BGP concepts — autonomous systems, path vectors, and the policy that connects networks

BGP is the protocol that connects networks. Every Internet-visible prefix between organisations is exchanged through BGP. Every cloud provider peering with a customer is running BGP. Every multihomed edge that wants redundant transit runs BGP. Unlike OSPF — which is designed for a single administrative domain and trusts its participants — BGP is designed for the boundary between organisations, where trust is partial, policy is explicit, and prefixes are advertisements the receiver must filter.

This lesson covers what BGP is, the autonomous-system model it implements, the eBGP and iBGP distinction, the path-vector algorithm and the attributes that drive path selection, route filtering and prefix lists, and the policy model BGP enables.

What BGP is

BGP (Border Gateway Protocol) is a path-vector exterior gateway protocol standardised in RFC 4271 (BGP-4). The protocol’s distinguishing feature is its path vector: every BGP route carries the sequence of autonomous systems (ASes) it has traversed, and the receiver uses that vector to detect loops and to apply policy.

The model BGP implements:

• Autonomous systems (ASes) — every network on the Internet has an AS number (a 32-bit identifier today; originally 16-bit). An AS is a network under a single administrative control. BGP connects ASes; within an AS, an interior gateway protocol (OSPF, IS-IS, EIGRP, static) carries the routes.
• Path vector — every BGP UPDATE carries the AS path: the list of ASes the route has traversed. A router that sees its own AS in the path rejects the route (loop detection).
• Policy — BGP is policy-based. The receiver of a route decides whether to accept it, whether to advertise it to other peers, and what attributes to attach. The decision is explicit; the protocol does not impose a single “best” algorithm.

The trade-off vs link-state (OSPF): BGP is much slower to converge (minutes vs seconds) because the policy decisions are not as simple as “compute the shortest path”. BGP makes the trade-off because the Internet needs policy: an organisation may want to prefer one transit provider over another, may want to refuse routes from a particular peer, may want to advertise only its own prefixes and not customer prefixes.

eBGP and iBGP

BGP has two flavours, distinguished by the topology:

The topology rules of iBGP are the surprising one: iBGP routers do not advertise routes learned from one iBGP peer to another iBGP peer (the “iBGP split-horizon rule”). The result: every iBGP router in an AS must have a session with every other iBGP router — a full mesh. A network with 10 iBGP routers has 45 sessions; with 100, it has 4,950. The protocol solves this with route reflectors (one or more routers allowed to re-advertise iBGP routes) or confederations (sub-ASes within a larger AS).

A firewall that runs BGP with an upstream ISP runs eBGP. If the firewall is part of a multi-router AS that also runs iBGP among its routers, the firewall may also run iBGP to receive routes from internal routers.

The path-vector algorithm

When a BGP speaker receives an UPDATE, it processes the route through this pipeline:

1. Filter (in) — accept or reject the route based on the inbound filter (prefix list, route map, AS path filter).
2. Install in Adj-RIBs-In — the unfiltered route is held; the filtered-accepted route is held.
3. Decision process — for the prefix, pick the best route among all candidates (from this peer and from other peers). The decision process uses the attributes.
4. Filter (out) — for the best route, decide what to advertise to each peer (based on the outbound filter).
5. Send UPDATE — the advertised route has the local AS prepended to the AS path, the next hop set to the local IP, and any outbound policy applied.

The decision process is the heart of BGP. The operator who understands the decision process can predict what BGP will do; the operator who does not is at the mercy of defaults.

BGP attributes and the decision process

BGP routes carry attributes. The well-known mandatory attributes:

The decision process evaluates these in order. The first attribute to differ breaks the tie; the remaining attributes are not evaluated for that prefix.

The production discipline:

• Local Preference sets the operator’s preference for outbound traffic. “I prefer transit provider A over provider B” is a local-preference statement.
• AS Path length sets the operator’s preference for inbound traffic (when the upstream applies it on egress). A shorter AS path is preferred.
• MED sets the operator’s preference for inbound traffic at a multihomed site. “Please send me traffic via this link” is a MED statement.

Route filtering with prefix lists and route maps

BGP without filtering is dangerous. The two filter mechanisms:

• Prefix list — a list of prefixes (and prefix lengths) that match or do not match. Used to filter inbound (what the operator is willing to accept) and outbound (what the operator is willing to send). A prefix list with a single entry “permit 192.0.2.0/24” matches exactly that prefix; “permit 192.0.2.0/24 le 24” matches that prefix and any more-specific (longer) prefix within it.
• Route map — a sequence of match/set statements. The match clauses can match on prefix list, AS path, community, MED, and others. The set clauses can modify attributes (Local Preference, MED, community) or accept/deny the route. A route map with “match ip address prefix-list MY-OWN-PREFIXES; set community no-export” is a typical “send my own prefixes with the no-export community so the receiver does not re-advertise”.

The operator who configures BGP without an inbound prefix list has accepted every route the peer sent. The operator who configures BGP without an outbound prefix list or route map has sent every route they have to the peer.

bgp-node# vtysh -c 'show bgp ipv4 unicast summary'; echo '---'; vtysh -c 'show bgp ipv4 unicast neighbors 198.51.100.1 routes'

Neighbor        V    AS   MsgRcvd  MsgSent  Up/Down   State/PfxRcd
198.51.100.1    4  64512      1247      892   03:45:12      42

---
Network          Next Hop            Metric LocPrf Weight Path
*> 192.0.2.0/24    198.51.100.1             0    100      0 64512 65001 i
*> 192.0.2.128/25  198.51.100.1             0    100      0 64512 65001 i
*> 198.51.100.0/24 198.51.100.1             0    100      0 64512 i

The policy model BGP enables

BGP is policy. The protocol does not compute “the best path” — it computes “the best path according to my local policy”. The policy is expressed as:

• Prefix lists that say “accept these prefixes from this peer” and “send these prefixes to this peer”.
• Route maps that say “if the prefix matches X, set Local Preference to Y”.
• Communities that propagate policy across AS boundaries — “tag routes with community 65001:100 and I (AS 65001) will set their Local Preference to 100 when I see them”.
• AS path prepending that artificially lengthens the AS path to make a route less preferred: “send my route with my AS prepended three times so upstream B prefers upstream A”.

The operator who configures BGP without policy has accepted whatever the peer sends and sent whatever the local routing table has — including the peer’s own routes (a route leak) and prefixes the operator does not own.

Summary

• BGP is a path-vector exterior gateway protocol; it connects autonomous systems and implements policy.
• eBGP is between ASes; iBGP is within an AS and requires full mesh, route reflection, or confederation.
• The path-vector carries the AS path; a router rejects routes containing its own AS (loop detection).
• The decision process has nine steps, evaluated in order: Weight, Local Pref, Local Origin, AS Path, Origin, MED, eBGP-over-iBGP, IGP cost, Router ID.
• Filter inbound (prefix list) and outbound (route map). Every BGP session must have both.
• The operator who runs BGP without filtering accepts whatever the peer sends — a hijack waiting to happen.