Skip to main content

Alert Rules

Quick summary​

Select, configure and activate the alert rules for routing events you would like to be notified about. Click on Add Alert Rule to add a new alert rule. To remove an alert rule for an event you do not want to be notified about anymore, select it and click Delete. All active alert rules are displayed in the current page.

Alert rules can be configured with different parameters, like different type, origin ASes, neighbors, prefixes and notification channel options. Note that for correct alerting operation, you should setup properly your prefix filters besides the AS filters.

Alert rules can be sorted and filtered based on the following fields:

  • Name: the custom name assigned to the rule by the user.

  • Type: the type of the rule (and corresponding alert) according to the following table.

  • Time Created: the timestamp of the creation of the rule

    The (filtered) table can be exported in CSV format.

Supported alert rules​

Alert TypeSeverityDescription
Exact Prefix HijackCriticalIllegal origin ASes that announce configured prefixes.
Sub-Prefix HijackCriticalIllegal origin ASes that announce subprefixes of configured prefixes.
Route LeakCriticalUnexpected prefixes in the list of prefixes that are announced by configured ASes.
New NeighborWarningNew neighbors that appear to peer with configured ASes. Possible AS path manipulation.
Neighbor Leak/HijackCriticalNew neighbors that not only appear to peer with configured ASes, but also propagate their prefixes.
SquattingCriticalIllegal origin ASes announcing prefixes that are not currently announced by configured ASes.
Presence in AS PathWarningPresence of ASes in paths towards configured prefixes.
Invalid AS Path PatternWarningViolation of valid pattern by AS paths towards configured prefixes.
Long AS PathWarningPaths towards configured prefixes exceed a specified length threshold.
Prefix Visibility LossCriticalVisibility of prefix falls below a configured data source count threshold.
Peering Visibility LossCriticalVisibility of (AS-level) peering falls below a configured data source count threshold.
RPKI-Invalid DetectionCriticalRPKI-Invalid announcements of configured prefixes by other ASes.
RPKI-Invalid AnnouncementCriticalRPKI-Invalid announcements by configured ASes.
RPKI-Invalid PropagationWarningRPKI-Invalid routes propagated by configured ASes.
RPKI-NotFound PropagationWarningRPKI-NotFound routes propagated by configured ASes.
Bogon (Exact-)PrefixWarningAnnouncements of bogon prefixes by configured ASes.
Bogon (Sub-)PrefixWarningAnnouncements of bogon subprefixes by configured ASes.
Bogon ASWarningIn-path presence of bogon ASes, in routes towards configured prefixes.
AS Path ComparisonWarningDiscrepancies in AS paths towards the same prefix, comparing between different Data Services, up to a terminating (end) AS.
Prefix ComparisonWarningDiscrepancies in prefixes announced by configured ASes, comparing between different Data Services.
CustomUser-definedUser-defined.

These rules can be broadly categorized as follows:

Details​

Using our powerful BGPQL API we can subscribe to alertable BGP data and trigger alerts on demand when corresponding state data is detected via regexes, within seconds. Rules are in place to generate alerts according to user preferences. The data pipeline we employ for this is: Persistent State --> GraphQL --> Custom Alerts Provider --> Alertmanager|Persistent State --> Notification channel(s). Note that when the state data stops being alertable (i.e., the regex matches stop firing), alerts are automatically resolved. See also this page for more details on the displayed alerts via the Alertmanager, and this page for more details on the persistently stored (active or resolved) alerts.

Examples​

Neighbor Leak-Hijack​

Query: 

subscription InvalidNeighborsToWhichPrefixesAreAnnounced($origin_asn: bigint!, $neighbor_asns: [bigint!] = [], $prefixes: [cidr!] = []) {
  routes(
    where: {originAutonomousSystem: {number: {_eq: $origin_asn}}, neighborAutonomousSystem: {number: {_nin: $neighbor_asns}}, prefix: {network: {_in: $prefixes}}}
    order_by: {neighborAutonomousSystem: {number: asc}, prefix: {network: asc}}
  ) {
    neighborAutonomousSystem {
      number
    }
    prefix {
      network
    }
  }
}

Variables: 

{
  origin_asn: <asn>, 
  neighbor_asns: [<neighbor_1>,...,<neighbor_N>],
  prefixes: [<prefix_1>,...,<prefix_N>]
}

Regex: "^.*routes.*neighborAutonomousSystem.*$"

Description: New neighbors that propagate a prefix originated by a configured AS.

Resulting alert:

---ALERT START---

Status
firing

Started
12:28:22 UTC 2023-03-16

Ended
No

Severity
critical

Name
L-Root ICANN Neighbor Leak HJ

Type
Neighbor Leak/Hijack

Description
New neighbors that not only appear to peer with configured ASes, but also propagate their prefixes

Event
Neighbor AS6057 has leaked prefixes: 2001:500:9e::/47, 2001:500:9f::/48.

Configured Resources
AS20144 is configured to announce to neighbors AS10084, AS11170, AS1221, AS1239, AS12731, AS12883, AS1299, AS13004, AS13238, AS133210, AS133296, AS134376, AS13657, AS137409, AS138064, AS15348, AS15626, AS15954, AS16735, AS17557, AS1797, AS18200, AS1828, AS19653, AS199524, AS20144, AS2018, AS20766, AS208722, AS20912, AS210767, AS21282, AS22548, AS23028, AS23106, AS23550, AS24445, AS24482, AS2470, AS2495, AS24990, AS25091, AS263152, AS263237, AS263327, AS263508, AS264479, AS27678, AS27839, AS28186, AS28329, AS28496, AS28571, AS286, AS28634, AS29049, AS29075, AS2914, AS29432, AS29467, AS29504, AS29571, AS30781, AS31287, AS32098, AS3257, AS33544, AS33891, AS33920, AS34019, AS34177, AS3462, AS3491, AS35280, AS35313, AS35426, AS35600, AS36236, AS37045, AS37100, AS37468, AS38001, AS38880, AS39107, AS39138, AS395611, AS396998, AS40528, AS40994, AS42473, AS42961, AS44097, AS47445, AS47787, AS48287, AS49638, AS5056, AS50628, AS52320, AS52814, AS52871, AS52873, AS53046, AS53062, AS53070, AS57695, AS57801, AS59605, AS59613, AS61317, AS61573, AS61595, AS6697, AS6881, AS6939, AS7004, AS7195, AS7575, AS7590, AS7784, AS8218, AS8220, AS8265, AS8473, AS8522, AS8849, AS8966, AS9430, AS9790 the following no-announce prefixes: 192.0.37.0/24, 192.0.40.0/24, 192.0.41.0/24, 199.43.132.0/24, 199.7.82.0/23, 199.7.83.0/24, 199.7.94.0/24, 199.7.95.0/24, 2001:500:3::/48, 2001:500:8c::/48, 2001:500:9c::/48, 2001:500:9d::/48, 2001:500:9e::/47, 2001:500:9f::/48, 2602:800:9004::/48, 2620:0:22b0::/48, 2620:0:2ee0::/48.

---ALERT END---

Suppressing alerts​

Alerts can be silenced via the Alertmanager/Alerts tab. Moreover, you can edit rules (see this section), and add/adjust/remove parameters to include configurations that you may have forgotten at installation stage. The alerts will be auto-resolved and auto-regenerated with the new parameters if needed. For example, assume that you receive a Route Leak alert for a new prefix 10.0.0.0/8. You realize that you are actually announcing this prefix since a couple hours due to a policy update. The corresponding rule can be edited, by adding the prefix to the valid prefix list. After this is completed, the alert will be auto-resolved as long as no other leak is taking place. We warrant caution with this process since exceptions should be removed as long as they do not apply.

Screenshots​

Add a new Alert Rule​

Pre-made Exact Prefix Hijack Rule​

Determine Type and Name​

Configure Parameters and Notification Options​

Preview Rule​

Expand stored Rule​

Custom Rule​

If you are an advanced GraphQL/BGPQL user you can create a custom rule. You will need to specify the underlying GraphQL query (GQL Subscription Query), its parameters (GQL Subscription Query Parameters) in JSON format, the regex which determines if the received data are alertable or not (Alert Fire Regex) as well as a custom description and severity.

Edit an existing Alert Rule​

In each rule, name, parameters and notification options are fully editable.

Delete an existing Alert Rule​