Remember, Linux has no concept of downing an interface when the link goes away, so even if you have two interfaces with the same subnet config, the kernel will continue to send traffic to a disconnected interface. Utilizing the bonding kernel module is the only really effective way to handle layer-2 redundancy for a Linux system. I use it for a large number of production Linux systems and it works pretty much flawlessly. James Hess wrote:
On Mon, May 11, 2009 at 7:04 PM, Ben Scott <mailvortex@gmail.com> wrote:
On Mon, May 11, 2009 at 6:01 PM, Patrick W. Gilmore <patrick@ianai.net> wrote: [snip]
Many OSes should handle it correctly, in principle, there's nothing wrong with hosts homed twice to the same network and addressed inside the same subnet, but for Linux hosts, no....
Unless you have a _very_ special need: just use IP aliasing and bonding (with supported NICs); I say you'll probably be a lot happier.
But go ahead... try testing multiple interfaces on the same subnet for a while on a Linux host, see how well that works out, that's how you can truly see.....
Possible dangers to keep in mind (bad defaults of Linux), with multiple interfaces on same subnet (without bonding):
* ARP Flux: Linux treats IP addresses as owned by the "host" not the "interface", the first interface to receive an ARP request replies. So if Linux receives an ARP request for interface B's IP address on interface A, it will reply on interface A, thus associating interface B's IP with interface A's hardware address.
Oh, but next time an ARP request comes in, interface B might get it instead.
(*even if the IP is outside interface A's subnet range, Linux just always responds to ARP for any IP it thinks it owns in global scope, no matter what interface received the ARP.... this can enable connectivity you never intended, i.e. If you have a Linux-based firewall, the inside interface's IP can be detected from outside by ARP requesting for random private IPs. ....)
* Some popular distros set net.ipv4.rp_filter (Reverse Path Forwarding) on by default. This means Linux can reject the very traffic that said promiscuous ARP activity brought in, unless outgoing traffic for that destination would be routed using the interface it was received on. Get ready to tune arp_ignore, arp_filter, turn off rp_filter, and possibly have to apply some kernel patches (depending on OS version)..
-- -J