Consider a simple network with two routers connected to each other (Figure 2-5).

Figure 2-5. Split horizon

Let’s say that router A lost its connection to 172.18.1.0, but before it could update B about this change, B sent A its full routing table, including 172.18.1.0 at one hop. Router A now assumes that B has a connection to 172.18.1.0 at one hop, so A installs a route to 172.18.1.0 at two hops via B. A’s next update to B announces 172.18.1.0 at two hops, so B adjusts its route 172.18.1.0 to three hops via A! This cycle continues until the route metric reaches 16, at which stage the route update is discarded.

Split horizon solves this problem by proposing a simple solution: when a router sends an update through an interface, it does not include in its update any routes that it learned via that interface. Using this rule, the only network that A would send to B in its update would be 172.18.1.0, and the only network that B would send to A would be 172.18.2.0. B would never send 172.18.1.0 to A, so the previously described loop would be impossible.

Split horizon works well for two routers directly connected to each other. However, consider the following network (shown in Figure 2-6).

Figure 2-6. Counting to infinity

Let’s say that router A stopped advertising network X to its neighbors B and E. Routers B, D, and E will finally purge the route to X, but router C may still advertise X to D (without violating split horizon). D, in turn, will advertise X to E, and E will advertise X to A. Thus, the router (C) that did not purge X from its table can propagate a bad route.

This problem is solved by equating a hop count of 16 to infinity and hence disregarding any advertisement for a route with this metric.

In Figure 2-6, when B finally receives an advertisement for X with a metric of 16, it will consider X to be unreachable and will disregard the advertisement. The choice of 16 as infinity limits RIP networks to a maximum diameter of 15 hops between nodes. Note that the choice of 16 as infinity is a compromise between convergence time and network diameter -- if a higher number were chosen, the network would take longer to converge after a failure; if a lower number were chosen, the network would converge faster but the maximum possible diameter of a RIP network would be smaller.

When a router detects a change in the metric for a route and sends an update to its neighbors right away (without waiting for its next update cycle), the update is referred to as a triggered update. The triggered update speeds convergence between two neighbors by as much as 30 seconds. A triggered update does not include the entire routing table, but only the route that has changed.

When a router detects that a link is down, its next update for that route will contain a metric of 16. This is called poisoning the route. Downstream routers that receive this update will immediately place the route in hold-down (without going through the invalid period).

Poison reverse and triggered updates can be combined. When a router detects that a link has been lost or the metric for a route has changed to 16, it will immediately issue a poison reverse with triggered update to all its neighbors.

Neighbors that receive unreachability information about a route via a poison reverse with triggered update will place the route in hold-down if their next hop is via the router issuing the poison reverse. The hold-down state ensures that bad information about the route (say from a neighbor that may have lost its copy of the triggered update or may have issued a regular update just before it received the triggered update) does not propagate in the network.

Triggered updates and hold-downs can handle the loss of a route, preventing bad routing information. Why, then, do we need the count-to-infinity limits? Triggered updates may be dropped, lost, or corrupted. Some routers may not ever receive the unreachability information and may inject a path for a route into the network even when that path has been lost. Count to infinity would take care of these situations.

The value of RIP timers on a Cisco router can be seen in the following example:

Chicago>sh ip protocol

Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 24 seconds
Invalid after 90 seconds, hold down 90, flushed after 180

These timers could be modified to allow faster convergence. The following command:

timers basic 10 25 30 40

would send RIP updates every 10 seconds instead of every 30 seconds. The other three timers specify the invalid, hold-down, and flush timers, respectively. These timers can be configured as follows:

NewYork#config
NewYork-config#router rip
NewYork-config#timers basic 10 25 30 40

However, RIP timers should not be modified without a detailed understanding of how RIP works. Potential problems with decreasing the timer values are that updates will be issued more frequently and can cause congestion on low-bandwidth networks, and that congestion in the network is more likely to cause routes to go into hold-down; this, in turn, can cause route flapping.

If an interface on a router goes down, the router sends a RIP request out to the other, up interfaces. This speeds up convergence if any of the other neighbors can reach the destinations that were missed in the first request.