Network Flows

Question: Can the Apstra Flow collector’s port be changed?

Answer: The collector receives packets containing flow records using UDP. Table 1 lists the three configurable parameters:

Table 1: UDP Input Parameters

UDP Parameters	Description
EF_FLOW_SERVER_UDP_PORT	The UDP port the Apstra Flow collector listens to for NetFlow/IPFIX/sFlow packets.
EF_FLOW_SERVER_UDP_IP	The IP addresses the UDP socket is bound to on the Apstra Flow collector.
EF_FLOW_SERVER_UDP_READ_BUFFER_MAX_SIZE	The UDP receive buffer for the system. If this value exceeds the maximum allowed buffer size ( net.core.rmem_max) on Linux, the maximum allowed size is used.

Problem

Flow exporters are configured to output IPFIX, sFlow, or NetFlow, but one or more flow exporters’ data does not appear in the Apstra Flow dashboards.

There can be several reasons for this:

• The packets carrying the expected flow records are not arriving at the system running the flow collector.
• The packets carrying the expected flow records are not arriving on a UDP port on which the collector is not listening.
• The Linux firewall is blocking the packets from reaching the collector.

Solution

Verify the packets are arriving.

Use tcpdump to verify that the packets carrying the expected flow records are arriving at the interface where the collector is listening. For example, if the collector is listening on UDP port 2055(EF_FLOW_SERVER_UDP_PORT) the following tcpdump command shows the incoming packets to this port:

To see packets from a specific exporter, you can also specify the exporter's IP address. For example, if packets are expected from 192.0.2.11, use the following command:

Note:

You might need to specify the interface on which tcpdump observes the incoming packet. You can do this by specifying the -i option in the tcpdump command. For example:

If you do not receive any packets, this can mean that:

• The device is not sending the packets.
• The packets are being sent to the wrong place.
• The packets are being blocked along the way, e.g. by a firewall

You will need to troubleshoot and fix this issue before proceeding.

Verify the collector is receiving the packets.

Verify that the collector is receiving the packets from the operating system, by running the collector with debug (EF_LOGGER_LEVEL) set to debug. A message should appear indicating when the packets were received and from which IP addresses the packets were sent.

If you have verified that the packets are arriving at the system, but you do not see any messages in the collector's logs, the packets are likely being blocked by the Linux firewall. You can temporarily disable the Linux firewall to confirm this. If after doing this the logs indicate that packets are received, you will need to reconfigure the Linux firewall to allow the traffic to reach the collector.

The log indicates that the Apstra Flow collector cannot process an sFlow record because it has enterprise-specific information that is not supported. For example:

Problem: The collector received an sFlow structure it does not recognize. This is usually due to a vendor sending its own enterprise-specific structure.

Solution: To add support for a specific sFlow Structure, contact Juniper support. You will need to supply a PCAP of the records that contain the structure and documentation from the vendor about the contents of the structure.

Problem: The Apstra Flow collector’s log displays the error: Could not decode flowsets: template not yet received. This error applies to both NetFlow v9 and IPFIX templates.

The Apstra Flow collector indicates a message similar to the following:

Solution:

In most cases, waiting allows the issue to resolve itself. You'll usually see these messages when starting the collector, however these messages should stop after the needed templates are received. Devices usually send templates every few minutes, although some may take 15-30 minutes. This interval is usually configurable, but may vary by vendor and model.

If waiting does not solve the problem, contact your Juniper sales representative. To investigate your issues, we'll need a PCAP of the incoming records from the device in question. The PCAP will need to be long enough to include templates.

In the following example, tcpdump is configured to capture incoming packets to port 2055 from 192.0.2.11 and write them to a file named netflow.pcap.

Question: How does Apstra Flow handle a flow exporter that supports bidirectional flow records (RFC 5103), where two directions of traffic are expressed in a single record?

Answer: The collector produces two unidirectional records, one for each direction. This allows the bidirectional flow records to be processed and analyzed in the same manner as unidirectional flows.