General • Re: QinQ, VLAN Filtering, and absolute confusion!

Basically:

bridge with VLAN filtering enabled will deal with only outer VLAN header and won't care about inside headers.
vlan interface (anchored off another interface) will deal with only VLAN header and won't care about inside headers.

Based on that there's a short sketch of what you can do (this is far from cookbook recipe to directly apply to your devices):

1. let's say your carrier is connected to SFP1. It requires 802.1q headers with VLAN ID 1500, and ether type 0x8100 ("normal" VLANs ... not 0x88A8 S-tags or any other VLAN type)
2. create vlan interface: /interface/vlan/add interface=sfp1 name=vlan1500outer vlan-id=1500
3. create vlan-aware bridge which handles your LAN ... so it'll have ports with either tagged(trunk) or access ports with VLANs set to 103 and/or 107
4. add vlan interface vlan1500outer as trunk port to this bridge and set it as tagged member of appropriate VLANs (103, 107, whatnot)

You could implement similar functionality using another bridge instead of vlan interface (point #2), but ROS can only HW offload single bridge to single switch chip used in device. If underlying port is not run by switch chip (e.g. your CCR1072 doesn't have switch chip so it doesn't offload anything), then bridge functions will be done by software running on device's CPU and then there is no difference between the two solutions performance wise. But it might be a bit easier to understand the setup for those who are not highly fluent in ROSish.
There are use case where it would be better to use another bridge here, one is if ethertype on carrier line is anything but 0x8100 or 0x88A8 (it is possible to set bridge with other ethertypes - in particular 0x9100 - but not vlan interface).

Explanation of bullets above:

1. this is assumption and you have to adjust it to actually used interfaces
2. VLAN interfaces, created under /interface/vlan are kind of pipes where one end is tagged and the other end is untagged.
   The tagged end is attached to interface named in configuration stanza (sfp1 in above example). On ingress it accepts only frames with appropriate ether type (if use-service-tag=yes, then it accepts ether type 0x88A8, otherwise it accepts ether type 0x8100. And more importantly on ingress it accepts only frames with correct VLAN ID set. On egress it adds another 802.1q header with appropriatelly set ether type and VLAN ID.
   The untagged end is "free" and can be used as port (e.g. a bridge member) or as interface (i.e. set IP settings to it).
   The nice feature: vlan interface only handles single layer of 802.1q headers. If ingress frames are QinQ, then only outer header will be removed and the inner header will be left intact (and present on the "untagged" end of vlan "pipe"). Likewise it'll add 802.1q header to frames which enter through "untagged" end already tagged, it won't touch existing tags ... so it'll create QinQ frames out of tagged frames.
   The only thing you have to be careful when creating vlan interface meant for QinQ is that you may want to set mtu to larger value (default is 1500 and clearly doesn't support QinQ where original payload uses 1500 byte MTU already).
3. it's a standard vlan-aware bridge you would create to deal with normal VLAN-tagged frames. Some member ports might be access ports (with pvid set appropriately), some member ports might be tagged only (trunk) and you'd add them as tagged member of needed VLANs under /interface/bridge/vlan. There are a few security properties of ports you may want to look into: ingress-filtering and frame-types as the can affect the way individual ports behave.
   Also beware that bridge port has to be set explicitly as tagged (or untagged, but I don't recommend it) member of VLANs with which router itself has to interact (and routing between VLANs falls into this category).
4. add the before mentioned vlan interface (intended to add QinQ headers) as port to this bridge and set it as tagged member of VLANs which have to pass in QinQ pipe

Statistics: Posted by mkx — Thu Jan 25, 2024 11:15 am

---