QinQ VLAN's Help needed

RouterOS General
1

I am treading in waters I have not done before and it is a semi live network, so I need to get my ducks in a row, below is what I need:

Cust 1 ---- C-Vlan 10 -----

Cust 2 ---- C-Vlan 20 --------– CCR1036 – S-Vlan 50 ---- Co Loc for ISP’s
/
Cust 3 ---- C-Vlan 30 ---- /

Customers coming in on their relevant Vlan’s to the CCR1036, then encapsulate the C-Vlan’s into one Service Vlan to the co location where the S-Vlan will be stripped again and then be routed accordingly to the relevant ISP based on original Vlan’s.

I have read somewhere on the Wiki that only “initial” support for this is available on bridges from 6.43RC14 I think it was (can’t find it now). I have some concerns running Release Candidate versions in production.

Is above possible at the moment without running RC version, if so, can you provide some guidance on how I can achieve this?

Thanking you in advance

Cisco style Q in Q tunnels
2

So you want it like this, right?

Ethernet II, Src: Routerbo_78:5a:37 (64:d1:54:78:4a:37), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
IEEE 802.1ad, ID: 50
    000. .... .... .... = Priority: 0
    ...0 .... .... .... = DEI: 0
    .... 0000 0011 0010 = ID: 50
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 10
    000. .... .... .... = Priority: Best Effort (default) (0)
    ...0 .... .... .... = DEI: Ineligible
    .... 0000 0000 1010 = ID: 10
    Type: ARP (0x0806)
Address Resolution Protocol (request)

I haven’t tried yet, but from what the wiki says, the “initial support of QinQ” is relevant to using vlan-filtering on frames with 802.1ad tags on a bridge, so unless you need a bridge hosting several s-vlans, you don’t need that feature. So if you want to avoid rc in production and you have enough CPU for adding the s-tag using /interface vlan, it is possible to do it the following way:

                 bridge-x
ether1---tag(c10)===|
ether2---tag(c20)===|---s-vlan50===ether4
ether3---tag(c30)===|

(— … tagless side, === … tagged side)
i.e.

/interface vlan
add interface=ether4 name=s-vlan50 use-service-tag=yes vlan-id=50

/interface bridge
add name=bridge-x vlan-filtering=yes

/interface bridge port
add bridge=bridge-x interface=s-vlan50
add bridge=bridge-x interface=ether1 pvid=10
add bridge=bridge-x interface=ether2 pvid=20
add bridge=bridge-x interface=ether3 pvid=30

/interface bridge vlan
add bridge=bridge-x tagged=bridge-x,s-vlan50 untagged=ether1 vlan-ids=10
add bridge=bridge-x tagged=bridge-x,s-vlan50 untagged=ether2 vlan-ids=20
add bridge=bridge-x tagged=bridge-x,s-vlan50 untagged=ether3 vlan-ids=30

I haven’t tested it completely, so be careful.

Of course if the CCR already gets c10,c20,c30 tagged in a single trunk, all you need is

      bridge-x
ether1===|---s-vlan50===ether4

so all shrinks down to just

/interface vlan
add interface=ether4 name=s-vlan50 use-service-tag=yes vlan-id=50

/interface bridge
add name=bridge-x vlan-filtering=yes

/interface bridge port
add bridge=bridge-x interface=s-vlan50
add bridge=bridge-x interface=ether1

/interface bridge vlan
add bridge=bridge-x tagged=bridge-x,ether1,s-vlan50 vlan-ids=10,20,30
3

QinQ is fine for this. However we have only used CCR’s for this. We have not tried it in the CRS platforms.
BUT, what happens when you need more than one S-tag?

e.g C-tag 10, 20, 30 to S-tag 100
and
C-tag 11,21,31 to S-tag 101

Then you need Selective q-in-q if it needs to be done on the same uplink interface.

4

This can be obtained using vlan-filtering on the bridge hosting the c-vlans and two s-vlan interfaces:

/interface vlan
add interface=ether4 name=s-vlan-100 use-service-tag=yes vlan-id=100
add interface=ether4 name=s-vlan-101 use-service-tag=yes vlan-id=101

/interface bridge
add name=bridge-x vlan-filtering=yes

/interface bridge port
add bridge=bridge-x interface=s-vlan-100
add bridge=bridge-x interface=s-vlan-101
add bridge=bridge-x interface=ether1

/interface bridge vlan
add bridge=bridge-x tagged=bridge-x,ether1,s-vlan100 vlan-ids=10,20,30
add bridge=bridge-x tagged=bridge-x,ether1,s-vlan101 vlan-ids=11,21,31
5

Strange - this is from Mikrotik support 3 weeks ago.

“At the beginning it is planned to have one s-tag for all c-tags on port.
Selective tagging might be possible later using Switch Chip ACL rules or by another implementation.”

6

Yes, on port. But my suggestion uses two different ports, on one of them only the c-vlans 10,20,30 are permitted by the vlan-filtering rule, and on the other one only the c-vlans 11,21,31.

7

Ok which is not ideal in all cases, unless ALL your switches can do this.

e.g Switch A (some other brand or such - managed switch but no q-in-q) - one uplink to switch B (mikrotik) - and then to switch C (Mikrotik) - handover point.
So on switch B you wont be able to say c-tag 10-30 goes to s-tag 100 and c-tag 40-100 goes to s-tag 120.

But either way - nice to know Mikrotik supports it and maybe one day can do the above.

8

Sorry, I didn’t get your point here. How Mikrotik’s “more native” support of this “selective tagging” than using the setup I’ve suggested would change the fact that the other vendor’s equipment cannot do it? And, to extend my mental horizon, what would be the application scenario?

The usual application scenario is that the ISP provides L2 WAN service to several unrelated customers and uses s-vlans to isolate from one another the traffic of these customers, which comes as trunks of c-vlans. In such arrangement, there is little use for c-vlan to s-vlan mapping inside the ISP’s network, the traffic is normally s-tagged on the border switch, port-based.

Already @CZFan’s application scenario is quite far from typical, as he

  1. uses c-vlans to isolate his customers from one another instead of s-vlans (but that’s exactly what saves him from the need to use rc which would be needed to support vlan-filtering of s-vlans), and
  2. hands over the result already s-tagged to his carrier ISP while the usual approach is that the carrier ISP s-tags the traffic on their own equipment.

Your scenario is even more unusual, as you take several c-vlans and want to map groups of them to different s-vlans, and on top of that you seem to want to change that mapping on an intermediate equipment.

Can you give a practical example where this would be purposeful?

9

It’s great that Mikrotik supports it, but there are scenarios where selective q-in-q in certain networks is needed. Not Mikrotik’s fault as I do realise it is an unusual setup.

e.g say you have 100 buildings - and use a different brand of switch. Why? Well maybe until very recently Mikrotik had no multi ( > 24 port) SFP switches or 48 port ethernet switches. One would not want to replace them all, and they do not support q-in-q. One would simply tag the various ports and then install one “master” Mikrotik switch which can do selective q-in-q.

Why would you want to do this? Maybe to enable open access on your own network.

10

Thank you sindy, all

11

If I may throw in another curve ball, I am new to the “Nuts & Bolts” of Vlan, so please bear with me.

Have a MT CCR with ether1 as a routed port (Stand alone, not part of a bridge / switch group)
Attach Vlan 10 to ether1, and attach vlan’s 20, 30 & 40 to vlan 10, creating QinQ

Ether2 - ethernth in a bridge
Configure bridge for Vlan filter=yes
In Bridge Vlan, ether2 to ether5 & bridge tagged for vlan-ids=20,30,40

Trying to get frames coming in tagged on ether2 - 5 with vlan id ether 20, or 30 or 40, tag must stay on frame and go out via relevant vlan 20, 30 or 40, tunneled into vlan 10 out on ether1?

Hope it makes sense

12

Drawings are better, but I assume you want ether1 to carry the QinQ frames where VID 10 is the outer one (service-vlan, or S-vlan, ethertype 0x88a8) and VID 20,30,40 are the inner ones (customer-vlan, C-vlan, ethertype 0x8100). If so, the method suggested above is still valid, just modify the picture (and configuration) from

      bridge-x
ether1===|---s-vlan50===ether4

to

     bridge-vlan
ether2===|
ether3===|---s-vlan10===ether1
ether4===|
ether5===|
13

@sindy, thank you very much. Apologies, was in a rush, but you are 100% correct, drawings will make it more clear, so below drawing and explanation, also explaining how I see it, so please correct me if I am wrong.

Vlans coming into CCR already tagged for 20, 30 & 40.
CCR is configured:

  • ether1 is stand alone, router port, not part of any switch group / bridge, used for routing to WAN.
    — on ether1 I have vlan 10 attached to ether1 and vlan’s 20, 30, 40 attached to vlan 10 (QinQ Tunneling)
  • ether 2 - ether4 configured as part of a bridge
    — under /bridge vlan, I have selected the bridge, with Vlan-Ids=20, 30, 40, tagged=bridge, ether2, ether3, ether4 and untagged=none

So if my understanding is correct, packets/frames will come into the CCR already tagged by CPE devices with relevant ISP Vlan ID, as they come into bridge via ether2, 3 & 4, they will remain tagged, go out of the bridge still tagged, will then be encapsualted with vlan 10, go accross WAN linek, get to Co-Loc, Vlan 10 gets stripped and based on the Vlan tag remaining, will be routed to relevant ISP.

I am of the understanding that if I do the above, it remains 802.1Q (ethertype 0x8100), should I enable the “use service tag”, it will become 802.1ad (ethertype 0x88a8), is my understanding correct?
If so, will it work on 802.1Q?
QinQ VLAN.JPG

14

I have not tried an actual QinQ, only “Qinad”, but I don’t see why it should not work with the outer tag being a Q one (0x8100, use-service-tag=no).

15

I cant get above working, anyone that can offer help, please

16

yes, in some cases Q-in.Q works, in other cases you have to do Q-in-ad

17

I will try that in lab quickly, thx

18

Just to be clear what I am trying to achieve, I want tagged vlans coming into a bridge, that must then go out of a routed interface still tagged, the routed interface is not part of the bridge, is that possible?

19

i think one way to do it is:

ether going to collocation with vlan and vlan in vlan interfaces

ether going in the other direction with vlan interfaces

make a bridge for each tagged vlan and add to that bridge as ports corresponding, for example:

bridge-20: ports: vlan20 ether1. vlan 20 ether2, vlan 20 ether3

in that way for each vlan

20

Now wait a bit. So you want that a packet comes in via VLAN 20 on interface A, gets routed (i.e. not bridged) to VLAN20 on interface B? So the IP subnet living in VLAN 20 on interface A is a different one than the IP subnet living in VLAN 20 on interface B (let’s leave QinQ aside for the moment)?