This document provides troubleshooting information for common problems
with Enhanced Interior Gateway Routing Protocol (EIGRP). For more information,
or to go to the next flowchart, refer to the links provided in this
This document is not restricted to specific software and hardware
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
In order to troubleshoot EIGRP, use this flowchart, starting at the box
marked Main. Depending on the symptoms, the flowchart might
refer to one of the three flowcharts later in this document or to other
relevant documents on Cisco.com. There are some problems that might not be
resolvable here. In these cases, links are provided to Cisco Technical Support.
In order to open a service request, you must have a valid service
Note: If you are not able to ping successfuly between neighbors, run the
ip packet command in order to verify if the hellos are
sent to Multicast Address 18.104.22.168.
Note: For example:
R1#debug ip packet
IP packet debugging is on
*Mar 1 00:10:54.643: IP: s=10.10.10.1 (local), d=22.214.171.124 (FastEthernet0/0), len 60,
*Mar 1 00:10:58.611: IP: s=10.10.10.2 (FastEthernet0/0), d=126.96.36.199, len 60, rcvd 2
!--- Indicates that the hello packets are sent to 188.8.131.52.
Issue the show ip eigrp interface
command to verify.
Issue the show interface serial
command to verify. If the interface is not listed, ensure it is not a passive
interface. If passive-interface default is enabled, then the interface needs to
be manually removed from the passive-interface list with the no
passive-interface <interface> command.
Note: If you experience the problems with EIGRP flapping across the GRE
interface tunnel, it is possible that you have to configure the
keepalive 10 3 and ip tcp adjust-mss
1400 commands at both ends of the GRE tunnel. .
Issue the show ip eigrp topology
command to verify. If routes are not seen in the topology table, issue the
clear ip eigrp topology command.
Issue the show ip eigrp topology
to find the Router ID (RID). You can find the local RID with the same command
on the locally generated external router. In Cisco IOS Software Release 12.1
and later, the show ip eigrp topology command shows
The stability of the neighbor relationship is of primary concern. A
failure in the neighbor relationship is accompanied by increased CPU and
bandwidth utilization. EIGRP neighbors can flap for these reasons:
Underlying link flaps. When an interface goes down, EIGRP takes down
the neighbors that are reachable through that interface and flushes all routes
learned through that neighbor.
Misconfigured hello and hold intervals. The EIGRP hold interval can
be set independently of the hello interval if you issue the ip
hold-time eigrp command. If you set a hold interval smaller than
the hello interval, it results in the neighbors flapping continuously. Cisco
recommends that the hold time be at least three times the hello interval. If
the value is set less than 3 times the hello interval, there is the chance for
link flapping or neighborship flapping.
Loss of hello packets: Hello packets can be lost on overly congested
links or error-prone links (CRC errors, Frame errors, or excessive
Existence of unidirectional links. A router on a unidirectional link
can be able to receive hello packets, but the hello packets sent out are not
received at the other end. The existence of this state is usually indicated by
the retry limit exceeded messages on one end. If the routers generating retry
limit exceeded messages has to form neighborship, then make the link
bidirectional for both unicast and multicast. In case tunnel interfaces are
used in the topology make sure that the interfaces are advertised
Route goes stuck-in-active. When a router enters the stuck-in-active
state, the neighbors from which the reply was expected are reinitialized, and
the router goes active on all routes learned from those
Provision of insufficient bandwidth for the EIGRP process. When
sufficient bandwidth is not available, packets can be lost, which causes
neighbors to go down.
The EIGRP neighbor relationship is not established over the multipoint
GRE tunnel if there is an incorrect NHRP association in the spoke. Next Hop
Resolution Protocol (NHRP) is used to discover the addresses of other routers
and networks behind the routers that are connected to a nonbroadcast
multiaccess (NBMA) network. When a network statement under Eigrp covers both
the physical interface and tunnel interface (tunnel interface ip address and
physical interface ip address belong to the same major class) and if the
phyiscal interface is the source of the tunnel, then the both interfaces have
to be separately advertised in the Eigrp to avoid issues with DMVPN. The best
practice is to advertise the interfaces using specific subnet advertisements.
This issue can be resolved when you clear the NHRP associations with