What is LOCAL_PREF?

LOCAL_PREF (local preference) is the BGP attribute that decides which path your autonomous system uses to send traffic outbound when several routes to the same prefix exist. It is a 32-bit value propagated only inside a single AS over iBGP, and it never leaves your network. In the BGP best-path selection algorithm, LOCAL_PREF is one of the first criteria: after the local weight (a Cisco-specific attribute) and before AS_PATH length. The rule is simple: the route with the higher LOCAL_PREF wins.

How LOCAL_PREF works

When a border router learns a prefix from an eBGP neighbour, it assigns a LOCAL_PREF value according to an inbound policy (a route-map or policy statement). That value is then advertised over iBGP to every router in the AS, so the whole network makes a consistent outbound path decision. The default value on most platforms is 100, but you set it explicitly to get predictable behaviour. Because LOCAL_PREF is evaluated very early, it overrides AS_PATH length: a route with a worse (longer) AS_PATH still wins if it carries a higher LOCAL_PREF.

Preferring peering over transit

The most common use of LOCAL_PREF is steering outbound traffic by cost. IP transit is billed by volume, whereas peering at an internet exchange is usually settlement-free. By assigning a higher LOCAL_PREF to routes learned over peering and a lower one to transit routes, you send outbound traffic through cheaper, shorter paths first and keep transit as a fallback. A typical value scheme looks like this:

• Customer routes: highest LOCAL_PREF, e.g. 200. Traffic to customers always takes priority.
• IXP peering and PNI: high LOCAL_PREF, e.g. 150. A cheaper, shorter path.
• Primary transit: medium LOCAL_PREF, e.g. 100 (the default).
• Backup transit: low LOCAL_PREF, e.g. 80. Used only when no better route exists.
• LOCAL_PREF affects outbound traffic only. Inbound traffic is influenced by AS_PATH prepending, MED and BGP communities.

What LOCAL_PREF does not do

LOCAL_PREF does not control inbound traffic, because it is not advertised to eBGP neighbours. Adjacent networks never see it and never consider it. To influence how traffic returns to your AS, you use AS path prepending, the MED attribute, or BGP communities agreed with your provider. LOCAL_PREF also beats AS_PATH, so carelessly raising the preference on a backup route can unintentionally pull all traffic onto a more expensive link. That is why the values are designed deliberately and documented, ideally mapped to BGP communities so customers can lower the preference themselves.

LOCAL_PREF in the AS202520 SkyPass network

At AS202520 SkyPass we use LOCAL_PREF in the routing policy of our PoPs in Warsaw and Wrocław so that outbound traffic prefers peering at the Polish exchanges (THINX, TPIX, WRIX and 1-IX) over transit links. As a result, your traffic to Polish and regional networks takes a shorter, lower-latency path. For IP transit and remote IXP customers we expose BGP communities you can use to steer LOCAL_PREF on our routers, and you can check the current state of routes in our looking glass.