cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
29143
Views
10
Helpful
39
Replies

2820i AP, 5508 WLCs, DHCP Relay - DHCP NOT working

Sean Haynes
Level 1
Level 1

Morning

We have 2 Cisco 5508 WLCs, we have around 50 1142N APs across the campus, all of which use DHCP and PoE without any issues.

The WLCs are configured as DHCP relay agents which works perfectly well for both the APs and Clients.

 

We had a need for an additional AP, so we purchased a 2820i, ran a new cable which terminated into a Cisco 3750 switch which is already supporting several of the said 1142n APs.

The 3750 switch does not provided enough power for the newer AP so I also purchased an inline power injector - which works fine.

 

I have never had to pre-stage an AP before, so as before the new AP was installed and powered on. I was expecting it to mimic what every other AP has done for the last several years - get a DHCP address and join the controller  - NOPE!!!

 

So in summary:

Yes, all other APs joined to that switch are able to get a DHCP address, all other APs tested on the very same port of that same switch are able to get a DHCP address - just not this AP.

If I console into the AP and debug DHCP events I can see that DHCP requests are indeed being sent, but not responded to:

 

[02/20/2018 23:26:26.7100] wired0 emac 2: link up
[02/20/2018 23:26:26.7600] wired0: link up
[02/20/2018 23:26:26.8100] wired0: started
[*02/20/2018 23:26:26.8635] aptrace_register_sysproc_fn: duplicate registeration for 'wired'
[*02/20/2018 23:26:27.6503] chatter: DHCP-EVT: Sending DHCP discover packet length 346 bytes
[*02/20/2018 23:26:27.6503] chatter: DHCP-PAK: Sent DHCP_DISCOVER pak:
[*02/20/2018 23:26:27.6503] chatter: sent pkt source: 0.0.0.0, destination: 255.255.255.255
[*02/20/2018 23:26:27.6503] chatter: UDP sport: 68, dport: 67, length: 312
[*02/20/2018 23:26:27.6503] chatter: DHCP op: 1, htype: 1, hlen: 6, hops: 0
[*02/20/2018 23:26:27.6503] chatter: xid: 7cd9e03e, secs: 0, flags: 0
[*02/20/2018 23:26:27.6503] chatter: client: 0.0.0.0, your: 0.0.0.0
[*02/20/2018 23:26:27.6504] chatter: srvr: 0.0.0.0, gw: 0.0.0.0
[*02/20/2018 23:26:30.8648] Waiting for uplink IPv4/IPv6 configuration
[*02/20/2018 23:26:35.8657] Waiting for uplink IPv4/IPv6 configuration
[*02/20/2018 23:26:40.8666] Waiting for uplink IPv4/IPv6 configuration
[*02/20/2018 23:26:41.8667] Resetting wired0, if[02/20/2018 23:26:41.9000] wired0: stopped
config down up

 

If from console I do a 'sho arp', it does just that and returns dozens of IP addresses from across the wireless network, so broadcasts are working, it just can't seem to get it's own IP address via a DHCP broadcast.

I have run 'Wireshark' on both DHCP servers and can see no requests from the AP's MAC address, though I can see other requests from devices on the wireless network being properly relayed through the controllers to the DHCP servers. So it can't be a relay problem.

 

If from console I enter a static address, subnet mask and the IP of the default gateway on the AP - it will IMMEADIATELY find both controllers and go through the automated process of joining with out issue. Clients are then able to use that AP, again without issue.

 

[*02/21/2018 10:33:53.4489] AP IPv4 Address updated from 0.0.0.0 to 172.20.255.230
[*02/21/2018 10:33:53.4561] dtls_init: Use MIC device cert
[*02/21/2018 10:33:53.4564] dtls_init: Use MIC device cert private key
[*02/21/2018 10:33:53.4565]
[*02/21/2018 10:33:53.4565] CAPWAP State: Init
[*02/21/2018 10:33:53.4569]
[*02/21/2018 10:33:53.4569] PNP is not required, Starting CAPWAP discovery
[*02/21/2018 10:33:53.4569]
[*02/21/2018 10:33:53.4571]
[*02/21/2018 10:33:53.4571] CAPWAP State: Discovery
[*02/21/2018 10:33:53.4617] Discovery Request sent to 172.20.255.201, discovery type STATIC_CONFIG(1)
[*02/21/2018 10:33:53.4630] Discovery Request sent to 255.255.255.255, discovery type UNKNOWN(0)
[*02/21/2018 10:33:53.4630]
[*02/21/2018 10:33:53.4630] CAPWAP State: Discovery
[*02/21/2018 10:33:53.4635] Discovery Response from 172.20.255.201
[*02/21/2018 11:05:01.0004] Discovery Response from 172.20.255.202
[*02/21/2018 11:05:01.0001] Discovery Response from 172.20.255.201
[*02/21/2018 11:05:01.0000]
[*02/21/2018 11:05:01.0000] CAPWAP State: DTLS Setup
[*02/21/2018 11:05:01.1328] dtls_load_ca_certs: LSC Root Certificate not present
[*02/21/2018 11:05:01.1328]
[*02/21/2018 11:05:01.2326]
[*02/21/2018 11:05:01.2326] CAPWAP State: Join
[*02/21/2018 11:05:01.2339] Sending Join request to 172.20.255.201 through port 5264
[*02/21/2018 11:05:01.2373] Join Response from 172.20.255.201
[*02/21/2018 11:05:01.3126] HW CAPWAP tunnel is ADDED
[*02/21/2018 11:05:01.3258]
[*02/21/2018 11:05:01.3258] CAPWAP State: Image Data
[*02/21/2018 11:05:01.3562] do NO_UPGRADE, part2 is active part
[*02/21/2018 11:05:01.3609]
[*02/21/2018 11:05:01.3609] CAPWAP State: Configure
[*02/21/2018 11:05:01.3640] NO-ENC-PROVIDER for DOT11R_WLC_MAC_IP_PAYLOAD
[*02/21/2018 11:05:02.0198] Started Radio 0
[*02/21/2018 11:05:02.0389] DOT11_DRV[0]: set_channel Channel set to 1
[*02/21/2018 11:05:02.9272] DOT11_DRV[0]: set_channel Channel set to 1
[*02/21/2018 11:05:04.1417] Started Radio 1
[*02/21/2018 11:05:04.1647] DOT11_DRV[1]: set_channel Channel set to 36
[*02/21/2018 11:05:05.0840] DOT11_DRV[1]: set_channel Channel set to 36
[*02/21/2018 11:05:06.3229] Discarding msg CAPWAP_WTP_EVENT_REQUEST(type 9) in CAPWAP state: Configure(8).
[*02/21/2018 11:05:06.3230] Discarding msg CAPWAP_WTP_EVENT_REQUEST(type 9) in CAPWAP state: Configure(8).
[*02/21/2018 11:05:06.3231] Discarding msg CAPWAP_WTP_EVENT_REQUEST(type 9) in CAPWAP state: Configure(8).
[*02/21/2018 11:05:06.3231] Discarding msg CAPWAP_WTP_EVENT_REQUEST(type 9) in CAPWAP state: Configure(8).
[*02/21/2018 11:05:06.3232] Discarding msg CAPWAP_WTP_EVENT_REQUEST(type 9) in CAPWAP state: Configure(8).
[*02/21/2018 11:05:06.4150] DOT11_DRV[0]: set_channel Channel set to 1
[*02/21/2018 11:05:07.4264] DOT11_DRV[1]: set_channel Channel set to 36
[*02/21/2018 11:05:08.3442] DOT11_DRV[1]: set_channel Channel set to 36
[*02/21/2018 11:05:09.4703]
[*02/21/2018 11:05:09.4703] CAPWAP State: Run
[*02/21/2018 11:05:09.5009] CAPWAP HW tunnel params changed, UPDATING the existing
[*02/21/2018 11:05:09.5559] AP has joined controller Cisco5508_WLC_Primary

 

I have checked the VLAN config which is on the switches, made sure the IP Helper Addresses are correct, basically gone through everything I can think of - still no closer to figuring this out. It has to be said the Cisco literature is pretty base and of no use when troubleshooting this issue.

Anyone else had this problem?

 

 

 

 

 

39 Replies 39

Console into the 2800 and post the complete output to the command "sh version".

Here you go:

u-boot>> sh
HUSH_VERSION=0.01
u-boot>> version

U-Boot 2013.01-g729a7b4 (Dec 05 2016 - 23:44:32) SDK version: 2015_T2.0p10
arm-openwrt-linux-uclibcgnueabi-gcc (OpenWrt GCC 4.7.1 r48430) 4.7.1
GNU ld (GNU Binutils) 2.24.0

If the AP is in u-boot, what happens if you enter the u-boot command of "dhcp"?

Here:

u-boot>> dhcp
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5

Retry count exceeded; starting again
mvEgigaInit: egiga1 mvNetaPortEnable failed (error)
mvEgigaInit: egiga1 failed
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5

Retry count exceeded; starting again
mvEgigaInit: egiga1 mvNetaPortEnable failed (error)
mvEgigaInit: egiga1 failed

The issue is, that the dhcp client on the AP is crashing. Therefore the AP does not get an IP. Our setup works properly with "older" APs (3702).

In u-boot, when you enter the command "dhcp" does the AP eventually get an IP address or not?
1800/2800/3800 have a bug in the OS and they don't like asymmetric routing, which look like this is what you've got.

No, the APs do not get an IP.
What makes you think that there is an issue with asymmetric routing?
The controller and the AP are in the same subnet.

DHCP is not enabled.
In u-boot, when the "dhcp" command is invoked, the AP will act like a "computer" (and not an AP). It will request for an IP address (regardless of DHCP Option is enabled or not).
If in u-boot and the AP doesn't get an IP address then DHCP on that subnet is not enabled.

Thanks, that's valuable input! I need to check on that.
However, it's strange... DHCP is definitely enabled. My computer gets an IP, other APs (older models) also get IPs.

u-boot is like the "base" OS of the AP. WHen the finishes booting in u-boot, it will load the OS and then the AP boots up as an AP.
u-boot doesn't require DHCP Option 43. u-boot will take any DHCP being offered like your corner vagabond.

Any update? Happening to us now to. I reset it 4 times and just keep getting a message Restart DHCP CLient

 

Review Cisco Networking for a $25 gift card