Traffic Insights System Requirements

This section describes certain prerequisites, plus hardware, software, and configuration requirements for Traffic Insights components, including:

• Enterprise Agent device and installation types that can be enabled for Traffic Insights.

• The Cisco SD-WAN versions and other Cisco devices supported, as well as support for non-Cisco devices.

• Network flow record requirements.

Component Relationships

Before we get into the specifics of hardware and software requirements, it’s important to note how the different network components interact with each other. Here are some guidelines regarding one-to-one and many-to-one relationships between traffic monitors, forwarders, and the interfaces being monitored.

• There is a maximum of one forwarder enabled per Enterprise Agent.

• You can have multiple traffic monitors sending network flow data to a single forwarder that’s been enabled on a ThousandEyes Enterprise Agent. See Forwarder Flow Capacity for the different monitor-to-forwarding-agent ratios.

• A single traffic monitor can be watching different interfaces, and send network flow data for multiple interfaces to the same Enterprise Agent forwarder.

• The same interface can be monitored for both IPv4 and IPv6.

Flow Forwarder Requirements

The following requirements and performance criteria apply to the Enterprise Agents you enable for flow forwarding.

Enterprise Agent Requirements

The forwarder enablement on the ThousandEyes Enterprise Agent is supported only for:

• ThousandEyes Virtual Appliances (TEVA). Machine requirements:

  • 32 GB RAM, 16 Cores.

  • 8 GB RAM, 4 Cores.

• CAF (Cisco Application-Hosted Framework)

  • Available via ISR1k, ISR4k, Cat8k and ASR1k routers.

In addition, there are a couple restrictions on the use of Enterprise Agents:

• No clustering: You cannot enable Traffic Insights for an Enterprise Agent cluster. Any Enterprise Agent that has already been enabled for Traffic Insights cannot be added to a cluster. See Working with Enterprise Agent Clusters for more information.
• No shared Account Groups: You cannot enable Traffic Insights for an Enterprise Agent that is shared with another Account Group. Any Enterprise Agent that has already been enabled for Traffic Insights cannot be shared with another Account Group.

To check if you already have a supported Enterprise Agent, see Finding a Supported Agent. If you don’t already have a compatible Enterprise Agent, you can install one for Traffic Insights; see the Enterprise Agent Installing section for the relevant articles about installing an Enterprise Agent on a virtual appliance or via the CAF.

Forwarder Flow Capacity

Flow forwarder capacity is estimated for each Enterprise Agent type below. Estimations are based on the most powerful machine configuration and on records containing all recommended fields. Minimum flow records could enable a higher rate while flow records with more than the recommended number of fields might yield a lower rate. A packet per second (PPS) is estimated to equal around 10 flows per second (FPS).

• One TEVA forwarding agent on a 32 GB RAM machine supports up to 200,000 FPS (around 20,000 PPS) and up to 1,000 traffic monitors.

• One TEVA forwarding agent on an 8 GB RAM machine supports up to 50,000 FPS (around 5,000 PPS) and up to 1,000 traffic monitors.

• One CAF forwarding agent supports up to 10,000 FPS (around 1,000 PPS) and up to 3 traffic monitors.

• A ThousandEyes Account Group is capped at 500,000 FPS (around 50,000 PPS), regardless.

Note: Once you have set up Traffic Insights, you can check whether your forwarder is breaching capacity via the Dropped Events column at Traffic Insights > Settings > Forwarders. If the number in the column is higher than 0, some packets were likely discarded due to overcapacity. For example, a TEVA agent that receives 250,000 FPS may drop up to 50,000 FPS (around 5,000 PPS) in order to maintain its estimated capacity of 200,000 FPS. The Dropped Events column in this case would reflect the number of discarded packets. See the Forwarders Screen for a screenshot.

Deployment Approaches

The capacity rates above for TEVA and CAF naturally suggest two kinds of forwarder deployment approaches. Because the TEVA appliance can handle much larger exporter numbers and flow rates, we recommend installing the forwarder on one or more centralized Enterprise Agents at central or regional data centers. In this scenario, you only configure one forwarder for your entire network or one forwarder per regional network.

For those using CAF, we recommend a more distributed approach, such as a forwarder on each local network. CAF users are likely to have Enterprise Agents already installed on these local networks, making enabling them as forwarders relatively straightforward.

Additionally, we recommend using the designated Enterprise Agent(s) only for Traffic Insights, rather than as an agent that also runs tests. We acknowledge, however, in the CAF scenario, that you may be repurposing Enterprise Agents that still run tests. In this case, we recommend reducing the number of tests run on those agents to less than 10 to optimize their flow rates.

Cisco Catalyst SD-WAN and IOS-XE Requirements

Cisco Catalyst SD-WAN includes Cisco Catalyst SD-WAN Manager, formerly known as vManage.

The following minimum and recommended versions apply when using Cisco SD-WAN or other devices that run IOS-XE to set up your network flow environments.

Supported IOS-XE Versions

• Minimum required IOS-XE version:

  • Cisco IOS-XE v17.9 +.

• Minimum recommended IOS-XE version:

  • Cisco IOS-XE v17.15.1 +.

Supported Cisco Catalyst SD-WAN Versions

• Minimum required version for Cisco SD-WAN environments that use Cisco Catalyst SD-WAN:

  • Cisco Catalyst SD-WAN Release 20.9 +.

• Minimum recommended version for Cisco SD-WAN environments that use Cisco Catalyst SD-WAN:

  • Cisco Catalyst SD-WAN Release 20.12.1 +.

Traffic Monitor Requirements

Traffic monitors can be configured on the following types of routers and/or switches within your enterprise network.

Supported Cisco Devices

Supported Cisco devices for NetFlow v9 and IPFIX are:

Routers

• ISR1K

• ISR4K

• CSR1K

• ASR1K

• Cat8K

Switches

• Cat9K for switches

Meraki

• MX devices

These devices don’t have to be capable of running a ThousandEyes Enterprise Agent. They only have to be able to send network flows to Enterprise Agents acting as a forwarders.

Supported Non-Cisco Devices

Any device that supports the standard NetFlow v9 or IPFIX with the minimum fields can send network flow data to Traffic Insights. See Minimum Fields Required for information about the minimum fields.

Network Flow Record Requirements

Traffic Insights supports NetFlow v9 and IPFIX network flow records as outlined below.

This section is intended for a technical audience, specifically network engineers who already have a solid working knowledge of enterprise networking, and prior experience configuring network flow on network devices.

The network flow configuration for NetFlow v9 and IPFIX can vary based on the network environment. Traffic Insights only requires a minimum set of fields, but we recommend using the recommended set of fields for optimum functionality, including application visibility fields. Minimum fields correspond to a 5T (5-tuple) record type. Find more information below at Network Flow Traffic Types.

To receive network flow data, you must ensure the minimum records are captured on each network device that serves as a traffic monitor.

Configuration of Network Flows on Cisco vs. non-Cisco Devices

For those using Cisco Catalyst SD-WAN Manager (formerly vManage) or Meraki MX, the bulk of the network flow configuration is performed via their user interfaces. See Step 3.6 Option 1: Cisco SD-WAN Centralized Cflowd policy for SD-WAN Manager and 3.3 Meraki Dashboard Configuration for Meraki MX.

However, if you are not using Cisco’s SD-WAN solution or Meraki MX, you may need to manually configure network flow records on your Cisco or non-Cisco devices in order to create records that can be ingested by Traffic Insights. The following section describes the minimum and recommended IPFIX and NetFlow-equivalent fields required as part of these records. The configuration steps for manual flow record configuration are described under 3.1 Command-Line Configuration.

Network Flow Traffic Types

Network flow “records” are better understood as network flow traffic types rather than a formally defined “record type”, since the records themselves don’t contain a record type identifier.

While there are multiple traffic types (e.g., 4-tuple, 5-tuple, application performance monitoring (APM), and WAN, with unidirectional and bidirectional variants), minimum records only mandate the 5T (5-tuple) type, while the recommended records optimize your results by including fields from other traffic types.

Network Flow Records and Fields

Information within this section is based on IP Flow Information Export (IPFIX) Entities from the Internet Assigned Numbers Authority (IANA). The IANA document serves as a network flow data dictionary reference.

Fields are uniquely referenced by number (in parentheses in the tables below) rather than by descriptive name. The descriptions themselves are not part of the standard nomenclature as they don’t appear in the network flow traffic records, but are included for understanding here.

Fields also come in two types: match fields and collect fields. Match fields identify and classify the data collected; they are what determine the type of traffic, and hence record, it is. For example, source IP and destination IP are match fields that help to identify where the traffic is coming from and going to. Collect fields “collect” additional data about the traffic, such as how many bytes the traffic is using, packets are being sent, or application it’s related to. Collect fields are mostly used to help analyze traffic flow data.

The IANA document covers standard fields up to number 32767. Any number above 32767, for example 45005, are Cisco-specific and are not part of the IANA standard. Not all IANA fields have a Cisco equivalent.

How Records are Recognized by ThousandEyes

ThousandEyes recognizes a network flow record as valid based on whether it includes the minimum fields listed below. If one of the minimum-required fields is missing, the record is ignored. Records can include more than the minimum-required fields, of course.

In cases where there are different fields depending on whether you are monitoring an IPv4 or an IPv6 interface, those fields are both listed as alternatives and you should choose the appropriate option.

Minimum Fields Required

The following collect and match fields are mandatory for ThousandEyes to be able to ingest your network’s flow record.

Description	Field Type	IANA Field	Cisco Alternative Fields
Number of total bytes transferred	Collect	octetDeltaCount (1)
Protocol ID, IPv4 or IPv6	Match	protocolIdentifier (4)
Source port	Match	sourceTransportPort (7)	Cisco client transport port (45008)
Source IP address	Match	Use one of: sourceIPv4Address (8), sourceIPv6Address (27)	Use one of: Cisco client IP address, IPv4 (45004), Cisco client IP address, IPv6 (45006)
ID of the interface where packets are received	Match	ingressInterface (10)
Destination port	Match	destinationTransportPort (11)	Cisco server port (45009)
Destination IP address	Match	Use one of: destinationIPv4Address (12), destinationIPv6Address (28)	Use one of: Cisco server IP address, IPv4 (45005), Cisco server IP address, IPv6 (45007)
ID of the interface packets are sent to	Collect	egressInterface (14)

Recommended Fields

Whether you have configured flow records already or not, we recommend ensuring the following collect fields are part of your flow records, in addition to the minimum fields, for optimum network visibility.

Description	Field Type	IANA Field
Number of incoming packets	Collect	packetDeltaCount (2)
TCP transport flags	Collect	tcpControlBits (6)
IP address of the next hop	Collect	Use one of: ipNextHopIPv4Address (15), ipNextHopIPv6Address (62)
Direction of the traffic flow	Collect	flowDirection (61)
ID of the application generating the traffic (for Cisco networks)	Collect	applicationId (95)
The point where traffic observation occurs	Collect	observationPointId (Interface) (138)
Timestamp of the absolute first packet	Collect	flowStartMilliseconds (152)
Timestamp of the absolute last packet	Collect	flowEndMilliseconds (153)
DSCP value, IPv4 or IPv6	Collect	ipDiffServCodePoint (195)

For Optimum Functionality

In order to generate fully enriched network flow data in ThousandEyes, you need to enable certain features inside your enterprise network.

Application Recognition

Cisco offers application recognition via NetFlow v9 on its networks via two methods: for non-SD-WAN solutions, you must include the applicaton ID field as part of your flow record (see recommended fields); for networks using an SD-WAN solution, you must enable an application policy or application visibility on your SD-WAN solution (see Configure Traffic Flow Monitoring for information about application visibility on your device template). Both of these methods activate Cisco's NBAR (Network Based Application Recognition), which enhances your Traffic Insights experience with application data for applications with public IP addresses. Through your SD-WAN solution, or via the CLI for non-SD-WAN Cisco networks, you can also separately set up custom applications for identification, ensuring you see applications in Traffic Insights with both public and private IP addresses (see Chapter: NBAR2 Custom Protocol).

For those using non-Cisco devices and for Meraki MX devices, Traffic Insights can infer application information about applications that have public IP addresses. As such, Traffic Insights is able to enrich your flow data with information about many commercial applications you use, so long as their IP addresses are public. Note that ThousandEyes cannot guarantee that an application with a public IP address will always be identifiable, but makes a best effort to identify it.

Identify Subnets

Subnet tagging gives you more granular data about your network flows, such as if they pertain to your engineering department or your HR department. If you want to use the subnet tagging feature of Traffic Insights, you need a list of all the subnets in use on your network, and then decide which ones are relevant for traffic profiling. The ones that are relevant can be tagged in Traffic Insights, as described in the section titled Subnet Tagging Screen.