Networks

Ask something
Discussion Locked

Duplicate IP addresses using DHCP

0 helpful
9 replies

by paul.hudson

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Our problem appears to be DHCP issuing duplicate IP addresses on our W2K network. We have a mixture of PC's and Wyse Winterms using DHCP to control IP addresses. The Winterms sporadically lockup and refuse to connect to the network. We remove them from the network, let them sit for a few days and they connect fine until the next time they lock up.

When we implemented port security on our Cisco 55xx switches, the mystery deepened. Somehow another MAC address is getting into the switch andshutting down the port. It appeared that someone was connecting unauthorized equipment to out network. Not so. The offending MAC address is from other Winterms on different switches and even in different buildings.

I believe somehow the DHCP server is issuing duplicate IP addresses. These addresses are then somehow picked up by the switch that recognizes them as illegal and the port gets shut down.

Am I on the right track? Can anyone shed any light on this? Wyse won't respond to my e-mails and Cisco is no help. Their solution is to turn off port security, which has no effect on the problem.

9 replies

by jon pratt

Well the easy way to test your hypothesis is to set the DHCP lease time to unlimited(naturally sufficient IPs will be needed to cover all of the nodes, but of course one would be crazy to design a subnet any other way). If you still get conflicts then it's something else since the server never revokes its addresses. If it stops then your theory was correct. If you decide that an unlimited lease period is not an acceptable solution you can try deploying windows 2000 dhcp(assuming you don't already use it) which allows you to implement "conflict detection." Hope this helps(other dhcp services may offer "conflict detection" as well).

by jereg

I had a similar problem with a flakey hardware item plugged into my network. Every 3-4 weeks a user would tell methat they couldn't log into the network. At their desktop would be a message that said there was an IP conflict with something else, andit always had the same MAC address. I figured out quickly what it was. It wasn't that duplicate adresses were beiing issued, but the device was taking someone elses address.

The solution was to reserve an address for this offending unit in the DHCP table. Basicly, it assigns a static IP address. Since I did that, I've had no more problems.

This may be the situation with your Winterms. For some reason, they just don't want to get along. You could assign static IP addresses to the boxes, but if you don't keep track, you can have a bigger mess. By setting up a reserved IP address in the DHCP table, you can still use DHCP, keep a running track of the addresses, and if you expand or change your numbering scheme down the road, all you needto do is make the changes to your DHCP settings, the boxes stay the same.
Hope that helps.

by paul.hudson

Not always the same MAC address. Not always the same Winterm. The problem really appears to be "random". If such a thing is possible in a computer environment. Really don't want to static IP everything. That defeats the purpose of DHCP and turns into a logistical nightmare.

by hobbitt

Make sure you don't have a rogue DHCP server someplace in your network. I've never had to shoot this problem, so I don't know how you'd go about determining if there is a rogue, but I recall reading in the past that this situation causes the problem you've described. Does your DHCP provide logging? You'd want to analyze the log to see if the server were providing duplicates.
I also recall that there are tools (commercial or free?) that scan your network to determine if there are duplicate MAC or IP addresses. Might be worth a trip to your favorite search engine.

by gigelul

In addition try to use option from DHCP manager to check consistency of database and reconcile it with registry.

This discussion is closed to new replies.