Myths and Truths about EIGRP

reekydizzyNetworking and Communications

Oct 28, 2013 (3 years and 9 months ago)

159 views

Myths and Truths

about EIGRP

Peter Pal
úch, CCIE
#23527, CCIP, CCAI

Cisco CSC Designated VIP 2011
-
2012


Networking Academy Webinar

February 29
th
, 2012

2

Rationale behind this session


EIGRP has been supported since 1992 in IOS 9.21


Despite its long existence, EIGRP still proves to be little
known and poorly understood when it comes to details


There are many materials about EIGRP published


Sadly, many of them are superficial


Even more sadly, quite a few of them contain incomplete,
inaccurate or outright misleading and incorrect information


Certain topics are notorious for this



Not even official materials have been spared


This session would like to dispel some of the most
common myths and superstitions about EIGRP

3

About EIGRP’s Nature (1)


EIGRP was described in the past as “balanced hybrid”


Combining Distance
-
Vector (DV) and Link
-
State (LS) properties


To decide what EIGRP really is, we need to look at what
classifies the protocol as either DV or LS


What defines a LS protocol?


LS works by routers exchanging
topological elements
, i.e. exact
information about
routers themselves

and their
adjacencies


Addresses, networks and metrics are merely attributes of routers
and their interconnections


Each router knows all other routers and their connections
precisely; all routers have identical link
-
state database


Using the link
-
state database of any single router, administrator
can draw the diagram of the entire network

4

About EIGRP’s Nature (2)


What defines a DV protocol?


DV works by routers exchanging
vectors
, i.e. arrays,
of distances
to individual known
networks


The CCNA
-
level explanation of the DV as exchanging “metrics and
directions” is perhaps illustrative but imprecise


No topological information (i.e. what are the individual routers,
how are they interconnected) is ever exchanged or known


What
does not

influence the routing protocol’s type?


Type of metrics used


Full vs. incremental updates


Periodic vs. event
-
based updates


Usage of a Hello mechanism and establishing neighborships


Usage of a reliable transport mechanism



5

A Network Topology Example

R1

R2

R3

R4

R5

A

B

C

D

E

F

G

6

What would Router A see in LS and DV?

R1

R2

R3

R4

R5

A

B

C

D

E

F

G

R1

R2

R3

R4

D, E,

F, G

In Link
-
State Protocol

In Distance
-
Vector Protocol

A

B

C

7

What information does EIGRP carry?



In EIGRP, routing information is
carried inside Update packets


In an Update, after header, an array
of records follows:


Type and size of the record in the
array (IP internal, IP external, …)


Next Hop


Metric Values (Delay, Bandwidth,
MTU, Hop Count, Reliability, Load)


Address information (prefix, netmask)


This is a
vector of distances
!

8

About EIGRP’s Nature (3)


EIGRP carries detailed information about a particular path’s
properties but there is no topological information


No matter how diverse the component metrics are, they are only
metrics and do not reveal the complete picture of the network


Addition of mechanisms formerly typical for LS protocols does
not make EIGRP a hybrid protocol


A hybrid protocol would need to maintain a LS database for a limited
part of network, describing the rest using a DV approach


This is the principle of areas in LS protocols


Hello mechanism, neighborships, event
-
driven incremental updates
etc.


all these only increase the effectivity of EIGRP communication


They do not change the nature of routing information itself


The conclusion about EIGRP’s nature:


Advanced Distance
-
Vector


absolutely!


Hybrid? No way


9

About EIGRP’s Metrics (1)


EIGRP’s metric system includes six components


Bandwidth (static, min along path)


Delay (static, cumulative)


Reliability (dynamic, min along path)


Load (dynamic, max along path)


MTU (dynamic, min along path)


Hop Count (dynamic, cumulative)


EIGRP uses a weighted formula to compute a single
composite metric using the first four components


MTU and Hop Count are not used in this formula


All metrics are
always

advertised in their individual form


Delay and Hop Count are added to


Bandwidth, Reliability, MTU are minimized, Load is maximized

10

About EIGRP’s Metrics (2)


A couple of misconceptions exists about the K
-
values


The K
-
values are sometimes confused with metrics themselves


The K
-
values are thought to control the individual metrics, in
particular, K5 is thought to control the MTU usage




The K
-
values are simply weights applying to diverse
metric components


MTU is not included in the formula


Regardless of K
-
values settings, Update packets always contain
all metric components


K
-
values are carried in Hello packets and must match neighbor’s

11

About EIGRP’s Metrics (3)


The Hop Count is not used in best path selection


It is used as a safety net against count
-
to
-
infinity situations


Hop Count Limit can be configured in EIGRP configuration using
the
metric maximum
-
hops

command


Prefixes with a higher Hop Count will not be accepted


Information about MTU usage is conflicting


Some materials maintain that MTU is unused


Some other suggest that the MTU is used in cases where multiple
equal
-
cost paths are available


In discussions with four independent Cisco employees, it has
been confirmed that using the MTU was an idea considered but
ultimately never actually implemented

12

About EIGRP’s Metrics (4)


Reliability and Load metrics are unused by default


By tweaking the K
-
values, they can be utilized


However, Reliability and Load metrics in EIGRP do not
behave as intuitively expected


Reliability and Load counters on interfaces are updated steadily


Simply taking them into EIGRP would necessitate sending
Updates every moment these counters change


This could create extensive churn in routing tables, possibly leading
to ever increasing swings in these metrics values


In reality, advertised values of Reliability and Load always
correspond to their state in the moment of sending the update


They are set when advertising a route


Updates are not sent as a result of Reliability and Load changes

13

About EIGRP’s Metrics (5)


Thus, Reliability and Load are largely useless in EIGRP


Why are they even included, then?


The reason is backward compatibility and seamless
interoperability with IGRP that originally introduced them


If both IGRP and EIGRP were configured on a router in the same
AS, automatic redistribution between IGRP and EIGRP took place


Out of all EIGRP’s metrics, only Bandwidth and Delay are
usable in a reasonable way


Bandwidth should never be used to influence routing decisions


It behaves non
-
linearly


Various IOS mechanisms depend on correct bandwidth setting


If EIGRP metric is to be influenced, the Delay should be modified

14

About EIGRP’s Terminology (1)


EIGRP uses an arcane terminology that is sometimes
troublesome to be used or understood in a proper way


Autonomous System: really a process number


Topology Table: does not contain any topological information


Successor and Feasible Successor: these are routers, not routes


Advertised Distance: its acronym of AD often gets confused with
Administrative Distance, a totally unrelated concept


Feasible Distance: it is not the current best distance, neither a
total distance through a particular neighbor


The Feasible Distance (FD) is one of the most
misunderstood concepts in EIGRP


Before diving into details about FD, let’s make a small
experiment in the network topology


15

Network Topology with Addressing


Assume that, initially, all links are configured with the same Delay=10
and K
-
values are 0, 0, 1, 0, 0 (on R5, the stub network’s Delay=1)


Now, assume that the Delay on links from R1 to R2
-
R4 gets increased to
20, resulting in the metric growup


What happens to FD?

R1

R2

R3

R4

R5

10.0.13.0/24

10.0.35.0/24

192.0.2.0/24

16

About EIGRP’s Terminology (2)


FD is not the current best path metric


FD is not the total distance via a particular neighbor


Rather, FD is a record of the smallest distance to the
destination since the last time the route went Passive


In other words, the FD is the historical minimum of the distance to
the particular destination


The history here ends and starts anew with the route transitioning
from Active to Passive state


During Passive state, the FD may only decrease


The only way to increase FD is to engage in a diffusing
computation and reset the FD after finishing it


FD is a local variable associated with each known prefix and is
never sent to any other EIGRP router

17

About EIGRP’s Terminology (3)


Using this notion of the FD, the Feasibility Condition can
be rewritten as:



“If a neighbor is closer to the destination than I have ever been, it
is guaranteedly not on a routing loop that would eventually lead
back to me.”



18

About EIGRP’s Feasible Successors (1)


To recall:


A successor must meet two constraints: pass the FC check and
provide the least total distance to the destination


A feasible successor must only pass the FC check


A FS provides a convenient back
-
up next hop in case the
current successor fails


It is widely believed that if the successor fails and at least one
feasible successor is known, it will always be used


However, there are situations in which a feasible
successor is known


and yet, when successor fails,
router will enter Active mode instead of using the FS

19

Network Topology with Modified Metrics


Let’s focus on the route from R1 to the network behind R5


FD = 21


R4: successor, Total Distance = 21*256 = 5376, RD = 11*256 = 2816


R3: feasible successor, Total Distance = 36*256 = 9216, RD = 11*256 = 2816


R2: fails FC check, Total Distance = 28*256 = 7168, RD = 23*256 = 5888

R1

R2

R3

R4

R5

5

25

10

22

10

10

1

20

About EIGRP’s Feasible Successors (2)


Assume that R4 as a successor fails


R1 will determine that while R3 is a FS, R2 has even better total
metric towards the destination but it does not pass the FC check


R1 will move the route into Active state and send queries


After receiving all replies and going Passive, R1 will reset the FD
and set it to the metric of the newly found route towards the
destination


The FS, although identified, will not be used in this case


Satisfying ourselves with the current FS would make us stay with
using a worse route than what is objectively available


The true logic regarding the use of FS


After successor fails, find the neighbor providing the next least
cost route to the destination


If it is a FS, start using it, otherwise, enter the Active state

21

About EIGRP’s SIA state (1)


The process of diffusing computation in EIGRP depends on
correct and timely arrival of Replies to all Queries


Once a router sends a Query, it must wait to receive Replies from all
queried neighbors before starting to send Replies itself


Delays in waiting for a single Reply will slow down the entire process
of convergence to a new path


One of the most sensitive weak spots in EIGRP


In extreme situation, if a Reply never comes, a route in Active state
can never reach the Passive state


EIGRP uses a so
-
called Active timer to bound the diffusing computation
to the duration of max. 3 minutes


If a diffusing computation does not finish in this time, the router declares
a so
-
called Stuck
-
in
-
Active state and resets the adjacency with the
unresponsive neighbor


Lossy and oversubscribed links, overloaded neighbors, misbehaving
EIGRP implementation, overly redundant or deep network topology:
all of this contributes to the risk of creating a SIA state

22

About EIGRP’s SIA state (2)

Will this circular topology lead to SIAs?

23

About EIGRP’s SIA state (3)


In circular topologies, Queries may be forwarded in a way
that they eventually reach back to the router that started
the diffusing computation


It is a popular belief that this will cause a deadlock and a SIA


This statement has even made it into Cisco Press CCNP
textbooks


In reality, if a router in Active state receives a Query, it
just replies immediately with the same information it has
already advertised in its own Query


Hence, circular topologies are no more prone to SIA states than
any other


In fundamental EIGRP’s algorithms, there are no deadlocks or
race conditions

24

Small things to be aware of (1)


EIGRP has a concept of Router ID


Chosen in a similar way to OSPF


By
eigrp router
-
id
command


If not, then by the highest active loopback IP address


If not, then by the highest IP address on all active interfaces


Router ID is displayed in the
show ip eigrp topology
output


Router ID is used as a prevention against routing loops, mostly caused
by circular route redistribution


Router ID is attached to redistributed routes


If a router receives a route tagged with its own Router ID, it will ignore it


Formerly, the Router ID has been attached to external (redistributed)
routes only


In recent IOS versions, the Router ID is also added to internal routes and
evaluated accordingly


See the
show ip eigrp topology X.X.X.X
output

25

Small things to be aware of (2)


Static routes defined using egress interfaces are
considered by EIGRP as directly connected


They can be injected into EIGRP using the
network

command
just like any other directly connected network


This often leads to confusion that static routes do not need to be
redistributed using the
redistribute

command


Especially dangerous when trying to inject a default route using
network 0.0.0.0

command


This will add all directly connected networks into EIGRP

(this is
probably not what you want)


Whether the default route will be injected as well depends on how it is
defined


it would have to be a static route via egress interface

26

Small things to be aware of (3)


When configuring metrics, it is good to avoid values close
to the maximum value


Delay can be defined in the range of 1


16,777,215


The maximum delay value represents infinity and a network with
such delay value will be considered unreachable


Remember that delay is cumulative


The variance code in EIGRP has a small glitch


Variance of “V” allows to use all FS routes whose metric is in the
interval of <BM, V * BM> where BM is the current best metric


In certain networks, even if the variance seems to be sufficient,
FS routes are mysteriously not included into the routing table


It turns out that the EIGRP code suffers from a trivial unsigned
integer overflow: the product of V*BM is not capped at 2
32
-
1 and
instead, it overflows, possibly producing a smaller value

27

Conclusions


EIGRP is a unique protocol in many aspects


As a proprietary protocol, its details are understandably
less publicly known and understood


Great care must be taken not to propagate incorrect
information about its workings


Huge THANK YOU to Donald Slice, Edison Ortiz, Russ White and
Riccardo Simoni for clarifying some of the obscure facts

28

Thank you!






Peter Pal
ú
ch

Peter.Paluch@fri.uniza.sk