[c-nsp] RFC4090 and Implementation in Cisco

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Thu Apr 19 15:27:45 EDT 2007


Bruce Pinsky <mailto:bep at whack.org> wrote on Thursday, April 19, 2007
7:27 PM:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> alaerte.vidali at nsn.com wrote:
>> 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.

What is the TE config on the headend? Did you configure to re-optimize
upon link-up?
If you didn't, I'm not sure why the headend re-optimizes along the new
path, it should keep the one it found shortly after the link has failed
(i.e. based on the link-down notification).

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

Why do the tunnels go down? Don't they find an alternate path? Not sure
I understand the topology and the tests you're doing.

>> -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. 

see above, would need to learn more about the topology to comment. 

Bruce:

> Based on the supported protocols list at:
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft
/120limit/120s/120s22/s_ipevdp.htm
> 
> I would say that MPLS/TE is not supported.  I would think there is a
> need for some RSVP hooks in that scenario.

Not sure there is. If IP event dampening holds the lineprotocol down
(i.e. when the penalty accumulated is too high), ISIS/OSPF will not get
notified, so the headend will not reoptimize (if it is configured to do
so). 

	oli



More information about the cisco-nsp mailing list