Allegro Network Multimeter Manual - User contributions [en]

Path measurement

2025-08-27T09:56:25Z

Ralf:

== Path measurement ==

The path measurement module allows to passively measure the packet loss and latency at two measurement points. These can be between two Allegro Network Multimeter installations, or on a single device with traffic from two different locations.

For example, a network connection (line/link) between the main office and a remote office can be analyzed by installing one Allegro Network Multimeter at the main office and another Allegro Network Multimeter at the remote office.

Only network traffic (packets) passing through both Allegro Network Multimeters can be analyzed. The packet loss and two-way-latency thereof is measured and shown in graphs.

The time synchronization setting (e.g. NTP/PTP or OFF) should be the same on both devices for the best results.

It is also possible to use a single device to measure the traffic delay/losses between two different [[Virtual Link Group functionality|virtual link groups]]. In this mode, the primary device is used as a client too.

Two pcap capture files can be compared to do an offline path measurement with previously captured files in two different locations.

=== Live analysis ===
In live analysis mode, the packets are either gathered from the local device and a configured remote Allegro Network Multimeter, or from two different sources on the same local devices (different interfaces, different VLAN tags, or similar parameters available through virtual link group configuration).

=== PCAP analysis ===
In PCAP mode, two PCAP files are processed the matching packets are used to determine the delay and possible loss between both files. For best results, the file should be recorded on the same device (by running two captures simultaneously from different sources), or from two devices with good time synchronization.

== Overview ==
The main device captures packet meta data from the remote (or client) device which takes only a fraction of the total traffic. Approximately 5% additional bandwidth is required for this capture connection. So for fully loaded 100 Mbit/s connection to the remote location an additional load of ~5 Mbit/s is required to get packet information to the main device.

The measurement connection can be a separate line or can be run over the line that is measured, the capture connection will be automatically ignored for the measurement.

The measurement module must be configured with a maximum packet delay. This delay describes the amount of time the main device waits for packet information to arrive from the remote device. The delay must be large enough to cover the actual latency of the connection and delay of the capture connection. Typical values are between 2 and 5 seconds. Larger values requires more memory to buffer packet meta data so very large values might only be selectable on larger Multimeter devices (Allegro 1000 or greater).
== Configuration live measurement ==

{|class="wikitable sortable"
|-
|[[File:Ap-mm-path-measurement-1.png|600px|none|right]]
|}

=== Settings ===

* Enable analysis: This will disable or enable the path measurement feature. When disabled, no additional memory is used. When enabled, memory for the packet buffer is used which cannot be used for other analyzing modules thus reducing the maximum time the device can go back in time.
Primary device settings:
* Description of this main device: This field is only used for informational purposes to identify the main device. It can be freely chosen, for example to the location the device is installed. This field can also be left empty to use the default name '''main'''.
* '''Primary device VLG filter:''' It is possible to limit the amount of data analyzed by any configured virtual link group. Often, the primary device is located at a central network point and thus sees a lot of traffic that is not actually going to the remote device. The algorithm will automatically take this into account, but using a filter will reduce the processing overhead as well as the amount of data that needs to be buffered.

The following '''Client device''' configuration section configures the access to the remote device:

* '''Device to use''': To use a remote device for path measurement, you first need to add that device as a remote device to the list of [[Multi-device settings]]. It does not matter if the device is active or not. You can select the device from the list of known multi-devices. You can also select the primary device as a client to analyze the traffic between two different virtual link groups.
* '''Device description''': Similar to the description of the main device, this field is for informational purpose only and has no other effect than helping identifying the remote device in the statistics. Usually the location of the remote device is entered.
* '''Client device VLG filter''': The traffic used for comparison at the main device can be filtered to any virtual link group defined at the client device. There are two main purposes for this setting:
*# reduce the amount of data required to be transferred to the main device. The path measurement only considers connections seen on both devices, but the client device of course cannot know if any connection it sees also is visible on the main device. If only traffic of a specific virtual link group (VLG) actually reaches the main device, using this filter can reduce the amount of data transferred and later dismissed.
*# filter duplicate traffic: If, for some reason, traffic is seen multiple times, it can create wrong results as the number of occurrences differs from main to client devices. A VLG filter can fix this problem by only considering one part of the total traffic.
* '''GNSS-synchronized clocks''' (Firmware >= 4.5): If the selected device is a remote device and both primary and client device have GNSS time synchronization enabled, this option can be enabled to generate one-way latency instead of regular two-way latency.

Measurement settings:

* '''Maximum packet delay''': This field describes the maximum amount of seconds to wait for packet information from the remote device.
: It basically means that the main devices waits for this number of seconds before deciding if a packet has been lost or not. If the data from the remote device arrives before those number of seconds, the path measurement can account the packet loss, if any and the two-way latency. This value must be at least as large as the worst-case latency between both measurement sites.
: Usually 3 seconds are more than enough but when the network in between can have a very long delay, you can increase the value. This will, however, use more main memory for the packet buffer.

* '''Maximum original packet rate:''' This field defines the maximum packet rate that is to be expected. It directly defines the necessary amount of memory for storing packet information for the defined packet delay. The field can be left empty (or zero) to use the maximum supported packet rate of the device. This value usually only has to be adjusted if the debug information about "Packets processed too early" is non-zero which indicates that the packet rate exceeded the assumed packet rate limit.

* '''Ignore IP identification field''': This option can be enabled if the IP identification field in the IPv4 header is modified by some component in the network. Often it remains constant for a single packet so this option should be left disabled as it will also increase the chance of reporting duplicate packets. But if you notice symmetrical packet loss you can enable this option to see if this helps.

*'''Ignore VLAN tags for connection matching''': The path measurement only calculate loss and latency for connections seen on both devices. Usually the connection ID takes the IP pairs, port ports and possible VLAN tags into account. If a VLAN is different on both machines for the some connection, then this option must be enabled to be able to correlate the connection and calculate correct statistics.
* '''Account latency also per IP connection''': Enabling this option will let the path measurement also store the latency for each individual IP connection, which of course increases the memory usage.
* '''Enable NAT mode''' (Firmware >= 4.3): This feature will enable support for Network-Address-Translation setup (typical for firewalls or internet uplink routers).
** '''NAT Private subnet/mask:''' This value describes the internal IP addresses that gets translated into an external IP address. An example value is "192.168.1.0/24" if all internal devices uses IP addresses in the range 192.168.1.0-192.168.1.255.
** '''NAT Public subnet/mask:''' This value defines the external IP address that internal IPs of the private subnet are translated to. It can also be an IP subnet (for example, if multiple external IP addresses are used). An example value is "10.1.2.3" if the NAT router is using the external IP 10.1.2.3 and all its internal clients are visible under this IP.
** '''Account unmatched flows:''' This option allows to monitor also connections there are not seen on the other measurement side. This is useful to see blocked connections in firewall setups.

* '''Maximum packet length for lost packets PCAP''': If a lost packet capture is running this setting configures the packet length for these packets. Keep this number as low as possible for optimal memory consumption. Each packet will be stored in memory until it is either confirmed by the client device (considered as not lost) or the maximum packet delay is over and the packet is considered lost and written to the PCAP.

* '''Threshold for high latency packets PCAP''': This is the threshold for a high latency PCAP. This is applied for single device measurement only. Packets with a larger time difference in their configured VLGs as this threshold can be captured. The latency value must not be larger than the maximum packet delay.

The settings must be saved but to actually take effect, a restart of the packet processing is necessary. If this step is required, a notification will tell so at the bottom of the page under '''Required actions'''.

=== Parameters currently in use ===

This section shows the current state of the measurement engine. The engine might be inactive even if the feature is enabled. Usually a restart is required to actually make it active. If active, the current packet delay is shown. It might be different from the selected value in the configuration above, but if so a note appears that a restart is required.

=== Required actions ===

An info box appears if the a restart of the packet processing is required. The shown link leads to the page '''Settings → Administration''' where the restart can be triggered. The device itself does not need to be rebooted, only the packet processing must be restarted which usually takes only a few seconds.

== Configuration PCAP measurement ==
[[File:Path-measurement-pcap-settings.png|border|660x660px]]

The path measurement can also be done based on two capture files created from two different network locations. The separate configuration tab "Configuration PCAP Analysis" allows to select two files from attached storage devices.

The files are replayed based on the packet time stamps within each file, in chronological order. Matching packets are only recognized if they are within the maximum packet delay. If the difference of the timestamps is larger, a time-delta adjustment value can be entered which will be added to the timestamp of the client packets. Negative values are possible as well to be able to adjust the time in both directions. If the time difference is too large, a lot of packet loss are reported, or even a "network setup problem" note is shown in the overview tab. If the time delta between both files is not known, a test run can be enabled to calculate the approximate difference. When both files are fully processed in this test run, the result is shown in the overview tab and this value can be used for the actual analysis.

The settings are similar to the live measurement. VLG filter can be applied to both files, but an option also allows to disable the use of the configured virtual link groups, or use separate groups for each file. In contrast to live mode, a VLG does not need to be used to differentiate traffic since it is clear from the selected file which one is the primary traffic and which one is the client traffic. But of course VLG can be used to filter out traffic that should not be part of the analysis.

The "Measurement settings" contains all settings from the live measurement plus three options only applicable in PCAP mode.

* Virtual link group mode: Select to either use:
** Use global VLG settings: Use the VLG configuration configured globally on this device.
** Use separate VLG per file: Create a temporary VLG for each file so all statistics can be accessed for each individual file regardless of the configuration of the regular virtual link groups.
** Disable use of VLGs: Disable all VLG configurations and use one common view of all data.
* Run analysis in main memory: The analysis requires a relatively large amount of memory depending on the setting values for packet delay and packet rate. In live mode, this data is always kept in main memory for performance reasons, but in PCAP mode the data is stored on a local storage device by default. This is slower but does not require a lot of additional memory reserved, especially when parallel pcap analysis is enabled.
* Storage device to use: If a storage device is available, the first one is selected by default. Otherwise the system disc is used to store the packet comparison information. The approximate amount of storage space required is shown below the selection box.

<u>IMPORTANT NOTE 1:</u> The configuration values for packet rate and packet delay can be adjusted to reflect the actual parameters of the given PCAP files. The values are in relation to packet time of the PCAP files, not real time. So the packet rate does not correlate with the actual processing speed (which might be higher or lower than the packet rate within the PCAP files). The packet rate should be adjusted if the debug value "Packets processed too early" is non-zero. The default packet delay is set to 1 second to reduce the amount of memory required but should be adjusted to the expected maximum delay within the PCAP recording.

<u>IMPORTANT NOTE 2:</u> If time stamp adjustment is used, all time stamps from the client file are adjusted which affects the analysis, but also the capture of these packets. So when doing a capture from that client file data, the packet time stamps are no longer the original timestamps but adjusted by the configured time delta.

== Measurement statistics ==

{|class="wikitable sortable"
|-
|[[File:Ap-mm-path-measurement-2.png|600px|none|right]]
|}

=== Measurement ===
The '''measurement''' tab show the real-time results of the ongoing measurement.
At the top the current state of the measurement engine and the remote connection is shown.
The measurement status can be '''not running''' if it is disabled, '''warming up''' if the engine waits for synchronization with remote device, and '''running''' if it actually measures data.
The '''remote client status''' indicates if the connection to the remote device is established.
Since the packet information are gathered real regular capturing from the remote device, the capture connection is visible in the capture section of the remote device and might be stopped there.
If the measurement connection is stopped or stopped working for other reasons (remote device unavailable, etc), the status box will turn red and a button appears to reconnect to the remote device.
If the reconnect fails, an error message appears with detailed information what was going wrong.

''' Typical errors are:'''
*remote device inaccessible (are the IP and port settings correct?)
* authentication error (invalid credentials?) When both boxes are green, the measurement is running and the four graphs show the real-time results.
* Insufficient memory: Usually may only appear in PCAP analysis mode indicating that the values for packet delay and packet rate are too large. Either reduce the values or use a larger storage devices capable of storing the required data (amount shown in the configuration section)

==== Two-Way-Latency ====

The first graph shows the latency measured from the main device to the remote device and back.
It cannot (due to asynchronous local time sources) measure the one-way latency of a single packet but only the duration of packets going in both directions.
Example: Assume a packet A is seen from main to remote device and another packet B is seen from remote to main device.
The time difference when packet A is seen on main and on remote device plus the time difference of packet B being seen on remote and main device is taken into account to determine the two-way latency. Packet A and packet B do not need to be related in any way.
If traffic is going only in one direction, the measurement will not show any time result (even though packet loss is still visible).
For each second, the average, minimum, and maximum two-way-latency is accounted and shown in the graph.
To the left of the graph the statistics for the visible time range is shown, changing the zoom level or time interval will update the values accordingly.

==== One-Way-Latency ====
If the path measurement is used on a single device (by selecting the primary device as client device too), the one-way latency is shown for each direction instead of the two-way-latency. PCAP buttons are available for a capture of high latency packets that exceeds the configured threshold.

==== Lost packets ====

The second and third graph show the number of lost packets in each direction. Lost packets are only accounted for connections that have been seen on both devices.

Depending on the installation point and routing setup, connections might be not be routed to the second device on purpose. These connections are not accounted as loss on the other device.

The second graph accounts all packets that have been seen on the remote device, but are missed on the main device. That means that those packets got loss on its way to the main device.

Accordingly, the third graph accounts all packets that have been seen on the main device, but are missed on the remote device. An additional counter "'''Client packet drop due to overload'''" indicates if some packets could not have been captured on the client device so they are missing for comparison at the main device. If this value is not zero, those packets are accounted as packet loss even though it might not be actually losses. For correct measurements, make sure the graph for remote packet drops is never non-zero. These drops may happen due to several reasons:

A capture button for lost packets is available for capturing packets seen on main device but considered as lost on the remote device. The capture is available for live mode only, i.e. if a time interval is selected in the Allegro Network Multimeter it will be ignored. When starting the capture, the path measurement engine will store all packets on the main device with the configured length and write them after the packet delay timeout into the PCAP. Only packets of the main device are considered (packets lost on main device but seen on remote device will '''not''' be captured). For a single device measurement between different VLGs the lost packets PCAP buttons are available for both directions (main to remote or remote to main).

#System capture overload: If multiple captures are running in parallel, the CPU might be overloaded. Check the '''All''' tab in the Capture page to see how many captures are running. In best case there is only the one capturing connection to the main device.
#The capturing connection is encrypted with SSL. The small Allegro 200 has a limited encryption capacity so for large traffic this can be a bottleneck. The only solution is to use a more powerful Allegro Network Multimeter.
#Capture drops can also occur if the network connection is not capable of transferring the data fast enough. Rule of thumb is that approximately 5% of the total traffic is used for the measurement connection. For example, if the traffic is 500 MBit/s, the measurement requires ~25 MBit/s of bandwidth on the management port.

==== Monitored packet rate ====
The fourth graph shows all packets that are monitored for the path measurement. This will cover all connections that have been seen on both devices.

==== NAT collision packet rate ====
This graph shows the number of packets per second that appeared in connections with colliding IP addresses/ports in NAT setups. This happens if matching packets are seen on both sides for more than two connections (the internal and the external connection). Since this is only relevant for matching packets within the defined timeout, it may help to reduce the timeout if possible.

=== IP addresses ===

The second tab shows packet loss information for each pair of [[Common table columns#IP|IP addresses]]. This statistic covers all IP connections that has been seen on both measurement sides. The table shows the number of packets that have been counted for each communication pair. Additionally the number of packets seen on the main device and the corresponding packet loss is shown. The same statistics are shown for the client device too. You can click on the IP address to go to the detailed statistics of the IP module to check which kind of traffic was happening for that IP. Two graphs are shown for each IP pair which shows the packet loss for both direction on one graph and the total packets in the second graph.
There is also a capture button to capture traffic for the IP pair. The captured traffic is only the traffic seen on the main device, it will not contain any packet from the client device as the main device does not have the packet data information available. To capture traffic from the client device, you have to go to the web interface of the client device and start a capture on that device.

The IP pair table also show the two-way latencies for the traffic of each IP pair, if the corresponding toggle is selected above the table. In single-device mode, also the one-way latency is shown.

For each IP, there is also a link to the IP connections. If enabled, each individual IP connection also stores the latencies for more detailed view.

==== Switching graph modes ====

The toggle buttons above the graphs allow to switch the graph modes from absolute values to relative values. This setting will show the lost packets in relation to the total (monitored) traffic. The second option allows to show Mbit/s throughput instead of the packet rate.

== Limitations ==

There are some limitations about the path measurement:

# Due to technical reasons, large clock adjustments cannot be filtered out. So in such cases, a very large two-way-latency is measured. Both devices need not be time synchronized per se, however, considerable time differentiation must be avoided. This means that time synchronization (e.g. NTP/PTP) should either be enabled or disabled on both devices for best results. Clock differentiation miss-measurements are however one-time events, and will not lead to false values for the following packets.
# The maximum supported packet size for the path measurement is currently 2048 bytes. Larger packets are truncated for the measurement.
# WAN optimizer and similar devices which rewrite some of the traffic are not supported either. If packet data is changed (like modifying the TCP header, adding TCP options, etc) the flow will account packet loss on both sides as the original packets are not seen on the other side. If the device in between also modifies the IP addresses or ports, the flows will be accounted as unmonitored.
# The global setting for the packet length accounting should be set to the same value on both devices. Otherwise identical packets might be considered different because of different length and the bandwidth information will be inconsistent.
# (Only firmware < 4.3): NAT setups and different VLAN combinations on main and client are not supported at the moment. Such flows will be accounted as unmonitored flows in the debug view.

== Typical use cases==

See [[Analyze connections between remote sites]] to get a detailed overview of use cases and device setup.

== Debug information ==

The debug information tab shows additional statistics which are usually only relevant for identifying problems in the path measurement, either program errors or test setup errors.

#'''Monitored flows seen on both devices:'''The monitored flows describes all IPv4 and IPv6 connections that have been seen on both devices and are used for calculating the latency and packet loss. Only this traffic can be considered for the actual measurement. In a working setup, the value must be non-zero.
#'''Flows seen on both devices without matching packets:''' If a flow is seen on both devices but not a single packet matches on both sides, it indicates a potential network setup problem. This probably means the packet is somehow modified by a device in between both measurement points. This setup is not supported. Usually this value should be zero. Small non-zero values can be ok, if the first number of monitored flows is much larger.
#'''Unmonitored flows seen only on ''main'':''' This counter shows the number of IP connections that are only visible at the main device. It means that for those connections no matching client packet has been received. If the main device also sees network traffic that is not routed to the client device, this value can be non-zero.
#'''Unmonitored flows seen only on ''client''''': This is the same counter as for the main device, but counting the connections on the client device that have not been seen on the main. Again, if the client device sees traffic that is not routed to the main, it is fine to see non-zero values here.

Possible problematic scenarios:

* There is a device between main and client that modifies the traffic (like a WAN optimizer): You will notice a larger value for counter 2 (flow without matching packets),almost zero value for counter 1 (flows seen on both devices).

* There is a device between main and client that changes ports and IP addresses (a NAT):

You will notice almost zero values for counter 1 and 2, but high values for counter 3 and 4.

Both scenarios are not supported by the path measurement.

Please adjust the test setup to disable any device modifying the network as described above.

The table below shows the following counters for the main and remote device:

#The counter about packets seen on all devices measures the total amount of packets monitored and considered for the analysis.
#The packets seen only on one devices indicates how much packets are lost on the other devices.
#Duplicated packets: This counter includes packets that are duplicated or have the same checksum. It is valid to see non-zero values here. Some protocols like broadcast actually do not differ in the payload so the packet checksum will be identical. If those packets appear within the packet delay time window, it is accounted as a duplicate to the previous one.
#Failed to process on main device: This counter indicates that packets from the client have been discarded due to overload of the main device. The main device was not fast enough to process client packets. This usually means the local packet rate (at the main device) is too high.
# Ignored on main device: These packets are ignored because the flow is unknown to the main devices. This happens when the packet checksum is received from the client but no connection information for that packet is known by the main device. This value should always be zero. Otherwise it means that the number of active flows is too high.
#Packets processed too early: This counter covers packets that packets could not be stored long enough to hit the configured packet delay limit. This happens when the packet rate is higher than the supported packet rate of the main device.
#NAT collision packets: This counter counts all packets that are seen on both sides for multiple connections so the Network Address Translation could not be reversed for connection tracking.

Below the table, two graphs showing time drift information are visible.
The first graph shows the '''packet delay'''. It is the time between a matching packet from the main device and the client.
This value describes for how long the main device needed to wait to get a matching packet from the client.
This value should always be much lower than the maximum packet delay configured in the path measurement configuration.
The value cannot be larger than the maximum as then packets can no longer be matched. If the value keeps reaching the maximum, two problems are possible:

#The delay between main device and client is large due to generic network delay. For example, if a high-latency connection is used for path measurement, it can even take a few seconds for a packet info to arrive. Configure a larger maximum packet delay.
#The bandwidth of the connection from the client (the client’s upload speed) is too small to satisfy the requirement for the checksum connection. This problem can be identified if even increasing the maximum packet delay does not help. If the bandwidth is too small, the packet will hit the maximum delay for any value configured, it will just take a little longer.

In this case try to use an alternative network connection to connect to the client device.

The second graph shows the time drift between the main device and client device.
Usually there will always be a drift between the clocks of both devices (if they are not synchronized by some mean). Even large drifts (hours, days, etc) are typically not a problem as the two-way latency zero-out the drift.
But if the drift increased dramatically (like multiple seconds) constantly over a large period of time, it usually indicates a bandwidth overload just like the first graph.

== FAQ ==
# What does the note '''Network setup problem detected: Packet modification or complete loss''' means?
#:This message box appears if flows have been identified for which not a single packet could be seen on both sides. Usually this means that there is some device in between both measurement points that modifies the packet. This can be WAN optimizer which rewrite TCP connection for improved network performance. Such setup is not supported.
#: It can also mean that some other packet field is modified at some point in the network. One field that is known for modification is the IP identification field in the IPv4 header. For this case an additional option can be enabled to ignore this field.
#: When using the PCAP analysis mode, this error can also appear if the files are not time synchronized. In this case, a time adjustment value must be entered to synchronize both files. A test run can be used to calculate a possible value.
# What does the note '''VLAN tag mismatch detected for matching packets on main device and client''' means?
#:This message indicates that matching packets have been seen on both devices but the used VLAN tag is different. Depending on the measurement setup, this may indicate an error as for connection matching the IP addresses, ports, and VLAN tags are used unless the option to ignore the VLAN tag is enabled. Therefore, the identical packets will be accounted for two different connections often resulting in shown packet loss.
#: Often, the recommended solution is to enable the configuration option '''Ignore VLAN tags for connection matching'''.
# What kind of packet information is used to determine latency and packet loss?
#:Both measurement devices calculate checksums starting from the layer 3 packet data to compare packet information on both sides. This means for IPv4 and IPv6 traffic, the Ethernet header including possible VLAN tags is ignored. For non-IP traffic, the complete layer 2 packet is used so this traffic can only be analyzed in switched networks.
# What can I do if I think the packet loss is wrong?
#: Often, incorrect loss is reported because there is some kind of packet modification that is not support. See the list of limitations above if any of those apply to your setup. Also, try the configuration options to ignore some packet fields to see if that makes any difference.
#: You can contact [[Reaching Allegro Support|our support]] and if possible provide a small capture from both network sides that cover the same traffic. This will help us to find the reason for the shown packet loss.
# How can I distinguish between real packet loss and reported packet loss due to packet modifications?
#: Packet loss is reported when a packet checksum does not match any other checksum reported by the other side within the configured maximum packet delay timeout. Reasons for such an event are
## Actual loss
##: The packet have been seen on one side but not the other. In this event the loss graph is usually different between the main device and remote device.
## Packet modification
##: Some component modifies the packet in some way. Since such a modification is usually done in both direction (sender and receiver), the packet loss is visible on both sides. Therefore the loss graph is symmetrical.
## Overloaded management connection
##: The management connection is used to get packet checksum from the remote device. If the connection is not fast enough to transmit the checksum within the configured maximum packet delay time, the packets are then reported as loss.
##: This can be verified by looking at the debug graph '''Packet delay between local and remote packets'''. In this event, the time will always be at the top limit that is the maximum packet delay time.
## Temporary network failure
##: In this event the packets are really lost on both directions so the loss graph may also look similar. However, since no packet can be transmitted to the other side, you will also see no entries in the two-way-latency graph.
# How is the two-way latency calculated?
#:The system monitors individual IP connections and stores the time difference between the occurrence of the same checksum on both the main and client devices. Since this time difference contains the unknown time drift between both systems, it cannot be used directly as a latency value. Instead, the system waits until a packet from the opposite direction has been seen on both systems. Both time differences for direction A->B and B->A build the actual two-way latency. Since both packets may not be directly related, it is not directly comparable with a round-trip time. It gives however an accurate view on how long data took transmitting back and forth during each individual time segment.

Longterm DB

2025-08-14T09:55:56Z

Ralf:

==Description==
The Long-term DB feature (in firmware >= 4.3) uses an attached storage devices to store traffic information of IP addresses and Layer 7 protocols with low resolution for a much longer time than the live statistics.

The elements stored in the long-term DB are as follows, graph data is available in 5 minute resolution:

* MAC addresses (in firmware >= 4.5)
*# activity time
*# traffic graph in 5 minute resolution
*# global statistics
* IP addresses
*# activity time
*# traffic graph in 5 minute resolution
*# global statistics (in firmware >= 4.5)
*# IP peers and their traffic (in firmware >= 4.6)
*IP groups (in firmware >= 4.5)
*# activity time
*# traffic graph in 5 minute resolution
* Global IP pairs (in firmware >= 4.6)
*# List of IP pairs and their traffic
* Layer 7 protocols
*# traffic graph in 5 minute resolution

The storage is used similar to a swap file mechanism. The long-term data needs to be written in a format readable by new versions. Since firmware version 4.5, this is done automatically on restarts. An option allows to write the DB back into a persisted format on a daily basis.

==Usage==
[[File:Longterm DB dashboard.png|alt=Long-term DB activated dashboard|thumb|Long-term DB activated dashboard]]If this feature is enabled, a view toggle button appears in the top menu bar. This button allows to switch between the real time "RT" view and the long-term ("LT") view.

In the long-term view, the IP address information contain only information about the traffic amount in 5 minute resolution.

The navigation menu in the long-term view only contains those modules which are available in this view.

If the long-term view is activated on module pages which do not support long-term data, a corresponding info box is shown.

==Setting==
The configuration can be found in the global settings page in the "Long-term DB and persistence" tab.

* To enable this feature, select a storage device to be used, enable the feature and enter a file size. The "required storage space" field shows how much memory is actually used which is usually at least double the configuration long-term DB size (due to additional space required for data persistence).
* The option "Data persistence mode" allows to select an alternative mode which also dumps parts of the live database onto disc. This increases the amount of space and time required to write the data and is usually not necessary.
* The long-term data base can be persisted once per day by enabling the corresponding option and selecting a time of day where the dump should happen. It is recommended to enable this option and to choose a time with less traffic then usual to avoid system overload during the dump time.

Once enabled, the utilization of the file is shown and the [[System Info Page]] contains information about how long the data can be kept.

Tip: Since the amount of information stored in the long-term DB is limited by the graph resolution, the file size usually don't need to be similar sized as the main memory. 10 GByte is a good starting point.

The size can be increase but it requires a restart of the packet processing.

[[File:DB persistence settings.png|thumb|Long-term DB settings]]

== Notes ==
Recommended storage device types:
{| class="wikitable"
|+
!Storage device
!Note
|-
|NMVe based SSD
|recommended
|-
|SATA based SSD
|can be used for moderate traffic, check system load for high system utilization
|-
|USB based SSD
|not recommended, but might be useful for small systems (Allegro 200/500/510)
|-
|HDD
|not recommended, should not be used
|}
It is also not recommended to place the long-term DB on the same storage device that is used a packet ring buffer as it will deteriorate the performance of both features.

The feature can be disabled temporarily and the last snapshot of persisted data is still kept. To remove this data permanently, use the delete buttons at the bottom of the configuration page.

== Limitations ==

# The data in the long-term DB is limited to a selected subset of the data in the In-Memory-DB. See above for an exact list of elements available.
# The data is written into the long-term DB in variable intervals depending on traffic and system load. It takes up to 10 minutes (two graph intervals) until the data appears in the graph. Therefore, the last 5-10 minutes appear empty or with less traffic than in live view.

List of Supported Transceiver Modules

2025-08-08T09:27:32Z

Ralf: /* List of tested third-party modules */

== DISCLAIMER ==

Allegro Packets allows you to use third-party vendor modules in its appliances but guarantees only warranty and support for transceiver modules sold by Allegro Packets. Any malfunction or configuration issue with third-party modules are NOT covered by the warranty.

Allegro Packets does not restrict the use of third-party SFP+ modules for the devices. However, some hardware limitations apply which are described as follows:

== Built-in ports vs. expansion cards ==

The Allegro Network Multimeter 800/810/1000/1010/1200/3000/3010/3200/x310/x410 series have two on-board SFP+ ports which are restricted to original or branded '''Intel modules'''.

All non built-in ports are '''not''' vendor locked and can accept all transceiver modules. However, there are modules that do not work because of specific vendor extensions within the modules. This applies for all ports of the Allegro Network Multimeter x300, x310, x400, x410, x500 and x510 series and all expansion cards for the Allegro Network Multimeter 810/1000/1010/1200/3000/3010/3200.

The following table shows which kind of modules are supported by Allegro by
port type:

{| class="wikitable sortable"
|-
! Port type !!original or branded Intel modules !! non-Intel branded modules
|-
| built-in SFP+ ports || x || -
|-
| SFP+ expansion|| x || x
|-
| SFP28 expansion|| x || x
|-
| QSFP expansion|| x|| x
|-
| QSFP28 expansion|| x || x
|-
|}

The use of Intel branded modules is mandatory for the built-in SFP+ ports. These restrictions do not apply to the additional network expansion cards (2 port and 4 port SFP+, high precision GPS card, etc.) that are available for the Allegro Network Multimeter 1000 and 3000 series. These ports accept generic modules from a wide range of vendors.

Since auto-negotiation is often not available on 1G/10G SFP+ interfaces, it may be necessary to manually set the correct speed in the `Interface Stats` section of the user interface.

QSFP+ breakout cables are NOT supported.

== List of tested third-party modules ==

The following list of modules have been either tested by Allegro Packets or customers and have been reported to operate

NOTE: Please be aware that this can change due new module revisions. Specific module (firmware) settings may also be required to make modules work.

{| class="wikitable"
|-
! Optics/Copper Module !! Transceiver P/N !! Media Type
!Connector
!Speed!! Remarks
|-
|SFP
|Flexoptix T.C12.02.A
|Copper
| RJ45
|10/100/1000M
|not supported in builtin ports in model 810/1000/1010/1200/3000/3010/3200, only in expansion slots,
|-
|SFP
|Finisar FCLF8521P2BTL
|Copper
|RJ45
|10/100/1000M
|not supported in builtin ports in model 810/1000/1010/1200/3000/3010/3200, only in expansion slots,
|-
|SFP
|Flexoptix S.1312.10.D
|Fiber (LR)
|LC
|1G
|not supported in onboard Allegro 810/1000/1010/1200/3000/3010/3200 SFP+ ports
supported in Allegro 800 and any SFP+ expansion card
|-
|SFP
|Flexoptix S.8512.02.D
|Fiber (SR)
|LC
|1G
|not supported in onboard Allegro 810/1000/1010/1200/3000/3010/3200 SFP+ ports
supported in Allegro 800 and any SFP+ expansion card
|-
|SFP
|Flexoptix S.B1312.10.DL
Flexoptix S.B1512.10.DL
|Fiber (LR, BiDi)
|LC
|1G
|not supported in onboard Allegro 810/1000/1010/1200/3000/3010/3200 SFP+ ports

supported in Allegro 800 and any SFP+ expansion card

requires Intel branding
|-
| SFP+ || Intel E10GSFPSR || Fiber (SR)
|
|1G/10G||
|-
| SFP+ || Intel E10GSFPLR || Fiber (LR)
|
|1G/10G||
|-
| SFP+ || Intel XDACBL1M, XDACBL3M or XDACBL5M|| DA(Copper, Passive)
| -
| 10G
|
|-
| SFP+ || Flexoptix P.8596.02 || Fiber (SR)
|LC
|1G/10G|| requires Intel branding
|-
| SFP+ || Flexoptix P.1396.10 || Fiber (LR)
|LC
|1G/10G|| requires Intel branding
|-
| SFP+ || fs.com 36431 || Fiber (SR)
|LC
|10G|| requires Intel branding, supports only 10G operation, 1G does NOT work
|-
| SFP+ || fs.com 36432 || Fiber (LR)
|LC
|10G|| requires Intel branding, supports only 10G operation, 1G does NOT work
|-
| SFP28 || Flexoptix P.8525G.01 || Fiber (SR)
|LC
|25G|| recommended with Intel branding
|-
| SFP28 || Flexoptix P.1325G.10 || Fiber (LR)
|LC
|25G|| recommended with Intel branding
|-
| SFP28 || fs.com 68000 || Fiber (SR)
|LC
|25G|| requires Intel branding
|-
| QSFP+ || Flexoptix Q.8540G.02 || Fiber (SR4)
|MPO
|40G|| recommended with Intel branding
|-
| QSFP+ || Flexoptix Q.1640G.10 || Fiber (LR4)
|LC
|40G|| recommended with Intel branding
|-
| QSFP+ || FINISAR FTL4C1QE1C || Fiber (LR4)
|
|40G||
|-
| QSFP+ || FINISAR FTL410QD2C || Fiber (SR4)
|
|40G||
|-
| QSFP+ || FINISAR FTL410QE1C || Fiber (SR4)
|
|40G||
|-
| QSFP+ || FINISAR FTL410QE2C || Fiber (SR4)
|
|40G||
|-
| QSFP+ || FINISAR FTL410QE3C || Fiber (SR4)
|
|40G||
|-
| QSFP+ || Amphenol 603020002, 603020005 || DA(Copper, Passive)
| -
|40G||
|-
| QSFP+ || fs.com 36281 || Fiber (SR4)
|MPO
|40G|| requires Intel branding
|-
| QSFP28 || Flexoptix Q.851HG.02 || Fiber (SR4)
|MPO
|100G||
|-
| QSFP28 || Flexoptix Q.161HG.10 || Fiber (LR4)
|LC
|100G||only works in High-Speed-100G card (A-P-2xQSFP28H) due to power budget limit
|-
| QSFP28 || fs.com 75308 || Fiber (SR4)
|MPO
|100G||
|-
| QSFP28 || Cisco QSFP-100G-CU (1M, 2M, 3M, 5M) || DA(Copper, Passive)
| -
|100G||
|-
|QSFP28
|QSFP28-100G-LR4-IX
|Fiber (LR4)
|LC
|100G
|only works in High-Speed-100G card (A-P-2xQSFP28H) due to power budget limit
|}

== Limited support ==
{| class="wikitable"
|-
! Optics/Copper Module !! Transceiver P/N !! Media Type
!Connector
!Speed!! Remarks
|-
|QSFP28
|QSFP28-100G-LR4-IX
|Fiber (LR4)
|LC
|100G
|only works in High-Speed-100G card (A-P-2xQSFP28H) due to power budget limit
|-
|QSFP+ 40G SR BG
|Cisco qsfp-40g-sr-bg P/N: 191402
|Fiber (SR4)
|
|40G
|only partial support, modules must be (re-) inserted after power up
|-
|QSFP+ 40G SR4
|Cisco qsfp-40g-sr4 P/N: 186602
|Fiber (SR4)
|
|40G
|only partial support, modules must be (re-) inserted after power up
|-
|QSFP+ 40G AOC
|Cisco qsfp-h40g-aoc10m P/N: 187627
|Fiber (SR)
|
|40G
|only partial support, modules must be (re-) inserted after power up
|}

== Non-working modules ==

Original Cisco modules have many issues working in the Allegro Network Multimeter. Allegro Packets got the feedback from multiple customers that they have issues with Cisco modules.

{| class="wikitable"
|-
! Optics/Copper Module !! Transceiver P/N !! Media Type !! Remarks
|-
| QSFP+ 40/100 SRBD || Cisco qsfp-40/100-srbd P/N: 199804 || Fiber (SR) || does '''NOT''' work
|-
| QSFP28 || Cisco QSFP-100G-SM-SR || Fiber (LR4 lite) || may work
|-
|QSFP28
|Innolight QSFP28 MSA LR4 P/N: TR-FC13R-N00
|Fiber (LR4)
|does '''NOT''' work
|}

== Link status issues with different network equipment ==

=== Problem: 1G link is not coming up with 1G/10G SFP+ fiber modules ===
There is a known incompatibility with our 1G/10G SFP+ fiber modules when used with some Cisco equipment, such as a Cisco Nexus or Catalyst switch with 1G connectivity.

The solution is as follows:

* Disable auto-negotiation for the Cisco switch port which is connected to the Allegro device.
* Manually set speed to 1G for the Cisco switch port

Example configuration for Nexus:
configure terminal
interface ethernet x/yy
speed 1000
no negotiate auto
Actual commands depends on the Cisco model. Alternative commands are:
speed nonegotiates
set port speed 1000
Combinations known to work for 1G connectivity:

* Our 1G/10G SFP+ SR module in an Allegro SFP port (article number 700)
* Cisco GLC-SX-MMD in a Cisco switch
* Cisco switch settings applied as described above

List of Supported Transceiver Modules

2025-08-08T09:25:53Z

Ralf: /* List of tested third-party modules */

== DISCLAIMER ==

Allegro Packets allows you to use third-party vendor modules in its appliances but guarantees only warranty and support for transceiver modules sold by Allegro Packets. Any malfunction or configuration issue with third-party modules are NOT covered by the warranty.

Allegro Packets does not restrict the use of third-party SFP+ modules for the devices. However, some hardware limitations apply which are described as follows:

== Built-in ports vs. expansion cards ==

The Allegro Network Multimeter 800/810/1000/1010/1200/3000/3010/3200/x310/x410 series have two on-board SFP+ ports which are restricted to original or branded '''Intel modules'''.

All non built-in ports are '''not''' vendor locked and can accept all transceiver modules. However, there are modules that do not work because of specific vendor extensions within the modules. This applies for all ports of the Allegro Network Multimeter x300, x310, x400, x410, x500 and x510 series and all expansion cards for the Allegro Network Multimeter 810/1000/1010/1200/3000/3010/3200.

The following table shows which kind of modules are supported by Allegro by
port type:

{| class="wikitable sortable"
|-
! Port type !!original or branded Intel modules !! non-Intel branded modules
|-
| built-in SFP+ ports || x || -
|-
| SFP+ expansion|| x || x
|-
| SFP28 expansion|| x || x
|-
| QSFP expansion|| x|| x
|-
| QSFP28 expansion|| x || x
|-
|}

The use of Intel branded modules is mandatory for the built-in SFP+ ports. These restrictions do not apply to the additional network expansion cards (2 port and 4 port SFP+, high precision GPS card, etc.) that are available for the Allegro Network Multimeter 1000 and 3000 series. These ports accept generic modules from a wide range of vendors.

Since auto-negotiation is often not available on 1G/10G SFP+ interfaces, it may be necessary to manually set the correct speed in the `Interface Stats` section of the user interface.

QSFP+ breakout cables are NOT supported.

== List of tested third-party modules ==

The following list of modules have been either tested by Allegro Packets or customers and have been reported to operate. Please be aware that this can change due new module revisions.

{| class="wikitable"
|-
! Optics/Copper Module !! Transceiver P/N !! Media Type
!Connector
!Speed!! Remarks
|-
|SFP
|Flexoptix T.C12.02.A
|Copper
| RJ45
|10/100/1000M
|not supported in builtin ports in model 810/1000/1010/1200/3000/3010/3200, only in expansion slots,
|-
|SFP
|Finisar FCLF8521P2BTL
|Copper
|RJ45
|10/100/1000M
|not supported in builtin ports in model 810/1000/1010/1200/3000/3010/3200, only in expansion slots,
|-
|SFP
|Flexoptix S.1312.10.D
|Fiber (LR)
|LC
|1G
|not supported in onboard Allegro 810/1000/1010/1200/3000/3010/3200 SFP+ ports
supported in Allegro 800 and any SFP+ expansion card
|-
|SFP
|Flexoptix S.8512.02.D
|Fiber (SR)
|LC
|1G
|not supported in onboard Allegro 810/1000/1010/1200/3000/3010/3200 SFP+ ports
supported in Allegro 800 and any SFP+ expansion card
|-
|SFP
|Flexoptix S.B1312.10.DL
Flexoptix S.B1512.10.DL
|Fiber (LR, BiDi)
|LC
|1G
|not supported in onboard Allegro 810/1000/1010/1200/3000/3010/3200 SFP+ ports

supported in Allegro 800 and any SFP+ expansion card

requires Intel branding
|-
| SFP+ || Intel E10GSFPSR || Fiber (SR)
|
|1G/10G||
|-
| SFP+ || Intel E10GSFPLR || Fiber (LR)
|
|1G/10G||
|-
| SFP+ || Intel XDACBL1M, XDACBL3M or XDACBL5M|| DA(Copper, Passive)
| -
| 10G
|
|-
| SFP+ || Flexoptix P.8596.02 || Fiber (SR)
|LC
|1G/10G|| requires Intel branding
|-
| SFP+ || Flexoptix P.1396.10 || Fiber (LR)
|LC
|1G/10G|| requires Intel branding
|-
| SFP+ || fs.com 36431 || Fiber (SR)
|LC
|10G|| requires Intel branding, supports only 10G operation, 1G does NOT work
|-
| SFP+ || fs.com 36432 || Fiber (LR)
|LC
|10G|| requires Intel branding, supports only 10G operation, 1G does NOT work
|-
| SFP28 || Flexoptix P.8525G.01 || Fiber (SR)
|LC
|25G|| recommended with Intel branding
|-
| SFP28 || Flexoptix P.1325G.10 || Fiber (LR)
|LC
|25G|| recommended with Intel branding
|-
| SFP28 || fs.com 68000 || Fiber (SR)
|LC
|25G|| requires Intel branding
|-
| QSFP+ || Flexoptix Q.8540G.02 || Fiber (SR4)
|MPO
|40G|| recommended with Intel branding
|-
| QSFP+ || Flexoptix Q.1640G.10 || Fiber (LR4)
|LC
|40G|| recommended with Intel branding
|-
| QSFP+ || FINISAR FTL4C1QE1C || Fiber (LR4)
|
|40G||
|-
| QSFP+ || FINISAR FTL410QD2C || Fiber (SR4)
|
|40G||
|-
| QSFP+ || FINISAR FTL410QE1C || Fiber (SR4)
|
|40G||
|-
| QSFP+ || FINISAR FTL410QE2C || Fiber (SR4)
|
|40G||
|-
| QSFP+ || FINISAR FTL410QE3C || Fiber (SR4)
|
|40G||
|-
| QSFP+ || Amphenol 603020002, 603020005 || DA(Copper, Passive)
| -
|40G||
|-
| QSFP+ || fs.com 36281 || Fiber (SR4)
|MPO
|40G|| requires Intel branding
|-
| QSFP28 || Flexoptix Q.851HG.02 || Fiber (SR4)
|MPO
|100G||
|-
| QSFP28 || Flexoptix Q.161HG.10 || Fiber (LR4)
|LC
|100G||only works in High-Speed-100G card (A-P-2xQSFP28H) due to power budget limit
|-
| QSFP28 || fs.com 75308 || Fiber (SR4)
|MPO
|100G||
|-
| QSFP28 || Cisco QSFP-100G-CU (1M, 2M, 3M, 5M) || DA(Copper, Passive)
| -
|100G||
|-
|QSFP28
|QSFP28-100G-LR4-IX
|Fiber (LR4)
|LC
|100G
|only works in High-Speed-100G card (A-P-2xQSFP28H) due to power budget limit
|}

== Limited support ==
{| class="wikitable"
|-
! Optics/Copper Module !! Transceiver P/N !! Media Type
!Connector
!Speed!! Remarks
|-
|QSFP28
|QSFP28-100G-LR4-IX
|Fiber (LR4)
|LC
|100G
|only works in High-Speed-100G card (A-P-2xQSFP28H) due to power budget limit
|-
|QSFP+ 40G SR BG
|Cisco qsfp-40g-sr-bg P/N: 191402
|Fiber (SR4)
|
|40G
|only partial support, modules must be (re-) inserted after power up
|-
|QSFP+ 40G SR4
|Cisco qsfp-40g-sr4 P/N: 186602
|Fiber (SR4)
|
|40G
|only partial support, modules must be (re-) inserted after power up
|-
|QSFP+ 40G AOC
|Cisco qsfp-h40g-aoc10m P/N: 187627
|Fiber (SR)
|
|40G
|only partial support, modules must be (re-) inserted after power up
|}

== Non-working modules ==

Original Cisco modules have many issues working in the Allegro Network Multimeter. Allegro Packets got the feedback from multiple customers that they have issues with Cisco modules.

{| class="wikitable"
|-
! Optics/Copper Module !! Transceiver P/N !! Media Type !! Remarks
|-
| QSFP+ 40/100 SRBD || Cisco qsfp-40/100-srbd P/N: 199804 || Fiber (SR) || does '''NOT''' work
|-
| QSFP28 || Cisco QSFP-100G-SM-SR || Fiber (LR4 lite) || may work
|-
|QSFP28
|Innolight QSFP28 MSA LR4 P/N: TR-FC13R-N00
|Fiber (LR4)
|does '''NOT''' work
|}

== Link status issues with different network equipment ==

=== Problem: 1G link is not coming up with 1G/10G SFP+ fiber modules ===
There is a known incompatibility with our 1G/10G SFP+ fiber modules when used with some Cisco equipment, such as a Cisco Nexus or Catalyst switch with 1G connectivity.

The solution is as follows:

* Disable auto-negotiation for the Cisco switch port which is connected to the Allegro device.
* Manually set speed to 1G for the Cisco switch port

Example configuration for Nexus:
configure terminal
interface ethernet x/yy
speed 1000
no negotiate auto
Actual commands depends on the Cisco model. Alternative commands are:
speed nonegotiates
set port speed 1000
Combinations known to work for 1G connectivity:

* Our 1G/10G SFP+ SR module in an Allegro SFP port (article number 700)
* Cisco GLC-SX-MMD in a Cisco switch
* Cisco switch settings applied as described above

Global settings

2025-07-28T09:23:05Z

Ralf: /* External original packet lengths */

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.<br/ >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.<br>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.<br />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.<br />[[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only".<br />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.<br />[[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.<br />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 <u>value shown in the graph</u> might be shown as 10 packets per second as each sample point is scaled to represent an value per second.<br>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. This is especially useful if truncated packets are received and the traffic statistics should still show the original traffic amount.

At this time only the Ixia/Keysight original packet length trailer format is supported. In firmware version >= 4.6, the length in the IP header can also be used as information about the original packet length. A type selector allows to choose the corresponding format.

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.

Capture module

2025-07-25T07:03:55Z

Ralf: /* Configuration settings */

==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", "P-Preferred-Identity". Call IDs, usernames and sip.instance values 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.
* '''callNumber''': SIP caller (SIP from tag) or callee (SIP to tag) number (firmware >= 4.5)
* '''callerNumber''': SIP caller (SIP from tag) number (firmware >= 4.5)
* '''calleeNumber''': SIP callee (SIP to tag) number (firmware >= 4.5)

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 <u>only DNS packets</u> 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.

<i>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</i>

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 maximum number of concurrent packet ring buffers is 8.

*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. The speed of the replay can be chosen below to real-time or specific speed or unlimited speed. The actual achievable speed depends on factors like the speed of the storage device. The maximum speed is typically <= 5 Gbps/400 kpps (also depending on the interface speed).

:* 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.

Process traffic capture from remote device

2025-07-18T13:29:59Z

Ralf:

== Overview ==
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.

===== Parallel remote packets =====
Starting with version 4.3 there is now the option to run the remote packet processing in parallel to the live analysis just like a parallel PCAP analysis or parallel Packet Ring Buffer analysis. For this to work the PCAP parallel analysis feature must be enabled (see [[PCAP parallel analysis]]).

In the tab ''Parallel remote packets'' the following parameters can be set:

* '''Port number:''' the port on which this parallel remote packet processing should listen for incoming connections
* '''Name:''' a name displayed on the Top User Dashboard when the replay slot is selected (optional)
* '''Description:''' a description displayed on the Top User Dashboard when the replay slot is selected (optional)
* '''Analysis Profile:''' a settings profile to be used for the parallel remote packet processing (see [[Pcap analysis module]])
* '''Replay Slot:''' the replay slot to be used for the parallel remote packet processing

A checkbox ''Use a temporary Packet Ring Buffer for the parallel remote packets analysis'' can be enabled to let the the parallel remote packet analysis use a Packet Ring Buffer on the selected storage device. This Packet Ring Buffer and all its contents will be deleted once the remote packets analysis ends. Selecting this checkbox shows the following additional settings:

* '''Storage device:''' the storage device on which to create the temporary Packet Ring Buffer
* '''Ring buffer size in MB:''' the size of the temporary Packet Ring Buffer in MB

Once the ''Start parallel remote packets'' button is pressed the user interface can be switched between the parallel remote packets analysis and live analysis just like with the parallel PCAP analysis by selecting the respective replay slot. The processing can be stopped in the ''Parallel remote packets'' tab or on the Top user dashboard when the replay slot is selected.

== Receive packets from remote capture device ==

=== Example uses ===

The capturing tool can be downloaded from the '''Remote packets''' page in the '''Generic''' section.
{| class="wikitable"
|-
| [[File:Process traffic capture from remote device.png|600px|none]]
|}

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.

To see all available options, execute the program with the argument "-h"
./ap_capture_to_remote -h

=== Additional notes ===

* The tool automatically applies a filter to not capture the connection to the remote Allegro Network Multimeter to avoid running a loop when the remote connection is visible on the captured interface. That means no additional actions need to be made to skip the remote capture connection.
* Not all interface types are supported for capturing. The interface must provide either Ethernet frames or WiFi frames.

===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

==Remote capture via ERSPAN==

The capturing tool also supports sending the packets as ERSPAN-wrapped packets. In this mode, the remote capture feature must be '''disabled''' and instead the regular live mode is used with an endpoint mode enabled interface.

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 123 1.2.3.4
In this mode, the [[ERSPAN Installation|endpopint mode for ERSPAN]] must be enabled and configured for the same IP as used in the ap_capture_to_remote command line argument.

Note that the IP address used is NOT the address or name of the management, but the separate IP address that is only valid on the interface for which the endpoint mode is configured.

__FORCETOC__

FAQ

2025-07-07T10:47:45Z

Ralf:

== Setup ==
==== What is the difference between the Monitor interfaces and the Management interfaces? ====

The Monitor interfaces are used to passively analyze traffic and cannot be used for management functions such as accessing
the user interface. These interfaces do not generate any traffic apart from forwarding traffic received on the adjacent
interface if configured to Bridge mode.
The Management interface on the other hand, is dedicated for management functions like accessing the user interface,
downloading and uploading pcaps, streaming captured data to the device for analysis and so on. The Management
interface actively participates in the network it is connected to.

==== How can I monitor the traffic of a single computer? ====

The easiest way of monitoring and analyzing the traffic of a single device like a computer is to configure the
Allegro Network Multimeter in Bridge mode. The device to be monitored is connected to one interface of a bridged pair
of interfaces on the Allegro Network Multimeter. The other interface of the bridged pair is connected to the
network to which the device would normally be directly connected.

In a setup like this, the Allegro Network Multimeter transparently forwards traffic between the device and the
network while providing full insight into the traffic between the device and the network.

==== What is the difference between Bridge mode and Sink mode? ====

If the Allegro Network Multimeter is configured to Sink mode, all Monitor interfaces act in a similar way in that they
receive traffic which is then analyzed by the appliance but not forwarded. The appliance acts as a traffic
sink, as it receives packets, analyzes them and discards them. This mode is ideally suited for situations
where traffic is already a copy; for example, on a Mirror Port of a Switch or on a network traffic Tap.

If configured in Bridge mode, the Allegro Network Multimeter transparently forwards all traffic between adjacent Monitor
interfaces while simultaneously analyzing the forwarded traffic. The appliance acts as a network Bridge and can
be connected between two network devices which would normally be connected directly to each other. This mode
is suited for inserting the Allegro Network Multimeter directly into a point of the network without the need of a separate network
Tap or other means of providing a copy of the network traffic.

==== I have used the LAN Management interface but I do not know the leased IP. How can I get the assigned IP address? ====

===== DHCP server =====

If the selected DHCP server provides some kind of log output or an overview of devices for which IP address leases have
been granted, it might help to search for a device with a hostname that starts with '''allegro-mm-''' followed by a four
digit hexadecimal number. The Allegro Network Multimeter announces itself with this hostname when it requests a
DHCP lease and should be traceable in the DHCP server info.

===== WI-FI =====

Every Allegro Network Multimeter comes with an USB to Wi-Fi adapter. In the factory default configuration the adapter will
create a wi-Fi Access Point when connected to the appliance. This Access Point shows up as '''allegro-mm-xxxx''' where the
'''xxxx''' part consists of a hexadecimal number which is unique to the device. In factory default settings the password
for the Wi-Fi network is '''Allegro-MM''' (without the quotes). As soon as there is a connection to Wi-Fi, the user
interface of the device can be accessed by either browsing to https://allegro or https://192.168.4.1.
When access to the user interface is established, the IP address of the LAN Management interface can be found under
'''Settings''' -> '''Management interface settings''' in the '''Active interfaces''' section.

===== Display =====

The Allegro Network Multimeter 200 comes with a HDMI connector and
the 1000 and 3000 series come with a VGA connector. When a compatible
display is connected, the console displays information about the running
Firmware version along with information on the configured
management network IP addresses. On the 200 model the
display must be connected before starting the appliance to obtain the output.

===== KVM =====

The video output of the device displaying the management IP addresses can be viewed over the network using the [[IPMI KVM on Allegro series 1000+|KVM/IPMI management module of the 1000 or 3000 series]]. Please see the FAQ entry '''What can I do with the integrated KVM port?''' on how to get started.

==== What can I do with the integrated KVM port? ====

The Allegro Network Multimeter 1000 and 3000 series devices contain a KVM/IPMI management module from Supermicro by
which several hardware management functions like powering the device on and off, system health messages and much
more can be accessed. It is also possible to view the video output of the device over the network from which the
current active management IP addresses can be retrieved.

By default the KVM/IPMI management module will obtain an IP address through DHCP and the default user name as well
as default password is '''ADMIN''' (without the quotes).

See [[IPMI KVM on Allegro series 1000+]] for additional information.

==== I do not have a Wi-Fi client and I do not have a DHCP server. How can I access the Allegro Network Multimeter? ====

It is possible to make the Allegro Network Multimeter set a temporary static address on the LAN management interface.
It will return to the configured behavior for the LAN management interface following the next restart.

To enable the temporary static IP address, a USB keyboard is needed. When the keyboard is attached to one of the USB
ports of the Allegro Network Multimeter, start the device. Wait for two minutes to make sure that the device is fully operational.
Then press and hold the '''shift''' key while pressing the '''s''' key. After this procedure the device will be configured to
use the IP address '''192.168.0.1''' on the LAN management interface. It is now possible to e.g. connect another
computer to the LAN management interface with an IP address statically configured to e.g. '''192.168.0.100''' and from
that computer the user interface of the Allegro Network Multimeter is accessible at https://192.168.0.1.
If for some reason the IP address '''192.168.0.1''' is already used in the network, the Allegro Network Multimeter will try to
set another IP address in the range of '''192.168.0.2''' - '''192.168.0.10'''.

Once access to the user interface is established, a static IP address can be configured under '''Settings''' ->
'''Management interface settings'''.

== Data protection ==

==== What kind of user data is stored on the Allegro Network Multimeter ====

All metadata and statistics are stored in the device's main memory and are deleted as soon as the device is rebooted,
powered off, or packet processing is restarted. Any user data that can be derived from these statistics is therefore
only stored for the duration of continuous operation. If, however, reports are generated and stored on the device, these
reports exist until manually deleted or until a device configuration reset is performed.

Raw packet data in the packet ring buffer or in stored pcap capture files will persist on the internal or external
storage until overwritten or deleted. If it is important that captured or deleted data must not be retrieved by someone
with physical access to the storage devices, it is possible to format the storage device with industry-standard full
disk encryption.

==== How can I reset the Allegro Network Multimeter to a default configuration? ====

There are two ways to reset the configuration of the appliance.

The first option is to use the '''Reset System Configuration''' button which can be found under '''Settings''' ->
'''Administration''' in the user interface. After confirmation, this will trigger a restart of the system and afterward the
appliance will revert to the factory default settings.

If, for some reason, the user interface is not accessible, a configuration reset can be performed by attaching
a USB keyboard and a HDMI/VGA display to the appliance. When booting the device, there is a short period when a GNU GRUB
menu is displayed. The arrow up and arrow down keys can be used to select an entry and the selected entry can be chosen
by pressing the '''enter''' key. Below the default '''multimeter''' entry, there is a '''configuration-reset''' option which will
perform a reset to default configuration and then reboot the appliance.

Keep in mind that a reset to the default configuration does not delete any
packet ring buffer data or captured files from internal or external
storage.

== System behavior ==

==== Where does the Allegro Network Multimeter display L1 issues like bad CRC frames? ====

Issues like these are accounted for the Monitoring interface on which the issue was encountered and the respective
statistics are available on the '''Interface stats''' page in the '''Errors''' column. For an explanation of the error
counters, refer to the [[Interface_statistics|Interface statistics]] manual page.

==== What happens in the case of a system overload? ====

In the case of a system overload, a prominent warning is displayed at the top of the user interface for a few seconds
and this warning and the time when the error occurred can be reviewed on the '''Info''' -> '''Status''' page. As long as there are
still notifications on the '''Info''' -> '''Status''' page, this is indicated by colored icons at the top of the user interface.

If a system overload occurs and not all packets can be analyzed, these packets are accounted at the Monitoring
interface on which they were received. The counter can be found on the '''Interface stats''' page in the '''Errors''' column
under the '''Not processed''' section and titled '''due to overload'''.

When the Allegro Network Multimeter is operating in Bridge mode and packets cannot be processed due to a system
overload, a software bypass will ensure that these packets are still forwarded to the adjacent Monitoring interface.

==== What happens if the maximum number of stored connections has been reached? ====

In this case, the Allegro Network Multimeter will start freeing up memory by removing historic statistical data which
lies before a certain point in time. This cut-off time is constantly adjusted to provide the best possible use of the
available memory. For how far back-in-time historical statistics are currently available, can be reviewed on the
'''Info''' -> '''System Info''' page.

==== I can only see the traffic of the last day. How can I increase this period? ====

If the system does not provide a sufficient look back-in-time with the given traffic, it may help to deactivate certain
features that provide very detailed information but also consume a large amount of memory. Features that typically
fit into this category are different settings of the '''IP statistics'''. These settings can be accessed by navigating to
'''IP''' -> '''IP Statistics''' and clicking the '''Settings''' button at the top of the page. Especially turning off the '''Store connection information for every IP''' and '''Store traffic history graph for IP peers''' settings can help saving
a lot of memory.

==== What happens to the data after shutdown, reboot, or restart processing? ====

The Allegro Network Multimeter uses an In-Memory database to store the
metadata of the packets it processes. This metadata will be lost when the
processing is stopped (shutdown, reboot, restart processing). This metadata
is also lost in case of an unexpected power loss.

When using a packet ring buffer (see [[Storage|storage]]), the packets will be
stored on the attached hard disk drive. This data is not lost after the
processing is stopped. It is possible to reanalyze the packet ring buffer, but
this will interrupt the '''live''' mode, so no new packets will be processed when this is in operation.

==== Why am I not seeing (expected) statistics or graphs in the web-interface? ====
There are several reasons why, the Allegro Network Multimeter may not show you the traffic that you are expecting. Here we will go into each and everyone of them.

First and foremost, always start out by verifying that (the expected amount of) network traffic is actually received by the Allegro Network Multimeter. This is done via the left menu, under "Interface stats". Another more global way for checking this, is via the Top Users dashboard, where the top graph "active interface overview" should display network traffic. If this is not the case, please (re)check all of the physical connections and span, tap, or endpoint-mode configurations in relation to the measurement/monitoring setup.

In a working setup, verifiable as described above, the "active interface overview" graph on the Top Users screen should display traffic. Here are several reasons why, the Allegro Network Multimeter may still not show you the traffic that you are expecting:

* Span/Mirror misconfiguration — When hooking up span/mirror port to your Allegro Network Multimeter, make sure that the traffic you want to see is actually incorporated in the configured span/mirror port.
* Virtual Link Group — If you have configured any virtual Link Groups, make sure that you are looking at the correct Link Group. I.e. the "local - default" Link Group will not plot any statistics, if all of the network traffic matches one ore more configured Link Group(s).
* Limited analysis — The "Detail of Traffic Analysis" (settings > global settings > middle of the page) may have been lowered. Factory default, this is set to "unlimited".
* Ingress filtering — Active ingress filtering (settings > ingress filter) will prevent partial or all network traffic from being analyzed by the Allegro Network Multimeter. A notification, indicating active filters, will show up in the top bar on the right.

[[File:Active Filter(s) Notification.png|550x550px]]

Important note: Filters do NOT have an effect on network Live traffic, which will be forwarded uninterrupted and fully transparently.

== Allegro Network Multimeter hardware ==

==== What types of SFP modules are supported? ====

See [[List_of_Supported_Transceiver_Modules|List of supported transceiver modules]] for details.

== Bypass ==

==== What bypass options are available? ====

Two bypass options are available:

* a quad-port RJ45 1Gbps copper option supporting 1000BaseT and 100BaseT speeds. Each pair of interfaces makes up a bridged link with bypass.
* a dual-port 10Gbps fiber option with built in SR transceivers and LC connectors. The two interfaces make up a bridged link with bypass.

==== How does the bypass work? ====

If the Allegro Network Multimeter contains a bypass option, it is only active when the device is configured to operate
in Bridge mode. The bypass activates when the device is powered off, when the device is starting but is not yet
processing traffic or when an unexpected failure like a crash or a power loss occurs. If the bypass is active, the
two interfaces that make up a bypass link will be physically connected to each other so that devices connected on
either side will always find a working link.

If the device is operating in Sink mode, the bypass interfaces will act just like all the other interfaces on the device
and the bypass will never be activated.

== User interface ==

==== What does the question mark on packets/bytes counters mean? ====

The Allegro Network Multimeter stores historical traffic data in different time resolutions depending on the age of the data.

When zooming into a specific time window, packet and byte counters are shown for this specific time interval only. Since the time resolution available internally might be coarser than the selected zoom level, the shown packet and byte values might not exactly represent the time interval.

If this is the case, the actual interval time is shown in square brackets (for example [120s]). This means that the value represents the time in seconds between the first and last data point used to calculate the displayed value.

This value is shown to avoid confusion about unexpected values due to interactive graph zooming.

==== How can I print statistics? ====

The Allegro Network Multimeter web interface can be printed by using
the built-in printing support of your browser. Navigate to the desired
statistics and click on the printing button (Ctrl+P in most browsers). The pages
are optimized for printing. Tabs, pcap and navigation buttons are hidden in
print mode.

If the browser is truncating the page in print preview, you can try the
'''Shrink to fit''' option (Firefox) or use a smaller scaling than 100% (Chrome).
You can also use another page orientation and change between '''landscape''' or '''portrait'''.

== Packet ring buffer ==

==== Which time stamps are used during packet ring buffer replay? ====

Packet ring buffer replay will use the original time stamps of the packets as they were captured. Therefore the replay
recreates the original sequence and timing of packets in the displayed statistics.

== Capturing ==

==== How many captures can be used in parallel? ====

Per default out-of-box setting (factory default), all Allegro Network Multimeter models allow up to 4 parallel captures. The number of allowed parallel captures, can be increased up to 64, depending on model and available RAM. Note, that Increasing the number of allowed parallel captures will decrease memory capacity for the in-memory DB, therewith decrease 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 Network Multimeter itself.

To change the number of allowed parallel captures, go to "Generic -> Capture traffic -> settings" or go to "Settings -> Module settings -> Caption: Capture traffic".

== Protocols ==

==== What protocols are recognized by the Allegro Network Multimeter ====

As an advanced packet-based network analysis and (performance) troubleshooting solution, Allegro Packets is capable of recognizing a long list of protocols to be found in various Ethernet-based network types. Apart from the actual recognition, Allegro Network Multimeter also features extensive individual decoding and graphical representation for quite a lot of commonly seen communication protocols such as TCP, SSL, SIP, RTP, DNS, DHCP, IEC 60870-5-104, PROFINET and many more.
A full list of protocols supported and recognized by the Allegro Network Multimeter can be found on the page -> [[Supported protocols]]

== TLS certificates ==

=== I get the message "Your TLS Certificate is about to expire soon. Please renew your certificate.", how can I renew it? ===
By default, the Allegro Network Multimeter uses a self-signed certificate that expires after 10 years. 2 weeks before expiration, this dialog appears to inform the user.

How to solve the issue:

# To create a new self-signed certificate, go to Settings -> [[Administration#TLS/SSL certificate|Administration]] and the TLS certificate section. Click on "Reset TLS certificate configuration" to delete the old, expiring certificate and a new certificate is created automatically.
# Reload the browser window, accept the new certificate to finalize the step.

For higher security, CA signed certificate can be uploaded manually or via ACME.

Incidents

2025-07-04T11:16:27Z

Ralf:

[[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 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 "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.
* Trigger cooldown: Depending on the selected trigger, once the incident was activated and finished, the trigger will wait for this cooldown period before the next incident may be triggered again. Each rule will have a seperate cooldown timer. The cooldown period may be configured in seconds.

=== Available triggers ===
{| class="wikitable"
|+
!Trigger name
!Description
!Attributes
!Attribute usage
|-
|ARP: MAC change for an IP<br>
(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<br>
(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<br>
(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<br>
(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<br>
(global_gps_sync_status_change)
|This trigger is checked when the GPS clock synchronization status changes.
|gps_sync_status
|optional
|-
|Global: Number of connections<br>
(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<br>
(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.
The expressions are [[wikipedia:Perl_Compatible_Regular_Expressions|Perl Compatible Regular Expressions (PCRE)]]
|
|no attributes are available for this trigger
|-
|Global: Ring buffer<br>
(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<br>
(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<br>
(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<br>
(global_interface_status_change)
|This trigger is checked when the status of an interfaces changes.
|interface_status
|optional
|-
|Global: Traffic<br>
(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<br>
(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<br>
(iec104_response_times)
|This trigger is checked whenever an IEC104 ACTCON reply for an ACT has been seen.
|response_time
|mandatory
|-
|IEC104: Traffic<br>
(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<br>
(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, l4_port, l4_client_port, l4_server_port
|mandatory
|-
|IP: Connection start<br>
(ip_flow_start)
|This trigger checks the attributes whenever an IP flow starts.
|new_connections, geolocation
|mandatory
|-
|IP: Local IP with multiple MAC addresses<br>
(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<br>
(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<br>
(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<br>
(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, l4_port, l4_server_port, l4_client_port, l7_protocol
|mandatory
|-
|IP: Traffic on IP addresses<br>
(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<br>
(ip_ttl_change)
|This trigger is checked continuously for each active IP.
|ttl_change
|mandatory
|-
|LACP: Status change of a channel<br>
(lacp_channel_status_change)
|This trigger is checked when the status of a LACP port channel changes.
|channel_status
|optional
|-
|MAC: New L7 protocol<br>
(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<br>
(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<br>
(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<br>
(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<br>
(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<br>
(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<br>
(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<br>
(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<br>
(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<br>
(smb_version_negotiation,

prior to 4.3: <s>smb_v1_negotiation</s>)
|This trigger is executed at the beginning of each SMB connection and checks whether insecure SMB1 has been negotiated (until firmware 4.3).
|
|none
|-
|SMB: SMB version negotiation<br>
(smb_version_negotiation)
|This trigger is executed at the beginning of each SMB connection and checks for a given SMB version (starting with firmware 4.4).
|version
|mandatory
|-
|TLS: first data packet
(tls_handshake_first_data)
|This trigger is checked when receiving the first data packet of each TLS connection.
|tls_first_data_time_ms
|mandatory
|-
|TLS: Handshake<br>
(tls_handshake,

prior to 4.4: <s>ssl_handshake</s>)
|This trigger is checked during handshake of each TLS connection.
|certificate_expires, tls_alert_level
|mandatory
|-
|TLS: TLS Handshake Server Hello
(tls_handshake_server_hello,

prior to 4.4: <s>tls_version</s>)
|This trigger is checked when receiving the Server Hello message of each TLS connection.
|used_tls_version, tls_handshake_time_ms
|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_port''': The layer 4 port number, will be compared against both sides of a connection.
* '''l4_client_port''': The layer 4 port number of the client side of a connection.
* '''l4_server_port''': The layer 4 port number of the server side of a connection.
* '''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.
* '''tls_handshake_time_ms:''' The [[TLS module|TLS handshake response time]] of the TLS handshake.
* '''tls_handshake_first_data:''' The [[TLS module|TLS data response time]] of the TLS handshake.
* '''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)
* '''version''':
** ''SMB: SMB version negotiation'': The SMB version SMB1 or SMB2/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), mTLS (firmware >= 4.4)
* 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.
* Partitioner (firmware >= 4.5)
** Random: Choose random partition on Kafka server (default)
** Consistent: Choose partition based on CRC32 hash of the multimeter hostname

'''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 of an even amount of 10 to 64 hexadecimal digits, optionally prefixed with "0x")

'''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.

After saving the configuration, a test message can be sent to the target system.

== 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.<br>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.

== Incident statistics ==
[[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.

Administration

2025-06-30T08:33:15Z

Ralf: /* TLS/SSL certificate */

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 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.

=== 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-06-26T06:46:26Z

Ralf: /* IPFIX 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.<br/ >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.<br>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.<br />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.<br />[[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only".<br />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.<br />[[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.<br />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 <u>value shown in the graph</u> might be shown as 10 packets per second as each sample point is scaled to represent an value per second.<br>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.

Path measurement

2025-06-25T06:42:56Z

Ralf: /* Settings */

== Path measurement ==

The path measurement module allows to passively measure the packet loss and latency between two Allegro Network Multimeter installations.

For example, a network connection (line/link) between the main office and a remote office can be analyzed by installing one Allegro Network Multimeter at the main office and another Allegro Network Multimeter at the remote office.

Only network traffic (packets) passing through both Allegro Network Multimeters can be analyzed. The packet loss and two-way-latency thereof is measured and shown in graphs.

The time synchronization setting (e.g. NTP/PTP or OFF) should be the same on both devices for the best results.

It is also possible to use a single device to measure the traffic delay/losses between two different [[Virtual Link Group functionality|virtual link groups]]. In this mode, the primary device is used as a client too.

Two pcap capture files can be compared to do an offline path measurement with previously captured files in two different locations.

=== Live analysis ===
In live analysis mode, the packets are either gathered from the local device and a configured remote Allegro Network Multimeter, or from two different sources on the same local devices (different interfaces, different VLAN tags, or similar parameters available through virtual link group configuration).

=== PCAP analysis ===
In PCAP mode, two PCAP files are processed the matching packets are used to determine the delay and possible loss between both files. For best results, the file should be recorded on the same device (by running two captures simultaneously from different sources), or from two devices with good time synchronization.

== Overview ==
The main device captures packet meta data from the remote (or client) device which takes only a fraction of the total traffic. Approximately 5% additional bandwidth is required for this capture connection. So for fully loaded 100 Mbit/s connection to the remote location an additional load of ~5 Mbit/s is required to get packet information to the main device.

The measurement connection can be a separate line or can be run over the line that is measured, the capture connection will be automatically ignored for the measurement.

The measurement module must be configured with a maximum packet delay. This delay describes the amount of time the main device waits for packet information to arrive from the remote device. The delay must be large enough to cover the actual latency of the connection and delay of the capture connection. Typical values are between 2 and 5 seconds. Larger values requires more memory to buffer packet meta data so very large values might only be selectable on larger Multimeter devices (Allegro 1000 or greater).
== Configuration live measurement ==

{|class="wikitable sortable"
|-
|[[File:Ap-mm-path-measurement-1.png|600px|none|right]]
|}

=== Settings ===

* Enable analysis: This will disable or enable the path measurement feature. When disabled, no additional memory is used. When enabled, memory for the packet buffer is used which cannot be used for other analyzing modules thus reducing the maximum time the device can go back in time.
Primary device settings:
* Description of this main device: This field is only used for informational purposes to identify the main device. It can be freely chosen, for example to the location the device is installed. This field can also be left empty to use the default name '''main'''.
* '''Primary device VLG filter:''' It is possible to limit the amount of data analyzed by any configured virtual link group. Often, the primary device is located at a central network point and thus sees a lot of traffic that is not actually going to the remote device. The algorithm will automatically take this into account, but using a filter will reduce the processing overhead as well as the amount of data that needs to be buffered.

The following '''Client device''' configuration section configures the access to the remote device:

* '''Device to use''': To use a remote device for path measurement, you first need to add that device as a remote device to the list of [[Multi-device settings]]. It does not matter if the device is active or not. You can select the device from the list of known multi-devices. You can also select the primary device as a client to analyze the traffic between two different virtual link groups.
* '''Device description''': Similar to the description of the main device, this field is for informational purpose only and has no other effect than helping identifying the remote device in the statistics. Usually the location of the remote device is entered.
* '''Client device VLG filter''': The traffic used for comparison at the main device can be filtered to any virtual link group defined at the client device. There are two main purposes for this setting:
*# reduce the amount of data required to be transferred to the main device. The path measurement only considers connections seen on both devices, but the client device of course cannot know if any connection it sees also is visible on the main device. If only traffic of a specific virtual link group (VLG) actually reaches the main device, using this filter can reduce the amount of data transferred and later dismissed.
*# filter duplicate traffic: If, for some reason, traffic is seen multiple times, it can create wrong results as the number of occurrences differs from main to client devices. A VLG filter can fix this problem by only considering one part of the total traffic.
* '''GNSS-synchronized clocks''' (Firmware >= 4.5): If the selected device is a remote device and both primary and client device have GNSS time synchronization enabled, this option can be enabled to generate one-way latency instead of regular two-way latency.

Measurement settings:

* '''Maximum packet delay''': This field describes the maximum amount of seconds to wait for packet information from the remote device.
: It basically means that the main devices waits for this number of seconds before deciding if a packet has been lost or not. If the data from the remote device arrives before those number of seconds, the path measurement can account the packet loss, if any and the two-way latency. This value must be at least as large as the worst-case latency between both measurement sites.
: Usually 3 seconds are more than enough but when the network in between can have a very long delay, you can increase the value. This will, however, use more main memory for the packet buffer.

* '''Maximum original packet rate:''' This field defines the maximum packet rate that is to be expected. It directly defines the necessary amount of memory for storing packet information for the defined packet delay. The field can be left empty (or zero) to use the maximum supported packet rate of the device. This value usually only has to be adjusted if the debug information about "Packets processed too early" is non-zero which indicates that the packet rate exceeded the assumed packet rate limit.

* '''Ignore IP identification field''': This option can be enabled if the IP identification field in the IPv4 header is modified by some component in the network. Often it remains constant for a single packet so this option should be left disabled as it will also increase the chance of reporting duplicate packets. But if you notice symmetrical packet loss you can enable this option to see if this helps.

*'''Ignore VLAN tags for connection matching''': The path measurement only calculate loss and latency for connections seen on both devices. Usually the connection ID takes the IP pairs, port ports and possible VLAN tags into account. If a VLAN is different on both machines for the some connection, then this option must be enabled to be able to correlate the connection and calculate correct statistics.
* '''Account latency also per IP connection''': Enabling this option will let the path measurement also store the latency for each individual IP connection, which of course increases the memory usage.
* '''Enable NAT mode''' (Firmware >= 4.3): This feature will enable support for Network-Address-Translation setup (typical for firewalls or internet uplink routers).
** '''NAT Private subnet/mask:''' This value describes the internal IP addresses that gets translated into an external IP address. An example value is "192.168.1.0/24" if all internal devices uses IP addresses in the range 192.168.1.0-192.168.1.255.
** '''NAT Public subnet/mask:''' This value defines the external IP address that internal IPs of the private subnet are translated to. It can also be an IP subnet (for example, if multiple external IP addresses are used). An example value is "10.1.2.3" if the NAT router is using the external IP 10.1.2.3 and all its internal clients are visible under this IP.
** '''Account unmatched flows:''' This option allows to monitor also connections there are not seen on the other measurement side. This is useful to see blocked connections in firewall setups.

* '''Maximum packet length for lost packets PCAP''': If a lost packet capture is running this setting configures the packet length for these packets. Keep this number as low as possible for optimal memory consumption. Each packet will be stored in memory until it is either confirmed by the client device (considered as not lost) or the maximum packet delay is over and the packet is considered lost and written to the PCAP.

* '''Threshold for high latency packets PCAP''': This is the threshold for a high latency PCAP. This is applied for single device measurement only. Packets with a larger time difference in their configured VLGs as this threshold can be captured. The latency value must not be larger than the maximum packet delay.

The settings must be saved but to actually take effect, a restart of the packet processing is necessary. If this step is required, a notification will tell so at the bottom of the page under '''Required actions'''.

=== Parameters currently in use ===

This section shows the current state of the measurement engine. The engine might be inactive even if the feature is enabled. Usually a restart is required to actually make it active. If active, the current packet delay is shown. It might be different from the selected value in the configuration above, but if so a note appears that a restart is required.

=== Required actions ===

An info box appears if the a restart of the packet processing is required. The shown link leads to the page '''Settings → Administration''' where the restart can be triggered. The device itself does not need to be rebooted, only the packet processing must be restarted which usually takes only a few seconds.

== Configuration PCAP measurement ==
[[File:Path-measurement-pcap-settings.png|border|660x660px]]

The path measurement can also be done based on two capture files created from two different network locations. The separate configuration tab "Configuration PCAP Analysis" allows to select two files from attached storage devices.

The files are replayed based on the packet time stamps within each file, in chronological order. Matching packets are only recognized if they are within the maximum packet delay. If the difference of the timestamps is larger, a time-delta adjustment value can be entered which will be added to the timestamp of the client packets. Negative values are possible as well to be able to adjust the time in both directions. If the time difference is too large, a lot of packet loss are reported, or even a "network setup problem" note is shown in the overview tab. If the time delta between both files is not known, a test run can be enabled to calculate the approximate difference. When both files are fully processed in this test run, the result is shown in the overview tab and this value can be used for the actual analysis.

The settings are similar to the live measurement. VLG filter can be applied to both files, but an option also allows to disable the use of the configured virtual link groups, or use separate groups for each file. In contrast to live mode, a VLG does not need to be used to differentiate traffic since it is clear from the selected file which one is the primary traffic and which one is the client traffic. But of course VLG can be used to filter out traffic that should not be part of the analysis.

The "Measurement settings" contains all settings from the live measurement plus three options only applicable in PCAP mode.

* Virtual link group mode: Select to either use:
** Use global VLG settings: Use the VLG configuration configured globally on this device.
** Use separate VLG per file: Create a temporary VLG for each file so all statistics can be accessed for each individual file regardless of the configuration of the regular virtual link groups.
** Disable use of VLGs: Disable all VLG configurations and use one common view of all data.
* Run analysis in main memory: The analysis requires a relatively large amount of memory depending on the setting values for packet delay and packet rate. In live mode, this data is always kept in main memory for performance reasons, but in PCAP mode the data is stored on a local storage device by default. This is slower but does not require a lot of additional memory reserved, especially when parallel pcap analysis is enabled.
* Storage device to use: If a storage device is available, the first one is selected by default. Otherwise the system disc is used to store the packet comparison information. The approximate amount of storage space required is shown below the selection box.

<u>IMPORTANT NOTE 1:</u> The configuration values for packet rate and packet delay can be adjusted to reflect the actual parameters of the given PCAP files. The values are in relation to packet time of the PCAP files, not real time. So the packet rate does not correlate with the actual processing speed (which might be higher or lower than the packet rate within the PCAP files). The packet rate should be adjusted if the debug value "Packets processed too early" is non-zero. The default packet delay is set to 1 second to reduce the amount of memory required but should be adjusted to the expected maximum delay within the PCAP recording.

<u>IMPORTANT NOTE 2:</u> If time stamp adjustment is used, all time stamps from the client file are adjusted which affects the analysis, but also the capture of these packets. So when doing a capture from that client file data, the packet time stamps are no longer the original timestamps but adjusted by the configured time delta.

== Measurement statistics ==

{|class="wikitable sortable"
|-
|[[File:Ap-mm-path-measurement-2.png|600px|none|right]]
|}

=== Measurement ===
The '''measurement''' tab show the real-time results of the ongoing measurement.
At the top the current state of the measurement engine and the remote connection is shown.
The measurement status can be '''not running''' if it is disabled, '''warming up''' if the engine waits for synchronization with remote device, and '''running''' if it actually measures data.
The '''remote client status''' indicates if the connection to the remote device is established.
Since the packet information are gathered real regular capturing from the remote device, the capture connection is visible in the capture section of the remote device and might be stopped there.
If the measurement connection is stopped or stopped working for other reasons (remote device unavailable, etc), the status box will turn red and a button appears to reconnect to the remote device.
If the reconnect fails, an error message appears with detailed information what was going wrong.

''' Typical errors are:'''
*remote device inaccessible (are the IP and port settings correct?)
* authentication error (invalid credentials?) When both boxes are green, the measurement is running and the four graphs show the real-time results.
* Insufficient memory: Usually may only appear in PCAP analysis mode indicating that the values for packet delay and packet rate are too large. Either reduce the values or use a larger storage devices capable of storing the required data (amount shown in the configuration section)

==== Two-Way-Latency ====

The first graph shows the latency measured from the main device to the remote device and back.
It cannot (due to asynchronous local time sources) measure the one-way latency of a single packet but only the duration of packets going in both directions.
Example: Assume a packet A is seen from main to remote device and another packet B is seen from remote to main device.
The time difference when packet A is seen on main and on remote device plus the time difference of packet B being seen on remote and main device is taken into account to determine the two-way latency. Packet A and packet B do not need to be related in any way.
If traffic is going only in one direction, the measurement will not show any time result (even though packet loss is still visible).
For each second, the average, minimum, and maximum two-way-latency is accounted and shown in the graph.
To the left of the graph the statistics for the visible time range is shown, changing the zoom level or time interval will update the values accordingly.

==== One-Way-Latency ====
If the path measurement is used on a single device (by selecting the primary device as client device too), the one-way latency is shown for each direction instead of the two-way-latency. PCAP buttons are available for a capture of high latency packets that exceeds the configured threshold.

==== Lost packets ====

The second and third graph show the number of lost packets in each direction. Lost packets are only accounted for connections that have been seen on both devices.

Depending on the installation point and routing setup, connections might be not be routed to the second device on purpose. These connections are not accounted as loss on the other device.

The second graph accounts all packets that have been seen on the remote device, but are missed on the main device. That means that those packets got loss on its way to the main device.

Accordingly, the third graph accounts all packets that have been seen on the main device, but are missed on the remote device. An additional counter "'''Client packet drop due to overload'''" indicates if some packets could not have been captured on the client device so they are missing for comparison at the main device. If this value is not zero, those packets are accounted as packet loss even though it might not be actually losses. For correct measurements, make sure the graph for remote packet drops is never non-zero. These drops may happen due to several reasons:

A capture button for lost packets is available for capturing packets seen on main device but considered as lost on the remote device. The capture is available for live mode only, i.e. if a time interval is selected in the Allegro Network Multimeter it will be ignored. When starting the capture, the path measurement engine will store all packets on the main device with the configured length and write them after the packet delay timeout into the PCAP. Only packets of the main device are considered (packets lost on main device but seen on remote device will '''not''' be captured). For a single device measurement between different VLGs the lost packets PCAP buttons are available for both directions (main to remote or remote to main).

#System capture overload: If multiple captures are running in parallel, the CPU might be overloaded. Check the '''All''' tab in the Capture page to see how many captures are running. In best case there is only the one capturing connection to the main device.
#The capturing connection is encrypted with SSL. The small Allegro 200 has a limited encryption capacity so for large traffic this can be a bottleneck. The only solution is to use a more powerful Allegro Network Multimeter.
#Capture drops can also occur if the network connection is not capable of transferring the data fast enough. Rule of thumb is that approximately 5% of the total traffic is used for the measurement connection. For example, if the traffic is 500 MBit/s, the measurement requires ~25 MBit/s of bandwidth on the management port.

==== Monitored packet rate ====
The fourth graph shows all packets that are monitored for the path measurement. This will cover all connections that have been seen on both devices.

==== NAT collision packet rate ====
This graph shows the number of packets per second that appeared in connections with colliding IP addresses/ports in NAT setups. This happens if matching packets are seen on both sides for more than two connections (the internal and the external connection). Since this is only relevant for matching packets within the defined timeout, it may help to reduce the timeout if possible.

=== IP addresses ===

The second tab shows packet loss information for each pair of [[Common table columns#IP|IP addresses]]. This statistic covers all IP connections that has been seen on both measurement sides. The table shows the number of packets that have been counted for each communication pair. Additionally the number of packets seen on the main device and the corresponding packet loss is shown. The same statistics are shown for the client device too. You can click on the IP address to go to the detailed statistics of the IP module to check which kind of traffic was happening for that IP. Two graphs are shown for each IP pair which shows the packet loss for both direction on one graph and the total packets in the second graph.
There is also a capture button to capture traffic for the IP pair. The captured traffic is only the traffic seen on the main device, it will not contain any packet from the client device as the main device does not have the packet data information available. To capture traffic from the client device, you have to go to the web interface of the client device and start a capture on that device.

The IP pair table also show the two-way latencies for the traffic of each IP pair, if the corresponding toggle is selected above the table. In single-device mode, also the one-way latency is shown.

For each IP, there is also a link to the IP connections. If enabled, each individual IP connection also stores the latencies for more detailed view.

==== Switching graph modes ====

The toggle buttons above the graphs allow to switch the graph modes from absolute values to relative values. This setting will show the lost packets in relation to the total (monitored) traffic. The second option allows to show Mbit/s throughput instead of the packet rate.

== Limitations ==

There are some limitations about the path measurement:

# Due to technical reasons, large clock adjustments cannot be filtered out. So in such cases, a very large two-way-latency is measured. Both devices need not be time synchronized per se, however, considerable time differentiation must be avoided. This means that time synchronization (e.g. NTP/PTP) should either be enabled or disabled on both devices for best results. Clock differentiation miss-measurements are however one-time events, and will not lead to false values for the following packets.
# The maximum supported packet size for the path measurement is currently 2048 bytes. Larger packets are truncated for the measurement.
# WAN optimizer and similar devices which rewrite some of the traffic are not supported either. If packet data is changed (like modifying the TCP header, adding TCP options, etc) the flow will account packet loss on both sides as the original packets are not seen on the other side. If the device in between also modifies the IP addresses or ports, the flows will be accounted as unmonitored.
# The global setting for the packet length accounting should be set to the same value on both devices. Otherwise identical packets might be considered different because of different length and the bandwidth information will be inconsistent.
# (Only firmware < 4.3): NAT setups and different VLAN combinations on main and client are not supported at the moment. Such flows will be accounted as unmonitored flows in the debug view.

== Typical use cases==

See [[Analyze connections between remote sites]] to get a detailed overview of use cases and device setup.

== Debug information ==

The debug information tab shows additional statistics which are usually only relevant for identifying problems in the path measurement, either program errors or test setup errors.

#'''Monitored flows seen on both devices:'''The monitored flows describes all IPv4 and IPv6 connections that have been seen on both devices and are used for calculating the latency and packet loss. Only this traffic can be considered for the actual measurement. In a working setup, the value must be non-zero.
#'''Flows seen on both devices without matching packets:''' If a flow is seen on both devices but not a single packet matches on both sides, it indicates a potential network setup problem. This probably means the packet is somehow modified by a device in between both measurement points. This setup is not supported. Usually this value should be zero. Small non-zero values can be ok, if the first number of monitored flows is much larger.
#'''Unmonitored flows seen only on ''main'':''' This counter shows the number of IP connections that are only visible at the main device. It means that for those connections no matching client packet has been received. If the main device also sees network traffic that is not routed to the client device, this value can be non-zero.
#'''Unmonitored flows seen only on ''client''''': This is the same counter as for the main device, but counting the connections on the client device that have not been seen on the main. Again, if the client device sees traffic that is not routed to the main, it is fine to see non-zero values here.

Possible problematic scenarios:

* There is a device between main and client that modifies the traffic (like a WAN optimizer): You will notice a larger value for counter 2 (flow without matching packets),almost zero value for counter 1 (flows seen on both devices).

* There is a device between main and client that changes ports and IP addresses (a NAT):

You will notice almost zero values for counter 1 and 2, but high values for counter 3 and 4.

Both scenarios are not supported by the path measurement.

Please adjust the test setup to disable any device modifying the network as described above.

The table below shows the following counters for the main and remote device:

#The counter about packets seen on all devices measures the total amount of packets monitored and considered for the analysis.
#The packets seen only on one devices indicates how much packets are lost on the other devices.
#Duplicated packets: This counter includes packets that are duplicated or have the same checksum. It is valid to see non-zero values here. Some protocols like broadcast actually do not differ in the payload so the packet checksum will be identical. If those packets appear within the packet delay time window, it is accounted as a duplicate to the previous one.
#Failed to process on main device: This counter indicates that packets from the client have been discarded due to overload of the main device. The main device was not fast enough to process client packets. This usually means the local packet rate (at the main device) is too high.
# Ignored on main device: These packets are ignored because the flow is unknown to the main devices. This happens when the packet checksum is received from the client but no connection information for that packet is known by the main device. This value should always be zero. Otherwise it means that the number of active flows is too high.
#Packets processed too early: This counter covers packets that packets could not be stored long enough to hit the configured packet delay limit. This happens when the packet rate is higher than the supported packet rate of the main device.
#NAT collision packets: This counter counts all packets that are seen on both sides for multiple connections so the Network Address Translation could not be reversed for connection tracking.

Below the table, two graphs showing time drift information are visible.
The first graph shows the '''packet delay'''. It is the time between a matching packet from the main device and the client.
This value describes for how long the main device needed to wait to get a matching packet from the client.
This value should always be much lower than the maximum packet delay configured in the path measurement configuration.
The value cannot be larger than the maximum as then packets can no longer be matched. If the value keeps reaching the maximum, two problems are possible:

#The delay between main device and client is large due to generic network delay. For example, if a high-latency connection is used for path measurement, it can even take a few seconds for a packet info to arrive. Configure a larger maximum packet delay.
#The bandwidth of the connection from the client (the client’s upload speed) is too small to satisfy the requirement for the checksum connection. This problem can be identified if even increasing the maximum packet delay does not help. If the bandwidth is too small, the packet will hit the maximum delay for any value configured, it will just take a little longer.

In this case try to use an alternative network connection to connect to the client device.

The second graph shows the time drift between the main device and client device.
Usually there will always be a drift between the clocks of both devices (if they are not synchronized by some mean). Even large drifts (hours, days, etc) are typically not a problem as the two-way latency zero-out the drift.
But if the drift increased dramatically (like multiple seconds) constantly over a large period of time, it usually indicates a bandwidth overload just like the first graph.

== FAQ ==
# What does the note '''Network setup problem detected: Packet modification or complete loss''' means?
#:This message box appears if flows have been identified for which not a single packet could be seen on both sides. Usually this means that there is some device in between both measurement points that modifies the packet. This can be WAN optimizer which rewrite TCP connection for improved network performance. Such setup is not supported.
#: It can also mean that some other packet field is modified at some point in the network. One field that is known for modification is the IP identification field in the IPv4 header. For this case an additional option can be enabled to ignore this field.
#: When using the PCAP analysis mode, this error can also appear if the files are not time synchronized. In this case, a time adjustment value must be entered to synchronize both files. A test run can be used to calculate a possible value.
# What does the note '''VLAN tag mismatch detected for matching packets on main device and client''' means?
#:This message indicates that matching packets have been seen on both devices but the used VLAN tag is different. Depending on the measurement setup, this may indicate an error as for connection matching the IP addresses, ports, and VLAN tags are used unless the option to ignore the VLAN tag is enabled. Therefore, the identical packets will be accounted for two different connections often resulting in shown packet loss.
#: Often, the recommended solution is to enable the configuration option '''Ignore VLAN tags for connection matching'''.
# What kind of packet information is used to determine latency and packet loss?
#:Both measurement devices calculate checksums starting from the layer 3 packet data to compare packet information on both sides. This means for IPv4 and IPv6 traffic, the Ethernet header including possible VLAN tags is ignored. For non-IP traffic, the complete layer 2 packet is used so this traffic can only be analyzed in switched networks.
# What can I do if I think the packet loss is wrong?
#: Often, incorrect loss is reported because there is some kind of packet modification that is not support. See the list of limitations above if any of those apply to your setup. Also, try the configuration options to ignore some packet fields to see if that makes any difference.
#: You can contact [[Reaching Allegro Support|our support]] and if possible provide a small capture from both network sides that cover the same traffic. This will help us to find the reason for the shown packet loss.
# How can I distinguish between real packet loss and reported packet loss due to packet modifications?
#: Packet loss is reported when a packet checksum does not match any other checksum reported by the other side within the configured maximum packet delay timeout. Reasons for such an event are
## Actual loss
##: The packet have been seen on one side but not the other. In this event the loss graph is usually different between the main device and remote device.
## Packet modification
##: Some component modifies the packet in some way. Since such a modification is usually done in both direction (sender and receiver), the packet loss is visible on both sides. Therefore the loss graph is symmetrical.
## Overloaded management connection
##: The management connection is used to get packet checksum from the remote device. If the connection is not fast enough to transmit the checksum within the configured maximum packet delay time, the packets are then reported as loss.
##: This can be verified by looking at the debug graph '''Packet delay between local and remote packets'''. In this event, the time will always be at the top limit that is the maximum packet delay time.
## Temporary network failure
##: In this event the packets are really lost on both directions so the loss graph may also look similar. However, since no packet can be transmitted to the other side, you will also see no entries in the two-way-latency graph.
# How is the two-way latency calculated?
#:The system monitors individual IP connections and stores the time difference between the occurrence of the same checksum on both the main and client devices. Since this time difference contains the unknown time drift between both systems, it cannot be used directly as a latency value. Instead, the system waits until a packet from the opposite direction has been seen on both systems. Both time differences for direction A->B and B->A build the actual two-way latency. Since both packets may not be directly related, it is not directly comparable with a round-trip time. It gives however an accurate view on how long data took transmitting back and forth during each individual time segment.

Longterm DB

2025-05-14T10:06:57Z

Ralf:

==Description==
The Long-term DB feature (in firmware >= 4.3) uses an attached storage devices to store traffic information of IP addresses and Layer 7 protocols with low resolution for a much longer time than the live statistics.

The elements stored in the long-term DB are as follows, graph data is available in 5 minute resolution:

* IP addresses
*# activity time
*# traffic graph in 5 minute resolution
* Layer 7 protocols
*# traffic graph in 5 minute resolution

The storage is used similar to a swap file mechanism. The long-term data needs to be written in a format readable by new versions. Since firmware version 4.5, this is done automatically on restarts. An option allows to write the DB back into a persisted format on a daily basis.

==Usage==
[[File:Longterm DB dashboard.png|alt=Long-term DB activated dashboard|thumb|Long-term DB activated dashboard]]If this feature is enabled, a view toggle button appears in the top menu bar. This button allows to switch between the real time "RT" view and the long-term ("LT") view.

In the long-term view, the IP address information contain only information about the traffic amount in 5 minute resolution.

The navigation menu in the long-term view only contains those modules which are available in this view.

If the long-term view is activated on module pages which do not support long-term data, a corresponding info box is shown.

==Setting==
The configuration can be found in the global settings page in the "Long-term DB and persistence" tab.

* To enable this feature, select a storage device to be used, enable the feature and enter a file size. The "required storage space" field shows how much memory is actually used which is usually at least double the configuration long-term DB size (due to additional space required for data persistence).
* The option "Data persistence mode" allows to select an alternative mode which also dumps parts of the live database onto disc. This increases the amount of space and time required to write the data and is usually not necessary.
* The long-term data base can be persisted once per day by enabling the corresponding option and selecting a time of day where the dump should happen. It is recommended to enable this option and to choose a time with less traffic then usual to avoid system overload during the dump time.

Once enabled, the utilization of the file is shown and the [[System Info Page]] contains information about how long the data can be kept.

Tip: Since the amount of information stored in the long-term DB is limited by the graph resolution, the file size usually don't need to be similar sized as the main memory. 10 GByte is a good starting point.

The size can be increase but it requires a restart of the packet processing.

[[File:DB persistence settings.png|thumb|Long-term DB settings]]

== Notes ==
Recommended storage device types:
{| class="wikitable"
|+
!Storage device
!Note
|-
|NMVe based SSD
|recommended
|-
|SATA based SSD
|can be used for moderate traffic, check system load for high system utilization
|-
|USB based SSD
|not recommended, but might be useful for small systems (Allegro 200/500/510)
|-
|HDD
|not recommended, should not be used
|}
It is also not recommended to place the long-term DB on the same storage device that is used a packet ring buffer as it will deteriorate the performance of both features.

The feature can be disabled temporarily and the last snapshot of persisted data is still kept. To remove this data permanently, use the delete buttons at the bottom of the configuration page.

== Limitations ==

# The data in the long-term DB is limited to a selected subset of the data in the In-Memory-DB. See above for an exact list of elements available.
# The data is written into the long-term DB in variable intervals depending on traffic and system load. It takes up to 10 minutes (two graph intervals) until the data appears in the graph. Therefore, the last 5-10 minutes appear empty or with less traffic than in live view.

DB persistence

2025-05-14T10:04:56Z

Ralf:

'''Note: Since firmware version 4.5, this feature is merged with the long-term DB feature and no separate configuration is required anymore.'''

The DB persistence feature (in firmware >= 4.2) can write parts of the In-Memory database onto an selected storage device when stopping the packet processing (either manually or when rebooting the device). On restart, the stored data is imported again to make some data available again after restart.

The stored data comprises:
[[File:DB persistence settings.png|thumb|DB persistence settings]]
* the list of MAC addresses and their direct graphs, not including the per-element tables.
* the list of IP addresses and their direct graphs (traffic, retransmissions and other TCP stats for that IP address), not including the per-element tables.
* the IP groups data (same elements as the IP addresses).
* the Layer 7 protocol traffic graphs.

The feature must be enabled in the global settings in the "Long-term DB and persistence" tab. The storage device must be selected and should be reasonable fast. We recommend using SSD storage only as it can take a few seconds to a few minutes on such fast disc but much longer on slower spinning discs.

The configuration sections shows the estimated required space on the storage device. Since the amount of data stored depends on the actual number elements (IP addresses etc), it may vary and the process will use less memory if possible or try to use more memory if necessary.

The processing restart dialog will allow to disable dump and/or restoration for one time.

The dialog also shows progress during restart which also to cancel the operation.

The configuration dialog also shows the size of the persisted data and allow to remove it.

=== Additional options ===

* With longterm DB, skip writing live data onto storage device (reduces dump/restore time): Since Firmware version 4.3, the [[Longterm DB]] is also stored on the SSD. To reduce the amount of time needed for dump and restore, the dump of the live data can be disabled since this is usually much more data and it might not be necessary to write this as well.
* Since firmware version 4.5, it is also possible to enable a periodic dump once per day. In case of unexpected loss of power or other restarts, the last dump will be automatically read in on restart. The configuration settings allows to select any full hour of the day. It is recommended to choose an hour with less traffic then usual as the dump process increases the load of the system.

=== Limitations ===

* Data dump and restoration works between the same firmware version and also between different firmware version but due to increasing feature set, importing data from a newer firmware (when downgrading) may not work always. In this case the import will be only partial and normal operation continues.
* Some setting changes will make the import of some data impossible:
** Changing the resolution of graph data is not supported for the DB persistence feature. The import will skip data from written with different settings.
* As with all data on storage devices, the configuration of factory reset will not delete the persisted DB data and it must be removed manually by either selecting the button in the configuration dialog or by formatting the storage device.

Global settings

2025-05-14T10:03:08Z

Ralf: /* Long-term DB and persistence (BETA) */

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.<br/ >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.<br>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.<br />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.<br />[[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only".<br />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.<br />[[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.<br />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 <u>value shown in the graph</u> might be shown as 10 packets per second as each sample point is scaled to represent an value per second.<br>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.

Longterm DB

2025-05-14T10:02:11Z

Ralf:

==Description==
The Long-term DB feature (in firmware >= 4.3) uses an attached storage devices to store traffic information of IP addresses and Layer 7 protocols with low resolution for a much longer time than the live statistics.

The elements stored in the long-term DB are as follows, graph data is available in 5 minute resolution:

* IP addresses
*# activity time
*# traffic graph in 5 minute resolution
* Layer 7 protocols
*# traffic graph in 5 minute resolution

The storage is used similar to a swap file mechanism. The long-term data needs to be written in a format readable by new versions. Since firmware version 4.5, this is done automatically on restarts. An option allows to write the DB back into a persisted format on a daily basis.

==Usage==
[[File:Longterm DB dashboard.png|alt=Long-term DB activated dashboard|thumb|Long-term DB activated dashboard]]If this feature is enabled, a view toggle button appears in the top menu bar. This button allows to switch between the real time "RT" view and the long-term ("LT") view.

In the long-term view, the IP address information contain only information about the traffic amount in 5 minute resolution.

The navigation menu in the long-term view only contains those modules which are available in this view.

If the long-term view is activated on module pages which do not support long-term data, a corresponding info box is shown.

==Setting==
The configuration can be found in the global settings page in the "Long-term DB and persistence" tab.

To enable this feature, select a storage device to be used, enable the feature and enter a file size.

The option "Data persistence mode" allows to select an alternative mode which also dumps parts of the live database onto disc. This increases the amount of space and time required to write the data and is usually not necessary.

The long-term data base can be persisted once per day by enabling the corresponding option and selecting a time of day where the dump should happen. It is recommended to enable this option and to choose a time with less traffic then usual to avoid system overload during the dump time.

Once enabled, the utilization of the file is shown and the [[System Info Page]] contains information about how long the data can be kept.

Tip: Since the amount of information stored in the long-term DB is limited by the graph resolution, the file size usually don't need to be similar sized as the main memory. 10 GByte is a good starting point.

The size can be increase but it requires a restart of the packet processing.

[[File:DB persistence settings.png|thumb|Long-term DB settings]]

== Notes ==
Recommended storage device types:
{| class="wikitable"
|+
!Storage device
!Note
|-
|NMVe based SSD
|recommended
|-
|SATA based SSD
|can be used for moderate traffic, check system load for high system utilization
|-
|USB based SSD
|not recommended, but might be useful for small systems (Allegro 200/500/510)
|-
|HDD
|not recommended, should not be used
|}
It is also not recommended to place the long-term DB on the same storage device that is used a packet ring buffer as it will deteriorate the performance of both features.

The feature can be disabled temporarily and the last snapshot of persisted data is still kept. To remove this data permanently, use the delete buttons at the bottom of the configuration page.

== Limitations ==

# The data in the long-term DB is limited to a selected subset of the data in the In-Memory-DB. See above for an exact list of elements available.
# The data is written into the long-term DB in variable intervals depending on traffic and system load. It takes up to 10 minutes (two graph intervals) until the data appears in the graph. Therefore, the last 5-10 minutes appear empty or with less traffic than in live view.

Capture module

2025-04-09T14:31:25Z

Ralf:

==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 <u>only DNS packets</u> 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.

<i>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</i>

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. The speed of the replay can be chosen below to real-time or specific speed or unlimited speed. The actual achievable speed depends on factors like the speed of the storage device. The maximum speed is typically <= 5 Gbps/400 kpps (also depending on the interface speed).

:* 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.

DB persistence

2025-03-25T08:20:12Z

Ralf:

The DB persistence feature (in firmware >= 4.2) can write parts of the In-Memory database onto an selected storage device when stopping the packet processing (either manually or when rebooting the device). On restart, the stored data is imported again to make some data available again after restart.

The stored data comprises:
[[File:DB persistence settings.png|thumb|DB persistence settings]]
* the list of MAC addresses and their direct graphs, not including the per-element tables.
* the list of IP addresses and their direct graphs (traffic, retransmissions and other TCP stats for that IP address), not including the per-element tables.
* the IP groups data (same elements as the IP addresses).
* the Layer 7 protocol traffic graphs.

The feature must be enabled in the global settings in the "Long-term DB and persistence" tab. The storage device must be selected and should be reasonable fast. We recommend using SSD storage only as it can take a few seconds to a few minutes on such fast disc but much longer on slower spinning discs.

The configuration sections shows the estimated required space on the storage device. Since the amount of data stored depends on the actual number elements (IP addresses etc), it may vary and the process will use less memory if possible or try to use more memory if necessary.

The processing restart dialog will allow to disable dump and/or restoration for one time.

The dialog also shows progress during restart which also to cancel the operation.

The configuration dialog also shows the size of the persisted data and allow to remove it.

=== Additional options ===

* With longterm DB, skip writing live data onto storage device (reduces dump/restore time): Since Firmware version 4.3, the [[Longterm DB]] is also stored on the SSD. To reduce the amount of time needed for dump and restore, the dump of the live data can be disabled since this is usually much more data and it might not be necessary to write this as well.
* Since firmware version 4.5, it is also possible to enable a periodic dump once per day. In case of unexpected loss of power or other restarts, the last dump will be automatically read in on restart. The configuration settings allows to select any full hour of the day. It is recommended to choose an hour with less traffic then usual as the dump process increases the load of the system.

=== Limitations ===

* Data dump and restoration works between the same firmware version and also between different firmware version but due to increasing feature set, importing data from a newer firmware (when downgrading) may not work always. In this case the import will be only partial and normal operation continues.
* Some setting changes will make the import of some data impossible:
** Changing the resolution of graph data is not supported for the DB persistence feature. The import will skip data from written with different settings.
* As with all data on storage devices, the configuration of factory reset will not delete the persisted DB data and it must be removed manually by either selecting the button in the configuration dialog or by formatting the storage device.

Back-in-Time functionality

2025-02-18T15:00:32Z

Ralf:

The Allegro Network Multimeter allows for accessing older data to debug network issues that happen sporadically or are already over.

On the top bar you see either a green '''LIVE''' box or a red '''back-in-time''' box indicate whether live data is shown are (fixed) data from the past.

{|
|
: [[File:time_dropdown_unselected.png|430px|Selecting time span|border]] :[[File:time_dropdown_set.png|500px|Selecting time span|border]]
|}
In the latter mode, the start and end time is shown as well.

You can click into any history graph shown in the web interface to go back to the corresponding time under the mouse pointer.

The time window is also halved on every click to be able to zoom into specific network events.

A lot of data is available for any specific time frame, such as the amount of traffic processed for an IP address.

But not every single data set is available in the '''back-in-time''' view due to memory constraints to store all data.

Also, the resolution of data decreases with new data arriving.

For instance, data for the last minute is always available in one second resolution, while older data might be only available in two second resolution or larger.

Network problems within smaller time spans can still be debugged since absolute counters will still show any network traffic happened between time intervals.

The time constraints applied depend on the context of the data. For instance, IP lists are filtered so that only IPs that had activity before and after the time window.

IPs that are not active during the time window are not shown.

The '''back-in-time''' mode can be exited by clicking on the red '''back-in-time''' box on the top of the web interface. The Allegro Network Multimeter will switch back to the live view.

Note that even in '''back-in-time''' mode, the device still measures every packet going through it so you will not miss any data.

=== Difference Live and Back-In-Time Mode ===
One notable difference between Live and Back-In-Time mode is the presentation of numerical counters. Counters in live mode are always from start of measurement (or last reset), while counters in back-in-time mode a relative counters within the active time interval.

That means that regardless of the zoom level, in live mode the counters are always the shown since start of the measurement, not start of the zoom level interval.
{| class="wikitable"
|+
!
!LIVE
!Back-In-Time
|-
|Traffic counter
|Total counter from start or last reset
Example: "packets" are packets since start
|Relative counters during time interval
Example: "packets" are number of packets in interval
|-
|Graph data
|Traffic data within time interval
|Traffic data within time interval
|-
|Capturing
|Data source is live traffic (no need for ring buffer).
Exception: Manual time range override in capture dialog
|Date source is ring buffer
|}

==== Use cases: ====

# Task: Check the traffic within the last hour of the IP addresses with the most traffic overall. Solution: Choose "1 hour live" display and sort the IP table for bytes. The first IP is the IP with the most bytes overall. The graph contains the activity within the last one hour. Use case: you want to check if multiple backup servers which usually have a lot of traffic had activity within the last hour. Sort for bytes is an easy way to identify those and with live view you can still see the activity within that interval.
# Task: Which IP had the most traffic within the last hour? Solution: Choose "Last hour" display and sort the IP table for bytes. The first IP is the IP with the most bytes within the last one hour.

=== Data not available in back-in-time mode ===
Some data is not available for a specific time period in the back-in-time mode, but only as a total value since the start of the measurement.

The web interface highlights all data that is not available with a Gray background.

This allows to still read the data while still knowing which data is from the time window and which data comes from the latest measurements.

'''<u>Example:</u>'''

The global TCP handshake in the [[TCP module]] reflects the total average in live mode, while it shows the average during the selected time period in back-in-time mode. But the server classification into high/normal/low is only available as a total value for the whole runtime and is there shown in gray.

Longterm DB

2025-02-11T12:20:39Z

Ralf:

==Description==
The Long-term DB feature (in firmware >= 4.3) uses an attached storage devices to store traffic information of IP addresses and Layer 7 protocols with low resolution for a much longer time than the live statistics.

The elements stored in the long-term DB are as follows, graph data is available in 5 minute resolution:

* IP addresses
*# activity time
*# traffic graph in 5 minute resolution
* Layer 7 protocols
*# traffic graph in 5 minute resolution

The storage is used similar to a swap file mechanism so the long-term data is not kept between restart unless the [[DB persistence]] feature is enabled too, which is recommended when using the long-term feature. To reduce the amount of time to dump/restore, the DB persistence configuration allow to skip storing live data.

==Usage==
[[File:Longterm DB dashboard.png|alt=Long-term DB activated dashboard|thumb|Long-term DB activated dashboard]]If this feature is enabled, a view toggle button appears in the top menu bar. This button allows to switch between the real time "RT" view and the long-term ("LT") view.

In the long-term view, the IP address information contain only information about the traffic amount in 5 minute resolution.

The navigation menu in the long-term view only contains those modules which are available in this view.

If the long-term view is activated on module pages which do not support long-term data, a corresponding info box is shown.

==Setting==
The configuration can be found in the global settings page in the "Long-term DB and persistence" tab.

To enable this feature, select a storage device to be used, enable the feature and enter a file size.

It is recommended to also enable the [[DB persistence]] feature to be able to save and restore the long-term DB data during restarts.

Once enabled, the utilization of the file is shown and the [[System Info Page]] contains information about how long the data can be kept.

Tip: Since the amount of information stored in the long-term DB is limited by the graph resolution, the file size usually don't need to be similar sized as the main memory. 10 GByte is a good starting point.

The size can be increase but it requires a restart of the packet processing.

[[File:DB persistence settings.png|thumb|Long-term DB settings]]

== Notes ==
Recommended storage device types:
{| class="wikitable"
|+
!Storage device
!Note
|-
|NMVe based SSD
|recommended
|-
|SATA based SSD
|can be used for moderate traffic, check system load for high system utilization
|-
|USB based SSD
|not recommended, but might be useful for small systems (Allegro 200/500)
|-
|HDD
|not recommended, should not be used
|}
It is also not recommended to place the long-term DB on the same storage device that is used a packet ring buffer as it will deteriorate the performance of both features.

== Limitations ==

# The data in the long-term DB is limited to a selected subset of the data in the In-Memory-DB. See above for an exact list of elements available.
# The data is written into the long-term DB in variable intervals depending on traffic and system load. It takes up to 10 minutes (two graph intervals) until the data appears in the graph. Therefore, the last 5-10 minutes appear empty or with less traffic than in live view.

Longterm DB

2025-02-11T12:19:11Z

Ralf:

==Description==
The Long-term DB feature (in firmware >= 4.3) uses an attached storage devices to store traffic information of IP addresses and Layer 7 protocols with low resolution for a much longer time than the live statistics.

The elements stored in the long-term DB are as follows, graph data is available in 5 minute resolution:

* IP addresses
*# activity time
*# traffic graph in 5 minute resolution
* Layer 7 protocols
*# traffic graph in 5 minute resolution

The storage is used similar to a swap file mechanism so the long-term data is not kept between restart unless the [[DB persistence]] feature is enabled too, which is recommended when using the long-term feature. To reduce the amount of time to dump/restore, the DB persistence configuration allow to skip storing live data.

==Usage==
[[File:Longterm DB dashboard.png|alt=Longterm DB activated dashboard|thumb|Longterm DB activated dashboard]]If this feature is enabled, a view toggle button appears in the top menu bar. This button allows to switch between the real time "RT" view and the long-term ("LT") view.

In the long-term view, the IP address information contain only information about the traffic amount in 5 minute resolution.

The navigation menu in the long-term view only contains those modules which are available in this view.

If the long-term view is activated on module pages which do not support long-term data, a corresponding info box is shown.

==Setting==
The configuration can be found in the global settings page in the "Long-term DB and persistence" tab.

To enable this feature, select a storage device to be used, enable the feature and enter a file size.

It is recommended to also enable the [[DB persistence]] feature to be able to save and restore the long-term DB data during restarts.

Once enabled, the utilization of the file is shown and the [[System Info Page]] contains information about how long the data can be kept.

Tip: Since the amount of information stored in the long-term DB is limited by the graph resolution, the file size usually don't need to be similar sized as the main memory. 10 GByte is a good starting point.

The size can be increase but it requires a restart of the packet processing.

[[File:Longterm db settings.png|thumb|Longterm DB settings]]

== Notes ==
Recommended storage device types:
{| class="wikitable"
|+
!Storage device
!Note
|-
|NMVe based SSD
|recommended
|-
|SATA based SSD
|can be used for moderate traffic, check system load for high system utilization
|-
|USB based SSD
|not recommended, but might be useful for small systems (Allegro 200/500)
|-
|HDD
|not recommended, should not be used
|}
It is also not recommended to place the long-term DB on the same storage device that is used a packet ring buffer as it will deteriorate the performance of both features.

== Limitations ==

# The data in the long-term DB is limited to a selected subset of the data in the In-Memory-DB. See above for an exact list of elements available.
# The data is written into the long-term DB in variable intervals depending on traffic and system load. It takes up to 10 minutes (two graph intervals) until the data appears in the graph. Therefore, the last 5-10 minutes appear empty or with less traffic than in live view.

DB persistence

2025-02-11T12:17:22Z

Ralf:

The DB persistence feature (in firmware >= 4.2) can write parts of the In-Memory database onto an selected storage device when stopping the packet processing (either manually or when rebooting the device). On restart, the stored data is imported again to make some data available again after restart.

The stored data comprises:
[[File:DB persistence settings.png|thumb|DB persistence settings]]
* the list of MAC addresses and their direct graphs, not including the per-element tables.
* the list of IP addresses and their direct graphs (traffic, retransmissions and other TCP stats for that IP address), not including the per-element tables.
* the IP groups data (same elements as the IP addresses).
* the Layer 7 protocol traffic graphs.

The feature must be enabled in the global settings in the "Long-term DB and persistence" tab. The storage device must be selected and should be reasonable fast. We recommend using SSD storage only as it can take a few seconds to a few minutes on such fast disc but much longer on slower spinning discs.

The configuration sections shows the estimated required space on the storage device. Since the amount of data stored depends on the actual number elements (IP addresses etc), it may vary and the process will use less memory if possible or try to use more memory if necessary.

The processing restart dialog will allow to disable dump and/or restoration for one time.

The dialog also shows progress during restart which also to cancel the operation.

The configuration dialog also shows the size of the persisted data and allow to remove it.

=== Additional options ===

* With longterm DB, skip writing live data onto storage device (reduces dump/restore time): Since Firmware version 4.3, the [[Longterm DB]] is also stored on the SSD. To reduce the amount of time needed for dump and restore, the dump of the live data can be disabled since this is usually much more data and it might not be necessary to write this as well.

=== Limitations ===

* Data dump and restoration works between the same firmware version and also between different firmware version but due to increasing feature set, importing data from a newer firmware (when downgrading) may not work always. In this case the import will be only partial and normal operation continues.
* Some setting changes will make the import of some data impossible:
** Changing the resolution of graph data is not supported for the DB persistence feature. The import will skip data from written with different settings.
* As with all data on storage devices, the configuration of factory reset will not delete the persisted DB data and it must be removed manually by either selecting the button in the configuration dialog or by formatting the storage device.

Global settings

2025-02-11T11:59:18Z

Ralf:

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.<br/ >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.<br>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.<br />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.<br />[[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only".<br />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.<br />[[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.<br />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 <u>value shown in the graph</u> might be shown as 10 packets per second as each sample point is scaled to represent an value per second.<br>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 [[DB persistence]] for details about the persistence and [[Longterm DB]] for details about the long-term 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.

DB persistence

2025-02-10T14:32:45Z

Ralf:

The DB persistence feature (in firmware >= 4.2) can write parts of the In-Memory database onto an selected storage device when stopping the packet processing (either manually or when rebooting the device). On restart, the stored data is imported again to make some data available again after restart.

The stored data comprises:
[[File:DB persistence settings.png|thumb|DB persistence settings]]
* the list of MAC addresses and their direct graphs, not including the per-element tables.
* the list of IP addresses and their direct graphs (traffic, retransmissions and other TCP stats for that IP address), not including the per-element tables.
* the IP groups data (same elements as the IP addresses).
* the Layer 7 protocol traffic graphs.

The feature must be enabled in the global settings in the "DB persistence" tab. The storage device must be selected and should be reasonable fast. We recommend using SSD storage only as it can take a few seconds to a few minutes on such fast disc but much longer on slower spinning discs.

The processing restart dialog will allow to disable dump and/or restoration for one time.

The dialog also shows progress during restart which also to cancel the operation.

The configuration dialog also shows the size of the persisted data and allow to remove it.

=== Additional options ===

* With longterm DB, skip writing live data onto storage device (reduces dump/restore time): Since Firmware version 4.3, the [[Longterm DB]] is also stored on the SSD. To reduce the amount of time needed for dump and restore, the dump of the live data can be disabled since this is usually much more data and it might not be necessary to write this as well.

=== Limitations ===

* Data dump and restoration works between the same firmware version and also between different firmware version but due to increasing feature set, importing data from a newer firmware (when downgrading) may not work always. In this case the import will be only partial and normal operation continues.
* Some setting changes will make the import of some data impossible:
** Changing the resolution of graph data is not supported for the DB persistence feature. The import will skip data from written with different settings.
* As with all data on storage devices, the configuration of factory reset will not delete the persisted DB data and it must be removed manually by either selecting the button in the configuration dialog or by formatting the storage device.

Live filtering of tables

2025-01-24T12:39:42Z

Ralf:

== General ==
Multiple measuring statistics show all entries in tables with different columns for all measured values, which can be sorted individually.

Since often there are a lot of entries, the Allegro Network Multimeter allows for filtering those tables to quickly find the relevant information.

All search text areas show a hint about for what kind of information the table can be filtered. Once entered, the table is updated immediately while still updating the measured values for the visible entries.

This live filtering allows for viewing live data only for the entries that are currently important for the investigation of a network problem.

== Single word matching ==
It is always possible the enter a single word for filtering.

In this case the Allegro Network Multimeter will match any possible field for the given text.

For instance, in the IP statistics, the IP will be matched if a number representation is entered, with an optional subnet mask length (1.2.3.4/8).

The known alternative names are also matched, so it is possible to enter a host name and the list will show only those entries which contain the string in the DHCP name, DNS name, HTTP name, or any other name field.

== Complex filter expressions ==
Some tables allow for using more complex expressions for flexible live filtering.

The support of filter expressions is indicated by the hint text in the search area, which informs that the entered string must start with an open parenthesis '''('''.

In this mode it is possible to enter expressions in the form of '''keyword == value'''.

The keyword depends on the actual context of the search field, often '''name''', '''ip''', or '''packets''' is possible.

The web interface will give hints about all possible keywords in the current context which usually directly correlate with the available columns.

Also, the comparison operator can be '''==''' or '''!=''' for equal or unequal compare, but for numbers '''<''', '''>=''', etc can be used too.

Multiple expressions can be combined with boolean operators '''and''' or '''or''' (or equivalent '''&&''' / '''||'''). Also, parentheses can be used to enter even more complex expressions.

== Examples ==

# Show all IPs with at least 100 packets, that have been active within the last minute:
#: <code>(packets > 100 and lasttime < 60)</code>
# Show all IPs that showed up not more than 24 hours ago and have an associated name of alice or bob:
#: <code>( (firsttime < 86400 and ( name == alice or name == bob ))</code>
#: 86400 is the number of seconds in 24 hours (24 * 60 * 60)

== Notes ==

* It is possible to enter values in quotes if they contain reserved characters used for the expressions (<,=,&,(, etc).
* Under the search text area, the interface will show all valid values for the last element entered in the expression.
* A green check mark indicates if the entered expression has been successfully parsed.

== Available keywords ==

The available keywords vary depending on the web interface section.

The web interface will always show the available keywords in the specific context. The following table contains all keywords:

{| class="wikitable sortable"
|-
! Keyword !! Description
|-
|name || any name information (DNS, DHCP, SSL, HTTP, custom names, etc)
|-
|name.dns || DNS name information only for IPs and IP connections
|-
|category ||the category of a custom name
|-
|ip ||the IP address of the client or server side
|-
|ipgroup || the name(s) of the matching IP groups if configured
|-
|clientip || the IP address of the client
|-
|serverip || the IP address of the server
|-
|packets || the number of packets (received and transmitted combined)
|-
|rxpackets || the number of received packets
|-
|txpackets || the number of transmitted packets
|-
|clientpackets || the number of packets sent by the client
|-
|serverpackets || the number of packets sent by the server
|-
|bytes || the number of bytes (received and transmitted combined)
|-
|rxbytes || the number of received bytes
|-
|txbytes || the number of transmitted bytes
|-
|clientbytes || the number of bytes sent by the client
|-
|serverbytes || the number of bytes sent by the server
|-
|pps || the packets per second value
|-
|rxpps||the received packets per second value
|-
|txpps|| the transmitted packets per second value
|-
| bps ||the bits per second value
|-
|rxbps ||the received bits per second value
|-
|txbps||the transmitted bits per second value
|-
|firsttime||the time of the first activity
|-
|lasttime || the time of the last activity
|-
|tcppackets||the number of TCP packets (received and transmitted combined)
|-
|udppackets|| the number of UDP packets (received and transmitted combined)
|-
|tcppayload||the amount of bytes processed as TCP payload
|-
|tcpRetrans||the amount of payload bytes retransmitted
|-
|tcpRetransRx||the amount of received payload bytes retransmitted
|-
|tcpRetransTx||the amount of transmitted payload bytes retransmitted
|-
| tcpRetransClient||the amount of client payload bytes retransmitted
|-
|tcpRetransServer ||the amount of server payload bytes retransmitted
|-
|mac||the MAC address of the client or server
|-
|port||the layer 4 port of the client or server (a number or range)
|-
|clientport||the layer 4 port of the client (a number or range)
|-
|serverport||the layer 4 port of the server (a number or range)
|-
|l4protocol|| the layer 4 protocol name (tcp, udp, icmp, etc)
|-
|l7protocol||the layer 7 protocol name (http, dns, etc)
|-
|tcpend ||the ending reason of a TCP connection (open, fin, rst, timeout)
|-
|tcpstate ||the state of a TCP connection (valid, invalid, unknown)
|-
|tcpclienthandshake||the TCP handshake time in milliseconds for the client (time to answer the server's syn packet)
|-
|tcpserverhandshake||the TCP handshake time in milliseconds for the server (time to answer the client's syn packet)
|-
|tcpdataresponseavg||the average TCP data response time in milliseconds of the connection
|-
|tcpdataresponsemax||the max TCP data response time in milliseconds of the connection (any direction)
|-
|httpresponse ||the HTTP response time for a request
|-
|httpstatus||the HTTP status code of the response
|-
|sslhandshake||the SSL handshake time (time for the server to answer the SSL setup)
|-
|packetratio||the client/server packet ratio as a floating point number
|-
| vlan ||the VLAN tag (a tag or 'none'), both outer and inner VLAN will be considered
|-
|outervlan||the outer VLAN tag (a tag or 'none')
|-
| innervlan||the inner VLAN tag (a tag or 'none')
|-
|interface.name||the interface name or ID (starting at 1)
|-
|interface.rawid
|the raw interface ID (starting at 0)
|-
|validconnections||the number of valid TCP connections
|-
|invalidconnections|| the number of invalid TCP connections
|-
| profinetFrameId||the number of a Profinet frame ID
|-
| minCallerJitter||the minimum jitter of the caller as a floating point number
|-
| avgCallerJitter|| the average jitter of the caller as a floating point number
|-
| maxCallerJitter||the maximum jitter of the caller as a floating point number
|-
| minCalleeJitter|| the minimum jitter of the callee as a floating point number
|-
|avgCalleeJitter ||the average jitter of the callee as a floating point number
|-
|maxCalleeJitter||the maximum jitter of the callee as a floating point number
|-
|minJitter ||the minimum jitter of the caller or callee as a floating point number
|-
| avgJitter || the average jitter of the caller or callee as a floating point number
|-
|maxJitter||the maximum jitter of the caller or callee as a floating point number
|-
|minCallerMos||the minimum MOS of the caller as a floating point number
|-
|avgCallerMos ||the average MOS of the caller as a floating point number
|-
|maxCallerMos||the maximum MOS of the caller as a floating point number
|-
|minCalleeMos ||the minimum MOS of the callee as a floating point number
|-
|avgCalleeMos || the average MOS of the callee as a floating point number
|-
|maxCalleeMos||the maximum MOS of the callee as a floating point number
|-
| minMos||the minimum MOS of the caller or callee as a floating point number
|-
|avgMos||the average MOS of the caller or callee as a floating point number
|-
|maxMos||the maximum MOS of the caller or callee as a floating point number
|-
|minClientJitter ||the minimum jitter of the client as a floating point number
|-
|maxClientJitter ||the maximum jitter of the client as a floating point number
|-
|avgClientJitter ||the average jitter of the client as a floating point number
|-
|minServerJitter ||the minimum jitter of the server as a floating point number
|-
|maxServerJitter||the maximum jitter of the server as a floating point number
|-
|avgServerJitter||the average jitter of the server as a floating point number
|-
|statusCode||the number of a status code
|-
|mpls||the MPLS label (a label or 'none'), both outer and inner MPLS label will be considered
|-
| outermpls||the outer MPLS label (a label or 'none')
|-
|innermpls|| the inner MPLS label (a label or 'none')
|-
|qos||Filter for presence or absence of QoS. May be 'any' or 'none'.
|-
|qosIpDscp||the DSCP value in the IP header
|-
|qosMplsTc|| the traffic class value in the outermost MPLS label stack entry
|-
|qosVlanPcp||the priority code point in the outermost VLAN tag
|-
|usedCipherSuite||the negotiated SSL/TLS cipher suite name
|-
|usedTlsVersion
|the negotiated SSL/TLS version
|-
|pppoeSessionId||the PPPoE session ID (in hexadecimal or decimal representation)
|-
|mtu||the MTU value in bytes
|-
|rxMtu ||the MTU value of the RX direction in bytes
|-
|txMtu||the MTU value of the TX direction in bytes
|-
|clientMtu||the MTU value of the sent direction of the client in bytes
|-
|serverMtu||the MTU value of the sent direction of the server in bytes
|-
|callId|| the string value of a SIP call ID or similar identifier (e.g. P-Palladion-ID)
|-
| dnsresponse|| the DNS response time (for DNS connections)
|-
| dnsstatus||matches DNS response status (either a DNS reply code, e.g, 0 for success, or noanswer for unanswered DNS connections
|-
|dnsname||the requested DNS name
|-
|callerRtpPacketLoss || the amount of lost packets of the RTP flow of the caller
|-
| calleeRtpPacketLoss||the amount of lost packets of the RTP flow of the callee
|-
| rtpPacketLoss || the amount of lost packets of the RTP flow of the caller or callee
|-
| clientRtpPacketLoss ||the amount of lost packets of the RTP flow of the client
|-
|serverRtpPacketLoss||the amount of lost packets of the RTP flow of the server
|-
|callerRtpJitterBufferExceeded || the amount of packets with jitter above configured max jitter buffer threshold (default 50ms) of the RTP flow of the caller
|-
| calleeRtpJitterBufferExceeded||the amount of packets with jitter above configured max jitter buffer threshold (default 50ms) of the RTP flow of the callee
|-
| rtpJitterBufferExceeded || the amount of packets with jitter above configured max jitter buffer threshold (default 50ms) of the RTP flow of the caller or callee
|-
| clientRtpJitterBufferExceeded ||the amount of packets with jitter above configured max jitter buffer threshold (default 50ms) of the RTP flow of the client
|-
|serverRtpJitterBufferExceeded||the amount of packets with jitter above configured max jitter buffer threshold (default 50ms) of the RTP flow of the server
|-
| callerRtpPayloadType||the payload type of the RTP flow of the caller as a string, will match also parts of the name e.g. G.711
|-
|calleeRtpPayloadType|| the payload type of the RTP flow of the callee as a string, will match also parts of the name e.g. G.711
|-
|rtpPayloadType||the payload type of the RTP flow of the caller or callee as a string, will match also parts of the name e.g. G.711
|-
|duration, sipDuration ||the duration of a connection or a SIP call, amount of seconds
|-
|callerDuration|| the duration of a SIP call of the caller, amount of seconds
|-
|calleeDuration||the duration of a SIP call of the callee, amount of seconds
|-
|diffRtpSipDuration||the difference between the duration of a SIP call and its RTP connection, amount of seconds
|-
|sipQos||Filter for presence or absence of QoS in SIP calls. May be 'any' or 'none'.
|-
|sipQosIpDscp||the DSCP value in the IP header of SIP packets
|-
| sipQosMplsTc|| the traffic class value in the outermost MPLS label stack entry of SIP packets
|-
|sipQosVlanPcp||the priority code point in the outermost VLAN tag of SIP packets
|-
|rtpQos||Filter for presence or absence of QoS in RTP streams. May be 'any' or 'none'.
|-
|rtpQosIpDscp ||the DSCP value in the IP header of RTP packets
|-
|rtpQosMplsTc||the traffic class value in the outermost MPLS label stack entry of RTP packets
|-
|rtpQosVlanPcp||the priority code point in the outermost VLAN tag of RTP packets
|-
|tcpZeroWindow || the number of TCP zero window packets
|-
|tcpZeroWindowRx||the number of TCP zero window packets in RX direction
|-
|tcpZeroWindowTx|| the number of TCP zero window packets in TX direction
|-
|tcpZeroWindowClient||the number of TCP zero window packets of the client
|-
|tcpZeroWindowServer ||the number of TCP zero window packets of the server
|-
|tcpWindowSize||the value of the announced TCP window size in bytes
|-
|tcpWindowSizeClient||the value of the announced TCP window size of the client in bytes
|-
|tcpWindowSizeServer|| the value of the announced TCP window size of the server in bytes
|-
|tcpSmallestWindowSize|| the smallest announced TCP window in bytes
|-
|tcpSmallestWindowSizeClient|| the smallest announced TCP window of the client in bytes
|-
|tcpSmallestWindowSizeServer|| the smallest announced TCP window of the server in bytes
|-
|tcpWindowScale
|the value of the announced TCP window scale
|-
|tcpWindowScaleClient
|the value of the announced TCP window scale of the client
|-
|tcpWindowScaleServer
|the value of the announced TCP window scale of the server
|-
| tcpUsedWindowSize||the value of the actual used TCP window in bytes
|-
|tcpUsedWindowSizeClient||the value of the actual used TCP window of the client in bytes
|-
| tcpUsedWindowSizeServer||the value of the actual used TCP window of the server in bytes
|-
|tcpSyn||the number of TCP SYN packets
|-
|tcpSynClient||the number of TCP SYN packets of the client
|-
|tcpSynServer||the number of TCP SYN packets of the server
|-
|tcpSynRx||the number of received TCP SYN packets of an IP
|-
|tcpSynTx||the number of transmitted TCP SYN packets of an IP
|-
|tcpSynAck||the number of TCP SYN-ACK packets
|-
|tcpSynAckClient||the number of TCP SYN-ACK packets of the client
|-
| tcpSynAckServer||the number of TCP SYN-ACK packets of the server
|-
|tcpSynAckRx||the number of received TCP SYN-ACK packets of an IP
|-
|tcpSynAckTx||the number of transmitted TCP SYN-ACK packets of an IP
|-
|tcpRst||the number of TCP RST packets
|-
|tcpRstClient||the number of TCP RST packets of the client
|-
|tcpRstServer ||the number of TCP RST packets of the server
|-
|tcpRstRx||the number of received TCP RST packets of an IP
|-
|tcpRstTx||the number of transmitted TCP RST packets of an IP
|-
|tcpFin || the number of TCP FIN packets
|-
|tcpFinClient||the number of TCP FIN packets of the client
|-
|tcpFinServer||the number of TCP FIN packets of the server
|-
|tcpFinRx||the number of received TCP FIN packets of an IP
|-
|tcpFinTx||the number of transmitted TCP FIN packets of an IP
|-
|tcpDupAck || the number of TCP DUP ACK packets
|-
|tcpDupAckClient||the number of TCP DUP ACK packets of the client
|-
|tcpDupAckServer||the number of TCP DUP ACK packets of the server
|-
|tcpDupAckRx||the number of received TCP DUP ACK packets of an IP
|-
|tcpDupAckTx||the number of transmitted TCP DUP ACK packets of an IP
|-
|tcpMissedData||the estimated amount of TCP bytes to not see
|-
|tcpDataTransferTime
|the data transfer time in milliseconds (TCP applications times)
|-
|tcpFirstDataResponseTime
|first data response time in milliseconds (TCP applications times)
|-
|tcpTotalRequestResponseTransferTime
|total request response transfer time in milliseconds (TCP applications times)
|-
|traceroute||the IP or host name of a traceroute network hop
|-
|tracerouteHostname||the host name of a traceroute network hop
|-
|tracerouteIp||the IP of a traceroute network hop
|-
|tlsAlert||the description of TLS alert messages (see RFC8446 section 6 for a full list)
|-
|tlsAlertLevel||the TLS alert level (can be warning, fatal or unknown)
|-
|supportedTlsVersion
|the announced TLS version
|-
|supportedCipherSuite
| the announced SSL/TLS cipher suite name
|-
|spi||IPSec SPI (security parameter index), a number in hexadecimal or decimal representation
|-
|number||The phone number of the caller or callee of a SIP call. Extracted from 'From', 'To', 'Contact', 'P-Asserted-Identity', or 'P-Preferred-Identity' field or request URI.
|-
|callerNumber||The phone number of the caller of a SIP call. Extracted from 'From' field.
|-
|calleeNumber||The phone number of the callee of a SIP call. Extracted from 'To' field.
|-
|packetTimeDelta min/avg/max || The RTP packet time delta in milliseconds (min, average or max). This is the delta of arrival time between two subsequent packets.
|-
|callerPacketTimeDelta min/avg/max || The RTP packet time delta in milliseconds (min, average or max) of the caller. This is the delta of arrival time between two subsequent packets.
|-
|calleePacketTimeDelta min/avg/max || The RTP packet time delta in milliseconds (min, average or max) of the callee. This is the delta of arrival time between two subsequent packets.
|-
|clientPacketTimeDelta min/avg/max || The RTP packet time delta in milliseconds (min, average or max) of the client. This is the delta of arrival time between two subsequent packets.
|-
|serverPacketTimeDelta min/avg/max || The RTP packet time delta in milliseconds (min, average or max) of the server. This is the delta of arrival time between two subsequent packets.
|-
|serverMaxPacketLossBurst || The longest RTP packet loss in a row of the server.
|-
|clientMaxPacketLossBurst || The longest RTP packet loss in a row of the client.
|-
|callerMaxPacketLossBurst || The longest RTP packet loss in a row of the caller.
|-
|calleeMaxPacketLossBurst || The longest RTP packet loss in a row of the callee.
|-
|maxPacketLossBurst || The longest RTP packet loss in a row of either client/server or caller/callee.
|-
|peerRole || The peer role. Could be either client or server.
|-
|ssrc || The RTP synchronization source value of either client or server. It can also be used in hexadecimal notation.
|-
|clientSsrc || The RTP synchronization source value of the client. It can also be used in hexadecimal notation.
|-
|serverSsrc || The RTP synchronization source value of the server. It can also be used in hexadecimal notation.
|-
|callerSsrc || The RTP synchronization source value of the caller. It can also be used in hexadecimal notation.
|-
|calleeSsrc || The RTP synchronization source value of the callee. It can also be used in hexadecimal notation.
|-
|peers || The amount of peers of an IP address.
|-
|sipCallerIp || The IP address of the SIP caller, usually the sender of SIP Invite packet.
|-
|sipCalleeIp || The IP address of the SIP callee, usually the receiver of SIP Invite packet.
|-
|minTtl || The min value of TTL for IPv4 or hop limit for IPv6.
|-
|maxTtl || The max value of TTL for IPv4 or hop limit for IPv6.
|-
|avgTtl || The avg value of TTL for IPv4 or hop limit for IPv6.
|}
There are some additional keywords to support some limited set of wireshark compatible filter expressions:
{| class="wikitable"
|+
!Keyword
!Description
!Available in firmware version
|-
|ip.addr
|the IPv4 address (either source or destination)
|3.4
|-
| ip.src
| the IPv4 source address
|3.4
|-
|ip.dst
|the IPv4 destination address
|3.4
|-
|ipv6.addr
|the IPv6 address (either source or destination)
| 3.4
|-
|ipv6.src
|the IPv6 source address
|3.4
|-
|ipv6.dst
|the IPv6 destination address
|3.4
|-
|tcp.port
|the source or destination port of a TCP connection
| 3.4
|-
|tcp.srcport
|the source port of a TCP connection
|3.4
|-
|tcp.dstport
|the destination port of a TCP connection
|3.4
|-
|udp.port
|the source or destination port of a UDP connection
|3.4
|-
|udp.srcport
|the source port of a UDP connection
| 3.4
|-
|udp.dstport
|the destination port of a UDP connection
|3.4
|-
|smb.shareName
|the Name of the smb share
|4.1
|-
|smb.connectionEncrypted
|if the connection between a client and a server is encrypted (possible values are: "encrypted" and "unencrypted"
|4.1
|-
|smb.negotiationState
|the negotiation state of a connection
|4.1
|-
|smb.successfulConnects / smb.failedConnects
|number of successful/failed connects to a smb share
|4.1
|-
|smb.successfulDisconnects / smb.failedDisconnects
|number of successful/failed disconnects to a smb share
|4.1
|-
|smb.dialect
|the used dialects of a smb server
|4.1
|-
|smb.dialectReq
|the dialects requested by a client
|4.1
|-
|smb.dialectUsed
|the dialects used by a client
|4.1
|-
|smb.failedOpens / smb.successfulOpens
|the number of successful/failed opens of a file by a client of a file
|4.1
|-
|smb.failedOpens / smb.successfulOpens
|the number of successful/failed opens of a file by a client
|4.1
|-
|smb.failedCloses / smb.successfulCloses
|the number of successful/failed closes of a file by a client
|4.1
|-
|smb.failedDeletes / smb.successfulDeletes
|the number of successful/failed deletes of a file by a client
|4.1
|-
|smb.firstOpen / smb.lastOpen
|time since the first/last open
|4.1
|-
|smb.lastClose
|time since the file got closed the last time
|4.1
|-
|smb.lastDelete
|time since the file got deleted the last time
|4.1
|-
|smb.bytesWritten / smb.bytesRead
|the number of bytes written to/read from the file
|4.1
|-
| icmp.pingLatencyMin
| the ping latency (min) in ms for ICMP ping request/replies tuples of one connection
|4.2
|-
| icmp.pingLatencyAvg
| the ping latency (average) in ms for ICMP ping request/replies tuples of one connection
|4.2
|-
| icmp.pingLatencyMax
| the ping latency (max) in ms for ICMP ping request/replies tuples of one connection
|4.2
|-
| icmp.requests
| the number of ICMP ping requests of one connection
|4.2
|-
| icmp.replies
| the number of ICMP ping replies of one connection
|4.2
|-
| ip.ttl.min / max / avg
| the min / max / avg TTL value of an IPv4
|4.2
|-
| ipv6.hlim.min / max / avg
| the min / max / avg hop limit value of an IPv6
|4.2
|-
| tds.loginack.tdsversion
| the used TDS version as negotiated during the login process
|4.3
|}

== Wireshark filter syntax==
Wireshark uses a filter syntax that is not directly compatible to the filter syntax in the Allegro Network Multimeter as it is more strict regarding the expression and also supports many packet header related fields.

However, Wireshark conversion filters for IPV4, IPV6, TCP, and UDP can be used directly:

*Example: The filter "(ip.addr eq 1.2.3.4 and ip.addr eq 2.3.4.5) and (tcp.port eq 80 and tcp.port eq 1234)" is a valid filter expression. The corresponding native expression is: "ip == 1.2.3.4 and ip == 2.3.4.5 and port == 80 and port == 1234 and l4protocol == TCP" (the last part about the l4protocol can be left out since most of the time there is only one connection matching the port portion).

Capture module

2025-01-24T12:38:13Z

Ralf:

==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 <u>only DNS packets</u> 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.

<i>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</i>

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.

=== 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.

Management interface settings

2024-12-16T07:46:38Z

Ralf:

Access to the web interface of the Allegro Network Multimeter is handled by an out-of-band network connection separately connected to the device via a wired connection or wireless.
This section allows to configure the settings of the wireless and the wired access. The configuration of the [[Management interface settings on console]] is possible, too.

=== Wireless management interface ===

The wireless access can be disabled or enabled, regardless of a connected Wi-Fi device since such a device can be connected later at any time.
The wireless management interface can operate in two modes:

* Manage own network: In this mode (default), the Allegro Network Multimeter will setup its own Access Point so you can connect a laptop or smartphone directly to the device and access the management interface. In this mode, the web interface can be accessed by entering the URL '''https://allegro/''' into a web browser.
* Join existing network: In this mode, the Allegro Network Multimeter will connect to an existing Wi-Fi network. To do so, enter the name (SSID) of the network and the password. The Wi-Fi Access Point or controller should list the IP it has assigned to the Allegro Network Multimeter.

Additionally, two other options are available under Wireless management interface settings:

* Channel: a fixed Wi-Fi channel can be selected so the Access Point only uses this channel instead of automatically choosing the best available channel.
* Disable default gateway: If enabled, the Access Point will not announce to be the default gateway/route for this network. If so, the device can only be accessed by using the IP address 192.168.4.1. If this option is disabled, the name server running on the device will also resolve the name '''allegro/''' to make it easier to access to the device. This option is useful if there is still another active connection which should still be used, such as a mobile connection or the internal company network.

=== LAN management interface ===

For wired connections there are three operation modes:

* Join existing network: in this mode the Allegro Network Multimeter obtains an IP address (DHCP) from the network connected to the management port. The Router or DHCP server in the network should list the Allegro Network Multimeter IP address.
* Manage own network: In this mode, the Allegro Network Multimeter will run a DHCP server on the management port, enabling you to connect another computer via a cable to the system. Be aware that in this mode, the management port should not be connected to the main network, since running multiple DHCP servers will disturb the network. In this mode, the web interface can be accessed by entering the URL '''https://allegro/''' into a web browser.
* Use static IP: It is also possible to configure a fixed IP address for the wired management port. You can enter any IP address for the port. The IP address must end with a slash followed by the subnet size. Example: /24 stands for a subnet mask of 255.255.255.0. Optionally you can enter the IP address of your gateway computer and the IP address of the DNS server. You can leave them empty if you want to directly connect the device to another computer with no Router involved. In this mode, the web interface can be reached by the static IP address you configured.

=== Secondary management interface ===

You can attach a USB Ethernet adapter to any USB port of the Allegro Network Multimeter and use this as an additional management interface. Also, in models with multiple management interfaces, those can be configured as secondary management interfaces, too.

Such a secondary management interface can be operated with a static IP address or in DHCP client mode. In the address input field, enter the IP address followed by a slash and the subnet size. Optionally you can enter the IP address of your gateway computer and the IP address of the DNS server. You can leave them empty if you want to directly connect the device to another computer with no Router involved.

A secondary management interface can be restricted to a specific device by selecting the MAC address from the corresponding drop down menu. By default, any available interface is selected that is not used for data plane measurements.

=== IPMI interface ===
Most Allegro Network Multimeter support an IPMI interface to access a separate Base Management Controller (BMC) ([[IPMI KVM on Allegro series 1000+]]). The IPMI can be configured via a separate web interface of the BMC, but basic IP settings can be applied here too.

By default, the dedicated port is configured to do DHCP to get a dynamic IP address, but it can be reconfigured to use a static IP.

=== Host name ===

By default, the host name is in the format '''allegro-mm-xxxx''' where the last four characters depend on the actual device. Because of this, multiple Allegro Network Multimeters can be used in the same network.
It is however, possible to choose your own host name. Enter a new name and save the changes. If the name field is empty, the default name will be used again following the next reboot.

=== LLDP ===

If enabled, the Allegro Network Multimeter will transmit LLDP (Link Layer Discovery Protocol) information for the management MAC and IP addresses on the management interface.
The LLDP system name will contain the hostname of the Allegro Network Multimeter and the LLDP system description will contain the platform type (e.g. Allegro-200-rev1) and the currently installed Firmware version.

=== Huawei E8372 | E3372 LTE Wingle ===

Allegro Network Multimeter 500 and upwards allow for one Management Interface to be connected via LTE through a Huawei E8372 or E3372 LTE Wingle. This setup allows for a remote management connection through the [https://allegro-packets.com/wiki/Using_the_Allegro_Remote_Service Allegro Remote Service] without a local internet connectivity. In order to do this, connect your USB Wingle to your Computer and follow Huawei's instructions to set up your LTE connection. Afterwards connect the Huawei Wingle to one of the USB ports on your Allegro Network Multimeter and go to '''Settings'''->'''Management Interfaces'''. Activate '''Use optional management interface''' and configure an available IP address (e.g. 192.168.8.2/24), gateway IP (e.g. 192.168.8.1) and name server (e.g. 192.168.8.1).

[[File:Secondary_lan_management.png|900px]]

=== iPerf3 Server Settings ===

The Allegro Network Multimeter Firmware provides an optional iPerf3-Server. iPerf3 helps measuring the maximum achievable bandwidth between a machine and your Allegro Network Multimeter.
It is turned off by default. You are able to start the server and configure the used port. The Management interface is used as interface.

The documentation for iPerf3 and the client-download can be found [[https://iperf.fr/ here]].

If the ip adress of your Allegro Network Multimeter is 10.0.1.1 and the configured port is 5201 you can run iperf3 against your Allegro Network Multimeter with:

iperf3 -c 10.0.1.1 -p 5201

=== Hawkeye/IxChariot Settings ===
The version 4.1 of the Allegro Multimeter Firmware adds an optional Hawkeye/IxChariot endpoint. You are able to enable the client in the management interface settings.

The Hawkeye/IxChariot enables the user to actively measure the network performance between endpoints . A license for the Hawkeye server is required.

=== Proxy Server Settings/Updating behind a proxy ===

A Proxy Server can be used to check for firmware updates. If you are behind a proxy you are able to configure it in the Management Interface Settings. At the moment SOCKSv5-, HTTP- and HTTPS-Proxies are supported.
{| class="wikitable"
|+Proxy URL examples
!scheme
!with port
!with default port
!default port
|-
|http
|<nowiki>http://10.0.0.1:8080/</nowiki>
|<nowiki>http://10.0.0.1/</nowiki>
|80
|-
|https
|<nowiki>https://10.0.0.1:8443/</nowiki>
|<nowiki>https://10.0.0.1/</nowiki>
|443
|-
|socks5
|socks5://10.0.0.1:9999/
|socks5://10.0.0.1/
|1080
|}

Global settings

2024-12-06T12:09:58Z

Ralf:

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.<br/ >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.<br>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.<br />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.<br />[[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]

* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only".<br />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.<br />[[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.<br />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 <u>value shown in the graph</u> might be shown as 10 packets per second as each sample point is scaled to represent an value per second.<br>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.

Memory extension

2024-12-06T12:09:36Z

Ralf:

NOTE: This feature was available in firmware version 3.3 up to 4.2 and was removed in later versions.

Some old statistical data can be stored on an attached flash based storage device to extend the amount of time for historical data. When enabled, the system will automatically swap out old history data onto the flash device making more room in the main memory to increase history data.

This is a BETA feature which is subject to change in future firmware versions. It is only recommended to be used for very fast flash based storage devices and devices with low load.

The configuration dialog allows to check the speed of an active storage device.

*Excellent performance: this result can only be reached on very fast U.2 or PCIe flash devices, such as Intel Optane storage. This class of devices can be used for low to medium traffic load.
*Acceptable performance: this result can be reached by fast U.2 or SATA flash devices. It can be used for low traffic load.
*Low performance: the speed is usually too slow to be used effectively for this feature. In very low traffic load situations it might still be usable.

Spinning hard disc drives are in general not recommended to be used for this feature.

The configuration dialog allows to choose the storage device to use and the size of the memory extension. Larger values does not automatically increase the history time, as only part of the historical data ca be swapped out. As long as the usage is not reaching 100%, there is no need to increase the memory extension.

Recommended size values:

*Use at least 1 GB of memory.
*If possible use 1-2 times the amount of main memory.

Saving the settings will activate the memory extension immediately.

To disable the memory extension, first disable the feature and then restart the packet processing in the administration menu.

Note: The used storage device cannot be deactivated as long as the memory extension is enabled.

Tip: Since only data that is no longer changing can be swapped out onto the storage device, the graph detail settings can be adjusted to make more information available for external memory. The graph resolution reduction can be adjusted to lower values. It will however also make showing graph data slower for larger time periods so the best value depends on the actual amount of data stored and the use case. It is possible to start with a value of 1/1 for the reduction parameter and increase it, if the overall performance is not good enough.

=== Recommended SSD devices ===
We recommend to use sever-grade high speed SSDs with low access times and high I/O ops.
{| class="wikitable"
|+
!Speed
!Model
!Notes
|-
|High
|[https://www.intel.com/content/www/us/en/products/details/memory-storage/data-center-ssds/optane-dc-ssd-series.html Intel Optane SSD DC P5800X series]
|Recommended for low to medium traffic load, statistic output is slower than usual
|-
|Average
|[https://www.micron.com/products/ssd/product-lines/9300 Micron 9300 MAX SSD]
|Use for low traffic load only, statistic output is slower too
|-
|Low
|Other U.2/SATA/USB SSDs
|might be used for low traffic scenarios, access to statistics will be significantly slower as well
|}

Process traffic capture from remote device

2024-09-20T08:54:56Z

Ralf:

== Overview ==
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.

===== Parallel remote packets =====
Starting with version 4.3 there is now the option to run the remote packet processing in parallel to the live analysis just like a parallel PCAP analysis or parallel Packet Ring Buffer analysis. For this to work the PCAP parallel analysis feature must be enabled (see [[PCAP parallel analysis]]).

In the tab ''Parallel remote packets'' the following parameters can be set:

* '''Port number:''' the port on which this parallel remote packet processing should listen for incoming connections
* '''Name:''' a name displayed on the Top User Dashboard when the replay slot is selected (optional)
* '''Description:''' a description displayed on the Top User Dashboard when the replay slot is selected (optional)
* '''Analysis Profile:''' a settings profile to be used for the parallel remote packet processing (see [[Pcap analysis module]])
* '''Replay Slot:''' the replay slot to be used for the parallel remote packet processing

A checkbox ''Use a temporary Packet Ring Buffer for the parallel remote packets analysis'' can be enabled to let the the parallel remote packet analysis use a Packet Ring Buffer on the selected storage device. This Packet Ring Buffer and all its contents will be deleted once the remote packets analysis ends. Selecting this checkbox shows the following additional settings:

* '''Storage device:''' the storage device on which to create the temporary Packet Ring Buffer
* '''Ring buffer size in MB:''' the size of the temporary Packet Ring Buffer in MB

Once the ''Start parallel remote packets'' button is pressed the user interface can be switched between the parallel remote packets analysis and live analysis just like with the parallel PCAP analysis by selecting the respective replay slot. The processing can be stopped in the ''Parallel remote packets'' tab or on the Top user dashboard when the replay slot is selected.

== Receive packets from remote capture device ==

=== Example uses ===

The capturing tool can be downloaded from the '''Remote packets''' page in the '''Generic''' section.
{| class="wikitable"
|-
| [[File:Process traffic capture from remote device.png|600px|none]]
|}

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.

{| class="wikitable"
|-
|[[File:Process traffic capture from remote device1.png|1000px|none]]
|}

=== Additional notes ===

* The tool automatically applies a filter to not capture the connection to the remote Allegro Network Multimeter to avoid running a loop when the remote connection is visible on the captured interface. That means no additional actions need to be made to skip the remote capture connection.
* Not all interface types are supported for capturing. The interface must provide either Ethernet frames or WiFi frames.

===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

==Remote capture via ERSPAN==

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 123 1.2.3.4
In this mode, the [[ERSPAN Installation|endpopint mode for ERSPAN]] must be enabled and configured for the same IP as used in the ap_capture_to_remote command line argument.

Note that the IP address used is NOT the address or name of the management, but the separate IP address that is only valid on the interface for which the endpoint mode is configured.

__FORCETOC__

Main Page

2024-08-28T07:09:39Z

Ralf:

__NOTOC__
{|
|[[Image:Combination mark transparent.png|300px|link=https://www.allegro-packets.com]]      
|-
|'''This is the Allegro Network Multimeter manual. Please visit the website of [https://allegro-packets.com Allegro Packets] for more information about the product.'''
|}

{| class="wikitable" style="color:black; background-color:#ffdda3;"
|Translation: Document language is English, but you can use [https://translate.google.com/translate?u=allegro-packets.com/wiki automatic Google translation] into your language!
|}

<div class="mainpage_row">
<div class="mainpage_box">
=== Installation ===
* [[Generic Allegro Network Multimeter installation|Generic Allegro Network Multimeter installation guides]]
* Additional installation notes for specific devices:
** [[Allegro 200 series]]
* [[Management interface settings|Configure Management IP address]]
* [[IPMI KVM on Allegro series 1000+]]
* [[User Management|Multi users and permissions]]
* [[Firmware update]]
* [[Performing a factory reset or configuration reset]]
</div>
<div class="mainpage_box">

=== Typical Installation Setups ===
* [[In-Line Installation|In-Line Installation Guide]]
* [[Mirror Port, TAP and Packet Broker Installation|Mirror Port, TAP and Packet Broker Installation Guide]]
* [[ERSPAN Installation|ERSPAN Installation Guide]]
* [[VMWare Workstation Player/Pro Installation Guide]]
* [[VMWare ESXI Installation Guide]]
* [[Hyper-V Installation Guide]]
</div>
<div class="mainpage_box">
=== Configuration Guides ===
* [[Ring Buffer Configuration Guide]] <br/> ( Single Storage Device, Multiple Disks,... )
* [[Parallel packet processing|Parallel Packet Processing Configuration Guide]]
* [[Virtual Link Group Configuration Guide]]
* [[Multi-device settings|Multi-Allegro Configuration]]

* [[Performance Optimization Guide]]
</div>
</div>

<div class="mainpage_row">
<div class="mainpage_box">

=== Web Interface / Dashboard Manual ===
* [[Introduction]]
* [[Quickstart]]
* [[Usage]]
* [[Measurement modules]]
* [[Info Menu]]
* [[Settings]]
* [[User Profile Settings]]
* [[FAQ|FAQ - Frequently Asked Questions]]
* [[Error descriptions]]
* [[Feature documentation]]
* [[Reports]]
* [[Speedtest]]
* [[Longterm DB]]
</div>
<div class="mainpage_box">

=== Use Cases ===
* [[Investigate Network Load ]]
* [[Forensic pcap Analysis ]]
* [[Find Profinet problems]]
* [[Network Burst Analysis]]
* [[Burst analysis on a Mirror or Packet Broker input]]
* [[Capturing]]
* [[Analyze connections between remote sites]]
* [[Debugging Skype Traffic|Troubleshooting Microsoft Teams and Skype]]
* [[USB Presenter Capture]]
* [[VoIP monitoring and troubleshooting]]
* [[Generic troubleshooting processes|Generic troubleshooting process]]
* [[Process traffic capture from remote device]]
</div>
<div class="mainpage_box">

=== Data export and third-party tools===
* [[REST API description]]
*[[Statistics Export via POST]]
*[[SNMP]]
*[[NetFlow/IPFIX interface]]
*[[Public limited statistics]]
</div>
</div>

<div class="mainpage_row">
<div class="mainpage_box">

===Remote access===

*[[Using the Allegro Remote Service]]
*[[Self-hosted SSH Proxy]]
</div>
<div class="mainpage_box">
===Settings ===

*[[ Global settings]]
*[[ Module settings]]
* [[ User defined names]]
* [[ Management interface settings]]
*[[ Multi-device settings]]
*[[ Virtual_Link_Group_functionality | Virtual link groups]]
*[[ Administration]]
*[[ Ingress filter]]
* [[ Remote access and export]]
* [[WiFi]]
*[[ User Management]]
*[[ Firmware update]]
*[[ License upload]]
</div>
<div class="mainpage_box">

===Getting support===

*[[Reaching Allegro Packets Support]]
*[[Reporting Bugs]]
</div>
</div>

<div class="mainpage_row">
<div class="mainpage_box">

===Support of third-party hardware===

*[[List of Supported Transceiver Modules]]
*[[Supported Storage Devices for x300/x400/x500 Series]]
</div>
<div class="mainpage_box">

===Additional resources===
*[[Device icons|Pictograms/Icons/Stencils for all Allegro models]]
*[[Supported protocols]]
</div>
</div>

Longterm DB

2024-08-28T07:08:45Z

Ralf:

==Description==
The Longterm DB feature (in firmware >= 4.3) uses an attached storage devices to store traffic information of IP addresses and Layer 7 protocols with low resolution for a much longer time than the live statistics.

The elements stored in the longterm DB are as follows, graph data is available in 5 minute resolution:

* IP addresses
*# activity time
*# traffic graph in 5 minute resolution
* Layer 7 protocols
*# traffic graph in 5 minute resolution

The storage is used similar to a swap file mechanism so the longterm data is not kept between restart unless the [[DB persistence]] feature is enabled too, which is recommended when using the longterm feature. To reduce the amount of time to dump/restore, the DB persistence configuration allow to skip storing live data.

==Usage==
[[File:Longterm DB dashboard.png|alt=Longterm DB activated dashboard|thumb|Longterm DB activated dashboard]]If this feature is enabled, a view toggle button appears in the top menu bar. This button allows to switch between the real time "RT" view and the longterm ("LT") view.

In the longterm view, the IP address information contain only information about the traffic amount in 5 minute resolution.

The navigation menu in the longterm view only contains those modules which are available in this view.

If the longterm view is activated on module pages which do not support longterm data, a corresponding info box is shown.

==Setting==
The configuration can be found in the global settings page in the "Longterm DB" tab.

To enable this feature, select a storage device to be used, enable the feature and enter a file size.

It is recommended to also enable the [[DB persistence]] feature to be able to save and restore the longterm DB data during restarts.

Once enabled, the utilization of the file is shown and the [[System Info Page]] contains information about how long the data can be kept.

Tip: Since the amount of information stored in the longterm DB is limited by the graph resolution, the file size usually don't need to be similar sized as the main memory. 10 GByte is a good starting point.

The size can be increase but it requires a restart of the packet processing.

[[File:Longterm db settings.png|thumb|Longterm DB settings]]

== Notes ==
Recommended storage device types:
{| class="wikitable"
|+
!Storage device
!Note
|-
|NMVe based SSD
|recommended
|-
|SATA based SSD
|can be used for moderate traffic, check system load for high system utilization
|-
|USB based SSD
|not recommended, but might be useful for small systems (Allegro 200/500)
|-
|HDD
|not recommended, should not be used
|}
It is also not recommended to place the longterm DB on the same storage device that is used a packet ring buffer as it will deteriorate the performance of both features.

== Limitations ==

# The data in the longterm DB is limited to a selected subset of the data in the In-Memory-DB. See above for an exact list of elements available.
# The data is written into the longterm DB in variable intervals depending on traffic and system load. It takes up to 10 minutes (two graph intervals) until the data appears in the graph. Therefore, the last 5-10 minutes appear empty or with less traffic than in live view.

Longterm DB

2024-08-16T14:17:18Z

Ralf:

==Description==
The Longterm DB feature (in firmware >= 4.3) uses an attached storage devices to store traffic information of IP addresses with low resolution for a much longer time than the live statistics.

The stored data comprises the IP addresses and their traffic data in graphical representation with 5 minutes resolution.

The storage is used similar to a swap file mechanism so the longterm data is not kept between restart unless the [[DB persistence]] feature is enabled too, which is recommended when using the longterm feature. To reduce the amount of time to dump/restore, the DB persistence configuration allow to skip storing live data.

==Usage==
[[File:Longterm DB dashboard.png|alt=Longterm DB activated dashboard|thumb|Longterm DB activated dashboard]]If this feature is enabled, a view toggle button appears in the top menu bar. This button allows to switch between the real time "RT" view and the longterm ("LT") view.

In the longterm view, the IP address information contain only information about the traffic amount in 5 minute resolution.

The navigation menu in the longterm view only contains those modules which are available in this view.

If the longterm view is activated on module pages which do not support longterm data, a corresponding info box is shown.

==Setting==
The configuration can be found in the global settings page in the "Longterm DB" tab.

To enable this feature, select a storage device to be used, enable the feature and enter a file size.

It is recommended to also enable the [[DB persistence]] feature to be able to save and restore the longterm DB data during restarts.

Once enabled, the utilization of the file is shown and the [[System Info Page]] contains information about how long the data can be kept.

Tip: Since the amount of information stored in the longterm DB is limited by the graph resolution, the file size usually don't need to be similar sized as the main memory. 10 GByte is a good starting point.

The size can be increase but it requires a restart of the packet processing.

[[File:Longterm db settings.png|thumb|Longterm DB settings]]

== Notes ==
Recommended storage device types:
{| class="wikitable"
|+
!Storage device
!Note
|-
|NMVe based SSD
|recommended
|-
|SATA based SSD
|can be used for moderate traffic, check system load for high system utilization
|-
|USB based SSD
|not recommended, but might be useful for small systems (Allegro 200/500)
|-
|HDD
|not recommended, should not be used
|}
It is also not recommended to place the longterm DB on the same storage device that is used a packet ring buffer as it will deteriorate the performance of both features.

== Limitations ==

# The data in the longterm DB comprises the following information:
## IP addresses
### activity time
### traffic graph in 5 minute resolution
# The data is written into the longterm DB in variable intervals depending on traffic and system load. It takes up to 10 minutes (two graph intervals) until the data appears in the graph. Therefore, the last 5-10 minutes appear empty or with less traffic than in live view.

IP module

2024-08-09T13:35:04Z

Ralf:

The IP module operates on layer 3 of the network stack. It stores information about all IPv4 and IPv6 addresses.
For every address, the corresponding network traffic is accounted, the used protocols and their individual traffic.
The communication peers are stored as well as the traffic between both IP addresses. Every connection and its amount of traffic and the protocol can be accessed too.

== Web interface ==

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

=== IP addresses tab ===

The IP addresses tab shows the complete list of all IP addresses seen by the system. The button row allows for select specific information to be shown or hidden so that only the relevant information fit on the screen.
By clicking on '''Counters (combined)''' the table toggles between sent and received bytes and packets displayed in either one column or in separate columns for sorting purposes.
For each address, the table contains the following information:

* IP
:See [[Common table columns#IP|Common table columns - IP]].

* Alternative names
:See [[Common table columns#Alternative names|Common table columns - Alternative names]].
:The name information are also used when filtering the table for some entered string.

* Traceroute
:A traceroute for the IP can be requested or updated using the available button. When traceroute information is available for the IP, brief information about each found network hop (IP, hostname, ping response time) is displayed. Since this list of hops can get very long, the view can be toggled to show all found hops or just the last one by clicking on the traceroute header.

* First (recent) activity
:See [[Common table columns#First (recent) activity|Common table columns - First (recent) activity]].

* Last activity
:See [[Common table columns#Last activity|Common table columns - Last activity]].

* Packets and Bytes
:See [[Common table columns#Packets|Common table columns - Packets]] and [[Common table columns#Bytes|Common table columns - Bytes]].

* Packets/s and Bit/s
:See [[Common table columns#Packets/s|Common table columns - Packets/s]] and [[Common table columns#Bit/s|Common table columns - Bit/s]].

* Peers
: This shows the amount of peers of this IP. This counter is an all time only value and does not consider a selected interval.

* TTL
: This shows the min, max and average TTL value (or hop limit in case of IPv6) of TCP/UDP traffic of an IP address. Non-UDP and non-TCP traffic as well as multicast traffic is ignored as e.g. ICMP packets likely have very high TTL values of 255 at the sender.

* MTU
: The maximum transmission unit (i.e. layer 2 payload) is calculated for both receive and send direction. The maximum values are displayed.

* TCP packets and UDP packets
:This is the number of TCP and UDP packets that have been seen for this IP.

* TCP handshake time and TCP data response time
: The average time for a handshake as a TCP client and/or a TCP server is displayed as well as the average time the IP takes to acknowledge TCP data.

* TCP application time
: The [[TCP application time|TCP application times]] are shown as aggregated values from each connection.

* TCP payload and retransmissions
:These two columns show the number of bytes transmitted as TCP payload and how many bytes have been retransmitted, indicating a bad connection quality.

* Graph
:See [[Common table columns#Graph|Common table columns - Graph]].
:Available data sources are load (bps or packets/s), TCP statistics or connections.

* PCAP
:See [[Common table columns#PCAP|Common table columns - PCAP]]

When multiple pages are available, there will be a control field for switching pages.
The IP search bar allows to enter IP addresses or names to see only those element for which the entered string is part of the IP address or name.
Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for a detailed description about how to use this feature.
The columns can be sorted also, for example to easily spot the IP addresses with the most bytes, or the highest current throughput.

Below the table a CSV download button provides the ability to download the whole table contents in CSV format.
Sorting and filtering are applied as selected for the table but all IPs in the table are exported, not only the currently visible page.

=== Global IP statistics tab ===

The global IP statistics shows global sums about the processed IPv4 and IPv6 traffic and often used layer 4 protocols.
Non-IP packets such as ARP packets are indicated as other traffic and are not covered by this module.
The available information is:
* Layer 3 protocols (IPv4, IPv6 and non-IP traffic, its distribution over time and a history graph)
* Layer 4 protocols (TCP, UDP and traffic for other often used layer 4 protocols, its distribution over time and a history graph)
* Number of IPv4 fragmented packets (distribution over time and a history graph)

For layer 3 and layer 4 protocols, traffic can be downloaded by clicking on the PCAP download button. The captured packets are not stored on the system but they are directly sent over the HTTP connection to your computer.
To stop capture, click on the same button again (which turned to a STOP symbol), or go to the capture traffic page in the generic section and stop the corresponding download.

=== Top IP statistics ===

On this page pie charts are shown with the top 10 sending and receiving IP addresses. By clicking on a pie chart section the related IP detail page is opened.

=== Per IP statistics ===

It is possible to select an IP from the list of IP addresses and get an more detailed view of the information stored about that IP.
The headline of the page includes three buttons.
The first left arrow button navigates back to the complete IP overview.
The second download button allows to download the traffic for the current IP address.
The third button allows for opening this manual section.
Below the buttons there are two graphs for the packets and bytes sent and received by the IP address.
The third section contains six tabs for various information about the selected IP.

==== Overview tab ====

This tab summarizes all the standard information from the main IP view, such as
* the alternative names,
* the packet and bytes counters, and
* the current throughput.

Additionally, the top DPI protocols are printed both in the table as well as a pie chart at the bottom of the page.
The last line in the table shows the MAC addresses seen for this IP address.
There can be multiple MAC addresses for the same IP, for example if the DHCP reuse the IP address after some time.
The last new connection time is the start time of the last connection seen for this IP.
There is also a download button to capture the traffic for the specific IP and MAC address pair.
The final two rows shows all VLAN tags that have been seen for the given IP. An IP address might be visible in multiple VLANs.
If the Allegro Network Multimeter is installed at a mirror port of a switch which also modifies the VLAN tag, it might happen that an IP address is seen without a VLAN tag (none) and a specific VLAN tag.
This setup will decrease the quality of the results as connections use the VLAN information too to distinguish connections.
The measurement results can be improved if the mirror port is reconfigured to only see traffic with VLAN or completely without VLAN tags.
The last row shows the devices interfaces at which the IP has been seen.
The displayed interface always considers the sender side of an IP connection.
This information helps especially in bridge mode to determine at which side of an link the IP address is visible as sender of packets.

==== Layer 3 QoS tab ====

This tab lists all seen IP DSCP values for the current IP.
Several traffic counters are displayed and a history graph of the traffic over time. A PCAP button allows for capturing the specific QoS tagged traffic for that IP.
By clicking on the shown DSCP class name you will be redirected to the '''Connection''' tab with a filter active that only shows connections for that specific DSCP value.

==== Layer 2 QoS tab ====

This tab lists all seen MPLS traffic classes and VLAN priority code points for the current IP.
Several traffic counters are displayed and a history graph of the traffic over time.
A PCAP button allows for capturing the specific QoS tagged traffic for that IP.
By clicking on the shown QoS class name you will be redirected to the '''Connection''' tab with a filter active that only shows connections for that specific QoS.

==== Protocols tab ====

This tab lists the DPI protocols for the current IP. The download button allows to capture the traffic for the IP and protocol pair.

==== Peers tab ====

The Peers tab shows all communication peers the current IP address has talked to. The table contains the [[Common table columns#IP|IP address]] which can be clicked to see the statistics for that IP.
The alternative names are shown, depending on which data is available (DNS name, DHCP name, NIC vendor name).
The packets and bytes columns show the total amount of data transferred between those two IP addresses.
The list of peers can be filtered by entering a string into the text area. Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for details.

==== Layer 4 endpoints ====

The layer 4 endpoint tab shows all peers of the current IP address and the used server port. If the peer is the server, the port of the peer is shown. If the peer is the client, the other port is shown.

The table shows [[Common table columns#IP|IP addresses]] with port number, whether the peer acts as a server or client, alternative names, layer 4 protocol and byte and packet counters. If there were multiple connection between the IP address and the peer with the same port, the counters will show aggregated data.

When clicking on "Peer connections" the connection tab is opened with the filter set to match that particular endpoint.

==== Connections tab ====

The connection tabs lists all connections which involves the current IP. The button rows allow to select which kind of information should be shown.

{| class="wikitable"
|+
!Column
!Description
|-
|Client IP/port
|Client side IP information (see [[Common table columns#IP|Common table columns - IP]])
|-
|Server IP/port
|Server side IP information (see [[Common table columns#IP|Common table columns - IP]])
|-
|Layer 4 protocol
|TCP, UDP, or others
|-
|Go to
|allows to go to the connection details page which shows all information in more detail.
|-
|Start time
|The start time is the time of the first packet for that connection.
|-
|Last activity
|shows the time of the last packet seen so far for the connection
|-
|Duration
|Difference between last activity and start time.
|-
|Packets
|Number of packets
|-
|Bytes
|Number of bytes
|-
|Packets/s
|Packet rate
|-
|Bit/s
|Bit rate
|-
|MTU
|The maximum transmission unit (i.e. layer 2 payload) is calculated for both directions.
|-
|Layer 7 protocol
|shows the detect application layer 7 protocol.
|-
|TCP handshake time
|The time between SYN and ACK.
|-
|TCP response time (max/avg)
|contains response times for TCP data
|-
|TCP application time
|Performance metrics for L7 applications (see [[TCP application time]] for details)
|-
|Layer 7 response time
|contains response times for the maximum HTTP response for HTTP connections, or the SSL response times for SSL connections. The column also contains a score for this connection and this IP, based on the average response times of the server. See HTTP module and SSL module for additional information. When sorting the column and more than one time value is shown in a field, the maximum of all time values of that field is taken into account.
|-
|TCP retransmissions/TCP restransmission %
|shows the number of bytes that have been retransmitted on TCP layer because of packet loss. High percentage indicate connection problems for this communication pair.
|-
|TCP DUP ACKs
|Number of DUP ACK packets
|-
|TCP missed data
|shows the estimated amount of TCP data not seen for this connection. See [[TCP module#Missed data|TCP module]] for details about missed data.
|-
|TCP SYNs/SYN-ACKs/FINs/RSTs
|shows the amount of TCP SYN, SYN-ACK, FIN and RST packets per direction. Up to 255 packets can be accounted, if more were seen, >= 255 will be displayed.
|-
|TCP end termination reason
|Connection end can be regular FIN, RST, or timeout if no termination is seen at all
|-
|TCP MSS
|The TCP maximum segment size may be announced by the peers using a TCP option during connection negotiation. If the option is not announced, default values will be used. The values represents the payload capacity of TCP packets sent by the peer.
|-
|Max announced TCP window size
|shows the size of the biggest TCP receive window announced for each direction of a connection.
|-
|Min announced TCP window size
|shows the size of the smallest TCP receive window announced for each direction of a connection.
|-
|Max TCP bytes in flight
|shows how much of the TCP receive window of the corresponding direction has been used at max during the lifetime of the connection, in other words this is the bytes in flight of the opposite, sending direction.
|-
|Announced TCP window size limit
|The TCP window size limit columns show the maximum possible value that could be used for the TCP receive window size. This is calculated from the announced TCP window scale option for each direction of a connection. The raw window scale (ws) shift count value is displayed in parentheses next to the byte value.
|-
|TCP window limit usage
|show the ratio of the TCP max window size values compared to the TCP window size limit values in percent.
|-
|TCP zero window packets
|Number of TCP zero window packets indicated full receive buffer.
|-
|Client announced TLS versions/Negotiated TLS version, Client announced cipher suites/Negotiated cipher suite
|shows the TLS versions and all supported cipher suites announced by the client during a SSL client hello. In the negotiated columns the currently used TLS version and cipher suite is shown as indicated by the SSL server hello. As the client announced cipher suite list can be quite long, it is possible expand or minimize the list by click on it.
|-
|TLS alert
|
|-
|TLS alert level
|
|-
|Validity
|Connections are counted as valid if the handshake succeeded or at least some data is transferred.
|-
|Meta data
|may contain additional information that could be retrieved depending on the protocol. For instance, for HTTP traffic this column shows the request URL and response code for the last transaction seen in the corresponding connection.
|-
|Outer VLANs
|shows which VLAN tags has been seen for a specific connection.
|-
|Inner VLANs
|shows which inner VLAN tags has been seen for a specific connection in QinQ setups.
|-
|PPPoE session ID
|shows the PPPoE session ID which has been seen for packets of that specific connection. If a PPPoE session ID changes at any time while the connection is active, a 'changed' indication is given. In this case the latter session ID is displayed.
|-
|MPLS labels
|shows all seen MPLS labels for every direction of the connection. The full label stack is shown. A '''no label''' indication is given, if no MPLS labels have been used. If a MPLS label changes at any time while the connection is active, a '''changed''' indication is given. In this case the latter MPLS labels are displayed.
|-
|QoS
|shows all seen QoS service classes for every direction of the connection. IP DSCP, outermost MPLS traffic classes and outermost VLAN priority code points may be detected and displayed. If a QoS class changes at any time while the connection is active, a '''changed''' indication is given. In this case the latter QoS service classes are displayed. TCP RST packets will be ignored, as that packet may be less important and is indicated by a QoS class with lower priority than the previous packets with data.
|-
|Interfaces
|shows at which interface the connection has been established. This is especially helpful in bridge mode to determine at which side of link the connection has been established.
|-
|Two-way latency avg interval
|[[Path measurement#Measurement_statistics|Statistics from the path measurement]]
|-
|Two-way latency min interval
|
|-
|Two-way latency max interval
|
|-
|One-way latency avg interval
|
|-
|One-way latency min interval
|
|-
|One-way latency max interval
|
|-
|Graph
|shows the historical throughput for each connection, it is possible to select the displayed graph from multiple different statistics (see [[Common table columns#Graph|Common table columns - Graph]]). Some may only be available if module options has been enabled, as it will increase the overall memory usage. Some statistics like the path latency is only available, if the path measurement module is active (and the corresponding option to store latencies per connection is enabled)
|-
|PCAP
|allows for capturing the specific connection (see [[Common table columns#PCAP|Common table columns - PCAP]])
|}
The list of connections can be filtered by entering a string into the text area. Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for details.
[[File:IP connection details.png|thumb|600x600px|Connection detail view]]
A detailed connection view can be accessed by clicking on the magnifying glass symbol in the client IP column.

===== CSV download =====

The connection list can also be downloaded as a CSV document by clicking at the CSV download button. The current filter and sort order is used when creating the CSV file.

The CSV file can also be accessed without using the web interface by getting the following URL:

<code>/API/stats/modules/ip/ips/x.x.x.x/connections?csv=true</code>

x.x.x.x must be replaced with the actual IP address. Additional URL parameters can be used to choose a time span, applying filters, etc. See [[REST API description]] for details.

==== Open TCP server ports ====

This tab shows the list of ports for which the IP address has accessed incoming connections.
It shows which service is (usually) behind the port.
Additionally, the first and last connection time is shown as well.
Also, there is button to capture traffic for the current IP and the corresponding port.

==== TCP statistics ====

This web page shows statistics about the response time of TCP connection handshake of all TCP connections of the current IP address. Also, the amount of data retransmitted due to packet loss is shown on the right side of the page. When TCP data has not been seen for TCP connections, the estimated amount is shown as well (see [[TCP module#Missed data|TCP module]] for details).

The graphs below show the historical data for each TCP handshake. The data point is the average handshake time and the vertical line shows the min and max handshake time for that specific time window (depending on the zoom level). Up to two graphs might be visible, one for data when the IP connected other IPs as a client, and another graph for data when the IP has been connected from other IPs as a server.

The TCP application times show info about data packets being transferred between the clients and server.
For each TCP connection, the following key attributes are measured and reported:

* '''Transactions:''' This metric indicates the count of data transaction cycles, allowing you to track the volume of activity over time.
* '''Data Transfer Time:''' This measures the time interval from the first data packet to the last consecutive data packet sent from the same side, giving you a clear picture of the data flow duration.
* '''First Data Response Time:''' This tracks the time between the last data packet sent and the first data packet received from the other peer, marking the conclusion of a transaction cycle
* '''Total Request-Response Time:''' This attribute captures the time interval from the first client data packet to the last server data packet during the entire request-response cycle, offering a comprehensive view of transaction latency.

It’s essential to understand that the values provided by the TCP application times feature are correlated through TCP packets containing data. This analysis is performed without decrypting the packets themselves, relying on observed patterns rather than the actual content of the packets. As such, the reported metrics are considered '''heuristics'''—meaning they offer insights based on empirical data rather than direct measurements of specific transactions. This approach allows for efficient monitoring while maintaining data integrity and privacy.
[[File:IP details application times.png|thumb|327x327px|TCP application time per IP]]
See [[TCP application time]] for more details about these values.

The connection table below shows a subset of the main connection table only for TCP connections for this IP. When sorting the handshake and response time columns and more than one time value is shown in a field, the maximum of all time values of that field is taken into account.

==== HTTP server statistics ====

This tab shows statistics (if available) of all HTTP requests handled by the current IP address.
The statistics contains:

* HTTP server names: All host names are shown that have been used to contact the HTTP server on this IP.
* Sent HTTP responses: This is the total number of requests/responses that have been seen on the network.
* Average response time: This is the average response time in milliseconds for all servers.
* Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
* Minimum response time: This is the smallest response time seen on the network.
* Maximum response time: This is the largest response time seen on the network.

The graph shows the historical data for all responses.
Below the graph, the number of response codes for each main code family is shown together with the last URL requested.

==== SSL server statistics ====

This tab shows statistics (if available) of all SSL requests handled by the current IP address.
The statistics contains:

* SSL server names: All host names are shown that have been used to contact the SSL server on this IP.
* Response time for SSL handshake
** Number of handshake: This is the total number of SSL requests/responses that have been seen for this IP.
** Average response time: This is the average response time in milliseconds.
** Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
** Minimum response time: This is the smallest response time.
** Maximum response time: This is the largest response time.
* Response time for SSL data
** Number of first data responses: This is the total number of initial SSL data requests/responses that have been seen for this IP.
** Average response time: This is the average response time in milliseconds.
** Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
** Minimum response time: This is the smallest response time.
** Maximum response time: This is the largest response time.

The graphs shows the historical data for all handshakes and SSL first data responses

==== SSL/TLS infos ====

This tab shows statistics (if available) of all negotiated SSL/TLS versions and cipher suites used by the current IP address either as server or client.

In case of an SSL/TLS client this tab will also show the supported SSL/TLS versions and cipher suites that have been announced by this client IP address.

==== SIP statistics ====

This tab shows statistics (if available) of all SIP request methods, all SIP response types as well as all SIP request/response pairs sent or received by the current IP address.

==== RTP statistics ====

This tab shows statistics (if available) of all RTP connections which involve the current IP address as either client or server.
A list shows all connections with client and server [[Common table columns#IP|IP addresses]] and ports. The RTP payload type is shown as well as timing informations and counters, jitter, packet time delta, MOS and R values and SSRC (synchronization source) of both client and server.
The min and max audio levels (decibel relative to full scale, dBFS) per direction are shown if G.711 A-Law or μ-Law is used.
For calculation, raw A-Law or μ-Law values are converted to 16 bit PCM values. Those values are then converted to dbFS:

value_dBFS = 20 * log10(abs(pcm_value) / 32768)
Values range from 0 dBFS (loudest) to -96 dBFS (absolute silence).

Graphs per connection show packets and packet loss, jitter, packet time delta, MOS, R value and the max audio level of client and server over time.
A PCAP button allows for PCAP capturing. If a proper codec is used, audio capture buttons for both directions are available allowing downloads in MP3 format.
Following codecs are supported for audio extraction:

* G.711 A-Law and μ-Law
* G.722
* G.729

==== Ping/Traceroute ====

A traceroute to the IP can be started or updated by clicking the Traceroute/Update button. Available traceroute data is shown in a table, containing details of each discovered network hop.
The following hop information may be displayed:

* IP address
* host name
* round trip time (average, minimum, maximum)
* rate of received responses to sent requests
* dropped packets count
* country
* city
* link to watch the location in online map services Google Maps or OpenStreetMaps

A button is available to easily navigate to the traceroute configuration section.

=== IP connection details ===
The connection detail view shows connection information in a single page. The view can be accessed in the list of IP connection (or the global connection list) by clicking on the magnifying glass symbol in the client IP column.

The page shows all data in a tabular format as well all graphs that are available for the connection.

A capture button at the right hand side can be used to capture packets of that connection.

The zoom button select the time range in which the connection was active.

For TCP connections a [[TCP flow chart]] can be calculated by clicking on the corresponding button:
[[File:TCP flow graph start.png|none|thumb|614x614px|Start TCP flow graph analysis]]See also [[IP connection details]].

== Configuration settings ==

By clicking on the gear button on the top right of the IP statistics web page, you can access the configuration section.

* Store connection information for every IP This option is enabled by default.
:When enabled, the IP measurement module stores every connection for each IP.
:This includes historical packet counter so you can see for individual connection at which time the connection transferred which amount of data.
:Connection data will be stored as long as possible regarding the total memory usage.
:Disabling this option will increase the minimum storage time significantly.

* Store layer 7 protocol information for every IP The network protocols and their historical traffic data is stored for each IP if this option is enabled.
:Disabling this option will increase the minimum storage time slightly.

* Track number of new connections for every IP
:When This option is enabled, TCP connections per IP will be tracked.
:Connections are divided into valid and invalid connections for server and client direction and the amount is shown.
:Disabling this option will increase the minimum storage time slightly.

* Store traffic history graph for IP peers
:This option allows enabling or disabling the traffic history graph that is shown per peer in the '''Peers''' tab for an IP.
:Disabling this option will increase the minimum storage time slightly.

* Store RTP performance information per IP and connection
:This option allows enabling or disabling of RTP related statistics that are shown in the '''RTP statistics''' tab for an IP.
:Jitter, packet time delta and MOS calculation in the [[SIP_module|SIP module]] also depends on this switch since it partially shows information stored at the IP address of RTP senders/receivers.
:Disabling this option will reduce the memory utilization and therefor increase the minimum storage time slightly.

* Store QoS information for every IP
:This option enables or disables to storage of Quality of Service information per IP.
:These information require additional memory so if these information are not necessary, memory can be save to increase global data storage time.

* Store SSL/TLS information for every connection
:This option enables or disables to storage of SSL/TLS information per IP. This includes used and announced
:encryption ciphers which can take additional memory per IP connection. If these information are not necessary, memory can be save to increase global data storage time.

* Store detailed TCP statistics for every connection
:This option allows to store detailed TCP statistics per connection, such as TCP retransmissions or TCP response time. The graph type can be selected in the IP connection tab to access these information.

* Maximum number of IP groups
:This option configures how many IP groups can be defined. The minimum (and default) value is 32 IP groups.
:The maximum value is 65535 IP groups. A new configuration value only takes effect after restarting the packet processing in the Administration menu.

* Maximum number of HTTP requests per connection
:This options configures how many HTTP request/response tuples are stored by default. The default is 1.
:On global and IP detail connection page it is possible to download CSV file with either the last or all HTTP request/responses per connection. In the latter case each connection line is duplicated with another HTTP request/response in chronological order.

IP module

2024-08-09T13:34:13Z

Ralf: /* IP addresses tab */

The IP module operates on layer 3 of the network stack. It stores information about all IPv4 and IPv6 addresses.
For every address, the corresponding network traffic is accounted, the used protocols and their individual traffic.
The communication peers are stored as well as the traffic between both IP addresses. Every connection and its amount of traffic and the protocol can be accessed too.

== Web interface ==

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

=== IP addresses tab ===

The IP addresses tab shows the complete list of all IP addresses seen by the system. The button row allows for select specific information to be shown or hidden so that only the relevant information fit on the screen.
By clicking on '''Counters (combined)''' the table toggles between sent and received bytes and packets displayed in either one column or in separate columns for sorting purposes.
For each address, the table contains the following information:

* IP
:See [[Common table columns#IP|Common table columns - IP]].

* Alternative names
:See [[Common table columns#Alternative names|Common table columns - Alternative names]].
:The name information are also used when filtering the table for some entered string.

* Traceroute
:A traceroute for the IP can be requested or updated using the available button. When traceroute information is available for the IP, brief information about each found network hop (IP, hostname, ping response time) is displayed. Since this list of hops can get very long, the view can be toggled to show all found hops or just the last one by clicking on the traceroute header.

* First (recent) activity
:See [[Common table columns#First (recent) activity|Common table columns - First (recent) activity]].

* Last activity
:See [[Common table columns#Last activity|Common table columns - Last activity]].

* Packets and Bytes
:See [[Common table columns#Packets|Common table columns - Packets]] and [[Common table columns#Bytes|Common table columns - Bytes]].

* Packets/s and Bit/s
:See [[Common table columns#Packets/s|Common table columns - Packets/s]] and [[Common table columns#Bit/s|Common table columns - Bit/s]].

* Peers
: This shows the amount of peers of this IP. This counter is an all time only value and does not consider a selected interval.

* TTL
: This shows the min, max and average TTL value (or hop limit in case of IPv6) of TCP/UDP traffic of an IP address. Non-UDP and non-TCP traffic as well as multicast traffic is ignored as e.g. ICMP packets likely have very high TTL values of 255 at the sender.

* MTU
: The maximum transmission unit (i.e. layer 2 payload) is calculated for both receive and send direction. The maximum values are displayed.

* TCP packets and UDP packets
:This is the number of TCP and UDP packets that have been seen for this IP.

* TCP handshake time and TCP data response time
: The average time for a handshake as a TCP client and/or a TCP server is displayed as well as the average time the IP takes to acknowledge TCP data.

* TCP application time
: The TCP application times are shown as aggregated values from each connection.

* TCP payload and retransmissions
:These two columns show the number of bytes transmitted as TCP payload and how many bytes have been retransmitted, indicating a bad connection quality.

* Graph
:See [[Common table columns#Graph|Common table columns - Graph]].
:Available data sources are load (bps or packets/s), TCP statistics or connections.

* PCAP
:See [[Common table columns#PCAP|Common table columns - PCAP]]

When multiple pages are available, there will be a control field for switching pages.
The IP search bar allows to enter IP addresses or names to see only those element for which the entered string is part of the IP address or name.
Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for a detailed description about how to use this feature.
The columns can be sorted also, for example to easily spot the IP addresses with the most bytes, or the highest current throughput.

Below the table a CSV download button provides the ability to download the whole table contents in CSV format.
Sorting and filtering are applied as selected for the table but all IPs in the table are exported, not only the currently visible page.

=== Global IP statistics tab ===

The global IP statistics shows global sums about the processed IPv4 and IPv6 traffic and often used layer 4 protocols.
Non-IP packets such as ARP packets are indicated as other traffic and are not covered by this module.
The available information is:
* Layer 3 protocols (IPv4, IPv6 and non-IP traffic, its distribution over time and a history graph)
* Layer 4 protocols (TCP, UDP and traffic for other often used layer 4 protocols, its distribution over time and a history graph)
* Number of IPv4 fragmented packets (distribution over time and a history graph)

For layer 3 and layer 4 protocols, traffic can be downloaded by clicking on the PCAP download button. The captured packets are not stored on the system but they are directly sent over the HTTP connection to your computer.
To stop capture, click on the same button again (which turned to a STOP symbol), or go to the capture traffic page in the generic section and stop the corresponding download.

=== Top IP statistics ===

On this page pie charts are shown with the top 10 sending and receiving IP addresses. By clicking on a pie chart section the related IP detail page is opened.

=== Per IP statistics ===

It is possible to select an IP from the list of IP addresses and get an more detailed view of the information stored about that IP.
The headline of the page includes three buttons.
The first left arrow button navigates back to the complete IP overview.
The second download button allows to download the traffic for the current IP address.
The third button allows for opening this manual section.
Below the buttons there are two graphs for the packets and bytes sent and received by the IP address.
The third section contains six tabs for various information about the selected IP.

==== Overview tab ====

This tab summarizes all the standard information from the main IP view, such as
* the alternative names,
* the packet and bytes counters, and
* the current throughput.

Additionally, the top DPI protocols are printed both in the table as well as a pie chart at the bottom of the page.
The last line in the table shows the MAC addresses seen for this IP address.
There can be multiple MAC addresses for the same IP, for example if the DHCP reuse the IP address after some time.
The last new connection time is the start time of the last connection seen for this IP.
There is also a download button to capture the traffic for the specific IP and MAC address pair.
The final two rows shows all VLAN tags that have been seen for the given IP. An IP address might be visible in multiple VLANs.
If the Allegro Network Multimeter is installed at a mirror port of a switch which also modifies the VLAN tag, it might happen that an IP address is seen without a VLAN tag (none) and a specific VLAN tag.
This setup will decrease the quality of the results as connections use the VLAN information too to distinguish connections.
The measurement results can be improved if the mirror port is reconfigured to only see traffic with VLAN or completely without VLAN tags.
The last row shows the devices interfaces at which the IP has been seen.
The displayed interface always considers the sender side of an IP connection.
This information helps especially in bridge mode to determine at which side of an link the IP address is visible as sender of packets.

==== Layer 3 QoS tab ====

This tab lists all seen IP DSCP values for the current IP.
Several traffic counters are displayed and a history graph of the traffic over time. A PCAP button allows for capturing the specific QoS tagged traffic for that IP.
By clicking on the shown DSCP class name you will be redirected to the '''Connection''' tab with a filter active that only shows connections for that specific DSCP value.

==== Layer 2 QoS tab ====

This tab lists all seen MPLS traffic classes and VLAN priority code points for the current IP.
Several traffic counters are displayed and a history graph of the traffic over time.
A PCAP button allows for capturing the specific QoS tagged traffic for that IP.
By clicking on the shown QoS class name you will be redirected to the '''Connection''' tab with a filter active that only shows connections for that specific QoS.

==== Protocols tab ====

This tab lists the DPI protocols for the current IP. The download button allows to capture the traffic for the IP and protocol pair.

==== Peers tab ====

The Peers tab shows all communication peers the current IP address has talked to. The table contains the [[Common table columns#IP|IP address]] which can be clicked to see the statistics for that IP.
The alternative names are shown, depending on which data is available (DNS name, DHCP name, NIC vendor name).
The packets and bytes columns show the total amount of data transferred between those two IP addresses.
The list of peers can be filtered by entering a string into the text area. Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for details.

==== Layer 4 endpoints ====

The layer 4 endpoint tab shows all peers of the current IP address and the used server port. If the peer is the server, the port of the peer is shown. If the peer is the client, the other port is shown.

The table shows [[Common table columns#IP|IP addresses]] with port number, whether the peer acts as a server or client, alternative names, layer 4 protocol and byte and packet counters. If there were multiple connection between the IP address and the peer with the same port, the counters will show aggregated data.

When clicking on "Peer connections" the connection tab is opened with the filter set to match that particular endpoint.

==== Connections tab ====

The connection tabs lists all connections which involves the current IP. The button rows allow to select which kind of information should be shown.

{| class="wikitable"
|+
!Column
!Description
|-
|Client IP/port
|Client side IP information (see [[Common table columns#IP|Common table columns - IP]])
|-
|Server IP/port
|Server side IP information (see [[Common table columns#IP|Common table columns - IP]])
|-
|Layer 4 protocol
|TCP, UDP, or others
|-
|Go to
|allows to go to the connection details page which shows all information in more detail.
|-
|Start time
|The start time is the time of the first packet for that connection.
|-
|Last activity
|shows the time of the last packet seen so far for the connection
|-
|Duration
|Difference between last activity and start time.
|-
|Packets
|Number of packets
|-
|Bytes
|Number of bytes
|-
|Packets/s
|Packet rate
|-
|Bit/s
|Bit rate
|-
|MTU
|The maximum transmission unit (i.e. layer 2 payload) is calculated for both directions.
|-
|Layer 7 protocol
|shows the detect application layer 7 protocol.
|-
|TCP handshake time
|The time between SYN and ACK.
|-
|TCP response time (max/avg)
|contains response times for TCP data
|-
|TCP application time
|Performance metrics for L7 applications (see [[TCP application time]] for details)
|-
|Layer 7 response time
|contains response times for the maximum HTTP response for HTTP connections, or the SSL response times for SSL connections. The column also contains a score for this connection and this IP, based on the average response times of the server. See HTTP module and SSL module for additional information. When sorting the column and more than one time value is shown in a field, the maximum of all time values of that field is taken into account.
|-
|TCP retransmissions/TCP restransmission %
|shows the number of bytes that have been retransmitted on TCP layer because of packet loss. High percentage indicate connection problems for this communication pair.
|-
|TCP DUP ACKs
|Number of DUP ACK packets
|-
|TCP missed data
|shows the estimated amount of TCP data not seen for this connection. See [[TCP module#Missed data|TCP module]] for details about missed data.
|-
|TCP SYNs/SYN-ACKs/FINs/RSTs
|shows the amount of TCP SYN, SYN-ACK, FIN and RST packets per direction. Up to 255 packets can be accounted, if more were seen, >= 255 will be displayed.
|-
|TCP end termination reason
|Connection end can be regular FIN, RST, or timeout if no termination is seen at all
|-
|TCP MSS
|The TCP maximum segment size may be announced by the peers using a TCP option during connection negotiation. If the option is not announced, default values will be used. The values represents the payload capacity of TCP packets sent by the peer.
|-
|Max announced TCP window size
|shows the size of the biggest TCP receive window announced for each direction of a connection.
|-
|Min announced TCP window size
|shows the size of the smallest TCP receive window announced for each direction of a connection.
|-
|Max TCP bytes in flight
|shows how much of the TCP receive window of the corresponding direction has been used at max during the lifetime of the connection, in other words this is the bytes in flight of the opposite, sending direction.
|-
|Announced TCP window size limit
|The TCP window size limit columns show the maximum possible value that could be used for the TCP receive window size. This is calculated from the announced TCP window scale option for each direction of a connection. The raw window scale (ws) shift count value is displayed in parentheses next to the byte value.
|-
|TCP window limit usage
|show the ratio of the TCP max window size values compared to the TCP window size limit values in percent.
|-
|TCP zero window packets
|Number of TCP zero window packets indicated full receive buffer.
|-
|Client announced TLS versions/Negotiated TLS version, Client announced cipher suites/Negotiated cipher suite
|shows the TLS versions and all supported cipher suites announced by the client during a SSL client hello. In the negotiated columns the currently used TLS version and cipher suite is shown as indicated by the SSL server hello. As the client announced cipher suite list can be quite long, it is possible expand or minimize the list by click on it.
|-
|TLS alert
|
|-
|TLS alert level
|
|-
|Validity
|Connections are counted as valid if the handshake succeeded or at least some data is transferred.
|-
|Meta data
|may contain additional information that could be retrieved depending on the protocol. For instance, for HTTP traffic this column shows the request URL and response code for the last transaction seen in the corresponding connection.
|-
|Outer VLANs
|shows which VLAN tags has been seen for a specific connection.
|-
|Inner VLANs
|shows which inner VLAN tags has been seen for a specific connection in QinQ setups.
|-
|PPPoE session ID
|shows the PPPoE session ID which has been seen for packets of that specific connection. If a PPPoE session ID changes at any time while the connection is active, a 'changed' indication is given. In this case the latter session ID is displayed.
|-
|MPLS labels
|shows all seen MPLS labels for every direction of the connection. The full label stack is shown. A '''no label''' indication is given, if no MPLS labels have been used. If a MPLS label changes at any time while the connection is active, a '''changed''' indication is given. In this case the latter MPLS labels are displayed.
|-
|QoS
|shows all seen QoS service classes for every direction of the connection. IP DSCP, outermost MPLS traffic classes and outermost VLAN priority code points may be detected and displayed. If a QoS class changes at any time while the connection is active, a '''changed''' indication is given. In this case the latter QoS service classes are displayed. TCP RST packets will be ignored, as that packet may be less important and is indicated by a QoS class with lower priority than the previous packets with data.
|-
|Interfaces
|shows at which interface the connection has been established. This is especially helpful in bridge mode to determine at which side of link the connection has been established.
|-
|Two-way latency avg interval
|[[Path measurement#Measurement_statistics|Statistics from the path measurement]]
|-
|Two-way latency min interval
|
|-
|Two-way latency max interval
|
|-
|One-way latency avg interval
|
|-
|One-way latency min interval
|
|-
|One-way latency max interval
|
|-
|Graph
|shows the historical throughput for each connection, it is possible to select the displayed graph from multiple different statistics (see [[Common table columns#Graph|Common table columns - Graph]]). Some may only be available if module options has been enabled, as it will increase the overall memory usage. Some statistics like the path latency is only available, if the path measurement module is active (and the corresponding option to store latencies per connection is enabled)
|-
|PCAP
|allows for capturing the specific connection (see [[Common table columns#PCAP|Common table columns - PCAP]])
|}
The list of connections can be filtered by entering a string into the text area. Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for details.
[[File:IP connection details.png|thumb|600x600px|Connection detail view]]
A detailed connection view can be accessed by clicking on the magnifying glass symbol in the client IP column.

===== CSV download =====

The connection list can also be downloaded as a CSV document by clicking at the CSV download button. The current filter and sort order is used when creating the CSV file.

The CSV file can also be accessed without using the web interface by getting the following URL:

<code>/API/stats/modules/ip/ips/x.x.x.x/connections?csv=true</code>

x.x.x.x must be replaced with the actual IP address. Additional URL parameters can be used to choose a time span, applying filters, etc. See [[REST API description]] for details.

==== Open TCP server ports ====

This tab shows the list of ports for which the IP address has accessed incoming connections.
It shows which service is (usually) behind the port.
Additionally, the first and last connection time is shown as well.
Also, there is button to capture traffic for the current IP and the corresponding port.

==== TCP statistics ====

This web page shows statistics about the response time of TCP connection handshake of all TCP connections of the current IP address. Also, the amount of data retransmitted due to packet loss is shown on the right side of the page. When TCP data has not been seen for TCP connections, the estimated amount is shown as well (see [[TCP module#Missed data|TCP module]] for details).

The graphs below show the historical data for each TCP handshake. The data point is the average handshake time and the vertical line shows the min and max handshake time for that specific time window (depending on the zoom level). Up to two graphs might be visible, one for data when the IP connected other IPs as a client, and another graph for data when the IP has been connected from other IPs as a server.

The TCP application times show info about data packets being transferred between the clients and server.
For each TCP connection, the following key attributes are measured and reported:

* '''Transactions:''' This metric indicates the count of data transaction cycles, allowing you to track the volume of activity over time.
* '''Data Transfer Time:''' This measures the time interval from the first data packet to the last consecutive data packet sent from the same side, giving you a clear picture of the data flow duration.
* '''First Data Response Time:''' This tracks the time between the last data packet sent and the first data packet received from the other peer, marking the conclusion of a transaction cycle
* '''Total Request-Response Time:''' This attribute captures the time interval from the first client data packet to the last server data packet during the entire request-response cycle, offering a comprehensive view of transaction latency.

It’s essential to understand that the values provided by the TCP application times feature are correlated through TCP packets containing data. This analysis is performed without decrypting the packets themselves, relying on observed patterns rather than the actual content of the packets. As such, the reported metrics are considered '''heuristics'''—meaning they offer insights based on empirical data rather than direct measurements of specific transactions. This approach allows for efficient monitoring while maintaining data integrity and privacy.
[[File:IP details application times.png|thumb|327x327px|TCP application time per IP]]
See [[TCP application time]] for more details about these values.

The connection table below shows a subset of the main connection table only for TCP connections for this IP. When sorting the handshake and response time columns and more than one time value is shown in a field, the maximum of all time values of that field is taken into account.

==== HTTP server statistics ====

This tab shows statistics (if available) of all HTTP requests handled by the current IP address.
The statistics contains:

* HTTP server names: All host names are shown that have been used to contact the HTTP server on this IP.
* Sent HTTP responses: This is the total number of requests/responses that have been seen on the network.
* Average response time: This is the average response time in milliseconds for all servers.
* Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
* Minimum response time: This is the smallest response time seen on the network.
* Maximum response time: This is the largest response time seen on the network.

The graph shows the historical data for all responses.
Below the graph, the number of response codes for each main code family is shown together with the last URL requested.

==== SSL server statistics ====

This tab shows statistics (if available) of all SSL requests handled by the current IP address.
The statistics contains:

* SSL server names: All host names are shown that have been used to contact the SSL server on this IP.
* Response time for SSL handshake
** Number of handshake: This is the total number of SSL requests/responses that have been seen for this IP.
** Average response time: This is the average response time in milliseconds.
** Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
** Minimum response time: This is the smallest response time.
** Maximum response time: This is the largest response time.
* Response time for SSL data
** Number of first data responses: This is the total number of initial SSL data requests/responses that have been seen for this IP.
** Average response time: This is the average response time in milliseconds.
** Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
** Minimum response time: This is the smallest response time.
** Maximum response time: This is the largest response time.

The graphs shows the historical data for all handshakes and SSL first data responses

==== SSL/TLS infos ====

This tab shows statistics (if available) of all negotiated SSL/TLS versions and cipher suites used by the current IP address either as server or client.

In case of an SSL/TLS client this tab will also show the supported SSL/TLS versions and cipher suites that have been announced by this client IP address.

==== SIP statistics ====

This tab shows statistics (if available) of all SIP request methods, all SIP response types as well as all SIP request/response pairs sent or received by the current IP address.

==== RTP statistics ====

This tab shows statistics (if available) of all RTP connections which involve the current IP address as either client or server.
A list shows all connections with client and server [[Common table columns#IP|IP addresses]] and ports. The RTP payload type is shown as well as timing informations and counters, jitter, packet time delta, MOS and R values and SSRC (synchronization source) of both client and server.
The min and max audio levels (decibel relative to full scale, dBFS) per direction are shown if G.711 A-Law or μ-Law is used.
For calculation, raw A-Law or μ-Law values are converted to 16 bit PCM values. Those values are then converted to dbFS:

value_dBFS = 20 * log10(abs(pcm_value) / 32768)
Values range from 0 dBFS (loudest) to -96 dBFS (absolute silence).

Graphs per connection show packets and packet loss, jitter, packet time delta, MOS, R value and the max audio level of client and server over time.
A PCAP button allows for PCAP capturing. If a proper codec is used, audio capture buttons for both directions are available allowing downloads in MP3 format.
Following codecs are supported for audio extraction:

* G.711 A-Law and μ-Law
* G.722
* G.729

==== Ping/Traceroute ====

A traceroute to the IP can be started or updated by clicking the Traceroute/Update button. Available traceroute data is shown in a table, containing details of each discovered network hop.
The following hop information may be displayed:

* IP address
* host name
* round trip time (average, minimum, maximum)
* rate of received responses to sent requests
* dropped packets count
* country
* city
* link to watch the location in online map services Google Maps or OpenStreetMaps

A button is available to easily navigate to the traceroute configuration section.

=== IP connection details ===
The connection detail view shows connection information in a single page. The view can be accessed in the list of IP connection (or the global connection list) by clicking on the magnifying glass symbol in the client IP column.

The page shows all data in a tabular format as well all graphs that are available for the connection.

A capture button at the right hand side can be used to capture packets of that connection.

The zoom button select the time range in which the connection was active.

For TCP connections a [[TCP flow chart]] can be calculated by clicking on the corresponding button:
[[File:TCP flow graph start.png|none|thumb|614x614px|Start TCP flow graph analysis]]See also [[IP connection details]].

== Configuration settings ==

By clicking on the gear button on the top right of the IP statistics web page, you can access the configuration section.

* Store connection information for every IP This option is enabled by default.
:When enabled, the IP measurement module stores every connection for each IP.
:This includes historical packet counter so you can see for individual connection at which time the connection transferred which amount of data.
:Connection data will be stored as long as possible regarding the total memory usage.
:Disabling this option will increase the minimum storage time significantly.

* Store layer 7 protocol information for every IP The network protocols and their historical traffic data is stored for each IP if this option is enabled.
:Disabling this option will increase the minimum storage time slightly.

* Track number of new connections for every IP
:When This option is enabled, TCP connections per IP will be tracked.
:Connections are divided into valid and invalid connections for server and client direction and the amount is shown.
:Disabling this option will increase the minimum storage time slightly.

* Store traffic history graph for IP peers
:This option allows enabling or disabling the traffic history graph that is shown per peer in the '''Peers''' tab for an IP.
:Disabling this option will increase the minimum storage time slightly.

* Store RTP performance information per IP and connection
:This option allows enabling or disabling of RTP related statistics that are shown in the '''RTP statistics''' tab for an IP.
:Jitter, packet time delta and MOS calculation in the [[SIP_module|SIP module]] also depends on this switch since it partially shows information stored at the IP address of RTP senders/receivers.
:Disabling this option will reduce the memory utilization and therefor increase the minimum storage time slightly.

* Store QoS information for every IP
:This option enables or disables to storage of Quality of Service information per IP.
:These information require additional memory so if these information are not necessary, memory can be save to increase global data storage time.

* Store SSL/TLS information for every connection
:This option enables or disables to storage of SSL/TLS information per IP. This includes used and announced
:encryption ciphers which can take additional memory per IP connection. If these information are not necessary, memory can be save to increase global data storage time.

* Store detailed TCP statistics for every connection
:This option allows to store detailed TCP statistics per connection, such as TCP retransmissions or TCP response time. The graph type can be selected in the IP connection tab to access these information.

* Maximum number of IP groups
:This option configures how many IP groups can be defined. The minimum (and default) value is 32 IP groups.
:The maximum value is 65535 IP groups. A new configuration value only takes effect after restarting the packet processing in the Administration menu.

* Maximum number of HTTP requests per connection
:This options configures how many HTTP request/response tuples are stored by default. The default is 1.
:On global and IP detail connection page it is possible to download CSV file with either the last or all HTTP request/responses per connection. In the latter case each connection line is duplicated with another HTTP request/response in chronological order.

IP module

2024-08-09T13:33:05Z

Ralf: /* TCP statistics */

The IP module operates on layer 3 of the network stack. It stores information about all IPv4 and IPv6 addresses.
For every address, the corresponding network traffic is accounted, the used protocols and their individual traffic.
The communication peers are stored as well as the traffic between both IP addresses. Every connection and its amount of traffic and the protocol can be accessed too.

== Web interface ==

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

=== IP addresses tab ===

The IP addresses tab shows the complete list of all IP addresses seen by the system. The button row allows for select specific information to be shown or hidden so that only the relevant information fit on the screen.
By clicking on '''Counters (combined)''' the table toggles between sent and received bytes and packets displayed in either one column or in separate columns for sorting purposes.
For each address, the table contains the following information:

* IP
:See [[Common table columns#IP|Common table columns - IP]].

* Alternative names
:See [[Common table columns#Alternative names|Common table columns - Alternative names]].
:The name information are also used when filtering the table for some entered string.

* Traceroute
:A traceroute for the IP can be requested or updated using the available button. When traceroute information is available for the IP, brief information about each found network hop (IP, hostname, ping response time) is displayed. Since this list of hops can get very long, the view can be toggled to show all found hops or just the last one by clicking on the traceroute header.

* First (recent) activity
:See [[Common table columns#First (recent) activity|Common table columns - First (recent) activity]].

* Last activity
:See [[Common table columns#Last activity|Common table columns - Last activity]].

* Packets and Bytes
:See [[Common table columns#Packets|Common table columns - Packets]] and [[Common table columns#Bytes|Common table columns - Bytes]].

* Packets/s and Bit/s
:See [[Common table columns#Packets/s|Common table columns - Packets/s]] and [[Common table columns#Bit/s|Common table columns - Bit/s]].

* Peers
: This shows the amount of peers of this IP. This counter is an all time only value and does not consider a selected interval.

* TTL
: This shows the min, max and average TTL value (or hop limit in case of IPv6) of TCP/UDP traffic of an IP address. Non-UDP and non-TCP traffic as well as multicast traffic is ignored as e.g. ICMP packets likely have very high TTL values of 255 at the sender.

* MTU
: The maximum transmission unit (i.e. layer 2 payload) is calculated for both receive and send direction. The maximum values are displayed.

* TCP packets and UDP packets
:This is the number of TCP and UDP packets that have been seen for this IP.

* TCP handshake time and TCP data response time
: The average time for a handshake as a TCP client and/or a TCP server is displayed as well as the average time the IP takes to acknowledge TCP data.

* TCP payload and retransmissions
:These two columns show the number of bytes transmitted as TCP payload and how many bytes have been retransmitted, indicating a bad connection quality.

* Graph
:See [[Common table columns#Graph|Common table columns - Graph]].
:Available data sources are load (bps or packets/s), TCP statistics or connections.

* PCAP
:See [[Common table columns#PCAP|Common table columns - PCAP]]

When multiple pages are available, there will be a control field for switching pages.
The IP search bar allows to enter IP addresses or names to see only those element for which the entered string is part of the IP address or name.
Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for a detailed description about how to use this feature.
The columns can be sorted also, for example to easily spot the IP addresses with the most bytes, or the highest current throughput.

Below the table a CSV download button provides the ability to download the whole table contents in CSV format.
Sorting and filtering are applied as selected for the table but all IPs in the table are exported, not only the currently visible page.

=== Global IP statistics tab ===

The global IP statistics shows global sums about the processed IPv4 and IPv6 traffic and often used layer 4 protocols.
Non-IP packets such as ARP packets are indicated as other traffic and are not covered by this module.
The available information is:
* Layer 3 protocols (IPv4, IPv6 and non-IP traffic, its distribution over time and a history graph)
* Layer 4 protocols (TCP, UDP and traffic for other often used layer 4 protocols, its distribution over time and a history graph)
* Number of IPv4 fragmented packets (distribution over time and a history graph)

For layer 3 and layer 4 protocols, traffic can be downloaded by clicking on the PCAP download button. The captured packets are not stored on the system but they are directly sent over the HTTP connection to your computer.
To stop capture, click on the same button again (which turned to a STOP symbol), or go to the capture traffic page in the generic section and stop the corresponding download.

=== Top IP statistics ===

On this page pie charts are shown with the top 10 sending and receiving IP addresses. By clicking on a pie chart section the related IP detail page is opened.

=== Per IP statistics ===

It is possible to select an IP from the list of IP addresses and get an more detailed view of the information stored about that IP.
The headline of the page includes three buttons.
The first left arrow button navigates back to the complete IP overview.
The second download button allows to download the traffic for the current IP address.
The third button allows for opening this manual section.
Below the buttons there are two graphs for the packets and bytes sent and received by the IP address.
The third section contains six tabs for various information about the selected IP.

==== Overview tab ====

This tab summarizes all the standard information from the main IP view, such as
* the alternative names,
* the packet and bytes counters, and
* the current throughput.

Additionally, the top DPI protocols are printed both in the table as well as a pie chart at the bottom of the page.
The last line in the table shows the MAC addresses seen for this IP address.
There can be multiple MAC addresses for the same IP, for example if the DHCP reuse the IP address after some time.
The last new connection time is the start time of the last connection seen for this IP.
There is also a download button to capture the traffic for the specific IP and MAC address pair.
The final two rows shows all VLAN tags that have been seen for the given IP. An IP address might be visible in multiple VLANs.
If the Allegro Network Multimeter is installed at a mirror port of a switch which also modifies the VLAN tag, it might happen that an IP address is seen without a VLAN tag (none) and a specific VLAN tag.
This setup will decrease the quality of the results as connections use the VLAN information too to distinguish connections.
The measurement results can be improved if the mirror port is reconfigured to only see traffic with VLAN or completely without VLAN tags.
The last row shows the devices interfaces at which the IP has been seen.
The displayed interface always considers the sender side of an IP connection.
This information helps especially in bridge mode to determine at which side of an link the IP address is visible as sender of packets.

==== Layer 3 QoS tab ====

This tab lists all seen IP DSCP values for the current IP.
Several traffic counters are displayed and a history graph of the traffic over time. A PCAP button allows for capturing the specific QoS tagged traffic for that IP.
By clicking on the shown DSCP class name you will be redirected to the '''Connection''' tab with a filter active that only shows connections for that specific DSCP value.

==== Layer 2 QoS tab ====

This tab lists all seen MPLS traffic classes and VLAN priority code points for the current IP.
Several traffic counters are displayed and a history graph of the traffic over time.
A PCAP button allows for capturing the specific QoS tagged traffic for that IP.
By clicking on the shown QoS class name you will be redirected to the '''Connection''' tab with a filter active that only shows connections for that specific QoS.

==== Protocols tab ====

This tab lists the DPI protocols for the current IP. The download button allows to capture the traffic for the IP and protocol pair.

==== Peers tab ====

The Peers tab shows all communication peers the current IP address has talked to. The table contains the [[Common table columns#IP|IP address]] which can be clicked to see the statistics for that IP.
The alternative names are shown, depending on which data is available (DNS name, DHCP name, NIC vendor name).
The packets and bytes columns show the total amount of data transferred between those two IP addresses.
The list of peers can be filtered by entering a string into the text area. Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for details.

==== Layer 4 endpoints ====

The layer 4 endpoint tab shows all peers of the current IP address and the used server port. If the peer is the server, the port of the peer is shown. If the peer is the client, the other port is shown.

The table shows [[Common table columns#IP|IP addresses]] with port number, whether the peer acts as a server or client, alternative names, layer 4 protocol and byte and packet counters. If there were multiple connection between the IP address and the peer with the same port, the counters will show aggregated data.

When clicking on "Peer connections" the connection tab is opened with the filter set to match that particular endpoint.

==== Connections tab ====

The connection tabs lists all connections which involves the current IP. The button rows allow to select which kind of information should be shown.

{| class="wikitable"
|+
!Column
!Description
|-
|Client IP/port
|Client side IP information (see [[Common table columns#IP|Common table columns - IP]])
|-
|Server IP/port
|Server side IP information (see [[Common table columns#IP|Common table columns - IP]])
|-
|Layer 4 protocol
|TCP, UDP, or others
|-
|Go to
|allows to go to the connection details page which shows all information in more detail.
|-
|Start time
|The start time is the time of the first packet for that connection.
|-
|Last activity
|shows the time of the last packet seen so far for the connection
|-
|Duration
|Difference between last activity and start time.
|-
|Packets
|Number of packets
|-
|Bytes
|Number of bytes
|-
|Packets/s
|Packet rate
|-
|Bit/s
|Bit rate
|-
|MTU
|The maximum transmission unit (i.e. layer 2 payload) is calculated for both directions.
|-
|Layer 7 protocol
|shows the detect application layer 7 protocol.
|-
|TCP handshake time
|The time between SYN and ACK.
|-
|TCP response time (max/avg)
|contains response times for TCP data
|-
|TCP application time
|Performance metrics for L7 applications (see [[TCP application time]] for details)
|-
|Layer 7 response time
|contains response times for the maximum HTTP response for HTTP connections, or the SSL response times for SSL connections. The column also contains a score for this connection and this IP, based on the average response times of the server. See HTTP module and SSL module for additional information. When sorting the column and more than one time value is shown in a field, the maximum of all time values of that field is taken into account.
|-
|TCP retransmissions/TCP restransmission %
|shows the number of bytes that have been retransmitted on TCP layer because of packet loss. High percentage indicate connection problems for this communication pair.
|-
|TCP DUP ACKs
|Number of DUP ACK packets
|-
|TCP missed data
|shows the estimated amount of TCP data not seen for this connection. See [[TCP module#Missed data|TCP module]] for details about missed data.
|-
|TCP SYNs/SYN-ACKs/FINs/RSTs
|shows the amount of TCP SYN, SYN-ACK, FIN and RST packets per direction. Up to 255 packets can be accounted, if more were seen, >= 255 will be displayed.
|-
|TCP end termination reason
|Connection end can be regular FIN, RST, or timeout if no termination is seen at all
|-
|TCP MSS
|The TCP maximum segment size may be announced by the peers using a TCP option during connection negotiation. If the option is not announced, default values will be used. The values represents the payload capacity of TCP packets sent by the peer.
|-
|Max announced TCP window size
|shows the size of the biggest TCP receive window announced for each direction of a connection.
|-
|Min announced TCP window size
|shows the size of the smallest TCP receive window announced for each direction of a connection.
|-
|Max TCP bytes in flight
|shows how much of the TCP receive window of the corresponding direction has been used at max during the lifetime of the connection, in other words this is the bytes in flight of the opposite, sending direction.
|-
|Announced TCP window size limit
|The TCP window size limit columns show the maximum possible value that could be used for the TCP receive window size. This is calculated from the announced TCP window scale option for each direction of a connection. The raw window scale (ws) shift count value is displayed in parentheses next to the byte value.
|-
|TCP window limit usage
|show the ratio of the TCP max window size values compared to the TCP window size limit values in percent.
|-
|TCP zero window packets
|Number of TCP zero window packets indicated full receive buffer.
|-
|Client announced TLS versions/Negotiated TLS version, Client announced cipher suites/Negotiated cipher suite
|shows the TLS versions and all supported cipher suites announced by the client during a SSL client hello. In the negotiated columns the currently used TLS version and cipher suite is shown as indicated by the SSL server hello. As the client announced cipher suite list can be quite long, it is possible expand or minimize the list by click on it.
|-
|TLS alert
|
|-
|TLS alert level
|
|-
|Validity
|Connections are counted as valid if the handshake succeeded or at least some data is transferred.
|-
|Meta data
|may contain additional information that could be retrieved depending on the protocol. For instance, for HTTP traffic this column shows the request URL and response code for the last transaction seen in the corresponding connection.
|-
|Outer VLANs
|shows which VLAN tags has been seen for a specific connection.
|-
|Inner VLANs
|shows which inner VLAN tags has been seen for a specific connection in QinQ setups.
|-
|PPPoE session ID
|shows the PPPoE session ID which has been seen for packets of that specific connection. If a PPPoE session ID changes at any time while the connection is active, a 'changed' indication is given. In this case the latter session ID is displayed.
|-
|MPLS labels
|shows all seen MPLS labels for every direction of the connection. The full label stack is shown. A '''no label''' indication is given, if no MPLS labels have been used. If a MPLS label changes at any time while the connection is active, a '''changed''' indication is given. In this case the latter MPLS labels are displayed.
|-
|QoS
|shows all seen QoS service classes for every direction of the connection. IP DSCP, outermost MPLS traffic classes and outermost VLAN priority code points may be detected and displayed. If a QoS class changes at any time while the connection is active, a '''changed''' indication is given. In this case the latter QoS service classes are displayed. TCP RST packets will be ignored, as that packet may be less important and is indicated by a QoS class with lower priority than the previous packets with data.
|-
|Interfaces
|shows at which interface the connection has been established. This is especially helpful in bridge mode to determine at which side of link the connection has been established.
|-
|Two-way latency avg interval
|[[Path measurement#Measurement_statistics|Statistics from the path measurement]]
|-
|Two-way latency min interval
|
|-
|Two-way latency max interval
|
|-
|One-way latency avg interval
|
|-
|One-way latency min interval
|
|-
|One-way latency max interval
|
|-
|Graph
|shows the historical throughput for each connection, it is possible to select the displayed graph from multiple different statistics (see [[Common table columns#Graph|Common table columns - Graph]]). Some may only be available if module options has been enabled, as it will increase the overall memory usage. Some statistics like the path latency is only available, if the path measurement module is active (and the corresponding option to store latencies per connection is enabled)
|-
|PCAP
|allows for capturing the specific connection (see [[Common table columns#PCAP|Common table columns - PCAP]])
|}
The list of connections can be filtered by entering a string into the text area. Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for details.
[[File:IP connection details.png|thumb|600x600px|Connection detail view]]
A detailed connection view can be accessed by clicking on the magnifying glass symbol in the client IP column.

===== CSV download =====

The connection list can also be downloaded as a CSV document by clicking at the CSV download button. The current filter and sort order is used when creating the CSV file.

The CSV file can also be accessed without using the web interface by getting the following URL:

<code>/API/stats/modules/ip/ips/x.x.x.x/connections?csv=true</code>

x.x.x.x must be replaced with the actual IP address. Additional URL parameters can be used to choose a time span, applying filters, etc. See [[REST API description]] for details.

==== Open TCP server ports ====

This tab shows the list of ports for which the IP address has accessed incoming connections.
It shows which service is (usually) behind the port.
Additionally, the first and last connection time is shown as well.
Also, there is button to capture traffic for the current IP and the corresponding port.

==== TCP statistics ====

This web page shows statistics about the response time of TCP connection handshake of all TCP connections of the current IP address. Also, the amount of data retransmitted due to packet loss is shown on the right side of the page. When TCP data has not been seen for TCP connections, the estimated amount is shown as well (see [[TCP module#Missed data|TCP module]] for details).

The graphs below show the historical data for each TCP handshake. The data point is the average handshake time and the vertical line shows the min and max handshake time for that specific time window (depending on the zoom level). Up to two graphs might be visible, one for data when the IP connected other IPs as a client, and another graph for data when the IP has been connected from other IPs as a server.

The TCP application times show info about data packets being transferred between the clients and server.
For each TCP connection, the following key attributes are measured and reported:

* '''Transactions:''' This metric indicates the count of data transaction cycles, allowing you to track the volume of activity over time.
* '''Data Transfer Time:''' This measures the time interval from the first data packet to the last consecutive data packet sent from the same side, giving you a clear picture of the data flow duration.
* '''First Data Response Time:''' This tracks the time between the last data packet sent and the first data packet received from the other peer, marking the conclusion of a transaction cycle
* '''Total Request-Response Time:''' This attribute captures the time interval from the first client data packet to the last server data packet during the entire request-response cycle, offering a comprehensive view of transaction latency.

It’s essential to understand that the values provided by the TCP application times feature are correlated through TCP packets containing data. This analysis is performed without decrypting the packets themselves, relying on observed patterns rather than the actual content of the packets. As such, the reported metrics are considered '''heuristics'''—meaning they offer insights based on empirical data rather than direct measurements of specific transactions. This approach allows for efficient monitoring while maintaining data integrity and privacy.
[[File:IP details application times.png|thumb|327x327px|TCP application time per IP]]
See [[TCP application time]] for more details about these values.

The connection table below shows a subset of the main connection table only for TCP connections for this IP. When sorting the handshake and response time columns and more than one time value is shown in a field, the maximum of all time values of that field is taken into account.

==== HTTP server statistics ====

This tab shows statistics (if available) of all HTTP requests handled by the current IP address.
The statistics contains:

* HTTP server names: All host names are shown that have been used to contact the HTTP server on this IP.
* Sent HTTP responses: This is the total number of requests/responses that have been seen on the network.
* Average response time: This is the average response time in milliseconds for all servers.
* Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
* Minimum response time: This is the smallest response time seen on the network.
* Maximum response time: This is the largest response time seen on the network.

The graph shows the historical data for all responses.
Below the graph, the number of response codes for each main code family is shown together with the last URL requested.

==== SSL server statistics ====

This tab shows statistics (if available) of all SSL requests handled by the current IP address.
The statistics contains:

* SSL server names: All host names are shown that have been used to contact the SSL server on this IP.
* Response time for SSL handshake
** Number of handshake: This is the total number of SSL requests/responses that have been seen for this IP.
** Average response time: This is the average response time in milliseconds.
** Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
** Minimum response time: This is the smallest response time.
** Maximum response time: This is the largest response time.
* Response time for SSL data
** Number of first data responses: This is the total number of initial SSL data requests/responses that have been seen for this IP.
** Average response time: This is the average response time in milliseconds.
** Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
** Minimum response time: This is the smallest response time.
** Maximum response time: This is the largest response time.

The graphs shows the historical data for all handshakes and SSL first data responses

==== SSL/TLS infos ====

This tab shows statistics (if available) of all negotiated SSL/TLS versions and cipher suites used by the current IP address either as server or client.

In case of an SSL/TLS client this tab will also show the supported SSL/TLS versions and cipher suites that have been announced by this client IP address.

==== SIP statistics ====

This tab shows statistics (if available) of all SIP request methods, all SIP response types as well as all SIP request/response pairs sent or received by the current IP address.

==== RTP statistics ====

This tab shows statistics (if available) of all RTP connections which involve the current IP address as either client or server.
A list shows all connections with client and server [[Common table columns#IP|IP addresses]] and ports. The RTP payload type is shown as well as timing informations and counters, jitter, packet time delta, MOS and R values and SSRC (synchronization source) of both client and server.
The min and max audio levels (decibel relative to full scale, dBFS) per direction are shown if G.711 A-Law or μ-Law is used.
For calculation, raw A-Law or μ-Law values are converted to 16 bit PCM values. Those values are then converted to dbFS:

value_dBFS = 20 * log10(abs(pcm_value) / 32768)
Values range from 0 dBFS (loudest) to -96 dBFS (absolute silence).

Graphs per connection show packets and packet loss, jitter, packet time delta, MOS, R value and the max audio level of client and server over time.
A PCAP button allows for PCAP capturing. If a proper codec is used, audio capture buttons for both directions are available allowing downloads in MP3 format.
Following codecs are supported for audio extraction:

* G.711 A-Law and μ-Law
* G.722
* G.729

==== Ping/Traceroute ====

A traceroute to the IP can be started or updated by clicking the Traceroute/Update button. Available traceroute data is shown in a table, containing details of each discovered network hop.
The following hop information may be displayed:

* IP address
* host name
* round trip time (average, minimum, maximum)
* rate of received responses to sent requests
* dropped packets count
* country
* city
* link to watch the location in online map services Google Maps or OpenStreetMaps

A button is available to easily navigate to the traceroute configuration section.

=== IP connection details ===
The connection detail view shows connection information in a single page. The view can be accessed in the list of IP connection (or the global connection list) by clicking on the magnifying glass symbol in the client IP column.

The page shows all data in a tabular format as well all graphs that are available for the connection.

A capture button at the right hand side can be used to capture packets of that connection.

The zoom button select the time range in which the connection was active.

For TCP connections a [[TCP flow chart]] can be calculated by clicking on the corresponding button:
[[File:TCP flow graph start.png|none|thumb|614x614px|Start TCP flow graph analysis]]See also [[IP connection details]].

== Configuration settings ==

By clicking on the gear button on the top right of the IP statistics web page, you can access the configuration section.

* Store connection information for every IP This option is enabled by default.
:When enabled, the IP measurement module stores every connection for each IP.
:This includes historical packet counter so you can see for individual connection at which time the connection transferred which amount of data.
:Connection data will be stored as long as possible regarding the total memory usage.
:Disabling this option will increase the minimum storage time significantly.

* Store layer 7 protocol information for every IP The network protocols and their historical traffic data is stored for each IP if this option is enabled.
:Disabling this option will increase the minimum storage time slightly.

* Track number of new connections for every IP
:When This option is enabled, TCP connections per IP will be tracked.
:Connections are divided into valid and invalid connections for server and client direction and the amount is shown.
:Disabling this option will increase the minimum storage time slightly.

* Store traffic history graph for IP peers
:This option allows enabling or disabling the traffic history graph that is shown per peer in the '''Peers''' tab for an IP.
:Disabling this option will increase the minimum storage time slightly.

* Store RTP performance information per IP and connection
:This option allows enabling or disabling of RTP related statistics that are shown in the '''RTP statistics''' tab for an IP.
:Jitter, packet time delta and MOS calculation in the [[SIP_module|SIP module]] also depends on this switch since it partially shows information stored at the IP address of RTP senders/receivers.
:Disabling this option will reduce the memory utilization and therefor increase the minimum storage time slightly.

* Store QoS information for every IP
:This option enables or disables to storage of Quality of Service information per IP.
:These information require additional memory so if these information are not necessary, memory can be save to increase global data storage time.

* Store SSL/TLS information for every connection
:This option enables or disables to storage of SSL/TLS information per IP. This includes used and announced
:encryption ciphers which can take additional memory per IP connection. If these information are not necessary, memory can be save to increase global data storage time.

* Store detailed TCP statistics for every connection
:This option allows to store detailed TCP statistics per connection, such as TCP retransmissions or TCP response time. The graph type can be selected in the IP connection tab to access these information.

* Maximum number of IP groups
:This option configures how many IP groups can be defined. The minimum (and default) value is 32 IP groups.
:The maximum value is 65535 IP groups. A new configuration value only takes effect after restarting the packet processing in the Administration menu.

* Maximum number of HTTP requests per connection
:This options configures how many HTTP request/response tuples are stored by default. The default is 1.
:On global and IP detail connection page it is possible to download CSV file with either the last or all HTTP request/responses per connection. In the latter case each connection line is duplicated with another HTTP request/response in chronological order.

TCP module

2024-08-09T13:31:08Z

Ralf:

The TCP module measures the time taken to receive the first response to a TCP connection setup packet. This time is influenced by the network round-trip time and the load of the server to be able to response to a connection request.
A score value is calculated based on a scoring algorithm.

'''Web interface'''
{| class="wikitable sortable"
|-
|[[File:TCP module.png|1000px|none|right]]
|}

== TCP handshake ==

This web page of the TCP module shows global statistics about the response time of TCP connection handshake of all TCP connections and a list of all servers for which response times could be calculated.

The global statistics contains:

* Number of TCP handshakes: This is the total number of TCP connections for which the handshake has been seen. It may be less than the number of all connections if connections have been established before the system has been started.
* Average handshake time: This is the average time between first TCP SYN packet and its response in milliseconds for all servers.
* Standard deviation: This value shows the variation of the handshake times (https://en.wikipedia.org/wiki/Standard_deviation)
* Minimum handshake time: This is the smallest handshake time seen on the network.
* Maximum handshake time: This is the largest handshake time seen on the network.

Next to the global statistics, there is a summary about the number of servers with good, bad, or medium handshake quality. The table is split to local servers (those within private networks) and global servers (all the rest).
The green plus symbol contains all servers with a quality score of 4 or more, the orange symbol covers all servers with a quality score between 3 and 4, and the red minus symbol covers all servers with a quality score of less than 3. The
list of servers below can be sorted for the quality value to view the relevant servers from each category.
Below the global statistics, there are up to two graphs showing the historical data for TCP handshakes.
Each data point shows the average handshake time for the time span (depending on the zoom factor), and the min and max time. One graph is for handshake times for the server (that is the time between the first SYN packet and the server
response) and the second graph shows the data for the client time (that is the time between the server response packet and the client acknowledgment).
Below the graph there is the list of all servers with the following columns:

* IP (see [[Common table columns#IP|Common table columns - IP]]): The server IP. Clicking on ''TCP statistics'' leads to the IP module subpage listing all TCP connections.
* No of handshake: The number of TCP requests/responses seen for this IP address.
* Avg handshake time: This is the average handshake time for this IP address.
* Deviation: This is the standard deviation for all handshake times of this IP address.
* Min handshake time: The minimum handshake time in milliseconds.
* Max handshake time: The maximum handshake time in milliseconds.
* Score: The score is a value between 1 and 5 describing the quality of the TCP handshake times. 1 means the worst quality, 5 means the best quality. The value is calculated based on a [[Scoring of response times|scoring algorithm]]. The score allows to quickly sort for quality and identify bad performing servers or servers with high round-trip time.
* Alternative names: The column contains other names for this IP address, from whatever name source that is available (DNS, DHCP, ...).

=== Per IP statistics ===

It is possible to select an IP from the list of IP addresses and get an more detailed view of the information stored about that IP.
The link leads to the TCP statistics page of that specific IP. Additional information can be found in the IP module.

== TCP response time ==

This tab shows the continuous measurement of TCP response times. The time measured is the interval between a transfer of data and the respective acknowledgement.

The graph on the top shows a minimum, maximum and average response time over all TCP connections observed.

The IP list below shows the minimum, maximum and average response time for each IP address.

== TCP application time ==
The application time measures the time of TCP transactions, that is consecutive data packets sent by the client, followed by a server response of consecutive data packets.
[[File:TCP module application times.png|none|thumb|550x550px|TCP application time]]
See [[TCP application time]] for more details about the measured values.
== TCP retransmissions ==

This tab shows all IP addresses with TCP traffic and the aggregated amount of TCP payload sent and received and the amount of data that needed to be retransmitted due to packet loss.

=== Garbage bytes ===
Garbage bytes are single bytes sent as part of TCP keep alive packets that have already been acknowledged before by the receiver the data. Some TCP implementations send single bytes as keep alive packets instead of just empty ACK packets. The retransmitted byte has already been acknowledge and may be the same or different as the original byte of the same sequence number. The TCP stack of the receiver will discard this byte. Technically it is a retransmitted byte, but since it is already acknowledged and will be discarded, we account this byte as a garbage byte to not show as part of regular retransmissions.

=== Missed data ===

Additionally to retransmission data, there is also a graph for the number of bytes not seen by the Allegro Network Multimeter. This can happen if for example a mirror/SPAN port is incapable of sending all packets to the Allegro.<br>
So the data was actually sent over the network, but only part of it was sent to the Allegro Network Multimeter for analysis.
In WireShark, such "missed data" events will be displayed with the ''additional protocol information'' [TCP ACKed unseen segment].

Example:

If there is a transfer of 500 Mbit/s going in the network but the mirror port only outputs 100 Mbit/s, the Allegro Network Multimeter of course can only account those 100 Mbit/s. But based on the TCP sequence numbers, we can estimate that the remaining 400 Mbit/s has been missed. This portion is visible in the missed data graph.

Usually one can expect to see no missed data at all, especially in inline mode, but it can still happen that there is a small amount of bytes not seen due to multiple reason. One reason is corrupt data where TCP sequence numbers are wrong on purpose. There can also be situations where TCP packets are not seen but actually sent, for example, if they are dropped in some other network component.

== TCP server with invalid connections ==

Here a list of all servers with invalid connections is shown. Connections are counted as invalid if the handshake fails or no data is transferred at all.

Each line shows the number of invalid connections and the number of valid connections for a certain TCP server.

The "invalid connection factor" is the ratio of invalid connections vs valid connection (invalid/(valid+1)). A higher value means more invalid connections and therefore indicates problematic IPs.

== TCP flags ==

This tab shows the occurence of certain TCP flags. Packets with the following flags are counted:

* TCP SYNs: TCP packets where the SYN flag is set but not the ACK flag
* TCP SYN-ACKs: TCP packets where the SYN flag and the ACK flag is set
* TCP FINs: TCP packets where the FIN flag is set
* TCP RSTs: TCP packets where the RST flag is set

A graph shows the number of packets for each tracked flag type over time. The IP list below the graph shows the number of sent and received TCP packets for each tracked flag type per IP.

== TCP zero window ==

This tab shows the occurence of TCP packets that signal a window size of zero. This usually means that the TCP receive buffer of the system sending the zero window packet is filled up and the system cannot receive any more data for that connection.
A graph shows the global number or TCP zero window packets over time. The [[Common table columns#IP|IP list]] below the graph shows the number of sent and received TCP zero window packets for each IP.

== Configuration settings ==

The TCP connection information rely on the IP module to store connections for each IP address. This feature takes significant amount of memory and can be disabled in the IP module configuration.
The button at the bottom of the page leads to the corresponding configuration section.

IP module

2024-08-09T13:28:35Z

Ralf: /* Connections tab */

The IP module operates on layer 3 of the network stack. It stores information about all IPv4 and IPv6 addresses.
For every address, the corresponding network traffic is accounted, the used protocols and their individual traffic.
The communication peers are stored as well as the traffic between both IP addresses. Every connection and its amount of traffic and the protocol can be accessed too.

== Web interface ==

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

=== IP addresses tab ===

The IP addresses tab shows the complete list of all IP addresses seen by the system. The button row allows for select specific information to be shown or hidden so that only the relevant information fit on the screen.
By clicking on '''Counters (combined)''' the table toggles between sent and received bytes and packets displayed in either one column or in separate columns for sorting purposes.
For each address, the table contains the following information:

* IP
:See [[Common table columns#IP|Common table columns - IP]].

* Alternative names
:See [[Common table columns#Alternative names|Common table columns - Alternative names]].
:The name information are also used when filtering the table for some entered string.

* Traceroute
:A traceroute for the IP can be requested or updated using the available button. When traceroute information is available for the IP, brief information about each found network hop (IP, hostname, ping response time) is displayed. Since this list of hops can get very long, the view can be toggled to show all found hops or just the last one by clicking on the traceroute header.

* First (recent) activity
:See [[Common table columns#First (recent) activity|Common table columns - First (recent) activity]].

* Last activity
:See [[Common table columns#Last activity|Common table columns - Last activity]].

* Packets and Bytes
:See [[Common table columns#Packets|Common table columns - Packets]] and [[Common table columns#Bytes|Common table columns - Bytes]].

* Packets/s and Bit/s
:See [[Common table columns#Packets/s|Common table columns - Packets/s]] and [[Common table columns#Bit/s|Common table columns - Bit/s]].

* Peers
: This shows the amount of peers of this IP. This counter is an all time only value and does not consider a selected interval.

* TTL
: This shows the min, max and average TTL value (or hop limit in case of IPv6) of TCP/UDP traffic of an IP address. Non-UDP and non-TCP traffic as well as multicast traffic is ignored as e.g. ICMP packets likely have very high TTL values of 255 at the sender.

* MTU
: The maximum transmission unit (i.e. layer 2 payload) is calculated for both receive and send direction. The maximum values are displayed.

* TCP packets and UDP packets
:This is the number of TCP and UDP packets that have been seen for this IP.

* TCP handshake time and TCP data response time
: The average time for a handshake as a TCP client and/or a TCP server is displayed as well as the average time the IP takes to acknowledge TCP data.

* TCP payload and retransmissions
:These two columns show the number of bytes transmitted as TCP payload and how many bytes have been retransmitted, indicating a bad connection quality.

* Graph
:See [[Common table columns#Graph|Common table columns - Graph]].
:Available data sources are load (bps or packets/s), TCP statistics or connections.

* PCAP
:See [[Common table columns#PCAP|Common table columns - PCAP]]

When multiple pages are available, there will be a control field for switching pages.
The IP search bar allows to enter IP addresses or names to see only those element for which the entered string is part of the IP address or name.
Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for a detailed description about how to use this feature.
The columns can be sorted also, for example to easily spot the IP addresses with the most bytes, or the highest current throughput.

Below the table a CSV download button provides the ability to download the whole table contents in CSV format.
Sorting and filtering are applied as selected for the table but all IPs in the table are exported, not only the currently visible page.

=== Global IP statistics tab ===

The global IP statistics shows global sums about the processed IPv4 and IPv6 traffic and often used layer 4 protocols.
Non-IP packets such as ARP packets are indicated as other traffic and are not covered by this module.
The available information is:
* Layer 3 protocols (IPv4, IPv6 and non-IP traffic, its distribution over time and a history graph)
* Layer 4 protocols (TCP, UDP and traffic for other often used layer 4 protocols, its distribution over time and a history graph)
* Number of IPv4 fragmented packets (distribution over time and a history graph)

For layer 3 and layer 4 protocols, traffic can be downloaded by clicking on the PCAP download button. The captured packets are not stored on the system but they are directly sent over the HTTP connection to your computer.
To stop capture, click on the same button again (which turned to a STOP symbol), or go to the capture traffic page in the generic section and stop the corresponding download.

=== Top IP statistics ===

On this page pie charts are shown with the top 10 sending and receiving IP addresses. By clicking on a pie chart section the related IP detail page is opened.

=== Per IP statistics ===

It is possible to select an IP from the list of IP addresses and get an more detailed view of the information stored about that IP.
The headline of the page includes three buttons.
The first left arrow button navigates back to the complete IP overview.
The second download button allows to download the traffic for the current IP address.
The third button allows for opening this manual section.
Below the buttons there are two graphs for the packets and bytes sent and received by the IP address.
The third section contains six tabs for various information about the selected IP.

==== Overview tab ====

This tab summarizes all the standard information from the main IP view, such as
* the alternative names,
* the packet and bytes counters, and
* the current throughput.

Additionally, the top DPI protocols are printed both in the table as well as a pie chart at the bottom of the page.
The last line in the table shows the MAC addresses seen for this IP address.
There can be multiple MAC addresses for the same IP, for example if the DHCP reuse the IP address after some time.
The last new connection time is the start time of the last connection seen for this IP.
There is also a download button to capture the traffic for the specific IP and MAC address pair.
The final two rows shows all VLAN tags that have been seen for the given IP. An IP address might be visible in multiple VLANs.
If the Allegro Network Multimeter is installed at a mirror port of a switch which also modifies the VLAN tag, it might happen that an IP address is seen without a VLAN tag (none) and a specific VLAN tag.
This setup will decrease the quality of the results as connections use the VLAN information too to distinguish connections.
The measurement results can be improved if the mirror port is reconfigured to only see traffic with VLAN or completely without VLAN tags.
The last row shows the devices interfaces at which the IP has been seen.
The displayed interface always considers the sender side of an IP connection.
This information helps especially in bridge mode to determine at which side of an link the IP address is visible as sender of packets.

==== Layer 3 QoS tab ====

This tab lists all seen IP DSCP values for the current IP.
Several traffic counters are displayed and a history graph of the traffic over time. A PCAP button allows for capturing the specific QoS tagged traffic for that IP.
By clicking on the shown DSCP class name you will be redirected to the '''Connection''' tab with a filter active that only shows connections for that specific DSCP value.

==== Layer 2 QoS tab ====

This tab lists all seen MPLS traffic classes and VLAN priority code points for the current IP.
Several traffic counters are displayed and a history graph of the traffic over time.
A PCAP button allows for capturing the specific QoS tagged traffic for that IP.
By clicking on the shown QoS class name you will be redirected to the '''Connection''' tab with a filter active that only shows connections for that specific QoS.

==== Protocols tab ====

This tab lists the DPI protocols for the current IP. The download button allows to capture the traffic for the IP and protocol pair.

==== Peers tab ====

The Peers tab shows all communication peers the current IP address has talked to. The table contains the [[Common table columns#IP|IP address]] which can be clicked to see the statistics for that IP.
The alternative names are shown, depending on which data is available (DNS name, DHCP name, NIC vendor name).
The packets and bytes columns show the total amount of data transferred between those two IP addresses.
The list of peers can be filtered by entering a string into the text area. Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for details.

==== Layer 4 endpoints ====

The layer 4 endpoint tab shows all peers of the current IP address and the used server port. If the peer is the server, the port of the peer is shown. If the peer is the client, the other port is shown.

The table shows [[Common table columns#IP|IP addresses]] with port number, whether the peer acts as a server or client, alternative names, layer 4 protocol and byte and packet counters. If there were multiple connection between the IP address and the peer with the same port, the counters will show aggregated data.

When clicking on "Peer connections" the connection tab is opened with the filter set to match that particular endpoint.

==== Connections tab ====

The connection tabs lists all connections which involves the current IP. The button rows allow to select which kind of information should be shown.

{| class="wikitable"
|+
!Column
!Description
|-
|Client IP/port
|Client side IP information (see [[Common table columns#IP|Common table columns - IP]])
|-
|Server IP/port
|Server side IP information (see [[Common table columns#IP|Common table columns - IP]])
|-
|Layer 4 protocol
|TCP, UDP, or others
|-
|Go to
|allows to go to the connection details page which shows all information in more detail.
|-
|Start time
|The start time is the time of the first packet for that connection.
|-
|Last activity
|shows the time of the last packet seen so far for the connection
|-
|Duration
|Difference between last activity and start time.
|-
|Packets
|Number of packets
|-
|Bytes
|Number of bytes
|-
|Packets/s
|Packet rate
|-
|Bit/s
|Bit rate
|-
|MTU
|The maximum transmission unit (i.e. layer 2 payload) is calculated for both directions.
|-
|Layer 7 protocol
|shows the detect application layer 7 protocol.
|-
|TCP handshake time
|The time between SYN and ACK.
|-
|TCP response time (max/avg)
|contains response times for TCP data
|-
|TCP application time
|Performance metrics for L7 applications (see [[TCP application time]] for details)
|-
|Layer 7 response time
|contains response times for the maximum HTTP response for HTTP connections, or the SSL response times for SSL connections. The column also contains a score for this connection and this IP, based on the average response times of the server. See HTTP module and SSL module for additional information. When sorting the column and more than one time value is shown in a field, the maximum of all time values of that field is taken into account.
|-
|TCP retransmissions/TCP restransmission %
|shows the number of bytes that have been retransmitted on TCP layer because of packet loss. High percentage indicate connection problems for this communication pair.
|-
|TCP DUP ACKs
|Number of DUP ACK packets
|-
|TCP missed data
|shows the estimated amount of TCP data not seen for this connection. See [[TCP module#Missed data|TCP module]] for details about missed data.
|-
|TCP SYNs/SYN-ACKs/FINs/RSTs
|shows the amount of TCP SYN, SYN-ACK, FIN and RST packets per direction. Up to 255 packets can be accounted, if more were seen, >= 255 will be displayed.
|-
|TCP end termination reason
|Connection end can be regular FIN, RST, or timeout if no termination is seen at all
|-
|TCP MSS
|The TCP maximum segment size may be announced by the peers using a TCP option during connection negotiation. If the option is not announced, default values will be used. The values represents the payload capacity of TCP packets sent by the peer.
|-
|Max announced TCP window size
|shows the size of the biggest TCP receive window announced for each direction of a connection.
|-
|Min announced TCP window size
|shows the size of the smallest TCP receive window announced for each direction of a connection.
|-
|Max TCP bytes in flight
|shows how much of the TCP receive window of the corresponding direction has been used at max during the lifetime of the connection, in other words this is the bytes in flight of the opposite, sending direction.
|-
|Announced TCP window size limit
|The TCP window size limit columns show the maximum possible value that could be used for the TCP receive window size. This is calculated from the announced TCP window scale option for each direction of a connection. The raw window scale (ws) shift count value is displayed in parentheses next to the byte value.
|-
|TCP window limit usage
|show the ratio of the TCP max window size values compared to the TCP window size limit values in percent.
|-
|TCP zero window packets
|Number of TCP zero window packets indicated full receive buffer.
|-
|Client announced TLS versions/Negotiated TLS version, Client announced cipher suites/Negotiated cipher suite
|shows the TLS versions and all supported cipher suites announced by the client during a SSL client hello. In the negotiated columns the currently used TLS version and cipher suite is shown as indicated by the SSL server hello. As the client announced cipher suite list can be quite long, it is possible expand or minimize the list by click on it.
|-
|TLS alert
|
|-
|TLS alert level
|
|-
|Validity
|Connections are counted as valid if the handshake succeeded or at least some data is transferred.
|-
|Meta data
|may contain additional information that could be retrieved depending on the protocol. For instance, for HTTP traffic this column shows the request URL and response code for the last transaction seen in the corresponding connection.
|-
|Outer VLANs
|shows which VLAN tags has been seen for a specific connection.
|-
|Inner VLANs
|shows which inner VLAN tags has been seen for a specific connection in QinQ setups.
|-
|PPPoE session ID
|shows the PPPoE session ID which has been seen for packets of that specific connection. If a PPPoE session ID changes at any time while the connection is active, a 'changed' indication is given. In this case the latter session ID is displayed.
|-
|MPLS labels
|shows all seen MPLS labels for every direction of the connection. The full label stack is shown. A '''no label''' indication is given, if no MPLS labels have been used. If a MPLS label changes at any time while the connection is active, a '''changed''' indication is given. In this case the latter MPLS labels are displayed.
|-
|QoS
|shows all seen QoS service classes for every direction of the connection. IP DSCP, outermost MPLS traffic classes and outermost VLAN priority code points may be detected and displayed. If a QoS class changes at any time while the connection is active, a '''changed''' indication is given. In this case the latter QoS service classes are displayed. TCP RST packets will be ignored, as that packet may be less important and is indicated by a QoS class with lower priority than the previous packets with data.
|-
|Interfaces
|shows at which interface the connection has been established. This is especially helpful in bridge mode to determine at which side of link the connection has been established.
|-
|Two-way latency avg interval
|[[Path measurement#Measurement_statistics|Statistics from the path measurement]]
|-
|Two-way latency min interval
|
|-
|Two-way latency max interval
|
|-
|One-way latency avg interval
|
|-
|One-way latency min interval
|
|-
|One-way latency max interval
|
|-
|Graph
|shows the historical throughput for each connection, it is possible to select the displayed graph from multiple different statistics (see [[Common table columns#Graph|Common table columns - Graph]]). Some may only be available if module options has been enabled, as it will increase the overall memory usage. Some statistics like the path latency is only available, if the path measurement module is active (and the corresponding option to store latencies per connection is enabled)
|-
|PCAP
|allows for capturing the specific connection (see [[Common table columns#PCAP|Common table columns - PCAP]])
|}
The list of connections can be filtered by entering a string into the text area. Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for details.
[[File:IP connection details.png|thumb|600x600px|Connection detail view]]
A detailed connection view can be accessed by clicking on the magnifying glass symbol in the client IP column.

===== CSV download =====

The connection list can also be downloaded as a CSV document by clicking at the CSV download button. The current filter and sort order is used when creating the CSV file.

The CSV file can also be accessed without using the web interface by getting the following URL:

<code>/API/stats/modules/ip/ips/x.x.x.x/connections?csv=true</code>

x.x.x.x must be replaced with the actual IP address. Additional URL parameters can be used to choose a time span, applying filters, etc. See [[REST API description]] for details.

==== Open TCP server ports ====

This tab shows the list of ports for which the IP address has accessed incoming connections.
It shows which service is (usually) behind the port.
Additionally, the first and last connection time is shown as well.
Also, there is button to capture traffic for the current IP and the corresponding port.

==== TCP statistics ====

This web page shows statistics about the response time of TCP connection handshake of all TCP connections of the current IP address. Also, the amount of data retransmitted due to packet loss is shown on the right side of the page. When TCP data has not been seen for TCP connections, the estimated amount is shown as well (see [[TCP module#Missed data|TCP module]] for details).

The graphs below show the historical data for each TCP handshake. The data point is the average handshake time and the vertical line shows the min and max handshake time for that specific time window (depending on the zoom level). Up to two graphs might be visible, one for data when the IP connected other IPs as a client, and another graph for data when the IP has been connected from other IPs as a server.

The TCP application times show info about data packets being transferred between the clients and server.
For each TCP connection, the following key attributes are measured and reported:

* '''Transactions:''' This metric indicates the count of data transaction cycles, allowing you to track the volume of activity over time.
* '''Data Transfer Time:''' This measures the time interval from the first data packet to the last consecutive data packet sent from the same side, giving you a clear picture of the data flow duration.
* '''First Data Response Time:''' This tracks the time between the last data packet sent and the first data packet received from the other peer, marking the conclusion of a transaction cycle
* '''Total Request-Response Time:''' This attribute captures the time interval from the first client data packet to the last server data packet during the entire request-response cycle, offering a comprehensive view of transaction latency.

It’s essential to understand that the values provided by the TCP application times feature are correlated through TCP packets containing data. This analysis is performed without decrypting the packets themselves, relying on observed patterns rather than the actual content of the packets. As such, the reported metrics are considered '''heuristics'''—meaning they offer insights based on empirical data rather than direct measurements of specific transactions. This approach allows for efficient monitoring while maintaining data integrity and privacy.

See [[TCP application time]] for more details about these values.

The connection table below shows a subset of the main connection table only for TCP connections for this IP. When sorting the handshake and response time columns and more than one time value is shown in a field, the maximum of all time values of that field is taken into account.

==== HTTP server statistics ====

This tab shows statistics (if available) of all HTTP requests handled by the current IP address.
The statistics contains:

* HTTP server names: All host names are shown that have been used to contact the HTTP server on this IP.
* Sent HTTP responses: This is the total number of requests/responses that have been seen on the network.
* Average response time: This is the average response time in milliseconds for all servers.
* Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
* Minimum response time: This is the smallest response time seen on the network.
* Maximum response time: This is the largest response time seen on the network.

The graph shows the historical data for all responses.
Below the graph, the number of response codes for each main code family is shown together with the last URL requested.

==== SSL server statistics ====

This tab shows statistics (if available) of all SSL requests handled by the current IP address.
The statistics contains:

* SSL server names: All host names are shown that have been used to contact the SSL server on this IP.
* Response time for SSL handshake
** Number of handshake: This is the total number of SSL requests/responses that have been seen for this IP.
** Average response time: This is the average response time in milliseconds.
** Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
** Minimum response time: This is the smallest response time.
** Maximum response time: This is the largest response time.
* Response time for SSL data
** Number of first data responses: This is the total number of initial SSL data requests/responses that have been seen for this IP.
** Average response time: This is the average response time in milliseconds.
** Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
** Minimum response time: This is the smallest response time.
** Maximum response time: This is the largest response time.

The graphs shows the historical data for all handshakes and SSL first data responses

==== SSL/TLS infos ====

This tab shows statistics (if available) of all negotiated SSL/TLS versions and cipher suites used by the current IP address either as server or client.

In case of an SSL/TLS client this tab will also show the supported SSL/TLS versions and cipher suites that have been announced by this client IP address.

==== SIP statistics ====

This tab shows statistics (if available) of all SIP request methods, all SIP response types as well as all SIP request/response pairs sent or received by the current IP address.

==== RTP statistics ====

This tab shows statistics (if available) of all RTP connections which involve the current IP address as either client or server.
A list shows all connections with client and server [[Common table columns#IP|IP addresses]] and ports. The RTP payload type is shown as well as timing informations and counters, jitter, packet time delta, MOS and R values and SSRC (synchronization source) of both client and server.
The min and max audio levels (decibel relative to full scale, dBFS) per direction are shown if G.711 A-Law or μ-Law is used.
For calculation, raw A-Law or μ-Law values are converted to 16 bit PCM values. Those values are then converted to dbFS:

value_dBFS = 20 * log10(abs(pcm_value) / 32768)
Values range from 0 dBFS (loudest) to -96 dBFS (absolute silence).

Graphs per connection show packets and packet loss, jitter, packet time delta, MOS, R value and the max audio level of client and server over time.
A PCAP button allows for PCAP capturing. If a proper codec is used, audio capture buttons for both directions are available allowing downloads in MP3 format.
Following codecs are supported for audio extraction:

* G.711 A-Law and μ-Law
* G.722
* G.729

==== Ping/Traceroute ====

A traceroute to the IP can be started or updated by clicking the Traceroute/Update button. Available traceroute data is shown in a table, containing details of each discovered network hop.
The following hop information may be displayed:

* IP address
* host name
* round trip time (average, minimum, maximum)
* rate of received responses to sent requests
* dropped packets count
* country
* city
* link to watch the location in online map services Google Maps or OpenStreetMaps

A button is available to easily navigate to the traceroute configuration section.

=== IP connection details ===
The connection detail view shows connection information in a single page. The view can be accessed in the list of IP connection (or the global connection list) by clicking on the magnifying glass symbol in the client IP column.

The page shows all data in a tabular format as well all graphs that are available for the connection.

A capture button at the right hand side can be used to capture packets of that connection.

The zoom button select the time range in which the connection was active.

For TCP connections a [[TCP flow chart]] can be calculated by clicking on the corresponding button:
[[File:TCP flow graph start.png|none|thumb|614x614px|Start TCP flow graph analysis]]See also [[IP connection details]].

== Configuration settings ==

By clicking on the gear button on the top right of the IP statistics web page, you can access the configuration section.

* Store connection information for every IP This option is enabled by default.
:When enabled, the IP measurement module stores every connection for each IP.
:This includes historical packet counter so you can see for individual connection at which time the connection transferred which amount of data.
:Connection data will be stored as long as possible regarding the total memory usage.
:Disabling this option will increase the minimum storage time significantly.

* Store layer 7 protocol information for every IP The network protocols and their historical traffic data is stored for each IP if this option is enabled.
:Disabling this option will increase the minimum storage time slightly.

* Track number of new connections for every IP
:When This option is enabled, TCP connections per IP will be tracked.
:Connections are divided into valid and invalid connections for server and client direction and the amount is shown.
:Disabling this option will increase the minimum storage time slightly.

* Store traffic history graph for IP peers
:This option allows enabling or disabling the traffic history graph that is shown per peer in the '''Peers''' tab for an IP.
:Disabling this option will increase the minimum storage time slightly.

* Store RTP performance information per IP and connection
:This option allows enabling or disabling of RTP related statistics that are shown in the '''RTP statistics''' tab for an IP.
:Jitter, packet time delta and MOS calculation in the [[SIP_module|SIP module]] also depends on this switch since it partially shows information stored at the IP address of RTP senders/receivers.
:Disabling this option will reduce the memory utilization and therefor increase the minimum storage time slightly.

* Store QoS information for every IP
:This option enables or disables to storage of Quality of Service information per IP.
:These information require additional memory so if these information are not necessary, memory can be save to increase global data storage time.

* Store SSL/TLS information for every connection
:This option enables or disables to storage of SSL/TLS information per IP. This includes used and announced
:encryption ciphers which can take additional memory per IP connection. If these information are not necessary, memory can be save to increase global data storage time.

* Store detailed TCP statistics for every connection
:This option allows to store detailed TCP statistics per connection, such as TCP retransmissions or TCP response time. The graph type can be selected in the IP connection tab to access these information.

* Maximum number of IP groups
:This option configures how many IP groups can be defined. The minimum (and default) value is 32 IP groups.
:The maximum value is 65535 IP groups. A new configuration value only takes effect after restarting the packet processing in the Administration menu.

* Maximum number of HTTP requests per connection
:This options configures how many HTTP request/response tuples are stored by default. The default is 1.
:On global and IP detail connection page it is possible to download CSV file with either the last or all HTTP request/responses per connection. In the latter case each connection line is duplicated with another HTTP request/response in chronological order.

IP module

2024-08-09T13:27:14Z

Ralf: /* TCP statistics */

The IP module operates on layer 3 of the network stack. It stores information about all IPv4 and IPv6 addresses.
For every address, the corresponding network traffic is accounted, the used protocols and their individual traffic.
The communication peers are stored as well as the traffic between both IP addresses. Every connection and its amount of traffic and the protocol can be accessed too.

== Web interface ==

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

=== IP addresses tab ===

The IP addresses tab shows the complete list of all IP addresses seen by the system. The button row allows for select specific information to be shown or hidden so that only the relevant information fit on the screen.
By clicking on '''Counters (combined)''' the table toggles between sent and received bytes and packets displayed in either one column or in separate columns for sorting purposes.
For each address, the table contains the following information:

* IP
:See [[Common table columns#IP|Common table columns - IP]].

* Alternative names
:See [[Common table columns#Alternative names|Common table columns - Alternative names]].
:The name information are also used when filtering the table for some entered string.

* Traceroute
:A traceroute for the IP can be requested or updated using the available button. When traceroute information is available for the IP, brief information about each found network hop (IP, hostname, ping response time) is displayed. Since this list of hops can get very long, the view can be toggled to show all found hops or just the last one by clicking on the traceroute header.

* First (recent) activity
:See [[Common table columns#First (recent) activity|Common table columns - First (recent) activity]].

* Last activity
:See [[Common table columns#Last activity|Common table columns - Last activity]].

* Packets and Bytes
:See [[Common table columns#Packets|Common table columns - Packets]] and [[Common table columns#Bytes|Common table columns - Bytes]].

* Packets/s and Bit/s
:See [[Common table columns#Packets/s|Common table columns - Packets/s]] and [[Common table columns#Bit/s|Common table columns - Bit/s]].

* Peers
: This shows the amount of peers of this IP. This counter is an all time only value and does not consider a selected interval.

* TTL
: This shows the min, max and average TTL value (or hop limit in case of IPv6) of TCP/UDP traffic of an IP address. Non-UDP and non-TCP traffic as well as multicast traffic is ignored as e.g. ICMP packets likely have very high TTL values of 255 at the sender.

* MTU
: The maximum transmission unit (i.e. layer 2 payload) is calculated for both receive and send direction. The maximum values are displayed.

* TCP packets and UDP packets
:This is the number of TCP and UDP packets that have been seen for this IP.

* TCP handshake time and TCP data response time
: The average time for a handshake as a TCP client and/or a TCP server is displayed as well as the average time the IP takes to acknowledge TCP data.

* TCP payload and retransmissions
:These two columns show the number of bytes transmitted as TCP payload and how many bytes have been retransmitted, indicating a bad connection quality.

* Graph
:See [[Common table columns#Graph|Common table columns - Graph]].
:Available data sources are load (bps or packets/s), TCP statistics or connections.

* PCAP
:See [[Common table columns#PCAP|Common table columns - PCAP]]

When multiple pages are available, there will be a control field for switching pages.
The IP search bar allows to enter IP addresses or names to see only those element for which the entered string is part of the IP address or name.
Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for a detailed description about how to use this feature.
The columns can be sorted also, for example to easily spot the IP addresses with the most bytes, or the highest current throughput.

Below the table a CSV download button provides the ability to download the whole table contents in CSV format.
Sorting and filtering are applied as selected for the table but all IPs in the table are exported, not only the currently visible page.

=== Global IP statistics tab ===

The global IP statistics shows global sums about the processed IPv4 and IPv6 traffic and often used layer 4 protocols.
Non-IP packets such as ARP packets are indicated as other traffic and are not covered by this module.
The available information is:
* Layer 3 protocols (IPv4, IPv6 and non-IP traffic, its distribution over time and a history graph)
* Layer 4 protocols (TCP, UDP and traffic for other often used layer 4 protocols, its distribution over time and a history graph)
* Number of IPv4 fragmented packets (distribution over time and a history graph)

For layer 3 and layer 4 protocols, traffic can be downloaded by clicking on the PCAP download button. The captured packets are not stored on the system but they are directly sent over the HTTP connection to your computer.
To stop capture, click on the same button again (which turned to a STOP symbol), or go to the capture traffic page in the generic section and stop the corresponding download.

=== Top IP statistics ===

On this page pie charts are shown with the top 10 sending and receiving IP addresses. By clicking on a pie chart section the related IP detail page is opened.

=== Per IP statistics ===

It is possible to select an IP from the list of IP addresses and get an more detailed view of the information stored about that IP.
The headline of the page includes three buttons.
The first left arrow button navigates back to the complete IP overview.
The second download button allows to download the traffic for the current IP address.
The third button allows for opening this manual section.
Below the buttons there are two graphs for the packets and bytes sent and received by the IP address.
The third section contains six tabs for various information about the selected IP.

==== Overview tab ====

This tab summarizes all the standard information from the main IP view, such as
* the alternative names,
* the packet and bytes counters, and
* the current throughput.

Additionally, the top DPI protocols are printed both in the table as well as a pie chart at the bottom of the page.
The last line in the table shows the MAC addresses seen for this IP address.
There can be multiple MAC addresses for the same IP, for example if the DHCP reuse the IP address after some time.
The last new connection time is the start time of the last connection seen for this IP.
There is also a download button to capture the traffic for the specific IP and MAC address pair.
The final two rows shows all VLAN tags that have been seen for the given IP. An IP address might be visible in multiple VLANs.
If the Allegro Network Multimeter is installed at a mirror port of a switch which also modifies the VLAN tag, it might happen that an IP address is seen without a VLAN tag (none) and a specific VLAN tag.
This setup will decrease the quality of the results as connections use the VLAN information too to distinguish connections.
The measurement results can be improved if the mirror port is reconfigured to only see traffic with VLAN or completely without VLAN tags.
The last row shows the devices interfaces at which the IP has been seen.
The displayed interface always considers the sender side of an IP connection.
This information helps especially in bridge mode to determine at which side of an link the IP address is visible as sender of packets.

==== Layer 3 QoS tab ====

This tab lists all seen IP DSCP values for the current IP.
Several traffic counters are displayed and a history graph of the traffic over time. A PCAP button allows for capturing the specific QoS tagged traffic for that IP.
By clicking on the shown DSCP class name you will be redirected to the '''Connection''' tab with a filter active that only shows connections for that specific DSCP value.

==== Layer 2 QoS tab ====

This tab lists all seen MPLS traffic classes and VLAN priority code points for the current IP.
Several traffic counters are displayed and a history graph of the traffic over time.
A PCAP button allows for capturing the specific QoS tagged traffic for that IP.
By clicking on the shown QoS class name you will be redirected to the '''Connection''' tab with a filter active that only shows connections for that specific QoS.

==== Protocols tab ====

This tab lists the DPI protocols for the current IP. The download button allows to capture the traffic for the IP and protocol pair.

==== Peers tab ====

The Peers tab shows all communication peers the current IP address has talked to. The table contains the [[Common table columns#IP|IP address]] which can be clicked to see the statistics for that IP.
The alternative names are shown, depending on which data is available (DNS name, DHCP name, NIC vendor name).
The packets and bytes columns show the total amount of data transferred between those two IP addresses.
The list of peers can be filtered by entering a string into the text area. Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for details.

==== Layer 4 endpoints ====

The layer 4 endpoint tab shows all peers of the current IP address and the used server port. If the peer is the server, the port of the peer is shown. If the peer is the client, the other port is shown.

The table shows [[Common table columns#IP|IP addresses]] with port number, whether the peer acts as a server or client, alternative names, layer 4 protocol and byte and packet counters. If there were multiple connection between the IP address and the peer with the same port, the counters will show aggregated data.

When clicking on "Peer connections" the connection tab is opened with the filter set to match that particular endpoint.

==== Connections tab ====

The connection tabs lists all connections which involves the current IP. The button rows allow to select which kind of information should be shown.

{| class="wikitable"
|+
!Column
!Description
|-
|Client IP/port
|Client side IP information (see [[Common table columns#IP|Common table columns - IP]])
|-
|Server IP/port
|Server side IP information (see [[Common table columns#IP|Common table columns - IP]])
|-
|Layer 4 protocol
|TCP, UDP, or others
|-
|Go to
|allows to go to the connection details page which shows all information in more detail.
|-
|Start time
|The start time is the time of the first packet for that connection.
|-
|Last activity
|shows the time of the last packet seen so far for the connection
|-
|Duration
|Difference between last activity and start time.
|-
|Packets
|Number of packets
|-
|Bytes
|Number of bytes
|-
|Packets/s
|Packet rate
|-
|Bit/s
|Bit rate
|-
|MTU
|The maximum transmission unit (i.e. layer 2 payload) is calculated for both directions.
|-
|Layer 7 protocol
|shows the detect application layer 7 protocol.
|-
|TCP handshake time
|The time between SYN and ACK.
|-
|TCP response time (max/avg)
|contains response times for TCP data
|-
|Layer 7 response time
|contains response times for the maximum HTTP response for HTTP connections, or the SSL response times for SSL connections. The column also contains a score for this connection and this IP, based on the average response times of the server. See HTTP module and SSL module for additional information. When sorting the column and more than one time value is shown in a field, the maximum of all time values of that field is taken into account.
|-
|TCP retransmissions/TCP restransmission %
|shows the number of bytes that have been retransmitted on TCP layer because of packet loss. High percentage indicate connection problems for this communication pair.
|-
|TCP DUP ACKs
|Number of DUP ACK packets
|-
|TCP missed data
|shows the estimated amount of TCP data not seen for this connection. See [[TCP module#Missed data|TCP module]] for details about missed data.
|-
|TCP SYNs/SYN-ACKs/FINs/RSTs
|shows the amount of TCP SYN, SYN-ACK, FIN and RST packets per direction. Up to 255 packets can be accounted, if more were seen, >= 255 will be displayed.
|-
|TCP end termination reason
|Connection end can be regular FIN, RST, or timeout if no termination is seen at all
|-
|TCP MSS
|The TCP maximum segment size may be announced by the peers using a TCP option during connection negotiation. If the option is not announced, default values will be used. The values represents the payload capacity of TCP packets sent by the peer.
|-
|Max announced TCP window size
|shows the size of the biggest TCP receive window announced for each direction of a connection.
|-
|Min announced TCP window size
|shows the size of the smallest TCP receive window announced for each direction of a connection.
|-
|Max TCP bytes in flight
|shows how much of the TCP receive window of the corresponding direction has been used at max during the lifetime of the connection, in other words this is the bytes in flight of the opposite, sending direction.
|-
|Announced TCP window size limit
|The TCP window size limit columns show the maximum possible value that could be used for the TCP receive window size. This is calculated from the announced TCP window scale option for each direction of a connection. The raw window scale (ws) shift count value is displayed in parentheses next to the byte value.
|-
|TCP window limit usage
|show the ratio of the TCP max window size values compared to the TCP window size limit values in percent.
|-
|TCP zero window packets
|Number of TCP zero window packets indicated full receive buffer.
|-
|Client announced TLS versions/Negotiated TLS version, Client announced cipher suites/Negotiated cipher suite
|shows the TLS versions and all supported cipher suites announced by the client during a SSL client hello. In the negotiated columns the currently used TLS version and cipher suite is shown as indicated by the SSL server hello. As the client announced cipher suite list can be quite long, it is possible expand or minimize the list by click on it.
|-
|TLS alert
|
|-
|TLS alert level
|
|-
|Validity
|Connections are counted as valid if the handshake succeeded or at least some data is transferred.
|-
|Meta data
|may contain additional information that could be retrieved depending on the protocol. For instance, for HTTP traffic this column shows the request URL and response code for the last transaction seen in the corresponding connection.
|-
|Outer VLANs
|shows which VLAN tags has been seen for a specific connection.
|-
|Inner VLANs
|shows which inner VLAN tags has been seen for a specific connection in QinQ setups.
|-
|PPPoE session ID
|shows the PPPoE session ID which has been seen for packets of that specific connection. If a PPPoE session ID changes at any time while the connection is active, a 'changed' indication is given. In this case the latter session ID is displayed.
|-
|MPLS labels
|shows all seen MPLS labels for every direction of the connection. The full label stack is shown. A '''no label''' indication is given, if no MPLS labels have been used. If a MPLS label changes at any time while the connection is active, a '''changed''' indication is given. In this case the latter MPLS labels are displayed.
|-
|QoS
|shows all seen QoS service classes for every direction of the connection. IP DSCP, outermost MPLS traffic classes and outermost VLAN priority code points may be detected and displayed. If a QoS class changes at any time while the connection is active, a '''changed''' indication is given. In this case the latter QoS service classes are displayed. TCP RST packets will be ignored, as that packet may be less important and is indicated by a QoS class with lower priority than the previous packets with data.
|-
|Interfaces
|shows at which interface the connection has been established. This is especially helpful in bridge mode to determine at which side of link the connection has been established.
|-
|Two-way latency avg interval
|[[Path measurement#Measurement_statistics|Statistics from the path measurement]]
|-
|Two-way latency min interval
|
|-
|Two-way latency max interval
|
|-
|One-way latency avg interval
|
|-
|One-way latency min interval
|
|-
|One-way latency max interval
|
|-
|Graph
|shows the historical throughput for each connection, it is possible to select the displayed graph from multiple different statistics (see [[Common table columns#Graph|Common table columns - Graph]]). Some may only be available if module options has been enabled, as it will increase the overall memory usage. Some statistics like the path latency is only available, if the path measurement module is active (and the corresponding option to store latencies per connection is enabled)
|-
|PCAP
|allows for capturing the specific connection (see [[Common table columns#PCAP|Common table columns - PCAP]])
|}
The list of connections can be filtered by entering a string into the text area. Also, complex filter expressions are possible, if the string starts with an open parenthesis '''('''. See [[Live_filtering_of_tables|Live filtering of tables]] for details.
[[File:IP connection details.png|thumb|600x600px|Connection detail view]]
A detailed connection view can be accessed by clicking on the magnifying glass symbol in the client IP column.

===== CSV download =====

The connection list can also be downloaded as a CSV document by clicking at the CSV download button. The current filter and sort order is used when creating the CSV file.

The CSV file can also be accessed without using the web interface by getting the following URL:

<code>/API/stats/modules/ip/ips/x.x.x.x/connections?csv=true</code>

x.x.x.x must be replaced with the actual IP address. Additional URL parameters can be used to choose a time span, applying filters, etc. See [[REST API description]] for details.

==== Open TCP server ports ====

This tab shows the list of ports for which the IP address has accessed incoming connections.
It shows which service is (usually) behind the port.
Additionally, the first and last connection time is shown as well.
Also, there is button to capture traffic for the current IP and the corresponding port.

==== TCP statistics ====

This web page shows statistics about the response time of TCP connection handshake of all TCP connections of the current IP address. Also, the amount of data retransmitted due to packet loss is shown on the right side of the page. When TCP data has not been seen for TCP connections, the estimated amount is shown as well (see [[TCP module#Missed data|TCP module]] for details).

The graphs below show the historical data for each TCP handshake. The data point is the average handshake time and the vertical line shows the min and max handshake time for that specific time window (depending on the zoom level). Up to two graphs might be visible, one for data when the IP connected other IPs as a client, and another graph for data when the IP has been connected from other IPs as a server.

The TCP application times show info about data packets being transferred between the clients and server.
For each TCP connection, the following key attributes are measured and reported:

* '''Transactions:''' This metric indicates the count of data transaction cycles, allowing you to track the volume of activity over time.
* '''Data Transfer Time:''' This measures the time interval from the first data packet to the last consecutive data packet sent from the same side, giving you a clear picture of the data flow duration.
* '''First Data Response Time:''' This tracks the time between the last data packet sent and the first data packet received from the other peer, marking the conclusion of a transaction cycle
* '''Total Request-Response Time:''' This attribute captures the time interval from the first client data packet to the last server data packet during the entire request-response cycle, offering a comprehensive view of transaction latency.

It’s essential to understand that the values provided by the TCP application times feature are correlated through TCP packets containing data. This analysis is performed without decrypting the packets themselves, relying on observed patterns rather than the actual content of the packets. As such, the reported metrics are considered '''heuristics'''—meaning they offer insights based on empirical data rather than direct measurements of specific transactions. This approach allows for efficient monitoring while maintaining data integrity and privacy.

See [[TCP application time]] for more details about these values.

The connection table below shows a subset of the main connection table only for TCP connections for this IP. When sorting the handshake and response time columns and more than one time value is shown in a field, the maximum of all time values of that field is taken into account.

==== HTTP server statistics ====

This tab shows statistics (if available) of all HTTP requests handled by the current IP address.
The statistics contains:

* HTTP server names: All host names are shown that have been used to contact the HTTP server on this IP.
* Sent HTTP responses: This is the total number of requests/responses that have been seen on the network.
* Average response time: This is the average response time in milliseconds for all servers.
* Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
* Minimum response time: This is the smallest response time seen on the network.
* Maximum response time: This is the largest response time seen on the network.

The graph shows the historical data for all responses.
Below the graph, the number of response codes for each main code family is shown together with the last URL requested.

==== SSL server statistics ====

This tab shows statistics (if available) of all SSL requests handled by the current IP address.
The statistics contains:

* SSL server names: All host names are shown that have been used to contact the SSL server on this IP.
* Response time for SSL handshake
** Number of handshake: This is the total number of SSL requests/responses that have been seen for this IP.
** Average response time: This is the average response time in milliseconds.
** Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
** Minimum response time: This is the smallest response time.
** Maximum response time: This is the largest response time.
* Response time for SSL data
** Number of first data responses: This is the total number of initial SSL data requests/responses that have been seen for this IP.
** Average response time: This is the average response time in milliseconds.
** Standard deviation: This value shows the variation of the response times (https://en.wikipedia.org/wiki/Standard_deviation)
** Minimum response time: This is the smallest response time.
** Maximum response time: This is the largest response time.

The graphs shows the historical data for all handshakes and SSL first data responses

==== SSL/TLS infos ====

This tab shows statistics (if available) of all negotiated SSL/TLS versions and cipher suites used by the current IP address either as server or client.

In case of an SSL/TLS client this tab will also show the supported SSL/TLS versions and cipher suites that have been announced by this client IP address.

==== SIP statistics ====

This tab shows statistics (if available) of all SIP request methods, all SIP response types as well as all SIP request/response pairs sent or received by the current IP address.

==== RTP statistics ====

This tab shows statistics (if available) of all RTP connections which involve the current IP address as either client or server.
A list shows all connections with client and server [[Common table columns#IP|IP addresses]] and ports. The RTP payload type is shown as well as timing informations and counters, jitter, packet time delta, MOS and R values and SSRC (synchronization source) of both client and server.
The min and max audio levels (decibel relative to full scale, dBFS) per direction are shown if G.711 A-Law or μ-Law is used.
For calculation, raw A-Law or μ-Law values are converted to 16 bit PCM values. Those values are then converted to dbFS:

value_dBFS = 20 * log10(abs(pcm_value) / 32768)
Values range from 0 dBFS (loudest) to -96 dBFS (absolute silence).

Graphs per connection show packets and packet loss, jitter, packet time delta, MOS, R value and the max audio level of client and server over time.
A PCAP button allows for PCAP capturing. If a proper codec is used, audio capture buttons for both directions are available allowing downloads in MP3 format.
Following codecs are supported for audio extraction:

* G.711 A-Law and μ-Law
* G.722
* G.729

==== Ping/Traceroute ====

A traceroute to the IP can be started or updated by clicking the Traceroute/Update button. Available traceroute data is shown in a table, containing details of each discovered network hop.
The following hop information may be displayed:

* IP address
* host name
* round trip time (average, minimum, maximum)
* rate of received responses to sent requests
* dropped packets count
* country
* city
* link to watch the location in online map services Google Maps or OpenStreetMaps

A button is available to easily navigate to the traceroute configuration section.

=== IP connection details ===
The connection detail view shows connection information in a single page. The view can be accessed in the list of IP connection (or the global connection list) by clicking on the magnifying glass symbol in the client IP column.

The page shows all data in a tabular format as well all graphs that are available for the connection.

A capture button at the right hand side can be used to capture packets of that connection.

The zoom button select the time range in which the connection was active.

For TCP connections a [[TCP flow chart]] can be calculated by clicking on the corresponding button:
[[File:TCP flow graph start.png|none|thumb|614x614px|Start TCP flow graph analysis]]See also [[IP connection details]].

== Configuration settings ==

By clicking on the gear button on the top right of the IP statistics web page, you can access the configuration section.

* Store connection information for every IP This option is enabled by default.
:When enabled, the IP measurement module stores every connection for each IP.
:This includes historical packet counter so you can see for individual connection at which time the connection transferred which amount of data.
:Connection data will be stored as long as possible regarding the total memory usage.
:Disabling this option will increase the minimum storage time significantly.

* Store layer 7 protocol information for every IP The network protocols and their historical traffic data is stored for each IP if this option is enabled.
:Disabling this option will increase the minimum storage time slightly.

* Track number of new connections for every IP
:When This option is enabled, TCP connections per IP will be tracked.
:Connections are divided into valid and invalid connections for server and client direction and the amount is shown.
:Disabling this option will increase the minimum storage time slightly.

* Store traffic history graph for IP peers
:This option allows enabling or disabling the traffic history graph that is shown per peer in the '''Peers''' tab for an IP.
:Disabling this option will increase the minimum storage time slightly.

* Store RTP performance information per IP and connection
:This option allows enabling or disabling of RTP related statistics that are shown in the '''RTP statistics''' tab for an IP.
:Jitter, packet time delta and MOS calculation in the [[SIP_module|SIP module]] also depends on this switch since it partially shows information stored at the IP address of RTP senders/receivers.
:Disabling this option will reduce the memory utilization and therefor increase the minimum storage time slightly.

* Store QoS information for every IP
:This option enables or disables to storage of Quality of Service information per IP.
:These information require additional memory so if these information are not necessary, memory can be save to increase global data storage time.

* Store SSL/TLS information for every connection
:This option enables or disables to storage of SSL/TLS information per IP. This includes used and announced
:encryption ciphers which can take additional memory per IP connection. If these information are not necessary, memory can be save to increase global data storage time.

* Store detailed TCP statistics for every connection
:This option allows to store detailed TCP statistics per connection, such as TCP retransmissions or TCP response time. The graph type can be selected in the IP connection tab to access these information.

* Maximum number of IP groups
:This option configures how many IP groups can be defined. The minimum (and default) value is 32 IP groups.
:The maximum value is 65535 IP groups. A new configuration value only takes effect after restarting the packet processing in the Administration menu.

* Maximum number of HTTP requests per connection
:This options configures how many HTTP request/response tuples are stored by default. The default is 1.
:On global and IP detail connection page it is possible to download CSV file with either the last or all HTTP request/responses per connection. In the latter case each connection line is duplicated with another HTTP request/response in chronological order.

TCP application time

2024-08-09T13:25:07Z

Ralf: Created page with "== Overview == The TCP module measures applications times by monitoring TCP transactions to indicate, if a server takes too long to answer, or takes too long to transfer its response, and similar application problems. TCP application time results == Description of measured data == === Definition of values === {| class="wikitable" |+ !Value !Description |- |Transaction |A transaction is defined as a sequence..."

== Overview ==
The TCP module measures applications times by monitoring TCP transactions to indicate, if a server takes too long to answer, or takes too long to transfer its response, and similar application problems.
[[File:TCP module application times.png|none|thumb|871x871px|TCP application time results]]

== Description of measured data ==

=== Definition of values ===
{| class="wikitable"
|+
!Value
!Description
|-
|Transaction
|A transaction is defined as a sequence of TCP data packets sent by the client, followed by a sequence of TCP data packets sent as a response by the server.
Each change in direction "Client -> Server -> Client" is considered one transaction.
|-
|Data transfer time
|This is the amount of time took to transfer all consecutive TCP data packets as part of the TCP transaction in either client or server direction.
Note, that there is no duration for transactions with only a single TCP data packet for a transaction direction.
|-
|First data response time
|This time describes how long the server took to send the first data packet as a response to client request.
|-
|Total request response transfer time
|This time is sum of the client data transfer, the first data response time, and the server data transfer time.
|}

=== Measured values ===

* For individual connections, each transaction "Client request, Server response" is measured. Each connection stores:
** Number of transactions
** Maximum time for client data transfer
** Maximum time for first data response of the server
** Maximum time for server data transfer
** Maximum time for the total request response transfer time
* Each IP aggregates the per connection values:
** Number of transactions executed as a client of a transaction
** Number of transactions executed as a server of a transaction
** Duration of the data transfers as a client
** Duration of the data transfers as a server
** The first data response time when acting as a server
** Duration of the total request response transfer

== Web interface ==
The TCP application time results can be found in multiple places depending on the context.

# [[TCP module|L4 TCP statistics]]In this module, the list of IP addresses is shown with their TCP application time values, including various graphs for historical values
# [[IP module#IP addresses tab|IP list]]The IP list can show the TCP application times as well by enabling the corresponding column
# [[IP module#TCP statistics|IP details]]The TCP tab in the IP details page for a specific IP shows all available data in one place.
# [[IP module#Connections tab|IP connection]]The IP connection list also shows the application time values for each individual connection, summarized as a maximum of each value in case multiple transactions happen within a connection

== Limitations ==

# The TCP application time is only measured for TCP connections with TCP handshake. That means, connections for which no handshake has been seen, no results are available.
# Data transfer times can only be measured for at least two consecutive data packets. So for single packet request/responses, no data transfer time is available, yet the total request response time will still cover the whole time between request and response.

Back-in-Time functionality

2024-08-08T10:49:50Z

Ralf:

Back-in-Time functionality

2024-08-08T10:45:38Z

Ralf:

Longterm DB

2024-08-06T07:22:24Z

Ralf:

==Description==
The Longterm DB feature (in firmware >= 4.3) uses an attached storage devices to store traffic information of IP addresses with low resolution for a much longer time than the live statistics.

The stored data comprises the IP addresses and their traffic data in graphical representation with 5 minutes resolution.

The storage is used similar to a swap file mechanism so the longterm data is not kept between restart unless the [[DB persistence]] feature is enabled too, which is recommended when using the longterm feature. To reduce the amount of time to dump/restore, the DB persistence configuration allow to skip storing live data.

==Usage==
[[File:Longterm DB dashboard.png|alt=Longterm DB activated dashboard|thumb|Longterm DB activated dashboard]]If this feature is enabled, a view toggle button appears in the top menu bar. This button allows to switch between the "LIVE" view and the longterm ("LT") view.

In the longterm view, the IP address information contain only information about the traffic amount in 5 minute resolution.

Other data is still shown if available from the live data base. To highlight the difference, the live graphs are shown in light gray background (and a larger gray background indicates the limit of back-in-time view in the live data).

The example screenshot to the right shows the differences. The IP addresses are available for multiple days, while the MAC address and L7 protocol data comes from the live data and is only available for a few hours.

Having both data views available at the same time helps to navigate through the time and directly see which kind of data is available.

==Setting==
The configuration can be found in the global settings page in the "Longterm DB" tab.

To enable this feature, select a storage device to be used, enable the feature and enter a file size.

It is recommended to also enable the [[DB persistence]] feature to be able to save and restore the longterm DB data during restarts.

Once enabled, the utilization of the file is shown and the [[System Info Page]] contains information about how long the data can be kept.

Tip: Since the amount of information stored in the longterm DB is limited by the graph resolution, the file size usually don't need to be similar sized as the main memory. 10 GByte is a good starting point.

The size can be increase but it requires a restart of the packet processing.

[[File:Longterm db settings.png|thumb|Longterm DB settings]]

== Notes ==
Recommended storage device types:
{| class="wikitable"
|+
!Storage device
!Note
|-
|NMVe based SSD
|recommended
|-
|SATA based SSD
|can be used for moderate traffic, check system load for high system utilization
|-
|USB based SSD
|not recommended, but might be useful for small systems (Allegro 200/500)
|-
|HDD
|not recommended, should not be used
|}
It is also not recommended to place the longterm DB on the same storage device that is used a packet ring buffer as it will deteriorate the performance of both features.

== Limitations ==

# The data in the longterm DB comprises the following information:
## IP addresses
### activity time
### traffic graph in 5 minute resolution
# The data is written into the longterm DB in variable intervals depending on traffic and system load. It takes up to 10 minutes (two graph intervals) until the data appears in the graph. Therefore, the last 5-10 minutes appear empty or with less traffic than in live view.

Main Page

2024-08-06T06:54:02Z

Ralf:

__NOTOC__
{|
|[[Image:Combination mark transparent.png|300px|link=https://www.allegro-packets.com]]      
|-
|'''This is the Allegro Network Multimeter manual. Please visit the website of [https://allegro-packets.com Allegro Packets] for more information about the product.'''
|}

{| class="wikitable" style="color:black; background-color:#ffdda3;"
|Translation: Document language is English, but you can use [https://translate.google.com/translate?u=allegro-packets.com/wiki automatic Google translation] into your language!
|}

<div class="mainpage_row">
<div class="mainpage_box">
=== Installation ===
* [[Generic Allegro Network Multimeter installation|Generic Allegro Network Multimeter installation guides]]
* Additional installation notes for specific devices:
** [[Allegro 200 series]]
* [[Management interface settings|Configure Management IP address]]
* [[IPMI KVM on Allegro series 1000+]]
* [[User Management|Multi users and permissions]]
* [[Firmware update]]
* [[Performing a factory reset or configuration reset]]
</div>
<div class="mainpage_box">

=== Typical Installation Setups ===
* [[In-Line Installation|In-Line Installation Guide]]
* [[Mirror Port, TAP and Packet Broker Installation|Mirror Port, TAP and Packet Broker Installation Guide]]
* [[ERSPAN Installation|ERSPAN Installation Guide]]
* [[VMWare Workstation Player/Pro Installation Guide]]
* [[VMWare ESXI Installation Guide]]
* [[Hyper-V Installation Guide]]
</div>
<div class="mainpage_box">
=== Configuration Guides ===
* [[Ring Buffer Configuration Guide]] <br/> ( Single Storage Device, Multiple Disks,... )
* [[Parallel packet processing|Parallel Packet Processing Configuration Guide]]
* [[Virtual Link Group Configuration Guide]]
* [[Multi-device settings|Multi-Allegro Configuration]]

* [[Performance Optimization Guide]]
</div>
</div>

<div class="mainpage_row">
<div class="mainpage_box">

=== Web Interface / Dashboard Manual ===
* [[Introduction]]
* [[Quickstart]]
* [[Usage]]
* [[Measurement modules]]
* [[Info Menu]]
* [[Settings]]
* [[User Profile Settings]]
* [[FAQ|FAQ - Frequently Asked Questions]]
* [[Error descriptions]]
* [[Feature documentation]]
* [[Reports]]
* [[Speedtest]]
</div>
<div class="mainpage_box">

=== Use Cases ===
* [[Investigate Network Load ]]
* [[Forensic pcap Analysis ]]
* [[Find Profinet problems]]
* [[Network Burst Analysis]]
* [[Burst analysis on a Mirror or Packet Broker input]]
* [[Capturing]]
* [[Analyze connections between remote sites]]
* [[Debugging Skype Traffic|Troubleshooting Microsoft Teams and Skype]]
* [[USB Presenter Capture]]
* [[VoIP monitoring and troubleshooting]]
* [[Generic troubleshooting processes|Generic troubleshooting process]]
* [[Process traffic capture from remote device]]
</div>
<div class="mainpage_box">

=== Data export and third-party tools===
* [[REST API description]]
*[[Statistics Export via POST]]
*[[SNMP]]
*[[NetFlow/IPFIX interface]]
*[[Public limited statistics]]
</div>
</div>

<div class="mainpage_row">
<div class="mainpage_box">

===Remote access===

*[[Using the Allegro Remote Service]]
*[[Self-hosted SSH Proxy]]
</div>
<div class="mainpage_box">
===Settings ===

*[[ Global settings]]
*[[ Module settings]]
* [[ User defined names]]
* [[ Management interface settings]]
*[[ Multi-device settings]]
*[[ Virtual_Link_Group_functionality | Virtual link groups]]
*[[ Administration]]
*[[ Ingress filter]]
* [[ Remote access and export]]
* [[WiFi]]
*[[ User Management]]
*[[ Firmware update]]
*[[ License upload]]
</div>
<div class="mainpage_box">

===Getting support===

*[[Reaching Allegro Packets Support]]
*[[Reporting Bugs]]
</div>
</div>

<div class="mainpage_row">
<div class="mainpage_box">

===Support of third-party hardware===

*[[List of Supported Transceiver Modules]]
*[[Supported Storage Devices for x300/x400/x500 Series]]
</div>
<div class="mainpage_box">

===Additional resources===
*[[Device icons|Pictograms/Icons/Stencils for all Allegro models]]
*[[Supported protocols]]
</div>
</div>

Process traffic capture from remote device

2024-08-06T06:52:55Z

Ralf:

Process traffic capture from remote device

2024-08-06T06:51:58Z

Ralf:

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.

{| 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

==Remote capture via ERSPAN==

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 123 1.2.3.4
In this mode, the [[ERSPAN Installation|endpopint mode for ERSPAN]] must be enabled and configured for the same IP as used in the ap_capture_to_remote command line argument.

Note that the IP address used is NOT the address or name of the management, but the separate IP address that is only valid on the interface for which the endpoint mode is configured.

__FORCETOC__

Process traffic capture from remote device

2024-08-06T06:51:24Z

Ralf:

Process traffic capture from remote device

2024-08-06T06:48:58Z

Ralf:

Main Page

2024-08-05T11:34:59Z

Ralf:

__NOTOC__
{|
|[[Image:Combination mark transparent.png|300px|link=https://www.allegro-packets.com]]      
|-
|'''This is the Allegro Network Multimeter manual. Please visit the website of [https://allegro-packets.com Allegro Packets] for more information about the product.'''
|}

{| class="wikitable" style="color:black; background-color:#ffdda3;"
|Translation: Document language is English, but you can use [https://translate.google.com/translate?u=allegro-packets.com/wiki automatic Google translation] into your language!
|}

<div class="mainpage_row">
<div class="mainpage_box">
=== Installation ===
* [[Generic Allegro Network Multimeter installation|Generic Allegro Network Multimeter installation guides]]
* Additional installation notes for specific devices:
** [[Allegro 200 series]]
* [[Management interface settings|Configure Management IP address]]
* [[IPMI KVM on Allegro series 1000+]]
* [[User Management|Multi users and permissions]]
* [[Firmware update]]
* [[Performing a factory reset or configuration reset]]
</div>
<div class="mainpage_box">

=== Typical Installation Setups ===
* [[In-Line Installation|In-Line Installation Guide]]
* [[Mirror Port, TAP and Packet Broker Installation|Mirror Port, TAP and Packet Broker Installation Guide]]
* [[ERSPAN Installation|ERSPAN Installation Guide]]
* [[VMWare Workstation Player/Pro Installation Guide]]
* [[VMWare ESXI Installation Guide]]
* [[Hyper-V Installation Guide]]
</div>
<div class="mainpage_box">
=== Configuration Guides ===
* [[Ring Buffer Configuration Guide]] <br/> ( Single Storage Device, Multiple Disks,... )
* [[Parallel packet processing|Parallel Packet Processing Configuration Guide]]
* [[Virtual Link Group Configuration Guide]]
* [[Multi-device settings|Multi-Allegro Configuration]]

* [[Performance Optimization Guide]]
</div>
</div>

<div class="mainpage_row">
<div class="mainpage_box">

=== Web Interface / Dashboard Manual ===
* [[Introduction]]
* [[Quickstart]]
* [[Usage]]
* [[Measurement modules]]
* [[Info Menu]]
* [[Settings]]
* [[User Profile Settings]]
* [[FAQ|FAQ - Frequently Asked Questions]]
* [[Error descriptions]]
* [[Feature documentation]]
* [[Reports]]
* [[Speedtest]]
</div>
<div class="mainpage_box">

=== Use Cases ===
* [[Investigate Network Load ]]
* [[Forensic pcap Analysis ]]
* [[Find Profinet problems]]
* [[Network Burst Analysis]]
* [[Burst analysis on a Mirror or Packet Broker input]]
* [[Capturing]]
* [[Analyze connections between remote sites]]
* [[Debugging Skype Traffic|Troubleshooting Microsoft Teams and Skype]]
* [[USB Presenter Capture]]
* [[VoIP monitoring and troubleshooting]]
* [[Generic troubleshooting processes|Generic troubleshooting process]]
</div>
<div class="mainpage_box">

=== Data export and third-party tools===
* [[REST API description]]
*[[Statistics Export via POST]]
*[[SNMP]]
*[[NetFlow/IPFIX interface]]
*[[Public limited statistics]]
</div>
</div>

<div class="mainpage_row">
<div class="mainpage_box">

===Remote access===

*[[Using the Allegro Remote Service]]
*[[Self-hosted SSH Proxy]]
</div>
<div class="mainpage_box">
===Settings ===

*[[ Global settings]]
*[[ Module settings]]
* [[ User defined names]]
* [[ Management interface settings]]
*[[ Multi-device settings]]
*[[ Virtual_Link_Group_functionality | Virtual link groups]]
*[[ Administration]]
*[[ Ingress filter]]
* [[ Remote access and export]]
* [[WiFi]]
*[[ User Management]]
*[[ Firmware update]]
*[[ License upload]]
</div>
<div class="mainpage_box">

===Getting support===

*[[Reaching Allegro Packets Support]]
*[[Reporting Bugs]]
</div>
</div>

<div class="mainpage_row">
<div class="mainpage_box">

===Support of third-party hardware===

*[[List of Supported Transceiver Modules]]
*[[Supported Storage Devices for x300/x400/x500 Series]]
</div>
<div class="mainpage_box">

===Additional resources===
*[[Device icons|Pictograms/Icons/Stencils for all Allegro models]]
*[[Supported protocols]]
</div>
</div>

System Info Page

2024-08-05T11:34:27Z

Ralf: Ralf moved page System Info Page to Info Menu

#REDIRECT [[Info Menu]]