Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!apple!csibtfr!excelan!edc
From: edc@excelan.com (Eric Christensen)
Newsgroups: comp.dcom.lans
Subject: Re: Netware 2.0a++ performance degradation, how come?
Message-ID: <406@excelan.COM>
Date: 10 Mar 90 01:08:12 GMT
References: <5620@decvax.dec.com>
Sender: news@excelan.COM
Reply-To: edc@excelan.com (Eric Christensen)
Organization: Excelan - A Novell Company, San Jose, Califonia
Lines: 91

In article <5620@decvax.dec.com> f0057@uafhp.uucp (James E. Ward) writes:
>
>Can you help me?  We have a 30-40 station Novel Netware LAN running 2.0a++
>which has suddenly developed a performance problem.  Response time has
>dropped a great deal in the last week.  It was a sudden change.  One day
>it was fine, the next day it was slow.  Any ideas at all?
>

A network suddenly taking a performance hit can be caused by a number
of things.I'm going to assume we're talking about an Ethernet network
here, since there's no mention of any specific network architecture.

By far the most common problem is an electrical fault. Misbehaving
trancievers, fanouts, repeaters, and the like cause a lot of collisions
and make the net run slow. Likewise, poor termination or loose
connections are common culprits.

A station who has a broken controller and doesn't sense carrier on the
line will also cause similar problems. Since it always things the lines
clear, it'll just barf out whatever it has to say, often right on top
of someone else's packet!

There are a number of protocol dependent conditions which could cause
your net perfomance to drop off. Since I'm not really an IPX protocol
expert, I'll leave this one to someone who is. But, just for example,
in the TCP/IP world broadcast storms are one of the most common maladys
that we encounter. These are often caused by a station using the wrong
broadcast address, which in turn causes other systesm to ARP it, and
that causes still other systems to answer the ARP queries. This
particular scenario is very common on networks running both BSD4.2 and
BSD4.3. (Why'd they change the broadcast address anyway???)

Anyhow, unfortunatly, the only way to really find out what's going on
with a misbehaving network is to use a network analyzer and a TDR (time
domain reflectometer). While I highly reccommend that both these tools
be part of any network admin's tollkit, they're quite pricey ( $10,000
or so for a network analyzer and a couple grand for a good TDR). There
are some small, hand held network monitors around which can replace the
TDR for a few hunderd bucks, and are easier to use (interpreting a TDR
trace is not a job for the network novice). But there's just no
replacement for a good network analyzer.

Of course, there is the low budget version of debugging the network
without these tools. Start my disconnecting everything except your
fileserver and 1 client. If the performance still sucks then you've
probably got something wrong with either your cable or maybe your
server or client. Probably your cable though.

If the throughput looks ok with just the one server and client, start
adding devices back onto the net one at a time. Do network devices like
fanouts and repeaters first (since they seem to fail more often then
other devices), then start with your systems. Eventually your
perfomance *might* drop back to it's previous dismal level, and you've
got your suspect device.

If you suspect cable problems, try minimizing your cable by unplugging
segments (assuming thin-net), or whatever else you can manage.
Eventually you should be able to isolate the cable that's causing the
problem. Without a TDR, your probably money ahead to call in a cabling
company to track the problem down.

Needless to say, this is horribly time consuming, and I've seen lots of
problems disappear just by cycling power on a fanout, or something else
similarly simple. So you may spend a day thrashing around only to find
that your problem has totally disappeared (probably to return sometime
in the future).

Anyway, now that I've babbled on and on about this, I'll just sum it up
with one statement...

	GET THE RIGHT TOOLS! 

It'll save your sanity (and possibly your butt, if you have militant
users).

I guess I should mention at least a couple of sources of network
analyzers and TDRs. Network General, Excelan, and HP all make various
network analyzers which are appropriate for these applications. For
TDRs, Cabletron makes a number of fine units.

The features (and prices) of these units vary greatly, so you'll really
need to do a bit of research and shopping for one that meets your
particular needs and budget. There are plenty of other manufacturers
around too. Please don't take my suggestions above as recommendations,
they just happen to be the ones that I'm most familiar with, not
nessecarily the best for your application.

+-----------------------------------------------------------------------------+
| Eric Christensen  -  Sr. System Administrator  -  Excelan, A Novell Company |
| Email: edc@excelan.COM        {ames | apple | mtxinu | leadsv }!excelan!edc |
+-----------------------------------------------------------------------------+