Date: Mon, 11 Oct 1999 11:55:34 +1000 From: Mark Summerfield <m.summerfield@ee.mu.oz.au> To: Archie Cobbs <archie@whistle.com>, wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Cc: freebsd-net@FreeBSD.ORG Subject: Re: arp errors on machines with two interfaces Message-ID: <199910110153.LAA19461@mullian.ee.mu.OZ.AU> In-Reply-To: <199910110023.RAA11188@bubba.whistle.com> References: <199910090121.VAA68534@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
At 17:23 10/10/99 -0700, Archie Cobbs wrote: >Garret, I'd be interested in seeing what references you have that >say having two NICs on the same wire (with NON-overlapping net ranges) >is somehow broken or illegal or technically incorrect. > >I had always assumed this was perfectly legal, just like running >AppleTalk and TCP/IP on the same wire is perfectly legal. AppleTalk and TCP/IP are different protocols -- there's no possibility (in a properly functioning system) that an Ethernet broadcast packet carrying an AppleTalk packet will get passed to the IP stack for processing. However, if you have two interfaces in the same wire, then broadcast packets carrying IP datagrams will be received on both interfaces, and thus passed to the IP stack twice. And in many cases there is no way to determine at that point which interface the broadcast "should" have been received on. This could be resolved by adding appropriate additional information to the IP header. But that information is not provided for, because it is not part of the protocol design. Ipso facto, we conclude that this is not an intended use of IP, since necessary support is not part of the protocol. It's a question of where, when and how multiplexing is done, both between and within protocol suites. You can (presumably) do wacky things like running IP over AppleTalk over Ethernet on the same wire as plain old IP over Ethernet, and there's no problem -- because the multiplexing between the two IP interfaces is resolved by the encapsulation of one in AppleTalk packets. Which perhaps suggests a possible solution for the original question. It might be possible, by using a different encapsulation, to avoid binding an IP address to the second interface altogether -- that should stop it from delivering broadcast packets to the IP stack. How's that PPPoE code coming along?! ;-) Mark ---- Dr. Mark Summerfield Australian Photonics Cooperative Research Centre Photonics Research Laboratory Dept. of Electrical and Electronic Engineering The University of Melbourne Parkville, 3052 AUSTRALIA Phone: +61 3 9344 7419 Fax: +61 3 9344 6678 Email: m.summerfield@ieee.org WWW: http://www.ee.mu.oz.au/staff/summer/index.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910110153.LAA19461>