Cacti should support with bogus OIDs coming from devices (example: Juniper Netscreen security metrics)

[bernisys]

Feature Request

Is your feature request related to a problem? Please describe

This might be a corner case, but i think Cacti could support here easily, requiring less effort in the XML part of the query.

The Juniper Netscreen devices offer security metrics (like SYN attack counters) under the OID .1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.1

Problem here is, that the string indexes of the contained objects are padded with trailing zeros .. If someone from Juniper reads this: Guys this is majorly ugly .. someone might think a check for an end-of-string is missed in the code :)

Cacti doesn't parse this properly out of the box, the zeros seem to irritate it too much, the index enumeration is not counting up the object number, the result is that only the first element is kept in the list of returned objects, even though the debug output lists all strings properly.

Describe the solution you'd like

Cacti should drop trailing zeros in the OIDs before parsing the name objects of an OID-index.

Describe alternatives you've considered

The XML solution is to use this regex to parse out the zeros at the end:

<oid_index_parse>OID/REGEXP:\.*1\.3\.6\.1\.4\.1\.2636\.3\.39\.1\.8\.1\.1\.1\.1\.1\.([0-9.]*?)[0.]*$</oid_index_parse>

Though this can really be a bit misleading for even advanced Cacti users, to have to produce a regex parser for something that should actually work without it.

Additional context

Here's the result without the regex:

Here with regex parser included in the XML:

[bernisys]

As i was asked on the call, here's the model: System: Juniper Networks, Inc. srx4200 internet router, kernel JUNOS 23.4R2-S2.1, Build date: 2024-08-21 10:46:39 UTC Copyright (c) 1996-2024 Juniper Networks, Inc.

and here's the "juniper-netscreen-screenmon.xml"

<screenmon>
  <name>Get Juniper Netscreen ScreenMon security stats</name>
  <description>Queries a Juniper Netscreen device for security stats</description>
  <!--oid_index>.1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.1</oid_index-->
  <!--oid_num_indexes> not available here </oid_num_indexes-->
  <oid_index_parse>OID/REGEXP:\.*1\.3\.6\.1\.4\.1\.2636\.3\.39\.1\.8\.1\.1\.1\.1\.1\.([0-9.]*)$</oid_index_parse>
  <index_order>jnxJsScreenZoneName</index_order>
  <index_order_type>alphabetic</index_order_type>
  <index_title_format>|chosen_order_field|</index_title_format>

  <fields>
    <jnxJsScreenZoneName>
      <name>Name of the security zone</name>
      <method>walk</method>
      <source>value</source>
      <direction>input</direction>
      <oid>.1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.1</oid>
    </jnxJsScreenZoneName>

    <jnxJsScreenNumOfIf>
      <name>Number of interfaces in the zone</name>
      <method>walk</method>
      <source>value</source>
      <direction>output</direction>
      <oid> .1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.3</oid>
    </jnxJsScreenNumOfIf>

    <jnxJsScreenMonSynAttk>
      <name>Number of SYN attacks</name>
      <method>walk</method>
      <source>value</source>
      <direction>output</direction>
      <oid> .1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.3</oid>
    </jnxJsScreenMonSynAttk>

    <jnxJsScreenMonUdpFlood>
      <name>UDP flood attack packets</name>
      <method>walk</method>
      <source>value</source>
      <direction>output</direction>
      <oid>.1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.10</oid>
    </jnxJsScreenMonUdpFlood>

    <jnxJsScreenMonPortScan>
      <name>port scan attempt attack packets</name>
      <method>walk</method>
      <source>value</source>
      <direction>output</direction>
      <oid>.1.3.6.1.4.1.2636.3.39.1.8.1.1.1.1.12</oid>
    </jnxJsScreenMonPortScan>

  </fields>
</screenmon>

[bernisys]

We had a ticket with Juniper which was of not much success, they simply claim "these are 64 character fixed-length strings". They mentioned we can file a feature request, but i doubt that this will be implemented/fixed.

We took into account to have a scripted solution, but this is not really a good approach, as other vendors could have the same issue in the OID presentation which would then trigger the same behavior.

We also thought about fixing this on the device - on Juniper you can implement scripts and bind them to OIDs, this was already done for a specific parameter that was only present on the device itself but not in the MIBs.

So it seems that it's on Cacti side to decide a proper solution for this case. If there are any proposals for code changes in order to test this, as usual i can offer to port this into our environment and check the outcome.

One thing i am pondering about is: When I leave it to Cacti to detect the index, it always detects "0" - so it almost seems like Cacti is cutting of the front of the OID string, leaving only the chain of zeros. When i use the Regex which cuts of the trailing zeros, then it detects the string correctly, but the queries are not working - probably because the wrong OID is produced during the queries to the device (trailing zeros missing). Actually this should be covered by using the "SNMP Walk" method, which should query all sub-objects and return the correct result in the end. But it might be that the same issue could happen with the OID translation during the actual query.

[TheWitness]

Yea, that's pretty common with hardware or stacks that they no longer want to support (aka snmp).

[TheWitness]

Got to get back on track with my stream plugin. Too many distractions and not enough retirement yet.