Route Redistribution: Exchanging Routes Between Different Routing Protocols

Why Multiple Routing Protocols Coexist in Real Networks

Every routing protocol covered so far in this series — OSPF, EIGRP, BGP — operates independently, maintaining its own separate database and routing logic. In an ideal world, a single network would run a single routing protocol throughout, but real networks frequently end up running multiple protocols simultaneously: a company merger combining two networks that each standardized on a different protocol, legacy equipment that only supports an older protocol, or an edge connecting to an ISP via BGP while running OSPF internally, discussed earlier in this series.

The Problem: Protocols Do Not Share Routes Automatically

Each routing protocol maintains its own separate database and has no native awareness of routes learned by a different protocol running on the same router. Without intervention, a router running both OSPF and EIGRP would have two completely isolated sets of routes, with devices reachable via one protocol invisible to areas of the network relying on the other.

Redistribution: Manually Bridging Protocol Boundaries

Route Redistribution solves this by explicitly taking routes learned by one protocol and re-advertising them into a different protocol, performed on a router that participates in both protocols (sometimes called a Boundary Router or Redistribution Point).

Router(config)# router ospf 1
Router(config-router)# redistribute eigrp 100 subnets metric 20

-- Takes routes learned via EIGRP AS 100 and
-- re-advertises them into OSPF as external routes

Router(config)# router eigrp 100
Router(config-router)# redistribute ospf 1 metric 10000 100 255 1 1500

-- Takes routes learned via OSPF process 1 and
-- re-advertises them into EIGRP

The Critical Problem: Metric Incompatibility

OSPF's cost, discussed earlier in this series, and EIGRP's composite metric, also discussed earlier in this series, are fundamentally incompatible units — there is no mathematical conversion between "OSPF cost of 5" and "EIGRP metric of 3072," since they measure completely different underlying characteristics using entirely different formulas.

This is why redistribution commands require a
manually specified "seed metric" -- a starting
metric value assigned to every redistributed route,
since the receiving protocol has no way to
translate the original protocol's metric into
its own units

OSPF redistribution requires: a single cost value
  (or "subnets" keyword to include non-classful
  subnets, almost always required in modern networks)

EIGRP redistribution requires: five separate values
  (bandwidth, delay, reliability, load, MTU) --
  EIGRP's full composite metric components,
  discussed earlier in this series, must all be
  manually specified since there is no automatic
  translation available

Forgetting the subnets keyword during OSPF redistribution is an extremely common mistake — without it, OSPF only redistributes routes that exactly match a classful network boundary, discussed earlier in this series regarding classful addressing, silently dropping the vast majority of routes in any modern VLSM-based network.

Setting Administrative Distance to Prefer the Correct Path

Redistributed routes lose their original protocol's administrative distance and inherit the receiving protocol's external route distance instead, which can cause a router to prefer a less desirable redistributed path over a better, more direct route learned by a different protocol elsewhere.

Administrative distances relevant to redistribution:
EIGRP internal: 90
OSPF: 110
EIGRP external (redistributed into EIGRP): 170
OSPF external (redistributed into OSPF): 110
  (same as internal OSPF by default, a frequent
  source of suboptimal path selection)

The Serious Risk: Redistribution Routing Loops

When redistribution occurs at more than one boundary router between the same two protocol domains, a genuinely dangerous routing loop becomes possible: a route learned from Protocol A can be redistributed into Protocol B at one boundary router, propagate across Protocol B's domain, then get redistributed back into Protocol A at a second boundary router — potentially causing Protocol A to learn a worse path back to a destination it should already know a better path to directly.

Two-way redistribution loop scenario:

Router 1 (OSPF <-> EIGRP boundary):
  Redistributes OSPF routes into EIGRP,
  and EIGRP routes into OSPF

Router 2 (also OSPF <-> EIGRP boundary):
  Also redistributes in both directions

Risk: a route originally learned via OSPF can
travel through EIGRP at Router 1, then get
redistributed back into OSPF at Router 2,
appearing to OSPF as if it were learned from
a completely different, potentially worse path

Mitigating Redistribution Loops with Route Filtering

Router(config)# route-map PREVENT-LOOP deny 10
Router(config-route-map)# match tag 100
Router(config-route-map)# exit
Router(config)# route-map PREVENT-LOOP permit 20

Router(config)# router ospf 1
Router(config-router)# redistribute eigrp 100 subnets route-map PREVENT-LOOP

-- Tagging routes as they are redistributed, then
-- filtering based on that tag at the second
-- boundary router, prevents a route from being
-- redistributed back into its original protocol

Tagging redistributed routes and filtering based on those tags at every redistribution point is the standard mitigation technique — a route tagged as "originally from EIGRP" can be explicitly denied from being redistributed back into EIGRP anywhere else in the network, closing the loop path entirely.

Verifying Redistributed Routes

Router# show ip route ospf

O E2  192.168.5.0/24 [110/20] via 10.0.0.2, GigabitEthernet0/1

-- "E2" indicates an OSPF External Type 2 route,
-- meaning the metric shown (20) is entirely the
-- redistribution seed metric, unchanged as it
-- propagates through OSPF -- distinct from
-- External Type 1, where OSPF's own internal
-- cost is added to the seed metric as the
-- route propagates further

The distinction between OSPF's External Type 1 and Type 2 routes matters directly for path selection in networks with multiple redistribution points — Type 1 accounts for the internal OSPF cost to reach the redistribution point, making it generally the more accurate choice when multiple boundary routers redistribute the same external routes.

Why Redistribution Requires Careful, Deliberate Design

Redistribution is a powerful tool for bridging genuinely necessary multi-protocol environments, but it is also one of the most common sources of serious, hard-to-diagnose routing problems in real networks specifically because of the loop risks and metric incompatibilities covered in this article. The best practice, wherever organizationally possible, remains standardizing on a single routing protocol; when redistribution is genuinely unavoidable, careful route tagging, filtering, and administrative distance planning are not optional refinements but essential safeguards against the specific failure modes this article has described.