Routing Protocols – Part 5

Continuing on with our discussion of improvements to Distance-Vector protocols, we were about to discuss hold down timers. Here’s our topology:

Let’s go back to the initial conditions, where the subnet was reachable. At that point, we had:

  • R1 sees as directly connected (zero hops)
  • R2 sees as reachable via R1 (one hop)
  • R3 sees as reachable via R1 (one hop)

Since R2 and R3 consider R1 to be their best next hop to reach, per the split-horizon rule neither R2 nor R3 is advertising to R1, but they are advertising it to each other. Let’s assume that R1 loses its connection to the subnet, we then have:

  • R1 sees as unreachable
  • R2 sees as reachable via R1 (one hop)
  • R3 sees as reachable via R1 (one hop)

Notice that R2 and R3 are currently mistaken as to the state of At this time, R1 sends flash updates to R2 and R3, poisoning the route to Let’s imagine that R2 processes the flash update prior to R3. Upon receipt of a poisoned update, a router will place the prefix into “hold down”, meaning that it will:

  • Start a hold down timer for that prefix
  • Mark the prefix as “possibly down”
  • Flood poison updates for the prefix
  • Continue routing packets for that prefix as before
  • Ignore updates for the prefix, unless the metric is better than before

The route stays in hold down until either the hold down timer expires, or a route for that prefix with a better metric is learned.

When a route is in hold down, packets for the prefix are routed as before, in case the route has come back up. The situation at this moment is:

  • R1 sees as unreachable
  • R2 sees as “possibly down” via R1 (one hop)
  • R3 sees as reachable via R1 (one hop)

Notice R2 now has in hold down, and that R3 is currently mistaken. Let’s imagine that just before processing the flash update it received from R1, R3’s periodic update timer expires, and R3 sends its routing table to R2. Since is in hold down on R2, the update from R3 (with a metric of two hops, worse than R2’s previous best metric of one hop) is ignored. Thus, the situation remains:

  • R1 sees as unreachable
  • R2 sees as “possibly down” via R1 (one hop)
  • R3 sees as reachable via R1 (one hop)

Shortly thereafter, R3 processes the triggered update it received from R1, and also places in hold down. The situation is now:

  • R1 sees as unreachable
  • R2 sees as “possibly down” via R1 (one hop)
  • R3 sees as “possibly down” via R1 (one hop)

In accordance with the hold down rules, any packets received by either R2 or R3 that are bound for will still be forwarded to R1, which will drop them or forward them depending on the actual state of that prefix. Obviously, no routing loop exists, but since neither R2 nor R3 is sure of the topology, the network is not yet converged.

Eventually the hold down timers on R2 and R3 will expire. At that point, either is reachable, or it is not. If it’s reachable, R1 will be periodically advertising it to R2 and R3, which will restore it to their routing tables as a normal route. If it’s not reachable, both R2 and R3 will remove it from their routing tables when their flush timers expire. Either way, shortly after the hold down timers expire, the network will be converged.

We’ve looked at six techniques for improving the performance of Distance-Vector routing protocols, including:

  • Defining a Maximum
  • Split Horizon
  • Route Poisoning
  • Poison Reverse
  • Triggered Updates
  • Hold Down Timers

In Cisco’s implementation of RIP, which uses all six techniques, the default values of the timers are:

  • Update – 30 seconds
  • Invalid – 180 seconds
  • Hold Down – 180 seconds
  • Flush – 240 seconds

The timers can be viewed with the show ip protocols command, and changed under the RIP routing process with the timers basic command.

Author: Al Friebe

In this article

Join the Conversation

1 comment

  1. shivlu jain Reply

    nice blog