This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

SNMP Trap marked for discard, doesn't

One of our switches has been spamming us with notifications that one of the 10G transceivers has a Rx power threshold violation. This is a false positive because the transceiver isn't made by the switch vendor although it functions perfectly, and I don't want to get these messages.

On the SW Trap Viewer, we have a rule that emails SNMP traps to the network admins. The Source IP is for the whole subnet, Trap Details is *, Conditions are blank, and the Alert Action is to e-mail.

I added a new rule to filter the messages we don't want. The Source IP is for the whole subnet, Trap Details is *THRESHOLD_VIOLATION*, Conditions are blank, and the Alert Action is to discard the trap. I placed this new rule above the existing rule.

Now, I am still getting e-mails for the threshold violation messages, but it notes that they are Marked for Discard. This seems cruel and unusual. Am I missing a step in the new rule that's supposed to filter these out, or do I need to modify the existing rule that sends e-mails on everything?

  • Did you manually create the rule?  If so, I'd say to right-click on the trap message on the trap in question and create the trap rule that way.  This way you're using the information directly from the trap to configure the rule to discard the trap.  Now, due to the fact that you are emailing it, it requires it to write it to the database, where as discarding prevents the write.  With it being marked, then these may clear out at the run of the next database maintenance.

    Regards,

    Matthew Harvey

  • I did manually create the rule. When I went back to the Trap Viewer to check what you suggested, I noticed that the traps aren't writing to the Current Traps page any longer (although I am still getting e-mails), so the rule appears to be working in that regard. When I right-click to create a rule off of one of the previous entries, it gives me a new rule with the condition of "SNMPv2-MIB:snmpTrapOID is equal to CISCO-SYSLOG-MIB:clogMessageGenerated." I don't want to filter out this OID entirely, as we get plenty of valid and useful traps from it other than the THRESHOLD_VIOLATION.

  • So from what you describe the discard is preventing new traps from writing.  If you are wanting to get rid of the other ones, I'd just allow DB maintenance to take care of it based on your retention settings.

  • The traps weren't writing to the trap viewer, but they were still coming to me as e-mails. The e-mails would even note that the traps were marked for discard.

    However...although I still believe the messages were a false positive due to a lack of any performance issue on the link, I just swapped the transceiver out with a spare on a hunch (I wasn't seeing these same messages on any of the other off-brand transceivers we installed) and the messages cleared up. So while I still don't have an explanation as to why I received e-mail alerts on traps that were supposed to be discarded, it's a moot point now (until the next time it happens, anyway).

  • If the rule to email was before the discard it took precedence.  So the email was sent letting you know the trap would be discarded then it was discarded.  Trap rules work in order based on where they fall on the list.

  • The discard rule was above the "e-mail everything" rule. My guess is that I would have needed to add something to the "e-mail everything" rule to make it "e-mail everything except discards," but I don't know how that would have been worded specificially.

  • "Marked for Discard" means that a trap rule processed the Discard Trap Message however, another trap rule has been processed to send an email. What you need to do is for the trap rule that has an Alert Action to Discard Trap Message, Add another Action and select "Stop Processing Trap Rules" so it won't proceed further to the other trap rule to send an email.