Recursive Static Route Timers - Convergence time HIGH :(

kfarrington · ‎10-01-2008

Hey all,

I gotta a kinda urgent one for all the tech-heads to see if they can comment on.

Haven't posted to this forum (LAN) for a while, so hope you are all well :)

routerA<--------------->RouterB

Router A has a loopback79 of 79.79.79.79/32

Router A also has a loopback99 of 99.99.99.1/24

RouterA#sh ip route conn

99.0.0.0/24 is subnetted, 1 subnets

C 99.99.99.0 is directly connected, Loopback99

77.0.0.0/32 is subnetted, 1 subnets

C 77.77.77.77 is directly connected, Loopback77

RouterA#

So routerA and routerB run EIGRP between them and routerA has network statements in for both networks 99.0.0.0 and 79.0.0.0

RouterB has the following routes

RouterB#sh ip route 99.99.99.0

Routing entry for 99.99.99.0/24

Known via "eigrp xxx", distance 90, metric 153856, type internal

Redistributing via eigrp xxx

Last update from x.x.x.2 on GigabitEthernet1/43, 00:07:16 ago

Routing Descriptor Blocks:

* x.x.x.2, from x.x.x.2, 00:07:16 ago, via GigabitEthernet1/43

Route metric is 153856, traffic share count is 1

Total delay is 5010 microseconds, minimum bandwidth is 100000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

RouterB#sh ip route 79.79.79.79

Routing entry for 79.79.79.79/32

Known via "eigrp xxx", distance 90, metric 153856, type internal

Redistributing via eigrp xxx

Last update from x.x.x.2 on GigabitEthernet1/43, 00:00:13 ago

Routing Descriptor Blocks:

* x.x.x.2, from x.x.x.2, 00:00:13 ago, via GigabitEthernet1/43

Route metric is 153856, traffic share count is 1

Total delay is 5010 microseconds, minimum bandwidth is 100000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

RouterB#

====================All Normal so far, EIGRP routing===================

So, what I want to do is have on routerB, a recursive static route to 99.99.99.20/30 (subnet of the 99.99.99.0/24) that points towards the loopback 79.79.79.79 which is received on router B.

ip route 99.99.99.20 255.255.255.252 79.79.79.79

The reason for this is to generate a BGP prefix to another router routerC which is directly connected, to routerB, and runs eBGP.

But for clarity here, forget the BGP bit if you don't mind.

So, this all works.

RouterB#sh ip route 99.99.99.20

Routing entry for 99.99.99.20/30

Known via "static", distance 1, metric 0

Routing Descriptor Blocks:

* 79.79.79.79

Route metric is 0, traffic share count is 1

RouterB#sh ip route 79.79.79.79

Routing entry for 79.79.79.79/32

Known via "eigrp xxx", distance 90, metric 153856, type internal

Redistributing via eigrp xxx

Last update from x.x.x.2 on GigabitEthernet1/43, 00:00:13 ago

Routing Descriptor Blocks:

* x.x.x.2, from x.x.x.2, 00:00:13 ago, via GigabitEthernet1/43

Route metric is 153856, traffic share count is 1

Total delay is 5010 microseconds, minimum bandwidth is 100000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

RouterB#

The problem.

When you shut down the lo79 interface on routerA, eigrp updates IMMEDIATELY and the route is no longer in the table

BUT,

The static recursive route remains for between 30 and 60 seconds.

RouterB#show ip route 79.79.79.79

% Network not in table

RouterB#sh ip route 99.99.99.20

Routing entry for 99.99.99.20/30

Known via "static", distance 1, metric 0

Routing Descriptor Blocks:

* 79.79.79.79

Route metric is 0, traffic share count is 1

RouterB#

Is there a way to fix this via some sort of static route timer?

Many thx for your help with this and I hope someone else has seen this potential Issue/Feature?

Many thanks and kind regards,

Ken

Giuseppe Larosa · ‎10-01-2008

Hello Ken,

I would suggest you to use static routes with object tracking of the ip next hop so that detection of next hop available is done faster.

see

http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html#wp1066247

Hope to help

Giuseppe

kfarrington · ‎10-01-2008

Hi Giuseppe,

This looks like a good feaure. I will have a look at this, and will put in the lab. I am still strugling about the convergences times when a route is lost, it take 30 seconds plas to remover the recursive entry.

That would be a sensible way forward, and maybe I have done somthing wrong, or there is a way of tuning this.

Just need to see if we can get the basics right, and why this is a problem?

Am gonna test this feature tho mate :))

But still need to get to the bottom of this particular timing issue.

Thx Mr G, and all.

Ken

kfarrington · ‎10-01-2008

Hi all,

So, I have performed some debugs

And as you can see, the static routing process runs every 60 secs, and then just after the 3rd cycle, a few seconds later, i shutdown the lo79 on routerA.

I did a show IP route to ensure it was still there about 30 secs later and it was not until the Static routing timer ran on the next run, the recursive static route was removed.

Umm. Can that behaviour be changed?

What is the point of waiting for the timer to run?

Also, it is exactly the same for the reverse, ie, when the route or the lo79 comes back into the RT, the static recursive route will not be put in until the next ststic route timer run?

Many thx indeed,

Ken

routerB#sh debug

IP routing:

IP routing debugging is on

IP-STATIC:

IP static routing destination debugging is on, for 99.99.99.20 255.255.255.252

IP static routing detail debugging is on

IP static routing time spent debugging is on

IP static routing summary debugging is on

routerB#

23:26:18: IP-ST: if_list try 0

23:26:18: IP-Static: 99.99.99.20 255.255.255.252 79.79.79.79 Path = 2 3 5 7, route table no change, recursive flag clear

23:26:18: IP-ST: gw_list total 1, try 1, completed list TRUE

23:26:18: IP-Static: all_list, time elapsed 0 ms

routerB#

23:27:18: IP-ST: if_list try 0

23:27:18: IP-Static: 99.99.99.20 255.255.255.252 79.79.79.79 Path = 2 3 5 7, route table no change, recursive flag clear

23:27:18: IP-ST: gw_list total 1, try 1, completed list TRUE

23:27:18: IP-Static: all_list, time elapsed 0 ms

routerB#

23:28:18: IP-ST: if_list try 0

23:28:18: IP-Static: 99.99.99.20 255.255.255.252 79.79.79.79 Path = 2 3 5 7, route table no change, recursive flag clear

23:28:18: IP-ST: gw_list total 1, try 1, completed list TRUE

23:28:18: IP-Static: all_list, time elapsed 0 ms

routerB#

23:28:25: RT: delete route to 79.79.79.79 via 10.125.194.2, eigrp metric [90/153856]

23:28:25: RT: no routes to 79.79.79.79

23:28:25: RT: delete subnet route to 79.79.79.79/32

23:28:25: RT: delete network route to 79.0.0.0

routerB#

Routing entry for 99.99.99.20/30

Known via "static", distance 1, metric 0

Routing Descriptor Blocks:

* 79.79.79.79

Route metric is 0, traffic share count is 1

routerB#

routerB#sh clock

*04:44:47.490 UTC Wed Oct 1 2008

routerB#

23:29:18: IP-ST: if_list try 0

23:29:18: IP-Static: 99.99.99.20 255.255.255.252 79.79.79.79 Path = 2 3 5 6

23:29:18: RT: del 99.99.99.20/30 via 79.79.79.79, static metric [1/0]

23:29:18: RT: delete subnet route to 99.99.99.20/30 8, route table deleted, recursive flag clear

23:29:18: IP-ST: gw_list total 1, try 1, completed list TRUE

23:29:18: IP-Static: all_list, time elapsed 0 ms

Giuseppe Larosa · ‎10-01-2008

Hello Ken,

>> What is the point of waiting for the timer to run?

It is an implementation choice to limit cpu resources used by a single process: instead of executing on demand when the event occurs the static route ip next hops in case of recursion are checked every 60 seconds.

The scenario is similar for BGP for example: the BGP default scan time is of 60 seconds.

In this way if multiple changes occur one call of code manage all of them.

the trade-off is with convergence time.

Be aware that if you were using a simple static route using a directly connected next-hop on a lan interface the detection time could be up to the ARP timeout for the next-hop.

Hope to help

Giuseppe

kfarrington · ‎10-01-2008

Hi Mate,

This is most interesting.

As for the BGP scan time, yes it is 60 seconds. We found with conditional advertisements, it was using this scan time rather than the BGP next-hop scan time which is configurable.

Is now fixed as we raised a TAC case BugIDCSCsb54969

Would be nice if there was this kind of feature (per router) for statics to improve convergence?

Thx

Ken