Menu

#837 netlink-based link state trap generation (5.2.3-7 - debian)

open
nobody
None
5
2014-04-30
2007-07-23
No

Greetings SNMP coders and users,

Every once in a while someone complains about having to wait for the 60 second timer to elapse before getting their 'linkUpDownNotifications'. The attached patch causes snmpd to register with the linux RT-NETLINK facility in order to be notified of link state changes. IP interfaces going up and down now generate traps immediately.

The linkUpDownNotifications snmpd.conf directive has been changed to use rt-netlink instead of the 60s timer, and a "-n" option has been added to the monitor directive in order to trigger it using netlink instead of a timed poll. The ifTable cache reload has also been changed to trigger on netlink message reception in addition to its own 30s timer.

Note that the netlink trigger method has not been generalized, and registers only for IP interface link activity.

Rate limiting:

A configuration directive was added to snmpd.conf to control the frequency with which link up down traps are generated.

 "netlinkTiggerRes <timeout in milliseconds>" default = 5000ms

(Netlink trigger resolution) specifies the minimum time allowed between consecutive link state traps for a single IP interface. For example, if a link changes state at t=0, a trap is generated immediately. If the same link changes state at t=1000ms, this is less than the trigger resolution of 5000 ms, and therefore a trap will not be generated. An event will, however, be scheduled for 5000-1000ms = 4000ms in the future, that will check link state and send traps if link states have changed since the last link state traps were transmitted.

If, instead of the same IP Link changing state, a different link changes state at t=1000ms, the timeout restriction would not apply, and a trap would be generated immediately.

The patch applies to net-snmp 5.2.3-7 (debian) - I apologise ahead of time for the vintage of net-snmp that I've applied this to. The patch is relatively small, and should hopefully be easily adaptable to more recent versions.

Michael Leslie
--
RuggedCom Inc.
www.ruggedcom.com
Telephone: (905) 856-5288

Discussion

  • el_fontanero

    el_fontanero - 2007-07-23

    patch to provide netlink-based link state trap generation (5.2.3-7 - debian)

     
  • Thomas Anders

    Thomas Anders - 2007-09-19

    Logged In: YES
    user_id=848638
    Originator: NO

    Are you willing to update your patch against a more recent net-snmp version (e.g. 5.4.1) to make it easier to incorporate your patch both upstream and in Debian?

     
  • Wes Hardaker

    Wes Hardaker - 2008-02-13

    Logged In: YES
    user_id=76242
    Originator: NO

    I haven't finished reviewing this yet (but will). I'm sort of thinking that using the monitor line to continue registering things via netlink is a bit odd... It would make more sense to me to handle linkup/down traps directly. The monitor/disman hack was only put in place because there wasn't a better way to receive direct notifications when links happened. If there is, I don't think there is any reason to do disman at all.

    There is a copyright line in the rtnetlink.c file that doesn't include a license definition. That line needs to be modified to indicate it's a BSD license for the copyright or we can't accept the patch.

     
  • Vincent Bernat

    Vincent Bernat - 2012-07-21

    This patch relies on disman to send the traps. There is now code directly in if-mib module to send a trap if enabled. The cache is also autoupdating and there is only a small latency before getting a trap. I have yet to find a way to attach a patch to this report...

     
  • Vincent Bernat

    Vincent Bernat - 2012-12-09

    And the third one (happy to see that SF says "Attachments" while it is not possible to attach more than one).

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.