Lesser-known BGP path attributes

The past few weeks we’ve discussed the main BGP path attributes: the next hop, the AS path, the MED. We also covered the community attribute last year.
Today, we’re going to look at some of the lesser-known attributes.
The Internet Assigned Numbers Authority (IANA) has given out codes for 24 attributes in addition to the seven defined in the BGP specification. Seven of the 24 additional attributes have since been declared “deprecated” and should no longer be used.

The seven attributes specified in RFC 4271 are:

ORIGIN AS_PATH NEXT_HOP MULTI_EXIT_DISC LOCAL_PREF ATOMIC_AGGREGATE AGGREGATOR

Origin

The origin attribute indicates the origin of a prefix and can take three values: the prefix originates from an interior routing protocol (IGP), it originates from EGP, the predecessor to BGP, or the origin is “incomplete”, if the prefix is learned through “other means”. On Cisco routers, the origin is set to “i” (IGP) if a route is injected into BGP using a network statement and to “?” (incomplete) if static or connected routes or routes from another routing protocol are redistributed in BGP. An i, e or ? is shown to the right of the AS path in show ip bgp output.

Presumably, the origin attribute provided a function when transitioning from EGP to BGP, but these days it doesn’t really serve a purpose anymore, but the BGP specification mandates including it. And the origin attribute is still considered in the BGP route selection algorithm, so it can be used for traffic engineering. Only the routes with the lowest origin value (where IGP < EGP < incomplete) are considered when multiple routes share the shortest AS path, before the algorithm continues with considering the MED.

As a result, it’s possible to set the origin to EGP or incomplete in order to make it less preferred than a route with the usual IGP origin:

 

Atomic aggregate and aggregator

The big new feature in BGP-4 was CIDR: classless inter-domain routing. A network that had, for example, 16 class C networks could now announce those as a single /20 prefix in BGP rather than as 16 individual class C announcements. To help with the transition towards CIDR, routers could be configured to aggregate several longer prefixes into a shorter one. The ATOMIC_AGGREGATE and AGGREGATOR attributes may then be added. The rules for aggregating prefixes by a network other than the origin of those prefixes are somewhat complex, and it’s unclear how well this worked. The practice is now obsolete. Still, when adding the 32-bit AS capability, in addition to the new AS4_PATH a new AS4_AGGREGATOR attribute was also added.

Route reflectors and confederations

An important limitation of BGP is that all the BGP routers in an AS must speak iBGP with all other BGP routers in the AS: the full mesh requirement. That way, each router learns new information directly from the router where that information enters the AS and loops are impossible. The downside is that when a network with 100 routers gets router 101, not only does router 101 need to be configured with 100 iBGP sessions towards the existing routers, but also all existing routers must be configured with a session towards the new router. There are two mechanisms that solve this: route reflectors and confederations.

With confederations (RFC 5065), a large AS is split into sub-ASes, where the rules for sessions between sub-ASes hold middle ground between the rules for eBGP and iBGP, and the full mesh requirement only applies within a sub-AS. The confederation mechanism doesn’t introduce any new path attributes. Confederations are currently not widely used.

Route reflectors (RFC 4456) also get rid of the full mesh requirement. When a router is made a route reflector, it will “reflect” routes between other routers that are its clients. Route reflectors exhibit regular iBGP behavior, including the full mesh requirement, towards each other and non-client peers. It is possible to have a hierarchy of route reflectors, where the lower level route reflectors are clients of the higher level route reflectors. It’s also best practice for a client to communicate with at least two route reflectors for redundancy. In this situation, it would be easy to make a configuration mistake that allows routing loops to form, so route reflectors add two attributes to reflected routes.

The ORIGINATOR_ID attribute contains the BGP identifier of the router that originated the route. So when a route comes back to the router that originated it, that router can reject the route in question.

The CLUSTER_LIST attribute contains all the CLUSTER_IDs of the clusters that a route has propagated through, so a route reflector can determine that a route is looping when it sees the CLUSTER_ID for the cluster it belongs to. In the case of a single route reflector, the CLUSTER_ID is simply the reflector’s BGP identifier, but when multiple route reflectors are deployed for redundancy, they can be configured with the same CLUSTER_ID to reject loops more efficiently.

Multiprotocol extensions

The first BGP specification was published in 1989, well before IPv6 was created and only shortly after multicast was added to IPv4. Even BGP-4 doesn’t support IPv6, multicast or VPNs. Until 1998, that is, when RFC 2283 introduced the multiprotocol extensions. These allow BGP to handle routing information for arbitrary “address families”. In practice, an address family is associated with a specific network layer protocol, such as IPv4, IPv6, IPX or AppleTalk. There are also Address Family Identifier (AFI) numbers for tunneling mechanisms such as VPNs and MPLS. A Subsequent Address Family Identifier (SAFI) further specifies unicast versus multicast or more tunneling options.

When routers make a BGP connection, they exchange the AFIs and SAFIs they’re prepared to exchange routing information for. If the two routers agree on those, they’ll send UPDATE messages containing the regular path attributes with the prefixes (also known as Network Layer Reachability Information, NLRI) and next hops encoded in an MP_REACH_NLRI attribute. Withdrawn routes are encoded in an MP_UNREACH_NLRI attribute.

Most other attributes on the IANA list are not in general use, with the exception of the extended community attribute. The regular community attribute is rather limited at 32 bits; extended communities allow for much more information to be encoded in more meaningful ways. The downside of that extra flexibility is that this makes using them a good deal more complex, so they’re much less common than regular communities.