Page 1 of 1

Challenging Question regarding QinQ !!!

Posted: Tue Jun 08, 2010 9:00 pm
by ginovilla
Anyone nows how to accept multiple vlans from a customer on Ether1 of a RB1000 and
encapsulate all those vlans into a single QinQ vlan?

Re: Challenging Question regarding QinQ !!!

Posted: Wed Jun 09, 2010 2:33 am
by blake
Hi,

I haven't tested this but I believe you just set use-service-tag=yes on your VLAN interface under /interface vlan. It should add the tag specified by vlan-id to previously tagged packets, thus giving you QinQ.

Re: Challenging Question regarding QinQ !!!

Posted: Thu Jun 10, 2010 1:08 am
by Chupaka
ginovilla, do you want to pass definite VLAN number to QinQ tunnel, or you want to create a vlan trunk, so that any vlans created by your customer were passed into QinQ vlan?

Re: Challenging Question regarding QinQ !!!

Posted: Thu Jun 10, 2010 3:26 am
by ginovilla
I could do either as define and have to control of the customer vlans or do a trunk, I need control of the QinQ

The final solution is to

1-Receive standard Vlans from customer (ex. vlans 100,101,102,103)

2-Encapsulate all those vlans in a single Service Provider Vlan (QinQ Vlan 10)

3-Bridge that Q in Q vlan to a VPLS interface for transport purposes

I have the VPLS running, tested with QinQ. I have still to find a way to do 1 and 2

Re: Challenging Question regarding QinQ !!!

Posted: Thu Jun 10, 2010 1:19 pm
by Eising
What you're describing is a switch thing. Cisco calls it dot1q-tunnel. It's hard for me to see how you can do this with RouterOS. Cisco does this with their insanely expensive ES20 cards by manipulating the incoming tags before sending them over a VPLS.
If it was me, I'd use a cisco 3550/3560 with a loopback cable in front of the router.
The problem here on routeros is that you cannot manipulate vlan tags. You can do limited rewrite with the switch chips, but that does not include imposing tags, so you're best off with a device that aggregates your vlans for you.

Re: Challenging Question regarding QinQ !!!

Posted: Thu Jun 10, 2010 2:05 pm
by ginovilla
Thanks tyo all, I was able to do it with a loopback cable bewtween two ports on the unit:

Port1-Receives vlans from customer, vlans are defined on the Eth port (Eth1)

Port2 has those vlans created as sub interfaces on a qinq vlan (Eth2)

I created bridges for each vlan between Eth1 and Eth2

Eth3 is bridge to VPLS inteface

Loopback cable installed between Eth2 and Eth3

Thanks to all!

Re: Challenging Question regarding QinQ !!!

Posted: Fri Jun 11, 2010 5:30 pm
by Mplsguy
Any particular reason why you do not create "QinQ VLAN" directly on VPLS interface?
Kind of:
   / vlan1 - bridge(vlan1) - vlan1 \
eth- vlan2 - bridge(vlan2) - vlan2 - QinQvlan - VPLS
   \ vlan3 - bridge(vlan3) - vlan3 /

Re: Challenging Question regarding QinQ !!!

Posted: Sat Jun 12, 2010 3:02 am
by ginovilla
Can you expand?

Re: Challenging Question regarding QinQ !!!

Posted: Sat Jun 12, 2010 7:52 pm
by Chupaka
add vlan with parent=VPLS (it will be QinQ vlan)
add necessary vlans to that QinQ vlan and the same set to the ethernet interface
create bridges between those customer vlans

Re: Challenging Question regarding QinQ !!!

Posted: Sun Jun 13, 2010 12:36 pm
by FIPTech
For those interested by Provider to Clients connectivity, see Provider Backbone Bridge standard (PBB). This is a part of 802.1ah standard.

PBB is something like the big father of QinQ and Vlans, (802.1ad - 802.1q).

It does allow to isolate clients Mac adresses from the provider backbone, and does allow to easily manage client circuits, using a mapping between clients QinQ or Vlan tags and provider service circuits.

802.1ah do allow network control and monitoring through Ethernet OAM protocol. This is not the case with 802.1ad. OAM do allow fast detect, repair and convergence to avoid gaps more than 50 ms, like in SDH world.

For Provider Networks, there is 802.1Qay, or PBB-TE, Provider Backbone Bridge Traffic Engineering, disabling RSTP and flooding - broadcasting compared to 802.1ah.

According to Wikipedia :

"PBB-TE equipment leverages economies of scale inherent in Ethernet, promising solutions that are 30% to 40% cheaper than T-MPLS networks with identical features and capabilities[2], giving PBB-TE a better overall return on investment."

PBB is considered like a better alternative to MPLS. It is less costly and less complex, and it integrates more easily in actual networks infrastructures.

Unfortunately only big hardware manufacturers like Cisco or Juniper do support this actually. In Europe, BT provider in England deploy it actually.


For speed, there is no real advantage to use MPLS today, because hardware routers have compiled routing tables. This is as fast as MPLS forwarding. On Cisco hardware, (starting with real hardware routers like 7600 series) there is no speed imrovement from classical routing to MPLS forwarding.

As we have now level2 switching functions today even in small chips like Broadcom ones, there are chances that MPLS will never have a big success in the world, because level 3 routing could integrate those chips fastly and replace very costly hardware routers for medium sized provider networks.

There is no need to use Asics to do hardware routing today. FPGA chips can do the same thing for less monney, and they are programmable, so they are almost as flexible than full software solutions.

Mikrotik, why don't you use a small FPGA chips for level 3 routing and filtering, and implement 802.1ah ? This is about 5 $ by chip. Or ask Broadcom to put an FPGA inside their chips ?

With this you will have wire speed for routing, at a fraction of Cisco / Juniper cost, and you will sell your products to almost all the world mid sized providers....

Re: Challenging Question regarding QinQ !!!

Posted: Sun Jun 13, 2010 7:54 pm
by ginovilla
Chipaka... I like your idea! One thing is that im using Dynamic VPLS tunnels (BGP Signaled)

Re: Challenging Question regarding QinQ !!!

Posted: Wed Sep 09, 2015 10:31 pm
by celeritynetworks
I know this is an older post, but got to thinking about it:

Can the customer-facing Ether iface simply be bridged to the q-in-qVLAN iface with the VPLS as its parent without having to bridge all the individual customer VLANs? Like this:

|---------bridge---------|
Eth - <br> - vlan900 - VPLS

Won't this simply add the 802.1q tag 900 (or 802.1ad tag 900 if service tag is checked) to any frame ingressing the Eth port (untagged or 802.1q tagged)? If the ingressing frame already has an 802.1q tag on it from the customer, won't this just add a 900 tag on top of it and send it out the VPLS?