June 1999 - Test - lists.nanog.org

Is there a PSI.NET person in the house?
by Roeland M.J. Meyer 11 Apr '00

11 Apr '00

I just got half a hundred of these (and 123 of these last Friday) and all e-mail, to the usual locations, bounces or gets ignored. I am livid, I am pissed, I am *really* wanting to SMURF PSI.NET because they have been a spam-harbor for *years*! PSI.NET should have made it into the RBL a long time ago. >Return-Path: <admin1(a)fnmail.com> >Received: from beta.pragmatix.com (epsilon.pragmatix.com [205.166.32.6] (may >be forged)) > by condor.lvrmr.mhsc.com (8.9.1/8.9.1) with ESMTP id FAA18857 > for <rmeyer(a)mhsc.com>; Mon, 1 Mar 1999 05:04:57 -0800 >Date: Mon, 1 Mar 1999 05:04:57 -0800 >From: admin1(a)fnmail.com >Message-Id: <199903011304.FAA18857(a)condor.lvrmr.mhsc.com> >Received: from jgroves (ip33.phoenix8.az.pub-ip.psi.net [38.29.61.33]) by >beta.pragmatix.com with SMTP (Microsoft Exchange Internet Mail Service >Version 5.5.1960.3) > id FS46B0Z3; Sun, 28 Feb 1999 18:33:11 -0500 >To: travelers(a)ibm.net >Subject: Make $$, Travel and Have Fun! >X-UIDL: 2ddab26e92763572b29a9545c30b592f ___________________________________________________ Roeland M.J. Meyer - e-mail: mailto:rmeyer@mhsc.com Internet phone: hawk.lvrmr.mhsc.com Personal web pages: http://staff.mhsc.com/~rmeyer Company web-site: http://www.mhsc.com ___________________________________________________ KISS ... gotta love it!

3 3

Route-Reflector Redundancy
by Brandon Applegate 01 Jul '99

01 Jul '99

Greetings all, In a redundant RR design, I have several questions that don't seem to be clearly covered in RFC1966. 1) Does a given route-reflector have to peer with the other route-reflectors in its own cluster ?? 2) If yes to 1), do the RRs in the cluster peer with each other as clients or non-clients ?? 3) If no to all of the above, do you just put X numbers of route reflectors into the AS and each client etc. in the cluster now peers with X # of RR's ? Above and beyond all of the above (actually depending on all of the above :) ), if my client router hears something from RR1, will it also hear it from RR2 ?? Is there a race condition ? Thanks in advance. -------------------------------------------------- Brandon Applegate, CCNA : Network Administrator http://www.one.net : brandon(a)one.net --------------------------------------------------

6 5

Cisco TAC KRAP !!
by TOO MUCH 30 Jun '99

30 Jun '99

Over the last year it seems that the quality of service I have received from TAC has diminished. At one time I found myself speaking to a knowledgeable engineer. Who knew the product and protocols involved and they were willing to share information. The norm these days is to get an engineer who knows less then I do. I'm call requesting technical information pertaining to their products, What I get is some clown telling me to hold on while he surfs the internal web page looking for the answer. I can scan CCO myself!! Is it just me ? Phantom hates Cisco or should I say Sissy-Co TAC!! _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

7 7

Re: Who are you gonna call?
by Sean Donelan 30 Jun '99

30 Jun '99

>Seriously, though, there comes a point when you have to just trust in >something. The chances of one's phone and palm both going out at the same >time are fairly remote, I would expect. Yes, paper has a 451F temperature problem, and palm pilots and cellphones have an EMP problem (not to mention a battery recharger problem). But my question wasn't about remembering the numbers. Assume some really experienced people are doing this stuff and will make sure the numbers are there and the message goes through, no matter what. Even if they have to send a messenger on foot to relay the messages like the Roman Empire. I know its difficult for engineers, but ignore the people behind the curtain. Who would you want to be able to call to bootstrap the system back up? Would you call CERT/CC? Or since they don't actually fix anything, is that a wasted call? Would you call Microsoft? Or since nothing critical on the Internet depends on their products, is that a wasted call? Nortan or Symantec? How about IANA/ICANN? CNN or AOL to say stay off the infobahn, accident and workers in the road ahead? Or instead of corporations, would you rather individuals be on the list? Is there any consensus, rough or otherwise, of Internet-specific resources the network operations community would like to have access? Ask now. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 4

Re: Who are you gonna call?
by Derek J. Balling 30 Jun '99

30 Jun '99

Another question -- how many people would be totally screwed if their phone suddenly LOST all their pre-programmed speed dials and their connectivity problems didn't allow them on-line access to find out what the numbers were... D At 01:47 PM 6/29/99 -0500, Michael P. Lucking wrote: >How about direct dial numbers (not toll-free). What would happen if you could >not dial a toll free number, but could call directly. How many people know >the Cisco TAC direct number in the US? > >On Tue, 29 Jun 1999, Sean Donelan wrote: > > > > > I went through my old tickets, and besides telephone repair, its remarkable > > how infrequently most of the Internet stuff we depend on breaks. So I > > based my list not on how likely something would break, but on how bad it > > would be if it did break. > > > > Nothing may happen, but assuming such a list affected the setting of > > priorities, any changes to my list and why? > > -- > > Sean Donelan, Data Research Associates, Inc, St. Louis, MO > > Affiliation given for identification not representation > > > > > > > >======================================================================= >Michael Lucking Michael(a)Lucking.COM >

6 6

Who are you gonna call?
by Sean Donelan 29 Jun '99

29 Jun '99

We're all doomed. Techweek reports Cisco CEO John Chambers plans to be working with his programmers on New Year's Eve. Anyone who has ever worked on a software project knows what kind of code gets produced by programmers while the CEO is hanging around :-) http://www.techweek.com/articles/6-28-99/countdow.htm On to something a little more serious, although its going to sound a bit strange. Imagine you had a special phone which always worked and can call any number in the world. It has just one limitation. The phone has only 9 speed-dial keys. And no cheating, you can't call the AT&T/MCI/Sprint/etc operator to dial a number which wasn't pre-programmed, and no third-party call forwarding. What Internet specific resources would you like to have access? Assume police, fire, medical, telephone repair, generator repair, etc are already handled. Here was my list: - Cisco TAC (Have you paid your IOS service contract yet?) - MFS (MAE-East tech on duty) - Merit (Route Server, Gated) - Internet Software Consortium (Have you paid your BIND service contract yet?) - UUNET NOC (if the 800lbs ISP falls over, we're all going to feel it) - Sendmail, Inc (after TCP/IP, mail is something all NOC's depend on) - Sun Microsystems (for those not running Linux) - ARIN (assuming APNIC and RIPE are mirrored) - My home phone (Family is important too) I went through my old tickets, and besides telephone repair, its remarkable how infrequently most of the Internet stuff we depend on breaks. So I based my list not on how likely something would break, but on how bad it would be if it did break. Nothing may happen, but assuming such a list affected the setting of priorities, any changes to my list and why? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 4

DEW #3 - 48 hours
by bmanning＠ISI.EDU 29 Jun '99

29 Jun '99

Hi, I appologize for duplicates. Its almost time for the next quarterly walk of the inverse tree of the DNS. For the last few quarters, I've been walking the in-addr tree looking for numbers of delegations, accurate delegations, and types and styles of error conditions. So... this is a heads up that you will be seeing zone transfers being generated by a couple of the collecter machines here. For those of you who utilize BINDs access controls, I'd appreciate your inclusion of the collector machines in allowed transfers. The expectation is that they will be the following IP addresses: 128.9.160.57 and 198.32.4.13 Past data is at: www.isi.edu/div7/people/bmanning.home/in-addr-audit.html The run is scheduled to start 01 July 1999 @ 00:01 UTC. If there are any questions or concerns, I'd be happy to talk about them. Past data has been presented at IEPG, Apricot and RIPE meetings. The expectation is that future data will be presented in the same and similar forums. -- bill manning 310.822.1511

1 0

Vendor Support Clue/NOC Clue
by Forrest W. Christian 28 Jun '99

28 Jun '99

NOTE: This is just something to think about.... It's not meant to start a flame war or another neverending thread. Please followup to me directly instead of the whole list. My opinion on what is really wrong with support - be it from a software, hardware, router vendor, or the NOC of some other ISP can be fairly easily summed up as follows: Each of us have varing levels of "Clue" depending on what you are talking about. Back in the "good ol' days", whenever you called support you got someone with at least as much clue as you did, thus, the clue relationship looked something like: Support Rep Clue >= Customer Clue This is good. Basically it means that you are at least talking to your equal, and someone who could probably understand what your problem was and if not fix it could at least go find someone else in the company (the engineer who built it) who knew more than they did. Now as things progressed, your favorite company added more and more customers - more and more of which had little clue. They found that a lot of the customers didn't have much of a clue at all. And they were having lots of problems keeping enough customer support reps with a high level of clue. So they decided to create the "1st level support rep". So, the clue relationship looks something like this: "typical customer" clue => 1st level support rep clue. "advanced customer" clue < 1st level support rep clue. The 1st level support reps are supposed to have enough of a clue to be able to tell when they don't have enough clue and to pass them up to the "2nd level support" - which might pass them up to a "3rd level support" and so on. The problem is that a typical 1st level support rep, for some reason or another rarely passes the problems up the chain. Might be company policy, might be personal pride or something. I've had numerous times that I've tried to deal with the 1st level rep and finally, after finally begging "is there someone else I can talk to" numerous times, getting passed onto someone else with more clue and the problem being fixed in less than 30 seconds. Here's the real thinker.... Is there a way that a company could set up their support lines so that "normal customers" get "1st level support reps" and "advanced (clueful) customers" get "2nd or higher level support reps"? Every time I think of an option, I can see a fatal flaw. Separate numbers would be abused. Certifications are expensive and mean nothing. And so on. There HAS to be a solution, we just haven't thought of it yet. So put on your thinking caps..... - Forrest W. Christian (forrestc(a)imach.com) ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------

4 3

IEPG?
by Howard C. Berkowitz 28 Jun '99

28 Jun '99

I hadn't noticed the usual announcement, then cancellation, then filling of the agenda for IEPG. Is that just because it's not North American this time? Howard

2 1

The Cidr Report
by Tony Bates 28 Jun '99

28 Jun '99

This is an auto-generated mail on Fri Jun 25 12:00:00 PDT 1999 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 25Jun99 0) General Status Table History ------------- Date Prefixes 180699 60164 190699 60219 200699 60266 210699 60373 220699 60763 230699 60904 240699 61044 250699 61068 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: 3806 Number of ASes announcing only one prefix: 1501 (322 cidr, 1179 classful) Largest number of cidr routes: 157 announced by AS6172 Largest number of classful routes: 811 announced by AS701 1) Gains by aggregating at the origin AS level --- 25Jun99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 350 148 202 57.7% BCnet Backbone AS4293 255 150 105 41.2% IMCI AS577 280 187 93 33.2% Bell Canada Backbone AS174 582 490 92 15.8% Performance Systems International AS7046 318 240 78 24.5% UUNET-CUSTOMER AS4200 179 101 78 43.6% AGIS (Apex Global Information Ser AS3749 137 63 74 54.0% TECNET AS7545 128 62 66 51.6% TPG Internet Pty Ltd AS7496 98 32 66 67.3% Power Up AS7122 139 78 61 43.9% MTS ADVANCED Network Policy AS1221 452 392 60 13.3% TELSTRA-AS AS1239 540 481 59 10.9% SprintLink Backbone AS4755 134 76 58 43.3% Videsh Sanchar Nigam Ltd. India AS9269 66 9 57 86.4% Hong Kong CTI AS7657 184 127 57 31.0% The Internet Group Limited AS72 95 39 56 58.9% Schlumberger Information Network AS4740 317 261 56 17.7% Ozemail Pty Ltd (ASN-OZEMAIL) AS10928 99 45 54 54.5% UNKNOWN AS2493 171 118 53 31.0% iSTAR Internet, Inc. AS719 462 410 52 11.3% LANLINK autonomous system AS3737 159 110 49 30.8% PenTeleData Inc. (ASN-PTD) AS549 222 178 44 19.8% ONet Backbone AS803 73 37 36 49.3% SaskNet Backbone AS3549 154 119 35 22.7% Frontier GlobalCenter AS6944 37 3 34 91.9% RapidSite, Inc. AS6172 153 119 34 22.2% HOME-NET-1 AS1 478 444 34 7.1% BBNPLANET AS1785 246 214 32 13.0% NYSERNet Backbone AS11515 32 1 31 96.9% UNKNOWN AS10479 36 5 31 86.1% ITESM-Rectoria Zona Norte 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

2 1