The neighbors are up, the interfaces are clean, and yet a route that should be in the table simply is not. Missing-route problems are sneakier than adjacency problems because nothing is visibly broken; the protocol is running exactly as configured, and the configuration is quietly wrong. This guide is a systematic walk through every place an EIGRP route can go missing, with real failure output from a CML lab. Adjacency problems are the prerequisite check, covered in troubleshooting EIGRP neighbor adjacencies; protocol fundamentals live in the EIGRP complete guide.
Follow the Route: The Five Places It Can Die
A prefix travels a pipeline: covered by a network statement on the source router, advertised out an interface, accepted by the neighbor, chosen by DUAL, installed in the RIB. It can die at each stage, and the fastest troubleshooting order matches the pipeline. The single most useful triage question: is the route in the topology table (show ip eigrp topology) but not the routing table, or not in the topology table at all? Topology-but-not-RIB points at administrative distance or a better competing source. Missing from topology entirely points at the source, a filter, or split horizon.
Cause 1: The Network Statement Does Not Cover the Interface
EIGRP's network command selects interfaces, not prefixes: any interface whose address falls inside the statement gets enabled, and its connected network gets advertised. The two classic mistakes are a wildcard mask that does not cover a new interface, and assuming a classful network 10.0.0.0 statement was narrower than it is. Check what the process actually matched:
R3# show ip protocols | section eigrp
Routing Protocol is "eigrp 100"
Routing for Networks:
3.3.3.3/32
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
10.0.13.1 90 00:00:57
10.0.35.1 90 00:00:57If the interface holding the missing prefix is not covered under Routing for Networks, nothing downstream matters. show ip eigrp interfaces confirms which interfaces EIGRP is actually running on. Named mode uses the same network statements (syntax differences are in the EIGRP configuration guide).
Cause 2: A Distribute List Is Eating It
This one hides in plain sight because the router is doing exactly what someone once told it to do. In the lab, R3 filters two of its four /24s, and R1 comes up short:
R1# show ip route eigrp | include 10.1.
D 10.1.0.0/24 [90/3584000] via 10.0.13.2, 00:02:18, Ethernet0/2
D 10.1.1.0/24 [90/3584000] via 10.0.13.2, 00:02:18, Ethernet0/2Where did 10.1.2.0/24 and 10.1.3.0/24 go? One command on the advertising router answers it:
R3# show ip protocols | include filter
Outgoing update filter list for all interfaces is (prefix-list) BLOCK-LAB-NETS
Incoming update filter list for all interfaces is not set
R3# show ip prefix-list BLOCK-LAB-NETS
ip prefix-list BLOCK-LAB-NETS: 3 entries
seq 5 deny 10.1.2.0/24
seq 10 deny 10.1.3.0/24
seq 15 permit 0.0.0.0/0 le 32Check both routers: an out filter on the advertiser and an in filter on the receiver produce identical symptoms. Distribute lists, prefix lists, and route maps each have their own show commands, and the full filtering toolkit is covered in EIGRP route filtering with distribute lists and route maps.
Cause 3: A Summary Is Suppressing It
Summarization deliberately hides component routes, and sometimes it hides more than intended. The fingerprint: the specific prefix is missing but a covering summary is present:
R2# show ip route eigrp | include 10.1.
D 10.1.0.0/22 [90/4096000] via 10.0.12.1, 00:00:16, Ethernet0/1Nothing is unreachable here, and that is what makes it subtle: traffic still flows via the /22, but through whatever path the summary takes, which after a topology change may not be the path you expect. The extreme case is a default-route summary: summary-address 0.0.0.0/0 suppresses every more-specific prefix on that interface, and neighbors with a second path suddenly prefer wildly indirect specifics from elsewhere. We captured exactly that effect in the summarization and default routes guide. Find the suppression on the advertising router with show run | include summary-address and look for the telltale Null0 entry:
R3# show ip route | include Null0
D 10.1.0.0/22 is a summary, 00:00:24, Null0Cause 4: Split Horizon on a Hub
Split horizon forbids advertising a route out the interface it was learned on. On point-to-point links it is invisible protection. On a hub-and-spoke topology where two spokes share the hub's single multipoint interface (DMVPN, classic frame relay, some tunnel designs), it means spoke A's routes are never advertised to spoke B: both live on the same hub interface. The fix belongs on the hub:
Hub(config)# interface Tunnel0
Hub(config-if)# no ip split-horizon eigrp 100In named mode it is no split-horizon under the af-interface. If spokes can see the hub's routes but never each other's, split horizon should be your first suspicion. (Tunnel topologies stack additional quirks on top; see routing protocols over GRE.)
Cause 5: The Route Lost to a Better Source
Sometimes EIGRP has the route and the RIB still shows something else. Administrative distance decides: EIGRP internal 90, external 170, and anything with a lower AD (a static at 1, OSPF at 110 loses to internal but external EIGRP loses to OSPF) takes the slot. The diagnostic is comparing tables:
R1# show ip eigrp topology 10.1.0.0/24
...State is Passive, 1 Successor(s), FD is 458752000...
R1# show ip route 10.1.0.0 255.255.255.0
Known via "static", distance 1, metric 0An EIGRP route present in topology but beaten in the RIB is working as designed; the question becomes whether that static (or that redistributed route at AD 170) should exist. The AD ladder and its edge cases are laid out in EIGRP administrative distance, and the external-route AD interplay matters most at redistribution boundaries with OSPF or BGP.
Cause 6: A Stub Router Is Not Advertising What You Think
An EIGRP stub advertises only connected and summary routes by default. If a spoke learned a route from one neighbor and you expect it to pass it to another, stub configuration says no, silently and by design. The neighbor's view exposes it:
R1# show ip eigrp neighbors detail
1 10.0.13.2 Et0/2 14 00:01:27 1 100 0 5
Version 28.0/2.0, Retrans: 1, Retries: 0, Prefixes: 6
Topology-ids from peer - 0
Topologies advertised to peer: baseOn a real stub peer, this output includes a line like Stub Peer Advertising (CONNECTED SUMMARY) Routes plus Suppressing queries. When a route is missing beyond a spoke, check whether the spoke is a stub before checking anything else on it. Design intent and configuration are in EIGRP stub routing.
Cause 7: Redistribution Without a Metric
The classic-mode trap that has consumed entire afternoons: routes redistributed into EIGRP from another protocol arrive with no EIGRP metric of their own, and classic EIGRP assigns them an infinite metric by default. Infinite metric means the route is not advertised at all. No error, no log; the redistribute ospf 1 line sits in the config looking correct while producing nothing.
R1(config)# router eigrp 100
R1(config-router)# redistribute ospf 1
! Nothing appears anywhere. Now with seed metric:
R1(config-router)# redistribute ospf 1 metric 10000 100 255 1 1500The five seed values are bandwidth, delay, reliability, load, and MTU; default-metric under the process does the same job for all redistributed sources at once. Named mode softened this trap by applying a default seed metric for some sources, but relying on that is how configs break during migrations; set the seed explicitly, always. Redistributed routes then appear as D EX with AD 170, which feeds directly into the AD competition in Cause 5: an external EIGRP route loses to OSPF's 110, so redistributing into EIGRP at one boundary and expecting it to win against OSPF at another is a design error, not a bug. Two-way redistribution between OSPF and EIGRP at multiple points needs route tags and filtering to avoid loops, which is its own article-sized topic.
Cause 8: auto-summary (the Legacy Landmine)
On modern IOS XE, no auto-summary is the default and this cause is nearly extinct, but older gear and pasted-forward configs keep it alive. With auto-summary enabled, EIGRP summarizes to classful boundaries wherever a network statement crosses one: your 10.1.2.0/24 becomes 10.0.0.0/8 as it leaves the site. The symptom is distinctive: a huge classful prefix in tables where you expected specifics, and traffic to discontiguous subnets of the same major network blackholing (two sites both advertising 10.0.0.0/8 toward the core). One glance at show ip protocols settles it:
R3# show ip protocols | include Automatic
Automatic Summarization: disabledIf that line says enabled on anything in your path, add no auto-summary and move on with your life.
The Method, End to End
- Confirm adjacencies first; a missing neighbor explains everything downstream.
- On the source router:
show ip protocols(Routing for Networks),show ip eigrp interfaces. Is the prefix even entering EIGRP? - Walk the path router by router with
show ip eigrp topology <prefix>. The first router where it disappears is where the problem lives. - On that router:
show ip protocols | include filter,show run | include summary-address, stub status inshow ip eigrp neighbors detail, split horizon on multipoint interfaces. - If topology has it but the RIB does not: compare administrative distances and look for competing sources.
Key Takeaways
- Split the problem in half immediately: topology table versus routing table tells you whether to hunt upstream (source, filters, split horizon) or locally (AD, competing protocols).
show ip protocolsis the densest triage screen in IOS: networks covered, filters active, sources learned from, and AD, all in one page.- Missing routes usually mean someone configured exactly this: a filter, a summary, or a stub. The router is obeying; find the instruction.
- Split horizon on multipoint hub interfaces is the classic spoke-to-spoke route killer.
- Walk the path prefix-first with
show ip eigrp topology <prefix>; the first router where it vanishes owns the answer.
Missing routes are where EIGRP troubleshooting turns into detective work, and the pipeline model keeps the search finite. For everything upstream of the mystery, from DUAL to design patterns, the EIGRP complete guide is home base.
