Automation

On-Box Storage: Option 3 - Utility MIB as a Data Store

By Elevate posted 08-11-2015 22:18

  

Part 4 of 6 of On-Box Storage

 

Previous Article: On-Box Storage: Option 2 - JUNOS Device Configuration as a Data Store

Next Article: On-Box Storage: Option 4 - JUNOS Accounting Files as a Data Store

 

For SLAX version 1.0 and higher, Junos OS provides the capability to store number and string data in a database and expose it as SNMP data using the Junos OS Utility MIB. This data is available from Junos OS to any authorized IP device as SNMP object Identifiers (OIDs). A common use of the Utility MIB is to provide SNMP instrumentation for system characteristics, counters, or gauges that are NOT otherwise exposed via SNMP. For example, you can write a script to collect or derive a non-SNMP value and then write it to the Utility MIB, where it then becomes readable to authorized SNMP-capable applications.


The Utility MIB can also be used as a “scratch pad” area where scripts can store data (such as, counter values), that can be referenced at a later time -- even after the script has exited.

 

Pros

 

  • Easy to use.
  • Data is available locally as well as remotely to any SNMP-capable applications.
  • Since any data put into the Utility MIB is available for other on-box SNMP access, it’s also possible to apply JUNOS RMON alarm expressions against any custom counter or gauge data written to the Utility MIB.

Cons

 

  • Removing data from the Utility MIB should be done carefully. Nothing stops you from removing any other application’s data from the Utility MIB, if you have access to the RPCs.
  • Each Routing Engine maintains its own Utility MIB; there is no synchronization or mirroring between them. If you need your data to be replicated or synchronized on the other Routing Engine, then it’s incumbent on your script to provide that.
  • Data written to the Utility MIB will not survive a routing engine restart. Each time snmpd restarts, all data stored in the Utility MIB is deleted.  (So more specifically: your data will not survive an snmpd process restart.)

Gotchas

 

The Utility MIB is just a set of tables – one for each basic data type: Counter32, Counter64, Integer, Unit, and String. Your application just adds or removes rows to these tables. It does NOT enable you to create “real” OID hierarchies.

 

(If the terminology in the previous 2 sentences is a little confusing, then you probably don’t need to care about this; it’s an SNMP thing.)

 

The names that the Utility MIB creates for the values you add are not necessarily “human-friendly”. The resulting OID names are derived by taking a string value for the name you choose (such as, “foo”), then converting it into a dotted decimal sequence of each of the characters in the name. So OID name for the 64-bit counter jnxUtilCounter64Value.”foo” would really be specified externally as this OID:jnxUtilCounter64Value.102.111.111 -- where the trailing 3 values (102.111.111)  represent the decimal ASCII code values for the characters “f”, ”o”, “o”.

 

And actually, it’s a little more complicated. Any external SNMP applications that wish to collect SNMP data from your Utility MIB-based data store must use that ASCII decimal code translation to reference “jnxUtilCounter64Value.”foo” as a fully qualified OID in their SNMP PDU to JUNOS.  

 

In other words, the full-qualified OID for JUNIPER-UTIL-MIB::jnxUtilCounter64Value.”foo”
will have to be rendered as .1.3.6.1.4.1.2636.3.47.1.1.2.1.2.102.111.111 by the SNMP manager.

 

However, if you never need to expose your Utility MIB data to an off-box SNMP manager, then the “ugly OID syndrome” becomes a non-issue.

 

Written by Douglas McPherson

Solutions Consultant at Juniper


#ExpertAdvice
#How-To
0 comments
0 views

Permalink