June 1999 - Test - lists.nanog.org

Need Dan Nydick address/info
by GAVRON＠ACES.COM 09 Jun '99

09 Jun '99

The following piece of code from TrACESroute identifies Dan Nydick, and has a copyright that prevents the use of this code in a distribution I was trying to get it into. Could someone let me know how to contact Dan, or which parts of the code are Copyright... it all looks like stuff I've seen in every other program in the world... Ehud /* DNS lookup portions of this code also subject to the following: */ /* * Use the domain system to resolve a name. * * Copyright (C) 1988,1990,1992 Dan Nydick, Carnegie-Mellon University * Anyone may use this code for non-commercial purposes as long * as my name and copyright remain attached. */ Ehud

1 0

Re: HP Openview Slowness.
by Sean Donelan 09 Jun '99

09 Jun '99

scall(a)devolution.COM (Scott Call) writes: > As part of a network I'm working on, I've install HPOpenView NNM >(first time, I've only used free/cheap stuff in the past) on a Sun >Ultra5, and it's performance is less than stellar. It takes between 30 >seconds and 5 minutes to traverse from one map to another (either up or >down). This occurs no matter how many (or few) objects are on each >submap. I use Netview (a HP Openview derivative via IBM/DEC, now Tivoli). It will use whatever resources you give it. Yeah, the sales guy may have said it will run in 64meg, depending how you define "run." After I upgraded to a DEC Alpha/4000 with 640MB, and it is responsive enough to use. Other folks have told me their HP Openview was also much happier after they added a LOT more memory. The free/cheap stuff works well too. We use both, backing each other up. The Cabletron, Openview, etc stuff may be on the front wall with CNN to show visitors how cool your network is, but almost every NOC I've visited has something like NOCOL in the back. But don't tell upper management, otherwise they'll want to know why they spent mucho bucks on the stuff which displays pretty color pictures. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: TOS issues with non RFC compliant TCP stacks
by Sean Donelan 09 Jun '99

09 Jun '99

alan(a)globalcenter.NET (Alan Hannan) writes: > We have learned of a problem with non RFC compliant users of > the Internet. Although many network operators may want to apply RFC standards to non-compliant users; I think your problem is with protocol implementations instead of the users of those implementations :-) > Certain versions of MacTCP send a RST when they receive SYN ACK > packets of TOS!=0. > > I assume there are other TCP implementations which also have > this behaviour. MacTCP is pretty old. But you're going to quickly discover a lot of other quirks in other old vendor's TOS handling. I would hesitate to call some them non-RFC compliant, because sometimes the original RFCs left openings for different interpretations. And the early 'reference' implementations had even more interpretations. Later RFCs tried to clarify some of the practices, but it is an iterative process. Because TOS is so rarely used (until now), I suspect there is still lots of buggy code which has never been tickled. Some IBM mainframes will RST a connection if the TOS changes after the SYN. Several old implementations try to set to identical values in both directions, even though TOS is supposed to be independent between senders. And exactly how TOS interacts with MTU settings and fun stuff like fragmentation or path-MTU discovery is a mystery path through some stacks. >------------------------ = ------------------------ >2.10. Robustness Principle > > TCP implementations will follow a general principle of robustness: be > conservative in what you do, be liberal in what you accept from > others. >------------------------ = ------------------------ Like all great principles, it is a two-edged sword. Please heed both parts. Many implementors have justified their actions, on both sides, by saying it is too difficult for them to do, but trivial for the other guy to do. If you believe in the robustness principle, it works best when both sides use it. > Because of a hardware implementation limitation on most of > routers, INbound TOS setting is efficient, while OUTbound TOS > setting is inefficient. > > So it is difficult for us to modify the TOS settings leaving > our network. > > It would be moderately trivial for most interconnection partners > to modify the TOS settings on input. This is a path we plan > to pursue. With an end-to-end parameter, I think network operators are somewhat justified in telling the user: If it hurts don't set that parameter. But when the network operator sets/changes parameters in flight, I think it is up to that network operator to restore it/set-it-to-a- neutral-value when it hurts. Saying the other guy must be liberal in what they accept only meets the robustness principle if you are conservative in what you send. If TOS is changing from an end-to-end parameter to a hop-by-hop parameter, it would be nice to have a simple way to clear it at a border router. Do we need a "ip tos ignore/strip" interface command for the TOS field somewhat similar to the "ip security" interface configuration setting for IP options? [naturally modified for other vendor configuration languages.] Perhaps those providers with more pull with router vendors than me, and who are planning on using TOS for their internal network decisions, could encourage router vendors to add this feature. It is unlikely every single end-system or intermediate network will do the right thing in every case with TOS, so a simple way to turn it off before it gets to the end-system would be a very useful addition to the network operator toolkit. Trying to explain how to do packet surgery via complex router configurations over the phone to a customer is likely to result in as many ambiguities as the original RFCs. Trying to explain it to an intermediate NSP/ISP; well you know how well inter-provider coordination works now. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Really bad backhoe (off topic)
by Gregory Urban 09 Jun '99

09 Jun '99

A backhoe in Baltimore MD has set a new standard, and it was unmaned at the time. It seems while as flatbed was transporting a backhoe around the Baltimore Beltway (I-695), the backhoe hit a pedestrian bridge that spaned the road. The bridge collapsed onto the road, killing 1 person and sending 3 others to the hospital in critical condition. Details are on the Baltimore Sun's web site at http://www.sunspot.net/content/storyserver.cgi?storyid=1150080223022 Greg U urban(a)cs.umbc.edu

3 2

Re: OSPF multi-level hierarchy: Necessary at all?
by Vadim Antonov 08 Jun '99

08 Jun '99

Tony Li <tony1(a)home.net> wrote: >I suspect that the main driver is not the amount of routing information >in the gross sense, but the scalability of the protocol as the number of >nodes increases. There's a better solution: decrease the number of nodes by replacing clusters with bigger boxes. This has an additional advantage of reducing number of hops (and, consequently, latency variance). K.I.S.S. rulez :) --vadim PS. Using DUAL or DASM instead of SPF helps, too -- these algorithms tend to eliminate updates which "do not matter" unlike SPF-based algorithms which have to inform everyone about local topology changes.

5 4

Off-Topicish
by Tim Wolfe 08 Jun '99

08 Jun '99

PageNet service in all of Oregon is down for unknown reasons at this time. They do not currently have an ETR. Now, to bring this somewhat on topic. How many of you are carrying backup pagers from a different provider than your primary paging service? Tim ============================================================= | Timothy M. Wolfe | Wireless Internet = Get Some | | Chief Network Engineer | 1.800.338.2629 tim(a)clipper.net | | ClipperNet Corporation | http://www.clipper.net/services/ | =============================================================

3 2

Geektools superwhois updates
by Rodney Joffe 06 Jun '99

06 Jun '99

The tar'd source for the GeekTools superwhois proxy is now available at www.geektools.com behind the 'software' icon. V2.0 In addition, there is also an updated whois server list available in the same section. This lists all of the whois servers we are aware of, as of the date stated. It will be updated each time we find a new server, or identify a change. This is the same list used in whois-servers.net. Finally, for the geeks who are forced to use Windows 95/98/NT/2000 machines at work, there is a GeekTools superwhois client available that uses the same lists as above. Binary only. Comments/suggestions as usual to complaints(a)centergate.com... Rodney Joffe CenterGate Research Group, LLC www.centergate.com

1 0

Thermal Load Calcs
by Greg Skafte 05 Jun '99

05 Jun '99

We are getting ready to move our equipment from a place that had its own air conditioning to a new NOC. Is there anyone who has any references to sites with such info. Conversely can someone tell me the thermal loads of cisco 2500 cisco 2600 cisco 4700 cat 1900 cat 2900 cat 5000 apc smartups 1400 250w atx pc's sun ultra 450 w/ 2 ps -- Email: skafte(a)worldgate.com Voice: +780 413 1910 Fax: +780 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris)

3 3

Off-topic plea for help - DS-3 CESM
by Alex Bligh 05 Jun '99

05 Jun '99

This is actually a "how do I configure my router to do that?" Has anyone ever been given a DS-3 CESM circuit (i.e. you order a DS-3, and get some circuit-emultated thing running over a ATM on a higher order SONET circuit - no I don't know why) and actually got it to work? I appear to have (down/down) LOF one end and (up/down) the other. Are there restrictions on scrambling, framing, dsu-mode etc. that apply here in some way there wouldn't be had I been delivered the point to point DS-3 I originally ordered? Replies off-list most appreciated. -- Alex Bligh GX Networks (formerly Xara Networks)

1 0

The Cidr Report
by Tony Bates 04 Jun '99

04 Jun '99

This is an auto-generated mail on Fri Jun 4 12:00:00 PDT 1999 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 04Jun99 0) General Status Table History ------------- Date Prefixes 280599 60794 290599 60486 300599 60423 310599 60546 010699 60651 020699 60740 030699 61574 040699 60877 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 5052 Number of ASes announcing only one prefix: 2600 (1423 cidr, 1177 classful) Largest number of cidr routes: 400 announced by AS701 Largest number of classful routes: 1230 announced by AS209 1) Gains by aggregating at the origin AS level --- 04Jun99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS209 1230 577 653 53.1% Qwest Communications AS271 349 144 205 58.7% BCnet Backbone AS4293 256 151 105 41.0% IMCI AS577 276 183 93 33.7% Bell Canada Backbone AS174 582 491 91 15.6% Performance Systems International AS4200 175 99 76 43.4% AGIS (Apex Global Information Ser AS3749 137 63 74 54.0% TECNET AS7046 304 231 73 24.0% UUNET-CUSTOMER AS1267 94 24 70 74.5% IUNET-AS AS7496 99 33 66 66.7% Power Up AS10928 118 52 66 55.9% UNKNOWN AS7545 115 50 65 56.5% TPG Internet Pty Ltd AS7122 139 78 61 43.9% MTS ADVANCED Network Policy AS1221 452 392 60 13.3% TELSTRA-AS AS4755 139 80 59 42.4% Videsh Sanchar Nigam Ltd. India AS1239 543 484 59 10.9% SprintLink Backbone AS9269 68 10 58 85.3% Hong Kong CTI AS7657 181 124 57 31.5% The Internet Group Limited AS72 95 39 56 58.9% Schlumberger Information Network AS4740 323 267 56 17.3% Ozemail Pty Ltd (ASN-OZEMAIL) AS2493 174 121 53 30.5% iSTAR Internet, Inc. AS719 465 413 52 11.2% LANLINK autonomous system AS3737 161 111 50 31.1% PenTeleData Inc. (ASN-PTD) AS803 73 37 36 49.3% SaskNet Backbone AS1 490 455 35 7.1% BBNPLANET AS6944 34 2 32 94.1% RapidSite, Inc. AS6172 154 122 32 20.8% HOME-NET-1 AS1785 246 214 32 13.0% NYSERNet Backbone AS549 164 133 31 18.9% ONet Backbone AS4307 32 1 31 96.9% SVINET-1 For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0