Apr
15

Sometimes its the simple things that are struggled with. RIP is one of those. Most CCIE candidates understand that we can change the interface or global parameters for updates, unicast, multicast, etc. What does take some time, is figuring out the global timers, especially if a person is not sure how they interact.

In this post, we will address the RIP process level timers for update, invalid, hold down and flush. I don’t want you to sleep during this, so we will save that one for later.

Timers Basic, all in seconds:
Update: how often to send updates in seconds
Invalid: how many seconds, since seeing a valid update, to consider the route invalid, and placing the route into hold down
Hold Down: Once in hold down, how long (in seconds) to “not believe” any equal or less impressive (worse) route updates for routes that are in hold down
Flush: how many seconds, since the last valid update, until we throw that route in the trash (garbage collection for un-loved non-updated routes)

Here is our topology.  Keep your attention on R2, and that will be the focal point for this lesson.

rip hold down

Let’s set up some unique values, so we can see the results.
Defaults are:

Update: 30
Invalid: 180
Hold Down: 180
Flush: 240

We will use 30,  40, 10 and 90 respectively.

R2(config)#router rip R2(config-router)#timers basic 30 40 10 90

We can see the results of our changes with show ip protocols.

R2#show ip protocols
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 23 seconds
 Invalid after 40 seconds, hold down 10, flushed after 90
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    FastEthernet0/1       2     2
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    10.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.23.0.3            120      00:00:03
  Distance: (default is 120)

We can see that R2 is learning 2 routes from R3, the 10.33.0.0/24 and 10.77.0.0/24 R2 received the last update 7 seconds ago, based on the output.

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 4 subnets
C       10.12.0.0 is directly connected, FastEthernet0/1
C       10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0 [120/1] via 10.23.0.3, 00:00:07, FastEthernet0/0 R 10.77.0.0 [120/8] via 10.23.0.3, 00:00:07, FastEthernet0/0

Let’s enable debugging so we can see the play by play.

R2#debug ip routing
IP routing debugging is on
R2#debug ip rip
RIP protocol debugging is on

Here is an update from R3. Notice the time stamp of 1:24:23. This will be the last one sent from R3. (Because we’ll configure R3 to go passive in a moment). Also, notice that we are sending and update as well. An update schedule of 30 seconds, based on the RFC for RIP, may be 30 seconds, + or – 5 seconds, to avoid synchronization. Let’s focus on the learned 10.77.0.0 network with a hop count of 8.

R2#
01:24:23: RIP: received v2 update from 10.23.0.3 on FastEthernet0/0
01:24:23:      10.34.0.0/24 via 0.0.0.0 in 1 hops
01:24:23: 10.77.0.0/24 via 0.0.0.0 in 8 hops
R2#
01:24:24: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2)
01:24:24: RIP: build update entries
01:24:24:       10.23.0.0/24 via 0.0.0.0, metric 1, tag 0
01:24:24:       10.34.0.0/24 via 0.0.0.0, metric 2, tag 0
01:24:24:       10.77.0.0/24 via 0.0.0.0, metric 9, tag 0
R2#
01:24:27: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2)
01:24:27: RIP: build update entries
01:24:27:       10.12.0.0/24 via 0.0.0.0, metric 1, tag 0

After the update from R3, learned on Fa0/0, I used the passive-interface default command on R3 inside of the router rip process.   While we wait for the invalid time to occur, due to the missing routes, we can entertain ourselves by seeing  updates being sent from R2, at 30 second intervals.

R2#
01:24:53: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2)
01:24:53: RIP: build update entries
01:24:53:       10.23.0.0/24 via 0.0.0.0, metric 1, tag 0
01:24:53:       10.34.0.0/24 via 0.0.0.0, metric 2, tag 0
01:24:53:       10.77.0.0/24 via 0.0.0.0, metric 9, tag 0
R2#
01:24:56: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2)
01:24:56: RIP: build update entries
01:24:56:       10.12.0.0/24 via 0.0.0.0, metric 1, tag 0

It has been 40 seconds since the last updates from R3, and 40 seconds was our invalid timer setting. (Our last update was 1:24:23, and now it is 1:25:03). The routes enter hold down, which means the router will not believe any new updates regarding these routes. Hold down is intended to assist in avoiding inaccurate routing by rumor information while the network converges. The exception would be if a route with a better (lower) metric was received by R2  for the 10.77.0.0, R2 would use it. (In our example, 10.77.0.0 had a metric of 8. If R2 learned about the 10.77.0.0 with a metric of 7 or lower from a neighbor, it would use it if learned during the hold down.)

R2#
01:25:03: RT: delete route to 10.34.0.0 via 10.23.0.3, rip metric [120/1]
01:25:03: RT: no routes to 10.34.0.0, entering holddown
01:25:03: RT: NET-RED 10.34.0.0/24
01:25:03: RT: delete route to 10.77.0.0 via 10.23.0.3, rip metric [120/8]
01:25:03: RT: no routes to 10.77.0.0, entering holddown
01:25:03: RT: NET-RED 10.77.0.0/24

R2 advertises a poisoned route for the networks in hold down. This is a triggered update, and not based on the normal 30 second update timer.

R2#
01:25:05: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2)
01:25:05: RIP: build flash update entries
01:25:05:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:05:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:05: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2)
01:25:05: RIP: build flash update entries
01:25:05:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:06:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0

R1, sends us a poison-reverse update, regarding the same networks. This intentionally overrides the split horizon rule which is in place on Ethernet interfaces by default.

R2#
01:25:08: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1
01:25:08:      10.34.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
01:25:08:      10.77.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
R2#
01:25:10: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1
01:25:10:      10.34.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
01:25:10:      10.77.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)

Another normal update, being sent by R2, including the poisoned routes.

R2#
01:25:22: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2)
01:25:22: RIP: build update entries
01:25:22:       10.23.0.0/24 via 0.0.0.0, metric 1, tag 0
01:25:22:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:22:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:22: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2)
01:25:22: RIP: build update entries
01:25:22:       10.12.0.0/24 via 0.0.0.0, metric 1, tag 0
01:25:22:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:22:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0

While the routes are in hold down, the router still forwards packets to those networks, based on the last information that it last learned about how to reach those networks. The routes will show up as “possibly down”.

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 4 subnets
C       10.12.0.0 is directly connected, FastEthernet0/1
C       10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0/24 is possibly down,
          routing via 10.23.0.3, FastEthernet0/0
R 10.77.0.0/24 is possibly down,
          routing via 10.23.0.3, FastEthernet0/0

So were is the removal of the hold down. The timer was only 10 seconds? Better late than never. Even though the hold down timer was set to 10 seconds, the hold down timer has to expire and then the next poisoned route received causes the routes to be removed from hold down. Our routes went into hold down at 25:03, it is now 25:36. Regardless of the hold down timer setting, if we didn’t receive any poisoned updates from neighbors, the hold down would stay until the flush timer removes the route completely.

R2#
01:25:36: RIP: received v2 update from 10.12.0.1 on FastEthernet0/1
01:25:36:      10.34.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
01:25:36: RT: 10.34.0.0 came out of holddown
01:25:36:      10.77.0.0/24 via 0.0.0.0 in 16 hops  (inaccessible)
01:25:36: RT: 10.77.0.0 came out of holddown

Even though the routes are done with their hold down, R2 still will show the route as possibly down, and will continue to do so until the flush timer expires.

R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 4 subnets
C       10.12.0.0 is directly connected, FastEthernet0/1
C       10.23.0.0 is directly connected, FastEthernet0/0
R 10.34.0.0/24 is possibly down,
          routing via 10.23.0.3, FastEthernet0/0
R 10.77.0.0/24 is possibly down,
          routing via 10.23.0.3, FastEthernet0/0

Another update clicks off, and then we approach the 90 second flush timer

R2#
01:25:49: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.12.0.2)
01:25:49: RIP: build update entries
01:25:49:       10.23.0.0/24 via 0.0.0.0, metric 1, tag 0
01:25:49:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:49:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:49: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.23.0.2)
01:25:49: RIP: build update entries
01:25:49:       10.12.0.0/24 via 0.0.0.0, metric 1, tag 0
01:25:49:       10.34.0.0/24 via 0.0.0.0, metric 16, tag 0
01:25:49:       10.77.0.0/24 via 0.0.0.0, metric 16, tag 0

Based on the last valid update of 1:24:23, and now that it is 1:25:53, 90 seconds are up (flush timer) and the routes are deleted.

R2# 01:25:53: RT: delete subnet route to 10.34.0.0/24 01:25:53: RT: NET-RED 10.34.0.0/24 01:25:53: RT: delete subnet route to 10.77.0.0/24 01:25:53: RT: NET-RED 10.77.0.0/24

Now the routes don’t show up in the routing table either.

R2# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 2 subnets
C       10.12.0.0 is directly connected, FastEthernet0/1
C       10.23.0.0 is directly connected, FastEthernet0/0

If we use context sensitive help, we find one more parameter for the timers:

R2(config-router)#timers basic 30 40 10 90 ?

<1-4294967295>  Sleep time, in milliseconds

And we’ll save that one for another blog.

Best wishes.


You can leave a response, or trackback from your own site.

16 Responses to “How basic are RIP timers? Test your knowledge now.”

 
  1. Ian Finlayson says:

    Excellent Blog…. Thanks for that!!!
    Really covers the RIP timers in the detail we would want…

    Cheers,
    Ian.

  2. Michal says:

    thanks for covering that in a lab form and waiting for the sleep time walk through.
    salutations,
    michal

  3. Rob Fleury says:

    Great post! How about doing the detail on when an interface
    actually fails ? Since a flash update and then regular updates would be sent, how do the timers respond/act ?

    Keep up the excellent work !

    Rob.

  4. Ronnie_hitman says:

    Sorry… i had Anthony on my mind…. Anyways thanks.

  5. Ronnie_hitman says:

    Great post … Thumb;s up to Anthony

  6. ARaaz says:

    Very informative, you’ve done it again.

    You woke me up from sleep – LoL.

  7. Somit Maloo says:

    Superb explanation.

  8. Raj says:

    Hi,
    Router R2 entered in Hold down state at
    01:25:03: RT: no routes to 10.34.0.0, entering holddown
    01:25:03: RT: NET-RED 10.34.0.0/24,
    Here we setted Holddown timer as 10 sec from Invaid.Then why it’s not come out from holdown at 01:25:13,
    Here it’s came out around
    01:25:36: 10.34.0.0/24 via 0.0.0.0 in 16 hops (inaccessible)
    01:25:36: RT: 10.34.0.0 came out.

    Pls clarify….

  9. AlexF says:

    > Pls clarify….

    OP says, “Regardless of the hold down timer setting, if we didn’t receive any poisoned updates from neighbors, the hold down would stay (until the flush timer removes the route completely).”
    OP implies that expiry of hold down timer on its own is not sufficient for the routes to be removed from hold down – an update is required.

  10. vgm says:

    Results were different from what was explained. I expected the flush timer to begin upon receipt of valid update. Instead, the flush timer, like the hold down timer, started upon expiration of the invalid timer. I connected four routers, configuring each with rip version2, and tried different values for the timers. Specific timer values used were, 30 60 90 120, 20 40 60 100, and the default timer values, 30 180 180 240. I deleted the link between Router1 and Router2 and observed the debug output from Router3.

  11. Excellent!!! says:

    I was bit confused with the timers. Got it now!!. thanks for the detail explanation.

  12. Niraj Shrestha says:

    Really appreciate the pains you took to illustrate the RIP timers concept.
    Thanks a ton man!

  13. mik says:

    excellent!!!!!

  14. Bob Potere says:

    slight typo near the top

    “We can see that R2 is learning 2 routes from R3, the 10.33.0.0/24 and 10.77.0.0/24 R2″

    should be:

    “We can see that R2 is learning 2 routes from R3, the 10.34.0.0/24 and 10.77.0.0/24 R2″

    Nice write up though, ran it through Packet Tracer to study it.

  15. Mehdi says:

    Hello,Great Job!Thank you very much for this post.It’s actually covered all aspect of RIP timers one by one clearly.Nice attempts!

    Cheers,
    Mehdi

  16. sandeepthumu says:

    if holddown timer(180 sec) starts after the invalid timer, the holddown timer will still be left with 120 more seconds even after flush timer (240 sec) is expired. pls expain?

 

Leave a Reply

Categories

CCIE Bloggers