- NANOG - lists.nanog.org

Re: URL for Sean's presentation
by sob＠academ.com 08 Jun '98

08 Jun '98

1 0

Re: NANOG 'Cast
by Simon Leinen 08 Jun '98

08 Jun '98

The Mbone feed is excellent, too, here in Switzerland. -- Simon Leinen simon(a)babar.switch.ch SWITCH http://www.switch.ch/

1 0

Re: Load balancing/Multiple CNAME's (Was: Re: Beyond DNS...)
by Paul Vixie 08 Jun '98

08 Jun '98

manar(a)ivision.co.uk (Manar Hussain) writes: > Actually I'm not so sure - I can well imagine that a reasonably well > publicised change in how DNS works in order to make "the web better" would > probably get adopted more readily in browsers than mere conformance to well > documented, already existent RFCs that are currently flouted. i imagined that, which is why i contributed to RFC 2052. but i was wrong. the browser vendors don't think of this as one of their important problems. -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul(a)vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

2 1

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