# Why BGP Can Prefer a Longer Path

Local policy can prefer a longer route\. Compare alternatives to the same prefix and verify the real traffic path\.

<https://rdpcore.blog/en/articles/bgp-path-selection>

![A longer illuminated route connects nodes while a shorter route remains idle\.](<https://rdpcore.blog/media/9263e4014fcd52941c65847a194158be/1600.jpg>)

Commercial and operational policy can outweigh AS path length\.

Two upstreams advertise the same prefix\. One AS path contains two autonomous systems; the other contains four\. The router selects the longer path\. This can be an ordinary expression of routing policy rather than a malfunction\.

## Separate preference from distance

BGP exchanges reachability information and attributes between autonomous systems\. A router first needs an eligible path, including a usable next hop\. Policy can assign different local preferences to eligible alternatives\. In a common implementation, a higher local preference is considered before comparing AS path length\. Exact selection details depend on the platform and configuration\.

Imagine a network setting local preference 200 for customer routes and 100 for transit routes\. A four\-AS customer path can beat a shorter transit path for the same prefix\. The operator may prefer a commercial relationship, capacity arrangement or traffic policy that is invisible to someone looking only at AS count\.

## Compare the right routes

Check the exact prefix first\. A more\-specific prefix wins a forwarding lookup over a less\-specific one regardless of a tempting AS path on the aggregate\. Compare attributes for alternatives to the same prefix, verify where policy was applied and inspect the selected next hop\. A BGP table entry and a successfully installed forwarding entry are related but different observations\.

AS path length counts routing domains, not fiber kilometers or queuing delay\. An AS can span continents, and a route that is shorter on paper can lead through congestion\.

## Verify the intended outcome

Measure actual traffic from the relevant source and at a representative time\. Return traffic may take another path\. Before changing policy, state which prefixes and peers should be affected, predict the selected routes and define rollback conditions\. An attractive traceroute is insufficient justification for moving an entire traffic class\.

## Further reading

[IETF RFC 4271: BGP\-4](<https://datatracker.ietf.org/doc/html/rfc4271>)

Related guide: [Read Traceroute Loss Without Blaming the Wrong Hop](<https://rdpcore.blog/en/articles/interpret-traceroute-loss>)\.
