Every time you access a website hosted on another continent, stream video from a content delivery network, or send an email to someone using a different ISP, your traffic traverses the boundaries between Autonomous Systems. These boundary crossings are governed by a single, remarkable protocol that has scaled from connecting a few dozen research networks in the 1980s to managing routes for the entire global Internet today.

That protocol is BGP—the Border Gateway Protocol.

Exterior Gateway Protocols (EGPs) are routing protocols designed to exchange routing information between Autonomous Systems. Unlike IGPs that optimize paths within a trusted domain, EGPs must handle the complex realities of the Internet: competing commercial interests, diverse routing policies, security threats from untrusted peers, and a scale that encompasses billions of routes.

Before BGP, the Internet used a protocol literally named EGP (Exterior Gateway Protocol). Understanding this history illuminates why BGP evolved as it did.

The Original EGP (RFC 827, 1982):

The original EGP was designed for the nascent ARPANET/Internet when there were only a handful of interconnected networks. It had fundamental limitations:

• Tree topology assumption: EGP assumed the Internet was organized as a strict tree with the core at the top. It couldn't handle arbitrary connectivity.
• No loop prevention: With only tree topologies expected, loop prevention wasn't built in.
• No policy support: EGP simply exchanged reachability information; no mechanism for preferring routes or implementing complex policies.
• Limited scalability: As networks grew more interconnected, EGP's limitations became critical.

The Birth of BGP:

By the late 1980s, the Internet's topology had evolved beyond a tree structure. Networks connected to multiple upstream providers, creating loops that EGP couldn't handle. BGP was developed with several key innovations:

1. Path Vector Protocol: BGP tracks the complete AS path to each destination, not just distance or next-hop. This enables loop detection (a router rejects routes containing its own AS) and policy decisions (prefer or avoid routes through specific ASes).

2. Policy-Based Routing: BGP allows operators to implement complex routing policies—prefer customer routes over peer routes, avoid certain transit providers, prepend AS paths to influence inbound traffic, etc.

3. Arbitrary Topology: BGP assumes nothing about network topology. It works correctly in any configuration of AS interconnections.

4. Stability Over Speed: Unlike IGPs that prioritize fast convergence, BGP deliberately converges slowly. Mechanisms like MRAI (Minimum Route Advertisement Interval), dampening, and holddown timers prevent local instability from cascading globally.

BGP-4 and CIDR:

BGP-4, the current version, introduced support for Classless Inter-Domain Routing (CIDR), enabling route aggregation that was essential for the Internet's address scalability. Without CIDR and BGP-4's support for it, the Internet routing table would have exploded beyond manageability decades ago.

BGP is classified as a path vector protocol, distinct from both distance vector and link state protocols. Understanding this classification is essential for understanding BGP's behavior.

What Makes Path Vector Different:

The AS_PATH Attribute:

The most distinctive feature of path vector is the AS_PATH attribute. Every BGP route advertisement includes a list of all ASes the route has traversed:

Prefix: 8.8.8.0/24 (Google DNS)
AS_PATH: 15169    → Originated by Google (AS15169)

Prefix: 8.8.8.0/24
AS_PATH: 3356 15169    → Seen via Lumen transit

Prefix: 8.8.8.0/24  
AS_PATH: 174 3356 15169    → Seen via Cogent → Lumen path

Loop Detection:

When a BGP router receives a route, it examines the AS_PATH. If the router's own ASN appears in the path, the route is rejected—it has already seen and propagated this route, so accepting it would create a loop. This is eleganly simple and foolproof, unlike the heuristic approaches of distance vector protocols.

Policy Implementation:

The AS_PATH enables sophisticated policy decisions:

• Prefer routes with shorter AS paths (typically closer, lower latency)
• Reject routes through specific ASes (competitors, unreliable networks)
• Prepend your own ASN to make a route look longer (discourage inbound traffic)
• Filter based on origin AS (only accept routes from authorized sources)

BGP and IGPs solve different problems, which leads to fundamentally different designs. Understanding these differences prevents incorrect assumptions when configuring or troubleshooting BGP.

Why BGP Uses TCP:

Unlike IGPs that use specialized protocol headers (OSPF protocol 89, IS-IS on Layer 2) or UDP (RIP), BGP runs over TCP port 179. This design choice reflects BGP's requirements:

1. Reliability: TCP's guaranteed delivery eliminates the need for BGP to implement retransmission logic. Important in an environment where packets may traverse multiple networks.

2. Flow Control: TCP handles congestion and flow control, preventing BGP from overwhelming receivers during large table transfers.

3. Simplicity: Using TCP simplifies the BGP implementation—it focuses on routing logic, not transport mechanics.

4. Security: TCP's connection model enables authentication (MD5, TCP-AO) and stateful filtering at firewalls.

5. Cross-AS Transport: TC/IP works across AS boundaries where IGP-specific transports cannot.

Why BGP Converges Slowly:

BGP deliberately includes mechanisms that slow convergence:

• MRAI (Minimum Route Advertisement Interval): Routers wait before advertising changes (30 seconds for eBGP by default)
• Route Dampening: Flapping routes are suppressed to prevent instability propagation
• Holdtime: Peers are declared dead only after holdtime expires (default 180 seconds)

These timers exist because Internet-scale instability is catastrophic. A flapping link between two ASes should not cause route oscillations across thousands of other networks. BGP sacrifices speed for global stability.

BGP is used in two distinct contexts with different rules:

External BGP (eBGP): Sessions between routers in different Autonomous Systems. This is "true" inter-domain routing—exchanging routes with external organizations.

Internal BGP (iBGP): Sessions between routers in the same Autonomous System. Used to distribute externally-learned routes throughout the AS.

Despite sharing the BGP protocol mechanics, eBGP and iBGP have critical behavioral differences:

The iBGP Full Mesh Problem:

A critical iBGP rule: Routes learned from one iBGP peer are NOT advertised to other iBGP peers. This prevents loops within the AS (since AS_PATH isn't modified for iBGP). However, it creates a requirement:

All iBGP speakers must be directly peered (full mesh).

With n routers, this means n×(n-1)/2 sessions:

• 10 routers: 45 sessions (manageable)
• 50 routers: 1,225 sessions (challenging)
• 100 routers: 4,950 sessions (impractical)
• 1000 routers: 499,500 sessions (impossible)

Solutions to the Full Mesh Requirement:

1. Route Reflectors (RR):

   • Designated routers that "reflect" iBGP routes to other iBGP peers
   • Breaks the "don't re-advertise iBGP" rule in a controlled way
   • Clients peer with RRs, not with each other
   • Reduces sessions from O(n²) to O(n)

2. Confederation:

   • Divide the AS into internal sub-ASes (confederation members)
   • Each sub-AS runs iBGP internally
   • Sub-ASes peer with each other using eBGP-like semantics
   • External ASes see only the confederation's public ASN

BGP is a stateful protocol with explicit session establishment and maintenance. Understanding BGP message types and session lifecycle is essential for operations and troubleshooting.

BGP Message Types:

BGP Session States (Finite State Machine):

BGP sessions progress through a well-defined state machine:

UPDATE Message Structure:

The UPDATE message is where route information is exchanged:

UPDATE Message:
├── Withdrawn Routes Length (2 bytes)
├── Withdrawn Routes (variable)
│   └── List of prefixes being removed
├── Total Path Attribute Length (2 bytes)
├── Path Attributes (variable)
│   ├── ORIGIN (IGP, EGP, INCOMPLETE)
│   ├── AS_PATH (list of ASes)
│   ├── NEXT_HOP (IP address)
│   ├── MULTI_EXIT_DISC (MED, optional)
│   ├── LOCAL_PREF (iBGP only)
│   ├── COMMUNITIES (optional tags)
│   └── [Many more optional attributes...]
└── Network Layer Reachability Information (NLRI)
    └── List of prefixes being advertised

A single UPDATE can advertise multiple prefixes sharing the same attributes, and can simultaneously withdraw other prefixes.

BGP routes carry path attributes that provide information about the route and influence path selection. Understanding these attributes is essential for implementing routing policy.

Attribute Categories:

Key Path Attributes:

1. ORIGIN (Well-known Mandatory)

• Indicates how the route was injected into BGP
• Values: IGP (i), EGP (e), INCOMPLETE (?)
• IGP means originated within BGP (network command or redistribution from IGP)
• INCOMPLETE means redistributed from another source without full information

2. AS_PATH (Well-known Mandatory)

• Ordered list of ASes the route has traversed
• Used for loop detection and path selection
• Shorter paths generally preferred

3. NEXT_HOP (Well-known Mandatory)

• IP address to forward traffic toward this destination
• Must be reachable in the routing table (via IGP or static route)

4. LOCAL_PREF (Well-known Discretionary, iBGP only)

• Preference level for a route within the AS
• Higher = more preferred (default 100)
• Used to prefer certain exit points within your network
• NOT sent to eBGP peers

5. MED (Multi-Exit Discriminator) (Optional Non-transitive)

• Suggests to external ASes which entry point to use
• Lower = more preferred
• Only compared between routes from the same neighboring AS
• Non-transitive (stripped at AS boundaries)

6. COMMUNITY (Optional Transitive)

• 32-bit tags attached to routes for policy
• Format: ASN:value (e.g., 65000:100)
• Used to mark routes for special handling
• Well-known communities: NO_EXPORT, NO_ADVERTISE, LOCAL_AS

7. ATOMIC_AGGREGATE (Well-known Discretionary)

• Indicates route has been aggregated and some path information lost
• Set when advertising aggregate routes

8. AGGREGATOR (Optional Transitive)

• Identifies the AS and router that performed aggregation
• Paired with ATOMIC_AGGREGATE for troubleshooting

9. ORIGINATOR_ID and CLUSTER_LIST (Optional Non-transitive)

• Used with route reflectors to prevent loops
• ORIGINATOR_ID identifies the original route reflector client
• CLUSTER_LIST tracks route reflector clusters traversed

When multiple paths exist to the same destination, BGP selects the "best" path using a well-defined decision process. Understanding this process is crucial for predicting BGP behavior and implementing effective routing policy.

The BGP Best Path Selection Algorithm:

BGP evaluates paths in order, using the first criterion that differentiates them:

Practical Path Selection Scenarios:

Scenario 1: Preferring a Specific Upstream You connect to ISP-A (customer, paying for transit) and ISP-B (peer, settlement-free). You want to prefer ISP-A for all outbound traffic.

Solution: Set higher LOCAL_PREF (e.g., 150) on routes from ISP-A, lower (100) on ISP-B. LOCAL_PREF is step 2, so it takes precedence over AS_PATH length.

Scenario 2: Traffic Engineering Inbound You want inbound traffic from AS65001 to prefer your Link-A over Link-B.

Solution: Advertise to AS65001 via Link-B with AS prepending (make AS_PATH longer), or advertise more specifics via Link-A. Note: You don't control their LOCAL_PREF, so use attributes they'll evaluate.

Scenario 3: Cold Potato vs Hot Potato By default (step 8), BGP prefers routes with lower IGP cost to NEXT_HOP—"hot potato" routing (exit your network quickly). To implement "cold potato" (carry traffic longer in your network), disable this with bgp bestpath igp-metric ignore.

We've deeply explored Exterior Gateway Protocols and BGP's role as the Internet's routing backbone. Let's consolidate the essential knowledge:

What's Next:

With solid understanding of both IGP and EGP protocols, we'll now explore protocol selection—how network architects decide which routing protocols to deploy, when to use static routing, and how to design for specific requirements like redundancy, convergence, and scalability.