IBM Support

QRadar: Licenses and Flow Data FAQ

Question & Answer


I received a notification that I exceeded my flow license. How do licenses apply to flows in QRadar?


QRadar collects network activity information on how devices in your network communicate to each other. We refer to these communications as flows or flow records. Flows represent network activity by normalizing IP addresses, ports, byte and packet counts, as well as other details in to a flow. The flow represents a communication session between two hosts with each session represented in to 1 minute intervals. For sessions that span multiple intervals (minutes), QRadar reports a record at the end of each minute with the current metrics for each flow. As hosts communicate, a new flow records is generated when any new session is opened that uses a different core communication feature, such as source IP address, source port, destination IP, destination port, protocol, or application.

How are flows different from events?

A flow is different from an event because flows has a start and an end time that can span up to a minute, where an event is a record of a single activity that occurred. As multiple events occur that are the same type, the event count is increased. As multiple flows occur between two hosts, users can see multiple records (per minute) in QRadar with the same "First Packet Time" but with "Last Packet Time" values that increment through time. This is how QRadar represents ongoing communication between two hosts.

How are flows licensed in QRadar?

Flows are a record of communication between two hosts over a one minute interval. QRadar licenses flow based on flows per minute (FPM). All of the packets within a one minute interval that contains the same source IP, destination IP, source port, destination port, and protocol is combined to become one flow record. This means that if you have a license of 25,000 FPM on your appliance, that the appliance can handle 25,000 flow records per minute, which contains information such as the number of packets sent, how many bytes were transferred between the source and destination, and other data relevant to the communication.

For example, a host at opens a secure connection to a server on port 443 that lasts 5 minutes. The QFlow Collector in the network has a license of 25,000 flows per minute. The QFlow Collector sees the communication between the two servers on port 443 and combines all of the session data for each minute of the communication in to a flow record and displays the information in the Network Activity tab. This flow record counts as one flow against the 25,000 flow license limit. In a real-life scenario, there are many communications occurring across the network. Each minute, the QFlow Collector is capturing, summarizing, and rolling up communications in to unique flow records. QRadar counts the number of unique flow records and applies the number against the license for the appliance.

Figure 1: Example of how two different flow records are created in QRadar.

How does QFlow determine if a communication is continuing or has stopped?

Each line in the example image below represents one flow record as it contains information about the communication between two servers that lasted 5 minutes. As the communication reaches the one minute limit, the flow record is created and the flow is written to disk with the Last Packet Time incremented by one minute. Communications can span over multiple hours and could potentially last days, weeks, or months if uninterrupted. Communications that are in the same session together all share the same timestamp for the First Packet Time field.

If communication stops more for than one interval, the system believes that the communication between servers has stopped and writes the flow to disk. If communication starts again, then the flow record is created for the communication, but since it is a new session, then a new First Packet Time is displayed in the user interface.

Figure 2: Flow records display a first packet time to identify when communication began.

My flow licenses displays two numbers in the user interface. What does this mean?

When administrators review their licenses for appliances or virtual machine (VM), they might notice that the appliances lists capabilities as two numbers (licensed flow rate/hardware capacity).
  • The first value represents the number of flows currently licensed to the appliance.
    In the example, 10000 indicates that if an administrator exceeds 10000 flows/minute (or 166 flows/second), then a system notification will be generated by the system to alert administrators.
  • The second value represents the overall number of flows that the appliances is capable of handling.
    In the example, the appliance is licensed for 10000 flows/minute, but the license can be increased to handle 1.2 million FPM or 20,000 flows per second. As license is added to the Console appliance, any unallocated FPM can be assigned to a Flow Processor (17xx) or combination Event/Flow Processor (18xx) appliance.

Figure 3: An appliance displays a Flow Rate Limit of 10000 (licensed) /1200000 (hardware capacity) flows per minute.

Do dropped flows provide license giveback?

Yes, administrators who use Routing Rules in QRadar to drop flows get their license credited back on the next interval. License giveback allows unimportant event or flow data from your organization to be dropped, which applies a credit to the QRadar license on the next interval. Both events and flows that are dropped by a routing rule are given back to the license at a 100% rate, meaning if you drop 3,000 flows in one second, in the next interval your license is increased by 3,000 flows per second.

Administrators who have QRadar Deployment Intelligence (QDI) installed can view the flow giveback rate.

Figure 4: Example of flow license graph in the QRadar Deployment Intelligence app, filtered by License Giveback.

Figure 5: Default license rate to display flow capacity of the hardware and the licensed flow rate. As you enable routing rules for flows, graphs will begin to populate with data.

NOTE: Administrators who both forward and drop data should review their routing rules to ensure their configurations are correct. Forwarded flow data must use online forwarding mode to ensure that the data is sent from the pipeline to the external appliance. Administrators who attempt to use offline routing rules will not receive forwarded data as offline forwarding requires data to be read from disk and dropped flows are never written to disk.

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"Component":"License","Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Versions","Edition":"All Editions","Line of Business":{"code":"LOB24","label":"Security Software"}}]

Document Information

Modified date:
07 January 2021