[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