Hands-On Lab: Verifying the EIGRP Database

This hands-on lab examines the EIGRP topology table directly, identifying the successor and feasible successor for a destination network, and demonstrates how this underlying data explains what appears in the IP routing table.

EIGRP Topology TableSuccessor and Feasible SuccessorFeasible Distance

~3 min read · Updated Sep 22, 2026

Lab Objective

Examine the EIGRP topology table for a specific destination network, identify the successor and any feasible successor, and connect this underlying DUAL data directly to what appears in the IP routing table.

Lab Purpose

The IP routing table shows only the single best path EIGRP has chosen, but the topology table reveals the complete picture DUAL, discussed earlier in this series, actually used to make that choice — including any backup path already verified as loop-free and ready for instant use if the primary path fails.

Lab Topology

R1 has two paths to reach network 192.168.50.0/24:

Path via R2: cost 3072
Path via R3: cost 3840

Both R2 and R3 are directly connected
neighbors of R1, offering redundant paths
to the same destination

Task 1: Verify the Routing Table Shows Only One Path

Confirm the IP routing table lists only the single best (successor) path to 192.168.50.0/24.

Task 2: Examine the Full Topology Table Entry

Display the complete topology table entry for 192.168.50.0/24, showing every known path, not just the installed one.

Task 3: Identify the Successor and Feasible Successor

Determine which path is the successor (installed in the routing table) and which qualifies as a feasible successor (backup, loop-free).

Task 4: Verify the Feasibility Condition

Confirm the feasible successor's reported distance is genuinely lower than the successor's feasible distance, the mathematical condition that makes it safe to use as an instant backup.

Solution and Verification

R1# show ip route 192.168.50.0

Routing entry for 192.168.50.0/24
  Known via "eigrp 100", distance 90, metric 3072
  Routing Descriptor Blocks:
  * 10.1.1.2 (via R2), from 10.1.1.2, ...
-- Only the single best path (via R2) appears
-- here, with no indication a backup even exists

R1# show ip eigrp topology 192.168.50.0/24

EIGRP-IPv4 Topology Entry for AS(100)/ID(1.1.1.1)
for 192.168.50.0/24
  State is Passive, Query origin flag is 1,
  1 Successor(s), FD is 3072
  Descriptor Blocks:
  10.1.1.2 (Serial0/0/0), from 10.1.1.2,
    Composite metric is (3072/2816), route is Internal
  10.1.2.2 (Serial0/0/1), from 10.1.2.2,
    Composite metric is (3840/2816), route is Internal
-- Both paths are visible here, unlike the
-- routing table view

-- Reading the composite metric format (FD/RD):

Via R2: (3072/2816) -- FD is 3072, this router's
        own metric to reach the destination
Via R3: (3840/2816) -- higher FD, not the
        installed path

-- The successor is the path via R2, since
-- its FD (3072) matches the topology entry's
-- overall FD -- this is the path in the
-- routing table

-- For R3's path to qualify as a feasible
-- successor: R3's REPORTED distance (2816,
-- the second number) must be less than R2's
-- FD (3072) -- checking: 2816 < 3072 ✓
-- This confirms R3's path IS a feasible
-- successor, ready for instant use

Key Takeaway

The composite metric shown as (FD/RD) in the topology table directly encodes the feasibility condition discussed earlier in this series: whenever a neighbor's reported distance (the second number) is less than the successor's feasible distance, that neighbor is mathematically guaranteed loop-free and instantly promotable if the successor fails — reading this single line of output is how an engineer confirms whether true near-instant EIGRP failover is actually available for a given destination, or whether a failure would instead trigger the slower query process.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configure GLBP Redundancy

This hands-on lab configures GLBP between two routers to achieve load balancing across both routers simultaneously, verifying that different hosts receive different virtual MAC addresses and therefore route through different physical gateways.

Continue

Hands-On Lab: Implementing HSRP

This hands-on lab configures HSRP between two routers sharing a virtual gateway address, sets priority and preempt to control which router is active, and verifies automatic failover when the active router fails.

Continue

Hands-On Lab: Summarizing Routes with EIGRP

This hands-on lab manually configures interface-level route summarization in EIGRP, advertising a single aggregated route instead of several specific subnets, and verifies the automatically created Null0 discard route that prevents summarization-related loops.

Continue

Hands-On Lab: Passive Interfaces for EIGRP Updates

This hands-on lab configures a passive interface in EIGRP to stop routing updates from being sent out a LAN-facing interface while the network remains advertised, mirroring the same security and efficiency rationale covered earlier for OSPF passive interfaces.

Continue

Hands-On Lab: EIGRP Automatic Summarization

This hands-on lab enables EIGRP's legacy automatic summarization feature on a router with discontiguous subnets, observing the routing problem it creates, then disables it to restore correct connectivity.

Continue

Hands-On Lab: Configuring EIGRP Routing Using Wildcard Masks

This hands-on lab configures EIGRP using precise wildcard masks in the network command to advertise only specific subnets rather than entire classful networks, giving finer control over exactly which interfaces participate in EIGRP.

Continue