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.
Refer to the GCenter documentation.
topic 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.2. Prerequisites
User: setup
Commands used in this procedure:
5.5.16.3. Preliminary operations
Connect to the GCap (see Procedure for connecting to the GCap via SSH)
Stop the detection engine (see monitoring-engine)
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.
Use the
show advanced-configuration mtu
command to display the MTU value in bytes of all enabled network interfacesUse the
set advanced-configuration mtu
command to change the number of dedicated CPUs
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).
Use the x command to display the number of CPUs dedicated to the Sigflow detection engine
Use the
set advanced-configuration cpu-config
command to change the number of dedicated CPUs
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.
Use the
show advanced-configuration packet-filtering
command to display static packet filter rules.Use the
set advanced-configuration packet-filtering
command to specify static rules for filtering flows captured by the capture interfaces.
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)..
Use the
show advanced-configuration load-balancing
command to display the load balancing configuration from the monx capture interface listed to the GCap CPUs.Use the
set advanced-configuration load-balancing
command to change the load of the capture interfaces.
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.