bisdn
Help about enabling QinQ
The documentation about QinQ feature is somehow incomplete to me. I've created the bridge using vlan_protocol 802.1ad but no packets get through it. It seems dropped somehow.
If I change the protocol back to 802.1q we get the packets.
Please provide the exact configuration you used.
Also be aware that while we do support using 802.1AD tags instead of 802.1Q tags / ethertype, we currently do not support stacked VLANs (so no actual Q-in-Q).
Also be aware that while we do support using 802.1AD tags instead of 802.1Q tags / ethertype, we currently do not support stacked VLANs (so no actual Q-in-Q).
I think it's better to mention this on the doc. The doc clearly says about "qinq and multiple VLAN tags". Also, could you confirm when you plan to implement the actual QinQ?
After a bit more investigation, it partially works, but not fully as expected.
Here are the results with a bridge in 802.1AD mode:
| Input | port vlan config | result |
|---|---|---|
| untagged | PVID | 802.1AD tag added with VID according to PVID, then forwarded |
| untagged | no PVID | dropped |
| 802.1AD single-tagged | PVID | forwarded according to VID in tag |
| 802.1AD single-tagged | no PVID | forwarded according to VID in tag |
| 802.1Q single-tagged | PVID | dropped |
| 802.1Q single-tagged | no PVID | dropped |
| 802.1AD TAG + 802.1Q TAG (any VID) | PVID | forwarded according to VID in 802.1AD tag |
| 802.1AD TAG + 802.1Q TAG (any VID) | no PVID | forwarded according to VID 802.1AD tag |
All learning happens according to the 802.1AD tag.
My first guess would be you stumbled upon the case where PVID does not add the 802.1AD tag to an already 802.1Q tagged frame.
If my guess is wrong, then please share your configuration (or a minimal example) and I can try to figure out where it breaks, and if there is any workaround.
Configs as follow:
ip link del dev swbridge
ip addr flush dev port1
ip addr flush dev port2
ip link add name swbridge type bridge vlan_filtering 1 vlan_protocol 802.1ad vlan_default_pvid 0
ip link set dev port1 master swbridge up
ip link set dev port2 master swbridge up
bridge vlan add vid 11 dev port1 pvid untagged
bridge vlan add vid 11 dev port2
ip link set dev swbridge up
with this scenario:
We test the setup with running a ping on Client.port1
We plan to tag the ingress packets that are already tagged from MySwitch.port1. Then, we expect that any packet that egresses from port2 will be a 802.1ad doubly tagged (vlan 11 as s-tag) packet.
I can see ingress packets on MySwitch.port1 (802.1q arps), but no packets captured on swbridge nor port2. Is there any configurations needed in order to 802.1ad on swbridge works? Required kernel modules is already present and active (8021q).
We plan to tag the ingress packets that are already tagged from MySwitch.port1. Then, we expect that any packet that egresses from port2 will be a 802.1ad doubly tagged (vlan 11 as s-tag) packet.
Unfortunately this is exactly the scenario that does not currently work, i.e. converting single tagged to double tagged and vice versa. Only converting untagged to single tagged works.
I can see ingress packets on MySwitch.port1 (802.1q arps), but no packets captured on swbridge nor port2. Is there any configurations needed in order to 802.1ad on swbridge works? Required kernel modules is already present and active (8021q).
By default you won't see any packets that get forwarded by the ASIC. You can force all packets recieved on a port to be copied to the switch by using the switch_tcpdump utility, which dynamically installs an appropriate ACL flow.
Unfortunately this is exactly the scenario that does not currently work, i.e. converting single tagged to double tagged and vice versa. Only converting untagged to single tagged works.
Could you share more info about the future plan? Is it on the road map?
I identified an issue and pushed a fix that prevented 802.1Q tagged packets being encapsulated when ingressing on a PVID untagged port of a 802.1ad bridge. So the bolded wrong behaviour in the table above should now be fixed in the current nightlies.
dropped => 802.1ad tag with VID according to PVID added, then forwarded (so single to double tagged)
Double tagged packets are already correctly stripped of their outer tag on egress for untagged ports.
Switching is done based on the outer 802.1ad tag, FWIW.