BGP and Internet Routing: The Path-Vector Protocol, AS-Level Topology, Convergence, and the Prefix Hijacking Problem

The internet is not a single network. It is a network of networks — about 70,000 autonomous systems (ASes), each operated by an ISP, a content provider, a university, or an enterprise. These ASes are connected by physical links (fiber, copper, wireless) and by business relationships (peering, transit, settlement-free). The protocol that glues them together — that decides which path a packet takes from a server in Singapore to a laptop in São Paulo — is the Border Gateway Protocol, BGP. And BGP, for all its importance, is a protocol designed in the late 1980s for a trusting world of academic and government networks. It has no built-in security. It converges slowly. It is routinely exploited to hijack IP prefixes and redirect traffic. And yet, it works — most of the time, well enough to carry the world’s internet traffic.

This post is a deep dive into BGP from a systems perspective. We will examine the path-vector algorithm, the AS-level topology, the convergence problem (and why BGP can take minutes to stabilize after a failure), route-flap damping, prefix hijacking, and the defenses — RPKI, BGPSec, and ASPA — that the internet engineering community has deployed to make BGP slightly less terrifying.

1. The Path-Vector Algorithm

BGP is a path-vector protocol. Each BGP router (a “BGP speaker”) maintains a routing table that maps destination IP prefixes (e.g., 8.8.8.0/24) to the best path to reach that prefix. A path is a sequence of AS numbers (the “AS path”) that the route advertisement has traversed, plus a set of path attributes (local preference, MED — multi-exit discriminator, community strings). The AS path serves two purposes: (a) loop prevention (a router rejects a route if its own AS number appears in the AS path), and (b) path length metric (shorter AS paths are generally preferred).

BGP uses a complex, policy-driven path selection algorithm. When a router receives multiple routes to the same destination, it selects the best one by evaluating a sequence of criteria:

1. Highest local preference (a locally configured value that expresses business preferences — e.g., prefer a customer route over a peer route).
2. Shortest AS path (fewer AS hops is generally better, all else being equal).
3. Lowest origin type (IGP < EGP < Incomplete — routes originated from an interior gateway protocol are preferred over routes learned from the old EGP or statically configured).
4. Lowest MED (Multi-Exit Discriminator — a hint from the neighboring AS about which entry point to use).
5. eBGP over iBGP (routes learned from an external BGP peer are preferred over routes learned from an internal BGP peer).
6. Lowest IGP cost to the next-hop (the path with the shortest interior distance to the BGP next-hop router).
7. Lowest router ID (a tiebreaker — the router with the lowest router ID wins).

The path-vector nature of BGP means that route advertisements carry the full AS path, allowing each router to apply its own policies independently. This is in contrast to link-state protocols (OSPF, IS-IS), where every router has the same global topology map and computes shortest paths independently.

2. AS-Level Topology and Business Relationships

The internet’s AS-level topology is shaped by business relationships rather than by raw shortest-path metrics. There are three fundamental relationship types:

Transit (customer-provider). A customer AS pays a provider AS to carry its traffic to and from the rest of the internet. The provider announces the customer’s prefixes to its peers and upstream providers. The customer typically announces only its own prefixes and a default route to the provider. This is the “money flow” of the internet: customers pay providers.

Peering (settlement-free). Two ASes of roughly equal size agree to exchange traffic between their customers without payment. Neither announces routes learned from its own providers or peers to the other — only customer routes and locally originated routes. Peering is typically done at internet exchange points (IXPs) and is governed by “peering policies” that specify minimum traffic volumes, presence at multiple IXPs, and 24/7 NOC contact.

Sibling. Two ASes operated by the same organization exchange all routes freely. Sibling relationships are common among large content providers (e.g., Google’s various ASes) and among ISPs that have merged but maintain separate AS numbers.

The business relationships create a hierarchical structure: a small number of Tier-1 ISPs (roughly 15-20 globally — AT&T, NTT, Deutsche Telekom, Level 3, etc.) form the “default-free zone” — they have no default route and carry the full internet routing table (currently ~950,000 IPv4 prefixes and ~200,000 IPv6 prefixes). Tier-2 ISPs buy transit from Tier-1 ISPs and peer with each other. Tier-3 ISPs and content providers buy transit from Tier-2 ISPs.

3. BGP Convergence: The Minutes-Long Problem

BGP is notoriously slow to converge after a topology change. When a route is withdrawn (because a link fails or a policy changes), BGP routers must propagate the withdrawal and explore alternative paths. The exploration process can involve many rounds of announcements and withdrawals, a phenomenon known as “path hunting” or “BGP path exploration.” In the worst case, BGP can take several minutes to converge — a phenomenon captured by the famous “BGP convergence” experiments by Labovitz, Ahuja, Bose, and Jahanian (2002), which showed that BGP convergence after a route withdrawal can take up to 15 minutes in the worst case.

The root cause is the path-vector algorithm’s “minimum route advertisement interval” (MRAI) timer. To prevent excessive updates, BGP speakers are required to wait at least 30 seconds between successive updates for the same prefix. During path exploration, a router may try a path, find it invalid (because of a loop or a policy rejection), withdraw it, and try another path — each step delayed by the MRAI timer. For a prefix with many alternative paths (common for large ISPs with many peers), the exploration can take many MRAI cycles.

BGP also suffers from the “route-flap” problem: when a route oscillates (advertised, withdrawn, advertised, …), it can cause cascading updates across the internet. BGP’s defense is route-flap damping: if a route flaps (changes state) more than a configurable number of times within a window, it is suppressed (not advertised) for a penalty period that increases exponentially with the number of flaps. Route-flap damping was introduced in the 1990s and successfully reduced the update churn on the internet, but it has been criticized for punishing well-behaved prefixes that happen to experience legitimate instability (e.g., a multi-homed prefix where one link flaps due to physical-layer problems).

4. Prefix Hijacking: BGP’s Fundamental Security Flaw

BGP has no built-in mechanism to verify that a route advertisement is authorized. Any BGP speaker can announce any prefix, and if its advertisement has a shorter AS path or a higher local preference than the legitimate advertisement, it may attract traffic. This is prefix hijacking, and it happens with alarming regularity — major incidents include:

• 2008 Pakistan Telecom hijack of YouTube. Pakistan Telecom, attempting to block YouTube within Pakistan (under government order), accidentally announced a more specific route for YouTube’s prefix (208.65.153.0/24 vs. the legitimate /22), causing YouTube to be inaccessible globally for about two hours.
• 2018 Google Cloud hijack. A Nigerian ISP (MainOne) accidentally announced over 200 Google Cloud prefixes, redirecting traffic through MainOne’s network. The cause was a BGP optimization gone wrong (MainOne’s routers, running a route optimizer, accidentally re-announced prefixes they had learned from Google, instead of only their own customer routes).
• 2022 KLAYswap cryptocurrency hijack. An attacker hijacked the BGP prefix of KLAYswap, a cryptocurrency exchange, by announcing a more specific route. Users who visited the exchange during the hijack were directed to a fake website that stole their credentials and funds.

Prefix hijacking can be:

• Accidental (route leak): A network inadvertently announces prefixes it learned from a provider or peer, rather than only its own customer routes. Route leaks are the most common form of BGP incident.
• Malicious (hijack): An attacker deliberately announces a prefix to intercept, blackhole, or manipulate traffic destined for the legitimate owner.

5. RPKI and BGPSec: Defending BGP

The internet engineering community has developed several defenses against prefix hijacking, deployed incrementally over the past decade:

RPKI (Resource Public Key Infrastructure). RPKI ties IP prefix allocations to the ASes that are authorized to originate them, using X.509 certificates. A prefix owner creates a Route Origin Authorization (ROA) — a digitally signed object that says “AS 1234 is authorized to originate prefix 192.0.2.0/24, with a maximum prefix length of /24.” BGP speakers can validate received route announcements against the RPKI database: if a route’s origin AS does not match an ROA, the route is “invalid” and can be rejected or given a lower preference. RPKI adoption has grown significantly: as of 2025, about 45% of IPv4 prefixes and 55% of IPv6 prefixes are covered by ROAs.

BGPSec (BGP Security). RPKI only validates the origin — the first AS in the AS path. An attacker could still announce a prefix with the correct origin AS but a falsified AS path (e.g., claiming to be directly connected to the origin). BGPSec extends RPKI to validate the entire AS path: each AS signs the route advertisement it forwards, and downstream ASes can verify that the AS path is a valid chain of signatures. BGPSec deployment has been extremely slow because it requires changes to BGP speakers (they must generate and verify cryptographic signatures for every route update) and it significantly increases BGP message sizes and CPU load.

ASPA (Autonomous System Provider Authorization). ASPA is a lighter-weight alternative to BGPSec. An ASPA object states “AS 1234 uses AS 5678 as a transit provider.” When verifying a route, an AS can check that the AS path respects the provider-customer hierarchy: no AS should appear as a provider of an AS that is not, in fact, its provider. ASPA detects route leaks (where a route is announced to a peer or provider instead of being kept within the customer cone) without the cryptographic overhead of BGPSec.

6. BGP in Data Centers and the Cloud

BGP is not just for the internet backbone. It is also the routing protocol of choice for large data centers and cloud providers. In a data center Clos topology (spine-leaf), BGP (often eBGP) runs between every leaf and spine switch, replacing older protocols like OSPF or IS-IS. The reasons:

• Policy-rich: BGP’s path attributes allow fine-grained traffic engineering (e.g., preferring a specific spine for certain traffic classes based on community strings).
• Multiprotocol: BGP carries IPv4, IPv6, MPLS labels, and VPN routes natively.
• Scale: A single BGP session can carry the entire routing table, making it more scalable than link-state protocols for large fabrics.
• Ecosystem: Network engineers know BGP. Using BGP everywhere — WAN, data center, campus — reduces operational complexity.

Microsoft Azure, for example, runs BGP on every server (the “Azure Host Agent” uses BGP to advertise the server’s virtual IPs to the top-of-rack switch). Facebook’s data center fabric (the “FBoss” platform) uses BGP between every switch. The BGP that runs the internet is the same protocol that runs the cloud.

7. Summary

BGP is the internet’s fundamental glue — a path-vector routing protocol that connects 70,000+ autonomous systems through a web of business relationships. It is slow to converge, vulnerable to prefix hijacking, and yet indispensable. The defenses — RPKI, BGPSec, ASPA — are incrementally improving BGP’s security, but the internet’s routing infrastructure remains fundamentally trust-based: a malicious AS, or a misconfigured one, can still cause significant damage.

Understanding BGP is essential for anyone who builds systems that operate at internet scale. When your CDN chooses which edge to route a user to, BGP determines the latency. When your cloud provider announces your virtual IP, BGP determines how traffic reaches it. When a cable is cut in the Mediterranean, BGP determines how quickly the internet routes around the damage. BGP is the invisible protocol that makes the internet work, and despite its flaws, it is one of the most consequential distributed systems ever built.

8. BGP Monitoring and Internet Topology Research

BGP is not just a routing protocol; it is a research platform. Because BGP route announcements are publicly visible (through public route collectors like Route Views and RIPE RIS), researchers can observe the internet’s AS-level topology in near-real-time. This has enabled a vibrant research community in internet topology, routing security, and network economics.

Route collectors and BGPmon. Route Views (University of Oregon) and RIPE RIS (Réseaux IP Européens) operate hundreds of BGP collectors worldwide. These collectors peer with ISPs and receive their BGP routing tables (anonymized and aggregated). Researchers can query these collectors to answer questions like: “Which ASes are announcing YouTube’s prefix?” “How many ASes does a typical route traverse?” “How quickly did the internet route around the 2021 Facebook outage?” BGPmon (now part of ThousandEyes/Cisco) provides real-time BGP monitoring and alerting for prefix hijacks, route leaks, and other anomalies.

The CAIDA topology project. The Center for Applied Internet Data Analysis (CAIDA) at UC San Diego maintains a comprehensive map of the internet’s AS-level topology, built from BGP data, traceroute measurements, and peering database analysis. The CAIDA AS-relationship dataset classifies each AS-AS link as customer-provider, peer-peer, or sibling based on the observed routing policies. This dataset is the foundation of much internet topology research.

What BGP topology reveals. The internet’s AS-level topology has several surprising properties:

• It is a small world: the average AS path length is about 3.5 AS hops (far fewer than the 6 degrees of separation in social networks).
• It is highly centralized at the top: the top 10 ASes (Tier-1 ISPs) are directly connected to over 50% of all other ASes.
• It is dynamic: ASes appear and disappear, peering relationships change, and the topology evolves on timescales of days to months.
• It is not efficient: BGP routes are often longer than the shortest AS path because of business policies (preferring a customer route over a shorter peer route).

9. BGP Communities and Traffic Engineering

BGP communities are a mechanism for attaching metadata to route announcements, enabling flexible traffic engineering. A BGP community is a 32-bit value (often written as AS:value, like 1234:100) that the receiving AS interprets according to a pre-arranged agreement with the sending AS.

Common community uses include:

Local preference setting. A provider might assign community 1234:90 to routes that should have a high local preference (preferred routes) and 1234:10 to routes that should have a low local preference (backup routes). The customer can tag its route announcements with these communities to control how the provider routes traffic to it.

Geographic routing. A content provider might assign communities indicating the geographic region of the advertising PoP (e.g., 15169:1001 = North America East, 15169:1002 = Europe, 15169:1003 = Asia-Pacific). Transit providers use these communities to prefer routes that keep traffic within a region, reducing latency and cross-continental bandwidth costs.

Blackholing. A community like 65535:666 can signal the provider to drop all traffic to the tagged prefix — a remote-triggered blackhole for DDoS mitigation. The customer detects an attack, tags the victim prefix with the blackhole community, and the provider drops traffic to that prefix at the network edge, protecting the customer’s infrastructure.

Route servers at IXPs. At an internet exchange point, a route server collects routes from all participants and re-distributes them, allowing each participant to peer with all others through a single BGP session (instead of N × (N-1)/2 pairwise sessions). Communities are used to control which routes are distributed to which peers (e.g., “announce this route to all peers except AS 1234”).

10. Summary (Extended)

BGP is the internet’s fundamental glue, and it is both a triumph of distributed systems engineering and a cautionary tale about security and scalability. It has scaled from a few hundred ASes in the 1980s to over 70,000 today, carrying nearly a million IPv4 prefixes and growing. It has survived multiple existential crises — the IPv4 address exhaustion, the growth of the routing table, the emergence of prefix hijacking as a threat — and each time, the internet engineering community has patched it (CIDR, route aggregation, RPKI, ASPA) rather than replacing it.

The lesson of BGP for systems researchers is that the most successful distributed protocols are not the most elegant or the most secure — they are the ones that are deployed, that interoperate with existing infrastructure, and that can be incrementally improved. BGP is messy, slow, and insecure. It is also indispensable. That tension — between what a protocol should be and what it must be to succeed in the real world — is the central tension of internet architecture.

11. The Future of Inter-Domain Routing

BGP has been the internet’s inter-domain routing protocol for over three decades. Is it time for a replacement? The internet engineering community has debated this question for years, and the consensus is: “yes, in theory; no, in practice.” Replacing BGP would require every AS on the internet to upgrade their routers simultaneously — an impossible coordination problem.

Instead, the future of inter-domain routing is likely to be evolutionary, not revolutionary:

BGPsec or an alternative path validation. BGPsec’s slow adoption suggests that full path validation may be too expensive (in CPU, memory, and operational complexity) for the benefit it provides. Lighter-weight alternatives (like ASPA) that validate the provider-customer hierarchy without per-hop signatures may be more practical.

Centralized route control with BGP as the data plane. Software-defined WAN (SD-WAN) products (from Cisco, VMware, Aruba) use a centralized controller to compute optimal routes based on application requirements (latency, bandwidth, cost) and use BGP to install those routes in the edge routers. This is the SDN model applied to WAN routing: BGP is the southbound protocol, and the SD-WAN controller is the control plane. This is likely the direction BGP will evolve: it will remain the inter-domain routing protocol, but it will be increasingly controlled by centralized, application-aware controllers rather than by distributed, policy-based path selection.

BGP in space. SpaceX’s Starlink and Amazon’s Project Kuiper are deploying satellite constellations that provide internet access globally. These constellations use BGP to exchange routes with terrestrial ISPs. The inter-satellite links (laser links between satellites) create a dynamic, constantly-changing topology that challenges BGP’s slow convergence. This may drive further evolution of BGP — or motivate a new routing protocol designed for highly dynamic, 3D mesh networks.

Quantum-safe BGP. The cryptographic signatures used by RPKI and BGPsec rely on RSA and ECDSA, which are vulnerable to quantum computing attacks (Shor’s algorithm). The IETF is working on quantum-safe cryptographic algorithms for RPKI and BGP, but the transition will be complex: every router that validates RPKI signatures must be upgraded to support post-quantum algorithms. This is a multi-decade effort that is just beginning.

12. Final Thoughts

BGP is the protocol that holds the internet together, and it is a miracle that it works as well as it does. It was designed in the late 1980s, for a network of a few hundred ASes in a trusting academic environment. It has scaled to 70,000+ ASes, a million prefixes, a hostile threat environment, and a global economy that depends on it. It has done so not because it is perfect but because it is good enough, and because the internet engineering community has continuously patched, extended, and fortified it.

The lesson of BGP for systems researchers is that the most important protocols are not the most elegant or the most secure. They are the ones that are deployed, that interoperate, and that can evolve. BGP is a testament to the power of incremental improvement and the resilience of the internet architecture. It will be with us for decades to come, evolving slowly, holding the internet together, one AS path at a time.

13. BGP in the Age of Hyperscale: How Google, Amazon, and Microsoft Use BGP

The hyperscale cloud providers (Google, Amazon, Microsoft) operate some of the largest BGP networks in the world. Their use of BGP illuminates both the protocol’s strengths and its limitations at extreme scale.

Google’s BGP network. Google operates AS 15169, one of the largest ASes on the internet. Google peers with thousands of ISPs at internet exchange points worldwide and operates a global backbone network connecting its data centers. Google’s BGP configuration is highly automated: the “BGP configuration” is generated from a high-level intent specification and pushed to routers via a CI/CD pipeline. Google also operates a separate BGP network for Google Cloud customers (via Cloud Interconnect and Cloud VPN).

Amazon’s BGP network. Amazon operates multiple ASes (AS 16509 for AWS, AS 14618 for retail) and peers with thousands of networks. AWS customers can use BGP to advertise their own IP prefixes to AWS (via Direct Connect) and to receive routes from AWS. Amazon’s VPC (Virtual Private Cloud) uses BGP internally to distribute routes between the software-defined networking overlay and the physical underlay network.

Microsoft’s BGP network. Microsoft operates AS 8075 (Microsoft Corporation) and peers with thousands of networks. Azure uses BGP for ExpressRoute (private connectivity between customer data centers and Azure), for VPN gateways, and for internal route distribution within Azure regions. Microsoft is also a major user of BGP communities for traffic engineering, allowing customers to control how their traffic is routed through Azure’s global network.

The hyperscale experience with BGP reveals both its durability and its pain points: BGP scales to tens of thousands of peers and millions of routes, but the configuration complexity is enormous. Each peer has its own BGP session parameters, its own route policies, its own community semantics. Automating this complexity — and verifying that the automation is correct — is a significant engineering investment. The hyperscale operators have effectively built SDN-like control planes on top of BGP, using BGP as the southbound protocol and managing it through centralized, software-defined controllers.

14. Final Thoughts

BGP is the internet’s oldest continuously running distributed system. It has survived the transition from NSFNET to the commercial internet, from IPv4 to IPv6, from a few hundred ASes to over 70,000. It has been patched, extended, and fortified against threats that its original designers could not have imagined. It is slow, insecure, and operationally complex. It is also indispensable.

The lesson of BGP for systems researchers is that the most important systems are not the most elegant — they are the ones that are deployed, that interoperate, and that can evolve. BGP’s evolution — from a simple path-vector protocol to a policy-rich, community-tagged, RPKI-validated substrate for internet routing — is a testament to the power of incremental improvement. The internet runs on BGP. It will run on BGP for decades to come. And the challenge for the next generation of internet engineers is not to replace BGP but to continue improving it, making it more secure, more reliable, and more automated, one AS path at a time.

15. The Philosophy of BGP: Why the Internet Chooses Paths the Way It Does

BGP is often described as a “policy-based” routing protocol, in contrast to “shortest-path” protocols like OSPF and IS-IS. The distinction is profound: BGP does not try to find the shortest path; it tries to find the path that best satisfies the business policies of the ASes involved. This is both BGP’s greatest strength and its greatest weakness.

BGP as an economic protocol. BGP’s path selection criteria — local preference, AS path length, MED — are economic, not engineering, criteria. Local preference encodes business relationships (prefer customer routes because they generate revenue; deprioritize peer routes because they cost money). AS path length is a rough proxy for “how many business entities must I pay or negotiate with to reach this destination?” MED encodes “which of my provider’s entry points is cheapest or most efficient?”

The valley-free routing principle. Internet routing follows the “valley-free” principle: a route should not go up the provider hierarchy (from customer to provider) and then down (from provider to customer) without a good reason. Routes that violate this principle — “valley routes” — are typically rejected by BGP policy. This principle emerges from the economics of peering and transit, not from any technical requirement.

BGP as a distributed constraint solver. The global BGP routing table is the solution to a massive, distributed constraint satisfaction problem: each AS imposes preferences and constraints (prefer customers, avoid certain paths, respect RPKI ROAs), and the BGP protocol iterates to a stable state that satisfies all of them (or oscillates if no stable state exists). This is a different paradigm from the “shortest path” mindset of most routing protocols, and it is the reason BGP is so hard to reason about and so resistant to replacement.

16. Final Summary

BGP is the internet’s oldest distributed system, and it remains its most important. It is messy, slow, and insecure. It is also indispensable. It has scaled from hundreds of ASes to tens of thousands, from thousands of prefixes to nearly a million, from a trusting academic network to a hostile commercial one. It has evolved — RPKI for origin validation, ASPA for path validation, SDN-style centralized control — but it has not been replaced.

The lesson of BGP is that the most successful systems are not the most beautiful. They are the ones that work, that interoperate, that evolve, and that are too deeply embedded to be replaced. The internet runs on BGP. It will run on BGP for the foreseeable future. Our task is not to replace it but to improve it, incrementally, patiently, one route at a time.

17. BGP’s Place in the Internet Architecture

BGP operates at a unique point in the internet protocol stack. It is an application-layer protocol (it runs on top of TCP, port 179) that controls the network layer (it determines IP packet forwarding). This recursive relationship — an application that controls the very network it runs on — is one of the reasons BGP is so hard to reason about. BGP’s stability depends on the IP connectivity it provides, and IP connectivity depends on BGP’s routing decisions. A BGP misconfiguration can create a “routing black hole” — a network that is reachable via BGP but cannot actually forward packets because its internal routing is inconsistent.

BGP is also one of the few protocols that has resisted replacement for decades. The IETF has considered BGP replacements — HLP (Hybrid Link-state Path-vector), LISP (Locator/ID Separation Protocol), SCION — but none have achieved significant deployment. The reasons are instructive: (1) BGP is “good enough” for most purposes; (2) replacing BGP would require coordinated action by tens of thousands of independently operated networks; (3) any replacement would need to interoperate with BGP during a transition period that might last decades.

The resilience of BGP is both a strength and a weakness. It demonstrates that a protocol that is widely deployed and incrementally improvable can outlast more elegant alternatives. But it also demonstrates that the internet’s architectural foundations are hard to change, even when they are clearly suboptimal. The internet runs on BGP, and it will continue to run on BGP for the foreseeable future — not because BGP is the best possible inter-domain routing protocol, but because it is the one we have.

18. Epilogue: The Glue That Holds the Internet Together

BGP is the internet’s fundamental glue — a path-vector routing protocol that connects 70,000+ autonomous systems through a web of business relationships. It is slow to converge, vulnerable to prefix hijacking, and yet indispensable. The defenses — RPKI, BGPSec, ASPA — are incrementally improving its security, but the internet’s routing infrastructure remains fundamentally trust-based. BGP is not the best inter-domain routing protocol we could design. But it is the one we have deployed, the one we have scaled, and the one we have evolved. And that — not elegance, not security, not performance — is what makes a protocol succeed.

19. Afterword: The Internet Routes Around Damage

The internet’s most famous aphorism — “the internet routes around damage” — is literally true, and BGP is the protocol that does the routing. When a fiber cut severs a transatlantic cable, BGP finds alternative paths. When a DDoS attack overwhelms a data center, BGP withdraws the routes and traffic shifts elsewhere. When a new network connects to the internet, BGP announces its prefixes and the world learns how to reach it. BGP is slow, insecure, and operationally complex. But it has kept the internet running for over three decades, through growth of five orders of magnitude, through wars and natural disasters and economic upheavals. BGP is not the best protocol we could design. But it is the one we have, and it has earned our respect.

20. Coda: The Internet’s Oldest Protocol

BGP is the internet’s oldest continuously running distributed system. It has been operating, in one form or another, since the late 1980s. It has survived the transition from NSFNET to the commercial internet, from classful to classless addressing (CIDR), from IPv4 to IPv6, from a few hundred ASes to over 70,000. It has been patched, extended, and fortified against threats its original designers never imagined. It is slow, insecure, and operationally complex. But it has kept the internet running for over three decades, and it will keep it running for decades more. BGP is not the best protocol we could design. But it is the one we have, and it has earned its place in the pantheon of great distributed systems — not for its elegance, but for its endurance.

The BGP story has no ending. As long as the internet exists, BGP will be there, quietly exchanging routes between autonomous systems, adapting to new threats and new requirements, evolving incrementally. It will not be replaced. It will not be rewritten. It will simply continue — the internet’s oldest distributed system, doing its job, keeping the packets flowing, one AS path at a time. And that, perhaps, is the highest compliment a protocol can receive.

BGP is not just a protocol. It is the nervous system of the internet — the mechanism by which the network senses its own topology, responds to failures, and adapts to growth. It is slow, insecure, and complex. It is also essential, irreplaceable, and remarkably resilient. Understanding BGP — its path-vector algorithm, its policy-driven decisions, its convergence behavior, its security vulnerabilities — is understanding how the internet works at its most fundamental level. Every distributed systems engineer should know BGP, not because they will configure it (most won’t), but because it is the protocol that makes the internet possible.