-
Notifications
You must be signed in to change notification settings - Fork 5
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
Implement SNMP trap reception mechanism #173
Comments
The |
Some more digging, and it turns out The man page source corresponding to the link above is here: https://github.com/flightaware/scotty/blob/23645564467704119dca051b6c8b16a4c56b74af/tnm/doc/nmtrapd.8 . The manpage describes the output format from the multiplexer's UNIX socket; the original SNMP trap packets can be gotten from this, and if PySNMP can be made to process raw packets, Zino 2.0 could be adapted to support both a built-in trap daemon, or fetch data from a multiplexer daemon like |
Please note that we're already using this multiplexing method actively. The above method means that you can only have a single program listening |
We definitely understand the advantages, @he32, but we don't want to make Zino 2 immediately depend on this 3rd party software for trap reception as its default implementation. This is why we've made the basic trap daemon from scratch, so that we can concentrate on the actual trap management code - and then down the road, we can add support for a trap multiplexer as an alternative mode of operation. An interesting question in that regard: Could the |
All associated sub-tasks have been closed, this can now also be closed |
Design considerations
Zino 1 uses a trap daemon model taken from Scotty, wherein an SNMP trap multiplexer daemon (
straps
ornmtrapd
) is run as root, and any Scotty program (like Zino) that wants a copy of all received traps can run as unprivileged users and connect to a UNIX socket to receive a stream of the received trap messages.While this is a really nice model for both debugging and for having multiple small and independent programs that can run on the same machine and react to traps, we don't see this as an essential model to replicate.
In Zino 2, we will instead opt for a model where the Zino program itself will listen for incoming SNMP trap messages (on UDP port 162). This does have the side-effect that the Zino program must be started by root, and needs to be able to switch to a less privileged user immediately after opening the privileged port 162.
A model where Zino connects to a trap message multiplexer can be added later if deemed necessary.
Sub-tasks
Add initial trap receiver functionality to Zino #189
Implement a generic trap dispatcher framework in
zino.trapd.TrapReceiver
#193Traps that are handled by the original Zino in some way or the other
These traps cause Zino to take action:
IF-MIB::linkUp
andIF-MIB::linkDown
) #232BFD-STD-MIB::bfdSessUp
andBFD-STD-MIB::bfdSessDown
) #292jnxBgpM2BackwardTransition
andjnxBgpM2Established
fromBGP4-V2-MIB-JUNIPER
) #288These traps are only parsed and logged (in simple or less simple ways):
SNMPv2-MIB::coldStart
andSNMPv2-MIB::warmStart
trap loggers #226These traps seem to be just ignored entirely:
bgpBackwardTransition
(a.k.a.BGP4-MIB::bgpBackwardTransition
)BGP4-MIB::bgpBackwardTransNotification
jnxBgpM2Experiment.1.1.0.2
(a.k.aBGP4-V2-MIB-JUNIPER::jnxBgpM2BackwardTransition
)SNMPv2-MIB::authenticationFailure
CISCOTRAP-MIB::tcpConnectionClose
(but contains some commented out logging code)BGP4-V2-MIB-JUNIPER::jnxBgpM2BackwardTransition
The default trap handler just logs incoming trap details as an "unknown trap"
The text was updated successfully, but these errors were encountered: