cancel
Showing results for 
Search instead for 
Did you mean: 

AP Controller Discovery failing after moving subnet, DNS DHCP, SLP

AP Controller Discovery failing after moving subnet, DNS DHCP, SLP

Peter_D_
New Contributor

We have this problem https://extremeportal.force.com/ExtrArticleDetail?an=000077066 but have followed all advice on the forums to no avail.

We are undertaking a re-addressing of our wireless network and are moving AP's from one subnet/core to another. At one of our sites when we move the AP's to a new subnet they do not retain any DHCP information other than an IP address and gateway and get stuck in a loop running the discovery process. If we take a "Faulty" AP to our secondary site it will auto config with no issues.

Access points will connect if we manually assign the controller IP address but this is not practical for 300+ AP's.

Two controller site enterprise, both on separate C5210 WLC. We have an "identical" equipment setup at our secondary site and we do not see this issue there.

Things we have tried:

1. cset factory
2. cset authip - works fine, therefore no routing issue.
3. New AP MGMT Vlan setup
4. New DHCP Server
5. DHCP Server away from the network and switch, AP retains the DNS config etc works fine.
6. Laptop on the AP MGT Vlan connects to DHCP fine and gets all IP, DG and DNS info.
7. Reduce MTU - All local subnets but tried anyway.
8. DNS entry for "controller" exists.
9. SLP options set.

Packet capture at DHCP server show the DHCP Server ACK the INFORM with the information requested.

Packet capture at the Access Switch shows that DHCP Inform is received. AP Shows it receives the DHCP info but then seems to dump it and start auto config again.

Once the AP has an IP address (from DHCP) you can ping the controller and vice versa. All required ports are open on the controller.

GTAC have just said "assign authip manually", not really an answer for 300+ APs

Firmware on EWC and AP - 09.15.04.0011

The tail -f ap.log below shows the AP receiving the correct DHCP Inform but then discarding that information except for the IP

3b0e6cea01d84c33a23b52e271c576c6_RackMultipart20161205-67444-rsribt-DHCP_Issue_-_Notepad_2016-12-05_13-47-45_inline.png

7 REPLIES 7

Peter_D_
New Contributor
Thanks for all the replies. In the end this did not work and we have scripted adding the primary and secondary controller IP addresses to be added to the AP's without a reboot. When we migrate the AP to the new network they then can see the controller.

Drew_C
Valued Contributor III
Hi Peter, do you still need assistance with this issue?

Peter_D_
New Contributor
Thanks for the replies.

We have tried DHCP provided by either Server 2008 or Server 2012 R2 running in a HyperV environment. Option 78 has been set the same as in the working DHCP environment at our other site. Option 2 was tried as a test, it neither works with or without it.

5bf7026b83f5415288367f24bd2be901_RackMultipart20161206-40934-ccdguo-dhcp_issue_inline.jpg

We have tried that with no Option 2. It still does not work. We have also just tried a new DHCP Server (from a laptop) that is not in the HyperV environment but still running through our network and that works. Must be a DHCP Server issue but with HyperV only. Our second site runs the same DHCP System but on ESXI VM Hosts.
GTM-P2G8KFN