How would you begin to troubleshoot an AP that does not register with a WLC issue? You can start by using one of the most basic but important debug commands: debug lwapp events enable.
Note If you are enabling large amounts of debugs or global debugs—debugs that apply to all devices—the console can become unresponsive because of the vast output and results in the buffering filling up. In circumstances like this, it is best to define a syslog server to output the debugs—available in Version 5.2. For any version prior to that and as another alternative, it is best to filter the debugs with a MAC address—debug mac addr 00:00:00:00:00:00—and then enter your remaining debugs.
The debug lwapp events enable WLC command output in Example 7-7 shows that the LAP is registered to the WLC.
Example 7-7 Sample Output from debug lwapp events enable
The output in Example 7-8 shows these useful WLC debug commands in action:
■ debug pem state enable: Displays the access policy manager state machine debug options
■ debug pem events enable: Displays policy manager events
■ debug dhcp message enable: Shows the debug of DHCP messages that are exchanged to and from the DHCP server
■ debug dhcp packet enable: Shows the debug of DHCP packet details that are sent to and from the DHCP server
Example 7-8 Debug PEM and DHCP Debug Output
Example 7-8 Debug PEM and DHCP Debug Output
In addition to the aforementioned debug commands, you can use the following debug commands to troubleshoot your configuration:
■ debug lwapp errors enable: Shows output of the debug of LWAPP errors
■ debug pm pki enable: Shows the debug of certificate messages that are passed between the AP and the WLC
One of the major issues to notice is that the controller does not defend the AP-Manager address. If an IP address is duplicated, it can take some time to resolve because of the way the controller handles the issue—or does not handle, in this case. This problem manifests itself in some odd circumstances. On the positive side, this issue has been resolved but still exists in older code versions. This issue is a result of bug CSCsg75863.
If the user accidentally injects a device on the subnet that uses the AP-Manager IP address of the controller, the Address Resolution Protocol (ARP) cache on the default gateway router is refreshed with the wrong MAC address. When this occurs, the APs can no longer reach the controller and drop into their discovery phase to look for a controller. The APs send discovery requests, and the controller responds with discovery replies, but the join requests never reach the AP-Manager interface of the controller because of the bad ARP entry on the gateway router. After the default 4-hour ARP refresh interval, the APs join the controller if the device is removed.
A workaround for this issue is to configure the static ARP entries on the gateway router of the controller for these IP addresses:
■ Management IP address: Customers gain access to the graphical user interface (GUI) from another subnet, and the controller receives the AP discovery requests.
■ AP-Manager IP address: APs join the controller from another subnet.
■ Every Dynamic interface IP address: Packets from other subnets reach the dynamic interface of the controller.
DHCP packets transmit from the interface of the wireless client. Telnet or SSH to the gateway address of the controller, and use the arp ip address hhhh.hhhh.hhhh command to add the ARP entries. Use the ping command on the default router of the controller to the different addresses to refresh the ARP cache on the router. To discover the MAC addresses, use the show arp | include ip address command.
Summary
Once again, understanding the architecture of the product and how it works plays a key role in allowing you to design the best topology for your network and troubleshoot it. Keeping abreast on the changes of the product as new controllers are introduced is also important. (An example would be the new 5508 that no longer has an AP-Manager interface.) That knowledge can change your understanding of how the system works and the way you intend to troubleshoot it. As the product grows and changes are made to improve the overall system, you are forced to educate yourself. Knowing the product prior to any implementations makes the understanding of why those changes were made much easier to understand. Nevertheless, keeping up with the product and understanding its benefits always places you in the best position even if your objective is for designing or troubleshooting an issue.
