Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have our LAN set up with DHCPD providing fixed IP addresses to the systems. However we are facing IP address conflicts if some one connects a laptop and assigns an IP address belonging to another system.

Is there a way to prevent this? Or ways to detect computers causing this?

share|improve this question
2  
DHCP doesn't "provide static IP addresses"; Sounds like you don't have the DHCP address pool set up correctly –  Fergus Jul 13 '11 at 4:57
    
In dhcpd you set fixed IP's for MAC addresses –  nitins Jul 13 '11 at 5:49
2  
(splitting hairs) certainly, but DHCPD does not provide static addresses. It only ensures those addresses are not in the address pool through the dhcpd.conf file –  Fergus Jul 13 '11 at 5:53
    
yes fixed IP addresses corrected it –  nitins Jul 13 '11 at 7:10
    
Great news...... –  Fergus Jul 14 '11 at 3:08

4 Answers 4

up vote 5 down vote accepted

If users assign IPs to their systems, they'll choose whatever they fancy, and no amount of begging, asking, shouting and threatening is going to change this. Therefore, the safest way would be to separate subnets of servers and users. In that setup a user can conflict only with another user and disrupt one person at worst. What is more, if they assign themselves an address from the servers' network, their networking will not work at all, and that's a mechanism that speeds up users' learning a lot.

That's the only way you can prevent people with administration rights assigning reserved IPs to their stations -- make it not work.

As far as detection goes, you wait for a report. Either a user, who had a working configuration suddenly looses access to the network (that is, there's a newcomer with a Windows station that does not respect the TCP/IP standard of not bringing an interface up if it detects an IP address conflict), or a user reports in, that he configured an IP address, and it does not work.

In the former case, you know that the wrongdoer took over the IP address. You can connect to the same network and use arp to determine his MAC address. If you have an assets database with MAC addresses of users' computers, you have the perpetrator. If you don't then it's time to see which port of which switch sees this MAC address on its interface, go to the corresponding wall socket and see whose cable is plugged in. Bring a 2x4 LART.

In the latter case, the newcomer is the one who tries fancy tricks with his network setup, but the newcomer has a well-behaved OS installed. Instruct the user on the benefits of using a DHCP service set up by his hard-working administrators. If he does not appreciate, use the above-mentioned LART ;).

share|improve this answer
1  
+1 for the LART (I use my voice as an acoustic LART, it generally produces lots of reddish skin and high levels of reluctance to repeat the experience, but is otherwise undetectable). –  wolfgangsz Jul 13 '11 at 13:07

Your DHCP server will allow you to specify an available range. You just have to tell it only to assign addresses above .100 and make sure any static IPs you assign manually are below that range (for example).

share|improve this answer

The way to prevent this is to place your server assets onto a different network from your workstations. You can still utilize DHCP to service the different scopes that corresponds to each network.

share|improve this answer

You can easily detect and watch system causing an IP address conflict:

arping -b -I ethX <ip> (or lowercase -i in case of Debian's arping).

And that's all for Ethernet. You need switches with any kind of ACLs (IP address-to-MAC address port binding or DHCP snooping or 802.1x) to get rid of this problem for good.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.