02-01-2012 04:07 AM
HI All,
I have an issue with an MPLS design on the 6500's new sup2t's (12.2(50)SY), in that the standby supervisor seems to be dropping VPLS traffic one way. See the diagram below;
In this topology everything else works fine, internal routing between sites, vrfs/MP-BGP all work fine - VPLS is the only thing that is affected.
We have eigrp peering between all 3 nodes advertising the loopbacks, mpls ip on the interfaces, ldp as the protocol.
The VPLS circuits are showing as being up, the ldp neighbor and route to the loopback is over the directly connected link however the standby supervisor seems to ignore VPLS traffic inbound on its port.
If i move the ports from the standby to the spare port on the active supervisor at the 3 sites the VPLS traffic is fine in all directions.
Can anyone comment on this design on wether this should work in principle and we are looking at a code/bug issue or a limitation of the architecture of the sup2t?
Many thanks
Solved! Go to Solution.
02-02-2012 10:21 PM
I think what he means is that he's using the uplink ports on the supervisors for 10g and they are dropping the packets.
Does the standby use the PFC built in like a DFC module when you use the uplink ports or does it ship it to the primary like it was a CFC module? This may be a bug as it should work.
02-02-2012 03:42 PM
Hi Steven,
The Stand-by Sup (whether you are running SSO or RPR) is not going to forward traffic. The stand-by sup is ready to take over and start forwarding packets in case there is failure with the primary.
HTH
02-02-2012 10:21 PM
I think what he means is that he's using the uplink ports on the supervisors for 10g and they are dropping the packets.
Does the standby use the PFC built in like a DFC module when you use the uplink ports or does it ship it to the primary like it was a CFC module? This may be a bug as it should work.
02-08-2012 08:26 AM
Did anyone get an answer to this or have a bug id with Cisco ?
02-08-2012 12:25 PM
No answer as yet, I'm awaiting our support contract to be organized to log this with TAC, i will post an update with cisco's response when i get it, or if anyone has any thoughts on this i would love to hear from them.
02-27-2012 08:30 AM
Hi Guys,
This issue was fixed using the command Mpls ldp graceful-restart on each of the 6500's. Apparently this mechanism is used to synchronize the LDP information between the active and standby supervisor.
Thanks to all who responded.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide