Skip to content

MIB Parsing Issues (v2.0.2)

Jump to bottom
Remington Campbell edited this page Jul 29, 2020 · 4 revisions

MIB parsing is not verified in TDM. It needs to be revisited with domain expertise.

OIDs missing.

The number one issue here is that there are OIDs missing from what is loaded in to TDM. This implies that our MIB parsing is to some degree incorrect. For instance, OSPF-MIB or ciscoFlashPartitionEntry.

Overlapping OIDs.

There are OIDs which appear to overlap each other which breaks the TDM schema tracking numeric OID as machine_id. e.g.

etl_1       | ERROR:root:Duplicate oid 1.3.6.1.4.1.351.110.6.2.6 from BASIS-RAS-DISK-MIB in CISCO-MGX82XX-DSX3-BERT-MIB!
etl_1       | ERROR:root:Duplicate oid 1.3.6.1.4.1.351.110.6.2.7 from BASIS-RAS-DISK-MIB in CISCO-MGX82XX-DSX3-BERT-MIB!
etl_1       | ERROR:root:Duplicate oid 1.3.6.1.4.1.351.110.6.2.8 from BASIS-RAS-DISK-MIB in CISCO-MGX82XX-DSX3-BERT-MIB!
etl_1       | ERROR:root:Duplicate oid 1.3.6.1.4.1.353 from ATM-SOFT-PVC-MIB in IMA-MIB!
etl_1       | ERROR:root:Duplicate oid 1.3.6.1.4.1.353.5 from ATM-SOFT-PVC-MIB in IMA-MIB!

These entire trees will likely not make it in to TDM as a result.

Uncertain pysmi usage.

The current SNMP ETL implementation uses pysmi to compile the MIBs to a JSON output. How this works isn't very well understood, and there are various overrides to ignore errors, etc. The outputs were never inspected for correctness. Now that gaps in what is present have been identified it is time to inspect the intermediary files which are emitted by the code, and determine if options are missing from how we parse using pysmi or if it is a more fundamental data issue with the MIBs themselves.

If this is not reconcilable we may need to attempt to source information from other tooling such as the Cisco SNMP Object Navigator, or another third-party MIB source (of which there are many).

Clone this wiki locally