BGP-ADJ neighbor flagged Disconnected while session Established since longtime — False positive

Products

• VMware Smart Assurance
• Network Observability

Issue/Introduction

• You are observing what appears to be false positive BGP session disconnect alerts on devices. Alerts were raised reporting the BGP adjacency as Disconnected, however the underlying BGP sessions have been continuously Established since long time and remained up throughout.

• One of the hub devices was experiencing an issue. you suspect this hub-side event may have influenced the alert correlation logic, causing the access device to be flagged with a BGP-down condition even though its local session state was Established.

• How does the alerting/correlation logic determine a BGP "Disconnected" state? Can a failure on an upstream hub device (two eBGP hops away) cause a downstream L3 access device to be flagged as Disconnected while its directly-attached session remains Established?

Environment

All supported releases of Smart

Cause

The BGPProtocolEndpoint::Established method in BGP.mdl relies on PreviousPeerState to determine session status when DisableBGPAlertsOnSNMPError is set to TRUE. The current implementation immediately overwrites the PreviousPeerState with the polling error code (e.g., SNMP_ETIMEOUT). Because the last known good state is lost, the logic cannot confirm the ESTABLISHED state, leading to false-positive alerts.

Resolution

Below fix is currently targeted for release in a future version of DX NetOps. Please note that target releases are subject to change, and we recommend checking with your SE team or the product roadmap or raise a case with Broadcom support for the most accurate timeline.

• Only update PreviousPeerState when cur_value is a real BGP protocol state (NOT_POLLED_YET, IDLE, CONNECT, ACTIVE, OPENSENT, OPENCONFIRM, ESTABLISHED, UNKNOWN). SNMP error states (SNMP_ETIMEOUT, SNMP_EXCEPTION, SNMP_EXP_NOSUCHOBJECT, SNMP_EXP_NOSUCHINSTANCE, SNMP_ERR_NOSUCHNAME, SNMP_EXP_ENDOFMIBVIEW, NO_RESPONSE) no longer overwrite PreviousPeerState, so the last known good protocol state is preserved.

• PeerState itself continues to reflect the true current (error) state, which is what drives PeerStatePollingFail and the DisableBGPAlertsOnSNMPError suppression logic as intended.