I’m a bit confused about the VLAN / hw-offload changes regarding CRS3xx. I do realize the VLAN menu has even been removed from Winbox until all feature parity has been restored.
Now I’m wondering whether I can realize my scenario with a CRS328-24P-4S:
I’d like to use one of the sfpplus interfaces as Q-in-Q interface, that is with outer TPID = inner TPID = 0x8100, not 0x88a8 for the outer tag. This is why I believe that the new 802.1ad example at https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#VLAN_Tunneling_.28Q-in-Q.29 does not apply for me.
Is this still possible? How would I change the TPID from its apparent new default 0x88a8 to 0x8100?
And what about bonding? Can I configure a bond over 2 sfpplus interfaces and do Q-in-Q over the bond?
Or ist this not possible with this model (oldest possible firmware is 6.41 for those)?
It is not possible to tag SVID and CVID with 0x8100 on CRS3xx using 6.43, and Mikrotik support don’t seem to believe me that this is the most common method for QinQ.
Hilarious… I’ve emailed them, they told me I was only the second person to ask for this feature for the CRS3x series …
I agree that this has been the most widely deployed VLAN stacking scenario in the past and still remains popular as far as I can see, the existence of “proper” 802.1ad notwithstanding.
At first I was frustrated, but then I saw the funny side of it
They only added the feature 3 weeks ago, we are probably the only people to test it. I would say everyone who tries to use this feature will give them the same feedback.
I purchased a CRS317 specifically to test this feature and provide fast feedback to help Mikrotik get the QinQ feature set complete. We want to use Mikrotik switches but need at least basic QinQ ethertype selection, QinQ tunelling, CVID untagged and CVID filtering.
Did a quick look in the current RC with initial qinq support and then what port settings for stack trunk or stack access.
setting vlans marking them as outer q? no.
MT Will this surface later in the development or did you not think this through?
I requested these features as soon as rumors of the CRS3xx started. I have since lodged 3 detailed feature requests (2 to support, 1 to sales) for these features, and also talked to Mikrotik guys in person about these features. I’m not sure where the message was lost, or if they just don’t understand the use cases for these features.
i absolutely agree. q-in-q as interconnect between service providers is 99% stacked dot-q, so 0x8100 - which ros doesn’t support anymore hw offload.
0x88a8 makes only sense when you don’t want to stack further - so only in your own network - where, finally it has no advantage over 0x8100 for my point of view.
cisco, juniper & co are all able to de-strip or change those tags in wire speed inside their asics. in previous versions of ros in some devices this was possible, too (eg CRS210, CRS226)
I can confirm that VLAN stacking with 0x88a8 and 0x8100 ether-types is now possible on CRS3xx series switches running RouterOS 6.43rc51 or greater.
Mikrotik have also kindly brought the terminology in line with the rest of the industry by renaming “vlan-protocol” to “ether-type” and listing the actual ether-types as options, e.g. 0x8100, 0x88a8 and 0x9100
I am still waiting for the ability to change the ether-type on a per-port basis, but I am sure that will come in the near future.
