Having an issue with the 9800 controller setup in sso, where I cant get clients to get a dhcp reply. The aps are up.. the ssid are up.. but external dhcp not so much
I have tried setting it up globally under policy without effect. I have tried setting up the svi with an helper and I can reach the dhcp server . but traffic comes back on the mgmt intf (ap intf) been looking everywhere for some good guides on the 9800 regarding dhcp externally (also the vrf options) does anyone have any good tips here=?
Do you see any logs
follow below gude
It would be really useful if someone could give a quick breakdown on the difference between AireOS config and IOS XE ....not getting anywhere fast with the documentation. Thanks.
I'm also having an issue with a new 9800-L not passing DHCP requests properly. I'm sure it's a config issue. On AireOS the relay/proxy setup was all in the interface settings. You could have it source DHCP requests or ignore and send the requests through the connected switch, which is what I do.
In the 9800, it looks like the general policy screen has a DHCP text box, but that does nothing. I've also tried adding SVIs on the 9800 and put in helpers there just to see if it would work and it does not. A client debug shows a broadcast DHCP request going out, but nothing coming back. Trunks look good and an AireOS WLC connected to the same switch with the same VLANs is sending DHCP requests fine.
I am in the same situation on a new 9800 deployment. I tried several configuration, just like kdavison suggests. I did some packet captures on the L3 router and the WLC is clearly not relaying the DHCP request. We had to enable DHCP relay on the L3 router instead. It was working fine with a previous AireOS controller in the same subnet.
DHCP relay however works when using an internal DHCP pool on the 9800 and relaying to the Loopback of the 9800.
We are running version 16.12.1s.
My problem is that the DHCP Request of the client never makes it out of the controller because I cannot not see any UDP/67 while capturing packet at the L3 router (actually a firewall). Sure you can have issues with option 82 but this is a different matter here.
I will try and replicate the issue on the lab, maybe I missed something on the customer configuration...
We have the same issue here.
In my case, the DHCP server resides in the same network as the controller. I can see the requests reach the DHCP server and being processed, however, the answer never seems to reach the controller.
As far as I found out (didn't verify this by packet capture) the problem is a change in the way packets are routed.
Within AireOS, the default gateway of the VLAN from which the original request came was used to send the relayed request to the configured dhcp server.
Now, with IOS XE, the default gateway of the system is used (you can not enter any default gateway for VLANs within IOS XE, only the IP and netmask.). So the relayed DHCP packets are send to the DHCP server using the controllers routing table, are being processed by the DHCP server and I believe the DHCP server is sending the answer back to the IP of the controllers SVI in the originating VLAN of the DHCP request, which is embodied in the relayed DHCP request. The controller does not expect the answer on its SVI interface and drops the packet.
On the controller, I had to add a static route to the dhcp server using the gateway of the VLAN and all starts working. But that means you will be unable to use the same DHCP server for different VLANs. And in my case, the radius service is running on the same boxes as the DHCP service, so I had to add IP aliases to the boxes to make this all work together. I see this behavior as a massive setback to the old AireOS-based controllers.
Hope I made myself clear, sorry for my bad english.
Edit/Addition: Its worse than I thought. I now did some packet capturing which confirmed my suspicions.
The controller sends out the relayed DHCP packet using its routing table instead of using the default gateway of the originating VLAN (which can be entered nowhere in the controller - or I didn't find it yet). To make this even worse, its using the IP address of its SVI interface as source address regardless of the interface it is sending the packet out. This is doomed to fail.
Edit2: I contacted Cisco TAC about this and they confirmed this behavior is a known bug (CSCvr86358). Suggested workaround is to delete the SVI on the controller and using the upstream routers dhcp forwarding capability. This works for me so far.
I Also have this issue. I see the DHCP server reply's to the wireless management interface of the controller. Then a pcap on the client shows that the DHCP offer is being send from the controller wireless management interface to the client. BUT the client dosent accept the dhcp OFFER. ??
Not too sure what happening here.
I had the same problem, Cisco TAC recommended that I set the DHCP helper address on the gateway IP. I also had to specify the Source-Interface Vlan under the Advanced tab of the SVI on the controller. This corrected the problem for me.