Novell Doc: NW 6.5 SP8: Utilities Reference - Monitoring Network Traffic

A.1 Monitoring Network Traffic

By comparing information about LAN drivers installed on your server, you can tell which cabling system is handling the most traffic.

If errors occur frequently on a high-traffic system, you may want to switch some of the stations on the busy system to a new or less busy cabling system.

To view LAN driver statistics:

At the server console prompt, enter
```
[LOAD] MONITOR
```
Select Available Options > LAN/WAN Drivers.
Select a LAN driver from the Available LAN Driver menu.

The statistics for the selected LAN driver are displayed. Press Tab > PageUp or PageDown to scroll through the information in the window.

For more information, see Section 1.82, LOAD.

A.1.1 Common LAN Driver Statistics

The generic statistics common to most of the drivers are maintained by two modules in the NetWare® operating system that are autoloaded by LAN drivers. The modules are:

The Media Support Module™ (msm.nlm)
The Topology Specific Module™ (tsm.nlm)

There are three TSM™ modules. The one that is autoloaded will depend on your server's LAN driver. The three are ETHERTSM (Ethernet), TOKENTSM (token-ring), and FDDITSM.

These common LAN driver statistics can be viewed with MONITOR. Select Available Options > LAN/WAN Drivers, and then select a driver. The system displays a window containing both the generic and custom statistics for the selected driver.

Brief descriptions of the statistics maintained by the MSM module and each of the TSM modules are found in the following tables:

A.1.2 Custom LAN Driver Statistics

Custom statistics describe LAN activity for specific LAN device drivers.

The custom LAN driver statistics can be viewed with MONITOR. Select Available Options > LAN/WAN Drivers, and then select a driver, then press Tab. The system displays a window containing both the generic and custom statistics for the selected driver.

Brief descriptions of statistics for selected drivers are found in the following tables:

NOTE:Custom statistics vary, depending on the LAN driver installed. For statistical information about third-party drivers not listed in the custom statistics section, check the documentation that comes with the driver.

Table A-1 LAN Driver Statistics

Statistic	Description
Driver Name	The driver name and parameters that correspond to the hardware settings on the network board.
Version	The current version of the driver.
Logical Board Number	The number which uniquely identifies each time a driver is registered with the system.
Board Instance Number	The number assigned to each physical adapter for which the driver has been loaded..
Node Address	The station or node address of the network board in the NetWare server.
Protocols	The communication protocols bound to the driver with BIND.
Network	The network number assigned to the cabling system the LAN driver is operating on. Appears only if the IPX™ protocol has been bound to the board.
Total Packets Transmitted	The number of packets sent from the NetWare server through this LAN driver since the driver was loaded. (By comparing this figure with the figures for other LAN drivers, you can see which driver is handling the most traffic.) This value is maintained by the TSM module.
Total Packets Received	The number of packets received by the NetWare server sincethe driver was loaded. This includes file service requests, packets routed to another network, and packets sent to other IPX sockets in the NetWare server. This value is maintained by the TSM module.
Transmit failed, packet too big	A counter that is incremented when the NetWare server tries to transmit a packet that is too large for the hardware to handle. This value is maintained by the TSM module.
Transmit failed, packet too small	A counter that is incremented when the NetWare server tries to transmit a packet that is too small. This value is maintained by the TSM module.
Receive discarded, no available buffers	A counter that is incremented when a device sends a packet to your NetWare server, but no packet receive buffer is available. The server allocates more packet receive buffers after each incident until it reaches its maximum limit (configured with a SET parameter). If you are using an EISA or microchannel bus-master board (such as the NE3200™ board), you will probably need to increase both the minimum and maximum number of packet receive buffers. See Minimum Packet Receive Buffers and Maximum Packet Receive Buffers in SET Communications Parameters. No ECB Available Count messages can also indicate that the driver is not configured correctly or that the TSM module and the Hardware Specific Module™ (HSM™) are incompatible. This value is maintained by the TSM module.
Receive failed, packet too big	A counter that is incremented when the NetWare server receives a packet that is too big for the provided receive buffers. This value is maintained by the TSM module.
Receive failed, packet too small	A counter that is incremented when the NetWare server receives a packet that is too small. Currently only the RX-Net™ TSM module maintains this counter.
Receive failed, adapter overflow	A counter that is incremented each time the adapter's private receive buffer pool was exhausted. This causes subsequent incoming packets to be discarded. This value is maintained by the HSM module.
Transmit failed, Miscellaneous Error	A counter that is incremented when errors with send packets occur. This value is maintained by the HSM module.
Receive failed, Miscellaneous Error	A counter that is incremented when errors with receive packets occur. This value is maintained by the HSM module.
Transmit failed, retried	A counter that is incremented when the NetWare server tries to send a packet but fails because of a hardware error. The server tries to send the packet until either it succeeds or the retry setting is reached. This value is maintained by the HSM module.
Receive failed, checksum error	A counter that is incremented when the checksum byte at the end of the packet does not match the sum of the bytes contained in the packet. This indicates a data error. This value is maintained by the HSM module.
Receive failed, packet length	A counter that is incremented when the packet length received by the hardware and the length specified by the packet do not match. Currently only the Ethernet TSM module maintains this counter.
Bytes transmitted modulo 4 GB	The number of bytes, including low-level headers, successfully transmitted. This value is maintained by the TSM module.
Bytes transmitted rollover <times 4 GB>	Upper 32 bits of the Total Send OK Byte Count Low. The Total Send OK Byte Count High statistic is incremented to 1 when the Total Send OK Byte Count Low counter reaches 4 GB. This value is maintained by the TSM module.
Bytes received modulo 4 GB	The number of bytes, including low-level headers, successfully received. This value is maintained by the TSM module.
Bytes received rollover <times 4 GB>	Upper 32 bits of the Total Receive OK Byte Count Low. The Total Receive OK Byte Count High statistic is incremented to 1 when the Total Receive OK Byte Count Low value reaches 4 GB. This field is maintained by the TSM module.
Transmitted to a group address	The number of packets transmitted with a group or multicast destination address. This field is maintained by the TSM module.
Received from a group address	The number of packets received with a group or multicast destination address. This field is maintained by the TSM module.
Adapter resets	The number of times the adapter was reset because of internal failures or other calls to the Driver Reset routine. This field is maintained by the HSM module.
Adapter state change time stamp	The time stamp indicating when the adapter last changed operational state (such as load, shutdown, or reset). This value is maintained by the MSM module.
Packets queued for transmission	The number of transmit packets (transmit ECBs) that are queued for the adapter. This is an indication of throughput overload on transmits. This field is maintained by the TSM module.

Table A-2 Generic Statistics for Ethernet Drivers That Use Ethertsm.nlm

Statistic	Description
Transmit succeeded, single collision	The number of frames involved in a single collision that are subsequently transmitted successfully. When the Ethernet controller detects a collision, it backs off and then retries the transmission.
Transmit succeeded, multiple collisions	The number of frames involved in more than one collision that are transmitted successfully. This happens if the Ethernet controller had to back off more than once due to collisions.
Transmit succeeded, deferred	The number of frames whose transmission was delayed because of a busy medium. This happens if another station is transmitting on the wire when the adapter receives the command to transmit a packet.
Transmit failed, late collision	The number of transmits that had a collision after 512 bits of the packet were transmitted. This can be caused by faulty adapters, faulty network equipment, cables that are too long, or faulty terminators.
Transmit failed, excessive collisions	The number of transmits that were aborted because of too many collisions. This usually indicates that a board in the network is bad or jabbering. (Jabbering means the board has been on the channel longer than the time needed to transmit the maximum size packet.) This condition could also occur in very heavy traffic conditions.
Transmit failed, carrier sense missing	The number of transmits aborted because of loss of carrier sense while transmitting without any collisions. This is usually caused by a faulty adapter in the network, faulty cabling, an unterminated cable, or a faulty repeater.
Transmit failed, excessive deferral	The number of transmits aborted because of excessive deferrals. This is usually caused by a faulty adapter or repeater in the system that is jabbering on the wire. It can also occur under very heavy traffic conditions.
Receive failed, bad frame alignment	The number of received frames that were misaligned. This occurs when the number of octets in the frame is not correct or the frame does not pass the FCS check. These bad packets are usually caused by a faulty adapter or repeater in the system. They can also be caused by a collision.

Table A-3 Generic Statistics for Token Ring Drivers That Use Tokentsm.nlm

Statistics	Description
AC Errors	This counter is incremented when a ring station receives a Standby Monitor Present MAC frame with the A/C bits in the Frame Status field equal to zero without first receiving an Active Monitor Present MAC frame.
Transmit failed, abort delimiter sent	This counter is incremented when a ring station transmits an abort delimiter. An abort delimiter is transmitted when a ring station receives a frame in which the token bit of the access control field is set to show Token and not Frame. A ring station can also transmit an abort delimiter if an internal hardware error has occurred.
Burst errors	This counter is incremented when a ring station detects the absence of five half-bit times (a burst-five error). Other stations will detect a burst-four error followed by idles.
Frame copied errors	This counter is incremented when a ring station recognizes (receives or repeats) a frame addressed to its specific address and detects that the FC field A bits are set to 1, indicating a possible line hit or a duplicate address.
Frequency errors	This counter is incremented when the frequency of the incoming signal differs from the expected frequency by more than that specified in Section 7 of IEEE Standard 802.5-1989.
Recoverable internal error	This counts the times a ring station has a recoverable internal error, which means a ring station is probably marginal.
Last ring status	This code changes each time the ring status changes. Status codes are reported by the physical hardware. See the IBM* Token-Ring Network Architecture Reference for the status code, function, and meaning.
Line errors	This counter is incremented when a frame or token is repeated by the ring station. A frame is repeated when a Frame check Sequence error occurs or a code violation exists between the starting and ending delimiters of the frame.
Transmit failed, lost frame	This counter is incremented when a ring station transmits a frame that does not return to the station. The active monitor sends a new token.
Error tokens transmitted	This counter is incremented when a station acting as the active monitor recognizes an error condition that needs a token transmitted. This occurs when the TVX time expires.
Upstream node address	The twelve digits of the upstream node address of the next node up stream on the ring.
Last ring ID	This contains the value of the local ring ID.
Last beacon type	This contains the value of the last beacon type.

Table A-4 Generic Statistics for FDDI Drivers That Use Fdditsm.nlm

Statistic	Description
Configuration State	The attachment configuration for the station or concentrator: 0=isolated; 1=local_a; 2=local_b; 3=local_ab; 4=local_s; 5=wrap_a; 6=wrap_b; 7=wrap_ab; 8=wrap_s; 9=c_wrap_a; 10=c_wrap_b; 11=c_wrap_s; 12=thru
Upstream Node Address	The upstream neighbor's MAC address (0 if unknown).
Downstream Node Address	The downstream neighbor's MAC address (0 if unknown).
Receive failed, frame error	The number of frames that were detected in error by this MAC that had not been detected in error by another MAC.
Receive failed, lost frame	The number of instances that this MAC detected a format error during frame reception such that the frame was stripped.
Ring Management State	Indicates the current state of the Ring Management state machine: 0=Isolated; 1=Non_Op; 2=Ring_Op; 3=Detect; 4=Non_Op_Dup; 5=Ring_Op_Dup; 6=Directed; 7=Trace
Consecutive LCT failures	The count of the consecutive times the link confidence test (LCT) has failed during connection management.
LEM, link rejected	The link error monitor (LEM) count of the times that a link was rejected
LEM, total errors	The aggregate link error monitor (LEM) error count.
Connection state	The state of this port's Physical Connection Management (PCM) state machine: 0=Off; 1=Break; 2=Trace; 3=Connect; 4=Next; 5=Signal; 6=Join; 7=Verify; 8=Active; 9=Maint

Table A-5 Custom Statistics for NE2000, NE2, NE2_32, CNE2_32, and Other Ethernet Drivers

Statistic	Description
UnderrunErrorCount	This counter is incremented when the RAM buffer on the network board is full; the board cannot accept any more packets until the RAM buffer is cleared.
TransmitTimeoutCount	This counter is incremented when a network board interrupts the file server with the message that the send bit is lost. This is a hardware problem caused by faulty cabling, a bad network board, or a missing terminator.
RxPagingErrorCount	This is a count of the errors that occur when internal buffers on the board are corrupted.
ReceiveFIFOOverrunErrorCount	This counter is incremented when an incoming packet causes an overflow because FIFO was not serviced.
ReceiverMissedPacketCount	This counter is incremented when a packet is sent to a network board that cannot accept the packet because all its receive buffers are full.
GotNothingCount	This counter is incremented when the file server receives an interrupt from a network board that is not transmitting or receiving anything. This is not serious.
UnsupportedFramePacketCount	This counter is incremented when a packet is received by the LAN driver with a frame type that hasn't been loaded for the given board.
UnsupportedMulticastCount	This counter is incremented for each multicast packet received by the board that is not registered with the driver.
BackToBackSendCount	This counter is incremented each time the driver can buffer a send packet onto the network board while the board is sending a previous buffer. Use this counter to track congestion on the network board. See also EnqueuedSendsCount.
EnqueuedSendCount	This counter is incremented when the driver is unable to transmit a packet and must put the packet in a queue until the transmitter is available. Use the counter to track congestion on the network board. See also BackToBackSendCount.
HeartBeatError	(NE2100™, NE1500T™, or CNEAMD™) This counter is incremented when there is a signal quality error. This function is also known as the heartbeat or Signal Quality Error (SQE) test. This counter indicates a hardware problem.
MemoryTimeout	(NE2100, NE1500T, or CNEAMD) This counter is incremented when there is contention on the bus. If this counter is incremented, there may be multiple boards in the server or another bus-mastering device in the server, such as a LAN or disk channel device.
TxBabblingError	(NE2100, NE1500T, or CNEAMD)This counter is incremented when there is excessive length in the transmit buffer. It will increment after 1,519 data bytes have been transmitted from the buffer. It indicates that the transmitter has been on the channel longer than the time required to send the maximum length packet. If this counter is incremented, it indicates a hardware problem with the network board in the server.
TxUnderflowError	(NE2100, NE1500T, or CNEAMD) This counter is incremented when something else on the bus takes control of the bus while the LAN driver is putting the data on the wire. If this occurs, the packet must be retransmitted.
TXBufferError	(NE2100, NE1500T, or CNEAMD) This counter is incremented when there is a problem with the transmit buffer. This counter is usually incremented when TxUnderflowError is incremented; it indicates a hardware problem in the server.
RxECBsOver16MegCount TxECBsOver16MegCount	(NE2100, NE1500T, or CNEAMD) One of these counters is incremented when either a transmit or receive occurs and the driver has double buffered the ECB in the reserved buffers below 16 MB in memory. These boards require double buffering because they have a physical limitation that prevents them from accessing memory above 16 MB. Therefore, if the operating system issues an Event Control Block (ECB) with a memory address above 16 MB, the board uses some of the reserved buffers below 16 MB to queue the request. These are not errors. This value tracks how many ECBs are redirected to the buffers below 16 MB. In many cases, this counter can be as high as the total packets sent and received. This double buffering decreases performance. If you have more than 16 MB of RAM and a board that is bus-mastering or using DMA that is not a 32-bit adapter, performance might be degraded.
PacketUsed2ECBs	(NE2100, NE1500T, or CNEAMD) This counter is incremented if the Server Maximum Physical Receive Packet Size is set to 1514 bytes (default for NetWare 3.11 servers), and you need to receive a near-full-size packet. For NetWare 3.12 and 4.x, the default Maximum Physical Receive Packet Size is 4202. In this instance, two ECBs are used instead of one, since the CRC on the end of the packet requires an extra four bytes. Using two ECBs instead of one may decrease performance slightly.
TransmitRetryCount	(NE3200™) This counter is incremented when the driver is unable to transmit a packet after a specified number of times. This may indicate a hardware problem.
TxClearToSendsErrors	(NE3200) This counter tracks an 82586 error. There are some conditions when the Clear to Send signal from the 82586 chip is incorrect. This counter indicates the number of times the corrective code on the adapter was executed to work around this condition in the 82586.
TxDMAUnderrunErrors	(NE3200) This counter tracks an 82586 error. Contention among the BMIC, 80186, and 82586 can occur on the adapter, causing the 82586 to assume it did not receive all of the packet for transmission. The transmit operation must then be retried. This counter indicates the number of times the corrective code on the adapter was executed to work around this condition.
RxDMAOverrunErrors	(NE3200) This counter tracks an 82586 error. If two packets are received back-to-back at close to 9.6 microseconds (the minimum Ethernet interframe spacing), then the chip may report an overrun. If so, the frames are lost by the chip and the source must retransmit. This counter indicates the number of times this error has occurred.
RxPacketSlideErrors	(NE3200) This counter tracks the number of instances of an 82586 anomaly. In some conditions, the 82586 might be off by two bytes in the receive packet descriptors. In this case, the sending station must retransmit the packet. This counter indicates the number of times this condition has occurred.
RxDummyRCBUsedErrors	(NE3200) This counter tracks an 82586 error. In some cases, the 82586 may attempt to receive data into a nonexistent receive buffer at the end of its receive buffer list. To catch this condition and avoid internal data corruption, a dummy receive buffer is added to the end of the list. This variable counts the number of times the 82586 attempted to write into the dummy buffer.
InternalAdapterReset	(NE3200) This counts the number of resets (by the 80186) that occurred on the adapter due to failures on the adapter. This counter is incremented when the software corrects itself for minor problems or if the adapter is in an unknown state. It is common for this counter to be incremented. Under normal conditions, more of these errors should occur during idle time than when the driver is busy. This counter would only indicate a hardware problem if it registered thousands of these errors when the network is busy.
MondoFragmentLengthErrors	(NE3200) This counter tracks the number of instances in which an NLM™ on the server has passed the NE3200 driver an ECB whose logical memory address could not be translated to a physical memory address. You should check other NLM programs on the system and upgrade them. If you are still experiencing problems, identify which NLM is causing the problem and contact the third-party manufacturer of the NLM.
PollingTimeout	(NE3200) This counter tracks the number of times the adapter's request was put on the queue but was not serviced within 800 nanoseconds (default). After this occurs, the adapter fires an interrupt.
ResetBecauseHardwareDiedErrors	(NE3200) If the adapter is in an unknown state or stops transmitting on the host side, the driver increments this counter and resets or restarts the adapter.
NumberOfInterruptsFired	(NE3200) This counter is incremented each time the adapter had to fire an interrupt to service a request because the polled request wasn't serviced.

Table A-6 Custom Statistics for Token Ring Drivers

Statistic	Description
Bad Correlator Count	(CNTR2000™, NTR2000™) This counter is incremented when a network board responds with a request for data from the file server that the file server does not have. The ECB or some other code may be corrupted. Eventually, this error will abend the server. If this counter is non-zero, you should try to find the software that is corrupting the data.
Unknown ARB requests	(CNTR2000, NTR2000) This counts bad Adapter Request Blocks (ARBs). Normally the network board (adapter) uses one of four known commands to communicate with the driver. If a network board sends a command that is not one of the four, the driver does not recognize the request. This error is not a catastrophic error. Sometimes old adapters send bad ARB requests because of software problems on the board. NetWare responds to the network board so that the board will not hang.
MicroChannel Error Count	(TOKENDMA) This counter tracks the number of times the adapter had a problem transmitting on the bus. The adapter interrupt occurred from the firmware on the board.
ECBs Over 16 MB	(TOKENDMA) This counter tracks the number of packets received that had to use an ECB over 16 MB. This number should increment only when more than 16 MB of RAM is used in the server.
DMA Bus Errors Count	(TOKENDMA) This counter is incremented when a DMA transfer completes with a bus error. If this counter is incremented, it could indicate a hardware problem.
DMA Parity Errors Count	(TOKENDMA) This counter is incremented when a DMA transfer completes with a parity error. If this is incremented, it could indicate a hardware problem.
Command Reject Count	(TOKENDMA) This counter is incremented when the driver sends a command to the board and the command is either invalid or the board is still busy processing the previous command. This number should be zero or a low number.
Tx Timeout Count	(TOKENDMA) This counter is incremented and the adapter is reset if two seconds elapse before the driver learns from the firmware that the transmit was or wasn't successful. This counter shows the driver is successfully recovering from the lost hardware transmit. It isn't a problem if this number is incremented.
Transmit Late Count	(TOKENDMA) This counter is incremented when the firmware reports that the board transmitted more than it actually did. After this event occurs, the data that wasn't transmitted will be sent in the next packet. This problem is more likely to occur on busier networks.
Transmit Defragment Count	(TOKENDMA) This counter tracks how many ECBs are redirected to the buffer below 16 MB. The IBM Token-Ring DMA LAN boards are not able to access memory above 16 MB. Therefore, if the operating system issues an Event Control Block (ECB) with a memory address above 16 MB, the board uses some of the reserved buffers below 16 MB to double buffer the ECB. These are not errors. In many cases, this counter can be as high as the total packets sent and received. However, this double buffering decreases performance. If the system has more than 16 MB of RAM and a board that is bus-mastering or using DMA that is not a 32-bit adapter, performance may decrease.

Table A-7 Custom Statistics for IBM Baseband PCN2L Drivers

Statistic	Description
HotCarrierInterruptCount	(PCN2L) This counter is incremented when the board detects a carrier longer than expected without a transmit. This indicates that some board on the network has failed or is beginning to fail.
No82588InterruptCount	(PCN2L) This counter is incremented each time the server receives an interrupt from the board, but not from the 82588 chip. This should happen very seldom, if ever.
WeirdInterruptCount	(PCN2L) This counter is incremented when the server has received an interrupt from the board, but the board claims not to have sent one. This should happen very seldom, if ever.
BadTransmitComplete-InterruptCount	(PCN2L) This counter is incremented for each complete transmission with no transmit active.
HardTransmitErrorCount	(PCN2L) This counter is incremented when a transmit fails and the driver retries the transmit.
GotNothingCount	(PCN2L) This counter is incremented when the driver receives an interrupt from the board indicating that it has completed a receive but there is no data in the board's receive buffer. This is not serious.
ReceiveUnderrunErrorCount	(PCN2L) This counter is incremented when the driver finds less data in the board's buffer than the board reported.
ReceivedShortPacketCount	(PCN2L) This counter is incremented when a packet of fewerthan 17 bytes is received.
BadReceiveConditionCodeCount	(PCN2L) This counter is incremented when the buffer is flushed because the board hasn't received the incoming packets properly.