Troubleshooting IGRP

Like RIP, troubleshooting IGRP is usually an easy task. In most cases, it is a matter of following a route through the internetwork and examining the routing tables at each hop until the source of the trouble is discovered . The trouble is usually related to a misconfigured address or mask or to discontiguous addressing.

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

Figure 6.20. This internetwork has three paths from Acheson to network 10.0.0.0.

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.

Figure 6.21. The route to 10.0.0.0 via Lovett is not included in the table for load sharing.

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.

Figure 6.22. After the delay on Lovett's serial interface is decreased by 10mS, Acheson will accept Lovett's route to 10.0.0.0.

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).

Figure 6.23. The intermittent behavior of traffic to subnet 10.108.14.0 can be observed with these pings. Only 45% are successful.

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.

Figure 6.24. Sending 15 pings with packet debugging turned on reveals a large clue. Packets taking the route via Lovett successfully reach their destination, whereas all packets through Kennan 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.