In our first post on Interface Classification, we looked at what it is and how it works. This time we’ll follow up with more specifics on why it’s useful, illustrating with a few use cases that demonstrate the practical value of this new feature. To briefly review, Interface Classification enables an organization to quickly and efficiently assign a Connectivity Type and Network Boundary value to every interface in the network, and to store those values in the Kentik Data Engine (KDE) records of each flow that is ingested by Kentik Detect. Associating the classification information of interfaces with the flows that pass through those interfaces makes it possible for queries to segment traffic based on interface characteristics. For a closer look at how this is achieved, check out the Interface Classification article in our Knowledge Base.
The easiest place to see Interface Classification in action is the Data Explorer in the Kentik Detect portal. Interface classifications may be accessed here in two forms:
The following table shows the columns in which the Interface Classification values are stored in the records of the KDE and how they are referred to in the Data Explorer UI.
|Portal dimensions and filters||KDE field name|
|Portal dimensions and filters||KDE field name|
|SOURCE: Connectivity Type||`i_src_connect_type_name`|
|SOURCE: Network Boundary||`i_src_network_bndry_name`|
|DESTINATION: Connectivity Type||`i_dst_connect_type_name`|
|DESTINATION: Network Boundary||`i_dst_network_bndry_name`|
In the next sections we’ll look at how these new dimensions can be easily applied in some very common use cases. Without them, performing the same tasks would require devoting significantly more effort to the construction of queries.
One common task for network operators is to regularly review global connectivity, often evaluating it on a country-by-country basis. To intelligently price content destined for a given country, for example, content providers need a pretty good idea how much it actually costs them to deliver traffic to that locale. With costs of bandwidth varying from PNI (Private Network Interconnect) to Transit, it’s typically useful to look at segmentation for traffic — either inbound or outbound, depending on whether you are a content provider, carrier, or ISP — to each country of interest.
We set up for this type of analysis using the following settings in the sidebar of the Data Explorer:
After we click Apply Changes, we can see in the result shown above that a lot of the French traffic goes through transit, which is the most costly form of connectivity. We can go deeper on this first pass of investigation by figuring out which PoPs said traffic is delivered by, and, even more precisely, which devices and towards which ISP networks.
To do this our Data Explorer settings would be as follows:
The resulting diagram shows where (from which of your devices) the traffic with a given destination ASN is leaving your network, as well as the 1st hop ASN for that traffic. By combining that information with your cost information for each of those ASes, you can now develop an overview of your outbound traffic cost structure in the selected country.
A lot of peering review meetings basically consist of reviewing connectivity in a given market and trying to see what can be optimized for cost and/or performance. Either way, it’s always a good practice to try to shift as much traffic as possible from transit to any form of peering (ideally free PNI, but possibly public peering in an IX fabric). Figuring out how to do that is effectively a two-step process.
Step one is to select the destination country. How you do this depends on whether you already know what destination country you want to study or whether you want to select that country based on how much transit connectivity it requires. For the latter analysis in Data Explorer we would use the following settings:
As shown above, we now have a list of destination countries that are ranked by transit connectivity. This tells us where the greatest potential lies for saving money by shifting from transit to peering. Let’s focus on Germany (DE) for our next step.
Step 2 is to look at the Destination ASNs for the given country. This is where Data Explorer’s drill-down capabilities become particularly useful. In the table under the graph, click on the Show Options icon at the right of the DE row. In the resulting popup menu, choose Show by » Destination » AS Number.
After applying the changes we have an ordered list of the top ASNs, in Germany, that are currently reached via transit, a.k.a a list of the traffic destinations with which it would be most beneficial for us to peer. This is valuable business intelligence that it would be far more difficult to obtain without our new Interface Classification dimensions.
By now we have a good idea of the power that Interface Classification gives us in terms of extracting business value from network data. We can take this even further by marrying IC with another relatively new feature of Kentik Detect: Ultimate Exit. As a quick refresher (see this post to get fully reaquainted), Ultimate Exit augments flow records in KDE with information about the site, device, and interface of the exit point of the underlying flows from which the records are derived.
As shown in the Sankey diagram below, using this Ultimate Exit information allows you to slice traffic by the sites/devices/interfaces toward which it is headed so that you can see how much traffic is flowing between an entry site and an ultimate exit site/device/interface (the BGP ultimate exit dimension). You can also see which eyeball networks (the destination ASN) are reached by that traffic, and you can export that information for business analytics (from Options menu at top right of graph, choose Export » Table » as CSV). The business utility of this capability is to enable you to look at where transport is the most expensive between your entry site and ultimate exit site so that you can take appropriate steps to optimize.
To understand the benefit of combining Interface Classification with Ultimate Exit, let’s assume that your cost per Mb/s depends on connectivity type, and that the greater the cost the lower your ROI. As shown in the following diagram, the resulting ROI hierarchy would be: transit (ROI = $) < paid peering (ROI = $$) < IX peering (ROI = $$$) < routing between devices across your network (ROI = $$$$) < routing within a single device, a.k.a. hot-potato-routing (ROI = $$$$$).
To maximize ROI, you need network business intelligence that tells you where the traffic you carry for a given customer falls into this hierarchy. You can get that information in Data Explorer using two new dimensions: BGP Ultimate Exit Connectivity Type and BGP Ultimate Exit Network Boundary. Here’s how to set up such a query:
This query yields us a Sankey with some very valuable ROI information. Focusing on the central part of the diagram, the annotations in the image below use color to show three different types of paths taken by the traffic of the customer in this example, with each representing different levels of ROI:
The fact that Kentik Detect enables us to see different paths like the ones that we’ve colored in the diagram above illustrates that we can use it to precisely establish the different types of traffic that can be compounded into an ROI — weighted by traffic volume —for each customer. A ballpark ROI analysis can be conducted by eyeballing a Sankey generated from the settings shown above, which can be downloaded as an image to share during a traffic engineering or sales meeting. Or the underlying data can be exported from Kentik Detect (either as CSV via the portal or as JSON via our APIs) for further analysis in a financial or BI environment.