Allegro Network Multimeter Manual - User contributions [en]

Using the Allegro Remote Service

2022-09-01T09:20:24Z

Mark:

=== Allegro Remote Service ===

The Allegro Remote Service is a public Internet server provided by Allegro Packets which uses the same [[Self-hosted SSH Proxy|SSH Port Forwarding feature]] that can also be used for private servers.

The advantage of using this service is that it enables the Allegro Network Multimeter to be accessed from anywhere in the world without requiring additional services.

When enabled, a unique URL is generated that can be used to access the Allegro Network Multimeter. The traffic is still SSL encrypted with the certificate installed on the device but you must ensure a secure password is used for the accounts on the Allegro Network Multimeter, since by using the URL anyone can contact the device.

The Allegro Remote Service is a transparent proxy which does not terminate the SSL connection. The certificate presented to your browser is the same that is configured on the Allegro Network Multimeter.

==== Configuration ====

To use the Allegro Remote Service, enter the menu "Settings -> Remote access & export ".

You can see the current status and enable the service by toggling the button.

[[File:Allegro Remote Access.jpg|frameless|900x900px]]

Optionally, it is possible to restrict access by specifying subnets which are allowed to access the Allegro Network Multimeter.

Save the settings and a unique URL will be presented which can be accessed via the Internet.

Global settings

2022-08-18T07:45:23Z

Mark:

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

== Generic settings ==

=== Packet processing mode ===

This section allows for configuring the main packet processing mode:

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

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

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

The packet processing mode can be changed during runtime.

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

=== Endpoint mode ===

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

* Ethernet packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address. The system will process the packets as if only the inner encapsulated packet is seen and any traffic captures will only contain the encapsulated packet.
* UDP packets to specific port (packets will be analyzed as is).

An interface with endpoint mode enabled will respond to ARP requests and to ICMP echo requests so it is possible to use ping to verify that the interface is reachable under the configured IP address.

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

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

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

=== Webshark support ===

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

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

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

Changing Webshark parameters requires a restart of the processing.

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

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

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

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

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

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

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

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

=== PCAP parallel analysis ===

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

== IPFIX settings ==

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

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

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

== Time settings ==

The 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 GPS-capable PTP grandmaster card is available, 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.

'''GPS''' - The GPS time retrieval option will become available when a GPS capable PTP grandmaster 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.

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.

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

==Memory extension (BETA)==

See [[Memory extension]] for details about this beta 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 VXLAN, ERSPAN type II and type III, GENEVE, CAPWAP as well as L2TPv3 data traffic. In this mode all non-encapsulated traffic will be discarded. On the Dashboard a dropped counter will display dropped non-encapsulated packets for indication if this mode is active. The Allegro Network Multimeter will show the encapsulated content in all analysis modules. 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 a 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.

=== 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, only the Arista timestamp format is supported. If this option is enabled, 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.

Global settings

2022-08-18T07:44:47Z

Mark:

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

== Generic settings ==

=== Packet processing mode ===

This section allows for configuring the main packet processing mode:

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

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

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

The packet processing mode can be changed during runtime.

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

=== Endpoint mode ===

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

* Ethernet packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address. The system will process the packets as if only the inner encapsulated packet is seen and any traffic captures will only contain the encapsulated packet.
* UDP packets to specific port (packets will be analyzed as is).

An interface with endpoint mode enabled will respond to ARP requests and to ICMP echo requests so it is possible to use ping to verify that the interface is reachable under the configured IP address.

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

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

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

=== Webshark support ===

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

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

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

Changing Webshark parameters requires a restart of the processing.

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

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

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

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

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

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

Here are some examples for reference on a Allegro Network Multimeter 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 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 GPS-capable PTP grandmaster card is available, 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.

'''GPS''' - The GPS time retrieval option will become available when a GPS capable PTP grandmaster 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.

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.

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

==Memory extension (BETA)==

See [[Memory extension]] for details about this beta 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 VXLAN, ERSPAN type II and type III, GENEVE, CAPWAP as well as L2TPv3 data traffic. In this mode all non-encapsulated traffic will be discarded. On the Dashboard a dropped counter will display dropped non-encapsulated packets for indication if this mode is active. The Allegro Network Multimeter will show the encapsulated content in all analysis modules. 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 a 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.

=== 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, only the Arista timestamp format is supported. If this option is enabled, 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.

Parallel packet processing

2022-08-18T07:38:17Z

Mark:

== What is '''parallel packet processing?''' ==

The '''parallel packet processing''' mode allows you to analyze historic packets in parallel to the live analytics on one Allegro Network Multimeter. The Allegro Network Multimeter supports '''pcap files''' and '''packet''' '''ring buffers''' as input for the '''parallel packet processing'''.

== How can I configure '''parallel packet processing?''' ==

You can enable '''parallel packet processing''' at '''Settings''' → '''Global settings''' → '''PCAP parallel analysis'''. This mode has 3 options:

* Globally enable/disable this mode
* Reserved memory in percentage of main memory ( default 10 percent )
* Number of offline analysis slots ( default 1 )

[[File:Parallel pcap processing configuration.png|border|400px]]

Allegro Packets recommends you to enable parallel packet processing with default values and restart the processing. Please be aware that your current measurement will be lost when restarting the processing.

== How can I use '''parallel packet processing?''' ==

=== pcap upload ===

Once you have enabled this feature and restarted the processing, you can use it by uploading a pcap file at '''Generic''' → '''PCAP analysis'''. Please select a pcap file here.

[[File:Pcap Analysis before start.png|800px]]

Once a file is selected and you press '''Analyze pcap''', the following pop-up will appear:

[[File:Pcap Analysis dialoge.png|400px]]

The Option '''Use a packet buffer...''' will store a temporary second packet ring buffer on the storage device to allow pcap extraction after the pcap upload. This option is only available if there is a storage device attached.

Once you click OK, the file will be uploaded and analyzed immediately. If the upload is complete, you will see the following dialogue

[[File:Pcap Analysis upload succesful.png|400px]]

To switch between the pcap and the live analysis, use the selector in the top menu.

[[File:Pcap Analysis selector.png|border|300px]]

The Allegro Network Multimeter will keep the replay open even if you close the browser session. You can terminate the pcap replay session at the dashboard:

[[File:Pcap Analysis dashboard.png|border|900px]]

=== '''Packet ring buffer analysis''' ===

The packet ring buffer analysis works similar to the pcap upload, except that a part or the total packet ring buffer is used. Please navigate to the packet ring buffer statistics at '''Generic''' → '''Packet ring buffer'''. Select a time which shall be re-analyzed.

[[File:Ring buffer Analysis button.png|border|900px]]

Then press the button '''Analyze packet ring buffer''' below the graphs and the following dialogue will appear.

[[File:Ring buffer Analysis dialogue.png|border|500px]]

Here you can select the replay slot. Once the replay is started, you can proceed like the pcap upload and select the replay and terminate it on the dashboard.

Reaching Allegro Packets Support

2022-08-18T07:35:15Z

Mark:

== How to get Allegro Packets hardware or software support ==

The Allegro Packets Support can be reached via email or phone by filling out the support form at [http://www.allegro-packets.com/support Allegro Packets Support].

=== Necessary information ===

We may ask you for additional information if necessary:

* We need the ''SystemID'' to identify your appliance. You can find this information in the menu "Info -> System info".
* If you experience a crash, a special crash log is generated that helps us to identify and fix the problem. See also [[Reporting Bugs]].
* Often we need a file "debuginfo.zip" which is available at the menu "Info -> Status". It contains multiple internal log files for different components and the current configuration (without sensitive data).
* If the question or problem is related to specific network traffic, it can help if you create a small capture for the traffic if possible and share that trace file with us. We will give detailed information about how to obtain the capture.

Using the Allegro Remote Service

2022-08-18T07:33:51Z

Mark:

=== Allegro Packets Remote Service ===

The Allegro Packets Remote Service is a public Internet server provided by Allegro Packets which uses the same [[Self-hosted SSH Proxy|SSH Port Forwarding feature]] that can also be used for private servers.

The advantage of using this service is that it enables the Allegro Network Multimeter to be accessed from anywhere in the world without requiring additional services.

When enabled, a unique URL is generated that can be used to access the Allegro Network Multimeter. The traffic is still SSL encrypted with the certificate installed on the device but you must ensure a secure password is used for the accounts on the Allegro Network Multimeter, since by using the URL anyone can contact the device.

The Allegro Packets Remote Service is a transparent proxy which does not terminate the SSL connection. The certificate presented to your browser is the same that is configured on the Allegro Network Multimeter.

==== Configuration ====

To use the Allegro Packets Remote Service, enter the menu "Settings -> Remote access & export ".

You can see the current status and enable the service by toggling the button.

[[File:Allegro Remote Access.jpg|frameless|900x900px]]

Optionally, it is possible to restrict access by specifying subnets which are allowed to access the Allegro Network Multimeter.

Save the settings and a unique URL will be presented which can be accessed via the Internet.

Using the Allegro Remote Service

2022-08-18T07:32:23Z

Mark:

=== Allegro Packets Remote Service ===

The Allegro Remote Service is a public Internet server provided by Allegro Packets which uses the same [[Self-hosted SSH Proxy|SSH Port Forwarding feature]] that can also be used for private servers.

The advantage of using this service is that it enables the Allegro Network Multimeter to be accessed from anywhere in the world without requiring additional services.

When enabled, a unique URL is generated that can be used to access the Allegro Network Multimeter. The traffic is still SSL encrypted with the certificate installed on the device but you must ensure a secure password is used for the accounts on the Allegro Network Multimeter, since by using the URL anyone can contact the device.

The Allegro Remote Service is a transparent proxy which does not terminate the SSL connection. The certificate presented to your browser is the same that is configured on the Allegro Network Multimeter.

==== Configuration ====

To use the Allegro Remote Service, enter the menu "Settings -> Remote access & export ".

You can see the current status and enable the service by toggling the button.

[[File:Allegro Remote Access.jpg|frameless|900x900px]]

Optionally, it is possible to restrict access by specifying subnets which are allowed to access the Allegro Network Multimeter.

Save the settings and a unique URL will be presented which can be accessed via the Internet.

Complex filter

2022-05-12T10:41:04Z

Mark:

In different features such as the [[Capture module]] or the overview of the [[SIP module]] the Allegro Network Multimeter allows to use a diverse set of filters.
One of these filters is the complex or expert filter which allows to filter in a more complex way.

The filter are described in a C-Style-Syntax and support a combination with AND and OR operators, precedence order with parentheses and equal/not equal comparisons.
If more than one filter-type is supported in a text field (for example in a table-view) the complex filter has to be enclosed by parentheses.
If the filter expression can be evaluated to true, the packet gets captured, the connection is displayed and so on.

If a value contains a space, the whole value must be quoted with ".

== Combination Operators ==

Following operators are supported:
{| class="wikitable"
|+
!Operator
!Description
|-
|and, &&
|AND operator. The filter expression will match if all operands could be evaluated to true.
|-
|<nowiki>or, ||</nowiki>
|OR operator. The filter expression will match if any operand can be evaluated to true.
|}

== Comparison Operators ==

The following comparison operators are overall supported but not in every feature:
{| class="wikitable"
|+
!Operator
!Description
|-
|<nowiki>==</nowiki>, eq
|Will evaluate expression to true if left and right operand are equal.
|-
|!=, ne
|Will evaluate expression to true if left and right operand are not equal.
|-
|<nowiki>===</nowiki>
|Will evaluate expression to true if left and right operand are exact equal.
|-
|<=
|Will evaluate expression to true if left operad is less or equal to the right operand.
|-
|<
|Will evaluate expression to true if left operad is less than the right operand.
|-
|>=
|Will evaluate expression to true if left operad is more or equal to the right operand.
|-
|>
|Will evaluate expression to true if left operad is more than the right operand.
|-
|~
|Will evaluate expression to true if left and right operand are approximately equal.
|}

== Operands and Example ==

The operands depend on the feature where you want to use it.

Example from the [[Capture module]]:
* '''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-
|-
|}

Parallel packet processing

2022-05-12T10:40:25Z

Mark:

== What is '''parallel packet processing?''' ==

The '''parallel packet processing''' mode allows you to analyze historic packets in parallel to the live analytics on one Allegro Network Multimeter. The Allegro Network Multimeter supports '''pcap files''' and '''ring buffers''' as input for the '''parallel packet processing'''.

== How can I configure '''parallel packet processing?''' ==

You can enable '''parallel packet processing''' at '''Settings''' → '''Global settings''' → '''PCAP parallel analysis'''. This mode has 3 options:

* Globally enable/disable this mode
* Reserved memory in percentage of main memory ( default 10 percent )
* Number of offline analysis slots ( default 1 )

[[File:Parallel pcap processing configuration.png|border|400px]]

Allegro Packets recommends you to enable parallel packet processing with default values and restart the processing. Please be aware that your current measurement will be lost when restarting the processing.

== How can I use '''parallel packet processing?''' ==

=== pcap upload ===

Once you have enabled this feature and restarted the processing, you can use it by uploading a pcap file at '''Generic''' → '''PCAP analysis'''. Please select a pcap file here.

[[File:Pcap Analysis before start.png|800px]]

Once a file is selected and you press '''Analyze pcap''', the following pop-up will appear:

[[File:Pcap Analysis dialoge.png|400px]]

The Option '''Use a packet buffer...''' will store a temporary second ring buffer on the storage device to allow pcap extraction after the pcap upload. This option is only available if there is a storage device attached.

Once you click OK, the file will be uploaded and analyzed immediately. If the upload is complete, you will see the following dialogue

[[File:Pcap Analysis upload succesful.png|400px]]

To switch between the pcap and the live analysis, use the selector in the top menu.

[[File:Pcap Analysis selector.png|border|300px]]

The Allegro Network Multimeter will keep the replay open even if you close the browser session. You can terminate the pcap replay session at the dashboard:

[[File:Pcap Analysis dashboard.png|border|900px]]

=== '''Ring buffer analysis''' ===

The ring buffer analysis works similar to the pcap upload, except that a part or the total ring buffer is used. Please navigate to the ring buffer statistics at '''Generic''' → '''Packet ring buffer'''. Select a time which shall be re-analyzed.

[[File:Ring buffer Analysis button.png|border|900px]]

Then press the button '''Analyze packet ring buffer''' below the graphs and the following dialogue will appear.

[[File:Ring buffer Analysis dialogue.png|border|500px]]

Here you can select the replay slot. Once the replay is started, you can proceed like the pcap upload and select the replay and terminate it on the dashboard.

IP module

2022-05-05T07:00:55Z

Mark:

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:

* Alternative names
:The names are gathered from different data sources. If known, the DNS name is shown first. Secondly, there can be the DHCP name as announced by the system itself. Thirdly, the name of the vendor of the network card of the system using the IP address is shown as well.
:These three names allow to easily identify the system behind an IP address.
:The name information are also used when filtering the table for some entered string.

* First (recent) activity
:This column shows the time of first activity of an IP address after some long inactivity period. This columns can be sorted to see the IP addresses that are active in the recent past.

* Last activity
:The last activity of an IP is the time of the last packet for that IP.

* Packets and Bytes
:This is the number of packets and bytes, sent by the IP address as a blue arrow up, and the received packets and bytes as a yellow arrow down.

* Packets/s and Bit/s
:These both numbers describe the current throughput of this IP address.

* 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
:The graph column shows the history graph of the traffic for each IP address. It shows the timestamp on the x-axis and the bytes on the y-axis. The resolution can be changed by using the control buttons on the top of the web page. The graph icon allows for selecting different graph types such as load (bps or packets/s), TCP statistics or connections.

* PCAP
:It is possible to download the traffic of an IP address by clicking on the 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.

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

* The table lists the client and server side and shows the IP address, port, and corresponding country of that IP.

* The maximum transmission unit (i.e. layer 2 payload) is calculated for both directions. The maximum values of the connection are displayed in the '''MTU''' column.

* The layer 4 protocol is the protocol of the layer 4 protocol used (TCP, UDP, or others).

* The start time is the time of the first packet for that connection, while the last activity column shows the time of the last packet seen so far for the connection. It is possible to sort for both fields to see the most recent active connections.

* The number of packets and bytes as well as the current throughput is shown too.

* The DPI protocol column shows the detect layer 7 protocol.

* The Response time column contains response times for TCP and 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.

* The TCP retransmissions columns 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.

* The TCP missed data column shows the estimated amount of TCP data not seen for this connection. See [[TCP module#Missed data|TCP module]] for details about missed data.

* The TCP flags column show 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.

* The TCP max window size columns show the size of the biggest TCP receive window announced for each direction of a connection.

* The TCP max used window size columns 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.

* The TCP window usage columns show the ratio of the TCP max window size compared to the actual max used window size.

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

* The TCP window limit usage columns show the ratio of the TCP max window size values compared to the TCP window size limit values in percent.

* The Client announced and negotiated TLS version and cipher suites columns 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.

* The column 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.

* The columns VLANs and Interfaces shows which VLAN tags has been seen for a specific connection and 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.

* The column PPPoE 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.

* The column MPLS 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.

* The column 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.

* The column Graph shows the historical throughput for each connection. In Firmware >= 3.3, it is also possible to select the displayed graph from multiple different statistics. 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).

* A PCAP button allows for capturing the specific connection.

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 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 IP addresses and ports. The RTP payload type is shown as well as timing informations and counters, jitter and MOS 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, MOS 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

=== IP connection details ===
In firmware version 3.4, a connection detail view has been added to show 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.

Since firmware version 3.5, for TCP connection 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]]

== Configuration settings ==

By clicking on the gear button on the top left 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 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 (Firmware >= 3.3)
: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.

Packet ring buffer

2022-05-05T06:59:38Z

Mark:

== Packet ring buffer==
The ring buffer feature allows to create a buffer of fixed size on an external storage device to which all processed packets will be recorded.
If the fixed size buffer is full then the oldest packets in the buffer will be replaced with new packets in a round-robin fashion.
If the feature is not enabled, a button titled '''Create ring buffer''' is visible.
Upon clicking on it a dialogue will be displayed and allows you to specify the size of the ring buffer.
It must be ensured that enough space is available on the external storage device.
As soon as the ring buffer has been created, statistics about the ring buffer will be displayed instead of the button:

'''Web interface'''
{|class="wikitable sortable"
|-
|[[File:Create Packet ring buffer1.png|600px|none|right]]
|}
* Timestamp of oldest packet: The timestamp of the oldest packet in the ring buffer.

* Total size: The total size of the ring buffer on the external storage device.
:If the cluster packet ring buffer feature is active and the Write redundancy level is set to a different value than zero replication, an adjusted value is displayed to reflect the redundant copies of packet data.
:The raw on-disk value will be displayed next to it in parentheses.

* Used size: The currently used amount of memory in the capture buffer.
:If the cluster packet ring buffer feature is active and the Write redundancy level is set to a different value than zero replication, an adjusted value is displayed to reflect the redundant copies of packet data. The raw on-disk value will be displayed next to it in parentheses.
* Overall bytes captured since start: The amount of captured bytes since system start.
:This may be smaller than the used size if the system has been restarted. And it may be larger than the used size in case the ring buffer is full.
:The history graph shows the captured traffic of the last minute or in the selected interval (if set).
* Bytes dropped since start: The traffic which was processed but could not be written to the ring buffer since the start of processing.
:This is usually an indicator that writes to the external storage device were not fast enough. The history graph shows the drops over time.
* Bytes discarded due to snapshot length rules since start: The traffic which matched the snapshot length rules criteria and was not written to the ring buffer.
:The history graph shows discarding over time.
* Data in flight: The amount of data which is currently stored in the queue that holds processed packets before they are written to the packet ring buffer.
:If larger bursts of traffic need to be stored in this queue, the size can be modified in the capture module settings.

'''Web interface'''
{|class="wikitable sortable"
|-
|[[File:Create Packet ring buffer2.png|600px|none|right]]
|}

When the ring buffer is full and old packets are deleted, the graphs will show the time range with no data with a dark grey background colour.
The time range before start of the ring buffer will be visualized in the same way.
When the ring buffer is running, the behaviour of the pcap capture buttons throughout the system changes: if the user interface is in live mode and a capture is started, a dialogue will appear asking you to specify from how far back in time the capture should start.
This way it is possible to e.g. capture the traffic of an IP address starting from an hour ago.
The capture will also continue with live traffic.
If the user interface is in '''back-in-time''' mode (a timespan from the past is selected) starting a capture will produce a dialogue asking to confirm that the capture will cover exactly the timespan selected.
The capture will automatically stop after the selected timespan has been processed.

'''Web interface'''
{|class="wikitable sortable"
|-
|[[File:Create Packet ring buffer3.png|1200px|none|right]]
|}

==== Cluster ring buffer ====
The cluster ring buffer feature allows you to use multiple whole disks in parallel for a single packet ring buffer.
It also allows you to optionally write redundant copies of packets to multiple disks to provide fault tolerance in case of a disk failure.

It is also possible to create multiple cluster packet ring buffers that
run in parallel. To enable multiple cluster packet ring buffers, the
option `The maximum number of concurrent packet ring buffers` in the
capture module options can be set to the required number.

When clicking the '''Create cluster ring buffer''' button, an empty cluster ring buffer will be created and the '''Cluster configuration''' tab on the now visible packet ring buffer statistics page becomes available.

If multiple cluster packet ring buffers are used, the page will show
a number of buttons at the top to switch between the different clusters.
Each cluster has its own statistics and configuration.

In the Cluster configuration tab you can configure the '''Write redundancy level''' at the very top.
This level controls how many redundant copies of each packet are written.
No replication means that only a single copy of each packet is written and provides no redundancy.
This level gives the highest write bandwidth for a given number of disks; single replication means that one additional copy of each packet is written to some other disk and thus reduces the total write performance for a given number of disks to half the performance of no replication.
Double replication and triple replication writes two and three additional copies of each packet respectively.
Note that for each level to work there must be at least the number of replications + 1 disks available in the cluster.

'''Web interface'''
{|class="wikitable sortable"
|-
|[[File:Cluster3.png|600px|none|right]]
|}

Below the '''Write redundancy level''' setting is the list of all disks available for use in the cluster.
The following columns are displayed in the list:
* Disk: A description of the disk and its capacity.
* Enclosure: If the disk is part of a multi-disk enclosure this column will show the enclosure number along with the slot number.
* Status: If the disk has been added to the cluster this column will display the current status as '''ok''' or '''failed'''. If multiple cluster packet ring buffers are used this will also show if the disk is active in another cluster.
* Locator: For disks in a multi-disk enclosure the button displayed in this column allows to turn the slot locator LED on and off.

In the last unlabelled column, three buttons are displayed which have the following functionality:
* Add to cluster: Add a fresh disk to the cluster.
:The disk will be formatted and added as empty storage to the cluster. All previous data on the disk is lost.
* Resume in cluster: If the disk was previously part of a cluster it can be resumed.
:The data on that disk is now part of the packet ring buffer.
* Remove from cluster: Remove the disk from the ring buffer.
:The data stored on that disk is no longer part of the packet ring buffer but the data is not removed from the disk. It can be resumed in the cluster at a later time.

:If a disk is missing because it was e.g. removed from the enclosure, it will be displayed in a separate list with much of the information as in the list described above but only one button with the option to remove it from the cluster packet ring buffer.

'''Web interface'''
{|class="wikitable sortable"
|-
|[[File:Cluster4.png|1200px|none|right]]
|}

==== Packet ring buffer snapshot length filter ====
Rules can be configured to control the snapshot length of each packet which will be stored in the packet ring buffer.
These rules can also be used to prevent certain packets from being stored in the packet ring buffer.
This allows you to fine tune how much packet data needs to be written to the packet ring buffer.
The information about the original length of a packet will still be available in captures except when the packet was not written to the packet ring buffer at all (e.g. due to a '''discard''' rule).

These rules can be created, edited, deleted, moved up and moved down in the rules list by using the respective buttons.

Evaluation of the rules takes place in the order of the rules as displayed in the rules list from top to bottom.
The first rule that matches for a given packet will be applied and no further rules will be evaluated for that packet.
This means that the most generic rule should be at the bottom of the list (like e.g. ‘all packets will be discarded’) and more specific rules should be higher up in the list (like e.g ‘packets with an IP matching 192.168.1.0/24 will be fully captured’).

When creating a snapshot length filter rule, a dialogue is displayed and allows the following options:
* Rule condition: Specify which packets to match.

:The input field below allows entering the corresponding value.

:{| class="wikitable"
|-
! Rule condition
! description
|-
| All packets
| everything
|-
| MAC address
| source or destination MAC address
|-
| IP address
| source or destination IP address or subnet
|-
| TCP port
| the source or destination TCP port
|-
| UDP port
| the source or destination UDP port
|-
| Layer 7 protocol
| the selected Layer 7 protocol
|-
| outer VLAN tag
| the most outer VLAN tag (directly after Ethernet header). It is also possible to match packets that have no VLAN tag at all by choosing 'no VLAN' from the drop-down menu or match packets with an arbitrary VLAN tag by choosing 'any VLAN' form the drop-down menu.
|-
| interface
| the ingress interface the packet originated from
|-
| SIP phone number
|
The number matches part of the 'From:', 'To:', 'Request-URI', 'Contact', 'P-Asserted-Identity' or 'P-Preferred-Identity' entry in a SIP INVITE packet.
* only the part between '''<nowiki>'<'</nowiki>''' and '''<nowiki>'>'</nowiki>''' of the From/To line is tested.
* value '''<nowiki>'234'</nowiki>''' will match '<nowiki>From: "Caller1" <sip:234></nowiki>', but also '<nowiki>From: "Caller2" <sip:12345@test></nowiki>'
* to match from the start, use '''<nowiki>'sip:234'</nowiki>'''

Correlating SIP packets for the same Call-ID will match.

The RTP and RTCP packets correlated to this SIP call will also match.
|-
| Calls between SIP phone number A and B
| Match SIP, RTP and RTCP packets related to SIP phone calls between both numbers
|-
| virtual link group
| the virtual link group the packet belongs to
|-
|SSL after handshake
|SSL packets that occur after the SSL handshake (the encrypted part of the SSL communication)
|}

* Negate: Controls comparison of the rule condition to the value. If this is off, the value must match.
:If this is on, the value must not match.
* Action: What shall be done with the matching packets.
:{| class="wikitable"
|-
! Action !! Description
|-
| Snapshot length
| The packet is captured with a max length as specified in the input field below. If the packet is larger, the remaining bytes will be discarded.
|-
| Discard
| Discard the whole packet.
|-
| Full
| The entire packet is captured.
|-
| Header + data
|
Capture just certain parts of the packet.

When selecting '''L3 header''', Layer 2 and Layer 3 headers are stored.

When selecting '''L3 + L4 header''', Layer 2, 3 and 4 headers are stored.

When selecting '''L3 + L4 + L7 data''', an input field is shown where the length of Layer 7 data can be configured. In this case Layers 2, 3 and 4 are stored together with the specified amount of Layer 7 data.

|}

==== Analyzing the packet ring buffer ====
When the packet ring buffer is activated, it is possible to restart the packet processing core and analyze all packets contained in the packet ring buffer.
When the Analyze packet ring buffer button is pressed, a dialogue will appear which allows you to choose the time range of the packet ring buffer which is to be replayed.
After confirming this dialogue, the Allegro Network Multimeter will reset all statistics and start analyzing the contents of the packet ring buffer.
Progress, statistics and the option to resume normal operation will appear on the Packet ring buffer page.

==== Extracting the packet ring buffer ====
When the packet ring buffer is active, the entire contents can be extracted by capturing the complete timespan that is contained within.
For convenience, a button labelled Extract packet ring buffer is available that opens the capture dialogue with the start time and end time set to the appropriate values.

Capture module

2022-05-05T06:58:50Z

Mark:

==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 an 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 later might be used. The capture module page displays all currently running captures and allows starting new captures with specific filters.

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

=== Current captures ===
The first part of the page displays all downloads running for the current user session, and all downloads running for other user sessions (like when a download has been started outside the browser by directly using command line tools such as wget or curl).
The list contains the client IP and port of the user running the download. The next three counters describe the number of packets captured for the corresponding filter, the number of packets dropped by the capturing module, and the number of ignored packets. Packet drops happen when more packets are captured than can be transferred via HTTP to the client. Ignored packets do not match the given capture filter. The following columns list the applied filter criteria. The last column contains a button to stop the corresponding download. Downloads can also be stopped by clicking the same capture button that started the capture in the corresponding module. If multiple devices have been configured, the list also contains all captures from all multi-devices which can be stopped individually.

==== Recently captured ====
This list shows the most recently performed captures for the current user. The most recent capture is displayed on the top. Next to each capture there is a button to permanently save this capture as a favorite as well as a button to simply start this capture 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 captures''' 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 the 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 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 are always stored on the active storage device and thus will not function if no storage device is active.

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

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

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

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

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

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

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

ip == ff02::1:3

ip == 10.0/16

ip == 10.0.0.1:1234

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

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

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

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

* '''serverport''': A TCP or UDP port of a server. The packet is captured if the given port is a port of the server and not of a client.
:Example:
:{| class="wikitable sortable"
|-
| serverport == 80
|-
|}

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

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

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

* '''link''': The link pair of two interfaces as stated in Interface stats. A single link number can be given.
* '''ptpMsgType''': A specific PTP message type number or any for the whole PTP traffic.
* '''profinetFrameId''': A specific Profinet frame ID.
* '''profinetCmOpnum''': A specific operation number for Profinet CM (Context Manager) requests or responses. Can also be any for every operation number. Following values are used:
:#connect
:#release
:#read
:#write
:#control
:#read implicit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:*HTTP download
::This is the default method. The capture will start a HTTP download of a PCAP file directly in the browser.
:: Available HTTP download options:
::*Set file name: allow to configure a custom file name for the capture file
::*Download as zip archive: Download the capture file as a compressed zip archive '''[New in version 3.0]'''
:*Disk
::This method is only visible if a storage device is active and has some amount of free storage space. The capture will create a PCAP file on the 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.

*File name
:If browser download or disk storage has been chosen, 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DNS module

2022-05-05T06:57:50Z

Mark:

The DNS module tracks name lookup requests and responses to be able to present names for IP address without doing an active lookup.
This allows the Allegro Network Multimeter to do efficient passive name resolving.
The DNS module stores for each name the last IP that has been announced. Due to load balancing mechanisms in content delivery networks (or other setups) and virtual hosting, a name might be resolved to multiple IP addresses or a single IP address uses multiple names. The web frontend will always show the latest information seen on the network.

== Main view ==

[[File:Dns servers.png|600xp|DNS servers]]

=== DNS server ===

This tab shows all DNS servers in the network for which DNS traffic has been seen.

For each server the number of requests and responses are shown including a history. The table allows to go to a detailed page for the DNS server (DNS server details), the generic IP details page, and to the connections of the IP server.

=== Resolved names ===

This tab shows a table with all IP addresses and its name based on seen DNS request and response pairs.
The Expire time column contains the date when the name is no longer valid. Usually DNS servers use a short timespan to let clients not store wrong names too long. The timespan usually ranges from a few minutes to some hours.
The DNS server IP column lists the IP of the DNS server which responded to a query. Often, especially in smaller networks, there is only one server, but clients are free to use any other available DNS server.

[[File:Dns resolved names.png|400px|DNS resolved names]]

=== Server response times ===

The response times tab shows global and per DNS server statistics about response times between a DNS request by a client and the response by the server.
In the global section a graph shows minimum, average and maximum values over time.
A table lists the amount of requests and responses, as well as response times per DNS server. A graph shows the amount of requests and responses over time.

[[File:Dns server response time.png|400px|DNS server response time]]

=== Server reply codes ===

This tab shows reply codes globally and per DNS server in a list. Graphs show the distribution over time.
The most common reply codes are shown:

* No error (0)
* Format error (1)
* Server failure (2)
* Non-existent domain (3)
* Other errors

[[File:Dns server reply codes.png|400px|DNS server reply codes]]

=== DNS record types ===

This tab shows the amount of DNS record types globally for all DNS server. Detailed graphs are available for the most commonly used record types A, AAAA, CNAME and MX

[[File:Dns record types.png|400px|DNS record types]]

== DNS server details ==

[[File:Dns server details.png|600px|DNS server details]]

The server details page shows an overview for the selected DNS server and a detailed list of DNS lookup response times for each individual DNS connection. Also, the unanswered DNS requests are shown and the non-existing names.

=== Overview ===

The overview tab shows DNS statistics for the selected DNS server, including the number of requests and responses, the average response time, and the historical graph.

=== Lookup response times ===

[[File:Dns server names.png|400px|DNS names and lookup times]]

This tab shows the number of unique DNS names that have been answered by the current DNS server. The table shows the number of requests and responses per name as well as counters for each reply code. Clicking any number will filter the connection list below the able for the corresponding elements. By using the toggle buttons above the table it is possible to hide name elements which do not have a non-zero counter for the specific field. For example, this allows for easily see only those names that have been answered with a server failure reply code.

The second table lists all DNS connection and shows when the request happened, the response time and the name and status code.

The list of connections can be filtered, for example to search for specific names, or for specific status codes.
For example, the filter expression '''(dnsstatus==2)''' shows all DNS connections with a server failure.

The list can also be downloaded to get all matching connections as CSV file for further processing.

=== Unanswered requests ===

This tab shows the unique number of DNS names that have not been answered by the current DNS server. It is possible to click on the number to filter the connection table below to that specific name.

=== Non-existing domains ===
This tab shows the unique number of DNS names that has been rejected by the DNS server for being not existing. It is possible to click on the number to filter the connection table below to that specific name.

Path measurement

2022-05-05T06:57:12Z

Mark:

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

In Firmware version >= 3.3, 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.
== 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 ==

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

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.

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

The settings must be saved but to actually take effect, a restart of the packet processing is necessary. If this step is required 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.

== Measurement statistics ==

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

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.

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

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

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

=== IP statistics ===

The second tab shows packet loss information for each pair of 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 differantiation 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 differantiation 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.
# 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.
# 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.

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

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

Measurement modules

2022-05-05T06:49:38Z

Mark:

The Allegro Network Multimeter provides a number of network measurement modules for different use cases. Here
you can find a list of modules and a short description and see the specific module for detailed documentation.

== Generic modules ==

* [[Capture_module|Capture module]]
:The Capture module lists all running captures which were started interactively in any other module.
:It also allows for starting new captures with specific filters.

* [[Path_measurement|Path measurement]]
:This module allows you to measure packet loss and latency between two Allegro Network Multimeter installations.

* [[Packet_ring_buffer|Packet ring buffer]]
:The packet ring buffer feature allows you to create a buffer of fixed size on an external storage device to which all processed packets will be recorded. If the fixed size buffer is full, the oldest packets in the buffer will be replaced with new packets in a round-robin fashion.

* [[PCAP#Pcap_analysis_module|Pcap analysis module]]
:The Pcap analysis module allows for the analysis of Pcap files by sending them to the appliance. After analyzing a Pcap, the web interface displays all the metadata as if the packets are live traffic at the time of the Pcap recording.

* [[Incidents#Incidents_module|Incidents module]]
:The Incidents module allows for notifications to be created when specific network incidents are detected.

== L2 - Ethernet Layer ==

* [[MAC_module|MAC module]]
:The MAC module gathers information about all captured MAC addresses, including the protocols used, traffic, communication peers and MAC/IP mappings.

* [[QoS module]]
:The QoS module processes and displays traffic with QoS tags VLAN PCP and MPLS TC on Layer 2 (and IP DSCP on Layer 3).

* [[Packet_size_module|Packet size module]]
:The packet size module accounts the size of all packets (Layer 2 with CRC) and shows packet size distribution.

* [[ARP_module|ARP module]]
:The ARP module monitors ARP packets for tracking MAC addresses and announced IP addresses.

* [[VLAN_module|VLAN module]]
:The VLAN module accounts traffic per VLAN tag seen on the network.

* [[MAC_protocols_module|MAC protocols module]]
:The MAC protocols module accounts traffic of all different MAC protocols.

* [[STP_module|STP module]]
:The stp module analyzes STP traffic and shows a history of the identified root Bridges with their configurations.

* [[MPLS_module|MPLS module]]
:The MPLS module displays information about all identified MPLS labels (single label and double-stacked).

* [[LLDP_module|LLDP module]]
:The LLDP module extracts information from LLDP (Link Layer Discovery Protocol) messages and correlates this information to the respective MAC and IP addresses.

* [[PPPoE module]]
:The PPPoE module displays all PPPoE sessions and traffic within a specific session.

* [[Burst_analysis|Burst analysis]]
:The Burst analysis module measures throughput per interface or MAC address and displays utilization graphs for fast burst recognition.

* [[IEEE 802.11 module]]
:This module analyse wireless frames forwarded by access points.

== L3 - IP Layer ==
* [[IP_module|IP module]]
:The IP module gathers information about all captured IPv4 and IPv6 addresses including the protocol used, traffic, communication peers, and connections.

* [[IP_groups|IP groups]]
:The IP groups module gathers information for groups of IP addresses. Any IP subnet can be configured to be used as a group.

* [[IP_pairs|IP pairs]]
:The IP pairs module shows traffic information between pairs of IP addresses.

* [[QoS_module|QoS module]]
:The QoS module processes and displays traffic with QoS tags for IP DSCP on Layer 3 and VLAN PCP (and MPLS TC on Layer 2).

* [[Geolocation_statistics|Geolocation statistics]]
:The Allegro Network Multimeter uses a geolocation library to identify the IP addresses of individual countries. The country information is shown in other modules; however, this web page lists all countries and their corresponding amount of traffic. It also shows detailed statistics per country including all IP addresses seen for that country.

* [[DHCP_module|DHCP module]]
:The DHCP module tracks requests and responses for dynamic IP assignments in networks.

* [[DNS_module|DNS module]]
:DNS name resolving is handled passively by processing all DNS requests and responses captured by the system.
:This module lists all IP addresses and names known by the system. This information is used by other modules to look up names.

* [[NetBIOS_module|NetBIOS module]]
:The NetBIOS module monitors NetBIOS packets for tracking announced host names for IP addresses.

* [[ICMP_module|ICMP module]]
:The ICMP module shows information about ICMP traffic and specific packet types.

* [[Multicast_statistics|Multicast statistics]]
:The multicast module analyzes IGMP traffic and displays detailed information on multicast groups and members.

== L4 - Transport Layer ==

* [[Connections_module|Connections module]]
:The Connections module provides access to a list of connections of all IPs aggregated together based on selected sort and filter parameters.

* [[TCP_module|TCP module]]
:The TCP module measures the TCP handshake time for connection setup. It allows you to identify slow responding servers in a network.

* [[Layer_4_server_ports_module|Layer 4 server ports module]]
:The Layer 4 server ports module measures traffic per TCP and UDP server port.

* [[IPSec_module|IPSec module]]
:The IPSec module shows information about IPSec ESP traffic and sequence counter correctness.

== L7 - Application Layer ==

* [[SSL_module|SSL module]]
:The SSL module keeps track of SSL server names and common names in SSL/TLS encrypted traffic. It enables you to get the name resolved even if no DNS has been seen.

* [[HTTP_module|HTTP module]]
:The HTTP module keeps track of HTTP host names requested in HTTP connections. It allows you to get the name resolved even if no DNS has been seen and to see which virtual host is handled by a given server.

* [[L7_module|L7 module]]
:The L7 module gathers information about all supported Layer 7 protocols. This includes information on how much traffic was seen for each protocol for each IPv4 and IPv6 address.

* [[Response_time_analysis|Response time analysis]]
:The response-time analysis module allows you to define your own protocol request and response pattern and measure the response time and request/response loss.

* [[SMB_statistics|SMB statistics]]
:The SMB module gathers information about all SMB servers handling unencrypted traffic. It shows which shares have been accessed and which files in those shares have been read or written to, together with detailed statistics per file.

* [[SIP_module|SIP module]]
:The SIP statistics includes all SIP calls and their associated metadata.

* [[NTP_module|NTP module]]
:The NTP module shows detailed information about Network Time Protocol servers selected and their corresponding network clients.

* [[PTP_module|PTP module]]
:The PTP module stores the PTP members and their associated metadata like the PTP version.

* [[Profinet_module|Profinet module]]
:The Profinet module analyzes Profinet RT cyclic and acyclic traffic and displays details on all devices and their communication relationships.

* [[OPC-UA_module|OPC-UA module]]
:The OPC-UA module displays information about OPC-UA binary protocol traffic and performs response-time measurement.

* [[IEC_60870-5-104_module|IEC 60870-5-104 module]]
:The IEC 60870-5-104 module shows information about IEC 60870-5-104 traffic, sequence counter correctness and response times.

* [[RTP_statistics|RTP statistics]]
:The RTP module shows detailed information about RTP codecs used.

Interface statistics

2022-05-05T06:48:05Z

Mark:

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

The Interface status column contains generic information about each port.

The Interface ID is a unique number enumerated for all network ports.

The Link pair number covers two ports linked to each other in the '''bridge mode''' or '''mixed bridge/sink mode'''.

That is, traffic received from one port of the same link pair will be sent to the corresponding port of the same link pair, and vice verse. In '''sink mode''', the link pair number is irrelevant as no traffic is forwarded.

If the packet processing mode '''Mixed bridge/sink mode''' has been enabled in the [[Global settings]] a drop down menu appears and the packet processing mode for the interface can be chosen. A selection here automatically affects the other interface of the link pair. Single interfaces which are not part of a link pair do not show the drop down menu as they always operate in '''Sink mode'''.

The Speed setting offers a possibility to change the speed of the port.

A selection of all possible settings is presented. The default selection is '''auto''' for the highest possible speed. This selection also has the option '''disabled''' to permanently disable the interface and bring the link down.

The Speed indicates whether a network cable is connected and which link speed has been negotiated.

The Duplex status shows whether the link is operated in '''full-duplex''' or '''half-duplex''' mode.

In case the Allegro Network Multimeter operates in bridge mode and two mutual interfaces do not have the same link speed and duplex, a warning will be shown below the Duplex status for both interfaces.

The Current receive/transmit utilization summarizes the traffic received and sent by the network port.

The value is calculated by the number of bytes received and sent in relation to full-duplex link speed.

A PCAP buttons allows capturing all traffic for that network port.

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

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

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

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

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

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

=== L3 tunnel stats ===

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

Info Menu

2022-05-05T06:46:07Z

Mark:

==System Info==

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

This page contains multiple sections about different parameters of the system.
The System description describes system parameters such as the Firmware version and the installed CPU cores and memory.
The System utilization summarizes statistics about the current utilization which is dependent on the actual network traffic.

* Processing packets since: This is the time since the packet processing was started. This can be the uptime of the system but packet processing can be manually restarted for various reasons (replaying pcap files, clearing all data, changing some configuration settings, etc).
* Data stored for last: This value describes how long the Allegro Network Multimeter contains information from historical traffic.
:The storage duration depends on the network traffic, the configuration settings, and the amount of memory available in the system.
:Once the memory is fully utilized, older data will be automatically removed in favor of new data.
* Estimated data store time: This value is calculated based on the current data store time and the memory utilization. It gives an indication for how long data can be stored once the memory is fully in use (which is automatically adjusted to 90%).
* Packets stored in ring buffer for last: If a storage device is used for a packet ring buffer, this time indicates how long packet data has been stored in the buffer.
:This means that network traffic can be extracted from the past within this time period.
:The duration may be larger than the data store time or even shorter depending on the actual network traffic and the size of the storage device and ring buffer.
* Memory utilization: The current utilization is printed together with a graph about the change of the utilization over time.
:The Allegro Network Multimeter uses an automatic cleanup mechanism to remove old data in favor of new data.
:The available memory should always be used as much as possible and the cleanup mechanism ensures that approximately 90% of the system memory is in use.
* Load: The load information shows the utilization of the system’s CPU.
:If the load hits 100% for a longer period of time, it means the system is overloaded for the current network traffic.
:A corresponding notification is shown at the top of the window.
:When this happens, usually some network traffic can no longer be analyzed and packet drops occur.
:This only affects packet analysis. In Bridge mode, packet forwarding is still possible even if the analysis is overloaded.
*Ingress packet memory utilization: Shows the usage of the memory reserved for buffering received packets.
:The current utilization is printed together with a graph about the change of the utilization over time.
:If this memory is depleted some packets will not be processed.
:See [[Global settings]] for the configuration of the '''Ingress packet memory''' size.
*The Global element count lists some global parameters about how many MAC addresses, IP addresses, connections and so on are stored in the system.
*If the system is equipped with a GPS precision option, the section GPS information shows information about the clock synchronization, accuracy, and so on.
: 
== Status==

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

The Status page lists possible problems occurred during packet processing. This includes bypassed packets in case of system overload, core restarts, and other problems.
In case of crashes, crash logs are shown which can be downloaded and send to our [[Reaching Allegro Support|support]] to be able to identify problems.

Pcap analysis module

2022-05-05T06:44:48Z

Mark:

The pcap analysis module allows analyzing pcap files by sending them to the device. After analyzing the pcap, the web interface shows all the metadata as if the packets are live traffic at the time of the pcap recording.

'''Web Interface'''

{| class="wikitable"
|-
|
[[File:Pcap.png|1000px|none]]
|}

====Notes====
Starting pcap analyze will stop the network ports and thus the normal packet processing and forwarding is disabled. The network connections of the devices connected to the Allegro Network Multimeter will stop working.

==== Start new Upload====
To select a file to analyze, simply drag a file from your file manager to the drop zone. The second option is to click into the drop zone. After a click, a file selection dialog will open.
After selecting a file, the name and the size of the pcap will be displayed in the drop zone box.

To proceed, press the '''Upload and analyze pcap''' button. A modal dialog will open.

* A warning will be shown if the device is in bridge mode, since no more packets will be forwarded when starting pcap analyze mode.
* If a storage device is active, it is possible to buffer the packets on it. This allows simple extraction of packets as in live packet processing.

The pcap file itself will not be stored on the storage of the Allegro Network Multimeter (except in the packet ring buffer, if activated in the upload modal dialog).

==== PCAP analysis statistics====
After the upload started, a progress section will be displayed. This includes a progress bar and the time of the last
processed packet. When viewing the progress bar on a different tab or on a different browser, the progress bar
will not show the correct value.

==== Viewing the pcap metadata====
During and after the upload of the file, all modules will show the metadata produced by analyzing the packets in the pcap file.

==== Resuming normal operation====
After finishing the analysis, the processing can be set back to live mode by clicking the '''Resume normal operation''' button at the bottom of the page.

Storage

2022-05-05T06:43:44Z

Mark:

==General==
The Allegro Network Multimeter allows for internal or external storage device(s) to be connected.

Such HDD- or SSD-based storage devices, serve the following purposes:

* Ring Buffer: Allows for network traffic recording (partial or 100%) onto a fixed size '''ring buffer'''/circular buffer (FiFo)
* Storage: Allows for the creation of a dedicated storage partition, for saving and storing pcap files onto the local device
* Network traffic replay and analysis of data recorded onto the ring buffer
* Retroactive filtered packet capturing, from network traffic data residing in the ring buffer. see -> [[Capture module]]

{| class="wikitable"
|-
| [[File:Storage.png|1000px|none]]
|}

== Managing storage devices ==
The Allegro Network Multimeter supports disks formatted with an '''ext4 filesystem ''' and will only use '''the first partition''' of a disk.

If a compatible disk is attached it will be activated automatically and the Storage page will show stats about the device as well as the contents.

If an '''unformatted disk''' or a disk with an '''incompatible file system''' is attached, it will show up on the Storage page where it can be formatted using the '''Format button''' displayed next to the device's type and size. After formatting the disk, it will be automatically activated for use as storage device.

For securing your data, Allegro Network Multimeter supports the use of '''AES256 disk encryption'''.

To encrypt a storage device with AES256 disk encryption, (re)format the disk and enable the AES256 disk encryption option in the on-screen menu.

[[File:Disk formatting and encryption.png|700x700px]]

If an active storage device is to be disconnected from the Allegro Network Multimeter, the deactivate button on the storage page can be used to deactivate the storage device.

The page will then show that the respective storage device has become unactive. Now, the device can be disconnected safely.

== Secure erase ==
For security reasons, the "'''Securely erase content"''' button, allows for special formatting algorithms to wipe your disk(s).

Everything on the disk is overwritten with randomly generated patterns, making attempts to recover data (near to) impossible.

Allegro Packets utilizes the sata (extended) secure erase instruction set, for sata disks that support it.

For NVME type SSD's, Allegro Packets utilizes the "Cryptographic Erase" instruction set.

NOTE: The erasing may take several hours, depending on the size and the speed of the disk. After the secure erase process, a disk needs to be formatted before use.

== File storage ==
The Allegro Network Multimeter will initially show the top level directory of the storage partition. By clicking on a directory name the view can be switched to the contents of that sub-directory. This will also show the path of the current directory above the table along with a button that allows to change back to the parent directory.

Generic files which are not packet capture (pcap) files, will show with two buttons next to them. As the names suggest the '''Delete button''' will delete the file from the storage device and the '''Download button''' will start a browser download of this file.

Next to packet capture (pcap) files, an additional '''Analyze PCAP''' button will show. When this button is pressed the Allegro Network Multimeter will either reset all statistics and start analyzing the packet capture file or enables to start a parallel PCAP analysis if this is configured (see [[Parallel packet processing]]). Progress, statistics and the option to resume normal operation will appear at the top of the Storage page.

The '''New directory''' button opens as dialog that can be used to create a new sub-directory in the currently shown directory. Sub-directories can be used as target for storing packet captures (see [[Capture module#Capture settings dialog|Capture settings dialog]]).

The '''Select or drop file''' area along with the '''Upload file''' button allows to upload a file to the current directory.
== WebDAV ==
The Network Multimeter also provides access to the storage contents via WebDAV.

For this, use the '''Connect to server''' or '''Connect to a network drive''' function on your computer and use the link https://<host name>/webdav.

The credentials are the same as of the web interface. Use the admin account to access the files on the storage device.

WebDAV is supported natively by all current operating systems.

If you have connection problems due to SSL certificate issues under Windows you may try 3rd party tools with WebDAV support.
{| class="wikitable"
|+
!Operating system
!Usage
!Notes
|-
|Windows
|In third-party tools with webdav support:
enter URL

https://<hostname or ip>/webdav
|Standard windows explorer does not accept self-signed certificates.
Use a third-party tool to use webdav!
|-
|Linux
|In file manger, enter URL
davs://<hostname or ip>/webdav
|System usually asks to accept the certificate and that asks for username and password.
|-
|MacOS
|Open Finder, select menu "go to -> connect to server".
Enter "https://<hostname or ip>/webdev"
|System usually asks to accept the certificate and that asks for username and password.
|}

== iSCSI ==

{| class="wikitable"
|-
| [[File:Configure iSCSI device.png|600px|none|]]
|}

A remote iSCSI target can be used as a storage device.

The iSCSI target must be reachable over the management network connection.

To add an iSCSI target as storage device use the Configure iSCSI device button which is visible on the Storage page when no storage device is currently activated.

In the displayed dialog you must enter the host which can be an IP address or host name and may include a port number (e.g. 'storageServer:3260').

You must also enter the '''iSCSI Qualified Name (IQN)''' of the iSCSI target on the iSCSI host.

Using authentication like CHAP is optional and if no authentication is to be used the User and Password` fields can be left empty.

After confirming the dialog by pressing the Configure button the iSCSI storage device will show up in the storage device list after a few seconds.

The Allegro Network Multimeter will also try to activate a configured iSCSI target automatically after system startup.

Once an iSCSI device has been configured the device can be modified or removed using the Modify iSCSI device and Remove iSCSI device buttons on the Storage page.

Only one iSCSI device can be used at a time.

Self-hosted SSH Proxy

2022-05-05T06:39:30Z

Mark:

== SSH Port Forwarding ==

The Allegro Network Multimeter can be configured to to use SSH Port Forwarding to allow remote access to the device behind a NAT.
The Allegro Network Multimeter will create a tunnel to an SSH endpoint and will open a listening port on the SSH server.
This port can now be used to send HTTPS requests to the Allegro Network Multimeter.

=== Preparing the SSH server ===

==== Create a user ====

The user on the SSH server does not need any special rights and does not need a login shell. Example:

$> useradd -m -s /usr/sbin/nologin mmremote

==== Allow SSH access via public key ====

The Allegro Network Multimeter uses SSH public key authentication to log in to the SSH server. The public key can be found in the '''SSH public key''' field in the '''SSH Port Forwarding''' settings dialogue.

$> mkdir /home/mmremote/.ssh
$> chown mmremote: /home/mmremote/.ssh
$> nano /etc/mmremote/.ssh/authorized_keys

Paste the line into the file and save/close the file.
There are two options to access the Allegro Network Multimeter:

==== Option 1: No proxy ====

Advantage:
* no additional software required.

Disadvantage:
* no port < 1024 (as non-root user).
* Default HTTPS port 443 is not possible.

The SSH server can be configured to allow only local listening ports. This has to be changed to allow listening on any subnet.

Edit the SSH configuration file '''/etc/ssh/sshd_config''' and activate the following line:

<code>GatewayPorts clientspecified</code>

Save and close the configuration file and restart the SSH service.

==== Option 2: With HTTPS proxy ====

Advantage:
* uses default HTTPS port 443.
* uses several filter mechanisms provided by the proxy software.
* uses the same SSH server as proxy for several Allegro Network Multimeters through SNI routing.

Disadvantage:
* additional configuration required.

The following block shows a sample configuration for the '''nginx''' proxy server:

server {
listen 443 ssl;
listen [::]:443 ssl;

server_name allegro-mm-1234.mm-remote.company.com;

ssl_certificate /etc/letsencrypt/live/allegro-mm-1234.mm-remote.company.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/allegro-mm-1234.mm-remote.company.com/privkey.pem;

location / {
proxy_pass https://localhost:55443; # 55443 =configured listen port on multimeter
}
client_max_body_size 200M; # for firmware uploads
}
server {
listen 80;
listen [::]:80;

server_name allegro-mm-1234.mm-remote.company.com;

return 301 https://$host$request_uri;
}

Forwarding to the Allegro Network Multimeter uses the configured server name. In this example, requests to '''allegro-mm-1234.mm-remote.company.com''' will be forwarded to the Allegro Network Multimeter.
This requires that the hostname is resolved by the DNS server. This can be solved by a wildcard DNS CNAME entry to point at the SSH server.

=== Configuration of the Allegro Network Multimeter ===

In the configuration dialogue, insert the parameters to access the SSH server. For example:

* SSH Host: '''mm-remote.company.com'''
* SSH Port: '''22'''
* SSH User: '''mmremote'''
* Listening HTTPS Port on SSH Host: '''55443'''

The settings have to match the above configuration. '''Every Allegro Network Multimeter requires a separate HTTPS listening port..'''
If the '''SSH user''' is not '''root, no port below 1024''' is possible. Otherwise, an error message will appear when trying to connect.

Dashboard

2022-05-05T06:31:56Z

Mark:

The dashboard gives a quick overview about the network traffic processed by the Allegro Network Multimeter.

There are '''three''' different dashboards available which focus on different aspects of the network traffic.

# Top Users
# Quality
# Triple play

{|class="wikitable"
|-
|[[File:Dashboard 1.png|150 px|none]]
|}

== Top Users dashboard ==
The Top Users dashboard provides an overview of the most active entities and protocols in the network traffic.

All sections can be minimized or maximized by click on the arrow next to a section.

{|class="wikitable"
|-
|[[File:Top Users dashboard.png|700px|none]]
|}

==== Active Interface Overview ====

This overview lists all active network interfaces used for traffic analysis.

A history graph shows the receive bitrate for each active interface.

The table next to the history graph contains the link status for each active interface including the active link speed, the current receive bitrate, the link utilization and a button that allows to capture the traffic of that particular interface. If a NIC filter has been configured, the filtered amount of traffic is shown in the last row of the table.

If no interface is active or the system is operating in one of the replay modes (e.g. PCAP replay, packet ring buffer replay) instead of the Active interface overview history graph a Traffic overview history graph is shown which displays the combined traffic processed by the system.

{|class="wikitable"
|-
|[[File:Active Interface Overview.png|700px|none]]

|}

==== Active Groups Overview ====

The group list provides an overview of all groups for which traffic
has been seen. The traffic counters and received traffic over time as a
graph are shown for each group. A PCAP button is available for capturing the
traffic for that group.
This section is only visible if there are groups configured.

{|class="wikitable"
|-
|[[File:Active Groups Overview.png|700px|none]]
|}

==== Top sending IPs / Top receiving IPs ====

The Top sending IPs and Top receiving IPs panels show the top 5 most active sending/receiving IP addresses.

A button is available to toggle between list view and graph view.

In live view mode, the IPs are listed with the most bytes during the last minute.

If an interval is selected, the IPs with the most bytes in that interval are listed.

The list contains the IP address and name (if known) as well as the current packet rate and bit rate.

There is also a button to directly capture traffic for the corresponding IP address.

Each IP address in the list can be clicked to get to the IP details statistics of that IP, or the Top sending IPs / Top receiving IPs link can be clicked to get to the main IP module.

{| class="wikitable"
|-
|[[File:Top sending IPs ,Top receiving IPs_1_1.png|1000px|none]]
|Top IPs as graph
|-
|[[File:Top sending IPs ,Top receiving IPs_1_2.png|1000px|none]]
|Top IPs as list
|}

====Top MACs====

Similar to the Top sending IPs / Top receiving IPs , the Top MACs panel shows the top 5 most active MAC addresses.

A button is available to toggle between list view and graph view.

In live view mode, the MAC addresses are listed with the most packets during the last minute. If an interval is selected, the MAC addresses with the most packets in that interval are listed.

The list contains the MAC address and name (if known) as well as the current packet rate and bit rate. There is also a button to directly capture traffic for the corresponding MAC address.

Each MAC address in the list can be clicked to get to the MAC details statistics of that MAC, or the Top MACs link can be clicked to get to the main [[MAC_module|MAC module]].

==== Top protocols====

The Top Protocols panel shows the top 5 most active network protocols.

A button is available to toggle between list view and graph view.

In live view mode, the protocols are listed with the most packets during the last minute. If an interval is selected, the protocols with the most packets in that interval are listed.

Each protocol in the list can be clicked to get to the detailed statistics for that protocol, or the Top protocols linked can be clicked to get the main [[L7_module|L7 module]].

{| class="wikitable"
|-
|[[File:Top sending IPs ,Top receiving IPs_2_1.png|1000px|none]]
|Top MACs as graph
|-
|[[File:Top sending IPs ,Top receiving IPs_2_2.png|1000px|none]]
|Top MACs as list
|}

== Quality dashboard==

The Quality dashboard provides an overview of various quality-related metrics and their development over time.

{| class="wikitable"
|-
|[[File:Quality dashboard.png|1000px|none]]
|}

====Burst analysis====

This graph shows the combined network interface throughput utilization which is measured with 1ms resolution. A link to the detailed Burst analysis page is provided [[Burst_analysis|Burst analysis]].

====Response time====

Here the average TCP data response time and the combined average application response time are shown. There are two links which navigate to the detailed TCP response time analysis page and to the application response time overview page.

====Jitter====

This graph shows the average RTP jitter and the average Profinet jitter.

Links above the graph navigate to the respective detail pages.

====Packet loss====

This graph shows the packet loss percentage for RTP, IPSec and Profinet.

Links above the graph navigate to the respective detail pages.

====TCP retransmitted data / TCP retransmission ratio====

The TCP retransmitted data and TCP retransmission ratio graphs show the amount and ratio of TCP data that was retransmitted due to packet loss.

More detailed information can be found when following the link to the [[TCP_module|TCP module]].

====TCP zero window packets ====

The TCP zero window packets graph shows the global number of TCP zero window packets over time. More detailed information like the number of TCP zero window packets per IP can be found when following the link to the [[TCP_module|TCP module]].

==Triple play dashboard==

The triple play dashboards shows global data about VoIP and RTP protocols.

{| class="wikitable"
|-
|[[File:Triple play dashboard.png|1000px|none]]
|}

====VoIP statistics====

The VoIP statistics panel shows SIP calls and their associated metadata.

====RTP statistics====

The RTP statistics panel shows RTP traffic of the last minute or of the selected interval.

A pie chart shows the distribution of currently used RTP codecs.

The Top RTP codecs table shows detailed statistics for the five most used RTP codecs. A PCAP button allows to capture traffic for a certain codec.

Supported Storage Devices for x300, x310, x400, x410, x500 and x510 Series

2022-05-05T06:24:27Z

Mark:

Some Allegro Network Multimeter aplliances can be equipped with hot-swappable storage devices. This page lists which appliances support which type of storage devices.

In general, we recommend to use devices with similar specs for best performance but there is no technical restriction to use different units.
When using multiple ring buffers (see [[Ring Buffer Configuration Guide]]), it can be beneficial to use different devices, for example, slow but large devices for long-term capturing with packet truncation, and fast but smaller devices for full line rate capturing.

== Allegro x300 (1300/3300/5300) ==

The Allegro Network Multimeter x300 series has 10 x 2.5" device slots, two of them also support U.2 devices.

{| class="wikitable"
|-
! Slot 0+1 !! Slot 2+3 !! Slot 4+5 !! Slot 6+7 !! Slot 8+9
|-
| 2.5" SATA3 || 2.5" SATA3 || 2.5" SATA3 || 2.5" SATA3 || 2.5" SATA3 2.5" U.2
|-
| 2.5" SATA3 || 2.5" SATA3 || 2.5" SATA3 || 2.5" SATA3 || 2.5" SATA3 2.5" U.2
|}

Note: SAS devices are not supported!

== Allegro x500 (1500/3500/5500) ==

The Allegro Network Multimeter x500 has 36 x 3.5" device slots, supporting SATA3 or SAS3 devices. The rev2 of the x500 chassis also supports U.2 devices.

U.2 devices can be installed at the rear of the Allegro Network Multimeter (which has 12 slots in total). The U.2 slots are the top two slots in the last fourth column (at the right):

[[File:3500-back-u2.png|frameless|U.2 slots]]

== Allegro 2U/4U JBOD extension ==

The Allegro Network Multimeter JBOD extension has 12x (2U) or 44x (4U) 3.5" device slots, supports SATA3 or SAS3 devices.

Multi-device settings

2022-04-27T15:17:57Z

Mark:

== Multi-device settings ==
The multi-device feature allows you to access multiple Allegro Network
Multimeters from a single Allegro Network Multimeter (the main device). Access to the remote
Allegro Netwoek Multimeters is routed through the main appliance so the web user does not
need to have direct access to the target devices.

Features like the [[Path measurement|Path measurement]] also use the multi-device
settings to access the remote appliance for the measurement.

As soon as a remote multi-device is active, the top menu shows a
drop-down menu for you to be able to select the current view. All measurement
data shown in the web interface are from the selected device.
== List of remote devices ==

The first part of the page contains the list of all configured remote
devices. It shows the host name or IP address for the corresponding device and
an arbitrary description for each device which can also be changed.

Next to the description, details of the SSL certificate of the remote
device is shown so it is possible to verify the correct
certificate.

The last column allows you to activate or deactivate devices and remove
them completely from the list. Only activated devices are actually
contacted and made available in the top selection box. It is also possible
to update the firmware of the remote device with the version of the main device.
The settings of the main device can also by synchronized to the remote device.[[File:Multi device settings.png|alt=|thumb|600x600px|Multi device settings|none]]

== Add a remote Allegro Network Multimeter ==

Below the list of registered Allegro Network Multimeters, new devices can be added by
entering the host name or IP address, optionally setting a description
for the device, and the login credentials.

== Main device description ==

The main device can also have an arbitrary description to make it
easier to select it from the top selection box.

== Firmware update ==

It is possible to update remote devices to the same firmware as the main device.
The downloaded firmware file must exist on the main device and is used for uploading
to all remote devices. No internet access is necessary.

The firmware update will trigger a restart of the processing of the remote Allegro Network Multimeter. In case
it is running in bridge mode, the link will be interrupted for a short moment!

Each remote device can be updated separately by clicking the "Update firmware" button in the
action column. The status column will show progress information and whether the update was
successful.

It is also possible to update more than one device at a time. You can check the checkboxes of
one or many devices and use the button "Update firmware of selected Multimeters". All checked
and visible devices of the current page will be updated. The button "Update firmware of all
Multimeters" will perform the update for every configured Allegro network Multimeter regardless whether it is
selected or not.

If the firmware version of the remote Allegro Network Multimeter is already the same version as the main
device or prior to version 3.0, the update is not performed.

== Settings synchronization ==

It is possible to synchronize the overall settings throughout an Allegro Network Multimeter (core settings), from the main device to all the remote devices.
Similar to the firmware update, it is possible to synchronize one, many or all remote devices at a time.

Management interface settings, multi-device settings and user management (roles) cannot be synchronized between Allegro Network Multimeters.

Attention: The settings update will trigger a reboot of the remote Allegro Network Multimeter(s). In case it is running in bridge mode,
the link will be interrupted for a short moment!

== License update ==

It is possible to update the licenses of remote Allegro Network Multimeters on this page. An archive with the
licenses can be uploaded to the selected or all Allegro Network Multimeters. The Allegro Network Multimeter will try to find
its matching license in the archive and update accordingly.

List of Supported Transceiver Modules

2022-04-21T09:53:52Z

Mark:

== 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 1000/1200/3000/3200 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 and x500 series and all expansion cards for the Allegro Network Multimeter 1000/1200/3000/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
|requires Intel branding
|-
|SFP
|Finisar FCLF8521P2BTL
|Copper
|RJ45
|10/100/1000M
|not supported in builtin ports in model 1000/1200/3000/3200, only in expansion slots,
|-
| 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||
|-
| QSFP28 || fs.com 75308 || Fiber (SR4)
|MPO
|100G||
|-
| QSFP28 || Cisco QSFP-100G-CU (1M, 2M, 3M, 5M) || DA(Copper, Passive)
| -
|100G||
|}

== 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+ 40G SR BG || Cisco qsfp-40g-sr-bg P/N: 191402 || Fiber (SR4) || only partial support, modules must be (re-) inserted after power up
|-
| QSFP+ 40G SR4 || Cisco qsfp-40g-sr4 P/N: 186602 || Fiber (SR4) || only partial support, modules must be (re-) inserted after power up
|-
| QSFP+ 40G AOC || Cisco qsfp-h40g-aoc10m P/N: 187627 || Fiber (SR) || only partial support, modules must be (re-) inserted after power up
|-
| QFSP+ 40/100 SRBD || Cisco qsfp-40/100-srbd P/N: 199804 || Fiber (SR) || does '''NOT''' work
|-
| QFSP28 || Cisco QSFP-100G-SM-SR || Fiber (LR4 lite) || does '''NOT''' work
|}

Ingress filter

2022-04-21T09:48:27Z

Mark:

=== Ingress (NIC) filter ===

The ingress (NIC) filter page, allows setting allow/deny filters for live traffic preprocessing. Filtered out/denied traffic, will NOT become available throughout the dashboard nor the packet ring buffer. Filtered out/denied traffic will be irretrievable for (post) analysis.

Filters can be applied for:

* IP addresses (with possible subnet mask).
* pairs of IP addresses (with possible subnet mask).
* MAC addresses.
* VLAN tags (or none for no VLAN tag).
* specific TCP/UDP ports.
* physical interface IDs (as listed in Interface statistics).
* duplicate packets.

They can all be set to either deny list or allow list mode.
Filtering will be evaluated for every packet in tab order.
The more restrictive filter will be applied.
For instance if no IP address is denied but a specific MAC address is on the deny list, no traffic for that MAC address will be processed.

NOTE: The ingress (NIC) filter is applied to live traffic only, i.e. the traffic sent to the monitoring interfaces of an Allegro Network Multimeter. When replaying data from the ring buffer, loading a pcap or using the remote traffic capture feature, filtering is not used and/or applied.

NOTE: The data recorded to/stored in the Packet Ring buffer, is of course also affected by the Ingress filter. Additional ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here [[Packet ring buffer#Packet%20ring%20buffer%20snapshot%20length%20filter|https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter]]

{| class="wikitable sortable"
|-
| [[File:NIC filter.png|1000px|none|right]]
|}

=== IP filters ===

In the IP filter/IP pair filter, IP addresses and IP ranges can be entered with their respective subnet mask.
* /32 subnet mask: 192.168.1.1/32 means the filter will deny/allow IP 192.168.1.1
* /24 subnet mask: 192.168.1.0/24 means the filter will deny/allow IP range 192.168.1.0 - 192.168.1.255
* /16 subnet mask: 192.168.0.0/16 means the filter will deny/allow IP range 192.168.0.0 - 192.168.255.255

The IP filter/IP pair filter allows for importing an IP list in the following format:

#A line with a comment
1.2.3.1
1.2.3.2
1.2.3.3

By clicking on '''Import list''' a dialogue box will be opened where you can choose to download such a list from a given URL or specify a file from your system. The IP addresses are added to the existing ones up to a maximum of 10000 addresses.

The '''Export list''' button allows for exporting the IP filter list in the same format as the import.

The '''Delete all''' button allows for deleting all IP addresses from the filter list.

=== Packet deduplication ===

Packet deduplication provides the ability to filter packets from live traffic which have already been seen. This feature creates a hash from significant parts of the packet and stores the hash for a certain amount of time and within the configured memory limit. If for a second packet (or possibly further packets) the same hash value is calculated this packet is discarded and will not be analyzed by the system. The feature provides several options for configuring which parts of a packets are regarded as significant for duplicate detection.

It is also possible to capture packets which have been detected as duplicates but since these packets are excluded from further processing as well as the packet ring buffer it is only possible to create a live capture. Also, since only hash values are stored, the first packet of a series of duplicates will not be part of the duplicate capture, but it can be captured with the regular capture feature as it is part of the packet processing.

==== Statistics ====

The top graph and counter show how many packets have been discarded as duplicates.

The '''Memory used''' graph shows how much of the memory which has been configured for use by the packet deduplication is actually consumed. If the value is very high it is possible that the configured amount of memory is not sufficient for the actual traffic.

The '''Oldest packet age''' graph shows how old the oldest packet known to the packet deduplication is. If this value is significantly lower than the configured '''Packet timeout''' value the configured amount of memory may not be sufficient for the actual traffic.

==== Settings ====

{| class="wikitable"
|-
! Option !! Description
|-
| Enabled || Turns the packet deduplication filter on and off.
|-
| Reserved memory (MB) || Controls how much memory in megabytes is reserved for packet deduplication. This memory then cannot be used for other statistics. Changes to this value will need a restart of the processing to take effect.
|-
| Packet timeout (ms) || The time in milliseconds after which a packet hash is removed from the packet deduplication. If the time is between identical packets is longer than this value the packets will not be detected as duplicates.
|-
| Compare starting at layer || Here it is possible to choose where the packet deduplication will start to analyze the packet. If e.g. 'Layer 3' is chosen it is possible for two packets to have different MAC addresses and still be detected as duplicates.
|-
| Layer 7 length limit for compare (bytes) || This value controls how many bytes of the application payload are actually used for the hash calculation. A very high value may affect the performance while a very low value may increase the risk of false positives.
|-
| Ignore VLAN || The VLAN tag will not be used by the packet deduplication so that two packets from different VLANs can still be detected as duplicates.
|-
| Ignore IP TOS and traffic class || The IP 'type of service' and 'traffic class' fields will not be used by the packet deduplication so that two packets with different values in these fields can still be detected as duplicates.
|-
| Ignore IP TTL and HOP || The IP 'time to live' and 'hop counter' fields will not be used by the packet deduplication so that two packets with different values in these fields can still be detected as duplicates.
|-
| Ignore TCP SEQ and ACK numbers || The TCP sequence and acknowledgement numbers will not be used by the packet deduplication so that two packets with different TCP sequence and acknowledgement numbers can still be detected as duplicates.
|-
| Ignore TCP options || Any TCP options will not be used by the packet deduplication so that two packets with different TCP options can still be detected as duplicates.
|}

==== Limitations ====

# In some circumstances, real duplicates cannot be distinguished from retransmissions. For example, for TCP in IPv6 traffic a retransmitted ACK packet might be byte-wise identical to the original ACK packet. The IPv6 header does not have an IP-ID field by default so it is identical and the TCP header is identical too if both the sequence and acknowledge number are the same and no timestamp option header is used. In this case it might help to decrease the packet timeout in the deduplication configuration since real duplicates in a network setup usually appear much faster than actual retransmissions.

Management interface settings

2022-04-21T09:46:22Z

Mark:

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. This management interface can be operated with a static IP address only. 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. This feature is not supported by the Allegro 200.

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

With the release of the Allegro Network Multimeter Firmware version 3.4 an optional iPerf3-Server was added to the Allegro Network Multimeter.
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

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

Since the version 3.4 of the Allegro Network Multimeter Firmware you are able to configure a Proxy Server to use when checking for firmware.
If you are behind a proxy you are able to configure it in the Management Interface Settings.

Global settings

2022-04-21T09:44:07Z

Mark:

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

== Generic settings ==

=== Packet processing mode ===

This section allows for configuring the main packet processing mode:

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

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

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

The packet processing mode can be changed during runtime.

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

=== Endpoint mode ===

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

* Ethernet packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address. The system will process the packets as if only the inner encapsulated packet is seen and any traffic captures will only contain the encapsulated packet.
* UDP packets to specific port (packets will be analyzed as is).

An interface with endpoint mode enabled will respond to ARP requests and to ICMP echo requests so it is possible to use ping to verify that the interface is reachable under the configured IP address.

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

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

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

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

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

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

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

Here are some examples for reference on a Allegro Network Multimeter 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 Allegro Network Multimeter can be configured to use a time synchronization service. NTP is supported for all variants of the Multimeter. PTP service may be used if management interface supports hardware time stamping. If a GPS-capable PTP grandmaster card is available, 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 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.

'''GPS''' - The GPS time retrieval option will become available when a GPS capable PTP grandmaster 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.

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.

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

==Memory extension (BETA)==

See [[Memory extension]] for details about this beta 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 VXLAN, ERSPAN type II and type III, GENEVE, CAPWAP as well as L2TPv3 data traffic. In this mode all non-encapsulated traffic will be discarded. On the Dashboard a dropped counter will display dropped non-encapsulated packets for indication if this mode is active. The Allegro Network Multimeter will show the encapsulated content in all analysis modules. 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 a 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.

=== 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, only the Arista timestamp format is supported. If this option is enabled, 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.

Self-hosted SSH Proxy

2022-04-21T09:27:06Z

Mark:

== SSH Port Forwarding ==

The Allegro Network Multimeter can be configured to to use SSH Port Forwarding to allow remote access to the device behind a NAT.
The Allegro network Multimeter will create a tunnel to an SSH endpoint and will open a listening port on the SSH server.
This port can now be used to send HTTPS requests to the Allegro Network Multimeter.

=== Preparing the SSH server ===

==== Create a user ====

The user on the SSH server does not need any special rights and does not need a login shell. Example:

$> useradd -m -s /usr/sbin/nologin mmremote

==== Allow SSH access via public key ====

The Allegro Network Multimeter uses SSH public key authentication to log in to the SSH server. The public key can be found in the '''SSH public key''' field in the '''SSH Port Forwarding''' settings dialogue.

$> mkdir /home/mmremote/.ssh
$> chown mmremote: /home/mmremote/.ssh
$> nano /etc/mmremote/.ssh/authorized_keys

Paste the line into the file and save/close the file.
There are two options to access the Allegro Network Multimeter:

==== Option 1: No proxy ====

Advantage:
* no additional software required.

Disadvantage:
* no port < 1024 (as non-root user).
* Default HTTPS port 443 is not possible.

The SSH server can be configured to allow only local listening ports. This has to be changed to allow listening on any subnet.

Edit the SSH configuration file '''/etc/ssh/sshd_config''' and activate the following line:

<code>GatewayPorts clientspecified</code>

Save and close the configuration file and restart the SSH service.

==== Option 2: With HTTPS proxy ====

Advantage:
* uses default HTTPS port 443.
* uses several filter mechanisms provided by the proxy software.
* uses the same SSH server as proxy for several Allegro Network Multimeters through SNI routing.

Disadvantage:
* additional configuration required.

The following block shows a sample configuration for the '''nginx''' proxy server:

server {
listen 443 ssl;
listen [::]:443 ssl;

server_name allegro-mm-1234.mm-remote.company.com;

ssl_certificate /etc/letsencrypt/live/allegro-mm-1234.mm-remote.company.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/allegro-mm-1234.mm-remote.company.com/privkey.pem;

location / {
proxy_pass https://localhost:55443; # 55443 =configured listen port on multimeter
}
client_max_body_size 200M; # for firmware uploads
}
server {
listen 80;
listen [::]:80;

server_name allegro-mm-1234.mm-remote.company.com;

return 301 https://$host$request_uri;
}

Forwarding to the Allegro Network Multimeter uses the configured server name. In this example, requests to '''allegro-mm-1234.mm-remote.company.com''' will be forwarded to the Allegro Network Multimeter.
This requires that the hostname is resolved by the DNS server. This can be solved by a wildcard DNS CNAME entry to point at the SSH server.

=== Configuration of the Allegro Network Multimeter ===

In the configuration dialogue, insert the parameters to access the SSH server. For example:

* SSH Host: '''mm-remote.company.com'''
* SSH Port: '''22'''
* SSH User: '''mmremote'''
* Listening HTTPS Port on SSH Host: '''55443'''

The settings have to match the above configuration. '''Every Allegro Network Multimeter requires a separate HTTPS listening port..'''
If the '''SSH user''' is not '''root, no port below 1024''' is possible. Otherwise, an error message will appear when trying to connect.

Using the Allegro Remote Service

2022-04-21T09:25:02Z

Mark:

Statistics Export via POST

2022-04-21T09:16:39Z

Mark:

The Statistics Export allows querying the API of the Allegro Network Multimeter and transmit JSON results to a remote server via HTTP POST requests. The API path can be determined by using a browser debug console on any of the modules of the Allegro Network Multimeter.

The configuration can be found in the menu "Settings -> Remote access & export -> Statistics export".

Example:

* Interval: '''60'''
* Internal URL Path: '''/API/stats/interfaces'''
* External POST target: '''http://10.0.0.1:3000/interface-stats-for-mm-1234'''

This will generate a '''POST /interface-stats-for-mm-1234''' request to '''10.0.0.1''' every minute and send the interface statistics of the Allegro Network Multimeter.

== Example receiving server ==

To test the correct setup, a simple example server using Node.js can be used to receive the POST requests and show the transmitted data.

The following script is a basic '''Node.js''' server (with minimal error handling) which reads all POST requests and stores them to a file:

const http = require('http');
const fs = require('fs');

const listenAddress = '0.0.0.0';
const port = 3000;

let fileCount = 1;

const server = http.createServer((req, res) => {

if (req.method != 'POST') {
res.statusCode = 405;
res.end();
return;
}

let id = fileCount++;

let outputFilename = `${req.url.substring(1).replace(/\//g, '_')}_${id}.json`;

console.log(`${id}: ${req.method} ${req.url} => ${outputFilename}`);

let data = [];

req.on('data', chunk => data.push(chunk));

req.on('end', () => {
fs.writeFile(outputFilename, data, (err) => {
if (err != null) {
console.log(err);
res.statusCode = 500;
} else {
res.statusCode = 200;
}
res.end();
});
});
});

server.listen(port, listenAddress, () => {
console.log(`Server running at http://${listenAddress}:${port}/`);
});

REST API description

2022-04-21T09:15:53Z

Mark:

This page describes how to access and use the REST API. It allows to post-process data with 3rd party systems. The Allegro Network Multimeter web interface is itself based on this REST API and all displayed statistics can be extracted from the Allegro Network Multimeter with this API.

== General API Setup ==

=== REST API Interface ===

All Allegro Network Multimeter statistics are derived from HTTPS requests and provided as JSON objects.
The requests are stateless, i.e. there are no prerequisites and there is no fixed sequence of requests necessary.
Example requests related to a specific module and statistics can be seen in the web interface by opening the browser development console (Ctrl+Shift+I for Chrome and Firefox, F12 for Edge).

Here an example of the structured JSON data for the IP overview. This data has been extracted with the Google Chrome developer console while accessing the IP statistics page.

[[File:Rest api chrome console.png|800px]]

=== Credentials ===

The credentials are the same as for the web interface. The admin user allows to access all APIs. A non-admin user has read access to most of the statistics. If you have enabled the pcap role, the capture URL is also possible for the API.

Allegro Packets recommends to set up a separate non-admin user with or without the pcap role for the REST API of only statistics shall be gathered. This will prevent to accidentally shut down or change any configuration by calling the REST API.

== Useful shell commands and their parameters ==

=== Curl ===

Most examples are written for curl [https://en.wikipedia.org/wiki/CURL]. Curl is available as for many operating systems like Linux or Windows. Curl needs a few parameters for the access of the Allegro Network Multimeter:

The parameter '''-u''' allows you to set a user name and password for the request.

The parameter '''-k''' will allow self-signed certificates.

The parameter '''-s''' or '''--silent''' mutes any debugging output.

The URL of the API call is the first argument. It is recommended to enclose the API call with the character ' to avoid replacing the argument ( unless you need to replace parts of it )

<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm-XXXX/...'</pre>

Please note that you might need to use <code>curl.exe</code> in windows.

=== PowerShell ===

The Integrated Windows PowerShell can be used to access the REST API. This guide requires at least PowerShell v6.

The command to call a REST API is '''Invoke-RestMethod''' [https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-restmethod].
Invoke-RestMethod on the PowerShell needs a few parameters for the access of the Allegro Network Multimeter:

To set the user name for basic authorization, use the '''-Headers''' parameter:

<pre>-Headers @{Authorization = ("Basic {0}" -f [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f 'USER', 'PASSWORD'))))}</pre>

You also need to announce that you accept JSON as response with:

<pre>-ContentType'application/json; charset=utf-8'</pre>

To disable the certificate check, use:

<pre>-SkipCertificateCheck</pre>

The URL must be passed with the parameter '''-Uri''', so the full command is:

<pre>Invoke-RestMethod -Uri 'https://allegro-mm-XXXX/...' -Headers @{Authorization = ("Basic {0}" -f [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f 'USER', 'PASSWORD'))))} -ContentType'application/json; charset=utf-8' -Method 'Get' -SkipCertificateCheck</pre>

=== jq ===

jq ([https://stedolan.github.io/jq/]) is a powerful tool to extract parameters from a json document. If called without parameters, jq formats the JSON output into a readable format with indenting and new lines. It also allows to select specific values and do basic operations like addition with this values.
Please read the jq documentation for more information.

== API hierarchy ==

=== Query available URIs with OPTIONS ===

The Allegro Network Multimeter REST API has the fixed URI <code>API/stats</code> for statistics. To see all possible subtrees of a specific request, use the '''OPTIONS''' request instead of '''GET'''. It can be set with the parameter <code>-X OPTIONS</code> for curl.

<pre>
$ curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats' -X OPTIONS
{
"subResources": [
"modules",
"reports",
"incidentReporting",
"time",
"ringBufferReplay",
"pcap",
"reset",
"interfacesError",
"interfaces",
"load",
"processing"
]
}
</pre>

This allows you to query for example for all modules that are available for a specific release of the Allegro Network Multimeter:

<pre>
$ curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules' -X OPTIONS
{
"subResources": [
"pppoe",
"lldp",
"groups",
"mpls",
"opc_ua",
"quality",
"ipsec",
"profinet",
"multicast",
"burst_analysis",
"global_incidents",
"ptp",
"ntp",
"icmp",
"stp",
"sip",
"smb",
"dpa",
"l4_ports",
"netbios",
"crt",
"dpi",
"http",
"ssl",
"dns",
"dhcp",
"location",
"qos",
"ip",
"mac_protocols",
"vlan",
"arp",
"packet_size",
"mac",
"capture"
]
}
</pre>

=== URI content parameters ===

Some modules allow to use a parameter as part of the URI like the IP or Mac address. The path <code>API/stats/modules/ip/ips</code> allows you to use an IP address as next uri element

<pre>
$ curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips' -X OPTIONS
{
"subResources": [
"protocol",
":ip"
]
}
</pre>

The path of an IP address shows all further available elements:

<pre>
$ curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips/10.0.54.254' -X OPTIONS
{
"subResources": [
"sip_request_responses",
"peers_ports",
"sip_responses",
"sip_requests",
"qos",
"ports",
"connections",
"protocols",
"macs",
"peers",
"tcpStats"
]
}
</pre>

== JSON output traffic counters ==

All counters are aggregated counters, either for the selected time interval or since the processing start of the Allegro Network Multimeter. Many traffic counters have 4 separate values. These traffic counters are represented as a JSON array with at least 4 lines. The structure is as follows:
* line 1: '''received packets''', extraction example: jq .lastSecond[0]
* line 2: '''received bytes''', extraction example: jq .lastSecond[1]
* line 3: '''transmitted packets''', extraction example: jq .lastSecond[2]
* line 4: '''transmitted bytes''', extraction example: jq .lastSecond[3]
* additional lines are module specific

The following counters exist for many REST APIs like IP, MAC, l4 protocol, l7 protocol and many more:
* '''interval''': Values of the selected time interval. If no interval is specified, this is similar to lastSecond.
* '''allTime''': Values since start of the Allegro Network Multimeter.
* '''lastSecond''': Values of the last second.
* '''intervalPerSecond''': Average per second value of the selected time interval. If no interval is specified, this is similar to lastSecond.

Please note that all counters are byte counters, not bit counters. You need to multiply the counters by 8 to get the bitrate.

This example extracts the received bytes of the last second of a specific IP.

<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips/10.1.2.3' | jq .lastSecond[1]</pre>

This example extracts received and transmitted bytes of the last second of a specific IP.

<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips/10.1.2.3' | jq '.lastSecond[1] + .lastSecond[3]'</pre>

== API parameters ==

The Allegro Network Multimeter REST API has a number of query parameters that can be added to modify the request. By default, the API will display the real time counters since the last restart of the processing unit.

This example extracts the amount of received and transmitted bytes for an IP address since the processing start of the Allegro Network Multimeter. It queries via the REST API the JSON and then adds the values second value ( row 1, rx bytes ) and 4th value ( row 3, tx bytes ) of the interval counters together.

<pre>
$ curl --silent -k -u USER:PASSWORD "https://allegro-mm/API/stats/modules/ip/ips/10.54.0.254" | jq '.interval[1] + .interval[3]'
</pre>

=== Time interval selection ===

Requests can be given a time interval. If present, the '''interval''' counters are adjusted to this interval. The following GET parameters are necessary:
* '''starttime''', '''endtime''': Start and end time of the interval. Format: seconds since 1970/01/01 UTC (Unix time, epoch). You can use <code>date +%s</code> on your machine to adjust to the best interval. Please consult the man page of date for more parameters.
* '''skiphistorydata''': shall the JSON include the history data without datasets, this reduces the amount of transferred bytes if datasets are required to render a graph, can be false/true default: false
* '''timespan''': required resolution for the graph dataset

This example extracts the amount of received and transmitted bytes for an IP address for the last 24 hours.
<pre>
$ curl --silent -k -u USER:PASSWORD "https://allegro-mm/API/stats/modules/ip/ips/10.54.0.254?starttime=$(date --date="1 day ago" +%s)&endtime=$(date +%s)&skiphistorydata=true" | jq '.interval[1] + .interval[3]'
</pre>

=== List queries ===

List queries are requested with pagination parameters to reduce the size of the resulting JSON objects and to increase performance. In the resulting JSON object, the list elements are stored in the displayedItems array.
The following list parameters are possible:

* sort: Sorting criteria for the list. Following criteria's are supported for most lists:
** bytes: Received and transmitted bytes (either in selected time interval or since start of the Allegro Network Multimeter).
** rxbytes: Received bytes.
** txbytes: Transmitted bytes.
** bps: Received and transmitted bytes per second (either average per second value of the selected time interval or last second, if no interval is specified).
** rxbps: Received bytes per second.
** txbps: Transmitted bytes per second.
* reverse: Sort ascending (= false) or descending (= true).
* page: Requested page.
* count: Amount of entries in the list. Maximum is 100.
* values: Amount of maximal values in history object(s).

This example shows IP address with the highest amount of traffic

<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips_paged?sort=bps&reverse=true&page=0&count=1' | jq .displayedItems[0].ip</pre>

This example shows up to 9999 peers of a specific IP address:

<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips/10.1.2.3/peers?sort=bytes&reverse=true&page=0&count=9999&timespan=60&values=100' | jq '.displayedItems[].ip'</pre>

=== Pcap extraction ===

The Allegro Network Multimeter allows to extract the raw packets with the REST API with the special capture URI <code>/API/data/modules/capture</code>

<pre>curl -k -u USER:PASSWORD 'https://allegro-mm/API/data/modules/capture?expression=ip==10.1.2.3' > path_to/capture.pcap</pre>

The available parameters are:

* '''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. If not specified, the current time will be used.
* '''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). If not specified, unlimited will be used. The end time can also be set to 'now', in this case the timespan parameter will be taken and the corresponding start time will be calculated.
* '''timespan''': The time span in seconds. Will be used if no startTime but endTime with 'now' is set.
* '''expression''': The filter expression. There are no whitespaces allowed. You may use ‘%20’ instead. See [[Capture module]] for available expressions.
* '''snapPacketLength''': The maximum 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 (= true) or just live traffic (= false).
* '''captureBufferSlotId''': In case a cluster packet ring buffer is used, the id of the ring buffer must be given. The id of the first ring buffer is 0. If this parameter is omitted, 0 will be taken as default value.
* '''captureToMedia''': Whether to store a pcap on an external storage device (= true) or download to your computer (= false).
* '''mm-id''': If you are extracting a Pcap from a parallel Pcap analysis job or a multi device connected Allegro Network Multimeter, you have to specify the device and the slot where to get the data from. The syntax is: <code>mm-id=<device name>:<slot id></code>. If the capture shall be performed on the local device, the device name can be omited (e.g. mm-id=:1 for the first replay slot on the local device).

Example to capture everything from now on:

<pre>curl -k -u USER:PASSWORD 'https://allegro-mm/API/data/modules/capture' > path_to/capture.pcap</pre>

Example to capture a specific IP of the last hour

<pre>curl -k -u USER:PASSWORD "https://allegro-mm/API/data/modules/capture?expression=ip==10.1.2.3&starttime=$(($(date --date="1 hour ago" +%s%N)/1000))&endtime=$(($(date +%s%N)/1000))&fromCaptureBuffer=true" > path_to/capture.pcap</pre>

Example to capture a specific IP of a given time span of the first parallel Pcap analysis slot

<pre>curl -k -u USER:PASSWORD "https://allegro-mm/API/data/modules/capture?expression=ip==10.1.2.3&starttime=$(($(date --date="2020-07-15 08:55:00" +%s%N)/1000))&endtime=$(($(date --date="2020-07-15 09:55:00" +%s%N)/1000))&fromCaptureBuffer=true&mm-id=:1" > path_to/capture.pcap</pre>

=== Pcap upload and analysis ===

Pcap upload and analysis can also be done via API calls.

The PCAP upload is split into 3 commands. First, the replay is being initialized. Then the analyzing is started. In the last step the PCAP is streamed to the Allegro Network Multimeter. Depending on the size of the PCAP the third step could take some time, but the Allegro Network Multimeter already allows access to the statistics of the already analyzed packets via web/API.

The example assumes that PCAP parallel analysis is enabled in the global settings, so the PCAP analysis will be done in slot 1 and a dedicated ring buffer is available.

<pre>
curl -k -u USER:PASSWORD "https://allegro-mm/API/system/replay/upload" -d '{"fileName": "abc.pcapng", "fileSize": '$(stat -c %s abc.pcapng)', "replaySlotID": 1, "forceSlotID": true, "useReplayBuffer": true}'
curl -k -u USER:PASSWORD "https://allegro-mm/API/data/pcap?mm-id=:1" -d '{"command":"start"}'
curl -F 'name=file' -F 'filename=abc.pcapng' -F 'file=@path_to/abc.pcapng' -k -u USER:PASSWORD "https://allegro-mm/API/system/analyze-pcap?replaySlotID=1"
</pre>

=== Virtual Link Groups ===

The Allegro Network Multimeter REST API allows to access all link groups by the parameter '''group'''. The group index starts at zero, which is the default value. If a virtual link group is enabled.

This example extracts the traffic of the IP 10.54.0.254 from the second virtual link group ( index 1 ).

<pre>
$ curl --silent -k -u USER:PASSWORD "https://allegro-mm/API/stats/modules/ip/ips/10.54.0.254?group=1" | jq '.interval[1] + .interval[3]'
</pre>

=== Parallel pcap analysis ===

The Allegro Network Multimeter can process in parallel offline traffic like a pcap file or a ring buffer. In case a parallel PCAP analysis is running, the API call must be given either the additional header field <code>"X-AllegroPackets-Multimeter-ID: :1"</code> or the parameter mm-id with the PCAP instance ID.

This allows to extract information of automated pcap uploads.

=== Multi-device analysis ===

If the Allegro Network Multimeter is configured as a gateway for multiple Allegro devices by the [[Multi-device settings]], you need to add either the additional header field <code>"X-AllegroPackets-Multimeter-ID: hostname"</code> or the parameter mm-id where the hostname must be the same as configured in the multi-device settings.

== REST API Examples ==

==== MAC statistics ====

Extract the packets per second statistic of the MAC broadcast address

<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/mac/macs/ff:ff:ff:ff:ff:ff'</pre>

==== IP statistics ====

<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips/10.1.2.3'</pre>

==== Pretty displaying JSON output with jq ====

<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm-XXXX/API/stats/modules/ip/ips/10.1.2.3' | jq</pre>

==== Capture a specific IP ====

<pre>curl -k -u USER:PASSWORD 'https://allegro-mm-XXXX/API/data/modules/capture?expression=ip==10.1.2.3' > path_to/capture.pcap</pre>

==== Capture two IP addresses with ports on a specific Layer 4 protocol ====

<pre>curl -k -u USER:PASSWORD 'https://allegro-mm-XXXX/API/data/modules/capture?expression=IP==10.1.2.3:62887 and IP==10.1.2.100:548 and l4Protocol==TCP' > path_to/capture.pcap</pre>

Generic troubleshooting processes

2022-04-21T09:07:57Z

Mark:

'''Allegro Network Multimeter troubleshooting workflows'''

Every now and then we get asked, what a (generic) troubleshooting approach/workflow with an Allegro Network Multimeter would look like.

And, rightfully so, because the endless possibilities of an Allegro Network Multimeter might be overwhelming for some.

In this tutorial, we’ll go into several topics that might be of interest to you -the user- while working with an Allegro Network Multimeter.

== The basics ==
It all starts with basic understanding about what’s actually presented on your screen.

When it comes to providing you with elementary yet essential and actionable troubleshooting insights, Allegro Packets has got you covered with the “Top users” and “Quality” dashboards.

Both can be found at the top of the control menu, at the left hand side of the web interface.

[[File:Top users.png|900x900px]]

''Above: access to “Top users” and “Quality” screens highlighted in the green box''
==TOP users ==
The “Top users” screen is a great place to start your generic troubleshooting workflow.

The top users screen provides you with high-level information about what is going on in your network.

On this page you will find trending graphs and tables, depicting total packets and bytes for the top 5 IPs, top 5 MACs and top 5 protocols that were traversing your network – during the selected time interval.

Toggling between tables and graphs is very easy, by simply clicking the respective icon next to the widget’s caption.

[[File:Top_Sending.png|alt=|none|frame]]

When troubleshooting or better understanding network behavior, most of the times it makes sense to “take a step back” and look at the bigger picture or larger trend.

To accomplish this with your Allegro Network Multimeter, you can switch the -viewable timeframe- at in the top right-hand corner of the web interface.

[[File:Time_frame.png|alt=|none|frame]]

Let us for example change the viewable timeframe from 1 minute LIVE to “1 day LIVE” or “Last day”.

Now we have a clear overview of the TOP talkers over a 1 day timeframe.

For identical time frames, e.g. “1 Day LIVE” and “Last Day”, both view modes will display exactly the same graphs.

However, in table view (depicted below) the practical difference between the two becomes very clear.

[[File:Top talker 2.png|1000x1000px|alt=]]

As becomes clear from the above illustration, LIVE-view will display TOP Talker information -for the selected LIVE timeframe- (in this case 10 minutes),

accompanied with live traffic indicators based on packets per second and bits per second.

When selecting the “Last 10 minutes” view mode, the TOP talkers will be accompanied by total traffic in packets and Bytes – during the selected time frame.

This can be of great help to more quickly and easily identify communication relations.

The download buttons, that you find everywhere throughout the Allegro Network Multimeter web interface, give you quick and easy access to pre-filtered Pcap files.

[[File:Get_Pcap.png|alt=|none|frame]]

With the pcap download buttons, pcap-files can be retroactively (back-in-time) extracted out of the Allegro Network Multimeter ring buffer.

The download buttons can also be used to initiate pre-filtered Live captures.

E.g. clicking the download button next to IP 192.168.178.101, will initiate a capture that is already pre-filtered to only capture traffic containing that IP during the selected time interval.

Again, such time interval may be in the past, as the Allegro Network Multimeter is able to extract the requested packets from its packet ring buffer (if the specific time frame and traffic was recorded).

== IP details page ==

If you want very detailed information about a certain IP, go to the IP-details page of that specific IP.

This is easily done, by clicking on an IP, everywhere throughout the Allegro Network Multimeter web interface. This will bring you to the IP-details page of that specific IP-address.

The IP-details page, gives you 1-click access to all sorts of network performance information -during the selected time frame-.

The different tabs that you can go through on the IP-details page, are highlighted in green in the image below.

[[File:IP details TABS.png|1200x1200px]]

Click on the image below for an enlarged view of a full IP details page.

[[File:IP details.png|none|thumb|495x495px]]

As you can see, it is very easy to look into and investigate the (mis)use of QoS and protocols on a per IP basis.

From the IP details page, you can also quickly and easily look into communication relations on connection/flow level, and even take a deep dive into the TCP-statistics for that IP.

== Quality dashboard ==

For quality and performance assessment, the Allegro Network Multimeter quality dashboard is a great place to start.

All of the most important graphs, related to high level quality and performance monitoring/troubleshooting, are gathered on this page.

[[File:Quality Dashboard.png|660x660px]]

=== Burst Analysis ===
The first graph on Allegro Network Multimeter’s predefined quality dashboard, represents “Burst Analysis”.

Because the Allegro Network Multimeter supports data measurement intervals (sampling rates), as detailed as 1 ms, you can identify instances where a Link is 100% saturated, for very short fractions of time.

Evidently, micro bursts could potentially be (part of) the root cause of network performance issues.

Other than Allegro Packets, most monitoring & troubleshooting solutions are unable to pick this up, because of “low resolution” data sampling (i.e. ≥ 5 minutes).

=== Response times ===
The second graph provides you with trending information about global response times for TCP and HTTP, SSL, DNS plus DHCP.

Clicking on “Application”, will bring you to the response time overview page, where trending response time graphs for HTTP, SSL, DNS and DHCP are individually presented.

[[File:Response times.png|1000x1000px]]

From here, it is very easy to identify -and zoom in on- timing related issues that happened on the network.

In the 1-day time frame exampled above, clearly HTTP and DHCP show instances where response time deviated massively from the overall median line.

You can select such a spike in the graph by clicking and holding the left mouse-button, selecting the spike and then releasing the left mouse-button.

When zoomed in to your liking, click on the graphs title (e.g. DHCP) which will bring you to that specific details page.

[[File:DHCP.png|1100x1100px]]

Because you already zoomed into to a specific time frame on the graph, this page will now only show you the client / DHCP-server relations, that happened during the time frame that you selected in the graph.

Also on this page, you’ll find a download button for simple (retroactive) extraction of a Pcap, that is pre-filtered to only contain DHCP and BOOTP packets.

=== UDP Jitter & packet loss ===
The next two graphs provide trending and actionable insights for UDP-based protocols RTP and Profinet. First up is the graph depicting Jitter over time.

Bad jitter can have a very negative impact on business critical production services and on VoIP- / Unified Communication services.

[[File:Jitter.png|700x700px]]

From this graphs, it is very easy to quickly identify quality issues, such as instances where jitter is above 20ms in networks where VoIP is being used.

=== TCP retransmissions/packet loss ===
The next two graphs provide trending visibility and information about TCP packet loss in your network.

TCP retransmission are seen in all networks, it’s the amount of retransmission -and better yet the retransmission ratio in percent- that indicate if things are problematic in your network.

This is why graphs for both TCP retransmissions in absolute numbers, as well as in ratio are presented to you.

[[File:Tcp.png|700x700px]]

As a reference;

For wired infrastructures, a retransmission ratio of up to 2% is generally accepted to still be okay.

In wireless infrastructures however, retransmissions of up to 10% are very common and considered to be a well-functioning wireless network.

=== TCP Zero window ===
For identifying application performance problems and/or server capacity issues, the “TCP Zero Window” graph is a very, very powerful instrument.

Here’s why…
TCP zero window packets are being sent out by a client or (mostly) server, whenever it cannot optimally handle the oncoming traffic any more.

Because of whatever reason, its receive buffer is full, and the device will start every sending party to slow down – by means of TCP zero packets.

[[File:Zerowin2.png|1200x1200px]]

Couple of reasons for high (continuous) counts of TCP zero window packets, may be things like:

* Too much oncoming traffic, relative to the NIC Link speed
* Applications that are too slow or problematic and therefore are unable to keep up
* Storage that is too slow or problematic, and therefore is unable to keep up.

== IP statistics (all IPs) ==

If you are looking for network information based on multiple or all IP addresses, or want to start your troubleshooting journey from an IPs perspective – the L3 IP Statistics page is the right place for you.

[[File:L3- IPs.png|1100x1100px]]

IPs (of interest) can quickly be found, by entering (part of) an IP or resolved-name information.

When searching for a singular IP or IP-range, add a subnet mask to the IP for optimal results.

E.g. searching for 192.168.178.1 will give you a filtered list with all IPs matching 192.168.178.1xx. To mitigate this, add a subnet mask like so 192.168.178.1/32.

On the IP Statistics page, it is also possible to only present IPs that match certain (quality) metrics.

To start filtering with a “complex filter”, start your entry in the search bar with a "(". The next possible inputs are then shown to you, as a form of help.

By using a “complex filter” in the search bar, you can narrow down the number of displayed IPs, based on the following parameters:

"name", "ip", "packets", "bytes", "pps", "bps", "firsttime", "lasttime", "tcppackets", "udppackets", "tcppayload", "tcpRetrans", "tcpRetransRx", "tcpRetransTx", "category", "vlan", "mpls", "outermpls", "innermpls", "interface", "validconnections", "invalidconnections", "tcpZeroWindowRx", "tcpZeroWindowTx", "ipgroup", "mtu", "mtuRx", "mtuTx", "tcpMissedData", "("

When typing in complex filters, the use of and/or/must contain/exact match operators is allowed in the form of: AND, &&, OR, ||, ==, ===

''This page might be extended over time.''

VoIP monitoring and troubleshooting

2022-04-21T09:06:24Z

Mark:

==Intro==
Nowadays, in most companies phone systems are based on voice over IP…in short VoIP. While VoIP has quite some benefits over “legacy” telephone infrastructures, VoIP also introduces new challenges for network administrators and engineers who are responsible for upholding a great network.
More often than not, VoIP services and traffic are passing through the very same infrastructure components that also handle your regular server/end-point communication. Thankfully VoIP is a rather low-bandwidth type of communication (E.g. codec G.711 = 64 Kbps BR* / 87.2 Kbps NEB*). On the other hand however, Administrators better be on their A-game concerning the overall quality of their network, because VoIP relies on impeccable timings and a minimum amount of packet loss.
*BR = Bit rate / NEB = Nominal Ethernet Bandwidth (one direction)
Allegro Network Multimeter helps network administrators and engineers by providing full visibility into VoIP communications, paired with advanced VoIP troubleshooting capabilities.

VoIP monitoring and analysis with Allegro Network Multimeters can be done in real-time and back in time.

==Global SIP statistics==
[[File:Sip statistics.png|none|thumb|800x800px]]

VoIP analysis and debugging in Allegro Network Multimeter, can be reached via the left menu
L7 – Application -> SIP statistics. The overall SIP statistics dashboard, as shown in the picture above, will be presented to the user. This screen is intended for “taking a step back” and enables the administrator to look at statistics and incidents over time. Were there instances of abnormal packet loss or high jitter over the past 4 days, might be a good example.
The graphs are rather self-explanatory and depict traffic distribution stats, packet loss and jitter information, a concurrent call trend graph and statistics revolving SIP signaling response types/codes. Sections of all graphs can be selected with the mouse, to zoom into certain timeframes or incidents of interest.

==VoIP calls analysis screen==
Going into the second tab “SIP calls”, the user will be presented with a list of all the VoIP calls during a selected timeframe and/or in real-time. Multiple tables with statistics information can be toggled ON or OFF at the users discretion and tables can be sorted.
[[File:Voip Call analysis.png|none|thumb|800x800px]]

To investigate a specific phone number, e.g. from a person reporting call (quality) issues, simply type in the phone number in the search bar and sort your table of interest (e.g. "initiation" time) accordingly.
Throughout the Allegro Network Multimeter, the search bar can also be used for applying complex display filters. If for example, from 100’s or 1000’s of indexed VoIP calls, you are only interested in the unsuccessful ones…(statuscode !=200) would apply.
We’ve already touched on VoIP’s sensitivity to timings. One may state that, jitter above 20ms in either call direction, starts to impact and degrade call quality. The higher the jitter the more call quality will suffer. For a list showing only calls that were affected by bad jitter, filter (avgjitter > 20) is easily set within the search bar on the SIP calls screen.
[[File:Advanced filter.png|none|thumb|800x800px]]

==Detail report for an individual call==
Next to each and every specific call, you will find a couple of buttons to make your life so much easier. Please note that the column toggle “PCAP” must be enabled. Right now we will go into the “Details” button as highlighted below.
[[File:Individual voip call.png|none|thumb|800x800px]]

Administrators and engineers often find themselves in a position where they are interested in the history of events or a detailed report. A one pager that tells the whole story and features a couple of graphs to more easily translate to the less tech savvy people who might be involved. Clicking on the “Details” buttons next to a call will give you just that.
[[File:Voip Call details screen.png|none|thumb|800x800px]]

When the call details page is opened, it is important to first click on one of the “Zoom” to call buttons. When doing so, the data shown in the Allegro Network Multimeter will be focused (or zoomed in) on the exact time and duration in which the call started and ended. You will now see the data and statistics revolving the call nicely centered in their respective graphs.
Condensed into one view, you’ll find your facts and figures about the codecs and the network on the left hand side of the screen, trending graphs of key quality metrics in the middle and capture buttons on the right of the screen.

=== Packets, jitter and MOS ===
In the top graph you can see the packet stream (or data stream) for the specific call. The second graph holds all the information revolving packet loss and overhead packets. The third graph displays the oh so critical jitter information. Fact is, that the performance and quality of a network and its services, is dependent on multiple factors. The VoIP specific scoring algorithm called MOS, calculates a call quality grade from 1 (bad) - 5 (best), based on multiple dependencies such as the CODEC, its sensetivity to packet loss and the actual packet loss in the network.

In every graph dips or inconsistencies will be clear to see. The measurements shown are available and displayed per individual A/B number i.e. the caller and the callee .

===Audio Level Graph (dBFS)===
The fifth graph from the top shows audio Level information about the RTP audio coming from both directions. How does this help me you might ask. Well, since at Allegro Packets we are also network engineers and think like one, we will gladly explain how this can help you A LOT.
Let’s say you receive an end-user complaint describing -bad quality during a phone call-. Most likely you’ll barely ever receive complaints more detailed than this anyway. However, as an administrator you might already be considering voice distortion, interrupts or crackling noise.
Now, voice distortion, delays and interrupts may very well be caused by packet loss and/or bad jitter. So navigating to the call detail screen to investigate how bad the packet loss and jitter were at the time of the call, you instantly see that…?...no packet loss, perfectly low jitter…EUREKA! It’s not the network.
In such cases you can easily take a glance at the audio Level graph for visual confirmation of audio clipping (the level where distortion sets in) whenever the graph goes above 0.
[[File:VoIP Audio Level.png|none|thumb|800x800px]]

===RTCP reports===
Notice that the Allegro Network Multimeter also decodes the RTCP reports that are sent between handsets. This provides additional valuable insights regarding packet loss and estimated jitter, as experienced by a caller/callee handset (outside of your network) itself.
[[File:VoIP RTCP reports.png|none|thumb|800x800px]]

==Getting a pcap from SIP, RTP, RTCP==
We've learned from network administrators and engineers that it is not an easy task to capture and view the SIP and its corresponding RTP of a call in Wireshark. Especially on Links where multiple calls were active. This is however very easy with an Allegro Network Multimeter. Next to each individual call on the Voip Calls screen (and on the call Details page), you will find several download buttons. Herewith the corresponding and correlated data can easily be extracted and downloaded as a pcap. Whether you are interested in viewing just the SIP flow in Wireshark, or retrieve a calls’ correlated SIP+RTP+RTCP all in one cleanly filtered PCAP for post analysis. It’s all just 1 click away in the Allegro Network Multimeter. The slicing of recorded packet data is supported and fully customizable within the Allegro Network Multimeters. For instance, one may want to slice RTP packets after the first 80 bytes to eliminated the possibility for listening in on conversations.
[[File:Sip rtp download.png|none|thumb|800x800px]]
[[File:Wireshark SIP RTP.png|none|thumb|800x800px]]

==Audible VoIP troubleshooting (MP3)==
Crackling, echoing or muffled audio may very well not be due to the network. Unfortunately these specific things also cannot be derived from the information in the audio Level graph. It’s cases like this for which the Allegro Network Multimeter provides download buttons for retreiving calls as an MP3. As such, where allowed or where troubleshooting benefits outweigh privacy constraints, the administrator/engineer is enabled to download calls in form of an MP3, for audible troubleshooting. This greatly helps troubleshoot very specific issues, and provides audible evidence of bad headsets (cable), terrible car kit or other things alike. This feature may be disabled for certain users by means of user-roles. Also, the slicing of recorded packet data is supported by the Allegro Network Multimeter to a great extent. Therewith and per example, one is able to slice RTP packets after the first 80 bytes, to prevent the reconstruction and replay of audio.

USB Presenter Capture

2022-04-21T09:05:07Z

Mark:

This page describes how the Allegro Network Multimeter allows a user to start a capture with a USB presenter. This capture can be actioned 'Back in Time' for a defined period.

In addition, the capture files can be uploaded to an SFTP server at a defined time.

This feature has been designed to allow non-IT staff to record/initiate pcaps when an error occurs; it also allows for captures without opening a Web interface.
 

== Use case example ==
An IT or VoIP service provider needs to troubleshoot intermittent issues at a (residential) customer.

The service provider is limited by time, resources and packet capture/data collection constraints (AVG, GDPR).

With the Allegro Network Multimeter "USB Capture trigger" functionality, a "fool proof" remote control is handed to the customer, with the instruction to press any button when the issue arrises.

A simple button press on the remote, will initiate a pre-configured capture (filter + duration) around the time of the "incident", e.g. from 60s before until 60s after the "incident".

As only packets around an issue are being recorded and saved as a pcap, the service provider needs not sift through huge amounts of data for root-cause analysis.

Also, there are little to no privacy implications, since the capture was end-customer initiated, pre-filtered and limited to short time-intervals only.
 

== Requirements ==

This feature is supported by all Allegro Network Multimeters (also VM) from firmware release V3.0.

As of now, the '''Logitech R400''' is supported. Allegro will add more presenters on request. An optional USB sound device will play a beep when a key has been pressed.

It requires a free USB 2.0 (or higher) port on the Allegro Network Multimeter. An internal or external disk needs to be configured at '''Generic''' → '''Storage,''' and a [[Packet ring buffer|ring buffer]] must be configured.

Please note that the capture initiated by this feature is extracted from the ring buffer, and ring buffer filter rules for packet slicing will affect exported pcaps.
 

== USB Capture Trigger Setup ==

Connect the Logitech R400 USB dongle to the Allegro Network Multimeter. If you have a Allegro Virtual Edition, please pass-through the USB device directly to the Allegro VM.

Once this is done, navigate to the '''Settings''' -> '''Expert settings''' page and open the '''USB capture trigger'''.
 
[[File:Presenter dialog.png|600px]]

Whenever a key on the presenter is pressed, a pcap will be generated.

NOTE! - The pcap end-time, is when the button on the presenter is pressed and the start time is defined by the capture interval.

This means, that a configured interval of 60 seconds, will generate a capture (pcap) of the full 60 seconds '''prior''' to when a presenter key was pressed.

Captures are stored in the root directory of the storage partition or, if enabled, in the upload directory (cue) for periodic/automated SFTP uploads.
 

== SFTP Export Setup ==

The Allegro Network Multimeter can automatically upload pcap files to an SFTP server from the upload directory on the disk.

To configure it, please navigate to '''Settings''' → '''Remote Access and Export''' → '''Pcap export via SFTP'''.

This allow to export all captured pcap files at a certain time of day. As example it can be used to transfer pcaps during the night from remote locations to a central SFTP server.
 
[[File:Sftp export.png|1000px]]
 

== Advanced Multi-pcap Setup ==

There are situations where the Allegro Network Multimeter may be configured to record multiple separate pcaps, each with specific filters, with only one button-press on the usb-presenter.

This can be done by enabling the '''USB capture filter''' in the '''USB capture trigger''' dialog. Filter syntaxes are described in the [[Capture module]].

A good example is the installation of an Allegro 500 with 2 links and 2 virtual link groups ( see [[Virtual Link Group Configuration Guide]]), one before and one behind the firewall.
 
[[File:Presenter filter group.png|600px]]

As a second example, you can record pcaps of up to 4 different IP addresses at the same time with just one click.
 
[[File:Presenter filter ip.png|600px]]

Debugging MS Teams Traffic

2022-04-21T08:57:08Z

Mark:

This page describes how Microsoft Teams and Skype traffic can be analyzed with the '''Allegro Network Multimeter'''.

== Microsoft Teams and Skype client protocols ==

The Microsoft Teams and Skype clients relie on SSL for all control based traffic and RTP for all audio/video based traffic.

The '''Allegro Network Multimeter''' allows you to search for traffic to the Microsoft cloud, helps to analyze the response time of the SSL encrypted control traffic and analyzes the RTP traffic for quality parameters like packet loss, jitter, etc.

== Microsoft Teams and Skype control traffic ==

Microsoft Teams and Skype control traffic is SSL encrypted. This does not allow for decoding and analysis of the control connection content. Since SSL uses TCP as the Layer 4 protocol, all of the TCP connection quality statistics can be used for debugging. Additionally, the response time for the SSL handshake and the first encrypted SSL data response time is available.

The most important quality parameters are:

* TCP handshake response time
* TCP retransmission rates
* TCP Zero Window times
* SSL hello handshake response time
* SSL first data response time

Please read the [[TCP module]] and [[SSL module]] for more information on these and more counters.

A simple way to see an overview of the response time for Microsoft Teams and Skype servers is the '''IP statistics''' table. You can use the free text search for "skype" and select the graph dialogue: "TCP response time". This will present you the top IP addresses with a correlated name to '''skype''' and their TCP response times. You can also enable the '''Timing''' columns to view and sort for response times.

[[File:Skype response time.png|600px]]

This graph shows you the TCP stack delay to confirm data reception. Note that many TCP stacks wait a few milliseconds if there is no data to respond to(see [[https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment Wikipedia TCP delayed acknowledgment]]). Any additional delay on top of this time (usually 40 ms) indicates a significant roundtrip time delay. If you have installed the Allegro Network Multimeter close to the Microsoft Teams or Skype client, it will be the roundtrip time of the TCP packets from your network to the Teams/Skype cloud.

DNS names and IP address ranges for both Microsoft Teams and Skype are subject to change regularly, since the control servers in the Microsoft cloud use load balancing, which can point data to different servers. A current description for Skype for Business can be found here: [https://techcommunity.microsoft.com/t5/skype-for-business-blog/simplified-port-requirements-for-skype-for-business-online/ba-p/77094]

The analysis can also be done for TCP retransmissions and TCP Zero Window statistics. If you have installed the Allegro Netwok Multimeter close to the Microsoft Teams or Skype client, this will indicate if the data sent to the Teams/Skype server required a retransmission on the WAN link or if the receiver buffer is full, indicating receiver overload.

== Microsoft Teams and Skype audio/video traffic ==

The Microsoft Teams and Skype audio/video traffic is sent by encrypted RTP frames. As RTP encryption is applied only on the content and not on the RTP header, you can still debug the RTP traffic with the RTP decoder output of the Allegro Network Multimeter.

To get an overview of which IPs have used RTP, you can use the '''Applications''' → '''RTP statistics''' page and search for Teams or Skype.

[[File:Skype rtp statistics overview.png|1000px]]

This allows you to see which IP address have used the protocol RTP. It shows an overview of the RTP packet loss and jitter based on RTP sequence numbers. To obtain detailed information about individual connections, click on the IP address. This will show RTP packet loss and jitter for each connection.

[[File:Skype rtp statistics ip detailed.png|1000px]]

Analyze connections between remote sites

2022-04-21T08:46:28Z

Mark:

== Problem ==
Often multiple locations are connected by dedicated
lines. Sometimes, network problems are reported which cannot be easily
tracked down. These can be caused by issues in the local network, the remote
network, or the dedicated line itself.

This section describes how to use two Allegro Network Multimeters to
measure packet loss and network latency between a local
installation and a remote site.

{|
|[[File:Ap-mm-path-measurement-3.png|600px|thumb|right]]
|}
The image shows an example setup for measuring packet loss and latency
between two networks which are connected via the
Internet.

== Requirements ==

# You need two Allegro Network Multimeters (any model).
# One Allegro Network Multimeter (the main device) will receive traffic information from the remote Allegro Network Multimeter via a standard SSL connection; the main device must be able to connect to the remote device. If a firewall is in place between both devices, an additional rule might be necessary to connect the remote device on port 443.

== Device installation ==

# Install the main device in your network where it can see the traffic sent and received to the remote site. The Allegro Network Multimeter can be installed on a Mirror Port of a Switch which sees all the traffic, or inline between the local network and uplink to the remote site.
# Install the device on the remote site at a network position where it sees all traffic from and to the local network. Again, this can be a Mirror Port of a Switch on the remote site, or inline between the remote network and the link to the local network.

== Configuration ==

{|
| [[File:Ap-mm-path-measurement-1.png|600px|thumb|right]]
|}

# Remote device: First, the remote device must be added to your multi-device setup, which can be configured under [[Multi-device settings|Multi device settings]].
# Main device:
## Access the web page of the Allegro Network Multimeter and go to "Generic -> Path measurement".
## Switch to the configuration tab.
## Click on the toggle button to enable the feature.
## Enter an descriptive name for the main device to make it easier to read the statistics.
## For the remote device, enter the information described above. You can select a descriptive name for this device also.
## Enter a maximum packet delay. This parameter defines how long the main device waits for data from the remote device until it decides whether or not a packet has been lost. Larger values requires more memory. Typical values are between 2 and 5 seconds.
## Finally save the configuration settings.
## At the bottom of the page a note will appear in most cases that a restart of the packet processing is necessary. Follow the link to the administration page and click on "Restart processing". Be aware that this will interrupt the network connection for a few seconds (if in Bridge mode); you will lose all previously measured data.
## Return to the "Generic -> Path measurement" page.
## The "Measurement" tab should indicate that the measurement status is either warming up or running.
## The "Remote client status" should say "connected". If not, a button appears which can be clicked to reconnect to the remote device. Any error will be displayed in an information box.

== Evaluation ==

{|
| [[File:Ap-mm-path-measurement-2.png|600px|thumb|right]]
|}

The "Measurement" tab shows the results of the analysis of packet data
between the main and remote device(s).

At the bottom, the fourth graph shows the packet rate of all traffic
that is used for measurement. This includes the traffic seen on both
devices, but excludes the traffic that is only seen on one device.

=== Checking packet loss ===

To identify packet loss during a time interval, first select the
corresponding zoom level to see the entire time range. You can also
select the time range by clicking into the graph.

The second and third graphs show the number of packets lost
separately for each direction. If packet loss occurred, you will see a
non-zero value in the graph.

Keep in mind that the analysis waits the configured maximum packet
delay before deciding if a packet is lost. This means that the
time of the packet loss is actually before the data point in the
graph, up to the maximum number of packet delay seconds in the past.

Example: In the graph above, a packet loss is indicated at
17:45:34. For a configured maximum packet delay of 5 seconds, the
original lost packet was sent 5 seconds earlier starting from
17:45:29.

=== Checking latency ===

The "Two-way latency" graph shows the minimum, maximum and average
delay of both aggregated directions. Select the zoom level for the
required time period and check if there are any unusual events in the graph.

A high maximum but low average value means that there have been a few
points in time where the delay was high but the majority of the traffic experienced a
lower delay.

A high maximum and high average indicates a general latency problem.

A high latency does not necessarily mean low bandwidth since network
buffers can handle latency and still provide high bandwidth. But
real-time applications such as audio calls or video chats will
exhibit poorer quality due to high latency.

=== How to identify packet loss or high latency ===

First, select the relevant time window when the packet loss or high
latency occurred.

Once the time window has been selected, switch the "IP -> IP
statistics" to see which IP addresses had traffic within the time
window.

Packet loss for TCP connections always generate retransmission
packets. Toggle the display of "TCP counters" on the top bar and sort
the table for "TCP retransmissions" to see the IP addresses with the
most retransmissions in that time period.

Select an IP address which shows a high retransmission rate and check its peers or connections to
identify the traffic during the packet loss or high latency period.

== See also ==

Read on about the [[Path measurement|Path measurement]] module for additional information about configuration, usage, and limitations.

Capturing

2022-04-21T07:53:00Z

Mark:

== Introduction ==
With the Allegro Network Multimeter it is very easy to start and retrieve very specific network packet captures in pcap format. Such pre-filtered pcap files, can then easily be investigated with Allegro Network Multimeter's built in Webshark or a tool like Wireshark.

== How can I create a pcap of a specific IP or MAC address? ==
All Allegro Network Multimeter L2-L7 analysis modules, feature dedicated pcap buttons throughout the dashboard,
to very specifically capture most traffic types in a really easy way.

For example; to capture a specific IP address, in the left menu navigate to 'L3 - IP' -> 'IP' statistics. 
Then, easily find the desired IP address by sorting and/or a filtered search, and clicking the capture button - [[File:Capture button.png]].

When a specific time interval is displayed in the dashboard, only the payload during that time interval is extracted.
[[File:IP pcap.png|none|thumb|800x800px|alt=]]

To quickly find an IP address, you can sort the IP table via almost every column. The search bar/filter bar provides a quick method to reduce the table content to your hearts content. This can be done by typing in (fragments of) the
IP address, (fragments of) the DNS name or by entering a "complex" filter.

[[File:Search bar.png|1100px|thumb|alt=|none]]

Another quick way to create a pcap of a specific address, is to use Allegro Network Multimeter's Simple Capture feature.

In the menu go to 'Generic' -> 'Capture traffic'. Now, in the "start simple capture" section, toggle the desired capture fields (e.g. MAC, IP), type the address, and click the "Start capture" button.

[[File:Ap-mm-capture-capture-simple.png|600px|thumb|alt=|none]]

== Which settings should I choose? ==

After clicking on the capture button, the dialogue "Choose capture settings" will be
displayed. Here you can limit the start and end time of the capture and select
whether to download the pcap file directly to your
computer or store it on the Allegro Network Multimeter attached storage device. You can
limit the captured packets to a given length if you do not need the full packet
and just want a small pcap file that opens faster in Wireshark.
[[File:Choose capture settings.png|none|thumb|600x600px]]

Clicking the "Save capture" button begins the configured capture.

Clicking on the "Webshark preview" will open a basis web-based Wireshark window within the Allegro Network Multimeter web interface.

A fully detailed explanation of the "Choose Capture Settings" dialog is documented in our Wiki here: [[Capture module#Capture settings dialog]]

== How can I extract traffic from the past? ==

With the Allegro Network Multimeter packet ring buffer, it is possible to extract traffic from the past as a pcap file. The packet ring buffer is stored on the internal storage device of an Allegro Network Multimeter (if your model is equipped with one), or on an externally attached USB storage device. A fast USB3.x capable SSD is recommended. A USB thumb drive can also be used, but some burst packets may be dropped if the thumb drive write speed is too slow.

You can see an overview about all storage devices that can be used for the Allegro Network Multimeter under 'Generic' -> 'Storage'.
{|
| [[File:Ap-mm-capture-storage.png|600px|thumb|right]]
|}

An external SSD is attached to the USB port and is not yet activated. Click the
"Activate" button so the device can be used. If the filesystem of the disk is not
suitable for the ring buffer a warning will pop up prompting you to format the disk.
After formatting or activating, the storage page will display information
on disk usage and an overview of all files on the disk.

{|
| [[File:Ap-mm-capture-storage-active.png|600px|thumb|right]]
|}

Now that the storage is active, the ring buffer has to be created if not already
prepared during formatting. This can be achieved in 'Generic' -> 'Packet ring buffer'.
Click the "Create ring buffer" button.

{|
| [[File:Ap-mm-capture-create-ring-buffer.png|600px|thumb|right]]
|}

The size of the ring buffer must be specified. If no pcap is required on
the storage device, the ring buffer will use 100% of the storage device capacity.

{|
|[[File:Ap-mm-capture-ring-buffer-size.png|600px|thumb|right]]
|}

When the packet ring buffer is created and running, the "Packet ring buffer"
statistics page displays information about the ring buffer usage and several
graphs restored or filtered traffic are also displayed. A filter can be applied
to determine which packets are stored in the ring buffer. Check out the chapter
[[Generic_modules(Teil_3)#Packet_ring_buffer|Packet ring buffer]] for more details.

{|
|
[[File:Ap-mm-capture-ring-buffer-statistics.png|600px|thumb|right]]
|}

When the packet ring buffer is up and running, any capture may be utilized to
extract traffic from the past. Select a timespan in any graph of the user interface
by left-clicking with the mouse and then click a pcap button.
The selected timespan will be displayed in the start and end time fields of the
"Choose capture settings" dialogue.

{|
|
[[File:Ap-mm-capture-choose-capture-settings-2.png|600px|thumb|right]]
|}

Start and end times can be changed by using the date and time popup window when
selecting the time fields or clicking the dedicated buttons for commonly used times.
If the start time is earlier than the start of the packet ring buffer, it will
be adjusted to the start and a hint will be displayed.

== Is it possible to plan a future capture? ==

Yes. Simply select the desired start time in the "Choose capture settings" dialogue
and the capture will start with the first packet at that time.

On the 'Generic' -> 'Capture traffic' page there is also a tab 'Planned captures' where captures to a storage device can be configured and those captures can even be set to automatically repeat.

== Create complex captures with several criteria ==

Captures can be started with complex filter expressions for a specific capture of e.g.
an IP address or a Layer 7 protocol.

To see a basic overview, start a capture from any module. You can see all running active captures at the capture button at the top bar of the web interface.

{|
|
[[File:Ap-mm-capture-filter-expression.png|600px|thumb|right]]
|}

On the "Start simple capture" page, all frequently
used filter expressions are easily accessible. The resulting expression is
displayed below.

{|
|
[[File:Ap-mm-capture-capture-simple-2.png|600px|thumb|right]]
|}

This expression can be used and edited in the expert filter field. All
filters can be combined with "and" / "&&" or "or" / "||". Parentheses may
be used to clarify precedence.

The chapter [[Capture_module|Capture module]] explains every possible filter.

== Generate a pcap via the command line ==

It is easy to generate a pcap via the command line or in scripts with "curl"
which is a tool available for recent versions of Windows 10, Linux and MacOS.

Just type:

{| class="wikitable"
| curl -k -u USER:PASSWORD https://allegro-mm-XXXX/API/data/modules/capture?expression=ip==10.1.2.3 > path_to/capture.pcap
|}

The user name, password and hostname have to be the same as the ones used to access
the web interface. Every filter expression that can be used in the web interface
can also be used here.

Check out the chapter [[Capture_module|Capture module]] for further information.

== It takes too long to open a pcap file in Wireshark. What can I do? ==
If you are in a situation where you have a large pcap and are only
interested in the traffic between two specific IP addresses, you can
use the Allegro Network Multimeter to analyze the pcap file and
extract the specific traffic for post-processing with tools such as
Wireshark. See [[Forensic_pcap_Analysis|Forensic Pcap Analysis]] for details.

Find Profinet problems

2022-04-20T10:59:04Z

Mark:

== Problem ==
How can you use the Allegro Network Multimeter to quickly and easily examine
a network of Profinet devices and find problems?

Read all about it on this page and more on our [[Profinet module|Profinet module]] page.

== Preparation ==
Attach the Allegro Network Multimeter to the Mirror Port of a Profinet-capable
Switch or use a Tap. Once placed there, the Multimeter will analyze all packets
and collect live and back-in-time Profinet statistics.

We do not recommend installing the Allegro Network Multimeter inline
in Bridge mode in a Profinet real-time network since it will
cause additional latency of around 50 microseconds. Use a
network Tap to maintain a reliable network connection.

We recommend using the packet ring buffer feature since it allows
for historical specific packet extraction.

== Profinet overview ==
First we start with an overview of the Profinet main device and all Profinet
devices that communicate with the main device or each other. Open the web interface
with a browser and go to 'Application' -> 'Profinet statistics'.

{|
|
[[File:Ap-mm-profinet-statistics.png|600px|thumb|right]]
|}

On this page, an overview of the entire Profinet communication is shown. Here,
traffic was running at a constant 250 kbit/s and then it stopped.
You can see alarms at around 14:11:53. Errors will be presented in
the same way. A jitter graph with minimum, average and maximum values shows
at a glance when there is a deviation in the timing of real-time frames.
Around the same time the alarms were sent, the jitter increases significantly.

The pcap button allows you to capture the entire Profinet-related traffic.

If you wish to see what happened at the same time at this network point,
use the mouse to zoom into a time frame, then navigate to the Dashboard. It
will show an overview of the entire traffic during this time interval. This helps to
identify Profinet issues which are related to non-Profinet traffic such as updates
or streams which can disturb a Profinet setup.

== Profinet devices ==
An overview of all Profinet devices can be seen in the tab "Devices".

{|
| [[File:ap-mm-profinet-devices-alarms.png|600px|thumb|right]]

|}

All significant information is displayed such as byte count and the number of
frames in the selected time span. For fast recognition of alarms and errors you
can sort the device table by clicking on the related column header. A specific
device can be filtered by typing its station name, vendor, MAC or IP address into
the filter field.

MAC addresses are displayed for every Profinet device. IP addresses and Profinet
station names will be shown for all devices as soon as related frames have been
seen.

Two of the alarms on the Profinet statistics page have been issued from WAGO
device 00:30:de:06:66:a5 and WAGO device 00:30:de:06:66:fa with the station
name "montagekanuelekappe".

== Profinet device ==
By clicking on a MAC address you can see detailed statistics for a specific
Profinet device.

Statistics for a device include incoming and outgoing traffic, jitter and the number
of outgoing alarms and errors.

The pcap button enables you to create a capture of all incoming and outgoing traffic for
that particular Profinet device.

== Communication relations ==
The tab "Communication relations" lists all groups of incoming and outgoing frames from this
device. Both source and destination are shown, so the direction can be easily recognized.
{|
| [[File:Ap-mm-profinet-device-comm-relations-alarms.png|600px|thumb|right]]
|}

The "Alarms" tab shows all alarms that have been sent by this device. Here the
WAGO device 00:30:de:06:66:fa with the station name "montagekanuelekappe" sent
an alarm with low priority to the VIPA device 00:20:d5:01:19:45.

Are you interested in a capture of the data during this selected time frame for
further analysis? Just click on the pcap button on the right.

{|
|
[[File:Ap-mm-profinet-device-comm-relations.png|600px|thumb|right]]
|}

In the "Profinet real-time" tab you will see all real-time communication and
checks for poor jitter values.

How is the jitter calculated? The clock period of two adjacent frames is calculated
by using the cycle counters. It is then compared to the measured time between
these two frames. A good jitter value would be zero, meaning all frames arrive
without deviation within the same clock period. A poor jitter value would be equal to
or even larger than the cycle time.

Does the device have a problem with sending frames and is it the only one with
poor jitter values or even frame losses? Or is a Switch in the network causing
the problem? Check the jitter values and errors of other Profinet devices that
communicate over the same Switch. Or, attach the Allegro Network Multimeter to
another Switch and see if the jitter and errors decrease.

______________________________________________________________________________________________________________________________

More information about PROFINET monitoring & troubleshooting with Allegro Network Multimeter can be found on our very detailed [[Profinet module|'''Profinet module''']] page.

Investigate Network Load

2022-04-20T10:54:40Z

Mark:

== Challenge ==
How can you use the Allegro Network Multimeter to quickly and easily examine
the load on a network? Let's take a practical example: multiple users
complain that their network connection is sometimes very slow.
For example; an event between 9am and 10am.

== Dashboard ==
First we start with an overview in the Dashboard.
Open the web interface via a browser.

[[File:Allegro Default Dashboard.png|1000px|Allegro Network Multimeter Dashboard]]

== Time Selection ==
Next select a time view in the upper right corner, which is a longer timeframe than the
interval to be examined:

{|
| [[File:Ap-mm-time-select-1-day.png|300px|thumb|right]]
|}

In this case, we are looking for events from this morning and I chose the previous
day's view. Now select the time period in which the users have reported
problems by selecting (click 'n drag) such section with the mouse:

{|
| [[File:Ap-mm-select-traffic-mouse.png|600px|thumb|right]]
|}

The Allegro Network Multimeter's internal database now works with the selected time interval
so you can investigate what problems there were. The following points
are easy to clarify on the Dashboard:

* Do you know the TOP protocols? Endpoints in a network can experience increased and unexpected traffic such as large Windows updates. By clicking on the protocol you can see which IPs generated this traffic.
* Do you know the TOP IP addresses? For example, there may be several backups running at the same time which burden the link and internal servers.
* Do you know the TOP MAC addresses? If, for example, significant multicast or broadcast traffic appears here; this can indicate loops or similar issues, and a packet storm can place a heavy burden on a network.
* Is there a high TCP retransmission rate of more than 3 percent compared with similar periods? This can indicate a network segment overload, such as from the WLAN or an end device.
* Is there extremely low or no network traffic during this period? This may indicate link problems such as no connection to the Internet or to another network node.

In our example, Dropbox showed up with a total of 900 MB data transfer.
By clicking on "Dropbox" I can easily see an overview of who triggered this
traffic:

{|
| [[File:Ap-mm-dropbox.png|600px|thumb|right]]
|}

Here, the computer "nb-nina.allegro" generated both uploads and downloads
to Dropbox with rates up to 40 MBit/s. This can lead to user disruption caused by
the uploads and downloads, allowing you to take further action.

By clicking on the IP address, then on the tab "Connections" you can sort the
connections by TCP retransmission:

{|
|
[[File:Ap-mm-connection-retransmissions.png|600px|thumb|right]]
|}

You can use the number of retransmission to estimate if there was a bottleneck
between the Allegro Network Multimeter and the recipient and if more packets had to be retransmitted.
Here in our example, there were 1.4 percent (6MB of 448,2MB) retransmissions with an approx. 12 MBit/s
(upload) to Dropbox. Possibly the uplink was busy at this point and dropped several TCP packets.

If you need an even more detailed analysis, you can use the pcap button to extract the connection packets.

DB mode

2022-04-20T10:43:58Z

Mark:

The DB mode (or Database mode) is special operating mode designed for large Allegro Network Multimeter systems for high traffic throughput.
This mode optimizes the internal database management used for measured network data to be able to process a higher amount of network traffic.
On smaller systems this method introduces an additional overhead so it is only available on selected models.
There is however no difference in the measurement results.

The only side effect of the DB mode is that results might appear with an additional delay in the web interface.
The DB mode uses separate CPU threads for databases management (instead of combined threads for both packet analysis and database management).

''' Configuration settings'''

The DB mode is automatically enabled if the system is powerful enough. On some systems the mode can still enabled manually for special use cases.
If the system supports the DB mode, additional configuration settings appear in the [[Settings#Global_settings|Global settings]] section under the '''Expert settings''' tab.
There are two settings influencing the behavior of the DB mode.

* Queue multiplier: This setting configures the size of the message queue between packet analyzing threads and database threads.
:Usually the value does not need to be changed. If the system reports overload, the [[System_Info_Page|System Info Page]] should be checked. There is detailed load page when clicking on the load percentage. If any of packet analyzing threads show DB message lost counter, the queue size multiply might be increased.

* DB thread factor: This value configures how many packet analyzing threads are managed by a single DB thread.
:Setting this value to 0 disables the DB mode.
:Depending on the complexity of the network traffic, it can be beneficial to increase or decrease the value. The default value on most system is 4 (if the DB mode is available).
:The [[System_Info_Page|load]] graphs for each thread can be checked to decide if the value needs to be changed.

'''Possible reasons to modify the configuration values'''

Depending on the actual network, there can be situations where different configuration settings lead to better overall performance.

1. System overload and skipped packets.
:If packet drops appear, the packet analyzing threads might be overloaded. This can be checked in the load statistics.
:The current load percentage can be clicked to get detailed information about each system component. If the analyzing threads tend to have significantly more load than the DB threads, it is recommended to increase the '''DB thread factor''' in allocate less DB threads and use more analyzing threads.

2. System overload due to DB message lost.
:If DB message lost counters appear in the detailed [[System_Info_Page|load]] statistics (by clicking on the current load percentage), it means that the DB threads where not capable of processing the data created by the analyzing threads.

In this case it is beneficial to decrease the '''DB thread factor''' to use more DB threads and thus decrease the load per thread.
Also, if the load graph shows only sporadic peaks to 100% load, it can help to increase the message queue size to buffer temporary overload.
The '''Queue multiplier''' is an integer value which is used to multiply the queue size by this value. The value should be chosen carefully as a value of 10 already makes the queue ten times larger but also uses ten times more memory and can also increase the latency of the displayed measurement values by a factor of ten. If regular overload appears, a larger queue usually does not help much as it will just delay the message lost.

DB mode

2022-04-20T10:39:27Z

Mark:

Feature documentation

2022-04-20T10:36:51Z

Mark:

This section contains information about special Allegro Network Multimeter features not directly related to measurement of network traffic.

* [[DB mode]]
* [[TCP flow chart]]

FAQ

2022-04-20T10:27:32Z

Mark:

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

(In firmware versions less than 3.1, the value represented the time between the end of the selected interval (the right end of the graph) and the first data point.)

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. As of FW ≥ V3.4, 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]]

Names and look-ups

2022-04-20T09:27:06Z

Mark:

It is possible to label IP and MAC address with custom names and group them together into categories to allow for easy access to specific systems.
For example, all your internal machines could be labeled to match their actual name and you can categorize them into different departments.

These user defined names are persistent and are available from start on. All entries are assigned per Allegro Appliance and not per user. An assigned name is available for all users.

== Configuration==

'''Web Interface'''
{| class="wikitable"
|-
|[[File:User defined names.png|800px|none]]
|}

'''Adding or remove entries'''

The configuration of the list of names is available via '''Settings -> User defined names'''.

The configuration page shows on top the list of IP and MAC names currently set in the system.
It is possible to search for a specific entry by entering the IP or MAC address, or the category or actual name.

Individual entries may be removed from the list by clicking at the trashcan symbol in the last column.

At the bottom of the table new elements can be added by entering the IP or MAC address, and the category and name of the element.
By clicking at the '''plus''' symbol, the entry is added and will be used without further doing.

The complete IP or MAC address list can be cleared by clicking at the bottom below the table. A dialog will ask for confirmation.

Names may also be set directly at the IP or MAC detail page, see below for more information.

'''Importing IP list'''

The IP names allows importing an IP list from an external URL or from a file in the format:

{| class="wikitable"
|#A line with a comment
1.2.3.1

1.2.3.2

1.2.3.3
|}

By clicking on '''Import list''' a dialog will be opened where you can choose to download such a list from a given URL or specify a file from your system.
The IPs are added to the already existing ones.

'''Uploading or downloading the complete list as CSV file'''

Depending on the use case, the number of elements to add may be large.
In this case it is also possible to upload a comma separated text file (.csv).
The format is simple as follows:

{| class="wikitable"
|ip,192.168.0.1,category,name
mac,00:00:00:00:00:00,category,name
...
|}

The first column defines whether the line describes an IP or MAC address.
The second column is the actual address and the third and fourth is the category and the name of the entry.

The web page allows to download a template file which may be opened in a spreadsheet application.

The final file can be uploaded by clicking at the upload button and selecting the file from your local directory.

The current list can be downloaded also by clicking at the download button. The CSV file will contain both IP and MAC addresses.

'''DNS resolve'''

The Allegro Network Multimeter can resolve IP addresses by using the DNS server known to the management interface. A reverse lookup is being performed and the retrieved naming information is shown next to the IP address in various modules.

The DNS resolving can also be configured to run periodically after an interval passed and try to resolve IPs of certain given subnets. To prevent high load on the DNS server, only 5 queries may be active in parallel.

== Name display for user defined names==

If a user defined name is configured for an IP or MAC address, the name will be shown among the alternative names (which also include possible DNS, DHCP name, or other sources of information).

{| class="wikitable"
|-
![[File:Ap-mm-ip-list-user-defined-name.png|800px|none]] !! IP
|}

{| class="wikitable"
! [[File:Ap-mm-mac-list-user-defined-name.png|800px|none]] !! MAC
|-
|}

In the detailed page for a single IP or MAC address, you can click on the pencil symbol to directly set a name for this specific address.

{| class="wikitable"
|-
![[File:Ap-mm-ip-alternative-names.png|800px|none]] !! IP
|}

{| class="wikitable"
! [[File:Ap-mm-mac-alternative-names.png|800px|none]] !! MAC
|-
|}

The IP and MAC overview, the IP or MAC column is highlighted to indicate such special entries for which a name is configured.

== Filtering==

It is possible to enter the category or user defined name for IP and MAC filters.

Also, the '''name''' check in [[Live filtering of tables|complex filters]] matches the user defined name, like in this example:

{| class="wikitable"
|(name=systemA)
|}

It is also possible to filter for specific category by using the '''category''' check:

{| class="wikitable"
|(category=server)
|}

In this example, the list would only show those element for which a user defined name is set and its category contains the string '''server'''.

Introduction

2022-04-20T07:50:59Z

Mark:

The Allegro Network Multimeter is a real-time network measurement tool to identify network problems, performance bottlenecks, and to measure network quality parameters. It can be used for network troubleshooting, performance measurement, performance monitoring and other use cases. The appliance is easy to install and provides a modern web-based interface to analyze multiple network traffic parameters from all Layers of the network stack.

The appliance can be placed inline in gigabit networks, or running on the Mirror Port of a router. It will measure the following network parameters:
* '''Layer 2''' statistics & analysis MAC, QoS, ARP, VLAN, STP, MPLS, LLDP, PPPoE, packet size distribution and Micro burst analysis.
* '''Layer 3''' statistics & analysis Individual IP, QoS, DHCP, DNS, Netbios, ICMP, Multicast and Geolocation.
* '''Layer 4''' statistics & analysis TCP, IPSec, individual connections and L4 server ports.
* '''Layer 7''' statistics & analysis SSL, HTTP, SIP, RTP, SMB, Profinet, OPC-UA, L7 app. protocols, NTP, PTP and custom response time analysis.
{|class="wikitable"
|[[File:1.png|800px|Introduction|link=https://allegro-packets.com/wiki/File:1.png|alt=|none|thumb]]
|}

All information is available in Real-Time including history graphs of the global traffic, traffic per MAC address, per IP address, or even per protocol. Additionally, graphs can be clicked to zoom into a specific timeframe and see measurement results for only that specific time interval.
=== Data processing and storage ===
The Allegro Network Multimeter consists of two different and completely separate types of memory where data is being processed (RAM and Storage), which facilitates different modes of operation.

1. Allegro Network Multimeter uniquely utilizes Random Access Memory (RAM) to construct its very fast In-Memory Database. Measurement data and statistics shown throughout the web-interface/dashboard, are stored in, and retrieved from RAM. This allows for the Allegro Network Multimeter to be used in restricted and GDPR/AVG sensitive areas, where it is not allowed to store or remove data. Statistics and data shown in the dashboard will be gone in event of a power cycle.

2. Allegro Network Multimeter facilitates the use of a so called Packet Ring Buffer. The packet ring buffer (see [[Storage]]) is a HDD/SSD storage device where packet data can be stored "permanently". This allows Allegro Network Multimeter users to retroactively extract packets of interest from the web-interface. In depth analysis of such extracted pcap file can be done either with Allegro's built in Webshark or with Wireshark.

The use of a packet ring buffer also allows to easily replay network traffic (or parts thereof) that was captured to the storage device. So for instance, an engineer could send out a portable Allegro Network Multimeter to a remote site/customer, have the Allegro Network Multimeter collect network traffic for multiple days and replay & analyze this data afterwards. Packet broker type filters can be set for the In-Memory Database and the packet ring buffer.
===Dynamic memory utilization===
The Allegro Network Multimeter dynamically adjusts its memory usage to the traffic it sees. This means that in smaller networks with few IPs and connections, the analyzer can store historical data longer than in larger networks with far more IP- and connection information.

The Network Multimeter will automatically remove old data from memory (FiFo) if the memory usage is above 90%. Under "Info" in the web interface's menu, the "System info" page shows the current usage and, more importantly, for which period of time data is available.

A high memory usage is usually not a problem as the device will not remove any measured data unless the limit of 90% is reached. So over time, 90% of the memory will be used. The type of traffic has a great influence on how long data can be accessed.

In a situation where the memory usage keeps increasing to 100%, the Analyzer is overloaded. This basically means that for that traffic load or situation, a larger Allegro Network Multimeter is required.

By default, all graphs will display recent network traffic with a 1 second resolution. For older traffic the graph resolution will dynamically be lowered e.g. up to 16s. It is possible to adjust the aforementioned graph resolution and reduction values in the settings, to either get more detailed graphs OR a longer period of data & statistics available in the dashboard.
===Name correlation===
The Network Multimeter will display "Name information" whenever available. Different data sources are used for extracting such name information from network devices and their respective IP addresses. Name information is often announced by the device itself (via DHCP or NetBIOS), or as part of the network infrastructure (via DNS or HTTP host names).

All information is gathered during runtime and shown for each IP address to make it possible to identify the actual system parameters.

Depending on the network setup, the same IP can be assigned to different devices over time. The Allegro Network Multimeter will show as much name information as possible even if such information is outdated. This means that it can occur that a name is displayed for an IP address that actually belongs to a different device. This is not really a problem, since new devices (should) announce their name regularly, which will bring the internal name database up to date again.

Multi-device settings

2022-04-14T10:21:56Z

Mark:

== Multi-device settings ==
The multi-device feature allows you to access multiple Allegro Network
Multimeters from a single Multimeter (the main device). Access to the remote
Multimeters is routed through the main appliance so the web user does not
need to have direct access to the target devices.

Features like the [[Path measurement|Path measurement]] also use the multi-device
settings to access the remote appliance for the measurement.

As soon as a remote multi-device is active, the top menu shows a
drop-down menu for you to be able to select the current view. All measurement
data shown in the web interface are from the selected device.
== List of remote devices ==

The first part of the page contains the list of all configured remote
devices. It shows the host name or IP address for the corresponding device and
an arbitrary description for each device which can also be changed.

Next to the description, details of the SSL certificate of the remote
device is shown so it is possible to verify the correct
certificate.

The last column allows you to activate or deactivate devices and remove
them completely from the list. Only activated devices are actually
contacted and made available in the top selection box. It is also possible
to update the firmware of the remote device with the version of the main device.
The settings of the main device can also by synchronized to the remote device.[[File:Multi device settings.png|alt=|thumb|600x600px|Multi device settings|none]]

== Add a remote Multimeter ==

Below the list of registered Multimeters, new devices can be added by
entering the host name or IP address, optionally setting a description
for the device, and the login credentials.

== Main device description ==

The main device can also have an arbitrary description to make it
easier to select it from the top selection box.

== Firmware update ==

It is possible to update remote devices to the same firmware as the main device.
The downloaded firmware file must exist on the main device and is used for uploading
to all remote devices. No internet access is necessary.

The firmware update will trigger a restart of the processing of the remote Multimeter. In case
it is running in bridge mode, the link will be interrupted for a short moment!

Each remote device can be updated separately by clicking the "Update firmware" button in the
action column. The status column will show progress information and whether the update was
successful.

It is also possible to update more than one device at a time. You can check the checkboxes of
one or many devices and use the button "Update firmware of selected Multimeters". All checked
and visible devices of the current page will be updated. The button "Update firmware of all
Multimeters" will perform the update for every configured Multimeter regardless whether it is
selected or not.

If the firmware version of the remote Multimeter is already the same version as the main
device or prior to version 3.0, the update is not performed.

== Settings synchronization ==

It is possible to synchronize the overall settings throughout an Allegro Network Multimeter (core settings), from the main device to all the remote devices.
Similar to the firmware update, it is possible to synchronize one, many or all remote devices at a time.

Management interface settings, multi-device settings and user management (roles) cannot be synchronized between Allegro Network Multimeters.

Attention: The settings update will trigger a reboot of the remote Allegro Network Multimeter(s). In case it is running in bridge mode,
the link will be interrupted for a short moment!

== License update ==

It is possible to update the licenses of remote Allegro Network Multimeters on this page. An archive with the
licenses can be uploaded to the selected or all Allegro Network Multimeters. The Allegro Network Multimeter will try to find
its matching license in the archive and update accordingly.

Parallel packet processing

2022-04-14T10:18:00Z

Mark:

== What is '''parallel packet processing?''' ==

The '''parallel packet processing''' mode allows you to analyze historic packets in parallel to the live analytics on one Allegro Network Multimeter. The Allegro Network Multimeter supports '''pcap files''' and '''ring buffers''' as input for the '''parallel packet processing'''.

== How can I configure '''parallel packet processing?''' ==

You can enable '''parallel packet processing''' at '''Settings''' → '''Global settings''' → '''PCAP parallel analysis'''. This mode has 3 options:

* Globally enable/disable this mode
* Reserved memory in percentage of main memory ( default 10 percent )
* Number of offline analysis slots ( default 1 )

[[File:Parallel pcap processing configuration.png|border|400px]]

Allegro recommends you to enable parallel packet processing with default values and restart the processing. Please be aware that your current measurement will be lost when restarting the processing.

== How can I use '''parallel packet processing?''' ==

=== pcap upload ===

Once you have enabled this feature and restarted the processing, you can use it by uploading a pcap file at '''Generic''' → '''PCAP analysis'''. Please select a pcap file here.

[[File:Pcap Analysis before start.png|800px]]

Once a file is selected and you press '''Analyze pcap''', the following pop-up will appear:

[[File:Pcap Analysis dialoge.png|400px]]

The Option '''Use a packet buffer...''' will store a temporary second ring buffer on the storage device to allow pcap extraction after the pcap upload. This option is only available if there is a storage device attached.

Once you click OK, the file will be uploaded and analyzed immediately. If the upload is complete, you will see the following dialogue

[[File:Pcap Analysis upload succesful.png|400px]]

To switch between the pcap and the live analysis, use the selector in the top menu.

[[File:Pcap Analysis selector.png|border|300px]]

The Allegro Network Multimeter will keep the replay open even if you close the browser session. You can terminate the pcap replay session at the dashboard:

[[File:Pcap Analysis dashboard.png|border|900px]]

=== '''Ring buffer analysis''' ===

The ring buffer analysis works similar to the pcap upload, except that a part or the total ring buffer is used. Please navigate to the ring buffer statistics at '''Generic''' → '''Packet ring buffer'''. Select a time which shall be re-analyzed.

[[File:Ring buffer Analysis button.png|border|900px]]

Then press the button '''Analyze packet ring buffer''' below the graphs and the following dialogue will appear.

[[File:Ring buffer Analysis dialogue.png|border|500px]]

Here you can select the replay slot. Once the replay is started, you can proceed like the pcap upload and select the replay and terminate it on the dashboard.

Ring Buffer Configuration Guide

2022-04-14T10:13:20Z

Mark:

This section describes the '''ring buffer''' configuration and options for the Allegro Network Multimeter.

== What is the '''ring buffer?''' ==

[[File:Historic capture dialog.png|thumb|300px]]
The '''ring buffer''' is a packet buffer. It stores raw Ethernet packets on one or many '''storage devices'''. A '''storage device''' is an internal or external HDD or SSD. If the buffer is full, it will overwrite the oldest packets in a circular manner. The '''ring buffer''' is an optional feature for the Allegro Network Multimeter. It does not store any of the statistics of the In-Memory-Database.

Allegro recommend you to take a look at the [https://allegro-packets.com/en/resources-service/whitepaper/whitepaper-paket-ring-buffer ring buffer White Paper] from the Allegro Packets website.

The '''Webshark''' and the '''pcap''' extraction works with historic dates as in the screenshot here on the right. This dialogue is shown by using the '''pcap''' button in the Allegro User Interface. The Allegro Network Multimeter will search for all packets in the '''ring buffer''' if they match the criteria and extracts the packets.

If there is no '''ring buffer''' configured, the Allegro Network Multimeter allows a '''pcap''' extraction of live traffic only.

== Different '''ring buffer''' modes ==

The '''ring buffer''' supports 2 different modes.
The '''single shared ring buffer''' can be used if you need only one ring buffer that fits into your storage device. The '''single shared ring buffer''' uses '''one''' shared storage for the '''ring buffer''' and '''pcap to disk'''. This mode is recommended if only one storage device is used since it allows a '''ring buffer''' and space for '''pcap files''' on the same storage device. Please note that using both features at the same time may lead to a performance bottleneck.

The '''cluster ring buffer''' mode allows to use multiple ring buffers where each ring buffer can have multiple disks. It allows having a separate disk for pcap files which allows fast '''ring buffer''' and fast '''pcap to disk''' writes at the same time.

== '''Single shared ring buffer''' ==

The single shared ring buffer the default setup on all Allegro Network Multimeters that are shipped with '''one''' internal or external storage device. This mode is designed for '''ONE''' internal, external or iSCSI storage device. ( Please see the section [[#iSCSI ring buffer]] for more information ). It does not allow you to use multiple ring buffers with one Allegro Network Multimeter. You can check at '''Generic''' → '''Storage''' if the Allegro Network Multimeter has detected a storage device. Here an example of ONE attached disk:

[[File:Storage no device active.png|border|600px]]

You can activate and deactivate the storage device for pcap files here. You can also format new disks by using the format option and erase the content of a disk if required. If the disk has not been formatted before, press the ''Format'' button here. It will show the dialogue:

[[File:Format disk dialogue.png|border|300px]]

Here you can decide whether disk encryption will be used or not, see [[#Encryption]] below. You can also decide if and how much space can be used for the '''packet ring buffer'''. Please note that you cannot save any pcap files to the external disk when you use '''100 %''' for the '''ring buffer'''.

If the disk has been formatted, you can continue with the configuration of the '''ring buffer''' at '''Generic''' → '''ring buffer'''. If you have created a disk with a ring buffer, you should see the statistics of the buffer as in the screen shot here below.

[[File:Running packet ring buffer.png|border|600px]]

The ring buffer is now running and all pcap buttons will work for historic dates. For advanced setup, please continue at the section [[#Filter Rules]].

== '''Cluster ring buffer''' ==

The cluster ring buffer is the default mode on all Allegro Network Multimeters that are shipped with '''two or more''' internal or external storage devices.

By default, the Allegro Network Multimeter uses '''One''' cluster ring buffer. If you need more, please open the Settings menu at the top right corner.

[[File:Settings button.png|border|100px]]

Here you can increase the number of cluster ring buffers. We will continue this tutorial with 2 ring buffers to show the full flexibility of the Allegro Network Multimeter. Please note that you need to restart the processing when you change the parameter. This can be done at '''Settings''' → '''Administration''' → '''Restart processing'''.

To enable the cluster ring buffer mode, please check at '''Generic''' → '''ring buffer''', if the tab ''cluster configuration'' is selected or not. If it is not, selected, delete the non-cluster ring buffer with:

[[File:Delete ring buffer button.png|border|100px]]

Once this is done, you should see the dialogue:

[[File:Select ring buffer.png|border|300px]]

Here you can select '''Create cluster ring buffer'''. Once this is selected, you will see all available clusters of ring buffers. By default, the first cluster is running but has no disk assigned to it. The size of the buffer is 0 Bytes and it drops all packets written into it.

[[File:Cluster ring buffer initial startup.png|border|600px]]

As a next step, please select the configuration for the cluster.

[[File:Cluster ring buffer configuration.png|border|600px]]

Please select here '''Add to cluster''' to format a disk and add it to the cluster. Once you have added disks to a cluster, the packets will be written to the storage device.

[[File:Cluster ring buffer with disks.png|border|600px]]

== Filter Rules ==

Both ring buffer modes support packet filtering mechanisms. Most situations require that only a subset of all packets are stored to the disk. Each ring buffer can be configured by a separate list of rules. All packet that do not match a condition are captured. The first matching condition is applied to the packets.

=== Filter rule conditions ===

The Allegro Network Multimeter supports packet slicing with the following conditions:

* All packets → matches on all Ethernet packets
* MAC address → matches a specific L2 MAC address
* IP Address and IP Subnet → matches a specific IP address and subnet, works for IPv4 and IPv6
* TCP/UDP Ports → matches all TCP or UDP packets with a specific source or destination port
* L7 Protocol → matches one of the built-in L7 protocols
* Outer VLAN Tag → matches a single VLAN tag or the outer VLAN of a double-tagged VLAN frame. It is also possible to match packets that have no VLAN tag at all by choosing 'no VLAN' from the drop-down menu or match packets with an arbitrary VLAN tag by choosing 'any VLAN' form the drop-down menu
* Interface → matches a specific network interface
* SIP Phone Number → matches a specific SIP caller or callee phone number and its correlated RTP flow
* Virtual Link Group → matches a virtual link group
* SSL after handshake → matches packets of SSL connections that occur after the SSL handshake

All conditions can be negated to match everything except an IP subnet and similar.

=== Filter rule actions ===

The following items are supported as actions:

* Snapshot Length → byte packet slicing; allows for the capture of only a certain number of bytes per packet
* Discard → do not capture this packet
* Full → capture the full packet
* Header+Data → capture only up to L3 or L4 or a specified quantity of L7 bytes.

=== Filter rule examples ===

Filter rules can be set up below the statistics of each ring buffer. This is a list of the most-used filter rules. Note that you can combine these rules.

==== Capture all traffic from and to a single IP ====

This use case is valid when you need to investigate the packets of one IP but you need the statistics of the total link. This is a common use case where the link bandwidth is above the ring buffer write rate. As an example, it can occur when you monitor a heavy loaded 10G or 40G link with a single HDD as the ring buffer device.

You need to set up 2 rules to capture only one single IP. The first rule matches the IP address and captures the entire payload, the second rule drops all packets. This will also drop all non-IP packets like ARP requests.

[[File:Ring buffer filter one ip.png|border|600px]]

==== Capture only the handshake of SSL traffic and limit the encrypted part to L4 ====

Also a common use case is to not capture encrypted content. This can be done by setting up a rule for SSL after handshake packets to capture only up to the L4 header for IP and TCP investigation. This can be configured with the following settings:

[[File:Ring buffer rule create ssl after handshake.png|alt=|border|399x399px]]

The configured rule will look like:

[[File:Ring buffer rule ssl after handshake.png|alt=|border|600x600px]]

==== Capture full SIP, capture RTP to the first 12 bytes of the payload and drop all other packets ====

This is a common VoIP use case where you are allowed to capture the signaling traffic and the RTP header ( 12 bytes ) but not the RTP traffic payload. Here is the example rule setup:

[[File:Ring buffer rule sip rtp.png|border|600px]]

==== Capture all packets except SIP and RTP ====

This use case is very common for all environments where no voice is allowed to be captured. Here is the example rule setup:

[[File:Ring buffer rule drop sip rtp.png|600px]]

== Performance ==

=== Disk read and write performance ===

Note that one disk can have '''one''' shared ring buffer or be part of '''one''' cluster ring buffer. Hard disk drives have a high constant write rate when only one write is active.

The Allegro Network Multimeter has a ''write first'' policy on the ring buffer devices. The Allegro Network Multimeter prioritizes writes over reads for storage. A pcap read can be very slow when there is a high write rate to the ring buffer.

=== Concurrent '''ring buffer''' and live '''pcap''' recording ===

Note that HDDs are not made for 2 simultaneous write streams. The write rate will be very low if you capture a live pcap to the single shared storage device while having an active ring buffer. Please use the browser download feature, different disks with the cluster ring buffer or pause the ring buffer while capturing the live pcap.

=== Buffering traffic peaks or disk slowdowns ===

Note that most HDDs and SSDs do not have a guaranteed write rate. Especially HDDs via the USB or SATA3 protocol can have downtimes of hundreds of milliseconds between writes. Each ring buffer uses a certain amount of memory to buffer traffic peaks. This buffer can be configured at the '''Settings''' of the '''ring buffer'''

[[File:Ring buffer queue resize config.png|border|800px]]

You can check if the queue length is large enough with the '''Bytes in Flight''' graph and the '''Dropped Bytes''' graph in the ring buffer statistics.

[[File:Ring buffer data in flight.png|border|800px]]

== iSCSI ring buffer ==

'''''DISCLAIMER''' Whenever possible, use a direct-connected exclusive external storage device via USB. The Allegro Network Multimeter can control the USB channel far better than an iSCSI channel due to exclusivity.''

The iSCSI ring buffer feature allows you to mount an iSCSI volume via the management interface. Allegro recommends to use this feature only for capture rates up to 1GBit/s. The iSCSI controller will have an exclusive low-latency connection to the Allegro Network Multimeter and the rate shall be exclusive to the Allegro Network Multimeter. Also, the management traffic between the Allegro Network Multimeter and the iSCSI rate will not be monitored by the Allegro Network Multimeter to prevent a write loop.
If the rate is non-exclusive, other reads or writes will heavily reduce the constant write rate. Note that the iSCSI connection is not encrypted.

== Advanced Options ==

=== Disk format ===

The Allegro Network Multimeter uses EXT4 for all formatted file systems for the ring buffer. EXT4 file systems support advanced features that are mandatory to capture with full SSD speed.

=== Encryption ===

The Allegro Network Multimeter uses an '''AES256 LUKS encryption container''' for encrypted single shared ring buffers. You can connect and mount the encrypted disk with many Linux Distributions. It will ask for your password to mount the container.
The Allegro Network Multimeter uses hardware encryption if available. The Allegro 200 does not have HW encryption support and can encrypt up to 400MBit/s in software. All other Allegro devices can encrypt with 2GB/s by using the built-in hardware encryption.

The Allegro Network Multimeter does ''not'' store the password of the encrypted device on the disk. you need to re-enter the password if you unmount, reboot or power-off the Allegro Network Multimeter.

The encryption is not available for the cluster ring buffer.

==== Random, device specific passwords ====

Since firmware version 3.4 it is possible to use a randomly generated password for the encrypted storage device. When used, the storage can be activated and deactivated without entering the password. Also, the storage device is automatically activated on system start/restart.
The password is stored encrypted on the device and cannot be moved a different device. The password is also deleted on a configuration reset of the Allegro Network Multimeter.
Since the password is stored on the Allegro Network Multimeter, the storage device cannot be used on a different Allegro Network Multimeter without reformatting.
When the key is removed (on configuration reset or reformat), it cannot be restored!

ERSPAN Installation

2022-04-14T09:53:37Z

Mark:

This section describes the '''ERSPAN installation''' for the Allegro Network Multimeter to receive ERSPAN packets. '''ERSPAN''' is the abbreviation for ''Encapsulated Remote Switch Port Analyzer''. It is a Switch feature that encapsulates traffic into an IP/GRE tunnel.

== General ==

=== What is the '''ERSPAN''' mode? ===

'''ERSPAN''' is an advanced Switch feature that encapsulates mirrored traffic into an IP and GRE packet. The full method is described in the RFC draft [https://tools.ietf.org/html/draft-foschiano-erspan-03 https://tools.ietf.org/html/draft-foschiano-erspan-03].

The advantage of the '''ERSPAN''' mode is that it can be routed via IP and the ERSPAN generator can be at a different location than the Allegro Network Multimeter. This allows very simple captures of a low-bandwidth remote device.

=== How should the '''ERSPAN''' mode be used? ===

'''ERSPAN''' quality depends on the Switch performance and the bandwidth and latency between the Switch and the Allegro Network Multimeter. It will also add substantial load to the IP networks and can generate a packet storm when the ERSPAN packets are mirrored again into the ERSPAN tunnel.

See [[#Limitations]] for more details.

=== How can I configure the '''ERSPAN''' mode? ===

Please refer to your Switch manual how to set up a Switch ERSPAN channel. Please note that the Allegro Network Multimeter can also send '''ERSPAN''' traffic.

The '''ERSPAN''' mode can be configured at '''Settings''' → '''Global settings''' → '''Expert settings''' → '''L3 tunnel mode'''.
[[File:L3 tunnel mode.png|1000px]]

You can enable the ERSPAN mode in parallel to the [[In-Line installation]] or [[Mirror Port, Tap and Packet Broker Installation]] for one or multiple interfaces. Please be aware that ERSPAN cannot work in parallel with the Bridge mode for such an interface. The Bridge mode will be disabled for this interface pair when '''ERSPAN''' is enabled for one interface.

The '''ERSPAN''' mode works on all of the Allegro Network Multimeter interfaces including the Virtual Edition.

Once the ERSPAN mode is activated, the interface will respond to ARP requests for the configured IP address. The '''ERSPAN''' interface responds to '''ICMP Ping''' messages. Once ERSPAN is configured, you should be able to send a ping to the IP address.

=== Behaviour of the '''ERSPAN''' mode ===

The behaviour for all packets on the '''ERSPAN''' interfaces is:

* reply to ARP requests
* reply to Ping messages
* decapsulate all ERSPAN packets and forward them to the packet analytics
* discard all other packets

Be aware that mirrored packets without an ERSPAN header are dropped.

The ERSPAN header will be decapsulated for the analytics. The Allegro Network Multimeter analyzes the inner packet and ignores the outer ERSPAN header. The Packet Ring Buffer and Pcap export stores the full packets including the ERSPAN header.

=== Configuration of an Allegro as an '''ERSPAN''' sender ===

The Allegro Network Multimeter allows you to send '''ERSPAN''' packets via the management interface over a switched and routed network like a pcap capture. Allegro recommend you use the '''ERSPAN''' sending feature only via the LAN interface and not with the Wi-Fi interface. Please see [#Limitations] for more details.
Please make sure that the sending Allegro MTU size is big enough to send the whole packet including the '''ERSPAN''' header. To configure the Allegro Network Multimeter as an '''ERSPAN''' sender, increase the MTU size on the management interface AND on all Switches between the sending and receiving Allegro Network Multimeter. This can be done at '''Settings''' → '''Management settings''' → '''LAN management interface'''.

[[File:Lan mtu settings.png|900px]]

Once this is configured, you can initiate a '''live''' capture with or without filters with the capture button. Please select the ERSPAN as the capture type and fill the receiving IP address.

[[File:Erspan capture dialog.png|400px]]

This can be done also using Back-In-Time. Please use the real-time replay with factor 1.0 to replay with the same packet timing for the receiving Allegro Network Multimeter. See [#Limitations] for more details.

== Limitations ==

=== ERSPAN protocol version ===

The Allegro Network Multimeter supports ERSPAN version II and III as described in the RFC draft [https://tools.ietf.org/html/draft-foschiano-erspan-03 https://tools.ietf.org/html/draft-foschiano-erspan-03].

=== Fragmentation ===

ERSPAN is supported for non-fragmented ERSPAN packets. Please make sure that the link between the Switch and the Allegro Network Multimeter supports a higher MTU than the monitored link. We recommend to use jumbo frames with 9000 bytes to forward packets.

=== Timestamping ===

The Allegro Network Multimeter does '''NOT''' use the timestamp of the ERSPAN receiver since there is only one real-time source for the Allegro Network Multimeter.

=== Back-In-Time support ===

Please note that the Back-In-Time support requires that the storage is fast enough to extract the packets at the configured speed. A replay with factor 1.0 should work as most Ring Buffers can read at the same speed as they write data. Please stop or pause the Ring Buffer in this case to allow high speed reads. Higher factors work very well as long as the capture rate is lower than the replay rate.
If the storage is not fast enough, the replay will slow down to the storage speed. If you use the Back-In-Time mode without any speed limitation, it will be limited by the storage and the interface link speed.

Mirror Port, TAP and Packet Broker Installation

2022-04-14T07:54:36Z

Mark:

This section describes the installation for network situations where the Allegro Network Multimeter receives traffic. It is referred to here as '''Mirror Port Installation''' or '''Mirror Port Mode''' but it is also applicable for Tap and Packet Broker installations.

The '''Mirror Port''' is a feature that is available on almost all manageable Ethernet switches.

== General ==

=== DISCLAIMER ===

The '''Mirror Port Mode''' depends on the quality of the Switch mirroring. Please check the Mirror Port statistics of your Switch if all packets have been forwarded. Allegro Network Multimeter measurements depend on accurate packet mirroring and may lead to incorrect statistics if the Mirror Port is not working as expected.

Allegro recommends a separate Tap or a Packet Broker if the quality of the Mirror Port cannot be guaranteed.

=== What is the '''Mirror Port Mode?''' ===

The Allegro Network Multimeter works in the '''Mirror Port Mode''' as a traffic receiving device. It will '''NOT''' forward any traffic on the measurement Ethernet ports.

=== How should the '''Mirror Port Mode''' be used? ===

The data plane ports of the Allegro Network Multimeter should be connected in '''Mirror Port Mode''' to one or multiple Mirror Ports on a Switch. The Allegro Network Multimeter management port needs to be connected to a standard Switch port or to an out-of-band management Switch.

See [[#Limitations]] for more details.

=== How do I configure the '''Mirror Port Mode?''' ===

Please refer to your Switch manual how to set up a Switch port as a mirror port.

The Allegro '''Mirror Port Mode''' can be configured at '''Settings''' → '''Global settings''' → '''Packet processing mode'''. The interfaces can be configured to '''Bridge mode''' or '''Sink mode'''. The '''Sink mode''' will disable packet forwarding and transmission on the Ethernet ports. Please switch to '''Sink mode''' and save the settings at the bottom of the page
[[File:Sink mode.png|800px]]

== Allegro Network Multimeter Data Plane Ports ==

=== Devices with built-in network ports ===

The '''Allegro 200, 500, 1000, 1200, 3000 and 3200''' have built-in physical network ports.

{| class="wikitable"
! style="text-align:center;" |Device||Picture||Number of Monitoring Ports||Remarks
|-
|'''Allegro 200'''||[[File:Allegro-200 back cut.jpg|400px]]||2||
|-
|'''Allegro 500'''||[[File:Allegro-500 back cut.jpg|400px]] [[File:Allegro-500 front cut.jpg|400px]]||4||
|-
|'''Allegro 1000''' '''Allegro 3000'''||[[File:Allegro-1000 front cut.jpg|400px]]||7||Can be extended by [[#Devices with port expansion cards| expansion cards]].
|-
|'''Allegro 1200''' '''Allegro 3200'''||[[File:Allegro-1200-front cut.jpg|400px]]||7||Can be extended by [[#Devices with port expansion cards| expansion cards]].
|-
|'''Allegro x300''' '''Allegro x500'''||||none||The Allegro x300 and x500 series do not have built-in network ports, see section [[#Devices with port expansion cards| expansion cards]] below.
|}

=== Devices with port expansion cards ===

All Allegro Network Multimeters with network card expansion slots support the '''Mirror Port Mode'''. All expansion cards have either '''2''' or '''4''' network ports.

=== Bypass expansion cards ===

The Allegro Network Multimeter bypass cards deliver a fail-over when the software bypass is not active in '''Bridge Mode''' ( see [[In-Line Installation|In-Line installation]] for more details ). The bypass is deactivated when the '''Mirror Port Mode / Sink Mode''' is active.

== Grouping of multiple links ( Trunk vs. separate links ) ==

By default, the Allegro Network Multimeter processes all incoming traffic as one big pipe and it does not use the port as an criteria to separate links. If you have connected separate links at the Allegro Network Multimeter, please use the virtual link grouping feature to specify which ports belong together.

This feature can also be used to forward multiple links with a Packet Broker to one Allegro port with VLANs as a separator.

== Advanced VLAN handling ==

Some Switches remove the VLAN for one flow direction and keep it for the other when mirroring a VLAN trunk. Usually the Allegro Network Multimeter treats different packets of different VLANs as different links. The Allegro Network Multimeter can be configured to ignore the VLAN tag. This can be done at: '''Settings''' → '''Global settings''' → '''Expert settings''' → '''VLAN handling'''. Do not forget to save the settings at the bottom of the page!

[[File:Ignore vlan key.png|1200px]]

== Limitations ==

=== Switch limitations ===

Please be aware that the Allegro Network Multimeter can only analyze packets that have been forwarded by the Switch port. Please also be aware that the exact packet timing and ordering depends on the Switch implementation. Allegro recommends the installation of a Tap to prevent any Switch side effects.