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
▸Read an AS path and say what it does and does not count
▸Apply the decision process in order, and explain why the order is the whole point
▸Explain how the AS path prevents loops without any timer or counter
A metric is a number, and comparing numbers requires everyone to agree what the number means. Inside one organisation that works: OSPF cost is a configured number, conventionally derived from bandwidth, and everyone uses the same scale.
Between organisations, what number would you even compare? Your provider's idea of a good path involves their contracts, which you cannot see and would not agree with.
So BGP has no single end-to-end path cost comparable to an IGP metric. It does have metric-like attributes — MED is literally MULTI_EXIT_DISC and is compared — but they sit inside an ordered list of comparisons, several of whose entries are values a human sets deliberately. The list makes the outcome predictable; the knobs make it controllable.
✗ 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.
Before working through the list, one honest caveat. There is no single BGP decision process that every router on earth runs. RFC 4271 defines the core comparisons, most implementations follow them in the same order, and each vendor then adds steps of its own at the front and at the back.
SubnetLayer teaches one documented sequence so that the outcome of every lab is explainable. Read it as a correct order, not the order.
1SubnetLayer uses a documented teaching-grade decision sequence, and every lab result follows from it.
2Real implementations may add or reorder preliminary and tie-breaking steps — a proprietary weight, a preference for locally originated routes, extra multipath conditions.
3For a production network, consult your platform's own documentation for its actual sequence.
4In every implementation, BGP selects according to policy and attribute comparison — not measured speed, latency, or physical distance.
✓ 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.
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.