- Test - lists.nanog.org

The Cidr Report
by Tony Bates 23 Jun '01

23 Jun '01

This is an auto-generated mail on Fri Jun 22 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. 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 me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 22Jun01 0) General Status Table History ------------- Date Prefixes 150601 101429 160601 101413 170601 101455 180601 101185 190601 101168 200601 101266 210601 101030 220601 101078 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 11056 Number of ASes announcing only one prefix: 6521 (3719 cidr, 2802 classful) Largest number of cidr routes: 1030 announced by AS701 Largest number of classful routes: 1425 announced by AS701 1) Gains by aggregating at the origin AS level --- 22Jun01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1363 1022 341 25.0% TELSTRA-AS AS701 1425 1226 199 14.0% Alternet AS4755 261 140 121 46.4% Videsh Sanchar Nigam Ltd. Autonom AS4293 398 283 115 28.9% part of AS assignment AS4287 - AS AS6595 157 58 99 63.1% DoD Education Activity Network As AS6429 203 105 98 48.3% ATT LA Internet Chile AS705 238 142 96 40.3% part of AS assignment AS701 - AS7 AS13999 103 11 92 89.3% Mega Cable S.A. de C.V. AS7018 725 642 83 11.4% AT&T WorldNet Service Backbone AS4151 158 77 81 51.3% part of AS assignment AS4151 - AS AS8013 293 218 75 25.6% PSINet Ltd. Canada AS577 250 177 73 29.2% Bell Advanced Communications Inc. AS6471 114 51 63 55.3% ENTEL CHILE S.A. AS3464 152 90 62 40.8% Alabama Research and Education Ne AS724 217 156 61 28.1% part of AS assignment AS721 - AS7 AS7046 303 242 61 20.1% UUNET Technologies, Inc. AS1 591 532 59 10.0% GTE Internetworking AS16758 63 6 57 90.5% IKON Office Solutions AS1239 445 390 55 12.4% SprintLink Backbone AS2149 326 272 54 16.6% PSINET-2 AS3908 203 150 53 26.1% Supernet, Inc. AS226 143 90 53 37.1% Los Nettos AS6413 66 14 52 78.8% Southern Online Systems, Inc. AS4323 236 184 52 22.0% Time Warner Telecom Internet AS5106 94 43 51 54.3% Ameritech Advanced Data Services, AS17561 112 61 51 45.5% Internet service provision to Wes AS9842 54 5 49 90.7% Lotte Data Communication Company AS852 209 161 48 23.0% Telus Advanced Communications AS855 143 97 46 32.2% part of AS assignment AS853 - AS1 AS3602 225 179 46 20.4% Sprint Canada Inc. 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: IP Addresses for colocation
by smd＠clock.org 23 Jun '01

23 Jun '01

| The concern I have is this: if we decide a few months down the road that we | don't like this particular colocation facility and wish to move to another one | across the street, I'd have to renumber all of my hosts. So, it's like the DNS has totally stopped working, to the point where there is zero possibility of adding in new A RRs? And the tools that allow centralizatioin of address administration, like DHCP, have also broken down, I guess. I blame the Internet Software Consortium for people wanting to migrate _whole /24s_ instead of doing a renumbering exercise when they shift gear from using one connection to the Internet to another, since obviously their software (like BIND and DHCP) is horribly flawed and unusable. | Is there a better way to get a /24 that can "go anywhere"? You can pay each of the thousands of ISPs whose routing tables will have to carry your prefix in their routing systems... have you considered that? (I'll do it for 100 U.S. dollars, inquire within!) Sean.

3 2

IETF draft on Operator Requirements of Network Management Tools
by Bill Woodcock 23 Jun '01

23 Jun '01

The IETF Operations and Management area held an interim meeting in Phoenix in conjunction with the last NANOG. It was called to address the gulf which has grown between the operator community and the management tools development community. There are clearly un-met needs for network management tools, and tools which haven't found use in operational networks. Randy and Bert want to get the two groups talking again so the management tools folks' time won't be wasted and the operators will get tools they can use. Suzanne Woolf and I have been tasked with producing a draft to document operator requirements of infrastructure management methods. We need to describe the tools, methods, and practices which operators need the management software community to support, in as unambiguous a fashion as possible. There's an email list for discussing the requirements, which you can subscribe to in the usual manner at: ops-nm-request(a)ops.ietf.org and there's an email address to which specific suggested requirements can be sent, which Suzanne and I will try to incorporate into the document. Please write up exactly what you're thinking, with clear examples, if possible, and as much detail as you think is necessary, and send them to: ops-nm-suggestions(a)ops.ietf.org As likely requirements are submitted, Suzanne and I will summarize them back to the ops-nm list for discussion. If you need to contact us privately we can be reached at: Suzanne Woolf woolf(a)mfnx.net +1 408 367 6666 (GMT +8) Bill Woodcock woody(a)pch.net +1 510 409 6620 (GMT +8) Thanks, -Suzanne Woolf -Bill Woodcock

1 0

Re: IP Addresses for colocation
by Roger Marquis 23 Jun '01

23 Jun '01

Mark J. Scheller wrote: > Is there a better way to get a /24 that can "go anywhere"? Or should I just > justify a /24 at the colocation facility and go through the same process > should we decide to change? Is there a way to buy a routable /24? Not sure I understand the concerns WRT renumbering. If you have numerous VPNs and ACLs which are dependent on the IPs then it may be a little work, but otherwise there's not really much to renumbering a /24. Just make sure the new nameservers are in place, the old TTLs are turned down to 24 hours or so, and the environment is replicated at the new co-lo. You can use GRE tunneling and optionally NAT to do this with even more cut-over transparency. If you've never done it before hire a consultant to draw up the project plan and walk you through. The second time is much easier, and after that you'll be free to choose a co-lo without needing to worry if it'll be forever viable. BTW, no matter what ISP you choose chances are that at some time in the future you'll want to move. Plan on it and you'll sleep a lot easier. One question for the gurus on this list: if a site were to get a portable /24 would they be able to assure connectivity to ISPs that filter small subnets from their BGP? -- Roger Marquis Roble Systems Consulting http://www.roble.com/

1 0

[OT] Lucent max tnt config
by Sabri Berisha 23 Jun '01

23 Jun '01

Hi, I have such a device for configuration on my desk however I'm completely clueless on how to. Does anyone have an example configuration which I can use? Please mail me off the list. Thanks in advance. -- /* Sabri Berisha CCNA,BOFH,+iO O.O speaking for just myself * Join HAL!!: www.HAL2001.org ____oOo_U_oOo____ http://www.bit.nl/~sabri * "We deliver quality services, we just can't get it on the internet" * Anonymous sysadmin - on IRC */

6 5

qrz.com outage yesterday
by Kevin Loch 22 Jun '01

22 Jun '01

Here's an unusually detailed report of a localized outage, with pictures. http://www.qrz.com/photos/cables.html KL

1 0

EXDS needs your money!
by Ellen Handcock 22 Jun '01

22 Jun '01

> Dear Exodus Customer, > > As part of our ongoing preventive maintenance program the Facilities > Department will be working with contractors to have the space under > the raised floors cleaned. ... Who else thinks they're looking for change under there? __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/

1 0

Re: Routing Problem?
by smd＠clock.org 22 Jun '01

22 Jun '01

| I'm trying to convince their NOC something is not rite. Are you sure it's "not rite" by accident, rather than by design? [traceroute showing singapore->teleglobe-in-LA->Alternet-in-LA-> Alternet-in-DC->Teleglobe-in-Montreal] "AS Healing" via another network has been done the past, this looks an awful lot like an example of that. Sean.

2 1

RE: IP Addresses for colocation
by Cutler, James R 22 Jun '01

22 Jun '01

Mark, I would like to understand why you need to use access by IP address rather than DNS name. Using DNS CNAME records for URL domain lookup would seem to insulate one rather well from renumbering. JimC -----Original Message----- From: Mark J. Scheller [mailto:scheller@u1.net] Sent: Thursday, June 21, 2001 4:15 PM To: nanog(a)merit.edu Subject: IP Addresses for colocation Hello NANOG, I'm in the process of evaluating whether to transition away from self-hosting web servers to have them hosted at a colocation facility. The obvious advantages being greater capacities for bandwidth, power, cooling, and oh yes, proper methods of putting out a fire (instead of drowning the servers in water if they so much as overheat). The concern I have is this: if we decide a few months down the road that we don't like this particular colocation facility and wish to move to another one across the street, I'd have to renumber all of my hosts. Is it possible to go to any colocation facility with a block of IP addresses in hand and use them? I'm talking about a /24 here, so I cannot request the addresses directly from ARIN, rather I need to get them from some other source. I attempted to get them from our current bandwidth provider, but they seem to be a little taken aback by my request for a block of addresses that will not be routed by them -- in fact, while writing this they called to tell me they will not provide IP space unless they route to it. Is there a better way to get a /24 that can "go anywhere"? Or should I just justify a /24 at the colocation facility and go through the same process should we decide to change? Is there a way to buy a routable /24? Thanks in advance for any advice, on or off list. I will summarize unless the answer is "you're crazy, such things aren't possible" in which case I'll be off drowning my sorrows at a nearby watering hole. Mark J. Scheller (scheller(a)u1.net)

1 0

Routing Problem?
by Poon Keen Mun 22 Jun '01

22 Jun '01

Hi, Is there any folks from Teleglobe on nanog list. I'm trying to convince their NOC something is not rite. Thanks. Target Name: www.teleglobe.net IP: 199.202.44.109 1 1 ms [203.120.94.2] 2 2 ms scipk009.pacific.net.sg [192.154.24.241] 3 2 ms scipk001.pacific.net.sg [203.120.90.1] 4 216 ms if-5-0-1.bb2.LosAngeles.Teleglobe.net [207.45.212.185] 5 217 ms if-6-0.bb3.LosAngeles.Teleglobe.net [207.45.220.69] 6 217 ms ix-5-0-1.bb3.LosAngeles.Teleglobe.net [207.45.200.198] 7 217 ms 0.so-0-3-0.XL2.LAX9.ALTER.NET [152.63.115.6] 8 216 ms 0.so-0-0-0.TL2.LAX9.ALTER.NET [152.63.115.146] 9 * [152.63.10.61] 10 * 0.so-6-0-0.XL2.DCA6.ALTER.NET [152.63.38.74] 11 * POS7-0.BR2.DCA6.ALTER.NET [152.63.38.137] 12 * [137.39.52.166] 13 * 0.so-2-1-0.XL1.DCA6.ALTER.NET [152.63.38.85] 14 * POS6-0.BR2.DCA6.ALTER.NET [152.63.38.133] 15 * if-9-0.core2.Montreal.Teleglobe.net [207.45.222.110] 16 * Vlan3.msfc2.Montreal.Teleglobe.net [207.45.221.167] 17 * [199.202.50.134] 18 * [199.202.45.23] 19 * wnet-gw.teleglobe.com [199.202.42.1] 20 * [199.202.50.134] 21 * www.teleglobe.com [199.202.44.109] --- Poon Keen Mun Pacific Internet Limited, Singapore.

1 0