What you should know about BGP’s LOCAL_PREF

In the previous blog post, we looked at the BGP NEXT_HOP attribute. Today we’ll cover another attribute: the LOCAL_PREF or local preference.

What is LOCAL_PREF?

The LOCAL_PREF (local preference) is the first attribute a Cisco router looks at to determine which route towards a certain destination is the “best” one and deserves a spot in the router’s routing table. If you look at the BGP best path algorithm on Cisco’s website, you’ll see no fewer than 13 steps to make this determination. The algorithm is executed for each prefix in the BGP table—i.e., each of the nearly 600,000 IPv4 and IPv6 prefixes that are currently present in a full BGP feed. This way, the best path towards each destination will be used. Three steps are by far the most important ones.

• Prefer the path with the highest local preference
• Prefer the path with the shortest AS path
• Prefer the path with the lowest multi-exit discriminator (MED)

We’ll look at the AS path and MED attributes in subsequent articles.

The way the BGP algorithm works is as follows. Suppose a router has three BGP sessions, and receives a route towards a given destination over each session, where one route has a local preference of 200, one has a local preference of 150 and one has a local preference of 75. “Prefer the path with the highest local preference” means the route with a LOCAL_PREF of 200 is used, which means that it’s installed in the main routing table and propagated to BGP neighbors as allowed by policies/filters. The other two routes with LOCAL_PREFs of 150 and 75 are kept in the BGP table, but aren’t used at this time and also not propagated to BGP neighbors.

Things get more interesting when there are two or more routes with a local preference of 200. Unless a router is configured for multipath BGP, only a single BGP path/route may be used. What happens here is that both routes with the highest LOCAL_PREF of 200 are selected at this step, and the algorithm progresses to the next step, where the AS path length is compared. But more about that in the next article.

An important thing to understand about the local preference is that it’s local in the sense that the attribute is only propagated over iBGP sessions (within our AS) and not over eBGP sessions (to external ASes). So when a router learns a prefix from a neighbor in another autonomous system, the update will not contain the LOCAL_PREF attribute. But when the router then propagates the prefix towards BGP neighbors within the local AS, these updates do contain the LOCAL_PREF attribute. As a result, when executing the command show ip bgp, the output will show routes with and without a local preference value:

The default value for the local preference is 100. This also means that a route that has no local preference value is treated as if it had a local preference of 100. So in the example above, all the routes except for the fourth and the sixth share the highest local preference value of 100. So these five prefixes are carried over to the following steps in the path selection algorithm, while the fourth and sixth routes are no longer considered because they have a lower LOCAL_PREF value.

The local preference is commonly used to make traffic flow align with business relationships. For background about this, see the seminal paper Stable Internet Routing Without Global Coordination. The idea is that connections to customers get a higher local preference than connections to peers, and connections to peers get a higher local preference than connections to transit providers. For instance:

• Customers: 150
• Private peering: 130
• Preferred internet exchange peering: 120
• Other internet exchange peering: 110
• Transit ISPs: 100

So if a customer announces prefix 203.0.113.0/24, then traffic will always flow over the route directly to the customer by virtue of that route having the highest possible local preference. But when the connection to the customer fails, traffic may be rerouted through the customer’s second ISP. If that ISP is reachable through multiple peerings, the private peering (LOCAL_PREF 130) will be used if possible, and otherwise the preferred internet exchange (120), a less preferred internet exchange (110), or, if there’s no other option, the traffic will be handled over a transit connection. Setting the local preference is done through a route map:

This route map sets the local preference to 110 for all prefixes received from neighbor 198.51.100.90. It is of course also possible to selectively change the local preference only for routes matching certain conditions.

Some BGP-capable customers connected to multiple ISPs may want to use one of those ISPs as a backup only. So under normal circumstances, no traffic flows through that ISP. This can be accomplished by having a local preference lower than peering and transit in that ISP’s network. Big ISPs often let customers trigger this by adding a community attribute to their BGP announcement. For instance, Level 3 allows customers to use the communities 3356:70, 3356:80 and 3356:90 to set the local preference for their prefixes to 70, 80 or 90, respectively, in the Level 3 network. As a result, traffic for such a prefix that enters the Level 3 network will be sent on its way through a peering connection (or a second customer connection with the regular local preference). Only when that other path with a higher local preference goes away will Level 3 start using and advertising the lower LOCAL_PREF path.

If you took the time to look at the page outlining Cisco’s BGP best path selection algorithm (versions used by other vendors are quite similar), then you may have noticed the local preference step is actually the second of the 13 steps. The first one is to prefer the path with the highest weight. The weight is not a BGP attribute; it’s a local parameter that is not communicated between routers. In some uncommon situations it can be useful to increase the weight so a path with a lower local preference is preferred over one with a higher local preference. This is done with a route map like the one above, only substituting “set local-preference …” with “set weight …”. By default, Cisco routers attach a weight of 32768 to prefixes that are injected into BGP, while prefixes learned over eBGP or iBGP have a weight of 0. This way, the router always prefers its own locally generated route and the router will always attempt to advertise that route to other BGP routers, regardless of the local preference and other attributes present on the routes learned from other routers.