ETHERNET

Her vises uddybende forklaringer til fejltyper som kan forekomme nævnt i målerapporter, hvor der anvendes Hewlett Packard Network Advisor som dataanalysator.

Network Advisor anvendes i forbindelse med følgende standardmålinger hos Holm & Bertram: LAN Status Måling, LAN Belastnings Måling, LAN Netværks Måling.


uddybning af målerapporter

VITAL SIGNS

Utilization % is a measure of the amount of time that your network is being used to transmit data. Therefore, it is an important statistical parameter which indicates how much of the network bandwidth is in use. A high Utilization % could indicate excessive traffic levels.

There are two Utilization % measurements which can be done in Ethernet Vital Signs, and which one is performed depends on the current data source (which is selected in the Network Advisor Setup window):

* If the data source is Network Under Test, the Network Counts Utilization % measurement is done. This measurement runs from hardware connected directly to the network interface. Therefore this measurement is not affected by the presence of capture filters, because the Utilization % calculation is done on frames before they enter the Capture Buffer. This measurement is guaranteed to not miss any frames or data.

* If the data source is Capture Buffer, the Buffer Counts Utilization % measurement is done. This measurement runs from frames already in the Capture Buffer. Since capture filters affect which frames enter the Capture Buffer, capture filters affect this measurement. In addition, the performance of this measurement is limited by the RISC processor analysis system.

Regardless of which Utilization % measurement is run, the following formula is used to calculate the Utilization percentage:

(Number of bits measured in 1 second / 10,000,000) * 100


where the number of bits measured does NOT include the preamble, the start delimiter, or the minimum interframe spacing (9.6 microseconds). Any sequence of bits which is preceded by a valid preamble and which contains a frame delimiter is counted as a frame and is included in the Utilization % calculation.

Here are two example calculations for a fully loaded 10Mbps Ethernet network:

----------------------------------

Frames of the Minimum Frame Length

----------------------------------

The minimum frame length is 64 octets:

* 6 octets for the Destination Address

* 6 octets for the Source Address

* 2 octets for the type or length

* 46 octets for the data

* 4 octets for the FCS

To these 64 octets must be added the following 20 octets in order

to calculate the maximum frame rate:

* 7 octets for the preamble

* 1 octet for the frame delimiter

* 9.6 microsecond for the minimum frame spacing (equivalent to 12 octets)

Thus, the total number of bits is 672 (84 octets times 8 bits per octet), and the maximum frame rate for frames of the minimum legal length is:

10,000,000/672 = 14,881

In such a case, the Utilization % is calculated as the number of bits for the minimum frame length times the maximum frame rate divided by 10,000,000. The resulting number is then multiplied by 100 to convert it to a percentage:

64 * 8 (14881/10,000,000) * 100 = 76.2%

----------------------------------

Frames of the Maximum Frame Length

----------------------------------

The maximum frame length is 1518 octets. To this must be added the following 20 octets in order to calculate the maximum frame rate:

* 7 octets for the preamble

* 1 octet for the frame delimiter

* 9.6 microsecond for the minimum frame spacing (equivalent to 12 octets)

Thus, the total number of bits is 12,304 (1538 octets times 8 bits per octet), and the maximum frame rate for frames of the maximum legal length is:

10,000,000/12,304 = 813

In such a case, the Utilization % is calculated as the number of bits for the maximum frame length times the maximum frame rate divided by 10,000,000. The resulting number is then multiplied by 100 to convert it to a percentage:

1518 * 8 * (813/10,000,000) * 100 = 98.7%

--------------------------------

'---' Displayed in Utilization %

--------------------------------

Normally, when Ethernet Vital Signs is running, the Advisor continuously monitors the network and sends, to the display at the end of each sample time, data about the total number of bytes on the network. If the Vital Signs measurement is unable to process the samples as fast as they are arriving, '---' is displayed in place of a Utilization percentage. This can happen if you have too many other measurements running or if you are printing a long file. As soon as the measurement can accept sample data again, the Utilization % field displays a value.

Frames is a count of all the frames and frame fragments received by the Advisor. This includes collision fragments, all good frames, and all frames with errors on the network.

The Local Collisions count is incremented when a proper collision fragment has been received. To be proper, the frame must be shorter than 64 bytes (a runt), and the Advisor must have

detected a collision during the reception of the frame.

The Late Collisions count is incremented when an improper collision fragment has been received. To be counted as a late collision, the frame must be longer than 64 bytes and the Advisor must have detected a collision during the reception of the frame.


The Remote Collisions count is incremented when a fragment is received which is likely to be the result of a proper collision on another segment of the network. Bridges, repeaters, and 10BaseT hubs commonly filter out the signal levels that positively identify collisions. Therefore, the Ethernet Vital Signs measurement must infer that a collision occurred.

To be judged a remote collision, the fragment must be shorter than 64 bytes, have a bad FCS, and contain the jam pattern of alternating 1's and 0's.

On 10BaseT networks, virtually all collisions will appear as remote collisions. On coaxial-based networks, these collisions will be common if the network involves heavy traffic and repeaters. Remote collisions are thus a normal occurrence on most networks. They should occur in numbers similar to local ollisions.


The Remote Late Collisions count is incremented when a fragment is received which is likely to be the result of a late collision on another segment of the network. Bridges, repeaters, and 10BaseT hubs commonly filter out the signal levels that positively identify collisions. Therefore, the Ethernet Vital Signs measurement must infer that a remote late collision occurred.

To be judged a remote late collision, the fragment must be longer than 64 bytes, have a bad FCS, and contain the jam pattern of alternating 1's and 0's.


On 10BaseT networks, virtually all late collisions will appear as remote late collisions. On coaxial-based networks, these collisions will be common if the network involves heavy traffic and repeaters.

If remote late collisions are appearing in surprising numbers on coaxial-based networks, try moving the Advisor to different segments to determine which segment has the LOCAL late collisions and investigate from there. The Ethernet Node Stats measurement can be used to try to isolate the source of these frames.


This is a count of all frames and fragments on the network with a

bad FCS. When a frame is transmitted, a calculation is done using the contents of the Destination Address, Source Address, Type/Length, and Data fields. The resulting value is put into the FCS field. When the frame is received, a similar calculation is done. If the values do not match, an FCS error has occurred.


Runts are frames that are too short. They have less than the 64 bytes required in the Destination Address through the FCS fields. Runts may occur as a result of collisions on the network, or if the transmitting station sent a Data field with less than 46 bytes.

This Runts count includes Runts with good or bad FCS fields.


Misaligns are frames that have a total number of bits that is not divisible by eight and also have an FCS error.

The Runts (good FCS) count is incremented when a runt frame with

a good FCS is received. This is an indication that a device has intentionally sent a runt frame.

Though a violation of the specification, some devices use runts to communicate. These devices are primarily bridges and routers, who use runts to prevent these frames from leaving the local network. No bridge or router should forward a runt frame.


Jabbers are frames that are too long. They have more than 1518 bytes in the Destination Address through the FCS fields.

The Jabbers count is incremented when a jabber frame with a good FCS is received. This indicates that a device has intentionally sent a jabber frame.


In large numbers, jabbers may cause excessive collisions and, therefore, a drop in network throughput due to contention and resolution. The Ethernet Node Stats measurement can be used to try to isolate the source of these frames. Jabbers are frames that are too long. They have more than 1518 bytes in the Destination Address through the FCS fields.

The Jabbers (bad FCS) count is incremented when a jabber frame with a bad FCS is received. These should never occur on a normal network.


The Dribble Frames counter is incremented whenever a frame with no errors is received that has one or more extraneous bits on the end of it. Dribble frames are not a problem under most circumstances.

The Broadcasts count is incremented when a frame with a destination address of FF-FF-FF-FF-FF-FF is received. These frames are commonly used and should be expected in moderate quantities of a few a second.


These frames are significant because each device on the network must spend time receiving and processing them. Bursts of broadcast frames may cause significant problems for some network devices.

The Multicasts count is incremented when a frame is received with a group destination address. A group destination address has the least significant bit of the most significant byte set to 1. In Ethernet, a group address is any address where the first address byte is odd, for example, ODD#-XX-XX-XX-XX-XX.

These frames are significant because, like broadcasts, they represent processing overhead for all devices which are members of the group. Multicast frames are common on many networks. Usually, multicast frames occur less frequently than broadcast frames.


TOP ERROR SOURCES

Ethernet statistical measurements count errors in frames in the following ways.

* Ethernet Summary Stats: Summary Stats shows an overall Error counter which is the total of all error counts. Each kind of error in a frame is also sorted into an error category. Summary Stats can be configured to count many kinds of errors. See the Configure Trends menu for choices.

* Ethernet Vital Signs: Each kind of error is sorted into an error category. This measurement also makes inferences about types of collisions that occur.

* Ethernet Top Error Sources: The number of errors in the frame is added to the total errors seen for each listed node. The kinds of errors seen by each node are listed, although the totals for each kind of error are not listed. Use Vital Signs or Summary Stats to see totals for each kind of error.

* Ethernet Node Stats: Errors in the Data Link Layer (physical layer) are totaled for each node. Runts, jabbers, bad FCS, and misaligns are counted as errors.

* Ethernet Protocol Stats: Errors in the Data Link Layer (physical layer) are totaled for each protocol. Runts, jabbers, bad FCS, and misaligns are counted as errors.


There are many combinations of errors that can occur in a frame. The table below shows several examples of error frames and how they are processed by the Internet Advisor LAN Statistical measurements.

Note: Because a frame can have more than one error, the total error count may be greater than the number of frames.


Except for interpreting and counting collisions in Ethernet Vital Signs, the statistical measurements agree on error counts.

The Ethernet Vital Signs measurement gives definitions for each specific frame error.


NOVELL VITAL SIGNS

Network Utilization % is a measure of the amount of time that your network is being used to transmit data. Therefore, it is an important statistical parameter which indicates how much of the network bandwidth is in use. A high Network Utilization % could indicate excessive traffic levels.


The Network Utilization percentage is calculated by totalling all the bytes in each frame on the network. The frame bytes counted include all the good frames, frame fragments, and frames with errors received by the Internet Advisor LAN. This total is then divided by the theoretical maximum. For example, on an Ethernet network, the theoretical maximum is 1.25 MBytes per second for a 10 Mbits/second network. (Note that because the theoretical maximum can never be achieved, the Network Utilization % is never greater than 99%.)

--------------------------------

'---' Displayed in Utilization %

--------------------------------

Normally, when Novell Vital Signs is running, the Internet Advisor LAN continuously monitors the network and sends data to the display about the total number of bytes on the network at the end of each sample time. If the Vital Signs measurement is unable to process the samples as fast as they are arriving, '---' is displayed in place of a utilization percentage. This can happen if you have too many other measurements running or if you are printing a long file. As soon as the measurement can accept sample data again, the Network Utilization % field displays a value.

The IPX Utilization percent shows the percentage of all frames on the network which are IPX frames.

The Network Packets count shows the count of packets per second on the network.

The IPX Packets count shows the count of IPX packets per second detected on the network.

The IPX Packet Size value is the average number of bytes in the IPX packets seen during the last sample period.

Small packet sizes are efficient for command exchanges, large packets are efficient for file transfers. Use this statistic to tune your network.


The Local Transmission Rate shows the number of kilobytes per second transmitted on the local network during the last sample period. Packets with a hop count of zero are considered local transmission frames.

The Remote Transmission Rate shows the number of kilobytes per second transmitted on remote networks during the last sample period. Packets with a non-zero hop count are considered remote transmission frames.

The Burst Mode count shows the Netware traffic using the Netware Burst Mode protocol.

This value shows the number of Routing Information Protocol (RIP) frames during the last sample period. A Routing Information Protocol packet is used to exchange routing information on the network.

This value shows the number of Service Advertising Protocol (SAP) frames on the network during the last sample period. A Service Advertising Protocol packet is used to announce which services are available at which addresses.

This value shows the number of Read Request frames during the last sample period.


This value shows the number of Write Request frames during the last sample period.

A Busy Server message is sent by the file server when it receives a duplicate service request while the original request is being processed. The requestor then resets its timeout and retry values.

The Busy Server % is calculated as the total number of Busy Server messages divided by the total number of IPX frames.

Note that if you want to find the number of Busy Server messages sent by just one server, you need to activate a capture filter in which you enter the server's address as the source address.

For example, you can modify the Basic Ethernet IPX filter by opening the Basic Ethernet IPX Capture Filter window and putting in a server's MAC address in the IPX Station 1 Address field, leaving the Station 2 Address field set to Don't Cares (all Xs), and setting the Traffic Mode field to From Stn 1. Then you can activate the filter in the Capture Filters window and run the Novell Vital Signs measurement. This will then show you the Busy Server %, and the other vital signs, for just this server.

Use the Commentator measurement and Commentator help topics to troubleshoot the problem.




TCP/IP VITAL SIGNS

Network Utilization % is a measure of the amount of time that your network is being used to transmit data. Therefore, it is an important statistical parameter which indicates how much of the network bandwidth is in use. A high Network Utilization % could indicate excessive traffic levels.

The Network Utilization percentage is calculated by totalling all the bytes in each frame on the network. The frame bytes counted include all the good frames, collision fragments, and frames with errors received by the Internet Advisor LAN. This total is then divided by the theoretical maximum. For example, on an Ethernet network, the theoretical maximum is 1.25 MBytes per second for a 10 Mbits/second network. (Note that because the theoretical maximum can never be achieved, the Network Utilization % is never greater than 99%.)

--------------------------------

'---' Displayed in Utilization %

--------------------------------

Normally, when TCP/IP Vital Signs is running, the Internet Advisor LAN continuously monitors the network and sends data to the display about the total number of bytes on the network at the end of each sample time. If the Vital Signs measurement is unable to process the samples as fast as they are arriving, '---' is displayed in place of a utilization percentage. This can happen if you have too many other measurements running or if you are printing a long file. As soon as the measurement can accept sample data again, the Network Utilization % field displays a value.

IP Utilization % shows the percentage of all frames on the network which are IP (Internet Protocol) frames.


IP Packets shows the number of IP (Internet Protocol) packets per second on the network.

The IP (Internet Protocol) Broadcast count increments when a frame is received in which the destination address matches the address specified in the IP B-Storm Address field of the Configuration window.

A storm may be caused by misconfigured multicast addresses on Ethernet.


The IP (Internet Protocol) Fragment count increments when a frame with the More Fragments bit set is seen on the network, or when the Fragment Offset field is non-zero.

The ICMP Redirect count shows the number of times a packet had to be redirected to another gateway or router.


A large number of ICMP Redirects can indicate a segment of the network is malfunctioning. Use the Commentator measurement and Commentator help topics to troubleshoot the problem.

An ICMP Unreachable message is sent when a router cannot route an IP datagram to its destination.


Use the Commentator measurement and Commentator help topics to troubleshoot the problem.

The Low TTL threshold is crossed when more than the threshold number of frames with Time To Live values less than what is specified in the IP Low TTL Value field of the Configuration window are seen during the sample period.


IP Packet Size shows the current, average, and peak IP packet size. The packet size is determined by dividing the number of IP bytes by the number of IP packets.

Small packet sizes are efficient for command exchanges, large packets are efficient for file transfers.


The SNMP Get/Set Packets count increments when an SNMP V1 or V2 Get or Set packet is seen on the network.

The SNMP Trap Packets count increments when an SNMP V1 or V2 Trap packet is seen on the network.


The DNS Packets count increments when a Domain Name System packet is seen on the network.

The ARP Packet count increments when an Address Resolution Protocol packet is seen on the network.

The Low Window threshold is exceeded when more than the threshold number of frames with a Low Window size less than what is specified in the TCP Low Window Value field of the Configuration window are detected during the sample period. A low window size may result in unacceptably slow file transfers, and often indicates a poorly tuned network.


The Reset Connection count is increased when a TCP frame indicates a session is terminated abnormally.

Another possible cause of this message is a user aborting a connection due to slow response from a server.


The Routing Packets count increments when RIP (Routing Information Protocol), GGP (Gateway to Gateway Protocol), IGRP (Inter-Gateway Routing Protocol), and OSPF (Open Shortest Path First) frames are detected on the network during the sample period.

DecNet VITAL SIGNS


Network Utilization % is a measure of the amount of time that your network is being used to transmit data. Therefore, it is an important statistical parameter which indicates how much of the network bandwidth is in use. A high Network Utilization % could indicate excessive traffic levels.

The Network Utilization percentage is calculated by totalling all the bytes in each frame on the network. The frame bytes counted include all the good frames, collision fragments, and frames with errors received by the Internet Advisor LAN. This total is then divided by the theoretical maximum. For example, on an Ethernet network, the theoretical maximum is 1.25 MBytes per second for a 10 Mbits/second network. (Note that because the theoretical maximum can never be achieved, the Network Utilization % is never greater than 99%.)


--------------------------------

'---' Displayed in Utilization %

--------------------------------

Normally, when DECnet Vital Signs is running, the Internet Advisor LAN continuously monitors the network and sends data to the display about the total number of bytes on the network at the end of each sample time. If the Vital Signs measurement is unable to process the samples as fast as they are arriving, '---' is displayed in place of a utilization percentage. This can happen if you have too many other measurements running or if you are printing a long file. As soon as the measurement can accept sample data again, the Network Utilization % field displays a value.

The DRP (DECNet Network Routing Protocol) Utilization percent shows the percentage of all frames on the network which are DRP frames. A frame with Ethertype 6003 Hex is counted as a DRP frame.


The LAVC (Local Area Vax Cluster) Utilization percent shows the percentage of all frames on the network which are LAVC frames. A frame with Ethertype 6007 Hex is counted as a LAVC frame.

The MOP (Maintenance Operations Protocol) Utilization percent shows the percentage of all frames on the network which are MOP frames. A frame with Ethertype 6001 or 6002 Hex is counted as a MOP frame.

The DECNet Network Architecture Routing Protocol (DRP) Packet Size count shows the average DRP Packet Size. The value is determined by dividing the number of DRP bytes by the number of DRP packets.


The DECNet Network Architecture Routing Protocol (DRP) Data Messages count shows the total number of DRP Packet Data Messages per second on the network.

The two types of Data Messages are:

* Short Data Message

* Long Data Message

The DECNet Network Architecture Routing Protocol (DRP) Routing and Control Messages count shows the total number of DRP Routing and Control Messages on the network.


Routing and Control messages are any of the following:

* Initialization message

* Verification Message

* Hello and Test Message

* Level 1 Routing Message

* Level 2 Routing Message

* Ethernet Router Hello Message

* Ethernet Endnode Hello Message


The DECNet Network Architecture Routing Protocol (DRP) Return to Sender (RTS) Packets count shows the number of DRP Packets that could not be delivered and are being returned to the sender. Packets are returned to sender only if requested, so this is not the count of packets which could not be delivered.

The DECNet Network Architecture Routing Protocol (DRP) High Visit Count shows the number of packets in which the Visit Count is greater than the value specified in the DRP High Visit Count field of the Configuration window. The Visit Count is incremented by every node that receives the packet as it is on its way to its destination.


The Network Services Protocol (NSP) Fragment count shows the number of fragmented data packages seen during the sample period. A packet is counted as a fragment if either the 'Begin Message' or the 'End Message' bit is set, but not if both are set.

The Network Services Protocol (NSP) Retransmitted Connect Initiates count shows the number of packets indicating a retransmitted connection initiated packet.

The DECV Utilization percent shows the percentage of all frames on the network which are DECV frames.

The DECV Packet Size shows the average size of the DEC packets on the network. The DECV Packet Size is determined by dividing the number of DECV bytes by the number of DECV packets.


The Connectionless Network Protocol (CLNP) Error Protocol Data Units (PDU) count is the number of CLNP Error PDUs seen on the network. A CLNP Error PDU shows the reason for discarding the errored frame. The reason can be any of the following:

* Reason not specified

* Protocol procedure error

* Incorrect checksum

* PDU discarded due to congestion

* Header syntax error (cannot be parsed)

* Segmentation needed but not permitted

* Incomplete PDU received

* Duplicate option

* Destination address unreachable

* Destination address unknown

* Unspecified source routing field

* Syntax error in source routing field

* Unknown address in source routing field

* Path not acceptable

* Lifetime expired while data unit in transit

* Lifetime expired during reassembly

* Unsupported option not specified

* Unsupported protocol version

* Unsupported security option

* Unsupported source routing option

* Unsupported recording of route option

* Reassembly interference

Use the Commentator to see the error value for this frame.


The DECV Connectionless Network Protocol (CLNP) Data Protocol Data Units (PDU) count shows the number of CLNP Data PDUs seen on the network.

The DECV Low Lifetime count shows the number of packets in which the Lifetime value is less than the value specified in the DECV CLNP Low Lifetime field of the Configuration window. The Lifetime count is decremented by every node that receives the packet as it is on its way to its destination.

The Transport Protocol Error PDU count shows the number of Transport Protocol PDUs on the network. A TP Error PDU is generated when a TP frame is discarded.


The possible reasons for discard are:

* Reason not specified

* Invalid parameter code

* Invalid TPDU type

* Invalid parameter value


The DECV Low Credit count shows the number of packets in which the Credit value is less than the value specified in the DECV TP Low Credit field of the Configuration window. The Credit count is an indication of how many PDUs can be sent without Acknowledgement.

The DECV Fragments count shows the number of frames on the network that do not have the EOT bit set. This count is an indication of the number of frames that are being fragmented.