RC-LINK-OAM-MIB: View SNMP OID List / Download MIB

A rcnLinkOamRemoteCriticalEventTrap is raised when received a critical event protocol packet from peer, cleared when the critical event indicator is no longer set in the received OAMPDU

A rcnLinkOamRemoteLoopbackActiveTrap is raised when remote port has been successfully put into remote loopback mode

A rcnLinkOamRemoteLoopbackFailureTrap is raised when the remote port cannot be put into remote loopback mode

A rcnLinkOamRemoteDiscoveryFailureTrap is raised to identify cases where the discovery protocol fails to execute successfully. Cleared by rcnLinkOamRemoteDiscoveryTrap

A rcnLinkOamRemoteLinkHeartbeatFailureTrap is raised when the peer heartbeat message is no longer being received. Cleared by rcnLinkOamRemoteDiscoveryTrap

A rcnLinkOamRemoteLoopbackTerminateSucceedTrap is raised when the remote loopback mode has been terminated successfully

A rcnLinkOamRemoteLoopbackTerminateFailureTrap is raised when the remote loopback mode has failed to be terminated

A rcnLinkOamRemoteDiscoveryTrap is raised when the peer is discovered. Clears rcnLinkOamRemoteDiscoveryFailureTrap and rcnLinkOamRemoteLinkHeartbeatFailureTrap

A rcnLinkOamRemoteDyingGaspTrap is raised when received a dying gasp protocol packet from peer (for example, the far-end line card has a power loss), cleared when dying gasp indicator is no longer set in the received OAMPDU

A rcnLinkOamRemoteLinkFaultTrap is raised raised when received a link fault protocol packet from peer, cleared when the link fault indicator is no longer set in the received OAMPDU

This table contains the primary controls and status for the OAM capabilities of an Ethernet-like interface. There will be one row in this table for each Ethernet-like interface in the system that supports the OAM functions defined in [802.3ah].

An entry in the table that contains information on the Ethernet OAM function for a single Ethernet like interface. Entries in the table are created automatically for each interface supporting Ethernet OAM. The status of the row entry can be determined from rcLinkOamOperStatus.

the port index on which the Link OAM is enabled. This value is similar to ifIndex in MIB2.

This object is used to provision the default administrative OAM mode for this port. This object represents the desired state of OAM for this port. The rcLinkOamAdminState always starts in the disabled(2) state until an explicit management action or configuration information retained by the system causes a transition to the enabled(1) state. When enabled(1), Ethernet OAM will attempt to operate over this port.

Used to create/delete entries

At initialization and failure conditions, two OAM entities on the same full-duplex Ethernet link begin a discovery phase to determine what OAM capabilities may be used on that link. The progress of this initialization is controlled by the OA sublayer. This value is always disabled(1) if OAM is disabled on this port via the rcLinkOamAdminState. If the link has detected a fault and is transmitting OAMPDUs with a link fault indication, the value is linkFault(2). Also, if the interface is not operational (ifOperStatus is not up(1)), linkFault(2) is returned. Note that the object ifOperStatus may not be up(1) as a result of link failure or administrative action (ifAdminState being down(2) or testing(3)). The passiveWait(3) state is returned only by OAM entities in passive mode (rcLinkOamMode) and reflects the state in which the OAM entity is waiting to see if the peer device is OA capable. The activeSendLocal(4) value is used by active mode devices (rcLinkOamMode) and reflects the OAM entity actively trying to discover whether the peer has OAM capability but has not yet made that determination. The state sendLocalAndRemote(5) reflects that the local OA entity has discovered the peer but has not yet accepted or rejected the configuration of the peer. The local device can, for whatever reason, decide that the peer device is unacceptable and decline OAM peering. If the local OAM entity rejects the peer OAM entity, the state becomes oamPeeringLocallyRejected(7). If the OAM peering is allowed by the local device, the state moves to sendLocalAndRemoteOk(6). Note that both the sendLocalAndRemote(5) and oamPeeringLocallyRejected(7) states fall within the state SEND_LOCAL_REMOTE of the Discovery state diagram [802.3ah, Figure 57-5], with the difference being whether the local OAM client has actively rejected the peering or has just not indicated any decision yet. Whether a peering decision has been made is indicated via the local flags field in the OAMPDU (reflected in the aOAMLocalFlagsField of 30.3.6.1.10). If the remote OAM entity rejects the peering, the state becomes oamPeeringRemotelyRejected(8). Note that both the sendLocalAndRemoteOk(6) and oamPeeringRemotelyRejected(8) states fall within the state SEND_LOCAL_REMOTE_OK of the Discovery state diagram [802.3ah, Figure 57-5], with the difference being whether the remote OAM client has rejected the peering or has just not yet decided. This is indicated via the remote flags field in the OAMPDU (reflected in the aOAMRemoteFlagsField of 30.3.6.1.11). When the local OAM entity learns that both it and the remote OAM entity have accepted the peering, the state moves to operational(9) corresponding to the SEND_ANY state of the Discovery state diagram [802.3ah, Figure 57-5]. Since Ethernet OAM functions are not designed to work completely over half-duplex interfaces, the value nonOperHalfDuplex(10) is returned whenever Ethernet OAM is enabled (dot3OamAdminState is enabled(1)), but the interface is in half-duplex operation.

This object configures the mode of OAM operation for this Ethernet-like interface. OAM on Ethernet interfaces may be in active mode or passive mode. These two modes differ in that active mode provides additional capabilities to initiate monitoring activities with the remote OAM peer entity, while passive mode generally waits for the peer to initiate OA actions with it. As an example, an active OAM entity can put the remote OAM entity in a loopback state, where a passive OA entity cannot. The default value of rcLink3OamMode is dependent on the type of system on which this Ethernet-like interface resides. The default value should be active(2) unless it is known that this system should take on a subservient role to the other device connected over this interface. Changing this value results in incrementing the configuration revision field of locally generated OAMPDUs and potentially re-doing the OAM discovery process if the rcLinkOamOperStatus was already operational(9).

The largest OAMPDU that the OAM entity supports. OA entities exchange maximum OAMPDU sizes and negotiate to use the smaller of the two maximum OAMPDU sizes between the peers. This value is determined by the local implementation.

The configuration revision of the OAM entity as reflected in the latest OAMPDU sent by the OAM entity. The config revision is used by OAM entities to indicate that configuration changes have occurred, which might require the peer OAM entity to re-evaluate whether OAM peering is allowed.

The OAM functions supported on this Ethernet-like interface. OAM consists of separate functional sets beyond the basic discovery process that is always required. These functional groups can be supported independently by any implementation. These values are communicated to the peer via the local configuration field of Information OAMPDUs. Setting unidirectionalSupport(0) indicates that the OA entity supports the transmission of OAMPDUs on links that are operating in unidirectional mode (traffic flowing in one direction only). Setting loopbackSupport(1) indicates that the OAM entity can initiate and respond to loopback commands. Setting eventSupport(2) indicates that the OAM entity can send and receive Event Notification OAMPDUs. Setting variableSupport(3) indicates that the OAM entity can send and receive Variable Request and Response OAMPDUs.

This table contains information about the OAM peer for a particular Ethernet-like interface. OAM entities communicate with a single OAM peer entity on Ethernet links on which OA is enabled and operating properly. There is one entry in this table for each entry in the rcLinkOamTable for which information on the peer OAM entity is available.

An entry in the table containing information on the peer OA entity for a single Ethernet-like interface. Note that there is at most one OAM peer for each Ethernet-like interface. Entries are automatically created when information about the OAM peer entity becomes available, and automatically deleted when the OAM peer entity is no longer in communication. Peer information is not available when rcLinkOamOperStatus is disabled(1), linkFault(2), passiveWait(3), activeSendLocal(4), or nonOperHalfDuplex(10).

the port index on which the Link OAM is enabled. This Value is similar to ifIndex in MIB2.

The MAC address of the peer OAM entity. The MAC address is derived from the most recently received OAMPDU.

The OUI of the OAM peer as reflected in the latest Information OAMPDU received with a Local Information TLV. The OUI can be used to identify the vendor of the remote OA entity. This value is initialized to three octets of zero before any Local Information TLV is received.

The Vendor Info of the OAM peer as reflected in the latest Information OAMPDU received with a Local Information TLV. The semantics of the Vendor Information field is proprietary and specific to the vendor (identified by the rcLinkOamPeerVendorOui). This information could, for example, be used to identify a specific product or product family. This value is initialized to zero before any Local Information TLV is received.

The mode of the OAM peer as reflected in the latest Information OAMPDU received with a Local Information TLV. The mode of the peer can be determined from the Configuration field in the Local Information TLV of the last Information OAMPDU received from the peer. The value is unknown(3) whenever no Local Information TLV has been received. The values of active(2) and passive(1) are returned when a Local Information TLV has been received indicating that the peer is in active or passive mode, respectively.

The maximum size of OAMPDU supported by the peer as reflected in the latest Information OAMPDU received with a Local Information TLV. Ethernet OAM on this interface must not use OAMPDUs that exceed this size. The maximum OAMPDU size can be determined from the PDU Configuration field of the Local Information TLV of the last Information OAMPDU received from the peer. A value of zero is returned if no Local Information TLV has been received. Otherwise, the value of the OAM peers maximum OAMPDU size is returned in this value.

The configuration revision of the OAM peer as reflected in the latest OAMPDU. This attribute is changed by the peer whenever it has a local configuration change for Ethernet OA on this interface. The configuration revision can be determined from the Revision field of the Local Information TLV of the most recently received Information OAMPDU with a Local Information TLV. A value of zero is returned if no Local Information TLV has been received.

The OAM functions supported on this Ethernet-like interface. OAM consists of separate functionality sets above the basic discovery process. This value indicates the capabilities of the peer OAM entity with respect to these functions. This value is initialized so all bits are clear. If unidirectionalSupport(0) is set, then the peer OAM entity supports sending OAM frames on Ethernet interfaces when the receive path is known to be inoperable. If loopbackSupport(1) is set, then the peer OAM entity can send and receive OAM loopback commands. If eventSupport(2) is set, then the peer OAM entity can send and receive event OAMPDUs to signal various error conditions. If variableSupport(3) is set, then the peer OAM entity can send and receive variable requests to monitor the attribute value as described in Clause 57 of [802.3ah]. The capabilities of the OAM peer can be determined from the configuration field of the Local Information TLV of the most recently received Information OAMPDU with a Local Information TLV. All zeros are returned if no Local Information TLV has yet been received.

This table contains controls for the loopback state of the local link as well as indicates the status of the loopback function. There is one entry in this table for each entry in rcLinkOamTable that supports loopback functionality (where rcLinkOamFunctionsSupported includes the loopbackSupport bit set). Loopback can be used to place the remote OAM entity in a state where every received frame (except OAMPDUs) is echoed back over the same interface on which they were received. In this state, at the remote entity, normal traffic is disabled as only the looped back frames are transmitted on the interface. Loopback is thus an intrusive operation that prohibits normal data flow and should be used accordingly.

An entry in the table, containing information on the loopback status for a single Ethernet-like interface. Entries in the table are automatically created whenever the local OAM entity supports loopback capabilities. The loopback status on the interface can be determined from the rcLinkOamLoopbackStatus object.

the port index on which the Link OAM is enabled. This Value is similar to ifIndex in MIB2.

The loopback status of the OAM entity. This status is determined by a combination of the local parser and multiplexer states, the remote parser and multiplexer states, as well as by the actions of the local OAM client. When operating in normal mode with no loopback in progress, the status reads noLoopback(1). The values initiatingLoopback(2) and terminatingLoopback(4) can be read or written. The other values can only be read - they can never be written. Writing initiatingLoopback causes the local OAM entity to start the loopback process with its peer. This value can only be written when the status is noLoopback(1). Writing the value initiatingLoopback(2) in any other state has no effect. When in remoteLoopback(3), writing terminatingLoopback(4) causes the local OAM entity to initiate the termination of the loopback state. Writing terminatingLoopack(4) in any other state has no effect. If the OAM client initiates a loopback and has sent a Loopback OAMPDU and is waiting for a response, where the local parser and multiplexer states are DISCARD (see [802.3ah, 57.2.11.1]), the status is initiatingLoopback. In this case, the local OAM entity has yet to receive any acknowledgment that the remote OAM entity has received its loopback command request. If the local OAM client knows that the remote OAM entity is in loopback mode (via the remote state information as described in [802.3ah, 57.2.11.1, 30.3.6.1.15]), the status is remoteLoopback(3). If the local OAM client is in the process of terminating the remote loopback [802.3ah, 57.2.11.3, 30.3.6.1.14] with its local multiplexer and parser states in DISCARD, the status is terminatingLoopback(4). If the remote OAM client has put the local OAM entity in loopback mode as indicated by its local parser state, the status is localLoopback(5). The unknown(6) status indicates that the parser and multiplexer combination is unexpected. This status may be returned if the OAM loopback is in a transition state but should not persist. The values of this attribute correspond to the following values of the local and remote parser and multiplexer states. value LclPrsr LclMux RmtPrsr RmtMux noLoopback FWD FWD FWD FWD initLoopback DISCARD DISCARD FWD FWD rmtLoopback DISCARD FWD LPBK DISCARD tmtngLoopback DISCARD DISCARD LPBK DISCARD lclLoopback LPBK DISCARD DISCARD FWD unknown *** any other combination ***

Since OAM loopback is a disruptive operation (user traffic does not pass), this attribute provides a mechanism to provide controls over whether received OAM loopback commands are processed or ignored. When the value is ignore(1), received loopback commands are ignored. When the value is process(2), OAM loopback commands are processed. The default value is to ignore loopback commands (ignore(1)).

The number of loopback messages to be transmitted.

An artitrary size of data to be included in the remote loopback PDU, if the frame size is selected to be sent.

Indicates the result of the operation: -true. The Loopback Message(s) will be (or have been) sent. -false. The Loopback Message(s) will not be sent.

Display the Loopback result.

State of the transmit loopback service: -ready. The service is available. -transmit. The service is transmitting, or about to transmit, the Loopback messages. -abort. The service is aborted, or about to abort the loopback message This column will also be used to avoid concurrency or race condition problems that could occur if two or more management entities try to use the service at the same time.

A count of the number of OAM frames received on this interface during the most recent remote loopback test

A count of the number of OAM frames transmitted on this interface during the most recent remote loopback test

This table contains statistics for the OAM function on a particular Ethernet-like interface. There is an entry in the table for every entry in the rcLinkOamTable. The counters in this table are defined as 32-bit entries to match the counter size as defined in [802.3ah]. Given that the OA protocol is a slow protocol, the counters increment at a slow rate.

An entry in the table containing statistics information on the Ethernet OAM function for a single Ethernet-like interface. Entries are automatically created for every entry in the rcLinkOamTable. Counters are maintained across transitions in rcLinkOamOperStatus.

the port index on which the Link OAM is enabled. This Value is similar to ifIndex in MIB2.

A count of the number of Information OAMPDUs transmitted on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime.

A count of the number of Information OAMPDUs received on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime.

A count of the number of Loopback Control OAMPDUs transmitted on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime.

A count of the number of Loopback Control OAMPDUs received on this interface. Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime.

Clear Link OAM Statistics

Link OAM indication signifies whether the trap is set or cleared