Snmp agent oid vs table name

agsun · February 13, 2020, 8:14pm

Hi Frank

I found an interesting behavior between walking using oid and tablename. We skipped the obsolete attributes when we auto-generate the mib class.
When we talk using oid of the table, it displays the attributes we put in value properly. However, when talking with mib table name, it tried to show the obsolete attributes and actual attributes that have data does not line up correctly. Hence, it resulted in invalid type. Is this an agent issue? How can we make the table walk work like oid?

Thanks

MIB Table
DocsQosServiceFlowEntry ::= SEQUENCE {
docsQosServiceFlowId Unsigned32,
docsQosServiceFlowProvisionedParamSetIndex Unsigned32, —obsolete
docsQosServiceFlowAdmittedParamSetIndex Unsigned32, —obsolete
docsQosServiceFlowActiveParamSetIndex Unsigned32, —obsolete docsQosServiceFlowSID Unsigned32,
docsQosServiceFlowDirection IfDirection,
docsQosServiceFlowPrimary TruthValue,
docsQosServiceFlowActiveTimeout Integer32, —obsolete
docsQosServiceFlowAdmittedTimeout Integer32, —obsolete
docsQosServiceFlowSchedulingType SchedulingType, —obsolete
docsQosServiceFlowRequestPolicy OCTET STRING (SIZE(4)), —obsolete
docsQosServiceFlowTosAndMask OCTET STRING (SIZE(1)), —obsolete
docsQosServiceFlowTosOrMask OCTET STRING (SIZE(1)) —obsolete
}

oid walk
$ snmpwalk -v2c -c public 127.0.0.1 1.3.6.1.2.1.10.127.7.1.3
SNMPv2-SMI::transmission.127.7.1.3.1.3.3.6 = Gauge32: 6
SNMPv2-SMI::transmission.127.7.1.3.1.3.3.8 = Gauge32: 8
SNMPv2-SMI::transmission.127.7.1.3.1.3.3.8195 = Gauge32: 0
SNMPv2-SMI::transmission.127.7.1.3.1.3.3.8196 = Gauge32: 0
SNMPv2-SMI::transmission.127.7.1.3.1.3.4.4097 = Gauge32: 4097
SNMPv2-SMI::transmission.127.7.1.3.1.3.4.12289 = Gauge32: 0
SNMPv2-SMI::transmission.127.7.1.3.1.4.3.6 = INTEGER: 2
SNMPv2-SMI::transmission.127.7.1.3.1.4.3.8 = INTEGER: 2
SNMPv2-SMI::transmission.127.7.1.3.1.4.3.8195 = INTEGER: 1
SNMPv2-SMI::transmission.127.7.1.3.1.4.3.8196 = INTEGER: 1
SNMPv2-SMI::transmission.127.7.1.3.1.4.4.4097 = INTEGER: 2
SNMPv2-SMI::transmission.127.7.1.3.1.4.4.12289 = INTEGER: 1
SNMPv2-SMI::transmission.127.7.1.3.1.5.3.6 = INTEGER: 1
SNMPv2-SMI::transmission.127.7.1.3.1.5.3.8 = INTEGER: 1
SNMPv2-SMI::transmission.127.7.1.3.1.5.3.8195 = INTEGER: 1
SNMPv2-SMI::transmission.127.7.1.3.1.5.3.8196 = INTEGER: 1
SNMPv2-SMI::transmission.127.7.1.3.1.5.4.4097 = INTEGER: 1
SNMPv2-SMI::transmission.127.7.1.3.1.5.4.12289 = INTEGER: 1

table walk
$ snmpwalk -v2c -c public 127.0.0.1 DOCS-QOS-MIB::docsQosServiceFlowTable
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.3.6 = Gauge32: 6
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.3.8 = Gauge32: 8
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.3.8195 = Gauge32: 0
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.3.8196 = Gauge32: 0
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.4.4097 = Gauge32: 4097
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.4.12289 = Gauge32: 0
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.3.6 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 2
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.3.8 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 2
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.3.8195 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.3.8196 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.4.4097 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 2
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.4.12289 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.3.6 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.3.8 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.3.8195 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.3.8196 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.4.4097 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.4.12289 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1

AGENTPP · February 13, 2020, 8:29pm

Hi,
If the skipping of the obsolete columns would have been successful during the code generation, there would not be any instance for that column. Instead, those obsolete columns have the wrong syntax (Integer32 instead Gauge32).

How did you suppress the generation of the obsolete columns? Using the skip=true should not generate the columns and there shouldn’t be any values returned for them.

Best regards,
Frank

agsun · February 13, 2020, 9:24pm

The skipping was successful and those columns don’t exist in the mib class. What puzzles me is why when using the tablename for snmpwalk, those obsolete attributes displayed and not just displaying, it would try to map the value to the wrong column? Is this a display issue? or something serious?

agsun · February 13, 2020, 9:24pm

yes we changed the template to use skip=true. Walk with oid looks fine, but we are not sure why walk with table name is not. Is there any log I can find out the issue.

AGENTPP · February 13, 2020, 9:38pm

The walk with OID is identical to those with MIB support (name encoding). The column IDs seems to be wrong in the agent. That is serious!

Please check the constants generated that start with:

public static final int col...;

Have you manually modified the generated sources?

agsun · February 13, 2020, 11:49pm

Frank

The auto gen looks right. That’s why I am puzzled what went wrong.

// Column sub-identifier definitions for docsQosServiceFlowEntry:
public static final int colDocsQosServiceFlowSID = 3;
public static final int colDocsQosServiceFlowDirection = 4;
public static final int colDocsQosServiceFlowPrimary = 5;

// Column index definitions for docsQosServiceFlowEntry:
public static final int idxDocsQosServiceFlowSID = 0;
public static final int idxDocsQosServiceFlowDirection = 1;
public static final int idxDocsQosServiceFlowPrimary = 2;

agsun · February 13, 2020, 11:49pm

We have not manually modified this file.

AGENTPP · February 13, 2020, 11:58pm

OK, the agent is fine then - as you expected it.
The problem with the MIB based walk is the MIB you are using with the NET-SNMP tool. It seems to be a different version with a different column structure.
Normally, MIB specifications have to be written backward compatible (there is a standard for that) and MIBs must not shared OIDs.
At least one of these two rules have been ignored by the authors of your MIB or the one used by the NET-SNMP tool.

agsun · February 14, 2020, 12:10am

Thanks Frank. I want to make sure I understand this correctly.
This behavior could be caused by the MIB used by NET-SNMP tool is different from my current MIB. Or, my MIB is not backward compatible from the previous version. Is the above statement, correct?
If so, I have an additional question.
My MIB table still have the obsolete attributes defined in the Mib file, but I only have data for the non-obsolete in the agent. Could that cause the issues despite the MIB file is backward compatible?
Could it also be the NET-SNMP tool doesn’t do the correct mapping based on the field name and just display?

MIB Table
DocsQosServiceFlowEntry ::= SEQUENCE {
docsQosServiceFlowId Unsigned32,
docsQosServiceFlowProvisionedParamSetIndex Unsigned32, —obsolete
docsQosServiceFlowAdmittedParamSetIndex Unsigned32, —obsolete
docsQosServiceFlowActiveParamSetIndex Unsigned32, —obsolete docsQosServiceFlowSID Unsigned32,
docsQosServiceFlowDirection IfDirection,
docsQosServiceFlowPrimary TruthValue,
docsQosServiceFlowActiveTimeout Integer32, —obsolete
docsQosServiceFlowAdmittedTimeout Integer32, —obsolete
docsQosServiceFlowSchedulingType SchedulingType, —obsolete
docsQosServiceFlowRequestPolicy OCTET STRING (SIZE(4)), —obsolete
docsQosServiceFlowTosAndMask OCTET STRING (SIZE(1)), —obsolete
docsQosServiceFlowTosOrMask OCTET STRING (SIZE(1)) —obsolete
}

AGENTPP · February 14, 2020, 12:18am

Yes, that is correct, but…

Your perception might be correct, that there is a bug in the NET-SNMP walk tool, because you explicitly walk a table. There might an incorrect optimisation implemented that does not check the returned OIDs correctly to resolve them to object names. Please specify the MIB without giving the table name but its parent node’s name. Maybe then the correct column names are displayed.

agsun · February 14, 2020, 1:12am

Frank

I am not quite sure if I did correctly on walking a table. Below are my tests.
I tried

$ snmpwalk -v2c -c public 127.0.0.1 DOCS-QOS-MIB
DOCS-QOS-MIB: Unknown Object Identifier (Sub-id not found: (top) -> DOCS-QOS-MIB)

I tried

$ snmpwalk -v2c -c public 127.0.0.1 DOCS-QOS-MIB::docsQosMIB
…
DOCS-QOS-MIB::docsQosParamSetBitMap.4.12289.active = BITS: F0 00 00 00 trafficPriority(0) maxTrafficRate(1) maxTrafficBurst(2) minReservedRate(3)
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.3.6 = Gauge32: 6
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.3.8 = Gauge32: 8
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.3.8195 = Gauge32: 0
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.3.8196 = Gauge32: 0
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.4.4097 = Gauge32: 4097
DOCS-QOS-MIB::docsQosServiceFlowProvisionedParamSetIndex.4.12289 = Gauge32: 0
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.3.6 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 2
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.3.8 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 2
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.3.8195 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.3.8196 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.4.4097 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 2
DOCS-QOS-MIB::docsQosServiceFlowAdmittedParamSetIndex.4.12289 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.3.6 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.3.8 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.3.8195 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.3.8196 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.4.4097 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowActiveParamSetIndex.4.12289 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1
DOCS-QOS-MIB::docsQosServiceFlowPkts.3.6 = Counter32: 0
DOCS-QOS-MIB::docsQosServiceFlowPkts.3.8 = Counter32: 0
…
I still see the “wrong type” output. If my walk incorrect, please let me know. Thanks

AGENTPP · February 14, 2020, 1:14am

The second walk is OK. The result of the walk indicates that there is a MIB specification mismatch.

agsun · February 15, 2020, 9:57am

Got it. Thanks Frank.

stezhou · February 17, 2020, 6:31pm

Hi Frank, Agnes,
Sorry that I just see this topic and realize it might be caused by my code change in template file.
I just deleted those ‘obsolete’ objects as below, and modified the ‘idx’ and ‘col’ values of un-obsolete objects.

  // Column sub-identifier definitions for #genObjectName($table):
#set( $num = 0)
#foreach ($column in $columns.get($table))
#set( $count = $foreach.count - 1 )
#if( !$agenUtils.isDefined($column.printableOid, "skip") && ($column.getStatus() != "obsolete"))
  #set( $tmp = ${column.objectID.lastSubIdentifier} - $num)
  #genConstantAccess($column)static final int col#upperCamelCase($column) = $tmp;
#else
  #set( $num = $num + 1)
#end
#end

  // Column index definitions for #genObjectName($table):
#set( $num = 0)
#foreach ($column in $columns.get($table))
#set( $count = $foreach.count - 1 )
#if( !$agenUtils.isDefined($column.printableOid, "skip") && ($column.getStatus() != "obsolete"))
  #set( $tmp = $count - $num)
  #genConstantAccess($column)static final int idx#upperCamelCase($column) = ${tmp};
#else
  #set( $num = $num + 1)
#end
#end


@SuppressWarnings(value={"unchecked"})
  private void create#upperCamelCase($table)(MOFactory moFactory) {
    // Index definition
#genIndexStruct($table)
    // Columns
#set ($num = 0)
#foreach ($column in $columns.get($table))
#if( $agenUtils.isDefined($column.printableOid, "skip") || ($column.getStatus() == "obsolete"))
#set ($num = $num + 1)
#end
#end
#set( $col = $columns.get($table).size() - $num)
    MOColumn[] #genObjectName($table)Columns = new MOColumn[$col];
#set ( $rowCreation = false)
#foreach ( $column in $columns.get($table))
#if( !$agenUtils.isDefined($column.printableOid, "skip") && ($column.getStatus() != "obsolete"))
    #genObjectName($table)Columns[idx#upperCamelCase($column)] = 
#if( $column.access == "read-create" ) 
#set ( $rowCreation = true )
#end
#genColumn($column)

Frank, would you please help to confirm about this:
If I define ‘new MOColumn[$columns.get($table).size()]’ and ‘idx’ / ‘col’ values for ‘obsolete’ objects as official template file does, and do not ‘genColumn($column)’ for the ‘obsolete’ objects, will there be errors triggered?

Thanks.

AGENTPP · March 6, 2020, 1:09am

That would work. Simply adapt the code that is used to to the “skip” processing in the template.

Changing idx and col numbers will cause incorrect object types!