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:

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:

sudo tcpdump "udp port 2055

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:

sudo tcpdump "src 192.0.2.11 and udp port 2055"

sudo tcpdump -i eth0 "src 192.0.2.11 and udp port 2055"

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:

{"level":"error","ts":"2023-06-09T02:50:20.427Z","logger":"flow_processor","caller":"flowprocessor/flow.go:75","msg":"failed to process record","code":"processor/process-record-error","reason":"sFlow v5: could not decode samples: flow struct not supported - enterprise: 25506, format: 1003","stacktrace":"g

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 issue applies to both NetFlow v9 and IPFIX templates.

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

error netflow9/netflow9.go:59        netflow v9: could not decode flowsets: template not yet received from 10.1.1.1 for session: 27856, observation domain: 33312, template ID 260

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.

sudo tcpdump "src 192.0.2.11 and udp port 2055" -w netflow.pcap -vvv

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.