9
386 Nokia Network Voyager for IPSO 4.0 Reference Guide
Request packet
Update packet
IGRP dynamically builds its routing table from information received in IGRP update messages.
On startup, IGRP issues a request on all IGRP-enabled interfaces. If a system is configured to
supply IGRP, it hears the request and responds with an update message based on the current
routing database.
IGRP processes update messages differently depending on whether or not holddowns are
enabled.
If all the following conditions are true, the route is deleted and put into a holddown:
Holddowns are enabled.
Route entry comes from the originator of the route.
Calculated composite metric is worse than composite metric of the existing route by more
than 10 percent.
During this holddown period, no other updates for that route are accepted from any source.
If all the following are true, the route is deleted (note that it does not enter a holddown period):
Holddowns are disabled.
Route entry comes from the originator of the route.
Hop count has increased.
Calculated composite metric is greater than the composite metric of the existing route.
In both cases, if a route is not in holddown and a route entry in an update message indicates it
has a better metric, the new route is adopted. In general, routing updates are issued every 90
seconds. If a router is not heard from for 270 seconds, all routes from that router are deleted from
the routing database. If holddowns are enabled and a route is deleted, the route remains in the
holddown for 280 seconds. If a router is not heard from for 630 seconds, all routes from that
router are no longer announced (that is, after the initial 270 seconds, such routes are advertised
as unreachable).
This implementation of IGRP does not support all of the features listed in the specification. The
following is a list of non-supported features:
Multiple type of service (TOS) routing
Variance factor set only to a value of one
Equal or roughly equal cost path splitting
This implementation has interoperated with other vendor’s implementations of IGRP, namely
Cisco IOS version 10.3(6) and 11.0(7). Listed here for completeness are a few minor observable
differences between the Nokia and the Cisco implementations (no interoperability problems
have occurred to date because to these differences):
Validity Checks—packets that are malformed (that is, those that have trailing data on a
request packet, have nonzero data in a field that must be zero, or have route counts in an
update packet that do not agree with the actual packet size) are rejected. Other
implementations allow such packets. You can disable some of these checks for request
packets, but not for the update packets.