[c-nsp] OSPF per-prefix LFA

Mohammad Khalil eng_mssk at hotmail.com
Thu May 28 08:43:25 EDT 2015


Hi
Dan , carrier-delay did not do the trick for me
George , I have configured the below
router ospf 1
timers throttle spf 777 888 999

And , yes it made a difference :)
Now , the question in my mind is that if I changed these timers to lower values than the default , will that affect the performance of the router or the SPF calculations negatively ?

BR,
Mohammad

From: ggiannou at gmail.com
Date: Thu, 28 May 2015 15:19:38 +0300
Subject: Re: [c-nsp] OSPF per-prefix LFA
To: eng_mssk at hotmail.com
CC: dan at illusionnetworks.com; cisco-nsp at puck.nether.net

Actually I was referring to the following timers
timers throttle spf X X X 
timers throttle lsa X X X 
timers lsa arrival X
timers pacing flood X
On Thu, May 28, 2015 at 3:17 PM, Mohammad Khalil <eng_mssk at hotmail.com> wrote:
Hi



Now , the main link is active again with hello/dead intervals adjsuted



CSR#sh ip ospf interface gigabitEthernet 1 | inc Dead

  Timer intervals configured, Hello 1, Dead 4, Wait 4, Retransmit 5



R2#sh ip ospf int f0/0 | inc Dead

  Timer intervals configured, Hello 1, Dead 4, Wait 4, Retransmit 5



CSR#sh ip route 2.2.2.2

Routing entry for 2.2.2.2/32

  Known via "ospf 1", distance 110, metric 2, type intra area

  Last update from 192.168.12.2 on GigabitEthernet1, 00:01:33 ago

  Routing Descriptor Blocks:

  * 192.168.12.2, from 2.2.2.2, 00:01:33 ago, via GigabitEthernet1

      Route metric is 2, traffic share count is 1

      Repair Path: 192.168.13.3, via GigabitEthernet2



CSR#sh ip cef 2.2.2.2

2.2.2.2/32

  nexthop 192.168.12.2 GigabitEthernet1

    repair: attached-nexthop 192.168.13.3 GigabitEthernet2



CSR#sh ip route repair-paths 2.2.2.2

Routing entry for 2.2.2.2/32

  Known via "ospf 1", distance 110, metric 2, type intra area

  Last update from 192.168.12.2 on GigabitEthernet1, 00:02:08 ago

  Routing Descriptor Blocks:

  * 192.168.12.2, from 2.2.2.2, 00:02:08 ago, via GigabitEthernet1

      Route metric is 2, traffic share count is 1

      Repair Path: 192.168.13.3, via GigabitEthernet2

    [RPR]192.168.13.3, from 2.2.2.2, 00:02:08 ago, via GigabitEthernet2

      Route metric is 3, traffic share count is 1



The outputs as I understood the feature is fine and backup route is in place , but I was asking about the time it should take the backup path to be installed in the RIB?



Thanks again



BR,

Mohammad



> Date: Thu, 28 May 2015 13:02:08 +0100

> From: dan at illusionnetworks.com

> To: cisco-nsp at puck.nether.net

> Subject: Re: [c-nsp] OSPF per-prefix LFA

>

> On 28 May 2015 at 12:24, Mohammad Khalil <eng_mssk at hotmail.com> wrote:

>

> > Hi all

> > I am trying to test the feature

> > My topology consists of three routers (one of them is CSR1000v) and the

> > other two are 3725 all simulated via GNS3

> >

> > R1(CSR) is connected to R2 and R3 , there is a direct connection as well

> > between R2 and R3

> > All routers are configured with a loopback interface with the form of

> > x.x.x.x/32 where x is the router number

> >

> > Now , R1 is learning R2 loopback interface normally and logically through

> > the direct link with R2

> >

> > When I shutdown the interface with R2 (as I do not want to turn off the

> > remote interface on R2 as I cannot turn on BFD on GNS3) and I have checked

> > the route to 2.2.2.2 , it took about 5-6 seconds to install the same route

> > via the backup path (via R3)

> >

> > Now , I have configured the feature on the CSR

> > CSR(config)#router ospf 1

> > CSR(config-router)#fast-reroute per-prefix enable area 0 prefix-priority

> > high

> >

> > And I repeat the same test it took about 4 seconds to learn the prefix via

> > the backup path

> >

> > Is this the expected behavior or it should be less than that?

> >

> > Thanks in advance

> >

> > BR,

> > Mohammad

> >

> >

>

> Hi Mohammed,

>

> What's the output of 'show ip repair-paths' and 'show ip cef 2.2.2.2' on R1

> when the link between R1 and R2 is up? You should see an RPR route for R2

> loopback via R3.

>

> If you don't see any RPR route, you may also need to force prefix-priority

> of loopbacks to high with something like:

>

> ip prefix-list LOOPBACK-PREFIXES seq 5 permit 2.2.2.2/32

> !

> route-map OSPF-SPF-PRIORITY permit 10

>  match ip address prefix-list LOOPBACK-PREFIXES

> !

> router ospf 1

>  prefix-priority high route-map OSPF-SPF-PRIORITY

> !

>

> I've had to do this on IOS before - not sure about XE.

>

> Thanks,

>

> Dan

> _______________________________________________

> cisco-nsp mailing list  cisco-nsp at puck.nether.net

> https://puck.nether.net/mailman/listinfo/cisco-nsp

> archive at http://puck.nether.net/pipermail/cisco-nsp/



_______________________________________________

cisco-nsp mailing list  cisco-nsp at puck.nether.net

https://puck.nether.net/mailman/listinfo/cisco-nsp

archive at http://puck.nether.net/pipermail/cisco-nsp/


 		 	   		  


More information about the cisco-nsp mailing list