Short answer: BGP LOCAL_PREF is the cleanest attribute for choosing which exit point your autonomous system uses for outbound traffic. Higher LOCAL_PREF wins inside the local AS, it is carried across iBGP, and it is not advertised to external BGP neighbors because RFC 4271 defines LOCAL_PREF as a well-known discretionary attribute used inside an AS.[1]
If you remember one rule, remember this: use LOCAL_PREF to choose your outbound exit; do not expect it to directly force how the Internet sends traffic back to you.
Where LOCAL_PREF fits in BGP path selection
BGP stores routes as NLRI plus path attributes, then applies local policy to decide which route becomes best and which routes are advertised onward.[1] LOCAL_PREF is one of the early policy levers in that decision process: when two paths to the same prefix are otherwise eligible, the path with the higher local preference is preferred before shorter AS_PATH or lower MED are considered in common vendor best-path logic.[2]
That position is why LOCAL_PREF is so useful operationally. You can prefer ISP-A for default Internet access, send SaaS traffic toward a cloud interconnect, drain an edge router before maintenance, or keep a backup MPLS/Internet circuit available without making it the normal forwarding path.
What LOCAL_PREF controls
Outbound control
LOCAL_PREF controls outbound traffic from your AS toward a destination prefix. If router Edge-1 learns 203.0.113.0/24 from ISP-A with local preference 200 and Edge-2 learns the same prefix from ISP-B with local preference 100, iBGP should distribute those paths internally and your routers should prefer the ISP-A exit, assuming the next hop is reachable and no earlier eligibility rule removes the path.
Inbound influence
LOCAL_PREF does not leave your AS, so it does not directly tell an upstream provider or a remote network how to reach your prefixes.[1] For inbound influence you normally use provider communities, AS_PATH prepending, MED toward the same neighboring AS, selective advertisements, or more-specific prefixes where policy and address ownership allow it.
What it cannot control
LOCAL_PREF cannot override missing next-hop reachability, route filtering, RPKI/IRR policy at an upstream, a more-specific route that wins by longest-prefix match, or a remote AS policy that chooses a different return path. It also cannot guarantee traffic symmetry through a firewall pair unless your routing design, NAT placement, state synchronization and inbound policy all agree.
Practical dual-ISP example
Assume a company has AS 65010, two edge routers, ISP-A on Edge-1 and ISP-B on Edge-2. The design goal is simple: use ISP-A as the primary Internet exit, keep ISP-B ready for failover, and avoid touching every internal router.
iBGP / IGP core
+--------------------------+
| |
Edge-1 Edge-2
AS65010 AS65010
ISP-A ISP-B
local-pref 200 local-pref 100On Cisco IOS-style syntax, set LOCAL_PREF inbound from the preferred ISP so all internal BGP speakers see the same policy:
ip prefix-list DEFAULT-ONLY seq 5 permit 0.0.0.0/0
route-map ISP-A-IN permit 10
match ip address prefix-list DEFAULT-ONLY
set local-preference 200
route-map ISP-A-IN permit 100
set local-preference 200
route-map ISP-B-IN permit 10
match ip address prefix-list DEFAULT-ONLY
set local-preference 100
route-map ISP-B-IN permit 100
set local-preference 100
router bgp 65010
neighbor 198.51.100.1 remote-as 64496
neighbor 198.51.100.1 description ISP-A
neighbor 198.51.100.1 route-map ISP-A-IN in
neighbor 203.0.113.1 remote-as 64497
neighbor 203.0.113.1 description ISP-B
neighbor 203.0.113.1 route-map ISP-B-IN inThe same idea in FRRouting-style syntax is nearly identical:
route-map ISP-A-IN permit 10
set local-preference 200
exit
route-map ISP-B-IN permit 10
set local-preference 100
exit
router bgp 65010
neighbor 198.51.100.1 remote-as 64496
neighbor 198.51.100.1 route-map ISP-A-IN in
neighbor 203.0.113.1 remote-as 64497
neighbor 203.0.113.1 route-map ISP-B-IN inOn Junos, do it with import policy. Juniper documents BGP route preference and routing-policy examples for changing route selection behavior, while the practical BGP LOCAL_PREF pattern is to set local-preference under policy terms and apply the policy to BGP import.[3]
policy-options {
policy-statement ISP-A-IN {
term default {
from route-filter 0.0.0.0/0 exact;
then {
local-preference 200;
accept;
}
}
then {
local-preference 200;
accept;
}
}
policy-statement ISP-B-IN {
then {
local-preference 100;
accept;
}
}
}
protocols {
bgp {
group ISP-A {
type external;
import ISP-A-IN;
neighbor 198.51.100.1 { peer-as 64496; }
}
group ISP-B {
type external;
import ISP-B-IN;
neighbor 203.0.113.1 { peer-as 64497; }
}
}
}Packet and policy walkthrough
- ISP-A advertises
0.0.0.0/0and Internet prefixes to Edge-1. - Edge-1 import policy sets LOCAL_PREF 200 on those routes.
- ISP-B advertises the same or similar reachability to Edge-2.
- Edge-2 import policy sets LOCAL_PREF 100.
- iBGP carries the routes inside AS 65010.
- Internal routers compare available BGP paths and prefer the path with LOCAL_PREF 200 when both paths are eligible.
- If ISP-A fails or the BGP session drops, the LOCAL_PREF 200 path disappears and the LOCAL_PREF 100 path through ISP-B becomes best.
Verification commands and expected logic
Cisco IOS / IOS XE / NX-OS style
show ip bgp 0.0.0.0/0
show bgp ipv4 unicast 203.0.113.0/24
show ip bgp neighbors 198.51.100.1 received-routes
show route-map ISP-A-IN
show ip route 0.0.0.0Expected logic: the preferred route should show a higher local preference, should be marked as best, and the routing table should point to the intended next hop. If the BGP table shows the higher LOCAL_PREF path but the RIB does not install it, check next-hop reachability and administrative distance against other protocols.
Junos style
show route protocol bgp 0.0.0.0/0 detail
show route receive-protocol bgp 198.51.100.1 extensive
show route advertising-protocol bgp <ibgp-neighbor> 0.0.0.0/0
show policy ISP-A-INExpected logic: the active BGP route should be the route with the intended local preference, and hidden or secondary routes should explain why they were not selected.
Arista EOS style
Arista EOS BGP follows the same operational model of neighbors, UPDATE exchange and route attributes; its documentation also highlights BGP state behavior and EOS BGP configuration workflows.[4]
show ip bgp 0.0.0.0/0 detail
show ip bgp summary
show route-map ISP-A-IN
show ip route bgpModern usage patterns
Data center BGP underlay
In a leaf-spine underlay, LOCAL_PREF is usually less visible than ECMP, next-hop reachability and consistent prefix advertisement. Still, it can help during controlled maintenance, brownfield migration, or DCI edge selection where one exit should be preferred without withdrawing the backup path.
EVPN/VXLAN and fabric exits
In EVPN/VXLAN fabrics, LOCAL_PREF is more likely to appear at border leaves, route-server policy points or external connectivity edges than inside pure host-facing VXLAN forwarding. Use it to prefer a fabric exit for external prefixes, not to solve tenant import/export decisions that belong to route targets and VRF policy.
ACI-like fabrics and cloud edge
In controller-based fabrics, the platform may abstract the BGP policy into an L3Out, external network object or route-control profile. The design rule remains the same: prefer outbound exits with local policy inside your routing domain, and use upstream-agreed mechanisms when you need to influence inbound traffic.
Troubleshooting checklist
- Wrong path is best: compare LOCAL_PREF values first, then AS_PATH, origin, MED, eBGP over iBGP, IGP metric to next hop and vendor-specific tie-breakers.
- Policy did not apply: check route-map or policy term order, prefix-list matches, address-family activation and whether the policy is inbound or outbound.
- LOCAL_PREF is correct but route is not installed: verify next-hop reachability, recursive resolution and competing routes from static, OSPF, IS-IS or connected sources.
- Failover works but return traffic breaks: inspect NAT, firewall state, public-prefix advertisements and provider-side policy. LOCAL_PREF only changed your outbound path.
- iBGP routers disagree: confirm route reflector policy, cluster behavior, add-path/multipath settings and whether all routers receive the same BGP attributes.
- Traffic did not move after a change: check CEF/FIB, flow hashing, long-lived sessions and upstream caching of BGP decisions.
Common interview answer
Question: What is BGP LOCAL_PREF and when would you use it?
Answer: LOCAL_PREF is a BGP attribute used inside one autonomous system to choose the preferred outbound exit. Higher is better. It is normally set with import policy on routes learned from eBGP neighbors and propagated through iBGP. It is excellent for outbound traffic engineering, but it does not directly control inbound Internet traffic because it is not advertised outside the AS.
Related reading
- How to Influence Inbound and Outbound BGP Traffic: LOCAL_PREF, Prepending and MED
- BGP Maintenance Drain: Practical Checklist for Zero-Downtime Network Changes
- BGP Max-Prefix and Prefix-Limit: Stop Route Leaks Before They Take Down Peering
- BGP Table Watch
Post a Comment