February 2000 - Test - lists.nanog.org

SERVER NAMES
by DeepBlue 08 Feb '00

08 Feb '00

This is a little off of the normal lines of the list. But I am at a loss as to what naming convention I should use with my new set of servers. I have already used Southpark, Jet sons,and Warner brothers cartoons. Does any one have any good suggestions other than the Super Friends? I apologize ahead of time if this email seems useless to some of you.. but humor me please. James james(a)iceblue.net <mailto:james@iceblue.net>

32 37

RealMedia feed down since 3:15 ?
by Kai Schlichting 07 Feb '00

07 Feb '00

The RealMedia feed died around 3:15 PST. Reason ? bye,Kai

1 0

nanog media recordings ?
by Kai Schlichting 07 Feb '00

07 Feb '00

Whatever became of the Real Audio/Video recordings of NANOG-17 ? I checked the web page but couldn't find any links to previous meeting's AV recordings. Given that lots of people are in different time zones (and have day ops to attend to), they might want to watch NANOG-18 in time-delayed fashion. Any chance that this (NANOG-18 recordings) is going up today after hours ? Thanks, bye,Kai

1 0

RE: Audio Quality
by Craig Labovitz 07 Feb '00

07 Feb '00

You should send email to nanog-support(a)nanog.org for all questions/problems about NANOG meetings, the web page, or the mailing list. - Craig > -----Original Message----- > From: Daniel Senie [mailto:dts@senie.com] > Sent: Monday, February 07, 2000 2:00 PM > To: nanog(a)merit.edu > Subject: Re: Audio Quality > > > > David Brouda wrote: > > > > Agreed, audio is better now. Also, the video bit-rate is more > > reasonable now (128kbps for a non-changing image, compared > to 400kbps > > previously). > > Both audio and video are much better now. Is there a proper email to > reach the folks running the service for feedback/problem reports? > > One plea: please leave the video live (mute audio if desired) during > lunch breaks and such. Real doesn't provide a very good > methodology for > finding out when a session is back... when you stop the live feed, the > session ends, and attempts to reconnect tell you you've got a > bad (old) > URL. > > > > > At 4:38 PM -0500 2/7/00, CUNNINGHAM(a)PSC.EDU wrote: > > > >Also, the audio in the H.261 stream is a bit distorted. > Perhaps the > > > >input level to the machine generating the stream need > to be turned > > > >down? > > > > > >This seems to have improved. Thanks. > > > > > >I'm not getting any audio on the MPEG2 stream. Is it just me? > > > > > >Steve > > > -- > ----------------------------------------------------------------- > Daniel Senie dts(a)senie.com > Amaranth Networks Inc. http://www.amaranthnetworks.com >

1 0

RE: Audio Quality
by David Brouda 07 Feb '00

07 Feb '00

Agreed, audio is better now. Also, the video bit-rate is more reasonable now (128kbps for a non-changing image, compared to 400kbps previously). At 4:38 PM -0500 2/7/00, CUNNINGHAM(a)PSC.EDU wrote: > >Also, the audio in the H.261 stream is a bit distorted. Perhaps the > >input level to the machine generating the stream need to be turned > >down? > >This seems to have improved. Thanks. > >I'm not getting any audio on the MPEG2 stream. Is it just me? > >Steve

2 1

Re: Yahoo network outage
by Declan McCullagh 07 Feb '00

07 Feb '00

Yep, it's back up for me too. Total three hours outage, apparently. -Declan At 15:29 2/7/2000 -0600, Andy Walden wrote: >It appears to be up now. > >Cnet (www.news.com) had an article in it where Yahoo appeared to take >responsibility.

1 0

Re: Worldcom and Qwest switch places
by michael.dillon＠gtsip.net 07 Feb '00

07 Feb '00

On Sat, 05 February 2000, Sean Donelan wrote: > Since Lucent equipment was also involved in the 10 days of Worldcom problems, > is there a common root cause between the Worldcom's problems and Qwest's > problems? Is there some lesson other providers should be learning from > these events? Or is each service provider expected to learn and re-learn > these lessons individually? Is there some network design decision engineers > are getting wrong? Lucent people told me that the Worldcom problem resulted from a software upgrade to Worldcom's Lucent switches that was done without having a good fallback plan. Lucent engineers had recommended a different strategy to Worldcom but Worldcom went ahead and did it their way. Then the software upgrade triggered some kind of cascading problem that either affected the old code or travelled through the network or both. In other words, they created a problem as a side effect of the upgrade but didn't have agood strategy to contain or kill the problem that propogated like some kind of living organism. Seems to me that we *HAVE* seen this type of problem before in the Internet with things like AS7007 routes which seemed to hang around parts of the net for days. How do you plan to rollback to a known state when you can't simply backtrack or reverse your actions? --- Michael Dillon Phone: +44 (20) 7769 8489 Mobile: +44 (79) 7099 2658 Director of Product Engineering, GTS IP Services 151 Shaftesbury Ave. London WC2H 8AL UK

1 0

RR.COM has backbone problems
by Vadim Antonov 07 Feb '00

07 Feb '00

I tried to contact their NOC, but the bozo on call didn't even want to hear what the problem is, advising me to contact my cable provider (how helpful). Please if there's anyone with a clue from RR.COM / MEDIAONE.NET or any other Time Warner holding - wake up, you've got a big problem. It doesn't show on your network monitors, but it is sure to screw your customers. And, please track down who was on the NOC telephone ((703) 345-3416) at this time (see message headers) and kick him hard for being an idiot and not taking a real trouble report. It appears that somehow long packets between boxes 24.218.189.197 and 24.218.188.118 get corrupted: kitty 67: ping -s1500 24.218.188.118 PING 24.218.188.118 (24.218.188.118): 1500 data bytes 1508 bytes from 24.218.188.118: icmp_seq=0 ttl=246 time=164.0 ms wrong data byte #1404 should be 0x7c but was 0xaa 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 <skipped> 1508 bytes from 24.218.188.118: icmp_seq=1 ttl=246 time=164.6 ms 1508 bytes from 24.218.188.118: icmp_seq=2 ttl=246 time=166.1 ms 1508 bytes from 24.218.188.118: icmp_seq=3 ttl=246 time=164.7 ms 1508 bytes from 24.218.188.118: icmp_seq=5 ttl=246 time=164.3 ms 1508 bytes from 24.218.188.118: icmp_seq=6 ttl=246 time=168.6 ms wrong data byte #1404 should be 0x7c but was 0xaa 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 <skipped> 1508 bytes from 24.218.188.118: icmp_seq=7 ttl=246 time=163.9 ms wrong data byte #924 should be 0x9c but was 0xaa 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 <skipped> kitty 70: ping -s1500 24.218.189.197 PING 24.218.189.197 (24.218.189.197): 1500 data bytes 1508 bytes from 24.218.189.197: icmp_seq=0 ttl=248 time=144.3 ms 1508 bytes from 24.218.189.197: icmp_seq=1 ttl=248 time=83.2 ms 1508 bytes from 24.218.189.197: icmp_seq=2 ttl=248 time=82.4 ms 1508 bytes from 24.218.189.197: icmp_seq=3 ttl=248 time=80.8 ms 1508 bytes from 24.218.189.197: icmp_seq=4 ttl=248 time=80.9 ms kitty 72: /usr/sbin/traceroute 24.218.189.170 traceroute: Warning: Multiple interfaces found; using 205.158.141.97 @ eth0 traceroute to 24.218.188.118 (24.218.188.118), 30 hops max, 40 byte packets 1 192.168.203.1 (192.168.203.1) 19.680 ms 19.540 ms 19.521 ms 2 mpk.core.rtr.wavepath.net (205.158.140.129) 19.825 ms 19.699 ms 21.328 ms 3 pop.access.rtr.wavepath.net (205.158.140.249) 21.097 ms 21.252 ms 21.030 ms 4 pop.border.rtr.wavepath.net (205.158.140.1) 21.204 ms 21.146 ms 23.449 ms 5 us-ca-scl-web1-e8.rtr.concentric.net (205.158.7.97) 22.883 ms 21.793 ms 22.879 ms 6 us-ca-scl-border2-fe4-0d0.rtr.concentric.net (207.88.95.9) 24.269 ms 101.210 ms 23.812 ms 7 us-ca-scl-core2-g5-0-0.rtr.concentric.net (207.88.1.3) 23.506 ms 24.663 ms 22.793 ms 8 PacBellrr.com (198.32.128.50) 23.761 ms 25.667 ms 26.280 ms 9 pabrt02-pabrt03.rr.com (24.218.189.197) 26.108 ms 57.919 ms 24.778 ms 10 24.218.188.118 (24.218.188.118) 110.427 ms * 116.969 ms 11 bsgsr01-nygsr01.rr.com (24.218.188.21) 116.396 ms 115.738 ms 116.053 ms 12 cambrt01-bsgsr01.rr.com (24.128.191.58) 113.668 ms 114.166 ms 115.836 ms 13 cmrtr01-srp3.ne.mediaone.net (24.218.189.170) 113.589 ms 114.720 ms 113.175 ms (Note that the problem affects all _transit_ packets): kitty 78: ping -s1500 24.218.188.21 PING 24.218.188.21 (24.218.188.21): 1500 data bytes 1508 bytes from 24.218.188.21: icmp_seq=1 ttl=245 time=525.0 ms 1508 bytes from 24.218.188.21: icmp_seq=2 ttl=245 time=171.2 ms 1508 bytes from 24.218.188.21: icmp_seq=3 ttl=245 time=173.8 ms 1508 bytes from 24.218.188.21: icmp_seq=4 ttl=245 time=174.3 ms wrong data byte #1404 should be 0x7c but was 0xaa 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 <skipped> Regards, --vadim

4 4

Re: DNS problem at NANOG18
by Michael Shields 07 Feb '00

07 Feb '00

In article <4.2.2.20000207125404.02969100(a)ianai.net>, I Am Not An Isp <patrick(a)ianai.net> wrote: > There do not seem to be even reverses for the wireless IPs. The nameserver the DHCP server is handing out knows about the reverses somehow, but the in-addr delegation chain is broken. And there are no forwards. -- Shields.

2 1

Simple? Question...
by NANOG Mailing List 07 Feb '00

07 Feb '00

Can someone please tell me what I need to do in order to have secondary interfaces on a Cisco report themselfs as the alias IP rather than the primary interface IP address in a traceroute? Example: FastEthernet 1/0/1 has a primary address of 10.1.1.1 It has a secondary address of 172.16.1.1 In a traceroute, where it would be expected that the box report itself as 172.16.1.1, it is reporting itself as 10.1.1.1 Is there a way to remedy this situation and have it report itself as the IP address that is actually being used for that flow?

2 1