Troubleshooting Route Redistribution: Missing and Looping Routes

Redistribution failures come in exactly two flavors: routes that never arrive, and routes that arrive too well (echo back, win the border router's affection, and loop). Both were built deliberately in our lab for this post, so every failure signature below is a real capture from Cisco IOS XE, not a hypothetical. Keep the complete redistribution guide open for the underlying mechanics; this is the diagnostic runbook. Part of the IP Routing 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; your job is to find which, and the commands below bracket the search fast.

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 the prefix 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:

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. The habit of always typing subnets costs nothing and self-documents; the habit of checking show ip protocols tells you which behavior your platform has.

Two more members of the missing-routes family, same diagnostic station: routes that are in the table but learned BY the would-be exporter from the destination protocol (redistribution exports only routes actually installed from the named source protocol, so a prefix that lost the AD battle is invisible to it), and route-map filters that match more than intended (a deny that catches everything is verified in seconds with show route-map, which 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. Intermittent ping success is the churn signature: the protocols are flapping between states as the echoed route wins and loses. Confirm by reading 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 the prefix in the first place: that is a route that left home and came back wearing a disguise. The fix is mutual route tagging on every border router (tag on export, deny your own tag on import). The full design with captures of the fixed state is in Redistribution Loop Prevention: Route Tags, AD, and Filtering; the after picture looks like this:

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 correct 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 routes the routing table attributes to the named source protocol, so "redistribute ospf 1" walks past the prefix entirely; as far as the RIB is concerned, it is not an OSPF route here. 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 exactly the feedback fuel that Case 3 burns, so finding one during a missing-routes hunt is a prompt to check your tagging posture while you are in there.

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; a show ip route issued too fast shows the old world, and the honest habit is checking the route's age column (our fixed-state captures all show fresh timers like 00:00:30, which is itself evidence the fix took). Second, flap-induced ambiguity: during active feedback churn like Case 3, consecutive commands can show different next hops, which is not your terminal lying but the pathology itself; a traceroute plus two RIB reads a few seconds apart distinguishes "converging" from "oscillating". If the state will not settle, capture the oscillation (it is diagnostic gold) rather than waiting for a clean screenshot that will never come.

Prevention: The Five-Line Checklist

Every redistribution change, before you type it: name the single owner of each prefix range (which domain originates it); 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 border routers plus one interior router per domain. The whole ritual costs ten minutes and converts redistribution from folklore into an auditable change. The design reasoning behind each line is covered 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.

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 full circle a route traveled, as we did 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 currently say.

Key Takeaways

Missing routes are almost always a seed metric (EIGRP's default is infinity and it fails silently), a filter, or exporting a route the border router installed from the wrong protocol; "Total Redist Count: 0" under show ip protocols is the tell. The subnets keyword matters on legacy IOS and is default behavior on modern IOS XE, and the router tells you which world you are in. Looping routes announce themselves as alternating traceroute hops and flapping pings, the EIGRP topology table names the router that echoed the prefix, and route tags at every border are the structural cure. Work the four stations in order and you will not chase ghosts. The mechanics live in the redistribution guide, the loop design in the route tags deep dive, and the rest of the protocol family in the IP Routing pillar.