Hands-On Lab: Configuring Redistribution Between OSPF and EIGRP

This hands-on lab configures two-way mutual redistribution between OSPF and EIGRP domains on a boundary router, verifying routes propagate correctly in both directions and demonstrating the seed metric requirement each protocol imposes on redistributed routes.

Mutual RedistributionSeed Metric ConfigurationRedistributed Route Administrative Distance

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

Lab Objective

Configure a boundary router running both OSPF and EIGRP to redistribute routes from each protocol into the other, verify routes appear correctly on both sides with the expected administrative distance, and confirm the seed metric each protocol requires for redistributed routes is properly applied.

Lab Purpose

Every routing protocol lab throughout this series operated within a single protocol domain. Real networks frequently run multiple protocols simultaneously — during a migration, after a merger, or due to vendor requirements — and redistribution is the mechanism that shares routes between these otherwise-isolated routing domains.

Lab Topology

OSPF Domain (Area 0)          EIGRP Domain (AS 100)
R1 ---- R2 (boundary) ---- R3

R1's LAN: 192.168.30.0/24 (OSPF)
R3's LAN: 192.168.40.0/24 (EIGRP)

R2 runs both OSPF (toward R1) and EIGRP
(toward R3)

Task 1: Verify Baseline Isolation Between Domains

Confirm R1 cannot see R3's LAN and vice versa before any redistribution is configured.

Task 2: Redistribute EIGRP Routes Into OSPF

On R2, redistribute EIGRP routes into OSPF, specifying an appropriate seed metric.

Task 3: Redistribute OSPF Routes Into EIGRP

On R2, redistribute OSPF routes into EIGRP, specifying EIGRP's required seed metric components.

Task 4: Verify R1 Learns R3's LAN via OSPF

Confirm R1 now sees R3's LAN as an OSPF external route.

Task 5: Verify R3 Learns R1's LAN via EIGRP

Confirm R3 now sees R1's LAN as an EIGRP external route.

Solution and Verification

R1# show ip route | include 192.168.40
-- (no output -- R3's LAN not yet visible)

R3# show ip route | include 192.168.30
-- (no output -- R1's LAN not yet visible)

R2(config)# router ospf 1
R2(config-router)# redistribute eigrp 100 metric-type 1 subnets

-- "subnets" is required for OSPF
-- redistribution to include any routes
-- more specific than a classful boundary
-- -- omitting it is a common mistake that
-- silently drops subnetted routes from
-- redistribution entirely

R2(config)# router eigrp 100
R2(config-router)# redistribute ospf 1 metric 10000 100 255 1 1500

-- EIGRP requires an explicit seed metric
-- with five components: bandwidth (kbps),
-- delay (10s of microseconds), reliability,
-- load, and MTU -- unlike OSPF's simpler
-- single metric value

R1# show ip route ospf

O E1  192.168.40.0/24 [110/20] via 10.1.1.2
-- R1 now sees R3's LAN as an OSPF External
-- Type 1 route, discussed earlier in this
-- series regarding OSPF external route types

R3# show ip route eigrp

D EX  192.168.30.0/24 [170/2681856] via 10.2.2.1
-- R3 sees R1's LAN as an EIGRP external
-- route (D EX), with administrative
-- distance 170 -- distinct from the 90
-- used for internally learned EIGRP
-- routes, reflecting the lower trust
-- typically given to redistributed routes

R1# ping 192.168.40.1

!!!!!
Success rate is 100 percent (5/5)

R3# ping 192.168.30.1

!!!!!
Success rate is 100 percent (5/5)
-- Full bidirectional connectivity
-- confirmed across both previously
-- isolated routing domains

Key Takeaway

Each protocol imposes its own seed metric requirement on redistributed routes since a route's original metric (an EIGRP composite value or an OSPF cost) has no meaningful translation into the receiving protocol's metric system — OSPF requires only a single metric value plus the subnets keyword, while EIGRP demands all five composite metric components explicitly, and forgetting either requirement (subnets for OSPF, the full five-part metric for EIGRP) is one of the most common redistribution configuration mistakes.

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

مقالات مرتبط

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.

ادامه