Network Flow Collection Is Missing Data

Network Flow Collection Is Missing Data

Problem

After installation of ktranslate, you're having issues collecting network flow telemetry.

Background

ktranslate returns the raw flow telemetry collected, without editing any of the packet payload. Several flow types are supported out of the box, with the most prominent being NetFlow v5, NetFlow v9, sFlow, and IPFIX.

Solution

Flow configuration on your network monitoring agent

ktranslate can only collect one type of flow template, configured by the -nf.source argument at runtime (defaults to auto). The auto setting tells ktranslate to expect any templates from NetFlow v5 | NetFlow v9 | sFlow | IPFIX so it can translate the packets. A common problem is setting ktranslate to listen to a specific type of flow template, and then exporting another type into the agent. You need to run separate containers for any templates not covered by auto.

Another common misstep is exporting flow telemetry to a ktranslate agent while targeting multiple ports as a destination. In this scenario, you need to run multiple ktranslate agents, with each set to a different value for -nf.port at runtime (default is 9995). You may also need to update the flow exporter configuration on your source network devices to target their specific port.

Flow configuration on your network device

Each vendor will have their own documentation on properly configuring their devices for the export of network flows. The more advanced versions like NetFlow v9, IPFIX, and sFlow have options that allow administrators to customize the fields being collected and exported. Editing these can effectively disable the ability for ktranslate to correctly process the flow records.

The following fields are required:

Required for all records

Field	Field Type Number	Description
Protocol	4	Layer 4 protocol
Source Address	8, 27	Source IPv4 or IPv6 address
Source Port	7	Source TCP/UDP port
Destination Address	12, 28	Destination IPv4 or IPv6 address
Destination Port	11	Destination TCP/UDP port

Required interface fields (at least one)

Field	Field Type Number	Description
Interface Receive	10	SNMP index for ingress interface
Interface Transmit	14	SNMP index for egress interface

Required bytes fields (at least one)

Field	Field Type Number	Description
Delta Bytes	1	Delta bytes
Total Bytes	85	Total bytes
Out Bytes	23	Out bytes
Initiator Octets	231	Initiator bytes
Responder Octets	232	Responder bytes

Required packets fields (at least one)

Field	Field Type Number	Description
Delta Packets	2	Delta packets
Total Packets	86	Total packets
Out Packets	24	Out packets
Initiator Packets	298	Initiator packets
Responder Packets	299	Responder packets

Required routing fields (at least one)

Field	Field Type Number	Description
ToS	5	Type of service
Source AS	16	Source BGP autonomous system number
Destination AS	17	Destination BGP autonomous system number
Peer Source AS	129	Peer source BGP autonomous system number
Peer Destination AS	128	Peer destination BGP autonomous system number

Tip: ktranslate defaults all flow records to Direction: ingress unless the record explicitly uses a value of egress. This covers various situations where flow records are sent without the Direction field.

Confirming flow reception

Each vendor will have their own documentation on watching flow export counters via their device CLI/UI. A lack of counter growth on the device indicates the flow export is not configured correctly on the device.

Both the Docker container and Linux service deployment options for ktranslate use the host's network to receive data on the mapped port. To validate that flow records are being received by the host, you can use the tcpdump utility to create a packet capture (.pcap) file that you can later investigate in Wireshark.

The following command sets tcpdump to capture every incoming packet across all interfaces on the host and write the output to a file in the current directory:

sudo tcpdump -s 0 -i any -w dump_capture.pcap

You can add multiple arguments to tcpdump. The most important item here is the output file, which you can use for analysis later. Outputting results to STDOUT creates limited value for this purpose.

Tip: One of the most common issues found is a network configuration/firewall rule that blocks packets from the source network devices to the target ktranslate host. If you're not getting any results with tcpdump, start by confirming your network rules and iptables configuration.

Identifying flow record templates with Wireshark

Follow these steps to use Wireshark to inspect the packet capture file.

1. Start the Wireshark application and open the packet capture file.

2. The initial view shows all captured packets. For flow analysis, you need to set the application to decode them properly. Using the menu, navigate to Analyze > Decode As..., which opens a new popup.

3. In the popup, click the plus (+) icon in the bottom left to add a new row to the panel. The initial option in the Current column is (none). Click it to open a drop-down menu and select either CFLOW (for NetFlow and IPFIX) or sFlow (for sFlow packets). Click OK in the bottom right to return to the main UI.

   Tip: This menu is alphabetized with case-sensitivity. The sFlow option is at the very bottom of the list.

4. In the main UI, you should now see CFLOW | sFlow packets identified in the Protocol column. Applying the display filter (cflow or sflow) will automatically isolate the relevant packets from anything else in the capture file.

The following sections outline how to inspect each packet type.

Analyzing NetFlow and IPFIX packets

NetFlow and IPFIX protocols use a template approach where the administrator identifies which fields to collect from a list of standard options. Analysis of these packets ensures the required fields listed above are being captured.

In the Wireshark main UI, click to select a single CFLOW packet and expand the section titled FlowSet n, where n is an integer identifying a singular flow record in the packet. Then expand the Flow n subgroup to analyze the fields of that flow record.

Tip: You can also click the Template Frame link in the packet to jump to the captured packet that contains the template for all flows from that device.

Analyzing sFlow packets

Due to protocol differences between sFlow and the more traditional NetFlow/IPFIX protocols, there are different fields to analyze.

In the Wireshark main UI, click to select a single sFlow packet and expand the section titled InMon sFlow. The following fields should be present:

Field	Description
Datagram version	The version of this sFlow packet.
Agent address type	IPv4 (1) or IPv6 (2)
Agent address	IP address the flows are being exported from. This is where you have your flow exporter configured.
Sub-agent ID	In sFlow v5, you can run multiple exporter processes. This is their unique identifier.
Sequence number	The number of sFlow packets sent by the agent device.
SysUptime	Time since the agent device last rebooted.
NumSamples	The count of sFlow samples contained in the current packet.

Expanding a sub-group entitled Flow sample will show these additional fields:

Field	Description
Enterprise	Annotates custom sFlow enterprise configurations that administrators can optionally enable. (0 by default)
sFlow sample type	The designation for the type of sample when an enterprise customizes their sFlow exports. See the sFlow documentation for definitions.
Sample length	Length of the sample, in bytes.
Sequence number	Counter value incremented every time the agent takes a sample.
Sampling rate	1 in X packets are sampled.
Sample pool	Total possible packets that could have been sampled, including the actual sampled packets.
Dropped packets	Number of packets dropped due to resource constraints.
Input interface	SNMP ifIndex of the interface the packet arrived on.
Flow record	Number of sampled records contained in this sample.

Tip: This same pattern — without the Decode as... step — can be applied to validate receipt of both syslog and SNMP trap data.