- Test - lists.nanog.org

Re: NATs *ARE* evil!
by Jeff Mcadams 16 Dec '00

16 Dec '00

Also sprach David R Huberman >> We're currently efficiently (according to ARIN's guidelines) >> utilizing a /20, 2 /23's and a /24. We apply to ARIN for space, and >> what do they say they'll give us? A /20. Period. Someone care to >> explain this to me? >It means you didn't explain your goals clearly enough, I guess. What is there to explain? >If you demonstrate to ARIN efficient utilization of 21 /24s (as you >describe above), you qualify for 32 /24s for renumbering purposes; a /19. >Go back and show them you've used 21 /24s efficiently and ask for >sufficient address space with which to renumber and grow your business. >You'll get a /19 every time. Hello...I'm using *more* than a /20 right *now*. If I had 100% efficient utilization of the IP addresses that we're using *today* I couldn't fit into just a /20. I can't come up with *any* logic that would make sense to renumber into a /20. This information was clearly spelled out on our application. If the folks at ARIN are too dense to add a few numbers together, you'd think they'd at least drop us an email or a phone call and ask a question or two! Sheesh! There is *NO* excuse for ARIN here, what they've done with us has *NO* rational explanation. -- Jeff McAdams Email: jeffm(a)iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

7 8

Create Your Own Fake Id's From Home
by vic112＠mail.net 15 Dec '00

15 Dec '00

1 0

Re: multi-homing without the BGP (was RE: Packet Loss)
by Paul Vixie 15 Dec '00

15 Dec '00

WOW. Now THAT is juxtaposition! dan(a)netrail.net (Daniel Golding) writes: > You don't really need a /20 to multihome or use BGP. Just get an ASN, > multiple providers, and advertise your space. ... tbates(a)cisco.com (Tony Bates) writes: > Table History > ------------- > Date Prefixes > 081200 95404 > 091200 95823 > 101200 95806 > 111200 95907 > 121200 95679 > 131200 95592 > 141200 95583 > 151200 95822 In other words, see http://www.academ.com/nanog/feb1997/multihoming.html.

1 0

RE: Packet Loss
by Karyn Ulriksen 15 Dec '00

15 Dec '00

Just a quick story involving punched tape distribution. The meteorogist in the story has since past away - but he would have appreciated it if these packets *had* been lost: Briefly: Mom's best friend's husband was a meteorologist for the government up on Donner Summit (the infamous one!). He had this handy typewriter that spat out punched tape. You could pass the punch tape back through and it would regenerate what ever you typed. Cool! There was a toggle on the gadget that allowed you to regenerate on the local teletype or broadcast to ALL the teletypes across the U.S. - generally used to distribute locally gather weather statistics. Well, my friends and I liked singing and I found the lyrics to "Bad, Bad Leroy Brown" (showing my age here). I probably don't have to go on here with what happened. Just suffice it to say that the punched tapes worked great and every meteorologist in the US had five copies of the lyrics. I'm sure that everyone was wondering what people were eating up on Donner Pass this season! K > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: Friday, December 15, 2000 10:20 AM > To: John R. Grant > Cc: Roeland Meyer; Valdis.Kletnieks(a)vt.edu; 'Scott Bradner'; > nanog(a)merit.edu > Subject: Re: Packet Loss > > > > In message > <Pine.LNX.4.30.0012150921140.15394-100000(a)grant.liveonthenet.com>, " > John R. Grant" writes: > >Yesterday, Roeland Meyer wrote: > >> I know for certain that it dates back to the pain-frame > daze and originally > >> refered to 9600 baud open-reel tape <snip> > > > ><cringe> > >that would be 9600 bit per inch GCR format 9-track tape, > don't you think? > ></cringe> > > They didn't have nearly that density -- when I heard the > phrase, it was > 800 or 1600 bits per linear inch (1600' reels), with 8 bits (plus > parity) across. And 200 bpi 6-track tapes were still in use, > though being > phased out. > > > --Steve Bellovin > > >

1 0

The Cidr Report
by Tony Bates 15 Dec '00

15 Dec '00

This is an auto-generated mail on Fri Dec 15 12:00:00 PST 2000 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 15Dec00 0) General Status Table History ------------- Date Prefixes 081200 95404 091200 95823 101200 95806 111200 95907 121200 95679 131200 95592 141200 95583 151200 95822 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 *** Bogus 219.219.219.0 from AS2563 AS Summary ---------- Number of ASes in routing system: 9359 Number of ASes announcing only one prefix: 5425 (3034 cidr, 2391 classful) Largest number of cidr routes: 1190 announced by AS705 Largest number of classful routes: 1678 announced by AS1221 1) Gains by aggregating at the origin AS level --- 15Dec00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1678 1238 440 26.2% TELSTRA-AS AS2563 264 82 182 68.9% KoRean Education Network AS701 1593 1434 159 10.0% Alternet AS271 284 131 153 53.9% BCnet Backbone AS9269 167 48 119 71.3% Hong Kong CTI AS7545 166 50 116 69.9% TPG Internet Pty Ltd AS8013 455 349 106 23.3% PSINET-CA AS6595 162 63 99 61.1% DODDSEUR AS7657 277 188 89 32.1% The Internet Group Limited AS13999 94 6 88 93.6% UNKNOWN AS705 326 242 84 25.8% ALTERNET-AS AS4755 189 105 84 44.4% Videsh Sanchar Nigam Ltd. India AS174 530 449 81 15.3% Performance Systems International AS4293 340 260 80 23.5% Internal ASN for C&W AS7496 100 23 77 77.0% Power Up AS7046 328 251 77 23.5% UUNET-CUSTOMER AS4151 282 208 74 26.2% USDA Internet Access Network AS724 243 170 73 30.0% DLA-ASNBLOCK-AS AS1727 172 99 73 42.4% MRMS-WEST AS3908 236 164 72 30.5% Supernet, Inc. AS1942 137 65 72 52.6% FR-CICG-GRENOBLE AS577 242 171 71 29.3% Bell Backbone AS7018 594 528 66 11.1% AT&T WorldNet Service Backbone AS5106 101 37 64 63.4% AADS-COLUMBUS AS3749 123 59 64 52.0% TECNET AS226 167 104 63 37.7% USC/Information Sciences Institut AS3602 307 249 58 18.9% Sprint Canada Inc. AS2548 366 308 58 15.8% DIGEX-AS AS16758 63 6 57 90.5% UNKNOWN AS376 133 77 56 42.1% RISQ 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: Packet Loss
by Steven M. Bellovin 15 Dec '00

15 Dec '00

In message <Pine.LNX.4.30.0012150921140.15394-100000(a)grant.liveonthenet.com>, " John R. Grant" writes: >Yesterday, Roeland Meyer wrote: >> I know for certain that it dates back to the pain-frame daze and originally >> refered to 9600 baud open-reel tape <snip> > ><cringe> >that would be 9600 bit per inch GCR format 9-track tape, don't you think? ></cringe> They didn't have nearly that density -- when I heard the phrase, it was 800 or 1600 bits per linear inch (1600' reels), with 8 bits (plus parity) across. And 200 bpi 6-track tapes were still in use, though being phased out. --Steve Bellovin

1 0

RE: Packet Loss
by Muir, Ronald 15 Dec '00

15 Dec '00

That's mylar punched paper tape for bootstraps. :-----Original Message----- :From: Hugh Irvine [mailto:hugh@open.com.au] :Sent: Friday, December 15, 2000 11:51 AM :To: tme(a)21rst-century.com; Marshall Eubanks; Valdis.Kletnieks(a)vt.edu; :nanog@merit.edu :Subject: Re: Packet Loss : : : : :Hello all - : :> :> Real Men use punched paper tape to store programs and :load the boot :> block, after toggling :> its binary location on the system console register :) The :Gods Who Walk :> Among Us program in machine :> code by toggling it in at the console. :> :> (I still have some punched paper tape somewhere. I remember feeling :> impressed when I graduated to :> punched cards. They didn't tend to crack if you had a string :of all bits :> set to one.) :> :> On the other hand, I did tens of thousands of lines of code on IBM :> punched cards and I never :> once recall a bug caused by a chad, hanging or otherwise. :> : :Further to my previous post, we used to use punched paper tape :as the absolute :fall-back to boot the acquisition sytem (we didn't take disks :to sea back then). : :We had a heck of a time keeping the tapes dry.... : :;-) : :Hugh : :-- :Radiator: the most portable, flexible and configurable RADIUS server :anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. :- :Nets: internetwork inventory and management - graphical, extensible, :flexible with hardware, software, platform and database independence. : : :

1 0

Re: NATs *ARE* evil!
by Jeff Mcadams 15 Dec '00

15 Dec '00

Also sprach David R Huberman >> (it has been a royal pain to get anyone on the phone at ARIN in the >> past) >That is a patently false statement. >Since late 1997, ARIN staff have answered the phone on the first ring, >generally. You'll never get a busy signal or a complicated phone tree. >Stating that ARIN doesn't answer the phone is so wildly incorrect it >makes me wonder why you would say such a thing. And who on earth are *you* to tell *me* what *my* experience with ARIN has been. I *have* had a nightmare of a time getting anyone from ARIN on the phone in the past, and for you to say that you haven't doesn't invalidate my experiences. Perhaps I haven't found the same phone numbers that you have or something, but my experience has been that I have *always* had a hard time getting anyone from ARIN on the phone...shoot...first time I wanted to try, I couldn't even find a phone number on their web site to even *attempt* it...this has since changed, but ARIN does have a history of being *extremely* difficult to deal with. It seems they are attempting to improve this. They needed to. -- Jeff McAdams Email: jeffm(a)iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

1 0

RE: Packet Loss
by Roeland Meyer 15 Dec '00

15 Dec '00

> From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Thursday, December 14, 2000 10:52 AM > > > Can we call on the Avian Carrier RFC here? Packet Loss may > take on a whole > > new meaning here... > > especially for the bulk transfer mode Never under-estimate the bandwidth of a mini-van filled with DLT tapes, on the freeway at 65 mph. - updated to current - rmeyer - original author unknown

7 6

Re: Packet Loss
by David Lesher 15 Dec '00

15 Dec '00

It's distressing to realize there are at least three things in my message the vast majority here will likely look at with a ?huh?: Trailblazers 9 Track tape ftp by mail Sigh..... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

2 1