RobRiker EIGRP

EIGRP
15.3 only commands

add-path
default-information allowed
eigrp upgrade cli - 15.4
Timers signal
Cisco proprietary
-both distance vector and link state behavior
-advanced distance vector
Features
-classless
supports vlsm and summarization
manual and automatic summarization
-Uses its own transport protocol
ip protocol 88
RTP reliable transport ptotocol
uses multicast to 224.0.0.10 and unicast
uses multicast to discover neighbors and form adjacencies
uses reliable multicast with sequence numbers and acknowledgements
unicast to synchronize unicast routing topology
-forms active neighbor adjacencies
guarantess packet delivery and supports partial updates
-Guarantees loop-free topology
we don't have a full copy of the database of the network
DUAL is performed to determine best routes
which paths are considered backup routes
-fast convergence
fastest of all IGPs in certain designs
EIGRP is faster because it has a known backup
-Granular metric
hybrid metric derived from multiple factors
-Unequal cost load balancing
only IGP that supports true load balancing
RIP, OSPF can equal cost load balance
-Secure neighbor adjacencies
Authentication is used to gaurantee nieghbor relationships
Supports MD5 in Classic Mode
Supports MD5 and HMAC-SHA 256 in Named Mode
Key chains are used to verify authentication and provide key rotation
-Traffic engineering and Optimization
Stub routing and summarization
ACL filtering and route manipulation
Forming adjacencies
Network command
Controls which interfaces are running the EIGRP process, does not
control which networks are being advertised.
Used to form adjacencies that use multicast address of 224.0.0.10 to
form the adjacency
network 155.1.45.5 0.0.0.0 means only the interfaces with 155.1.45.5
will run the EIGRP process and be able to form adjacencies
network 155.1.45.0 0.0.0.255 means any interface with 155.1.45.x will
be able to run the EIGRP process
the wildcard mask determines how much of the network 155.1.45.x
matters,
0 means it must match, 155.1.45 = 0.0.0 = the first 3
octets must be 155.1.45
255 means it doesn't matter, .x = 255 = the last octet can
be anything in that range 0-255, specifically 2-254
Neighbor command
uses the neighbor x.x.x.x outgoing interface command
This command alone under the routing process will not form an adjacency
Can be used to form adjacencies with other routers if multicast isn't
available for transit.
neighbor description - named mode

To associate a description with a neighbor
neighbor maximum-prefix - named mode

configured to protect an individual peering session or to protect
all peering sessions.
When this feature is enabled and the maximum-prefix limit has
been reached, the
router will tear down the peering session, clear all routes that
were learned from the peer, and then place the
peer in a penalty state for the default or user-defined time
period.
After the penalty time period expires, normal peering will be
reestablished.
Neighbors are discovered with hello packets

sent to 224.0.0.10 from primary IP address
you can't form neighborships on secondary IPs
neighbors must agree on
IPv4 subnet
ASN
authentication
metric weightings (k values)
Neighbors do not need to agree on timers
opposite of OSPF timer logic
Once neighbors are found, EIGRP update messages used to exchange routes
sent as multicast 224.0.0.10 or as unicast
Hello
multicast to 224.0.0.10 by default but can be configured to be unicast
contains parameters like k values and AS number
sent every 5 or 60 seconds depending on link type
broadcast - 5 second hello and 15 second hold
NBMA - 60 second hello and 180 second hold
Update messages describe attributes of a route
prefix and length
next hop value
bandwidth
delay
load
reliability
MTU
hop count
external/internal attributes
EIGRP router ID
If you receive your router ID you will discard the update to
prevent a loop
Acknowledgement
acknowledges receipt of update, query and reply messages via unicast
uses same opcode as hello
query
used to query neighbors to find paths to a destination
multicast to all neighboring routers initially, but unicast if
multicast fails
each query should be acknowledged and answered with a reply
Query mechanism
When a route fails, different things can happen depending on if the
router already knows about an alternate path or not
if a FS exists
install the best one into the routing table immediately and
send updates to neighbors about the new best path
if a FS does not exist
the router has gone into "active" mode and it will query
all EIGRP neighbors for the route
if the querying router is not the successor
reply with the route information or stating that it doesn't
know about the router
if the querying router is the current successor - queried router
lost its successor
if a feasible successor exists, install the FS route and
reply with the new route info
if a feasible successor does not exist - query all
neighbors
Stuck in active
eigrp routers must wait for a reply to each query message
in turn routers queried may need to go active, querying their neighbors
and also wait for those replies
this can create a domino effect, if a router doesn't hear a reply
within the active timer period, 3 minutes, the route goes stuck into
a stuck in active state
when a route goes stuck in active, the router brings down the neighbor
relationship with the router that did not reply to the query
reply
unicast back to the querying router in response to a query for a route
acknowledged with an ACK
Verifying EIGRP
verify neighbor adjacencies
show ip eigrp neighbors [detail]
queue count should be 0
veryify topology
show ip eigrp topology
all links, prefix/length
debug eigrp packet

this is an output of the multiprotocol implementation
debug ip eigrp
this is the ipv4/ipv6 implementation
debug eigrp fsm
The neighbor table records the IP address of the neighbor and the interface
on which the neighbor’s Hellos
are received.
R2#sh ip route 155.1.0.4

Routing entry for 155.1.0.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 1
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1
R2#sh ip ei neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO
Q Seq
(sec) (ms) Cnt Num

1 155.1.0.5 Tu0 10 00:10:43 1272 5000
0 44
0 155.1.23.3 Gi1/0.23 12 00:10:43 369 2214
0 59
R2#sh ip eigrp topology 155.1.0.0/24

EIGRP-IPv4 Topology Entry for AS(1)/ID(150.1.2.2) for 155.1.0.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 26880000
Descriptor Blocks:
0.0.0.0 (Tunnel0), from Connected, Send flag is 0x0
Composite metric is (26880000/0), route is Internal
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 50000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1400
Hop count is 0
Originating router is 150.1.2.2
R2#ping 150.1.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/152/200 ms
R2#trace 150.1.4.4
Tracing the route to 150.1.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 155.1.23.3 76 msec 44 msec 60 msec
2 155.1.13.1 120 msec 92 msec 132 msec
3 155.1.146.4 152 msec 152 msec 188 msec
H - The list of neighbors in the order they are learned, starting at 0.

Address - The IP address of the neighbor.
Interface - The interface via which the neighbor is learned.
Hold - The Hold timer for the neighbor. If it gets to 0, the neighbor is
down.
Uptime - Timer for how long the neighbor relationship has been up.
SRTT - This is the Smooth Round Trip Time, which is the time it takes to send
and receive a reliable EIGRP packet.
RTO - This is the Round Trip Timeout, which is the amount of time the router
will wait to retransmit
the EIGRP reliable packet if an Ack is not received.
Q Cnt – This is the number of EIGRP packets (Update, Query, and Reply) that
the software is waiting to send.
Seq Num – This is the sequence number of the last EIGRP reliable packets
being received from the neighbor.
This is to ensure that packets received from the neighbor are in order.
TCL Ping/traceroute scripts

TCL - tool command language is a CLI tool used to test reachability
everywhere in the network from any point in the network
Caveat - TCL is processed before the IOS CLI parser, once in TCL mode
all commands will processed in respect to TCL. The tclquit command
is needed to exit TCL mode and go back to the CLI parser
R2#tclsh
R2(tcl)#foreach ADDRESS {
+>(tcl)#150.1.1.1 <----- type in the address of the destination,
copy/paste won't work
+>(tcl)#155.1.0.1
+>(tcl)#155.1.13.1
+>(tcl)#155.1.146.1
+>(tcl)#} { ping $ADDRESS }
let the pings run, network failures are quickly detected by failed
pings
use the tclquit command to exit
R2(tcl)#tclquit
Did this on one router

R2(tcl)#foreach ADDRESS {
+>(tcl)#?
+>(tcl)#
+>(tcl)#150.1.1.1
+>(tcl)#155.1.0.1
+>(tcl)#} { ping $ADDRESS }
% Unrecognized host or address, or protocol not running.

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/105/120
ms
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 152/246/328
ms
Within the EIGRP packet header;
Version field - is 4-bit field used to indicate the protocol version of the
originating EIGRP router process.
The version has not changed since its release.
OPCode - is a 4-bit field that specifies the EIGRP message type,
1 = Update,
3 = Query,
4 = Reply,
5 = Hello,
6 = IPX SA,
10 = SIA Query,
11 = SIA Reply.
Checksum – is a 24-bit field that is used to run a sanity check on the EIGRP
packet itself.
This field is based on the entire EIGRP packet and not including the IP
header.
Flags – is a 32-bit field that is used to indicate either an INIT (when set
(0×00000001))
for a new EIGRP neighbor or for the Conditional Receive (CR) (second
bit (0×00000002)),
used in the proprietary Reliable Multicasting algorithm, for EIGRP
Reliable Transport Protocol. (RTP)
Flags - Defines special handling of the packet. There are currently two
defined flag bits.
Init Flag (0x01) - This bit is set in the initial UPDATE packet sent
to a newly discovered neighbor.
It requests the neighbor to download a full set
of routes.
CR Flag (0x02) - This bit indicates that receivers should only accept
the packet if they are in Conditionally Received mode.
A router enters conditionally received mode when it
receives and processes a HELLO packet with a Sequence TLV present.
RS (0x04) - The Restart flag is set in the HELLO and the init UPDATE
packets during the signaling period.
Thee router looks at the RS flag to detect if a
neighbor is restarting and maintain the adjacency.
A restarting router looks at this flag to determine
if the neighbor is helping out with the restart.
EOT (0x08) - The End-of-Table flag marks the end of the startup process
with a new neighbor.
A restarting router looks at this flag to determine
if it has finished receiving the startup UPDATE
packets from all neighbors, before cleaning up the
stale routes from the restarting neighbor.
Sequence – is a 32-bit field that contains sequence number used by RTP.

This is used to ensure orderly delivery of reliable
packets.
A value of 0 means that an acknowledgment is not required.
Acknowledgment – is a 32-bit field that contains the sequence number last
heard from the neighbor
to which the packet is being sent. A Hello packet with a nonzero ACK
field will be treated as an
ACK packet rather than as a Hello. Note that an ACK field will only be
nonzero if the packet itself
is a unicast because an acknowledgment are never multicast.
Autonomous System Number – is a 32-bit field that identifies the number of
the EIGRP domain.
Type/Length/Value (TLV) – is a 32-bit triplet field that is used to carry
route entries,
as well as provide EIGRP DUAL information. EIGRP supports several
different types of TLVs as follows;
- 0×0001 EIGRP Parameters (General TLV Types)
- 0×0003 Sequence (General TLV Types)
- 0×0004 Software Version (General TLV Types)
- 0×0005 Next Multicast Sequence (General TLV Types)
- 0×0102 IP Internal Routes (IP-Specific TLV Types)
- 0×0103 IP External Routes (IP-Specific TLV Types)
TLV Fields
TLVs (type-length-value) are not only found within EIGRP but can be found in
other protocols like IS-IS for one.
The type and length fields are fixed in size (typically 1-4 bytes), and
the value field is of variable size.
Type - A binary code, often simply alphanumeric, which indicates the kind of
field that this part of
the message represents.
Length - The size of the value field (typically in bytes)
Value - Variable-sized series of bytes which contains data for this part of
the message.
TLVs carry EIGRP management information. The Parameters of TLV that are used
to convey metric weights and
the hold time. The Sequence, Software Version, and Next Multicast
Sequence TLVs are used by the Cisco
proprietary Reliable Multicast algorithm. As it was mentioned earlier
TLV not only works with IP but also
IPX and Apple Talk. Each Internal and External Routes TLV contains one
route entry. Every Update, Query,
and Reply packet contains at least one Routes TLV. The Internal and
External Routes TLVs include metric
information for the route.
IP Internal Routes TLV
An internal route is a path to a destination within the EIGRP autonomous

system.
Next Hop – is the next-hop, neighboring router, IP address.

Delay – is the sum of the configured delays expressed in units of 10
microseconds.
A delay of 0xFFFFFFFF, or 256, indicates an unreachable route.
Bandwidth – is 256 x BW(min), or 2,560,000,000 divided by the lowest
configured bandwidth of any interface
along the route.
MTU – is the smallest Maximum Transmission Unit of any link along the route
to the destination.
This value is not used for the metric calculation.
Hop Count – is a number between 0×01 and 0xFF indicating the number of hops
to the destination.
A router will advertise a directly connected network with a hop count
of 0.
Reliability – is a number between 0×01 and 0xFF that reflects the total
outgoing error rates of the
interfaces along the route, calculated on a five-minute exponentially
weighted average. 0xFF indicates a
100 percent reliable link.
Load – is also a number between 0×01 and 0xFF, reflecting the total outgoing
load of the interfaces
along the route, calculated on a five-minute exponentially weighted
average. 0×01 indicates a minimally
loaded link.
Reserved – is an unused field and is always 0×0000
Prefix Length – specifies the number of network bits of the address mask.
Destination – is the destination address of the route.
IP External Routes TLV
An external route is a path that leads to a destination outside of the EIGRP

autonomous system and that
has been redistributed into the EIGRP domain.
Next Hop – is the next-hop IP address. On a multiaccess network, the router

advertising the route might
not be the best next-hop router to the destination. The Next Hop field
allows the “bilingual” router
to tell its EIGRP neighbors, “Use address A.B.C.D as the next hop
instead of using my interface address.”
Originating Router – is the IP address or router ID of the router that
redistributed the external route into
the EIGRP autonomous system.
Originating Autonomous System Number – is the autonomous system number of the
router originating the route.
Arbitrary Tag – may be used to carry a tag set by route maps.
External Protocol Metric – is the metric of the external protocol.
Reserved – is an unused field and is always 0×0000.
External Protocol ID – specifies the protocol from which the external route
was learned.
0×01 = IGRP,
0×02 = EIGRP,
0×03 = Static Route,
0×04 = RIP,
0×05 = Hello,
0×06 = OSPF,
0×07 = IS-IS,
0×08 = EGP,
0×09 = BGP,
0x0A = IDRP,
0x0B = Connected Link.
Flags – currently constitute just two flags. If the right-most bit of the
eight-bit field is set (0×01),
the route is an external route. If the second bit is set (0×02), the
route is a candidate default route
R10#sh ip eigrp traffic

EIGRP-IPv4 Traffic Statistics for AS(1)
Hellos sent/received: 140/138
Updates sent/received: 2/2
Queries sent/received: 0/0
Replies sent/received: 0/0
Acks sent/received: 1/2
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0
Hello Process ID: 274
PDM Process ID: 273
Socket Queue: 0/10000/1/0 (current/max/highest/drops)
Input Queue: 0/2000/1/0 (current/max/highest/drops)
EIGRP Packets
R10#debug eigrp packets ?
SIAquery EIGRP SIA-Query packets
SIAreply EIGRP SIA-Reply packets
ack EIGRP ack packets
all Display all EIGRP packets
hello EIGRP hello packets
query EIGRP query packets
reply EIGRP reply packets
request EIGRP request packets
retry EIGRP retransmissions
stub EIGRP stub packets
terse Display all EIGRP packets except Hellos
update EIGRP update packets
EIGRP Auto summary

Like Rip v2 EIGRP is classless but does automatic classful summarization by
default
15.x IOS code and later releases, Auto summary is disabled by default
disabled with no auto summary under EIGRP process
VLSM is supported within the same major network
Advertisements between major network boundaries are summarized to classful
boundary
will not result in traffic black hole due to discard route
uses a null route or discard route to prevent a blackhole
EIGRP won't advertise a route to get back to itself to prevent a loop
It will drop updates that is directly connected
If you have auto-summary enabled, a discard or null0 route will be locally

generated to prevent loops.
D 150.1.0.0/16 is a summary, 00:00:08, Null0
if you were to try to ping R4's loopback IP address from R5
R5#ping 150.1.4.4
Sending 5, 100-byte ICMP Echos to 150.1.4.4, timeout is 2
seconds:
.....
It fails, traffic is being null routed
Shutdown the loopback on R5, the null route is removed
D 150.1.0.0/16
R5#ping 150.1.4.4
Sending 5, 100-byte ICMP Echos to 150.1.4.4, timeout is 2
seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =
48/90/120 ms
The ping succeeds because the route is not being null routed, it is
being routed via EIGRP
EIGRP Split Horizon

Always on
undesired in partial mesh NBMA
Disabled at interface level
no ip split horizon eigrp #
Wont cause a loop due to DUAL feasibility condition
is used to clean up and make updates more efficient
EiGRP will only advertise what's installed in the routing table
•Split-horizon behavior is turned on by default.
•When you change the EIGRP split-horizon setting on an interface, all
adjacencies with EIGRP neighbors reachable over that interface are reset.
•Split-horizon should typically be disabled only on non-broadcast multi-
access interfaces.
•The EIGRP split-horizon behavior is not controlled or influenced by the ip
split-horizon command.
To configure split-horizon for an EIGRP address family,
use the split-horizon command in address-family interface configuration
mode.
When using DMVPN in the network, the hub router interface connecting to the
DMVPN network, the interface must have split horizon disabled
EIGRP Named Mode

EIGRP Multi-AF Mode, EIGRP Named Mode, is an enhancement to the EIGRP syntax
format introduced in IOS release 15.0.
In EIGRP Classic Mode, EIGRP Autonomous System Mode, syntax was fragmented
between the global process and the interface level.
Furthermore, syntax at the interface level did not follow a strict hierarchy
in its command structure.
With EIGRP Multi-AF mode, all configuration is now consolidated to the global
process.
In EIGRP Named Mode, the name of the EIGRP process is any locally significant
string.
The address-family configuration specifies which particular AF EIGRP is
configured in,
such as IPv4,
the sub-address-family identifier (SAFI),
such as unicast,
the routing table,
such as global or VRF,
and the autonomous system.
Furthermore, any commands that were previously issued at the interface level,
such as no ip split-horizon eigrp,
are now configured under the af-interface mode, with the specific
interface denoted
Attributes that are global to the EIGRP process are either configured under
the SAFI itself or under the topology base,
assuming that Multi-Topology Routing (MTR) is not being used
In addition to the syntax parser change, EIGRP Wide Metric scaling is

automatically enabled when EIGRP runs in Named Mode.
This can be seen from the delay value now being measured in picoseconds in
the EIGRP topology, as well as the RIB scaling factor seen below:
R1#show eigrp address-family ipv4 100 topology 150.1.2.2/32

EIGRP-IPv4 VR(MULTI-AF) Topology Entry for AS(100)/ID(150.1.1.1) for
150.1.2.2/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is
10485841920, RIB is 81920640
Descriptor Blocks:
155.1.0.5 (Tunnel0), from 155.1.0.5, Send flag is 0x0
Vector metric:
Total delay is 60001250000 picoseconds
Load is 1/255
Minimum MTU is 1400
Hop count is 2
155.1.13.3 (GigabitEthernet1.13), from 155.1.13.3, Send flag is 0x0
Vector metric:
Total delay is 60011250000 picoseconds
Load is 1/255
Minimum MTU is 1400
Hop count is 3
If you are running EIGRP in classic mode and would like to move Mulit-AF
mode, there are two ways to do this, depending on the IOS version your running
15.3 and below, you will have to disable EIGRP Classic mode and enable
EIGRP named mode, Classic and Named mode can not run the same ASN
for 15.4 and above, you can issue the eigrp upgrade-cli NAME under
router configuration mode
After conversion, the running configuration on the device will show only
named mode configurations; you will be unable to see any classic
mode configurations.
This command is available only under EIGRP classic router configuration mode.
You must use the eigrp upgrade-cli command for every classic router
configuration in order to ensure that this configuration is
upgraded to named mode.
Therefore, if multiple classic configurations exist, you must use this
command per autonomous system number.
Both Classic and Named mode are completely compatible with each other, R1 can
run Classic mode and R2 can run Named mode and exchange routes
Named Mode specific changes - any command with default is all interfaces
enter AF ipv4/v6
af-interface Enter Address Family interface configuration
default Set a command to its defaults
eigrp EIGRP Address Family specific commands
exit-address-family Exit Address Family configuration mode
help Description of the interactive help system
maximum-prefix Maximum number of prefixes acceptable in
aggregate
metric Modify metrics and parameters for address
advertisement
neighbor Specify an IPv4 neighbor router
network Enable routing on an IP network
no Negate a command or set its defaults
nsf Non-stop forwarding
remote-neighbors Specify IPv4 service remote neighbors
EIGRP Over The Top
shutdown Shutdown address family
timers Adjust peering based timers
topology Topology configuration mode
topology base is the global routing table

auto-summary Enable automatic network number
summarization
default-information Control distribution of default information
default-metric Set metric of redistributed routes
distance Define an administrative distance
distribute-list Filter entries in eigrp updates
eigrp EIGRP specific commands
exit-af-topology Exit from Address Family Topology
configuration mode
fast-reroute Configure Fast-Reroute
maximum-paths Forward packets over multiple paths
metric Modify metrics and parameters for
advertisement
offset-list Add or subtract offset from EIGRP metrics
redistribute Redistribute IPv4 routes from another
routing protocol
snmp Modify snmp parameters
summary-metric Specify summary to apply metric/filtering
timers Adjust topology specific timers
traffic-share How to compute traffic share over alternate
paths
variance Control load balancing variance
af-interface
add-paths Advertise add paths
authentication authentication subcommands
bandwidth-percent Set percentage of bandwidth percentage limit
bfd Enable Bidirectional Forwarding Detection
dampening-change Percent interface metric must change to cause
update
dampening-interval Time in seconds to check interface metrics
exit-af-interface Exit from Address Family Interface
configuration mode
hello-interval Configures hello interval
hold-time Configures hold time
next-hop-self Configures EIGRP next-hop-self
passive-interface Suppress address updates on an interface
shutdown Disable Address-Family on interface
split-horizon Perform split horizon
EIGRP Topology
show ip eigrp all-links
show ip eigrp prefix/length
All routes learned from all neighbors make up the EIGRP topology table
Once topology is learned DUAL runs to choose loop-free best path to
each
destination
best path has the lowest composite metric
Composite metric calculated from
administrative weighting
bandwidth
delay
load
reliablility
Path with lowest composite metric is considered best and installed in
IP routing table
Only best route is advertised to other EIGRP neighbors
Will only advertise route it will use
One or more backup routes can also be pre calculated per destination
Neighbor, topology and routing table - Feasibility condition
Multitopology capabilities
mutiple topology configurations are available in EIGRP
Base is the default routing environment that exists prior to enabling
MTR
multitopology routing needs to be enabled before you can route
between mutliple topologies
You can have base, the global process and up to 31 additional unicast
topologies and a separate multicast topology
topologies are separated from each other by use of the TID, topology ID
and can share the same physical medium
topologies are handled in IOS based on their DSCP values and are
forwarded based on those values
-Loop Prevention
guarantees loop free topology through
split horizon
dont advertise routes out the link they came in on
Can can issues on hub and spoke or partial mesh topologies
DUAL feasibility condition
if your metric is lower than mine you are loop free
-Reconvergence
Active EIGRP neighbor adjacnecy reduces convergence time
adjacent neighbors hello packets contain hold time
if no hello is received with hold time, neighbor declared
unreachable
Neighbor is lost
paths via that neighbor are removed from topology and routing
table
if backup routes exist, they become the new best paths and are
inserted
into the routing table
in this case EIGRP can have sub second convergence
No quesry and reply if backup route exists
if no backup route exists, the DUAL is ran again
When best path is lost and no backup routes exist, route goes into
active state and active timer starts
stable routes not in active state are considered passive or
routing
Query message is reliably sent to remaining neighbors asking if there
is an alternate route
query is propagated to all neighbors with EIGRP query domain or
flooding domain
if there is a change in the topology, how many routers do I have
send query messages
summarization and EIGRP stub feature limits the query
domain
Stub is not a transit network, hub and spoke, spokes are
stubs
Reply packet
neighbors that respond to queries with a reply packet indicate an
alternate
route is available
if alternate route exists, DUAL recalculates new best path
if no alternate route, prefix is removed from topology
table
if active timer expires and no reply received, route is
declared
stuck in active and removed from the topology table
IP Fast ReRoute
reduce the routing transition time to less than 50 ms by
precomputing repair paths or backup routes and installing these paths or
routes in the Routing Information Base (RIB).
Fast Reroute (FRR) is the mechanism that enables traffic that
traverses a failed link to be rerouted around the failure.
Only paths that are reachable through point-to-point interfaces
are protected.
IPv6 is not supported.
A loop-free alternate (LFA) is a precomputed next-hop route that
delivers a packet to its destination without looping back.
Traffic is redirected to an LFA after a network failure and the
LFA makes the forwarding decision without any knowledge of the failure.
Per-link (link-based) computation:

In link-based LFAs, all prefixes (networks) that are
reachable through the primary (protected) link share the same backup information.
This means that the whole set of prefixes sharing the
primary link also share the repair or the Fast Reroute (FRR) ability.
The per-link approach protects only the next-hop address.
It need not necessarily protect the destination node
Per-prefix (prefix-based) computation:
Prefix-based LFAs allow computing backup information per
prefix (network) and protect the destination address.
The per-prefix approach is preferred over the per-link
approach because of its greater applicability and better bandwidth utilization.
Per-prefix computations provide better load sharing and
better protection coverage than per-link computations because per-prefix
computations evaluate all possible LFAs and use tie-
breakers to select the best LFA from among the available LFAs.
EIGRP always computes prefix-based LFAs. EIGRP uses the Diffusing

Update Algorithm (DUAL) to calculate the successor and
feasible successors.
EIGRP uses the successor as the primary path and feasible
successors as repair paths or LFAs.
NOTE - The repair or backup information computed for a primary

path by using prefix-based LFAs may be different from that computed by using link-
based LFAs.
LFA Tie-Breaking Rules

When there are multiple candidate LFAs for a given primary
path,
EIGRP uses a tie-breaking rule to select one LFA per
primary path per prefix.
A tie-breaking rule considers LFAs that satisfy certain
conditions or have certain attributes.
EIGRP uses the following four attributes to implement tie-
breaking rules:
Interface-disjoint—
Eliminates LFAs that share the outgoing interface with the
protected path.
Linecard-disjoint—
Eliminates LFAs that share the line card with the protected
path.
Lowest-repair-path-metric—
Eliminates LFAs whose metric to the protected prefix is
high.
Multiple LFAs with the same lowest path metric may remain
in the routing table after this tie-breaker is applied.
Shared Risk Link Group (SRLG)-disjoint—
Eliminates LFAs that belong to any of the protected path
SRLGs.
SRLGs refer to situations where links in a network share a
common fiber (or a common physical attribute).
If one link fails, other links in the group may also fail.
Therefore, links in a group share risks.
Disabling Load Sharing Among Prefixes

When the primary path is an Equal Cost Multipath (ECMP)
path with multiple LFAs, prefixes (networks) are distributed equally
among the LFAs because the default behavior for ECMP paths
is load sharing.
However, you can control the selection of LFAs by enabling
tie-breaking configurations.
To enable tie-breaking configurations, you should disable
load sharing among prefixes.
Perform this task to disable load sharing among prefixes.
Enabling Tie-Breaking Rules for EIGRP LFAs

Perform this task to enable tie-breaking rules to select a
single loop-free alternate (LFA) when there are multiple LFAs for a
given primary path.
EIGRP allows you to use four attributes to configure tie-
breaking rules.
Each of the following keywords of the fast-reroute tie-
break command allows you to configure a tie-breaking rule based on a
specific attribute:
interface-disjoint,
linecard-disjoint,
lowest-backup-path-metric,
srlg-disjoint.
You can assign a priority value for each attribute.
Tie-breaking rules are applied on the basis of the priority
assigned to each attribute.
The lower the assigned priority value the higher the
priority of the tie-breaking attribute.
EIGRP Dampening - Change

When a peer metric changes on an interface that is configured
with the dampening-change command, EIGRP
multiplies the dampening-change percentage with the old peer
metric and compares the result (the threshold)
to the difference between the old and new metrics. If the metric
difference is greater than the calculated
threshold, then the new metric is applied and routes learned from
that peer are updated and advertised to other
peers. If the metric difference is less than the threshold, the
new metric is discarded.
There are exceptions that will result in an immediate update
regardless of the dampening-change setting:
• An interface is down.
• A route is down.
• A change in metric which results in the router selecting
a new next hop.
Peer metric changes that do not exceed a configured change
percentage and that do not result in a routing
change do not result in an update being sent to other
adjacencies. Peer metric changes are based on the stored
last-update of the peer. Peer metric changes that exceed the
threshold value are stored and used for future
comparisons.
EIGRP Dampening - Interval

When a peer metric changes on an interface that is configured
with a dampening interval, EIGRP will apply
the metric change only if the time difference since the last
metric changed exceeds the specified interval. If
the time difference is less than the specified interval, the
update is discarded.
There are exceptions that result in an immediate update
regardless of the dampening interval settings:
• An interface is down.
• A route is down.
• A change in metric that results in the router selecting a
new next hop.
Time interval, in seconds, that must elapse before a route change
will cause an update to occur.
Value range is 1 to 65535.
If an interval value is not specified, the default is 30 seconds.
log-neighbor-changes
The log-neighbor-changes command enables the logging of neighbor
adjacency changes to monitor the stability
of the routing system and to help detect problems.
log-neighbor-warnings
The time interval (in seconds) between repeated neighbor warning
messages.
The range of seconds is from 1 through 65535.
you can disable and enable the logging of neighbor warning
messages and configure the interval
between repeated neighbor warning messages.
match extcommunity
The match extcommunity command is used to configure match clauses
that use extended community attributes in route maps.
All of the standard rules of match and set clauses apply to the
configuration of extended community attributes.
R10#sh ip eigrp topology ?

A.B.C.D Network to display information about
A.B.C.D/nn Prefix <network>/<length>, e.g., 192.168.0.0/16
active Show only active entries
all-links Show all links in topology table
detail-links Show all links in topology table
frr Show frr in topology table
pending Show only entries pending transmission
summary Show a summary of the topology table
zero-successors Show only zero successor entries
| Output modifiers
<cr>
EIGRP Update types

EIGRP uses multicast and unicast
hello, query, update etc. muticast to 224.0.0.10
update, ack, reply, etc. unicast to neighbor
neighbor statment disables multicasts

it also disables listening for multicast updates
implies that all neighbors must agree
disables sending and receiving of multicasts
if neighbor statements are used, all router interfaces that will become
adjacent need to have the neighbor statment
passive interface stops both unicast and multicast hellos

implies no adjacencies on passive links
the neighbor statement enables unicast adjacency

the network statement is still needed to enable EIGRP on the interface,
no network statement, no adjacency will form
EIGRP Timers
hello interval
how often i send hellos on a link
ip hello interval eigrp ASN # of seconds
holdtime
how long you should wait to declare me down
is used to control the remote neighbor
opposite of OSPF hello and dead interval
for NBMA its 180 by default, all others 15
ip hold time eigrp ASN # of seconds
Timers don't have to match for adjacency to form
stuck in active
how long the router will keep routes in the active state
timers active time | minutes | disabled router command
AF Timers
timers nsf signal
default value is 20 seconds
Only entered on a NSF capable routers
The EIGRP process starts a signal timer when it is notified of a
switchover event.
Hello packets with the RS bit set are sent during this period.
The converge timer is used to wait for the last end-of-table
(EOT) update if all startup updates have not been
received within the signal timer period.
If an EIGRP process discovers no neighbor, or if it has received
all startup updates from its neighbor within
the signal timer period, the converge timer will not be
started.
timers graceful-restart purge-time - replaced the timers nsf route-hold
The default is 240 seconds
The route-hold timer sets the maximum period of time that the
NSF-aware router will hold known routes for
an NSF-capable neighbor during a switchover operation or a
well-known failure condition.
The route-hold timer is configurable so that you can tune network
performance and avoid undesired effects,
such as “black holing” routes if the switchover operation takes
too much time.
When this timer expires, the NSF-aware router scans the topology
table and discards any stale routes,
allowing EIGRP peers to find alternate routes instead of
waiting during a long switchover operation.
timers nsf converge
The default converge timer is 120 seconds
The timers nsf converge command is entered only on an NSF-capable
router to wait for the last EOT update
if all startup updates have not been received within the
signal timer period.
If an EIGRP process discovers no neighbor, or if it has received
all startup updates from its neighbor within
the signal timer period, the converge timer will not be
started.
EIGRP Bandwidth
by default EIGRP can only utilize 50% of the link bandwidth, as specified by
the bandwidth configured on the interface
this is configurable with the ip bandwidth percent eigrp interface
command
EIGRP will use up to 50 percent of the bandwidth of a link, as defined by the
bandwidth interface configuration command.
This command may be used if some other fraction of the bandwidth is desired.
Note that values greater than 100 percent may be configured.
EIGRP Route Authentication

uses key chains like RIP v2
whitespace counts as a character (pressing spacebar before, during or
after the key is entered)
key number must match
key is configured in global config, applied at the interface level
supports automatic key rotation
based on the time of day, accept lifetime and send lifetime
device clocks must me sync'd, if there off, authentication will
fail
applied at interface level
ip authentication mode eigrp ASn md5 | hmac-sha 256
ip authentication key chain eigrp ASn key chain
one debug is key chain is missing or off
key not defined or not live
the other is key chain is wrong, invlaid authentication
router perfers lowest key number if multiple keys configured
EIGRP Time Based Authentication

Key chain supports multiple key numbers
router always sends lowest valid key
key numbers validity is based on time
accept lifetime
when is key valid to be received
send lifetime
when is key valid to be sent
Automatic rotation by defining different validity timers
implies time must be agreed upon
accept life time should overlap in case of mismatch of time
To prevent any issues with authentication with time differences, use the
highest numbered key as the last resort key
EIGRP/SAF HMAC-SHA-256 Authentication

EIGRP also supports the Hashed Message Authentication Code-Secure Hash
Algorithm-256 (HMAC-SHA-256) authentication method.
shared secret key is configured on all devices attached to a common network.
For each packet, the key is used to generate and verify a message digest
that gets added to the packet.
The message digest is a one-way function of the packet and the secret key.
The device sending a packet calculates the hash to be sent based on the
following:
• Key part 1—the configured shared secret.
• Key part 2—the local interface address from which the packet will be
sent.
• Data—the EIGRP packet to be sent (prior to the addition of the IP
header).
The device receiving the packet calculates the hash for verification based on
the following:
• Key part 1—the configured shared secret.
• Key part 2—the IPv4 or IPv6 source address in the IPv4 or IPv6 packet
header.
• Data—the EIGRP packet received (after removing the IP header).
For successful authentication, all of the following must be true:
• The sender and receiver must have the same shared secret.
• The source address chosen by the sender must match the source address
in the IP header that the receiver receives.
• The EIGRP packet data that the sender transmits must match the EIGRP
packet data that the receiver receives.
Authentication cannot succeed if any of the following is true:
• The sender does not know the shared secret expected by the receiver.
• The IP source address in the IP header is modified in transit.
• Any of the EIGRP packet data is modified in transit.
Config
3. router eigrp virtual-name
4. Enter one of the following:
• address-family ipv4 [multicast] [unicast] [vrf vrf-name] autonomous-
system [autonomous-system-number]
• address-family ipv6 [unicast] [vrf vrf-name] autonomous-system
[autonomous-system-number]
5. network ip-address [wildcard-mask]
6. af-interface {default | interface-type interface-number}
7. authentication mode {hmac-sha-256 encryption-type password | md5}
https://www.ciscolive.com/online/connect/flowPlayer.do?
url=http://d2zmdbbm9feqrf.cloudfront.net/2013/usa/BRKRST-2444.mp4
EIGRP DUAL How Path Selection is figured out

Choose path with lowest composite metric
bandwidth
inverse lowest bandwidth along path in Kbps scaled by 10^7*256
whatever is the slowest link is the link speed
delay
cumulative delay along path in tes of microseconds scaled by 256
delay is 100, the calc. 10 10s of microseconds
load
highest load along path
Reliability
lowest reliability along path
Metric Calculation
Composite metric is computed
Route with lowest metric is the Successor
route with lowest end to end metric
this route is installed in the routing table
Successors metric is the feasible distance
Metric weighting
K values allow for manual adimistrative weighting
default k1 and k3
implies default composite is bandwidth and delay
Can be modified with metric weights command
must match for adjacency to occur
all routers participating in that AS, their metrics must
match
Terms in detail
successor
best path to a destination
Feasible distance
composite metric of best path
feasible successor
backup path to a destination
advertised distance
composite metric learned by neighbor
this is the upstream routers metric for the best path
local distance
composite metric to reach local neighbor
feasibility condition
criteria for valid back path
Path selection in detail
Advertised distance
each update includes the metric the upstream router uses to reach
destination
Local distance
local router knows the metric to reach upstream router
advertised distance and local distance
best path (successor) is chosen based on lowest AD and LD
Feasibility Condition
once best path is chosen, additional paths are examined for backup
routes
feasibility condition finds loop free back route via
if AD < FD, path is loopfree and viable backup
if your metric is lower than mine, you are closer to destination
and loop free
Paths that meet the FC and FS
only feasible successor can be used for unequal cost load
balancing
EIgrp only knows about its directly connected neighbor, all other paths
are learned
serno is a pointer to a doubly linked serial number for the route.

This is used by an internal (and proprietary) mechanism for tracking
the correct route
information in a rapidly changing topology.
show ip eigrp topology
P 172.22.71.208/29, 2 successors, FD is 46163456
via 172.30.1.42 (46163456/45651456), Serial0.2, serno 7539273
via 172.30.2.49 (46163456/45651456), Serial2.6, serno 7539266
Serno stands for serial number. When DRDBs are threaded to be sent, they are
assigned a serial number.
If you display the topology table at the time an entry is threaded, it
shows you the serial number associated with the DRDB.
Threading is the technique used inside the router to queue items up for
transmission to neighbors.
The updates are not created until it is time for them to go out
the interface.
Before that, a linked list of pointers to items to send is
created (for example, the thread).
These sernos are local to the router and are not passed with the
routing update.
EIGRP supports 3 protocol suites: IP, IPv6, and IPX. Each of them has its own
PDM. These are the primary functions of PDM:
PDM - defines the type and format for the destination data. In EIGRP,
each address family is implemented as a PDM - Protocol Dependent modules
Maintaining the neighbor and topology tables of EIGRP routers
that belong to that protocol suite
Building and translating protocol specific packets for DUAL
Interfacing DUAL to the protocol specific routing table
Computing the metric and passing this information to DUAL; DUAL
handles only the picking of the feasible successors (FSs)
Implement filtering and access lists.
Perform redistribution functions to/from other routing protocols.
It contains all destinations advertised by neighboring routers.
Associated with each entry are the destination address and a list of
neighbors that have advertised this destination.
For each neighbor, the advertised metric is recorded.
This is the metric that the neighbor stores in its routing table.
H - The list of neighbors in the order they are learned, starting at 0.

Address - The IP address of the neighbor.
Interface - The interface via which the neighbor is learned.
Hold - The Hold timer for the neighbor. If it gets to 0, the neighbor
is down.
Uptime - Timer for how long the neighbor relationship has been up.
SRTT - This is the Smooth Round Trip Time, which is the time it takes
to send and receive a reliable EIGRP packet.
RTO - This is the Round Trip Timeout, which is the amount of time the
router will wait to retransmit the EIGRP reliable
packet if an Ack is not received.
Q Cnt – This is the number of EIGRP packets (Update, Query, and Reply)
that the software is waiting to send.
Seq Num – This is the sequence number of the last EIGRP reliable
packets being received from the neighbor.
This is to ensure that packets received from the neighbor are in
order.
EIGRP metric calculation

metric - EIGRP use a composite metric based on the following formula
[k1*bandwidth+(k2*bandwidth)/(256-load)+k3*delay]*-[k5/(reliability+k4)]
bandwidth
delay
reliability
load
k values
mtu has nothing to do with calculation
k values
clearly we have 5 variables in the equation labeled k1-5 in addition to
other variables like
bandwidth, delay, reliability and load
what exactly are these k values and what are they used for
k values are nothing more that numbers from 0-255
k values simply define how important the other variables are,
bandwidth, delay, reliability and load
by scaling them, multiplying them by an integer
k values are not equal to the variables they help scale
by default k1 and k3 equal 1 and k2, 4 and 5 are equal to 0
we can manipulate k values with the metric weights EIGRP command
if k5 is 0, the last section of the equation is not taken into account
it is 0 by default, by default the last section of the equation
is not considered in a calculation
the variable bandwidth really means 256*(10^7/minimum bandwidth in
kbps)
the variable delay really means 256* cumulative delay along the path in
tens of microseconds
reducing the formula
metric by default
[1*bandwidth+(0-bandwidth)/256-load)+1*delay]
this can be reduced more
(bandwidth+delay) =
bandwidth = 256*(10^7/minimum bandwidth in kbps)
delay = 256* cumulative delay in tens of microseconds
metric = 256*((10000000/min bandwidth)+delay)
Dly - 2*65536=128256
BW - 10000000 *65536 / 1000000
30000000
19660890000000
Offsetting the metric, metric now and subtract it by the needed metric
and the result is your offset
Wide Metrics Calculation

Classic calculation
BW=10^7*256/interface bandwidth + the cumulative delay end to
end, 10's of microsecnds
Wide Metrics calculation
BW=10^7*65536/Interface BW + delay in picoseconds = Dly=delay in
pico's*65536/10^6
BW is now throughput
Throughput = K1 * (EIGRP BW * Wide scale) / Interface bandwidth
in kbps
Delay is now latency
Latency = K3 * (delay * wide scale) / Delay in pico
Default metric is still the same formula
metric = (k1 * min (throughput)) + (k3 * sum(latency))
Backwards compatible with old (legacy) metrics calculation
RIB Scaling
IOS RIB only supports 32 bit metrics
After DUAL is ran the metric is scaled down to fit in the RIB
Default is to scale * 1/128
Modified with the metric rib-scale command
Metric manipulation
By default EIGRP uses only bandwidth and delay to calculate its composite
metric, as K1=K3=1 and K2=K4=K6=0.
Load, reliability and extended attributes can also be used, or the ratio at
which bandwidth and delay are used can be changed,
by modifying the metric weights.
Specifically, the calculation is as follows for Classic EIGRP which uses a
32-bit metric:
Metric = 256*[(K1*Scaled Bw) + (K2*Scaled Bw)/(256 - Load) + (K3*Scaled
Delay)]*[K5/(Reliability + K4)]
The calculation is as follows for EIGRP Named mode which uses a 64-bit
metric:
Metric = [(K1*Minimum Throughput + (K2*Minimum Throughput/(256-Load) +
(K3*Total Latency) + (K6*Extended Attributes)]* [K5/(K4 + Reliability)]
If K5 equals zero, the second half of the equation is ignored in both cases.
modify interface parameters

calculations are always done on the inbound interface
bandwidth, delay, load, reliability
modify k values with metric weights command
configure off set lists
offset lists allow us to modify the metric for a particular prefix in
or out, to or from the router by a specific value
Metric holddown
The holddown state keeps new routing information from being used
for a certain period of time.
This function can prevent routing loops caused by slow
convergence.
metric maximum-hops
This command provides a safety mechanism that breaks any
potential count-to-infinity problems.
It causes the IP routing software to advertise as unreachable
routes with a hop count greater than the value assigned to
the hops-number argument.
metric rib-scale
Scaling value for the RIB installation.
The range is from 1 to 255.
The default value is 128.
metric weights
Use this command to alter the default behavior of EIGRP routing
and metric computation and to allow the
tuning of the EIGRP metric calculation for a particular
type of service (ToS).
Router Configuration
metric weights tos k1 k2 k3 k4 k5
tos Type of service. This value must always be zero.
no metric weights
Address Family Configuration

metric weights tos [k1 [k2 [k3 [k4 [k5 [ k6 ]]]]]]
no metric weights
Per the RFC, Loading is the most greatly effected at 90% or greater
Changing load and reliability metrics will effect the routing metric based on
how much traffic is being sent/received
load interval is a 5 minute average by default, modifying this to a
lower time value will cause EIGRP to calculate the load at a faster
average
EIGRP Wide Metrics - EIGRP wide metrics are sent with a TLV version of 2
EIGRP composite cost metric is not scaled correctly for high-bandwidth
interfaces resulting in incorrect or inconsistent routing behavior
The lowest delay that can be configured for an interface is 10 microseconds.
High-speed interfaces
10 Gigabit Ethernet interfaces
high-speed interfaces channeled together gig etherchannel appear to
EIGRP as a single GE interface
This may cause undesirable equal-cost load balancing
To resolve this issue
EIGRP Wide Metrics feature supports 64-bit metric calculations and
(RIB) scaling
This provides the ability to support interfaces
either directly or via channeling techniques like port channels up to
approximately 4.2 terabits
The 64-bit metric calculations work only in EIGRP named mode configurations.
EIGRP classic mode uses 32-bit metric calculations.
The EIGRP Wide Metrics feature also introduces K6 as an additional K value

for future use.
EIGRP wide metrics introduce the following two new metric values represented
as k6 in the EIGRP metrics configuration:
•Jitter—(Measured in microseconds) accumulated across all links in the
route path.
Routes lower jitter values are preferred for EIGRP path
selection.
•Energy—(Measured in watts per kilobit) accumulated across all links in
the route path.
Routes lower energy values are preferred for EIGRP path
selection.
EIGRP prefers a path with no jitter or energy metric values or lower
jitter or metric values over a path with higher values.
By default, the path selection scheme used by EIGRP is a combination of

throughput and latency
formula for calculating the composite cost metric is as follows:
Composite Cost Metric = (K1*Minimum Throughput) + (K3*Total
Latency)
Minimum Throughput = (107* 65536)/Bw), where 65536 is the wide-
scale constant.
Total Latency for bandwidths below 1 gigabit = (Delay*65536)/10,
where 65536 is the wide-scale constant.
Total Latency for bandwidths above 1 gigabit = (10^7* 65536/10)/
Bw, 65536 is the wide-scale constant.
Issues found with Wide metrics

EIGRP can no longer fit the computed metric into a 4-byte unsigned long
value that is needed by the Cisco RIB
To set the RIB scaling factor for EIGRP, use the metric rib-scale
command.
When configured the metric rib-scale command
EIGRP routes in the RIB are cleared and replaced with the
new metric values.
Bandwidth is lowest bandwidth along the path on a per prefix basis

essentially the bandwidth bottleneck
hard to predict what a modification will affect
delay is cumulative on a hop by hop basis
easier to influence path selection with
delay interface command
any modification done in the K values need to be the same for all
neighbors in the path to be engineered
If you want a route to use a specific route,
you need to make sure that the interface directly connected needs
to be the destination is the interface pointing to the destination
all routers in the path need to be modified so that the interface
pointing to the destination is the one being installed in the routing table
starting at the destination interface and making sure that the
interfaces connecting the path are the proper interfaces being installed
in the routing table
Scalability
EIGRP can achieve sub second reconvergence through use of backup routes
backup routes are feasible successors if they pass the feasibility
condition
If my metric is X to the destination, if your metric to X is lower your
a feasible successor
if my metric is X to the destination, if your metric to X is higher
your not a FS
if no backup routes a Query message is sent
asks other neighbors for an alternate path
reply message needs to come in before the route is withdrawn from the
routing table
if no reply is received, it becomes stuck in active, the adjacencies
need to be reset to reconverge
Query domain can be bounded by
summarization | stub routing | route filtering | segment into multiple
processes, query messages only propagate through a single AS
can occur anywhere since it's only exchanging routes with it's
neighbors
not exchanging the full topology with all router in the AS
it not only reduces the size of the routing table
it also reduces the size of the query domain
ip summary address eigrp x.x.x.x x.x.x.x and the administrative
distance at the link level
supports any bit boundary including 0.0.0.0/0
automatically suppresses subnet advertisements
can advertise subnets though leak map argument
administrative distance defaults to 5
allows for floating summaries
automatically generates discard route
can be removed with the AD of 255
the discard route or null0 is for aggregate routes
where 2 /24 routes are
summarized as a single /23, if one of those routes go
down the router will not
continue to forward packets to the down subnet.
EIGRP hierarchary is arbitrary
You can summarize anywhere in the network
Summarization pitfalls
Churning subnets due to metrics changing means the summary will
be churning
Change of best subnet metric means summary must be re
advertised
Summary-metric in Named mode can mitigate this

metric is statically defined per summary in topology base
if the subnet metric changes that won't affect the
summaries metric
Query Scoping
If a query goes out, and there is 1 route that goes down, a
single query for a single route update is sent everywhere
A query and replay is needed on every router for that route
that is in the AS
If a query goes out, and there is multiple routes that go down, a
query for every single route update is sent everywhere
A query and replay is needed on every router for each route
that is in the AS
Traffic Engineering with summaries

EIGRP automatically suppresses subnet advertisements of summaries
Since EIGRP hierarchy is arbitrary, selective summaries can be
used for traffic engineering
longest match route is always preferred
implies router performing the summary is less preferred
Summarization
The /summary-address (EIGRP) command is used to configure interface-
level address summarization.
EIGRP summary routes are given an administrative distance value of 5.
The administrative distance metric is used to advertise a summary
address without installing it in the routing table.
Like RIP, EIGRP supports summarization at the interface level anywhere
throughout the topology, but it does not have the
limitation of being unable to summarize beyond the classful
boundary.
When a summary is configured in EIGRP, all subnets that make up the
summary are suppressed from being advertised out the link.
From a design perspective, this feature can be used to both reduce the
size of the routing table and limit the scope of EIGRP query messages.
Summarization with default routes
Summarization can also be used to originate a default route in EIGRP.
The disadvantage of this configuration, however, is that all subnets
previously advertised out an interface will be suppressed,
because all IPv4 networks are a subnet of the aggregate 0.0.0.0/0
Summarization with Leak Maps
The EIGRP leak-map feature of the summary-address allows the
advertisement of specific subnets encompassed by the interface-level summary,
similar to the unsuppress-map feature of BGP aggregation.
Routes matched in the leak-map route-map will be advertised in addition
to the summary.
If the route-map matches all routes, all subnets of the aggregate will
be advertised in addition to the aggregate.
This is useful in cases where you want to originate a default route
with the interface summary-address,
but you don’t want to stop the advertisement of specific subnets.
leak maps allow you to advertise a single subnet in a summary, so the summary
and the more specific route get advertised
prefix list WORD subnet and prefix length
route map that matches the subnet referenced in the prefix list
apply the leak map at the end of the summary route with the leak map on
the interface you want to engineer the traffic
goes down the leak map will allow for a more specific route while still
maintaining the summary
IP Prefix list NAME

route map that calls the prefix list
leak map tacked on the end of the summary address
Advertise a summary of a default and the loopback subnet of the

directly connected neighbor and the subnets the summarizing router EIGRP is on
route map NAME - no match or set statements, matches everything
summary address with leak map tacked on with the route map name
ip summary address eigrp 100 0.0.0.0/0 leak map NAME <-
route map name
Floating Summarization
When summaries are created in EIGRP, OSPF, and BGP, the router
automatically installs a route to Null0 to match the summary.
This is used to prevent the router from forwarding traffic for
destinations inside the summary that it does not have a longer match for.
However, in certain designs this can be an undesirable behavior.
To resolve this, EIGRP sets its interface-level summaries to have an
administrative distance of 5 by default.
This means that any other route with a distance of 1–4 will take
precedence over the summary.
Poisoned Floating summarization

Routes with an administrative distance of 255 are not candidates to be
installed in the routing table.
By poisoning the interface-level summary with a distance of 255, the
route to Null0 cannot be installed locally in the
routing table, but the summary itself can be advertised out the
interface.
In previous IOS codes (before 15.x), the distance was configured along
with the interface-level summary,
in newer IOS codes it is globally configured at the process level
using command summary-metric <prefix> distance <value>.
From a design perspective, this configuration is for cases in which you
want the router to forward traffic for destinations inside
the summary that it does not have a longer match for.
In previous IOS codes (before 15.x), the router performing the
summarization would still adertise the summary in its EIGRP updates,
even though AD of 255 was configured which prohibited the router
to install it in the routing table.
In newer IOS codes, the summary is no longer advertised if poisoned
with AD of 255, but it is active as all routes comprised within
the summary are no longer advertised out on the interface sumamry
is configured on.
Stub Routing
stub router advertisement
reduces size of EIGRP query domain
stub routers dont receive query messages
stub routers aren't used for transit
normally...
good design for DMVPN spokes
process level eigrp stub arguments
what types of prefixes are advertised
arguements control what router advertises
defaults to connected routes and summary routes
stub routers are not designed as transit routers
can be transit with the leak map command
it has 3 main benefits

improved network stability
stub routers are not queried by neighbors going active on
routers
stub routers reply to query with inaccessible message
stub routers prevent the stub from becoming a transit router
reduces resource utilization

no need for stub router to process query messages
very limited amount of routes are sent from the stub upstream
simplifies stub router config

stub router configuration automates the processes you would
normally have to do manually, route filtering
Config
on the stub
eigrp stub - by default will only advertise connected and
summary routes
connected
advertises connected routes
redist
advertise routes redistributed to this router
summary
advertise summary|summarized routes
static
advertise static routes
receive only
will only receive routes that are advertised,
won't advertise any routes
leak map
advertise routes that exist behind the stub
Leak maps advertising all specific routes

Leam maps advertising summarized specific routes
Load balancing
equal cost
traffic is load balanced out equal cost paths
default is 4 paths and can be changed with the maximum paths command
Some IOS code supports up to 32 equal cost paths
unequal cost
taffic can be portionally balanced out unequal cost paths
EIGRP allows load distribution among unequal paths
controlled by variance command
Feasible distance * variance > feasible successor, load balancing
occurs
only feasible successors are candidate for load balancing
Automatically calculated traffic share counter causes links to be used
in ratio proportional to their composite metrics
actual load balancing still controlled by switching path
process and fast switching can do per packet load balancing
where CEF goes based on flow, TCP and UDP for next hop and the
adjacency
if you want per packet load balancing, ip packet load balancing
under the interface
The FC Advertised Distance must be less than my FD in order to be
considered a FS and be candidate for UECLB
traffic sharing
when eigrp performs unequal cost load balancing, traffic is
proportionally distributed across the links based on metric
the default behavior based on the default command is traffic share
balanced
traffic share min across interfaces modifies the default behavior
the unequal cost paths up to the maximum allowed paths that is
configured will all be in the routing table, but
traffic will only be sent out the best path
reason-convergence time
Reconvergence differes for paths with or without a FS

Paths without a FS
loss of successor sends route into active state
send quesry to all neighbors
reconverged when reply heard from all neighbors
Paths with a FS
loss of successor does not make route active
feasible successor promoted to successor
query not generated
result is sub second convergence
Convergence is the time for the FIB to remove the lost successor and
install the FS into the FIB as the successor
BW and Delay modification until the the FS falls inside the feasibility
condition to be a backup route
BFD - bidirection forwarding detection, lower layer ping to determine

neighbor failure
Traffic Engineering
Manipulating AD
two general way to change AD
change AD for all EIGRP routes
distance eigrp | internal AD | external AD
change AD for EIGRP routes learned from a specific source
manipulate AD for all routes learned from a specific
source
manipulate AD for some routes learned from a specific
source
-distance AD source wc mask ACL-
acl can be standard name or numbered
extended acl may not be useful
this will not work for external routes
we can not change the AD for a specific
EIGRP external route, all or nothing
EIGRP over DMVPN

Split horizon
next hop processing
Split Horizon
EIGRP is Distance Vector
Split horizon rule is still use
dont advertise an update back out the interface it was
learned on
Why would you not want SH

Partial Mesh NBMA
DMVPN is partial mesh in some implementations
Caveats with the Named Process

Some routes may not get installed into the routing table
due to the scaling factor associated with the wide metrics
The AS mode scale is 256 where redist. a route with a
metric string of 1 1 1 1 1 was fine and it worked
the MAF mode scale is 65536 where redist. a route with a
metric string of 1 1 1 1 1 1 won't work as the metric will viewed as infinite
The tunnel interface on the hub should be set to the same

of the physical interface
Internet routing doesn't support multicast, if a spoke wants to

send an update it sends the update to 224.0.0.10 to the hub
The hub can't send multicast updates, updates are sent as
reliatble unicast
the hub would have to send replicated unicast updates to each
spoke to receive the update, 1 update per route
Implies if 10 routes are being updated, each spoke would
receive 10 individual updates from the hub
The best practice is to have the hub advertise a default route to

all spokes so the updates from the spoke is avoided
Next hop processing

EIGRP updates includes next hop forwarding address
the next hop for the route
If zero, use the IP address from the received IP header
next hop is who you learned the route from
Why would you not want to do this
third party next hop
DMVPN phase 2
This is DMVPN Phase 2

Use the af-interface command no next hop self, this modifies the
hub to not advertise the hubs IP address but rather the
originating routers IP address
Essentially when R3 advertises R7s Loopback to R5, R1 learns this

in and the IP to route traffic is now R3s IP on DMVPN not R5s IP
DMVPN Phase 3
You can go to the hub and use the nhrp redirect and nhrp shortcut
commands to let NHRP resolve the address
If you advertise a default route from the hub to the spokes
The shortcut/redirect options let the spoke with the
default route ask the hub for the next hop
Once the NHRP resolves the next hop, you will no longer
route to the hub you'll route to the spoke
NHRP will install, while valid, a NHRP route in the in the
routing table, once the route expires the route to the spoke will be removed
Default routing
supports default routing two ways
candidate default network
ip default network x.x.x.x
native advertisement of 0.0.0.0/0 prefix
default network must be
dynamically learned through EIGRP
not directly connected
classful network
limited application due to these restrictions
default-information command in EIGRP does not behave the same as other
protocols
no default information in, you will not receive any default routes in
no default information out, you will receive default information but
you will not not propagate information out
Exterior routes are always accepted and default information is passed
between EIGRP processes when redistribution occurs.
native default advertisement
native 0.0.0.0/0 network can be advertised
static default route to an interface and network 0.0.0.0 under
EIGRP process
redistribution from static or another protocol
summarization
Inbound route filtering
distribute list
standard access list
extended access list
source is route source, destination is prefix
source is in the "from" section of a route
std and extd ACL for filtering data plane
can match on the route but not on the
prefix lengths
prefix list
offset list
distance
255=infinite
can be per prefix and per neighbor
route map
cannot apply it to a neighbor or the process
metric filter
route tag filter
Router ID
used for external\internal loop prevention, depending on the version of IOS
code
don't accept self originated external routes
if external EIGRP has a lower administrative distance than the
protocol you are redistributing from, it could cause a loop
duplicate router ids can result in traffic black holes
these routers will not accept external routes
can be manually specified with eigrp router id x.x.x.x under the process
The router ID is used to identify the originating router for external routes.
If an external route is received with the local router ID, the route is
discarded.
The router ID can be configured with any IP address with two exceptions;
0.0.0.0 and 255.255.255.255 are not legal values and cannot be entered.
A unique value should be configured for each router.

In EIGRP named IPv4, named IPv6, and Cisco Service Advertisement Framework
(SAF) configurations,
the router-id is also included for identifying internal routes and loop
detection.
Redistribution
when redistributing into EIGRP, we must set the metric
default metric command
redistribute command itself
you could use a route map and set the metric that way
redistribution can be made conditional or much more specific by using route
maps
when redistibuting from OSPF, we can use the match command to match specific
OSPF LSA types
redistributed routes into EIGRP are external routes and get an AD of 170
Redistributed protocols can have metric applied 2 ways
default metrics command and the K values set, any protocol
redistributed inherits these metrics
metric command, on a per redistribution basis, OSPF can be one set of
values, RIP can be another
EIGRP Add-Path
Prerequisites for Add Path Support in EIGRP - 15.3
All interfaces in EIGRP topology are by default configured with the next-hop-
self command.
This command enables EIGRP to set the local outbound interface as the next-
hop value while advertising a route to a peer
even when advertising routes out of the interface on which the routes
were learned
This default EIGRP behavior may interfere with the add-paths command that
helps configure the Add Path Support in EIGRP feature
before you configure this feature on a hub device in a Dynamic
Multipoint VPN (DMVPN) domain,
you must disable the next-hop-self command that is configured on the
hub interface that connects to spokes in the DMVPN domain.
Restrictions for Add Path Support in EIGRP

• The Add Path Support in EIGRP feature can be enabled only in (EIGRP) named
mode configurations.
• The variance command should not be configured when the Add Path Support in
EIGRP feature is enabled.
The variance command alters the metrics of routes in an EIGRP topology
thereby enabling
EIGRP to balance traffic among desired paths.
Therefore, if you configure the variance command on a hub device, the
command may interfere with the configuration of this feature.
EIGRP Add Path Support Overview

In most DMVPN domains, two or more spokes are connected to the same LAN
segment.
In a single DMVPN domain, a hub connects to all spokes through one tunnel
interface.
In EIGRP topologies, when a hub has more than one path (with the same metric
but through different spokes) to reach the same network,
both paths are chosen as best paths.
However, by default, EIGRP advertises only one path as the best path to
connected spokes.
With the implementation of the Add Path Support in EIGRP feature, hubs in an
EIGRP-DMVPN
domain can advertise up to four additional best paths to connected spokes,
thereby allowing load balancing
and path redundancy.
This feature supports both IPv4 and IPv6 configurations.
Configuring IPv4/v6 Add Path Support on a Hub

SUMMARY STEPS
1. enable
2. configure terminal
4. address-family ipv4/v6 autonomous-system as-number
5. af-interface {default | interface-type interface-number}
6. no next-hop-self [no-ecmp-mode]
7. add-paths number
8. end
9. show running-config
EIGRP MIB Overview

The EIGRP MIB feature provides MIB support in Cisco software for (EIGRP)
routing processes that run over IPv4 and IPv6.
The EIGRP MIB is accessed through remote (SNMP) software clients.
MIB table objects are accessed as read-only through GETBULK, GETINFO,
GETMANY, GETONE, and GETNEXT requests.
Counters for MIB table objects are cleared when the EIGRP routing process is
reset or when the routing table is refreshed when you
enter the clear ip route or clear ip eigrp command.
Managed objects for all EIGRP routing processes are implemented as five table
objects—
EIGRP Interface, EIGRP Neighbor, EIGRP Topology, EIGRP Traffic
Statistics, and EIGRP VPN—on a per-autonomous-system or per-VPN basis.
SUMMARY STEPS
1.enable
2.configure terminal
3.snmp-server host {hostname|ip-address} [traps | informs | version {1 | 2c |
3 [auth | noauth | priv] community-string [udp-port port] [notification-type]
4.snmp-server community string
5.snmp-server enable traps [notification-type]
6.end
7.show running-config
EIGRP MPLS VPN PE-CE Site of Origin

Prerequisites for EIGRP MPLS VPN PE-CE Site of Origin
This document assumes that Border Gateway Protocol (BGP) is configured in the
network core (or the service provider backbone).
The following tasks will also need to be completed before you can configure
this feature:
•This feature was introduced to support the MPLS VPN Support for EIGRP
Between Provider Edge and
Customer Edge feature and should be configured after the EIGRP MPLS VPN
is created.
•All PE routers that are configured to support the EIGRP MPLS VPN must
run a Cisco IOS release that
provides support for the SoO extended community.
Restrictions for EIGRP MPLS VPN PE-CE Site of Origin

•If a VPN site is partitioned and the SoO extended community attribute
is configured on a backdoor
router interface, the backdoor link cannot be used as an alternate path
to reach prefixes originated in
other partitions of the same site.
•A unique SoO value must be configured for each individual VPN site.
The same value must be configured
on all provider edge and customer edge interfaces (if SoO is configured
on the CE routers) that support
the same VPN site.
EIGRP MPLS VPN PE-CE Site of Origin Support Overview

The EIGRP MPLS VPN PE-CE Site of Origin feature introduces SoO support for
EIGRP-to-BGP and BGP-to-EIGRP redistribution.
The SoO extended community is a BGP extended community attribute that is used
to identify routes that have originated from a
site so that the readvertisement of that prefix back to the source site
can be prevented.
The SoO extended community uniquely identifies the site from which a PE
router has learned a route.
SoO support provides the capability to filter MPLS VPN traffic on a per-
EIGRP-site basis.
SoO filtering is configured at the interface level and is used to manage MPLS
VPN traffic and to prevent routing loops from occurring
in complex and mixed network topologies, such as EIGRP VPN sites that
contain both VPN and backdoor links.
The configuration of the SoO extended community allows MPLS VPN traffic to be
filtered on a per-site basis.
The SoO extended community is configured in an inbound BGP route map on the
PE router and is applied to the interface.
The SoO extended community can be applied to all exit points at the customer
site for more specific filtering but must be
configured on all interfaces of PE routers that provide VPN services to
CE routers.
Site of Origin Support for Backdoor Links

The EIGRP MPLS VPN PE-CE Site of Origin (SoO) feature introduces support for
backdoor links.
A backdoor link or a route is a connection that is configured outside of the
VPN between a remote and main site; for
example, a WAN leased line that connects a remote site to the corporate
network.
Backdoor links are typically used as back-up routes between EIGRP sites if
the VPN link is down or not available.
A metric is set on the backdoor link so that the route though the backdoor
router is not selected unless there is a VPN link failure.
The SoO extended community is defined on the interface of the backdoor
router.
It identifies the local site ID, which should match the value that is used on
the PE routers that support the same site.
When the backdoor router receives an EIGRP update (or reply) from a neighbor
across the backdoor link, the router checks the
update for an SoO value.
If the SoO value in the EIGRP update matches the SoO value on the local
backdoor interface, the route is rejected and not added
to the EIGRP topology table.
This typically occurs when the route with the local SoO valued in the
received EIGRP update was learned by the other VPN site and then
advertised through the backdoor link by the backdoor router in the
other VPN site.
SoO filtering on the backdoor link prevents transient routing loops from
occurring by filtering out EIGRP updates that contain
routes that carry the local site ID.
If a VPN site is partitioned and the SoO extended community attribute is

configured on a backdoor router
interface, the backdoor link cannot be used as an alternate path to reach
prefixes originated in other
partitions of the same site.
If this feature is enabled on the PE routers and the backdoor routers in the
customer sites, and SoO values are
defined on both the PE and backdoor routers, both the PE and backdoor routers
will support convergence
between the VPN sites. The other routers in the customer sites need only
propagate the SoO values carried
by the routes, because the routes are forwarded to neighbors. These routers
do not otherwise affect or support
convergence beyond normal Diffusing Update Algorithm (DUAL) computations.
Router Interoperation with a Site of Origin Extended Community

The configuration of an SoO extended community allows routers that support
the EIGRP MPLS VPN PE-CE
Site of Origin feature to identify the site from which each route originated.
When this feature is enabled, the
EIGRP routing process on the PE or CE router checks each received route for
the SoO extended community
and filters based on the following conditions:
•A received route from BGP or a CE router contains a SoO value that
matches the SoO value on the receiving interface.
If a route is received with an associated SoO value that matches the SoO
value that is configured on the
receiving interface, the route is filtered because it was learned from
another PE router or from a backdoor
link. This behavior is designed to prevent routing loops.
•A received route from a CE router is configured with an SoO value that
does not match.
If a route is received with an associated SoO value that does not match the
SoO value that is configured on
the receiving interface, the route is added to the EIGRP topology table so
that it can be redistributed into BGP.
If the route is already installed to the EIGRP topology table but is
associated with a different SoO value, the
SoO value from the topology table will be used when the route is
redistributed into BGP.
•A received route from a CE router does not contain an SoO value.
If a route is received without a SoO value, the route is accepted into the
EIGRP topology table, and the SoO
value from the interface that is used to reach the next hop CE router is
appended to the route before it is
redistributed into BGP.
When BGP and EIGRP peers that support the SoO extended community receive
these routes, they will also
receive the associated SoO values and pass them to other BGP and EIGRP peers
that support the SoO extended
community. This filtering is designed to prevent transient routes from being
relearned from the originating
site, which prevents transient routing loops from occurring.
Redistribution of BGP VPN Routes That Carry the Site of Origin into EIGRP
When an EIGRP routing process on a PE router redistributes BGP VPN routes
into an EIGRP topology table,
EIGRP extracts the SoO value (if one is present) from the appended BGP
extended community attributes and
appends the SoO value to the route before adding it to the EIGRP topology
table. EIGRP tests the SoO value
for each route before sending updates to CE routers. Routes that are
associated with SoO values that match
the SoO value configured on the interface are filtered out before they are
passed to the CE routers. When an
EIGRP routing process receives routes that are associated with different SoO
values, the SoO value is passed
to the CE router and carried through the CE site.
BGP Cost Community Support for EIGRP MPLS VPN PE-CE Network Topologies
The BGP cost community is a nontransitive extended community attribute that
is passed to internal BGP
(iBGP) and confederation peers but not external BGP (eBGP) peers. The cost
community feature allows you
to customize the local route preference and influence the BGP best path
selection process.
Before BGP cost community support for EIGRP MPLS VPN PE-CE network topologies
was introduced,
BGP preferred locally sourced routes over routes learned from BGP peers.
Backdoor links in an EIGRP MPLS
VPN topology were preferred by BGP when the backdoor link was learned first.
(A backdoor link or a route
is a connection that is configured outside of the VPN between a remote and
main site; for example, a WAN
leased line that connects a remote site to the corporate network).
The “prebest path” point of insertion (POI) was introduced in the BGP Cost
Community feature to support
mixed EIGRP VPN network topologies that contain VPN and backdoor links. This
POI is applied automatically
to EIGRP routes that are redistributed into BGP. The “prebest path” POI
carries the EIGRP route type and
metric. This POI influences the best path calculation process by influencing
BGP to consider this POI before
any other comparison step. No configuration is required. This feature is
enabled automatically for EIGRP
VPN sites when a Cisco IOS release that supports this feature is installed on
the PE routers or the CE and
backdoor router at the customer sites.
For more information about the BGP Cost Community feature, see to the BGP
Cost Community module in
the Cisco IOS IP Routing: BGP Configuration Guide.
Benefits of the EIGRP MPLS VPN PE-CE Site of Origin Support Feature
The configuration of the EIGRP MPLS VPN PE-CE Site of Origin Support feature
introduces per-site VPN
filtering, which improves support for complex topologies, such as MPLS VPNs
with backdoor links, CE
routers that are dual-homed to different PE routers, and PE routers that
support CE routers from different sites
within the same virtual routing and forwarding (VRF) instance.
Configuring the Site of Origin Extended Community

SUMMARY STEPS
The configuration of the SoO extended community allows MPLS VPN traffic to be
filtered on a per-site basis.
The SoO extended community is configured in an inbound BGP route map on the
PE router and is applied to
the interface. The SoO extended community can be applied to all exit points
at the customer site for more
specific filtering but must be configured on all interfaces of PE routers
that provide VPN services to CE
routers.
Before You Begin
•Border Gateway Protocol (BGP) is configured in the network core (or
the service provider backbone).
•Configure an EIGRP MPLS VPN before configuring this feature.
•All PE routers that are configured to support the EIGRP MPLS VPN must
support the SoO extended community.
•A unique SoO value must be configured for each VPN site. The same
value must be used on the interface
of the PE router that connects to the CE router for each VPN site.
1.enable
3.route-map map-name {permit | deny} [sequence-number]
4.set extcommunity {rt extended-community-value [additive] | soo extended-
community-value}
5.exit
6.interface type number
7.ip vrf forwarding vrf-name
8.ip vrf sitemap route-map-name
9.ip address ip-address subnet-mask
10.end
EIGRP Nonstop Forwarding (NSF) Awareness

Prerequisites for EIGRP Nonstop Forwarding Awareness
• Your network is configured to run EIGRP.
• An NSF-aware router must be up and completely converged with the
network before it can assist an
NSF-capable router in an NSF restart operation.
• A version of Cisco IOS that supports NSF awareness or NSF capabilities
must be installed.
Restrictions for EIGRP Nonstop Forwarding Awareness

• All neighboring devices participating in EIGRP NSF must be NSF-capable
or NSF-aware.
• EIGRP NSF awareness does not support two neighbors performing an NSF
restart operation at the same
time. However, both neighbors can reestablish peering sessions after the NSF
restart operation is
completed.
Cisco NSF Routing and Forwarding Operation

Cisco NSF is supported by the BGP, EIGRP, OSPF, and IS-IS protocols for
routing and by (CEF) for forwarding.
Of the routing protocols, BGP, OSPF, and IS-IS have been enhanced with NSF-
capability and awareness,
which means that routers running these protocols can detect a
switchover and
take the necessary actions to continue forwarding network traffic and
to recover route information from the
peer devices.
The IS-IS protocol can be configured to use state information that has been
synchronized between
the active and the standby route processor (RP) to recover route information
following a switchover instead
of information received from peer devices.
In this document, a networking device that is NSF-aware is running NSF-
compatible software. A device that
is NSF-capable has been configured to support NSF; therefore, the device
rebuilds routing information from
NSF-aware or NSF-capable neighbors.
Each protocol depends on CEF to continue forwarding packets during switchover
while the routing protocols
rebuild the routing information base (RIB) tables. After the routing
protocols have converged, CEF updates
the forwarding information base (FIB) table and removes stale route entries.
CEF, in turn, updates the line
cards with the new FIB information.
Cisco Express Forwarding

In a Cisco networking device, CEF provides packet forwarding, a key element
of NSF. CEF maintains the
FIB and uses the FIB information that was current at the time of a switchover
to continue forwarding packets
during the switchover. NSF helps to reduce traffic interruption during the
switchover.
During normal NSF operation, CEF on the active RP synchronizes its current
FIB and adjacency databases
with the FIB and adjacency databases on the standby RP. Upon switchover of
the active RP, the standby RP
initially has FIB and adjacency databases that are mirror images of those
that were current on the active RP.
For platforms with intelligent line cards, the line cards will maintain the
current forwarding information over
a switchover; for platforms with forwarding engines, CEF will keep the
forwarding engine on the standby RP
current with changes that are sent to it by CEF on the active RP. In this
way, the line cards or forwarding
engines will be able to continue forwarding after a switchover as soon as the
interfaces and a data path are
available.
As the routing protocols start to repopulate the RIB on a prefix-by-prefix
basis, the updates in turn cause
prefix-by-prefix updates for CEF, which it uses to update the FIB and
adjacency databases. Existing and new
entries will receive the new version (“epoch”) number, indicating that they
have been refreshed. The forwarding
information is updated on the line cards or forwarding engine during
convergence. The RP signals when the
RIB has converged. The software removes all FIB and adjacency entries that
have an epoch older than the
current switchover epoch. The FIB now represents the newest routing protocol
forwarding information
The routing protocols run only on the active RP, and they receive routing
updates from their neighbor routers.
Routing protocols do not run on the standby RP. Following a switchover, the
routing protocols request that
the NSF-aware neighbor devices send state information to help rebuild the
routing tables.
For NSF operation, the routing protocols depend on CEF to continue forwarding
packets while the routing
protocols rebuild the routing information.
EIGRP Nonstop Forwarding Awareness

Note
NSF awareness allows a router that is running EIGRP to assist NSF-capable
neighbors to continue forwarding
packets during a switchover operation or well-known failure condition. The
EIGRP Nonstop Forwarding
Awareness feature provides EIGRP with the capability to detect a neighbor
that is undergoing an NSF restart
event (RP switchover operation) or well-known failure condition, maintain the
peering session with this
neighbor, retain known routes, and continue to forward packets for these
routes. The deployment of EIGRP
NSF awareness can minimize the effects of the following:
•Well-known failure conditions (for example, a stuck-in-active event)
•Unexpected events (for example, an RP switchover operation)
•Scheduled events (for example, a hitless software upgrade)
EIGRP NSF awareness is enabled by default and is transparent to the network
operator and EIGRP peers that
do not support NSF capabilities.
An NSF-aware router must be up and completely converged with the network

before it can assist an
NSF-capable router in an NSF restart operation
EIGRP NSF Capable and NSF Aware Interoperation

EIGRP NSF capabilities are exchanged by EIGRP peers in hello packets. An NSF-
capable router notifies its
neighbors that an NSF restart operation has started by setting the restart
(RS) bit in a hello packet. When an
NSF-aware router receives notification from an NSF-capable neighbor that an
NSF-restart operation is in
progress, both routers immediately exchange their topology tables. The NSF-
aware router sends an end-of-table
(EOT) update packet when the transmission of its topology table is complete.
The NSF-aware router then
performs the following actions to assist the NSF-capable router:
•Expires the EIGRP hello hold timer to reduce the time interval set for hello
packet generation and
transmission. This allows the NSF-aware router to reply to the NSF-capable
router more quickly and
reduces the amount of time required for the NSF-capable router to rediscover
neighbors and rebuild the
topology table.
•Starts the route-hold timer. This timer is used to set the period of time
that the NSF-aware router will
hold known routes for the NSF-capable neighbor. This timer is configured with
the timers
graceful-restart purge-timecommand. The default time period is 240 seconds.
•Notes in the peer list that the NSF-capable neighbor is restarting,

maintains adjacency, and holds known
routes for the NSF-capable neighbor until the neighbor signals that it is
ready for the NSF-aware router
to send its topology table or the route-hold timer expires. If the route-hold
timer expires on the NSF-aware
router, it discards held routes and treats the NSF-capable router as a new
router joining the network and
reestablishing adjacency accordingly.
When the switchover operation is complete, the NSF-capable router notifies

its neighbors that it has reconverged
and has received all of their topology tables by sending an EOT update packet
to the assisting routers. The
NSF-capable router then returns to normal operation. The NSF-aware router
looks for alternate paths (go
active) for any routes that are not refreshed by the NSF-capable (restarting)
router. The NSF-aware router
returns to normal operation. If all paths are refreshed by the NSF-capable
router, the NSF-aware router
immediately returns to normal operation.
Non-NSF Aware EIGRP Neighbors

Note
NSF-aware routers are completely compatible with non-NSF aware or non-NSF
capable neighbors in an
EIGRP network. A non-NSF aware neighbor ignores NSF capabilities and resets
the adjacency when they
are received.
The NSF-capable router drops any queries that are received while converging
to minimize the number of
transient routes that are sent to neighbors. The NSF-capable router, however,
still acknowledges these queries
to prevent these neighbors from resetting adjacency.
An NSF-aware router continues to send queries to an NSF-capable router that

is converging after a
switchover, effectively extending the time before a stuck-in-active (SIA)
condition can occur.
EIGRP NSF Route-Hold Timers
The route-hold timer is configurable, which allows you to tune network
performance and avoid undesired
conditions such as “black holing” routes if the switchover operation is
lengthy. When the timer expires, the
NSF-aware router scans the topology table and discards stale routes, allowing
EIGRP peers to find alternate
routes instead of waiting during a long switchover operation.
The route-hold timer is configured with the timers graceful-restart purge-
time router configuration command.
The default time period for the route-hold timer is 240 seconds. The
configurable range is from 10 to 300
seconds.
Adjusting NSF Route-Hold Timers

SUMMARY STEPS
1.enable
3.router eigrp {autonomous-system-number | virtual-instance-name}
4.address-family ipv4 [multicast][unicast][vrf vrf-name] autonomous-system
autonomous-system-number
5.timers graceful-restart purge-time seconds
6.exit
EIGRP Prefix Limit Support

Prerequisites for EIGRP Prefix Limit Support
• Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN)
services have been configured
between the Provider Edge (PE) routers and the customer edge (CE)
routers at the customer sites.
Restrictions for EIGRP Prefix Limit Support
• This feature is supported only under the IPv4 VRF address family and
can be used only to limit the
number of prefixes that are accepted through a VRF.
• The EIGRP Prefix Limiting Support feature is enabled only under the
IPv4 VRF address-family. A peer
that is configured to send too many prefixes or a peer that rapidly
advertises and then withdraws prefixes
can cause instability in the network. This feature can be configured to
automatically reestablish a disabled
peering session at the default or user-defined time interval or when
the maximum-prefix limit is not
exceeded. However, the configuration of this feature alone cannot
change or correct a peer that is sending
an excessive number of prefixes. If the maximum-prefix limit is
exceeded, you will need to reconfigure
the maximum-prefix limit or reduce the number of prefixes that are sent
from the peer.
Misconfigured VPN Peers
In MPLS VPNs, the number of routes that are permitted in the VPN
routing and forwarding instance (VRF)
is configured with the maximum routes VRF configuration command.
However, limiting the number routes
permitted in the VPN does not protect the local router from a
misconfigured peer that sends an excessive
number of routes or prefixes. This type of external misconfiguration
can have a negative effect on the local
router by consuming all available system resources (CPU and memory) in
processing prefix updates. This
type of misconfiguration can occur on a peer that is not within the
control of the local administrator.
EIGRP Prefix Limit Support Overview
The EIGRP Prefix Limit Support feature provides the ability to
configure a limit on the number of prefixes
that are accepted from EIGRP peers or learned through redistribution.
This feature can be configured on
per-peer or per-process basis and can be configured for all peers and
processes. This feature is designed to
protect the local router from misconfigured external peers by limiting
the amount of system resources that
can be consumed to process prefix updates.
Protecting the Router from External Peers
This feature can be configured to protect an individual peering session
or protect all peering sessions. When
this feature is enabled and the maximum-prefix limit has been exceeded,
the router will tear down the peering
session, clear all routes that were learned from the peer, and then
place the peer in a penalty state for the
default or user-defined time period. After the penalty time period
expires, normal peering will be reestablished.
Limiting the Number of Redistributed Prefixes
This feature can be configured to limit the number of prefixes that are
accepted into the EIGRP topology table
through redistribution from the Routing Information Base (RIB). All
sources of redistribution are processed
cumulatively. When the maximum-prefix limit is exceeded, all routes
learned through redistribution are
discarded and redistribution is suspended for the default or user-
defined time period. After the penalty time
period expires, normal redistribution will occur.
Protecting the Router at the EIGRP Process Level
This feature can be configured to protect the router at the EIGRP
process level. When this feature is configured
at the EIGRP process level, the maximum-prefix limit is applied to all
peering sessions and to route
redistribution. When the maximum-prefix limit is exceeded, all sessions
with the remote peers are torn down,
all routes learned from remote peers are removed from the topology and
routing tables, all routes learned
through redistribution are discarded, and redistribution and peering
are suspended for the default or user-defined
time period.
Warning-Only Mode
The EIGRP Prefix Limit Support feature has two modes of operation. This
feature can control peering and
redistribution per default and user-defined values or this feature can
operate in warning-only mode. In
warning-only mode the router will monitor the number of prefixes
learned through peering and/or redistribution
but will not take any action when the maximum-prefix limit is exceeded.
Warning-only mode is activated
only when the warning-only keyword is configured for any of the
maximum-prefix limit commands. Only
syslog messages are generated when this mode of operation is enabled.
Syslog messages can be sent to a
syslog server or printed in the console. These messages can be buffered
or rate limited per standard Cisco
IOS system logging configuration options.
Restart Reset and Dampening Timers and Counters
The EIGRP Prefix Limit Support feature provides two user-configurable
timers, a restart counter, and a
dampening mechanism. When the maximum-prefix limit is exceeded, peering
and/or redistribution is suspended
for a default or user-defined time period. If the maximum-prefix limit
is exceeded too often, redistribution
and/or peering will be suspended until manual intervention is taken.
Restart Timer
The restart timer determines how long the router will wait to form an
adjacency or accept redistributed routes
from the RIB after the maximum-prefix limit has been exceeded. The
default restart-time period is 5 minutes.
Restart Counter
The restart counter determines the number of times a peering session
can be automatically reestablished after
the peering session has been torn down or after the a redistributed
routes have been cleared and relearned
because the maximum-prefix limit has been exceeded. The default
restart-count limit is three.
After the restart count limit has been crossed, you will need to enter the clear ip
route *, clear ip eigrp
neighbor, or clear eigrp address-family neighbor command to restore normal peering
and redistribution.
Reset Timer
The reset timer is used to configure the router to reset the restart
count to 0 after the default or configured
reset-time period has expired. This timer is designed to provide
administrator with control over long-and
medium-term accumulated penalties. The default reset-time period is 15
minutes.
Dampening Mechanism
The dampening mechanism is used to apply an exponential decay penalty
to the restart-time period each time
the maximum-prefix limit is exceeded. The half-life for the decay
penalty is 150 percent of the default or
user-defined restart-time value in minutes. This mechanism is designed
to identify and suppress unstable
peers. It is disabled by default.
Configure the Maximum-Prefix Limit

The maximum-prefix limit can be configured for all peering sessions or
individual peering sessions with the
neighbor maximum-prefix(EIGRP) command. When the maximum-prefix limit
is exceeded, the session
with the remote peer is torn down and all routes learned from the
remote peer are removed from the topology
and routing tables. The maximum-prefix limit that can be configured is
limited only by the available system
resources on the router.
Default or user-defined restart, restart-count, and reset-time values

for the process-level configuration of this
feature, configured with the maximum-prefix command, are inherited by
the redistribute maximum-prefix
and neighbor maximum-prefix command configurations by default. If a
single peer is configured with the
neighbor maximum-prefix command, a process-level configuration or a
configuration that is applied to all
neighbors will be inherited.
Before You Begin
• VRFs have been created and configured.
• EIGRP peering is established through the MPLS VPN.
SUMMARY STEPS Router configuration

1. enable
3. router eigrp as-number
4. address-family ipv4 [multicast][unicast][vrf vrf-name] autonomous-
system autonomous-system-number
5. neighbor {ip-address | peer-group-name} description text
6. neighbor ip-address maximum-prefix maximum [threshold] [warning-
only]
7. neighbor maximum-prefix maximum [threshold] [[dampened] [reset-time
minutes] [restart minutes] [restart-count number] | warning-only]
SUMMARY STEPS Named configuration

1. enable
3. router eigrp virtual-instance-name
4. address-family ipv4 [multicast] [unicast] [vrf vrf-name] autonomous-
5. neighbor {ip-address | peer-group-name} description text
6. neighbor ip-address maximum-prefix maximum [threshold][warning-only]
7. neighbor maximum-prefix maximum [threshold] [[dampened] [reset-time
minutes] [restart minutes] [restart-count number] | warning-only]
8. exit-address-family
This task can be configured only in IPv4 VRF address family

configuration mode.
SUMMARY STEPS
1. enable
3. router eigrp as-number
4. address-family ipv4 [unicast] vrf vrf-name
5. redistribute maximum-prefix maximum [threshold] [[dampened] [reset-
time minutes] [restart minutes] [restart-count number] | warning-only]
6. end
This task can be configured only in IPv4 VRF address family topology
configuration mode.
SUMMARY STEPS
1. enable
4. address-family ipv4 [multicast] [unicast] [vrf vrf-name] autonomous-
5. network ip-address [wildcard-mask]
6. topology {base | topology-name tid number}
7. redistribute maximum-prefix maximum [threshold] [[dampened] [reset-
time minutes] [restart minutes] [restart-count number] | warning-only]
8. exit-af-topology
EIGRP Route Tag Enhancements

The EIGRP Route Tag Enhancements feature enables you to specify and display
route tags in dotted-decimal
format, filter routes using the route tag value with wildcard mask, and set a
default route tag for all internal
(EIGRP) routes.
Restrictions for EIGRP Route Tag Enhancements

• Default route tags are not supported in EIGRP autonomous system
configurations.
• Route tags will not be displayed in dotted-decimal format if the route-tag
notation global configuration
command is not enabled on the device.
A route tag is a 32-bit value attached to routes. Route tags are used to
filter routes and apply administrative
policies, such as redistribution and route summarization, to tagged routes.
You can tag routes within a route map by using the set tag command.
You can match tagged routes and apply administrative policies to tagged
routes within a route map by using the match tag or match tag list command.
The match tag list command is used to match a list of route tags.
Prior to the EIGRP Route Tag Enhancements feature, EIGRP routes could only be
tagged using plain decimals (range: 1 to 4294967295).
This feature enables users to specify and display route tag values as dotted
decimals (range: 0.0.0.0 to 255.255.255.255),
similar to the format used by IPv4 addresses.
This enhancement is intended to simplify the use of route tags as users can
now filter routes by using the route tag wildcard mask.
This feature also allows you to configure a default route tag for all
internal EIGRP routes without using route maps.
Use the eigrp default-route-tag command in address family configuration mode
to configure a default
route tag for internal EIGRP routes.
Setting a Route Tag in a Route Map

SUMMARY STEPS
1. enable
3. route-map map-name [permit | deny] [sequence-number]
4. set tag {tag-value | tag-value-dotted-decimal}
5. end
6. show route-map
Enabling Dotted-Decimal Notation for Route Tags

SUMMARY STEPS
1. enable
3. route-tag notation dotted-decimal
4. end
5. Enter one of the following:
• show ip route tag
• show ipv6 route tag
EIGRP Over the Top

The EIGRP Over the Top feature enables a single end-to-end Enhanced Interior
Gateway Routing Protocol
(EIGRP) routing domain that is transparent to the underlying public or
private WAN transport that is used
for connecting disparate EIGRP customer sites. When an enterprise extends its
connectivity across multiple
sites through a private or a public WAN connection, the service provider
mandates that the enterprise use an
additional routing protocol, typically the Border Gateway Protocol (BGP),
over the WAN links to ensure
end-to-end routing. The use of an additional protocol causes additional
complexities for the enterprise, such
as additional routing processes and sustained interaction between EIGRP and
the routing protocol to ensure
connectivity, for the enterprise. With the EIGRP Over the Top feature,
routing is consolidated into a single
protocol (EIGRP) across the WAN, which provides the following benefits:
• There is no dependency on the type of WAN connection used.
• There is no dependency on the service provider to transfer routes.
• There is no security threat because the underlying WAN has no
knowledge of enterprise routes.
• This feature simplifies dual carrier deployments and designs by
eliminating the need to configure and
manage EIGRP-BGP route distribution and route filtering between
customer sites.
• This feature allows easy transition between different service
providers.
• This feature supports both IPv4 and IPv6 environments.
EIGRP Over the Top Works

The EIGRP Over the Top solution can be used to ensure connectivity
between disparate Enhanced Interior
Gateway Routing Protocol (EIGRP) sites. This feature uses EIGRP on the
control plane and Locator ID
Separation Protocol (LISP) encapsulation on the data plane to route
traffic across the underlying WAN
architecture. EIGRP is used to distribute routes between customer edge
(CE) devices within the network, and
the traffic forwarded across the WAN architecture is LISP encapsulated.
Therefore, to connect disparate
EIGRP sites, you must configure the neighbor command with LISP
encapsulation on every CE in the network.
If your network has many CEs, then you can use EIGRP Route Reflectors
(E-RRs) to form a half-mesh
topology and ensure connectivity among all CEs in the network. An E-RR
is an EIGRP peer that receives
EIGRP route updates from CEs in the network and reflects these updates
to other EIGRP CE neighbors without
changing the next hop or metrics for the routes. An E-RR can also
function as a CE in the network. You must
configure E-RRs with the remote-neighbors source command to enable E-
RRs to listen to unicast messages
from peer CE devices and reflect the messages to other EIGRP CE
neighbors. You must configure the CEs
with the neighbor command to allow them to identify the E-RRs in their
network and exchange routes with
the E-RRs. Upon learning routes from E-RRs, the CEs install these
routes into their routing information base
(RIB). You can use dual or multiple E-RRs for redundancy. The CEs form
adjacencies with all E-RRs
configured in the network, thus enabling multihop remote neighborship
amongst themselves.
Configuring EIGRP Over the Top on a CE Device
You must enable the EIGRP Over the Top feature on all customer edge
(CE) devices in the network so that
the CEs know how to reach the Enhanced Interior Gateway Routing
Protocol (EIGRP) Route Reflector
configured in the network. Perform the following task to configure the
EIGRP Over the Top feature on a CE
device and enable Locator ID Separation Protocol (LISP) encapsulation
for traffic across the underlying WAN.
SUMMARY STEPS
1. enable
4. address-family ipv4 autonomous-system as-number
5. neighbor{ip-address | ipv6-address} interface-type interface-number
[remote maximum-hops [lisp-encap
[lisp-id]]]
6. network ip-address[wildcard-mask]
7. end
Configuring EIGRP Route Reflectors

SUMMARY STEPS
1. enable
4. address-family ipv4 unicast autonomous-system as-number
5. af-interface interface-type interface-number
6. no next-hop-self
7. no split-horizon
8. exit
9. remote-neighbors source interface-type interface-number
unicast-listen lisp-encap
10. network ip-address
11. end
IPv6 for EIGRP

Restrictions for IPv6 Routing EIGRP Support
This section lists ways in which EIGRP for IPv6 differs from EIGRP IPv4 and
lists EIGRP for IPv6 restrictions:
• EIGRP for IPv6 is directly configured on the interfaces over which it runs.
This feature allows EIGRP for IPv6 to be configured without the use of
a global IPv6 address.
There is no network statement in EIGRP for IPv6.
In per-interface configuration at system startup, if EIGRP has been
configured on an interface,
then the EIGRP protocol may start running before any EIGRP router mode
commands have been executed.
• An EIGRP for IPv6 protocol instance requires a router ID before it can
start running.
• EIGRP for IPv6 has a shutdown feature.
The routing process should be in "no shut" mode in order to start
running.
• EIGRP for IPv6 provides route filtering using the distribute-list prefix-
list command.
Use of the route-map command is not supported for route filtering with
a distribute list.
Cisco EIGRP for IPv6 Implementation

When EIGRP is enabled, the largest possible width is 224 hops.
Because the EIGRP metric is large enough to support thousands of hops, the
only barrier to expanding the network is the
transport layer hop counter.
Cisco works around this limitation by incrementing the transport control
field only when an IPv4 or an IPv6 packet has
traversed 15 devices and the next hop to the destination was learned by
way of EIGRP.
Then a RIP route is being used as the next hop to the destination, the
transport control field is incremented as usual.
• Fast convergence--The DUAL algorithm allows routing information to converge
as quickly as any other routing protocol.
• Partial updates--EIGRP sends incremental updates when the state of a
destination changes,
instead of sending the entire contents of the routing table.
This feature minimizes the bandwidth required for EIGRP packets.
• Neighbor discovery mechanism--This is a simple hello mechanism used to
learn about neighboring devices.
It is protocol-independent.
• Arbitrary route summarization.
• Scaling--EIGRP scales to large networks.
• Route filtering--EIGRP for IPv6 provides route filtering using the
distribute-list prefix-listcommand.
Use of the route-map command is not supported for route filtering with
a distribute list.
EIGRP has the following four basic components:

• Neighbor discovery--
Neighbor discovery is the process that devices use to dynamically learn of
other devices on their directly attached networks.
Devices must also discover when their neighbors become unreachable or
inoperative.
EIGRP neighbor discovery is achieved with low overhead by periodically
sending small hello packets.
EIGRP neighbors can also discover a neighbor that has recovered after an
outage because the recovered neighbor will send out a hello packet.
As long as hello packets are received, the Cisco software can determine that
a neighbor is alive and functioning.
Once this status is determined, the neighboring devices can exchange routing
information.
• Reliable transport protocol--

The reliable transport protocol is responsible for guaranteed, ordered
delivery of EIGRP packets to all neighbors.
It supports intermixed transmission of multicast and unicast packets.
Some EIGRP packets must be sent reliably and others need not be.
For efficiency, reliability is provided only when necessary.
For example, on a multiaccess network that has multicast capabilities, it is
not necessary to send hello packets reliably
to all neighbors individually.
Therefore, EIGRP sends a single multicast hello with an indication in the
packet informing the receivers that the packet need not be
acknowledged.
Other types of packets (such as updates) require acknowledgment, which is
indicated in the packet.
The reliable transport has a provision to send multicast packets quickly when
unacknowledged packets are pending.
This provision helps to ensure that convergence time remains low in the
presence of varying speed links.
• DUAL finite state machine--

The DUAL finite state machine embodies the decision process for all route
computations.
It tracks all routes advertised by all neighbors.
DUAL uses several metrics including distance and cost information to select
efficient, loop-free paths.
When multiple routes to a neighbor exist, DUAL determines which route has the
lowest metric (named the feasible distance), and enters this
route into the routing table.
Other possible routes to this neighbor with larger metrics are received, and
DUAL determines the reported distance to this network.
The reported distance is defined as the total metric advertised by an
upstream neighbor for a path to a destination.
DUAL compares the reported distance with the feasible distance, and if the
reported distance is less than the feasible distance, DUAL
considers the route to be a feasible successor and enters the route
into the topology table.
The feasible successor route that is reported with the lowest metric becomes
the successor route to the current route
if the current route fails.
To avoid routing loops, DUAL ensures that the reported distance is always
less than the feasible distance for a neighbor device to
reach the destination network; otherwise, the route to the neighbor may
loop back through the local device.
• Protocol-dependent modules--
When there are no feasible successors to a route that has failed, but there
are neighbors advertising the route, a recomputation must occur.
This is the process in which DUAL determines a new successor.
The amount of time required to recompute the route affects the convergence
time.
Recomputation is processor-intensive; it is advantageous to avoid unneeded
recomputation.
When a topology change occurs, DUAL will test for feasible successors.
If there are feasible successors, DUAL will use them in order to avoid
unnecessary recomputation.
SUMMARY STEPS
1. enable
3. ipv6 unicast-routing
4. interface type number
5. no shut
6. ipv6 enable
7. ipv6 eigrp as-number
8. ipv6 router eigrp as-number
9. router-id ip-address
10. exit
11. show ipv6 eigrp [as-number] interfaces [type number] [detail]
Configuring the Percentage of Link Bandwidth Used by EIGRP
SUMMARY STEPS
1. enable
4. no shut
5. ipv6 bandwidth-percent eigrp as-number percent
Configuring Summary Addresses

SUMMARY STEPS
1. enable
4. no shut
5. ipv6 summary-address eigrp as-number ipv6-address [admin-distance]
Overriding the Next Hop in EIGRP

EIGRP will, by default, set the IPv6 next-hop value to be itself for routes
that it is advertising, even when
advertising those routes back out the same interface where it learned
them.
Perform this task to change this default and instruct EIGRP to use the
received next-hop value when advertising these routes.
SUMMARY STEPS
1. enable
4. no shut
5. no ipv6 next-hop-self eigrp as-number
Adjusting the Interval Between Hello Packets in EIGRP for IPv6

Routing devices periodically send hello packets to each other to dynamically
learn of other devices on their directly attached networks.
This information is used to discover neighbors and learn when neighbors
become unreachable or inoperative.
SUMMARY STEPS
1. enable
4. no shut
5. ipv6 hello-interval eigrp as-number seconds
Adjusting the Hold Time in EIGRP for IPv6

On very congested and large networks, the default hold time might not be
sufficient time for all devices to
receive hello packets from their neighbors.
In this case, you may want to increase the hold time.
This task configures the hold time on a specified interface for a particular
EIGRP routing process designated by the autonomous system number.
The hold time is advertised in hello packets and indicates to neighbors the
length of time they should consider the sender valid.
The default hold time is 3 times the hello interval, or 15 seconds.
For slow-speed nonbroadcast multi-access (NBMA) networks, the default hold
time is 180 seconds.
The hold time should be changed if the hello-interval value is changed.
SUMMARY STEPS
1. enable
4. no shut
5. ipv6 hold-time eigrp as-number seconds
Disabling Split Horizon in EIGRP for IPv6
SUMMARY STEPS
1. enable
4. no shut
5. no ipv6 split-horizon eigrp as-number
EIGRP IPv6 VRF-Lite

VRF-lite allows a service provider to support two or more VPNs with an
overlapping IP address using one interface.
VRF-lite uses input interfaces to distinguish routes for different VPNs and
forms virtual
packet-forwarding tables by associating one or more Layer 3 interfaces
with each VRF.
Interfaces in a VRF can be either physical, such as Ethernet ports, or
logical, such as VLAN SVIs, but a Layer 3 interface cannot
belong to more than one VRF at any time.
The EIGRP IPv6 VRF-Lite feature is available only in EIGRP named

configurations.
Enabling the EIGRP IPv6 VRF-Lite Named Configuration

SUMMARY STEPS
1. enable
4. address-family ipv6 vrf vrf-name autonomous-system autonomous-system-
number
5. end
BFD Support for EIGRP IPv6

Prerequisites for BFD Support for EIGRP IPv6
EIGRP IPv6 sessions have a shutdown option in router, address family,
and address-family interface configuration modes.
To enable BFD support on EIGRP IPv6 sessions, the routing process
should be in no shut mode in the abovementioned modes.
Restrictions for BFD Support for EIGRP IPv6
• The BFD Support for EIGRP IPv6 feature is supported only in EIGRP
named mode.
• EIGRP supports only single-hop Bidirectional Forwarding Detection
(BFD).
• The BFD Support for EIGRP IPv6 feature is not supported on passive
interfaces.
BFD is implemented in EIGRP at multiple levels; it can be implemented per

interface or on all interfaces.
When BFD is enabled on a specific interface, all peer relationships formed
through the EIGRP “Hello”
mechanism on that interface are registered with the BFD process.
Subsequently, BFD establishes a session with each of the peers in the EIGRP
topology and notifies EIGRP through a callback mechanism of any change
in the state of any peer.
When a peer is lost, BFD sends a “peer down” notification to EIGRP, and EIGRP
unregisters a peer from BFD.
BFD does not send a “peer up” notification to EIGRP when the peer is up
because BFD now has no knowledge of the state of the peer.
This behavior prevents rapid neighbor bouncing and repetitive route
computations.
The EIGRP “Hello” mechanism will later allow peer rediscovery and
reregistration with the BFD process.
Configuring BFD Support on All Interfaces

SUMMARY STEPS
1. enable
5. ipv6 address ipv6-address/prefix-length
6. bfd interval milliseconds min_rx milliseconds multiplier interval-
multiplier
7. exit
10. eigrp router-id ip-address
11. af-interface default
12. bfd
13. end
14. show eigrp address-family ipv6 neighbors
Configuring BFD Support on an Interface

SUMMARY STEPS
1. enable
5. ipv6 address ipv6-address /prefix-length
6. bfd interval milliseconds min_rx milliseconds multiplier interval-
multiplier
7. exit
10. eigrp router-id ip-address
11. af-interface interface-type interface-number
12. bfd
13. end
14. show eigrp address-family ipv6 neighbors
EIGRP Support for 6PE/6VPE

The EIGRP Support for 6PE/6VPE feature enables native IPv6 (EIGRP) routes to
preserve their original characteristics
(metric and other attributes like type, delay, bandwidth, and the
maximum transmission unit [MTU]) while being redistributed from one
IPv6 EIGRP site to another over a service-provider VPN cloud or an IPv6
provider edge (6PE) Multiprotocol Label Switching-VPN
(MPLS-VPN) network.
The EIGRP 6PE/6VPE implementation allows native IPv6 EIGRP routes to run on
provider-edge (PE) and customer-edge (CE) devices while
preserving their original characteristics.
MPLS supports only IPv4.
Therefore, the Border Gateway Protocol (BGP) is used to redistribute IPv6
routes over a service-provider VPN cloud or a 6PE MPLS-VPN network.
BGP Extended Communities

For the Enhanced Interior Gateway Routing Protocol (EIGRP) to recreate route
metrics derived from the
originating customer site, the original metrics are encoded into Border
Gateway Protocol (BGP) Extended
Communities by the provider-edge (PE) device that receives the routes from
the transmitting customer-edge
(CE) device. These extended communities are then transported across the
Multiprotocol Label Switching-VPN
(MPLS-VPN) backbone by BGP from one customer site to the other (peering
customer site). After the peering
customer site receives the routes, BGP redistributes the routes into EIGRP.
EIGRP, then, extracts the BGP
Extended Community information and reconstructs the routes as they appeared
in the original customer site.
The following rules govern BGP Extended Communities:
Non-EIGRP-Originated Routes: If a non-EIGRP-originated route is received

through BGP and the route has
no extended community information for EIGRP, BGP advertises the route to the
receiving CE as an external
EIGRP route by using the route’s default metric. If no default metric is
configured, BGP does not advertise
the route to the CE.
EIGRP-Originated Internal Routes: If an EIGRP-originated internal route is

received through BGP and the
route has extended community information for EIGRP, the PE sets the route
type to “internal” if the source
autonomous system number matches the autonomous system number configured for
this VPN routing and
forwarding (VRF) instance. BGP, then, reconstructs and advertises the route
to the receiving CE as an internal
EIGRP route by using the extended community information. If there is no
autonomous system match, these
routes are treated as non-EIGRP-originated routes.
EIGRP-Originated External Routes: If an EIGRP-originated external route is

received through BGP and the
route has extended community information for EIGRP, the PE sets the route
type to “external” if the source
autonomous system number matches the autonomous system number configured for
this VRF instance. BGP,
then, reconstructs and advertises this external route to the receiving CE as
an external EIGRP route by using
the extended community information. If there is no autonomous system match,
these routes are treated as
non-EIGRP-originated routes.
EIGRP 6PE/6VPE SoO

The EIGRP 6PE/6VPE Site of Origin (SoO) functionality allows an Enhanced
Interior Gateway Routing
Protocol (EIGRP) network to support complex topologies, such as Multiprotocol
Label Switching-VPN
(MPLS-VPN) links between sites with backdoor links, customer-edge (CE)
devices that are dual-homed to
different provider-edge (PE) devices, and PEs supporting CEs from different
sites within the same VPN
routing and forwarding (VRF) instance. Path selection within the EIGRP
network containing PE-CE links is
based on route metrics that allow either the link through the VPN or the
EIGRP backdoor to act as the primary
(best) link or the backup link, if the primary link fails. EIGRP accomplishes
this path selection by retrieving
the Site of Origin (SoO) attribute from routes redistributed from the Border
Gateway Protocol (BGP) network.
This BGP/EIGRP interaction takes place through the use of the BGP Cost
Community Extended Community
attribute.
When routes are redistribued into EIGRP from a BGP network, BGP Cost
Community Extended Community
attributes are added to the routes. These attributes include the SoO
attribute. The SoO attribute is used to
identify the site of origin of a route and prevent advertisement of the route
back to the source site. To enable
the EIGRP SoO functionality, you must configure the ip vrf sitemap command on
the PE interface that is
connected to the CE device. This command enables SoO filtering on the
interface. When EIGRP on the PE
device receives CE routes on the interface that has a SoO value defined,
EIGRP checks each route to determine
whether there is an SoO value associated with the route that matches the
interface SoO value. If the SoO
values match, the route will be filtered. This filtering is done to stop
routing loops.
When EIGRP on the PE receives a route that does not contain an SoO value or
contains an SoO value that
does not match the interface SoO value, the route will be accepted into the
topology table so that it can be
redistributed into BGP. When the PE redistributes an EIGRP route that does
not contain an SoO value into
BGP, the SoO value that is defined on the interface used to reach the next
hop (CE) is included in the Extended
Communities attribute associated with the route. If the EIGRP topology table
entry already has an SoO value
associated with the route, this SoO value, instead of the interface SoO
value, will be included with the route
when it is redistributed into the BGP table. Any BGP peer that receives these
prefixes will also receive the
SoO value associated with each prefix, identifying the site, where each
prefix originated.
The EIGRP SoO functionality ensures that BGP does not follow its normal path-
selection behavior, where
locally derived routes (such as native EIGRP routes redistributed into BGP)
are preferred over BGP-derived
routes.
Backdoor Devices
Backdoor devices are EIGRP devices that connect one EIGRP site to
another, but not through the Multiprotocol
Label Switching-VPN (MPLS-VPN) network. Typically, a backdoor link is
used as a backup path between
peering EIGRP sites if the MPLS-VPN link is down or unavailable. The
metric on the backdoor link is set
high enough so that the path through the backdoor will not be selected
unless there is a VPN link failure. You
can define Site of Origin (SoO) values on the backdoor device on
interfaces connecting the device to the
peering sites, thus identifying the local-site identity of the link.
When a backdoor device receives EIGRP updates or replies from a

neighbor, the device checks each received
route to verify that the route does not contain an SoO value that
matches the ones defined on its interfaces. If
the device finds a route with a SoO value that matches the value
defined on any of its interfaces, the route is
rejected and not included in the topology table. Typically, the reason
that a route is received with a matching
SoO value is that the route is learned by the other peering site
through the MPLS-VPN connection and is
being advertised back to the original site over the backdoor link. By
filtering such routes based on the SoO
value defined on the backdoor link, you can avoid short-term, invalid
routing.

RobRiker EIGRP

Uploaded by

Copyright:

Available Formats

RobRiker EIGRP

Uploaded by

Document Information

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

RobRiker EIGRP

Uploaded by

Copyright:

Available Formats

EIGRP

15.3 only commands

neighbor description - named mode

neighbor maximum-prefix - named mode

Neighbors are discovered with hello packets

debug eigrp packet

R2#sh ip route 155.1.0.4

(sec) (ms) Cnt Num

R2#sh ip eigrp topology 155.1.0.0/24

H - The list of neighbors in the order they are learned, starting at 0.

TCL Ping/traceroute scripts

Did this on one router

Type escape sequence to abort.

Within the EIGRP packet header;

Sequence – is a 32-bit field that contains sequence number used by RTP.

IP Internal Routes TLV

An internal route is a path to a destination within the EIGRP autonomous

Next Hop – is the next-hop, neighboring router, IP address.

IP External Routes TLV

An external route is a path that leads to a destination outside of the EIGRP

Next Hop – is the next-hop IP address. On a multiaccess network, the router

R10#sh ip eigrp traffic

EIGRP Auto summary

If you have auto-summary enabled, a discard or null0 route will be locally

EIGRP Split Horizon

EIGRP Named Mode

In addition to the syntax parser change, EIGRP Wide Metric scaling is

R1#show eigrp address-family ipv4 100 topology 150.1.2.2/32

topology base is the global routing table

Neighbor, topology and routing table - Feasibility condition

Per-link (link-based) computation:

EIGRP always computes prefix-based LFAs. EIGRP uses the Diffusing

NOTE - The repair or backup information computed for a primary

LFA Tie-Breaking Rules

Disabling Load Sharing Among Prefixes

Enabling Tie-Breaking Rules for EIGRP LFAs

EIGRP Dampening - Change

EIGRP Dampening - Interval

R10#sh ip eigrp topology ?

EIGRP Update types

neighbor statment disables multicasts

passive interface stops both unicast and multicast hellos

the neighbor statement enables unicast adjacency

EIGRP Route Authentication

EIGRP Time Based Authentication

EIGRP/SAF HMAC-SHA-256 Authentication

EIGRP DUAL How Path Selection is figured out

serno is a pointer to a doubly linked serial number for the route.

H - The list of neighbors in the order they are learned, starting at 0.

EIGRP metric calculation

metric = 256*((10000000/min bandwidth)+delay)

Wide Metrics Calculation

modify interface parameters

Address Family Configuration

The EIGRP Wide Metrics feature also introduces K6 as an additional K value

By default, the path selection scheme used by EIGRP is a combination of

Issues found with Wide metrics

Bandwidth is lowest bandwidth along the path on a per prefix basis

Summary-metric in Named mode can mitigate this