So we're now going to look at the Weight. I've included Weight in the list even though it's not really an attribute. A BGP attribute is passed from BGP speaker and from AS to AS. A Weight isn't passed from any BGP speaker. It's just local to the router, and it's stored within the BGP RIB when prefixes arrive on the router. So i like to see Weight as a local preference that only applies to the router and indeed it overrides the local preference as we'll see later. Highest Weight wins, easy to remember I think, a little bit like local preference, highest local preference wins. It can be applied in a number of ways. We can apply weight to all routes from a neighbor, so you can apply Weight directly on the neighbor peering. It can be applied to routes based on a filter as well, and it can be applied within the policy language that Cisco IOS and other vendors implement also. So when would we actually use weight? Well, we've got a couple of examples here which have been used and are used on networks on the internet today. The first example is to help deploy RPF. RPF is reverse path forwarding. It's a common check used to catch spoofed source addresses coming from adjacent networks and the internet today So we refer to the diagram, if we want to deploy RPF in this case, and this is an example of an Autonomous System that has got two links to a neighboring AS. If we want to deploy RPF on this, then we need to use the Weight otherwise we end up with severe problems with connectivity. So let's look at the diagram, the link from AS1 to AS4, from router B to router C is the primary link. We also have a backup link from router A to router C, and what we want to do is have all the traffic go from AS1 to AS4 over the B to C link. So what we do as we've learned when we looked at the local pref attribute is set high local preference on it So i think that should be quite clear high local pref make it 200 outbound traffic from AS1 to AS4, goes from router B to router C. We have the backup link from route A to router C, so if the primary path fails then traffic will use the AC link. What now if we want to implement RPF. Well reverse path forwarding check will check the source address of the packets coming from router C to make sure that they're reachable back through the link they came in on. So if we turn on RPF on router A on the link to router C, what would happen in the scenario we've set up here? Well AS1, we've set local pref 200, on the path B to C. So all prefixes from AS4 as seen in AS1 of local pref200, including those on route array. So when router A does the RPF check, a legitimate packet comes in from AS4, the source address is AS4 address space. What's the best path? Well the best path has local preference 200 from router B not back on the direct link to router C. So the RPF check will cause router A to drop that packet even though it is valid. This is bad, so to work around it what we do is all prefixes we learn on router A from router C, we set a high weight. If we make the Weight even 100, it's the only path we're hearing prefixes directly on. Everything else we hear about IBGP has Weight of zero, so this path will win. So that means the RPF check will succeed because now the best path only from router A to router C is on on the direct link. For the rest of AS1 the local preference 200 will indicate that the best path is through router B and onwards to router C. We have included a description of how URPF works elsewhere in this series. The second example of the use of the Weight is for traffic policy. Many operators use this if they're trying to give specific paths for specific end users and user customers of theirs. Here's an example that I've commonly been involved in, and it shows how to give particular set of customers a particular transit to other Autonomous Systems. The diagram has AS1 as the service provider and maybe a couple of upstreams AS4 and AS7, giving connection to the rest of the internet. Now what AS1 wants to do is most of its customers that are connected to AS1 walk head through router B to use the big link to AS4 to get to the rest of the internet. Router A also has another connection to another upstream maybe a smaller link, maybe a bigger bandwidth link, who knows, and it may have some customers that are also connected to router A. There could be a particular class of customers, they could be transit customers again whatever the operator has decided. What we want to do is to have the customers connecting to router A to use the direct link through AS7 and then to AS4 to see the internet, while the rest of AS1 simply uses the main transit link from B to C to AS4. Now if we want the whole of AS1 to use the main transit link we set local preference 200 on everything we hear from router C. The problem with this is that router A then sees the best path through router B. So any of the customers connected to router A would see best path to B, even though they have an external link to AS7 and then on to AS4. So where we fix it for router A customers is to set a Weight of 100 and all the prefixes we learn from AS7 and then router A customers would use the outbound path to AS7 for their internet access. So this is how Weight can be used to override local preferences for localized traffic policy. It's an extremely useful feature for BGP and it's used by several operators in fairly specialized situations like this. So as a recap the Weight is not a BGP attribute, but it is actually stored in the BGP RIB. It can be set on the local router and is used by the local router in a case where the network operator wants to override the local preference that's used for the Autonomous System.

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.