Order of ASes in the BGP Path
Hi, Is the order of AS numbers (except for perhaps the first one which denotes the AS the route was originated from) in the AS_PATH in BGP important? In fact, does anybody even care for the first AS number that appears in the Path? AFAIK, AS numbers in the BGP serves two purposes. It helps in loop detection and it helps us count the AS Path length. If this is the case then the order should not really matter much. My question is that whether the operators care if the order, for some reason changes? Eg. Legend: {} denotes the sequence, while [] denotes the set Path {1 2} [3 4] {5} Would somebody mind if this was represented as {1 2 5} [3 4] ? Thanks, Abhishek
On Mon, Aug 29, 2005 at 10:15:26PM +0530, Abhishek Verma wrote:
Hi,
Is the order of AS numbers (except for perhaps the first one which denotes the AS the route was originated from) in the AS_PATH in BGP important? In fact, does anybody even care for the first AS number that appears in the Path?
AFAIK, AS numbers in the BGP serves two purposes. It helps in loop detection and it helps us count the AS Path length.
If this is the case then the order should not really matter much.
My question is that whether the operators care if the order, for some reason changes?
Just that pesky little thing called sanity, aka having a hope in hell of being able to figure out which network is connected to which and in what order. While it is technially possible to run everything with an unordered AS-PATH set, it is so rare that "most" people looking at AS-PATHs either don't know it is possible, or don't take its possibility into account properly. Besides being likely to confuse the hell out of a lot of people, you're even more likely to break someone's BGP querying perl scripts. I wouldn't underestimate the amount of that stuff out there either, especially in areas like abuse tracking/reporting. Basically you'd be making a general pain in the ass out of yourself, so hopefully you have a damn good reason for it. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
I thank everyone who took time off their busy schedules and answered me on this. I now understand that people do look at the AS_PATH and the order of ASes is important for debugging, etc. Regards, Abhishek On 8/29/05, Richard A Steenbergen <ras@e-gerbil.net> wrote:
On Mon, Aug 29, 2005 at 10:15:26PM +0530, Abhishek Verma wrote:
Hi,
Is the order of AS numbers (except for perhaps the first one which denotes the AS the route was originated from) in the AS_PATH in BGP important? In fact, does anybody even care for the first AS number that appears in the Path?
AFAIK, AS numbers in the BGP serves two purposes. It helps in loop detection and it helps us count the AS Path length.
If this is the case then the order should not really matter much.
My question is that whether the operators care if the order, for some reason changes?
Just that pesky little thing called sanity, aka having a hope in hell of being able to figure out which network is connected to which and in what order. While it is technially possible to run everything with an unordered AS-PATH set, it is so rare that "most" people looking at AS-PATHs either don't know it is possible, or don't take its possibility into account properly.
Besides being likely to confuse the hell out of a lot of people, you're even more likely to break someone's BGP querying perl scripts. I wouldn't underestimate the amount of that stuff out there either, especially in areas like abuse tracking/reporting. Basically you'd be making a general pain in the ass out of yourself, so hopefully you have a damn good reason for it. :)
-- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
-- -- Computer Science Deptt. Institute of Technology, BHU Varanasi - India
Since i smell some traces of sarcasm here. On 8/30/05, Randy Bush <randy@psg.com> wrote:
I thank everyone who took time off their busy schedules and answered me on this. I now understand that people do look at the AS_PATH and the order of ASes is important for debugging, etc.
and thank you for reading the rfc
Randy, I respect your knowledge and wisdom and that of other people on this list here which is why i asked this question. Yes, i have gone through the RFC 1771 throughly and trust me it does not mention any other use of this Path attribute, except for the path length/loop detection. People on this list have a *lot* of experience and its these people who actually use this protocol. To me these were the best people to tell me if they indeed use it for other purposes also. Thanks, Abhishek randy
-- -- Computer Science Deptt. Institute of Technology, BHU Varanasi - India
On Tue, 30 Aug 2005, Abhishek Verma wrote:
Since i smell some traces of sarcasm here.
On 8/30/05, Randy Bush <randy@psg.com> wrote:
I thank everyone who took time off their busy schedules and answered me on this. I now understand that people do look at the AS_PATH and the order of ASes is important for debugging, etc.
and thank you for reading the rfc
Randy, I respect your knowledge and wisdom and that of other people on this list here which is why i asked this question. Yes, i have gone through the RFC 1771 throughly and trust me it does not mention any other use of this Path attribute, except for the path length/loop detection. People on this list have a *lot* of experience and its these people who actually use this protocol. To me these were the best people to tell me if they indeed use it for other purposes also.
from time to time people say 'but the rfc says...'. but theres a big place for precedent and common practice too. Steve
### On Tue, 30 Aug 2005 11:02:18 +0100 (BST), "Stephen J. Wilcox" ### <steve@telecomplete.co.uk> casually decided to expound upon Abhishek ### Verma <abhishekv.verma@gmail.com> the following thoughts about "Re: ### Order of ASes in the BGP Path": SJW> from time to time people say 'but the rfc says...'. but theres a big SJW> place for precedent and common practice too. True... but the latest BGP draft series attempts to address BCP and updates on 1771. Typically, the answers sought in light of current BGP practices can be found in the draft. -- /*===================[ Jake Khuon <khuon@NEEBU.Net> ]======================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=========================================================================*/
Does anyone know anything about supposed bellsouth.net outages in Southeast Florida and what it affects? I can't bring up the local link on PPPoE and they're not wanting to test or anything because of outages. I'm sending PADI active discovery initiates and getting no response. Usually when this happens, about yearly, they just come out and reset or replace a card in a Mini-Ram/Dslam right down the street. --- Alan Spicer (a_spicer@bellsouth.net) http://telecom.dyndns.biz/ +1 954 977 5245 +1 954 683 3426
On Tue, 30 Aug 2005, Alan Spicer wrote:
Does anyone know anything about supposed bellsouth.net outages in Southeast Florida and what it affects? I can't bring up the local link on PPPoE and they're not wanting to test or anything because of outages. I'm sending PADI active discovery initiates and getting no response. Usually when this happens, about yearly, they just come out and reset or replace a card in a Mini-Ram/Dslam right down the street.
If by Southeast FL, you mean the Miami area, Bell does have many remote terminal outages. They seem to have gotten dial tone restored in areas where DSL has not and apparently won't be for some time. If you're an ISP with DSL customers on BellSouth DSLAM provided DSL, you should be able to check on this by calling the DSG. Incidentally, I found yesterday that the DSG's toll free number is not reachable from Gainesville, FL. Initially, I thought it might be a problem with the PRI our office phone system uses, but I found my home phone could not get through either...(2 rings, then all circuits busy). My Cingular wireless phone (with a Gainesville local number) can get through, and utilizing our VOIP network, if I force the call to go out through a PRI in a city other than Gainesville, it also goes through. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Mon, 29 Aug 2005, Abhishek Verma wrote:
Legend: {} denotes the sequence, while [] denotes the set
Path {1 2} [3 4] {5}
Would somebody mind if this was represented as {1 2 5} [3 4] ?
Yes, they are different paths. You are allowed to merge adjacent sequences, eg: {1 2} {5} [3 4] the two sequences can be merged, to give: {1 2 5} [3 4] You can *not* merge AS_SET's, as the current BGP specs imply an AS_SET has a fixed path-length, hence you should NOT merge the sets in: {1 2} [3 4] [5 6] into: {1 2} [3 4 5 6] as the former path has a length of 3, the latter a length of just 2 - merging sets could change their meaning. Note though that you're not at all likely to see such paths with BGP speakers implementing the RFC / draft-ietf-idr-bgp-26.txt draft. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: The best way to make a fire with two sticks is to make sure one of them is a match. -- Will Rogers
seems to me that, if your questions are not clearly answered by the bgp specs, then something is sorely broken. randy
You can *not* merge AS_SET's, as the current BGP specs imply an AS_SET has a fixed path-length, hence you should NOT merge the sets in:
{1 2} [3 4] [5 6]
into:
{1 2} [3 4 5 6]
as the former path has a length of 3, the latter a length of just 2 - merging sets could change their meaning. Note though that you're not at all likely to see such paths with BGP speakers implementing the RFC / draft-ietf-idr-bgp-26.txt draft.
This is one thing that i have always been aware of but dont see it mentioned in the BGP draft which can be quite confusing to the newbies. Is it possible to explicitly mention this in draft-ietf-idr-bgp-26.txt? Toms.
On Tue, 30 Aug 2005, Tom Sanders wrote:
This is one thing that i have always been aware of but dont see it mentioned in the BGP draft which can be quite confusing to the newbies. Is it possible to explicitly mention this in draft-ietf-idr-bgp-26.txt?
Impossible given draft-ietf-idr-bgp4-26 is in the RFC Editor Queue. However, the IDR have a working document to update the definition of AS_PATH, draft-ietf-idr-as4bytes-10, so might feasible to have clarifying text put in. Ask on IDR. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Fanaticism consists of redoubling your effort when you have forgotten your aim. -- George Santayana
In message <ce8d9033050829094562f3dc2e@mail.gmail.com>, Abhishek Verma writes:
Hi,
Is the order of AS numbers (except for perhaps the first one which denotes the AS the route was originated from) in the AS_PATH in BGP important? In fact, does anybody even care for the first AS number that appears in the Path?
AFAIK, AS numbers in the BGP serves two purposes. It helps in loop detection and it helps us count the AS Path length.
If this is the case then the order should not really matter much.
My question is that whether the operators care if the order, for some reason changes?
Eg.
Legend: {} denotes the sequence, while [] denotes the set
Path {1 2} [3 4] {5}
Would somebody mind if this was represented as {1 2 5} [3 4] ?
Any of the proposed BGP security schemes would have trouble with reordering. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Mon, 29 Aug 2005, Abhishek Verma wrote:
Hi,
Is the order of AS numbers (except for perhaps the first one which denotes the AS the route was originated from) in the AS_PATH in BGP important? In fact, does anybody even care for the first AS number that appears in the Path?
AFAIK, AS numbers in the BGP serves two purposes. It helps in loop detection and it helps us count the AS Path length.
If this is the case then the order should not really matter much.
My question is that whether the operators care if the order, for some reason changes?
Eg.
Legend: {} denotes the sequence, while [] denotes the set
Path {1 2} [3 4] {5}
Would somebody mind if this was represented as {1 2 5} [3 4] ?
I'd mind, I value the predictability and ability to understand how a bgp path arrives into my network. Fiddling with this kind of thing is quite similar to spoofing in some ways, particularly that I can see fabricating the as-path could be used to confuse folks tracing announcements, perhaps I'm missing the positive use for this. As no one has asked yet, allow me.. what are you trying to do? Steve
As no one has asked yet, allow me.. what are you trying to do?
Basically I was thinking on these lines. If i have an AS path {1 2} [3 4] { 5 } then is it possible to pull the AS in the last segment and merge it with the first segment? This would give me {1 2 5} [3 4]. This way i dont need to carry two AS_SEQ segments in my path and i can manage with just one. However, there are some problems here: [1] I can never generate such an AS Path, given the way BGP works currently. [2] Merging ASes from different segments can mangle the sequence in which the ASes appear in the AS Path. I wanted to know if this was required and used by admins, and hence my original mail. Thanks everybody for all the help, Abhishek
On Mon, 29 Aug 2005, Abhishek Verma wrote:
Legend: {} denotes the sequence, while [] denotes the set
Path {1 2} [3 4] {5}
Would somebody mind if this was represented as {1 2 5} [3 4] ?
I see it as a bad idea for bgp table / routing analysis as it completely confuses who is #5 really peering with. But at this time, I'd like to see you actually provide justification as it applies to your case for why you would want to change bgp route for routes coming from #5 in the first place? -- William Leibzon Elan Networks william@elan.net
participants (11)
-
Abhishek Verma -
Alan Spicer -
Jake Khuon -
Jon Lewis -
Paul Jakma -
Randy Bush -
Richard A Steenbergen -
Stephen J. Wilcox -
Steven M. Bellovin -
Tom Sanders -
william(at)elan.net