BGP Deep Dive Part 1: The Application That Runs Between Autonomous Systems
I read Halabi’s Internet Routing Architectures first. It’s a respected book and I don’t regret reading it, but I found it heavy going, the kind of heavy where you finish a chapter technically correct about what it said and still can’t explain BGP to someone else. Then I read Jeff Doyle’s Routing TCP/IP, Volume II, and somewhere in the NLRI chapter the penny dropped. It’s been on my desk ever since, more thumbed than almost anything else on the shelf.
Two things from that book have stuck with me since, and both are going to shape how this series is structured. The first is Doyle’s treatment of path attributes as the actual mechanism behind policy, not routing-table entries with extra metadata bolted on, but the thing policy is made of. The second is smaller but changed how I think day to day: his distinction that interior gateway protocols, OSPF, EIGRP, RIP, are protocols that run within an autonomous system, while BGP is closer to an application that runs between them. That distinction sounds like semantics until you sit with it, and this post is largely an attempt to earn it properly rather than just assert it, the way Doyle’s own “spot the issue” exercises train you to read a network for what’s actually happening rather than what the topology diagram implies.
This series is going deep, the way the book that clicked it into place went deep. Twelve parts of theory before a single vendor CLI shows up: history and session mechanics first, then the full attribute catalog and the best path algorithm, then scaling, policy, traffic engineering, multiprotocol extensions, convergence, and security. The vendor-implementation parts, real Cisco 8200s, real Juniper SRX, real FortiOS, real FRR, come after, once the lab hardware is ready. This post is where it starts: why BGP exists at all, and why it was never trying to solve the same problem an IGP solves.
What came before BGP, and why it stopped working
The internet’s first inter-network routing protocol was the Exterior Gateway Protocol, specified in RFC 827 in 1982 and formalized in RFC 904 in 1984. EGP worked, for a while, because the internet it was built for had a shape that made the job easy: a single core backbone, with everything else attached to it as a tree. EGP exchanged reachability information as a distance-vector protocol, hop count as the metric, and it didn’t need to detect routing loops because the topology it was designed for structurally couldn’t produce one. There was one path to the core and everything hung off it.
That assumption held until the internet stopped being one organization’s backbone with customers attached, and became a mesh of independently operated networks that connected to each other for their own commercial and operational reasons. Once there could be more than one path between two networks, and once those paths could belong to organizations with no obligation to trust each other’s metrics or intentions, a hop-count distance-vector protocol with no concept of policy had nothing useful to say. EGP was formally retired by the Internet Architecture Board in 1994, five years after its replacement had already been written.
The two-napkin protocol
BGP’s origin story is well documented enough that it isn’t really folklore anymore. In January 1989, at the 12th IETF meeting in Austin, Texas, Kirk Lougheed of Cisco and Yakov Rekhter of IBM sat down together, with Cisco’s Len Bosack also involved, and sketched out a new routing protocol during a meal. The first draft genuinely was written on the backs of napkins, later transcribed onto three sheets of paper that Cisco still has framed. That sketch became RFC 1105, published in June 1989: BGP version 1.
The protocol went through three more revisions in rapid succession as early deployment surfaced real problems: RFC 1163 in 1990 (BGP-2), RFC 1267 in 1991 (BGP-3), and RFC 1771 in 1995 (BGP-4), which added support for classless inter-domain routing, CIDR, at the point the internet’s growth made class-based addressing unsustainable. BGP-4 is still the version running today. The current specification is RFC 4271, published in 2006, which obsoletes RFC 1771 but doesn’t change the protocol version number: everything on the wire today is still BGP-4, twenty years and counting on the same base spec, extended rather than replaced.
Path vector: not distance-vector, not link-state
Every routing protocol answers the same underlying question, what’s the best path to this destination, but BGP answers it differently enough from an IGP that calling it “just another routing protocol” undersells what it’s actually doing.
RIP is distance-vector: each router knows what its neighbors told it, hop count as the only input, and trusts that information without seeing the topology behind it. OSPF and IS-IS are link-state: every router builds a complete, identical map of the area and runs Dijkstra’s algorithm against a shared cost metric to compute what’s provably the shortest path by that metric. Both approaches depend on something BGP doesn’t have: a single administrative domain where everyone agrees the metric means the same thing and a shortest path is actually what’s wanted.
BGP is path vector. The thing it carries in AS_PATH isn’t a distance, it’s a path, an ordered list of the autonomous systems a route has crossed to get here. That list does two jobs at once: it’s the loop-prevention mechanism, a router that sees its own AS number already in the path simply won’t accept the route, and it’s an input into a decision that BGP deliberately doesn’t try to make universally. There is no BGP equivalent of Dijkstra computing one objectively correct answer, because between autonomous systems there’s no shared cost metric for it to compute over. What one AS considers the best path might be irrelevant, or actively against its interests, to the AS next door. Path vector’s job is to carry enough information for each AS to make that call itself, not to make the call for everyone.
Why an IGP and BGP are solving different problems
This is the distinction Doyle’s book put into words for me better than anything I’d read before it, and it’s worth stating plainly because it changes how you should read the rest of this series: an IGP’s job is to find the best path to a destination inside a network one organization owns and operates. There’s a single administrative authority, a metric everyone inside that authority agrees to use, and the honest goal is efficiency, get traffic from A to B along the path that metric says is shortest.
BGP’s job starts from a different premise. The networks on either side of a BGP session are, in the general case, run by different organizations with different equipment budgets, different commercial relationships, and no shared obligation to optimize for each other’s convenience. Two autonomous systems peering at an internet exchange aren’t cooperating to find a jointly shortest path, they’re each independently deciding what they’re willing to accept from the other, what they’re willing to announce to the other, and what they’re willing to let that other party pass on to third parties. That’s not a routing computation, it’s a negotiation, conducted continuously, in a protocol.
That’s the sense in which BGP is closer to an application running on top of the internet’s connectivity than a protocol that discovers that connectivity in the first place. It doesn’t map physical topology the way OSPF’s LSDB does. It carries policy, expressed as attributes attached to reachability information, and lets every autonomous system apply its own local rules to decide what to do with what it hears. The rest of this series, path attributes, the best path algorithm, communities, traffic engineering, is really just an extended answer to a single question: what does policy actually look like when you have to express it as data on the wire, one attribute at a time.
What an autonomous system actually is
The term autonomous system gets thrown around loosely, so it’s worth being precise before this series leans on it for eleven more parts. RFC 1930 defines an AS as a connected group of one or more IP prefixes operated by one or more network operators that presents a single, clearly defined routing policy to the outside world. The internal detail, how many routers, what IGP they run, how the network is actually built, is invisible from outside the AS. What’s visible, and what BGP actually exchanges, is the policy boundary: this AS number, these prefixes, these attributes.
AS numbers are allocated by IANA down through the regional internet registries, the same allocation hierarchy that hands out IP address space. The original 16-bit AS number field allowed for a little over 64,000 values, and as the internet’s growth started to exhaust that space, RFC 6793 extended AS numbers to 32 bits in 2007, opening up over four billion possible values. Both sizes are still live on the internet today, and the transition between them is its own small piece of protocol history that’s worth a proper look when this series gets to session mechanics, since 4-byte AS number support is negotiated as a BGP capability, not assumed.
Part 2 covers what actually happens when two of these autonomous systems decide to talk to each other: the TCP session on port 179, the full BGP finite state machine from Idle through to Established, and what gets negotiated in the OPEN message before either side sends a single route.