On 11.05.2009, at 22:34, Patrick W. Gilmore wrote:
On May 11, 2009, at 4:29 PM, Chris Meidinger wrote:
I would be grateful for a pointer to such an RFC statement,
assuming it exists.
Why would an RFC prohibit this?
Most _implementations_ do, but as far as network "rules" in general
it is a valid configuration.
That was essentially my conclusion as well: logically it can't work,
but I wasn't certain where it might be forbidden.
Thusly did I come to NANOG with the question, thinking smarter people
than I might know. If it's completely down to implementation, or
really to the interaction between TCP and underlying IP, then so be
it. I was hoping that I might just not have thought of the right place
to look.
On 11.05.2009, at 22:39, Mikael Abrahamsson wrote:
On Mon, 11 May 2009, Chris Meidinger wrote:
I've been looking through RFC's trying to find a clear statement
that having two interfaces in the same subnet does not work, but
can't find it that statement anywhere.
I don't know if it still works, but it did in Linux little over 10
years back. Proxy-arp:ed all the IPs in the /27 in the /24 and
everything was fine (legacy reasons plus radiolink which I didn't
want to run a lot of broadcasts over). There are "legitimate" cases
where you might want to do this.
Yes, I've gotten it to work as well as little as 10 days ago, but it's
not something that $random_customer should be doing as a matter of
practice.
Thus, again, my hope that I just wasn't thinking of the right place to
look to find an IETF recommendation against doing so.
Thanks for the input!
Chris
