Generic BGP (BGP4-MIB) on Netdata

BGP flapping: why a peer keeps resetting and how to find the cause

Mon, 01 Jan 0001 00:00:00 +0000

A BGP peer cycling between Established and Idle is sending a specific signal. The session tears down because one side sent a NOTIFICATION message, and that message carries an error code and subcode that pinpoints the cause. Most monitoring watches only the FSM state (up or down) and ignores the NOTIFICATION payload, so the operator sees flapping without knowing why.

The second trap is treating the symptom. Clearing the session or increasing the hold timer does not fix the underlying cause. The session re-establishes briefly, then drops again identically. The hold timer is not the problem; the hold timer is detecting the problem.

BGP NOTIFICATION and Cease messages: what each subcode is telling you

Mon, 01 Jan 0001 00:00:00 +0000

A BGP NOTIFICATION in your router log is a peer telling you why it tore down the session. The message carries an error code and an error subcode. Those two numbers tell you whether you are looking at a maintenance window, a route leak, a prefix-limit hit, a CPU-starved control plane, or a BFD-triggered teardown.

Cease (code 6) is the most common NOTIFICATION. Its subcodes, defined in RFC 4486 and extended by RFC 8538 and RFC 9384, hold most of the diagnostic value. Codes 2 through 5 appear less often but point to distinct failure classes: parameter mismatch, malformed updates, hold-timer expiry, and FSM errors.

BGP route leak and hijack: the detection signals and alerts that matter

Mon, 01 Jan 0001 00:00:00 +0000

A BGP route leak or hijack does not tear down your session. The peering stays Established, keepalives flow, and the session “up” indicator stays green. What changes is which prefixes your network believes are reachable, through which origin AS, and via what path. Traffic is silently misrouted or blackholed while the session looks healthy.

BGP has no built-in authentication of route ownership. Any AS can announce any prefix. Whether other networks accept the announcement depends on their filtering, and filtering is inconsistently deployed. Approximately 50% of routable IP prefixes carry a Route Origin Authorization (ROA), and only about 6.5% of Internet users sit behind networks that actively reject RPKI-invalid routes. That gap is where leaks and hijacks propagate globally before anyone notices.

BGP session Established but stale: detecting silent route loss

Mon, 01 Jan 0001 00:00:00 +0000

Your BGP session to a transit provider or iBGP peer is Established, but destinations are unreachable. The RIB is missing prefixes from that peer, or the routes it has are stale. No NOTIFICATION was sent, no session flap occurred, and your monitoring trusts the FSM state.

This is the “Established but stale” pattern. KEEPALIVEs are still exchanged at the TCP level, but the UPDATE exchange has stopped. The peer stopped sending routes, a middlebox is silently dropping UPDATE packets, or Graceful Restart is holding the session open after the remote side went down.