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
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. 
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,
seems to me that, if your questions are not clearly answered by the
bgp specs, then something is sorely broken.
randy
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
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
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
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.
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?
Since i smell some traces of sarcasm here.
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
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,
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
from time to time people say 'but the rfc says...'. but theres a big place for
precedent and common practice too.
Steve