18

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

0

4 Answers 4

12

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

11
  • 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. Jun 28, 2013 at 9:36
  • 3
    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.
    – user275
    Jun 28, 2013 at 9:44
  • 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 Jun 28, 2013 at 9:49
  • Just realised, you need to be holding the mode button when plugging the power in. No just doing it while its on.
    – user275
    Jun 28, 2013 at 10:11
  • 1
    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 Jun 28, 2013 at 10:41
2

I can't speak to Option 43 being ignored but can you put in a DNS entry for CISCO-CAPWAP-CONTROLLER.domain-given-by-dhcp and point it at 10.19.3.209? That should let them unicast to the controller.

2
  • 1
    Ok, I knew that... I just didn't think that someone would actually propose this as an answer when I spent the entire question talking about DHCP... I will reword my question :-) Jun 27, 2013 at 17:18
  • the DNS entry is a pain across a large campus network with multiple controllers and all though. You either let them all go to one controller then re-assign them manually to the controller you really want them to be one. Thats what we do here....:| I haven't had time to actually figure out option 43 and etc properly. eager to see the answer!
    – knotseh
    Jun 27, 2013 at 17:48
2

Was looking for some other stuff and ran across this post. A few suggestions/thoughts in case anyone else runs across this.

On the DNS issue, agreed, it can be a pain in a larger environment to assign all AP's to one Controller. You could potentially use either IP Anycast for this, if you've set up your management networks for Anycast, or use round-robin DNS for load-sharing amongst the controllers.

On the DHCP Option 43, I am running a pair of ASA's (5505's w the onboard PoE ports) for a set of AP's and have the following syntax:

  dhcpd option 43 hex f104.c0a8.f92a 

Looks pretty like what the OP has, aside from different IP's. The decimal->hex matches so that doesn't appear to be the issue. I would take a look at the local console of the AP when it boots up.

e.g. Does it look more like this:

*Mar  1 00:17:34.521: %CAPWAP-5-DHCP_RENEW: Could not discover WLC using DHCP IP. Renewing DHCP IP.
Not in Bound state.
*Mar  1 00:17:43.117: %CAPWAP-3-ERRORLOG: Invalid event 38 & state 2 combination.
*Mar  1 00:17:43.150: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0 assigned DHCP address 192.168.253.67, mask 255.255.255.0, hostname AP1####.####.####

Translating "CISCO-CAPWAP-CONTROLLER"...domain server (192.168.253.1) [OK]

*Mar  1 00:17:51.024: %CAPWAP-3-ERRORLOG: Did not get log server settings from DHCP.   <---

or more like this:

*Mar  1 00:14:00.251: %LWAPP-3-LWAPP_INTERFACE_GOT_IP_ADDRESS: Interface GigabitEthernet0 obtained IP from DHCP...
*Mar  1 00:14:10.930:  status of voice_diag_test from WLC is false
*Mar  1 00:14:10.987: Logging LWAPP message to 255.255.255.255.

Translating "CISCO-CAPWAP-CONTROLLER"...domain server (192.168.253.1) [OK]

*Mar  1 00:14:22.010: %CAPWAP-5-DHCP_OPTION_43: Controller address 192.168.249.42 obtained through DHCP     <-------
*Dec 10 10:57:48.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 192.168.249.42 peer_port: 5246
*Dec 10 10:57:48.000: %CAPWAP-5-CHANGED: CAPWAP changed state to  
*Dec 10 10:57:48.509: %CAPWAP-5-DTLSREQSUCC: DTLS connection created sucessfully peer_ip: 192.168.249.42 peer_port: 5246
*Dec 10 10:57:48.509: %CAPWAP-5-SENDJOIN: sending Join Request to 192.168.249.42
*Dec 10 10:57:48.509: %CAPWAP-5-CHANGED: CAPWAP changed state to JOIN

You might also try a "show capwap client config" command, to show the local configuration on the AP. e.g.

AP3502-02#show capwap client config 
configMagicMark         0x#########
chkSumV2                ####
chkSumV1                #####
swVer                   7.0.250.0
adminState              ADMIN_ENABLED(1)
name                    AP3502-02
location                ASA02
...
Heart Beat Timer        30 secs
Led State Enabled       1 
Primed Interval         0 
AP ILP Pre-Standard Switch Support Disabled
AP Power Injector Disabled
Infrastructure MFP validation Enabled
Configured Switch 1 Addr 192.168.249.44      <-------
non-occupancy channels: 
Ethernet (Duplex/Speed) auto/auto 

Slot 0
        adminstate              ADMIN_ENABLED(1)
        radioType               RADIO_TYPE_80211bg
...
-1

option 43 hex f104.0a13.03d1 is not correct use this for

option 43 hex f1080a1303d1

1
  • 2
    You could improve your answer by editing it to add more details to make it more useful both for the original poster and future users. Typically short answers like this could provide reasoning why you believe this is the answer, more explanation about the concepts mentioned, references/links to supporting resources, or applicable examples.
    – YLearn
    Feb 18, 2016 at 18:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.