February 1998 - Test - lists.nanog.org

heh
by Bradley Reynolds 09 Feb '98

09 Feb '98

Good to see we practice what we preach. x0r:~$ ping 206.29.134.255 PING 206.29.134.255 (206.29.134.255): 56 data bytes 64 bytes from 206.29.134.34: icmp_seq=0 ttl=50 time=88.2 ms 64 bytes from 206.29.134.94: icmp_seq=0 ttl=241 time=88.8 ms (DUP!) 64 bytes from 206.29.134.95: icmp_seq=0 ttl=241 time=89.4 ms (DUP!) 64 bytes from 206.29.134.85: icmp_seq=0 ttl=241 time=90.5 ms (DUP!) 64 bytes from 206.29.134.240: icmp_seq=0 ttl=241 time=91.2 ms (DUP!) 64 bytes from 204.134.79.166: icmp_seq=0 ttl=242 time=92.5 ms (DUP!) 64 bytes from 206.29.130.33: icmp_seq=0 ttl=241 time=95.3 ms (DUP!) 64 bytes from 206.29.135.43: icmp_seq=0 ttl=49 time=95.9 ms (DUP!) 64 bytes from 206.29.135.83: icmp_seq=0 ttl=49 time=98.6 ms (DUP!) 64 bytes from 206.29.134.178: icmp_seq=0 ttl=240 time=103.1 ms (DUP!) 64 bytes from 206.29.135.81: icmp_seq=0 ttl=49 time=103.8 ms (DUP!) 64 bytes from 206.29.134.242: icmp_seq=0 ttl=49 time=104.7 ms (DUP!) 64 bytes from 206.29.135.67: icmp_seq=0 ttl=49 time=105.9 ms (DUP!) 64 bytes from 206.29.134.84: icmp_seq=0 ttl=49 time=106.6 ms (DUP!) 64 bytes from 206.29.134.70: icmp_seq=0 ttl=240 time=107.3 ms (DUP!) 64 bytes from 206.29.135.77: icmp_seq=0 ttl=49 time=107.8 ms (DUP!) 64 bytes from 206.29.134.36: icmp_seq=0 ttl=49 time=110.4 ms (DUP!) 64 bytes from 206.29.134.10: icmp_seq=0 ttl=240 time=110.8 ms (DUP!) 64 bytes from 206.29.134.222: icmp_seq=0 ttl=240 time=111.3 ms (DUP!) 64 bytes from 206.29.134.78: icmp_seq=0 ttl=49 time=112.2 ms (DUP!) 64 bytes from 206.29.135.244: icmp_seq=0 ttl=49 time=112.7 ms (DUP!) 64 bytes from 206.29.134.66: icmp_seq=0 ttl=49 time=113.3 ms (DUP!) 64 bytes from 206.29.135.56: icmp_seq=0 ttl=240 time=114.2 ms (DUP!) 64 bytes from 10.0.10.168: icmp_seq=0 ttl=240 time=116.0 ms (DUP!) 64 bytes from 206.29.135.246: icmp_seq=0 ttl=240 time=118.5 ms (DUP!) 64 bytes from 10.0.14.104: icmp_seq=0 ttl=240 time=119.0 ms (DUP!) 64 bytes from 10.0.3.156: icmp_seq=0 ttl=240 time=119.6 ms (DUP!) 64 bytes from 10.0.8.102: icmp_seq=0 ttl=240 time=121.3 ms (DUP!) 64 bytes from 206.29.134.15: icmp_seq=0 ttl=45 time=121.9 ms (DUP!) 64 bytes from 206.29.134.115: icmp_seq=0 ttl=240 time=122.6 ms (DUP!) 64 bytes from 206.29.135.82: icmp_seq=0 ttl=240 time=123.6 ms (DUP!) 64 bytes from 206.29.135.41: icmp_seq=0 ttl=240 time=125.0 ms (DUP!) 64 bytes from 206.29.134.104: icmp_seq=0 ttl=240 time=127.3 ms (DUP!) 64 bytes from 206.29.134.114: icmp_seq=0 ttl=240 time=128.7 ms (DUP!) 64 bytes from 206.29.134.82: icmp_seq=0 ttl=240 time=130.6 ms (DUP!) 64 bytes from 206.29.135.84: icmp_seq=0 ttl=240 time=143.2 ms (DUP!) 64 bytes from 206.29.134.100: icmp_seq=0 ttl=240 time=144.9 ms (DUP!) 64 bytes from 206.29.134.34: icmp_seq=1 ttl=50 time=92.1 ms 64 bytes from 204.134.79.166: icmp_seq=1 ttl=242 time=92.6 ms (DUP!) 64 bytes from 206.29.134.85: icmp_seq=1 ttl=241 time=93.5 ms (DUP!) 64 bytes from 206.29.134.94: icmp_seq=1 ttl=241 time=94.6 ms (DUP!) 64 bytes from 206.29.134.95: icmp_seq=1 ttl=241 time=96.4 ms (DUP!) 64 bytes from 206.29.134.240: icmp_seq=1 ttl=241 time=96.9 ms (DUP!) 64 bytes from 206.29.130.33: icmp_seq=1 ttl=241 time=98.9 ms (DUP!) 64 bytes from 206.29.135.244: icmp_seq=1 ttl=49 time=99.4 ms (DUP!) 64 bytes from 206.29.135.43: icmp_seq=1 ttl=49 time=104.5 ms (DUP!) 64 bytes from 10.0.14.104: icmp_seq=1 ttl=240 time=105.5 ms (DUP!) 64 bytes from 206.29.135.83: icmp_seq=1 ttl=49 time=106.1 ms (DUP!) 64 bytes from 206.29.134.66: icmp_seq=1 ttl=49 time=108.7 ms (DUP!) 64 bytes from 206.29.134.10: icmp_seq=1 ttl=240 time=109.4 ms (DUP!) 64 bytes from 206.29.134.36: icmp_seq=1 ttl=49 time=110.4 ms (DUP!) 64 bytes from 206.29.135.81: icmp_seq=1 ttl=49 time=111.0 ms (DUP!) 64 bytes from 10.0.3.156: icmp_seq=1 ttl=240 time=112.1 ms (DUP!) 64 bytes from 206.29.135.67: icmp_seq=1 ttl=49 time=114.6 ms (DUP!) 64 bytes from 206.29.134.70: icmp_seq=1 ttl=240 time=115.1 ms (DUP!) 64 bytes from 10.0.8.102: icmp_seq=1 ttl=240 time=115.6 ms (DUP!) 64 bytes from 206.29.134.78: icmp_seq=1 ttl=49 time=116.0 ms (DUP!) 64 bytes from 206.29.135.246: icmp_seq=1 ttl=240 time=116.6 ms (DUP!) 64 bytes from 206.29.134.84: icmp_seq=1 ttl=49 time=117.2 ms (DUP!) 64 bytes from 206.29.135.77: icmp_seq=1 ttl=49 time=117.7 ms (DUP!) 64 bytes from 206.29.134.222: icmp_seq=1 ttl=240 time=120.8 ms (DUP!) 64 bytes from 206.29.134.242: icmp_seq=1 ttl=49 time=123.2 ms (DUP!) 64 bytes from 206.29.135.56: icmp_seq=1 ttl=240 time=123.6 ms (DUP!) 64 bytes from 10.0.10.168: icmp_seq=1 ttl=240 time=124.2 ms (DUP!) 64 bytes from 206.29.134.178: icmp_seq=1 ttl=240 time=124.7 ms (DUP!) 64 bytes from 206.29.135.84: icmp_seq=1 ttl=240 time=125.3 ms (DUP!) 64 bytes from 206.29.135.82: icmp_seq=1 ttl=240 time=130.2 ms (DUP!) 64 bytes from 206.29.134.15: icmp_seq=1 ttl=45 time=130.8 ms (DUP!) 64 bytes from 206.29.134.115: icmp_seq=1 ttl=240 time=131.7 ms (DUP!) 64 bytes from 206.29.134.82: icmp_seq=1 ttl=240 time=134.1 ms (DUP!) 64 bytes from 206.29.134.104: icmp_seq=1 ttl=240 time=134.9 ms (DUP!) 64 bytes from 206.29.135.41: icmp_seq=1 ttl=240 time=135.3 ms (DUP!) 64 bytes from 206.29.134.100: icmp_seq=1 ttl=240 time=135.8 ms (DUP!) 64 bytes from 206.29.134.114: icmp_seq=1 ttl=240 time=136.2 ms (DUP!) 64 bytes from 206.29.134.34: icmp_seq=2 ttl=50 time=142.7 ms 64 bytes from 206.29.134.95: icmp_seq=2 ttl=241 time=143.5 ms (DUP!) 64 bytes from 206.29.134.85: icmp_seq=2 ttl=241 time=144.0 ms (DUP!) 64 bytes from 204.134.79.166: icmp_seq=2 ttl=242 time=144.5 ms (DUP!) 64 bytes from 206.29.134.94: icmp_seq=2 ttl=241 time=145.0 ms (DUP!) 64 bytes from 206.29.134.240: icmp_seq=2 ttl=241 time=145.4 ms (DUP!) BR brad reynolds ber(a)cwru.edu

1 0

Re: Real audio broadcast
by brandon＠rd.bbc.co.uk 09 Feb '98

09 Feb '98

> RealVideo is working now. Sort of, it selects pn.Washington.mci.net (it's all hidden away so the user has to dig to find out the server) as the server for us but that's broken - puts up the title then sits there saying buffering. This is the normal RealServer splitting failure mode, we get them all the time on ours and have to restart the server. Can whoever is liasing with Real get them to kick it? Thanks, Brandon

1 0

Re: MTU of the Internet?
by Per Gregers Bilse 09 Feb '98

09 Feb '98

FWIW, our router at MAE-East says: IP packet size distribution (38569M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .000 .400 .046 .016 .018 .012 .008 .009 .011 .012 .006 .007 .005 .004 .004 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .010 .006 .120 .000 .099 .197 .000 .000 .000 .000 .000 It's been up for some weeks and the sample size is, well, OK. As expected, large number at the low end, but I'm not sure what to think about the 2048 slot. I would have thought that once packets are bigger than ethernet MTU, they would also be bigger than 2048. If the numbers are true, then close to 1/3 of all packets (1536 slot plus 2048 slot) are larger than 576. -- ------ ___ --- Per G. Bilse, Director Network Eng & Ops ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at domain

15 20

Timeout problems in Cancun room
by Andy McConnell 09 Feb '98

09 Feb '98

I've noticed (and so has everyone at the table I'm sitting at!) there are sporadic timeouts on the local LAN. Is this because there are more than 4 or 5 hubs daisy chaned supporting more than a few hosts? -Andy -- Andy McConnell アンディマッコネル Network Architect, NTT Multimedia Communications Laboratories Madness takes its toll. Please have exact change.

2 1

Re: watch for video at noon MT
by Sean M. Doran 09 Feb '98

09 Feb '98

What a pity all of this happens at the beginning of the conference, when much of the really interesting stuff is happening... :( I hope the bits everyone is missing will be in the rebroadcast. Sean.

4 3

real networks != live
by Sean M. Doran 09 Feb '98

09 Feb '98

Hi - A couple of us are having fun actually seeing the video and audio now. kc is in the middle of her presentation from what we see and hear, while she is nearly finished with the Q&A session in reality according to the IRC crowd. Is this deliberate, or a side-effect of all the other fun problems being ironed out in this experiment? Sean. (who must admit the quality of the audio is wonderful and the video is actually watchable. Suggestion: MBONE for live stuff and real video/audio for archives)

1 0

Re: Stop
by Joe Shaw 09 Feb '98

09 Feb '98

NANOG is the North American Network Operators Group, and the nanog(a)merit.edu address is not only valid, but it acts as the mailing list for the group. And this is not a ghost mailer of any kind . I'm sitting in the computer room at teh NANOG 12 conference taking place until tomorrow afternoon, so please be clueful enough to understand what's going on here. Now, with that in mind, let's get this straight... 1: nanog(a)merit.edu isn't a bulk remailing service, it's a mailing list made up of people who subscribe to it. 2: Someone from your domain had to apply to get on the mailing list as it's not just something that happens by accident. 3: We're not using anyone's resources illegally (I am postmaster(a)insync.net) and if you want off the list, I'm sure whoever manages it will be more than happy to remove that address from it. BTW, if you had read any of those 200+ messages youd see that not only do we not like spam, we're actively looking for ways to stop it and keep it off our own networks. Good day, Joe Shaw - jshaw(a)insync.net NetAdmin - Insync Internet Services On Mon, 9 Feb 1998, Keith Hudgins wrote: > You have sent over 200 messages to the email address of allan(a)cass.iarc.com > within the last month. > > Issue #1 - You are spamming our system with bulk email that will not be > responded to. > > Issue #2 - There is _no_ email accound at cass.iarc.com for a username of > allan. > > Issue #3 - I realize that you are using a ghost email program to send mail > from somewhere else. I have forwarded this to every account I could extract > from the email header. It is unlawful to utilize the resources of a system > that you do not have permission to use. > > _________________________________________________________ > Keith Hudgins Technical Services Manager > IA Inc. phone 404-816-8786 > 247 Buckhead Ave. Suite 103 fax 404-816-4072 > Atlanta, GA 30305 http://www.iarc.net > > "If one studies too zealously, one easily loses his pants." > --Albert Einstein >

1 0

Re: Real audio broadcast
by Steve Hultquist 09 Feb '98

09 Feb '98

--On Monday, February 09, 1998, 12:35 PM -0800 "Sean M. Doran" <smd(a)clock.org> wrote: > Still no video/audio, real or otherwise... :( Connectivity has been a little... well... flakey here. It's not clear what the problem is, but it seems like the connection out of the hotel is having some periodic problems. That may be the reason for the periodic outages that you're seeing... -- Steve Hultquist, Chief Technology Officer HSAnet providing high-speed Internet access Boulder, Colorado mailto:ssh@HSAnet.net +1.303.581.0800 http://www.HSAnet.net/

1 0

Re: Real audio broadcast
by Sean M. Doran 09 Feb '98

09 Feb '98

I can no longer reach any of ihighway.net, fwiw... Sean.

1 0

Re: Real audio broadcast
by Sean M. Doran 09 Feb '98

09 Feb '98

The IRC play-by-play is making up for no live video/audio but there is ntill something missing. No chance for a standard MBONE back-up for avg's and kc's presentations (I consider them very important)? Or maybe a MERIT cell phone for me to call and listen in on? Sean.

1 0