Border Gateway Protocol is the routing protocol that stitches the global internet together. Where interior gateway protocols like OSPF and IS-IS exchange topology within a single administrative domain, BGP operates between autonomous systems — independently operated networks identified by unique autonomous system numbers. Every major ISP, hyperscaler, university, and enterprise edge that participates in global routing runs BGP at its boundaries. Understanding BGP is not optional for anyone who touches internet-facing infrastructure.
BGP is a path-vector protocol. Unlike distance-vector protocols that advertise only a next hop and metric, BGP speakers exchange full AS paths along with a rich set of path attributes. Receivers apply a deterministic decision process to select the best path for each prefix. The result is not always the shortest path in hop count — commercial policy, traffic engineering, and security considerations routinely override pure topology.
Autonomous Systems and the Global Table
An autonomous system represents a collection of prefixes under common administrative control. AS numbers are 32-bit values allocated by regional internet registries. When an AS originates a prefix, it announces reachability to its BGP neighbors. Those neighbors propagate the announcement, appending their own AS number to the AS_PATH attribute. The global BGP table today carries well over one million prefixes, and every edge router participating in default-free routing must store and process this full table or a carefully filtered subset.
Enterprise networks typically run BGP only at the edge, receiving a default route or a partial table from upstream providers. Service providers and internet exchanges run BGP extensively, maintaining sessions with dozens or hundreds of peers. The distinction matters when troubleshooting: an enterprise engineer focuses on provider routes and local policy, while a carrier engineer manages full-table propagation, prefix aggregation, and peering relationships across multiple continents.
Path Selection and Policy Attributes
BGP path selection follows a well-defined algorithm. After filtering invalid or unwanted routes, a router compares available paths using local preference first — a higher value wins and is evaluated only within the local AS. Next comes AS_PATH length, origin type, MED, eBGP over iBGP preference, IGP cost to the next hop, and finally router ID as a tiebreaker. Operators influence traffic by manipulating these attributes. Setting a higher local preference on routes received from a preferred transit provider ensures outbound traffic exits through that link even when a shorter AS_PATH exists elsewhere.
Multi-exit discriminators allow one AS to suggest inbound path preference to a neighboring AS, though MED comparison only occurs between routes from the same neighboring AS. BGP communities — optional transitive attributes carrying 32-bit values — encode policy at scale. A transit provider might honor community 65535:666 to block announcement to specific peers, or community values agreed with a customer to adjust local preference on their routes. Documenting your community scheme is as important as documenting your IP addressing plan.
Peering, Transit, and Internet Exchanges
Internet connectivity comes through two fundamental relationship types. Transit is a commercial arrangement where a customer pays a provider to carry their traffic to and from the entire internet. The provider announces the customer's prefixes to the global table and provides full or partial routing tables in return. Peering is a settlement-free exchange of traffic between networks of comparable size, typically at internet exchange points where hundreds of networks interconnect over shared fabric.
Peering reduces transit costs and can improve latency by keeping traffic on direct paths. However, peering is non-transitive by design — if AS A peers with AS B and AS B peers with AS C, AS A does not reach AS C through B unless a separate peering or transit relationship exists. Internet exchange points provide route servers that simplify bilateral peering by allowing participants to maintain a single session to the route server rather than hundreds of bilateral sessions, though many large networks still prefer direct peering for policy control.
Session Types and Scaling iBGP
BGP sessions are either external between different autonomous systems or internal within the same AS. eBGP sessions typically connect edge routers to upstream providers or peers. iBGP sessions propagate externally learned routes within the AS so all routers share a consistent view of external destinations. A critical rule governs iBGP: a router does not advertise a route learned via iBGP to another iBGP neighbor unless that route is also reachable via the IGP. This prevents routing loops but creates a scaling challenge in large networks.
Route reflectors solve iBGP full-mesh scaling by allowing designated routers to reflect routes to clients without the non-transitivity restriction. A typical design places route reflectors in each region, with edge routers as clients. Confederations offer an alternative, splitting the AS into sub-autonomous systems that appear as a single AS externally. Both approaches reduce the number of iBGP sessions from order n-squared toward order n while preserving consistent policy application.
Security: Filtering, RPKI, and Incident Response
BGP was designed in an era of cooperative research networks and lacks built-in authentication of route origin. Route leaks — accidental propagation of routes beyond their intended scope — and deliberate prefix hijacks redirect traffic at internet scale. A misconfigured export policy on a single router can announce a customer's entire address space to peers who accept and propagate it globally within minutes.
Prefix filtering on every eBGP session is mandatory baseline hygiene. Accept only prefixes your peer is authorized to announce, using IRR route objects or RPKI ROA data as the source of truth. Resource Public Key Infrastructure allows prefix holders to publish cryptographically signed Route Origin Authorizations specifying which AS may originate each prefix. Networks that perform RPKI-based route origin validation reject invalid origins automatically. Combine RPKI with maximum-prefix limits on sessions, bogon filtering, and aggressive monitoring through services that alert on unexpected prefix appearances in the global table.
Operational Practices
Every BGP-speaking router should have documented neighbors, prefix limits, and policy intent. Maintain looking-glass access or automated checks that validate your prefixes are visible globally with expected AS_PATH attributes. During maintenance, use BGP shutdown mechanisms that gracefully withdraw routes before taking links offline. Understand graceful restart and route refresh capabilities on your platform so sessions recover quickly after control-plane interruptions without traffic blackholes.
When troubleshooting reachability complaints, trace the AS_PATH from multiple vantage points, compare with expected policy, and check for recent configuration changes or provider incidents. BGP is the control plane of the internet — treating it with the same rigor you apply to DNS and certificate management prevents outages that no amount of redundant hardware can fix.