NT DHCP can do, why Cisco 6509 can not do?

[morriszhu]

Hello,

As I use 6509 DHCP services to support multi-vlan, when one user log on domain in one vlan using windows 98 platform, after he move the pc to another vlan he can not get IP and log on the domain again, even have already set 'portfast'. Only use WINIPCFG to release IP first, then get the IP - but it will confuse users.

Some expert told me that it might be related to windows platform: when network disconnected, windows would not take it as a release.

My question is, why the problem does not exist if using NT DHCP service? only if using Cisco DHCP service, the problem happens - seems not 100% related to windows98 ONLY.

Thanks,

Morris

[bsivasub]

when a user moves from one vlan to another vlan and assuming he is moving the cable, the user PC has to resend the DHCPOFFER. So even with portfast enabled you are not getting the IP address, that means that DCHPOFFER either is not sent and doesn't reach the server. What you need to do is to use a sniffer to span the port in which the user connects and see if the switch sees the DHCPOFFER packet. There is nothing switch can do to force the PC to do this.

[morriszhu]

Thanks for your suggestion, but my question is - if there is no DHCPOFFER sent out by windows98, why there is no problem for relogon in another network using NT DHCP, only problem for using 6509 DHCP.

So there must be some critical difference between NT DHCP and Cisco DHCP for such function.

Appreciate if have solution to it.

Morris

[mbhat]

The normal procedure that a DHCP client places an IP address request is as follows:

1.DHCP DISCOVER send by the win98 m/c

2.A DHCP server responds back with a DHCP OFFER

3.Then the DHCP client sends a DHCP REQUEST

4.The DHCP server sends back an ACK

Now when a Win98 machine goes down it informs the DHCP server that the IP is no more used and is made available for another machine on the DHCP server.

If the Windows machine is moved into another VLAN,without having gone through this procedure(DHCP RELEASE) it keeps the same IP address.

So when in the new VLAN it still has the IP of the older VLAN,and thus you will have to manually use the release and renew command so that it get an IP.

The switch does have anything to do with this.

Hope this helps.

[morriszhu]

Thanks, but the problem does exist when change to a vlan which DHCP service is run by NT DHCP server (not cisco DHCP service) - I can't understand it.

Morris

[mbhat]

Could you please find using a sniffer whether the Win98 client is sending the DHCP RELASE when it does down ?

[morriszhu]

Sorry - what I mean in last email is:

Thanks, but the problem does NOT exist when change to a vlan which DHCP service is run by NT DHCP server (not cisco DHCP service) - I can't understand it.

Morris

[msjouw]

Morris,

You can try to put this registry entry in that will force the release:

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP]

"ReleaseLeaseOnShutdown"=dword:00000001

But next to that can the Cisco DHCP server address be reached from the new VLAN?

The Windows machine will, depending on the lease time, first try to find the DHCP server it has gotten the address from and asks if it is still allowed to use it and only when it does not find that server, or when it get denied, it will do a new request.

Regards, Maarten Sjouw.

[morriszhu]

It works, but my question is to change thousands of PCs is an issue,

In addition, I have tried times that if change PC from Cisco DHCP vlan to WINDOWS NT vlan, the problem does not exist -

There is must some critical difference between NT DHCP server and Cisco DHCP server. or the latter has critical limitation on it or error configuration.

I am still confused on it.

Morris

[glen.grant]

i believe the above procedure is correct except when the user moves to a different vlan , if he does this then the dhcp server should send back a nack because it see's the frame has come from a different vlan , the win98 client then should then go thru the full dhcp discover ,offer,request ack phase and get a new address automatically without having to manually release the old address though this certainly would work .

[mbruner]

Actually, the same DHCP problems you are experiencing also happen with Windows based DHCP implementations (we experienced it when relocating our corporate office). Additionally, it is not specific to Windows 98, as it would probably occur in any DHCP enabled OS.

What's happening is that on bootup, the client is sending out a DHCPRequest with the "DHCP Requested Address" option set and its last IP address. If it doesn't receive a NACK from the DHCP server, it assumes it is okay to use its last IP address. This is probably caused by spanning tree delays in moving the port to the forwarding state. Its been my experience that this can sometime happen even with portfast enabled. It could also be caused by overlapping IP address scopes.

Microsoft says that the only work around is to release and renew the address after bootup.

For a more detailed explanation of what is happening on the client side of things, read article Q167014 on Microsoft's knowledgebase.

I hope this helps!

Best Regards,

Matt

[morriszhu]

Thanks, Matt - some one told me to disable the spantree on our Cisco 6509 and Cisco 3524, but it seems it is still there by default. In addition, by disabling the SPT, will the total network be shutdown by accident loop / flooding?

Morris

[morriszhu]

in addition, if it's caused by the port delay, why there is no problem for next and further reboot after release/renew?

Re: we have not set overlay IP pools for vlans, and have no idea about 'superscope' alleged by Q167014.

Thanks,

Morris

[mbruner]

The reason you don't see the problem reoccurring after the initial release/renew is because the client already has the IP addressing information for its current network from its last session.

When the machine boots, it sends out a request to see if it can keep its existing address. If the machine doesn't receive a NACK, it assumes its okay to keep using its cached IP addressing information and begins communicating to the network using those settings. As long as the address hasn't been assigned to another client, or the network addressing scheme hasn't changed, it should have no problems communicating on the network. Once it starts communicating, it can automatically renew its lease information normally.

Also, I'm not exactly sure how the machine would react if its lease expired between reboots, as I've never experienced it. We set our DHCP leases to a long enough period of time to keep this from happening on a regular basis. I suspect, however, than another release/renew could be necessary. Maybe someone else could verify this for us.

Hopefully, I'm explaining things clearly enough for you. Please let me know if you need me to clarify anything!!

Best Regards,

Matt

mbruner@web-host.net

[mbruner]

Using Cisco's network design model (core, distribution and access layers), I've heard it recommended that you disable spanning tree in the core layer. However, like you mentioned, you have to be VERY careful not to insert a loop into the network in absence of a loop detection and avoidance mechanism like STP. It could wreak havoc across your network.

The real issue is that the elapsed time between the NIC being initialized and the DHCP request is shorter than the time it takes the switch to initialize the port and put it into a forwarding state. Since we very rarely have the option to remove STP from our access layer switches, it is up to the OS companies to amend their boot processes to allow more time between the card initialization and the DHCP request.