Date: Tue, 20 Jun 2000 16:55:05 -0400 (EDT) From: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca> To: luigi@info.iet.unipi.it Cc: archie@whistle.com, gregoire@cholla.inrs-telecom.uquebec.ca, vitaly@riss-telecom.ru, net@freebsd.org Subject: Re: bridge + VLAN + netgraph Message-ID: <200006202055.QAA08381@cholla.INRS-Telecom.UQuebec.CA>
next in thread | raw e-mail | index | archive | help
I am replying to both your mails here, hope you don't mind. from: Luigi Rizzo <luigi@info.iet.unipi.it> Subject: Re: bridge + VLAN + netgraph To: Julian Elischer <julian@elischer.org> Date: Tue, 20 Jun 2000 21:24:12 +0200 (CEST) CC: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>, archie@whistle.com= ,=20 gregoire@cholla.inrs-telecom.uquebec.ca, "Vitaly V. Belekhov"=20 <vitaly@riss-telecom.ru>, net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit > Tarik Alj wrote: > >=20 > > Hi, > >=20 > > we are interested in develloping a netgraph=20 > > bridge node following the > > 802.1Q standard; that is a bridge with VLAN support=20 If i can comment: i dod a VLAN bridge (between cards on the same VLAN and supporting TRUNK interfaces) back in 2.2.x times, and was looking at porting this to 3.x/4.x just this morning. The way i did it was within /sys/net/bridge.c and without the VLAN supoprt in RELENG_3 and above. The implementation within bridge.c is relatively straightforward (and tightly related to the idea of clusters of interfaces which is already in the source tree). The only problem is perhaps performance because the VLAN header insertion/deletion is done manually rather than resorting to the hardware support that some cards might have. On the other hand, i am not sure either if if_vlan.c does support it. can I have the source for that? it would be at the very least hintful. I am not sure how easy would it be to make bridging see directly the "vlanX" interface because i think you cannot define a trunk interface, and also there is the problem that vlan_input() calls ether_input again so there is the need for some care in avoiding that the packet is forwarded twice. Yes, the way if_vlan.c works is really *not* the proper way to do it I beli= eve,=20 if you want to handle more than one VLAN it should be done at the bridge le= vel; otherwise you should let the nic handle it, as i think some card are capabl= e of tagging (not sure thought). this is why we would like to see it implemented as a bridge; netgraph seeme= d to=20 be a clean approach as it provides for some sort of API. Plus, i am not really sure how vlan works with Archie's commits to simplify device drivers. =09cheers =09luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- >From: Luigi Rizzo <luigi@info.iet.unipi.it> >Subject: Re: bridge + VLAN + netgraph >To: aljtarik@cholla.inrs-telecom.uquebec.ca >Date: Tue, 20 Jun 2000 21:37:59 +0200 (CEST) >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit > >As a followup: > >> > Hi, >> >=20 >> > we are interested in develloping a netgraph=20 >> > bridge node following the >> > 802.1Q standard; that is a bridge with VLAN support=20 > >Forgot one detail: doing the vlan stuff in bridge.c >you can surely make use of the features of ipfw/dummynet. >I understand that you have probably the resources to make this work >by yourself, and that you might be a university, so am asking just >in case-- would you be interested in giving me a small support to >adapt and commit my code in 3.x and above ? (For commits to RELENG_3 >i have to check with Jordan about policy, but if nothing else you >can make use of diffs vs. RELENG_3_5_0_RELEASE). sure. I still have to read about dummynet. We are interested in using dummy= net=20 anyways. And yes, we are a university (http://www.inrs-telecom.uquebec.ca);= the=20 supervisor for the project is Jean-Charles Gr=E9goire=20 (gregoire@inrs-telecom.uquebec.ca). >If not, given that i have some medium-term plans to make this >work anyways before fall, could i suggest that you have a look >at two issues which are missing in the bridging code, namely >spanning tree support (this can be done in userland i believe, >and just implement some {s|g}etsockopt to enable/disable bridging >on some interfaces) and IGMP snooping (forget if this was one >of thie things you had listed in your msg). ok, let me tell you what we would like to have the bridge do : - handle MAC address based VLANs=20 - handle Trunking - have some sort of 802.1p (priority field in 802.1Q header) capabilities (= such=20 as mapping from DSCP to 802.1p for example) - participate in Spanning Tree Protocol - participate in GARP apps (GVRP, possibly GMRP) the aim is to turn the BSD box in a full 802.1Q switch... don't know about IGMP thought. > >For the 3.x branch things are simpler as i know the code very well; >for the 4.x/5.x i need to have a closer look at archie's patches >which are, as far as i can tell, not tested (at least i did not >see a single email confirming that bridging+ipfw still works under >4.x). > >=09cheers >=09luigi > >-----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 >-----------------------------------+------------------------------------- Cheers, Tarik. Tarik Alj INRS-Telecommunications Place Bonaventure 900 De La Gauchetierre Ouest Niveau C, Case Postale 644 Montreal, Qc, H5A 1C6 Canada 514 875-1266 #2036 (email preferred) 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?200006202055.QAA08381>