Thanks, Lazaros for clarifying.
In your BGP Weight Attribute session, you have explained with a lab scenario, as per that, its manipulating the traffic coming inside, but Weight is use to manipulate the traffic going out of the router right?. Could you please help to explain the lab scenario. If So, we would do the weight config on R2 instead of R1, or else R1 should have advertised the network .
Thanks
Akhil N R
Hello Akhil
You are correct that the weight attribute will affect the choice of path for outgoing traffic from the router on which it is configured. However, we must keep in mind that there is a distinction between incoming and outgoing traffic, and incoming and outgoing BGP updates, and I believe that this is where the confusion lies.
Now there are a couple of ways of configuring the weight attribute. The first is to assign a particular weight to a neighbor using a BGP command like this:
R1(config-router)#neighbor 192.168.13.3 weight 500
This will cause all prefixes learned from the neighbor to be assigned a weight of 500. In other words, all incoming BGP updates from this neighbor will have their prefixes assigned a weight of 500. The result is that traffic destined to those prefixes (outgoing) will choose this route over another with a lower weight.
The other way to assign weight is to do so to a specific prefix using a route map on incoming BGP updates, something like this:
R1(config-router)#neighbor 192.168.13.3 route-map SETWEIGHT in
where SETWEIGHT is a route-map. (See the lesson for more details). Now this route map is applied in an inward direction, but only in relation to the BGP updates. So this will be applied to prefixes of incoming BGP updates from this particular neighbor. However, it is the routing of the outgoing traffic that will be affected by these changes.
I hope this has been helpful!
Laz
Hi Rene/Laz,
In your example you mention that R1 selects the route via next-hop 192.168.13.3 as best path due to lower neighbour address. Why did the process not pick the oldest path? Iâm assuming one of the sessions would have come up first, even if by a second. Is there a time threshold required in order for oldest path be factored into the best path selection process?
Thanks
Hello Bhawandeep
Actually, for the case where the router ID is used, R1 selects the route via next-hop 192.168.12.2.
This is the case when the weight attribute is not employed. In this case, all BGP attributes are the same so it is indeed the lower router ID that is used to decide the route.
The use of an âolderâ path is not part of the BGP process. Whenever a BGP topology is converged, it will always be the attributes as they are defined by the BGP protocol that are used. These can be further seen at this lesson.
Now if the BGP peering between R1 and R3 is established first, then yes, R3 will be the next-hop IP for the route, but not because it is the oldest path, but because it is the only path. After X number of seconds, if the BGP peering between R1 and R2 comes up, then the BGP topology will reconverge, and R2 will become the next-hop IP address, simply because there are now two options, and the BGP process chooses this based on the router ID.
I hope this has been helpful!
Laz
Hello Rene,
I was simulating this lab but found something interesting. I used the parameters as yours. But surprisingly, the iBGP between R2 and R3 was not coming up. But found issue was with loopbacks. Since loopback IPâs for R2 and R3 are the same, then was getting this error in debugs
Jan 5 04:55:01.146: BGP: 192.168.23.3 passive bad OPEN, wrong router identifier 22.22.22.22
I changed the IPâs and the adjacence came up. Why is this the case in my LAB ?
Hello Eugene
By default, the router ID that is used when loopbacks are present is the highest IPv4 address on a loopback interface. In the case of this lesson, the router IDs are the same for R2 and R3, and for this reason, you get the error you shared in your post.
The configuration should indeed be changed so that the loopback IP addresses are different, but they must remain in the same subnet for the lab to work. I will let @ReneMolenaar know to make the necessary adjustments.
I hope this has been helpful!
Laz
Hello Sir,
Thank you for your share.
I have a difficult to understand when I make in or out on BGP configuration with route-map.
Could you explain to me plz?
Thank you,
Best regards,
Brahim
Hello Brahim
In the lesson, two ways to modify the weight were shown. The first one was:
neighbor 192.168.13.3 weight 500
In the lesson, this command was applied on R1, and it references the IP address of the neighbor R3. The result is that all BGP prefixes that are learned from this neighbor will have a weight of 500.
Now the route map works a little differently. A route map can be made to modify the weight attribute. How does it work? A route map will act upon specific BGP prefixes that are exchanged with a specific neighbor, in a specific direction.
In the configuration in the lesson, an access list is created to identify the prefixes that we want to change the weight attribute for.
R1(config)#access-list 1 permit 22.22.22.0 0.0.0.255
The route map is configured to match this access list, and if any match is made, to set the weight for that particular prefix to 400. The route map has a second statement that sets the weight to 0 for any prefix that does not match the access list. This is necessary in order to allow all other prefixes to pass without being modified.
Finally, the following commandâŚ
R1(config-router)#neighbor 192.168.13.3 route-map SETWEIGHT in
âŚtells the router to pass all prefixes exchanged with this neighbor (R3) through the route map. If there is a match, change the weight to 400. Note also, that this will only take place in an âinwardâ direction. That is, the route map will only be applied for prefixes sent from R3 towards R1.
Itâs important to note here that the route map acts upon the exchanged BGP prefixes and not on actual user traffic. The result is:
BGP prefixes sent from R3 to R1 will be examined by the route map. If the prefix is 22.22.22.0/24, a weight of 400 will be assigned to it. If the prefix is anything else, a weight of 0 is assigned to it. The result can be seen in the BGP table of R1.
I hope this has been helpful!
Laz
Hello Sir,
Thank you so much.
Best regards,
Brahim
1 Like
Rene,
You might want to add a note to this lesson that the default weight for networks/paths that originate in the router is not 0 but is actually 32768. The different defaults for routes originating in the router vs added by another router threw me for a loop at first.
Cheers,
Joe
Hello Joe
Thanks for the feedback, Iâll let @ReneMolenaar know about your suggestion. I think itâs a good oneâŚ
Thanks again!
Laz
1 Like
kindly correct meâŚif I configure teh route-map IN it will effect my local BGP table and if i will configure the OUT then it will affect my neighbor BGP table .
But Local preference and ,AS path prepend , u can configure the inbound and outbound direction as well .What happen in that case ??
Can u tell me any rule of thumb regarding BGP policy in and out ??
Hello Narad
Yes that is correct.
When applying local preference, you can do so in an inbound or outbound direction. The same applies. Take a look at this lesson, and imagine what would happen if you applied the route map outbound instead of inbound. Simply put, it would be the other BGP routerâs table that is affected.
The same goes for path prepending. Imagine this lesson and determine what would happen if you used the route-map outbound instead of inboundâŚ
I guess the rule of thumb would be what you mentioned before. Applied in an outbound direction, the neighborâs BGP table is affected. Applied in an inbound direction, the local BGP table is affected.
I hope this has been helpful!
Laz
I have a doubt while doing LAB
I am checking the prefix learned by R2
The output i got is
Now my doubt is according to Path selection criteria
Local Preference is at No2 and EBGP OVER IBGP is at no 7
So why it selected the EBGP path of 192.168.12.1 instead of the path 3.3.3.3 with 100 Local Preference
Hello Anoop
At first glance, this confused me as well! It took me a while but I finally realized whatâs going on.
First of all, the default local preference for BGP is 100. So if you see a blank in the LocPrf column of the BGP table, you can put in a 100 there. Based on this, you can see that since the local preference is the same, the tie-breaking attribute is eBGP vs iBGP.
Now the next question that came to mind is, why does the local preference appear in the entry for 3.3.3.3 and not in the entry for 192.168.12.1? Well, the local preference value will only appear if that value has been retrieved from an iBGP peer. Remember, the local preference is a value that is shared among iBGP routers. Therefore, the 100 in the first entry, is the local preference that is sent from R3. There is no local preference value received from R1 because thatâs an eBGP relationship, so no value is entered in the table, but the default is 100.
Now if you take a look at the BGP table of R4, you will see that the LocPrf column is populated like so:
R4#show ip bgp
BGP table version is 2, local router ID is 4.4.4.4
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
* i1.1.1.0/24 3.3.3.3 0 100 0 1 i
*>i 2.2.2.2 0 100 0 1 i
You see the LocPrf of 100 for both neighbors because they have been advertised as such over the iBGP peering.
I hope this has been helpful!
Laz
Thanks Lagapides
It was a bit confusing to see in âSH IP BGPâ
i should have done " SH IP BGP" with the prefix to check this
R2#sh ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 2
Paths: (2 available, best #2, table default)
Advertised to update-groups:
1
Refresh Epoch 1
1
3.3.3.3 (metric 3) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
1
**192.168.12.1 from 192.168.12.1 (1.1.1.1)**
Origin IGP, metric 0, **localpref 100**, valid, external, best
rx pathid: 0, tx pathid: 0x0
R2#
1 Like
Hi Rene,
First of all, thank you very much for this useful lesson. My question is, when all BGP features are equal, is the path selection based on the router id or is it based on the oldest path? When i tried this on my lab i restarted interfaces and noticed that oldest neighbour is selected as the path even i didnt change router id.
Hello Mehme
Assuming all other attributes are equal, the final three attributes that are used as tie breakers for the BGP path selection process are:
- oldest path
- router ID
- neighbor IP address
If a particular destination has two or more possible paths, then it is the path that was received first, or the oldest path, that is chosen. If the two possible paths were not received in the same BGP update, that means that they were received at different times. If that is the case, then it will indeed be the oldest path that is chosen.
Remember, an attribute will be used as a tiebreaker if it differs between the paths. In your case, the age of each path was not the same, so the oldest path attribute was used.
If the age of each path was the same, then it would go on to router ID for the next tiebreaker. Take a look at this lesson for more information about the BGP attributes and path selection.
I hope this has been helpful!
Laz
Hi Rene,
Why the route-map is applied as an incoming route? (neighbor 192.168.13.3 route-map SETWEIGHT in) as my understanding, you want to manipulate R1 outgoing traffic to 22.22.22.0. is it supposed to be SETWEIGHT out?
Please help to clarify this.