- Test - lists.nanog.org

Cidr Report in parts - part 1
by Tony Bates 28 Sep '96

28 Sep '96

Due to what I'm guessing is a problem with the merit mailer it seems to eat my mail message containing the full report so I going to break it up in part to see how that works. --Tony This is an auto-generated mail on Fri Sep 27 12:01:14 PDT 1996 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. In the future I hope to put some (or most) of this report up on the web. ------------------------------------------------------------------------------ CIDR REPORT for 27Sep96 0) General Status Table History ------------- Date Prefixes 210996 43100 220996 42436 230996 42636 240996 42498 250996 41621 260996 42422 270996 42323 Possible Bogus Routes --------------------- *** Bogus 211.199.11.0 from AS6176 AS Summary ---------- Number of ASes in routing system: 1630 Number of ASes announcing only one prefix: 644 (330 cidr, 314 classful) Largest number of cidr routes: 493 announced by AS3561 Largest number of classful routes: 1268 announced by AS174

1 0

Re: ATM Traceroute middle packet loss?
by Sanjay Dani 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. Looks like Solaris has the same bug as the ATM link you described. I see every other packet dropped by a Solaris box on my ethernet but not by a linux box on the same ethernet. 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 --

2 1

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