- Test - lists.nanog.org

The Cidr Report
by Tony Bates 06 Mar '98

06 Mar '98

This is an auto-generated mail on Fri Mar 6 12:00:01 PST 1998 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 06Mar98 0) General Status Table History ------------- Date Prefixes 270298 49830 280298 49218 010398 49211 020398 49301 030398 49206 040398 49095 050398 49430 060398 49432 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: 3301 Number of ASes announcing only one prefix: 1558 (805 cidr, 753 classful) Largest number of cidr routes: 430 announced by AS3561 Largest number of classful routes: 1012 announced by AS701 1) Gains by aggregating at the origin AS level --- 06Mar98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 583 360 223 38.3% iSTAR Internet, Inc. AS4293 431 222 209 48.5% IMCI AS816 615 440 175 28.5% UUNET Canada (ASN-UUNETCA-AS4) AS174 800 639 161 20.1% Performance Systems International AS3602 460 307 153 33.3% Sprint Canada Inc. AS3749 216 66 150 69.4% TECNET AS701 1012 863 149 14.7% Alternet AS8505 150 36 114 76.0% Middle East Technical University AS3751 125 48 77 61.6% SNET-AS AS5668 110 38 72 65.5% Century Telephone Inc. AS4151 122 56 66 54.1% USDA Internet Access Network AS3804 206 143 63 30.6% Bell Solutions AS3221 94 34 60 63.8% EENet Autonomous System AS1239 579 520 59 10.2% SprintLink Backbone AS271 112 56 56 50.0% BCnet Backbone AS10928 94 40 54 57.4% UNKNOWN AS3464 118 65 53 44.9% Alabama Research and Education Ne AS549 211 162 49 23.2% ONet Backbone AS4755 82 33 49 59.8% Videsh Sanchar Nigam Ltd. India AS72 84 36 48 57.1% Schlumberger Information Network AS1221 266 218 48 18.0% AARNET-AS AS4763 124 78 46 37.1% Telstra New Zealand AS7046 138 94 44 31.9% UUNET-CUSTOMER AS6181 67 23 44 65.7% FUSE-NET AS6335 64 22 42 65.6% NTRNET AS3561 888 846 42 4.7% MCI AS2711 97 55 42 43.3% SUNBELT-AS AS10722 73 31 42 57.5% Aluminum Co. of America AS4740 348 307 41 11.8% ASN-OZEMAIL (Ozemail Pty Ltd) AS852 154 115 39 25.3% AGT Advance Communication 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

White paper: What is a VPN?
by Avi Freedman 06 Mar '98

06 Mar '98

I'm forwarding this for Paul, who's on vacation... FYI for anyone interested in something to give customers or management :) Blurb follows. Avi [snip] Here is a pointer to the completed white paper that Geoff Huston (Telstra Internet) and I have just completed: Title: What is a VPN? Abstract: The term "VPN," or Virtual Private Network, has become almost as recklessly used in the networking industry as has "QoS" (Quality of Service) to describe a broad set of problems and "solutions," when the objectives themselves have not been properly articulated. This confusion has resulted in a situation where the popular trade press, industry pundits, and vendors and consumers of networking technologies alike, generally use the term "VPN" as an offhand reference for a set of different technologies. This paper attempts to provide a common sense definition of a VPN, and an overview of different approaches to building them. The paper can be found under the subheading "Presentations, Slideware, and Assorted Cruft" at the URL: http://www.employees.org:80/~ferguson/ This paper is currently only available in a PostScript (.ps) and Adobe Acrobat (.pdf) formats. The paper (filenames: vpn.zip & vpn.pdf) is also available via anonymous ftp at ftp://ftp.employees.org/ferguson/<filename> It should be noted that this is not a positioning paper, but rather, an attempt to provide some sanity in the effort to define what constitutes a virtual private network. Please direct any comments, concerns, kudos, etc. to either Geoff or myself directly. Cheers, - paul (on vacation) [snip] -- Paul Ferguson || || Consulting Engineering || || Herndon, Virginia USA |||| |||| tel: +1.703.397.5938 ..:||||||:..:||||||:.. mailto:ferguson@cisco.com c i s c o S y s t e m s

1 0

Looking for T1 connectivity, Owensboro, KY
by Alan B. Clegg 05 Mar '98

05 Mar '98

Greetings, all. I'm about to give up hope of anyone in sales being able to help me, *SO*, I figured the folks on this list might actually be able to provide an answer (or pass this on to their sales folks that have clue). I'm looking for T1 connectivity for a startup ISP in Owensboro, KY. Area code 502-926-xxxx If anyone would be interested in proposing connectivity, please e-mail me. Thanks, -abc

1 0

Re: InterNIC problems?
by David H. Holtzman 04 Mar '98

04 Mar '98

We're not having any unusual problems here, certainly nothing with mail or template processing. In fact, we think that we're processing them faster now. As far is referral whois for linking to ARIN, RIPE, etc. It's a pretty good idea and we have in fact been working on it. David H. Holtzman Sr VP Engineering, Network Solutions dholtz(a)internic.net

1 0

InterNIC problems?
by Peter Murray 04 Mar '98

04 Mar '98

I've not heard anything from the InterNIC in recent days - forms submitted via their web page aren't resulting in forms in my inbox anymore. Has anyone else noticed a distinct lack of InterNIC mail lately? The last time I got anything from them was 15.45 on 2/28/98. Hmmm.. now that I think of it, I haven't seen any recent NANOG postings in a while - not since the "Halon-protected colo space available" posting on 3/1/98, at 21.12. I've received other mail, but these two sources have been noticeably quiet. We'll see what this posting does. Thanks for any insight! -Pete Pete Murray - FASTNET(tm) / You Tools Corporation > pete(a)fast.net (610) 954-5200 - http://www.fast.net > FASTNET - Business and Personal Internet Solutions >

5 4

Re: routing registries....
by Ben Kirkpatrick, ELI 04 Mar '98

04 Mar '98

As I mentioned in my original post, I will summarize the responses I received. This is fairly easy since I only got one message and it said simply, "Use the RADB". To a company like the one I'm currently participating in, using the RADB is unacceptable because they want to have complete security and control over the database. This is rather short-sited, but it's not my decision. I'll be researching more in the near future and send an update then. --Ben Kirkpatrick. On Tue, 3 Mar 1998 someone wrote: > on 2/9/98, you sent a posting to nanog, asking what most large NSP's were > doing in the way of routing registries? RADB or a local database....what > kind of responses did you get?

2 1

Re: Internic PGP Auth busted
by Sanjay Dani 03 Mar '98

03 Mar '98

> requirement so that you can then change each one to CRYPT. [File away > that first response that has your encrypted password. I am told you don't > ever get it again.] If you are lucky (?), the (A)ck/(N)ak NOTIFY message that goes to the "other" contact might include your password. I saw my password, as the admin contact for a domain, included in the NOTIFY message that went to the technical contact, luckily it was our own NOC. Regards, Sanjay. PS. Thanks to everyone who responded to my query on overseas telco provisioning, I will post one summary when the info is complete. --------------------------------------------------------------- Web Professionals, Inc. Direct: +1 408-863-4850 20111 Stevens Creek Blvd, Suite 145 Biz/NOC: +1 408-863-4848 Cupertino CA 95014 USA http://web.professionals.com --------------------------------------------------------------- -=- Your Outsourcing Partner for Website and Server Hosting -=-

4 3

Halon-protected colo space available (how do I market it?)
by Brian Topping 02 Mar '98

02 Mar '98

Hi all, I have a 1000 sq ft Halon protected vault in San Francisco (about 1.5 miles from downtown) that I am looking to sublet some space in. We can rack it out or sell it by the square foot. It has about 10 tons of redundant AC and copper access to a PacBell Lightspan 200 mux in the building MPOE. We also have about a thousand square feet of concrete outside for the location of condensers and generators. We are very close to the power plant and as a result were not affected by the power outage in SF the other day. We expect that we will improve the HVAC and power as time proceeds. I would like to move quickly to get some deposits on moving in, and am willing to do what it takes to get them. If anyone has ideas about targeted marketing in this arena or are interested themselves, please contact me at this address. Thanks! Brian Topping

1 0

don't fall victim to FUD was Re: action: Santa Clara CA & Montgomery MD
by Gordon Cook 28 Feb '98

28 Feb '98

Dear Nanog list members and Congress people Before you get too excercised about Bill Simpson's allegations in the message below let me provide some context that is missing from Mr. Simpson's message. On Monday in the IETF mail list considerable anger was displayed over the statement in the Green Paper that the IANA Policy Council would "coordinate the development of other technical protocol parameters as needed to maintain universal connectivity on the Internet." It was pointed out that the proper function should be to "coordinate the **assignment** of other technical protocol parameters . . ." On Monday afternoon I interviewed Ira Magaziner and brought up this issue. On Monday evening I posted to the IETF list Ira's statement to me that development was mistaken and assignment should have been used. On Feb 25 Scott Bradner posted the a separate denial from IRA to IETF list: Date: Wed, 25 Feb 1998 08:48:53 -0500 (EST) From: Scott Bradner <sob(a)harvard.edu> To: ietf(a)ns.ietf.org Subject: from Ira Magaziner Re: IETF relationship to new IANA I asked Ira Magaziner about the wording in the Green Paper in the area of the relationship between the IETF and the new IANA. This is his reply which he said I could forward. Scott ---- Mr-Received: by mta EOPMRX; Relayed; Mon, 23 Feb 1998 18:12:16 -0500 Alternate-Recipient: prohibited Disclose-Recipients: prohibited Date: Mon, 23 Feb 1998 18:10:00 -0500 (EST) Subject: Re: this is what I am very worried about To: sob(a)harvard.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Ua-Content-Id: MBLINKAA X400-Mts-Identifier: [;61218132208991/1513276@EOPMRX] Hop-Count: 1 Message Creation Date was at 23-FEB-1998 18:10:00 Thanks for your note. The wording of the green paper is a mistake. We certainly do not intend for the IETF to in any way become subserviant to this new organization. We will correct it in the next draft. Ira ========== In his Feb 23rd interview with me Ira said: Magaziner: Let me make clear then what is going on. I think that the word "development" was not a correct word to represent the function we were trying to indicate and that has been pointed out to us by a number of people. So that is a good criticism. There are mistakes in this report as there would be in any report and when they are pointed out, we acknowledge them and say we will fix them. Whether the word assignment or not is the right one I don't know, but development is clearly the wrong word. I think the process of assigning port numbers is what we are trying to convey. Secondly I think it is accurate to say that we would respond to the sense of the broader community about whether that function which has been performed by Postel historically should be performed by this new organization or whether it should be performed by the IETF itself. I think whatever the community wanted to do on that would be OKAY with us. That is the way I put it. I did not say have power or not have power. What we did in our report was to propose it as a continued IANA function, or if the IETF wished to that it could assume the authority. But let me again make it very clear we don't intend this word development. That was a mistake." ======= Cook: In his interview Ira also made it very clear that the IANA policy Council is to have control of the root servers and not the US government. Consequently it seems to be that Mr. Simpson is feeding the current atmosphere of mistrust and suspicion by moving a problem that quite clearly has been answered on the IETF list to the NANOG list and into Congress where many are unaware of what has transpired on the IETF list. Note also that I have just pulled down both the jan 30th text and the federal register texts of the green paper. I searched both texts for the string policies and standards for those activities and found nothing in either one. I might suggest that Mr. Simpson give us the complete citations of what he is ranting against for, on the basis of my knowledge of the green paper and conversations with Magaziner he is falsely accusing the US government and seeking to stir up dissension that will do none of us any good. It would be far more useful if he would apply his talents to the establishment of an IANA policy council that protected the ability of the net to run its own affairs. There will be an IANA policy council.... Jon postel himself is working on it. The IANA functions must be institutionalized. Jon is not immortal. Why not accept this reality and work toward that institutionalization instead of undermining efforts designed to accomplish it via fear, uncertainty, and doubt? ============================================================== >Gentlefolk, the US proposed rule taking over the Internet root servers has >many issues that may be of concern to network operators. Here are two >congressional offices that have expressed interest in electronic comments. >They want to gauge current levels of interest by the community. > >If you live or have business offices in these areas, or somewhere near, >please take a moment to send a short email to one of these representatives >in the next few days. The congress members are in recess (that means >at home) this week, and go back next Tuesday. > > >Zoe Lofgren > zoegram(a)lofgren.house.gov > Please include a complete U.S. Postel address. > > Local Office: > 635 North 1st Street, Suite B > San Jose, CA 95112 > tel: 408-271-8700 > Washington: > 318 Cannon Building > Washington, D.C. 20515 > tel: 202-225-3072 > >Constance A. Morella > Rep.Morella(a)mail.house.gov. > Be sure to include U.S. Postal address. > > Rockville (301) 424 - 3501 > Office 51 Monroe Street, Suite 507 > Rockville, Maryland 20850 > Washington (202) 225 - 5341 > Office 2228 Rayburn House Office Building > Washington, D.C. 20515 > > >Some issues of particular concern are: > > - the proposed rule allows the US government to control > "... policies and standards for those activities, including ... > interoperability, privacy, security, ...." > > Do we really think it would be a good idea for the US government > to control the standards for interoperability? > > Do we really think it would be a good idea for the US government > to control the standards for privacy and security? > > Especially as operators, do we really think it would be a good idea > for the US government to control the passwords and keys for the root > servers? > > Please think hard about the consequences. Will they let your domain > into the system (sign your NS records) unless you agree to escrow > your server keys with them? > > - Since the announcement last year, we have been looking forward to > the day (March 31) when NSI no longer has monopoly control over > registration. The proposed rule extends the monopoly another 6 > months (minimum), and control of the major domains indefinitely > (at least 2 years). > > Do we really think that is a great idea? After a year has passed, > and no plans for transition have been made by NSI? > > - The root servers are currently run by volunteers. The proposed > rule would take over operation, and give it to a new corporation, > set up by the US government. > > Are we having any real problems with our current servers? > > Do we really think it is a great idea for the US government to be > actively involved at all? *************************************************************************** The COOK Report on Internet New Special Report: Building Internet 431 Greenway Ave, Ewing, NJ 08618 USA Infrastructure ($395) available. See (609) 882-2572 (phone & fax) http://www.cookreport.com/building.html cook(a)cookreport.com Index to 6 years of COOK Report, how to subscribe, exec summaries, special reports, gloss at http://www.cookreport.com ***************************************************************************

4 4

Can you explain why paths to same host diverge?
by Mark Boolootian 28 Feb '98

28 Feb '98

Folks, We've been seeing some large latencies to sites inside of UUNET lately. In trying to figure out where the latency is coming from (UUNET or our provider, Sprint), I observed something which has me baffled. I have two hosts on the same subnet. One of them is 128.114.2.53 and the other is 128.114.2.91. Here are ping results from these machines to www.uu.net: from 128.114.2.91: PING www.uu.net (199.170.0.30): 56 data bytes, 100 packets 100 packets transmitted, 100 packets received, 0% packet loss round-trip (ms) min/avg/max = 362/548/778 (std = 103) from 128.114.2.53: PING www.uu.net (199.170.0.30): 56 data bytes, 100 packets 100 packets transmitted, 100 packets received, 0% packet loss round-trip (ms) min/avg/max = 92.9/107/139 (std = 8.43) The RTT from 128.114.2.91 are always much higher (many times a full order of magnitude) than those of 128.114.2.53. The explanation for the differing RTTs turns out to be that the paths between each of my machines and www.uu.net are different. In the below traceroutes, everything agrees up through hop five. But at hop six, the paths diverge: from 128.114.2.53: traceroute to www.uu.net (199.170.0.30): 1-30 hops, 38 byte packets 1 comm-g.UCSC.EDU (128.114.2.252) 4.52 ms 2 frontdoor.UCSC.EDU (128.114.103.1) 1.15 ms 3 UC-net-dmz.ucsc.edu (208.1.176.6) 1.45 ms 4 bgty-lata01.ucnet.net (192.35.219.2) 7.79 ms 5 sl-gw10-stk-11-0-T3.sprintlink.net (144.228.146.49) 8.70 ms 6 sl-bb10-stk-2-1-155M.sprintlink.net (144.232.4.78) 30.2 ms 7 sl-bb3-stk-0-0-0-155M.sprintlink.net (144.232.4.42) 33.0 ms 8 Hssi8-1-0.BR1.SFO1.ALTER.NET (137.39.166.121) 42.3 ms 9 114.ATM3-0-0.XR1.SCL1.ALTER.NET (146.188.145.222) 76.9 ms 10 100.ATM2-0-0.TR1.SCL1.ALTER.NET (146.188.145.226) 41.3 ms 11 107.ATM8-0-0.TR1.DCA1.ALTER.NET (146.188.136.221) 110 ms (ttl=242!) 12 199.ATM4-0-0.XR1.TCO1.ALTER.NET (146.188.161.161) 223 ms (ttl=243!) 13 193.ATM5-0-0.GW2.FFX1.ALTER.NET (146.188.160.209) 158 ms (ttl=242!) 14 UUNET7-GW.UU.NET (137.39.12.162) 214 ms (ttl=241!) 163 ms (ttl=241!) 15 www.uu.net (199.170.0.30) 155 ms (ttl=240!) from 128.114.2.91: traceroute to www.uu.net (199.170.0.30): 1-30 hops, 38 byte packets 1 comm-g.UCSC.EDU (128.114.2.252) 1.29 ms 2 frontdoor.UCSC.EDU (128.114.103.1) 1.7 ms 3 UC-net-dmz.ucsc.edu (208.1.176.6) 2.82 ms 4 bgty-lata01.ucnet.net (192.35.219.2) 7.75 ms 5 sl-gw10-stk-11-0-T3.sprintlink.net (144.228.146.49) 10.6 ms 6 sl-bb11-stk-1-1-155M.sprintlink.net (144.232.4.98) 11.2 ms 7 sl-bb3-stk-4-0-0.sprintlink.net (144.232.4.14) 9.27 ms 8 Hssi8-1-0.BR1.SFO1.ALTER.NET (137.39.166.121) 609 ms 9 114.ATM3-0-0.XR2.SCL1.ALTER.NET (146.188.145.210) 541 ms 10 100.ATM3-0-0.TR2.SCL1.ALTER.NET (146.188.145.246) 578 ms 11 107.ATM8-0-0.TR2.DCA1.ALTER.NET (146.188.136.225) 633 ms 12 198.ATM8-0-0.XR2.TCO1.ALTER.NET (146.188.161.185) 683 ms (ttl=243!) 13 192.ATM12-0-0.GW2.FFX1.ALTER.NET (146.188.160.221) 622 ms (ttl=242!) 14 UUNET7-GW.UU.NET (137.39.12.162) 569 ms (ttl=241!) 534 ms (ttl=241!) 15 www.uu.net (199.170.0.30) 579 ms (ttl=240!) Can anyone explain to me why paths would diverge in this fashion? These traceroutes aren't aberrations - the packets follow these forward paths consistently. Clues greatly appreciated. thanks, mb --- Mark Boolootian UC Santa Cruz

5 6