CPQNIC-MIB: View SNMP OID List / Download MIB

The Major Revision level of the MIB. A change in the major revision level represents a major change in the architecture of the MIB. A change in the major revision level may indicate a significant change in the information supported and/or the meaning of the supported information. Correct interpretation of data may require a MIB document with the same major revision level.

The Minor Revision level of the MIB. A change in the minor revision level may represent some minor additional support, no changes to any pre-existing information has occurred.

The overall condition. This object represents the overall status of the system represented by this MIB. Enumeration: 'unknown': 1, 'degraded': 3, 'ok': 2, 'failed': 4.

The Insight Agent's polling frequency. The frequency, in seconds, at which the Insight Agent requests information from the device driver. A frequency of zero (0) indicates that the Insight Agent retrieves the information upon request of a management station, it does not poll the device driver at a specific interval. If the poll frequency is zero (0) all attempts to write to this object will fail. If the poll frequency is non-zero, setting this value will change the polling frequency of the Insight Agent. Setting the poll frequency to zero (0) will always fail. An agent may choose to fail any request to change the poll frequency to a value that would severely impact system performance.

A table of software modules that provide an interface to the device this MIB describes.

A description of a software module that provides an interface to the device this MIB describes.

A unique index for this module description.

The module name.

The module version in XX.YY format. Where XX is the major version number and YY is the minor version number. This field will be null (size 0) string if the agent cannot provide the module version.

The module date. field octets contents range ===== ====== ======= ===== 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minute 0..59 6 7 second 0..60 (use 60 for leap-second) This field will be set to year = 0 if the agent cannot provide the module date. The hour, minute, and second field will be set to zero (0) if they are not relevant. The year field is set with the most significant octet first.

The purpose of the module described in this entry.

A table of interface to logical hardware mappings.

A mapping of an interface table entry to logical hardware.

An index that uniquely specifies this entry.

An OCTET STRING representing an array of MIB II Interface Numbers implemented by this logical adapter. Each entry is a 32-bit value, represented by 4 octets in LSB...MSB (Little-Endian) order. There may be 0 or more Interface Numbers on a particular logical adapter, depending on the operating system's assignment of Interface Numbers. There is an interface number field in the cpqNicIfPhysAdapterTable which may contain one or more interface numbers. For logical adapters with one Physical Adapter, the same Interface Number(s) may appear in both tables.

Description of the logical adapter. This string is NULL terminated.

The type of Fault Tolerance supplied by this logical adapter. The following types of Fault Tolerance are supported: unknown(1) Indicates that the instrument agent does not recognize the controller. You may need to upgrade the instrument agent. none(2) Indicates the logical adapter is not fault tolerant. There is a single physical adapter associated with the logical adapter. redundantPair(3) Indicates that the logical adapter has two adapters associated with it. One adapter is active and the other adapter is a hot standby. No longer used. nft(4) Network Fault Tolerance. The logical adapter has two or more adapters associated with it. One adapter is active on the network and the other(s) are hot standby(s). alb(5) Adaptive Load Balancing. Indicates that the logical adapter has more than one physical adapter associated with it. One adapter transmits and receives, while the others only transmit. If the receiving adapter fails, one of the other adapters assumes this role. No longer used. fec(6) Fast EtherChannel. This allows all physical adapters associated with the logical adapter to both receive and transmit. This requires a switch that cooperates with the adapters. If any adapter fails, the load is spread among the remaining adapters. No longer used. gec(7) Gigabit EtherChannel. This allows all physical adapters associated with the logical adapter to both receive and transmit. This requires a gigabit switch that cooperates with the adapters. If any adapter fails, the load is spread among the remaining adapters. No longer used. ad(8) IEEE802.3ad Link Aggregation. This allows all physical adapters associated with the logical adapter to both receive and transmit. This requires a switch that cooperates with the adapters. If any adapter fails, the load is spread among the remaining adapters. No longer used. slb(9) Switch-assisted load balancing. This allows all physical adapters associated with the logical adapter to both receive and transmit. This requires a switch that cooperates with the adapters. If any adapter fails, the load is spread among the remaining adapters. Aggregates fec, gec, and ad. tlb(10) Transmit Load Balancing. Indicates that the logical adapter has more than one physical adapter associated with it. One adapter transmits and receives, while the others only transmit. If the receiving adapter fails, one of the other adapters assumes this role. Formerly alb. redundancySet(11) Indicates that the logical adapter has more than one adapter associated with it. This value is used when the type of the team could not be determined. Enumeration: 'none': 2, 'fec': 6, 'unknown': 1, 'alb': 5, 'redundancySet': 11, 'gec': 7, 'tlb': 10, 'nft': 4, 'redundantPair': 3, 'slb': 9, 'ad': 8.

The number of physical adapters associated with this logical adapter.

The number of physical adapters associated with this logical adapter that have an OK condition.

An array of octets corresponding to the indices in the cpqNicIfPhysAdapterTable of the physical adapters associated with this logical adapter. The number of octets is equal to cpqNicIfLogMapAdapterCount.

The MAC (physical) address that the logical adapter presents to the network.

The algorithm used to determine when to switch network traffic from one adapter to another. The following algorithms are supported: unknown(1) Indicates that the instrument agent does not recognize the controller. You may need to upgrade the instrument agent. none(2) Indicates the logical adapter is not fault tolerant. There is a single physical adapter associated with the logical adapter. manual(3) Indicates that the logical adapter has more than one physical adapter associated with it. In order to switch from the active adapter to a standby adapter, user action is required. switchOnFail(4) Indicates that the logical adapter has more than one physical adapter associated with it. If a failure of the active adapter is detected, network traffic will automatically switch to a standby adapter. The standby adapter will remain active until some action (manual switch, system restart) restores the primary adapter to active. preferredPrimary(5) Indicates that the logical adapter has more than one physical adapter associated with it. If a failure of the active adapter is detected, network traffic will automatically switch to a standby adapter. If the original primary adapter recovers from the failure, it will automatically become active again. auto(6) Indicates that the logical adapter is not in manual failover mode. preferenceOrder(7) Indicates that the logical adapter has more than one physical adapter associated with it. When a failure of the active adapter is detected, network traffic automatically switchs to one standby adapter. The relative priority of adapters are used to select the new primary adapter. Enumeration: 'none': 2, 'unknown': 1, 'preferenceOrder': 7, 'manual': 3, 'switchOnFail': 4, 'preferredPrimary': 5, 'auto': 6.

The condition of this interface. This value represents the overall condition of the logical adapter group. This value is driven by the cpqNicIfLogMapStatus object as follows: other(1) Indicates that the value of the Logical Map Status is unknown(1). ok(2) Indicates that the value of the Logical Map Status is ok(2). degraded(3) Indicates that the value of the Logical Map Status is either primaryFailed(3) or standbyFailed(4). The Logical adapter still functions in this state, but performance and redundancy are degraded. failed(4) Indicates that the value of the Logical Map Status is groupFailed(5). This indicates that all the adapters in the logical group have failed and no network traffic is occurring. Enumeration: 'failed': 4, 'degraded': 3, 'other': 1, 'ok': 2.

The status of the logical group. The following values are valid for the logical group status: unknown(1) The instrument agent may not support this value. You may need to load a new instrument agent. ok(2) The adapter group is functioning properly. primaryFailed(3) The adapter specified as primary in the group has failed. the group is still functioning and one of the standby adapters has assumed the role of primary. Depending on the number of adapters in the group, redundancy may be lost. standbyFailed(4) An adapter specified as standby or secondary in the group has failed. the group is still functioning and one of the standby adapters has assumed the role of primary. Depending on the number of adapters in the group, redundancy may be lost. groupFailed(5) All adapters in the group have failed. Network connectivity has been lost for the group. This status will be returned for logical groups with a single physical adapter that has failed. redundancyReduced(6) Atleast one adapter in the team has failed but there are more than one adapter available. redundancyLost(7) Only one adapter in the team is functioning properly. If this adapter fails, the team will go to failed status. Enumeration: 'ok': 2, 'primaryFailed': 3, 'unknown': 1, 'groupFailed': 5, 'standbyFailed': 4, 'redundancyReduced': 6, 'redundancyLost': 7.

The number of times a fault tolerant switchover has occurred. Switchovers occur because the primary adapter fails.

A text description of the hardware location, on complex multi SBB hardware only, for the adapters. A NULL string indicates that the hardware location could not be determined or is irrelevant.

An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth.

The number of VLANs associated with this logical adapter.

An array of octets corresponding to the indices in the cpqNicIfVlanMapTable of the VLANs associated with this logical adapter. The number of octets is equal to cpqNicIfLogMapVlanCount.

The time the underlying link associated with this interface changed its status from either link up to link down or link down to link up.

This bitmap indicates the advanced features being used by the logical adapter (team). cpqNicIfLogMapAdvancedTeaming AND 1 is 1, Active Path Failover is enabled. cpqNicIfLogMapAdvancedTeaming AND 2 is 2, Fast Path Failover is enabled. cpqNicIfLogMapAdvancedTeaming AND 4 is 4, Static dual channel is enabled. cpqNicIfLogMapAdvancedTeaming AND 8 is 8, Dynamic dual channel is enabled. cpqNicIfLogMapAdvancedTeaming AND 16 is 16, Router Path Failover is enabled.

An estimate of the interface's current bandwidth in Megabits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth.

The CIDR(Classless Inter-Domain Routing) notation that the logical adapter presents to the network.

Local Area Connection number that the logical adapter presents to the network.

The overall condition of all interfaces. This object is the worst case of any individual interface. For example, if there is one degraded interface, this variable will have a value of degraded(3). If there is one failed interface, this variable will have a value of failed(4). Enumeration: 'failed': 4, 'degraded': 3, 'other': 1, 'ok': 2.

A table of physical adapters.

A physical adapter table entry.

An index that uniquely specifies this entry.

An OCTET STRING representing an array of MIB II Interface Numbers implemented by this physical adapter. Each entry is a 32-bit value, represented by 4 octets in LSB...MSB (Little-Endian) order. There may be 0 or more Interface Numbers on a particular physical adapter, depending on the operating system's assignment of Interface Numbers. There is also an Interface Number field in the cpqNicIfLogMapTable which may contain one or more Interface Numbers. For logical adapters with one Physical Adapter, the same Interface Number(s) appear in both tables.

The role this physical adapter has in the logical group. The following values are valid: unknown(1) The role of the adapter could not be determined. This indicates a problem with the instrument agent. A new agent may need to be installed. primary(2) The adapter is the primary adapter in the group, or the group consists of a single adapter. The primary adapter in a Single Pair or NFT group handles all the network traffic unless it fails. The primary adapter in an ALB group receives all traffic. The physical address of this adapter is the default address of the group. In a FEC group, an arbitrary adapter is designated as primary, but all adapters are equal and participate fully on the network. secondary(3) In Single Pair and NFT groups, this adapter functions as a hot standby. No network traffic is handled by this adapter other than periodic test packets. In an ALB group, this adapter is in a secondary role and transmits packets to increase bandwidth. In an FEC group, this adapter participates fully in network traffic. member(4) The adapter is a member of a Switch Assisted Load Balancing Team. The adapter participates fully in network traffic. TxRx(5) The adapter can transmit and receive. Tx(6) The adapter can only transmit. standby(7) The adapter does not transmit or receive. It can go to TxRx or Tx when required. none(8) The adapter is not in use. notApplicable(255) The physical adapter is not a member of any group. Enumeration: 'none': 8, 'txRx': 5, 'tx': 6, 'standby': 7, 'unknown': 1, 'primary': 2, 'member': 4, 'notApplicable': 255, 'secondary': 3.

The physical (MAC) address of the adapter. In some configurations this may be a null length octet string.

The number of the slot containing the physical hardware that implements this interface. The number zero (0) indicates an embedded interface (on the system board). A value of -1 indicates an interface whose slot is unknown. Values may be unknown if the physical hardware has not been configured using the System Configuration Utility.

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 this information is unavailable.

The number of the IRQ (interrupt) used for this physical hardware interface. The number zero (0) indicates that this device does not use an IRQ or this information is unavailable.

The number of the DMA channel used for this physical hardware interface. The number -1 indicates that this device does not use a DMA channel or this information is unavailable.

The base memory address used by this physical hardware interface. The number zero (0) indicates that this device does not use system memory or this information is unavailable.

The port number of the interface for multi-port NICs. A port number of -1 indicates that the port could not be determined.

This variable describes the current duplex state of the adapter. A value of unknown indicates that the duplex state could not be determined. Enumeration: 'unknown': 1, 'full': 3, 'half': 2.

The condition of this physical adapter. This value is driven by the cpqNicIfPhysAdapterStatus object as follows: other(1) Indicates that the value of the Physical Adapter Status is unknown(1). ok(2) Indicates that the value of the Physical Adapter Status is ok(2). degraded(3) Defined for all condition variables, but is not applicable for single adapters. failed(4) Indicates that the value of the Physical Adapter Status is linkFailure(4). Enumeration: 'failed': 4, 'degraded': 3, 'other': 1, 'ok': 2.

The fault tolerant state of this adapter. Although this value is valid for adapters that are not part of a fault tolerant group, it only provides additional information when the adapter participates in a group. The following values are valid: unknown(1) The fault tolerant state could not be determined. The instrument agent may need to be upgraded. active(2) The adapter is actively participating in the network. This state is displayed for adapters that are not part of a fault tolerant group and for adapters in a fault tolerant group that are not in the standby state. standby(3) The adapter is ready to assume network activity in case of a failure of the active adapter. failed(4) The adapter has failed and cannot participate on the network. Enumeration: 'active': 2, 'unknown': 1, 'standby': 3, 'failed': 4.

The physical adapter status. The following values are valid: unknown(1) The instrument agent was not able to determine the status of the adapter. The instrument agent may need to be upgraded. ok(2) The physical adapter is operating properly. generalFailure(3) The physical adapter has failed. linkFailure(4) The physical adapter has lost link. Check the cable connections to this adapter. Enumeration: 'generalFailure': 3, 'unknown': 1, 'ok': 2, 'linkFailure': 4.

This value indicates whether the following statistics in the table are accurate. Some adapters may not be able to report the statistics accurately, and the statistics should not be reported for these adapters. The following values are valid: true(1) The statistics are accurate. false(2) The statistics are not accurate and should not be used. Enumeration: 'false': 2, 'true': 1.

A count of frames successfully transmitted by the physical adapter.

A count of frames successfully received by the physical adapter.

A count of frames that were not transmitted by the adapter because of an error. This counter is the sum of MIB items cpqNicIfPhysAdapterDeferredTransmissions cpqNicIfPhysAdapterLateCollisions, cpqNicIfPhysAdapterExcessiveCollisions, cpqNicIfPhysAdapterCarrierSenseErrors, and cpqNicIfPhysAdapterInternalMacTransmitErrors. If this counter increments frequently, check the more detailed error statistics and take appropriate action.

A count of frames that were received by the adapter but which had an error. This counter is the sum of mib items cpqNicIfPhysAdapterAlignmentErrors, cpqNicIfPhysAdapterFCSErrors, cpqNicIfPhysAdapterFrameTooLongs, and cpqNicIfPhysAdapterInternalMacReceiveErrors. If this counter increments frequently, check the more detailed error statistics and take appropriate action.

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 check. The alignment of a frame is checked by the receiver after the packet has failed the Cyclical Redundancy Check (CRC). Misaligned packets do not end on an 8-bit boundary. All packets contain a set number of bytes and must end after a defined number of bytes. Packets that do not end on a byte boundary fail the alignment check. Faulty components may be the cause of alignment errors. 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.

A count of frames received on a particular interface that are an integral number of octets in length but do not pass the FCS check. Faulty components may be the cause of FCS errors. 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.

The number of single collision packets: This counter contains the number of packets that are involved in a single collision and are subsequently transmitted successfully. These errors show that the network has light to moderate traffic. If single collisions become more frequent, the count for multiple collisions escalates.

The number of multiple collision packets: This counter contains the number of packets that are involved in multiple collisions and are subsequently transmitted successfully. These errors mean that the network is experiencing moderate to heavy traffic. If multiple collisions become more frequent, the count for excessive collisions escalates.

The number of packets deferred before transmission: This counter contains the number of packets whose transmission was delayed on its first attempt because the medium was busy. Packets involved in any collisions are not counted. Frames that wait before transmission are counted. This statistic will be incremented often during normal operation on a busy network. Deferred transmissions occur when the network is extremely busy; so busy that the NIC did not try to transmit. High counts of multiple collisions and excessive collisions also occur. Deferred transmissions indicate that this segment of the LAN is overcrowded. Reduce the traffic by reorganizing the LAN. For example, if you have 100 stations on one Ethernet bus, break it into two Ethernet segments by adding a NIC to your server. In this way you can balance the load by putting 50 stations on one segment and 50 on the other. If a few isolated stations create the traffic, put them on a separate segment.

Late collisions may be a symptom of cabling problems. A late collision is one that occurred 64 bytes or more into the packet. Late collisions may be an indication that a segment is longer than allowed by the wiring specifications. A station will believe it has control of the cable segment if it has already transmitted 64 bytes. If another node at the far end of the segment has not yet seen the packet, and transmits, this packet will collide with the first transmission after the first 64 bytes have been sent. Ensure that your segment length does not exceed the maximum length allowed. Because the location of cabling problems can be very difficult to detect on an Ethernet network, you may want to 'shorten' an Ethernet segment (remove portions of the network to isolate problems) until the problems are no longer seen, and then expand the network until the problem recurs. If this counter increments quickly in a short period of time, it may mean that the network card is running in half duplex mode, but your hub or switch port is configured for full duplex mode. Compare your network card's configuration with the port's configuration. Late collisions are also included in other collision-related statistics.

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.

A count of frames for which transmission on a particular interface fails due to an internal MAC sublayer transmit error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of either the cpqNicIfPhysAdapterLateCollisions object, the cpqNicIfPhysAdapterExcessiveCollisions object, or the cpqNicIfPhysAdapterCarrierSenseErrors object. The precise meaning of the count represented by an instance of this object is implementation- specific. In particular, an instance of this object may represent a count of transmission errors on a particular interface that are not otherwise counted.

The number of packets transmitted with carrier sense errors: This counter contains the number of times that the carrier sense signal from the physical layer interface was not asserted or was de-asserted during transmission of a packet without collision. The carrier sense signal is an ongoing activity of a data station to detect whether or not another station is transmitting. Carrier sense errors are detected when a station transmits a frame and does not detect its own signal on the wire. If you receive carrier sense errors, check the following: Failing cable: Packet data traveling through shorted or damaged cabling may cause a signal loss. Ensure that your cable is working and plugged in properly. Segment not grounded properly: Improper grounding of a segment may allow ground-induced noise to interrupt the signal. Ensure that you have properly grounded all segments. Noisy cable: Interference or noise produced by motors or other devices can interrupt the signals. Deaf/partially deaf node: A faulty station that cannot hear the activity is considered a deaf node. If you suspect a deaf node, the network interface card should be replaced. Failing hub, switch, or controller: Repeaters, switches and controllers can disrupt the network signal, transmit erroneous signals on the wire, or ignore incoming packets. Perform the following steps: 1. Swap out the adapter, adapter cable, and adapter attachment point, one at a time. If you find a faulty component, replace it. 2. If none of the items listed above help you isolate the problem, you may need to replace the switch or hub. Use a network analyzer to isolate the problem area.

A count of frames received on a particular interface that exceed the maximum permitted frame size.

A count of frames for which reception on a particular interface fails due to an internal MAC sublayer receive error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of either the cpqNicIfPhysAdapterStatsFrameTooLongs object, the cpqNicIfPhysAdapterStatsAlignmentErrors object, or the cpqNicIfPhysAdapterStatsFCSErrors object. The precise meaning of the count represented by an instance of this object is implementation- specific. In particular, an instance of this object may represent a count of receive errors on a particular interface that are not otherwise counted.

A text description of the hardware location, on complex multi SBB hardware only, for the physical adapter. A NULL string indicates that the hardware location could not be determined or is irrelevant.

A text description of the hardware part number.

An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth.

The physical adapter configured speed and duplex. The following values are valid: other(1) The configured speed and duplex are unknown. autoAuto(2) Auto negotiate both speed and duplex. ethernetHalf(3), ethernetFull(4), fastEthernetHalf(5), fastEthernetFull(6), gigEthernetHalf(7), gigEthernetFull(8), gig10EthernetFull(9) Speed and duplex forced to the given value. Enumeration: 'autoAuto': 2, 'gigEthernetFull': 8, 'fastEthernetHalf': 5, 'gigEthernetHalf': 7, 'fastEthernetFull': 6, 'other': 1, 'ethernetFull': 4, 'gig10EthernetFull': 9, 'ethernetHalf': 3.

Aggregation group number of the adapter. A value of -1 means the Aggregation group number could not be determined or not present.

An estimate of the interface's current bandwidth in Megabits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth.

A count of Octets Received on the physical adapter. This includes traffic generated due to different protocols like TCP/IP, DECNET etc

A count of Octets Sent on the physical adapter. This includes traffic generated due to different protocols like TCP/IP, DECNET etc

Name of the physical adapter. This string is NULL terminated.

Identifies the Interconnect Bay Number to which the adapter is connected in a Blade Environment. A value of -1 means the Interconnect Bay number could not be determined or its not a Blade Environment. cpqNicIfPhysAdapterSlot will reflect a Mezz number and cpqNicIfPhysAdapterPort will reflect Switch Port number when Interconnect Bay number is not -1.

Firmware version of the physical adapter. This string is NULL terminated.

A table of base memory used by a physical adapter.

A base memory table entry.

An index that uniquely specifies this entry.

An index ifTable. This identifies the physical adapter interface this Base memory address is associated with.

A base memory address used by the physical hardware interface associated.

A table of interface to VLAN mappings.

A mapping of an interface table entry to VLANs.

An index that uniquely specifies this entry.

An index into the logical map table. This identifies the logical adapter this VLAN is associated with.

An index ifTable. This identifies the MIB-II interface this VLAN is associated with.

The ID of this VLAN.

The name of this VLAN.

The CIDR(Classless Inter-Domain Routing) notation that the VLAN presents to the network.

Local Area Connection number that the VLAN presents to the network.

Indicates installation status of Virus Throttle Filter Driver Enumeration: 'notInstalled': 1, 'installed': 2.

Indicates license status of Virus Throttle Filter Driver Enumeration: 'licensed': 2, 'notLicensed': 1.

Indicates virus activity detection status of Virus Throttle Filter Driver Enumeration: 'detected': 2, 'notDetected': 1.

This trap will be sent any time connectivity is restored to a logical adapter. This occurs when the physical adapter in a single adapter configuration returns to the OK condition or at least one physical adapter in a logical adapter group returns to the OK condition. This can be caused by replacement of a faulty cable or re-attaching a cable that was unplugged. User Action: None required.

This trap will be sent any time the status of a logical adapter changes to the Failed condition. This occurs when the adapter in a single adapter configuration fails, or when the last adapter in a redundant configuration fails. This can be caused by loss of link due to a cable being removed from the adapter or the Hub or Switch. Internal adapter, Hub, or Switch failures can also cause this condition. User Action: Check the cables to the adapter and the Hub or Switch. If no cable problems are found, the adapter, Hub, or Switch may need replacement.

This trap will be sent any time a previously failed physical adapter in a connected logical adapter group returns to the OK condition. This trap is not sent when a logical adapter group has connectivity restored from a Failed condition. The cpqNicConnectivityRestored trap is sent instead. This can be caused by replacement of a faulty cable or re-attaching a cable that was unplugged. User Action: None required.

This trap will be sent any time a physical adapter in a logical adapter group changes to the Failed condition, but at least one physical adapter remains in the OK condition.. This can be caused by loss of link due to a cable being removed from the adapter or the Hub or Switch. Internal adapter, Hub, or Switch failures can also cause this condition. User Action: Check the cables to the adapter and the Hub or Switch. If no cable problems are found, the adapter, Hub, or Switch may need replacement.

This trap will be sent any time connectivity is restored to a logical adapter. This occurs when the physical adapter in a single adapter configuration returns to the OK condition or at least one physical adapter in a logical adapter group returns to the OK condition. This can be caused by replacement of a faulty cable or re-attaching a cable that was unplugged. User Action: None required.

This trap will be sent any time the status of a logical adapter changes to the Failed condition. This occurs when the adapter in a single adapter configuration fails, or when the last adapter in a redundant configuration fails. This can be caused by loss of link due to a cable being removed from the adapter or the Hub or Switch. Internal adapter, Hub, or Switch failures can also cause this condition. User Action: Check the cables to the adapter and the Hub or Switch. If no cable problems are found, the adapter, Hub, or Switch may need replacement.

This trap will be sent any time a previously failed physical adapter in a connected logical adapter group returns to the OK condition. This trap is not sent when a logical adapter group has connectivity restored from a Failed condition. The cpqNicConnectivityRestored trap is sent instead. This can be caused by replacement of a faulty cable or re-attaching a cable that was unplugged. User Action: None required.

This trap will be sent any time a physical adapter in a logical adapter group changes to the Failed condition, but at least one physical adapter remains in the OK condition.. This can be caused by loss of link due to a cable being removed from the adapter or the Hub or Switch. Internal adapter, Hub, or Switch failures can also cause this condition. User Action: Check the cables to the adapter and the Hub or Switch. If no cable problems are found, the adapter, Hub, or Switch may need replacement.

This trap will be sent when the Virus Throttle Filter Driver detects virus like activity. User Action: The system reporting this trap requires immediate attention.

This trap will be sent when the Virus Throttle Filter Driver no longer detects virus like activity. User Action: None required.

This trap will be sent any time connectivity is restored to a logical adapter. This occurs when the physical adapter in a single adapter configuration returns to the OK condition or at least one physical adapter in a logical adapter group returns to the OK condition. This can be caused by replacement of a faulty cable or re-attaching a cable that was unplugged. User Action: None required.

This trap will be sent any time the status of a logical adapter changes to the Failed condition. This occurs when the adapter in a single adapter configuration fails, or when the last adapter in a redundant configuration fails. This can be caused by loss of link due to a cable being removed from the adapter or the Hub or Switch. Internal adapter, Hub, or Switch failures can also cause this condition. User Action: Check the cables to the adapter and the Hub or Switch. If no cable problems are found, the adapter, Hub, or Switch may need replacement.

This trap will be sent any time a previously failed physical adapter in a connected logical adapter group returns to the OK condition. This trap is not sent when a logical adapter group has connectivity restored from a Failed condition. The cpqNicConnectivityRestored trap is sent instead. This can be caused by replacement of a faulty cable or re-attaching a cable that was unplugged. User Action: None required.

This trap will be sent any time a physical adapter in a logical adapter group changes to the Failed condition, but at least one physical adapter remains in the OK condition.. This can be caused by loss of link due to a cable being removed from the adapter or the Hub or Switch. Internal adapter, Hub, or Switch failures can also cause this condition. User Action: Check the cables to the adapter and the Hub or Switch. If no cable problems are found, the adapter, Hub, or Switch may need replacement.