Heads up: Long AS-sets announced in the next few days
Hi, as announced to the RIPE routing working group mailing list [1] and elsewhere, over the next few days the Computer Networks research group at Roma Tre University, in collaboration with the RIPE NCC RIS project, will be performing experiments involving announcements with large AS-sets in the AS-path. We are doing this to test innovative network discovery methodologies we developed to allow ISPs to determine how their prefixes are seen by the rest of the Internet. The announcements will be for prefixes 84.205.73.0/24 and 84.205.89.0/24 and will originate in AS12654. We have been performing similar experiments over IPv6, in collaboration with the NAMEX internet exchange, since December 2004 with no ill effects; furthermore, our announcements are standard BGP, so conformant implementations should be able to process them, and very long AS-sets have already been observed in the past (e.g. [2], [3]). However, we want to be careful to avoid router bugs on legacy devices, old firmware versions and the like, so we are first sending out test announcements with progressively longer AS-sets. Should you encounter a problem with these advertisements, please let us know and we will withdraw them. The proposed timetable of the test announcements is as follows. 2005-03-04: 14:00 UTC: 10-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 25-element AS-set 16:30 UTC: withdrawal and, if there are no problems: 2005-03-07: 14:00 UTC: 50-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 100-element AS-set 16:30 UTC: withdrawal Note: For reference, the AS-sets already observed in [2] and [3] contained 123 and 124 ASes respectively. For questions/comments, please contact compunet@dia.uniroma3.it or lorenzo@ripe.net. Regards, Lorenzo Colitti On behalf of the Roma Tre Computer Networks Research group [1] http://www.ripe.net/ripe/maillists/archives/routing-wg/2005/msg00021.html [2] http://www.ripe.net/projects/ris/Talks/0101_RIPE38_AA/sld003.html [3] http://www.ripe.net/maillists/ncc-archives/ris-users/2002/msg00044.html
Hi, On Tue, Mar 01, 2005 at 07:49:50PM +0100, Lorenzo Colitti wrote:
The proposed timetable of the test announcements is as follows.
2005-03-04: 14:00 UTC: 10-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 25-element AS-set 16:30 UTC: withdrawal
Please do not announce AS-sets that contain 5539. We are not part of your experiment, and we don't want to see our AS appear in other people's router error messages. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Gert Doering wrote:
2005-03-04: 14:00 UTC: 10-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 25-element AS-set 16:30 UTC: withdrawal
Please do not announce AS-sets that contain 5539. We are not part of your experiment, and we don't want to see our AS appear in other people's router error messages.
Ok, no problem: we will not include AS 5539 in any of the AS-sets we announce. Regards, Lorenzo
This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use. In which case please keep AS8330, AS8550, and AS8943 out of your experiments too. Using not yet allocated ASns out of RIPEs asn-blocks would have been more sensible, IMHO. Regards James On Wed, 2 Mar 2005, Lorenzo Colitti wrote:
Gert Doering wrote:
2005-03-04: 14:00 UTC: 10-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 25-element AS-set 16:30 UTC: withdrawal
Please do not announce AS-sets that contain 5539. We are not part of your experiment, and we don't want to see our AS appear in other people's router error messages.
Ok, no problem: we will not include AS 5539 in any of the AS-sets we announce.
Regards, Lorenzo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-02, at 19.38, James A. T. Rice wrote:
This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use.
Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiYNZ6arNKXTPFCVEQL/sgCdHCBV87HM9jIgNATJhpW5aON/1TwAniAR i1p06marP5ra05ey9YcxX90f =W+rc -----END PGP SIGNATURE-----
On 2005-03-02, at 19.38, James A. T. Rice wrote:
This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use.
Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs?
Isn't this a case of illustrating how easy it is to tell lies in BGP today? I don't see what hitting the RIRs has do to with this. The problem appears to be more basic than that - its just too easy to tell lies in BGP and get the lies propagated globally. Geoff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-03, at 10.27, Geoff Huston wrote:
On 2005-03-02, at 19.38, James A. T. Rice wrote:
This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use.
Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs?
Isn't this a case of illustrating how easy it is to tell lies in BGP today? I don't see what hitting the RIRs has do to with this. The problem appears to be more basic than that - its just too easy to tell lies in BGP and get the lies propagated globally.
Well agreed. And that is an important point in itself. The reference to the RIRs was me trying to be ironic as when we have prefix hijacks that seems to be reported to the RIRs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQibejKarNKXTPFCVEQKO6ACeIzkX5j04JA3RK3Y48fSsXM0DMLEAoM+k 6+j6phNoiKSg5Qai2CNSloLa =TWvV -----END PGP SIGNATURE-----
On Thu, 2005-03-03 at 20:27 +1100, Geoff Huston wrote:
On 2005-03-02, at 19.38, James A. T. Rice wrote:
This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use.
Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs?
Isn't this a case of illustrating how easy it is to tell lies in BGP today? I don't see what hitting the RIRs has do to with this. The problem appears to be more basic than that - its just too easy to tell lies in BGP and get the lies propagated globally.
I am probably telling you what you already know, but for the ones who don't know it yet: Secure BGP (S-BGP): http://www.ir.bbn.com/projects/s-bgp/ http://www.nanog.org/mtg-0306/pdf/bellovinsbgp.pdf http://www.nwfusion.com/details/6484.html?def and of course the sister by amongst others Cisco: Secure Origin BGP (SO-BGP): http://bgp.potaroo.net/ietf/idref/ draft-ng-sobgp-bgp-extensions/ http://www.nwfusion.com/details/6485.html http://www.nanog.org/mtg-0306/pdf/alvaro.pdf etc... most people know how to google I guess ;) Aka BGP with certificates and other nice tricks. Greets, Jeroen
At 04:02 AM 4/03/2005, Jeroen Massar wrote:
On Thu, 2005-03-03 at 20:27 +1100, Geoff Huston wrote:
On 2005-03-02, at 19.38, James A. T. Rice wrote:
This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use.
Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs?
Isn't this a case of illustrating how easy it is to tell lies in BGP today? I don't see what hitting the RIRs has do to with this. The problem appears to be more basic than that - its just too easy to tell lies in BGP and get the lies propagated globally.
I am probably telling you what you already know, but for the ones who don't know it yet:
Secure BGP (S-BGP): http://www.ir.bbn.com/projects/s-bgp/ http://www.nanog.org/mtg-0306/pdf/bellovinsbgp.pdf http://www.nwfusion.com/details/6484.html?def
and of course the sister by amongst others Cisco:
Secure Origin BGP (SO-BGP): http://bgp.potaroo.net/ietf/idref/ draft-ng-sobgp-bgp-extensions/ http://www.nwfusion.com/details/6485.html http://www.nanog.org/mtg-0306/pdf/alvaro.pdf
precisely - I think we've now managed to reach a common understanding that looking for "lies" in BGP is a difficult and expensive task and more often than not the "lies" get through anyway. The approaches above clearly flag what is intended to be "truth", with the inference that what is not clearly traceable back to originating attestations is a potential lie. We really should be moving in this direction now! Geoff
I am probably telling you what you already know, but for the ones who don't know it yet:
Secure BGP (S-BGP): http://www.ir.bbn.com/projects/s-bgp/ http://www.nanog.org/mtg-0306/pdf/bellovinsbgp.pdf http://www.nwfusion.com/details/6484.html?def
and of course the sister by amongst others Cisco:
Secure Origin BGP (SO-BGP): http://bgp.potaroo.net/ietf/idref/ draft-ng-sobgp-bgp-extensions/ http://www.nwfusion.com/details/6485.html http://www.nanog.org/mtg-0306/pdf/alvaro.pdf
etc... most people know how to google I guess ;)
Aka BGP with certificates and other nice tricks.
And, of course, the RPSEC working group draft that is supposed to target the BGP requirements for those proposed systems is... http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-01.txt The folks who worked on S-BGP and SO-BGP participated in it's creation (as well as several operators). Please note that there are more than just two proposed mechanisms for securing BGP. The two mentioned above are just the most popular <grin>.
On Thu, 2005-03-03 at 13:51 -0500, Blaine Christian wrote:
And, of course, the RPSEC working group draft that is supposed to target the BGP requirements for those proposed systems is...
http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-01.txt
The folks who worked on S-BGP and SO-BGP participated in it's creation (as well as several operators). Please note that there are more than just two proposed mechanisms for securing BGP. The two mentioned above are just the most popular <grin>.
Thanks for the new reading material, I had not seen that one yet... *print* will be a nice read (hmmm, actually I should swear at you for even more reading material, for which I have no time, oh well :) Greets, Jeroen
James A. T. Rice wrote:
This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use.
In which case please keep AS8330, AS8550, and AS8943 out of your experiments too.
Using not yet allocated ASns out of RIPEs asn-blocks would have been more sensible, IMHO.
James, we are not picking ASes at random. The AS-set announcements are part of new techniques we are developing for ISPs who wish to discover how their prefixes are seen by the rest of the Internet. We believe this will come to be a useful tool for operators. However, since this is still work in progress, and in scientific research there is no room for second place, I can't really reveal any more than that at the moment. I would like to point out, though, that our research group does have a proven track record in the field network discovery (examples available on request), and has created software useful to the operator community such as BGPlay [1][2]. That said, if you want us to exclude those ASes from our AS-sets, then we will do so. Regards, Lorenzo [1] http://www.ris.ripe.net/bgplay/ [2] http://bgplay.routeviews.org/bgplay/
we are not picking ASes at random. The AS-set announcements are part of new techniques we are developing for ISPs who wish to discover how their prefixes are seen by the rest of the Internet. We believe this will come to be a useful tool for operators.
However, since this is still work in progress, and in scientific research there is no room for second place, I can't really reveal any more than that at the moment.
I would like to point out, though, that our research group does have a proven track record in the field network discovery (examples available on request), and has created software useful to the operator community such as BGPlay [1][2].
That said, if you want us to exclude those ASes from our AS-sets, then we will do so.
So, the ASn's are not picked at random, yet mine might be included if I don't specifically ask for them not to be included, yet you decline to tell how my ASn might have been selected for this. So, yes, please do keep my ASns out of this cloak and dagger research. I would have thought it prudent to seek permission from the particular ASn operators before even considering using them for this experiment. Regards James PS, curious if AS7007 is part of your set of selected ASns, however they may have been selected.
James A. T. Rice wrote:
So, the ASn's are not picked at random, yet mine might be included if I don't specifically ask for them not to be included, yet you decline to tell how my ASn might have been selected for this.
Ok, I realize I might have given the wrong impression here. Sorry. So here's what we are doing: by artificially inserting ASes into the AS-set of an announcement, the ISP that makes the announcement can control where the announcement is propagated and thus discover paths followed by its announcements that are not usually visible, giving it a more complete knowledge of network topology in the vicinity. Since this is a new technique, it's not clear if it is actually effective, and to measure this we need to test it in the real world. If the experiments show that the technique performs as we hope, we intend to publish the results and provide the details for public use. We will post appropriate references to this list as soon as we have some hard data and have put it into a presentable form. But first we need to do the experiments... Regards, Lorenzo
On Thu, 3 Mar 2005, Lorenzo Colitti wrote:
Ok, I realize I might have given the wrong impression here. Sorry.
So here's what we are doing: by artificially inserting ASes into the AS-set of an announcement, the ISP that makes the announcement can control where the announcement is propagated and thus discover paths followed by its announcements that are not usually visible, giving it a more complete knowledge of network topology in the vicinity.
Since this is a new technique, it's not clear if it is actually effective, and to measure this we need to test it in the real world. If the experiments show that the technique performs as we hope, we intend to publish the results and provide the details for public use.
We will post appropriate references to this list as soon as we have some hard data and have put it into a presentable form. But first we need to do the experiments...
Hi Lorenzo, Its a basic design function to keep the net loop free, of BGP to not accept a route with the routers own ASn in the path from an external peer. You appear to be trying to take advantage of a side effect of this behaviour, in order to see what other ASn transitive adjacancies are available that would not normally be used, by inserting the ASns of transit AS's that would normally be used, into the as path you are announcing. I'm sure this was never an intended use for BGP as paths (or as sets, but that could be confused with the as-set object in the ripe database, which is something different, so i'll say as-paths). More to the point, you are breaking a very fundemenatal convention and expectation that if you see a given ASn in an as path, that route will have transited that given ASn. As such, inserting others ASns into an as path is about as helpful to debugging as policy routing all your ICMP traffic to a box running fakeroute! There are various 'better than regular bgp bestpath' platforms out there, such as those internap implements, routescience, sockeye, netvmg.. Are you certain that these products do not take into account the amount of churn of a given ASn? By inserting operators ASns into announcements for your research, you are artifically increasing the amount of churn seen for their ASn. I note from your initial email "The announcements will be for prefixes 84.205.73.0/24 and 84.205.89.0/24 and will originate in AS12654." I'd like to point you at https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html and note that the smallest allocation from 84/8 is a /21, so by doing your announcements with /24s, you are probably going to hit some operators prefix length filters, thus tainting your results. You might be better off with some swamp space, which will be accepted globally as /24s. Sorry to be a wet blanket, but I think inserting other operators ASns without their permission is lunacy. I'm also concerned that this might lead to a convention where inserting other operators ASns into a path becomes more seen as 'acceptable', whereas it is currently regarded as a big 'no no'. And I suspect that prefix length filtering on your /24s from /21 space is going to taint the results anyway. Regards James
James A. T. Rice wrote:
You appear to be trying to take advantage of a side effect of this behaviour, in order to see what other ASn transitive adjacancies are available that would not normally be used, by inserting the ASns of transit AS's that would normally be used, into the as path you are announcing.
Yes, that's more or less what we are proposing.
I'm sure this was never an intended use for BGP as paths
No, obviously not. But many things in the protocols we use today are used in ways that the original authors didn't have in mind. Examples I can think of at the moment are IP-in-IP tunnels, TCP congestion control (bolted on to TCP long after it was first designed), NAT and private addresses, ..., but I'm sure there are many more. So I think a more relevant question than "was this intended", rather "is this useful? If so, does it break existing stuff?"
More to the point, you are breaking a very fundemenatal convention and expectation that if you see a given ASn in an as path, that route will have transited that given ASn.
That is not true in all cases. RFC 1771, paragraph 5.1.6, says:
A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute needs to be cognizant of the fact that the actual path to destinations, as specified in the NLRI of the route, while having the loop-free property, may traverse ASs that are not listed in the AS_PATH attribute.
I think that most of the the AS-sets you see announced in the Internet today have this property, and ours are no different: the sequence before the AS-set shows which ASes the announcement has passed through, and the AS-set which ASes the announcement "might have passed through".
As such, inserting others ASns into an as path is about as helpful to debugging as policy routing all your ICMP traffic to a box running fakeroute!
I don't understand why this should be the case. If you exclude the AS-set, then you get exactly the path that was followed by the announcement. How does that hamper debugging? Regards, Lorenzo
Dear All,
But first we need to do the experiments...
Given the large number of complaints on the various lists, I have decided to cancel this experiment for the time being. We may reschedule it at a later date, but only after we have posted a list of AS# to be used and given people a chance to opt-out beforehand. How exactly we are going to do this, has not been decided. As the RIPE NCC, we place great value in the support that you have given to our measurement experiments over the last years. I do not want to be responsible for destroying that trust with an experiment that may affect the reachability of 100+ AS's for a few hours during office hours. In Lorenzo's defence, I have to say that he is a very enthousiastic student who has been doing great stuff in the routing area. On this occasion, he became a bit overenthousiastic though. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine)
On Thu, Mar 03, 2005 at 07:58:18AM +0100, Henk Uijterwaal wrote:
Dear All,
But first we need to do the experiments...
Given the large number of complaints on the various lists, I have decided to cancel this experiment for the time being. We may reschedule it at a later date, but only after we have posted a list of AS# to be used and given people a chance to opt-out beforehand. How exactly we are going to do this, has not been decided.
Henk, Given that not everybody read these lists, although it would be usefull, I would suggest an opt-in model instead of opt-out. Grtx, MarcoH
Please exclude AS8220. Regards, Neil.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Lorenzo Colitti Sent: 02 March 2005 19:35 To: James A. T. Rice Cc: Gert Doering; nanog@merit.edu; routing-wg@ripe.net; ris-users@ripe.net; compunet@dia.uniroma3.it Subject: Re: Heads up: Long AS-sets announced in the next few days
James A. T. Rice wrote:
This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use.
In which case please keep AS8330, AS8550, and AS8943 out of your experiments too.
Using not yet allocated ASns out of RIPEs asn-blocks would have been more sensible, IMHO.
James,
we are not picking ASes at random. The AS-set announcements are part of new techniques we are developing for ISPs who wish to discover how their prefixes are seen by the rest of the Internet. We believe this will come to be a useful tool for operators.
However, since this is still work in progress, and in scientific research there is no room for second place, I can't really reveal any more than that at the moment.
I would like to point out, though, that our research group does have a proven track record in the field network discovery (examples available on request), and has created software useful to the operator community such as BGPlay [1][2].
That said, if you want us to exclude those ASes from our AS-sets, then we will do so.
Regards, Lorenzo
[1] http://www.ris.ripe.net/bgplay/ [2] http://bgplay.routeviews.org/bgplay/
What exactly are you attempting to do here? Those announcements will get dropped on the floor at least in this AS right away: route-map peers-in deny 5 match as-path 109 ip as-path access-list 109 permit ^[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+_[0-9]+ How does announcing ridiculously long as-paths help anyone, if anything we should be educating people that childishly long chains of prepends will not do what they want (presumably make more of a difference in traffic flows, which isn't going to work beyond a small number of prepends, as whats left is people localpreffing). James On Tue, 1 Mar 2005, Lorenzo Colitti wrote:
Hi,
as announced to the RIPE routing working group mailing list [1] and elsewhere, over the next few days the Computer Networks research group at Roma Tre University, in collaboration with the RIPE NCC RIS project, will be performing experiments involving announcements with large AS-sets in the AS-path. We are doing this to test innovative network discovery methodologies we developed to allow ISPs to determine how their prefixes are seen by the rest of the Internet. The announcements will be for prefixes 84.205.73.0/24 and 84.205.89.0/24 and will originate in AS12654.
We have been performing similar experiments over IPv6, in collaboration with the NAMEX internet exchange, since December 2004 with no ill effects; furthermore, our announcements are standard BGP, so conformant implementations should be able to process them, and very long AS-sets have already been observed in the past (e.g. [2], [3]). However, we want to be careful to avoid router bugs on legacy devices, old firmware versions and the like, so we are first sending out test announcements with progressively longer AS-sets. Should you encounter a problem with these advertisements, please let us know and we will withdraw them.
The proposed timetable of the test announcements is as follows.
2005-03-04: 14:00 UTC: 10-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 25-element AS-set 16:30 UTC: withdrawal
and, if there are no problems:
2005-03-07: 14:00 UTC: 50-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 100-element AS-set 16:30 UTC: withdrawal
Note: For reference, the AS-sets already observed in [2] and [3] contained 123 and 124 ASes respectively.
For questions/comments, please contact compunet@dia.uniroma3.it or lorenzo@ripe.net.
Regards, Lorenzo Colitti On behalf of the Roma Tre Computer Networks Research group
[1] http://www.ripe.net/ripe/maillists/archives/routing-wg/2005/msg00021.html [2] http://www.ripe.net/projects/ris/Talks/0101_RIPE38_AA/sld003.html [3] http://www.ripe.net/maillists/ncc-archives/ris-users/2002/msg00044.html
On Wed, Mar 02, 2005 at 01:27:31AM +0000, James A. T. Rice wrote:
What exactly are you attempting to do here? Those announcements will get dropped on the floor at least in this AS right away:
route-map peers-in deny 5 match as-path 109
AS-Sets, not AS-Paths... Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
At 02:49 AM 02-03-05 +0100, Daniel Roesen wrote:
On Wed, Mar 02, 2005 at 01:27:31AM +0000, James A. T. Rice wrote:
What exactly are you attempting to do here? Those announcements will get dropped on the floor at least in this AS right away:
route-map peers-in deny 5 match as-path 109
AS-Sets, not AS-Paths...
An example of which I received recently: Feb 27 19:54:16: %BGP-6-ASPATH: Long AS path 20965 1299 3320 15589 15589 5397 {33,109,145,293,559,816,1103,1273,1275,1752,1853,1930,2042,2200,2497,2500,2914,3257,3265,3333,3352,3425,3549,4691,4697,4716,4725,5511,5539,5609,5623,6175,6435,6453,6762,6830,6939,7580,7660,8447,8472,8763,9264,10566,12779,12793,12859,13944,14277,15897,17715,17965,24136,24895,25358,29377,29686,31103,32266} received from 2001:798:201B:10AA::1: More than configured MAXAS-LIMIT -Hank
On Wed, 2 Mar 2005, Hank Nussbacher wrote:
At 02:49 AM 02-03-05 +0100, Daniel Roesen wrote:
On Wed, Mar 02, 2005 at 01:27:31AM +0000, James A. T. Rice wrote:
What exactly are you attempting to do here? Those announcements will get dropped on the floor at least in this AS right away:
route-map peers-in deny 5 match as-path 109
AS-Sets, not AS-Paths...
An example of which I received recently: Feb 27 19:54:16: %BGP-6-ASPATH: Long AS path 20965 1299 3320 15589 15589 5397 {33,109,145,293,559,816,1103,1273,1275,1752,1853,1930,2042,2200,2497,2500,2914,3257,3265,3333,3352,3425,3549,4691,4697,4716,4725,5511,5539,5609,5623,6175,6435,6453,6762,6830,6939,7580,7660,8447,8472,8763,9264,10566,12779,12793,12859,13944,14277,15897,17715,17965,24136,24895,25358,29377,29686,31103,32266} received from 2001:798:201B:10AA::1: More than configured MAXAS-LIMIT
different, but related to: Feb 1 20:47:01.608: %BGP-6-ASPATH: Long AS path 3356 6770 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 received from x.y.a.b: More than configured MAXAS-LIMIT hey, 8282/Fido, perhaps you don't really need a 100 as as-path? :) -Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2 Mar 2005, at 08:09, Christopher L. Morrow wrote:
On Wed, 2 Mar 2005, Hank Nussbacher wrote:
At 02:49 AM 02-03-05 +0100, Daniel Roesen wrote:
On Wed, Mar 02, 2005 at 01:27:31AM +0000, James A. T. Rice wrote:
What exactly are you attempting to do here? Those announcements will get dropped on the floor at least in this AS right away:
route-map peers-in deny 5 match as-path 109
AS-Sets, not AS-Paths...
An example of which I received recently: Feb 27 19:54:16: %BGP-6-ASPATH: Long AS path 20965 1299 3320 15589 15589 5397 {33,109,145,293,559,816,1103,1273,1275,1752,1853,1930,2042,2200,2497,2 500,2914,3257,3265,3333,3352,3425,3549,4691,4697,4716,4725,5511,5539,5 609,5623,6175,6435,6453,6762,6830,6939,7580,7660,8447,8472,8763,9264,1 0566,12779,12793,12859,13944,14277,15897,17715,17965,24136,24895,25358 ,29377,29686,31103,32266} received from 2001:798:201B:10AA::1: More than configured MAXAS-LIMIT
different, but related to: Feb 1 20:47:01.608: %BGP-6-ASPATH: Long AS path 3356 6770 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 received from x.y.a.b: More than configured MAXAS-LIMIT
hey, 8282/Fido, perhaps you don't really need a 100 as as-path? :)
That was an embarrassing and painful week which I never wish to repeat, but related to a "feature" of OpenBGPD which has now been resolved. (Thanks Henning and Peter :) As a result of this I know a large number of companies have now instigated a max prefix length of 100 .... way too many Cisco's barfed on the 124+ lengths.
-Chris
Kindest Regards Jon Morby fax to email service - register at http://www.fido.net/fax2email/ and for all your telecom needs - http://www.fidotelecom.com/ - -- FidoNet Registration Services Ltd tel: 0845 004 3050 fido.net - the internet made simple! fax: 0845 004 3051 -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiWTtypkummzta06EQIrpwCgzbG+GJvjpbHLVsAu/ooTNJlmbTIAn3CZ zspuZD5Ts1iZTCgyeFTCvXuo =OQp5 -----END PGP SIGNATURE-----
participants (14)
-
Blaine Christian -
Christopher L. Morrow -
Daniel Roesen -
Geoff Huston -
Gert Doering -
Hank Nussbacher -
Henk Uijterwaal -
James A. T. Rice -
Jeroen Massar -
Jon Morby -
Kurt Erik Lindqvist -
Lorenzo Colitti -
MarcoH -
Neil J. McRae