Back to Learning
CCNA · 200-301Beginner

EIGRP Neighbor Down: AS Mismatch

A healthy link, an empty EIGRP neighbor table. Diagnose the mismatched AS number and fix it yourself, live, right below.

EIGRP Neighbor Down: AS Mismatch

R1 · R2

The problem

Two routers on the same subnet can ping each other directly, but their EIGRP adjacency never forms. Neither shows up in the other's neighbor table, and nothing about the interface or IP configuration looks wrong.

What you'll practice

  • Bring up a point-to-point EIGRP adjacency between two routers
  • Read show ip eigrp neighbors and verify neighbor state
  • Understand the EIGRP Autonomous System requirement
  • Correct a mismatched AS number on an EIGRP router instance
  • Verify adjacency and EIGRP-learned loopback reachability

1. Bring up a point-to-point EIGRP adjacency between two routers

EIGRP adjacency requires both routers to run the same routing process (AS number). Two routers on the same subnet with EIGRP configured won't exchange hellos unless their AS numbers match exactly.

2. Read show ip eigrp neighbors and verify neighbor state

Unlike OSPF's complex state machine (Init, 2-Way, ExStart, Exchange, Loading, Full), EIGRP neighbors are either listed as FULL or not listed at all. An empty neighbor table on an up/up link points to a configuration problem, not a transient state.

3. Understand the EIGRP Autonomous System requirement

Each EIGRP router process is tied to a single Autonomous System number (1-65535). Two routers in different AS numbers will not exchange EIGRP hellos, even if they're directly connected and configured for EIGRP on the same interface.

4. Correct a mismatched AS number on an EIGRP router instance

Changing a router's AS number requires removing the old router eigrp X instance and creating a new one with the correct AS number. Unlike OSPF area changes, the entire EIGRP process must be re-created.

5. Verify adjacency and EIGRP-learned loopback reachability

Once AS numbers match, check show ip eigrp neighbors to confirm FULL adjacency, then verify the remote loopback is learned via EIGRP (show ip route eigrp) and reachable via ping.

The topology

R1 and R2 connect over a single point-to-point /30 link and each advertise a loopback into EIGRP, the minimum topology needed to isolate an adjacency problem to the routing protocol itself.

Commands to run yourself

The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.

Confirm the interface is up/up
show ip interface brief
Confirm direct Layer 3 reachability
ping 10.0.12.2
Check for a formed EIGRP adjacency
show ip eigrp neighbors
Check the router's EIGRP AS configuration
show run | include router eigrp
Check the console/log buffer for an EIGRP error
show logging | include EIGRP
Confirm the route is EIGRP-learned, not static
show ip route eigrp

Topology diagram

Locked

Enter your email to see the root cause behind EIGRP Neighbor Down: AS Mismatch, free.

No spam. The root cause lands in your inbox too. The full fix is part of the Learning Pass.

Frequently asked

Is this real Cisco IOS or a simulator?

Real Cisco IOS on virtualized router platforms, full CLI behavior including console log messages on protocol rejections, not a simulated subset like Packet Tracer.

Does this cover the CCNA 200-301 EIGRP topics?

Yes. Forming a basic EIGRP adjacency and troubleshooting why one won't come up are explicit CCNA 200-301 routing blueprint items, and this lab is scoped directly to that.

How is this different from the OSPF lab?

Both cover neighbor adjacency problems, but the root cause is different: OSPF requires matching areas, EIGRP requires matching AS numbers. Seeing both patterns teaches you to debug routing protocol state independently.

Ready to run this lab yourself?

No setup, no image sourcing. Book a session or ask for a live demo.