nanog mailing list archives

Re: two interfaces one subnet


From: Ben Scott <mailvortex () gmail com>
Date: Mon, 11 May 2009 20:04:27 -0400

On Mon, May 11, 2009 at 6:01 PM, Patrick W. Gilmore <patrick () ianai net> wrote:
You are assuming facts not in evidence.

  I *have* actually done this before, so I'd like to think, for my own
purposes at least, my experiences are factual.  :)

It doesn't matter which physical interface transmits the packet.

  Well, in the general sense, I suppose not.  The computer can put
whatever it wants in an Ethernet frame, and as long as it's valid for
the receiving system, it will work.

  But in the Linux IP stack, at least, and by default, the physical
interface used to send a datagram is determined by the route selected,
and that also determines the source IP address put on the datagram.
At the same time, the only thing which influences route selection is
the destination IP address.

  In particular, there's no concept of "session" or "connection" in
that.  So client X attempts to open a TCP connection to IP address B
on my example server.  When the server sends its SYN-ACK response, it
doesn't pay attention to the fact that the connection "came in on" B.
It just looks at destination X.  If it decides A is the best route,
then the SYN-ACK datagram will have source IP address A.  But X is
looking for a datagram from A.  The datagram from B will get to X, but
X will promptly drop it, as it's not expecting anything from B.

  Again, this is all by default.  If you configure policy routing
properly, many things can be made to work.

Another example: Imagine a web server with two uplinks in _different_
subnets running Quagga.

  That's a different scenario entirely.  Diverse routes work fine
because all the intermediate routers work the same way I describe
above: They don't care where the packet came from, they don't know
about "connections", they just forward packets to the destination.

  If the actual interface went down, you can bet that the HTTP request
in progress will be killed, because the TCP session is dependent on an
IP address that just evaporated.  :)

-- Ben


Current thread: