Community discussions

MikroTik App
 
Elisium91
just joined
Topic Author
Posts: 5
Joined: Sat Sep 18, 2021 3:51 pm

Problem with building QinQ on "new bridge" with vlan-filtering

Sat Sep 18, 2021 3:58 pm

Hello all.

I have a problem with building QinQ scheme on "new bridge" with vlan-filtering on Mikrotik CCR1016-12G RouterOS v6.48.4
My goal: I need to take vlan 3119 (CVID) from interface ether1 and pack it into the vlan 52 (SVID) on vpls interface justnet_vlan52

Config:
/interface ethernet
set [ find default-name=ether1 ] l2mtu=1598 mtu=1598

/interface vpls
add advertised-l2mtu=1550 cisco-style=yes cisco-style-id=103 disabled=no l2mtu=1550 mac-address=02:73:81:DD:2D:AE name=justnet pw-type=\
    tagged-ethernet remote-peer=172.16.33.6 use-control-word=yes

/interface vlan
add interface=ether1 name=vlan3119_eth1 vlan-id=3119
add interface=justnet name=justnet_vlan52 vlan-id=52

/interface bridge
add name=br_justnet protocol-mode=none vlan-filtering=yes

/interface bridge port
add bridge=br_justnet interface=vlan3119_eth1 multicast-router=disabled pvid=3119 tag-stacking=yes
add bridge=br_justnet interface=justnet_vlan52 multicast-router=disabled pvid=52

/interface bridge vlan
add bridge=br_justnet tagged=justnet_vlan52 untagged=vlan3119_eth1 vlan-ids=3119

With this configuration, I have the following situation:
1. Tagged traffic (dhcp requests) in vlan 3119 comes to the "ether1" interface.
2. I take only this vlan through the "vlan3119_eth1" interface.
3. I add tag 3119 to the traffic to the "vlan3119_eth1" interface via tag-stacking and add this interface to the "br_justnet" bridge.
4. I make a bridge vlan rule that adds one more tag (52) to the existing one (3119)
5. That's all.

Then I look at the traffic dump using "torch":
On the "vlan3119_eth1" interface, I see incoming dhcp requests. Then they fly via the "justnet" interface to the BRAS, which sends responses back to the "justnet" interface. I see these responses on the "justnet_vlan52" interface with tag 3119 (since tag 52 is already removed on "justnet_vlan52").
And HERE, I expect that traffic with the 3119 tag, according to the existing rule in the bridge vlan, will go to the "vlan3119_eth1" interface, where the 3119 tag will be removed and the responses will go further to "ether1". But in fact, responses are NOT sent to "vlan3119_eth1".

Where am I wrong?

I did a similar config earlier on an old RouterOS 6.42.1 firmware on the same CCR1016-12G and it worked as expected.

Any help on this situation would be welcome.

Thanks!
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Problem with building QinQ on "new bridge" with vlan-filtering

Sun Sep 19, 2021 1:34 pm

The pvid must differ from 3119 on the /interface bridge port row linking ether1 to br_justnet, and ether1 must be on the tagged list on that single row of /interface bridge vlan, otherwise you strip the tag with VID 3119 on egress through ether1.

And you don't need to enable tag stacking at the bridge, because the tagging/untagging with the additional tag (with VID 52) takes place as the frames pass through justnet_vlan52 between the bridge and the VPLS interface. So the bridge never gets a frame tagged with VID 52.
 
Elisium91
just joined
Topic Author
Posts: 5
Joined: Sat Sep 18, 2021 3:51 pm

Re: Problem with building QinQ on "new bridge" with vlan-filtering

Mon Sep 20, 2021 9:30 pm

Hello! TY for answer.

But .. I read your message several times and still did not understand what exactly you are proposing.
If it's not difficult for you, can you write your proposal as configuration commands?
According to my logic (and the description), tag 3119 is not removed in my configuration (for some reason) in traffic FROM justnet_vlan52.

N.B. I cannot add the whole ether1 interface to the bridge. In fact, I need to take some vlans (CVID, in a list 3100-3xxx. Few other vlans (not in list) terminated on this mikrotik, few just bridging with other interfases) from ether1 and pack each vlan in qinq (SVID, also in a list - 52,53,etc) with its own vpls interface (justnet_vlan52, justnet_vlan53,etc).
It was supposed to make as many bridges as there will be qinq vlans, and then only add the vlans I need from ether1 to each bridge.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Problem with building QinQ on "new bridge" with vlan-filtering

Mon Sep 20, 2021 10:00 pm

If it's not difficult for you, can you write your proposal as configuration commands?
Sure I can, but first I have to understand what your actual goal is, as the following statement
According to my logic (and the description), tag 3119 is not removed in my configuration (for some reason) in traffic FROM justnet_vlan52.
is totally confusing for me.

My understanding was that, if we forget for a moment about other VLANs than C3119 and S52, ether1 is a trunk port for C3119. If so, it is correct that as a QinQ frame tagged with S52 as the outer tag and with C3119 as the inner tag arrives via the VPLS tunnel, only the S52 tag gets stripped whereas the C3119 tag remains attached on egress of that frame through ether1; in the opposite direction, the frame arrives to ether1 from the wire already tagged with C3119, and as it is forwarded to the VPLS tunnel, an outer tag S52 is added.

Is this what you actually want or I have misunderstood the required handling? Namely, should ether1 be an access port to C-VLAN 3119 instead, so both tags should be added as the frame travels from the wire to the VPLS tunnel, as your complaint that the C 3119 tag is not removed in the VPLS -> wire direction suggests?

I cannot add the whole ether1 interface to the bridge. In fact, I need to take some vlans (CVID, in a list 3100-3xxx. Few other vlans (not in list) terminated on this mikrotik, few just bridging with other interfases) from ether1 and pack each vlan in qinq (SVID, also in a list - 52,53,etc) with its own vpls interface (justnet_vlan52, justnet_vlan53,etc).
It was supposed to make as many bridges as there will be qinq vlans, and then only add the vlans I need from ether1 to each bridge.
All that can still be done using a single bridge with vlan-filtering at the C-VLAN side. You can also attach multiple /interface vlan to ether1, but then it cannot be only for the C-VLANs you need to transport via the VPLS tunnels, you'd have to use the one-bridge-per-VLAN approach also for the VLANs that need to be bridged with other ports. You cannot make an interface (ether1 in your case) a member port of a bridge and at the same time attach /interface vlan directly to that interface. RouterOS allows you to do that but weird things happen if you do.
 
Elisium91
just joined
Topic Author
Posts: 5
Joined: Sat Sep 18, 2021 3:51 pm

Re: Problem with building QinQ on "new bridge" with vlan-filtering

Tue Sep 21, 2021 4:34 pm

I need equivalent of "selective qinq" on mikrotik.

On Huawei its looks like a:
#
interface XGigabitEthernet0/0/1
 port link-type hybrid
 qinq vlan-translation enable
 port hybrid tagged vlan 10 20
 port hybrid untagged vlan 52 53
 port vlan-stacking vlan 3110 to 3120 stack-vlan 52
 port vlan-stacking vlan 3000 stack-vlan 53
#
Incoming (to iface X0/0/1) vlans 10 and 20 go in w\o changes, vlans from 3110 to 3120 packed to Svlan 52, vlan 3000 packed to Svlan 53. After it i can add vlans 52\53 to vpls ifaces on Huawei.

I need the same on microtik: incoming (to iface ether1) vlans 10 and 20 are terminated on mikrotik (iface L3 with addresses), vlans from 3110 to 3120 are packed in Svlan 52 and sent to vpls justnet52, vlan 3000 is packed in Svlan 53 and goes to vpls justnet53. At the endpoint on vpls where BRAS is located, I need to see double-tagged traffic with SVLAN-CVLAN tags like 52-3119 or 53-3000.

I hope this makes it clearer what I want to get as a result.
Thanks !
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Problem with building QinQ on "new bridge" with vlan-filtering

Tue Sep 21, 2021 5:25 pm

I would have preferred a drawing to a configuration from other vendor I just know to exist, but it seems you confirm my understanding, that C-VLANs 3110 to 3120 all come tagged to ether1. As you've said you need to also bridge some VLANs within the Mikrotik, I'll put together an example Mikrotik configuration doing the above and including also a hypothetical vlan 3333 bridged with ether2 as trunk and ether3 as access, in a few hours from now.
 
Elisium91
just joined
Topic Author
Posts: 5
Joined: Sat Sep 18, 2021 3:51 pm

Re: Problem with building QinQ on "new bridge" with vlan-filtering

Tue Sep 21, 2021 8:21 pm

HOHO!!
I DID IT !!

All you need is love (c) =) ..
I mean, аll you need is to imagine that in microtik the physical port is a multiservice entity as in Juniper and Ether1, in fact, analogous to Unit 0 in Juniper.
Simply put, everything that is not explicitly specified specifically for ether1 (for example, vlans in /interface vlan) is accepted (already understood, yes) on the ether1 physical interface.

Actually, the config is simple, I'll post it a bit later.

N.B. I just had to look at it all from a different point of view.
 
Elisium91
just joined
Topic Author
Posts: 5
Joined: Sat Sep 18, 2021 3:51 pm

Re: Problem with building QinQ on "new bridge" with vlan-filtering

Tue Sep 21, 2021 8:59 pm

/interface ethernet
set [ find default-name=ether1 ] l2mtu=1598 mtu=1598

/interface vpls
add advertised-l2mtu=1550 cisco-style=yes cisco-style-id=103 disabled=no l2mtu=1550 name=justnet pw-type=tagged-ethernet remote-peer=172.16.33.6 use-control-word=yes

/interface vlan
add interface=justnet name=justnet_vlan52 vlan-id=52

/interface bridge port
add bridge=ether1-bridge ingress-filtering=yes interface=ether1 multicast-router=disabled
add bridge=ether1-bridge interface=justnet_vlan52 multicast-router=disabled pvid=52

/interface bridge vlan
add bridge=ether1-bridge tagged=justnet_vlan52,ether1 vlan-ids=3119
I hope, in situation with two vpls ifaces i just can add (as example) this:
/interface vlan
add interface=nextnet name=nextnet_vlan53 vlan-id=53

/interface bridge port
add bridge=ether1-bridge interface=nextnet_vlan53 multicast-router=disabled pvid=53

/interface bridge vlan
add bridge=ether1-bridge tagged=nextnet_vlan53,ether1 vlan-ids=3000
... and it will be work too =)


N.B. ++ to sindy =) Ty !
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Problem with building QinQ on "new bridge" with vlan-filtering

Tue Sep 21, 2021 9:29 pm

If VLANs 10 and 20 are S-VLANs, like VLANs 52 and 53, the Huawei configuration above makes sense to me, because the first tag of all frames on the switch is of the same type (S-tag, 0x88a8). But maybe you use the C-VLAN and S-VLAN only to describe the roles of the tags, and expect both to have ethertype 0x8100? Or maybe the Huawei, when switching, looks at the VID of the outer (or only) tag no matter what its Ethertype is? In any case, the Huawei adds the outer tags with VID 52 and VID 53 already on ingress via X0/0/1, and strips them on egress via that port. Such a single-step mapping is not possible with a CCR, a workaround is necessary.

The first Mikrotik configuration proposal below assumes that VLANs 10, 20, and 3333 are C-VLANs, like VLANs 3000 and 3110-3120, and only VLANs 52 and 53 are S-VLANs. In this scenario, the single common bridge works with ethertype 0x8100, and the outer tag is added (stripped) by /interface vlan as the frames are forwarded from (to) that bridge to (from) the VPLS tunnels. If that is not the case, i.e. if VLAN 10, 20, 3333 are S-VLANs, the second configuration proposal (far more complex) is necessary.

/interface bridge
add name=the-bridge ... ether-type=0x8100 ... vlan-filtering=yes

/interface vlan
add name=justnet52.s52 interface=justnet52 vlan-id=52 use-service-tag=yes
add name=justnet53.s53 interface=justnet53 vlan-id=53 use-service-tag=yes
add name=bridge.c10 interface=the-bridge vlan-id=10
add name=bridge.c20 interface=the-bridge vlan-id=20

/interface bridge port
add interface=justnet52.s52 bridge=the-bridge pvid=1
add interface=justnet53.s53 bridge=the-bridge pvid=1
add interface=ether1 bridge=the-bridge pvid=1
add interface=ether2 bridge=the-bridge pvid=1
add interface=ether3 bridge=the-bridge pvid=3333

/interface bridge vlan
add vlan-ids=10,20 bridge=the-bridge tagged=the-bridge,ether1
add vlan-ids=3000 bridge=the-bridge tagged=ether1,justnet53.s53
add vlan-ids=3110-3120 bridge=the-bridge tagged=ether1,justnet52.s52
add vlan-ids=3333 bridge=the-bridge tagged=ether1,ether2



The following one is for the case that VLANs 10,20,and 3333 are S-VLANs. I would recommend to set protocol-mode=none on all bridges as otherwise you'll end up with a mess of tagged STP BPDUs.
/interface bridge
add name=br-s3333 ... ether-type=0x88a8 ... vlan-filtering=yes
add name=br-s52 ... ether-type=0x8100 ... vlan-filtering=yes
add name=br-s53 ... ether-type=0x8100 ... vlan-filtering=yes

/interface vlan
add name=ether1.s10 interface=ether1 vlan-id=10 use-service-tag=yes
add name=ether1.s20 interface=ether1 vlan-id=20 use-service-tag=yes
add name=ether1.s3333 interface=ether1 vlan-id=3333 use-service-tag=yes

add name=ether1.c3000 interface=ether1 vlan-id=3000

add name=ether1.c3110 interface=ether1 vlan-id=3110
...
add name=ether1.c3120 interface=ether1 vlan-id=3120

add name=justnet52.s52 interface=justnet52 vlan-id=52 use-service-tag=yes
add name=justnet53.s53 interface=justnet53 vlan-id=53 use-service-tag=yes

/interface bridge port
add bridge=br-s3333 interface=ether1.s3333 pvid=3333
add bridge=br-s3333 interface=ether2 pvid=1
add bridge=br-s3333 interface=ether3 pvid=3333

add bridge=br-s53 interface=ether1.c3000 pvid=3000
add bridge=br-s53 interface=justnet53.s53 pvid=1

add bridge=br-s52 interface=ether1.c3010 pvid=3010
...
add bridge=br-s52 interface=ether1.c3020 pvid=3020
add bridge=br-s52 interface=justnet52.s52 pvid=1

/interface bridge vlan
add vlan-ids=3333 bridge=br-s3333 tagged=ether2
add vlan-ids=3000 bridge=br-s53 tagged=justnet53.s53
add vlan-ids=3110-3120 bridge=br-s52 tagged=justnet52.s52
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Problem with building QinQ on "new bridge" with vlan-filtering

Tue Sep 21, 2021 10:06 pm

I wonder why the forum hasn't warned me about your posts following the last-but-one from me...

Regardless that woe, yes, it is simple when you have a single C-VLAN to be packed into a single S-VLAN, but it becomes more complicated if the other requirements need to be fulfilled simultaneously.

Who is online

Users browsing this forum: Bing [Bot], ItchyAnkle, JDF, RobertsN and 71 guests