Classification Overview

This article provides an overview of Kentik’s interface classification process, which automatically classifies the types of interfaces through which traffic enters and leaves your network.

Notes:

• To manage classification via the Kentik portal's Interface Classification page, see Interface Classification.

• For interface classification use cases, see Using Interface Classification.

About Interface Classification

Interface classification assigns values to two attributes (network boundary and connectivity type) for each interface. Kentik collects flow records from traffic using each interface and incorporates the attribute values into these records. Once classified (see Classification Rules), you can use these values as source or destination dimensions and/or filters in queries in Data Explorer, Dashboards, or Alerting, and via the Kentik V5 Query API.

Key points about Interface Classification in Kentik:

• Rules are defined on the Interface Classification Page of the Kentik portal (Settings » Interface Classification):

  • Rules evaluate either the description or IP address of an interface and apply a connectivity type value or network boundary value (see Connectivity Type Attribute and Network Boundary Attribute).

  • Rules apply a network boundary value (see Network Boundary Attribute), that is either specified manually (per rule) or applied automatically based on connectivity type.

• Rules are evaluated from the Interface Classification page (see Applying Classification Rules), resulting in:

  • Efficient automated classification of some interfaces.

  • Identification of devices with remaining interfaces for manual modification.

• Once a given interface is classified, KDE augments the flow records for that interface with the classification values:

  • For network boundaries, the values are stored in src_interface_network_boundary and dst_interface_network_boundary.

  • For connectivity types, the values are stored in src_interface_connectivity_type and dst_interface_connectivity_type.

• Kentik queries use these classifications for group-by dimensions and filters.

Network Boundary Attribute

This attribute classifies interfaces as Internal or External. It helps Kentik avoid counting flows multiple times as they pass through the network and allows technical decision makers to see network traffic in and out of their network.

This diagram illustrates the over-counting issue that network boundary classification addresses:

AS100, an imaginary Kentik customer, receives and sends traffic to multiple ASNs via five network devices. Two flows generate three flow records each: at ingress, internal to the network, and at egress. To count flows at ingress, we’d need to exclude the records not from the orange segments at the left. Similarly, to count flows at egress, we’d need to exclude records not from the blue segments at the right.

Here’s an example visualization you can generate in Data Explorer once network boundary classification is implemented on an interface.

By default, a network boundary value is assigned to an interface based its connectivity type during interface classification. However, this default can be overridden in individual interface classification rules (see Rule THEN Settings). To change the defaults, see IC Default Network Boundaries.

Connectivity Type Attribute

The connectivity type attribute classifies interfaces based on their role in the network, such as transit, ix, or paid peering. Identifying the type of connectivity used by traffic through an interface helps determine the network from which traffic enters and exits, optimizing costs and pricing. For the supported connectivity types, see Understanding Connectivity Types.

Kentik evaluates SNMP polling data about interfaces to determine the connectivity type (see SNMP OID Polling):

• Interface description: Kentik retrieves interface descriptions from network devices with SNMP polling enabled. If a description has been manually overridden, interface classification uses the Kentik description instead (see Edit an Interface).

• Interface IP address: Kentik polls the IP address of an interface to infer its connectivity type based on network addressing policies. Examples of policies include:

  • A range of IP addresses can be used exclusively for transit customers.

  • A range of RFC1918 IP addresses can be used exclusively for interfaces on CDN servers behind a load balancer.

  • A range corresponding to the LAN of a particular Internet Exchange.

This screenshot shows an example of a visualization you can generate in Data Explorer after implementing connectivity type classification on an interface.

Understanding Connectivity Types

Kentik’s supported connectivity types are described here.

Aggregation Interconnect

This type is applied to bundles of interfaces between devices on separate traffic aggregation levels. It’s commonly found in hierarchical data center switching or routing topologies (e.g., Clos/leaf-and-spine). If no specific distinction is needed, these interfaces can classified as backbone.

Available

This type is not currently used and is not reserved for future use. Their names or descriptions may indicate availability to facilitate network planning.

Notes:

• Depending on company policy, “available” Interfaces might be provisioned with a transceiver.

• The network boundary of an available interface indicates if it’s for internal or external use.

Backbone

“Backbone” is the generic connectivity type for an interface (or bundle of interfaces) between two devices within the same network, regardless of their location within the data center. Users with separate backbone and data center teams usually use “datacenter interconnect” and “aggregation interconnect” categories within the data center, and “backbone” outside.

Cloud Interconnect

This type is used to connect a physical device to a Public Cloud. The term varies by cloud provider:

• AWS: Direct Connect (https://aws.amazon.com/directconnect/)

• Azure: ExpressRoute (https://docs.microsoft.com/en-us/azure/expressroute/expressroute-introduction)

• GCP: Cloud Interconnect (https://cloud.google.com/network-connectivity/docs/interconnect/concepts/overview)

• OCI: FastConnect (https://www.oracle.com/cloud/networking/fastconnect/)

Note: If the interface accesses the cloud provider through a partner, the connection should instead be classified as a Virtual Cross Connect.

Customer

This type of interface (or bundle of interfaces) typically points toward a downstream customer. The BGP session established through this interface usually announces a full route view (“Full view transit”) or a partial route view (“Partial Transit”) to that downstream customer. A customer interface is the financial inverse of a transit (Full view) or paid private peering (Partial view) interface.

Data Center Fabric

This type of interface connects devices within a data center to other devices within the same data center (e.g., devices assigned Clos fabric roles like Super Spine, Spine, Leaf, or Top of Rack).

Datacenter Interconnect

This type of interface (or bundle of interfaces) connects devices within a single data center. While some may call interfaces “backbone”, this classification is intended for cases where a data center team and a backbone team coexist, with one being a customer of the other.

Embedded Cache

This type is for an interface connected to a Cache Appliance Server provided by a CDN or content provider (e.g., Facebook Appliance, Google Global Cache, Netflix Open Connect, Akamai Caches). These appliances are embedded in the ISP's last mile network to deliver popular traffic directly, bypassing the CDN or content provider’s network. Content on these appliances is refreshed via proxy feed during off-peak hours.

Free Private Peering

This connectivity type is used for an interface (or bundle of interfaces) connected to a non-transit AS using direct private connections to the AS's facing router. BGP peering typically involves routes from the directly connected AS (including a few downstream ASes). This form of peering is settlement-free (if either party charges the other, then it becomes paid private peering).

Host/Access

This connectivity type indicates a direct connection between a router and a server host.

IX Peering

This type of interface (or bundle of interfaces) connects to a public peering facility, a switching LAN where multiple ASes offer to peer. Unlike free or paid peering interfaces, IX peering allows multiple BGP sessions to multiple ASes through the same interface, resulting in multiple Next-Hop ASNs.

Other

This is a “catch-all” type for interfaces where no other connectivity type applies. Alternatively, exclude interfaces from Interface Classification if they lack an IP address or description.

Paid Private Peering

This type of interface is connected are similar to free private peering but involve payment between parties. The classifications supports cost-related business analytics.

Reserved

This type of interface is available but allocated for future use.

Notes:

• Depending on company policy, available interfaces might be provisioned with a transceiver.

• The network boundary of an available interface indicates if it’s for internal or external use.

Transit

These interfaces are used to connect to an upstream providers of Internet connectivity. They typically support BGP full routes.

Virtual Cross Connect

This interface type is a third-party Layer 2 interface that enables point-to-point or multipoint connectivity. Use cases include backbone and point-to-point interfaces, customer extranets, and indirect cloud interconnects.

Classification Rules

Interface classification is an automated process that assigns network boundary and connectivity type attributes to every device registered with Kentik. The process, run from the Interface Classification Page of the Kentik portal, involves creating and applying “if-match-then-classify” rules. The rules engine periodically evaluates interface descriptions and IP addresses gathered via SNMP polling for devices. It matches conditions in the rules and classifies the matching interface.

Note: For more information, see Applying Classification Rules.

Classification of Flows

Classification of flows involves storing network boundary and connectivity type values for each interface in Kentik’s device database. When traffic crosses a device, Kentik derives interfaces from device-generated flow records (e.g., NetFlow), looks up those interfaces in the device database, and incorporates attribute values into the flow records stored in the Kentik Data Engine (KDE).

Including interface classification attributes in the device database enables the following:

• Each interface on each device can be classified with its network boundary (internal or external) and connectivity type.

• Each flow record in KDE can include the network boundary and connectivity type values for its source and destination interfaces.

© 2014-25 Kentik