Every time you send a packet across the internet, it traverses multiple autonomous systems—distinct networks operated by ISPs, enterprises, and content providers. Border Gateway Protocol is the glue holding this patchwork together, but it doesn't work the way most engineers initially assume.

BGP isn't a shortest-path protocol. It doesn't calculate optimal routes based on latency, bandwidth, or hop count in any traditional sense. Instead, it implements a complex decision process where policy trumps performance at nearly every step. The routes your packets take reflect business relationships, peering agreements, and administrative preferences as much as network topology.

Understanding BGP's actual decision-making logic reveals why internet routing sometimes seems irrational. Routes that appear suboptimal often represent carefully negotiated traffic engineering policies. The system's design acknowledges a fundamental truth: the internet is a network of competing commercial interests, not a unified technical system optimized for efficiency.

BGP routers don't simply pick the shortest path to a destination. When multiple routes exist to the same prefix, BGP applies a sequential decision process with roughly a dozen attributes, evaluated in strict order until a single best path emerges. This hierarchy determines everything about internet routing behavior.

The process begins with local preference, an attribute set by network administrators to express routing policy. A route learned from a paid transit provider might receive local preference 100, while the same prefix learned from a settlement-free peer gets 200. Higher wins. This single attribute often determines the outcome before BGP examines anything else—your traffic flows based on your network's business relationships.

Only when local preference ties does BGP consider AS path length—the number of autonomous systems a route traverses. Shorter paths win. But this metric is easily manipulated through AS path prepending, where networks artificially inflate their path length to make routes less attractive. A network might prepend its own AS number three times to shift inbound traffic to a different interconnection point.

When AS path length also ties, BGP descends through origin type, MED values, eBGP versus iBGP preference, IGP cost to the next hop, and ultimately arbitrary tie-breakers like lowest router ID. Each step reflects different technical or administrative considerations. The system guarantees a single winning route, but the winner often surprises engineers who expect purely technical optimization.

Takeaway

BGP's decision process evaluates policy attributes before path efficiency—local preference determines most routing outcomes, making business relationships more influential than network topology.

Internet routing reflects economic reality. Networks pay for transit, exchange traffic through peering agreements, and use BGP to implement these relationships technically. Route filtering and BGP communities provide the mechanisms, transforming commercial contracts into packet-forwarding decisions.

Consider a dual-homed enterprise with two ISP connections. Without policy configuration, BGP might send all outbound traffic through whichever ISP advertises shorter AS paths—regardless of which connection has more capacity or lower cost. By setting local preference appropriately, the enterprise ensures traffic flows through its preferred provider, falling back to the secondary only during outages.

Inbound traffic control proves more challenging since you can't directly control other networks' routing decisions. Networks influence inbound paths by selectively advertising prefixes and manipulating attributes visible to external peers. Advertising a /24 to one provider and a /23 covering the same space to another creates preference through longest-prefix matching. AS path prepending makes specific routes less attractive without withdrawing them entirely.

BGP communities extend this control by carrying metadata that receiving networks interpret according to bilateral agreements. Sending a route with a specific community value might tell your upstream provider to deprioritize that path, or advertise it only to customers rather than peers. These community-based policies enable sophisticated traffic engineering without constant manual coordination. The protocol becomes a language for expressing network policy across organizational boundaries.

Takeaway

BGP communities and route filtering transform business relationships into routing behavior—understanding these mechanisms matters more than understanding shortest-path algorithms for real-world traffic engineering.

When routing changes occur—a link fails, a new path appears, or policy updates take effect—BGP must propagate this information across the internet. Unlike interior gateway protocols that converge in seconds, BGP convergence can take minutes. This delay stems from fundamental protocol design decisions optimized for stability over speed.

BGP uses incremental updates rather than flooding complete routing tables. When a route changes, routers send UPDATE messages to their neighbors, who process them, apply local policy, and potentially propagate further updates. Each hop introduces processing delay. With the global routing table containing over 900,000 prefixes and typical AS paths spanning 4-5 hops, changes ripple slowly.

The protocol includes Minimum Route Advertisement Interval (MRAI) timers—typically 30 seconds for eBGP sessions—that deliberately slow update propagation. This prevents route oscillation from overwhelming the network with rapid changes, but it means a single failure can take several minutes to fully propagate. During convergence, different parts of the internet hold inconsistent routing state, causing packets to take unexpected paths or black-hole entirely.

Route oscillation presents a more serious challenge. Certain network topologies combined with specific policy configurations can cause routes to continuously flip between states, never converging. BGP's path-vector design can create scenarios where each network's locally optimal decision creates globally unstable behavior. Route flap damping mechanisms suppress oscillating routes but introduce their own problems by delaying legitimate convergence after real outages.

Takeaway

BGP deliberately trades convergence speed for stability—expect minutes, not seconds, for routing changes to propagate globally, and design failover mechanisms accordingly.

BGP's decision process reveals the internet's true nature: a federation of competing networks cooperating just enough to maintain connectivity. The protocol's policy-first design isn't a flaw but a feature, enabling the complex commercial relationships that fund global infrastructure.

For network engineers, this understanding transforms troubleshooting and design. Route optimization means policy optimization. Traffic engineering requires manipulating attributes and communities, not chasing theoretical shortest paths. Convergence delays demand redundancy and fast-failover mechanisms at layers above BGP.

The routing table you see represents countless bilateral negotiations encoded in protocol attributes. Every path your packets take reflects technical capability filtered through business reality—a system that's simultaneously elegant and messy, like the internet itself.