BGP LOCAL_PREF Attribute

What LOCAL_PREF Is

LOCAL_PREF (Type code 5) is the path attribute that makes every router in the local AS agree on which exit to use (BGP Path Attributes and Best Path Selection). RFC 4271 section 4.3 e) defines it as “a well-known attribute that is a four-octet unsigned integer”, used by a speaker to inform its other internal peers of its degree of preference for a route.

Item	Description
Type code	5
Classification	Well-known. Required towards iBGP peers, forbidden towards eBGP peers
Value	A 4-byte unsigned integer. Higher is preferred
Default	100 (not specified by the RFC; the value in most implementations, IOS XR included)
Propagation scope	Within the local AS only (carried on iBGP, never on eBGP)
Definition	RFC 4271 sections 4.3 e), 5.1.5 and 9.1.1

LOCAL_PREF is often classified as “well-known discretionary”, but RFC 4271 does not say that. The attribute table in section 5 lists LOCAL_PREF as “EBGP: see Section 5.1.5 / IBGP: required”, and applies the word discretionary to MULTI_EXIT_DISC and AGGREGATOR (both optional attributes). The only attribute RFC 4271 calls “well-known discretionary” is ATOMIC_AGGREGATE (sections 4.3 f) and 5.1.6). “Discretionary” reads as “include it or not, as you like”, whereas the rule for LOCAL_PREF is asymmetric: required on iBGP, forbidden on eBGP. That asymmetry is the nature of the attribute, so the rule is a safer thing to remember than the label.

Required on iBGP, Never Carried on eBGP

RFC 4271 section 5.1.5 states three things (confederations excepted).

Situation	Rule
Advertising to an iBGP peer	`LOCAL_PREF` must be included (SHALL be included in all UPDATE messages)
Advertising to an eBGP peer	`LOCAL_PREF` must not be included (MUST NOT include)
Received from an eBGP peer	Ignore it even if present (MUST be ignored)

LOCAL_PREF has meaning only inside the local AS. A border router attaches it to routes learned from outside and distributes them over iBGP, so every router in the AS chooses the same exit. It is not a way to steer a neighbouring AS’s entry point (that is MED). In the lab below, the UPDATE from R5 carries no LOCAL_PREF; border router R2 attaches 200 inbound, it travels over iBGP to R1 and R3, and it is left out again when R1 advertises to R4.

The propagation scope of LOCAL_PREF. The eBGP UPDATE from R5 in AS 65003 to R2 carries no LOCAL_PREF, and R2 attaches 200 with an inbound policy. The iBGP UPDATEs from R2 to R1 and R3 carry LOCAL_PREF 200, but it is dropped again on the eBGP UPDATE from R1 to R4 in AS 65002

The scope of each attribute.

Attribute	Propagation scope
WEIGHT	The local router only (never advertised; Cisco-specific, not an RFC attribute)
`LOCAL_PREF`	The local AS only (carried on iBGP, never on eBGP)
`MULTI_EXIT_DISC` (MED)	As far as the neighbouring AS (must not be passed beyond it)
`AS_PATH`	Every AS the route traverses

Why It Is Set in an Inbound Policy

RFC 4271 section 9.1.1 splits the calculation of a route’s degree of preference by the kind of peer it was learned from.

Route learned from	How the degree of preference is determined
An external peer	Computed from preconfigured policy. The return value MUST be used as the `LOCAL_PREF` value in any IBGP readvertisement
An internal peer	Either the `LOCAL_PREF` value is taken as the degree of preference, or the local system computes it from policy — but the RFC notes that the latter may result in formation of persistent routing loops

The first row is why LOCAL_PREF is configured in the inbound policy of an eBGP neighbour: the value decided inbound becomes the LOCAL_PREF carried on iBGP, by specification. The second row is why the value is left alone inside the AS. If each router recomputed the value it received from an internal peer, the routers could disagree about the exit and loop.

Where It Sits in Best Path Selection

LOCAL_PREF is evaluated second in best path selection, after WEIGHT (Cisco-specific) and before AS_PATH length (fourth).

Rank	Comparison
1	WEIGHT (higher wins; Cisco-specific)
2	`LOCAL_PREF` (higher wins)
3	Locally originated routes
4	`AS_PATH` length (shorter wins)
5	`ORIGIN` (IGP < EGP < incomplete)
6	MED (lower wins)

Sitting ahead of AS_PATH means you can deliberately make a route with a longer AS_PATH win: “the long way round, but that circuit is cheaper or fatter”.

The Default of 100 and the Direction of Comparison

The default is 100 (not specified by the RFC; the value in most implementations, IOS XR included). Routes received over eBGP arrive without it, so the localpref 100 in show bgp is a value the receiver attached itself. The comparison is the opposite of MED: higher wins.

Attribute	Direction	Whom it addresses
`LOCAL_PREF`	Higher wins	Routers in the local AS: “use this exit”
MED	Lower wins	The neighbouring AS: “please use this entry point”

Configuration

On IOS XR you normally use set local-preference in the inbound policy of an eBGP neighbour.

IOS XR LOCAL_PREF configuration (inbound policy)
route-policy <policy name>
  set local-preference <value>
  pass
end-policy
!
router bgp <AS number>
 neighbor <eBGP peer address>
  address-family ipv4 unicast
   route-policy <policy name> in

There is also a command that changes the router-wide default.

IOS XR LOCAL_PREF default value
router bgp <AS number>
 bgp default local-preference <value>

Changing the default, however, only changes that router’s own decision, and does so immediately. BGP re-advertises a route when its best path changes, so a mere change of value produces no UPDATE towards iBGP peers. To carry it into the AS you have to make the router re-advertise with clear bgp ipv4 unicast <peer> soft out. Removing the default behaves the same way: the router itself reverts, but the old value stays on its peers. Both are verified below.

Verification on Real Hardware

Five XRd 26.1.1 routers in two labs confirm the following.

LOCAL_PREF outranks AS_PATH length
The value propagates over iBGP so every router in the AS faces the same exit
When the values tie, the next comparison (AS_PATH length) decides
It is never carried to an eBGP peer (setting it in an outbound policy is ignored)
A value lower than the default (100) makes that path lose
Changing the router-wide default does not reach the AS by itself. An outbound refresh carries it, and removing the default leaves the old value behind

LOCAL_PREF verification topology. In AS 65001, R1 and R2 are border routers and R3 is internal, connected by an iBGP full mesh and OSPF area 0. R4 in AS 65002 peers with R1 and R5; R5 in AS 65003 peers with R2 and R4

R4 (AS 65002) advertises 192.168.4.0/24, and we follow which exit AS 65001 uses
AS 65001 sees two paths: straight out via R1 (65002, shorter) and round through AS 65003 via R2 (65003 65002, longer)
R3 is not a border router; which exit it faces shows whether LOCAL_PREF works across the whole AS
The iBGP is a Loopback0 full mesh with next-hop-self

Router	AS	Role	Advertised network
R1	65001	Border (eBGP with R4)	192.168.1.0/24
R2	65001	Border (eBGP with R5)	192.168.2.0/24
R3	65001	Internal (iBGP only)	192.168.3.0/24
R4	65002	eBGP with R1 and R5	192.168.4.0/24
R5	65003	eBGP with R2 and R4	192.168.5.0/24

Only R1 and R2 have their configuration changed.

STEP	Operation	What it shows
0	Initial state (the policies only `pass`)	The shorter `AS_PATH` wins, so the exit is R1, and R3 faces R1 too
1	`LOCAL_PREF 200` inbound on R2’s neighbour R5	The longer path via R2 takes over. R3 faces R2 as well, so it works across the whole AS
2	`LOCAL_PREF 200` inbound on R1’s neighbour R4 as well	On a tie the next comparison (`AS_PATH` length) decides, so the exit returns to R1
3	`set local-preference 200` outbound on R1’s neighbour R4	Not carried on eBGP (a warning syslog appears, and the attribute is absent from the pcap)
4	Remove everything	Back to the STEP 0 state, and the value on iBGP UPDATEs returns to 100
5	`LOCAL_PREF 50` inbound on R2’s neighbour R5	The side given a value lower than the default of 100 loses
6	`bgp default local-preference 150` on R1	Only R1 becomes 150; R2 and R3 never hear about it

Each STEP captures four segments: R1 - R3 and R2 - R3 (iBGP), R1 - R4 and R2 - R5 (eBGP).

STEP 0: The Shorter AS_PATH via R1 Wins

On the internal router R3, 192.168.4.0/24 points at 10.0.0.1 (R1) with a LocPrf of 100.

R3 (internal to AS 65001): show bgp (STEP 0)
RP/0/RP0/CPU0:R3#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    100      0 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i
*> 192.168.3.0/24     0.0.0.0                  0         32768 i
*>i192.168.4.0/24     10.0.0.1                 0    100      0 65002 i
*>i192.168.5.0/24     10.0.0.2                 0    100      0 65003 i
<snip>
Processed 5 prefixes, 5 paths

R3 holds only one path for 192.168.4.0/24. R2 receives the same route over iBGP, but a route learned over iBGP is not re-advertised to other iBGP peers, so R2 passes nothing to R1 or R3. Which way R3’s single path points is what the whole AS has decided.

R2 is the only router with two paths: its own eBGP path (65003 65002) and the iBGP path from R1 (65002). Their LOCAL_PREF values tie, so AS_PATH length decides. R2 ignores the circuit in front of it and takes the shorter path via R1.

R2 (border router): show bgp 192.168.4.0/24 (STEP 0)
RP/0/RP0/CPU0:R2#show bgp 192.168.4.0/24
<snip>
Paths: (2 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002, (received & used)
    10.0.0.1 (metric 3) from 10.0.0.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
<snip>
  Path #2: Received by speaker 0
<snip>
  65003 65002, (received & used)
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, localpref 100, valid, external, group-best

The traceroute from R3 takes two hops via R1.

R3: traceroute 192.168.4.1 (STEP 0)
RP/0/RP0/CPU0:R3#traceroute 192.168.4.1 source 192.168.3.1 probe 3 timeout 1 maxttl 5
<snip>
Type escape sequence to abort.
Tracing the route to 192.168.4.1
<snip>
 1  10.1.3.1 6 msec  4 msec  4 msec 
 2  10.1.4.4 38 msec  *  10 msec 

STEP 1: Making the Longer AS_PATH Win

LOCAL_PREF 200 is attached to the routes R2 receives from R5.

Configuration committed on R2 in STEP 1
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Mon Oct  5 23:14:12.626 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy FROM-R5
  set local-preference 200
  pass
end-policy
!
end

R2’s best path switches to its own eBGP path (65003 65002, localpref 200). The same route appears twice because the state after the inbound policy (Path #1) and the state as received, which soft-reconfiguration inbound always keeps (Path #2, (received-only), localpref 100), are counted separately. It shows that the route arrived without a LOCAL_PREF and that R2 had attached the default of 100.

R2: show bgp 192.168.4.0/24 (STEP 1)
RP/0/RP0/CPU0:R2#show bgp 192.168.4.0/24
<snip>
Paths: (2 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65003 65002
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, localpref 200, valid, external, best, group-best
<snip>
  Path #2: Received by speaker 0
<snip>
  65003 65002, (received-only)
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, localpref 100, valid, external

R3 follows the value even though nothing was configured on it. Its path switches to the one via R2, whose AS_PATH is the longer 65003 65002.

R3 (internal to AS 65001): show bgp 192.168.4.0/24 (STEP 1)
RP/0/RP0/CPU0:R3#show bgp 192.168.4.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65003 65002, (received & used)
    10.0.0.2 (metric 2) from 10.0.0.2 (10.0.0.2)
      Origin IGP, localpref 200, valid, internal, best, group-best

Forwarding changes with it. R3 now takes three hops (R2, R5, R4), and even R1, which is directly connected to R4, ignores the circuit in front of it and doubles back through the AS to leave via R2 (four hops).

R3: traceroute 192.168.4.1 (STEP 1)
RP/0/RP0/CPU0:R3#traceroute 192.168.4.1 source 192.168.3.1 probe 3 timeout 1 maxttl 5
<snip>
Type escape sequence to abort.
Tracing the route to 192.168.4.1
<snip>
 1  10.2.3.2 6 msec  5 msec  5 msec 
 2  10.2.5.5 32 msec  8 msec  8 msec 
 3  10.4.5.4 11 msec  *  11 msec 

R1: traceroute 192.168.4.1 (STEP 1)
RP/0/RP0/CPU0:R1#traceroute 192.168.4.1 source 192.168.1.1 probe 3 timeout 1 maxttl 5
<snip>
Type escape sequence to abort.
Tracing the route to 192.168.4.1
<snip>
 1  10.1.3.3 7 msec  5 msec  5 msec 
 2  10.2.3.2 9 msec  53 msec  8 msec 
 3  10.2.5.5 14 msec  11 msec  11 msec 
 4  10.4.5.4 43 msec  *  11 msec 

Inside the AS the value does travel on iBGP. No.11 on the R2 - R3 segment is the UPDATE R2 sent to R3, and it carries LOCAL_PREF: 200.

No.11 R2 to R3 UPDATE (iBGP, 192.168.4.0/24), tshark -V
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.0.0.2
<snip>
                    MP Reach NLRI IPv4 prefix: 192.168.4.0
        Path Attribute - ORIGIN: IGP
<snip>
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65003 65002 
<snip>
            AS Path segment: 65003 65002
<snip>
        Path Attribute - LOCAL_PREF: 200
<snip>
            Local preference: 200

Download the pcap of the packet in the tshark output above (No.11, LOCAL_PREF 200 travelling over iBGP)

Nothing reaches the neighbouring AS, though. The AS 65001 routes R4 holds still show localpref 100, the value R4 attached itself.

R4 (AS 65002): show bgp 192.168.1.0/24 (STEP 1)
RP/0/RP0/CPU0:R4#show bgp 192.168.1.0/24
<snip>
Paths: (2 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65001, (received & used)
    10.1.4.1 from 10.1.4.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, external, best, group-best
<snip>
  Path #2: Received by speaker 0
<snip>
  65003 65001, (received & used)
    10.4.5.5 from 10.4.5.5 (10.0.0.5)
      Origin IGP, localpref 100, valid, external, group-best

STEP 2: On a Tie the Next Comparison Decides

LOCAL_PREF 200 is added inbound on R1’s neighbour R4 as well, making the values tie.

Configuration committed on R1 in STEP 2
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Mon Oct  5 23:21:00.163 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy FROM-R4
  set local-preference 200
  pass
end-policy
!
end

R2’s Path #1 (the iBGP path from R1, 65002) and Path #2 (its own eBGP path, 65003 65002) are both at localpref 200, so the next comparison, AS_PATH length, makes the shorter Path #1 best.

R2: show bgp 192.168.4.0/24 (STEP 2)
RP/0/RP0/CPU0:R2#show bgp 192.168.4.0/24
<snip>
Paths: (3 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002, (received & used)
    10.0.0.1 (metric 3) from 10.0.0.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 200, valid, internal, best, group-best
<snip>
  Path #2: Received by speaker 0
<snip>
  65003 65002
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, localpref 200, valid, external, group-best
<snip>
  Path #3: Received by speaker 0
<snip>
  65003 65002, (received-only)
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, localpref 100, valid, external

The 3 in Paths: (3 available) is not the number of paths available to use. Two are in use (the iBGP path from R1 and its own eBGP path) and the third is the (received-only) copy from before the inbound policy. On a router with soft-reconfiguration inbound always, using an inbound policy adds one to this count.

R3 goes back to the path via R1, at localpref 200 with AS_PATH 65002.

R3: show bgp 192.168.4.0/24 (STEP 2)
RP/0/RP0/CPU0:R3#show bgp 192.168.4.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002, (received & used)
    10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 200, valid, internal, best, group-best

STEP 3: An Outbound Policy Cannot Put It on eBGP

set local-preference 200 is applied outbound on R1’s neighbour R4.

Configuration committed on R1 in STEP 3
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Mon Oct  5 23:27:42.872 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-R4
  set local-preference 200
  pass
end-policy
!
end

IOS XR accepts the commit, but emits a warning syslog the moment it is applied.

R1: show logging (the STEP 3 range)
RP/0/RP0/CPU0:R1#show logging start Oct 5 23:23:48
<snip>
RP/0/RP0/CPU0:Oct  5 23:27:42.066 UTC: bgp[1084]: %ROUTING-BGP-4-POLICY_EBGP : Local-preference modification operations in Outbound IPv4 Unicast policy "TO-R4" will be ignored for external neighbor/update-group default/0:0.4 

It says in so many words that local-preference modifications in an outbound policy are ignored for an external neighbour.

The pcap agrees. No.1 on the R1 - R4 segment is the UPDATE R1 sent to R4 right after the policy was applied: ORIGIN, AS_PATH and MULTI_EXIT_DISC are present, but there is no LOCAL_PREF.

No.1 R1 to R4 UPDATE (eBGP, 192.168.1.0/24, after set local-preference outbound), tshark -V
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.1.4.1
<snip>
                    MP Reach NLRI IPv4 prefix: 192.168.1.0
        Path Attribute - ORIGIN: IGP
<snip>
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65001 
<snip>
            AS Path segment: 65001
<snip>
        Path Attribute - MULTI_EXIT_DISC: 0

Download the pcap of the packet in the tshark output above (No.1, an eBGP UPDATE with no LOCAL_PREF)

Counted across every STEP, every route-advertising UPDATE on the two iBGP segments carries LOCAL_PREF, and not one on the two eBGP segments does.

Captured segment	Route-advertising UPDATEs	Of which carry `LOCAL_PREF`
R1 - R3 (iBGP)	12	12
R2 - R3 (iBGP)	12	12
R1 - R4 (eBGP)	3	0
R2 - R5 (eBGP)	3	0

STEP 4: Removing the Policies

The policies are removed from R1 and R2. The contents of running-config return to the STEP 0 state (apart from the last-changed timestamp line).

Configuration committed on R1 in STEP 4
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Mon Oct  5 23:34:24.175 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-R4
  pass
end-policy
!
route-policy FROM-R4
  pass
end-policy
!
end

Configuration committed on R2 in STEP 4
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Mon Oct  5 23:34:31.769 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy FROM-R5
  pass
end-policy
!
end

R3’s 192.168.4.0/24 is back to 65002 via R1, with a LocPrf of 100.

R3: show bgp (STEP 4)
RP/0/RP0/CPU0:R3#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    100      0 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i
*> 192.168.3.0/24     0.0.0.0                  0         32768 i
*>i192.168.4.0/24     10.0.0.1                 0    100      0 65002 i
*>i192.168.5.0/24     10.0.0.2                 0    100      0 65003 i
<snip>
Processed 5 prefixes, 5 paths

Removing them changes the best path, so R1 re-advertises. No.6 on the R1 - R3 segment carries LOCAL_PREF back at 100. That is how the default of 100 gets there: a border router attaches it.

No.6 R1 to R3 UPDATE (iBGP, 192.168.4.0/24, after removal), tshark -V
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.0.0.1
<snip>
                    MP Reach NLRI IPv4 prefix: 192.168.4.0
        Path Attribute - ORIGIN: IGP
<snip>
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65002 
<snip>
            AS Path segment: 65002
<snip>
        Path Attribute - MULTI_EXIT_DISC: 0
<snip>
        Path Attribute - LOCAL_PREF: 100
<snip>
            Local preference: 100

Download the pcap of the packet in the tshark output above (No.6, LOCAL_PREF 100 after removal)

In BGP AS_PATH Attribute the existing best path was kept and did not revert when eBGP paths tied, but here the higher comparison itself changes, so the choice reverts the moment the policy goes away.

STEP 5: A Value Below the Default Loses

The inbound policy on R2’s neighbour R5 is set to LOCAL_PREF 50.

Configuration committed on R2 in STEP 5
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Mon Oct  5 23:41:12.642 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy FROM-R5
  set local-preference 50
  pass
end-policy
!
end

For 192.168.4.0/24, R2’s path was already losing, so nothing changes in the output. The effect shows on R5’s own 192.168.5.0/24. Up to STEP 4 all three routers took the path via R2 (65003, one AS away); now that R2’s path is at 50, the long way round that R1 received from R4 (65002 65003, localpref 100) wins across the whole AS.

R1: show bgp 192.168.5.0/24 (STEP 5)
RP/0/RP0/CPU0:R1#show bgp 192.168.5.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.1.4.4 from 10.1.4.4 (10.0.0.4)
      Origin IGP, localpref 100, valid, external, best, group-best

R2: show bgp 192.168.5.0/24 (STEP 5)
RP/0/RP0/CPU0:R2#show bgp 192.168.5.0/24
<snip>
Paths: (3 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.0.1 (metric 3) from 10.0.0.1 (10.0.0.1)
      Origin IGP, localpref 100, valid, internal, best, group-best
<snip>
  Path #2: Received by speaker 0
<snip>
  65003
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, metric 0, localpref 50, valid, external, group-best
<snip>
  Path #3: Received by speaker 0
<snip>
  65003, (received-only)
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, metric 0, localpref 100, valid, external

R3: show bgp 192.168.5.0/24 (STEP 5)
RP/0/RP0/CPU0:R3#show bgp 192.168.5.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
      Origin IGP, localpref 100, valid, internal, best, group-best

R2 has R5 right in front of it, yet delivers via R1, R4 and R5. Because higher wins, attaching a low value amounts to saying “do not use this exit”. Connectivity is unaffected.

R3: ping 192.168.5.1 (STEP 5)
RP/0/RP0/CPU0:R3#ping 192.168.5.1 source 192.168.3.1 count 50 timeout 1
<snip>
Sending 50, 100-byte ICMP Echos to 192.168.5.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 10/13/63 ms

STEP 6: Changing the Router-Wide Default Does Not Reach the AS

bgp default local-preference 150 is configured on R1.

Configuration committed on R1 in STEP 6
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Mon Oct  5 23:47:52.294 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 bgp default local-preference 150
!
end

R1’s own decision changes at once and 192.168.4.0/24 becomes localpref 150. R2 and R3, however, stay at 100.

R1: show bgp 192.168.4.0/24 (STEP 6)
RP/0/RP0/CPU0:R1#show bgp 192.168.4.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002, (received & used)
    10.1.4.4 from 10.1.4.4 (10.0.0.4)
      Origin IGP, metric 0, localpref 150, valid, external, best, group-best

R2: show bgp 192.168.4.0/24 (STEP 6)
RP/0/RP0/CPU0:R2#show bgp 192.168.4.0/24
<snip>
Paths: (3 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002, (received & used)
    10.0.0.1 (metric 3) from 10.0.0.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
<snip>
  Path #2: Received by speaker 0
<snip>
  65003 65002
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, localpref 50, valid, external, group-best
<snip>
  Path #3: Received by speaker 0
<snip>
  65003 65002, (received-only)
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, localpref 100, valid, external

R3: show bgp 192.168.4.0/24 (STEP 6)
RP/0/RP0/CPU0:R3#show bgp 192.168.4.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002, (received & used)
    10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best

The pcap shows the same: R1 sent 0 route-advertising UPDATEs to its iBGP peers in this STEP. No best path changed, so R1 never re-advertised. The follow-up lab picks the question up from here.

Follow-Up Lab: Carrying a Default Change into the AS

The same topology and the same addresses were rebuilt as a second lab, with four STEPs, to see what happens when an outbound refresh follows the change of default.

STEP	Operation	What it shows
0	Initial state	All three routers at `localpref 100`
1	`bgp default local-preference 150` on R1	R1 becomes 150. UPDATEs towards iBGP appear only for the routes whose best path changed
2	`clear bgp ipv4 unicast <peer> soft out` from R1 to both iBGP peers	Every route is re-advertised, and R2 and R3 become 150
3	Remove the default	R1 reverts to 100, but 150 stays on R2 and R3

Follow-Up STEP 1: A Changed Value Alone Produces No UPDATE

The default of 150 is configured on R1.

Configuration committed on R1 in follow-up STEP 1
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Sun Oct 11 15:24:30.542 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 bgp default local-preference 150
!
end

On R1 the routes learned over eBGP now carry 150, and the best path for 192.168.5.0/24 switched from the iBGP path via R2 (100) to its own eBGP path (150). Only that 192.168.5.0/24 reached R2 and R3.

R1: show bgp 192.168.5.0/24 (follow-up STEP 1)
RP/0/RP0/CPU0:R1#show bgp 192.168.5.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65003, (received & used)
    10.1.4.4 from 10.1.4.4 (10.0.0.4)
      Origin IGP, localpref 150, valid, external, best, group-best

R2: show bgp (follow-up STEP 1)
RP/0/RP0/CPU0:R2#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    100      0 i
*> 192.168.2.0/24     0.0.0.0                  0         32768 i
*>i192.168.3.0/24     10.0.0.3                 0    100      0 i
*>i192.168.4.0/24     10.0.0.1                 0    100      0 65002 i
*                     10.2.5.5                               0 65003 65002 i
*>i192.168.5.0/24     10.0.0.1                      150      0 65002 65003 i
*                     10.2.5.5                 0             0 65003 i
<snip>
Processed 5 prefixes, 7 paths

R3: show bgp (follow-up STEP 1)
RP/0/RP0/CPU0:R3#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    100      0 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i
*> 192.168.3.0/24     0.0.0.0                  0         32768 i
*>i192.168.4.0/24     10.0.0.1                 0    100      0 65002 i
*>i192.168.5.0/24     10.0.0.1                      150      0 65002 65003 i
<snip>
Processed 5 prefixes, 5 paths

The difference comes from re-advertisement happening only when the best path changes.

Prefix	R1’s best path in STEP 0	After the default of 150	UPDATE
`192.168.5.0/24`	The iBGP path from R2 (`65003`, 100)	Its own eBGP path (`65002 65003`) wins at 150	Sent
`192.168.4.0/24`	Its own eBGP path (`65002`)	The same path; only the value goes from 100 to 150	Not sent
`192.168.1.0/24`	Locally originated	Unchanged	Not sent

No.5 on the R1 - R3 segment is that single UPDATE, carrying only 192.168.5.0/24 with LOCAL_PREF: 150.

No.5 R1 to R3 UPDATE (iBGP, 192.168.5.0/24), tshark -V
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.0.0.1
<snip>
                    MP Reach NLRI IPv4 prefix: 192.168.5.0
        Path Attribute - ORIGIN: IGP
<snip>
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65002 65003 
<snip>
            AS Path segment: 65002 65003
<snip>
        Path Attribute - LOCAL_PREF: 150
<snip>
            Local preference: 150

Download the pcap of the packet in the tshark output above (No.5, only the route whose best path changed is advertised)

Follow-Up STEP 2: An Outbound Refresh Carries It

soft out is issued from R1 towards both iBGP peers. No configuration changes, so the record is the exec output.

Commands executed on R1 in follow-up STEP 2
RP/0/RP0/CPU0:R1#clear bgp ipv4 unicast 10.0.0.2 soft out
<snip>
RP/0/RP0/CPU0:R1#clear bgp ipv4 unicast 10.0.0.3 soft out
<snip>
RP/0/RP0/CPU0:R1#show clock
<snip>
15:31:09.159 UTC Sun Oct 11 2026

All three routes on R2 and R3 are now at 150.

R2: show bgp (follow-up STEP 2)
RP/0/RP0/CPU0:R2#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    150      0 i
*> 192.168.2.0/24     0.0.0.0                  0         32768 i
*>i192.168.3.0/24     10.0.0.3                 0    100      0 i
*>i192.168.4.0/24     10.0.0.1                 0    150      0 65002 i
*                     10.2.5.5                               0 65003 65002 i
*>i192.168.5.0/24     10.0.0.1                      150      0 65002 65003 i
*                     10.2.5.5                 0             0 65003 i
<snip>
Processed 5 prefixes, 7 paths

R3: show bgp (follow-up STEP 2)
RP/0/RP0/CPU0:R3#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    150      0 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i
*> 192.168.3.0/24     0.0.0.0                  0         32768 i
*>i192.168.4.0/24     10.0.0.1                 0    150      0 65002 i
*>i192.168.5.0/24     10.0.0.1                      150      0 65002 65003 i
<snip>
Processed 5 prefixes, 5 paths

No.3 on the R1 - R3 segment packs three UPDATEs into one TCP segment, and the one for 192.168.4.0/24 carries LOCAL_PREF: 150.

No.3 R1 to R3 UPDATE (iBGP, 192.168.4.0/24, after soft out), tshark -V
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.0.0.1
<snip>
                    MP Reach NLRI IPv4 prefix: 192.168.4.0
        Path Attribute - ORIGIN: IGP
<snip>
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65002 
<snip>
            AS Path segment: 65002
<snip>
        Path Attribute - MULTI_EXIT_DISC: 0
<snip>
        Path Attribute - LOCAL_PREF: 150
<snip>
            Local preference: 150

Download the pcap of the packet in the tshark output above (No.3, the three routes re-advertised by soft out)

Follow-Up STEP 3: Removing It Leaves the Old Value Behind

The default is removed.

Configuration committed on R1 in follow-up STEP 3
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Sun Oct 11 15:37:44.261 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
 no bgp default local-preference 150
!
end

R1 reverts to 100, but R2 and R3 stay at 150. For the same reason as before, no best path changes, so no UPDATE is sent.

R1: show bgp 192.168.4.0/24 (follow-up STEP 3)
RP/0/RP0/CPU0:R1#show bgp 192.168.4.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002, (received & used)
    10.1.4.4 from 10.1.4.4 (10.0.0.4)
      Origin IGP, metric 0, localpref 100, valid, external, best, group-best

R2: show bgp (follow-up STEP 3)
RP/0/RP0/CPU0:R2#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    150      0 i
*> 192.168.2.0/24     0.0.0.0                  0         32768 i
*>i192.168.3.0/24     10.0.0.3                 0    100      0 i
*>i192.168.4.0/24     10.0.0.1                 0    150      0 65002 i
*                     10.2.5.5                               0 65003 65002 i
*>i192.168.5.0/24     10.0.0.1                      150      0 65002 65003 i
*                     10.2.5.5                 0             0 65003 i
<snip>
Processed 5 prefixes, 7 paths

R3: show bgp (follow-up STEP 3)
RP/0/RP0/CPU0:R3#show bgp
<snip>
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    150      0 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i
*> 192.168.3.0/24     0.0.0.0                  0         32768 i
*>i192.168.4.0/24     10.0.0.1                 0    150      0 65002 i
*>i192.168.5.0/24     10.0.0.1                      150      0 65002 65003 i
<snip>
Processed 5 prefixes, 5 paths

The AS is left disagreeing about the value (R1 thinks 100, R2 and R3 think 150). bgp default local-preference can produce both “configured but never propagated” and “removed but the old value lingers”, so an outbound refresh after every change is part of operating it.

Operation	On that router	On its iBGP peers
Configure the default	Changes at once	Only the routes whose best path changed
`soft out`	—	Every route
Remove the default	Reverts at once	Nothing at all (the old value lingers)

Summary of Results

The best path for 192.168.4.0/24 and the first hop of the traceroute from R3, in the main lab (STEP 0 to 6).

STEP	R1	R2	R3	First hop from R3
0	`65002` lp100	`65002` lp100	`65002` lp100	10.1.3.1
1	`65003 65002` lp200	`65003 65002` lp200	`65003 65002` lp200	10.2.3.2
2	`65002` lp200	`65002` lp200	`65002` lp200	10.1.3.1
3	`65002` lp200	`65002` lp200	`65002` lp200	10.1.3.1
4	`65002` lp100	`65002` lp100	`65002` lp100	10.1.3.1
5	`65002` lp100	`65002` lp100	`65002` lp100	10.1.3.1
6	`65002` lp150	`65002` lp100	`65002` lp100	10.1.3.1

The LOCAL_PREF of 192.168.4.0/24 in the follow-up lab (STEP 0 to 3).

STEP	R1	R2	R3	Route-advertising UPDATEs from R1
0	lp100	lp100	lp100	0
1	lp150	lp100	lp100	2
2	lp150	lp150	lp150	2
3	lp100	lp150	lp150	0

Verification Configuration and show Output

Every STEP is captured from all five routers, split by router into the following kinds. The verification configuration is these ..._run.txt files (the final state is the one from the last STEP).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route`, plus the full BGP and OSPF state (per-neighbour `advertised-routes` / `routes` / `received routes`, `show bgp <prefix>` and `show rpl route-policy` included)
`..._log.txt`	`show logging` narrowed to that STEP
`..._run.txt`	`show running-config` at that STEP (the verification configuration)
`..._ping.txt`	The `ping` and `traceroute` results for that STEP (R1, R3 and R4)
`..._trace.txt`	`show bgp trace neighbor` / `show bgp trace error`
`..._commit.cfg`	Only the configuration actually committed in that STEP (routers that were changed)
`..._exec.txt`	The exec command run in that STEP (the `clear` in follow-up STEP 2)

Main Lab (STEP 0 to 6)

STEP 0: Initial state (the policies only pass)

Router	show output	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—
R5	show	log	run	—	trace	—

STEP 1: LOCAL_PREF 200 inbound on R2’s neighbour R5

Router	show output	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—
R5	show	log	run	—	trace	—

STEP 2: LOCAL_PREF 200 inbound on R1’s neighbour R4 as well (making them tie)

Router	show output	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	commit
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—
R5	show	log	run	—	trace	—

STEP 3: set local-preference 200 outbound on R1’s neighbour R4

Router	show output	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	commit
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—
R5	show	log	run	—	trace	—

STEP 4: Everything removed (the configuration returns to the STEP 0 state)

Router	show output	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	commit
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—
R5	show	log	run	—	trace	—

STEP 5: LOCAL_PREF 50 inbound on R2’s neighbour R5 (below the default)

Router	show output	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	commit
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—
R5	show	log	run	—	trace	—

STEP 6: bgp default local-preference 150 on R1 (final state)

Router	show output	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	commit
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—
R5	show	log	run	—	trace	—

Packet captures are taken per STEP on four segments (main lab).

STEP	R1 - R3 (iBGP)	R2 - R3 (iBGP)	R1 - R4 (eBGP)	R2 - R5 (eBGP)
0	pcap	pcap	pcap	pcap
1	pcap	pcap	pcap	pcap
2	pcap	pcap	pcap	pcap
3	pcap	pcap	pcap	pcap
4	pcap	pcap	pcap	pcap
5	pcap	pcap	pcap	pcap
6	pcap	pcap	pcap	pcap

Follow-Up Lab (STEP 0 to 3)

STEP 0: Initial state (all three routers at localpref 100)

Router	show output	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	—
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—
R5	show	log	run	—	trace	—

STEP 1: bgp default local-preference 150 on R1

Router	show output	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	commit
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—
R5	show	log	run	—	trace	—

STEP 2: clear bgp ipv4 unicast <peer> soft out from R1 to both iBGP peers

Router	show output	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	exec
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—
R5	show	log	run	—	trace	—

STEP 3: The default removed (final state)

Router	show output	syslog	running-config	ping	trace	commit
R1	show	log	run	ping	trace	commit
R2	show	log	run	—	trace	—
R3	show	log	run	ping	trace	—
R4	show	log	run	ping	trace	—
R5	show	log	run	—	trace	—

Packet captures are taken per STEP on four segments (follow-up lab).

STEP	R1 - R3 (iBGP)	R2 - R3 (iBGP)	R1 - R4 (eBGP)	R2 - R5 (eBGP)
0	pcap	pcap	pcap	pcap
1	pcap	pcap	pcap	pcap
2	pcap	pcap	pcap	pcap
3	pcap	pcap	pcap	pcap

References

Document	Title	Summary
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	Section 4.3 e) defines `LOCAL_PREF` as a well-known attribute that is a four-octet unsigned integer, and the table in section 5 lists it as required towards iBGP. Section 5.1.5 requires it on iBGP, forbids it on eBGP and mandates ignoring it when received from an external peer; section 9.1.1 defines the calculation of the degree of preference (for routes from external peers the policy’s return value must be used as the `LOCAL_PREF` in iBGP readvertisement, and computing it locally for routes from internal peers may form persistent routing loops).
RFC 4451	BGP MULTI_EXIT_DISC (MED) Considerations	Clarifies how MED is compared; the natural counterpart for understanding how `LOCAL_PREF` differs in role.
RFC 7454	BGP Operations and Security	Operational recommendations, including route preference control with `LOCAL_PREF`.
IANA	Border Gateway Protocol (BGP) Parameters	The registry of path attribute type codes.