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
Lv Zheng wrote:> 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 <--- failureThis should work fine..what are the errors? Ben -- Ben Greear <greearb at candelatech.com> Candela Technologies Inc http://www.candelatech.com
richardvoigt at gmail.com
2009-Jan-06 21:35 UTC
[Bridge] vlan and bond integration in bridge
On Tue, Jan 6, 2009 at 5:19 PM, Ben Greear <greearb at candelatech.com> wrote:> Lv Zheng wrote: > >> 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 > > This should work fine..what are the errors?And what kernel version is being discussed? Many devices matching "hardware VLAN aware switch engine in the appliance" are still on 2.4.x> > Ben > > -- > Ben Greear <greearb at candelatech.com> > Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > Bridge mailing list > Bridge at lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/bridge >
>> vconfig set_name_type DEV_PLUS_VID_NO_PADI made a mistake here. As we want single management interface per VLAN (single L3 management address per VLAN, we will run single L3 authentication service instance -- such as DHCP -- per VLAN), we tried VLAN_PLUS_VID_NO_PAD. Using name_type as DEV_PLUS_VID or DEV_PLUS_VID_NO_PAD will end up without failures, but we will get tow management interface for single VLAN: eth0.1/eth1.1 Failure screen shot is as follows: root at zlv:/root# vconfig set_name_type VLAN_PLUS_VID_NO_PAD Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config root at zlv:/root# vconfig add eth0 1 Added VLAN with VID == 1 to IF -:eth0:- WARNING: VLAN 1 does not work with many switches, consider another number if you have problems. root at zlv:/root# vconfig add eth1 1 ERROR: trying to add VLAN #1 to IF -:eth1:- error: Invalid argument root at zlv:/root# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:E0:4C:17:05:4F inet addr:192.168.100.100 Bcast:192.168.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:495 errors:0 dropped:0 overruns:0 frame:0 TX packets:48 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:51480 (50.2 KiB) TX bytes:4333 (4.2 KiB) Interrupt:169 Base address:0xd800 eth1 Link encap:Ethernet HWaddr 00:14:2A:DE:A9:FC inet addr:10.241.110.78 Bcast:10.241.110.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8204 errors:0 dropped:0 overruns:0 frame:0 TX packets:501 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1244653 (1.1 MiB) TX bytes:40928 (39.9 KiB) Interrupt:177 Base address:0xd400 vlan1 Link encap:Ethernet HWaddr 00:E0:4C:17:05:4F BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Best regards/Zetalog -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/bridge/attachments/20090107/57ce8212/attachment.htm
> And what kernel version is being discussed? Many devices matching > "hardware VLAN aware switch engine in the appliance" are still on > 2.4.xWe are building our application on stock kernel 2.6.23.x. Best regards/Lv Zheng
Lv Zheng wrote:> >> vconfig set_name_type DEV_PLUS_VID_NO_PAD > > I made a mistake here. As we want single > management interface per VLAN (single L3 > management address per VLAN, we will run > single L3 authentication service instance > -- such as DHCP -- per VLAN), we tried > VLAN_PLUS_VID_NO_PAD.Maybe leave the naming as DEV_PLUS_VID and then add all of those VLAN interfaces to a bridge and put your mgt IP on that bridge? Thanks, Ben -- Ben Greear <greearb at candelatech.com> Candela Technologies Inc http://www.candelatech.com
> +---------------------------+-----------------+ > | br0 | br1 | > +------------------+--------+--------+--------+ > | bond0 | eth2 | eth3 | eth4 | > +---------+--------+ | | | > | eth0 | eth1 | | | | > +---------+--------+--------+--------+--------+ > > without the VLAN layer, otherwise packets will be tagged.Do you mean BPDU will also be tagged and no longer a BPDU on the wire?