CVSROOT:        /cvs
Module name:    src
Changes by:     [email protected]    2025/11/20 21:44:26

Modified files:
        sbin/ifconfig  : brconfig.c ifconfig.c ifconfig.h 
        sys/net        : if.c if_bpe.c if_bridge.h if_etherbridge.c 
                         if_etherbridge.h if_gre.c if_veb.c if_vxlan.c 
        sys/sys        : sockio.h 

Log message:
add Private VLAN support to veb(4) as per RFC 5517

this extends the core etherbridge functionality so it stores the
extra information needed to be usable by a pvlan aware bridge. in
practice this means address entries in etherbridges store an extra
vlan id on top of the one i just added to make veb vlan aware. a
mac address remains scoped by what is now referred to as a "primary"
vlan id, but has an additional "secondary" vlan id recorded against
it. ie, the "key" to a address lookup in etherbridge is made up of
the mac address and the primary vlan id, and the value returned by
the lookup is the port the mac address should go to and the secondary
vlan id.

the non veb users of the etherbridge code just hard code these extra
vlan ids to 0.

because normal vlans function identically to a primary vlan in a
pvlan topology (or primary vlans in pvlan function like normal
vlans), the veb forwarding code pretends normal vlans are pvlans,
but tries to optimise for the primary vlan case. the changes to the
forwarding path are surprisingly small, the bulk of the code ended
up being around the ioctls.

pvlans are configured on the veb interface, so all ports participating
in the bridge are subject to that config. ifconfig has been extended
so you can claim a vlan for use as pvlan, and then attach secondary
vlans for use as an isolated or community vlans within that pvlan.

the rfc assumes that all the vlan aware devices in a pvlan network are
pvlan aware, however, in practice this is not true. there are a lot of
routers and firewalls that understand vlans because it's handy to be
able to route between vlans without having to have a physical interface
per vlan. every pvlan capable switch ive used has a way to deal with
this, which is basically mark a trunk to such a device as only working
with primary pvlan tags. this diff also provides that with the "pvptags"
option you can set on veb ports that face vlan aware but pvlan
unaware endpoints.

ok djm@ (fwiw he says)

Reply via email to