On Mon, May 11, 2009 at 11:01 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
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.
The OP asked for an RFC showing why this is forbidden.
Um, yah, I know. You replied to me telling me I was "assuming facts not in evidence". So I was responding to that. Neither my message which you replied to, nor your reply, nor my reply to *your reply*, had anything to do with the OP's request for an RFC citation. Notice the distinct lack of the string "RFC" in my post, your reply, or my reply to your reply. To borrow your phrase, "Do you read your own posts?"
Do you even read your own posts? Specifically:
On May 11, 2009, at 5:40 PM, Ben Scott wrote:
Either way, if the packet *from* X was addressed *to* B but the response comes back from *A*, then host X is going to drop the packet as invalid/irrelevant/etc.
The receiving host X does not care (or even know) if A and B are in the same prefix.
Look again. A and B are *IP addresses*, not hosts. If I'm standing on my home PC and try to connect to Google at 64.233.161.104, my home PC is going to open a TCP connection to that IP address. If Google then tries to send me a response back from 64.233.161.105, then my PC is going to ignore that packet, because it's expecting a response from 64.233.161.104. They're both coming from Google, and maybe they're evening coming from the same node at Google, but since *my* computer doesn't get the response it expects, it doesn't work. Get it? Just to be clear, I'm not talking about what the RFC's say in the above three paragraphs. I'm talking about the specifics of a failure mode which occur under certain conditions in the implementation the OP is using.
So if it works with "diverse routes", it works without diverse routes.
Not when the problem is malfunction at one of the end points!
Two physical interfaces on one machine in the same prefix is allowed.
Indeed, and unlike yourself, I was offering practical, operational advice on how one might configure the given implementation to support just that. -- Ben