5.4 -- bridging, ipfw, dot1q

[Luigi Rizzo]

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