Question: (by Tiny Timmy) I've been working with the link-up/link-down traps in Net-SNMP, and notice that they only update every 60 seconds.
Supposedly you can overwrite this in the configuration file, but when I have tried to make it every two seconds, it just goes back to 60 seconds. In other words, the settings are not honored.
Has any one figured out a way around this?
Answer One: (by PumpkinJason) Are you saying the traps are delayed while being sent out by your snmpd daemon, or you actually meant the traps are just logged with a delay by snmptrapd?
What configuration directive you used to make it to "2 seconds" interval?
Answer Two: (by TinyTimmy) The problem with net-snmp is that it checks the link status only once every 60 seconds.
That means that if you yank the network cable out you will wait anywhere between 0 and 59.999 seconds before the net-snmp agent emits a link down trap.
Or, if the link is already down and you insert a network cable you wait From 0 to 59.999 seconds before the agent emits a link-up trap. And worse, if you manage to yank the cable and then put it back again so that both of those events occur between the checks by the net-snmp agent, *no* link-down or link-up trap will be emitted at all - only silence.
There are directives in net-snmp to alter that polling period. But they don't work; they do not change the one minute cycle.
This issue has absolutely nothing about a trap receiver - I watched this Emission (or non-emission) of traps using Wireshark.
Answer Three: (by PumpkinJason) I suspect this has something to do with DNS resolution time?
If you are using host domain name for trapsink insnmpd.conf, changeit to IP address to see if it makes any difference?
Answer Four: (by TinyTimmy) I have been using the IP address and the DNS is resolving in a couple of milliseconds, so that is not it.
Answer Five: (by Sandiyago) For the default linkUpDownNotification trap, current Net-snmp implementation polls for link state change every 60 seconds, that likely explains what you observed. An event based mechanism is supposed to appear in a future release.
Answer Six: (by Sandiyago) more reading suggests by using an agent compiled with Event MIB support we may be able to control the polling FREQUENCY:
DisMan Event MIB:
will configure the Event MIB tables to monitor the ifTable for network interfaces being taken up or down,
and triggering a linkUp or linkDown notification as appropriate.
This is exactly equivalent to the configuration: notificationEvent linkUpTrap linkUp ifIndex ifAdminStatus ifOperStatus notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus
monitor -r 60 -e linkUpTrap ""Generate linkUp"" ifOperStatus != 2 monitor -r 60 -e linkDownTrap ""Generate linkDown"" ifOperStatus == 2
It is likely using a different -r x may do the trick. But it may not if the linkDown/linkUp traps are hard-coded to a minimum 60 seconds to avoid the overhead of frequent polling.Answer Seven: (by TinyTimmy) I was already using the ""monitor"" lines below with -r value of 2 (two seconds).
However, what is useful is to learn that despite what the documentation says in net-snmp about the -r flag controlling the testing interval the fact is that the testing interval is "hard-coded to a minimum 60 seconds".
That means that if one is using net-snmp that the link-up/down traps are really only useful if one doesn't care about things that could occur in less than a minute.
If one is in a security center this means that a bad person could insert a man-in-the-middle box and if the cables are switched quickly that nobody would notice that link-state went down and then came back.
And if one is in a NOC one could miss transient link drops/recovery(indicative of an error condition) unless that condition just happened to occur at the instant net-snmp made its once a minute test.