<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>BMP (BGP Monitoring Protocol) on Netdata</title><link>https://www.netdata.cloud/tags/bmp-bgp-monitoring-protocol/</link><description>Recent content in BMP (BGP Monitoring Protocol) on Netdata</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://www.netdata.cloud/tags/bmp-bgp-monitoring-protocol/index.xml" rel="self" type="application/rss+xml"/><item><title>BGP route leak and hijack: the detection signals and alerts that matter</title><link>https://www.netdata.cloud/guides/network/network-bgp-route-leak-hijack/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/network/network-bgp-route-leak-hijack/</guid><description>&lt;p&gt;A BGP route leak or hijack does not tear down your session. The peering stays Established, keepalives flow, and the session &amp;ldquo;up&amp;rdquo; 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.&lt;/p&gt;&#10;&lt;p&gt;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.&lt;/p&gt;</description></item><item><title>BGP session Established but stale: detecting silent route loss</title><link>https://www.netdata.cloud/guides/network/network-bgp-session-stale/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/guides/network/network-bgp-session-stale/</guid><description>&lt;p&gt;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.&lt;/p&gt;&#10;&lt;p&gt;This is the &amp;ldquo;Established but stale&amp;rdquo; 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.&lt;/p&gt;</description></item></channel></rss>