The number of packets aborted during transmission
due to excessive collisions: This counter contains
the number of packets that, due to excessive
collisions, are not transmitted successfully.
A station may attempt to transmit up to 16 times
before it must abort the attempt. Once the abort
occurs, this counter increments.
If you see an increase in deferred transmissions
as well as excessive collisions, the network is
extremely busy and this segment of the LAN is
overcrowded. Reduce the traffic by reorganizing
your LAN or adding a NIC to the server. For example,
if you have 100 stations on one Ethernet bus, break
it into two Ethernet buses by adding a NIC to your
server. In this way you can balance the load by
putting 50 stations on one bus and 50 on the other.
If there are a few isolated stations creating the
traffic, try placing them on a separate bus.
Faulty components may be the cause of excessive
collisions. Check the following:
Segment too long: Nodes at the far end of the
cabling system transmit, unaware that a station
at the other end has already gained control of
the medium by transmitting the first 64 bytes
of a frame.
Failing cable: Packet data traveling through
shorted or damaged cabling may become corrupt
before reaching the destination station.
Segment not grounded properly: Improper grounding
of a segment may allow ground-induced noise to
corrupt data flow.
Improper termination: If a cable segment is not
properly terminated, allowing the signal to be
absorbed upon reaching the end of the segment,
a partial signal will bounce back and collide
with existing signals.
Noisy cable: Interference or noise produced by
motors or other devices can distort the signals
and cause CRC/Alignment errors.
Deaf/partially deaf node: A faulty station that
cannot hear the activity is considered a deaf node.
If you suspect a deaf node, replace the NIC.
Failing repeater, transceiver, or controller:
Repeaters, transceivers, and controllers can
disrupt the network signal, transmit erroneous
signals on the wire, or ignore incoming packets.
Perform the following steps:
1. If your NIC is continuously transmitting,
it causes erroneous signals, or 'jabber.'
Replace a jabbering transmitter to ensure
proper network performance.
2. Check your hub or switch. This component
may be at fault. Use the diagnostics from
the component manufacturer to help you
determine if a problem exists.
Parsed from file CPQNIC1.MIB.txt
Company: None
Module: CPQNIC-MIB
The number of packets aborted during transmission
due to excessive collisions: This counter contains
the number of packets that, due to excessive
collisions, are not transmitted successfully.
A station may attempt to transmit up to 16 times
before it must abort the attempt. Once the abort
occurs, this counter increments.
If you see an increase in deferred transmissions
as well as excessive collisions, the network is
extremely busy and this segment of the LAN is
overcrowded. Reduce the traffic by reorganizing
your LAN or adding a NIC to the server. For example,
if you have 100 stations on one Ethernet bus, break
it into two Ethernet buses by adding a NIC to your
server. In this way you can balance the load by
putting 50 stations on one bus and 50 on the other.
If there are a few isolated stations creating the
traffic, try placing them on a separate bus.
Faulty components may be the cause of excessive
collisions. Check the following:
Segment too long: Nodes at the far end of the
cabling system transmit, unaware that a station
at the other end has already gained control of
the medium by transmitting the first 64 bytes
of a frame.
Failing cable: Packet data traveling through
shorted or damaged cabling may become corrupt
before reaching the destination station.
Segment not grounded properly: Improper grounding
of a segment may allow ground-induced noise to
corrupt data flow.
Improper termination: If a cable segment is not
properly terminated, allowing the signal to be
absorbed upon reaching the end of the segment,
a partial signal will bounce back and collide
with existing signals.
Noisy cable: Interference or noise produced by
motors or other devices can distort the signals
and cause CRC/Alignment errors.
Deaf/partially deaf node: A faulty station that
cannot hear the activity is considered a deaf node.
If you suspect a deaf node, replace the NIC.
Failing repeater, transceiver, or controller:
Repeaters, transceivers, and controllers can
disrupt the network signal, transmit erroneous
signals on the wire, or ignore incoming packets.
Perform the following steps:
1. If your NIC is continuously transmitting,
it causes erroneous signals, or 'jabber.'
Replace a jabbering transmitter to ensure
proper network performance.
2. Check your hub or switch. This component
may be at fault. Use the diagnostics from
the component manufacturer to help you
determine if a problem exists.
Parsed from file CPQNIC-MIB.mib
Module: CPQNIC-MIB
cpqNicIfPhysAdapterExcessiveCollisions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets aborted during transmission due to excessive collisions: This counter contains the number of packets that, due to excessive collisions, are not transmitted successfully. A station may attempt to transmit up to 16 times before it must abort the attempt. Once the abort occurs, this counter increments. If you see an increase in deferred transmissions as well as excessive collisions, the network is extremely busy and this segment of the LAN is overcrowded. Reduce the traffic by reorganizing your LAN or adding a NIC to the server. For example, if you have 100 stations on one Ethernet bus, break it into two Ethernet buses by adding a NIC to your server. In this way you can balance the load by putting 50 stations on one bus and 50 on the other. If there are a few isolated stations creating the traffic, try placing them on a separate bus. Faulty components may be the cause of excessive collisions. Check the following: Segment too long: Nodes at the far end of the cabling system transmit, unaware that a station at the other end has already gained control of the medium by transmitting the first 64 bytes of a frame. Failing cable: Packet data traveling through shorted or damaged cabling may become corrupt before reaching the destination station. Segment not grounded properly: Improper grounding of a segment may allow ground-induced noise to corrupt data flow. Improper termination: If a cable segment is not properly terminated, allowing the signal to be absorbed upon reaching the end of the segment, a partial signal will bounce back and collide with existing signals. Noisy cable: Interference or noise produced by motors or other devices can distort the signals and cause CRC/Alignment errors. Deaf/partially deaf node: A faulty station that cannot hear the activity is considered a deaf node. If you suspect a deaf node, replace the NIC. Failing repeater, transceiver, or controller: Repeaters, transceivers, and controllers can disrupt the network signal, transmit erroneous signals on the wire, or ignore incoming packets. Perform the following steps: 1. If your NIC is continuously transmitting, it causes erroneous signals, or 'jabber.' Replace a jabbering transmitter to ensure proper network performance. 2. Check your hub or switch. This component may be at fault. Use the diagnostics from the component manufacturer to help you determine if a problem exists." ::= { cpqNicIfPhysAdapterEntry 26 }
Vendor: Compaq
Module: CPQNIC-MIB
[Automatically extracted from oidview.com]
cpqNicIfPhysAdapterExcessiveCollisions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets aborted during transmission due to excessive collisions: This counter contains the number of packets that, due to excessive collisions, are not transmitted successfully. A station may attempt to transmit up to 16 times before it must abort the attempt. Once the abort occurs, this counter increments. If you see an increase in deferred transmissions as well as excessive collisions, the network is extremely busy and this segment of the LAN is overcrowded. Reduce the traffic by reorganizing your LAN or adding a NIC to the server. For example, if you have 100 stations on one Ethernet bus, break it into two Ethernet buses by adding a NIC to your server. In this way you can balance the load by putting 50 stations on one bus and 50 on the other. If there are a few isolated stations creating the traffic, try placing them on a separate bus. Faulty components may be the cause of excessive collisions. Check the following: Segment too long: Nodes at the far end of the cabling system transmit, unaware that a station at the other end has already gained control of the medium by transmitting the first 64 bytes of a frame. Failing cable: Packet data traveling through shorted or damaged cabling may become corrupt before reaching the destination station. Segment not grounded properly: Improper grounding of a segment may allow ground-induced noise to corrupt data flow. Improper termination: If a cable segment is not properly terminated, allowing the signal to be absorbed upon reaching the end of the segment, a partial signal will bounce back and collide with existing signals. Noisy cable: Interference or noise produced by motors or other devices can distort the signals and cause CRC/Alignment errors. Deaf/partially deaf node: A faulty station that cannot hear the activity is considered a deaf node. If you suspect a deaf node, replace the NIC. Failing repeater, transceiver, or controller: Repeaters, transceivers, and controllers can disrupt the network signal, transmit erroneous signals on the wire, or ignore incoming packets. Perform the following steps: 1. If your NIC is continuously transmitting, it causes erroneous signals, or 'jabber.' Replace a jabbering transmitter to ensure proper network performance. 2. Check your hub or switch. This component may be at fault. Use the diagnostics from the component manufacturer to help you determine if a problem exists." ::= { cpqNicIfPhysAdapterEntry 26 }
OID | Name | Sub children | Sub Nodes Total | Description |
---|---|---|---|---|
1.3.6.1.4.1.232.18.2.3.1.1.1 | cpqNicIfPhysAdapterIndex | 0 | 0 | An index that uniquely specifies this entry. |
1.3.6.1.4.1.232.18.2.3.1.1.2 | cpqNicIfPhysAdapterIfNumber | 0 | 0 | An OCTET STRING representing an array of MIB II Interface Numbers implemented by this physical adapter. Each entry is a 32-bit va… |
1.3.6.1.4.1.232.18.2.3.1.1.3 | cpqNicIfPhysAdapterRole | 0 | 0 | The role this physical adapter has in the logical group. The following values are valid: unknown(1) The role of the adapter could … |
1.3.6.1.4.1.232.18.2.3.1.1.4 | cpqNicIfPhysAdapterMACAddress | 0 | 0 | The physical (MAC) address of the adapter. In some configurations this may be a null length octet string. |
1.3.6.1.4.1.232.18.2.3.1.1.5 | cpqNicIfPhysAdapterSlot | 0 | 0 | The number of the slot containing the physical hardware that implements this interface. The number zero (0) indicates an embedde… |
1.3.6.1.4.1.232.18.2.3.1.1.6 | cpqNicIfPhysAdapterIoAddr | 0 | 0 | The base I/O address of the physical adapter. The number zero (0) indicates that the device does not use I/O mapped addresses or… |
1.3.6.1.4.1.232.18.2.3.1.1.7 | cpqNicIfPhysAdapterIrq | 0 | 0 | The number of the IRQ (interrupt) used for this physical hardware interface. The number zero (0) indicates that this device does… |
1.3.6.1.4.1.232.18.2.3.1.1.8 | cpqNicIfPhysAdapterDma | 0 | 0 | The number of the DMA channel used for this physical hardware interface. The number -1 indicates that this device does not use a… |
1.3.6.1.4.1.232.18.2.3.1.1.9 | cpqNicIfPhysAdapterMemAddr | 0 | 0 | The base memory address used by this physical hardware interface. The number zero (0) indicates that this device does not use sy… |
1.3.6.1.4.1.232.18.2.3.1.1.10 | cpqNicIfPhysAdapterPort | 0 | 0 | The port number of the interface for multi-port NICs. A port number of -1 indicates that the port could not be determined. |
1.3.6.1.4.1.232.18.2.3.1.1.11 | cpqNicIfPhysAdapterDuplexState | 0 | 0 | This variable describes the current duplex state of the adapter. A value of unknown indicates that the duplex state could not be… |
1.3.6.1.4.1.232.18.2.3.1.1.12 | cpqNicIfPhysAdapterCondition | 0 | 0 | The condition of this physical adapter. This value is driven by the cpqNicIfPhysAdapterStatus object as follows: other(1) Indicates… |
1.3.6.1.4.1.232.18.2.3.1.1.13 | cpqNicIfPhysAdapterState | 0 | 0 | The fault tolerant state of this adapter. Although this value is valid for adapters that are not part of a fault tolerant group,… |
1.3.6.1.4.1.232.18.2.3.1.1.14 | cpqNicIfPhysAdapterStatus | 0 | 0 | The physical adapter status. The following values are valid: unknown(1) The instrument agent was not able to determine the status o… |
1.3.6.1.4.1.232.18.2.3.1.1.15 | cpqNicIfPhysAdapterStatsValid | 0 | 0 | This value indicates whether the following statistics in the table are accurate. Some adapters may not be able to report the sta… |
1.3.6.1.4.1.232.18.2.3.1.1.16 | cpqNicIfPhysAdapterGoodTransmits | 0 | 0 | A count of frames successfully transmitted by the physical adapter. |
1.3.6.1.4.1.232.18.2.3.1.1.17 | cpqNicIfPhysAdapterGoodReceives | 0 | 0 | A count of frames successfully received by the physical adapter. |
1.3.6.1.4.1.232.18.2.3.1.1.18 | cpqNicIfPhysAdapterBadTransmits | 0 | 0 | A count of frames that were not transmitted by the adapter because of an error. This counter is the sum of MIB items cpqNicIfPhy… |
1.3.6.1.4.1.232.18.2.3.1.1.19 | cpqNicIfPhysAdapterBadReceives | 0 | 0 | A count of frames that were received by the adapter but which had an error. This counter is the sum of mib items cpqNicIfPhysAda… |
1.3.6.1.4.1.232.18.2.3.1.1.20 | cpqNicIfPhysAdapterAlignmentErrors | 0 | 0 | A count of frames received on a particular interface that are not an integral number of octets in length and do not pass the FCS … |
1.3.6.1.4.1.232.18.2.3.1.1.21 | cpqNicIfPhysAdapterFCSErrors | 0 | 0 | A count of frames received on a particular interface that are an integral number of octets in length but do not pass the FCS chec… |
1.3.6.1.4.1.232.18.2.3.1.1.22 | cpqNicIfPhysAdapterSingleCollisionFrames | 0 | 0 | The number of single collision packets: This counter contains the number of packets that are involved in a single collision and ar… |
1.3.6.1.4.1.232.18.2.3.1.1.23 | cpqNicIfPhysAdapterMultipleCollisionFrames | 0 | 0 | The number of multiple collision packets: This counter contains the number of packets that are involved in multiple collisions an… |
1.3.6.1.4.1.232.18.2.3.1.1.24 | cpqNicIfPhysAdapterDeferredTransmissions | 0 | 0 | The number of packets deferred before transmission: This counter contains the number of packets whose transmission was delayed on… |
1.3.6.1.4.1.232.18.2.3.1.1.25 | cpqNicIfPhysAdapterLateCollisions | 0 | 0 | Late collisions may be a symptom of cabling problems. A late collision is one that occurred 64 bytes or more into the packet. Lat… |
1.3.6.1.4.1.232.18.2.3.1.1.27 | cpqNicIfPhysAdapterInternalMacTransmitErrors | 0 | 0 | A count of frames for which transmission on a particular interface fails due to an internal MAC sublayer transmit error. A frame … |
1.3.6.1.4.1.232.18.2.3.1.1.28 | cpqNicIfPhysAdapterCarrierSenseErrors | 0 | 0 | The number of packets transmitted with carrier sense errors: This counter contains the number of times that the carrier sense si… |
1.3.6.1.4.1.232.18.2.3.1.1.29 | cpqNicIfPhysAdapterFrameTooLongs | 0 | 0 | A count of frames received on a particular interface that exceed the maximum permitted frame size. |
1.3.6.1.4.1.232.18.2.3.1.1.30 | cpqNicIfPhysAdapterInternalMacReceiveErrors | 0 | 0 | A count of frames for which reception on a particular interface fails due to an internal MAC sublayer receive error. A frame is o… |
1.3.6.1.4.1.232.18.2.3.1.1.31 | cpqNicIfPhysAdapterHwLocation | 0 | 0 | A text description of the hardware location, on complex multi SBB hardware only, for the physical adapter. A NULL string indicate… |
1.3.6.1.4.1.232.18.2.3.1.1.32 | cpqNicIfPhysAdapterPartNumber | 0 | 0 | A text description of the hardware part number. |
1.3.6.1.4.1.232.18.2.3.1.1.33 | cpqNicIfPhysAdapterSpeed | 0 | 0 | An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those … |
1.3.6.1.4.1.232.18.2.3.1.1.34 | cpqNicIfPhysAdapterConfSpeedDuplex | 0 | 0 | The physical adapter configured speed and duplex. The following values are valid: other(1) The configured speed and duplex are unk… |
1.3.6.1.4.1.232.18.2.3.1.1.35 | cpqNicIfPhysAdapterAggregationGID | 0 | 0 | Aggregation group number of the adapter. A value of -1 means the Aggregation group number could not be determined or not present. |
1.3.6.1.4.1.232.18.2.3.1.1.36 | cpqNicIfPhysAdapterSpeedMbps | 0 | 0 | An estimate of the interface's current bandwidth in Megabits per second. For interfaces which do not vary in bandwidth or for th… |
1.3.6.1.4.1.232.18.2.3.1.1.37 | cpqNicIfPhysAdapterInOctets | 0 | 0 | A count of Octets Received on the physical adapter. This includes traffic generated due to different protocols like TCP/IP, DECNE… |
1.3.6.1.4.1.232.18.2.3.1.1.38 | cpqNicIfPhysAdapterOutOctets | 0 | 0 | A count of Octets Sent on the physical adapter. This includes traffic generated due to different protocols like TCP/IP, DECNET etc |
1.3.6.1.4.1.232.18.2.3.1.1.39 | cpqNicIfPhysAdapterName | 0 | 0 | Name of the physical adapter. This string is NULL terminated. |
1.3.6.1.4.1.232.18.2.3.1.1.40 | cpqNicIfPhysAdapterIoBayNo | 0 | 0 | Identifies the Interconnect Bay Number to which the adapter is connected in a Blade Environment. A value of -1 means the Interco… |
1.3.6.1.4.1.232.18.2.3.1.1.41 | cpqNicIfPhysAdapterFWVersion | 0 | 0 | Firmware version of the physical adapter. This string is NULL terminated. |
1.3.6.1.4.1.232.18.2.3.1.1.42 | cpqNicIfPhysAdapterVirtualPortNumber | 0 | 0 | Identifies the virtual port number of a partioned adapter . A value of -1 means the virtual port number could not be determined … |