Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

EIGRP Stub Router ConfigurationQuery Scope LimitationStub Route Restrictions

~4 min read · Updated Sep 26, 2026

Lab Objective

Configure a branch router as an EIGRP stub advertising only connected networks, verify the hub router correctly identifies it as a stub and excludes it from EIGRP queries triggered elsewhere in the topology, and confirm the stub router itself never attempts to act as a transit path for other routers' traffic.

Lab Purpose

In a hub-and-spoke EIGRP topology with many branch routers, a single topology change at the hub can trigger EIGRP queries fanning out to every spoke, each of which must respond before the hub's DUAL computation can complete — a slow process at scale. EIGRP stub routing tells the hub explicitly not to query specific branch routers, since they have no alternate paths to offer, dramatically reducing query scope.

Lab Topology

Hub ---- R1 (branch, to be configured as stub)
Hub ---- R2 (another branch, not a stub,
             will trigger a query)

R1's LAN: 192.168.50.0/24
Hub also connects to a third router R3
whose link failure will trigger the test
query in this lab

Task 1: Configure R1 as an EIGRP Stub

Configure R1 as an EIGRP stub advertising only connected routes.

Task 2: Verify the Hub Recognizes R1 as a Stub

Confirm the hub's neighbor table shows R1 flagged as a stub router.

Task 3: Verify R1's Advertised Routes Are Restricted

Confirm R1 only advertises its own connected LAN, not any routes it may have learned from elsewhere.

Task 4: Trigger a Topology Change Elsewhere in the Network

Simulate a link failure on R3's connection to the hub, an event that would normally trigger EIGRP queries.

Task 5: Verify R1 Is Excluded from the Query Process

Confirm debug output on the hub shows R1 was never queried as part of recomputing the affected route.

Solution and Verification

R1(config)# router eigrp 100
R1(config-router)# eigrp stub connected

-- "connected" restricts R1 to advertising
-- only its own directly connected
-- networks -- other stub variants exist
-- (static, summary, receive-only) for
-- different advertisement restrictions,
-- but connected is the most common for a
-- simple branch office scenario

Hub# show ip eigrp neighbors detail

EIGRP-IPv4 Neighbors for AS(100)
H   Address         Interface   Hold Uptime
0   10.1.1.2        Se0/0/0      12  00:02:15
   Version 20.0/3.0, Retrans: 0, Retries: 0
   Stub Peer Advertising ( CONNECTED )Routes
-- The hub explicitly recognizes R1 as
-- advertising only connected routes,
-- information learned during the initial
-- neighbor handshake itself

Hub# show ip route eigrp | include 192.168.50

D    192.168.50.0/24 [90/2681856] via 10.1.1.2, Serial0/0/0
-- R1's connected LAN is still advertised
-- and learned normally -- stub restricts
-- WHICH routes R1 forwards onward from
-- other sources, not its own directly
-- connected networks

Hub# debug eigrp fsm

R3(config)# interface serial0/0/1
R3(config-if)# shutdown

-- (simulating R3's link failure, which
--  would normally cause the hub to query
--  neighbors for an alternate path to
--  whatever R3 was advertising)

Hub# show ip eigrp topology active

-- (checking whether any routes entered
--  active/query state)

*Jun 25 14:22:01.204: DUAL: Find FS for
dest 192.168.60.0/24. FD is 2681856, RD
is 2681856
*Jun 25 14:22:01.208: DUAL: Peer 10.2.2.2:
metric 4294967295 not FS. Old FD: 2681856
*Jun 25 14:22:01.210: DUAL: New topology
entry for 192.168.60.0/24
*Jun 25 14:22:01.212: DUAL: RT installed
192.168.60.0/24 via 10.3.3.2

-- Notice the query process, and its
-- associated debug messages, involve only
-- R2's address (10.2.2.2) and R3's --
-- 10.1.1.2 (R1, the stub) never appears
-- anywhere in this exchange, confirming
-- it was correctly excluded from the
-- query fan-out entirely

Key Takeaway

Configuring a branch router as an EIGRP stub is a query-scope optimization built on an honest declaration: the branch is telling the hub "I have no alternate paths to offer, so never bother asking me during a query" — this is precisely why stub routers should only ever be configured on legitimate dead-end branches with no transit role, since applying it to a router that genuinely does have alternate paths would cause the hub to silently miss viable routing information during convergence.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue

Hands-On Lab: Configuring StackWise Virtual

This hands-on lab configures two physical switches into a single logical StackWise Virtual switch using a dedicated Stackwise Virtual Link, verifying both members present as one control plane and that a member failure triggers predictable failover behavior.

Continue