Recieving SNMP Traps
Recieving SNMP Traps
Hey Gents, I apologize in advance for being an absolute newbie in regards to SNMP...Like everyone else, and other posts, I have followed this guide: https://assets.nagios.com/downloads/nag ... ios_XI.pdf but frankly it was pretty much all gibberish to me. Nevertheless I finished the the guide and here is where I am at...
I am trying to monitor a couple of Liebert UPS's using SNMP; If the circuit providing power to the UPS's fails the backup generator will kick-in after 10 seconds. So SNMP is useless to me here unless Nagios happens to runs its check at that exact time. Therefor I started working on SNMP traps. Picture just for reference:
In that picture above, the last service "SNMP Traps" is what I need to work on. I could already have this right but testing is not something I can easily. I was testing by initiating self-tests but then I get the really long trap message. Is it possible that this MIB is just not in there?
SERVICE ALERT: Core UPS Rack 3;SNMP Traps;OK;HARD;1;This notification is sent each time a condition is inserted into the 14 SNMPv2-SMI::enterprises.476.1.42.3.2.1.71 0:1:47:16.99 / lgpConditionId.14 (UNSIGNED32):14 lgpConditionDescr.14 (OBJECTID):SNMPv2-SMI::enterprises.476.1.42.3.2.1.71 lgpConditionTime.14 (TICKS):0:1:47:16.99
I believe I have uploaded the MIB's correctly..? It won't let me add a 4th picture but I can see them in the MIB's list, I also had the checkbox for process trap as well.
I guess my main questions are how do I make the traps process as critical so it will generate an alert and not be so lengthy? Any other general posts anyone could refer to me and newbie friendly, I would appreciate it.
I have attached the config files.
[root@NAGIOS snmp]# cat snmptrapd.conf
disableAuthorization yes
traphandle default /usr/sbin/snmptthandler
Nagios XI 5.4.4
CentoOS 6.8
VMware
I am trying to monitor a couple of Liebert UPS's using SNMP; If the circuit providing power to the UPS's fails the backup generator will kick-in after 10 seconds. So SNMP is useless to me here unless Nagios happens to runs its check at that exact time. Therefor I started working on SNMP traps. Picture just for reference:
In that picture above, the last service "SNMP Traps" is what I need to work on. I could already have this right but testing is not something I can easily. I was testing by initiating self-tests but then I get the really long trap message. Is it possible that this MIB is just not in there?
SERVICE ALERT: Core UPS Rack 3;SNMP Traps;OK;HARD;1;This notification is sent each time a condition is inserted into the 14 SNMPv2-SMI::enterprises.476.1.42.3.2.1.71 0:1:47:16.99 / lgpConditionId.14 (UNSIGNED32):14 lgpConditionDescr.14 (OBJECTID):SNMPv2-SMI::enterprises.476.1.42.3.2.1.71 lgpConditionTime.14 (TICKS):0:1:47:16.99
I believe I have uploaded the MIB's correctly..? It won't let me add a 4th picture but I can see them in the MIB's list, I also had the checkbox for process trap as well.
I guess my main questions are how do I make the traps process as critical so it will generate an alert and not be so lengthy? Any other general posts anyone could refer to me and newbie friendly, I would appreciate it.
I have attached the config files.
[root@NAGIOS snmp]# cat snmptrapd.conf
disableAuthorization yes
traphandle default /usr/sbin/snmptthandler
Nagios XI 5.4.4
CentoOS 6.8
VMware
You do not have the required permissions to view the files attached to this post.
-
npolovenko
- Support Tech
- Posts: 3457
- Joined: Mon May 15, 2017 5:00 pm
Re: Recieving SNMP Traps
Hello, @ahoward12. Based on the message you're getting the MIB file that you uploaded in XI is not complete. In particular it's missing object identifiers(OIDS 476.1.42.3.2.1.71) with object name "lgpConditionBatteryTestInProgress". You need to contact the UPS manufacturer for the specific MIB file that has all the OID's required for SNMP.
When you get the right MIB, in your XI web interface go to admin, and then manage MIBs in the left column on the bottom. Update the new MIB and don't forget to check the "Process trap" box.
And before you do that, delete the old entry in snmptt.conf. Delete everything from this line to the bottom of the file.
A very good tutorial on SNMP traps is on the Nagios KB: https://support.nagios.com/kb/article.php?id=77 It will help you set up a critical status for your check as well.
When you get the right MIB, in your XI web interface go to admin, and then manage MIBs in the left column on the bottom. Update the new MIB and don't forget to check the "Process trap" box.
And before you do that, delete the old entry in snmptt.conf. Delete everything from this line to the bottom of the file.
Code: Select all
MIB: LIEBERT-GP-REGISTRATION-MIB (file:/usr/share/snmp/mibs/LIEBERT_GP_REG.MIB) converted on Fri Oct 13 09:54:26 2017 using snmpttconvertmib v1.4beta2As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Re: Recieving SNMP Traps
Hey, I did what you said. I deleted them from the GUI and then deleted them from snmptt.conf. I re-downloaded them from the website. Once I start to upload them several of them give me errors:
MIB is added, but is does not contain any TRAP-TYPE definitions, so no traps were added, even though user input said there should be traps specified. < I don't think this is an issue so mach as it just telling me there are no "traps" in it.
or
Uploaded file had one or more failed translations when converting to snmptt mib. < This is when I try and upload the LIEBERT_GP_NOTIFY.MIB FILE. I am no expert by any means but when I just open it in vi or notepad ++ it has the checks I am looking for. Is there something wrong the MIB file or how it is being processed?
I attached all of the MIB's..
MIB is added, but is does not contain any TRAP-TYPE definitions, so no traps were added, even though user input said there should be traps specified. < I don't think this is an issue so mach as it just telling me there are no "traps" in it.
or
Uploaded file had one or more failed translations when converting to snmptt mib. < This is when I try and upload the LIEBERT_GP_NOTIFY.MIB FILE. I am no expert by any means but when I just open it in vi or notepad ++ it has the checks I am looking for. Is there something wrong the MIB file or how it is being processed?
I attached all of the MIB's..
You do not have the required permissions to view the files attached to this post.
-
npolovenko
- Support Tech
- Posts: 3457
- Joined: Mon May 15, 2017 5:00 pm
Re: Recieving SNMP Traps
@ahoward12, By default, Net SNMP will not include all MIB files when they are executed. To have Net SNMP search through and include all MIB files:
Create the file /etc/snmp/snmp.conf, and put into it:
mibs +ALL
After that restart your snmp service:
Create the file /etc/snmp/snmp.conf, and put into it:
mibs +ALL
After that restart your snmp service:
Code: Select all
service snmptt restartAs of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Re: Recieving SNMP Traps
I think you are misunderstanding. Here is a picture:
You do not have the required permissions to view the files attached to this post.
-
npolovenko
- Support Tech
- Posts: 3457
- Joined: Mon May 15, 2017 5:00 pm
Re: Recieving SNMP Traps
@ahoward12, I think those definitions could've already been imported with previous MIB files. That error that you're seeing could be XI's way of telling that.
Try to upload that file without checking "process trap".
And then go ahead with my instructions in the previous post.
Try to upload that file without checking "process trap".
And then go ahead with my instructions in the previous post.
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Re: Recieving SNMP Traps
Ok, I did what you said and it is not working at all.
Can we take another approach to this? I feel like I was fairly close to having this work prior to your first post. So, assume I am back to EXACTLY where I was with my initial post. Can you give me a step by step on what you would like me to do.
Did you mean /etc/snmp/snmptt.conf? Either way I have tried both and it does nothing. Once I restart the service the file continues to stay empty no matter what I do.@ahoward12, By default, Net SNMP will not include all MIB files when they are executed. To have Net SNMP search through and include all MIB files:
Create the file /etc/snmp/snmp.conf, and put into it:
mibs +ALL
Can we take another approach to this? I feel like I was fairly close to having this work prior to your first post. So, assume I am back to EXACTLY where I was with my initial post. Can you give me a step by step on what you would like me to do.
Re: Recieving SNMP Traps
What do you mean by this from your post
"Once I restart the service the file continues to stay empty no matter what I do."
What are you restarting and which file is empty?
One thing to do is in the LgpMibDistribution_12.4 (1).zip file you posted, extract all of the MIB files and Upload them to the Nagios XI server by going to the Admin > Manage MIB's menu but do NOT check the Process Trap box.
Try that and see if that works.
"Once I restart the service the file continues to stay empty no matter what I do."
What are you restarting and which file is empty?
One thing to do is in the LgpMibDistribution_12.4 (1).zip file you posted, extract all of the MIB files and Upload them to the Nagios XI server by going to the Admin > Manage MIB's menu but do NOT check the Process Trap box.
Try that and see if that works.
Be sure to check out our Knowledgebase for helpful articles and solutions!
Re: Recieving SNMP Traps
Hey tgriep,
1) Following your directions, I deleted all of the current MIB's in question. Following that I removed them from my snmptt.conf file
I checked the /var/log/snmptt/snmptt.log and found nothing correlating to the test. I checked the snmpttunknown.log and found these events but no trap was ever recognized by Nagios:
As well, after all of that, here is my snmptt.conf:
I appreciate all of the help and my ignorance regarding SNMP Traps. Please let me know if you need anything else from me.
I meant once I cleared out my /etc/snmp/snmptt.conf and ran service snmptt restart re-added the MIB's, my /etc/snmp/snmptt.conf continued to to be lacking any sort of resemblance to the new MIB's. I may have had a lack of understanding on this part.What do you mean by this from your post
"Once I restart the service the file continues to stay empty no matter what I do."
1) Following your directions, I deleted all of the current MIB's in question. Following that I removed them from my snmptt.conf file
2) I re-uploaded all of the MIB's and did not check the process trap on any of them. I uploaded them in this order following the "readme" instructions:@npolovenko: And before you do that, delete the old entry in snmptt.conf. Delete everything from this line to the bottom of the file.
MIB: LIEBERT-GP-REGISTRATION-MIB (file:/usr/share/snmp/mibs/LIEBERT_GP_REG.MIB) converted on Fri Oct 13 09:54:26 2017 using snmpttconvertmib v1.4beta2
3) Once I did that, I re-enabled the SNMP trap service. I triggered an event by running a self test on the UPS itself. I watched the Nagios event log, and didn't get anything for the trap service. My other SNMP services worked, just not the trap service.Load/compile the twelve individual MIB files onto your NMS in
the following order:
LIEBERT_GP_REG.MIB (Load First)
LIEBERT_GP_AGENT.MIB
LIEBERT_GP_COND.MIB
LIEBERT_GP_CONTROLLER.MIB
LIEBERT_GP_NOTIFY.MIB
LIEBERT_GP_SYSTEM.MIB
LIEBERT_GP_ENV.MIB
LIEBERT_GP_PDU.MIB
LIEBERT_GP_POWER.MIB
LIEBERT_GP_FLEXIBLE.MIB
LIEBERT_GP_FLEXIBLE_COND.MIB
RFC1628_UPS_MIB.MIB (Load Last)
It is important that the MIB files be loaded in the correct
order.
I checked the /var/log/snmptt/snmptt.log and found nothing correlating to the test. I checked the snmpttunknown.log and found these events but no trap was ever recognized by Nagios:
Code: Select all
Thu Oct 19 08:50:01 2017: Unknown trap (.1.3.6.1.2.1.33.2.0.3) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:56:56.38
Value 3: .1.3.6.1.2.1.33.2.0.3
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.2.1.33.2
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.33.1.6.2.1.1.1=1
Ent Value 1: .1.3.6.1.2.1.33.1.6.2.1.2.1=UPS-MIB::upsAlarmTestInProgress
Thu Oct 19 08:50:02 2017: Unknown trap (.1.3.6.1.2.1.33.2.0.3) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:56:56.39
Value 3: .1.3.6.1.2.1.33.2.0.3
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.2.1.33.2
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.33.1.6.2.1.1.1=1
Ent Value 1: .1.3.6.1.2.1.33.1.6.2.1.2.1=UPS-MIB::upsAlarmTestInProgress
Thu Oct 19 08:50:02 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.3.0.1) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:56:56.39
Value 3: .1.3.6.1.4.1.476.1.42.3.3.0.1
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.3
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.476.1.42.3.2.3.1.1.2=2
Ent Value 1: .1.3.6.1.4.1.476.1.42.3.2.3.1.2.2=LIEBERT-GP-CONDITIONS-MIB::lgpConditionBatteryTestInProgress
Ent Value 2: .1.3.6.1.4.1.476.1.42.3.2.3.1.3.2=1:13:57:18.75
Thu Oct 19 08:50:02 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.3.0.1) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:56:56.39
Value 3: .1.3.6.1.4.1.476.1.42.3.3.0.1
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.3
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.476.1.42.3.2.3.1.1.2=2
Ent Value 1: .1.3.6.1.4.1.476.1.42.3.2.3.1.2.2=LIEBERT-GP-CONDITIONS-MIB::lgpConditionBatteryTestInProgress
Ent Value 2: .1.3.6.1.4.1.476.1.42.3.2.3.1.3.2=1:13:57:18.75
Thu Oct 19 08:50:02 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.7.8.0.1) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:56:56.40
Value 3: .1.3.6.1.4.1.476.1.42.3.7.8.0.1
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.7.8
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.1.3=1:13:57:18.78
Ent Value 1: .1.3.6.1.4.1.476.1.42.3.7.7=Active:Battery Under Test
Thu Oct 19 08:50:02 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.7.8.0.1) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:56:56.40
Value 3: .1.3.6.1.4.1.476.1.42.3.7.8.0.1
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.7.8
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.1.3=1:13:57:18.78
Ent Value 1: .1.3.6.1.4.1.476.1.42.3.7.7=Active:Battery Under Test
Thu Oct 19 08:50:17 2017: Unknown trap (.1.3.6.1.2.1.33.2.0.4) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:57:12.92
Value 3: .1.3.6.1.2.1.33.2.0.4
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.2.1.33.2
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.33.1.6.2.1.1.1=1
Ent Value 1: .1.3.6.1.2.1.33.1.6.2.1.2.1=UPS-MIB::upsAlarmTestInProgress
Thu Oct 19 08:50:18 2017: Unknown trap (.1.3.6.1.2.1.33.2.0.4) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:57:12.92
Value 3: .1.3.6.1.2.1.33.2.0.4
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.2.1.33.2
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.33.1.6.2.1.1.1=1
Ent Value 1: .1.3.6.1.2.1.33.1.6.2.1.2.1=UPS-MIB::upsAlarmTestInProgress
Thu Oct 19 08:50:18 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.3.0.2) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:57:12.93
Value 3: .1.3.6.1.4.1.476.1.42.3.3.0.2
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.3
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.476.1.42.3.2.3.1.1.2=2
Ent Value 1: .1.3.6.1.4.1.476.1.42.3.2.3.1.2.2=LIEBERT-GP-CONDITIONS-MIB::lgpConditionBatteryTestInProgress
Ent Value 2: .1.3.6.1.4.1.476.1.42.3.2.3.1.3.2=1:13:57:18.75
Thu Oct 19 08:50:18 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.3.0.2) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:57:12.93
Value 3: .1.3.6.1.4.1.476.1.42.3.3.0.2
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.3
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.476.1.42.3.2.3.1.1.2=2
Ent Value 1: .1.3.6.1.4.1.476.1.42.3.2.3.1.2.2=LIEBERT-GP-CONDITIONS-MIB::lgpConditionBatteryTestInProgress
Ent Value 2: .1.3.6.1.4.1.476.1.42.3.2.3.1.3.2=1:13:57:18.75
Thu Oct 19 08:50:18 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.7.8.0.2) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:57:12.94
Value 3: .1.3.6.1.4.1.476.1.42.3.7.8.0.2
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.7.8
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.1.3=1:13:57:35.28
Ent Value 1: .1.3.6.1.4.1.476.1.42.2.1.6=1
Thu Oct 19 08:50:18 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.7.8.0.2) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:57:12.94
Value 3: .1.3.6.1.4.1.476.1.42.3.7.8.0.2
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.7.8
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.1.3=1:13:57:35.28
Ent Value 1: .1.3.6.1.4.1.476.1.42.2.1.6=1
Thu Oct 19 08:50:18 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.7.8.0.1) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:57:12.94
Value 3: .1.3.6.1.4.1.476.1.42.3.7.8.0.1
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.7.8
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.1.3=1:13:57:35.29
Ent Value 1: .1.3.6.1.4.1.476.1.42.3.7.7=Message:System Return to Normal
Thu Oct 19 08:50:18 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.7.8.0.1) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:57:12.95
Value 3: .1.3.6.1.4.1.476.1.42.3.7.8.0.1
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.7.8
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.1.3=1:13:57:35.29
Ent Value 1: .1.3.6.1.4.1.476.1.42.3.7.7=Message:System Return to Normal
Thu Oct 19 08:50:19 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.7.8.0.1) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:57:12.95
Value 3: .1.3.6.1.4.1.476.1.42.3.7.8.0.1
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.7.8
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.1.3=1:13:57:35.31
Ent Value 1: .1.3.6.1.4.1.476.1.42.3.7.7=Cleared:Battery Under Test
Thu Oct 19 08:50:19 2017: Unknown trap (.1.3.6.1.4.1.476.1.42.3.7.8.0.1) received from 10.10.99.245 at:
Value 0: 10.10.99.245
Value 1: 10.10.99.245
Value 2: 1:13:57:12.95
Value 3: .1.3.6.1.4.1.476.1.42.3.7.8.0.1
Value 4: 10.10.99.245
Value 5: cafaro
Value 6: .1.3.6.1.4.1.476.1.42.3.7.8
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.2.1.1.3=1:13:57:35.31
Ent Value 1: .1.3.6.1.4.1.476.1.42.3.7.7=Cleared:Battery Under Test
Code: Select all
#[root@NAGIOS snmp]# cat snmptt.conf
#
#
#
EVENT coldStart .1.3.6.1.6.3.1.1.5.1 "Status Events" Normal
FORMAT Device reinitialized (coldStart)
#EXEC qpage -f TRAP notifygroup1 "Device reinitialized (coldStart)"
SDESC
A coldStart trap signifies that the SNMPv2 entity, acting
in an agent role, is reinitializing itself and that its
configuration may have been altered.
EDESC
#
#
#
EVENT warmStart .1.3.6.1.6.3.1.1.5.2 "Status Events" Normal
FORMAT Device reinitialized (warmStart)
#EXEC qpage -f TRAP notifygroup1 "Device reinitialized (warmStart)"
SDESC
A warmStart trap signifies that the SNMPv2 entity, acting
in an agent role, is reinitializing itself such that its
configuration is unaltered.
EDESC
#
#
#
EVENT linkDown .1.3.6.1.6.3.1.1.5.3 "Status Events" Normal
FORMAT Link down on interface $1. Admin state: $2. Operational state: $3
#EXEC qpage -f TRAP notifygroup1 "Link down on interface $1. Admin state: $2. Operational state: $3"
SDESC
A linkDown trap signifies that the SNMP entity, acting in
an agent role, has detected that the ifOperStatus object for
one of its communication links is about to enter the down
state from some other state (but not from the notPresent
state). This other state is indicated by the included value
of ifOperStatus.
EDESC
#
#
#
EVENT linkUp .1.3.6.1.6.3.1.1.5.4 "Status Events" Normal
FORMAT Link up on interface $1. Admin state: $2. Operational state: $3
#EXEC qpage -f TRAP notifygroup1 "Link up on interface $1. Admin state: $2. Operational state: $3"
SDESC
A linkUp trap signifies that the SNMP entity, acting in an
agent role, has detected that the ifOperStatus object for
one of its communication links left the down state and
transitioned into some other state (but not into the
notPresent state). This other state is indicated by the
included value of ifOperStatus.
EDESC
#
#
#
EVENT authenticationFailure .1.3.6.1.6.3.1.1.5.5 "Status Events" Normal
FORMAT SNMP athentication failure
#EXEC qpage -f TRAP notifygroup1 "SNMP authentication failure"
SDESC
An authenticationFailure trap signifies that the SNMPv2
entity, acting in an agent role, has received a protocol
message that is not properly authenticated. While all
implementations of the SNMPv2 must be capable of generating
this trap, the snmpEnableAuthenTraps object indicates
whether this trap will be generated.
EDESC
#
#
#
#
MIB: FORTINET-FORTIGATE-MIB (file:/usr/share/snmp/mibs/FORTINET-FORTIGATE-MIB.mib) converted on Thu May 11 17:49:25 2017 using snmpttconvertmib v1.4beta2
#
#
#
#
MIB: FORTINET-CORE-MIB (file:/usr/share/snmp/mibs/FORTINET-CORE-MIB.mib) converted on Wed May 17 16:28:53 2017 using snmpttconvertmib v1.4beta2
#
#
#
EVENT fnTrapCpuThreshold .1.3.6.1.4.1.12356.100.1.3.0.101 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates that the CPU usage has exceeded the configured threshold.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapMemThreshold .1.3.6.1.4.1.12356.100.1.3.0.102 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates memory usage has exceeded the configured threshold.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapLogDiskThreshold .1.3.6.1.4.1.12356.100.1.3.0.103 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Log disk usage has exceeded the configured threshold. Only available
on devices with log disks.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapTempHigh .1.3.6.1.4.1.12356.100.1.3.0.104 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
A temperature sensor on the device has exceeded its threshold.
Not all devices have thermal sensors. See manual for specifications.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapVoltageOutOfRange .1.3.6.1.4.1.12356.100.1.3.0.105 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Power levels have fluctuated outside of normal levels. Not all devices
have voltage monitoring instrumentation. See manual for specifications.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapPowerSupplyFailure .1.3.6.1.4.1.12356.100.1.3.0.106 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Power supply failure detected. Not available on all models. Available
on some devices which support redundant power supplies. See manual
for specifications.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapAmcIfBypassMode .1.3.6.1.4.1.12356.100.1.3.0.107 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
An AMC interface entered bypass mode. Available on models with an AMC
expansion slot. Used with the ASM-CX4 and ASM-FX2 cards.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapFanFailure .1.3.6.1.4.1.12356.100.1.3.0.108 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
A fan failure has been detected. Not all devices have fan sensors.
See manual for specifications.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapIpChange .1.3.6.1.4.1.12356.100.1.3.0.201 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates that the IP address of the specified interface has been changed.
Variables:
1: fnSysSerial
2: sysName
3: ifIndex
EDESC
#
#
#
EVENT fnTrapTest .1.3.6.1.4.1.12356.100.1.3.0.999 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Trap sent for diagnostic purposes by an administrator.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
#
MIB: FORTINET-CORE-MIB (file:/usr/share/snmp/mibs/FORTINET-CORE-MIB.txt) converted on Fri May 19 08:46:35 2017 using snmpttconvertmib v1.4beta2
#
#
#
EVENT fnTrapCpuThreshold .1.3.6.1.4.1.12356.100.1.3.0.101 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates that the CPU usage has exceeded the configured threshold.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapMemThreshold .1.3.6.1.4.1.12356.100.1.3.0.102 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates memory usage has exceeded the configured threshold.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapLogDiskThreshold .1.3.6.1.4.1.12356.100.1.3.0.103 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Log disk usage has exceeded the configured threshold. Only available
on devices with log disks.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapTempHigh .1.3.6.1.4.1.12356.100.1.3.0.104 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
A temperature sensor on the device has exceeded its threshold.
Not all devices have thermal sensors. See manual for specifications.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapVoltageOutOfRange .1.3.6.1.4.1.12356.100.1.3.0.105 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Power levels have fluctuated outside of normal levels. Not all devices
have voltage monitoring instrumentation. See manual for specifications.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapPowerSupplyFailure .1.3.6.1.4.1.12356.100.1.3.0.106 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Power supply failure detected. Not available on all models. Available
on some devices which support redundant power supplies. See manual
for specifications.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapAmcIfBypassMode .1.3.6.1.4.1.12356.100.1.3.0.107 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
An AMC interface entered bypass mode. Available on models with an AMC
expansion slot. Used with the ASM-CX4 and ASM-FX2 cards.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapFanFailure .1.3.6.1.4.1.12356.100.1.3.0.108 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
A fan failure has been detected. Not all devices have fan sensors.
See manual for specifications.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fnTrapIpChange .1.3.6.1.4.1.12356.100.1.3.0.201 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates that the IP address of the specified interface has been changed.
Variables:
1: fnSysSerial
2: sysName
3: ifIndex
EDESC
#
#
#
EVENT fnTrapTest .1.3.6.1.4.1.12356.100.1.3.0.999 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Trap sent for diagnostic purposes by an administrator.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
#
MIB: FORTINET-FORTIGATE-MIB (file:/usr/share/snmp/mibs/FORTINET-FORTIGATE-MIB.txt) converted on Fri May 19 08:46:45 2017 using snmpttconvertmib v1.4beta2
#
#
#
EVENT fgTrapVpnTunUp .1.3.6.1.4.1.12356.101.2.0.301 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates that the specified VPN tunnel has been brought up.
Variables:
1: fnSysSerial
2: sysName
3: fgVpnTrapLocalGateway
4: fgVpnTrapRemoteGateway
5: fgVpnTrapPhase1Name
EDESC
#
#
#
EVENT fgTrapVpnTunDown .1.3.6.1.4.1.12356.101.2.0.302 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The specified VPN tunnel has been brought down.
Variables:
1: fnSysSerial
2: sysName
3: fgVpnTrapLocalGateway
4: fgVpnTrapRemoteGateway
5: fgVpnTrapPhase1Name
EDESC
#
#
#
EVENT fgTrapHaSwitch .1.3.6.1.4.1.12356.101.2.0.401 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The specified cluster member has transitioned from a slave role to a master role.
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fgTrapHaStateChange .1.3.6.1.4.1.12356.101.2.0.402 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Trap being sent when the HA cluster
member changes its state
Variables:
1: fnSysSerial
EDESC
#
#
#
EVENT fgTrapHaHBFail .1.3.6.1.4.1.12356.101.2.0.403 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The heartbeat device failure count has exceeded the configured threshold.
Variables:
1: fnSysSerial
EDESC
#
#
#
EVENT fgTrapHaMemberDown .1.3.6.1.4.1.12356.101.2.0.404 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The specified device (by serial number) is moving to a down state.
Variables:
1: fnSysSerial
EDESC
#
#
#
EVENT fgTrapHaMemberUp .1.3.6.1.4.1.12356.101.2.0.405 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
A new cluster member has joined the cluster.
Variables:
1: fnSysSerial
EDESC
#
#
#
EVENT fgTrapIpsSignature .1.3.6.1.4.1.12356.101.2.0.503 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
An IPS signature has been triggered
Variables:
1: fnSysSerial
2: sysName
3: fgIpsTrapSigId
4: fgIpsTrapSrcIp
5: fgIpsTrapSigMsg
EDESC
#
#
#
EVENT fgTrapIpsAnomaly .1.3.6.1.4.1.12356.101.2.0.504 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
An IPS anomaly has been detected
Variables:
1: fnSysSerial
2: sysName
3: fgIpsTrapSigId
4: fgIpsTrapSrcIp
5: fgIpsTrapSigMsg
EDESC
#
#
#
EVENT fgTrapIpsPkgUpdate .1.3.6.1.4.1.12356.101.2.0.505 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The IPS signature database has been updated
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fgTrapIpsFailOpen .1.3.6.1.4.1.12356.101.2.0.506 "Status Events" Normal
FORMAT The IPS network buffer is full $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "The IPS network buffer is full $*"
SDESC
The IPS network buffer is full
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fgTrapAvVirus .1.3.6.1.4.1.12356.101.2.0.601 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
A virus has been detected by the anti-virus engine
Variables:
1: fnSysSerial
2: sysName
3: fgAvTrapVirName
EDESC
#
#
#
EVENT fgTrapAvOversize .1.3.6.1.4.1.12356.101.2.0.602 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
An over-sized file has been detected by the anti-virus engine
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fgTrapAvPattern .1.3.6.1.4.1.12356.101.2.0.603 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The anti-virus engine has blocked a file because it matched a configured pattern
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fgTrapAvFragmented .1.3.6.1.4.1.12356.101.2.0.604 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The anti-virus engine has detected a fragmented file
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fgTrapAvEnterConserve .1.3.6.1.4.1.12356.101.2.0.605 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The anti-virus engine has entered conservation mode due to low memory conditions
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fgTrapAvBypass .1.3.6.1.4.1.12356.101.2.0.606 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The anti-virus engine has been bypassed due to conservation mode
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fgTrapAvOversizePass .1.3.6.1.4.1.12356.101.2.0.607 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
An over-sized file has been detected,
but has been passed due to configuration
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fgTrapAvOversizeBlock .1.3.6.1.4.1.12356.101.2.0.608 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
An over-sized file has been detected
and has been blocked
Variables:
1: fnSysSerial
2: sysName
EDESC
#
#
#
EVENT fgTrapFazDisconnect .1.3.6.1.4.1.12356.101.2.0.701 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The device has been disconnected from the FortiAnalyzer.
Variables:
1: fnSysSerial
EDESC
#
#
#
EVENT fgTrapWcApUp .1.3.6.1.4.1.12356.101.2.0.801 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates that the specified AP is up.
Variables:
1: fnSysSerial
2: sysName
3: fgWcApVdom
4: fgWcApSerial
5: fgWcApName
EDESC
#
#
#
EVENT fgTrapWcApDown .1.3.6.1.4.1.12356.101.2.0.802 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates that the specified AP is down.
Variables:
1: fnSysSerial
2: sysName
3: fgWcApVdom
4: fgWcApSerial
5: fgWcApName
EDESC
#
#
#
EVENT fgTrapFcSwUp .1.3.6.1.4.1.12356.101.2.0.901 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates that the specified switch controller session is up.
Variables:
1: fnSysSerial
2: sysName
3: fgFcSwVdom
4: fgFcSwSerial
5: fgFcSwName
EDESC
#
#
#
EVENT fgTrapFcSwDown .1.3.6.1.4.1.12356.101.2.0.902 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates that the specified switch controller session is down.
Variables:
1: fnSysSerial
2: sysName
3: fgFcSwVdom
4: fgFcSwSerial
5: fgFcSwName
EDESC
#
#
#
EVENT fgFmTrapDeployComplete .1.3.6.1.4.1.12356.101.6.0.1000 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates when deployment of a new configuration has been completed. Used for verification by FortiManager.
Variables:
1: fnSysSerial
EDESC
#
#
#
EVENT fgFmTrapDeployInProgress .1.3.6.1.4.1.12356.101.6.0.1002 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Indicates that a configuration change was not immediate and that the change is currently in progress. Used for verification by FortiManager.
Variables:
1: fnSysSerial
EDESC
#
#
#
EVENT fgFmTrapConfChange .1.3.6.1.4.1.12356.101.6.0.1003 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
The device configuration has been changed by something other than the managing FortiManager device.
Variables:
1: fnSysSerial
EDESC
#
#
#
EVENT fgFmTrapIfChange .1.3.6.1.4.1.12356.101.6.0.1004 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
Trap is sent to the managing FortiManager if an interface IP is changed
Variables:
1: fnSysSerial
2: ifName
3: fgManIfIp
4: fgManIfMask
5: fgManIfIp6
EDESC
#
#
#
EVENT fgTrapServerLoadBalanceRealServerDown .1.3.6.1.4.1.12356.101.2.0.1101 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
One of servers in a Server Load Balance group goes down.
Variables:
1: fnSysSerial
2: sysName
3: fgServerLoadBalanceRealServerAddress
4: fgServerLoadBalanceVirtualServerName
EDESC
#
#
#
EVENT fgTrapDeviceNew .1.3.6.1.4.1.12356.101.2.0.1201 "Status Events" Normal
FORMAT $*
EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "$*"
SDESC
A new device is found.
Variables:
1: fnSysSerial
2: sysName
3: ifIndex
4: fgVdEntIndex
5: fgDeviceCreated
6: fgDeviceLastSeen
7: fgDeviceMacAddress
EDESC
#
#
Re: Recieving SNMP Traps
Thanks for the info, especially the info from the unknown log. That Unknown OID is included in the RFC1628_UPS_MIB.MIB file and that file will have to be re-uploaded to the Nagios Server but this time, the Process Traps box needs to be checked.
Doing this will add back the entries in to the /etc/snmp/snmptt.conf file and the snmptt daemon will be able to translate that OID as the settings will be restored.
Then, generate that Trap from the device and you should see it show up in the /var/log/snmptt/snmptt.log file.
If you do, login to the XI GUI and go to the Admin > Unconfigured Objects menu, you should see the trap there and it has to be configured by clicking on the Blue arrow.
After configuring it, it should be received by XI automatically.
Doing this will add back the entries in to the /etc/snmp/snmptt.conf file and the snmptt daemon will be able to translate that OID as the settings will be restored.
Then, generate that Trap from the device and you should see it show up in the /var/log/snmptt/snmptt.log file.
If you do, login to the XI GUI and go to the Admin > Unconfigured Objects menu, you should see the trap there and it has to be configured by clicking on the Blue arrow.
After configuring it, it should be received by XI automatically.
Be sure to check out our Knowledgebase for helpful articles and solutions!