September 2001 - Test - lists.nanog.org

The Cidr Report
by CIDR Report 29 Sep '01

29 Sep '01

This is an auto-generated mail on Fri Sep 28 23:00:00 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 28Sep01 0) General Status Table History ------------- Date Prefixes 210901 103625 220901 103684 230901 103666 240901 103680 250901 103629 260901 103632 270901 104968 280901 104483 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 82.105.0.0/16 from AS3269 *** Bogus 82.105.128.0/17 from AS3269 AS Summary ---------- Number of ASes in routing system: 11715 Number of ASes announcing only one prefix: 6979 (3955 cidr, 3024 classful) Largest number of cidr routes: 855 announced by AS701 Largest number of classful routes: 1389 announced by AS701 1) Gains by aggregating at the origin AS level --- 28Sep01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1262 961 301 23.9% Telstra Pty Ltd AS4151 299 171 128 42.8% USDA AS16473 201 76 125 62.2% Bell South AS577 306 187 119 38.9% Bell Advanced Communications Inc. AS13999 132 16 116 87.9% Mega Cable S.A. de C.V. AS6595 170 60 110 64.7% DoD Education Activity Network As AS4293 376 267 109 29.0% Cable & Wireless USA AS2048 209 115 94 45.0% State of Louisiana AS6429 195 102 93 47.7% AT&T Chile Internet S.A. AS4755 213 131 82 38.5% Videsh Sanchar Nigam Ltd. Autonom AS12302 98 28 70 71.4% MobiFon S.A. AS1239 471 402 69 14.6% Sprint AS4200 142 74 68 47.9% Apex Global Information Services, AS6471 128 63 65 50.8% ENTEL CHILE S.A. AS17557 128 65 63 49.2% Pakistan Telecom AS3464 157 96 61 38.9% Alabama SuperComputer Network AS19632 67 9 58 86.6% Metropolis Intercom S.A. AS16758 63 6 57 90.5% IKON Office Solutions AS209 303 248 55 18.2% Qwest AS3908 283 230 53 18.7% Supernet, Inc. AS11686 160 107 53 33.1% Education Networks of America AS226 145 93 52 35.9% Los Nettos AS17561 113 62 51 45.1% Internet service provision to Wes AS1 533 482 51 9.6% BBN Planet AS4323 247 197 50 20.2% Time Warner Communications, Inc. AS306 59 10 49 83.1% National Guard Bureau AS637 104 56 48 46.2% Department of Navy AS10620 68 21 47 69.1% TVCABLE BOGOTA AS1913 151 105 46 30.5% Defense Logistics Agency AS15290 244 199 45 18.4% AT&T Canada IES For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 28 Sep '01

28 Sep '01

| Gimme a break. Arm, leg, neck, spine or ego? | s/the Sprint sales guy calls him and/he calls a Sprint sales guy who/ Clearly you have never ever tried to buy Internet stuff from Sprint! | This would cause depletion of address space faster. That sky hasn't fallen yet, despite the warnings since 1995. | This does not address performance issues. Nobody's perfect. | > 3. the maximum 254 things in the /24 can be renumbered | > into small ISP's PA space and announced to UUWHO | > with a constraining (set of) community(ies) | > | > (NAT, incidentally, was also invented to make renumbering easier) | | All this does is swap the problem around, not solve it. It does: traffic follows the aggregate to some part of the network that knows the secret exception and uses it, even though it does not tell the rest of the world it is doing so. This network either needs to be big, or it needs to leak a constrained more specific out to some of its neighbours, which is a harder problem. Essentially you are creating a wormhole, by analogy with a black hole. "Ad hoc confederation of wormholers" either knows the more specific prefix or follows the PI aggregate around to the small provider, depending on connectivity. Everyone else only knows the PI aggregate and follows that. If the following lands on any "ad hoc confederation of wormholers" router, it follows the privately-known more specific. Geoff Huston has been talking about a community which is useful for doing the most common case of this kind of "ad hoc confederation"-making, even though it's designed to deal with traffic engineering: "announce this longer prefix to everyone receiving money from me". | Why bother, when ISP-X down the street will "just do it"? ... which is ineffectual if people are doing filtering or progressive flap dampening. Sean.

2 1

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by Paul Vixie 28 Sep '01

28 Sep '01

Here we go again, but isolated and clearly this time: > Sprint had valid reasons for filtering. ... ^^^^^ Oh yeah? Did they think so? Who else has any voice in whether their reasons were valid? Frankly my dear, if Sprint or any other provider wanted to filter all prefixes containing an odd number of bits, and if they thought they had a valid reason for doing so, then by definition, their reasons would be valid. *Our* opinion of the validity (or not) of their reasons would be *irrelevant*. MIBH used to run with prefix filters. It didn't stop much but what it did stop was worthless -- not just people chopping up their ARIN blocks, people doing cheap distributed load balancing by emitting a prefix from multiple locations as a way to do cheap distributed load balancing(*), but erroneous garbage that never should have been there, and so, wasn't. At least in our view of the net. Our customers were happy, so, so were we. (*) if you want to do cheap distributed load balancing by faking multihoming of a prefix, you'll need swamp space, which seems like a small fence to climb.

2 1

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 28 Sep '01

28 Sep '01

Patrick writes: | >Wouldn't it have been easier for small ISP to just aggregate? | >I mean, /19s got through after all! | | No, it would not have helped. Assume the prospective customer has a link | to UUNET and a /24, but wants a second link for [insert reason]. He now | goes to SmallISP.com and asks for info on getting a second T1. Then the | Sprint sales guy calls him and mentions that IF AND ONLY IF he buys a line | from Sprint, will Sprint hear his /24. Let's see. Firstly, this is a valid point, although I wonder how Sprint's sales person could possibly know she or he should call the customer in the first place. Unless Sprint is known to employ psychics, this seems like a bit of a stretch in producing a bete noire. Secondly, /24 is not a small ISP, but wants a small ISP to back-up connectivity to UUNET. Valid goal. However, asking small ISP to ensure the world hears the hole in UUNET's CIDR block is not a good solution. Instead: 1. this is one reason why NAT was invented in the first place, and (hopefully) NAT is feasible for /24 (which is not an ISP) 2. where NAT is impractical or even undesirable, Tony Bates and Yakov Rekhter have a solution in RFC 2260 tailor-made to this situation 3. the maximum 254 things in the /24 can be renumbered into small ISP's PA space and announced to UUWHO with a constraining (set of) community(ies) (NAT, incidentally, was also invented to make renumbering easier) 4. "creative value-added approaches to this problem are sold for $" If the premise that /24 is not an ISP is false, then it should renumber anyway into PA space which is readily available and a generally understood cost of business for transit providers/ISPs. Remember that the /19 boundary is both aligned with RIR policy, which with its slow-start mechanism and fee structure is a really low barrier for a prospective ISP while still putting some costs on consumption of address space, and also small enough that it's not a deadly pain to renumber anything containable by a longer prefix, even without the assistance of NAT. | NOTE: I am not saying this is good or bad, simply saying that what you | suggest would not be useful in this situation. If I cover all the bases, exceptions, and gotchas I will write fewer individual messages but my heaven will they ever be lonnnnnnng! Market research indicates that this is not desired. Sean. PS: | "I realize that this is hard for you to wrap your brain around," but please | believe there may actually be other people on the planet who have the | brains to understand what they are doing and perhaps make a different | decision than you made for a good reason. Requires evidence, and sometimes is undone by subsequent messages. I hope you'll note my tone varies considerably in my various replies to people.

2 1

Why filtering? (was Re: Verio Peering Question)
by smd＠clock.org 28 Sep '01

28 Sep '01

Historical notes, rather than disagreement follows: Jeff McAdams writes: | Filtering on prefix length? There's just no solidly backed up reasoning | to support it that I've heard. 1. it was easy to do (although the EACL was a little hairy) 2. there wasn't a flap-damping choice at the time Note that the network I'm associated with now does RIPE-210 and applies it uniformly. And we figured that out ourselves, some years ago. I think it may have something to do with the fact that even less-experienced people understand that rapidly flapping announcements are (a sign of something) bad. :-) We've also learned that table size just makes a problem more likely to occur in the steady state, and have mitigated against "great big change" events with things like soft resets and checkpointing. Constraining size is now known to be an indirect treatment of the illness best expressed as "too dynamic a network". Sean.

1 0

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by Patrick W. Gilmore 28 Sep '01

28 Sep '01

At 10:12 PM 9/28/2001 -0400, Sean Donelan wrote: > >> The global routing table is hereby capped at 125K routes. After that, >> if you want a route, you have to pay somebody to give up theirs. > >Of course, we could adopt geographic allocations. North American is >still working on (+1) in e.164 space. We could shrink the global >route table to a few thousand routes. There are many prefixes which are demonstrably useless in the global table (e.g. most of 7046). If you are really interested in reducing the size of the table, why not go after those? Instant gratification and all that. But I thought the problem is not *size* of the table, but *changes* in the table. With zero updates, a BGP table of double the current size would not bother any core router on the 'Net today. So, let's work on things like progressive flap dampening. I believe you suggested this before, Sean? -- TTFN, patrick

2 1

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 28 Sep '01

28 Sep '01

| > ip as-path access-list 1 permit _badguy_ | > | > route-map fix-badguy permit 10 | > descr proxy-aggregate the networks who are "holey" | > match as-path 1 | > | > router bgp my-as | > aggregate-address bad.guy.blo.ck1 255.255.224.0 as-set suppress-map fix-badguy | > aggregate-address bad.guy.blo.ck2 255.255.224.0 as-set suppress-map fix-badguy | > ... | | And one aggregates a lone /24 with what? Oh yay, a bona fide techical question. The answer: ACL 1 need not match only one AS as-set is there to deal with matches on multiple AS paths since we want to avoid looping announcements. conveniently, not only does it handle the case where ACL 1 matches lots of AS paths containing _X_, it can equally handle the case where ACL 1 matches lots of AS paths containing _Y_. Next time I use the example I will remember to make ACL 1 longer, and change "bad.guy.blo.ck1" (etc) into something along the lines of "poo.rag.gre.g81", but perhaps more aesthetically pleasing. Sean.

1 0

Too many people named Sean...
by James Smith 28 Sep '01

28 Sep '01

For a while I thought he was arguing with himself... ...need caffeine.... ;-) James H. Smith II I speak for myself, that gets me in enough trouble...

1 0

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 28 Sep '01

28 Sep '01

| The only people who complained were Sprint customers. They always | had the same story, but the filter's don't apply to us. "_Sprint_'s filters don't apply to you. These are _my_ filters." Sprint has had stupid customers, just like everyone else. "If you become a customer[*] of mine, then _my_ filters won't apply to you either." [*] here are our prices for transit, and we have a special deal where for just $XX.99 _my_ filters no longer apply to your networks Oh wait, capitalism is evil and selling filter-exceptions is also immoral (like Indulgences), so forget I mentioned it. Let's go back to whether or not I'm a lying corporate shill and an evil greedy bastard, that's more fun than trying to figure out how to approach non-technical problems presented by the marketplace. | Upon further investigation, they always found they didn't | need to announce those more specific routes. With a little extra | work, they figured out how to announce their registry allocated block. Great, so the plan to distribute the education of the masses off my desk and onto the desks of people like yours worked perfectly. | If Sprint had used a consistent route announcement policy, their | customers could have reduced their use of the global routing table | must sooner. It was consistent, just not symmetrical. It was deliberate and an attempt to get others to filter likewise, which would have accomplished exactly the same thing as symmetrical filtering would have, only with protection from Sprint folks deciding that filtering their customers might cause them to be unhappy and go elsewhere, since there was no expectation that anybody else [*] would filter their customers. | "save the | Internet, unless you pay Sprint extra then its all you can eat | night at the village commons." Shut up and send me a cheque. Sean. [*] of consequence

1 0

good advice for operators (forwarded, with commentary)
by smd＠clock.org 28 Sep '01

28 Sep '01

The muckslinging here reminds me of the break between the operators and the IETF -- the users go on and on about the evil motives of the operators big & small, and demonstrate their lack of understanding or lack of social skills in the process enough that operators decide it's no longer fun to play. I got a message from an operator people would recognize that is interesting, useful, and relevant to operations. Hopefully the good advice in here won't get lost just because the author in question is on the "filtering side". "announce ... aggregates [, develop a] sensible policy [, and acquire] /20's for each location." Who can argue with that? Those of you who feel that regional & local ISPs are being persecuted, please tattoo that advice on your forehead, backwards, so you can see it reflected in your monitor next time before you flame on NANOG about how horrible filtering long prefixes is. My correspondent and his or her colleagues will appreciate the reduction in stomach acids which are not good for any engineer's duodenum. Sean. PS: Well, it's even better if you never announce the more specifics in the first place, imho, but... - -- | of course. it may not be appropriate for someone paid by "X" | to be posting or the source of the comments | | [...] | | On Fri, Sep 28, 2001 at 05:46:56PM -0700, Sean M. Doran wrote: | > can i quote these two paragraphs please, anonymously or otherwise? | > or encourage you to post them? | > | > they are an important dose of factual information | > | > Sean. | > | > ps - bad cold, hence in for the night bored | > - -- | > | if people would just announce their /16's, /20's or aggregates | > | as well as the specifics it would solve the problem. people don't | > | understand their allocations then complain to us. | > | | > | the obvious case of that is when people get a /20 then | > | split the /24's into different geographic regions. as long as | > | they have a sensible policy, the rir will assign them /20's for | > | each location.

3 2