FIGURE 1: RIP Convergence Timers
Route Invalidation Timer
In figure-1, what will happen if R3 fails? There must be some mechanism to tackle this situation to avoid routing black-hole. When a route is learned from a neighbor, an invalidation timer is associated with it. If invalidation timer expires and no periodic update has been received, the route will be marked unreachable and pass down to neighbors along next update. In this case, R2 will mark R3 as unreachable and provide associate update to R1. Let us consider an example on IOS CLI. Consider figure-2 for topology details. The routing protocol is RIP version 2.
FIGURE-2: Route Invalidation, Triggered Update and Dead Timer example
RIP is configured as under:
|
Router R1 |
Router R2 |
|
router rip version 2 timers basic 5 10 20 40 network 10.0.0.0 network 192.168.1.0 no auto-summary |
router rip version 2 timers basic 5 10 20 40 network 10.0.0.0 network 172.16.0.0 no auto-summary |
Note that, RIP timers are tuned for faster convergence. The update is sent every 5 second. Route is invalid after 10 seconds. The hold-down period is 20 seconds and route is finally flushed after 40 seconds. The link/routing update failure is simulated with “passive-interface default” command on R1. This will cause the link status to “up and up” on R2.
The network is stable and routing tables for R1 and R2 are as under:
|
R1#show ip route | being Gateway Gateway of last resort is not set
172.16.0.0/24 is subnetted, 1 subnets R 172.16.2.0 [120/1] via 10.1.1.2, 00:00:02, Serial0/0 10.0.0.0/30 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Serial0/0 C 192.168.1.0/24 is directly connected, Loopback0 |
|
R2#show ip route | being Gateway Gateway of last resort is not set
172.16.0.0/24 is subnetted, 1 subnets C 172.16.2.0 is directly connected, Loopback0 10.0.0.0/30 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Serial0/0 R 192.168.1.0/24 [120/1] via 10.1.1.1, 00:00:03, Serial0/0 |
Let us consider that the link between R1 and R2 goes down and for some reason on R2 the line protocol status is still “up”.
Let us look at the routing table of R2:
|
R2#sh ip route rip R 192.168.1.0/24 [120/1] via 10.1.1.1, 00:00:12, Serial0/0 R2#sh ip route rip R 192.168.1.0/24 is possibly down, routing via 10.1.1.1, Serial0/0 |
Triggered Updates
Distance vector routing protocols send regular update at a specified time interval. This periodic update is a major source of routing information inconsistency and thus leading to routing loop. For example, in figure-1, if R2 losses path to R3 it must wait for the specified periodic update interval to inform R1. During this time interval, R1 continuously sends the traffic toward R2, a routing black-hole is now created for traffic destined to R3. The worst part is that if R2 install the alternative path via R1 leading to routing loop between R1 and R2. To avoid routing loop and speed up convergence, triggered update must be implemented.
Triggered updates send partial (not full) update when a metric change occurs. Reduces the chance of count-to-infinity problem, speed up convergence and saves link bandwidth since update contains only affected networks. In figure-1, as soon as R2 losses the route to R3, it must inform immediately R1 that path to R3 is lost. Thus R1 will immediately install the alternative path.
In the previous example, 192.168.1.0 was invalid after (around) 10 seconds, but still we have to wait for another 30 seconds for this invalid route entry to be removed from routing table. A quick way to refresh the routing table is to issue “clear ip route *” command. This causes the router to refresh the routing database instantly.
|
R2#sh ip route rip R 192.168.1.0/24 is possibly down, routing via 10.1.1.1, Serial0/0 R2# clear ip route * R2# show ip route | be Gateway Gateway of last resort is not set 172.16.0.0/24 is subnetted, 1 subnets C 172.16.2.0 is directly connected, Loopback0 10.0.0.0/30 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Serial0/0 |
Another example could be the route metric for 192.168.1.0/24 changes (to infinity). R1 will issue a triggered update to R2 at the same time it comes know of this change. Below is output of “debug ip rip” command.
|
Router R1: |
|
R2# configure terminal R2(config)# interface loopback 0 R2#(config-if)# shutdown
*Mar 1 00:30:24.779: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (10.1.1.1) *Mar 1 00:30:24.779: RIP: build flash update entries *Mar 1 00:30:24.783: 192.168.1.0/24 via 0.0.0.0, metric 16, tag 0 |
|
Router R2: |
|
*Mar 1 00:30:08.885: RIP: received v2 update from 10.1.1.1 on Serial0/0 *Mar 1 00:31:08.675: 192.168.1.0/24 via 0.0.0.0 in 16 hops (inaccessible) |
Dead Timer
Also called the flush timer (or garbage collector timer). Used to control how long a route stays in route table before completely flushed. Considering the previous example, R1 will wait from R2 for destination R3 for specified interval, until it flushes out from the routing table.
This brings us to the end of this article in which we covered further enhancements used by Distance Vector Routing Protocols to prevent routing loops and improve network convergence time.