BGP

Peers are configured by hand and talk over TCP port 179. Each AS announces its networks; each AS passing an announcement on adds its number to the AS path. BGP prefers the shortest AS path by default and ignores link speed. A silent peer is dropped after the hold time, and its routes withdrawn.

How BGP works, step by step

The internet is tens of thousands of networks run by different organisations, each an autonomous system (AS) with a number of its own. Inside, an AS routes however it likes. Between them, routers speak BGP-4 (RFC 4271).

1. Peers are configured, not discovered. Each side names the other's address and AS number. One opens a TCP connection to port 179; everything else rides on it.
2. OPEN. Each sends its AS number, its BGP identifier (router ID), the hold time it proposes and its capabilities, such as 4-byte AS numbers or IPv6. The session moves through the states Idle, Connect, Active, OpenSent and OpenConfirm to Established.
3. UPDATE. Each announces the prefixes it can deliver to, with path attributes: the AS path, the next hop, the origin, and optional ones such as MED and communities. An UPDATE can also withdraw prefixes that are no longer reachable.
4. Passing it on. A router that announces a route to another AS puts its own AS number in front of the path. A router that sees its own AS number already in a path drops the route: that is BGP's loop prevention.
5. Choosing. With several paths to one prefix, each router picks one. In order, the main rules are: highest local preference, a route it originated itself, shortest AS path, lowest origin type, lowest MED, eBGP over iBGP, closest next hop, then tie-breakers such as the lowest router ID. Link speed is not on the list.
6. KEEPALIVE. Sent every third of the hold time. If nothing arrives for the hold time, the router sends a NOTIFICATION, closes the session and withdraws every route learned over it.

Because the choice depends on policy, organisations steer traffic by what they announce. A network that wants less traffic over one link prepends its own AS number several times on announcements sent there, making that path look longer.

What it looks like on a Linux machine

In the BGP lab three FRR routers play a home ISP (AS 65001), a transit ISP (AS 65002) and a content provider (AS 65003). Numbers 64512 to 65534 are private AS numbers, BGP's equivalent of 10.x. The session is an ordinary TCP connection:

$ ss -tn state established '( sport = :179 or dport = :179 )'
Recv-Q Send-Q   Local Address:Port    Peer Address:Port
0      0            10.0.13.2:179        10.0.13.3:41528
0      0            10.0.12.2:52314      10.0.12.3:179

The BGP table holds every path heard, not just the best:

$ vtysh -c 'show bgp ipv4 unicast'
    Network          Next Hop            Metric LocPrf Weight Path
 *> 10.0.1.0/24      0.0.0.0                  0         32768 i
 *> 10.0.3.0/24      10.0.13.3                0             0 65003 i
 *                   10.0.12.3                              0 65002 65003 i

* is a valid path, > the best one, i the origin (announced with a network statement). The direct path, 65003, beats 65002 65003 through transit. The winner goes into the kernel, and ip route shows it as proto bgp. When the content provider prepends 65003 65003 on the peering link, the transit path becomes shorter and traffic moves. Cut the link and, after the hold time, the backup path is installed with no one touching a route.

What goes wrong, and how you see it

The session never comes up. show bgp summary shows Active or Idle instead of a prefix count. Check that each side names the other's address and AS correctly, and that TCP port 179 is reachable. A wrong AS number is answered with a NOTIFICATION (Bad Peer AS) and the session resets.

Up, but no routes. Many implementations, FRR among them, follow RFC 8212 and exchange nothing with an eBGP peer until a policy allows it. The summary shows (Policy) where the count would be.

Routes received, not used. The best path's next hop must be reachable through the router's own table. A next hop that is not, often inside iBGP, leaves the route in the BGP table and out of the kernel.

Slow failover. With a 180-second hold time, a silent link failure takes three minutes to notice. BFD cuts it to under a second.

Someone else's routes. BGP believes what peers announce. A network that announces prefixes it does not own, or passes a peer's routes where it should not, draws traffic its way: a hijack or a route leak. Filters on what each customer may announce, and RPKI origin validation, are the defences.

Questions people ask

What is the difference between eBGP and iBGP? eBGP runs between different ASes; iBGP between routers of the same AS, to share what the edges learned. iBGP does not add to the AS path, so by default an iBGP router does not pass iBGP routes to other iBGP peers.

Why does BGP use TCP? It gives reliable, ordered delivery, so BGP can send only changes instead of repeating its whole table.

Is BGP a distance-vector protocol? It is called path-vector: each route carries the whole list of ASes, not just a distance.

See it on real machines