You may see the following alarm traps occurring several times a day,

ISD4000 SNMP Traps 101.154 Lvl4 SIERRA23 16:44:02 16:44:05

DISMAN-EVENT-MIB:sysUpTimeInstance = Timeticks: (3018052183) 349 days, 7:28:41.83

SNMPv2-MIB:snmpTrapOID.0 = OID: BGP4-MIB:bgpBackwardTransition

bgpPeerLastError.10.100.100.2 = 02 07

bgpPeerState.10.100.100.2 = connect(2)

SNMPv2-MIB:snmpTrapEnterprise.0 = OID: JUNIPER-CHASSIS-DEFINES-MIB:jnxProductNameQFX1000260C

ISDEOM

The trap BGP4-MIB:bgpBackwardTransition means the BGP session to 10.100.100.2 dropped to a lower state, in that case to connect state.  In logs we can see messages like “unsupported capability) MP capability afi 1, safi 1 <inet-unicast>” and lines showing peer: <inet-unicast> … us: <evpn>.

This could indicate a family mismatch: this neighbor is being asked to speak EVPN (or you’re advertising EVPN signaling) while the other side only speaks inet-unicast. This could result that the peer rejects, so then the trap is generated. 

Sep 15 16:01:33.019 switch rpd[10705]: %DAEMON-4-BGP_NLRI_MISMATCH: bgp_process_caps: mismatch NLRI with 10.10.10.2 (Internal AS 65500): peer: <inet-unicast>(1) us: <evpn>(8388608) (instance master)

Sep 15 16:01:33.043 switch rpd[10705]: %DAEMON-4: bgp_process_caps:4181: NOTIFICATION sent to 10.10.10.2 (Internal AS 65500): code 2 (Open Message Error) subcode 7 (unsupported capability) MP capability afi 1, safi 1 <inet-unicast>

This log shows a BGP session failure due to a capability mismatch between router 10.10.10.1 (switch 1) and the peer at IP 10.10.10.2 (swich 2). Basically, switch 1 is expecting EVPN (AFI/SAFI: 25/70) and the peer switch 1 is only offering IPv4 unicast (AFI/SAFI: 1/1). This means the BGP session cannot be established because the two sides are not speaking the same "protocol family", one expects EVPN, the other IPv4 Unicast.

This relates to the missing configuration. The switch is missing the family evpn and is only working for IPv4 Unicast. We need to add the following configuration on switch 2:

group OVERLAY-CORE {

apply-groups BGP-OVERLAY;

type internal;

local-address 10.10.10.2;

family evpn {

signaling;

}

multipath;

neighbor 10.10.10.1;

Also, for the group OVERLAY-RR we may need to add the type internal if it is configured on switch 1:

#set protocols bgp group OVERLAY-RR type internal

After correcting the configuration the trap should not appear again.