Date: Fri, 12 Aug 2005 17:03:48 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Jeremie Le Hen <jeremie@le-hen.org> Cc: hackers@freebsd.org, "Dan Mahoney, System Admin" <danm@prime.gushi.org> Subject: Re: 5.4 -- bridging, ipfw, dot1q Message-ID: <20050812170348.A20828@xorpc.icir.org> In-Reply-To: <20050812224956.GG45385@obiwan.tataz.chchile.org>; from jeremie@le-hen.org on Sat, Aug 13, 2005 at 12:49:56AM %2B0200 References: <20050812042749.H87994@prime.gushi.org> <20050812063359.A14229@xorpc.icir.org> <20050812224956.GG45385@obiwan.tataz.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 13, 2005 at 12:49:56AM +0200, Jeremie Le Hen wrote: > Hi, > > > I am afraid the existing code cannot help you. > > The packets you see are encapsulated in 802.1q aka VLAN frames, > > and since ipfw2 does not try to decapsulate the packets, you > > don't get to see the IP headers. > > > > Your most reasonable option would be to write a new ipufw2 opcode, > > say something like 'vlan-decap x-y', which succeeds if the packet has > > a vlan header in the range x to y, and in this case skips the VLAN header, > > tries to re-parse the header fields as in the beginning of > > ip_fw_chk() after the section > > > > /* > > * Collect parameters into local variables for faster matching. > > */ > > > > and then continues. > > It's not a lot of code, in the worst case you can just cut&paste > > the relevant 50-60 lines from the beginning of the code > > (though of course it would be nice to rearrange the code to > > reduce duplication). > > > > By doing this you can do something like > > > > ipfw add skipto 1000 vlan-decap 1-50 > > > > and then process vlans 1 to 50 at line 1000. > > Maybe it is a good idea to split the vlan-id matching and the decapsulation. > > Isn't it posible to cheat using vlan(4) interface ? I think it's > possible to create them in order to use its code to zap the VLAN header > and then use ipfw to filter on these vlan(4) interfaces. This isn't > more than a workaround, but it might help. well it would be painful to configure, because the number of vlans is (according to what Dan says) is large, and he would have to define N vlan interfaces on each of the physical ones, then define N bridges between the corresponding vlans (and i think there is a limit on how large N can be). Additionally demuxing incoming packets would take O(N) time. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050812170348.A20828>