How can I make a server not give up it's IP address in case of conflict?
July 13, 2016 7:31 AM Subscribe
My client's server detected an IP address conflict and gave up its IP address to the other device (someone's misconfigured cell phone), with predictable 911 business-disrupting results. I'd like the server to not give up its IP address; is there a way to make that happen?
The client's server is running Windows SBS 2008. When I logged in after the client reported that their server was down, I saw a message on the screen saying "IP Address Conflict detected." It appears that another device on the network had a static IP address that matched the server's IP address. Running ipconfig from the server gave me a 169.xxx.xxx.xxx address, despite the server's static IP address remaining in the network connection settings.
So it appears to me that when the server detected an IP address conflict, it yielded the address to the other device. I'd like it to not do that again. Is there a way to tell the server not to give up its IP address in case of conflict?
(We did get them back up by removing the offending device from the network and rebooting things, but I'm looking for prevention of future problems.)
The client's server is running Windows SBS 2008. When I logged in after the client reported that their server was down, I saw a message on the screen saying "IP Address Conflict detected." It appears that another device on the network had a static IP address that matched the server's IP address. Running ipconfig from the server gave me a 169.xxx.xxx.xxx address, despite the server's static IP address remaining in the network connection settings.
So it appears to me that when the server detected an IP address conflict, it yielded the address to the other device. I'd like it to not do that again. Is there a way to tell the server not to give up its IP address in case of conflict?
(We did get them back up by removing the offending device from the network and rebooting things, but I'm looking for prevention of future problems.)
This doesn't directly help your problem, but for the love of god get off the 192.168.1.0 DHCP range.
Even if you just set it to 10.10.10.0 you'll dodge conflicts like this.
posted by Oktober at 7:50 AM on July 13, 2016
Even if you just set it to 10.10.10.0 you'll dodge conflicts like this.
posted by Oktober at 7:50 AM on July 13, 2016
Maybe you can set assign addresses based on MAC addresses. Tutorial.
posted by Foci for Analysis at 7:55 AM on July 13, 2016 [2 favorites]
posted by Foci for Analysis at 7:55 AM on July 13, 2016 [2 favorites]
you have to set the switches up to only accept traffic from DHCP assigned IP addresses. You then put a DHCP reservation in for anything that was previously static.
posted by noloveforned at 8:03 AM on July 13, 2016 [3 favorites]
posted by noloveforned at 8:03 AM on July 13, 2016 [3 favorites]
2nding assiging IP addresses based on MAC address. Even my cheap, five+ year old home wifi router has this functionality.
posted by usonian at 8:04 AM on July 13, 2016 [1 favorite]
posted by usonian at 8:04 AM on July 13, 2016 [1 favorite]
I've never had to deal with this problem myself, so take my opinions with a grain of salt, but: I really don't think there's much point trying to convince the server to hang on to an IP address that it sees someone else using--at that point you've already lost, and you're going to have problems one way or another.
Better would be to prevent the conflict from happening in the first place--e.g. assuming your server and wireless access point are both plugged into the same router, that router should be configured to know that any traffic from the wireless AP should be using only address in the DHCP range, and should be dropping that misconfigured phone's packets.
posted by bfields at 8:06 AM on July 13, 2016 [3 favorites]
Better would be to prevent the conflict from happening in the first place--e.g. assuming your server and wireless access point are both plugged into the same router, that router should be configured to know that any traffic from the wireless AP should be using only address in the DHCP range, and should be dropping that misconfigured phone's packets.
posted by bfields at 8:06 AM on July 13, 2016 [3 favorites]
Response by poster: Ah, I like that idea. Makes it so that static addresses can't be assigned without us knowing about it. Thanks!
posted by JDHarper at 8:27 AM on July 13, 2016
posted by JDHarper at 8:27 AM on July 13, 2016
To expand, yes: it sounds like everything necessary has been done, at least from the server's standpoint, as far as DHCP goes.
As others indicated, the resolution then lies in the other end of the relationship - indeed, through binding the MAC of the server to a preferred static internal IP, through that router or networking point tasked with distributing those DHCP leases. A factory-given MAC address will be unique by definition, so 'fingerprint-matching' a network-address to any given device is possible.
(I learned, also, that the 169.x.x.x address that you wrote about is actually expected behavior for a Windows device! It will normally take this IP subnet whenever DHCP is unable to distribute a lease for its preferred internal IP for any given reason.)
posted by a good beginning at 8:59 AM on July 13, 2016
As others indicated, the resolution then lies in the other end of the relationship - indeed, through binding the MAC of the server to a preferred static internal IP, through that router or networking point tasked with distributing those DHCP leases. A factory-given MAC address will be unique by definition, so 'fingerprint-matching' a network-address to any given device is possible.
(I learned, also, that the 169.x.x.x address that you wrote about is actually expected behavior for a Windows device! It will normally take this IP subnet whenever DHCP is unable to distribute a lease for its preferred internal IP for any given reason.)
posted by a good beginning at 8:59 AM on July 13, 2016
When I worked in server land, we would reduce the range of the DHCP numbers served to say, 1-200, then that would leave 50 numbers on a Class C network not served by DHCP on the network. All your servers go into the non-DHCP portion with static addresses.
You wouldn't normally give a server a DHCP setup, it would get a static IP in its configuration. Once it's on the reserved range, then it's unlikely to get bumped off due to DHCP. However, if some misconfigured device pops up at that IP, there is the potential for an IP conflict and bad results.
To be absolutely certain of no conflicts, you would then bind the port/Mac address of the server on your managed switch so no device with the reserved IP can get on the network unless they are on that port with the correct Mac address.
That's my two cents worth.
posted by diode at 3:49 PM on July 13, 2016
You wouldn't normally give a server a DHCP setup, it would get a static IP in its configuration. Once it's on the reserved range, then it's unlikely to get bumped off due to DHCP. However, if some misconfigured device pops up at that IP, there is the potential for an IP conflict and bad results.
To be absolutely certain of no conflicts, you would then bind the port/Mac address of the server on your managed switch so no device with the reserved IP can get on the network unless they are on that port with the correct Mac address.
That's my two cents worth.
posted by diode at 3:49 PM on July 13, 2016
This thread is closed to new comments.
posted by JDHarper at 7:38 AM on July 13, 2016