📡 BGP Routing: How Autonomous Systems Agree on a Path Across the Internet

The Coordination Problem BGP Solves

Picture roughly 70,000 independently-owned networks — ISPs, cloud providers, universities, enterprises, content delivery networks — each with its own equipment, its own business interests, and zero obligation to trust any of the others. Somehow, traffic from a home in São Paulo reaches a server in Singapore, correctly, most of the time, in milliseconds. BGP (Border Gateway Protocol) is the entire mechanism making that possible: a shared language networks use to tell each other what they can reach, combined with a decision process each network runs independently to pick which of several possible paths it prefers. No central controller decides this. Every network makes its own locally-optimal choice, and the aggregate of those choices is what we experience as "the internet routing itself."

A Brief History: Why BGP Looks the Way It Does

BGP's current version, BGP-4, was standardized in RFC 4271, but its lineage traces back to EGP (Exterior Gateway Protocol) in the early ARPANET era, when the internet was small enough that a simpler, less policy-flexible protocol sufficed. As the network grew into a collection of genuinely competing commercial entities in the 1990s, EGP's assumptions broke down — networks needed a protocol that let them express business policy (who they'd carry traffic for, and under what terms), not just reachability. BGP-4's addition of CIDR support in the same era solved two problems simultaneously: policy-based routing between autonomous systems, and classless addressing that let the routing table scale without exploding in size. That dual heritage — policy expressiveness plus routing table scalability — still defines BGP's design today.

Architecture: eBGP vs iBGP

BGP operates in two distinct modes depending on whether the two speaking routers belong to the same autonomous system. eBGP (external BGP) runs between routers in different autonomous systems — this is the "internet routing" most people picture, exchanging reachability information across organizational boundaries. iBGP (internal BGP) runs between routers within the same AS, ensuring every router inside that organization has a consistent view of externally-learned routes before they're used internally. A common point of confusion for engineers newer to BGP: iBGP routes are not, by default, re-advertised to other iBGP peers (the "split-horizon" rule for iBGP), which is why large networks need either a full iBGP mesh, route reflectors, or confederations to properly distribute routing information internally — a real architectural decision, not just a configuration detail.

A simple multi-homed enterprise: two routers inside AS 64500 talk to each other via iBGP, and each independently peers with a different upstream ISP via eBGP — giving the enterprise two paths to the internet.

The BGP Decision Process, Step by Step

When a router learns multiple paths to the same destination prefix from different neighbors, it must pick exactly one as the "best path" to actually use and advertise onward. This happens through a strict, sequential tie-breaking algorithm — evaluated in order, stopping at the first step that produces a single winner:

1. Highest Weight (Cisco-specific, local to the router, not advertised to neighbors).
2. Highest Local Preference — an AS-wide policy value indicating how strongly this AS prefers a given path, shared via iBGP.
3. Locally originated routes preferred over ones learned from a neighbor.
4. Shortest AS-path length — fewer autonomous systems traversed is generally preferred.
5. Lowest origin type — IGP-originated routes preferred over EGP, which are preferred over Incomplete.
6. Lowest MED (Multi-Exit Discriminator) — a hint from a neighboring AS about its own preferred entry point, only compared between paths from the same neighboring AS by default.
7. eBGP paths preferred over iBGP paths.
8. Lowest IGP metric to the BGP next-hop.
9. Oldest route (stability preference, avoiding unnecessary path churn).
10. Lowest router ID, as a final deterministic tie-breaker.

The practical implication: two organizations can both be technically "correct" while disagreeing about the best path to the same destination, because local preference and MED are locally-configured policy values, not objective measurements — a network engineer's configuration choices genuinely shape what "best" means for that specific AS.

Path Attributes That Drive the Decision

Worked Example: Local Preference in Action

Consider an enterprise multi-homed to two ISPs — a primary fiber connection and a secondary backup link. Both ISPs announce a default route, and both are technically reachable. The enterprise sets a higher local preference on routes learned from the primary ISP, ensuring all outbound traffic prefers that path under normal conditions, with the secondary ISP's routes only becoming the effective path if the primary session goes down (at which point the higher-local-preference routes simply disappear from the table, and the remaining routes via the backup ISP become the new best path by default, with no manual intervention required).

Real-World Deployment Examples

BGP vs Interior Gateway Protocols

Security Considerations Baked Into (and Missing From) BGP

BGP's original design includes essentially no cryptographic verification that an AS announcing a prefix actually has the authority to do so — a gap that's been the root cause of numerous real-world route hijacking and leak incidents over the protocol's history (see our dedicated guide on BGP hijacking for concrete cases). RPKI (Resource Public Key Infrastructure) addresses this by letting prefix holders publish cryptographically signed statements of which ASNs are authorized to originate their prefixes, which routers can validate against — meaningful protection, though adoption remains uneven globally, meaning BGP's trust-based design still matters operationally today.

Common Mistakes in BGP Configuration

Troubleshooting Approach for Unexpected Paths

1. Check local preference values first — it's the highest-priority tie-breaker and the most common source of "why is traffic going this way" surprises.
2. Verify AS-path length and confirm whether prepending is being applied intentionally or accidentally by an upstream.
3. Confirm MED is being compared between paths from the same neighboring AS, not across different ones.
4. Use a BGP lookup tool to independently verify what the rest of the internet currently sees as the origin for a given prefix.

Performance and Operational Best Practices

Well-run networks document their local preference and MED policy explicitly rather than relying on default values scattered across router configurations, since undocumented policy is one of the most common causes of confusing, hard-to-diagnose routing behavior during incident response. Route filtering (only accepting and announcing prefixes that make policy sense) and prefix limits (capping how many routes a session will accept before shutting down defensively) are both considered baseline operational hygiene per RFC 7454's BGP security recommendations, protecting against both misconfiguration and malicious announcements from neighbors.

Checklist for Understanding a BGP Deployment

• Identify every eBGP and iBGP session and confirm the AS boundaries they represent.
• Document local preference values and the business logic behind them.
• Confirm whether route reflectors or a full iBGP mesh are used for internal route distribution, and why.
• Verify prefix filters exist on every eBGP session to prevent accepting or announcing unintended routes.
• Check RPKI validation status on eBGP sessions where available.

Summary

BGP routing works because every one of roughly 70,000 independent networks runs the same well-defined decision process — evaluating local preference, AS-path length, MED, and several further tie-breakers in a strict order — using information voluntarily shared by its neighbors. There's no central coordinator, and there doesn't need to be, because the protocol's design lets purely local, self-interested decisions aggregate into a globally functional (if not always globally optimal) routing system. Understanding that decision process, and specifically which attributes are policy choices rather than objective measurements, is the foundation for understanding nearly everything else about how the internet actually routes traffic.