5.5.16. Optimising performance

5.5.16.1. Introduction

Performance optimisation can be achieved in the following ways:

  • Subject 1: adapting the GCap to the network characteristics

    • Inconsistency between the MTU defined on the GCap and that of the captured frames.
      To modify the MTU see the Procedure for adjusting the size of the captured packet.

    • Check that the characteristics of the GCap, such as maximum throughput, number of sessions, etc., match those of the network to be monitored.
      For this purpose, consult the GCap datasheets.

  • Subject 2: optimising GCap resources

    • The number of CPUs allocated to the detection engine is too low. The CPUs may be overloaded and potentially packets may go unanalysed and therefore dropped.
      To change this value, see the Procedure for assigning the number of CPUs to the detection engine.

    • Prefer using a TAP aggregator as opposed to the GCap "cluster" function.
      The solution using a TAP aggregator is preferable because it requires the least amount of GCap resources for the same flow.

  • Subject 3: optimising the network flow to be analysed

    • One or more CPUs are being overloaded because there are too many packets being analysed.

      • To reduce the size of the captured network, it is possible to suppress the unnecessarily analysed flow.

      • To manage this packet filtering, see the procedure for defining flow filtering rules.

    • Only one CPU is being overloaded. In this case, the flow load is poorly distributed between the CPUs.

      • To change this, another rule can be defined or, more likely, an existing rule can be modified. A flow was defined but it was too large. It must therefore be subdivided so that each part is analysed by several CPUs.

      • To modify the rules, see the procedure for defining static packet filtering rules.

    • Change the analysed protocols.

      • To modify this list, this action must be performed on the paired GCenter.
        See the GCenter documentation for more information.

  • Subject 4: optimising the detection engine rules

    The rules define:

    • Detection rules

    • File rebuilding rules

    • Rules defining thresholds or limits under the threshold heading

      See the GCenter documentation for more information.

  • Subject 5: monitoring the solution

    A monitoring service known as Netdata, embedded in the GCenter, enables real-time information to be collected on the status of CPUs, load, disks, detection engines, and filtering.
    This feature is available at https://Nom_du_GCenter/gstats.
    On the GCap, Netdata enables more information on protocol counters, number of sessions, flows, and hash table status from 'Stats.log'.

5.5.16.3. Preliminary operations

5.5.16.4. Procedure for adjusting the captured packet size

This setting enables adjusting the size of the captured packet to match the size of those packets circulating on the network.

Danger

Load Balancing and XDP Filtering features are not supported if the MTU > 3000.

5.5.16.5. Procedure for assigning the number of CPUs to the detection engine

Astuce

Dedicate the maximum number of CPUs present to the detection engine without exceeding 80% of the CPUs.
This is done when the CPUs dedicated to the detection engine are overloaded (use the show cpus command).

5.5.16.6. Procedure for defining flow filtering rules

Astuce

The CPU(s) present are overloaded and part of the flow cannot be analysed, a number of packets are dropped:

  • To view the CPU overload, use the show cpus command

  • To view the number of dropped packets per cpux core, use the show health command, sofnet counter details- Statistics on received packets by CPU core.

Certain parts of the captured flow cannot be detected or reconstructed: for example, encrypted flows.
If nothing is done, the system will monopolise resources to achieve a result known in advance.
To avoid this, it is possible to create rules to filter the flow to be captured.

5.5.16.7. Procedure for load balancing configuration from the monx capture interface

Astuce

In this case where there is an incorrect distribution of the flow load between the CPUs, it is possible to define a rule or most certainly modify an existing rule.
A flow was defined but it was too large. It must therefore be subdivided so that each part is analysed by several CPUs using load balancing methods (algorithm)..

5.5.16.8. Procedure for optimising the detection engine rules

Astuce

The rules for the detection engine can be defined:

  • Locally on the GCap,

  • On the GCenter.

It is on these 2 applications that they must be modified to optimise them.
Moreover, if the current configuration is multi-tenant then the same rules are applied on the interfaces. This may not be optimised!

  • Use the show advanced-configuration local-rules command to display:

    • Under Rules heading: the local Sigflow rules, i.e.:

      • Detection rules

      • File rebuilding rules

    • Under the Threshold heading:

      • Thresholds or limits defined by the keyword "threshold"

      • Deletion rules defined by the keyword "suppress"

  • Use the set advanced-configuration local-rules command to modify the local rules of the GCap probe.

  • Optimise the ruleset sent from the GCenter. To do this, use the GCenter.