Transcript Myths_and_Truths_about_EIGRP_02_2012

Myths and Truths
about EIGRP
Peter Palúch, CCIE #23527, CCIP, CCAI
Cisco CSC Designated VIP 2011-2012
Networking Academy Webinar
February 29th, 2012
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
2
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
3
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
4
A Network Topology Example
R2
A
D
B
E
R3
R1
C
R5
F
G
R4
5
What would Router A see in LS and DV?
A
R2
D
A
B
C
E
R3
R1
R1
B
F
D, E, F, G
C
R5
G
R4
R2
In Link-State Protocol
R3
R4
In Distance-Vector Protocol
6
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!
7
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 
8
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
9
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
10
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
11
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
12
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
13
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
14
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?
R2
10.0.35.0/24
10.0.13.0/24
R1
R3
R5
192.0.2.0/24
R4
15
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
16
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.”
17
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
18
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
R2
5
22
25
10
R3
R1
R5
10
10
R4
1
19
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
20
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
21
About EIGRP’s SIA state (2)
Will this circular topology lead to SIAs?
22
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
23
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
24
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
25
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 232-1 and
instead, it overflows, possibly producing a smaller value
26
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
27
Thank you!
Peter Palúch
[email protected]
28