When APs don't register to a controller and have a static IP
I ran into an interesting problem last Monday (02/01/10) at work - someone had deployed APs at a remote location and configured them as autonomous APs. I performed a quick lightweight upgrade on them, and made the mistake of leaving static IPs on them.
The upgrade tool asks for your WLC address so I thought that would prime the APs with that address for the controller... Wrong. As soon as the APs booted to their lightweight IOS (the standard recovery image) I lost connectivity with them (no DHCP so option 43/60 is not available. APs are on a different domain than the switch - why it kept this but not snmp and passwords is irritating - so controller DNS didn't work). Passwords were of course reset, so telnet/ssh responded with "password required but none set." SNMP was also reset... I thought I had lost connectivity to them and would be required to ship out new APs!
In reviewing some of the Cisco literature, though, I found a cool little workaround. You can set the IP helper-address to the IP address of the controller, and then use the "forward protocol" command to forward all CAPWAP/LWAPP traffic to the IP helper-address, i.e. the controller (protocols 12222, 12223 for LWAPP and 5246, 5247 for CAPWAP)! Once connectivity was re-established to the APs, I set them to DHCP and removed the forward protocol commands and set the IP helper-address back to the DHCP server. Problem solved without sending new APs!
The upgrade tool asks for your WLC address so I thought that would prime the APs with that address for the controller... Wrong. As soon as the APs booted to their lightweight IOS (the standard recovery image) I lost connectivity with them (no DHCP so option 43/60 is not available. APs are on a different domain than the switch - why it kept this but not snmp and passwords is irritating - so controller DNS didn't work). Passwords were of course reset, so telnet/ssh responded with "password required but none set." SNMP was also reset... I thought I had lost connectivity to them and would be required to ship out new APs!
In reviewing some of the Cisco literature, though, I found a cool little workaround. You can set the IP helper-address to the IP address of the controller, and then use the "forward protocol" command to forward all CAPWAP/LWAPP traffic to the IP helper-address, i.e. the controller (protocols 12222, 12223 for LWAPP and 5246, 5247 for CAPWAP)! Once connectivity was re-established to the APs, I set them to DHCP and removed the forward protocol commands and set the IP helper-address back to the DHCP server. Problem solved without sending new APs!
Labels: 12222, 12223, 5246, 5247, autonomous AP, CAPWAP, dhcp, ip helper-address, lightweight AP, LWAPP, option 43, option 60, WLC
posted by Tim at
8:29 AM
