ZXR10-CFM-MIB: View SNMP OID List / Download MIB

Connectivity Fault Management module for managing IEEE 802.1ag

A MEP has a persistent defect condition. A notification (fault alarm) is sent to the management entity with the OID of the MEP that has detected the fault. Whenever a MEP has a persistent defect, it may or may not generate a Fault Alarm to warn the system administrator of the problem, as controlled by the MEP Fault Notification Generator State Machine and associated Managed Objects. Only the highest-priority defect, as shown in Table 20-1, is reported in the Fault Alarm. If a defect with a higher priority is raised after a Fault Alarm has been issued, another Fault Alarm is issued. The management entity receiving the notification can identify the system from the network source address of the notification, and can identify the MEP reporting the defect by the indices in the OID of the dot1agCfmMepHighestPrDefect variable in the notification: dot1agCfmMdIndex - Also the index of the MEP's Maintenance Domain table entry (dot1agCfmMdTable). dot1agCfmMaIndex - Also an index (with the MD table index) of the MEP's Maintenance Association table entry (dot1agCfmMaTable). dot1agCfmSessionId - MEP Identifier and final index into the MEP table (dot1agCfmMepTable).

This object contains an unused value for dot1agCfmMdIndex in the dot1agCfmMdTable, or a zero to indicate that none exist.

The Maintenance Domain table. Each row in the table represents a different Maintenance Domain. A Maintenance Domain is described in 802.1ag (3.22) as the network or the part of the network for which faults in connectivity are to be managed. The boundary of a Maintenance Domain is defined by a set of DSAPs, each of which can become a point of connectivity to a service instance.

The Maintenance Domain table entry. This entry is not lost upon reboot. It is backed up by stable storage.

The index to the Maintenance Domain table. dot1agCfmMdTableNextIndex needs to be inspected to find an available index for row-creation. Referential integrity is required i.e. the index needs to be persistent upon a reboot or restart of a device. The index can never be reused for other Maintenance Domain. The index value should keep increasing up to the time that they wrap around. This is to facilitate access control based on OID.

The type (and thereby format) of the Maintenance Domain Name.

The Maintenance Domain name. The type/format of this object is determined by the value of the dot1agCfmMdNameType object. Each Maintenance Domain has unique name amongst all those used or available to a service provider or operator. It facilitates easy identification of administrative responsibility for each Maintenance Domain. Clause 3.24 defines a Maintenance Domain name as the identifier, unique over the domain for which CFM is to protect against accidental concatenation of Service Instances, of a particular Maintenance Domain.

The Maintenance Domain Level.

Enumerated value indicating whether the management entity can create MHFs (MIP Half Function) for this Maintenance Domain.

Enumerated value indicating what, if anything, is to be included in the Sender ID TLV (21.5.3) transmitted by MPs configured in this Maintenance Domain. Since, in this variable, there is no encompassing Maintenance Domain, the value sendIdDefer takes the meaning of sendIdChassisManage.

Value to be used as the index of the MA table entries for this Maintenance Domain when the management entity wants to create a new row in the MA table.

The status of the row. The writable columns in a row can not be changed if the row is active. All columns must have a valid value before a row can be activated.

The Maintenance Association table. Each row in the table represents an MA. An MA is a set of MEPs, each configured with a single service instance. Creation of a Service Instance establishes a connectionless association among the selected DSAPs. Configuring a Maintenance association End Point (MEP) at each of the DSAPs creates a Maintenance Association (MA) to monitor that connectionless connectivity. The MA is identified by a Short MA Name that is unique within the Maintenance Domain and chosen to facilitate easy identification of the Service Instance. Together, the Maintenance Domain Name and the Short MA Name form the Maintenance Association Identifier (MAID) that is carried in CFM Messages to identify incorrect connectivity among Service Instances. A small integer, the Maintenance association End Point Identifier (MEPID), identifies each MEP among those configured on a single MA (802.1ag clauses 3.17 and 18.2). This table uses two indices, first index is the index of the Maintenance Domain table. The writable objects in this table need to be persistent upon reboot or restart of a device.

The MA table entry.

Index of the MA table dot1agCfmMdMaTableNextIndex needs to be inspected to find an available index for row-creation.

The Primary VLAN ID with which the Maintenance Association is associated, or 0 if the MA is not attached to any VID. If the MA is associated with more than one VID, the dot1agCfmVlanTable lists them.

The type (and thereby format) of the Maintenance Association Name.

The Short Maintenance Association name. The type/format of this object is determined by the value of the dot1agCfmMaNameType object.

Indicates if the Management entity can create MHFs (MIP Half Function) for this MA.

Enumerated value indicating what, if anything, is to be included in the Sender ID TLV (21.5.3) transmitted by MPs configured in this MA.

Interval between CCM transmissions to be used by all MEPs in the MA.

The status of the row. The writable columns in a row can not be changed if the row is active. All columns must have a valid value before a row can be activated.

Fast or slow. If it is fast, do by hareware.

List of Vlan.

The known Vlan table entry.

VlanId

The status of the row. Read SNMPv2-TC (RFC1903) for an explanation of the possible values this object can take.

List of MEPIDs (in any bridge) that belong to the same MA. Clause 12.14.6.1.3 specifies that a list of MEPIDs in all bridges in that MA, but since SNMP SMI does not allow to state in a MIB that an object in a table is an array, the information has to be stored in another table with two indices, being the first index, the index of the table that contains the list or array.

The known MEPS table entry.

MEPID

The status of the row. Read SNMPv2-TC (RFC1903) for an explanation of the possible values this object can take.

The Maintenance Association End Point (MEP) table. Each row in the table represents a different MEP. A MEP is an actively managed CFM entity, associated with a specific DSAP of a Service Instance, which can generate and receive CFM PDUs and track any responses. It is an end point of a single Maintenance Association, and is an endpoint of a separate Maintenance Entity for each of the other MEPs in the same Maintenance Association (802.1ag clause 3.18). This table uses three indices. The first two indices are the indices of the Maintenance Domain and MA tables, the reason being that a MEP is always related to an MA and Maintenance Domain. The Transmit Loopback table. Entries in this table are created/removed at the same time than entries in the MEP table are created/removed. The MEP table also stores all the managed objects for sending LBM and LTM. *LBM Managed objects LBM Managed objects in the MEP table enables the management entity to initiate transmission of Loopback messages. It will signal the MEP that it should transmit some number of Loopback messages and detect the detection (or lack thereof) of the corresponding Loopback messages. Steps to use entries in this table: 1) Wait for dot1agCfmMepTransmitLbmStatus value to be 'ready'. To do this do this sequence: a. an SNMP GET for both SnmpSetSerialNo and dot1agCfmMepTransmitLbmStatus objects (in same SNMP PDU). b. Check if value for dot1agCfmMepTransmitLbmStatus is 'ready' - if not, wait x seconds, go to step a above. - if yes, save the value of SnmpSetSerialNo and go to step 2) below 2) Change dot1agCfmMepTransmitLbmStatus value from 'ready' to 'notReady' to ensure no other management entity will use the service. In order to not disturb a possible other NMS do this by sending an SNMP SET for both SnmpSetSerialNo and dot1agCfmMepTransmitLbmStatus objects (in same SNMP PDU, and make sure SNmpSetSerialNo is the first varBind). For the SnmpSetSerialNo varBind, use the value that you obtained in step 1)a.. This ensures that two cooperating NMSes will not step on each others toes. 3) Setup the different data to be sent (number of messages, optional TLVs,...). 4) Record the current values of dot1agCfmMepLbrIn, dot1agCfmMepLbrInOutOfOrder, and dot1agCfmMepLbrBadMsdu. 6) Change dot1agCfmMepTransmitLbmStatus value from 'notReady' to 'transmit' to initiate transmission of Loopback messages. 7) Check the value of dot1agCfmMepTransmitLbmResultOK to find out if the operation was successfully initiated or not. 8) Monitor the value of dot1agCfmMepTransmitLbmMessages. When it reaches 0, the last LBM has been transmitted. Wait an additional 5 seconds to ensure that all LBRs have been returned. 9) Compare dot1agCfmMepLbrIn, dot1agCfmMepLbrInOutOfOrder, and dot1agCfmMepLbrBadMsdu to their old values from step 4, above, to get the results of the test. 10) Change the dot1agCfmMepTransmitLbmStatus value back to 'ready' to allow other management entities to use the table. *LTM Managed objects The LTM Managed objects in the MEP table are used in a manner similar to that described for LBM transmission, above. Upon successfully initiating the transmission, the variables dot1agCfmMepTransmitLtmSeqNumber and dot1agCfmMepTransmitLtmEgressIdentifier return the information required to recover the results of the LTM from the dot1agCfmLtrTable.

The MEP table entry

Integer that is unique among all the MEPs in the same MA. Other definition is: a small integer, unique over a given Maintenance Association, identifying a specific Maintenance association End Point (3.19). MEP Identifier is also known as the MEPID.

This object is the interface index of the interface either a bridge port, or an aggregated IEEE 802.1 link within a bridge port, to which the MEP is attached. Upon a restart of the system, the system SHALL, if necessary, change the value of this variable so that it indexes the entry in the interface table with the same value of ifAlias that it indexed before the system restart. If no such entry exists, then the system SHALL set this variable to 0.

The direction in which the MEP faces on the Bridge port.

An integer indicating the Primary VID of the MEP, always one of the VIDs assigned to the MEP's MA. The value 0 indicates that either the Primary VID is that of the MEP's MA, or that the MEP's MA is associated with no VID.

Administrative state of the MEP A Boolean indicating the administrative state of the MEP. True indicates that the MEP is to function normally, and false that it is to cease functioning.

Current state of the MEP Fault Notification Generator State Machine.

If set to true, the MEP will generate CCM messages.

The priority value for CCMs and LTMs transmitted by the MEP. Default Value in the highest priority value allowed to pass through the bridge port for any of this MEPs VIDs. The management entity can obtain the default value for this variable from the priority regeneration table by extracting the highest priority value in this table on this MEPs bridge port. (1 is lowest, then 2, then 0, then 3-7).

MAC address of the MEP.

An integer value specifying the lowest priority defect that is allowed to generate fault alarm.

The highest priority defect that has been present since the MEPs Fault Notification Generator State Machine was last in the FNG_RESET state.

A vector of Boolean error conditions from Table 20-1, any of which may be true: DefRDICCM(0) DefMACstatus(1) DefRemoteCCM(2) DefErrorCCM(3) DefXconCCM(4)

Total number of Continuity Check messages transmitted.

Session Id

MEP AttachType

Tunnel Id

LMFlage

DMFlage

Mep Port Name

Total number of valid, in-order Loopback Replies received.

The total number of valid, out-of-order Loopback Replies received.

(optional) The total number of LBRs received whose mac_service_data_unit did not match (except for the OpCode) that of the corresponding LBM (20.2.3).

Next transaction identifier/sequence number to be sent in a Linktrace message. This sequence number can be zero because it wraps around.

The total number of unexpected LTRs received (20.39.1).

Total number of Loopback Replies transmitted.

The status of the row. The writable columns in a row can not be changed if the row is active. All columns must have a valid value before a row can be activated.

This table extends the MEP table and contains a list of Linktrace replies received by a specific MEP in response to a linktrace message. SNMP SMI does not allow to state in a MIB that an object in a table is an array. The solution is to take the index (or indices) of the first table and add one or more indices.

The Linktrace Reply table entry.

Transaction identifier/Sequence number returned by a previous transmit linktrace message command, indicating which LTM's response is going to be returned.

trace route index.

TTL field value for a returned LTR.

Indicates if a LTM was forwarded by the responding MP, as returned in the 'FwdYes' flag of the flags field.

A boolean value stating whether the forwarded LTM reached a MEP enclosing its MA, as returned in the Terminal MEP flag of the Flags field.

An octet field holding the Last Egress Identifier returned in the LTR Egress Identifier TLV of the LTR. The Last Egress Identifier identifies the MEP Linktrace Initiator that originated, or the Linktrace Responder that forwarded, the LTM to which this LTR is the response. This is the same value as the Egress Identifier TLV of that LTM.

An octet field holding the Next Egress Identifier returned in the LTR Egress Identifier TLV of the LTR. The Next Egress Identifier Identifies the Linktrace Responder that transmitted this LTR, and can forward the LTM to the next hop. This is the same value as the Egress Identifier TLV of the forwarded LTM, if any. If the FwdYes bit of the Flags field is false, the contents of this field are undefined, i.e. any value can be transmitted, and the field is ignored by the receiver.

Value returned in the Relay Action field.

The value returned in the Ingress Action Field of the LTM.

MAC address returned in the ingress MAC address field.

The value returned in the Egress Action Field of the LTM.

MAC address returned in the egress MAC address field.

The MEP Database. A database, maintained by every MEP, that maintains received information about other MEPs in the Maintenance Domain. The SMI does not allow to state in a MIB that an object in a table is an array. The solution is to take the index (or indices) of the first table and add one or more indices.

The MEP Database table entry.

Maintenance association End Point Identifier of a remote MEP whose information from the MEP Database is to be returned.

The MAC address of the remote MEP.

State of the RDI bit in the last received CCM (true for RDI=1), or false if none has been received.

Session Id

MIP Table

The MIP table entry

Session Id

Mip Name

Mip Port Name