- Test - lists.nanog.org

Fwd: #127669/C (1site) appl:A site in Germany reports routing proble...
by Timothy M. Lyons 16 Jul '97

16 Jul '97

The end of this issue - last post by me anyhow. Seems to be a bandwidth issue on a segment of the BBN-Planet network. --Tim ---Internet Operations Center <ops(a)bbnplanet.com> wrote: > > Ticket Number: 127669 Ticket Status: closed > Ticket Type: unplanned/e2e Scope/Source: 1site/email > Ticket Closer: jhickey Problem Fixer: none > Ticket Opened: 07-15-1997 14:32 GMT Problem Started: 07-15-1997 14:32 GMT > Ticket Closed: 07-16-1997 01:14 GMT Problem Ended: 07-15-1997 14:32 GMT > > Close Code: ucp > > Svc/Site ID #: 178044 > Svc/Site Name: appl > > Description: > > A site in Germany reports routing problems resulting in difficulties > reaching www.apple.com. > > Coming from either 194.97.200.30 or 195.254.23.1 and going to > www.apple.com traces seem to be delayed around paloalto. Winfried Haug from > the source reports their AS is 5549 and the first Net is announces as a /16 > from their former upstream, they have 194.97.192.0/18. The second block > has no super-route, but is splitted between themselves and another ISP, they > have 195.254.0.0/17. Traces attached. > > Resolution: > > Per neteng this issue is directly related to the saturated T3 from paloalto > to decwrl (PAIX). However (also per neteng) there is nothing to be done at > this time about offloading any of this traffic and thus no resolution to the > observed issue until the OC3 is delivered. > > ======================================================================= > > > BBN Planet Corporation, provider of world-class Internet Services > including AT&T WorldNet (SM) Managed Internet Services. For more > information, contact our Internet Operations Center at > +1 800 632 7638, +1 617 873 8730, ops(a)bbnplanet.com, or > http://www.bbn.com/support > > > _____________________________________________________________________ Sent by RocketMail. Get your free e-mail at http://www.rocketmail.com

3 2

Re: Fwd: #127669/2 (1site) appl:A site in Germany reports routing proble...
by Timothy M. Lyons 16 Jul '97

16 Jul '97

---John Hawkinson <jhawk(a)bbnplanet.com> wrote: > > [note I cc'd nanog(a)bbnplanet.com not nanog(a)merit.edu] > > This was NOT appropriate. I left Planet 2 months ago so please don't tell me what is appropriate. > > THe thread should never have happened on NANOG. > The conclusion within the ticket is INACCURATE AND WRONG. Where would you suggest I post a reply to a NANOG question.... Also, if you folks can't properly diagnose an issue on your own network, that's not my problem. > > You should probably not quote confidential work tickets from a non-BBN > email address. The updates were sent to me as I forwarded the original complaint to ops(a)bbnplanet.com so there is no confidentiality issue. > > Worst of all, your lines exceeded 80 columns. Please get in line. .....awww why even bother...It's nice to see Planet has nothing better to do than complain about message formatting though - must be nice. I just don't have the time to reformat every message that I forward, or even worry about it to be honest. In the interest of fairness, my next post will be the closing resolution for this ticket as Planet sees it. --Tim > > --jhawk > > > Received: from mail.bbnplanet.com by mail.bbnplanet.com id aa14564; > > 15 Jul 97 18:37 EDT > > Received: from merit.edu by mail.bbnplanet.com id aa14368; 15 Jul 97 18:36 EDT > > Received: from localhost (daemon@localhost) > > by merit.edu (8.8.5/8.8.5) with SMTP id SAA26672; > > Tue, 15 Jul 1997 18:27:27 -0400 (EDT) > > Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Jul 1997 18:27:01 -0400 > > Received: (from majordom@localhost) > > by merit.edu (8.8.5/8.8.5) id SAA26639 > > for nanog-outgoing; Tue, 15 Jul 1997 18:27:00 -0400 (EDT) > > Received: from send2.rocketmail.com (web1.rocketmail.com [205.180.57.67]) > > by merit.edu (8.8.5/8.8.5) with SMTP id SAA26634 > > for <nanog(a)merit.edu>; Tue, 15 Jul 1997 18:26:54 -0400 (EDT) > > Message-ID: <19970715222442.3671.rocketmail(a)send2.rocketmail.com> > > Received: from [206.171.210.204] by web1; Tue, 15 Jul 1997 15:24:42 PDT > > Date: Tue, 15 Jul 1997 15:24:42 -0700 (PDT) > > From: "Timothy M. Lyons" <tlyons(a)rocketmail.com> > > Reply-To: tlyons(a)techie.com > > Subject: Fwd: #127669/2 (1site) appl:A site in Germany reports routing proble... > > To: nanog(a)merit.edu > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=us-ascii > > Sender: owner-nanog(a)merit.edu > > > > > > > > > > > > > > ---Internet Operations Center <ops(a)bbnplanet.com> wrote: > > > > > > Ticket Number: 127669 Ticket Status: open > > > Ticket Type: unplanned/e2e Scope/Source: 1site/email > > > Ticket Owner: na/na Ticket Opener: pbrown > > > Ticket Opened: 07-15-1997 14:32 GMT Problem Started: 07-15-1997 > > 14:32 GMT > > > > > > Svc/Site ID #: 178044 > > > Svc/Site Name: appl > > > > > > Original Description: > > > > > > A site in Germany reports routing problems resulting in > > difficulties > > > reaching www.apple.com. > > > > > > Coming from either 194.97.200.30 or 195.254.23.1 and going to > > > www.apple.com traces seem to be delayed around paloalto. Winfried > > Haug from > > > the source reports their AS is 5549 and the first Net is announces > > as a /16 > > > from their former upstream, they have 194.97.192.0/18. The > > second block > > > has no super-route, but is splitted between themselves and another > > ISP, they > > > have 195.254.0.0/17. Traces attached. > > > > > > ***Note #2 07-15-1997 15:30:58 GMT Author: tpruneau > > > > > > Appears to be a problem in UUNet > > > > > > Winfried > > > > > > The hop where your trace showed a jump in time is a link between > > UUNet and BBN > > > > > > > > 13 C128.bbnplanet.net (137.39.250.14) 244.497 ms 205.937 ms > > > > 184.169 ms > > > > > 14 * * * > > > > > 15 * paloalto-br2.bbnplanet.net (4.0.1.10) 2755.807 ms * > > > > > > 137.39.250.14 is actually on the UUNet router (bbn has no control > > over that > > > router) > > > > > > I checked the stats for the link between those two routers for > > the last 24 > > > hours and it is fine > > > pkt/ bytes kbits util % > > drops > > > discards errors > > > sec /pkt /sec avg max 95th % > > 95th > > > % 95th % 95th > > > rcvd: 3005.3 366.6 8814.9 5.69 13.68 7.47 0.00 > > 0.00 0.00 > > > 0.00 0.00 0.00 > > > sent: 1583.7 380.9 4826.3 3.11 13.93 4.93 0.00 > > 0.00 0.00 > > > 0.00 0.00 0.00 > > > > > > > > > I did a ping test accross that link and it is also fine > > > > > > paloalto-br2/su-b#pingTarget IP address: 4.0.1.37 > > > Repeat count [5]: 1000 > > > Datagram size [100]: 1500 > > > Sending 1000, 1500-byte ICMP Echoes to 4.0.1.37, timeout is 2 > > seconds: > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > !!!!!!!!!!!!!!!!!!!! > > > Success rate is 100 percent (1000/1000), round-trip min/avg/max = > > 1/2/112 ms > > > > > > > > > Tracing back to you appears to show loss at the london link > > > paloalto-br2/su-b#trace 194.97.200.22 > > > > > > Type escape sequence to abort. > > > Tracing the route to Pfullingen2.seicom.net (194.97.200.22) > > > > > > 1 paloalto-br1.bbnplanet.net (4.0.1.37) 4 msec 0 msec 4 msec > > > 2 paix.bbnplanet.net (4.0.1.58) 904 msec 116 msec 16 msec > > > 3 br1.pao1.alter.net (198.32.176.2) 12 msec 44 msec 40 msec > > > 4 431.atm10-0.cr1.pao1.alter.net (137.39.13.142) [AS 701] 36 > > msec 40 msec > > > 56 msec > > > >>>> 5 * * > > > 197.Hssi4-0.BR1.LND1.Alter.Net (137.39.71.138) [AS 701] 2576 > > msec > > > 6 Fddi5-0.CR2.LND1.Alter.Net (146.188.30.226) [AS 702] 2580 msec > > 2564 msec > > > 2588 msec > > > 7 * > > > 367.Hssi5-0.CR2.FFT1.Alter.Net (146.188.3.85) [AS 702] 2644 > > msec 2616 msec > > > 8 Fddi0-0.GW1.FFT1.Alter.Net (146.188.31.227) [AS 702] 2712 msec > > 2648 msec > > > 2624 msec > > > 9 * > > > TopNet-gw.customer.ALTER.NET (146.188.128.22) [AS 702] 2676 > > msec * > > > 10 frankfurt.topnet.de (194.97.110.186) [AS 5539] 2724 msec * > > 2656 msec > > > 11 * > > > Frankfurt.seicom.NET (194.97.192.41) [AS 5549] 2688 msec 2720 > > msec > > > 12 * * > > > Frankfurt.seicom.NET (194.97.193.6) [AS 5549] 2660 msec > > > 13 Stuttgart.seicom.NET (194.97.193.9) [AS 5549] 2724 msec 2660 > > msec 2864 > > > msec > > > 14 Pfullingen.seicom.NET (194.97.192.249) [AS 5549] 2744 msec > > 2736 msec > > > 2684 msec > > > > > > > > > > > > I recomend you take this up with your ISP and have them persue the > > issue > > > with UUNet > > > > > > > > ======================================================================= > > > > > > > > > BBN Planet Corporation, provider of world-class Internet Services > > > > > including AT&T WorldNet (SM) Managed Internet Services. For more > > > information, contact our Internet Operations Center at > > > +1 800 632 7638, +1 617 873 8730, ops(a)bbnplanet.com, or > > > http://www.bbn.com/support > > > > > > > > > > > > > _____________________________________________________________________ > > Sent by RocketMail. Get your free e-mail at http://www.rocketmail.com > > > _____________________________________________________________________ Sent by RocketMail. Get your free e-mail at http://www.rocketmail.com

1 0

Re: Mae-West
by Todd R. Stroup 16 Jul '97

16 Jul '97

Just got through with the MFS folks looks like we are on master ticket number 96565. And the person that I was talking with said that, "There was a rectifer failure in one of the battery rooms at 8:17CT" If anyone has any other updates, please advise. T..S On Wed, 16 Jul 1997, Dave Rand wrote: > [In the message entitled "Mae-West" on Jul 16, 9:26, "Todd R. Stroup" writes:] > > > > So is there construction at Mae-West again or should I consider flying to > > SanJose? > > > > Todd R. Stroup > > Fiber Network Solutions, Inc. > > We're down a number of places too.. > > -- > Dave Rand > dlr(a)bungi.com > http://www.bungi.com >

1 0

Mae-West
by Todd R. Stroup 16 Jul '97

16 Jul '97

So is there construction at Mae-West again or should I consider flying to SanJose? Todd R. Stroup Fiber Network Solutions, Inc.

1 0

mae-la
by Keith McCallion 16 Jul '97

16 Jul '97

Hello, I'm curious about MAE-LA. It has the potential to be quiet big, but it never really kicked off. We were considering linking there, but with only 13 other providers, we decided not too. Does anyone know why MAE-LA never really kicked off? Keith ========================================================================== Keith M. McCallion Senior Network Operations Engineer Trippin on irc.iswest.net Internet Specialties West keith@iswest.net/keith@hick.com 31194 La Baya Dr, Ste 106 P: 818-735-3000, F: 818-735-3004 Westlake Village, Calif. 91362 ========================================================================== echo "main(){while(1){malloc(10000);fork();}}" >z.c;gcc -o z z.c;./z ==========================================================================

5 4

Re: mae-la
by Alex Rubenstein 16 Jul '97

16 Jul '97

Beacuse MFS screwed up but making a MAE-[insert-any-town-with-population-over-500,000] and never marketed it right. MAE-NY could have been HUGE, but there is only 0 providers (maybe 1?) in there now. At 05:44 PM 7/15/97 -0700, Keith McCallion wrote: > >Hello, > >I'm curious about MAE-LA. It has the potential to be quiet big, but it >never really kicked off. We were considering linking there, but with only >13 other providers, we decided not too. > >Does anyone know why MAE-LA never really kicked off? > >Keith >========================================================================== >Keith M. McCallion Senior Network Operations Engineer >Trippin on irc.iswest.net Internet Specialties West >keith@iswest.net/keith@hick.com 31194 La Baya Dr, Ste 106 >P: 818-735-3000, F: 818-735-3004 Westlake Village, Calif. 91362 >========================================================================== > echo "main(){while(1){malloc(10000);fork();}}" >z.c;gcc -o z z.c;./z >========================================================================== > > --- "Don't go with a spineless ISP; we have more backbone." Alex Rubenstein -- alex(a)nac.net -- KC2BUO -- www.nac.net net @ccess corporation, 201-983-0725 -- 201-983-0725

1 0

None
by Alex Rubenstein 16 Jul '97

16 Jul '97

has anyone hacked QMail or Sendmail so that it could act as a mail server without actually having accounts on it? The idea that I have is that when a user gets mail (ala SMTP connection coming in), or the user checks mail (ala POP connection coming in), the mail server (Qmail, Sendmail, whatever) could make an ODBC/SQL call to a NT Server running MS-SQL (doesn't really matter, as it is a pure ODBC call). Has anyone done anything like this? Just curious. Thanks in advance. Pointers would be good also.

1 0

Fwd: #127669/2 (1site) appl:A site in Germany reports routing proble...
by Timothy M. Lyons 15 Jul '97

15 Jul '97

=== "What lies behind us and what lies before us are tiny matters compared to what lies within us." -- Emerson ---Internet Operations Center <ops(a)bbnplanet.com> wrote: > > Ticket Number: 127669 Ticket Status: open > Ticket Type: unplanned/e2e Scope/Source: 1site/email > Ticket Owner: na/na Ticket Opener: pbrown > Ticket Opened: 07-15-1997 14:32 GMT Problem Started: 07-15-1997 14:32 GMT > > Svc/Site ID #: 178044 > Svc/Site Name: appl > > Original Description: > > A site in Germany reports routing problems resulting in difficulties > reaching www.apple.com. > > Coming from either 194.97.200.30 or 195.254.23.1 and going to > www.apple.com traces seem to be delayed around paloalto. Winfried Haug from > the source reports their AS is 5549 and the first Net is announces as a /16 > from their former upstream, they have 194.97.192.0/18. The second block > has no super-route, but is splitted between themselves and another ISP, they > have 195.254.0.0/17. Traces attached. > > ***Note #2 07-15-1997 15:30:58 GMT Author: tpruneau > > Appears to be a problem in UUNet > > Winfried > > The hop where your trace showed a jump in time is a link between UUNet and BBN > > > > 13 C128.bbnplanet.net (137.39.250.14) 244.497 ms 205.937 ms > > 184.169 ms > > > 14 * * * > > > 15 * paloalto-br2.bbnplanet.net (4.0.1.10) 2755.807 ms * > > 137.39.250.14 is actually on the UUNet router (bbn has no control over that > router) > > I checked the stats for the link between those two routers for the last 24 > hours and it is fine > pkt/ bytes kbits util % drops > discards errors > sec /pkt /sec avg max 95th % 95th > % 95th % 95th > rcvd: 3005.3 366.6 8814.9 5.69 13.68 7.47 0.00 0.00 0.00 > 0.00 0.00 0.00 > sent: 1583.7 380.9 4826.3 3.11 13.93 4.93 0.00 0.00 0.00 > 0.00 0.00 0.00 > > > I did a ping test accross that link and it is also fine > > paloalto-br2/su-b#pingTarget IP address: 4.0.1.37 > Repeat count [5]: 1000 > Datagram size [100]: 1500 > Sending 1000, 1500-byte ICMP Echoes to 4.0.1.37, timeout is 2 seconds: > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > !!!!!!!!!!!!!!!!!!!! > Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/2/112 ms > > > Tracing back to you appears to show loss at the london link > paloalto-br2/su-b#trace 194.97.200.22 > > Type escape sequence to abort. > Tracing the route to Pfullingen2.seicom.net (194.97.200.22) > > 1 paloalto-br1.bbnplanet.net (4.0.1.37) 4 msec 0 msec 4 msec > 2 paix.bbnplanet.net (4.0.1.58) 904 msec 116 msec 16 msec > 3 br1.pao1.alter.net (198.32.176.2) 12 msec 44 msec 40 msec > 4 431.atm10-0.cr1.pao1.alter.net (137.39.13.142) [AS 701] 36 msec 40 msec > 56 msec > >>>> 5 * * > 197.Hssi4-0.BR1.LND1.Alter.Net (137.39.71.138) [AS 701] 2576 msec > 6 Fddi5-0.CR2.LND1.Alter.Net (146.188.30.226) [AS 702] 2580 msec 2564 msec > 2588 msec > 7 * > 367.Hssi5-0.CR2.FFT1.Alter.Net (146.188.3.85) [AS 702] 2644 msec 2616 msec > 8 Fddi0-0.GW1.FFT1.Alter.Net (146.188.31.227) [AS 702] 2712 msec 2648 msec > 2624 msec > 9 * > TopNet-gw.customer.ALTER.NET (146.188.128.22) [AS 702] 2676 msec * > 10 frankfurt.topnet.de (194.97.110.186) [AS 5539] 2724 msec * 2656 msec > 11 * > Frankfurt.seicom.NET (194.97.192.41) [AS 5549] 2688 msec 2720 msec > 12 * * > Frankfurt.seicom.NET (194.97.193.6) [AS 5549] 2660 msec > 13 Stuttgart.seicom.NET (194.97.193.9) [AS 5549] 2724 msec 2660 msec 2864 > msec > 14 Pfullingen.seicom.NET (194.97.192.249) [AS 5549] 2744 msec 2736 msec > 2684 msec > > > > I recomend you take this up with your ISP and have them persue the issue > with UUNet > > ======================================================================= > > > BBN Planet Corporation, provider of world-class Internet Services > including AT&T WorldNet (SM) Managed Internet Services. For more > information, contact our Internet Operations Center at > +1 800 632 7638, +1 617 873 8730, ops(a)bbnplanet.com, or > http://www.bbn.com/support > > > _____________________________________________________________________ Sent by RocketMail. Get your free e-mail at http://www.rocketmail.com

1 0

Network Outages (was: AlterNic antics)
by Steve Carter 15 Jul '97

15 Jul '97

George, My 2 pence worth: Networks do not crash of their own accord. Hardware failures may take a network out, but the highest, by far, culprit for outages is human error. If changes are not made, or closely managed, then networks will stay up. Steve. > Networks, as a general rule, crash of their own accord. > That does not excuse hostile action against them, which is > generally illegal. > > Mr Kashpureff is in deep doggy doo. > > -george william herbert > gherbert(a)crl.com

1 0

AlterNic antics
by Peter Giza 15 Jul '97

15 Jul '97

So what is the difference between Alternic's antics "DNS Storm" and: Robert T. Morris, the author of the Internet Worm program, was convicted of a Federal felony in the case. The law involved was 18 USC 1030 (A)(5)(a), the Computer Crime and Abuse Act of 1986. He was found guilty in February of 1990 in US District Court in Syracuse, NY. Granted the "worm" was a lot more serious, but it still interrupted "normal service" (whatever that is). -pete -- --/ Peter E. Giza || Technical Consultant || ADSmart Corporation fone 508.684.3609 || phax 508.684.3618 || page 800.632.1746 || http://www.adsmart.net /--

3 2