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

[Oliver Boehmer (oboehmer)]

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