Lab Objective
Add a second boundary router to the previous lab's topology, observe a routing loop or suboptimal path forming when both boundary routers redistribute mutually without coordination, then apply route tagging and distribute lists to prevent a route from being redistributed back into the protocol it originated from.
Lab Purpose
The single-boundary-router redistribution in the previous lab has no opportunity for a loop, since there is only one path between domains. With two mutual redistribution points, a route learned via redistribution can be redistributed back into its original protocol at the second boundary, creating exactly the kind of routing loop or suboptimal path that route tagging is specifically designed to prevent.
Lab Topology
OSPF Domain -- R2 (boundary 1) -- EIGRP Domain
| |
+-------- R4 (boundary 2) ---------+
Both R2 and R4 perform mutual
redistribution between OSPF and EIGRP,
creating two paths between the domainsTask 1: Configure R4 as a Second Mutual Redistribution Point
Configure R4 with the same mutual redistribution as R2 from the previous lab, without any loop prevention yet.
Task 2: Observe the Resulting Routing Behavior
Examine the routing tables for signs of suboptimal path selection or route flapping caused by the redistribution loop.
Task 3: Apply Route Tags During Redistribution
Configure both R2 and R4 to tag routes as they are redistributed out of OSPF into EIGRP, and out of EIGRP into OSPF.
Task 4: Configure a Distribute List Matching the Tag
On each boundary router, configure a route-map that denies redistribution of routes carrying the tag indicating they originated from the other protocol.
Task 5: Verify the Loop Is Resolved
Confirm routes are no longer redistributed back into their originating protocol, and that path selection stabilizes.
Solution and Verification
R4(config)# router ospf 1
R4(config-router)# redistribute eigrp 100 metric-type 1 subnets
R4(config)# router eigrp 100
R4(config-router)# redistribute ospf 1 metric 10000 100 255 1 1500
-- Identical mutual redistribution to R2,
-- creating a second path between the
-- domains -- no coordination between the
-- two boundary routers yetR1# show ip route 192.168.40.0
O E1 192.168.40.0/24 [110/20] via 10.1.1.2
[110/20] via 10.1.1.4
-- Two paths now exist to reach R3's LAN --
-- one via each boundary router -- and in
-- more complex topologies this exact
-- pattern can cause routes to bounce
-- between OSPF and EIGRP repeatedly as
-- each boundary router re-advertises what
-- it just learned from the otherR2(config)# route-map TAG-FROM-OSPF permit 10
R2(config-route-map)# set tag 100
R2(config)# router ospf 1
R2(config-router)# redistribute eigrp 100 metric-type 1 subnets route-map TAG-FROM-OSPF
-- Wait -- tagging happens on redistribution
-- INTO a protocol, marking where the route
-- came from, so it can be recognized and
-- excluded when redistributing back OUT of
-- that protocol elsewhere in the topologyR2(config)# route-map TAG-FROM-EIGRP permit 10
R2(config-route-map)# set tag 200
R2(config)# router eigrp 100
R2(config-router)# redistribute ospf 1 metric 10000 100 255 1 1500 route-map TAG-FROM-EIGRP
R4 configured identically with the same
tag values (100 for OSPF-originated,
200 for EIGRP-originated)R2(config)# route-map BLOCK-EIGRP-TAG deny 10
R2(config-route-map)# match tag 200
R2(config)# route-map BLOCK-EIGRP-TAG permit 20
R2(config)# router ospf 1
R2(config-router)# redistribute eigrp 100 metric-type 1 subnets route-map BLOCK-EIGRP-TAG
-- This denies redistributing INTO OSPF any
-- route already tagged 200 (meaning it
-- originated in OSPF, went to EIGRP via
-- the other boundary router, and would
-- otherwise loop back into OSPF here)R2(config)# route-map BLOCK-OSPF-TAG deny 10
R2(config-route-map)# match tag 100
R2(config-route-map)# permit 20
R2(config)# router eigrp 100
R2(config-router)# redistribute ospf 1 metric 10000 100 255 1 1500 route-map BLOCK-OSPF-TAG
-- R4 configured with equivalent
-- tag-matching deny statementsR1# show ip route 192.168.40.0
O E1 192.168.40.0/24 [110/20] via 10.1.1.2
-- Only one path remains, since the tagged
-- route is now correctly excluded from
-- being reintroduced via the second
-- boundary routerKey Takeaway
Route tagging works by marking a route's origin at the moment it crosses into a new protocol, then checking that tag at every subsequent redistribution point to prevent the route from being fed back into the protocol it started in — this is the standard, purpose-built mechanism for multi-boundary-router redistribution scenarios, far more reliable than relying on administrative distance or metric differences alone to prevent the kind of routing loop that becomes possible the moment a second redistribution point is introduced.