Indexing modern brocade switches

[error1]

Several of the OIDs in the old templates posted in viewtopic.php?f=12&t=6346 have been deprecated in new switches and new firmwares, while trying to figure out what's broken I found an updated snmp reference here https://docs.broadcom.com/doc/FOS-82x-MIB-RM (search the pdf for "obsolete")

I think the reason the old OIDs were obsoleted is that the traffic counters used to be 32-bit counters that wrapped way too fast on modern switches. The latest generation of FC is 32gb per port and at that point not even 1 minute polling would be able to keep the counter from wrapping several times per polling cycle.
Old counters:
swFCPortTxWords 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.11
swFCPortRxWords 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.12
New counters:
connUnitPortStatCountTxElements 1.3.6.1.3.94.4.5.1.6
connUnitPortStatCountRxElements 1.3.6.1.3.94.4.5.1.7

The new counters reply with Hex-STRING but fortunately cacti seems to handle them fine once it knows the right OID.

I haven't been able to index the new traffic counters properly yet though, when I walk those OIDs I get a bunch of extra numerical OID data that I'm not sure what is:
# snmpwalk -m FCMGMT-MIB -v2c -cpublic 192.168.1.10 .1.3.6.1.3.94.4.5.1.7
FCMGMT-MIB::connUnitPortStatCountRxElements.'....3..H........'.1 = Hex-STRING: 00 00 03 AB A0 BA 1D CC
FCMGMT-MIB::connUnitPortStatCountRxElements.'....3..H........'.2 = Hex-STRING: 00 00 05 4A EE 5D 9A A0
FCMGMT-MIB::connUnitPortStatCountRxElements.'....3..H........'.3 = Hex-STRING: 00 00 02 0D 66 93 01 68
FCMGMT-MIB::connUnitPortStatCountRxElements.'....3..H........'.4 = Hex-STRING: 00 00 00 00 00 00 03 B0
etc

# snmpwalk -m FCMGMT-MIB -v2c -cpublic 192.168.1.10 .1.3.6.1.3.94.4.5.1.7 -O fn
.1.3.6.1.3.94.4.5.1.7.16.0.0.5.51.253.167.72.0.0.0.0.0.0.0.0.1 = Hex-STRING: 00 00 03 AB A0 BA 1D CC
.1.3.6.1.3.94.4.5.1.7.16.0.0.5.51.253.167.72.0.0.0.0.0.0.0.0.2 = Hex-STRING: 00 00 05 4A EE 5E 3B 24
.1.3.6.1.3.94.4.5.1.7.16.0.0.5.51.253.167.72.0.0.0.0.0.0.0.0.3 = Hex-STRING: 00 00 02 0D 66 93 01 68
.1.3.6.1.3.94.4.5.1.7.16.0.0.5.51.253.167.72.0.0.0.0.0.0.0.0.4 = Hex-STRING: 00 00 00 00 00 00 03 B0
etc

In this output the interface number is the last digit of the OID but I don't know what to do about the "16.0.0.5.51.253.167.72.0.0.0.0.0.0.0.0" part of the OID. Updating the template to include all the extra numbers I can get it to work on a single switch but the middle part of the OID is different on my switches. Maybe it's a serial number or something. Unless I'm missing something it isn't explained in the reference PDF either. Is it possible to extract that middle part of the OID and store it in a variable per device with a regular snmp query?

[TheWitness]

Good question for the hardware vendor.

[error1]

I've contacted the vendor but I'm not expecting much help from Broadcom, I will probably have to figure out some workaround.
They would much rather sell me their own monitoring software (which we already use, but Cacti is much better at aggregates and tracking long term historical metrics)

I think I'm about to get it working for everything under the 1.3.6.1.3.94 OID tree with this massive kludge to use the last 17 nodes as the index:

<oid_index>.1.3.6.1.3.94.1.10.1.18</oid_index>
<oid_index_parse>OID/REGEXP:.*\.([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,4})$</oid_index_parse>

oof
Once I know it actually works and the data looks correct I can post an updated brocade query xml and template