4

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?

7
  • 2
    DHCP doesn't "provide static IP addresses"; Sounds like you don't have the DHCP address pool set up correctly
    – Fergus
    Jul 13, 2011 at 4:57
  • In dhcpd you set fixed IP's for MAC addresses
    – nitin
    Jul 13, 2011 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, 2011 at 5:53
  • yes fixed IP addresses corrected it
    – nitin
    Jul 13, 2011 at 7:10
  • Great news......
    – Fergus
    Jul 14, 2011 at 3:08

4 Answers 4

6

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 ;).

1
  • 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, 2011 at 13:07
0

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).

0

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.

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .