Stream of Knowledge: Day 14

Day 14 — BGP LOCAL_PREF: Building an AS-Wide Outbound Exit Policy

at September 10, 2026

Learning objective

Use LOCAL_PREF to create a consistent preferred exit throughout an autonomous system, verify that the attribute is propagated to iBGP peers but not ordinary eBGP peers, and correct a conflicting edge policy.

BGP LOCAL_PREF

1. Opening — policy must travel farther than one router

Weight solved a local problem on Day 13. LOCAL_PREF solves a different problem: several routers inside one AS need to agree on the preferred outbound exit.

Consider an enterprise with two edge routers. Edge E1 connects to ISP-A and Edge E2 connects to ISP-B. A core router C1 learns both Internet paths through iBGP. The enterprise wants traffic to prefer E1 during normal operation but retain E2 as a backup.

A local-only Weight change on E1 cannot communicate that preference to C1. LOCAL_PREF can.

RFC 4271 defines LOCAL_PREF as a well-known discretionary attribute used inside an AS. Higher LOCAL_PREF is preferred. In ordinary eBGP operation, LOCAL_PREF is not sent to external peers; it is an internal policy signal.

2. What LOCAL_PREF represents

LOCAL_PREF answers an internal policy question:

> “Which exit does this AS prefer for this route?”

It does not tell a remote AS how to enter your network. It tells routers inside your AS how strongly they should prefer a path relative to another path.

Cisco IOS XE documentation uses a default local preference of 100 when no different policy is applied. Operators often use values such as 200 for primary, 150 for secondary and 100 for default, but those numbers are conventions—not protocol-mandated tiers.

The only protocol rule that matters for selection is that the higher LOCAL_PREF wins, assuming the paths are eligible and no earlier Cisco-specific Weight decision has already separated them.

3. Propagation boundary

RFC 4271 requires LOCAL_PREF to be included in UPDATEs to internal peers and prohibits including it in ordinary UPDATEs sent to external peers, except for the special case of BGP confederations.

Operationally:

ISP-A ---> E1 -- LOCAL_PREF 200 --> C1
ISP-B ---> E2 -- LOCAL_PREF 100 --> C1

C1 can make the same preferred-exit decision as the edge routers because the policy value travels through iBGP.

This is why LOCAL_PREF is the canonical BGP tool for outbound exit selection inside an AS.

4. Where to set LOCAL_PREF

The cleanest pattern is usually to classify the route at the ingress edge where it enters the AS.

For example:

route-map ISP-A-IN permit 10
 set local-preference 200
!
router bgp 65030
 address-family ipv4 unicast
  neighbor 192.0.2.1 route-map ISP-A-IN in

The route then carries LOCAL_PREF 200 when E1 advertises it to iBGP peers.

Cisco also provides bgp default local-preference to change the default local preference on a router, but broad defaults deserve caution because they can alter many routes at once.

5. Scenario — Meridian Preferred Exit

Illustrative lab

Topology

BGP LOCAL_PREF: Building an AS-Wide Outbound Exit Policy

 ISP-A R1                 ISP-B R2
 AS65010                  AS65020
    | eBGP                   | eBGP
    |                        |
 E1 ----------------------- E2
 AS65030        iBGP        AS65030
   \                         /
    \        iBGP           /
             C1
          AS65030

Use documentation-safe transit addressing:

R1–E1: 192.0.2.0/30
R2–E2: 198.51.100.0/30
E1–C1: 203.0.113.0/30
E2–C1: 203.0.113.4/30
E1–E2: 203.0.113.8/30

Both providers advertise lab prefix 192.0.2.128/25.

Objective

E1 sets LOCAL_PREF 200 on the ISP-A path.
E2 leaves the ISP-B path at 100.
Both edges use next-hop-self toward C1 for this foundation lab.
C1 prefers E1.
Removing E1's policy causes C1 to return to later tie-breakers.

6. Prerequisites

Five logical roles: R1, R2, E1, E2 and C1.
IOS XE-compatible lab nodes for enterprise BGP roles.
Full-mesh iBGP among E1, E2 and C1 for this small topology.
Reachable iBGP next hops.
Both provider paths otherwise constructed to be comparable.

Route reflectors are intentionally deferred to the iBGP-scaling module.

7. Topic-specific configuration excerpt

The complete interface underlay is stored in the companion lab files. The policy-relevant configuration is shown here.

E1

ip prefix-list LAB-SERVICE permit 192.0.2.128/25
!
route-map ISP-A-IN permit 10
 match ip address prefix-list LAB-SERVICE
 set local-preference 200
route-map ISP-A-IN permit 20
!
router bgp 65030
 neighbor 192.0.2.1 remote-as 65010
 neighbor 203.0.113.2 remote-as 65030
 neighbor 203.0.113.10 remote-as 65030
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
  neighbor 192.0.2.1 route-map ISP-A-IN in
  neighbor 203.0.113.2 activate
  neighbor 203.0.113.2 next-hop-self
  neighbor 203.0.113.10 activate
  neighbor 203.0.113.10 next-hop-self
 exit-address-family

E2

router bgp 65030
 neighbor 198.51.100.1 remote-as 65020
 neighbor 203.0.113.6 remote-as 65030
 neighbor 203.0.113.9 remote-as 65030
 address-family ipv4 unicast
  neighbor 198.51.100.1 activate
  neighbor 203.0.113.6 activate
  neighbor 203.0.113.6 next-hop-self
  neighbor 203.0.113.9 activate
  neighbor 203.0.113.9 next-hop-self
 exit-address-family

C1

router bgp 65030
 neighbor 203.0.113.1 remote-as 65030
 neighbor 203.0.113.5 remote-as 65030
 address-family ipv4 unicast
  neighbor 203.0.113.1 activate
  neighbor 203.0.113.5 activate
 exit-address-family

The exact interface mapping in the lab package must match these neighbor addresses before execution.

8. Verification before policy

On C1:

show ip bgp 192.0.2.128
show ip bgp summary
show ip route 203.0.113.1
show ip route 203.0.113.5

On E1 and E2:

show ip bgp 192.0.2.128
show ip bgp neighbors <internal-peer> advertised-routes

Record the baseline before setting LOCAL_PREF 200. Do not assume which equal path wins before policy; late tie-breakers can depend on IDs and arrival order.

9. Controlled modification

Apply the inbound route map on E1 and use a safe inbound refresh if needed.

Expected path logic:

ISP-A path enters E1
        |
set LOCAL_PREF 200
        |
iBGP advertisement to C1
        |
C1 compares 200 versus 100
        |
C1 prefers E1 exit

Verify on C1:

show ip bgp 192.0.2.128
show ip route 192.0.2.128 255.255.255.128

The path via E1 should display the higher LOCAL_PREF and become best if Weight is equal and both paths remain eligible.

10. Fault injection

Illustrative lab — not a real incident.

Lab name

Meridian Split Policy

Fault

E2 accidentally applies LOCAL_PREF 250 to the ISP-B path while E1 applies 200.

route-map ISP-B-IN permit 10
 set local-preference 250
!
router bgp 65030
 address-family ipv4 unicast
  neighbor 198.51.100.1 route-map ISP-B-IN in

Expected symptom

C1 prefers E2, even though documentation says ISP-A is primary.

Misleading symptom

Both edge sessions are healthy. There is no protocol failure. The problem is policy correctness.

11. Troubleshooting sequence

Confirm the affected prefix and desired primary exit.
Verify both eBGP sessions.
Inspect C1's candidate paths and LOCAL_PREF values.
Trace each LOCAL_PREF back to the ingress edge policy.
Inspect inbound route maps and prefix-list matches.
Check for bgp default local-preference on either edge.
Check for Cisco Weight that could override the LOCAL_PREF decision locally.
Confirm next-hop reachability and RIB installation.
Correct the smallest wrong policy value or match condition.
Refresh safely and verify stable convergence.

12. Root cause and correction

Root cause

The backup edge assigned a higher LOCAL_PREF than the designated primary edge.

Correction

Remove or lower the incorrect E2 policy so the intended ranking is restored—for example E1 = 200, E2 = 100.

Why it works

LOCAL_PREF is propagated inside the AS, so C1 and the edge routers can make a consistent outbound-exit decision from the same policy signal.

13. Post-fix verification

On C1:

show ip bgp 192.0.2.128
show ip route 192.0.2.128 255.255.255.128

On E1/E2:

show route-map
show running-config | section router bgp
show ip bgp neighbors <peer> routes

If a data-plane endpoint exists, verify traffic exits through E1 and that failure of E1 causes the tested prefix to use E2.

14. Rollback

On E1:

router bgp 65030
 address-family ipv4 unicast
  no neighbor 192.0.2.1 route-map ISP-A-IN in

If the route map is used elsewhere, do not delete it globally until references are checked.

Rollback should restore the baseline decision process, not necessarily force the path through a specific peer.

15. Production design considerations

Set policy at ingress

Classifying a route when it enters the AS makes intent easier to reason about than changing preference repeatedly downstream.

Use a documented preference scale

Values are arbitrary, but a documented internal convention reduces accidental inversions.

Do not confuse outbound and inbound engineering

LOCAL_PREF primarily influences which exit your AS uses. It does not directly force external networks to choose how they enter your AS.

Audit broad defaults

bgp default local-preference can be valid, but broad defaults have larger blast radius than selective route-map policy.

Watch interactions with security

RPKI or customer/peer classification policy may intentionally lower LOCAL_PREF for certain routes. A later broad route map must not accidentally undo those controls.

15A. What LOCAL_PREF does not solve

LOCAL_PREF is powerful precisely because it is scoped to routing policy inside the AS, but that means it does not solve every traffic-engineering problem.

It does not force inbound traffic

If AS65030 gives ISP-A a LOCAL_PREF of 200, that tells AS65030's own routers to leave through ISP-A. A remote network choosing how to reach AS65030 does not receive that LOCAL_PREF in normal eBGP and cannot use it directly. Inbound engineering requires different tools such as selective advertisement, more-specific prefixes, provider communities, MED in the appropriate relationship, or carefully designed AS-path prepending.

It does not repair an unreachable next hop

A path with LOCAL_PREF 200 is not useful if its next hop is inaccessible. Day 12 remains a prerequisite: path eligibility and recursive resolution come before assuming that a preference value will translate into forwarding.

It does not override Cisco Weight

On a Cisco router, a local Weight difference is evaluated before LOCAL_PREF. If one edge has an unexplained Weight override, the router can disagree with the AS-wide policy even though the LOCAL_PREF values are correct.

It should not become a dumping ground for every policy decision

A mature design often uses communities to classify route source or business relationship and then derives LOCAL_PREF from that classification. This separates route meaning from route preference and makes policy easier to audit. The community modules later in the series will build that pattern explicitly.

15B. Preference-scale design

There is no RFC-defined enterprise scale such as 100/200/300. Operators create their own. A useful scale leaves room between tiers so emergency or security policy can insert temporary values without renumbering everything.

For example, an organization might document:

50   = degraded / temporary fallback
100  = normal backup transit
150  = normal secondary transit
200  = primary transit
250  = customer or preferred private interconnect class

Those numbers are only an example. The engineering requirement is consistency: every ingress policy that assigns LOCAL_PREF must align with the same documented hierarchy, and security policy must not be accidentally overridden by a generic route map later in the chain.

16. Knowledge check

Q1

Why does C1 learn the preferred-exit policy when Weight would not provide it?

Answer: LOCAL_PREF is carried to iBGP peers inside the AS, while Weight is local to one Cisco router.

Q2

Does LOCAL_PREF normally cross an eBGP boundary?

Answer: No. RFC 4271 says it must not be included in ordinary UPDATEs sent to external peers, except in the special case of BGP confederations.

Q3

Which LOCAL_PREF is preferred: 80 or 200?

Answer: 200, because higher LOCAL_PREF is preferred.

17. Sources

RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — LOCAL_PREF definition and propagation rules.
Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.18.x: Configuring BGP* — local preference in the Cisco best-path sequence and default 100 behavior.
Cisco — *Cisco IOS IP Routing: BGP Command Reference* — bgp default local-preference.
Cisco — *Cisco IOS IP Routing: Protocol-Independent Command Reference* — set local-preference.

Accessed: 2026-08-11.