[c-nsp] stuck transit LSP's

[Ben Cornish]

Hey Lukas,

Both platforms:

7600's -> c7600s72033-advipservicesk9-mz.151-3.S4.bin
ASR1001-X -> asr1001x-universal.03.13.02.S.154-3.S2-ext.SPA.bin

It's a static Tunnel with FRR set.

The only commonality we can find it in all cases - the forwarding path for the LSP on the midpoint is ECMP ... 

The crap thing is - we are having real difficulty in reproducing this in the LAB... 

-----Original Message-----
From: Lukas Tribus [mailto:luky-37 at hotmail.com] 
Sent: Tuesday, 17 November 2015 12:42 AM
To: Ben Cornish; 'cisco-nsp at puck.nether.net'
Subject: RE: [c-nsp] stuck transit LSP's

> Hey All,
>
> For the purpose of this issue / explanation.. We run lots of brocade LSP's over top of a Cisco MPLS network.
> Mostly of ASR 1K's and 7600's - all running LDP and RSVP dual stack for transiting these LSP's. brocade MLX / CER's / CES's on the edge.
> The Cisco routers are simply transiting the LSP's.
>
> Everything works as expected except after we see a OSPF topology change. For example a carrier link drop and come back.
> After this event, we see the odd LSP just sit in a up/down state. As in over a hundred FRR around the issue yet one of 2 just don't.
> It seems the cisco is still signals back to the brocades that the tunnel is ok - when its clearly not. The brocades all indicate tunnels are fine.
> The tunnel remains down and each end believes its up. The only identifications we see is the 'show mpls traffic-eng tunnels' is its up/down - on the cisco transiting LSP device.
> We see next to no pattern and the issue when repeats doesn't always affect the same LSP's.
>
> The only resolution is to tear the tunnel down manually and bring it back. Re-optimisation doesn't work.
>
> Curious if anyone has seen an issue like this ? or any suggestions ?

This happens on both ASR1k and 7600 midpoints? In different releases?

What about the requested tunnel bandwidth, is it static or are you using something like auto-bw? The requested bandwidth may be the pattern you are looking for (thinking of CSCsg44555).


Lukas