An Intuitive Look at Path Attributes
Last updated
Last updated
You have likely seen path attributes described as the following:
This was always a little confusing to me, because some path attributes didn’t seem to cleanly fit inside these four types. For example, LOCAL_PREF is a well-known discretionary attribute, because it must be recognized by a BGP speaker, but it doesn’t need to be included on every Update. However, in practice it is included on every Update sent to an iBGP peer.
The four types of path attributes are defined as such due to the Optional and Transitive flags that are included on each PA (path attribute):
The Optional flag lets a BGP speaker know whether it needs to understand this PA. The transitive flag lets a BGP speaker know whether it should keep a PA attached to the Update and pass it along to another BGP peer. If a BGP speaker doesn’t recognize an optional, transitive PA, it sets the Partial flag and passes it along.
The transitive flag seems to only be used to tell a router what to do if it doesn’t recognize an optional PA. For example, the LOCAL_PREF attribute is well-known and transitive, but you must not include it when sending an Update to an eBGP peer:
MED on the other hand is not transitive but it should be passed on from an iBGP learned route to an eBGP peer.
Getting confused yet?
When learning and trying to understand how PAs work, I suggest a different approach to classifying each PA:
Well-known/Optional
Dictates whether the BGP speaker must implement the PA
Mandatory/Discretionary for Updates sent to iBGP peers
Mandatory/Discretionary for Updates sent to eBGP peers
Transitive/Non-transitive
Disctates whether the PA can transit from one AS to another AS. For example, if AS1 advertises a route to AS2, can AS2 include the PAs in an advertisement to AS3.
All PAs are “transitive” for iBGP updates. This is because the AS should collectively agree on the route. Therefore transitive/non-transitive refers to whether the PA passes to another AS, not whether it passes to another BGP peer (which might be an iBGP peer).
ORIGIN is well-known, mandatory for both iBGP and eBGP Udates, and transitive.
This PA defines how a prefix was originated into BGP. A BGP speaker should not change the ORIGIN value. The PA is set by the router that originates the Update.
Code 0 is IGP
On Cisco routers, the prefix was injected with the network statement
Code 1 is EGP (which is no longer in use in today’s networks)
Code 2 is Unknown
On Cisco routers, the prefix was injected via redistribution
I believe this PA was loosely used for loop prevention when EGP was in place. Between two routes known via the IGP and EGP, you should select the IGP route which was “directly” injected into BGP versus the EGP-learned route that came from the separate external routing protocol.
However, these days Origin does not really serve much purpose. A prefix injected via the network statement is not really inheritently “better” than a prefix injected via a redistribution statement. In fact, I believe Juniper cosiders redistribution as code 0.
If you wanted to use Origin code for path selection purposes, there are other more intuitive ways to select paths. It is useful to understand what the purpose of the Origin code is for, but you don’t really need to worry about it these days.
AS_PATH is well-known, mandatory for both iBGP and eBGP Udates, and transitive.
This PA lists the ASs that have passed the NLRI. The AS to the furthest right of the list is the AS that originated the route, or aggregated the route, and the AS to the furthest left of the list is the neighboring AS.
A BGP speaker should only add its own AS to the left of the AS_PATH when sending an Update to an eBGP peer.
NEXT_HOP is well-known, mandatory for both iBGP and eBGP Updates, and transitive.
This PA is pretty self-explanitory: it lists the next-hop IP for the route. A BGP speaker should change this value when sending an Update to an eBGP peer. Optionally a BGP speaker can also change this value when sending an Update to an iBGP peer (using next-hop-self).
LOCAL_PREF is well-known, mandatory for iBGP Updates, prohibited for eBGP Updates, and non-trasitive. (Non-transitive means that the PA should be dropped when sending an Update to an eBGP peer).
This PA is used to signal the local AS’s preference for a route. A router should select the route with the highest local preference value as best.
By default, an eBGP learned route will have a local preference of 100. The local preference attribute is not included on the eBGP Update. Instead the router assigns the local preference value as dictated by the route-policy attached to the neighbor when inputing the prefix into its local BGP RIB table. If no route-policy exists for the neighbor, a local preference value of 100 is assigned. An iBGP route beats an eBGP learned route if the iBGP route has a higher local preference value.
Because of this, a router can set local preference for a route to a high value, signal the route to its iBGP neighbors, and the AS should collectively use that route as the best path. Local preference influences outbound traffic.
MED is optional, discretionary for both eBGP and iBGP Updates, and non-transitive.
This PA is used by an AS to signal to a neighboring AS its preferred entry point. It is a way to influence inbound traffic. This is a weak attribute because several other attributes, like LOCAL_PREF, can override this decision point. Therefore, AS_PATH prepending, or even better, communities that set LP, are frequently used to influence inbound traffic.
COMMUNITY and EXTENDED COMMUNITY are optional, discretionary for both eBGP and iBGP Updates, and transitive.
Communities are akin to route tags, which hold additional information. Communities can be up to 32 bits in value. There are a few well-known communities, included NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED. Usually carriers will define inbound route-policies which use community values in the form of <ASN>:<value>. The carrier will publish what each value means for their route-policies. For example, 3356:80 might set their local preference to 80 for that prefix. 3356:3000 might prepend 3356 to the AS_PATH three times.
Communities are not directly involved with path selection, instead they are arbritrary buckets for holding or tagging information. Extended communities can be larger, up to 48 bits, and are regularly used for VPN routes to signal the RT values.
ATOMIC_AGGREGATE is well-known, discretionary for iBGP and eBGP Updates, and transitive.
This is a unique PA because it contains no value. It’s presence simply states that the prefix has been aggregated and path information may be missing. As far as I know, this is the only PA that has a length of zero. The PA has no value itself, it is simply a tag.
When you create an aggregate prefix using the command aggregate-address, the router will by default strip all existing AS Path information. The aggregated prefix will have an empty AS path. The ATOMIC_AGGREGATE PA is added which is a tag that lets other routers know that AS path information is missing.
If you use the keyword as-set on the aggregate-address command, the existing AS paths are added as an AS_SET to the AS_PATH PA, in an unordered list. AS_PATH information is no longer missing, so the ATOMIC_AGGREGATE PA is no longer present. The AS_SET restores loop prevention.
The router with RID 10.2.3.3 in AS 65003 aggregated a route, 100.1.0.0/23, of which 65005 and 65000 had contributing routes. The router was configured with as-set, so the ATOMIC_AGGREGATE is not present. The AS paths of the contributing routes are seen in the AS_SET under the AS_PATH.
AGGREGATOR is well-known, discretionary for iBGP and eBGP Updates, and transitive.
This PA simply contains the AS and RID of the router that preformed the aggregation. It is present whether or not you use as-set. This is used as sort of tag on the Update which points to the router that created the aggregated prefix.
ORIGINATOR_ID is optional, discretionary for iBGP Updates, prohibited for eBGP Updates, and nontransitive. You could say it is required on Updates reflected from clients on a route reflector.
A route reflector adds the ORIGINATOR_ID PA to a route when reflecting it. The ORIGINATOR_ID is the RID of the router that generated the iBGP Update. If the originator receives an Update with its own RID in the ORIGINATOR_ID, it should ignore it. The purpose of this PA is for loop prevention within a single cluster.
CLUSTER_LIST is optional, discretionary for iBGP Updates, prohibited for eBGP Updates, and nontransitive. You could say it is required on Updates reflected from clients on a route reflector.
CLUSTER_LIST works like AS_PATH but inside a single AS. When a route reflector reflects a route, it appends its cluster ID to the CLUSTER_LIST. The CLUSTER_LIST therefore represents the clusters through which the route has “traveled.” A route reflector drops Updates that have its own cluster ID in the CLUSTER_LIST, thus implementing loop prevention between clusters.
By default, the CLUSTER_ID is the RID of the RR if no CLUSTER_ID is specified in the config.
