SubnetLayerProtocols

What BGP Does Not Check

Communities, trust, and why a wrong announcement is indistinguishable from a right one

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:
Every other protocol in this course fails in ways you can see. A checksum does not match, a port is closed, a certificate names the wrong site — the packets tell you. BGP has a category of failure that packets cannot tell you about, because a false announcement is byte-for-byte identical to a true one. There is no field that carries entitlement, no signature, no authority. A route is believed because a peer you configured sent it. Knowing that is not cynicism. It is the difference between reading a BGP table as fact and reading it as testimony.

Watch these fields in the lab: bgp.type

Community
A tag attached to a route and carried with it, written as two numbers. A handful have standard meanings; the rest mean whatever two networks agreed, and the protocol acts on none of them by itself.
Prefix filter
A locally configured list of what a neighbour may announce. Effective, and only as good as whoever maintains the list.
RPKI origin validation
A signed statement from an address holder saying which AS may originate a prefix. Validates the origin — the last AS in the path — and nothing else about the path.
Route leak
An announcement that is technically valid and violates the business relationships it crosses, such as a customer re-announcing one provider's routes to another.

✓ 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.

A BGP session is authenticated with TCP-AO. What is now protected?

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.