February 2000 - Test - lists.nanog.org

Re: yahoo, again?
by Mike Tancsa 21 Feb '00

21 Feb '00

At 10:04 PM 2/21/2000 -0500, David Diaz wrote: >Yep seeing the same. It was working around 8:30PM EST Some paths seem to be working just fine 1 nero-eugene-hub.oregon-ix.net (198.32.162.2) [AS 2914] 4 msec 0 msec 0 msec 2 eugene-isp.nero.net (207.98.64.41) [AS 3701] 0 msec 4 msec 0 msec 3 xcore2-serial0-1-0.SanFrancisco.cw.net (204.70.32.5) [AS 3561] 12 msec 12 msec 12 msec 4 bordercore1.SanFrancisco.cw.net (166.48.12.1) [AS 3561] 12 msec 12 msec 12 msec 5 frontier-communications.SanFrancisco.cw.net (166.48.13.242) [AS 3561] 272 msec 112 msec 136 msec 6 pos4-2-155M.cr1.SNV.gblx.net (206.132.150.25) [AS 3549] 80 msec 80 msec 84 msec 7 pos0-0-2488M.hr8.SNV.gblx.net (206.132.254.37) [AS 3549] 80 msec 84 msec 80 msec 8 208.178.22.58 [AS 3549] 80 msec 84 msec 80 msec 9 www.yahoo.com (204.71.200.74) [AS 3549] 80 msec 80 msec 80 msec But others not. marble# traceroute www.yahoo.com traceroute to www.yahoo.com (204.71.200.67), 30 hops max, 40 byte packets 1 iolite-gate (199.212.134.14) 0.410 ms 0.366 ms 0.319 ms 2 hespler-border (205.211.165.178) 0.443 ms 0.447 ms 0.470 ms 3 206.222.95.25 (206.222.95.25) 1.116 ms 0.993 ms 0.960 ms 4 206.222.95.21 (206.222.95.21) 6.231 ms 4.504 ms 5.505 ms 5 brdr1-tor.tor.rns.net (206.222.64.2) 4.992 ms 6.241 ms 4.302 ms 6 sl-gw21-chi-5-1-0.sprintlink.net (144.232.188.149) 28.330 ms 28.046 ms 28.032 ms 7 sl-bb11-chi-1-1.sprintlink.net (144.232.10.37) 28.432 ms 28.785 ms 27.931 ms 8 sl-bb10-chi-9-0.sprintlink.net (144.232.10.49) 39.518 ms 59.201 ms 67.531 ms 9 sl-bb11-nyc-5-1.sprintlink.net (144.232.9.149) 68.574 ms 43.531 ms 53.200 ms 10 sl-bb1-nyc-4-0-0.sprintlink.net (144.232.7.10) 166.779 ms 189.807 ms 184.812 ms 11 sl-intsys-8-0-0-155M.sprintlink.net (144.232.171.130) 45.339 ms 48.740 ms 68.757 ms 12 * * * 13 * * * 14 * * * ---Mike

1 0

Re: whois broke again? (Cannot configure router with this one)
by Richard Irving 21 Feb '00

21 Feb '00

> The owner of each zone may choose to publish > relevent data in the zone(s) they control. " may " ... * shudder * "RFC Wish List": should, or even -SHALL-. :) > zero leverage * shudder * > This whole thing gets much tighter when/if we can get DNSSEC deployed > :) > Yes there are interesting scoping issues. Yes there are concerns wrt > evil people and tolerent applications. But this tactic clearly puts the > onus on the people in control of the useage, not some centralized repository. What I am contemplating is accountability during, say, a DDOS. My Point: Typical NOC response time (NRT) ~= 20 minutes. (+-) Total Reaction Time (TRT) = Sum of Noc Response Times. If NC = Noc Count, then: Overly simplified, TRT = (NC * NRT ) Therefore, as NC approaches infinity, so does TRT. :( "The greater the distance between an accountable entity, and the last traceable chain of authority on the net, typically, the greater the total reaction time for an incident." (As NC increases, so does, -typically-, TRT) Also, related: "The greater the total reaction time, the lower the probability of isolating and identifying a real time culprit." Traceable chains of authority are broken by A: Lack of Data B: MisDirection C: Variants of all the above. So, it would seem, IMHO that we should attempt to keep NC minimized, and to do so we would focus on strategies for minimizing A and B (effectively C). I support the idea of using BIND to replace/augment whois, however, I see a forthcoming Caveat: "A BIND based solution may help solve some of the B type problems, and accidental/temporary A's, while setting the stage for intentional type A's and B's" Whois was managed by NSI, who maintained at least a reasonable level of A. As such, -most- complaints appear to be oriented around B type issue's. Wait till A destabilizes, for real. As NC approaches infinity..... :( Any way we can nail both A, -and- B ? (See: "RFC Wish List" ) > YMMV. My point exactly. ;) </thinking out loud>

1 0

Re: whois broke again?
by Sean Donelan 21 Feb '00

21 Feb '00

On Mon, 21 February 2000, bmanning(a)vacation.karoshi.com wrote: > Yes there are interesting scoping issues. Yes there are concerns wrt > evil people and tolerent applications. But this tactic clearly puts the > onus on the people in control of the useage, not some centralized repository. That sounds great, except the time when WHOIS is most important is when the contact has totally screwed up their site and can't be reached by any in-band network. The nice thing about WHOIS is it tends to be out-of-band with respect to most screw-ups. The notable exception is when NSI screws-up. The open question is why can RIPE get people to put good data in their database, and NSI can't manage to keep the little correct data they have uncorrupted?

6 5

RE: UUNet problems in Chicago?
by Vincenzo Jon - IL 21 Feb '00

21 Feb '00

Yes! We are experiencing the same issue here in my office(Lombard,IL). They were very verbose in their explanation to me: 'We are experiencing problems with our network backbone in the chicago area and hope to have it resolved shortly.' EOM. Jon Vincenzo TUSC Lombard, IL (630)960-2909 > ---------- > From: Mark Radabaugh - Amplex[SMTP:mark@amplex.net] > Sent: Monday, February 21, 2000 3:54 AM > To: nanog(a)merit.edu > Subject: UUNet problems in Chicago? > > > Anyone have any information on UUNets problems in Chicago? Very heavy > ping / packet loss on several links. > > Mark Radabaugh - Amplex > (419) 833-3635 > mark(a)amplex.net > > >

1 0

Re: whois broke again?
by bmanning＠vacation.karoshi.com 21 Feb '00

21 Feb '00

> >>>> delegation glue ? > >> > >> and how/where did you get your AS & delegation? > > Public viewable data will have no verification, > and ARIN/NSI/JPNIC/ETC will be in the critical path > for timely resolution of said corrected data. > > [Seriously -Pregnant- Pause] ok, ICANN delegates 64.0.0.0/8 to ARIN. ARIN delegates 64.64.0.0/16 to BillsBait&Sushi BBS delegates 64.64.0.0/20 to OnCall OnCall delegates 64.64.0.0/24 to AviFreedman There is a DNS inverse delegation at every point (granted w/o verification today) where each site publishes a zone file. There is a chain of custody at each delegation point. The owner of each zone may choose to publish relevent data in the zone(s) they control. ARIN has near zero leverage on OnCall for the delegations it makes to Avi. OnCall however does have leverage since there is an existing business relationship w/ Avi. This whole thing gets much tighter when/if we can get DNSSEC deployed at least in the inverse tree. Yes there are interesting scoping issues. Yes there are concerns wrt evil people and tolerent applications. But this tactic clearly puts the onus on the people in control of the useage, not some centralized repository. YMMV. --bill

1 0

Re: SMTP in distributed DOS
by Michael Shields 21 Feb '00

21 Feb '00

In article <20000220110421.A16950(a)noc.power.net>, Dirk Harms-Merbitz <dirk(a)power.net> wrote: > Why don't we all just turn SMTP bounces OFF? Like return-receipts, > the information content in bounces is very low. MTAs must not silently drop mail. Mail is precious. -- Shields.

3 2

Forgot to forward this to the list: stats for multicast sessions nanog 18 feb 6-8
by Joel Jaeggli 21 Feb '00

21 Feb '00

discrete joins per day Mpeg-1 h.261 trailer 02/02/2000 8 14 02/02/2000 10 14 02/04/2000 9 20 02/05/2000 1 4 conference 02/06/2000 30 15 02/07/2000 100 70 02/08/2000 48 75 as measured by streamwatch from the UO campus. joelja -------------------------------------------------------------------------- Joel Jaeggli joelja(a)darkwing.uoregon.edu Academic User Services consult(a)gladstone.uoregon.edu PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -------------------------------------------------------------------------- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843.

1 0

RE: Test message....problem solved!
by Vincenzo Jon - IL 21 Feb '00

21 Feb '00

Thanks to everyone for your kind responses. It was a 'chair-to-keyboard interface' problem. I subscribed to post, but not to the main list! Dumb. Sorry. JV

1 0

Re: SMTP in distributed DOS
by Michael Shields 21 Feb '00

21 Feb '00

> AOL's MTAs silently drop mail instead of denying it at the border. No, they don't: Return-Path: <> Delivered-To: shields(a)challah.msrl.com Received: (qmail 15733 invoked by alias); 21 Feb 2000 17:17:31 -0000 Delivered-To: alias-msrl-shields(a)msrl.com Received: (qmail 15730 invoked for bounce); 21 Feb 2000 17:17:30 -0000 Date: 21 Feb 2000 17:17:30 -0000 From: MAILER-DAEMON(a)challah.msrl.com To: shields(a)msrl.com Subject: failure notice Lines: 29 Xref: challah.msrl.com MSRL.COM:10378 Hi. This is the qmail-send program at challah.msrl.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <ntbhekcaedkreukdr(a)aol.com>: 205.188.156.130 does not like recipient. Remote host said: 550 MAILBOX NOT FOUND Giving up on 205.188.156.130. --- Below this line is a copy of the message. Return-Path: <shields(a)msrl.com> Received: (qmail 15728 invoked by uid 1000); 21 Feb 2000 17:17:10 -0000 Sender: shields(a)challah.msrl.com To: ntbhekcaedkreukdr(a)aol.com Subject: test From: Michael Shields <shields(a)msrl.com> Organization: Mad Science Research Labs Date: 21 Feb 2000 17:17:10 +0000 Message-ID: <87n1oueaqx.fsf(a)challah.msrl.com> Lines: 3 User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Bryce Canyon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii -- Shields. -- Shields.

1 0

Re: NYT on Internet traffic reporting
by Michael Shields 21 Feb '00

21 Feb '00

In article <20000221061552.7878.cpmta(a)c004.sfo.cp.net>, Sean Donelan <sean(a)donelan.com> wrote: > The New York Times has an article about Internet traffic reporting today. > > http://www.nytimes.com/library/tech/00/02/biztech/articles/21view.html Headline: "Traffic and Weather Get Regular Updates. Why Not the Internet?" But it would be very depressing if the public decided that network congestion and server failure were a normal event, as they do with road congestion and inclement weather. -- Shields.

1 0