- Test - lists.nanog.org

Network collapses
by mark＠vielle.datasys.net 08 Jun '98

08 Jun '98

If a large network with large amounts of nonportable space, like UUNET, were to fail entirely (financially, or system-wide, e.g.), what would happen to the address space that that network had assigned to its customers? When those customers go elsewhere for access, would the routing tables be flooded with /24's? Alternately, would that space be reclaimed by the registries, and all of those customers be forced to renumber? How long would that take? In a similar vein, how would the DNS act with millions more lame delegations? (And what if all of the root servers were smurfed under at the same time? ;^) If this has been discussed elsewhere, I apologize for the bother, and would appreciate a pointer to that discussion. --- Mark R. Lindsey, mark(a)datasys.net Internet Engineering, DSS Online, LLC Voice: 912.241.0607; Fax: 912.241.0190 (Wish I were there.)

6 6

In the terminal room...
by James Klossner 08 Jun '98

08 Jun '98

People might want to be careful what binary you run in the terminal room if you're using ssh (or whatever). I happened to find this today while using them (extra junk snipped): % pwd /usr/home/nanog % ls -al ssh -rwxr-xr-x 1 nanog nanog 1218960 Jun 7 13:04 ssh % ./ssh -v SSH Version 1.2.22 [i386-unknown-freebsd2.2.6], protocol version 1.5. Standard version. Does not use RSAREF. [snipped] % which ssh /usr/local/bin/ssh % ls -al /usr/local/bin/ssh lrwxrwxrwx 1 root wheel 14 Jun 6 07:55 /usr/local/bin/ssh -> ../ssh/bin/ssh % ls -al /usr/local/ssh/bin/ssh lrwxrwxrwx 1 root wheel 4 Jun 6 07:55 /usr/local/ssh/bin/ssh -> ssh1 % ls -al /usr/local/ssh/bin/ssh1 -rws--x--x 1 root wheel 212952 May 20 09:20 /usr/local/ssh/bin/ssh1 % /usr/local/bin/ssh -v SSH Version 1.2.23 [i386-unknown-freebsd2.2.6], protocol version 1.5. Standard version. Does not use RSAREF. [snipped] Dot isn't in the path on these boxes, but you still might want to be careful anyway. Perhaps someone just brought over their own ssh binary, because they didn't trust the one here, or it could be something more malicious. I guess the moral of the story is to be careful about what you run on these machines. -jkk -- Jim Klossner - jkk(a)frontiernet.net http://www.frontiernet.net "VMS is about as secure as a poodle encased in a block of lucite... ...about as useful, too." -wendigo(a)pobox.com

1 0

MBONE / NANOG 13
by Adam Rothschild 08 Jun '98

08 Jun '98

Hey... Excuse my lameness, but could someone please fill me in on how to access the NANOG festivities over MBONE? I have vat and vic, and they seem to run fine, but no clue what to do from there... Thanks, Adam

1 0

flat vs non-flat charging
by Jerry Scharf 08 Jun '98

08 Jun '98

I think the idea of distance charging is going away in many cases. With WDM, the cost of the WDM and SONET eqiupment on the ends of a fully populated 32 channel per fiber, 144 strand pull vastly outweight end-to-end fiber costs of anything pulled through the ground. When you add routers and the like on top of that, the distance issue really goes away and it becomes on of network topology hops. Can anyone with figures for new intercontinental pulls say whether this is true there as well (project oxygen marketing claims this, but...)? Using archaic telephone pricing models to argue cost of providing bulk IP services is just not right. jerry

5 5

Re: More smurf networks. FIX YOUR ROUTERS.
by John Fraizer 07 Jun '98

07 Jun '98

While you IRC people are out checking for SMURF amplifier networks, perhaps you should check your own: [root@eth0-core0]:~ # ping 132.249.66.0 PING 132.249.66.0 (132.249.66.0): 56 data bytes 64 bytes from 132.249.66.6: icmp_seq=0 ttl=245 time=83.0 ms 64 bytes from 132.249.66.159: icmp_seq=0 ttl=244 time=84.3 ms (DUP!) 64 bytes from 132.249.66.148: icmp_seq=0 ttl=244 time=84.8 ms (DUP!) 64 bytes from 132.249.66.109: icmp_seq=0 ttl=244 time=85.3 ms (DUP!) 64 bytes from 132.249.30.7: icmp_seq=0 ttl=245 time=85.8 ms (DUP!) 64 bytes from 132.249.66.154: icmp_seq=0 ttl=53 time=86.3 ms (DUP!) 64 bytes from 132.249.66.62: icmp_seq=0 ttl=244 time=87.0 ms (DUP!) 64 bytes from 132.249.66.208: icmp_seq=0 ttl=244 time=87.4 ms (DUP!) 64 bytes from 132.249.66.140: icmp_seq=0 ttl=244 time=89.6 ms (DUP!) 64 bytes from 132.249.66.146: icmp_seq=0 ttl=244 time=90.1 ms (DUP!) 64 bytes from 132.249.66.45: icmp_seq=0 ttl=244 time=90.6 ms (DUP!) 64 bytes from 132.249.66.124: icmp_seq=0 ttl=53 time=91.1 ms (DUP!) 64 bytes from 132.249.66.229: icmp_seq=0 ttl=244 time=91.6 ms (DUP!) 64 bytes from 132.249.66.166: icmp_seq=0 ttl=244 time=92.1 ms (DUP!) --- 132.249.66.0 ping statistics --- 1 packets transmitted, 1 packets received, +13 duplicates, 0% packet loss round-trip min/avg/max = 83.0/87.7/92.1 ms [root@eth0-core0]:~ # ping 132.249.66.255 PING 132.249.66.255 (132.249.66.255): 56 data bytes 64 bytes from 132.249.66.159: icmp_seq=0 ttl=244 time=85.0 ms 64 bytes from 132.249.66.148: icmp_seq=0 ttl=244 time=86.1 ms (DUP!) 64 bytes from 132.249.66.109: icmp_seq=0 ttl=244 time=87.0 ms (DUP!) 64 bytes from 132.249.30.7: icmp_seq=0 ttl=245 time=87.5 ms (DUP!) 64 bytes from 132.249.66.154: icmp_seq=0 ttl=53 time=88.0 ms (DUP!) 64 bytes from 132.249.66.6: icmp_seq=0 ttl=245 time=88.5 ms (DUP!) 64 bytes from 132.249.66.62: icmp_seq=0 ttl=244 time=88.9 ms (DUP!) 64 bytes from 132.249.66.140: icmp_seq=0 ttl=244 time=89.5 ms (DUP!) 64 bytes from 132.249.66.146: icmp_seq=0 ttl=244 time=91.3 ms (DUP!) 64 bytes from 132.249.66.208: icmp_seq=0 ttl=244 time=91.8 ms (DUP!) 64 bytes from 132.249.66.45: icmp_seq=0 ttl=244 time=92.4 ms (DUP!) 64 bytes from 132.249.66.229: icmp_seq=0 ttl=244 time=92.9 ms (DUP!) 64 bytes from 132.249.66.124: icmp_seq=0 ttl=53 time=93.4 ms (DUP!) 64 bytes from 132.249.66.166: icmp_seq=0 ttl=244 time=93.9 ms (DUP!) --- 132.249.66.255 ping statistics --- 1 packets transmitted, 1 packets received, +13 duplicates, 0% packet loss round-trip min/avg/max = 85.0/89.7/93.9 ms ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

2 1

follow up for: System Hack and Data Stolen
by James McKenzie 07 Jun '98

07 Jun '98

Thank you to everyone who responded to this request for help. Colorado University has contacted me and we are working on the problem. Please do not think of this reflects in any way on the University, the user involved had a legitimate account and specifically used it as the user considered the site secure. James James McKenzie mcs(a)1ipnet.net http://www.1ipnet.net

1 0

Warning
by Jared Mauch 07 Jun '98

07 Jun '98

I'm doing a sweep of various networks that may be smurf amps. If you log an attempt from 204.42.254.5 trying to hit your boxes, it's just me. I will post a link to my results once I have the data. It should take me some time though. Thanks for your understanding in this matter. - jared -- Work: jared(a)qual.net - We Make The Internet Work for Your Business 9-5pm(ET) 800 637 4424x2634 - 24x7 NOC - 800 424 3223 pgp key available via finger from jared(a)puck.nether.net

1 0

Re: Hello, Detriot! This is not an operational message...
by elezar＠pfrc.org 07 Jun '98

07 Jun '98

On Sat, Jun 06, 1998 at 05:31:27PM -0400, Al Reuben wrote: > So, we're here. In the same lines, I'm interested to hear if anyone wants to do a Spam BOF or something similar sometime in the evening. I'll be here for the rest of the evening until after the "Interesting things you can do with ospf" talk. If anyone's interested, lets say we meet in the terminal room afterwards? -- Jeffrey Haas "He that breaks a thing to find out what it is has elezar(a)pfrc.org left the paths of wisdom." (Or works for Fermilab...)

1 0

Re: BGP4 and gated for Linux
by swright＠merit.edu 07 Jun '98

07 Jun '98

The latest public release of gated is 3.5.9 and is available at: ftp://gated.merit.edu/net-research/gated/gated-3-5-9.tar.gz Lots of information regarding licenses, bug reports, and releases can be found at http://www.gated.org/ Cheers, Shane -- Shane W. Wright /~_ _ _|_ _ |~\ Systems Research Programmer \_/ (_| | (/_ |_/ Merit Network, Inc. w w w . g a t e d . o r g

1 0

System Hack and Data Stolen
by James McKenzie 07 Jun '98

07 Jun '98

I'm looking for contacts for Colorado.edu. I'm the system administrator for Pathway Communications. Earlier to day our site was compromised. Data files were taken and the hardrive wiped. We have tracked him back to refuge.Colorado.edu and his home provider fastelane.net. Currently I have sent email to the contacts listed on Colorado.edu. I'm hoping someone reading this list may be with Colorado.edu or know someone who is. Any information you can provide is appreciated. The following is my contact information. James McKenzie mcs(a)1ipnet.net voice: 408/249-4780 pager: 408/233-9164 Thank you for your time. James James McKenzie mcs(a)1ipnet.net http://www.1ipnet.net

1 0