Cisco Route Redistribution Between OSPF and BGP

What Route Redistribution Actually Is

Route redistribution is the process of taking routes learned by one routing protocol and importing them into another. That definition is accurate, but it doesn't capture how consequential getting the details wrong can be. In the context of OSPF and BGP, redistribution is the mechanism that bridges your internal infrastructure to the wider world. OSPF handles your interior routing — tracking what's reachable inside your autonomous system. BGP handles the exterior — who you are to your upstream providers, peers, and in some designs, your own data centers. These two protocols don't share a common language, and redistribution is the translator between them.

OSPF calculates cost using a link-state metric, builds its topology database from LSAs, and converges using Dijkstra's shortest path first algorithm. BGP cares almost nothing about link cost. It makes forwarding decisions based on attributes like AS path length, local preference, MED, and origin type. When you redistribute between them, you have to deliberately bridge those two different models — and if you don't control what crosses that bridge, you'll regret it quickly.

On Cisco IOS and IOS-XE, redistribution is configured with the

redistribute

command under the target routing process. But calling it a single command undersells the complexity involved. A bare redistribute statement with no filtering can seriously destabilize your network. In my experience, any redistribution configuration worth pushing to production includes prefix-lists, route-maps, metric values, and a clear understanding of what attributes get assigned when routes cross protocol boundaries.

How Redistribution Works Under the Hood

When you redistribute OSPF routes into BGP, the BGP process takes each matching OSPF route and creates a new BGP prefix entry. That route gets assigned an origin type — typically incomplete (?) since it wasn't learned natively via BGP — and a MED value if you've configured one. Without a route-map explicitly setting a MED, none is assigned, which means your BGP peers won't have a basis for preferring one exit path over another based on your internal OSPF topology. That's usually not what you want at a multi-homed edge.

Going the other direction — redistributing BGP into OSPF — requires a seed metric. OSPF has no concept of a route with no cost. If you don't provide one, IOS may default to a metric of 1 or 20 depending on the platform and version, but the behavior isn't always predictable. More importantly, you need the

subnets

keyword, or IOS will silently ignore every non-classful route in the redistribution. If your BGP table contains 10.10.5.0/24, that's a subnet of the classful Class A network 10.0.0.0, and without

subnets

it won't enter OSPF. This is a classic gotcha that has burned network engineers since the early IOS 12.x days and still catches people on IOS-XE today. No warning, no error — the routes just don't appear.

Administrative distance (AD) adds another layer of complexity. OSPF has an AD of 110. External BGP (eBGP) has an AD of 20. Internal BGP (iBGP) is 200. When both protocols run on the same router and both know about the same prefix, the lower AD wins the RIB. That means an eBGP-learned route will always beat an OSPF-learned route into the routing table, even if the OSPF path is better for your internal topology. This interaction matters a great deal in mutual redistribution scenarios, because unexpected AD outcomes can cause traffic to take paths you didn't intend.

Redistributing OSPF into BGP

Let's walk through the most common deployment pattern. You have a border router at 10.1.0.1 running OSPF area 0 internally and eBGP to an upstream provider. Your internal OSPF domain covers several subnets in the 10.10.0.0/16 and 10.20.0.0/16 ranges. You want to advertise those internal prefixes to your BGP peer at 10.254.0.1 in AS 65002.

The naive approach — redistributing everything from OSPF into BGP without filtering — looks like this:

router bgp 65001
 bgp router-id 10.1.0.1
 neighbor 10.254.0.1 remote-as 65002
 neighbor 10.254.0.1 description UPSTREAM-PROVIDER
 !
 address-family ipv4 unicast
  redistribute ospf 1
 exit-address-family

It works, but it's reckless. You're injecting everything OSPF knows into BGP — including management loopbacks, point-to-point transit links, and internal infrastructure subnets you never intended to advertise externally. A better approach uses a prefix-list to explicitly control what crosses the boundary:

ip prefix-list INTERNAL-NETS seq 10 permit 10.10.0.0/16 le 24
ip prefix-list INTERNAL-NETS seq 20 permit 10.20.0.0/16 le 24
ip prefix-list INTERNAL-NETS seq 30 deny 0.0.0.0/0 le 32

route-map OSPF-TO-BGP-MAP permit 10
 match ip address prefix-list INTERNAL-NETS
 set origin incomplete
 set metric 200

router bgp 65001
 bgp router-id 10.1.0.1
 neighbor 10.254.0.1 remote-as 65002
 neighbor 10.254.0.1 description UPSTREAM-PROVIDER
 !
 address-family ipv4 unicast
  neighbor 10.254.0.1 activate
  redistribute ospf 1 route-map OSPF-TO-BGP-MAP
 exit-address-family

The

set metric 200

line sets the MED on the redistributed routes. MED is what you send to a BGP peer to influence which of your links they prefer for inbound traffic. If you have two upstream connections and want to steer inbound traffic based on internal OSPF cost, deriving MED from the OSPF metric using

set metric-type internal

in your route-map is an elegant way to accomplish that without maintaining separate MED values manually.

Redistributing BGP into OSPF

This is where the real danger lives. Redistributing BGP into OSPF means your interior routing protocol is about to learn external prefixes. On a router carrying a full internet BGP table, that's over 900,000 routes. Flooding those into OSPF as Type 5 External LSAs will destroy your OSPF domain. The SPF recalculation load will cause adjacency instability across every router in the area, the LSDB will balloon beyond what most platforms can handle, and you'll have an outage that takes hours to explain in a post-mortem.

The only sensible approach is to redistribute a tightly controlled, minimal set of BGP prefixes into OSPF. In most enterprise designs, that means a default route only — letting internal routers point their unknown traffic toward the edge without knowing anything about the external topology. Occasionally you'll also need a small number of specific aggregated prefixes, but keep the list as short as possible.

ip prefix-list DEFAULT-ONLY seq 10 permit 0.0.0.0/0
ip prefix-list DEFAULT-ONLY seq 20 deny 0.0.0.0/0 le 32

route-map BGP-TO-OSPF-MAP permit 10
 match ip address prefix-list DEFAULT-ONLY
 set metric 50
 set metric-type type-2
 set tag 65001

router ospf 1
 router-id 10.1.0.1
 redistribute bgp 65001 subnets route-map BGP-TO-OSPF-MAP

Two things demand attention here. The

subnets

keyword is non-negotiable — without it, non-classful routes silently disappear. And

set metric-type type-2

keeps the metric fixed as the route propagates through OSPF. A Type 2 external route carries the same metric value across every router in the domain, regardless of the link costs between them. A Type 1 external route adds the internal OSPF cost to the external metric as it traverses the network. Type 2 is the default and is generally preferred for redistributed routes because it simplifies behavior and makes the metric value predictable.

Notice the

set tag 65001

line. That's not just organizational housekeeping — it's the foundation of loop prevention, which we'll get to next.

Mutual Redistribution and Routing Loop Prevention

When you're redistributing in both directions simultaneously — OSPF into BGP and BGP into OSPF — on the same router or across multiple redistribution points, you create the conditions for routing loops. I've seen this scenario cause production outages, and the failure mode is subtle enough that it's worth walking through in detail.

Here's the loop scenario: Router A redistributes an OSPF-originated prefix into BGP and advertises it to Router B. Router B also has a redistribution configuration and takes that BGP route and injects it back into OSPF as an external route. Now OSPF on Router A sees two entries for the same prefix — the original internal OSPF route, and a re-imported Type 5 external route coming from Router B. Depending on metric values, one may win over the other in unexpected ways. In the worst case, Router A forwards traffic toward Router B expecting Router B to handle it, while Router B's RIB sends that same traffic back to Router A. The loop spins until TTL expires.

The standard fix is OSPF route tagging combined with route-map deny clauses. When you redistribute BGP into OSPF, you tag those external routes with a value that identifies their origin. When you redistribute OSPF back into BGP, a deny clause in your route-map drops any route carrying that tag before it can re-enter BGP. This is a one-way valve that prevents re-importation regardless of how many redistribution points are in your topology.

! Deny routes that were originally from BGP (tagged 65001)
route-map OSPF-TO-BGP-MAP deny 5
 match tag 65001

! Permit internal OSPF-originated routes into BGP
route-map OSPF-TO-BGP-MAP permit 10
 match ip address prefix-list INTERNAL-NETS
 set origin incomplete
 set metric 200

The deny clause at sequence 5 fires first. Any route in OSPF tagged 65001 — meaning it originally came from BGP and got redistributed inward — gets dropped. Only genuine OSPF-originated routes make it through to sequence 10. This pattern scales cleanly across multiple redistribution points as long as every point uses the same tagging convention consistently.

A Complete Production Configuration

Let me bring this together into a single, coherent configuration you could actually review in a change window. This is for a border router running IOS-XE, sitting at the edge of an enterprise OSPF domain and peering eBGP to an upstream provider. The goal is to advertise internal prefixes outbound and inject only a default route inbound — with full loop protection.

! Prefix lists
ip prefix-list INTERNAL-NETS seq 10 permit 10.10.0.0/16 le 24
ip prefix-list INTERNAL-NETS seq 20 permit 10.20.0.0/16 le 24
ip prefix-list INTERNAL-NETS seq 30 deny 0.0.0.0/0 le 32

ip prefix-list DEFAULT-ONLY seq 10 permit 0.0.0.0/0
ip prefix-list DEFAULT-ONLY seq 20 deny 0.0.0.0/0 le 32

! Route-map: BGP -> OSPF (default route only, tagged for loop prevention)
route-map BGP-TO-OSPF-MAP permit 10
 match ip address prefix-list DEFAULT-ONLY
 set tag 65001
 set metric 50
 set metric-type type-2

! Route-map: OSPF -> BGP (deny re-imports, permit internal nets)
route-map OSPF-TO-BGP-MAP deny 5
 match tag 65001

route-map OSPF-TO-BGP-MAP permit 10
 match ip address prefix-list INTERNAL-NETS
 set origin incomplete
 set metric 200

! OSPF process
router ospf 1
 router-id 10.1.0.1
 network 10.1.0.0 0.0.0.255 area 0
 network 10.10.0.0 0.0.255.255 area 0
 network 10.20.0.0 0.0.255.255 area 0
 redistribute bgp 65001 subnets route-map BGP-TO-OSPF-MAP

! BGP process
router bgp 65001
 bgp router-id 10.1.0.1
 bgp log-neighbor-changes
 neighbor 10.254.0.1 remote-as 65002
 neighbor 10.254.0.1 description UPSTREAM-PROVIDER
 neighbor 10.254.0.1 soft-reconfiguration inbound
 !
 address-family ipv4 unicast
  neighbor 10.254.0.1 activate
  redistribute ospf 1 route-map OSPF-TO-BGP-MAP
 exit-address-family

This configuration is explicit about every decision it makes. The prefix-lists define exactly what crosses each boundary. The route-map sequencing ensures tagged routes are blocked before they can loop. The

subnets

keyword is present so non-classful routes aren't silently dropped. And

soft-reconfiguration inbound

on the BGP neighbor lets you run

show bgp ipv4 unicast neighbors 10.254.0.1 received-routes

without triggering a route refresh — useful during troubleshooting without disrupting the peering session.

Verifying That Redistribution Is Working

Once the configuration is in place, verification is straightforward if you know which commands to use. Start by confirming that OSPF-originated routes are appearing in the BGP table:

! Confirm OSPF-learned prefixes appear in BGP RIB
show bgp ipv4 unicast | include 10.10
show bgp ipv4 unicast | include 10.20

! Verify the redistributed default in OSPF as External Type 2
show ip ospf database external

! Check the main routing table for each protocol's redistributed routes
show ip route ospf
show ip route bgp

! See route-map hit counts — zero hits on a deny clause means loop prevention isn't firing
show route-map OSPF-TO-BGP-MAP
show route-map BGP-TO-OSPF-MAP

! Confirm what you're advertising to your upstream peer
show bgp ipv4 unicast neighbors 10.254.0.1 advertised-routes

The

show route-map

output is one of the most useful diagnostic tools in a redistribution troubleshoot. Each clause shows a match count. If a permit clause that should be matching internal prefixes shows zero hits, either your prefix-list is wrong, the OSPF routes don't exist in the expected form, or the route-map isn't being applied to the right redistribution statement. If the deny clause at sequence 5 shows zero hits when you expect it to be blocking re-imports, your tagging isn't working — go back and verify that BGP-TO-OSPF-MAP is setting the tag correctly and that the OSPF redistribution is using that route-map.

Common Misconceptions

The most pervasive misconception I encounter is treating

redistribute ospf

and

network

statements in BGP as interchangeable. They're not. The

network

command under BGP advertises a specific prefix if and only if that exact prefix exists in the RIB — it's a manual, static declaration. Redistribution is dynamic: if OSPF learns a new subnet that matches your prefix-list, it automatically enters BGP. These serve different purposes and are often used together. Don't replace one with the other without understanding the behavioral difference.

Another misconception is that redistribution is bidirectional by default. It isn't.

redistribute ospf 1

under the BGP process moves OSPF routes into BGP. It has absolutely no effect on BGP routes appearing in OSPF. Those are two separate configuration statements under two separate routing process blocks, and forgetting the second one leads to an hour of troubleshooting where everything looks right on paper but traffic in one direction has no return path.

People also routinely underestimate the impact of OSPF area types on redistributed routes. Routes redistributed into OSPF become External LSAs — Type 5 in normal areas, Type 7 in NSSA areas. If any of your internal routers are in a stub area or totally-stub area, they won't receive Type 5 LSAs at all. Those routers will never see your redistributed BGP default route via the normal LSA mechanism. You'd need to either use an NSSA design, change the area type, or inject the default route separately using

default-information originate

under OSPF. Design your area structure around your redistribution points from the beginning — retrofitting this is painful.

Finally, there's the administrative distance trap in mutual redistribution. If a router learns the same prefix from both OSPF and eBGP, eBGP wins with AD 20 versus OSPF's 110. This can cause an internal prefix that should be OSPF-routed inside your domain to suddenly be overridden by a BGP entry. You can manipulate AD using

distance bgp

under the BGP process or even per-prefix using the

distance

command, but do this carefully. Changing AD solves one problem and usually creates at least two others if you haven't mapped out all the downstream effects first. When in doubt, tighten your prefix-lists before you start touching administrative distance.

---

Route redistribution between OSPF and BGP is one of those topics that looks straightforward in a lab and reveals its depth in production. The mechanics of the

redistribute

command are simple. The discipline required to do it safely — controlled prefix-lists, explicit route-maps, loop prevention via tags, and careful attention to metric types and administrative distance — is what separates a working configuration from a ticking clock. Get the structure right the first time, document your tagging conventions, and redistribution will run quietly in the background for years. Get it wrong and you'll be reading LSDBs at 2 AM wondering why your OSPF domain is unstable.