How do Traps and Thresholds work in NFA and what are the different types of Alerts for configuration

Products

• CA Network Flow Analysis (NetQos / NFA)

Issue/Introduction

How do Traps and Thresholds work in NFA and what are the different types of Alerts which can be configured 

 

Environment

Release: RAIB1H99000-9.x/10.x

Network Flow Analysis-Interface Bundle-Hardware

Resolution

Answer: 

All traps are defined on the console, and then synced down to the harvester database into the trap_definitions table.

 

Definitions:

.TBN Files: 

The .TBN is a file type commonly referred to as the “Time Bin” file.  It is written out by the Harvester service and is consumed by the Reaper Service.  This file contains all flows, filtered down to the fields of interest that the reaper uses to process data for 1 minute and 15 minute data points.  The filename describes the time, in unixtime, for the end time of the minute which collected flows.  It’s during processing of these files that the reaper validates and sends traps.

 

Trap Types:

There are four different alert types available in the NFA system:   Flows, Utilization, Rate and Volume. 

 

"Flows" based traps:

Flows is its own use case, and it should be clear what it’s operating on, and how those metrics are working.  Any flows that don’t make it past the harvester will not be counted towards the total flow count for an interface or group of interfaces (example of this is the harvester will drop any flows that represent 0 bytes, or don’t contain the minimum required fields to process data).

The other three types all work off of similar logic, but change the requirements for how the threshold is determined. Regardless of which of these types are chosen,  the threshold will always be represented as a volume threshold on “bytes” in the trap_definitions table (columns are InThreshold and OutThreshold) for these types.

Here are some examples of how this can be calculated:

For this situation, we’ll say that we’re using Interface A which has an interface speed of 1.54Mbps

 

Utilization based traps: 

Trap when In or Out exceeds 90% utilization

             Threshold = (.9 * 1.54 * 1000 * 1000)/8  * 60 - The 1000 * 1000 is to get Mbps to bps.  8 is to get from bits to bytes. 

60 is to remove the seconds from the denominator = 10395000 bytes

 

Rate based traps: 

Trap when In or Out exceeds 1.386 Mbps

Threshold = (1.386 * 1000 * 1000)/8 * 60 = 10395000 bytes

 

Volume based traps:

These don’t require an additional calculation, they’re written as provided to the database in bytes.

 

Trap Conditions:

Traps have a number of required and optional conditions that are used to evaluate when a trap should be sent. These filters (Protocol, ToS, Time Filter, etc) are all defined when creating or editing an existing trap, and anymodifications of these conditions will “reset” the trap condition (so if it is in violation, it will be reset to be out of violation).

 

How Traps work:

   Every minute the reaper picks up a new .TBN file and processes through the data that’s contained in the file. 

 

As the reaper is processing records in this file, it uses said records to evaluate if the data meets the preconditions set in any traps, and whether or not there has been a state change (States are determined by the InViolationStartTime, OutViolationStartTime, InViolationEndTime and OutViolationEndTime). 

 

The logic can be described as such:

If we ARE NOT in violation, and we process data that that is over the threshold conditions then we will send an open

trap and set the In or Out violation start time (depending on the direction that exceed the threshold).

 

If we ARE in violation, and we process data that is below the threshold conditions, then we will send a close trap and set the In or Out violation end time (depending                on the direction that fell below the threshold).

 

NOTE: It’s important to note again that this evaluation is currently being done as it’s processing the data of each record contained in a .TBN file.  Given

that this file only contains data on flows that are actively being seen, it sets the precondition that the reaper must see data (either above or below a

threshold) to actively alert on a particular set of thresholds.  What this means is that the reaper does NOT have the ability to alert on an absence of

data (so when data falls to zero or is not included in the flows that were received on the harvester during a particular minute).

 

Timing of Traps:

While a .TBN file is written out every minute, the first two minutes it runs it only writes out one .TBN file (for the earlier minute).   This is by design, and is due to the  “duration”  field that exists in a Flow.   Since a majority of flows exist in both the current minute,  and the previous,  the harvester will always keep a .TBN file for the current and previous minutes in memory to account for that flow in both .TBNs.  This provides a more accurate representation of how the traffic smooths over in the 1 min average views.

 

A quick example of this would be:

If traffic exceeds a defined Protocol Threshold on an interface between 10:01:00 and 10:01:59,  the .TBN file which contains the data showing that

will be written out at the beginning of 10:03.  The .TBN is then processed by the reaper, and traps will be evaluated. This means that all reaper

traps will typically be just over 1 min behind the data, with any additional time past that being based on the length of time it takes for the reaper

to process the .TBN file.