Hi,
I’ve got a question regarding SNMPv3 traps sent to DataMiner. In a scenario where there is some network latency and a ” Interface Link Up” trap is received before the “Interface Link Down” trap was received, how would DataMiner handle this? Would it ignore the first trap received “Interface Link Up” and just raise an alarm when the “Interface Link Down” trap was received?
Thanks in advance,
Carlos
Hi Carlos,
Normally the trap functionality (trap receiver) implemented in connectors (drivers) don’t take into account the network latency. This means that traps will be processed on a first-come, first-served basis.
From your question you are referring to two specific traps:
- Interface Link Up (1.3.6.1.6.3.1.1.5.4)
- Interface Link Down (1.3.6.1.6.3.1.1.5.3)
The purpose of the these traps is to update the status of an interface from the Interface table. Normally drivers (and specially the ones monitoring network devices) implement the Interface table (1.3.6.1.2.1.2.2). Assuming that the Interface table is also mapped into the driver, in the worst case scenario, the status of the interface will be updated in the next polling cycle.
Hello Miguel,
We would like to know if Dataminer performs status check on all interfaces regularly, will it be able to clear the link down alarm automatically when the interface is confirmed up by the regular check?
Can we request for enhancement on Dataminer to clear the alarm automatically as it will poll all interface status in every 5 minutes
Hi Mert,
Regarding your first question:
Thanks Miguel. As per your last update, traps will be processed on a first-come, first-served basis. When link-aggregation 1 link is down, then the SNMPv3inform unable to send out and wait for the retry, this will run on the interval of 3 seconds retry 20 times to dataminer until the trap is being acknowledge. After the retry timer expired, the SNMPv3Inform of Link aggregation 1 down is sent and Dataminer triggers the alarm. during this time, the link might be restored and interface link up was processed/received by dataminer before interface link down. question is, how will dataminer amange this? will dataminer continue to query link-aggregate 1 to check on the status? is this something that we can check/change in the cmts protocol driver?
This depends on how the protocol (or driver) is handling updates based on SNMP traps. Normally one of the following approaches is implemented:
1. Whenever a trap arrives, the driver will trigger a SNMP polling of the Interface table. In this case, it does not matter if the trap arrives late. As long as the response from the SNMP polling contains the updated states, no alarms will be displayed
2. Whenever a trap arrives, the driver will quickly update the status of the interface. In case the trap indicating that the link is down arrives after the element updated the Interface table (via SNMP polling, with the update ‘Link Up’ for the aggregated link), an alarm (indicating ‘Link Down’) will be displayed. The alarm will be cleared:
– Either after the next polling of the Interface table,
– Or the trap (indicating the link is up) arrives to DataMiner
For the latter approach, delays can be tackled by keeping track of the last time when the Interface table has been updated. If the trap arrives late, the driver could check first if this timestamp and proceed accordingly.
Hi Mert,
Regarding your second question:
Hello Miguel,
We would like to know if Dataminer performs status check on all interfaces regularly, will it be able to clear the link down alarm automatically when the interface is confirmed up by the regular check?
If the driver is monitoring the Interface table, as long as the element is running, the interface status (for all interfaces) will be updated. How often the Interface table is updated (via SNMP polling) depends on the polling time defined in the driver. Normally the Interface table is polled every 30 seconds. However, in order to provide more accurate information, we will need to look into the driver.
Thanks Miguel.
As per your last update, traps will be processed on a first-come, first-served basis.
When link-aggregation 1 link is down, then the SNMPv3inform unable to send out and wait for the retry, this will run on the interval of 3 seconds retry 20 times to dataminer until the trap is being acknowledge.
After the retry timer expired, the SNMPv3Inform of Link aggregation 1 down is sent and Dataminer triggers the alarm. during this time, the link might be restored and interface link up was processed/received by dataminer before interface link down.
question is, how will dataminer amange this? will dataminer continue to query link-aggregate 1 to check on the status? is this something that we can check/change in the cmts protocol driver?
Thanks Miguel.
As per your last update, traps will be processed on a first-come, first-served basis.
When link-aggregation 1 link is down, then the SNMPv3inform unable to send out and wait for the retry, this will run on the interval of 3 seconds retry 20 times to dataminer until the trap is being acknowledge.
After the retry timer expired, the SNMPv3Inform of Link aggregation 1 down is sent and Dataminer triggers the alarm. during this time, the link might be restored and interface link up was processed/received by dataminer before interface link down.
question is, how will dataminer amange this? will dataminer continue to query link-aggregate 1 to check on the status? is this something that we can check/change in the cmts protocol driver?