Why the internet needs a different protocol than internal networks
Protocols like OSPF or RIP are IGPs (Interior Gateway Protocols) — designed for routing inside a single organization, where every router trusts one shared authority. The internet, however, is a network of tens of thousands of independent organizations — internet service providers, companies, universities — each managing its own network, with none of them inherently trusting the others. Connecting such mutually distrustful networks is the job of a different category of protocol, EGP (Exterior Gateway Protocol), and the only practically used representative of that category today is BGP (Border Gateway Protocol, currently at version BGP-4, defined in RFC 4271).
Autonomous systems: the internet's basic unit
Every network that independently decides its own routing policy is assigned a unique number — an ASN (Autonomous System Number) — and is called an autonomous system (AS). It could be a major internet service provider, a cloud giant, a university, or a company with its own connections to multiple providers. BGP is the protocol these autonomous systems use to tell each other which networks (prefixes) they own, and through which other ASes those networks can be reached.
Path-vector: a third way of routing
BGP belongs to neither the distance-vector protocols (like RIP) nor the link-state protocols (like OSPF) — it uses a third approach, path-vector. Instead of a hop-count distance or a link cost, BGP remembers, for every prefix, the entire sequence of autonomous systems that must be crossed to reach it — an attribute called AS_PATH.
This seemingly minor difference has a major consequence: because a router can see the entire path of AS numbers, it can trivially detect and reject a loop — it just has to check whether its own AS number already appears in the path. Without this property, preventing routing loops between independent, mutually distrustful networks would be far more complicated.
eBGP vs iBGP
BGP distinguishes between two types of adjacencies (peerings):
- eBGP (external BGP) — between routers in different autonomous systems, typically directly physically connected. Routes received via eBGP are automatically forwarded on to every other neighbor.
- iBGP (internal BGP) — between routers within the same autonomous system, which can also be multiple routers far apart from each other. To prevent loops within a single AS (where the AS_PATH check doesn't help, since the AS number never changes), a route received via iBGP must not be automatically forwarded to another iBGP neighbor — which is why a full mesh is required between all iBGP routers in an AS. In practice, large networks work around this requirement using route reflectors or confederations, which bypass it without losing correctness.
BGP messages and establishing a session
BGP neighbors communicate over a reliable TCP connection on port 179 — unlike OSPF or RIP, BGP therefore doesn't need to handle its own delivery reliability; it relies on TCP. Four types of messages are used:
- OPEN — the first message when establishing a session, containing the ASN, BGP version, and other parameters.
- UPDATE — the core of the protocol; announces newly reachable prefixes (with their attributes), or conversely withdraws previously announced prefixes.
- KEEPALIVE — sent periodically to keep the session alive (BGP has no Hello mechanism of its own like OSPF; it relies on these periodic messages instead).
- NOTIFICATION — reports an error and terminates the session.
BGP attributes: what makes routes different
Besides AS_PATH, every route carries a number of other attributes that influence which route ultimately gets chosen as the best one:
| Attribute | Description |
|---|---|
| AS_PATH | The sequence of AS numbers along the path to the prefix; a shorter path is generally preferred |
| NEXT_HOP | The IP address traffic to that prefix should be sent to |
| LOCAL_PREF | A local preference set within your own AS; the higher value wins; not shared outside the AS |
| MED (Multi-Exit Discriminator) | A recommendation to a neighboring AS about which of several entry points to prefer; the lower value wins |
| ORIGIN | How the prefix was originally introduced into BGP (IGP, EGP, or incomplete) |
| COMMUNITY | An optional "tag" on a prefix that lets you apply policies in bulk (e.g. "don't advertise this to customers") |
| WEIGHT | A vendor-specific extension, purely local to that router, with the highest priority in the decision process |
The decision process: how BGP picks the "best" route
If a router knows multiple paths to the same prefix (typically from different neighbors), it has to pick exactly one to install in its routing table and advertise onward. BGP uses a precisely defined, multi-step decision process for this — attributes are compared in a fixed order, moving to the next criterion only when the previous one failed to produce a clear winner:
- Highest Weight (if supported and set)
- Highest Local Preference
- A route originated/injected locally on that router
- Shortest AS_PATH
- Lowest (best) Origin code
- Lowest MED value (generally only compared between routes from the same neighbor)
- Preference for eBGP routes over iBGP
- Lowest IGP metric to the next-hop address
- Oldest (longest-stable) eBGP route
- Lowest Router ID as the final tiebreaker
The exact order and availability of some steps can vary slightly by vendor, but the principle of working through a hierarchy of criteria in sequence is universal across implementations.
The global routing table: enormous, and still growing
The BGP table visible from the perspective of a large internet service provider today contains more than a million prefixes, and that number keeps growing as new networks appear and larger address blocks get split into smaller, more specifically announced ranges. This size places real demands on the memory and processing power of routers at the core of the internet, and it's one reason why BGP-speaking equipment is some of the most powerful (and most expensive) networking hardware there is.
BGP hijacking: when a protocol built on trust fails
BGP was designed at a time when the number of connected networks could be counted in the dozens, and mutual trust between operators was a given. As a result, the protocol doesn't verify by default whether the AS announcing a given prefix is actually its legitimate owner. This property is the source of one of the most serious types of attacks on internet infrastructure — BGP hijacking.
In practice, BGP hijacking has ranged from unintentional configuration mistakes (an operator accidentally forwarding on someone else's prefix) to targeted attacks in which traffic to legitimate services was temporarily rerouted through an attacker's network — with the potential for eavesdropping, tampering, or simply a total outage of the target service's availability. Since BGP routes traffic between networks all over the world, the consequences of such an incident can be visible to millions of users at once.
RPKI (Resource Public Key Infrastructure) lets a prefix owner cryptographically sign a record (a ROA — Route Origin Authorization) confirming which AS is authorized to announce a given prefix. Routers with RPKI validation enabled can then automatically reject invalid announcements before they ever affect the decision process. On top of that, strict prefix filtering is used at network boundaries (especially toward customers), and cryptographic protection of the entire AS_PATH (BGPsec) is gradually being adopted — though rolling out these protections across the entire internet remains an ongoing, long-term process.
Summary
BGP is the protocol that quite literally holds the internet together — without it, tens of thousands of independent networks would have no shared language for telling each other how to reach one another. Its path-vector principle elegantly solves the problem of routing loops between mutually distrustful networks via an explicit AS_PATH, and its rich set of attributes (Local Preference, MED, Community) gives operators fine-grained control over where their traffic flows. That same flexibility, built on the original trust between networks, is also the source of the protocol's greatest weakness — and modern solutions like RPKI exist precisely to close that gap left over from the 1980s.