BGP

Border Gateway Protocol · Routing (control plane)

Between organisations, shortest path is the wrong goal: what matters is policy — who you are willing to carry traffic for, and who you would rather pay. BGP carries routes with attributes describing the path, and each network applies its own rules to decide which to believe.

Understand these first

TCP — Turns unreliable packets into a reliable, ordered byte stream.IPv4 — Addresses and forwards packets across networks, with no promises about delivery.

Why does this protocol exist?: Inside one organisation, everyone can share a full map and agree on the shortest path. Between organisations that breaks down: nobody will publish their internal topology, and shortest is not what anyone is optimising for.
Which problem does it solve?: Exchange reachability between independently administered networks, with each side keeping complete local control over what it accepts, what it announces, and what it prefers.
Who participates?: Two BGP speakers, explicitly configured with each other's addresses. Peers, not client and server — though whoever's TCP connection succeeds first carries the session.
Which layer uses it?: Application layer, over a TCP session to port 179.
What does it depend on?: TCP for reliability and ordering (which is why BGP has no acknowledgements of its own), and an IGP or a connected route to make the peer's address reachable in the first place.
What depends on it?: The global routing table. This is how the internet knows where anything is.
What state does each participant maintain?: A session state per peer (Idle, Connect, OpenSent, OpenConfirm, Established), an Adj-RIB-In of everything each peer sent, the local RIB of what was selected, and what was advertised outward. Plus hold and keepalive timers.
Which fields matter?: OPEN: myAS / holdTime / bgpIdentifier — Checked before anything else. A mismatched AS number produces a NOTIFICATION and the session never opens.
UPDATE: AS_PATH — The list of AS numbers the route has crossed. Seeing your own in it means a loop, and the route is discarded.
UPDATE: NEXT_HOP — Where to send traffic for this prefix. If it is not reachable, the route cannot be used however good it looks.
UPDATE: LOCAL_PREF — Local policy, compared before AS path length. This is where a business decision becomes a routing decision.
UPDATE: withdrawn routes — Explicit removal. BGP announces changes rather than resending state, so a withdrawal is the only way a route goes away.
What does normal behaviour look like?: TCP handshake to port 179, OPEN both ways, KEEPALIVE, then the full table as UPDATEs, then near-silence with periodic keepalives and only incremental changes.
What does failure look like?: A session that never leaves Connect (TCP is not reaching port 179). A NOTIFICATION and immediate teardown (a parameter was rejected — a wrong AS number is the classic). A hold timer expiring (keepalives stopped). Or a session that is Established while a specific prefix is missing, which is a policy question rather than a session one.
How can I prove the diagnosis from packets?: Separate the session from the routes. Is the session Established? If not, it is TCP or OPEN. If it is, look in the Adj-RIB-In: if the prefix is not there, the peer never sent it; if it is there and not selected, the decision process will name the step that rejected it.
How does it interact with the rest of the stack?: BGP is the clearest example in this curriculum of a protocol layered on another: it gets reliability from TCP, and its peers can be many hops away because TCP is routed. It feeds routes into the same RIB that OSPF and static routes feed, and administrative distance decides between them.

Worth knowing

Neighbours are typed in by a person, not discovered, because who you exchange routing with must be an intentional decision. That relationship is often commercial, but it is just as often internal (iBGP inside one organisation), or a private interconnect, or a lab.

Guided course — 6 lessons

Read in order. Every lesson pauses the capture on the packets it is talking about, and every one reads at three levels — so the time below is an estimate from the number of steps, not a measurement of anybody.

Troubleshooting labs — 1

A symptom, a capture, and no answer given. Each one is a lesson from the course above, listed again here because the diagnosis is worth coming back for.

Received, Chosen, Announced

Decide, from the capture, whether the problem is at their end or at yours.

Packet explorer — 13 scenarios, no coaching

How a peering comes up

Three networks, configured by hand to talk to each other — BGP has no discovery. Watch the order: a TCP handshake to port 179, then OPEN, then KEEPALIVE, and only then a single route. Nothing is exchanged before the connection is up.

The same prefix, heard twice

AS 65001 hears about 203.0.113.0/24 from AS 65003 directly and from AS 65002 in transit. Read the route selection: the AS path decides, and note what it counts — organisations crossed, not routers or distance.

Preferring the longer path on purpose

An operator sets LOCAL_PREF 200 on everything heard from AS 65002. The route through AS 65002 now wins despite a longer AS path — because LOCAL_PREF is compared FIRST, and the AS path is never reached. This is how a network prefers a cheaper transit provider over a shorter route.

When a peering goes away

The direct session between AS 65001 and AS 65003 is shut down. Everything learned through it is withdrawn — a BGP route lives only as long as somebody vouches for it — and the transit path takes over without anyone re-announcing anything.

A route that is deliberately not offered

AS 65003 will not advertise anything to AS 65002. The transit path simply never exists, and AS 65001 has exactly one way to reach the content network. No failure, no error — a policy decision, which is what most of BGP actually is.

The wrong AS number

R1 is configured to peer with AS 65099 on the direct link; R3 answers that it is AS 65003. The TCP connection succeeds and the session still never opens — the parameter check happens in the OPEN, and a NOTIFICATION follows. Watch how far the session gets before it fails, and how the transit path carries the traffic anyway.

A session that dies of silence

The direct link to AS 65003 fails while the session is up. No shutdown, no NOTIFICATION — just nothing arriving. R1 waits out the 9-second hold time before believing it, and only then withdraws the routes. The delay is not a bug: it is the protocol refusing to tear down a session over one missed packet.

Peering with an address nobody owns

R1 is configured to peer with 10.0.13.3. R3's address on that link is 10.0.13.2, and nothing answers for .3. Watch how far this gets compared with the AS-number mismatch — there is no OPEN here, because there is no connection to carry one.

Port 179 filtered in the middle

A firewall on the direct link discards anything addressed to TCP port 179. Both routers are configured perfectly and neither will ever say so. The only evidence is SYNs leaving and nothing coming back — BGP's own messages never exist.

A route that arrives and is thrown away

AS 65001 has an inbound filter denying 203.0.113.0/24 from its direct peer. The session is healthy, the UPDATE arrives, and the prefix appears in no table. Compare the Adj-RIB-In of this session with the transit one.

Four networks announced as one

AS 65003 holds four /26s and tells the world about a single /24. Count the UPDATEs and then count the entries in R1's table. This is why the global routing table is measured in hundreds of thousands of routes rather than tens of millions — and why R1 can no longer treat the four networks differently.

The route that stops halfway through an AS

Three routers in AS 65010, chained by iBGP. RA learns 203.0.113.0/24 from AS 65003 and RB learns it from RA. Open RC's table: nothing. A route learned from an internal peer is never passed to another internal peer, because inside one AS the AS path does not grow and nothing would stop a loop.

One router allowed to pass routes on

The same three routers, with RB declared a route reflector and RA and RC declared its clients. RB may now do the one thing the previous lab showed it refusing to do, and RC has a route. Compare the two captures: the packets are almost identical and one table is not.

Reference material

The terms this module introduces, and the specifications behind them. Both lists come from the lessons themselves rather than from a list kept beside them.

BGP Autonomous system (AS)BGP session AS_PATH LOCAL_PREF BGP decision process

BGP — end of module →

That you can read a path selection as a policy decision, and describe what BGP does and does not verify.

Where BGP sits in a real request

These captures run BGP as one stage of a longer chain, and hand its result to whatever comes next.

A routed enterprise application, end to end

The office journeys stop at the gateway. This one starts before it: two routing protocols fill one routing table, then ARP and DNS do their usual jobs, then an application opens a connection across the result. Nothing in the application's packets refers to a routing protocol — and that is what the routing protocols are for.

Control plane and data plane

Two captures of one network. In the first, the routers talk only to each other and no user traffic exists at all. In the second, user traffic crosses the network — while the routing protocols carry on saying hello in the background, because they never stop. Not one of their packets carries a byte of anybody's data. OSPF and BGP create forwarding information; the routing table selects a path; IP forwards packets; TCP, TLS and HTTP carry the application. Each of those depends on the one before it having already finished.

Diagnosis: the intranet is gone, the internet is fine

External sites load. The internal application server does not respond at all. That split — outside works, inside does not — narrows this before you open a single packet.

Diagnosis: the link is up and the routes never arrive

The circuit to the provider is up and the interface counters climb. Nothing outside the company is reachable, and the internal network is completely unaffected.

Diagnosis: nothing is broken and it still does not work

Every device is up. Every protocol session is established. Every configuration matches the documentation. The application is unreachable anyway — this is the case that teaches what a routing table actually is.