Configuring IGRP

Although a few more configuration options are available to IGRP than to RIP, the basic configuration is every bit as simple: The router command is used to establish the routing process, and the network command is used to specify each network on which IGRP is to run. As with RIP, only major network numbers can be specified because IGRP is also a classful protocol.

The commands neighbor , for sending unicast updates, and passive-interface , for preventing updates from being broadcast on selected subnets, were introduced in Chapter 5, "Routing Information Protocol (RIP)." They can be used with IGRP just as with RIP.

Offset-list was also introduced in Chapter 5. When used with IGRP, the offset variable is delay instead of hops .

A significant difference from RIP is that each IGRP has a process ID, which allows multiple processes to be run on the same router.

Case Study: A Basic IGRP Configuration

Only two steps are necessary to configure IGRP:

1. Enable IGRP with the command router igrp process-id .

2. Specify each major network on which to run IGRP with the network command.

The process ID is carried in the 16-bit autonomous system field of the update packet. The selection of a process ID is arbitrary ”any number between 1 and 65,535 (0 is not allowed) can be used, as long as it is used consistently on all routers that must share information via that particular IGRP process. Figure 6.11 shows a simple internetwork; the configurations for the three routers are as follows :

 
 McCloy(config)#  router igrp 10  
 McCloy(config-router)  #network 192.168.1.0  
 McCloy(config-router)  #network 192.168.2.0  
 
 Acheson(config)#  router igrp 10  
 Acheson(config-router)  #network 192.168.2.0  
 Acheson(config-router)  #network 172.16.0.0  
 
 Kennan(config)#  router igrp 10  
 Kennan(config-router)  #network 172.16.0.0  
 Kennan(config-router)  #network 10.0.0.0  
 

Figure 6.11. IGRP will perform address summarization at these three network boundary routers.

IGRP will perform subnet hiding, or summarization, at network boundaries. In the case of Figure 6.11, all three routers are network boundary routers.

Case Study: Unequal -Cost Load Balancing

Given up to six parallel routes of equal cost, ^[5] IGRP will do equal-cost load balancing under the same fast/process switching constraints as RIP. Unlike RIP, IGRP can also perform unequal-cost load balancing. An additional serial link has been added between Acheson and Kennan in Figure 6.12, with a configured bandwidth of 256K. The goal is to have Acheson perform unequal-cost load balancing across these two links “spreading the traffic load inversely proportional to the metrics of the link.

^[5] The default is four paths. See the case study on setting maximum paths for further details.

Figure 6.12. IGRP can be configured to perform unequal-cost load balancing across links such as the two between Acheson and Kennan.

Examining the route from Acheson's S0 interface to network 10.0.0.0, the minimum bandwidth is 1544K ( assuming Kennan's Ethernet interface is using the default 10000K bandwidth). Referring to Table 6.1, DLYIGRP(sum) for the serial interface and the Ethernet interface is 2000 + 100 = 2100. BWIGRP(min) is 10 ⁷ /1544 = 6476, so the composite metric of the route is 6476 + 2100 = 8576.

The minimum bandwidth on the route via Acheson's S1 to 10.0.0.0 is 256K; DLYIGRP(sum) is the same as on the first route. Therefore, the composite metric for this route is 10 ⁷ /256 + 2100 = 41162. Without further configuration, IGRP will simply select the path with the lowest metric cost. Figure 6.13 shows that Acheson is using only the path with a metric of 8576.

Figure 6.13. Acheson is using only the lowest-cost link to network 10.0.0.0. Additional configuration is needed to enable unequal-cost load balancing.

Note

Variance

The variance command is used to determine which routes are feasible for unequal-cost load sharing. Variance defines a multiplier by which a metric may differ , or vary, from the metric of the lowest-cost route. Any route whose metric exceeds the metric of the lowest-cost route, multiplied by the variance, will not be considered a feasible route.

The default variance is one, meaning that the metrics of multiple routes must be equal in order to load balance. Variance must be specified in whole numbers.

The metric of Acheson's route through S1 is 41162/8576 = 4.8 times larger than the metric of the S0 route. So to conduct unequal-cost load balancing over Acheson, the variance at Acheson should be five. The IGRP configuration is:

 
 routerigrp10 
 network172.16.0.0 
 network192.168.2.0 
 variance5 
 

After specifying a variance of five at Acheson, its routing table will include the second, higher cost route (Figure 6.14). The following three conditions must be met for a route to be included in unequal-cost load sharing:

1. The maximum-paths limit must not be exceeded as a result of adding the route to a load-sharing " group ."

2. The next-hop router must be metrically closer to the destination. That is, its metric for the route must be smaller than the local router's metric. A next -hop router, being closer to the destination, is often referred to as the downstream router.

3. The metric of the lowest-cost route, when multiplied by the variance, must be greater than the metric of the route to be added.

Figure 6.14. The composite metric of the second path to 10.0.0.0 is 41162, or 4.8 times the metric of the lowest-cost route. IGRP will enter the second path into the routing table if the variance is set to at least five.

The rules concerning per destination versus per packet load sharing, discussed in Chapter 3, "Static Routing," apply here as well. Load sharing is per destination if the packet is fast switched and per packet if process switching is used. Figure 6.15 shows a debug output resulting from 20 ping packets being sent through Acheson; fast switching has been turned off with no ip route-cache , and the router is performing unequal-cost, per packet load balancing. For every five packets sent over the 1544K link (to next hop 172.16.1.2), one packet is sent over the 256K link (to next hop 172.16.2.2). This corresponds to the approximately five-to-one variance of the metrics of these two paths.

Figure 6.15. Per packet load sharing is being performed, with one packet being sent over the high-cost link for every five packets sent over the low-cost link.

If variance is set at one, IGRP enters only the lowest-cost route to a destination into the routing table. In some situations, however ”for example, to decrease reconvergence time or aid in troubleshooting ”all feasible routes should be entered into the table, even though no load balancing should occur. All packets should use the lowest-cost route and switch to the next-best path only if the primary fails. There is an implicit default command (that is, it exists, but is not observed in the configuration file) of traffic-share balanced . To configure the router to only use the minimum-cost path even when multiple paths are shown in the routing table, change this default to traffic-share min . If there are multiple minimum-cost paths and traffic-share min is configured, IGRP will perform equal-cost load balancing.

Case Study: Setting Maximum Paths

The maximum number of routes over which IGRP can load balance is set with the maximum-paths paths command. Paths may be any number from one to six in IOS 11.0 and later and any number from one to four in earlier versions. The default for all versions is four.

Figure 6.16 shows three parallel paths of varying costs from McCloy to network 172.18.0.0. The network administrator wants to load balance over a maximum of only two of these routes while ensuring that if either of these paths should fail, the third route will replace it.

Figure 6.16. The maximum-paths and variance commands can be used together to configure load balancing over only two of the three links between McCloy and Bohlen. If either link fails, the third will take its place.

The metrics from McCloy are:

• Via S0: 9765 + (2000 + 100) = 11865

• Via S1: 19531 + (2000 + 100) = 21631

• Via S2: 78125 + (2000 + 100) = 80225

The metric of the S2 route is 6.76 times as large as the lowest-cost metric, so the variance is seven. McCloy's IGRP configuration is

 
 routerigrp10 
 variance7 
 network172.20.0.0 
 network192.168.1.0 
 network192.168.2.0 
 maximum-paths2 
 

The variance command ensures that any of the three routes to 172.18.0.0 is feasible; the maximum-paths command limits the load-sharing group to only the two best routes. The results of this configuration can be seen in Figure 6.17. The first routing table shows that McCloy was load balancing over the two links with the lowest of the three metrics, S0 and S1. After a failure of the S1 link, the second routing table shows that the router is now load balancing over the S0 and S2 links. In each instance, the router will load balance inversely proportional to the metrics of the two paths.

Figure 6.17. The routing table for McCloy, before and after the failure of one of three links, shows the results of using the variance and maximum-paths commands to configure load sharing to 172.18.0.0.

Case Study: Multiple IGRP Processes

Two new routers, Lovett and Harriman, have been added to the internetwork (Figure 6.18). A decision has been made to create two IGRP autonomous system "domains" in the internetwork with no communications between the two. Figure 6.19 shows the two autonomous systems and the related links for each.

Figure 6.18. Separate routing domains are to be created in this internetwork.

Figure 6.19. The routers Harriman and Acheson will each run multiple IGRP processes to facilitate the creation of separate autonomous systems (AS 10 and AS 15) within this IGP.

The configurations for Bohlen, Lovett, McCloy, and Kennan are straightforward: Bohlen, Lovett, and McCloy will run IGRP 10, and Kennan will run IGRP 15. At Acheson, the configuration will be:

 
 routerigrp10 
 network192.168.2.0 
 network192.168.3.0 
 ! 
 routerigrp15 
 network172.16.0.0 
 

Each process will run only on the interfaces of the networks specified. At Harriman, both interfaces belong to network 10.0.0.0:

 
 routerigrp10 
 passive-interfaceTokenRing0 
 network10.0.0.0 
 ! 
 routerigrp15 
 passive-interfaceSerial0 
 network10.0.0.0 
 

Using the passive-interface command prevents IGRP updates from being broadcast on data links where they don't belong.