Preventing Count to Infinity Issues on Your Network
The Counting to Infinity phenomenon can quickly disable a Distance Vector routing protocol managed network. The following sections explore ways to prevent count to infinity and the resulting routing loops from happening on your network.
If you are using RIPv1, you have a solution in the form of a concept called split horizon. In this concept, if you receive routing on one interface, sending that information back out of that interface is not likely to be productive.
So, if you examine only the routing information for the network 10.4.0.0/16 in the routing process, the flow of the route information is passed as follows:
Router2 learns of the route to 10.4.0.0/16.
It learns of the route through interface S0/1 facing Router3.
Router2 sends its routing table updates.
The updates go out through both of its interfaces, but filters the route to 10.4.0.0/16 out of the list when it sends the routes out through interface S0/1, as shown in the following figure.
Router1 receives the route to 10.4.0.0/16 from Router2 on interface S0/0.
Router1 sends its routing table updates.
These updates go out through both of its interfaces, but filters the route to 10.4.0.0/16 out of the list when it sends the routes out through S0/0.
Rather than using split horizon, RIPv2 implements a process called route poisoning. Following is the sequence for the route poisoning process:
Router3 identifies that the link to 10.4.0.0/16 is down.
The Router3 immediately updates its metric for that network to infinity — or in the case of RIPv2, a hop count of 16 — and sends that routing table update out immediately, as illustrated in Figure 6-7.
Router2 gets the update.
It then updates its own routing table by removing the route to 10.4.0.0/16, because it is no longer valid. After this update is complete, Router2 sends its own update out through interface S0/0.
Router1 gets the update.
This update no longer includes a route to 10.4.0.0/16, causing Router1 to remove the route to that network.
With router poisoning, the update process escalates so that improper route information is removed from the network in a timely manner. You can extend this system using a process called poison reverse.
In this case, after Router2 sees the hop count or metric go to infinity, it also sends a routing table update back to Router3 with an infinite metric telling it that the route to 10.4.0.0/16 is no longer available. This process reduces the chance that an improper update will make it through to Router3 and cause a loop.
Hold-down timers are another solution to routing loops that some routing protocols implement. Hold-down timers prevent protocol update messages from improperly updating routes for links that are currently down. Following is the hold-down timers implementation sequence:
Router2 receives an update telling it that the link to 10.4.0.0/16 is down.
Router2 marks the route as possibly down and sets a hold-down timer.
Router2 waits for an update.
If it gets an update with a metric better than the original one, Router2 records the route as up and accessible.
If it does not get an update in the timer interval, Router2 removes the route from its routing table.
Routes that Router2 receives with a metric worse than the original route are automatically removed.
During the hold-down period, if any data is being sent to the 10.4.0.0/16 network, the data is sent on as a delivery attempt. The delivery attempt is made in the event that the link to 10.4.0.0/16 is having an intermittent problem.
Triggered updates deal with count to infinity issues by forcing an update as soon as the link changes.
So, going back to the network layout you have been using, when the link to network 10.4.0.0/16 goes down, Router3 sends an immediate update notifying its neighbors that the link is down. Router2 receives the update and immediately passes the update to its neighbors, such as Router1.
As part of its normal update schedule, Router2 might still receive another update from Router1 prior to getting the update to remove the route. The solution is to combine triggered updates with hold-down timers, which prevents routes with worse metrics from being added to a router's routing table.