BGP is the only protocol that stitches tens of thousands of independently operated networks into one forwarding table. It carries reachability, but what it really carries is policy: each network says which prefixes it originates, which neighbours it learned them from, and — through filters — which ones it is willing to pass on.

The tension is that this table is built on trust between parties who have no contract with each other. Nothing validates an announcement before it propagates, so a typo or a misconfigured filter is global within minutes and stays that way until a human notices.

The AS path is a loop check and a policy signal at once

On egress an eBGP speaker prepends its own AS number, and a receiver drops any update whose AS_PATH already contains its own AS. That is the entire loop-prevention mechanism, and it is why a route cannot be re-imported around a circle. iBGP does not prepend, which is why an iBGP-learned route carries the same AS_PATH as the eBGP route that brought it into the AS, and why an AS needs a full iBGP mesh or route reflectors to distribute it.

The same field does two more jobs. Operators filter on it — reject anything containing a peer’s AS, accept only routes whose path ends in a customer’s AS — and path selection compares its length. One field, three responsibilities, and they conflict: prepending to make a path less attractive also makes it look like a route your filters should reject.

Why the table is about a million prefixes

The real numbers, from the CIDR Report snapshot taken for this article: 1,080,189 IPv4 prefixes, or 597,258 if you collapse everything that can be aggregated. Amazon alone originates 18,025 prefixes, of which 15,759 are more-specifics of larger blocks. Roughly half the table is more-specifics of address space that is already announced.

That is a policy artifact, not a topology artifact. Multihoming creates a more-specific per provider, traffic engineering creates them per path, and a customer who wants their own routing decisions creates one more. Aggregation would halve the table, and nobody does it, because every one of those more-specifics is doing a job.

Path selection is a fixed order, not a distance

BGP picks a path by walking a list and stopping at the first step that breaks the tie: highest weight, then highest local preference, then locally originated, then shortest AS path, then lowest origin type, then lowest MED, then eBGP over iBGP, then lowest IGP cost to the next hop, then lowest router ID. Weight and local preference are local to one router or one AS and never travel in an update.

Running that over four candidate paths for one prefix: the decision lands on weight, because a weight of 100 beats 0 before anything else is read. Remove the weights and the decision moves to local preference. Remove local preference as well and it moves to AS-path length, where a two-AS path beats a three-AS path. The shortest path is step four of nine, which is why “BGP picks the shortest route” is not a useful statement.

When it breaks

The classic incident shape is a leaked more-specific that hijacks traffic. An unrelated AS originates 198.51.100.128/25 inside someone else’s 198.51.100.0/24, and longest-prefix-match hands it exactly half the victim’s address space — 128 of 256 addresses — with no withdrawal, no error, and the legitimate /24 still sitting in every table. It presents as partial unreachability and traffic appearing somewhere unexpected, and it is the shape documented in RFC 7908. RPKI origin validation is the mitigation, but it only answers whether an AS is allowed to originate a prefix; a ROA’s maxLength must cover the more-specific, and a forged AS path with a valid origin still validates.

The second failure is the table outgrowing the hardware. A device with 1,000,000 IPv4 FIB entries is already 80,189 prefixes short of today’s table; at 1,200,000 it fits. When a FIB fills, the router keeps the sessions up and stops installing routes — some prefixes move to software forwarding, others are dropped, and the blast radius is that unrelated destinations stop working while BGP looks perfectly healthy.

Check it quickly

Confirm what your router actually believes about a prefix:

show bgp ipv4 unicast summary
show bgp ipv4 unicast 198.51.100.0/24
show bgp ipv4 unicast 198.51.100.0/24 longer-prefixes
show ip route 198.51.100.200

The first prints the total prefix count, which is how you notice a peer dumping routes at you. The second and third together show whether a more-specific exists and who originates it — a /25 you do not recognise is the whole incident. The fourth is the verdict the forwarding engine reached, and if it disagrees with what you expected from the first three, the hijack is already live.

Sources