Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Exo
New Contributor

Timeout on snmpwalk

Hello,

 

I've noticed a strange problem on a new FortiOS 5.6.3, FortiGate 60E.

 

I'm trying to monitor, thanks to SNMP, my wan traffic Bandwidth. I'm using Centreon monitoring system.

The script that I used is working on other Fortigate (80D, 60D and 30E).

When I used this script i've got a "UNKNOWN: SNMP GET Request : Timeout" error.

 

When I do a "snmpwalk -v 2c -c my_community [my_public_ip_address]" I can go trough all the OIDs allways until this OID "EtherLike-MIB::dot3ControlInUnknownOpcodes.17". For exemple :

# snmpwalk -v 2c -c my_community [my_public_ip_address]
SNMPv2-MIB::sysDescr.0 = STRING:
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.12356.101.1.641
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (10257880) 1 day, 4:29:38.80
SNMPv2-MIB::sysContact.0 = STRING:

[...]

EtherLike-MIB::dot3ControlInUnknownOpcodes.13 = Counter32: 0
EtherLike-MIB::dot3ControlInUnknownOpcodes.14 = Counter32: 0
EtherLike-MIB::dot3ControlInUnknownOpcodes.15 = Counter32: 0
EtherLike-MIB::dot3ControlInUnknownOpcodes.16 = Counter32: 0
EtherLike-MIB::dot3ControlInUnknownOpcodes.17 = Counter32: 0
Timeout: No Response from [my_public_ip_address]

 

When I do a "snmpwalk -v 2c -c my_other_community [my_other_public_ip_address]" on my other FortiGate I can go trough all the OIDs whitout error.

 

All my other Centreon check (CPU, RAM, Session) on my 60E are working perfectly.

 

It's the only 60E Fortigate that i'll have, but my others FortiGate in 5.6.3 OS are working well.

The SNMP is enable and correctly configure. On my WAN interface the SNMP is enable : otherwise I think that I can't run a snmpwalk at all.

I don't think that my public interface is not working well because I'm always stuck on the same OID...

 

Is somebody know how to resolve this issue or have an idea ?

 

Thanks.

10 REPLIES 10
emnoc
Esteemed Contributor III

Q:

 

1: can you do this from a local SNMPhost

 

2:  is the unit in a cluster

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Exo
New Contributor

Hello,

 

Thanks for the reply.

 

This unit is not in a cluster.

 

You're right if I do the snmpwalk command from a local computer I can read all the OIDs.

Moreover I realise that I've the same problem with another brands but always with the same internet provider (french Orange connection).

Maybe it's some option with the box or the box itself who is dropping the query.

 

I 'm going to investigate on this point.

 

Thanks.

localhost
Contributor III

I have seen the same issue on other Fortigates as well. But unfortunately can't remember which model and forti os version :).

Definitely cluster and if I recall correctly we were accessing them over the internet as well.

 

As a workaround, I just added the traffic bandwith monitor manually using the snmp-index value, which you can find under #config system interface.

In PRTG network monitor it is as easy as copying an existing bandwith sensor from a different Fortigate and changing the snmp index.

emnoc
Esteemed Contributor III

Hey suggestion did you try a different  snmp-client? or  v1 or v3 ?

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
localhost

Hi

 

So last week I encountered the same issue on two different 400D cluster. One running 5.4.8 and the other 5.6.3.

Definitely looks like a bug to me, I opened a ticket at Fortinet. Let's see what comes out.

 

Happens to all SNMP versions 1, 2c and 3.

SNMP requests are going over the internal network only.

 

C:\Program Files (x86)\netsnmp\bin>snmpwalk.exe -v 2c -O0eEnU -Cc -c SNMP-Community 192.168.1.1 1.3.6.1.2.1.31.1.1.1.1
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: mgmt1
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: port11
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: port11
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: port11
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: port11
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: port11

 

- endless loop -

 

C:\Program Files (x86)\netsnmp\bin>snmpwalk.exe -v 2c -O0eEnU -Cc -c SNMP-Community 192.168.2.1 1.3.6.1.2.1.31.1.1.1.1
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: mgmt1
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: port1
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: port1
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: port1
.1.3.6.1.2.1.31.1.1.1.1.1 = STRING: port1

 

- endless loop -

 

 

 

emnoc
Esteemed Contributor III

Okay let's do a few things

 

1: rule out the snmpclient

2: run diag debug  enable         diag debug  application snmpd -1

 

Does the fortigate show the   snmp traffic and does it stop or die?

 

Ken

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
localhost

Don't think this is going to help you a lot.

 

Find attached the diag debug command. I removed all lines with community names and ip addresses.

 

Command while running debug: C:\Program Files (x86)\netsnmp\bin>snmpwalk.exe -v 2c -O0eEnU -Cc -c CommunityName  192.168.1.1 1.3.6.1.2.1.31.1.1.1.1

emnoc
Esteemed Contributor III

Try to re-enable the SNMP configuration unset allowacecs snmp and re-apply

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
localhost

In my case the problem were two interfaces with the same snmp-index. After making sure all snmp-index are unique, snmpwalk works fine again.

 

config system interface     edit "mgmt1"         set vdom "root"         set ip 192.168.1.99 255.255.255.0         set allowaccess ping https http fgfm         set type physical         set dedicated-to management         set snmp-index 1     next end

config system interface     edit "port11"         set vdom "root"         set vlanforward enable         set type physical         set snmp-index 1     next end

I wonder how this happened and why there is no sanity-check for this.

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors