Bug ID 867793: BIG-IP sending the wrong trap code for BGP peer state

Last Modified: Sep 13, 2023

Affected Product(s):
BIG-IP TMOS(all modules)

Known Affected Versions:
12.1.0, 12.1.1, 12.1.2, 12.1.3,,,,,,,, 12.1.4,, 12.1.5,,,, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0,,,,,,,,, 13.1.1,,,,, 13.1.3,,,,,,, 13.1.4,, 13.1.5,, 14.0.0,,,,,, 14.0.1,, 14.1.0,,,,,, 14.1.2,,,,,,,,, 14.1.3,, 15.0.0, 15.0.1,,,,, 15.1.0,,,,,, 15.1.1, 15.1.2

Fixed In:
16.0.0,, 14.1.4

Opened: Jan 09, 2020

Severity: 3-Major


When BGP peer is going down, the BIG-IP system sends the wrong 'bgpPeerState: 6(established)' with its SNMP trap.


The BIG-IP system sends the wrong code with its SNMP trap. It should be 'bgpPeerState: idle(1)' when the peer is not connected.


-- BIG IP system is connected with a Cisco router to verify the traps. -- BGP peer between the BIG-IP system and the Cisco router is going down. -- Both devices release an SNMP trap.



Fix Information

BIG-IP now sends the correct trap code for BGP peer state.

Behavior Change

The bgpPeerState for bgpBackwardTransNotification now reports the state after the state machine transition, i.e., the state into which the system is transitioning. In earlier releases, it reported the state prior to the state machine transition, which would always report idle because all backwards state transitions are into idle.

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips