OSPF vs BGP: When to Use Each (with a Lab to Prove It)

BGP vs OSPF in one sentence: OSPF is an interior gateway protocol (IGP) that uses link-state and Dijkstra's SPF algorithm to find the fastest path inside a single network, while BGP is an exterior gateway protocol (EGP) that uses path-vector logic and rich policy attributes to route between autonomous systems (and, increasingly, inside the data-center fabric). In practice you rarely pick one or the other — most production networks run OSPF as the IGP for reachability and BGP on top for policy, scale, and external peering.

That's the answer. The rest of this guide gives you the five-axis decision matrix the SERP keeps repeating, a clear "when to use which" table by use case, a quick touch on the adjacent ospf vs eigrp and is-is vs ospf questions — and then something none of the other explainers ship: a deployable, multi-vendor lab so you can run OSPF and BGP side by side and watch the difference yourself in about 2 minutes.

Bottom line: OSPF and BGP solve different problems and are usually used together, not either/or. To stop reading definitions and actually see SPF convergence vs BGP path selection, NetPilot deploys a mixed OSPF-backbone + BGP-between-two-ASes lab on a multi-vendor cloud emulator from a plain-English prompt — no GNS3 or EVE-NG install, no images to source.

Quick Comparison: BGP vs OSPF

The headline takeaway: OSPF gets packets moving fast inside one network; BGP gives you control and reach across many. Now let's unpack the five axes that AI engines and ranking pages consistently cite.

The Five-Axis Split

1. IGP vs EGP (interior vs exterior)

This is the root difference and the one that answers igp vs egp. OSPF is an IGP: it runs within a single autonomous system (AS) — your enterprise, your campus, your data center — to learn every internal prefix. BGP is an EGP: it was built to route between autonomous systems, which is how independent networks exchange reachability to form the internet. An AS is a network under one administrative/routing policy, identified by an AS number (ASN).

2. Link-state SPF vs path-vector policy

OSPF floods link-state advertisements (LSAs) so every router builds an identical map of the topology, then each runs Dijkstra's SPF to compute the lowest-cost path. The metric is derived from interface bandwidth — it's about speed, automatically.

BGP doesn't care about your link speeds. It's a path-vector protocol that selects a best path by walking an ordered list of attributes (weight, local-preference, AS-path length, origin, MED, eBGP-over-iBGP, and so on). That makes BGP about policy: you decide which path wins, even if it isn't the physically shortest one. This is what ospf vs bgp route selection is really asking — SPF math vs attribute-based decision.

3. Convergence

OSPF converges fast. A topology change floods, every router re-runs SPF, and (with tuned timers / BFD) reconvergence is sub-second. BGP converges deliberately — timers, path-hunting, and policy re-evaluation make it slower and more damping-prone on purpose, because a stable internet matters more than a fast one. So bgp convergence time vs ospf: OSPF wins on raw speed; BGP trades speed for stability and policy control.

4. Config complexity

OSPF is relatively simple — enable the process, put interfaces in areas, done. BGP is more involved: you define explicit peers, agree on ASNs, and usually write route-maps/policy to shape what's advertised and accepted. More power, more rope.

5. Scaling model

OSPF scales by hierarchy — you carve the network into areas around a backbone (area 0) to bound LSA flooding and SPF cost. BGP scales flat: a single BGP table can hold the full internet routing table (north of 950,000 IPv4 routes as of 2026) without an area design. That different scaling philosophy is exactly why the two protocols pair so well.

The Modern Twist: BGP Is Now a Data-Center Protocol

The classic teaching — "OSPF inside, BGP only at the edge" — is out of date. Modern leaf-spine (Clos) data-center fabrics increasingly run BGP as the fabric IGP, often with an AS-per-leaf design and VXLAN/EVPN for overlay. Why use an EGP internally? Because BGP's explicit peering, policy hooks, and flat scaling fit a fabric with hundreds of switches better than flooding-based OSPF areas, and EVPN rides natively on BGP. You'll also see BGP underpinning SD-WAN overlays and multi-cloud interconnects.

So the honest framing for when to use bgp in 2026 is: at the internet edge and as the underlay/overlay control plane of the data center. OSPF still owns a huge amount of enterprise and campus reachability, and frequently provides the loopback reachability that iBGP peers depend on.

When to Use Each: Decision Table

Rule of thumb: If the routing decision is "what's the fastest internal path?" reach for OSPF. If it's "which neighbor/network should this traffic prefer, and what do I advertise to whom?" reach for BGP. Big networks need both.

Adjacent Questions, Briefly

OSPF vs EIGRP. EIGRP is Cisco's advanced distance-vector IGP (DUAL algorithm), historically Cisco-proprietary (an informational RFC exists, but multi-vendor support is thin). OSPF is the open, standards-based link-state IGP that runs on every vendor. For ospf vs eigrp: pick OSPF for multi-vendor environments and standards compliance; EIGRP can be simpler and fast-converging in an all-Cisco shop. In the three-way bgp vs ospf vs eigrp framing, OSPF and EIGRP are both IGPs competing for the inside, while BGP plays a different (inter-AS/policy) role entirely.

IS-IS vs OSPF. IS-IS is the other open link-state IGP — same SPF math, different packaging (it runs directly over the link layer via CLNS, not IP). For is-is vs ospf: IS-IS is favored in large service-provider cores for its flatter, extensible level-1/level-2 hierarchy; OSPF dominates enterprise for familiarity and tooling. Functionally they're close cousins; the choice is usually about operational preference and scale.

Prove It: A Lab That Runs Both

Reading the difference is fine. Seeing SPF reconverge in milliseconds while BGP deliberately re-selects a path is what makes it stick. Here's a small topology that does exactly that: an OSPF backbone for internal reachability, plus eBGP between two autonomous systems on top.

        AS 65001                       AS 65002
┌──────────────────────────┐   ┌──────────────────────────┐
│   R1 ───OSPF──── R2 ──────┼───┼──── R3 ───OSPF──── R4    │
│  (FRR)          (FRR)     │eBGP│   (FRR)          (FRR)   │
│ Lo:10.1.1.1   Lo:10.1.1.2 │   │ Lo:10.2.2.3   Lo:10.2.2.4 │
└──────────────────────────┘   └──────────────────────────┘
  OSPF area 0 inside AS 65001     OSPF area 0 inside AS 65002
                R2 10.0.23.2 ── 10.0.23.3 R3  (eBGP link)

• AS 65001: R1 and R2 run OSPF area 0; R2 is the AS border router.
• AS 65002: R3 and R4 run OSPF area 0; R3 is the AS border router.
• R2 ↔ R3: eBGP peering. Each AS advertises its internal loopback subnet to the other.

We use FRR (built-in, no images to source) so every config below is copy-paste-runnable. The same lab works across Cisco IOL (BYOI), Juniper cRPD (BYOI), and Arista cEOS (BYOI) when you want true multi-vendor — the agent handles the per-vendor translation.

R1 — FRR (AS 65001, OSPF only)

interface lo
 ip address 10.1.1.1/32
!
interface eth1
 ip address 10.0.12.1/24
!
router ospf
 ospf router-id 10.1.1.1
 network 10.0.12.0/24 area 0
 network 10.1.1.1/32 area 0

R2 — FRR (AS 65001 border: OSPF + eBGP)

interface lo
 ip address 10.1.1.2/32
!
interface eth1
 ip address 10.0.12.2/24
!
interface eth2
 ip address 10.0.23.2/24
!
router ospf
 ospf router-id 10.1.1.2
 network 10.0.12.0/24 area 0
 network 10.1.1.2/32 area 0
 redistribute bgp route-map BGP-TO-OSPF
!
router bgp 65001
 bgp router-id 10.1.1.2
 neighbor 10.0.23.3 remote-as 65002
 !
 address-family ipv4 unicast
  network 10.1.1.2/32
  redistribute ospf
 exit-address-family
!
ip prefix-list AS65002-LOOPBACKS seq 5 permit 10.2.2.0/24 le 32
!
route-map BGP-TO-OSPF permit 10
 match ip address prefix-list AS65002-LOOPBACKS

There's a subtlety worth calling out: redistribute ospf only carries routes R2 learned via OSPF, so it picks up 10.1.1.1/32 (R1's loopback) but not R2's own 10.1.1.2/32 — that's a connected route on R2, not an OSPF route. To originate the border router's own loopback we add an explicit network 10.1.1.2/32 under router bgp; the connected /32 is an exact match in the RIB, so BGP originates it. Between the two, all of AS 65001's loopbacks (10.1.1.1/32 via redistribute ospf, 10.1.1.2/32 via the network statement) are advertised to AS 65002 as their real /32 host routes. (We dropped the old network 10.1.1.0/24 — the loopbacks are /32s, so there is no exact 10.1.1.0/24 route in the RIB for it to match, and it would originate nothing.) In the other direction, redistribute bgp under OSPF injects the eBGP-learned AS-65002 loopbacks (scoped by the route-map to 10.2.2.0/24 prefixes only) back into the local OSPF domain — that's what gives R1 a route to R4's loopback.

R3 — FRR (AS 65002 border: OSPF + eBGP)

interface lo
 ip address 10.2.2.3/32
!
interface eth1
 ip address 10.0.34.3/24
!
interface eth2
 ip address 10.0.23.3/24
!
router ospf
 ospf router-id 10.2.2.3
 network 10.0.34.0/24 area 0
 network 10.2.2.3/32 area 0
 redistribute bgp route-map BGP-TO-OSPF
!
router bgp 65002
 bgp router-id 10.2.2.3
 neighbor 10.0.23.2 remote-as 65001
 !
 address-family ipv4 unicast
  network 10.2.2.3/32
  redistribute ospf
 exit-address-family
!
ip prefix-list AS65001-LOOPBACKS seq 5 permit 10.1.1.0/24 le 32
!
route-map BGP-TO-OSPF permit 10
 match ip address prefix-list AS65001-LOOPBACKS

R3 mirrors R2: redistribute ospf originates 10.2.2.4/32 (R4's loopback, learned via OSPF), and the explicit network 10.2.2.3/32 originates R3's own connected loopback — together advertising both AS-65002 loopbacks into BGP toward AS 65001. In the other direction, redistribute bgp (route-map–scoped to 10.1.1.0/24 prefixes) injects the eBGP-learned AS-65001 loopbacks back into OSPF so R4 gets a route to R1's loopback.

R4 — FRR (AS 65002, OSPF only)

interface lo
 ip address 10.2.2.4/32
!
interface eth1
 ip address 10.0.34.4/24
!
router ospf
 ospf router-id 10.2.2.4
 network 10.0.34.0/24 area 0
 network 10.2.2.4/32 area 0

With this running, R1 (deep inside AS 65001) reaches R4's loopback (deep inside AS 65002) only because OSPF carries the prefix to each border router and BGP carries it across the AS boundary. That's the "used together" pattern made concrete.

Verify It — Agent-First, CLI Always Available

Ask the agent: "Across all four FRR routers, show me OSPF neighbors, the OSPF route table, and the BGP summary on R2 and R3. Flag any neighbor that isn't Full or Established."

The agent translates that intent into the right command per device, runs it across all four routers in parallel, and returns one consolidated table with anomalies flagged. In a mixed-vendor version of this lab it handles the syntax differences for you — show ip bgp summary on Cisco/Arista vs show bgp summary on Juniper vs FRR's vtysh-wrapped variant — from the same plain-English prompt.

Direct CLI is always available too. SSH into any router, drop into vtysh, and verify by hand:

vtysh -c "show ip ospf neighbor"
vtysh -c "show ip route ospf"
vtysh -c "show ip bgp summary"
vtysh -c "show ip bgp"

Want to see the difference the table describes? This is a minimal four-router chain with no redundant paths, so don't shut a router's only link — that just isolates it, it doesn't reconverge. Instead, change a metric and watch how each protocol reacts to the change:

Ask the agent: "On R2, raise the OSPF cost on eth1 (toward R1) to 500 and capture how fast OSPF re-floods the LSA and re-runs SPF in AS 65001. Then on R3, change the loopback advertisement — re-originate 10.2.2.3/32 with a longer AS-path prepend — and capture how BGP processes that path-vector update on R2. Report the timing and behavior of each."

You'll watch OSPF react immediately — R2 floods an updated router-LSA and every router in AS 65001 re-runs Dijkstra SPF in milliseconds to pick up the new cost — while BGP processes R3's re-advertised path deliberately, walking its best-path attribute list rather than recomputing a topology graph. Neither change isolates a router: R1 stays reachable the whole time (the cost change just makes the link more expensive, not gone), and R3's loopback stays reachable (the prepend changes the path attributes, not the prefix's existence) — so you observe the convergence behavior the table describes, not routes disappearing. To inspect administrative distance directly (ospf vs bgp administrative distance), run show ip route 10.2.2.4 on R1 and note the [110/...] for OSPF vs [20/0] you'd see for an eBGP-learned route — the lower distance wins when both protocols offer the same prefix.

Why Run This on NetPilot

Every other bgp vs ospf explainer ends with "go set up GNS3 / EVE-NG / Packet Tracer and try it." That's hours of installation and image sourcing before you type a single command. NetPilot is the agent-first, multi-vendor AI-native network emulator (cloud + on-prem) that closes that gap: describe the lab in plain English, the agent translates per vendor, deploys every device in parallel, and reports back — with full CLI access to inspect the RIB, BGP table, and admin distance yourself whenever you want.

"Build a two-AS lab: OSPF area 0 inside each AS on FRR, and eBGP between the two border routers. Advertise each AS's loopback block across the boundary so the far-end routers are reachable. Then verify OSPF neighbors and BGP peering on every device."

Paste that into NetPilot and you have the lab above running in about 2 minutes. Spin it up on the online network lab, then swap FRR for Cisco IOL (BYOI), Juniper cRPD (BYOI), or Arista cEOS (BYOI) to practice the real multi-vendor route-selection and convergence differences.

FAQ

Is BGP better than OSPF?

Neither is "better" — they solve different problems. OSPF is a fast, simple IGP for routing inside one network; BGP is a policy-driven EGP for routing between networks and scaling data-center fabrics. Most production networks run both: OSPF (or another IGP) for internal reachability, BGP for external peering and policy.

What is the administrative distance of OSPF vs BGP?

On Cisco, OSPF is 110, external BGP (eBGP) is 20, and internal BGP (iBGP) is 200. Lower wins, so an eBGP route (20) beats an OSPF route (110) for the same prefix, while an OSPF route beats an iBGP route (200). Administrative distance is how a router chooses when two protocols offer the same destination.

Can OSPF and BGP run together?

Yes — that's the normal design. OSPF (or IS-IS/EIGRP) provides internal/loopback reachability, and BGP rides on top for inter-AS routing and policy. iBGP peers commonly use loopbacks reachable via OSPF, and border routers redistribute or originate prefixes between the two, exactly as the lab above shows.

OSPF vs EIGRP — which should I use?

Use OSPF for multi-vendor or standards-based networks; it runs on every vendor and uses link-state/SPF. EIGRP is Cisco's distance-vector IGP (DUAL) and can be simpler with fast convergence in an all-Cisco environment, but multi-vendor support is limited. For most modern, mixed-vendor networks, OSPF is the safer default.

IS-IS vs OSPF — what's the difference?

Both are open link-state IGPs using SPF. IS-IS runs directly over the link layer (CLNS) and is common in large service-provider cores for its flat, extensible hierarchy; OSPF runs over IP and dominates enterprise networks. They're functionally close — the choice is mostly operational preference and scale.

When should I use BGP instead of OSPF?

Use BGP when you connect to other autonomous systems (an ISP, a peer, the internet), when you need policy control over path selection or what you advertise, when you multihome, or when you build a leaf-spine data-center fabric with EVPN. Use OSPF for fast internal reachability inside a single network.

Keep Building

• BGP Peering Lab: Cisco + Juniper + Arista in One Topology — multi-vendor eBGP with real per-vendor configs
• OSPF Multi-Vendor Lab — areas, ABRs, and interoperability gotchas
• FRR Cloud Lab Guide — the free, built-in routing stack used in this lab

Copy-paste ready: Grab the OSPF + BGP redistribution prompt from our example library — the two-protocol lab from this post, ready to run.

Stop reading, start running. Try NetPilot to deploy this OSPF + BGP lab in ~2 minutes, or explore the online network lab and the AI-native network emulator.