Troubleshooting Route Redistribution: Missing, Looping, and Suboptimal Routes

Redistribution failures come in three flavors: routes that never arrive, routes that arrive too well (echo back, win the border router's affection, and loop), and routes that arrive perfectly but take the long way round. All three were built deliberately in the lab, so every signature below is a real capture from Cisco IOS XE 17.18.2 on CML iol-xe nodes. The third is the one nobody opens a ticket for: the prefix is there, pings succeed, and traffic quietly takes two extra hops for months. Keep the complete redistribution guide open for the mechanics; this is the diagnostic runbook. Part of the IP routing fundamentals cluster.

The Diagnostic Frame

Redistribution moves routes from the routing table of one protocol into the database of another. So every missing-route investigation walks the same four stations: is the route in the source protocol's table on the border router, does the redistribute statement select it, does it appear in the destination protocol's database, and does the far router install it? One of those four links is broken, and the commands below bracket the search fast. A fifth station applies once the route is present: is the copy the router installed the one you wanted? Presence and correctness are separate tests.

Case 1: Missing Routes, EIGRP Edition (No Seed Metric)

The single most common redistribution failure in the wild. Symptom first, from the far EIGRP router:

R4# show ip route 1.1.1.1
% Network not in table

On the border router R3 the config looks plausible, and show ip protocols even confirms redistribution is on... read it to the end though:

R3# show ip protocols | section eigrp
  Redistributing: ospf 1
    ...
      Total Prefix Count: 5
      Total Redist Count: 0

"Redistributing: ospf 1" and "Total Redist Count: 0" in the same output is the whole diagnosis. EIGRP's default seed metric is infinity: without an explicit metric every imported route is advertised as unreachable, which is to say not advertised at all. No error, no syslog. The topology table confirms it never entered EIGRP:

R3# show eigrp address-family ipv4 topology 1.1.1.1/32
EIGRP-IPv4 VR(PINGLABZ) Topology Entry for AS(100)/ID(3.3.3.3)
%Entry 1.1.1.1/32 not in topology table

The fix is the five-part seed metric, in named mode under the topology base:

router eigrp PINGLABZ
 address-family ipv4 unicast autonomous-system 100
  topology base
   redistribute ospf 1 metric 1000000 1 255 1 1500

Seconds later, R4 holds the whole OSPF domain as externals (note the AD: 170 on every one, harmless here and the subject of Case 5):

R4# show ip route | begin Gateway
D EX     1.1.1.1 [170/1029120] via 10.0.34.3, 00:00:30, Ethernet0/0
D EX     2.2.2.2 [170/1029120] via 10.0.34.3, 00:00:30, Ethernet0/0
D EX     10.0.12.0/24 [170/1029120] via 10.0.34.3, 00:00:30, Ethernet0/0

Case 2: Missing Routes, OSPF Edition (The subnets Story)

The classic advice says: if you redistribute into OSPF and only classful networks appear, you forgot the subnets keyword. Worth knowing, with a modern footnote. On current IOS XE, subnets are included by default, and the router says so:

R3# show ip protocols | include subnets
    eigrp, includes subnets in redistribution

So on a modern box this failure will not reproduce (we tried, in this very lab). You will still meet it on legacy IOS, where redistribute eigrp 100 without subnets silently drops every subnetted prefix, which in a world of /24s and /32s means everything. Typing subnets costs nothing and self-documents; checking show ip protocols tells you which behavior your platform has.

Two more members of the family sit at the same station: a prefix the exporter itself learned from the destination protocol (Case 4), and a route-map whose deny matches more than intended, which show route-map settles in seconds because it counts matches per sequence.

Case 3: Looping Routes (Two Borders, No Tags)

The opposite failure: everything redistributes wonderfully, in both directions, at two border routers, and one day a routine metric change produces this:

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

R1# ping 172.16.4.4
..!!!
Success rate is 60 percent (3/5)

A traceroute alternating between two addresses is a forwarding loop between two routers that each believe the other has the path (the general signature, and how to break one, is in reading a repeating traceroute). Intermittent ping success is the churn signature: the protocols flap between states as the echoed route wins and loses. Read the same prefix on both border routers:

R2# show ip route 172.16.4.0 | include Known|via 10
  Known via "ospf 1", distance 110 ... via Ethernet0/1        (points at R3)

R3# show ip route 172.16.4.0
  Known via "eigrp 100", distance 170 ...
  * 10.0.23.2, from 10.0.23.2 ... via Ethernet0/0             (points at R2)

Root cause in one sentence: R3 redistributed the EIGRP prefix into OSPF, R2 preferred the OSPF copy (AD 110 beats EIGRP external 170) and re-redistributed it back into EIGRP with a fresh seed metric that eventually beat the original. The forensic tool is the EIGRP topology table, which names the echo's author:

R3# show eigrp address-family ipv4 topology 172.16.4.0/24
  10.0.34.4 ... External protocol is Connected, Originating router is 4.4.4.4
  10.0.23.2 ... External protocol is OSPF, external metric is 20,
                Originating router is 2.2.2.2

A prefix whose external protocol is OSPF, originated by your other border router, sitting in the EIGRP topology table of the domain that created it: that is a route that left home and came back wearing a disguise. The structural cure is mutual tagging at every border, covered with fixed-state captures in the companion piece on tagging on export and denying your own tag on the way back in. After:

R1# show ip route 172.16.4.0
  Known via "ospf 1", distance 110, metric 20
  Tag 100, type extern 2, forward metric 20

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 msec

The Runbook

Case 4: The Route That Refuses to Export (AD Theft)

A subtler missing-routes variant, and the one that most reliably confuses smart engineers. Symptom: a prefix you are certain lives in OSPF will not redistribute into EIGRP, even though the seed metric is right and no filter exists. The catch: on this border router the prefix was ALSO learned via EIGRP, and EIGRP won the RIB (internal AD 90 versus OSPF 110). Redistribution exports only what the routing table attributes to the named source protocol, so redistribute ospf 1 walks straight past it. The one-command diagnosis is the detail view:

R2# show ip route 10.0.34.0
Routing entry for 10.0.34.0/24
  Known via "eigrp 100", distance 90, metric 1536000, type internal

"Known via" naming the other protocol on the router you expected to export from ends the mystery. It is also a design smell: prefixes reachable through both domains at a border are the feedback fuel Case 3 burns, so check your tagging posture while you are in there.

Case 5: Suboptimal Routing, the Better Path That Loses

Nothing is missing and nothing is looping. The prefix is installed, the destination answers, and the traffic points the wrong way. Second lab for this one: R1, R2 and R3 run OSPF in area 0, and R1 also has a direct EIGRP link to R3, which owns 172.16.3.0/24, advertises it into OSPF and redistributes OSPF into EIGRP AS 100. R1 learns the prefix twice, natively over OSPF (two hops via R2) and as an EIGRP external over the direct cable:

R1# show ip route 172.16.3.0 255.255.255.0
Routing entry for 172.16.3.0/24
  Known via "ospf 1", distance 110, metric 21, type intra area
  Last update from 10.0.12.2 on Ethernet0/0, 00:01:00 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 3.3.3.3, 00:01:00 ago, via Ethernet0/0
      Route metric is 21, traffic share count is 1

OSPF, distance 110, next hop 10.0.12.2, which is R2: R1 picked the two-hop path over a direct link to the router that owns the prefix. CEF says this is not just a control-plane curiosity:

R1# show ip cef 172.16.3.0 255.255.255.0
172.16.3.0/24
  nexthop 10.0.12.2 Ethernet0/0

Packets really do take the long way. Before blaming the direct link, ask EIGRP what it knows:

R1# show ip eigrp topology 172.16.3.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.0.13.1) for 172.16.3.0/24
  State is Passive, Query origin flag is 1, 0 Successor(s), FD is Infinity
  Descriptor Blocks:
  10.0.13.2 (Ethernet0/1), from 10.0.13.2, Send flag is 0x0
      Composite metric is (307200/281600), route is External
      ...
      External data:
        AS number of route is 1
        External protocol is OSPF, external metric is 0

That block is the whole lesson. The direct path over Ethernet0/1 exists, EIGRP computed a usable composite metric for it, and it is marked External with OSPF named as the source (proof it arrived through R3's redistribution). It will never be installed. 0 Successor(s) with FD is Infinity is EIGRP saying it has a candidate and the RIB declined it: not because the path is longer (it is shorter) and not because the metric is worse (metrics from different protocols are never compared), but because a redistributed route enters EIGRP as an external, an external carries AD 170, and 170 loses to OSPF's 110 before the path is considered at all. That is the short answer to how a router picks between two protocols offering the same prefix: AD ranks the source of the information, never the quality of the route.

The asymmetry lives inside EIGRP: internal routes at 90 beat OSPF, externals at 170 lose to it, so redistributing a prefix into EIGRP drops it from guaranteed winner to guaranteed loser (why EIGRP trusts its own routes and distrusts imported ones).

The One-Line Fix

R1 is making the bad choice, so R1 is where the change goes. Leave internal alone and drop the external distance below OSPF's 110:

router eigrp 100
 distance eigrp 90 109

R1# show ip route 172.16.3.0 255.255.255.0
Routing entry for 172.16.3.0/24
  Known via "eigrp 100", distance 109, metric 307200, precedence routine (0), type external
  Redistributing via eigrp 100
  Last update from 10.0.13.2 on Ethernet0/1, 00:00:48 ago
  Routing Descriptor Blocks:
  * 10.0.13.2, from 10.0.13.2, 00:00:48 ago, via Ethernet0/1
      Route metric is 307200, traffic share count is 1

Read three fields, not one: distance is 109, so the command took; the next hop is 10.0.13.2 out Ethernet0/1, the direct link; and the age of 00:00:48 says this is a freshly installed route, not a stale screen. Forwarding follows:

R1# show ip cef 172.16.3.0 255.255.255.0
172.16.3.0/24
  nexthop 10.0.13.2 Ethernet0/1

Why the One-Line Fix Is Often the Wrong One

Know how blunt distance eigrp 90 109 is before it goes in a change window. It moves every EIGRP external on the router, not just the prefix you were chasing, and AD is locally significant, so R1 now ranks routes differently from its neighbors, which is how asymmetric routing gets built quietly. At a second border it is worse: an AD change is exactly the trigger that lets an echoed route win, and you are back in Case 3. Use it where there is one crossing point, scope it with an access-list, and read the far end afterwards. Where the design has redundancy, prefer the structural fix: tag on export, or keep the redistributed prefix out of the return path with a distribute-list. AD makes the router prefer the right answer; a filter stops the wrong answer existing.

What This Was Captured On

Both labs are CML with iol-xe nodes on IOS XE 17.18.2. Cases 1 to 4 come from a four-router mutual-redistribution topology with two OSPF/EIGRP borders and EIGRP in named mode. Case 5 uses R1 (Et0/0 10.0.12.1/30 to R2 in OSPF, Et0/1 10.0.13.1/30 direct to R3 in EIGRP AS 100), R2 in OSPF only, and R3 with Lo0 172.16.3.3/24 set to ip ospf network point-to-point so it advertises the full /24, plus redistribute ospf 1 metric 10000 100 255 1 1500. An EEM applet wrote the R1 output to syslog before and after the fix, so both captures are the same commands minutes apart on the same box.

Timing Matters: When the Capture Lies

Two timing traps pad many redistribution tickets. First, convergence lag: after fixing a seed metric EIGRP must run DUAL and propagate, so a show ip route issued too fast shows the old world. Check the route's age (the fixed-state captures show fresh timers like 00:00:30 and 00:00:48, which is itself evidence the fix took). Second, flap-induced ambiguity: during feedback churn like Case 3 consecutive commands can show different next hops, which is the pathology, not your terminal. If the state will not settle, capture the oscillation rather than waiting for a clean screenshot that will never come. And in Case 5's world the RIB can be right while CEF is not, so no capture is finished until show ip cef agrees.

Prevention: The Five-Line Checklist

Every redistribution change, before you type it: name the single owner of each prefix range; set an explicit seed metric even where defaults would work (documentation by configuration); tag at every crossing and deny your own tags back in, from day one, not after the first loop; filter what should never cross with a prefix-list on the same route-map; and capture before/after state on both borders plus one interior router per domain, checking not just that each prefix is present but which interface it now points out of. Ten minutes, and redistribution stops being folklore. The reasoning behind each line is spread across the redistribution guide and the loop-prevention deep dive.

FAQ

My redistribute command took, but show ip protocols shows no metric. Broken?

For EIGRP, yes-in-waiting: no metric line means the infinite default applies and nothing exports (confirm with Total Redist Count: 0). For OSPF the absence is fine; the seed defaults to 20 (1 for BGP) and E2.

Why does the better path show in the topology table but not the routing table?

They answer different questions. The topology table is everything EIGRP knows; the RIB is what won against every other protocol offering that prefix. A valid composite metric next to 0 Successor(s) and FD is Infinity means EIGRP computed a usable path and the RIB refused it, which at a redistribution boundary is nearly always AD 170 losing to 110.

Can I see WHERE a looping prefix entered the domain?

Yes. EIGRP externals name the originating router and source protocol in the topology table; OSPF type 5 LSAs name the advertising ASBR (show ip ospf database external). Between the two you can reconstruct the circle a route traveled, as in Case 3.

Is mutual redistribution ever safe without tags?

With a single border router, yes: there is no second door for the echo. The moment redundancy adds a second crossing, tags stop being optional, whatever the metrics say. The harder variants, three protocols meeting at more than one point, are worked through in redistribution at two or more borders.

Key Takeaways

• Missing routes are almost always a seed metric (EIGRP's default is infinity and fails silently), a filter, or exporting a route the border installed from the wrong protocol. "Total Redist Count: 0" is the tell.
• The subnets keyword matters on legacy IOS and is default on modern IOS XE. show ip protocols tells you which world you are in.
• Loops show up as alternating traceroute hops and flapping pings, and the topology table names the router that echoed the prefix back.
• Suboptimal routes are the silent failure: the redistributed copy arrives as an EIGRP external at AD 170, loses to the native OSPF copy at 110, and the shorter direct path sits unused with FD Infinity.
• AD ranks the source, never the path. distance eigrp 90 109 fixes one router; tags, filters and single-owner prefix design fix the cause everywhere.
• Test presence and correctness separately: show ip route proves the prefix arrived, show ip cef proves where packets go.

The question underneath every case here, how the routing protocols rank against each other when two of them offer the same prefix, runs through the rest of the family too.