The direction that is specified in the command does not refer to the direction of user traffic and how it is to be routed. It refers to the direction of the BGP updates upon which you want to apply the change in weight.
So this particular route map will change the weight of the routes learned via BGP that come from R3 to R1 inbound. So specifically:
R3 sends an update to R1 containing the 22.22.22.0/24 prefix
This update enters the R1 router via Fa1/0 in an inbound direction
R1 has a route-map that will act upon this update in an inbound direction
the Weight is changed, and installed in the BGP table with the newly modified weight
Thus, from here on in, outbound user traffic destined to 22.22.22.0/24 will have a weight of 400.
The in keyword here referrs to the direction of the BGP Update message and not user traffic. What this is saying is that the route map will be applied to the routes found within the BGP update that is received from that neighbor (in an inward direction). The weight will be adjusted for those routes that match the statements in the route map.
The lowest RID was chosen as the tiebreaker, according to the notes from this lesson.
Also, I did some testing and found that itās not preemptive when I re-bounce the R1-R2 peer to check the path selection for 2.2.2.2/24 loopback IP in AS-2. It chose the next available path via R3 as the best path for 2.2.2.2/24. Even after the BGP peer came up b/w R1-R2, it still chose the best path via R3. Please confirm whether this is BGPās actual behavior.
BGP is not preemptive in nature. It will only reevaluate a best path if a new BGP update is received or if there is a topology change on a local interface. There are no periodic updates between BGP peers like there are in some other routing protocols.
R1 will choose R2 as the best path to the 2.2.2.0/24 network using the lowest router ID attribute only if an event triggers R2 to send a BGP update with this information. R1 will not know of R2ās lower router ID unless it receives an update.
Now you are seeing that if you bounce the R1-R2 peering, it still chooses the path via R2. How you bounce the peering will affect whether or not R2 will resend a BGP update. How are you bouncing your peering?
Also, if you issue the clear ip bgp command on R2, it will force all its peerings to reset, resulting in sending an update. If after that you get the expected result of the path via R2, all is well. If not, then it is likely that there is another attribute before the router ID that is causing R3 to be chosen over R2. Let us know what you come up with in your troubleshooting.
Why did you have to set the route-map permit 20 for IPs that do not match the access-list? Wouldnāt the subnets that do not match the permit 10 statement default to the weight 0 in the BGP table?
Thatās an interesting observation. Letās take a closer look.
Route maps have an implicit deny statement that will match āeverything elseā and simply deny it. If statement 20 was not added in the specific route map, all networks other than those that match ACL 1 will be denied implicitly and will not even be considered for BGP.
However, we want any other networks to be considered by BGP, but simply not to have the weight changed. So the permit statement must be there. However, you could do away with the set weight 0 command. You can simply have a match statement that does nothing. That will permit the other networks to be considered for BGP without changing the default weight.
So for the specific lab, having the set weight command or not would not change anything. However, in a production network, you may want to reset that weight to 0 in the event that the attribute was influenced by some other policy configured on the router. For example, if you had set another weight for all routes in the router but you wanted to reset the weight to 0 for those coming from that particular neighbor, then you would need to keep the set weight command there.
Firstable, big thanks to @lagapidis for respond to @romoorej I had the same question about the sequence 20.
Probably this question is to silly but I would like to understand why the route-map is used with āINā and not āOUTā. So far, I know the weight attribute is just for local router and it handles the outgoing routes
As for your next question, itās not a silly question at all, this comes up very often. The āinā and āoutā keywords here refer to the direction of BGP updates. Remember, the route map acts upon the BGP updates and not on user traffic. So on R1, we want to set the weight of any prefixes contained within BGP updates that are received from the 192.168.13.3 BGP peer (i.e. R3). So when R3 advertises the 22.22.22.0/24 prefix to R1, the route map will match that update, and make the weight for that prefix set to 400. So when you look at the local BGP table of R1, you see a weight of 400.
Hello Guys
I have one question here, someone asked this āRene,
Great lesson however, I have questions if we have two ISPs and we would like to route traffic out through ISP-1. It means we need to set up a higher weight on the ISP-1 peering with us and setup a lower weight on the second ISP-2?
How can we make sure traffic goes out ISP-1 and comes back in using ISP-2?
Thanksā
I was wondering is this is possible, cause Rene applied the route map in inbound direction. AFAIK, you canāt apply in outbound direction.
So, my guess is that I need to apply a prefix-list o ACL for a default-route where I include the default route (If Iām taking about internet) and apply the route map with a higher weigh to my prefer ISP ?
Thanks
You can check out Reneās response just below it. Keep in mind that if you are the administrator of a router connected to two ISPs, then you can only guarantee the behavior of outgoing traffic. You can do that using the weight attribute for the local router, and youāre right, if you use route maps, you can only apply them in an inbound direction. If you apply it in an outbound direction, it has no meaning because weight is not conveyed within a BGP UPDATE message. You can also use Local Preference if you want to influence how traffic exits your whole AS.
However, you cannot guarantee the behavior of incoming traffic. You can influence it, but any attributes you use to try to cause incoming traffic to come in via one ISP or the other can always be overridden by the ISP. Weight cannot be used for this. To influence incoming traffic, you can use MED, AS Path Prepending, BGP communities, or advertising more specific routes. But those methods can be overridden by the receiving (ISP) routers, and may also be considered contrary to ISP policies, something that may incur penalties if not discussed beforehand. Typically, you should negotiate with the ISP and ask them how you should achieve this, because each ISP has different methods of routing such traffic, and you should conform to what they request.
