[c-nsp] RFC4090 and Implementation in Cisco

alaerte.vidali at nsn.com alaerte.vidali at nsn.com
Thu Apr 19 13:05:17 EDT 2007


Tks Oliver,

I performed tests last night. On the implementation I tested (IOS
12.2.18.SXF) there is not alternative path then the headend keep using
the same path, with local repair done by intermediate router. 

I tested several times, removing FRR and reproducing the interface
flapping and also using IP Dampening. These are the results:

-FRR works like a "dampening" feature. When the failure interface is
recovered FRR does not revert immediately, but waits some seconds.

-Without FRR there is CPU spike because all TE tunnels goes down. This
has other negative impacts on other process like HSRP.

-IP Dampening (tested several different values) did not help avoiding
flapping on TE Tunnels. I got the impression that it is not integrated
with MPLS TE the same way it is integrated with Routing Protocols.

Comments?

Rgds,
Alaerte


-----Original Message-----
From: ext Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com] 
Sent: Thursday, April 19, 2007 2:02 AM
To: Vidali Alaerte (NSN BR/Rio de Janeiro); cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] RFC4090 and Implementation in Cisco

alaerte.vidali at nsn.com <> wrote on Thursday, April 19, 2007 3:32 AM:

>  Do you know if Cisco follows recommendation of RFC4090 in IOS
> 12.2.18.SXF5 to decrease the impact of link flapping when router 
> performing FRR detects the interface was recovered (but is flapping)?
> 
> snapshot of RFC4090 concerned the issue
>
========================================================================
> =
> Revertive Behavior
> 
>    Upon a failure event, a protected TE LSP is locally repaired by the
>    PLR.  There are two basic strategies for restoring the TE LSP to a
>    full working path.
> 
>     - Global revertive mode: The head-end LSR of each tunnel is
>       responsible for reoptimizing the TE LSPs that used the failed
>       resource.  There are several potential reoptimization triggers:
>       RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and
>       timers.  Note that this re-optimization process may proceed as
>       soon as the failure is detected.  It is not tied to the
>       restoration of the failed resource.
> 
>     - Local revertive mode: Upon detecting that the resource is
>       restored, the PLR re-signals each of the TE LSPs that used to be
>       routed over the restored resource.  Every TE LSP successfully
>       re-signaled along the restored resource is switched back.
> 
>    There are several circumstances in which a local revertive mode
>    might not be desirable.  In the case of resource flapping (not an
>    uncommon failure type), this could generate multiple traffic
>    disruptions. Therefore, in the local revertive mode, the PLR
>    should implement a means to dampen the re-signaling process in
>    order to limit potential disruptions due to flapping.
>
========================================================================


Local revertive mode is not implemented as far as I know. 

As mentioned in my other mail: use link dampening, and if your links are
really not stable, think twice before enabling link-up reoptimization
(which disabled by default). So by default a link coming back into
service is not used by existing TE tunnels until their periodic
reoptimization timer (1 hour) expires.

	oli



More information about the cisco-nsp mailing list