FGT SNMP HA Monitoring

[Dominik]

Hi guys and girls,

we're using PRTG to monitor our and the customers environments.

At the current time we're using shell scripts to monitor the HA status of a FGT cluster via SSH. I'd like to switch over to SNMP, because shell scripts use a high amount of ressources. But it seems to me that HA monitoring over SNMP isn't that detailed as it should be. In the MIB (of 6.0, 6.2 and 6.4) I can't find an OID to monitor for example the "monitoring device/interface" status. An this is crucial.

Do you have any experience in using SNMP to monitor a FGT cluster and the HA status in detail? Thanks in advance.

Kind regards,

Dominik

[Jirka1]

Hi Dominik,

we also use PRTG for monitoring.

You must use a dedicated port for management and enable SNMP redirect.

FROM KB:

If devices are in HA:

Each device in the cluster sends its own traps and manager can query both the devices Dedicated HA management port has to be enabled in the HA settings.

[size="2"]

#config system ha
set ha-mgmt-status enable
set ha-mgmt-interface “interface"
set ha-mgmt-interface-gateway x.x.x.x
end

[/size]

[size="2"]“ha-direct” setting has to be enabled on the SNMP settings

#config system snmp community

edit 1
config hosts
edit 1
set ha-direct enable
next
next
end

[/size]

Jirka

[Dominik]

Hi Jirka,

that's correct.

For FGT models with dedicated mgmt ports you can easily monitor both nodes seperated. This way you can see if an interface is up/down. But not every location/every FGT model has a dedicated mgmt port. If you simple go onto the CLI and trigger 'get system ha status' you get such a detailed info about the ha status. This info should be able to request over SNMP. At least in my opinion. For now I don't see a way.

Kind regards,

Dominik

[Jirka1]

Hi Dominik,

I understand. Now I have tried to create a template for HA monitoring for our PRTG on HA cluster 2x 60D without mngmt port and it works.

Take a look at the screenshots to see if this would suit you: Download here: https://1drv.ms/u/s!Av_M3...DYzkwvyBR93hl?e=lpZLkG Just copy it to the folder: c: \ Program Files (x86) \ PRTG Network Monitor \ snmplibs \ and perform "Load Lookups and File Lists" in the Administration

EDIT: Of course, it is also possible to adjust the units for individual channels :)

Jirka

[Dominik]

Hi Jirka,

well, thanks. But I know that the HA mib works for small and big clusters. But especially for small clusters (for example a 60D cluster) you don't have the possibility to monitor the link state of the HA monitored interfaces. That isn't covered by the HA mib. And that's the problem.

At big cluster you simply monitor each node. That way you get the link state of each interface.

Kind regards,

Dominik

[Jirka1]

Dominik, but that's not true. As for the link-monitor only (up / down), this function is already implemented in the PRTG. In the settings of the sensor for SNMP traffic monitoring (or HA interface), it is enough to enable notification when the interface status changes - see. screenshot

Jirka

[localhost]

If I understand Dominik correctly, he wants to monitor physical interfaces on his slave unit.

Not just the HA-Port connecting both units.

All I can think of is using this method:

https://kb.fortinet.com/kb/viewContent.do?externalId=13077

If your SNMP community name is 'public' and the slave unit has the Serial 'FGT4HD1234500000'. The new community name becomes 'public-FGT4HD1234500000'.

In PRTG you would have to create a seperate device for this.

Because I it looks like, you can't set a SNMP community for an individual sensor, only per device.

[Dominik]

Hi localhost,

you're right. I wand to monitor the state of the physical interfaces on the slave unit.

On a cluster with a dedicated mgmt interface it's easy because I can query both units. But on a cluster without dedicated mgmt interfaces I have to rely on the information getting out from my SNMP ha status query. The SNMP OID doesn't communicate the status of the physikal interfaces of the slave. The command 'get system ha status' does so. Because of that we're currently using a ssh shell script. But that's very unperformant.

Back to your answer: if I understood the KB right you can query every SNMP command to the slave if you attach the SN of the corresponding unit after the SNMP community and the FGT will redirect the SNMP get over the HA link to the slave unit!?

If I am right: is this a good solution? Do you or anyone else have any experience with that?

Update: Just tested it. Doesn't work anymore. Tryed it with FGTs on 6.2.x and FGTs on 6.4.x. Furthermore it wouldn't be a solution for devices with SNMPv3. :\

Kind regards,

Dominik

[localhost]

Yes correct. This method is very similar to the method Jirka described. But instead of quering SNMP directly on the slave unit, the master unit forwards the snmp query to the slave unit.

I just tried with 6.2 and also running into issues. While on 6.0 it's working.

Interestingly - if I run a '#diagnose debug application snmpd -1' on 6.2, you can see that's it's still accepting and forwarding the SNMP query to the slave.

Master:

snmpd: <msg> 66 bytes 8.7.6.5:64217 -> 1.2.3.4/1.2.3.4:161 (itf 107.107)
snmpd: checking if community "TestCommunity-FG100FTK12345678" is valid
snmpd: checking against community "TestCommunity"
snmpd: request 1(root)/107/8.7.6.5 != comm 1/0/10.10.10.1/255.255.255.255
snmpd: request 1(root)/107/8.7.6.5 != comm 1/0/10.10.10.2/255.255.255.255
snmpd: request 1(root)/107/8.7.6.5 == comm 1/0/8.7.6.0/255.255.255.0
snmpd: HA claimed the community. "TestCommunity-FG100FTK12345678"
snmpd: </msg> 0

Slave:

snmpd: <msg> 65 bytes 1.2.3.4:64217-> 8.7.6.5/127.0.0.1:161 (itf 36.36)
snmpd: checking if community "TestCommunity-FG100FTK12345678" is valid
snmpd: loopback and HA means request from HA master, we trust the master. ACCEPT
snmpd: get     : system.3.0 -> () -> 0
snmpd: redirecting reply to HA master
snmpd: </msg> 0

So I guess, the feature is not totally removed, but somehow broken. Probably worth a support ticket @Fortinet.

And yep - would mean that you'd have to switch back to SNMPv2.

I don't know of any other options to monitor the slave ports, besides the two described in this post.