f0057@uafhp.uucp (James E. Ward) (09/18/89)
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? James Everett Ward f0057@uafhp.uark.edu I often quote myself; it adds spice to my conversation. -- G. B. Shaw
edc@excelan.com (Eric Christensen) (09/20/89)
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 suggestion above as reccommendations, 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 | +-----------------------------------------------------------------------------+
jbvb@ftp.COM (James Van Bokkelen) (09/21/89)
In article <406@excelan.COM>, edc@excelan.com (Eric Christensen) writes: >.... > 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. >.... Network monitors are indeed invaluable when something goes wrong, and you need a way of seeing what is actually happening on the cable. However, they aren't all as expensive as Eric implies (the more expensive ones do indeed provide more functionality, but it may not be what you want). Long ago people working on PC-IP at MIT needed a monitor, and had PCs with first-generation network interfaces in them, so they wrote "Netwatch", which puts the interface in promiscuous mode and displays summary information about each packet it receives. This is freeware, and is available in the PC-IP source distribution (FTP to husc6.harvard.edu, or buy a tape of an older version from the MIT Microcomputer Office). The authors of Netwatch helped found FTP, and they had an agenda for improvements to Netwatch, which resulted in our "LANWatch" product ($1.2K). We like it well enough that we don't own anything else, but we *are* somewhat likely to be biased... Wollongong also offers a derivative of Netwatch, which I've never seen. The common weakness of all these is that their packet capture and hardware analysis capabilities are limited, because they use a standard PC LAN interface instead of specialized hardware. This was much more crippling when the 3C500 was pitted against the EXOS225 than it is now that 3rd generation cards are everywhere, but it can be important in some situations. The 10K and up monitors will do their best to capture everything (there was an article in PC Magazine (I think) recently comparing the Spider Monitor, the LANAlyzer, the Sniffer and the HP monitor; they all started out well but their buffers aren't infinite). The ones that run on hardware you already own definitely can't capture everything, and they may not report as much detail on damaged packets, etc. on the net. The worst thing about all these monitors is that they aren't too much use unless you understand something about the protocols you're using; they don't tell you "4.2bsd host foo.bar.com apparently can't understand IP options", instead they let you look at the last packet before it crashed and make you figure it out for yourself. -- James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
f0057@uafhp.uucp (James E. Ward) (09/21/89)
Well, we used the cheap method and isolated various portions of the network until we found the culprit: a bad card on one of the workstations. Performance is back and our thanks to you, people of the net! I am going to ftp to the site mentioned and try to get the net monitoring software today as well! James Everett Ward f0057@uafhp.uark.edu "Somewhere", said Father Vittorini, "did Blake not speak of the Machineries of Joy? That is, did not God promote environments, then intimidate these Natures by provoking the existence of flesh, toy men
rick@lrark.UUCP (Rick Mobley) (09/23/89)
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? > James Everett Ward f0057@uafhp.uark.edu > I often quote myself; it adds spice to my conversation. > -- G. B. Shaw James, Without knowing what NIC's you are using, it sounds almost impossible to tell. I would suggest an analyzer (either PC-based monitor) or something that would allow you to watch the network. There is also a feature of Netware that will allow you to monitor traffic. It could be useful to see if you have a card that is sending broadcast packets out with no useful information or destination addresses. Performance tests are useful on a 30+ node network. I don't get into Fayetteville often, but could be worth a trip. (Say hi to Ray Puckett for me!) 73, -- Ricky L. Mobley, WB5FDP | Mail) ...!uunet!wugate! | CIS: 70505,1157 1800 Sanford Drive #4 | Path) wuarchive!texbell! | PACKET: WB5FDP @ WD5B Little Rock, AR 72207 | ark!lrark!rick | XBBS: (501) 224-9454
edc@excelan.com (Eric Christensen) (03/10/90)
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 | +-----------------------------------------------------------------------------+