What is BGP? Border Gateway Protocol Explained

The internet is not one network but tens of thousands of independently operated ones, each identified by an Autonomous System Number. Inside its own network an operator can route however it likes. Between networks, everyone needs a common language to say "I can reach these addresses" and "send that traffic to me". That language is BGP version 4, specified in RFC 4271. It is deliberately simple at its core: neighbors exchange reachability information, and each network applies its own policy to decide which routes to use and which to pass on.

Two BGP routers that exchange routes are called peers or neighbors. They are configured explicitly on both sides - BGP-4 has no built-in neighbor discovery - and talk over a TCP connection on port 179. A session between routers in different autonomous systems is external BGP (eBGP); a session between routers of the same network, used to distribute external routes internally, is internal BGP (iBGP).

A session moves through a small state machine (Idle, Connect, Active, OpenSent, OpenConfirm, Established). RFC 4271 defines four message types (a fifth, ROUTE-REFRESH from RFC 2918, is widely supported):

• OPEN - sent right after the TCP connection is up; it starts the session and negotiates parameters such as the ASN of each side, the hold time and optional capabilities (for example 4-byte ASNs or IPv6 support).
• UPDATE - exchanged once the session is Established; announces new routes or withdraws routes that are no longer reachable. This is where all the routing information travels.
• KEEPALIVE - sent periodically to show the peer is still alive. If no KEEPALIVE or UPDATE arrives within the hold time (commonly 90 or 180 seconds, depending on the implementation), the session is torn down and all its routes are withdrawn.
• NOTIFICATION - reports an error and closes the session.

After the initial exchange of the full table, BGP is incremental: peers only send changes. That is why a single misconfiguration can spread worldwide within minutes - every network that accepts a new route passes it on as an update to its own neighbors.

A route is a prefix - a block of addresses such as 203.0.113.0/24 - plus a set of path attributes that describe how to reach it and how attractive the route is. The most important attributes are:

Each network that re-advertises a route to an eBGP neighbor prepends its own ASN to the AS_PATH. The path therefore grows by one hop per network and ends at the origin AS, the network that first announced the prefix.

This is what a route looks like on a router running the open-source FRRouting suite. The prefix and ASNs are from the documentation ranges, but the format is what you will see on a real router:

router# show bgp ipv4 unicast 203.0.113.0/24
BGP routing table entry for 203.0.113.0/24
Paths: (2 available, best #1, table default)
  64501 64500
    198.51.100.1 from 198.51.100.1 (198.51.100.1)
      Origin IGP, metric 0, localpref 200, valid, external, best (Local Pref)
      Community: 64496:100
  64502 64503 64500
    198.51.100.9 from 198.51.100.9 (198.51.100.9)
      Origin IGP, localpref 100, valid, external

The router knows two paths to 203.0.113.0/24. Both end in AS64500, the origin. The first path is two hops long and arrives from the neighbor at 198.51.100.1; the second is three hops long. The router picked path 1, and the reason is given in brackets: its local preference of 200 beats 100. Local preference is checked before path length, so even if path 2 were shorter, path 1 would still win.

You can look at the same information for real prefixes without router access. The BGP lookup and the prefix pages show the origin AS, the RPKI status and the registration of any announced prefix. From a terminal, curl returns a plain-text summary:

$ curl ipctl.io/prefix/1.1.1.0/24
Prefix:          1.1.1.0/24
Origin AS:       AS13335
RIR:             APNIC
RPKI:            valid
...

When a router learns several routes for the same prefix, it runs the best-path selection algorithm and installs exactly one of them. Vendors differ in details and add their own steps (Cisco's "weight" is the best-known example), but the core order defined by RFC 4271 and common practice is:

1. Highest LOCAL_PREF - the network's own business preference.
2. Locally originated routes over learned ones.
3. Shortest AS_PATH.
4. Lowest ORIGIN type (IGP before EGP before incomplete).
5. Lowest MED, normally only compared between routes from the same neighboring AS.
6. eBGP-learned over iBGP-learned routes.
7. Lowest IGP cost to the NEXT_HOP ("hot-potato" routing: hand traffic off as early as possible).
8. Tie-breakers such as the oldest route or the lowest router ID.

Separately from best-path selection, forwarding always uses the longest matching prefix. If a router has both 203.0.113.0/24 and a more-specific 203.0.113.128/25, traffic to 203.0.113.200 follows the /25, no matter how attractive the /24 is. More-specific announcements are a legitimate traffic-engineering tool - and also the technique behind sub-prefix BGP hijacks, the most effective kind.

BGP itself has no notion of business relationships, but the internet runs on them. Between two networks there are essentially two kinds of link:

• Customer to provider (transit): the customer pays the provider to carry its traffic to and from the whole internet. The provider announces the customer's routes to everyone, and gives the customer all routes it knows.
• Peer to peer (peering): two networks exchange traffic between their own customers, usually without payment, often at an Internet Exchange Point. Each side only announces its own and its customers' routes to the other.

These relationships lead to simple export rules. Routes learned from customers are announced to everyone; routes learned from peers or providers are announced only to customers. A path that follows these rules is called valley-free: it goes up from customer to provider zero or more times, crosses at most one peering link, and then only goes down from provider to customer.

When a network breaks these rules - for example by passing routes learned from one provider on to another provider - it creates a route leak. Leaks are one of the most common causes of large routing incidents, and detecting them is the purpose of ASPA.

BGP was designed when the networks connected to it largely trusted each other. By default a router believes what its neighbors tell it: there is no built-in check that the origin AS actually holds the announced prefix, or that the AS-path is real. Three failure modes follow from that:

• Prefix hijacks: a network announces address space it does not hold, either the exact prefix or a more-specific of it, and attracts traffic meant for someone else.
• Route leaks: a network re-announces routes in violation of the export rules above, typically sending a large share of traffic through a network that cannot carry it.
• Path manipulation: a network forges or alters the AS-path so a route looks shorter or more legitimate than it is.

Most incidents are accidents - a typo in a prefix filter, a missing export policy - rather than attacks. The effect is the same, though: traffic is blackholed, slowed down or routed through networks it should never touch.

There is no single fix; operators combine several layers:

• Prefix filtering: providers accept from each customer only the prefixes that customer is entitled to announce, often built from Internet Routing Registry (IRR) data.
• RPKI Route Origin Validation: address holders publish signed ROAs that say which AS may originate their prefixes, and routers drop announcements that contradict them. See RPKI explained.
• ASPA: networks publish their authorized upstream providers, so routers can detect AS-paths that are not valley-free. See ASPA explained.
• BGP roles and the Only-to-Customer attribute (RFC 9234): neighbors declare their relationship in the session itself, which prevents many leaks at the source.
• Maximum-prefix limits on sessions, so a neighbor that suddenly announces far more routes than expected is shut down instead of flooding the network.

Checking your own exposure is straightforward: look up your ASN to see which prefixes are visible and whether each one is RPKI-valid, check that you have ROAs for all of them, and publish an ASPA object listing your providers.