Mutual redistribution between OSPF and BGP is the one design discussion that splits a room of network engineers faster than almost any other. The mechanics are simple. The consequences of getting it wrong are not. This post walks through what redistribution actually does to a route, why OSPF and BGP make different tiebreaker decisions when they both know about the same prefix, and how to decide which protocol should own which decision.
If you want the foundational reading first, start with the OSPF complete guide and the BGP complete guide. This post assumes you already know what an LSA is and what an AS_PATH is.
What redistribution actually does
When you type redistribute ospf 1 subnets under router bgp 65001, the router walks its RIB, finds every route whose source is OSPF process 1, and injects a copy into BGP's local routing table. The same prefix is now known to two protocols. Each protocol keeps its own copy with its own metric and its own next-hop selection logic. When the router decides which copy to install in the forwarding table, it uses administrative distance as the tiebreaker.
This is where it starts to matter.
The administrative distance tiebreaker
Cisco IOS XE ships with the following defaults. Lower wins.
| Route source | Administrative distance |
|---|---|
| Connected | 0 |
| Static | 1 |
| eBGP | 20 |
| EIGRP (internal) | 90 |
| OSPF (all types) | 110 |
| IS-IS | 115 |
| RIP | 120 |
| EIGRP (external) | 170 |
| iBGP | 200 |
Read that table twice. eBGP at 20 beats OSPF at 110. iBGP at 200 loses to OSPF. That single asymmetry is the source of most redistribution accidents you will ever see.
The two redistribution directions
There are two flows worth understanding separately because they fail in different ways.
OSPF into BGP
This is the common case. You have an internal OSPF domain, and you want some of those internal prefixes to be reachable from an external BGP peer. You have two options.
| Method | What it does | When to use |
|---|---|---|
network statement under router bgp | Advertises a single prefix that exactly matches a route in the local routing table (any source) | You know the exact prefixes you want to advertise. Safer. Recommended for production. |
redistribute ospf 1 subnets | Advertises every OSPF route the router knows. The subnets keyword is required or you only get classful summaries. | Lab work, or when the OSPF prefix list is large enough that maintaining a network-statement list is operationally painful. Always pair with a route-map filter. |
A minimal OSPF-into-BGP example with a safety filter:
ip prefix-list OSPF-TO-BGP-OK seq 10 permit 10.10.0.0/16 le 24
!
route-map OSPF-TO-BGP permit 10
match ip address prefix-list OSPF-TO-BGP-OK
!
router bgp 65001
redistribute ospf 1 route-map OSPF-TO-BGP subnetsBGP picks up an OSPF-sourced route with origin code ? (incomplete) and a MED equal to the OSPF cost at the redistribution point. That MED carryover is something you almost always want to override with a route-map set metric, because OSPF cost values are meaningful to OSPF, not to your eBGP neighbor.
BGP into OSPF
This is the dangerous one. The simple version looks like this:
router ospf 1
redistribute bgp 65001 subnetsYou just told OSPF to take every BGP route the router knows and inject it as an OSPF external (Type 5 LSA, or Type 7 if the redistributing router sits in an NSSA). If you peer with a full BGP table, that is roughly 950,000 prefixes you just dumped into your OSPF link-state database. Your switches will reload.
The rule is: filter ruthlessly when you redistribute BGP into OSPF. Use a route-map. Cap the count. Tag the routes so you can identify them later. A working pattern looks like this.
ip prefix-list BGP-TO-OSPF-OK seq 10 permit 192.0.2.0/24
ip prefix-list BGP-TO-OSPF-OK seq 20 permit 198.51.100.0/24
!
route-map BGP-TO-OSPF permit 10
match ip address prefix-list BGP-TO-OSPF-OK
set tag 65001
!
router ospf 1
redistribute bgp 65001 subnets route-map BGP-TO-OSPF metric-type 1The set tag is not cosmetic. It is your loop-prevention mechanism on the return path. If the same prefix tries to come back in via another redistribution point, you match the tag in a deny clause and drop it.
OSPF external types: E1 vs E2
When you inject a route into OSPF via redistribution, you choose its external type. The default is E2.
| Type | Metric calculation | When to use |
|---|---|---|
| E2 (default) | Metric stays constant across the OSPF domain. Receivers see the same cost regardless of how far they are from the ASBR. | You want all internal routers to treat the external destination as equally expensive. Most common. |
| E1 | Metric = redistributed cost + internal OSPF cost to the ASBR. Closer ASBRs win. | You have multiple ASBRs advertising the same prefix and you want traffic to hit the closest one. |
If you redistribute BGP into OSPF at two routers without thinking about this, you get a 50/50 split based on hash, not based on proximity. Use E1 and let OSPF do the proximity math for you.
The tiebreaker game in production
You have a prefix, 10.50.0.0/24, that is reachable two ways:
- Via OSPF, learned from an internal area, cost 100
- Via eBGP, learned from a transit peer
eBGP wins. Admin distance 20 beats OSPF's 110. The router installs the BGP-learned next-hop in the forwarding table. Internal traffic destined for 10.50.0.0/24 leaves the router via the eBGP next-hop, not via the OSPF path.
If 10.50.0.0/24 is actually inside your own network, this is a routing loop in slow motion. The traffic exits to the transit provider, who has no idea where 10.50.0.0/24 is, and either drops it or sends it right back to you.
The fix is to never accept your own internal prefixes from an external peer. Use a route-map on the eBGP inbound direction with an as-path filter or a prefix-list deny.
Verifying redistribution worked
The two commands worth memorizing:
show ip route 10.50.0.0
show ip bgp 10.50.0.0show ip route tells you which copy the RIB installed. The first line shows the source code (B for BGP, O for intra-area OSPF, O E2 for OSPF external type 2, etc.). If you redistributed BGP into OSPF and the route shows up as O E2 on remote routers, the redistribution succeeded.
show ip bgp tells you what the BGP table looks like. After OSPF-into-BGP redistribution, you should see your internal prefixes with origin code ? and the local AS prepended.
When to skip redistribution entirely
Most modern designs prefer not to mutually redistribute at all. The alternatives are worth considering before you write a single redistribute command.
- Static routes pointed at a service IP. If the only thing crossing the boundary is a handful of prefixes, static plus a network statement under BGP is simpler than redistribution and impossible to loop.
- BGP everywhere. Enterprises with consistent multi-vendor infrastructure increasingly run iBGP as the internal IGP-equivalent and skip OSPF entirely for prefix distribution, using OSPF only for next-hop reachability.
- Route leaking with explicit filters. EIGRP and BGP support route-leaking constructs (route-target import / export in VRFs) that give you per-prefix control without the redistribution blast radius.
Key takeaways
OSPF and BGP redistribute in both directions, but they fail in different ways. OSPF into BGP usually just leaks a few prefixes too many and is easy to filter. BGP into OSPF can take down your entire OSPF domain if you forget the filter. Always use a route-map. Always tag injected routes. Always set the metric explicitly rather than relying on the cross-protocol metric translation, because it never says what you think it says.
For deeper coverage on either side, see the OSPF pillar and the BGP pillar.
