I am working with a device that only communicates through SNMP traps. When an alarm is active, it sends a trap; when an alarm clears, it sends a trap. The bindings of the traps have a running index, so if a trap is received that is not lastIndex + 1, we will know that a trap was dropped.
At this point, a resync can be initiated, and the device will send all active alarms (the indexes will continue to increment by 1). If the indexes received are out of order again, another resync will be initiated.
Since traps are not guaranteed, this may lead to a loop of continuous resyncing. Is there a good approach to get all the active alarms?
Hi Joshua,
Since the device can only send traps, I believe there are a limited number of choices. A possible option could be using SNMP Inform instead of traps. SNMP Inform will require an acknowledge from the sender (in this case, the device). If an acknowledge is not received by the device, it should send again the SNMP Inform.
Hope it helps.
Aligned with the “inform” suggested by Miguel, if viable.
With traps being UDP, where the wiring & network design allow it,
it might help to minimize hops between source & destination… e.g. if both your device & DMA use the same default GW.
In any case, you might want to check with the vendor if the implementation of their SNMP agent could accommodate specific KPIs/OIDs to be polled every now & then.
Receiving traps only will always come with the limitations you’ve mentioned – not much you can do against UDP being “best effort”.
This is indeed the best course of action, although I’m not sure it guarantees the order of the traps. So Joshua may want to be a bit more lenient on when to trigger a resync if this still happens too often with informs. (e.g. a missed index still has x seconds to appear)
Additionally, if there are a lot of traps that can arrive at the same time, you may run into problems with the socket’s buffer not being emptied quickly enough by SLSNMPManager. This threshold is reached rather quickly on SNMPv3 (SNMP++), but holds up a lot better with SNMPv1 and SNMPv2 (WinSNMP). Either way, this buffer size can be increased using this DWORD value in the registry (may need to be created): [HKEY_LOCAL_MACHINE SYSTEM CurrentControlSetServicesAfdParameters] DefaultReceiveWindow
For SNMP++, this throughput has been improved with RN39629 (10.4.7, 10.4.0 CU4, 10.3.0 CU16)