snmp exporter and index queries

[paulinster]

Hi Everyone,

Has anyone succeeded in monitoring VPN using snmp_exporter/prometheus ? I am trying to query fgVpnTunTable(.1.3.6.1.4.1.12356.101.12.2.2) but it does fail with error like this...

800 error(s) occurred: * collected metric "fgVpnTunEntLocGwyIp" { label:<name:"fgVpnTunEntIndex" value:"140" > label:<name:"fgVpnTunEntLocGwyIp" value:"208.94.108.2" > gauge:<value:1 > } was collected before with the same name and label values * collected metric "fgVpnTunEntSelectorDstEndIp" { label:<name:"fgVpnTunEntIndex" value:"134" > label:<name:"fgVpnTunEntSelectorDstEndIp" value:"10.248.32.255" > gauge:<value:1 > } was collected before with the same name and label values * collected metric "fgVpnTunEntSelectorSrcBeginIp" { label:<name:"fgVpnTunEntIndex" value:"24" > label:<name:"fgVpnTunEntSelectorSrcBeginIp" value:"192.168.147.0" > gauge:<value:1 > } was collected before with the same name and label values * collected metric "fgVpnTunEntInOctets" { label:<name:"fgVpnTunEntIndex" value:"136" > counter:<value:1.9405667848e+10 > } was collected before with the same name and label values * collected metric "fgVpnTunEntTimeout" { label:<name:"fgVpnTunEntIndex" value:"171" > gauge:<value:41053 > } was collected before with the same name and label values * collected metric "fgVpnTunEntLocGwyIp" { label:<name:"fgVpnTunEntIndex" value:"136" > label:<name:"fgVpnTunEntLocGwyIp" value:"208.94.108.2" > gauge:<value:1 > } was collected before with the same name and label values

After digging a bit more I found that it look like the fgVpnTunEntIndex (1.3.6.1.4.1.12356.101.12.2.2.1.1) isn't returned by the Fortigate. I have open a case with them and they say the followging

"as per current design (6.2.3 and above) for SNMP query for VPN tunnel list, the phase1 serial and phase2 serial both are used to be indexes for VPN Tunnel list. So the original fgVpnTunEntIndex is NOT used now"

The fgVpnTunEntIndex became meaningless (just for MIB compatibility). And also, any index of the table should be defined as "not-accessible"."

So I am now confused on how I can query a VPN status or bandwitdh if I can't refer to an index. As per they say and my understanding the only value

[sw2090]

Our nagios/icinga based monitoring uses the nagios check_fortigate plugin which uses these oids to check vpn status. However we only have ipsec. Works fine for these.

# VPN OIDs # XXX to be checked my $oid_ActiveSSL = ".1.3.6.1.4.1.12356.101.12.2.3.1.2.1"; # Location of Fortinet firewall SSL VPN Tunnel connection count my $oid_ActiveSSLTunnel = ".1.3.6.1.4.1.12356.101.12.2.3.1.6.1"; # Location of Fortinet firewall SSL VPN Tunnel connection count my $oid_ipsectuntableroot = ".1.3.6.1.4.1.12356.101.12.2.2.1"; # Table of IPSec VPN tunnels my $oidf_tunstatus = ".20"; # Location of a tunnel's connection status my $oidf_tunndx = ".1"; # Location of a tunnel's index... my $oidf_tunname = ".3"; # Location of a tunnel's name...

[paulinster]

Well those are exactly the oid that I querying... 

But if I run an snmpwalk againt the index oid.. I am getting oid not found...

$ snmpbulkwalk -v2c -c stingrayread -Cr25 10.1.0.81 .1.3.6.1.4.1.12356.101.12.2.2.1.1 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.1 = No Such Instance currently exists at this OID

If I run it again the tunstatus and tunname does return result, but I am getting the result that include the phase1 interface index + phase2 interface index..

For example...

$ snmpbulkwalk -v2c -c stingrayread -Cr25 10.1.0.81 .1.3.6.1.4.1.12356.101.12.2.2.1.2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.52 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.53 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.54 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.55 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.56 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.57 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.58 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.59 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.61 = STRING: "REMOTE_OFFICEA" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.2.180.63 = STRING: "REMOTE_OFFICEA" $ snmpbulkwalk -v2c -c stingrayread -Cr25 10.1.0.81 .1.3.6.1.4.1.12356.101.12.2.2.1.3 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.52 = STRING: "REMOTE_OFFICEA_P1" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.53 = STRING: "REMOTE_OFFICEA_P2" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.54 = STRING: "REMOTE_OFFICEA_P3" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.55 = STRING: "REMOTE_OFFICEA_P4" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.56 = STRING: "REMOTE_OFFICEA_P5" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.57 = STRING: "REMOTE_OFFICEA_P6" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.58 = STRING: "REMOTE_OFFICEA_P7" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.59 = STRING: "REMOTE_OFFICEA_P8" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.61 = STRING: "REMOTE_OFFICEA_P9" SNMPv2-SMI::enterprises.12356.101.12.2.2.1.3.180.63 = STRING: "REMOTE_OFFICEA_P10" $ snmpbulkwalk -v2c -c stingrayread -Cr25 10.1.0.81 .1.3.6.1.4.1.12356.101.12.2.2.1.20 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.52 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.53 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.54 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.55 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.56 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.57 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.58 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.59 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.61 = INTEGER: 2 SNMPv2-SMI::enterprises.12356.101.12.2.2.1.20.180.63 = INTEGER: 1

As per the ticket I have open with them, look like Fortinet has completely change the way they returned snmp data...

[sw2090]

.1.3.6.1.4.1.12356.101.12.2.2.1.1 seems indeed not to exist.

howewver my nagios starts with .1.3.6.1.4.1.123456.101.12.2.2.1.

If I do an snmpwalk on one of my FGT that starts at this it runs through showing my all my ipsecs etc.

[paulinster]

It does also snmpwalk through the whole ipsec tun table fgVpnTunEntry(.1.3.6.1.4.1.12356.101.12.2.2.1), but the problem is that prometheus's snmp_exporter look at the fortigate MIB file and do rely on the index in order to push data within the database. When is push data to the database, it add some labels so when it' try to push/ingest the data, the format will look like this.

fgVpnTunEntStatus{ fgVpnTunEntIndex="x" } my_fgVpnTunEntStatus_value

The same snmp_exporter setup/config look to be working fine on previous version of FortiOS.

[lubyou]

paulinster wrote:

It does also snmpwalk through the whole ipsec tun table fgVpnTunEntry(.1.3.6.1.4.1.12356.101.12.2.2.1), but the problem is that prometheus's snmp_exporter look at the fortigate MIB file and do rely on the index in order to push data within the database. When is push data to the database, it add some labels so when it' try to push/ingest the data, the format will look like this.

fgVpnTunEntStatus{ fgVpnTunEntIndex="x" } my_fgVpnTunEntStatus_value

The same snmp_exporter setup/config look to be working fine on previous version of FortiOS.

I saw your bug report for the snmpexporter and the replies (https://github.com/prometheus/snmp_exporter/issues/609).

Did you made any progress with TAC?

[paulinster]

last comments/update I got from TAC look like they finally acknowledge the issue, however I haven't been able to get further details/informations :(

[lubyou]

paulinster wrote:

last comments/update I got from TAC look like they finally acknowledge the issue, however I haven't been able to get further details/informations :(

TAC told me that there is going to be an updated MIB with the release of FortiOS 7, "Add fgVpnTunEntPhase2Index as the second index of fgVpnTunTable in MIB file.".