BGP exchanges reachability between independently operated networks, but there is no single authoritative Internet forwarding table. Each router learns a policy-filtered view, chooses routes, and attempts to install usable next hops. Two routers can legitimately select different paths to the same prefix. Understanding BGP means separating announcements, selection policy, and packet forwarding rather than treating them as one universal answer.

The AS path carries history and policy

In ordinary eBGP operation, a speaker prepends its AS number when advertising a route externally. A receiver normally excludes paths containing its own AS to avoid inter-AS loops. There are configured exceptions and protocol extensions. Inside an AS, iBGP does not normally add another AS number; its advertisement restrictions and route-reflector rules address a different loop problem.

AS_PATH is also a policy input and a selection attribute. Repeated prepending can make one route less attractive where path length matters, but cannot override another network’s higher-priority local policy. There is no general rule that prepending makes a route fail filtering. Filters must be understood in their actual operator and customer context.

LOCAL_PREF is an attribute distributed to internal BGP peers, normally not to external peers. Weight, where an implementation provides it, is router-local and is not a standard BGP path attribute. Conflating these two controls hides an important distinction: a local preference change can influence decisions across the AS, while a weight change generally affects one router.

Compare the same prefix first

A router’s best-path process compares candidate paths for the same prefix. The exact sequence depends on the implementation and configuration, including eligibility, local policy, AS-path length, MED comparison rules, and next-hop reachability. A vendor’s weight-first list is not the complete protocol definition. MED is commonly compared within the same neighboring AS, with configurable exceptions.

Forwarding then performs longest-prefix matching over the installed destination routes. A /25 and its covering /24 do not compete through the same best-path tie-break list. If both are accepted and installed, the /25 matches its half of the address range even if the /24 has a shorter AS path. Policy routing and other forwarding features require additional inspection.

Table size likewise depends on the observation point, address family, and date. Distinct prefixes, all received paths, and hardware FIB entries are different counts. Aggregation can reduce some advertisements, but multihoming and traffic engineering may require specific routes. An address-only aggregation estimate is not proof that every corresponding policy can be preserved.

When it breaks

An unauthorized origin announcement is a prefix hijack; a route leak exports learned reachability beyond its intended policy scope. They can overlap, but are not synonyms. The hypothetical /25 below illustrates lookup only: real networks may reject it through prefix-length, origin, or customer filters. An unfamiliar more-specific deserves investigation, not an immediate conclusion that an attack is live.

RPKI origin validation checks the announced prefix, authorized origin, and permitted maximum length against validated records. It does not authenticate the entire AS path or determine every export relationship. Valid-origin routes can still be leaked. Combine origin validation with appropriately scoped import and export policy, and monitor changes rather than assuming all updates propagate unchecked.

A healthy session also does not prove successful forwarding installation. Hardware exhaustion, unresolved next hops, or programming failures can leave a control-plane route unusable. Failure behavior varies by platform; software fallback is not guaranteed. Capacity planning must use the device’s actual table partitions, supported features, and installation telemetry, not a universal million-entry threshold.

The article model first selects between paths for one prefix using local preference and AS-path length. A separate installed forwarding table uses longest-prefix matching: address 198.51.100.20 selects its /24 and 198.51.100.200 selects the covering range’s /25. Selection is distinct from installation and real forwarding.
Two distinct decisions: same-prefix path selection and cross-prefix forwarding lookup. The source fixture holds other conditions equal; it is not a router implementation or geographical shortest-path proof. No fixture was rerun.

Check it quickly

Run this Python 3 fixture with assertions enabled. The first half intentionally models only local preference and AS-path length, with every other selection condition held equal. The second half is an independent forwarding table. It uses documentation addresses and creates no sessions, listeners, or network announcements.

from ipaddress import ip_address, ip_network

paths = [
    {"name": "policy-first", "localpref": 200, "path": [64501, 64502, 64503]},
    {"name": "shorter", "localpref": 100, "path": [64504, 64503]},
]
def choose(candidates):
    return min(candidates, key=lambda p: (-p["localpref"], len(p["path"])))
assert choose(paths)["name"] == "policy-first"
paths[1]["localpref"] = 200
assert choose(paths)["name"] == "shorter"

routes = {ip_network("198.51.100.0/24"): "legitimate",
          ip_network("198.51.100.128/25"): "unexpected"}
def forward(address):
    matches = [p for p in routes if ip_address(address) in p]
    return routes[max(matches, key=lambda p: p.prefixlen)]
assert forward("198.51.100.20") == "legitimate"
assert forward("198.51.100.200") == "unexpected"
print("same prefix: local preference first, then path length")
print("different prefixes: lower half legitimate, upper half unexpected")

The longer path wins until local preference is equalized; then the shorter path wins. Separately, the lower address selects the legitimate /24, and the upper address selects the unexpected /25. These results explain two different decisions without claiming to implement a router. Real diagnosis must correlate received and advertised paths, selected routes, hardware installation, and permitted-client probes.

Sources