1. What Is BGP? Building the Core Mental Model

1.1 The International Postal Service Analogy

To understand BGP, imagine sending a physical letter from Tokyo, Japan to Madrid, Spain. Local postal workers in Tokyo handle neighborhood delivery using internal postal codes (representing **IGPs like OSPF**). But to send the letter overseas, the Japanese postal service hands the package to an international dispatch hub.

The international postal hub does not care about individual street addresses in Madrid. Instead, it looks at a high-level country routing table (**BGP Routing Table**): "Japan $\to$ United States $\to$ France $\to$ Spain". Each country represents an **Autonomous System (AS)** with a unique **AS Number (ASN)**. Border postal hubs negotiate routing contracts with neighboring countries, choosing paths based on cost, transit speed, and geopolitical contracts rather than raw physical distance. This is precisely how BGP routes IP packets across the global internet.

Diagram: External BGP (eBGP) peering between distinct Autonomous Systems and Internal BGP (iBGP) peering within an AS.

Pitfall — Assuming BGP chooses the shortest physical geographic path: BGP does NOT measure cable latency or physical distance. BGP selects paths based on administrative policy, `AS_PATH` hop count, and `LOCAL_PREF` metrics. A packet sent from London to Paris might travel through Frankfurt if the transatlantic peering contract prefers that route.

2. Autonomous Systems (AS) and BGP Peering Architecture

2.1 Autonomous System Numbers (ASN)

An **Autonomous System (AS)** is a collection of IP subnets under a single administrative domain sharing a unified routing policy. ASNs are globally unique identifiers assigned by Regional Internet Registries (RIRs like ARIN, RIPE, APNIC).

• 16-Bit ASNs: Legacy range ($1 \text{ to } 65,535$). Private range: $64,512 \text{ to } 65,534$.
• 32-Bit ASNs: Modern extended range ($1 \text{ to } 4,294,967,295$). Private range: $4,200,000,000 \text{ to } 4,294,967,294$.

2.2 eBGP vs iBGP Sessions over TCP Port 179

Unlike IGPs that send UDP or raw IP multicast packets to neighboring interfaces, BGP establishes reliable, point-to-point **TCP connections on Port 179** before exchanging routing information.

Pitfall — eBGP multi-hop failure over loopback interfaces: When establishing an eBGP session between loopback IP addresses, the session fails to connect because eBGP sets `TTL=1` by default. You must explicitly configure `neighbor ebgp-multihop ` (e.g. `ebgp-multihop 2`) to allow the TCP handshake across physical hops.

3. BGP Path-Vector Routing Engine & NLRI Attributes

3.1 Network Layer Reachability Information (NLRI)

BGP routers exchange **UPDATE** messages containing Network Layer Reachability Information (NLRI). An NLRI consists of an IP prefix (e.g. `192.0.2.0/24`) bound to a set of **Path Attributes (PAs)**.

Path attributes are categorized into four standard classes:

1. Well-Known Mandatory: Must be recognized by all BGP implementations and included in every UPDATE message (e.g. `ORIGIN`, `AS_PATH`, `NEXT_HOP`).
2. Well-Known Discretionary: Must be recognized by all BGP implementations but optional in UPDATE messages (e.g. `LOCAL_PREF`, `ATOMIC_AGGREGATE`).
3. Optional Transitive: Optional attributes passed transparently to neighboring ASNs even if not recognized (e.g. `COMMUNITY`).
4. Optional Non-Transitive: Optional attributes discarded if not recognized by neighboring ASNs (e.g. `MED` / Multi-Exit Discriminator).

3.2 Core Attribute Definitions

4. The BGP Best Path Selection Algorithm

4.1 The 8-Step Decision Tree

When a BGP router learns multiple candidate paths for the exact same IP prefix, it evaluates them through a strict, deterministic tie-breaking pipeline. The first criterion that differentiates candidate paths selects the winner:

1. Highest Weight (Cisco-proprietary): Local to router ($0 \text{ to } 65,535$; default 0). Highest wins.
2. Highest LOCAL_PREF: Sent across iBGP within local AS ($0 \text{ to } 4,294,967,295$; default 100). Highest wins.
3. Prefer Locally Originated Routes: Routes generated via local `network` or `aggregate` statements over learned routes.
4. Shortest AS_PATH: Count of ASNs listed in `AS_PATH`. Fewest hops wins.
5. Lowest ORIGIN Code: IGP ($i$) < EGP ($e$) < Incomplete ($?$).
6. Lowest MED (Multi-Exit Discriminator): Compared only between paths received from the same neighboring AS. Lowest wins.
7. Prefer eBGP Path over iBGP Path: External paths preferred over internal paths.
8. Lowest IGP Metric to NEXT_HOP: Route with closest internal IGP (OSPF) distance to the `NEXT_HOP` IP address wins.

Pitfall — Over-reliance on AS_PATH length for traffic engineering: Assuming `AS_PATH` is the primary decision factor is a common error. `LOCAL_PREF` is evaluated BEFORE `AS_PATH`. If a neighboring AS sets `LOCAL_PREF = 200` on a path with 5 AS hops, it overrides a path with `LOCAL_PREF = 100` having only 1 AS hop!

5. iBGP Scaling: Route Reflectors & Confederations

5.1 The iBGP Full-Mesh Problem

To prevent routing loops within an AS, iBGP enforces the **iBGP Split-Horizon Rule**: a router must never re-advertise a route learned via iBGP to another iBGP peer. Consequently, every iBGP router inside an AS must connect directly to every other iBGP router in a **Full Mesh** configuration.

For an Autonomous System with $N$ internal BGP routers, the number of required iBGP TCP sessions is calculated as:

For a network with $N = 100$ routers, a full mesh requires $\frac{100 \times 99}{2} = 4,950$ individual iBGP TCP sessions, creating an un-scalable configuration burden.

5.2 Route Reflectors (RR)

A **Route Reflector (RR)** bypasses the full-mesh requirement. Client routers peer only with the Route Reflector. The RR is permitted to re-advertise iBGP-learned routes to its clients, reducing iBGP sessions from $O(N^2)$ to $O(N)$.

Diagram: Route Reflector cluster topology replacing full-mesh iBGP sessions.

5.3 Route Reflector Loop Prevention: ORIGINATOR_ID and CLUSTER_LIST

Because Route Reflectors relax the iBGP split-horizon rule, they introduce potential internal routing loop risks. BGP prevents loops across Route Reflectors using two mandatory path attributes:

• ORIGINATOR_ID: Created by the first Route Reflector that reflects a route. It carries the BGP Router ID of the local router that originally injected the route into the iBGP domain. If a router receives an iBGP update containing its own Router ID in the `ORIGINATOR_ID` attribute, it silently drops the update.
• CLUSTER_LIST: A sequence of 4-byte Cluster IDs that the route has traversed. When a Route Reflector reflects an iBGP route, it prepends its local Cluster ID to the `CLUSTER_LIST`. If an RR receives an update containing its own Cluster ID in the list, it detects a reflection loop and discards the update.

5.4 BGP Autonomous System Confederations

An alternative to Route Reflectors in massive service provider backbones is **BGP Confederations (RFC 5065)**. A large single Autonomous System (e.g. AS65000) is partitioned internally into multiple sub-Autonomous Systems called **Member ASs** (e.g. AS65001, AS65002) using private ASNs.

Inside each Member AS, standard iBGP full-mesh or Route Reflector rules apply. Between Member ASs, routers run **Intra-Confederation eBGP (ebgp-confed)**. Intra-confederation eBGP behaves like standard eBGP for loop prevention (`AS_CONFED_SET` and `AS_CONFED_SEQUENCE`), but preserves internal attributes like `LOCAL_PREF`, `MED`, and original `NEXT_HOP`. To external peer networks outside AS65000, the internal sub-AS structure is completely invisible, presenting a single unified ASN `AS65000` in the global `AS_PATH`.

Pitfall — Sub-optimal routing with Route Reflectors (MED / IGP cost blindness): Because a Route Reflector chooses its single best path based on its own local IGP distance to the `NEXT_HOP`, client routers in distant data centers might be instructed to use a sub-optimal exit point. Implement **Optimal Route Reflection (ORR)** or BGP Add-Paths to allow RRs to compute custom best paths tailored to individual client locations.

6. Advanced: BGP Security & RPKI Cryptographic Validation

6.1 BGP Hijacking & Route Leaks

Because BGP was designed in the 1980s based on implicit trust, any BGP peer can publish fake UPDATE messages claiming ownership of IP prefixes assigned to other organizations (BGP Route Hijacking). In 2008, Pakistan Telecom accidentally hijacked global YouTube traffic by advertising a more specific `/24` prefix for YouTube's `/22` IP range.

6.2 Resource Public Key Infrastructure (RPKI)

Modern Internet backbones mitigate hijacking using **RPKI (Resource Public Key Infrastructure)**. RPKI binds IP address blocks to authorized origin ASNs using X.509 cryptographic certificates called **Route Origin Authorizations (ROAs)**.

During BGP UPDATE evaluation, routers perform **Route Origin Validation (ROV)**, assigning a cryptographic state to candidate paths:

Pitfall — Overly restrictive MaxLength in ROA certificates: Creating an RPKI ROA for `203.0.113.0/22` with `maxLength=22` prevents your network from announcing smaller `/24` subnets during DDoS mitigation. Always set `maxLength=24` when issuing ROA certificates.

7. Advanced: Production Traffic Engineering Patterns

7.1 Controlling Outbound Traffic via LOCAL_PREF

To force all outbound traffic from your enterprise network to prefer ISP-A over ISP-B, set `LOCAL_PREF` on incoming eBGP routes received from ISP-A using a route-map:

7.2 Controlling Inbound Traffic via AS-Path Prepending

Because you cannot directly set `LOCAL_PREF` inside external neighboring networks, you influence inbound traffic by making backup paths look artificially longer using **AS-Path Prepending** (repeating your ASN in advertisements):

7.3 BGP Community Tags for Advanced Policy Control

BGP **Communities** are 32-bit numerical tags attached to prefixes in UPDATE messages. Format is `ASN:Value` (e.g. `65000:100`). Standard Well-Known Communities include:

• NO_EXPORT (0xFFFFFF01): Do not advertise to external eBGP peers.
• NO_ADVERTISE (0xFFFFFF02): Do not advertise to any peer (iBGP or eBGP).
• BLACKHOLE (0xFFFFFF04): Instructs upstream ISPs to drop all traffic matching this prefix at the border (DDoS mitigation).

7.4 BGP Graceful Restart (RFC 4724)

When a BGP router process restarts or reloads control-plane software, standard BGP tearing down the TCP session causes neighboring routers to purge all routes, resulting in network-wide packet loss. **BGP Graceful Restart** decouples the control plane (BGP process) from the data plane (ASIC forwarding hardware).

During a restart, the restarting router notifies its peers via BGP OPEN Capability negotiated bits. Neighboring peers preserve forwarding state in their Forwarding Information Base (FIB) while waiting for the control plane to re-establish its TCP session (typically 120 seconds), ensuring zero packet loss during software upgrades.

8. Advanced: BGP Timer Tuning and BFD (Bidirectional Forwarding Detection)

8.1 Sub-Second Convergence with BFD

Standard BGP keepalive timers use a **30-second Keepalive** and **90-second Hold Time**. If a fiber optic cable is cut without link-down signal, standard BGP takes **up to 90 seconds** to detect peer loss and withdraw routes.

Pairing BGP with **Bidirectional Forwarding Detection (BFD)** offloads link health monitoring to hardware ASIC micro-code. BFD sends UDP control packets at 50ms intervals, detecting physical path failures in **$< 150\text{ms}$** and triggering immediate BGP failover.

9. Protocol Comparison Matrix

The table below compares BGP against Interior Gateway Protocols (IGP):

10. Interactive: BGP Path Selection Simulator

Click "Evaluate BGP Paths" to trace candidate route evaluation across LOCAL_PREF, AS_PATH, and MED criteria:

11. Convergence Speed Comparison

The chart below compares network convergence detection speed (in milliseconds) across BGP failover mechanisms:

12. Frequently Asked Questions