How to Configure BGP Local Preference Attribute

Hello Team,

I have the following topology:

topology

R1 on AS 100 advertising the 172.16.x.x prefixes.
Transit AS 200 and AS 300.
iBGP full-mesh on AS 400 between R4, R6 and R5.

On R4, we are receiving the 172.16.x.x prefixes from R2 and R6.
On R6, we are receiving the 172.16.x.x prefixes from R3 and R4.
On R4, set local preference to 172.16.0.0/24 to 150.
On R6, set local preference to 172.24.0.0/24 to 150.

R4 detects that the 172.24.0.0/24 from R6 has a higher local preference than the path from R2 (AS 200). R4 marks the path R6 as the best path for the prefix and sends a route withdrawals to R5 and R6 for the path from R2.

R6 detects that the 172.16.0.0/24 from R4 has a higher local preference than the path from R3 (AS 300). R6 selects the path from R4 as the best path for the prefix and sends route withdrawals to R4 and R5 for the path from R3.

In summary:
R4 and R5 receive R6’s withdrawal for the 172.16.0.0/24 prefix and remove it from the BGP table.
R5 and R6 receive R4’s withdrawal for the 172.24.0.0/24 prefix and remove it from the BGP table.

On R4’s BGP table I only see one path to 172.16.0.0/24 via R2.
The path through R6 was removed it from the BGP table.
On R6’s BGP table I only see one path to 172.24.0.0/24 via R3.
The path through R4 was removed it from the BGP table.

My questions are:

  • why sending a prefix withdrawal message?
  • why not keeping both paths to the prefix?
  • Do the routers keep the alternate path (not-best-path) in a backup table in case either R4 or R6 routers crashes?
  • What would happen if R3 fails and the path through R4 was previously removed it from the BGP table? How BGP will converge?

Regards,

Hello Luis

Your topology and your explanation is very comprehensive, thank you for your clarity!

BGP routers will advertise only the best route to a particular destination. If a better route is found, they will actually send a withdrawal message to remove the old advertisement.

So using R6 as an example:

  • Without any local preference configuration, R6 has two routes to the 172.16.0.0/24 network: via R3 and R4. The best route is via R3, therefore, it advertises this route to R4
  • Once the local preference for this route on R4 was increased to 150, R6 learned of the better route from R4, and changed its BGP table accordingly, making R4 the best route
  • Because R3 is no longer the best path, R6 sends a withdrawal to R4 removing the previous best path, and replacing it with its current best path.

This is the default behaviour of BGP. However, you can change this behaviour, and you can see how this is done in the following lesson:

This can be configured using the above mentioned feature called BGP additional paths.

If there is a failure in some link, then it will take some time for BGP to re-converge. If the next hop IP address of some route fails, then the BGP Next Hop Address Tracking feature kicks in, and BGP routes begin to be withdrawn, resulting in BGP peers sharing their revised routes.

I hope this has been helpful!

Laz

Hi, I have a question . when checking the show ip bgp in router 4, we can see it prefers Router 2 path for reaching to network 1.1.1.0/24 in As1 . We are changing the local preference value in Router 3 and configuring route map LOCALPREF in. My questions would be,

R2 , R3 and R4 are in same AS. if we set local preference value for the As it will be shared within AS. Going by this fact, why cant we set the local preference value in Router 4 itself ? This is where we are checking by giving command show ip bgp and seeing it is preferring router 2 for reaching the network 1.1.1.0/24.

If we set the local preference value in Router 4 , cant we write the route map like the below

router bgp 2
neighbor 192.168.13.1 route-map LOCALPREF out
!
route-map LOCALPREF permit 10
 set local-preference 700

Also please explain what happens here if we apply
neighbor 192.168.13.1 route-map LOCALPREF out

Hello Dakshinamurthy

The local pref can be configured in two ways. Either using the bgp default local-preference command, or using route maps. In the first case, you must configure this command in the router that is advertising the route, or the router that is on the edge of the AS, specifically, either R2 or R3 in our topology. Applying the bgp default local-preference command on R4 will not affect the way R4 reaches the 1.1.1.0/24 network.

When using route maps however, yes, you could configure the change in local pref in R4.

I am assuming that the above commands are applied to R4, correct? If so, your route map is correct, but its application on the neighbor must be modified. In your configuration above, you are applying it to a peering between R4 and R1, (an eBGP peering) but such a peering does not exist. Actually, you would have to implement the route map on the BGP peering between R3 and R4. Specifically, you would apply it like so on R4:

R4(config-router)#neighbor 3.3.3.3 route-map LOCALPREF in

In this way, all advertisements sent from R3 (with an ID of 3.3.3.3) that are incoming (hence the keyword “in”) will get a local preference value of 700 in R4’s BGP table. I labbed it up and confirmed this.

If you applied the above on R4, then what you are saying is that all BGP routes that are advertised to (hence the “out” keyword) R1 (the 192.168.13.1 neighbor) are to be advertised with a local pref of 700 (or whatever the route map assigns).

BUT, there are two problems with this. First, R4 does not have a peering with R1, so if you applied this, nothing would happen. Second, R4 does not actually have a path to any other AS’es so there is no meaning to having R4 advertise routes with a higher local pref. Remember, the local pref essentially indicates the preferred exit point from the current AS for a particular route.

I hope this has been helpful!

Laz

Thank you Laz, So can we say BGP Local preference is also one of that attributes that can be used to influence the incoming traffic ?

Hello Dakshinamurthy

It depends on what you mean by incoming traffic. You see, the “in” and “out” keywords used in the route maps do not refer to the direction of user traffic, but to the direction of exchanged BGP updates.

So for the following command applied to R4:

R4(config-router)#neighbor 192.168.13.1 route-map LOCALPREF out

the result is, any BGP update containing a route that is sent from R4 to neighbor 192.168.13.1 (R3) will have the LOCALPREF route-map applied to it. BGP updates from R4 to R3 are considered outbound from the point of R4. So if the route-map changes the local preference to, say, 500, then such a command will make all routes shared by R4 with R3 will have their localpref changed to 500.

If we’re talking about user traffic, then no. LocalPref will only affect the choice of path to exit the local AS for a particular prefix. If you have two or more eBGP routers within your AS, and they both have a route to the same prefix via eBGP, the local pref can be used to prefer one over the other.

Inbound traffic can be influenced using MED or AS-PATH prepending, but even so you do not have ultimate control over incoming routing, only your ISP can do that. For more info about influencing incoming traffic, take a look at the following post:

I hope this has been helpful!

Laz

Hello, there follows a question of BGP of an internet sim that I was practicing.

I suspect that something is wrong with that!

1st answer> On router A, set the default location preference to 50.

#this case would influence the entire traffic output of the AS100 to go through routerB and not specifically the prefix 10.10.25.0/24

-2nd answer> On router B, configure a route map for 10.10.25.0/24 with the local preference of 150 linked to neighbor 192.168.30.2.

# the filter applied to the neighbor (192.168.30.2) does not make sense.
because in the IN sense it does not match the route-map to the prefix (10.10.25.0/24)
in the out direction it has no effect because the session is EBGP.

-3rd answer> On router B set the default location preference to 150

#this case would influence the entire output of the AS100 and not specifically the prefix 10.10.25.0/24

4th answer> In router B set the default metric to 150

# has no effect on the proposed question

makes sense??

Hello Yuri

You are correct in your explanation of answers A, C, and D. However, answer B is the correct answer to the question.

Keep in mind that the question is only asking about outgoing traffic, so it only affects traffic in the direction from AS 100 to AS 200. Local preference can only affect outgoing traffic, and this is the goal of the scenario. Local preference essentially tells an AS the most appropriate exit point for traffic.

So by creating a route map where traffic originating from 10.10.25.0/24 will have a higher local preference via router B to router F, you are essentially moving that 20% of the traffic from one link to the other, thus more evenly distributing the traffic between the links. The result is the A-E link will have 45% traffic and the B-F link will have 40%.

I hope this has been helpful!

Laz

Hi @lagapides

Answer B asks to “match” only in the prefix 10.10.25.0/24 which is behind router C by placing a local preference 150 and tying to the neighbor ebgp.

ip prefix-list rota10-25 seq 5 permit 10.10.25.0/24
!
route-map route10-25 permit 10
match ip address prefix-list rota10-25
set local-preference 150
!

and then apply to the neighbor (192.168.30.2)
applying in the IN or OUT direction has no result for the proposal of the statement.

the local preference in B would affect all traffic from the AS 100 out of the B-F point-to-point.

Hello Yuri

Taking a closer look, yes, I would have to agree with you that the question (and the supposed correct answer) is incorrect. You would not be able to achieve this using a route map and changing the local preference. Local preference is applied to prefixes that you receive from other AS’es rather than the prefixes on your own network. Such a configuration would only affect traffic based on the destination address. In this example, you are trying to adjust traffic based on the source address, something that BGP does not do.

What you could do is use weight or local preference to have traffic prefer the B-F link, but only based on the prefixes you receive from AS 200.

My apologies for the misunderstanding. I hope this has been helpful!

Laz

1 Like

Hi, @lagapides

OK. that’s what I imagined.

thank you!

1 Like

That’s why I will always pay for this website, this break down of of local-pref, was explained in one sentence where you will never forget. Really good Job-

1 Like

Did the LocalPref lesson on vIOS routers in EVE-NG.

When doing the technique to change the default local preference on R3 (config t, router bgp 2, bgp default local-preference 600), the localpref value is not shown in the bgp-loc-rib:

 Network          Next Hop            Metric LocPrf Weight Path
 *>   1.1.1.0/24       192.168.13.1             0             0 1 i
 * i                   192.168.12.1             0    100      0 1 i

Yet it is shown if I do “sho ip bgp 1.1.1.0/24”:

192.168.13.1 from 192.168.13.1 (1.1.1.1)
  Origin IGP, metric 0, localpref 600, valid, external, best
  rx pathid: 0, tx pathid: 0x0

If I look at routes I am advertising to my neighbors R2 and R4, LocalPref doesn’t show up in that command either:

R3#sho ip bgp nei 4.4.4.4 advertised-routes
     Network          Next Hop            Metric LocPrf Weight Path
 *>   1.1.1.0/24       192.168.13.1             0             0 1 i

Yet, R4 gets the route with the correct local preference.

I may try this on IOSL or even IOS-XR with its different commands.

UPDATE:

Apparently, the logic is to not display the “default local preference” on the commands I used above (“sho ip bgp” and “sho ip bgp neighbor a.b.c.d advertised-routes”.

Rene, this would be an interesting point to add to the Local Preference lesson. When you change the default LocalPref on R3 from 100 to 600, and do “sho ip bgp” you will see that no LP is shown for the eBGP route learned from R1. That’s because we changed the default LP from 100 to 600.

Hello Harold

What you describe is considered normal behaviour. Whenever you configure the local preference value on a BGP router, it doesn’t change the local preference value of its own BGP table. This is because this is an attribute that is advertised to a BGP router’s neighbors. By changing the local preference of a router, you are changing how that router’s BGP neighbors perceive the routes it advertises.

Only neighbors will see a change in the local preference, and not the router itself. This is why the local preference of the 1.1.1.0/24 network remains 0. Also, if you look at the advertised routes, you always see whatever is in the BGP table before it is modified by local preference or route map configurations.

I hope this has been helpful!

Laz

Lazaros, I do see local preference modified on the prefix in the router’s BGP loc-rib. It’s just that it only shows if you do “sho ip bgp 1.1.1.0/24” instead of “sho ip bgp” and read the BGP RIB’s entire set of prefixes.

My scenario is what was done in the lab: learn 1.1.1.0/24 from an eBGP neighbor, and set the default local preference of 600, which we changed.

If the router’s own BGP loc RIB didn’t modify its own local preference, I’m not sure how it could even select this as the best path. It has to do this so it can supply the BGP best path to the routing table manager on the manager, which manages the RIB.

Hello Harold

You bring up an interesting point. Looking deeper into this topic, and according to Cisco’s command line reference documentation, the value displayed under the LocPrf column in the output of the show ip bgp command is different from the value of the localpref displayed in the output of the show ip bgp 1.1.1.0 command. Specifically, in the BGP table, the LocPrf column displays the following, as stated by Cisco:

Local preference value as set with the set local-preference route-map configuration command. The default value is 100.

Whereas the localpref value in the specific prefix entry displays the result of the bgp default local-preference command. Here we see what local preference value has been shared with that particular eBGP neighbor, the one that provides us with the 1.1.1.0 prefix.

Here we have no route map that is modifying the local preference, therefore you will see no change in the local preference in the output of ip bgp. But you will see a change in the default local preference that is advertised to eBGP neighbours.

Remember that the local preference doesn’t affect the best path choices of the local router, but affects the best path choices of neighbouring eBGP routers. So the local preference modification in R3 should not have any effect whatsoever on R3’s path choices. Indeed it should not have any affect on the path choices of R4 or R2 either! But it should affect R1’s choice when choosing the best path to prefixes within AS2.

I hope this has been helpful!

Laz

Hello,

On the iBGP configs for R2 and R3, why is next-hop-self only configured for the sessions with R4? If this is a full mesh then shouldn’t it be configured for all iBGP sessions?

Hello Bhawandeep

The next-hop-self feature is used in order to advertise networks outside of the local AS in such a way so that routers inside the AS can reach them too. In this particular case, R2 and R3 are both eBGP routers that learn about outside networks via their eBGP peerings. R4 is running only iBGP, so it has no eBGP peerings. When R4 learns about routes outside of the local AS, the next hop it will receive is that of the eBGP peer in the neighboring AS which is an IP address not directly reachable by R4. Such a configuration will not work.

Note that this situation occurs only for routers internal to the AS that have no eBGP peerings. So all routes sent to R4 must have the next-hop-self parameter configured. The opposite however is not necessary, because all the routes shared by R4 will have R4 itself as the next hop, and that is what we want.

The next-hop-self parameter does not play a role in the state of a full mesh iBGP topology. Regardless of this parameter, the iBGP full mesh is still achieved. For more information on the next-hop-self parameter and how it is used, take a look at the following lesson:

I hope this has been helpful!

Laz

1 Like

Hi Laz,

Could you explain how Local preference performing a task of choosing of external outbound BGP path b/c here we are using it in inbound direction.
Please clarify this that which attributes can be used as outbound and which one as inbound?, this question has been asking by many interviewers so please clarify this doubt?

Hello Pradyumna

We must make a distinction between the direction of user traffic, and the direction of BGP updates.

When we talk about applying BGP Local Preference, as an attribute, it affects which router will be used to forward outbound user traffic out of the local AS. This is referencing USER TRAFFIC.

However, when Local Preference is applied using a route map, it is applied on R3, and specifically on the BGP peering between R1 and R3 in an inbound direciton. This inbound direction references the BGP updates that R3 recieves from R1.

So the BGP updates to which a specific LocalPref is to be applied are applied on the incoming BGP updates, but the LocalPref values are actually used to direct outbound user traffic.

I hope this has been helpful!

Laz