This article provides information on how to generate BGP state SNMP traps to an NMS (network management system)  server by using event-options .

Whenever a change in the BGP state occurs, SNMP traps should be generated to the NMS server.  There are various methods to generate SNMP traps. But this article will focus on generating SNMP traps by using event-options :

Topology:

   |----------iBGP------|
R1>----------------------<R2>--------------<NMS server

• R1 and R2 are IBGP peers.
• BGP connectivity is established by using IGP via Loopback interfaces.

event-options {
    policy BGP_STATE_CHANGE {
        events rpd_bgp_neighbor_state_changed; < this will match the BGP state change in the RPD process
        then {
            raise-trap;
        }
    } 
}



snmp {
    trap-options {
        source-address 10.141.227.12; < source address of the router
    }
trap-group SNMP_BGPCHANGE {
    targets {
        10.130.35.203; NMS server IP address
    }
}

Verification :
Use deactivate protocols BGP or interface flap and check if the SNMP trap is generated in the NMS server.

Additionally, traceoptions can be enabled to confirm the traps are being generated. Deactivate or delete SNMP traceoptions after confirming traps are sent to  NMS server. 

snmp {
traceoptions {
    file snmp size 2m world-readable;
    flag all;
    flag pdu;
}
}

user@lab>show log snmp
Jun 27 15:37:48.734175 snmpd[0]  <<< V2 Trap
Jun 27 15:37:48.734185 snmpd[0]  <<<  Source:      10.141.227.12
Jun 27 15:37:48.734194 snmpd[0]  <<<  Destination: 10.130.35.203
Jun 27 15:37:48.734202 snmpd[0]  <<<  Version:     SNMPv2
Jun 27 15:37:48.734217 snmpd[0]  <<<  Community:   SNMP_BGPCHANGE

#delete snmp traceoptions