two interfaces one subnet
david at davidcoulson.net
Mon May 11 20:16:42 CDT 2009
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
James Hess wrote:
> On Mon, May 11, 2009 at 7:04 PM, Ben Scott <mailvortex at gmail.com> wrote:
>> On Mon, May 11, 2009 at 6:01 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:
> 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)..
More information about the NANOG