CCNA online course

EIGRP Neighbors and Neighbor Adjacencies

Learn how Cisco EIGRP discovers neighbors, forms and maintains adjacencies, verifies neighbor status, and troubleshoots failed IPv4 neighbor relationships.

An EIGRP neighbor is a directly connected router with which EIGRP has formed an active adjacency. An adjacency is the established relationship that allows routers to exchange EIGRP routing information.

EIGRP does not exchange route information with every router that happens to run EIGRP. The routers first discover each other, verify compatibility, and create a neighbor-table entry. Only then can they exchange routing updates.

How EIGRP Neighbors Are Discovered

EIGRP uses periodic Hello packets for neighbor discovery and keepalive behavior. For IPv4, EIGRP control traffic normally uses the multicast address 224.0.0.10. EIGRP uses IP protocol number 88, not TCP or UDP.

A router sends Hellos through an EIGRP-enabled, non-passive interface. When another router on the shared segment receives a compatible Hello, it can begin forming an adjacency. Hello packets are normally sent periodically and are normally not acknowledged. Other EIGRP packet types use EIGRP Reliable Transport Protocol behavior when reliable delivery is required.

What “directly connected” means

Neighbor relationships are local to a directly connected Layer 3 segment. A router does not normally form an EIGRP adjacency with a peer several routed hops away. Both interfaces must be part of the same reachable segment, and their primary IPv4 addresses normally need to be in the same subnet.

Adjacency Formation Requirements

Receiving a Hello is not enough by itself. The routers must agree on the settings that define the EIGRP relationship.

Adjacency Lifecycle

1. Interface readiness: The physical interface and data-link protocol become operational.
2. Hello transmission: EIGRP sends Hellos through the enabled interface to 224.0.0.10.
3. Compatibility validation: The routers compare process or address-family context, K-values, authentication, and relevant capabilities.
4. Neighbor entry: A successful peer is recorded in the neighbor table.
5. Routing exchange: EIGRP exchanges routing information and builds topology information.
6. Maintenance: Periodic Hellos refresh the neighbor's hold timer while reliable packets are acknowledged or retransmitted as needed.

If a neighbor is removed, EIGRP may recalculate its topology and converge on alternate routes. A neighbor can disappear because of hold-time expiration, interface failure, manual shutdown, configuration incompatibility, authentication failure, or sustained packet loss. On platforms that support it, a graceful shutdown or goodbye behavior can notify the peer that the relationship is being intentionally closed.

The EIGRP Neighbor Table

The neighbor table lists currently active and compatible EIGRP peers. It is not the same as the topology table or the routing table.

• Neighbor table: Lists EIGRP peers and transport information for maintaining each adjacency.
• Topology table: Stores EIGRP route information learned from neighbors, including feasible successors and route states.
• Routing table: Contains the best routes selected for installation and forwarding.

Use show ip eigrp neighbors to inspect the basic table. A typical output contains fields similar to these:

Hello and Hold Timers

The Hello interval is the expected periodicity of Hello messages. The hold timer is the maximum time a router waits without receiving a valid Hello before declaring the neighbor unreachable.

A received Hello advertises the hold time that the receiving router should use to track that neighbor. This means a router can use the peer's advertised hold value rather than assuming that both sides use identical local timer settings.

Common Ethernet and point-to-point defaults on many Cisco platforms are often a 5-second Hello interval and a 15-second hold time, but defaults vary with platform, interface type, and configuration. Always verify the actual values instead of relying on a memorized default.

Hello and hold values do not generally have to be identical for an adjacency to form. However, inconsistent settings change failure-detection behavior. A short hold time can detect failures faster but is more sensitive to delay and packet loss; a longer hold time is more tolerant but can delay detection.

EIGRP Reliable Transport Behavior

RTP, or EIGRP Reliable Transport Protocol behavior, provides both reliable and unreliable delivery. It is an EIGRP mechanism, not the unrelated Real-time Transport Protocol used by some applications.

Reliable packets carry sequence information. The receiver acknowledges them, and the sender retransmits packets when acknowledgments do not arrive. SRTT measures smoothed round-trip behavior and helps EIGRP calculate the RTO, or retransmission timeout. The neighbor's Q count shows how many EIGRP packets are waiting for reliable transmission. A Q count that remains above zero can indicate loss, congestion, one-way communication, or filtering.

Classic IPv4 EIGRP Configuration

In classic configuration, a router eigrp process and an autonomous system number are created. A network statement enables EIGRP on interfaces whose primary IPv4 addresses match the statement. Those connected networks are also eligible to be advertised by that EIGRP process.

R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip address 10.12.12.1 255.255.255.0
R1(config-if)# no shutdown
R1(config)# router eigrp 100
R1(config-router)# network 10.12.12.0 0.0.0.255
R1(config-router)# no auto-summary

R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip address 10.12.12.2 255.255.255.0
R2(config-if)# no shutdown
R2(config)# router eigrp 100
R2(config-router)# network 10.12.12.0 0.0.0.255
R2(config-router)# no auto-summary

The no auto-summary command is included for legacy IOS compatibility. It may be unnecessary or unavailable on newer platforms.

Named-Mode EIGRP and Interface Participation

Named EIGRP uses a process name and an address-family context. The exact syntax depends on the IOS family and supported feature set.

R1(config)# router eigrp CAMPUS
R1(config-router)# address-family ipv4 unicast autonomous-system 100
R1(config-router-af)# network 10.12.12.0 0.0.0.255
R1(config-router-af)# af-interface GigabitEthernet0/0
R1(config-router-af-interface)# no shutdown

Passive Interfaces

A passive interface does not send EIGRP Hellos and does not form an adjacency. In classic EIGRP, a passive interface can still advertise its connected network when it matches a network statement. This makes passive interfaces useful on user-facing LANs: the subnet can be advertised without accepting routing neighbors from end hosts.

R1(config)# router eigrp 100
R1(config-router)# passive-interface default
R1(config-router)# no passive-interface GigabitEthernet0/0

This pattern suppresses neighbor formation on all EIGRP-enabled interfaces except the transit interface toward the intended router. Accepting routing neighbors on untrusted segments can expose the network to unauthorized route advertisements, so use authentication and carefully selected active interfaces where appropriate.

Optional Manual Neighbors

Manual neighbor configuration is a special-case feature for environments where multicast or broadcast delivery is unavailable or restricted, such as certain non-broadcast networks. It is not the normal method for an Ethernet deployment. Prefer automatic Hello discovery on ordinary shared Ethernet segments, and verify platform-specific behavior before using manual neighbors.

Verification and Monitoring Commands

show ip eigrp neighbors
show ip eigrp neighbors detail
show ip eigrp interfaces
show ip eigrp interfaces detail
show ip protocols
show ip eigrp topology
show ip route eigrp
show running-config | section router eigrp
show running-config interface GigabitEthernet0/0

• show ip eigrp neighbors confirms whether an active adjacency exists and displays address, interface, hold time, uptime, SRTT, RTO, Q count, and sequence information.
• show ip eigrp interfaces detail helps validate EIGRP participation, Hello and hold settings, and peer counts.
• show ip protocols confirms the classic autonomous system or protocol context, network statements, passive interfaces, timers, and metric weights.
• show ip eigrp topology displays learned EIGRP topology information, which is different from the neighbor table.
• show ip route eigrp shows EIGRP routes actually installed in the IPv4 routing table.

Troubleshooting Failed Adjacencies

Use a bottom-up workflow. Do not begin by clearing neighbors; first identify which requirement is failing.

1. Check interface state: Use show ip interface brief and show interfaces. Confirm that the interface is up and the line protocol is up. Investigate errors, drops, flaps, speed, and duplex conditions where applicable.
2. Check addressing: Confirm both primary IPv4 addresses, masks, and directly connected subnet membership. Test basic reachability with a ping, but remember that a successful ping does not prove that EIGRP traffic is allowed.
3. Check EIGRP enablement: Use show ip eigrp interfaces and the running configuration to confirm that the transit interface participates in EIGRP.
4. Check process or address-family compatibility: Compare the classic AS number, named-mode address family, VRF, and protocol settings.
5. Check passive status: Confirm that neither transit interface is passive. Review passive-interface default and any no passive-interface exceptions.
6. Check K-values: Compare metric weights with show ip protocols. Restore matching values rather than changing one side only.
7. Check authentication: Compare interface-level authentication settings, key material, and key-chain usage. One missing or different credential can prevent packets from being accepted.
8. Check filtering and packet delivery: Inspect ACLs, control-plane policies, firewall rules, multicast handling, and switch or provider restrictions. Where filtering exists, permit IP protocol 88 and the required multicast behavior for 224.0.0.10.
9. Use logging and scoped debugging: Examine show logging. If show commands are insufficient, use debugging briefly and in a controlled window.

Useful diagnostics

debug eigrp packets hello
debug eigrp packets
undebug all

Use debugging only in controlled conditions. It can generate substantial output and affect device performance. A missing neighbor often indicates that Hellos are not arriving or are not accepted. A neighbor that repeatedly resets often indicates hold-time expiration, authentication problems, link instability, or intermittent filtering. A rising SRTT, RTO, or persistent Q count points toward reliable-transport trouble rather than simple discovery failure.

Clearing neighbors or restarting the EIGRP process is disruptive because it forces adjacency and route reconvergence. Use those actions deliberately, preferably after collecting evidence and correcting the underlying cause.

Timers, Failure Detection, and BFD

Hello and hold timers provide ordinary EIGRP failure detection. Networks that require faster detection can use an optional mechanism such as Bidirectional Forwarding Detection (BFD), when supported and properly configured. BFD supplements rather than replaces understanding of EIGRP Hellos, adjacency compatibility, and reliable packet delivery.

Basic Adjacency Example

Suppose R1 uses 10.12.12.1/24 and R2 uses 10.12.12.2/24 on their connected GigabitEthernet interfaces. Both run classic EIGRP AS 100, both interfaces are up and non-passive, and their K-values and authentication settings match.

After Hello exchange, each router should show one neighbor. The neighbor address should be the other router's interface address, the interface should identify the transit link, uptime should increase, hold time should refresh, and Q count should normally remain zero.

Common variations

• If R1 uses AS 100 and R2 uses AS 200, IP connectivity alone will not create an adjacency.
• If R1's transit interface is passive, R1 will not send Hellos and the peer will be absent.
• If Hellos are blocked or lost, the existing peer can disappear when its hold timer expires.
• If authentication differs, packets may arrive but fail validation.
• If K-values differ, EIGRP rejects the incompatible relationship until the metric weights match.

Key Points to Remember

• EIGRP exchanges routing information after a neighbor adjacency is established.
• IPv4 EIGRP uses Hellos, multicast 224.0.0.10, and IP protocol 88.
• A configured EIGRP interface is not automatically an active neighbor.
• Neighbors normally share a directly connected Layer 3 segment and compatible primary subnet addresses.
• Classic AS numbers, address-family context, K-values, authentication, passive status, VRF, and capabilities must be compatible.
• The neighbor table, topology table, and routing table answer different operational questions.
• Hold-time expiration, resets, SRTT, RTO, and Q count provide important troubleshooting clues.
• Use passive interfaces and authentication to reduce unwanted or unauthorized adjacency formation.

For foundational protocol layering, review the OSI Reference Model. You can also compare EIGRP neighbor behavior with OSPF configuration and adjacencies and revisit computer network fundamentals.