RIP timers and reality, #3 (HOLDDOWN again)

We’re now going to test a different topology introduced at the end of article #2.

We are now going to test the HOLDDOWN timer of RIP when the backup router send a route with a metric higher than the primary router.

In this series of tests, we’ll see if the HOLDDOWN works in case the route disappears of R100 because of HOLDDOWN timer. Next time, we’ll see if it disappear if R101 advertises a metric 16 for NETWORK.

Third configuration

Normal situation: R101 advertises R100 for NETWORK with a RIP metric of 1. R100 has one route for NETWORK in his routing table via R101 with metric 1.

R102 does not yet advertise NETWORK to R100.

Breakdown: Instead of putting down R101, an distribute ACL for outgoing RIP advertisements is enabled on R101 so that R100 won’t receive RIP advs anymore, but can continue to ping R101 F0/0.

After some time, admin triggers R102 to start advertising NETWORK to R100 with metric 2.

Test 1

Timeline
-X min: network up and working
0 min: Action: NETWORK is not advertised anymore by R101, but R100 can’t see that directly, since it’s behind SW1. INVALID Timer starts
1 min and 30 sec: Action: R102 starts advertising NETWORK to R100 with metric 2 ; Reaction : route via R102 not put in routing table by R100 because its metric is higher than route via R101 (and R100 does not yet know R101 is dead)
3 min: Reaction: on R100, route to NETWORK via R101 is marked “possibly down”
3 min and 20 sec: on R100, route via R102 is now put into routing table.

Conclusion
It seems the HOLDDOWN holds itself from working. Indeed, even during the HOLDDOWN timer (more than 3 min after breakdown), R100 believes a route given by another router with a higher metric. How strange.

Now with the next two tests, we are going to an active breakdown instead of a silent breakdown. It means that the NETWORK will be cut from R101, so R101 will instantly see it and advertise R100. We are now completely in the context of the Cisco docs for the HOLDDOWN mechanism. Let’s see if it works.

Test 2

Timeline
-X min: network up and working
0 min: Action: NETWORK is cut from R101, that is interface F0/0 on R101 is shutdown. A route for NETWORK with metric 16 is sent by R101 to R100 ; Reaction: on R100, the route for NETWORK via R101 disappears instantly from the routing table
30 sec: Action: R102 starts advertising NETWORK to R100 with metric 2 ; Reaction: this route appears instantly in R100 : no holddown.

Conclusion
R100 should see the route coming from R102 as suspicious. Indeed, because of the nature of Distance Vector protocol, R100 cannot be sure that R102 does not go through R101 to reach NETWORK and is not advertised that it’s unreachable (maybe because of lost packets or 100% CPU). Instead of applying this suspicion, R100 chooses to put R102’s route into its routing table right away. How strange.

Let’s give a last chance to the HOLDDOWN mechanism : maybe it’s because R102 was not advertising since the very beginning?

Test 3

Timeline
-X min: network up and working
-30 sec: Action: R102 starts advertising NETWORK to R100 with metric 2
0 min: Action: NETWORK is cut from R101, that is interface F0/0 on R101 is shutdown. A route for NETWORK with metric 16 is sent by R101 to R100 ; Reaction: on R100, the route for NETWORK via R101 disappears instantly from the routing table
20 sec: Reaction: a route for NETWORK via R102 with metric appears in the routing table. R100 was waiting for the next RIP adv from R102 to take it into account. No holddown.

Conclusion
Here again, the HOLDDOWN mechanism does not work. This is very puzzling. It seems we are now far from the theory given by Cisco in the CCNA books.

(Un)fortunatly, I’m not the only one reaching this conclusion. Here’s what a guy in a thread said :
“Okay, ive read alot of stuff now. And even though its stated that when a route is received with an unreachable metric, the route should go into holddown. There’s no way I can get it to do this. The router sends out the inaccessible metric for the route, the neighbor receives it, sends out poison reverse, and deletes it from its routing table. Done.

Its annoying when the theory doesnt match reality.”

Here is some other discussion between CCIE experts about the subject and its implication on the CCNA exam.