Redistribution

Why it exists

Networks end up running more than one routing protocol — an acquisition, a vendor migration, a segment that needs something the rest does not. Each protocol knows only its own routes, and something has to carry a prefix across the boundary.

Redistribution does that, and in doing so discards two things: the metric, because the units are incompatible, and the loop prevention, because that is internal to the protocol that had it. Everything difficult about redistribution follows from the second. RFC 2328 §12.4.4AS-external-LSAsRFC 2328 · INTERNET STANDARD · April 1998

The best redistribution design is usually less redistribution. Most requirements that look symmetric are not, and a default route one way with a summary the other removes the problem rather than managing it.

A route crosses a boundary and loses its history

Two protocols measure distance in incompatible units. Crossing between them discards the metric, and something has to invent a replacement.

How it works

A router running both protocols takes routes from one routing information base and originates them into the other. It supplies a seed metric, because the original is meaningless in the new protocol, and marks them external.

External routes are deliberately discounted. A protocol prefers its own routes because it can reason about them and cannot reason about one whose history it does not have — which is why EIGRP gives external routes an administrative distance of 170 against 90 for internal.

Administrative distance decides which protocol wins for the same prefix on the same router. It is local, configurable, compares nothing about the routes themselves, and runs only after longest-prefix match has already chosen the prefix.

Route tags are the mechanism that puts back what redistribution removed. A tag applied on export and matched on import lets a router recognise a route that originated in its own domain and refuse to re-import it.

On the wire

Constructed examples, encoded from the field table below them — not captured traffic.

Configure it

When it breaks

Symptom first, because that is what you have when it happens.

1. Traffic to a prefix loops between two border routers, or a route flaps continuously between two sources.

   Narrow it down

   1. Establish where the prefix originates and trace every path it can take back to that protocol.
   2. Check whether both borders redistribute in both directions.
   3. Look for route tags — their absence is usually the answer.

   Cause

   Mutual redistribution with no tagging. A route leaves one protocol, returns through the other, and is re-injected because nothing records that it started there.

   Fix

   Tag on export and deny on import at every redistribution point, in both directions. Or remove one direction and send a default instead.

2. Redistribution is configured, the command is accepted, and no routes appear.

   Narrow it down

   1. Check whether a seed metric was set, and what the platform default is.
   2. Confirm the source routes are actually in the routing table, not just in the protocol database.
   3. Look for a route map that matches nothing.

   Cause

   A missing seed metric. Redistributing into some protocols with no metric produces a metric of infinity, which is a valid configuration that advertises nothing.

   Fix

   Set the metric explicitly. Never rely on the default, which differs by platform and by target protocol.

3. Traffic takes a long path to a destination that has a much shorter one, and the routing table looks correct.

   Narrow it down

   1. Check whether the preferred route is internal and the shorter one external.
   2. Compare administrative distances rather than metrics.
   3. Establish whether the flat seed metric has made two very different paths look identical.

   Cause

   Either external routes are being discounted as designed, or every redistributed route carries the same seed metric so the protocol cannot tell a near destination from a far one.

   Fix

   Set metrics per prefix with a route map where the distinction matters. Changing administrative distance is the tempting fix and the one that creates loops.

4. Redistributing one protocol into another works, and the directly connected networks on the redistributing router are missing.

   Narrow it down

   1. Check whether connected routes are being redistributed separately.
   2. Confirm which interfaces are covered by the source protocol’s own configuration.
   3. Look at whether a passive interface is involved.

   Cause

   Redistributing a protocol moves that protocol’s routes and nothing else. A connected network the source protocol does not carry is not included, because it was never one of its routes.

   Fix

   Redistribute connected as well, with a route map limiting it to the interfaces intended. Redistributing all connected routes without one is how management and point-to-point subnets end up advertised globally.

5. Routes leave one domain and never return, or return only for some prefixes, after a route-map change that looked symmetric.

   Narrow it down

   1. Compare the export and import route maps at every redistribution point.
   2. Confirm tag match and set clauses point the same way on both borders.
   3. Check whether a deny that was meant for re-import also matches first-hop exports.

   Cause

   Policy applied in only one direction, or a deny that matches more than the tagged re-imports. Redistribution is not symmetric just because both directions are configured — each map is evaluated independently.

   Fix

   Make export and import explicit and opposite: set the tag on the way out, match and deny it on the way in. Test with a single prefix before opening the whole table.

Design notes

Tag from the beginning, at every redistribution point, in both directions. Tags cost nothing and retrofitting them to a network that is already looping means enumerating every path a route can take — which is exactly the analysis the loop made hard.

Set the seed metric deliberately. The default on some platforms is infinity, which silently redistributes nothing; on others it is a flat value that makes every external destination look equidistant regardless of how far away it is.

Changing administrative distance to fix a redistribution problem usually moves it. Distance is per router and per source, so a change that fixes the path at one border can invert the preference at another and produce a loop that was not there before.

Prefer one-way redistribution with a default. It is smaller, it cannot loop, and the optimality it gives up is rarely worth what mutual redistribution costs to operate.

Misconceptions

“The metric is converted when a route is redistributed.”

It is discarded. There is no conversion because the units are not comparable — an OSPF cost is not a number of anything EIGRP measures. A seed metric is invented at the boundary, and every route gets the same one unless a policy says otherwise.

“Administrative distance is a kind of metric.”

A metric compares paths within one protocol. Distance compares protocols, is local to one router, is configurable, and never crosses the wire. Two routers can disagree about it entirely, which is one way to build a loop.

“Route tags are a nice-to-have.”

They are the only mechanism that puts back the loop prevention redistribution removes. In a mutual redistribution they are not optional, and adding them after the loop appears is far harder than adding them at the start.

“Redistributing at two points is more redundant.”

It is more redundant and it is what creates the loop. One redistribution point cannot loop; two can, and the second is the reason tagging exists. The redundancy is worth having and has to be paid for with policy.

More walkthroughs

Terms

Seed metric

The metric invented at a redistribution boundary, because the original is meaningless in the receiving protocol. Every route gets the same one unless a policy differentiates them.

Administrative distance

A local, configurable preference between routing protocols offering the same prefix. It never crosses the wire and runs only after longest-prefix match has chosen the prefix.

Route tag

A value attached to a route and carried across protocols. In a mutual redistribution it restores the origin history that redistribution discarded, which is what prevents the loop.

Check yourself

• What happens to a route’s metric when it is redistributed into another protocol?

  • It is converted proportionally
  • It is discarded, and a seed metric is supplied at the boundary
  • It is carried unchanged
  • It is set to the lowest possible value
• Why does mutual redistribution at two routers create a loop when one router does not?

  • Two routers double the metric
  • Each router sees only half the round trip, and nothing records that the route originated in the other protocol
  • The two routers disagree about the metric
  • It is a bug in specific implementations
• What does administrative distance compare?

  • Paths within one protocol
  • Routing protocols offering the same prefix, locally on one router
  • Prefix lengths
  • Interface bandwidths
• What does a route tag provide in a mutual redistribution?

  • A better metric
  • The origin history that redistribution discarded, so a router can refuse to re-import its own domain’s routes
  • Faster convergence
  • Authentication
• A branch running EIGRP connects to an OSPF core. What is usually the better design?

  • Mutual redistribution with tags at both borders
  • A default route into the branch and a summary into the core
  • Run OSPF everywhere
  • Static routes only
• Redistribution into a protocol is configured and accepted, but no routes appear. What is the most common cause?

  • Administrative distance is too high
  • A missing seed metric — some platforms treat the default as infinity and advertise nothing
  • The source protocol is not running
  • BGP will not accept redistributed IGP routes
• You redistribute OSPF into EIGRP. Which connected networks on the ASBR are included?

  • Every connected interface on the router
  • Only connected networks that OSPF itself carries — redistribution moves that protocol’s routes and nothing else
  • Only the interface facing the EIGRP domain
  • None — connected routes cannot be redistributed
• Why does EIGRP give redistributed (external) routes a worse administrative distance than internal ones?

  • External metrics are always larger
  • The receiving protocol cannot reason about a route whose history it does not have, so it deliberately prefers its own
  • BGP requires it
  • Seed metrics are unreliable on every platform

Related

• OSPFv2

  Each router floods a description of its links, then independently computes the same shortest-path tree — so the forwarding tables agree without exchanging routes.

• BGP

  A TCP session that exchanges path attributes, then picks one path with a total-order waterfall — not a shortest-path flood.

• EIGRP

  A distance-vector protocol that keeps a proven loop-free backup ready, so most failures are a switch rather than a recomputation — and asks the network only when it has none.