Detection Types
What each BGP detection means, and how we assign severity and confidence.
Anomalous vs. steady
Every detection is evaluated twice: first “is this a violation?”, then “is this violation new?” The second question is answered against a rolling 30-day baseline. A violation seen before in that window is a known, long-standing condition and is marked steady; one never seen in the window is anomalous.
The internet carries an enormous amount of permanent policy violation (routes that have been RPKI-invalid for years, unregistered legacy space, and so on). None of that should page anyone. What matters is change, so each type carries two severities: one for the anomalous case, one for the steady case. Alerting only ever considers anomalous incidents.
How alerts are delivered
Every alert appears in your in-app feed. Other channels depend on severity:
- High and critical alerts are emailed within the hour, grouped into one message.
- Medium, low and info alerts go into one email digest a day, sent at 10:00 New York time.
- Slack, Discord and webhook channels receive every alert as it happens.
To get fewer alerts, untick detection types on a monitor. New Origin also lets you pick which of its severities to receive.
When an alert repeats
You get one alert when an incident opens. An incident closes once the route stops being announced. If the same thing happens again after that, it is a new incident and a new alert.
| Detection | Severity (anomalous / steady) | Confidence |
|---|---|---|
|
rpki_invalid_asn
RPKI Invalid Origin
|
high
/
info
|
high |
|
rpki_invalid_length
RPKI Invalid Length
|
high
/
info
|
high |
|
moas_conflict
MOAS Conflict
|
high
/
info
|
medium |
|
origin_mismatch_new
New Origin
|
high
/
info
|
medium |
|
irr_invalid_asn
IRR Origin Mismatch
|
medium
/
info
|
medium |
|
reserved_as_in_path
Reserved AS in Path
|
medium
/
low
|
high |
|
unallocated_as_in_path
Unallocated AS in Path
|
medium
/
low
|
high |
|
path_loop
AS Path Loop
|
medium
/
low
|
high |
|
first_as_violation
First-AS Violation
|
medium
/
low
|
medium |
|
new_prefix
New Prefix
|
low
/
info
|
low |
|
unregistered_route
Unregistered Route
|
low
/
info
|
medium |
|
roa_change
ROA Change
|
info
/
info
|
low |
|
irr_change
IRR Change
|
info
/
info
|
low |
|
visibility_drop
Visibility Drop
|
low
/
low
|
medium |
|
prefix_withdrawn
Prefix Withdrawn
|
medium
/
medium
|
high |
rpki_invalid_asn high
A ROA covers the prefix but the announced origin AS is not authorized by it.
rpki_invalid_length high
The origin is authorized by a covering ROA, but the announcement is more specific than the ROA's max length.
moas_conflict high
Two or more ASNs originate the same prefix within the concurrency window (multi-origin AS).
origin_mismatch_new high
A (prefix, origin) pair is absent from the 30-day baseline: never seen before, or returning after 30 or more days dormant.
- highAnother network announcing this space for the first time. This is the pattern a hijack follows.
- mediumA network that announced this space before, coming back after 30 or more days away.
- infoA network announcing a new, smaller prefix inside a block it already announces.
On a monitor you can receive all of these, medium and higher, or high only. New monitors start at medium and higher.
irr_invalid_asn medium
One or more IRR route objects exist for the exact prefix, and none match the origin AS.
reserved_as_in_path medium
A reserved or private-use ASN (e.g. an RFC 6996 private-range ASN) appears in the public AS path.
unallocated_as_in_path medium
A path ASN is not covered by any RIR delegation (allocated or assigned). Dampered against fresh allocations.
path_loop medium
The same ASN appears at non-adjacent positions in the AS path (legitimate prepending is excluded).
first_as_violation medium
The peer that exported the route is not the first AS in the path, and the peer is not a known route server.
new_prefix low
A (prefix, origin) pair appears with no prior origin history in the registry or baseline. The prefix itself is new; this is not a mismatch.
unregistered_route low
The route has neither RPKI ROA coverage nor any IRR route object.
roa_change info
A covering RPKI ROA for the prefix was added, removed, or had its authorized origin / max-length changed between reference snapshots.
irr_change info
An IRR route object authorizing an origin for the prefix was added or removed between reference snapshots.
visibility_drop low
A prefix consistently seen by many peers over its 30-day baseline dropped to near-zero distinct peers across the recent multi-day window. BGPHorizon ingests BGP updates, not full routing tables, so this means the prefix stopped appearing, not necessarily that it was withdrawn.
prefix_withdrawn medium
A prefix went dark, and per-peer net-state reconstruction shows the last event from nearly every peer was a withdrawal with almost none still announcing it. The confirmed form of a visibility drop.