Overview
Catchpoint BGP Monitoring observes global routing behavior for your publicly-announced prefixes by collecting BGP route data from many autonomous system peers around the world. It helps you verify that your prefixes are reachable and that routing information for those prefixes remains consistent, including detection of suspicious routing behavior such as unexpected more specific announcements that can indicate a potential hijack.
Each BGP test you create in Catchpoint represents a prefix that Catchpoint treats as expected to be announced by your organization. The set of monitored prefixes is the system’s expectation of what you legitimately originate.
This expectation directly influences hijack and prefix mismatch detection. The platform does not automatically assume that prefixes under a monitored parent are legitimate. A more specific prefix is only considered expected when it is also explicitly monitored.
Rule: If you announce it, monitor it. Catchpoint treats unmonitored more-specific prefixes as hijacks.
How Catchpoint evaluates a monitored prefix
For each monitored prefix, Catchpoint gathers routing visibility from many peers and tracks:
- Whether peers have a path to the prefix
- The route information peers report for the prefix, including origin and AS path
- More specific prefixes observed beneath the monitored prefix
Catchpoint can raise routing anomaly alerts based on unexpected origin or neighbor ASNs, and on the presence of unexpected more specific prefixes under a monitored prefix.
More specific announcements and hijack detection behavior
Catchpoint expects the monitored prefix itself to be announced. If peers report announcements that are more specific than the monitored prefix, Catchpoint treats those more specific prefixes as unexpected unless they are also being monitored as their own tests.
Example:
- If you monitor 8.8.8.0/23, Catchpoint expects 8.8.8.0/23 to be announced.
- If peers report 8.8.8.0/24 as well, that /24 is considered a prefix mismatch and can trigger a hijack style alert unless 8.8.8.0/24 is also monitored as a separate prefix.
What to monitor: practical guidance
Scenario 1: you announce only the parent prefix
If you originate only a parent prefix, monitor only that parent prefix.
Example:
- You announce 203.0.113.0/23
- You do not announce any /24s under it
Recommended monitoring:
- Create a test for 203.0.113.0/23
Behavior:
- If a /24 under that /23 appears, it is treated as unexpected more specific activity and may indicate a potential hijack.
Scenario 2: you announce the parent and also announce child prefixes under it
If you originate a parent prefix and also originate one or more specific prefixes under it, monitor every prefix you originate.
Example:
- You announce 203.0.113.0/23
- You also announce 203.0.113.0/24 and 203.0.114.0/24
Recommended monitoring:
- Create a test for 203.0.113.0/23
- Create a test for 203.0.113.0/24
- Create a test for 203.0.114.0/24
Behavior:
- When analyzing the /23, Catchpoint will still observe the /24s beneath it
- Because the /24s are also monitored, they are treated as legitimate announcements rather than hijacks
- You can view routing behavior for the /23 and for each /24 independently
You Need to Avoid Announcing a Hierarchy but Monitor only the Top Prefix
If you originate a broader prefix and originate more specific prefixes beneath it, but you monitor only the broader prefix, Catchpoint will treat the more specific prefixes as unexpected.
Example:
- You announce 198.51.100.0/22
- You also announce 198.51.100.0/23
- You also announce 198.51.100.0/24
If you monitor only:
- 198.51.100.0/22
Behavior:
- If the /23 or /24 are observed under the /22, they are treated as unexpected more specific activity, which can trigger hijack style alerts
You need to avoid this and create tests for each prefix you originate, not just the top level prefix.
Data Capture Limits when Not Monitoring All Announced Prefixes
When monitoring a broad prefix such as a /16, many more specific prefixes may be announced under it. If those more specific prefixes are not monitored as separate tests, Catchpoint will still capture them beneath the monitored prefix, but limits this to up to 10 more specific prefixes per peer in a given minute.
Because the limit is per peer and peers differ by network and geography, the set of captured more specific prefixes can vary:
- Different peers may report different sets of more specific prefixes
- The captured set can change over time
Additionally, because of how BGP works, and the limit being per minute, you could end up seeing in a given hour up to 600 different prefixes (in theory). The limit is there to ensure we capture true hijacks, and what the hijacking prefix was.
As a result, monitoring a broad prefix, without monitoring the more specific prefixes underneath it that you do announce, provides a sampled visibility of more specific activity under that space. It is not intended to represent a complete inventory of every child prefix that may be announced under the broad prefix.
Additionally, monitoring very broad prefixes can negatively impact UI and API responsiveness for that prefix because the volume of collected data can become very large. For IPv4, Catchpoint collects data from more than 900 peers and storing up to 10 more specific prefixes per peer for each announcement or withdrawal event can quickly increase the size of the underlying dataset.
Key takeaways
- A monitored prefix is treated as expected to be announced by your organization
- More specific prefixes are treated as legitimate only when they are also monitored as their own tests
- If you originate parent and child prefixes, monitor every prefix you originate to prevent legitimate more specific announcements from being flagged as hijacks
- For broad prefixes, Catchpoint captures only a sample of unmonitored more specific prefixes, limited to up to 10 per peer per minute. The captured set can vary by peer and over time.