Configure a NetFlow & IPFIX Source

​

1. On the top bar, select Products, and then select Cribl Stream. Under Worker Groups, select a Worker Group. Next, you have two options:
   • To configure via QuickConnect, navigate to Routing > QuickConnect (Stream) or Collect (Edge). Select Add Source and select the Source you want from the list, choosing either Select Existing or Add New.
   • To configure via the Routes, select Data > Sources (Stream) or More > Sources (Edge). Select the Source you want. Next, select Add Source.
2. In the New Source modal, configure the following under General Settings:
   • Input ID: Enter a unique name to identify this Source.
   • Description: Optionally, enter a description.
   • Address: Enter the hostname/IP on which to listen for data. For example: localhost, 0.0.0.0, or ::.
   • Port: Enter the port number.
   • Enable pass-through: Enable this setting to allow Cribl Stream to forward events to a NetFlow Destination. If enabled, Cribl Stream generates an additional event containing __netflowRaw, which directly routes the raw NetFlow packet data to a downstream NetFlow Destination. These additional events do not count against any ingest quotas.
   • Version Support: Toggle which versions of NetFlow and IPFIX (NetFlow v10) data are processed. By default, all versions (V5, V9, and IPFIX) are enabled. You can disable support for specific versions if needed. Disabling a version prevents the Source from processing data for that version and treats any received packets of that version as unsupported messages.
3. Next, you can configure the following Optional Settings:
   • Tags: Optionally, add tags that you can use to filter and group Sources in Cribl Stream’s UI. These tags aren’t added to processed events. Use a tab or hard return between (arbitrary) tag names.
4. Optionally, you can adjust the Persistent Queue, Processing, and Advanced settings outlined in the sections below.
5. Select Save, then Commit & Deploy.

Persistent Queue Settings

​

In the Persistent Queue Settings tab, you can optionally specify persistent queue storage, using the following controls. Persistent queue buffers and preserves incoming events when a downstream Destination has an outage or experiences backpressure.

Before enabling persistent queue, learn more about persistent queue behavior and how to optimize it with your system:

• About Persistent Queues
• Optimize Source Persistent Queues (sPQ)

On Cribl-managed Cloud Workers (with an Enterprise plan), this tab exposes only the Enable Persistent Queue toggle. If enabled, PQ is automatically configured in Always On mode, with a maximum queue size of 1 GB disk space allocated per PQ‑enabled Source, per Worker Process.

The 1 GB limit is on uncompressed inbound data, and the queue does not perform any compression. This limit is not configurable. For configurable queue size, compression, mode, and other options below, use a hybrid Group.

Enable persistent queue: Default is toggled off. When toggled on:

Mode: Select a condition for engaging persistent queues.

• Always On: This default option will always write events to the persistent queue, before forwarding them to the Cribl Stream data processing engine.
• Smart: This option will engage PQ only when the Source detects backpressure from the Cribl Stream data processing engine.

Smart mode only engages when necessary, such as when a downstream Destination becomes blocked and the Buffer size limit reaches its limit. When persistent queue is set to Smart mode, Cribl attempts to flush the queue when every new event arrives. The only time events stay in the buffer is when a downstream Destination becomes blocked.

Buffer size limit: The maximum number of events to hold in memory before reporting backpressure to the sender and writing the queue to disk. Defaults to 1000. This buffer is for all connections, not just per Worker Process. For that reason, this can dramatically expand memory usage. Connections share this limit, which may result in slightly lower throughput for higher numbers of connections. For higher numbers of connections, consider increasing the limit.

Commit frequency: The number of events to send downstream before committing that Stream has read them. Defaults to 42.

File size limit: The maximum data volume to store in each queue file before closing it and (optionally) applying the configured Compression. Enter a numeral with units of KB, MB, and so forth. If not specified, Cribl Stream applies the default 1 MB.

Queue size limit: The maximum amount of disk space that the queue is allowed to consume on each Worker Process. Once this limit is reached, this Source will stop queueing data and block incoming data. Required, and defaults to 5 GB. Accepts positive numbers with units of KB, MB, GB, and so forth. Can be set as high as 1 TB, unless you’ve configured a different Worker Process PQ size limit in Group or Fleet settings.

Queue file path: The location for the persistent queue files. Defaults to $CRIBL_HOME/state/queues. To this field’s specified path, Cribl Stream will append /<worker-id>/inputs/<input-id>.

Compression: Optional codec to compress the persisted data after a file closes. Defaults to None; Gzip is also available.

In Cribl Stream 4.1 and later, the Source persistent queue default Mode is Always on, to best ensure events’ delivery. For details on optimizing this selection, see Optimize Source Persistent Queues (sPQ).

You can optimize Workers’ startup connections and CPU load at Group/Fleet settings > Worker Processes.

Processing Settings

​

Fields

​

In this section, you can define new fields or modify existing ones using JavaScript expressions, similar to the Eval function.

• The Name specifies the field name, which can either be a new field (unique within the event) or an existing field name to modify its value.
• The Value is a JavaScript expression (enclosed in quotes or backticks) to compute the field’s value (can be a constant). Select this field’s advanced mode icon (far right) if you’d like to open a modal where you can work with sample data and iterate on results.

This flexibility means you can:

• Add new fields to enrich the event.
• Modify existing fields by overwriting their values.
• Compute logic or transformations using JavaScript expressions.

Pre-Processing

​

In this section’s Pipeline drop-down list, you can select a single existing Pipeline or Pack to process data from this input before the data is sent through the Routes.

Advanced Settings

​

IP allowlist regex: Regex matching IP addresses that are allowed to establish a connection. Defaults to .* (that is, all IPs).

IP denylist regex: Regex matching IP addresses whose messages you want this Source to ignore. Defaults to ^$ (that is, every specific IP address in the list). This takes precedence over the allowlist.

UDP socket buffer size (bytes): Optionally, set the SO_RCVBUF socket option for the UDP socket. This value tells the operating system how many bytes can be buffered in the kernel before events are dropped. Leave blank to use the OS default. Minimum: 256. Maximum: 4294967295.

It may also be necessary to increase the size of the buffer available to the SO_RCVBUF socket option. Consult the documentation for your operating system for a specific procedure.

Setting this value will affect OS memory utilization.

Template cache minutes (minutes): This setting only affects v9 flow records. Use this setting to specify the length of time (in minutes) that Cribl Stream caches NetFlow v9 templates before discarding them. For example, setting the duration to 30 means Cribl Stream will cache templates for 30 minutes. If flow records are not refreshed by a new event, the templates are discarded.

The template cache minutes setting helps optimize the performance and reliability of NetFlow v9 data processing. This setting manages memory usage and ensures that outdated templates do not persist indefinitely. The goal is to balance system performance against memory use. Monitor your network and adjust this setting to find the right balance between template availability and system data overload. Some considerations when tuning your system:

• If your network’s data patterns change often, consider using a shorter cache duration. Conversely, if the data records are stable and change less frequently, try using a longer duration.
• Monitor the status of this Source across your Worker/Edge nodes. If you notice Cribl Stream discards FlowSets, it may mean the cache duration is too short. Try increasing the cache duration and then observer whether there is a performance improvement. Alternatively, adjust your NetFlow exporters to send templates more frequently.
• If your system is using too much memory, it may mean that your cache duration is too long, especially if you have a lot of NetFlow exporters sending data to a single Source.

Environment: If you’re using GitOps, optionally use this field to specify a single Git branch on which to enable this configuration. If empty, the config will be enabled everywhere.

Connected Destinations

​

Select Send to Routes to enable conditional routing, filtering, and cloning of this Source’s data via the Routing table.

Select QuickConnect to send this Source’s data to one or more Destinations via independent, direct connections.

What Fields to Expect

​

The NetFlow Source does minimal processing of the incoming UDP messages to remain consistent with the internal Cribl event model. For each UDP message received on the socket, you can expect an event with the following fields.

Field Representation for NetFlow v9 & IPFIX (v10)

​

For both NetFlow v9 and IPFIX (v10), fields map to their most natural representation in Cribl. Specifically:

• IPv4 addresses are represented as dotted octet strings.
• IPv6 as colon-separated octet strings.
• MAC addresses also as colon-separated strings.
• Numbers that are six bytes or less are represented as numbers.
• Numbers that are greater than six bytes are represented as strings.
• Registered field attribute names are the camelCase versions of the SCREAMING_CASE names in the Cisco whitepaper.

Cribl Stream collects and offers unregistered fields in an array of records consisting of their type codes and byte buffers. You can add Pipeline functions to change how these fields are processed by default.

Fields for NetFlow IPFIX (v10)

​

IPFIX fields are derived from the IANA IPFIX Information Elements list. These fields are predefined and included in the ipfix-information-elements.yml configuration file.

Fields for NetFlow v9

​

We have organized these fields into categories to make them easier to grasp; the categories are our own, and not from the NetFlow specifications. The field definitions are mostly copied from Cisco NetFlow documentation.

Not all NetFlow v9 fields will appear on all events, only those that are specified by the template for that specific data record. These fields are available for NetFlow v9:

• inBytes: The number of incoming Bytes.
• inPkts: The number of incoming packets.
• flows: The number of flows that were aggregated.
• protocol: The IP protocol.
• srcTos: The type of service setting when entering the incoming interface.
• tcpFlags: The accumulation of all the TCP flags seen in this flow.
• l4SrcPort: The TCP/UDP source port number.
• ipv4SrcAddr: The IPv4 source address.
• srcMask: The number of contiguous bits in the source subnet mask.
• inputSnmp: The input interface index.
• l4DstPort: The TCP/UDP destination port number.
• ipv4DstAddr: The IPv4 destination address.
• dstMask: The number of contiguous bits in the destination subnet mask.
• outputSnmp: The output interface index.
• ipv4NextHop: The IPv4 address of the next-hop router.
• srcAs: The source BGP autonomous system number. The length may be and defaults to 2.
• dstAs: The destination BGP autonomous system number. The length may be and defaults to 2.
• bgpIpv4NextHop: The IPv4 address of the next-hop router in the bgp domain.
• mulDstPkts: The number of IP multicast outgoing packets.
• mulDstBytes: The number of IP multicast outgoing bytes.
• lastSwitched: The system uptime in milliseconds at which the last packet of this flow was switched.
• firstSwitched: The system uptime in milliseconds at which the first package of this flow was switched.
• outBytes: The number of outgoing bytes.
• outPkts: The number of outgoing packets.
• minPktLngth: The minimum IP packet length on incoming packets.
• maxPktLngth: The maximum IP packet length on incoming packets.
• ipv6SrcAddr: The IPv6 source address.
• ipv6DstAddr: The IPv6 destination address.
• ipv6SrcMask: The number of contiguous bits in the IPv6 source mask.
• ipv6DstMask: The number of contiguous bits in the IPv6 destination mask.
• ipv6FlowLabel: The IPv6 flow label as per the RFC 2460 definition.
• icmpType: The ICMP packet type, reported as type * 256 + code.
• mulIgmpType: The IGMP packet type.
• samplingInterval: The rate at which packets are sampled; a value of 100 indicates that 1% of packets are sampled.
• samplingAlgorithm: The platform sampling algorithm; 1 is deterministic, 2 is random.
• flowActiveTimeout: Timeout value in seconds for active flow entries in the NetFlow cache.
• flowInactiveTimeout: Timeout value in seconds for inactive flow entries in the NetFlow cache.
• engineType: The type of flow switching engine; 0 is RP, 1 is VIP/Linecard.
• engineId: The ID number of the flow switching engine.
• totalBytesExp: The number of bytes exported by the observation domain.
• totalPktsExp: The number of packets exported by the observation domain.
• totalFlowsExp: The number of flows exported by the observation domain.
• ipv4SrcPrefix: The IPv4 source address prefix, specific for Catalyst architecture.
• ipv4DstPrefix: The IPv4 destination address prefix, specific for Catalyst architecture.
• mplsTopLabelType: The MPLS top label type; 0 is unknown, 1 is TE midpoint, 2 is AToM, 3 is VPN, 4 is BGP, and 5 is LDP.
• mplsTopLabelIpAddr: The IPv4 address of the forwarding equivalent class corresponding to the MPLS top label.
• flowSamplerId: The ID number of the flow sampler.
• flowSampleMode: The type of algorithm used for sample data.
• flowSamplerRandomInterval: The packet interval at which to sample.
• minTtl: Minimum TTL on incoming packets.
• maxTtl: Maximum TTL on incoming packets.
• ipv4Ident: The IPv4 identification field.
• dstTos: The type of service byte setting when exiting the outgoing interface.
• inSrcMac: The incoming source MAC address.
• outDstMac: The outgoing destination MAC address.
• srcVlan: The virtual LAN ID associated with the ingress interface.
• dstVlan: The virtual LAN ID associated with the egree interface.
• ipProtocolVersion: The IP version. The default is assumed to be 4 if unspecified.
• direction: The flow direction; 0 is ingress, 1 is egress.
• ipv6NextHop: The IPv6 address of the next-hop router.
• bgpIpv6NextHop: The IPv6 address of the next-hop router in the bgp domain.
• ipv6OptionHeaders: The IPv6 option headers found in the flow.
• mplsLabel1: The MPLS label at position 1 in the stack.
• mplsLabel2: The MPLS label at position 2 in the stack.
• mplsLabel3: The MPLS label at position 3 in the stack.
• mplsLabel4: The MPLS label at position 4 in the stack.
• mplsLabel5: The MPLS label at position 5 in the stack.
• mplsLabel6: The MPLS label at position 6 in the stack.
• mplsLabel7: The MPLS label at position 7 in the stack.
• mplsLabel8: The MPLS label at position 8 in the stack.
• mplsLabel9: The MPLS label at position 9 in the stack.
• mplsLabel10: The MPLS label at position 10 in the stack.
• inDstMac: The incoming destination MAC address.
• outSrcMac: The outgoing source MAC address.
• ifName: The shortened interface name.
• ifDesc: The full interface name.
• samplerName: The name of the flow sampler.
• inPermanentBytes: The running byte counter for a permanent flow.
• inPermanentPkts: The running packet counter for a permanent flow.
• fragmentOffset: The fragment-offset value from fragmented IP packets.
• forwardingStatus: The forwarding status.
• mplsPalRd: The MPLS pal route distinguisher.
• mplsPrefixLen: The number of consecutive bits in the MPLS prefix length.
• srcTrafficIndex: The BGP policy accounting source traffic index.
• dstTrafficIndex: The BGP policy accounting destination traffic index.
• applicationDescription: The application description.
• applicationTag: The application tag.
• applicationName: The name associated with a classification.
• postIpDiffServeCodePoint: The value of a differentiated services code point encoded in the differentiated services field, after modification.
• replicationFactor: The multicast replication factor.
• layer2PacketSectionOffset: The layer 2 packet section offset, potentially a generic offset.
• layer2PacketSectionSize: The layer 2 packet section size, potentially a generic size.
• layer2PacketSectionData: The layer 2 packet section data.

Option Data Records for NetFlow v9

​

Options data records report aggregate metadata about the Exporters. Like data records, they can include any or all of the previous fields. Additionally, they also have a scopes field with a value containing an array of records with a type field. The valid types are:

• system
• interface
• line-card
• cache
• template

Option data records also have a value field, which is a natural number. The JavaScript type is either a number or a string, depending on the size of the value.

Fields for NetFlow v5

​

General

​

• _time: The UNIX timestamp (in seconds) at which the message was received by Cribl Stream.
• source: A string in the form udp|<remote IP address>|<remote port>, indicating the remote sender.
• host: The hostname of the machine running Cribl Stream that ingested this event.
• inputInt: SNMP index of input interface; always set to zero.
• outputInt: SNMP index of output interface.
• protocol: IP protocol type (for example, TCP = 6; UDP = 17) of the observed network flow.
• tcpFlags: Cumulative logical OR of TCP flags in the observed network flow.
• tos: IP type of service; switch sets it to the ToS of the first packet of the flow.
• icmpType: Type of the ICMP message. Only present if the protocol is ICMP.
• icmpCode: Code of the ICMP message. Only present if the protocol is ICMP.

Because this Source reads input data directly from bytes in a compact format, there is nothing suitable to put in a _raw field, and the Source does not add a _raw field to events.

Flow Source and Destination

​

• srcAddr: Source IP address; in case of destination-only flows, set to zero.
• dstAddr: Destination IP address.
• nextHop: IP address of next hop router.
• srcPort: TCP/UDP source port number.
• dstPort: TCP/UDP destination port number. If this is an ICMP flow, this field is a combination of ICMP type and ICMP code, which are broken out separately as icmpType and icmpCode fields.
• srcMask: Source address prefix mask bits.
• dstMask: Destination address prefix mask bits.
• srcAs: Autonomous system number of the source, either origin or peer.
• dstAs: Autonomous system number of the destination, either origin or peer.

Flow Statistics

​

• packets: Packets in the flow.
• octets: Total number of Layer 3 bytes in the packets of the flow.
• startTime: System uptime, in milliseconds, at the start of the flow.
• endTime: System uptime, in milliseconds, at the time the last packet of the flow was received.
• durationMs: endTime minus startTime.

Header

​

The following are subfields within the header field:

• count: Number of flows exported in this flow frame (protocol data unit, or PDU).
• sysUptimeMs: Current time in milliseconds since the export device booted.
• unixSecs: Current seconds since 0000 UTC 1970.
• unixNsecs: Residual nanoseconds since 0000 UTC 1970.
• flowSequence: Sequence counter of total flows seen.
• engineType: Type of flow switching engine.
• engineId: ID number of the flow switching engine.
• samplingMode: The first two bits of what Cisco NetFlow documentation calls SAMPLING_INTERVAL. These bits specify a sampling mode.
• samplingInterval: The remaining 14 bits of what Cisco NetFlow documentation calls SAMPLING_INTERVAL. These bits specify a sampling interval.
• version: NetFlow export format version number.

Also, the internal fields listed below will be present.

Internal Fields

​

Cribl Stream uses a set of internal fields to assist in handling of data. These “meta” fields are not part of an event, but they are accessible, and functions can use them to make processing decisions.

Fields accessible for this Source:

• __netflowRaw : Directly routes the raw NetFlow packet data to a downstream NetFlow Destination.

Considerations for Working with NetFlow Data FlowSets

​

For both NetFlow v5 and v9, Cribl Stream:

• Can forward NetFlow packets to other NetFlow destinations. However, it cannot modify the the contents of the incoming packet. In other words, Cribl Stream forwards the packets verbatim as they came in.
• Only routes NetFlow packets from upstream exporters and cannot generate its own NetFlow packets.
• Cannot forward non-NetFlow input data to NetFlow Destinations.
• Can forward NetFlow packets to non-NetFlow Destinations, such as Splunk, Syslog, S3, and others. To send NetFlow flow records to other non-NetFlow Destinations, use the other events generated on the NetFlow & IPFIX Source that do not include the __netflowRaw field. NetFlow Destinations discard those events.

Cribl Stream emits:

• Decoded Cribl events downstream for each data record and options data record.
• When you enable pass-through mode: an undecoded Cribl event for the entire packet.

Leader and Worker Node Interactions

​

The NetFlow & IPFIX Source uses the Leader Node to keep all Worker Nodes in sync with NetFlow v9 and IPFIX template information. If the Leader is unavailable, Worker Nodes can still process data using the templates they already have. However, new or updated templates for v9 flows will only be learned by the specific Worker Node receiving that traffic. Other Worker Nodes won’t get these updates and will drop any flowsets that use those new templates.

High Availability and Disaster Recovery for NetFlow v9

​

NetFlow v9 Template Records are sent every 20 packets or every 30 minutes. Cribl Stream uses a key-value store to share these records across Worker Nodes in a Worker Group, ensuring availability for processing FlowSets.

• Template Sharing: Records are shared across Worker Nodes with a minimal delay, ensuring timely processing. The brief interval between receiving and sharing Template Records is designed to be negligible, given the low rate of Template Record changes.
• Worker Coordination: The key-value store allows uninterrupted processing during Worker Node failures.
• Disaster Recovery: Replication in the key-value store ensures Template Records are preserved, enabling seamless recovery.

UDP Tuning

​

Incoming UDP traffic is put into a buffer by the Linux kernel. Cribl will drain from that buffer as resources are available. At lower throughput levels, and with plenty of available processes, this isn’t an issue. As you scale up, however, the default size of that buffer may be too small.

You can check the current buffer size with:

$ sysctl net.core.rmem_max

A typical value of about 200 KB is far too small for an even moderately busy syslog server. You can check the health of UDP with the following command. Check the packet receive errors line.

$ netstat -su

If packet receive errors is more than zero, you have lost events, which is a particularly serious problem if the number of errors is increasing rapidly. This means you need to increase your net.core.rmem_max setting (see earlier).

You can update the live settings, but you’ll also need to change the boot-time setting so next time you reboot everything is ready to roll.

Live change, setting to 25 MB:

$ sysctl -w net.core.rmem_max=26214400
net.core.rmem_max = 26214400
$ sysctl -w net.core.rmem_default=26214400
net.core.rmem_default = 26214400

For the permanent settings change, add the following lines to /etc/sysctl.conf:

net.core.rmem_max=26214400
net.core.rmem_default=26214400

We recommend you track a few things related to UDP receiving:

• The netstat -su command, watching for errors.
• The Status tab in the UDP (Raw) Source. In particular, watch for dropped messages. They could indicate you need a bigger buffer under Advanced Settings (default: 1000 events). They could also indicate your Worker is encountering pressure further down the Pipeline.
• Especially if you increase your kernel receive buffer as above, watch your Worker processes’ memory usage.

Troubleshooting

​

The Source’s configuration modal has helpful tabs for troubleshooting:

Live Data: Try capturing live data to see real-time events as they are ingested. On the Live Data tab, click Start Capture to begin viewing real-time data.

Logs: Review and search the logs that provide detailed information about the ingestion process, including any errors or warnings that may have occurred.

You can also view the Monitoring page that provides a comprehensive overview of data volume and rate, helping you identify ingestion issues. Analyze the graphs showing events and bytes in/out over time.

Data Collisions

​

When Cribl Stream receives a NetFlow v9 template, it identifies the template using three values:

• Template ID
• Source ID, which is unique to the upstream exporting device
• IP address of the upstream exporting device

Cribl Stream uses these three values to prevent data collisions. However, data collisions may occur under these two conditions:

• Your system has a heterogeneous variety of upstream exporter devices, AND
• The Exporter IP addresses are rewritten (such as by a proxy server) before they are sent downstream to Cribl Stream.

In that situation, it is possible for two exporter devices with the same IP address to send packets simultaneously and cause a collision. The workaround is to create unique IP addresses for the exporters or use the original IP addresses.