Much of our development effort in July 2017 was directed toward under-the-hood improvements that will make it faster for us to innovate in response to customer needs and feedback (more on this in coming months). At the same time, we haven’t lost our focus on practical ways to make daily operations easier. With that in mind, we’ve added a cool new feature called Interface Classification (IC). By allowing you to more quickly and easily understand the types of interfaces your traffic uses to enter and leave the network, IC gives you the ability to optimize your network for cost and performance.

Network boundary attributes

Interface Classification relies on a couple of different types of attributes derived from network data, one category of which is “network boundary.” By classifying the interfaces as internal or external, we can compare the source and destination of the traffic to see if both are fully within your network or crossed a network boundary (came from or went to a different AS). This distinction allows Kentik Detect to avoid counting a given flow multiple times as it passes through the network. And it gives technical decision makers the ability to see how much traffic is coming in and out of their network versus how much of it is contained within the network.

Connectivity type attributes

Another category of IC attribute is connectivity type, in which interfaces are labeled by their connectivity type, such as transit, ix, paid peering, etc. Identifying the type of connectivity used by traffic through a given interface gives you a way to determine costs and optimize pricing for each category of traffic.

Defining interface classifications

Now that we understand classification attributes, how is IC enabled in Kentik Detect? The goal is to use the attributes as dimensions and filters in queries and visualizations. To do so, the attributes must be added to flow records as they are ingested into the Kentik Data Engine (KDE). The magic starts on the Interface Classification page of the portal (Admin » Interface Classification), where you create rules that classify interfaces by evaluating patterns in the interface description or IP address.

To create a new rule, click on the green Add Rule button. The “If” section tells the rules engine what to look for. In the “Then” section, you can define the Connectivity Type and optionally the Network Boundary. By default, the Network Boundary is automatically determined by the Connectivity Type (more on this in the next section).

Once you’ve created and saved a rule, the Evaluate Rule button (upper right) initiates evaluation of your Kentik-registered interfaces against all of your currently active rules. The number and percentage of interfaces that are matched is shown in the sidebar. If you update your IP addresses or interface descriptions, you can click on the Evaluate Rules button to re-run the classification rules. This makes it exceptionally efficient to classify all of your interfaces.

Setting up network boundaries

In the operation described above the classification of network boundary (internal or external to the network) was automatic, and it relied on Kentik Detect’s preset definition of the network boundary associated with each connectivity type. However, using the Configure Network Boundaries modal (button at top of IC page), you can set your own correlation between a connectivity type (backbone, customer, host, etc.) and network boundary.

The description above just skims the surface of Interface Classification. Look to the Kentik blog in coming months for deeper insights into how IC works and what you can do with it.