Since IGRP is such a close cousin of RIP, we will not repeat the details of how DV algorithms work, how updates are sent, and how route convergence is achieved. However, because IGRP employs a much more comprehensive metric, I’ll discuss the IGRP metric in detail. I’ll begin this discussion with AS numbers.
Each IGRP process requires an autonomous system number:
router igrp autonomous-system-numberThe AS number allows the network administrator to define routing domains; routers within a domain exchange IGRP routing updates with each other but not with routers in different domains. Note that in the context of IGRP the terms “autonomous system number” and “process ID” are often used interchangeably. Since the IGRP autonomous system number is not advertised to other domains, network engineers often cook up arbitrary process IDs for their IGRP domains.
Let’s say that TraderMary created a subsidiary in Africa and that the new topology is as shown in Figure 3-2.
Note that IGRP is running in the U.S. and Africa with AS numbers of 10 and 20, respectively. The U.S. routers now exchange IGRP routes with each other, as before, and the routers Nairobi and Casablanca exchange IGRP updates with each other. IGRP updates are processed only between routers running the same AS number, so NewYork and Nairobi do not exchange IGRP updates with each other. We will see this in more detail later, when we look at the format of an IGRP update.
The advantage of creating small domains with unique AS numbers is
that a routing problem in one domain is not likely to ripple into
another domain running a different AS number. So, for example,
let’s say that a network engineer in Africa
configured network 172.16.50.0 on
Casablanca (172.16.50.0
already exists on Chicago). The U.S. network
would not be disrupted because of this duplicate address. In another
situation, an IGRP bug in IOS on Chicago could
disrupt routing in the U.S., but Nairobi and
Casablanca would not be affected by this problem
in the AS 10.
The problem with creating too many small domains running different
IGRP AS numbers is that sooner or later the domains will need to
exchange routes with each other. The office in New York would need to
send files to Nairobi. This could be accomplished by adding static
routes on NewYork (to
172.16.150.0) and Nairobi (to
172.16.1.0). However, static routes can be
cumbersome to install and administer and do not offer the redundancy
of dynamic routing protocols. Dynamic distribution of routes between
routing domains is discussed in Chapter 8.
In the meantime, all I will say is to use good judgment when breaking networks into autonomous systems. Making a routing domain too small will require extensive redistributions or the creation of static entries. Making a routing domain too big exposes the network to failures of the type just described.
The boundary between domains is often geographic or organizational.
The RIP metric was designed for small, homogenous networks. Paths were selected based on the number of hops to a destination; the lowest hop-count path was installed in the routing table. IGRP is designed for more complex networks. Cisco’s implementation of IGRP allows the network engineer to customize the metric based on bandwidth, delay, reliability, load, and MTU. In order to compare metrics between paths and select the least-cost path, IGRP converts bandwidth, delay, reliability, delay, and MTU into a scalar quantity -- a composite metric that expresses the desirability of a path. Just as in the case of RIP, a path with a lower composite metric is preferred to a path with a higher composite metric.
The computation of the IGRP composite metric is user-configurable; i.e., the network administrator can specify parameters in the formula used to convert bandwidth, delay, reliability, load, and MTU into a scalar quantity.
The following sections define bandwidth, delay, reliability, load, and MTU. We will then see how these variables can be used to compute the composite metric for a path.
The IGRP metric for a path is derived from the bandwidth, delay, reliability, load, and MTU values of every media in the path to the destination network.
The bandwidth, delay, reliability, load, and MTU values at any interface to a media can be seen as output of the show interface command:
router1#sh interface ethernet 0
Ethernet0 is up, line protocol is up
Hardware is AmdP2, address is 0010.7bcf.e340 (bia 0010.7bcf.e340)
Description: Lab Test
Internet address is 1.13.96.1/16
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
...The bandwidth, delay, reliability, load, and MTU for a media are defined as follows:
- Bandwidth
The bandwidth for a link represents how fast the physical media can transmit bits onto a wire. Thus, an HSSI link transmits approximately 45,000 kbits every second, Ethernet runs at 10,000 kbps, a T-1 link transmits 1,544 kbits every second, and a 56-kbps link transmits 56 kbits every second.
Ethernet0 on router1 is configured with a bandwidth of 10,000 kbps.
- Delay
The delay for a link represents the time to traverse the link in an unloaded network and includes the propagation time for the media. Ethernet has a delay value of 1 ms; a satellite link has a delay value in the neighborhood of 1 second.
Ethernet0 on router1 is configured with a delay of 1,000 ms.
- Reliability
Link reliability is dynamically measured by the router and is expressed as a numeral between 1 and 255. A reliability of 255 indicates a 100% reliable link.
Ethernet0 on router1 is 100% reliable.
- Load
Link utilization is dynamically measured by the router and is expressed as a numeral between 1 and 255. A load of 255 indicates 100% utilization.
Ethernet0 on router1 has a load of 1/255.
- MTU
The MTU, or Maximum Transmission Unit, represents the largest frame size the link can handle.
Ethernet0 on router1 has an MTU size of 1,500 bytes.
The MTU, bandwidth, and delay values are static parameters that Cisco routers derive from the media type. Table 3-1 shows some common values for bandwidth and delay. These default values can be modified using the commands shown in the next section.
Table 3-1. Default bandwidth and delay values
|
Media type |
Default bandwidth |
Default delay |
|---|---|---|
|
Ethernet |
10 Mbps |
1,000 ms |
|
Fast Ethernet |
100 Mbps |
100 ms |
|
FDDI |
100 Mbps |
100 ms |
|
T-1 (serial interface)[a] |
1,544 kbps |
20,000 ms |
|
56 kbps (serial interface) |
1,544 kbps |
20,000 ms |
|
HSSI |
45,045 kbps |
20,000 ms |
[a] All serial interfaces on Cisco routers are configured with the same default bandwidth (1,544 kbits/s) and delay (20,000 ms) parameters. | ||
The reliability and load values are dynamically computed by the router as five-minute exponentially weighted averages.
The default bandwidth and delay values may be overridden by the following interface commands:
bandwidthkilobitsdelaytens-of-microseconds
So, the following commands will define a bandwidth of 56,000 bps and a delay of 10,000 ms on interface Serial0:
interface Serial0 bandwidth 56 delay 1000
These settings affect only IGRP routing parameters. The actual physical characteristics of the interface -- the clock-rate on the wire and the media delay -- have no relationship to the bandwidth or delay values configured as in this example or seen as output of the show interface command. Thus, interface Serial0 in the previous example may actually be clocking data at 128,000 bps, a rate that will be governed by the configuration of the modem or the CSU/DSU attached to Serial0. Note that, by default, Cisco sets the bandwidth and delay on all serial interfaces to be 1,544 kbps and 20,000 ms, respectively (see Table 3-1).
Note that delay on an interface is specified in tens of microseconds. Thus:
delay 1000
describes a delay of 10,000 ms.
The MTU on an interface can be modified using the following command:
mtu bytesHowever, the MTU size has no bearing on IGRP route selection. The MTU size should not be modified to affect routing behavior. The default MTU values represent the maximum allowed for the media type; lowering the MTU size can impair performance by causing needless fragmentation of IP datagrams.
Later in this chapter we will see how modifications to the bandwidth and delay parameters on an interface can affect route selection.
IGRP updates are directly encapsulated in IP with the protocol field (in the IP header) set to 9. The format of an IGRP packet is shown in Figure 3-3.
Just like RIP, IGRP allows a station to request routes. This allows a router that has just booted up to request the routing table from its neighbors instead of waiting for the next cycle of updates, which could be as much as 90 seconds later for IGRP.
The destination IP address in IGRP updates is
255.255.255.255. The source IP address is the IP
address of the interface from which the update is issued.
Each update packet contains three types of routes:
- Interior routes
Contain subnet information for the major network number associated with the address of the interface to which the update is being sent. If the IGRP update is being sent on a broadcast network, the internal routes are subnet numbers from the same major network number that is configured in the broadcast media.
- System routes
Contain major network numbers that may have been summarized when a network-number boundary was crossed.
- Exterior routes
Represent candidates for the default route. Unlike RIP, which uses
0.0.0.0to represent the default, IGRP uses specific network numbers as candidates for the default by tagging the routes as exterior.
Interior, system, and exterior routes appear in order in each update packet. The count of interior, system, and exterior routes identifies the route type for each route entry.
Note that the IGRP update has only three octets for the destination network-number field, whereas IP addresses are four octets in length. IGRP extracts the four-octet IP address using the heuristic shown in Table 3-2.
Table 3-2. Deriving the four-octet IP destination address from the three-octet destination field
|
Route type |
Heuristic to derive four-octet IP destination address |
|---|---|
|
Interior route |
The first octet is derived from the IP address of the interface that received the update; the last three octets are derived from the IGRP update. |
|
System route |
The route is assumed to have been summarized. The last octet of the IP destination address is 0. |
|
Exterior route (default route) |
The route is assumed to have been summarized. The last octet of the IP destination address is 0. |
Just like RIP, IGRP updates do not contain subnet mask information. This classifies both RIP and IGRP as classful routing protocols. Subnet mask information for routes received in IGRP updates is derived using the same rules as in RIP.
When an update is received for a route, it contains the bandwidth, delay, reliability, load, and MTU values for the path to the destination network via the source of the update. I already defined bandwidth, delay, reliability, load, and MTU for an interface. Now let’s define these parameters again for a path.
The following list defines bandwidth, delay, reliability, load, and MTU for a path:
- Bandwidth
The bandwidth for a path is the minimum bandwidth in the path to the destination network. Compare a network to a sequence of pipes for the transmission of a fluid; the slowest pipe (or the thinnest pipe) will dictate the rate of flow of the fluid. Thus, if a path to a network is through an Ethernet segment, a T-1 line, and another Ethernet segment, the path bandwidth will be 1,544 kbps (see Table 3-1).
- Delay
The delay for a path is the sum of all delay values on the path to the destination network. The IGRP unit of delay is in tens of microseconds. A path through a network via an Ethernet segment, a T-1 line, and another Ethernet segment will have a path delay of 22,000 ms or 2,200 IGRP delay units (see Table 3-1).
The IGRP update packet has three octets to represent delay (in units of tens of microseconds). The largest value of delay that can be represented is 224 x 10 ms, which is roughly 167.7 seconds. 167.7 seconds is thus the maximum possible delay value for an IGRP network. All ones in the delay field are also used to indicate that the network indicated is unreachable.
- Reliability
The reliability for a path is the reliability of the least reliable link in the path.
- Load
The load for a path is the load on the most heavily loaded link in the path.
- MTU
The MTU represents the smallest MTU along the path. MTU is currently not used in computing the metric.
Note that, in addition to these parameters, the update packet includes the hop count to the destination. The default maximum hop count for IGRP is 100. This default can be modified with the command:
metric maximum-hops hopsThe maximum value for hops is 255. A network with a diameter over 100 is very large indeed, especially for a network running IGRP. Do not expect to modify the maximum hop count for IGRP, even if you are working for an interstellar ISP. Large networks will usually require routing features that do not exist in IGRP.
The bandwidth, delay, reliability, load, and MTU values for the path selected by a router can be seen as output of the show ip route command:
NewYork#show ip route 172.16.100.0
Routing entry for 172.16.100.0 255.255.255.0
Known via "igrp 10", distance 100, metric 8576
Redistributing via igrp 10
Advertised by igrp 10 (self originated)
Last update from 172.16.251.2 on Serial1, 00:00:29 ago
Routing Descriptor Blocks:
* 172.16.251.2, from 172.16.251.2, 00:00:29 ago, via Serial1
Route metric is 8576, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2The path metric of bandwidth, delay, reliability, load, and MTU needs to be expressed as a composite metric for you to be able to compare paths. The default behavior of Cisco routers considers only bandwidth and delay in computing the composite metric (the parameters reliability, load, and MTU are ignored):
Metric = BandW + Delay
BandW is computed by taking the smallest bandwidth (expressed in kbits/s) from all outgoing[2] interfaces to the destination (including the destination) and dividing 10,000,000 by this number (the smallest bandwidth). For example, if the path from a router to a destination Ethernet segment is via a T-1 link, then:
BandW = 10,000,000/1,544 = 6,476
Delay is computed by adding the delays from all outgoing interfaces to the destination (including the delay on the interface connecting to the destination network) and dividing by 10:
Delay = (20,000 + 1,000)/10 = 2,100
And then the composite metric for the path to the Ethernet segment would be:
Metric = BandW + Delay = 1,000 + 2,100 = 3,100
Let’s now go back to TraderMary’s network to see why router NewYork selected the direct 56-kbps link to route to 172.16.100.0 and not the two-hop T-1 path via Chicago:
NewYork>sh ip route
...
I 172.16.100.0 [100/8576] via 172.16.251.2, 0:00:31, Serial0
...The values of the IGRP metrics for these paths can be seen here:
Ames#sh interface Ethernet 0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 00e0.b056.1b8e (bia 00e0.b056.1b8e)
Description: Lab Test
Internet address is 172.16.100.1/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
...
NewYork# show interfaces serial 0
Serial 0 is up, line protocol is up
Hardware is MCI Serial
Internet address is 172.16.250.1, subnet mask is 255.255.255.0
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
...There are two paths to consider:
NewYork → Ames →
172.16.100.0.Bandwidth values in the path: (serial link) 1,544 kbits/s, (Ethernet segment) 10,000 kbits/s
Delay values in the path: (serial link) 2,000, (Ethernet segment) 100
Smallest bandwidth in the path: 1,544
BandW = 10,000,000/1,544 = 6,476 Delay = 2,000 + 100 = 2,100 Metric = BandW + Delay = 8,576 NewYork → Chicago → Ames to
172.16.100.0.Bandwidth values in the path: (serial link) 1,544 kbits/s, (serial link) 1,544 kbits/s, (Ethernet segment) 10,000 kbits/s
Delay values in the path: (serial link) 2,000, (serial link) 2,000, (Ethernet segment) 100
Smallest bandwidth in the path: 1,544
BandW = 10,000,000/56 = 6,476 Delay = 2,000 + 2,000 + 100 = 4,100 Metric = BandW + Delay = 10,576
NewYork will prefer to route via the first path because the metric is smaller. Why does NewYork use a bandwidth of 1,544 for the 56-kbps link to Ames? Go back to Table 3-1 and you will see that the default bandwidth and delay values of 1,544 kbps and 20,000 ms apply to all serial interfaces, regardless of the speed of the modem device attached to the router port.
The IGRP metric can be customized to use reliability and load with the following formula (Equation 1):
Metric = k1 x BandW + k2 x BandW/(256 - load) + k3 x Delay
where the default values of the constants are k1 = k3 = 1 and k2 = k4 = k5 = 0.
If k5 is not equal to zero, an additional operation is done:
Metric = Metric x [k5/(reliability + k4)]
The constants k1, k2, k3, k4, and k5 can be modified with the command:
metric weights tos k1 k2 k3 k4 k5
where tos identifies the type of service and must be set to zero (because only one type of service has been defined).
Plugging the default values of k1, k2, k3, k4, and k5 into Equation 1 yields:
Metric = BandW + Delay
which we saw earlier.
To make the metric sensitive to the network load (in addition to bandwidth and delay), set k1 = k2 = k3 = 1 and k4 = k5 = 0. This yields:
Metric = BandW + BandW/(256 - load) + Delay
The problem with using load in the metric computation is that it can make a route unstable. For example, a router may select a path through router P as its next hop to reach a destination. When the load on the path through P rises, in a few minutes (the value of load is computed as a five-minute exponentially weighted average) the metric for the path through P may become larger than the metric for an alternative path through router Q. The traffic then shifts to Q; this causes the load to increase on the path through Q and the path through P becomes more attractive. Thus, setting k2 = 1 can make a route unstable and cause traffic to bounce between two paths. Further, abrupt changes in metric cause flash updates; the route may also go into hold-down.
Instead of selecting the best path based on load, you may consider load balancing over several paths. Load balancing occurs automatically over equal-cost paths. If two or more paths have slightly different metrics, you may consider modifying the bandwidth and delay parameters to make the metrics equal and to utilize all the paths. See the example on modifying bandwidth and delay parameters in the next section.
To make the metric sensitive to network reliability (in addition to bandwidth and delay), set k1 = k3 = k5 =1 and k2 = k4 = 0. In the event of link errors, this will cause the metric on the path to increase, and IGRP will select an alternative path when the metric has worsened enough. A typical action in today’s networks is to turn a line down until the transmission problem is resolved, not to base routing decisions on how badly the line is running.
TraderMary’s network was still using the 56-kbps path between NewYork and Ames, even when IGRP was running on the routers (refer to Section 3.1). Why is it that NewYork and Ames did not pick up the lower bandwidth for the 56-kbps link?
Table 3-1 contains the key to our question. All serial interfaces on a Cisco router are configured with the same bandwidth (1,544 kbps) and delay (20,000 ms) values. Thus, IGRP sees the 56-kbps line with the same bandwidth and delay parameters as a T-1 line.
In order to utilize the 56-kbps link only as backup, we need to modify TraderMary’s network as follows:
hostname NewYork
...
interface Ethernet0
ip address 172.16.1.1 255.255.255.0
!
interface Ethernet1
ip address 192.168.1.1 255.255.255.0
!
interface Serial0
description New York to Chicago link
ip address 172.16.250.1 255.255.255.0
!
interface Serial1
description New York to Ames link
bandwidth 56
ip address 172.16.251.1 255.255.255.0
...
router igrp 10
network 172.16.0.0
hostname Chicago
...
interface Ethernet0
ip address 172.16.50.1 255.255.255.0
!
interface Serial0
description Chicago to New York link
ip address 172.16.250.2 255.255.255.0
!
interface Serial1
description Chicago to Ames link
ip address 172.16.252.1 255.255.255.0
...
router igrp 10
network 172.16.0.0
hostname Ames
...
interface Ethernet0
ip address 172.16.100.1 255.255.255.0
!
interface Serial0
description Ames to Chicago link
ip address 172.16.252.2 255.255.255.0
!
interface Serial1
description Ames to New York link
bandwidth 56
ip address 172.16.251.2 255.255.255.0
...
router igrp 10
network 172.16.0.0The new routing tables look like this:
NewYork#show ip route
...
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
172.16.0.0/24 is subnetted, 6 subnets
I 172.16.252.0 [100/10476] via 172.16.250.2, 00:00:43, Serial0
C 172.16.250.0 is directly connected, Serial0
C 172.16.251.0 is directly connected, Serial1
I 172.16.50.0 [100/8576] via 172.16.250.2, 00:00:43, Serial0
C 172.16.1.0 is directly connected, Ethernet0
I 172.16.100.0 [100/10576] via 172.16.250.2, 00:00:43, Serial0
C 192.168.1.0/24 is directly connected, Ethernet1
Chicago#sh ip route
...
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 6 subnets
C 172.16.252.0 is directly connected, Serial1
C 172.16.250.0 is directly connected, Serial0
I 172.16.251.0 [100/182571] via 172.16.250.1, 00:00:01, Serial0
[100/182571] via 172.16.252.2, 00:01:01, Serial1
C 172.16.50.0 is directly connected, Ethernet0
I 172.16.1.0 [100/8576] via 172.16.250.1, 00:00:01, Serial0
I 172.16.100.0 [100/8576] via 172.16.252.2, 00:01:01, Serial1
Ames#sh ip route
...
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 6 subnets
C 172.16.252.0 is directly connected, Serial0
I 172.16.250.0 [100/10476] via 172.16.252.1, 00:00:24, Serial0
C 172.16.251.0 is directly connected, Serial1
I 172.16.50.0 [100/8576] via 172.16.252.1, 00:00:24, Serial0
I 172.16.1.0 [100/10576] via 172.16.252.1, 00:00:24, Serial0
C 172.16.100.0 is directly connected, Ethernet0Let’s now go back to TraderMary’s
network and corroborate the metric values seen for
172.16.100.0 in router
NewYork’s routing table. The
following calculations show TraderMary’s network as
in Figure 3-1 but with IGRP bandwidth and delay
values for each interface. There are two paths to consider:
NewYork → Ames →
172.16.100.0.Bandwidth values in the path: (serial link) 56 kbits/s, (Ethernet segment) 10,000 kbits/s
Smallest bandwidth in the path: 56
BandW = 10,000,000/56 = 178,571 Delay = 2,000 + 100 = 2100 Metric = BandW + Delay = 180,671 NewYork → Chicago → Ames →
172.16.100.0Bandwidth values in the path: (serial link) 1,544 kbits/s, (serial link) 1,544 kbits/s, (Ethernet segment) 10,000 kbits/s
Smallest bandwidth in the path: 1,544
BandW = 10,000,000/1,544 = 6,476 Delay = 2,000 + 2,000 + 100 = 4,100 Metric = BandW + Delay = 10,576
Using the lower metric for the path via Chicago,
NewYork’s route to
172.16.100.0 shows as:
NewYork>sh ip route
...
I 172.16.50.0 [100/1] via 172.16.250.2, 0:00:31, Serial0
I 172.16.100.0 [100/10576] via 172.16.250.2, 0:00:31, Serial0
I 172.16.252.0 [100/1] via 172.16.250.2, 0:00:31, Serial0Let’s corroborate IGRP’s selection of the two-hop T-1 path in preference to the one-hop 56-kbps link by comparing the transmission delay for a 1,000-octet packet. A 1,000-octet packet will take 143 ms (1,000 x 8/56,000 second) over a 56-kbps link and 5 ms (1,000 x 8/1,544,000 second) over a T-1 link. Neglecting buffering and processing delays, two T-1 hops will cost 10 ms in comparison to 143 ms via the 56-kbps link.
The processing of IGRP updates is very similar to the processing of RIP updates, described in Chapter 2. The IGRP update comes with an autonomous system number. If this does not match the IGRP AS number configured on the router receiving the update, the entire upgrade is disregarded. Thus, routers NewYork and Nairobi in TraderMary’s network will receive updates from each other but will discard them.
Each network number received in the update is checked for validity.
Illegal network numbers such as 0.0.0.0/8,
127.0.0.0/8, and 128.0.0.0/16
are sometimes referred to as “Martian Network
Numbers” and will be disregarded when received in an
update (RFCs 1009, 1122).
The rules for processing IGRP updates are:
If the destination network number is unknown to the router, install the route using the source IP address of the update (provided the route is not indicated as unreachable).
If the destination network number is known to the router but the update contains a smaller metric, modify the routing table entry with the new next hop and metric.
If the destination network number is known to the router but the update contains a larger metric, ignore the update.
If the destination network number is known to the router and the update contains a higher metric that is from the same next hop as in the table, update the metric.
If the destination network number is known to the router and the update contains the same metric from a different next hop, install the route as long as the maximum number of paths to the same destination is not exceeded. These parallel paths are then used for load balancing. Note that the default maximum number of paths to a single destination is six in IOS Releases 11.0 or later.
For the routing table to be able to install multiple paths to the same destination, the IGRP metric for all the paths must be equal. The routing table will install several parallel paths to the same destination (the default maximum is six in current releases of IOS).
Load-sharing over parallel paths depends on the switching mode. If the router is configured for process switching , load balancing will be on a packet-by-packet basis. If the router is configured for fast switching, load balancing will be on a per-destination basis. For a more detailed discussion of switching mode and load balancing, see Chapter 2.
The default behavior of IGRP installs parallel routes to a destination only if all routes have identical metric values. Traffic to the destination is load-balanced over all installed routes, as described earlier.
Equal-cost load balancing works well almost all the time. However, consider TraderMary’s network again. Say that TraderMary adds a node in London. Since traffic to London is critical, the network is engineered with two links from New York: one running at 128 kbps and another running at 56 kbps. Figure 3-4 shows unequal-cost load balancing.
The routers are first configured as follows:
hostname NewYork ... interface Ethernet0 ip address 172.16.1.1 255.255.255.0 ! interface Ethernet1 ip address 192.168.1.1 255.255.255.0 ... interface Serial2 bandwidth 128 ip address 172.16.249.1 255.255.255.0 ! interface Serial3 bandwidth 56 ip address 172.16.248.1 255.255.255.0 ... router igrp 10 network 172.16.0.0 hostname London ... interface Ethernet0 ip address 172.16.180.1 255.255.255.0 ! interface Serial0 bandwidth 128 ip address 172.16.249.2 255.255.255.0 ! interface Serial1 bandwidth 56 ip address 172.16.284.2 255.255.255.0 ... router igrp 10 network 172.16.0.0
However, if you check NewYork’s routing table you will see that all traffic to London is being routed via the 128-kbps link:
NewYork>sh ip route ... 172.16.0.0/24 is subnetted, ... I 172.16.180.0 [100/80225] via 172.16.249.2, 00:01:07, Serial2 ...
This is because the NewYork → London metric is 80,225 via the 128-kbps path and 180,671 via the 56-kbps path.
The problem with this routing scenario is that the 56-kbps link is entirely unused, even when the 128-kbps link is congested. Overseas links are expensive: the network design ought to try to utilize all links. One way around this problem is to modify the IGRP parameters to make both links look equally attractive. This can be accomplished by modifying the 56-kbps path as follows:
hostname NewYork ... interface Serial3 bandwidth 128 ip address 172.16.248.1 255.255.255.0 ...
With this approach, both links would appear equally attractive. The routing table for NewYork will look like this:
NewYork>sh ip route
...
172.16.0.0/24 is subnetted, ...
I 172.16.180.0 [100/80225] via 172.16.249.2, 00:01:00, Serial2
[100/80225] via 172.16.248.2, 00:01:00, Serial3However, traffic will now be evenly distributed over the two links, which may congest the 56-kbps link while leaving the 128-kbps link underutilized.
Another solution is to modify IGRP’s default behavior and have it install unequal-cost links in its table, balancing traffic over the links in proportion to the metrics on the links. The variance that is permitted between the lowest and highest metrics is specified by an integer in the variance command. For example:
router igrp 10 network 172.16.0.0 variance 2
specifies that IGRP will install routes with different metrics as long as the largest metric is less than twice the lowest metric. In other words, if the variance is v, then:
highest metric ≥ lowest metric x v
The maximum number of routes that IGRP will install will still be four, by default. This maximum can be raised to six when running IOS 11.0 or later.
Going back to TraderMary’s network, the metric value for the 128-kbps path to London is 80,225 while the metric value for the 56-kbps path is 180,671. The ratio 180,671/80,225 is 2.25; hence, a variance of 3 will be adequate. NewYork may now be configured as follows:
hostname NewYork ... interface Ethernet0 ip address 172.16.1.1 255.255.255.0 ! interface Ethernet1 ip address 192.168.1.1 255.255.255.0 ... interface Serial2 bandwidth 128 ip address 172.16.249.1 255.255.255.0 ! interface Serial3 bandwidth 56 ip address 172.16.248.1 255.255.255.0 ... router igrp 10 network 172.16.0.0 variance 3
And the routing table for NewYork will look like this:
NewYork>sh ip route
...
172.16.0.0/24 is subnetted, ...
I 172.16.180.0 [100/80225] via 172.16.249.2, 00:01:00, Serial2
[100/180671] via 172.16.248.2, 00:01:00, Serial3Traffic from NewYork to London will be divided between Serial2 and Serial3 in the inverse ratio of their metrics: Serial2 will receive 2.25 times as much traffic as Serial3.
The default value of variance is 1. A danger with using a variance value of greater than 1 is the possibility of introducing a routing loop. Thus, NewYork may start routing to London via Chicago if the variance is made sufficiently large. IGRP checks that the paths it chooses to install are always downstream (toward the destination) by choosing only next hops with lower metrics to the destination.
It is important for you as the network administrator to be familiar with the state of the network during normal conditions. Deviations from this state will be your clue to troubleshooting the network during times of network outage. This output shows the values of the IGRP timers:
NewYork#sh ip protocol
Routing Protocol is "igrp 10"
Sending updates every 90 seconds, next due in 61 seconds
Invalid after 270 seconds, hold down 280, flushed after 630
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
IGRP maximum hopcount 100
IGRP maximum metric variance 1
Redistributing: igrp 10
Routing for Networks:
172.16.0.0
Routing Information Sources:
Gateway Distance Last Update
1 172.16.250.2 100 00:00:40
2 172.16.251.2 100 00:00:09
Distance: (default is 100)Note that IGRP updates are sent every 90 seconds and the next update is due in 61 seconds, which means that an update was issued about 29 seconds ago.
Further, lines 1 and 2 show the gateways from which router NewYork has been receiving updates. This list is valuable in troubleshooting -- missing routes from a routing table could be because the last update from a gateway was too long ago. Check the time of the last update to ensure that it is within the IGRP update timer:
NewYork#show ip route
...
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 6 subnets
I 172.16.252.0 [100/10476] via 172.16.251.2, 00:00:26, Serial1
[100/10476] via 172.16.250.2, 00:00:37, Serial0
C 172.16.250.0 is directly connected, Serial0
C 172.16.251.0 is directly connected, Serial1
I 172.16.50.0 [100/8576] via 172.16.250.2, 00:00:37, Serial0
C 172.16.1.0 is directly connected, Ethernet0
I 172.16.100.0 [100/8576] via 172.16.251.2, 00:00:26, Serial1
C 192.168.1.0/24 is directly connected, Ethernet1One key area to look at in the routing table is the timer values. The format that Cisco uses for timers is hh:mm:ss (hours:minutes:seconds). You would expect the time against each route to be between 00:00:00 (0 seconds) and 00:01:30 (90 seconds). If a route was received more than 90 seconds ago, that indicates a problem in the network. You should begin by checking to see if the next hop for the route is reachable.
You should also be familiar with the number of major network numbers (two in the previous output -- 172.16.0.0 and 192.168.1.0) and the number of subnets in each (six in 172.16.0.0 and one in 192.168.1.0). In most small to mid-sized networks, these counts will change only when networks are added or subtracted.
[2] The concept of an outgoing interface is best illustrated with an example. In TraderMary’s network, the outgoing interfaces from NewYork to 172.16.100.0 will be NewYork interface Serial0, Chicago interface Serial, and Ames interface Ethernet0. When computing the metric for NewYork to 172.16.100.0, we will use the IGRP parameters of bandwidth, delay, load, reliability, and MTU for these interfaces. We will not use the IGRP parameters from interfaces. However, unless they have been modified, the parameters on this second set of interfaces would be identical to the first.