- Test - lists.nanog.org

More route-table bloat vs. ARIN micro-allocations
by John M. Brown 22 Feb '00

22 Feb '00

so I decided to poke around some more... I really can't see how the argument of ""Route / AS-Path" table bloat is going to break things if ARIN starts doing mico-allocations for providers that need to multi-home, but don't need tons of space. I really like the /30's, /32's... Wonder if AS 4293 really needs the diversity with /28's and /27's I count a total of 145 >/24 routes coming from AS 3561 Of course this doesn't even begin to count all the Net-63 /24 breakouts, the Net-12 /24 breakouts, etc....... If people really started doing there part on cleaning up their announcements I bet we could reduce the total routes back down to some nice number........ *> 63.84.242.192/26 166.48.176.25 0 3561 14510 i *> 128.88.250.0/27 166.48.176.25 0 3561 2516 2915 2915 2915 2915 151 i *> 128.88.250.32/29 166.48.176.25 0 3561 2516 2915 2915 2915 2915 151 i *> 137.39.250.20/30 166.48.176.25 0 3561 i *> 158.205.225.40/29 166.48.176.25 0 3561 4694 ? *> 166.32.131.160/27 166.48.176.25 0 3561 i *> 166.35.174.160/27 166.48.176.25 0 3561 i *> 206.98.105.48/28 166.48.176.25 0 3561 4293 i *> 206.141.223.224/27 166.48.176.25 0 3561 6081 7053 7053 7053 7053 i *> 206.142.63.0/28 166.48.176.25 0 3561 i *> 206.151.223.0/26 166.48.176.25 0 3561 4293 i *> 206.151.223.64/28 166.48.176.25 0 3561 4293 i *> 206.151.223.80/28 166.48.176.25 0 3561 4293 i *> 206.151.223.96/27 166.48.176.25 0 3561 4293 i *> 206.151.223.128/27 166.48.176.25 0 3561 4293 i *> 206.151.223.160/28 166.48.176.25 0 3561 4293 i *> 206.151.223.180/30 166.48.176.25 0 3561 4293 i *> 206.151.223.184/30 166.48.176.25 0 3561 4293 i *> 206.151.223.188/30 166.48.176.25 0 3561 4293 i *> 206.151.223.192/27 166.48.176.25 0 3561 4293 i *> 206.152.253.0/27 166.48.176.25 0 3561 4293 i *> 206.157.77.40/30 166.48.176.25 0 3561 i *> 206.157.77.56/30 166.48.176.25 0 3561 i *> 206.157.77.96/30 166.48.176.25 0 3561 i *> 206.157.77.108/30 166.48.176.25 0 3561 i *> 206.157.77.152/30 166.48.176.25 0 3561 i *> 206.157.77.200/30 166.48.176.25 0 3561 i *> 206.157.77.208/30 166.48.176.25 0 3561 i *> 206.171.94.0/26 166.48.176.25 0 3561 3549 13405 i *> 206.218.185.192/26 166.48.176.25 0 3561 3549 i *> 207.49.17.192/28 166.48.176.25 0 3561 4293 i *> 207.51.164.128/26 166.48.176.25 0 3561 11192 i

10 13

enough already on SNV
by Dana Hudes 22 Feb '00

22 Feb '00

Please don't be the umpteenth person to tell me that SNV is Sunnyvale CA and that yes it really is an OC-48

1 0

yahoo, again?
by David Bird 22 Feb '00

22 Feb '00

5 san1.dfw2.verio.net (129.250.2.242) 40.465 ms 39.994 ms 40.208 ms 6 dfw2.dfw3.verio.net (129.250.3.74) 40.082 ms 40.07 ms 39.986 ms 7 s11-1-0.ar1.DAL1.gblx.net (206.132.119.125) 40.922 ms 40.487 ms 40.493 ms 8 pos2-0-155M.cr2.DAL1.gblx.net (206.132.119.117) 41.231 ms 40.6 ms 40.704 ms 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * -- David Bird dbird(a)bpnetworks.com http://www.bpnetworks.com/

9 9

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

22 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 22 Feb '00

22 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 22 Feb '00

22 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