Click on the Clear button to clear the errors and start at zero

4. Wait for about 60 seconds and then look at the accumulated errors (which will be the current errors from the time of zeroing).

Troubleshooting with the Performance View

When you begin to look at error rates and other traffic information, keep in mind that most of the statistics provided have to do with usage levels, packet formation problems, access problems, or network design problems.

Knowing which statistics indicate which sorts of problems can help to narrow the search for your network troubles to one general area. For

Delivered Forwarded Transmitted Errors Discards Total

Packet Breakdown

Total Delta Accum Clear 1515660 73.85%

67818 3.30%

22398 1.09%

9996 0.49%

436528 21.27%

2052400

example, high numbers of active users and high utilization rates may explain why your network is experiencing high collision levels, and may indicate a need for bridging or routing to control traffic levels. Protocol and frame size statistics can help you identify the portions of your network that might best lend themselves to isolation. You may want to group users by protocol, or provide a group of users with an appropriate server if they are consistently using a server outside their network segment. An evaluation of frame size statistics may tell you where and/or when big file transfers are clogging up the cable, or where management packets make up the bulk of traffic (indicating a need for a DLM or RMON device).

Error Rates are a function of frame rates. A high number of errors may actually be a very small percentage of overall traffic, resulting in no significant network disturbance. Looking at error rates as a function of traffic levels can be a good way to detect errors that are occurring simply because your network is getting busier.

The following descriptions will help to isolate the problem:

Collisions (and sometimes runts) are a natural by-product of a busy network; if you notice the levels of these two errors gradually increasing over time, or suddenly increasing at certain times of the day (accompanied by an increase in traffic levels), you may want to consider using bridges or routers for traffic management. High collision counts can also indicate other problems, such as a data loop (redundant active network

connections) or a bad NIC (someone transmitting without listening first).

CRC and Alignment errors can indicate some MAC layer/packet formation problem — either packets are not being properly formed in units of 8 bits, or the element responsible for either the transmit or receive CRC

calculation is malfunctioning, causing perfectly good packets to be

discarded as errors. These error types can also indicate some transmission medium problem — noisy or otherwise unreliable cable that is corrupting the packet as it is transmitted. Remember, according to the error priority schemes employed by Cabletron devices, packets counted as alignment errors may also have CRC errors; packets counted as CRC errors, however, do not contain truncated bytes.

Out-of-Window (OOW) Collisions can either indicate that some portion of your network is out of spec — that is, the furthest distance between two nodes exceeds the 51.2 µs collision window— or that you have a bad transceiver which is transmitting without first listening for carrier sense (either intermittently or consistently). If your network begins to experience OOW collisions, use the port-level statistics screens to determine which nodes are recording these errors. Note that these nodes are not

necessarily the ones which are the source of the problem: the only node that will record an OOW collision is the one that was transmitting for more than 51.2 µs before the collision occurred. If you have an established network which suddenly begins to experience OOW collisions, make sure the maximum propagation delay has not been violated and that your network is still in spec; be especially sure to check the distance between the node or nodes that are recording the errors and the nodes furthest away from those, and between the nodes recording the errors and the newest nodes.

If you find that your network does meet the propagation delay spec, chances are you have a node which is transmitting without first listening for carrier sense. This can be a more difficult problem to track, since the malfunctioning node may only fail to listen occasionally, and since not all of its failures to listen will result in OOW collisions — some may simply result in collisions (if the 51.2 µs window has not closed), and some will get through fine (if no one else happens to be transmitting). The best way to track this kind of problem is to gradually bridge your network until you have isolated the OOW collisions on one segment, then check each node on that segment until you find the culprit. You might also look for a segment which is experiencing both OOW collisions and a sudden increase in regular collisions.

Runts and Giants can both be caused by packet formation problems or by corrupted packets (packets being truncated or lengthened, or frame size bits being corrupted); as stated above, runts can also result from

collisions. Most frequently, giant packets are the result of a jabbering node

— one that just transmits continuously, either for long periods of time or only occasionally — and indicate a bad transmitter on a NIC.

Framesize Statistics Aside from runt and giant packets, which are caused by errors, the sizes of the packets being transmitted on your network can give you an indication of what kind of traffic your network is seeing — many large packets can mean a lot of file transfers; small packets can mean a lot of management traffic — and can also give you an indication of the efficiency of your network — too many small packets indicates an inefficient use of bandwidth (too much overhead for too little data); too many large packets can slow your network down. You can use the framesize data to effectively bridge and/or route your network for a more evenly balanced flow of traffic.

% Load, Bytes, and Packets provide a good overall sense of network usage. You can use these statistics to pinpoint peak usage times or

segments of your network where usage is particularly heavy, which in turn can alert you to upcoming needs to expand, bridge, or route your network.

One thing to note about packet and byte counts: on the newer Cabletron management devices (such as the EMME and the MRXI-24), packet and byte counts include errors; on older devices (such as the IRM2 or IRM3), they do not.

High Broadcast packet counts can indicate the presence of a broadcast storm — an unending flood of ARP and RARP packets transmitted by a defective or improperly configured bridge or router. These storms are a serious matter and can completely shut down your network by

monopolizing the bandwidth.

Packet Size data can provide valuable information about how efficiently your network bandwidth is being used — too many small packets indicates a high overhead cost for the data being transmitted; too many large packets can clog your network and hurt performance. Packet size statistics can also give you a general sense of the types of data being transmitted:

many large packets may indicate large file transfers; many small packets may indicate high levels of management traffic. Many packet size-related problems can be solved by bridging or routing to isolate network segments with special needs.

Protocol Statistics breakdowns can be helpful if you are planning to add bridges, routers, or gateways to your network; you may want to group users by protocol so traffic needn’t pass through multiple segments to reach a designated protocol server or to avoid any problems of

incompatibility. Also, different protocols have different overhead costs and may tend to use either very large or very small packets, so protocol statistics may give you some insight into other network performance issues: You may discover, for example, that a protocol which tends to have large packets also receives heavy use at a particular time of day or on a particular network segment, causing a noticeable slowdown in network traffic. Such problems can be solved by isolating those users on their own bridge- or router-protected network segment.

Protocol Type data can be very useful in planning for bridges, routers, gateways, and even additional servers; you may want to group and/or isolate users based on protocol, especially if users are sending packets beyond their own network segment to reach a specific protocol server on another segment or if there are any issues of incompatibility. In addition, different protocols have different overhead requirements and transmission characteristics, which may have different effects on overall network performance.