[Bridge] vlan and bond integration in bridge
Lv Zheng
lv.zheng at soliton.com.cn
Sun Jan 11 20:41:45 PST 2009
> I was talking about regular data packets. Usually, when refering to
> "port based" VLAN, we mean that the host (or the hosts) connected to
> that port has no knowledge whatsoever of what a VLAN is.
>
> If (and only if) this is what you want, then br0 should be directly
> connected to the physical port (bond or eth), and not on top of a vlan
> layer which will filter out untagged incoming packets, and tag outgoing
> packets.
Greetings.
802.1Q defines that each bridge port
shall support following parameters:
1. acceptable frame types, one of the following:
A. admit only VLAN tagged frames
B. admit only untagged and priority-tagged frames
C. admit all frames (default)
2. a PVID for port based VLAN classification
may support following parameters:
3. a VID set for port and protocol based classification
For port based VLAN, a netdevice might still be
VLAN-aware and at least 1 & 2 should be configurable
for the netdevice (known as EISS support).
I noticed following differences are exist between
802.1Q compatible switch chip's MAC port devices
and a normal NIC devices:
Switch port do support 802.1Q parameters will
1. drop untagged frames if it is configured to admit
only VLAN tagged frames and drop frames not
admitted
2. drop any tagged frames whose tag is not in the
VID set if it is configured to admit only VLAN
tagged frames and drop frames not admitted
3. handle any untagged frames as PVID tagged frames
if it is configured to admit untagged and
priority-tagged frames and handle such frames as
if they are coming from the default vlan
4. handle any tagged frames whose tag is not in the
VID set as PVID tagged frames if it is configured
to admit untagged and priority-tagged frames and
handle such frames as if they are coming from the
default vlan
While Linux does not support such features.
Should following attributes be added to netdevice
to support port based VLAN?
1. pvid
2. admit_frame_types
VLAN ioctl command may be added for all
netdevice (like ADD_VLAN_CMD) to
manipulate above 2 vlan specific parameters:
SET_PVID_CMD
SET_FRAME_TYPES_CMD
SET_FRAME_ACTIONS_CMD
Addtional hooks might also be added to
netdevice:
vlan_set_pvid
vlan_set_admit_frames (types & actions)
if frames is not admitted, actions might be configured
to allow:
2.1 DROP: drop the frame
2.2 DEF_VLAN: handle the frame as if it is pvid tagged
3. vlan_nr_groups:
set by NIC driver, its default value might be a Kconfig
option such as CONFIG_VLAN_8021Q_GROUPS
4. vlan_gid_map
GID enabling bits, might be BITMAP(vlan_nr_groups)
5. vlan_groups
VID <-> GID mappings, might be u16[vlan_nr_groups]
register_vlan_device / unregister_vlan_device
might maintain this map and gid array
If hardware do support 802.1Q parameters, it might
report vlan_nr_groups on registration.
Hardware vlan_gid_map and vlan_groups might be
synchronized by supporting
vlan_rx_add_vid / vlan_rx_kill_vid.
Hardware PVID and admit_frame_types might be
synchronized by supporting
vlan_set_pvid / vlan_set_admit_frames.
If PVID in netdevice was implemented, there might be
tow options we could choose:
1. ensure there is always a ethx.pvid device exist
might be suitable for tag based switch applications
2. ensure there is always not a ethx.pvid device exist
might be suitable for port based switch applications
vlan_skb_recv might be modified to support EISS features
because this function will handle all VLAN-tagged frames
netif_recv_skb might be modified to support EISS features
because this function will handle all VLAN-untagged frames
dev_hard_start_xmit might be modified to support EISS
feauturs to do tagging on outgoing packets before hard_xmit
if pvid is set and no ethx.pvid device exists.
If I were wrong, pls let me know. Thanks in advance.
Best regards/Lv Zheng
More information about the Bridge
mailing list