- Test - lists.nanog.org

Re: ATM Traceroute middle packet loss?
by Eric D. Madison 28 Sep '96

28 Sep '96

No, it's not a Sun issue, it drops every other packet only if I got over the ATM Backbone. I can trace to another router, a ATM Switch, A CSU panel, anything and I get the same dropped packet. I did further testing, and it is every other packet, not just the middle one. Eric At 05:11 PM 9/27/96 -0700, maillists wrote: > >> hmm.. >> Seems that every traceroute across an ATM link will result in the middle >> packet being dropped. The ATM Switch nor the Router have any idea that it >> is the second packet.. weird! Anyone have a clue to why that is? >> >> Tracing the route to ns2 >> 1 206.222.97.6 44msec 44msec 44msec >> 2 ns2.acsi.net (206.222.97.50) 44 msec * 44 msec > >I don't think it has got anything to do with ATM. I >bet you that ns2.acsi.net is a Solaris 2 box. Solaris >drops every other icmp echo if it comes too close to >the last one. This I was told is an inadvertent bug >although Sun could claim it to be a feature against >an ICMP flood attack ;-) > >Try tracerouting to sun.com (a SunOS box) and >playground.sun.com (Solaris 2). You'll see the difference. >Also try traceroute with the -q parameter greater than >the default of 3 packets each destination. > >Sanjay. > >--------------------------------------------------------------- >Web Professionals, Inc. >20370 Town Center Lane, Suite 245 +1 408-865-0899 >Cupertino CA 95014 USA http://web.professionals.com >--------------------------------------------------------------- > World's largest Webspace provider with dedicated domain sites > Ref: Open Market's Commercial Sites Index www.directory.net >-- > >

1 0

Re: ATM Traceroute middle packet loss?
by Sanjay Dani 28 Sep '96

28 Sep '96

> hmm.. > Seems that every traceroute across an ATM link will result in the middle > packet being dropped. The ATM Switch nor the Router have any idea that it > is the second packet.. weird! Anyone have a clue to why that is? > > Tracing the route to ns2 > 1 206.222.97.6 44msec 44msec 44msec > 2 ns2.acsi.net (206.222.97.50) 44 msec * 44 msec I don't think it has got anything to do with ATM. I bet you that ns2.acsi.net is a Solaris 2 box. Solaris drops every other icmp echo if it comes too close to the last one. This I was told is an inadvertent bug although Sun could claim it to be a feature against an ICMP flood attack ;-) Try tracerouting to sun.com (a SunOS box) and playground.sun.com (Solaris 2). You'll see the difference. Also try traceroute with the -q parameter greater than the default of 3 packets each destination. Sanjay. --------------------------------------------------------------- Web Professionals, Inc. 20370 Town Center Lane, Suite 245 +1 408-865-0899 Cupertino CA 95014 USA http://web.professionals.com --------------------------------------------------------------- World's largest Webspace provider with dedicated domain sites Ref: Open Market's Commercial Sites Index www.directory.net --

1 0

ATM Traceroute middle packet loss?
by Eric D. Madison 27 Sep '96

27 Sep '96

hmm.. Seems that every traceroute across an ATM link will result in the middle packet being dropped. The ATM Switch nor the Router have any idea that it is the second packet.. weird! Anyone have a clue to why that is? Tracing the route to ns2 1 206.222.97.6 44msec 44msec 44msec 2 ns2.acsi.net (206.222.97.50) 44 msec * 44 msec Tracing the route to 206.222.97.5 1 206.222.97.5 16 msec * 16msec ________________________________________________________ Eric D. Madison - Senior Network Engineer ACSI - Advanced Data Servics - ATM/IP Backbone NOC - 800-291-7889 - noc(a)acsi.net

1 0

RE: Advice on dealing with Sprint
by cdc＠GroupZ.net 27 Sep '96

27 Sep '96

I called Sprint. They said to multihome, load balance across to distinct backbones (i.e Sprint & UUNET), and accept the full routing table, I'd have to use a 7000 series. I didn't believe them, so I logged a call with the TAC. They said they knew of no technical reason why the 4500 wouldn't do the trick, but maybe I should call my sales engineer. My sales engineer said the 4500 would to the trick (of course they'd prefer to sell me a 7000), but I might have to accept reduced routes or perform some other kludge to reduce the load on the router; and no telling what the performance would be like 2 months from now. Note: Our primary interest is bypassing problems we're experiencing between Sprint and UUNET via MAE-E, but we'd like to offer the best connectivity to our web servers. I called Sprint back, and they said they could work out a 'Special Customer Arrangement' to deal with the 4500. Based on the e-mail addresses I see on this group, it seems like we should be able to come to some consensus about the viability/sensibility/performance related issues related to this topology. > > 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. > >

2 1

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