Troubleshooting IGRP

When the timers and other variables of the IGRP process are changed from their defaults, the likelihood of causing problems increases. This is especially true if these values are changed without fully understanding the effects the changes will have. The first case study demonstrates this situation; IGRP is doing what it should, but the trouble is due to "cockpit error." The second case study demonstrates that a discontiguous range of addresses does not always result from a configuration error.

Case Study: Unequal-Cost Load Balancing, Again

The entire internetwork of Figure 6.20 is routed with a single IGRP process, and the bandwidths for the serial links are configured to the numbers shown. Default delays are used. Notice that the addresses of the link between Lovett and Harriman are different from the previous examples. Because network 10.0.0.0 can be reached from Acheson not only by the two serial links but also via the Ethernet to Lovett, the network administrator wants to distribute the traffic proportionately among all three routes:

The access points to network 10.0.0.0 are:

• Kennnan's Token Ring interface

• Kennan's Ethernet interface

• Harriman's Token Ring interface

Of Kennan's two interfaces to network 10.0.0.0, the lowest delay will be advertised, which is on the Token Ring interface. The minimum bandwidths of all three routes are the bandwidths of the serial interfaces. The metrics of the three routes from Acheson are:

• Via S0: 6476 + (2000 + 63) = 8539

• Via S1: 39062 + (2000 + 63) = 41125

• Via E1: 6476 + (100 + 2000 + 63) = 8639

The highest metric is 4.8 times the lowest metric, so variance will be five.

The variance is configured, but the administrator finds that load balancing is not working as expected (Figure 6.21). The routing table shows only the two routes via Kennan; the route via Lovett is between the highest and lowest metrics, but is not included.

Recall the three rules for including a route in a load sharing "group," as noted in the configuration case study on unequal-cost load balancing. In this example, the second rule, which says that the next-hop router must be metrically closer to the destination than the local best route, is being violated. At Lovett, the metric to 10.0.0.0 is 6476 + (2000 + 63) = 8539. This is equal to, but not better than, Acheson's best route.

The metric at Lovett can be made lower than 8539 by slightly increasing the bandwidth or slightly decreasing the delay on the serial interface. In this case, the delay is decreased by 10 microseconds:

Lovett(config)#interface serial 0
Lovett(config-if)#delay 1999
				

The resulting routing table is shown in Figure 6.22.

When manipulating metrics, pay close attention to the results. If the cost of a path does not reasonably reflect its actual capacity, the traffic load may be distorted—a low-bandwidth link may be overloaded, or a high-bandwidth link may be underutilized.

Case Study: A Segmented Network

Some time after the internetwork of Figure 6.20 has been up and running, with load sharing working properly, users begin to complain that traffic to subnet 10.108.14.0 through Acheson is intermittent. When the network administrator sends 100 pings to an address on this network, they confirm that traffic is indeed intermittent (Figure 6.23).

There is a nonrandom pattern to the ping results: five successful pings alternating with six timeouts. Enabling packet debugging and sending more pings reveals what is happening (Figure 6.24). Acheson is load balancing as it should, with a pattern of 5/5/1 (five packets via E1, five packets via S0, one packet via S1). The packets sent via E1 are successful, but all packets sent across the serial links fail.

Further investigation uncovers a disconnected lobe cable at Kennan's Token Ring interface, and the problem is repaired. The question remains: Why did the routes via the serial interfaces stay up? They were not marked unreachable, because Kennan's ethernet interface was still good. The router is summarizing network 10.0.0.0 to network 172.16.0.0, so there is no way for it to communicate the failed subnet.