Troubleshoot: EIGRP Neighbor Won't Form

EIGRP (Enhanced Interior Gateway Routing Protocol) is a Cisco-proprietary distance-vector routing protocol that uses a neighbor discovery mechanism based on periodic Hello messages. For two routers to become EIGRP neighbors, they must exchange Hello packets successfully and agree on several parameters. When a neighbor fails to form, the root cause almost always lies in one of a handful of areas: Layer 1/2 connectivity, IP addressing, EIGRP configuration (AS number, network statements, passive interfaces), authentication mismatch, K-value mismatch, or ACLs blocking EIGRP traffic.

The exam objective 3.5 (Troubleshoot EIGRP) expects you to methodically isolate the issue using show commands. Cisco's troubleshooting methodology is layered: start with physical connectivity, then Layer 3 reachability, then EIGRP-specific parameters.

EIGRP routers send Hello packets to the multicast address 224.0.0.10 every 5 seconds on most LAN interfaces (default Hello timer). On low-speed NBMA links (e.g., Frame Relay with bandwidth less than 1.544 Mbps), the default Hello timer is 60 seconds. The Hold timer is by default three times the Hello timer: 15 seconds for LAN, 180 seconds for low-speed NBMA.

The process: 1. Router A sends a Hello packet with its K-values, AS number, authentication data (if configured), and a list of neighbors it already knows. 2. Router B receives the Hello. It checks:

- The source IP must be on the same subnet as Router B's interface. - The AS number must match. - The K-values must match (though Cisco IOS by default uses 'metric weights 0 1 0 1 0 0', which is K1=1, K2=0, K3=1, K4=0, K5=0; any deviation must match exactly). - If authentication is configured, the key and algorithm (MD5 or SHA-256) must match. 3. If all checks pass, Router B adds Router A to its neighbor table and sends its own Hello back. 4. Both routers then transition to the INIT state, then to TWO-WAY (if they see their own Router ID in the other's Hello), and finally to FULL after exchanging topology tables via Update packets.

Troubleshooting focuses on the first two states. If you never see a neighbor reach 'Init', the problem is likely at Layer 1/2, ACL, or passive interface. If you see Init but not Two-way, check authentication or mismatched parameters.

The primary command is show ip eigrp neighbors. Example output:

R1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                           (sec)         (ms)       Cnt Num
0   192.168.1.2             GigabitEthernet0/0  12 00:01:23   1   100  0  5

Key fields: Hold (remaining hold time), Uptime (time since neighbor became FULL). If no neighbors appear, EIGRP is not receiving Hellos.

Other vital commands: - show ip eigrp interfaces – shows interfaces on which EIGRP is active. - show ip eigrp topology – shows route entries. - debug eigrp packets – use with caution in production; shows Hello, Update, Query, Reply packets. - show ip protocols – displays AS number, router ID, networks, passive interfaces, K-values.

Example output of show ip protocols:

R1# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 100"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP-IPv4 Protocol for AS(100)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
    NSF-aware route hold timer is 240
    Router-ID: 10.0.0.1
    Topology : 0 (base)
      Active Timer: 3 min
      Distance: internal 90 external 170
      Maximum path: 4
      Maximum hopcount 100
      Maximum metric variance 1

  Interfaces:
    GigabitEthernet0/0
    GigabitEthernet0/1
  Redistribution:
    None

EIGRP uses RTP (Reliable Transport Protocol) for Updates, Queries, and Replies, but Hello packets are sent unreliably via multicast. ACLs that deny 224.0.0.10 will block Hellos. Additionally, if a switchport has port security or VLAN mismatch, Layer 2 frames carrying EIGRP packets may be dropped. EIGRP also relies on the IP routing table for reachability; if a neighbor's interface is down, the route is removed.

In enterprise networks, EIGRP is often used in data center or campus environments where Cisco gear dominates. A typical scenario: a branch router connects to a headquarters router via a WAN link. The branch router is newly deployed, and the EIGRP neighbor won't form. The engineer starts with show ip eigrp neighbors on both ends — empty. Then show ip interface brief shows both interfaces up/up. Pings succeed. show ip protocols reveals that the branch router has a different AS number (100 vs 200) — the first misconfiguration. After correcting the AS, still no neighbor. show ip eigrp interfaces shows the WAN interface is not listed — the network statement uses a wildcard that doesn't match the interface subnet. Fixing the network statement brings the neighbor up.

Another scenario: a security team implements an ACL on the WAN edge router to block non-essential traffic. They copy a standard ACL that denies any any inbound, but forget to permit EIGRP. Suddenly, all EIGRP neighbors go down. The engineer uses show ip eigrp neighbors and sees nothing, then debug eigrp packets reveals no Hellos received. Checking the ACL with show ip access-lists shows the deny statement. Adding permit eigrp any any before the deny fixes it.

Performance considerations: EIGRP scales well up to hundreds of routers, but neighbor formation can be slow if the Hello timer is increased (e.g., on satellite links). The default timers are fine for most links. Misconfigurations like passive interface on a transit link are common when using passive-interface default and forgetting to enable the necessary interface. In production, always verify neighbor formation after any configuration change using show ip eigrp neighbors and monitor uptime.