[c-nsp] OSPF per-prefix LFA

Thu May 28 09:06:43 EDT 2015

I guess it depends on the values you configure.. But you need to be extra
careful if you are going to apply on a production device..

As you have probably already noticed, after OSPF timers tuning, the
convergence is quite fast even without the LFA.. So why would you bother to
configure LFA in the fiirst place?

My concern though is that according to RFC6571: "*Behavior of LFAs is an
automated process that makes fast restoration an intrinsic part of the IGP,
with no additional configuration burden **in the IGP or any other protocol.*
"

As I see it, the requirement for IGP tuning in order to make LFA work as
expected is somewhat "illegal".. If anyone else can explain that, I'd be
glad to hear..

--
George

On Thu, May 28, 2015 at 3:43 PM, Mohammad Khalil <eng_mssk at hotmail.com>
wrote:

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