By popular demand, you can now download as a CSV file is a log of all Alerts within a chosen time range and with specific attributes. 

To enable this oft-requested feature we’ve now added an Export to CSV button on the History page (Alerting » History). The download process is the same as for the Unclassified Interfaces report described above.

Once downloaded and opened in a spreadsheet, the CSV file will appear as shown in the screenshot below:

Interface Classification is a quick and easy process that reveals the role of each interface through which your traffic enters and leaves the network. The higher the percent of interfaces you’re able to classify, the better you’ll be able to optimize your network for cost and performance.

We now make available a downloadable CSV file that lists all of the interfaces that can’t currently be classified, so that you can take steps to facilitate a better interface classification percentage (e.g. revise SNMP-retrieved description strings).

To export the CSV file, click on the Unclassified Interfaces button below the ring diagram in the Classified Devices pane (right sidebar) of the Interface Classification page (Admin » Interface Classification).

In the resulting Unclassified Interfaces dialog you’ll see the list of unclassified interfaces as well as a new Export CSV button at the upper right. When you click the button you’ll see alerts indicating the progress of the export, after which you’ll be able to access the Recent Reports dialog, from which you can download the Unclassified Interfaces report.

We’ve reworked the BGP status indicators in the Device List (in Admin » Devices) to better explain the shown status. Previously, if you had v4 BGP enabled, it would show v6 BGP as “not established” even if you had not set it up. Now a tooltip (displayed on mouseover) will now tell you about non-established and not-configured BGP states. As shown below, you’ll see a separate indicator of states for v4 and v6 BGP.

Session is not configured

Sankey flow diagrams have long been an important feature of Kentik Detect, used to represent the flow of network data from hop to hop. We’ve recently refined the calculations underlying our Sankeys related to performance metrics, such as percent retransmits or latencies, to give a more accurate picture of these metrics. Our Sankeys also now support bracketing, which enables the coloring of nodes — and the links between them — based on your bracket specifications, which is very useful for performance diagrams.

Subtenancy provides a mechanism by which a Kentik customer (e.g. an ISP) can enable each of its own external or internal customers to see a curated set of visualizations and metrics of their own traffic. This has been a recurring ask from existing and prospective Kentik users, and we’re excited to announce the availability of this feature.

Subtenancy needs to be activated by Kentik (contact Customer Success for details), after which you’ll see a new page (Admin » Subtenancy) that we’ve created for you to manage subtenancy in the Kentik Detect portal.

As shown above, you begin configuration by defining the properties of your subtenant portal (subdomain, logo, etc.; see Subtenancy Page in our Knowledge Base), which can be thought of as a customer-branded version of the portal Library (see below).

Next, you’ll use the Add Subtenant dialog (shown below) to create subtenants that can access the subtenant portal. If you’re an ISP, each subtenant might correspond to one of your business accounts. Alternatively, a large Enterprise might create subtenants that each corresponds to an internal team that would benefit from access to specific reports generated by Kentik. For each subtenant, you can determine the reports (e.g. Dashboards and Saved Views) that will be available, the traffic that’s covered in those reports, and the subtenant users (identified by email address) that will have access.

The subtenant portal feature will help Kentik customers boost revenue by selling subtenancy as a value-added service. And subtenancy will also increase the “stickiness” of ISP service offerings, which can provide a significant edge in a competitive provider market.

Selecting devices is one of the foundational functions required to return meaningful results in Kentik Detect, not only from ad-hoc queries in Data Explorer but also elsewhere, including the Library’s Saved Views and Dashboards. Our device selector has allowed you to choose groups of devices by type (router or host) or by site (physical location; see About Sites). But until now you haven’t been able to flexibly define your own device groups or to change the devices covered by Dashboards and Saved Views (e.g. add a newly deployed router) without editing the device assignments for each specific view.

Introducing Device Labels

With the recent introduction of Device Labels, those limitations are now gone. A device label is simply a non-exclusive property, any number of values for which can be assigned to (or removed from) any device at any time. Labels allow you to define groups of devices based on any criteria you choose: capacity, the customers they serve, the device manufacturer, etc.

When a query is defined using a device label then the devices whose flow data will be included in the query are determined at run time based on which devices have that label. This means that if you refer to devices via labels when building components such as dashboards, saved views, reports, and saved filters then you can change the devices that a given component covers without going back and revising the component itself. This makes the assignment of devices to queries much less tedious, and it makes the views that use those queries (Dashboards, Saved Views) much easier to maintain as your network evolves.

Using Device Labels

Device Labels are implemented in the portal with a new page (Admin » Device Labels) where you assign labels to devices as shown below.

Depending on where you are in the portal you’ll also see a new Device Selector that’s been redesigned to take advantage of device labels. As shown below, you can still select individual devices from the sidebar, or you can select by label, so that all devices that have the label at query run-time will be covered by the query.

As shown below, device labels are also now available for filtering in the Ad_Hoc filter Groups dialog in both Data Explorer and Alerting:

It’s important to note one area where you won’t find device labels, which is in the Group-By Dimensions selector. Because multiple overlapping labels can be assigned to a given device, it’s not workable for us to break down traffic by labels. Even so, we’re sure that you’ll find device labels to be a very flexible and efficient enhancement to Kentik Detect.

Quite a few of our customers use Kentik Detect to answer questions about how much traffic is being sent to and from the networks they are directly connected to (transit providers, private peers, public peers, Internet Exchanges, customers, etc.). To make this task a lot easier we have removed the need to use a Custom Dimension (more details on Custom Dimensions can be found in our KB article), and we’ve introduced a new feature called Provider Classification as part of our existing Interface Classification feature discussed above. This feature matches a string in the interface description and sets the provider name using one of two methods:

• Static: This method uses a static, plain-text provider name for interfaces that match. To use this configuration on an existing rule, click on the rule within Interface Classification and fill in the Provider text field in the Then pane. In the pictured example, we are matching on “IX” in our interfaces description and setting the provider for any of these interfaces to “cyrusone” (NOTE: provider names are converted to all lowercase to avoid duplications).

  

• Regular Expression (RegEx): For more complex matching and classification, we support RegEx Capture Group Notation. This method allows for matching using RegEx and extracting the provider name using the RegEx Capture Group Notation. In the pictured example, our group is extracting the word that comes after “TO-” and using that ($1 refers to the first group extracted) as our provider name.

  

If you need a refresher on RegEx Capture Group Notation check out this helpful guide. If you need help testing your RegEx syntax, check out this useful application.

Once you are happy with your RegEx configuration, click on the Test Rule button to see what is matching. You should get a list of Device Matches list the one pictured.

The rows with blue in the bar and a non-zero number in the blue background have interfaces that were matched by the tested rule. Click on one of those rows (e.g. pe1_ord1) and you can see what interfaces matched and what provider was pulled out of the interface description.

To exit this screen and return to your rule, click the X in the upper right-hand corner.

Once you are confident you have matched what you expected, click the Save button to return to the main Interface Classification Screen. Your updated rule will be displayed with the RegEx matching and Provider group:

For more information on Provider Classification, be sure to check out our KB  article.

Those readers who’ve used our alerting system know that it’s based on alert policies that are each made up of one or more thresholds that enter alarm state when triggered by user-defined conditions. Alarms generate notifications (email, Slack, PagerDuty, etc.) but they can also automatically initiate mitigation. With our latest iteration, you can now assign more than one mitigation per threshold.

What’s the advantage of multiple mitigations per threshold? Below are a few simple examples of why this feature is so useful:

• You can now use a single policy to configure all of the desired mitigation methods/platforms with which you’d like to respond to a given set of conditions, which is much more scalable than cloning a given policy for each of your appliances so that they can all trigger at the same time for a given condition.
• Users with mitigation appliances at multiple sites now have the ability to trigger them all at the same time.
• The response for a given alarm can now include a mix of mitigation types, e.g. RTBH, A10, and Radware. A multi-location DDoS response involving multiple mitigations types is outlined in the following example:
  1. De-preference or stop announcing a BGP route on Location #1 by injecting a route whose community has been predefined as a flag for these actions.
  2. Announce a broader routing table entry, less-specific than /24 (thus forcing acceptance by Internet peers), for Location #2.
  3. Trigger a 3rd-party mitigation method — e.g. A10 or Radware — on Location #2 to announce more specific prefixes for internal re-direction to a scrubbing center.

For more information about using mitigation, check out our KB article on Alert Mitigation.