How basic are RIP timers? Test your knowledge now.
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.
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.
<strong>R2(config)#router rip R2(config-router)#timers basic 30 40 10 90</strong>
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 routeGateway 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 routeGateway 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 routeGateway 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.
<strong>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</strong>
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 routeGateway 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.
