Cisco SPCOR – The AS_PATH Attribute
It is time to dig deep into another key BGP attribute. Yes, it is another well-known, mandatory path attribute that is fundamental to the operation of BGP.
The AS_PATH attribute is a list of all of the autonomous systems that the prefix has transited on its way to your BGP table. How is this list populated? It is simple. When a router sends a prefix to another AS using eBGP, it prepends its AS in the AS_PATH attribute. Each AS does this of course. So when you read the AS_PATH, you can read it from the right to the left if you want to envision the source AS first. The leftmost AS in your AS_PATH is the last AS to have handled the prefix. Note that this is also the AS that handed the prefix to your local AS.
As you know from the last post we did on the ORIGIN attribute, the AS_PATH length is one of the key path attributes that is considered in the BGP best path selection algorithm. The shorter the AS_PATH attribute, the more preferred the path. This makes sense of course. It is like a hop count after all, but on a bigger scale potentially!
We can use the AS_PATH to influence inbound traffic to our AS. For example, we might poison a path by prepending our own AS number multiple times to the AS_PATH. This makes the attribute longer and less preferred. Notice that prepending our own AS number, this will not negatively impact the loop prevention mechanism that AS_PATH provides. It does not matter to the loop prevention if our AS number is there once, or twice, or three times, or more!
There is actually two types of AS_PATH attributes that can be communicated. This is controlled with a type code for the AS_PATH attribute.
The two types of AS_PATH presentation are:
- AS_SEQUENCE – this is the list of AS path numbers like I have described in this post
- AS_SET – this is an unordered list of all the AS numbers that have handled the prefix
The AS_SET method includes AS numbers for systems that are behind the aggregation that might have taken place with the prefix. While this might sound like a great idea from a loop prevention standpoint, it is NOT a great idea from a stability perspective. We do not want there to be updates to the AS_PATH every time there is a change of the AS reachability behind the aggregation point. This defeats one of the main advantages to aggreagation.
There is more and more support for dropping of the AS_SET feature completely. You will certainly see it very rarely in production today.
