How to Configure BGP Local Preference Attribute

Lessons Discussion
83

Hello Sims

With the above configuration using the “IN” keyword, any BGP routes that are recieved from that neighbor will have a local preference set to 700. In other words, if the 192.168.13.1 neighbor sends R3 a prefix to 1.1.1.0/24, R3 will set the LOCALPREF to 700 before installing it in its BGP table.

If you used the “OUT” keyword, then this route-map will be applied to prefixes that are sent from R3 to the 192.168.13.1 neighbor. For example, if R3 sends the 2.2.2.0/24 prefix to the 192.168.13.1 neighbor, it will adjust the LOCALPREF of that prefix to 700 before sending it to its neighbor.

Remember that the “IN” and “OUT” keywords apply to the exchange of BGP information and not to the actual user traffic that is being exchanged.

I hope this has been helpful!

Laz

84

Hi,

R2(config)#router bgp 2
R2(config-router)#neighbor 4.4.4.4 remote-as 2
R2(config-router)#neighbor 4.4.4.4 update-source loopback 0

why bgp does not form neighbourship if I am not adding “neighbor 4.4.4.4 update-source loopback 0”
Thanks

85

Hello Sims

By default, for a BGP neighbor relationship to be established, the source IP address of BGP packets must be the same as the neighbor ip-address set on the neighboring router. By default, the packet’s source IP address for BGP is the outgoing interface. This is also called the “best local address”. In your example above, if you don’t issue the update-source command, this results in a BGP neighor relationship that is attempting to be created using 4.4.4.4 as the IP address of the local BGP peer, and 192.168.23.2 as the source of the BGP packets. This is an incorrect configuration and will not function until you redefine the source interface that BGP will be using. This is why once you issue the update-source command, the BGP peering takes place successfully.

If you used the 192.168.23.2 address in the neighbor command, then the update-source command would not be needed because both the source address and the exit interface would have the same IP address.

I hope this has been helpful!

Laz

86

Hi,

local prefernce is available only in the AS ,so what is the point of using OUT ?
Please give an example with sh ip bgp command

Thanks

87

Hello Sims

Yes you are correct, the example I gave would not change anything because R1 and R3 are eBGP peers, and LOCALPREF is not exchanged between eBGP routers. The logic however remains the same. You can apply the example I gave to an iBGP peering, where R3 could have the LOCALPREF adjusted for any prefixes that are sent to R4. For example take a look at the following :

R3(config)#route-map LOCALPREF permit 10
R3(config-route-map)#set local-preference 700

R3(config)#router bgp 2
R3(config-router)#neighbor 192.168.34.4 route-map LOCALPREF out

With the above configuration, any external routes (such as that to 1.1.1.0/24 for example) that are shared by R3 to R4 will have the route-map applied, which means the LOCALPREF would be adjusted to 700, causing R4 to prefer to reach 1.1.1.0/24 via R2.

I hope this has been helpful!

Laz

1 Like
88

Hello,

I have a setup very similar topology to the one in the course. The only difference with the topology in the local preference course is that I have R4 in the place of R3 and vice versa. In addition, I have used loopback intefaces to form the peerings both for eBGP and iBGP with all the pre-requisites (static route, update source loopback , ebgp-multihop for the eBGP peers) , and the equivalent (ospf and so on) for the iBGP peers.

This is where my question comes in place,

I advertise 2 prefixes from R1, that is 1.1.1.1/32 and 10.10.10.10/32

In the R4, both show with next hop 1.1.1.1

BGP-LOCAPREF-TOPOLOGY
BGP-LOCAPREF-TOPOLOGY.JPG761×361 31 KB

Below the output from show ip bgp in the R4 router.
SH_IP_BGP_R4

and in the R3,
SH_IP_BGP_R3

So in my case, it appears that both prefixes use R2 loopback to reach R3.

What if I want to advertise 1.1.1.1/32 from R2 loopback and 10.10.10.10/32 from R4 loopback, while keeping the loopback peerings as they are ?

The problem in my case is that in R4, both prefixes appear to have the same next-hop.

Thank you in advance for recommendations,

Konstantinos

89

Hello Konstantinos

The local preference attribute applied in this lesson is applied to all routes that are learned from a particular neighbor. However, it is possible to selectively choose which routes the local preference attribute will be applied to. You can add a match statement to the route-map that will specify the particular path that you would like to add. So for your example above, you can add a route-map to R2 that will increase the local preference of the route to 1.1.1.1 that is advertised from R2 to R3. The result would be that R3 would have R2 as the next hop for only this route while 10.10.10.10 would maintain a next hop of R4.

There are other ways to adjust this as well using other attributes assigned in route maps. These attributes include Weight and AS Path Length, both of which can be further researched below:



I hope this has been helpful!

Laz

90

Thanks for the explanation @ReneMolenaar

1 Like
91

LP & RR
LP & RR1608×852 165 KB

Hello Rene/Las,
On above i have pasted my topology with necessary configuration. The prefix 1.1.1.1/32 is coming from R1 and get injects in to AS -2 with local preference configured on R3.

You can use local preference to choose the outbound external BGP path.
Local preference is sent to all internal BGP routers in your autonomous system.
Default value is 100.
The path with the highest local preference is preferred.

The second line is very confusing and my question is also to know about the LP propagation between the routers participating in AS-2.
Adding my observations once configured the LP policy on R3 router is mentioned below.

  1. Before implementing LP configurations ,R2 can able to advertise the same route 1.1.1.1/32 towards R4.
  2. After LP configured,only the highest LP tagged route will be there in R4’s BGP table which never allows R2 to advertise the same route towards neighbor belongs to same AS -2.

Why it is like that ? Which bgp message is using for that attribute propagation to inform all i-BGP neighbors about this preferred exit entry?

And i think because of this we won’t receive two routes from different path in bgp table of R4 right? Can be a reason to block maximum path configuration for load sharing using two paths?

Network          Next Hop            Metric LocPrf Weight Path
* i  1.1.1.1/32  3.3.3.3                  0    100      0 1 ?
*>i              2.2.2.2                  0    100      0 1 ?

This is pre LP implementation Maximum path because we have two path in BGP table achieved load balancing.

Network          Next Hop            Metric LocPrf Weight Path
*mi  1.1.1.1/32       3.3.3.3                  0    100      0 1 ?
*>i                   2.2.2.2                  0    100      0 1 ?

   1.0.0.0/32 is subnetted, 1 subnets
B        1.1.1.1 [200/0] via 3.3.3.3, 00:00:39
                 [200/0] via 2.2.2.2, 00:00:39
B     192.168.13.0/24 [200/0] via 3.3.3.3, 00:00:39
                 [200/0] via 2.2.2.2, 00:00:39
Router#

Let me add few more points here below
R2#show ip bgp neighbors 192.168.12.1 received-routes

 Network          Next Hop            Metric LocPrf Weight Path
  • 1.1.1.1/32 192.168.12.1 0 0 1 ? ----------------> Received routes but not advertising from here towards 4.4.4.4 (R4) after higher LP has implemented on R3.

R2#show ip bgp neighbors 4.4.4.4 advertised-routes

 Network          Next Hop            Metric LocPrf Weight Path

*> 22.22.22.22/32 192.168.12.1 0 0 1 ? ------------> blank for 1.1.1.1/32
r> 192.168.12.0 192.168.12.1 0 0 1 ?
*> 192.168.13.0 192.168.12.1 0 0 1 ?

My question is why 1.1.1.1/32 is valid route only in R2 …On what basis R2 took decision to keep 1.1.1.1/32 as valid route not best .If it becomes best it is supposed to advertise from here right?
On what basis R2 took that decision to keep 1.1.1.1/32 as valid only .So i think we need to know the BGP propagation of LP attribute using which type of messages in AS-2.
Correct me if i am wrong in my understanding.

Regards
Unni

92

Hello Unni

I labbed this up to try to replicate your results. It is true that before implementing LP, you find that R4 indeed has both routes to reach 1.1.1.1 via R2 and R3. Here is the BGP table I get for this:

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

And the routing table routes traffic to 1.1.1.1 via R2:

R4#show ip route

  1.0.0.0/24 is subnetted, 1 subnets
B        1.1.1.0 [200/0] via 2.2.2.2, 00:01:08

Now if we add the local preference configuration on R3, this changes on R4:

R4#show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>i  1.1.1.0/24       3.3.3.3                  0    600      0 1 i
 * i                   2.2.2.2                  0    100      0 1 i

And the routing table changes accordingly:

R4#show ip route

  1.0.0.0/24 is subnetted, 1 subnets
B        1.1.1.0 [200/0] via 3.3.3.3, 00:01:01

As you can see here, the BGP table of R4 still has the advertised route to 1.1.1.1 via R2, but with a local preference of 100 while that of R3 has a local preference of 600. So both routes are indeed advertised to R4, but only the best is installed in the routing table.

Now in your output of the routing table above, where local pref is the same value, you have both routes in the routing table, because you have increased the maximum paths.

I hope this has been helpful!

Laz

1 Like
93

[quote=“monsterunni835, post:91, topic:953”]
Let me add few more points here below
R2#show ip bgp neighbors 192.168.12.1 received-routes

 Network          Next Hop            Metric LocPrf Weight Path
  • 1.1.1.1/32 192.168.12.1 0 0 1 ? ----------------> Received routes but not advertising from here towards 4.4.4.4 (R4) after higher LP has implemented on R3.

R2#show ip bgp neighbors 4.4.4.4 advertised-routes

 Network          Next Hop            Metric LocPrf Weight Path

*> 22.22.22.22/32 192.168.12.1 0 0 1 ? ------------> blank for 1.1.1.1/32
r> 192.168.12.0 192.168.12.1 0 0 1 ?
*> 192.168.13.0 192.168.12.1 0 0 1 ?

My question is why 1.1.1.1/32 is valid route only in R2 …On what basis R2 took decision to keep 1.1.1.1/32 as valid route not best .If it becomes best it is supposed to advertise from here right?
On what basis R2 took that decision to keep 1.1.1.1/32 as valid only .So i think we need to know the BGP propagation of LP attribute using which type of messages in AS-2.
Correct me if i am wrong in my understanding.

Regards
Unni

94

Hello Unni

First of all, keep in mind that all iBGP routers in an area must be configured with full mesh neighborship, that is, all BGP routers must be neighbors with all other BGP routers in the AS. (Unless you configure a route reflector, but that’s another lesson…) This means that if you change the Local Pref of a particular router or destination, this information will be learned by all other iBGP routers in the AS.

Having said that, R2 learns about the path to 1.1.1.0/24 via two sources: eBGP and iBGP. For this reason, both are placed in the BGP table of R2. However, because Local Pref is configured to force traffic destined to 1.1.1.0/24 via R3, the best path that is chosen by R2 is via R3.

So R2 learns about 1.1.1.0/24 via R1, but because a “preferred” route exists via R3 due to LP configuration, this is the path that is shared with R4.

I hope this has been helpful!

Laz

95

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,

96

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

97

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

98

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

99

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 ?

100

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

101

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

I suspect that something is wrong with that!

questao bgp forum NL
questao bgp forum NL1435×531 164 KB

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??

102

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