> For the complete documentation index, see [llms.txt](https://docs.thousandeyes.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thousandeyes.com/product-documentation/tests/bgp-tests/bgp-alerts.md).

# Configuring BGP Alerts

Border Gateway Protocol (BGP) is the backbone of internet routing, enabling the exchange of routing information between Autonomous Systems (ASes) to direct traffic across the global internet. Monitoring BGP routing is critical for organizations to ensure network reliability, security, and performance, as BGP issues like hijacks, route leaks, or misconfigurations can lead to service disruptions, data breaches, or degraded user experiences. ThousandEyes’ BGP Monitoring provides visibility into routing dynamics, leveraging public and private monitors to track prefixes, AS paths, and reachability.

For more information about working with alert rules, see [Creating and Editing Alert Rules](https://docs.thousandeyes.com/product-documentation/alerts/creating-and-editing-alert-rules).

## Alerting on Routing Reachability

Alerting on routing reachability enables network operators to monitor the availability of their prefixes and detect routing issues or attacks. **Reachability (%)** in ThousandEyes measures the percentage of BGP monitors that have an existing route to a target prefix (exactly matching the prefix) in their routing tables. A value of 100% indicates the prefix is exactly reachable across all monitors, while a lower percentage (for example, <100%) suggests potential routing issues, such as prefix withdrawals, blackholing, or hijacks.

### Use Cases for Alerting on BGP Reachability

* Identify when a prefix becomes unreachable, causing service disruptions or traffic blackholing. Alerts on **<** a threshold (for example, <90%) detect potential outages.
* Verify that critical prefixes are available worldwide, which is essential for global applications like CDNs or SaaS platforms. Alerts on **>** a threshold (for example, >99%) confirm global availability.
* Track Reachability changes during dynamic routing events, such as DDoS mitigation or ISP failover, to ensure correct routing behavior. Alerts on **<** a threshold verify mitigation-induced changes, while **>** alerts confirm post-event stability.
* Meet regulatory or organizational requirements for prefix availability, critical for industries like finance or government. Alerts on **<** a threshold (for example, <99%) enforce compliance with standards like NIST or GDPR.
* Detect when a prefix is advertised incorrectly, reducing Reachability due to non-existing or unintended routing paths. Alerts on **<** a threshold may identify potential leaks.
* Detect when a prefix is advertised when it should not be present in BGP, increasing Reachability to unintended destinations. Alerts on **>** a threshold (even 0%) identify potential squatting attacks.

### Configuring Routing Reachability Alerts

To set up reachability alerts:

1. Navigate to **Manage > Alert Rules** in the ThousandEyes dashboard and select the **Routing** tab.
2. Create a new **BGP Alert Rule** or edit an existing one.
3. Add a new condition by clicking on the **+** symbol at the lower right corner of the screen.
4. Select **Reachability** from the dialog and set the conditions for the alert to trigger:
   * **>**: “Reachability > 99%” (for example, to confirm high availability)
   * **<**: “Reachability < 90%” (for example, to detect outages)
5. Use the **Notification** tab to set up notification preferences.
6. Save and enable the rule, ensuring alerts trigger in near real-time (1-minute granularity).
7. Link this alert to a BGP test or tests with BGP data enabled (for example, Network Tests with **Collect BGP Data**) from **Network & App Synthetics > Test Settings**.

## Alerting on Routing Path Changes

Alerting on the number of path changes allows operators to monitor the stability of BGP routes, as frequent or unexpected changes in the AS path (the sequence of ASes a route traverses) can indicate routing issues, security threats, or performance degradation. The **Path Changes** metric in ThousandEyes represents the number of AS path changes that a monitor reports during a test round.

### Use Cases for Alerting on Number of Path Changes

* Identify unstable routes oscillating between paths, causing packet loss or latency. Alerts on **>** a threshold (for example, more than one change during a test round) detect flapping.
* Detect malicious ASes causing path instability to hijack traffic. Alerts on **>** a threshold flag excessive changes indicative of hijacks.
* Ensure stable routing during peering updates or ISP failovers, verifying compliance with agreements. Alerts on **<** a threshold (for example, <1 change) confirm stability post-change, while **>** alerts detect unexpected shifts.
* Meet regulatory or organizational requirements for stable routing to support critical applications. Alerts on **>** a threshold enforce stability standards (for example, NIST).
* Maintain stable routes for latency-sensitive applications (for example, VoIP, gaming, trading) by monitoring path changes. Alerts on **>** a threshold identify instability affecting performance.
* Monitor path changes during DDoS mitigation, where routes may shift to a mitigation provider’s AS, ensuring availability during the DDoS attack. Alerts on **>** a threshold verify mitigation-induced changes, while **<** alerts confirm post-mitigation stability.

### Configuring Routing Path Change Alerts

To set up path change alerts:

1. Navigate to **Manage > Alert Rules** in the ThousandEyes dashboard and select the **Routing** tab.
2. Create a new **BGP Alert Rule** or edit an existing one.
3. Add a new condition by clicking on the **+** symbol at the lower right corner of the screen.
4. Select **Path Changes** from the dialog and set the conditions for the alert to trigger:
   * **>**: “Path Changes > 1” (for example, more than one change during a test round)
   * **<**: “Path Changes < 1” (for example, fewer than one change during a test round)
5. Use the **Notification** tab to set up notification preferences.
6. Save and enable the rule, ensuring alerts trigger in near real-time (1-minute granularity).
7. Link this alert to a BGP test or tests with BGP data enabled (for example, Network Tests with **Collect BGP Data**) from **Network & App Synthetics > Test Settings**.

### Example: Detecting Frequent Path Changes

Use **Path Changes** as a routing condition to detect route flapping for a critical prefix. The following example uses sample values. Replace them with values that match your routing policy.

| Alert Rule Field          | Example Value                                                               |
| ------------------------- | --------------------------------------------------------------------------- |
| **Condition Reference**   | **Path Changes**                                                            |
| **Path Changes**          | `> 3 changes during a test round`                                           |
| **Monitors**              | The BGP monitors for the sites you want to check                            |
| **Global Alert Criteria** | The same monitor meets the condition during two of three consecutive rounds |

This rule alerts when the same monitor reports more than three path changes during at least two of three consecutive test rounds.

## Alerting on Routing Prefix

Alerting on whether a prefix is in or not in a specified value enables network operators to monitor the presence or absence of specific prefixes in BGP routing tables, detecting issues like unauthorized announcements, misconfigurations, or routing policy violations. A prefix in BGP is an IP address block, defined by a network address and subnet mask (for example, `192.0.2.0/24`), that an Autonomous System (AS) advertises to indicate reachability. Prefixes are the fundamental units of BGP routing, specifying destinations for internet traffic. In ThousandEyes, alerting on whether a prefix is **"in" a specified value** means it matches a defined prefix or range (for example, `192.0.2.0/24` or any /24 prefix), while **"not in" a specified value** means it deviates from the expected prefix or range, or an unexpected prefix is advertised.

### Use Cases for Alerting on Routing Prefix

* Identify unauthorized prefix announcements that could redirect traffic to malicious destinations. Alerts on a prefix **not in** (for example, unexpected `192.0.2.0/25`) detect potential sub-prefix hijacks.
* Detect errors in prefix announcements that cause traffic misrouting or blackholing. Alerts on a prefix **not in** (for example, incorrect `192.0.2.0/25` instead of `192.0.2.0/24`) or **in** identify misconfigurations.
* Ensure only authorized prefixes are advertised, aligning with organizational or regulatory policies. Alerts on prefixes **in** (for example, only `192.0.2.0/24`) or **not in** enforce compliance.
* Verify prefix announcements during dynamic routing changes, such as DDoS mitigation or ISP failover, to ensure correct routing. Alerts on prefixes **in** confirm mitigation provider or failover prefixes, while **not in** alerts detect errors.
* Detect when a prefix is advertised incorrectly, causing traffic to take unintended paths. Alerts on prefixes **not in** identify potential leaks.

### Configuring Routing Prefix Alerts

To set up prefix alerts:

1. Navigate to **Manage > Alert Rules** in the ThousandEyes dashboard and select the **Routing** tab.
2. Create a new **BGP Alert Rule** or edit an existing one.
3. Add a new condition by clicking on the **+** symbol at the lower right corner of the screen.
4. Select **Prefix** from the dialog and set the conditions for the alert to trigger:
   * **in**: “Prefix = 192.0.2.0/24”
   * **not in**: “Prefix ≠ 192.0.2.0/24”
5. Use the **Notification** tab to set up notification preferences.
6. Save and enable the rule, ensuring alerts trigger in near real-time (1-minute granularity).
7. Link this alert to a BGP test or tests with BGP data enabled (for example, Network Tests with **Collect BGP Data**) from **Network & App Synthetics > Test Settings**.

## Alerting on Routing Covered Prefix

Alerting on whether a covered prefix is in or not in a given value, or if it exists at all, enables network operators to monitor routing integrity, detect security threats, enforce policy compliance, and optimize traffic flow. A covered prefix in BGP refers to a more specific IP prefix that falls within the range of a less specific prefix announced by an AS. For example, if an AS advertises `192.0.2.0/24` (less specific), a covered prefix might be `192.0.2.0/25` (more specific), as its address space is a subset of the address space of the larger prefix. Covered prefixes are typically advertised by the same or a different AS than the less specific prefix, often for traffic engineering, load balancing, or sub-delegation to customers.

In ThousandEyes, a covered prefix is monitored relative to a target prefix specified in a BGP Test, allowing alerts to trigger based on whether a more specific prefix exists (if any prefix is advertised under the target prefix, regardless of its value), matches a given value, or doesn't match a given value. Not matching could indicate an unexpected or unauthorized announcement.

### Use Cases for Alerting on Covered Prefixes

* Identify malicious or unauthorized covered prefix announcements that could redirect traffic, compromising security. Alerts on a covered prefix **not in** or **exists** when none are expected detect potential sub-prefix hijacks.
* Detect errors in prefix announcements or ROA configurations that cause routing issues or blackholing. Alerts on a covered prefix **in** or **not in** identify misconfigurations.
* Ensure only authorized covered prefixes are advertised, aligning with organizational or regulatory policies. Alerts on covered prefixes **in** enforce compliance.
* Verify that covered prefixes are advertised as intended for load balancing or regional routing, ensuring optimal traffic flow. Alerts on covered prefixes **exists** or **in** confirm traffic engineering goals.
* Detect unexpected covered prefix announcements or withdrawals that could indicate upstream issues, route leaks, or attacks. Alerts on covered prefixes **not in** or **existing** highlight anomalies.

### Configuration in ThousandEyes

To set up covered prefix alerts:

1. Navigate to **Manage > Alert Rules** in the ThousandEyes dashboard and select the **Routing** tab.
2. Create a new **BGP Alert Rule** or edit an existing one.
3. Add a new condition by clicking on the **+** symbol at the lower right corner of the screen.
4. Select **Covered Prefix** from the dialog and set the conditions for the alert to trigger:
   * **In**: “Covered Prefix = 192.0.2.0/25”
   * **Not in**: “Covered Prefix ≠ 192.0.2.0/25”
   * **Exists**: “Covered Prefix Exists”
5. Use the **Notification** tab to set up notification preferences.
6. Save and enable the rule, ensuring alerts trigger in near real-time (1-minute granularity).
7. Link this alert to a BGP test or tests with BGP data enabled (for example, Network Tests with **Collect BGP Data**) from **Network & App Synthetics > Test Settings**.

## Alerting on ASN Presence or Absence

Alerting on whether an ASN is in or not in specific parts of the BGP route enables network operators to monitor routing behavior, detect security threats, enforce peering agreements, and ensure compliance with routing policies. Each condition targets different aspects of the AS path:

* **BGP Origin**: The AS that originates (announces) the prefix. Alerting on the Origin ASN ensures the prefix is advertised by the expected AS, critical for preventing hijacks.
* **Any BGP Hop**: Any AS in the AS path, including transit or peering ASes. Alerts detect unexpected or unauthorized ASes anywhere in the route.
* **No BGP Hop**: Ensures a specific AS is absent from the entire AS path, useful for avoiding undesirable or untrusted ASes.
* **Specific BGP Hop Number**: Monitors whether an AS appears at a particular position in the AS path (for example, the 2nd hop), useful for validating specific peering or transit relationships.

### Use Cases for Alerting on ASN Presence or Absence

* Identify unauthorized ASes announcing a prefix to prevent traffic redirection or data theft. Alerts on **BGP Origin** for unexpected ASNs or **Any BGP Hop** for malicious ASes detect potential hijacks.
* Ensure traffic follows agreed-upon routes through specific transit or peering ASes, avoiding costly or inefficient paths. Alerts on **Specific BGP Hop Number** verify a partner’s AS at a designated hop (for example, 2nd hop), while **No BGP Hop** alerts detect routing through undesirable ASes.
* Detect when a prefix is advertised incorrectly, causing traffic to take unintended paths. Alerts on **Any BGP Hop** for unexpected ASes or **BGP Origin** for incorrect origins identify potential leaks.
* Meet regulatory or organizational requirements by avoiding untrusted ASes or ensuring authorized prefix announcements. Alerts on **No BGP Hop** detect routes through sanctioned or untrusted ASes, while **BGP Origin** alerts ensure only approved ASes advertise prefixes.
* Maintain low-latency, high-performance routes for critical applications by monitoring ASNs in the path. Alerts on **Hop #** or **Any BGP Hop** ensure traffic uses preferred ASes, while **No BGP Hop** avoids high-latency ASes.

### Configuration in ThousandEyes

To set up ASN alerts:

1. Navigate to **Manage > Alert Rules** in the ThousandEyes dashboard and select the **Routing** tab.
2. Create a new **BGP Alert Rule** or edit an existing one.
3. Add a new condition by clicking on the **+** symbol at the lower right corner of the screen.
4. Select **BGP Origin**, **Any BGP Hop**, **No BGP Hop**, or **BGP Hop #** from the dialog. Set the conditions for each ASN:
   * **BGP Origin**, ASN **in**/**not in**: “ASN = AS12345” or “ASN ≠ AS12345”.
   * **Any BGP Hop**, ASN **in**/**not in**: “ASN = AS67890” (present) or “ASN ≠ AS67890” (absent).
   * **No BGP Hop**, ASN **in**/**not in**: “ASN ≠ AS11223” (ensure absent from entire path).
   * **BGP Hop #**, **monitor**/**origin**, ASN **in**/**not in**: “ASN = AS45678 at Hop 2”.
5. Use the **Notification** tab to set up notification preferences.
6. Save and enable the rule, ensuring alerts trigger in near real-time (1-minute granularity).
7. Link this alert to a BGP test or tests with BGP data enabled (for example, Network Tests with **Collect BGP Data**) from **Network & App Synthetics > Test Settings**.

### Example: Detecting an Unexpected Origin AS

Use **BGP Origin** as a routing condition to detect when a prefix is originated by an unexpected AS. The following example uses sample values. Replace them with values that match your routing policy.

| Alert Rule Field        | Example Value                                    |
| ----------------------- | ------------------------------------------------ |
| **Prefix**              | `in 192.0.2.0/24`                                |
| **Condition Reference** | **BGP Origin**                                   |
| **BGP Origin**          | `not in AS64496`                                 |
| **Monitors**            | The BGP monitors for the sites you want to check |

This rule alerts when the selected monitors report `192.0.2.0/24` with an origin other than `AS64496`.

### Example: Detecting an Unexpected Upstream AS

Use **BGP Hop #** as a routing condition to detect when a route uses an unexpected upstream AS.

| Alert Rule Field        | Example Value                                        |
| ----------------------- | ---------------------------------------------------- |
| **Prefix**              | `in 192.0.2.0/24`                                    |
| **Condition Reference** | **BGP Hop #**                                        |
| **BGP Hop #**           | At the hop adjacent to the monitor, `not in AS64498` |
| **Monitors**            | The BGP monitors for the sites you want to check     |

This rule alerts when the selected monitors report the route through an AS other than `AS64498` at the hop adjacent to the monitor. If the upstream AS can appear at different positions in the path, use **Any BGP Hop** instead.

## Alerting on Routing RPKI Status

Alerting on RPKI status enables network operators to monitor the validity of BGP route announcements in near real-time, detecting potential security threats, misconfigurations, or policy violations that could disrupt network operations or compromise data integrity. RPKI status can be *Valid* (route matches a valid ROA), *Invalid* (route violates all valid ROAs, for example, wrong AS or prefix length), or *NotFound* (no valid ROA exists for the prefix).

### Use Cases for Alerting on RPKI Status

* Identify unauthorized prefix announcements that could redirect traffic to malicious destinations, compromising data security. Alerts on **Invalid** RPKI status when a prefix is announced by an unauthorized AS, enabling rapid mitigation (for example, filtering the route).
* Detect errors in BGP announcements or ROA configurations that cause routing failures or blackholing. Alerts on **Invalid** or **Not Found** statuses highlight misconfigured prefixes or ROAs (for example, wrong `maxLength` in a ROA).
* Meet regulatory or industry requirements for secure routing by validating all prefixes against RPKI. Alerts on **Not Found** statuses identify prefixes lacking ROAs, ensuring compliance with standards like NIST or GDPR.
* Track and prioritize RPKI adoption to secure prefixes against hijacking risks. Alerts on **Not Found** statuses highlight unprotected prefixes, prompting ROA creation.
* Monitor RPKI status changes during DDoS mitigation, where prefixes may shift to a mitigation provider’s AS, ensuring valid routing. Alerts on **Invalid** or **Valid** status changes verify mitigation provider announcements align with ROAs.

### Configuration in ThousandEyes

To set up an RPKI status alert:

1. Navigate to **Manage > Alert Rules** in the ThousandEyes dashboard and select the **Routing** tab.
2. Create a new **BGP Alert Rule** or edit an existing one.
3. Add a new condition by clicking on the **+** symbol at the lower right corner of the screen.
4. Select **RPKI Status** from the dialog and set the conditions for the alert to trigger:

* **Valid**: "RPKI Status = Valid"
* **Invalid**: “RPKI Status = Invalid”
* **NotFound**: “RPKI Status = Not Found”

5. Use the **Notification** tab to set up notification preferences.
6. Save and enable the rule, ensuring alerts trigger in near real-time (1-minute granularity).
7. Link this alert to a BGP test or tests with BGP data enabled (for example, Network Tests with **Collect BGP Data**) from **Network & App Synthetics > Test Settings**.

To learn more about RPKI, see [Monitoring RPKI Status](https://docs.thousandeyes.com/product-documentation/tests/bgp-tests/rpki).

## Alerting on AS Path Length

Alerting on AS Path Length allows network operators to monitor changes in the number of ASes a BGP route crosses, which can indicate routing inefficiencies, performance degradation, or potential security issues. Alerting on AS Path Length provides actionable insights into routing behavior, enhancing network reliability, performance, and security.

### Use Cases for Alerting on AS Path Length

* Identify when traffic takes unnecessarily long or inefficient routes, which can increase latency and degrade application performance. Alerts on AS Path Length increases (for example, path length > 5 ASes) flag routes that traverse additional ASes, prompting operators to optimize routing.
* Detect route leaks where a prefix is advertised through unintended ASes, causing traffic to take suboptimal or unauthorized paths. Alerts on unexpected AS Path Length increases identify potential leaks.
* Identify potential BGP hijacks where a malicious AS inserts itself into the path, extending the AS Path Length and redirecting traffic. Alerts on abnormal path length increases (for example, sudden jump from 3 to 6 ASes) signal possible hijacks.
* Ensure traffic adheres to agreed-upon routing paths, avoiding costly or inefficient transit providers. Alerts on path lengths deviating from expected values (for example, > 3 ASes) verify peering agreements.
* Meet organizational or regulatory requirements by maintaining short, secure AS paths for critical traffic. Alerts on path lengths exceeding policy thresholds (for example, > 4 ASes) enforce compliance with standards like NIST or GDPR.
* Track changes in AS Path Length during events like DDoS mitigation or ISP failover, ensuring that routing adjustments maintain performance. Alerts on path length changes (for example, increase by > 1 AS) verify intended routing shifts.
* Maintain low-latency routes for latency-sensitive applications (for example, VoIP, gaming, trading) by monitoring AS Path Length. Alerts on path length increases identify routes that could degrade performance.

### Configuration in ThousandEyes

To set up an AS Path Length alert:

1. Navigate to **Manage > Alert Rules** in the ThousandEyes dashboard and select the **Routing** tab.
2. Create a new **BGP Alert Rule** or edit an existing one.
3. Add a new condition by clicking on the **+** symbol at the lower right corner of the screen.
4. Select **Path Length** from the dialog and set the conditions for the alert to trigger by adding a numeric path length value (for example, “Path Length > 10”).
5. Use the **Notification** tab to set up notification preferences.
6. Save and enable the rule, ensuring alerts trigger in near real-time (1-minute granularity).
7. Link this alert to a BGP test or tests with BGP data enabled (for example, Network Tests with **Collect BGP Data**) from **Network & App Synthetics > Test Settings**.

## Learn More

* To create a test that monitors one prefix, see [Monitoring a Single Prefix](https://docs.thousandeyes.com/product-documentation/tests/bgp-tests/monitoring-a-single-prefix).
* To investigate the routing events that triggered an alert, see [Visualizing BGP Routes](https://docs.thousandeyes.com/product-documentation/tests/bgp-tests/using-the-bgp-route-visualization-view) and [Using the BGP Updates Table](https://docs.thousandeyes.com/product-documentation/tests/bgp-tests/using-the-bgp-updates-table).
* To understand route origin validation and RPKI status, see [Monitoring RPKI Status](https://docs.thousandeyes.com/product-documentation/tests/bgp-tests/rpki).