Cisco APs ignore DHCP Option 43 and use CAPWAP UDP broadcasts
I am trying to redeploy Cisco 1242 LWAPs on new Cat4507R+E switches, which means the IP address of the WLC is changing for that LWAP. For some reason, I have to configure
ip helper-addresseson my AP vlan to jumpstart communication between my Cisco AP1242 APs and the WLC; I have DHCP (with Option 43) on the AP Vlan, but I don't know why the AP is ignoring the DHCP Option.
DHCP runs on Cisco 4507R+E switches... The switches are configured with DHCP Option 43 (Single WLC address: 10.19.3.209 / hex: 0a13.03d1) and Option 60...
ip dhcp pool lwap_v99 network 10.1.1.0 255.255.255.0 default-router 10.1.1.254 dns-server 10.19.26.225 option 43 hex f104.0a13.03d1 option 60 ascii "Cisco AP c1240" !
The AP is getting a DHCP address...
WL-DST2#sh ip dhcp bind Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type Hardware address/ User name 10.1.1.17 0158.8d09.03ec.de Jun 28 2013 03:07 AM Automatic WL-DST2#
Using wireshark on Supervisor 7, I can see that the APs are ignoring Option 43; instead, the APs (for example, 10.1.1.17) are broadcasting CAPWAP packets and never send a unicast request...
WL-DST2#sh monitor capture file bootflash:mycap.pcap | i CAPWAP 681 597.979997 10.1.1.17 -> 10.19.26.225 DNS Standard query A CISCO-CAPWAP-CONTROLLER 684 600.977998 10.1.1.17 -> 10.19.26.225 DNS Standard query A CISCO-CAPWAP-CONTROLLER 689 603.977998 10.1.1.17 -> 10.19.26.225 DNS Standard query A CISCO-CAPWAP-CONTROLLER 705 615.975999 10.1.1.17 -> 255.255.255.255 CAPWAP CAPWAP-Control - Discovery Request 715 625.974001 10.1.1.17 -> 255.255.255.255 CAPWAP CAPWAP-Control - Discovery Request 728 635.970995 10.1.1.17 -> 255.255.255.255 CAPWAP CAPWAP-Control - Discovery Request
I validated that DHCP is offering Option 43 in the DHCP Offer message...
Option: (t=43,l=13) Vendor-Specific Information Option: (43) Vendor-Specific Information Length: 13
I tried setting both
option 43 ascii "10.19.3.209"and
option 43 hex f104.0a13.03d1... both of these are ignored by the AP. I also tried [hard-resetting the AP with the mode button].
Workaround for non-functional DHCP Option 43 & 60
At this point, the only thing that makes the AP talk to the WLC is a helper-address (for udp/5246 & udp/5247) on the Vlan...
! interface Vlan99 ip address 10.1.1.252 255.255.255.0 ip helper-address 10.19.3.209 <------ no ip redirects no ip unreachables no ip proxy-arp standby 99 ip 10.1.1.254 ! ip forward-protocol udp 5246 <------ ip forward-protocol udp 5247 <------
How do I use DHCP to make these APs use unicast packets to initiate CAPWAP with the WLC? FWIW, I don't want to use DNS to direct the APs to the WLC.
Version information for the AP / WLC system...
(Cisco Controller) >show ap config general AP588d.0903.ecde ... S/W Version .................................... 188.8.131.52 Boot Version ................................... 184.108.40.206
The 4507R+E switches are running IOS-XE 3.4.0SG
Cisco LWAPs will do this process in order to try and find a controller:
- CAPWAP broadcast on the local subnet
- Check NVRAM for previous controllers/mobility groups and try those.
- OTAP (remove now though)
- DHCP Option 43/60
- DNS Lookup for "CISCO-CAPWAP-CONTROLLER.localdomain"
If the controllers are on the local subnet, then it will find those via broadcast, if you have an IP helper pointing to the controller as well as ip forward-protocol on 5246/12223 it will find it that way too.
The APs also keep previously joined controllers in NVRAM, and will connect to those before option 43.
Note that these will happen in this order! I had an issue installing a new WLAN whilst a legacy WLAN was in use, and the IT guy had plugged in some of the APs, so they were going to the WLCs in their NVRAM instead of using option 43 like I had wanted. I factory reset on the APs solved this however.
Reference is here (quite old): http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a00806c9e51.shtml
I'm curious about something... do you know whether the big indicator LED on the AP1242 is supposed to turn amber or magenta when the unit is reset to factory defaults? I tried an experiment after posting and held the mode button down for about 20 seconds... at that point it turned magenta... if that is how long it takes the AP to reset to defaults, then it never got reset the last time I followed these instructions.
I've had varying success using that reset function. Magenta puts it into ROMMON mode I believe. Its best to reset to factory from the WLC, or telnet onto it and delete config.txt and also do "clear capwap private-config", then reboot. That should force it to do a completely fresh discovery and associate to the controller. It will probably still use broadcast, as that is the first thing it will try.
I don't think magenta is rommon, b/c it booted right up after I did that... I will open a case and ask what magenta meant unless someone knows offhand
Just realised, you need to be holding the mode button when plugging the power in. No just doing it while its on.
Yes, that's what I did... pulled the PoE out, held the tip of a key on the mode button and kept it there after I re-inserted the PoE.
https://supportforums.cisco.com/docs/DOC-21897 says that purple flashing should be factory reset or ROMMON, but it also says if ethernet is connected, it doesn't work properly, so you'll need a PSU plugged into it
I did hold the button for 20 seconds, and maybe you could call magenta "purple"... it looked more pink / magenta to me... all I know is the LAP booted after I released the button, which is not what I would expect if it went into rommon
Essentially you're saying in the comments to be 100% sure that I "reset the LAP", which is the answer which solved my problem yesterday... it boots with DHCP now. I still want TAC to explain the mode button question
For posterity, does this mean the 1k works with subID 241 as per your post? And does not require subID 102 as per documentation?
@ytti, it is not an aironet1000 and the dhcp configuration in my question is exactly what is working as I type this