EIGRP Neighbor Relationships and Adjacency Troubleshooting

Learn how EIGRP neighbors discover and maintain adjacencies, verify neighbor tables, configure IPv4 EIGRP, and troubleshoot timers, K values, authentication, and filtering.

EIGRP (Enhanced Interior Gateway Routing Protocol) is an advanced distance-vector routing protocol. Before two EIGRP routers can exchange routes, they must establish a neighbor relationship, also called an adjacency. This lesson explains neighbor discovery, adjacency requirements, verification, configuration, and a systematic troubleshooting process.

This lesson assumes familiarity with IP routing fundamentals, IPv4 addressing, router interfaces, and Cisco IOS command-line navigation. Review subnetting if the connected-network examples are unfamiliar.

Why EIGRP Neighbor Relationships Matter

A directly connected Layer 3 relationship does not automatically create an EIGRP adjacency. Two routers can have valid IP addresses on the same subnet and successfully ping each other while EIGRP remains inactive because of a process, interface, authentication, or packet-compatibility problem.

An EIGRP neighbor is a directly connected EIGRP-speaking router with which an adjacency has been successfully formed. The adjacency allows routers to:

Exchange topology information and route updates.
Build and refresh each router's topology table.
Deliver reliable updates, queries, and replies.
Provide the information DUAL uses to calculate loop-free paths.
Detect failures and begin route recomputation when a neighbor is lost.

The neighbor table, topology table, and IP routing table are separate. The neighbor table records active peers, the topology table records routes learned from those peers before selection, and the routing table contains routes selected for forwarding.

EIGRP Neighbor Discovery

EIGRP sends periodic hello packets on enabled, non-passive interfaces. Hello packets are used both to discover routers and to maintain existing relationships. For IPv4, EIGRP uses multicast address 224.0.0.10. For IPv6, it uses FF02::A.

An operational interface has an IP address and EIGRP is enabled on that interface.
The router sends EIGRP hello packets and listens for hellos from the connected segment.
When a compatible hello is received, the routers begin neighbor establishment.
Acknowledgments and other EIGRP transport information confirm communication and support reliable delivery.
The new adjacency is recorded in the neighbor table.
The routers exchange topology information through EIGRP updates.
DUAL evaluates the received routes, and eligible routes can be installed in the IP routing table.

EIGRP uses RTP (Reliable Transport Protocol) to provide both reliable and unreliable delivery. Hello packets normally do not require reliable retransmission. Updates, queries, and replies may require acknowledgments. RTP tracks packet sequence numbers and uses transport timing to retransmit reliable packets when necessary.

EIGRP Packet Types

Packet Type	Primary Purpose	Reliable Delivery	Role in Neighbor Operation
Hello	Discover and maintain neighbors	Normally no	Refreshes the hold timer
Acknowledgment	Confirm receipt of a reliable packet	Confirms reliable traffic	Supports RTP delivery
Update	Advertise route and topology information	May require acknowledgment	Fills or changes the topology table
Query	Ask neighbors for information about a route	Yes	Can be used during DUAL recomputation
Reply	Answer a query	Yes	Provides route information needed to complete recomputation
Request	Request specific routing information	May require acknowledgment	Supports information exchange in applicable implementations

EIGRP Adjacency Requirements

Both routers must be connected through a common Layer 3 subnet or shared network segment where EIGRP packets can reach the neighboring interface. The interface must be operational, correctly addressed, and included in EIGRP. The following settings must also be compatible.

Requirement	Must Match or Be Present	Effect When Incorrect	How to Verify
Layer 3 reachability and active interfaces	Interfaces are up, addresses are valid, and the routers share the expected subnet	Hellos cannot be exchanged	`show ip interface brief`, targeted `ping`
EIGRP enabled on the shared interface	The interface must participate in the correct EIGRP process	No EIGRP hellos are sent or accepted there	`show ip eigrp interfaces detail`
Classic AS number or named address family	Classic EIGRP neighbors use the same autonomous system number; named mode requires compatible process and address-family settings	Hellos are rejected or no adjacency forms	`show ip protocols`
K values	Metric weighting values must be compatible	Adjacency is prevented, commonly with a K-value mismatch message	`show ip protocols`
Authentication	Key chain, key ID, algorithm, and currently valid key material must agree	Authenticated packets are rejected	`show ip eigrp interfaces detail`, configuration and logs
Passive-interface state	The neighbor-facing interface must not be passive	Connected routes may be advertised, but no hellos are sent and no neighbor forms	`show ip protocols`
IP address family	Both sides must operate the same address family for the adjacency	IPv4 and IPv6 operation do not form one shared adjacency	IPv4 and IPv6 EIGRP configuration and show commands
Packet filtering and multicast reachability	ACLs, firewalls, and Layer 2 controls must permit EIGRP traffic and required multicast behavior	Hellos or reliable packets are dropped	ACL, firewall, interface counters, captures, and logs

In classic EIGRP, the autonomous system number is the EIGRP process identifier. It is not necessarily the organization's global Internet AS number. In named mode, the process name alone is not sufficient: the address-family configuration and autonomous-system settings must be compatible on both routers.

K values control how EIGRP calculates its composite metric. Different K values could cause routers to calculate incompatible metrics, so EIGRP prevents the adjacency when the values do not agree. Router IDs normally do not need to match; in fact, each router should have a unique router ID. Hello and hold timers also do not normally need to match because the hold value is communicated by the sending router.

Hello and Hold Timers

The hello interval is the time between hello packets. The hold time is the maximum time a router waits without hearing from a neighbor before declaring that neighbor down. Each received hello refreshes the neighbor's hold timer.

If the hold timer expires, the router removes the neighbor from its neighbor table. Routes learned through that neighbor may be marked unreachable, and DUAL may recompute paths. A feasible successor can allow rapid recovery without a broad query; otherwise, DUAL may send queries to other neighbors.

Neighbor Formation Sequence

Interface activation: The link is up, the interface has an appropriate address, and EIGRP is enabled.
Hello exchange: Each router sends and receives EIGRP hellos on the shared segment.
Compatibility check: The routers validate address family, AS or named-mode settings, K values, authentication, and other protocol information.
Adjacency creation: Each router adds the peer to its own neighbor table. Neighbor relationships are maintained independently on each participating interface.
Topology exchange: Reliable updates communicate route information, with acknowledgments handled by RTP.
DUAL calculation: EIGRP evaluates successors and feasible successors and installs appropriate routes.

The EIGRP Neighbor Table

The neighbor table is a per-process record of active EIGRP peers and transport statistics. On Cisco IOS, inspect it with show ip eigrp neighbors for IPv4 or show ipv6 eigrp neighbors for IPv6.

Field	Meaning	Normal Interpretation	Potential Warning Sign
Neighbor address	Address of the EIGRP peer	Matches the connected neighbor interface	Unexpected address or missing peer
Interface	Local interface used to reach the peer	Expected transit interface	Unexpected interface or interface flapping
Hold time	Time remaining before the peer is declared down if no hello arrives	Counts down and is refreshed by hellos	Repeatedly reaches zero or drops rapidly
Uptime	How long the current adjacency has existed	Continuously increases for a stable peer	Repeated resets or short-lived entries
SRTT	Smooth Round-Trip Time for EIGRP transport	Reflects transport response time	Large or rapidly changing values with retransmissions
RTO	Retransmission Timeout	Transport's wait before retransmitting reliable packets	Increasing values can accompany delay or loss
Queue count	Reliable packets waiting for delivery or acknowledgment	Usually zero or small	Persistent nonzero or growing queue
Sequence number	Transport sequencing information	Changes as reliable traffic is exchanged	Stalled progress or repeated retransmission symptoms

A stable neighbor normally has continuously increasing uptime, a hold timer that is refreshed, and little or no queued reliable traffic. A repeatedly resetting uptime, short-lived entries, nonzero queue counts, or unusual SRTT and RTO values deserve investigation.

Basic IPv4 EIGRP Configuration

This point-to-point example uses 192.0.2.0/30. R1 uses 192.0.2.1 and R2 uses 192.0.2.2. Both routers use classic EIGRP autonomous system 100.

R1

interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.252
 no shutdown
!
router eigrp 100
 network 192.0.2.0 0.0.0.3
 no passive-interface GigabitEthernet0/0

R2

interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 no shutdown
!
router eigrp 100
 network 192.0.2.0 0.0.0.3
 no passive-interface GigabitEthernet0/0

The wildcard mask in the network statement selects the interface address range. The no passive-interface command is important when a router-wide passive-interface policy is in use. A passive interface can advertise its connected network but does not send hellos or form neighbors.

Named-Mode IPv4 Example

router eigrp CAMPUS
 address-family ipv4 autonomous-system 100
  network 192.0.2.0 0.0.0.3
  no passive-interface GigabitEthernet0/0
 exit-address-family

Named mode organizes EIGRP configuration by address family. Use the syntax supported by the platform and software release, and ensure both routers use compatible named-mode address-family settings.

Optional Authentication Example

key chain EIGRP-KEYS
 key 1
  key-string ExampleSharedKey
!
interface GigabitEthernet0/0
 ip authentication mode eigrp 100 md5
 ip authentication key-chain eigrp 100 EIGRP-KEYS

Apply matching authentication settings at both ends. Compare the key chain, key ID, algorithm, and key validity period. Exact syntax and supported algorithms can vary by platform and software release.

Verification and Monitoring

show ip interface brief
show ip eigrp neighbors
show ip eigrp interfaces detail
show ip protocols
show ip eigrp topology
show ip route eigrp
ping 192.0.2.2
show logging

show ip interface brief confirms interface and protocol status.
show ip eigrp neighbors verifies IPv4 adjacencies.
show ipv6 eigrp neighbors verifies IPv6 adjacencies.
show ip eigrp interfaces detail shows participating interfaces, timers, authentication details where supported, and passive status.
show ip protocols displays process settings, networks, passive interfaces, and metric weights.
show ip eigrp topology helps determine whether routes were learned even if they were not selected.
show ip route eigrp confirms EIGRP routes installed in the routing table.
A targeted ping tests underlying IP connectivity, but a successful ping alone does not prove that EIGRP packets are compatible.

Use debug eigrp neighbors and debug eigrp packets only in a lab or controlled maintenance window. Debug output can be extensive and can consume router resources. Disable debugging after the test with the platform's debug-disable command, commonly undebug all.

Systematic Troubleshooting Workflow

Check interface state: Confirm the expected interface is up/up, has the correct IP address and mask, and has no physical or Layer 2 errors.
Confirm the shared subnet: Verify both routers are on the same connected Layer 3 network where an adjacency is expected. Use a targeted ping.
Confirm EIGRP participation: Use show ip eigrp interfaces detail to verify that the correct interface is enabled and is not passive.
Compare process settings: Check the classic AS number or the named-mode process and address-family configuration with show ip protocols.
Compare K values: Restore compatible metric weights on the neighbor-facing EIGRP processes.
Check authentication: Compare key chain, key ID, algorithm, key-string, and key validity. Authentication must be consistent on both ends.
Check packet handling: Inspect ACLs, firewalls, multicast controls, protocol filters, and interface counters. EIGRP hellos use multicast, and filtering can prevent discovery or reliable exchanges.
Check identity and platform details: Investigate duplicate router IDs and platform-specific address-family or feature behavior when the basic checks pass.
Use logs and focused debugging: Look for K-value mismatch, authentication failure, neighbor-down, hold-time expiration, and retransmission messages.

Common Symptoms

Symptom	Likely Causes	Verification Command or Check	Corrective Action
No neighbor entry	Down interface, wrong subnet, EIGRP disabled, AS mismatch, passive interface, K-value or authentication mismatch, filtering	`show ip interface brief`, ping, `show ip eigrp interfaces detail`, `show ip protocols`	Correct addressing, enable EIGRP, remove passive status, align process settings, authentication, and packet filters
Neighbor repeatedly resets	Intermittent hello loss, physical or Layer 2 instability, congestion, filtering, changing authentication	Neighbor uptime, interface counters, logs, queue, SRTT, and RTO	Repair the link, reduce loss or congestion, and correct policies or authentication
Hold time reaches zero	Hellos are not received before the advertised hold time expires	Neighbor output, logs, interface counters, packet filtering checks	Restore packet delivery; do not treat a timer mismatch alone as the primary cause
K-value mismatch message	Modified metric weights differ between routers	`show ip protocols`	Use compatible K values on both sides
Authentication failure	Different key, key ID, algorithm, or invalid key lifetime	Interface authentication configuration and logs	Align authentication configuration and valid key material
Routes absent despite expected adjacency	Neighbor has no eligible routes, filtering suppresses updates, or routes are not selected	`show ip eigrp topology`, `show ip route eigrp`, policy configuration	Confirm advertised networks, remove unintended filters, and investigate route selection
High queue count or retransmissions	Packet loss, delay, congestion, or an unreliable path	`show ip eigrp neighbors`, interface counters, logs	Investigate transport quality, errors, congestion, and filtering

Practical Troubleshooting Scenarios

No Neighbor Entry

If show ip eigrp neighbors is empty, begin with show ip interface brief and a ping to the neighbor's connected address. Then verify EIGRP interface participation, AS or named-mode compatibility, passive-interface state, K values, authentication, ACLs, firewalls, and multicast handling. Do not jump directly to route troubleshooting before confirming the adjacency.

Passive Interface

Suppose R1 and R2 have correct addresses and the same AS, but R1's transit interface is passive. R1 may still advertise the connected network in some configurations, yet it sends no hellos and cannot form the neighbor relationship. Apply no passive-interface to the transit interface, then verify the neighbor table.

K-Value Mismatch

If one router has customized metric weights and the other uses defaults, compare show ip protocols on both devices. Restore compatible K values on the neighbor-facing processes and verify that the adjacency forms. K values are not a tuning parameter to change on only one side.

Authentication Mismatch

Two routers can share a subnet and an AS while still rejecting one another's EIGRP packets. Compare the key chain, key ID, algorithm, key-string, and time validity. Correct both ends and check logs for accepted hellos and a new neighbor entry.

Hold-Time Expiration

When an established neighbor disappears as its hold timer reaches zero, investigate missed hellos rather than assuming a timer mismatch. Check physical errors, Layer 2 events, congestion, ACLs, firewalls, multicast handling, and EIGRP packet loss. Neighbor uptime that repeatedly returns to a low value is evidence of instability.

Neighbor Stability and Routing Operation

When a neighbor is lost, routes learned through that neighbor may become unavailable. DUAL checks for a feasible successor, which is a prequalified loop-free backup path. If none exists, DUAL can query other neighbors. A stable, well-designed neighbor relationship helps limit query scope and improves convergence; repeated adjacency loss causes repeated route calculations and can increase control-plane traffic.

Exam-Relevant Notes

Direct Layer 3 connectivity and an EIGRP adjacency are different conditions.
IPv4 EIGRP multicast is 224.0.0.10; IPv6 EIGRP multicast is FF02::A.
Classic EIGRP neighbors use the same AS number. Named mode requires compatible address-family configuration.
K values must be compatible; router IDs and hello/hold timers normally do not need to match.
A passive interface does not send hellos or form neighbors.
The hold timer is refreshed by received hellos; expiration removes the neighbor.
Verify the neighbor table before diagnosing missing learned routes.
Nonzero queue counts, repeated uptime resets, and short-lived adjacencies are warning signs.
RTP provides reliable transport behavior for applicable EIGRP packets through acknowledgments, sequencing, and retransmission.