Creating MIB Instrumentation

To convert a MIB module to a YANG module and add Server Instrumentation Library (SIL) code the following steps should be followed. The example below uses the IF-MIB. An example version of the IF-MIB SIL is provided with YumaPro SDK.

Convert the selected MIB module to a YANG module using the smidump tool from libsmi
```
> smidump -f yang --yang-smi-extensions IF-MIB > IF-MIB.yang
```

Validate the conversion using yangdump-pro.

> yangdump-pro IF-MIB > ~/yangdump_output.log

Copy the yang files into your work folder.
Run make_sil_dir_pro to generate the instrumentation source code.
```
make_sil_dir_pro IF-MIB
```
Modify the instrumentation code as needed. Look for the lines that say “insert xxx code”. The process of converting the MIB to YANG creates smi:oid "x.y.z" tags in the YANG module for leaf instrumentation. Only the leafs with the smi:oid tag will be seen from an SNMP client. See the following section “SNMP to YANG Mdmapping”
Compile the code:
```
> make DEBUG=1
```
Install the code:
```
> sudo make DEBUG=1 install
```
Note that "DEBUG=1" is optional and is used to enable debug logging.

This will install the generated library in the system path for netconfd-pro to load.

SNMP to YANG Mapping

Only YANG objects that have the smi:oid "x.y.z" tags will be visible for netconfd-pro SNMP engine. All other objects will be ignored, and the server will report that there is no such an object or will jump into the next object in case of 'snmpgetnext'.

YANG data model cannot be utilized in full if it needs to represent MIB module. After the MIB to YANG conversion the YANG module will have several limitations and some of the regular YANG features and properties will be either ignored by the netconfd-pro server or even invalid. The following list illustrates the limitations:

List or container may not have an OID number (smi:oid "x.y.z" tags), since they may not have analogy in the MIB modules;
The generic architecture for the YANG module must always be /container/list/leaf or /container/leaf in case of scalar objects. There should not be nested structures, nested architecture. Although, the netconfd-pro server is capable to handle the complex nested architecture, it is still not recommended;
Choice, case statements and their leaf nodes are ignored and will be invisible to netconfd-pro SNMP server;
If an object has a "deprecated" statement or the "status" is not current, e.g.: "obsolete", the object will be ignored;
Leafref, augment, uses, etc. are all allowed to be present in the converted YANG module but must be dealt with caution.

Note

The netconfd-pro SNMP server only fully supports YANG modules that were converted from MIB using the 'smidump' tool. Customized modules may not work properly.