local preference
termThe BGP attribute that carries an autonomous system's own preference for a route to its internal peers; higher wins.
LOCAL_PREF, type code 5 in RFC 4271, is how an operator states which exit it prefers for a destination. It is set by local policy, sent only to iBGP peers, and compared before the AS path length is even considered, so it overrides every tie-break that follows.
RFC 4271's decision process starts by giving each route a degree of preference. For a route from an internal peer that is either the LOCAL_PREF value or a value computed from local policy; for an external route the speaker computes it from preconfigured policy, and the higher degree of preference must be preferred. How that policy works is a local matter. Only routes that tie on it go on to the tie-breaks: shortest AS_PATH, lowest ORIGIN, lowest MED and the rest.
The attribute never leaves the AS. It shall be included in every UPDATE sent to internal peers and must not be sent to external peers, except within a BGP confederation. A neighbouring AS therefore cannot set it for you; its own means of influencing how traffic enters it are MED and communities that the receiving AS has agreed to act on.
Two consequences are worth seeing. A route given LOCAL_PREF 200 by import policy beats a route with a shorter AS path, because the comparison never reaches path length. In FRRouting's BGP table the LocPrf column holds the value, and the header states the default, Default local pref 100. Implementations may add steps of their own before it: FRRouting, for one, checks a router-local weight first.
Also known as: local_pref, local pref, localpref, locprf, bgp local preference
Sources
- RFC 4271, A Border Gateway Protocol 4 (BGP-4), January 2006: sections 5, 5.1.5, 9.1, 9.1.1 and 9.1.2.2 (read 2026-10-19)
- IANA, Border Gateway Protocol (BGP) Parameters registry, last updated 2026-09-09: BGP Path Attributes (read 2026-10-19)
- FRRouting documentation, BGP (latest): Route Selection and Displaying BGP Information (read 2026-10-19)