Tuning EIGRP Updates

Tuning, Redistribution, and Controlling IGRP Updates

Like RIP, IGRP has several parameters for tuning timers, controlling broadcasts, load-sharing, and controlling routes. The following is a list of parameters adjustable within IGRP:

• Router(config-router)#timers basic update invalid holddown flush [ sleeptime ] ” This allows the user to set the update, invalid, hold-down, flush, and optional sleep timers for IGRP.

  To allow IGRP unicast updates, define a next -hop neighbor with the neighbor command. The command functions identically to the RIP version. For more information on configuring unicast routing updates, see Chapter 9, "Distance Vector Protocols: Routing Information Protocol Versions 1 and 2 (RIP-1 and RIP-2)."

• Router(config-router)#passive-interface interface_name ” This command prevents routing updates from being sent on an interface. The router, however, still listens to broadcast or unicast updates as they are received on that interface.

• Router(config-router)#neighbor a.b.c.d ” This command defines an IGRP neighbor to exchange unicast updates with. This command should be used in conjunction with the passive-interface command.

• Router(config-router)#offset-list [ access_list_0-99 [ in out ] offset {metric_offset_ 1-214748364} [ interface ] ” Use this command to increase the value of the routing metrics. The metric offset cannot exceed 214,748,364.

  To filter routing updates in IGRP, use a distribute list. A distribute list, as you recall, calls a standard or extended access list and filters routing updates accordingly . When redistributing one protocol into another, use the redistribute command along with the default metric. A route map should be used in place of a distribute list when controlling specific routes during the redistribution process. In the section on IGRP integration, you can see an example of redistribute and default-metric commands.

• Router(config-router)#distribute-list {1-199} [ in out ] [ interface ] ” Use this command to call a standard or extended access list to filter inbound or outbound routing updates.

• Router(config-router)#redistribute {connected static bgp rip eigrp ospf isis} [ metric metric-value ] [ route-map map-tag ] ” Use this command to redistribute other routing protocols into IGRP. A route map can be added for additional route control. An optional metric also can be supplied for routes originating from the routing protocol being redistributed that are different from the default metric. Whenever redistributing routes, remember that IP needs a route to and from a destination. Many times mutual redistribution might be required to give IP a path to and from its destination.

• Router(config-router)#default-metric bandwidth_kbps 1-4214748364 delay_ microseconds 1-4214748364 reliability 1-255 load 1-244 mtu 1-4214748364 ” Use this command to set the default metric of all routes redistributed into IGRP. Keep in mind that if the metrics are defined on the redistribute command shown previously, those metrics override any metrics set here. You must supply a default metric when redistributing between protocols either by using the default-metric command or by specifying the metrics on the redistribute command. A common metric to use is default-metric 10000 1000 254 1 1500. This metric tells the router to derive the composite metric from the values of bandwidth of 10000, a delay of 1000, a load of 1 (or no load), and an MTU of 1500. The link is 254 reliable here, where 255 is 100 percent reliable.

The following subsets of commands are used to influence routing decisions. Individual metrics can be modified, as can the administrative distance of the IGRP. Whenever influencing a specific links metric, use the delay command over the bandwidth command. Both can be used, but OSPF also is affected by bandwidth, whereas delay affects only IGRP and EIGRP.

• Router(config-router)#metric weights 0 k1 k2 k3 k4 k5 ” This command enables you to set the weight of the IGRP metric in terms of bandwidth, load, delay, and reliability.

• Router(config-router)#distance weight_1-255 [ adjacent_neighbors_ip_address wildcard_mask [ access_list_0-99 ]] ” Use this command to change the administrative distance of routes received from a neighbor. If the IP address and wildcard mask are omitted, all routes for that protocol are set to the distance value. For a specific example and more practice with the distance command, see Chapter 9 lab 20.

• Router(config-if)#delay microseconds_1- 4214748364 ” This command specifies the delay of an interface in tens of microseconds. This command is used only by routing protocols and does not affect traffic on the link.

• Router(config-if)#bandwidth bandwidth_kbps_1-4214748364 ” This command specifies the bandwidth of an interface in kilobits per second. This command is used only by routing protocols and does not affect traffic on the link.

Unequal -Cost Load Balancing

IGRP has the capability to use unequal-cost load balancing. The router uses variance as a multiplier in choosing the upper boundary of path with the greatest metric.

Configuring unequal-cost load balancing is a three-step process:

Step 1. Configure the bandwidth on both sides of all the interfaces involved in the load-sharing group . Use the bandwidth kbps command to accomplish this.

Step 2. Define the lowest -cost metric and the highest-cost metric. From these values, compute the variance multiplier and add it to the IGRP routing process.

Step 3. Optional: Set the maximum-paths or the traffic-share variables .

The following example walks through the calculation of a fictional variance. IGRP has a route, and the metric of that route is 100. The router also has two more routes to that same destination, and the metrics for those routes are 200 and 300. To allow IGRP to use all three paths in sharing data, you would set the variance to 3. (3 x 100) = 300, or (Best_metric) x (variance) = Largest metric of path to load share over. To properly set the variance, use the following formula:

The metric of the lowest-cost route can be discovered with the debug ip igrp transactions command. Be sure to change the variance and other variables on both ends of the link. The bandwidth also should be set on all serial links. The following syntax is used in configuring load balancing:

• Router(config-router)#variance metric_multiplier 1-128 ” Defines the metric multiplier of which routes to use in unequal-cost load balancing. The default variance is 1, which is equal-cost load balancing.

• Router(config-router)#maximum-paths 1-6 ” By default, the router uses four equal-cost paths for load sharing, but up to six paths can be set using this command. This command also can be used to limit this number. The multiple paths that make up a single-hop transport to a common destination are called a load-sharing group.

• Router(config-router)#traffic-share {balanced min} ” If multiple minimum-cost paths exist and traffic-share min is configured, IGRP uses equal-cost load balancing. By default, the command is set to balanced, where traffic is distributed proportionally to the ratio of the metrics. For example, if the variance is set to 3 and traffic-share is set to balanced, the best route transports traffic three times that of the worst route.

• Router(config-router)#bandwidth xx-kbps ” This command configures bandwidth that IGRP uses in route decisions.

For a route to be included in unequal-cost load sharing, three other conditions must be met:

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

• The downstream router must be metrically closer to the destination.

• The metric of the lowest-cost route, multiplied by the variance, must be greater than the metric of the route to be added to the load-sharing group.

Configuring IGRP Unequal-Cost Load Sharing

In the network model in Figure 10-2, there are two routers: klipsch and carver. The routers are connected by two serial links: One link is running at 56 kbps, and the other is running at T1 speeds. The routers are both running IGRP in the private autonomous system of 65,001. In this model, you want to enable unequal-cost load balancing across the serial links.

Figure 10-2. IGRP with Unequal Metric Calculation

The first step, after configuring basic IGRP, is to set the bandwidth on the serial interfaces. If IGRP is enabled without tuning the bandwidth, the routers get an inconsistent view of the metrics of the network. In Example 10-6, the klipsch router has calculated a composite metric of 180,671 for the subnet 172.16.1.0 from the Serial 1 interface. On the other hand, the router has calculated a metric of 8576 for the same route from the Serial 0 interface.

How IGRP calculates the metrics for each route can be displayed by the debug ip igrp transactions command, as shown in Example 10-6.

Example 10-6 Metric of the 172.16.1.0 Route on klipsch

 klipsch#  debug ip igrp transactions  IGRP protocol debugging is on klipsch# 00:50:05: IGRP: received update from 172.16.11.4 on Serial0 00:50:05:       subnet 172.16.10.0, metric 182571 (neighbor 180571)  00:50:05:       subnet 172.16.1.0, metric 8576 (neighbor 1100)  00:50:05: IGRP: received update from 172.16.10.4 on Serial1 00:50:05:       subnet 172.16.11.0, metric 182571 (neighbor 8476)  00:50:05:       subnet 172.16.1.0, metric 180671 (neighbor 1100)  00:50:05:       subnet 172.16.100.0, metric 182671 (neighbor 8576) klipsch# 

Example 10-7 illustrates how, without setting the bandwidth on both sides of the serial links, the routers might have different perspectives on the link.

Example 10-7 Metric of 192.168.1.0 Route of carver

 carver#  debug ip igrp transactions  IGRP protocol debugging is on 03:12:26: IGRP: received update from 172.16.11.1 on Serial1 03:12:26:       subnet 172.16.10.0, metric 10476 (neighbor 8476)  03:12:26:       network 192.168.1.0, metric 8576 (neighbor 1100)  03:12:26: IGRP: received update from 172.16.10.1 on Serial7  03:12:26:       subnet 172.16.11.0, metric 90956 (neighbor 8476)  03:12:26:       network 192.168.1.0, metric 89056 (neighbor 1100) carver# 

To assist in synchronizing the metrics, assign the bandwidth statement to the two serial interfaces. Once again, this is done with the bandwidth kbps interface command. After applying the bandwidth command, the metrics are consistent throughout the network, as shown in Example 10-8.

Example 10-8 debug ip igrp transactions Command Output on the klipsch and carver Routers

 klipsch# 03:54:18: IGRP: received update from 172.16.11.4 on Serial0 03:54:18:       subnet 172.16.10.0, metric 182571 (neighbor 180571)  03:54:18:       subnet 172.16.1.0, metric 8576 (neighbor 1100)  03:54:19: IGRP: received update from 172.16.10.4 on Serial1 03:54:19:       subnet 172.16.11.0, metric 182571 (neighbor 8476)  03:54:19:       subnet 172.16.1.0, metric 180671 (neighbor 1100)  03:54:19:       network 192.168.1.0, metric 182671 (neighbor 8576) ______________________________________________________________ carver# 03:49:31: IGRP: received update from 172.16.11.1 on Serial1 03:49:31:       subnet 172.16.10.0, metric 182571 (neighbor 180571)  03:49:31:       network 192.168.1.0, metric 8576 (neighbor 1100)  03:49:31: IGRP: received update from 172.16.10.1 on Serial7 03:49:31:       subnet 172.16.11.0, metric 182571 (neighbor 8476) 03:49:31:       subnet 172.16.1.0, metric 182671 (neighbor 8576)  03:49:31:       network 192.168.1.0, metric 180671 (neighbor 1100)  carver# carver# 

The routing table is now consistent and all traffic flows through the lowest-cost path. Notice in Figure 10-3 that the routing table for the klipsch router now reports only the lowest-cost path to the network 172.16.1.0.

Figure 10-3. IGRP with Equal Metric Calculation

The final step is to set the variance. Recall that the formula to calculate variance is as follows :

Therefore, in this example, you have 1 + (180671/8576) = 22. After the variance is set, the router reports two paths to the destination network and load-share over them. The load sharing is in an inverse proportion to the variance setting. In this model, every 22nd packet crosses the lowest-cost path.

Finally, Example 10-9 lists the route table on the carver and klipsch routers when unequal-cost load balancing is in effect. Notice that all possible paths to the destination networks are listed.

Example 10-9 show ip route Command Output Lists All Possible Paths to Remote Networks

  I    192.168.1.0/24 [100/8576] via 172.16.11.1, 00:01:09, Serial1   [100/180671] via 172.16.10.1, 00:01:10, Serial7  172.16.0.0/24 is subnetted, 3 subnets C       172.16.10.0 is directly connected, Serial7 C       172.16.11.0 is directly connected, Serial1 C       172.16.1.0 is directly connected, Ethernet0 carver# ______________________________________________________________      172.16.0.0/24 is subnetted, 3 subnets C       172.16.10.0 is directly connected, Serial1 C       172.16.11.0 is directly connected, Serial0  I       172.16.1.0 [100/8576] via 172.16.11.4, 00:00:20, Serial0   [100/180671] via 172.16.10.4, 00:00:20, Serial1  C    192.168.1.0/24 is directly connected, Ethernet5 klipsch# 

Example 10-10 lists the configuration of the carver and klipsch routers.

Example 10-10 Relevant Portions of the carver and klipsch Router Configurations

  hostname carver   !   interface Ethernet0   ip address 172.16.1.1 255.255.255.0   !   interface Serial1   ip address 172.16.11.4 255.255.255.0   bandwidth 1544   clockrate 2000000   !   interface Serial7   ip address 172.16.10.4 255.255.255.0   bandwidth 56   clockrate 56000   !   router igrp 65001   variance 22   network 172.16.0.0   !   ip classless  ______________________________________________________________  hostname klipsch   !   interface Ethernet5   ip address 192.168.1.1 255.255.255.0   media-type 10BaseT   !   interface Serial0   ip address 172.16.11.1 255.255.255.0   no ip mroute-cache   bandwidth 1544   !   interface Serial1   ip address 172.16.10.1 255.255.255.0   bandwidth 56   !   router igrp 65001   variance 22   network 172.16.0.0   network 192.168.1.0   !   ip classless  

IGRP and EIGRP Integration and Migration

Migration from IGRP to EIGRP was designed to be an effortless migration. For the most part, this is true. If IGRP and EIGRP use the same Autonomous System IDs, redistribution occurs automatically. This facilitates a rather painless migration from IGRP to EIGRP. If the routing processes are in different autonomous systems, manual redistribution must be configured.

IGRP is also a classful routing protocol, which means that routing updates in the same major class or bit boundary as the interface receiving the update must have a subnet mask that matches the mask of the interface receiving the update. If the update is in a different class, it automatically is summarized at that class's major bit boundary, 8-bit, 16-bit, or 24-bit. Therefore, care must be taken to use summarization so that all the networks are at the same bit boundary throughout the portion of the network that supports only classful routing.

Expanding upon the model from the previous example, a new router has been added to the internetwork and some other subnet changes have been made, as illustrated in Figure 10-4. There now exists an EIGRP domain in the model. A router called dts is connected by a T1 serial link to the carver router.

Figure 10-4. IGRP and EIGRP Integration

To integrate the dts router to the network, manual redistribution is necessary. This is because the network resides in different autonomous systems. Example 10-11 highlights the IGRP and EIGRP redistribution on the carver router. The passive-interface commands are not necessary but are configured to prevent unnecessary EIGRP hellos and IGRP broadcast from entering networks that they shouldn't.

Example 10-11 IGRP and EIGRP Redistribution on the carver Router

  !   router eigrp 2001    redistribute igrp 65001   Redistribute IGRP into EIGRP    passive-interface Ethernet0   do not send EIGRP hellos on these interfaces   passive-interface Serial1   network 172.16.0.0    default-metric 1544 100 254 1 1500   Use this metric for redistributed routes   no auto-summary   !   router igrp 65001    redistribute eigrp 2001   Redistribute EIGRP into IGRP   passive-interface Serial0   network 172.16.0.0    default-metric 1544 100 254 1 1500   Default metric for redistributed routes   !  

The link between the carver and dts routers is on a 30-bit boundary. IGRP is not capable of advertising this network after it is redistributed because the subnet mask does not match the subnet mask on the advertising interface. To remedy this, summarize the 172.16.128.0/30 network to 172.16.128.0/24 by using the ip summary-address eigrp 2001 172.16.128.0 255.255.255.0 command under the Serial 0 interface of the carver router.

Downstream routers, such as klipsch, now have IP reachability to the subnet 172.16.128.0/24. Example 10-12 lists the route table of the klipsch router.

Example 10-12 Route Table of the klipsch Router

 klipsch#  show ip route  <<<text omitted>>> Gateway of last resort is not set      172.16.0.0/24 is subnetted, 3 subnets I       172.16.128.0 [100/10476] via 172.16.11.4, 00:00:31, Serial0 C       172.16.11.0 is directly connected, Serial0 I       172.16.1.0 [100/8576] via 172.16.11.4, 00:00:31, Serial0 klipsch# 

IGRP and Default Routing

A default route is necessary whenever connecting to the Internet because, without it, the router would need a path to every single network in its routing table. Fundamentally, a default route points to a gateway of last resort. When a router cannot find a specific match in its route table for a packet, it forwards that packet to the gateway of last resort. Cisco routers always perform a classful route lookup, which means that they do not forward packets to a gateway of last resort unless the global ip classless command is set. ip classless is enabled by default in Cisco IOS Software Release 11.3 and later.

The concept of default routing varies by each routing protocol. Each routing protocol uses a specific method when defining and advertising a default route.

The two steps to perform when configuring default routing with IGRP follow:

Step 1. Define a default network. IGRP does not recognize the address of 0.0.0.0 as a default route. Recall that the IGRP actually advertises a route as an external network. To "flag" or define a network as external, two things must happen. First, the route must be flagged by the ip default-network a.b.c.d command. Second, for the route to be advertised as external, the interface advertising the route must not be in the same major class boundary as the default network.

Step 2. Ensure that IP classless is enabled on the router.

In Figure 10-5, igrp_rtr has a default network of 206.191.241.40/29. The ip default-network 206.191.241.0 command has been added to the configuration. This causes the route to be flagged as a default and as an external network. The route table for the igrp_rtr router marks this route with an *, meaning that the route is the candidate default. When the route is propagated to a downstream router, it becomes a gateway of last resort, as shown in Figure 10-5.

Figure 10-5. IGRP Default Network

Example 10-13 lists the configuration of the igrp_rtr router.

Example 10-13 Relevant Portions of the igrp_rtr Configuration

  router igrp 2001   network 172.16.0.0   network 206.191.241.0   !   ip classless   ip default-network 206.191.241.0   !