cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1837
Views
0
Helpful
4
Replies

[ios pw redundancy with xr mc-lag termination]

Carlos A. Silva
Level 3
Level 3

hi, all:

first of all, thanks in advance and please take a look at the attached diagram.

i'm trying to setup a pseudowire redundancy setup between an ME3800 and two ASR9000s that build a mlacp etherchannel towards a cat4500, 4500-2. when primary pseudowire is up, everything works as expected. the problem is that, when you cause a switchover scenario from the primary asr9k-1 (say by shutting down the link to the 4500-2) to the secondary asr9k-2, traffic does not pass from one end of the pw to the other. if we bring up the failed link back up, primary pw works.

all 'show' commands checkout and pw switches over as expected. as a test, i have a 3rd asr9k connected in parallel to the ME3800 and we have no problem with that. when we cause the exact same failure scenario, the primary pw switches over to the secondary and everything works exactly like i would expect. traffic passes in both pri and stby pws when using the parallel asr9k.

as you will be able to see from attached-configs, the pw's from ME3800 and asr9k are a little different. ME3800 pw is port-based and asr9k pw is vlan-based, but since both primary pws work i see no obvious problem with that.

now, i know both ends of the mc-lag work, because the asr9k pw redundancy setup works.

if i build a single pw (no redundancy) from ME3800 to asr9k-1 connecivity works AND if i build a single pw from me3800 to asr9k-2 on same exact vlan, connecivity works also.

hopefully, one of you will take the time to look at configs and let me know if you see something wrong (i think with the ME3800 config). please keep in mind that everything works perfectly when working with asr9k pw redundancy (xr on both ends of pw)

c.

============

ME3800 (pw-redundancy)

3800#show run | section pseudowire

pseudowire-class mpls

encapsulation mpls

status peer topology dual-homed

! tried it without above status command, didn't work either.

3800#show run int g0/24          

Building configuration...

Current configuration : 175 bytes

!

interface GigabitEthernet0/24

no switchport

no ip address

xconnect 207.x.y.9 1100 encapsulation mpls pw-class mpls

  backup peer 207.x.y.17 1101 pw-class mpls

end

3800#

3800#show xconnect all

Legend:    XC ST=Xconnect State  S1=Segment1 State  S2=Segment2 State

  UP=Up       DN=Down            AD=Admin Down      IA=Inactive

  SB=Standby  HS=Hot Standby     RV=Recovering      NH=No Hardware

XC ST  Segment 1                         S1 Segment 2                         S2

------+---------------------------------+--+---------------------------------+--

UP pri   ac Gi0/24:78(Ethernet)          UP mpls 207.x.y.9:1100            UP

IA sec   ac Gi0/24:78(Ethernet)          UP mpls 207.x.y.17:1101           DN

3800_sw_pruebas#

============

ASR-3 (pw-redundancy)

RP/0/RSP1/CPU0:ASR-3#show run l2vpn

Sat Jun 15 09:07:10.183 CST

l2vpn

xconnect group PRUEBAS-XXXX

  p2p ESC-MTZ

   interface Bundle-Ether1000.28

   neighbor 207.x.y.9 pw-id 1128

    backup neighbor 207.x.y.17 pw-id 1228

RP/0/RSP1/CPU0:ASR-3#show l2vpn xconnect

Sat Jun 15 09:20:26.183 CST

Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,

        SB = Standby, SR = Standby Ready

XConnect                   Segment 1                   Segment 2               

Group      Name       ST   Description            ST   Description            ST

------------------------   -------------------------   -------------------------

PRUEBAS-XXXX

           to4500-2    UP   BE1000.28              UP   207.x.y.9    1128   UP

                                                       Backup                  

                                                       207.x.y.17   1228   DN

--------------------------------------------------------------------------------

RP/0/RSP1/CPU0:ASR-3#

============

asr9k-1  (pw-termination)

RP/0/RSP0/CPU0:asr9k-1#show run l2vpn

Sat Jun 15 09:09:10.555 CST

l2vpn

pw-status

pw-class mpls

  encapsulation mpls

   redundancy

    one-way

   !

  !

!

xconnect group PRUEBAS-XXXX

  p2p toASR-3

   interface Bundle-Ether1000.28

   neighbor 207.x.y.1 pw-id 1128

   !

  !

  p2p toME3800

   interface Bundle-Ether1000.26

   neighbor 207.x.y.30 pw-id 1100

   !

  !

!

!

RP/0/RSP0/CPU0:asr9k-1#show run redundancy

Sat Jun 15 09:09:16.659 CST

redundancy

iccp

  group 1000

   mlacp node 1

   mlacp system mac 000d.000e.000f

   mlacp system priority 1

   member

    neighbor 207.x.y.17

   !

   backbone

    interface Bundle-Ether1

   !

  !

!

============

RP/0/RSP0/CPU0:asr9k-2#show run l2vpn

Sat Jun 15 09:13:39.908 CST

l2vpn

pw-status

pw-class mpls

  encapsulation mpls

   redundancy

    one-way

   !

  !

!

xconnect group PRUEBAS-XXXX

  p2p toASR-3

   interface Bundle-Ether1000.28

   neighbor 207.x.y.1 pw-id 1228

   !

  !

  p2p toME3800

   interface Bundle-Ether1000.26

   neighbor 207.x.y.30 pw-id 1101

   !

  !

!

!

RP/0/RSP0/CPU0:asr9k-2#show run redundancy

Sat Jun 15 09:13:43.656 CST

redundancy

iccp

  group 1000

   mlacp node 2

   mlacp system mac 000d.000e.000f

   mlacp system priority 1

   member

    neighbor 207.x.y.9

   !

   backbone

    interface Bundle-Ether1

   !

  !

!

!

4 Replies 4

xthuijs
Cisco Employee
Cisco Employee

hard to tell where and why the traffic gets dropped if I were to guess the me might send traff still down the wrong PW

due to mac learning so it might need to get flushed.

I thought however that as part of the pw switchover the mac flush is instantiated.

either case you want to set up a stream of say 1000 pps so it is easy to verify and check the np counters to see where and why these paks are getting dropped and if it is the 9k or the me in that regard.

suspect a pw signaling and mac flushing issue here.

xander

See the thing here is I'm sending traffic from the mc-lag side to the 3800. I actually see the counters increase (going in to) in the ME3800 but they never go out to the AC. At least that's what I think.

Since the all-ASR scenario works without problem, I'm assuming it's an ME3800 issue.

Interesting Carlos, you see it coming in on the right PW?

If that is the case then there is some internal switching issue inside the 3800 based on sig or something like that.

I dont know the me3800 well enough so I cant really tell you what commands to verify for this and you may have better luck handing this over to the ME3800 TAC support or the forum specific to that product.

cheers

xander

yup, coming into the right PW. i'll wait until tomorrow and might open a case.

thanks,

c.