5
3
We have different sets of IPs within the same subnet on the same interface for different purposes:
192.168.1.201..230 are for servers (all Linux)
192.168.1.1..199 are for services running on those servers
As a consequence, every server has multiple IPs - could be two or even more - on the same physical interface. The idea was to be able to move a service from one server to another easily.
There are some services - such as ssh - that are not bound to a specific IP, but all "productive" services (proxy, DNS, NTP, etc.) are bound to one specific IP (and DNS name) which is meant to be moved to another server if the service is moved.
Now, this setup may not be considered "best practice" but so far we haven't had any trouble whatsoever caused by this. However, a lot of people I talk to about this keep saying that "It's just a matter of time until very bad things happen in such a setup" - without being able to explicitly state what that might be. Right now we're discussing whether we should change the setup in the long run which would require a significant amount of effort. Basically I'm looking for arguments for and against changing this.
So this is the question: what "bad things" might be expected in such a setup? Is it something that can always be avoided by doing or refraining from doing certain things? Is there some problem that can be "triggered" in order to demonstrate the problem and show the need to change the setup?
I don’t see any problems except perhaps administrative overhead. The only real alternative is to use non-standard ports for most services. Not exactly user-friendly. – Daniel B – 2018-07-16T08:27:25.767
What "bad things" might be expected in such a setup? When service sends a packet, it "gives" this packet to the OS and "says": var.1) send it to {dest IP} anyway (close to always on Win); var.2) send it to {dest IP} with {src IP} (close to always on *nix). In the second case no "bad things" might be expected. – Akina – 2018-07-16T08:39:50.043
Considering the goal (failing over a different server) I do see it as a correct practice. For example a fail-over cluster (eg: pacemaker/corysync on RHEL) would do the same: have an additional IP set on a server, then if the server goes down for any reason, the IP would be "moved" to an other server along with the service. What might happen is ARP issues making the floating IP appearing dead for a few minutes on the new server. use arping's Gratuitous ARP or DAD requests to prevent this (like what would do a real cluster) – A.B – 2018-07-16T12:44:21.987
1As someone who thinks in binary, 1-199 and 201-230 does make me itch. Do you really need those last 8 services? 1-191 and 193-223 make more sense. (Hex 01-BF and C1-DF). – MSalters – 2018-07-16T13:52:27.530
This question would fit better on https://serverfault.com
– Philipp – 2018-07-16T14:33:17.997