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

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.

Detection is not a single signal. It is a composite of RPKI validation state, origin AS baseline comparison, AS-path anomaly detection, per-peer prefix count monitoring, and prefix granularity checks. This article covers the signals that matter, how to check them during an incident, and how to build alerting that catches leaks before they become outages.

Anatomy of leaks and hijacks

A route leak occurs when a network advertises prefixes it learned from one peer to another peer it should not have. The prefixes are real, but the propagation path violates policy. A hijack occurs when a network announces prefixes it does not own, either by originating them directly (origin AS hijack) or by announcing a more-specific sub-prefix of someone else’s block.

The most dangerous amplification mechanism is Longest Prefix Match (LPM). BGP routers always prefer the most specific prefix. If your network announces 203.0.113.0/24 and another AS announces 203.0.113.0/25 or even a /32 inside that block, traffic to the more-specific destination follows the other AS’s route regardless of AS-path length or RPKI state. The more-specific wins.

RPKI Route Origin Validation (ROV) helps but does not close this gap entirely. A /32 announcement inside a /24 that has a valid ROA for the /24 is RPKI INVALID, because the ROA authorizes the /24’s origin AS, not the /32’s origin AS. But many networks still accept and forward INVALID routes. The June 2024 incident where 1.1.1.1/32 was announced by an unauthorized AS demonstrated this: the /32 was RPKI INVALID but was accepted as a Remote-Triggered Blackhole route at a Tier-1 provider, causing continent-wide blackholing of 1.1.1.1.

Here is how the detection signals cascade:

flowchart TD
    A[Unexpected prefix from peer] --> B{RPKI validation}
    B -->|INVALID| C[High-confidence hijack]
    B -->|Unknown| D{Origin AS changed?}
    B -->|Valid| E{Expected AS-path?}
    D -->|Yes| F[Origin AS anomaly]
    D -->|No| G{More-specific than baseline?}
    E -->|No| H[AS-path deviation]
    E -->|Yes| I[Legitimate - monitor]
    G -->|Yes| J[Sub-prefix hijack risk]
    G -->|No| I
    C --> K[Aggregate into event with score]
    F --> K
    H --> K
    J --> K
    K --> L[Alert with confidence and evidence]

No single signal is conclusive. An RPKI INVALID route could be a stale ROA on your end. An origin AS change could be a legitimate re-announcement. A more-specific prefix could be operational. Production detection systems aggregate multiple weak signals into a single event with a confidence score, weighting RPKI validation, IRR validation, bogon checks, AS relationship checks, and AS-path continuity. Events are closed when the suspicious prefix is withdrawn or the legitimate origin re-announces, with a timeout of approximately six hours of inactivity.

Common causes

Quick checks

These are read-only checks safe to run during initial triage.

# Check BGP summary for unexpected peers or prefix count changes
ssh <router> 'show ip bgp summary | begin Neighbor'

# Check for RPKI-invalid routes accepted in the RIB
ssh <router> 'show bgp ipv4 unicast rpki invalid'

# Check per-peer received prefix count for the suspicious peer
ssh <router> 'show ip bgp neighbor <peer> received-routes | include Total'

# SNMP walk of BGP peer state (BGP4-MIB)
snmpwalk -v2c -c <community> <router> .1.3.6.1.2.1.15.3.1.2

# SNMP walk of peer remote AS to detect unexpected sessions
snmpwalk -v2c -c <community> <router> .1.3.6.1.2.1.15.3.1.9

# Check BGP NOTIFICATION history for Cease/1 (Maximum Prefixes)
ssh <router> 'show ip bgp neighbors <peer> | include notification|Last'

# Check your prefix origin AS on public route collectors
curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS<your_asn>"

# Check RPKI validation state for a specific prefix
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=<prefix>"

# Check for more-specific announcements of your prefix
curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=<your_prefix>"

How to diagnose it

1. Identify the source. Look at which peer’s prefix count spiked. Correlate the BGP RIB size increase with per-peer prefix counts to find the offending peer. A sudden per-peer increase versus gradual growth distinguishes a leak from organic expansion.

2. Verify against RPKI/ROA. Check whether the suspicious routes are RPKI INVALID, Unknown, or Valid. INVALID is high-confidence. Unknown requires AS-path baseline comparison because RPKI alone cannot confirm. Not all prefixes have ROAs; absence of a ROA produces “Unknown,” not “Invalid,” and Unknown hijacks are invisible to RPKI-only detection.

3. Check AS-path via BMP or route collectors. BGP4-MIB only shows best-path routes, not the full Adj-RIB-In. The bgp4PathAttrTable only reflects best-path; Adj-RIB-In entries return “NA” over SNMP. For pre-policy AS-path visibility, use BMP (RFC 7854) if deployed, or external route collectors (RIPE RIS, RouteViews).

4. Check for more-specifics. Search global collectors for more-specific prefixes of your announced blocks. A /32 or /25 inside your /24 that you did not announce is a sub-prefix hijack signal. More-specifics win LPM regardless of RPKI state on the less-specific.

5. Cross-reference public validators. Before acting, verify your local RPKI cache against public validators (RIPEstat, Routinator). A stale local cache can produce false INVALIDs that look like a hijack.

6. Assess propagation. Check whether the leaked prefixes are appearing in multiple peers’ views via looking glasses. Widespread propagation means the leak has escaped containment and is harder to recall.

7. Check for a stale session masking the real issue. Watch for “BGP silent session drop” where the FSM stays Established but no UPDATEs flow. If prefix counts are flat or declining despite the session showing up, you may have a stale Established on top of the leak. Track bgpPeerInUpdates rate and the timestamp of the last received prefix.

Metrics and signals to monitor

Fixes

Filter leaked prefixes inbound

Apply inbound prefix-lists or route-maps to the offending peer to reject the leaked prefixes. This is the immediate containment action.

Warning: Inbound filtering changes what your router accepts from the peer. If the filter is too broad, you will drop legitimate routes and potentially blackhole your own traffic to valid destinations through that peer. Test against the current RIB before committing.

Tradeoff: Use RPKI validation as the first filter layer, then IRR-based prefix-lists as a second layer. Manual prefix-lists are the most precise but highest-maintenance option. IRR data is manually maintained and frequently stale, so IRR-based filters can both miss new legitimate routes and accept stale ones.

Coordinate with the leaking peer

If the leak originates from a peer or customer, contact them to stop the leak at the source. They may have a misconfigured export policy.

Tradeoff: Response time depends on the peer’s NOC availability. For active hijacks affecting critical services, filter locally first, then coordinate.

Withdraw if you are the source

If your own AS is the leak source, withdraw the prefixes immediately and review your export policy.

Warning: Withdrawing affects routing for all downstream dependents. Coordinate with your NOC and downstream customers before withdrawing critical prefixes.

Deploy RPKI ROV enforcement

Configure your routers to reject RPKI INVALID routes. This is the strongest preventive control widely available today.

Tradeoff: RPKI validator cache staleness can produce false INVALIDs. Monitor validator health and cross-reference with public validators. Approximately half of prefixes have no ROA, so RPKI alone does not catch leaks on unsigned prefixes.

Prevention

• Deploy RPKI ROV enforcement on all external BGP sessions. Tag routes as VALID, Invalid, or NOT_FOUND, and reject INVALIDs.
• Sign all your own prefixes with ROAs. This protects your prefixes from origin hijack by networks that enforce ROV.
• Configure per-peer maximum-prefix limits. Set a threshold alert at 75% of the limit and a hard session reset at the configured maximum. Cease/1 from a peer means they hit your limit, which is the last line of defense.
• Deploy BMP (RFC 7854) for Adj-RIB-In visibility. This is the only reliable way to see pre-policy AS-path changes and per-prefix route deviations that SNMP cannot expose.
• Maintain IRR/RPSL objects. Keep them current. Stale IRR data is a common leak enabler for networks that still filter on IRR objects.
• Build origin AS baseline monitoring. Track the expected origin AS for every prefix you own and alert on any change.
• Monitor for more-specifics of your prefixes globally. Use route collector feeds (RIPE RIS, RouteViews) to watch for unexpected sub-prefix announcements of your blocks.
• Consider RFC 9234 BGP Role and OTC attribute on peering sessions to enforce valley-free routing at the protocol level. The RFC is stable but deployment remains sparse; Arista EOS, Juniper Junos OS, and Cisco IOS-XR have varying degrees of implementation, and it requires coordinated configuration across both sides of a peering session.
• ASPA (Autonomous System Provider Authorization) is an emerging RPKI extension (draft-ietf-sidrops-aspa-verification, active as of April 2026) that cryptographically authorizes provider relationships and rejects valley paths. It reuses the existing RPKI-to-Router protocol stack. Deployment is early-stage as of mid-2026.

How Netdata helps

Netdata correlates BGP signals across your monitoring stack to surface route leaks and hijacks before traffic is impacted.

• BGP session state and prefix count tracking per peer provides the baseline against which sudden changes are measured, turning a raw counter into an anomaly signal.
• RPKI validation state collected from router CLI or SNMP can be correlated with per-peer prefix count changes to identify high-confidence hijacks with evidence.
• SNMP-based BGP metrics (peer state at .1.3.6.1.2.1.15.3.1.2, bgpPeerInUpdates, prefix counts) are collected automatically and support custom alert thresholds.
• Syslog correlation ties BGP NOTIFICATION messages and Cease subcodes to the exact session and timestamp, building the event timeline needed during triage.
• BGP RIB size monitoring per VRF catches sudden prefix-count spikes that indicate a leak is being accepted, before downstream impact.
• Cross-signal correlation between interface utilization, flow data, and BGP state helps distinguish “routing changed” from “link is down” or “traffic declined” during active incidents.

Related guides

• NetFlow storage sizing: how much disk your flow collector really needs
• Flow export-to-ingest latency: why your NetFlow data is minutes behind
• Network monitoring checklist: the signals every production network needs
• NetFlow v9/IPFIX template desync: flows decoded wrong or dropped after a reboot
• Silent UDP flow data loss: why your NetFlow collector is dropping records
• NetFlow vs sFlow vs IPFIX: what they measure and how each one fails
• sFlow sampling rate: why your traffic totals are off by 1000x
• SNMP counter discontinuity after reboot: bogus rate spikes explained
• SNMP counter rollover: fake traffic spikes from 32-bit counters
• SNMP poll response latency: diagnosing a slow poller
• SNMP poller falling behind: the polling-storm cascade and how to catch it
• SNMP timeouts and retries: why devices show as down when they aren’t