I’m looking into using Telegraf as an SNMP trap forwarder. Many existing trap forwarders run into issues when device / agent is reset because the Engine ID changes, and the trap forwarder stops receiving traps requiring the Engine ID to be re-registered on the trap forwarder manually. This is obviously not optimal.
The question is how does is the Engine ID implemented in the SNMP V3 Trap input plugin and can you predict what would happen if the agent (source) reset with a new Engine ID. Is manual intervention required? (I don’t yet have a lab to test this)
Hmm I’m not sure. Maybe @jpowers can provide an answer if he has time Thank you.
Off-hand I do not, but briefly looking at the code the engine ID is used as a tag with gosnmp version 3. Otherwise, I would not expect a change to affect collection.
@Hipska knows far more about the SNMP plugins than I do, maybe he could confirm?
As Josh said, it will just be a tag value. Nothing is done with it.
But, be aware there is no snmp_trap output, so it won’t be directly possible to use telegraf as a trap “forwarder” as in it cannot out of the box send/forward any traps…
Thanks for the info. This use case is sending the trap notifications to Kafka topics to be consumed by a variety subscribers like loggers, data lakes, event correlation platforms etc., so no need for a SNMP output plug.
In terms of Engine ID, I think some solutions used is to verify the identity of the agent to prevent spoofing. I assume that a changed Engine ID wouldn’t break the authentication encryption of the V3 traps?
No indeed. If really wanted you can add metric filtering by checking the engineID value and drop metrics containing a wrong ID…