"Conflicting" IP addresses on a server after a reboot; DNS shows no conflicts
Hey, Experts!
We have a server running Windows 2008 SP2 that is our front-end to our SharePoint site. No changes have been made to it in nearly a year.
For the past several months, the system will reboot cleanly and be available through the terminal, but after rebooting no one can access the server at the primary IP (10.0.0.24), though the secondary (.23) was accessible. I changed the primary NIC to .22 for testing purposes, and it came up right away. When I attempted to re-assign .24 as primary, it failed due to a duplicate IP address being detected. I'm unable to ping or find any other trace of another device on .24, but the SharePoint server is insisting that there's a conflict when I try to re-assign that address.
That being as it is, I changed the primary IP of SharePoint to 10.0.0.22 - changes have been made in DNS, and we updated the firewall rules for this change as well. Everything works fine until...
The server is restarted a month later and the same process is followed; except that the server complains that .22 is in use -- so we have to choose another IP... ad nauseum.
Any ideas?
Thanks!
We have a server running Windows 2008 SP2 that is our front-end to our SharePoint site. No changes have been made to it in nearly a year.
For the past several months, the system will reboot cleanly and be available through the terminal, but after rebooting no one can access the server at the primary IP (10.0.0.24), though the secondary (.23) was accessible. I changed the primary NIC to .22 for testing purposes, and it came up right away. When I attempted to re-assign .24 as primary, it failed due to a duplicate IP address being detected. I'm unable to ping or find any other trace of another device on .24, but the SharePoint server is insisting that there's a conflict when I try to re-assign that address.
That being as it is, I changed the primary IP of SharePoint to 10.0.0.22 - changes have been made in DNS, and we updated the firewall rules for this change as well. Everything works fine until...
The server is restarted a month later and the same process is followed; except that the server complains that .22 is in use -- so we have to choose another IP... ad nauseum.
Any ideas?
Thanks!
Marcus Capps
You need to check DHCP, you dont have a reservation in place for that server, so it's getting handed out.
ASKER
Good thought -- I should have mentioned that in my initial post. DHCP is set to hand out leases only within the 10.0.0.200-239 range; so that's not a factor here.
In your ping failures for the duplicate, I assume you are performing the ping from another host, correct?
Given the above assumption, I'm curious if the server in question, once the IP is changed to something else, can ping the phantom host?
If so, I would grab the MAC of the phantom host (arp -a) and see if that matches anything. I would check MAC addresses, physical and virtual, of the server itself first to look for a match.
I ran into this once before, though not with Sharepoint. Sorry, I don't recall the issue (several years ago) but if this may yield some information getting you closer to the culprit.
- Tom
Given the above assumption, I'm curious if the server in question, once the IP is changed to something else, can ping the phantom host?
If so, I would grab the MAC of the phantom host (arp -a) and see if that matches anything. I would check MAC addresses, physical and virtual, of the server itself first to look for a match.
I ran into this once before, though not with Sharepoint. Sorry, I don't recall the issue (several years ago) but if this may yield some information getting you closer to the culprit.
- Tom
I'm not sure if this could help as I don't understand why one will shutdown a server every month.
Shutdown everything, restart your first your DC, then DHCP server, then DNS server(s) and then your SharePoint site.
Note: You reduce server performace and fault tolerance if you reboot them often.
Shutdown everything, restart your first your DC, then DHCP server, then DNS server(s) and then your SharePoint site.
Note: You reduce server performace and fault tolerance if you reboot them often.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.