IGRP and EIGRP | Teleinf Edu

Introduction: IGRP and EIGRP in Cisco routing

Network routing developed along two main lines: a simple distance-vector protocol based on information from neighbors, such as RIP, and a link-state protocol based on a topology view, such as OSPF. Open standards provided a common way for routers from different manufacturers to exchange information, but they involved specific trade-offs. Cisco Systems developed solutions tailored to its hardware and to routing decisions in large networks.

This led to the development of proprietary protocols. Such a protocol is designed and owned by one company and was historically used only on that company’s equipment. This limits interoperability, but gives the company freedom to develop features beyond the constraints of public standardization processes.

Cisco developed the Interior Gateway Routing Protocol (IGRP) to address RIP’s main problems, followed by its successor, the Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP retains IGRP’s composite metric and adds classless routing and the DUAL algorithm.

IGRP: Distance-vector routing and composite metric

Cisco designed and deployed the Interior Gateway Routing Protocol (IGRP) in the mid-1980s. It remained a distance-vector protocol: routers exchanged information about their distance to networks, as in RIP. The protocol addressed RIP’s main weaknesses.

Fixing RIP’s Flaws

IGRP was created to solve two key problems:

A simple metric: RIP’s sole reliance on hop count was its biggest flaw: a slow 56 kbps satellite link had the same value as a high-speed fiber link. IGRP introduced a path-quality measure that considered more than hop count.
Limited scale: RIP’s maximum hop count of 15 made it unsuitable for a network of moderate size. IGRP was designed for larger enterprise networks, with a higher default maximum hop count (100, configurable up to 255).

The IGRP composite metric

IGRP’s main extension was its composite metric. Instead of just counting routers, IGRP considered multiple path characteristics to calculate its cost. It took into account five vector metrics. Four could affect the cost through K coefficients, while MTU was tracked but not included in the formula:

Bandwidth (K1): The lowest bandwidth along the entire path, because the path is limited by its narrowest section.
Delay (K3): The cumulative delay, or latency, of all links in the path.
Load (K2): The utilization of the link, showing how busy it is.
Reliability (K4 and K5): A measure of successful packet delivery on the link, related to its error rate; K4 and K5 determine its contribution to the formula.
MTU: The Maximum Transmission Unit, or the largest packet size supported on the path. MTU is tracked but is not a component of the metric formula.

K coefficients allow bandwidth, delay, load, and reliability to be included in the calculation. The default configuration for IGRP and classic EIGRP uses only Bandwidth and Delay. The formula prefers paths with higher bandwidth and lower cumulative delay.

IGRP metric formula

\text{Metric} = \left[ K_1 \cdot \text{Bandwidth} + \frac{K_2 \cdot \text{Bandwidth}}{256 - \text{Load}} + K_3 \cdot \text{Delay} \right] \cdot \left[ \frac{K_5}{\text{Reliability} + K_4} \right]

The full expression also contains the $K_5$ factor. When $K_5=0$ , as in the default settings, the reliability quotient is defined as 1 and does not change the first bracket. By default, $K_1=1$ and $K_3=1$ , while $K_2, K_4, K_5$ are set to 0. For IGRP, this simplifies the formula to:

\text{Metric} = \text{Bandwidth} + \text{Delay}

Where “Bandwidth” is calculated as $(\frac{10^7}{ \text{Slowest Bandwidth in kbps}})$ and “Delay” is the $\text{Sum of Delays in tens of microseconds}$ .

Classic EIGRP uses the same components but scales the result by 256. With the default K values, its metric is 256 × (Bandwidth + Delay). EIGRP wide metrics modify the packet format and formula for high-bandwidth links and measure information-transfer time in picoseconds. In named mode, they use 64-bit calculations and can include the additional K6 coefficient, whose default value is 0.

IGRP limitation: classful routing

Despite its composite metric, IGRP had the same key flaw as RIPv1: it was a classful routing protocol. It did not send subnet mask information in its updates. This meant IGRP did not support VLSM and did not fit classless addressing in current networks.

As the Internet moved towards a classless model to conserve IP addresses, IGRP became obsolete. Cisco needed a successor that retained IGRP’s metric and supported classless addressing. That successor was EIGRP.

Characteristics of EIGRP

Enhanced Interior Gateway Routing Protocol (EIGRP) is an interior gateway protocol developed by Cisco. It is an enhanced version of IGRP and uses distance-vector technology. The DUAL algorithm calculates loop-free routes and selects backup routes.

EIGRP supports classless routing, neighbor relationships, partial route updates, and equal-cost and unequal-cost load balancing. These mechanisms combine neighbor information with route selection and topology-change processing.

DUAL and EIGRP tables

EIGRP route computation is based on the Diffusing Update Algorithm (DUAL). DUAL calculates loop-free routes and backup paths from information stored by the router.

Three routing tables

To store neighbor information and alternative routes, EIGRP maintains three tables instead of just one:

Neighbor Table: A list of all directly connected routers that have established an EIGRP adjacency. It contains the information needed to maintain those relationships.
Topology Table: The topology table contains all learned paths to every destination advertised by its neighbors, not just the best one. It is the complete set of advertised routes and their metrics.
Routing Table: Contains only the best path to each destination, selected from the topology table. It is used for forwarding packets.

The Feasibility Condition and loop-free backup paths

DUAL selects loop-free backup routes using a rule called the Feasibility Condition. Applying it requires two definitions:

This is the router’s stored lowest-known metric to the destination. It is not necessarily the metric of the path currently used in its routing table.
This is the value the neighbor reports for the destination. It is the neighbor’s advertised metric, not a Feasible Distance calculated locally, and it may differ from the neighbor’s current distance during route recomputation.

The Feasibility Condition states: For a path advertised by a neighbor to be considered a valid, loop-free backup path, the neighbor’s Reported Distance (RD) to the destination must be strictly less than the router’s stored Feasible Distance (FD) to that same destination. This is a sufficient but not necessary condition: every path that meets the inequality is loop-free, but not every loop-free path meets it.

\text{Feasibility Condition: } \text{RD}_{\text{neighbor}} < \text{FD}_{\text{me}}

Numeric example: Router A computes a route to destination Z. Its stored FD is 60 metric units. Neighbor B reports RD 40, so 40 is less than 60; B’s path meets the condition, can serve as a backup, and is downstream toward Z. Neighbor C reports RD 70, which exceeds A’s FD, so C’s path is not selected as a feasible successor. Without the condition, C’s path could return through A and form a loop.

Successor and Feasible Successor

This condition allows DUAL to classify the paths in its topology table:

Successor: This is the route with the lowest metric (the best path). The successor is installed in the routing table.
Feasible Successor (FS): This is an alternative path that meets the Feasibility Condition $(\text{RD} < \text{FD})$ . It is a loop-free backup path kept in the topology table and ready for use.

If the successor path fails and a Feasible Successor is present, the router does not need to send queries or wait for timers. It can install the Feasible Successor as the new successor without recomputing the route. Only when no Feasible Successor exists does the router enter an “active” state and send queries to its neighbors to find a new path.

EIGRP packets and additional features

In addition to DUAL, EIGRP defines features for packet transport, route updates, and path selection.

Reliable Transport Protocol (RTP): EIGRP does not use UDP or TCP. Packets are directly encapsulated in IPv4 or IPv6 and use IP protocol identifier 88. Its own Reliable Transport Protocol provides ordered, reliable delivery for packets that require acknowledgment. EIGRP defines five packet types: HELLO, UPDATE, QUERY, REPLY, and REQUEST. An ACK is carried in a HELLO packet, so it is not a separate sixth packet type. RTP is unrelated to the Real-time Transport Protocol used for voice and video.
Partial and bounded updates: Unlike RIP’s periodic transmission of the entire table, EIGRP sends updates in response to topology changes. After a neighbor relationship is formed, it sends the full table to the new neighbor; later updates are generated when a link goes up or down or a metric changes. The updates are partial because they contain only changed information, and bounded because they are sent only to routers affected by the change. This limits routing traffic on the network.
Classless by design: EIGRP was designed from the start to be classless. It supports VLSM and sends subnet mask information with every route update.
Equal- and unequal-cost load balancing: EIGRP can distribute traffic across multiple paths to the same destination. By default, it supports load balancing over up to 4 equal-cost paths, with more configurable. It can also perform unequal-cost load balancing using a feature called Variance. This allows traffic to use backup paths that are not as good as the primary path, as long as they meet the Feasibility Condition.

Specification Status and Use of EIGRP

IGRP is a retired protocol. EIGRP retained the composite-metric concept and added classless routing and the DUAL algorithm.

EIGRP was documented in 2016 as RFC 7868. The document is Informational, was independently submitted outside the IETF standards process, and is not an Internet Standard. Publication made the protocol description available but does not make EIGRP an open IETF standard. Selecting EIGRP, OSPF, or IS-IS depends on device support, interoperability requirements, topology, and operational policy.