Cisco APs ignore DHCP Option 43 and use CAPWAP UDP broadcasts

  • Background
    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-addresses on 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        <------
    

    Question

    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 .................................... 7.3.101.0
    Boot  Version ................................... 12.4.13.0
    

    The 4507R+E switches are running IOS-XE 3.4.0SG

  • Artanix

    Artanix Correct answer

    8 years ago

    Cisco LWAPs will do this process in order to try and find a controller:

    1. CAPWAP broadcast on the local subnet
    2. Check NVRAM for previous controllers/mobility groups and try those.
    3. OTAP (remove now though)
    4. DHCP Option 43/60
    5. 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

    Thanks. Looking further at the docs '1000 series' is indeed just 10xx, not 1xxx.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM