Re: The Cidr Report
When my zebra BGP daemin looses its grip on life and dies a horrible death the rest to the scripts wander into a strange twilight zone and make up numbers sorry (I really need to code more defensively for this type of condition!) geoff At 04:56 AM 11/11/2006, Fergie wrote: Indeed -- it apears to have flaked out a bit this (IETF) week. :-) Date PrefixesCIDR Aggregated 04-11-06 199323 129829 05-11-06 199330 129854 06-11-06 199273 129854 07-11-06 -1077937252 129854 08-11-06 -1077936760 129854 09-11-06 672037797 129854 10-11-06 -1077937324 129854 11-11-06 134555024 129854 - ferg -- Simon Leinen [EMAIL PROTECTED] wrote: cidr-report writes: Recent Table History Date PrefixesCIDR Agg 03-11-06199409 129843 [...] 10-11-06 134555024 129854 Growth of the global routing table really picked up pace this week! (But maybe I'm just hallucinating for having heard the report from the IAB Routing Workshop report three times in a week :-) Or the CIDR Report software has an R200K problem? -- Simon. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
RE: The Cidr Report
It sounds like government work! When something doesn't work, they just make numbers up! (Just be sure to create more plausible numbers next time! (smirk)) Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Huston Sent: Sunday, November 12, 2006 12:15 PM To: Fergie; [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: Re: The Cidr Report When my zebra BGP daemin looses its grip on life and dies a horrible death the rest to the scripts wander into a strange twilight zone and make up numbers sorry (I really need to code more defensively for this type of condition!) geoff At 04:56 AM 11/11/2006, Fergie wrote: Indeed -- it apears to have flaked out a bit this (IETF) week. :-) Date PrefixesCIDR Aggregated 04-11-06 199323 129829 05-11-06 199330 129854 06-11-06 199273 129854 07-11-06 -1077937252 129854 08-11-06 -1077936760 129854 09-11-06 672037797 129854 10-11-06 -1077937324 129854 11-11-06 134555024 129854 - ferg -- Simon Leinen [EMAIL PROTECTED] wrote: cidr-report writes: Recent Table History Date PrefixesCIDR Agg 03-11-06199409 129843 [...] 10-11-06 134555024 129854 Growth of the global routing table really picked up pace this week! (But maybe I'm just hallucinating for having heard the report from the IAB Routing Workshop report three times in a week :-) Or the CIDR Report software has an R200K problem? -- Simon. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
RE: The Cidr Report
heh heh No its all amateur time round here. :-) Geoff At 06:17 AM 13/11/2006, Scott Morris wrote: It sounds like government work! When something doesn't work, they just make numbers up! (Just be sure to create more plausible numbers next time! (smirk))
Re: The Cidr Report
cidr-report writes: Recent Table History Date PrefixesCIDR Agg 03-11-06199409 129843 [...] 10-11-06 134555024 129854 Growth of the global routing table really picked up pace this week! (But maybe I'm just hallucinating for having heard the report from the IAB Routing Workshop report three times in a week :-) Or the CIDR Report software has an R200K problem? -- Simon.
Re: The Cidr Report
Indeed -- it apears to have flaked out a bit this (IETF) week. :-) Date PrefixesCIDR Aggregated 04-11-06 199323 129829 05-11-06 199330 129854 06-11-06 199273 129854 07-11-06 -1077937252 129854 08-11-06 -1077936760 129854 09-11-06 672037797 129854 10-11-06 -1077937324 129854 11-11-06 134555024 129854 - ferg -- Simon Leinen [EMAIL PROTECTED] wrote: cidr-report writes: Recent Table History Date PrefixesCIDR Agg 03-11-06199409 129843 [...] 10-11-06 134555024 129854 Growth of the global routing table really picked up pace this week! (But maybe I'm just hallucinating for having heard the report from the IAB Routing Workshop report three times in a week :-) Or the CIDR Report software has an R200K problem? -- Simon. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: The Cidr Report
I was hoping the report would be cleaned up by now but it hasn't so sorry for the multiple list post. The Bogon section is IMHO, broken. Taking just the 1st line as an example: Prefix Origin AS AS Description Unallocated block 3.0.0.0/8 AS80 GE-CRD - General Electric Company 0.0.0.0 - 3.0.0.0 3.0.0.0/8 is allocated, as is AS80. I suspect the algorithm, which determines the unallocated block of 0.0.0.0 - 3.0.0.0 to be somewhat broken. There are thousands of lines like that. The bogus AS section also appears to be broken. -Hank
Re: The Cidr Report
At 10:27 AM 14-02-05 +1000, Philip Smith wrote: Well said. At NANOG you get the clueful people cuz they at least knew to come. That is a start. But there are hundreds of ISPs out there who don't have a clue. RIPE realized this without having to do a membership poll and rightly so, goes and does training where it is needed (and believe me - I am their biggest critic and all-around pain in the ass when it comes to their expenses as Leo and Rob can attest). NANOG is not the place to do it. ARIN, as part of their overhead should do an east coast, west coast and Chicago area tutorial at least once a year. And guess what - most of the training material has already been written by the other RIRs. -Hank The BGP tutorials I've been doing on Sundays at NANOG all cover aggregation - at least, I seem to end up talking about aggregation in each one. Maybe I need to be more direct? But then again, who am I preaching to? The choir maybe, I don't know. Maybe we need a specific aggregation tutorial for those who don't know how to? Those who have operational and technical reasons not to aggregate have made that decision with prior knowledge. We should try and give everyone else the knowledge, then at least we will know that all de-aggregation is done for a reason. Then it begs the question, is NANOG the conference actually reaching the people who'd most benefit from it? I say this as I'm in transit in Singapore heading back from a hugely successful and enjoyable SANOG (South Asia NOG) in Bangladesh. Similar idea to NANOG, but heavier emphasis on education (workshops tutorials), and we had ISPs falling over themselves to participate in the first Internet operations meeting held in that country. philip -- +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
Re: The Cidr Report
[EMAIL PROTECTED] (Hank Nussbacher) wrote: Duh! No suprise there. ARIN just gives IP space and only offers some measly online training: http://www.arin.net/library/training/index.html RIPE on the other hand, has 3-6 course a month, throughout Europe: http://www.ripe.net/training/lir/index.html http://www.ripe.net/cgi-bin/courselist.pl.cgi You should read the course outline. RIPE teaches nothing whatsoever to do with routing. It's all registration stuff... But certainly, a routing course could be added, maybe to a somewhat more techy track like where the DNSSEC courses sit. Yours, Elmar. -- Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren. (PLemken, [EMAIL PROTECTED]) --[ ELMI-RIPE ]---
RE: The Cidr Report
Hank and Warren are right on. I have seen several ISPs (one of which has been around a long time) who don't even understand the basics of CIDR routing or why they should aggregate their announcements. This same group are the ones who are not subscribed to this mailing list and don't go to Nanog events, and there are surly a large number of them. I think one thing the CIDR report glosses over, with its ranking system is the sheer number of ASes which announce extra routes. At least that is what strikes me when I start punching my local peer (not customer) ASes into the cidr-report website, virtually all of them have an aggregation problem and by percentage of junk announcements, the small ASes are often far worse than the big guys. That being said, perhaps we need some sort of nanog outreach or BGP support community that larger (or clue full) providers can point their less clue full BGP customers towards. The question then becomes, who would maintain such a group and how do we get the large number of currently non-participating ASes involved? John van Oppen PocketiNet Communications AS23265 (which yes, is fully aggregated) -Ursprüngliche Nachricht- Von: Hank Nussbacher [mailto:[EMAIL PROTECTED] Gesendet: Monday, February 14, 2005 12:26 AM An: Philip Smith Cc: Nanog Betreff: Re: The Cidr Report At 10:27 AM 14-02-05 +1000, Philip Smith wrote: Well said. At NANOG you get the clueful people cuz they at least knew to come. That is a start. But there are hundreds of ISPs out there who don't have a clue. RIPE realized this without having to do a membership poll and rightly so, goes and does training where it is needed (and believe me - I am their biggest critic and all-around pain in the ass when it comes to their expenses as Leo and Rob can attest). NANOG is not the place to do it. ARIN, as part of their overhead should do an east coast, west coast and Chicago area tutorial at least once a year. And guess what - most of the training material has already been written by the other RIRs. -Hank The BGP tutorials I've been doing on Sundays at NANOG all cover aggregation - at least, I seem to end up talking about aggregation in each one. Maybe I need to be more direct? But then again, who am I preaching to? The choir maybe, I don't know. Maybe we need a specific aggregation tutorial for those who don't know how to? Those who have operational and technical reasons not to aggregate have made that decision with prior knowledge. We should try and give everyone else the knowledge, then at least we will know that all de-aggregation is done for a reason. Then it begs the question, is NANOG the conference actually reaching the people who'd most benefit from it? I say this as I'm in transit in Singapore heading back from a hugely successful and enjoyable SANOG (South Asia NOG) in Bangladesh. Similar idea to NANOG, but heavier emphasis on education (workshops tutorials), and we had ISPs falling over themselves to participate in the first Internet operations meeting held in that country. philip -- +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
RE: The Cidr Report
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hank Nussbacher Sent: Monday, February 14, 2005 3:26 AM To: Philip Smith Cc: Nanog Subject: Re: The Cidr Report At 10:27 AM 14-02-05 +1000, Philip Smith wrote: Well said. At NANOG you get the clueful people cuz they at least knew to come. That is a start. But there are hundreds of ISPs out there who don't have a clue. RIPE realized this without having to do a membership poll and rightly so, goes and does training where it is needed (and believe me - I am their biggest critic and all-around pain in the ass when it comes to their expenses as Leo and Rob can attest). NANOG is not the place to do it. ARIN, as part of their overhead should do an east coast, west coast and Chicago area tutorial at least once a year. And guess what - most of the training material has already been written by the other RIRs. Am I misreading the report? That doesn't look like a list of clueless people. Just because another RIR does something doesn't mean we should automatically assume ARIN should too. This is a different area with different dynamics. Regardless, you could always propose this to ARIN instead of NANOG. :-) -M
RE: The Cidr Report
Based on the experience with the CIDR Police project (http://www.nanog.org/mtg-0302/cidr.html), you can encourge operators to aggregate. My observation during that time was that operators: - Didn't know they had a problem. - Didn't know how to set up an aggregation policy - Had no one paying attention to the advertisements - Never had time to deal with the problem. Usually, nudging, encouragement, and clue helped. Having the NANOG Tutorials on-line helped - since we use them as on-line learning tools to tactfully clue-in people. Perhaps it is time for a new crew to get together to form a new CIDR Police team? Every week would get people from the CIDR Police knocking on the doors of their peers offering their help and asstance to enhance their aggregation. Hank and I are occupied with another project, but I'm sure we can brain dump to any who would like to build this new team. My $.02, Barry
Re: The Cidr Report
Jerry Pasker wrote: Until there's deep shame, or real financial incentive to not being listed as a member of the dirty 30, nothing is going to happen in terms of aggregation. I sometimes wonder if this list is seen as some sort of hit parade of potential peers and if that is the case then perhaps another list acknowledging the largest players with the best aggregation might also be in order. Mark.
Re: The Cidr Report
On Sun, 13 February 2005 07:31:16 +, Christopher L. Morrow wrote: [..] There are some business reasons to de-aggregate. Look at some outages caused by 'routing problems' (someone leaked my /24's to their peers, peers, peer and my traffic got blackholed, because the public net only knows me as a /20) I am surprised you bring such an argument up. While we can surely agree on this happening on the net, I have yet to hear from someone saying this is happening more than once a month or so. Maybe Todd from Renesys has other examples besides the Yahoo incident.^ There are multiple reasons for deaggregation aside from 'dumb operator', some are even 'valid' if you look at them from the protection standpoint. I won't argue that, but how many ISPs are using this line of argument? I have not heard anyone yet telling me this, not in years. And surely you can get notification for any more specific prefixes in your networks from Renesys and likely others already, if you do not write a script yourself that has a look on routeviews or other similar services and notifies you. Also things like conditional announcements and no-export are often not known, and if you have two POPs and lack the 'backbone' capacity between these there are still other ways than just announce more specifics all around the place. Alexander
Re: The Cidr Report
On Sun, 13 Feb 2005, Alexander Koch wrote: On Sun, 13 February 2005 07:31:16 +, Christopher L. Morrow wrote: [..] There are some business reasons to de-aggregate. Look at some outages caused by 'routing problems' (someone leaked my /24's to their peers, peers, peer and my traffic got blackholed, because the public net only knows me as a /20) I am surprised you bring such an argument up. While we can surely agree on this happening on the net, I have yet to hear from someone saying this is happening more than once a month or so. Maybe Todd from Renesys has other examples besides the Yahoo incident.^ if it happens once to you and lasts long enough... I'm not condoning it, nor saying it's even a valid reason to do it, just pointing out that it does happen :( There are multiple reasons for deaggregation aside from 'dumb operator', some are even 'valid' if you look at them from the protection standpoint. I won't argue that, but how many ISPs are using this line of argument? I have not heard anyone yet telling me this, not in years. a few have... recently in fact.
Re: The Cidr Report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 13, 2005, at 2:31 AM, Christopher L. Morrow wrote: On Sat, 12 Feb 2005, Alexander Koch wrote: On Sat, 12 February 2005 14:58:42 +, Stephen J. Wilcox wrote: From: Stephen J. Wilcox [EMAIL PROTECTED] [...] - would you agree that most of the poor deaggregating is not intentional ie that they're announcing their '16 class Cs' or historically had 2 /21s and Think about someone putting in a Null0 route and re- exporting stuff unconditionally, now after he originates his /19 he is then adding a /24 here, and a /25 there. Lack of experience, when you suggest to them they should remove these announcements they are afraid to change it, not understanding the implications, etc. Not to mention ppl using cisco and prefix lists, it is way too easy with cisco to say '/19 le 24', and then they use outbound prefix lists to their transit supplier (different, but related as I see it). Some transit ISPs use that a lot, and encourage the table growth. There are some business reasons to de-aggregate. Look at some outages caused by 'routing problems' (someone leaked my /24's to their peers, peers, peer and my traffic got blackholed, because the public net only knows me as a /20) There are multiple reasons for deaggregation aside from 'dumb operator', some are even 'valid' if you look at them from the protection standpoint. -Chris That and the I have 1 circuit to $good_provider and 1 circuit to $bad_provider and the only way I can make them balance is to split my space in half and announce more specifics out through each provider argument. I have also often seen people do this without announcing the aggregate because some undefined bad thing will happen, usually justified with much hand-waving. The people who do this can usually not be reasoned with It happens all the time... Warren. - -- He who laughs last, thinks slowest. -- Anonymous -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCEMBhHSkNr4ucEScRArsVAKD98l4rpQLmPh6PBuCqvaYHFWYPhwCg1+Ua KP85z1snGejdGB+D7klo+U8= =Mz3a -END PGP SIGNATURE-
RE: The Cidr Report
I have recently heard companies saying their reasoning for de-aggregation was 1) to protect against outages to their customer base when a more specific of their aggregate was announced somewhere else and 2) if they are getting DDOS attacked on a given /24 they can just drop that advertisement and only affect part of their customer base. As technically savvy folks, we may not agree with this line of reasoning. However, keep in mind that the technically savvy folks are not always the ones making the decisions within a company. Just because someone has enable access and clue does not mean they have the authority to make certain decisions. Most of those people probably spend a large amount of their time arguing with the decision makers to try and do the right thing but at some point they lose those arguments. -- Justin Ryburn [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher L. Morrow Sent: Sunday, February 13, 2005 2:30 AM To: Alexander Koch Cc: nanog@merit.edu Subject: Re: The Cidr Report On Sun, 13 Feb 2005, Alexander Koch wrote: On Sun, 13 February 2005 07:31:16 +, Christopher L. Morrow wrote: [..] There are some business reasons to de-aggregate. Look at some outages caused by 'routing problems' (someone leaked my /24's to their peers, peers, peer and my traffic got blackholed, because the public net only knows me as a /20) I am surprised you bring such an argument up. While we can surely agree on this happening on the net, I have yet to hear from someone saying this is happening more than once a month or so. Maybe Todd from Renesys has other examples besides the Yahoo incident.^ if it happens once to you and lasts long enough... I'm not condoning it, nor saying it's even a valid reason to do it, just pointing out that it does happen :( There are multiple reasons for deaggregation aside from 'dumb operator', some are even 'valid' if you look at them from the protection standpoint. I won't argue that, but how many ISPs are using this line of argument? I have not heard anyone yet telling me this, not in years. a few have... recently in fact.
Re: The Cidr Report
On Mon, 14 Feb 2005, Warren Kumari, Ph.D, CCIE# 9190 wrote: On Feb 13, 2005, at 2:31 AM, Christopher L. Morrow wrote: There are multiple reasons for deaggregation aside from 'dumb operator', some are even 'valid' if you look at them from the protection standpoint. That and the I have 1 circuit to $good_provider and 1 circuit to $bad_provider and the only way I can make them balance is to split my space in half and announce more specifics out through each provider argument. I have also often seen people do this without announcing the aggregate because some undefined bad thing will happen, usually justified with much hand-waving. The people who do this can usually not be reasoned with this just reinforces the argument that they are lacking in technical savvy. i have a transit provider who i dont want to carry much traffic and i dont want to prepend my announcements.. by looking at that providers supported customer communities i just get them to prepend as they export to other major networks thus moving the main volume of the traffic to the desired ingress paths no deaggregation, no prepending.. Steve
RE: The Cidr Report
On Sun, 13 Feb 2005, Justin Ryburn wrote: I have recently heard companies saying their reasoning for de-aggregation was 1) to protect against outages to their customer base when a more specific of their aggregate was announced somewhere else and 2) if they are getting DDOS attacked on a given /24 they can just drop that advertisement and only affect part of their customer base. 1) this only provides partial protection, even if you announce a /24 i can still announce my own /24 and get some of your traffic 2) either they are operating networks that cant support their business and i dont see why we should bale them out or in the cases where certain hosts are accepted by us as targets (ircnets etc) you could argue to obtain a discrete /24 which is the better evil than taking a /16 and breaking it down to take out a /24 i'm not keen on this latter idea, what if i operate an anti-ddos specialist isp, hosting ircnets, gambling, security sites etc - do i put each host in a /24 and waste a whole /16 with a couple hundred customers? i strongly believe if you want to be an autonomous internet provider then you should be able to run your network by accepted means not thro cheap hacks As technically savvy folks, we may not agree with this line of reasoning. However, keep in mind that the technically savvy folks are not always the ones making the decisions within a company. Just because someone has enable access and clue does not mean they have the authority to make certain decisions. Most of those people probably spend a large amount of their time arguing with the decision makers to try and do the right thing but at some point they lose those arguments. if their suppliers/peers disagree strongly they would not be able to present these options in the first place.. lack of regulation has its downsides it would seem.. Steve
Re: The Cidr Report
--On 13 February 2005 01:36 -0600 Jerry Pasker [EMAIL PROTECTED] wrote: Until there's deep shame, or real financial incentive to not being listed as a member of the dirty 30, nothing is going to happen in terms of aggregation. Unfortunately, an automated email going out to each of the dirty 30 weekly from the Cidr Report saying that their network again made the list of top 30 most shameful examples of how to participate as an active member in the global routing table would probably have little effect. If they cared, they'd already be doing something about it. Nothing is going to happen unless enough people (ASNs) take a simultaneous, and UNITED stand, and make it painful for those that don't care about the routes they leak to the net. Here's an idea, it's probably not the best idea, and has a *lot* of potential problems, but it's just an idea: Pick the top 1 or two worst offenders every week, and automatically dump them into a route distribution server would work in the same way as the Team Cymru bogon server list. I bet THAT would get people to scramble aggregate! Want to make a clear business case for spending time to clean up routes? How about global routability ? Every week, the top of the list would be singled out, and they could be placed on the server, and anyone that wanted to null route them based on that information could do so. A level of automation would be required to quickly remove them from the blacklist as soon as they aggregated, and quickly re-add them without warning if they decide to deaggregate within a certain time frame of being on the blacklist. If the addition/removal was automated, it would be clear cut as to why the victim was placed on the list. No favoritism or politics would come in to play. It would get results. I'm not sure what those results would be, and the result might just be a bunch of really mad and aggravated people, and a slightly more broken internet, but there'd definitely be results. Or something.;-) (I bet it would be a lot like the early days of DNS-RBL for mail servers) I'm sure someone on this list who is wiser than me, has a better idea. I'd love to hear it discussed. I'm going to repeat what I typed earlier: Nothing is going to happen unless enough people (ASNs) take a simultaneous, and UNITED stand, and make it painful for those that don't care about the routes they leak to the net. -Jerry Perhaps another way this could happen might be by somewhat widespread use of something along the lines of = Cisco Version route-map CIDR_Top10 deny 10 match as-path 10 match ip address prefix-list deagg_pollution route-map CIDR_Abusers permit 1000 ip as-path access-list 10 permit _4323$ ip as-path access-list 10 permit _18566$ ip as-path access-list 10 permit _4134$ ip as-path access-list 10 permit _721$ ip as-path access-list 10 permit _22773$ ip as-path access-list 10 permit _7018$ ip as-path access-list 10 permit _27364$ ip as-path access-list 10 permit _6197$ ip as-path access-list 10 permit _3602$ ip as-path access-list 10 permit _6478$ ip prefix-list deagg_pollution seq 10 permit 0.0.0.0/1 ge 21 ip prefix-list deagg_pollution seq 20 permit 128.0.0.0/2 ge 21 ip prefix-list deagg_pollution seq 30 permit 192.0.0.0/3 ge 24 The as-path could easily be changed to include the top n abusers or to include downstream ASs rather than just source ASs. Just thinking out loud Peter Walker
Re: The Cidr Report
From: Warren Kumari, Ph.D, CCIE# 9190 [EMAIL PROTECTED] Date: Mon, 14 Feb 2005 10:14:38 -0500 To: nanog@merit.edu Subject: Re: The Cidr Report -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 13, 2005, at 2:31 AM, Christopher L. Morrow wrote: On Sat, 12 Feb 2005, Alexander Koch wrote: On Sat, 12 February 2005 14:58:42 +, Stephen J. Wilcox wrote: From: Stephen J. Wilcox [EMAIL PROTECTED] [...] - would you agree that most of the poor deaggregating is not intentional ie that they're announcing their '16 class Cs' or historically had 2 /21s and Think about someone putting in a Null0 route and re- exporting stuff unconditionally, now after he originates his /19 he is then adding a /24 here, and a /25 there. Lack of experience, when you suggest to them they should remove these announcements they are afraid to change it, not understanding the implications, etc. Not to mention ppl using cisco and prefix lists, it is way too easy with cisco to say '/19 le 24', and then they use outbound prefix lists to their transit supplier (different, but related as I see it). Some transit ISPs use that a lot, and encourage the table growth. There are some business reasons to de-aggregate. Look at some outages caused by 'routing problems' (someone leaked my /24's to their peers, peers, peer and my traffic got blackholed, because the public net only knows me as a /20) There are multiple reasons for deaggregation aside from 'dumb operator', some are even 'valid' if you look at them from the protection standpoint. -Chris That and the I have 1 circuit to $good_provider and 1 circuit to $bad_provider and the only way I can make them balance is to split my space in half and announce more specifics out through each provider argument. I have also often seen people do this without announcing the aggregate because some undefined bad thing will happen, usually justified with much hand-waving. The people who do this can usually not be reasoned with It happens all the time... Warren. So, say I'm a provider that has received a /22 from UUNet (just for example Chris :-) ) and I now get another transit provider and announce the /22 there. So, I call UUNet and ask them to announce the /22 as a more specific because I don't want a de-facto asymmetric configuration. I *want* to get a /20 from ARIN but my usage doesn't justify it yet, so I have to ride the /22 for some time. By the long string of anecdotal attacks in the string to date, listing most or all such providers as bad or uninformed how do you separate out those providers who are legitimately interested in routing redundancy and not clue impaired? Do we just say too bad, routing table bloat is more important than your need for redundancy small guy!? I find it interesting that the general theme is one of we're smarter than they are because we aggregate more routes as if clue were directly correlated to aggregated routing announcements. Mike -- Michael K. Smith NoaNet 206.219.7116 (work) 866.662.6380 (NOC) [EMAIL PROTECTED] http://www.noanet.net
Re: The Cidr Report
On Sun, 13 Feb 2005, Michael Smith wrote: From: Warren Kumari, Ph.D, CCIE# 9190 [EMAIL PROTECTED] On Feb 13, 2005, at 2:31 AM, Christopher L. Morrow wrote: That and the I have 1 circuit to $good_provider and 1 circuit to $bad_provider and the only way I can make them balance is to split my space in half and announce more specifics out through each provider argument. I have also often seen people do this without announcing the aggregate because some undefined bad thing will happen, usually justified with much hand-waving. The people who do this can usually not be reasoned with So, say I'm a provider that has received a /22 from UUNet (just for example Chris :-) ) and I now get another transit provider and announce the /22 there. So, I call UUNet and ask them to announce the /22 as a more specific Meaning you have PA space from UUNET, and you have BGP so you can multi-home... I'd expect you to know how to deaggregate yourself. You MIGHT even know how to send no-export on deaggregated prefixes, or use the 1996 policies to influence preferences/prepends internal to 701, yes? because I don't want a de-facto asymmetric configuration. I *want* to get a /20 from ARIN but my usage doesn't justify it yet, so I have to ride the /22 for some time. I'm not clear as to how the /22 to /20 discussion goes, or how it's even relevant... but it's been a long day. Can you elaborate? By the long string of anecdotal attacks in the string to date, listing most or all such providers as bad or uninformed how do you separate out those providers who are legitimately interested in routing redundancy and not clue a /22 in both directions seems like safe 'redundancy'. Adding no-export /24's or /32's if you want (yuck) would get you more preference inside one provider or the other. I'm also fairly sure I didn't say: bad or uniformed the 'bad provider' is from Warren, not I. impaired? Do we just say too bad, routing table bloat is more important than your need for redundancy small guy!? I think that folks have been pushed toward multihoming with multiple providers (not just 'redundant T1' or 'shadow T1' services inside the same provider) over the last few years. That means some bloat is bound to occur. I'm not measuring it myself, but the renesys folks and LCS folks have been I think? Perhaps they can comment on that phenomenon? I find it interesting that the general theme is one of we're smarter than they are because we aggregate more routes as if clue were directly correlated to aggregated routing announcements. it's not? :) (joking of course) As I said before some folks feel they have a legitimate reason for deaggregating. If you can spend some time chatting them up about their reasons and either: 1) realizing they hav a point 2) re-purpose their thoughts toward 'better cidr management' (as pfs said) then good for you... and everyone else :) I have spent sometime on occasion doing this, sometimes it works out, othertimes it doesn't :( It's always an experience though. -Chris
Re: The Cidr Report
On Sun, 13 Feb 2005, Michael Smith wrote: From: Warren Kumari, Ph.D, CCIE# 9190 [EMAIL PROTECTED] Date: Mon, 14 Feb 2005 10:14:38 -0500 To: nanog@merit.edu Subject: Re: The Cidr Report -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 13, 2005, at 2:31 AM, Christopher L. Morrow wrote: On Sat, 12 Feb 2005, Alexander Koch wrote: On Sat, 12 February 2005 14:58:42 +, Stephen J. Wilcox wrote: From: Stephen J. Wilcox [EMAIL PROTECTED] [...] - would you agree that most of the poor deaggregating is not intentional ie that they're announcing their '16 class Cs' or historically had 2 /21s and Think about someone putting in a Null0 route and re- exporting stuff unconditionally, now after he originates his /19 he is then adding a /24 here, and a /25 there. Lack of experience, when you suggest to them they should remove these announcements they are afraid to change it, not understanding the implications, etc. Not to mention ppl using cisco and prefix lists, it is way too easy with cisco to say '/19 le 24', and then they use outbound prefix lists to their transit supplier (different, but related as I see it). Some transit ISPs use that a lot, and encourage the table growth. There are some business reasons to de-aggregate. Look at some outages caused by 'routing problems' (someone leaked my /24's to their peers, peers, peer and my traffic got blackholed, because the public net only knows me as a /20) There are multiple reasons for deaggregation aside from 'dumb operator', some are even 'valid' if you look at them from the protection standpoint. -Chris That and the I have 1 circuit to $good_provider and 1 circuit to $bad_provider and the only way I can make them balance is to split my space in half and announce more specifics out through each provider argument. I have also often seen people do this without announcing the aggregate because some undefined bad thing will happen, usually justified with much hand-waving. The people who do this can usually not be reasoned with It happens all the time... Warren. So, say I'm a provider that has received a /22 from UUNet (just for example Chris :-) ) and I now get another transit provider and announce the /22 there. So, I call UUNet and ask them to announce the /22 as a more specific because I don't want a de-facto asymmetric configuration. I *want* to get a /20 from ARIN but my usage doesn't justify it yet, so I have to ride the /22 for some time. Hi Mike, this isnt the scenario being discussed. The scenario of issue is where you get your /22 from UUNET and announce 4x /24 ie based on what ips you have you choose to announce more than the minimum to make them routable By the long string of anecdotal attacks in the string to date, listing most or all such providers as bad or uninformed how do you separate out those providers who are legitimately interested in routing redundancy and not clue impaired? Do we just say too bad, routing table bloat is more important than your need for redundancy small guy!? As I say this isnt the issue here, altho what you suggest would be an example of further aggregation that i personally think is extreme. Multihoming must be possible and a hierarchical structure to the internet is not appropriate. I find it interesting that the general theme is one of we're smarter than they are because we aggregate more routes as if clue were directly correlated to aggregated routing announcements. Well, there does seem to be some loose correlation it cant be denied... (counter examples not required, we know they exist) Steve
RE: The Cidr Report
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christopher L. Morrow Sent: Sunday, February 13, 2005 6:19 PM To: Michael Smith Cc: Warren Kumari, Ph.D, CCIE# 9190; Nanog Subject: Re: The Cidr Report On Sun, 13 Feb 2005, Michael Smith wrote: From: Warren Kumari, Ph.D, CCIE# 9190 [EMAIL PROTECTED] On Feb 13, 2005, at 2:31 AM, Christopher L. Morrow wrote: That and the I have 1 circuit to $good_provider and 1 circuit to $bad_provider and the only way I can make them balance is to split my space in half and announce more specifics out through each provider argument. I have also often seen people do this without announcing the aggregate because some undefined bad thing will happen, usually justified with much hand-waving. The people who do this can usually not be reasoned with So, say I'm a provider that has received a /22 from UUNet (just for example Chris :-) ) and I now get another transit provider and announce the /22 there. So, I call UUNet and ask them to announce the /22 as a more specific Meaning you have PA space from UUNET, and you have BGP so you can multi-home... I'd expect you to know how to deaggregate yourself. You MIGHT even know how to send no-export on deaggregated prefixes, or use the 1996 policies to influence preferences/prepends internal to 701, yes? Is aggregation being covered in the Sunday BoF's? [ hint, hint ] -M
Re: The Cidr Report
On Sun, 13 Feb 2005, Jerry Pasker wrote: Until there's deep shame, or real financial incentive to not being listed as a member of the dirty 30, nothing is going to happen in terms of aggregation. [...] Nothing is going to happen unless enough people (ASNs) take a simultaneous, and UNITED stand, and make it painful for those that don't care about the routes they leak to the net. Similarly, enough people won't get involved until there is real financial incentive to do so. Most people won't particularly care about the number of routes in a full table until their equipment becomes unable to handle it. Does anyone have any idea of the routing table size limits of old but still common equipment? I suspect we'll see a lot more interest in routing table size when things start to break. -- Aaron
Re: The Cidr Report
Hannigan, Martin said the following on 14/02/2005 09:32: Is aggregation being covered in the Sunday BoF's? [ hint, hint ] The BGP tutorials I've been doing on Sundays at NANOG all cover aggregation - at least, I seem to end up talking about aggregation in each one. Maybe I need to be more direct? But then again, who am I preaching to? The choir maybe, I don't know. Maybe we need a specific aggregation tutorial for those who don't know how to? Those who have operational and technical reasons not to aggregate have made that decision with prior knowledge. We should try and give everyone else the knowledge, then at least we will know that all de-aggregation is done for a reason. Then it begs the question, is NANOG the conference actually reaching the people who'd most benefit from it? I say this as I'm in transit in Singapore heading back from a hugely successful and enjoyable SANOG (South Asia NOG) in Bangladesh. Similar idea to NANOG, but heavier emphasis on education (workshops tutorials), and we had ISPs falling over themselves to participate in the first Internet operations meeting held in that country. philip --
Re: The Cidr Report
On Feb 13, 2005, at 2:36 AM, Jerry Pasker wrote: Pick the top 1 or two worst offenders every week, and automatically dump them into a route distribution server would work in the same way as the Team Cymru bogon server list. I bet THAT would get people to scramble aggregate! Want to make a clear business case for spending time to clean up routes? How about global routability ? Great idea. Too bad the networks at the top of the list are exactly the networks we would need to implement the filtering for it to really hurt. I can't see them filtering themselves -- TTFN, patrick
Re: The Cidr Report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 13, 2005, at 6:19 PM, Christopher L. Morrow wrote: On Sun, 13 Feb 2005, Michael Smith wrote: From: Warren Kumari, Ph.D, CCIE# 9190 [EMAIL PROTECTED] On Feb 13, 2005, at 2:31 AM, Christopher L. Morrow wrote: That and the I have 1 circuit to $good_provider and 1 circuit to $bad_provider and the only way I can make them balance is to split my space in half and announce more specifics out through each provider argument. I have also often seen people do this without announcing the aggregate because some undefined bad thing will happen, usually justified with much hand-waving. The people who do this can usually not be reasoned with So, say I'm a provider that has received a /22 from UUNet (just for example Chris :-) ) and I now get another transit provider and announce the /22 there. So, I call UUNet and ask them to announce the /22 as a more specific Meaning you have PA space from UUNET, and you have BGP so you can multi-home... I'd expect you to know how to deaggregate yourself. You MIGHT even know how to send no-export on deaggregated prefixes, or use the 1996 policies to influence preferences/prepends internal to 701, yes? because I don't want a de-facto asymmetric configuration. I *want* to get a /20 from ARIN but my usage doesn't justify it yet, so I have to ride the /22 for some time. I'm not clear as to how the /22 to /20 discussion goes, or how it's even relevant... but it's been a long day. Can you elaborate? By the long string of anecdotal attacks in the string to date, listing most or all such providers as bad or uninformed how do you separate out those providers who are legitimately interested in routing redundancy and not clue a /22 in both directions seems like safe 'redundancy'. Adding no-export /24's or /32's if you want (yuck) would get you more preference inside one provider or the other. I'm also fairly sure I didn't say: bad or uniformed the 'bad provider' is from Warren, not I. Whoops, I guess I wasn't very clear. By $good_provider and $bad_provider I wasn't meaning to imply that $good_provider ran their network better or cleaner than $bad_provider, merely that (by default and without tuning) more traffic travels via $good_provider than via $bad_provider (e.g. $bad_provider buys transit from $good_provider). I guess I should have used big_provider and little_provider or something. impaired? Do we just say too bad, routing table bloat is more important than your need for redundancy small guy!? No, I don't think anybody was saying that, just that many people are needlessly de-aggregating space. I have seen someone with a single T3 (and obviously a single provider!) announcing his PA /19 as a bunch of /24s, redistributed into BGP from OSPF! Some consultant had come in, set it up and left. After a bit of help, said person turned off BGP and has been running fine ever since. No-one was trying to take away your redundancy, just limit the number of unnecessary announcements. See Chris's comments above on how to get redundancy without making others pay for it I think that folks have been pushed toward multihoming with multiple providers (not just 'redundant T1' or 'shadow T1' services inside the same provider) over the last few years. That means some bloat is bound to occur. I'm not measuring it myself, but the renesys folks and LCS folks have been I think? Perhaps they can comment on that phenomenon? I find it interesting that the general theme is one of we're smarter than they are because we aggregate more routes as if clue were directly correlated to aggregated routing announcements. Well, often lack of aggregation is directly caused by lacy of clue. Obviously there are legitimate reasons for de-aggregating a big block (otherwise we would all just carry 0/0 :-) ) but if there is no additional information in the more specifics, then there is no reason for them the be announced. it's not? :) (joking of course) As I said before some folks feel they have a legitimate reason for deaggregating. If you can spend some time chatting them up about their reasons and either: 1) realizing they hav a point 2) re-purpose their thoughts toward 'better cidr management' (as pfs said) then good for you... and everyone else :) I have spent sometime on occasion doing this, sometimes it works out, othertimes it doesn't :( It's always an experience though. It certainly is... -Chris - -- Militant Agnostic--I don't know and you don't either! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCEAWZHSkNr4ucEScRAoz3AKD6qP+le+n38KEodea6WsoWB/av9gCdH/bu 4YG3VVrMNd/61Lr5ZZBgnRY= =/Ebs -END PGP SIGNATURE-
RE: The Cidr Report
Mike, It seems to me they get paid to carry prefixes by their customers. And their peers listen to the prefixes because they make money by using those prefixes. I'm sure this type of statement helps drug dealers to sleep at night! :-) If the top 100 AS's de-aggregated and increased the routes they announce by 6000 each would we be so content? However, if you are the one filtering and all your competitors figure out how to handle 154,000 routes then you will be at a competitive disadvantage. But its not just 154,000 routes though is it?! If we all start doing this at a much increased rate [as we've seen in recent times] then it will be more like 1,540,000 routes. When we cleaned the issue from 8220 we found that a lot of the issues were config issues and ancient history transient workarounds for problems that were not fixed after the event. The issue we see is bad aggregation - the root cause is bad practise and processes that manifest into bad aggregation. I would argue that networks with poor aggregation are also networks that will tend to have more routeing issues and other outages although I have no data to back that claim up. Coincidentally, the largest networks also spend the most with their vendors and get to tell the vendors what they want in the next generation of boxes they buy. And look how well that's worked out not notably on this issue. Regards, Neil.
RE: The Cidr Report
Commercial reasons? The traffic goes to the 32x/24 instead of the /19. If that's the reason why the table is growing so much then we are all in deep deep trouble.
Re: The Cidr Report
Neil J. McRae said the following on 12/02/2005 21:06: The issue we see is bad aggregation - the root cause is bad practise and processes that manifest into bad aggregation. I would argue that networks with poor aggregation are also networks that will tend to have more routeing issues and other outages although I have no data to back that claim up. I think it depends on which part of the world you look in. But I've visited enough ISPs in the last 7 years in my part of the world (outside US and Western Europe) to know that this is an accurate statement. Again, no data to back this experience up. Neil J. McRae said the following on 12/02/2005 21:07: Commercial reasons? The traffic goes to the 32x/24 instead of the /19. If that's the reason why the table is growing so much then we are all in deep deep trouble. Quite often many service providers are de-aggregating without knowing it. They receive their /20 or whatever from the RIR, but they consider this to be 16 Class Cs - I'm not joking - and announce them as such to the Internet. I spend a lot of time getting these folks to announce aggregates, but it is hard work convincing people that this will even work. Even if the RIR recommends that they announce their address block, they still consider it as Class Cs - even Class Bs for some big allocations. :( Solution is education, but the industry is such in many parts of the world that education is not desired but considered a negative reflection on people's abilities, whether they have the abilities or not. And the lack of educators - there are several of us on the worldwide NOG trail but it's very clear we are not enough. Nor do the NOGs cover the ISP industry, but just those who are interested in participating. We are not enough due to lack of time, lack of supportive employers, more focus on making profit in these leaner times, etc... Where next I don't know... philip --
Re: The Cidr Report
Hi Philip, On Sat, 12 Feb 2005, Philip Smith wrote: Quite often many service providers are de-aggregating without knowing it. They receive their /20 or whatever from the RIR, but they consider this to be 16 Class Cs - I'm not joking - and announce them as such to the Internet. I spend a lot of time getting these folks to announce aggregates, but it is hard work convincing people that this will even work. Even if the RIR recommends that they announce their address block, they still consider it as Class Cs - even Class Bs for some big allocations. :( this is getting into what i was implying earlier.. you have wider experience than me - would you agree that most of the poor deaggregating is not intentional ie that they're announcing their '16 class Cs' or historically had 2 /21s and dont even realise they could fix it.. that applies to medium and large providers too reading this list - how often do they actually check what prefixes they are sourcing, from my recent work at a couple of european IXes i had a number of folks email me offlist as they hadnt realised til I sent out an email they had deaggregation and once it was pointed out they just fixed it. so to repeat my earlier suggestion - if transit providers, particularly the larger ones setup scripts to notify their customers daily/weeks of routing deaggregation do you think we might gain some traction in educating and fixing this? Steve
Re: The Cidr Report
On Sat, 12 Feb 2005, Stephen J. Wilcox wrote: this is getting into what i was implying earlier.. you have wider experience than me - would you agree that most of the poor deaggregating is not intentional ie that they're announcing their '16 class Cs' or historically had 2 /21s and dont even realise they could fix it.. that applies to medium and large providers too reading this list - how often do they actually check what prefixes they are sourcing, from my recent work at a couple of european IXes i had a number of folks email me offlist as they hadnt realised til I sent out an email they had deaggregation and once it was pointed out they just fixed it. so to repeat my earlier suggestion - if transit providers, particularly the larger ones setup scripts to notify their customers daily/weeks of routing deaggregation do you think we might gain some traction in educating and fixing this? Why does it have to be transit providers (customer relationship, so it's not spam? :) Anyone could look at the global table (or just take the CIDR Report data) and automate emailing the ASN contacts for each ASN a list of what they're announcing and a list of the routes they probably should be announcing instead. I've personally dealt with a customer not too long ago who when we turned them up was announcing 2 /20s, a /21, a /22, and several /23s and /24s all deaggregated as /24s. Sprint and Qwest (their other upstreams at the time) apparently had no problem with this. I saw what they were doing and asked them why. That's how our router consultant set it up. There was no technical reason for it. I helped them reaggregate their BGP announcements. I'll bet there are at least hundreds of similar AS's that just need to be prodded (or maybe even some hand holding or config help) in order to clean up their announcements. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: The Cidr Report
On Sat, 12 Feb 2005, Philip Smith wrote: From my own Routing Report (due out in a couple of hours), a quick glance shows that the vast majority of the increase comes from ASNs assigned by ARIN (the ASNs from the other three registry regions show minimal increase in announcements). Duh! No suprise there. ARIN just gives IP space and only offers some measly online training: http://www.arin.net/library/training/index.html RIPE on the other hand, has 3-6 course a month, throughout Europe: http://www.ripe.net/training/lir/index.html http://www.ripe.net/cgi-bin/courselist.pl.cgi APNIC also has a number of courses and goes out to where it is needed: http://www.apnic.net/training/schedule.html As long as ARIN just doles out IP space with no education, the routing table will continue to grow. -Hank Most seem to come from AS4323. Today they are announcing 2606 prefixes, a week ago they were announcing 844 prefixes. philip
Re: The Cidr Report
On Sat, 12 Feb 2005, Jon Lewis wrote: I've personally dealt with a customer not too long ago who when we turned them up was announcing 2 /20s, a /21, a /22, and several /23s and /24s all deaggregated as /24s. Sprint and Qwest (their other upstreams at the time) apparently had no problem with this. I saw what they were doing and asked them why. That's how our router consultant set it up. There was no technical reason for it. I helped them reaggregate their BGP announcements. I'll bet there are at least hundreds of similar AS's that just need to be prodded (or maybe even some hand holding or config help) in order to clean up their announcements. It would appear that ARIN education is somehow lacking in regards to their paying membership. -Hank [see my previous post] -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: The Cidr Report
On Sat, 12 February 2005 14:58:42 +, Stephen J. Wilcox wrote: From: Stephen J. Wilcox [EMAIL PROTECTED] [...] - would you agree that most of the poor deaggregating is not intentional ie that they're announcing their '16 class Cs' or historically had 2 /21s and Think about someone putting in a Null0 route and re- exporting stuff unconditionally, now after he originates his /19 he is then adding a /24 here, and a /25 there. Lack of experience, when you suggest to them they should remove these announcements they are afraid to change it, not understanding the implications, etc. Not to mention ppl using cisco and prefix lists, it is way too easy with cisco to say '/19 le 24', and then they use outbound prefix lists to their transit supplier (different, but related as I see it). Some transit ISPs use that a lot, and encourage the table growth. Also I think a further problem is (from experience) some content hosters wanting to bleed (right word?) /24's to their providers, even though their ratio is 10:1 or more and inbound traffic is not exactly relevant. Too often it makes no sense, and I am speaking of the '32* /24 is a /19' version, mind you, sometimes not even announcing the supernet... Seeing the larger DSL prefixes in Europe then in Europe what do we conclude? See for 3352 or 3269 (sorry)... But when we try to measure (de-) aggregation by continent it gets tricky... (and I believe I know winner and loser) I am not sure doing it the Swisscom way (they filter a lot) is the way to go, yet I would be curious how many routes they currently carry for a full route set. Ah, here it is: - route-views.oregon-ix.netsh ip bg su | incl 3303 164.128.32.11 4 3303 3351176 140593 7403748100 2w2d69713 - I have a hard time argueing this topic with customers, and I have the feeling I am not the only one. We are past that already, I feel. so to repeat my earlier suggestion - if transit providers, particularly the larger ones setup scripts to notify their customers daily/weeks of routing deaggregation do you think we might gain some traction in educating and fixing this? That may be a way to go actually. Like the mail for what prefixes are lacking a route: object that one might just send to customers, not to peers... (5430 peers surely remember) Alexander
Re: The Cidr Report
Alexander Koch wrote: I am not sure doing it the Swisscom way (they filter a lot) is the way to go, yet I would be curious how many routes they currently carry for a full route set. Ah, here it is: - route-views.oregon-ix.netsh ip bg su | incl 3303 164.128.32.11 4 3303 3351176 140593 74037481 0 0 2w2d 69713 - Since you mentioned it: http://www.ip-plus.net/technical/route_filtering_policy.en.html Additionally you might want to see the slides of André Chapuis' presentation held at SwiNOG #7: http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt Pro's and con's, of course. But I guess Swisscom is still living with 128 Meg ;-) Fredy Kuenzler Init Seven AG / AS13030
Re: The Cidr Report
At 02:52 PM 2/12/2005, Fredy Kuenzler wrote: Alexander Koch wrote: I am not sure doing it the Swisscom way (they filter a lot) is the way to go, yet I would be curious how many routes they currently carry for a full route set. Ah, here it is: - route-views.oregon-ix.netsh ip bg su | incl 3303 164.128.32.11 4 3303 3351176 140593 74037481 0 0 2w2d 69713 - Since you mentioned it: http://www.ip-plus.net/technical/route_filtering_policy.en.html Additionally you might want to see the slides of André Chapuis' presentation held at SwiNOG #7: http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt Pro's and con's, of course. But I guess Swisscom is still living with 128 Meg ;-) If that list is current, they're also living without connectivity to many networks on the Internet (entire /8's missing). ;) Vinny Abello Network Engineer Server Management [EMAIL PROTECTED] (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN There are 10 kinds of people in the world. Those who understand binary and those that don't.
Re: The Cidr Report
I split my Routing Analysis based on registry region so that the constituents of each region know what is going on in their area. As you know registries offer training if their membership ask for it. APNIC and RIPE NCC membership seem to ask for training other than just how to be an LIR. But how to be an LIR doesn't cover every single ASN who is announcing address space. For example, APNIC has an extensive region wide programme, but there is still large deaggregation here in the AP region... So I really don't see what RIR training has to do with this. It helps, but it isn't the complete solution. If the industry is worried, the industry has to do something about it. philip -- Hank Nussbacher said the following on 13/02/2005 04:16: Duh! No suprise there. ARIN just gives IP space and only offers some measly online training: http://www.arin.net/library/training/index.html RIPE on the other hand, has 3-6 course a month, throughout Europe: http://www.ripe.net/training/lir/index.html http://www.ripe.net/cgi-bin/courselist.pl.cgi APNIC also has a number of courses and goes out to where it is needed: http://www.apnic.net/training/schedule.html As long as ARIN just doles out IP space with no education, the routing table will continue to grow. -Hank Most seem to come from AS4323. Today they are announcing 2606 prefixes, a week ago they were announcing 844 prefixes. philip
Re: The Cidr Report
Hi Stephen, Stephen J. Wilcox said the following on 13/02/2005 00:58: that applies to medium and large providers too reading this list - how often do they actually check what prefixes they are sourcing, from my recent work at a couple of european IXes i had a number of folks email me offlist as they hadnt realised til I sent out an email they had deaggregation and once it was pointed out they just fixed it. I don't think many people have the time to check customers deaggregation - it doesn't obviously help with their company's business/profits therefore isn't on the radar. Or is a job done when they have time. Like you, Hank and I (amongst many others) have spent quite a bit of time pointing out possible leakages to providers - and most have been very polite and appreciative of the advice. I've had a few negative reactions, mostly questioning why this is any of my business. :( so to repeat my earlier suggestion - if transit providers, particularly the larger ones setup scripts to notify their customers daily/weeks of routing deaggregation do you think we might gain some traction in educating and fixing this? Interesting thought - yes that might help, but then how many providers would be willing to do this? The CIDR report website is available, anyone can pop their ASN into the tool there, and they can figure out what needs to be aggregated. Should the tool be packaged up as something anyone can run from their web page, or a cron job? What would customers think about this if their upstreams do it? Or should some third party do it, like Geoff and I post our respective regional reports and aggregation summaries...? How would this differ from spam - and anyway, how would be get in touch with every ISP on the Internet... etc... philip --
Re: The Cidr Report
On Sat, 12 Feb 2005, Alexander Koch wrote: On Sat, 12 February 2005 14:58:42 +, Stephen J. Wilcox wrote: From: Stephen J. Wilcox [EMAIL PROTECTED] [...] - would you agree that most of the poor deaggregating is not intentional ie that they're announcing their '16 class Cs' or historically had 2 /21s and Think about someone putting in a Null0 route and re- exporting stuff unconditionally, now after he originates his /19 he is then adding a /24 here, and a /25 there. Lack of experience, when you suggest to them they should remove these announcements they are afraid to change it, not understanding the implications, etc. Not to mention ppl using cisco and prefix lists, it is way too easy with cisco to say '/19 le 24', and then they use outbound prefix lists to their transit supplier (different, but related as I see it). Some transit ISPs use that a lot, and encourage the table growth. There are some business reasons to de-aggregate. Look at some outages caused by 'routing problems' (someone leaked my /24's to their peers, peers, peer and my traffic got blackholed, because the public net only knows me as a /20) There are multiple reasons for deaggregation aside from 'dumb operator', some are even 'valid' if you look at them from the protection standpoint. -Chris
Re: The Cidr Report
Until there's deep shame, or real financial incentive to not being listed as a member of the dirty 30, nothing is going to happen in terms of aggregation. Unfortunately, an automated email going out to each of the dirty 30 weekly from the Cidr Report saying that their network again made the list of top 30 most shameful examples of how to participate as an active member in the global routing table would probably have little effect. If they cared, they'd already be doing something about it. Nothing is going to happen unless enough people (ASNs) take a simultaneous, and UNITED stand, and make it painful for those that don't care about the routes they leak to the net. Here's an idea, it's probably not the best idea, and has a *lot* of potential problems, but it's just an idea: Pick the top 1 or two worst offenders every week, and automatically dump them into a route distribution server would work in the same way as the Team Cymru bogon server list. I bet THAT would get people to scramble aggregate! Want to make a clear business case for spending time to clean up routes? How about global routability ? Every week, the top of the list would be singled out, and they could be placed on the server, and anyone that wanted to null route them based on that information could do so. A level of automation would be required to quickly remove them from the blacklist as soon as they aggregated, and quickly re-add them without warning if they decide to deaggregate within a certain time frame of being on the blacklist. If the addition/removal was automated, it would be clear cut as to why the victim was placed on the list. No favoritism or politics would come in to play. It would get results. I'm not sure what those results would be, and the result might just be a bunch of really mad and aggravated people, and a slightly more broken internet, but there'd definitely be results. Or something.;-) (I bet it would be a lot like the early days of DNS-RBL for mail servers) I'm sure someone on this list who is wiser than me, has a better idea. I'd love to hear it discussed. I'm going to repeat what I typed earlier: Nothing is going to happen unless enough people (ASNs) take a simultaneous, and UNITED stand, and make it painful for those that don't care about the routes they leak to the net. -Jerry
RE: The Cidr Report
Recent Table History Date PrefixesCIDR Agg 04-02-05151613 103143 05-02-05152142 103736 06-02-05152231 103721 07-02-05152353 103830 08-02-05152514 103966 09-02-05153855 104090 10-02-05154283 104246 11-02-05154341 104240 ... ~ +3000 routes in one week? Anyone else frightened by this? Florian
RE: The Cidr Report
~ +3000 routes in one week? Anyone else frightened by this? Only people who have stock in vendors welcome it. Be prepared for another huge glut of unnecessary outages, hardware and memory upgrades soon folks! FYI - at $job [AS8220] we have just completed a program to fix the aggregation problem that we had. It took about 10 weeks to complete and I will present a paper on this at LINX 48 next week. Regards, Neil.
RE: The Cidr Report
On Fri, 11 Feb 2005, Frotzler, Florian wrote: Recent Table History Date PrefixesCIDR Agg 04-02-05151613 103143 05-02-05152142 103736 06-02-05152231 103721 07-02-05152353 103830 08-02-05152514 103966 09-02-05153855 104090 10-02-05154283 104246 11-02-05154341 104240 ... ~ +3000 routes in one week? Anyone else frightened by this? Florian any thoughts on how to fix it? my peers keep sending these to me and i'll even admit my customers do too. telling people its bad doesnt appear to have an effect, at the small end networks seem to collect /24s and announce them freely, at the large end i'm still without an explanation as to why large networks require so many prefixes - none of them seem to comment? if people arent self policing it seems the only other way is for the larger transit providers to stop accepting prefixes and telling their customers to fix their s**t. and i dont see them doing this. Steve
RE: The Cidr Report
any thoughts on how to fix it? my peers keep sending these to me and i'll even admit my customers do too. telling people its bad doesnt appear to have an effect, at the small end networks seem to collect /24s and announce them freely, at the large end i'm still without an explanation as to why large networks require so many prefixes - none of them seem to comment? if people arent self policing it seems the only other way is for the larger transit providers to stop accepting prefixes and telling their customers to fix their s**t. and i dont see them doing this. proxy aggregation if they don't fix it. Neil.
Re: The Cidr Report
Frotzler, Florian said the following on 11/02/2005 21:31: Recent Table History Date PrefixesCIDR Agg 04-02-05151613 103143 05-02-05152142 103736 06-02-05152231 103721 07-02-05152353 103830 08-02-05152514 103966 09-02-05153855 104090 10-02-05154283 104246 11-02-05154341 104240 ~ +3000 routes in one week? Anyone else frightened by this? Yup. From my own Routing Report (due out in a couple of hours), a quick glance shows that the vast majority of the increase comes from ASNs assigned by ARIN (the ASNs from the other three registry regions show minimal increase in announcements). Most seem to come from AS4323. Today they are announcing 2606 prefixes, a week ago they were announcing 844 prefixes. philip --
RE: The Cidr Report
I noticed a large jump in prefixes from 4323 this week as well. -Chris -Original Message- From: Philip Smith [mailto:[EMAIL PROTECTED] Sent: Friday, February 11, 2005 4:00 PM To: nanog@merit.edu Subject: Re: The Cidr Report Frotzler, Florian said the following on 11/02/2005 21:31: Recent Table History Date PrefixesCIDR Agg 04-02-05151613 103143 05-02-05152142 103736 06-02-05152231 103721 07-02-05152353 103830 08-02-05152514 103966 09-02-05153855 104090 10-02-05154283 104246 11-02-05154341 104240 ~ +3000 routes in one week? Anyone else frightened by this? Yup. From my own Routing Report (due out in a couple of hours), a quick glance shows that the vast majority of the increase comes from ASNs assigned by ARIN (the ASNs from the other three registry regions show minimal increase in announcements). Most seem to come from AS4323. Today they are announcing 2606 prefixes, a week ago they were announcing 844 prefixes. philip --
RE: The Cidr Report
On Fri, 11 Feb 2005, Neil J. McRae wrote: ~ +3000 routes in one week? Anyone else frightened by this? Only people who have stock in vendors welcome it. Be prepared for another huge glut of unnecessary outages, hardware and memory upgrades soon folks! Actually, from a quick look at the following: http://www.cidr-report.org/as4637/aggrweek.html http://www.cidr-report.org/as4637/as-announce.txt http://www.cidr-report.org/as4637/as-wdl.txt either I'm misreading the data, or the script that generates the email is broken and giving wrong numbers of total routes. FWIW, my I'm not seeing any more than 152843 routes in the global table...but I reject anything longer than /24. According to the weekly agg in the first link, there are 151999 routes in the table today and were 151889 on 11Feb05, which is the date the emailed report goes up to. According to the weekly add/withdraw data, 1732 routes were added and 1964 routes were withdrawn, a decrease of 232 routes in the week, and looking at the aggrweek.html page gives a net decrease of 232 routes for the week (12Feb05 - 05Feb05). Time Warner apparently had some sort of deaggregation accident where they went from 962 nets on 07Feb05 to 2238 routes 08Feb05, 2602 routes 09Feb05, and finally back down to 1031 on 11Feb05. Anyone know what happened there? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: The Cidr Report
On Fri, 11 Feb 2005, Stephen J. Wilcox wrote: On Fri, 11 Feb 2005, Frotzler, Florian wrote: Recent Table History Date PrefixesCIDR Agg 04-02-05151613 103143 05-02-05152142 103736 06-02-05152231 103721 07-02-05152353 103830 08-02-05152514 103966 09-02-05153855 104090 10-02-05154283 104246 11-02-05154341 104240 ... ~ +3000 routes in one week? Anyone else frightened by this? Florian any thoughts on how to fix it? my peers keep sending these to me and i'll even admit my customers do too. telling people its bad doesnt appear to have an effect, at the small end networks seem to collect /24s and announce them freely, at the large end i'm still without an explanation as to why large networks require so many prefixes - none of them seem to comment? if people arent self policing it seems the only other way is for the larger transit providers to stop accepting prefixes and telling their customers to fix their s**t. and i dont see them doing this. It seems to me they get paid to carry prefixes by their customers. And their peers listen to the prefixes because they make money by using those prefixes. So, to the extent you make money listening to them, use the routes. And if they start to cause you problems you will have to take corrective action to stablize your network, as was done a long time ago (internet time): http://www.merit.edu/mail.archives/nanog/1995-09/msg00047.html (link grabbed at random from the archives, I'm sure there are better posts that actually list the full old school sprint filters.) However, if you are the one filtering and all your competitors figure out how to handle 154,000 routes then you will be at a competitive disadvantage. Coincidentally, the largest networks also spend the most with their vendors and get to tell the vendors what they want in the next generation of boxes they buy. Mike. +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
Re: The Cidr Report
Hello Stephen, any thoughts on how to fix it? back to the smallest allocation per /8 that the RIRs have published and make it part of the MoU at the larger NAPs/exchange points. at the large end i'm still without an explanation as to why large networks require so many prefixes - none of them seem to comment? Commercial reasons? The traffic goes to the 32x/24 instead of the /19. Not to mention the BGP customer may go to another provider. You end up in discussions (if you get that chance at all) with your sales group and look like a dogmatic fool as other companies do this. Saving the world works best if the pain is no one's fault - at least not my fault ;-) Regards, Marc -- Marc Binderberger[EMAIL PROTECTED]
RE: The Cidr Report
On Fri, 11 Feb 2005, Mike Leber wrote: On Fri, 11 Feb 2005, Stephen J. Wilcox wrote: On Fri, 11 Feb 2005, Frotzler, Florian wrote: Recent Table History Date PrefixesCIDR Agg 04-02-05151613 103143 05-02-05152142 103736 06-02-05152231 103721 07-02-05152353 103830 08-02-05152514 103966 09-02-05153855 104090 10-02-05154283 104246 11-02-05154341 104240 ... ~ +3000 routes in one week? Anyone else frightened by this? Florian any thoughts on how to fix it? my peers keep sending these to me and i'll even admit my customers do too. telling people its bad doesnt appear to have an effect, at the small end networks seem to collect /24s and announce them freely, at the large end i'm still without an explanation as to why large networks require so many prefixes - none of them seem to comment? if people arent self policing it seems the only other way is for the larger transit providers to stop accepting prefixes and telling their customers to fix their s**t. and i dont see them doing this. It seems to me they get paid to carry prefixes by their customers. the payment would be the same if it was a /19 or 32x/24 announced at source And their peers listen to the prefixes because they make money by using those prefixes. So, to the extent you make money listening to them, use the routes. so the problem is noone wants to be the first to jump as it costs money? so whats the suggestion for how to not be first? ie is it possible for a small group of large operators to agree a consensus? you dont even have to actively filter to start this, if a script were run to advise customers daily when they were announcing routes incompliant to the transits 'routing policy' it would have some effect. one thing i've found from some of my customers is they're actually ignorant to the problems they cause, they think its cool to announce 10 prefixes and can be educated otherwise. Steve And if they start to cause you problems you will have to take corrective action to stablize your network, as was done a long time ago (internet time): http://www.merit.edu/mail.archives/nanog/1995-09/msg00047.html (link grabbed at random from the archives, I'm sure there are better posts that actually list the full old school sprint filters.) However, if you are the one filtering and all your competitors figure out how to handle 154,000 routes then you will be at a competitive disadvantage. Coincidentally, the largest networks also spend the most with their vendors and get to tell the vendors what they want in the next generation of boxes they buy. Mike. +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
Re: The Cidr Report
Correct on 'knee' but for crying out loud, follow the pointy clicky references to the website. Of course there isn't going to be a curve in email [you want ascii plots? how 1980s], but the email quite clearly points you the way to the site where there is some analysis of the raw data. My bad ;-) But I include the CIDR reports website in my complaint about data versus information. Yes it does have SOME analysis and that is good. But the way it is presented overwhelms one with data and obscures the point of the website. Also, I somehow missed the URL for the plot that you posted even though I've been to this website several times. In fact, it shows that when Cengiz/Packeteer presented the findings showing almost no growth, the routing table was about to begin growing again at the same rate as prior to the telecom collapse. Packeteer's data did get a certain amount of press coverage, Lightreading for instance, so maybe that's why most people stopped looking at how to control routing table growth. However, CAIDA did make a presentation about atoms in the AS path last fall http://www.caida.org/projects/routing/atoms/documents/atoms-widew0311.pdf If only everyone ran their BGP processes on servers rather than routers, people could actually begin using this now because the code is available http://www.caida.org/projects/routing/atoms/ Now that, whether you agree with the approach or not, is definitely something new in regards to managing routing table growth. --Michael Dillon
Re: The Cidr Report
- this month, another knee was at 150k [Dec 4th] and similarly garbled results came out. Again, no response. ...in this one year we've seen the shape of the climb return to the curve characterized by two years 99-01. Going for e? I'm not quite sure what the current point of the report is if no-one responds to even it breaking. Knee? Shape? Curve? Are you reading the same CIDR report that I see here every Friday? The report that I see is basically a dump of raw data. Perhaps the author needs to remember the distinction between data and information and make the CIDR report into something that people *WANT* to read. This posting of yours contained far more information than any CIDR report. Those believing otherwise are encouraged to send real, hard data. There is no meaningful data I can find since the Bellovin/Bush/ Griffin/Rexford 2001 paper. I don't know why people like to post cryptic references to documents or meetings etc. Perhaps there is an implicit desire to hide it from outsiders who are not part of the secret inner circle? Perhaps this type of behavior is at the root of the growing problems, i.e. clue is not being spread around because people are too cliquish in the way that they present this info. I'm not talking about NANOG meetings here, just the list, which arguably reaches more people than the meetings. Now, on to Bellovin et al. Janet Rexford wrote this paper on filtering http://www.research.att.com/~jrex/papers/filter.pdf This was presented at NANOG but the NANOG site here http://www.nanog.org/mtg-0105/prefix.html points to Janet's site here http://www.research.att.com/~jrex/nanog/lost.html (note the word LOST in the URL) which points to Randy's slides here http://psg.com/~randy/010521.nanog/ unfortunately those appear to be lost... But there is some video from IETF 51 here http://videolab.uoregon.edu/events/ietf/ietf51.html which might be the same stuff. Bush talks on Routing Issues. One would think that if the problems noted in 2001 are not being solved, then perhaps a review of this material might prove more fruitful than more studies of the data. According to the plot here http://www.cidr-report.org/ the average announcements per origin AS has actually taken a turn for the better. And the chart of the BGP table here http://bgp.potaroo.net/ seems more like a power curve than the exponential curve prior to 2001. --Michael Dillon --Michael Dillon
Re: The Cidr Report
More on BGP table size and the number of fragmentary announcements in the Internet http://www.tm.uka.de/idrws/2004/contributions2004/IDRWS2004--04--Huston_Geoff--Allocations_and_Advertisements.pdf This is Geoff Huston's presentation at the Inter-Domain Routing Workshop in May 2004. Slides for all the other talks here http://www.tm.uka.de/idrws/2004/contributions2004/ I suggest that if people find this stuff useful, they might want to ask the authors to provide an update at the next NANOG meeting. As for Joe's lament about no new studies, I think that after it was pointed out that BGP table growth had halted http://www.netsys.com/library/papers/cengiz-bgp-2002-08.pdf many people probably thought that the problem had been solved forever by the telecom collapse. --Michael Dillon
Re: The Cidr Report
On Dec 13, 2004, at 6:39 AM, [EMAIL PROTECTED] wrote: - this month, another knee was at 150k [Dec 4th] and similarly garbled results came out. Again, no response. ...in this one year we've seen the shape of the climb return to the curve characterized by two years 99-01. Going for e? I'm not quite sure what the current point of the report is if no-one responds to even it breaking. Knee? Shape? Curve? Are you reading the same CIDR report that I see here every Friday? The report that I see is basically a dump of raw data. Perhaps the author needs to remember the distinction between data and information and make the CIDR report into something that people *WANT* to read. This posting of yours contained far more information than any CIDR report. The author is providing a service by giving us raw data. If that is all they want to do, we cannot (and should not) force them to do more. Besides, I like raw data. :-) Also, as for the knee Joe mentioned, I think he is talking about the fact the report went wonky. Look at the data presented in the last CIDR report - it is nonsense, obviously in error. This is not the shape of the curve, it is the data itself. -- TTFN, patrick
Re: The Cidr Report
On Mon, Dec 13, 2004 at 01:08:39PM -0500, Patrick W Gilmore wrote: On Dec 13, 2004, at 6:39 AM, [EMAIL PROTECTED] wrote: [my attribution clipped -jzp] - this month, another knee was at 150k [Dec 4th] and similarly garbled results came out. Again, no response. ...in this one year we've seen the shape of the climb return to the curve characterized by two years 99-01. Going for e? I'm not quite sure what the current point of the report is if no-one responds to even it breaking. Knee? Shape? Curve? Are you reading the same CIDR report that I see here every Friday? The report that I see is basically a dump of raw data. Perhaps the author needs to remember the distinction between data and information and make the CIDR report into something that people *WANT* to read. This posting of yours contained far more information than any CIDR report. [snip] Also, as for the knee Joe mentioned, I think he is talking about the fact the report went wonky. Look at the data presented in the last CIDR report - it is nonsense, obviously in error. This is not the shape of the curve, it is the data itself. Correct on 'knee' but for crying out loud, follow the pointy clicky references to the website. Of course there isn't going to be a curve in email [you want ascii plots? how 1980s], but the email quite clearly points you the way to the site where there is some analysis of the raw data. For many of us, the mail is a reminder 'here's the current raw info, check the detailed stuff over here'. There is no secret cabal or hidden ionfo, the report email Joe, finding it a sad state of affairs that he must cut and paste http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas4637%2fbgp%2dactive%2etxtdescr=Active%20BGP%20entries%20%28FIB%29ylabel=Active%20BGP%20entries%20%28FIB%29with=step; into this message for people to actually look at the graph. PS 2001 bellovin bush griffin rexford entered into google hits the specific reference quite nicely - sorry i didn't include the title. as michael pointed out the specific links migrate all the time, so i was purposefully avoiding 'where it can be found at this moment' [try http://www.research.att.com/~jrex/papers/filter.pdf] -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: The Cidr Report
[This was started last month. been a little busy. unsuprisingly I only had to *add* an incident and it still works.] On Fri, Nov 12, 2004 at 02:47:30PM -0800, Randy Bush wrote: [snip] Yes it means what you think. No, I don't see anyone giving a rat's patootie about aggregation. I was starting to think I was the only one still reading the reports. Had a half-written rant each time interesting events happened, just been too busy. In recent months: - on the 4th-5th of November, the (reported) table bloated by ~9k pfefixes overnight. not an eyebrow raised. - when the table bloated over 140k, just this last July, the report was hosed at the end of a cycle obviously hit its own MAXINT. Not a comment from regular report readers, nor even a mocking Nelson Ha-Haw post by those taking the actions. - this month, another knee was at 150k [Dec 4th] and similarly garbled results came out. Again, no response. ...in this one year we've seen the shape of the climb return to the curve characterized by two years 99-01. Going for e? I'm not quite sure what the current point of the report is if no-one responds to even it breaking. I never saw a single post following up to to the actual purpose and policy issues from October's aggregation table entries thread. Other than the specifics of multihomed customers and RPF issues, my point about segregation of internal and externaal policies and the reflection in the announce used vs announce allocated was neither agreed, refuted, nor even commented further. I have seen deaggregators claim 'security' [shred the routing table in response to windows worms scanning their classical-B], or assume that if Some Other Company can base their entire business plan on moving the costs of 'optimized' deaggregation onto the global community (beyond their providers), then why can't they. When I'm feeling conspiracy-minded, it seems that those of a certain size are trying to squeeze the smaller folks out of the business by encouraging the behavior of bloat. But then I correct the angle of my tinfoil beanie and realize they are just lazy. Their laziness does directly cost any newly-multihoming enterprises; some of the networks who are contributing to the garbage still tell customers that full tables will fit into 128M on a cisco. (eg, http://www.sprintlink.net/support/bgp_request.html) It is disappointing and frankly I can't see a way past it. When 2914 finally slid down to the lowest common denominator, the last 'big stick' was gone. 1239 is unapologetically violating their own customer bgp policies in this regard (point 9 on http://www.sprintlink.net/policy/bgp.html). The list goes on and on. Otherwise reasonable people have refuted logic and claim adding more data into the system doesn't increase churn effect and thereby degrade stability. Control theory and structured programming be damned, they say it hasn't melted yet. Perhaps they want to see if they can make Metcalfe's predict come true, just 10 years too early? The baseline expectation is that the DFZ carries rechability data. Any more-specific data of interest is exchanged between parties who want it, request it, or pay for it. Being conservative in what you send also applies to anticipating *others* not being liberal in what they receive. There's a whole lot of non-conservative senders out there, and when they have reachability problems of their own making, with simple and trivial fixes if they had only thought things through in the first place, they have no-one but themselves to blame. Those believing otherwise are encouraged to send real, hard data. There is no meaningful data I can find since the Bellovin/Bush/ Griffin/Rexford 2001 paper. Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: The Cidr Report
Daniel Roesen writes: Well, it boils down that if you have enough customers, you seem to get away with about any antisocial behaviour on the net. You don't need to have many customers, it's just more fun if you have a larger space that you can deaggregate. Since everybody stopped filtering you can deaggregate everything into /24s today and get away with it. So as soon as you have a /23 you can play. And there are just too many valid reasons to resist. Around here most ISPs, when they announce new customer routes, send mail to their peers saying we will announce these prefixes under these paths, please update your filters. I often respond with a friendly note that we will filter this or that prefix because it's a more specific of a PA prefix (which we will actually do, although it doesn't matter that much since we always have a fallback). Sometimes I offer to put in a temporary (usually a year) filter exception so that they can renumber their new customer into aggregatable space. It doesn't help often, but sometimes it does. Think globally, act locally. -- Simon.
Re: The Cidr Report
On Sat, Nov 13, 2004 at 03:31:26AM +, Christopher L. Morrow wrote: [snip] Of these listed 4 are cable companies, is there something in the cable modem networking that requires deaggregated routes beyond their borders? No, for the general statement about 'cable modem networking'. Is the problem that they might have seperate 'networks' for their regional parts and leak more specifics for these parts along with 'backup' routes via aggregates? This is trivial to do only as far as your $s carry. Aggregate draws the traffic, then NO_EXPORT-tagged longest-match carries the regionalized traffic. Folks do this as a 'best exit' approach between peer netwworks all the time. If you are suggesting disjoint, unconnected islands, then they should be separate ASNs for sane paths; see charter's islands, the pre-271 refleif ILEC LATA-bound islands, etc. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
RE: The Cidr Report
You have jumped to the conclusion that a customer of the cable company is not multi-homed. Bad assumption. I can tell you that there are multihomed customers behind what you would normally think of as a cable company. Roy Engehausen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christopher L. Morrow Sent: Friday, November 12, 2004 7:31 PM To: Randy Bush Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: The Cidr Report Of these listed 4 are cable companies, is there something in the cable modem networking that requires deaggregated routes beyond their borders? Is the problem that they might have seperate 'networks' for their regional parts and leak more specifics for these parts along with 'backup' routes via aggregates?
Re: The Cidr Report
At 02:47 PM 12-11-04 -0800, Randy Bush wrote: ASnumNetsNow NetsAggr NetGain % Gain Description AS18566 7516 74599.2% CVAD Covad Communications AS4134 825 178 64778.4% CHINANET-BACKBONE No.31,Jin-rong Street AS4323 794 223 57171.9% TWTC Time Warner Telecom AS6197 814 430 38447.2% BNS-14 BellSouth Network Solutions, Inc AS22773 401 17 38495.8% CXA Cox Communications Inc. AS27364 413 45 36889.1% ARMC Armstrong Cable Services AS701 1230 884 34628.1% UU UUNET Technologies, Inc. AS22909 412 81 33180.3% CMCS Comcast Cable Communications, Inc. are these numbers what i think, but hope not, they are? e.g. is AS18566 the origin AS for 751 prefixes that could be collapsed to 6? Barry and me tried: http://www.nanog.org/mtg-0302/cidr.html Covad was first contacted Aug 2002: ASnumNetsNow NetsCIDR NetGain % Gain Description AS18566 264 4 260 98.5%COVAD Covad Communications But Covad was just one. I used to quietly contact these pollutors along with a few others who helped out (Barry and Terry) but as of a year ago I'm giving my 5-10 hours of volunteerism per month to nsp-sec. -Hank if not, then perhaps the report could use some work. if so, then o why are providers indulging is such extremely sick behavior o and who can hack the perl to generate filters for this so we can listen only to the aggregates randy
Re: The Cidr Report
On Nov 13, 2004, at 10:18 AM, Roy wrote: You have jumped to the conclusion that a customer of the cable company is not multi-homed. Bad assumption. I can tell you that there are multihomed customers behind what you would normally think of as a cable company. You have assumed that they assumed. Bad assumption. Most of those deaggregated CIDRs do not show up behind any other AS. Nor are they in another AS. If they are multi-homed, at least one, and hopefully both of those properties would hold. -- TTFN, patrick
Re: The Cidr Report
At 09:47 AM 13/11/2004, Randy Bush wrote: ASnumNetsNow NetsAggr NetGain % Gain Description AS18566 7516 74599.2% CVAD Covad Communications are these numbers what i think, but hope not, they are? e.g. is AS18566 the origin AS for 751 prefixes that could be collapsed to 6? yup - see http://www.cidr-report.org/cgi-bin/as-report?as=AS18566view=4637 if not, then perhaps the report could use some work. I'm more than happy to do further work on this report to improve its accuracy and helpfulness to the operator community, but in this case I'm not sure what such work would be, as I believe that the report is accurate about the potential level of prefix removal at a global BGP level. Geoff
Re: The Cidr Report
e.g. is AS18566 the origin AS for 751 prefixes that could be collapsed to 6? Sort of - from here it looks like they aren't actually announcing the supernets. The covering /162, /15 and /14 aggregates are being globally announced, and the more specifics are being announced from the same origin AS, apparently along the same AS paths as the specifics, so its not clear that there is any form of traffic engineering or load balancing going on. regards, Geoff o and who can hack the perl to generate filters for this so we can listen only to the aggregates I don't see their stuff listed in the radb, so it looks like you have to go to the router itself to read the routes to determine what they are announcing, then ask the appropriate registry which block they are announcing from, aggregate the routes in that block, rinse and repeat, aggregate the aggregated blocks, then filter. ..but that only works if they announce the supernets. Without that I'm not sure what you can do that wouldn't end up biting you back. It's also a lot of work for not too much reward as long as these messes are the exception and not the rule. Plus the public hand slap is kind of amusing. But that's probably just me. Austin
RE: The Cidr Report
Interestingly enough what Covad appears to be saying is: If we had a way to announce two things 1 - here are the advertisements for covering aggregates for Covad AND 2 - do not believe any more specifics for these address blocks, as they are NOT part of Covad's routing policy for these prefixes then we would not be seeing this unfortunate case of unauthorized route leakage being resolved in a way that seems to have unfortunate bgp implications in terms of more specifics appearing. So its an interesting question. How could Covad achieve a routing policy announcement of the form as stated in 2 above? regards, Geoff
RE: The Cidr Report
Interestingly enough what Covad appears to be saying is: If we had a way to announce two things 1 - here are the advertisements for covering aggregates for Covad AND 2 - do not believe any more specifics for these address blocks, as they are NOT part of Covad's routing policy for these prefixes then we would not be seeing this unfortunate case of unauthorized route leakage being resolved in a way that seems to have unfortunate bgp implications in terms of more specifics appearing. So its an interesting question. How could Covad achieve a routing policy announcement of the form as stated in 2 above? register the covering prefixes in the irr and folk should filter. folk who don't filter are welcome to the results. i encourage my competitors not to filter. randy
Re: The Cidr Report
On (13/11/04 16:38), Randy Bush wrote: register the covering prefixes in the irr and folk should filter. folk who don't filter are welcome to the results. i encourage my competitors not to filter. it won't be your competitors who suffer though...it would be the networks that someone is trying to hijack that would see traffic/reachability problems. granted this would be limited in scope to those networks which are not filtering, but as we have seen numberous times on this list and others, filtering isn't universal or equally applied. while i don't agree with the methodology covad is using, i can understand their position. and if it had happened to me, i probably would have done the same, albeit for a shorter time frame...you and i are free to filter our networks as we see fit (or are contractually obligated), so if you want to filter at /18, go for it. i however will urge everyone (especially my competitors) to filter because it is good for them and good for me. /joshua -- END NANOG CENSORSHIP FREE RAS FREE WILCO
RE: The Cidr Report
On Sat, 13 Nov 2004, Roy wrote: You have jumped to the conclusion that a customer of the cable company is not multi-homed. Bad assumption. I can tell you that there are multihomed customers behind what you would normally think of as a cable company. I'm not sure I did jump to that conclusion, and most (all?) of the prefixes I looked at (quickly as they scrolled) had an originating ASN of 18665 or whichever was covad. Either way, that would account for a few, not all, of their deaggregated routes. Roy Engehausen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christopher L. Morrow Sent: Friday, November 12, 2004 7:31 PM To: Randy Bush Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: The Cidr Report Of these listed 4 are cable companies, is there something in the cable modem networking that requires deaggregated routes beyond their borders? Is the problem that they might have seperate 'networks' for their regional parts and leak more specifics for these parts along with 'backup' routes via aggregates?
Re: The Cidr Report
ASnumNetsNow NetsAggr NetGain % Gain Description AS18566 7516 74599.2% CVAD Covad Communications AS4134 825 178 64778.4% CHINANET-BACKBONE No.31,Jin-rong Street AS4323 794 223 57171.9% TWTC Time Warner Telecom AS6197 814 430 38447.2% BNS-14 BellSouth Network Solutions, Inc AS22773 401 17 38495.8% CXA Cox Communications Inc. AS27364 413 45 36889.1% ARMC Armstrong Cable Services AS701 1230 884 34628.1% UU UUNET Technologies, Inc. AS22909 412 81 33180.3% CMCS Comcast Cable Communications, Inc. are these numbers what i think, but hope not, they are? e.g. is AS18566 the origin AS for 751 prefixes that could be collapsed to 6? if not, then perhaps the report could use some work. if so, then o why are providers indulging is such extremely sick behavior o and who can hack the perl to generate filters for this so we can listen only to the aggregates randy
Re: The Cidr Report
On Fri, 12 Nov 2004, Randy Bush wrote: ASnumNetsNow NetsAggr NetGain % Gain Description AS18566 7516 74599.2% CVAD Covad Communications AS4134 825 178 64778.4% CHINANET-BACKBONE No.31,Jin-rong Street AS4323 794 223 57171.9% TWTC Time Warner Telecom AS6197 814 430 38447.2% BNS-14 BellSouth Network Solutions, Inc AS22773 401 17 38495.8% CXA Cox Communications Inc. AS27364 413 45 36889.1% ARMC Armstrong Cable Services AS701 1230 884 34628.1% UU UUNET Technologies, Inc. AS22909 412 81 33180.3% CMCS Comcast Cable Communications, Inc. are these numbers what i think, but hope not, they are? e.g. is AS18566 the origin AS for 751 prefixes that could be collapsed to 6? if not, then perhaps the report could use some work. if so, then o why are providers indulging is such extremely sick behavior not to justify the expense, but perhaps covad is renumbering from one block to another? Looking at their advertisments I see lots of /23 or /24 blocks inside their larger covering routes... So either they deaggregated to renumber more gracefully, or they forgot their prefix-list outbound to williams and exodus ? perhaps covad can explain? or silently cover up the 'mistake' (which is acceptable as well...)
Re: The Cidr Report
On Fri, Nov 12, 2004 at 02:47:30PM -0800, Randy Bush wrote: ASnumNetsNow NetsAggr NetGain % Gain Description AS18566 7516 74599.2% CVAD Covad Communications are these numbers what i think, but hope not, they are? e.g. is AS18566 the origin AS for 751 prefixes that could be collapsed to 6? Sort of - from here it looks like they aren't actually announcing the supernets. o and who can hack the perl to generate filters for this so we can listen only to the aggregates I don't see their stuff listed in the radb, so it looks like you have to go to the router itself to read the routes to determine what they are announcing, then ask the appropriate registry which block they are announcing from, aggregate the routes in that block, rinse and repeat, aggregate the aggregated blocks, then filter. ..but that only works if they announce the supernets. Without that I'm not sure what you can do that wouldn't end up biting you back. It's also a lot of work for not too much reward as long as these messes are the exception and not the rule. Plus the public hand slap is kind of amusing. But that's probably just me. Austin
Re: The Cidr Report
On Fri, Nov 12, 2004 at 04:23:29PM -0800, Austin Schutz wrote: ASnumNetsNow NetsAggr NetGain % Gain Description AS18566 7516 74599.2% CVAD Covad Communications are these numbers what i think, but hope not, they are? e.g. is AS18566 the origin AS for 751 prefixes that could be collapsed to 6? Sort of - from here it looks like they aren't actually announcing the supernets. So you don't see: 64.105.0.0/16 66.134.0.0/16 66.166.0.0/15 67.100.0.0/14 68.164.0.0/14 69.3.0.0/16 ? I don't see their stuff listed in the radb, They actually did register all that more-specific crap (determined by checking some 10 samples), so they do this fully intentional. Well, it boils down that if you have enough customers, you seem to get away with about any antisocial behaviour on the net. Plus the public hand slap is kind of amusing. But that's probably just me. The problem is that they probably couldn't care less. There is no public sanctioning and pressure. Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
RE: The Cidr Report
[snip] ASnumNetsNow NetsAggr NetGain % Gain Description AS18566 7516 74599.2% CVAD Covad Communications [snip] not to justify the expense, but perhaps covad is renumbering from one block to another? Looking at their advertisments I see lots of /23 or /24 blocks inside their larger covering routes... So either they deaggregated to renumber more gracefully, or they forgot their prefix-list outbound to williams and exodus ? perhaps covad can explain? or silently cover up the 'mistake' (which is acceptable as well...) I've been secretly hoping no one would notice Covad's ascension to the number one spot (which we've held for well over a month now ;). I actually made it through the last NANOG without a single mention of Covad's route bloat! There are no mistakes or excuses here. And there's definitely no renumbering going on. We were actually fully aggregated until an unfortunate incident this past May involving a distant service provider leaking our specifics. Gigs of traffic somehow vanished into Eastern Europe. The net result was deaggregation. It's unlikely we will aggregate down to less than 10 netblocks again. However, we do make every effort to aggregate where possible. Our superblocks are also being advertised, for those of you that want to filter our routes. Want to discuss further? Great. Call me or email me directly. Contact info is below. Think you can do it better? Even better. It turns out I'm hiring. :) Regards, Brad -- Covad Communications 408-434-2048 [EMAIL PROTECTED]
Re: The Cidr Report
ASnumNetsNow NetsAggr NetGain % Gain Description AS18566 7516 74599.2% CVAD Covad Communications AS4134 825 178 64778.4% CHINANET-BACKBONE No.31,Jin-rong Street AS4323 794 223 57171.9% TWTC Time Warner Telecom AS6197 814 430 38447.2% BNS-14 BellSouth Network Solutions, Inc AS22773 401 17 38495.8% CXA Cox Communications Inc. AS27364 413 45 36889.1% ARMC Armstrong Cable Services AS701 1230 884 34628.1% UU UUNET Technologies, Inc. AS22909 412 81 33180.3% CMCS Comcast Cable Communications, Inc. e.g. is AS18566 the origin AS for 751 prefixes that could be collapsed to 6? not to justify the expense, but perhaps covad is renumbering from one block to another? Looking at their advertisments I see lots of /23 or /24 blocks inside their larger covering routes... So either they deaggregated to renumber more gracefully, or they forgot their prefix-list outbound to williams and exodus ? perhaps covad can explain? or silently cover up the 'mistake' (which is acceptable as well...) it's not just covad. they're just such an egregious case among many socially and technically irresponsible polluters. randy
RE: The Cidr Report
geoff, your proggy already knows what filter list(s) would keep us from carrying the polluters' rubbish. any chance you could generate the filter code for juniper, procket, and cisco so automated router builds could fetch it with batch wget or ncftp or whatever? another cutie would be if whovever is maintaining peval this week could add an option to not deliver covered prefixes from the same origin? no slur intended on any particular polluter. but i think what we have here is the strafing of the commons. enough is enough. randy
Re: The Cidr Report
On Sat, 13 Nov 2004, Daniel Roesen wrote: On Fri, Nov 12, 2004 at 04:23:29PM -0800, Austin Schutz wrote: ASnumNetsNow NetsAggr NetGain % Gain Description AS18566 7516 74599.2% CVAD Covad Communications are these numbers what i think, but hope not, they are? e.g. is AS18566 the origin AS for 751 prefixes that could be collapsed to 6? Sort of - from here it looks like they aren't actually announcing the supernets. So you don't see: 64.105.0.0/16 66.134.0.0/16 66.166.0.0/15 67.100.0.0/14 68.164.0.0/14 69.3.0.0/16 ? there are still places on the net that do odd-ball filtering... perhaps he lives in one? (or nets from one?) (he being austin...) Plus the public hand slap is kind of amusing. But that's probably just me. The problem is that they probably couldn't care less. There is no public sanctioning and pressure. and like I said, they MIGHT have a valid reason for this. I seem to remember a cable company a few months back doing this during a renumber, or some migration... I was hoping Covad would stand up, or someone who knows more (and has less of an axe to grind?), and set the record straight. Or, 'just make it go away' and leave randy/daniel/austin to wonder what happened :) Either way, so long as it stops, right?
RE: The Cidr Report
thanks brad :) atleast some answer was provided. On Fri, 12 Nov 2004, Roldan, Brad wrote: There are no mistakes or excuses here. And there's definitely no renumbering going on. We were actually fully aggregated until an unfortunate incident this past May involving a distant service provider leaking our specifics. Gigs of traffic somehow vanished into Eastern Europe. The net result was deaggregation. so, because someone 'hijacked' your more specifics you deaggregated entirely? Makes the 'everyone should prefix filter customers' talk sound more relevant everyday.
Re: The Cidr Report
On Fri, 12 Nov 2004, Randy Bush wrote: ASnumNetsNow NetsAggr NetGain % Gain Description AS18566 7516 74599.2% CVAD Covad Communications AS4134 825 178 64778.4% CHINANET-BACKBONE No.31,Jin-rong Street AS4323 794 223 57171.9% TWTC Time Warner Telecom AS6197 814 430 38447.2% BNS-14 BellSouth Network Solutions, Inc AS22773 401 17 38495.8% CXA Cox Communications Inc. AS27364 413 45 36889.1% ARMC Armstrong Cable Services AS701 1230 884 34628.1% UU UUNET Technologies, Inc. AS22909 412 81 33180.3% CMCS Comcast Cable Communications, Inc. e.g. is AS18566 the origin AS for 751 prefixes that could be collapsed to 6? not to justify the expense, but perhaps covad is renumbering from one block to another? Looking at their advertisments I see lots of /23 or /24 blocks inside their larger covering routes... So either they deaggregated to renumber more gracefully, or they forgot their prefix-list outbound to williams and exodus ? perhaps covad can explain? or silently cover up the 'mistake' (which is acceptable as well...) it's not just covad. they're just such an egregious case among many socially and technically irresponsible polluters. eh, since I singled out covad: (and I feel bad for it now) what about for COX? what about for UU (doh, thats me...or our tac or something, I'll look/ask), what about Comcast? and TWTC? ArmStrong? Of these listed 4 are cable companies, is there something in the cable modem networking that requires deaggregated routes beyond their borders? Is the problem that they might have seperate 'networks' for their regional parts and leak more specifics for these parts along with 'backup' routes via aggregates? -Chris
Re: The Cidr Report
eh, since I singled out covad: (and I feel bad for it now) what about for COX? what about for UU (doh, thats me...or our tac or something, I'll look/ask) thanks! randy
Re: The Cidr Report
On Nov 5, 2004, at 6:00 AM, [EMAIL PROTECTED] wrote: Recent Table History Date PrefixesCIDR Agg [...] 05-11-04156315 103781 Well, we broke 150K prefixes - and without someone deaggregating the classical B space. :) Impressive. Remember when the 'Net was supposed to have fallen over before now? Pat yourselves on the back everyone, you did the impossible. Congratulations are in order. -- TTFN, patrick
yo, savvis, cox, comcast, and armstrong! (Re: The Cidr Report)
[EMAIL PROTECTED] writes:
This report has been generated at Fri Jun 4 21:43:44 2004 AEST.
...
Recent Table History
Date PrefixesCIDR Agg
...
03-06-04137774 96139
04-06-04137884 95196
ok, so in one day we saw the addition of 110 prefixes, but they were aligned
such that the size of a properly cidr-aggregated table dropped by 943. this
is quite a trick. what does it all mean?
...
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
and who's doing it?
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 136767951724159530.4% All ASes
AS6347 940 160 78083.0% SAVV SAVVIS Communications
Corporation
yo, savvis! you're putting 940 routes into the global routing table, and
when somebody did sort -u on the as-paths, they found that with no change
to your transit policies, you could be sending just 160 instead. help?
AS22909 390 33 35791.5% CMCS Comcast Cable
Communications, Inc.
yo, comcast!
AS22773 378 58 32084.7% CXAB Cox Communications Inc.
Atlanta
AS27364 360 44 31687.8% ARMC Armstrong Cable Services
yo, cox and armstrong!
AS11172 351 56 29584.0% Servicios Alestra S.A de C.V
AS17676 339 50 28985.3% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS9929 316 33 28389.6% CNCNET-CN China Netcom Corp.
AS6478 305 48 25784.3% ATTW ATT WorldNet Services
AS25844 243 16 22793.4% SASMFL-2 Skadden, Arps, Slate,
Meagher Flom LLP
AS14654 2305 22597.8% WAYPOR-3 Wayport
AS6327 208 28 18086.5% SHAWC-2 Shaw Communications
Inc.
yo! yo! yo! (i've only listed those who could reduce their impact on the
global routing table by 80% or more... as you all saw, the list *was* longer.)
there are any number of unemployed bgp experts haunting this mailing list
looking for post-dotbomb work. many of them would accept work as short term
consultants to help you folks get down under the 80% level. just ask!
--
Paul Vixie
Re: yo, savvis, cox, comcast, and armstrong! (Re: The Cidr Report)
yeah, we(being savvis) are aware. this will all disappear when AS6347
is integrated to AS3561. AS3561 is, for the most part clean, and it
will stay that way. AS6347 will drop off the map in the coming months.
have patience. ;-)
thx,
mark
Paul Vixie wrote:
[EMAIL PROTECTED] writes:
This report has been generated at Fri Jun 4 21:43:44 2004 AEST.
...
Recent Table History
Date PrefixesCIDR Agg
...
03-06-04137774 96139
04-06-04137884 95196
ok, so in one day we saw the addition of 110 prefixes, but they were aligned
such that the size of a properly cidr-aggregated table dropped by 943. this
is quite a trick. what does it all mean?
...
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
and who's doing it?
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 136767951724159530.4% All ASes
AS6347 940 160 78083.0% SAVV SAVVIS Communications
Corporation
yo, savvis! you're putting 940 routes into the global routing table, and
when somebody did sort -u on the as-paths, they found that with no change
to your transit policies, you could be sending just 160 instead. help?
AS22909 390 33 35791.5% CMCS Comcast Cable
Communications, Inc.
yo, comcast!
AS22773 378 58 32084.7% CXAB Cox Communications Inc.
Atlanta
AS27364 360 44 31687.8% ARMC Armstrong Cable Services
yo, cox and armstrong!
AS11172 351 56 29584.0% Servicios Alestra S.A de C.V
AS17676 339 50 28985.3% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS9929 316 33 28389.6% CNCNET-CN China Netcom Corp.
AS6478 305 48 25784.3% ATTW ATT WorldNet Services
AS25844 243 16 22793.4% SASMFL-2 Skadden, Arps, Slate,
Meagher Flom LLP
AS14654 2305 22597.8% WAYPOR-3 Wayport
AS6327 208 28 18086.5% SHAWC-2 Shaw Communications
Inc.
yo! yo! yo! (i've only listed those who could reduce their impact on the
global routing table by 80% or more... as you all saw, the list *was* longer.)
there are any number of unemployed bgp experts haunting this mailing list
looking for post-dotbomb work. many of them would accept work as short term
consultants to help you folks get down under the 80% level. just ask!
Re: The Cidr Report
Last June I promised here that AS13345 was working on the issues preventing aggregation internally Top 20 Net Decreased Routes per Originating AS Prefixes Change ASnum AS Description -36 91-55 AS13345 RKCI Rockynet.com, Inc We're not done yet, but did make the biggest possible gains in the last week.
Re: The Cidr Report
On Mar 19, 2004, at 9:00 AM, Mike Lewinski wrote: Last June I promised here that AS13345 was working on the issues preventing aggregation internally Top 20 Net Decreased Routes per Originating AS Prefixes Change ASnum AS Description -36 91-55 AS13345 RKCI Rockynet.com, Inc We're not done yet, but did make the biggest possible gains in the last week. I'd just like to publicly thank and commend anyone who spends what we all know are limited time and resources on this. -- TTFN, patrick
Re: The Cidr Report
So anyway, was discussing the cidr report at the last nanog.. I was pointing out
that deaggregation is discouraged by the naming and shaming and then someone
else pointed out that this list has scarcely altered in months.
So, what can we do as the operator community if this report isnt having the
desired effect?
Steve
On Fri, 14 Nov 2003, [EMAIL PROTECTED] wrote:
This report has been generated at Fri Nov 14 21:48:00 2003 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
07-11-03127597 90282
08-11-03127873 90220
09-11-03127555 90261
10-11-03127607 90361
11-11-03127817 90325
12-11-03127745 90342
13-11-03127842 90301
14-11-03127686 90402
AS Summary
16121 Number of ASes in routing system
6426 Number of ASes announcing only one prefix
1410 Largest number of prefixes announced by an AS
AS701 : ALTERNET-AS UUNET Technologies, Inc.
73534720 Largest address span announced by an AS (/32s)
AS568 : SUMNET-AS DISO-UNRRA
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 14Nov03 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 127709903473736229.3% All ASes
AS4323 687 201 48670.7% TW-COMM Time Warner
Communications, Inc.
AS701 1410 979 43130.6% ALTERNET-AS UUNET
Technologies, Inc.
AS7018 1367 948 41930.7% ATT-INTERNET4 ATT WorldNet
Services
AS7843 526 122 40476.8% ADELPHIA-AS Adelphia Corp.
AS6197 641 261 38059.3% BATI-ATL BellSouth Network
Solutions, Inc
AS6198 611 253 35858.6% BATI-MIA BellSouth Network
Solutions, Inc
AS209880 536 34439.1% ASN-QWEST Qwest
AS22909 3119 30297.1% DNEO-OSP1 Comcast Cable
Communications, Inc.
AS4355 386 101 28573.8% ERMS-EARTHLNK EARTHLINK, INC
AS22773 305 25 28091.8% CCINET-2 Cox Communications
Inc. Atlanta
AS27364 338 72 26678.7% ACS-INTERNET Armstrong Cable
Services
AS6347 349 85 26475.6% DIAMOND SAVVIS Communications
Corporation
AS1221 955 693 26227.4% ASN-TELSTRA Telstra Pty Ltd
AS1239 928 671 25727.7% SPRINTLINK Sprint
AS17676 278 35 24387.4% GIGAINFRA Softbank BB Corp.
AS4134 363 125 23865.6% CHINANET-BACKBONE
No.31,Jin-rong Street
AS25844 243 16 22793.4% SKADDEN1 Skadden, Arps, Slate,
Meagher Flom LLP
AS9583 275 81 19470.5% SATYAMNET-AS Satyam Infoway
Ltd.,
AS11305 229 38 19183.4% INTERLAND-NET1 Interland
Incorporated
AS2386 397 214 18346.1% INS-AS ATT Data
Communications Services
AS4519 193 12 18193.8% MAAS Maas Communications
AS9498 210 32 17884.8% BBIL-AP BHARTI BT INTERNET
LTD.
AS6140 340 164 17651.8% IMPSAT-USA ImpSat
AS6327 203 27 17686.7% SHAW Shaw Communications Inc.
AS14654 1752 17398.9% WAYPORT Wayport
AS2048 252 86 16665.9% LANET-1 State of Louisiana
AS7132 472 308 16434.7% SBIS-AS SBC Internet Services
- Southwest
AS20115 584 424 16027.4% CHARTER-NET-HKY-NC Charter
Communications
AS9929 192 36 15681.2% CNCNET-CN China Netcom Corp.
AS15270 202 48 154
Re: The Cidr Report
On Fri, 14 Nov 2003, Suresh Ramasubramanian wrote: Stephen J. Wilcox writes on 11/14/2003 7:16 AM: So anyway, was discussing the cidr report at the last nanog.. I was pointing out that deaggregation is discouraged by the naming and shaming and then someone else pointed out that this list has scarcely altered in months. So, what can we do as the operator community if this report isnt having the desired effect? Stop accepting /24 type routes? Yeah maybe but what about where the RIRs have assigned independent /24 space.. or ISPs have subdelegated the IPs to a multihomed customer, was more thinking about where a bunch of routes originating from a single ASN can be aggregated rather than routing bloat in general. There are numerous such examples of people with eg a /19 announcing 32x /24 etc Steve
RE: The Cidr Report
On Fri, 14 Nov 2003, Suresh Ramasubramanian wrote: Stephen J. Wilcox writes on 11/14/2003 7:16 AM: So anyway, was discussing the cidr report at the last nanog.. I was pointing out that deaggregation is discouraged by the naming and shaming and then someone else pointed out that this list has scarcely altered in months. So, what can we do as the operator community if this report isnt having the desired effect? Stop accepting /24 type routes? Please no... That will drop me off the map.. Yeah maybe but what about where the RIRs have assigned independent /24 space.. or ISPs have subdelegated the IPs to a multihomed customer, was more thinking about where a bunch of routes originating from a single ASN can be aggregated rather than routing bloat in general. There are numerous such examples of people with eg a /19 announcing 32x /24 etc Steve I don't have the stats handy at the moment, but we decided to Multi-home I researched several issues with /24 blocks. One thing that seemed to stick out was that some providers were using /20 and /21 as multi-home blocks. They were reserving that block just for /24 multi-homing.. and I also remember that of the /24 being annouced independently, a majority of them were not multihomed... just how bad is the auto-summarization at the upstream for the route propagation via BGP in the large routers anyway? Jim
Re: The Cidr Report
On 14 Nov 2003, at 14:41, McBurnett, Jim wrote: just how bad is the auto-summarization at the upstream for the route propagation via BGP in the large routers anyway? What auto-summarisation? If you're talking about the cisco auto-summary command, then the answer is so bad that it's universally disabled (but then auto-summary is concerned with aggregation on pre-CIDR, classful boundaries which I don't think is what you were talking about). Absent a precise understanding of all the routing policies concerned, proxy aggregation is dangerous and is hence generally not done. Joe
Re: The Cidr Report
Stephen J. Wilcox writes on 11/14/2003 12:54 PM: Yeah maybe but what about where the RIRs have assigned independent /24 space.. or ISPs have subdelegated the IPs to a multihomed customer, was more thinking about where a bunch of routes originating from a single ASN can be aggregated rather than routing bloat in general. There are numerous such examples of people with eg a /19 announcing 32x /24 etc So how do you deal with one but not with the other? -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: The Cidr Report
On Fri, 14 Nov 2003, Suresh Ramasubramanian wrote: Stephen J. Wilcox writes on 11/14/2003 12:54 PM: Yeah maybe but what about where the RIRs have assigned independent /24 space.. or ISPs have subdelegated the IPs to a multihomed customer, was more thinking about where a bunch of routes originating from a single ASN can be aggregated rather than routing bloat in general. There are numerous such examples of people with eg a /19 announcing 32x /24 etc So how do you deal with one but not with the other? I think your confusing my point - they're different questions, legitimate announcement of /24s by multihoming corporates is at least in principal okay. But I do regulary see people announcing consecutive prefixes all originating in the same AS and (from my view) having the same policy. Ok look heres one example, looks like these guys have a /20: Broad Band Networks / ESINET BBNESINET-48 (NET-12-5-48-0-1) 12.5.48.0 - 12.5.55.255 Broad Band Networks / ESINET BROAD-BA16-56 (NET-12-5-56-0-1) 12.5.56.0 - 12.5.59.255 BROAD BAND NETWORK SERVICES BROAD-BA927-60 (NET-12-5-60-0-1) 12.5.60.0 - 12.5.63.255 So why do I see this lot from them? 11 routes where only one would suffice (1100% more than needed for anyone mathematically challenged).. * 12.5.48.0/24 6453 1239 5778 12163 i * 12.5.48.0/21 6453 1239 5778 12163 i * 12.5.49.0/24 6453 1239 5778 12163 i * 12.5.50.0/23 6453 1239 5778 12163 i * 12.5.52.0/24 6453 1239 5778 12163 i * 12.5.54.0/23 6453 1239 5778 12163 i * 12.5.56.0/23 6453 1239 5778 12163 i * 12.5.56.0/22 6453 1239 5778 12163 i * 12.5.58.0/24 6453 1239 5778 12163 i * 12.5.59.0/24 6453 1239 5778 12163 i * 12.5.60.0/22 6453 1239 5778 12163 i I'm sure these arent the worst offenders but they were the first I came across in my sh ip bgp ... So who's job is it to clean this up - I dont think proxy aggregation is a good idea as someone suggested, the only people in a position to fix this are the ISP themselves, their upstreams and their peers. Steve
Re: The Cidr Report
Stephen J. Wilcox writes on 11/14/2003 6:55 PM: So who's job is it to clean this up - I dont think proxy aggregation is a good idea as someone suggested, the only people in a position to fix this are the ISP themselves, their upstreams and their peers. Thank you for making my point for me. Nobody - other than the people actually announcing the routes (and their upstreams and peers) can resolve this problem. So self discipline is the only solution - and that looks like it isn't going to happen anytime soon. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: The Cidr Report
On Fri, 14 Nov 2003, Suresh Ramasubramanian wrote: Stephen J. Wilcox writes on 11/14/2003 6:55 PM: So who's job is it to clean this up - I dont think proxy aggregation is a good idea as someone suggested, the only people in a position to fix this are the ISP themselves, their upstreams and their peers. Thank you for making my point for me. Huh? Your one liner didnt make a point.. ? Nobody - other than the people actually announcing the routes (and their upstreams and peers) can resolve this problem. So self discipline is the only solution - and that looks like it isn't going to happen anytime soon. Erm right but see, thats the problem they're announcing lots of routes they dont need to be and dont have self discipline, they need teaching and its not nobody, other than themselves they have their peers and their upstreams, and their upstreams in particular are going ot have the most control on dictating policy.. Steve
Re: The Cidr Report
On Fri, 07 Nov 2003 22:00:01 +1100, [EMAIL PROTECTED] said: The report analyses the BGP Routing Table of an AS4637 (Reach) router ... Possible Bogus Routes 10.127.32.0/24 AS25186 TRANSIT-VPN-AS France Telecom Transpac's Transit VPN network 10.129.113.0/24 AS25186 TRANSIT-VPN-AS France Telecom Transpac's Transit VPN network 10.129.131.0/24 AS25186 TRANSIT-VPN-AS France Telecom Transpac's Transit VPN network OK.. I'll bite. How many peering points between AS25186 and AS4637 need to drop the ball on BGP filtering before this shows up in the report? pgp0.pgp Description: PGP signature
Re: The Cidr Report
AS209 1097 532 56551.5% ASN-QWEST Qwest It's worth pointing out that Qwest had such a huge jump this week because they are moving from AS2908 to AS209 in their 14 state ILEC area. Thanks, Adam Debus Linux Certified Professional, Linux Certified Administrator #447641 Network Engineer, ReachONE Internet [EMAIL PROTECTED]
Re: The Cidr Report
On my active bogons list I'm also seeing 223.0.0.0/8 ## AS65333 : IANA-RSVD2 : Internet Assigned Numbers Authority 223.0.0.0 - 223.255.255.255 ## Bogon (unallocated) ip range Would that be some kind of experiment? On Fri, 7 Nov 2003 [EMAIL PROTECTED] wrote: On Fri, 07 Nov 2003 22:00:01 +1100, [EMAIL PROTECTED] said: The report analyses the BGP Routing Table of an AS4637 (Reach) router ... Possible Bogus Routes 10.127.32.0/24 AS25186 TRANSIT-VPN-AS France Telecom Transpac's Transit VPN network 10.129.113.0/24 AS25186 TRANSIT-VPN-AS France Telecom Transpac's Transit VPN network 10.129.131.0/24 AS25186 TRANSIT-VPN-AS France Telecom Transpac's Transit VPN network OK.. I'll bite. How many peering points between AS25186 and AS4637 need to drop the ball on BGP filtering before this shows up in the report?
RE: The Cidr Report
Not sure how relevent this may be but:
Interland has recently been in a major network
move
They boight out Communitech and are in the
process of moving datacenters to the Interland
centers..
This could explain it
But they should be doing a better job of it though...
Jim
-Original Message-
From: Hank Nussbacher [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 21, 2003 3:41 PM
To: Haesu; [EMAIL PROTECTED]
Subject: Re: The Cidr Report
At 01:00 PM 21-06-03 -0400, Haesu wrote:
What is up with ASN11305 generating humongous loads of unaggregated /24's?
Sent them an email 11 days ago, no reply yet:
Date: Tue, 10 Jun 2003 10:56:46 +0200
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
From: Hank Nussbacher [EMAIL PROTECTED]
Subject: AS11305 - routing table bloat
Cc: Terry Baranski [EMAIL PROTECTED], [EMAIL PROTECTED]
AS11305 has been lately seen to be sending out too many prefixes not based
on CIDR boundries, thereby increasing the global router table size:
ASnumNetsNow NetsAggr NetGain % Gain Description
AS11305 646 136 51078.9% INTERLAND-NET1 Interland
Incorporated
See http://www.mcvax.org/~jhma/routing/ and http://bgp.potaroo.net/cidr/
and http://bgp.potaroo.net/cgi-bin/as-report?as=as11305view=4637
for further details.
Regards,
Hank
-Hank
-hc
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 20Jun03 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 122681877223495928.5% All ASes
AS7132 923 229 69475.2% SBIS-AS SBC Internet Services
- Southwest
AS11305 647 137 51078.8% INTERLAND-NET1 Interland
Incorporated
AS701 1514 1070 44429.3% ALTERNET-AS UUNET
Technologies, Inc.
AS7843 614 175 43971.5% ADELPHIA-AS Adelphia Corp.
AS4323 600 177 42370.5% TW-COMM Time Warner
Communications, Inc.
AS7018 1337 927 41030.7% ATT-INTERNET4 ATT WorldNet
Services
AS3908 889 521 36841.4% SUPERNETASBLK SuperNet, Inc.
AS1221 1062 756 30628.8% ASN-TELSTRA Telstra Pty Ltd
AS6197 518 225 29356.6% BATI-ATL BellSouth Network
Solutions, Inc
AS4355 397 111 28672.0% ERMS-EARTHLNK EARTHLINK, INC
AS6198 475 189 28660.2% BATI-MIA BellSouth Network
Solutions, Inc
AS1239 959 677 28229.4% SPRINTLINK Sprint
AS6347 367 92 27574.9% DIAMOND SAVVIS Communications
Corporation
AS27364 319 87 23272.7% ACS-INTERNET Armstrong Cable
Services
AS17676 250 24 22690.4% GIGAINFRA XTAGE CORPORATION
AS22773 2208 21296.4% CCINET-2 Cox Communications
Inc. Atlanta
AS209498 305 19338.8% ASN-QWEST Qwest
AS705508 331 17734.8% ALTERNET-AS UUNET
Technologies, Inc.
AS2386 406 235 17142.1% INS-AS ATT Data
Communications Services
AS2048 258 87 17166.3% LANET-1 State of Louisiana
AS17557 341 173 16849.3% PKTELECOM-AS-AP Pakistan
Telecom
AS6327 190 24 16687.4% SHAWFIBER Shaw Fiberlink
Limited
AS13601 205 46 15977.6% ASN-INNERHOST Innerhost, Inc.
AS690450 293 15734.9% MERIT-AS-27 Merit Network
Inc.
AS20115 463 311 15232.8% CHARTER-NET-HKY-NC Charter
Communications
AS3602 226 79 14765.0% SPRINT-CA-AS Sprint Canada
Inc.
AS2686 258 112 14656.6% AS2686 ATT Global Network
Services - EMEA
AS6140 297 155 14247.8% IMPSAT-USA ImpSat
AS7303 238 98 14058.8% AR-TAST-LACNIC Telecom
Re: The Cidr Report
What is up with ASN11305 generating humongous loads of unaggregated /24's?
-hc
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 20Jun03 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 122681877223495928.5% All ASes
AS7132 923 229 69475.2% SBIS-AS SBC Internet Services
- Southwest
AS11305 647 137 51078.8% INTERLAND-NET1 Interland
Incorporated
AS701 1514 1070 44429.3% ALTERNET-AS UUNET
Technologies, Inc.
AS7843 614 175 43971.5% ADELPHIA-AS Adelphia Corp.
AS4323 600 177 42370.5% TW-COMM Time Warner
Communications, Inc.
AS7018 1337 927 41030.7% ATT-INTERNET4 ATT WorldNet
Services
AS3908 889 521 36841.4% SUPERNETASBLK SuperNet, Inc.
AS1221 1062 756 30628.8% ASN-TELSTRA Telstra Pty Ltd
AS6197 518 225 29356.6% BATI-ATL BellSouth Network
Solutions, Inc
AS4355 397 111 28672.0% ERMS-EARTHLNK EARTHLINK, INC
AS6198 475 189 28660.2% BATI-MIA BellSouth Network
Solutions, Inc
AS1239 959 677 28229.4% SPRINTLINK Sprint
AS6347 367 92 27574.9% DIAMOND SAVVIS Communications
Corporation
AS27364 319 87 23272.7% ACS-INTERNET Armstrong Cable
Services
AS17676 250 24 22690.4% GIGAINFRA XTAGE CORPORATION
AS22773 2208 21296.4% CCINET-2 Cox Communications
Inc. Atlanta
AS209498 305 19338.8% ASN-QWEST Qwest
AS705508 331 17734.8% ALTERNET-AS UUNET
Technologies, Inc.
AS2386 406 235 17142.1% INS-AS ATT Data
Communications Services
AS2048 258 87 17166.3% LANET-1 State of Louisiana
AS17557 341 173 16849.3% PKTELECOM-AS-AP Pakistan
Telecom
AS6327 190 24 16687.4% SHAWFIBER Shaw Fiberlink
Limited
AS13601 205 46 15977.6% ASN-INNERHOST Innerhost, Inc.
AS690450 293 15734.9% MERIT-AS-27 Merit Network Inc.
AS20115 463 311 15232.8% CHARTER-NET-HKY-NC Charter
Communications
AS3602 226 79 14765.0% SPRINT-CA-AS Sprint Canada
Inc.
AS2686 258 112 14656.6% AS2686 ATT Global Network
Services - EMEA
AS6140 297 155 14247.8% IMPSAT-USA ImpSat
AS7303 238 98 14058.8% AR-TAST-LACNIC Telecom
Argentina Stet-France Telecom
S.A.
AS14654 1456 13995.9% WAYPORT Wayport
Total 15574 7660 791450.8% Top 30 total
Possible Bogus Routes
24.2.128.0/21AS6478 ATT-INTERNET3 ATT WorldNet Services
24.7.10.0/24 AS6478 ATT-INTERNET3 ATT WorldNet Services
24.11.98.0/24AS6478 ATT-INTERNET3 ATT WorldNet Services
24.14.197.0/24 AS6478 ATT-INTERNET3 ATT WorldNet Services
24.18.132.0/23 AS6478 ATT-INTERNET3 ATT WorldNet Services
24.23.8.0/24 AS6478 ATT-INTERNET3 ATT WorldNet Services
24.119.0.0/16AS11492 CABLEONE CABLE ONE
24.119.66.0/24 AS11492 CABLEONE CABLE ONE
24.180.60.0/24 AS6478 ATT-INTERNET3 ATT WorldNet Services
24.183.185.0/24 AS6478 ATT-INTERNET3 ATT WorldNet Services
24.183.186.0/24 AS6478 ATT-INTERNET3 ATT WorldNet Services
24.183.187.0/24 AS6478 ATT-INTERNET3 ATT WorldNet Services
24.183.188.0/24 AS6478 ATT-INTERNET3 ATT WorldNet Services
24.183.189.0/24 AS6478 ATT-INTERNET3 ATT WorldNet Services
24.183.191.0/24 AS6478 ATT-INTERNET3 ATT WorldNet Services
Re: The Cidr Report
At 01:00 PM 21-06-03 -0400, Haesu wrote:
What is up with ASN11305 generating humongous loads of unaggregated /24's?
Sent them an email 11 days ago, no reply yet:
Date: Tue, 10 Jun 2003 10:56:46 +0200
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
From: Hank Nussbacher [EMAIL PROTECTED]
Subject: AS11305 - routing table bloat
Cc: Terry Baranski [EMAIL PROTECTED], [EMAIL PROTECTED]
AS11305 has been lately seen to be sending out too many prefixes not based
on CIDR boundries, thereby increasing the global router table size:
ASnumNetsNow NetsAggr NetGain % Gain Description
AS11305 646 136 51078.9% INTERLAND-NET1 Interland
Incorporated
See http://www.mcvax.org/~jhma/routing/ and http://bgp.potaroo.net/cidr/
and http://bgp.potaroo.net/cgi-bin/as-report?as=as11305view=4637
for further details.
Regards,
Hank
-Hank
-hc
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 20Jun03 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 122681877223495928.5% All ASes
AS7132 923 229 69475.2% SBIS-AS SBC Internet Services
- Southwest
AS11305 647 137 51078.8% INTERLAND-NET1 Interland
Incorporated
AS701 1514 1070 44429.3% ALTERNET-AS UUNET
Technologies, Inc.
AS7843 614 175 43971.5% ADELPHIA-AS Adelphia Corp.
AS4323 600 177 42370.5% TW-COMM Time Warner
Communications, Inc.
AS7018 1337 927 41030.7% ATT-INTERNET4 ATT WorldNet
Services
AS3908 889 521 36841.4% SUPERNETASBLK SuperNet, Inc.
AS1221 1062 756 30628.8% ASN-TELSTRA Telstra Pty Ltd
AS6197 518 225 29356.6% BATI-ATL BellSouth Network
Solutions, Inc
AS4355 397 111 28672.0% ERMS-EARTHLNK EARTHLINK, INC
AS6198 475 189 28660.2% BATI-MIA BellSouth Network
Solutions, Inc
AS1239 959 677 28229.4% SPRINTLINK Sprint
AS6347 367 92 27574.9% DIAMOND SAVVIS Communications
Corporation
AS27364 319 87 23272.7% ACS-INTERNET Armstrong Cable
Services
AS17676 250 24 22690.4% GIGAINFRA XTAGE CORPORATION
AS22773 2208 21296.4% CCINET-2 Cox Communications
Inc. Atlanta
AS209498 305 19338.8% ASN-QWEST Qwest
AS705508 331 17734.8% ALTERNET-AS UUNET
Technologies, Inc.
AS2386 406 235 17142.1% INS-AS ATT Data
Communications Services
AS2048 258 87 17166.3% LANET-1 State of Louisiana
AS17557 341 173 16849.3% PKTELECOM-AS-AP Pakistan
Telecom
AS6327 190 24 16687.4% SHAWFIBER Shaw Fiberlink
Limited
AS13601 205 46 15977.6% ASN-INNERHOST Innerhost, Inc.
AS690450 293 15734.9% MERIT-AS-27 Merit Network
Inc.
AS20115 463 311 15232.8% CHARTER-NET-HKY-NC Charter
Communications
AS3602 226 79 14765.0% SPRINT-CA-AS Sprint Canada
Inc.
AS2686 258 112 14656.6% AS2686 ATT Global Network
Services - EMEA
AS6140 297 155 14247.8% IMPSAT-USA ImpSat
AS7303 238 98 14058.8% AR-TAST-LACNIC Telecom
Argentina Stet-France
Telecom
S.A.
AS14654 1456 13995.9% WAYPORT Wayport
Total 15574 7660 791450.8% Top 30 total
Possible Bogus Routes
24.2.128.0/21AS6478 ATT-INTERNET3 ATT WorldNet Services
24.7.10.0/24 AS6478 ATT-INTERNET3 ATT WorldNet Services
24.11.98.0/24AS6478 ATT-INTERNET3 ATT WorldNet Services
24.14.197.0/24 AS6478 ATT-INTERNET3 ATT
Re: The Cidr Report
They transit thro Qwest and Cogent. Perhaps its the responsibility of folks
accepting the routes to sanity check and implement sensible policy?
Steve
On Sat, 21 Jun 2003, Hank Nussbacher wrote:
At 01:00 PM 21-06-03 -0400, Haesu wrote:
What is up with ASN11305 generating humongous loads of unaggregated /24's?
Sent them an email 11 days ago, no reply yet:
Date: Tue, 10 Jun 2003 10:56:46 +0200
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
From: Hank Nussbacher [EMAIL PROTECTED]
Subject: AS11305 - routing table bloat
Cc: Terry Baranski [EMAIL PROTECTED], [EMAIL PROTECTED]
AS11305 has been lately seen to be sending out too many prefixes not based
on CIDR boundries, thereby increasing the global router table size:
ASnumNetsNow NetsAggr NetGain % Gain Description
AS11305 646 136 51078.9% INTERLAND-NET1 Interland
Incorporated
See http://www.mcvax.org/~jhma/routing/ and http://bgp.potaroo.net/cidr/
and http://bgp.potaroo.net/cgi-bin/as-report?as=as11305view=4637
for further details.
Regards,
Hank
-Hank
-hc
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 20Jun03 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 122681877223495928.5% All ASes
AS7132 923 229 69475.2% SBIS-AS SBC Internet Services
- Southwest
AS11305 647 137 51078.8% INTERLAND-NET1 Interland
Incorporated
AS701 1514 1070 44429.3% ALTERNET-AS UUNET
Technologies, Inc.
AS7843 614 175 43971.5% ADELPHIA-AS Adelphia Corp.
AS4323 600 177 42370.5% TW-COMM Time Warner
Communications, Inc.
AS7018 1337 927 41030.7% ATT-INTERNET4 ATT WorldNet
Services
AS3908 889 521 36841.4% SUPERNETASBLK SuperNet, Inc.
AS1221 1062 756 30628.8% ASN-TELSTRA Telstra Pty Ltd
AS6197 518 225 29356.6% BATI-ATL BellSouth Network
Solutions, Inc
AS4355 397 111 28672.0% ERMS-EARTHLNK EARTHLINK, INC
AS6198 475 189 28660.2% BATI-MIA BellSouth Network
Solutions, Inc
AS1239 959 677 28229.4% SPRINTLINK Sprint
AS6347 367 92 27574.9% DIAMOND SAVVIS Communications
Corporation
AS27364 319 87 23272.7% ACS-INTERNET Armstrong Cable
Services
AS17676 250 24 22690.4% GIGAINFRA XTAGE CORPORATION
AS22773 2208 21296.4% CCINET-2 Cox Communications
Inc. Atlanta
AS209498 305 19338.8% ASN-QWEST Qwest
AS705508 331 17734.8% ALTERNET-AS UUNET
Technologies, Inc.
AS2386 406 235 17142.1% INS-AS ATT Data
Communications Services
AS2048 258 87 17166.3% LANET-1 State of Louisiana
AS17557 341 173 16849.3% PKTELECOM-AS-AP Pakistan
Telecom
AS6327 190 24 16687.4% SHAWFIBER Shaw Fiberlink
Limited
AS13601 205 46 15977.6% ASN-INNERHOST Innerhost, Inc.
AS690450 293 15734.9% MERIT-AS-27 Merit Network
Inc.
AS20115 463 311 15232.8% CHARTER-NET-HKY-NC Charter
Communications
AS3602 226 79 14765.0% SPRINT-CA-AS Sprint Canada
Inc.
AS2686 258 112 14656.6% AS2686 ATT Global Network
Services - EMEA
AS6140 297 155 14247.8% IMPSAT-USA ImpSat
AS7303 238 98 14058.8% AR-TAST-LACNIC Telecom
Argentina Stet-France
Telecom
S.A.
AS14654 1456 13995.9% WAYPORT Wayport
RE: The Cidr Report
They transit thro Qwest and Cogent. Perhaps its the
responsibility of folks
accepting the routes to sanity check and implement sensible policy?
And the one who filters the customer first will lose revenue..
Kris
On Sat, 21 Jun 2003, Hank Nussbacher wrote:
At 01:00 PM 21-06-03 -0400, Haesu wrote:
What is up with ASN11305 generating humongous loads of
unaggregated /24's?
Sent them an email 11 days ago, no reply yet:
Date: Tue, 10 Jun 2003 10:56:46 +0200
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
From: Hank Nussbacher [EMAIL PROTECTED]
Subject: AS11305 - routing table bloat
Cc: Terry Baranski [EMAIL PROTECTED], [EMAIL PROTECTED]
AS11305 has been lately seen to be sending out too many
prefixes not based
on CIDR boundries, thereby increasing the global router table size:
ASnumNetsNow NetsAggr NetGain % Gain Description
AS11305 646 136 51078.9%
INTERLAND-NET1 Interland
Incorporated
See http://www.mcvax.org/~jhma/routing/ and
http://bgp.potaroo.net/cidr/
and http://bgp.potaroo.net/cgi-bin/as-report?as=as11305view=4637
for further details.
Regards,
Hank
-Hank
-hc
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 20Jun03 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 122681877223495928.5% All ASes
AS7132 923 229 69475.2% SBIS-AS
SBC Internet Services
- Southwest
AS11305 647 137 51078.8%
INTERLAND-NET1 Interland
Incorporated
AS701 1514 1070 44429.3% ALTERNET-AS UUNET
Technologies, Inc.
AS7843 614 175 43971.5%
ADELPHIA-AS Adelphia Corp.
AS4323 600 177 42370.5% TW-COMM
Time Warner
Communications, Inc.
AS7018 1337 927 41030.7%
ATT-INTERNET4 ATT WorldNet
Services
AS3908 889 521 36841.4%
SUPERNETASBLK SuperNet, Inc.
AS1221 1062 756 30628.8%
ASN-TELSTRA Telstra Pty Ltd
AS6197 518 225 29356.6% BATI-ATL
BellSouth Network
Solutions, Inc
AS4355 397 111 28672.0%
ERMS-EARTHLNK EARTHLINK, INC
AS6198 475 189 28660.2% BATI-MIA
BellSouth Network
Solutions, Inc
AS1239 959 677 28229.4% SPRINTLINK Sprint
AS6347 367 92 27574.9% DIAMOND
SAVVIS Communications
Corporation
AS27364 319 87 23272.7%
ACS-INTERNET Armstrong Cable
Services
AS17676 250 24 22690.4% GIGAINFRA
XTAGE CORPORATION
AS22773 2208 21296.4% CCINET-2
Cox Communications
Inc. Atlanta
AS209498 305 19338.8% ASN-QWEST Qwest
AS705508 331 17734.8% ALTERNET-AS UUNET
Technologies, Inc.
AS2386 406 235 17142.1% INS-AS ATT Data
Communications Services
AS2048 258 87 17166.3% LANET-1
State of Louisiana
AS17557 341 173 16849.3%
PKTELECOM-AS-AP Pakistan
Telecom
AS6327 190 24 16687.4% SHAWFIBER
Shaw Fiberlink
Limited
AS13601 205 46 15977.6%
ASN-INNERHOST Innerhost, Inc.
AS690450 293 15734.9%
MERIT-AS-27 Merit Network
Inc.
AS20115 463 311 15232.8%
CHARTER-NET-HKY-NC Charter
Communications
AS3602 226 79 14765.0%
SPRINT-CA-AS Sprint Canada
Inc.
AS2686 258 112 14656.6% AS2686
ATT Global Network
Services - EMEA
AS6140 297 155 14247.8% IMPSAT-USA ImpSat
AS7303 238 98 14058.8%
