Back
Home
IGRP
-
- Background
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.
IGRP Protocol Characteristics
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.
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.
Stability Features
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 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.
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.
Back
Home