BGP Local Preference

Contents

Intro

BGP weight works best when you want to influence outbound path selection on a single router only. What if you want that outbound policy to apply to all routers within your Autonomous System? Sure I can configure the weight on each router but that’s a lot of work. That’s where BGP local preference comes in. Local preference is attached to routes when they are sent to iBGP peers. Local preference is the second attribute looked at in the BGP best path selection algorithm. It’s not sent to eBGP peers. When it comes to local preference the default value is 100 and the higher value is preferred. In this tutorial I’m going to make all routers in AS12 use R2 as an exit point when trying to reach the prefixes behind R3 in AS3. What’s even better is I only need to configure it on one router. 

Local preference lets the routers know the preferred exit point within an AS. Think of it like " You wanna leave the AS, then go this way!"

Topology

Network diagram for BGP local preference tutorial with three routers, R1 and R2 in AS12, and R3 in AS3 advertising networks.
The last octet is the router number unless specified otherwise. Example: R1's G0/0 is 10.10.12.1/24. Don't forget to download the EVE-NG topology file for this tutorial below.

Initial Configs

Configuration Steps

1. Configure Basic BGP

The first thing I’ll do is establish BGP peering between the routers and ensure that R3 is advertising its networks:

R1:

router bgp 12
 neighbor 10.10.12.2 remote-as 12
 neighbor 10.10.13.3 remote-as 3

R2:

router bgp 12
 neighbor 10.10.12.1 remote-as 12
 neighbor 10.10.23.3 remote-as 3

R3:

router bgp 3
 neighbor 10.10.13.1 remote-as 12
 neighbor 10.10.23.2 remote-as 12
 network 3.3.3.3 mask 255.255.255.255
 network 33.33.33.33 mask 255.255.255.255

After a few moments I should see a message on each router that the neighbors are up. 

R1:

%BGP-5-ADJCHANGE: neighbor 10.10.12.2 Up 
%BGP-5-ADJCHANGE: neighbor 10.10.13.3 Up

R2:

%BGP-5-ADJCHANGE: neighbor 10.10.23.3 Up
%BGP-5-ADJCHANGE: neighbor 10.10.12.1 Up

R3:

%BGP-5-ADJCHANGE: neighbor 10.10.13.1 Up 
%BGP-5-ADJCHANGE: neighbor 10.10.23.2 Up

Looks like the neighbors are up on all routers. Let me check the BGP tables on R1 and R2 which live in AS12. 

R1:

R1#show ip bgp
BGP table version is 7, local router ID is 10.10.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 * i  3.3.3.3/32       10.10.12.2               0    100      0 3 i
 *>                    10.10.13.3               0             0 3 i
 * i  33.33.33.33/32   10.10.12.2               0    100      0 3 i
 *>                    10.10.13.3               0             0 3 i

The above output shows that R1 is receiving both prefixes directly from the eBGP connection R3 and from it’s iBGP neighbor R2. The path that is being preferred is the eBGP path towards R3.

R2:

R2#show ip bgp
BGP table version is 3, local router ID is 10.10.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 * i  3.3.3.3/32       10.10.12.1               0    100      0 3 i
 *>                    10.10.23.3               0             0 3 i
 * i  33.33.33.33/32   10.10.12.1               0    100      0 3 i
 *>                    10.10.23.3               0             0 3 i

R2 is also receiving both prefixes from its eBGP peer R3 and its iBGP peer R1. Both R1 and R2 are choosing the eBGP path as best. The reason for this is because the weight, local preference, origination, AS-Path, origin type and MED are all the same. The tie breaker is in the very next step which is to prefer the eBGP path over iBGP paths.

Both R1 and R2 are preferring the eBGP path to reach those prefixes over the iBGP learned one. Right now the default local preference is 100. I’ll change the default local preference to 101 on R1. This change will be advertised to R2. When R2 sees the higher local preference from R1 it will prefer that path to reach those prefixes. Let me show you. 

1. Configure higher local preference on R1

R1:

router bgp 12
 bgp default local-preference 101

I changed the default local preference on R1 to 101. This value is higher than the default of 100. All iBGP peers in As12 will use R1 as an exit point. Let me confirm this by looking at R2’s BGP table. 

R2#show ip bgp
BGP table version is 13, local router ID is 10.10.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>i  3.3.3.3/32       10.10.12.1               0    101      0 3 i
 *                     10.10.23.3               0             0 3 i
 *>i  33.33.33.33/32   10.10.12.1               0    101      0 3 i
 *                     10.10.23.3               0             0 3 i

R2’s BGP table has received the update from R1 with the higher local preference values. The best path selection algorithm ran again and the paths with the higher local preference were preferred. By using the bgp default local-preference command on R1 I’m affecting all prefixes advertised to iBGP peers. 

If I want to change the local preference for indiviual routes then I need to use a route-map. I’ll show you this now. Let me remove the bgp default local-preference command. 

Local preference is only sent to iBGP peers only.

R1:

router bgp 12
 no bgp default local-preference 101

Let me check R2’s BGP table to make sure it’s back the original state.

R2#sh ip bgp 
BGP table version is 15, local router ID is 10.10.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 * i  3.3.3.3/32       10.10.12.1               0    100      0 3 i
 *>                    10.10.23.3               0             0 3 i
 * i  33.33.33.33/32   10.10.12.1               0    100      0 3 i
 *>                    10.10.23.3               0             0 3 i
R2#

Great, R2 is back to preferring the eBGP paths over the iBGP learned ones. Now I’ll create a route-map on R1 that matches the 3.3.3.3/32 prefix only and sets the local preference to 1000. The other prefix 33.33.33.33/32 I won’t change the local preference on. 

Route-maps give you the control to change local preference on some routes and not others.

First I’ll create a prefix-list for the 3.3.3.3/32 prefix. 

R1:

ip prefix-list ROUTES_FROM_R3 seq 5 permit 3.3.3.3/32

Now I’ll match that prefix in a route-map and set the local preference to 1000.

R1:

route-map PREFER_R1 permit 10
 match ip address prefix-list ROUTES_FROM_R3
 set local-preference 1000
route-map PREFER_R1 permit 20

The above config sets the local preference to 1000 for prefixes that match the prefix-list. I added a second route-map statement, sequence 20 which permits everything else but doesn’t change anything. If I forget this then the implicit deny at the end of the route-map will block all other prefixes like the 33.33.33.33/32 that isn’t being allowed in earlier statements.  The final thing I need to do is activate the route-map by applying it to a neighbor and specifying a direction. 

R1:

router bgp 12
 neighbor 10.10.13.3 route-map PREFER_R1 in

This route-map is configured on R1 and is applied to the eBGP neighbor on R3 in the inbound direction. All prefixes that come inbound on R1 from R3 will be process by this route-map. Let’s check the BGP table to R2 to see if anything changed. 

If the policy takes a while to kick in, do a clear ip bgp * soft on R2 to speed things up. 
R2#sh ip bgp
BGP table version is 16, local router ID is 10.10.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>i  3.3.3.3/32       10.10.12.1               0   1000      0 3 i
 *                     10.10.23.3               0             0 3 i
 * i  33.33.33.33/32   10.10.12.1               0    100      0 3 i
 *>                    10.10.23.3               0             0 3 i

In the above output you can see that for the 3.3.3.3/32 prefix the local preference was changed to 1000. This is higher than the default value of 100 which makes this the preferred path. The other prefix 33.33.33.33/32 was unaffected and the eBGP path is still preferred.  You can also see the local preference by looking at the details of a prefix.  

R2#show ip bgp 3.3.3.3
BGP routing table entry for 3.3.3.3/32, version 16
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 13
  3
    10.10.12.1 from 10.10.12.1 (10.10.13.1)
      Origin IGP, metric 0, localpref 1000, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 9
  3
    10.10.23.3 from 10.10.23.3 (33.33.33.33)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

The above output shows that R2 learned about the 3.3.3.3/32 prefix from from its eBGP peer R3, and its iBGP R1. The path via R1 is marked as best because the local preference value of 1000. 

That’s how you can use a prefix-list and a route-map to change the local prefence on individual prefixes. Here’s what the BGP update message in Wireshark looks like. This is what R1 sent to R2. Notice the local preference values for each prefix. 

Wireshark capture of a BGP update message from R1 to R2 showing increased local preference for specific networks.

I hope you found this tutorial helpful. Don’t forget to lab it out in EVE-NG. I’ve included the topology file so you can practice it on your own. If you have any questions please let me know. 

EVE-NG Lab File

Images used in lab: VIOS-ADVENTERPRISEK9-M), Version 15.9(3)M2

Here’s the EVE-NG Topology file if you want to import it into your own EVE-NG lab and practice. Please note this is the topology file not the Cisco images, we don’t provide those. 

Download

Full Configs

Here are the full configs from all routers if you want to try it out yourself.

Got Questions?

Any questions or comments feel free to send me an email at rafael@networkengineerpro.com and I’ll get back to you when I can.