Allegro Network Multimeter Manual - User contributions [en]

Settings

2025-07-28T09:17:21Z

Robert:

The Settings sub-menu allows for configuring several system parameters and for updating the system. The Allegro Network Multimeter is designed to work out-of-the-box in most installation scenarios. Therefore there are no mandatory options that must be configured before using the system.

* [[Global settings]]
* [[Module settings]]
* [[User defined names]]
* [[Management interface settings]]
* [[Multi-device settings]]
* [[Administration]]
* [[Time settings]]
* [[Filter|Ingress Filter]]
* [[Module-specific Filter]]
* [[Remote access and export]]
* [[User Management]]
* [[Firmware update]]
* [[License upload]]

Time settings

2025-07-28T09:13:34Z

Robert: Created page with "== Generic == === Time settings === The Allegro Network Multimeter can be configured to use a time synchronization service. NTP is supported for all variants of the Allegro Network Multimeter. PTP service may be used if management interface supports hardware time stamping. If a GNSS/GPS-capable extension card is available, GNSS/GPS time synchronization is available and the antenna cable delay in nanoseconds can be configured. To enable a time service, switch to the des..."

== Generic ==

=== Time settings ===
The Allegro Network Multimeter can be configured to use a time synchronization service. NTP is supported for all variants of the Allegro Network Multimeter. PTP service may be used if management interface supports hardware time stamping. If a GNSS/GPS-capable extension card is available, GNSS/GPS time synchronization is available and the antenna cable delay in nanoseconds can be configured.

To enable a time service, switch to the desired type in the dropdown box. The time service field will show whether the selected service is running or not.

'''NTP''' - For active NTP time retrieval, you can specify and edit dedicated NTP servers the Allegro Network Multimeter should communicate with. If you do not specify a NTP server, a set of predefined NTP servers will be automatically selected.

'''NTP from data plane''' - For passive time retrieval, NTP from data plane can be used to retrieve the time to be synchronized passively from NTP packets within the traffic that is analyzed. The IP address of a desired NTP server must be set. As soon as a NTP server packet is seen, the system time of the Allegro Network Multimeter will be set. The wait period field can be used to set a time period where subsequent updates are ignored. If set to 0, every time packet of that server will be used. NTP from data plane is ideal in situation where the Allegro Network Multimeter MGT interface can not or may not actively connect to the network.

'''PTP''' - For PTP time retrieval, the PTP grandmaster clock identity is shown. This is usually an EUI-64 address. The first and last set of octets of the identity represent the (EUI-48) MAC address of the grandmaster.

The following settings are possible for PTP and should match the settings of the PTP grandmaster:
*Delay mechanism: Use end-to-end (E2E), peer-to-peer (P2P) or automatic delay measurement. In case automatic measurement is selected, E2E is used at the beginning and switched to P2P when a peer delay request is received. Default is '''Auto'''.
*Network transport: Use UDPv4, UDPv6 or Layer 2 as network transport. Default is '''UDPv4'''.
*Domain number: The domain number of the grandmaster. This is used to define logical groups of synchronized clocks.
'''GNSS/GPS''' - The GNSS/GPS time synchronization option will become available when a GNSS/GPS-capable extension card is installed in the Allegro Network Multimeter.

If no time synchronization mechanism is selected the date and time of the device can be manually configured by entering a properly formatted date and time description. Below the time synchronization settings, the time zone used by the device can be configured. The drop-down list provides a list of cities grouped by world regions to select the appropriate time zone.

When a nanosecond-resolution capture card with support for '''PPS'''-synchronization is installed, the toggle ''Enable PPS synchronization'' can be used to enable this type of synchronization. It is only shown when the time service chosen is not ''GPS'' as those two modes cannot be used simultaneously. The time offset in nanoseconds is also configurable allowing to compensate for the PPS connection cable length. This feature should only be enabled when it is made sure that a proper PPS signal is provided to the network adapter. Otherwise the packet timestamps may be incorrect.

To make any of the above changes take effect, click on the Save settings button at the bottom of the page. To reload the stored settings, click on Reload settings.

==== Changes of the system time and packet timestamping ====
The packet processing uses a monotonically increasing time for software packet timestamping and statistics calculation (see ''Hardware packet timestamping'' in [[Global settings]] for information about packet timestamps on interfaces with hardware packet timestamping enabled) . If the clock for some reason jumps forward in time (e.g. changing the time synchronization method or manually changing the time) the same will happen with the statistics and the packet timestamps and there may be a gap in the statistics. If the system clock jumps backwards in time the packet processing cannot jump back. In this case a warning "problematic change of system time detected (core restart recommended)" is displayed. While the packet processing time is ahead of the system clock the packet processing time will run at a speed of 75% of real-time so that the system clock will eventually catch up. This can e.g. lead to statistics that show higher traffic bandwidth than there actually is. A restart of the packet processing is always recommended in this case.

=== Time discrepancy ===
If the clocks of the multimeter and the browser accessing the web interface are not synchronized, the displayed results may appear to be unexpected or wrong (due to the results being timestamped using the multimeter's clock, but some calculations being done in the browser using the browser's clock). The web interface can detect when these two clocks are not in sync and can generate a warning when it happens. The number of seconds the clocks need to drift apart before a warning is displayed can be configured here. The default value is 60 seconds

== Time profiles ==
Time profiles are used to configure the time frame during which certain rules (e.g. incidents, ringbuffer filters) in the multimeter should be applied. Each profile consists of a name and a set of timespans that dictate when the profile is active. Multiple timespans can be configured for each weekday.

Administration

2025-07-28T09:04:00Z

Robert: /* Time Settings */

The administration page allows the following actions:

{| class="wikitable sortable"
|-
| [[File:Administration.png|800px|none|right]]
|}

=== Power ===

Reboot or power off the Allegro Network Multimeter.

After clicking on the buttons, a confirmation dialogue will appear. Most of the time, rebooting is not necessary since it takes a significant time. If packet processing needs to be restarted because some options cannot be changed during runtime, the next option is a better choice since it minimizes downtime.

=== Processing ===

Restart the Allegro Network Multimeter processing software. This will reset all measured statistics.

Choosing this option will stop packet processing but the machine and its web interface is still available as the device itself is not rebooted. The packet processing core is restarted with the current settings and will begin processing packets after a few seconds.

=== Configuration ===

By clicking on the '''Reset System Configuration''' button a dialog is displayed that allows to reset all settings, including the network configuration, to factory defaults and the system will be restarted. As of version 3.4 the dialog allows to keep certain settings (management interface settings, users and passwords, disk and packet ring buffer cluster settings including optional random device-specific encryption keys) while setting the rest of the system configuration to defaults.

The '''Export System Configuration''' button allows you to export the entire configuration of the *Allegro Network Multimeter*. A zip compressed file can be downloaded and used for import.

The '''Import System Configuration''' button allows you to select several configuration items:

* Core settings: All settings of global settings, module settings, incident settings, user defined names, virtual link groups, ingress (NIC) filter and IP groups, excluding management interface settings, multi-device settings, and user settings. Some core settings (network interfaces, virtual link groups, incidents and time synchronization) can also be retained during import. Simply uncheck the global core setting checkbox und check the child checkboxes for settings to be imported and overwritten.
* Management interface settings: All settings of the management interface (e.g. Wi-Fi, LAN, hostname).
* Multi device settings: All settings on the configured remote devices.
* User and roles: All users and their passwords. The admin user cannot be changed and cannot be deleted by a configuration import.
* User settings: All user settings (such as search history or dashboard configuration)
It is possible to import the selected settings to all configured remote devices by selecting the last check box.

The button '''Save current system configuration on Multimeter''' will store the current configuration as a file on the device itself (in contrast to the export feature, which will download the file the user's computer).

When there are saved configuration available, any of them can be selected and load onto the system again. It is also possible to delete the configuration.

=== CORS Configuration ===
With version 4.1 the option to configure the "Cross-Origin Resource Sharing" (CORS) settings was introduced.

You can learn about CORS on the MDN Web docs[https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS].

=== Access Control ===
Since version 4.1 there is the the option to limit the access to the multimeter api, the web interface and some other services like the sftp-server to specific subnets.

If you enable the access control, you have the option to specify the subnets from which people are allowed to access the multimeter.

If you want to allow the access for the clients in the subnet in which the multimeter is deployed you are able to allow that with ticking "Allow local access".

=== TLS/SSL certificate ===

The appliance comes with a pre-installed generic TLS certificate but a custom certificate can be uploaded, generated or downloaded from a Certificate Authority via ACME.

==== Modes ====
The following modes are supported:
* '''Legacy''': The default certificates the appliance got shipped with will be used if the appliance got shipped with an older firmware than 3.6. You won't be able to switch back to this option and it will be hidden if it is not selected.
* '''ACME''': The Certificates will be downloaded from the specified Certificate Authority
* '''Upload''': You are able to upload a X.509 certificate file and a (unencrypted) key file in the .pem-file format. Upon successful upload, this certificate will be used to serve the user interface. The .pem-file should contain the full certificate chain to trust the certificate: If there is an intermediate CA, its certificate should also be in the file.
* '''Self-Signed''': Generate self-signed certificates with a custom host-name. They will be valid for 10 years and replace the legacy certificates for devices shipped with firmware version 3.6 or older.
The Default Mode is always the fall-back if the process does not work.

The '''Reset to default SSL certificate''' button will remove any user-provided SSL certificate and the user interface will be served using the default SSL certificate.

==== HSTS ====
With the version 4.2 the option to enable HTTP Strict Transport Security (HSTS) for the multimeter was added. HSTS stops users from trying to access the multimeter via unencrypted HTTP or ignoring invalid certificates for the multimeter.

If the administrator locked themselves out by enabling HSTS there are multiple options:

* If HSTS was already activated and the certificates were changed on purpose after that, they have to remove information about the site from their browser.
* If HSTS was already activated and the certificates were changed accidental, they are able to connect to the multimeter via a private window or via the ip address.

=== Certificate Authority ===

Some features also connect to external SSL services, for instance when sending email notifications via SMTP or when searching for [[Firmware update|firmware updates]]. Usually these SSL connections are verified with the built-in CA certificate pool. It is also possible to upload one or many own CA certificates which are used additionally to the system ones.

The button "Install SSL CA certificates" opens a dialoug where the file can be selected and uploaded. This file must contain certificates in the PEM format. It may contain multiple certificates.

Before version 3.6 uploading new certificates will replace the existing ones. The button "Remove SSL CA certificates" will delete the previously installed custom CA certificates so that only the system CA pool is used again for certificate verification.

With version 3.6 uploading a new certificate adds to the old one. You can delete all by pressing the "Remove all CA certificates" and also remove separate certificates.

=== Time Settings ===
The Time settings were moved to [[Time settings]].

=== Email notification ===
Certain modules support the sending of email notifications. The following settings are used to globally configure the SMTP server used and the target email address that will receive the notifications:
*Enable email notifications: globally enables or disables the sending of email notifications.
*SMTP server address: the address of the SMTP server that will be used to send notification emails.
*SMTP server port: the TCP port on which the SMTP server is listening.
*SMTP server uses SSL: must be set to On if the SMTP server expects an SSL connection from the very start. If the SMTP server uses no SSL or STARTTLS this setting must be set to Off.
*Ignore certificate errors: if the SSL certificate should not be validated because e.g. it is a self-signed certificate this setting can be used to turn off certificate validation.
*Allow unencrypted connections: if an unencrypted connection must be allowed because e.g. a legacy SMTP server does not support it this setting can be used.
*Username: the username used to log in to the SMTP server.
*Password: the password used to log in to the SMTP server.
*From email address: the email address from which incident notifications will be sent.
*Target email address: the email address to which incident notifications will be sent.
*Email links base URL: this base URL will be used to generate the HTML links in notification emails. Since the device cannot by itself determine the proper address by which it is visible to the email recipient this setting can be used to set the correct URL prefix for links sent with the notification emails.
*Send periodic system status mail: if set to hourly or daily, a periodic system status report email will be sent to the configured target address with the selected frequency. It will contain basic system information and system health status, management interface configuration and a list of detected LLDP neighbours if the management LLDP feature is enabled.
The Send test email button can be used to verify that the entered settings are working.

Global settings

2025-07-28T09:02:13Z

Robert: /* Time settings */

The Global settings section contains parameters for adjusting the behavior of the system.
The settings are split among multiple tabs, described as follows.

== Generic settings ==

=== Packet processing mode ===

This section allows for configuring the main packet processing mode:

* '''Bridge mode''': In Bridge mode A.K.A. In-Line mode, all received packets will be transmitted between corresponding port pairs (e.g. 1+2, 3+4 on Allegro 500/510) so that the Allegro Network Multimeter can be placed in-line between any network component. The device will operate transparent and will not modify network traffic in any way. The additional latency will be typically around or less than 1 millisecond. In Bridge mode it is also possible to process network traffic from a mirror port or Tap. However, "only" half of the total available ports on each respective Allegro Network Multimeter model can be used to operate in this way. For example on a 4-port Allegro model 500, you can conveniently leave the unit in bridge mode and connect up to two mirror ports on interfaces 1 and 3 respectively. Aforementioned interfaces are physically separated and not an (in-line) interface pair. Always avoid connecting mirror port traffic on an Allegro Network Multimeter interface pair (e.g. 1+2, 3+4 on Allegro 500/510), as this will result in TX traffic in the direction of a mirror port which if highly undesirable. [[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only". Packets are not forwarded and there's no bi-directional traffic on any of the monitoring ports. This operation mode allows for installation at a Mirror port of a Switch or when using a network Tap to access the network traffic. [[File:Sink mode1.jpg|800px|Allegro in Sink mode on Mirror port or Tap]]

* '''Mixed bridge/sink mode:''' This mode enables to configure the packet processing mode for each interface pair. Interface pairs default to Bridge mode but the mode can be permanently changed in the [[interface statistics]].

The packet processing mode can be changed during runtime.

Attention: Please always keep in mind, that while in bridge mode (Allegro Network Multimeter = in-line), a Link will be (shortly) interrupted when switching processing mode or/and rebooting the Allegro Network Multimeter.

=== Endpoint mode ===

If the endpoint mode is enabled for an interface, this interface will only process packets sent to the configured IP address (and potentially the port). If the system is running in bridge packet processing mode, links with an interface configured for endpoint mode will not forward traffic. The following types of traffic are supported:

* Ethernet packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address. 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.
* UDP packets to specific port (packets will be analyzed as is).

An interface with endpoint 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.

It must be noted that if the system is running in bridge packet processing mode, any links with an interface configured for endpoint mode will not forward traffic.

VLAN tag handling is not supported. The Allegro Network Multimeter will accept ARP and ICMP requests with any VLAN tags but will send replies without VLAN tagging.

Note: In versions 3.0 or older, the mode was named "l3 tunnel mode".

=== Webshark support ===

The Allegro Network Multimeter allows having a preview of packets, directly in the browser. This is the so called Webshark. To support Webshark previewing, the Allegro Network Multimeter needs to reserve an amount of system memory.

This reserved amount of memory (RAM) is configurable and will not be available for the In-Memory database, thus the history of stored statistics in the dashboard becomes a little shorter. If this is not desired, it is possible to disable the Webshark support.

Multiple parallel sessions/instances of Webshark previewing within one Allegro Network Multimeter is possible. The number of simultaneous Webshark instances and max. preview file size (e.g. 5MB) are configurable but may vary depending on Allegro model and installed RAM.

Changing Webshark parameters requires a restart of the processing.

[[File:Webshark.jpg|900px|Built in Webshark - Allegro Network Multimeter ]]

=== Snort analysis===
{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}The Allegro Network Multimeter is able to perform intrusion detection based on the [https://www.snort.org/ Snort] software project. The detection can be performed on live traffic or ring buffer traffic. This analysis is invoked via the capture dialog on any page and respects the same capture filter expressions as a normal traffic capture.
[[File:Snort Settings.png|thumb|Snort section in the global settings]]
This feature is disabled by default, to enable it navigate to Global Settings > Snort Analysis and enable it via the toggle switch. Once enabled a new setting will appear to regulate the allowed memory usage by the intrusion detection as well as the rules and configs used by Snort. The user is able to set a hard maximum limit on the usable memory, and if the Snort process exceeds this limit it will be killed by the OOM-Manager. Additionally, another soft memory limit will be installed just below the hard maximum, and if the process reaches this limit it will be throttled heavily. If your intrusion analysis appears to get stuck or is unusually slow, a good troubleshooting step is to increase the memory limit. It is generally not recommended to keep the memory limit below 200MB.

A more detailed guide on how to use the rule and config editors can be found [[Snort|here]].

===Detail of traffic analysis===

Limit module processing, allows you to configure which OSI-layers (2,3,4,7) are actively processed and analyzed by the Allegro Network Multimeter. With this setting, the performance of the Allegro Network Multimeter can be significantly improved and allows for higher throughput when disabling some analysis modules.

For both realtime and offline parallel analysis, the following modes are possible :

*Only capturing: Only interface statistics and the capture module is provided. Capture filters are supported without Layer 7 protocol specification/recognition.
*Capturing and protocol detection: Additionally Layer 7 protocol specification in Capture filters will now work.
*Up to Layer 2: Additionally all Layer 2 related modules are active such as MAC, MAC protocols, ARP and Burst Analysis.
*Up to Layer 3: Additionally all Layer 3 related modules are active such as IP and DHCP statistics.
*Up to Layer 4: Additionally all Layer 4 related modules are active such as TCP and Layer 4 server ports.
*Unlimited: All Allegro Network Multimeter modules are active.

When switching to another mode you need to restart the processing in order to activate the new settings.

NOTE: The data recorded to/stored in the Packet Ring buffer, will NOT be affected by any of the above settings. Packet ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter

====Enable single flow load balancing====
When the ''Limit module processing'' slider is turned to ''Only capturing'' the option to enable ''single flow load balancing'' appears. If this option is enabled, even a single flow is load-balanced to different analyzer threads.

This is only recommended when there are very few flows and there is an imbalance in the load of the analyzers. As the packets of a single flow are processed by different analyzers the packets of the flow may be stored out-of-order in the Packet Ring Buffer and a larger amount of memory may be required to reorder the packets when capturing from the Packet Ring Buffer (see [[Capture module#Configuration settings|Capture module]] configuration settings).

===Graph detail settings===

It is possible to modify the detail level of all graphs in the interface. This settings allow you to see a more detailed view (with higher time resolution) or to reduce the detail level so more data can be stored on the device. Changing the default values has an impact on the performance and memory usage. Changing a slider to the left increases the detail level of graphs, but increases memory usage and decreases performance.

*Best graph resolution: This option configures how detailed the graph information are shown in the best case (the latest information). The default value is one second which means that a graph sample point represents a second of packet time. You can change the resolution up to 1 millisecond which gives a detailed sub-second representation of the traffic. You can also decide to decrease the resolution which enables the Allegro Network Multimeter to store more data for a longer period of time.

*Reduce graph resolution of old data by up to: The resolution of older graph data is automatically reduced to save memory and to allow a longer view into the traffic history. This option allows you to change this behaviour. With a reduction factor of 1/1 no reduction is done at all which means the selected graph resolution is available for the complete time.
:This reduces the time period to see historical data. You can choose to increase the reduction factor to store more data for a longer period. The time printed in parentheses represents the worst-case graph resolution based on the chosen resolution and reduction factor. The reduction is done in multiple steps up to this limit. The newest data always has the highest resolution defined by the "Best graph resolution" setting above. Between 60 and 120 data points are stored at a minimum, so with default resolution of 1 second, between one and two minutes are available in the highest resolution. Due to internal compression, the exact number of data points cannot be foreseen but 60 data points are always available at least, usually much more. Once the limit is reached, data is reduced by a factor of two thus doubling the amount of time available in half resolution (2 to 4 minutes in 2 second resolution). When the next limit is reached, the data is halved again thus doubling the time again, until the configured reduction limit is reached. With default settings of one second resolution and reduction limit of 1/6, the worst resolution of 64 seconds (or 1 minute and 4 seconds) is reached not before 2 hours into the past. The drop down menu in graph view gives an exact number about the available graph resolution in the given time period.

Note: Regardless of these settings, the graph values are always converted to represent a value per second (when applicable). For example, the packets per second for an IP addresses will always be a value literally per second even if the resolution is larger or smaller than one second. The displayed value is scaled to match this view. Especially with sub-second resolution this might be misleading.

For instance, if there is a network element sending one packet per second and the resolution is set to 100 milliseconds, the value shown in the graph might be shown as 10 packets per second as each sample point is scaled to represent an value per second. For a detailed investigation it is recommended to always select a specific time interval and look at the (packet) counters shown in all statistics since these are unscaled and represent the actual values.

Performance implications: The performance degradation and memory usage depends on the actual network traffic and is not exactly predictable.

Here are some examples for reference on a Allegro 1000 series with different configuration values (under ideal test conditions):

* 1 second resolution, 1/1 reduction factor: 90% of default performance
*100 millisecond resolution, 1/1 reduction factor: 50% of default performance,
*10 millisecond resolution, 1/1 reduction factor: 15% of default performance
*1 millisecond resolution, 1/1 reduction factor: 10% of default performance

=== PCAP parallel analysis===

The PCAP parallel analysis feature allows to analyse PCAP files or the
packet ring buffer in parallel to the live measurement. The settings
allow to enable the feature and choose how much memory of the main
memory is used for parallel analysis and how many parallel slots can
be used. Detailed description of the configuration values are
described [[parallel packet processing|here]].

==IPFIX settings ==

The Allegro Network Multimeter may be running as an IPFIX exporter. These settings allows for reporting configuration. When enabled, the following settings are possible:

*IP address: Address of IPFIX collector.
*Port: Corresponding port.
*Protocol: TCP or UDP.
*Update interval: Interval in seconds for sending a status update of flows.
*UDP resend interval: Interval in seconds for resending IPFIX templates for UDP connections.
* TCP reconnect timeout: When TCP connections could not be established, wait for this time period until the next attempt to establish a connection.

Individual IPFIX messages can be enabled or disabled by toggling corresponding options. See the [[NetFlow/IPFIX interface]] documentation for details about the message types.

==Time settings==

The Time settings were moved to [[Time settings]].

== Email notification==

The Email notification settings were moved to [[Administration]].

==Long-term DB and persistence (BETA) ==
These two features allow to use a storage device as additional memory for long-term statistics of selected values, and to use a storage device to store and restore measurement data between restarts. See [[Longterm DB]] for more details.

== Expert settings==

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

===Packet length accounting===

This setting allows you to configure which packet length is used for all traffic counters and incidents. The 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 Bytes)
*Layer 2 without frame check sequence (default): Packet length is accounted on Layer 2 without a frame check sequence (4 Bytes)
*Layer 2 with frame check sequence: Account packet length on Layer 2 with frame check sequence (4 Bytes) When switching to another mode, it will only be applied on new packets. Older packet size statistics will not be changed.

===VLAN handling ===

The Allegro Network Multimeter can '''ignore VLAN tags''' for connection tracking. Enabling this option may be necessary if network traffic is seen on the Allegro Network Multimeter that contains changing VLAN tags for the same connection. For example, depending on the configuration of the Mirror Port to which the Allegro Network Multimeter is connected, incoming traffic could contain a VLAN tag while outgoing traffic does not. In this example, a connection would appear twice in the statistics which often is desired behaviour to be able to identify a network misconfiguration. In some cases however, such "duplicate" data in the dashboard may be misleading, and the user would want to see only one connection. In these scenarios the option ignore VLAN tags may be enabled.

===Tunnel view mode===

The Allegro Network Multimeter can decapsulate GRE, VXLAN, ERSPAN type II and type III, GENEVE, CAPWAP as well as L2TPv3 data traffic. Depending on this option either the outer tunnel or the inner content is shown in all analysis modules.

There are three possible modes:

* don't decapsulate traffic (default)
*decapsulate tunnel traffic, discard non-encapsulated traffic
*decapsulate tunnel traffic, process also non-encapsulated traffic

Optionally, a filter can be set to limit decapsulation on specific packets with a certain IP address, IP ranges or interfaces. If the filter is empty, all packets will be decapsulated.

In case the mode is active with discarding non-encapsulated traffic, on the Dashboard a dropped counter will display dropped non-encapsulated packets.

When capturing, packets with complete outer Layer 2, Layer 3, GRE, ERSPAN, GENEVE, CAPWAP and L2TPv3 headers will be stored as seen on the wire.

===Database mode settings===

The database mode is a special analysis mode for high-performance Allegro Network Multimeters with multiple processors to increase the performance on such systems. It is normally enabled automatically but depending on the actual network traffic and system usage, some parameter tweak might be necessary to improve overall system performance.
You should only change these parameters in discussion with the Allegro Packets support department.
These settings are only visible if your Allegro Network Multimeter is capable of running this mode.

You can read more about the meaning of the settings [[DB mode|here]].

===Network performance ===

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

*Max RX queues per socket: This setting specifies the quantity 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 since 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 since 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 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 department.

===Processing performance===

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

*Processing performance mode: This setting allows for fine tuning processing performance. By using '''Analysing''', as much processing ressources on all CPUs as possible are used for data analysis. By using '''Capturing''', the focus will be on high data throughput and low latency for capturing purposes by using only the CPU where the preferred network controller is attached to. This has an impact on data analysis performance. '''Analysing''' is used by default.
You should only change this parameter in discussion with the Allegro Packets support department.

===Packet ring buffer timeouts===

Two timeout settings related to the packet ring buffer can be adjusted.

*'''Long timeout''' controls after which maximum amount 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 order in the packet ring buffer but it may increase the amount of unused overhead data in the packet ring buffer.
*'''Short timeout''' controls after which amount 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 order in the packet ring buffer, but it may also decrease the performance of the packet ring buffer.

===Data retention timeout===

When the data retention timeout is set to a value greater than 0, data will be removed everywhere throughout 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.

===Multithreaded capture analysis ===

This option enables the use of multiple CPUs for capture analysis like when
analyzing a pcap capture file or analyzing the packet ring buffer. Depending
on the number of available CPUs this can significantly speed up the analysis.

It is possible to dedicate a number of CPUs exclusively to capture analysis.
Since these CPUs are not available for live packet processing the performance of
live traffic analysis may be lower.
When set to 0 a lower priority is used for capture analysis than for live analysis
but it cannot be ruled out that the performance of the live processing is
affected.

===Load balancing===

This option select the load distribution method. By default, network
traffic is balanced among all processing threads based on the IP
addresses. This is fast and usually the best way for efficient load
balancing.

If the network traffic only occurs between a few IP addresses, this
method can lead to a load imbalance so that some threads are doing more
work while other threads may be idle. In this scenario, "flow based
balancing" can be enabled to distribute the traffic based on the IP
and port information. This will lead to better utilization of all
processing threads.

Since this option induces additional processing overhead per packet
and additional memory for all internal IP statistics, it should only
be enabled in cases of significant load imbalance.

===Ingress packet memory===

This slider allows to configure the amount of memory which is used to buffer received packets. A larger amount of ingress packet memory may help in processing bursts of high bandwidth traffic without packet drops but it also decreases the amount of memory available for statistics. It is important to know that a restart of the processing does not suffice to make changes to this setting active. A full reboot of the device is required for that. See [[Performance Optimization Guide]].

===Jumbo frame mode===
This options allows to set how jumbo frames are handled by the system.

Three settings are available and the '''normal''' mode, which is also the default, is the mode that was used before this configuration option was introduced:

*'''Normal''': the default mode offers the best balance of full support for jumbo frames with an efficient usage of the ingress packet memory. This mode uses efficiently sized packet buffers and splits larger packets over multiple packet buffers.
*'''Large buffers''': this mode uses a single large buffer for each packet which may improve the performance but does not use the ingress packet memory as efficiently and limits the maximum jumbo frame size to 9kB.
*'''Disabled''': this mode disables support for jumbo frames and offers the best performance and efficient usage of the ingress packet memory. Jumbo frames will be discarded by the network interface.

===Hardware packet timestamping===
This option allows to enable the use of high-precision hardware packet timestamps on supported interfaces. If an interface is supported, it has the “Hardware Timestamps” feature in the interface statistics (firmware >= 4.4).

This feature will require approximately 30% more load in the I/O threads. The load increase can be reduced to about 10% by using the jumbo frame mode "Large buffers" or "Disabled".

When enabled, packets received on supported interfaces will carry a timestamp with nanosecond resolution instead of microsecond resolution.

====== Time synchronization for hardware packet timestamping ======
Except when the network interface supports GNSS/GPS time synchronization and this has been selected as type of time synchronization (see [[Administration]] time settings) the internal clock of the interface is synchronized to the main device system clock. Even when no time synchronization method is chosen ("none") the system clock is free-running and the internal clock of the interface will be regularly synced to the system clock.

The synchronization to the system time happens roughly every 5 seconds. When the interface clock deviates more than 500ms from the system clock (should only happen at startup or when there is a big jump in the system time e.g. when changing the time synchronization method) the interface time is immediately reset to the system time. If there is a smaller deviation from the system clock the frequency of the interface clock is gradually adjusted to make the clock anneal to the system time so to avoid any discontinuous jumps of the packet timestamps.

When "GNSS/GPS" time synchronization has been configured and the interface is receiving a valid GNSS/GPS time signal the interface clock is directly disciplined to the GNSS/GPS time signal and the system clock is synchronized to the GNSS/GPS time. Information of the synchronistation status is display on the System Info page. Interfaces with hardware packet timestamping but without a GNSS/GPS connection will continue to be synchronized to the system time (which is now running much closer to the global GNSS/GPS time).

===External timestamps===
When this option is enabled, the system will use timestamps contained in the packet data instead of timestamps measured at packet arrival. Currently the Arista and Ixia/Keysight as well as the SRCMAC timestamp formats are supported.

If the Ixia/Keysight or Arista type is selected, packets without an external timestamp will not be analyzed. The current number of packets that are dropped because they do not contain an external timestamp is displayed in the active interface overview table of the top-user dashboard. If there are no packets with external timestamps arriving the time of the packet processing will effectively stand still and most graphs will not make progress in live-mode.

If one of the SRCMAC options is selected, all packets will be analyzed with all-zero MAC addresses.

=== External original packet lengths ===
This option allows to enable the use of original packet length information contained in the packet data instead of the length of the packet as received. At this time only the Ixia/Keysight original packet length trailer format is supported.

This feature can also be used in combination with the ''External timestamps'' option to support packets that contain a Ixia/Keysight trailer with both timestamp and original length information.

===Memory utilization limit===
This option allows to reduce the limit until old data is removed from the in-memory database. By default the system tries to target 90% memory utilization. In some case, the load might be too high to match this limit. A smaller limit may enable the system to keep the target memory utilization and perform better in general.

Global settings

2025-07-28T08:57:29Z

Robert: /* Snort analysis */

The Global settings section contains parameters for adjusting the behavior of the system.
The settings are split among multiple tabs, described as follows.

== Generic settings ==

=== Packet processing mode ===

This section allows for configuring the main packet processing mode:

* '''Bridge mode''': In Bridge mode A.K.A. In-Line mode, all received packets will be transmitted between corresponding port pairs (e.g. 1+2, 3+4 on Allegro 500/510) so that the Allegro Network Multimeter can be placed in-line between any network component. The device will operate transparent and will not modify network traffic in any way. The additional latency will be typically around or less than 1 millisecond. In Bridge mode it is also possible to process network traffic from a mirror port or Tap. However, "only" half of the total available ports on each respective Allegro Network Multimeter model can be used to operate in this way. For example on a 4-port Allegro model 500, you can conveniently leave the unit in bridge mode and connect up to two mirror ports on interfaces 1 and 3 respectively. Aforementioned interfaces are physically separated and not an (in-line) interface pair. Always avoid connecting mirror port traffic on an Allegro Network Multimeter interface pair (e.g. 1+2, 3+4 on Allegro 500/510), as this will result in TX traffic in the direction of a mirror port which if highly undesirable. [[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only". Packets are not forwarded and there's no bi-directional traffic on any of the monitoring ports. This operation mode allows for installation at a Mirror port of a Switch or when using a network Tap to access the network traffic. [[File:Sink mode1.jpg|800px|Allegro in Sink mode on Mirror port or Tap]]

* '''Mixed bridge/sink mode:''' This mode enables to configure the packet processing mode for each interface pair. Interface pairs default to Bridge mode but the mode can be permanently changed in the [[interface statistics]].

The packet processing mode can be changed during runtime.

Attention: Please always keep in mind, that while in bridge mode (Allegro Network Multimeter = in-line), a Link will be (shortly) interrupted when switching processing mode or/and rebooting the Allegro Network Multimeter.

=== Endpoint mode ===

If the endpoint mode is enabled for an interface, this interface will only process packets sent to the configured IP address (and potentially the port). If the system is running in bridge packet processing mode, links with an interface configured for endpoint mode will not forward traffic. The following types of traffic are supported:

* Ethernet packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address. 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.
* UDP packets to specific port (packets will be analyzed as is).

An interface with endpoint 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.

It must be noted that if the system is running in bridge packet processing mode, any links with an interface configured for endpoint mode will not forward traffic.

VLAN tag handling is not supported. The Allegro Network Multimeter will accept ARP and ICMP requests with any VLAN tags but will send replies without VLAN tagging.

Note: In versions 3.0 or older, the mode was named "l3 tunnel mode".

=== Webshark support ===

The Allegro Network Multimeter allows having a preview of packets, directly in the browser. This is the so called Webshark. To support Webshark previewing, the Allegro Network Multimeter needs to reserve an amount of system memory.

This reserved amount of memory (RAM) is configurable and will not be available for the In-Memory database, thus the history of stored statistics in the dashboard becomes a little shorter. If this is not desired, it is possible to disable the Webshark support.

Multiple parallel sessions/instances of Webshark previewing within one Allegro Network Multimeter is possible. The number of simultaneous Webshark instances and max. preview file size (e.g. 5MB) are configurable but may vary depending on Allegro model and installed RAM.

Changing Webshark parameters requires a restart of the processing.

[[File:Webshark.jpg|900px|Built in Webshark - Allegro Network Multimeter ]]

=== Snort analysis===
{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}The Allegro Network Multimeter is able to perform intrusion detection based on the [https://www.snort.org/ Snort] software project. The detection can be performed on live traffic or ring buffer traffic. This analysis is invoked via the capture dialog on any page and respects the same capture filter expressions as a normal traffic capture.
[[File:Snort Settings.png|thumb|Snort section in the global settings]]
This feature is disabled by default, to enable it navigate to Global Settings > Snort Analysis and enable it via the toggle switch. Once enabled a new setting will appear to regulate the allowed memory usage by the intrusion detection as well as the rules and configs used by Snort. The user is able to set a hard maximum limit on the usable memory, and if the Snort process exceeds this limit it will be killed by the OOM-Manager. Additionally, another soft memory limit will be installed just below the hard maximum, and if the process reaches this limit it will be throttled heavily. If your intrusion analysis appears to get stuck or is unusually slow, a good troubleshooting step is to increase the memory limit. It is generally not recommended to keep the memory limit below 200MB.

A more detailed guide on how to use the rule and config editors can be found [[Snort|here]].

===Detail of traffic analysis===

Limit module processing, allows you to configure which OSI-layers (2,3,4,7) are actively processed and analyzed by the Allegro Network Multimeter. With this setting, the performance of the Allegro Network Multimeter can be significantly improved and allows for higher throughput when disabling some analysis modules.

For both realtime and offline parallel analysis, the following modes are possible :

*Only capturing: Only interface statistics and the capture module is provided. Capture filters are supported without Layer 7 protocol specification/recognition.
*Capturing and protocol detection: Additionally Layer 7 protocol specification in Capture filters will now work.
*Up to Layer 2: Additionally all Layer 2 related modules are active such as MAC, MAC protocols, ARP and Burst Analysis.
*Up to Layer 3: Additionally all Layer 3 related modules are active such as IP and DHCP statistics.
*Up to Layer 4: Additionally all Layer 4 related modules are active such as TCP and Layer 4 server ports.
*Unlimited: All Allegro Network Multimeter modules are active.

When switching to another mode you need to restart the processing in order to activate the new settings.

NOTE: The data recorded to/stored in the Packet Ring buffer, will NOT be affected by any of the above settings. Packet ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter

====Enable single flow load balancing====
When the ''Limit module processing'' slider is turned to ''Only capturing'' the option to enable ''single flow load balancing'' appears. If this option is enabled, even a single flow is load-balanced to different analyzer threads.

This is only recommended when there are very few flows and there is an imbalance in the load of the analyzers. As the packets of a single flow are processed by different analyzers the packets of the flow may be stored out-of-order in the Packet Ring Buffer and a larger amount of memory may be required to reorder the packets when capturing from the Packet Ring Buffer (see [[Capture module#Configuration settings|Capture module]] configuration settings).

===Graph detail settings===

It is possible to modify the detail level of all graphs in the interface. This settings allow you to see a more detailed view (with higher time resolution) or to reduce the detail level so more data can be stored on the device. Changing the default values has an impact on the performance and memory usage. Changing a slider to the left increases the detail level of graphs, but increases memory usage and decreases performance.

*Best graph resolution: This option configures how detailed the graph information are shown in the best case (the latest information). The default value is one second which means that a graph sample point represents a second of packet time. You can change the resolution up to 1 millisecond which gives a detailed sub-second representation of the traffic. You can also decide to decrease the resolution which enables the Allegro Network Multimeter to store more data for a longer period of time.

*Reduce graph resolution of old data by up to: The resolution of older graph data is automatically reduced to save memory and to allow a longer view into the traffic history. This option allows you to change this behaviour. With a reduction factor of 1/1 no reduction is done at all which means the selected graph resolution is available for the complete time.
:This reduces the time period to see historical data. You can choose to increase the reduction factor to store more data for a longer period. The time printed in parentheses represents the worst-case graph resolution based on the chosen resolution and reduction factor. The reduction is done in multiple steps up to this limit. The newest data always has the highest resolution defined by the "Best graph resolution" setting above. Between 60 and 120 data points are stored at a minimum, so with default resolution of 1 second, between one and two minutes are available in the highest resolution. Due to internal compression, the exact number of data points cannot be foreseen but 60 data points are always available at least, usually much more. Once the limit is reached, data is reduced by a factor of two thus doubling the amount of time available in half resolution (2 to 4 minutes in 2 second resolution). When the next limit is reached, the data is halved again thus doubling the time again, until the configured reduction limit is reached. With default settings of one second resolution and reduction limit of 1/6, the worst resolution of 64 seconds (or 1 minute and 4 seconds) is reached not before 2 hours into the past. The drop down menu in graph view gives an exact number about the available graph resolution in the given time period.

Note: Regardless of these settings, the graph values are always converted to represent a value per second (when applicable). For example, the packets per second for an IP addresses will always be a value literally per second even if the resolution is larger or smaller than one second. The displayed value is scaled to match this view. Especially with sub-second resolution this might be misleading.

For instance, if there is a network element sending one packet per second and the resolution is set to 100 milliseconds, the value shown in the graph might be shown as 10 packets per second as each sample point is scaled to represent an value per second. For a detailed investigation it is recommended to always select a specific time interval and look at the (packet) counters shown in all statistics since these are unscaled and represent the actual values.

Performance implications: The performance degradation and memory usage depends on the actual network traffic and is not exactly predictable.

Here are some examples for reference on a Allegro 1000 series with different configuration values (under ideal test conditions):

* 1 second resolution, 1/1 reduction factor: 90% of default performance
*100 millisecond resolution, 1/1 reduction factor: 50% of default performance,
*10 millisecond resolution, 1/1 reduction factor: 15% of default performance
*1 millisecond resolution, 1/1 reduction factor: 10% of default performance

=== PCAP parallel analysis===

The PCAP parallel analysis feature allows to analyse PCAP files or the
packet ring buffer in parallel to the live measurement. The settings
allow to enable the feature and choose how much memory of the main
memory is used for parallel analysis and how many parallel slots can
be used. Detailed description of the configuration values are
described [[parallel packet processing|here]].

==IPFIX settings ==

The Allegro Network Multimeter may be running as an IPFIX exporter. These settings allows for reporting configuration. When enabled, the following settings are possible:

*IP address: Address of IPFIX collector.
*Port: Corresponding port.
*Protocol: TCP or UDP.
*Update interval: Interval in seconds for sending a status update of flows.
*UDP resend interval: Interval in seconds for resending IPFIX templates for UDP connections.
* TCP reconnect timeout: When TCP connections could not be established, wait for this time period until the next attempt to establish a connection.

Individual IPFIX messages can be enabled or disabled by toggling corresponding options. See the [[NetFlow/IPFIX interface]] documentation for details about the message types.

==Time settings==

The Time settings were moved to [[Administration]].

== Email notification==

The Email notification settings were moved to [[Administration]].

==Long-term DB and persistence (BETA) ==
These two features allow to use a storage device as additional memory for long-term statistics of selected values, and to use a storage device to store and restore measurement data between restarts. See [[Longterm DB]] for more details.

== Expert settings==

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

===Packet length accounting===

This setting allows you to configure which packet length is used for all traffic counters and incidents. The 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 Bytes)
*Layer 2 without frame check sequence (default): Packet length is accounted on Layer 2 without a frame check sequence (4 Bytes)
*Layer 2 with frame check sequence: Account packet length on Layer 2 with frame check sequence (4 Bytes) When switching to another mode, it will only be applied on new packets. Older packet size statistics will not be changed.

===VLAN handling ===

The Allegro Network Multimeter can '''ignore VLAN tags''' for connection tracking. Enabling this option may be necessary if network traffic is seen on the Allegro Network Multimeter that contains changing VLAN tags for the same connection. For example, depending on the configuration of the Mirror Port to which the Allegro Network Multimeter is connected, incoming traffic could contain a VLAN tag while outgoing traffic does not. In this example, a connection would appear twice in the statistics which often is desired behaviour to be able to identify a network misconfiguration. In some cases however, such "duplicate" data in the dashboard may be misleading, and the user would want to see only one connection. In these scenarios the option ignore VLAN tags may be enabled.

===Tunnel view mode===

The Allegro Network Multimeter can decapsulate GRE, VXLAN, ERSPAN type II and type III, GENEVE, CAPWAP as well as L2TPv3 data traffic. Depending on this option either the outer tunnel or the inner content is shown in all analysis modules.

There are three possible modes:

* don't decapsulate traffic (default)
*decapsulate tunnel traffic, discard non-encapsulated traffic
*decapsulate tunnel traffic, process also non-encapsulated traffic

Optionally, a filter can be set to limit decapsulation on specific packets with a certain IP address, IP ranges or interfaces. If the filter is empty, all packets will be decapsulated.

In case the mode is active with discarding non-encapsulated traffic, on the Dashboard a dropped counter will display dropped non-encapsulated packets.

When capturing, packets with complete outer Layer 2, Layer 3, GRE, ERSPAN, GENEVE, CAPWAP and L2TPv3 headers will be stored as seen on the wire.

===Database mode settings===

The database mode is a special analysis mode for high-performance Allegro Network Multimeters with multiple processors to increase the performance on such systems. It is normally enabled automatically but depending on the actual network traffic and system usage, some parameter tweak might be necessary to improve overall system performance.
You should only change these parameters in discussion with the Allegro Packets support department.
These settings are only visible if your Allegro Network Multimeter is capable of running this mode.

You can read more about the meaning of the settings [[DB mode|here]].

===Network performance ===

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

*Max RX queues per socket: This setting specifies the quantity 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 since 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 since 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 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 department.

===Processing performance===

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

*Processing performance mode: This setting allows for fine tuning processing performance. By using '''Analysing''', as much processing ressources on all CPUs as possible are used for data analysis. By using '''Capturing''', the focus will be on high data throughput and low latency for capturing purposes by using only the CPU where the preferred network controller is attached to. This has an impact on data analysis performance. '''Analysing''' is used by default.
You should only change this parameter in discussion with the Allegro Packets support department.

===Packet ring buffer timeouts===

Two timeout settings related to the packet ring buffer can be adjusted.

*'''Long timeout''' controls after which maximum amount 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 order in the packet ring buffer but it may increase the amount of unused overhead data in the packet ring buffer.
*'''Short timeout''' controls after which amount 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 order in the packet ring buffer, but it may also decrease the performance of the packet ring buffer.

===Data retention timeout===

When the data retention timeout is set to a value greater than 0, data will be removed everywhere throughout 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.

===Multithreaded capture analysis ===

This option enables the use of multiple CPUs for capture analysis like when
analyzing a pcap capture file or analyzing the packet ring buffer. Depending
on the number of available CPUs this can significantly speed up the analysis.

It is possible to dedicate a number of CPUs exclusively to capture analysis.
Since these CPUs are not available for live packet processing the performance of
live traffic analysis may be lower.
When set to 0 a lower priority is used for capture analysis than for live analysis
but it cannot be ruled out that the performance of the live processing is
affected.

===Load balancing===

This option select the load distribution method. By default, network
traffic is balanced among all processing threads based on the IP
addresses. This is fast and usually the best way for efficient load
balancing.

If the network traffic only occurs between a few IP addresses, this
method can lead to a load imbalance so that some threads are doing more
work while other threads may be idle. In this scenario, "flow based
balancing" can be enabled to distribute the traffic based on the IP
and port information. This will lead to better utilization of all
processing threads.

Since this option induces additional processing overhead per packet
and additional memory for all internal IP statistics, it should only
be enabled in cases of significant load imbalance.

===Ingress packet memory===

This slider allows to configure the amount of memory which is used to buffer received packets. A larger amount of ingress packet memory may help in processing bursts of high bandwidth traffic without packet drops but it also decreases the amount of memory available for statistics. It is important to know that a restart of the processing does not suffice to make changes to this setting active. A full reboot of the device is required for that. See [[Performance Optimization Guide]].

===Jumbo frame mode===
This options allows to set how jumbo frames are handled by the system.

Three settings are available and the '''normal''' mode, which is also the default, is the mode that was used before this configuration option was introduced:

*'''Normal''': the default mode offers the best balance of full support for jumbo frames with an efficient usage of the ingress packet memory. This mode uses efficiently sized packet buffers and splits larger packets over multiple packet buffers.
*'''Large buffers''': this mode uses a single large buffer for each packet which may improve the performance but does not use the ingress packet memory as efficiently and limits the maximum jumbo frame size to 9kB.
*'''Disabled''': this mode disables support for jumbo frames and offers the best performance and efficient usage of the ingress packet memory. Jumbo frames will be discarded by the network interface.

===Hardware packet timestamping===
This option allows to enable the use of high-precision hardware packet timestamps on supported interfaces. If an interface is supported, it has the “Hardware Timestamps” feature in the interface statistics (firmware >= 4.4).

This feature will require approximately 30% more load in the I/O threads. The load increase can be reduced to about 10% by using the jumbo frame mode "Large buffers" or "Disabled".

When enabled, packets received on supported interfaces will carry a timestamp with nanosecond resolution instead of microsecond resolution.

====== Time synchronization for hardware packet timestamping ======
Except when the network interface supports GNSS/GPS time synchronization and this has been selected as type of time synchronization (see [[Administration]] time settings) the internal clock of the interface is synchronized to the main device system clock. Even when no time synchronization method is chosen ("none") the system clock is free-running and the internal clock of the interface will be regularly synced to the system clock.

The synchronization to the system time happens roughly every 5 seconds. When the interface clock deviates more than 500ms from the system clock (should only happen at startup or when there is a big jump in the system time e.g. when changing the time synchronization method) the interface time is immediately reset to the system time. If there is a smaller deviation from the system clock the frequency of the interface clock is gradually adjusted to make the clock anneal to the system time so to avoid any discontinuous jumps of the packet timestamps.

When "GNSS/GPS" time synchronization has been configured and the interface is receiving a valid GNSS/GPS time signal the interface clock is directly disciplined to the GNSS/GPS time signal and the system clock is synchronized to the GNSS/GPS time. Information of the synchronistation status is display on the System Info page. Interfaces with hardware packet timestamping but without a GNSS/GPS connection will continue to be synchronized to the system time (which is now running much closer to the global GNSS/GPS time).

===External timestamps===
When this option is enabled, the system will use timestamps contained in the packet data instead of timestamps measured at packet arrival. Currently the Arista and Ixia/Keysight as well as the SRCMAC timestamp formats are supported.

If the Ixia/Keysight or Arista type is selected, packets without an external timestamp will not be analyzed. The current number of packets that are dropped because they do not contain an external timestamp is displayed in the active interface overview table of the top-user dashboard. If there are no packets with external timestamps arriving the time of the packet processing will effectively stand still and most graphs will not make progress in live-mode.

If one of the SRCMAC options is selected, all packets will be analyzed with all-zero MAC addresses.

=== External original packet lengths ===
This option allows to enable the use of original packet length information contained in the packet data instead of the length of the packet as received. At this time only the Ixia/Keysight original packet length trailer format is supported.

This feature can also be used in combination with the ''External timestamps'' option to support packets that contain a Ixia/Keysight trailer with both timestamp and original length information.

===Memory utilization limit===
This option allows to reduce the limit until old data is removed from the in-memory database. By default the system tries to target 90% memory utilization. In some case, the load might be too high to match this limit. A smaller limit may enable the system to keep the target memory utilization and perform better in general.

Snort

2025-07-28T08:55:58Z

Robert: add usage info

{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}Version 4.3.0 of the Allegro Network Multimeter introduced Snort as a new capture method for network traffic. Similar to the Webshark analysis this capture mode does not produce raw packets, but instead sends them to another tool for further processing. With Snort the user is able to conveniently analyze the traffic in their network for potential attacks or intrusions, both live and retroactively.

== Configuration ==
For Snort to function properly it needs to be configured. The multimeter comes pre-equipped with the community ruleset to provide a basic set of rules to cover the most well-known and common attacks in a network. Note that currently no updates are provided for this ruleset by Allegro Packets, instead the user is expected to keep their ruleset up do date themselves.

All configurations of the Snort analysis are done via the Global Settings, under Generic Settings > Snort analysis.
[[File:Snort Settings.png|thumb|Snort section of the generic settings page]]

=== Configuring memory ===
Snort needs a certain amount of memory to be able to perform the intrusion detection and threat analysis. The more memory Snort is configured to use, the less memory will be available for the in-memory databases of the multimeter. Snort may only use half of the systems memory at max, but generally the software is able to run with less than one gigabyte of memory. A minimum of 256MB is required (and also the default) to use this feature, as lower values can cause Snort to hang up and crash. If you are experiencing similar issues, try raising the memory threshold.

Below the slider for maximum memory, a value for "Usable memory" is displayed. This value is a soft memory limit for Snort, which will cause it to be throttled when it reaches it. The usable memory is 5MB below the maximum. If Snort should reach the true maximum memory threshold it will immediately be killed by the OOM manager.

Changing this setting requires a processing restart in order to allocate the configured memory.

=== Configuring Snort ===
==== Config====
Snort can be configured via Lua scripts which are executed in a sandboxed environment at startup. The multimeter is delivered with the default configuration files of Snort, with the exception that some of the variables have been moved to a new <code>config.lua</code> file. This file is included before everything else.

To learn more about how Snort configuration works, refer to [https://docs.snort.org/start/configuration their documentation].

In order to edit this configuration the multimeter provides a web-based interface to either change the <code>config.lua</code> via a GUI, or to edit any configuration file directly. To start editing the configuration click the "Edit config" button. This opens a new modal providing the two editing modes, which can be switched via the buttons at the top center of the window.

=====Simple editor=====
This is the first editing mode, and is the one selected by default when opening the config modal. It provides a GUI which allows the user to edit the variables stored in the <code>config.lua</code>. Note that this implies that <code>config.lua</code> is a managed file, which means that directly editing this file is discouraged. As the warning in this file states, editing the values of variables will work fine, however adding new content to the file will cause it to be overridden once the simple editor is used for the next time.
[[File:Snort config simple settings.png|thumb|The Snort config's simple editor]]
The simple editor provides only a few values that can be edited. Users are encouraged to adjust these values according to their network setup. Setting the home and external network is the only strictly necessary configuration, as the other values are derived from them. The default values for these networks is "any". Refer to the Snort documentation (see above) to find out which values are allowed. Values with a dollar sign ($) in front of them are variables, e.g. setting your DNS servers to <code>$HOME_NET</code> will set the value of the DNS servers field to the value of the Home network field. This is the default.

Modifications to these values are not committed until the "Apply" button is pressed.

=====Lua editor=====
This is the "advanced" configuration mode for Snort, and is toggled by clicking the appropriate button at the center top of the modal.[[File:Snort configuration lua mode.png|thumb|The Snort config's lua editor]]
This view provides a text editor interface which allows for editing any of the Snort configuration files. The left hand side provides a file browser displaying all files in Snort's configuration folder. This does not necessarily mean that all of these files are used in the configuration. Only files included by an active configuration file are used. The analysis invokes Snort with <code>snort.lua</code> as the config file, so any other config files need to be included either by <code>snort.lua</code>, or one of its included files.

'''While the <code>config.lua</code> is displayed in this list, it is discouraged to edit it directly.'''

It is possible to create new files via the button at the bottom of the file list. Hovering over a file reveals four buttons:

* ''Rename file''
* ''Delete file''
* ''Download file''
* ''Restore file''

Changes to files (including deleting a file) are not committed until the "Apply" button is pressed. Restoring a file discards uncommitted changes. In the case of default config files (i.e. files that are shipped by default with the multimeter firmware) can also be deleted and recovered later. After deletion they will appear greyed out in the file list.

New files can be created by clicking the green "New file" button at the bottom of the file list on the left hand side of the modal. Below this button there are two more buttons that allow for file uploads and downloads. Downloading the config will zip all config files and download the archive.

==== Rules ====
[[File:Snort config rule editor.png|thumb|The Snort rule editor]]
Snort needs a set of rules in order to know what malicious network traffic looks like. The [https://docs.snort.org/rules/ Snort documentation] goes into exhaustive detail about how rules are written, and we recommend users who are interested in writing their own rules read it carefully. The multimeter comes pre-equipped with an older version of the community ruleset, which is a file containing a huge list of rules which is not up-to-date, but still provides a good starter set to detect the most common suspicious network activity. Updates to this ruleset are not provided, so users who want to use the most recent set of rules need to keep this ruleset updated themselves.

To start editing the ruleset click the "Edit rules" button. This will bring up a modal displaying a file editor which is functionally identical to the [https://allegro-packets.com/wiki/Snort#Lua_editor Lua editor] . From here it is possible to create new ruleset files as well as editing or deleting existing ones.

'''Tip: Users who want to stay up-to-date and get access to rulesets containing the most recent exploits and attack vectors may want to consider subscribing to [https://www.snort.org/products#rule_subscriptions Snort's official ruleset].'''

All files in this view are loaded by Snort, so no additional action needs to be taken to add a new file to the ruleset.

== Usage ==
[[File:Snort Analysis Results.png|thumb|Snort Analysis Results]]
Snort analysis are triggered in the capture dialog. If the feature has been enabled, the button to begin the analysis is located in the bottom right-hand corner of the modal. Should there be no button named "Snort analysis", make sure to check the global settings if the feature is enabled.

When invoking the analysis a new modal will open which displays the results of the analysis. The result modal is a list of detected incidents, sorted by order of appearance. An entry in this list has the following structure:
{| class="wikitable"
|+Snort results table structure
!Severity
! Time
!Classification
!Message
!Connection
|-
|This is denoted by the color on the left hand side of the row.
| The packet timestamp of the offending packet.
|A normalized name for the type of incident that occured.
| A more detailed description of the incident
| A diagram of the connection in which the incident occured. The IPs can be clicked to go to the IP detail page, and on the right there is an "external link" icon that opens the connection details page in a new tab.
|}Additionally, on the right hand side of the modal is another color band that serves as a rough overview over all incidents. The band is static and roughly aligned with the scroll bar to make it easier to navigate to specific severity incidents.

Snort works by reading a rule file which contains a list of rules used to match packets against. These rules can match subnet, direction, protocol, payload contents, and more (see the Snort documentation for more information on rules), and are given a classification, message and priority, which are displayed in the analysis results. Internally this feature uses a community rule set which is available for free and receives periodic updates. '''Note:''' The Allegro Network Multimeter (currently) does NOT automatically update this rule set. We are deploying the same rule set to all devices independent of the date of installation. Thus the analysis may not be able to detect zero day exploits and should not be relied on when trying to detect recently discovered attack vectors.

At the moment, only critical and severe incidents are reported (Snort priorities 0 and 1). The classification and message strings are taken directly from the rule that triggered this incidents.

Global settings

2025-07-28T08:49:49Z

Robert: /* Snort analysis */

The Global settings section contains parameters for adjusting the behavior of the system.
The settings are split among multiple tabs, described as follows.

== Generic settings ==

=== Packet processing mode ===

This section allows for configuring the main packet processing mode:

* '''Bridge mode''': In Bridge mode A.K.A. In-Line mode, all received packets will be transmitted between corresponding port pairs (e.g. 1+2, 3+4 on Allegro 500/510) so that the Allegro Network Multimeter can be placed in-line between any network component. The device will operate transparent and will not modify network traffic in any way. The additional latency will be typically around or less than 1 millisecond. In Bridge mode it is also possible to process network traffic from a mirror port or Tap. However, "only" half of the total available ports on each respective Allegro Network Multimeter model can be used to operate in this way. For example on a 4-port Allegro model 500, you can conveniently leave the unit in bridge mode and connect up to two mirror ports on interfaces 1 and 3 respectively. Aforementioned interfaces are physically separated and not an (in-line) interface pair. Always avoid connecting mirror port traffic on an Allegro Network Multimeter interface pair (e.g. 1+2, 3+4 on Allegro 500/510), as this will result in TX traffic in the direction of a mirror port which if highly undesirable. [[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only". Packets are not forwarded and there's no bi-directional traffic on any of the monitoring ports. This operation mode allows for installation at a Mirror port of a Switch or when using a network Tap to access the network traffic. [[File:Sink mode1.jpg|800px|Allegro in Sink mode on Mirror port or Tap]]

* '''Mixed bridge/sink mode:''' This mode enables to configure the packet processing mode for each interface pair. Interface pairs default to Bridge mode but the mode can be permanently changed in the [[interface statistics]].

The packet processing mode can be changed during runtime.

Attention: Please always keep in mind, that while in bridge mode (Allegro Network Multimeter = in-line), a Link will be (shortly) interrupted when switching processing mode or/and rebooting the Allegro Network Multimeter.

=== Endpoint mode ===

If the endpoint mode is enabled for an interface, this interface will only process packets sent to the configured IP address (and potentially the port). If the system is running in bridge packet processing mode, links with an interface configured for endpoint mode will not forward traffic. The following types of traffic are supported:

* Ethernet packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address. 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.
* UDP packets to specific port (packets will be analyzed as is).

An interface with endpoint 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.

It must be noted that if the system is running in bridge packet processing mode, any links with an interface configured for endpoint mode will not forward traffic.

VLAN tag handling is not supported. The Allegro Network Multimeter will accept ARP and ICMP requests with any VLAN tags but will send replies without VLAN tagging.

Note: In versions 3.0 or older, the mode was named "l3 tunnel mode".

=== Webshark support ===

The Allegro Network Multimeter allows having a preview of packets, directly in the browser. This is the so called Webshark. To support Webshark previewing, the Allegro Network Multimeter needs to reserve an amount of system memory.

This reserved amount of memory (RAM) is configurable and will not be available for the In-Memory database, thus the history of stored statistics in the dashboard becomes a little shorter. If this is not desired, it is possible to disable the Webshark support.

Multiple parallel sessions/instances of Webshark previewing within one Allegro Network Multimeter is possible. The number of simultaneous Webshark instances and max. preview file size (e.g. 5MB) are configurable but may vary depending on Allegro model and installed RAM.

Changing Webshark parameters requires a restart of the processing.

[[File:Webshark.jpg|900px|Built in Webshark - Allegro Network Multimeter ]]

=== Snort analysis===
{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}
The Allegro Network Multimeter is able to perform intrusion detection based on the [https://www.snort.org/ Snort] software project. The detection can be performed on live traffic or ring buffer traffic. This analysis is invoked via the capture dialog on any page and respects the same capture filter expressions as a normal traffic capture.
[[File:Snort Analysis Results.png|thumb|Snort Analysis Results]]
This feature is disabled by default, to enable it navigate to Global Settings > Snort Analysis and enable it via the toggle switch. Once enabled a new setting will appear to regulate the allowed memory usage by the intrusion detection as well as the rules and configs used by Snort. The user is able to set a hard maximum limit on the usable memory, and if the Snort process exceeds this limit it will be killed by the OOM-Manager. Additionally, another soft memory limit will be installed just below the hard maximum, and if the process reaches this limit it will be throttled heavily. If your intrusion analysis appears to get stuck or is unusually slow, a good troubleshooting step is to increase the memory limit. It is generally not recommended to keep the memory limit below 200MB.

A more detailed guide on how to use the rule and config editors can be found [[Snort|here]].

When invoking the analysis a new modal will open which displays the results of the analysis. The result modal is a list of detected incidents, sorted by order of appearance. An entry in this list has the following structure:
{| class="wikitable"
|+
!Severity
!Time
!Classification
!Message
!Connection
|-
|This is denoted by the color on the left hand side of the row.
|The packet timestamp of the offending packet.
|A normalized name for the type of incident that occured.
|A more detailed description of the incident
|A diagram of the connection in which the incident occured. The IPs can be clicked to go to the IP detail page, and on the right there is an "external link" icon that opens the connection details page in a new tab.
|}
Additionally, on the right hand side of the modal is another color band that serves as a rough overview over all incidents. The band is static and roughly aligned with the scroll bar to make it easier to navigate to specific severity incidents.

Snort works by reading a rule file which contains a list of rules used to match packets against. These rules can match subnet, direction, protocol, payload contents, and more (see the Snort documentation for more information on rules), and are given a classification, message and priority, which are displayed in the analysis results. Internally this feature uses a community rule set which is available for free and receives periodic updates. '''Note:''' The Allegro Network Multimeter (currently) does NOT automatically update this rule set. We are deploying the same rule set to all devices independent of the date of installation. Thus the analysis may not be able to detect zero day exploits and should not be relied on when trying to detect recently discovered attack vectors.

At the moment, only critical and severe incidents are reported (Snort priorities 0 and 1). The classification and message strings are taken directly from the rule that triggered this incidents.

===Detail of traffic analysis===

Limit module processing, allows you to configure which OSI-layers (2,3,4,7) are actively processed and analyzed by the Allegro Network Multimeter. With this setting, the performance of the Allegro Network Multimeter can be significantly improved and allows for higher throughput when disabling some analysis modules.

For both realtime and offline parallel analysis, the following modes are possible :

*Only capturing: Only interface statistics and the capture module is provided. Capture filters are supported without Layer 7 protocol specification/recognition.
*Capturing and protocol detection: Additionally Layer 7 protocol specification in Capture filters will now work.
*Up to Layer 2: Additionally all Layer 2 related modules are active such as MAC, MAC protocols, ARP and Burst Analysis.
*Up to Layer 3: Additionally all Layer 3 related modules are active such as IP and DHCP statistics.
*Up to Layer 4: Additionally all Layer 4 related modules are active such as TCP and Layer 4 server ports.
*Unlimited: All Allegro Network Multimeter modules are active.

When switching to another mode you need to restart the processing in order to activate the new settings.

NOTE: The data recorded to/stored in the Packet Ring buffer, will NOT be affected by any of the above settings. Packet ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter

====Enable single flow load balancing====
When the ''Limit module processing'' slider is turned to ''Only capturing'' the option to enable ''single flow load balancing'' appears. If this option is enabled, even a single flow is load-balanced to different analyzer threads.

This is only recommended when there are very few flows and there is an imbalance in the load of the analyzers. As the packets of a single flow are processed by different analyzers the packets of the flow may be stored out-of-order in the Packet Ring Buffer and a larger amount of memory may be required to reorder the packets when capturing from the Packet Ring Buffer (see [[Capture module#Configuration settings|Capture module]] configuration settings).

===Graph detail settings===

It is possible to modify the detail level of all graphs in the interface. This settings allow you to see a more detailed view (with higher time resolution) or to reduce the detail level so more data can be stored on the device. Changing the default values has an impact on the performance and memory usage. Changing a slider to the left increases the detail level of graphs, but increases memory usage and decreases performance.

*Best graph resolution: This option configures how detailed the graph information are shown in the best case (the latest information). The default value is one second which means that a graph sample point represents a second of packet time. You can change the resolution up to 1 millisecond which gives a detailed sub-second representation of the traffic. You can also decide to decrease the resolution which enables the Allegro Network Multimeter to store more data for a longer period of time.

*Reduce graph resolution of old data by up to: The resolution of older graph data is automatically reduced to save memory and to allow a longer view into the traffic history. This option allows you to change this behaviour. With a reduction factor of 1/1 no reduction is done at all which means the selected graph resolution is available for the complete time.
:This reduces the time period to see historical data. You can choose to increase the reduction factor to store more data for a longer period. The time printed in parentheses represents the worst-case graph resolution based on the chosen resolution and reduction factor. The reduction is done in multiple steps up to this limit. The newest data always has the highest resolution defined by the "Best graph resolution" setting above. Between 60 and 120 data points are stored at a minimum, so with default resolution of 1 second, between one and two minutes are available in the highest resolution. Due to internal compression, the exact number of data points cannot be foreseen but 60 data points are always available at least, usually much more. Once the limit is reached, data is reduced by a factor of two thus doubling the amount of time available in half resolution (2 to 4 minutes in 2 second resolution). When the next limit is reached, the data is halved again thus doubling the time again, until the configured reduction limit is reached. With default settings of one second resolution and reduction limit of 1/6, the worst resolution of 64 seconds (or 1 minute and 4 seconds) is reached not before 2 hours into the past. The drop down menu in graph view gives an exact number about the available graph resolution in the given time period.

Note: Regardless of these settings, the graph values are always converted to represent a value per second (when applicable). For example, the packets per second for an IP addresses will always be a value literally per second even if the resolution is larger or smaller than one second. The displayed value is scaled to match this view. Especially with sub-second resolution this might be misleading.

For instance, if there is a network element sending one packet per second and the resolution is set to 100 milliseconds, the value shown in the graph might be shown as 10 packets per second as each sample point is scaled to represent an value per second. For a detailed investigation it is recommended to always select a specific time interval and look at the (packet) counters shown in all statistics since these are unscaled and represent the actual values.

Performance implications: The performance degradation and memory usage depends on the actual network traffic and is not exactly predictable.

Here are some examples for reference on a Allegro 1000 series with different configuration values (under ideal test conditions):

* 1 second resolution, 1/1 reduction factor: 90% of default performance
*100 millisecond resolution, 1/1 reduction factor: 50% of default performance,
*10 millisecond resolution, 1/1 reduction factor: 15% of default performance
*1 millisecond resolution, 1/1 reduction factor: 10% of default performance

=== PCAP parallel analysis===

The PCAP parallel analysis feature allows to analyse PCAP files or the
packet ring buffer in parallel to the live measurement. The settings
allow to enable the feature and choose how much memory of the main
memory is used for parallel analysis and how many parallel slots can
be used. Detailed description of the configuration values are
described [[parallel packet processing|here]].

==IPFIX settings ==

The Allegro Network Multimeter may be running as an IPFIX exporter. These settings allows for reporting configuration. When enabled, the following settings are possible:

*IP address: Address of IPFIX collector.
*Port: Corresponding port.
*Protocol: TCP or UDP.
*Update interval: Interval in seconds for sending a status update of flows.
*UDP resend interval: Interval in seconds for resending IPFIX templates for UDP connections.
* TCP reconnect timeout: When TCP connections could not be established, wait for this time period until the next attempt to establish a connection.

Individual IPFIX messages can be enabled or disabled by toggling corresponding options. See the [[NetFlow/IPFIX interface]] documentation for details about the message types.

==Time settings==

The Time settings were moved to [[Administration]].

== Email notification==

The Email notification settings were moved to [[Administration]].

==Long-term DB and persistence (BETA) ==
These two features allow to use a storage device as additional memory for long-term statistics of selected values, and to use a storage device to store and restore measurement data between restarts. See [[Longterm DB]] for more details.

== Expert settings==

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

===Packet length accounting===

This setting allows you to configure which packet length is used for all traffic counters and incidents. The 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 Bytes)
*Layer 2 without frame check sequence (default): Packet length is accounted on Layer 2 without a frame check sequence (4 Bytes)
*Layer 2 with frame check sequence: Account packet length on Layer 2 with frame check sequence (4 Bytes) When switching to another mode, it will only be applied on new packets. Older packet size statistics will not be changed.

===VLAN handling ===

The Allegro Network Multimeter can '''ignore VLAN tags''' for connection tracking. Enabling this option may be necessary if network traffic is seen on the Allegro Network Multimeter that contains changing VLAN tags for the same connection. For example, depending on the configuration of the Mirror Port to which the Allegro Network Multimeter is connected, incoming traffic could contain a VLAN tag while outgoing traffic does not. In this example, a connection would appear twice in the statistics which often is desired behaviour to be able to identify a network misconfiguration. In some cases however, such "duplicate" data in the dashboard may be misleading, and the user would want to see only one connection. In these scenarios the option ignore VLAN tags may be enabled.

===Tunnel view mode===

The Allegro Network Multimeter can decapsulate GRE, VXLAN, ERSPAN type II and type III, GENEVE, CAPWAP as well as L2TPv3 data traffic. Depending on this option either the outer tunnel or the inner content is shown in all analysis modules.

There are three possible modes:

* don't decapsulate traffic (default)
*decapsulate tunnel traffic, discard non-encapsulated traffic
*decapsulate tunnel traffic, process also non-encapsulated traffic

Optionally, a filter can be set to limit decapsulation on specific packets with a certain IP address, IP ranges or interfaces. If the filter is empty, all packets will be decapsulated.

In case the mode is active with discarding non-encapsulated traffic, on the Dashboard a dropped counter will display dropped non-encapsulated packets.

When capturing, packets with complete outer Layer 2, Layer 3, GRE, ERSPAN, GENEVE, CAPWAP and L2TPv3 headers will be stored as seen on the wire.

===Database mode settings===

The database mode is a special analysis mode for high-performance Allegro Network Multimeters with multiple processors to increase the performance on such systems. It is normally enabled automatically but depending on the actual network traffic and system usage, some parameter tweak might be necessary to improve overall system performance.
You should only change these parameters in discussion with the Allegro Packets support department.
These settings are only visible if your Allegro Network Multimeter is capable of running this mode.

You can read more about the meaning of the settings [[DB mode|here]].

===Network performance ===

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

*Max RX queues per socket: This setting specifies the quantity 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 since 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 since 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 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 department.

===Processing performance===

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

*Processing performance mode: This setting allows for fine tuning processing performance. By using '''Analysing''', as much processing ressources on all CPUs as possible are used for data analysis. By using '''Capturing''', the focus will be on high data throughput and low latency for capturing purposes by using only the CPU where the preferred network controller is attached to. This has an impact on data analysis performance. '''Analysing''' is used by default.
You should only change this parameter in discussion with the Allegro Packets support department.

===Packet ring buffer timeouts===

Two timeout settings related to the packet ring buffer can be adjusted.

*'''Long timeout''' controls after which maximum amount 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 order in the packet ring buffer but it may increase the amount of unused overhead data in the packet ring buffer.
*'''Short timeout''' controls after which amount 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 order in the packet ring buffer, but it may also decrease the performance of the packet ring buffer.

===Data retention timeout===

When the data retention timeout is set to a value greater than 0, data will be removed everywhere throughout 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.

===Multithreaded capture analysis ===

This option enables the use of multiple CPUs for capture analysis like when
analyzing a pcap capture file or analyzing the packet ring buffer. Depending
on the number of available CPUs this can significantly speed up the analysis.

It is possible to dedicate a number of CPUs exclusively to capture analysis.
Since these CPUs are not available for live packet processing the performance of
live traffic analysis may be lower.
When set to 0 a lower priority is used for capture analysis than for live analysis
but it cannot be ruled out that the performance of the live processing is
affected.

===Load balancing===

This option select the load distribution method. By default, network
traffic is balanced among all processing threads based on the IP
addresses. This is fast and usually the best way for efficient load
balancing.

If the network traffic only occurs between a few IP addresses, this
method can lead to a load imbalance so that some threads are doing more
work while other threads may be idle. In this scenario, "flow based
balancing" can be enabled to distribute the traffic based on the IP
and port information. This will lead to better utilization of all
processing threads.

Since this option induces additional processing overhead per packet
and additional memory for all internal IP statistics, it should only
be enabled in cases of significant load imbalance.

===Ingress packet memory===

This slider allows to configure the amount of memory which is used to buffer received packets. A larger amount of ingress packet memory may help in processing bursts of high bandwidth traffic without packet drops but it also decreases the amount of memory available for statistics. It is important to know that a restart of the processing does not suffice to make changes to this setting active. A full reboot of the device is required for that. See [[Performance Optimization Guide]].

===Jumbo frame mode===
This options allows to set how jumbo frames are handled by the system.

Three settings are available and the '''normal''' mode, which is also the default, is the mode that was used before this configuration option was introduced:

*'''Normal''': the default mode offers the best balance of full support for jumbo frames with an efficient usage of the ingress packet memory. This mode uses efficiently sized packet buffers and splits larger packets over multiple packet buffers.
*'''Large buffers''': this mode uses a single large buffer for each packet which may improve the performance but does not use the ingress packet memory as efficiently and limits the maximum jumbo frame size to 9kB.
*'''Disabled''': this mode disables support for jumbo frames and offers the best performance and efficient usage of the ingress packet memory. Jumbo frames will be discarded by the network interface.

===Hardware packet timestamping===
This option allows to enable the use of high-precision hardware packet timestamps on supported interfaces. If an interface is supported, it has the “Hardware Timestamps” feature in the interface statistics (firmware >= 4.4).

This feature will require approximately 30% more load in the I/O threads. The load increase can be reduced to about 10% by using the jumbo frame mode "Large buffers" or "Disabled".

When enabled, packets received on supported interfaces will carry a timestamp with nanosecond resolution instead of microsecond resolution.

====== Time synchronization for hardware packet timestamping ======
Except when the network interface supports GNSS/GPS time synchronization and this has been selected as type of time synchronization (see [[Administration]] time settings) the internal clock of the interface is synchronized to the main device system clock. Even when no time synchronization method is chosen ("none") the system clock is free-running and the internal clock of the interface will be regularly synced to the system clock.

The synchronization to the system time happens roughly every 5 seconds. When the interface clock deviates more than 500ms from the system clock (should only happen at startup or when there is a big jump in the system time e.g. when changing the time synchronization method) the interface time is immediately reset to the system time. If there is a smaller deviation from the system clock the frequency of the interface clock is gradually adjusted to make the clock anneal to the system time so to avoid any discontinuous jumps of the packet timestamps.

When "GNSS/GPS" time synchronization has been configured and the interface is receiving a valid GNSS/GPS time signal the interface clock is directly disciplined to the GNSS/GPS time signal and the system clock is synchronized to the GNSS/GPS time. Information of the synchronistation status is display on the System Info page. Interfaces with hardware packet timestamping but without a GNSS/GPS connection will continue to be synchronized to the system time (which is now running much closer to the global GNSS/GPS time).

===External timestamps===
When this option is enabled, the system will use timestamps contained in the packet data instead of timestamps measured at packet arrival. Currently the Arista and Ixia/Keysight as well as the SRCMAC timestamp formats are supported.

If the Ixia/Keysight or Arista type is selected, packets without an external timestamp will not be analyzed. The current number of packets that are dropped because they do not contain an external timestamp is displayed in the active interface overview table of the top-user dashboard. If there are no packets with external timestamps arriving the time of the packet processing will effectively stand still and most graphs will not make progress in live-mode.

If one of the SRCMAC options is selected, all packets will be analyzed with all-zero MAC addresses.

=== External original packet lengths ===
This option allows to enable the use of original packet length information contained in the packet data instead of the length of the packet as received. At this time only the Ixia/Keysight original packet length trailer format is supported.

This feature can also be used in combination with the ''External timestamps'' option to support packets that contain a Ixia/Keysight trailer with both timestamp and original length information.

===Memory utilization limit===
This option allows to reduce the limit until old data is removed from the in-memory database. By default the system tries to target 90% memory utilization. In some case, the load might be too high to match this limit. A smaller limit may enable the system to keep the target memory utilization and perform better in general.

Global settings

2025-07-28T08:48:42Z

Robert: /* Snort analysis */

The Global settings section contains parameters for adjusting the behavior of the system.
The settings are split among multiple tabs, described as follows.

== Generic settings ==

=== Packet processing mode ===

This section allows for configuring the main packet processing mode:

* '''Bridge mode''': In Bridge mode A.K.A. In-Line mode, all received packets will be transmitted between corresponding port pairs (e.g. 1+2, 3+4 on Allegro 500/510) so that the Allegro Network Multimeter can be placed in-line between any network component. The device will operate transparent and will not modify network traffic in any way. The additional latency will be typically around or less than 1 millisecond. In Bridge mode it is also possible to process network traffic from a mirror port or Tap. However, "only" half of the total available ports on each respective Allegro Network Multimeter model can be used to operate in this way. For example on a 4-port Allegro model 500, you can conveniently leave the unit in bridge mode and connect up to two mirror ports on interfaces 1 and 3 respectively. Aforementioned interfaces are physically separated and not an (in-line) interface pair. Always avoid connecting mirror port traffic on an Allegro Network Multimeter interface pair (e.g. 1+2, 3+4 on Allegro 500/510), as this will result in TX traffic in the direction of a mirror port which if highly undesirable. [[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only". Packets are not forwarded and there's no bi-directional traffic on any of the monitoring ports. This operation mode allows for installation at a Mirror port of a Switch or when using a network Tap to access the network traffic. [[File:Sink mode1.jpg|800px|Allegro in Sink mode on Mirror port or Tap]]

* '''Mixed bridge/sink mode:''' This mode enables to configure the packet processing mode for each interface pair. Interface pairs default to Bridge mode but the mode can be permanently changed in the [[interface statistics]].

The packet processing mode can be changed during runtime.

Attention: Please always keep in mind, that while in bridge mode (Allegro Network Multimeter = in-line), a Link will be (shortly) interrupted when switching processing mode or/and rebooting the Allegro Network Multimeter.

=== Endpoint mode ===

If the endpoint mode is enabled for an interface, this interface will only process packets sent to the configured IP address (and potentially the port). If the system is running in bridge packet processing mode, links with an interface configured for endpoint mode will not forward traffic. The following types of traffic are supported:

* Ethernet packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address. 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.
* UDP packets to specific port (packets will be analyzed as is).

An interface with endpoint 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.

It must be noted that if the system is running in bridge packet processing mode, any links with an interface configured for endpoint mode will not forward traffic.

VLAN tag handling is not supported. The Allegro Network Multimeter will accept ARP and ICMP requests with any VLAN tags but will send replies without VLAN tagging.

Note: In versions 3.0 or older, the mode was named "l3 tunnel mode".

=== Webshark support ===

The Allegro Network Multimeter allows having a preview of packets, directly in the browser. This is the so called Webshark. To support Webshark previewing, the Allegro Network Multimeter needs to reserve an amount of system memory.

This reserved amount of memory (RAM) is configurable and will not be available for the In-Memory database, thus the history of stored statistics in the dashboard becomes a little shorter. If this is not desired, it is possible to disable the Webshark support.

Multiple parallel sessions/instances of Webshark previewing within one Allegro Network Multimeter is possible. The number of simultaneous Webshark instances and max. preview file size (e.g. 5MB) are configurable but may vary depending on Allegro model and installed RAM.

Changing Webshark parameters requires a restart of the processing.

[[File:Webshark.jpg|900px|Built in Webshark - Allegro Network Multimeter ]]

=== Snort analysis===
{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}
The Allegro Network Multimeter is able to perform intrusion detection based on the [https://www.snort.org/ Snort] software project. The detection can be performed on live traffic or ring buffer traffic. This analysis is invoked via the capture dialog on any page and respects the same capture filter expressions as a normal traffic capture.
[[File:Snort Analysis Results.png|thumb|Snort Analysis Results]]
This feature is disabled by default, to enable it navigate to Global Settings > Snort Analysis and enable it via the toggle switch. Once enabled a new setting will appear to regulate the allowed memory usage by the intrusion detection as well as the rules and configs used by Snort. The user is able to set a hard maximum limit on the usable memory, and if the Snort process exceeds this limit it will be killed by the OOM-Manager. Additionally, another soft memory limit will be installed just below the hard maximum, and if the process reaches this limit it will be throttled heavily. If your intrusion analysis appears to get stuck or is unusually slow, a good troubleshooting step is to increase the memory limit. It is generally not recommended to keep the memory limit below 200MB.

A more detailed guide on how to use the rule and config editors can be found [here]([[Snort|https://allegro-packets.com/wiki/Snort]]).

When invoking the analysis a new modal will open which displays the results of the analysis. The result modal is a list of detected incidents, sorted by order of appearance. An entry in this list has the following structure:
{| class="wikitable"
|+
!Severity
!Time
!Classification
!Message
!Connection
|-
|This is denoted by the color on the left hand side of the row.
|The packet timestamp of the offending packet.
|A normalized name for the type of incident that occured.
|A more detailed description of the incident
|A diagram of the connection in which the incident occured. The IPs can be clicked to go to the IP detail page, and on the right there is an "external link" icon that opens the connection details page in a new tab.
|}
Additionally, on the right hand side of the modal is another color band that serves as a rough overview over all incidents. The band is static and roughly aligned with the scroll bar to make it easier to navigate to specific severity incidents.

Snort works by reading a rule file which contains a list of rules used to match packets against. These rules can match subnet, direction, protocol, payload contents, and more (see the Snort documentation for more information on rules), and are given a classification, message and priority, which are displayed in the analysis results. Internally this feature uses a community rule set which is available for free and receives periodic updates. '''Note:''' The Allegro Network Multimeter (currently) does NOT automatically update this rule set. We are deploying the same rule set to all devices independent of the date of installation. Thus the analysis may not be able to detect zero day exploits and should not be relied on when trying to detect recently discovered attack vectors.

At the moment, only critical and severe incidents are reported (Snort priorities 0 and 1). The classification and message strings are taken directly from the rule that triggered this incidents.

===Detail of traffic analysis===

Limit module processing, allows you to configure which OSI-layers (2,3,4,7) are actively processed and analyzed by the Allegro Network Multimeter. With this setting, the performance of the Allegro Network Multimeter can be significantly improved and allows for higher throughput when disabling some analysis modules.

For both realtime and offline parallel analysis, the following modes are possible :

*Only capturing: Only interface statistics and the capture module is provided. Capture filters are supported without Layer 7 protocol specification/recognition.
*Capturing and protocol detection: Additionally Layer 7 protocol specification in Capture filters will now work.
*Up to Layer 2: Additionally all Layer 2 related modules are active such as MAC, MAC protocols, ARP and Burst Analysis.
*Up to Layer 3: Additionally all Layer 3 related modules are active such as IP and DHCP statistics.
*Up to Layer 4: Additionally all Layer 4 related modules are active such as TCP and Layer 4 server ports.
*Unlimited: All Allegro Network Multimeter modules are active.

When switching to another mode you need to restart the processing in order to activate the new settings.

NOTE: The data recorded to/stored in the Packet Ring buffer, will NOT be affected by any of the above settings. Packet ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter

====Enable single flow load balancing====
When the ''Limit module processing'' slider is turned to ''Only capturing'' the option to enable ''single flow load balancing'' appears. If this option is enabled, even a single flow is load-balanced to different analyzer threads.

This is only recommended when there are very few flows and there is an imbalance in the load of the analyzers. As the packets of a single flow are processed by different analyzers the packets of the flow may be stored out-of-order in the Packet Ring Buffer and a larger amount of memory may be required to reorder the packets when capturing from the Packet Ring Buffer (see [[Capture module#Configuration settings|Capture module]] configuration settings).

===Graph detail settings===

It is possible to modify the detail level of all graphs in the interface. This settings allow you to see a more detailed view (with higher time resolution) or to reduce the detail level so more data can be stored on the device. Changing the default values has an impact on the performance and memory usage. Changing a slider to the left increases the detail level of graphs, but increases memory usage and decreases performance.

*Best graph resolution: This option configures how detailed the graph information are shown in the best case (the latest information). The default value is one second which means that a graph sample point represents a second of packet time. You can change the resolution up to 1 millisecond which gives a detailed sub-second representation of the traffic. You can also decide to decrease the resolution which enables the Allegro Network Multimeter to store more data for a longer period of time.

*Reduce graph resolution of old data by up to: The resolution of older graph data is automatically reduced to save memory and to allow a longer view into the traffic history. This option allows you to change this behaviour. With a reduction factor of 1/1 no reduction is done at all which means the selected graph resolution is available for the complete time.
:This reduces the time period to see historical data. You can choose to increase the reduction factor to store more data for a longer period. The time printed in parentheses represents the worst-case graph resolution based on the chosen resolution and reduction factor. The reduction is done in multiple steps up to this limit. The newest data always has the highest resolution defined by the "Best graph resolution" setting above. Between 60 and 120 data points are stored at a minimum, so with default resolution of 1 second, between one and two minutes are available in the highest resolution. Due to internal compression, the exact number of data points cannot be foreseen but 60 data points are always available at least, usually much more. Once the limit is reached, data is reduced by a factor of two thus doubling the amount of time available in half resolution (2 to 4 minutes in 2 second resolution). When the next limit is reached, the data is halved again thus doubling the time again, until the configured reduction limit is reached. With default settings of one second resolution and reduction limit of 1/6, the worst resolution of 64 seconds (or 1 minute and 4 seconds) is reached not before 2 hours into the past. The drop down menu in graph view gives an exact number about the available graph resolution in the given time period.

Note: Regardless of these settings, the graph values are always converted to represent a value per second (when applicable). For example, the packets per second for an IP addresses will always be a value literally per second even if the resolution is larger or smaller than one second. The displayed value is scaled to match this view. Especially with sub-second resolution this might be misleading.

For instance, if there is a network element sending one packet per second and the resolution is set to 100 milliseconds, the value shown in the graph might be shown as 10 packets per second as each sample point is scaled to represent an value per second. For a detailed investigation it is recommended to always select a specific time interval and look at the (packet) counters shown in all statistics since these are unscaled and represent the actual values.

Performance implications: The performance degradation and memory usage depends on the actual network traffic and is not exactly predictable.

Here are some examples for reference on a Allegro 1000 series with different configuration values (under ideal test conditions):

* 1 second resolution, 1/1 reduction factor: 90% of default performance
*100 millisecond resolution, 1/1 reduction factor: 50% of default performance,
*10 millisecond resolution, 1/1 reduction factor: 15% of default performance
*1 millisecond resolution, 1/1 reduction factor: 10% of default performance

=== PCAP parallel analysis===

The PCAP parallel analysis feature allows to analyse PCAP files or the
packet ring buffer in parallel to the live measurement. The settings
allow to enable the feature and choose how much memory of the main
memory is used for parallel analysis and how many parallel slots can
be used. Detailed description of the configuration values are
described [[parallel packet processing|here]].

==IPFIX settings ==

The Allegro Network Multimeter may be running as an IPFIX exporter. These settings allows for reporting configuration. When enabled, the following settings are possible:

*IP address: Address of IPFIX collector.
*Port: Corresponding port.
*Protocol: TCP or UDP.
*Update interval: Interval in seconds for sending a status update of flows.
*UDP resend interval: Interval in seconds for resending IPFIX templates for UDP connections.
* TCP reconnect timeout: When TCP connections could not be established, wait for this time period until the next attempt to establish a connection.

Individual IPFIX messages can be enabled or disabled by toggling corresponding options. See the [[NetFlow/IPFIX interface]] documentation for details about the message types.

==Time settings==

The Time settings were moved to [[Administration]].

== Email notification==

The Email notification settings were moved to [[Administration]].

==Long-term DB and persistence (BETA) ==
These two features allow to use a storage device as additional memory for long-term statistics of selected values, and to use a storage device to store and restore measurement data between restarts. See [[Longterm DB]] for more details.

== Expert settings==

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

===Packet length accounting===

This setting allows you to configure which packet length is used for all traffic counters and incidents. The 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 Bytes)
*Layer 2 without frame check sequence (default): Packet length is accounted on Layer 2 without a frame check sequence (4 Bytes)
*Layer 2 with frame check sequence: Account packet length on Layer 2 with frame check sequence (4 Bytes) When switching to another mode, it will only be applied on new packets. Older packet size statistics will not be changed.

===VLAN handling ===

The Allegro Network Multimeter can '''ignore VLAN tags''' for connection tracking. Enabling this option may be necessary if network traffic is seen on the Allegro Network Multimeter that contains changing VLAN tags for the same connection. For example, depending on the configuration of the Mirror Port to which the Allegro Network Multimeter is connected, incoming traffic could contain a VLAN tag while outgoing traffic does not. In this example, a connection would appear twice in the statistics which often is desired behaviour to be able to identify a network misconfiguration. In some cases however, such "duplicate" data in the dashboard may be misleading, and the user would want to see only one connection. In these scenarios the option ignore VLAN tags may be enabled.

===Tunnel view mode===

The Allegro Network Multimeter can decapsulate GRE, VXLAN, ERSPAN type II and type III, GENEVE, CAPWAP as well as L2TPv3 data traffic. Depending on this option either the outer tunnel or the inner content is shown in all analysis modules.

There are three possible modes:

* don't decapsulate traffic (default)
*decapsulate tunnel traffic, discard non-encapsulated traffic
*decapsulate tunnel traffic, process also non-encapsulated traffic

Optionally, a filter can be set to limit decapsulation on specific packets with a certain IP address, IP ranges or interfaces. If the filter is empty, all packets will be decapsulated.

In case the mode is active with discarding non-encapsulated traffic, on the Dashboard a dropped counter will display dropped non-encapsulated packets.

When capturing, packets with complete outer Layer 2, Layer 3, GRE, ERSPAN, GENEVE, CAPWAP and L2TPv3 headers will be stored as seen on the wire.

===Database mode settings===

The database mode is a special analysis mode for high-performance Allegro Network Multimeters with multiple processors to increase the performance on such systems. It is normally enabled automatically but depending on the actual network traffic and system usage, some parameter tweak might be necessary to improve overall system performance.
You should only change these parameters in discussion with the Allegro Packets support department.
These settings are only visible if your Allegro Network Multimeter is capable of running this mode.

You can read more about the meaning of the settings [[DB mode|here]].

===Network performance ===

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

*Max RX queues per socket: This setting specifies the quantity 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 since 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 since 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 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 department.

===Processing performance===

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

*Processing performance mode: This setting allows for fine tuning processing performance. By using '''Analysing''', as much processing ressources on all CPUs as possible are used for data analysis. By using '''Capturing''', the focus will be on high data throughput and low latency for capturing purposes by using only the CPU where the preferred network controller is attached to. This has an impact on data analysis performance. '''Analysing''' is used by default.
You should only change this parameter in discussion with the Allegro Packets support department.

===Packet ring buffer timeouts===

Two timeout settings related to the packet ring buffer can be adjusted.

*'''Long timeout''' controls after which maximum amount 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 order in the packet ring buffer but it may increase the amount of unused overhead data in the packet ring buffer.
*'''Short timeout''' controls after which amount 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 order in the packet ring buffer, but it may also decrease the performance of the packet ring buffer.

===Data retention timeout===

When the data retention timeout is set to a value greater than 0, data will be removed everywhere throughout 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.

===Multithreaded capture analysis ===

This option enables the use of multiple CPUs for capture analysis like when
analyzing a pcap capture file or analyzing the packet ring buffer. Depending
on the number of available CPUs this can significantly speed up the analysis.

It is possible to dedicate a number of CPUs exclusively to capture analysis.
Since these CPUs are not available for live packet processing the performance of
live traffic analysis may be lower.
When set to 0 a lower priority is used for capture analysis than for live analysis
but it cannot be ruled out that the performance of the live processing is
affected.

===Load balancing===

This option select the load distribution method. By default, network
traffic is balanced among all processing threads based on the IP
addresses. This is fast and usually the best way for efficient load
balancing.

If the network traffic only occurs between a few IP addresses, this
method can lead to a load imbalance so that some threads are doing more
work while other threads may be idle. In this scenario, "flow based
balancing" can be enabled to distribute the traffic based on the IP
and port information. This will lead to better utilization of all
processing threads.

Since this option induces additional processing overhead per packet
and additional memory for all internal IP statistics, it should only
be enabled in cases of significant load imbalance.

===Ingress packet memory===

This slider allows to configure the amount of memory which is used to buffer received packets. A larger amount of ingress packet memory may help in processing bursts of high bandwidth traffic without packet drops but it also decreases the amount of memory available for statistics. It is important to know that a restart of the processing does not suffice to make changes to this setting active. A full reboot of the device is required for that. See [[Performance Optimization Guide]].

===Jumbo frame mode===
This options allows to set how jumbo frames are handled by the system.

Three settings are available and the '''normal''' mode, which is also the default, is the mode that was used before this configuration option was introduced:

*'''Normal''': the default mode offers the best balance of full support for jumbo frames with an efficient usage of the ingress packet memory. This mode uses efficiently sized packet buffers and splits larger packets over multiple packet buffers.
*'''Large buffers''': this mode uses a single large buffer for each packet which may improve the performance but does not use the ingress packet memory as efficiently and limits the maximum jumbo frame size to 9kB.
*'''Disabled''': this mode disables support for jumbo frames and offers the best performance and efficient usage of the ingress packet memory. Jumbo frames will be discarded by the network interface.

===Hardware packet timestamping===
This option allows to enable the use of high-precision hardware packet timestamps on supported interfaces. If an interface is supported, it has the “Hardware Timestamps” feature in the interface statistics (firmware >= 4.4).

This feature will require approximately 30% more load in the I/O threads. The load increase can be reduced to about 10% by using the jumbo frame mode "Large buffers" or "Disabled".

When enabled, packets received on supported interfaces will carry a timestamp with nanosecond resolution instead of microsecond resolution.

====== Time synchronization for hardware packet timestamping ======
Except when the network interface supports GNSS/GPS time synchronization and this has been selected as type of time synchronization (see [[Administration]] time settings) the internal clock of the interface is synchronized to the main device system clock. Even when no time synchronization method is chosen ("none") the system clock is free-running and the internal clock of the interface will be regularly synced to the system clock.

The synchronization to the system time happens roughly every 5 seconds. When the interface clock deviates more than 500ms from the system clock (should only happen at startup or when there is a big jump in the system time e.g. when changing the time synchronization method) the interface time is immediately reset to the system time. If there is a smaller deviation from the system clock the frequency of the interface clock is gradually adjusted to make the clock anneal to the system time so to avoid any discontinuous jumps of the packet timestamps.

When "GNSS/GPS" time synchronization has been configured and the interface is receiving a valid GNSS/GPS time signal the interface clock is directly disciplined to the GNSS/GPS time signal and the system clock is synchronized to the GNSS/GPS time. Information of the synchronistation status is display on the System Info page. Interfaces with hardware packet timestamping but without a GNSS/GPS connection will continue to be synchronized to the system time (which is now running much closer to the global GNSS/GPS time).

===External timestamps===
When this option is enabled, the system will use timestamps contained in the packet data instead of timestamps measured at packet arrival. Currently the Arista and Ixia/Keysight as well as the SRCMAC timestamp formats are supported.

If the Ixia/Keysight or Arista type is selected, packets without an external timestamp will not be analyzed. The current number of packets that are dropped because they do not contain an external timestamp is displayed in the active interface overview table of the top-user dashboard. If there are no packets with external timestamps arriving the time of the packet processing will effectively stand still and most graphs will not make progress in live-mode.

If one of the SRCMAC options is selected, all packets will be analyzed with all-zero MAC addresses.

=== External original packet lengths ===
This option allows to enable the use of original packet length information contained in the packet data instead of the length of the packet as received. At this time only the Ixia/Keysight original packet length trailer format is supported.

This feature can also be used in combination with the ''External timestamps'' option to support packets that contain a Ixia/Keysight trailer with both timestamp and original length information.

===Memory utilization limit===
This option allows to reduce the limit until old data is removed from the in-memory database. By default the system tries to target 90% memory utilization. In some case, the load might be too high to match this limit. A smaller limit may enable the system to keep the target memory utilization and perform better in general.

Snort

2025-07-28T08:46:39Z

Robert: remove in-dev warning

Snort

2025-07-08T10:44:30Z

Robert: /* Configuration */

{{Warning|title=In Development|This page documents as of yet unreleased features}}

{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}Version 4.3.0 of the Allegro Network Multimeter introduced Snort as a new capture method for network traffic. Similar to the Webshark analysis this capture mode does not produce raw packets, but instead sends them to another tool for further processing. With Snort the user is able to conveniently analyze the traffic in their network for potential attacks or intrusions, both live and retroactively.

== Configuration ==
For Snort to function properly it needs to be configured. The multimeter comes pre-equipped with the community ruleset to provide a basic set of rules to cover the most well-known and common attacks in a network. Note that currently no updates are provided for this ruleset by Allegro Packets, instead the user is expected to keep their ruleset up do date themselves.

All configurations of the Snort analysis are done via the Global Settings, under Generic Settings > Snort analysis.
[[File:Snort Settings.png|thumb|Snort section of the generic settings page]]

=== Configuring memory ===
Snort needs a certain amount of memory to be able to perform the intrusion detection and threat analysis. The more memory Snort is configured to use, the less memory will be available for the in-memory databases of the multimeter. Snort may only use half of the systems memory at max, but generally the software is able to run with less than one gigabyte of memory. A minimum of 256MB is required (and also the default) to use this feature, as lower values can cause Snort to hang up and crash. If you are experiencing similar issues, try raising the memory threshold.

Below the slider for maximum memory, a value for "Usable memory" is displayed. This value is a soft memory limit for Snort, which will cause it to be throttled when it reaches it. The usable memory is 5MB below the maximum. If Snort should reach the true maximum memory threshold it will immediately be killed by the OOM manager.

Changing this setting requires a processing restart in order to allocate the configured memory.

=== Configuring Snort ===
==== Config====
Snort can be configured via Lua scripts which are executed in a sandboxed environment at startup. The multimeter is delivered with the default configuration files of Snort, with the exception that some of the variables have been moved to a new <code>config.lua</code> file. This file is included before everything else.

To learn more about how Snort configuration works, refer to [https://docs.snort.org/start/configuration their documentation].

In order to edit this configuration the multimeter provides a web-based interface to either change the <code>config.lua</code> via a GUI, or to edit any configuration file directly. To start editing the configuration click the "Edit config" button. This opens a new modal providing the two editing modes, which can be switched via the buttons at the top center of the window.

=====Simple editor=====
This is the first editing mode, and is the one selected by default when opening the config modal. It provides a GUI which allows the user to edit the variables stored in the <code>config.lua</code>. Note that this implies that <code>config.lua</code> is a managed file, which means that directly editing this file is discouraged. As the warning in this file states, editing the values of variables will work fine, however adding new content to the file will cause it to be overridden once the simple editor is used for the next time.
[[File:Snort config simple settings.png|thumb|The Snort config's simple editor]]
The simple editor provides only a few values that can be edited. Users are encouraged to adjust these values according to their network setup. Setting the home and external network is the only strictly necessary configuration, as the other values are derived from them. The default values for these networks is "any". Refer to the Snort documentation (see above) to find out which values are allowed. Values with a dollar sign ($) in front of them are variables, e.g. setting your DNS servers to <code>$HOME_NET</code> will set the value of the DNS servers field to the value of the Home network field. This is the default.

Modifications to these values are not committed until the "Apply" button is pressed.

=====Lua editor=====
This is the "advanced" configuration mode for Snort, and is toggled by clicking the appropriate button at the center top of the modal.[[File:Snort configuration lua mode.png|thumb|The Snort config's lua editor]]
This view provides a text editor interface which allows for editing any of the Snort configuration files. The left hand side provides a file browser displaying all files in Snort's configuration folder. This does not necessarily mean that all of these files are used in the configuration. Only files included by an active configuration file are used. The analysis invokes Snort with <code>snort.lua</code> as the config file, so any other config files need to be included either by <code>snort.lua</code>, or one of its included files.

'''While the <code>config.lua</code> is displayed in this list, it is discouraged to edit it directly.'''

It is possible to create new files via the button at the bottom of the file list. Hovering over a file reveals four buttons:

* ''Rename file''
* ''Delete file''
* ''Download file''
* ''Restore file''

Changes to files (including deleting a file) are not committed until the "Apply" button is pressed. Restoring a file discards uncommitted changes. In the case of default config files (i.e. files that are shipped by default with the multimeter firmware) can also be deleted and recovered later. After deletion they will appear greyed out in the file list.

New files can be created by clicking the green "New file" button at the bottom of the file list on the left hand side of the modal. Below this button there are two more buttons that allow for file uploads and downloads. Downloading the config will zip all config files and download the archive.

==== Rules ====
[[File:Snort config rule editor.png|thumb|The Snort rule editor]]
Snort needs a set of rules in order to know what malicious network traffic looks like. The [https://docs.snort.org/rules/ Snort documentation] goes into exhaustive detail about how rules are written, and we recommend users who are interested in writing their own rules read it carefully. The multimeter comes pre-equipped with an older version of the community ruleset, which is a file containing a huge list of rules which is not up-to-date, but still provides a good starter set to detect the most common suspicious network activity. Updates to this ruleset are not provided, so users who want to use the most recent set of rules need to keep this ruleset updated themselves.

To start editing the ruleset click the "Edit rules" button. This will bring up a modal displaying a file editor which is functionally identical to the [https://allegro-packets.com/wiki/Snort#Lua_editor Lua editor] . From here it is possible to create new ruleset files as well as editing or deleting existing ones.

'''Tip: Users who want to stay up-to-date and get access to rulesets containing the most recent exploits and attack vectors may want to consider subscribing to [https://www.snort.org/products#rule_subscriptions Snort's official ruleset].'''

All files in this view are loaded by Snort, so no additional action needs to be taken to add a new file to the ruleset.

Snort

2025-07-04T06:52:56Z

Robert: /* Lua editor */

{{Warning|title=In Development|This page documents as of yet unreleased features}}

{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}Version 4.3.0 of the Allegro Network Multimeter introduced Snort as a new capture method for network traffic. Similar to the Webshark analysis this capture mode does not produce raw packets, but instead sends them to another tool for further processing. With Snort the user is able to conveniently analyze the traffic in their network for potential attacks or intrusions, both live and retroactively.

== Configuration ==
For Snort to function properly it needs to be configured. The multimeter comes pre-equipped with the community ruleset to provide a basic set of rules to cover the most well-known and common attacks in a network. Note that currently no updates are provided for this ruleset by Allegro Packets, instead the user is expected to keep their ruleset up do date themselves.

All configurations of the Snort analysis are done via the Global Settings, under Generic Settings > Snort analysis.
[[File:Snort Settings.png|thumb|Snort section of the generic settings page]]

=== Configuring memory ===
Snort needs a certain amount of memory to be able to perform the intrusion detection and threat analysis. The more memory Snort is configured to use, the less memory will be available for the in-memory databases of the multimeter. Snort may only use half of the systems memory at max, but generally the software is able to run with less than one gigabyte of memory. The default setting allocates 256MB for the Snort analysis, and generally we do not recommend going too far below this value, as too little memory can cause Snort to hang and crash during analysis. If you experience similar issue, try raising the memory threshold.

Below the slider for maximum memory, a value for "Usable memory" is displayed. This value is a soft memory limit for Snort, which will cause it to be throttled when it reaches it. The usable memory is 5MB below the maximum. If Snort should reach the true maximum memory threshold it will immediately be killed by the OOM manager.

Changing this setting requires a processing restart in order to allocate the configured memory.

=== Configuring Snort ===
==== Config====
Snort can be configured via Lua scripts which are executed in a sandboxed environment at startup. The multimeter is delivered with the default configuration files of Snort, with the exception that some of the variables have been moved to a new <code>config.lua</code> file. This file is included before everything else.

To learn more about how Snort configuration works, refer to [https://docs.snort.org/start/configuration their documentation].

In order to edit this configuration the multimeter provides a web-based interface to either change the <code>config.lua</code> via a GUI, or to edit any configuration file directly. To start editing the configuration click the "Edit config" button. This opens a new modal providing the two editing modes, which can be switched via the buttons at the top center of the window.

=====Simple editor=====
This is the first editing mode, and is the one selected by default when opening the config modal. It provides a GUI which allows the user to edit the variables stored in the <code>config.lua</code>. Note that this implies that <code>config.lua</code> is a managed file, which means that directly editing this file is discouraged. As the warning in this file states, editing the values of variables will work fine, however adding new content to the file will cause it to be overridden once the simple editor is used for the next time.
[[File:Snort config simple settings.png|thumb|The Snort config's simple editor]]
The simple editor provides only a few values that can be edited. Users are encouraged to adjust these values according to their network setup. Setting the home and external network is the only strictly necessary configuration, as the other values are derived from them. The default values for these networks is "any". Refer to the Snort documentation (see above) to find out which values are allowed. Values with a dollar sign ($) in front of them are variables, e.g. setting your DNS servers to <code>$HOME_NET</code> will set the vaule of the DNS servers field to the value of the Home network field. This is the default.

Modifications to these values are not committed until the "Apply" button is pressed.

=====Lua editor=====
This is the "advanced" configuration mode for Snort, and is toggled by clicking the appropriate button at the center top of the modal.[[File:Snort configuration lua mode.png|thumb|The Snort config's lua editor]]
This view provides a text editor interface which allows for editing any of the Snort configuration files. The left hand side provides a file browser displaying all files in Snort's configuration folder. This does not necessarily mean that all of these files are used in the configuration. Only files included by an active configuration file are used. The analysis invokes Snort with <code>snort.lua</code> as the config file, so any other config files need to be included either by <code>snort.lua</code>, or one of its included files.

'''While the <code>config.lua</code> is displayed in this list, it is discouraged to edit it directly.'''

It is possible to create new files via the button at the bottom of the file list. Hovering over a file reveals four buttons:

* ''Rename file''
* ''Delete file''
* ''Download file''
* ''Restore file''

Changes to files (including deleting a file) are not committed until the "Apply" button is pressed. Restoring a file discards uncommitted changes. In the case of default config files (i.e. files that are shipped by default with the multimeter firmware) can also be deleted and recovered later. After deletion they will appear greyed out in the file list.

New files can be created by clicking the green "New file" button at the bottom of the file list on the left hand side of the modal. Below this button there are two more buttons that allow for file uploads and downloads. Downloading the config will zip all config files and download the archive.

==== Rules ====
[[File:Snort config rule editor.png|thumb|The Snort rule editor]]
Snort needs a set of rules in order to know what malicious network traffic looks like. The [https://docs.snort.org/rules/ Snort documentation] goes into exhaustive detail about how rules are written, and we recommend users who are interested in writing their own rules read it carefully. The multimeter comes pre-equipped with an older version of the community ruleset, which is a file containing a huge list of rules which is not up-to-date, but still provides a good starter set to detect the most common suspicious network activity. Updates to this ruleset are not provided, so users who want to use the most recent set of rules need to keep this ruleset updated themselves.

To start editing the ruleset click the "Edit rules" button. This will bring up a modal displaying a file editor which is functionally identical to the [https://allegro-packets.com/wiki/Snort#Lua_editor Lua editor] . From here it is possible to create new ruleset files as well as editing or deleting existing ones.

'''Tip: Users who want to stay up-to-date and get access to rulesets containing the most recent exploits and attack vectors may want to consider subscribing to [https://www.snort.org/products#rule_subscriptions Snort's official ruleset].'''

All files in this view are loaded by Snort, so no additional action needs to be taken to add a new file to the ruleset.

File:Snort configuration lua mode.png

2025-07-04T06:50:10Z

Robert: Robert uploaded a new version of File:Snort configuration lua mode.png

The Snort configuration modal in lua mode

File:Snort config rule editor.png

2025-07-04T06:49:43Z

Robert: Robert uploaded a new version of File:Snort config rule editor.png

Editor for the snort module

File:Snort config simple settings.png

2025-07-04T06:49:28Z

Robert: Robert uploaded a new version of File:Snort config simple settings.png

This is the simple editor for modifying the Snort config

File:Snort config rule editor.png

2025-07-04T06:47:36Z

Robert: Robert uploaded a new version of File:Snort config rule editor.png

Editor for the snort module

Snort

2025-07-04T06:46:41Z

Robert:

{{Warning|title=In Development|This page documents as of yet unreleased features}}

{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}Version 4.3.0 of the Allegro Network Multimeter introduced Snort as a new capture method for network traffic. Similar to the Webshark analysis this capture mode does not produce raw packets, but instead sends them to another tool for further processing. With Snort the user is able to conveniently analyze the traffic in their network for potential attacks or intrusions, both live and retroactively.

== Configuration ==
For Snort to function properly it needs to be configured. The multimeter comes pre-equipped with the community ruleset to provide a basic set of rules to cover the most well-known and common attacks in a network. Note that currently no updates are provided for this ruleset by Allegro Packets, instead the user is expected to keep their ruleset up do date themselves.

All configurations of the Snort analysis are done via the Global Settings, under Generic Settings > Snort analysis.
[[File:Snort Settings.png|thumb|Snort section of the generic settings page]]

=== Configuring memory ===
Snort needs a certain amount of memory to be able to perform the intrusion detection and threat analysis. The more memory Snort is configured to use, the less memory will be available for the in-memory databases of the multimeter. Snort may only use half of the systems memory at max, but generally the software is able to run with less than one gigabyte of memory. The default setting allocates 256MB for the Snort analysis, and generally we do not recommend going too far below this value, as too little memory can cause Snort to hang and crash during analysis. If you experience similar issue, try raising the memory threshold.

Below the slider for maximum memory, a value for "Usable memory" is displayed. This value is a soft memory limit for Snort, which will cause it to be throttled when it reaches it. The usable memory is 5MB below the maximum. If Snort should reach the true maximum memory threshold it will immediately be killed by the OOM manager.

Changing this setting requires a processing restart in order to allocate the configured memory.

=== Configuring Snort ===
==== Config====
Snort can be configured via Lua scripts which are executed in a sandboxed environment at startup. The multimeter is delivered with the default configuration files of Snort, with the exception that some of the variables have been moved to a new <code>config.lua</code> file. This file is included before everything else.

To learn more about how Snort configuration works, refer to [https://docs.snort.org/start/configuration their documentation].

In order to edit this configuration the multimeter provides a web-based interface to either change the <code>config.lua</code> via a GUI, or to edit any configuration file directly. To start editing the configuration click the "Edit config" button. This opens a new modal providing the two editing modes, which can be switched via the buttons at the top center of the window.

=====Simple editor=====
This is the first editing mode, and is the one selected by default when opening the config modal. It provides a GUI which allows the user to edit the variables stored in the <code>config.lua</code>. Note that this implies that <code>config.lua</code> is a managed file, which means that directly editing this file is discouraged. As the warning in this file states, editing the values of variables will work fine, however adding new content to the file will cause it to be overridden once the simple editor is used for the next time.
[[File:Snort config simple settings.png|thumb|The Snort config's simple editor]]
The simple editor provides only a few values that can be edited. Users are encouraged to adjust these values according to their network setup. Setting the home and external network is the only strictly necessary configuration, as the other values are derived from them. The default values for these networks is "any". Refer to the Snort documentation (see above) to find out which values are allowed. Values with a dollar sign ($) in front of them are variables, e.g. setting your DNS servers to <code>$HOME_NET</code> will set the vaule of the DNS servers field to the value of the Home network field. This is the default.

Modifications to these values are not committed until the "Apply" button is pressed.

=====Lua editor=====
This is the "advanced" configuration mode for Snort, and is toggled by clicking the appropriate button at the center top of the modal.[[File:Snort configuration lua mode.png|thumb|The Snort config's lua editor]]
This view provides a text editor interface which allows for editing any of the Snort configuration files. The left hand side provides a file browser displaying all files in Snort's configuration folder. This does not necessarily mean that all of these files are used in the configuration. Only files included by an active configuration file are used. The analysis invokes Snort with <code>snort.lua</code> as the config file, so any other config files need to be included either by <code>snort.lua</code>, or one of its included files.

'''While the <code>config.lua</code> is displayed in this list, it is discouraged to edit it directly.'''

It is possible to create new files via the button at the bottom of the file list. Hovering over a file reveals four buttons:

* ''Rename file''
* ''Delete file''
* ''Download file''
* ''Restore file''

Changes to files (including deleting a file) are not committed until the "Apply" button is pressed. Restoring a file discards uncommitted changes. In the case of default config files (i.e. files that are shipped by default with the multimeter firmware) can also be deleted and recovered later. After deletion they will appear greyed out in the file list.

==== Rules ====
[[File:Snort config rule editor.png|thumb|The Snort rule editor]]
Snort needs a set of rules in order to know what malicious network traffic looks like. The [https://docs.snort.org/rules/ Snort documentation] goes into exhaustive detail about how rules are written, and we recommend users who are interested in writing their own rules read it carefully. The multimeter comes pre-equipped with an older version of the community ruleset, which is a file containing a huge list of rules which is not up-to-date, but still provides a good starter set to detect the most common suspicious network activity. Updates to this ruleset are not provided, so users who want to use the most recent set of rules need to keep this ruleset updated themselves.

To start editing the ruleset click the "Edit rules" button. This will bring up a modal displaying a file editor which is functionally identical to the [https://allegro-packets.com/wiki/Snort#Lua_editor Lua editor] . From here it is possible to create new ruleset files as well as editing or deleting existing ones.

'''Tip: Users who want to stay up-to-date and get access to rulesets containing the most recent exploits and attack vectors may want to consider subscribing to [https://www.snort.org/products#rule_subscriptions Snort's official ruleset].'''

All files in this view are loaded by Snort, so no additional action needs to be taken to add a new file to the ruleset.

Interface statistics

2025-03-20T09:23:21Z

Robert: /* Link state propagation */

The interface statistics page lists all network ports that are utilized by the Allegro Network Multimeter. To easily focus on the currently used network interfaces, unused interfaces can be hidden via the checkbox to show only active interfaces.

The Interface status column contains generic information about each port:

* The Interface ID is a unique number enumerated for all network ports.
* The Link pair number covers two ports linked to each other in the '''bridge mode''' or '''mixed bridge/sink mode'''.
* That is, traffic received from one port of the same link pair will be sent to the corresponding port of the same link pair, and vice verse. In '''sink mode''', the link pair number is irrelevant as no traffic is forwarded.
* If the packet processing mode '''Mixed bridge/sink mode''' has been enabled in the [[Global settings]] a drop down menu appears and the packet processing mode for the interface can be chosen. A selection here automatically affects the other interface of the link pair. Single interfaces which are not part of a link pair do not show the drop down menu as they always operate in '''Sink mode'''.
* The '''Module Info''' button opens a dialog that shows SFP-Module information like the vendor name or serial number or metrics like the signal strength or temperature, if available.
* The '''Speed setting''' offers a possibility to change the speed of the port.
* The '''Autoneg''' checkbox can be used to select if the interface uses autonegotiation or not. It may help to disable this setting if the connected device requires a fixed speed without autonegotiation.
* A selection of all possible settings is presented. The default selection is '''auto''' for the highest possible speed. This selection also has the option '''disabled''' to permanently disable the interface and bring the link down.
* The Speed indicates whether a network cable is connected and which link speed has been negotiated.
* The Duplex status shows whether the link is operated in '''full-duplex''' or '''half-duplex''' mode.
* Features are special network card hardware functions (Firmware >= 4.4)
** Bypass: Hardware bypass
** PoE: Power over Ethernet
** HWTS: Hardware Timestamps
** GNSS: Global Navigation Satellite System (GNSS) Time
* The Maximum frame size shows the largest Ethernet frame size that can be received on that interface.
* In case the Allegro Network Multimeter operates in bridge mode and two mutual interfaces do not have the same link speed and duplex, a warning will be shown below the Duplex status for both interfaces.
* The Current receive/transmit utilization summarizes the traffic received and sent by the network port.
* The value is calculated by the number of bytes received and sent in relation to full-duplex link speed.
* The '''Clock synchronization''' is shown for GNSS/GPS-capable interfaces when the GNSS/GPS time synchronization method is enabled (see [[Administration]]). It shows either GNSS/GPS or PPS depending on the clock source of the interface. If 'not locked' is displayed behind the synchronization source this means that the internal DPLL synchronization circuit is not yet fully locked onto the source clock signal. It may take several minutes after activation for the DPLL to lock onto the clock source.
* The '''Clock offset''' is shown for GNSS/GPS-capable interfaces when the GNSS/GPS time synchronization method is enabled (see [[Administration]]). It shows the time offset in nanoseconds at the last synchronization between the interface clock and the DPLL synchronization circuit driven either by GNSS/GPS or PPS.
* A PCAP buttons allows capturing all traffic for that network port.

Next to the Interface status there are three graphs for the number of processed packets, the number of processed bytes, and possible error counters.

Both packets and bytes statistics show past values in the graph and the current total values and the current rate during the last second, separately for receiving ('''yellow''' down arrow) and sending side ('''blue''' up arrow).

The error values list all possible packet processing errors. Depending on the network interface card´s capabilities, slightly different counters are shown.

'''RX errors apply to ''received'' packets. Following errors are counted:'''
* Malformed packets: The packet was corrupt. This is a general receive error counter and more detailed counters will be reported below.
* Hardware miss: The packet couldn't be received by the network interface card.
* Out of packet buffer: There have been problems with allocating memory for the packet.
* Undersized: The packet was shorter than the minimum size of 64 Bytes and had a valid CRC.
* Oversized: The packet exceeded the defined MTU.
* Under or oversized: The packet was either too small or it exceeded MTU.
* Bad CRC: Frame check sequence of layer 2 was broken.
* Bad fragmentation: The packet was shorter than the minimum size of 64 Bytes and had a bad CRC.
* Jabber: The packet was longer than the MTU and had a bad CRC.

'''TX errors indicates errors when ''sending'' to the wire fails for some reason.'''
* Unable to forward: This is a generic error counter.
* Dropped due to missing capacity: The packet could not be sent as the link capacity was too small.

Not processed packets were dropped due to overloaded software send queues.
{| class="wikitable"
|-
|[[File:Interface statistics.png|1000 px|none]]
|}

=== L3 tunnel stats ===

If the Endpoint mode (see [[Global settings]]) has been activated for an interface or the Tunnel View Mode is used this tab will show a list of the L3 tunnels processed by the system. It shows the source IP address along with the target IP address (see [[Common table columns#IP|Common table columns - IP]]) and provides statistics about the amount of traffic transmitted through the tunnel. In case of ERSPAN tunnels the ERSPAN session ID will also be used to differentiate between tunnels in addition to the IP addresses.

=== Link state propagation ===
Since bridged interfaces are implemented as a software bridge, any link changes behind the Multimeter are effectively masked by the bridge. Propagation of the link state through the bridged interfaces can be enabled via the checkbox labeled "Link state propagation" located in the interface status box. This means, if the device connected to one side of the bridge goes down, this change in link state will be reflected on the other side of the bridge, allowing monitoring devices to see the status of devices behind the Multimeter.

=== WiFi interfaces ===
If WiFi monitoring interfaces are active a tab named ''WiFi interfaces'' is available. This displays statistics for each active WiFi monitoring interface similar to the statistics on the ''Interfaces'' tab.

Snort

2025-03-18T10:18:25Z

Robert:

{{Warning|title=In Development|This page documents as of yet unreleased features}}

{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}Version 4.3.0 of the Allegro Network Multimeter introduced Snort as a new capture method for network traffic. Similar to the Webshark analysis this capture mode does not produce raw packets, but instead sends them to another tool for further processing. With Snort the user is able to conveniently analyze the traffic in their network for potential attacks or intrusions, both live and retroactively.

== Configuration ==
For Snort to function properly it needs to be configured. The multimeter comes pre-equipped with the community ruleset to provide a basic set of rules to cover the most well-known and common attacks in a network. Note that currently no updates are provided for this ruleset by Allegro Packets, instead the user is expected to keep their ruleset up do date themselves.

All configurations of the Snort analysis are done via the Global Settings, under Generic Settings > Snort analysis.
[[File:Snort Settings.png|thumb|Snort section of the generic settings page]]

=== Configuring memory ===
Snort needs a certain amount of memory to be able to perform the intrusion detection and threat analysis. The more memory Snort is configured to use, the less memory will be available for the in-memory databases of the multimeter. Snort may only use half of the systems memory at max, but generally the software is able to run with less than one gigabyte of memory. The default setting allocates 256MB for the Snort analysis, and generally we do not recommend going too far below this value, as too little memory can cause Snort to hang and crash during analysis. If you experience similar issue, try raising the memory threshold.

Below the slider for maximum memory, a value for "Usable memory" is displayed. This value is a soft memory limit for Snort, which will cause it to be throttled when it reaches it. The usable memory is 5MB below the maximum. If Snort should reach the true maximum memory threshold it will immediately be killed by the OOM manager.

Changing this setting requires a processing restart in order to allocate the configured memory.

=== Configuring Snort ===
{{Warning|title=Beta Feature|Currently there is no proper way to inspect Snort's error output, so invalid configs may result in the Snort analysis seemingly crashing for no reason. At the moment we recommend testing the validity of the configuration with a local Snort installation.}}
==== Config====
Snort can be configured via Lua scripts which are executed in a sandboxed environment at startup. The multimeter is delivered with the default configuration files of Snort, with the exception that some of the variables have been moved to a new <code>config.lua</code> file. This file is included before everything else.

To learn more about how Snort configuration works, refer to [https://docs.snort.org/start/configuration their documentation].

In order to edit this configuration the multimeter provides a web-based interface to either change the <code>config.lua</code> via a GUI, or to edit any configuration file directly. To start editing the configuration click the "Edit config" button. This opens a new modal providing the two editing modes, which can be switched via the buttons at the top center of the window.

=====Simple editor=====
This is the first editing mode, and is the one selected by default when opening the config modal. It provides a GUI which allows the user to edit the variables stored in the <code>config.lua</code>. Note that this implies that <code>config.lua</code> is a managed file, which means that directly editing this file is discouraged. As the warning in this file states, editing the values of variables will work fine, however adding new content to the file will cause it to be overridden once the simple editor is used for the next time.
[[File:Snort config simple settings.png|thumb|The Snort config's simple editor]]
The simple editor provides only a few values that can be edited. Users are encouraged to adjust these values according to their network setup. Setting the home and external network is the only strictly necessary configuration, as the other values are derived from them. The default values for these networks is "any". Refer to the Snort documentation (see above) to find out which values are allowed. Values with a dollar sign ($) in front of them are variables, e.g. setting your DNS servers to <code>$HOME_NET</code> will set the vaule of the DNS servers field to the value of the Home network field. This is the default.

Modifications to these values are not committed until either the "Apply" or "Save" button are pressed. Saving the settings will close the modal, while applying them will commit the changes but keep the modal open. Cancelling will cause all unsaved changes to be discarded (a warning modal will ask for confirmation before discarding).

=====Lua editor=====
This is the "advanced" configuration mode for Snort, and is toggled by clicking the appropriate button at the center top of the modal.[[File:Snort configuration lua mode.png|thumb|The Snort config's lua editor]]
This view provides a text editor interface which allows for editing any of the Snort configuration files. The left hand side provides a file browser displaying all files in Snort's configuration folder. This does not necessarily mean that all of these files are used in the configuration. Only files included by an active configuration file are used. The analysis invokes Snort with <code>snort.lua</code> as the config file, so any other config files need to be included either by <code>snort.lua</code>, or one of its included files.

'''While the <code>config.lua</code> is displayed in this list, it is discouraged to edit it directly.'''

It is possible to create new files via the button at the bottom of the file list. Hovering over a file reveals two buttons for deleting a file and reloading a file. Deleting a file will mark it for deletion, but that change will not be committed until "Save" or "Apply" are pressed. Reloading a file causes it to be re-fetched from the multimeter and discards all changes to that file. A file can be renamed by selecting it and pressing F2.

==== Rules ====
[[File:Snort config rule editor.png|thumb|The Snort rule editor]]
Snort needs a set of rules in order to know what malicious network traffic looks like. The [https://docs.snort.org/rules/ Snort documentation] goes into exhaustive detail about how rules are written, and we recommend users who are interested in writing their own rules read it carefully. The multimeter comes pre-equipped with an older version of the community ruleset, which is a file containing a huge list of rules which is not up-to-date, but still provides a good starter set to detect the most common suspicious network activity. Updates to this ruleset are not provided, so users who want to use the most recent set of rules need to keep this ruleset updated themselves.

To start editing the ruleset click the "Edit rules" button. This will bring up a modal displaying a file editor which is functionally identical to the [https://allegro-packets.com/wiki/Snort#Lua_editor Lua editor] . From here it is possible to create new ruleset files as well as editing or deleting existing ones.

'''Tip: Users who want to stay up-to-date and get access to rulesets containing the most recent exploits and attack vectors may want to consider subscribing to [https://www.snort.org/products#rule_subscriptions Snort's official ruleset].'''

All files in this view are loaded by Snort, so no additional action needs to be taken to add a new file to the ruleset.

Snort

2025-01-29T11:58:47Z

Robert: /* Rules */

{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}Version 4.3.0 of the Allegro Network Multimeter introduced Snort as a new capture method for network traffic. Similar to the Webshark analysis this capture mode does not produce raw packets, but instead sends them to another tool for further processing. With Snort the user is able to conveniently analyze the traffic in their network for potential attacks or intrusions, both live and retroactively.

== Configuration ==
For Snort to function properly it needs to be configured. The multimeter comes pre-equipped with the community ruleset to provide a basic set of rules to cover the most well-known and common attacks in a network. Note that currently no updates are provided for this ruleset by Allegro Packets, instead the user is expected to keep their ruleset up do date themselves.

All configurations of the Snort analysis are done via the Global Settings, under Generic Settings > Snort analysis.
[[File:Snort Settings.png|thumb|Snort section of the generic settings page]]

=== Configuring memory ===
Snort needs a certain amount of memory to be able to perform the intrusion detection and threat analysis. The more memory Snort is configured to use, the less memory will be available for the in-memory databases of the multimeter. Snort may only use half of the systems memory at max, but generally the software is able to run with less than one gigabyte of memory. The default setting allocates 256MB for the Snort analysis, and generally we do not recommend going too far below this value, as too little memory can cause Snort to hang and crash during analysis. If you experience similar issue, try raising the memory threshold.

Below the slider for maximum memory, a value for "Usable memory" is displayed. This value is a soft memory limit for Snort, which will cause it to be throttled when it reaches it. The usable memory is 5MB below the maximum. If Snort should reach the true maximum memory threshold it will immediately be killed by the OOM manager.

Changing this setting requires a processing restart in order to allocate the configured memory.

=== Configuring Snort ===
{{Warning|title=Beta Feature|Currently there is no proper way to inspect Snort's error output, so invalid configs may result in the Snort analysis seemingly crashing for no reason. At the moment we recommend testing the validity of the configuration with a local Snort installation.}}
==== Config====
Snort can be configured via Lua scripts which are executed in a sandboxed environment at startup. The multimeter is delivered with the default configuration files of Snort, with the exception that some of the variables have been moved to a new <code>config.lua</code> file. This file is included before everything else.

To learn more about how Snort configuration works, refer to [https://docs.snort.org/start/configuration their documentation].

In order to edit this configuration the multimeter provides a web-based interface to either change the <code>config.lua</code> via a GUI, or to edit any configuration file directly. To start editing the configuration click the "Edit config" button. This opens a new modal providing the two editing modes, which can be switched via the buttons at the top center of the window.

=====Simple editor=====
This is the first editing mode, and is the one selected by default when opening the config modal. It provides a GUI which allows the user to edit the variables stored in the <code>config.lua</code>. Note that this implies that <code>config.lua</code> is a managed file, which means that directly editing this file is discouraged. As the warning in this file states, editing the values of variables will work fine, however adding new content to the file will cause it to be overridden once the simple editor is used for the next time.
[[File:Snort config simple settings.png|thumb|The Snort config's simple editor]]
The simple editor provides only a few values that can be edited. Users are encouraged to adjust these values according to their network setup. Setting the home and external network is the only strictly necessary configuration, as the other values are derived from them. The default values for these networks is "any". Refer to the Snort documentation (see above) to find out which values are allowed. Values with a dollar sign ($) in front of them are variables, e.g. setting your DNS servers to <code>$HOME_NET</code> will set the vaule of the DNS servers field to the value of the Home network field. This is the default.

Modifications to these values are not committed until either the "Apply" or "Save" button are pressed. Saving the settings will close the modal, while applying them will commit the changes but keep the modal open. Cancelling will cause all unsaved changes to be discarded (a warning modal will ask for confirmation before discarding).

=====Lua editor=====
This is the "advanced" configuration mode for Snort, and is toggled by clicking the appropriate button at the center top of the modal.[[File:Snort configuration lua mode.png|thumb|The Snort config's lua editor]]
This view provides a text editor interface which allows for editing any of the Snort configuration files. The left hand side provides a file browser displaying all files in Snort's configuration folder. This does not necessarily mean that all of these files are used in the configuration. Only files included by an active configuration file are used. The analysis invokes Snort with <code>snort.lua</code> as the config file, so any other config files need to be included either by <code>snort.lua</code>, or one of its included files.

'''While the <code>config.lua</code> is displayed in this list, it is discouraged to edit it directly.'''

It is possible to create new files via the button at the bottom of the file list. Hovering over a file reveals two buttons for deleting a file and reloading a file. Deleting a file will mark it for deletion, but that change will not be committed until "Save" or "Apply" are pressed. Reloading a file causes it to be re-fetched from the multimeter and discards all changes to that file. A file can be renamed by selecting it and pressing F2.

==== Rules ====
[[File:Snort config rule editor.png|thumb|The Snort rule editor]]
Snort needs a set of rules in order to know what malicious network traffic looks like. The [https://docs.snort.org/rules/ Snort documentation] goes into exhaustive detail about how rules are written, and we recommend users who are interested in writing their own rules read it carefully. The multimeter comes pre-equipped with an older version of the community ruleset, which is a file containing a huge list of rules which is not up-to-date, but still provides a good starter set to detect the most common suspicious network activity. Updates to this ruleset are not provided, so users who want to use the most recent set of rules need to keep this ruleset updated themselves.

To start editing the ruleset click the "Edit rules" button. This will bring up a modal displaying a file editor which is functionally identical to the [https://allegro-packets.com/wiki/Snort#Lua_editor Lua editor] . From here it is possible to create new ruleset files as well as editing or deleting existing ones.

'''Tip: Users who want to stay up-to-date and get access to rulesets containing the most recent exploits and attack vectors may want to consider subscribing to [https://www.snort.org/products#rule_subscriptions Snort's official ruleset].'''

All files in this view are loaded by Snort, so no additional action needs to be taken to add a new file to the ruleset.

Snort

2025-01-29T11:57:47Z

Robert: /* Rules */

{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}Version 4.3.0 of the Allegro Network Multimeter introduced Snort as a new capture method for network traffic. Similar to the Webshark analysis this capture mode does not produce raw packets, but instead sends them to another tool for further processing. With Snort the user is able to conveniently analyze the traffic in their network for potential attacks or intrusions, both live and retroactively.

== Configuration ==
For Snort to function properly it needs to be configured. The multimeter comes pre-equipped with the community ruleset to provide a basic set of rules to cover the most well-known and common attacks in a network. Note that currently no updates are provided for this ruleset by Allegro Packets, instead the user is expected to keep their ruleset up do date themselves.

All configurations of the Snort analysis are done via the Global Settings, under Generic Settings > Snort analysis.
[[File:Snort Settings.png|thumb|Snort section of the generic settings page]]

=== Configuring memory ===
Snort needs a certain amount of memory to be able to perform the intrusion detection and threat analysis. The more memory Snort is configured to use, the less memory will be available for the in-memory databases of the multimeter. Snort may only use half of the systems memory at max, but generally the software is able to run with less than one gigabyte of memory. The default setting allocates 256MB for the Snort analysis, and generally we do not recommend going too far below this value, as too little memory can cause Snort to hang and crash during analysis. If you experience similar issue, try raising the memory threshold.

Below the slider for maximum memory, a value for "Usable memory" is displayed. This value is a soft memory limit for Snort, which will cause it to be throttled when it reaches it. The usable memory is 5MB below the maximum. If Snort should reach the true maximum memory threshold it will immediately be killed by the OOM manager.

Changing this setting requires a processing restart in order to allocate the configured memory.

=== Configuring Snort ===
{{Warning|title=Beta Feature|Currently there is no proper way to inspect Snort's error output, so invalid configs may result in the Snort analysis seemingly crashing for no reason. At the moment we recommend testing the validity of the configuration with a local Snort installation.}}
==== Config====
Snort can be configured via Lua scripts which are executed in a sandboxed environment at startup. The multimeter is delivered with the default configuration files of Snort, with the exception that some of the variables have been moved to a new <code>config.lua</code> file. This file is included before everything else.

To learn more about how Snort configuration works, refer to [https://docs.snort.org/start/configuration their documentation].

In order to edit this configuration the multimeter provides a web-based interface to either change the <code>config.lua</code> via a GUI, or to edit any configuration file directly. To start editing the configuration click the "Edit config" button. This opens a new modal providing the two editing modes, which can be switched via the buttons at the top center of the window.

=====Simple editor=====
This is the first editing mode, and is the one selected by default when opening the config modal. It provides a GUI which allows the user to edit the variables stored in the <code>config.lua</code>. Note that this implies that <code>config.lua</code> is a managed file, which means that directly editing this file is discouraged. As the warning in this file states, editing the values of variables will work fine, however adding new content to the file will cause it to be overridden once the simple editor is used for the next time.
[[File:Snort config simple settings.png|thumb|The Snort config's simple editor]]
The simple editor provides only a few values that can be edited. Users are encouraged to adjust these values according to their network setup. Setting the home and external network is the only strictly necessary configuration, as the other values are derived from them. The default values for these networks is "any". Refer to the Snort documentation (see above) to find out which values are allowed. Values with a dollar sign ($) in front of them are variables, e.g. setting your DNS servers to <code>$HOME_NET</code> will set the vaule of the DNS servers field to the value of the Home network field. This is the default.

Modifications to these values are not committed until either the "Apply" or "Save" button are pressed. Saving the settings will close the modal, while applying them will commit the changes but keep the modal open. Cancelling will cause all unsaved changes to be discarded (a warning modal will ask for confirmation before discarding).

=====Lua editor=====
This is the "advanced" configuration mode for Snort, and is toggled by clicking the appropriate button at the center top of the modal.[[File:Snort configuration lua mode.png|thumb|The Snort config's lua editor]]
This view provides a text editor interface which allows for editing any of the Snort configuration files. The left hand side provides a file browser displaying all files in Snort's configuration folder. This does not necessarily mean that all of these files are used in the configuration. Only files included by an active configuration file are used. The analysis invokes Snort with <code>snort.lua</code> as the config file, so any other config files need to be included either by <code>snort.lua</code>, or one of its included files.

'''While the <code>config.lua</code> is displayed in this list, it is discouraged to edit it directly.'''

It is possible to create new files via the button at the bottom of the file list. Hovering over a file reveals two buttons for deleting a file and reloading a file. Deleting a file will mark it for deletion, but that change will not be committed until "Save" or "Apply" are pressed. Reloading a file causes it to be re-fetched from the multimeter and discards all changes to that file. A file can be renamed by selecting it and pressing F2.

==== Rules ====
[[File:Snort config rule editor.png|thumb|The Snort rule editor]]
Snort needs a set of rules in order to know what malicious network traffic looks like. The [https://docs.snort.org/rules/ Snort documentation] goes into exhaustive detail about how rules are written, and we recommend users who are interested in writing their own rules read it carefully. The multimeter comes pre-equipped with an older version of the community ruleset, which is a file containing a huge list of rules which is not up-to-date, but still provides a good starter set to detect the most common suspicious network activity. Updates to this ruleset are not provided, so users who want to use the most recent set of rules need to keep this ruleset updated themselves.

To start editing the ruleset click the "Edit rules" button. This will bring up a modal displaying a file editor which is functionally identical to the [https://allegro-packets.com/wiki/Snort#Lua_editor Lua editor] . From here it is possible to create new ruleset files as well as editing or deleting existing ones.

'''Tip: Users who want to stay up-to-date and get access to rulesets containing the most recent exploits and attack vectors may want to consider subscribing to [https://www.snort.org/products#rule_subscriptions Snort's official ruleset].'''

Snort

2025-01-29T10:46:41Z

Robert: add rule editor info

{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}Version 4.3.0 of the Allegro Network Multimeter introduced Snort as a new capture method for network traffic. Similar to the Webshark analysis this capture mode does not produce raw packets, but instead sends them to another tool for further processing. With Snort the user is able to conveniently analyze the traffic in their network for potential attacks or intrusions, both live and retroactively.

== Configuration ==
For Snort to function properly it needs to be configured. The multimeter comes pre-equipped with the community ruleset to provide a basic set of rules to cover the most well-known and common attacks in a network. Note that currently no updates are provided for this ruleset by Allegro Packets, instead the user is expected to keep their ruleset up do date themselves.

All configurations of the Snort analysis are done via the Global Settings, under Generic Settings > Snort analysis.
[[File:Snort Settings.png|thumb|Snort section of the generic settings page]]

=== Configuring memory ===
Snort needs a certain amount of memory to be able to perform the intrusion detection and threat analysis. The more memory Snort is configured to use, the less memory will be available for the in-memory databases of the multimeter. Snort may only use half of the systems memory at max, but generally the software is able to run with less than one gigabyte of memory. The default setting allocates 256MB for the Snort analysis, and generally we do not recommend going too far below this value, as too little memory can cause Snort to hang and crash during analysis. If you experience similar issue, try raising the memory threshold.

Below the slider for maximum memory, a value for "Usable memory" is displayed. This value is a soft memory limit for Snort, which will cause it to be throttled when it reaches it. The usable memory is 5MB below the maximum. If Snort should reach the true maximum memory threshold it will immediately be killed by the OOM manager.

Changing this setting requires a processing restart in order to allocate the configured memory.

=== Configuring Snort ===
{{Warning|title=Beta Feature|Currently there is no proper way to inspect Snort's error output, so invalid configs may result in the Snort analysis seemingly crashing for no reason. At the moment we recommend testing the validity of the configuration with a local Snort installation.}}
==== Config====
Snort can be configured via Lua scripts which are executed in a sandboxed environment at startup. The multimeter is delivered with the default configuration files of Snort, with the exception that some of the variables have been moved to a new <code>config.lua</code> file. This file is included before everything else.

To learn more about how Snort configuration works, refer to [https://docs.snort.org/start/configuration their documentation].

In order to edit this configuration the multimeter provides a web-based interface to either change the <code>config.lua</code> via a GUI, or to edit any configuration file directly. To start editing the configuration click the "Edit config" button. This opens a new modal providing the two editing modes, which can be switched via the buttons at the top center of the window.

=====Simple editor=====
This is the first editing mode, and is the one selected by default when opening the config modal. It provides a GUI which allows the user to edit the variables stored in the <code>config.lua</code>. Note that this implies that <code>config.lua</code> is a managed file, which means that directly editing this file is discouraged. As the warning in this file states, editing the values of variables will work fine, however adding new content to the file will cause it to be overridden once the simple editor is used for the next time.
[[File:Snort config simple settings.png|thumb|The Snort config's simple editor]]
The simple editor provides only a few values that can be edited. Users are encouraged to adjust these values according to their network setup. Setting the home and external network is the only strictly necessary configuration, as the other values are derived from them. The default values for these networks is "any". Refer to the Snort documentation (see above) to find out which values are allowed. Values with a dollar sign ($) in front of them are variables, e.g. setting your DNS servers to <code>$HOME_NET</code> will set the vaule of the DNS servers field to the value of the Home network field. This is the default.

Modifications to these values are not committed until either the "Apply" or "Save" button are pressed. Saving the settings will close the modal, while applying them will commit the changes but keep the modal open. Cancelling will cause all unsaved changes to be discarded (a warning modal will ask for confirmation before discarding).

=====Lua editor=====
This is the "advanced" configuration mode for Snort, and is toggled by clicking the appropriate button at the center top of the modal.[[File:Snort configuration lua mode.png|thumb|The Snort config's lua editor]]
This view provides a text editor interface which allows for editing any of the Snort configuration files. The left hand side provides a file browser displaying all files in Snort's configuration folder. This does not necessarily mean that all of these files are used in the configuration. Only files included by an active configuration file are used. The analysis invokes Snort with <code>snort.lua</code> as the config file, so any other config files need to be included either by <code>snort.lua</code>, or one of its included files.

'''While the <code>config.lua</code> is displayed in this list, it is discouraged to edit it directly.'''

It is possible to create new files via the button at the bottom of the file list. Hovering over a file reveals two buttons for deleting a file and reloading a file. Deleting a file will mark it for deletion, but that change will not be committed until "Save" or "Apply" are pressed. Reloading a file causes it to be re-fetched from the multimeter and discards all changes to that file. A file can be renamed by selecting it and pressing F2.

==== Rules ====
[[File:Snort config rule editor.png|thumb|The Snort rule editor]]
Snort needs a set of rules in order to know what malicious network traffic looks like. The [https://docs.snort.org/rules/ Snort documentation] goes into exhaustive detail about how rules are written, and we recommend users who are interested in writing their own rules read it carefully. The multimeter comes pre-equipped with an older version of the community ruleset, which is a file containing a huge list of rules which is not up-to-date, but still provides a good starter set to detect the most common suspicious network activity. Updates to this ruleset are no provided, so users who want to use most recent set of rules need to keep this ruleset updated themselves.

To start editing the ruleset click the "Edit rules" button. This will bring up a modal displaying a file editor which is functionally identical to the [https://allegro-packets.com/wiki/Snort#Lua_editor Lua editor] . From here it is possible to create new ruleset files as well as editing or deleting existing ones.

'''Tip: Users who want to stay up-to-date and get access to rulesets containing the most recent exploits and attack vectors may want to consider subscribing to [https://www.snort.org/products#rule_subscriptions Snort's official ruleset].'''

File:Snort config rule editor.png

2025-01-29T10:41:35Z

Robert:

Editor for the snort module

Snort

2025-01-29T10:34:04Z

Robert: mention snort config

File:Snort configuration lua mode.png

2025-01-29T10:24:29Z

Robert:

The Snort configuration modal in lua mode

File:Snort config simple settings.png

2025-01-29T10:18:29Z

Robert:

This is the simple editor for modifying the Snort config

Snort

2025-01-29T10:03:05Z

Robert: add mem config

File:Snort Settings.png

2025-01-29T09:50:58Z

Robert:

Snort Settings

Snort

2025-01-29T08:37:01Z

Robert: stub

Capture module

2025-01-29T08:23:18Z

Robert: mention snort in the capture documentation

==Capture module ==
The Allegro Network Multimeter allows direct capturing of network traffic as a HTTP download to your computer. No packet data is stored on the device itself. Traffic can be directly filtered for specific packets, only the relevant packets will be captured. In addition, it is also possible to capture network traffic to an attached storage device, see the settings section below for details. Capturing network traffic is usually started by clicking on a PCAP button in a certain module. These buttons allow capturing specific traffic, for example for a certain IP address or a network protocol. The capture module allows to configure filter for traffic that has not even started right now, for example for an IP address that is not in use at the moment but might be used later. The capture module page displays all currently running captures and allows starting new captures with specific filters.

{| class="wikitable sortable"
|-
|[[File:Generic modules.png|800px|none|right]]
|}

=== Current captures ===
The first part of the page displays all downloads running for the current user session, and all downloads running for other user sessions (like when a download has been started outside the browser by directly using command line tools such as wget or curl).
The list contains the client IP and port of the user running the download.

The next three counters describe:

* the number of packets captured for the corresponding filter.
* the number of packets dropped by the capturing module. Packet drops can appear when doing live capture and more packets are captured than can be transferred via HTTP to the client, or the storage is not capable of storing all matching packets. During live capture, the drop counter is the exact number of packets matching the filter but were dropped because of the reasons mentioned previously. Packet drops are also accounted when capturing from the past out of the ring buffer. It happens when the ring buffer dropped packets during the capture interval due to insufficient bandwidth available on the storage devices. In retrospective capturing, the drop counter only indicates that some packets may have been missed. The counter is the total amount of packets not available in the ring buffer, which are not necessarily part of the capture filter.
* the number of ignored packets. Ignored packets do not match the given capture filter.

The following columns list the applied filter criteria. The last column contains a button to stop the corresponding download. Downloads can also be stopped by clicking the same capture button that started the capture in the corresponding module. If multiple devices have been configured, the list also contains all captures from all multi-devices which can be stopped individually.

==== Finished captures ====
This list shows the last captures that have finished. It shows up to 100 entries while the oldest entries are discarded when the list is full. For each entry the following information is displayed:

* the packet capturing mode
* the type of capture
* the start- and end-time of the capture (the actual real-time when the capture was initiated and ended)
* the number of captured/dropped/ignored packets during the capture
* the amount of data generated for the capture (along with the average throughput of e.g. the capture download)
* the capture filter which was used for the capture
* the finishing reason of the capture job (e.g. completed normally, stopped by user or aborted due to no space left on storage)

The button '''Delete list of finished captures''' will delete all entries from this list.

==== Recent filters ====
This list shows the most recently used capture filters for the current user. The most recent capture filter is displayed on the top. Next to each capture filter there is a button to permanently save this capture filter as a favorite as well as a button to simply start a capture with this filter again. The '''Use as expert filter''' button will copy the capture filter into the expert filter input field and allows for customizing the capture. The button '''Delete list of recent filters''' will delete all entries from this list.

==== Favorites ====
This list shows favorite capture expressions. A capture can be marked as a favorite either in the capture dialog by clicking on the star button in the top right corner or by marking it as a favorite in the '''Recently captured''' list. A description can be given and will be displayed in this list. For each favorite capture a PCAP button is available to simply start this capture again. The '''Remove favorites''' button allows for cleaning the list. The '''Use as expert filter''' button will copy the capture filter into the expert filter input field and allows for customizing the capture.

==== Planned captures ====
On this tab captures to a storage device can be planned ahead of time and these captures can even be set to repeat automatically. A click on the '''Add planned capture''' button opens a dialog where the planned capture can be configured. This includes settings like the storage device to use, the start date and time of the capture, the duration of the capture, if a capture should repeat and the filter expression used during the capture. It is important to know that planned captures will not function if the chosen storage device is not active.

==== Capture profiles ====
[[File:Capture profiles config.png|thumb|600x600px|Capture profile configuration]]
[[File:Capture profiles edit profile.png|thumb|600x600px|Edit capture profile]]
Capture profiles can be used in the capture dialog for custom packet truncation rules. Such profiles defines custom rules for packet snapshot length similar to ring buffer filters. This allows to use a different snapshot length for specific layer 7 protocols, if for example traffic of one protocol shall be captured completely while for another protocol only the IP header shall be captured. Such a capture profile can be selected in the capture dialog in the "Truncate packet length" select box.

Up to 10 different profiles can be configured by clicking at the "Add profile" button. The add/edit dialog allows to enter a profile name and up to 10 rules for snapshot length. Similar to [[Packet ring buffer#Packet ring buffer snapshot length filter|ring buffer filters]], the first rule that matches for the selected type is used to decide for the snapshot length of the actual packet.

To restrict the capture possibilities of an user it is possible to choose an 'restricting profile'. This allows the administrator to stop the user from capturing other sensitive data like SIP- and RTP-Packages.

==== PCAP anonymization profile ====

Anonymization profiles can be used in capture dialog to allow for quickly switch between rules to anonymize aspects of the generated PCAPs.

When enabled, following options are available (more than one option is possible):
* MAC addresses on L2
:MAC addresses on L2 will be replaced by random addresses octet-wise. Multicast/broadcast addresses will not be randomized.
* IP addresses on L3
:IP addresses on L3 will be replaced by random addresses octet-wise for IPv4 and hextet-wise for IPv6. Multicast/broadcast addresses will not be randomized. The octets of the IP address will have the same length in textual representation (e.g. 100.20.3.40 -> 105.31.6.41). For IPv6 address short notation will be considered and the randomized result will also have the same textual length.
* IP addresses on L7
:IPv4 and IPv6 addresses in textual representation in L7 payload will be randomized similar to L3.
* Mapped IP addresses in STUN packets on L7
:STUN payload IP addresses will be randomized similar to L3.
* Phone numbers, name and Call ID in SIP packets on L7
: SIP payload data is masked with 'xxx' values for the names and phone numbers in the fields "From", "To", "Contact", "P-Asserted-Identity". Call Ids are also replaced. IP addresses are not touched, if they shall be anonymized, please use option "IP addresses on L7".
* URLs and HTTP hostnames on L7
: URLs and HTTP hostnames in L7 payload are masked with 'xxx' values. The length of the masked name/URL will stay the same and line feeds won't be touched.
:: Examples:
:: 'GET /website.html?param1=value HTTP/1.1\r\n' will be changed to 'GET xxxxxxxxxxxxxxxxxxxxxxxxxx HTTP/1.1\r\n'
:: 'Host: allegro-packets.com\r\n' will be changed to 'Host: xxxxxxxxxxxxxxxxxxx\r\n'
:: https://www.allegro-packets.com/en/ will be completely masked

Within an anonymization profile it is also possible to define MAC and IP lists with entries that should be anonymized or that should be excluded from anonymization. The proper L2/L3 anonymization option '''must be turned on''' in order to have an effect!

The amount of SIP phone numbers last hidden digits can be configured, e.g. with a setting of 4 last hidden digits a phone number +49123456789 becomes +4912345xxxx.

Address anonymization is stable for the whole PCAP, i.e. the same addresses will be replaced by the same random addresses. As an example, if both randomization of IP addresses on L3 and L7 is active and a SIP call with RTP is captured, both IP addresses in L3 and SIP SDP payload are replaced by the same values so that the correlation of the RTP stream is still intact.

Checksums of the changed packets are '''not''' being recalculated.

A privileged user may enforce an anonymization profile that is being used for all users that do not have the unrestrictive capture permission in a role. This profile will always be taken into account and the unprivileged user may only add additional anonymizations on top of it for captures (but the user can't overwrite it with less restrictive settings).

==== SFTP server ====
Credentials and upload directories for a SFTP server can be configured here. They can be selected in the capture dialog later when choosing "Capture to SFTP server" as capture type. It is possible to either configure a user and password or use authentication with a public key. In the latter case, the displayed SSH public key needs to be inserted in the authorized hosts list on the SFTP server.

=== Simple capture ===
The second section of the capture page allow to select some fields to filter network traffic for. By default, only the IP field is visible, the other fields can be enabled by clicking on the corresponding toggle switch. Each line allows to enter a filter criterion for the corresponding network traffic element. To start the capture with the entered filter criteria just click at the '''Start capture''' button. For reference, the expert filter expression is shown at the end of the section so it can be used to copy and paste
the string into the expert filter section.

=== Using expert filters to start captures ===
The third part of the page allows for starting a download for any criterion combination using complex filter expressions. A capture filter is defined in a C-style syntax and supports combination of AND/OR operators, precedence order with parentheses and equal/not equal comparisons. If the filter exp Session can be evaluated to true, the packet is
captured.
If a value contains a space, the whole value must be quoted with “”.
Following operators are supported:
* '''and''', '''&&''' : AND operator. The filter expression will match if all operands could be evaluated to true.
* '''or''', '''||''': OR operator. The filter expression will match if any operand can be evaluated to true.

Following comparison operators are supported:
* '''==''': Will evaluate expression to true if left and right operand are equal.
* '''!=''': Will evaluate expression to true if left and right operand are not equal.

Following operands are supported:
* '''ip''': An IP address. The packet is captured if either source or destination IP address of the packet match. A netmask and a port can also be specified. For IPv6 addresses with a specific port, the address must be written in brackets.
:Example:
:{| class="wikitable sortable"
|-
|
ip == 10.0.0.1

ip == ff02::1:3

ip == 10.0/16

ip == 10.0.0.1:1234

ip == [2a02:810a:1340:1292:1c6b:e58d:6ebc:6cd2]:123
|-
|}

* '''ip.src, ip.dst''': The source or destination IP address.
:Example:
:{| class="wikitable sortable"
|-
|
ip.src == 10.0.0.1/8 and ip.dst == 10.0.0.1/8
|-
|}
: This will match traffic only within 10.0.0.1/8 subnet. If src/dst is omitted, also in or outbound traffic from or to other subnets is captured!

*'''mac''': A MAC address. The packet is captured if either source or destination MAC address of the packet match.
:Example:
:{| class="wikitable sortable"
|-
| mac == 12:34: :56:78:90:ab
|-
|}

* '''port''': A TCP or UDP port. The packet is captured if either source or destination port match.
:Example:
:{| class="wikitable sortable"
|-
| port == 80
|-
|}

* '''portrange''': A TCP or UDP port range. The range can be a single number or a comma separated list of values or value ranges.
:Example:
:{| class="wikitable sortable"
|-
| portrange == 80,100-120,-10,65000-
|-
|}

* '''serverport''': A TCP or UDP port of a server. The packet is captured if the given port is a port of the server and not of a client. The range can be a single number or a comma separated list of values or value ranges.
:Example:
:{| class="wikitable sortable"
|-
| serverport == 80,100-120,-10,65000-
|}

* '''macProtocol''': A MAC protocol such as IPv4 or IPv6. For all seen MAC protocols, please consult the MAC Protocol Statistics module.
:Example:
:{| class="wikitable sortable"
|-
| macProtocol == IPv4
macProtocol == "Non IP"
|-
|}

* '''l4Protocol''': A layer 4 protocol such as TCP or UDP or any IP protocol number. Protocols can also be OR combined as a comma seperated list.
:Example:
:{| class="wikitable sortable"
|-
| l4Protocol == ICMP,ICMPv6
|-
|}

* '''l7Protocol''' or '''dpiProtocol''': A layer 7 protocol. Protocols can also be OR combined as a comma seperated list. For all seen protocols please consult the Layer 7 protocols module.
* '''countryCode''': A country code such as US. For all seen country codes please consult the Geolocation module.
* '''arpip''': An IP address within an ARP request or response.
* '''vlan''': A VLAN tag of an outer or inner VLAN. May be a number or none or any.
* '''outervlan''': A VLAN tag of an outer VLAN. May be a number or none or any.
* '''innervlan''': A VLAN tag of an inner VLAN. May be a number or none or any.
* '''multicastGroup''': A multicast IP address or any. The filter will match all IGMP or MLD negotiation packets related to that multicast IP address.
* '''rtpPayloadType''': The RTP payload type such as PCMU or MP2T. This filter will match all RTP packets with the given payload type.
* '''interface.name''' or '''namedInterface''': The physical interface. This can be the name or interface number (as printed on the device). For interface ids please consult the Interface stats page.
:Example:
:{| class="wikitable sortable"
|-
| <nowiki>interface.name == uplink || interface.name == 3</nowiki>
|-
|}

* '''interface.rawid''': This is the raw internal ID of interfaces. It starts from 0. The interface stats page also shows the raw ID.
* '''link''': The link pair of two interfaces as stated in Interface stats. A single link number can be given.
* '''pppoeProtocol''': A specific PPPoE protocol (by name or by ID), or "none"/"any"
* '''pppoeAuthentication''': An authentication state of a PPPoE session
* '''pppoeLinkConfiguration''': A link configuration state of a PPPoE session
* '''ptpMsgType''': A specific PTP message type number or any for the whole PTP traffic.
* '''profinetFrameId''': A specific Profinet frame ID.
* '''profinetCmOpnum''': A specific operation number for Profinet CM (Context Manager) requests or responses. Can also be any for every operation number. Following values are used:
:#connect
:#release
:#read
:#write
:#control
:#read implicit

* '''mpls''': A label of an outer or inner MPLS. May be a number or none or any.
* '''outerMpls''': A label of an outer MPLS. May be a number or none or any.
* '''innerMpls''': A label of an inner MPLS. May be a number or none or any.
* '''qosIpDscp''': The DSCP value in the IP header. May be a number.
* '''qosMplsTc''': The traffic class value in the outermost MPLS label stack entry.
* '''qosVlanPcp''': The priority code point value in the outermost VLAN tag.
* '''group''': The name of a configured group or ‘default’. If the name contains whitespaces, the name must be enclosed in quotes.
* '''badCRC''': The value of this operand will be 1 for packets with a CRC error and will be 0 for good packets. Capturing packets with bad CRC is currently only supported on 1Gb interfaces.
* '''icmpType''': The value of a certain ICMP type (e.g. Echo request 8, Echo reply 0).
* '''dhcpMessageType''': The value of a certain DHCP message type (e.g. Request 3, ACK 5).
* '''tcpFlags''': A single TCP flag or a list of TCP flags joined by the ‘+’ sign. If a list of flags is given, all flags must be present in the packet. Supported TCP flags are syn, ack, fin, rst, psh and urg.
* '''callId''': The string value of a SIP call ID or similar identifier (e.g. P-Palladion-ID)
* '''ipFragment''': If set to 1 all IPv4 fragments will be captured (i.e. packets having the 'More fragments' flag and 'Fragment offset' set). If set to 0 all packets without IPv4 fragmentation will be captured.
* '''regexp''': The packet payload matches the quoted regular expression (RegEx) to the other side of the == operator or does not match the regular expression to the other side of the != operator. In case of IP packets the matching will be performed on the L7 payload of the packet. In case of non-IP packets the matching will be performed on the whole packet except the Ethernet header. Regular expressions largely support the pattern syntax used by the PCRE library with the exception of certain constructs. An invalid pattern will produce a descriptive error message and prevent the capture from being started.
* '''ipDoNotFragment''': The value of this operand will be 1 for IPv4 packets that are marked as to not be fragmented (packets which have the 'do not fragment' flag set).
* '''mactype''': The type of the packets destination MAC address. Allowed values are 'unicast, 'broadcast' and 'multicast'.
* '''slowSubtype''': The subtype of packets with the macProtocol == SLOW (e.g. 1 for LACP).
* '''wifiFrequency''': The frequency (channel) of a WiFi packet in MHz.
* '''wifiBssid''': The BSS ID participating in a WiFi packet. This is similar to a MAC address.

For a specific precedence you may use parentheses '''('''/''')'''.

Examples:
* The expression
:{| class="wikitable sortable"
|-
| ip == 10.0.0.1:1234 and ip == 10.1.0.1:9876
|-
|}
:will match a connection from 10.0.0.1 to 10.1.0.1 or vice versa with the ports 1234 and 9876 involved.

* The expression
:{| class="wikitable sortable"
|-
| ip == 10.0.0.1 and ip != 10.0.0.2
|-
|}
:will match packets having 10.0.0.1 either as source or destination. If a communication peer of 10.0.0.1 is 10.0.0.2 the packets will not be captured.

* The expression
:{| class="wikitable sortable"
|-
| l4Protocol == ICMP,ICMPv6
|-
|}
:will match packets with ICMP or ICMPv6 layer 4 protocols.

* The expression
:{| class="wikitable sortable"
|-
| portrange == 80,443
|-
|}
:will match packets to or from port 80 or 443.

* The expression
:{| class="wikitable sortable"
|-
| regexp == "allegr[o,a]'''<nowiki>|</nowiki>'''HTTP"
|-
|}
:will case sensitive match packets that contain the string(s) 'allegro' and/or 'allegra' and/or 'HTTP' anywhere in the payload.
:NOTE: The use of regexp is CASE sensitive. You must use the (?i) modifier to enable case insensitive filtering.

* The expression
:{| class="wikitable sortable"
|-
| regexp == "(?i)allegro'''<nowiki>|</nowiki>'''http"
|-
|}
:will case insensitive match packets that contain the string(s) 'allegro' and/or 'http' anywhere in the payload.
:NOTE: The use of regexp is CASE sensitive. You must use the (?i) modifier to enable case insensitive filtering.

Of course the Allegro Network Multimeter regular expression (RegEx) capture filter, can also be used in combination with our other capture expressions.

* The expression
:{| class="wikitable sortable"
|-
| regexp == “allegro'''<nowiki>|</nowiki>'''analyzer” and l7protocol == "dns"
|-
|}
:Will case sensitive match and capture only DNS packets containing the string(s) “allegro” and/or “analyzer.

* The expression
:{| class="wikitable sortable"
|-
| regexp == “allegro'''<nowiki>|</nowiki>'''analyzer” and l7protocol != "dns"
|-
|}
:Will case sensitive match and capture all (except DNS) packets containing the string(s) “allegro” and/or “analyzer.

Whenever you are unsure about the outcome of RegEx based packet capturing, you can pre-test the outcome of your expressions on https://pythex.org/.
While pre-testing on https://pythex.org/, avoid using the “IGNORECASE” button. Instead use the (?i) modifier for constructing case insensitive expressions, as mentioned above.
PCRE/Python based expression examples and explanations you'll find on https://www.programiz.com/python-programming/regex

All captures can be limited to any amount of time or bytes, for example to capture only one minute or one megabyte of traffic.

Below the list of filter criteria, you will find the button to actually start (or stop) the capture. In case the filter expression is invalid, the button is disabled.

====Layer 7 protocol capture====
Layer 7 protocol detection engine may need several packets to recognize the currently used protocol. For these captures all not yet recognized packets will be skipped. As soon as the protocol recognition is finished, all packets matching the protocol filter will be captured.

=== Configuration settings ===
By clicking on the gear button on the top right of the Capture web page, you can access the configuration section.

*The maximum number of concurrent capture sessions
:Per default out-of-box setting (factory default), all Allegro Network Multimeter models allow up to 4 concurrent captures. As of FW ≥ V3.4, the number of allowed concurrent captures, can be increased up to 64, depending on model and available RAM. Note, that Increasing the number of allowed parallel/concurrent captures will decrease memory capacity for the in-memory DB, therewith decreasing the maximum timeframe of statistics held and presented in the web-interface. If the memory usage is too high, the number of parallel captures might be lower/limited by the Allegro itself.

*Split PCAP file after this size
: This option can be used to limit the size of the PCAP file when storing to an attached device. Once the captured traffic would exceed this threshold, a new PCAP file with the current time stamp is created and the traffic is written to the new file. If the time stamp is still the same, an index is attached to the filename.
: When set to 0, no splitting will be done.

*Split PCAP file after this duration
:This option can be used to limit the duration of the PCAP file when storing to an attached device. The duration starts counting with the start of the capture. Once the captured traffic would exceed the duration, a new PCAP file with the current time stamp is created and the traffic is written to the new file.
:When set to 0, no splitting will be done.
:Both split parameters can be combined. The PCAP file will be split as soon as one threshold has been reached.

*The maximum number of concurrent packet ring buffers
:This option is used to specify how many cluster packet ring buffers can run in parallel.
:Be aware that each cluster will have it's own queue in memory and therefore the memory required is the number of cluster packet ring buffers multiplied by the setting of '''The size in MB for the queue of the packet ring buffer'''.
:A reboot of the device or a restart of the processing is needed for a change to this option to take effect.

*The size in MB for the queue of the packet ring buffer
: This option allows to configure the size of the queue that holds processed packets before they are written to the packet ring buffer. Increasing the size of this queue may help if the disk used for the packet ring buffer cannot keep up with bursts of traffic so that packet drops occur in the packet ring buffer.
:Be aware that memory allocated to this queue is not available for storing statistics and metadata so that choosing a large value for this queue reduces the overall data storage time.
:Most users will not need to change this value from the default value.
:A reboot of the device or a restart of the processing is needed for a change to this option to take effect.

*The maximum size in MB for the packet reorder buffer when capturing from the packet ring buffer
:This setting allows to choose the maximum size that the packet reorder buffer may grow to. For performance reasons the packet ring buffer does not ensure a total order of packets when storing them on disk. The packet reorder buffer is used to restore the correct order of packets in a capture when capturing from the packet ring buffer. A larger packet reorder buffer makes it more likely that the packet order can be restored for all packets. The actual amount of memory used for the packet reorder buffer depends on this setting but also on the amount of free memory in the system so that the effectively used amount of memory may be less than this setting indicates.

=== Capture settings dialog ===
[[File:Choose capture settings.png|none|thumb|600x600px]]
This dialog appears after a capture button has been clicked. Following settings are possible:
*Start time and end time
:By clicking on the input field or on the calendar icon you can choose the start and end time of the capture. The input field is also editable with keyboard and allows entering a time on a second basis.
: If the start time is in the past, the complete capture is performed on the stored data of the capture ring buffer. When the capture reaches the newest packets it still continues to read from the capture ring buffer. The dialog will limit the start time input to the earliest data of the capture ring buffer. Be aware, that a possible capture ring buffer filter was applied on the past data and is also applied on future data in this mode.
: The start time may also be in the future. The capture is scheduled and starts as soon as a packet is received with a time later than the start time.
:If the whole time input field is marked and deleted, the start or end time will reset back to the default value. The default value for start time is '''now''', the capture will start with pushing the '''Start capturing''' button. The default value of the end time is '''unlimited''', the capture will not stop unless stopped manually by clicking on the stop button.
:Eight buttons offer quick selection of often used time settings.

*Packet ring buffer
:If multiple packet ring buffer clusters are active this dropdown menu allows to choose from which cluster the packets should be captured.

*Capture type
: This drop down menu allows to choose the method how packets are captured. The last successful setting is persistently stored per user. Following methods are available:

:*HTTP download
::This is the default method. The capture will start a HTTP download of a PCAP file directly in the browser.
:: Available HTTP download options:
::*Set file name: allow to configure a custom file name for the capture file
::*Download as zip archive: Download the capture file as a compressed zip archive
:*Disk
::This method is only visible if at least one storage device is active and has some amount of free storage space. The capture will create a PCAP file on the selected storage device.
::If PCAP export via SFTP is enabled, an additional checkbox is displayed to store the capture file in the export directory, slated for upload according the SFTP export settings.

:*Interface
::This mode will transmit the captured packets on a physical network interface. It is not available when the system is analyzing a PCAP file or is analyzing the packet ring buffer.

:* ERSPAN
::This mode will transmit the captured packets encapsulated in a GRE + ERSPAN header on the management interface to a given target IP address. On the target system the traffic can be selectively captured using the filter '''ip proto 0x2f''' when using an application like Wireshark or tcpdump.

:* Capture to SFTP server
::This mode will stream the PCAP to the selected SFTP server using the given credentials. SFTP servers can be configured on the Capture page

*Storage device
:If the 'disk' capture type is chosen, this drop-down menu allows to choose one of the active storage devices. The capture will be stored on the selected device.

*File name
:If browser download or disk storage has been chosen and the "Set file name" checkbox has been selected, the file name of the created capture file can be set in this field. The default value shows the filename with date wildcards and the capture filter. The date wildcards are then replaced by the start time of the capture.
:Date format specifier can be used as supported by strftime() function call. Some common specifier:
:*%Y for year
:*%m for month
:* %d for day
:*%H for hours
:*%M for minutes
:*%S for seconds
:Filenames are remembered when the dialog is closed and reopened. Clicking the circular arrow resets the filename to its default.

*Storage directory
:If disk storage has been chosen, the target directory on the storage device can be set in this field. Sub-directories on the storage device can be created and inspected on the [[Storage#Working with storage contents|Storage]] page.

* Zip options
:If browser download has been chosen and the zip download option is selected, the file size can be configured after which the pcap files within the archive is spit into additional files
:The number is entered in megabytes. 0 means no splitting.

*Interface to transmit on
:This dropdown menu is only shown when Capture type is Interface. Here the physical interface on which to transmit captured packets can be selected.

* ERSPAN target address
:This section is only shown when Capture type is ERSPAN. Here the target IP address or hostname for the ERSPAN encapsulated packets must be specified.

*ERSPAN session ID
:This section is only shown when Capture type is ERSPAN. The ERSPAN session ID can be used to differentiate between multiple capture session on the ERSPAN target.

*Transmit speed
: This dropdown menu is only shown when the Capture type is either Interface or ERSPAN and the start time is in the past so that packets are captured from the packet ring buffer. Here the limiting mode can be chosen which controls how fast captured packets are transmitted. Following modes are available:

:*none
::No limit will be applied and the packets are transmitted as fast as the network interface and the packet ring buffer allow.

:*limit to bandwidth
::A bandwidth limit will be applied so that the given bandwidth in Mbps is not exceeded. The bandwidth can be given as a decimal so that e.g. 500kbps can be configured with a value of 0.5.

:*realtime factor
:: Packets will be transmitted based on their recorded timing information. This means that with a real time factor of 1.0 packets will be transmitted approximately with the same timing as they were originally received. Using for example a real time factor of 2.0 would transmit the packets with twice the speed than they were received.

* Transmit bandwidth in Mbps
:This is only shown when limit to bandwidth has been selected in the Transmit speed dropdown menu. The meaning of this value is explained in the Transmit speed section.

*Transmit realtime factor
:This is only shown when realtime factor has been selected in the Transmit speed dropdown menu. The meaning of this value is explained in the :Transmit speed section.

*Truncate packet length:
:This dropdown menu is only shown when the Capture type is either HTTP or disk. You can truncate captured Packets with this setting. All packets will be captured, but truncated to the given length if they are longer than this setting. The length setting is applied on layer 2 without frame check sequence.
:Possible values are:
:*Full length
:*64 Bytes
:*1500 Bytes
:*Custom length with an input field for inserting any length between 64 and 15378 Bytes
:*Capture profile: select a configured capture profile which defines rules about how many bytes are saved depending on the configured rules.

*PCAP compatibility:
:This section is only shown when the Capture type is either HTTP or disk.
:*Omit interface ID
::Enabling this option will generate a PCAP file that only contains a single interface and treats all packets as if they arrived on that interface. This may improve compatibility with third party software that cannot handle PCAPs with multiple interfaces IDs.

*PCAP comment:
:Allows to add a user defined comment to the generated PCAP file.
:*Add device information to comment
::Enabling this option will insert additional device information such as name, serial, memory size or capture filter into he PCAP comment.

*PCAP packet type:
:This dropdown menu allows to choose the datalink packet type of the PCAP file. It is possible to choose between capturing regular Ethernet packets or raw Radiotap IEEE 802.11 WiFi packets in some places.
:Possible values are:
:*Ethernet
:*Radiotap

* Anonymization
: This option allows enabling or disabling anonymization of the downloaded PCAP file by either apply generic settings or choosing a custom anonymization profile.
: See [[Capture_module#PCAP_anonymization_profile|PCAP anonymization]] for details.

After pushing the '''Start capture''' button, the capture starts.

=== Webshark ===
The Allegro Nework Multimeter has a preview mode to see the first Megabyte of captured packets directly in the browser. By clicking the Webshark preview button in the capture dialog, the first Megabyte of the requested packets will be extracted. If this is extraction is finished, a modal dialog will open showing the captured packets similar to Wireshark. The capture can be moved from the modal dialog to a separate window by pressing the button in the upper right corner next to the close button.

=== Snort ===
The Allegro Network Multimeter is able to run a Snort analysis on the capture output and display the analysis output in the web browser. To do this, enable the feature in the [https://allegro-packets.com/wiki/Global_settings#Snort_analysis Global settings] and configure it accordingly. The Snort analysis button can be found at the bottom right of the capture modal.

=== Capture URL ===
It is possible to use an external tool like '''curl''' for creating and storing a PCAP.
{| class="wikitable sortable"
|-
| curl -k -u USER:PASSWORD 'https://allegro-mm-XXXX/API/data/modules/capture?startTime=1517306266000000&endTime=1517309267000000&expression=l7Protocol==HTTP&snapPacketLength=65535&fromCaptureBuffer=true' > path_to/capture.pcap
|-
|}
The user name, password and hostname similar to the access of the web interface have to be used.
Following parameters are possible:

* startTime: The start time of the capture. The first packet with exactly this or a later time will start the capture. The time format must be microseconds after January, 1st 1970 UTC (Unix time, epoch). If the start time is in the past, make sure you set fromCaptureBuffer parameter accordingly.
*endTime: The end time of the capture. The first packet with exactly this or a later time will stop the capture. The time format must be microseconds after January, 1st 1970 UTC (Unix time, epoch).
*expression: The filter expression. There are no whitespaces allowed. You may use ‘%20’ instead.
*snapPacketLength: The max size of a packet applied on layer 2 without frame check sequence. If a packet is larger than this value, it is truncated. Use 65535 for unlimited size.
* fromCaptureBuffer: Whether to extract data from the packet ring buffer or just live traffic.
*captureToMedia: Whether to store PCAP on external storage device or download with your browser on your computer.
* useSingleInterface: Whether to store only a single interface in the PCAP and treat all packets as if they arrived on that interface. This may improve compatibility with third party software that cannot handle PCAPs with multiple interfaces IDs.

Global settings

2025-01-29T08:15:51Z

Robert: /* Snort analysis */

The Global settings section contains parameters for adjusting the behavior of the system.
The settings are split among multiple tabs, described as follows.

== Generic settings ==

=== Packet processing mode ===

This section allows for configuring the main packet processing mode:

* '''Bridge mode''': In Bridge mode A.K.A. In-Line mode, all received packets will be transmitted between corresponding port pairs (e.g. 1+2, 3+4 on Allegro 500) so that the Allegro Network Multimeter can be placed in-line between any network component. The device will operate transparent and will not modify network traffic in any way. The additional latency will be typically around or less than 1 millisecond. In Bridge mode it is also possible to process network traffic from a mirror port or Tap. However, "only" half of the total available ports on each respective Allegro Network Multimeter model can be used to operate in this way. For example on a 4-port Allegro model 500, you can conveniently leave the unit in bridge mode and connect up to two mirror ports on interfaces 1 and 3 respectively. Aforementioned interfaces are physically separated and not an (in-line) interface pair. Always avoid connecting mirror port traffic on an Allegro Network Multimeter interface pair (e.g. 1+2, 3+4 on Allegro 500), as this will result in TX traffic in the direction of a mirror port which if highly undesirable. [[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only". Packets are not forwarded and there's no bi-directional traffic on any of the monitoring ports. This operation mode allows for installation at a Mirror port of a Switch or when using a network Tap to access the network traffic. [[File:Sink mode1.jpg|800px|Allegro in Sink mode on Mirror port or Tap]]

* '''Mixed bridge/sink mode:''' This mode enables to configure the packet processing mode for each interface pair. Interface pairs default to Bridge mode but the mode can be permanently changed in the [[interface statistics]].

The packet processing mode can be changed during runtime.

Attention: Please always keep in mind, that while in bridge mode (Allegro Network Multimeter = in-line), a Link will be (shortly) interrupted when switching processing mode or/and rebooting the Allegro Network Multimeter.

=== Endpoint mode ===

If the endpoint mode is enabled for an interface, this interface will only process packets sent to the configured IP address (and potentially the port). If the system is running in bridge packet processing mode, links with an interface configured for endpoint mode will not forward traffic. The following types of traffic are supported:

* Ethernet packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address. 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.
* UDP packets to specific port (packets will be analyzed as is).

An interface with endpoint 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.

It must be noted that if the system is running in bridge packet processing mode, any links with an interface configured for endpoint mode will not forward traffic.

VLAN tag handling is not supported. The Allegro Network Multimeter will accept ARP and ICMP requests with any VLAN tags but will send replies without VLAN tagging.

Note: In versions 3.0 or older, the mode was named "l3 tunnel mode".

=== Webshark support ===

The Allegro Network Multimeter allows having a preview of packets, directly in the browser. This is the so called Webshark. To support Webshark previewing, the Allegro Network Multimeter needs to reserve an amount of system memory.

This reserved amount of memory (RAM) is configurable and will not be available for the In-Memory database, thus the history of stored statistics in the dashboard becomes a little shorter. If this is not desired, it is possible to disable the Webshark support.

Multiple parallel sessions/instances of Webshark previewing within one Allegro Network Multimeter is possible. The number of simultaneous Webshark instances and max. preview file size (e.g. 5MB) are configurable but may vary depending on Allegro model and installed RAM.

Changing Webshark parameters requires a restart of the processing.

[[File:Webshark.jpg|900px|Built in Webshark - Allegro Network Multimeter ]]

=== Snort analysis===
{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}
The Allegro Network Multimeter is able to perform intrusion detection based on the [https://www.snort.org/ Snort] software project. The detection can be performed on live traffic or ring buffer traffic. This analysis is invoked via the capture dialog on any page and respects the same capture filter expressions as a normal traffic capture.
[[File:Snort Analysis Results.png|thumb|Snort Analysis Results]]
This feature is disabled by default, to enable it navigate to Global Settings > Snort Analysis and enable it via the toggle switch. Once enabled a new setting will appear to regulate the allowed memory usage by the intrusion detection. The user is able to set a hard maximum limit on the usable memory, and if the Snort process exceeds this limit it will be killed by the OOM-Manager. Additionally, another soft memory limit will be installed just below the hard maximum, and if the process reaches this limit it will be throttled heavily. If your intrusion analysis appears to get stuck or is unusually slow, a good troubleshooting step is to increase the memory limit. It is generally not recommended to keep the memory limit below 200MB.

When invoking the analysis a new modal will open which displays the results of the analysis. The result modal is a list of detected incidents, sorted by order of appearance. An entry in this list has the following structure:
{| class="wikitable"
|+
!Severity
!Time
!Classification
!Message
!Connection
|-
|This is denoted by the color on the left hand side of the row.
|The packet timestamp of the offending packet.
|A normalized name for the type of incident that occured.
|A more detailed description of the incident
|A diagram of the connection in which the incident occured. The IPs can be clicked to go to the IP detail page, and on the right there is an "external link" icon that opens the connection details page in a new tab.
|}
Additionally, on the right hand side of the modal is another color band that serves as a rough overview over all incidents. The band is static and roughly aligned with the scroll bar to make it easier to navigate to specific severity incidents.

Snort works by reading a rule file which contains a list of rules used to match packets against. These rules can match subnet, direction, protocol, payload contents, and more (see the Snort documentation for more information on rules), and are given a classification, message and priority, which are displayed in the analysis results. Internally this feature uses a community rule set which is available for free and receives periodic updates. '''Note:''' The Allegro Network Multimeter (currently) does NOT automatically update this rule set. We are deploying the same rule set to all devices independent of the date of installation. Thus the analysis may not be able to detect zero day exploits and should not be relied on when trying to detect recently discovered attack vectors.

At the moment, only critical and severe incidents are reported (Snort priorities 0 and 1). The classification and message strings are taken directly from the rule that triggered this incidents.

===Detail of traffic analysis===

Limit module processing, allows you to configure which OSI-layers (2,3,4,7) are actively processed and analyzed by the Allegro Network Multimeter. With this setting, the performance of the Allegro Network Multimeter can be significantly improved and allows for higher throughput when disabling some analysis modules.

For both realtime and offline parallel analysis, the following modes are possible :

*Only capturing: Only interface statistics and the capture module is provided. Capture filters are supported without Layer 7 protocol specification/recognition.
*Capturing and protocol detection: Additionally Layer 7 protocol specification in Capture filters will now work.
*Up to Layer 2: Additionally all Layer 2 related modules are active such as MAC, MAC protocols, ARP and Burst Analysis.
*Up to Layer 3: Additionally all Layer 3 related modules are active such as IP and DHCP statistics.
*Up to Layer 4: Additionally all Layer 4 related modules are active such as TCP and Layer 4 server ports.
*Unlimited: All Allegro Network Multimeter modules are active.

When switching to another mode you need to restart the processing in order to activate the new settings.

NOTE: The data recorded to/stored in the Packet Ring buffer, will NOT be affected by any of the above settings. Packet ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter

====Enable single flow load balancing====
When the ''Limit module processing'' slider is turned to ''Only capturing'' the option to enable ''single flow load balancing'' appears. If this option is enabled, even a single flow is load-balanced to different analyzer threads.

This is only recommended when there are very few flows and there is an imbalance in the load of the analyzers. As the packets of a single flow are processed by different analyzers the packets of the flow may be stored out-of-order in the Packet Ring Buffer and a larger amount of memory may be required to reorder the packets when capturing from the Packet Ring Buffer (see [[Capture module#Configuration settings|Capture module]] configuration settings).

===Graph detail settings===

It is possible to modify the detail level of all graphs in the interface. This settings allow you to see a more detailed view (with higher time resolution) or to reduce the detail level so more data can be stored on the device. Changing the default values has an impact on the performance and memory usage. Changing a slider to the left increases the detail level of graphs, but increases memory usage and decreases performance.

*Best graph resolution: This option configures how detailed the graph information are shown in the best case (the latest information). The default value is one second which means that a graph sample point represents a second of packet time. You can change the resolution up to 1 millisecond which gives a detailed sub-second representation of the traffic. You can also decide to decrease the resolution which enables the Allegro Network Multimeter to store more data for a longer period of time.

*Reduce graph resolution of old data by up to: The resolution of older graph data is automatically reduced to save memory and to allow a longer view into the traffic history. This option allows you to change this behaviour. With a reduction factor of 1/1 no reduction is done at all which means the selected graph resolution is available for the complete time.
:This reduces the time period to see historical data. You can choose to increase the reduction factor to store more data for a longer period. The time printed in parentheses represents the worst-case graph resolution based on the chosen resolution and reduction factor. The reduction is done in multiple steps up to this limit. The newest data always has the highest resolution defined by the "Best graph resolution" setting above. Between 60 and 120 data points are stored at a minimum, so with default resolution of 1 second, between one and two minutes are available in the highest resolution. Due to internal compression, the exact number of data points cannot be foreseen but 60 data points are always available at least, usually much more. Once the limit is reached, data is reduced by a factor of two thus doubling the amount of time available in half resolution (2 to 4 minutes in 2 second resolution). When the next limit is reached, the data is halved again thus doubling the time again, until the configured reduction limit is reached. With default settings of one second resolution and reduction limit of 1/6, the worst resolution of 64 seconds (or 1 minute and 4 seconds) is reached not before 2 hours into the past. The drop down menu in graph view gives an exact number about the available graph resolution in the given time period.

Note: Regardless of these settings, the graph values are always converted to represent a value per second (when applicable). For example, the packets per second for an IP addresses will always be a value literally per second even if the resolution is larger or smaller than one second. The displayed value is scaled to match this view. Especially with sub-second resolution this might be misleading.

For instance, if there is a network element sending one packet per second and the resolution is set to 100 milliseconds, the value shown in the graph might be shown as 10 packets per second as each sample point is scaled to represent an value per second. For a detailed investigation it is recommended to always select a specific time interval and look at the (packet) counters shown in all statistics since these are unscaled and represent the actual values.

Performance implications: The performance degradation and memory usage depends on the actual network traffic and is not exactly predictable.

Here are some examples for reference on a Allegro 1000 series with different configuration values (under ideal test conditions):

* 1 second resolution, 1/1 reduction factor: 90% of default performance
*100 millisecond resolution, 1/1 reduction factor: 50% of default performance,
*10 millisecond resolution, 1/1 reduction factor: 15% of default performance
*1 millisecond resolution, 1/1 reduction factor: 10% of default performance

=== PCAP parallel analysis===

The PCAP parallel analysis feature allows to analyse PCAP files or the
packet ring buffer in parallel to the live measurement. The settings
allow to enable the feature and choose how much memory of the main
memory is used for parallel analysis and how many parallel slots can
be used. Detailed description of the configuration values are
described [[parallel packet processing|here]].

==IPFIX settings ==

The Allegro Network Multimeter may be running as an IPFIX exporter. These settings allows for reporting configuration. When enabled, the following settings are possible:

*IP address: Address of IPFIX collector.
*Port: Corresponding port.
*Protocol: TCP or UDP.
*Update interval: Interval in seconds for sending a status update of flows.
*UDP resend interval: Interval in seconds for resending IPFIX templates for UDP connections.
* TCP reconnect timeout: When TCP connections could not be established, wait for this time period until the next attempt to establish a connection.

Individual IPFIX messages can be enabled or disabled by toggling corresponding options. See the NetFlow/IPFIX interface documentation for details about the message types.

==Time settings==

The Time settings were moved to [[Administration]].

== Email notification==

The Email notification settings were moved to [[Administration]].

==DB persistance (BETA) ==
See [[DB persistence]] for details about this feature.

==Longterm DB (BETA)==
See [[Longterm DB]] for details about this feature.

== Expert settings==

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

===Packet length accounting===

This setting allows you to configure which packet length is used for all traffic counters and incidents. The 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 Bytes)
*Layer 2 without frame check sequence (default): Packet length is accounted on Layer 2 without a frame check sequence (4 Bytes)
*Layer 2 with frame check sequence: Account packet length on Layer 2 with frame check sequence (4 Bytes) When switching to another mode, it will only be applied on new packets. Older packet size statistics will not be changed.

===VLAN handling ===

The Allegro Network Multimeter can '''ignore VLAN tags''' for connection tracking. Enabling this option may be necessary if network traffic is seen on the Allegro Network Multimeter that contains changing VLAN tags for the same connection. For example, depending on the configuration of the Mirror Port to which the Allegro Network Multimeter is connected, incoming traffic could contain a VLAN tag while outgoing traffic does not. In this example, a connection would appear twice in the statistics which often is desired behaviour to be able to identify a network misconfiguration. In some cases however, such "duplicate" data in the dashboard may be misleading, and the user would want to see only one connection. In these scenarios the option ignore VLAN tags may be enabled.

===Tunnel view mode===

The Allegro Network Multimeter can decapsulate GRE, VXLAN, ERSPAN type II and type III, GENEVE, CAPWAP as well as L2TPv3 data traffic. Depending on this option either the outer tunnel or the inner content is shown in all analysis modules.

There are three possible modes:

* don't decapsulate traffic (default)
*decapsulate tunnel traffic, discard non-encapsulated traffic
*decapsulate tunnel traffic, process also non-encapsulated traffic

Optionally, a filter can be set to limit decapsulation on specific packets with a certain IP address, IP ranges or interfaces. If the filter is empty, all packets will be decapsulated.

In case the mode is active with discarding non-encapsulated traffic, on the Dashboard a dropped counter will display dropped non-encapsulated packets.

When capturing, packets with complete outer Layer 2, Layer 3, GRE, ERSPAN, GENEVE, CAPWAP and L2TPv3 headers will be stored as seen on the wire.

===Database mode settings===

The database mode is a special analysis mode for high-performance Allegro Network Multimeters with multiple processors to increase the performance on such systems. It is normally enabled automatically but depending on the actual network traffic and system usage, some parameter tweak might be necessary to improve overall system performance.
You should only change these parameters in discussion with the Allegro Packets support department.
These settings are only visible if your Allegro Network Multimeter is capable of running this mode.

You can read more about the meaning of the settings [[DB mode|here]].

===Network performance ===

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

*Max RX queues per socket: This setting specifies the quantity 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 since 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 since 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 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 department.

===Processing performance===

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

*Processing performance mode: This setting allows for fine tuning processing performance. By using '''Analysing''', as much processing ressources on all CPUs as possible are used for data analysis. By using '''Capturing''', the focus will be on high data throughput and low latency for capturing purposes by using only the CPU where the preferred network controller is attached to. This has an impact on data analysis performance. '''Analysing''' is used by default.
You should only change this parameter in discussion with the Allegro Packets support department.

===Packet ring buffer timeouts===

Two timeout settings related to the packet ring buffer can be adjusted.

*'''Long timeout''' controls after which maximum amount 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 order in the packet ring buffer but it may increase the amount of unused overhead data in the packet ring buffer.
*'''Short timeout''' controls after which amount 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 order in the packet ring buffer, but it may also decrease the performance of the packet ring buffer.

===Data retention timeout===

When the data retention timeout is set to a value greater than 0, data will be removed everywhere throughout 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.

===Multithreaded capture analysis ===

This option enables the use of multiple CPUs for capture analysis like when
analyzing a pcap capture file or analyzing the packet ring buffer. Depending
on the number of available CPUs this can significantly speed up the analysis.

It is possible to dedicate a number of CPUs exclusively to capture analysis.
Since these CPUs are not available for live packet processing the performance of
live traffic analysis may be lower.
When set to 0 a lower priority is used for capture analysis than for live analysis
but it cannot be ruled out that the performance of the live processing is
affected.

===Load balancing===

This option select the load distribution method. By default, network
traffic is balanced among all processing threads based on the IP
addresses. This is fast and usually the best way for efficient load
balancing.

If the network traffic only occurs between a few IP addresses, this
method can lead to a load imbalance so that some threads are doing more
work while other threads may be idle. In this scenario, "flow based
balancing" can be enabled to distribute the traffic based on the IP
and port information. This will lead to better utilization of all
processing threads.

Since this option induces additional processing overhead per packet
and additional memory for all internal IP statistics, it should only
be enabled in cases of significant load imbalance.

===Ingress packet memory===

This slider allows to configure the amount of memory which is used to buffer received packets. A larger amount of ingress packet memory may help in processing bursts of high bandwidth traffic without packet drops but it also decreases the amount of memory available for statistics. It is important to know that a restart of the processing does not suffice to make changes to this setting active. A full reboot of the device is required for that. See [[Performance Optimization Guide]].

===Jumbo frame mode===
This options allows to set how jumbo frames are handled by the system.

Three settings are available and the '''normal''' mode, which is also the default, is the mode that was used before this configuration option was introduced:

*'''Normal''': the default mode offers the best balance of full support for jumbo frames with an efficient usage of the ingress packet memory. This mode uses efficiently sized packet buffers and splits larger packets over multiple packet buffers.
*'''Large buffers''': this mode uses a single large buffer for each packet which may improve the performance but does not use the ingress packet memory as efficiently and limits the maximum jumbo frame size to 9kB.
*'''Disabled''': this mode disables support for jumbo frames and offers the best performance and efficient usage of the ingress packet memory. Jumbo frames will be discarded by the network interface.

===Hardware packet timestamping===
This option allows to enable the use of high-precision hardware packet timestamps on supported interfaces. If an interface is supported, it has the “Hardware Timestamps” feature in the interface statistics (firmware >= 4.4).

This feature will require approximately 30% more load in the I/O threads. The load increase can be reduced to about 10% by using the jumbo frame mode "Large buffers" or "Disabled".

When enabled, packets received on supported interfaces will carry a timestamp with nanosecond resolution instead of microsecond resolution.

===External timestamps===
When this option is enabled, the system will use timestamps contained in the packet data instead of timestamps measured at packet arrival. Currently the Arista and Ixia/Keysight as well as the SRCMAC timestamp formats are supported.

If the Ixia/Keysight or Arista type is selected, packets without an external timestamp will not be analyzed. The current number of packets that are dropped because they do not contain an external timestamp is displayed in the active interface overview table of the top-user dashboard. If there are no packets with external timestamps arriving the time of the packet processing will effectively stand still and most graphs will not make progress in live-mode.

If one of the SRCMAC options is selected, all packets will be analyzed with all-zero MAC addresses.

=== External original packet lengths ===
This option allows to enable the use of original packet length information contained in the packet data instead of the length of the packet as received. At this time only the Ixia/Keysight original packet length trailer format is supported.

This feature can also be used in combination with the ''External timestamps'' option to support packets that contain a Ixia/Keysight trailer with both timestamp and original length information.

===Memory utilization limit===
This option allows to reduce the limit until old data is removed from the in-memory database. By default the system tries to target 90% memory utilization. In some case, the load might be too high to match this limit. A smaller limit may enable the system to keep the target memory utilization and perform better in general.

Global settings

2024-10-24T08:35:46Z

Robert: change warning box text

The Global settings section contains parameters for adjusting the behavior of the system.
The settings are split among multiple tabs, described as follows.

== Generic settings ==

=== Packet processing mode ===

This section allows for configuring the main packet processing mode:

* '''Bridge mode''': In Bridge mode A.K.A. In-Line mode, all received packets will be transmitted between corresponding port pairs (e.g. 1+2, 3+4 on Allegro 500) so that the Allegro Network Multimeter can be placed in-line between any network component. The device will operate transparent and will not modify network traffic in any way. The additional latency will be typically around or less than 1 millisecond. In Bridge mode it is also possible to process network traffic from a mirror port or Tap. However, "only" half of the total available ports on each respective Allegro Network Multimeter model can be used to operate in this way. For example on a 4-port Allegro model 500, you can conveniently leave the unit in bridge mode and connect up to two mirror ports on interfaces 1 and 3 respectively. Aforementioned interfaces are physically separated and not an (in-line) interface pair. Always avoid connecting mirror port traffic on an Allegro Network Multimeter interface pair (e.g. 1+2, 3+4 on Allegro 500), as this will result in TX traffic in the direction of a mirror port which if highly undesirable. [[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only". Packets are not forwarded and there's no bi-directional traffic on any of the monitoring ports. This operation mode allows for installation at a Mirror port of a Switch or when using a network Tap to access the network traffic. [[File:Sink mode1.jpg|800px|Allegro in Sink mode on Mirror port or Tap]]

* '''Mixed bridge/sink mode:''' This mode enables to configure the packet processing mode for each interface pair. Interface pairs default to Bridge mode but the mode can be permanently changed in the [[interface statistics]].

The packet processing mode can be changed during runtime.

Attention: Please always keep in mind, that while in bridge mode (Allegro Network Multimeter = in-line), a Link will be (shortly) interrupted when switching processing mode or/and rebooting the Allegro Network Multimeter.

=== Endpoint mode ===

If the endpoint mode is enabled for an interface, this interface will only process packets sent to the configured IP address (and potentially the port). If the system is running in bridge packet processing mode, links with an interface configured for endpoint mode will not forward traffic. The following types of traffic are supported:

* Ethernet packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address. 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.
* UDP packets to specific port (packets will be analyzed as is).

An interface with endpoint 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.

It must be noted that if the system is running in bridge packet processing mode, any links with an interface configured for endpoint mode will not forward traffic.

VLAN tag handling is not supported. The Allegro Network Multimeter will accept ARP and ICMP requests with any VLAN tags but will send replies without VLAN tagging.

Note: In versions 3.0 or older, the mode was named "l3 tunnel mode".

=== Webshark support ===

The Allegro Network Multimeter allows having a preview of packets, directly in the browser. This is the so called Webshark. To support Webshark previewing, the Allegro Network Multimeter needs to reserve an amount of system memory.

This reserved amount of memory (RAM) is configurable and will not be available for the In-Memory database, thus the history of stored statistics in the dashboard becomes a little shorter. If this is not desired, it is possible to disable the Webshark support.

Multiple parallel sessions/instances of Webshark previewing within one Allegro Network Multimeter is possible. The number of simultaneous Webshark instances and max. preview file size (e.g. 5MB) are configurable but may vary depending on Allegro model and installed RAM.

Changing Webshark parameters requires a restart of the processing.

[[File:Webshark.jpg|900px|Built in Webshark - Allegro Network Multimeter ]]

=== Snort analysis===
{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. There may be bugs or unexpected behavior when using this feature.}}
The Allegro Network Multimeter is able to perform intrusion detection based on the [https://www.snort.org/ Snort] software project. The detection can be performed on live traffic or ring buffer traffic. This analysis is invoked via the capture dialog on any page and respects the same capture filter expressions as a normal traffic capture.
[[File:Snort Analysis Results.png|thumb|Snort Analysis Results]]
This feature is disabled by default, to enable it navigate to Global Settings > Snort Analysis and enable it via the toggle switch. Once enabled a new setting will appear to regulate the allowed memory usage by the intrusion detection. The user is able to set a hard maximum limit on the usable memory, and if the Snort process exceeds this limit it will be killed by the OOM-Manager. Additionally, another soft memory limit will be installed just below the hard maximum, and if the process reaches this limit it will be throttled heavily. If your intrusion analysis appears to get stuck or is unusually slow, a good troubleshooting step is to increase the memory limit. It is generally not recommended to keep the memory limit above around 200MB.

When invoking the analysis a new modal will open which displays the results of the analysis. The result modal is a list of detected incidents, sorted by order of appearance. An entry in this list has the following structure:
{| class="wikitable"
|+
!Severity
!Time
!Classification
!Message
!Connection
|-
|This is denoted by the color on the left hand side of the row.
|The packet timestamp of the offending packet.
|A normalized name for the type of incident that occured.
|A more detailed description of the incident
|A diagram of the connection in which the incident occured. The IPs can be clicked to go to the IP detail page, and on the right there is an "external link" icon that opens the connection details page in a new tab.
|}
Additionally, on the right hand side of the modal is another color band that serves as a rough overview over all incidents. The band is static and roughly aligned with the scroll bar to make it easier to navigate to specific severity incidents.

Snort works by reading a rule file which contains a list of rules used to match packets against. These rules can match subnet, direction, protocol, payload contents, and more (see the Snort documentation for more information on rules), and are given a classification, message and priority, which are displayed in the analysis results. Internally this feature uses a community rule set which is available for free and receives periodic updates. '''Note:''' The Allegro Network Multimeter does NOT automatically update this rule set. We are deploying the same rule set to all devices independent of the date of installation. Thus the analysis may not be able to detect zero day exploits and should not be relied on when trying to detect recently discovered attack vectors.

At the moment, only critical and severe incidents are reported (Snort priorities 0 and 1). The classification and message strings are taken directly from the rule that triggered this incidents.

===Detail of traffic analysis===

Limit module processing, allows you to configure which OSI-layers (2,3,4,7) are actively processed and analyzed by the Allegro Network Multimeter. With this setting, the performance of the Allegro Network Multimeter can be significantly improved and allows for higher throughput when disabling some analysis modules.

For both realtime and offline parallel analysis, the following modes are possible :

*Only capturing: Only interface statistics and the capture module is provided. Capture filters are supported without Layer 7 protocol specification/recognition.
*Capturing and protocol detection: Additionally Layer 7 protocol specification in Capture filters will now work.
*Up to Layer 2: Additionally all Layer 2 related modules are active such as MAC, MAC protocols, ARP and Burst Analysis.
*Up to Layer 3: Additionally all Layer 3 related modules are active such as IP and DHCP statistics.
*Up to Layer 4: Additionally all Layer 4 related modules are active such as TCP and Layer 4 server ports.
*Unlimited: All Allegro Network Multimeter modules are active.

When switching to another mode you need to restart the processing in order to activate the new settings.

NOTE: The data recorded to/stored in the Packet Ring buffer, will NOT be affected by any of the above settings. Packet ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter

====Enable single flow load balancing====
When the ''Limit module processing'' slider is turned to ''Only capturing'' the option to enable ''single flow load balancing'' appears. If this option is enabled, even a single flow is load-balanced to different analyzer threads.

This is only recommended when there are very few flows and there is an imbalance in the load of the analyzers. As the packets of a single flow are processed by different analyzers the packets of the flow may be stored out-of-order in the Packet Ring Buffer and a larger amount of memory may be required to reorder the packets when capturing from the Packet Ring Buffer (see [[Capture module#Configuration settings|Capture module]] configuration settings).

===Graph detail settings===

It is possible to modify the detail level of all graphs in the interface. This settings allow you to see a more detailed view (with higher time resolution) or to reduce the detail level so more data can be stored on the device. Changing the default values has an impact on the performance and memory usage. Changing a slider to the left increases the detail level of graphs, but increases memory usage and decreases performance.

*Best graph resolution: This option configures how detailed the graph information are shown in the best case (the latest information). The default value is one second which means that a graph sample point represents a second of packet time. You can change the resolution up to 1 millisecond which gives a detailed sub-second representation of the traffic. You can also decide to decrease the resolution which enables the Allegro Network Multimeter to store more data for a longer period of time.

*Reduce graph resolution of old data by up to: The resolution of older graph data is automatically reduced to save memory and to allow a longer view into the traffic history. This option allows you to change this behaviour. With a reduction factor of 1/1 no reduction is done at all which means the selected graph resolution is available for the complete time.
:This reduces the time period to see historical data. You can choose to increase the reduction factor to store more data for a longer period. The time printed in parentheses represents the worst-case graph resolution based on the chosen resolution and reduction factor. The reduction is done in multiple steps up to this limit. The newest data always has the highest resolution defined by the "Best graph resolution" setting above. Between 60 and 120 data points are stored at a minimum, so with default resolution of 1 second, between one and two minutes are available in the highest resolution. Due to internal compression, the exact number of data points cannot be foreseen but 60 data points are always available at least, usually much more. Once the limit is reached, data is reduced by a factor of two thus doubling the amount of time available in half resolution (2 to 4 minutes in 2 second resolution). When the next limit is reached, the data is halved again thus doubling the time again, until the configured reduction limit is reached. With default settings of one second resolution and reduction limit of 1/6, the worst resolution of 64 seconds (or 1 minute and 4 seconds) is reached not before 2 hours into the past. The drop down menu in graph view gives an exact number about the available graph resolution in the given time period.

Note: Regardless of these settings, the graph values are always converted to represent a value per second (when applicable). For example, the packets per second for an IP addresses will always be a value literally per second even if the resolution is larger or smaller than one second. The displayed value is scaled to match this view. Especially with sub-second resolution this might be misleading.

For instance, if there is a network element sending one packet per second and the resolution is set to 100 milliseconds, the value shown in the graph might be shown as 10 packets per second as each sample point is scaled to represent an value per second. For a detailed investigation it is recommended to always select a specific time interval and look at the (packet) counters shown in all statistics since these are unscaled and represent the actual values.

Performance implications: The performance degradation and memory usage depends on the actual network traffic and is not exactly predictable.

Here are some examples for reference on a Allegro 1000 series with different configuration values (under ideal test conditions):

* 1 second resolution, 1/1 reduction factor: 90% of default performance
*100 millisecond resolution, 1/1 reduction factor: 50% of default performance,
*10 millisecond resolution, 1/1 reduction factor: 15% of default performance
*1 millisecond resolution, 1/1 reduction factor: 10% of default performance

=== PCAP parallel analysis===

The PCAP parallel analysis feature allows to analyse PCAP files or the
packet ring buffer in parallel to the live measurement. The settings
allow to enable the feature and choose how much memory of the main
memory is used for parallel analysis and how many parallel slots can
be used. Detailed description of the configuration values are
described [[parallel packet processing|here]].

==IPFIX settings ==

The Allegro Network Multimeter may be running as an IPFIX exporter. These settings allows for reporting configuration. When enabled, the following settings are possible:

*IP address: Address of IPFIX collector.
*Port: Corresponding port.
*Protocol: TCP or UDP.
*Update interval: Interval in seconds for sending a status update of flows.
*UDP resend interval: Interval in seconds for resending IPFIX templates for UDP connections.
* TCP reconnect timeout: When TCP connections could not be established, wait for this time period until the next attempt to establish a connection.

Individual IPFIX messages can be enabled or disabled by toggling corresponding options. See the NetFlow/IPFIX interface documentation for details about the message types.

==Time settings==

The Time settings were moved to [[Administration]].

== Email notification==

The Email notification settings were moved to [[Administration]].

==Memory extension (BETA)==

See [[Memory extension]] for details about this beta feature.

==DB persistance (BETA) ==
See [[DB persistence]] for details about this feature.

==Longterm DB (BETA)==
See [[Longterm DB]] for details about this feature.

== Expert settings==

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

===Packet length accounting===

This setting allows you to configure which packet length is used for all traffic counters and incidents. The 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 Bytes)
*Layer 2 without frame check sequence (default): Packet length is accounted on Layer 2 without a frame check sequence (4 Bytes)
*Layer 2 with frame check sequence: Account packet length on Layer 2 with frame check sequence (4 Bytes) When switching to another mode, it will only be applied on new packets. Older packet size statistics will not be changed.

===VLAN handling ===

The Allegro Network Multimeter can '''ignore VLAN tags''' for connection tracking. Enabling this option may be necessary if network traffic is seen on the Allegro Network Multimeter that contains changing VLAN tags for the same connection. For example, depending on the configuration of the Mirror Port to which the Allegro Network Multimeter is connected, incoming traffic could contain a VLAN tag while outgoing traffic does not. In this example, a connection would appear twice in the statistics which often is desired behaviour to be able to identify a network misconfiguration. In some cases however, such "duplicate" data in the dashboard may be misleading, and the user would want to see only one connection. In these scenarios the option ignore VLAN tags may be enabled.

===Tunnel view mode===

The Allegro Network Multimeter can decapsulate GRE, VXLAN, ERSPAN type II and type III, GENEVE, CAPWAP as well as L2TPv3 data traffic. Depending on this option either the outer tunnel or the inner content is shown in all analysis modules.

There are three possible modes:

* don't decapsulate traffic (default)
*decapsulate tunnel traffic, discard non-encapsulated traffic
*decapsulate tunnel traffic, process also non-encapsulated traffic

Optionally, a filter can be set to limit decapsulation on specific packets with a certain IP address, IP ranges or interfaces. If the filter is empty, all packets will be decapsulated.

In case the mode is active with discarding non-encapsulated traffic, on the Dashboard a dropped counter will display dropped non-encapsulated packets.

When capturing, packets with complete outer Layer 2, Layer 3, GRE, ERSPAN, GENEVE, CAPWAP and L2TPv3 headers will be stored as seen on the wire.

===Database mode settings===

The database mode is a special analysis mode for high-performance Allegro Network Multimeters with multiple processors to increase the performance on such systems. It is normally enabled automatically but depending on the actual network traffic and system usage, some parameter tweak might be necessary to improve overall system performance.
You should only change these parameters in discussion with the Allegro Packets support department.
These settings are only visible if your Allegro Network Multimeter is capable of running this mode.

You can read more about the meaning of the settings [[DB mode|here]].

===Network performance ===

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

*Max RX queues per socket: This setting specifies the quantity 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 since 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 since 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 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 department.

===Processing performance===

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

*Processing performance mode: This setting allows for fine tuning processing performance. By using '''Analysing''', as much processing ressources on all CPUs as possible are used for data analysis. By using '''Capturing''', the focus will be on high data throughput and low latency for capturing purposes by using only the CPU where the preferred network controller is attached to. This has an impact on data analysis performance. '''Analysing''' is used by default.
You should only change this parameter in discussion with the Allegro Packets support department.

===Packet ring buffer timeouts===

Two timeout settings related to the packet ring buffer can be adjusted.

*'''Long timeout''' controls after which maximum amount 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 order in the packet ring buffer but it may increase the amount of unused overhead data in the packet ring buffer.
*'''Short timeout''' controls after which amount 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 order in the packet ring buffer, but it may also decrease the performance of the packet ring buffer.

===Data retention timeout===

When the data retention timeout is set to a value greater than 0, data will be removed everywhere throughout 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.

===Multithreaded capture analysis ===

This option enables the use of multiple CPUs for capture analysis like when
analyzing a pcap capture file or analyzing the packet ring buffer. Depending
on the number of available CPUs this can significantly speed up the analysis.

It is possible to dedicate a number of CPUs exclusively to capture analysis.
Since these CPUs are not available for live packet processing the performance of
live traffic analysis may be lower.
When set to 0 a lower priority is used for capture analysis than for live analysis
but it cannot be ruled out that the performance of the live processing is
affected.

===Load balancing===

This option select the load distribution method. By default, network
traffic is balanced among all processing threads based on the IP
addresses. This is fast and usually the best way for efficient load
balancing.

If the network traffic only occurs between a few IP addresses, this
method can lead to a load imbalance so that some threads are doing more
work while other threads may be idle. In this scenario, "flow based
balancing" can be enabled to distribute the traffic based on the IP
and port information. This will lead to better utilization of all
processing threads.

Since this option induces additional processing overhead per packet
and additional memory for all internal IP statistics, it should only
be enabled in cases of significant load imbalance.

===Ingress packet memory===

This slider allows to configure the amount of memory which is used to buffer received packets. A larger amount of ingress packet memory may help in processing bursts of high bandwidth traffic without packet drops but it also decreases the amount of memory available for statistics. It is important to know that a restart of the processing does not suffice to make changes to this setting active. A full reboot of the device is required for that. See [[Performance Optimization Guide]].

===Jumbo frame mode===
This options allows to set how jumbo frames are handled by the system.

Three settings are available and the '''normal''' mode, which is also the default, is the mode that was used before this configuration option was introduced:

*'''Normal''': the default mode offers the best balance of full support for jumbo frames with an efficient usage of the ingress packet memory. This mode uses efficiently sized packet buffers and splits larger packets over multiple packet buffers.
*'''Large buffers''': this mode uses a single large buffer for each packet which may improve the performance but does not use the ingress packet memory as efficiently and limits the maximum jumbo frame size to 9kB.
*'''Disabled''': this mode disables support for jumbo frames and offers the best performance and efficient usage of the ingress packet memory. Jumbo frames will be discarded by the network interface.

===Hardware packet timestamping===
This option allows to enable the use of high-precision hardware packet timestamps on supported interfaces (quad 25G and dual 100G expansion).

This feature will require approximately 30% more load in the I/O threads. The load increase can be reduced to about 10% by using the jumbo frame mode "Large buffers" or "Disabled".

When enabled, packets received on supported interfaces will carry a timestamp with nanosecond resolution instead of microsecond resolution.

===External timestamps===
When this option is enabled, the system will use timestamps contained in the packet data instead of timestamps measured at packet arrival. Currently the Arista and Ixia/Keysight as well as the SRCMAC timestamp formats are supported.

If the Ixia/Keysight or Arista type is selected, packets without an external timestamp will not be analyzed. The current number of packets that are dropped because they do not contain an external timestamp is displayed in the active interface overview table of the top-user dashboard. If there are no packets with external timestamps arriving the time of the packet processing will effectively stand still and most graphs will not make progress in live-mode.

If one of the SRCMAC options is selected, all packets will be analyzed with all-zero MAC addresses.

=== External original packet lengths ===
This option allows to enable the use of original packet length information contained in the packet data instead of the length of the packet as received. At this time only the Ixia/Keysight original packet length trailer format is supported.

This feature can also be used in combination with the ''External timestamps'' option to support packets that contain a Ixia/Keysight trailer with both timestamp and original length information.

===Memory utilization limit===
This option allows to reduce the limit until old data is removed from the in-memory database. By default the system tries to target 90% memory utilization. In some case, the load might be too high to match this limit. A smaller limit may enable the system to keep the target memory utilization and perform better in general.

Global settings

2024-10-24T08:34:37Z

Robert: Add snort analysis setting explanation

The Global settings section contains parameters for adjusting the behavior of the system.
The settings are split among multiple tabs, described as follows.

== Generic settings ==

=== Packet processing mode ===

This section allows for configuring the main packet processing mode:

* '''Bridge mode''': In Bridge mode A.K.A. In-Line mode, all received packets will be transmitted between corresponding port pairs (e.g. 1+2, 3+4 on Allegro 500) so that the Allegro Network Multimeter can be placed in-line between any network component. The device will operate transparent and will not modify network traffic in any way. The additional latency will be typically around or less than 1 millisecond. In Bridge mode it is also possible to process network traffic from a mirror port or Tap. However, "only" half of the total available ports on each respective Allegro Network Multimeter model can be used to operate in this way. For example on a 4-port Allegro model 500, you can conveniently leave the unit in bridge mode and connect up to two mirror ports on interfaces 1 and 3 respectively. Aforementioned interfaces are physically separated and not an (in-line) interface pair. Always avoid connecting mirror port traffic on an Allegro Network Multimeter interface pair (e.g. 1+2, 3+4 on Allegro 500), as this will result in TX traffic in the direction of a mirror port which if highly undesirable. [[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only". Packets are not forwarded and there's no bi-directional traffic on any of the monitoring ports. This operation mode allows for installation at a Mirror port of a Switch or when using a network Tap to access the network traffic. [[File:Sink mode1.jpg|800px|Allegro in Sink mode on Mirror port or Tap]]

* '''Mixed bridge/sink mode:''' This mode enables to configure the packet processing mode for each interface pair. Interface pairs default to Bridge mode but the mode can be permanently changed in the [[interface statistics]].

The packet processing mode can be changed during runtime.

Attention: Please always keep in mind, that while in bridge mode (Allegro Network Multimeter = in-line), a Link will be (shortly) interrupted when switching processing mode or/and rebooting the Allegro Network Multimeter.

=== Endpoint mode ===

If the endpoint mode is enabled for an interface, this interface will only process packets sent to the configured IP address (and potentially the port). If the system is running in bridge packet processing mode, links with an interface configured for endpoint mode will not forward traffic. The following types of traffic are supported:

* Ethernet packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address. 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.
* UDP packets to specific port (packets will be analyzed as is).

An interface with endpoint 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.

It must be noted that if the system is running in bridge packet processing mode, any links with an interface configured for endpoint mode will not forward traffic.

VLAN tag handling is not supported. The Allegro Network Multimeter will accept ARP and ICMP requests with any VLAN tags but will send replies without VLAN tagging.

Note: In versions 3.0 or older, the mode was named "l3 tunnel mode".

=== Webshark support ===

The Allegro Network Multimeter allows having a preview of packets, directly in the browser. This is the so called Webshark. To support Webshark previewing, the Allegro Network Multimeter needs to reserve an amount of system memory.

This reserved amount of memory (RAM) is configurable and will not be available for the In-Memory database, thus the history of stored statistics in the dashboard becomes a little shorter. If this is not desired, it is possible to disable the Webshark support.

Multiple parallel sessions/instances of Webshark previewing within one Allegro Network Multimeter is possible. The number of simultaneous Webshark instances and max. preview file size (e.g. 5MB) are configurable but may vary depending on Allegro model and installed RAM.

Changing Webshark parameters requires a restart of the processing.

[[File:Webshark.jpg|900px|Built in Webshark - Allegro Network Multimeter ]]

=== Snort analysis===
{{Warning|title=Beta Feature|This feature is still in active development and is therefore subject to changes in the future. If you encounter issues or bugs using this feature please report them to our support.}}
The Allegro Network Multimeter is able to perform intrusion detection based on the [https://www.snort.org/ Snort] software project. The detection can be performed on live traffic or ring buffer traffic. This analysis is invoked via the capture dialog on any page and respects the same capture filter expressions as a normal traffic capture.
[[File:Snort Analysis Results.png|thumb|Snort Analysis Results]]
This feature is disabled by default, to enable it navigate to Global Settings > Snort Analysis and enable it via the toggle switch. Once enabled a new setting will appear to regulate the allowed memory usage by the intrusion detection. The user is able to set a hard maximum limit on the usable memory, and if the Snort process exceeds this limit it will be killed by the OOM-Manager. Additionally, another soft memory limit will be installed just below the hard maximum, and if the process reaches this limit it will be throttled heavily. If your intrusion analysis appears to get stuck or is unusually slow, a good troubleshooting step is to increase the memory limit. It is generally not recommended to keep the memory limit above around 200MB.

When invoking the analysis a new modal will open which displays the results of the analysis. The result modal is a list of detected incidents, sorted by order of appearance. An entry in this list has the following structure:
{| class="wikitable"
|+
!Severity
!Time
!Classification
!Message
!Connection
|-
|This is denoted by the color on the left hand side of the row.
|The packet timestamp of the offending packet.
|A normalized name for the type of incident that occured.
|A more detailed description of the incident
|A diagram of the connection in which the incident occured. The IPs can be clicked to go to the IP detail page, and on the right there is an "external link" icon that opens the connection details page in a new tab.
|}
Additionally, on the right hand side of the modal is another color band that serves as a rough overview over all incidents. The band is static and roughly aligned with the scroll bar to make it easier to navigate to specific severity incidents.

Snort works by reading a rule file which contains a list of rules used to match packets against. These rules can match subnet, direction, protocol, payload contents, and more (see the Snort documentation for more information on rules), and are given a classification, message and priority, which are displayed in the analysis results. Internally this feature uses a community rule set which is available for free and receives periodic updates. '''Note:''' The Allegro Network Multimeter does NOT automatically update this rule set. We are deploying the same rule set to all devices independent of the date of installation. Thus the analysis may not be able to detect zero day exploits and should not be relied on when trying to detect recently discovered attack vectors.

At the moment, only critical and severe incidents are reported (Snort priorities 0 and 1). The classification and message strings are taken directly from the rule that triggered this incidents.

===Detail of traffic analysis===

Limit module processing, allows you to configure which OSI-layers (2,3,4,7) are actively processed and analyzed by the Allegro Network Multimeter. With this setting, the performance of the Allegro Network Multimeter can be significantly improved and allows for higher throughput when disabling some analysis modules.

For both realtime and offline parallel analysis, the following modes are possible :

*Only capturing: Only interface statistics and the capture module is provided. Capture filters are supported without Layer 7 protocol specification/recognition.
*Capturing and protocol detection: Additionally Layer 7 protocol specification in Capture filters will now work.
*Up to Layer 2: Additionally all Layer 2 related modules are active such as MAC, MAC protocols, ARP and Burst Analysis.
*Up to Layer 3: Additionally all Layer 3 related modules are active such as IP and DHCP statistics.
*Up to Layer 4: Additionally all Layer 4 related modules are active such as TCP and Layer 4 server ports.
*Unlimited: All Allegro Network Multimeter modules are active.

When switching to another mode you need to restart the processing in order to activate the new settings.

NOTE: The data recorded to/stored in the Packet Ring buffer, will NOT be affected by any of the above settings. Packet ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter

====Enable single flow load balancing====
When the ''Limit module processing'' slider is turned to ''Only capturing'' the option to enable ''single flow load balancing'' appears. If this option is enabled, even a single flow is load-balanced to different analyzer threads.

This is only recommended when there are very few flows and there is an imbalance in the load of the analyzers. As the packets of a single flow are processed by different analyzers the packets of the flow may be stored out-of-order in the Packet Ring Buffer and a larger amount of memory may be required to reorder the packets when capturing from the Packet Ring Buffer (see [[Capture module#Configuration settings|Capture module]] configuration settings).

===Graph detail settings===

It is possible to modify the detail level of all graphs in the interface. This settings allow you to see a more detailed view (with higher time resolution) or to reduce the detail level so more data can be stored on the device. Changing the default values has an impact on the performance and memory usage. Changing a slider to the left increases the detail level of graphs, but increases memory usage and decreases performance.

*Best graph resolution: This option configures how detailed the graph information are shown in the best case (the latest information). The default value is one second which means that a graph sample point represents a second of packet time. You can change the resolution up to 1 millisecond which gives a detailed sub-second representation of the traffic. You can also decide to decrease the resolution which enables the Allegro Network Multimeter to store more data for a longer period of time.

*Reduce graph resolution of old data by up to: The resolution of older graph data is automatically reduced to save memory and to allow a longer view into the traffic history. This option allows you to change this behaviour. With a reduction factor of 1/1 no reduction is done at all which means the selected graph resolution is available for the complete time.
:This reduces the time period to see historical data. You can choose to increase the reduction factor to store more data for a longer period. The time printed in parentheses represents the worst-case graph resolution based on the chosen resolution and reduction factor. The reduction is done in multiple steps up to this limit. The newest data always has the highest resolution defined by the "Best graph resolution" setting above. Between 60 and 120 data points are stored at a minimum, so with default resolution of 1 second, between one and two minutes are available in the highest resolution. Due to internal compression, the exact number of data points cannot be foreseen but 60 data points are always available at least, usually much more. Once the limit is reached, data is reduced by a factor of two thus doubling the amount of time available in half resolution (2 to 4 minutes in 2 second resolution). When the next limit is reached, the data is halved again thus doubling the time again, until the configured reduction limit is reached. With default settings of one second resolution and reduction limit of 1/6, the worst resolution of 64 seconds (or 1 minute and 4 seconds) is reached not before 2 hours into the past. The drop down menu in graph view gives an exact number about the available graph resolution in the given time period.

Note: Regardless of these settings, the graph values are always converted to represent a value per second (when applicable). For example, the packets per second for an IP addresses will always be a value literally per second even if the resolution is larger or smaller than one second. The displayed value is scaled to match this view. Especially with sub-second resolution this might be misleading.

For instance, if there is a network element sending one packet per second and the resolution is set to 100 milliseconds, the value shown in the graph might be shown as 10 packets per second as each sample point is scaled to represent an value per second. For a detailed investigation it is recommended to always select a specific time interval and look at the (packet) counters shown in all statistics since these are unscaled and represent the actual values.

Performance implications: The performance degradation and memory usage depends on the actual network traffic and is not exactly predictable.

Here are some examples for reference on a Allegro 1000 series with different configuration values (under ideal test conditions):

* 1 second resolution, 1/1 reduction factor: 90% of default performance
*100 millisecond resolution, 1/1 reduction factor: 50% of default performance,
*10 millisecond resolution, 1/1 reduction factor: 15% of default performance
*1 millisecond resolution, 1/1 reduction factor: 10% of default performance

=== PCAP parallel analysis===

The PCAP parallel analysis feature allows to analyse PCAP files or the
packet ring buffer in parallel to the live measurement. The settings
allow to enable the feature and choose how much memory of the main
memory is used for parallel analysis and how many parallel slots can
be used. Detailed description of the configuration values are
described [[parallel packet processing|here]].

==IPFIX settings ==

The Allegro Network Multimeter may be running as an IPFIX exporter. These settings allows for reporting configuration. When enabled, the following settings are possible:

*IP address: Address of IPFIX collector.
*Port: Corresponding port.
*Protocol: TCP or UDP.
*Update interval: Interval in seconds for sending a status update of flows.
*UDP resend interval: Interval in seconds for resending IPFIX templates for UDP connections.
* TCP reconnect timeout: When TCP connections could not be established, wait for this time period until the next attempt to establish a connection.

Individual IPFIX messages can be enabled or disabled by toggling corresponding options. See the NetFlow/IPFIX interface documentation for details about the message types.

==Time settings==

The Time settings were moved to [[Administration]].

== Email notification==

The Email notification settings were moved to [[Administration]].

==Memory extension (BETA)==

See [[Memory extension]] for details about this beta feature.

==DB persistance (BETA) ==
See [[DB persistence]] for details about this feature.

==Longterm DB (BETA)==
See [[Longterm DB]] for details about this feature.

== Expert settings==

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

===Packet length accounting===

This setting allows you to configure which packet length is used for all traffic counters and incidents. The 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 Bytes)
*Layer 2 without frame check sequence (default): Packet length is accounted on Layer 2 without a frame check sequence (4 Bytes)
*Layer 2 with frame check sequence: Account packet length on Layer 2 with frame check sequence (4 Bytes) When switching to another mode, it will only be applied on new packets. Older packet size statistics will not be changed.

===VLAN handling ===

The Allegro Network Multimeter can '''ignore VLAN tags''' for connection tracking. Enabling this option may be necessary if network traffic is seen on the Allegro Network Multimeter that contains changing VLAN tags for the same connection. For example, depending on the configuration of the Mirror Port to which the Allegro Network Multimeter is connected, incoming traffic could contain a VLAN tag while outgoing traffic does not. In this example, a connection would appear twice in the statistics which often is desired behaviour to be able to identify a network misconfiguration. In some cases however, such "duplicate" data in the dashboard may be misleading, and the user would want to see only one connection. In these scenarios the option ignore VLAN tags may be enabled.

===Tunnel view mode===

The Allegro Network Multimeter can decapsulate GRE, VXLAN, ERSPAN type II and type III, GENEVE, CAPWAP as well as L2TPv3 data traffic. Depending on this option either the outer tunnel or the inner content is shown in all analysis modules.

There are three possible modes:

* don't decapsulate traffic (default)
*decapsulate tunnel traffic, discard non-encapsulated traffic
*decapsulate tunnel traffic, process also non-encapsulated traffic

Optionally, a filter can be set to limit decapsulation on specific packets with a certain IP address, IP ranges or interfaces. If the filter is empty, all packets will be decapsulated.

In case the mode is active with discarding non-encapsulated traffic, on the Dashboard a dropped counter will display dropped non-encapsulated packets.

When capturing, packets with complete outer Layer 2, Layer 3, GRE, ERSPAN, GENEVE, CAPWAP and L2TPv3 headers will be stored as seen on the wire.

===Database mode settings===

The database mode is a special analysis mode for high-performance Allegro Network Multimeters with multiple processors to increase the performance on such systems. It is normally enabled automatically but depending on the actual network traffic and system usage, some parameter tweak might be necessary to improve overall system performance.
You should only change these parameters in discussion with the Allegro Packets support department.
These settings are only visible if your Allegro Network Multimeter is capable of running this mode.

You can read more about the meaning of the settings [[DB mode|here]].

===Network performance ===

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

*Max RX queues per socket: This setting specifies the quantity 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 since 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 since 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 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 department.

===Processing performance===

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

*Processing performance mode: This setting allows for fine tuning processing performance. By using '''Analysing''', as much processing ressources on all CPUs as possible are used for data analysis. By using '''Capturing''', the focus will be on high data throughput and low latency for capturing purposes by using only the CPU where the preferred network controller is attached to. This has an impact on data analysis performance. '''Analysing''' is used by default.
You should only change this parameter in discussion with the Allegro Packets support department.

===Packet ring buffer timeouts===

Two timeout settings related to the packet ring buffer can be adjusted.

*'''Long timeout''' controls after which maximum amount 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 order in the packet ring buffer but it may increase the amount of unused overhead data in the packet ring buffer.
*'''Short timeout''' controls after which amount 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 order in the packet ring buffer, but it may also decrease the performance of the packet ring buffer.

===Data retention timeout===

When the data retention timeout is set to a value greater than 0, data will be removed everywhere throughout 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.

===Multithreaded capture analysis ===

This option enables the use of multiple CPUs for capture analysis like when
analyzing a pcap capture file or analyzing the packet ring buffer. Depending
on the number of available CPUs this can significantly speed up the analysis.

It is possible to dedicate a number of CPUs exclusively to capture analysis.
Since these CPUs are not available for live packet processing the performance of
live traffic analysis may be lower.
When set to 0 a lower priority is used for capture analysis than for live analysis
but it cannot be ruled out that the performance of the live processing is
affected.

===Load balancing===

This option select the load distribution method. By default, network
traffic is balanced among all processing threads based on the IP
addresses. This is fast and usually the best way for efficient load
balancing.

If the network traffic only occurs between a few IP addresses, this
method can lead to a load imbalance so that some threads are doing more
work while other threads may be idle. In this scenario, "flow based
balancing" can be enabled to distribute the traffic based on the IP
and port information. This will lead to better utilization of all
processing threads.

Since this option induces additional processing overhead per packet
and additional memory for all internal IP statistics, it should only
be enabled in cases of significant load imbalance.

===Ingress packet memory===

This slider allows to configure the amount of memory which is used to buffer received packets. A larger amount of ingress packet memory may help in processing bursts of high bandwidth traffic without packet drops but it also decreases the amount of memory available for statistics. It is important to know that a restart of the processing does not suffice to make changes to this setting active. A full reboot of the device is required for that. See [[Performance Optimization Guide]].

===Jumbo frame mode===
This options allows to set how jumbo frames are handled by the system.

Three settings are available and the '''normal''' mode, which is also the default, is the mode that was used before this configuration option was introduced:

*'''Normal''': the default mode offers the best balance of full support for jumbo frames with an efficient usage of the ingress packet memory. This mode uses efficiently sized packet buffers and splits larger packets over multiple packet buffers.
*'''Large buffers''': this mode uses a single large buffer for each packet which may improve the performance but does not use the ingress packet memory as efficiently and limits the maximum jumbo frame size to 9kB.
*'''Disabled''': this mode disables support for jumbo frames and offers the best performance and efficient usage of the ingress packet memory. Jumbo frames will be discarded by the network interface.

===Hardware packet timestamping===
This option allows to enable the use of high-precision hardware packet timestamps on supported interfaces (quad 25G and dual 100G expansion).

This feature will require approximately 30% more load in the I/O threads. The load increase can be reduced to about 10% by using the jumbo frame mode "Large buffers" or "Disabled".

When enabled, packets received on supported interfaces will carry a timestamp with nanosecond resolution instead of microsecond resolution.

===External timestamps===
When this option is enabled, the system will use timestamps contained in the packet data instead of timestamps measured at packet arrival. Currently the Arista and Ixia/Keysight as well as the SRCMAC timestamp formats are supported.

If the Ixia/Keysight or Arista type is selected, packets without an external timestamp will not be analyzed. The current number of packets that are dropped because they do not contain an external timestamp is displayed in the active interface overview table of the top-user dashboard. If there are no packets with external timestamps arriving the time of the packet processing will effectively stand still and most graphs will not make progress in live-mode.

If one of the SRCMAC options is selected, all packets will be analyzed with all-zero MAC addresses.

=== External original packet lengths ===
This option allows to enable the use of original packet length information contained in the packet data instead of the length of the packet as received. At this time only the Ixia/Keysight original packet length trailer format is supported.

This feature can also be used in combination with the ''External timestamps'' option to support packets that contain a Ixia/Keysight trailer with both timestamp and original length information.

===Memory utilization limit===
This option allows to reduce the limit until old data is removed from the in-memory database. By default the system tries to target 90% memory utilization. In some case, the load might be too high to match this limit. A smaller limit may enable the system to keep the target memory utilization and perform better in general.

File:Snort Analysis Results.png

2024-10-24T08:14:21Z

Robert:

Snort Analysis Results

Template:Warning

2024-10-24T08:01:26Z

Robert: Created page with "<div style="background-color: #faebcc; color: #8a6d3b; border-color: #faebcc; padding: 0.5em 1em; margin-bottom: 20px; border: 1px solid transparent; border-radius: 4px;"> {{{title}}} {{{1}}} </div>"

<div style="background-color: #faebcc; color: #8a6d3b; border-color: #faebcc; padding: 0.5em 1em; margin-bottom: 20px; border: 1px solid transparent; border-radius: 4px;">
{{{title}}}
{{{1}}}
</div>

WiFi module

2024-09-24T08:11:25Z

Robert: /* BSS-Client details */

This module analyses IEEE 802.11 frames either acquired using the WiFi monitoring feature (see [[WiFi|WiFi interface settings]]) or encapsulated in special packets (https://www.wireshark.org/docs/dfref/p/peekremote.html). It also provides statistics when analyzing PCAPs with a Radiotap link type and IEEE 802.11 packets.

=== Statistics ===

==== '''Channel statistics''' ====
[[File:Ieee 802 11 channels.png|thumb|300x300px|WiFi channel view]]
This page shows a list of all WiFi channels on which traffic is seen and offers the ability to capture the traffic of each channel. The table contains the following data:

* Frequency: the frequency of the channel in MHz. This uniquely identifies a channel as the channel numbers themselves are ambiguous.
* Channel: the channel number. These numbers are ambiguous as there exists a channel 1 in the 2.4GHz range as well as in the 5GHz range.
* Number of BSS: The number of BSS active on this channel.
* Active BSS within the last hour: the number of BSS that were active on this channel during the last hour.
* Packets: the number of packets seen on this channel.
* Packets retransmitted: the number of retransmitted packets seen on this channel. (firmware >= 4.2)
* Bytes: the number of bytes seen on this channel.
* Bytes retransmitted: the number of retransmitted bytes seen on this channel. (firmware >= 4.2)
* Graph: Multigraph selection that can show packet rate and data rate history.
The channel frequency can be clicked on get a list of BSS in that specific channel. This table contains the same information as the global table in the BSS statistics.

==== BSS statistics ====
[[File:Ieee 802 11 bss list.png|thumb|600x600px|BSS list]]The table shown on this page lists all so-called "base service sets" which are usually the access points and offers the ability to capture the traffic of each BSS.

The table contains the following data:

* BSS ID: This is the MAC address of the station.
** In firmware >= 3.4, we also show the number of other BSS IDs of the same device, based on their MAC addresses. When following the link to the BSS detail page, the other BSS are listed on that page.
* NIC vendor name: This is the vendor name of the MAC addresse.
* SSID: When available, the SSID is shown for this BSS (firmware >= 3.4)
* AP name: When available, the AP name is shown (firmware >= 3.4)
** Note: The AP name is Cisco specific extension of beacon frame attributes and therefore only available for specific devices.
* Subscribers: This column shows the number of MAC addresses communication from or to this BSS (Firmware >= 3.4)
** The number of clients in parentheses are the number of unicast addresses different than the BSS MAC address.
** The actual subscribers can be seen in the BSS detail page.
* Current channel: This is the channel the BSS is currently operating on (firmware >= 3.4)
* Current frequency: This is the frequency the BSS is currently operating on (firmware >= 4.0)
* Current channel utilization: This value is extracted from beacon frames indicating the percentage of time the channel was active (firmware >= 3.4)
* Current frequency: This classifies the BSS frequency into 2.4 GHz, 5 GHz, or 0 for other frequencies
* packets transmitted: This is the number of packets that have been analyzed for this BSS. (firmware >= 4.2)
* packets retransmitted: This is the number of retransmitted packets that have been analyzed for this BSS. (firmware >= 4.2)
* packets retransmitted ratio: This is the proportion of retransmitted packets that have been analyzed for this BSS. (firmware >= 4.2)
* bytes transmitted: This is the number of bytes that have been analyzed for this BSS.
* bytes retransmitted: This is the number of retransmitted bytes that have been analyzed for this BSS. (firmware >= 4.2)
* bytes retransmitted ratio: This is the proportion of retransmitted bytes that have been analyzed for this BSS. (firmware >= 4.2)
* Signal/noise level: These values indicate the signal quality of the BSS.
** It uses information from packets sent from or to the BSS to give an indication ab out the overall quality.
* Graph: Multigraph selection for detailed information over time:
** Packets: this is the number of frames seen over time
** Packets retransmitted: this is the number of retransmitted frames seen over time (firmware >= 4.2)
** Bytes: this is the number of bytes seen over time
** Bytes retransmitted: this is the number of retransmitted bytes seen over time (firmware >= 4.2)
** dbm signal/noise: the signal and noise level over time
** Channel: This is the channel used at any given time (firmware >= 3.4)
[[File:Ieee 802 11 client list.png|thumb|300x300px|WiFi client list]]

==== Client statistics ====
This page shows all clients devices (unicast devices other than BSS) that have been seen in QoS and beacon frame.

The table shows the client MAC address, its vendor name and in how many BSSs this client was active.
[[File:Ieee 802 11 client detail bss.png|thumb|300x300px|WiFi client detail]]
When clicking on the client address, a detailed page is shown. The BSS tab shows which BSS were actually used at which time so it is possible to identify how often a client switched access points.

==== Per-BSS statistics ====
For each BSS MAC address, more detailed information can be shown by clicking on the MAC address in the BSS list.
[[File:Ieee 802 11 bss detail.png|thumb|300x300px|WiFi BSS details]]
The detail page shows an overview for this BSS ID and contains additional tabs for the list of subscribers and network endpoints of that base service set, as well as the list of frequencies, channels, and bands used by this base service set.

The overview tab shows all information from the BSS table and also all MAC addresses of other BSS that are handled by the same physical device.

==== BSS-Client details ====
In the BSS subscribers list on the BSS details page, information for each subscriber in the BSS is shown. A subscriber is any MAC that has sent a unicast frame to the BSS. This table contains a "Handshakes seen" column which displays the number of handshakes a client has attempted with the BSS. Clicking on the "Details" link leads to a new details page for the BSS/Client pair.

This page displays information about the client profile and the most recent handshake. The client profile contains the decoded data transmitted by the client in a (re)association request frame. It contains information about the capabilities of the client (this includes supported operating frequencies, power saving mechanisms, cryptographic ciphers, beamforming information, ...). Each category is collapsible by clicking on the title text, and some of the categories are collapsed by default.

The "Handshake" tab displays the most recently seen handshake (successful or not) as a flowchart diagram. The page consists of the diagram on the left side, and a details panel on the right side. Clicking on an element in the flowchart will populate the details panel with additional information about the frame (if available). To the left of the flowchart there are timestamps (in absolute and relative format) showing when a frame was sent.

The handshake analysis also evaluates the correctness of the handshake. If a frame does not adhere to the IEEE802.11 specification (for example the client sends an association request before authenticating with the BSS) or a frame contains invalid information these frames will be marked as invalid. Frames that are technically allowed but unexpected at the current stage of the handshake (for example spurious probe requests after association) are marked as dubious. Dubious frames are unproblematic under normal circumstances. An invalid frame might be an indicator of a misconfigured WiFi device or poor signal quality at the Allegro Multimeter's location. Incident rules can be created to trigger when invalid handshake frames are seen, or when a handshake fails (for whatever reason).

The following details are displayed in the details panel:
[[File:WiFi Client Profile.jpg|thumb|357x357px|Example WiFi Client Profile decoded from an association request]]
{| class="wikitable mw-collapsible mw-collapsed" style="width: 60%"
|+Authentication
|Authentication algorithm
|The algorithm used for authentication with the BSS. Usually "Open Systen" indicates WPA2, and "SAE" indicates WPA3
|-
|Sequence number
|The current step in the authentication process
|-
|Status
|The status code of the authentication
|}
[[File:WiFi Handshake.jpg|thumb|356x356px|Example of a WPA2 handshake]]
{| class="wikitable mw-collapsible mw-collapsed" style="width: 60%"
|+(Re)association response
|Capabilities
|A list of capabilities the responder has. This is an overview of the client profile of the responder
|-
|Status
|The status code of the association
|-
|Association ID
|An ID given to the client by the BSS, used in future reassociations.
|}
{| class="wikitable mw-collapsible mw-collapsed" style="width: 60%"
|+Deauthentication / Disassociation
|Reason
|A code describing the reason why the client (was) deauthenticated/disassociated
|}
{| class="wikitable mw-collapsible mw-collapsed" style="width: 60%"
|+EAPOL-Key
|Descriptor version
|Describes the cryptographic authentication and key management mechanism used in the handshake
|-
|Key type
|Whether this frame is part of the 4-way handshake
|-
|Install
|Whether the client shall install the key derived from this frame
|-
|Key Ack
|Whether the client needs to respond to this frame
|-
|Key MIC
|Whether or not this frame contains a MIC
|-
|Secure
|Set to "true" once initial key exchange is complete (EAPOL-Key 3 and onwards)
|-
|Error
|Whether an error occured during the handshake
|-
|Request
|Set to "true" by the client when they request the initiation of a handshake
|-
|Encrypted Key Data
|Whether the key data in this frame is encrypted
|-
|Key length
|Length of the temporal key
|-
|Key replay counter
|Number of exchanges carried out during this handshake
|-
|Key nonce, IV, RSC, MIC
|Cryptographic values used in the key derivation
|-
|Key data length
|Length of the key data (0 means no key data is present)
|-
|Key Data
|Key Data
|}

=== Traffic processing ===
There are currently four kinds of 802.11 traffic that can be analyzed:

# Live packet processing of IEEE 802.11 packets acquired with the WiFi monitoring feature (see [[WiFi|WiFi interface settings]]).
# Radiotap PCAP files that contain IEEE 802.11 packets.
# PEEKREMOTE packets. This kind of traffic is generated by access points and is send via UDP to a specified IP address and port. To analyze this traffic, the endpoint mode has to be enabled on an interface which receives this traffic. In the [[Global settings#Endpoint mode|endpoint mode configuration]], an IP address and port can be configured for which the Allegro Network Multimeter accepts packets. PEEKREMOTE packets usually do not contain complete IP packets, only 802.11 statistics that are evaluated by the Allegro Network Multimeter.
# CAPWAP encapsulated packets. In contrast to PEEKREMOTE, CAPWAP packets encapsulate complete IP packets which itself contain 802.11 information. Therefore, the endpoint mode must be configured for a specific IP and port and the [[Global settings#Tunnel view mode|tunnel view mode]] must be enabled too to let the Allegro Network Multimeter look inside the encapsulated packets.

WiFi module

2024-09-24T08:02:14Z

Robert: fix some formatting

This module analyses IEEE 802.11 frames either acquired using the WiFi monitoring feature (see [[WiFi|WiFi interface settings]]) or encapsulated in special packets (https://www.wireshark.org/docs/dfref/p/peekremote.html). It also provides statistics when analyzing PCAPs with a Radiotap link type and IEEE 802.11 packets.

=== Statistics ===

==== '''Channel statistics''' ====
[[File:Ieee 802 11 channels.png|thumb|300x300px|WiFi channel view]]
This page shows a list of all WiFi channels on which traffic is seen and offers the ability to capture the traffic of each channel. The table contains the following data:

* Frequency: the frequency of the channel in MHz. This uniquely identifies a channel as the channel numbers themselves are ambiguous.
* Channel: the channel number. These numbers are ambiguous as there exists a channel 1 in the 2.4GHz range as well as in the 5GHz range.
* Number of BSS: The number of BSS active on this channel.
* Active BSS within the last hour: the number of BSS that were active on this channel during the last hour.
* Packets: the number of packets seen on this channel.
* Packets retransmitted: the number of retransmitted packets seen on this channel. (firmware >= 4.2)
* Bytes: the number of bytes seen on this channel.
* Bytes retransmitted: the number of retransmitted bytes seen on this channel. (firmware >= 4.2)
* Graph: Multigraph selection that can show packet rate and data rate history.
The channel frequency can be clicked on get a list of BSS in that specific channel. This table contains the same information as the global table in the BSS statistics.

==== BSS statistics ====
[[File:Ieee 802 11 bss list.png|thumb|600x600px|BSS list]]The table shown on this page lists all so-called "base service sets" which are usually the access points and offers the ability to capture the traffic of each BSS.

The table contains the following data:

* BSS ID: This is the MAC address of the station.
** In firmware >= 3.4, we also show the number of other BSS IDs of the same device, based on their MAC addresses. When following the link to the BSS detail page, the other BSS are listed on that page.
* NIC vendor name: This is the vendor name of the MAC addresse.
* SSID: When available, the SSID is shown for this BSS (firmware >= 3.4)
* AP name: When available, the AP name is shown (firmware >= 3.4)
** Note: The AP name is Cisco specific extension of beacon frame attributes and therefore only available for specific devices.
* Subscribers: This column shows the number of MAC addresses communication from or to this BSS (Firmware >= 3.4)
** The number of clients in parentheses are the number of unicast addresses different than the BSS MAC address.
** The actual subscribers can be seen in the BSS detail page.
* Current channel: This is the channel the BSS is currently operating on (firmware >= 3.4)
* Current frequency: This is the frequency the BSS is currently operating on (firmware >= 4.0)
* Current channel utilization: This value is extracted from beacon frames indicating the percentage of time the channel was active (firmware >= 3.4)
* Current frequency: This classifies the BSS frequency into 2.4 GHz, 5 GHz, or 0 for other frequencies
* packets transmitted: This is the number of packets that have been analyzed for this BSS. (firmware >= 4.2)
* packets retransmitted: This is the number of retransmitted packets that have been analyzed for this BSS. (firmware >= 4.2)
* packets retransmitted ratio: This is the proportion of retransmitted packets that have been analyzed for this BSS. (firmware >= 4.2)
* bytes transmitted: This is the number of bytes that have been analyzed for this BSS.
* bytes retransmitted: This is the number of retransmitted bytes that have been analyzed for this BSS. (firmware >= 4.2)
* bytes retransmitted ratio: This is the proportion of retransmitted bytes that have been analyzed for this BSS. (firmware >= 4.2)
* Signal/noise level: These values indicate the signal quality of the BSS.
** It uses information from packets sent from or to the BSS to give an indication ab out the overall quality.
* Graph: Multigraph selection for detailed information over time:
** Packets: this is the number of frames seen over time
** Packets retransmitted: this is the number of retransmitted frames seen over time (firmware >= 4.2)
** Bytes: this is the number of bytes seen over time
** Bytes retransmitted: this is the number of retransmitted bytes seen over time (firmware >= 4.2)
** dbm signal/noise: the signal and noise level over time
** Channel: This is the channel used at any given time (firmware >= 3.4)
[[File:Ieee 802 11 client list.png|thumb|300x300px|WiFi client list]]

==== Client statistics ====
This page shows all clients devices (unicast devices other than BSS) that have been seen in QoS and beacon frame.

The table shows the client MAC address, its vendor name and in how many BSSs this client was active.
[[File:Ieee 802 11 client detail bss.png|thumb|300x300px|WiFi client detail]]
When clicking on the client address, a detailed page is shown. The BSS tab shows which BSS were actually used at which time so it is possible to identify how often a client switched access points.

==== Per-BSS statistics ====
For each BSS MAC address, more detailed information can be shown by clicking on the MAC address in the BSS list.
[[File:Ieee 802 11 bss detail.png|thumb|300x300px|WiFi BSS details]]
The detail page shows an overview for this BSS ID and contains additional tabs for the list of subscribers and network endpoints of that base service set, as well as the list of frequencies, channels, and bands used by this base service set.

The overview tab shows all information from the BSS table and also all MAC addresses of other BSS that are handled by the same physical device.

==== BSS-Client details ====
In the BSS subscribers list on the BSS details page, information for each subscriber in the BSS is shown. A subscriber is any MAC that has sent a unicast frame to the BSS. This table contains a "Handshakes seen" column which displays the number of handshakes a client has attempted with the BSS. Clicking on the "Details" link leads to a new details page for the BSS/Client pair.

This page displays information about the client profile and the most recent handshake. The client profile contains the decoded data transmitted by the client in a (re)association request frame. It contains information about the capabilities of the client (this includes supported operating frequencies, power saving mechanisms, cryptographic ciphers, beamforming information, ...). Each category is collapsible by clicking on the title text, and some of the categories are collapsed by default.

The "Handshake" tab displays the most recently seen handshake (successful or not) as a flowchart diagram. The page consists of the diagram on the left side, and a details panel on the right side. Clicking on an element in the flowchart will populate the details panel with additional information about the frame (if available). To the left of the flowchart there are timestamps (in absolute and relative format) showing when a frame was sent.

The handshake analysis also evaluates the correctness of the handshake. If a frame does not adhere to the IEEE802.11 specification (for example the client sends an association request before authenticating with the BSS) or a frame contains invalid information these frames will be marked as invalid. Frames that are technically allowed but unexpected at the current stage of the handshake (for example spurious probe requests after association) are marked as dubious. Dubious frames are unproblematic under normal circumstances. An invalid frame might be an indicator of a misconfigured WiFi device or poor signal quality at the Allegro Multimeter's location. Incident rules can be created to trigger when invalid handshake frames are seen, or when a handshake fails (for whatever reason).

The following details are displayed in the details panel:
[[File:WiFi Client Profile.jpg|thumb|357x357px|Example WiFi Client Profile decoded from an association request]]
{| class="wikitable mw-collapsible mw-collapsed"
|+Authentication
|Authentication algorithm
|The algorithm used for authentication with the BSS. Usually "Open Systen" indicates WPA2, and "SAE" indicates WPA3
|-
|Sequence number
|The current step in the authentication process
|-
|Status
|The status code of the authentication
|}
[[File:WiFi Handshake.jpg|thumb|356x356px|Example of a WPA2 handshake]]
{| class="wikitable mw-collapsible mw-collapsed"
|+(Re)association response
|Capabilities
|A list of capabilities the responder has. This is an overview of the client profile of the responder
|-
|Status
|The status code of the association
|-
|Association ID
|An ID given to the client by the BSS, used in future reassociations.
|}
{| class="wikitable mw-collapsible mw-collapsed"
|+Deauthentication / Disassociation
|Reason
|A code describing the reason why the client (was) deauthenticated/disassociated
|}
{| class="wikitable mw-collapsible mw-collapsed"
|+EAPOL-Key
|Descriptor version
|Describes the cryptographic authentication and key management mechanism used in the handshake
|-
|Key type
|Whether this frame is part of the 4-way handshake
|-
|Install
|Whether the client shall install the key derived from this frame
|-
|Key Ack
|Whether the client needs to respond to this frame
|-
|Key MIC
|Whether or not this frame contains a MIC
|-
|Secure
|Set to "true" once initial key exchange is complete (EAPOL-Key 3 and onwards)
|-
|Error
|Whether an error occured during the handshake
|-
|Request
|Set to "true" by the client when they request the initiation of a handshake
|-
|Encrypted Key Data
|Whether the key data in this frame is encrypted
|-
|Key length
|Length of the temporal key
|-
|Key replay counter
|Number of exchanges carried out during this handshake
|-
|Key nonce, IV, RSC, MIC
|Cryptographic values used in the key derivation
|-
|Key data length
|Length of the key data (0 means no key data is present)
|-
|Key Data
|Key Data
|}

=== Traffic processing ===
There are currently four kinds of 802.11 traffic that can be analyzed:

# Live packet processing of IEEE 802.11 packets acquired with the WiFi monitoring feature (see [[WiFi|WiFi interface settings]]).
# Radiotap PCAP files that contain IEEE 802.11 packets.
# PEEKREMOTE packets. This kind of traffic is generated by access points and is send via UDP to a specified IP address and port. To analyze this traffic, the endpoint mode has to be enabled on an interface which receives this traffic. In the [[Global settings#Endpoint mode|endpoint mode configuration]], an IP address and port can be configured for which the Allegro Network Multimeter accepts packets. PEEKREMOTE packets usually do not contain complete IP packets, only 802.11 statistics that are evaluated by the Allegro Network Multimeter.
# CAPWAP encapsulated packets. In contrast to PEEKREMOTE, CAPWAP packets encapsulate complete IP packets which itself contain 802.11 information. Therefore, the endpoint mode must be configured for a specific IP and port and the [[Global settings#Tunnel view mode|tunnel view mode]] must be enabled too to let the Allegro Network Multimeter look inside the encapsulated packets.

TCP flow chart

2024-09-18T12:20:29Z

Robert: add window fill graph

The TCP flow chart feature allows for a detailed view of a TCP connection by using a retrospective analysis. It will extract all packets for a selected connection from the ring buffer or packet buffer and runs a detailed analysis on these packets.
[[File:TCP flow chart example1.png|thumb|600x600px|TCP flow chart]]

=== Table packet view ===
The results are shown in a table on the left hand side containing all packets, their time (which can be toggled between relative and absolute time by clicking on it) and detailed packet information. This information contains the direction of the packet and the packet type, like actual data, SYN, ACKs, DUP-ACKS, retransmission, etc. For ACK packets, the ack'ed packet number is shown and can be clicked to jump to that packet. Below the direction arrow the delta time to the previous packet is shown.

A simplified TCP state is shown for both client and server side.

Some packets, like DUP-ACKs or retransmissions, also describe a reference packet to which they refer to. The number of the reference packet is shown in the "Reference" column, clicking on it navigates to that packet.

The "Ack time" column shows the time between ACK packets and the previous data packet this is being acknowledged.

The packets in the table can be clicked to highlight the time in the graphs on the right hand side.

Buttons on top of the table allow to navigate to the next or previous occurrence of specific unusual TCP events, such as retransmissions, missed data, or duplicate ACKs.

=== Summarized statistics ===
The right hand side of the window contains some summarized values about the analysis.

A text field can be used to enter any packet number to jump to that packet in the table view.

The connection can be captured by using the corresponding button.

The maximum time between data and its acknowledgement is shown. Large values indicate network problems when packets may not have been received.

The time can be restricted by selecting an interval in the graphs below. The selected time period is independent of the global time period. A button on the right hand side part of the view allows to reset the time window back to the whole connection duration, and the second button allows to apply the time period to the global time. This allows to further analyze other network traffic in some selected time period.

=== Traffic graphs ===
[[File:Flowchart graphs 1.png|thumb|600x600px|Traffic graphs (part 1)]]
[[File:Flowchart graphs 2.png|thumb|600x600px|Traffic graphs (part 2)]]
Detailed graphs are available for different traffic metrics. The graph can be clicked to jump to the corresponding packet in the packet table, and packets can be clicked to highlight the graph section with a vertical line.

In contrast to other graphs in the regular live analysis, these graphs are always in millisecond resolution for the whole duration of the connection, so no data reduction is used for older data.

* Traffic: these graphs show the throughput in bit/s and packets/s for the connection.
* TCP zero window packets: this graph shows zero window packets that occurred within the connection.
* TCP window usage: The amount of data inside the respective windows in percent.
* DUP acks: this graph contains all occurrences of duplicate acknowledgments.
* TCP retransmissions: this graph shows all retransmitted data.
* Client and server sequence/acknowledgment: These graphs show each individual TCP sequence number and acknowledgment number. This makes it easier to spot large delays in receive acknowledgments, which often happens during time periods with retransmissions.
* Missing data: This graph shows data of TCP segments that have not been seen by the Allegro Network Multimeter. Main reasons for such data are errors in capturing (overloaded capturing), or overloaded or misconfigured mirror ports.

=== Limitations ===

# Since the analysis takes significant memory per connection, the analysis is not performed on live traffic. Instead, a ring buffer (or packet buffer for pcap analysis) is required to be able to extract the connection and run the analysis on that data. The analysis only uses the TCP header information, so it is sufficient to have the ring buffer configured to store truncated packets containing only the L4 header.
# The analysis result is stored on internal storage instead of main memory to keep as much memory available for live processing. Therefore, there is a size limit on how large the connection can be. The maximum number of packets is 100,000, but it can be lower if not enough disk space is available.
# Due to disk space limitations, the number of parallel opened analysis windows is limited to 5. Starting another TCP flow chart will invalidate the oldest one automatically.
# The analysis of a TCP connection starts at the beginning of the connection and stops either at the end of connection or the end time configured in [[Back-in-Time functionality|BIT-Mode]]. Since the packets are extracted from ring buffer, the analysis may take some time (especially if it is a long-lasting connection). A progress bar informs about the status of the analysis.

Incidents

2024-09-18T12:07:30Z

Robert: Add new wifi handshake trigger and attributes

[[File:Incidents_list.png|alt=|none|thumb|800x800px|Incident page]]
Incidents are used to alarm the user when configured network events occur, usually for traffic based rules, but also for system-specific events. These notifications can be viewed in the web GUI and may also be delivered on various notification channels. Repeating incidents are counted as such and the time of the first and last occurrence of an incident is remembered. This feature can be disabled for some incidents. What makes an incident unique depends on the type of incident.

The incident feature allows to define rules which are checked on the configured trigger point, like when a connection ends, a SIP call ends, or for checks on ongoing traffic. When such a trigger hits, configurable traffic attributes will be checked and if all attributes of a rule match, an incident is created.

Occurred incidents can be seen in the web interface, additionally reporting via the following notification channels is possible:
* email
* Apache Kafka
* SNMP trap
* syslog

The first occurrence of a medium or high severity incident will also trigger a status notification which is visible at the top right of the web GUI.

A configurable number of incidents will be remembered by the system and if the limit is exceeded the oldest incidents will be discarded [fixed number of 1000 incidents in firmware < 4.1].

== Rule configuration ==
[[File:Incidents rules.png|thumb|600x600px|Rule configuration]]
Incident rules can be defined in the "Configuration of incident rules" tab in the menu "Generic -> Incidents". All changes to the rule configuration will only take effect after saving the current configuration by clicking on the save button at the bottom of the page.

The page shows a table containing the existing rules and their configuration.

Each existing rule can be modified by clicking on the pencil symbol, or deleted by clicking on the "minus" symbol.

New rules can be added by clicking on the "Add rule" button. A dialog appears allowing for configuration of the rule. The same dialog is used when modifying an existing rule.

=== Add/modify a rule ===
[[File:Incidents add rule.png|thumb|600x600px|Add rule dialog]]
A rule is defined by the following settings:

* Rule name: This is an arbitrary text describing the purpose of the rule. This text is shown in the incident list and email/Kafka/SNMP trap/syslog ouptut.
* Severity: three different severity values "low", "medium", and "high" can be used to group more important and less important incidents. Reporting channels can be configured to only report incidents of a minimum severity level. A rule can also be disabled by choosing the severity level "disabled". It will not be evaluated and can be enabled later at will.
* Trigger: The trigger defines when a rule is evaluated. For each available trigger, a description is shown next to it giving more details about the trigger. Some triggers are evaluated at a very specific time, like when a VoIP call ends, or are evaluated regularly like for throughput triggers of IP traffic which can be configured to be checked periodically. See list below for a detailed description of the available triggers.
* Attributes: Attributes are used to make actual comparison of expected values vs. actual values.
** Each trigger has a different set of attributes which can be checked for, and some triggers don't need to have an attribute at all. See list below for a detailed description of the available attributes
** Up to four attributes can be added by clicking on the "Add attribute" button.
** Multiple attributes must all match at the same time to let the rule create an incident.
** Each attribute can be compared to a specific value, so that the actual value is lower, equal, or greater than a defined value.
** Some attributes have an additional parameter, like a time span which defines how the attribute value is calculated.
* Virtual link group: The rule can be limited to a selected [[Virtual Link Group functionality|virtual link group]] or to be applied for any group. Some triggers cannot be limited to a virtual link group so the configuration will be hidden.
* IP filter: Depending on the selected trigger, the rule can be limited to a specific IP address. The IP filter can also be an IP subnet in the format IP/mask-length (Example: 10.0.0.0/8)
* IP group: Depending on the selected trigger, the rule can be applied to an IP group instead of an individual IP address.
* Virtual link group, IP and IP filter can also be used inversely by using the != comparator
* Report channel: Incidents are always visible in the web interface, but can also be reported via multiple channels which can be configured separately in the tab "Configuration of notification channels". Up to ten channels can be selected so that the incident for this rule is reported on each channel. Also, no channel can be configured so the incident is only accessible on the web interface.
* Aggregation of recurring Incidents: Incidents are aggregated by default. This means the table only shows the number of incidents of the type and the timestamps of the first and the last incident. This can be disabled for most of the incidents, so that you are able to see every indent of the incident-type.
* Time Profiles: You are able to set a profile which defines the active time of an incident rule.
* Traffic capturing: If supported by the trigger, the rule can be configured to capture the network traffic triggering the rule, including some extra time before and after the incident.
** Possible options:
*** Disabled: capturing is disabled for this rule
*** Live traffic: capturing happens only for live network traffic
*** Replay traffic: capturing happens only for replayed network traffic (from PCAP files)
*** Always: capturing happens in all traffic processing types.
** Extra capture time: configure the number of seconds before the start of the incident and after the end of the incident.
*** If a time span parameter is used for attributes, the capture time includes this time duration as well.
** The traffic is automatically filtered to only contain the traffic that actually triggered the rule, i.e., an IP address or an IP group for IP rules.

=== Available triggers ===
{| class="wikitable"
|+
!Trigger name
!Description
!Attributes
!Attribute usage
|-
|ARP: MAC change for an IP 
(arp_ip_mac_changed)
|This trigger is checked on an ARP response and MAC address changed for a requested IP.
|time_since_last_mac
|optional
|-
|DNS: Server is not responding 
(dns_server_not_responding)
|This trigger is checked when a DNS server is not responding for some time. A server is considered unresponsive when more than 3 requests to the DNS server went unanswered for a period of more than 5 seconds. Such a server must have answered at least two requests previously.
|time_since_first_unanswered_request
|optional
|-
|DNS: Server response error 
(dns_server_response_error)
|This trigger is checked when a DNS server responds a configured error of type format error, server failure or non-existing domain
|error_type
|mandatory
|-
|Global: Connection start 
(global_new_connection)
|This trigger is checked continuously at connection start. It can be used to report new connections with a certain layer 4 protocol and a given port range.
|l4_protocol, port_range, since_start_time
|mandatory
|-
|Global: GPS synchronization status change 
(global_gps_sync_status_change)
|This trigger is checked when the GPS clock synchronization status changes.
|gps_sync_status
|optional
|-
|Global: Number of connections 
(global_connections)
|This trigger is checked continuously whether the amount of newly created connections exceeds a threshold. The update interval is defined by the timespan parameter of the attributes.
|new_connections
|mandatory
|-
|Global: Regular expressions 
(global_regex_match)
|This trigger allows to configure a list of regular expressions and is checked for each packet whose L7 data matches one of the regular expressions in the list. Since there are no attributes associated with this trigger, this effectively means that any packet which matches one of the regular expressions will result in an incident. The incident also contains information about which connection this packet belongs to as well as which of the regular expressions matches the packet.
|
|no attributes are available for this trigger
|-
|Global: Ring buffer 
(global_ring_buffer)
|This trigger is checked continuously to report changes in the ring buffer.
|used_size, bytes_captured, bytes_dropped
|mandatory
|-
|Global: Speed change of an interface 
(global_interface_speed_change)
|This trigger is checked when the speed of an interfaces changes.
|interface_speed
|optional
|-
|Global: Speed mismatch for an interface pair 
(global_interface_speed_mismatch)
|This trigger is checked when the status or speed of an interfaces changes and mismatches the speed of corresponding interface of a link.
|link_speed_difference
|optional
|-
|Global: Status change of an interface 
(global_interface_status_change)
|This trigger is checked when the status of an interfaces changes.
|interface_status
|optional
|-
|Global: Traffic 
(global_traffic)
|This trigger is checked continuously for the total traffic of the device. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase
|mandatory
|-
|IEC 61850 - GOOSE: State number change 
(iec61850_goose_state_change)
|This trigger is checked when a change in the state number of GOOSE packets is detected.
|GoCBRef
|optional
|-
|IEC104: Response times 
(iec104_response_times)
|This trigger is checked whenever an IEC104 ACTCON reply for an ACT has been seen.
|response_time
|mandatory
|-
|IEC104: Traffic 
(iec104_traffic)
|This trigger is checked continuously for each IEC104 connection. The update interval is defined by the timespan parameter of the attributes.
|percent_loss, absolute_loss, not_in_order
|mandatory
|-
|IP: Connection end 
(ip_flow_end)
|This trigger checks the attributes whenever an IP flow ended.
|total_packets, total_bytes, tcp_handshake_time, percent_retransmissions, zero_window_packets, duration, l7_protocol
|mandatory
|-
|IP: Connection start 
(ip_flow_start)
|This trigger checks the attributes whenever an IP flow starts.
|new_connections, geolocation
|mandatory
|-
|IP: Local IP with multiple MAC addresses 
(ip_local_ip_multiple_macs)
|This trigger is checked on each new flow of a local IP address and more than one MAC address uses this IP.
|mac_count
|optional
|-
|IP: New local IP address 
(ip_new_local_ip)
|This trigger is checked once for each new IP belonging to a private network address range.
|since_start_time
|optional
|-
|IP: New L7 protocol 
(ip_new_l7_protocol)
|This trigger is checked once for each new l7 protocol used by an IP.
|since_start_time, local_ip, l7_protocol
|optional
|-
|IP: TCP handshake 
(ip_tcp_handshake)
|This trigger is checked after successful TCP handshake or at connection end if handshake failed.
|handshake_time, server_handshake_time, client_handshake_time, handshake_failed
|mandatory
|-
|IP: Traffic on IP addresses 
(ip_traffic)
|This trigger is checked continuously for each active IP or IP group. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase, total_packets, total_bytes, retransmission_ratio, zero_window_packets, tcp_syn_packets, tcp_fin_packets, tcp_rst_packets
|mandatory
|-
|IP: TTL change 
(ip_ttl_change)
|This trigger is checked continuously for each active IP.
|ttl_change
|mandatory
|-
|LACP: Status change of a channel 
(lacp_channel_status_change)
|This trigger is checked when the status of a LACP port channel changes.
|channel_status
|optional
|-
|MAC: New L7 protocol 
(mac_new_l7_protocol)
|This trigger is checked when a unicast MAC address uses a l7 protocol for the first time.
|since_start_time
|optional
|-
|MAC: New MAC address 
(mac_new_address)
|This trigger is checked once when a new unicast MAC address appears for the first time.
|since_start_time
|optional
|-
|MAC: Traffic on MAC addresses 
(mac_traffic)
|This trigger is checked continuously for each active MAC address. The update interval is defined by the timespan parameter of the attributes.
|broadcast_packet_rate
|mandatory
|-
|PPPoE: PPPoE Discovery traffic 
(pppoe_discovery_traffic)
|This trigger is checked continuously for PPPoE discovery traffic. The update interval is defined by the timespan parameter of the attributes.
|pppoe_discovery_packets
|mandatory
|-
|Profinet: Traffic of Profinet devices 
(profinet_traffic)
|This trigger is checked continuously for Profinet traffic. For max jitter, the update interval is defined by the timespan parameter of the attributes. All other attributes will be checked upon event.
|alarms_low, alarms_high, errors, frames_lost, frames_repeated, frames_wrong_sequence, max_jitter
|mandatory
|-
|PTP: Timestamp packet 
(ptp_timestamp_packet)
|This trigger is checked when a PTP packet containing a valid timestamp is seen.
|time_offset
|mandatory
|-
|QOS: Traffic on QoS classes 
(qos_traffic)
|This trigger is checked continuously for each active QoS class. The update interval is defined by the timespan parameter of the attributes.
|throughput
|mandatory
|-
|RTP: Traffic for RTP connections 
(rtp_traffic)
|This trigger is checked continuously for traffic of each RTP connection. The update interval is defined by the timespan parameter of the attributes.
|jitter, percent_loss
|mandatory
|-
|SIP: Call end 
(sip_call_end)
|This trigger is checked when a SIP call ended.
|duration, status, mos, percent_loss, jitter, total_packets, total_bytes, total_caller_packets, total_callee_packets, total_caller_bytes, total_callee_bytes
|mandatory
|-
|SMB: SMB1 negotiation 
(smb_v1_negotiation)
|This trigger is executed at the beginning of each SMB connection and checks whether insecure SMB1 has been negotiated.
|
|none
|-
|SSL: Handshake 
(ssl_handshake)
|This trigger is checked during handshake of each SSL connection.
|certificate_expires, tls_alert_level
|mandatory
|-
|SSL: SSL/TLS version negotiation 
(tls_version)
|This trigger is checked during version negotiation at handshake of each SSL connection.
|used_tls_version
|mandatory
|-
|WiFi: Handshake failure
(wifi_handshake_failure)
|This trigger is checked during certain parts of a WiFi handshake when a client tries to join a network.
|handshake_failure_type
|mandatory
|}

==== Special trigger properties ====
Some triggers are checked continuously every configured time span period, so the incidents are generated differently than for fixed event specific triggers like a call end.

# Repeating incidents: The following triggers will be evaluated every configured time span and will be re-issued whenever the configured attributes match.
## ip_traffic
## mac_traffic
## qos_traffic
## rtp_traffic
# Start/stop incidents: The following triggers are reported once the configured attributes match and for a second time when the attributes no longer match.
## global_traffic

So for repeating incidents you will get repeated incidents for the same attribute every time span. For example, if an IP address has traffic of 100 Mbit/s for 2 minutes and a rule checks for more than 50 Mbit/s over 30 seconds, the rule will hit 4 times. There will be one incident which will contain the exact number of repetitions for reference.

For start/stop incidents, you will only see two rule hits and the incident description will state the start and stop time.

=== Available attributes ===

* '''absolute_loss''': Count of lost packets for IEC104 connection.
* '''alarms_low''', '''alarms_high''': Whether an low/high alarm occurred for a Profinet device.
* '''broadcast_packet_rate''': The attribute is the number of packets per second on average over the configured timespan for MAC broadcast packets.
* '''bytes_captured''': The amount of bytes captured by a ring buffer in the given timespan.
* '''bytes_dropped''': The amount of bytes dropped by a ring buffer in the given timespan.
* '''certificate_expires''': This is the number of days until the certificate expires. If the certificate is already expired, the value is <= 0.
* '''channel_status''': 0 means that the LACP port channel is not synchronized, 1 means that the LACP port channel is synchronized.
* '''duration''':
** ''IP: Connection end'': The time between first and last packet of the flow.
** ''SIP: Call end'': The call duration.
* '''errors''':
** ''Profinet: Traffic of Profinet devices: Whether errors occured.
* '''error_type''': equal or not equal to:
** Format Error: DNS responds a format error.
** Non-existent Domain: DNS could not find queried domain name.
** Server Failure: DNS responds server failure.
* '''frames_lost''', '''frames_repeated''', '''frames_wrong_sequence''': Whether Profinet frames have been seen with problems in sequence. For loss the count of lost frames is calculated.
* '''geolocation''': checks if a country is part of the connection
** '''Direction''': The direction of traffic
*** ''from'': Traffic is coming ''from the'' specified country
*** ''to'': Traffic is going ''to'' the specified country
*** ''any:'' The specified country is on either side of the connection, or on neither side if the inequality is selected.
* '''GoCBRef''', The GOOSE control block reference name of the device to filter.
* '''gps_sync_status''': 0 means that the GPS clock in not synchronized, 1 means that the GPS clock is synchronized.
* '''handshake_failed''': Whether TCP handshake failed, i.e. one packet of SYN, SYN-ACK, ACK sequence is missing. If no handshake is seen at all but data (e.g. Allegro was started in the middle of a connection), no incident is generated.
* '''handshake_failure_type''': The type of failure that occured during a WiFi handshake
** '''Erroneous handshake''': The handshake violated the protocol laid out by IEEE802.11. This is not an authentication failure, this is a technical issue with a network device, or an issue with signal strength at the multimeter.
** '''Failure to authenticate''' '''(WPA)''': A client attempted to join a network but failed to authenticate via WPA2 or WPA3. This indicates a problem during the EAPOL key derivation (most likely invalid credentials).
** '''Failure to authenticate (WEP)''': A client attempted to join a network but failed to authenticate via WEP. This indicates a general authentication failure in an authentication frame. More information can be found in the details panel of the offending authentication frame on the handshake details page.
** '''Failure to (re)associate''': A client attempted to join a network, succeeded authentication but ultimately failed to associate with the network. More information can be found in the details panel of the offending (re)association response frame on the handshake details page. Note that association happens ''after'' successful WEP authentication, but ''before'' WPA authentication.
* '''handshake_time''': The TCP handshake time between the first SYN packet and the ACK packet for the SYN/ACK packet of the server.
** '''client_handshake_time''': The TCP handshake time between the SYN/ACK packet of the server and the ACK packet of the client.
** '''server_handshake_time''': The TCP handshake time between the first SYN packet of the client and the SYN/ACK packet of the server.
* '''interface_speed''': The current speed of the interface in Mbit/s.
* '''interface_status''': 0 means interface is down, 1 means interface is up.
* '''jitter''':
** ''SIP: Call end'': The average jitter of the call, using the maximum value of both call sides.
** ''RTP: Traffic for RTP connections'': The average jitter of the RTP connection for the given timespan, using the maximum value of both directions.
* '''l4_protocol''': The layer 4 protocol. Can be TCP, UDP or other.
* '''l7_protocol''': The layer 7 protocol short name. Can also be a list, e.g. "HTTP, SSH, DHCP"
* '''local_ip''': Whether the IP is local (10/8, 172.16/12, 192.168/16, 169.254/16, fe80::/10, fc00::/7)
* '''link_speed_difference''': This is the absolute difference between the speeds of both interface of a link in Mbit/s.
* '''mac_count''': The number of different MAC addresses for the corresponding IP address.
* '''max_jitter''': The max jitter value for a Profinet device in % in a given timespan.
* '''mos''': The average MOS quality value of the call, using the minimum of both call sides.
* '''new_connections''': The amount of newly created connections (TCP and UDP) for the given timespan.
* '''not_in_order''': Count of not in order packets for IEC104 connection. The sequence number could be too high, too low or repeated.
* '''packet_rate''': The packet rate in packets per second on average during the configured timespan.
* '''packet_rate_increase''': The packet rate increase in % during the configured timespan compared to the average packet rate of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''percent_loss''':
** ''SIP: Call end'': The percentage of RTP packet loss for the call, accounting packets from both directions.
** ''RTP: Traffic for RTP connections'': The percentage of RTP packet loss for the given timespan, accounting packets from both directions of the RTP connection.
** ''IEC104: Traffic for IEC104 connections'': The percentage of IEC104 packet loss for the given timespan, accounting packets from both directions of the IEC104 connection.
* '''percent_transmissions''': The amount of TCP retransmission as a percentage of the total bytes.
* '''port_range''': The TCP or UDP port. Can be also a range, e.g. 80,443,8443-8445
* '''pppoe_discovery_packets''': The number of PPPoE discovery packets seen during the configured timespan.
* '''response_time''': The response time of IEC104 ACT requests and ACTCON replies.
* '''retransmission_ratio''': The TCP retransmission ratio seen in the configured timespan.
* '''since_start_time''':
** ''MAC: New L7 protocol'': This is the number of seconds after packet processing start when a new Layer-7 protocol for the MAC address appeared.
** ''MAC: New MAC address'': This is the number of seconds after packet processing start when the MAC address appeared. This is useful to only report new MAC address after some learning time.
** ''IP: New local IP address'': This is the number of seconds after packet processing start when the IP address appeared. This is useful to only report new IP address after some learning time.
** ''IP: New local L7 protocol'': This is the number of seconds after packet processing start when the Layer-7 protocol for the IP address appeared.
** ''Global: Connection start'': This is the number of seconds after packet processing start when the connection hast been started. This is useful to only report new connections after some learning time.
* '''status''': The call status code (a three digit number, like 200 for Success)
* '''tcp_handshake_time''': The TCP handshake time.
* '''tcp_fin_packets''': The number of TCP FIN packets (RX + TX) seen in the configured timespan.
* '''tcp_rst_packets''': The number of TCP RST packets (RX + TX) seen in the configured timespan.
* '''tcp_syn_packets''': The number of TCP SYN packets (RX + TX) seen in the configured timespan.
* '''throughput''': The throughput bandwidth in bit/s on average during the configured timespan.
* '''throughput_increase''': The throughput bandwidth increase in % during the configured timespan compared to the average throughput of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''time_offset''': The time offset between the local time and the timestamp seen in the PTP packet.
* '''time_since_first_unanswered_request''': This is the time span between when the trigger is checked and the first DNS request that has not been answered by the DNS server.
* '''time_since_last_mac''': This is the number of seconds between changed MAC addresses. If, for examples, dynamic IP assignment is used, changing MAC addresses is normal so the test can be limited to only a certain amount of time.
* '''tls_alert_level''': The alert level of a TLS alert packet. Can be 'fatal', 'warning' or 'unknown'. A fatal alert will be sent if e.g. TLS handshake failed and connection shall be closed.
* '''total_bytes''':
** ''IP: Connection end'': The total number of bytes seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of bytes seen in the configured timespan.
** '''total_callee_bytes''': The number of bytes seen for the callee of the call.
** '''total_caller_bytes''': The number of bytes seen for the caller of the call.
* '''total_packets''':
** ''IP: Connection end'': The total number of packets seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of packets seen in the configured timespan.
** '''total_callee_packets''': The number of packets seen for the callee of the call.
** '''total_caller_packets''': The number of packets seen for the caller of the call.
* '''ttl_change''': Whether TTL or hop limit has changed.
* '''type''': The type of PPPoE discovery packet (PADI, PADO, PADR, PADS, PADT or any).
* '''used_size''': The percentage of the ring buffer that needs to be filled.
* '''used_tls_version''': The TLS version (SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3)
* '''window_below_mss''': Whether the smallest announced TCP window was below the TCP MSS value. An additional offset is available, to check whether window was smaller than MSS + x bytes.
* '''zero_window_packets''': The number of packets with a TCP window of 0 for both directions of the flow.
* '''zero_window_packets''': The number of zero window packets seen in the configured timespan.

=== Capture settings ===
It is possible to automatically capture traffic for occurred incidents. These global settings control where capture files are stored and the capturing itself can be enabled for each rule separately.

The incident capture feature requires an active packet ring buffer since the packets are extracted from the buffer at the end of the incident period.

Available settings:

* Capture cooldown period: For each rule a cooldown period prevents multiple captures from happening in fast succession. By default, new captures happen firstly after 5 seconds, but any other value of at least 1 second can be configured. The cooldown is applied to each rule separately, but for each individual rule it does not matter if the same or a different entity triggers an incident. The incident is still reported within the cooldown period, but no additional capture is started.
* Storage device: Select the storage device where the captures should be stored on.
* Storage directory: Enter the directory where capture files should be stored or leave empty to use the top level directory.
* Select packet ring buffer to capture from: if multiple ring buffer cluster are in use, you can select which ring buffer to use for extraction.
* Capture profile: A capture profile can be configured to apply packet truncation rules to the capture file. If unset, the complete packets are captured (if the ring buffer uses separate truncation rules, truncated packets might still be within the capture file).

== Time Profiles ==
Incident rules can be active configured to be active in configured time spans (time profiles).

Every time profile allows the user to define one or more time spans per day of the week in which a rule should be active. After saving the user is able select the time profile when editing the rule.

Notes: Overlapping time spans will be merged. The earliest a time span is allowed to start is 0 and the latest end is 24, minutes are not allowed. The rule is not active for a day if there is no time span defined for the day.

== Channel configuration ==
[[File:Incidents channels.png|thumb|600x600px|Channel configuration]]
Incidents can be reported on different channels. The configuration allows to add new channels so they can be selected in the rule configuration described above.

Each channel can be of type:

'''email''' Incidents will be sent to the email address configured in the [[Global settings]].

'''kafka''' The incidents are sent to a topic on the configured Apache Kafka server. The message is the same as for syslog.
* Bootstrap Server: hostname/ip:port of a Kafka Broker or multiple Brokers separated by comma
* Protocol: Plaintext (no authentication, no encryption), SASL Paintext (Plain authentication, no encryption), SASL SSL (Plain authentication, TLS/SSL encryption)
* Ignore TLS Certificate: Ignore the TLS Certificate of the Brokers (only SASL SSL)
* Username: Broker Login (only SASL)
* Password: Broker Login (only SASL)
* Topic: The name of the topic into which the Incidents are sent.

'''snmp_trap''' Incidents will be sent to the configured SNMP trap receiver. A MIB file with the Allegro Network Multimeter SNMP trap definitions is available for download in the channel configuration dialog.
* Version: Supported SNMP version of the trap receiver (SNMP v2c or SNMP v3)
* Trap receiver (manager) hostname/IP: The trap receiver hostname or IP address

''SNMP v2c'':
* Community name: SNMP community name expected by the trap receiver

''SNMP v3'':
* Authentication protocol: Protocol for authenticated messages (MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512)
* Authentication password: Pass phrase for authenticated messages
* Privacy protocol: Protocol for message encryption (AES, DES)
* Privacy password: Pass phrase for message encryption
* Security name: Security name for authenticated SNMP messages
* Security level: Security level for SNMP messages (noAuthNoPriv, authNoPriv, authPriv)
* Engine ID: Authoritative (security) engineID (hexadecimal number)

'''syslog''' Incidents will be sent to the configured syslog server via TCP on any TCP or UDP port.

[[File:Incidents add channel.png|thumb|alt=|none|Adding a new channel]]
Each channel also uses a minimum severity setting, so only incidents are reported which are of at least that severity.

Each channel can be configured to only handle incidents from live traffic or from replayed traffic.

Some incidents cannot be configured via rules and you can choose to get those incidents also via email by enabling the settings at the lower part of the settings page.

== Other settings ==

=== Interface burst incident ===
[[File:Incidents others.png|thumb|600x600px|Other incidents]]
Burst incidents with milli-second resolution can be generated when the interface throughput exceeds a configurable threshold. The incident contains a graph of traffic for that interface with some data points before and after the threshold has been exceeded depending on the measurement interval. A PCAP link for capturing from the packet ring buffer is shown. For further investigation of that incident, the button "Use as global time range" can be used to set the global range to the start and end of the incident graph (at least 5 seconds) so that all modules of the Allegro Network Multimeter show that time span.

The incident generation can be configured in the "Other settings" tab as follows:
* '''Report "throughput threshold exceeded" with severity''': report an incident with the selected severity level if the throughput of any network interface exceeded.
* '''Throughput threshold (Mbit/s)''': The threshold is configured in Mbit/s.
* '''How long throughput must be above threshold to generate incident (in milliseconds)''': The throughput must exceed the threshold for this duration in order to generate the incident. If set to zero (default) the incident is generated immediately after the threshold has been exceeded.
* '''Throughput cool-down period between two incidents in milliseconds''': Defines the time after an incident where no new incident is generated even if the threshold is exceeded. If this period is passed, throughput incidents could be generated again.
Since each burst incidents stores the high resolution traffic graph, this feature uses a significant amount of memory. The actual amount is shown below and also depends on the maximum number of incidents configured in the section below.

=== Generic incident settings ===
This section allows to modify generic settings regarding the incident feature:

* '''Maximum number of stored incidents''': This value defines how many incidents are stored before old incidents are removed. Increasing this value also increased the amount of memory reserved for this feature. The corresponding value for the active setting is shown below, changing the configuration value requires a restart of the packet processing to take affect.

== Occured incidents ==
This page shows up to the last incidents occurred on the system. The table can be filtered for specific severity levels, as well as for specific trigger sources by selecting the trigger from the drop down menu.
[[File:Incidents list filter.png|thumb|600x600px|Filter incidents by severity or trigger]]
The list can also be filtered for the subject of the incident.

Individual incidents can be viewed in detail by clicking on the subject. The details page shows detailed information including links to the relevant measurement page.

Incidents can be deleted individually by clicking on the delete button next to the incident, or all incidents can be deleted by clicking on the button on the top right of the page.

The number of incidents available in this view is limited by a configurable number (firmware <4.1 was limited to 1000), the configuration as available in the "Other settings" tab.

== Statistics about incident rules ==
[[File:Incidents stats.png|thumb|600x600px|Statistics about rules]]
This page shows graphs about how often each rule has been hit both in absolute numbers as well as relatively to how often the rule has been checked.

== Incident list per measurement modules ==
Since incidents are triggered by different measurement modules (as indicate by the prefix of the trigger name, like the mac or ip module), the list of incidents from that specific module can also be seen in the corresponding tab of the measurement module for quicker access. This per-module view only lists those incidents coming from that module, all other potential incidents are hidden and must be accessed in their corresponding module page, or in the global view in the "Generic -> Incident" menu.

== Limitations ==
Some technical limitations apply:

* continuously checked triggers like "IP traffic" are only evaluated if there was at least one packet in the corresponding time interval. Therefore, rules check for zero packet count or throughput will never match.

WiFi module

2024-09-18T11:57:10Z

Robert: Add pictures for WiFi Handshake analysis

This module analyses IEEE 802.11 frames either acquired using the WiFi monitoring feature (see [[WiFi|WiFi interface settings]]) or encapsulated in special packets (https://www.wireshark.org/docs/dfref/p/peekremote.html). It also provides statistics when analyzing PCAPs with a Radiotap link type and IEEE 802.11 packets.

=== Statistics ===

==== '''Channel statistics''' ====
[[File:Ieee 802 11 channels.png|thumb|300x300px|WiFi channel view]]
This page shows a list of all WiFi channels on which traffic is seen and offers the ability to capture the traffic of each channel. The table contains the following data:

* Frequency: the frequency of the channel in MHz. This uniquely identifies a channel as the channel numbers themselves are ambiguous.
* Channel: the channel number. These numbers are ambiguous as there exists a channel 1 in the 2.4GHz range as well as in the 5GHz range.
* Number of BSS: The number of BSS active on this channel.
* Active BSS within the last hour: the number of BSS that were active on this channel during the last hour.
* Packets: the number of packets seen on this channel.
* Packets retransmitted: the number of retransmitted packets seen on this channel. (firmware >= 4.2)
* Bytes: the number of bytes seen on this channel.
* Bytes retransmitted: the number of retransmitted bytes seen on this channel. (firmware >= 4.2)
* Graph: Multigraph selection that can show packet rate and data rate history.
The channel frequency can be clicked on get a list of BSS in that specific channel. This table contains the same information as the global table in the BSS statistics.

==== BSS statistics ====
[[File:Ieee 802 11 bss list.png|thumb|600x600px|BSS list]]The table shown on this page lists all so-called "base service sets" which are usually the access points and offers the ability to capture the traffic of each BSS.

The table contains the following data:

* BSS ID: This is the MAC address of the station.
** In firmware >= 3.4, we also show the number of other BSS IDs of the same device, based on their MAC addresses. When following the link to the BSS detail page, the other BSS are listed on that page.
* NIC vendor name: This is the vendor name of the MAC addresse.
* SSID: When available, the SSID is shown for this BSS (firmware >= 3.4)
* AP name: When available, the AP name is shown (firmware >= 3.4)
** Note: The AP name is Cisco specific extension of beacon frame attributes and therefore only available for specific devices.
* Subscribers: This column shows the number of MAC addresses communication from or to this BSS (Firmware >= 3.4)
** The number of clients in parentheses are the number of unicast addresses different than the BSS MAC address.
** The actual subscribers can be seen in the BSS detail page.
* Current channel: This is the channel the BSS is currently operating on (firmware >= 3.4)
* Current frequency: This is the frequency the BSS is currently operating on (firmware >= 4.0)
* Current channel utilization: This value is extracted from beacon frames indicating the percentage of time the channel was active (firmware >= 3.4)
* Current frequency: This classifies the BSS frequency into 2.4 GHz, 5 GHz, or 0 for other frequencies
* packets transmitted: This is the number of packets that have been analyzed for this BSS. (firmware >= 4.2)
* packets retransmitted: This is the number of retransmitted packets that have been analyzed for this BSS. (firmware >= 4.2)
* packets retransmitted ratio: This is the proportion of retransmitted packets that have been analyzed for this BSS. (firmware >= 4.2)
* bytes transmitted: This is the number of bytes that have been analyzed for this BSS.
* bytes retransmitted: This is the number of retransmitted bytes that have been analyzed for this BSS. (firmware >= 4.2)
* bytes retransmitted ratio: This is the proportion of retransmitted bytes that have been analyzed for this BSS. (firmware >= 4.2)
* Signal/noise level: These values indicate the signal quality of the BSS.
** It uses information from packets sent from or to the BSS to give an indication ab out the overall quality.
* Graph: Multigraph selection for detailed information over time:
** Packets: this is the number of frames seen over time
** Packets retransmitted: this is the number of retransmitted frames seen over time (firmware >= 4.2)
** Bytes: this is the number of bytes seen over time
** Bytes retransmitted: this is the number of retransmitted bytes seen over time (firmware >= 4.2)
** dbm signal/noise: the signal and noise level over time
** Channel: This is the channel used at any given time (firmware >= 3.4)
[[File:Ieee 802 11 client list.png|thumb|300x300px|WiFi client list]]

==== Client statistics ====
This page shows all clients devices (unicast devices other than BSS) that have been seen in QoS and beacon frame.

The table shows the client MAC address, its vendor name and in how many BSSs this client was active.
[[File:Ieee 802 11 client detail bss.png|thumb|300x300px|WiFi client detail]]
When clicking on the client address, a detailed page is shown. The BSS tab shows which BSS were actually used at which time so it is possible to identify how often a client switched access points.

==== Per-BSS statistics ====
For each BSS MAC address, more detailed information can be shown by clicking on the MAC address in the BSS list.
[[File:Ieee 802 11 bss detail.png|thumb|300x300px|WiFi BSS details]]
The detail page shows an overview for this BSS ID and contains additional tabs for the list of subscribers and network endpoints of that base service set, as well as the list of frequencies, channels, and bands used by this base service set.

The overview tab shows all information from the BSS table and also all MAC addresses of other BSS that are handled by the same physical device.

==== BSS-Client details ====
In the BSS subscribers list on the BSS details page, information for each subscriber in the BSS is shown. A subscriber is any MAC that has sent a unicast frame to the BSS. This table contains a "Handshakes seen" column which displays the number of handshake a client has attempted with the BSS. Clicking on the "Details" link leads to a new details page for the BSS/Client pair.

This page displays information about the client profile and the most recent handshake. The client profile contains the decoded data transmitted by the client in a (re)association request frame. It contains information about the capabilities of the client (this includes supported operating frequencies, power saving mechanisms, cryptographic ciphers, beamforming information, ...). Each category is collapsible by clicking on the title text, and some of the categories are collapsed by default.

The "Handshake" tab displays the most recently seen handshake (successful or not) as a flowchart diagram. The page consists of the diagram on the left side, and a details panel on the right side. Clicking on an element in the flowchart will populate the details panel with additional information about the frame (if available). To the left of the flowchart there are timestamps (in absolute and relative format) showing when a frame was sent.

The handshake analysis also evaluates the correctness of the handshake. If a frame does not adhere to the IEEE802.11 specification (for example the client sends an association request before authenticating with the BSS) or a frame contains invalid information these frames will be marked as invalid. Frames that are technically allowed but unexpected at the current stage of the handshake (for example spurious probe requests after association) are marked as dubious. Dubious frames are unproblematic under normal circumstances. An invalid frame might be an indicator of a misconfigured wifi device or poor signal quality at the Allegro Multimeter's location. Incident rules can be created to trigger when invalid handshake frames are seen, or when a handshake fails (for whatever reason).

The following details are displayed in the details panel:
[[File:WiFi Client Profile.jpg|thumb|357x357px|Example WiFi Client Profile decoded from an association request]]
{| class="wikitable mw-collapsible mw-collapsed"
|+Authentication
|Authentication algorithm
|The algorithm used for authentication with the BSS. Usually "Open Systen" indicates WPA2, and "SAE" indicates WPA3
|-
|Sequence number
|The current step in the authentication process
|-
|Status
|The status code of the authentication
|}
[[File:WiFi Handshake.jpg|thumb|356x356px|Example of a WPA2 handshake]]
{| class="wikitable mw-collapsible mw-collapsed"
|+(Re)association response
|Capabilities
|A list of capabilities the responder has. This is an overview of the client profile of the responder
|-
|Status
|The status code of the association
|-
|Association ID
|An ID given to the client by the BSS, used in future reassociations.
|}
{| class="wikitable mw-collapsible mw-collapsed"
|+Deauthentication / Disassociation
|Reason
|A code describing the reason why the client (was) deauthenticated/disassociated
|}
{| class="wikitable mw-collapsible mw-collapsed"
|+EAPOL-Key
|Descriptor version
|Describes the cryptographic authentication and key management mechanism used in the handshake
|-
|Key type
|Whether this frame is part of the 4-way handshake
|-
|Install
|Whether the client shall install the key derived from this frame
|-
|Key Ack
|Whether the client needs to respond to this frame
|-
|Key MIC
|Whether or not this frame contains a MIC
|-
|Secure
|Set to "true" once initial key exchange is complete (EAPOL-Key 3 and onwards)
|-
|Error
|Whether an error occured during the handshake
|-
|Request
|Set to "true" by the client when they request the initiation of a handshake
|-
|Encrypted Key Data
|Whether the key data in this frame is encrypted
|-
|Key length
|Length of the temporal key
|-
|Key replay counter
|Number of exchanges carried out during this handshake
|-
|Key nonce, IV, RSC, MIC
|Cryptographic values used in the key derivation
|-
|Key data length
|Length of the key data (0 means no key data is present)
|-
|Key Data
|Key Data
|}

=== Traffic processing ===
There are currently four kinds of 802.11 traffic that can be analyzed:

# Live packet processing of IEEE 802.11 packets acquired with the WiFi monitoring feature (see [[WiFi|WiFi interface settings]]).
# Radiotap PCAP files that contain IEEE 802.11 packets.
# PEEKREMOTE packets. This kind of traffic is generated by access points and is send via UDP to a specified IP address and port. To analyze this traffic, the endpoint mode has to be enabled on an interface which receives this traffic. In the [[Global settings#Endpoint mode|endpoint mode configuration]], an IP address and port can be configured for which the Allegro Network Multimeter accepts packets. PEEKREMOTE packets usually do not contain complete IP packets, only 802.11 statistics that are evaluated by the Allegro Network Multimeter.
# CAPWAP encapsulated packets. In contrast to PEEKREMOTE, CAPWAP packets encapsulate complete IP packets which itself contain 802.11 information. Therefore, the endpoint mode must be configured for a specific IP and port and the [[Global settings#Tunnel view mode|tunnel view mode]] must be enabled too to let the Allegro Network Multimeter look inside the encapsulated packets.

File:WiFi Handshake.jpg

2024-09-18T11:55:30Z

Robert:

WiFi Handshake example

File:WiFi Client Profile.jpg

2024-09-18T11:53:29Z

Robert:

Client Profile example

WiFi module

2024-09-18T11:47:41Z

Robert: Add information for handshake analysis

This module analyses IEEE 802.11 frames either acquired using the WiFi monitoring feature (see [[WiFi|WiFi interface settings]]) or encapsulated in special packets (https://www.wireshark.org/docs/dfref/p/peekremote.html). It also provides statistics when analyzing PCAPs with a Radiotap link type and IEEE 802.11 packets.

=== Statistics ===

==== '''Channel statistics''' ====
[[File:Ieee 802 11 channels.png|thumb|300x300px|WiFi channel view]]
This page shows a list of all WiFi channels on which traffic is seen and offers the ability to capture the traffic of each channel. The table contains the following data:

* Frequency: the frequency of the channel in MHz. This uniquely identifies a channel as the channel numbers themselves are ambiguous.
* Channel: the channel number. These numbers are ambiguous as there exists a channel 1 in the 2.4GHz range as well as in the 5GHz range.
* Number of BSS: The number of BSS active on this channel.
* Active BSS within the last hour: the number of BSS that were active on this channel during the last hour.
* Packets: the number of packets seen on this channel.
* Packets retransmitted: the number of retransmitted packets seen on this channel. (firmware >= 4.2)
* Bytes: the number of bytes seen on this channel.
* Bytes retransmitted: the number of retransmitted bytes seen on this channel. (firmware >= 4.2)
* Graph: Multigraph selection that can show packet rate and data rate history.
The channel frequency can be clicked on get a list of BSS in that specific channel. This table contains the same information as the global table in the BSS statistics.

==== BSS statistics ====
[[File:Ieee 802 11 bss list.png|thumb|600x600px|BSS list]]The table shown on this page lists all so-called "base service sets" which are usually the access points and offers the ability to capture the traffic of each BSS.

The table contains the following data:

* BSS ID: This is the MAC address of the station.
** In firmware >= 3.4, we also show the number of other BSS IDs of the same device, based on their MAC addresses. When following the link to the BSS detail page, the other BSS are listed on that page.
* NIC vendor name: This is the vendor name of the MAC addresse.
* SSID: When available, the SSID is shown for this BSS (firmware >= 3.4)
* AP name: When available, the AP name is shown (firmware >= 3.4)
** Note: The AP name is Cisco specific extension of beacon frame attributes and therefore only available for specific devices.
* Subscribers: This column shows the number of MAC addresses communication from or to this BSS (Firmware >= 3.4)
** The number of clients in parentheses are the number of unicast addresses different than the BSS MAC address.
** The actual subscribers can be seen in the BSS detail page.
* Current channel: This is the channel the BSS is currently operating on (firmware >= 3.4)
* Current frequency: This is the frequency the BSS is currently operating on (firmware >= 4.0)
* Current channel utilization: This value is extracted from beacon frames indicating the percentage of time the channel was active (firmware >= 3.4)
* Current frequency: This classifies the BSS frequency into 2.4 GHz, 5 GHz, or 0 for other frequencies
* packets transmitted: This is the number of packets that have been analyzed for this BSS. (firmware >= 4.2)
* packets retransmitted: This is the number of retransmitted packets that have been analyzed for this BSS. (firmware >= 4.2)
* packets retransmitted ratio: This is the proportion of retransmitted packets that have been analyzed for this BSS. (firmware >= 4.2)
* bytes transmitted: This is the number of bytes that have been analyzed for this BSS.
* bytes retransmitted: This is the number of retransmitted bytes that have been analyzed for this BSS. (firmware >= 4.2)
* bytes retransmitted ratio: This is the proportion of retransmitted bytes that have been analyzed for this BSS. (firmware >= 4.2)
* Signal/noise level: These values indicate the signal quality of the BSS.
** It uses information from packets sent from or to the BSS to give an indication ab out the overall quality.
* Graph: Multigraph selection for detailed information over time:
** Packets: this is the number of frames seen over time
** Packets retransmitted: this is the number of retransmitted frames seen over time (firmware >= 4.2)
** Bytes: this is the number of bytes seen over time
** Bytes retransmitted: this is the number of retransmitted bytes seen over time (firmware >= 4.2)
** dbm signal/noise: the signal and noise level over time
** Channel: This is the channel used at any given time (firmware >= 3.4)
[[File:Ieee 802 11 client list.png|thumb|300x300px|WiFi client list]]

==== Client statistics ====
This page shows all clients devices (unicast devices other than BSS) that have been seen in QoS and beacon frame.

The table shows the client MAC address, its vendor name and in how many BSSs this client was active.
[[File:Ieee 802 11 client detail bss.png|thumb|300x300px|WiFi client detail]]
When clicking on the client address, a detailed page is shown. The BSS tab shows which BSS were actually used at which time so it is possible to identify how often a client switched access points.

==== Per-BSS statistics ====
For each BSS MAC address, more detailed information can be shown by clicking on the MAC address in the BSS list.
[[File:Ieee 802 11 bss detail.png|thumb|300x300px|WiFi BSS details]]
The detail page shows an overview for this BSS ID and contains additional tabs for the list of subscribers and network endpoints of that base service set, as well as the list of frequencies, channels, and bands used by this base service set.

The overview tab shows all information from the BSS table and also all MAC addresses of other BSS that are handled by the same physical device.

==== BSS-Client details ====
In the BSS subscribers list on the BSS details page, information for each subscriber in the BSS is shown. A subscriber is any MAC that has sent a unicast frame to the BSS. This table contains a "Handshakes seen" column which displays the number of handshake a client has attempted with the BSS. Clicking on the "Details" link leads to a new details page for the BSS/Client pair.

This page displays information about the client profile and the most recent handshake. The client profile contains the decoded data transmitted by the client in a (re)association request frame. It contains information about the capabilities of the client (this includes supported operating frequencies, power saving mechanisms, cryptographic ciphers, beamforming information, ...). Each category is collapsible by clicking on the title text, and some of the categories are collapsed by default.

The "Handshake" tab displays the most recently seen handshake (successful or not) as a flowchart diagram. The page consists of the diagram on the left side, and a details panel on the right side. Clicking on an element in the flowchart will populate the details panel with additional information about the frame (if available). To the left of the flowchart there are timestamps (in absolute and relative format) showing when a frame was sent.

The handshake analysis also evaluates the correctness of the handshake. If a frame does not adhere to the IEEE802.11 specification (for example the client sends an association request before authenticating with the BSS) or a frame contains invalid information these frames will be marked as invalid. Frames that are technically allowed but unexpected at the current stage of the handshake (for example spurious probe requests after association) are marked as dubious. Dubious frames are unproblematic under normal circumstances. An invalid frame might be an indicator of a misconfigured wifi device or poor signal quality at the Allegro Multimeter's location. Incident rules can be created to trigger when invalid handshake frames are seen, or when a handshake fails (for whatever reason).

The following details are displayed in the details panel:
{| class="wikitable mw-collapsible mw-collapsed"
|+Authentication
|Authentication algorithm
|The algorithm used for authentication with the BSS. Usually "Open Systen" indicates WPA2, and "SAE" indicates WPA3
|-
|Sequence number
|The current step in the authentication process
|-
|Status
|The status code of the authentication
|}
{| class="wikitable mw-collapsible mw-collapsed"
|+(Re)association response
|Capabilities
|A list of capabilities the responder has. This is an overview of the client profile of the responder
|-
|Status
|The status code of the association
|-
|Association ID
|An ID given to the client by the BSS, used in future reassociations.
|}
{| class="wikitable mw-collapsible mw-collapsed"
|+Deauthentication / Disassociation
|Reason
|A code describing the reason why the client (was) deauthenticated/disassociated
|}
{| class="wikitable mw-collapsible mw-collapsed"
|+EAPOL-Key
|Descriptor version
|Describes the cryptographic authentication and key management mechanism used in the handshake
|-
|Key type
|Whether this frame is part of the 4-way handshake
|-
|Install
|Whether the client shall install the key derived from this frame
|-
|Key Ack
|Whether the client needs to respond to this frame
|-
|Key MIC
|Whether or not this frame contains a MIC
|-
|Secure
|Set to "true" once initial key exchange is complete (EAPOL-Key 3 and onwards)
|-
|Error
|Whether an error occured during the handshake
|-
|Request
|Set to "true" by the client when they request the initiation of a handshake
|-
|Encrypted Key Data
|Whether the key data in this frame is encrypted
|-
|Key length
|Length of the temporal key
|-
|Key replay counter
|Number of exchanges carried out during this handshake
|-
|Key nonce, IV, RSC, MIC
|Cryptographic values used in the key derivation
|-
|Key data length
|Length of the key data (0 means no key data is present)
|-
|Key Data
|Key Data
|}

=== Traffic processing ===
There are currently four kinds of 802.11 traffic that can be analyzed:

# Live packet processing of IEEE 802.11 packets acquired with the WiFi monitoring feature (see [[WiFi|WiFi interface settings]]).
# Radiotap PCAP files that contain IEEE 802.11 packets.
# PEEKREMOTE packets. This kind of traffic is generated by access points and is send via UDP to a specified IP address and port. To analyze this traffic, the endpoint mode has to be enabled on an interface which receives this traffic. In the [[Global settings#Endpoint mode|endpoint mode configuration]], an IP address and port can be configured for which the Allegro Network Multimeter accepts packets. PEEKREMOTE packets usually do not contain complete IP packets, only 802.11 statistics that are evaluated by the Allegro Network Multimeter.
# CAPWAP encapsulated packets. In contrast to PEEKREMOTE, CAPWAP packets encapsulate complete IP packets which itself contain 802.11 information. Therefore, the endpoint mode must be configured for a specific IP and port and the [[Global settings#Tunnel view mode|tunnel view mode]] must be enabled too to let the Allegro Network Multimeter look inside the encapsulated packets.

Packet ring buffer

2023-09-11T12:54:31Z

Robert: Mention comments in snapshot filter length rules

== Packet ring buffer==
The ring buffer feature allows to create a buffer of fixed size on an external storage device to which all processed packets will be recorded.
If the fixed size buffer is full then the oldest packets in the buffer will be replaced with new packets in a round-robin fashion.
If the feature is not enabled, a button titled '''Create ring buffer''' is visible.
Upon clicking on it an empty packet ring buffer is created. To actually store data, storage space needs to allocated to the Packet Ring Buffer. In the ''Configuration'' tab by clicking on a ''Allocate space for Packet Ring Buffer'' button, a dialogue will be displayed and allows you to specify the size of the ring buffer.
It must be ensured that enough space is available on the external storage device.
As soon as storage space has been allocated to the Packet Ring Buffer, packets will be stored and the graphs on the ''Statistics'' tab will reflect this:

'''Web interface'''
{| class="wikitable sortable"
|-
|[[File:Create Packet ring buffer1.png|600px|none]]
|}

{| class="wikitable sortable"
|-
|[[File:Create Packet ring buffer2.png|600px|none]]
|}

* Timestamp of oldest packet: The timestamp of the oldest packet in the ring buffer.

* Total size: The total size of the ring buffer on the external storage device.
:If the cluster packet ring buffer feature is active and the Write redundancy level is set to a different value than zero replication, an adjusted value is displayed to reflect the redundant copies of packet data.
:The raw on-disk value will be displayed next to it in parentheses.

* Used size: The currently used amount of memory in the capture buffer.
:If the cluster packet ring buffer feature is active and the Write redundancy level is set to a different value than zero replication, an adjusted value is displayed to reflect the redundant copies of packet data. The raw on-disk value will be displayed next to it in parentheses.
*Overall bytes captured since start: The amount of captured bytes since start of the packet ring buffer. Starting with version 3.6 this statistic is persisted beyond a restart of the system.
:This value may be larger than the used size in case the ring buffer is full and parts of it were overwritten.
:The history graph shows the captured traffic of the last minute or in the selected interval (if set).
*Bytes/Packets dropped since start: The traffic which was processed but could not be written to the ring buffer since the start of the packet ring buffer. Starting with version 3.6 this statistic is persisted beyond a restart of the system.
: This is usually an indicator that writes to the external storage device were not fast enough. The history graph shows the drops over time.
*Bytes discarded due to filter rules since start: The traffic which matched the filter rules criteria and was not written to the ring buffer. Starting with version 3.6 this statistic is persisted beyond a restart of the system.
: The history graph shows discarding over time.
*Data in flight: The amount of data which is currently stored in the queue that holds processed packets before they are written to the packet ring buffer.
:If larger bursts of traffic need to be stored in this queue, the size can be modified in the capture module settings.
:
When the ring buffer is full and old packets are deleted, the graphs will show the time range with no data with a dark grey background colour.
The time range before start of the ring buffer will be visualized in the same way.
When the ring buffer is running, the behaviour of the pcap capture buttons throughout the system changes: if the user interface is in live mode and a capture is started, a dialogue will appear asking you to specify from how far back in time the capture should start.
This way it is possible to e.g. capture the traffic of an IP address starting from an hour ago.
The capture will also continue with live traffic.
If the user interface is in '''back-in-time''' mode (a timespan from the past is selected) starting a capture will produce a dialogue asking to confirm that the capture will cover exactly the timespan selected.
The capture will automatically stop after the selected timespan has been processed.

{| class="wikitable sortable"
|-
|[[File:Create Packet ring buffer3.png|1200px|none]]
|}

====Packet Ring Buffer with multiple disks====
The Packet Ring Buffer feature allows you to use multiple whole disks and multiple storage space allocations on active storage devices in parallel for a single packet ring buffer.
This also allows you to optionally write redundant copies of packets to multiple disks to provide fault tolerance in case of a disk failure.

It is also possible to create multiple Packet Ring Buffers that
run in parallel. To enable multiple Packet Ring Buffers, the
option `The maximum number of concurrent packet ring buffers` in the
capture module options can be set to the required number.

If multiple Packet Ring Buffers are used, the page will show
a number of buttons at the top to switch between the different Packet Ring Buffers.
Each Packet Ring Buffer has its own statistics and configuration.

In the ''Configuration'' tab you can configure the '''Write redundancy level''' at the very top.
This level controls how many redundant copies of each packet are written.
No replication means that only a single copy of each packet is written and provides no redundancy.
This level gives the highest write bandwidth for a given number of disks; single replication means that one additional copy of each packet is written to some other disk and thus reduces the total write performance for a given number of disks to half the performance of no replication.
Double replication and triple replication writes two and three additional copies of each packet respectively.
Note that for each level to work there must be at least the number of replications + 1 disks available in the cluster.

'''Web interface'''

Below the '''Write redundancy level''' setting is the list of all disks available for use in the Packet Ring Buffer.
The following columns are displayed in the list:
*Disk: A description of the disk and its capacity.
*Enclosure: If the disk is part of a multi-disk enclosure this column will show the enclosure number along with the slot number.
*Status: If the disk has been added to the cluster this column will display the current status as '''ok''' or '''failed'''. If multiple Packet Ring Buffers are used this will also show if the disk or storage space is active in another cluster.
*Locator: For disks in a multi-disk enclosure the button displayed in this column allows to turn the slot locator LED on and off.

In the last unlabelled column, buttons are displayed which have the following functionality.

These buttons are shown for working with entire disks:
* Add to Packet Ring Buffer: Add a complete disk to the Packet Ring Buffer.
: The disk will be formatted and added as empty storage to the Packet Ring Buffer. All previous data on the disk is lost.
*Resume in Packet Ring Buffer: If the disk was previously part of a Packet Ring Buffer it can be resumed.
: The data on that disk is now part of the Packet Ring Buffer.
*Remove from Packet Ring Buffer: Remove the disk from the Packet Ring Buffer.
:The data stored on that disk is no longer part of the Packet Ring Buffer but the data is not removed from the disk. It can be resumed in the Packet Ring Buffer at a later time.
:
These buttons are shown for working active storage devices:

* Allocate space for Packet Ring Buffer: Allocate space on an active storage device and add that space to the Packet Ring Buffer. It will then be shown in the list below the active storage device.
* Delete: Removes the allocated storage space from the Packet Ring Buffer and permanently deletes it from the storage device.
* Remove from Packet Ring Buffer: Removes the allocated storage space from the Packet Ring Buffer but leaves it on the storage device.
* Resume in Packet Ring Buffer: Add a currently unused storage space from a storage device to the Packet Ring Buffer.

If a disk is missing because it was e.g. removed from the enclosure, it will be displayed in a separate list with much of the information as in the list described above but only one button with the option to remove it from the Packet Ring Buffer.

'''Web interface'''
{| class="wikitable sortable"
|-
|[[File:Cluster4.png|1200px|none]]
|}

====Packet ring buffer filter====
Rules can be configured to control the snapshot length of each packet which will be stored in the packet ring buffer.
These rules can also be used to prevent certain packets from being stored in the packet ring buffer.
This allows you to fine tune how much packet data needs to be written to the packet ring buffer.
The information about the original length of a packet will still be available in captures except when the packet was not written to the packet ring buffer at all (e.g. due to a '''discard''' rule).

These rules can be created, edited, deleted, moved up and moved down in the rules list by using the respective buttons. They can also be given names to quickly see what rule is used for what purpose.

Evaluation of the rules takes place in the order of the rules as displayed in the rules list from top to bottom.
The first rule that matches for a given packet will be applied and no further rules will be evaluated for that packet.
This means that the most generic rule should be at the bottom of the list (like e.g. ‘all packets will be discarded’) and more specific rules should be higher up in the list (like e.g ‘packets with an IP matching 192.168.1.0/24 will be fully captured’).

When creating a filter rule, a dialogue is displayed and allows the following options:
* Rule condition: Specify which packets to match.

:The input field below allows entering the corresponding value.

:{| class="wikitable"
|-
!Rule condition
!description
|-
|All packets
| everything
|-
|MAC address
|source or destination MAC address
|-
|IP address
|source or destination IP address or subnet
|-
|TCP port
|the source or destination TCP port
|-
|UDP port
|the source or destination UDP port
|-
|Layer 7 protocol
|the selected Layer 7 protocol
|-
|outer VLAN tag
|the most outer VLAN tag (directly after Ethernet header). It is also possible to match packets that have no VLAN tag at all by choosing 'no VLAN' from the drop-down menu or match packets with an arbitrary VLAN tag by choosing 'any VLAN' form the drop-down menu.
|-
| interface
|the ingress interface the packet originated from
|-
|SIP phone number
|
The number matches part of the 'From:', 'To:', 'Request-URI', 'Contact', 'P-Asserted-Identity' or 'P-Preferred-Identity' entry in a SIP INVITE packet.
*only the part between '''<nowiki>'<'</nowiki>''' and '''<nowiki>'>'</nowiki>''' of the From/To line is tested.
*value '''<nowiki>'234'</nowiki>''' will match '<nowiki>From: "Caller1" <sip:234></nowiki>', but also '<nowiki>From: "Caller2" <sip:12345@test></nowiki>'
*to match from the start, use '''<nowiki>'sip:234'</nowiki>'''

Correlating SIP packets for the same Call-ID will match.

The RTP and RTCP packets correlated to this SIP call will also match.
|-
|Calls between SIP phone number A and B
|Match SIP, RTP and RTCP packets related to SIP phone calls between both numbers
|-
|virtual link group
|the virtual link group the packet belongs to
|-
|SSL after handshake
| SSL packets that occur after the SSL handshake (the encrypted part of the SSL communication)
|}

*Negate: Controls comparison of the rule condition to the value. If this is off, the value must match.
:If this is on, the value must not match.
*Action: What shall be done with the matching packets.
:{| class="wikitable"
|-
!Action!!Description
|-
|Snapshot length
|The packet is captured with a max length as specified in the input field below. If the packet is larger, the remaining bytes will be discarded.
|-
|Discard
|Discard the whole packet.
|-
|Full
|The entire packet is captured.
|-
|Header + data
|
Capture just certain parts of the packet.

When selecting '''L3 header''', Layer 2 and Layer 3 headers are stored.

When selecting '''L3 + L4 header''', Layer 2, 3 and 4 headers are stored.

When selecting '''L3 + L4 + L7 data''', an input field is shown where the length of Layer 7 data can be configured. In this case Layers 2, 3 and 4 are stored together with the specified amount of Layer 7 data.

|}

====Analyzing the packet ring buffer====
When the packet ring buffer is activated, it is possible to restart the packet processing core and analyze all packets contained in the packet ring buffer.
When the Analyze packet ring buffer button is pressed, a dialogue will appear which allows you to choose the time range of the packet ring buffer which is to be replayed.
After confirming this dialogue, the Allegro Network Multimeter will reset all statistics and start analyzing the contents of the packet ring buffer.
Progress, statistics and the option to resume normal operation will appear on the Packet ring buffer page.

====Extracting the packet ring buffer====
When the packet ring buffer is active, the entire contents can be extracted by capturing the complete timespan that is contained within.
For convenience, a button labelled Extract packet ring buffer is available that opens the capture dialogue with the start time and end time set to the appropriate values.

Names and look-ups

2023-09-11T12:53:18Z

Robert: Add information for VLAN naming list

On this settings page, user defined names for IPs, MAC addresses and ports can be configured, as well as the configuration for active look-ups using DNS resolve or traceroute.

= User defined names =

It is possible to label IP and MAC address, as well as TCP-/UDP-ports with custom names and group them together into categories to provide easy access to specific systems.
For example, all your internal machines could be labeled to match their actual name and you can categorize them into different departments.

These user defined names are persistent and are available from start on. All entries are assigned per Allegro Appliance and not per user. An assigned name is available for all users.

== Configuration ==

The configuration of the list of user defined names is available via '''Settings -> Names and look-ups'''.

'''Web Interface'''
{| class="wikitable"
|-
|[[File:User defined names.png|800px|none]]
|}

=== IP names, MAC names and VLAN names ===

'''Adding or removing entries'''

In the tabs for IP, MAC and VLAN names, the configuration page shows on top the list of names currently set in the system.
It is possible to search for a specific entry by entering the IP or MAC address or VLAN tag, category or actual name.

Individual entries may be removed from the list by clicking at the trashcan symbol in the last column.

At the bottom of the table new elements can be added by entering the IP or MAC address or VLAN tag, the category and name of the element.
By clicking the '''plus''' symbol, the entry is added and will be used without further doing.

The complete IP, MAC and VLAN lists can be cleared by clicking the respective clear button below the table, a dialog will ask for confirmation.

Names may also be set directly at the IP or MAC detail page, see below for more information.

'''Importing IP list'''

IP names can be imported as an IP list from an external URL or a file in the format:

{| class="wikitable"
|#A line with a comment
1.2.3.1

1.2.3.2

1.2.3.3
|}

By clicking on '''Import IP list''' a dialog will be opened where you can choose to download such a list from a given URL or specify a file from your system.
The IPs are added to the already existing ones.

'''Uploading or downloading the complete list as CSV file'''

Depending on the use case, the number of elements to add may be large.
In this case it is also possible to upload a comma separated text file (.csv).
The format is simple as follows:

{| class="wikitable"
|ip,192.168.0.1,category,name
mac,00:00:00:00:00:00,category,name

vlan,4,category,name 
...
|}

Each line describes one entry.
The columns contain the following information in this order:
# Entry type. Can be '''ip''' for an IP address, '''mac''' for a MAC address or '''vlan''' for a VLAN tag.
# Actual address or tag.
# Category name.
# Entry name.

A template file which may be opened in a spreadsheet application can be downloaded using the '''Download CSV template''' button.

The final file can be uploaded by clicking the '''Upload CSV list''' button and selecting the file from your local directory.

The current list can be downloaded by clicking the '''Download''' button. The CSV file will contain IP and MAC addresses, and VLAN tags.

=== L4 port names ===

'''Adding or removing entries'''

On top of this tab, a list of configured TCP- and UDP-port names is shown.
Entries from this list can be removed by clicking the trashcan icon on the right of each entry line.

New port names can be created by clicking the '''Add port name''' button on the bottom of the list.
A configuration dialog pops up and allows to select the protocol type (TCP or UDP) and configure the port number as well as the name.

== Name display for user defined names ==

If a user defined name is configured for an IP or MAC address or VLAN tag, the name will be shown among the alternative names (which also include possible DNS, DHCP name, or other sources of information).

In the IP and MAC overview screenshots below, the IP or MAC column is highlighted to indicate such special entries for which a name is configured.

{| class="wikitable"
|-
![[File:Ap-mm-ip-list-user-defined-name.png|800px|none]] !! IP
|}

{| class="wikitable"
! [[File:Ap-mm-mac-list-user-defined-name.png|800px|none]] !! MAC
|-
|}

In the detailed page for a single IP or MAC address, you can click on the pencil symbol to directly set a name for this specific address.

{| class="wikitable"
|-
![[File:Ap-mm-ip-alternative-names.png|800px|none]] !! IP
|}

{| class="wikitable"
! [[File:Ap-mm-mac-alternative-names.png|800px|none]] !! MAC
|-
|}

== Filtering==

It is possible to enter the category or user defined name for IP and MAC filters.

Also, the '''name''' check in [[Live filtering of tables|complex filters]] matches the user defined name, like in this example:

{| class="wikitable"
|(name=systemA)
|}

It is also possible to filter for a specific category by using the '''category''' check:

{| class="wikitable"
|(category=server)
|}

In this example, the list would only show those elements for which a user defined name is set and its category contains the string '''server'''.

= DNS resolve =

The Allegro Network Multimeter can resolve IP addresses by using the DNS server known to the management interface. A reverse lookup is being performed and the retrieved naming information is shown next to the IP address in various modules.

The DNS resolving can also be configured to run periodically after an interval passed and try to resolve IPs of certain given subnets. To prevent high load on the DNS server, only 5 queries may be active in parallel.

= Traceroute =
(Starting from v4.0)

The Allegro Network Multimeter can perform a traceroute to IP addresses using the management interface.
Discovering the network hops to reach the target can take a considerable amount of time.
To trade between a swift and complete result, the following settings can be adjusted to meet the requirements:
* '''Ping count on each network hop''': higher values can compensate occasional packet losses and make the displayed packet loss ratio more representative, but increase the traceroute duration
* '''Maximum TTL value''': upper limit of discoverable network hops; lower values reduce traceroute duration but may cut off some network hops closer to the target IP
* '''Timeout per network hop''': duration of milliseconds to wait for a hop response before it fails as timed out; higher values may discover more network hops at the expense of an increased traceroute duration

The currently displayed settings will be applied after clicking the '''Save settings''' button.
To show the currently used settings, the '''Reload settings''' button needs to be clicked.
The default values can be shown by clicking the '''Load default settings''' button, they are not automatically applied.

Process traffic capture from remote device

2023-09-11T12:46:13Z

Robert: Add ERSPAN mode to example uses

The Allegro Network Multimeter can also be switched into a special mode to receive pcap stream via TCP from any remote device.
It is possible to process plain pcap files or use an additional tool to capture traffic and send it to the Allegro Network Multimeter.

This mode can be enabled or disabled, and if enabled, the port for receive packet streams can be configured. Be aware that this port is plain unencrypted TCP!

If changes to these settings are made, a restart of the measurement application is required, which can be done in the Administration page.

Every pcap file streamed to the TCP socket will be processed as it would be analysed locally from a connected storage device.
Up to 16 connections can be used simultaneously.
Since the internal clock depends on the packet time, all clocks of the sources should be (almost) synchronous (for example by using NTP time synchronization).

To analyze a bunch of files chronologically, stream the files one at a time to the Multimeter.
The timestamps of the actual packets are used for the internal time clock of the Allegro Network Multimeter so network problems and events can be traced back to the actual time they happened.

The clock of multiple files should not run backwards, i.e. when a file from an older capture time is processed after a file from a newer capture time.
If such files need to be analyzed, the measurement core should be started via the Administration page.

The [[System Info Page]] shows the current packet processing mode, indicating whether live traffic from local network interface is processed, live traffic from the TCP port, or a pcap file from the storage device is analyzed.

'''Web Interface'''
{| class="wikitable"
|-
| [[File:Process traffic capture from remote device.png|600px|none]]
|}

== Receive packets from remote capture device ==

=== Example uses ===

The capturing tool can be downloaded from the '''Remote packets''' page in the '''Generic''' section. The tool allows to capture packets from any or a specific network device, and also to stream a file to the Allegro Network Manager:

* Processing a local pcap file:

./ap_capture_to_remote -f trace.pcap allegro-mm-abcd 8001

* Live-capture from eth0:

sudo ./ap_capture_to_remote -i eth0 allegro-mm-abcd 8001

or permit access to network interfaces only instead of full root permissions:

sudo setcap cap_net_raw=ep ap_capture_to_remote
./ap_capture_to_remote -i eth0 allegro-mm-abcd 8001

* Live-capture from all network devices:
sudo ./ap_capture_to_remote allegro-mm-abcd 1234

In all examples, host and port number must be set according to the actual Allegro Network Multimeter device and the configured port number.

===== ERSPAN mode =====
The capturing tool also supports sending the packets as ERSPAN-wrapped packets. This mode is used with the `-e` flag (which needs an ERSPAN session ID as a parameter). If this mode is used, the port doesn't need to be specified anymore.
sudo ./ap_capture_to_remote -e 1234 allegro-mm-abcd
{| class="wikitable"
|-
| [[File:Process traffic capture from remote device1.png|1000px|none]]
|}

=== Alternative tools ===

The Allegro Network Multimeter also accepts plain pcap files on the configured port.
That means it is possible to stream files to the device or use tcpdump with additional filters.

Example uses are:

* Processing a local pcap file:

cat trace.pcap | netcat allegro-mm-abcd 1234

* Live-capture via tcpdump:

sudo tcpdump -i eth0 -s 0 -U -w /dev/stdout | netcat allegro-mm-abcd 1234

NTP module

2023-09-11T12:38:44Z

Robert: Add information about Jitter and Peer dispersion

'''Web interface'''
{| class="wikitable sortable"
|-
|[[File:NTP statistics.png|800px|none|right]]
|}

The NTP module processes NTP traffic. It stores the NTP servers, including their clients, and further NTP related information.
The following documentation is based on the RFCs. See also http://www.faqs.org/rfcs/rfc1305.html

'''NTP server IP'''

This is the IP of a seen NTP server. This status is assigned when this IP has sent a NTP with flag 4. Therefore every clock that is configured as a reference clock will be stored as a server.

'''Alternative name'''

This column shows all known name information about the server IP.

'''Leap indicator'''

If the leap indicator is set to 1 respectively 2 a leap second will be inserted respectively removed this day.
A leap indicator of 0 means that everything is okay and no insertion or removing of leap seconds is necessary.
The clock is unsynchronized if the leap indicator is set to 3 (warning).
{| class="wikitable"
|-
! Leap indicator !! explanation
|-
| 0 || no second will be removed/inserted
|-
| 1 || a leap second will be inserted
|-
| 2 || a leap second will be removed
|-
| 3 || clock is in an unsynchronized state (warning)
|}

'''Version number'''

The currently used version number. Recent version is NTPv4.

'''Poll'''

The minimum interval in seconds between transmitted messages. It is specified in log2.

'''Stratum'''

The stratum is the hierarchy level of the NTP server and represents the distance from the reference clock.

{| class="wikitable"
|-
! Stratum !! explanation
|-
| 0 || unspecified
|-
| 1 || primary reference (e.g. an atom clock)
|-
| 2-15 || one plus the stratum of the reference clock
|-
| 16 || indicates an unsynchronized state
|}

'''Precision'''

The precision of the reference time clock, more precise: A precision value 25ms indicates that the reference clock is able to maintain this precision.

'''Root delay'''

This number indicates the total roundtrip delay to the primary reference source at the root of this subnet.

'''Root dispersion'''

This is the maximum error relative to the primary reference source at the root of this subnet.

'''Peer dispersion'''

This is the maximum error of the peer clock relative to the local clock over the network path between them.

'''Last origin timestamp'''

Time at the client when the request was sent to the server.

'''Last receive timestamp'''

Time at the server when the client request arrived.

'''Last reference timestamp'''

Time when the system clock was last set.

'''Last transmit timestamp'''

Time at the server when the response was sent to the client.

'''Number of clients'''

The number of NTP users that use this clock as a reference.

'''Jitter'''

The jitter (psi) is defined as the root-mean-square (RMS) average of the most recent offset differences, and it represents the nominal error in estimating the offset. Jitter is a quantity calculated for each server/client pair. The min/med/max values are the minimum/median/maximum jitter of all the clients that have connected to the server.

'''Remark for chrony users'''

Chrony sets the reference timestamp to zero and the received/transmit timestamp to a random value. Only the origin timestamp is correct. This also causes the jitter calculation to become invalid since the exact timestamps are needed.

'''Rows without values'''

It can happen that rows have no values respectively show only ‘-‘ for most values. This indicates that this server/client has received a NTP packet but didn’t send a response to the client/server.
That means that this server/client is recorded as a NTP member, but there is no further information about it, because it never sent a NTP packet.

Capture module

2023-03-29T10:08:56Z

Robert: /* Using expert filters to start captures: add pppoe filters */

==Capture module ==
The Allegro Network Multimeter allows direct capturing of network traffic as a HTTP download to your computer. No packet data is stored on the device itself. Traffic can be directly filtered for specific packets, only the relevant packets will be captured. In addition, it is also possible to capture network traffic to an attached storage device, see the settings section below for details. Capturing network traffic is usually started by clicking on a PCAP button in a certain module. These buttons allow capturing specific traffic, for example for a certain IP address or a network protocol. The capture module allows to configure filter for traffic that has not even started right now, for example for an IP address that is not in use at the moment but might be used later. The capture module page displays all currently running captures and allows starting new captures with specific filters.

{| class="wikitable sortable"
|-
|[[File:Generic modules.png|800px|none|right]]
|}

=== Current captures ===
The first part of the page displays all downloads running for the current user session, and all downloads running for other user sessions (like when a download has been started outside the browser by directly using command line tools such as wget or curl).
The list contains the client IP and port of the user running the download. The next three counters describe the number of packets captured for the corresponding filter, the number of packets dropped by the capturing module, and the number of ignored packets. Packet drops happen when more packets are captured than can be transferred via HTTP to the client. Ignored packets do not match the given capture filter. The following columns list the applied filter criteria. The last column contains a button to stop the corresponding download. Downloads can also be stopped by clicking the same capture button that started the capture in the corresponding module. If multiple devices have been configured, the list also contains all captures from all multi-devices which can be stopped individually.

==== Finished captures ====
This list shows the last captures that have finished. It shows up to 100 entries while the oldest entries are discarded when the list is full. For each entry the following information is displayed: the packet capturing mode, the type of capture, the start- and end-time of the capture (the actual real-time when the capture was initiated and ended), the number of captured/dropped/ignored packets during the capture, the amount of data generated for the capture (along with the average throughput of e.g. the capture download) and the capture filter which was used for the capture.The button '''Delete list of finished captures''' will delete all entries from this list.

==== Recent filters ====
This list shows the most recently used capture filters for the current user. The most recent capture filter is displayed on the top. Next to each capture filter there is a button to permanently save this capture filter as a favorite as well as a button to simply start a capture with this filter again. The '''Use as expert filter''' button will copy the capture filter into the expert filter input field and allows for customizing the capture. The button '''Delete list of recent filters''' will delete all entries from this list.

==== Favorites ====
This list shows favorite capture expressions. A capture can be marked as a favorite either in the capture dialog by clicking on the star button in the top right corner or by marking it as a favorite in the '''Recently captured''' list. A description can be given and will be displayed in this list. For each favorite capture a PCAP button is available to simply start this capture again. The '''Remove favorites''' button allows for cleaning the list. The '''Use as expert filter''' button will copy the capture filter into the expert filter input field and allows for customizing the capture.

==== Planned captures ====
On this tab captures to a storage device can be planned ahead of time and these captures can even be set to repeat automatically. A click on the '''Add planned capture''' button opens a dialog where the planned capture can be configured. This includes settings like the storage device to use, the start date and time of the capture, the duration of the capture, if a capture should repeat and the filter expression used during the capture. It is important to know that planned captures will not function if the chosen storage device is not active.

==== Capture profiles ====
[[File:Capture profiles config.png|thumb|600x600px|Capture profile configuration]]
[[File:Capture profiles edit profile.png|thumb|600x600px|Edit capture profile]]
Capture profiles can be used in the capture dialog for custom packet truncation rules. Such profiles defines custom rules for packet snapshot length similar to ring buffer filters. This allows to use a different snapshot length for specific layer 7 protocols, if for example traffic of one protocol shall be captured completely while for another protocol only the IP header shall be captured. Such a capture profile can be selected in the capture dialog in the "Truncate packet length" select box.

Up to 10 different profiles can be configured by clicking at the "Add profile" button. The add/edit dialog allows to enter a profile name and up to 10 rules for snapshot length. Similar to [[Packet ring buffer#Packet ring buffer snapshot length filter|ring buffer filters]], the first rule that matches for the selected type is used to decide for the snapshot length of the actual packet.

==== SFTP server ====
Credentials and upload directories for a SFTP server can be configured here. They can be selected in the capture dialog later when choosing "Capture to SFTP server" as capture type. It is possible to either configure a user and password or use authentication with a public key. In the latter case, the displayed SSH public key needs to be inserted in the authorized hosts list on the SFTP server.

=== Simple capture ===
The second section of the capture page allow to select some fields to filter network traffic for. By default, only the IP field is visible, the other fields can be enabled by clicking on the corresponding toggle switch. Each line allows to enter a filter criterion for the corresponding network traffic element. To start the capture with the entered filter criteria just click at the '''Start capture''' button. For reference, the expert filter expression is shown at the end of the section so it can be used to copy and paste
the string into the expert filter section.

=== Using expert filters to start captures ===
The third part of the page allows for starting a download for any criterion combination using complex filter expressions. A capture filter is defined in a C-style syntax and supports combination of AND/OR operators, precedence order with parentheses and equal/not equal comparisons. If the filter exp Session can be evaluated to true, the packet is
captured.
If a value contains a space, the whole value must be quoted with “”.
Following operators are supported:
* '''and''', '''&&''' : AND operator. The filter expression will match if all operands could be evaluated to true.
* '''or''', '''||''': OR operator. The filter expression will match if any operand can be evaluated to true.

Following comparison operators are supported:
* '''==''': Will evaluate expression to true if left and right operand are equal.
* '''!=''': Will evaluate expression to true if left and right operand are not equal.

Following operands are supported:
* '''ip''': An IP address. The packet is captured if either source or destination IP address of the packet match. A netmask and a port can also be specified. For IPv6 addresses with a specific port, the address must be written in brackets.
:Example:
:{| class="wikitable sortable"
|-
|
ip == 10.0.0.1

ip == ff02::1:3

ip == 10.0/16

ip == 10.0.0.1:1234

ip == [2a02:810a:1340:1292:1c6b:e58d:6ebc:6cd2]:123
|-
|}

*'''mac''': A MAC address. The packet is captured if either source or destination MAC address of the packet match.
:Example:
:{| class="wikitable sortable"
|-
| mac == 12:34: :56:78:90:ab
|-
|}

* '''port''': A TCP or UDP port. The packet is captured if either source or destination port match.
:Example:
:{| class="wikitable sortable"
|-
| port == 80
|-
|}

* '''portrange''': A TCP or UDP port range. The range can be a single number or a comma separated list of values or value ranges.
:Example:
:{| class="wikitable sortable"
|-
| portrange == 80,100-120,-10,65000-
|-
|}

* '''serverport''': A TCP or UDP port of a server. The packet is captured if the given port is a port of the server and not of a client.
:Example:
:{| class="wikitable sortable"
|-
| serverport == 80
|-
|}

* '''macProtocol''': A MAC protocol such as IPv4 or IPv6. For all seen MAC protocols, please consult the MAC Protocol Statistics module.
:Example:
:{| class="wikitable sortable"
|-
| macProtocol == IPv4
macProtocol == "Non IP"
|-
|}

* '''l4Protocol''': A layer 4 protocol such as TCP or UDP or any IP protocol number. Protocols can also be OR combined as a comma seperated list.
:Example:
:{| class="wikitable sortable"
|-
| l4Protocol == ICMP,ICMPv6
|-
|}

* '''l7Protocol''' or '''dpiProtocol''': A layer 7 protocol. Protocols can also be OR combined as a comma seperated list. For all seen protocols please consult the Layer 7 protocols module.
* '''countryCode''': A country code such as US. For all seen country codes please consult the Geolocation module.
* '''arpip''': An IP address within an ARP request or response.
* '''vlan''': A VLAN tag of an outer or inner VLAN. May be a number or none or any.
* '''outervlan''': A VLAN tag of an outer VLAN. May be a number or none or any.
* '''innervlan''': A VLAN tag of an inner VLAN. May be a number or none or any.
* '''multicastGroup''': A multicast IP address or any. The filter will match all IGMP or MLD negotiation packets related to that multicast IP address.
* '''rtpPayloadType''': The RTP payload type such as PCMU or MP2T. This filter will match all RTP packets with the given payload type.
* '''interface''': The physical interface. This can be a single number or a range. For interface ids please consult the Interface stats page.
:Example:
:{| class="wikitable sortable"
|-
| interface == 1,3-5
|-
|}

* '''link''': The link pair of two interfaces as stated in Interface stats. A single link number can be given.
* '''pppoeProtocol''': A specific PPPoE protocol (by name or by ID), or "none"/"any"
* '''pppoeAuthentication''': An authentication state of a PPPoE session
* '''pppoeLinkConfiguration''': A link configuration state of a PPPoE session
* '''ptpMsgType''': A specific PTP message type number or any for the whole PTP traffic.
* '''profinetFrameId''': A specific Profinet frame ID.
* '''profinetCmOpnum''': A specific operation number for Profinet CM (Context Manager) requests or responses. Can also be any for every operation number. Following values are used:
:#connect
:#release
:#read
:#write
:#control
:#read implicit

* '''mpls''': A label of an outer or inner MPLS. May be a number or none or any.
* '''outerMpls''': A label of an outer MPLS. May be a number or none or any.
* '''innerMpls''': A label of an inner MPLS. May be a number or none or any.
* '''qosIpDscp''': The DSCP value in the IP header. May be a number.
* '''qosMplsTc''': The traffic class value in the outermost MPLS label stack entry.
* '''qosVlanPcp''': The priority code point value in the outermost VLAN tag.
* '''group''': The name of a configured group or ‘default’. If the name contains whitespaces, the name must be enclosed in quotes.
* '''badCRC''': The value of this operand will be 1 for packets with a CRC error and will be 0 for good packets. Capturing packets with bad CRC is currently only supported on 1Gb interfaces.
* '''icmpType''': The value of a certain ICMP type (e.g. Echo request 8, Echo reply 0).
* '''tcpFlags''': A single TCP flag or a list of TCP flags joined by the ‘+’ sign. If a list of flags is given, all flags must be present in the packet. Supported TCP flags are syn, ack, fin, rst, psh and urg.
* '''callId''': The string value of a SIP call ID or similar identifier (e.g. P-Palladion-ID)
* '''ipFragment''': If set to 1 all IPv4 fragments will be captured (i.e. packets having the 'More fragments' flag and 'Fragment offset' set). If set to 0 all packets without IPv4 fragmentation will be captured.
* '''regexp''': The packet payload matches the quoted regular expression (RegEx) to the other side of the == operator or does not match the regular expression to the other side of the != operator. In case of IP packets the matching will be performed on the L7 payload of the packet. In case of non-IP packets the matching will be performed on the whole packet except the Ethernet header. Regular expressions largely support the pattern syntax used by the PCRE library with the exception of certain constructs. An invalid pattern will produce a descriptive error message and prevent the capture from being started.
* '''ipDoNotFragment''': The value of this operand will be 1 for IPv4 packets that are marked as to not be fragmented (packets which have the 'do not fragment' flag set).
* '''mactype''': The type of the packets destination MAC address. Allowed values are 'unicast, 'broadcast' and 'multicast'.
* '''slowSubtype''': The subtype of packets with the macProtocol == SLOW (e.g. 1 for LACP).

For a specific precedence you may use parentheses '''('''/''')'''.

Examples:
* The expression
:{| class="wikitable sortable"
|-
| ip == 10.0.0.1:1234 and ip == 10.1.0.1:9876
|-
|}
:will match a connection from 10.0.0.1 to 10.1.0.1 or vice versa with the ports 1234 and 9876 involved.

* The expression
:{| class="wikitable sortable"
|-
| ip == 10.0.0.1 and ip != 10.0.0.2
|-
|}
:will match packets having 10.0.0.1 either as source or destination. If a communication peer of 10.0.0.1 is 10.0.0.2 the packets will not be captured.

* The expression
:{| class="wikitable sortable"
|-
| l4Protocol == ICMP,ICMPv6
|-
|}
:will match packets with ICMP or ICMPv6 layer 4 protocols.

* The expression
:{| class="wikitable sortable"
|-
| portrange == 80,443
|-
|}
:will match packets to or from port 80 or 443.

* The expression
:{| class="wikitable sortable"
|-
| regexp == "allegr[o,a]'''<nowiki>|</nowiki>'''HTTP"
|-
|}
:will case sensitive match packets that contain the string(s) 'allegro' and/or 'allegra' and/or 'HTTP' anywhere in the payload.
:NOTE: The use of regexp is CASE sensitive. You must use the (?i) modifier to enable case insensitive filtering.

* The expression
:{| class="wikitable sortable"
|-
| regexp == "(?i)allegro'''<nowiki>|</nowiki>'''http"
|-
|}
:will case insensitive match packets that contain the string(s) 'allegro' and/or 'http' anywhere in the payload.
:NOTE: The use of regexp is CASE sensitive. You must use the (?i) modifier to enable case insensitive filtering.

Of course the Allegro Network Multimeter regular expression (RegEx) capture filter, can also be used in combination with our other capture expressions.

* The expression
:{| class="wikitable sortable"
|-
| regexp == “allegro'''<nowiki>|</nowiki>'''analyzer” and l7protocol == "dns"
|-
|}
:Will case sensitive match and capture only DNS packets containing the string(s) “allegro” and/or “analyzer.

* The expression
:{| class="wikitable sortable"
|-
| regexp == “allegro'''<nowiki>|</nowiki>'''analyzer” and l7protocol != "dns"
|-
|}
:Will case sensitive match and capture all (except DNS) packets containing the string(s) “allegro” and/or “analyzer.

Whenever you are unsure about the outcome of RegEx based packet capturing, you can pre-test the outcome of your expressions on https://pythex.org/.
While pre-testing on https://pythex.org/, avoid using the “IGNORECASE” button. Instead use the (?i) modifier for constructing case insensitive expressions, as mentioned above.
PCRE/Python based expression examples and explanations you'll find on https://www.programiz.com/python-programming/regex

All captures can be limited to any amount of time or bytes, for example to capture only one minute or one megabyte of traffic.

Below the list of filter criteria, you will find the button to actually start (or stop) the capture. In case the filter expression is invalid, the button is disabled.

====Layer 7 protocol capture====
Layer 7 protocol detection engine may need several packets to recognize the currently used protocol. For these captures all not yet recognized packets will be skipped. As soon as the protocol recognition is finished, all packets matching the protocol filter will be captured.

=== Configuration settings ===
By clicking on the gear button on the top right of the Capture web page, you can access the configuration section.

*The maximum number of concurrent capture sessions
:Per default out-of-box setting (factory default), all Allegro Network Multimeter models allow up to 4 concurrent captures. As of FW ≥ V3.4, the number of allowed concurrent captures, can be increased up to 64, depending on model and available RAM. Note, that Increasing the number of allowed parallel/concurrent captures will decrease memory capacity for the in-memory DB, therewith decreasing the maximum timeframe of statistics held and presented in the web-interface. If the memory usage is too high, the number of parallel captures might be lower/limited by the Allegro itself.

*Split PCAP file after this size
: This option can be used to limit the size of the PCAP file when storing to an attached device. Once the captured traffic would exceed this threshold, a new PCAP file with the current time stamp is created and the traffic is written to the new file. If the time stamp is still the same, an index is attached to the filename.
: When set to 0, no splitting will be done.

*Split PCAP file after this duration
:This option can be used to limit the duration of the PCAP file when storing to an attached device. The duration starts counting with the start of the capture. Once the captured traffic would exceed the duration, a new PCAP file with the current time stamp is created and the traffic is written to the new file.
:When set to 0, no splitting will be done.
:Both split parameters can be combined. The PCAP file will be split as soon as one threshold has been reached.

*The maximum number of concurrent packet ring buffers
:This option is used to specify how many cluster packet ring buffers can run in parallel.
:Be aware that each cluster will have it's own queue in memory and therefore the memory required is the number of cluster packet ring buffers multiplied by the setting of '''The size in MB for the queue of the packet ring buffer'''.
:A reboot of the device or a restart of the processing is needed for a change to this option to take effect.

*The size in MB for the queue of the packet ring buffer
: This option allows to configure the size of the queue that holds processed packets before they are written to the packet ring buffer. Increasing the size of this queue may help if the disk used for the packet ring buffer cannot keep up with bursts of traffic so that packet drops occur in the packet ring buffer.
:Be aware that memory allocated to this queue is not available for storing statistics and metadata so that choosing a large value for this queue reduces the overall data storage time.
:Most users will not need to change this value from the default value.
:A reboot of the device or a restart of the processing is needed for a change to this option to take effect.

*The maximum size in MB for the packet reorder buffer when capturing from the packet ring buffer
:This setting allows to choose the maximum size that the packet reorder buffer may grow to. For performance reasons the packet ring buffer does not ensure a total order of packets when storing them on disk. The packet reorder buffer is used to restore the correct order of packets in a capture when capturing from the packet ring buffer. A larger packet reorder buffer makes it more likely that the packet order can be restored for all packets. The actual amount of memory used for the packet reorder buffer depends on this setting but also on the amount of free memory in the system so that the effectively used amount of memory may be less than this setting indicates.

=== Capture settings dialog ===
[[File:Choose capture settings.png|none|thumb|600x600px]]
This dialog appears after a capture button has been clicked. Following settings are possible:
*Start time and end time
:By clicking on the input field or on the calendar icon you can choose the start and end time of the capture. The input field is also editable with keyboard and allows entering a time on a second basis.
: If the start time is in the past, the complete capture is performed on the stored data of the capture ring buffer. When the capture reaches the newest packets it still continues to read from the capture ring buffer. The dialog will limit the start time input to the earliest data of the capture ring buffer. Be aware, that a possible capture ring buffer filter was applied on the past data and is also applied on future data in this mode.
: The start time may also be in the future. The capture is scheduled and starts as soon as a packet is received with a time later than the start time.
:If the whole time input field is marked and deleted, the start or end time will reset back to the default value. The default value for start time is '''now''', the capture will start with pushing the '''Start capturing''' button. The default value of the end time is '''unlimited''', the capture will not stop unless stopped manually by clicking on the stop button.
:Eight buttons offer quick selection of often used time settings.

*Packet ring buffer
:If multiple packet ring buffer clusters are active this dropdown menu allows to choose from which cluster the packets should be captured.

*Capture type
: This drop down menu allows to choose the method how packets are captured. The last successful setting is persistently stored per user. Following methods are available:

:*HTTP download
::This is the default method. The capture will start a HTTP download of a PCAP file directly in the browser.
:: Available HTTP download options:
::*Set file name: allow to configure a custom file name for the capture file
::*Download as zip archive: Download the capture file as a compressed zip archive '''[New in version 3.0]'''
:*Disk
::This method is only visible if at least one storage device is active and has some amount of free storage space. The capture will create a PCAP file on the selected storage device.
::If PCAP export via SFTP is enabled, an additional checkbox is displayed to store the capture file in the export directory, slated for upload according the SFTP export settings.

:*Interface
::This mode will transmit the captured packets on a physical network interface. It is not available when the system is analyzing a PCAP file or is analyzing the packet ring buffer.

:* ERSPAN
::This mode will transmit the captured packets encapsulated in a GRE + ERSPAN header on the management interface to a given target IP address. On the target system the traffic can be selectively captured using the filter '''ip proto 0x2f''' when using an application like Wireshark or tcpdump.

:* Capture to SFTP server
::This mode will stream the PCAP to the selected SFTP server using the given credentials. SFTP servers can be configured on the Capture page

*Storage device
:If the 'disk' capture type is chosen, this drop-down menu allows to choose one of the active storage devices. The capture will be stored on the selected device.

*File name
:If browser download or disk storage has been chosen and the "Set file name" checkbox has been selected, the file name of the created capture file can be set in this field. The default value shows the filename with date wildcards and the capture filter. The date wildcards are then replaced by the start time of the capture.
:Date format specifier can be used as supported by strftime() function call. Some common specifier:
:*%Y for year
:*%m for month
:* %d for day
:*%H for hours
:*%M for minutes
:*%S for seconds
:Filenames are remembered when the dialog is closed and reopened. Clicking the circular arrow resets the filename to its default.

*Storage directory
:If disk storage has been chosen, the target directory on the storage device can be set in this field. Sub-directories on the storage device can be created and inspected on the [[Storage#Working with storage contents|Storage]] page.

* Zip options '''[New in version 3.0]'''
:If browser download has been chosen and the zip download option is selected, the file size can be configured after which the pcap files within the archive is spit into additional files
:The number is entered in megabytes. 0 means no splitting.

*Interface to transmit on
:This dropdown menu is only shown when Capture type is Interface. Here the physical interface on which to transmit captured packets can be selected.

* ERSPAN target address
:This section is only shown when Capture type is ERSPAN. Here the target IP address or hostname for the ERSPAN encapsulated packets must be specified.

*ERSPAN session ID
:This section is only shown when Capture type is ERSPAN. The ERSPAN session ID can be used to differentiate between multiple capture session on the ERSPAN target.

*Transmit speed
: This dropdown menu is only shown when the Capture type is either Interface or ERSPAN and the start time is in the past so that packets are captured from the packet ring buffer. Here the limiting mode can be chosen which controls how fast captured packets are transmitted. Following modes are available:

:*none
::No limit will be applied and the packets are transmitted as fast as the network interface and the packet ring buffer allow.

:*limit to bandwidth
::A bandwidth limit will be applied so that the given bandwidth in Mbps is not exceeded. The bandwidth can be given as a decimal so that e.g. 500kbps can be configured with a value of 0.5.

:*realtime factor
:: Packets will be transmitted based on their recorded timing information. This means that with a real time factor of 1.0 packets will be transmitted approximately with the same timing as they were originally received. Using for example a real time factor of 2.0 would transmit the packets with twice the speed than they were received.

* Transmit bandwidth in Mbps
:This is only shown when limit to bandwidth has been selected in the Transmit speed dropdown menu. The meaning of this value is explained in the Transmit speed section.

*Transmit realtime factor
:This is only shown when realtime factor has been selected in the Transmit speed dropdown menu. The meaning of this value is explained in the :Transmit speed section.

*Truncate packet length:
:This dropdown menu is only shown when the Capture type is either HTTP or disk. You can truncate captured Packets with this setting. All packets will be captured, but truncated to the given length if they are longer than this setting. The length setting is applied on layer 2 without frame check sequence.
:Possible values are:
:*Full length
:*64 Bytes
:*1500 Bytes
:*Custom length with an input field for inserting any length between 64 and 15378 Bytes
:*Capture profile: select a configured capture profile which defines rules about how many bytes are saved depending on the configured rules.

*PCAP compatibility:
:This section is only shown when the Capture type is either HTTP or disk.
:*Omit interface ID
::Enabling this option will generate a PCAP file that only contains a single interface and treats all packets as if they arrived on that interface. This may improve compatibility with third party software that cannot handle PCAPs with multiple interfaces IDs.

*PCAP comment:
:Allows to add a user defined comment to the generated PCAP file.
:*Add device information to comment
::Enabling this option will insert additional device information such as name, serial, memory size or capture filter into he PCAP comment.

After pushing the '''Start capture''' button, the capture starts.

=== Webshark ===
The Allegro Nework Multimeter has a preview mode to see the first Megabyte of captured packets directly in the browser. By clicking the Webshark preview button in the capture dialog, the first Megabyte of the requested packets will be extracted. If this is extraction is finished, a modal dialog will open showing the captured packets similar to Wireshark. The capture can be moved from the modal dialog to a separate window by pressing the button in the upper right corner next to the close button.

=== Capture URL ===
It is possible to use an external tool like '''curl''' for creating and storing a PCAP.
{| class="wikitable sortable"
|-
| curl -k -u USER:PASSWORD 'https://allegro-mm-XXXX/API/data/modules/capture?startTime=1517306266000000&endTime=1517309267000000&expression=l7Protocol==HTTP&snapPacketLength=65535&fromCaptureBuffer=true' > path_to/capture.pcap
|-
|}
The user name, password and hostname similar to the access of the web interface have to be used.
Following parameters are possible:

* startTime: The start time of the capture. The first packet with exactly this or a later time will start the capture. The time format must be microseconds after January, 1st 1970 UTC (Unix time, epoch). If the start time is in the past, make sure you set fromCaptureBuffer parameter accordingly.
*endTime: The end time of the capture. The first packet with exactly this or a later time will stop the capture. The time format must be microseconds after January, 1st 1970 UTC (Unix time, epoch).
*expression: The filter expression. There are no whitespaces allowed. You may use ‘%20’ instead.
*snapPacketLength: The max size of a packet applied on layer 2 without frame check sequence. If a packet is larger than this value, it is truncated. Use 65535 for unlimited size.
* fromCaptureBuffer: Whether to extract data from the packet ring buffer or just live traffic.
*captureToMedia: Whether to store PCAP on external storage device or download with your browser on your computer.
* useSingleInterface: Whether to store only a single interface in the PCAP and treat all packets as if they arrived on that interface. This may improve compatibility with third party software that cannot handle PCAPs with multiple interfaces IDs.

PPPoE module

2023-03-29T10:05:54Z

Robert: /* Web interface */

The PPPoE module shows all PPPoE sessions and traffic within a certain
session.

== Web interface ==

The PPPoE page shows on top a global graph for both PPPoE discovery
and PPPoE session traffic. PCAP buttons allows for capturing that particular
protocol. Discovery packets can also be extracted together with LCP packets.

A table shows all PPPoE sessions with its session ID, used authentication
protocol (PAP or CHAP), authentication state and link configuration state. The PACP button allows for
capturing that particular session.

=== Timing ===

For every PPPoE session the start and termination time is shown if corresponding PPPoE discovery PADS or PADT packets have been seen. The session duration is calculated based on those times. The first and last activity is updated according to session traffic. In case PADS or PADT have not yet been seen, the activity times will be taken into account for duration calculation.

PPPoE module

2023-03-29T10:04:55Z

Robert: /* Web interface */

The PPPoE module shows all PPPoE sessions and traffic within a certain
session.

== Web interface ==

The PPPoE page shows on top a global graph for both PPPoE discovery
and PPPoE session traffic. PCAP buttons allows for capturing that particular
protocol. Discovery packets can also be extracted together with LCP packets.

A table shows all PPPoE sessions with its session ID, used authentication
protocol (PAP or CHAP) and authentication state. The PACP button allows for
capturing that particular session.

=== Timing ===

For every PPPoE session the start and termination time is shown if corresponding PPPoE discovery PADS or PADT packets have been seen. The session duration is calculated based on those times. The first and last activity is updated according to session traffic. In case PADS or PADT have not yet been seen, the activity times will be taken into account for duration calculation.

Incidents

2023-03-29T09:57:04Z

Robert: /* Available triggers: add geolocation triggers */

[[File:Incidents_list.png|alt=|none|thumb|800x800px|Incident page]]
Incidents are used to alarm the user when configured network events occur, usually for traffic based rules, but also for system-specific events. These notifications can be viewed in the web GUI and may also be delivered on various notification channels. Repeating incidents are counted as such and the time of the first and last occurrence of an incident is remembered. This feature can be disabled for some incidents. What makes an incident unique depends on the type of incident.

The incident feature allows to define rules which are checked on the configured trigger point, like when a connection ends, a SIP call ends, or for checks on ongoing traffic. When such a trigger hits, configurable traffic attributes will be checked and if all attributes of a rule match, an incident is created.

Occurred incidents can be seen in the web interface, additionally reporting via the following notification channels is possible:
* email
* Apache Kafka
* SNMP trap
* syslog

The first occurrence of a medium or high severity incident will also trigger a status notification which is visible at the top right of the web GUI.

Up to 1000 incidents will be remembered by the system and if this limit is exceeded the oldest incidents will be discarded.

== Configuration of incident rules ==
[[File:Incidents rules.png|thumb|600x600px|Rule configuration]]
Incident rules can be defined in the "Configuration of incident rules" tab in the menu "Generic -> Incidents". All changes to the rule configuration will only take effect after saving the current configuration by clicking on the save button at the bottom of the page.

The page shows a table containing the existing rules and their configuration.

Each existing rule can be modified by clicking on the pencil symbol, or deleted by clicking on the "minus" symbol.

New rules can be added by clicking on the "Add rule" button. A dialog appears allowing for configuration of the rule. The same dialog is used when modifying an existing rule.

=== Add/modify a rule ===
[[File:Incidents add rule.png|thumb|600x600px|Add rule dialog]]
A rule is defined by the following settings:

* Rule name: This is an arbitrary text describing the purpose of the rule. This text is shown in the incident list and email/Kafka/SNMP trap/syslog ouptut.
* Severity: three different severity values "low", "medium", and "high" can be used to group more important and less important incidents. Reporting channels can be configured to only report incidents of a minimum severity level. A rule can also be disabled by choosing the severity level "disabled". It will not be evaluated and can be enabled later at will.
* Trigger: The trigger defines when a rule is evaluated. For each available trigger, a description is shown next to it giving more details about the trigger. Some triggers are evaluated at a very specific time, like when a VoIP call ends, or are evaluated regularly like for throughput triggers of IP traffic which can be configured to be checked periodically. See list below for a detailed description of the available triggers.
* Attributes: Attributes are used to make actual comparison of expected values vs. actual values.
** Each trigger has a different set of attributes which can be checked for, and some triggers don't need to have an attribute at all. See list below for a detailed description of the available attributes
** Up to four attributes can be added by clicking on the "Add attribute" button.
** Multiple attributes must all match at the same time to let the rule create an incident.
** Each attribute can be compared to a specific value, so that the actual value is lower, equal, or greater than a defined value.
** Some attributes have an additional parameter, like a time span which defines how the attribute value is calculated.
* Virtual link group: The rule can be limited to a selected [[Virtual Link Group functionality|virtual link group]] or to be applied for any group. Some triggers cannot be limited to a virtual link group so the configuration will be hidden.
* IP filter: Depending on the selected trigger, the rule can be limited to a specific IP address. In firmware version >= 4.0, the IP filter can also be an IP subnet in the format IP/mask-length (Example: 10.0.0.0/8)
* IP group: Depending on the selected trigger, the rule can be applied to an IP group instead of an individual IP address.
* Virtual link group, IP and IP filter can also be used inversely by using the != comparator
* Report channel: Incidents are always visible in the web interface, but can also be reported via multiple channels which can be configured separately in the tab "Configuration of notification channels". Up to ten channels can be selected so that the incident for this rule is reported on each channel. Also, no channel can be configured so the incident is only accessible on the web interface.
* Aggregation of recurring Incidents: Incidents are aggregated by default. This means the table only shows the number of incidents of the type and the timestamps of the first and the last incident. This can be disabled for most of the incidents, so that you are able to see every indent of the incident-type.
* Time Profiles: With version 4.0 the new setting time profiles was introduced. You are able to set a profile which defines the active time of an incident rule.
* Traffic capturing [since version >= 4.0]: If supported by the trigger, the rule can be configured to capture the network traffic triggering the rule, including some extra time before and after the incident.
** Possible options:
*** Disabled: capturing is disabled for this rule
*** Live traffic: capturing happens only for live network traffic
*** Replay traffic: capturing happens only for replayed network traffic (from PCAP files)
*** Always: capturing happens in all traffic processing types.
** Extra capture time: configure the number of seconds before the start of the incident and after the end of the incident.
*** If a time span parameter is used for attributes, the capture time includes this time duration as well.
** The traffic is automatically filtered to only contain the traffic that actually triggered the rule, i.e., an IP address or an IP group for IP rules.

=== Available triggers ===
{| class="wikitable"
|+
!Trigger name
!Description
!Attributes
!Attribute usage
|-
|ARP: MAC change for an IP 
(arp_ip_mac_changed)
|This trigger is checked on an ARP response and MAC address changed for a requested IP.
|time_since_last_mac
|optional
|-
|DNS: Server is not responding 
(dns_server_not_responding)
|This trigger is checked when a DNS server is not responding for some time. A server is considered unresponsive when more than 3 requests to the DNS server went unanswered for a period of more than 5 seconds. Such a server must have answered at least two requests previously.
|time_since_first_unanswered_request
|optional
|-
|DNS: Server response error 
(dns_server_response_error)
|This trigger is checked when a DNS server responds a configured error of type format error, server failure or non-existing domain
|error_type
|mandatory
|-
|Global: Connection start 
(global_new_connection)
|This trigger is checked continuously at connection start. It can be used to report new connections with a certain layer 4 protocol and a given port range.
|l4_protocol, port_range, since_start_time
|mandatory
|-
|Global: GPS synchronization status change 
(global_gps_sync_status_change)
|This trigger is checked when the GPS clock synchronization status changes.
|gps_sync_status
|optional
|-
|Global: Number of connections 
(global_connections)
|This trigger is checked continuously whether the amount of newly created connections exceeds a threshold. The update interval is defined by the timespan parameter of the attributes.
|new_connections
|mandatory
|-
|Global: Regular expressions 
(global_regex_match)
|This trigger allows to configure a list of regular expressions and is checked for each packet whose L7 data matches one of the regular expressions in the list. Since there are no attributes associated with this trigger, this effectively means that any packet which matches one of the regular expressions will result in an incident. The incident also contains information about which connection this packet belongs to as well as which of the regular expressions matches the packet.
|
|no attributes are available for this trigger
|-
|Global: Ring buffer 
(global_ring_buffer)
|This trigger is checked continuously to report changes in the ring buffer.
|used_size, bytes_captured, bytes_dropped
|mandatory
|-
|Global: Speed change of an interface 
(global_interface_speed_change)
|This trigger is checked when the speed of an interfaces changes.
|interface_speed
|optional
|-
|Global: Speed mismatch for an interface pair 
(global_interface_speed_mismatch)
|This trigger is checked when the status or speed of an interfaces changes and mismatches the speed of corresponding interface of a link.
|link_speed_difference
|optional
|-
|Global: Status change of an interface 
(global_interface_status_change)
|This trigger is checked when the status of an interfaces changes.
|interface_status
|optional
|-
|Global: Traffic 
(global_traffic)
|This trigger is checked continuously for the total traffic of the device. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase
|mandatory
|-
|IP: Connection end 
(ip_flow_end)
|This trigger checks the attributes whenever an IP flow ended.
|total_packets, total_bytes, tcp_handshake_time, percent_retransmissions, zero_window_packets, duration
|mandatory
|-
|IP: Connection start 
(ip_flow_start)
|This trigger checks the attributes whenever an IP flow starts.
|new_connections, geolocation
|mandatory
|-
|IP: Local IP with multiple MAC addresses 
(ip_local_ip_multiple_macs)
|This trigger is checked on each new flow of a local IP address and more than one MAC address uses this IP.
|mac_count
|optional
|-
|IP: New local IP address 
(ip_new_local_ip)
|This trigger is checked once for each new IP belonging to a private network address range.
|since_start_time
|optional
|-
|IP: New local L7 protocol 
(ip_new_local_l7_protocol)
|This trigger is checked once for each new l7 protocol used by a local IP.
|since_start_time
|optional
|-
|IP: TCP handshake 
(ip_tcp_handshake)
|This trigger is checked after successful TCP handshake.
|handshake_time, server_handshake_time, client_handshake_time
|mandatory
|-
|IP: Traffic on IP addresses 
(ip_traffic)
|This trigger is checked continuously for each active IP or IP group. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase, total_packets, total_bytes, retransmission_ratio, zero_window_packets, tcp_syn_packets, tcp_fin_packets, tcp_rst_packets
|mandatory
|-
|LACP: Status change of a channel 
(lacp_channel_status_change)
|This trigger is checked when the status of a LACP port channel changes.
|channel_status
|optional
|-
|MAC: New L7 protocol 
(mac_new_l7_protocol)
|This trigger is checked when a unicast MAC address uses a l7 protocol for the first time.
|since_start_time
|optional
|-
|MAC: New MAC address 
(mac_new_address)
|This trigger is checked once when a new unicast MAC address appears for the first time.
|since_start_time
|optional
|-
|MAC: Traffic on MAC addresses 
(mac_traffic)
|This trigger is checked continuously for each active MAC address. The update interval is defined by the timespan parameter of the attributes.
|broadcast_packet_rate
|mandatory
|-
|PPPoE: PPPoE Discovery traffic 
(pppoe_discovery_traffic)
|This trigger is checked continuously for PPPoE discovery traffic. The update interval is defined by the timespan parameter of the attributes.
|pppoe_discovery_packets
|mandatory
|-
|Profinet: Traffic of Profinet devices 
(profinet_traffic)
|This trigger is checked continuously for Profinet traffic. For max jitter, the update interval is defined by the timespan parameter of the attributes. All other attributes will be checked upon event.
|alarms_low, alarms_high, errors, frames_lost, frames_repeated, frames_wrong_sequence, max_jitter
|mandatory
|-
|PTP: Timestamp packet 
(ptp_timestamp_packet)
|This trigger is checked when a PTP packet containing a valid timestamp is seen.
|time_offset
|mandatory
|-
|QOS: Traffic on QoS classes 
(qos_traffic)
|This trigger is checked continuously for each active QoS class. The update interval is defined by the timespan parameter of the attributes.
|throughput
|mandatory
|-
|RTP: Traffic for RTP connections 
(rtp_traffic)
|This trigger is checked continuously for traffic of each RTP connection. The update interval is defined by the timespan parameter of the attributes.
|jitter, percent_loss
|mandatory
|-
|SIP: Call end 
(sip_call_end)
|This trigger is checked when a SIP call ended.
|duration, status, mos, percent_loss, jitter, total_packets, total_bytes, total_caller_packets, total_callee_packets, total_caller_bytes, total_callee_bytes
|mandatory
|-
|SMB: SMB1 negotiation 
(smb_v1_negotiation)
|This trigger is executed at the beginning of each SMB connection and checks whether insecure SMB1 has been negotiated.
|
|none
|-
|SSL: Handshake 
(ssl_handshake)
|This trigger is checked during handshake of each SSL connection.
|certificate_expires
|mandatory
|-
|SSL: SSL/TLS version negotiation 
(tls_version)
|This trigger is checked during version negotiation at handshake of each SSL connection.
|used_tls_version
|mandatory
|}

==== Special trigger properties ====
Some triggers are checked continuously every configured time span period, so the incidents are generated differently than for fixed event specific triggers like a call end.

# Repeating incidents: The following triggers will be evaluated every configured time span and will be re-issued whenever the configured attributes match.
## ip_traffic
## mac_traffic
## qos_traffic
## rtp_traffic
# Start/stop incidents: The following triggers are reported once the configured attributes match and for a second time when the attributes no longer match.
## global_traffic

So for repeating incidents you will get repeated incidents for the same attribute every time span. For example, if an IP address has traffic of 100 Mbit/s for 2 minutes and a rule checks for more than 50 Mbit/s over 30 seconds, the rule will hit 4 times. There will be one incident which will contain the exact number of repetitions for reference.

For start/stop incidents, you will only see two rule hits and the incident description will state the start and stop time.

=== Available attributes ===

* '''alarms_low''', '''alarms_high''': Whether an low/high alarm occurred for a Profinet device.
* '''broadcast_packet_rate''': The attribute is the number of packets per second on average over the configured timespan for MAC broadcast packets.
* '''bytes_captured''': The amount of bytes captured by a ring buffer in the given timespan.
* '''bytes_dropped''': The amount of bytes dropped by a ring buffer in the given timespan.
* '''certificate_expires''': This is the number of days until the certificate expires. If the certificate is already expired, the value is <= 0.
* '''channel_status''': 0 means that the LACP port channel is not synchronized, 1 means that the LACP port channel is synchronized.
* '''duration''':
** ''IP: Connection end'': The time between first and last packet of the flow.
** ''SIP: Call end'': The call duration.
* '''errors''':
** ''Profinet: Traffic of Profinet devices: Whether errors occured.
* '''error_type''': equal or not equal to:
** Format Error: DNS responds a format error.
** Non-existent Domain: DNS could not find queried domain name.
** Server Failure: DNS responds server failure.
* '''frames_lost''', '''frames_repeated''', '''frames_wrong_sequence''': Whether Profinet frames have been seen with problems in sequence. For loss the count of lost frames is calculated.
* '''geolocation''': checks if a country is part of the connection
** '''Direction''': The direction of traffic
*** ''from'': Traffic is coming ''from the'' specified country
*** ''to'': Traffic is going ''to'' the specified country
*** ''any:'' The specified country is on either side of the connection, or on neither side if the inequality is selected.
* '''gps_sync_status''': 0 means that the GPS clock in not synchronized, 1 means that the GPS clock is synchronized.
* '''handshake_time''': The TCP handshake time between the first SYN packet and the ACK packet for the SYN/ACK packet of the server.
** '''client_handshake_time''': The TCP handshake time between the SYN/ACK packet of the server and the ACK packet of the client.
** '''server_handshake_time''': The TCP handshake time between the first SYN packet of the client and the SYN/ACK packet of the server.
* '''interface_speed''': The current speed of the interface in Mbit/s.
* '''interface_status''': 0 means interface is down, 1 means interface is up.
* '''jitter''':
** ''SIP: Call end'': The average jitter of the call, using the maximum value of both call sides.
** ''RTP: Traffic for RTP connections'': The average jitter of the RTP connection for the given timespan, using the maximum value of both directions.
* '''l4_protocol''': The layer 4 protocol. Can be TCP, UDP or other.
* '''link_speed_difference''': This is the absolute difference between the speeds of both interface of a link in Mbit/s.
* '''mac_count''': The number of different MAC addresses for the corresponding IP address.
* '''max_jitter''': The max jitter value for a Profinet device in % in a given timespan.
* '''mos''': The average MOS quality value of the call, using the minimum of both call sides.
* '''new_connections''': The amount of newly created connections (TCP and UDP) for the given timespan.
* '''packet_rate''': The packet rate in packets per second on average during the configured timespan.
* '''packet_rate_increase''': The packet rate increase in % during the configured timespan compared to the average packet rate of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''percent_loss''':
** ''SIP: Call end'': The percentage of RTP packet loss for the call, accounting packets from both directions.
** ''RTP: Traffic for RTP connections'': The percentage of RTP packet loss for the given timespan, accounting packets from both directions of the RTP connection.
* '''percent_transmissions''': The amount of TCP retransmission as a percentage of the total bytes.
* '''port_range''': The TCP or UDP port. Can be also a range, e.g. 80,443,8443-8445
* '''pppoe_discovery_packets''': The number of PPPoE discovery packets seen during the configured timespan.
* '''retransmission_ratio''': The TCP retransmission ratio seen in the configured timespan.
* '''since_start_time''':
** ''MAC: New L7 protocol'': This is the number of seconds after packet processing start when a new Layer-7 protocol for the MAC address appeared.
** ''MAC: New MAC address'': This is the number of seconds after packet processing start when the MAC address appeared. This is useful to only report new MAC address after some learning time.
** ''IP: New local IP address'': This is the number of seconds after packet processing start when the IP address appeared. This is useful to only report new IP address after some learning time.
** ''IP: New local L7 protocol'': This is the number of seconds after packet processing start when the Layer-7 protocol for the IP address appeared.
** ''Global: Connection start'': This is the number of seconds after packet processing start when the connection hast been started. This is useful to only report new connections after some learning time.
* '''status''': The call status code (a three digit number, like 200 for Success)
* '''tcp_handshake_time''': The TCP handshake time.
* '''tcp_fin_packets''': The number of TCP FIN packets (RX + TX) seen in the configured timespan.
* '''tcp_rst_packets''': The number of TCP RST packets (RX + TX) seen in the configured timespan.
* '''tcp_syn_packets''': The number of TCP SYN packets (RX + TX) seen in the configured timespan.
* '''throughput''': The throughput bandwidth in bit/s on average during the configured timespan.
* '''throughput_increase''': The throughput bandwidth increase in % during the configured timespan compared to the average throughput of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''time_offset''': The time offset between the local time and the timestamp seen in the PTP packet.
* '''time_since_first_unanswered_request''': This is the time span between when the trigger is checked and the first DNS request that has not been answered by the DNS server.
* '''time_since_last_mac''': This is the number of seconds between changed MAC addresses. If, for examples, dynamic IP assignment is used, changing MAC addresses is normal so the test can be limited to only a certain amount of time.
* '''total_bytes''':
** ''IP: Connection end'': The total number of bytes seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of bytes seen in the configured timespan.
** '''total_callee_bytes''': The number of bytes seen for the callee of the call.
** '''total_caller_bytes''': The number of bytes seen for the caller of the call.
* '''total_packets''':
** ''IP: Connection end'': The total number of packets seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of packets seen in the configured timespan.
** '''total_callee_packets''': The number of packets seen for the callee of the call.
** '''total_caller_packets''': The number of packets seen for the caller of the call.
* '''type''': The type of PPPoE discovery packet (PADI, PADO, PADR, PADS, PADT or any).
* '''used_size''': The percentage of the ring buffer that needs to be filled.
* '''used_tls_version''': The TLS version (SSl 3.0, TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3)
* '''zero_window_packets''': The number of packets with a TCP window of 0 for both directions of the flow.
* '''zero_window_packets''': The number of zero window packets seen in the configured timespan.

=== Capture settings ===
Since firmware version 4.0, it is possible to automatically capture traffic for occurred incidents. These global settings control where capture files are stored and the capturing itself can be enabled for each rule separately.

The incident capture feature requires an active packet ring buffer since the packets are extracted from the buffer at the end of the incident period.

Available settings:

* Capture cooldown period: For each rule a cooldown period prevents multiple captures from happening in fast succession. By default, new captures happen firstly after 5 seconds, but any other value of at least 1 second can be configured. The cooldown is applied to each rule separately, but for each individual rule it does not matter if the same or a different entity triggers an incident. The incident is still reported within the cooldown period, but no additional capture is started.
* Storage device: Select the storage device where the captures should be stored on.
* Storage directory: Enter the directory where capture files should be stored or leave empty to use the top level directory.
* Select packet ring buffer to capture from: if multiple ring buffer cluster are in use, you can select which ring buffer to use for extraction.
* Capture profile: A capture profile can be configured to apply packet truncation rules to the capture file. If unset, the complete packets are captured (if the ring buffer uses separate truncation rules, truncated packets might still be within the capture file).

== Time Profiles ==
Incident rules can be active configured to be active in configured time spans (time profiles).

Every time profile allows the user to define one or more time spans per day of the week in which a rule should be active. After saving the user is able select the time profile when editing the rule.

Notes: Overlapping time spans will be merged. The earliest a time span is allowed to start is 0 and the latest end is 24, minutes are not allowed. The rule is not active for a day if there is no time span defined for the day.

== Channel configuration ==
[[File:Incidents channels.png|thumb|600x600px|Channel configuration]]
Incidents can be reported on different channels. The configuration allows to add new channels so they can be selected in the rule configuration described above.

Each channel can be of type:

'''email''' Incidents will be sent to the email address configured in the [[Global settings]].

'''kafka''' The incidents are sent to a topic on the configured Apache Kafka server. Firmware >= 4.0. The message is the same as for syslog.
* Bootstrap Server: hostname/ip:port of a Kafka Broker or multiple Brokers separated by comma
* Protocol: Plaintext (no authentication, no encryption), SASL Paintext (Plain authentication, no encryption), SASL SSL (Plain authentication, TLS/SSL encryption)
* Ignore TLS Certificate: Ignore the TLS Certificate of the Brokers (only SASL SSL)
* Username: Broker Login (only SASL)
* Password: Broker Login (only SASL)
* Topic: The name of the topic into which the Incidents are sent.

'''snmp_trap''' Incidents will be sent to the configured SNMP trap receiver (firmware >= 4.0). A MIB file with the Allegro Network Multimeter SNMP trap definitions is available for download in the channel configuration dialog.
* Version: Supported SNMP version of the trap receiver (SNMP v2c or SNMP v3)
* Trap receiver (manager) hostname/IP: The trap receiver hostname or IP address

''SNMP v2c'':
* Community name: SNMP community name expected by the trap receiver

''SNMP v3'':
* Authentication protocol: Protocol for authenticated messages (MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512)
* Authentication password: Pass phrase for authenticated messages
* Privacy protocol: Protocol for message encryption (AES, DES)
* Privacy password: Pass phrase for message encryption
* Security name: Security name for authenticated SNMP messages
* Security level: Security level for SNMP messages (noAuthNoPriv, authNoPriv, authPriv)
* Engine ID: Authoritative (security) engineID (hexadecimal number)

'''syslog''' Incidents will be sent to the configured syslog server via TCP on any TCP or UDP port.

[[File:Incidents add channel.png|thumb|alt=|none|Adding a new channel]]
Each channel also uses a minimum severity setting, so only incidents are reported which are of at least that severity.

Each channel can be configured to only handle incidents from live traffic or from replayed traffic.

Some incidents cannot be configured via rules and you can choose to get those incidents also via email by enabling the settings at the lower part of the settings page.

== Interface burst incident ==
[[File:Incidents others.png|thumb|600x600px|Other incidents]]
Burst incidents with milli-second resolution can be generated when the interface throughput exceeds a configurable threshold. The incident contains a graph of traffic for that interface with some data points before and after the threshold has been exceeded depending on the measurement interval. A PCAP link for capturing from the packet ring buffer is shown. For further investigation of that incident, the button "Use as global time range" can be used to set the global range to the start and end of the incident graph (at least 5 seconds) so that all modules of the Allegro Network Multimeter show that time span. The incident generation can be configured as follows:
* '''Report "throughput threshold exceeded" with severity''': report an incident with the selected severity level if the throughput of any network interface exceeded.
* '''Throughput threshold (Mbit/s)''': The threshold is configured in Mbit/s.
* '''How long throughput must be above threshold to generate incident (in milliseconds)''': The throughput must exceed the threshold for this duration in order to generate the incident. If set to zero (default) the incident is generated immediately after the threshold has been exceeded.
* '''Throughput cool-down period between two incidents in milliseconds''': Defines the time after an incident where no new incident is generated even if the threshold is exceeded. If this period is passed, throughput incidents could be generated again.

== Occured incidents ==
This page shows up to the last 1000 incidents occurred on the system. The table can be filtered for specific severity levels, as well as for specific trigger sources by selecting the trigger from the drop down menu.
[[File:Incidents list filter.png|thumb|600x600px|Filter incidents by severity or trigger]]
The list can also be filtered for the subject of the incident.

Individual incidents can be viewed in detail by clicking on the subject. The details page shows detailed information including links to the relevant measurement page.

Incidents can be deleted individually by clicking on the delete button next to the incident, or all incidents can be deleted by clicking on the button on the top right of the page.

== Statistics about incident rules ==
[[File:Incidents stats.png|thumb|600x600px|Statistics about rules]]
This page shows graphs about how often each rule has been hit both in absolute numbers as well as relatively to how often the rule has been checked.

== Incident list per measurement modules ==
Since incidents are triggered by different measurement modules (as indicate by the prefix of the trigger name, like the mac or ip module), the list of incidents from that specific module can also be seen in the corresponding tab of the measurement module for quicker access. This per-module view only lists those incidents coming from that module, all other potential incidents are hidden and must be accessed in their corresponding module page, or in the global view in the "Generic -> Incident" menu.

== Limitations ==
Some technical limitations apply:

* continuously checked triggers like "IP traffic" are only evaluated if there was at least one packet in the corresponding time interval. Therefore, rules check for zero packet count or throughput will never match.