Bug: CRS317 cuts off C-tag in qinq packets

Switch CRS317 cuts off C-tag in qinq packets:
the switch receives a packet with two labels (S-tag & C-tag), but passes only with one label (S-tag).
qinq packets must pass between ports t01 and t02 with S-tag 11.

example config:
/interface bridge
add name=bridge1 protocol-mode=none vlan-filtering=yes

/interface ethernet
set [ find default-name=sfp-sfpplus1 ] l2mtu=9092 mtu=9000 name=t01
set [ find default-name=sfp-sfpplus2 ] l2mtu=9092 mtu=9000 name=t02

/interface bridge port
add bridge=bridge1 ingress-filtering=yes interface=t01 pvid=17
add bridge=bridge1 ingress-filtering=yes interface=t02 pvid=27

/interface bridge vlan
add bridge=bridge1 tagged=t01,t02 vlan-ids=11

/system package update print
channel: current
installed-version: 6.42.1

I cant se your C tag in your setup. A ctag is a vlan to a vlan interface… You need to paste your complete setup with vlan tagged to another vlan interface.

well, I guess there is no specific c-tag configured (as the CRS317 wouldn’t support qinq in hardware anyway), therefore the claimed s-tag (vlan 11) should be able to transport such a qinq-vlan at least without interference I agree it should and ask the original poster to report this issue to support@mikrotik.com

on the other hand the CRS317 (sadly) never claimed to support qinq so I guess MT will probably not solve this issue.

This is not a bug, its clearly misconfiguration starting with ingress-filtering on ports, you can’t filter ingress frames when you haven’t stated if that interface will be tagged or untagged for the vlan in interface bridge vlan. You’re are actually dropping all frames not for vlan17 or 27 so no vlan11 would be going through even if it were correctly configured.

Get Intervlan to work first https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#VLAN_Example_.233_.28InterVLAN_Routing_by_Bridge.29
Then implement QinQ vlan-child(vlan17-vlan27) on vlan-parent(11) and vlan-parent(11) on physical trunk port(??) for vlan11. https://wiki.mikrotik.com/wiki/Manual:Interface/VLAN#Q-in-Q

Do you absolutely need to use QinQ?

respectfully disagree - the CRS and the new bridge-hardware-accelleration config to use it as a switch and get hardware-forwarding is what the original poster tried to achieve imho (and I see no flaw in the config); you are referencing the implementation on cpu-level and as the switch’s CPU would then be maxed out at about 2Gbps (and it’s a 10G switch) this is probably not the solution he’s looking for.

Lets revise that, hw-offload is supported and autoenabled on CRS3xx when using bridge vlan filtering this is all layer2, now if you create a vlan interface its L3 which will use the cpu , can’t do L3 on the (switch chip) all L2 is hw-offloaded all L3 sent to cpu-switch for intervlan routing, an example CRS2xx has no hw-offload for bridge vlan filtering so to use the switch-chip you have to create vlans in /interface switch vlan this is L2 and hw-offloaded, but if you need intervlan routing you’ll have to create a new switch vlan with port cpu-switch assigned to it and create a vlan interface on the physical trunk port for the vlan, so as i understand hw-offload across all CRS devices is for layer2, all L3 is handled by the cpu. Maybe am wrong, still think the use of ingrees-filtering is wrong but wont get into that explanation.

*Edit

As you say

(and it’s a 10G switch)

not 10G router
it should do 10Gb within the same vlan but not intervlan because that is not switching, Maybe if vlans were tagged to a CCR that handles L3 routing you could get 10Gbps+ since CRS would only be doing L2 and all is hw-offloaded.

the original poster was never talking about inter-vlan-anything maybe you should revisit the original problem-report.

QinQ requires intervlan. it’s a vlan interface inside another vlan interface so revisit the docs :wink:, to be more clear QinQ requires 2 vlan interfaces which can’t be hw-offloaded because they are L3.

you might brush up your knowledge, you are misinformed and did not read the first post to understand the issue at hand.
whatever sub-vlan-frames are packed within an ethernet-frame a switch should not remove this information when forwarding a packet according to its layer2-rules.
full stop.

you might brush up your knowledge

sure thing :laughing:

@TestCRS

/interface ethernet switch
set bridge-type=service-vid-used-as-lookup-vid

/interface ethernet switch egress-vlan-tag
add tagged-ports=ISP vlan-id=11

# This is assuming that traffic incoming on internal interface is already tagged. if it's not then add #2 instead of #1

#1
/interface ethernet switch ingress-vlan-translation
add customer-vid=17 new-service-vid=11 ports=Internal
add customer-vid=27 new-service-vid=11 ports=Internal

#2
/interface ethernet switch ingress-vlan-translation
add new-customer-vid=17 new-service-vid=11 ports=Internal
add new-customer-vid=27 new-service-vid=11 ports=Internal

I rest my case it’s not a bug.

Thanks for supporting me. You got it right. I do not require the switch to attach additional tags (stag) to incoming packets and to form a qinq packet out of the ordinary. I want the switch to simply pass through qinq packet without change, that’s all.

You do not want to understand that any switch (and even hub) can be let through qinq packets without changing them, enough that switch was able to pass jumbo frames (at least 1526)

Tested and worked look at the wireshark capture!!

@RoadkillX you do not test your setup on the mentioned HW therefore it’s invalid and not what anybody was asking for.

@TestCRS thx for the ethertype reminder from RoadkillX I found the relatively simple case to do: set the vlan added to the bridge with “use service tag” and you should be fine.

→ seems like no bug - sorry for the confusion.

Yes you’re right on CRS3xx is different, the service tag could work but i just can’t seem to wrap my head around the idea of a vlan inside another vlan, which is how is done on crs3xx. https://wiki.mikrotik.com/wiki/Manual:Interface/VLAN#802.1Q.

“use-service-tag” - this setting applies to the L3 vlan interface setup, the example below:
/interface vlan add
Creates new item with specified property values.
arp – Address Resolution Protocol
arp-timeout –
comment – Short description of the item
copy-from – Item number
disabled – Defines whether item is ignored or used
interface – Physical interface to the network where are VLANs
loop-protect –
loop-protect-disable-time –
loop-protect-send-interval –
mtu – Maximum Transmit Unit
name – Name of the VLAN interface
use-service-tag –
vlan-id – Virtual LAN identificator or tag that is used to distinguish VLANs



There are no such parameters in L2 vlan setup, the example below:
/interface bridge vlan add
Creates new item with specified property values.
bridge –
comment – Short description of the item
copy-from – Item number
disabled – Defines whether item is ignored or used
tagged –
untagged –
vlan-ids –



I remind you that we are talking about the switch crs317 with the current firmware: 6.42.1
Switching must be performed at the HW level (at 10Gbit speed)

That is what i was referring to, according to the documentation for QinQ to work you will have 1 vlan(17/27 c-tag) inside another vlan(11 s-tag) and it to ethernet trunk which will be the ethernet port from ISP with vlan11. That is why i was saying for that to work it’d require layer3 which won’t be hw-offloaded.

/interface vlan
add interface=bridge1 name=vlan11 use-service-tag=yes vlan-id=11
add interface=vlan11 name=vlan17 vlan-id=17
add interface=vlan11 name=vlan27 vlan-id=27

/interface bridge port
add bridge=bridge1 ingress-filtering=yes interface=t01 pvid=11
add bridge=bridge1 interface=vlan17 ingress-filtering=yes pvid=17
add bridge=bridge1 interface=vlan27 ingress-filtering=yes pvid=27

/interface bridge vlan
add bridge=bridge1 tagged=bridge, t01 vlan-ids=11 #Assuming t01 is ISP and t02 is internal with vlans coming in tagged already
add bridge=bridge1 tagged=vlan11, t02 vlan-ids=17
add bridge=bridge1 tagged=vlan11, t02 vlan-ids=27

This might and probably is bs but hey this is after all a forum and after re-reading the documentation as i was suggested is the conlusion i came to, i tried his on a CRS112 and it doesn’t work don’t know the reason wasn’t able to do a packet capture of the output on isp port to see if anything was tagged.

the test is performed not on the switch crs317, because he does not know these parameters:

/interface ethernet switch ingress-vlan-translation
bad command name ingress-vlan-translation (line 1 column 28)

/interface ethernet switch
.. – go up to ethernet
edit –
export – Print or save an export script that can be used to restore configuration
find – Find items by value
get – Gets value of item’s property
host –
port –
print – Print values of item properties
reset-counters –
rule –
set – Change item properties

Honestly don’t understand how something so simple on CRS1xx/CRS2xx is so complicated or even as you say not possible on CRS3xx.