Using Interface Classification

Analyze Your Connections for Competitive Advantage

The practical usage of interface classification, illustrated with specific use cases, is covered in the following topics:

• Interface Classification Dimensions
• Checking Country-level Connectivity
• Optimizing Connectivity by Country
• Adding Ultimate Exit

Notes:
- For a general description of interface classification, see Classification Overview.
- For a reference to the administration of interface classification in the Kentik portal, see Interface Classification.

Interface classification enables an organization to quickly and efficiently assign a Connectivity Type and Network Boundary value to every interface in the network. As flow records are ingested into the Kentik Data Engine (KDE) they are augmented with the connectivity and boundary values for the interfaces that the flows have used. Incorporating these values into the flow records makes it possible for them to be represented as dimensions in queries, which enables you to create queries that segment traffic based on interface characteristics.

The easiest place to see interface classification in action is the Data Explorer in the Kentik portal. Interface classifications may be accessed here in two forms:

• Group-by dimensions (see Dimension Selectors): Set the combination of fields that define a set of traffic that can be counted (by metric) and ranked.
• Filters (see Filtering Settings) Include or exclude traffic records that contain a specified value in the field that you’re filtering on.

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.

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:

• Group-by dimensions: [Destination] Connectivity Type
• Filters (ANDed):
  - Destination Network Boundary = external
  - Destination Country = FR (France for this example)
• Devices: Select all routers. We don’t need to be more specific because the Network Boundary filter will ensure that we only query on traffic as it exits the network.
• Display Type: Pie Chart (gives us a quick visual overview).

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:

• Dimensions/Group By: [Full] Site, [Destination] Connectivity Type, [Full] Device, [Destination] Next-Hop ASN, [Destination] ASN.
• Display and Sort By (Advanced Options): 95th percentile (smooths out potential spikes).
• Filters (ANDed):
  - Destination Network Boundary = external
  - Destination Country = FR (France for this example)
• Devices selected: Select all routers.
• Display Type: Sankey diagram

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:

• Dimension/Group By: [Destination] Country
• Filters (ANDed):
  - Destination Network Boundary = External
  - Destination Connectivity Type = Transit
• Devices: Select all routers.
• Display Type: Time series stacked graph

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 Options icon (hamburger) at the right of the DE row. In the resulting popup menu, choose Show by, which opens the Show-by Dimensions dialog. Select Destination » AS Number, then click the Show By Selected Dimensions button.

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 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 feature of Kentik: Ultimate Exit. As a quick refresher (for more, see Using Ultimate Exit), 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 (specified with Ultimate Exit Dimensions). 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 diagram below, the resulting ROI hierarchy would be as follows (low to high):

• 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:

• Dimension/Group By:
  - [Source] AS Number: this isn’t crucial, but it helps us make sure that we’re catching ports for the right customer ASN.
  - [Full] Site: the sites where we connect to our customer, named Customer AS1234
  - [Destination] BGP Ultimate Exit Site: the site where the customer’s traffic will be handed over, which will give us an idea of how much transport is involved for us to deliver it.
  - [Destination] BGP Ultimate Exit Connectivity Type: the type of connectivity over which this customer’s traffic will be handed over. Can help calculate the cost of transport between Customer’s traffic entry and exit sites.
  - [Destination] AS Number (optional).
• Filters: [Source] Interface Description = “Customer AS1234” (assuming that we’ve included the customer name in the description of the interface serving that customer, this filters the results to just those coming from that customer).
• Devices: All edge routers.
• Display Type: Sankey Diagram.

This query yields us a Sankey with some very valuable ROI information related to the traffic coming from Customer AS1234. 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:

• Traffic on the pink path is the most profitable. This traffic is routed within the same site (Washington to Washington), so it has neither a metro nor long-haul cost. And since it’s delivered to another customer (Ultimate Exit Connectivity Type is “Customer”), it can be billed to that other customer.
• Traffic on the orange path is second in terms of ROI. It’s hot-potato-routed, so it has no transport costs, and it’s handed over via free PNI (Ultimate Exit Connectivity Type is “Free PNI”), so there’s no cost to deliver it. But it does not actually generate revenue like traffic on the pink path.
• Lastly, traffic on the blue path has the lowest ROI. It enters in San Francisco and is delivered in Sao Paulo, Brazil, which involves costly transport between two countries. This cost is probably not offset by the fact that it is delivered to a Free PNI.

The fact that Kentik 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 for further analysis in a financial or BI environment, either as CSV via the portal (see Export Chart or Table) or as JSON via our Query API (see Query Data Method).