locked
Duplicate IP Addresses found on network

    Question

  • I have a new 2008 server in my DMZ to replace a server I am removing (W2K). I gave the new server the IP address of the old, and took the old server off line.

    The server 2008 thinks there is a duplicate IP on the network and will not connect. I can give it any other address and it works fine.

    I flushed all the caches, did the diagnose and repair, and rebooted several times. I can't ping the address it thinks is still out there. IPCONFIG shows the server giving itself an APIPA address as (prefered) and my static address with (Duplicate).

    Monday, August 17, 2009 10:43 PM

Answers

  • The new sever in the DMZ was experiencing conflicts with our Cisco PIX firewall. The problem was caused by broadcasts  from  the firewall when “Proxy ARP” is enabled. Proxy ARP is necessary for the DMZ to contact internal servers such as our backup server, and Citrix servers that the web developers use to upload files.

     

    While an IOS upgrade of the PIX may have fixed a known issue with aggressive ARP broadcasting, the registry edit from Microsoft tech support below was a much less invasive fix to the issue.

     

    (response from Microsoft)

    As discussed over phone earlier , for conflict detection, the client computer uses the Address Resolution Protocol (ARP) request to determine whether the IP address is being used. However, a ProxyArp device might incorrectly answer the ARP request, and an IP address conflict is reported.

    When this problem occurs, the ProxyArp device responds to all ARP requests.
    To work around this problem, we can turn off gratuitous ARP by setting the value of the ARPRetryCount registry entry to 0. To do this, follow these steps.

     

    1.  Click Start , type regedit in the Start Search box, and then press ENTER. 

    2.  Locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 

    3.  On the Edit menu, point to New , and then click DWORD Value . 

    4.  Type ArpRetryCount . 

    5.  Right-click the ArpRetryCount registry entry, and then click Modify . 

    6.  In the Value data box, type 0 , and then click OK . 

    7.  Exit Registry Editor. 

    (Reboot)

     

     

    • Marked as answer by IT2B Friday, August 21, 2009 8:57 PM
    Friday, August 21, 2009 8:56 PM

All replies

  • Try deleting any records for that host in DNS.  The DNS references and deleting/resetting the computer object are the only references that still may be lurking.  Otherwise, you've covered your bases on the host side.  
    Different scenario but I've had DCs that would not demote gracefully and even after forcefully demoting the DC and cleaning out DNS, etc and then promoting the server again - the DC would still not replicate.  There were records buried that were still tied to the corrupted DC.  The fix was demoting, chaning the name of the DC, and then promoting with the same IP and then everything worked fine.  Just food for thought.   
    Tuesday, August 18, 2009 12:57 AM
  • In my DMZ the servers are members of a workgroup. I'm not using DNS to register the server internally.  This is a web server, so there should be a host record pointing to an external address that is NATed through our firewall. I don't know if any of that fits into the problem.
    • Marked as answer by IT2B Tuesday, August 18, 2009 3:56 PM
    • Unmarked as answer by IT2B Friday, August 21, 2009 8:56 PM
    Tuesday, August 18, 2009 2:02 AM
  • Try executing (from the cmd prompt) netsh ip int reset reset.txt.  This command serves to uninstall/reset the TCP/IP stack to the factury defaults and was implemented on operating systems when it was no longer possible to uninstall TCP/IP. That hopefully would clear the problem on the host side if tcp/ip on the server was somehow corrupted.  If that doesn't fix the problem, my question is are you sure someone in this address range hasn't already assigned this ip without your knowledge.  And it doesn't necessarily have to be a PC - what about printers or switch, router interfaces.  Anyway, hope this helps.   
    Wednesday, August 19, 2009 1:47 AM
  • The new sever in the DMZ was experiencing conflicts with our Cisco PIX firewall. The problem was caused by broadcasts  from  the firewall when “Proxy ARP” is enabled. Proxy ARP is necessary for the DMZ to contact internal servers such as our backup server, and Citrix servers that the web developers use to upload files.

     

    While an IOS upgrade of the PIX may have fixed a known issue with aggressive ARP broadcasting, the registry edit from Microsoft tech support below was a much less invasive fix to the issue.

     

    (response from Microsoft)

    As discussed over phone earlier , for conflict detection, the client computer uses the Address Resolution Protocol (ARP) request to determine whether the IP address is being used. However, a ProxyArp device might incorrectly answer the ARP request, and an IP address conflict is reported.

    When this problem occurs, the ProxyArp device responds to all ARP requests.
    To work around this problem, we can turn off gratuitous ARP by setting the value of the ARPRetryCount registry entry to 0. To do this, follow these steps.

     

    1.  Click Start , type regedit in the Start Search box, and then press ENTER. 

    2.  Locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 

    3.  On the Edit menu, point to New , and then click DWORD Value . 

    4.  Type ArpRetryCount . 

    5.  Right-click the ArpRetryCount registry entry, and then click Modify . 

    6.  In the Value data box, type 0 , and then click OK . 

    7.  Exit Registry Editor. 

    (Reboot)

     

     

    • Marked as answer by IT2B Friday, August 21, 2009 8:57 PM
    Friday, August 21, 2009 8:56 PM
  • Thank you for this! I just had this problem this week after one of our OCS Edge servers failed with this issue. That registry key change helped perfectly!
    Genious!
    Nick Clark -- Senior Systems Engineer University of the West of England, Bristol (UK)
    Friday, October 30, 2009 4:59 PM