IGRP (Interior Gateway Routing Protocol)

IGRP is a Cisco proprietary routing protocol that uses a distance-vector algorithm because it uses a vector (a one-dimensional array) of information to calculate the best path. This vector consists of four elements:

• Bandwidth

• Delay

• Load

• Reliability

MTU (maximum transfer unit) information is included in the final route information, but it’s used as part of the vector of metrics. Each of these elements will be described in detail later. Remember that only bandwidth and delay are used to create a link metric. Load, reliability, MTU, and hop count can be configured through configuration, but that is not typical.

IGRP is intended to replace RIP and create a stable, quickly converging protocol that would scale with increased network growth. As mentioned earlier, it’s preferable to implement a link-state protocol in large networks because of the overhead and delay that results from using a distance-vector protocol.

IGRP Features

IGRP has several features included in its algorithm. Table 8.2 lists these features and a brief description of each. These features were added to make IGRP more stable, and a few were created to deal with routing updates and make network convergence happen faster.

Table 8.2: IGRP Features

Feature	Description
Configurable metrics	Metrics involved in the algorithm responsible for calculating route infor mation may be configured by the user.
Flash update	Updates are sent out prior to the default time setting. This occurs when the met rics for a route change.
Poison reverse updates	Implemented to prevent routing loops. These updates place a route in hold-down.
Unequal-cost load balancing	Allows packets to be shared/distributed across multiple paths.

IGRP Timers

To control performance, IGRP includes timers with default settings for each of the following:

Update timers Update timers specify how frequently routing update messages should be sent. The default is 90 seconds.

Invalid timers Invalid timers specify how long a router should wait before declaring a route invalid because it didn’t receive a specific update about it. The default is three times the update period.

Hold-down timers Hold-down timers specify the hold-down period. The default is three times the update timer period, plus 10 seconds.

Flush timers Flush timers indicate how much time should pass before a route should be flushed from the route table. The default is seven times the routing update period. After both the invalid timer and flush timer expire, IGRP will then flush the invalid route from the table.

IGRP Routes

IGRP is a classfull protocol, which means it doesn’t include any subnet information about the network with route information. Three types of routes are recognized by IGRP:

Interior routes Interior routes are networks directly connected to a router interface.

System routes System routes are advertised by other IGRP neighbors within the same AS (autonomous system). The AS number identifies the IGRP session, because it’s possible for a router to have multiple IGRP sessions.

Exterior routes Exterior routes are learned via IGRP from a different AS number, which provide information used by the router to set the gateway of last resort. The gateway of last resort is the path a packet will take if a specific route isn’t found on the router.

To really understand how IGRP routes, it’s important to understand the difference between these route types, which are illustrated in Figure 8.3.

Figure 8.3: Route types recognized by IGRP

The discussion of the scalability of distance-vector protocols told you that they don’t establish a formal neighbor relationship with directly connected routers and that routing updates are sent at designated intervals. IGRP’s interval is 90 seconds, which means that every 90 seconds IGRP will broadcast its entire route table to all directly connected IGRP neighbors.

Figure 8.4 portrays how IGRP routing updates work. It depicts three routers, all within the same AS. On the left-hand side of the figure, the relative times (in seconds) for each of the routers are listed. Notice that they’re not the actual clock times. The first line shows Routers A and C sending their route tables to Router B. Router B timestamps the routing updates from both routers and will expect to receive updates from them every 90 seconds thereafter. At the next time increment (30 seconds later), Router B broadcasts its route table to both Routers A and C, which they in turn timestamp. They will also expect to receive an update from Router B every 90 seconds based on that time stamp.

Figure 8.4: IGRP route update process

Once the timers for Routers A and C reach 90 seconds, they broadcast their route tables to Router B. Router B then resets its receive timer and expects to receive route updates within 90 seconds. Router B’s transmit timer continues to count to 90 seconds and broadcasts the route table when that period elapses. Notice that Router C received an update, but Router A didn’t. Because of that, Router C resets its receive timer, but Router A’s timer continues to count.

Another 90 seconds elapse, so Router B sends out another update. Again, only Router C receives it. Router A’s clock is now at 180 seconds because it hasn’t yet received an update.

Finally, an additional 90 seconds passes when Router B broadcasts the route table, and again Router C receives the broadcast and resets its receive timer. However, for the third time, Router A doesn’t receive the update, so the algorithm flags the next-hop Router B as unreachable and assigns it a higher metric. After Router A recalculates a new table, it will send out flash updates to all other routers connected to Router A, notifying them that Router B is unreachable.

The total time that passed between the first update received from Router B and the point that Router A flagged Router B as unreachable was 270 seconds. Three consecutive failures to receive an update from a directly connected router are required for IGRP to consider a neighbor unreachable and assign it a new metric. After seven failures, any routes associated with Router B will be removed from the table and no longer advertised.

Note

More than one route can be associated with a next-hop router, so once it’s been determined that a next-hop router is down, a router will remove all associated routes from its route table.

Preventing Routing Loops

Two methods are used to prevent routing loops with IGRP:

• Split horizon

• Poison reverse updates

With split horizon, route information learned from a given interface isn’t sent back out the same interface. Using Figure 8.5 as a reference, we’ll explain split horizon updates.

Router D advertises network 10.2.1.0/24 to Routers A and B. After Router B receives the update and recalculates its own route table, a broadcast update is sent. However, specific route information learned from Router D isn’t advertised back to Router D.

Poison reverse updates use a function within IGRP called hold-down, which stops the router from being confused about multiple routes to a given network. If a router has a bunch of routers connected to it, it’s possible for it to receive duplicate route advertisements. Figure 8.5 shows a router that’s meshed with three other routers. Router A learns of network 10.2.1.0/24 from Routers C and D. If the Ethernet segment connected to Router D fails, Router D will advertise the change to Routers A and B. So Router A will receive information from Router D that network 10.2.1.0/24 is unreachable—a fact that increases its metrics. Router B must recalculate the route table before it can update Router C. At this point, Router A has a higher metric for the 10.2.1.0/24 network. Due to the change in the metric, the router will place the route in hold- down so that updates regarding the network are ignored unless they’re received from the router that advertised the increased metric. During hold-down, the network is advertised to other routers with the increased metric.

Figure 8.5: Split horizon

Tip

For a detailed explanation of IGRP configuration, see CCNP: Building Scalable Cisco Internetworks, also by Sybex.