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