Interior vs. Exterior Gateway Protocols: Where Each Fits
Every routing protocol exists to answer the same basic question — "what is the best path to this destination network?" — but the scope of "best" and "network" differs enormously depending on where the protocol runs. Routing protocols are split into two broad classes based on that scope.
An Interior Gateway Protocol (IGP) distributes routes within a single administrative domain, known as an Autonomous System (AS) — a network (or group of networks) under one organization's control, using one consistent routing policy. OSPF, IS-IS, and EIGRP are all IGPs. They are optimized for fast convergence and mathematically shortest paths, because inside your own network, the goal is simply to move traffic as efficiently as possible.
An Exterior Gateway Protocol (EGP) exchanges routes between different Autonomous Systems. BGP (Border Gateway Protocol) is, for all practical purposes, the only EGP in production use today — it is the protocol that holds the entire public internet together, and it is also used at the edge of enterprise networks to peer with ISPs, and increasingly inside large data centers and MPLS/SD-WAN backbones to carry routes between sites. BGP does not aim for the shortest path; it is a policy-routing protocol that lets each AS decide, route by route, which path it prefers based on business relationships, traffic engineering, and administrative preference. This distinction — fast, shortest-path IGPs on the inside, policy-driven BGP on the boundaries — is the organizing idea behind almost every enterprise routing design, and it is exactly the layer that sits underneath the OSPF/IS-IS/BGP/MPLS/EVPN modeling in a network simulator: the simulator lets you build the topology, but OSPF and BGP are the actual decision-making logic running on top of it.
OSPF Fundamentals: Link-State Routing and Areas
OSPF (Open Shortest Path First) is a link-state routing protocol, and understanding that term is the key to understanding everything else about it. Rather than trusting a neighbor's summarized opinion of "how far away" a network is (as older distance-vector protocols like RIP do), every OSPF router builds a complete, identical map of the entire area's topology — every router, every link, every link's cost — called the link-state database (LSDB). Routers exchange small pieces of topology information called Link-State Advertisements (LSAs) and flood them, unchanged, to every other router in the area, so that eventually all routers converge on exactly the same LSDB. Each router then independently runs Dijkstra's Shortest Path First (SPF) algorithm against its own copy of that database to compute the lowest-cost path to every known destination, with itself as the root of the resulting tree. Because every router computes its own view from complete information rather than depending on a neighbor's summarized route, link-state protocols avoid the slow convergence and loop-prone behavior that plagued older distance-vector designs, and they scale to much larger, more complex topologies.
Areas and the Backbone
Flooding a full topology map to every router works well up to a point, but in a large network it means every router pays the CPU cost of a full SPF recalculation for every change, anywhere. OSPF solves this with areas: a group of contiguously connected routers and links, identified by a 32-bit area number (commonly written in dotted-decimal or plain integer form, e.g., Area 0, Area 1, Area 10.10.10.0). Routers inside an area maintain a full, detailed LSDB only for that area; reachability to networks in other areas is carried as compact, pre-summarized routes rather than raw topology detail.
Every OSPF domain must have exactly one backbone area, Area 0, and every other (non-backbone) area must connect directly to it through a router that sits on the boundary between the two — an Area Border Router (ABR). This hub-and-spoke arrangement, with the backbone as the mandatory transit hub, is what lets OSPF avoid running a full loop-prevention algorithm between areas: routes only ever flow area-to-backbone-to-area, never area-to-area directly (unless a virtual link is configured to patch a discontiguous backbone, which is a workaround rather than a design goal). A router that sits entirely within Area 0 is just a normal backbone router; a router that originates routes from outside OSPF entirely — from BGP or a static route, for example — is called an Autonomous System Boundary Router (ASBR).
The OSPF Cost Metric, and Forming Adjacencies
OSPF's metric is called cost, and unlike a hop count, it is bandwidth-derived and cumulative along the path. On Cisco platforms, the default formula for each interface's cost is:
| Formula element | Value |
|---|---|
| Reference bandwidth (default) | 100,000,000 bps (100 Mbps) |
| Interface cost formula | cost = reference bandwidth ÷ interface bandwidth |
| Minimum cost | 1 (result is rounded and floored at 1, never 0) |
Working the formula for common links: a 100 Mbps Fast Ethernet interface costs 100,000,000 ÷ 100,000,000 = 1. A 10 Mbps Ethernet link costs 10. A 1.544 Mbps T1 serial link costs roughly 64. A router adds up the cost of every outgoing interface along a path to reach a destination, and the path with the lowest total cost wins in the SPF tree. The catch with the default reference bandwidth is that anything at or above 100 Mbps — a 1 Gbps link, a 10 Gbps link, a 100 Gbps link — all compute to the same minimum cost of 1, so OSPF cannot tell a Gigabit uplink apart from a 100-Gigabit backbone trunk without help. In any modern network with mixed link speeds above 100 Mbps, engineers raise the reference bandwidth (the auto-cost reference-bandwidth command) to a much larger number so that faster links compute meaningfully lower costs and get correctly preferred.
Designated Router and Backup Designated Router Election
On a point-to-point link, only two routers can ever be neighbors, so there's nothing to elect. But on a multi-access segment — a shared broadcast Ethernet VLAN or an NBMA (non-broadcast multi-access) network — a naive full mesh of adjacencies between every pair of routers would flood the same LSAs redundantly across the segment. OSPF avoids this by electing a Designated Router (DR) and a Backup Designated Router (BDR) for each multi-access segment. Every other router forms a full adjacency only with the DR and BDR, not with each other (they remain in a lighter "2-way" state with one another, called DROTHER). The DR is responsible for originating the Type 2 Network LSA describing that segment and for relaying updates, cutting the number of adjacencies from n(n-1)/2 down to roughly 2n.
Election is based on OSPF interface priority (a configurable value from 0–255; default is usually 1). The router with the highest priority on the segment becomes DR, the second-highest becomes BDR; a priority of 0 means a router can never become DR or BDR. If priorities tie, the highest OSPF Router ID (a 32-bit, dotted-decimal identifier, typically the highest loopback or interface IP unless manually set) breaks the tie. Critically, DR election is not preemptive — once a DR is elected and stable, a router with a higher priority joining later does not trigger a re-election; it only takes effect if the current DR and BDR both go down and an election has to happen again.
OSPF LSA Types and Convergence Behavior
LSAs are the actual data OSPF floods to build the LSDB, and different LSA types describe different scopes of the topology:
- Type 1 (Router LSA): Originated by every router, describing its own links, their state, and their cost. Flooded only within its own area.
- Type 2 (Network LSA): Originated by the DR on a multi-access segment, listing all routers attached to that segment. Also confined to its own area.
- Type 3 (Summary LSA): Originated by an ABR, advertising a route to a network in one area into another area, as a single summarized cost — this is what keeps inter-area topology detail hidden while still allowing reachability.
- Type 4 (ASBR Summary LSA): Originated by an ABR, advertising the location (route to) an ASBR, so that routers in other areas know how to reach the router that is redistributing external routes.
- Type 5 (AS External LSA): Originated by an ASBR, describing routes redistributed into OSPF from an external source (a different routing protocol, static routes, or BGP). Flooded through the entire domain by default, except into stub-type areas designed to filter them out.
Because every router in an area holds the identical LSDB, convergence after a topology change is fast and largely independent per router: a link failure triggers a new or updated LSA, that LSA floods to all routers in the affected area (and, if relevant, as a summarized update to other areas), and every router that received the update reruns SPF against its refreshed LSDB. On modern hardware with tuned timers, this typically completes in well under a second on a stable network, though default timer settings (10-second Hello / 40-second Dead timer on broadcast links) mean full detection-to-reconvergence can take several seconds if timers aren't tuned down and fast failure-detection mechanisms (like BFD) aren't in use.
Worked Example: A Route Crossing Three OSPF Areas
Consider a network with Area 1, the backbone Area 0, and Area 2, connected by two ABRs: R2 (between Area 1 and Area 0) and R3 (between Area 0 and Area 2).
- Step 1: Router R1, inside Area 1, owns the LAN 10.1.1.0/24 on a Gigabit interface. It originates a Type 1 Router LSA describing that link with cost 1, flooded to every router in Area 1, including ABR R2. Say the path from R1 to R2 within Area 1 has an accumulated cost of 1 (R1's LAN) + 1 (a Gig link from R1 to R2) = 2.
- Step 2: R2 runs SPF within Area 1, determines the best cost to 10.1.1.0/24 is 2, and — because it's an ABR — originates a Type 3 Summary LSA advertising "10.1.1.0/24, cost 2" into Area 0. Note the original Type 1/Type 2 topology detail from Area 1 is not sent into Area 0; only this single summarized cost value crosses the boundary.
- Step 3: ABR R3 sits in both Area 0 and Area 2. It receives R2's Type 3 LSA in Area 0's LSDB and computes its own cost from itself to R2 across the backbone — say that's a 10 Gbps link with cost 1. R3 adds that to the cost already carried in the LSA: 2 (from R2's LSA) + 1 (R3-to-R2 within Area 0) = 3.
- Step 4: R3, now acting as ABR for Area 2, originates its own Type 3 Summary LSA into Area 2, advertising "10.1.1.0/24, cost 3."
- Step 5: Router R4, sitting inside Area 2 with a cost-1 link to R3, receives that Type 3 LSA and adds its own local cost to reach R3: 3 (from R3's LSA) + 1 (R4-to-R3 within Area 2) = total cost 4 to reach 10.1.1.0/24.
This chain illustrates the core inter-area rule: each ABR re-originates a fresh summary LSA carrying the accumulated cost up to itself, and the next area's routers simply add their own local cost to reach that ABR. No router outside Area 1 ever sees R1's actual link-state detail — only the progressively re-summarized cost.
BGP Fundamentals: Path-Vector Routing and Autonomous Systems
BGP is classified as a path-vector protocol. Like a distance-vector protocol, each BGP speaker learns routes from its neighbors rather than building a full topology map — but instead of just a metric, every route carries an explicit list of every AS it has traversed, the AS-path. This list is BGP's built-in loop prevention: if a router ever receives a route whose AS-path already contains its own AS number, it rejects that route outright, because accepting it would create a routing loop. BGP runs over TCP port 179, meaning BGP sessions rely on TCP for reliable, ordered delivery rather than implementing their own retransmission logic — a deliberate design choice that simplifies the protocol at the cost of a slightly higher session-setup overhead than lighter IGP hellos.
Every BGP-speaking network identifies itself with an Autonomous System Number (ASN). Classic (2-byte) ASNs range from 1 to 65,535, with 64,512–65,534 reserved for private use (not globally routed). Because the internet has consumed most of the original 2-byte space, RFC 6793 extended BGP to support 4-byte ASNs, with a vastly larger public range and a private range of 4,200,000,000–4,294,967,294. In practice, enterprises typically use a private ASN for their own network when peering with ISPs (unless they've been allocated a public one), while every ISP and major cloud/content network uses a globally unique, publicly registered ASN.
iBGP vs. eBGP
BGP sessions come in two flavors depending on whether the two peers are in the same AS or different ones. eBGP (external BGP) is a session between routers in two different Autonomous Systems — this is the classic "peering" or "transit" relationship between an enterprise and its ISP, or between two ISPs. eBGP peers are normally directly connected (though multihop eBGP is possible with configuration), and each eBGP hop always prepends its own AS number onto the AS-path, which is exactly the mechanism that lets loop detection and best-path length comparisons work.
iBGP (internal BGP) is a session between two routers inside the same AS — used to carry externally-learned BGP routes across an organization's own internal network so that every edge router has a consistent view of external reachability. Because an iBGP session doesn't cross an AS boundary, the AS-path doesn't grow, which means iBGP has no built-in loop-prevention analogous to eBGP's AS-path check. BGP compensates with a strict rule: a router must never re-advertise a route learned from one iBGP peer to another iBGP peer. Only eBGP-learned or locally originated routes get forwarded to iBGP neighbors. The direct consequence is that, taken literally, this rule requires a full mesh of iBGP sessions between every router in the AS that needs external routes — which is why large networks instead deploy route reflectors (a designated router explicitly permitted to reflect iBGP routes to its clients) or confederations (splitting one AS into several sub-ASes) to avoid an unmanageable full mesh.
The BGP Best-Path Selection Process
Unlike an IGP's single-metric comparison, BGP evaluates a sequence of attributes in strict order and stops at the first tiebreaker that produces a winner. The most commonly taught order, from first to last:
| Order | Attribute | Preference rule |
|---|---|---|
| 1 | Weight | Highest wins (Cisco-proprietary, local to the router only, never advertised to peers) |
| 2 | Local Preference | Highest wins (AS-wide value, carried between iBGP peers) |
| 3 | AS-path length | Shortest wins (fewer AS hops in the path) |
| 4 | Origin code | IGP beats EGP beats Incomplete |
| 5 | MED (Multi-Exit Discriminator) | Lowest wins (compared only between paths from the same neighboring AS) |
| 6 | eBGP vs. iBGP | eBGP-learned path preferred over an otherwise-equal iBGP-learned path |
| 7 | Oldest route | The longest-established (most stable) eBGP path is preferred, to reduce unnecessary route churn |
| 8 | Lowest router ID | Final tiebreaker among otherwise-identical paths |
Weight and Local Preference are both ways of expressing "prefer this path" within your own administrative control — Weight is set per-router and never leaves it, while Local Preference is set once and shared across the whole AS via iBGP, making it the standard tool for AS-wide outbound traffic engineering (for example, preferring one ISP over another for all outbound traffic). AS-path length is the closest thing BGP has to a "shortest path" concept, but it counts AS hops, not physical distance or bandwidth — a 2-AS path can easily be physically shorter or longer than a 3-AS path. MED is essentially the inverse of local preference: it's a hint one AS gives to a neighboring AS about which of several entry points it would prefer inbound traffic to use, but it is only compared between routes learned from that same neighboring AS, and many networks ignore it if untrusted.
Worked Example: A BGP Best-Path Decision
Suppose a router in AS 65001 learns two eBGP paths to the same prefix, 203.0.113.0/24:
| Path | Neighbor AS | AS-path | Local Pref | MED |
|---|---|---|---|---|
| Path A | AS 65002 | 65002 65010 | 100 (default) | 20 |
| Path B | AS 65003 | 65003 | 100 (default) | 50 |
Walking the algorithm: neither path has Weight set, so step 1 is a tie. Local Preference is the default 100 on both, so step 2 is also a tie. Step 3 — AS-path length — is where this resolves: Path A's AS-path is two hops (65002, 65010), while Path B's is a single hop (65003). Path B is shorter, so Path B wins outright at step 3, and the router never even reaches the MED comparison at step 5. This is a common point of confusion for engineers newer to BGP: Path A actually has the lower (more attractive) MED value of 20 versus Path B's 50, but MED is evaluated far later in the algorithm and never gets a chance to matter here, because a decisive result was already reached at the AS-path length step. This is exactly why the order of the best-path algorithm — not just the individual attribute values — determines the outcome, and why engineers troubleshooting an "unexpected" route choice should always check Weight, Local Preference, and AS-path length before assuming a MED or origin-code issue.
OSPF vs. BGP at a Glance
| Characteristic | OSPF | BGP |
|---|---|---|
| Protocol class | IGP — link-state | EGP — path-vector |
| Primary use case | Routing within one organization's network | Routing between Autonomous Systems (internet, WAN, multi-site) |
| Metric / decision basis | Cumulative cost (bandwidth-derived), via Dijkstra SPF | Ordered policy attributes (Weight, Local Pref, AS-path, MED, etc.), not pure shortest path |
| Transport | IP protocol 89, multicast hello (224.0.0.5 / 224.0.0.6) | TCP port 179 |
| Convergence speed | Fast — typically sub-second to a few seconds, event-driven | Slower and more conservative — seconds to minutes, damped deliberately for internet-scale stability |
| Typical scale | Hundreds to low thousands of routes per area | Millions of prefixes (a full internet table is well over 900,000 IPv4 prefixes) |
The two protocols are not competitors — they are complementary layers. A well-designed enterprise network runs OSPF (or another IGP) internally for fast, efficient routing between its own routers, and hands off to BGP at every boundary where routing decisions become a matter of policy rather than pure topology: the ISP edge, MPLS or SD-WAN attachment points, and increasingly the leaf-spine fabric of large data centers, where BGP's stability and explicit policy control are valued even inside a single administrative domain. Understanding both — and specifically the order-of-operations logic in OSPF's area-based summarization and BGP's best-path algorithm — is foundational to reading, and correctly predicting, the behavior of any topology built in an OSPF/IS-IS/BGP/MPLS/EVPN network simulator.