Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for receiving SNMP traps through a multiplexer #362

Open
lunkwill42 opened this issue Aug 27, 2024 · 2 comments
Open

Add support for receiving SNMP traps through a multiplexer #362

lunkwill42 opened this issue Aug 27, 2024 · 2 comments
Labels
enhancement New feature or request post-zino2.0 These are features Zino1 does not have, but might be desired later

Comments

@lunkwill42
Copy link
Member

lunkwill42 commented Aug 27, 2024

Rationale

As mentioned in Håvard Eidnes' comments in #173, there is often a limit to how many trap receivers that can be meaningfully configured in any one router.

For this reason (and other reasons), the legacy Zino does not actually provide its own SNMP trap listener, but instead connects to an SNMP trap multiplexer service (straps, or nmtrapd in later incarnations, a part of the Scotty framework, I think). The trap multiplexer receives the actual trap messages, and multiplexes them to a UNIX socket that multiple processes can read from. Under this model, Zino never has to be started as a privileged user, only the trap multiplexer does.

This model is not currently supported by Zino 2. It provides its own trap listener, as we wanted it to be as standalone as possible, without introducing dependencies to the older Tcl-based tools.

However, Zino 2 could be extended to also support some kind of trap multiplexer, whether it be straps/nmtrapd or something else.

Some implementation considerations

  • A trap multiplexer like nmtrapd will add an extra header to an SNMP trap message before passing it on to a UNIX socket. This header typically contains information about the originators IP address and the length of the incoming packet.
  • Zino would have to connect to the UNIX socket and get its trap packets from there. We would have to find some way to feed a raw SNMP trap packet into the PySNMP framework, rather than having PySNMP read it from "the wire" itself.
  • Zino 1 features a "watchdog" service: Since the connection to the UNIX socket could be lost without warning, the watchdog takes to automatically re-connect to the UNIX socket if a trap has not been received in some specified interval of time.
@lunkwill42 lunkwill42 added enhancement New feature or request post-zino2.0 These are features Zino1 does not have, but might be desired later labels Aug 27, 2024
@lunkwill42
Copy link
Member Author

The straps/nmtrapd utility is part of Scotty, and is licensed under a 2-clause BSD license. However, Håvard has his own Zino-related patches to the tool. If we want to go the route of supporthing nmtrapd, we should maybe consider publishing our own fork.

@lunkwill42
Copy link
Member Author

@runborg has, however, suggested an alternative approach using more modern tools: Generic packet multiplexing. This would not be SNMP-specific at all, and can be accomplished through either userspace packet replicators (e.g. such as https://github.com/steinnes/udp-hub) or through iptables configuration (under Linux).

If these approaches could be tested and made into documented proof-of-concepts, no changes to Zino would be necessary. These could also allow Zino to be started as a non-privileged user on an alternative port, with another tool replicating packets received on UDP port 162 to the non-privileged port Zino is listening on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request post-zino2.0 These are features Zino1 does not have, but might be desired later
Projects
Status: No status
Development

No branches or pull requests

1 participant