But after setting it up on a CRS instead, throughput is really bad, as the packages reaches the CPU. I have tried setting hw=yes on the bridge port, and the CLI doesn’t complain, but it doesn’t make a difference.
How is it supposed to be configured?
Only one bridge on a device can be hardware offloaded. As a result, you should avoid having multiple bridges on the same device. The default config for the CRS326 only has a single bridge, and you may want to revert to that to restore your original performance. The bridge VLAN filtering options negate the need to have multiple bridges on a single device.
No, the CRS can handle this just fine without having to use the CPU for bridging. The issue is certainly with your config, so yes it can be achieved another way. You need to use bridge VLAN filtering on a single bridge instead of creating multiple bridges - it allows similar controls to having multiple bridges, but the configuration is different.
Using those basic VLAN setups you can certainly create more complex ones…
You are using a CRS3xx device along with VLANS without using Bridge VLAN filtering, that is hardware offloaded for all the CRS3xx devices, instead you are using the CPU…
So performance issues are expected …
Why do you want to Bridge all these VLAN interfaces in the first place ?
@Zacharias, the setup is not simple at all. According to the picture, @hmortensen wants the switch to translate VLAN tags - what comes tagged with VID 10 or VID 20 is expected to leave with VID 111, and what comes tagged with VID 30 or VID 40 is expected to leave with VID 222. Worse, in the opposite direction, what arrives from with VID111 is to leave with either VID 10 or VID 20 depending on… what? So he needs a series of bridges linked together to take care of this, and that’s a complex thing.
@hmortensen, if you don’t mind wasting some interfaces, and if the available bandwidth will be sufficient, you can achieve this in hardware using an ugly trick.
Create a single bridge with vlan-filtering=yes. Create two access ports per VLAN 111 and VLAN 112, and one access port per VLANs 10, 20, 30, 40. Either disable STP on the bridge completely, or at least set all the access ports as edge ones, and most likely also disable loop detection. Then connect the access ports of VLANs 10 and 20 to the two access ports of VLAN 111 and the two access ports of VLANs 30 and 40 to the two access ports of VLAN 112. Bear in mind that frames from VLAN 111 will be broadcast to both VLAN 10 and VLAN 20 until a response packet comes from either of the two.
To do this without hairpin cables, you’d need something like a CCR2004, and I can’t guess what the throughput would be.
If you actually want to add the VID 111 and VID 112 as outer tags in the QinQ scheme, it’s actually yet another task.
ok, i see…
I read again your previous post… what kind of connection do you mean (Then connect the access ports of VLANs 10 and 20 to the two access ports of VLAN 111) ?
An external patchcord. To “map” two VIDs to one in hardware, the only thing you can do on a CRS3xx is to untag the frame on one pass through the switch, and tag it again with the other VID on another pass. You can map a single VID to another single one using switch chip rules on a CRS3xx, but you can’t map the same one (111) to one of the two (10 or 20) this way as you don’t know in advance which one you need, and there are like tens of rules while there are hundreds of MAC addresses, so even dynamically creating these rules woudln’t help as you’d run out of rules quickly. Plus it would only work if the first frame always came from the client, which may or may not be the case depending on how the clients get their IP addresses.
OK, so show the complete tag stack coming from/expected to be sent to the customer-facing ports, and the complete tag stack coming from/expected to be sent to the server-facing ports. The drawing didn’t suggest anything about QinQ.