DDoS Defense

Purpose: Streamline the protection of your network from DDoS attacks with easily customizable Kentik-provided preset alert policies for the most common attack profiles.
Benefits: - Eliminate false positives/negatives and decrease response time with automatic machine learning-based traffic profiling.
- Visualize attack characteristics and network impact.
- Trigger automatic mitigation actions including RTBH, Flowspec, and external mitigation hardware or services.
Use Cases: DDoS detection, mitigation, and administration
Relevant Roles: Network Engineers/Architects, Network Security Engineers, NOC Engineers, Carrier Product Managers

DDoS Defense is covered in the following topics:

Automate DDoS detection, investigation, and mitigation.
 

About DDoS Defense

DDoS attacks utilize a wide variety of attack vectors across multiple types including volumetric, invalid protocols, UDP, TCP, ICMP, amplification and reflection, and DNS. It takes intricate knowledge of all these possibilities to devise effective detection and alerting for each. With the DDoS Defense workflow (Protect » DDoS Defense) Kentik has created a set of more than 20 readymade alert policies that cover this entire spectrum and require only minimal tailoring to protect you from the most common attacks.

The workflow is composed of two main parts:

  • DDoS Defense Configuration: A wizard in which you determine:
    - The scope of your DDoS protection (by excluding Interfaces and IP addresses that you don't want monitored).
    - The specific attack profiles against which you want to activate alert policies.
    - The deviations from normal traffic patterns — as established by retrospective baselining of your actual traffic — that you want to be alerted about.
    - The actions, such as notification and mitigation, that you want Kentik to automatically take in response to traffic anomalies.
  • DDoS Defense Page: A view where you can quickly see information about ongoing and historical attacks and mitigations.

The part you'll be taken to when you choose DDoS Defense from the menu in the portal's main navbar depends on the current state of DDoS Defense configuration:

  • If configuration isn't yet completed you'll be taken to the landing page for DDoS Defense configuration (see DDoS Defense Initial State).
  • If configuration has been completed (see Finishing Configuration) you'll be taken to the DDoS Defense page. You can get to the configuration wizard using the Configure button at upper right.

Note: To protect against attack profiles that are not covered by the Kentik preset alert policies in DDoS Defense you can create a Custom insight in Core » Insights & Alerting (see Insights & Alerting).

 

DDoS Defense Configuration

DDoS Defense configuration is structured as a wizard with five steps that are covered in the following topics:

 
top  |  section

DDoS Defense Initial State

If the DDoS Defense workflow hasn't yet been set up for your organization then when you arrive at the workflow (Protect » DDoS Defense) you'll see the initial landing page, which contains some information about DDoS Defense and the Get Started button. Click the button to begin configuration.

 
top  |  section

Check Prerequisites

Effective detection of DDoS attacks requires us to fully understand the structure of your network in order to differentiate normal traffic patterns from anomalous behavior. We gain this understanding through the prerequisites listed below. By checking that these prerequisites are completed we are able to ensure the accuracy of our detection, minimizing false positives and negatives.

Our prerequisite check looks at the following factors:

  • Interface Classification (recommended): Interface Classification enables us to determine which of your interfaces are external (see Network Boundary Attribute) and thus subject to DDoS attack. If Interface Classification hasn't yet been completed in your organization, we recommend that you click the link to go to the Interface Classification settings page, then return to the DDoS Defense wizard to complete the configuration. You'll have the opportunity to exclude specific interfaces later in the process.
    Note: You'll receive on-screen notification in the following situations:
    - Less than 70% of your interfaces are classified.
    - No interfaces are classified as external, in which case you'll have to check into the classification of your edge interfaces (for help, see Customer Support) before continuing with configuration of DDoS Defense.
  • Traffic History (required): To understand what external traffic is "normal" for your network, we need to have ingested flow records for at least 120 hours from at least one of your edge devices (a device with at least one interface whose network boundary is classified as external).
    Note: You'll receive on-screen notification if we don't yet have sufficient traffic data to build the history, in which case you will have to wait to be able to continue with configuration of DDoS Defense.
  • BGP Configuration (optional): BGP is not required to configure attack detection, but you will need to configure BGP on all edge routers if you'd like to use either of Kentik's built-in mitigation methods (see RTBH Mitigation Methods or Flowspec Mitigation Methods).
    Note: You'll receive on-screen notification in the following situations:
    - Your Kentik Licenses don't include BGP.
    - BGP is not enabled on your devices (see Device BGP Settings).

When the prerequisites have been checked, click the Continue button at the bottom of the page.

 
top  |  section

Exclude Interfaces

By default, the interfaces that are monitored for DDoS are the interfaces that were found by Interface Classification to have a network boundary value of external. In this step, however, you can individually exclude interfaces that you do not want to monitor for attack traffic. To start, click the Exclude Interfaces button and use the resulting dialog to choose interfaces to exclude (see Exclude Interfaces UI). The dialog provides two ways for you to define a list of interfaces to exclude: dynamic groups and individual static interfaces.

When you click Save to close the dialog, the interfaces that will be excluded from DDoS attack monitoring will be the combination of all dynamic groups and excluded interfaces currently defined in the dialog. Any previous Excluded Interfaces settings will be overridden.

When the Excluded Interfaces dialog closes you're returned to the Exclude Interfaces step of the DDoS Defense Configuration wizard. If you created any dynamic groups or selected any individual interfaces in the dialog you'll now see them in the lists on this page. To remove one or more items from the list, click the Exclude Interfaces button and revise the settings in the dialog. When the list is as you want it, click the Continue button at the bottom of the page.

The Exclude Interfaces dialog.

Exclude Interfaces UI

The Excluded Interfaces dialog includes the following main UI elements:

  • Filters: Filters used to narrow the set of interfaces from which you either create a dynamic group or choose individual interfaces to exclude (see Filters Pane).
  • Group By: A set of buttons that determine how the interfaces in the Matching Interfaces list will be organized into groups, either by Device, Connectivity Type, or Network Boundary (see Interface Classification Dimensions).
  • Create Dynamic Group: A button, active only when one or more filters are set in the filters pane, that creates a dynamic group made up of all interfaces that match the current filter criteria.
    Note: The composition of a dynamic group will change in response to changes in the interfaces that match the group's filter conditions. For example, if a group is defined as interfaces on a given device whose network boundary is external, then additional external interfaces added on that device will become members of that group.
  • Matching Interfaces: A list (just below the Create Dynamic Group button) of the individual interfaces available to add to the Excluded Interfaces list at the right of the dialog. By default the Matching Interfaces List will include the interfaces on all of your Kentik-registered devices. To make it easier to see the interfaces that you want to select, or to define dynamic groups of interfaces, you can use the Filters pane at the left of the dialog.
  • Dynamic Groups: A list of the dynamic groups that are part of this set of excluded interfaces (see Excluded Interfaces Lists).
  • Excluded Interfaces: A list of the individual interfaces that you've added to this set of excluded interfaces (see Excluded Interfaces Lists).
  • Cancel: Exit the dialog, leaving the set of excluded interfaces as it was when the dialog was opened.
  • Save: Exit the dialog, updating the set of excluded interfaces to the current dynamic groups and excluded interfaces.

Filters Pane

The Filters pane of the Exclude Interfaces dialog includes the following filter controls (fields and checkboxes):

  • Name: Match interfaces whose name contains the entered string.
  • Description: Match interfaces whose description contains the entered text (case insensitive).
  • IP: Match interfaces with the entered IP/CIDR address range.
  • Device: Match interfaces whose device name contains the entered string.
  • Capacity: Match interfaces whose capacity matches the entered value.
  • Logical Interfaces Only: Show only interfaces that have been assigned an IP address.
  • Provider: Match interfaces whose source/destination traffic reaches the Internet via the entered provider.
  • Connectivity Type: Match interfaces whose Connectivity Type is checked (see Understanding Connectivity Types).
  • Network Boundary: Match interfaces whose Network Boundary is checked (see Network Boundary Attribute).

You can use the above filter controls to narrow the set of available interfaces. The Matching Interfaces List will update to show only interfaces that match the current filters, and the Create Dynamic Group button will become active.

Matching Interfaces List

The Matching Interfaces list in the Excluded Interfaces dialog is populated based on the current filters in Filters Pane and grouped according to the Group By buttons. Interfaces in the list can be manually designated for inclusion in the Excluded Interfaces list by clicking on the + icon at the right of each row.

The list includes the following columns and controls:

  • Interface: In each row, the top line is the interface’s SNMP alias and the bottom line is the interface’s description (see Information SNMP OIDs).
  • Information: Indicators showing the interface’s capacity, connectivity type, and network boundary (see Interface Classification Dimensions).
  • Add (+): An icon at the right of an individual row in the Matching Interfaces list. Click to add the corresponding interface to the Excluded Interfaces list.

Excluded Interfaces Lists

The Excluded Interfaces lists show the two categories of interfaces that will be excluded from attack traffic monitoring when the Excluded Interfaces dialog is closed with the Save button:

  • Dynamic Groups: Each listed item represents the set of criteria that was specified in the Filters Pane when the Create Dynamic Group button was clicked (one dynamic group per click of the button). The group is dynamic because all interfaces on your network that currently meet the criteria for a listed dynamic group will be excluded even if those interfaces didn't exist or didn't meet the criteria when the dynamic group was created.
  • Excluded Interfaces: Each listed item represents, by SNMP alias, an interface that was excluded using the + icons in the Matching Interfaces List.

An item in either of the above lists may be manually removed using the red X at the right of each row.

 
top  |  section

Exclude IP Addresses

This step enables you to identify any IP addresses that should be globally excluded from the historical traffic that Kentik will evaluate in order to build the baselines that tell us what traffic patterns should be considered normal for your network.

Note: To exclude a given IP from baselining for some but not all alert policies, exclude it in your individual attack profiles (next step) rather than in this step.

To exclude an IP, click the plus button (+) at the bottom left of the Addresses list (which will initially be empty). An input field will appear. Enter an IPv4 or IPv6 address or CIDR range into the field. Repeat as needed for all IPs that you'd like to exclude. To remove an address, click the X at the right of that address's field. When you're done, click the Continue button at the bottom of the page.

 
top  |  section

Enable Attack Profiles

In this step you activate one or more Kentik preset alert policies that are each designed to respond to a specific attack profile. These policies have been designed by Kentik to cover a wide range of the most common attacks. With a few adjustments to a given policy's threshold settings (see Policy Settings) you will be able to tailor that policy to the specifics of your network's traffic.

The policies are listed in a table, each row of which includes the following UI elements:

  • Enabled: If a checkmark is present, the alert policy associated with this attack profile is enabled.
  • Name: The name of the policy.
  • Description: A description of the policy, which includes an explanation of the attack profile for which the policy is designed.

To open the Policy Settings for a given attack profile, click on the profile's row in the table. A drawer containing the settings will slide out from the right of the page.

Note: While you can modify any of the available Kentik preset policies, you can't currently create a new policy from this page. You can, however, create a new Custom insight (in Core » Insights and Alerting; see Insights & Alerting) that will alert you to DDoS attacks.

The Enable Attack Profiles page lists the DDoS-related alert policies available in your organization.
 
top  |  section

Policy Settings

When you click on a profile's row in the Enable Attack Profiles table, a drawer containing settings for that profile will slide out from the right of the page, which allows you to tailor policy parameters to the individual circumstances of your organization.

  • Enabled: A switch that determines whether or not the policy is enabled.
  • Exclude IPs (not present on every policy): A button that opens the Exclude IPs dialog. To exclude traffic on a given IP from evaluation by this policy, find the IP in the list and click the icon in the Exclude column at the right of the IP’s row. When you’re finished excluding IPs, click the Apply button to close the dialog.
  • Description: Text describing the type of attack that this policy is designed to detect.
  • Query Settings: A set of panes that define the evaluation this policy will employ to detect attacks (see Policy Query Settings).

Policy Query Settings

Every alert policy queries network traffic to find traffic that matches the conditions defined in the policy. The controls available to tailor these queries include the following:

Thresholds Chart

The Thresholds chart is a line chart on which the following is plotted over a baselining period that's typically the last seven days (minimum 5 days):

  • Historical traffic volume: A gray line is plotted for the volume of each IP/CIDR as measured in the policy's primary metric (e.g. packets/s or bits/s).
  • Thresholds: A colored line is plotted for each of the policy's currently active thresholds, showing how the threshold, as currently defined, would have compared to the actual traffic over the baselining period. You can click and drag a threshold line to change the static metric component (if any) of that threshold's primary condition (see Threshold Conditions).
  • Refresh: Updates the Threshold line chart.
  • View in Explorer: Opens Data Explorer in a new tab, with the Query sidebar set to match the parameters of the Thresholds graph. The table will show a breakdown of the traffic by Destination IP/CIDR.

Note: Hovering over the chart at a given point in the timeline will open a popup giving traffic volume (in the primary metric) at that time for each of the plotted IP/CIDRs and thresholds.

Threshold Controls

A threshold is a collection of settings that define a set of conditions that must be matched in order to activate an alert, at which point an alarm is generated for each key for which conditions have been matched. Each alert policy includes at least one threshold by default, but may include up to five, one for each Severity level: Critical, Severe, Major, Warning, and Minor.

The following settings, which are available for each threshold, determine when an alarm will be triggered:

  • Enabled: A switch that toggles activation of the threshold. A threshold must be on to trigger an alarm.
  • Conditions: The traffic conditions that constitute a match for this threshold (see Threshold Conditions). Click the Edit Conditions button to open the dialog.
  • Activate When Conditions Met: The frequency (number of matches in a specified period) with which a match must occur for an alarm to be triggered, which involves three settings:
    - Number: How many times a match must occur.
    - Duration value: The number of time units.
    - Duration units: The time unit, either minutes or hours.
    Note: If number is 1, the time settings are irrelevant; an alarm will be generated immediately upon the first match.
  • Notifications: A drop-down menu from which you can choose one or more notification channels that have been defined in your organization (see Alert Notifications). Each channel represents a notification mode (e.g. email) and one or more notification targets (e.g. a set of email addresses).
  • Mitigations: A drop-down menu from which you can choose one or more mitigations to respond to an alarm from this threshold. Each mitigation defined in your organization is a linked combination of mitigation platform and mitigation method; see Mitigation Overview.
    Note: A mitigation that is set here will be triggered automatically when the threshold enters alarm state. Use caution when making this setting (for assistance see Customer Support).

Threshold Conditions

The Edit Threshold Conditions dialog is used to set the specific traffic conditions that the threshold looks for when evaluating traffic. The dialog is structured as a set of up to three different condition cards, one for each of the following metrics:

  • Packets/second
  • Bits/second
  • Unique Source IPs

The attack profile determines whether all three of the above metrics are relevant for a given policy, and thus whether a card for a given metric will be included in the dialog for that policy's thresholds. Whichever cards are included, one metric will be primary and the others secondary, with the distinction being as follows:

  • Primary condition (upper left of the dialog): This card enables you to set either or both of the following conditions:
    - Static condition: Compares current traffic with a fixed number, either specified by the user or auto-calculated. Example: packets/s > 21 kpps.
    - Baseline condition: Compares current traffic with a historical baseline that we derive from evaluating the last 120 hours or more of traffic already ingested into KDE. Example: > 130 % of baseline.
    Note: In the Kentik preset alert policies found on the Enable Attack Profiles page (step 5 of the DDoS Defense configuration wizard) the primary condition card is already set but should be modified to fit your specific network traffic norms (for assistance see Customer Support).
  • Secondary condition: These cards each let you set one additional static condition.

Note: All specified conditions must be met for the threshold to trigger an alarm.

If both a static condition and a baseline condition are specified for the primary metric then they work together to determine the actual threshold that must be matched at a given point in time. The static condition is a minimum value that must be met, but the baseline condition can increase that value at times when higher traffic is the norm.

To better understand how the baseline condition is used, let's suppose that you're an eyeball ISP with embedded caches from a major CDN that are filled every day at 2 AM, resulting in your typical 2 AM traffic volume being 500 Mbps higher than the average bitrate over the baseline period. Baselining identifies this pattern, so setting a baseline condition of 100% would keep your thresholds from triggering an alarm in response to a typical cache refresh, but would still notify you of spikes greater than the norm. In practice, to account for variations in the cache refresh you'd choose a baseline condition of greater that 100%, so an alarm would trigger only when the spike is, for example, 25% above the expected 2 AM bump (baseline condition setting of 125%).

Condition Card UI

Each card in the Edit Threshold Conditions dialog includes the following UI elements:

  • Condition value: Click the number in the condition field to set/edit the condition's value:
    - In the card for the primary metric you can set the value of a static condition, a baseline condition, or both (see Threshold Conditions).
    - In each card for a secondary metric you can set a single static condition.
  • Remove condition (trash icon at right of condition field): Click the icon to remove the condition from the card.
  • Add condition (present only when a condition can be added): Click the blue plus sign (+) or the accompanying label ("Static Condition" or "Baseline Condition") to add a condition to the card.
  • Condition chart: A visualization of the condition plotted against baseline traffic. You can change the value of a static condition by clicking and dragging on the colored threshold line in the chart.
  • Refresh: Click to refresh the chart.
  • View in Explorer: Opens Data Explorer in a new tab, with the Query sidebar set to match the parameters of this condition. The table will show a breakdown of the traffic by Destination IP/CIDR.

Finishing Configuration

On the Enable Attack Profiles page, when you're done activating and editing alert policies for attack profiles you're ready to complete DDoS configuration. At this point you have two choices:

  • Finish: Saves all of your current DDoS Defense configuration settings and immediately activates the policies you've specified.
  • Save For Later: Saves all of your current DDoS Defense configuration settings without actually activating the policies. You can return to the wizard later to click Finish and activate your policies.

Note: When you click either of the above options all changes will be saved to all activated policies. If you experimented with changing a threshold's fixed condition by dragging a colored line in a policy's chart (see Thresholds Chart), be sure to double-check (before saving) that you left the setting at the desired value.

 

DDoS Defense Page

The DDoS Defense page gives you a high-level view of DDoS attack activity that has generated alarms from the alert policies configured on the Enable Attack Profiles page. The DDoS Defense page is covered in the following topics:

 
top  |  section

DDoS Defense Page UI

The DDoS Defense page includes the following main controls and information:

  • Configure: A button that opens a menu from which you can choose to go to a specific page in the DDoS Defense Configuration wizard:
    - Interface Exclusions: See Exclude Interfaces.
    - Global IP Exclusions: See Exclude IP Addresses.
    - Configure Attack Profiles: See Enable Attack Profiles.
  • Indicator pane: A set of cards with summary information (see Indicator Pane).
  • Attack Activity: A chart showing attack activity in the last 24 hours (see Attack Activity Chart).
  • Last 24 Hour Traffic: A set of cards that each contain a chart showing traffic in the last 24 hours as measured in a different metric (see Traffic Charts).
  • Attacks Within Last 24 Hours: A table listing attacks within the last 24 hours and providing details on those attacks (see Attack Table).
 
top  |  section

Indicator Pane

The indicators in this pane show current information for the following:

  • Active Attacks: The number of attacks that are happening right now, meaning that the conditions specified in a policy threshold are matched for at least one key, triggering an alarm (see Threshold Conditions).
  • Active Mitigations: The number of mitigations currently underway, meaning that there is an alert assigned to a policy threshold that triggered on ongoing alarm (see Threshold Controls). Click the link to go to the Mitigations Page.
  • Attacks within last 24 hours: The number of attacks that occurred in the last 24 hours.
  • Live Update: A button that determines whether the page is auto-refreshed at one minute intervals:
    - If green, Live Update is off; click to start.
    - If red, Live Update is on; click to stop.
  • Last updated: Indicates the date-time of the most recent refresh of the page.
Indicators show key information related to recent DDoS attacks.
 
top  |  section

Attack Activity Chart

This chart shows attack activity over a timeline that covers the last 24 hours. The blue bar indicates a new alarm (triggered by an alert policy entering ALARM state) while the red line represents the count of active alarms at each point in the timeline. Hovering over the chart at any point in the timeline triggers a popup that gives a count of new and active alarms at that date-time.

The timeline shows the number and times of attacks in the last 24 hours.
 
top  |  section

Traffic Charts

The Last 24 Hour Traffic charts show a breakdown of traffic for each of the metrics that are evaluated by DDoS Defense alert policies (see Threshold Conditions):

  • Bits/s
  • Packets/s
  • Unique Src IPs
These charts show traffic over the last 24 hours expressed in the metrics used to evaluate attacks.
 
top  |  section

Attack Table

The attack table provides information about alarms from the DDoS Defense alert policies that are activated on the Enable Attack Profiles page in the configuration wizard. Each row of the table gives summary information about the alarm (see Attack Table Columns). Click on the row to expand it for more details (see Attack Details).

This table appears in two forms:

  • Attacks Within Last 24 Hours: Located on the DDoS Defense page, this table is limited to alarms from the last 24 hours.
  • Attack Log: Located on the Attack Log page, this table includes not only alarms from the last day but also those that are more than 24 hours old. To reach the table from the DDoS Defense page, click the View Full Attack Log button.

Both tables include the same columns, which are described in Attack Table Columns.

The table lists the alarms generated by alert policies over the last 24 hours.

Attack Table Columns

Attacks within the last 24 hours are listed in a table, one row for each policy that entered alarm state. The following columns provide information about each alarm:

  • State: The state of the alarm:
    - Alarm: Ongoing, not being mitigated.
    - Mitigating: Currently being mitigated.
    - Cleared: Resolved.
  • Severity: The severity (Critical, Major, etc.) assigned to the alert policy threshold that triggered the alarm (see Threshold Controls).
  • Attack Profile: The alert policy (e.g. Total Traffic Volumetric Attack) that generated the alarm (see Enable Attack Profiles).
  • Dimensions: The IP/CIDR(s) toward which the attack was directed.
  • Metric: All of the static conditions set in the Edit Threshold Conditions dialog for the threshold that triggered the alarm. The baseline condition, if any, for a given alarm isn't shown here, but it's shown when the alarm's row is expanded (see Attack Details).
  • Alarm ID: The ID of the alarm. Click to go to the Insight Details Page corresponding to the alarm.
  • Time:
    - Start: The date-time at which the threshold generated the alarm.
    - End: If the alarm is ongoing, then "Currently active." Otherwise the date-time at which the alert policy exited ALARM state (i.e. the conditions that cause the alarm are no longer present).

Attack Details

The following details are provided in a drawer that slides out from the left of the page when you click on the row for a given alarm:

  • Description: A description of the attack profile.
  • Traffic Summary: The same "last 24 hours" metrics charts that are described in Traffic Charts above, but with highlights showing the time period during which the alarm was active.
  • Attack Trigger: The conditions that caused the alert to enter alarm state:
    - Dimensions: The traffic dimensions that were evaluated by the alert policy that generated this alarm, e.g. "Dest IP/CIDR, Protocol."
    - Primary Metric: The primary metric in which traffic was evaluated for this alarm (see Threshold Conditions), e.g. "packets/s."
    - Secondary Metrics: The secondary metrics (if any) in which traffic was evaluated for this alarm, e.g.
    bits/s, Unique Src IPs."
    - Conditions: The static and baseline conditions that had to be matched for this alarm, e.g. "packets > 22M packets/s."
    - Activates: The frequency with which conditions had to be matched to generate this alarm (see Threshold Controls), e.g. "5 times within 10 minutes."
    - Clears: The conditions that cause the alarm to enter Clear state. This value is predetermined by Kentik as "20 minutes of inactivity."
  • Attack Stats:
    - Severity: The severity level of the threshold that triggered the alarm (Critical, Severe, Major, Warning, or Minor).
    - Start: Date-time at which the alarm was triggered.
    - End: If the alarm is ongoing, then "Active." Otherwise the date-time at which the alert policy exited Alarm state (i.e. the conditions that cause the alarm are no longer present).
    Target: The IP/CIDR toward which the attack was directed and the protocol used (e.g. TCP).
    - Bits/s: The bitrate of the attack traffic.
    - Packets/s: The packet rate of the attack traffic.
    - Unique Src IPs: The number of unique source IPs that were involved in the attack.
 

Mitigations Page

The Mitigations page, accessed via the Active Mitigations link in the Indicator Pane, is covered in the following topics:

The Mitigations page lists in-progress mitigations.
 
top  |  section

Mitigations UI

The Mitigations page provides information about mitigations currently underway in your organization. The page includes the following UI elements:

 
top  |  section

Mitigations List

The Mitigations List on the Mitigations page is a table providing information about mitigations triggered by your organization's alert policies. Each row in the table represents an individual mitigation. The table includes the following columns:

  • State: Two icons representing mitigation states (see Mitigation Row States):
    - The current state of the mitigation.
    - The state that the mitigation will be in next.
  • Triggered By: The alert policy that triggered the mitigation.
  • Mitigation: The following information about the mitigation:
    - ID: The Kentik-generated unique ID for the mitigation.
    - Alarm: The Kentik-generated unique ID for the alarm that triggered the mitigation.
    - Method: The mitigation method associated with this mitigation (see Mitigation Methods).
    - Platform: The mitigation platform associated with this mitigation (see Mitigation Platforms).
  • Target / Dimensions: The specific instances of the dimension that the mitigation method used to identify which traffic to mitigate.
  • Date (UTC): The date-time at which the mitigation began.
  • Actions: Available mitigation actions vary depending on the current state of the mitigation and whether the mitigation is automatic (see Automatic Mitigation Actions) or manual (see Manual Mitigation Actions).

Notes:
- The list is filtered by the Mitigations List Filters.
- To see further details about an individual alarm, click the alarm's row to open a Mitigation Details Pane that slides out from the right of the page.

 
top  |  section

Mitigations List Filters

The mitigations displayed in the Mitigations List can be filtered using the controls in the filtering pane on the right. The pane includes the following filters:

  • Show Historical:
    - If on, the list will include past mitigations that have been archived.
    - If off (default), the list will show only currently active mitigations.
  • Time Range (only if Show Historical is on): A set of radio buttons that determines how old the mitigations in the list can be.
  • Clear all (appears only when you've specified one or more filters): Click to clear all current filters.
  • Mitigation ID: Include only mitigations whose ID equals or contains the entered numbers.
  • Alarm ID: Include only mitigations for which the ID of the triggering alarm equals or contains the entered numbers.
  • Policy: Include only mitigations for which the name of the triggering alert policy equals or contains the entered string.
  • Target: Include only mitigations for which the entered text matches specific instances of the dimension that the mitigation method used to identify which traffic to mitigate.
  • Dimension: Include only mitigations for which the entered text matches the dimension that the mitigation method used to identify which traffic to mitigate.
  • Exact: A switch that determines whether the string entered in the Dimension field is matched strictly or loosely.
 
top  |  section

Mitigation Details Pane

The details pane for a given mitigation slides out from the right of the page when the row for that alarm is clicked in the Mitigations List, showing the following additional information:

  • Mitigation ID: The Kentik-generated unique ID for the mitigation.
  • Policy: The alert policy that triggered the mitigation.
  • Alarm: The Kentik-generated unique ID for the alarm that triggered the mitigation.
  • View Insight: A link that takes you to the Insight Details Page for the alert policy (a.k.a. custom insight) that triggered this mitigation.
  • Method: The mitigation method associated with this mitigation (see Mitigation Methods).
  • Platform: The mitigation platform associated with this mitigation (see Mitigation Platforms).
  • Target / Dimensions: The specific instances of the dimension that the mitigation method used to identify which traffic to mitigate.
  • Event list: A table listing, in chronological order, events involving the mitigation:
    - State: The mitigation state at the time of the event.
    - Event: The event.
    - Date (UTC): The date-time of the event.
© 2014- Kentik

In this article: