ER Reduce BGP SNMP traps

From JuniperClue

Problem

Currently, JunOS software generates SNMP traps for every BGP state change. Unfortunately, some of the traps generated are unnecessary. Some examples of the unnecessary state changes are the traps generated by the transitions between Idle, Connect, and Active, which all occur while trying to reestablish connection. When taken to their extremes, such as during the loss of an IBGP mesh, the number of traps can become disruptive to an SNMP trap monitoring station.

Solution

JunOS should only generate a trap upon the change to or from the Established state, or when a session goes from one of the 3 "connecting" states (Idle, Connect, and Active) to one of the synchronization states, and returns to one of the connecting states without successfully becoming Established.

It may also make sense to emit a trap on a session which remains in the connecting states after a configurable amount of time, such as every 30 minutes. This is how Cisco IOS implements SNMP traps.