Hi Lagapides,
If I were to follow the rule of thumb of “in” for outbound and “out” for inbound for BGP PAs, why is this different for AS-Path prepending, if according to Cisco AS path prepending is for outbound traffic.
R1(config)#route-map PREPEND permit 10
R1(config-route-map)#set as-path prepend 1 1 1 1 1
R1(config-route-map)#exit
R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 route-map PREPEND out
Thanks
Hello Champion
My apologies, you’re absolutely right, I should have been clearer. This rule of thumb is only applied to the application of route maps for BGP neighbors when applying it to the weight and local pref attribute. It is not the case when applied to other parameters such as AS_PATH. The reason for this is that both weight and local pref are attributes that are local to the router and not shared.
Think about it this way: the direction for weight and local pref has to do with the direction of information you learn. You only learn info that comes into the interface.
I hope this has been helpful!
Laz
Is the second permit statement necessary? Won’t other prefixes outside of the matching ACL be assigned the default weight value?
Please clarify.
Thanks
Hello Billing
There are two purposes to the second permit statement. The first is that route maps have an implicit deny statement at the end. This means that if there was only one permit statement, then all prefixes outside the matching ACL would simply be denied. Secondly, the second permit statement resets the weight of any other routes received to 0, so that any changes to weight made downstream are cancelled out here.
I hope this has been helpful!
Laz
lagapides sir
I am confuse little bit u have applied 2 permit statement but i can do the same work with 1 permit statement you have used SETWEIGHT 0 why you use it if i am not using this permit statement my connection is working and in bgp table i can see all network go by 192.168.12.0 path with weight 0 and 22.22.22.0 by setweight 400 routemap please clarify this permit statement see below :
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.0/24 192.168.12.2 0 0 2 i
*> 3.3.3.0/24 192.168.12.2 0 0 2 i
*> 4.4.4.0/24 192.168.12.2 0 0 2 i
* 5.5.5.0/24 192.168.12.2 0 2 i
*> 192.168.13.3 0 200 2 i
sir but when i follow both permit command then 192.168.13.0 link add in bgp table see below:
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.0/24 192.168.12.2 0 0 2 i
* 192.168.13.3 0 0 2 i
*> 3.3.3.0/24 192.168.12.2 0 0 2 i
* 192.168.13.3 0 0 2 i
*> 4.4.4.0/24 192.168.12.2 0 0 2 i
* 192.168.13.3 0 2 i
* 5.5.5.0/24 192.168.12.2 0 2 i
*> 192.168.13.3 0 200 2 i
sir please clear it
Hello Harshit
There are two statements because what we want to do the following:
For all incoming BGP updates, we want to look at the networks in those updates and:
Now if we just used the first statement, it would still work, just like you said. However, if we only have the first statement, what happens if an update comes in with a destination network of 33.33.33.0/24 and a weight of 200? That weight would remain at 200, but this is not what we want. We want to reset EVERYTHING else to a weight of 0, and this is why we have the second statement.
In your case it works because all other networks you are sending already have a weight of 0.
I hope this has been helpful!
Laz
Sir,
Please can you show below output result command on (R2)
sh ip bgp nei 192.168.12.1 advertised-routes
Thanks!
Hi Asos,
Sure, here it is:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes
BGP table version is 3, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.0/24 0.0.0.0 0 32768 i
*> 22.22.22.0/24 0.0.0.0 0 32768 iRene
Hi Rene,
Can you please clear about route-map inbound and outbound where they are used, it’s bit confusing to found where we have to use it.
Thanks
Hello Navraj
When we are talking about inbound route maps, we are talking about modifying the information found in BGP updates that are coming in to an interface. So a command such as:
R1(config-router)#neighbor 192.168.13.3 route-map SETWEIGHT in
will cause all updates coming from this specific neighbor to the SETWEIGHT route map applied to them. Remember that the “in” or “out” does not apply to the actual user traffic, but applies to the BGP updates themselves.
I hope this has been helpful!
Laz
Thanks for the clear example. This may be a silly question but I’ll go anyway. If we are influencing the outbound traffic with Weight or Local Pref, how does this affect the return traffic? Does the far end router go through the same evaluation to decide best path back which could be a different path? Or does it use the same path for return traffic?
Thanks,
Brian
Hello Brian
First of all, no question is silly, feel free to ask away, that’s how we learn!
Now Weight and Local Pref are used only to influence outbound traffic. Specifically, Weight, which is limited only to a single device, influences the exit interface chosen for outbound traffic from a particular BGP router, while Local Pref will influence the choice of path to exit a particular AS. These locally configured attributes will have no effect on incoming traffic.
Incoming traffic on the other hand can be influenced, but cannot be enforced. What does that mean? When influencing inbound traffic using BGP, it is the far end router that has the last word on the subject. No matter what you do, the far end router has the capability of overriding any attempts you make to influence incoming traffic. If the far end router(s) are owned by an ISP, the best thing to do in such situations is to involve the ISP in the network configuration process. Talk with them, tell them what you require and find a solution that will be mutually beneficial.
The particular attributes that can be used to influence (but not enforce) incoming traffic can be found in the following post:
I hope this has been helpful!
Laz
Hi Rene ,i have little doubt , As we say Weight is local to router and will not goes to neighbor bgp router, Since we have configured weight on R1 how R2 or R3 influencing/Sending perfix 22 or 2…from the higher weight link. , when we increase weight at R1, Rather prefixes connected to R1 should be influenced ,when we should check them at R2 or R3…Means…perfixes 2… or 22… are external traffic for R1
Hello Parwinder
Weight is indeed a local attribute and information about weight will not be shared between BGP routers. Weight will simply choose one path over another based on its value. This means that in the topology in the lesson, R1 will place a weight of 500 or all prefixes learned from neighbor 192.168.13.3 which is R3.
So in this case, R3 will send a BGP update telling R1 how to reach 2.2.2.0. R2 will also senda BGP update telling R1 how to reach 2.2.2.0. Because the weight of R3 is configured to be greater, the path to 2.2.2.0 in the BGP table of R1 is chosen to be via R3, the router with the greatest weight.
Notice that the weight is evaluated only within the R1 router, but is based on the prefixes sent by R2 and R3.
I hope this has been helpful!
Laz
Hello Rene, I think the weight can influence the outbound traffic from a local router right? So that’s the reason we might put that in "IN " direction which allows the prefixes to apply the policies while getting injected in to our own local router so that we can later use them to influence the outbound traffic at the time of data plane.
Hello Unni
Yes, this is correct. The prefixes that are learned from R3 travel from R3 to R1 (inbound from the point of view of R1), which means that the route map is applied on inbound routes. The use of the terms inbound and outbound are often confusing because in this particular case, they are used to describe the exchange of prefixes using BGP and not traffic itself.
For example, the prefix 22.22.22.0/24 is advertised by R3 to R1. This is an inbound advertisement from the point of view of R1, which means we go through the route-map SETWEIGHT. Statement 10 is matched, and the weight is set to 400 and stored as such in the BGP table. The traffic to this destination is sent outbound via Fe1/0 due to the weight attribute that was set.
I hope this has been helpful!
Laz
HI,
I’m tryng to set the weight of a prefix of an aggregate address but I think that I’m doing something wrong.
for example Ive configured the aggregte address for 172.16.0.0 255.255.0.0.
with 172.16.10.0/24 - 172.16.20.0/24 - 172.16.30.0/24
And I want to set the weight only for the last one prefix.
Anyway the weight is not being modified until the access-list of the route map match exactly the summary address.
I hope that my example is clear,
Thanks
Hello Giovanni
Whenever you use the aggregate-address command on Cisco IOS without any parameters, then all information about individual route attributes including the weight is lost. This is also the case for the AS_PATH attribute. Because the AS_PATH is used for loop prevention, it can cause some issues. For this reason, there are ways that the AS_PATH attributes of the individual prefixes can be included in the summary, using the BGP AS-SET parameter.
However, because the WEIGHT attribute is not similarly critical (and is a Cisco proprietary attribute) there is no similar way to keep the WEIGHT attribute intact, unless you use the exact match in the access list as you mention.
More information about the AS-SET parameter of BGP can be found at the following lesson:
I hope this has been helpful!
Laz
For
I tried configuring till advertising 2.2.2.0/24 from R2 and R3 and since both the Loopbacks were configured with the same address, there was a conflict of the Router IDs, I changed it on both R2 and R3 with 22.22.22.22 and 33.33.33.33 respectively and R1 started choosing R3. However, I have doubts on the below line.
Router R1 decided to use 192.168.12.2 as the next hop. All the BGP attributes are the same so it came down to the router ID to select a winner. Now let’s change this behavior using the weight attribute…
How R1 chose 12.2 as the next hop since it is not the highest IP address and 13.3 should have been chosen instead. Please clarify me on this.
Hello Raj
When it comes down to the router ID, it is always the lowest neighbor router ID that “wins”. So since this is the case, the behaviour is correct.
Take a look at the following lesson for the detailed explanation:
I hope this has been helpful!
Laz
