Hi all, The question is whether planned or thought someone from the BIRD developers on the implementation of snmp traps in BIRD ? It would be nice to have a possibility to send SNMP trap when BGP session goes up/down or OSPF neighbor. For now, the only opportunity for the monitoring system to receive such an event it is parsing BIRD logs. Work with SNMP traps would be much easier for implementing into monitoring system. Thanks to the BIRD dev team. -- With best regards, Dmitry S. Nikolaev Moscow, Russia
Hi, you can generate snmp trap from syslog - and bird is capable to log over syslog. For example, with syslog-ng you can create filters and only invoke trap with standard tools only for events you really want. With regards, Daniel On 21.3.2014 05:53, Dmitry S. Nikolaev wrote:
Hi all,
The question is whether planned or thought someone from the BIRD developers on the implementation of snmp traps in BIRD ? It would be nice to have a possibility to send SNMP trap when BGP session goes up/down or OSPF neighbor. For now, the only opportunity for the monitoring system to receive such an event it is parsing BIRD logs. Work with SNMP traps would be much easier for implementing into monitoring system.
Thanks to the BIRD dev team.
Thanks for your reply. We will try, try to use this method. With best regards, Dmitry S. Nikolaev Moscow, Russia mail: dnikolaev@mega-net.ru On 21.03.2014 10:43, Daniel Suchy wrote:
Hi, you can generate snmp trap from syslog - and bird is capable to log over syslog. For example, with syslog-ng you can create filters and only invoke trap with standard tools only for events you really want.
With regards, Daniel
On 21.3.2014 05:53, Dmitry S. Nikolaev wrote:
Hi all,
The question is whether planned or thought someone from the BIRD developers on the implementation of snmp traps in BIRD ? It would be nice to have a possibility to send SNMP trap when BGP session goes up/down or OSPF neighbor. For now, the only opportunity for the monitoring system to receive such an event it is parsing BIRD logs. Work with SNMP traps would be much easier for implementing into monitoring system.
Thanks to the BIRD dev team.
Hi, I had planned to postpone any announcement to the community and the developers until I had some fully working code to show, but I am currently working on SNMP for BIRD. The idea is to have a generic SNMP framework that the routing protocols can use to generate traps and SNMP values. Then one or more protocols may implement SNMP-functionality for the framework. Initially I'll do an AgentX implementation, but in theory one could also add SMUX or plain SNMP. I am very careful to make the SNMP implementation as non-intrusive as possible and as event-loop-friendly as possible. If some route server decides to enable SNMP and all sessions are terminated at the same time, we can't have the SNMP protocols block BIRD while emitting SNMP notifications. My basic road map is as follows: 1. Implement basic SNMP framework with notification support. (complete) 2. Implement AgentX protocol for framework. (in progress) 3. Implement SNMP notifications for BGP. BGP4-MIB does not support 32-bit ASNs, so I am considering using the incomplete BGP4-V2-MIB using either my own OID (ordbogen) or that of Juniper (who have apparently implemented BGP4-V2-MIB) 4. Implement SNMP notifications for OSPF 5. Extend framework to handle read-only SNMP support 6. Extend AgentX protocol to handle reads 7. Implement SNMP data for BGP 8. Implement SNMP data for OSPF Also, after the patch have been submitted to the BIRD developers (and hopefully merged), support for UNIX sockets will need to be added to the AgentX protocol. As far as I could see, the current code did not support connecting to a UNIX socket which ordinarily is the default for AgentX. The work is in my backlog at work, but until it gets prioritized, all work is done in my spare time (which is limited). I have a personal goal to have everything done before the RIPE69 the 3rd of November. Best Regards Peter Christensen ------------------------------------------------------------------------ On 03/21/2014 09:08 AM, Dmitry S. Nikolaev wrote:
Thanks for your reply.
We will try, try to use this method.
With best regards, Dmitry S. Nikolaev
Moscow, Russia mail: dnikolaev@mega-net.ru
On 21.03.2014 10:43, Daniel Suchy wrote:
Hi, you can generate snmp trap from syslog - and bird is capable to log over syslog. For example, with syslog-ng you can create filters and only invoke trap with standard tools only for events you really want.
With regards, Daniel
On 21.3.2014 05:53, Dmitry S. Nikolaev wrote:
Hi all,
The question is whether planned or thought someone from the BIRD developers on the implementation of snmp traps in BIRD ? It would be nice to have a possibility to send SNMP trap when BGP session goes up/down or OSPF neighbor. For now, the only opportunity for the monitoring system to receive such an event it is parsing BIRD logs. Work with SNMP traps would be much easier for implementing into monitoring system.
Thanks to the BIRD dev team.
Thanks for your reply and work you do. Hope that your code will be included in BIRD when you finish. With best regards, Dmitry S. Nikolaev Moscow, Russia mail: dnikolaev@mega-net.ru On 21.03.2014 12:12, Peter Christensen wrote:
Hi,
I had planned to postpone any announcement to the community and the developers until I had some fully working code to show, but I am currently working on SNMP for BIRD.
The idea is to have a generic SNMP framework that the routing protocols can use to generate traps and SNMP values. Then one or more protocols may implement SNMP-functionality for the framework. Initially I'll do an AgentX implementation, but in theory one could also add SMUX or plain SNMP. I am very careful to make the SNMP implementation as non-intrusive as possible and as event-loop-friendly as possible. If some route server decides to enable SNMP and all sessions are terminated at the same time, we can't have the SNMP protocols block BIRD while emitting SNMP notifications.
My basic road map is as follows:
1. Implement basic SNMP framework with notification support. (complete) 2. Implement AgentX protocol for framework. (in progress) 3. Implement SNMP notifications for BGP. BGP4-MIB does not support 32-bit ASNs, so I am considering using the incomplete BGP4-V2-MIB using either my own OID (ordbogen) or that of Juniper (who have apparently implemented BGP4-V2-MIB) 4. Implement SNMP notifications for OSPF 5. Extend framework to handle read-only SNMP support 6. Extend AgentX protocol to handle reads 7. Implement SNMP data for BGP 8. Implement SNMP data for OSPF
Also, after the patch have been submitted to the BIRD developers (and hopefully merged), support for UNIX sockets will need to be added to the AgentX protocol. As far as I could see, the current code did not support connecting to a UNIX socket which ordinarily is the default for AgentX.
The work is in my backlog at work, but until it gets prioritized, all work is done in my spare time (which is limited). I have a personal goal to have everything done before the RIPE69 the 3rd of November.
Best Regards Peter Christensen
------------------------------------------------------------------------ On 03/21/2014 09:08 AM, Dmitry S. Nikolaev wrote:
Thanks for your reply.
We will try, try to use this method.
With best regards, Dmitry S. Nikolaev
Moscow, Russia mail: dnikolaev@mega-net.ru
On 21.03.2014 10:43, Daniel Suchy wrote:
Hi, you can generate snmp trap from syslog - and bird is capable to log over syslog. For example, with syslog-ng you can create filters and only invoke trap with standard tools only for events you really want.
With regards, Daniel
On 21.3.2014 05:53, Dmitry S. Nikolaev wrote:
Hi all,
The question is whether planned or thought someone from the BIRD developers on the implementation of snmp traps in BIRD ? It would be nice to have a possibility to send SNMP trap when BGP session goes up/down or OSPF neighbor. For now, the only opportunity for the monitoring system to receive such an event it is parsing BIRD logs. Work with SNMP traps would be much easier for implementing into monitoring system.
Thanks to the BIRD dev team.
participants (3)
-
Daniel Suchy -
Dmitry S. Nikolaev -
Peter Christensen