two interfaces one subnet
mailvortex at gmail.com
Mon May 11 22:43:26 CDT 2009
On Mon, May 11, 2009 at 11:01 PM, Patrick W. Gilmore <patrick at 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
> 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
> The receiving host X does not care (or even know) if A and B are in the same
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
126.96.36.199, 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
188.8.131.52, then my PC is going to ignore that packet, because
it's expecting a response from 184.108.40.206. 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.
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
> 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
Indeed, and unlike yourself, I was offering practical, operational
advice on how one might configure the given implementation to support
More information about the NANOG