Mikrotik to Cisco QinQ Tunneling behind an MLPS network

RouterOS General
1

Hi there!

I have a super confusing setup that I am trying to get right with Mikrotik. However after a few days, reading the Wikis and vlan setups here I am still not able to get this correct.

We were using Cisco 3750G’s as our base switches in a switching centre with a provider who gave us a single VLAN as a trunk(802.11Q, NO S-tag) into their MPLS network. Using the traditional Cisco QinQ method we were able to tag inside the tag and it was perfectly fine.

However, on Mikrotik I don’t seem to be able to get this right.

This is a huge enterprise network and core network (I work at an ISP) and is an absolute must for me to work out.

On Cisco, to achieve this the following config was used:

interface GigabitEthernet1/0/1

 description UplinkintoMLPS

 switchport trunk encapsulation dot1q

 switchport trunk allowed vlan 3246

 switchport mode trunk

!

interface GigabitEthernet1/0/2

 description QinQtoMPLS

 switchport access vlan 3246

 switchport mode dot1q-tunnel

 l2protocol-tunnel cdp

 l2protocol-tunnel stp

 l2protocol-tunnel vtp

 no cdp enable

 spanning-tree bpdufilter enable

!

interface GigabitEthernet1/0/3

 description QinQ-TrunkPort

 switchport trunk encapsulation dot1q

 switchport trunk allowed vlan 700,701,702,800

 switchport mode trunk

Interface 1 was the “Uplink/wan” link to the Network, Interface 2 and 3 were just joined by a loop cable to make the QinQ configuration work. And this worked really well.

However, after a few days, I am unable to replicate this config on Mikrotik.

I need a trunk on The port facing the Network, and all ports behind this, facing away from this switch as trunks too. No access ports/Untagged traffic here. All ports on my network are tagged for different services (OSPF, PPPoE, BGP etc). Basically I need a trunk vlan in a qinq vlan thats also a trunk. I’ve tried the Ethertag types and I just cant get this right. The reason why this is so important is that we have another Cisco on the other end of the network that needs to talk to this QinQ setup just as well as the one we had spoke to it. we can’t change this to Mikrotik.

2

I guess playing with additional bridge might help?

Assuming you’re using the “modern” way of bridging interfaces, such as this:

/interface bridge
add name=bridge-VLANs vlan-filtering=yes
/interface bridge port
add bridge=bridge-VLANs interface=port1
add bridge=bridge-VLANs interface=port2
add bridge=bridge-VLANs interface=port3
add bridge=bridge-VLANs interface=port4
...
/interface bridge vlan
add bridge=bridge-VLANs tagged=port1,port2,port3,port4,bridge-VLANs vlan-ids=100,200,300,400

The example above has ports 1-4 in “switch group” and all ports are trunk ports carrying VLANs 100, 200, 300 and 400. Note, that also interface bridge-VLANs is added as tagged member of all VLANs, making switch CPU able to interact with the said VLANs.

Actually the “usual” VLAN stuff doesn’t have to be the new style, it can also be the old way (VLANs on switch chip, bridge only there to logically link the ports together), but in that case, switch chip has to be configured to pass all needed VLANs towards CPU tagged.


Next the simplified schema might look like this:

port1 --\
         \
port2 ----\
           >  bridge-VLANs --> QinQ --> bridge-QinQ --> portQinQ
port3 ----/
         /
port4 --/

To get there, you’d add some more configuration:

/interface bridge
add name=bridge-QinQ vlan-filtering=yes
/interface bridge port
add bridge=bridge-QinQ interface=portQinQ
/interface vlan
add interface=bridge-QinQ name=vlan_QinQ vlan-ids=<provider_trunk_VLAN>
/interface bridge port
add bridge=bridge-VLANs interface=vlan_QinQ
/interface bridge vlan
add bridge=bridge-QinQ tagged=portQinQ,bridge-QinQ vlan-ids=<provider_trunk_VLAN>
set [ find bridge=bridge-VLANs vlan-ids=100,200,300,400 ] tagged=tagged=port1,port2,port3,port4,bridge-VLANs,vlan_QinQ

Some description (if only to remind myself what I was trying to do with this config):

  • we need another bridge to merge QinQ physical interface (towards ISP) and the tagged end of tagging/untagging pipe (which will add tag on top of whatever enter on the other, untagged, end).
  • add the physical port to the new bridge
  • create new vlan interface (QinQ tagging pipe) which will tag/untag traffic with provider’s outer VLAN tag … pinning it’s tagged end to the bridge carrying QinQ traffic
  • add the untagged end of QinQ tagging pipe as a member interface to the bridge carrying usual “single tagged” traffic
  • declare the “tagged” end of QinQ tagging pipe as tagged member of the QinQ bridge
  • declare the “untagged” end of QinQ tagging pipe as tagged member of the usual single-tagged bridge

It’s the last step which should take frames with single “inner” VLAN tags and add the “outer” VLAN tag when frames are traveling from bridge-VLANs to bridge-QinQ (and should strip the outer VLAN tag when traveling from bridge-QinQ to bridge-VLANs).


Beware that the QinQ operations as configured in the example above are done entirely in software so if you’ll be using some under-powered device (such as CRS3xx) the performance will not be great …

3

Hi mkx

Great post, vlan on Mikrotik really makes your head spin :slight_smile:

One thing I can’t find in your configuration is a psysical port connected to the ISP? The one carrying the ISP “outer” vlan.

Cheers
Biker