Two-point redistribution is where redistribution stops being a config exercise and starts being a design problem. The moment two border routers both translate between routing domains, every prefix has a feedback path: out through one door, around the block, and back in through the other, wearing a new metric that may beat the original. This post builds that failure live on Cisco IOS XE, captures an actual forwarding loop, and then fixes it the way production networks do: with route tags. It assumes you are comfortable with the basics from our complete redistribution guide, part of the IP Routing cluster.
The Setup: Two Border Routers, Both Redistributing
Same lab as the main guide: R1-R2 in OSPF area 0, R3-R4 in EIGRP named AS 100, with both protocols live on the R2-R3 link so that R2 and R3 are each full border routers. Both redistribute mutually with the same seed metric (redistribute eigrp 100 subnets into OSPF, redistribute ospf 1 metric 1000000 1 255 1 1500 into EIGRP). The victim prefix is 172.16.4.0/24, which R4 injects into EIGRP via redistribute connected, making it an EIGRP external (AD 170).
Failure Mechanism 1: Administrative Distance Betrays You
Before anything visibly breaks, the routing table is already lying. R2 hears 172.16.4.0/24 twice: natively via EIGRP as an external (AD 170), and via OSPF as an E2 (AD 110) because R3 redistributed it. AD is compared before any metric, so the OSPF copy wins:
R2# show ip route 172.16.4.0
Routing entry for 172.16.4.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
* 10.0.23.3, from 3.3.3.3, 00:02:07 ago, via Ethernet0/1An EIGRP-domain prefix, on an EIGRP border router, installed as an OSPF route. This is the quiet stage of the disease. EIGRP's designers anticipated exactly this scenario, which is why external EIGRP routes carry AD 170 instead of 90 (a route that left the domain and came back should lose to almost anything). But OSPF has no such split: internals and externals are both 110, so OSPF happily trusts routes that EIGRP originated.
Failure Mechanism 2: The Echo in the Topology Table
Because R2 installed the OSPF copy, R2's own OSPF-to-EIGRP redistribution now exports 172.16.4.0/24 back into EIGRP. R3's topology table shows the echo arriving, with the lineage data making the problem legible: one path from the legitimate originator (R4, external protocol Connected), one from R2 claiming it via OSPF:
R3# show eigrp address-family ipv4 topology 172.16.4.0/24
10.0.34.4 (Ethernet0/1) ... Composite metric is (131153920/163840), route is External
External protocol is Connected, external metric is 0
Originating router is 4.4.4.4
10.0.23.2 (Ethernet0/0) ... Composite metric is (131727360/1310720), route is External
External protocol is OSPF, external metric is 20
Originating router is 2.2.2.2Right now the legitimate path still wins, by less than half a percent of composite metric (131153920 versus 131727360). The loop is loaded; it just needs a trigger.
The Trigger: A Routine Delay Change
Someone tunes EIGRP delay for traffic engineering on the R3-R4 link (delay 1000 under the interface, a completely ordinary change). The legitimate path's metric inflates past the echo, and R3 flips its next hop to R2:
R3# show ip route 172.16.4.0
Known via "eigrp 100", distance 170, metric 1029120 ... type external
* 10.0.23.2, from 10.0.23.2, 00:00:04 ago, via Ethernet0/0R3 now forwards toward R2. But R2 still holds the OSPF E2 route pointing at R3. Each border router believes the other one knows the way:
R1# traceroute 172.16.4.4 numeric timeout 1 probe 1 ttl 1 10
1 10.0.12.2 3 msec
2 10.0.23.3 3 msec
3 10.0.23.2 2 msec
4 10.0.23.3 4 msec
5 10.0.23.2 3 msec
6 10.0.23.3 4 msec
7 10.0.23.2 6 msec
8 10.0.23.3 6 msec
R1# ping 172.16.4.4
..!!!
Success rate is 60 percent (3/5)A textbook micro-loop between 10.0.23.2 and 10.0.23.3, with the ping flapping as the protocols churn. On a real WAN this presents as intermittent reachability that mysteriously follows topology changes, one of the nastiest symptoms to chase.
The Fix: Route Tags at Every Boundary
The clean, scalable fix is to mark every route as it crosses the boundary and refuse to let it cross back. Two route-maps, applied identically on both border routers:
route-map EIGRP-TO-OSPF deny 10
match tag 200
route-map EIGRP-TO-OSPF permit 20
set tag 100
!
route-map OSPF-TO-EIGRP deny 10
match tag 100
route-map OSPF-TO-EIGRP permit 20
set tag 200
!
router ospf 1
redistribute eigrp 100 subnets route-map EIGRP-TO-OSPF
!
router eigrp PINGLABZ
address-family ipv4 unicast autonomous-system 100
topology base
redistribute ospf 1 metric 1000000 1 255 1 1500 route-map OSPF-TO-EIGRPRead it as a passport system. Routes leaving EIGRP for OSPF get stamped tag 100. Routes leaving OSPF for EIGRP get stamped tag 200. And each direction's deny clause rejects routes carrying the opposite stamp (if a route already crossed into OSPF once, tag 100 proves it, and it may not cross back). The tag travels inside the OSPF type 5 LSA and inside the EIGRP external data, so the check works on any border router, not just the one that applied the stamp. That is what makes tags scale to three, four, or N redistribution points where per-prefix filters collapse under their own maintenance burden.
Verifying the Fix
Seconds after applying the route-maps, R3 falls back to the legitimate path via R4, and the traceroute goes clean:
R3# show ip route 172.16.4.0
Known via "eigrp 100", distance 170, metric 5632640 ...
* 10.0.34.4, from 10.0.34.4, 00:00:48 ago, via Ethernet0/1
R1# traceroute 172.16.4.4 numeric timeout 1 probe 1 ttl 1 8
1 10.0.12.2 3 msec
2 10.0.23.3 3 msec
3 10.0.34.4 4 msecThe tag is visible end to end. R1's RIB shows it on the installed route, and the OSPF database shows it inside the LSA itself:
R1# show ip route 172.16.4.0
Known via "ospf 1", distance 110, metric 20
Tag 100, type extern 2, forward metric 20
Route tag 100
R1# show ip ospf database external 172.16.4.0 | include Tag|Advertising
Advertising Router: 3.3.3.3
External Route Tag: 100The Other Tools in the Kit
Route tags
Best default. Protocol-carried, self-documenting, scales to any number of boundaries. Costs two route-maps per border router.
AD manipulation
Raise the AD of external routes (e.g. distance ospf external 175) so echoes lose to originals. Simple, but silent and easy to forget; document it loudly.
Prefix filtering
Distribute-lists or prefix-list route-maps naming exactly what may cross. Precise but brittle: every new subnet means a filter change, and misses cause outages.
EIGRP AD 170 (built in)
External EIGRP routes are pre-demoted, which protects EIGRP from its own echoes. OSPF has no equivalent split, which is why the OSPF side loops first.
In practice, tags plus the default AD behavior cover nearly every design. Reach for prefix filtering when policy demands that specific prefixes never leak (compliance boundaries, extranets), not as your primary loop defense. And note that OSPF's E2 metric hides path degradation: since the metric stays at 20 everywhere, OSPF gives you no metric signal that a path got worse, which is exactly why the AD comparison at the border decides everything.
Why Not Just Fix the AD?
Since the failure began with OSPF's E2 route (AD 110) beating the EIGRP external (AD 170) on the border router, an obvious counter is to demote OSPF externals below 170:
router ospf 1
distance ospf external 175Applied on both border routers, this makes each border prefer the native EIGRP external over the echo, and in this specific two-domain shape it does prevent the loop. It is a legitimate tool with two sharp edges. First, it is invisible at a glance: nothing in the routing table advertises that this router's AD table is nonstandard, and the next engineer will reason from defaults (document it in the config with a description and in the runbook, or expect a confused successor). Second, it is positional rather than structural: AD manipulation protects the router you configured it on, while tags protect the boundary itself, wherever and however many crossings exist. The mature pattern is tags as the structural guarantee, AD adjustment as optional belt-and-braces on top.
Suboptimal Routing: The Loop's Quieter Sibling
Not every two-point pathology loops. The same AD mechanics routinely produce paths that merely limp: a border router sends traffic for a next-door EIGRP prefix on a tour through the OSPF domain because the E2 copy (AD 110) beat the native external (AD 170). Our first capture in this post, before any delay change, was exactly that state: R2 holding an OSPF route toward a prefix its own EIGRP interface could reach directly. Nothing alarms, pings succeed, and only a latency graph or a traceroute audit reveals the detour. Tags fix this variant identically, because the echo never gets to compete in the first place. If users report "it works but it is slow" across a redistribution boundary, run the same topology-table forensics from the troubleshooting runbook before blaming the WAN.
Tagging Nuances Per Protocol
A few implementation details keep the design honest. EIGRP named mode places the redistribute statement under topology base inside the address family, and the tag travels in the external data block (visible in show eigrp address-family ipv4 topology <prefix>, "Administrator tag"). OSPF carries the tag in the type 5 LSA itself, so it survives flooding across the whole domain and is checkable anywhere with show ip ospf database external. Tags are 32-bit values; pick a scheme with room (we use 100 for EIGRP-origin and 200 for OSPF-origin, and larger shops encode site or domain IDs). And if a third domain joins later, the same two route-maps per boundary extend naturally: each domain gets its own tag, and each import direction denies every foreign tag that has already crossed once.
FAQ
Do route tags cost anything?
Effectively nothing. The tag rides in fields both protocols already carry, adds no timers or adjacencies, and the route-map evaluation happens only at redistribution time, per prefix, not per packet.
Why did the loop only appear after the delay change?
The echoed route was always present in the topology table, just losing on composite metric by under one percent. Feedback designs sit in that metastable state indefinitely; any interface tune, link flap, or new parallel path can promote the echo. That is why the fix is structural (tags) rather than metric tuning, which merely re-hides the bomb.
Can I use one tag instead of two?
Yes, a single "has crossed a boundary" tag denied in both directions works for two domains. Two tags cost one extra route-map line and tell you which direction a route originally crossed, which pays for itself the first time you audit an LSDB at 2 a.m.
Key Takeaways
Two-point redistribution always creates a feedback path; whether it loops is just a question of metrics and timing, and any routine change can be the trigger. AD decides before metrics do, so OSPF E2 routes (AD 110) beat EIGRP externals (AD 170) on the border router even for prefixes EIGRP originated. Tag on the way out, deny your own tag on the way in, identically on every border router, and the loop becomes structurally impossible. Verify with show ip route (tag on the installed route), show ip ospf database external (tag in the LSA), and a traceroute that no longer ping-pongs. For the fundamentals behind these captures, see the complete redistribution guide, the redistribution troubleshooting walkthrough, and the broader IP Routing pillar.
