How to Configure BGP Local Preference Attribute

Lessons Discussion
103

Hi @lagapidis

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.

104

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
105

Hi, @lagapidis

OK. that’s what I imagined.

thank you!

1 Like
106

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
107

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.

108

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

109

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.

110

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

111

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?

112

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
113

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?

114

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

115

Thanks Laz, please let me know also that Which attributes can be used as outbound, as per my observation Local preference, MED and AS Path prepending are the main attributes can be used for outbound traffic?

116

Hello Pradyumna

As is the case with all routing protocols, BGP is used to determine out of which interface a packet should be forwarded based on its destination address. In that sense, all BGP attributes are used to determine where outgoing traffic will be forwarded to. I assume your question is which attributes are used to determine the outbound external path (path outside of the local BGP AS). Is that the case?

If so, then yes, Local preference AS Path and MED are all attributes that determine this.

I hope this has been helpful!

Laz

117

Hi ,
which scenario we will use “out” instead of " in "
#neighbor 192.168.13.1 route-map LOCALPREF in
Thanks

118

Hello Sims

Take a look at this post:

LocalPref is an attribute that is not exchanged between eBGP routers. This means that in the specific lesson, if you were to use out instead of in, then R3 would change the LocalPref attribute on all routes sent to R1 (outward). But R3 and R1 have an eBGP peering, so LocalPref would not be exchanged. Indeed it would be ignored.

However, ff R4 had a prefix it was advertising, and it applied a route map on the iBGP peering between R4 and R3, and on all routes that it shared with R3 (outward), the localPref could be changed using the out keyword.

I hope this has been helpful!

Laz

119 
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.13.1 route-map LOCALPREF in

When we are going to use out instead of "in’
Thanks

120

Hello Sims

When applied using a route map, changing the local pref is applied to the prefixes received from eBGP neighbors. The attribute is applied to prefixes from other AS’es. These are only learned in an incoming direction on the interfaces through which eBGP neighbors are established.

You could apply such a route map in an outward direction. This would cause the prefixes sent by the local router to the eBGP neighbor to be assigned a different local pref. However, local pref is an attribute that cannot be exchanged between eBGP routers, so even if you do this, the eBGP peer will never receive any local pref information.

Typically, such a route map would be applied to the interface connected to an eBGP peer, and in such a case only the in keyword would be used. However, you could apply it on R3 on interface F2/0 in an outbound direction. This would result in R4 receiving the same local pref for the route. However, R3 would not have the modified local pref in its BGP table, since it would have been applied only on the routes that are sent out of F2/0. This could cause instability within the iBGP topology. However, you can experiment with this and see the behaviour of the network in various situations.

I hope this has been helpful!

Laz

121

Hello Rene,
This was a great lesson/lab. However, I’m still a bit confused as to why we used OSPF in the configuration.

Many Thanks.

122

Hello Willie

In order to understand why we used OSPF, we’ll have to take a look at what Interior Gateway Protocols (IGPs) and what Exterior Gateway Protocols (EGPs) are.

OSPF, EIGRP, RIP, and IS-IS are some of the most common IGPs. IGPs are always employed within an autonomous system (AS). An AS is a self-contained network that is administered by a single entity. For example, an AS can be an enterprise network or a portion of an ISP’s network. IGPs are employed in order to allow routers within an AS to route traffic to each other. IGPs will have no knowledge of any routes outside of the AS.

EGPs are used to route traffic between AS’es. BGP is an EGP, and is used here to allow AS1 to exchange routing information with AS2.

So why do we use OSPF in this scenario? Well, an IGP must be used in order to allow R2, R3 and R4 to exchange routes between them, within the same AS. OSPF was chosen, but we could have chosen EIGRP, or even RIP if we wanted to.

I hope this has been helpful!

Laz