- Test - lists.nanog.org

The Cidr Report
by Tony Bates 28 Jul '00

28 Jul '00

This is an auto-generated mail on Fri Jul 28 12:00:00 PDT 2000 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 28Jul00 0) General Status Table History ------------- Date Prefixes 210700 82529 220700 82534 230700 82499 240700 82582 250700 82822 260700 82702 270700 82843 280700 82898 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.0.0.0/14 from AS6172 AS Summary ---------- Number of ASes in routing system: 8021 Number of ASes announcing only one prefix: 4513 (2506 cidr, 2007 classful) Largest number of cidr routes: 943 announced by AS701 Largest number of classful routes: 1078 announced by AS701 1) Gains by aggregating at the origin AS level --- 28Jul00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 435 152 283 65.1% BCnet Backbone AS7046 643 397 246 38.3% COQUI-NET PRTC Internet AS1221 583 418 165 28.3% TELSTRA-AS AS9706 155 25 130 83.9% Pusan Metropolitan City Office of AS2609 128 8 120 93.8% EUnet-TN AS9304 125 16 109 87.2% Hutchcity AS7657 300 192 108 36.0% The Internet Group Limited AS7545 157 58 99 63.1% TPG Internet Pty Ltd AS9269 155 62 93 60.0% Hong Kong CTI AS6429 208 115 93 44.7% RDC-INTERNET AS7496 126 38 88 69.8% Power Up AS4293 335 248 87 26.0% Internal ASN for C&W AS577 256 171 85 33.2% Bell Backbone AS174 535 456 79 14.8% Performance Systems International AS705 326 249 77 23.6% ALTERNET-AS AS1727 172 99 73 42.4% MRMS-WEST AS724 224 153 71 31.7% DLA-ASNBLOCK-AS AS3908 244 178 66 27.0% Supernet, Inc. AS4755 166 101 65 39.2% Videsh Sanchar Nigam Ltd. India AS701 1078 1014 64 5.9% Alternet AS6595 116 52 64 55.2% DODDSEUR AS5106 98 36 62 63.3% AADS-COLUMBUS AS3749 117 58 59 50.4% TECNET AS7018 546 488 58 10.6% AT&T WorldNet Service Backbone AS7568 80 23 57 71.2% C.S. Communications Co., Ltd. AS3602 299 242 57 19.1% Sprint Canada Inc. AS4740 325 272 53 16.3% Ozemail Pty Ltd (ASN-OZEMAIL) AS11252 90 37 53 58.9% Idaho State University AS7993 78 28 50 64.1% Global One Communications AS209 267 220 47 17.6% Qwest Communications 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

more NSI braindamage....
by woods＠weird.com 28 Jul '00

28 Jul '00

MORE NSI braindamage: . NS B.ROOT-SERVERS.NET A.ROOT-SERVERS.NET zone(a)nsiregistry.NET (2000072800 1800 900 604800 86400) !!! . SOA hostmaster zone(a)nsiregistry.NET has illegal mailbox Don't let the new guy play with the zone files!!!!!! -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <robohack!woods> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

1 0

Happy Sys Admin Appreciation Day
by James Smith 28 Jul '00

28 Jul '00

Happy Sys Admin Appreciation Day to every sys admin and network admin on the list! :) http://www.sysadminday.com/ -- James Smith, CCNA Chief Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2395 Speakman Drive, Suite 2200 Mississauga, ON, L5K 1B3 CANADA Tel: 905-822-1957 (email preferred) Fax: 905-822-0680 1-877-DXSTORM (1-877-397-8676) "Feeling 'connected' with carbon-based dolts holds all the joy of being handcuffed to a dead zebra - it sounds special, but it can get old fast." - The Dilbert Principle - Engineers, Scientists, Programmers and Other Odd People

1 0

How many nexuses would it take?
by Sean Donelan 28 Jul '00

28 Jul '00

I took a stab at estimating what it would take to knock out the top 4% of ASNs on the Internet, thus meeting Tu's threshold for partitioning the net. Of course, to really determine this requires perfect knowledge, and at least some NDA information from the providers involved. My rough estimate is 60 different physical locations worldwide would need to be destroyed. But I suspect congestive collapse would occur after 20 different physical locations were destroyed. This assumes you went after the nexus(es?) of the Net. You could possibly isolate the requisite nexuses, without destroying them. But knowing those locations requires a level of knowledge about the physical overlap between providers I don't have. I think there is a substantial physical overlap between providers' right of ways, so I wouldn't be suprised if the same level of effort to destroy the connectivity of the top 4% of the providers damaged the top 25% (SWAG) since many of the 'tier 2,' and even 'tier 3' providers co-locate in the same physical locations as the top 4%. But I have no proof, only a educated guess. >From the studies I know about, disrupting national telephone service would require less effort. A logical attack on the net would require substitutionally less effort. This also assumes a static network. Network operators could substantially increase the number of peering locations and ASN interconnectivity in response. Those shadow connections and locations I spoke about. Unlike telephone switches, backbone routers are very fungible. So its not inconceivable, some new connectivity between ASNs would rapidly appear in places where there wasn't any before. A lot of Tier 2 and Tier 3 providers are multi-homed, but don't currently provide transit between backbones. This is an administrative policy, not a physical restriction. It is possible for substantial additional inter-ASN connectivity to be brought up very quickly, assuming you had enough remaining communications to coordinate it. Is the shadow connectivity of tier 2 and tier 3 providers enough to invalidate the theory the Internet as a scale-free network? I don't know. On Wed, 26 July 2000, Dave Crocker wrote: > The proffered theory is that a small number of nexus points that form an > essential core. Take out that small number and the remaining alternate > paths won't be sufficient. > > 25 is probably a large number, never mind one or two orders of magnitude more. > > Some effort at figuring out how many (and which) would have to be > simultaneously removed strikes me as a worthy exercise, to make sure that > the number is high (and the specific sights are well enough protected.) > > Perhaps it's already been done and the results kept quiet. That's fine. > > As long as the fragility is nowhere near as extreme as the article implies.

1 0

Reminder - RIPE NCC - change in size of minimum allocation
by Joao Luis Silva Damas 28 Jul '00

28 Jul '00

Allocation policy change reminder: As of 1st August 2000 (next Monday), the RIPE NCC will apply the change in policy agreed during the last RIPE meeting by which the size of MINIMUM allocation will be a /20. Allocations of this size will initially be made from CIDR block 217/8. If you use prefix length filtering in your routers, please take this into consideration. For a complete list of default allocation sizes you can read RIPE document "Size of smallest allocations in CIDR blocks allocated by the RIPE NCC", available at http://www.ripe.net/ripe/docs/internet-registries.html Regards, Joao Damas Head of External Services RIPE NCC

1 0

above.net <=> bbnplanet.net?
by Jeff.Hodges＠kingsmountain.com 28 Jul '00

28 Jul '00

I have a (possibly naive) question.. The peering between above.net <=> bbnplanet.net seems to have (at least)two states.. (1) "abysmal" (500..800 ms latecies) : 9 dfw-lax-oc3.dfw.above.net (208.184.102.154) 59.474 ms 59.657 ms 59.794 ms 10 s3-0-6.crtntx1-cr1.bbnplanet.net (4.24.104.21) 758.127 ms 745.747 ms 741.110 ms : (2) "tolerable" (50..100 ms latencies) : 8 lax-sjc-oc3.lax.above.net (216.200.0.165) 16.479 ms 16.523 ms 16.183 ms 9 dfw-lax-oc3.dfw.above.net (208.184.102.154) 61.052 ms 58.664 ms 59.898 ms 10 s3-0-6.crtntx1-cr1.bbnplanet.net (4.24.104.21) 62.212 ms 67.094 ms 65.389 ms : ..with it being in state#1 for days at a time, and then suddenly being in state #2 for a while (a few hours to a day or so). This has been going on for months at least. Anybody have any idea what's up here? Has anyone else noticed this? today it exhibited a new state #3 for several hours: "near-death" (2000..3000+ ms latencies), after thankfully being in state #2 for a few hours. *sigh*. Isn't this affecting at least a few other folks? thanks, JeffH

1 0

NOC number for HP.
by Neil J. McRae 27 Jul '00

27 Jul '00

Does anyone have a NOC contact for Hewlett Packard? Some of our downstreams can't reach the MX for hp.com and I've had nothing useful from the numbers listed at Netsol or ARIN. Regards, Neil. -- Neil J. McRae C O L T I N T E R N E T neil(a)COLT.NET "In this world there's two kinds of people my friend: Those with loaded guns and those who dig. You dig?"

1 0

summary Re: replacement for Patton 2715 (G.703->V.35) ?
by Jim Mercer 27 Jul '00

27 Jul '00

as a summary, here are the pointers i was given for what other people are using in production: DL085E http://www.quickeagle.com/products/t1e1/soloe1.html SAT3000 http://www.dataman.nl/products/NETW/scitec1.htm GM-H http://www.pandatel.de/content/products?nummer=17&sb=tele FCD-20 http://www.rad.com/products/family/fcd-20/fcd-20.htm On Thu, Jul 27, 2000 at 10:59:38AM +0100, Ryan O`Connell wrote: > It's possible to do G.703 on the Cisco directly. What cards are you using? my last attempt to do exactly that failed. i was using a Cisco 3620 with a ethernet/dual-WAN card. in the dual WAN ports i had a dual-integrated-T1 and an integrated-E1. in the end (after 5 days of cisco attempting the same configuration in a lab), it was determined that they did not have an IOS that supported that configuration. cisco was somewhat confused by my requirement for T1 and E1 in the same router, but, well, that was my requirement. i believe that the reason was that the E1 card was designed to work with a channelized circuit (ie. we could not turn off framing on the E1). the dual T1 card was designed for VOIP and needed extra hardware to just do straight T1 data (???). cisco has since come out with a WAN-G703 card, which purportedly does a raw E1, but given past experience, i would prefer to go external unless i have lots of time to play around with different IOS, etc. (unfortunately not the case with this project). we decided in the last project and for this project to use a 4 port serial card on the cisco and use external equipment. i guess my one big misunderstanding is that T1 is to E1 what V.35 is to X.21. i hadn't realized that X.21 appears to be the preferred interface outside north america, but it does explain the puzzled look on various technicians faces. 8^) -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

1 0

RE: replacement for Patton 2715 (G.703->V.35) ?
by Gullerud, Lars Erik 27 Jul '00

27 Jul '00

On 26/07/2000, Jim Mercer wrote: >i'm in north america, so i don't have much experience to draw on for E1 gear. ... >can i get a short list of recommended E1 -> V.35 converters? We generally stick to one of these boxes for G.703 to V.35/X.21 conversion: Tellabs MartisDXX STU-2304 Pandatel GM-H or GM-F There are lots of other equipment out there, but these are the ones we have the best experiences with. Of course, it's easier to do G.703 directly on the router... :) Regards, Lars Erik

1 0

Re: Sonet protection usage
by Danny McPherson 27 Jul '00

27 Jul '00

> Are many ISPs taking advantage of SONET APS protection > to provide port or router redundancy on short (metro-area) > circuits? Or is it more typical to get two circuits and > load-share? Or just not bother? I know of a few providers that use inter-router APS to protect against router and ADM trib port (mainly router) failures in the core. The optical network side is protected by BLSR or the like. The optical protection options still seem to be much more cost-effective then simply provisioning parallel (but presumably diverse) links between two locations, not to mention that if some load-balancing schema is employed one needs to consider accommodating additional propagation delay incurred on the less optimal path (an ideal application for CoS & TE, perhaps). Inter-router APS proves itself especially useful on trans-oceanic circuits where simply acquiring additional capacity often isn't a viable option, nor is allowing some really expensive circuit to sit idle for 5 or 10 minutes while a router boots and becomes synchronized. As you can imagine, there are lots of interesting issues with inter-router APS and IGP interaction, most of which seem to cast a considerable shadow on its value when considering network availability and convergence in the event of failures. Intra-router APS is much more appealing, assuming stateful port mirroring is implemented, though it doesn't address the main concern of protecting against router failures. Of course, it's definitely better than simply selecting an alternative, presumably less optimal network path simply because a local router becomes unavailable. -danny

6 7