Classification Overview

Interface classification is an automated process that enables your organization to quickly and easily understand the types of interfaces through which your traffic enters and leaves the network, giving you the ability to optimize your network for cost and performance. An overview of interface classification is provided in the following topics:

• About Interface Classification
• Network Boundary Attribute
• Connectivity Type Attribute
• Understanding Connectivity Types
• Classification Rules
• Classification of Flows

Notes:
- For information on managing classification via the Kentik portal's Interface Classification page, see Interface Classification.
- For a look at use cases for interface classification, see Using Interface Classification.

Interface classification involves assigning to each interface a value for two attributes (network boundary and connectivity type) and incorporating those attribute values into the flow records collected by Kentik from traffic using each interface. Once a given interface has been classified (see Classification Rules), you can use the classification values as source or destination dimensions and/or filters in queries in Data Explorer, Dashboards, or Alerting, and also via the Kentik V5 Query API.

The following key points give a high-level introduction to Interface Classification in Kentik:

• Rules are defined on the Interface Classification Page of the Kentik portal (click Admin in the portal navbar and then Interface Classification in the sidebar):
  - Rules evaluate either the description or IP address of an interface;
  - Rules apply a connectivity type value (see Connectivity Type Attribute) to an interface;
  - 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 percent of interfaces;
  - Identification of devices with the remaining interfaces so that the descriptions/IP addresses can be modified to enable automatic classification.
• Once a given interface is classified, the flow records for traffic using that interface are augmented with the classification values as they are ingested into KDE:
  - For network boundary the values are stored in the following KDE fields: src_interface_network_boundary, dst_interface_network_boundary;
  - For connectivity type the values are stored in the following KDE fields: src_interface_connectivity_type, dst_interface_connectivity_type.
• Once flow records that include connectivity and boundary classifications are ingested into KDE, Kentik queries can use those classifications for group-by dimensions and/or filters.

The network boundary attribute is used to classify interfaces as Internal or External, which enables you to see whether both the source and destination of the traffic are within your network or if the traffic crossed a network boundary (came from or went to a different AS). This distinction allows Kentik 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.

The diagram below illustrates the over-counting issue that network boundary classification is intended to address. AS100 is the autonomous system of an imaginary Kentik customer that receives and sends traffic to multiple ASNs via five network devices. We’ve got two flows (the light and dark gray lines), but each flow is generating three flow records that are sent to Kentik: at ingress (orange segments at left), internal to the network (red segments in center), and at egress (blue segments at right). If we want to count flows at ingress then we need to be able to exclude the flow records that aren’t from the two orange segments at the left. Likewise, if we want to count the flows at egress we need to be able to exclude the flow records that aren’t from the two blue segments at the right.

The following screenshot shows an example of a visualization that you can generate in Data Explorer once network boundary classification is implemented on a given interface.

By default, a network boundary value is assigned to an interface during interface classification based on the interface’s connectivity type, but the default classification may be overridden in an individual interface classification rule (see Rule THEN Settings). To change the defaults, see IC Default Network Boundaries.

The connectivity type attribute is used to classify interfaces by their role in the overall network, such as transit, ix, paid peering, etc. Identifying the type of connectivity used by traffic through a given interface gives you a way to look at the type of network from which a given set of traffic is entering and to which it is going, which helps you to determine costs and optimize pricing for that traffic. For a list of currently supported connectivity types, see Understanding Connectivity Types.

The connectivity type is derived by evaluation of the following types of SNMP polling data collected about the interfaces by Kentik (see SNMP OID Polling):

• Interface description: Most decent-size networks follow more or less consistent naming conventions, and those names are one of the first attributes looked at when troubleshooting, so there’s usually a strong incentive to keep them up to date. If an organization has SNMP polling enabled on all of its network devices, descriptions are readily available and pulled by Kentik.
  Note: If a description has been manually overridden (see Edit an Interface) then interface classification will use the description in Kentik rather than the SNMP-polled value.
• Interface IP address: Depending on a network’s addressing policies, connectivity type can be inferred from the IP Addressing on the interface, which is polled by Kentik. Examples of policies might include:
  - a range of IP addresses may be used exclusively for transit customers;
  - a range of RFC1918 IP addresses may be used exclusively for interfaces on CDN servers behind a load balancer;
  - a range corresponding to the LAN of a particular Internet Exchange.

The following screenshot shows an example of a visualization that you can generate in Data Explorer once connectivity type classification is implemented on a given interface.

Currently supported connectivity types are described in the following topics:

• Aggregation Interconnect
• Available
• Backbone
• Cloud Interconnect
• Customer
• Data Center Fabric
• Datacenter Interconnect
• Embedded Cache
• Free Private Peering
• Host/Access
• IX Peering
• Other
• Paid Private Peering
• Reserved
• Transit
• Virtual Cross Connect

A connectivity type of “Aggregation Interconnect” is usually applied to a bundle of interfaces between two devices that are on separate levels of traffic aggregation. These are typically found in hierarchical data center switching or routing topologies (e.g. Clos/leaf-and-spine). If there's no need for a specific distinction in this regard then these interfaces could alternatively be classified as backbone.

An “Available” interface is not currently used and not reserved for future use. The interface name or description may indicate that the interface is available in order to facilitate network planning.

Notes:
- Depending on company policy, available Interfaces may or may not be provisioned with a transceiver.
- The network boundary of an available interface may indicate if the interface is available for internal or external use.

“Backbone” is the generic connectivity type for an interface (or bundle of interfaces) between two devices within the same network, whether or not they are within the same data center. However, users with separate backbone and data center teams will typically use “datacenter interconnect” and “aggregation interconnect” categories inside the data center, and “backbone” outside of the data center.

An interface classified as “Cloud Interconnect” is used to connect a device residing in a physical location to a Public Cloud. The term used to refer to this type of connection varies depending on the 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 via a partner of the provider rather than indirectly then the connection should instead be classified as a Virtual Cross Connect.

An interface (or bundle of interfaces) classified as “Customer” would most typically point towards a downstream customer. The BGP session established through this interface would normally announce to that downstream customer either a full route view (in a case that is often referred to as “Full view transit”) or a partial route view (often referred to as “Partial Transit”). A customer interface can be seen as the financial inverse of a transit (full view) or paid private peering (partial view) interface.

An interface classified as "Data Center Fabric" connects devices within a data center to other devices within the same data center (e.g. devices that have been assigned Clos fabric roles such as Super Spine, Spine, Leaf, or Top of Rack).

An interface (or bundle of interfaces) classified as “Datacenter Interconnect” is used to connect devices within a single data center. While some users may think of these interfaces as “backbone,” this classification is intended for cases where a data center team and a backbone team coexist and one is a customer of the other.

“Embedded cache” refers to an interface that's connected to a Cache Appliance Server that’s been provided to an ISP by a CDN or content provider (e.g. Facebook Appliance, Google Global Cache, Netflix Open Connect, Akamai Caches, etc.). These appliances are typically embedded in the ISP's last mile network as a source from which to deliver popular traffic directly instead of from the more distant or busy network of the CDN or content provider. The content on these appliances is often refreshed via proxy feed during off-peak hours.

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

A connectivity type of as “Host” indicates a direct connection between a router and a server host.

A connectivity type of “IX” indicates an interface (or bundle of interfaces) that is connected to a public peering facility. In other words, it is connected to a switching LAN on which multiple ASes offer to peer. The main difference from a free or paid peering interface is that multiple BGP sessions will be drawn through this interface (or bundle of interfaces), each one to a different AS. The net result is that such an interface will have multiple Next-Hop ASNs behind it.

The classification “Other” is a “catch-all” for interfaces for which no other connectivity type applies. Users may use it for specific use cases not covered by any of the classifications described above. An alternative to using the “Other” connectivity type is to exclude interfaces from Interface Classification if they haven’t been assigned an IP address and/or description.

Interfaces classified as “Paid Private Peering” are connected identically to free private peering, but the arrangement involves some form of payment between the parties. The classifications are distinct in order to support cost-related business analytics.

A “Reserved” interface is currently available but is already allocated for a future use.

Notes:
- Depending on company policy, available Interfaces may or may not be provisioned with a transceiver.
- The network boundary of an available interface may indicate if the interface is available for internal or external use.

An interface whose connectivity type is classified as “Transit” is used to connect to an upstream provider of Internet connectivity. These interfaces typically support BGP full routes.

A Virtual Cross Connect is a Layer 2 interface provided by a 3rd party to enable point-to-point or multipoint connectivity. Use cases for Virtual Cross Connects include backbone and other point-to-point interfaces, customer extranets, and even indirect cloud interconnects.

Interface classification is an automated process whereby the value of the network boundary and connectivity type attributes are specified for the interfaces of every device that your organization has registered with Kentik. The classification process, which is run from the Interface Classification Page of the Kentik portal, involves creating and applying any number of “if-match-then-classify” rules. The rules engine periodically evaluates interface description and IP addresses gathered via SNMP polling for the interfaces of your devices. It looks for a match with conditions defined in your rules, and if a match is found it classifies the matching interface as specified in the matched rule.

Note: For further information, see Applying Classification Rules.

Once the network boundary and connectivity type values have been determined for each interface (see Classification Rules) those values are stored in the device database that Kentik uses for information about each device (and its interfaces) that your organization registers with the system. When traffic crosses a device, Kentik derives from the device-generated flow records (e.g. NetFlow) which interfaces the traffic passed through, looks up those interfaces in the device database, and incorporates attribute values from that database into the flow records that are stored in the Kentik Data Engine (KDE).

The inclusion of interface classification attributes in the device database enables the following:

• Each interface on each device can now be classified with its network boundary value (internal or external).
• Each interface on each device can now be classified with its connectivity type.
• Each flow record stored in KDE can now include the network boundary and connectivity type values for its source and destination interfaces.