Here's our topology:
1130 series APs -> 4400 series WLC (mgmt vlan 51, client dynamic interface vlan 360) -> Catalyst 4500 series -> DHCP server (vlan id 11)
We appear to be unable to relay DHCP requests from a wireless client on VLAN 360 to the DHCP server on VLAN 11, even though we have specified the DHCP server in both the configuration for this dynamic interface for this vlan and also in the DHCP Override section. The WLC can ping the DHCP server, and the Catalyst has 'ip helper-address' configured for VLAN 360 to the DHCP server's IP. You can manually assign an IP in the segment to the wireless client and it will work fine, so the appropriate vlans appear to have been trunked correctly. However, the problem is that the DHCP server never sees any traffic being relayed to it by the Catalyst. I was hoping someone had some ideas short of me having to sniff the traffic between the WLC and the catalyst to see if the WLC is failing to relay the DHCP broadcasts properly.
WLC's firmware version is 4.1.181. We'd like to avoid moving to 4.2 if we can.
Who is the vendor for the DHCP server. Some servers do not accept requests via proxy and that is how the controller makes the request on behalf of the client.
the DHCP server is ISC DHCPD 3.0.1. Now, I do have 'one-lease-per-client true' set on this pool, _but_ this does not explain why the dhcpd logs do not show any wlan-associated IPs trying to get an IP in the first place.
While there can be technical reasons for this, it's normally just a simple case of user error, especially if you're using pretty standard kit like Cisco, Microsoft, ete...
Double-check your configurations are all correct - VLANs all present, tagged / un-tagged on Switch & WLC, DHCP Scope enabled, Client Interface Subnet matches DHCP Subnet, etc...
Also, check that a wired client in VLAN 360 can receive a DHCP Address - cutting the wireless element out will help you to identify where the problem lies.
Verify that vlan 360 is forwarding on the correct ports on the Cat4500 and all the other switches. Make sure vlan 360 is also allowed on the trunk ports especially on the ports that the WLC connect to.
Since I can manually configure the wireless client to have an IP in vlan 360 and everything works fine that way, then it appears that vlan 360 is trunked correctly.
You are correct. What I would do next is verify that the dhcp is correctly configured on the interface and that dhcp overide is no configured on the wlan ssid. I would restart the dhcp services also.
Because the interface dhcp settings didn't work, I added the same dhcp server to the dhcp override. I can back out this change, but obviously it still isn't working.
At this point we're going to sniff between the WLC and the Catalyst to see if there actually any encapsulated DISCOVER packets.
EDIT 2007-11-26 1450 EST
We can't sniff the traffic easily at this point because we have the 2 interfaces on the WLC aggregated via EtherChannel and the Catalyst doesn't allow you to mirror it.
I powered up a new controller yesterday and ran in to the same problem. In my case DHCP snooping was causing the problem. I just disabled it on the switch that the controller was attached to. I suppose it has to do with the fact that the controller acts like a DHCP relay. I am going to look at it in more detail today, but you may want to check if you have snooping enabled on your switches.
We resolved this yesterday too.
That is exactly how the controller is behaving - as their own DHCP relays. The catalyst never participates as the ip address helper. (Basically the DHCP server sees the request as coming from the actual WLC virtual interface, not the catalyst). So we basically had to add a rule to the catalyst acl to allow dhcp traffic to pass. We also turned on directed-broadcast on for the WLC management vlan (just in case, but I don't know if that did anything). Disabling dhcp proxy on the WLC did not appear to do anything. This bug was probably fixed in the 4.2 firmware.
As I stated in my first post about this. It is a dhcp relaying issue. It needs to be addressed at the switch level. This has not been fixed and is not looked at as a bug. It is how the system conducts business. It is a key part of security that all traffic from the APs is handled by proxy before allowing a unverified client access to the actual wired network. The virtual interface handles proxy of dhcp and RADIUS requests. Only after these are verified does the client gain access to the network.
Well the option to have "disable dhcp proxy" as a configurable option on the WLC makes it just all the more confusing :)
And just to report on what we're seeing: the virtual interface for the wireless VLAN is proxying the DHCP (say 10.5.18.2 on vlan id 360) but the RADIUS request is being proxied by the "physical" management interface on 10.5.1.6 on the WLC management vlan id 51.
Anyway, thanks for all your help guys, things are working now.