@mikek8877 wrote:
Hi cjoseph,
I understand what you posted. RAP is connected with IPSec, so it must not be accessed by any methods.
But network admins have monitoring tools for routers and stuff, and their thought may be extended if there is a convenient monitoring tools to detect non-functioning APs. Sometimes recovery speed is most important, rather than right approach to fix the problem properly.
Lastly, would you please introducing any commands from controller which can be helpful to obtain AP status to resolve the problem?
Is there any command to invoke AP core dump towards controller?
I am not saying that a RAP should not be accessed externally or even a regular Campus AP. There is just no interface besides polling that access point through the controller to obtain meaningful information. If an access point is loaded, management functions like polling will take a back seat to other functions. That does not mean that the access point is inoperable; that just means that it is proritizing functions. There is no definitive way to poll an AP to determine whether it is up or not, outside of the doing it through the controller (ping does not count in this case). Since the controller itself determines if an access point is up or not through normal communication with the AP, it is supposed to detect whether not the AP is up way before a human could attempt to poll it.
We can run through a long list of commands to run on that AP, but polling all access points for that could increase utilization and not buy you anything. You can run any command that begins with "show ap" to poll information, if that is the plan.
Long story short, we need to ensure that the software works, like it should in this scenario and not put the burden on our users to troubleshoot a non-functioning ap.
An excellent troubleshooting document, from clients, to AP to controller is here: http://community.arubanetworks.com/aruba/attachments/aruba/campus-wlan-and-high-density-wi-fi/112/1/Troubleshooting%20Cheat%20Sheet-Aug2007.pdf