BGP Basics: How Internet Routing Works

Autonomous systems and prefixes

An autonomous system (AS) is a network, or group of networks, under one administrative control with one routing policy toward the rest of the Internet. Each AS has an autonomous system number (ASN). ASNs were originally 16-bit numbers; RFC 6793 extended them to 32 bits because the original pool was running out. ASNs and IP address blocks are handed out by the Regional Internet Registries, under the coordination of IANA's number resources function.

What an AS announces is a prefix: a block of addresses written in CIDR notation, such as 203.0.113.0/24 or 2001:db8:1000::/36. If CIDR is new to you, IP Addresses, Subnets and CIDR covers the notation. When an AS originates a prefix, it is telling the world "send packets for these addresses to me." Neighbors that accept the announcement add their own ASN to the path and pass it along, so each route arrives with a record of the networks it has crossed.

The examples in this guide use the documentation ASNs reserved by RFC 5398 (64496 to 64511) and documentation address ranges, so nothing here points at a real network.

How a BGP session works

Two BGP routers that exchange routes are called peers or neighbors. Unlike most routing protocols, BGP does not discover neighbors automatically. An operator configures each session by hand, naming the neighbor's address and ASN. The routers then open a TCP connection to port 179 and exchange a small set of message types.

After the initial exchange, BGP is incremental. Peers send their full tables once, then only changes. If no KEEPALIVE or UPDATE arrives within the negotiated hold time, the session is torn down and every route learned over it is withdrawn at once. That is why a flapping link or an overloaded router CPU can cause large, sudden shifts in traffic.

There are two flavors of session. External BGP (eBGP) runs between different autonomous systems, usually across a direct link at a data center or Internet exchange point. Internal BGP (iBGP) runs between routers inside the same AS so they all share the routes learned at the edge. Because iBGP routers do not re-advertise iBGP-learned routes to each other, large networks use route reflectors, described in RFC 4456, rather than a full mesh of sessions.

Path attributes and best-path selection

Each route carries path attributes. A router that hears several routes for the same prefix compares those attributes to pick one best path, installs it, and advertises only that path onward. The exact comparison order varies between router vendors and can be changed by local policy, so treat this as the common core rather than a fixed sequence:

After those come tie-breakers such as preferring eBGP over iBGP routes, the lowest interior cost to the next hop, and finally the lowest router ID. In practice, LOCAL_PREF and AS_PATH decide most outcomes, and LOCAL_PREF is where business policy lives.

Separately from BGP's choice between paths for the same prefix, the forwarding table always uses the longest matching prefix. If one neighbor announces 203.0.113.0/24 and another announces 203.0.113.0/25, packets to 203.0.113.10 follow the /25 no matter how good the /24 path looks. This rule is what makes some hijacks so effective, as explained in BGP Hijacks and RPKI.

Here is what a router's view of one prefix might look like, with two candidate paths:

router> show ip bgp 203.0.113.0/24
BGP routing table entry for 203.0.113.0/24
Paths: (2 available, best #1)
  64500 64510
    198.51.100.1 from 198.51.100.1 (198.51.100.1)
      Origin IGP, localpref 200, valid, external, best
  64501 64502 64510
    192.0.2.9 from 192.0.2.9 (192.0.2.9)
      Origin IGP, metric 0, localpref 100, valid, external

Both paths end in AS64510, the origin. The first wins because the operator gave routes from AS64500 a higher local preference; it would also have won on the shorter AS path.

Policy: customers, peers and transit

BGP's flexibility exists because routing on the Internet follows money and contracts. Most relationships between networks fall into a few patterns:

A typical operator sets the highest LOCAL_PREF on routes from paying customers, a middle value on routes from peers, and the lowest on routes from transit providers it pays. It also filters what it exports: customer routes go to everyone, but routes learned from one peer or provider are not passed to another peer or provider, because that would mean carrying traffic for free between two outside parties. When that filtering fails, the result is a route leak.

Good operators also filter what they accept, using prefix lists built from Internet Routing Registry data or RPKI, and set a maximum number of prefixes per session so a misconfigured neighbor cannot flood them with routes.

Why BGP matters for DNS

DNS depends on BGP in a few concrete ways. First, every query and answer is a packet that BGP-learned routes carry. If the prefix holding your authoritative name servers is withdrawn, the servers can be healthy and still unreachable, and resolvers will eventually return SERVFAIL for your zone. Large outages have happened exactly this way, when an operator withdrew the routes to its own name servers.

Second, anycast is a BGP technique. Root servers, TLD servers, public resolvers, and many DNS providers announce the same prefix from many locations, and each network's BGP decision picks which instance its users reach. That choice is driven by policy and AS path, not geography, so a user can reach a distant instance if that is what their provider's routing prefers. DNS Anycast Explained covers the DNS side of this design.

Third, BGP changes are not instant. A withdrawn or new route takes time to spread, and during that convergence window some networks may black-hole traffic or send it on a longer path. If you are moving name servers to new address space, announce the new prefix and confirm it is visible before you change NS records.

How DNS Panopticon helps

The ASN Lookup shows the origin AS and RPKI status for any address or prefix, every prefix an AS announces, and a graph of its upstream and downstream neighbours. Website Recon looks up each IP address a hostname resolves to in RDAP and reports the network and AS number that hold it, which tells you whose BGP announcements carry traffic to that name. It also flags when the visible addresses belong to a CDN, where anycast routing hides the origin. For the DNS records themselves, Domain Visualizer resolves a domain's public records live, including its NS set, so you can see which name servers a routing problem would affect.