FortiSwitch fetching FDB table

Hi all,

I’m currently running into issues with trying to pull the FDB table from a bunch of FortiSwitches running versions 7.x.y and I’m curious if anyone has this functioning in some way, perhaps with a custom fortiswitch.inc.php file?

Running the following command:

./discovery.php -h 10.101.254.84 -m fdb-table -dd

Returns the following (amongst others):

Error discovering fdb-table module for 10.101.254.84. TypeError: Cannot access offset of type string on string in /opt/librenms/includes/discovery/fdb-table/bridge.inc.php:62
Stack trace:
#0 /opt/librenms/includes/discovery/fdb-table.inc.php(29): include()
#1 /opt/librenms/includes/discovery/functions.inc.php(164): include('...')
#2 /opt/librenms/discovery.php(108): discover_device()
#3 {main}  
SQL[insert into `eventlog` (`reference`, `type`, `datetime`, `severity`, `message`, `username`, `device_id`) values (?, ?, ?, ?, ?, ?, ?) [null,"discovery","2024-02-21 09:45:12",5,"Error discovering fdb-table module. Check log file for more details.","",82] 0.77ms] 
  
Cannot access offset of type string on string {"exception":"[object] (TypeError(code: 0): Cannot access offset of type string on string at /opt/librenms/includes/discovery/fdb-table/bridge.inc.php:62)"}

snmpwalking the OID 1.3.6.1.2.1.17.4.3.1 returns the following:

[librenms@nms01 ~]$  snmpwalk -v3 -l authPriv -a SHA256 -A $pwd -x AES256 -X $key -u $user 10.101.254.84 1.3.6.1.2.1.17.4.3.1
SNMPv2-SMI::mib-2.17.4.3.1.1.1 = Hex-STRING: 58 6C 25 E6 3C 4B 
SNMPv2-SMI::mib-2.17.4.3.1.1.2 = Hex-STRING: 28 D0 EA AB 6A 85 
SNMPv2-SMI::mib-2.17.4.3.1.1.3 = Hex-STRING: 18 66 DA 1B 0C 1E

… and so on with all the MAC addresses on the switch.

I was under the impression that this was functional previously on 6.4.5 but it seems not as per the below; perhaps the fdb-table module has never worked on FortiSwitches?

./discovery.php -h 10.101.254.56 -m fdb-table -dd

SNMP['/usr/bin/snmpbulkwalk' '-v3' '-l' 'authPriv' '-n' "" '-a' 'SHA-256' '-A' 'PASSWORD' '-u' 'USER' '-x' 'AES-256' '-X' 'PASSWORD' '-OQUsetX' '-m' 'Q-BRIDGE-MIB' '-M' '/opt/librenms/mibs:/opt/librenms/mibs/fortinet' 'udp:HOSTNAME:161' 'dot1qTpFdbPort']
dot1qTpFdbPort = No Such Object available on this agent at this OID  
  
SNMP['/usr/bin/snmpbulkwalk' '-v3' '-l' 'authPriv' '-n' "" '-a' 'SHA-256' '-A' 'PASSWORD' '-u' 'USER' '-x' 'AES-256' '-X' 'PASSWORD' '-OQUsetX' '-m' 'BRIDGE-MIB' '-M' '/opt/librenms/mibs:/opt/librenms/mibs/fortinet' 'udp:HOSTNAME:161' 'dot1dTpFdbPort']
dot1dTpFdbPort = No Such Object available on this agent at this OID

Here is my .validate.php:

[librenms@nms01 ~]$ ./validate.php 
===========================================
Component | Version
--------- | -------
LibreNMS  | 24.1.0-88-g4d3149497 (2024-02-19T13:16:03+01:00)
DB Schema | 2024_02_07_151845_custom_map_additions (290)
PHP       | 8.2.15
Python    | 3.9.18
Database  | MariaDB 10.5.22-MariaDB
RRDTool   | 1.7.2
SNMP      | 5.9.1
===========================================

[OK]    Composer Version: 2.7.1
[OK]    Dependencies up-to-date.
[OK]    Database connection successful
[OK]    Database Schema is current
[OK]    SQL Server meets minimum requirements
[OK]    lower_case_table_names is enabled
[OK]    MySQL engine is optimal
[OK]    Database and column collations are correct
[OK]    Database schema correct
[OK]    MySQL and PHP time match
[OK]    Active pollers found
[OK]    Dispatcher Service not detected
[OK]    Locks are functional
[OK]    Python poller wrapper is polling
[OK]    Redis is unavailable
[OK]    rrd_dir is writable
[OK]    rrdtool version ok
[librenms@nms01 ~]$

Many thanks for any and all help!

I can replicate your issue. I’ll see what’s going on

1 Like

Seems FortiSwitchOS returns the dot1qVlanFdbId table in a different way. This is from a HP ProCurve switch:

Q-BRIDGE-MIB::dot1qVlanFdbId.0.1 = Gauge32: 1
Q-BRIDGE-MIB::dot1qVlanFdbId.0.98 = Gauge32: 2
Q-BRIDGE-MIB::dot1qVlanFdbId.0.99 = Gauge32: 3
Q-BRIDGE-MIB::dot1qVlanFdbId.0.100 = Gauge32: 4
Q-BRIDGE-MIB::dot1qVlanFdbId.0.101 = Gauge32: 5
Q-BRIDGE-MIB::dot1qVlanFdbId.0.211 = Gauge32: 6
Q-BRIDGE-MIB::dot1qVlanFdbId.0.606 = Gauge32: 7
Q-BRIDGE-MIB::dot1qVlanFdbId.0.1022 = Gauge32: 8

The second number in the index is the VLAN ID.

Here’s a FortiSwitch:

Q-BRIDGE-MIB::dot1qVlanFdbId.1 = Wrong Type (should be Gauge32 or Unsigned32): Counter32: 0
Q-BRIDGE-MIB::dot1qVlanFdbId.2 = Wrong Type (should be Gauge32 or Unsigned32): Counter32: 0
Q-BRIDGE-MIB::dot1qVlanFdbId.3 = Wrong Type (should be Gauge32 or Unsigned32): Counter32: 0
Q-BRIDGE-MIB::dot1qVlanFdbId.4 = Wrong Type (should be Gauge32 or Unsigned32): Counter32: 0
Q-BRIDGE-MIB::dot1qVlanFdbId.5 = Wrong Type (should be Gauge32 or Unsigned32): Counter32: 0
Q-BRIDGE-MIB::dot1qVlanFdbId.6 = Wrong Type (should be Gauge32 or Unsigned32): Counter32: 0
Q-BRIDGE-MIB::dot1qVlanFdbId.7 = Wrong Type (should be Gauge32 or Unsigned32): Counter32: 0
Q-BRIDGE-MIB::dot1qVlanFdbId.8 = Wrong Type (should be Gauge32 or Unsigned32): Counter32: 0
Q-BRIDGE-MIB::dot1qVlanFdbId.9 = Wrong Type (should be Gauge32 or Unsigned32): Counter32: 0

Not only is the index just a single number (instead of X.Y from the HP), but it’s value is of the wrong type and all values are zero.

Based on my experience with FortiNet’s SNMP I’m leaning towards calling this a Forti bug, but I’ll do some more digging.

1 Like

Perhaps @PipoCanaja or @laf can chime in here to validate my findings…

From the Q-BRIDGE-MIB from line 1060:

dot1qVlanCurrentEntry OBJECT-TYPE
    SYNTAX      Dot1qVlanCurrentEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "Information for a VLAN configured into the device by
        (local or network) management, or dynamically created
        as a result of GVRP requests received."
    INDEX   { dot1qVlanTimeMark, dot1qVlanIndex }
    ::= { dot1qVlanCurrentTable 1 }

Relevant here is the INDEX which says should be dot1qVlanTimeMark, dot1qVlanIndex

However… FortiSwitchOS ignores dot1qVlanTimeMark and only uses dot1qVlanIndex for the index in dot1qVlanCurrentEntry

So, I believe FortiSwitchOS is not MIB compliant and is missing an index table. And obviously they return the value in the wrong datatype. And I’m pretty sure it shouldn’t all be 0 as value either.

2 Likes

This is great, thank you for your time and effort!

I guess it’s best to file a bug report with Fortinet on this if they indeed are not MIB compliant? Although who knows when they may get around to dealing with that.

I’ve got 5 tickets open with FortiNet currently about their SNMP.
One of them is their BGP4-MIB implementation not being compliant.

They acknowledged the issue. You’d think they’d fix it… But no… They are going to implement a new configuration parameter to revert their change. So default settings will still have broken BGP4-MIB implementation :frowning:

The non-default setting will make their SNMP MIB compliant, but lacking BGP peers for vDOMs

1 Like

That’s less than great, how infuriating!

I don’t suppose there’d be a way to work around this since OID 1.3.6.1.2.1.17.4.3.1 seems to return the MAC addresses at least?

The only way is to open cases with their support ! The more they have, the more chances you get to see a solution coming (even a partial one).
And of course considering other vendors when choosing replacement devices. Unfortunately, no vendor is perfect, so at the end of the game, you have to make choices …

Yeah, of course – I was just thinking if there’s a way to import all the MAC addresses into the LibreNMS’ FDB table via the above OID via a custom fortiswitch.inc.php file for the time being, as it’s very convenient to be able to search that way without granting access to actual network devices. :slight_smile:

Regardless, I’ll bring this up with our Fortinet representative.

Thank you @Tozz for your time, help, and expertise. <3

I have a call in 30 minutes with FortiNet regarding this issue. Our ticket ID is 9239914
If you open a ticket on your behalf, you might refer to our ticket ID so they know this is affecting multiple customers.

I’ll take a look at a FortiSwitchOS specific fix depending on what their answer is going to be.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.