BGP LOCAL_PREF Attribute

What LOCAL_PREF Is

LOCAL_PREF (LOCAL_PREFERENCE, Type code 5) is the path attribute used to make every router in the local AS agree on which exit to use. As covered in BGP Path Attributes and Best Path Selection, it is classified as well-known discretionary.

“Well-known” means every implementation understands it; “discretionary” means whether it goes into an UPDATE is up to the implementation. That discretion is not open-ended, though: RFC 4271 section 5.1.5 requires it to always be included in UPDATEs to iBGP peers and never to eBGP peers. The discretion is in the sense that the include/omit decision is settled by the kind of peer.

Item	Description
Type code	5
Classification	Well-known discretionary
Value	A 4-byte unsigned integer. Higher is preferred
Default	100 (in most implementations, IOS XR included)
Propagation scope	Within the local AS only (carried on iBGP, never on eBGP)
Definition	RFC 4271 section 5.1.5

It Is Never Carried on eBGP

The rule that decides the character of LOCAL_PREF is this “never put it on eBGP.” RFC 4271 section 5.1.5 states three things.

Situation	Rule
Advertising to an iBGP peer	`LOCAL_PREF` must be included
Advertising to an eBGP peer	`LOCAL_PREF` must not be included
Received from an eBGP peer	Ignore it even if present

In other words, LOCAL_PREF is a value that only has meaning inside the local AS. A border router attaches it to routes learned from outside and distributes them over iBGP, which makes every router in the AS choose the same exit. Conversely, it is not a way to tell a neighboring AS “please come in this way.” That is what MED is for.

Traced through the verification lab below, it goes like this. The UPDATE that arrives from R5 in AS 65003 carries no LOCAL_PREF, and border router R2 attaches 200 with an inbound policy. That value travels over iBGP to R1 and R3 inside the AS, but it is left out again when R1 advertises to R4 in AS 65002.

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

Each path attribute propagates over a different scope, and LOCAL_PREF sits at “inside the local AS only.”

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 neighboring AS (by default not passed beyond it)
`AS_PATH`	Every AS the route traverses

Where It Sits in Best Path Selection

LOCAL_PREF is evaluated second in best path selection. In the order given in BGP Path Attributes and Best Path Selection, it comes right after WEIGHT (Cisco-specific, first) 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. That expresses an operational requirement — “it is the long way round in AS_PATH terms, but that circuit is cheaper or fatter” — directly. The verification below confirms this on real hardware.

The Default of 100 and the Direction of Comparison

In most implementations, IOS XR included, the default LOCAL_PREF is 100. Routes received over eBGP arrive without a LOCAL_PREF, so the receiving router assigns its own default. When show bgp displays localpref 100 on an externally learned route, that is a value the receiver attached itself, not something the sender said.

The direction of comparison is the opposite of MED: higher wins. Since the two are easy to mix up, it helps to remember them together with their roles.

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

Configuration

On IOS XR you normally use set local-preference in the inbound policy of an eBGP neighbor. That reads as “prefer (or de-prefer) routes coming from this neighboring AS.”

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. Use it when you want a blanket adjustment — “lower the preference of everything this router receives” — without writing an individual policy.

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

Verification on Real Hardware

Using a lab of five XRd (IOS XR 26.1.1) routers, we confirm the following four points.

That LOCAL_PREF outranks AS_PATH length (you can make the longer AS_PATH win)
That the value you set propagates across the AS over iBGP so every router in the AS faces the same exit
That when the values tie, the next comparison (AS_PATH length) decides
That LOCAL_PREF is never carried to an eBGP peer (setting it in an outbound policy is ignored)

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

The key points of the setup are as follows.

R4 (AS 65002) advertises 192.168.4.0/24. We follow which exit AS 65001 uses to reach it
AS 65001 sees two paths: straight out to AS 65002 via R1 with AS_PATH 65002 (shorter), and the long way round through AS 65003 via R2 with AS_PATH 65003 65002
R3 is not a border router. Which exit this internal router faces is the indicator of whether LOCAL_PREF is working across the whole AS
The iBGP inside AS 65001 is a Loopback0-to-Loopback0 full mesh with next-hop-self (see BGP 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

Here is what changes in each STEP. Only R1 and R2 are reconfigured.

STEP	Operation
0	Only the `PASS-ALL` policy (initial state)
1	`LOCAL_PREF 200` inbound on R2 toward R5
2	`LOCAL_PREF 200` inbound on R1 toward R4 as well (making them tie)
3	`set local-preference 200` outbound on R1 toward R4
4	Remove everything (the configuration returns to exactly STEP 0)

Packet captures are taken at three points (all with tcp port 179). The R1 - R3 link is inside AS 65001 and carries the R1 - R3 iBGP session; the R1 - R4 and R2 - R5 links are eBGP.

STEP 0: The Shorter AS_PATH via R1 Wins

Here is the view from R3 inside the AS. 192.168.4.0/24 goes via 10.0.0.1 (R1), and LocPrf is the default 100.

R3 (internal to AS 65001): show bgp
BGP router identifier 10.0.0.3, local AS number 65001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 8
BGP main routing table version 8
BGP NSR Initial initsync version 3 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   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

Processed 5 prefixes, 5 paths

What decides this is border router R2. R2 holds two paths for 192.168.4.0/24, both with LOCAL_PREF 100, so the next comparison — AS_PATH length — settles it. Its own eBGP path (65003 65002, two entries) is longer than the iBGP path from R1 (65002, one entry), so R2 does not use its own circuit; it chooses the path via R1.

R2 (border): show bgp 192.168.4.0/24
BGP routing table entry for 192.168.4.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  8            8
Last Modified: Sep  7 22:35:58.774 for 00:04:11
Paths: (2 available, best #1)
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.2.5.5        
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.2.5.5        
  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
      Received Path ID 0, Local Path ID 1, version 8
  Path #2: Received by speaker 0
  Not advertised to any peer
  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
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

Here is the traceroute from R3. It goes through R1 (10.1.3.1) to R4 (10.1.4.4) in two hops.

R3: traceroute 192.168.4.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.4.1

 1  10.1.3.1 6 msec  5 msec  5 msec 
 2  10.1.4.4 8 msec  *  9 msec

iBGP UPDATEs Do Carry LOCAL_PREF

No.49 in the R1 - R3 capture (bgp-local-pref-r1r3.pcap) is an UPDATE R1 sent to an iBGP peer. It contains Path Attribute - LOCAL_PREF: 100. The output below is Wireshark’s tshark detail view, with the flag bit breakdown elided as <snip>.

No.49 R1 → R2 UPDATE (iBGP, 192.168.1.0/24) tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 61
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 38
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.0.1
                IPv4 Address: 10.0.0.1
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.1.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.1.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: empty
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 0
        Path Attribute - MULTI_EXIT_DISC: 0
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0
        Path Attribute - LOCAL_PREF: 100
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: LOCAL_PREF (5)
            Length: 4
            Local preference: 100

Download the pcap of the packet in the tshark output above (No.49, an iBGP UPDATE)

STEP 1: Making the Longer AS_PATH Win

We attach LOCAL_PREF 200 to the routes R2 receives from R5.

R2: show rpl route-policy LP-200
route-policy LP-200
  set local-preference 200
  pass
end-policy
!

R2: show running-config (the neighbor 10.2.5.5 part)
 neighbor 10.2.5.5
  remote-as 65003
  description eBGP to R5 (AS 65003)
  address-family ipv4 unicast
   route-policy LP-200 in
   route-policy PASS-ALL out
   soft-reconfiguration inbound always
  !
 !

Here is R2’s BGP table. The important thing is that the same route appears twice: Path #1 is after the inbound policy (localpref 200), and Path #2 is (received-only) — the raw state as received from R5 (localpref 100). The difference between those two lines shows that no LOCAL_PREF arrived over eBGP and that R2 had assigned its own default of 100.

R2: show bgp 192.168.4.0/24
BGP routing table entry for 192.168.4.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  9            9
Last Modified: Sep  7 22:42:41.774 for 00:02:46
Paths: (2 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 
  65003 65002
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, localpref 200, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 9
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Not advertised to any peer
  65003 65002, (received-only)
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

R3, which was not configured at all, follows this value too. Its 192.168.4.0/24 switches to the path via 10.0.0.2 (R2), whose AS_PATH is 65003 65002 — the longer one. This confirms that LOCAL_PREF is evaluated before AS_PATH length.

R3 (internal to AS 65001): show bgp 192.168.4.0/24
BGP routing table entry for 192.168.4.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  9            9
Last Modified: Sep  7 22:42:42.774 for 00:03:13
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  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
      Received Path ID 0, Local Path ID 1, version 9

R3’s traceroute grows from two hops to three, detouring via R2 (10.2.3.2) → R5 (10.2.5.5) → R4 (10.4.5.4).

R3: traceroute 192.168.4.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.4.1

 1  10.2.3.2 5 msec  4 msec  4 msec 
 2  10.2.5.5 6 msec  6 msec  7 msec 
 3  10.4.5.4 9 msec  *  12 msec

R1 is the more extreme case. R1 has a direct eBGP session with R4, yet it prefers the LOCAL_PREF 200 path, so it ignores the circuit right in front of it and doubles back across the AS to leave via R2 — four hops.

R1 (the border router directly connected to R4): traceroute 192.168.4.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.4.1

 1  10.1.3.3 8 msec  5 msec  5 msec 
 2  10.2.3.2 8 msec  8 msec  8 msec 
 3  10.2.5.5 13 msec  10 msec  11 msec 
 4  10.4.5.4 12 msec  *  13 msec

Nothing Reaches Outside AS 65001

At this point LOCAL_PREF 200 is shared inside AS 65001, but nothing at all has reached the neighboring AS. The routes R4 holds that came from AS 65001 still show localpref 100 — R4’s own default.

R4 (AS 65002): show bgp 192.168.1.0/24
BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  6            6
Last Modified: Sep  7 22:35:58.774 for 00:10:21
Paths: (2 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  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
      Received Path ID 0, Local Path ID 1, version 6
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Not advertised to any peer
  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
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

Inside the AS, on the other hand, it is carried properly. No.98 in the R1 - R3 capture is an UPDATE from R2 to R1 and contains Path Attribute - LOCAL_PREF: 200.

No.98 R2 → R1 UPDATE (iBGP, 192.168.4.0/24) tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 64
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 41
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.0.2
                IPv4 Address: 10.0.0.2
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.4.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.4.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65003 65002 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: 65003 65002
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 2
                AS4: 65003
                AS4: 65002
        Path Attribute - LOCAL_PREF: 200
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: LOCAL_PREF (5)
            Length: 4
            Local preference: 200

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

STEP 2: With a Tie, the Next Comparison Decides

We add the same LOCAL_PREF 200 to R1’s inbound policy toward R4, which makes both exits equal.

Three paths now line up in R2’s BGP table. Path #1 (iBGP from R1, AS_PATH 65002) and Path #2 (its own eBGP, AS_PATH 65003 65002) both have localpref 200, so LOCAL_PREF does not settle it. The next comparison, AS_PATH length, makes the shorter Path #1 the best.

R2: show bgp 192.168.4.0/24
BGP routing table entry for 192.168.4.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 11           11
Last Modified: Sep  7 22:47:22.774 for 00:02:41
Paths: (3 available, best #1)
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.2.5.5        
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.2.5.5        
  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
      Received Path ID 0, Local Path ID 1, version 11
  Path #2: Received by speaker 0
  Not advertised to any peer
  65003 65002
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, localpref 200, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #3: Received by speaker 0
  Not advertised to any peer
  65003 65002, (received-only)
    10.2.5.5 from 10.2.5.5 (10.0.0.5)
      Origin IGP, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

R3 is back on the path via 10.0.0.1 (R1) with localpref 200 and AS_PATH 65002, and the traceroute is back to two hops.

R3: show bgp 192.168.4.0/24
BGP routing table entry for 192.168.4.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 11           11
Last Modified: Sep  7 22:47:22.774 for 00:03:10
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  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
      Received Path ID 0, Local Path ID 1, version 11

R3: traceroute 192.168.4.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.4.1

 1  10.1.3.1 6 msec  4 msec  4 msec 
 2  10.1.4.4 8 msec  *  10 msec

STEP 3: Setting It Outbound Does Not Put It on eBGP

We apply a policy containing set local-preference 200 to R1’s outbound direction toward R4 — the very operation RFC 4271 section 5.1.5 says must not be included in an UPDATE to an eBGP peer. IOS XR accepts the configuration and the commit succeeds, but it emits a warning syslog the moment it takes effect.

R1: show logging start Sep 7 22:49:46 (the STEP 3 range)
Time Zone UTC, DST disabled
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    Console logging: Disabled
    Monitor logging: level debugging, 0 messages logged
    Trap logging: level informational, 0 messages logged
    Buffer logging: level debugging, 88 messages logged

Log Buffer (2097152 bytes):

RP/0/RP0/CPU0:Sep  7 22:49:46.341 UTC: logger[68210]: %OS-SYSLOG-6-LOG_INFO : informational STEP3-BEGIN 
RP/0/RP0/CPU0:Sep  7 22:51:53.296 UTC: config[68447]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000007' to view the changes. 
RP/0/RP0/CPU0:Sep  7 22:51:53.414 UTC: config[68447]: %MGBL-SYS-5-CONFIG_I : Configured from console by cisco 
RP/0/RP0/CPU0:Sep  7 22:51:55.711 UTC: config[68462]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000008' to view the changes. 
RP/0/RP0/CPU0:Sep  7 22:51:55.843 UTC: config[68462]: %MGBL-SYS-5-CONFIG_I : Configured from console by cisco 
RP/0/RP0/CPU0:Sep  7 22:51:59.390 UTC: bgp[1084]: %ROUTING-BGP-4-POLICY_EBGP : Local-preference modification operations in Outbound IPv4 Unicast policy "LP-OUT-200" will be ignored for external neighbor/update-group default-IPv4-Uni-UpdGrp-0.1-Out 
RP/0/RP0/CPU0:Sep  7 22:54:21.500 UTC: config[68652]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000009' to view the changes. 
RP/0/RP0/CPU0:Sep  7 22:54:21.714 UTC: config[68652]: %MGBL-SYS-5-CONFIG_I : Configured from console by cisco

It states explicitly that local-preference modification in an outbound policy for an external neighbor will be ignored. And indeed, in the packets the LOCAL_PREF attribute is simply not there. No.87 in the R1 - R4 capture (bgp-local-pref-r1r4.pcap) is the UPDATE R1 resent to R4 right after the policy was applied. The single TCP segment carries four UPDATEs; the third one, for 192.168.1.0/24, is shown here. Its attributes are MP_REACH_NLRI, ORIGIN, AS_PATH and MULTI_EXIT_DISC — there is no LOCAL_PREF anywhere.

No.87 R1 → R4 UPDATE (eBGP, 192.168.1.0/24, after set local-preference was applied outbound) tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 60
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 37
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.1.4.1
                IPv4 Address: 10.1.4.1
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.1.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.1.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65001 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 65001
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 1
                AS4: 65001
        Path Attribute - MULTI_EXIT_DISC: 0
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0

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

The same holds across the whole captures. On the two eBGP links (R1 - R4 and R2 - R5), not a single UPDATE carries a LOCAL_PREF attribute for the entire run. On the R1 - R3 link inside the AS, every UPDATE has one.

Capture	Segment	UPDATEs containing `LOCAL_PREF`
`bgp-local-pref-r1r3.pcap`	R1 - R3 (inside AS 65001, iBGP)	Yes (100 / 200)
`bgp-local-pref-r1r4.pcap`	R1 - R4 (eBGP)	None
`bgp-local-pref-r2r5.pcap`	R2 - R5 (eBGP)	None

STEP 4: Removing the Policies

We remove every policy from R1 and R2, leaving only PASS-ALL. The running-config of all five routers matches STEP 0, and LocPrf is back to the default 100.

R3: show bgp
BGP router identifier 10.0.0.3, local AS number 65001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 16
BGP main routing table version 16
BGP NSR Initial initsync version 3 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   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

Processed 5 prefixes, 5 paths

R3: traceroute 192.168.4.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.4.1

 1  10.1.3.1 25 msec  5 msec  5 msec 
 2  10.1.4.4 9 msec  *  11 msec

In the verification for BGP AS_PATH Attribute, removing the policy did not restore the best path and a session reset was needed. There, several eBGP paths tied and the “route age” tie-break decided. Here the higher-ranked comparison itself changes, so the best path reverts the moment the configuration is removed.

Here is a summary of the results by STEP.

STEP	R1’s LOCAL_PREF config	R2’s LOCAL_PREF config	R3’s chosen `192.168.4.0/24`	R3 traceroute	R1 traceroute
0	none	none	via R1 `65002` / LocPrf 100	2 hops	1 hop
1	none	inbound 200	via R2 `65003 65002` / LocPrf 200	3 hops	4 hops
2	inbound 200	inbound 200	via R1 `65002` / LocPrf 200	2 hops	1 hop
3	inbound 200 + outbound 200	inbound 200	via R1 `65002` / LocPrf 200	2 hops	1 hop
4	none	none	via R1 `65002` / LocPrf 100	2 hops	1 hop

Adding the outbound setting in STEP 3 changed nothing, either inside AS 65001 or in the neighboring AS. That row is what shows LOCAL_PREF to be an attribute that only means anything inbound.

Verification Configurations and show Output

For every STEP, the following three kinds of output were collected from all five routers, split per router. 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` / `show route bgp` / `show bgp` / `show bgp summary` / `show bgp <prefix>` (for 5 prefixes) / `show bgp neighbor` / `show bgp neighbors <peer> advertised-routes` / `show bgp neighbors <peer> routes` / `show bgp neighbors <peer> received routes` / `show bgp update-group` / `show rpl route-policy` / `show ospf neighbor` (R1, R2 and R3 only) / `traceroute`
`..._log.txt`	`show logging` narrowed to that STEP’s range. A marker was inserted with `logmsg` at the start of each STEP and its timestamp passed to `show logging start`. STEP 0 alone is the full history from boot (including the BGP and OSPF adjacencies coming up)
`..._run.txt`	`show running-config` at that STEP (that is, the verification configuration for that STEP)

In the final state (STEP 4) the only policy is PASS-ALL, and the running-config of all five routers matches STEP 0.

STEP 0: initial state (the shorter AS_PATH via R1)

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run

STEP 1: LOCAL_PREF 200 applied inbound on R2 toward R5

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run

STEP 2: LOCAL_PREF 200 applied inbound on R1 toward R4 as well

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run

STEP 3: set local-preference 200 applied outbound on R1 toward R4

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run

STEP 4: all policies removed (final state, configuration identical to STEP 0)

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run

The full captures are below. They contain every UPDATE from STEP 0 through STEP 4.

Download the full capture on the R1 - R3 link (inside AS 65001, iBGP)

Download the full capture on the R1 - R4 link (eBGP)

Download the full capture on the R2 - R5 link (eBGP)

References

Document	Title	Overview
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	Section 5.1.5 defines `LOCAL_PREF`: always include it toward iBGP peers, never toward eBGP peers, and ignore it if received from outside. Section 9.1.1 defines its place in best path selection.
RFC 4451	BGP MULTI_EXIT_DISC (MED) Considerations	A document clarifying the conditions under which MED is compared. It pairs with `LOCAL_PREF` for understanding the difference in their roles.
RFC 7454	BGP Operations and Security	Operational recommendations, including route preference control using `LOCAL_PREF`.
IANA	Border Gateway Protocol (BGP) Parameters	The registry of path attribute type codes.