So, what is local preference in BGP?
The BGP Local Preference attribute or local-pref is used to influence the outbound routing decision of a router running BGP.
The local preference has to be set inbound on routes being received to influence the outbound routing behaviour. A higher local preference is preferred and the default is 100.
It is the second attribute in the BGP best path algorithm with BGP Weight being the first.
For this BGP tutorial I will be using the simple topology below. The route 6.6.6.6/32 is being learned via R6 and we are going to try to influence the routing decision on R2 to take the path via the longer AS path through R4 and R5. All routers are addressed with the interface ip relevant to the router. e.g all R2’s ip addresses will end with .2
If you want to know how does BGP choose the best path please read BGP best path algorithm which states that if local preference is the same then the path with the shortest AS path will be chosen. As local preference is higher up the decision process if we can change that we can influence the routing over the shortest AS-path choice.
Page Contents
BGP Local Preference Command
Lets take a look at the routing on R2 and the path it is currently choosing to get to 6.6.6.6
R2#sh ip bgp BGP table version is 15, local router ID is 10.0.12.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 6.6.6.6/32 10.0.24.4 0 65504 65505 65506 i *> 10.0.23.3 0 65503 65506 i * i10.0.12.0/24 10.0.12.1 0 100 0 i *> 0.0.0.0 0 32768 i * 10.0.23.0/24 10.0.23.3 0 0 65503 i *> 0.0.0.0 0 32768 i * 10.0.24.0/24 10.0.24.4 0 0 65504 i *> 0.0.0.0 0 32768 i *> 10.0.36.0/24 10.0.23.3 0 0 65503 i *> 10.0.45.0/24 10.0.24.4 0 0 65504 i * 10.0.56.0/24 10.0.23.3 0 65503 65506 i *> 10.0.24.4 0 65504 65505 i
So as you can see R2 is preferring the path via R3 as indicated by the > symbol, you can also see that there are two paths available, but the path through R4 is via a longer AS path. We are now going to change the routing behaviour by setting the Local Preference of all routes coming in via R4 higher. This will mean R2 will decide to route to R4 to get to 6.6.6.6 as it has a higher local preference.
To set this we will configure a route map on connection to R4 inbound as below
R2(config-router)#neighbor 10.0.24.4 route-map LOCAL-PREF-150 in R2(config-router)#route-map LOCAL-PREF-150 R2(config-route-map)#set local-preference 150
After you make this change it’s best to clear the process, as this is a lab environment it is safe to just do clear ip bgp *
R2#clear ip bgp * R2# *Mar 1 01:21:08.847: %BGP-5-ADJCHANGE: neighbor 10.0.12.1 Down User reset *Mar 1 01:21:08.847: %BGP-5-ADJCHANGE: neighbor 10.0.23.3 Down User reset *Mar 1 01:21:08.851: %BGP-5-ADJCHANGE: neighbor 10.0.24.4 Down User reset R2# *Mar 1 01:21:22.607: %BGP-5-ADJCHANGE: neighbor 10.0.23.3 Up *Mar 1 01:21:22.611: %BGP-5-ADJCHANGE: neighbor 10.0.24.4 Up *Mar 1 01:21:22.627: %BGP-5-ADJCHANGE: neighbor 10.0.12.1 Up
There is a much better method to perform the route-refresh is to do a soft reset as below
R2#clear ip bgp 10.0.24.4 soft
This keeps the tcp session up and just refreshes any routing changes.
So lets see if our route-map changing the bgp local preference has made any difference?
R2#sh ip bgp
BGP table version is 22, local router ID is 10.0.24.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 6.6.6.6/32 10.0.24.4 150 0 65504 65505 65506 i
* 10.0.23.3 0 65503 65506 i
*> 10.0.12.0/24 0.0.0.0 0 32768 i
* i 10.0.12.1 0 100 0 i
*> 10.0.23.0/24 0.0.0.0 0 32768 i
* 10.0.23.3 0 0 65503 i
*> 10.0.24.0/24 0.0.0.0 0 32768 i
* 10.0.24.4 0 150 0 65504 i
*> 10.0.36.0/24 10.0.24.4 150 0 65504 65505 65506 i
* 10.0.23.3 0 0 65503 i
*> 10.0.45.0/24 10.0.24.4 0 150 0 65504 i
* 10.0.23.3 0 65503 65506 65505 i
*> 10.0.56.0/24 10.0.24.4 150 0 65504 65505 i
* 10.0.23.3 0 65503 65506 i
As you can see the route for 6.6.6.6/32 now has the > by the path via 10.0.24.4 (R4) and the local preference is showing as 150 this means it is taking a longer AS path but as local preference is higher up the bgp algorithm it is chosen first as the routing decision.
One last point is that the local-preference value is passed between iBGP neighbors but it is not passed between eBGP neighbors. So if we look on R1 you will see the bgp local preference value as 150
R1#sh ip bgp
BGP table version is 35, local router ID is 10.0.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i6.6.6.6/32 10.0.24.4 0 150 0 65504 65505 65506 i
* i10.0.12.0/24 10.0.12.2 0 100 0 i
*> 0.0.0.0 0 32768 i
*>i10.0.23.0/24 10.0.12.2 0 100 0 i
*>i10.0.24.0/24 10.0.12.2 0 100 0 i
*>i10.0.36.0/24 10.0.24.4 0 150 0 65504 65505 65506 i
*>i10.0.45.0/24 10.0.24.4 0 150 0 65504 i
*>i10.0.56.0/24 10.0.24.4 0 150 0 65504 65505 i
There is one more thing we can do and that is get a bit more specific. As you can see the local preference attribute has been applied to all routes coming in from R4, if we just wanted to do it for 6.6.6.6 then we could match this network in a prefix-list and add that to the route-map.
First I need to create a prefix-list and then match it in the route-map
ip prefix-list 6-6-6-6 seq 5 permit 6.6.6.6/32 route-map LOCAL-PREF-150 permit 10 match ip address prefix-list 6-6-6-6 set local-preference 150
If we then do a soft reset and check the sh ip bgp output again you will see that it is only affecting the 6.6.6.6 network
R2#sh ip bgp
BGP table version is 25, local router ID is 10.0.24.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 6.6.6.6/32 10.0.24.4 150 0 65504 65505 65506 i
* 10.0.23.3 0 65503 65506 i
*> 10.0.12.0/24 0.0.0.0 0 32768 i
* i 10.0.12.1 0 100 0 i
*> 10.0.23.0/24 0.0.0.0 0 32768 i
* 10.0.23.3 0 0 65503 i
*> 10.0.24.0/24 0.0.0.0 0 32768 i
*> 10.0.36.0/24 10.0.23.3 0 0 65503 i
*> 10.0.45.0/24 10.0.23.3 0 65503 65506 65505 i
*> 10.0.56.0/24 10.0.23.3 0 65503 65506 i
We can verify this is working with a trace showing the path to 6.6.6.6 is via 10.0.24.4 (R4)
R2#trace 6.6.6.6 Type escape sequence to abort. Tracing the route to 6.6.6.6 1 10.0.24.4 72 msec 84 msec 32 msec 2 10.0.45.5 [AS 65505] 64 msec 64 msec 68 msec 3 10.0.56.6 [AS 65506] 68 msec * 184 msec R2#trace
Cisco Documentation can be found here
Frequently asked questions
✅ What is local preference in BGP?
The local preference BGP attribute is the second attribute and used to choose the exit path to an autonomous system from a local perspective. It is not exchanged between routers, it’s default value is 100 and the path with the highest local preference is preferred.
✅ How does BGP choose the best path?
Using the best path selection alogrithm BGP works through each attribute until it finds one to that gives a preference, if there is no preffered attribute BGP will always route over the shortest AS path
✅ Is Local Preference Transitive?
Local Preference is transitive. It is a Well Known attribute meaning it must be supported by all BGP implementations, and all well known attributes are transitive.
Local Preference is not attached to eBGP updates, only to iBGP updates.
✅ What is the difference between Weight & Local Preference in BGP?
The major difference between the Weight and LOCAL_PREF attributes is that when the LOCAL_PREF attribute is changed, that change is reflected throughout the AS. The new LOCAL_PREF value will be advertised to all other routers in the AS, as compared to the Weight attribute, which is locally significant only
Clear and Simple Good Stuff. thanks.
Glad it helped you understand BGP Local Preference.
Roger
Hi, Roger.
Please take a look at this topology:
R1
/
/
/
R2——-R3
R1 belongs to AS 100 and R2 and R3 belong to AS 200.There are eBGP sessions between R1 and R2 and between R1 and R3. There is an iBGP session between R2 and R3.
Initially, I have two paths to a network in R1 from either R2 or R3 – in any case, the direct link is the preferred route and the link passing through the iBGP peer is the secondary route. I’ve set the local preference attribute in R3 to apply it to routes learned from R1. Everything is going well – I can reach a network in R1 from R2 through R3 and I can reach that network from R3 directly. However, I can’t understand why there is not a secondary route in R3 when I type ‘show ip bgp’ in that router. Actually, I can see only the route using the direct link between R3 and R1.
I’ve used GNS3 to build this topology, and I trying to understand how BGP works – by the weay, I’m a computer network professor in Brazil.
Thanks in advance, Roger.
Helcio.
Helcio,
Without seeing what config you have on your routers it is very tricky to see where your problem is, send me a message with your router configuration and I will take a look.
Just click on the email icon at the top right of the site.
Roger
Thanks roger, this tutorial realy help me to understand how to configure the bgp local preference.
I am glad it helped
Hi, Roger. Could you tell me why we don’t see two routes to 6.6.6.6/32 in R1?
I suppose BGP propagates only the best route it has received to a given destination (I think I’ve seen something like that in some place, but I’m not sure where). My guess is that R2 compares the two routes to 6.6.6.6/32, that one received from R3 and the other received from R4. It concludes that the route sent by R4 is the better (because it has the highest LOCAL_PREF) and propagates it to R1. Am I correct?
Thanks in advance for any clarification.
Exactly, R1 only has one way out and that is via R2. BGP will only advertise the best route onto R1 – This could get a lot more complicated if you wanted, but for this example let’s keep it simple.
Thank you so much, Roger.
Nice and easy to grasp clarification of the local reference attribute. Thank you very much
very well explained in simple language …
Great glad it helped
Need to know which tool is being used here to simulate the environment.
Hi this is GNS3, but I now use EVE-NG
very good EXPLANATION. I like it when a ccie explains stuff in an easy way.
Thanks Ulrich
thank you for your time to write this article! really a good stuff and very objective.
Keep up doing this great job.
Thanks Rafael,