currently to receive traps via snmp from deployed devices/nodes using snmptrapd (net-snmp). This concept works great together with bash script or perl script. At least when using snmpV1, however, there are limitations when trying to use snmpV3. snmptrapd, currently at release 5.8, is dependent on using engineID together with user credentials in order to receive and decode trap before being able to used. traps can either be received using engineID and credentials or via INFOFORMS if remote devices/nodes support this.

If you need to monitor not hundreds of devices but rather thousands of devices, effectively you would need to gather all thousands of devices’s engineID values and then pre-program the snmptrap.conf file with these obtained engineIDs. Once done, then you would be ready to start monitoring and receive traps and react accordingly. But in the real world, these devices may be changed out on a daily or weekly basis so there would be a constant updating of snmptrap.conf for editing engineID values. There may be a probability that net-snmp 5.9 may add some additional functionality that may overcome this limitation. A consideration to the ZABBIX R&D team : can a software engine be build to listen to port 162 or other which can interface directly with the ZABBIX system? This could handle snmpV1 and snmpV3 where it could offer to support standard reactions or even custom, e.g. accept snmpV3 traps based on user credentials only. This should be considered to live directly on the zabbix server as well as proxy options.