HeadlessChicken

This problem was caused by the IP range being in a superscope. Remove the superscope, all OK.

This is still buggered, if anybody has a clue.

Ok - Eyeball. On the test environment everything is the same - same cisco IOS, same config, same server 2003 r1 sp2. When you say "so once it has the first address, is on the VLAN and then releases it it cannot then obtain the second address?" that's not correct. When the device has been unplugged and plugged in again, it fails at the first step, because the address which is now offered the FIRST time is the address which was offered the SECOND time previously. Then the cisco router further down (which is transitting the dhcp offer) matches that address in it's config and applies a layer 2 tag, which prevents the device from seeing the offer. Basically the DHCP server seems to ignore the IP address from the ip-helper in the DHCP discovery which should enable it to choose which scope to pick from, and instead use the mac address which it now knows, and choses from the wrong (at that time) scope. In my test environment, even though the previous lease was not released when the device was rebooted, the server behaves correctly, and issues from the scope as per the ip-helper address in the dhcp discovery. Stoic Joker, the device is PoE so when the cable is removed and reinserted, the device boots from fresh and kicks off the original process.

I have a problem where a DHCP client fails to boot the 2nd time around, once 2003 Server has learned the MAC address.... A device boots on the lan (not currently known to DHCP server) and sends a DHCP discovery containing a VCI option 60 to identify its device type. Server responds with VSI option 43 offering an address and a VLAN id. The device takes the address A, releases it etc and uses the option 43 to switch to the new VLAN where it sends a new DHCP discovery, all OK. Device now is on the correct VLAN with a new IP address B. If you unplug the device and plug it in again (no chance to release the dhcp address), the whole process should be followed exactly the same..you'll get the same IP address etc due to MAC address being known but that's OK. The problem is the 2nd time round the DHCP server sends a DHCP offer of address B (in the native VLAN). Further down the line, a Cisco router matches the ip address in its configuration and it applies layer 2 tagging (for the VLAN it should eventually end up in), so my client device sends a DHCP discover in the native VLAN but receives a tagged packet back for the offer, which it can't see as it's not switched to that VLAN yet. If you shutdown the VLAN on the Cisco box the problem disappears (so the offer is not then layer 2 tagged), but that's no solution. Correct procedure (for my device) is for the DHCP server to offer address A, then B, not offer B straight away because it's learned the MAC address. This 2 step process has to be followed. The first IP address doesn't really matter, it gets released anyway..the problem here is that the offer get changed to a different vlan because of it.. In a lab environment it all works fine. This problem is on customer premises. Does anyone know why this server is not behaving as my test server ? It needs to issue the initial IP address A every time, so that the packet remains untagged across the network.... Any ideas much appreciated !