EIGRP only uses the information received from its directly connected neighbors to make

routing decisions.
A router only announces the routes its using to its directly connected neighbors.
EIGRP doesnt build peer relationships over secondary addresses. All EIGRP traffic is sourced
from the primary address.
EIGRP store all routes in its routing table, whether its loop-free or not. To see the entire
topology table, use show ip eigrp topology all-links instead of show ip eigrp topology
network assigns all subnets belonging to the specified major networks to the EIGRP
process. EIGRP neighbors are discovered on all the interfaces belonging to the specified
major network, and the routing information is exchanged with those neighbors.
Vector metric is a 5-element vector containing parameters (bandwidth, delay, load,
reliability, and hop count) that describe the distance between a router and the destination
subnet. This metric is used in all EIGRP routing updates.
Composite metric is an integer number used to compare different routes toward the same
destination subnet. Only used internally in the router and never sent to EIGRP neighbors.
EIGRP uses triggered routing updates that reflect interface load and reliability at the time of
the event. Therefore, load and reliability in EIGRP vector metric are useless. no metric
weights reset K-values back to default.
By default, metric = 256 * (107/slowest_bandwidth) + 256 * cumulative_delay
Poison reverse is advertising a route unreachable (maximum metric) out the interface to
which it was received so the originator of the route do not perceive the update as another
path toward the network its directly connected to, therefore, avoiding loops. EIGRP uses
poison reverse when:
- Two routers are exchanging topology table for the first time
- Advertising a topology table change
- Sending a query
When a router changes in such a way that you should advertise a network reversely back to
downstream router, split horizon is disabled.
You can manipulate EIGRP to mimic other routing protocols by:
- To emulate RIP, set delays on all interfaces to equal values and set all Ks, except K3 to 0
- To emulate OSPF, set interface delay to OSPF cost and set all Ks, except K3 to 0
- To select a route with maximum end-to-end bandwidth, set all Ks except K1, to 0.
Note: composite metric is always 1 if you set all K-values to 0.
Default bandwidth and delay
Interface Type
Ethernet
Token ring
Fddi
Serial interface
Low-speed serial interface[1]
ISDN BRI
ISDN PRI
Dialer interface
Channelized T1 or E1
Async interface

Bandwidth (kbps)
10000
16000
100000
1544
115
64[2]
64
56
n * 64
tty line speed

Delay (microseconds)
1000
630
100
20000
20000
20000
20000
20000
20000
100000

Loopback

8000000

5000

Setting proper bandwidth is particularly tricky on VLAN interfaces, especially so when

different routers attach to the same VLAN through different technology. Its recommended
that you set the bandwidth to a sensible value thats the same on all routers attached to the
same VLAN.
Delay is calculated as a sum of all delays the routers in the path has
Bandwidth is the minimum bandwidth of the all interfaces in the path. If router is
advertising a directly connected route (its the start router), bandwidth is its interface
bandwidth.
MTU is also the minimum MTU of all interfaces in the path
Hop count is previous hop count + 1

Downstream router (for a subnet) is the router that is closer to the destination subnet and
used by current router to forward data packets to the destination subnet.
Upstream router (for a subnet) is the router that is closer to the source subnet and uses the
current router to forward data packets to the destination subnet.
Note: these concepts are relative to a router and a specific flow, not fixed for all routers.
To send EIGRP updates, 3 steps are needed:
- Individual route updates are enqueued for an interface

- Route updates enqueued for an interface are bundled into a packet when the interface is
read to send more EIGRP traffic
- Update packet is sent toward individual neighbors reachable over that interface.
DUAL logic:
- Whenever a router chooses a new successor, it informs all its other neighbors about the
new RD
- Every time a router selects a successor, it sends a poison update to its source; poison
reverse
- Poison update is sent to all neighbors on the interface through which the successor is
reachable. If split-horizon is turned off, current router only send poison update to source
Loss:
- Router report a route loss using a normal update packet and delay is set to infinity (-1)
- Router report a neighbor loss if an update packet is received from that neighbor with delay
set to infinity for every route received from that neighbor
- EIGRP handles link loss as the loss of a directly connected subnet + loss of one or more
neighbors if there are EIGRP neighbors reachable through the lost interface.
An EIGRP router facing increased metric from its successor can find a better route
immediately if the new best route goes through a feasible successor. Update packets are
send out regarding the new best route.
DUAL:
Route is marked active in topology table
Reply-status table is created to track replies from neighbors
Query is sent to neighbors
Responses are collected and stored in topology table. Response status of individual
neighbors is traced in the reply-status table
- Best response is selected in the topology table and the new best route is installed nit he
routing table
- If necessary, an update is sent to the neighbors to inform the changed topology.
-

Reaction to Query
Condition
Action
Route not in topology table
Reply with infinity.
Route already active
Reply with current best metric (could be infinity).
Query received from nonsuccessor Reply with current best route.
Query received only from successor, Reply with infinity.
no other EIGRP neighbors
Query received from successor
Select new best route. If it goes through a feasible successor,
reply with new best route, otherwise extend diffused computation.
To Display
Routes currently under diffused computation
Routes currently being converged
Whether this router is a potential bottleneck

Use the Following Command

show ip eigrp topology active
show ip eigrp topology pending
show ip eigrp neighbor detail

Task
Command
Change the Stuck-in-Active timeoutrouter eigrp <AS> timers active-time <timeout-in-minutes>
Disable the Stuck-in-Active check router eigrp <AS> timers active-time disabled

SIA are usually caused by several route flaps combined with slow-speed or lossy links in
large networks. Here are some more general causes:

Flapping interface
Configuration change
Lossy link
Heavily loaded links
Misconfiguration of bandwidth parameter
Old EIGRP code
Routing loops with multiple (E)IGRP processes and redistribution
Redistributed IGRP routes
Frame Relay

All EIGRP packets share a common header

Where OPCODE can be

OPcode
1
3
4
5
6

Type
Update
Query
Reply
Hello
IPX SAP

EIGRP can be easily expanded using different TLVs

Number
General TLV Types
0x0001
0x0003
0x0004
0x0005
IP-Specific TLV Types
0x0102
0x0103

TLV Type
EIGRP Parameters
Sequence
Software Version 12
Next Multicast Sequence
IP Internal Routes
IP External Routes

Each TLVs contains the entry type (2 byte), entry length (2 bytes) and entry-specific
information. The following are IP internal and External TLVs

Hello protocol is used an unidirectional protocol where each router sends multicast packets
over all interfaces on which it runs EIGRP.
EIGRP hello packets are always sent from the primary IP address configured on the
interface, but the receiving router checks the packets source IP address against all IP
subnets configured on the interface. If you reverse primary and secondary subnets on two
adjacent routers, EIGRP still works. However, if the primary IP subnet between the neighbor
doesn't match, EIGRP doesnt start.
Default Hello and hold timer
Interface
Encapsulation
LAN interface Any
WAN interface HDLC or PPP
NBMA interface (X.25, Frame Relay, SMDS or
Dialer) with bandwidth <= T1
NBMA interface with bandwidth > T1
Point-to-point subinterface over NBMA interface

Hello Timer (sec) Hold Timer (sec)

5
15
5
15
60
180
5
5

15
15

When using passive-interface,

- No adjacencies are established over the passive interface
- No routing updates are accepted over the passive interface
- Subnet of the passive interface remains in the EIGRP process and appears in the EIGRP
topology table as an internal route.
One way to measure the Hello interval is using debugging. However, during loaded times,
you should take an extensive sample to determine the average time.
Remaining hold time can be displayed using show ip eigrp neighbor
RTP support unicast and multicast while TCP only support unicast. ACK (unicast) and Hello
(multicast) are not transported using RTP. All reliable multicast packets can also be sent as
unicast packet. The unicast version of the packet is used when:
- Transmission media doesnt support multicasting. To check, use show ip eigrp interface,
unsupported interface has 0/0 in Un/reliable mcasts.
- Neighbor didnt acknowledge the packet within multicast timeout interval
EIGRP uses the same flow of acknowledge number for both unicast and multicast packets,
this means any unicast or multicast packet will not have the same acknowledgment number.
EIGRP uses an individual flow for every packet instead of a continuous flow.
Condition
Sequence Number
Data packets before the first packet Current sequence number
is received from remote neighbor
Data packets after the first packet Current sequence number
is received from remote neighbor
ACK packet
0
hello packet

ACK Number
0
Last sequence number received from
the neighbor
Last sequence number received from
the neighbor
0

Round trip time (RTT) is defined as the interval between the packet being sent over an
interface and the acknowledgement for that packet being received from a neighbor. SRTT is
the average of all neighbors reachable over that interface.
RTO increases by 50% after each retransmission. After 16 unsuccessful tries, packet is
declared dead.

Difference between multicast and unicast packets:n

- Must track neighbors that should acknowledge packet and retransmit unacknowledged
packets as unicast after RTO timed out.
- ACK is always 0.
Note: EIGRP has a special mechanism that deal with unacknowledged multicast packets.
Recipients of the packets will then receive a unicast copy of the packet instead. This
prevents stalling traffic between all neighbors. The number of times such behavior occur is
documented in Mcast exceptions from show ip eigrp interface detail
EIGRP hello doesnt verify two-way adjacency, but whenever an unknown Hello is heard, this
router tries to form an adjacency with it.
An EIGRP router tries to exchange its topology table with the new neighbor as soon as its
discovered. This causes several initial topology exchange packets to be dropped before this
router responded with Hello packet and form adjacency. The initial topology table exchange
is signaled by INIT flag in the first update packet sent to the new neighbor.
When a neighbor is down, its removed from the neighbor table and a linkdown() event is
generated. All routes received from that neighbor are removed from the topology table. All
successor routes whose downstream router is the lost neighbor will start local computation
or DUAL.
Action
Effects on EIGRP Adjacencies
No packets are received from the neighbor within hold timer. Neighbor is declared dead.
A single reliable packet is retransmitted at least 16 times
Neighbor is declared dead.
and for a period larger than the hold timer.
The interface goes down (line down or line protocol down). All neighbors reachable over that
interface are declared dead.
The interface is shut down by an operation action.
All neighbors reachable over that
interface are declared dead.
A network is removed from EIGRP process.
All neighbors belonging to that network
are declared dead.

A change in bandwidth, delay, or MTU size will reset all adjacencies.

Change in auto-summary will also reset all adjacencies.
An EIGRP router only discovers adjacency reset when the neighbor send it a Hello with
INIT flag rather than normal Hello keepalive. However, this probably will cause the other
neighbor to time out and declare this neighbor dead, and the problem will have to start
again. This approach can result in loss of adjacency for the dead timer.

The only time when EIGRP neighbor logging cant give a lot of information is for SIA events.
The adjacency with a nonresponding neighbor is cleared when the EIGRP router experiences
an SIA event, but this is not logged using EIGRP neighbor logging.
Information can be inserted in the topology table when:
- An update packet with non-infinite delay is received
- A reply packet with a non-infinite delay is received
- A route is redistributed from another routing protocol
- A directly connected subnet belong to one of the network become active
Information can be updated in the topology table when a query with non-infinite delay is
received
Information can be deleted from the topology table when:
- A neighbor is dead
- A redistributed route disappear from the source routing process
- Update, query, or reply with infinite delay
- Directly connected subnet becomes unreachable
Note the next serial in show ip eigrp topology, it shows the number of routes stored in the
EIGRP topology table directly affects the memory usage and convergence speed. If the
number of routes in an EIGRP topology table is much larger than the number of routes
inserted from EIGRP into the IP routing table, it might indicate that your network is too
highly meshed or that the EIGRP split horizon is turned off in the wrong place.
The next serial field gives you information about the number of changes in the EIGRP
topology table; every time a change is introduced into the topology table, the next serial
number is increased by one. By monitoring this number over time, you can directly conclude
how stable your network is.
These are the attributes of external EIGRP route block
Attribute

Meaning

Originating router Router ID of the router redistributing external route into this EIGRP process. The
router ID is an IP address that follows the same rules as the router ID for OSPF or
BGP.
AS number
AS number of originating BGP or EIGRP process.
External protocol The originating protocol from which the route was redistributed into EIGRP.
External metric
The metric of the redistributed route in the originating protocol. For routes
redistributed from OSPF this would be the OSPF cost, for RIP routes the hop count,
and for the EIGRP routes the composite metric.
Administrator tag 32-bit quantity that can be set in the redistribution point with a route map.
Command
show ip eigrp topology
active
show ip eigrp topology
pending

Printout
Displays only the routes for which the diffused computation is performed.
Provide approximate time route has entered active state and point out
potential bottlenecks.
Displays the routes that haven't converged yet (for example, diffused
computation is performed or outgoing updates are still pending)

Entries marked with r indicate a waiting reply whereas entries under Remaining replies
indicate routers (neighbors) that have not send any information regarding this route to this
router before.
Local-origin in query-origin indicate local router initiated query.
NOTE:
- EIGRP may prefer a locally connected subnet with higher FD than remote subnet with
lower FD due to local routes have a lower AD.
- When an EIGRP router has a route that can be reached using its loopback interface and
several other sources, blocking the loopback interface prevents packets for the route being
transported using other routes. This route now has no successor and infinite FD
- Routes with at least one good successor but ignored due to other sources or routing
information can be found with show ip eigrp topology zero-successor
The AD becomes the only mean to choosing routes when they are coming from two different
EIGRP processes. If they have the same AD, route that was changed more recently (latest
flap) takes precedence and replace the older route. Therefore, its mandatory to use
different AD for different EIGRP processes if they cover overlapping parts of your network.
To change the AD
To Change
Default distances for internal and external
routes in an EIGRP process
Distance of all internal routes received from
a neighbor or a set of neighbors
Distance of a select set of internal routes
received from a neighbor or a set of
neighbors

Use This Command

router eigrp <as distance> <default-internaldistance> <default-external-distance>
router eigrp <as> distance <distance> <neighborip-address> <wildcard-bits>
router eigrp <as> distance <distance> <neighborip-address> <wildcard-bits> <route-selectionACL>

Variance
Task
Configure unequal-cost load balancing
Configure proportional load balancing
between unequal-cost routes based on
composite metric
Use only minimum-cost routes for load
balancing, rest only for DUAL

Configure With
router eigrp <as> variance <factor>
router eigrp <as> traffic-share balanced

router eigrp <as> traffic-share min acrossinterfaces

Configure the maximum number of equal-cost route eigrp <as> maximum-paths <1 to 6>
or unequal-cost routes for a given destination
Configure per-packet load balancing over an interface <int> no ip route-cache
interface on all platforms
Configure Cisco Express Forwarding (CEF) per interface <int> ip route-cache cef ip load-sharing
source-destination pair load balancing
per-destination
Configure CEF per-packet load balancing
interface <int> ip route-cache cef ip load-sharing
per-packet
Switching Path
Process switching
Fast switching, Optimum
switching, Autonomous
switching, Silicon switching,
Netflow switching
Cisco Express Forwarding
Cisco Express Forwarding with
per-packet load sharing
configured

Load Sharing Mechanism

Per-packet load sharing
Per-prefix load sharing (for example, all traffic for a certain prefix in
the routing table flows over one interface)

Per source-destination-pair load sharing (for example, all traffic for a

certain source-destination IP address pair flows over one interface)
Per-packet load sharing

Variance:
- Calculate the variance needed for the path you wish to load balance against
- Always verify load-balancing works in both directions
- If there is more than one router connected to a LAN (or multiaccess network) and you
want to load-balance outgoing traffic from that LAN, you need additional mechanisms like
HSRP to select proper exit from LAN
- You can solve some load-balancing problems where load balancing intuitively works but
does not work in reality due to feasible successor limitations by introducing another layer
of routers to distribute the traffic.
Query should be limited in these types of situations:
- Query received when the route is already active
- Query received from the only successor with the router having no other EIGRP neighbor.
- Query received but the route is not in topology database
To reduce EIGRP query diameter, there are generally 2 methods:
- Reduce overall EIGRP AS size by enforcing hard boundaries such as using another routing
protocol.
- Establish query boundaries using EIGRP built-in features such as summarization and stub
routers.
EIGRP is a protocol that can take abuse before breaking, but a minor event can bring the
entire network down. On the other hand, you have to continuously monitor the network to
discover potential symptoms of EIGRP overload. Here are some tips:
- Use Syslog or any other logging tool to discover an SIA ASAP
- Monitor EIGRP traffic with show ip eigrp traffic on the core router. If query number is
high, its likely that some remote router cant be able to cope with all the queries
- Monitor the number of active routes and the time they stay in active state with show ip
eigrp topology active. If the time is long, it indicates a slow response and unstable
network if there are many routes.
Autosummarization never announce the subnets of one major network into another major
network. Only the major network prefix is announce with the metric of the closest subnet
(usually a directly connected interface). Logic:

- Whenever an EIGRP process has more than one network defined, it creates a summary
route for each of the defined networks as soon as at least one of the subnets of that
network is in the EIGRP topology table. This route point to Null0 and uses the smallest
metric of a subnet covered by the network.
- On router where autosummarization is configured, AD of summary route is 5. However,
remember that AD is local to a router.
- Subnets of the network are suppressed, only the major network is advertised
- Subnets that dont belong to any of the network listed in EIGRP process are not
summarized
Autosummarization also applies to external routes redistributed into EIGRP. Queries of
subnets pass through different networks as the subnet rather than the network (when its
summarized)
Manual summarization logic:
- For each summary range configured over any interface belonging to an EIGRP process,
EIGRP process creates a summary route for the summarization range as soon as at least
one more specific route falling within the summary range appears in EIGRP topology table.
- Summary route created above points to Null0 and minimum metric of all the more specific
routes covered by the summary route. Summary route is also inserted into the IP routing
table with an AD of 5
- More specific routes summarized are suppressed when updates are sent over the interface
where summarization range is configured. Updates send to other interfaces are not
affected.
Note: subnet with lowest metric must remain stable as flapping cause instability and induce
DUAL on router.

EIGRP route filters doesnt apply to all EIGRP packets; query packets are not affected at all.
All other EIGRP packets are affected by:
- Route received in update packet but rejected by distribute-list in is ignored
- Route in topology database but rejected by distribute-list out is not sent in outgoing
update packet
- Reply packet for a route filtered using distribute-list out is sent with infinite metric
- Reply packet for a route filtered using distribute-list in is processed as if it has infinite
metric
EIGRP route filters always create query boundaries because the router itself doesnt have an
entry in its topology database for some subnets filtered by inbound or outbound filters.
Default route has 2 sorts of behavior:
- Classless: if a default route exist and no more specific subnets has matched the
destination, default route is used.
- Classful: if a default route exist and no classful networks for which the destination belongs
to exist, the default route is used. If a subnet of that classful network exist, but doesnt
match the destination IP address, the packet is discarded.
Typically, classful works fine when all routes are known by the router. If not, the classless
method should be preferred.
Default candidate means that they mark the exit from the local routing environment
toward another layer that has more routing information. Default candidates are not used as
default routes themselves, IOS only use the least routing metric and least AD to choose the
best route. The next hop of the best default candidate becomes the gateway of last resort.
Command
Results
ip default-network Marks the network as default candidate in the IP routing table. Starts
<major-network>
redistributing the network in all IGRP and EIGRP processes. Marks the network
for connected networks in the EIGRP topology database with default candidate flag.
ip default-network Marks the network as default candidate in the IP routing table. If the network
<major-network>
is already in EIGRP topology database, marks the network with default
for nonconnected
candidate flag. Takes no further actions to insert the network into EIGRP
networks
topology database.
ip default-network Equivalent to ip route <major-network> <mask> <subnet>. Inserts the
<subnet>
summary route for the major network into which the subnet belongs in the
routing table.
EIGRP Router
Configuration Command
default-information in
<ACL>
default-information out
<ACL>
no default-information in
no default-information
out

Result
Erases the default candidate marker from all received routes not matched
by the IP access list <ACL>
Erases the default candidate marker from all routes not matched by
<ACL> when they are advertised to EIGRP neighbors
Does not accept any default candidate markers
Does not mark any routes as default candidates in outgoing updates. The
router itself still uses the default candidate markers on the routes in the
EIGRP topology database to select its own gateway of last resort.

Only routes from the source routing protocol that the router itself uses for packet
forwarding are redistributed into the target routing protocol. In other words, redistribution is
done from the routing table.
If two routing processes are carrying the same information with the same administrative
distance, the results are unpredictable. Usually, the route appearing last in the topology

database (the less stable route) overwrites the previous route that came into the routing
table from another routing protocol with the same administrative distance.
Switched WAN network provide more challenge to implementing EIGRP as no multicasting is
supported.
Challenge
Output drops due to
emulated multicasts

Build dynamic maps using

inverse ARP
Neighbors reachable over one
interface have to handled in
different ways

Solution
Extend the output queue
length
Divide the neighbors across
several subinterfaces
Configure broadcast queue
Neighbor maps are hard to
maintain

Applicable WAN Technology

All
All
Frame Relay
Use automatic PVC
discovery
Frame Relay and ATM
Use subinterfaces

Frame Relay

All

Multicasts can only be emulated by creating several copies of the unicast packets and send
to neighbors that have broadcast option configured on the DLCI. All the copies are created
at a time and send to the interface output queue in a burst. No shaping or rate limiting is
performed on these packets.
The results of these traffic bursts are usually output queue overloads, and associated
output drops whenever a large number of neighbors are reachable over the same interface.
Solution: subinterfaces
Another drawback is the significant amount of jitter introduced by large multicast traffic
bursts.
To design the Frame Relay broadcast queue, you should consider:
- The only multicast packets generated by EIGRP over Frame Relay are the hello packets
that are sent every hello-interval seconds and are approximately 40 bytes long unless
the Frame Relay network supports Frame Relay level multicasting configured with the
frame-relay multicast-dlci command.
- The maximum overall byte rate should not exceed one quarter of the local interface speed
(or access rate) to prevent local congestion. The per-neighbor byte rate (overall byte rate
divided by the number of neighbors) should not exceed one quarter of the slowest remote
access rate or one quarter of the smallest CIR to prevent remote congestion.
- The number of packets sent per second (packet-rate) should not exceed the output queue
size minus some safety margin. A good value in uncongested networks would be three
quarters of the output queue.
- The overall broadcast queue size must be large enough to prevent multicast packet drops.
EIGRP pacing prevents WAN link overload by emitting the EIGRP packets onto the WAN
link in predefined time intervals. When designing the network, you specify the overall
bandwidth available to EIGRP by using the bandwidth configuration command on the
interface to indicate physical or logical interface bandwidth and the ip bandwidth-percent
eigrp configuration command to indicate the interface bandwidth percentage available to
EIGRP.

Different intervals are used for reliable packets (update, query and reply), which can be as
large as MTU of the interface and for unreliable packets that have fixed length. Both pacing
interval are displayed in show ip eigrp interface

Minimum reliable_pacing_interval is 10 msec and there is no minimum for

unreliable_pacing_interval.
Bandwidth available to EIGRP over an interface is shared between all EIGRP neighbors
reachable over that interface. Round-robin mechanism is used. Every time EIGRP is allowed
to send another packet to the interface, a packet is emitted from a different per-neighbor
output queue. You can estimate the length of an individual per-neighbor output queue from
the Q Cnt field displayed with the show ip eigrp neighbor command
General EIGRP pacing design:
1. Compute VC_based_EIGRP_bandwidth = slowest_VC_speed *
EIGRP_bandwidth_percentage * number_of_neighbors
2. Compute physical_EIGRP_bandwidth = physical_interface_speed *
EIGRP_bandwidth_percentage
If the sum of all VCs bandwidth < physical interface bandwidth, design is complete. Use
VC-based EIGRP bandwidth to compute either bandwidth or ip bandwidth-percent eigrp
command. If the sum of all VCs bandwidth > physical interfaces bandwidth, reduce VCbased EIGRP bandwidth. The VC-based EIGRP bandwidth of all routers connected to the
other ends of affected VCs must also be adjusted to reduce the EIGRP load received by the
affected router.
EIGRP bandwidths on a virtual circuit must be symmetrical. The design rules compute the
EIGRP bandwidth available to outgoing traffic, but the same limitations have to apply to
incoming traffic, otherwise the incoming EIGRP traffic could overload your WAN link.
Whenever possible, you should use default routes or route summarization and not to disable
split horizon. Disabling split horizon increases EIGRP topology database on the remote
routers and the traffic generated.
Change split horizon settings on an interface ([no] ip split-horizon eigrp ASN) resets all the
adjacencies with EIGRP neighbors.
EIGRP implementations over Frame Relay usually suffer from the following symptoms:
- Slow convergence due to very long hello intervals and hold timers, unless you use pointto-point interfaces where the default values for hello interval and hold timer are 5 and 15
seconds
- Retransmissions and output drops due to misconfigured interface bandwidths or badly
designed EIGRP pacing
- Heavy EIGRP traffic due to nonscalable network design, lack of query boundaries, or
misplacement of the query boundaries

EIGRP implementations over ATM are usually straightforward; the speed of a typical ATM
link is usually high enough to make any EIGRP WAN-related issues irrelevant. However, a
few caveats do exist, even in the ATM environment:
- Similar to X.25, ATM uses map statements to specify mapping between ATM PVCs or ATM
NSAPs and the IP addresses of the remote routers. These map statements have to include
a broadcast option for EIGRP to work correctly.
- EIGRP does not work well if the ATM cloud is implemented with Classical IP over ATM (RFC
1577) encapsulation. Due to the way IP multicast packets are propagated within the ATM
network configured as Classical IP over ATM, EIGRP adjacencies are established only
between the ARP server and other routers, resulting in all the IP traffic being routed
through the ARP server.
EIGRP MD5 authentication assign every EIGRP packet with an MD5 hash, which:
- Changes half the hash if a single bit in the original message changes
- Make forge very hard to achieve
- Security relies exclusively on shared secret (password), which should be periodically
changed.

Key chain rules:

- If several keys have an overlapping send-lifetime, key with lowest sequence number are
used
- If several keys have an overlapping accept-lifetime, incoming packets can be signed with
any one of those keys.
Key number must match between routers to form neighborship
If R1 try to match the latter (in situation of 2 or more keys in the key chain) to check on
authentication, R2 can't establish authentication check regardless whether it had the
correct/wrong password, matching/unmatching key number/chain.
Note these shortcomings when designing a highly secure EIGRP network:
- EIGRP packets are only authenticated, not encrypted. The information exchange is
reliable, but not confidential. Intruder can still obtain information based on routing
information exchange
- Passwords must be manually configured
- Passwords are stored in router configuration in plain text format
EIGRP leaking routes allow a subnet, along with its aggregate, to be advertised. This is
done using ip summary-address eigrp ASN x.x.x.x y.y.y.y leak-map NAME command.
Note that if the route map is nonexistent, keyword has no effect. However, if the route
map exists but the ACL doesnt exist, or no ACL is referred, the summary address and all
subnets routes are sent.