Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

dhcp problem

Hi. We are having a problem with dhcp, which is running on Win NT 4. We have Cisco 6500 switches on 7 subnets at this location. If a user shuts down and moves their laptop to another floor/subnet and starts up again, they do not get a valid ip address, they get a 169.x.x.x address. They must reboot, or disable/enable their network card to get a valid address for that subnet. If they do an ipconfig /release before shutting down, everything works fine. This is also a problem for people coming here from other offices, they have to reboot to get a valid address.

I can't find much useful info on MS's website, so I thought I would try here. Thanks for any information you can provide.

Tim

1 ACCEPTED SOLUTION

Accepted Solutions
Purple

Re: dhcp problem

Make sure you don't have a broadcast address specified on your interfaces such as 169.X.X.255 , it doesn't need to be there and will keep dhcp from workly correctly . We had the exact problem and finally tracked it down to having a broadcast address specified ont the interfaces which interferes with the way DHCP works when people plug into the network without releasing the address . This cured the problem by removing the specified broadcast address .

2 REPLIES
Community Member

Re: dhcp problem

Sad, but what you are describing is normal. A reference can be found in Cisco's DHCP product, CNR's documentation too:

"Moving a Client to Another Subnet

If you move a DHCP client to another subnet, you need to reboot the machine when it arrives on the new subnet or explicitly release and re-acquire a lease using the Windows ipconfig /release, and ipconfig /renew, utilities."

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ciscoasu/nr/nr55/nrug/10client.htm#xtocid16

Martin

Purple

Re: dhcp problem

Make sure you don't have a broadcast address specified on your interfaces such as 169.X.X.255 , it doesn't need to be there and will keep dhcp from workly correctly . We had the exact problem and finally tracked it down to having a broadcast address specified ont the interfaces which interferes with the way DHCP works when people plug into the network without releasing the address . This cured the problem by removing the specified broadcast address .

97
Views
0
Helpful
2
Replies
CreatePlease to create content