The Roots of EIGRP: An Overview of IGRP


Cisco developed IGRP in the mid-1980s as an answer to the limitations of RIP, the most significant of which are the hop count metric and the 15-hop network size. IGRP calculated a composite metric from a variety of route variables and provided "knobs" for weighting the variables to reflect the specific characteristics and needs of the network. Although hop count is not one of these variables, IGRP did track hop count, and could be implemented on networks of up to 255 hops in diameter.

The other advantages that IGRP presented over RIP are

  • Unequal-cost load sharing

  • An update period three times longer than RIP's

  • A more efficient update packet format

The chief disadvantage of both IGRP and EIGRP is that they are proprietary to Cisco and therefore limited to Cisco products, whereas RIP is a part of any IP routing process on any platform.

The Cisco objective when developing IGRP was to create a versatile, robust protocol capable of being adapted to a variety of routed protocol suites. In addition to routing IP, IGRP could also route the ISO Connectionless Network Protocol (CLNP). This multiprotocol capability was also adapted in EIGRP, which can route not only IP but also IPX and AppleTalk.

From a high-altitude view, IGRP shares many operational characteristics with RIP. It is a classful distance vector protocol that periodically broadcasts its entire routing tablewith the exception of routes suppressed by split horizonto all its neighbors. Like RIP, IGRP broadcasts a request packet out all IGRP-enabled interfaces upon startup and performs a sanity check on received updates to verify that the source address of the packet belongs to the same subnet on which the update was received.[1] New update entries with reachable metrics are placed in the routing table, and an entry replaces an older entry to the same destination only if the metric is smaller. Split horizon with poisoned reverse, triggered updates, and holddown timers are used for stability; IGRP summarizes addresses at network boundaries.

[1] This sanity check can be disabled with the command no validate-update-source.

Unlike RIP, which is accessed via UDP, the IGRP process is accessed directly from the IP layer as protocol 9.

Process Domains

IGRP also uses the concept of process domains. By defining and tracking multiple process domains, you can isolate the communications within one domain from the communications within another domain. Traffic between the domains can then be closely regulated by redistribution (Chapter 11, "Route Redistribution") and route filtering (Chapter 13, "Route Filtering").

Figure 7-1 illustrates the contrast between process domains and routing domains. Here two autonomous systems (AS) are defined: AS 10 and AS 40. These systems are routing domainsa set of routers running one or more IGPs under a common administration. They communicate via an Exterior Gateway Protocol (in this case, Border Gateway Protocol, or BGP).

Figure 7-1. An autonomous system number may specify a routing domain, which is a group of routers running one or more IGP processes under a single administrative domain. Under IGRP, an autonomous system number may also specify a process domain, which is a group of routers sharing routing information by means of a single routing process.


Within AS 10 are two IGRP process domains: IGRP 20 and IGRP 30. Under IGRP, the 20 and 30 are defined as autonomous system numbers. In this context, the numbers serve to distinguish two routing processes within the same routing domain. IGRP 20 and IGRP 30 communicate via the single router connected to both domains. This router runs both IGRP processes and automatically redistributes between them.

Within its updates, IGRP classifies route entries into one of three categories: interior routes, system routes, and exterior routes.

An interior route is a path to a subnet of the network address of the data link on which the update is being broadcast. In other words, a subnet advertised as an interior route is "local" to the major network to which the advertising router and the receiving router are commonly connected.

A system route is a path to a network address, which has been summarized by a network boundary router.

An exterior route is a path to a network that has been flagged as a default network. A default network is an address to which a router will send any packet that cannot be matched to a more specific destination.[2] Default networks and their configuration are covered in Chapter 12, "Default Routes and On-Demand Routing."

[2] Classifying a default network as an external route is unique to IGRP and EIGRP. Open protocols such as RIP and OSPF advertise default networks with the address 0.0.0.0.

Figure 7-2 shows how IGRP uses these three categories. The routers LeHand and Tully are connected to subnet 192.168.2.64/26, so major network 192.168.2.0 is considered the "local" network shared by those two routers. LeHand is also attached to 192.168.2.192/26, which is another subnet of the network connecting the two routers. Therefore, LeHand advertises that subnet to Tully as an internal route.

Figure 7-2. LeHand advertises subnet 192.168.2.192/26 to Tully as an internal route. Network 192.168.3.0 is advertised to Tully as a system route, and 192.168.1.0 is advertised as an external route.


However, the local network for LeHand and Thompson is 192.168.3.0. LeHand is the boundary router between major networks 192.168.2.0 and 192.168.3.0, so 192.168.2.0 will be advertised to Thompson as a system route. Likewise, 192.168.3.0 is advertised to Tully as a system route.

192.168.1.0 is a network in another autonomous system, and LeHand has been configured to advertise that network address as a default route. 192.168.1.0 will therefore be advertised to both Thompson and Tully as an external route.

IGRP Timers and Stability Features

The IGRP update period is 90 seconds. A random jitter variable of up to 20 percent is subtracted from each update time to prevent update timer synchronization, so the time elapsed between individual updates will vary from 72 to 90 seconds.

When a route is first learned, the invalid timer for that route is set for 270 seconds, or three times the update period. The flush timer is set for 630 secondsseven times the update period. Each time an update is received for the route, these timers are reinitialized. If the invalid timer expires before an update is heard, the route is marked as unreachable. It will be held in the routing table and advertised as unreachable until the flush timer expires, at which time the route will be deleted from the table.

The 90-second timer used by IGRP, in comparison to the 30-second timer used by RIP, means that compared to RIP, IGRP uses less bandwidth for periodic updates. However, the trade-off is that in some cases IGRP might be slower to converge than RIP. For example, if a router goes offline, IGRP takes three times as long as RIP to detect the dead neighbor.

If a destination becomes unreachable or if the next-hop router increases the metric of a destination enough to cause a triggered update, the route will be placed in holddown for 280 seconds (three update periods plus 10 seconds). Until the holddown timer expires, no new information will be accepted about this destination. IGRP holddown may be disabled with the command no metric holddown. In loop-free topologies, where holddown has no real benefit, disabling the function can reduce reconvergence time.

The default timers can be changed with the following command:

timers basic update invalid holddown flush [sleeptime]

This command is also used to manipulate RIP timers with the exception of the sleeptime option. Sleeptime is a timer used to specify a period, in milliseconds, to delay a regular routing update after receiving a triggered update.

IGRP Metrics

One of the most significant changes from RIP that IGRP introduces, and which carries over into EIGRP, is the use of multiple metric parameters, based on link characteristics. It is useful to study how IGRP handles these metrics to understand how EIGRP handles its metrics.

The link characteristics from which IGRP calculates its composite metric are bandwidth, delay, load, and reliability. By default, IGRP chooses a route based on bandwidth and delay. If a data link is thought of as a pipe, then bandwidth is the width of the pipe and delay is the length of the pipe. In other words, bandwidth is a measure of the carrying capacity, and delay is a measure of the end-to-end travel time. Load and reliability are taken into consideration only if the router is configured to do so. IGRP also tracks the smallest Maximum Transmission Unit (MTU) along each route, although the MTU is not used in the composite metric calculation. The quantities associated with IGRP's composite metric on a specific interface can be observed with the show interfaces command (Example 7-1).

Example 7-1. The output of every show interface command includes metric statistics for the interface. This Ethernet interface shows MTU = 1500 bytes, bandwidth = 10 megabits per second, delay = 1000 microseconds, reliability = 100 percent, and load = 39 percent (minimum load).
Newfoundland#show interfaces ethernet 0 Ethernet0 is up, line protocol is up   Hardware is Lance, address is 0000.0c76.5b7c (bia 0000.0c76.5b7c)   Internet address is 10.2.1.2/24   MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation ARPA, loopback not set   Keepalive set (10 sec)   ARP type: ARPA, ARP Timeout 04:00:00   Last input 00:00:07, output 00:00:01, output hang never   Last clearing of "show interface" counters never   Queueing strategy: fifo   Output queue 0/40, 0 drops; input queue 0/75, 0 drops   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec      601753 packets input, 113607697 bytes, 0 no buffer      Received 601753 broadcasts, 0 runts, 0 giants, 0 throttles      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored      0 input packets with dribble condition detected      693494 packets output, 557731861 bytes, 0 underruns      0 output errors, 5 collisions, 13 interface resets      0 babbles, 0 late collision, 48 deferred      0 lost carrier, 0 no carrier      0 output buffer failures, 0 output buffers swapped out Newfoundland#

Bandwidth is expressed in units of kilobits per second. It is a static number used for metric calculation only and does not necessarily reflect the actual bandwidth of the linkthat is, bandwidth is not measured dynamically. For example, the default bandwidth of a serial interface is 1544, whether the interface is attached to a T1 or a 56K line. This bandwidth number may be changed from the default with the bandwidth command.

IGRP updates use a three-octet number, referred to in this book as BWIGRP, which is the inverse of the bandwidth scaled by a factor of 107. So if the bandwidth of an interface is 1544, then

BWIGRP = 107/1544 = 6476, or 0x00194C.

Delay, like bandwidth, is a static figure and is not measured dynamically. It is displayed by the show interface command as DLY, in units of microseconds. The default delay of an interface may be changed with the delay command, which specifies the delay in tens of microseconds. Example 7-2 shows the bandwidth and delay commands used to change the defaults of the interface of Example 7-1.

Example 7-2. The bandwidth and delay commands are used to change the metric defaults of the e0 interface. The new quantities can be seen in the output of the show interfaces command.
Newfoundland(config)#interface e0 Newfoundland(config-if)#bandwidth 75000 Newfoundland(config-if)#delay 5 Newfoundland(config-if)#^Z Newfoundland# %SYS-5-CONFIG_I: Configured from console by console Newfoundland#show interfaces ethernet0 Ethernet0 is up, line protocol is up   Hardware is Lance, address is 0000.0c76.5b7c (bia 0000.0c76.5b7c)   Internet address is 10.2.1.2/24   MTU 1500 bytes, BW 75000 Kbit, DLY 50 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation ARPA, loopback not set   Keepalive set (10 sec)   ARP type: ARPA, ARP Timeout 04:00:00   Last input 00:00:02, output 00:00:02, output hang never   Last clearing of "show interface" counters never   Queueing strategy: fifo   Output queue 0/40, 0 drops; input queue 0/75, 0 drops   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec      601888 packets input, 113637882 bytes, 0 no buffer      Received 601888 broadcasts, 0 runts, 0 giants, 0 throttles      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored      0 input packets with dribble condition detected      693646 packets output, 557884632 bytes, 0 underruns      0 output errors, 5 collisions, 13 interface resets      0 babbles, 0 late collision, 48 deferred      0 lost carrier, 0 no carrier      0 output buffer failures, 0 output buffers swapped out Newfoundland#

When carried in an IGRP update, delay is a three-octet number expressed in the same 10-microsecond units as specified by the delay command. To avoid confusion, this number will be referred to as DLYIGRP, to differentiate it from DLY, in microseconds, observed with show interface. For example, if DLY is 50, then

DLYIGRP = DLY/10 = 50/10 = 5, or 0x000005.

IGRP also uses delay to indicate an unreachable route by setting DLYIGRP = 0xFFFFFF. This number translates to approximately 167.8 seconds, so the maximum end-to-end delay of an IGRP route is 167 seconds.

Because IGRP uses bandwidth and delay as its default metrics, these quantities must be configured correctly and consistently on all interfaces of all IGRP routers.

Changing the bandwidth or delay of an interface should be done only for good reasons and only with a full understanding of the results of those changes. In most cases, it is best to leave the default values unchanged. A notable exception is serial interfaces. As noted earlier in this section, serial interfaces on Cisco routers have a default bandwidth of 1544 no matter what the bandwidth is of the connected link. The bandwidth command should be used to set the interface to the actual bandwidth of the serial link.

It is important to note that OSPF also uses the bandwidth statement to calculate its metric. Therefore, if IGRP (or EIGRP) metrics are to be manipulated in a network where OSPF is also running, use the delay to influence IGRP. Changing the bandwidth will affect both IGRP and OSPF.

Table 7-1 lists the bandwidths and delays for a few common interfaces. (The default bandwidth of a serial interface is always 1544; Table 7-1 shows the figures that would result from using the bandwidth command to reflect the actual connected bandwidth.)

Table 7-1. Common BWIGRP and DLYIGRP quantities.

Media

Bandwidth

BWIGRP

Delay

DLYIGRP

100M ATM

100000K

100

100mS

10

Fast Ethernet

100000K

100

100mS

10

FDDI

100000K

100

100mS

10

HSSI

45045K

222

20000mS

2000

16M Token Ring

16000K

625

630mS

63

Ethernet

10000K

1000

1000mS

100

T1

1544K

6476

20000mS

2000

DS0

64K

156250

20000mS

2000

56K

56K

178571

20000mS

2000

Tunnel

9K

1111111

500000mS

50000


Reliability is measured dynamically and is expressed as an eight-bit number, where 255 is a 100 percent reliable link and 1 is a minimally reliable link. In the output of show interface, reliability is shown as a fraction of 255, for example, 234/255 (see Example 7-3).

Example 7-3. This interface shows a reliability of 234/255, or 91.8 percent.
Casablanca#show interface ethernet0 Ethernet0 is up, line protocol is up   Hardware is Lance, address is 0000.0c76.5b7c (bia 0000.0c76.5b7c)   Internet address is 172.20.1.1 255.255.255.0   MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 234/255, load 1/255   Encapsulation ARPA, loopback not set, keepalive set (10 sec)   ARP type: ARPA, ARP Timeout 4:00:00   Last input 0:00:28, output 0:00:06, output hang never   Last clearing of "show interface" counters 0:06:05   Output queue 0/40, 0 drops; input queue 0/75, 0 drops   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec      22 packets input, 3758 bytes, 0 no buffer      Received 21 broadcasts, 0 runts, 0 giants      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort      0 input packets with dribble condition detected      125 packets output, 11254 bytes, 0 underruns      39 output errors, 694 collisions, 0 interface resets, 0 restarts      0 output buffer failures, 0 output buffers swapped out Casablanca#

Load, in an IGRP update, is an eight-bit number. Load is represented in the output of show interface as a fraction of 255, such as 40/255 (Example 7-4); 1 is a minimally loaded link, and 255 is a 100 percent loaded link.

Example 7-4. This interface shows a load of 40/255, or 15.7 percent.
Yalta#show interface serial 1 Serial1 is up, line protocol is up   Hardware is HD64570   Internet address is 172.20.20.2 255.255.255.0   MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec, rely 255/255, load 40/255   Encapsulation HDLC, loopback not set, keepalive set (10 sec)   Last input 0:00:08, output 0:00:00, output hang never   Last clearing of "show interface" counters 0:05:05   Output queue 0/40, 0 drops; input queue 0/75, 0 drops   5 minute input rate 10000 bits/sec, 1 packets/sec   5 minute output rate 9000 bits/sec, 1 packets/sec      456 packets input, 397463 bytes, 0 no buffer      Received 70 broadcasts, 0 runts, 0 giants      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort      428 packets output, 395862 bytes, 0 underruns      0 output errors, 0 collisions, 0 interface resets, 0 restarts      0 output buffer failures, 0 output buffers swapped out      0 carrier transitions      DCD=up DSR=up DTR=up RTS=up CTS=up

If reliability or load is to be used as a metric or as part of a composite metric, the algorithm for calculating the metric must not allow sudden changes in the error rate or channel occupancy to destabilize the network. As an example, if a "raw," or instantaneous, measure of load is used, a burst of heavy traffic could cause a route to go into holddown and an abrupt drop in traffic could trigger an update. To prevent frequent metric changes, reliability and load are calculated based on an exponentially weighted average with a five-minute time constant, which is updated every five seconds.

The composite metric for each IGRP route is calculated as


     metric = [k1*BWIGRP(min) + (k2* BWIGRP(min))/(256-LOAD) + k3*DLYIGRP(sum)]
     x [k5/(RELIABILITY + k4)],

where BWIGRP(min) is the minimum BWIGRP of all the outgoing interfaces along the route to the destination and DLYIGRP(sum) is the total DLYIGRP of the route.

The values k1 through k5 are configurable weights; their default values are k1=k3=1 and k2=k4=k5=0. These defaults can be changed with the command:[3]

[3] tos is a relic of the Cisco original intention to have IGRP do type of service routing; this plan was never adopted, and tos in this command is always set to zero.

metric weights tos k1 k2 k3 k4 k53

If k5 is set to zero, the [k5/(RELIABILITY+k4)] term is not used.

Given the default values for k1 through k5, the composite metric calculation used by IGRP reduces to the default metric:

metric = BWIGRP(min) + DLYIGRP(sum)

The network example in Figure 7-3 shows the bandwidths and delays configured on each interface and a forwarding database from one of the routers with the derived IGRP metrics.[4]

[4] Also notice the administrative distance, which is 100 for IGRP.

Figure 7-3. By default, the total delay is added to the minimum bandwidth to derive the IGRP metric.


The routing table itself shows only the derived metric, but the actual variables recorded by IGRP for each route can be seen by using the command show ip route address, as in Example 7-5. Here the minimum bandwidth on the route from Casablanca to subnet 172.20.40.0/24 is 512K, at Quebec. The total delay of the route is (1000 + 20000 + 20000 + 5000) = 46000 microseconds:

BWIGRP(min) = 107/512 = 19531

DLYIGRP(sum) = 46000/10 = 4600

metric = BWIGRP(min) + DLYIGRP(sum) = 19531 + 4600 = 24131

Example 7-5. The metric for the route from Casablanca to subnet 172.20.40.0 is calculated from the minimum bandwidth of 512K and the total delay of 46000 microseconds.
Casablanca#show ip route 172.20.40.0 Routing entry for 172.20.40.0 255.255.255.0   Known via "igrp 1", distance 100, metric 24131   Redistributing via igrp 1   Advertised by igrp 1 (self originated)   Last update from 172.20.1.2 on Ethernet0, 00:00:54 ago   Routing Descriptor Blocks:   * 172.20.1.2, from 172.20.1.2, 00:00:54 ago, via Ethernet0       Route metric is 24131, traffic share count is 1       Total delay is 46000 microseconds, minimum bandwidth is 512 Kbit       Reliability 255/255, minimum MTU 1500 bytes       Loading 1/255, Hops 2

Example 7-5 shows that IGRP also records the smallest MTU along the route in addition to the hop count. MTU is not used in the metric calculation. Hop count is the hop count reported by the next-hop router and is used only to limit the diameter of the network. By default, the maximum hop count is 100 and can be configured from 1 to 255 with the command metric maximum-hops. If the maximum hop count is exceeded, the route will be marked unreachable by setting the delay to 0xFFFFFF.

Note that all metrics are calculated from the outgoing interfaces along the route. For example, the metric for the route from Yalta to subnet 172.20.4.0/24 is different from the metric for the route from Casablanca to subnet 172.20.40.0/24. This is due to the differences in the configured bandwidth on the link between Yalta and Quebec and to the differences in the delay on the outgoing interfaces to the two destination subnets.




CCIE Professional Development Routing TCP/IP (Vol. 12005)
Routing TCP/IP, Volume 1 (2nd Edition)
ISBN: 1587052024
EAN: 2147483647
Year: 2005
Pages: 233

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net