BGP Attributes

BGP Attributes

BGP associates several different basic attributes with each route prefix. These attributes include useful pieces of information about the route, where it came from, and how to reach it. Well known attributes must be supported by every BGP implementation. Some well known attributes are mandatory. All of the mandatory attributes must be included with every route entry. A BGP router will generate an error message if it receives a route that is missing one or more well known mandatory attributes.

There are also well known discretionary attributes, which every BGP router must recognize and support, but that don't have to be present with every route entry. Whenever a router passes along a route that it has learned via BGP to another BGP peer, it must include all of the well known attributes that came with this route, including any discretionary attributes. Of course, the router may need to update some of these attributes before passing them along, to include itself in the path, for example.

BGP routes can also include one or more optional attributes. These are not necessarily supported by all BGP implementations. Optional attributes can be either transitive or nontransitive, which is specified by a special flag in the attribute type field. If a router receives a route with a transitive optional attribute, it will pass this information along intact to other BGP routers, even if it doesn't understand the option. The router will mark the Partial bit in the attribute flags to indicate that it was unable to handle this attribute, however.

The router will quietly drop any unrecognized nontransitive optional attributes from the route information without taking any action.

We will now describe several of the most common BGP attributes.


ORIGINWell known, Mandatory

This attribute can have one of three different values, reflecting how the BGP router that was responsible for originating the route first learned it. The possible values are:

  • 0IGP: the route came from an IGP interior to the originating AS.

  • 1EGP: the route came from an EGP other than BGP.

  • 2Incomplete: any other method.


AS_PATHWell known, Mandatory

The AS_PATH is a list of ASNs, which show the path taken to reach the destination network. There are actually two types of AS_PATHs. An AS_SEQUENCE describes the literal path taken to reach the destination, while an AS_SET is an unordered list of ASNs along the path. Each time a BGP router passes a route update to an eBGP peer, it updates the AS_PATH variable to include its own ASN.


NEXT_HOPWell known, Mandatory

This attribute carries the IP address of the first BGP router along the path to the destination network. When the router installs the route for the associated prefix in its routing table, it will use this attribute for the next hop router. This is where the router will forward its packets for this destination network.

By default, the NEXT_HOP router will be the router that announced this route to the AS. For routes learned from an external AS via eBGP, the NEXT_HOP router will be the first router in the neighboring AS. This information is passed intact throughout the AS by using iBGP, so all routers in the AS see the same NEXT_HOP router.


MULTI_EXIT_DISCOptional, Nontransitive

The Multiple Exit Discriminatory (MED) option is also often called the BGP Metric. Because this 32-bit value is non-transitive, it is only propagated to adjacent ASs. Routers can use the MED to help differentiate between two or more equivalent paths between these ASs.


LOCAL_PREFWell known, Discretionary

BGP only distributes Local Preference information with routes inside of an AS. Routers can use this number to allow the network to favor a particular exit point to reach a destination network. This information is not included with eBGP route updates.


ATOMIC_AGGREGATEWell known, Discretionary

When a BGP router aggregates several route prefixes to simplify the routing tables that it passes to its peers, it usually sets the ATOMIC_AGGREGATE attribute to indicate that some information has been lost. It doesn't set this attribute, however, in cases in which it uses an AS_SET in its AS_PATH to show the ASNs of all of the different prefixes being summarized.


AGGREGATOROptional, Transitive

The AGGREGATOR attribute indicates that a router has summarized a range of prefixes. The router doing the route aggregation can include this attribute, which will include its own ASN and IP address or Router ID.


COMMUNITYOptional, Transitive

A COMMUNITY is a logical grouping of networks. This attribute is defined in RFC 1997, and RFC 1998 describes a useful application of the concept to ISP networks.


MP_REACH_NLRIOptional, Nontransitive

This attribute carries information about reachable multiprotocol destinations and next-hop routers. Multiprotocol in this context could refer to any foreign protocol, such as IPv6, although it is most commonly used with IP multicast, as we will discuss in Chapter 23. Multiprotocol Label Switching (MPLS) also uses MBGP for per-VPN routing tables.

Carrying foreign routing information this way ensures backward compatibility. Routers that don't support the extension can easily interoperate with routers that do.


MP_UNREACH_NLRIOptional, Nontransitive

The MP_UNREACH_NLRI attribute is similar to the MP_REACH_NLRI, except that it carries information about unreachable multiprotocol destinations.

BGP has several other optional attributes as well, although we will not discuss them in this book. For more information, we suggest referring to Internet Routing Architectures by Sam Halabi and Danny McPherson (Cisco Press).

Route Selection

Unlike the various interior routing protocols that we discussed in the preceding chapters, BGP doesn't support multipath routing by default. So if there are two or more paths to a destination, BGP will go to great extremes to ensure that only one of them is actually used.

BGP decides which route to use by applying a series of tests in order. It is important to understand these tests and the order that the router looks at them, particularly when you are trying to influence which routes are used. Otherwise you might end up wasting a lot of time trying to adjust your routing tables by using one method, while the router is making the actual decision at some earlier step, and never seeing your adjustments.

Note that at each step, there may be several routes to the same destination prefix that all meet the requirement, or are equal after a particular test. In that case, BGP will proceed to the next test to attempt to break the tie.

We should point out that these are the route selection rules on Cisco routers. Several of these rules are not part of the BGP specification. So for nonCisco equipment, you should consult the vendor's BGP documentation to see what the differences are.

  1. The first test is whether the next hop router is accessible. By default, routers do not update the next-hop attribute when exchanging routes by iBGP. So it is possible to receive a route whose next hop router is actually several hops away, and perhaps unreachable. BGP will not pass these routes to the main routing table, but it will keep them in its own route database.

  2. If synchronization is enabled, the router will ignore any iBGP routes that are not synchronized.

  3. The third test uses the Cisco proprietary weight parameter, selecting the route with the largest weight value. This parameter is not part of the routing protocol. Adjusting the weight of a particular route on a router will only affect route selection on this router. It is a purely local concept. The default weight value is zero, except for locally sourced routes, which get a default weight of 32,768. The maximum possible weight is 65,535.

  4. If the weights are the same, BGP then selects the route with the highest Local Preference value, from the LOCAL_PREF attribute. Routers only include this attribute when communicating within an AS (iBGP). For external routes, the router that receives a particular route via eBGP sets the Local Preference value. For internal routes, it is set by the router that introduced the route into BGP. This allows you to force every router in your AS to preferentially send traffic for a particular destination through a particular eBGP link.

  5. Next, the router looks to see if any of the equivalent routes were originated locally on this router by either a network or an aggregate command, with those originated locally by a network command being preferred.

  6. If two or more routes to the same destination network are still equal, the router moves on to look at the AS_PATH. This is the path vector that gives BGP its essential character. It is a set of AS numbers that describes the path to the destination network.

  7. A BGP router will prefer any routes that originate inside its own AS.

  8. For routes that originate outside of the AS, BGP will prefer the one with the shortest path (i.e., the one with the fewest ASNs). This is a simple indication of the most direct path.

  9. BGP then looks at the ORIGIN attribute if the AS Path lengths are the same, and selects IGP routes in preference to EGP, and EGP in preference to INCOMPLETE routes. An INCOMPLETE route is one that is injected into BGP via redistribution, so BGP isn't able to vouch for its validity.

  10. The next test looks at the Multiple Exit Discriminator (MED) and selects route with the lowest value. The MED is only used if both routes are received from the same AS, or if the command bgp always-compare-med has been enabled. With this command enabled, BGP will compare MED values even if they come from different ASs, although to reach this step the AS_PATHs must have the same length. Note that if you use this command at all, you should use it throughout the AS or you risk creating routing loops. MED values are only propagated to adjacent ASs, so routers that are further downstream don't see them at all.

  11. BGP will prefer eBGP to iBGP paths. This helps to eliminate loops by ensuring that the route selected is the one that leads out of the AS most directly. Note that the iBGP routes don't include internal routes that are sourced from within your AS because they are selected at step number 5 above. So this test looks only at routes to external destinations.

  12. The next test compares the IGP costs of the paths to the next hop routers and selects the closest one. This helps to ensure that faster links and shorter paths are used when possible.

  13. Next, BGP will look at the ages of the routes and use the oldest route to a particular destination. This is an indication of stability. If two routes are otherwise equivalent, it is best to use the one that appears to be the most stable.

  14. And finally, if the routes are still equivalent, BGP resorts to the router IDs of the next hop routers to break any ties, selecting the next hop router with the lowest router ID. Since router IDs are unique, this is guaranteed to eliminate any remaining duplicate route problems.

Note that there are subtle variations to these rules for special situations such as AS Confederations, and many individual rules can be disabled if you want the router to skip them.

Cisco has also implemented a BGP Multipath option that changes this route selection process somewhat. If you enable multiple path support, BGP will still perform the first seven tests, evaluating everything up to and including the MED values. But if two or more routes are still equivalent at this point, the router will install some or all of them, depending on how you implement this feature. Please refer to Recipe 9.8 for a discussion of this option.