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 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه