SubnetLayerProtocols

How Two Networks Agree to Talk

Configured by hand, carried over TCP, and silent until it is up

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

Before this lesson — it builds directly on:
OSPF works beautifully inside one organisation. Every router describes its links honestly, everyone builds the same map, everyone computes the same shortest paths. Now try that between competing companies. You would have to publish your internal topology to your competitors. You would have to trust their descriptions. And 'shortest' would be the wrong goal anyway — you do not want the shortest path, you want the path you are not paying for, or the one somebody is paying you to use. BGP is the protocol for that situation: minimal information, and every decision under local control. What it does not give you is safety. BGP believes what a configured peer tells it about reachability, with nothing in the protocol verifying the claim. That is why route hijacks work, and why filtering and RPKI exist — they are additions, not the base design.
Two shipping companies agreeing to carry each other's freight. Neither shows the other its depot layout, its staff rotas or its internal routes — that is nobody else's business. What they exchange is a list: *we can get things to these postcodes, and here is the chain of companies it would pass through on the way.* Each then decides for itself which offers to use, on grounds that have nothing to do with distance.
a shipping company
→ an autonomous system — one organisation's network
the list of postcodes
→ the prefixes advertised in an UPDATE
the chain of companies
→ the AS_PATH
the depot layout nobody shares
→ the internal topology an IGP would flood
deciding which offer to take
→ the decision process, driven by local policy

Where it breaks down: A shipping company can verify that a partner really does deliver to a postcode — parcels either arrive or they do not, and the invoice says so. Base BGP has no equivalent check: it accepts what a configured peer says about reachability with nothing verifying the claim. That gap is why route hijacks work and why RPKI was invented.

✗ Common misunderstanding: BGP picks the shortest or fastest path to a destination.

Why that's wrong: It measures nothing. There is no latency, no bandwidth and no distance anywhere in the protocol. The closest thing to a distance is the number of AS path entries, and even that is compared only after LOCAL_PREF — an operator's preference beats it outright. MED is a real metric attribute, but it is compared far down the list and usually only between routes from the same neighbouring AS.

Correct model: BGP applies a list of comparisons, several of which are knobs a human sets — and the list starts with local policy, which is why two vendors can order the early steps differently. The result expresses commercial policy at least as much as topology.

The packets prove it: In the LOCAL_PREF lab the route with an AS path of length 2 is installed over one of length 1, and the traffic visibly follows it.

✗ Common misunderstanding: All BGP routers eventually agree on the best path, the way OSPF routers do.

Why that's wrong: Each network applies its own policy to the same announcements. Two networks receiving identical information can legitimately install different routes, and neither is wrong.

Correct model: There is no global best path and no global agreement. Each AS optimises locally against constraints nobody else can see.

The packets prove it: In the LOCAL_PREF lab, AS 65001 prefers the transit path while AS 65002 and AS 65003 use the direct one. Every router is behaving correctly.

Watch these fields in the lab: bgp.myAs

Autonomous system (AS)glossary
One organisation's network, with a number. The unit BGP reasons about — it has no interest in what is inside one.
Peeringglossary
A configured relationship between two ASes. BGP defines no neighbour discovery, because routing relationships and policy must be intentional. The relationship may be settlement-free peering, customer-provider transit, a private interconnect, internal iBGP, or simply enterprise or lab policy.
eBGP / iBGPglossary
Between different ASes, or within one. The rules differ: the AS path is prepended only on the way out of an eBGP session.
Prefix
A block of addresses being advertised as reachable, e.g. 203.0.113.0/24. BGP announces reachability, not topology.
Attributeglossary
A value attached to an announcement — where it came from, which networks it crossed, how much this router likes it. Policy is written against these.

Watch these fields in the lab: bgp.type

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Why are BGP peers configured by hand rather than discovered?

What does BGP get from running over TCP?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.