cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1186
Views
4
Helpful
2
Replies

Transporting QinQ traffic over L2 EoMPLS circuit

marikakis
Level 7
Level 7

Hello,

Suppose that we have QinQ traffic that reaches a GigabitEthernet interface of a GSR. (The second VLAN tag has been previously imposed at a dot1q-tunnel interface of some edge switch. Traffic that reaches the GSR has 2 VLAN tags.) We want to deliver this traffic (over an MPLS backbone) to the GigabitEthernet interface of another GSR. What configuration options are there ? Would a configuration like the following (symmetrically configured at both GigabitEthernet interfaces) work and why ?

interface GigabitEthernet s1/s2/s3.x

encapsulation dot1Q x

xconnect <peer-router-id> <vc-id> encapsulation mpls

(x above is supposed to play the role of the outermost/service VLAN tag)

I am wondering whether the command encapsulation dot1q second-dot1q is actually needed or not.

Any answers or documentation or related standards/drafts will be appreciated.

Kind Regards,

Maria

2 Replies 2

guruprasadr
Level 7
Level 7

HI Maria, [Pls RATE if HELPS]

I have implemented a Scenario as below:

Base Station - A

=================

Metro Edge Switch Config:

int Gi 0/46

switchport access vlan 402 >> OuterVLAN in QnQ

switchport mode dot1q-tunnel

description X-Connect to BaseStation-LAN

Base Satation LAN Switch Config:

int GI 0/45

description X-connection to Metro Edge

switchport trunk encapsulation dot1q

switchport mode trunk

Bast Station - B

=================

Metro Edge Switch Config:

int GI 0/46

switchport access vlan 401 >> OuterVlan in QnQ

switchport mode dot1q-tunnel

description X-connect to Bast Station LAN

Base Station LAN Switch Config:

int GI 0/45

description X-Connect to Metro Edge

switchport trunk encapsulation dot1q

switchport mode trunk

NOC:

====

Metro Head end Switch Config:

int GI 0/45

description to X-Connect to Provider Edge

switchport mode dot1q-tunnel

switchport mode trunk

Provider Edge Router Config:

int Gi 0/1.402100

encapsulation dot1q 402 second-dot1q 100

!! 402 is the OuterVLAN and 100 is Customer VLAN

ip address 10.100.0.101 255.255.255.252

description Customer Bast Station - A

int Gi 0/1.401100

encapsulation dot1q 401 second-dot1q 100

!! 401 is the OuterVLAN and 100 is Customer VLAN

ip address 10.100.0.101 255.255.255.252

description Customer Bast Station - B

In the above Config the QnQ is enabled in the Metro Edge & provider edge routers encapsulation function will be carried out by the edge metro switches and PE Routers. By this way the VLAN's are duplicated are in Metro network itself also making the VLAN allocation locally.

Hope I am Informative.

PLS RATE if HELPS

Best Regards,

Guru Prasad R

Thank you for your reply Guru. I am more interested in carrying the QinQ traffic over an MPLS backbone though using EoMPLS (backbone includes POS interfaces, it is not a pure Ethernet environment).

Test results indicate that the "second-dot1q" style of configuration is required and that the configuration in my initial post will not work. (If anyone knows otherwise, please say so.) If the test results are correct, then my question is why this is so. I do not understand why the QinQ traffic has to be terminated at the router and then tunneled over the EoMPLS circuit. Why is it not possible to just tunnel the traffic transparently over the EoMPLS circuit using only the outer VLAN tag without previously terminating the QinQ traffic ? I am thinking that it has to do with the placement of the MPLS header as a shim header between the L2 and L3 headers. Still I cannot say where exactly in the header the problem arises. And now that I say "I cannot", I think I get it.

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/qinq.html#wp1046211

The Len/Etype field is probably not being located correctly by the router if it does not know beforehand that 2 VLAN tags exist in the header (so the perceived length of the frame is generally wrong). Is that correct ?

Kind Regards,

Maria