RIP holddown

vvalancius · ‎02-03-2004

Hi,

Im trying to put a route in hold-down state in RIP environment (12.2T). The problem is that it goes to hold down only when these conditions are met:

1)invalid timer for that route expired

2)there were no other neighbors advertizing that destination recently

Joff Doyle book (as some others) state that route must go hold down for example if current next-hop advertised worse metric. This does not work!

Any ideas?

adamboyce · ‎02-03-2004

Hi

why are you trying to put a route into hold down?

the hold down timer is is used to stop routing loops.

if a router has not recieved an update about a specific route that has been advetised to it within 120 seconds (default for rip in cisco routers), the link will be placed into hold down.

Whilest the route is in hold down the router wll not accept any updates from any neighbor (except the router that sent the original update) with a worse metric during this time.

if you already knew this then you can check your timers for rip using the command: sh ip pro

if the timers are not correct then you can change them.

To change the timers use the command:

Router(config-router)#timers basic update invalid holddown flush [sleeptime]

vvalancius · ‎02-03-2004

Hi Adam,

Well, there were some curious situations in our network and I was trying to test them in my lab. So thats why im trying to put route into hold-down.

Most of what you have said works in practice, but it oposes to 'Jeff Doyle TCP/IPvol1' and 'Caslow, Pavlichenko - Bridges Routers and Switches for CCIE's'.

Doyle says that: "...An update with a hop count higer than the metric recorded in the routing table will cause route to go into hold-down for 180 seconds...". CCO also does not bother to provide more acurate information on that.

I suspect that RIP holddown behavior has changed in more recent releases. I have heard that with IOS 11.x RIP behaves exacactly as Doyle says. Its a pitty that Cisco does not document these things...

adamboyce · ‎02-05-2004

Really the book says that?

Hmmm

When a network is in hold down the network is not accessible. So any time a router receives an update from a different neighbour with a poorer metric about the same route it will be not accessible. That does not make sense.

I am an instructor for the Cisco networking academy program so I had a look through the material to see what is says. Here is what it came up with:

When a router receives an update from a neighbor indicating that a previously accessible network is now inaccessible, the router marks the route as inaccessible and starts a hold-down timer. If at any time before the hold-down timer expires an update is received from the same neighbor indicating that the network is again accessible, the router marks the network as accessible and removes the hold-down timer.

If an update arrives from a different neighboring router with a better metric than originally recorded for the network, the router marks the network as accessible and removes the hold-down timer.

If at any time before the hold-down timer expires an update is received from a different neighboring router with a poorer metric, the update is ignored. Ignoring an update with a poorer metric when a hold-down timer is in effect allows more time for the knowledge of a disruptive change to propagate through the entire network.

hope this helps

to place a bunch of networks into hold down for testing purposes. on the router you want the hold down to occour set the up date timer and hold down timer to two seconds and keep the dead timer the same

cheers

vvalancius · ‎02-05-2004

Regarding the books the poorer metric must be receved from the current next-hop for route to go to hold-down, so in theory there is no problem with availability (actualy there is less availability than only to react to unreachable metrics).

CNA RIP Curriculum has one thing that does not work in parctice - the route is not put to hold-down if it was advertized by neighbor with unachable metric. It ONLY goes to hold-down if the local invalid timer for the route expired.

If you have some small routers you can check that by yourself. I have tried this with 12.2T, and I heard rumours that older releases might behave more close to theory.

cheers