We’re running a FusionHub VM with firmware 6.3.2s002 build 1425 and I’m monitoring the the remote devices pepvpn connection status via a zabbix snmp server. I have setup a monitor to map the dynamic indexes from the FUSIONHUB-PEPVPN::pepVpnRemotePeer table to the returned value then poll the FUSIONHUB-PEPVPN::pepVpnStatusConnectionState table for each instance. This has been working well as it saves me from trying to monitor the remote device wan connections independently and alerts us if the remote has gone entirely offline.
However what I have noticed is it seems like the SNMP table implementation has trouble with more that one peer failure within a single profile. When a second device drops out, the FusionHub drops the entire index.
Example: there are currently 2 remote peers offline, the first one to happen seems to become table index 0, while the second is just removed from the table:
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.0 = INTEGER: start(0)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.6826 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.22918 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.28925 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.33713 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.36928 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.38081 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.47166 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.49080 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.49592 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.51229 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.51326 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.52967 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.56837 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.59546 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.60557 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.62612 = INTEGER: connected(4)
FUSIONHUB-PEPVPN::pepVpnStatusConnectionState.2.63350 = INTEGER: connected(4)
and while the FusionHub staus page lists 19 peers in this profile, only 18 table entries are present.
I have only begun monitoring this way since we implemented the 6.3.2 beta firmware, so I’m not sure if it’s related to that or a bug in the snmp implementation.
As the universe is apparently trying to be helpful, I just lost another peer BR1 from the FusionHub and can confirm that table deletions continue after the first one:
I don’t think it’s a MIB problem as there is no issue with interpreting the OIDs, the issue appears to be that when a peer vpn connection is reset, the OID table re-indexes that device to x.0, where x is the profile index in the table. Then if the device does not re-connect it holds the .0 index so any further device disconnection can’t be re-indexed to 0 and is dropped out of the OID table entirely until the peer vpn is re-established and is given a new table index.
Sorry, about the lag I didn’t notice I wasn’t getting email updates on the new forum.
The problem seems to only occur when there are multiple connections defined under a single profile. As an example I have a FusionHub VM with 4 profiles, but one of those profiles is used by 12 BR1 endpoints. In your screenshot it appears you only have only a single connection defined in each profile, so the problem doesn’t occur as the index slot is available.
We monitor with zabbix, which makes use of shell snmpwalk and snmpget commands for polling.
