Route Redistribution OSPF EIGRP BGP

Introduction

In real enterprise networks, running a single routing protocol end-to-end is rarely practical. Mergers, acquisitions, multi-vendor environments, and phased migrations all lead to networks where OSPF, EIGRP, and BGP coexist. The mechanism that allows these protocols to share routing information with one another is called route redistribution.

Redistribution is one of the most tested and most operationally critical topics on the CCNP ENARSI exam. Mistakes here can cause routing loops, suboptimal paths, or complete reachability failures. This lesson walks through the core concepts behind redistributing routes between OSPF, EIGRP, and BGP, the configuration commands involved, and the pitfalls you must avoid.

By the end of this lesson, you will be able to:

Explain how route redistribution works between OSPF, EIGRP, and BGP
Configure redistribution using the correct match statements and default metrics
Understand OSPF path preference and external route types
Identify common redistribution problems and how to resolve them

Key Concepts

What Is Route Redistribution?

Route redistribution is the process of taking routes learned by one routing protocol and injecting them into another routing protocol. The router performing this function sits at the boundary between two routing domains and is known as an Autonomous System Boundary Router (ASBR) in OSPF terminology.

Each routing protocol uses its own metric system to evaluate path quality. OSPF uses cost, EIGRP uses a composite metric based on five variables, and BGP uses a complex set of path attributes. When routes cross from one protocol into another, the original metric is meaningless to the receiving protocol. This is why setting a proper seed metric (or default metric) during redistribution is essential.

OSPF Route Types and Path Preference

OSPF classifies routes into distinct categories, and the classification directly affects path selection:

Route Type	Symbol	Description
Intra-area	O	Routes within the same OSPF area
Inter-area	O IA	Routes crossing an Area Border Router (ABR), between areas
External Type 1	O E1	Redistributed routes; cost = external cost + internal cost to reach the ASBR
External Type 2	O E2	Redistributed routes; cost = external cost only, regardless of internal cost

OSPF prefers routes in the following strict order: intra-area (O) is preferred over inter-area (O IA), which is preferred over external E1, which is preferred over external E2. This hierarchy is important to understand because redistributed routes always enter OSPF as external routes, placing them at the lowest priority in the path selection process.

The key difference between E1 and E2 routes is how cost is calculated. An E2 route always uses only the external cost assigned at the point of redistribution, no matter how far the route travels inside the OSPF domain. An E1 route adds the internal OSPF cost to reach the ASBR on top of the external cost. In large networks with multiple ASBRs, E1 routes allow OSPF to make better forwarding decisions because they account for internal path cost.

EIGRP Metric Components

EIGRP uses five variables to calculate its composite metric:

Component	Description
Bandwidth	Minimum bandwidth along the path (in Kbps)
Delay	Cumulative delay along the path (in tens of microseconds)
Reliability	Link reliability (0-255, where 255 is fully reliable)
Load	Link utilization (1-255, where 255 is fully loaded)
MTU	Maximum Transmission Unit along the path

When routes are redistributed into EIGRP from another protocol, they do not carry these five parameters. Without them, EIGRP cannot properly calculate a metric, and the routes may not be installed. This is why you must configure a default metric when redistributing into EIGRP, supplying values for all five components so that EIGRP can work with the imported routes.

Redistributing OSPF into BGP — The Match Statement

When redistributing OSPF routes into BGP, a critical detail is the match statement on the redistribute command. By default, not all OSPF route types are included. Both external type 1 and type 2 routes must be explicitly matched to ensure they are redistributed. To redistribute all OSPF routes — internal, external type 1, and external type 2 — you must specify each type:

redistribute ospf 1 match internal external 1 external 2

If you omit the match keywords, you risk leaving out entire categories of OSPF routes from BGP, which leads to reachability problems.

How It Works

The Redistribution Process

When a router redistributes routes, it takes entries from the routing table of one protocol and advertises them as if they were native routes in the target protocol. The redistributing router becomes the injection point, and all other routers in the target domain learn these routes through normal protocol operation.

Here is the general flow:

The ASBR has active adjacencies in both routing domains (for example, OSPF on one set of interfaces and EIGRP on another).
The administrator configures the redistribute command under the target routing protocol, specifying the source protocol.
The router takes qualifying routes from the source protocol's routing table and injects them into the target protocol with an appropriate metric.
Downstream routers in the target domain receive these routes as external routes.

Metric Translation Challenges

The fundamental challenge is that metrics do not translate across protocols. OSPF cost (based on bandwidth) has no equivalent in EIGRP's composite calculation, and neither maps cleanly to BGP path attributes. When you redistribute:

Into EIGRP: You must supply a default metric with all five components — bandwidth, delay, reliability, load, and MTU. Without this, redistributed routes will not have a valid metric and may not appear in the routing table.
Into OSPF: Redistributed routes appear as E1 or E2 external routes. The external cost (seed metric) is assigned at the point of redistribution.
Into BGP: OSPF routes need the proper match statement to include the correct route types. BGP uses its own path selection algorithm based on attributes such as local preference, AS path length, and MED.

EIGRP for IPv6 Considerations

There are important caveats when working with EIGRP in an IPv6 environment. Unequal Cost Multi-Path (UCMP) using the variance command is not functional for IPv6. Even if variance is configured, unequal paths will be installed into the IPv6 Forwarding Information Base (FIB) as equal-cost paths. This behavior is due to a lack of metric-based UCMP support in the IPv6 Routing Information Base (RIB). This is tracked as an enhancement request under CSCwi91760.

Additionally, in a pure IPv6 environment, manual Router ID (RID) configuration is required for EIGRP, since there may be no IPv4 address available for automatic RID selection.

Configuration Example

Setting a Default Metric for EIGRP Redistribution

When redistributing routes into EIGRP, configure a default metric to provide the five required components:

Router(config-router)# default-metric 10000 100 255 100 1500

This sets:

Bandwidth: 10000 Kbps
Delay: 100 (tens of microseconds)
Reliability: 255 (maximum)
Load: 100
MTU: 1500 bytes

Overriding the Delay Component with a Route Map

You can use a route map to override metric components on redistributed routes. For example, to set a specific composite metric using the EIGRP metric format:

route-map Offset permit 10
 set metric 4294967295 655360 255 1 1500

This route map can then be applied under EIGRP to influence path selection for redistributed routes:

router eigrp ROCKS
 address-family ipv6 autonomous-system <ASN>
  topology base
   distribute-list route-map Offset in Gi1

Redistributing OSPF into BGP with Match Statements

To redistribute OSPF routes into BGP, always specify which OSPF route types to include:

redistribute ospf 1 match internal external 1 external 2

internal — includes intra-area (O) and inter-area (O IA) routes
external 1 — includes E1 routes
external 2 — includes E2 routes

Omitting any of these keywords means those route types will not be redistributed into BGP.

MP-BGP Configuration for IPv4 and IPv6

When running BGP with both IPv4 and IPv6 address families, use Multiprotocol BGP (MP-BGP) to exchange routes for multiple address families through a single peering session. The configuration separates neighbor definition (who) from address family activation (what):

router bgp 64512
 no bgp default ipv4-unicast
 neighbor 192.0.2.2 remote-as 64512
 neighbor 192.0.2.2 update-source Loopback0
 neighbor 192.0.2.3 remote-as 64513
 !
 address-family ipv4 unicast
  neighbor 192.0.2.2 activate
  neighbor 192.0.2.3 activate
 !
 address-family ipv6 unicast
  neighbor 192.0.2.2 activate

The no bgp default ipv4-unicast command prevents BGP from automatically activating IPv4 unicast for all neighbors, giving you explicit control over which address families each neighbor participates in.

For IPv6-addressed neighbors, the same separation applies:

router bgp 64512
 no bgp default ipv4-unicast
 neighbor 2001:db8:cafe::1 remote-as 64512
 neighbor 2001:db8:cafe::1 update-source Loopback0
 neighbor 2001:db8:f00d::2 remote-as 64513
 !
 address-family ipv4 unicast
  no neighbor 2001:db8:cafe::1 activate
  neighbor 2001:db8:f00d::2 activate
 !
 address-family ipv6 unicast
  neighbor 2001:db8:cafe::1 activate

MP-BGP Next-Hop Considerations

A critical consideration with MP-BGP is the next-hop address. By default, iBGP keeps the next hop unchanged, while eBGP sets the next hop to the local source address of the peering. This creates a challenge when the source address of the peering session belongs to a different address family than the routes being advertised. For example, advertising IPv6 routes over an IPv4-addressed peering requires careful next-hop handling to ensure reachability.

Real-World Application

Common Deployment Scenarios

Route redistribution is encountered in several real-world situations:

Corporate mergers and acquisitions: One company runs OSPF and the acquired company runs EIGRP. Redistribution bridges the two domains during the transition period.
Multi-vendor environments: EIGRP is a protocol historically associated with specific vendor platforms. When other vendors are introduced, OSPF or BGP serves as the common protocol, with redistribution at the boundary.
WAN-to-campus boundary: Many enterprise networks run OSPF or EIGRP internally and use BGP toward service providers. Redistribution between the IGP and BGP occurs at the edge routers.

Design Considerations and Best Practices

Best Practice: Always configure a default metric when redistributing into EIGRP. Without the five metric components, redistributed routes may not be installed.

Best Practice: When redistributing OSPF into BGP, explicitly match internal, external 1, and external 2 route types to avoid silently dropping routes.

Warning: A redistributed static route takes precedence over an EIGRP summary route because the static route has an administrative distance of 1, while the EIGRP summary route has an administrative distance of 5. This can cause unexpected forwarding behavior if not accounted for.

Keep redistribution points to a minimum — ideally one or two routers — to reduce the risk of routing loops.
Use route maps and distribute lists to filter routes at redistribution points, preventing unnecessary or dangerous routes from leaking between domains.
Monitor external route counts after redistribution to verify that the correct number of prefixes are being exchanged.

Summary

Route redistribution allows OSPF, EIGRP, and BGP to exchange routing information across protocol boundaries, but requires careful metric and route-type handling.
OSPF path preference follows a strict hierarchy: intra-area, then inter-area, then E1 external, then E2 external. Redistributed routes always enter as externals.
EIGRP redistribution requires a default metric with all five components (bandwidth, delay, reliability, load, MTU) because external routes lack native EIGRP metric values.
When redistributing OSPF into BGP, use the match internal external 1 external 2 keywords to include all route types.
MP-BGP separates neighbor identity from address family activation, allowing a single peering to carry both IPv4 and IPv6 routes.

Next, continue your studies with the final lesson in this course, which builds on these redistribution concepts with advanced filtering and path manipulation techniques.