Date: Wed, 21 Jun 2000 11:33:37 -0400 (EDT) From: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca> To: csg@waterspout.com Cc: net@freebsd.org Subject: Re: bridge + VLAN + netgraph Message-ID: <200006211533.LAA08791@cholla.INRS-Telecom.UQuebec.CA>
next in thread | raw e-mail | index | archive | help
I think the VLAN device should really be thought of as a bridge and not as an encapsulator. After all VLAN's purpose is to make the bridging transparent to groups of users on different LANs, and reduce broadcast domains. So VLAN functionnality should really be implemented in bridge. >Date: Tue, 20 Jun 2000 23:33:46 -0500 >From: "C. Stephen Gunn" <csg@waterspout.com> >To: Julian Elischer <julian@elischer.org> >Cc: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>, archie@whistle.com, gregoire@cholla.inrs-telecom.uquebec.ca, "Vitaly V. Belekhov" <vitaly@riss-telecom.ru>, net@freebsd.org >Subject: Re: bridge + VLAN + netgraph >Mime-Version: 1.0 > >On Tue, Jun 20, 2000 at 10:36:17AM -0700, Julian Elischer wrote: > >> There is VLAN support in FreeBSD but it is independent to >> the Netgraph framework as it was developed independently by >> other people. I have not looked at it closely. > >The VLAN driver was mostly written by Garrett Wollman. > >> It would be nice if we could consolidate these things under >> the single framework. > >our 802.1q VLAN implementation is complicated by several issues: > > - 802.1q is a Layer-2 in Layer-2 encapsulation. Tagged frames > are encapsulated with an ethertype of 0x8100, followed by > a 16-bit field encoding VLAN and Priority. Since we have > our VLAN devices masquerade to the rest of the system as > regular ethernet interfaces (preserving the link header for > things like BPF). > > We can't simply prepend/strip headers from the beginning of > the mbuf like most netgraph modules. > > - Some hardware support tag insertion/extraction. I'm not sure > that hardware tag insertion is a win, since we still have to > store the tag somewhere for I/O to the card. We might as well > just store the tag in the packet. Proably quicker than coding > for the exceptional case of hardware support. > > - Since VLANs shove another 4-byte field in the Ethernet Frame, > we bump the MTU by 4 bytes. Some cards/drivers reject frames > larger than 1500 bytes as giants. This limits the interfaces > recommended for user with VLANs. As someone pointed out > in discussions with me, MTU is a TCP/IP concept, not an > intrinsic property of an interface. > >> The standard 'ethenet' node was recently re-written >> and will be checked in soon. >> >> check: >> ftp://ftp.whistle.com/pub/archie/misc/NGETHER.patch.2 > >I think that ether_input2() is a horrible name. I would advocate >naming ether_demux(). This accurately describes its function. > >It would take a pointer to an ifnet, a pointer to the link-header, >and a the mbuf chain. It should update packet counters, and then >appropriately dispatch the packet to upper protocol layers. > >We could then modify ether_input() to take the full mbuf, including >the headers (like NetBSD). Drivers that want/need to optimize >the selection of packets (NE2000 drivers?) could do their busywork >and pass the packet to ether_demux(). > > - Steve Tarik 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?200006211533.LAA08791>