- NANOG - lists.nanog.org

Re: followup on TCP stuff.
by Bill Manning 09 Jun '99

09 Jun '99

> Bill, > > Can you forward my reply here, and > tell Nanog'ers to check TCPIMPL for > more info? > > Thanks, > > Joe > > > > >To: alan(a)globalcenter.net, nanog(a)merit.edu, tcp-impl(a)lerc.nasa.gov > > >Subject: Re: TOS issues with non RFC compliant TCP stacks > > >Cc: touch(a)ISI.EDU > > > > > >> From owner-tcp-impl(a)lerc.nasa.gov Tue Jun 8 23:27:07 1999 > > >> Date: Tue, 8 Jun 1999 22:45:11 -0700 > > >> From: Alan Hannan <alan(a)globalcenter.net> > > >> To: nanog(a)merit.edu, tcp-impl(a)lerc.nasa.gov > > >> Subject: TOS issues with non RFC compliant TCP stacks > > >... > > >> It has come to our attention that a notable fraction of the > > >> internet client community uses a TCP stack which is not RFC > > >> compliant, as far as we can determine. > > >> > > >> Certain versions of MacTCP send a RST when they receive SYN ACK > > >> packets of TOS!=0. > > > > > >Far as I have found, the spec (STD7) says that TOS is a TCP > > >per-connection property (page 12). > > > > > >On page 36 it appears to clearly state that (case 2): > > > > > > terminated then). If our SYN has been acknowledged (perhaps in this > > > incoming segment) the precedence level of the incoming segment must > > > match the local precedence level exactly, if it does not a reset > > > must be sent. > > > > > >> So, the empirical part: We implemented TOS bit-setting for the > > >> purpose of tracking traffic flows and traffic levels. For an > > >> entirely arbitrary reason, we chose TOS=5 for the default of > > >> traffic. We found that MacTCP ceased functioning. The MacTCP > > >> stack would initiate an RST when receiving SYN ACK packets with > > >> a TOS=5, as the SYN packets had a TOS=0. Therefore, all TCP > > >> sessions would fail. > > > > > >Granted, this is a first cut read, but wouldn't this appear > > >to indicate that NOT sending the RST is the violation of the > > >spec? > > > > > >Can you clarify? > > > > > >Joe > > > --bill

1 0

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 06 Jun '99

06 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