15

If there's a duplicate IP address, which one "wins"? First, last, flaps, neither?

Ron Maupin
  • 98,218
  • 26
  • 115
  • 191
Pseudocyber
  • 887
  • 4
  • 8
  • 15

5 Answers5

18

IPv4:

It will "flap". On the sending host (another host or the gateway/router) there will be an ARP entry for the IP pointing to the MAC address of one of the hosts. Packets will go to one of the hosts, wherever the ARP entry currently points. This will effectively disrupt connectivity for both hosts.

IPv6:

The neighbor discovery protocol will do a Duplicate Address Detection (DAD) before configuring/activating a new address. When it detects that the new tentative address is already in use it will not activate the address so the "first" host will continue to have connectivity.

Sebastian Wiesinger
  • 8,107
  • 3
  • 34
  • 60
  • 1
    Note: (as with everything IPv6) there's still a hole. DAD won't work if the two hosts cannot see each other when they assign the address. So, you can still end up in the same hole. – Ricky Aug 23 '13 at 20:37
  • 1
    Yes, when hosts don't see each other DAD will not work but then that's not an IPv6 problem as such. If you don't have connectivity, no protocol can prevent this from happening. – Sebastian Wiesinger Aug 23 '13 at 22:58
  • 3
    IPv4 can do DAD also, DHCP clients often do it. But on average I'd agree that v6 host is more likely to do it. Failure mode is pretty much same in both cases. – ytti Aug 24 '13 at 06:42
8

If there's a duplicate IP address, which one "wins"? First, last, flaps, neither?

I have been thinking about this question for the last six hours... I think the most appropriate answer is "Nobody wins".

In other words, at least two computers can't be used reliably. Furthermore, you are spending time fixing a problem, and that time could have been used on something much more productive. Anyone who has been a network engineer for long knows that time is one thing we often run short on.

A basic solution to prevent IP conflicts

IP conflicts indicate a basic breakdown in, or lack of good IP allocation processes. If the process is at fault, these kind of issues should be addressed quickly; otherwise you could spend too many cycles on tactical problems like this.

Proactive planning could be using:

  • DHCP for PCs
  • Static DHCP reservations for servers
  • DHCP snooping on switchports
  • IP Source Guard on switchports
  • Dynamic ARP Inspection on switchports

In Cisco IOS, the IP Source Guard and DHCP snooping config would look something like:

!! NOTE: Source guard requires DHCP Snooping global config
!! NOTE: Source guard requires DHCP Snooping on vlan
!! NOTE: Source guard *static* bindings REQUIRE DHCP snooping on the switch
!!     (even if you aren't using DHCP anywhere else)
ip dhcp snooping
ip dhcp snooping vlan 100,200
!
! static Source Guard binding for a non-DHCP device
ip source binding 0011.2233.4455 vlan 100 10.71.2.85 interface GigabitEthernet 5/48
!
interface GigabitEthernet 4/1
 description For DHCP_SERVER port
 switchport access vlan 200
 ! Trust DHCP server ports
 ip dhcp snooping trust
!
interface GigabitEthernet 5/20
 description For DHCP_PC port
 switchport access vlan 200
 no ip dhcp snooping trust
 ip verify source
!

A solution like this will prevent IP conflicts before they start. If you already have the problem, I would start building a plan to solve it. This is just one possible solution.

Mike Pennington
  • 29,876
  • 11
  • 78
  • 152
5

For IPv4, IP-packets sent to the duplicate address will be sent to the MAC address currently in the ARP cache. Flapping will only occur if both hosts send ARP replies to the sender, flapping the ARP entry. If no ARP replies are received, connectivity will be fine with one of the owners of the duplicate IP.

So the last host to answer (or have answered) an ARP request will "win". This competition will be held for every new host that wants to communicate with the duplicate IP.

You could rig the competition by regularly sending gratuitous ARPs.

Gerben
  • 4,670
  • 20
  • 32
4

If there's no ARP entry (another host wants to talk to the dup), then who ever answers first wins; and hosts (and many routers) cache ARP entries sometimes for hours.

Ricky
  • 31,438
  • 2
  • 43
  • 84
  • 1
    Doesn't the last answer win? ARPs can be cached for a long time, but I think the entry will be overwritten when a new ARP reply arrives. The second answer would overwrite the first one. The first packet(s) could end up at the host that answered first, but upon receiving the second answer, you would switch to sending packets to that host. – Gerben Aug 26 '13 at 11:08
1

Generally such kind of incidents are prevented before they create a conflict.
Gratuitous ARP helps the host to determine if another host is already using a particular IP address. Sending host is not expecting the reply, implying that the given address is not being used by another host. If a reply is received an error message "Duplicate IP address... " is displayed. This is a warning signal for mis-configuration. This don't provide any reaction scheme to deal with the issue.

DHCP servers generally perform Address Conflict Detection (ACD) [RFC5227] to avoid such conflicts. It comprise of ARP probe and ARP announcement packets. ARP probe is a special kind of ARP packet in which Sender's Protocol Address field is set to 0. This is done to avoid cache pollution. On the other hand ARP announcement is similar to ARP probe, but has Sender's Protocol Address and Target Protocol Address fields filled. It is used to announce sender's intention to use corresponding IP address.
When a new interface link is established, three ARP probe packets are send prior to waiting for a random time (range 0-1). While these probes are being send the node might receive ARP requests OR replies. A reply indicates the the presence of another node using the given IP address. A request containing the same IP address in it's target protocol address field implies that another node is trying to acquire the same IP address. In both the cases an error message is displayed and alternative IP address is pursued. This is recommended behavior when addresses are being assigned by DHCP. If sending node don't discover any conflict then it can claim the IP address that filled the Sender's Protocol Address.

Ugnes
  • 178
  • 1
  • 1
  • 9