cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1331
Views
0
Helpful
5
Replies

VPLS Support on 6500 Sup2t Standby Supervisor

Steve11
Level 1
Level 1

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.

net-pro-diag.png

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

1 Accepted Solution

Accepted Solutions

paulanfoo
Level 1
Level 1

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.

View solution in original post

5 Replies 5

Reza Sharifi
Hall of Fame
Hall of Fame

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

paulanfoo
Level 1
Level 1

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.

Did anyone get an answer to this or have a bug id with Cisco ?

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.

Steve11
Level 1
Level 1

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.