So one of the big problems with Cisco and the snmp-server trap config is that it only sends once. As such, it's not quite in a compatible config with a trigger threshold for a rule for minor alerts that self-resolve in the span of a minute or so. (redundant system failover, etc.) Currently, the goal is to remove extraneous alerts that resolve themselves by design inside of 1-5 minutes. (e.g.: Paired routers on site - router A's provider hiccups and router B picks up the load 30 seconds later. Instead of getting and DOWN/UP pair of email alerts, Syslog just drops it)
With that, it looks like snmp-server inform looks like a better choice. That said, there's a bit of a hitch there in that the inform option both expects a response from the target server and I'm uncertain that the status will continue to be broadcast at a set interval until the status changes.
So, this is where things start meandering out to left field.
If Syslog Viewer doesn't bother sending replies to the Cisco device, then that plays into my hand as I actually want multiple alerts on the same problem over time from the Cisco device. If I set the number of retries and the timeout for each retry to a sufficient length, then I can say that if the Cisco device doesn't resolve itself by the time it's exhausted its retries then Syslog will fire off an alert.
...But is that even feasible?
