September 1996 - Test - lists.nanog.org

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

27 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. > > Jon Green writes: > >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. > > You are actually getting some misinformation. You can use any router > you want, we just can't help you configure things other than Cisco > routers. If you want us to manage your router, then it must be a > Cisco, otherwise use whatever you want. > > >Any suggestions welcome. Anyone from Sprint who'd like to comment, please > >do so. > > Tell your Sprint sales folks that I said it was fine and approve the > SCA. If they have any questions, have them call me. > > -Hank Kilmer > Mgr Sprint IP OPS Engineering >

11 19

Draft NANOGr Agenda
by Susan R. Harris 27 Sep '96

27 Sep '96

North American Network Operators Group (NANOG) Draft Agenda Thursday, October 24 Time Topic Presenter(s) ---- ----- ------------ 9:00 a.m. Welcome, Introductions, Bill Norton, Merit Future Meetings 9:15 a.m. STATE OF THE INTERNET: NAPs Sprint NAP Steve Schnell, Sprint Ameritech NAP Andy Schmidt, Ameritech The MAEs Steve Feldman, MFS Datanet 10:30 a.m. Break 10:45 a.m. STATE OF THE INTERNET: NSPs Sprint Jim Steinhardt, Sprint IBM Global Network Dimitri Krinos, IBM ANS Curtis Villamizer, ANS MCI Jeff Young/Jack Waters, MCI 12:00-1:00 Lunch 1:00 p.m. New NAP Announcement Nathan Stratton, NetRail 1:15 p.m. Some Economics Issues for Jeff Mackie-Mason, the Future Internet Univ. of Mich. 2:00 p.m. vBNS Overview and Status John Jamison, MCI/vBNS 2:30 p.m. Broadening vBNS Access: Mark Luker, NSF the New Connections Program 3:00 p.m. Break 3:15 p.m. STATE OF THE INTERNET: Statistical Research, Part 1 Network Probe Daemon Dun Liu, Merit Routing Stability Craig Labovitz, Merit Analysis 4:15 p.m. Customer Requirements for Sue Hares, Merit Future Routers - What's Next? (moderator) 3Com Corporation Cyndi Yung, 3Com Cisco Systems Dave O'Leary and Tony Bates, Cisco NetStar David Ward, Ascend Bay Networks Jeff Burgan, Bay 5:15 p.m. RA Update Brian Renaud, Merit Jon Postel, ISI Friday, October 25 9:00 a.m. STATE OF THE INTERNET: Statistical Research, Part 2 Using AS Matrices for John Hawkinson, Capacity Planning BBN Planet, and Daniel McRobb, ANS Analysis of Real-time Steve Corbato, Univ. Aggregate Flows of Wash. 9:45 a.m. New Tools from the RA: Craig Labovitz, Merit NetNow and IPN (Inter- Provider Notification) 10:15 a.m. Break 10:30 a.m. MBoneD Working Group Dave Meyer, Univ. of Update Oregon 10:45 a.m. Source Spoofing and SYN Avi Freedman, Net Flooding: Problems, Access, Moderator Solutions, Community Views, and Discussion 11:30 a.m. Multihoming: Overview, Pros and Cons, Community Views Curtis Villamizer, ANS Avi Freedman, Net Access Randy Bush, RGnet Mystery Speaker, TBA 12:30 p.m. Closing Remarks Bill Norton, Merit

1 0

NANOG ANNOUNCEMENT: After NANOG Activities
by William B. Norton 27 Sep '96

27 Sep '96

Hi all - Good ideas - We have rescheduled the RA Tutorial and the Route Flap BOF to run in parallel from 1:30 until about 3:00. Thanks for the e-mail - We have the whirlyball courts for reserved for Thursday evening after dinner. It was suggested again that we should not allow the whirlyball superstars to team up, so we'll have to find a way to equitably split up teams. Maybe Metcalfe fans vs. Metcalfe Critics. Although that might be uneven as well.... Bill PS - We're going to have to close the NetSCARF workshop registration after this weekend; we have just about reached our 50 seat limit. Consider this a last call. ---------------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 936-2656

1 0

Re: List of Attendees
by William B. Norton 27 Sep '96

27 Sep '96

Perhaps light, but not as atypical as one might think. We usually get a flurry of registrations at the last call, about two weeks before the meeting. Bill At 09:35 PM 9/26/96 -0400, Paul Ferguson wrote: >Hmm. About 120 people. Interestingly sparse. > >- paul > > >

1 0

Re: Advice on dealing with Sprint
by Vadim Antonov 27 Sep '96

27 Sep '96

When i was at Sprint it was customary to ask customers to provide some assurance that routing information Sprint takes from them is going to stay sane. That was usually achieved by asking customers to send in their border configurations for review by SL engineering, and some formal criteria (like "no unfiltered IGP to BGP redistribution") was applied and said configuration had problems worked out before the actual peering was enabled. Anyway, that automatically made every customer with BGP to go down SCA (Special Customer Arrangement) route. I think sales didn't like that, for whatever reason, and i saw several attempts to make BGP peering a regular sale during my tenure there. I guess they succeded after coming with some "guidelines", but without any understanding of the issues involved. Somehow i became a big fan of Dilbert back then. --vadim

3 2

Re: syn attack and source routing
by Vadim Antonov 27 Sep '96

27 Sep '96

John Hawkinson <jhawk(a)bbnplanet.com> wrote: > i should have been more specific. i don't like the idea (at all) of > breaking traceroute -g either. i guess in a more general sense i > should ask "just how dangerous *is* having backbone-wide/internet-wide > loose source routing enabled?". >As Curtis explained, "not very". Want to wait until SYN attacks are augmented with LSRR-enabled traffic randomization to the point of making it nearly impossible to trace? People knew about SYN flooding for years. Nothing happened until s*t hit the fan. I strongly suspect that LSRR is of the same category. >This is a very different case from that of SYN flooding, where the >victims are powerless to stop it. Now, providers being unable to trace would be a nice addition. >Please don't take our LSRR away from us, it is very useful. Per se, LSRR is not useful. traceroute -g is. Why not to implement something saner like traceroute servers? Or better yet, the ICMP TRACEROUTE message, which would go hop by hop and on every hop generates a response message. Augmented with PROXY TRACEROUTE which will cause the destination box to send out the ICMP TRACEROUTE. I can write RFC in my copious spare time if you think that this makes more sense than the UDP kludge. >Campaigning to remove something just because you suspect it might be >bad is really not nice -- it will result in random clueless people >believeing you when perchance they should not :-) Ah. I love the "the moozhik won't cross until thunder rolls" attitude. --vadim

6 5

Hints for tracing SYN flooders (and others) through Ciscos
by Jeff Rizzo 27 Sep '96

27 Sep '96

Apologies to those to whom what I present here is blindingly obvious; I'm killing some time while waiting for a response from an ISP that we've traced an attack on one of our customers to, and I thought I'd share a tip: Since virtually everyone who has a Cisco has at least fast switching, if not cbus switching, enabled, the "debug ip packet [access-list] detail" suggested here the other day won't show much, as the processor (which is doing the debugging) won't actually see the whole packet. You can sit there for quite some time without results. :) Obviously it makes no sense from a performance perspective (at least if you have even moderate traffic) to turn off fast switching, you *can* clear the ip cache for the attacked network. This forces the processor to look at a number of packets to rebuild a cache entry. Now, if you're especially lucky, your debug may catch the packets you're looking for right off, and tell you the ingress interface. More likely, however, is you'll need to clear the cache entry a number of times to get a hit. You're still on your own when you get to a shared IXP fabric, and you'll need a sniffer there, but it can help. (Hey Cisco! Any chance of putting a source MAC address in the "detail" information? :) At least, if the attacker's sending rapidly enough to be noticeable. Hope this helps someone. +j -- Jeff Rizzo nc0005(a)noc.netcom.net NETCOM Sr. Network Administrator Guy +1 415 758 1457

2 1

Re: List of Attendees
by Paul Ferguson 26 Sep '96

26 Sep '96

At 04:32 PM 9/26/96 -0400, Pam Ciesla wrote: > >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 > Hmm. About 120 people. Interestingly sparse. - paul

2 1

Re: List of Attendees
by Bill Woodcock 26 Sep '96

26 Sep '96

> McCauley, Bill > Meyer, David, Does the fact that we go from MCC to MEY without passing through MET mean that we won't have to wear suits, or pre-boot our laptops? :-) -Bill ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

1 0

Nanog Advice
by None 26 Sep '96

26 Sep '96

Fri, 07 Sep 1996 08:26:53 -0500 From: Zachary DeAquila <zachary(a)zachs.place.org> Sender: owner-nanog(a)merit.edu Given all the recent advice and info here, how about making an 'Advice from Nanog' page off of the main NANOG web site? It could contain kind of a 'NANOG FAQ' and provide a place to point people who have questions at. The advice should be individualy attributed so you know whose views you're getting, so we can tell a Freedmanbit from a Metzgerbit from a Denningerbit from a Postelbit from a Doranbit... and also to give credit where it's due, of course :) --Z

2 1