Summary

  • LOCAL_PREF is an internal policy ranking, not a certificate of route quality. A higher value can outweigh a shorter AS path among eligible alternatives to the same prefix.
  • The receiving AS owns the assignment, including mappings from customer communities. That authority needs a bounded scope and evidence beyond the router on which the rule was changed.
  • Agreement on values does not prove agreement on forwarding. Alternatives, next-hop resolution, installed forwarding entries and packet paths determine whether the intended exit actually works.

Two roads, one local decision

Consider an illustrative network, not an observed incident. Border routers A and B offer feasible routes to the same prefix. Both initially carry LOCAL_PREF 100; A has the shorter AS path. Assume that any earlier comparison is tied—including Cisco weight where that implementation is used. An import rule raises B’s value to 200. For a speaker considering these alternatives under the documented ordering, B now wins before AS-path length can rescue A. Once that decision reaches the relevant internal speakers, traffic may move towards B.

Nothing in this example says B became faster, safer or cheaper. The organisation changed what it wanted. Nor does it establish that every router will select B: route visibility, additional policy and forwarding conditions still matter. This distinction is the reason a four-octet attribute belongs in an operational risk discussion, not merely in a list of BGP tie-breakers.

RFC 4271 defines LOCAL_PREF as an unsigned four-octet attribute carrying a degree of preference between internal peers. Higher is preferred; assignment for an external route comes from local policy. Ordinary EBGP neither exports it nor accepts it as the neighbour’s ranking instruction; confederations are an exception. The common protocol supplies those semantics, not a universal commercial hierarchy. RFC 4271, sections 4.3 and 5.1.5

The familiar 100 is convention, not a default mandated by that RFC. The implementation-experience record explicitly makes the distinction. A copied configuration can therefore import an assumption along with a number. What matters is the relationship between locally used classes, including values applied when no explicit action matches. RFC 4277, section 8

Admission is not preference

An operator needs two separate answers: may this route participate, and how should it rank if it does? Conflating them turns a commercial preference into a security exception. An accepted route with a high number is not thereby authenticated, origin-authorised or demonstrably reachable. Origin-validation results are separate evidence consumed by local policy, not an automatic universal ranking of exits. RFC 6483, section 3

There are implementation boundaries too. Cisco’s published procedure compares router-local weight before LOCAL_PREF and AS-path length afterwards. Junos checks next-hop resolution and routing-protocol preference before the local-preference comparison. Its routing-protocol preference is not LOCAL_PREF: similar display labels can conceal different selection mechanisms. Neither vendor’s complete order should be recast as a rule for every BGP implementation. Cisco best-path documentation, Junos path selection

The same-prefix qualification matters just as much. Giving an aggregate a high preference does not make it defeat a more-specific installed route for matching packet destinations. An experiment that checks the aggregate but probes an address covered by a more-specific route can produce a perfectly plausible, entirely misleading success report.

MED and AIGP answer different questions. MED can communicate a neighbour’s preference about entry points; LOCAL_PREF records the receiving AS’s own choice. AIGP is an accumulated metric used within a bounded administrative arrangement, not a synonym for a locally assigned rank. Treating any of these as a generic “better route” score hides who supplied the evidence and who authorised its effect.

The boundary is organisational, not physical

The word “local” can suggest a small blast radius. Here it describes an administrative boundary. A rule on one border router can influence choices elsewhere through IBGP. The affected population is the set of matching prefixes and address families, not the single destination used in a demonstration. A stale customer class or an overly broad match can therefore move traffic well beyond the engineer’s test case.

Yet coherent operation does not require an invented rule that every speaker must always hold identical values. RFC 4272 notes the absence of such a universal requirement. Deliberate regional policy can be legitimate. Separately, RFC 4271 warns that recomputing preference on an internally learned route may produce persistent loops. The operating test is whether the actual design forwards coherently, not whether a spreadsheet contains one number everywhere. RFC 4272, LOCAL_PREF analysis, RFC 4271, section 9.1.1

This is where apparently tidy policy can become untidy behaviour. One edge applies a new class while another retains the old mapping. A route reflector exposes a different candidate set from the one assumed by the change author. A regional exception rewrites preference without accounting for the next router’s forwarding choice. Each possibility warrants investigation; none can be diagnosed from a preferred-path screenshot alone.

Junos documents preservation of a present LOCAL_PREF by default and specific handling of 100 when exporting routes into BGP. That is useful implementation evidence, not permission to assume identical effective values at every observation point. Operators must distinguish received attributes, applied policy and advertised state. Junos local-preference documentation

A customer can ask; the provider still decides

Communities make the authority boundary easy to miss. RFC 1998 describes provider mappings through which a multihomed customer requests different preference treatment. The customer supplies a label; the provider’s policy gives it an effect. The wire label is neither the LOCAL_PREF attribute itself nor proof that its sender is entitled to every available action. RFC 1998, section 3.2

Large Communities can express action requests with administrative or geographic scope. Their interpretation still depends on the receiving operator’s rules and processing order. For an audit, the consequential object is the whole mapping: which neighbour may request which action for which routes, where it applies, and what happens when requests conflict. RFC 8195, sections 2.2 and 4.3

Maintenance provides a revealing counterexample to the idea that low means unusable. Graceful Shutdown recommends lowering preference, commonly to zero, while alternatives are selected and propagated. A route at zero is not withdrawn; if it remains the only eligible option, it may still carry traffic. The procedure also recognises that route reflectors can hide alternatives. A low number is therefore no substitute for proving that another usable path has arrived before disconnecting the old one. RFC 8326, sections 3–4

A valid mistake does not trip the parser

An unintended value of 200 is syntactically ordinary. Error handling will not recognise that a policy author meant 100. RFC 7606 distinguishes discarding LOCAL_PREF received from an ordinary external neighbour from treating an internally received update as withdrawn when the attribute’s length is not four octets. Those are protocol-format boundaries, not tests of business intent. RFC 7606, section 7.5

The practical consequence is uncomfortable: a preference accident may leave sessions established, updates valid and route counts broadly unchanged. Monitoring only adjacency health can miss the very change that matters. The signal may instead be a new concentration of traffic, loss on a previously quiet link, or an unexpected departure point for a particular destination set. These are diagnostic hypotheses, not evidence of any incident described here.

Follow the decision until it becomes traffic

The evidence should begin before the change: an accountable policy owner, a reason for favouring one class, a precise match set and a rollback condition. Preserve the alternatives seen in Adj-RIB-In and record the calculated values after import policy. Then compare internal advertisements or suitable telemetry with selected Loc-RIB paths at several relevant speakers, including those reached through route reflection. A public collector outside the AS cannot directly show the internal attribute responsible for the choice.

Next, verify the resolved next hop and the installed forwarding information base, including any equal-cost paths. Probe from the ingress locations whose traffic was meant to change, and correlate those observations with egress counters. Matching values alone cannot establish matching paths; matching control-plane paths cannot establish successful packet delivery. No single probe proves all destinations or all traffic classes.

Rollback needs the same discipline. Reverting configuration is only the beginning: affected routes must be re-evaluated, with retained route state or negotiated Route Refresh where appropriate, and the previous useful forwarding outcome must be observed again. Route Refresh reacquires information; it does not decide what the policy should be. The number is a compact instruction. The proof is the bounded, working behaviour it produces.