Advanced BGP – Influencing Outbound Path Selection

There are two attributes that are used to influence the path that BGP speakers within the same autonomous system will take to exit the autonomous system. Unlike the attributes used to influence inbound path selection, the attributes used to influence outbound path selection are applied in the inbound direction, but also using route maps. These two attributes are:

• The LOCAL_PREF Attribute
• The WEIGHT Attribute

The use of these two attributes and how they are applied when configuring BGP in Cisco IOS software is described in detail in the following sections.

Influencing Outbound Path Selection using the LOCAL_PREF Attribute

The LOCAL_PREF attribute is used only within an autonomous system for path selection. That is, this attribute is not passed on between autonomous systems; however, the attribute is propagated within a single autonomous system. If an iBGP speaker receives an UPDATE for the same destination from multiple iBGP peers, it will prefer the path with the highest LOCAL_PREF value. However, if a BGP speaker receives an UPDATE message that includes the LOCAL_PREF and this message is received from another BGP speaker that is not in the same autonomous system, i.e. an eBGP peer, the LOCAL_PREF is ignored.

By default, Cisco IOS software assigns a LOCAL_PREF value of 100 for all prefixes. This value can be administratively changed to influence path selection using either route maps or the bgp default local-preference [value] command.

NOTE: The bgp default local-preference [value] command defaults to a value of 100. If this command is issued, the default LOCAL_PREF value is set to the specified value for all UPDATES sent by the local BGP speaker.

To further understand the application of the LOCAL_PREF attribute in Cisco IOS software, consider the basic BGP network topology that is illustrated in Figure 7-6:

Figure 7-6 shows a basic enterprise network that has four BGP speakers. For simplicity, assume that all routers have an iBGP peer relationship with all other routers. In other words, assume that a fully meshed iBGP implementation has been deployed. Within AS 1, edge routers E1 and E2 are peered to two different service providers. The link between E1 and S5 is 2Mb, while the link between E2 and S7 is 4Mb. The service providers, in AS 5 and AS 7, are advertising a single default route to the enterprise network.

Assuming a basic BGP implementation in AS 1, i.e. no attribute manipulation, the routers in AS 1 select the best path for the default route as follows:

• Router E1 receives the default route from external neighbor 150.1.1.1 (AS 5) as well as from internal neighbor 2.2.2.2 (E2). Assuming all else is equal; this router prefers the external path over the internal path and selects the router via S5 as the best path. This path is installed into the routing table on router E1

• Router E2 receives the default route from external neighbor 150.2.2.2 (AS 7) as well as from internal neighbor 2.1.1.1 (E1). Assuming all else is equal; this router prefers the external path over the internal path and selects the router via S7 as the best path. This path is installed into the routing table on router E2

• Router E3 receives the default route from internal neighbors 2.1.1.1 (E1) and 2.2.2.2 (E2). Assuming all else is equal, E3 selects the path received from the router with the lowest RID as the best path and installs the path received from E1 into the routing table

• Router E4 receives the default route from internal neighbors 2.1.1.1 (E1) and 2.2.2.2 (E2). Assuming all else is equal, E4 selects the path received from the router with the lowest RID as the best path and installs the path received from E1 into the routing table

Based on the best path calculations, routers E1, E3, and E4 all prefer the default route received from AS 5, while only router E2 prefers the default route received from AS 7.  Given that the path via AS 7 should be the preferred path, because of the higher bandwidth link between E2 and S7, the LOCAL_PREF attribute can be used to influence the path routers within AS 1 will take when forwarding packets using the default route.

In Cisco IOS software, this configuration is implemented by using route map which are then applied in the inbound direction on a per-neighbor basis. Within the route map, the set local-preference [value] command is used to set the LOCAL_PREF value. This is illustrated and verified in the following section.

Setting the LOCAL_PREF is Cisco IOS Software

As was stated in the previous section, the LOCAL_PREF is set using a route map which is then applied in the inbound direction. UPDATES propagated by the local BGP speaker to any other iBGP peers include the configured LOCAL_PREF value, which is then used to select the best path out of the autonomous system by the other routers. To ensure that all routers within AS 1 prefer the default route via AS 7, the following configuration would be implemented on E2:

Before looking at the contents of the BGP RIB on the routers in AS 1, we will first go through the commands executed in the example above. The first configuration command configures a route map that sets the LOCAL_PREF value to 123 for all routes. Next, this route map is applied inbound on router E2 for its external BGP session with router S7 in AS 7. And finally, a soft reset is executed to ensure that this policy becomes effective immediately. After implementing the configuration on E2, the BGP RIB on router E3 shows the following:

NOTE: A similar output will also be shown by E4 and E1. This output is omitted for brevity.

In essence, by simply configuring a higher LOCAL_PREF value on E2, iBGP speakers within AS 1 prefer the default route that E2 is advertising into the autonomous system and all traffic destined to external networks is forwarded across the E2-S7 link, which is the preferred egress.

Now that we have a solid understanding of how to use the LOCAL_PREF attribute to influence the path routers within an autonomous system use to exit the autonomous system, the following section describes the use of the Cisco-proprietary WEIGHT attribute, how it can be used to also influence the path routers within an autonomous system use to exit the autonomous system, and the differences between the LOCAL_PREF and WEIGHT attributes.

Influencing Outbound Path Selection using the WEIGHT Attribute

There are several differences between the WEIGHT attribute and the LOCAL_PREF attribute. The differences between the WEIGHT and LOCAL_PREF attributes are as follows:

• WEIGHT is a Cisco-proprietary attribute; LOCAL_PREF is a standard BGP attribute
• WEIGHT is locally significant; LOCAL_PREF is significant within the AS
• WEIGHT is not included in UPDATEs; LOCAL_PREF is included in UPDATEs

Despite their differences, these two attributes do have some similarities. For example, Cisco IOS software assigns a default LOCAL_PREF (100) and WEIGHT (32,768) to prefixes. However, keep in mind that the default WEIGHT is only locally significant and is for prefixes injected into BGP on the local BGP speaker, and not for received prefixes.

The next similarity is that the higher the value, the more preferred the path. In other words, prefixes with higher WEIGHT and LOCAL_PREF values are preferred over those with lower values during best path selection.

One of the most commonly asked questions is that if the LOCAL_PREF attribute can be used to influence outbound path selection within the autonomous system, why does Cisco use the WEIGHT attribute? To answer that question, consider the basic topology shown in Figure 7-7:

Fig.7-7. Understanding How to Use the WEIGHT Attribute

Figure 7-7 shows an enterprise network that has been separated into two regions: the west coast and the east coast. Within each region, remote site routers are connected to each other and the Internet facing (W1 and E1) routers. These Internet facing routers have a 45Mbps link between that allows remote offices in either region to communicate with each other.

The enterprise prefers that this link only be used for Internet traffic from either region when the Interface facing routers lose their BGP peering to their respective ISPs.  The Internet facing routers are receiving a full Internet routing table from their respective upstream ISPs. These two routers also have an iBGP peer relationship which allows Internet routes to be advertised to either region in the event that one of the regions loses connectivity to its upstream ISP. And finally, in addition to the site prefixes the Internet facing routers advertise to their respective regional remote offices, these two routers are also advertising a default route which allows regional sites to forward Internet-bound packets to them.

While the topology seems simple enough, if we understand the BGP path selection process, we can determine that the default implementation alone will result in the 45Mbps link between used for Internet traffic even when both Internet facing routers have established BGP sessions with their respective ISP peer routers. Let’s expand on this by going through an example.

Let us assume that within the complete Internet routing tables both the west coast and the east coast Internet facing routers receive from their respective upstream peers, both of the routers receive the 150.254.254.0/24 prefix. The prefix W1 receives from the west coast Internet Service Provider has the following AS_PATH:

• 150.254.254.0/24: AS_PATH = 4, 10, 30

The prefix E1 received from the west coast ISP has the following AS_PATH:

• 150.254.254.0/24: AS_PATH = 1, 30

NOTE: The WEIGHT is a non-factor at this point as this is a locally significant attribute that is not carried in UPDATE messages. The LOCAL_PREF attribute is also a non-factor because both routers are receiving this prefix from an eBGP peer. Any LOCAL_PREF values set by the eBGP peer are ignored when included in UPDATE messages. The first valid attribute that is therefore used for best path selection is the AS_PATH attribute.

Given the AS_PATH lengths for the 150.254.254.0/24 prefix, the west coast Internet router, W1, will prefer the path via its iBGP peer E1 because that path has the shorter AS_PATH length. This means that all traffic from remote west coast sites destined to any address in the 150.254.254.0/24 prefix will be forwarded by W1 to E1 and then to the Internet. The same logic would apply to all other prefixes received by either router. This is undesirable.

If for example, you attempted to influence the path that router W1 took to the Internet by using the LOCAL_PREF attribute, this configuration would affect Internet-bound traffic on router E1, as this router would now prefer the path via W1, its iBGP peer, instead of via the east coast ISP because the UPDATE messages for all prefixes received from W1 would have a higher LOCAL_PREF value. Again, this solution is also undesirable and does not resolve the issue.
To resolve this issue, the Cisco WEIGHT attribute should be used to influence the path selection process. By configuring both the W1 and E1 routers with a higher WEIGHT value for all prefixes that are received via their eBGP peers, both routers prefer those routes as the WEIGHT is the second attribute (after validating the NEXT_HOP) that is used in the BGP path selection process is Cisco IOS software. Because the WEIGHT is locally significant, this configuration has no effect on either router.

As with all other attributes described in the previous sections, the WEIGHT is specified within a route map using the set weight [value] command. Once configured, the route map would then be applied in the inbound direction on routers W1 and E1. Prior to using the WEIGHT attribute to influence outbound path selection, referencing the topology illustrated in Figure 7-7, the BGP RIB on router W1 shows the following for the 150.254.254.0/24 prefix:

In the output above, we can see that W1 prefers the path via E1 when sending packets to the 150.254.254.0/24 prefix. This means that instead of using the west coast ISP, the traffic is forwarded via the private 45Mbps link between the east and west coast regions. The same would apply to any other prefixes with the same basic attributes. As previously stated, the enterprise prefers that all Internet-bound traffic within each region use the regional Internet Service Provider. This can be accomplished using the WEIGHT attribute.

Following is the configuration that would be applied to router W1 to ensure that this router preferred the west coast ISP for all Internet prefixes received:

Following this change, the BGP RIB on router W1 now shows the following:

Even though the path via the west coast ISP has a longer AS_PATH, because the WEIGHT is used prior to the AS_PATH attribute in the path selection, that path is the preferred path because of the higher WEIGHT value of 100. For consistency, the same must also be applied network-wide, i.e. on router E1. While a route map is the most common way of setting the WEIGHT, Cisco IOS software allows you to configure a default weight for all prefixes received from a peer using the neighbor [address] weight [value] router configuration command. The following configuration illustrates how to use this command to configure a WEIGHT of 100 for all prefixes that router E1 receives from the east coast ISP:

Following this configuration, the BGP RIB on router E1 shows the following:

Comparing the output of the show ip bgp command on routers W1 and E1, we can see that both routers prefer the path via their ISP. However, both routers also have a secondary path via their respective iBGP peer. This path will be used when the primary path is not available.

Because the WEIGHT and LOCAL_PREF attributes are somewhat similar, they are very often used incorrectly. It is very important to take the time to understand when to use one or the other. For example, let us assume that the same route map configured on router W1 specified the LOCAL_PREF instead of the WEIGHT, as shown in the following output:

The result of this configuration is that W1 prefers the west coast ISP for the 150.254.254.0/24 prefix. This can be validated by looking at the BGP RIB as follows:

However, because the LOCAL_PREF is included in UPDATE messages sent within an AS, this configuration would also mean that E1 prefers the same path as illustrated below:

From the output above, we can see that using the LOCAL_PREF attribute in this case produces undesirable results based on the requirements that the 45Mbps private link between the east and west coast be used primarily for inter-coast enterprise traffic, while each region should use its ISP for Internet-bound traffic.

In conclusion, a lot has been described in this section and it will probably take some time to grasp all of it. Therefore, we will conclude section by including Table 7-2 which lists the attributes described in this section as well as what they are used for and how to apply them:

Tab.7-2. BGP Attributes for Inbound and Outbound Path Manipulation