December 2017 comes with a heavy delivery of new features, this month we're adding:

• the Network Classification concept and dimensions (tldr: what's in your network, what's not)
• additional Interface Classification connectivity types
• Heatmap visualizations
• New Host Metrics
• A brand new Alerting Scoreboard
• IPv6 compatibility for Radware mitigations

---

Network Classification

We are constantly looking for ways to make Kentik Detect easier to use, especially for users that aren’t highly network savvy. One such improvement is Network Classification, which enables the following capabilities for our users:

• Network Directionality: Group traffic based on the direction from which it enters the network and to which it leaves.
• Host Directionality: Group host traffic captured by kprobe based on the direction it is flowing.

Network Classification Dimensions

The capabilities listed above are supported by four new dimensions that can be applied to each flow:

• Traffic Origination: This dimension indicates whether the source for a given flow is inside or outside of your network.
• Traffic Termination: This dimension indicates whether the destination for a given flow record is inside or outside of the network.
• Host Direction: When the flow record has been generated on a host, this dimension indicates whether the direction of traffic is into or out of that host.
• Traffic Profile: Derived from Traffic Origination and Traffic Termination, this dimension categorizes traffic into one of the following directionalities, which are illustrated in the graphic below:
  – Through: Traffic coming from outside the network and terminating outside the network.
  – Ingress: Traffic coming from outside the network and terminating inside the network.
  – Internal: Traffic originating and terminating inside the network.
  – Egress: Traffic coming from inside the network and terminating outside the network.

The dimensions described above are available throughout Kentik Detect as:

• Group-by Dimensions
• Filter match criteria
• Alert keys (dimensions of an Alert Policy)
• Alert filter match criteria

Network Directionality Use Case

One interesting use case involves using Network Directionality to investigate spikes in traffic. For example, in the left graph below from the Kentik portal’s Data Explorer, we can see a big spike in flows to a customer called Pear, Inc.

In the corresponding Data Explorer table (below the graph; not shown), we can dig deeper into the data by clicking the Action menu at the right of the row for Pear, Inc. We choose Show By to open the Show By Dimensions dialog, then choose one of our new Network Classification dimensions, Traffic Origination (listed under Source). After closing the dialog by clicking the Show By Selected Dimensions button, we re-run the query. We can now see (right graph) that the spike is made up of traffic that originated outside of our network. If we wanted to continue digging further, we would use Show By again, this time looking at source ASN or IP address.

Note that these same dimensions can also be used in Alerting to monitor traffic that comes from outside the network separately from traffic that is internal to the network. For more information on creating alerts, check out the Policy Alerts Overview in our Knowledge Base.

Host Directionality Use Case

Another use case for Network Classification is specific to host traffic captured by kprobe (Kentik’s software host agent). Since most hosts have only a single interface through which traffic can pass, kprobe captures both inbound and outbound traffic. Until now, it was difficult for a Kentik Detect user to separate which traffic was coming in and which traffic was leaving. But now it’s possible to distinguish one from the other. As shown in the graph, with Host Direction used as the group-by dimension you can now see separately the flows in (black) and out (blue) of a host.

Configuring Network Classification

To benefit from the new Network Classification feature you must first enable Kentik Detect to determine what is inside and what is outside of your network. The configuration is pretty simple, assuming that you are an Admin user. Start by navigating to Admin » Network Classification, then fill in the following two fields:

• Internal IPs: Enter a list of the IP CIDR blocks used inside the network. By default, the RFC1918 IP Space is included with the user defined list; this can be changed with the checkbox below the field.
• Internal ASNs: Enter a list of ASNs used inside the network. By default, the Private ASN range is included with the user defined list; this can be changed with the checkbox below the field.

Once the fields are filled and you’ve clicked the Save button, you’re ready to begin using Network Classification.

New Types for Interface Classification

Interface Classification — which debuted in our July Product Update — shows the types of interfaces through which your traffic enters and leaves your network so that you can optimize your network for cost and performance. As part of our ongoing enhancement of that feature, we just expanded the list of Connectivity Types, which are used to classify interfaces by their role in the overall network. The new types are:

• Datacenter Interconnect
• Aggregation Interconnect

If your network includes these types of interconnects, after you run Interface Classification you can now specify these interface types when you query, build dashboards, monitor with alerts, and more. For more information on using this feature, head to our Knowledge Base for the article on Interface Classification.

HeatMaps for Countries and Sites

One feature that’s been among the most common requests from customers is the ability to visualize network data on a map. We just added mapping capabilities in the form of a new Geo Heat Map view type (accessed via a drop down view type menu like you’ll find at the upper right of the display area in Data Explorer). This new type enables a couple of map visualizations that we think you’ll find quite useful:

• Country Heatmap
• Site Heatmap

Country Heatmap

A country heatmap shows the source or destination of traffic by country on a global map. This feature uses the GeoIP data that we add, based on Source and Destination IP address, to each flow record in the Kentik Data Engine. The visualization shows one direction (source or destination) at a time of traffic using Country geo-information. A color key indicates the volume of traffic for each country.

To generate a country heatmap in Data Explorer, first set the group-by dimension to either source or destination country. Then change the visualization type in the drop down in the upper right hand corner to Geo HeatMap. The resulting graph should look similar to the map below.

Site Heatmap

A site heatmap shows the total traffic, inbound plus outbound, by each site in your network. The larger the circle on the map, the more traffic at that site. For greater detail, hover over a circle to open a pop-up giving the site’s coordinates and the total amount of traffic.

Before you can use this feature you have to provide a street address for each of your sites, which you can do with the Edit Site dialog in Admin » Sites (you must be an Admin user; see Editing a Site in our Knowledge Base article) or with our Site API.

Once the site addresses have been specified, you can build a query in the Data Explorer using the group-by dimension Site (FULL) and the view type Geo HeatMap. The resulting visualization should look something like the map below.

Expanded Host Metrics

The savvy Kentik user is already aware of our software host agent, kprobe, which runs on a server and provides host performance metrics. For those not familiar with this functionality, check out our blog post on one intriguing application for this, which is using kprobe to monitor DNS infrastructure.

This month we’ve expanded kprobe functionality by adding the following metrics:

• Repeated Retransmits: The number of TCP packets that have been retransmitted more than once, likely due to packet loss along the path from sender to receiver.
• Zero-Window: The number of times the TCP receive window has been set to zero, indicating that the receiver cannot keep up with the flow of data from the sender.
• Receive Window Size: The size of the TCP receive window reported by the receiving host.
• Connection ID: The TCP or UDP Connection ID for the session that the reported flow belongs to.

To start leveraging the expanded metrics, install the latest version of kprobe (see kprobe download and install in our Knowledge Base).

Scoreboard for Alerting

Anomaly detection, alerting, and mitigation are core features of Kentik Detect, and we continue to devote a lot of effort toward improving workflow and usability. Recent changes to the Alerting section make this powerful functionality easier to set up and use. The first place you go when you click Alerting in the Kentik Detect navbar is the Active Alerts page, which we’ve just enhanced with an Alerting scoreboard. So it’s now easier to see at a glance the things that most need your attention.

The top part of the scoreboard is a set of summary tiles (shown above), one for each of three types of events:

• Mitigations: Shows a count of how many alerts are currently being mitigated, either automatically or manually. A button (+ sign) for manual mitigation is also included. The background color of the tile varies depending on the count:
  – Grey: No mitigations currently in progress.
  – Purple: 1 or more mitigations currently in progress.
• Alarms: Shows a count of alerts that are in ALARM state, meaning that the conditions defined in the alert policy have been met and notifications have been triggered. A count of the alarms at each severity is also included. The background color of the tile varies depending on the severity (minor, major, critical) of the most severe alarm:
  – Grey: No alarms currently active
  – Dark Red: The highest severity level is Critical.
  – Red: The highest severity level is Major.
  – Orange:  The highest severity level is Minor.
• Acknowledgements: Shows a count of alerts that are in ACK_REQ state, meaning that the conditions that resulted in an alarm are no longer present, but an acknowledgement is required from a user in your organization before the alert is removed from the active list. The background color of the tile varies depending on the count:
  – Grey: No acknowledgements pending.
  – Blue: 1 or more acknowledgements pending.

Below the summary tiles is a matrix whose rows represent either mitigations or alert policies that are in alarm. The columns represent the top values of a dimension chosen when the matrix was configured (click the gear button to edit the configuration). The matrix lets you quickly see what’s going on with the policies that are most in need of attention.

Key an eye on our Knowledge Base for coming topics related to the Alerting Scoreboard.

IPv6 Support for Radware Mitigation

Kentik Detect includes the ability to integrate with mitigation systems from third parties including Radware. Until recently, you could only define a Radware Mitigation Platform using an IPv4 address. We now have the ability to make an API call to a Radware appliance using either an IPv4 or an IPv6 address.