- Test - lists.nanog.org

Re: Root name server
by shields＠crosslink.net 01 Apr '98

01 Apr '98

In article <E0yK4f3-0000Kd-00@rhenium>, "Dave Haywood" <D.Haywood(a)btinternet.com> wrote: > I need to setup an internal root name server in my private network. Maybe you should ask on a DNS list. NANOG is about the Internet and you are asking about a private network. I think this is covered in Cheswick and Bellovin anyway, but I haven't looked in a long time. -- Shields, CrossLink.

2 1

RE: Operational issue: Packet loss at Pacbell NAP
by Goldstein_William＠bns.att.com 01 Apr '98

01 Apr '98

TO ALL NANOG PROPELLERHEAD TYPES MAKIN' REMARKS ON ATM: Da switch makers, ya know, dese guys had a problem. No matter how good business was, da stock keeps goin' down. Wid MPOA solvin' alla da problems, dey figured dis was unfair, dat dey should be solid, steadily growing stocks now dat dey no longer had to live life in da fast LANE. So, da ATM Forum has decided to sorta upgrade da public relations approach. Please be advised dat all youse geniusues makin' skeptical an' udderwise unsundry remarks on ATM is now subject to a personal interview from a special representative udda ATM Forum. On da boat. On a nice, long ocean voyage... (And alla youse gigabit ethernet wanks--ya know what we can do wid a little ether, heh, heh, heh!) Bill "The Mangler" Goldstein Chief Crusher and Mixer Dept. of Concrete Overshoes Enforcement Division The ATM Forum ;-) ---------- From: dlr Sent: Monday, March 30, 1998 6:41 PM To: nanog Cc: dlr Subject: Operational issue: Packet loss at Pacbell NAP Received: from wayne1.bns.att.com (wayne1.bns.att.com [135.170.166.240]) by pawayn01.bns.att.com (8.8.6/1.3) with ESMTP id SAA13273 for <Goldstein_William/bcs_pawayn01(a)pawayn01.bns.att.com>; Mon, 30 Mar 1998 18:49:24 -0500 (EST) Received: from caig1.att.att.com (caig1.att.att.com [192.128.52.73]) by wayne1.bns.att.com (8.7.3/2.5) with ESMTP id TAA19164 for <goldstein_william(a)bns.att.com>; Mon, 30 Mar 1998 19:01:20 -0500 (EST) Received: (from nuucp@localhost) by caig1.att.att.com (AT&T/GW-1.0) id SAA11015; Mon, 30 Mar 1998 18:49:21 -0500 (EST) >Received: by cagw1.att.com; Mon Mar 30 18:42 EST 1998 Received: by cagw1.att.com; Mon Mar 30 18:42 EST 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA24784; Mon, 30 Mar 1998 18:44:17 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 30 Mar 1998 18:41:07 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA24671 for nanog-outgoing; Mon, 30 Mar 1998 18:41:06 -0500 (EST) Received: from daver.bungi.com (daver.bungi.com [207.126.97.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA24666 for <nanog(a)merit.edu>; Mon, 30 Mar 1998 18:41:01 -0500 (EST) Received: by daver.bungi.com via sendmail with stdio id <m0yJoAm-0000DnC(a)daver.bungi.com> for nanog(a)merit.edu; Mon, 30 Mar 1998 15:41:00 -0800 (PST) (Smail-3.2.0.94 1997-Apr-22 #8 built 1997-Jun-19) Message-Id: <m0yJoAm-0000DnC(a)daver.bungi.com> From: dlr(a)bungi.com (Dave Rand) Date: Mon, 30 Mar 1998 15:41:00 PST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: nanog(a)merit.edu Subject: Operational issue: Packet loss at Pacbell NAP Sender: owner-nanog(a)merit.edu Content-Type: text -------------------------------------------------- Several of my peers at PB NAP are reporting significant loss (>10%) over the PB NAP. All are OC3 connected, and it seems that PB doesn't have the ability to look too closely at OC3 connections. Death of the 'net predicted: film at 11. So, does this mean that ATM NAPs also have problems with high traffic load? -- Dave Rand dlr(a)bungi.com http://www.bungi.com

2 1

RE: Operational issue: Packet loss at Pacbell NAP
by dlr＠bungi.com 01 Apr '98

01 Apr '98

[In the message entitled "RE: Operational issue: Packet loss at Pacbell NAP" on Mar 31, 16:49, "Ellis, Stephen C (PTSS-scellis)" writes:] > > Nope. The problem is link congestion between SJC and SFO. Pacbell > > was apparently not monitoring this. By rerouting some traffic, they > > were able to shift the peers that it affected. It, with 100% > > certainty, > > is within the cloud that makes up the PB NAP. > > > > > We've identified the facts that occured in this particular situation. > The problem was definitely **not** due to link congestion as we have > stats on the utilization of the OC3s. The rerouting which occured as a > result of this problem has been corrected. Not to beat you too badly, but the situation yesterday I was told was due to saturated trunks between SJC and SFO. Moving traffic from those saturated trunks immediately alleviated the problem on those peers. The problem identified today (with different peers) I was told was due to an ATM routing problem. There are several different problems active, I suspect. As each of the NAPs get to high utilization levels, various failure modes will manifest. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

RE: Seattle Sprint outage - update?
by Peter Murray 31 Mar '98

31 Mar '98

I've not had any problems recently getting through to knowledgeable people at Sprint via their Virginia call center. Try (800) 232-6895, and select option 3. I was talking with one of the fellows there on Friday afternoon, and he was fully aware of the fiber cut. Best Regards, -Pete Pete Murray - FASTNET(tm) / You Tools Corporation > pete(a)fast.net (610) 954-5200 - http://www.fast.net > FASTNET - Business and Personal Internet Solutions > > > -----Original Message----- > From: Joe Rhett [SMTP:jrhett@ISite.Net] > Sent: Tuesday, March 31, 1998 2:00 PM > To: randy(a)psg.com > Cc: nanog(a)merit.edu > Subject: Re: Seattle Sprint outage - update? > > > > > Any one from Sprint care to enlighten us on the major fiber cut in > > > > Seattle? > > > Isn't it a damned shame that a company the size of Sprint does not > have a > > NOC. <sigh> > > Try sarcasm that isn't true. It is a damn shame, and they don't have > anything to speak of. Their response center is downright useless, even > when > you pay them for the priveledge. > > The only way to get something out of Sprint is to know someone. If you > don't know someone, it would seem that lists like Nanog are your only > choice. > > I don't agree, but I don't see a better path either. > > -- > Joe Rhett Systems > Engineer > JRhett(a)ISite.Net ISite > Services > > PGP keys and contact information: > http://www.navigist.com/Staff/JRhett

1 0

Re: Operational issue: Packet loss at Pacbell NAP
by dlr＠bungi.com 31 Mar '98

31 Mar '98

[In the message entitled "Re: Operational issue: Packet loss at Pacbell NAP" on Mar 31, 14:53, "Kent W. England" writes:] > > I wouldn't jump to conclusions. Not likely that the ATM switches are > backplane loaded like the MAEs. These are Stratacom BPXs that replaced the > Newbridge 36150s over three years ago. Correct. > High bandwidth-delay product paths on a heavily loaded OC-3 to OC-3 virtual > circuit will strain the ATM switch buffers. If you can detect regularly > recurring losses on a high BDP path across an all-OC3 virtual circuit, then > look for buffer exhaustion on the OC3 interfaces. If no one at Pac Bell > knows what to do, tell them to look in the files in Fred Chang's Network > Engineering Group for Kent England's ATM NAP switch test plan and go out and > get some test gear that will stress an OC3 link in the lab. Mike Rudik in > the lab knows what to do to test for this. But my recollection was that the > BPX had enough buffers to run UBR over a full OC3. Nope. The problem is link congestion between SJC and SFO. Pacbell was apparently not monitoring this. By rerouting some traffic, they were able to shift the peers that it affected. It, with 100% certainty, is within the cloud that makes up the PB NAP. > > If the loss is on DS3-OC3 virtual circuits then perhaps you are pushing more > than 45 Mbps toward the DS3. There might be a Kentrox ADSU or two left on > the NAP that could have trouble with the cisco OC3 interface at much less > than 45 Mbps. Again, these are OC3 to OC3 in all cases. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: Operational issue: Packet loss at Pacbell NAP
by Kent W. England 31 Mar '98

31 Mar '98

>Several of my peers at PB NAP are reporting significant loss (>10%) over the >PB NAP. All are OC3 connected, and it seems that PB doesn't have the >ability to look too closely at OC3 connections. > >Death of the 'net predicted: film at 11. > >So, does this mean that ATM NAPs also have problems with high traffic load? > >-- >Dave Rand >dlr(a)bungi.com >http://www.bungi.com > I wouldn't jump to conclusions. Not likely that the ATM switches are backplane loaded like the MAEs. These are Stratacom BPXs that replaced the Newbridge 36150s over three years ago. High bandwidth-delay product paths on a heavily loaded OC-3 to OC-3 virtual circuit will strain the ATM switch buffers. If you can detect regularly recurring losses on a high BDP path across an all-OC3 virtual circuit, then look for buffer exhaustion on the OC3 interfaces. If no one at Pac Bell knows what to do, tell them to look in the files in Fred Chang's Network Engineering Group for Kent England's ATM NAP switch test plan and go out and get some test gear that will stress an OC3 link in the lab. Mike Rudik in the lab knows what to do to test for this. But my recollection was that the BPX had enough buffers to run UBR over a full OC3. If the loss is on DS3-OC3 virtual circuits then perhaps you are pushing more than 45 Mbps toward the DS3. There might be a Kentrox ADSU or two left on the NAP that could have trouble with the cisco OC3 interface at much less than 45 Mbps. If the cisco OC3 interfaces haven't been thoroughly shaken down, you might look there for things like buffer exhaustion. If the ciscos are losing, my test plan should show that effect if the ciscos are included in the test path. If no one at PacBell seems interested in the problem, you can talk to the Texans who run the place now. I can give you some names to call in Richardson, Texas but I wouldn't hold my breath. If you happen to be a Texan, then you can probably get something to happen, but if you are an avocado-sucking Hawaiian-shirt-wearing ears-pierced laid-back California dude, then you won't get far with the prime-rib-for-lunch crowd. ;-) --Kent

1 0

Root name server
by Dave Haywood 31 Mar '98

31 Mar '98

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I need to setup an internal root name server in my private network. I am using bind v8.1.1 (Solaris 2.5.1). Does anyone have any pointers on how to achieve this? For those of you not already asleep, the primary nameserver for the root domain and the organisation domain are the same server (I know this is a bad idea but that's just how it is). The nameserver starts up OK (no errors) but when I query the nameserver (dig xxx) it returns zero responses. If I use a FQDN (dig xxx.org.dom) I get the correct result. I do have "domain org.dom" in /etc/resolv.conf and "dns hosts" in /etc/nsswitch.conf. If I dump the nameserver database it looks OK. Perplexed, England. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBNSEjwFtv3tEWY+eVEQKR2ACfdOYy65pzhwQ4RfybTQ7UyZD1f7cAoNLU h9DPr9cYJdPhmPOwGr/zJzAZ =PNJx -----END PGP SIGNATURE----- --- Dave Haywood Network Manager ICL-CFM +44 194 223 5609 C85A 41F5 350F 0F5B 1489 C4BA 5B6F DED1 1663 E795

2 1

Seattle Sprint outage - update?
by Jay Stewart 31 Mar '98

31 Mar '98

Any one from Sprint care to enlighten us on the major fiber cut in Seattle? Any word on when the Sprint facilities in this area will be back up, or what was/is the problem? Jay Stewart Vice President Olympia Networking Services - "Premier Internet Access" Phone (360) 753.3636 Fax (360) 357.6160 http://www.olywa.net/

8 10

Re: more directed broadcast attacks
by Hal Murray 31 Mar '98

31 Mar '98

[Description of nasty DOS attack snipped.] > Needless to say, I did not have any fun today. Suggestion... Some people claim that the only way to get rid of professional spammers is to make it too expensive for them to do business, for example by charging them a serious "cleanup" fee if they get kicked off for spamming. Maybe the same idea logic holds for checking source IP addresses. If there isn't any visible cost to procrastinating then many sysamdins will continue to put installing the filters on the back burner. So how about modifying contracts, including peering agreements, to charge for DOS problems? You could charge twice as much (per hour?) if the NOC didn't respond within some time limit.

2 1

NANOG 13
by Pam Ciesla 31 Mar '98

31 Mar '98

Registration is open for the NANOG 13 Meeing at the Hyatt Regency Dearborn, June 7-9. Please contact me if there is any problems with registration. Merit Network Is hosting this NANOG and is seeking sponsors for a variety of events (4 breaks, 2 lunches, a social). If your company is interested in sponsoring part of NANOG, please send e-mail to wbn(a)merit.edu with "NANOG SPONSORSHIP" in the subject line. Information for the NANOG 13 Meeting can be found on the webpage http://www.nanog.org xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 734-936-0172 - phone Merit Network, Inc. 734-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0