two interfaces one subnet

James Hess mysidia at
Mon May 11 20:13:46 CDT 2009

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:

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 mailing list