Management
Highlighted
Management

Sending BGP SNMP traps

[ Edited ]
‎01-31-2020 02:39 AM

I've been struggling with sending SNMP traps to my NMS (LibreNMS).

I followed every step in this tutorial: https://kb.juniper.net/InfoCenter/index?page=content&id=KB24947

All configuration you see there has been copied to my test device (MX5), I of course changed the IP addresses accordingly.

 

Below is my configuration:

 

community "xxxxxx" {
    authorization read-only;
    client-list-name MANAGEMENT;
}
trap-options {
    source-address <IP ADDRESS LOOPBACK ROUTER>;
}
trap-group SNMP_BGPCHANGE {
    targets {
        <IP ADDRESS NMS SERVER>;
    }
}
policy BGP_STATE_CHANGE {
    events rpd_bgp_neighbor_state_changed;
    then {
        raise-trap;
    }
}

I tested this with bringing down and up a BGP peer, I see the messages appear in the logs:

 

Jan 31 12:24:01  ams-eq4-ar1-customs rpd[2264]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer <PEER IP> (External AS 65530) changed state from Established to Idle (event Stop) (instance master)
Jan 31 12:25:09  ams-eq4-ar1-customs rpd[2264]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer <PEER IP> (External AS 65530) changed state from OpenConfirm to Established (event RecvKeepAlive) (instance master)
Jan 31 12:34:49  ams-eq4-ar1-customs rpd[2264]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer <PEER IP> (External AS 65530) changed state from Established to Idle (event Stop) (instance master)

 

I'm not seeing any evidence that a trap is raised and sent to my NMS server.

I understand that by default there is no way to know if the trap receiver (NMS) has received anything from the SNMP agent point of view.

But I would at least like to see if a TRAP has been generated and sent to my NMS server.

 

Am I missing something here? 

4 REPLIES 4
Highlighted
Management

Re: Sending BGP SNMP traps

‎01-31-2020 03:09 AM

You can start by using spoof trap to validate the basic configuration of sending a trap and that it can reach the server.

 

https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/request-snmp-spoo...

 

If this works then you know the issue is your restriction commands for the trap forward.  

BGP state change will trap by default and when you add those restrictions you are basically turning off traps unless they are specified.  Is there are reason you don't want all default traps?

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
Management

Re: Sending BGP SNMP traps

‎01-31-2020 03:54 AM

Hi Spuluka,

 

Yes, i've used the spoof trap command to check if my server receives anything at all.

beelze@ams-eq4-ar1-customs# run request snmp spoof-trap bgpEstablished    
Spoof-trap request result: trap sent successfully

Nothing is shown in my NMS server, but that's something I might need to check there.

 

There is no reason why I would not want all default traps.

The most important traps are BGP Peer state changes and perhaps port up/down events.

I was not aware that juniper sends traps by default.

I thought that I would need to enable these traps.

 

I have not configured a syslog server, is that necessary in this situation?

Highlighted
Management

Re: Sending BGP SNMP traps

‎02-01-2020 05:10 AM

Syslog and snmp are independent configurations so they do not affect each other.  You can do them separately or together at your option.

 

To validate the path from the SRX to NMS allow ping on the zone where your trap will egress on the SRX and make sure you can ping the NMS from the SRX and the reverse direction as well.  A lack of network connectivity is another possible reason the trap does not reach the NMS server.

 

Once that is validated then it is confirmed the config on the server needs some adjustment.  Typically this will be the source ip address of the trap needs to be associated with a managed node in the NMS server.

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
Management

Re: Sending BGP SNMP traps

[ Edited ]
‎02-01-2020 08:53 AM

One more thing you'll want to check:

LibreNMS relies on the venerable snmptrapd tool from the net-snmp project.  That said, you should double-check your snmptrapd.conf configuration to make sure that you've setup access control there properlly. (Most common issue is that the device is sending traps with a mismatched community string, and snmptrapd will just drop them silently.)

 

To wit, see this note from http://www.net-snmp.org/docs/man/snmptrapd.conf.html:

Previously, snmptrapd would accept all incoming notifications, and log them automatically (even if no explicit configuration was provided). Starting with release 5.3, access control checks will be applied to incoming notifications. If snmptrapd is run without a suitable configuration file (or equivalent access control settings), then such traps WILL NOT be processed. See the section ACCESS CONTROL for more details.

 

HTH

/doug

 

UPDATE!    

I forgot to mention:  a simple tcpdump run on your librenms host will let you know if you're even receiving the trap pdu ( udp/162).   If you don't even see those messages on your eth interface then you have an issue (firewall?) in the path.  If you *do* see it arrive on the eth interface but not in LibreNMS, then start checking the access control for snmptrapd.

/doug

--
"There he goes. One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die." --HST