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.

Last month, we introduced a new analytics view called Raw Flow, which enables you to directly examine the flow data stored in Kentik Data Engine (KDE), the back end datastore used by Kentik Detect. We’ve further improved this functionality by adding a filter box and also the option to export the results in CSV format.

Back in October we launched kprobe, our improved host agent software that can be deployed anywhere (in your data center or in the cloud) to gather all kinds of useful data from real traffic on your hosts. We’ve been steadily enhancing kprobe ever since; this month we have a new release that includes a couple new CLI parameters:

• –status-port gives you the ability to check the status of the agent by defining the port to listen on.
• –status-host enables access beyond the localhost IP address (127.0.0.1).

Once the new parameters are configured, you can point your browser to http://host:port/v1/status to get a JSON output of the status.

{  
 “flows-in”: {  
   “count”: 953,  
   “1m.rate”: 4.297123404852097,  
   “5m.rate”: 2.286167148965094  
 },  
 “flows-out”: {  
   “count”: 953,  
   “1m.rate”: 4.297123404852097,  
   “5m.rate”: 2.286167148965094  
 }  
}

For more information on installing and configuring kprobe, check the Knowledge Base (KB) article on Host Configuration.

Keyboard shortcuts, enabling greater efficiency for commonly performed tasks, have now come to the Kentik Detect portal. How do you find the shortcut for a given task? Press [SHIFT]+[?] on your keyboard to pop up the shortcuts help menu. As shown in the screenshot at right, the popup is context-sensitive and will display both global shortcuts and those that are specific to an individual page (in this case Data Explorer).

The largest and most obvious change we made this month was the rollout of Kentik Detect v3.1, which introduces our new Library section of the portal. If you’ve logged in recently you probably noticed the announcement in a popup that appears at login. The Library gives you a single page from which to create, view, modify, and manage views of your network traffic data. It’s a big step forward in our effort to streamline your workflow when using the portal, and it will enable us to rapidly develop a rich array of preset views for specific use cases.

While the Library replaces the portal’s separate Dashboard and Saved Views pages, all of your existing dashboards and saved views have been preserved and are now available in a central location. Access the Library via the main navbar, then use the sidebar to choose views that have been created within your organization or provided by Kentik. 

You’ll be able to move quickly between different views, and to easily edit views, modify properties, and clone existing views to make variations. Learn more about the details in the following Knowledge Base articles:

• Portal Library
• Using the Library

Users can now make the Library their default landing page via the Default Settings pane of the User Profile (accessed via the drop-down menu at the far right of the main portal navbar).

Focus on Ease-of-Use

The Library is the latest example of our focus on portal ease-of-use, which we’ve mentioned in previous updates. The idea is to empower the consumers of information via dashboards and saved views (created by both power users and consumers). The Library also enables us to release Kentik-provided preset views that address specific use cases. The Library’s consumer-focussed UI supports this goal with the following design features:

• Persistent access: The Library tab is always available for direct access to dashboards and saved views. The list includes views that you’ve designated as favorites and also those that you’ve recently viewed.
• 
  Ubiquitous search: A search popup (shown at right) that launches from the main navbar means that you can quickly find views wherever you are in the portal. 
• Content organization: Views in the Library can be assigned to categories and are grouped into buckets (personal, company-shared, and Kentik presets). 
• Content discovery: The Library landing page gives us the ability to promote new and featured views, organized by task-specific categories or consumer teams.

The new Library is only one aspect of our recent usability efforts. Some additional steps include:

• Adding dimensions that enable characterization of network traffic, e.g. Interface Classifiers and Network Classifiers.
• Upping the portal’s visualization game with new view types (Gauge, Geo HeatMap) and making data more visually useful with Bracketing (application of colors based on value range).
• Bringing interactivity to dashboards via guided-mode dashboards and dashboard navigation (drill down to deeper views).

More usability enhancements are slated for release in coming months, so keep an eye on this space…

This March 2018, quite a bit of work also went into improving a few different areas of Kentik Detect’s filtering capabilities:

Bi-Directional Interface Classification Filters

Interface Classification results in the following filter criteria being available:

• Interface ID
• Interface Name
• Interface Description

These criteria can now be applied as Source or Destination meaning if either direction matches, the filter will apply.

Invert Perspective

Remove Active Saved Filters

For more detailed information on how to use filters in Kentik Detect, check out our KB article.

Sankey Diagrams have historically required a minimum of two dimensions to be selected in the Group-By selector in the Query pane since this visualizations shows a “from” and “to” relationship. We have now relaxed this requirement for Destination BGP AS_PATH given the fact that this dimension has both a “from” and “to” relationship within it.