Using VXLAN

The following topics provide a high-level overview to the use of VXLAN in Kentik:

• About VXLAN
• VXLAN in Kentik
• VXLAN Devices
• sFlow Tunnel Decode Devices
• Future Implementations

Formalized as RFC7348, Virtual eXtensible Local Area Network (VXLAN) is a protocol enabling the establishment of overlay networks using tunnels that carry Layer 3 UDP packets of encapsulated Layer 2 Ethernet frames. Developed primarily for use in data centers with multiple tenants, VXLAN addresses the limitations of VLAN to provide a more scalable and flexible approach to network virtualization.

Kentik currently supports VXLAN with two distinct categories of dimensions for group-by and filtering:

• VXLAN dimensions: High-level visibility for VXLAN traffic (see VXLAN Devices):
  - The flow format for the device must be sFlow (see Flow Protocols).
  - The device's Type (see Device General Settings) must be set to "VXLAN."
  - Individual dimensions are listed in our Dimensions Reference at VXLAN Dimensions.
• sFlow Tunnel Decode dimensions: Visibility into VXLAN encapsulated packets (see sFlow Tunnel Decode Devices):
  - The flow format for the device must be sFlow (see Flow Protocols).
  - The device's Type (see Device General Settings) must be set to "sFlow Tunnel Decode."
  - Individual dimensions are listed in our Dimensions Reference at sFlow Tunnel Decode Dimensions.

Use of the VXLAN device type provides visibility for traffic on sFlow-supporting network devices that use tunneling protocols — VXLAN, among others — to carry traffic over overlay networks in the data center. With VXLAN and similar tunneling protocols, valuable information about the traffic on virtual networks is encapsulated inside the headers, where it is “hidden” from standard flow monitoring protocols. When you set the device type to VXLAN, however, Kentik is able to take advantage of the fact that sFlow supports the export of certain parts of the packet (usually first 128-256 bytes), which includes the headers of any tunneling protocol used. This enables Kentik to extend the observability of data center traffic beyond just the "underlay" traffic that is traditionally visible between network devices, so you can also monitor the overlay traffic that traverses via tunnel between servers or virtual machines.

On VXLAN devices, Kentik decodes the information extracted from the sFlow headers into VXLAN-related dimensions that can be used for filtering and group-by. The diagram below shows how, in the case of a single VXLAN tunnel, Kentik's VXLAN dimensions are populated from the relevant data in the packet header.

When the VXLAN device type is used, the information extracted by Kentik follows the pattern and the structure of the network packet protocol stack. The limitation of this approach is that the information about the tunneled traffic that is of prime importance to users will be stored as VXLAN-related metrics rather than in “standard” traffic dimensions such as Protocol and source and destination MAC, IP, Ports, etc.

The "sFlow tunnel decode" approach was developed to address this issue, improving visibility into traffic transported via tunneling protocols such as VXLAN, as well as (in the future) GRE/NVGRE, GENEVE and others. Using the “sFlow Tunnel decode” device type instead of the "VXLAN" type described above changes the way that information is represented by Kentik's filter and group-by dimensions:

• Information about tunneled traffic is represented by the standard traffic dimensions mentioned above.
• VXLAN-specific information is stored in VXLAN-related dimensions, specifically VTEP and VNI.

The diagram below illustrates the mapping of the header information into Kentik dimensions in the sFlow tunnel decode category.

With the two VXLAN-related device types described above, Kentik gives users visibility into overlay traffic tunneled by VXLAN in the data center environment. We encourage you to let us know which of these approaches you find most effective. We'd also like to know whether it would be helpful for us to add similar support for other tunneling (network virtualization) protocols such as GRE/NVGRE or GENEVE. To share your thoughts, please use the Contact Support form (accessed via the Feedback icon at the right of the portal's main navbar). Your input will enable us to continue developing data center observability that best fits your needs.