Local Preference is used to choose the best path out of our network. It is typically applied to inbound route advertisements to influence how traffic leaves our network. The local preference attribute is advertised over iBGP to other routers within our AS.
On Junos, local preference is configured using a routing policy. We will see how to do this in the following examples.
Setting the local preference value without using policy is explored in examples 6 and 7.
Lab Environment
The lab is set up as per the below diagram. This is the same as the prepending example.
- vMX-1 and vMX-2 belong to AS 65002.
- vMX-3 belongs to AS 65001.
- iBGP is already configured between vMX-1 and vMX-2
- eBGP is already configured between vMX-2 and vMX-3.
- vMX-1 is advertising 172.16.101.0/24, 172.16.102.0/24, and 172.16.103.0/24 to vMX-2
- vMX-3 is advertising 172.17.201.0/24, 172.17.202.0/24, and 172.17.203.0/24 to vMX-2
Lab Baseline
On vMX-2 we have six BGP routes. Three routes are from vMX-1 and three from vMX-2. In the following examples, we will change the local preference for the routes vMX-2 receives from vMX-3.
All of the routes have the default local preference of 100.
lab@vMX-2> show route protocol bgp
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.101.0/24 *[BGP/170] 01:07:18, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.102.0/24 *[BGP/170] 01:07:18, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.103.0/24 *[BGP/170] 01:07:18, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.17.201.0/24 *[BGP/170] 01:03:33, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.202.0/24 *[BGP/170] 01:03:33, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.203.0/24 *[BGP/170] 01:03:33, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-2> Example 1 – Setting Local Preference On All Routes
In this first example, we will set local preference on all routes vMX-2 receives from vMX-3. We will increase it to 120.
The first step is to create a policy to modify the local preference attribute.
lab@vMX-2> edit
Entering configuration mode
[edit]
lab@vMX-2# set policy-options policy-statement my-set-local-pref term set-lpref then local-preference 120
[edit]
lab@vMX-2# show policy-options policy-statement my-set-local-pref
term set-lpref {
then {
local-preference 120;
}
}
[edit]
lab@vMX-2#There are a couple of things to note about this policy. The term set-lpref does not have a match statement so it will match on all routes. It doesn’t have a terminating action either, so the routes will continue to be processed by later terms or policies.
Next, we need to apply the policy to our BGP peer. In this case, we will set the import policy at the group level.
[edit]
lab@vMX-2# set protocols bgp group my-external-group import my-set-local-pref
[edit]
lab@vMX-2# show protocols bgp
group my-external-group {
type external;
import my-set-local-pref;
authentication-key "$9$7mdw2ZUH5Qn4aQn/CB17-V"; ## SECRET-DATA
peer-as 65001;
neighbor 192.168.2.1;
}
group my-internal-group {
type internal;
local-address 172.16.1.2;
authentication-key "$9$GSjkmz39O1hfT1hSr8LGDi"; ## SECRET-DATA
export fix-nhs;
neighbor 172.16.1.1;
}
[edit]
lab@vMX-2# commit
commit complete
[edit]
lab@vMX-2# Example 1 – Validation
We can validate this by looking at the local preference of the routes.
vMX-2
lab@vMX-2> show route protocol bgp
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.101.0/24 *[BGP/170] 01:15:33, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.102.0/24 *[BGP/170] 01:15:33, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.103.0/24 *[BGP/170] 01:15:33, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.17.201.0/24 *[BGP/170] 00:01:06, localpref 120
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.202.0/24 *[BGP/170] 00:01:06, localpref 120
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.203.0/24 *[BGP/170] 00:01:06, localpref 120
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-2>The policy has worked, the three routes we learned from vMX-3 have their local preference set to 120.
Example 2 – Setting Local Preference On Specific Routes
Sometimes we only want to change local preference for a few specific routes. We can match a particular route using a route filter as shown.
We will modify the existing policy to only affect the 172.17.202.0/24 route.
[edit]
lab@vMX-2# show policy-options policy-statement my-set-local-pref
term set-lpref {
then {
local-preference 120;
}
}
[edit]
lab@vMX-2# set policy-options policy-statement my-set-local-pref term set-lpref from route-filter 172.17.202.0/24 exact
[edit]
lab@vMX-2# show policy-options policy-statement my-set-local-pref
term set-lpref {
from {
route-filter 172.17.202.0/24 exact;
}
then {
local-preference 120;
}
}
[edit]
lab@vMX-2# commit
commit complete
[edit]
lab@vMX-2#Since the policy now has a match statement the local preference will only be changed for the 172.17.202.0/24 route.
Example 2 – Validation
We can validate this change by looking at the routes on vMX-2.
vMX-2
lab@vMX-2> show route protocol bgp
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.101.0/24 *[BGP/170] 01:21:27, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.102.0/24 *[BGP/170] 01:21:27, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.103.0/24 *[BGP/170] 01:21:27, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.17.201.0/24 *[BGP/170] 00:01:34, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.202.0/24 *[BGP/170] 00:07:00, localpref 120
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.203.0/24 *[BGP/170] 00:01:34, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-2> As expected, only the route route to 172.17.202.0/24 had its local preference value changed.
Example 3 – Effects Of Setting Local Preference In Multiple Terms Or Policies
What happens if we set local preference in multiple terms or policies? What do you think the following policy on vMX-2 will do to the routes received from vMX-3?
[edit]
lab@vMX-2# show policy-options policy-statement my-set-local-pref
term set-lpref-for-all {
then {
local-preference 120;
}
}
term set-lpref-for-specifics {
from {
route-filter 172.17.202.0/24 exact;
}
then {
local-preference 150;
}
}
[edit]
lab@vMX-2#Think about this before reading on to see the results.
Example 3 – Validation
We see the following results on the routers.
vMX-2
lab@vMX-2> show route protocol bgp
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.101.0/24 *[BGP/170] 01:26:08, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.102.0/24 *[BGP/170] 01:26:08, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.103.0/24 *[BGP/170] 01:26:08, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.17.201.0/24 *[BGP/170] 00:01:26, localpref 120
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.202.0/24 *[BGP/170] 00:01:26, localpref 150
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.203.0/24 *[BGP/170] 00:01:26, localpref 120
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-2> Did you guess correctly that the 172.17.202.0/24 route would have a local preference of 150?
The reason this occurs is that our policy is not using any terminating actions.
As the routes are processed through the first term in our policy, they will all have their local preference set to 120. Due to no terminating action, they will “fall through” and continue to be processed by later terms and policies.
The second term matches the 172.17.202.0/24 route and sets the local preference to 150. Again, there is no terminating action so the routes continue to be evaluated.
Once the routes have been evaluated by all the terms in the policy, they start to be evaluated by the next policy. In this case, the next policy is the Junos default BGP policy which accepts all BGP routes.
Example 4 – Adding Or Subtracting A Value From Local Preference
With local preference, we can also add or subtract a value from the existing local preference.
Remember that eBGP does not include local preference when it advertises a route. So vMX-2 will set it to the default of 100 when it receives the routes from vMX-3.
What do you think the following policy will do?
[edit]
lab@vMX-2# show policy-options policy-statement my-set-local-pref
term set-lpref-for-all {
then {
local-preference 120;
}
}
term add-30-to-lpref {
from {
route-filter 172.17.202.0/24 exact;
}
then {
local-preference add 30;
}
}
term subtract-20-from-lpref {
from {
route-filter 172.17.203.0/24 exact;
}
then {
local-preference subtract 20;
}
}
[edit]
lab@vMX-2#Take a moment to think about this carefully, what will local preference be set to for the three routes we learn from vMX-3?
Example 4 – Validation
You can see the results below, does it match what you expected?
lab@vMX-2> show route protocol bgp
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.101.0/24 *[BGP/170] 01:45:42, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.102.0/24 *[BGP/170] 01:45:42, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.103.0/24 *[BGP/170] 01:45:42, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.17.201.0/24 *[BGP/170] 00:21:00, localpref 120
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.202.0/24 *[BGP/170] 00:21:00, localpref 150
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.203.0/24 *[BGP/170] 00:00:10, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-2>Depending on what you were expecting, these results can feel wrong. So let’s look at what is happening here.
As noted earlier, because the routes are being learned via eBGP they do not have a local preference attribute, so vMX-2 sets it to the default of 100.
As the routes are processed through the import policy the first term sets the local preference to 120 for all of the routes.
The lack of a terminating accept or reject action means the routes get processed by the other terms.
The second term matches 172.17.202.0/24 and adds 30 to the local preference value of 120, making it 150. The other two routes are not matched by this term.
The third term matches 172.17.203.0/24 and subtracts 20 from the current value of 120, making local preference 100, the same as the default value. This term doesn’t match the other two routes so they are unaffected. Without a terminating action, the routes fall through to the default BGP policy and are accepted.
Example 5 – Preference Versus Local Preference
Something to be aware of on Junos is the difference between route preference and local preference.
Route preference is relevant when we learn the same route from different protocols. Local preference is a BGP attribute attached to a route.
It can be easy to mix these two up and have a policy like this:
vMX-2
[edit]
lab@vMX-2# show policy-options policy-statement my-set-local-pref
term set-lpref-for-all {
then {
local-preference 120;
}
}
term set-lpref-for-specifics {
from {
route-filter 172.17.202.0/24 exact;
}
then {
preference 150;
}
}
[edit]
lab@vMX-2#Example 5 – Validation
This is what the BGP routes look like on vMX-2 with the above policy applied.
lab@vMX-2> show route protocol bgp
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.101.0/24 *[BGP/170] 02:03:53, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.102.0/24 *[BGP/170] 02:03:53, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.103.0/24 *[BGP/170] 02:03:53, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.17.201.0/24 *[BGP/170] 00:39:11, localpref 120
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.202.0/24 *[BGP/150] 00:03:56, localpref 120
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.203.0/24 *[BGP/170] 00:03:56, localpref 120
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-2> Can you spot what has happened here?
All three BGP routes learned from vMX-3 have had their local preference set to 120. The specific route 172.17.202.0/24 was matched by the second term of the policy and had its route preference changed to 150, instead of its local preference.
Example 6 – Setting Local Preference Without Using Policy
In this example, we will use the local-preference command, which can be configured at the BGP group level or an individual peer level.
Be warned, this command doesn’t behave the way that you might expect it to.
Instead of setting the local preference on the routes we learn from a peer, it sets the local preference value on routes we advertise to that group or peer.
It has no effect when applied against an eBGP peer, as local preference values are not sent over eBGP sessions.
We need to set this on the iBGP session towards vMX-1.
Before we start, let’s validate the starting point. We’ll do this by looking at the BGP config and routes on vMX-2. Then, we’ll look at the routes on vMX-1.
vMX-2
lab@vMX-2> show route protocol bgp
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.101.0/24 *[BGP/170] 01:17:25, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.102.0/24 *[BGP/170] 01:17:25, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.103.0/24 *[BGP/170] 01:17:25, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.17.201.0/24 *[BGP/170] 00:30:03, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.202.0/24 *[BGP/170] 00:30:03, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.203.0/24 *[BGP/170] 00:30:03, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-2>
[edit]
lab@vMX-2# show protocols bgp
group my-external-group {
type external;
authentication-key "$9$7mdw2ZUH5Qn4aQn/CB17-V"; ## SECRET-DATA
peer-as 65001;
neighbor 192.168.2.1;
}
group my-internal-group {
type internal;
local-address 172.16.1.2;
authentication-key "$9$GSjkmz39O1hfT1hSr8LGDi"; ## SECRET-DATA
export fix-nhs;
neighbor 172.16.1.1;
}
[edit]
lab@vMX-2#The routes have the default local preference value of 100. The only policy applied to the iBGP session towards vMX-1 is a simple policy to fix the next-hop of routes vMX-2 learns from vMX-3.
vMX-1
lab@vMX-1> show route protocol bgp
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.17.201.0/24 *[BGP/170] 00:05:16, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
172.17.202.0/24 *[BGP/170] 00:05:16, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
172.17.203.0/24 *[BGP/170] 00:05:16, localpref 100, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
test.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
test.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-1>On vMX-1, the routes have the default local preference.
Next, on vMX-2 we configure the local preference setting at the group level for the iBGP session toward vMX-1
[edit]
lab@vMX-2# set protocols bgp group my-internal-group local-preference 185
[edit]
lab@vMX-2# show protocols bgp
group my-external-group {
type external;
authentication-key "$9$7mdw2ZUH5Qn4aQn/CB17-V"; ## SECRET-DATA
peer-as 65001;
neighbor 192.168.2.1;
}
group my-internal-group {
type internal;
local-preference 185;
local-address 172.16.1.2;
authentication-key "$9$GSjkmz39O1hfT1hSr8LGDi"; ## SECRET-DATA
export fix-nhs;
neighbor 172.16.1.1;
}
[edit]
lab@vMX-2# commit
commit complete
[edit]
lab@vMX-2#Example 6 – Validation
We can validate this by looking at the local preference of the routes.
vMX-2
lab@vMX-2> show route protocol bgp
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.101.0/24 *[BGP/170] 01:23:09, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.102.0/24 *[BGP/170] 01:23:09, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.16.103.0/24 *[BGP/170] 01:23:09, localpref 100, from 172.16.1.1
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
172.17.201.0/24 *[BGP/170] 00:35:47, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.202.0/24 *[BGP/170] 00:35:47, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
172.17.203.0/24 *[BGP/170] 00:35:47, localpref 100
AS path: 65001 I, validation-state: unverified
> to 192.168.2.1 via ge-0/0/1.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-2>The routes on vMX-2 are unchanged. Neither the routes from vMX-1 or vMX-3 have had their local preference value changed.
We can look at the routes vMX-2 is advertising to vMX-1 and see the local preference value.
lab@vMX-2> show route advertising-protocol bgp 172.16.1.1
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.17.201.0/24 Self 185 65001 I
* 172.17.202.0/24 Self 185 65001 I
* 172.17.203.0/24 Self 185 65001 I
lab@vMX-2>vMX-1
lab@vMX-1> show route protocol bgp
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.17.201.0/24 *[BGP/170] 00:02:43, localpref 185, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
172.17.202.0/24 *[BGP/170] 00:02:43, localpref 185, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
172.17.203.0/24 *[BGP/170] 00:02:43, localpref 185, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
test.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
test.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-1>The vMX-1 router looks as we would expect, with the routes having a local preference value of 185.
Although not shown here, if you set the local-preference at both the group and the neighbor level, the most specific entry will be used, so you will get the value set under the neighbor.
If you set this on an eBGP neighbor nothing much happens.
In general, I avoid directly setting local preference in the BGP configuration where possible, and instead use policy as per the previous examples. There are two main reasons for this:
- The local preference statement behaves in a way that is likely to confuse people unfamiliar with Junos. It is more likely that people will assume it is setting the local preference on the routes received, rather than the routes that are advertised.
- I think that consistent use of routing policy is clearer, more intuitive, and gives you more granular control over which routes have their local preference changed.
This does leave a question unanswered. What if you use this method and policy at the same time?
Example 7 – Setting Local Preference With And Without Using Policy
This example is to satisfy curiosity. This is a bad idea and not something I would normally do.
We’re going to extend the previous example by adding policy to the mix. Normally, I wouldn’t modify local preference on routes I advertise to an iBGP neighbor but I’m curious about the interaction when policy is added.
The vMX-2 router is updated as per the configuration below. An additional export policy is applied to the iBGP neighbor vMX-1.
[edit]
lab@vMX-2# show protocols bgp
group my-external-group {
type external;
authentication-key "$9$7mdw2ZUH5Qn4aQn/CB17-V"; ## SECRET-DATA
peer-as 65001;
neighbor 192.168.2.1;
}
group my-internal-group {
type internal;
local-preference 185;
local-address 172.16.1.2;
authentication-key "$9$GSjkmz39O1hfT1hSr8LGDi"; ## SECRET-DATA
export [ fix-nhs my-bad-idea ];
neighbor 172.16.1.1 {
local-preference 210;
}
}
[edit]
lab@vMX-2# show policy-options policy-statement my-bad-idea
term set-lpref {
from {
route-filter 172.17.201.0/24 exact;
}
then {
local-preference 230;
}
}
term add-to-lpref {
from {
route-filter 172.17.202.0/24 exact;
}
then {
local-preference add 40;
}
}
[edit]
lab@vMX-2#The policy matches route 172.17.201.0/24 and specifically sets the local preference value, while the second term adds to the existing local preference value of the 172.17.202.0/24 route.
The results on vMX-1 are as follows.
vMX-1
lab@vMX-1> show route protocol bgp
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.17.201.0/24 *[BGP/170] 00:02:52, localpref 230, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
172.17.202.0/24 *[BGP/170] 00:02:52, localpref 140, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
172.17.203.0/24 *[BGP/170] 06:06:23, localpref 210, from 172.16.1.2
AS path: 65001 I, validation-state: unverified
> to 192.168.1.1 via ge-0/0/0.0
test.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
test.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-1>The results are, honestly, not what I expected.
- 172.17.201.0/24 has a local preference of 230, which was explicitly set by policy.
- 172.17.202.0/24 has a local preference of 140, which appears to be the default of 100 plus the 40 added by the policy.
- 172.17.203.0/24 has a local preference of 210, which is the value set by the configuration under the BGP stanza.
Based on this, it appears that if the local preference value is modified by policy at all, it takes on the value given by policy. If the local preference for the route is not changed by policy, then the setting configured under the BGP stanza applies.
Prior to testing this, I had assumed that both methods would be applied, but I wasn’t sure what the order would be. It looks like only one method will be applied to a given route, with policy taking precedence over the BGP configuration.
Summary
On Junos, local preference is set using a routing policy. Local preference can either be set to a specific value or you can modify the existing value.
Care should be taken to not set the route preference by mistake instead of local preference.
While it is possible to set the local preference on routes advertised to iBGP peers without using policy, this is not an approach I would normally use.
If you are new to BGP on Junos, have a look at this basic BGP configuration example.