The Interior Gateway
Routing Protocol (IGRP) is a routing protocol that
was developed in the mid-1980s by Cisco Systems, Inc.
Cisco's principal goal in creating IGRP was to provide a robust protocol
for routing within an autonomous system (AS).
In the mid-1980s, the most popular
intra-AS routing protocol was the Routing
Information Protocol (RIP).
Although RIP was quite useful for routing within small-to
moderate-sized, relatively homogeneous internetworks, its limits were
being pushed by network growth. In particular, RIP's small hop-count
limit (16) restricted the size of internetworks, and its single metric
(hop count) did not allow for much routing flexibility in complex
environments. The popularity of Cisco routers and the robustness of IGRP
have encouraged many organizations with large internetworks to replace
RIP with IGRP.
Cisco's initial IGRP implementation
worked in Internet Protocol (IP)
networks. IGRP was designed to run in any network environment, however,
and Cisco soon ported it to run in OSI Connectionless-Network
Protocol (CLNP) networks. Cisco developed
Enhanced IGRP in the early 1990s to improve the operating efficiency of
IGRP. This chapter discusses IGRP's basic design and implementation.
Enhanced IGRP is discussed in "Enhanced
IGRP."
IGRP is a
distance-vector
interior gateway protocol (IGP). Distance-vector routing
protocols call for each router to send all or a portion of its routing
table in a routing-update message at regular intervals to each of its
neighboring routers. As routing information proliferates through the
network, routers can calculate distances to all nodes within the
internetwork.
Distance-vector routing protocols are
often contrasted
with link-state routing protocols, which send local
connection information to all nodes in the internetwork. For a
discussion of Open Shortest Path First (OSPF) and Intermediate
System-to-Intermediate System (IS-IS), two popular link-state
routing algorithms, see "Open Shortest Path First (OSPF),"
and "Open System Interconnection (OSI) Protocols,"
respectively.
IGRP uses a combination (vector) of metrics.
Internetwork delay, bandwidth, reliability,
and load are all factored into the routing decision. Network
administrators can set the weighting factors for each of these metrics.
IGRP uses either the administrator-set or the default weightings to
automatically calculate optimal routes.
IGRP provides a wide range for its
metrics. Reliability and load, for example, can take on any value
between 1 and 255; bandwidth can take on values reflecting speeds from
1,200 bps to 10 gigabits per second, while delay can take on any value
from 1 to 2 to the 24th power. Wide metric ranges allow satisfactory
metric setting in internetworks with widely varying performance
characteristics. Most importantly, the metric components are combined in
a user-definable algorithm. As a result, network administrators can
influence route selection in an intuitive fashion.
To provide additional flexibility, IGRP
permits multipath
routing. Dual
equal-bandwidth lines can run a single stream of traffic in round-robin
fashion, with automatic switchover to the second line if one line goes
down. Also, multiple paths can be used even if the metrics for the paths
are different. If, for example, one path is three times better than
another because its metric is three times lower, the better path will be
used three times as often. Only routes with metrics that are within a
certain range of the best route are used as multiple paths.
IGRP provides a number of features that
are designed to enhance its stability. These include hold-downs,
split horizons,
and poison-reverse updates.
Hold-downs are used to
prevent regular update messages from inappropriately reinstating a route
that might have gone bad. When a router goes down, neighboring routers
detect this via the lack of regularly scheduled update messages. These
routers then calculate new routes and send routing update messages to
inform their neighbors of the route change. This activity begins a wave
of triggered updates that filter through the network. These triggered
updates do not instantly arrive at every network device, so it is
therefore possible for a device that has yet to be informed of a network
failure to send a regular update message (indicating that a route that
has just gone down is still good) to a device that has just been
notified of the network failure. In this case, the latter device would
contain (and potentially advertise) incorrect routing information.
Hold-downs tell routers to hold down any changes that might affect
routes for some period of time. The hold-down period usually is
calculated to be just greater than the period of time necessary to
update the entire network with a routing change.
Split horizons derive from the premise
that it is never useful to send information about a route back in the
direction from which it came. Figure
38-1 illustrates the split-horizon rule. Router 1 (R1) initially
advertises that it has a route to Network A. There is no reason for
Router 2 (R2) to include this route in its update back to R1 because R1
is closer to Network A. The split-horizon rule says that R2 should
strike this route from any updates it sends to R1. The split-horizon
rule helps prevent routing loops. Consider, for example, the case where
R1's interface to Network A goes down. to R1horizons, R2 continues to
inform R1 that it can get to Network A (through R1). If R1 does not have
sufficient intelligence, it actually might pick up R2's route as an
alternative to its failed direct connection, causing a routing loop.
Although hold-downs should prevent this, split horizons are implemented
in IGRP because they provide extra algorithm
stability.
Figure 38-1: The
split horizons rule helps protect against routing loops.
Split horizons should prevent routing
loops between adjacent routers, but poison-reverse updates are necessary
to defeat larger routing loops. Increases in routing metrics generally
indicate routing loops. Poison-reverse
updates then are sent to remove the route and place it in hold-down. In
Cisco's implementation of IGRP, poison-reverse updates are sent if a
route metric has increased by a factor of 1.1 or greater.
Timers
IGRP maintains a number of timers
and variables containing time intervals. These include an update
timer, an invalid timer, a hold-time
period, and a flush timer. The update timer specifies
how frequently routing update messages should be sent. The IGRP default
for this variable is 90 seconds. The invalid timer
specifies how long a router should wait, in the absence of
routing-update messages about a specific route before declaring that
route invalid. The IGRP default for this variable is three times the
update period. The hold-time variable specifies the
hold-down period. The IGRP default for this variable is three times the
update timer period plus 10 seconds. Finally, the flush
timer indicates how much time should pass before a route should be
flushed from the routing table. The IGRP default
is seven times the routing update period.
Get
this document in PDF form
|
