TOKEN RING

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.

VITAL SIGNS

It is calculated by totaling all the bytes in each frame on the network. This total is then divided by the theoretical maximum of 0.5 MBytes per second for a 4 Mbit Token-Ring network and 2.0MBytes per second for a 16 Mbit Token-Ring network.

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

'---' Displayed in Utilization %

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

Normally, when Token-Ring 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 canhappen 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 Internet Advisor LAN. Therefore, the Frames count includes all Abort frames, all good frames, and all frames with errors on the network.

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 Frame Control, Destination Address,Source Address, Optional Routing Information, and Information 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.

Code Violations is a count of violations in the Differential Manchester code. Differential Manchester code is used to convert binary data into signal elements. These signal elements allow the receiver to derive clocking pulses from the encoded signal. Each bit of data consists of two signal elements of opposite polarity. This maintains the DC balance in each bit and guarantees a transition for clocking.

Data on the ring is encoded using Differential Manchester Encoding in which a half-bit clock signal is synchronized against a bit slot as follows:

* 0 is represented as a positive OR negative transition at the beginning of a bit slot.

* 1 is represented as NO transition at the beginning of a bit slot.

A transition should always occur in the middle of the bit slot because of the half bit clock. A code violation occurs when there is no transition about the midpoint, that is, when the elements on both sides of the midpoint of the data bit have the same polarity.

There are intentional code violations in Token Ring. In the Starting Delimiter or Ending Delimiter of a frame (token, data, or void), the non-data JK bits are used to signal the start and end of the frame.

These JK bits are intentional code violations. The Token Ring Internet Advisor LAN does not count these bits as code violations.

The Token Ring Internet Advisor LAN has custom hardware that monitors the Token Ring and can report on many error conditions that a standard NIC card can not. One of those errors is a code violation. A standard NIC card would see a code violation (especially SD and ED), but unless the code violation causes another type of error (bad FCS), then the NIC would not report the problem. The Internet Advisor LAN will report all code violations as an early warning system to the network manager/engineer.

Code Violations in limited numbers may be acceptable on your Token Ring, especially if data frames are not being corrupted. They may or may not cause serious problems. Code Violations in significant numbers may cause other serious problems on your network. If frames are being corrupted because of code violations then you will note a higher number of frames with Bad FCS, Frames Lost (code violation in Source Address), soft errors, corrupted tokens, etc. Code Violations may cause Ring Purges too.

If your Token Ring has many code violations and you also note that there are errors as noted above, then it is time to fix your network.

Application response times will be adversely affected, and timeouts may occur. Any time frames are lost or received with a bad FCS, the transport protocol will be responsible for retransmitting the original data, causing delays and additional user data on the network. If many tokens are being corrupted, then the Active Monitor will perform Ring Purges to clear the ring and send a new token. All frames on the network at that time will be lost and the application and transport protocols will retransmit the original data.

Code Violations are non-isolating errors. That means there is no way to identify the fault domain automatically. To find the cause of the code violations requires that you segment your network, possibly a MAU at a time, until the code violations are no longer present. Once the fault domain has been determined at that level then further analysis can be done to determine exactly which node or lobe wire is responsible for the code violations.

Aborts is a count of all the abort delimiters transmitted on the network in order to abort frames.

This is a count of all tokens. A token is a unique symbol sequence that is circulated around the ring following a data transmission. Once a station acquires the token, it removes the token from the ring and begins transmitting data. At the end of its transmission, the station issues a new token onto the ring to provide the other stations with the opportunity to transmit.

If there are very few tokens, there is most likely some other serious problem. For example, there may be wiring problems.

Receiver Congestion is a count of the soft errors with the non-isolating receiver congestion error count incremented. A station transmits this soft error when it is receiving/repeating a frame and recognizes a frame addressed to it, but has no buffer space available for the frame.

Some suggestions for isolating a congested station receiver are:

* Analyze the nature of the traffic destined for the station.

* Determine if the station is configured properly.

* Compare the actual traffic level with the manufacturer's recommended limits for the station's network interface card.

If recommended traffic levels are being exceeded, then explore balancing the traffic or upgrading the network interface card.

Burst Errors is a count of the soft errors with the isolating burst error count incremented. This counter is incremented when a station detects the absence of transitions for 5 half-bit times (burst-five error). The first ring station to detect a burst-four condition (4 half-bit times without transitions) transmits idles on the fifth half-bit time.

The station sending the burst errors can be determined by running the Token-Ring Network Commentator measurement and noting the station that is listed in any Soft Error Warning events which have a Burst Isolating Error.

Check that the connections are good and that the ring length is not exceeded.

Line errors is a count of the soft errors with the isolating line error count incremented. This counter is incremented when a frame or token is repeated by a station, the error-detected bit of the ending delimiter is set to 0, or the station detects either a code violation or frame check sequence (FCS) error.

The station sending the line errors can be determined by running the Token-Ring Network Commentator measurement and noting the station that is listed in any Soft Error Warning events which have a Line Isolating Error. Inspect the cabling and interface cards for possible damage near and around the indicated station.

Soft Errors is a count of soft error MAC frames. Soft error MAC frames are transmitted by a station to the ring error monitor functional address when a soft error is detected and the soft error timer has expired.

* Line Errors - A Line Error occurs when a frame or token is repeated by the ring station, the Error Detect Indicator is zero, and the ring station detects:

A code violation between the starting delimiter and the ending delimiter of the frame or token

A Frame Check Sequence (FCS) error in a frame

* Internal Errors - An Internal Error occurs when a station recognizes a Recoverable Internal Error. This can indicate a ring station in marginal operating condition.

* Burst Errors- A Burst Error occurs when a ring station detects the absence of transitions for 5 half-bit times (burst-five error). The first ring station to detect a burst-four condition (4 half-bit times without transitions) transmits idles on the fifth half-bit time.

* A/C Errors- An A/C Error occurs when a station receives an Active Monitor or Standby Monitor Present frame in which the Monitor bit in the Access field is zero, and then it receives a Standby Monitor Present frame in which the Monitor bit in the Access field is zero without first receiving an Active Monitor Present MAC frame.

* Abort Delimiters- An originating ring station can abort a frame that it is transmitting by sending an Abort Delimiter frame.

* Lost Frame Error- A Lost Frame Error occurs when a station is in transmit mode and it fails to receive the end of the frame. This can occur while stations are inserting and de- inserting.

* Receiver Congestion - The Receiver Congested Error occurs when a station is receiving/repeating a frame and it recognizes a frame addressed to it but it does has no buffer space available for the frame.

* Frame-Copied Error - A Frame Copied Error occurs when a station in the receive/repeat mode recognizes a frame addressed to its specific address but it finds the Address Recognized Bits not equal to 00. This can be caused by a duplicate address.

* Frequency Error - A Frequency Error occurs when there is a condition in which the ring clock and the crystal clock frequency of the adapter differ by an excessive amount.

* Token Error - A Token Error occurs when the Active Monitor recognizes an error resulting in the need to transmit a token. This occurs when the Active Monitor detects a lost frame, a lost token, a circulating frame, or a circulating token. A circulating frame or token is defined as a frame or token with a priority greater than zero that circulates past the Active Monitor twice.

Check that the connections to this station are good and also check that station's network interface card (NIC).

The Beacons value is a count of beacon MAC frames. A Beacon frame is used to isolate a serious ring failure such as a break in the ring. When a station attempts the claim-token process, it eventually times out if it does not come to a resolution. After timing out, the station issues a Beacon to all other stations on the same ring to begin the Beacon Process.

Temporary (intermittent) faults may be due to a broken wire, a station configured to the wrong line speed, or to loose or malfunctioning network interface cards or cables.

Permanent faults may be due to stuck MAU ports or to a broken path in the ring.

Claim Tokens is a count of claim token MAC frames. A Claim-Token frame is issued by a station that detects the loss of the Active Monitor. The Claim-Token frame is used to resolve contention among stations attempting to claim the status of Active Monitor.

Ring Purges is a count of ring purge MAC frames. Ring purge MAC frames are transmitted by the Active Monitor to all other stations on the same ring to clear the ring before the Active Monitor issues a new token. Ring purge MAC frames are also transmitted if a token error is detected. A token error is either a lost frame, or a circulation priority token.

The Ring Purge Process is the attempted resetting of the ring to Normal Repeat Mode. The Active Monitor initiates the Ring Purge Process for any of the following reasons:

* The Active Monitor detects an error condition on the ring, such as lost token or lost frames, or a disruption in the active timing between stations, or the improper execution of a ring process.

* The Active Monitor detects the M bit set to the 1 state in the Access Control field of a token or frame.

* The Active Monitor sees the T (Any-Token) timer expire.

* The Active Monitor sees the ring needs to be reset to Normal Repeat Mode.

TOP ERRORS REPORTERS

The Token-Ring Top Error Reporters measurement displays a list of up to 50 stations that have reported the most error frames since the measurement was started.

You can use the ARROW keys, the PAGE keys, and the HOME and END keys to scroll through the list. There is one line for each station which shows the following information:

* Station- This column shows either the hex MAC address, the station name, or the vendor name of each station, depending on the format selected in the Top Error Reporters Configuration window's Format menu.

* Total Errors - This column shows the total number of all types of error frames each station has sent since the measurement was started.

* Errors Detected- This column shows the types of error frames each station has sent. The possible errors are: Beacon- A beacon frame is used to isolate a serious ring failure such as a break in the ring. When a station attempts the claim-token procedure, it eventually times out if it does not come to a resolution. After timing out, the station issues a beacon to all other stations on the same ring to begin the Beacon Process.

Line Error- A line error occurs when a frame or token is repeated by the ring station, the Error Detect Indicator is zero, and the ring station detects:

- A code violation between the starting delimiter and the ending delimiter of the frame or token

- A Frame Check Sequence (FCS) error in a frame

Burst Error- A burst error occurs when a ring station detects the absence of transitions for 5 half-bit times (burst-five error). The first ring station to detect a burst-four condition (4 half-bit times without transitions) transmits idles on the fifth half-bit time.

Receiver Congestion Error- The Receiver Congested Error occurs when a station is receiving/repeating a frame and it recognizes a frame addressed to it but it does has no buffer space available for the frame.

Claim Error- A claim-token frame is issued by a station that detects the loss of the Active Monitor. The claim-token frame is used to resolve contention among stations attempting to claim the status of Active Monitor.

Frequency Error- A Frequency Error occurs when there is a condition in which the ring clock and the crystal clock frequency of the adapter differ by an excessive amount.

Lost Frame Error- A Lost Frame Error occurs when a station is in transmit mode and it fails to receive the end of the frame. This can occur while stations are inserting and de-inserting.

Ring Purge- The Active Monitor transmits a Ring Purge frame to clear the ring before issuing a new token.

Internal Error- An internal error occurs when a station recognizes a recoverable internal error. This can indicate a ring station in marginal operating condition.

A/C Error- An A/C error occurs when a station receives an Active Monitor or Standby Monitor Present frame in which the Monitor bit in the Access field is zero, and then it receives a Standby Monitor Present frame in which the Monitor bit in the Access field is zero

without first receiving an Active Monitor Present MAC frame.

Abort Delimiter- An originating ring station can abort a frame that it is transmitting by sending an Abort Delimiter frame.

Frame Copied Error- A Frame Copied Error occurs when a station in the receive/repeat mode recognizes a frame addressed to its specific address but it finds the Address Recognized Bits not equal to 00. This can be caused by a duplicate address.

Token Error- A Token Error occurs when the Active Monitor recognizes an error resulting in the need to transmit a token. This occurs when the Active Monitor detects a lost frame, a lost token, a circulating frame, or a circulating token. A circulating frame or token is defined as a frame or token with a priority greater than zero that circulates past the Active Monitor twice.

One way to use the Token-Ring Top Error Reporters measurement is in combination with a capture filter. For example, you can modify the Basic Token-Ring filter by opening the Basic Token- Ring Capture Filter window and putting in a router's MAC address in the 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 Token-Ring Top Error Reporters measurement. This will then show you how many errors and what type of errors this router is sending.

Another measurement you can run is the Token-Ring Station Stats measurement. This measurement shows the error information shown in the Token-Ring Top Error Reporters measurement, the information shown in the Token-Ring Top Talkers measurement, plus additional information such as the number of Source Routed Broadcasts and the number of Source Routed Frames, among other things. It also has advanced features like pie charts and bar charts, and it can log its results to disk.

NOVELL VITAL SIGNS

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.

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.

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.

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.

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 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

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.