Interdomain Routing Fundamentals

Author

K19G

Updated

October 31, 2026

Interdomain Routing Fundamentals

Interdomain routing is fundamentally distinct from intradomain routing. While an Interior Gateway Protocol (such as OSPF or IS-IS) solves an algorithmic optimization problem—finding the lowest-cost shortest path across a unified topology—interdomain routing solves a policy enforcement problem across independent, untrusted autonomous domains.

What Interdomain Routing Must Achieve

An interdomain routing system must fulfill four non-negotiable requirements:

  1. Autonomy of Policy: Every network operator must retain complete sovereignty over its routing decisions. An AS must be able to choose which paths to prefer, which paths to accept, and which paths to suppress, without revealing its internal topology or commercial agreements to competitors.
  2. Global Scalability: The control plane must scale to over 100,000 interacting ASes and more than a million prefixes without requiring synchronous global state synchronization or quadratic message complexity.
  3. Loop Freedom: Because interdomain paths traverse arbitrary meshes of autonomous networks, the protocol must guarantee loop-free forwarding without requiring complete knowledge of the global network graph.
  4. Incremental Convergence: In a dynamic topology where links bounce, fibers are severed, and routers reboot constantly, updates and withdrawals must propagate incrementally without triggering global routing storms.

Direct Connectivity: iBGP and eBGP Sessions

BGP-4 operates over point-to-point peering sessions using TCP (destination port 179). Sessions are categorized based on the AS membership of the two peers:

Property External BGP (eBGP) Internal BGP (iBGP)
ASN Relationship Peers reside in different ASes (\(AS_A \neq AS_B\)) Peers reside in the same AS (\(AS_A = AS_B\))
Physical Proximity Typically direct point-to-point link or IXP peering fabric Routers may be multiple IGP hops apart
Default TTL TTL = 1 (requires multihop override if not directly connected) TTL = 64 or 255 (traverses internal IGP topology)
AS_PATH Modification Prepends local ASN upon export Does not alter the AS_PATH attribute
NEXT_HOP Handling Rewrites NEXT_HOP to local peering interface address Preserves original eBGP NEXT_HOP (unless next-hop-self)
Split Horizon Rule Allows re-advertisement to other eBGP peers Routes learned via iBGP are never advertised to other iBGP peers 
+-------------------------------------------------------+
|                    Autonomous System 100              |
|                                                       |
|   +----------+          iBGP (TCP 179)          +----------+   |
|   | Router A | <==============================> | Router B |   |
|   +----+-----+         (Preserves AS_PATH)      +-----+----+   |
|        |                                              |        |
+--------|----------------------------------------------|--------+
         | eBGP (TTL=1)                                 | eBGP (TTL=1)
         | (Prepends AS100)                             | (Prepends AS100)
         v                                              v
+-----------------+                            +-----------------+
|   Router C      |                            |   Router D      |
|    (AS 200)     |                            |    (AS 300)     |
+-----------------+                            +-----------------+

Because iBGP enforces a strict split-horizon rule (a route learned from one iBGP peer cannot be passed to another iBGP peer), an AS traditionally required a full mesh of iBGP sessions across all internal BGP speakers. At scale, this is resolved using Route Reflectors (RFC 4456) or BGP confederations (RFC 5065).

Route Advertisements and Withdrawals in Practice

A BGP session is a continuous stateful exchange of Network Layer Reachability Information (NLRI). Unlike periodic link-state advertisements, BGP is purely event-driven:

Advertisements (UPDATE with NLRI)

When a network originates a prefix or selects a new best path from an upstream neighbor, it crafts an UPDATE message containing: - NLRI: One or more prefixes (e.g., 192.0.2.0/24). - Path Attributes: Mandatory metadata including ORIGIN, AS_PATH, and NEXT_HOP.

Withdrawals (UPDATE with Withdrawn Routes)

When a prefix becomes unreachable (due to an interface failure, policy change, or withdrawal received from an upstream transit provider), the router immediately issues an UPDATE specifying the prefix in the Withdrawn Routes field. A withdrawal requires no path attributes; it instructs the peer to purge the prefix from its Routing Information Base (RIB-In) and recompute best paths immediately.

Implicit Withdrawals

If a peer receives an UPDATE for a prefix that already exists in its table with different path attributes (e.g., a changed AS_PATH or NEXT_HOP), the router replaces the existing route in-place. This is known as an implicit withdrawal and avoids the latency of sending explicit teardown messages.

Import and Export Policies: The Operator’s Control Point

Routing policy is expressed through programmable filters executed at the boundary of the routing process:

[Peer Update] 
      |
      v
+-------------+
| Import Filter| ---> Drop (Reject) or Modify Attributes (e.g., set LOCAL_PREF)
+------+------+
       | Accept
       v
+-------------+
|   Adj-RIB-In |
+------+------+
       |
       v
+--------------------+
| Decision Process   | ---> Selects Best Path
+------+-------------+
       |
       v
+-------------+
|    Loc-RIB   | ---> Installs into Forwarding Information Base (FIB)
+------+------+
       |
       v
+-------------+
| Export Filter| ---> Suppress (Reject) or Modify Attributes (e.g., prepend AS)
+------+------+
       | Accept
       v
+-------------+
| Adj-RIB-Out | ---> Transmit UPDATE to Neighbor
+-------------+
  1. Import Policy: Evaluates inbound UPDATE messages before they are processed by the BGP decision engine. Operators can reject unauthorized prefixes, adjust LOCAL_PREF to prioritize specific uplinks, or rewrite communities.
  2. Export Policy: Evaluates best routes from the Loc-RIB before they are formatted into UPDATE messages and sent to neighbors. Export policies enforce transit boundaries, preventing customer routes from leaking to unauthorized peers.

Propagation Through the Transit Web

When an origin AS announces a prefix, the announcement cascades outward through transit tiers. A Tier-1 transit provider receiving the announcement over eBGP accepts it, prepends its own ASN to the AS_PATH, updates the NEXT_HOP, and propagates the update across its global backbone using iBGP. From there, edge routers advertise the prefix to downstream Tier-2 providers and peering networks via eBGP.

Within minutes, the prefix populates the routing tables of tens of thousands of routers worldwide. Crucially, unless explicit filtering is configured at each hop, routers along the path accept and propagate the announcement without any mathematical proof that the originating AS actually owns the prefix.