Monitoring route origin and AS-path changes for hijack detection

BGP route hijacks do not announce themselves. A prefix legitimately originated by AS2906 starts appearing in the global table with origin AS65001. Traffic that should reach your infrastructure follows a different path, gets blackholed, or lands on an interception point. The control-plane signals are there, but they are distributed across route collectors, RPKI validators, and per-prefix state that most monitoring stacks do not track at the granularity needed.

BGP has no built-in origin authentication. Any autonomous system can announce any prefix. Detection depends on comparing what you observe against what you expect: known-good origin ASes, baseline AS-path structures, and signed Route Origin Authorizations (ROAs). The gap between “BGP session is Established” and “the routes I am receiving are legitimate” is where hijacks live.

This article covers the security-lens signals that complement the broader route-leak and hijack detection in BGP route leak and hijack: the detection signals and alerts that matter. If you are investigating a suspected hijack or building proactive detection, the signals and commands below are the operational starting points.

What this means

Route origin and AS-path changes indicate one of three scenarios: a legitimate network change (planned renumbering, new peering, traffic engineering), a misconfiguration (fat-finger typo, stale IRR objects, wrong export filter), or a deliberate hijack. Distinguishing these requires layered evidence.

The primary detection signal is Multiple Origin AS (MOAS) conflict: a prefix appearing in the global routing table with more than one origin AS. MOAS is not inherently malicious. Anycast services, multi-homed networks with different ASNs at different sites, and reserved ASN usage in private networks all produce legitimate MOAS. But an unexpected MOAS on a prefix that has historically had a single origin AS is a candidate event requiring investigation.

The secondary signal is AS-path deviation: the sequence of ASNs between your network and the origin differs from the baseline structure. The useful signal is not “the path changed” but “the path changed in a way that introduces an AS that should not be there, or removes an AS that should be.”

The third layer is RPKI validation state. A Route Origin Authorization cryptographically binds a prefix to an origin AS. When a route’s origin AS does not match the ROA, the route is RPKI-invalid. Any RPKI-invalid route accepted in production is a security event.

flowchart TD
    A["Unexpected origin AS or AS-path change"] --> B{"RPKI state?"}
    B -->|Invalid| C["High-confidence hijack or misconfig"]
    B -->|Unknown, no ROA| D["Needs AS-path baseline comparison"]
    B -->|Valid| E["Possible route leak or legitimate change"]
    C --> F["Page security team, filter inbound"]
    D --> G["Check looking glass, BMP, peer prefix counts"]
    E --> H{"Matches change ticket?"}
    H -->|Yes| I["Monitor for convergence"]
    H -->|No| J["Investigate as route leak"]
    G --> K{"Matches known-good origin?"}
    K -->|No| F
    K -->|Yes| L["Update baseline"]

A critical limitation: SNMP-based BGP monitoring (BGP4-MIB) cannot detect most origin and AS-path changes in real time. The bgp4PathAttrTable is defined to include all received paths, but many vendor implementations only expose best-path data, and SNMP polling is too slow for real-time detection regardless. To detect origin changes, AS-path manipulation, and sub-prefix hijacks, you need BMP (RFC 7854), external route collectors (RouteViews, RIPE RIS), or a dedicated BGP monitoring platform.

Common causes

Quick checks

These are read-only and safe to run on any production router.

# Check BGP peer state and per-peer prefix counts
ssh <router> 'show ip bgp summary | begin Neighbor'

# List all BGP peers and their remote ASNs via SNMP
snmpwalk -v2c -c <community> <router> .1.3.6.1.2.1.15.3.1.1   # peer addresses
snmpwalk -v2c -c <community> <router> .1.3.6.1.2.1.15.3.1.9   # remote ASNs

# Check for RPKI-invalid routes accepted in the RIB
# Syntax varies by vendor and OS version; IOS-XR uses this form
ssh <router> 'show bgp ipv4 unicast rpki invalid'

# Check the AS-path for a specific prefix
ssh <router> 'show ip bgp <prefix>'

# Compare routes received vs advertised for a specific peer
# NOTE: received-routes requires soft-reconfiguration inbound on IOS/IOS-XE;
# without it, the router returns an error or shows only post-policy routes
ssh <router> 'show ip bgp neighbor <peer> received-routes | include Total'
ssh <router> 'show ip bgp neighbor <peer> advertised-routes | include Total'

# Check RIB/FIB size for sudden changes
ssh <router> 'show ip route summary'

# Cross-reference with a public route collector
# Query RouteViews, RIPE RIS, or a public looking glass to verify
# what the global table sees for your prefix

The show ip bgp <prefix> command is the single most useful check during an active investigation. It shows the AS-path, origin AS, and RPKI state for a specific prefix from the router’s perspective. If the origin AS does not match what you expect, you have a candidate event.

For prefixes you originate, cross-reference what the global table sees by querying a public route collector. If your prefix appears with a different origin AS from the global perspective but not from your router’s perspective, the hijack is propagating from a different part of the network.

How to diagnose it

1. Identify the affected prefix and expected origin AS. Pull from your ROA records, IRR objects, or baseline AS-path data. If you have no recorded baseline, establish one now from a public route collector.

2. Check RPKI validation state. Run show bgp ipv4 unicast rpki invalid on your edge routers. Any nonzero result is a security event. If RPKI shows “Unknown” (no ROA exists), you cannot rely on RPKI alone. Cross-reference with AS-path baseline data from your BMP station or external monitoring. “Unknown” is the most common RPKI state in production.

3. Check per-peer prefix counts. A sudden increase from one peer suggests a route leak from that peer. Compare received-routes count against the peer’s expected prefix count. A drop in per-peer prefix count without a session state change may indicate a silent route withdrawal or a filtering change upstream.

4. Examine the AS-path structure. For each candidate prefix, determine whether the AS-path contains ASNs that should not be there. If your BMP station or route collector has historical data, compare the current path against the baseline. A path that introduces a new AS-link pair (two ASNs adjacent that have never been adjacent before) is suspicious.

5. Check for sub-prefix hijacks. A /32 or /48 injected from an unexpected origin can override a legitimate /24 or /48 aggregate due to longest-prefix-match routing. The covering aggregate may remain in the table from the legitimate origin, making the hijack invisible if you only monitor the aggregate. Query the full table for all more-specifics of your critical prefixes.

6. Verify with external sources. Cross-reference against public route collectors (RouteViews, RIPE RIS) and RPKI validators (RIPEstat, Routinator). If your local cache is stale, RPKI state may be incorrect. Verify with at least one external validator before acting on an RPKI-invalid alert.

7. Check for unauthorized BGP session establishment. A session from a peer IP or remote AS not in your expected peer list indicates misconfiguration or attack. Verify all peers against your configured peer list using show ip bgp summary. Review firewall and ACL logs for TCP port 179 connections from unexpected sources.

Metrics and signals to monitor

Fixes

RPKI-invalid routes accepted

Enable strict RPKI Route Origin Validation (ROV) on import policy. This rejects routes whose origin AS does not match the ROA. The trade-off: if your RPKI validator cache is stale or misconfigured, legitimate routes may be rejected. Always verify cache health before enforcing strict ROV.

If a specific RPKI-invalid route is already in the RIB, filter it inbound from the offending peer and coordinate with the peer to investigate.

Route leak from upstream

Identify the source peer from per-peer prefix count growth. Filter the leaked prefixes inbound. Coordinate with the peer to stop the leak at the source. If you are the source, withdraw the leaked prefixes immediately and announce corrective action. Check your export filters and IRR/RPSL objects.

Sub-prefix hijack

Sub-prefix hijacks are harder to prevent because longest-prefix-match routing favors the more-specific. Detection requires monitoring for more-specifics of your critical prefixes from unexpected origins. Originating your own covering aggregate with a matching ROA provides cryptographic protection for prefixes you control. For prefixes you do not control, the only defense is detection and coordination with upstreams to filter the hijack.

AS-path poisoning

AS-path prepending attacks insert the victim’s AS into the attacker’s announcement, making the path look legitimate to origin-based checks. These are invisible to MOAS-only detection and to RPKI if the attacker uses the victim’s origin AS. Detection requires AS-path structural analysis: the path contains an AS-link pair that has never been observed in baseline data. BMP and external route collectors provide the historical data needed for this analysis.

Fat-finger origin AS typos

Single-digit ASN transcription errors (for example, AS29596 configured as AS2959) produce origin changes that look like hijacks but are configuration errors. If the edit distance between the expected and observed origin ASN is 1, treat as likely human error. Verify with the peer before escalating.

Prevention

Deploy BMP (RFC 7854). BMP provides Adj-RIB-In visibility (pre-policy and post-policy routes), per-prefix real-time streaming, and withdrawal tracking. Without BMP, you cannot detect AS-path changes, sub-prefix hijacks, or origin changes in real time via SNMP.

Create ROAs for all prefixes you originate. RPKI ROAs cryptographically bind your prefixes to your origin AS. Without a ROA, your prefix is RPKI “Unknown” and downstream networks cannot use RPKI to detect a hijack of your space.

Enforce strict RPKI ROV on import. Reject RPKI-invalid routes at your edge. This protects your network from accepting hijacked prefixes.

Maintain AS-path baselines. Record the expected AS-path structure for your critical prefixes and upstreams. Alert on new AS-link pairs (two ASNs adjacent that have never been observed before). This catches AS-path poisoning attacks that evade origin-based checks.

Monitor for sub-prefix hijacks. Alert when a more-specific of a critical prefix appears without the covering aggregate in the RIB, or when a more-specific appears from an origin AS that does not match the aggregate’s origin.

Filter private and reserved ASNs. Apply bogon filtering (RFC 1918, RFC 5735, RFC 6598 for CGNAT space) before scoring route changes. Private ASNs in AS-path are sometimes legitimate multi-homing artifacts but are also a source of false positives.

Track ASPA deployment. ASPA (Autonomous System Provider Authorization) verification extends RPKI beyond the origin AS to verify the entire AS_PATH against registered provider-customer relationships. It detects route leaks, improbable AS paths, and forged-origin hijacks that RPKI-ROV alone misses. ASPA is currently an IETF draft; track the active revision on the IETF SIDROPS working group page.

How Netdata helps

• Correlate BGP state changes with traffic impact. When an origin AS change or RPKI-invalid route appears, Netdata correlates the timing with interface traffic, latency probes, and flow data to confirm whether the hijack is actually affecting user traffic.
• Monitor per-peer prefix count trends. Netdata’s time-series storage of per-peer BGP prefix counts makes sudden increases (route leaks) and decreases (upstream issues) immediately visible without manual CLI queries.
• Alert on RPKI state transitions. Track the count of RPKI-invalid routes over time and alert on any nonzero value in production, or on a sudden increase in the RPKI “Unknown” rate (which may indicate validator cache staleness).
• Cross-reference with BGP NOTIFICATION events. A Cease/1 (Maximum Prefixes) from a peer often coincides with a route leak. Correlating Cease messages with per-peer prefix count changes narrows the investigation quickly. See BGP NOTIFICATION and Cease messages.
• Detect stale sessions masking route loss. A session in Established state that stops receiving updates can mask a hijack’s impact if the stale routes are being overridden by the hijacked path elsewhere. See BGP session Established but stale.
• Layer with RIB and FIB growth monitoring. Sudden RIB growth from a single peer is the leading indicator of a route leak. See BGP RIB and FIB growth.

Related guides

• ARP cache staleness: when IP-to-MAC mapping goes bad
• Asymmetric routing: why your path and latency measurements lie
• Audit log gaps: detecting syslog/trap tampering or loss
• BGP flapping: why a peer keeps resetting and how to find the cause
• BGP NOTIFICATION and Cease messages: what each subcode is telling you
• BGP RIB and FIB growth: monitoring route-table size before it bites
• BGP route leak and hijack: the detection signals and alerts that matter
• BGP session Established but stale: detecting silent route loss
• Correlating cloud VPC flow logs with on-prem NetFlow
• Cold-start topology: why your map is incomplete after a collector restart
• Collector CPU and TSDB write-queue saturation: the capacity signals
• NIC RSS misconfiguration: one CPU core silently dropping your telemetry