We’re using the helper functions to add trap destinations: NotificationOriginator::add_v2_trap_destination and NotificationOriginator::add_v3_trap_destination.
Now, with respect for the repeatedly expressed: The add_vX_trap… methods are oversimplified examples only. Never try to use this for something in production!
We see at the end of these functions that they call: snmpTargetAddrEntry::add_entry
However, the first argument passed to add_entry is the address, UdpAddress(addr), and we’re trying to add the same address for both SNMP versions.
The first add_entry parameter, name, is used as the key for the table row.
The outcome of this is that whichever of the add_vx_trap calls is made second will fail.
It is not by design, but for the reason to simplify the method usage.
As previously written, simply do not use these methods in production!
Call the individual methods, the sample method calls, but use your complex parameters instead to make the entries unique. The sample methods just oversimplify the number of parameters that are necessary to implement all possible setups.
Is there any reason the add_vx_trap_destinationcould not use theirname (second) argument as the name (first) argument to snmpTargetAddrEntry::add_entry?
(Rather than UdpAddress(addr).get_printable())
Yes, that’s pretty much how we’ve ‘patched’ it (as in, copy/paste/adjust of the agent++ code ).
I can then see in the MIB browser the registered entries within the `snmpNotifyTable`.
(We’re still checking if there were any consequences to the change.)