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

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.

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

مقالات مرتبط

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.

ادامه