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.

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”

1. Use the Notification tab to set up notification preferences.

2. Save and enable the rule, ensuring alerts trigger in near real-time (1-minute granularity).

3. 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.

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.

• To investigate the routing events that triggered an alert, see Visualizing BGP Routes and Using the BGP Updates Table.

• To understand route origin validation and RPKI status, see Monitoring RPKI Status.