BGP vs OSPF: When to Use Each Routing Protocol

BGP and OSPF are the two routing protocols every working network engineer ends up running, and they are the two most CCNP and CCIE candidates compare without fully understanding why they exist as separate things in the first place. The "BGP vs OSPF" framing makes it sound like a choice. It is not. They solve different problems and you almost always run both.

This article walks through what each protocol is actually for, the technical differences that matter in production, when each is the right answer, and the surprisingly common cases where the answer is "both, layered." If you are studying for a certification, designing a new network, or trying to explain to a manager why the answer to "should we use BGP" depends on the question, this is the comparison.

The TL;DR

OSPF is an interior gateway protocol (IGP). It finds the best path between routers inside a single administrative domain, fast, using a metric you do not get to argue with. BGP is an exterior gateway protocol (EGP). It exchanges reachability between administrative domains using a policy you have full control over, slowly and on purpose.

If you control the routers on both sides of every link, you want OSPF (or another IGP). If the routers on the other side of a link belong to someone else, you want BGP. Most production networks have both: OSPF inside, BGP at the edges, with OSPF providing the underlying reachability that lets BGP sessions stay up.

Protocol Type: Link-State vs Path-Vector

OSPF is link-state. Every router floods its view of the local topology to every other router in the area, every router builds the same map, and every router runs Dijkstra's shortest-path algorithm against that map independently. The result is a network where every router has the same picture of the topology and they all converge on the same answer.

BGP is path-vector. Every BGP route carries the list of autonomous systems (the AS_PATH) it has traversed. Routers do not exchange topology, they exchange routes plus path metadata. The "vector" is the AS-level path; the "path" is the explicit history that prevents loops (if your own AS appears in the AS_PATH of an incoming route, reject it).

The implications matter:

• OSPF reveals topology to all participants. That is fine inside one organization. It is not fine across organizational boundaries; you do not want to expose your internal topology to a peer ISP.
• BGP hides topology. Each AS only sees the AS-level path, not the routers inside other ASes. This is a feature, not a bug.
• OSPF converges fast. Sub-second with tuning, because every router already has the data it needs to recompute.
• BGP converges slowly. Tens of seconds or more in the default-free zone, because route propagation must walk the AS path and policy is evaluated at every hop.

The Side-by-Side Comparison

When OSPF is the Answer

OSPF is the right choice when:

• You control every router on every link. This is the defining condition for an IGP.
• You need fast convergence. Sub-second failover is achievable with default timers + BFD.
• You want vendor neutrality. RFC 2328 OSPFv2 is genuinely interoperable across Cisco, Juniper, Arista, Nokia, etc.
• You need hierarchical scaling. Areas let you scale to thousands of routers with bounded LSDB size and SPF run time.
• You want a metric that "just works." Cost is bandwidth-derived. Set the reference bandwidth once, and the protocol picks reasonable paths automatically.

The full OSPF picture, including LSA types, areas, and configuration, is in OSPF Complete Guide.

When BGP is the Answer

BGP is the right choice when:

• You are exchanging routes with another organization. Internet peering, IPsec VPN to a partner, multi-cloud peering. The other side does not trust your IGP and will not run one with you.
• You need to express explicit policy. "Prefer transit X for outbound except for these prefixes." OSPF cannot say that. BGP can.
• You are at internet scale. The default-free zone has more than a million prefixes; OSPF cannot carry that and would not converge if it tried.
• You need topology hiding. The other side gets to see your AS path, not your routers.
• You need to differentiate routes by source. BGP communities tag routes for downstream policy in ways that have no IGP equivalent.

And BGP shows up in places that surprise people:

• Data center underlays. Modern leaf-spine fabrics often run BGP all the way down to the leaf, often unnumbered, often with EVPN on top. Why? Because BGP carries policy better than any IGP, and you want explicit policy in a multi-tenant fabric.
• SD-WAN overlays. The control plane between vManage / vSmart / WAN edges is BGP-flavored.
• Cloud VPC peering. AWS, Azure, GCP all use BGP for VPN gateways and inter-VPC routing.

The full BGP picture, including the 13-step best-path algorithm and attribute reference, is in BGP (Border Gateway Protocol): The Complete Guide.

When You Run Both (Most of the Time)

The dominant production pattern is OSPF as the underlying IGP, BGP at the edges. Three reasons:

1. iBGP needs reachability. Internal BGP peers form TCP/179 sessions, often between loopbacks across the network. Those TCP sessions only stay up if there is a route between the loopbacks. That route comes from OSPF. Without OSPF, iBGP collapses on the first link flap that the BGP timers cannot survive.
2. BGP NEXT_HOPs must resolve. When an eBGP peer hands you a route, the NEXT_HOP attribute is the eBGP peer's IP. Your iBGP peers receive that route, but the NEXT_HOP is unchanged. They need a route to it (OSPF provides this) or the route is unusable. next-hop-self on the edge router is the alternative pattern.
3. Different jobs. Inside the AS, OSPF moves traffic fast and adapts to topology changes. At the AS edges, BGP enforces policy and exchanges routes with peers.

The architectural picture for a typical enterprise:

           ISP-A   ISP-B
              \     /
              eBGP eBGP
                \ /
            +---+---+
            | edge  |   <-- BGP, edge router holds DFZ partial table
            +---+---+
                |
              iBGP    <-- iBGP from edge to internal next-hop routers
                |
            +---+---+
            | core  |   <-- OSPF, fast intra-AS reachability
            +---+---+
              / | \
        access   distribution layers (OSPF)

OSPF carries internal prefixes (loopbacks, point-to-point links, internal user subnets). BGP carries the internet table and any inter-org routes. The two never overlap on the same prefix; redistribution between them is rare and should be done with extreme care if at all.

Convergence and Performance: The Numbers

Benchmark intuition for similar topologies:

The defaults are conservative. With BFD on every link, both protocols converge in similar timeframes for direct link failures. The big BGP cost is full-table operations: a soft-reset of an eBGP DFZ session takes minutes. OSPF has no comparable cost; an LSA refresh is small.

Redistribution Between BGP and OSPF

The temptation is to redistribute BGP into OSPF (so internal hosts can reach the internet via OSPF default routes) and OSPF into BGP (so external peers can reach your internal services). Both have failure modes:

• BGP into OSPF. Pulling 1,000,000 internet routes into your OSPF LSDB will explode it. SPF runs will pin the CPU and the network will hang. The right pattern: do not redistribute. Originate a default route in OSPF instead, pointing to the BGP-running edge.
• OSPF into BGP. Naively redistributing all OSPF routes into BGP will flood your peers with internal routes. Filter aggressively (route maps with prefix lists). Most environments only redistribute statics into BGP and use network statements to advertise specific prefixes.

For inbound from BGP, a sane pattern is "default route originate" in OSPF on the edge router. Combined with iBGP carrying the full table to the edge, internal hosts find the edge by default route, and the edge has the actual table to forward.

Design Decisions: Picking the Combination

Three real-world scenarios:

Single-site enterprise with one ISP. OSPF inside, single-homed to the ISP via static default. No BGP. The ISP has a static route back. This is fine for hundreds of single-site businesses. Add BGP only when you need the policy.

Multi-site enterprise with two ISPs. OSPF inside, BGP at every site that has internet connectivity. eBGP to each ISP, iBGP across the WAN to share inbound preferences. This is where the real BGP work begins: setting LOCAL_PREF for outbound preferences, AS-Path Prepending or MED for inbound preferences, communities for tagging.

Service provider or large enterprise data center. OSPF or IS-IS in the underlay (IS-IS is preferred at internet scale because of its layered hierarchy). iBGP with route reflectors as the overlay carrying customer routes, MPLS labels, EVPN, etc. The BGP/IGP split is even more pronounced here: BGP carries everything that needs to be policy-controlled; the IGP carries only loopbacks and link infrastructure.

Choosing the IGP: OSPF, EIGRP, or IS-IS

If you have decided on an IGP, the choice between OSPF, EIGRP, and IS-IS is its own discussion:

• OSPF. Default enterprise choice. Vendor-neutral, well-understood, certified everywhere.
• EIGRP. Faster convergence on small networks (DUAL has local re-convergence). Open since 2013 but practical adoption beyond Cisco is rare.
• IS-IS. Service-provider favorite. Two-level hierarchy (L1/L2) is cleaner than OSPF areas at very large scale, and it carries CLNS instead of IP so misconfiguration cannot blackhole production traffic. Enterprise adoption is rare but growing in modern data centers.

For most enterprises, OSPF is the safe default. For internet-scale providers, IS-IS often wins. For Cisco-only networks where convergence speed matters, EIGRP is still a valid choice.

Summary

BGP and OSPF are not alternatives. They are complementary protocols that solve different problems at different layers of a real network. OSPF gives you fast, automatic, intra-AS reachability with a metric you do not have to think about. BGP gives you policy-driven, inter-AS reachability with explicit control over every aspect of route selection.

The right answer is almost always "both": OSPF inside, BGP at the edges, with the IGP carrying internal infrastructure and BGP carrying everything that needs policy. If you are studying for a CCNP or CCIE, expect to know both cold; if you are designing a network, expect to deploy both. Bookmark the OSPF pillar and the BGP pillar for the full configuration and operational details.