T-Shoot EIGRP BRKRST-2331

#CLUS
Troubleshooting
EIGRP Networks
Peter Palúch, CCIE Exam Program Manager

@Peter_Paluch
BRKRST-2331
#CLUS
Troubleshooting EIGRP Networks –
Agenda
• EIGRP Troubleshooting Toolkit Overview
• Troubleshooting Neighbor Adjacency Issues
• Troubleshooting Best Path Selection Issues
• Troubleshooting Route Advertisement and Convergence Issues
• Troubleshooting Issues with Specific EIGRP Features
• Wrap-Up & Additional Sessions and Resources
#CLUS BRKRST-2331 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
EIGRP
Troubleshooting
Toolkit Overview
Approaching the Troubleshooting Process
• General trigger for troubleshooting
• The system behaves differently from our expectations
• Troubleshooting
• Minimizing the difference between the observed and expected behavior
• Key to successful troubleshooting
• Good understanding how the system should behave under circumstances
• Tools to gain insight into the system
• Structured approach
Troubleshooting Process for EIGRP
• Possible problem areas • Troubleshooting tools
• Neighbor Adjacency • show commands
• Initial Neighbor Synchronization • Event history
• Best Path Selection • Debugs
• Routing Table Updates • Packet captures
• Best Path Advertisement
• Reacting to Topology Changes
Troubleshooting Commands for EIGRP
IOS and IOS-XE Cheat Sheet
• There are two variants of show commands for EIGRP
• show { ip | ipv6 } eigrp …
• show eigrp address-family { ipv4 | ipv6 } …
• They are largely equivalent; the new CLI is a superset of the old CLI
• For packet captures, Embedded Packet Capture is an option
• For more in-depth insight, we often need to resort to debugs
• Obvious dangers in increased CPU footprint and console output
• Always use no logging console and either use logging buffered
or logging logfile
IOS and IOS-XE Cheat Sheet
• Neighbor Issues
• show { ip | ipv6 } eigrp neighbor [ detail ]
• show { ip | ipv6 } eigrp interfaces [ detail ]
• show { ip | ipv6 } eigrp events
• show logging
• debug eigrp packets (with care)
• debug eigrp transmit (with care)
EIGRP IOS Event Log
• On a busy, unstable network, debugs can be hazardous
• Event log is non-disruptive — it is running by default
• Defaults to 500 lines (configurable)
• eigrp event-log-size <number of lines>
• Maximum event-log-size is half of available memory
• Most recent events at top of log by default
• Read from the bottom to top
• Later version support displaying the event log in reverse!
• Can be cleared by clear ip eigrp event
• Contents displayed with show ip eigrp events
EIGRP IOS Event Log
• Three different event types can be logged
• eigrp log-event-type [dual] [xmit] [transport]
• Default is dual – typically most useful
• This is the decision mechanism in EIGRP driving its entire logic
• xmit and transport are different aspects of actually sending packets to
peers
• Any combination of the three can be on at the same time
• Work is in progress to add additional debug information to event log
NX-OS Cheat Sheet
• CLI in NX-OS is very similar to IOS/IOS-XE, only minor differences
• NX-OS has powerful event history logging
• In absolute majority of cases, debugs are not needed
• Another great tool in NX-OS is ethanalyzer
• Similar to tshark/tcpdump
• Real-time capture and dissection of traffic to/from supervisor CPU
• Be mindful of a slightly elevated CPU, though
• If debugs are needed after all, make sure to use debug logfile
NX-OS Cheat Sheet
• Neighbor Issues
• show { ip | ipv6 } eigrp neighbor [ detail ]
• show { ip | ipv6 } eigrp interfaces [ detail ]
• show { ip | ipv6 } eigrp event-history { fsm | packet }
• show eigrp internal event-history { errors | notif }
• show logging logfile
• ethanalyzer (with care)
• debug { ip | ipv6 } eigrp packets (with care)
• debug { ip | ipv6 } eigrp transmit (with care)
NX-OS Cheat Sheet
• Route Computation & Advertisement Issues
• show { ip | ipv6 } eigrp topology
• show { ip | ipv6 } eigrp event-h { fsm | packet | rib }
• show routing event-history add-route filter vrf …
• show routing event-history delete-route filter vrf …
• show routing event-history modify-route filter vrf …
• ethanalyzer (with care)
• debug { ip | ipv6 } eigrp (with care)
• debug { ip | ipv6 } eigrp packets (with care)
• debug { ip | ipv6 } eigrp transmit (with care)
Troubleshooting
Neighbor
Adjacency and
Initial Sync Issues
Tables in EIGRP
• EIGRP maintains several tables
• Interface table (show ip eigrp interface)
• Neighbor table (show ip eigrp neighbor)
• Topology table (show ip eigrp topology)
• These are the crucial tables our troubleshooting will always be focusing on
• We cannot have a neighbor on an interface if that interface is not present in the
interface table
• We cannot have a route from a neighbor if that neighbor is not present in the
neighbor table
• We cannot have a route installed in our RIB/FIB and advertised in EIGRP if it is not
present in the topology table
Neighbor Adjacencies in EIGRP
• EIGRP only accepts routing information from known neighbors
• Detected dynamically using multicast Hellos, or configured statically
• Necessary conditions for two routers to become neighbors:
• Use the same EIGRP autonomous system number (process ID)
• Be in common subnet on non-passive interfaces included in EIGRP
• Use the same K-values
• Use the same authentication parameters
Establishing Neighbor Adjacency in EIGRP
R1 R2
Hello
R2 puts R1 to Pending
Hello Waiting for Init and Init Ack
R1 puts R2 to Pending
Waiting for Init and Init Ack Similar to TCP
Null Update w/ Init, Seq=x 3-way handshake
Init received from R2
Waiting for Init Ack Null Update w/ Init, Seq=y, Ack=x
Init and Init Ack received from R1
Acknowledgement, Ack=y R2 puts R1 to Up
Init Ack received from R2
R1 puts R2 to Up
Database Synchronization
using Updates and Acks
show ip eigrp neighbors Outstanding Packets
RtrA# show ip eigrp neighbors Last Reliable Packet Received

IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 10.1.1.1 Et0 12 6d16h 20 200 0 233
1 10.1.4.3 Et1 13 2w2d 87 522 0 452
0 10.1.4.2 Et1 10 2w2d 85 510 0 3
Seconds Remaining Before Declaring Neighbor Down
How Long Since the Last Time Neighbor Has Come Up
How Long It Takes for This Neighbor to Respond to Reliable Packets
How Long We’ll Wait Before Retransmitting if No Acknowledgement

Issues with
Neighbor
Adjacencies
Reasons for Adjacency Flaps
• Neighbor adjacency issues always result in the adjacency ultimately
dropping for a certain reason
• Assuming eigrp log-neighbor-changes is configured (on by
default since 12.2(12)), logs will include a message explaining the
immediate reason for the adjacency drop
• peer graceful-restart
• peer restarted
• holding time expired
• retry limit exceeded
• Interface PEER-TERMINATION received / Interface Goodbye received
Typical Causes of EIGRP Adjacency Issues
Mismatched mandatory configuration parameters
• Typical symptoms
• Neighbors do not come up at all
• In some cases, messages might be logged
• What to check
• ASN, common IP subnet (beware of secondary addresses), K-values,
authentication, input ACLs
• Check show ip eigrp interface for the interface to the neighbor;
interfaces that are passive / not added to EIGRP will not be listed
• Verify the unicast and multicast connectivity between the neighbors by
pinging both the neighbor and the 224.0.0.10 or ff02::a multicast group
Incongruent unicast and multicast connectivity
• Adjacency comes up on both routers and keeps flapping (unicast issues)
• Adjacency comes up on one router and keeps flapping (multicast issues)
• show ip eigrp neighbor detail shows non-zero QCnt and reports
waiting for Init and/or Init Ack; neighbors flap due to retry limit exceeded
R2# show ip eigrp neighbor detail

EIGRP-IPv4 VR(ROCKS) Address-Family Neighbors for AS(1)
(sec) (ms) Cnt Num
0 10.0.12.1 Et2/1 13 00:00:19 1 5000 1 0
Version 18.0/2.0, Retrans: 5, Retries: 5, Waiting for Init, Waiting for Init Ack
Topology-ids from peer - 0
UPDATE seq 17 ser 0-0 Sent 19860 Init Sequenced
Incongruent unicast and multicast connectivity
• What to check
• Inspect input ACLs and NAT
• Try pinging the neighbor’s IP, and the 224.0.0.10 or ff02::a group, from
both routers
• If the ping to the unicast IP address fails, check the ARP/ND entry; if
missing, try configuring it statically; if still no response, the other router or
an L2 issue are the likely culprits, otherwise the issue is with ARP/ND
• If the ping to the multicast group is not answered by the neighbor, link-
local multicast delivery needs to be inspected
• These issues are mostly seen in stretched L2 environments (OTV/VXLAN)
L3 adjacencies over Virtual Port-Channel (vPC)
2.2.2.2/24
• vPC poses unique challenges for
IGP adjacencies including EIGRP
• Data Plane issue
• vPC Loop Prevention rule: A frame
received through the peer-link must
not be forwarded out any vPC
• This rule applies even if the packet in
the frame is routed and crosses the
SwA SwB
VLAN boundary
IP: 1.1.1.1/24 IP: 1.1.1.2/24
• Solution: Have the vPC peers share MAC: X MAC: Y
their MAC addresses (peer-gateway)
2.2.2.2/24
• Control Plane issue
• Packets for SwA (1.1.1.1, MAC X) may
be put on link to SwB, and vice versa
• With peer-gateway, SwB will route
them to SwA and decrement their TTL
• Packets with TTL=1 will expire on SwB;
these are typical IGP unicast packets
• GTSM might trigger, too
SwA SwB
• Solution: Do not decrement the TTL IP: 1.1.1.1/24 IP: 1.1.1.2/24
when routing unicast packets across MAC: X (+Y) MAC: Y (+X)
the peer-link (layer3 peer-router)
• The support for L3 IGP adjacencies over vPC has been introduced
gradually and is described in the document Supported Topologies
for Routing over Virtual Port Channel on Nexus Platforms
• Note: IOS before 15.2(1) sends EIGRP packets with TTL=2
• This allowed EIGRP adjacencies between IOS and Nexus devices over
vPC to “just work” without any additional configuration
• After upgrade to a 15.2+ IOS, things suddenly stop working since EIGRP
starts using TTL=1
Other unsorted causes
• Combination of static and dynamic neighbors on an interface
• Symptoms match the incongruent unicast/multicast connectivity scenario
• Either all neighbors on a segment are static, or none are
• Unidirectional link
• Adjacency comes up only on one router, flaps with retry limit exceeded
• Hold timer shorter than Hello timer
• Adjacency comes up fully with no ill symptoms but once the peers have
synchronized, it times out
• Packet loss, congestion, CoPP, physical layer errors
Issues with
Initial Neighbor
Synchronization
Initial Neighbor Synchronization
• Once the adjacency is up, EIGRP neighbors will proceed with
synchronizing their topology tables
• Each router sends all network entries from its topology table to its peer(s)
• Synchronization involves both unicast and multicast packets
• Be mindful of Split Horizon with Poisoned Reverse
• Size of the topology table matters

• EIGRP does not rely on IP fragmentation
• Advertised networks are packetized based on the egress interface’s MTU
Typical Causes of Initial Synchronization Issues
MTU Issues
• Neighbors initially become fully up
• show ip eigrp neighbor detail shows non-zero QCnt and reports
a sequenced Update; neighbors flap due to retry limit exceeded
• No waiting for Init/Init Ack (distinguishes from an adjacency issue!)
R2# show ip eigrp neighbor detail

EIGRP-IPv4 VR(ROCKS) Address-Family Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO
Q Seq
(sec) (ms) Cnt Num
0 10.0.12.1 Et2/1 13 00:42:01 26 5000 1 6
Version 18.0/2.0, Retrans: 14, Retries: 13, Prefixes: 1
Topology-ids from peer - 0
UPDATE seq 7 ser 5-5 Sent 31848 Sequenced
Typical Causes of Initial Synchronization Issues
Other unsorted causes
• EIGRP packet pacing
• By default, EIGRP can consume up to 50% of interface’s bandwidth
• Beware of unrealistic bandwidth setting
• Too low means delayed convergence (Tunnel interfaces used 9Kbps by default)
• Too high means possible oversubscription of the physical interface
• Packet loss, congestion, CoPP, physical layer errors
Troubleshooting
Best Path
Selection Issues
EIGRP Terminology
EIGRP Terminology
Reported Distance
• For every destination, each router
chooses the best path, and
reports its metric to its neighbors
• Reported Distance
• The last known distance of
a neighbor to a destination
• For each destination, there are
multiple RDs, one for each neighbor
• In the past, the term “Advertised
Distance” was also used
EIGRP Terminology
Computed Distance
• For RtrA, there are multiple
resulting distances to RtrE
• 20 through RtrB
• 25 through RtrC
• 45 through RtrD
• Computed Distance
• The overall distance to a destination
through a particular neighbor
• For each destination, there are
multiple CDs, one for each neighbor
EIGRP Terminology
Feasible Distance
• Feasible Distance
• The smallest known Computed
Distance to the destination since the
last transition from Active to Passive
• In a way, the “historically” smallest
distance to the destination
• Not necessarily equal to the current
best path’s CD (FD can be smaller!)
• Only one FD per destination
• FD is a local value, never advertised
to any neighbor
EIGRP Terminology
Feasible Distance
• During Passive state, FD can either
stay the same, or decrease
• Currently, FD is 20
• If the cost of A/B link grows from 10 8
15
to 15, the best CD will be 25 but FD
will stay at 20
• If the cost of A/B link shrinks to 8,
both the best CD and FD will fall to 18
• The only way for FD to increase is to
enter the Active state and perform
a diffusing computation
EIGRP Terminology
Feasibility Condition
• Feasibility Condition
• The key loop freedom test
performed with every path selection
• Every neighbor satisfying the
condition RD < FD provides a loop-
free path
“If you are closer to the destination

than I have ever been, your path
cannot possibly traverse through me.”
EIGRP Terminology
Successor, Feasible Successor
• Successor
• Neighbor meeting the Feasibility
Condition and providing the least
Computed Distance (shortest path)
• Both RtrB and RtrC meet the FC
• RtrB is a Successor
• Feasible Successor
• Neighbor meeting the FC but not
providing the least CD
• RtrC is a Feasible Successor
EIGRP Terminology
Possible Successor
• RtrD does not meet FC
• It could possibly be using RtrA
• FC is a sufficient, not a necessary
condition for loop freedom
• If met, then the path is guaranteed to
be loop-free
• If not met, the path may or may not
be loop-free – but we do not risk it
• RtrD is a Possible Successor
EIGRP Terminology
The Real Use of Feasible Successors
• In a stable state, from RtrA to RtrE:
• FD is 20
• RtrB is Successor, CD=20
• RtrC is Feasible Successor, CD=25
• RtrD is Possible Successor, CD=21
• RtrD does not really loop through RtrA
but RtrA has no way of knowing
• What happens if RtrB fails?
• We could use RtrC as the FS – but
we would stick to a suboptimal path
EIGRP Terminology
The Real Use of Feasible Successors
• What happens if RtrB fails?
• After RtrB is down, the smallest CD is
provided by RtrD but it is not a FS
• Therefore, RtrA goes Active and sends
a Query to both RtrC and RtrD claiming
its current infinite distance
• Since neither RtrC nor RtrD are
impacted, they just respond with 10
and 20, respectively
• RtrA can now reset its FD and take the
shortest path available – through RtrD
Here, RtrC has been, and has remained, a Feasible Successor only
EIGRP Terminology
Path Selection Rules
• Whenever an EIGRP router learns about a topology change:
• It updates the affected Reported and Computed Distances
• It finds the neighbor providing the least Computed Distance
• It checks whether that neighbor meets the Feasibility Condition
• If so (meaning it is the Successor or Feasible Successor), start using it as
a Successor and update neighbors about the new distance
• Otherwise, go Active and send out Queries, indicating the current (increased)
distance through the current Successor
• Just because a neighbor is a Feasible Successor does not mean it will
automatically be used when the Successor fails
EIGRP Topology
Table
EIGRP Topology Table
• The topology table is the most critical structure in EIGRP
• Fundamental data store of all EIGRP’s knowledge about reachable
networks and possible next hops
• All best path selections are done on the topology table contents
• A network cannot be placed into the routing table if missing from
topology table
• A network cannot be advertised to other neighbors if missing from
topology table
• Understanding the topology table contents is extremely important in
troubleshooting EIGRP problems
Total number of routes in the local topology table
Number of Replies to send from this router
Internal data structures used to manage the topology table
RtrA# sh ip eigrp topology sum

IP-EIGRP Topology Table for AS(200)/ID(40.80.0.17)
Head serial 1, next serial 1526
589 routes, 0 pending replies, 0 dummies
IP-EIGRP(0) enabled on 12 interfaces, neighbors present on 4 interfaces
Quiescent interfaces: Po3 Po6 Po2 Gi8/5
Interfaces with No Outstanding Packets to Be Sent or Acknowledged
show ip eigrp topology
.2 .1
• Displays a list of known networks B
known to EIGRP, their successors,
10.200.1.0/24
and feasible successors .1
.1 56K .2 .1 128K .2
.2
A 10.1.2.0/24 C 10.1.5.0/24 E
.1 .2
RtrA# show ip eigrp topology .2

D .1
[...]
P 10.200.1.0/24, 1 successors, FD is 21026560 Feasible distance
via 10.1.1.2 (21026560/20514560), Serial1/0 Successor
via 10.1.2.2 (46740736/20514560), Serial1/1 Feasible successor
Computed Reported
distance distance
Topology Table
show ip eigrp topology all-links
.2 .1
• Displays a list of known networks B
known to EIGRP, their successors,
10.200.1.0/24
feasible, and possible successors .1
.1 56K .2 .1 128K .2
.2
A 10.1.2.0/24 C 10.1.5.0/24 E
• Some neighbors may be missing .1 .2
• This is due to Split Horizon

.2 .1
D
RtrA# show ip eigrp topology all-links
[...]
via 10.1.3.2 (46740736/46228736), Serial1/2 Possible successor
Computed Reported
distance distance #CLUS BRKRST-2331 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 48
Topology Table
show ip eigrp topology network/netmask
.2 .1
• Displays detailed information for B
all paths received for a particular
10.200.1.0/24
destination including detailed .1
.1 56K .2 .1 128K .2
.2
metrics A 10.1.2.0/24 C 10.1.5.0/24 E

.1 .2
RtrA# show ip eigrp topology 10.200.1.0/24
IP-EIGRP topology entry for 10.200.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21026560
Routing Descriptor Blocks: .2 .1
D
10.1.1.2 (Serial1/0), from 10.1.1.2, Send flag is 0x0
Composite metric is (21026560/20514560), Route is Internal
Vector metric:
....
Vector metric:
....
Vector metric:
....
Topology Table
show ip eigrp topology zero-successors
.2 .1
• Zero successor routes are those B
that fail to get installed in the
10.200.1.0/24
routing table by EIGRP because .1
.1 56K .2 .1 128K .2
.2
there is a route with a better A 10.1.2.0/24 C 10.1.5.0/24 E

.1 .2
admin distance already installed
.2 .1
RtrA# show ip eigrp topology zero D
....
P 10.200.1.0/24, 0 successors, FD is Inaccessible
via 10.1.1.2 (21026560/20514560), Serial1/0 RtrA# show ip route 10.200.1.0 255.255.255.0
via 10.1.2.2 (46740736/20514560), Serial1/1 Routing entry for 10.200.1.0/24
via 10.1.3.2 (46740736/46228736), Serial1/2 Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.1.1.2
Route metric is 0, traffic share count is 1
Where to Look If a Route Is Not Getting Installed
• If the expected route is not being installed into RIB
• Check whether the route is in the EIGRP topology table
• If not, consider inbound/outbound route filtering, Split Horizon misbehavior, stub,
hop limit being exceeded, metric reaching infinity underway, duplicate RID
• If it is, check whether the route has a non-infinite metric and FD
• Check which neighbors satisfy the Feasibility Condition
• In case Wide Metrics are used, check whether the calculated RIB metric
is less than 4,294,967,295 (232 – 1)
Troubleshooting
Route
Advertisement and
Convergence
Issues
Convergence in
EIGRP
Understanding Convergence
• There are three scenarios to consider:
• Feasible Successor provides the least CD after the topology change
• Feasible Successor does not provide the least CD or does not even exist
• When things don’t converge as you had planned
• Understanding your topology and the appropriate scenario is

essential to know where to look and what to look for
• Get up close and personal with your topology table and event-logs!
Convergence through a Feasible Successor
Feasible Successor is providing the new least CD
.2 .1
• Changing over to the Feasible B
Successor for a destination is a short,
10.200.1.0/24
constant time operation .1
.1 56K .2 .1 128K .2
.2
A 10.1.2.0/24 C 10.1.5.0/24 E
• Extremely fast, and linear convergence .1 .2
time based on prefix count

.2 .1
D
RtrA# show ip eigrp topology
[...]
P 10.200.1.0/24, 1 successors, FD is 21026560
Computed Reported
distance distance RD (20514560) < FD (21026560) = FS!
Convergence through a Feasible Successor
Feasible Successor is providing the new least CD
.2 .1
• Purely a local computation B
Look for “FC sat”
10.200.1.0/24
• .1 .2
.1 56K .2 .1 128K .2
A 10.1.2.0/24 C 10.1.5.0/24 E
.1 .2
RtrA# show ip eigrp event

[...] .2 .1
39 13:10:13.491 Route install: 10.200.1.0/24 10.1.3.2 D
40 13:10:13.487 Route install: 10.200.1.0/24 10.1.2.2
41 13:10:13.487 Send reply: 10.200.1.0/24 10.1.1.2
42 13:10:13.487 FC sat rdbmet/succmet: 46740736 20514560
43 13:10:13.487 FC sat nh/ndbmet: 10.1.2.2 21026560
44 13:10:13.487 Find FS: 10.200.1.0/24 21026560
45 13:10:13.487 Rcv query met/succ met: 4294967295 4294967295
46 13:10:13.487 Rcv query dest/nh: 10.200.1.0/24 10.1.1.2
Convergence through a Possible Successor
Feasible Successor is not providing the new least CD
.2 .1
• Slower than local computation B
Involves transitioning to Active
10.200.1.0/24
• .1 .2
state, sending out Queries, and A
.1 56K .2
10.1.2.0/24 C
.1 128K
10.1.5.0/24
.2
E
waiting for Replies before making .1 .2
the best path selection

RtrA# show ip eigrp topology all-links .2 .1
D
[...]
via 10.1.3.2 (46740736/46228736), Serial1/2
Possible successor
Computed Reported RD (46228736) is not < FD (21026560); NO FS

distance distance
Convergence through a Possible Successor
Feasible Successor is not providing the new least CD
.2 .1
• Look for “FC not sat”, “Active”, B
“Rcv reply”
10.200.1.0/24
.1 .2
.1 128K .2
A C 10.1.5.0/24 E
.1 .2
RtrA# show ip eigrp event
16 13:35:06.035 Route install: 10.200.1.0/24 10.1.3.2
17 13:35:06.035 Send reply: 10.200.1.0/24 10.1.1.2
18 13:35:06.035 Find FS: 10.200.1.0/24 4294967295 .2 .1
D
[...]
22 13:35:06.031 Rcv reply met/succ met: 46740736 46228736
23 13:35:06.031 Rcv reply dest/nh: 10.200.1.0/24 10.1.3.2
[...]
54 13:35:05.955 Metric set: 10.200.1.0/24 4294967295
55 13:35:05.955 Active net/peers: 10.200.1.0/24 1
56 13:35:05.955 FC not sat Dmin/met: 46740736 21026560
57 13:35:05.955 Find FS: 10.200.1.0/24 21026560
58 13:35:05.955 Rcv query met/succ met: 4294967295 4294967295
59 13:35:05.955 Rcv query dest/nh: 10.200.1.0/24 10.1.1.2
Stuck In Active
Diffusing Computations in EIGRP
• Diffusing Computation is a mechanism
for coordinated update of routing tables
among multiple affected routers
• Diffusing Computation grows by sending
Queries and shrinks by receiving Replies
• Once a router is Active and has sent
out Queries, it cannot become Passive,
nor make a best path choice before
receiving all Replies itself
Query Reply
• Query depth directly impacts the network
convergence time Active Passive
Query Propagation Boundaries
10.1.1.0/24
• When EIGRP goes Active, it sends a Query
to its peers looking for the lost route A B
• The Query is bounded by: Local Knowledge of

an alternate path, So
• Local knowledge of an alternate Reply
loop-free path not learned through C
the peer the query was received from
Filter
Summary
E No peers,
• No local knowledge of the route So Reply
because of filtering D G
• No local knowledge of the route No Knowledge of
Route, So Reply
because of summarization F
No Knowledge of
• No peers to query, or stub neighbors Route, So Reply
Excessive Delays in Diffusing Computation – SIA
• Diffusing Computations allow EIGRP to update routing tables in
a coordinated fashion, always atomically moving from one loop-free
path to another
• They are also EIGRP’s Achilles heel
• A router cannot conclude its best path selection until it receives Replies
from all queried neighbors – but they may in turn wait for their own peers
• Diffusing Computation creates a chain of interdependent routers
• A single misbehaving router can prevent the Diffusing Computation from
ever concluding, and the network will never converge
• This condition is called Stuck In Active
Stuck-In-Active Routes (SIA)
• SIA events are logged with a message similar to:
%DUAL-3-SIA: Route 10.255.255.1/32 stuck-in-active state in IP-EIGRP(0) 1.
Cleaning up
• There are two aspects to a SIA condition

• A route went to Active state
• It got stuck in that state
• By the time this message was logged, both ‘Active’ and ‘Stuck’
have already occurred
• Event logs are an important help in tracing down the root cause
Troubleshooting SIAs
• Troubleshooting SIAs requires focus on both aspects
• Why did the route go Active?
• Why did it remain stuck in that state?
• The reason for a route going Active can be entirely independent from the
cause of getting stuck in that state
• Need to troubleshoot both parts
• Cause of Active often easier to find
• Cause of stuck more important to find
Troubleshooting the Active Part of SIAs
• The fewer routes and less frequently go Active, the fewer of them
can get SIA (provided the network is even prone to SIAs)
• The only reason for a route to go Active is the increase of the distance
through the current Successor, and a lack of neighbor satisfying the FC
with the current FD that would provide the next shortest path
• These events are also treated as distance increase:
• Destination becoming disconnected from its first hop router
• Loss of a neighbor
• Adjacency reinitialization (for example due to configuration change)
Troubleshooting the Stuck Part of SIAs
• Once the SIA event has been logged, it is actually over
• The event of a route becoming Active and staying Active for “longer than
usual” though not yet arriving into SIA state is not logged
• The difficulty is in capturing the moment when the to-be-SIA route is still
Active but not before the SIA timer expires
• Use show ip eigrp topology active to display routes in
Active state
• Useful only while the problem is occurring
• If the problem isn’t occurring at the time, it is very difficult to find the
reason the routes are getting stuck
Chasing Active Routes
20.1.1.0/24
A B C D
10.1.1.0/24 10.1.2.0/24 10.1.3.0/24
.1 .2 .1 .2 .1 .2
Why Is RtrA Reporting SIA Routes?

Let’s Look at a Problem in Progress
RtrA# show ip eigrp topology active

A 20.1.1.0/24, 1 successors, FD is Inaccessible
1 replies, active 00:01:17, query-origin: Local origin
via Connected (Infinity/Infinity), Ethernet1/0
Remaining replies:
via 10.1.1.2, r, Ethernet0/0
RtrA Is Waiting on RtrB
20.1.1.0/24
A B C D
10.1.1.0/24 10.1.2.0/24 10.1.3.0/24
.1 .2 .1 .2 .1 .2
So Why Hasn’t RtrB Replied?
RtrB# show ip eigrp topology active

A 20.1.1.0/24, 1 successors, FD is Inaccessible
1 replies, active 00:01:26, query-origin: Successor Origin
via 10.1.1.1 (Infinity/Infinity), Ethernet0/0
Remaining replies:
via 10.1.2.2, r, Ethernet1/0
RtrB is Waiting on RtrC
20.1.1.0/24
A B C D
10.1.1.0/24 10.1.2.0/24 10.1.3.0/24
.1 .2 .1 .2 .1 .2
What’s RtrC’s Problem?
RtrC# show ip eigrp topology active

A 20.1.1.0/24, 1 successors, FD is Inaccessible, Qqr
1 replies, active 00:01:33, query-origin: Successor Origin, retries(1)
via 10.1.2.1 (Infinity/Infinity), Ethernet0/0, serno 20
via 10.1.3.2 (Infinity/Infinity), rs, q, Ethernet1/0, serno 19, anchored
RtrC Is Waiting on RtrD
20.1.1.0/24
A B C D
10.1.1.0/24 10.1.2.0/24 10.1.3.0/24
.1 .2 .1 .2 .1 .2
Why Isn’t RtrD Answering?
RtrD# show ip eigrp topology active

RtrD#
No active routes… back to RtrC!
20.1.1.0/24
A B C D
10.1.1.0/24 10.1.2.0/24 10.1.3.0/24
.1 .2 .1 .2 .1 .2
No; RtrC Is Still Waiting on RtrD; What’s the Deal?
RtrC# show ip eigrp topology active

A 20.1.1.0/24, 1 successors, FD is Inaccessible, Qqr
1 replies, active 00:01:52, query-origin: Successor Origin, retries(1)
via 10.1.2.1 (Infinity/Infinity), Ethernet0/0, serno 20
via 10.1.3.2 (Infinity/Infinity), rs, q, Ethernet1/0, serno 19, anchored
RtrC is waiting on RtrD
20.1.1.0/24
A B C D
10.1.1.0/24 10.1.2.0/24 10.1.3.0/24
.1 .2 .1 .2 .1 .2
We need to investigate and see why they don’t seem to agree about the active route
RtrC# show ip eigrp neighbors

IP-EIGRP neighbors for process 1
(sec) (ms) Cnt Num
0 10.1.3.2 Et1/0 13 00:00:14 0 5000 1 0
1 10.1.2.1 Et0/0 13 01:22:54 227 1362 0 385
Looks like something’s broken between RtrC and RtrD
20.1.1.0/24
A B C D
10.1.1.0/24 10.1.2.0/24 10.1.3.0/24
.1 .2 .1 .2 .1 .2
RtrC# ping 10.1.3.2
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.3.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Okay—we can’t ping; we need to fix this before EIGRP stands a chance of working
Troubleshooting the Stuck Part of SIAs
• It is not always this easy to find the cause of an SIA
• Sometimes you chase the waiting neighbors in a circle
• If so, summarize and simplify
• Easier after CSCdp33034 (circa 2000)
• SIA should happen closer to the location of the cause of the problem
• CSCul80747 – introduces a new ‘soft reset’ for the SIA condition.
Graceful Resync of the peer can be enabled by the soft-sia CLI
command
Likely Causes for Stuck-in-Active
• Bad or congested links
• MTU issues (may be difficult to isolate)
• Query range is too deep
• Excessive redundancy
• Overloaded router (high CPU, CoPP drops)
• Router memory shortage
• Software defects (seldom)
Minimizing SIA Routes
• Decrease query scope (involve fewer routers in the query process)
• Summarization (filters out knowledge of the route to upstream peer)
• Route filters (filters out knowledge of the route to upstream peer)
• Define spoke/edge routers as stubs (explicitly defined as non-transit
device)
• Run a Cisco IOS which includes CSCdp33034
• As an added bonus, consider running with the soft-sia reset
option, provided by CSCul80747
Summary
Problems
Summary Metrics
A
• In EIGRP, the metric of
a summary is based on the
metrics of its components 10.1.0.0/23
Cost 10
10.2.0.0/23
Cost 10
• EIGRP chooses the metric of

the lowest cost component B C
route as the metric of the

overall summary
10.1.0.0/24
10.1.1.0/24
10.2.0.0/24
10.2.1.0/24
Cost 10
Cost 20
Cost 10
Cost 20
Summary Metrics
A
• If the component from which the metric
was derived flaps, then summary
updates are required as well
10.1.0.0/23 10.2.0.0/23
• The summary is used to hide Cost 10
Cost 20
Cost 10
reachability information, yet changes to

the metric information causes the B C
routers beyond the summary to

perform work to keep up with the
10.1.0.0/24
10.1.1.0/24
metric changes
10.2.0.0/24
10.2.1.0/24
Cost 10
Cost 20
Cost 10
Cost 20
• There is processing overhead for
EIGRP to recalculate the summary
metric each time a component
changes
Summary Metrics—Solutions
A
• In recent EIGRP code, you can define
the summary-metric command in
router mode in order to specify the 10.1.0.0/23
metric to be used on the summary, Cost 10
regardless of the metrics of the B
component routes
• This is similar to defining the metric on
10.1.0.0/24
10.1.1.0/24
Cost 20
Cost 20
redistribution statements in router mode
• This eliminates metric churn downstream
as well as local processing
router eigrp ROCKS
address-family ipv4 autonomous-system 1
network 10.0.0.0
topology base
summary-metric 10.1.0.0 255.255.254.0 10000 100 255 1 1500
Summary Admin Distance
• Original summary Admin Distance
problem
0.0.0.0
• Default summary is defined on distribution A B
routers to spokes
• Internet access point provides 0.0.0.0
external for default route to the Internet
C
• AD of 5 for the summary is better than the
AD of 170 from the external EIGRP route, ip summary-address eigrp 1 0.0.0.0 0.0.0.0 200
so the Internet default route is rejected!
• So let’s just add the AD to the

summary! RtrA# sh ip route 0.0.0.0 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "eigrp 1", distance 5, metric 25600, candidate default path, type internal
• Since the summaries created on
RtrA and RtrB now have a worse 0.0.0.0
AD than the external route A B
received, the external route wins
and is propagated to RtrC
C
• Components of the summary are still
suppressed ip summary-address eigrp 1 0.0.0.0 0.0.0.0 200
• RtrC has equal cost paths to 0.0.0.0/0

D*EX 0.0.0.0/0 [170/409600] via 10.1.2.2, 00:00:10, Serial1/0
• But what happens if RtrA loses the [170/409600] via 10.1.1.1, 00:00:10, Serial0/0
path to the Internet?
• Since RtrA no longer has the
external route, it creates the local 0.0.0.0
summary route and advertises it to A B
RtrC
• Now RtrC receives an external route
from RtrB and an internal route from A C
• The route from RtrA wins! Now RtrC’s ip summary-address eigrp 1 0.0.0.0 0.0.0.0 200
default route points to A, who doesn’t D* 0.0.0.0/0 [90/409600] via 10.1.1.1, 00:00:10, Serial0/0
have access to the Internet and
maybe not even the company’s
intranet!
• How do you resolve this
problem? 0.0.0.0
A B
• Define the Admin Distance on the
summary as 255 instead of
something lower C
• The route will only be advertised
ip summary-address eigrp 1 0.0.0.0 0.0.0.0 255
if an exactly matching
internal/external route exists D*EX 0.0.0.0/0 [170/409600] via 10.1.2.2, 00:00:10, Serial1/0
while still suppressing subnets

• Note: Don’t use 255 for single-
homed remotes!
• Another way to resolve the
problem
• Don’t use summary admin A
0.0.0.0
B
distance if sending to dual-
homed remotes
• Instead, use distribute-list to
C
permit 0.0.0.0 to remotes with
floating static on remotes
ip route 0.0.0.0 0.0.0.0 10.1.1.1 200
ip route 0.0.0.0 0.0.0.0 10.1.2.2 200
router eigrp 1
distribute-list 1 out Serial0/0
!
access-list 1 permit 0.0.0.0
Summary Black Holes
10.1.1.0/24
C
• This network implements manual

summarization from the distribution A
routers RtrA and RtrB toward the
core RtrX
10.1.2.0/24
D
• These summaries represent all spoke
networks and links to the spokes X
• It normally doesn’t matter whether

RtrA or RtrB is used to reach an
address on a spoke from RtrX
10.1.3.0/24
B
E
ip summary-address eigrp 1 10.1.0.0 255.255.0.0
RtrX# sh ip route | sec 10.1.0.0

D 10.1.0.0/16 [90/307200] via 10.2.1.52, 00:02:01, Ethernet0/0
[90/307200] via 10.2.1.51, 00:02:01, Ethernet0/0
Summary Black Holes
10.1.1.0/24
C
• What happens if the RtrA to RtrC link

fails? A
• RtrX is still receiving the summary from
both RtrA and RtrB and may choose RtrA
10.1.2.0/24
as its path for packets going to 10.1.1.0/24 D
• The best matching route for 10.1.1.0/24 on

X
RtrA is the discard route to Null0 for the
entire 10.1.0.0/16 summary
• The traffic will be dropped at RtrA
10.1.3.0/24
B
E
RtrA# sh ip route 10.1.1.0

Routing entry for 10.1.0.0/16
Known via "eigrp 1", distance 5, * directly connected, via Null0
Summary Black Holes RtrA# sh ip ei to all | sec 10.1.1.0
via 10.1.10.53 (307200/281600), Eth0/1
• Possible Solutions via 10.1.20.52 (1587200/307200), Eth1/0
C
10.1.1.0/24
• Add a new link between RtrA and
RtrB without summarization
configured A
• Add a GRE tunnel between RtrA and
RtrB without summarization
10.1.2.0/24
D
configured
X
New Link, No Summarization

GRE Tunnel, No Summarization
10.1.3.0/24
B
E
Redistribution
Problems
Redistribution Metrics
• RtrA is redistributing 10.1.1.0/24 from RIP, 10.1.1.0/24 via RIP
but RtrB and RtrC do not see the route
router eigrp 100
• EIGRP topology table on RtrA also does not A redistribute rip
show the route although it is learned in RIB
What Metric Should I Use?
• Check whether RtrA has a redistribution
metric configured via either B
RtrB# show ip route 10.1.1.0
B#
• default-metric <metric>
• redistribute rip metric <metric>
RtrC# show ip route 10.1.1.0
• route-map used in redistribute rip statement RtrC#
C
• EIGRP, in general, will not invent the metric
components if they have not been specified
explicitly (exceptions apply)
• More precisely, EIGRP can derive the redistribution metrics itself for:
• redistribute connected – the egress interface metrics are taken
• redistribute static – the egress interface metrics are taken
• redistribute eigrp - 1:1 copy of the other EIGRP process metrics
• redistribute bgp – in MPLS L3VPNs if the original routes come from another
site of the same VPN and were learned from EIGRP
• Otherwise, it is mandatory to specify the redistribution metric explicitly
• On the redistribute statement, either via metric keyword, or in a route-map
• Or with the default-metric statement
• Better safe than sorry – always specify the metrics explicitly!
• Always use sensible redistribution metrics
• redistribute rip metric 1 1 1 1 1 will result in a very high initial
EIGRP metric that will further grow as the route is advertised
• Such metric is in risk of growing to a value that is considered an infinity
• Beyond a certain hop, the route would apparently stop being learned
• The particular value of the redistribution metric has meaning only if

there are multiple redistribution points to indicate preference
• No harm done if the metric is always specified using
• BW = 1000000 (1Gbps), D = 1, RLY = 255, L = 1, MTU = 1500
Static Route to Connected Interface
r32# show ip route
10.0.0.0/24 is subnetted, 3 subnets
• Another surprise you could hit C
D
10.1.2.0 is directly connected, Ethernet0/0
10.2.2.0 [90/281600] via 10.1.2.31, 00:19:20, Ethernet0/0
is not really a “problem” but D 10.1.1.0 [90/307200] via 10.1.2.31, 00:24:19, Ethernet0/0
could be unexpected r32
• A static route defined only with router eigrp 1
the egress interface may be

network 10.0.0.0
!
r31 ip route 10.2.2.0 255.255.255.0 null0
automatically redistributed
r31# show ip eigrp topology 10.2.2.0/24
This happens if the destination

IP-EIGRP (AS 1): Topology entry for 10.2.2.0/24
• State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256
network is covered by
Routing Descriptor Blocks:
0.0.0.0, from Rstatic, Send flag is 0x0
a network statement
Vector metric:
Minimum bandwidth is 10000000 Kbit
Total delay is 0 microseconds
Reliability is 0/255
Load is 0/255
Minimum MTU is 1500
Hop count is 0
Multiple Points of Redistribution
• A route is injected into EIGRP as an
external; this route is redistributed into
OSPF by RtrB
A
• The route is transmitted through OSPF to Metric 25 Metric 2560256
RtrA, who redistributes it back into EIGRP
EIGRP
OSPF
Metric
2688000
• Depending on the manually set metrics,
RtrB may prefer this redistributed route, Metric 10 Metric 2816000
building a routing loop B
• Depending on the timing, the loop can be
persistent or transient. Either way, a bad 10.1.1.0/24
thing!
Redistribution Design
• There are three primary methods used to prevent this routing loop:
• Redistributing live routing information in only one direction
• Filtering routes based on their prefixes
• Filtering routes using route tags
• The underlying goal is always the same

• Prevent routes from being injected into where they originally came from
• Using route tags is typically the most flexible approach
Multiple Points of Redistribution
Filtering Based on Tags
route-map usetags deny 10
• Set route tags when redistributing match tag 1000
between the protocols; deny tagged route-map usetags permit 20
set tag 1000
routes at the redistribution point
• The route is injected into EIGRP as an A
10.1.0.0/16
external; it is redistributed into OSPF Metric 25
10.2.0.0/16
EIGRP
OSPF
by RtrB and a tag is set
• The route is transmitted to RtrA Metric 10 Metric 2816000
through OSPF B
• The route is blocked from being 10.1.1.0/24
redistributed into EIGRP Metric 2560256
because of the route tag router ospf 100
redistribute eigrp 100 metric 10 route-map usetags
router eigrp 100

redistribute ospf 100 metric 1000 1 255 1 1500 route-map usetags
Additional
Propagation
Problems
Zero Successor Routes
10.10.10.10/32
• Zero successor routes happen
when EIGRP attempts to install RtrA# show ip eigrp topology
a route in the RIB and it is rejected A via Connected, Loopback0
• This normally occurs when there is RtrB# show ip eigrp topology

a route in the RIB with a better P 10.10.10.10/32, 0 successors, FD is Inaccessible
via 10.1.1.30 (409600/128256), Ethernet0/0
admin distance than EIGRP B RtrB# show ip route static
10.0.0.0/8 is variably subnetted
EIGRP must not (and will not)
S 10.10.10.10/32 [1/0] via 10.1.2.2
•
propagate zero successor routes
C
to peers RtrC# show ip eigrp topology | incl 10.10.10.10
RtrC#
Zero Successor Routes
RtrA# show ip eigrp 1 topology
via Connected, Loopback0
Another case of zero successor
10.10.10.10/32
• RtrA# show ip eigrp 2 topology
routes happens with overlapping via Connected, Loopback0
EIGRP Autonomous Systems A RtrB# show ip eigrp 1 topology

• If a prefix is known in both AS with via 10.1.1.30 (409600/128256), Ethernet0/0
RtrB# show ip eigrp 2 topology
the same AD, only one AS can P 10.10.10.10/32, 0 successors, FD is Inaccessible
via 10.1.1.30 (409600/128256), Ethernet0/0
install it in the RIB B
D
• The EIGRP AS that failed to install RtrD# show ip eigrp 2 topology | incl 10.10.10.10
it will not propagate the route to its C
RtrD#
peers RtrC# sh ip eigrp 1 topology

via 10.1.2.2 (435200/409600), Ethernet0/0
Duplicate Router ID
• A problem previously limited to 10.1.1.0/24 via RIP
redistributed routes happens when router eigrp 100

there are duplicate Router IDs A redistribute rip
default-metric ....
• Initially, only external routes were
signed with the redistributing router’s ID RtrB# show ip route 10.1.1.0
....
• With recent code, both internal and B 10.1.1.0/24 via [RtrA]
external routes carry their injecting
router’s ID RtrC# show ip route 10.1.1.0
RtrC#
• A router will ignore a route carrying the C
same Router ID
Duplicate Router ID
• In current versions of Cisco IOS software, the Router ID is listed in the
output of show ip eigrp topology and show eigrp protocols
router-1# show ip eigrp topology
• If your event log is large enough, or things are happening slowly enough,
you might also see the problem indicated in your event log
1 02:30:18.591 Ignored route, metric: 192.168.1.0 2297856

2 02:30:18.591 Ignored route, neighbor info: 10.1.1.0/24 Serial0/3
3 02:30:18.591 Ignored route, dup router: 192.168.1.1
Duplicate Router ID
• Router ID on internal routes has been introduced in EIGRP release 5
• To determine the EIGRP release, use show eigrp plugin
• If the command is rejected, you are definitely running older code
• If the command is accepted, look at the version of EIGRP in the output to
see if it is before or after release 5
RtrA# show eigrp plugin

EIGRP feature plugins:::
eigrp-release : 5.01.00 : Portable EIGRP Release
: 2.02.34 : Source Component Release(Portable EIGRP Release(rel5_1))
igrp2 : 3.00.00 : Reliable Transport/Dual Database
external-client : 1.02.00 : Service Distribution Client Support
[...]
EIGRP Router ID
• EIGRP chooses its Router ID when the process is first started
• The selection sequence is common as with other protocols
• Use the RID configured with eigrp router-id command
• If there is none, pick the highest IP address from among loopbacks
• If there is still none, pick the highest IP address from among all interfaces
• Once the RID is chosen, it won’t change even if the interface from
which it was borrowed is readdressed or removed
• Manual RID configuration would be required to override it
• Make it a habit to always use loopbacks with unique IPv4 addresses
Troubleshooting
Issues with
Specific EIGRP
Features
EIGRP Resource Depletion
• EIGRP by default will use up to 50% of the link bandwidth for EIGRP
packets
• This parameter is manually configurable on a per-interface basis using
the ip bandwidth-percent eigrp command
• Make sure that the bandwidth setting on an interface is always
realistic, especially for virtual interfaces
• Never, ever, use bandwidth to influence best path decisions
• Use delay if necessary to impact the metric on a deterministic basis
• Be careful not to set delay close to maximum – risk of infinite metric
Bandwidth over Multipoint Interfaces
• EIGRP over multipoint
interfaces such as DMVPN and
mGRE has to share the
available bandwidth among
peers
• EIGRP uses the bandwidth on the
main interface divided by the
number of neighbors on that
interface to get the bandwidth
available per neighbor
• Set the bandwidth on the multipoint interface to a value that most
closely defines the actual circuit speed and ability to deliver traffic
to the peers
• Don’t artificially scale the bandwidth configuration down or up for
traffic control!
• Use DMVPN Per-Tunnel QoS feature to control bandwidth along
with the ip bandwidth-percent eigrp command
• For DMVPN, other resources can also be depleted (and often are)
• Several processes are involved, each of which has overhead and can run
into resource depletion
• NHRP, IPsec, IKE, …
• Make sure interface queues and buffers are tuned to minimize/eliminate
drops
• Monitor EIGRP process queues for drops in large scale scenarios with
instability
• No way to adjust these queues, amount of information or pacing needs to be
adjusted via good summarization (with summary metrics!) or filtering
Monitoring EIGRP Resource Usage
show ip eigrp traffic
RtrB# show ip eigrp traffic
EIGRP-IPv4 VR(IWAN) Address-Family Traffic Statistics for AS(1)
Hellos sent/received: 822997/205769
Updates sent/received: 4/4
Queries sent/received: 1/1
Replies sent/received: 1/1
Acks sent/received: 6/4
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0
Hello Process ID: 632
PDM Process ID: 627
Socket Queue: 0/10000/2/0 (current/max/highest/drops)
Input Queue: 0/10000/2/0 (current/max/highest/drops)
• DMVPN/mGRE is a very popular technology which presents some
interesting challenges in troubleshooting and avoiding problems
• From an EIGRP perspective, the mGRE Tunnel interface is multicast
• In reality, the multicast packet is replicated by the NHRP/IP code into
multiple IP/GRE packets
• IPsec then encrypts these packets
• Each step along the way has queues and buffers and other
resources required to do the job of packet delivery
• Each of these resources are potential places of resource depletion
• Many commands are useful to see how DMVPN/mGRE are behaving
resource-wise
• show ip nhrp summary
• show ip nhrp multicast
• show ip nhrp traffic
• show buffers | include failures
• show interface tunnel 1 | include nput
• show interface gig 0/1 | include nput !!! Output interface of a tunnel
• show buffer input-interface gig 0/1 header
• show ip eigrp topo summary
• show ip eigrp traffic
• show ip eigrp interface detail tunnel 1
Problems with
Links > 1G
Problems with Links > 1G
Scaled Bandwidth Problem
• EIGRP was created in times when FastEthernet was considered fast
• In order to simplify metric calculation and comparison, bandwidth was

scaled
• Scaled Bandwidth is 107/BW (with BW in Kbps)
• This worked fine until the BW was 107 or smaller
• 10G is 107 in Kbps, so the scaled value becomes 107/107 or a value of 1
• If the interface bandwidth is > 10G, the value becomes 0
• 107/(107+X) is < 1 therefore value becomes 0 (integer math)
• While the code is smart enough to discount a BW value of 0 for the
calculation, it can still cause invalid routing decisions
Scaled Bandwidth Problem
C6K-MCORE-1# show interface port-channel 12
Port-channel12 is up, line protocol is up (connected)
[...]
MTU 9216 bytes, BW 20000000 Kbit, DLY 10 usec,
[...]
C6K-MCORE-1# show ip eigrp topology 10.1.1.0/30

EIGRP-IPv4 Topology Entry for AS(1)/ID(1.0.0.23) for 10.1.1.0/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256
Descriptor Blocks:
0.0.0.0 (Port-channel12), from Connected, Send flag is 0x0
Composite metric is (256/0), route is Internal
Vector metric:
Total delay is 10 microseconds
[...]
Delay Granularity Problem
• Interface delay values are defined by the core code
• EIGRP just pulls in the value provided by the infrastructure
• Just like EIGRP with scaled BW, the core code didn’t foresee such high BW
• 1 Gigabit – Delay is 10 microseconds
• Etc.
• Since EIGRP uses aggregate delay in path selection, this means trouble
• A 1G, 10G, and 20G link all look the same value and the 20G isn’t preferred
Path Selection
• Due to the problem with Scaled BW and Delay granularity, path
selection is negatively impacted
• Links could be seen as equal cost when they’re not
• Higher BW links are not preferred over lower BW links
• While this will not create routing loops, sub-optimal routing could
easily occur
Path Selection
10.1.1.0/24
• One example for all:
• RtrD sees one best path to reach
10.1.1.0/24 through RtrC A
10G
• The path taken is definitely worse B
1G
than the other, but EIGRP is not
C
aware and thus makes the wrong 10G
routing decision E 1G
10G
D
The Old Solution
• In the past, the only solution to this problem was to manually set the delay
• This wasn’t a good answer, mainly because it was administratively burdensome
and hard to design/implement
• We also saw cases where customers built in routing loops by changing the delay
values differently on different ends of the links!
• OSPF solved this a few years ago by defining a reference bandwidth that
should be set to the same value on all routers for consistent results
• This approach was not deemed viable for EIGRP
• How can we solve this elegantly?
The Solution
• EIGRP has implemented a feature called “Wide Metric” support which no
longer scales the BW and dynamically creates the delay in picoseconds
• This feature is backward compatible (though mixed environments can have
suboptimal routing)
• Implemented in EIGRP Release 8.0 and later (Release 28.0 is the latest)
• NOTE: Only available when configured in Named Mode!
• On by default when configured in Named Mode
• https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-
software/enhanced-interior-gateway-routing-protocol-
eigrp/whitepaper_C11-720525.html
The Solution
Router# show eigrp address-family ipv4 topology
EIGRP-IPv4 VR(WideMetric) Topology Entry for AS(4453)/ID(3.3.3.3) for 100.1.0.0/16
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 262144, RIB is 2048
Descriptor Blocks:
2.0.0.2 (Ethernet0/2), from 2.0.0.2, Send flag is 0x0
Vector metric:
Total delay is 3000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 100.1.1.1
Granularity Problem for Offset-lists between Classic and Wide Metrics
Before:
R2# show ip eigrp topology 10.1.23.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.1.21.1) for 10.1.23.1/24
10.1.23.0/24
State is Passive, Query origin flag is 1, 1 Successor(s),
FD is 307200 R1
Descriptor Blocks:
10.1.12.2 (Ethernet0/0), from 10.1.12.2, Send flag is 0x0 Release 12
…
R1#show run | sec router eigrp
router eigrp 100
After: network 10.0.0.0
R2# show ip eigrp topology 10.1.23.0/24 offset-list 10 out 1000
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.1.21.1) for R1#show run | sec access-list
10.1.23.0/24 access-list 10 permit any
R2
State is Passive, Query origin flag is 1, 1 Successor(s),
FD is 307200 Release 6
Descriptor Blocks:
10.1.12.2 (Ethernet0/0), from 10.1.12.2, Send flag is 0x0
…
Summary:
Troubleshooting
EIGRP Networks
Summary: Troubleshooting EIGRP Networks
• EIGRP contains many tools and techniques that can be used to
keep the EIGRP network running smoothly and efficiently
• What now?
• Armed with Information
• Preventative Steps
• Hopefully this session shared a couple of useful hints, tools, and

approaches to make the best use of these tools and techniques
and translate them in a manner which will be relevant to your
network design
Recommended Reading for BRKRST-2331
EIGRP Specific Reading
Open-EIGRP:
RFC 7868
ASIN: 1578701651 ISBN: 0201657732
Recommended Reading for BRKRST-2331
General Routing Reading, Including EIGRP
ISBN 1587051877 ISBN-13: 978-1587144639

ISBN-13: 978-1587144233
ISBN-10: 1587144638
Now an Open standard – RFC 7868! https://tools.ietf.org/html/rfc7868

Cisco Webex Teams
Questions?
Use Cisco Webex Teams to chat
with the speaker after the session
How
1 Find this session in the Cisco Live Mobile App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
Webex Teams will be moderated cs.co/ciscolivebot#BRKRST-2331

by the speaker until June 16, 2019.
#CLUS © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 126
Complete your
online session • Please complete your session survey
evaluation after each session. Your feedback
is very important.
• Complete a minimum of 4 session
surveys and the Overall Conference
survey (starting on Thursday) to
receive your Cisco Live water bottle.
• All surveys can be taken in the Cisco Live
Mobile App or by logging in to the Session
Catalog on ciscolive.cisco.com/us.
Cisco Live sessions will be available for viewing
on demand after the event at ciscolive.cisco.com.
Continue your education
Demos in the
Walk-in labs
Cisco campus
Meet the engineer

Related sessions
1:1 meetings
Thank you
#CLUS
#CLUS

T-Shoot EIGRP BRKRST-2331

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T-Shoot EIGRP BRKRST-2331

Uploaded by

Copyright:

Available Formats

#CLUS

Peter Palúch, CCIE Exam Program Manager

• Routing Table Updates • Packet captures

• Best Path Advertisement

• Reacting to Topology Changes

RtrA# show ip eigrp neighbors Last Reliable Packet Received

Seconds Remaining Before Declaring Neighbor Down

How Long Since the Last Time Neighbor Has Come Up

How Long It Takes for This Neighbor to Respond to Reliable Packets

How Long We’ll Wait Before Retransmitting if No Acknowledgement

R2# show ip eigrp neighbor detail

• Size of the topology table matters

R2# show ip eigrp neighbor detail

• Packet loss, congestion, CoPP, physical layer errors

“If you are closer to the destination

RtrA# sh ip eigrp topology sum

Interfaces with No Outstanding Packets to Be Sent or Acknowledged

known to EIGRP, their successors,

RtrA# show ip eigrp topology .2

known to EIGRP, their successors,

• This is due to Split Horizon

all paths received for a particular

metrics A 10.1.2.0/24 C 10.1.5.0/24 E

that fail to get installed in the

there is a route with a better A 10.1.2.0/24 C 10.1.5.0/24 E

• Understanding your topology and the appropriate scenario is

Successor for a destination is a short,

time based on prefix count

Look for “FC sat”

RtrA# show ip eigrp event

Involves transitioning to Active

the best path selection

Computed Reported RD (46228736) is not < FD (21026560); NO FS

• The Query is bounded by: Local Knowledge of

• There are two aspects to a SIA condition

Why Is RtrA Reporting SIA Routes?

RtrA# show ip eigrp topology active

RtrA Is Waiting on RtrB

So Why Hasn’t RtrB Replied?

RtrB# show ip eigrp topology active

RtrB is Waiting on RtrC

What’s RtrC’s Problem?

RtrC# show ip eigrp topology active

RtrC Is Waiting on RtrD

Why Isn’t RtrD Answering?

RtrD# show ip eigrp topology active

No active routes… back to RtrC!

No; RtrC Is Still Waiting on RtrD; What’s the Deal?

RtrC# show ip eigrp topology active

RtrC is waiting on RtrD

RtrC# show ip eigrp neighbors

Looks like something’s broken between RtrC and RtrD

RtrC# ping 10.1.3.2

Type escape sequence to abort.

• EIGRP chooses the metric of

route as the metric of the

reachability information, yet changes to

routers beyond the summary to

• So let’s just add the AD to the

• RtrC has equal cost paths to 0.0.0.0/0

path to the Internet?

while still suppressing subnets