The Border Gateway Protocol (BGP) local-preference value gets altered to some junk value due to inter-relation between the local-preference and preference2 attributes of a BGP route.
This article describes the issue in detail and recommends not setting the preference2 attribute for a BGP route policy to avoid the problem.
Test Topology
xe-2/0/0 ----------- xe-2/0/1 xe-2/0/2 ------------ xe-2/0/3 [MX]<----------- ebgp ----------->[LSYS1]<----------- ibgp ----------->[LSYS2] AS65412 AS65000 import policy:preference2=250 localpref=550 localpref= 4294967045 172.27.0.0/16 --------------------------->--------------------------->
Sample MX Configuration
User@MX> show configuration |display set set logical-systems LSYS1 interfaces xe-2/0/1 unit 0 family inet address 192.168.10.2/24 set logical-systems LSYS1 interfaces xe-2/0/2 unit 0 family inet address 192.168.20.1/24 set logical-systems LSYS1 interfaces lo0 unit 1 family inet address 10.10.10.1/32 set logical-systems LSYS1 protocols bgp group ext type external set logical-systems LSYS1 protocols bgp group ext neighbor 192.168.10.1 peer-as 65412 set logical-systems LSYS1 protocols bgp group int type internal set logical-systems LSYS1 protocols bgp group int local-address 10.10.10.1 set logical-systems LSYS1 protocols bgp group int export nhs set logical-systems LSYS1 protocols bgp group int neighbor 10.10.10.2 set logical-systems LSYS1 protocols ospf area 0.0.0.0 interface lo0.1 set logical-systems LSYS1 protocols ospf area 0.0.0.0 interface xe-2/0/2.0 interface-type p2p set logical-systems LSYS1 policy-options policy-statement nhs term 1 from protocol bgp set logical-systems LSYS1 policy-options policy-statement nhs term 1 from neighbor 192.168.10.1 set logical-systems LSYS1 policy-options policy-statement nhs term 1 then local-preference 550 set logical-systems LSYS1 policy-options policy-statement nhs term 1 then next-hop self set logical-systems LSYS1 policy-options policy-statement nhs term 1 then accept set logical-systems LSYS1 routing-options autonomous-system 65000 set logical-systems LSYS2 interfaces xe-2/0/3 unit 0 family inet address 192.168.20.2/24 set logical-systems LSYS2 interfaces lo0 unit 2 family inet address 10.10.10.2/32 set logical-systems LSYS2 protocols bgp group int type internal set logical-systems LSYS2 protocols bgp group int local-address 10.10.10.2 set logical-systems LSYS2 protocols bgp group int import bgp-import set logical-systems LSYS2 protocols bgp group int neighbor 10.10.10.1 set logical-systems LSYS2 protocols ospf area 0.0.0.0 interface xe-2/0/3.0 interface-type p2p set logical-systems LSYS2 protocols ospf area 0.0.0.0 interface lo0.2 set logical-systems LSYS2 policy-options policy-statement bgp-import term accept-lp from local-preference 550 set logical-systems LSYS2 policy-options policy-statement bgp-import term accept-lp then accept set logical-systems LSYS2 routing-options autonomous-system 65000 set interfaces xe-2/0/0 unit 0 family inet address 192.168.10.1/24 set interfaces lo0 unit 0 family inet address 172.27.0.1/16 set routing-options autonomous-system 65412 set protocols bgp group ext type external set protocols bgp group ext export bgp-export set protocols bgp group ext neighbor 192.168.10.2 peer-as 65000 set policy-options prefix-list adv_route 172.27.0.0/16 set policy-options policy-statement bgp-export term 1 from prefix-list adv_route set policy-options policy-statement bgp-export term 1 then accept
Test Steps
User@MX> show configuration logical-systems LSYS1 policy-options policy-statement nhs { term 1 { from { protocol bgp; neighbor 192.168.10.1; } then { local-preference 550; next-hop self; accept; } } } User@MX> show configuration logical-systems LSYS2 policy-options policy-statement bgp-import { term accept-lp { from local-preference 550; then accept; } }
Note that LSYS2 is receiving the route with localpref 550 when the preference2 value is at its default value or is unchanged.
User@MX> show route 172.27.0.0/16 logical-system LSYS2 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.27.0.0/16 *[BGP/170] 00:02:26, localpref 550, from 10.10.10.1 AS path: 65412 I, validation-state: unverified > to 192.168.20.1 via xe-2/0/3.0
However, when preference2 is set to 250 , LSYS2 receives the route with localpref 4294967045 .
[edit] User@MX# set logical-systems LSYS2 policy-options policy-statement bgp-import term accept-lp then preference2 250 [edit] User@MX# show |compare [edit logical-systems LSYS2 policy-options policy-statement bgp-import term accept-lp then] + preference2 250; [edit] User@MX# commit commit complete User@MX> show route 172.27.0.0/16 logical-system LSYS2 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.27.0.0/16 *[BGP/170] 00:00:31, localpref 4294967045, from 10.10.10.1 AS path: 65412 I, validation-state: unverified > to 192.168.20.1 via xe-2/0/3.0
The local-preference value is calculated as (POLICY_MAX_METRIC - preference2), where POLICY_MAX_METRIC = 0xFFFFFFFF. However, when there is a preference2 attribute, the show route command displays localpref as [FFFFFFFF - (preference2)]. In our example, localpref would be (POLICY_MAX_METRIC (4294967295) - 250) = 4,294,967,045 as printed in the show route output above. As you can see, the local-preference value is seen to depend on the value of preference2, and is calculated as per the specified formula.
show route
localpref
Generally, the local-preference value should not be altered when the preference2 value is changed, because users have not made any changes to the local-preference value, and may expect it to remain the same. Also, local-preference is a separate attribute that is carried in BGP across routers and its value remains independent of any other entities (such as preference2). However, because of the code limitation in Junos OS release 18.1, the preference2 value cannot be added/altered for a BGP route by using a route policy without any impact on the local-preference value.
Further, due to the said code limitation, we can even see the same behavior the other way around as well. When the local-preference value is set to some non-default value on imported prefixes, the preference2 value gets altered to some junk value starting with (-) "minus." Thus, altering local-preference value is also seen to similarly affect the preference2 value of a BGP route.
User@MX> show configuration logical-systems LSYS1 policy-options policy-statement nhs { term 1 { from { protocol bgp; neighbor 192.168.10.1; } then { preference2 150; next-hop self; accept; } } } User@MX> show configuration logical-systems LSYS2 policy-options policy-statement bgp-import { term accept-lp { from preference2 150; then accept; } } User@MX> show route 172.27.0.0/16 detail logical-system LSYS2 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) 172.27.0.0/16 (1 entry, 1 announced) *BGP Preference: 170/150 Next hop type: Indirect, Next hop index: 0 Address: 0x5c90b50 Next-hop reference count: 2 Source: 10.10.10.1 [edit] User@MX# set logical-systems LSYS2 policy-options policy-statement bgp-import term accept-lp then local-preference 200 [edit] User@MX# show |compare [edit logical-systems LSYS2 policy-options policy-statement bgp-import term accept-lp then] + local-preference 200; [edit] User@MX# commit commit complete User@MX> show route 172.27.0.0/16 detail logical-system LSYS2 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) 172.27.0.0/16 (1 entry, 1 announced) *BGP Preference: 170/-201 Next hop type: Indirect, Next hop index: 0 Address: 0x5c90b50 Next-hop reference count: 3 Source: 10.10.10.1
This behavior is expected as per the Junos OS software implementation.
However, it is recommended that users do not set the preference2 attribute for the BGP route policy or manipulate the preference2 value in a policy because it can alter the local-preference value.
For more information about routing policy conditions and protocols preference configuration, refer to the following:
Routing Policy Match Conditions
preference (Protocols BGP)
2022-12-05: Updated non-compliant IP addresses to RFC standards.