Mitigation Overview

Kentik's mitigation capabilities are covered in the following topics:

• About Mitigation
• Supported Mitigation Types
• Using Mitigation
• Configuring RTBH Mitigation
• Configuring Flowspec Mitigation
• Configuring Third-party Mitigation

Notes:
- For information on configuring mitigation platforms and methods, see Manage Mitigations.
- For information on assigning mitigations in an alert policy, see Threshold Mitigations.
- For information about active mitigations, see Mitigations.
- For information on initiating mitigation manually, see Manual Mitigation.

In addition to notifying you about conditions defined in alert policies (see About Alerting), the Kentik alerting system also take protective actions in response to those conditions. These "mitigations" are intended to prevent undesirable traffic (e.g. a DDoS attack) from disrupting network availability. Mitigations may either be triggered automatically by an alert policy or started and stopped manually (see Manual Mitigation).

Kentik supports several different types of mitigation, which are detailed in Supported Mitigation Types. Each mitigation involves a mitigation method that runs on a mitigation platform (see Using Mitigation). The configuration settings for these platforms and methods are accessed via the Manage Mitigations page (Settings » Mitigations).

Current and historical mitigations are listed on the portal's Mitigations page (Protect » Mitigations), which can be accessed not only from the portal's main navbar menu but also from the SubNav of the Alerting page.

Note: The IP range 209.50.158.0/23 must be whitelisted on third-party mitigation platforms (e.g. Radware or A10) as well as on devices that will be used for Flowspec or RTBH mitigations.

Kentik supports the mitigation types covered in the following topics:

• RTBH Mitigation
• Flowspec Mitigation
• Third-party Mitigation

Remotely Triggered Black-Hole routing (RTBH) is an extremely powerful technique that network operators can use to protect their network infrastructure and their customers against Distributed Denial of Service (DDoS) attacks. By automating the redirection of undesirable traffic at discrete points in a network, RTBH gives operators the ability to mitigate DDoS and to enforce blacklist/bogon routing policy from a centralized station.

While there are a variety of methods to implement RTBH, including RFC 5634 and source-based RTBH, most network engineers consider destination-based RTBH to be their best first-line defense against DDoS attacks. In a traditional, non-automated RTBH setup, a customer might call and say, “Help! I think I’m under attack.” An operator would then log into a route server and configure the mitigation, which is a /32 host “black hole” route. The route is then redistributed via BGP — along with a ‘no-export’ community and a next-hop address — to the routers where the attack traffic is entering the network. These routers then route the traffic to a destination that doesn’t exist (the black hole), for example a null interface.

Destination-based RTBH is not only incredibly effective at protecting network infrastructure, it’s also relatively simple to implement and to automate with Kentik alert policies that define any number of conditions that will trigger an alarm, and define as well as how the system should respond to an alarm depending on the specific situation. That response may be immediate, delayed, or manual; it may include notification and/or mitigation; and it may involve just a /32 host route or include an aggregate /24. The details of the mitigation are defined via the Manage Mitigations page.

Kentik’s Flowspec-based mitigation is effectively an implementation of IETF RFC 8955. As a mitigation tool, Flowspec has the advantage of being far more precise than RTBH in two respects:

• Greater precision in defining which traffic is affected by a mitigation action.
• Greater range of possible mitigation actions.

RFC 8955 defines two complementary aspects of what is commonly referred to as a “Flowspec,” which are defined in the details tab of the settings dialog for a Flowspec mitigation method (see Flowspec Method Details).

• Traffic matching: A BGP Network Layer Reachability Information (BGP NLRI) encoding format is used to distribute a "flow specification" to a Flowspec receiver, which can be any routing system that supports MP-BGP. The flow specification is a filter that matches traffic based on the values of certain "component types," which are properties of packets (IP, ports, etc.; see Flowspec Component Types).
• Traffic actions: An Extended Community value is used to convey actions that a Flowspec receiver can take on packets that match the flow specification (see Flowspec Traffic Actions).

Kentik offers third-party mitigation options that integrate with cloud or data-center mitigation systems offered by leading vendors such as Radware, Cloudflare, and A10. Third-party mitigation is implemented via APIs that support third-party orchestration servers like Radware DefenseFlow as well as hardware scrubbing appliances like Radware DefensePro or A10 Thunder TPS. Third-party mitigations can be automated or activated manually.

To use a third-party mitigation system with Kentik:

• Add a new mitigation platform specifying the third-party system as the mitigation type (see Add a Mitigation Platform).
• Add a mitigation method to run on the platform (see Add a Mitigation Method).

Notes:
- The procedure for adding a third-party mitigation is outlined in Third-party Mitigation Workflow.
- For an example of the third-party mitigation setup process described above, see Cloudflare MT Setup.
- Cloudflare applies Magic Transit mitigation only when traffic volume exceeds protocol-dependent minimums (100K pps for TCP or UDP; 60K pps for ICMP or GRE). Assigning Cloudflare MT to a Kentik alert policy threshold whose traffic volume is below these minimums may result in Kentik indicating mitigation as active even when Cloudflare isn't actually mitigating. For lower-volume thresholds, assign an alternative mitigation platform (RTBH, Flowspec, etc.).

The following topics cover how mitigation is structured, configured, and deployed:

• Mitigation Platforms and Methods
• Mitigation Configuration
• Mitigation Deployment

A mitigation involves two main components:

• Mitigation Platform: The platform on which a mitigation will run.
• Mitigation Method: A group of mitigation settings that will run on a mitigation platform.

Mitigations are defined on the Manage Mitigations page of Kentik’s Settings section. Configuring a mitigation involves:

• Creating a mitigation platform (see Manage Mitigation Platform).
• Creating a mitigation method (see Manage Mitigation Method).

Methods of the same type can be used in more than one platform of the same type. For example, if you have several Flowspec methods created for a Flowspec platform, you can create new mitigations by adding one or more of those Flowspec methods to a new Flowspec platform (see Edit a Mitigation Platform).

To better understand how configuration of the mitigation method differs from configuration of the mitigation platform, consider a scenario where RTBH policies are differentiated based on transit providers, interface capacities, or available peers. Being able to create multiple methods for the same platform enables you to tailor your use of the RTBH platform for each different deployment scenario.

Once a mitigation method is configured and linked to a platform, the method can be deployed in two ways:

• Automated mitigation: The mitigation is assigned to a threshold in an alert policy and triggered when conditions match those specified in the threshold (see Threshold Actions). Automated mitigations will escalate and de-escalate automatically as changing conditions match different thresholds of the underlying alert policy.
  Note: Automatic mitigations are available only in alert policies whose Dimensions setting (see Data Funneling) includes source or destination IP/CIDR.
• Manual mitigation: The mitigation is started and stopped manually (not in associated with an alarm triggered by an alert policy threshold); see Manual Mitigation.

The following topics cover the setup procedure for mitigating with RTBH:

• IP Families in RTBH Mitigation
• RTBH Mitigation Workflow

Note: The settings for RTBH platforms and methods are made on the portal's Manage Mitigations page (Settings » Mitigations).

An RTBH Mitigation in Kentik involves using BGP to instruct devices that are part of a mitigation platform to redirect traffic destined for a given “target” IP/CIDR. To mitigate traffic to a given target, both of the following must be true:

• The BGP session between Kentik and each device assigned to the mitigation platform (see Configure Platform Devices), which is set on the BGP tab of Edit Device dialog in Settings » Networking Devices (see Device BGP Settings), must be established in the same address family (Ipv4 or Ipv6) as the target IP/CIDR of the traffic that will be mitigated.
• The address family (Ipv4 or Ipv6) of the Next Hop setting of the RTBH mitigation method (see RTBH Method Details) must match that of the target IP/CIDR.

Kentik applies the above requirements as follows:

• Manual mitigation: In the Start Manual Mitigation dialog, the family of the address you enter in the IP/CIDR to Mitigate field is checked against the family of the Next Hop setting of the RTBH mitigation method you chose with the Mitigation Platform and Method drop-down (see Manual Mitigation Settings). You will only be allowed to start the mitigation if the address families match.
• Automated mitigation: When a user associates a mitigation with an alert policy threshold (see Threshold Mitigations) it can’t be known in advance what addresses will trigger the mitigation. It is therefore up to the user to do one of the following to ensure that the mitigation is properly configured (and thus won’t fail when triggered):
  - Create family-specific policies using associated filters and mitigation options.
  - Associate multiple RTBH mitigations with the threshold to cover both Ipv4 and Ipv6.
  Note: This may result in attempted announcements on the wrong BGP sessions. Ask Customer Support for assistance.

The following workflow outlines the general process of creating, configuring, and deploying an RTBH Mitigation. If this is your first time working through the process, we recommend that you contact Customer Support before starting so that we can assist you.

The process involves the following tasks:

• A. Identify and enable routers
• B. Create an RTBH mitigation platform
• C. Create an RTBH mitigation method
• D. Specify RTBH details
• E. Link existing methods to an RTBH platform
• F. Assign RTBH mitigation to an alert policy

1. In the Kentik portal, go to Settings » Networking Devices.
2. In the Device List, check the Status column (BGP V4 and/or V6; see screenshot below) for each device on which you wish to implement RTBH mitigation (if the icon[s] are present, skip to step 7). If a given device doesn’t have a check mark in that column, click the Edit icon of the device’s row to open the Edit Device dialog.
3. In the resulting Edit Device dialog, go to the BGP tab.
4. Choose Peer with Device from the BGP Type drop-down menu.
5. Click the Save button to save changes and exit the dialog.
6. Repeat steps 2 through 5 to enable direct peering with the devices that you’d like to use for RTBH mitigation (if they aren’t already BGP-enabled).
7. Make a note of the names of the RTBH-ready devices.

Once you’ve enabled devices for RTBH, you can create a platform, with which the method will combine to make a mitigation:

1. Go to the Manage Mitigations page (Settings » Mitigations).
2. Click the Add Mitigation Platform button.
3. On the Add Mitigation Platform page, select RTBH for your mitigation type.
4. Fill in the common settings for your new platform (see Mitigation Platform Settings).
5. Click Select Devices to open the Data Sources dialog, then choose the routers that you enabled for RTBH in part A of this workflow.
6. Click Create Mitigation Platform to save your new platform.

1. Go to the Manage Mitigations page (Settings » Mitigations).
2. On your new RTBH platform pane (created in step B), click the Add Mitigation Method button.
3. On the General tab of the resulting dialog (see Mitigation Method Dialogs), give your method an informative name and description.
4. From the drop-down Notification Channels menu, assign a notification channel so that you can be notified when your alert triggers a mitigation.
   Note: If you have not already configured a notification channel, go to the Notifications page to add yourself to an existing channel or create a new channel for this mitigation method.
5. Turn on the Acknowledgement Required switch, which means that after a mitigation from this method has been triggered, the corresponding alarm must be cleared manually (rather than automatically) from the Alerts List on the Alerting page. Once you have acknowledged the alert, the mitigation can then proceed.
6. Use the IP/CIDRs Excluded field to enter any IP address(es) that you’d like to exclude from being blackholed with this method. Good candidates might be infrastructure addresses, point-to-point networks, or other addresses critical to the normal functioning of your network.
7. Select the Grace Period that Kentik should honor prior to withdrawing the blackhole route. Many operators are happy with the 30-minute default because it provides enough cushion to discourage repeat attacks while not being excessively punitive to the IP that was the attack destination.

1. Switch to the dialog's Details pane and in the Community to Advertise field, enter the community that has been programmed on the customer's router to induce a black hole next hop for the IPv4 address attached to the community.
2. For each Next Hop field (IPv4 and IPv6), enter a next-hop IP address. In some environments this will be the destination IP to blackhole. This number has traditionally been selected from the 192.0.2.0/24 CIDR block but may be any IP address.
3. Use the Local Preference field (see RTBH Method Details) to set the priority for the RTBH route.
4. If you plan to withdraw blocks from certain routers and re-advertise in other locations, you may want to turn on the Ensure at least /24 checkbox. Otherwise, leave it off.
5. When you’re finished, click the Add Mitigation Method button to save the new method and exit the dialog.

If your system has existing RTBH mitigation methods, you can also add them to your platform:

1. Click Edit in your RTBH mitigation platform pane (top right).
2. Under Assign mitigation methods, click to open a drop-down list of RTBH-based mitigation methods. Select any methods you would like to add to the platform. Already linked methods appear in blue.
   Note: By linking the method to the platform, you create a mitigation that can be automatically or manually applied.
3. Click the Update Mitigation Platform button to save the platform and return to the Manage Mitigations page.

Once configured, a mitigation can be deployed for either automated mitigation (initiated when an alarm is triggered by a threshold in an alert policy) or manual mitigation (described in Start a Manual Mitigation). To deploy your new RTBH mitigation automatically, assign the mitigation to an alert threshold (see Threshold Mitigations):

1. Go to the Policies page (from the main menu, go to the Alerting page and click the Configure Alert Policies button).
2. In the Alert Policies List, find the policy to which you’d like to assign an RTBH mitigation.
3. Click the Action menu and select Configure Policy from the drop-down menu.
4. On the Edit Alert Policy page, go to the Thresholds tab. Click one of the tabs to select the threshold (Critical, Major, etc.) to which you’d like to assign mitigation.
5. Under Actions, click to display the drop-down below Mitigations to show a list of mitigations (each displayed as "platform - method"). Choose the mitigation that you created in tasks B to E above, then click the Add Mitigation button.
6. In the individual mitigation pane that appears under Mitigations, click to open the Apply Mitigation drop-down and choose when you’d like to have the mitigation take effect, which could be:
   - Immediately when Kentik raises the alarm.
   - After a user manually acknowledges the alarm,
   - After a user manually acknowledges the alarm or after a timer expires where no user has acknowledged the alarm.
7. Click the Clear Mitigation drop-down to choose when the alarm about the mitigation should be cleared from the Mitigations List.
8. Click the Save button (top right).
   Note: The creation and settings of policies to which you can assign mitigations is covered in Alert Policies.

The following workflow outlines the general process of creating, configuring, and deploying a Flowspec Mitigation (a linked combination of platform and method).

Note: The settings for Flowspec platforms and methods are made on the portal's Manage Mitigations page (Settings » Mitigations).

The workflow involves the following tasks:

• A. Configure devices for Flowspec
• B. Enable Flowspec in device settings
• C. Create a Flowspec mitigation platform
• D. Create a Flowspec mitigation method
• E. Specify Flowspec conditions and actions
• F. Link existing methods to a platform
• G. Assign an automated Flowspec mitigation to an alert policy
• H. Deploy a manual Flowspec mitigation

Note: As with any mitigation, once the mitigation is applied to actual traffic (manually or automatically) it's important to monitor it via the Mitigations page.

You should be able to enable Flowspec in the configuration of any routing system that supports RFC 8955. The specifics of how to achieve this vary depending on the brand, operating system, model, and version of the device. To find configuration information for your device:

1. Navigate to Kentik's config-snippets repository on GitHub.
2. In the list of router brands, find and click on the directory corresponding to the manufacturer of your device. If the manufacturer makes multiple models that are configured differently, continue clicking until you reach the directory corresponding to the device that you want to configure.
3. Inside that directory, look for the file named flowspec.conf.
4. Open the file and configure your device as shown in the code snippet.

The following example is a config snippet for Flowspec on Juniper MX routers:

# this configuration on JunOS assumes you already have a BGP session configured
Protocols {
  bgp {
    group route-consumers_v4 {
      # Kentik-provided peering IP.
      neighbor {{kentik_UI_bgp_peering_ipv4}} {
        family inet {
          flow;
        }
      }
    }
  }
}
# Use the RFC 8955 defined ordering of the terms instead of the earlier draft version.
routing-options {
  flow {
    term-order standard;
  }
}

Each device that you configure to enable Flowspec (see part A above) must also be enabled for Flowspec in the device settings in the Kentik portal:

1. In the Device List on the Devices page (Settings » Network Devices), click the Edit icon of the device’s row to open the Edit Device dialog.
2. On the BGP tab, choose Peer with device from the BGP Type drop-down menu.
3. Set the BGP Flowspec Compatible switch to on.
4. Click the Save button to save changes and exit the dialog.

Once you've enabled devices for Flowspec (both on the device and in the BGP settings for the device in the Kentik portal) you can create the platform which, when combined with a method, make a mitigation:

1. Go to the Manage Mitigations page (Settings » Mitigations).
2. Click the Add Mitigation Platform button.
3. On the Add Mitigation Platform page, select Flowspec for your mitigation type.
4. Fill in the common settings for your new platform (see Mitigation Platform Settings).
5. Click Select Devices to open the Data Sources dialog, then choose the routers that you enabled for Flowspec in parts A and B of this workflow.
6. Click Create Mitigation Platform to save your new platform.

1. Go to the Manage Mitigations page (Settings » Mitigations).
2. In your new Flowspec platform pane (created in step C), click the Add Mitigation Method button.
3. On the General tab of the resulting dialog (see Mitigation Method Dialogs), give your method an informative name and description.
4. From the drop-down Notification Channels menu, assign a notification channel so that you can be notified when your alert triggers a mitigation.
   Note: If you have not already configured a notification channel, go to the Notifications page to add yourself to an existing channel or create a new channel for this mitigation method. See Notifications.
5. Turn on the Acknowledgement Required switch, which means that after a mitigation from this method has been triggered, the corresponding alarm must be cleared manually (rather than automatically) from the Alerts List on the Alerting page. Once you have acknowledged the alert, the mitigation can then proceed.
6. Use the IP/CIDRs Excluded field to enter any IP address(es) that you’d like to exclude from the actions taken by this method (see Flowspec Traffic Actions). Good candidates might be infrastructure addresses, point-to-point networks, or other address critical to the normal functioning of your network.
7. Now select the Grace Period that Kentik should honor prior to withdrawing the Flowspec action. Many operators are happy with the 30-minute default because it provides enough cushion to discourage repeat attacks while not being excessively punitive to the IP that was the attack destination.

1. On the Details tab of the Add Mitigation Method dialog, in the Traffic Matching pane, set the conditions that will be used to match traffic.
   Note: The components that are used for conditions are described in Flowspec Component Types, and the controls for setting conditions are explained in Flowspec Condition Controls. To avoid unintended consequences, familiarize yourself with the notes in those topics.
2. In the Traffic Filtering Actions pane, specify the actions that Flowspec receivers are to take on traffic that matches the traffic matching conditions (see Flowspec Traffic Actions).
   Note: To save the method you must select one of the five actions available on the Traffic Filtering Actions drop-down. Setting only the Sample and/or Terminal switch is not sufficient to define a Flowspec method.
3. Click the Add Mitigation Method button to save the new method and exit the dialog. The new method will appear in the Flowspec mitigation platform pane.

If your system has existing Flowspec mitigation methods, you can also add them to your platform:

1. Click Edit in the mitigation platform pane (top right).
2. Under Assign mitigation methods, click to open a drop-down list of Flowspec-based mitigation methods. Select any methods you would like to add to the platform. Already linked methods appear in blue.
   Note: By linking the method to the platform, you create a mitigation that can be automatically or manually applied.
3. Click the Update Mitigation Platform button to save the platform and return to the Manage Mitigations page.

Once configured, a mitigation can be deployed for either automated mitigation (initiated when an alarm is triggered by a threshold in an alert policy) or manual mitigation. To deploy your new Flowspec mitigation automatically, assign the mitigation to an alert threshold (see Threshold Mitigations):

1. Go to the Policies page (choose Alerting from the navbar menu, then click the Configure Alert Policies button).
2. In the Alert Policies List, find the policy to which you’d like to assign a Flowspec mitigation.
3. Click to display the Action menu and select Configure Policy from the drop-down menu.
4. On the Edit Alert Policy page, go to the Thresholds tab. Click one of the tabs to select the threshold (Critical, Major, etc.) to which you’d like to assign mitigation.
5. Under Actions, click to display the drop-down below Mitigations to show a list of mitigations (each displayed as "platform - method"). Choose the mitigation that you created in tasks C to F above, then click the Add Mitigation button.
   Note: The Mitigations section is only visible if the policy’s dimension list (Dimensions setting in Data Funneling) includes source or destination IP/CIDR.
6. In the individual mitigation pane that appears under Mitigations, click to open the Apply Mitigation drop-down and choose when you’d like to have the mitigation take effect, which could be:
   - Immediately when Kentik raises the alarm.
   - After a user manually acknowledges the alarm,
   - After a user manually acknowledges the alarm or after a timer expires where no user has acknowledged the alarm.
7. Click the Clear Mitigation drop-down to choose when the alarm about the mitigation should be cleared from the Mitigations List.
8. Click the Save button (right top).
   Note: The creation and settings of policies to which you can assign mitigations is covered in Alert Policies.

Notes:
- Flowspec-based mitigations should only be assigned to a threshold in an alert policy whose key definition includes the dimension IP/CIDR (see Dimensions in Data Funneling).
- If the Infer From Alarm switch is on for any conditions in a Flowspec-based method (see Flowspec Condition Controls) then a mitigation using that method should only be assigned to a threshold in an alert policy whose key definition includes the corresponding dimensions.
Example: If a given method has Infer from Alarm on for Destination IP/CIDR, Protocols, and Source Ports, then a mitigation using that method will be available to assign to a threshold only in policies whose key definition includes the dimensions Destination IP/CIDR, Protocol, and Source Port Number.

Flowspec mitigations can be deployed manually as described in Start a Manual Mitigation. Before applying a Flowspec-based manual mitigation, familiarize yourself with the special considerations discussed in Manual Mitigation with Flowspec.

The topics below outline the setup procedures for a Third-party Mitigation supported by an integration with Kentik:

• Third-party Mitigation Workflow
• Cloudflare MT Setup

Note: The platform and method settings for third-party mitigations are made on the portal's Manage Mitigations page (Settings » Mitigations).

The following steps provide a generic guide to configuring a third-party mitigation:

1. On the portal's Manage Mitigations page (Settings » Mitigations), click the Add Mitigation Platform button.
2. On the Add Mitigation Platform page, under Select Your Mitigation Type (see Common Platform Settings) choose the type of third-party mitigation you'd like to use (Radware, Cloudflare Magic Transit, or A10 TPS).
   Note: Cloudflare applies Magic Transit mitigation only when traffic volume exceeds protocol-dependent minimums (100K pps for TCP or UDP; 60K pps for ICMP or GRE). Assigning Cloudflare MT to a Kentik alert policy threshold whose traffic volume is below these minimums may result in Kentik indicating mitigation as active even when Cloudflare isn't actually mitigating. For lower-volume thresholds, assign an alternative mitigation platform (RTBH, Flowspec, etc.).
3. Under Assign Mitigation Methods, click the Add New Method button, which opens the Add Mitigation Method dialog.
4. On the General tab of the dialog, make the settings described in General Method Settings.
   Note: The settings dialog for a Cloudflare Magic Transit method includes only general settings and use no tabs.
5. If the mitigation type is A10 or Radware, the dialog will include a Details tab. Configure the settings on this tab, which vary depending on the mitigation type.
   Note: Customers are advised to make these settings in consultation with a support representative of the third-party vendor.
6. Click Add Mitigation Method to save your method.
7. Back on the Add Mitigation Platform page, under Configure API, fill in the API settings particular to the third-party mitigation type of your platform (see Configure Platform APIs).
8. Under Finish Up, fill in the Name and Description fields.
9. Click Create Mitigation Platform to save your new platform.

The following procedure is specific to Cloudflare Magic Transit (MT) but illustrates the more general mitigation setup process outlined in Third-party Mitigation Workflow:

1. On the Manage Mitigations page (Settings » Mitigations) in the Kentik portal, click the Add Mitigation Platform button.
2. On the Add Mitigation Platform page, select Cloudflare Magic Transit as the Mitigation platform.
   Note: Cloudflare applies Magic Transit mitigation only when traffic volume exceeds protocol-dependent minimums (100K pps for TCP or UDP; 60K pps for ICMP or GRE). Assigning Cloudflare MT to a Kentik alert policy threshold whose traffic volume is below these minimums may result in Kentik indicating mitigation as active even when Cloudflare isn't actually mitigating. For lower-volume thresholds, assign an alternative mitigation platform (RTBH, Flowspec, etc.).
3. Click the Add New Method button, which opens the Add Mitigation Method (Cloudflare Magic Transit) dialog.
4. Fill in the fields described in General Method Settings.
5. Click Add Mitigation Method to save your method.
6. Back on the Add Mitigation Platform page, fill in the required fields, including API Login, Cloudflare Account ID, and API Token (see Configure Platform APIs).
7. Fill in a name and description of the new platform (see Common Platform Settings).
8. If the mitigation method you created in steps 3 to 5 isn't listed yet under Assign mitigation methods, click Add Existing Method and choose the method from the drop-down list. It may take a few moments to display.
9. When the settings are complete, click the Create Mitigation Platform button to save your new platform and close the dialog.

Once you've created a Cloudflare MT mitigation for your organization it may be deployed manually or automatically (e.g. in response to conditions defined in a Custom Insight threshold); see Mitigation Deployment.

Notes:
- The procedure above covers only setup in the Kentik portal. You must also set up the mitigation in the Cloudflare account referenced in step 7. For further information please refer to Cloudflare’s documentation and support for Cloudflare Magic Transit.
- Cloudflare applies Magic Transit mitigation only when traffic volume exceeds protocol-dependent minimums (100K pps for TCP or UDP; 60K pps for ICMP or GRE). Assigning Cloudflare MT to a Kentik alert policy threshold whose traffic volume is below these minimums may result in Kentik indicating mitigation as active even when Cloudflare isn’t actually mitigating. For lower-volume thresholds, assign an alternative mitigation platform (RTBH, Flowspec, etc.).