Cisco 6500 SUP2T VPLS Layer 2 Capability

[martin.chapman44]

Good morning community,

I'm after some clarification on the VPLS functionality available on the 6500 SUP2T supervisor.

I have been doing some research as I’m looking at hardware to build a 3 site MPLS/VPLS carrier network for a client and was originally looking at the 6500/Sup2T solution due to the incredible expense of a ASR 9000 solution. However after reading through a number of documents I stumbled on the following bug for Layer 2 services with VPLS:

With a Supervisor Engine 2T, Layer 2 protocol tunnelling is not supported with VPLS (CSCue45974)

Now in several documents the above statement becomes confusing.

Does anyone know what this statement actually means as not having layer 2 capability on VPLS is surely not correct? During my research I believe that the statement means that no Layer 2 is support if using a QinQ service within a VPLS VSI, so tunnelling within VPLS. Is this correct or does this mean a huge functionality loss with no Layer 2 services (CDP, SP, etc) when using VPLS tunnels with the SUP2T?

Any help is much appreciated.

[Steve11]

Huge functionality loss...

We have a similar setup (7 sites with 6k/sup2t's run as a mini-isp) and we are forced to use EoMPLS for clients who require this functionality on their circuits, so far no client has demanded a VPLS.  We have survived so far but

we need this fixed and we are still waiting.

I was desperatly hoping 15.1(2)SY1 would have fixed this bug but it seems not

[martin.chapman44]

Steven

I'm glad that my Interpretations was correct before spending aload of money on hardware to find out we can't use basic layer 2 VPLS services.

It's serverly disappointing that Cisco promote the VPLS features of the Sup2T however they have this underlying  basic feature issue. It would be good to understand from Cisco if this is on the list of bugs to resolve with priority.

It seems that unless you go down the route of ASR 9000 there is not many hardware platforms within the Cisco portfolio that can accomodate VPLS in the instance of a Service Providor/Carrier category. 7600 platform can do this but is EOL and very hard to obtain the components and licensing.

I have spoken with other companies that have started their own networks as well and they have moved to Juniper and Extreme due to the huge costs associated trying to get the same functionality that seems only availble in the ASR 9000, CSR platforms. I have also looked at the ASR 1000 series and these too have similar VPLS constraints such as:

• No auto-discovery mechanism is supported.
• Load sharing and failover on redundant CE-PE links are not supported

• The virtual forwarding instance (VFI) is supported only with the interface vlan command

Very fustrating.

Have you raised a TAC call on this and can they provide any further updates on this bug?

[Steve11]

We haven't as yet we were hoping it would have been resolved in 15.1(2)SY1 so I might actually log this and see how far I get as your quite right its basic functionality as far as I'm concerned.

We also looked at other platforms some 2 years ago when we implemented this, the sup2t had just been released and we were sold on all the VPLS feature, familiarity with IOS and we actually ran happily on 12.x IOS for 18+ months.

Then we upgraded to 15.x but didn't realize the l2-protocol tunnel problem until a few days later. Realistically its only affected a small subset of our customers so isn't a major problem for us, as we have customers largely localized within a single DC anyway.

Auto-discovery apparently does work (at least on 6ks, cant speak for ASR9k). We have it configured in the lab (literally yesterday) but cant get traffic to pass through it, probably just a command missing but as far as the VC's concerned its up and found its neighbors.

Its been a good choice for us but i would be pushing for ASR's if i had my time again.

Depending on your requirements the ME 3800X's are a possible choice, we some deployed as 'Lite' PE's dual homed to the 6k's at POP sites, only problem is it only has 2 10gig ports so is only useful upto 1gig in the access.

If your only doing upto 1gig, a good low cost design could be to use 6k's as purely MPLS P routers, with ME3800X's dual uplinked to the P's for access ports. Just depends on your requirements and scale.

SteveH

[joshuacmoore]

Can you guys elaborate? We are about to purchase a 6500 sup2t chassis to replace some daisy chained me3800s. What VPLS features are not supported? L2protocol tunneling is different than layer 2 VPLS as it deals with tunneling/propagating layer 2 protocols such as BPDU and CDP. Can someone confirm this is the extent as this will be a major set back if we migrate to a 6500 due to having several existing VPLS connections on our 3800s.

Sent from Cisco Technical Support iPhone App

[Steve11]

l2protocol-tunneling is not supported across a VPLS. so if you have customer kit between 2+ sets of 6k's. the customers kit will not share the same STP domain, or CDP etc..

The workaround suggested sounds plausible however I've not tried it myself as yet. we are simply using EoMPLS circuits as we are mainly port based anyway.  Where we do use VPLS its generally for some sort of hosted service which doesn't require trunking and is a simple access port handoff to the client to a routed port on their network.

This bug will generally affect people who are providing layer 2 circuits across their infrastructure, where you (as the SP) want to remain as invisible as possible. if you give me a little more detail of what your providing these VPLS's for i can say based on our experiance if your going to have an issue?

SteveH

[joshuacmoore]

We provide layer 2 VPLS, and p2p VPWS (I guess "EoMPLS"). Layer 2 though is very simple and our customer expectations usually are that CDP and STP packets aren't going to propagate. I just want to make sure that this "issue" isn't going to hold back VPLS as a whole. If it's simply l2protocol tunneling that is an issue then that wouldn't impact us as much.

By the way, do you have any experience with configurations of the SUP2T 6500s with IOS 15 vs ME3800s with IOS 15? Does the EVC framework configs pretty much carry over?

[Amir Mehri]

Hi Dear

After 10 month, would you please elaborate? can i have VPLS on 6500 with SUP2T ?

Thank you

[joshuacmoore]

Yes you can and we have configured it. You cannot have EVC structure, bridge-domain, or flexible VLAN rewrite capability. You are limited by classic IOS switchport configurations but port-based EoMPLS, xconnect on VLAN interface, etc are all fully supported regardless of LC type so long as you have SUP2T.

[Steve11]

are you sure about that?

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-0SY/configuration/guide/15_0_sy_swcg/ethernet_virtual_connection.pdf

we do not operate with dot1ad so can't confirm, but it does seem possible?

• EVC support requires the following:

  • –  The spanning tree mode must be MST.

  • –  The dot1ad global configuration mode command must be configured. 

[joshuacmoore]

In our case the EVC was useless as you could not configure xconnect, VLAN tag manipulation, bridge domain or QoS policy on it.

[Steve11]

Thats great feedback, thanks Joshua.  I always thought we were at a disadvantage for not using this mode of operation but it sounds like its for a specific use case.

[joshuacmoore]

The lack of features seem to be isolated to the 6500 platform. The ME3600/3800 and ME2600 series seem to do a good job at implementing EVCs and are fairly feature rich.

Since we needed high port density and a collapsed core we decided to go the route of the ASR 9010 where we essentially could have all of our MPLS features.

The 6500 just seems to be an enterprise grade core router with enough MPLS functionality to meet the needs of an enterprise campus network or distribution/access layer box at best in a service provider environment.

[Steve11]

Couldn't agree more to be honest, same for the new 6800/6880 chassis - pure enterprise really. We also use ME3800's where we need that additional functionality. Unfortunately the feature set of the 6k's at our time of purchase met our needs, luckily the me3800's has gave us features we found we required as our network evolved (and at a reasonable price point) otherwise we'd have had a very expensive forklift upgrade to ASRx or other vendor.

[joshuacmoore]

How have you been dealing with them from a bug perspective? Any major hurts there? We have found that it's pretty critical to stay up to date on the software releases.