Mutual Redistribution and a Route Feedback Loop
A manufacturer runs OSPF area 0 in its data center and EIGRP 100 across 14 plants. Two routers, R1 and R2, mutually redistribute between the protocols. After a new plant was added, the 10.50.0.0/16 prefix appears in OSPF with cost 20 at R1 and cost 210 at R2, and data-center users intermittently lose access to the plant's MES application for 20–40 seconds. R1 CPU reaches 85 percent every 90 seconds; logs show EIGRP neighbor resets and repeated OSPF SPF runs. R1 redistributes EIGRP into OSPF with a seed metric of 20. R2 redistributes OSPF into EIGRP with a route-map that sets bandwidth 1000000 kbps, delay 10, reliability 255, load 1, and MTU 1500. Both routers originate a default route into their respective domains, and each has a static default toward a different ISP. The plant has a 50 Mbps primary circuit and a 20 Mbps LTE backup.
1. Explain the mechanism that makes 10.50.0.0/16 flap and drives CPU and neighbor resets on both routers.
Read the worked answer
R2 has no direct EIGRP adjacency to the new plant; its only view of 10.50.0.0/16 is the OSPF external learned from R1. R2 redistributes that OSPF route back into EIGRP and the route-map gives it a 1 Gbps bandwidth and delay of 10, making the feedback path look better than the native 50 Mbps EIGRP path when it reaches R1. R1 then prefers the EIGRP route advertised by R2, even though R2's next hop for that prefix is R1 over OSPF. The two routers point at each other.
Once the path changes, R1's EIGRP topology changes, so it reoriginates or withdraws the OSPF external. R2's redistributed EIGRP route then changes again. The 20 versus 210 OSPF cost makes the two routers disagree about the best path and produces asymmetric forwarding and black-holing. The 20–40 second outage matches EIGRP active and stuck-in-active behavior, while repeated SPF runs and EIGRP resets explain the CPU spikes.
The LTE backup is not the root cause, but it makes the failure worse: when the primary path flaps, EIGRP may prefer the backup and then oscillate again when the primary returns. The fix must stop the feedback, not just tune timers.
2. Design the redistribution controls you would apply on R1 and R2. Be specific about tags, prefix filters, and default route handling.
Read the worked answer
Use a tag-and-filter design at both trust boundaries:
- On R1, when redistributing EIGRP into OSPF, set tag 100 on 10.50.0.0/16 only and use a seed metric of 20. Deny any route already tagged 200.
- On R2, when redistributing OSPF into EIGRP, deny routes tagged 100. Tag all remaining OSPF-to-EIGRP routes with 200, and use a normal seed metric that does not beat the native 50 Mbps path.
- Apply a prefix list so only the plant summary 10.50.0.0/16 is redistributed in either direction; do not redistribute the entire OSPF or EIGRP table.
- Use distribute lists or route-map filters on the EIGRP and OSPF interfaces toward the other ASBR to prevent the tagged route from re-entering.
- Make R1 the primary redistribution point and give R2 a deliberately worse seed metric, so the backup path is used only when R1 fails.
For default routes, originate a default from R1 only into both domains, with a route tag and a metric that follows the intended ISP. R2 should originate a default only as a standby with a much higher metric, and it should filter any default learned from the other domain. Otherwise each domain can send traffic to the other domain's ISP through the redistributed default.
After applying the policy, clear the relevant adjacencies in a maintenance window and verify that 10.50.0.0/16 has exactly one EIGRP path and one OSPF external, with no tag 100 route appearing in EIGRP.
3. How would you verify the corrected design and what thresholds would tell you the network is stable again?
Read the worked answer
Verify in layers rather than relying on a single ping:
- Routing table: confirm 10.50.0.0/16 is learned from the plant over EIGRP and appears as a single OSPF external with tag 100 at R2. R2's EIGRP topology should not contain a path whose next hop is R1 for that prefix.
- Path: traceroute from the data center to the plant should show R1 to plant, not R1 to R2 back to R1. Repeat from multiple data-center subnets and from the LTE backup state.
- Control plane: OSPF SPF runs should stay below one per minute at steady state, and EIGRP neighbors should remain up for at least 24 hours. R1 CPU should fall below 40 percent at peak.
- Data plane: MES transaction success should be 100 percent during a one-hour test, with no 20–40 second gaps. Compare latency and loss on the primary and backup paths.
Thresholds for declaring stability: no EIGRP resets for 72 hours, no more than two SPF runs per hour, zero packet loss on a 1-second synthetic probe to the MES server, and no route changes for 10.50.0.0/16 during a 24-hour observation. If any threshold is missed, remove R2 from redistribution and run on R1 alone before reintroducing the backup path.