The first attribute we will look at is the AS Path. And very simply, this is the sequence of autonomous systems a route has traversed. So it's a little bit like an airline baggage tag but maybe in reverse. Normally when you check in at the airport you get a baggage tag which lists the airports that your suitcase is going to transit, and hopefully it actually matches your itinerary. With the AS Path, it actually lists the autonomous systems that this route has traversed to reach you. So it tells you where the prefix is originated, and all the intermediate autonomous systems the prefix has traversed. This is extremely useful for policy. You may have a policy, as we'll see later on, which says: "I don't want this prefix that's come through this particular autonomous system." or I may want to increase the priority if the prefix has gone through that autonomous system. Or I may want to reduce the priority and so on. You can make a lot of policy decisions based simply on the path that the prefix has taken to reach you. It's a mandatory attribute and it's transitive. So the AS must be set and it must be passed on as the prefix traverses autonomous systems on the internet. It's used for loop detection, which I'll show you next, and for applying policies in BGP, like those I've just described. And the graphic shows a group of autonomous systems connected together. AS 100, for example, is originating 180.10/16, and it's announcing that prefix through AS 200, which then passes it to 300, which then passes it to AS 400. And we take a look on a router in AS 400, We look at the 180.10/16 and we see this "300 200 100" appearing. And that's the AS Path, the list of autonomous systems the prefix has traversed. We don't see our own AS there right, we are in AS 400, we don't see that, because we've heard it from 300, which has heard it from 200, which has heard it from 100. So I've also introduced a slide showing the AS Path with a mix of 16 and 32-bit AS numbers. Now as we've already seen, internet is using 32-bit AS numbers and has been for probably last 8 or 9 years. But there's still some old network equipment being used by some network operators which do not support these newer 32-bit AS numbers. And so, what this graphic shows you is how the 32-bit AS numbers would appear in the AS Path on an old router. So we take a previous example and upgrade a couple of the AS numbers to 32-bit range. I've got AS 70000 now originating 180.10/16, and announcing that prefix to AS 80000, which then passes on to AS 300, and then we go back to our vantage point in AS 400 to see what we see. We've now got 180.10/16 with an AS Path of "300 23456 23456". As you've already learned, AS 23456 is a special autonomous system that was reserved for the transition from 16-bit to 32-bit AS numbers. So why the 23456 here? Well AS 400 routers don't support 32-bit AS numbers. And because they don't support 32-bit AS numbers they can't handle numbers bigger than 65535 for the ASN. So we have to represent them some other way. But then you probably wonder how does the router know that these are 32-bit AS numbers and to use 23456? Well the clever piece is in the transition. Assuming AS 300 is also only supporting 16-bit AS numbers, when AS 300 sets up the BGP session with its neighbor in AS 80000, what actually happens is, it's back to the capability negotiation at the start, because AS 300 can't set a BGP neighbor in 80000, because 80000 is bigger than 65535. So what the operator has to do instead, is use the transition AS, he sets up his neighbor with 23456. Now AS 80000 sets up the normal BGP peering: "bgp neighbor as300". It then gets, as it's bringing up the BGP session, it asks: "Dear neighbor do you support the extended AS numbers, the 32-bit AS range?" Of course the router in AS 300 is an old router, doesn't understand the question, and so gives a "don't understand" answer back. That way the router in AS 80000 sees that his neighbor doesn't support 32-bit AS numbers, and then sets up the BGP session to peer with AS 23456 instead. So that when the session is initiated, when AS 300 says: "Hello AS 23456", AS 80000 router actually knows to set up the BGP session with them. And because it knows that its neighbor cannot handle 32-bit AS numbers, It puts the 32-bit AS numbers in a new attribute called the AS4_PATH which stores the 32-bit AS numbers. And in the AS Path, which it sends to AS 300, it puts 23456 in instead. So by the time this AS Path gets to AS 400, we see that AS 23456 is standing in for the 32-bit AS numbers. Now it gets even more interesting if we look at AS 90000. Now AS 90000 has the 16-bit supporting router or network sitting in between. So we've removed the 32-bit numbers from the AS Path. We've created this new AS4_PATH attribute to carry 32-bit AS numbers. What happens when we get to AS 90000. Well AS 90000 has the same conversation when it talks to the routers in AS 300, it realizes ah, those ones don't understand 32-bit AS numbers. What it gets from its neighbor is a nearest path of 23456 or similar. It then takes this AS4_PATH attribute, the 32-bit AS numbers come out of that and take the place of AS 23456. So again, when we look on any other routers in AS 90000 we see 180.10/16, with AS Path 300 80000 70000, in other words that the full AS Path has been restored. So whichever vantage point we take, AS 90000 or AS 400 the AS Path length is exactly the same. Now normal operation, on routers that support 32-bit AS numbers, you should never ever see AS 23456 in the path. If you do, it's a configuration error and it's usually caused by operators who don't understand what AS 23456 is for. No network ever runs in AS 23456. It's only ever used on old routers when you're peering with routers that support 32-bit ASNs. Now, 8-9 years ago, when 32-bit AS numbers were first being deployed, this caused quite a bit of concern within the operator industry. Especially with the AS4_PATH, whether BGP implementations would actually transport this new attribute across the network. It was quite interesting we actually had deployed several 32-bit ASN speaking routers across the internet before, it was even made aware that we were doing this and they were working just fine. One thing to note about BGP is that, if there's an unknown attribute received the specification requires that this unknown attribute is passed along to the next BGP speaker. So it was quite interesting to note that almost all the BGP implementations at the time were transporting unknown attributes without any impact on the network. The final part of the AS Path is this loop detection capability. Of course the Internet is not just a long string of autonomous systems, the Internet is highly interconnected, highly meshed. What we don't want to have happen is, a prefix being originated by one autonomous system and then finding its way back to that autonomous system that originated it. You could end up with a BGP announcement loop. Where a prefix announcement ends up going round and round and round due to some error in BGP path selection or some implementation error or even just some simple policy. If you look at the diagram, AS 100 is originating 180.10/16, sending it to 200, to 300, through to 500. Now the routers in AS 500 will still announce that prefix, onwards back to AS 100 because they're connected to it. What will happen in AS 100, is that it will spot this prefix but with its own AS in the AS Path. Now of course the routers not going to know if this is a configuration error, or just a feature of how the networks are all interconnected. But what we don't want to happen is for the router to accept a prefix from outside its autonomous system that has its own autonomous system number in the path. and so the router will drop this prefix and so the actual received prefixes at AS 100 as it shows in the diagram, will just be the other two prefixes we sent on this announcement. So this is the loop detection in action, and it's very useful across the network and also has a little caveat as we'll see later on when we start looking at some of the other BGP attributes as well.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.