Skip to main content
gskneale
gskneale
New Member
June 13, 2013
Question

SNMP fgModel Support

  • June 13, 2013
  • 4 replies
  • 10060 views
Hello All, It seems that the fortinet - fnFortiGateMib - fgModel tree is not supported on all models. Specifically, I would suspect a query against a FWF40C for the OID .1.3.6.1.4.1.12356.101.1.411 to return something, but I may be wrong. Can anyone confirm that the OID returns data? Others that supposedly work are: fgt1000A: .1.3.6.1.4.1.12356.101.1.10001 fgt1240B: .1.3.6.1.4.1.12356.101.1.12400 fgt200B: .1.3.6.1.4.1.12356.101.1.2003 fgt310B: .1.3.6.1.4.1.12356.101.1.3002 fgt80C: .1.3.6.1.4.1.12356.101.1.800 fgt900F: .1.3.6.1.4.1.12356.101.1.8001 Any insight appreciated. Thanks in advance. Geoffrey

    4 replies

    emnoc
    emnoc
    New Member
    June 13, 2013
    .1.3.6.1.4.1.12356.101.1
    Does work for me. What are you trying to get? what version of code? What model? Have you ran snmpd debug? diag debug console diag debug app snmp 255 Than walk the tree or get the oid and see if it complains. BTW, I find the following oid is great for model type identification on older devices; e.g snmpget -c mycommunity -O ne -v2c xxx.xxxx.net .1.3.6.1.4.1.12356.1.3.0 .1.3.6.1.4.1.12356.1.3.0 = STRING: " FortiWiFi-60 3.00,build0730,080919" It provides you the model, OS family and build. One I' ve had problems with and snmp deals vdom and snmp issues. So if you have a model running vdoms, you should take that into consideration. And the following is better for newer devices; snmpget -c public -v2c 192.168.1.99 .1.3.6.1.4.1.12356.101.4.1.1.0 .1.3.6.1.4.1.12356.101.13.2.1.1.2.1 YMMV, but I would 1st check the OS and then run debug on the snmpd daemon while walking the tree. You could also just walk the tree and pipe it to grep; and look for the string that your looking for. snmpwalk -c myfgtatofc -v2c 10.10.12.92 .1.3.6.1.4.1.12356 | grep 310 adding a screenshot of my lab200A and I will do a 3040 and FWF60D later.
    gskneale
    gsknealeAuthor
    New Member
    June 13, 2013
    I have a FWF40C running FortiOS 4.3.14. When using the iReasoning MIB browser to get .1.3.6.1.4.1.12356.101.1 or .1.3.6.1.4.1.12356.101.1.411, it states there is no such object. Unfortunately, I am not sure what I am supposed to get. Should the query .1.3.6.1.4.1.12356.101.1 against a fgt1000A return a value of 10001? Or, should the query .1.3.6.1.4.1.12356.101.1.10001 against the same fgt1000A return 1? Alas, I do not have access the the models (note- the fgt900F should have been fgt800F) in the original post. The newer device strings work as expected. The older string did not. Thankfully, no VDOMs in place.
    emnoc
    emnoc
    New Member
    June 13, 2013
    Hmm. That oid does not response on FWF50B,60C or 310B that I queried. What version code are you running thru out your enterprise, or is it only one device 4.3.14 ? Have you tried other models? Have you download the fortinet.mib file from support.fortinet.com and check or install the mib file in a viewer? I' ll do my FWF60D here shortly, and post the output here, but here' s a FWF50B running 4.0 We just got shut out of my datacenter, so I can' t query a FGT3040B which is running 4.3.14. The oid might be available for only certain types of OSversion and Model types. Keep us posted, but you still have told us what/why you want response for that oid? if your looking for model/os type use any of the oid examples that I gave earlier. My scripter guide built some stupid nagios perl script that stripped off the model serial# and we archive the model types by location, model make, and then serial number. If I can find it, I' ll post that script here.
    emnoc
    emnoc
    New Member
    June 15, 2013
    OP I played around with my 60D which is the only thing I have on 5.0 and debug shows the following when you query that oid You can also debug the SNMP request also, using something like tshark.
    Terms & ConditionsAccessibility statement