Quick Notes: EIGRP Basics and Evolution, EIGRP Metrics (CCIE Official Cert Guide: Chapter 8)

From: CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1, 5th Edition

EIGRP Basics and Evolution

Basic EIGRP is no longer a closed, proprietary protocol. In 2013, Cisco opened up the EIGRP specification and published it as an IETF Internet Draft, a precursor to an RFC.

EIGRP Feature Summary

Transport: IP, protcol type 88 (does not use UDP or TCP). Implements its own Reliable Transport Protocol, providing reliable unicast and multicast packet delivery.
Metric: Based on constrained bandwidth and cumulative delay by default, and optionally load and reliability.
Hello interval: Interval at which routers send EIGRP Hello messages on an interface.
Hold timer: Timer used to determine when a neighboring router has failed, based on a router not receiving any EIGRP messages, including Hellos, in this timer period.
Update destination address: Normally sent to 224.0.0.10 or FF02::A, with retransmissions being sent to each other's unicast IP address.
Full or partial updates: Full updates are used when new neighbors are discovered; otherwise, partial updates are used.
Authentication: Supports MD5 and SHA-based authentication.
VLMS/Classless: EIGRP includes the mask with each route, also allowing it to support discontigous networks and VLSM.
Route Tags: Enables EIGRP to tag and filter internal and external routes using distribute-lists and route-maps.
Next-hop field: Supports the advertisement of routes with a different next-hop router than the advertising router.
Manual route summarization: Allows route summarization at any point in the EIGRP network.
Multiprotocol: Supports the advertisement of IPv4 and IPv6. Former implementations also supported IPX and AppleTalk routes.

EIGRP Roots: Interior Gateway Routing Protocol

IGRP is a dead protocol that was an immediate predecessor to EIGRP.
IGRP was developed to eliminate RIPv1's working but naive hop count metric and the network diameter limit of 15.
IGRP relied on a composite metric made up of a variety of route variables.

Benefits of IGRP over RIPv1:

wider network diameter, up to 255 hops
complex multivariate metric
unequal-cost load sharing
an update period of 90 seconds, three times longer than RIP
a more efficient update packet format

IGRP was designed to interoperate with multiple routed protocols, including IPv4, IPX, and AppleTalk.
IGRP broadcasted a Request packet out all IGRP-enabled interfaces at startup and performed a sanity check on received Update packets to verify that the source address of the packet belonged to the same subnet on which the Update was received.
Update packets were sent periodically every 90 seconds.
Like RIPv1, a classful distance-vector protocol.
Also relied on Split Horizon, triggered updates, Invalid after, Holddown, and Flushed after timers for functional stability.
IGRP summarized advertised addresses at network boundaries.
Overall, IGRP was better than RIP for larger networks, but it still had many of the fundamental limitations of RIP.

Moving From IGRP to EIGRP

Most significant IGRP weaknesses and detractors of IGRP include:

sending full routing updates periodically
the lack of VLSM support
slow convergence
the lack of adequate loop-prevention mechanisms

There is, in fact, very little left of the original IGRP in EIGRP - even though EIGRP is still a distance-vector routing protocol, albeit an advanced one.
In IGRP and RIP, the periodic Updates provided two separate and unrelated functions: 1) detecting neighbors and their liveliness, and 2) carrying routing information.
EIGRP decouples the building and maintaining of adjacencies from exchanging routing information.
The first task is accomplished by using a Hello protocol.
It is no longer necessary to periodically send Update packets to announce a router's continuous presence on a network. The Hello protocol is used to build and maintain neighbor adjacencies.
To send triggered updates, EIGRP implements the Reliable Transport Protocol (RTP; do not confuse with Real-time Transport Protocol), which is a Layer 3-independent transport protocol capable of reliable unicast and multicast delivery.
The use of RTP allows routers to initially exchange the complete routing information when synchronizing for the first time, and afterward, advertise changed routes only.
EIGRP completely abandons the periodic updating process and operates in an event-driven, incremental fashion.
To maintain a loop-free operation at every instant, EIGRP uses a so-called Feasibility Condition.
So-called diffusing computations work in tandem with the Feasibility Condition.
The current least-cost path can become ineligible, and EIGRP queries its neighbors to update their own best path selection in relation to the topology change and reply with their updated distances. Neighbors that are not adversely affected will simply respond right away; neighbors that are adversely affected will propagate the query further and can respond only after receiving all replies and making a choice themselves.
EIGRP implements a finite state machine called Diffusing Update Algorithm (DUAL) that controls the run of a diffusing computation, processing the replies and eventually inserting the gathered information into the routing table or commencing an additional computation.
The DUAL is not the diffusing computation algorithm itself; it is a control mechanism on top of diffusing computations.
EIGRP has a default hop-count limitation of 100 (can be manually adjusted with metric maximum-hops <1-255>).
EIGRP makes a distinction between internal and external routes.
Internal routes are those injected into EIGRP by the network command (AD of 90 by default).
External routes are redistributed into EIGRP from a different routing source (AD of 170 by default).
Changing the default AD values: distance eigrp int ext.

EIGRP Classic Metrics

EIGRP uses several metric components: bandwidth, delay, reliability, load, MTU, and hop count.
The first four are combined together using a well-known formula to produce a single number, i.e. the composite metric, which is used by EIGRP to choose the best path toward a destination.
EIGRP shipped with recent IOS versions also supports a so-called Wide Metrics, which expand the allowable range of existing Classic Metrics.

Bandwidth

A static metric assigned to each router interface using the bandwidth command.
Obviously, describes the transmission speed of an interface.
Expressed in kilobits per seconds.
If no bandwidth is specified, the IOS assigns an implicit bandwidth value to each interface, depending on its hardware type and operational characteristics.
With Ethernet interfaces, the implicit bandwidth value reflects the true speed negotiated by the interface with its links partner.
On other interface types, the value has no realistic relation to the interface capabilities.
EIGRP considers the minimum bandwidth along the route.
This is done by comparing the bandwidth as advertised by neighboring router to the bandwidth of the interface toward the advertising neighbor, and taking the lower value of these two.
With Classic Metrics, EIGRP is capable of describing the bandwidth in the range of 1 kbps up to 10 Gbps.

Delay

A static metric assigned to each interface using the delay command.
Estimates the serialization delay incurred by the interface.
Not related to any true characteristic of an interface.
Inconvenient units: tens of microseconds.
Configuring a delay of 123 defines the delay to be 1230 microseconds.
The show interface command output reports the interface delay directly in microseconds.
Therefore, the show interface output will always display a value ten times higher than the configured value.
If the delay is not configured explicitly, IOS assigns an implicit delay value to each interface, depending on the interface hardware type.
When calculating the composite metric, EIGRP takes the total delay into account.
This is done by taking the delay as advertised by a neighboring router and summing it with the delay of the interface toward the advertising neighbor.
With Classic Metrics, EIGRP is capable of describing the delay in the range of 10 to 167,772,140 microsends.
The maximum value is used to indicate an infinite distance.
Split Horizon with Poisoned Reverse, Route Poisoning, withdrawing a route - all these techniques in EIGRP use the maximum delay to indicate an unreachable route.

Reliability

A dynamically estimated metric of an interface that evaluates its ratio between successfully received and all received packets.
The ratio is expressed as a fraction of 255.
A reliability of 255 expresses a 100 percent reliability.
EIGRP takes the minimal reliability into account.
This is done by comparing the reliability as advertised by a neighboring router to the reliability of the interface toward the advertising neighbor, and taking the lower value of these two.
A change in interface reliability value does not trigger sending EIGRP updates.
Currently just a relic carried over from its predecessor, with no particular usability.

Load

A dynamically estimated metric that measures the amount of traffic flowing through the interface in relation to its maximum capacity.
Also expressed as a fraction of 255, with the load of 1 representing an emptry interface and the load of 255 representing a fully utilized interface.
IOS actually computes an exponentially weighted average over the momentary load that smooths out short-lived load swings.
Two independent load metric counters: the Txload for outgoing traffic and Rxload for incoming traffic.
EIGRP takes the maximal Txload into account.
This is done by comparing the load as advertised by a neighboring router to the Txload of the interface toward the advertising neighbor, and taking the higher value of these two.
The changes in the Txload values on interfaces do not trigger EIGRP updates.
Also a relic from IGRP with no particular usability in EIGRP.

MTU

EIGRP advertises the minimum MTU along the route to the destination.
However, the MTU is completely unused in the best-path selection process.
Not factored into the composite metric, nor is it used as any kind of a tiebreaker.

Hop Count

Simply a counter of routers (hops) in the path toward the destination.
It is just a fallback security measure: routes reaching over a predefined threshold are advertised as unreachable, thereby breaking any potential routing loops.
By default, the limit is 100, configurable in the range of 1 to 255.
Not factored into the composite metric calculation and does not impact the best-path selection in any way.

Calculating the Composite Metric

Because EIGRP treats each metric component differently (delay is summed, bandwidth and reliability are minimized, load is maximized), EIGRP routers exchange these component metrics as separate values.
Each router independently computes the resulting composite metric on its own.
This composite metric is used locally on a router, and is never advertised as a single number in EIGRP messages.
The only exception to this rule is when a route is redistributed from one EIGRP process to another.
Even in this case, the composite metric of the redistributed route is retaken only for diagnostic purposes and carried separately from the seed metric.
EIGRP computes the composite metric value using the following formula.

The constants K1 through K5, commonly called K values, are weight constants in the range 0-255 that can be tweaked to influence the impact of individual metric components on the overall composite metric.
It is crucial that all EIGRP routers in the same domain compute the composite metric in the same way.
Therefore, K values on all routers must match.
If K values do not match, two routers will not be able to establish an adjacency.
By default, K1 and K3 are set to 1, and all other K values are set 0, causing EIGRP to take only bandwidth and delay into account.
The multiplication by 256 is the result of expanding the former IGRP 24-bit metric into a 32-bit metric used by EIGRP.

EIGRP Wide Metrics

EIGRP Classic Metric faced issues with interfaces faster than 1 Gbps.
The Bandwidth component is unable to differentiate between 10 Gbps and faster interfaces.
The Delay component is already set to the lowest value of 1 (microseconds) on 1 Gbps interfaces, and cannot be made smaller.
Cisco routers perform integer arithmetic.
To verify support of Wide Metric, issue show eigrp tech-support and look for Wide Metrics in the output.
show ip protocols: the presence of the K6 constant, the rib-scale of 128 and 64-bit metric version all indicate that Wide Metrics are supported.

EIGRP Wide Metrics consist of the following components:

Throughput: Analogous to the classic Bandwidth component. Calculation: 65536x10^7/Interface Bandwidth in kbps. Effectively tells how many times slower the interface is than a 655.36 Tbps link.
Latency: Analogous to the classic Delay component. Calculation: 65536xInterface Delay/10^6. The interface delay is expressed in picoseconds. The computation of per-interface delay metric differs based on its physical capability and configuration.

If < 1 Gbps without bandwidth and delay commands, the interface delay is simply its IOS-based default delay converted to picoseconds.

If > 1 Gbps without bandwidth and delay commands, the interface delay is computed as 10^13/interface default bandwidth.

With explicit bandwidth but without delay, regardless of their physical operating speed, the interface delay is the IOS-based default delay converted to picoseconds.

With explicit delay, regardless of the physical operating speed and the bandwidth setting, the interface delay is computed as its specified delay value converted to picoseconds.

Reliability: Identical to the classic Reliability component, and has not changed in Wide Metrics.
Load: Identical to the classic Load component, and has not changed in Wide Metrics.
MTU: Identical to the classic MTU, and is advertised but not used.
Hop Count: Identical to the classic Hop Count, and is advertised but unused in path selection; it only prevents potential routing loops.
Extended Metrics: Considered as placeholders for future extensions to the composite metric computation. Three extended metrics are defined: Jitter, Energy, and Quiescent Engergy. K6 was introduced to incorporate these metric components. Not usually used or supported.

Wide Metric formula.

The Wide Metric support is available when EIGRP is configured in named mode, and is automatically activated (no command to control the activation).
EIGRP automatically detects if their neighbors also support Wide Metrics, and use the appropriate metric type when talking to them.
Wide Metrics are preferred.
In the case of mixed neighbors on a common interface, EIGRP will use both metric formats, allowing each neighbor to process the metric format it supports.
The Wide Metrics composite value can result in a number wider than 32 bits, which is the maximum supported by the the RIB.
The value must be downscaled before the route can be passed down to the RIB.
This is done by dividing the value by a factor configured in the metric rib-scale command.
The default value is 128 and can be configured in the range 1-255.
The downscaled value is not used by EIGRP in any way.
EIGRP makes all its path selections based on the Wide Metrics composite value; only after a best path toward a destination is selected, its composite metric value is downscaled as the route is installed to the RIB.

Tweaking Interface Metrics to Influence Path Selection

Only Bandwidth and Delay can be manually influenced.
Do not use Bandwidth for traffic engineering. The change will only affect path selection if the configured value is the lowest bandwidth over the entire path. Further, changing the bandwidth can have an impact beyond affecting the EIGRP metrics (for example, QoS).
By default, EIGRP throttles to use 50 percent of the configured bandwidth. Lowering the value can starve EIGRP neighbors from getting packets. An excessively high bandwidth can lead EIGRP to consume more bandwidth than physically available, leading to packet drops.
The delay does not impact other protocols nor does it cause EIGRP to throttle back, and as the sum of all delays, it has a direct effect on path selection.
Bandwidth should always be configured to the true bandwidth of the interface and should never be used to influence EIGRP's path selction.

Network Playroom

Search This Blog