two interfaces one subnet

David Coulson david at
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> wrote:
>> On Mon, May 11, 2009 at 6:01 PM, Patrick W. Gilmore <patrick at> 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

More information about the NANOG mailing list