Global settings: Difference between revisions

The Expert settings contains parameter which are often only necessary to change in rare installation scenarios or some specific need for a different operation mode.

This setting allows to configure which packet length is used for all traffic counters and incidents. Following modes are possible:

* Layer 1: Packet length is accounted on layer 1 including preamble (7 Byte), SFD (1 Byte) and inter frame gap (12 Byte)

* Layer 2 without frame check sequence (default): Packet length is accounted on layer 2 without frame check sequence (4 Byte)

* Layer 2 with frame check sequence: Account packet length on layer 2 with frame check sequence (4 Byte) When switching to another mode, it will only be applied on new packets. Older packet size statistics will not be changed.

The Allegro Network Multimeter can ignore VLAN tags for connection tracking. Enabling this option might be necessary if network traffic is seen on the Network Multimeter that contains changing VLAN tags for the same connection. For example, depending on the configuration of the mirror port to which the Network Multimeter is connected, incoming traffic could contain a VLAN tag while outgoing traffic does not. In this example, a connection would appear two times in the statistics which is often the desired behavior to be able to identify a network misconfiguration. But sometimes this behavior is intended and the user want to see only one connection. In this scenario the option can be enabled to ignore varying VLAN tags for a otherwise identical connection.

The Allegro Network Multimeter can decapsulate ERSPAN type II and type III traffic. In this mode all non-ERSPAN traffic is being discarded. On the dashboard a dropped counter will display dropped non ERSPAN packets for indication if this mode is active. The Multimeter will show the encapsulated content in all analysis modules. When capturing, packets with complete outer layer 2, layer 3, GRE and ERSPAN headers will be stored as seen on the wire.

You should only change these parameters in discussion with the Allegro Packets support.

There are several network performance settings available to improve performance on high-performance systems in case of packet drops during very high receive bandwidth. They are only visible if your Network Multimeter is capable of changing these settings.

* Max RX queues per socket: This setting specifies the amount of threads dedicated to read and write interactions with the network interface controllers. By increasing this value, network receive bandwidth can be increased before packet drops occur. By decreasing this value, data analysis will improve. The default setting of 2 RX queues is suitable for most configurations as data analysis typically needs much more processing ressources.

* Use Hyper-Threading for RX queues: This setting allows enabling or disabling Hyper-Threading for the threads dedicated to read and write interactions with the network interface controllers. By disabling it, network performance can be improved as the RX queues will be distributed to physical CPU cores only. By enabling it, RX queues will also be distributed to virtual Hyper-Threading CPU cores which is not as efficient as physical CPU cores. By using Hyper-Threading, data analysis will improve as there are more CPU cores available for these tasks. Hyper-Threading is used by default. This is suitable for most configurations as data analysis typically needs much more processing ressources.

* Preferred Network interface controller: This setting allows fine tuning of network and data analysis performance for dedicated network controllers. The selected set of network controllers will be preferred over the others. Usually the fastest or the network controller with the most traffic should be preferred. The '''Auto''' setting is used by default, preferring the fastest network controller.

You should only change these parameters in discussion with the Allegro Packets support.

The processing performance may be modified on high-performance systems. This is only visible if your Network Multimeter is capable of changing this setting.

You should only change this parameter in discussion with the Allegro Packets support.

* The long timeout controls after which maximum period of time a packet is actually written to the packet ring buffer. A lower value may decrease the time difference by which packets are stored out of their real order in the packet ring buffer but it may also increase the amount of unused overhead data in the packet ring buffer.

* The short timeout controls after which period of time smaller batches of packets are written to the packet ring buffer even if waiting for more packets would result in a more efficient operation. A lower value may decrease the time difference by which packets are stored out of their real order in the packet ring buffer but it may also decrease the performance of the packet ring buffer.

When this timeout is set to a value greater than 0, data will be removed from the system after the given number of minutes. This means that entities like IPs, which have been inactive for longer than the timeout, will be removed. History graph data for entities that are still active will be truncated to cover only the given timespan while the absolute values for the whole runtime will be retained. When a packet ring buffer is active, packets which are older than the timeout will be discarded.

If L3 tunnel mode is enabled for an interface this interface will only process packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address. All other packets received on that interface will be discarded. The system will process the packets as if only the inner encapsulated packet is seen and any traffic captures will only contain the encapsulated packet. An interface with L3 tunnel mode enabled will respond to ARP requests and to ICMP echo requests so it is possible to use ping to verify that the interface is reachable under the configured IP address. Currently only IPv4 L3 tunnels are supported. It must be noted that if the system is running in bridge packet processing mode any links with an interface configured for L3 tunnel mode will not forward traffic.

analyzing a PCAP capture file or analyzing the packet ring buffer. Depending

on the number of available CPUs this can speed up the analysis significantly.

addresses. This is fast and usually the best way for good load

If the network traffic only happens between few IP addresses, this

method can lead to load imbalance so that some threads doing much more

work while other threads may idle. In this scenario the "flow based