We upgraded from sup 720s running to SUPT2s running VSS with VPLS and the VCs wouldn't pass traffic so we had to roll back. I am wondering if our procedure for the upgrade might have caused the problem. We have tested VPLS failing over on the SUP2Ts in the lab and it works great, however in the production network we had trouble.
When we upgraded from HSRP to VSS, we had a requirement to keep the outages brief. To achieve that we:
1) shut down all ports on the active HSRP switch (Switch 1). This was because the VPLS configuration was on the standby switch (Switch 2).
2) powered down switch 1 and installed the VSS configured SUP2T with all ports shut down.
3) waited until all modules were okay.
4) using scripts shut down all ports on switch 2, and immediately did a no shut on switch 1.
5) powered down switch 2 and installed the VSS configured SUP2T with all ports shut down
6) did a no shut on all ports on switch 2
This allowed us to have a minimal outage in the network. IP routing came back just fine.
After we upgraded all VPLS VCs showed that they were UP, but they showed one-way traffic and remote macs weren't learned.
I was wondering if this upgrade method somehow confused MPLS labeling or something in VPLS to cause it not to work? Maybe some tables related to related to MPLS or VPLS weren't flushed out due to the quick switch over?
I'm planning to have a similar setup “VSS with MPLS/VPLS using Sup2T and WS-X69xx/WS-X68xx line cards” for green field deployment, however; I don’t have a time to PoC the proposed solution, I’d appreciate if you share any limitations/restrictions of deploying such scenario.
Also could you please advise if this is a validated solution by Cisco
I updated my question with the answers you requested. Hopefully you were notified.
Professional Network Administrator
AT&T Global Services
Confidential: This e-mail and any files transmitted with it are the property of AT&T and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to which this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 760-715-4149 and delete this message immediately from your computer. Any other use, retention, dissemination forwarding, printing, or copying of this e-mail is strictly prohibited.
I experienced the same behavior with pseudowires on my 6504E/Sup2T's. I have LDP and CE interfaces present on both active and standby supervisors. EoMPLS traffic arriving on the standby supervisor would not be forwarded out the CE-facing interface.
Problem is that LDP fails to populate the standby supervisor's hardware forwarding tables like it does for the active sup and all the line cards. Putting MPLS LDP GRACEFUL-RESTART on the PE's and each of their neighbors fixed it as mentioned previously. Apparently, the GRACEFUL-RESTART code happens to touch the standby sup's forwarding tables.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...