Every protocol earlier on this shelf answers 'what is the best path through my network?'. BGP answers a different question: 'what paths am I willing to accept, and what am I willing to tell others?' — routing as policy, between organisations that do not trust each other. It carries the full Internet table (on the order of a million IPv4 prefixes) and does it with a design almost provocatively plain: no discovery, no periodic refresh, no topology map. Just TCP sessions between configured neighbours, incremental updates, and attributes on which policy operates.
BGP is path-vector: each route carries the ordered list of autonomous systems it has traversed (the AS-path). A router seeing its own AS number in a received path discards the route — loop prevention across organisations, no metrics required.
Sessions, states and the FSM
Neighbours are statically configured on both sides; the session is a TCP connection to port 179, which means BGP peers do not need to be adjacent — they need IP reachability, nothing more. The finite state machine runs Idle → Connect → Active → OpenSent → OpenConfirm → Established. Two states matter operationally: Established is the only state in which routes flow, and a session oscillating between Active and Idle means the TCP connection itself is failing — wrong address, no route to the peer, an ACL, or the neighbour not configured to peer back. Keepalives default to 60 seconds with a 180-second hold time.
R1(config)# router bgp 65001R1(config-router)# neighbor 203.0.113.2 remote-as 65002 ! eBGPR1(config-router)# neighbor 10.0.0.2 remote-as 65001 ! iBGPR1(config-router)# neighbor 10.0.0.2 update-source Loopback0R1# show bgp ipv4 unicast summaryNeighbor V AS MsgRcvd MsgSent Up/Down State/PfxRcd203.0.113.2 4 65002 8942 8871 2d04h 84210.0.0.2 4 65001 4211 4190 2d04h 12
eBGP vs iBGP: same protocol, different rules
- eBGP — peers in different ASes, usually directly connected (TTL 1 by default; multihop must be configured). The router rewrites next-hop to itself when advertising, and prepends its AS to the path.
- iBGP — peers in the same AS. The AS-path is not modified, so the AS-path loop check cannot work inside the AS; instead, the split-horizon rule applies: a route learned from one iBGP peer is never advertised to another iBGP peer.
- The consequence: every iBGP speaker must hear routes first-hand — a full mesh of n(n−1)/2 sessions, or the scaling alternatives (route reflectors, confederations) covered in chapter four.
- Two defaults that bite: next-hop is not rewritten on iBGP advertisement (the exit router's eBGP next-hop is carried inside, so either advertise that subnet into the IGP or configure next-hop-self), and iBGP typically peers loopback-to-loopback with update-source, so sessions survive any single link failure.
What BGP is for
Use an IGP for fast convergence inside a routing domain; use BGP wherever policy, scale or administrative boundaries dominate: Internet edge (multihoming to two ISPs with control over inbound and outbound paths), MPLS L3VPNs (the SP shelf of this library runs entirely on BGP address families), large data-centre fabrics (eBGP per rack has become the hyperscaler standard), and SD-WAN underlays. The protocol's genius is that new address families bolt on without changing the machinery — the same four message types (Open, Update, Keepalive, Notification) carry IPv4, IPv6, VPN and EVPN routes alike.
Bring up a pair of routers, break the session both ways — wrong remote-as, missing update-source, an ACL on port 179 — and watch the state machine tell you exactly what is wrong. Once routes flow, the interesting question is which of several paths BGP prefers, and that is the next chapter: the eleven-step best-path algorithm.