HeadlessChicken Posted June 30, 2007 Share Posted June 30, 2007 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 ! Link to comment Share on other sites More sharing options...
eyeball Posted June 30, 2007 Share Posted June 30, 2007 so once it has the first address, is on the VLAN and then releases it it cannot then obtain the second (B) address?just clarify that for me, also on the clients site and your test environment are u using the same make/model of managed switch to create the vlans?thanks Link to comment Share on other sites More sharing options...
Stoic Joker Posted June 30, 2007 Share Posted June 30, 2007 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.Not exactly ... If you unplug the device and then plug it in again it will be running a DHCP renewal which is a 5 step process not the usual (never been there before) 7 step process. The (first two) steps that are skipped during renewal are the broadcast packets that locate the DHCP server. What impact that will have on DHCP Scope Classes (which I assume you're using) I'm not sure, but I thought the 5 step -vs- 7 step distinction might be worth pointing out. Link to comment Share on other sites More sharing options...
HeadlessChicken Posted June 30, 2007 Author Share Posted June 30, 2007 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. Link to comment Share on other sites More sharing options...
HeadlessChicken Posted July 2, 2007 Author Share Posted July 2, 2007 (edited) This is still buggered, if anybody has a clue. Edited July 2, 2007 by HeadlessChicken Link to comment Share on other sites More sharing options...
HeadlessChicken Posted July 15, 2007 Author Share Posted July 15, 2007 This problem was caused by the IP range being in a superscope. Remove the superscope, all OK. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now