L2VPN - QinQ to EoMPLS

[Dumpster Eightyeight]

Hi Guys:

I've got a requirement for L2 circuits over an MPLS network and from the customers perspective these need to look like L2 trunks to pass multiple VLANs over, I also need to tunnel STP as one customer is going to have 2 circuits.

Topology below and attached:

Cust Switch 1 and Cust Switch 2 are configured as standard trunks:

interface FastEthernet0/2

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,101-103,1002-1005

switchport mode trunk

SP 1 and SP 4 Switches are configured as qinq ports and are adding vlan tag 3011:

interface GigabitEthernet2/0/11

description *** Link to TEST SW3 F0/2 ***

switchport access vlan 3011

switchport mode dot1q-tunnel

l2protocol-tunnel cdp

l2protocol-tunnel stp

no cdp enable

SP 1 and SP 4 Switches uplink ports to SP 2 and 3 are all standard trunks:

interface Port-channel30

switchport trunk allowed vlan 234,3003,3011,3013

And so are the ports facing SP 1 and SP 4 on SP 2 and 3:

interface Port-channel30

switchport trunk allowed vlan 234,3003,3011,3013

And so are the ports facing the PE's on SP 2 and 3:

interface Port-channel70
  switchport trunk allowed vlan 234,3003,3011,3013

OK, over to the PE configurations:

ASR 9001-1:

interface Bundle-Ether70.3011 l2transport
encapsulation dot1q 3011 second-dot1q any
l2protocol cpsv tunnel

l2vpn
pw-class ETH-ATOM
  encapsulation mpls
  !
!
xconnect group TEST
  p2p VLAN301X
   interface Bundle-Ether70.3011
   neighbor ipv4 2.2.2.2 pw-id 3000
    pw-class ETH-ATOM

ASR 9001-2:

interface Bundle-Ether70.3011 l2transport
encapsulation dot1q 3011 second-dot1q any
l2protocol cpsv tunnel

l2vpn
pw-class ETH-ATOM
  encapsulation mpls
  !
!
xconnect group TEST
  p2p VLAN301X
   interface Bundle-Ether70.3011
   neighbor ipv4 1.1.1.1 pw-id 3000
    pw-class ETH-ATOM

On the PE's the subinterfaces are up and the xconnects are up, I haven't got any hosts on the test switches so I can't test whether a host in VLAN 101 on site 1 can talk to a host in VLAN 101 on site 2 (and vlan 102 and vlan 103), but my issue at this point is that I can't get STP or CDP tunneled, both Cust switch thinks its the STP root for the vlans and I can see them sending BPDUs but not receiving them, they can't see each other as CDP neighbours either.

Any help on this would be really appreciated, thanks a lot in advance.

SP 2 and 3

[xthuijs]

if you have MSTP enabled, then the BPDU's are untagged.

you need to define an efp with untagged encap and define it in the xconnect to the remote side to tunnel the bpdu;s.

however if you configure mstp on the 9k side, the bpdus will be snooped out of the untagged efp!

xander

[Dumpster Eightyeight]

I sort of have got MST enabled but lets say in a more 'original' sense - the switches I am using to test with as customer switches are 2950's and they are using standard STP - no pvstp available on version 12.0

So is this the issue then?

If I had better switches then does my configuraiton look ok for what I am trying to achieve? How come CDP isn't getting through?

Is what I am trying to achieve do-able with realistic CE switches?

[xthuijs]

sort of? either you're pregnant or you're not

those simple switches run by default some sort of 802.1d, the difference between old school stp and mstp is the vlan awareness, but regardless of dot1-d or MSTP they are untagged, so the same resoltuion applies to both.

PVST will tag the bpdu's with the vlan tag, so that would be a different story.

Looks like you will need to create an untagged EFP an craete an xcon for it to get those bpdu's across.

CDP is untagged also, same story.

what you want to do is certainly a scenario/design. some folks dont prefer it because of the issues that come with it;

loops as you basically push the loop mgmt down to the CE. on the other hand, you on the provider side terminating

STP etc has complexities in terms of how many instances you can support or want to.

I have some articles on that btw too, google the mstp doc from the support forums for the asr9000 and the cdp in l2 and l3 scenarios to get a better feel.

https://supportforums.cisco.com/docs/DOC-15749

https://supportforums.cisco.com/docs/DOC-15963

https://supportforums.cisco.com/docs/DOC-22848

these 3 may help you I think.

cheers!

xander

[Dumpster Eightyeight]

Thanks a lot for your reply, when u said about MST and the bpdu's being untagged i realised that with it being an old switch I realised it would be running standard 802.1d and that would have the same affect as MST, that's what I meant by 'sort of'.

Again thanks a lot for the help, I will definitely try what you suggested, and also upgrade the test switches.



Sent from Cisco Technical Support Android App

[xthuijs]

hi dumpster, yeah that is very likely they are running 802.1d standard STP.

Either you can/want to do the no spanning-tree , which can easily be done if there are no loops.

piping the bpdu's and relying on the CE's to figure it out without any provider involvement may make things more difficult to triage unless you have the right methods on place to prove your end being fine..

I would recommend either terminating STP on your PE's (leverage MSTAG for instance).

any case for this exercise, tunneling the bpdu's with an untagged EFP and a xcon will do, let me know how you go.

regards

xander

[Dumpster Eightyeight]

Thanks xander,

When you say untagged, aren't the frames arriving at the PE with an outer tag of 3011 and for the vlan traffic an inner tag of 101-103, for the STP and CDP traffic assuming these are untagged then won't the outer 3011 tag still be present?

If that is the case then doesn't the current EFP I have configured with: encapsulation dot1q 3011 second-dot1q any cover this traffic?

Is there any chance you could also explain the differnece between the following and in which instance they are used:

encapsulation dot1q

encapsulation dot1ad

Thanks

[xthuijs]

i can see your train of thought but no, that is not how it would go.

the switch sends its bpdu's and cdp untagged.

unless you have a scenario whereby there is another switch connected to your CE switch that is dot1q tunnelled.

in that casethat remote switch will have its cdp and bpdu tagged with the "s-vlan" on the CE switch.

Everything that originates from your CE switch will be untagged and you need to capture them with a dedicated EFP.

regards

xander

[Dumpster Eightyeight]

I seem to have resolved STP by changing:

interface Bundle-Ether70.3011 l2transport

encapsulation dot1q 3011 second-dot1q any

l2protocol cpsv tunnel

to:

interface Bundle-Ether70.3011 l2transport

encapsulation dot1q 3011 second-dot1q any

l2protocol cpsv reverse-tunnel

I still can't get CDP packets through though! Anyone with any advice???

[Dumpster Eightyeight]

Just to try and summarise the issue:

I am trying to get a l2 p2p xconnect configured between Cust Sw1 and Cust Sw2 and the end result I am looking for is that the Cust Switches see the link as a trunk.

The Cust Switches are connected to dot1q-tunnel tunnel ports on my edge switches and they are adding the S-VLAN of 3011 and trunking this vlan up to my PE's.

My PE's have the following configuration:

interface Bundle-Ether70.3011 l2transport

encapsulation dot1q 3011 second-dot1q any

l2protocol cpsv reverse-tunnel

!

l2vpn

pw-class ETH-ATOM

  encapsulation mpls

   transport-mode ethernet

  !

!

xconnect group TEST

  p2p VLAN301X

   interface Bundle-Ether70.3011

   neighbor ipv4 2.2.2.2 pw-id 3000

    pw-class ETH-ATOM

*** AND Mirrored on the other PE.

I have customer vlans 101-103 and I can get connectivity between a host on Cust Sw1 in vlan 101 and Cust Sw 2 in vlan 101 and so on for vlans 102 and 103.

I have also got STP going ove the xconnect for all 3 vlans.

My issue is that I can't get cdp neighborship working, I have it configured to tunnel on the dot1q-tunnel port on the edge switch (l2protocol-tunnel cdp & l2protocol-tunnel stp).

Any help would be greatly appreciated.

Thanks!

[danabersoch · Accepted solution]

Dumpster,

If you are adding a sVLAN on your edge switches then yes all traffic that arrives at your PE will have at least the sVLAN tag on it.

I believe the reason that STP is working is because these packets are tagged with the cVLAN (and the sVLAN as the outer tag).

Think of the EFP (subinterface) as a matching statement, in your configuration you have:

encapsulation dot1q 3011 second-dot1q any

This is matching the sVLAN tag of 3011 and any cVLAN.

My theroy here is that the cdp packets are are not being tagged so the above EFP is not matching them as it is expecting an inner tag.

If you configure the EFP with encapsulation dot1q 3011 then this will match traffic that has a sVLAN tag of 3011 and no cVLAN tag to match your cdp traffic.

This will also match traffic that has a sVLAN tag of 3011 and any cVLAN tag as the keywork 'exact' isn't present.

Let me know how you get on,

Dan

[xthuijs]

you are correct Dan, that is why I am advising to use the untagged EFP to capture these packets and assign a service (such as xcon) to them via the untagged EFP.

it is a much easier to manage approach then that friggen L2PT.

the only problem or potential gotcha in this approach is when we are considering the native vlan concept of some switches

whereby normally untagged traffic gets assigned the native vlan.

But in theory no siwtch should tag CDP or BPDU with the native vlan.

regards

xander

[Dumpster Eightyeight]

Thanks a lot for the help, when I created a untagged EFP and a xconnect for it it was tunneling untagged frames from my edge switch.

The configuration that Dan suggested worked, thanks a lot to you both


Sent from Cisco Technical Support Android App

[anand kumar]

Hi Guys,

Can i get the info why the EoMpls advantageous over qinq..

want to clarify , as this is the relevant thread to discuss on.

Regards

Kumar

[xthuijs]

We're talking core side here right?

if you map an AC into a qiq tunnel on the core, you have to nail up this circuit on every hop of the way, almost like ATM NRP (nailed up relay points). or what is really a PVC like behavior.

using mpls here allows you to convert this model into a S-PVC (soft pvc) model whereby you specify the endpoints and the network in between figures out how to get from a to b.

A third option is to use mac in mac or PBB for the core, this allows you to leverage qiq trunks in the core, and mac learn your PE node switches so you effectively have an L2 overlay under your L2 service.

xander