How to Configure BGP Weight Attribute

Please can you show below output result command on (R2)

sh ip bgp nei advertised-routes


Hi Asos,

Sure, here it is:

R2#show ip bgp neighbors advertised-routes 
BGP table version is 3, local router ID is
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
 *>                  0         32768 i
 *>                  0         32768 i


1 Like

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.


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


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?



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!


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 which is R3.

So in this case, R3 will send a BGP update telling R1 how to reach R2 will also senda BGP update telling R1 how to reach Because the weight of R3 is configured to be greater, the path to 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!


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



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

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,


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!



I tried configuring till advertising 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 and respectively and R1 started choosing R3. However, I have doubts on the below line.

Router R1 decided to use 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!


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 .
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 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 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!


Hi Rene/Laz,

In your example you mention that R1 selects the route via next-hop 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?


Hello Bhawandeep

Actually, for the case where the router ID is used, R1 selects the route via next-hop
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!


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: passive bad OPEN, wrong router identifier

I changed the IP’s and the adjacence came up. Why is this the case in my LAB ?