[c-nsp] Fast Reroute Behavior when link is recovered

[Alaerte.Vidali at nokia.com]

Hi Oliver,

Thanks for the reply.

The config of OSRa is a explicit path with FRR request: 

interface Tunnel1
ip unnumbered loopback0
tunnel destination b.b.b.b
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mode mpls traffic-eng priority 0 0
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng path-option 1 explicit identifier 1
tunnel mpls traffic-eng fast-reroute
!
ip explicit-path identifier 2 enable
next address f.f.f.f
next address g.g.g.g
next address h.h.h.h


OSR1 protects the link OSR1-OSR2

interface Tunnel1000
ip unnumbered loopback0
tunnel destination 27.2.2.2
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 0 0
tunnel mpls traffic-eng path-option 1 explicit identifier 2
!
ip explicit-path identifier 2 enable
next address x.x.x.x
next address y.y.y.y
next address z.z.z.z
!
interface POS5/0
ip address 160.2.2.1 255.255.255.0
mpls traffic-eng tunnels
mpls traffic-eng backup-path Tunnel1000
pos ais-shut
pos report lrdi
ip rsvp bandwidth 2480000 2480000

I have tested this configuration simulation failure on OSR1--OSR2 link.
When I remove fiber, OSR1 protects the tunnel from OSRa to OSRb. When I
recover the OSR1--OSR2 fiber, FRR goes inactive and path follows the
initial set of routers.
Now, clients says that when real failures occurred, FRR protected the
link OSR1--OSR2, but when failure was gone, FRR keeps active, that is,
it does not detect link recovery.

I understood what you said about dynamic. I will test this situation,
with dynamic.
But do you have other idea when Explicit is used, no dynamic, and the
previous described situation occurs?

Cordially,
Alaerte




-----Original Message-----
From: ext Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com] 
Sent: Thursday, November 02, 2006 2:37 PM
To: Vidali Alaerte (Nokia-NET/RioDeJaneiro); cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Fast Reroute Behavior when link is recovered

cisco-nsp-bounces at puck.nether.net <> wrote on Thursday, November 02,
2006 6:24 PM:

> Greetings,
> I have tested Fast Reroute on 7600 with IOS 12.2(18) SXF5 and after 
> recovering the link from a failure, the original tunnel path is 
> recovered. For example: OSRa-----------------OSR1---- 
> -------------OSR2---------OSRb
>>> 
>>> 
> --------------------OSR3
> Tunnel is between OSRa and OSRb. One explicit path is used, no dynamic

> tunnel at all. FRR is configured to protect link between
> OSR1--OSR2 using link OSR1-OSR3. When link OSR1--OSR2 fails, FRR 
> recover from the failure using OSR1--OSR3--OSR2. When link OSR1--OSR2 
> is recovered, FRR is deactivated and original tunnel again follow 
> original path: OSRa--OSR1--OSR2--OSRb.
> That was the result during tests, simulating failures.
> But there are user reports saying that when link OSR1--OSR2 is 
> recovered, FRR keeps active and original path is not recovered.
> Have you seen this situation?

I'm not 100% sure, but I think you want to use a dynamic tunnel between
OSRa and b so the tunnel will actually be able to re-optimize after the
failure (i.e. the backup-tunnel will only be used for a short time). How
does your head-end TE config look like?
If the primary tunnel re-optimizes after the failure, a later link-up
does not necessarily triggers reoptimization (using the a-1-2-b path),
you need to enable "mpls traffic-eng reoptimize events link-up" to
trigger reopt for link-up events (or reduce the reopt timer so the
head-end tries this more often)..

	oli