From owner-freebsd-net Tue Jun 15 22:20:34 1999 Delivered-To: freebsd-net@freebsd.org Received: from lion.butya.kz (butya-gw.butya.kz [194.87.112.252]) by hub.freebsd.org (Postfix) with ESMTP id 4442A155BB for ; Tue, 15 Jun 1999 22:20:25 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by lion.butya.kz with local-esmtp (Exim 2.12 #1) id 10u87A-0003g1-00; Wed, 16 Jun 1999 12:19:56 +0700 Date: Wed, 16 Jun 1999 12:19:56 +0700 (ALMST) From: Boris Popov To: "Justin C. Walker" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Multiple ethernet frames for IPX In-Reply-To: <199906160351.UAA00707@walker3.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 15 Jun 1999, Justin C. Walker wrote: > Thanks for the response; I have a few more questions: > > > > How does this handle the problem of getting a forwarded packet back > > > into the wrapper it needs (e.g., 802.3/SNAP)? > > > > Packet sended/forwarded to interface. Since frame type > > determined from the interface it is not a problem for ether_output() > > rotine to select appropriate frame to wrap in. > I should be clearer. What I meant to ask is: given that you have > a packet in the routing layer to forward, and that its incoming > framing has been stripped, how does the routing layer decide what > framing (E-II, 802.3/SNAP, ..) to use when sending it? In case of IPX protocol you have network numbers as a routing and forwarding criteria, and since one frame have only one corresponding network number it is easy to select outgoing interface. If host have no direct connection to destination network it will use routing entries gathered from RIP packets. So, it doesn't matter which frame type was on incoming packet. As a special case consider routing between different frame types on a single ethernet segment. > > > > Why is this better than, e.g., having stacks register for > > > packet-type reception? I'd think this would perform better than > the > > > "virtual device" scheme. A (minor?) drawback is updating both > stack > > > and "driver family support" (e.g., ether_input()) to handle this. > > > > No, you will also need to rewrite route* procedures. And changes > > required to protocol stack(s) aren't "minor" in this case. > I don't understand this. If the route* procedures need rewriting > in this case, why not in the "virtual device" case? Because route includes destination interface and only virtual interface knows about frames. > Also, I don't see why the stack changes are a big deal. For each > configured interface, the stack has to "register", which can be > handled in the same "piece" of the stack that deals, e.g., with ARP > and addressing issues. May be this will be reasonable when you'll redesign stack/interface framework to include frames support. But as follows from README file I have tried to keep minimal changes to kernel files. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message