9

„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.

386

Nokia Network Voyager for IPSO 4.0 Reference Guide

Page 386
Image 386
Nokia IPSO 4.0 manual 386