Hi, all
I'm new to this list.
I'm trying to build a 5 ports ethernet switch using Linux.
There's hardware VLAN aware switch engine in the appliance
forwarding packets between these ports, link aggregation
is also supported in the switch chip.
Following functionalities should is required for the appliance:
802.1D: require userspace RSTP
802.1Q: MSTP/tag based VLAN is not required currently,
but port based VLAN is required
802.3ad: auto negotiated link aggregation
Since VLAN device in Linux cannot support VID duplication
across multiple lowers, that is, following commands will fail:
vconfig set_name_type DEV_PLUS_VID_NO_PAD
vconfig add eth0 1
vconfig add eth1 1 <--- failure
I have to create netdevices as follows:
+--------------------+-------------+
| vlan1 | vlan2 |
+--------------------+-------------+
| br0 : |
+-------------+------+------+------+
| bond0 | eth2 | eth3 | eth4 |
+------+------+ | | |
| eth0 | eth1 | | | |
+------+------+------+------+------+
vlans are built on top of br, eth0/1/2 should be assigned
to vlan1, eth3/4 should be assigned to vlan2, eth0/1 may
be manually aggregated.
I have encountered following problems:
1. Are there any hw-accel mechanism that allows
replacement of the software FDB in br with switch
chip's MAC table.
As you may know, without hw-accel, problems will occur
to learn frames.
When MAC based authentication (802.1X, etc.) support is
required, every learn frames received by switch chip
should also be copied to CPU. If br handled every
learn frame, br module's FDB might grow too large to
maintain in case that the switch chip is running in a
limited memory system.
2. There's VLAN packet hw-accel in VLAN module, which is
supported by bond. But without VLAN hw-accel support
in br, the hw-accel will be broken in the br layer.
3. br do not support auto negotiated link aggregation.
IMO, br should be bond aware, LACP may be handled by
br through a hook between br and bond. br then can
dynamically combine multiple physical eth devices to
single logical bond device.
Are there any existing implementations that can solve
these issues, or any other solutions to avoid such
problems?
Best regards/Lv Zheng
_______________________________________________
Bridge mailing list
Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/bridge
