- NANOG - lists.nanog.org

List of Attendees
by Pam Ciesla 26 Sep '96

26 Sep '96

Is on the web at http://www.merit.edu/~nanog/NANOG.html. This list is as of 9/26 3:00PM. The following people have responded since & will be added at a later time. Bill Simpson, Brent Felder & Michael Patton. Pam

1 0

RE: Advice on dealing with Sprint
by Chris A. Icide 26 Sep '96

26 Sep '96

Yes, I'm extremely suprised that this is their stance. I'm pressed to find a technical reason behind such a requirement. The 7000 is a Motorola 68XXX based system, and the 4500/4700 is a risc based system. There have been performance tests that have shown that the 45/47 boxes out perform the 7000 boxes. I'd be very interested in hearing Sprints' reasoning on this. Chris ---------- From: Neil J. McRae[SMTP:neil@EASYNET.NET] Sent: Thursday, September 26, 1996 11:11 AM To: Deepak Jain Cc: Steve Mansfield; Rob Liebschutz; hank(a)rem.com; jon(a)worf.netins.net; nanog(a)merit.edu; neil(a)EASYNET.NET Subject: Re: Advice on dealing with Sprint On Thu, 26 Sep 1996 10:36:56 -0400 (EDT) Deepak Jain <deepak(a)jain.com> alleged: > > Steve - > > I think he means Sprint told him they would not BGP4 peer with > him if he didn't have a Cisco 7000 series router. Not that it wasn't > possible. :) > You have to vote with your feet on this and take your money elsewhere. Regards, Neil. -- Neil J. McRae. Alive and Kicking. E A S Y N E T G R O U P P L C neil(a)EASYNET.NET NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A> BTnet support reply regarding 45 minutes of no service: "BGP FNF, BGP A OK, BT ISP A OK, MFI NO GO!!" -- Bill.Peters(a)bt.net

4 3

Re: Advice on dealing with Sprint
by Jay Stewart 26 Sep '96

26 Sep '96

> I spoke to a sprint salesperson about 2 weeks ago and was told that I > could not get any kind of BGP4 peering with Sprint unless I had a > Cisco 7000 series router. This is my experience also, althought I was able to get my sales weasel to say that they might except a 45xx series if it had sufficient memory, as some "exceptions" had been granted on a "case by case" basis. As a reseller of IP services they will not manage my router for me, but said I still had to have a Cisco(tm) router, even if I'm not peering BGP. Jay Stewart Vice President Olympia Networking Services - "Olympia's Premier Internet Access" Phone (360) 753.3636 Fax (360) 357.6160 http://www.olywa.net/

6 6

NANOG Announcement
by Pam Ciesla 26 Sep '96

26 Sep '96

Hi all - Just a few announcements about the upcoming NANOG meeting. The meeting is less than one month away so be sure to register as soon as possible at http://www.nanog.org. For those of you would do not want to prepay please be sure to register now. We need info for name badges and head count. On a related note, hotel rooms are going fast so don't delay too long! Several of you have requested the Agenda - The agenda will e-mailed out in a couple of days after we confirm the speakers and topics. To allow time for all the presentations we're hoping to include, we may need to run the meeting until 1:00 p.m. on Friday; please plan your flight schedules accordingly. We're also planning to offer a tutorial on RA tools and use of the Internet Routing Registry, and there will be a route flap BOF on Friday afternoon. And there's a NetSCARF workshop preceding NANOG: NetSCARF Workshop 1-5PM Wednesday Oct 23rd, register required at www.merit.edu/~netscarf RA Tutorial 2-3:30 Friday Oct 25th Route Flap BOF 3:30-4:30 Friday Oct 25th If folks express an interest (send e-mail to wbn(a)merit.edu) we will reserve a whirlyball court for Thursday evening. Also note that the meeting will be at the Michigan Union in the Ballroom 2nd floor. If you have questions, please contact Pam Ciesla (313) 936-0172 or pam(a)merit.edu. Thanks!

2 1

Advice on dealing with Sprint
by Jon Green 26 Sep '96

26 Sep '96

Hi folks- I have a problem that I need some advice on, and figured this was a good place to turn. We are attempting to connect a T1 to Sprint in order to multi-home our network. Currently we are connected to multiple points on MCI's backbone, and have just installed a T1 to UUnet. We heard back from Sprint today.. they are rejecting us as a customer because we do not use Cisco routers. Apparently they feel that Bay Networks routers are not capable of routing Internet traffic, ignoring the fact that they already peer with ANS and several other providers using Bay routers. OK, Cisco bigots (hi Craig!), quit laughing at me for a second and give me some help here. Is there any technical justification for what Sprint is telling me? I have downstream customers using Bay, Cisco, HP, 3com, Compatible Systems, and even Proteon routers. All of them are able to connect with me just fine. I've been running BGP4 peering with MCI for over a year now, it also works fine. I can't find a single valid reason that Sprint should even need to "approve" my router vendor, except that some short-sighted engineer at Sprint doesn't understand that we live in a multi-vendor world. I'm obviously not going to force Sprint to accept my money, but this screws up a lot of the plans we have made in building our network. Any suggestions welcome. Anyone from Sprint who'd like to comment, please do so. -Jon ----------------------------------------------------------------- * Jon Green * Wide-Area Networking Technician * * jon(a)netINS.net * Iowa Network Services, Inc. * * Finger for Geek Code/PGP * 312 8th Street, Suite 730 * * #include "std_disclaimer.h" * Des Moines, IA 50309 * -------------------------------------------------------------------------

6 6

Re: Advice on dealing with Sprint
by Mark Borchers 26 Sep '96

26 Sep '96

> Perry E. Metzger writes: > >Not, you understand, that I think the global routing table should be > >kept in control, but I find it to be extraordinarily annoying that in > >a world where cheap PCs have been able to take 128meg on their > >motherboards for years (indeed, many can take far more!) and in which > >workstations frequently have 64M of memory in them, there are routers > >(many still sold!) which lack the slots to take more than 32M of > >memory. > > Cisco has been repeatedly abused for this. They have learned, a bit, > over the years. The non-M 45xx/47xx boxes are I think no longer being > sold, and the "M" replacements are upgradeable to 64MB. > > (of course, I suspect you'll never be able to get more than 64 MB of > memory for a 7000. Someday they will get abused for that, too.) > I believe the official line here will probably be that by the time you need 128 MB in your 7000, you also need to install the RSP7000 upgrade, which allows the additional memory. Mark Borchers InfiNet Network Engineering NOC: (757) 624-2295 ext. 3007

1 0

Re: Top-50 Report
by Paul Ferguson 26 Sep '96

26 Sep '96

At 11:48 AM 9/26/96 +0100, Tony Barber wrote: >The above is an excellent idea. Perhaps if you could mail the output to >nanog and ripe-list the peer pressure would help and in some cases inform >LIRS/ISPs what they may unknowingly be doing wrong. >RIPE did this earlier inthe year for the European registries and it worked. > >Is there an APNIC equivelant ? > Yes -- AP Ops <apops(a)apnic.net> - paul

1 0

Re: Advice on dealing with Sprint
by Rob Liebschutz 26 Sep '96

26 Sep '96

> > > I spoke to a sprint salesperson about 2 weeks ago and was told that I > > > could not get any kind of BGP4 peering with Sprint unless I had a > > > Cisco 7000 series router. > > > > This is my experience also, althought I was able to get my sales > > weasel to say that they might except a 45xx series if it had > > sufficient memory, as some "exceptions" had been granted on a "case > > by case" basis. > > > > As a reseller of IP services they will not manage my router for me, > > but said I still had to have a Cisco(tm) router, even if I'm not > > peering BGP. > > > > Jay Stewart > > I won't say there's "no way they can know", but basically they really > shouldn't. If you disable incoming telnet to your Bay box and tell > them it's a cisco with "cdp disabled", they shouldn't be able to > tell the difference. > > Of course, you'd best know how the hell to configure the bay box > if you want to go this route. > > Avi > > Actually, I was planning to change the login prompt on my BSDI box to User Access Verification Password: Rob

1 0

Re: Advice on dealing with Sprint
by Rob Liebschutz 26 Sep '96

26 Sep '96

I'm not criticizing Sprint, for this policy, only confirming the fact that I received similar information about their requirements to use Cisco equipment. I've had my share of bad experiences with customers buying some El Cheapo brand router and throwing it in my lap to deal with. I have my official list of routers & CSU/DSU's that I support (Cisco's are on that list) and for anything else the customer is on their own. On the other hand I wasn't asking Sprint to manage my router for me either and would hope that they would peer with any "reasonable" router that I might have if I could demonstrate to them that I was competent in bgp4 routing with it and that it would not cause them any problems. > > I spoke to a sprint salesperson about 2 weeks ago and was told that I > > could not get any kind of BGP4 peering with Sprint unless I had a > > Cisco 7000 series router. > > I suspect two problems. > > Some [potential] cvustomers are not hearing clearly, or Sprint has some > internal communication problem that is leaking out to customers. Probably > more of the latter then the former, but likely a bit of both. > > But the tough question is what to do when a customer wants to attach > something 'strange'. We're a few decades past the Carterphone decision, so > we probably should let the customer do it. But how much are we obliged to > debug it for them? And how are we compensated for our efforts beyond those > to which we are used? > > randy >

1 0

Re: New Denial of Service Attack ...
by vjs＠mica.denver.sgi.com 26 Sep '96

26 Sep '96

> From: Barney Wolff <barney(a)databus.com> > To: vjs(a)sgi.com (Vernon Schryver), nanog(a)merit.edu > > At R=100 SYNs/sec, RTT=250, and L=382, ((L-1)/L)^(RTT*R) = 93%, which > > is not so bad. Drop-oldest is better with those three numbers, since > > it works 100% (modulo ordinary problems), but its performance falls off > > the cliff to 0% at R=L/RTT. If you have a short queue and care about > > long RTT's, random drop is better than drop-oldest. > > Agreed. Note that 93% is not bad for a human-initiated telnet, but is > disastrous for a Web browser which initiates a dozen tcp sessions to > retrieve one page, because the browser will probably not retry at all if > it gets a reset, but instead report failure to retrieve the page to the > user, who can only ask it to start over from the beginning. Caching should keep them from having to retransfer everthing. Of course, if the problem is getting through the listen queue, that might not help much. > So I think > that it's better to accept the limited-radius-under-attack property of > drop-oldest, gaining the immunity from interference within the safe > radius. If you have a useful safe radius. At only 130 SYNs/sec, a 260 entry queue seems useful today, giving a 2 second radius. What is the limit on the queue in the typical router or Ethernet hub? > If it were possible to set the syn-rcvd timeout with sub-second > granularity, this "fix" would not even take any kernel code mods - but > of course it does not adjust the safe radius dynamically as the attack > rate changes. Again, I think it is practical to switch automagically from drop-oldest when the attack rate is modest to random-drop when the bad guys get something better than a v.34 modem, such as ISDN or just a corrupted machine somewhere on an Ethernet connected with a T1. > What's absolutely clear is that any method of queue pruning is better > than none, and a big queue is required for survival. A queue limit 50 to 500 times larger than the 7 from the classic BSD SO_MAXCONN=5 seems useful for handling the 100's of valid TCP connections/sec that you get on a busy WWW server. Vernon Schryver, vjs(a)sgi.com

1 0