cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
15889
Views
4
Helpful
14
Replies

QnQ Solution for Layer2 MPLS Customers

guruprasadr
Level 7
Level 7

Hello Experts,

Requirement: QnQ Solution for L2 MPLS Customers.

Kindly advice on the Solution and share your inputs.

Thanks in advance for the Help.

Best Regards,

Guru Prasad R

14 Replies 14

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Guru,

Vlan based EoMPLS should be able to support Q in Q too you may need to tune MTU settings to support the increased overhead.

see fig. 4 on

http://www.cisco.com/en/US/netsol/ns341/ns396/ns223/networking_solutions_white_paper09186a00800a11a2.shtml

Hope to help

Giuseppe

jimmy.anderson
Level 1
Level 1

You will need to make sure you are terminated directly on a card that supports QinQ termination (ES20 cards). If you are not connected to one of these cards, you can xconnect the EoMPLS to a pair of boxes that both have ES20 cards and are directly connected. Then you can xconnect to box#1, strip the outer tag, and then push the inner tag to box#2 and then you can do whatever you want with the inner tag.

thomas.feichter
Level 1
Level 1

Hi,

i think you have 2 possibilities:

- EoMPLS port mode

- dot1q tunnel over MPLS

EoMPLS port mode:

In this config the port is completely transparent.

interface X/Y

no switchport

no ip address

xconnect 50 encapsulation mpls

Dot1q-tunnel config:

interface X/Y

switchport

switchport access vlan 100

switchport mode dot1q-tunnel

switchport nonegotiate

l2protocol-tunnel cdp

l2protocol-tunnel stp

l2protocol-tunnel vtp

no cdp enable

interface Vlan100

no ip address

xconnect 100 encapsulation mpls

! the VC-ID 100 must not match with vlan id

I have tested this scenarios on 3750ME and 7600 with the WS-X6748-GE-TX linecard (also for a L2 solution for customers).

Works fine (in port mode ther is a little bug:cdp don't works).

So, if you do not have port density issues, I suggest the port mode.

If you have problems to bring up the service, check the mtu values! (maybe on interface vlan)

Best regards,

Thomas

HI Thomas,

Great Post Update !

Would like to clarify few points:

Normal L2 Customer Configuration:

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

interface X/Y

no switchport

no ip address

xconnect 50 encapsulation mpls

Dot1q-tunnel config:

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

interface X/Y

switchport

switchport access vlan 100

switchport mode dot1q-tunnel

switchport nonegotiate

l2protocol-tunnel cdp

l2protocol-tunnel stp

l2protocol-tunnel vtp

no cdp enable

>> As per my understanding, Here VLAN ID 100 means Dot1Q Tag VLAN.

I did not fully understand the below configuration:

interface Vlan100

no ip address

xconnect 100 encapsulation mpls

! the VC-ID 100 must not match with vlan id

In an L2-MPLS Scenario, the VC id should be common end-to-end to create a Circuit.

How does a Outer VLAN Tag of "100" is stripped of while creating a Circuit. Also, on what basis the L2 Circuit negotiate in your Case Study.

Request your Help / Advice.

Thanks in Advance.

Best Regards,

Guru Prasad R

Hi,

on the dot1q tunnel mode the vlan id 100 means the vlan tag.

however, exactly I don't know how the Vlan info is encoded in the MPLS packets...

And the VC-ID must match on both 2 PE's.

I have made only the functional tests at this time..

Regards,

Thomas

HI Thomas,

Can you please post the sample configurations,

Interface configurations of PE-A and PE-B

as well the QnQ Tunnel configuration on the Switch.

Best Regards,

Guru Prasad R

Hi guru,

here the configs:

QinQ Tunnel:

PE_A:

interface GigabitEthernet4/5

switchport

switchport access vlan 1602

switchport mode dot1q-tunnel

switchport nonegotiate

l2protocol-tunnel cdp

l2protocol-tunnel stp

l2protocol-tunnel vtp

interface Vlan1602

mtu 1900

no ip address

xconnect 1602 encapsulation mpls

no spanning-tree vlan 1602

PE_B:

interface GigabitEthernet4/5

switchport

switchport access vlan 1602

switchport mode dot1q-tunnel

switchport nonegotiate

l2protocol-tunnel cdp

l2protocol-tunnel stp

l2protocol-tunnel vtp

interface Vlan1602

mtu 1900

no ip address

xconnect 1602 encapsulation mpls

Here the port mode:

PE_A:

interface GigabitEthernet4/10

mtu 1900

no ip address

xconnect 150 encapsulation mpls

PE_B:

interface GigabitEthernet4/14

mtu 1900

no ip address

xconnect 150 encapsulation mpls

Note the mtu value. I recommend to use a big mtu on your MPLS core to avoid issues. Check the smallest mtu on your network (where mpls packets can flow) and set on all devices/interfaces where run mpls to that value.

However on the customer ports, you can manually set a smaller mtu (min 1504 to allow 1500byte dot1q packets).

I my example the mtu to customer is set to 1900.

Remember that if the mtu don't matches on the 2 PE's, the EoMPLS connection don't will go up.

Regards,

Tom

Hi Thomas,

I notice that you have applied a xconnect to an SVI per:

interface Vlan1602

mtu 1900

no ip address

xconnect 1602 encapsulation mpls

We tried the same a while back but could only get the xconnect to work when configured on the physical port.

What was your hardware in this setup? I tried it on a 7600, Sup32, and 61xx and 65xx series line cards. Suspect adding a SIP-400 or ES-20 facing the WAN may help matters, but can't confirm this anywhere.

Regards,

Kent.

Hi,

I user on the ports to the core SIP-400 with SPA-2x1G-V2. RSP-720-3CXL.

Sorry, I don't know exactly the HW requirements. On the datasheet of the SUP-32/Linecards you will find this informations.

Ragards,

Thomas

HI Thomas,

Have rated your post. I would/will update with some clarifications/results after my testing.

Best Regards,

Guru Prasad R

Guru

Please check one thing you need to add one more command so that you won't get any unncessary labels from the l2 peer.

mpls ldp neigbot acl

under acl use deny any any

regards

shivlu jain

Hi, you are right!

Xconnect under an SVI interface is only support if you have SIP or ES20 facing the MPLS WAN. You need to have MPLS configured on a phisical port of the ES20.

Regards.

Max

So your saying you cannot do a hardware EoMPLS to SVI with QinQ, or is this only possible with a ES20 or SIP card?

I have EoMPLS with Sup720 (x-connect based) and SUP2 (SVI based) up and running, but I need to trunk my traffic on each side of the network with EoMPLS connecting the two.

Please see this following link to help me with EoMPLS vlan transport :

https://supportforums.cisco.com/message/3054538#3054538