taking a look into ConfD User Guide, it seems that the rowStatus column for tables is always handled by the SNMP agent and should not be modeled in the YANG modules (rowStatus type is used for example in ALARM-MIB rfc3877). Does it mean that rowStatus is fully managed by ConfD?
Regarding the entryStatus type ( entryStatus is used for example in RMON-MIB rfc2819 ), is it handled by the SNMP agent? Nothing is mentioned on ConfD User guide.
The concept of RowStatus does not apply to ConfD CDB. It is handled by the ConfD SNMP agent only.
As the UG states, the RowStatus column in tables are handled by the SNMP agent and must not be part of the YANG model.
If an entry is in the database then its state is active only.
Regarding entryStatus, ConfD’s SNMP Agent only works with SMIv2 modules.
Whenever you depend on any of those old modules, it is because you are not working with MIBs written for SMIv2, and you are advised to move to newer versions of those MIBs instead.
Regarding RMON2-MIB, the MIB you want to implement is ALARM-MIB. This MIB
has this IMPORT:
So, in order to implement ALARM-MIB properly, you probably do not need the entire
RMON2-MIB; you just need the ZeroBasedCounter32 TEXTUAL-CONVENTION. The easiest way forward for you could be to put a “fake” minimal RMON2-MIB.mib file in place with only this TEXTUAL-CONVENTION in it.
Regarding the ALARM-MIB (rfc3877) was written to fulfil the need of mapping existing MIBS and Notifications (traps) to alarms. The assumption being that hosts exist, they already have MIBs but a management system does not know which notifications imply alarm, alarm clear or just events in general.
So the ALARM MIB is a mapping MIB, not a native MIB for a device.
At Tail-f we always recommend to follow standards, but for this specific MIB we do not recommend to implement it as the “native” ALARM MIB on the device, this was not intended. Read Section 2 in RFC3877.
So, can you consider implementing your own MIB for the alarms?
I’m interest to implement both RMON-MIB and ALARM-MIB.
ALARM-MIB will then be used to fulfil the need of mapping RMON-MIB to alarms.
One clear example of my needs is reported in RFC3877, section 6.5. RMON Alarm Example.
where alarmModelVarbindSubtree points to an alarmIndex, that is an entry in alarmTable defined in RMON-MIB.
Unfortunately alarmTable is an entryStatus table, not supported by ConfD’s SNMP Agent.
Hope it’s clearer now what I’m going to implement.
Do you have some hint?
Thank you very much
Update: probably one not so clear workaround could be to modify the RMON-MIB in order to accept rowStatus instead of entryStatus, but I’d like to figure out if there is another elegant solution, since this one force to modify the original RMON-MIB
I will provide a brief answer to your question, but please note that if you are interested in using ConfD Premium for your project, and want to evaluate ConfD Premium features such as SNMP, this forum is not the right forum for that. Please instead get in contact with your local Tail-f representative, or contact Tail-f through firstname.lastname@example.org.
In general you probably want to implement the latest version of any MIB. If you really wanted to implement RMON2, you may want to use the version from RFC4502.
So you can for example either update RMON2-MIB.mib to a version that uses SNMPv2-SMI instead of RFC1155-SMI, or patch the version of RMON2-MIB.mib that you have.
Thank you, I’ll get in contact with tail-f representative.
Just to conclude:
The first RMON MIB for Ethernet was issued as RFC 1271 in 1991. Later, this specification was superseded by RFC 1757 for SMIv1 and by RFC 2819 for SMIv2.
RFC 2819 extends RFC 1757 specification by documenting the RMON MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB.
RMON version 2 (RMON 2) is an extension to RMON version 1 (RMON 1), which refers to the initial RMON specifications monitoring on OSI Layer 2. RMON 2 focuses on the layers of traffic above the Media Access Control (MAC) layer; the main enhancement of RMON 2 is the capability to measure Layer 3 network traffic and application statistics.
I’m interest in RMON 1 since it includes only data link layer (Layer 2) details.
I’m not interest in RMON 2, since it offers network layer to application layer details (Layer 3 and up).
In the initial RMON MIB, the EntryStatus textual convention was introduced to provide table entry creation, validation, and deletion. This function then was added to the SNMP framework as the RowStatus textual convention (RFC 2579, Textual Conventions for SMIv2). The RowStatus textual convention is used to define all new tables. The old RMON 1 MIB (RFC 2819) uses EntryStatus, and the new RMON 2 MIB (RFC 4502) uses RowStatus.
Concluding, RFC 2819 for SMIv2 uses EntryStatus. RFC 4502 for SMIv2 uses rowStatus for the new defined tables in RMON2-MIB, but entryStatus for the tables imported from RMON-MIB.
… the RMON MIB aggregates its measurements to the link, hardware address, or hardware address pair - all data-link concepts.
In contrast, the RMON-2 MIB takes the same data-link metrics (packets, bytes, errors) and aggregates them based on network address, transport protocol, or application protocol.
The RMON-2 MIB [RFC2021] extends the architecture defined in RMON-1, primarily by extending RMON analysis up to the application layer.
In the RMON MIB [RFC2819], the EntryStatus textual convention was introduced to provide this mutual exclusion function. Since then, this function was added to the SNMP framework as the RowStatus textual convention. The RowStatus textual convention is used for the definition of all new tables.
True, this might not be your use case, but for example if the standard mib based manager only access the higher layer aggregated metrics that RMON2-MIB (RFC 4502) presents and do not access the RMON-MIB aggregated link-layer statistics directly you can replace EntryStatus with RowStatus in the RMON-MIB and create your own RMON-MIB without confusing the manager.