Short answer: BGP LOCAL_PREF tells routers inside one autonomous system which exit path to prefer for outbound traffic. A higher value wins among otherwise eligible paths, and the value is distributed to internal BGP peers—not to ordinary external peers.[1]
What LOCAL_PREF does
LOCAL_PREF is a well-known discretionary BGP path attribute used to express a route's degree of preference within an AS. A speaker advertises it to internal peers, and higher preference must be preferred; it is not sent to external peers except in BGP confederation cases.[1] This makes it the usual AS-wide policy signal for choosing among multiple exits.
Do not confuse LOCAL_PREF with MED. LOCAL_PREF is your AS's decision about which exit to use; MED is generally an optional hint offered to a neighboring AS about which of your entry points it might prefer.
Why network engineers use it
Suppose two border routers learn the same public prefix, one through a preferred transit provider and one through a backup. Setting a higher LOCAL_PREF on the preferred route allows routers across the AS to select that exit consistently, assuming the route remains valid and no earlier vendor-specific decision criterion overrides it.
Common policy tiers might be: private interconnect 300, primary transit 200, backup transit 100. These numbers are locally chosen conventions, not protocol defaults or universal values.
Traffic engineering: what it controls and what it cannot
- Outbound traffic: LOCAL_PREF is designed for this. The AS selects its preferred route to a destination and forwards traffic toward the corresponding exit.
- Inbound influence: LOCAL_PREF does not directly control how another AS sends traffic toward your prefixes. You can use provider-supported communities, AS_PATH prepending, MED in applicable designs, or selective advertisements to influence remote policy, but none guarantees a remote decision.
- Limits: LOCAL_PREF is not sent to ordinary eBGP peers, cannot make an unreachable NEXT_HOP usable, and cannot override filtering, route validity, or another policy decision that takes precedence in a vendor's best-path process.
Configuration examples
Cisco IOS-style inbound policy
ip prefix-list PREFERRED-DESTINATIONS permit 203.0.113.0/24
!
route-map ISP-A-IN permit 10
match ip address prefix-list PREFERRED-DESTINATIONS
set local-preference 250
route-map ISP-A-IN permit 100
!
router bgp 65010
neighbor 192.0.2.1 remote-as 64496
neighbor 192.0.2.1 route-map ISP-A-IN inThis applies the higher preference to the matched route as it enters the local BGP decision process. Validate exact syntax and address-family placement on the target platform and release.[2]
FRRouting-style example
route-map ISP-A-IN permit 10
set local-preference 250
!
router bgp 65010
neighbor 192.0.2.1 remote-as 64496
address-family ipv4 unicast
neighbor 192.0.2.1 route-map ISP-A-IN in
exit-address-familyFor all routes from one provider, apply a peer-wide policy; for destination-specific preference, match prefixes or communities deliberately. Keep a catch-all permit/deny behavior appropriate to your import policy.
Route walkthrough
Edge-A and Edge-B both receive 198.51.100.0/24. Policy assigns LOCAL_PREF 250 to Edge-A's path and 100 to Edge-B's. Internal BGP distributes the preference. Routers comparing these eligible paths prefer the Edge-A route because 250 is higher. If Edge-A's next hop becomes unreachable or its route is withdrawn, the alternate path can be selected. Verify that the policy is attached to the correct neighbor and address family and that the resulting route actually propagates internally.
Verification commands
show ip bgp 198.51.100.0/24
show ip bgp neighbors 192.0.2.1 received-routes
show ip route 198.51.100.0
show ip cef 198.51.100.0Check the received and selected paths' LOCAL_PREF, the best-path marker, next-hop resolution, and the installed forwarding entry. Command availability can depend on platform and inbound soft-reconfiguration settings. On FRRouting, inspect the IPv4 unicast BGP route and routing-table entry with the corresponding show bgp and show ip route commands.
Troubleshooting checklist
- Does the prefix arrive from both intended peers?
- Does the route map match the actual prefix, community, and address family?
- Is LOCAL_PREF present and higher on the route expected to win?
- Is the policy applied inbound where intended, and has the route been refreshed/re-evaluated?
- Is the route valid, with a reachable NEXT_HOP?
- Is another decision criterion or route policy determining the selected path?
- Do route reflectors and internal peers carry the expected preference?
- Does the forwarding table use the selected path, or is a different route installed?
Modern deployments
At dual-ISP and cloud/on-prem edges, LOCAL_PREF is useful for selecting a preferred egress across multiple border routers. It also applies in data-center BGP designs where policy must consistently select an exit or service path. In EVPN/VXLAN fabrics and ACI-like environments, use the platform's documented route-policy model; do not assume a WAN edge policy is automatically appropriate for tenant VRFs or overlay routes. Ensure policy scope is explicit so a preference intended for one routing context does not leak into another.
Interview answer
Question: How does BGP LOCAL_PREF affect traffic? Answer: LOCAL_PREF is an intra-AS preference advertised to internal BGP peers. The higher value is preferred, so I use it to select an outbound exit consistently across my AS. It is not normally sent to external peers, so it does not directly control inbound traffic from another AS. I verify the received value, best path, next-hop reachability, and installed route.
Related reading
Sources
- [1] RFC 4271, section 5.1.5: LOCAL_PREF — “The higher degree of preference MUST be preferred.”
- [2] Cisco BGP Configuration Guide — route attribute and LOCAL_PREF configuration reference.
Post a Comment