> Sorry but it is always a big deal. The DHCP server will check it’s
> database to see what numbers are available and assign one. After a number
> is assigned the DHCP server will note the assignment in it’s database (so
> it is not assigned to another device) and keep it reserved until it
> becomes time for the address to be renewed. At this point the DHCP server
> will ask the device if it still wants the address and if so renew the
> lease. If there is no response from the device the address will be put
> back in the pool so it can be handed out to another device. This
> operates through ack/nac between the server and client. Have you ever used
> a program like wireshark to analyze network traffic between a DHCP server
> and device needing an address? The DHCP server will assigh the address to
> another device without checking to see if another device stole the address
> (through a static setup) and errors will result.
Sure, errors will result if two boxes have the same IPs, but the magnitude
of those errors varies a lot, and in fact a lot of the time things will
just work. Try it out; I’ve done it a thousand times (possible
exaggeration), including when I knew I was duplicating an address on the
network for my own evil purposes.
A LAN trace showing what happens in this case can be pretty interesting,
and while most of our wired networks are switched, wireless world can
still work this same way, especially on open networks. Changing your IP
to match somebody else’s and then watching the wire (well, the non-wire)
shows some neat things as packets you solicited come back to you (and may
be rejected by the other host) or packets for the other host come to them
(but are rejected by your host). At the end of the day the default
firewall on openSUSE ignores these, so no extra traffic put on the wire
for things that come to you but were destined for the other box.
>> and (the bigness of the deal, as well as the
>> likelihood that you can get into this situations) depends entirely on the
>> For example, DHCP servers will often do a quick check (via ICMP
>> echo request, aka ping)
> No they don’t!
Calm down… this isn’t the end of the world, either way.
Some do. I didn’t say all do, but some do. Google for dhcp ping check if
you don’t believe me. In fact, as an opensuse user you probably have the
option to setup DHCP within openSUSE (ISC’s dhcp server). This one, as
well, has an option for a ping check (see the manpage).
>> for the address they’re about to give out. If no
>> response, or if nobody responded to the required ARP packet to find the
>> MAC of the host that had the IP address, give out the address. If not,
>> try another. Beyond the DHCP server side many clients do the same thing
>> (quickly check to make sure it’s not assigned) and will reject an offered
>> IP if already in use.
>> Worst case, two boxes get the same IP. Now the network configuration
>> decides how bad this is.
> No, you will always end up with collisions on the network resulting in so
> many retries that the devices will become almost useless as well as slow
> down the rest of the network due to excess traffic.
Always avoid absolutes.
A collision is an event that happens regardless of who has what IPs,
unique or otherwise. I think you are thinking of something else. These
happened primarily on the same old networks (not switched) mentioned
above, and it’s why CSMA/CD exists for wired networks (or I think CSMA/CA
for wireless, but it’s been a while since I looked into that).
If you have duplicates you will end up with some interesting symptoms, but
always ending up with slowing of the rest of the network is a bit extreme.
Why would that happen? A hub sends all packets to all interfaces in any
case. A switch should keep track of which box has the IP, so it should
only send packets to one port or another, and while there may be confusion
there for each end user, the overall network’s pain/suffering shouldn’t be
that extreme. Or consider wireless networks; like hubs, they broadcast
and everybody receives everything. Again, no major slowdown.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…