EIGRP Stub Routing for Hub-and-Spoke

EIGRP stub routing is the feature that makes hub-and-spoke topologies sane. Without it, a hub router with hundreds of spokes queries every spoke during DUAL active states, propagating control-plane traffic that the spokes cannot meaningfully reply to. With it, spokes are explicitly told they are dead-ends - the hub does not query them and they do not advertise transit routes.

This article walks through what stub routing does, the five stub options and what each advertises, when to use stubs, the impact on DUAL queries, and the configuration patterns. If you are designing or operating a hub-and-spoke EIGRP network, this is the feature that determines whether your hub router has a peaceful day or a constant stream of SIA events.

What Stub Routing Does

EIGRP stub routing modifies two behaviors at the spoke router:

1. Restricts what the spoke advertises. The spoke only sends specific route types (configurable). It does not act as a transit router for routes learned from other neighbors.
2. Tells the hub not to query the spoke during DUAL active states. The hub knows the spoke cannot offer alternative paths, so queries are wasted.

The combined effect: a hub-and-spoke network with N spokes does not generate N queries when a route enters Active state. Convergence is faster; the hub CPU stays sane; SIA events become rare.

The Problem Without Stub

Imagine a hub router with 200 spokes. Each spoke is a branch with two interfaces: one to the hub and one to local users. The hub knows every spoke's local networks via EIGRP.

Now a route somewhere in the broader network changes and the hub loses a path. If no Feasible Successor is cached, the route enters Active state and the hub queries all neighbors - including all 200 spokes.

Each spoke receives the query. The spokes have no useful answer (they have one path: through the hub). Each spoke sends a "no match" reply. The hub processes 200 replies. Meanwhile any spoke that takes too long to reply triggers SIA logic.

Multiply this by every flapping route across the network. The hub's CPU pegs; legitimate traffic suffers; the network feels unstable.

Stub routing eliminates this problem. The hub knows from the start that spokes have no useful information for queries; it does not ask.

The Five Stub Options

The defaults if you specify eigrp stub with no options: connected summary. Most production hub-and-spoke deployments use exactly this default - the spoke advertises its directly-connected branch networks (and any summary routes you have configured) and nothing else.

The five options are not mutually exclusive; you can combine them. eigrp stub connected static advertises both directly-connected and static routes.

receive-only: The Strictest Form

The receive-only option is special. It tells the spoke to listen for EIGRP updates but advertise nothing - not even its directly-connected networks. The spoke is purely a downstream consumer of routes.

Use cases:

• The hub needs to push a default route to the spoke; the spoke needs no upstream visibility
• Branch sites with no locally-originated services (every server lives at HQ)
• Read-only environments where local routes must not propagate

Less common than connected summary but useful for specific designs.

Configuration

! Classic mode on the spoke
router eigrp 100
 network 10.0.0.0 0.0.255.255
 eigrp stub connected summary
 no auto-summary

! Named mode on the spoke
router eigrp PROD
 address-family ipv4 unicast autonomous-system 100
  network 10.0.0.0 0.0.255.255
  eigrp stub connected summary
 exit-address-family

That is it. One line declares the router as a stub. The hub automatically detects this via the EIGRP Hello packet's K-value-and-stub-flag and adjusts its query behavior.

No configuration on the hub is required to make stub routing work. The hub reads the spoke's stub flag from Hello packets and updates its query lists accordingly.

Verification

On the spoke:

Spoke# show ip eigrp neighbors detail
EIGRP-IPv4 Neighbors for AS(100)
H   Address      Interface  Hold  Uptime    SRTT   RTO  Q  Seq Num
0   10.0.0.1     Gi0/0/0    14    01:23:45  10     200  0  234
   Stub Peer Advertising (CONNECTED, SUMMARY) Routes
   Suppressing queries

The "Stub Peer" line confirms the spoke is acting as a stub. "Suppressing queries" confirms the hub will not query this neighbor during DUAL active states.

On the hub looking at a spoke:

Hub# show ip eigrp neighbors detail
EIGRP-IPv4 Neighbors for AS(100)
H   Address      Interface  Hold  Uptime    SRTT   RTO  Q  Seq Num
0   10.0.10.2    Gi0/0/0    14    01:23:45  10     200  0  234
   Stub Peer Advertising (CONNECTED, SUMMARY) Routes
   Suppressing queries

Same output - the stub status is symmetric and visible from both sides.

Design Patterns

Three stub patterns dominate production:

1. Standard branch. eigrp stub connected summary. Branch advertises its local networks (and any summaries) and nothing else. The hub treats the branch as a leaf. Most common pattern.

2. Branch with locally-redistributed routes. eigrp stub connected summary redistributed. Branch advertises its locals plus any routes redistributed from another protocol (e.g. a local OSPF segment, or static routes for legacy systems). Used when the branch has connectivity to non-EIGRP infrastructure.

3. Read-only branch. eigrp stub receive-only. Branch listens but advertises nothing. Used for sites with no local services or strict read-only requirements.

Anti-Patterns

• Stub routing on transit routers. If two spokes need to reach each other through a hub, both being stubs prevents the path. Stubs do not transit traffic. If a router needs to be transit, it cannot be a stub.
• Forgetting stub on new branches. When you add a new spoke to an existing hub-and-spoke EIGRP network, configure stub routing immediately. Forgetting it leaves the spoke in transit mode and the hub queries it normally.
• Mixed stub and non-stub spokes. Confusing operationally. Standardize - either all spokes are stubs or none.
• Stub routing in a full mesh. Stubs assume hub-and-spoke. In full mesh, every router is a transit router; stubs break the topology.

Stub Routing in DMVPN

DMVPN (Dynamic Multipoint VPN) is a common hub-and-spoke implementation that combines mGRE tunnels with NHRP and a routing protocol underneath. EIGRP stub routing is the standard companion:

! On a DMVPN spoke
interface Tunnel0
 ip address 10.0.0.10 255.255.255.0
 ip nhrp network-id 100
 ip nhrp nhs 10.0.0.1
 tunnel mode gre multipoint
 tunnel source GigabitEthernet0/0/0
 tunnel destination 10.0.0.1

router eigrp 100
 network 10.0.0.0 0.0.0.255
 network 192.168.10.0 0.0.0.255
 eigrp stub connected summary
 no auto-summary

The spoke advertises its tunnel interface and local LAN; the hub treats it as a stub; query suppression applies. Standard pattern.

For spoke-to-spoke direct tunnels (NHRP redirect), the spokes are still stubs from EIGRP's perspective - the direct tunnel does not change the IGP topology, just the data plane.

Alternatives to Stub Routing

Other ways to limit query propagation:

Stub routing is the canonical solution because it integrates with DUAL's query logic. Other mechanisms can reduce route counts but do not stop the hub from querying.

Summary

EIGRP stub routing is the difference between a hub-and-spoke network that scales and one that does not. By telling spokes they are dead-ends, you save the hub from cascading queries during DUAL active states, eliminate Stuck-In-Active risk, and converge faster.

For most production hub-and-spoke designs (DMVPN, branch-to-HQ, retail chains, anything with a few large hubs and many smaller branches), eigrp stub connected summary on every spoke is the right configuration. Bookmark this article alongside the EIGRP cluster pillar and the DUAL deep-dive.