Enhance SnmpInterfacePoller to optionally treat additional statuses as down

Cisco marks the status of failed SIP dial peers as testing(3) rather than down(2) and I bet there are other use cases where someone might need to treat one or more of the other values down.

The possible values from IF-MIB are

int meaning
1 up
2 down
3 testing
4 unknown
5 dormant
6 notPresent
7 lowerLayerDown

A brief look through the code seems to reveal that SnmpMinimalPollInterface treats anything > 2 as unknown and PollableSnmpInterface only changes status and therefore sends events when the status is either up(1) or down(2). What I’m proposing is to add the additional statuses to the status array in SnmpMinimalPollInterface, then in SnmpMinimalPollInterface treat each value above 2 as equivalent to down when new false-by-default configuration options are marked as true that control treating each of those statuses as down, with an additional catch-all value that treats any value >= 2 as down (which would take precedence over the individual config items for those statuses).

1 Like

Thx to @dino2gnt for the recommendation to change the config to lists of mapped values similar to response in DNS/HTTP monitors. So by default the up values would be 1 and down values would be 2 but then you could change either with range and/or comma separated values.

For example to get anything >=2 marked as down, set the down config parameter it to 2-7. To only treat down(2) and testing(3) as down, set it to either 2-3 or 2,3. If you want down(2), testing(3) and lowerLayerDown(7) marked down, set it to 2-3,7, etc.

1 Like

OK I’ve got this working in my feature branch. Some details of the implementation follow:

For those unfamiliar with the feature, the SNMP interface poller is a separate daemon (and is disabled by default). It performs these actions for SNMP interfaces of eligible node interfaces:

  • update ifAdminStatus and ifOperStatus for eligible interfaces in the snmpinterfaces table
  • send uei.opennms.org/nodes/snmp/interfaceOperDown and uei.opennms.org/nodes/snmp/interfaceOperUp (and similar for interfaceAdminUp/Down) events when state changes on an interface.

There are two places which control which SNMP interfaces are eligible for these actions. You use the ENABLE_POLLING action of the SnmpInterfacePolicy in the foreign source definition of a provisioning requisition to turn on polling for SMP interfaces that match that policy’s rules. You can also optionally turn on useCriteriaFilters in the $ONMS_HOME/etc/snmp-interface-poller-configuration.xml file. There’s some conflicting information on exactly what using that feature does. Based on my testing, it seems that whether or not useCriteriaFilters is set to true or false, somehow the snmppoll column needs to be P in the snmpinterface table. Using a policy is the easiest way to accomplish that. As far as I can tell the only thing turning useCriteriaFilters on does is that things that don’t match a package interface in the config file won’t get polled at all, but when it is set to false they get polled with default settings.

For more details on how to configure and use this service, refer to the wiki page (and then probably also be prepared to read some code because not everything is covered there and not everything is accurate!).

As stated in the original post, the service as it was only emits up/down events when ifAdminStatus and ifOperStatus were literally the integer representations of up and down as defined in the IF-MIB, and I wanted to be able to map additional values to be considered as up and down. To do so, you can now define up-values and down-values as attributes of the top level element of the SNMP interface poller config file (snmp-interface-poller-configuration in $ONMS_HOME/etc/snmp-interface-poller-configuration.xml) and/or in an interface element of a package.

The values present in the snmp-interface-poller-configuration element are used if the node interface does not match an interface in a package or if the matching interface does not define explicit values.

Some examples:

<snmp-interface-poller-configuration xmlns="http://xmlns.opennms.org/xsd/config/snmpinterfacepoller" threads="30" service="SNMP" interval="60000" up-values="1,5" down-values="2,3">
   <node-outage>
      <critical-service name="ICMP"/>
      <critical-service name="SNMP"/>
   </node-outage>
   <package name="example1">
      <filter>IPADDR != '0.0.0.0'</filter>
      <include-range begin="172.17.14.1" end="172.17.14.10"/>
      <include-range begin="::1" end="::1"/>
      <interface criteria="snmpiftype = 104" name="VoIP" interval="30000" user-defined="false" status="on" up-values="1" down-values="2,3,7" />
   </package>
</snmp-interface-poller-configuration>

In this case, assume you’ve got a node interface of 172.17.14.10 which has some SNMP interfaces marked for polling with an ifType of 104. These interfaces would use 1 for up-values and 2,3,7 for down-values. But a node interface with an IP of, say, 172.17.14.11 would not match the package so it would use the global values of 1,5 for up-values and 2,3 for down-values. An interface marked for polling with a different ifType on 172.17.14.10 would also use 1,5 and 2,3 since it doesn’t match the criteria filter on the interface element, and useCriteriaFilters is default (false), so polling still occurs, but using default settings.

<snmp-interface-poller-configuration xmlns="http://xmlns.opennms.org/xsd/config/snmpinterfacepoller" threads="30" service="SNMP" interval="60000" up-values="1" down-values="2,3">
   <node-outage>
      <critical-service name="ICMP"/>
      <critical-service name="SNMP"/>
   </node-outage>
   <package name="example1">
      <filter>IPADDR != '0.0.0.0'</filter>
      <include-range begin="172.17.14.1" end="172.17.14.10"/>
      <include-range begin="::1" end="::1"/>
      <interface criteria="snmpiftype = 103" name="POTS" interval="30000" user-defined="false" status="on" up-values="1,5" down-values="2,3,4,6,7"/>
     <interface criteria="snmpiftype = 104" name="VoIP" interval="30000" user-defined="false" status="on" up-values="1" down-values="2,3,4,5,6,7"/>
   </package>
</snmp-interface-poller-configuration>

In this case, interfaces of ifType 103 get up-values="1,5" and down-values="2,3,4,6,7" whereas interfaces with ifType 104 get up-values="1" and down-values="2,3,4,5,6,7". Eligible interfaces with other ifTypes will get up-values="1" and down-values="2,3".

A note on the valid values for up-values and down-values: since ParameterMap.getKeyedIntegerArray(Map map, String key, int[] defVaules) exists and the total number of possible values is rather small, I opted to only support lists of individual values rather than parsing ranges.

1 Like