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.
Best wishes,
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.
R2(config)#router ripWe can see the results of our changes with show ip protocols.
R2(config-router)#timers basic 30 40 10 90
R2#show ip protocolsWe 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.
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)
R2#show ip routeLet’s enable debugging so we can see the play by play.
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
R2#debug ip routingHere 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.
IP routing debugging is on
R2#debug ip rip
RIP protocol debugging is on
R2#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.
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
R2#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.)
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
R2#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.
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#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.
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
R2#Another normal update, being sent by R2, including the poisoned routes.
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)
R2#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”.
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
R2#show ip routeSo 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.
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
R2#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.
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
R2#show ip routeAnother update clicks off, and then we approach the 90 second flush timer
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
R2#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.
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
R2#Now the routes don’t show up in the routing table either.
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
R2# show ip routeIf we use context sensitive help, we find one more parameter for the timers:
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
R2(config-router)#timers basic 30 40 10 90 ?And we’ll save that one for another blog.
<1-4294967295> Sleep time, in milliseconds
Best wishes,
0 comments:
Post a Comment