BGP Policy-Based Routing Functions Within an Autonomous System

Border Gateway Protocol mandates that a BGP router can advertise only routes that it uses itself to peers in an AS. This is exactly the way that routing hops function on the Internet. BGP is well suited for the modern Internet because it supports any implemented policy that abides by the current " hop-by-hop " routing mechanism. You cannot change how your peer AS will route your packets. You can affect only the manner in which your packets get to your peer ASs.

When a BGP router stores multiple routes to the same destination network in its routing table, it uses a complex sequence of configurable metrics known as attributes to choose the optimal path. Path attributes fall into one of the following four categories:

• Well-known, mandatory

• Well-known, discretionary

• Optional, transitive (only these can be marked as "partial")

• Optional, non-transitive

Well-known mandatory attributes, as the name signifies, must appear in all BGP update messages. These attributes are implemented and recognized by all compliant BGP implementations. These attributes are sent to BGP peers and must appear in the route description data. A well-known, discretionary attribute does not have to exist in a route description. It may or may not be included. An optional attribute could be some special attribute that is supported by only certain BGP implementations . A BGP speaker might not recognize an optional transitive attribute and it is not expected to because it is destined for some private BGP network. If the BGP router fails to recognize an optional transitive attribute, it will mark it as a partial message and will continue to propagate it to its peers untouched (transitive). An optional non-transitive attribute must be dropped (deleted) by the non-compliant router. Table 8.3 shows the four main categories of attributes and the associated attribute item.

Table 8.3. Path Attribute Categories and Associated Attributes

Category	Associated Attributes
Well-known, mandatory	AS-path, Next -hop, Origin
Well-known, discretionary	Local preference, Atomic aggregate
Optional, transitive	Aggregator, Community
Optional, non-transitive	Multi-exit-discriminator (MED)

AS_path Attribute

The AS-path attribute is BGP type code 2 and is a well-known mandatory attribute. Every BGP has an associated type code as will be shown through out this chapter. Whenever a route update passes through an AS, the AS number is prepended to that update. The AS-path attribute is actually a list of AS numbers that a route has traversed to reach a destination. An AS-set is an ordered mathematical set of all the ASs that have been traversed. If the route (or routes) does not originate from the local router, it will take the path with the shortest AS-path attribute. If the routes share the same AS path value, the router will give preference to the route with the lowest Origin attribute. Origin codes are displayed next to entries in the BGP routing table in a similar fashion to the code entries in the routing tables for other IP routing protocols.

In Figure 8.3, an update message exits AS 65510 and transits AS 65520 on its way to AS 65520. RouterB then prepends its AS number to the AS-path list so that RouterD has an AS path to 172.16.10.0 of (65520,64510).

Figure 8.3. The AS-path attribute at work.

Next-hop Attribute

The Next-hop attribute is BGP type code 3 and is a well-known mandatory attribute. The BGP Next-hop attribute is simply the next hop IP address that is going to be used to reach a certain destination. For EBGP, the next hop is always the IP address of the neighbor specified with the neighbor command. The following code snippet shows a BGP router specifying a neighbor with the neighbor command:

 RouterA#config t Enter configuration commands, one per line.  End with CNTL/Z. RouterA(config)#router bgp 65500 RouterA(config-router)#network 172.16.0.0 mask 255.255.255.0 RouterA(config-router)#network 10.1.10.0 mask 255.255.255.0 RouterA(config-router)#network 10.1.20.0 mask 255.255.255.0 RouterA(config-router)#neighbor 172.16.11.1 remote-as 65000 

Origin Attribute

The Origin attribute is BGP type code 1 and is a well-known, mandatory attribute. The Origin attribute defines the origin of the path information.

The origin code is an indication of whether the route originated from internal BGP (IBGP) or external BGP (EBGP). If the routes have the same origin code, the route with the lowest multi-exit-discriminator (MED) is preferred.

The Origin attribute can assume three values as described in Table 8.4.

BGP transmits routing update messages that contain Network layer reachability information (NLRI) to portray a particular route and how to get there. An NLRI is a prefix or assigned ASN that needs to be advertised over the Internet. A BGP update message holds one or more NLRI prefixes, as well as the attributes of a route for the NLRI prefixes. Route attributes include such elements as a BGP next hop address, Origin attribute, and more.

Table 8.4. Origin Attribute Values

Origin Attribute Value	Description
IGP	The Network layer reachability information (NLRI) is internal to the originating AS. When the bgp network command is used or when IGP is redistributed into BGP, the Origin attribute value is IGP. When the origin of the path information is IGP, the indicator i appears in the BGP table.
EGP	The NLRI is discovered through an EGP such as Border Gateway Protocol. This value will be represented by an e in the BGP table.
INCOMPLETE	In this case the NLRI is unknown or is learned by some other method such as a redistributed static route into BGP where the origin of the route is incomplete. This is indicated with a ? in the BGP table.

Local Preference Attribute

The Local preference attribute is BGP type code 5 and is a well-known discretionary attribute. It is an inverse value of the MED attribute described later in this section. EBGP neighbors use the Local preference attribute to guide outbound update traffic through a specific router. A path with higher Local preference value will be preferred over paths with lower Local preference values. An example of this is shown in Figure 8.4, in which the update message bound for AS 65504 will exit AS 65501 RouterA because of the higher Local preference value.

Figure 8.4. RouterA is preferred over RouterB because of the higher Local preference attribute.

Atomic Aggregate Attribute

The Atomic aggregate value is BGP type code 6. It is a well-known discretionary attribute that notifies BGP routers of policy routing choices made when there are overlapping routes. It is used to decide that a prefix will or will not be used.

Aggregator Attribute

The Aggregator attribute has a BGP type code of 7. It is an optional transitive attribute made up of the AS number and the identifying IP address for a total of 48 bits. This attribute is often appended to messages that are performing aggregation (route summarization) to designate the AS and the BGP router performing the aggregation.

Community Attribute

The Community attribute is BGP type code 8 and is an optional transitive attribute. This value has a range of 0 to 4,294,967,200 and is a method for clustering destinations into a particular community and employing routing decisions accordingly . You can use route maps to set the Community attributes. This is addressed in detail in Chapter 9.

You need to know that a route map is a technique for modifying and maintaining routing information by defining certain conditions for redistributing routes from one protocol to another.

Multi-exit-discriminator (MED) Attribute

The Multi-exit-discriminator attribute is type code 4 and is an optional non-transitive attribute. Multi-exit-discriminator, formerly the inter-AS attribute, is a metric incorporated into BGP updates to give external (EBGP) neighbors a favored path when there are two or more entry points into the local AS. MED is implemented to tell, or influence, remote ASs regarding the best path(s) into the local AS. If identical MED values exist, the router chooses a path through an interior BGP (IBGP) peer rather than through an exterior BGP peer (EBGP). The router finally selects the path with the lowest BGP peer Router ID value if the route is available only via an EBGP peer.

As you can see in Figure 8.5, RouterA has the MED value set to 200 and RouterB has the MED value configured to 300. RouterC will choose RouterA as the optimal next hop when it receives updates from RouterA and RouterB, because it prefers the lower MED metric. In situations where there are multiple entry points into the local AS and you want to direct inbound EBGP updates to a preferred EBGP route, set a lower MED attribute for the preferred route. A route map is used to configure the MED value for a route. Although route maps are covered in later chapters, it is important to realize that they are mechanisms used to manage and change routing information by determining conditions for redistributing routes from one protocol (or AS) to another. By using the MED metric, BGP will be the only set of rules that will attempt to influence how routes are injected into an AS.

Figure 8.5. The MED attribute at work.

Know the difference between the Local preference attribute and the MED. To help you remember, the term "local" represents information used inside the AS (intra-AS). Therefore, the Local preference attribute is exchanged only between internal BGP peers to determine preferred paths to exit the AS. It is not passed on to EBGP neighbors. MED, on the other hand, is shared among ASs. The metric is transported to a peer AS and used for decision making without being further passed to the next autonomous system.

Weight Attribute

Cisco also has a proprietary defined Weight attribute for BGP. Weight is a locally stored and manually assigned attribute used to designate the desirability of a route. If a next-hop router is available for multiple routes, the router will choose the one with the highest Weight value. If the multiple routes have the same weights, the router will pick the route with the highest Local preference value. Local preference also serves as a guide to route desirability, but it is shared among all IBGP neighbors in an AS. When paths have identical Local preference values, a route generated from the local router is favored over a route resulting from a remote router. The following sample output shows the Weight values in the show ip bgp output:

[View full width]

 
 [View full width] 
 RouterA# show ip bgp BGP table version is 583644, local router ID is 172.28.124.90 Status codes: s suppressed, d damped, h history, * valid, > best,  i - internal Origin codes: I  IGP, e  EGP, ? - incomplete     Network          Next Hop          Metric    LocPrf   Weight  Path *>  10.24.0.0        172.20.32.2           0       100      200  481  i *>  10.33.0.0        172.24.20.1           0       100      200  140  i *   10.55.0.0        172.23.1.10           0       300      100  360  i s                    192.168.5.2           0       450      150  200  i *>                   192.168.6.10          0       500      200  100  i *                    192.168.7.4           0       150      180  200  i 

Here is the syntax to configure the proprietary Weight value:

 neighbor {ip-address  peer-group-name}  weight  weight 

The parameter ip-address is the IP address of the designated neighbor router and weight is an integer value between 1 and 65,535. If unspecified, the router defaults to 32,768 for all routes.

Route Selection Process

Now that you have a grasp of the different attributes, let us see how they play into the BGP route selection process. BGP determines which path to choose to reach a certain destination network as soon as it receives updates about different destinations from other autonomous systems. BGP ultimately selects only one optimal path to a particular destination. BGP chooses the best route for routing traffic toward the destination, based on the following steps:

1. If the route is not in the IGP routing table (the route is not synchronized and synchronization is enabled), or the next hop address is unreachable, ignore it. When synchronization is enabled, a BGP router will not use or advertise a route learned by IBGP to an external BGP peer unless the route is local or is learned from the IGP.

2. Use the route with the highest Cisco-proprietary Weight attribute (Weight is local to the router only). If multiple routes have the same Weight, use the route with the highest Local preference attribute (Local preference is used intra-AS).

3. If the multiple routes have identical Local preference values then the route generated by the local router is selected. If multiple routes have the same local preference, or if the local router did not generate a route, use the route with the shortest AS-path attribute value.

4. If the AS-path length is identical, use the route with the lowest Origin code value. IGP is lower than EGP, which is lower than incomplete. If all the Origin codes are the same, choose the path with the lowest MED attribute. (Remember that the MED value was sent from another AS. Refer to Figure 8.5.) This step occurs only when the neighboring AS is the same for all the routes that are being considered .

5. If the routes have an identical MED attribute then give preference to external paths (EBGP) over internal paths (IBGP).

6. If you have disabled synchronization (see the synchronization section later in this chapter) and only internal paths remain , the shortest internal path within the AS to the destination (the closest IGP neighbor) will be chosen . If the remaining paths are EBGP paths, choose the oldest route to counteract flapping routes. This last step is proprietary behavior in Cisco routers.

7. Next, select the route with the lowest neighbor BGP router ID value. Loopback addresses are typically used to influence this decision. If the IDs are identical, then choose the route with the lowest neighbor IP address.

This is a generalized summary example of the process that BGP goes through before it injects a route into the routing table and propagates it to its peers.