CM-SA-MIB :: esaProbeHistoryY1731P2RNegLossOccurrences

MIB Reference — IPNetwork Monitor · Updated September 14, 2026

All MIBsCM-SA-MIBesaProbeHistoryY1731P2RNegLossOccurrences

esaProbeHistoryY1731P2RNegLossOccurrences

Module: CM-SA-MIB

OID (symbolic): CM-SA-MIB::esaProbeHistoryY1731P2RNegLossOccurrences

OID (numeric): 1.3.6.1.4.1.2544.1.12.8.1.8.1.54

Node type: OBJECT-TYPE

Type: PerfCounter64

Access: read-only

Description: This attribute is only applicable to Y.1731 probes. This is the number of occurences of negative frame loss from Source MEP (Probe) to Destination MEP (Reflector). If these counts are non-zero then there could be some kind of provisioning mismatch between the Probe MEP and Reflector MEP. Here are some scenarios this can happen: - Probe MEP is configured to count in-profile frames only and the Reflector MEP is configured to count all frames with a mismatch in value for the attribute cfmMepLmCountInProfileFrames. - Probe MEP is configured to count data frames for specific VLAN priority and the Reflector MEP is configured to count data frames for all the priorities with a mismatch in values for the attributes cfmMepLmTxCountAllPrios or cfmMepLmRxCountAllPrios. NOTE: This could possibly happen due to reasons not related to configuration such as frame reordering in the network.

What is esaProbeHistoryY1731P2RNegLossOccurrences?

esaProbeHistoryY1731P2RNegLossOccurrences is a 64-bit performance counter, applicable only to Y.1731 probes, counting negative frame-loss occurrences from the probe to the reflector, for a completed interval that has already closed and been archived into the rolling history log. A non-zero count here is a configuration red flag rather than a plain performance number: it means the probe's MEP and the reflector's MEP are not counting frames the same way, for example one side filtering to in-profile frames while the other counts everything. For example, finding this counter non-zero across every archived bin since a MEP was reconfigured months ago tells a technician the mismatch has been silently invalidating loss data ever since, not just in the most recent reading.

Examples

Walk all instances (SNMPv2c):

snmpwalk -v2c -c public <target> 1.3.6.1.4.1.2544.1.12.8.1.8.1.54
snmpwalk -v2c -c public <target> CM-SA-MIB::esaProbeHistoryY1731P2RNegLossOccurrences

Get a specific instance (index 1):

snmpget -v2c -c public <target> 1.3.6.1.4.1.2544.1.12.8.1.8.1.54.1
snmpget -v2c -c public <target> CM-SA-MIB::esaProbeHistoryY1731P2RNegLossOccurrences.1

Start monitoring ADVA/Ceragon FSP150 CM/CC (F3) microwave & Carrier Ethernet transport platform with a free 30-day trial of IPNetwork Monitor. Create custom SNMP monitor using the CM-SA-MIB::esaProbeHistoryY1731P2RNegLossOccurrences OID value, configure state conditions and alerts, and monitor any ADVA/Ceragon FSP150 CM/CC (F3) microwave & Carrier Ethernet transport platform from a single console.

OID Breakdown

Upper-level ancestors (9 from the standard OID tree / other modules)
Numeric OIDNameModule
1isoLANART-AGENT
1.3orgAirPair-MIB
1.3.6dodAirPair-MIB
1.3.6.1internetAirPair-MIB
1.3.6.1.4privateAirPair-MIB
1.3.6.1.4.1enterprisesAirPair-MIB
1.3.6.1.4.1.2544advaMIBADVA-MIB
1.3.6.1.4.1.2544.1productsADVA-MIB
1.3.6.1.4.1.2544.1.12fsp150cmADVA-MIB
Numeric OIDNameModule
1.3.6.1.4.1.2544.1.12.8cmServiceAssuranceMIBCM-SA-MIB
1.3.6.1.4.1.2544.1.12.8.1cmServAssuranceObjectsCM-SA-MIB
1.3.6.1.4.1.2544.1.12.8.1.8esaProbeHistoryTableCM-SA-MIB
1.3.6.1.4.1.2544.1.12.8.1.8.1esaProbeHistoryEntryCM-SA-MIB
1.3.6.1.4.1.2544.1.12.8.1.8.1.54esaProbeHistoryY1731P2RNegLossOccurrencesCM-SA-MIB