6500 VSS - EoMPLS

[Arthur Kant]

We are testing a EoMPLS VC type 5 / Ethernet vc in our lab on VSS setup and not able to pass traffic.  The VSS is Sup2T (15 + code) and we have a single AC connected to switch 2 of the VSS.. with switch 1 currently having the active sup in the system.  The vc comes up/up like normal all mpls testing end to end looks fine however the pw will not pass traffic.

When we move the ac to a port on switch 1 of the vss all works as expected... the vss has no upstream mec.. rather just dual links up. (one on each chassis).. with the active ip path out switch 1 for the lsp.  

In theory we would expect traffic from the AC to come in switch 2 go across the VSL and go out...  are we missing something very obvious with mpls and vss ??

thanks!

[Georg Pauwen]

Hello Arthur,

what does the configuration of the VSL look like ? There are not really many options on how to configure the link, but can you post the config ?

[William Knobles]

gpauwen,

Arthur and I have been working together to get this up and running, so here are configuration snippets from the VSL in question:

interface Port-channel131
 description VSL link to Switch 2
 no switchport
 no ip address
 no platform qos channel-consistency
 switch virtual link 1
!
interface Port-channel132
 description VSL link to Switch 1
 no switchport
 no ip address
 no platform qos channel-consistency
 switch virtual link 2
!
interface TenGigabitEthernet1/5/4
 description VSL link to Colo 2 Te5/4
 no switchport
 no ip address
 no cdp enable
 channel-group 131 mode on
!
interface TenGigabitEthernet1/5/5
 description VSL link to Colo 2 Te5/5
 no switchport
 no ip address
 no cdp enable
 channel-group 131 mode on
!
interface TenGigabitEthernet2/5/4
 description VSL link to Colo 1 Te5/4
 no switchport
 no ip address
 no cdp enable
 channel-group 132 mode on
!
interface TenGigabitEthernet2/5/5
 description VSL link to Colo 1 Te5/5
 no switchport
 no ip address
 no cdp enable
 channel-group 132 mode on
!

[Georg Pauwen]

Hello,

the configs look good. The only thing I found in the best practices paper was that they added this to the port channel:

mls qos trust cos
no mls qos channel-consistency

[William Knobles]

If it helps... here is a basic diagram of the overall setup as well. Essentially, when we have CE-1 connected to VSS-SWITCH-1 everything works as expected, but as soon as we physically move CE-1 over to VSS-SWITCH-2 we are unable tp pass traffic between CE-1 & CE-A. The VC is up in both situations, but traffic does not flow.

[Georg Pauwen]

William, Arthur,

can you try this: connect CE-1 to VSS-Switch-2, but disconnect the link between VSS-Switch-2 and Router-2 ? I am starting to wonder if there is some sort of routing loop in your setup...

[Arthur Kant]

We cannot change upstream links do to the production state of the chassis.  If a routing loop existed it should also break the successful test when the ac is on switch 1 ?  vss is a single control plane.... unless I am missing something.

[William Knobles]

gpauwen,

We have rebuilt this environment in our lab, and disconnecting the link between VSS-Switch-2 & Router-2 did not resolve the problem.

All traffic except the MPLS xconnect is passing without any issues. This is the only traffic that is having any issues.

Once we built the lab we saw the same issue, wherein when the end device was connected to VSS-Switch-1, traffic flowed without issue, but once the end device was moved to VSS-Switch-2, traffic stopped flowing even though all MPLS attributes do not show any problems.

[Georg Pauwen]

Hello,

based on the document below, you might want to try and set the load balancing method of the port channel to mpls:

port-channel load-balance mpls

I am not sure what difference that would make, but since the obvious doesn't work, we might as well try the not-so-obvious.

Also, try and set the mls ip cef load-sharing to 'full'. Again, I am not sure what the effect is, but since you are in a lab enviroment, nothing bad can happen:

mls ip cef load-sharing full

Here is the link to the document I have been looking at:

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-virtual-switching-system-1440/109638-vss-pf-tshoot.html

[William Knobles]

SOLVED: We were able to resolve this problem by adding the following command to the VSS cluster as well as any potential PE devices:

'mpls ldp graceful-restart'

Once this command was entered we restarted all LDP neighborships using:

'clear mpls ldp neighbor *'

Once this had been completed on all potential PE devices we were able to pass traffic across the pseudowire as expected.

[Georg Pauwen]

William,

great stuff, good to know that you got it solved. I actually thought that command was only necessary for SSO/NSF, apparently it is also needed in VSS.