Allegro Network Multimeter Manual - User contributions [en]

Snort

2025-07-08T09:54:56Z

Hartmut: /* Simple editor */ Typo fix

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

File:SSL module.png

2025-05-16T10:27:12Z

Hartmut: Hartmut uploaded a new version of File:SSL module.png

SSL module

RADIUS module

2025-03-03T16:53:54Z

Hartmut: /* Connections */ Link to live filtering of tables page

The RADIUS module shows information about RADIUS (Remote Authentication Dial-In User Service) traffic, which is used for authentication and accounting of users for dial-up connections like DSL, WLAN or VPN. Each RADIUS packet contains one message, which may carry optional attributes. RADIUS messages can be grouped into classes, the standard [https://datatracker.ietf.org/doc/html/rfc2865 RFC 2865] defined ''Access'' and ''Accounting'', but many other message types were implemented by various vendors.

=== Access messages ===

* '''Access Request''': Clients send such messages to the server with information used to determine if the user should be granted access. Attached information attributes may be the ''Called Station ID'', the ''Calling Station ID'' or the ''Network Access Server (NAS) Specifier''.
* '''Access Accept''': Servers may respond with such messages to provide configuration information to the client for using the requested services.
* '''Access Reject''': Servers may respond with such messages if the received request did not contain valid information to grant access to its services.
* '''Access Challenge''': Servers may respond with such messages send the client a challenge, requiring a response.

=== Accounting messages ===

* '''Accounting Request''': Clients send such messages to the server with information to identify the user, who uses a service.
* '''Accounting Response''': Servers respond with such messages to acknowledge that the request of the client has been received and recorded successfully.

== Overview ==
[[File: RADIUS_overview.png|thumb|RADIUS overview]]
Information about all RADIUS packets are shown as values and graphs to give a quick overview. Global traffic can be shown in the traffic graph to see the share of RADIUS on the overall traffic. A PCAP download button allows capturing that traffic.

The ''Packet response times'' section shows the delay between client requests and their server responses as minimum, average and maximum duration values, as well as in a graph.

The ''RADIUS messages'' section shows counters and graphs for the different message types grouped by their message type classes. Transport quality issues are indicated in the ''Messages with not in order sequence number'' subsection. Counters show for clients and servers the number of ''Expected messages''. Transport problems due to ''Repeated messages'', ''Reordered messages'' or even ''Lost messages'' are shown for both directions as counters and graphs.

== Connections ==
[[File: RADIUS_connections.png|thumb|RADIUS connections common columns]]
All RADIUS connections with their client and server IPs and ports and optional details like host names are shown. Various toggles allow to show only relevant information about the connections:

* '''Name''': The reported ''Called Station ID'', ''Calling Station ID'' and ''NAS Specifier'' of the client requests are shown.
* '''Timing''': The ''Start time'', ''Last activity'' and ''Duration'' of the connection will be visible.
* '''Counters''': RADIUS packets and bytes are shown as total counters as well as rates in packets or bits per second.
* '''Message types''': Counters for the total RADIUS message count and the different message type classes ''RADIUS Access messages'', ''RADIUS Accounting messages'' and ''RADIUS Other messages'' are shown for servers and clients.
** '''Access Messages''': In combination with the ''Message types'' toggle, counters for the message types ''RADIUS Access Accept messages'', ''RADIUS Access Challenge messages'', ''RADIUS Access Reject messages'' and ''RADIUS Access Response messages'' are shown.
** '''Accounting Messages''': In combination with the ''Message types'' toggle, counters for the message types ''RADIUS Accounting Request messages'' and ''RADIUS Accounting Response messages'' are shown.
* '''Lost/repeated Packets''': Packet counters with the result of the message sequence counter (RADIUS identifier) analysis can be shown. ''Expected Messages'' are the amount of RADIUS messages the peer should have sent according to the sequence numbers used. ''Repeated Messages'' count repeatedly seen packets from a peer with the same sequence number, while ''Reordered Messages'' indicate conditions, where older messages are seen after newer ones. ''Lost Messages'' count gaps in the seen sequence numbers, indicating that expected packets got lost.
* '''Response times''': The duration statistics between the seen client request packet and its corresponding (according to the RADIUS identifier) server response packet are shown for minimum, average and maximum value.
* '''VLAN''': The used IDs of ''Outer VLANs'' and ''Inner VLANs'' are shown.
* '''Graph''': Up to five graphs can be selected from the following available graphs to be shown simultaneously:
** RADIUS traffic (bit/s)
** RADIUS traffic (packets/s)
** Packet response times
** RADIUS messages (messages/s)
** RADIUS Access messages (messages/s)
** RADIUS Accounting messages (messages/s)
** Client message flow (messages/s)
** Server message flow (messages/s)
* '''PCAP''': The PCAP download button is shown for each RADIUS connection.

A complex filter for the shown row values can be used to limit the shown connections to the specific needs. See [[Live filtering of tables]] for a detailed description about how to use this.

TDS module

2025-03-03T16:52:26Z

Hartmut: /* Connections */ Link to live filtering of tables page

The TDS module shows information about TDS (Tabular Data Stream) traffic, used for database connections with Microsoft SQL Servers. Detected connections between clients and SQL servers are shown.

== Overview==
[[File: TDS_overview.png|thumb|TDS overview]]
Information about all TDS packets are shown as values and graphs to give a quick overview. Global traffic can be shown in the traffic graph to see the share of TDS on the overall traffic. A PCAP download button allows capturing that traffic.

In the section of overall TDS messages, recognized SQL Batch queries, as well as Remote Procedure Call queries and their server response messages are shown as counters and in a graph. The delay statistics between client queries and server response messages are shown as minimum, average and maximum Request-Response time values, as well as in a graph.

==Connections==
[[File: TDS_connections.png|thumb|TDS connections common columns]]
All TDS connections with their client and server IPs and ports are shown together with the recognized TDS version. If the ''Timing'' toggle is activated, the start and end time, as well as the duration of the connection will be visible. The ''Counters'' toggle switches visibility of common traffic counters for total packets and bytes, traffic rate counters for packets per second and bit per second, as well as the recognized valid SQL query and response messages. The connection quality can be evaluated in two columns: the ''Response times'' toggle enables the view of TCP handshake time separated for client and server, maximum and average response times, as well as SQL query response times (time between a SQL Batch query or Remote Procedure Call request sent by the client, until the server responds). Retransmissions (in byte and as a percentage of the total traffic), missed bytes and duplicated ACK-packets are shown when the ''TCP Retransmissions'' toggle is enabled.

The following graphs are available for individual selection:

* TDS traffic bitrate
* TDS traffic packet rate
* TDS SQL query response times (for both SQL Batch Queries and Remote Procedure Calls)
* TDS SQL query and response messages

The TDS traffic of each connection can be captured using the PCAP download button.

A complex filter for the shown row values can be used to limit the shown connections to the specific needs. See [[Live filtering of tables]] for a detailed description about how to use this.

IEC61850 module

2025-03-03T16:49:33Z

Hartmut: Link to live filtering of tables page

The IEC 61850 module shows information about communication protocols for intelligent electronic devices at electrical substations. These currently supported protocols are:

* GOOSE ('''G'''eneric '''O'''bject '''O'''riented '''S'''ubstation '''E'''vent)
* Sampled Values

The recognized data is transferred as payload of OSI-Layer 2 packets (optionally with VLAN tags). For GOOSE (in '''P'''rotocol '''D'''ata '''U'''nit - PDU) and Sampled Values (in '''A'''pplication '''S'''ervice '''D'''ata '''U'''nit - ASDU) data units, sequence counters are used to allow reordering the received packets and detecting lost packets.

== Overview ==

[[File:IEC61850 dashboard.png|thumb|IEC 61850 overview]]
Information about all recognized IEC 61850 packets are shown as values and graphs to give a quick overview. Global traffic can be shown in the traffic graph to see the share of each IEC 61850 protocol on the overall traffic.

For each of the protocols, measures of packets and data (accumulated and as per second rate), provide an impression of the used network capacity. Problems in the packet sequence are available as counters for expected packets (according to seen sequence numbers), lost packets (expected sequence number missing), repeated packets (sequence number seen multiple times). A PCAP download button allows capturing that traffic.

== Devices ==

[[File:IEC61850 devices.png|thumb|IEC 61850 devices]]
All devices sending or receiving IEC 61850 traffic are shown with their MAC address and the detected protocol. Besides packet counts and data rates of the protocol, quality measures like expected, lost and repeated data units/packets are shown. For having a quick overview, multiple graphs can be shown simultaneously for:

* general IEC 61850 traffic rate
* GOOSE packet rate rate
* Sampled Values data unit rate

The traffic for the specific device and protocol can be captured using the PCAP download button.

A complex filter for the shown row values can be used to limit the shown devices to the specific needs. See [[Live filtering of tables]] for a detailed description about how to use this.

== Connections ==

[[File:IEC61850 connections.png|thumb|IEC 61850 connections]]
All connections containing IEC 61850 traffic are shown with their two communication partners' MAC address and the detected protocol. Besides packet counts, data rates and time of last detected activity, quality measures like expected, lost and repeated data units/packets are shown. For having a quick overview, multiple graphs can be shown simultaneously for:
*general IEC 61850 traffic rate
* GOOSE packet rate rate
* Sampled Values data unit rate

The traffic for the specific connection and protocol can be captured using the PCAP download button.

A complex filter for the shown row values can be used to limit the shown connections to the specific needs. See [[Live filtering of tables]] for a detailed description about how to use this.

Live filtering of tables

2025-03-03T16:39:44Z

Hartmut: /* Available keywords */ add IEC 61850, TDS and RADIUS complex filter tokens

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Examples ==

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

== Notes ==

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

== Available keywords ==

The available keywords vary depending on the web interface section.

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

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

There are some additional keywords to support some limited set of wireshark compatible filter expressions:

{| class="wikitable sortable"
|+
!Keyword
!Description
!Available in firmware version
|-
|ip.addr
|the IPv4 address (either source or destination)
|3.4
|-
| ip.src
|the IPv4 source address
|3.4
|-
| ip.dst
|the IPv4 destination address
|3.4
|-
|ipv6.addr
|the IPv6 address (either source or destination)
|3.4
|-
|ipv6.src
|the IPv6 source address
|3.4
|-
|ipv6.dst
|the IPv6 destination address
|3.4
|-
|tcp.port
|the source or destination port of a TCP connection
|3.4
|-
|tcp.srcport
|the source port of a TCP connection
|3.4
|-
|tcp.dstport
|the destination port of a TCP connection
|3.4
|-
|udp.port
|the source or destination port of a UDP connection
|3.4
|-
|udp.srcport
|the source port of a UDP connection
|3.4
|-
|udp.dstport
|the destination port of a UDP connection
|3.4
|-
|smb.shareName
|the Name of the smb share
|4.1
|-
|smb.connectionEncrypted
|if the connection between a client and a server is encrypted (possible values are: "encrypted" and "unencrypted"
|4.1
|-
|smb.negotiationState
| the negotiation state of a connection
|4.1
|-
|smb.successfulConnects / smb.failedConnects
|number of successful/failed connects to a smb share
|4.1
|-
|smb.successfulDisconnects / smb.failedDisconnects
|number of successful/failed disconnects to a smb share
|4.1
|-
|smb.dialect
|the used dialects of a smb server
|4.1
|-
|smb.dialectReq
|the dialects requested by a client
|4.1
|-
|smb.dialectUsed
|the dialects used by a client
|4.1
|-
|smb.failedOpens / smb.successfulOpens
|the number of successful/failed opens of a file by a client of a file
|4.1
|-
|smb.failedOpens / smb.successfulOpens
|the number of successful/failed opens of a file by a client
|4.1
|-
| smb.failedCloses / smb.successfulCloses
|the number of successful/failed closes of a file by a client
|4.1
|-
|smb.failedDeletes / smb.successfulDeletes
|the number of successful/failed deletes of a file by a client
|4.1
|-
|smb.firstOpen / smb.lastOpen
|time since the first/last open
|4.1
|-
|smb.lastClose
|time since the file got closed the last time
|4.1
|-
|smb.lastDelete
|time since the file got deleted the last time
|4.1
|-
|smb.bytesWritten / smb.bytesRead
|the number of bytes written to/read from the file
|4.1
|-
|icmp.pingLatencyMin
| the ping latency (min) in ms for ICMP ping request/replies tuples of one connection
|4.2
|-
|icmp.pingLatencyAvg
|the ping latency (average) in ms for ICMP ping request/replies tuples of one connection
|4.2
|-
|icmp.pingLatencyMax
|the ping latency (max) in ms for ICMP ping request/replies tuples of one connection
|4.2
|-
|icmp.requests
| the number of ICMP ping requests of one connection
|4.2
|-
|icmp.replies
|the number of ICMP ping replies of one connection
|4.2
|-
|ip.ttl.min / max / avg
| the min / max / avg TTL value of an IPv4
|4.2
|-
|ipv6.hlim.min / max / avg
| the min / max / avg hop limit value of an IPv6
|4.2
|-
|goose.packetsExpected
| the number of expected IEC 61850 GOOSE packets
| 4.2
|-
|goose.packetsLost
|the number of lost IEC 61850 GOOSE packets
|4.2
|-
|goose.packetsRepeat
|the number of repeated IEC 61850 GOOSE packets
|4.2
|-
|sv.asduExpected
|the number of expected IEC 61850 Sampled Values ASDUs
|4.2
|-
|sv.asduLost
|the number of lost IEC 61850 Sampled Values ASDUs
|4.2
|-
|sv.asduRepeat
|the number of repeated IEC 61850 Sampled Values ASDUs
|4.2
|-
|tds.loginack.tdsversion
|the used TDS version as negotiated during the login process
|4.3
|-
|tds.sqlqueryresponse.avg/min/max
| the average/min/max response time for TDS SQL queries in ms
| 4.3
|-
|tds.sqlqueryrequests
|the number of TDS SQL queries
|4.3
|-
|tds.sqlqueryresponses
|the number of responses to TDS SQL queries
|4.3
|-
|radius.messages
radius.client.messages
radius.server.messages
|the number of (total/client/server) RADIUS messages
|4.4
|-
|radius.messages.access
radius.client.messages.access
radius.server.messages.access
|the number of (total/client/server) RADIUS Access messages
|4.4
|-
|radius.messages.access.accept
radius.client.messages.access.accept
radius.server.messages.access.accept
|the number of (total/client/server) RADIUS Access Accept messages
|4.4
|-
|radius.messages.access.challenge
radius.client.messages.access.challenge
radius.server.messages.access.challenge
|the number of (total/client/server) RADIUS Access Challenge messages
|4.4
|-
|radius.messages.access.reject
radius.client.messages.access.reject
radius.server.messages.access.reject
|the number of (total/client/server) RADIUS Access Reject messages
|4.4
|-
|radius.messages.access.request
radius.client.messages.access.request
radius.server.messages.access.request
|the number of (total/client/server) RADIUS Access Request messages
|4.4
|-
|radius.messages.accounting
radius.client.messages.accounting
radius.server.messages.accounting
|the number of (total/client/server) RADIUS Accounting messages
|4.4
|-
|radius.messages.accounting.request
radius.client.messages.accounting.request
radius.server.messages.accounting.request
|the number of (total/client/server) RADIUS Accounting Request messages
|4.4
|-
|radius.messages.accounting.response
radius.client.messages.accounting.response
radius.server.messages.accounting.response
|the number of (total/client/server) RADIUS Accounting Response messages
|4.4
|-
|radius.messages.others
radius.client.messages.others
radius.server.messages.others
|the number of other (total/client/server) RADIUS messages
|4.4
|-
|radius.client.messages.expected
radius.server.messages.expected
|the number of expected (client/server) RADIUS messages
|4.4
|-
|radius.client.messages.lost
radius.server.messages.lost
|the number of lost (client/server) RADIUS messages
|4.4
|-
|radius.client.messages.reorder
radius.server.messages.reorder
|the number of reordered (client/server) RADIUS messages
|4.4
|-
|radius.client.messages.repeat
radius.server.messages.repeat
|the number of repeated (client/server) RADIUS messages
|4.4
|-
|radius.calledStationId
|the called station ID string sent by the RADIUS client
|4.4
|-
|radius.callingStationId
|the calling station ID string sent by the RADIUS client
|4.4
|-
|radius.nasSpecifier
|the NAS Specifier/Identifier string sent by the RADIUS client
|4.4
|-
|radius.responsetime.avg/min/max
|the average/min/max duration between client requests and server responses
|4.4
|}

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

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

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

File:Quic server.png

2025-02-25T15:15:36Z

Hartmut: Hartmut uploaded a new version of File:Quic server.png

Overview of the QUIC TLS server tab

RADIUS module

2025-02-24T14:14:08Z

Hartmut: /* Connections */ Mention filter support

Measurement modules

2025-02-24T13:33:43Z

Hartmut: /* L7 - Application Layer */ add RADIUS module

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

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

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

* [[LACP_module|LACP module]]
:The LACP module shows information gathered from LACP packets about port channels.

* [[VXLAN_module|VXLAN module]]
:The VXLAN module shows information about all seen VXLANs.

* [[Geneve_module|GENEVE module]]
:The GENEVE module shows information about all seen GENEVE VNIs.

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

* [[UDP module|UDP module]]
:The UDP module shows global UDP traffic, IP adresses with UDP traffic and UDP connections.

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

* [[Fix_module|FIX module]]
:The FIX module shows information about '''F'''inancial '''I'''nformation e'''X'''change traffic.

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

* [[IEC61850_module|IEC 61850 module]]
:The IEC 61850 module analyzes '''G'''eneric '''O'''bject '''O'''riented '''S'''ubstation '''E'''vent (GOOSE) and IEC 61850 Sampled Values traffic and shows information about the different traffic types and sequence counter correctness.

* [[RADIUS_module|RADIUS module]]
:The RADIUS module analyzes '''R'''emote '''A'''uthentication '''D'''ial-'''I'''n '''U'''ser '''S'''ervice traffic and shows the protocol traffic, response times, message types and sequence counter correctness.

* [[TDS_module|TDS module]]
:The TDS module analyzes MS-SQL '''T'''abular '''D'''ata '''S'''tream traffic and shows the protocol traffic, response times and the recognized negotiated protocol version.

* [[TETRA_module|TETRA module]]
:The TETRA module shows detailed information about '''Te'''rrestrial '''T'''runked '''Ra'''dio traffic.

* [[QUIC module]]
:The QUIC Analysis Module provides comprehensive insights into '''Q'''uick '''U'''DP '''I'''nternet '''C'''onnections traffic.

* [[DICOM_statistics|DICOM module]]
:The DICOM module shows information about DICOM (Digital Imaging and Communications in Medicine) protocol usage.

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

RADIUS module

2025-02-24T13:25:44Z

Hartmut: /* Connections */

RADIUS module

2025-02-24T13:24:02Z

Hartmut: RADIUS module description

The RADIUS module shows information about RADIUS (Remote Authentication Dial-In User Service) traffic, which is used for authentication and accounting of users for dial-up connections like DSL, WLAN or VPN. Each RADIUS packet contains one message, which may carry optional attributes. RADIUS messages can be grouped into classes, the standard [https://datatracker.ietf.org/doc/html/rfc2865 RFC 2865] defined ''Access'' and ''Accounting'', but many other message types were implemented by various vendors.

=== Access messages ===

* '''Access Request''': Clients send such messages to the server with information used to determine if the user should be granted access. Attached information attributes may be the ''Called Station ID'', the ''Calling Station ID'' or the ''Network Access Server (NAS) Specifier''.
* '''Access Accept''': Servers may respond with such messages to provide configuration information to the client for using the requested services.
* '''Access Reject''': Servers may respond with such messages if the received request did not contain valid information to grant access to its services.
* '''Access Challenge''': Servers may respond with such messages send the client a challenge, requiring a response.

=== Accounting messages ===

* '''Accounting Request''': Clients send such messages to the server with information to identify the user, who uses a service.
* '''Accounting Response''': Servers respond with such messages to acknowledge that the request of the client has been received and recorded successfully.

== Overview ==
[[File: RADIUS_overview.png|thumb|RADIUS overview]]
Information about all RADIUS packets are shown as values and graphs to give a quick overview. Global traffic can be shown in the traffic graph to see the share of RADIUS on the overall traffic. A PCAP download button allows capturing that traffic.

The ''Packet response times'' section shows the delay between client requests and their server responses as minimum, average and maximum duration values, as well as in a graph.

The ''RADIUS messages'' section shows counters and graphs for the different message types grouped by their message type classes. Transport quality issues are indicated in the ''Messages with not in order sequence number'' subsection. Counters show for clients and servers the number of ''Expected messages''. Transport problems due to ''Repeated messages'', ''Reordered messages'' or even ''Lost messages'' are shown for both directions as counters and graphs.

== Connections ==
[[File: RADIUS_connections.png|thumb|RADIUS connections common columns]]
All RADIUS connections with their client and server IPs and ports and optional details like host names are shown. Various toggles allow to show only relevant information about the connections:

* '''Name''': The reported ''Called Station ID'', ''Calling Station ID'' and ''NAS Specifier'' of the client requests are shown.
* '''Timing''': The ''Start time'', ''Last activity'' and ''Duration'' of the connection will be visible.
* '''Counters''': RADIUS packets and bytes are shown as total counters as well as rates in packets or bits per second.
* '''Message types''': Counters for the total RADIUS message count and the different message type classes ''RADIUS Access messages'', ''RADIUS Accounting messages'' and ''RADIUS Other messages'' are shown for servers and clients.
** '''Access Messages''': In combination with the ''Message types'' toggle, counters for the message types ''RADIUS Access Accept messages'', ''RADIUS Access Challenge messages'', ''RADIUS Access Reject messages'' and ''RADIUS Access Response messages'' are shown.
** '''Accounting Messages''': In combination with the ''Message types'' toggle, counters for the message types ''RADIUS Accounting Request messages'' and ''RADIUS Accounting Response messages'' are shown.
* '''Lost/repeated Packets''': Packet counters with the result of the message sequence counter (RADIUS identifier) analysis can be shown. ''Expected Messages'' are the amount of RADIUS messages the peer should have sent according to the sequence numbers used. ''Repeated Messages'' count repeatedly seen packets from a peer with the same sequence number, while ''Reordered Messages'' indicate conditions, where older messages are seen after newer ones. ''Lost Messages'' count gaps in the seen sequence numbers, indicating that expected packets got lost.
* '''Response times''': The duration statistics between the seen client request packet and its corresponding (according to the RADIUS identifier) server response packet are shown for minimum, average and maximum value.
* '''VLAN''': The used IDs of ''Outer VLANs'' and ''Inner VLANs'' are shown.
* '''Graph''': Up to five graphs can be selected from the following available graphs to be shown simultaneously:
** '''RADIUS traffic (bit/s)'''
** '''RADIUS traffic (packets/s)'''
** '''Packet response times'''
** '''RADIUS messages (messages/s)'''
** '''RADIUS Access messages (messages/s)'''
** '''RADIUS Accounting messages (messages/s)'''
** '''Client message flow (messages/s)'''
** '''Server message flow (messages/s)'''
* '''PCAP''': The PCAP download button is shown for each RADIUS connection.

File:RADIUS connections.png

2025-02-24T13:22:22Z

Hartmut:

File:RADIUS overview.png

2025-02-24T13:20:30Z

Hartmut:

Incidents

2025-02-12T14:31:30Z

Hartmut: /* Channel configuration */ SNMP v3 engineID clarification

[[File:Incidents_list.png|alt=|none|thumb|800x800px|Incident page]]
Incidents are used to alarm the user when configured network events occur, usually for traffic based rules, but also for system-specific events. These notifications can be viewed in the web GUI and may also be delivered on various notification channels. Repeating incidents are counted as such and the time of the first and last occurrence of an incident is remembered. This feature can be disabled for some incidents. What makes an incident unique depends on the type of incident.

The incident feature allows to define rules which are checked on the configured trigger point, like when a connection ends, a SIP call ends, or for checks on ongoing traffic. When such a trigger hits, configurable traffic attributes will be checked and if all attributes of a rule match, an incident is created.

Occurred incidents can be seen in the web interface, additionally reporting via the following notification channels is possible:
* email
* Apache Kafka
* SNMP trap
* syslog

The first occurrence of a medium or high severity incident will also trigger a status notification which is visible at the top right of the web GUI.

A configurable number of incidents will be remembered by the system and if the limit is exceeded the oldest incidents will be discarded [fixed number of 1000 incidents in firmware < 4.1].

== Rule configuration ==
[[File:Incidents rules.png|thumb|600x600px|Rule configuration]]
Incident rules can be defined in the Incident rules" tab in the menu "Generic -> Incidents". All changes to the rule configuration will only take effect after saving the current configuration by clicking on the save button at the bottom of the page.

The page shows a table containing the existing rules and their configuration.

Each existing rule can be modified by clicking on the pencil symbol, or deleted by clicking on the "minus" symbol.

New rules can be added by clicking on the "Add rule" button. A dialog appears allowing for configuration of the rule. The same dialog is used when modifying an existing rule.

=== Add/modify a rule ===
[[File:Incidents add rule.png|thumb|600x600px|Add rule dialog]]
A rule is defined by the following settings:

* Rule name: This is an arbitrary text describing the purpose of the rule. This text is shown in the incident list and email/Kafka/SNMP trap/syslog ouptut.
* Severity: three different severity values "low", "medium", and "high" can be used to group more important and less important incidents. Reporting channels can be configured to only report incidents of a minimum severity level. A rule can also be disabled by choosing the severity level "disabled". It will not be evaluated and can be enabled later at will.
* Trigger: The trigger defines when a rule is evaluated. For each available trigger, a description is shown next to it giving more details about the trigger. Some triggers are evaluated at a very specific time, like when a VoIP call ends, or are evaluated regularly like for throughput triggers of IP traffic which can be configured to be checked periodically. See list below for a detailed description of the available triggers.
* Attributes: Attributes are used to make actual comparison of expected values vs. actual values.
** Each trigger has a different set of attributes which can be checked for, and some triggers don't need to have an attribute at all. See list below for a detailed description of the available attributes
** Up to four attributes can be added by clicking on the "Add attribute" button.
** Multiple attributes must all match at the same time to let the rule create an incident.
** Each attribute can be compared to a specific value, so that the actual value is lower, equal, or greater than a defined value.
** Some attributes have an additional parameter, like a time span which defines how the attribute value is calculated.
* Virtual link group: The rule can be limited to a selected [[Virtual Link Group functionality|virtual link group]] or to be applied for any group. Some triggers cannot be limited to a virtual link group so the configuration will be hidden.
* IP filter: Depending on the selected trigger, the rule can be limited to a specific IP address. The IP filter can also be an IP subnet in the format IP/mask-length (Example: 10.0.0.0/8)
* IP group: Depending on the selected trigger, the rule can be applied to an IP group instead of an individual IP address.
* Virtual link group, IP and IP filter can also be used inversely by using the != comparator
* Report channel: Incidents are always visible in the web interface, but can also be reported via multiple channels which can be configured separately in the tab "Notification channels". Up to ten channels can be selected so that the incident for this rule is reported on each channel. Also, no channel can be configured so the incident is only accessible on the web interface.
* Aggregation of recurring Incidents: Incidents are aggregated by default. This means the table only shows the number of incidents of the type and the timestamps of the first and the last incident. This can be disabled for most of the incidents, so that you are able to see every indent of the incident-type.
* Time Profiles: You are able to set a profile which defines the active time of an incident rule.
* Traffic capturing: If supported by the trigger, the rule can be configured to capture the network traffic triggering the rule, including some extra time before and after the incident.
** Possible options:
*** Disabled: capturing is disabled for this rule
*** Live traffic: capturing happens only for live network traffic
*** Replay traffic: capturing happens only for replayed network traffic (from PCAP files)
*** Always: capturing happens in all traffic processing types.
** Extra capture time: configure the number of seconds before the start of the incident and after the end of the incident.
*** If a time span parameter is used for attributes, the capture time includes this time duration as well.
** The traffic is automatically filtered to only contain the traffic that actually triggered the rule, i.e., an IP address or an IP group for IP rules.

=== Available triggers ===
{| class="wikitable"
|+
!Trigger name
!Description
!Attributes
!Attribute usage
|-
|ARP: MAC change for an IP 
(arp_ip_mac_changed)
|This trigger is checked on an ARP response and MAC address changed for a requested IP.
|time_since_last_mac
|optional
|-
|DNS: Server is not responding 
(dns_server_not_responding)
|This trigger is checked when a DNS server is not responding for some time. A server is considered unresponsive when more than 3 requests to the DNS server went unanswered for a period of more than 5 seconds. Such a server must have answered at least two requests previously.
|time_since_first_unanswered_request
|optional
|-
|DNS: Server response error 
(dns_server_response_error)
|This trigger is checked when a DNS server responds a configured error of type format error, server failure or non-existing domain
|error_type
|mandatory
|-
|Global: Connection start 
(global_new_connection)
|This trigger is checked continuously at connection start. It can be used to report new connections with a certain layer 4 protocol and a given port range.
|l4_protocol, port_range, since_start_time
|mandatory
|-
|Global: GPS synchronization status change 
(global_gps_sync_status_change)
|This trigger is checked when the GPS clock synchronization status changes.
|gps_sync_status
|optional
|-
|Global: Number of connections 
(global_connections)
|This trigger is checked continuously whether the amount of newly created connections exceeds a threshold. The update interval is defined by the timespan parameter of the attributes.
|new_connections
|mandatory
|-
|Global: Regular expressions 
(global_regex_match)
|This trigger allows to configure a list of regular expressions and is checked for each packet whose L7 data matches one of the regular expressions in the list. Since there are no attributes associated with this trigger, this effectively means that any packet which matches one of the regular expressions will result in an incident. The incident also contains information about which connection this packet belongs to as well as which of the regular expressions matches the packet.
|
|no attributes are available for this trigger
|-
|Global: Ring buffer 
(global_ring_buffer)
|This trigger is checked continuously to report changes in the ring buffer.
|used_size, bytes_captured, bytes_dropped
|mandatory
|-
|Global: Speed change of an interface 
(global_interface_speed_change)
|This trigger is checked when the speed of an interfaces changes.
|interface_speed
|optional
|-
|Global: Speed mismatch for an interface pair 
(global_interface_speed_mismatch)
|This trigger is checked when the status or speed of an interfaces changes and mismatches the speed of corresponding interface of a link.
|link_speed_difference
|optional
|-
|Global: Status change of an interface 
(global_interface_status_change)
|This trigger is checked when the status of an interfaces changes.
|interface_status
|optional
|-
|Global: Traffic 
(global_traffic)
|This trigger is checked continuously for the total traffic of the device. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase
|mandatory
|-
|IEC 61850 - GOOSE: State number change 
(iec61850_goose_state_change)
|This trigger is checked when a change in the state number of GOOSE packets is detected.
|GoCBRef
|optional
|-
|IEC104: Response times 
(iec104_response_times)
|This trigger is checked whenever an IEC104 ACTCON reply for an ACT has been seen.
|response_time
|mandatory
|-
|IEC104: Traffic 
(iec104_traffic)
|This trigger is checked continuously for each IEC104 connection. The update interval is defined by the timespan parameter of the attributes.
|percent_loss, absolute_loss, not_in_order
|mandatory
|-
|IP: Connection end 
(ip_flow_end)
|This trigger checks the attributes whenever an IP flow ended.
|total_packets, total_bytes, tcp_handshake_time, percent_retransmissions, zero_window_packets, duration, l7_protocol
|mandatory
|-
|IP: Connection start 
(ip_flow_start)
|This trigger checks the attributes whenever an IP flow starts.
|new_connections, geolocation
|mandatory
|-
|IP: Local IP with multiple MAC addresses 
(ip_local_ip_multiple_macs)
|This trigger is checked on each new flow of a local IP address and more than one MAC address uses this IP.
|mac_count
|optional
|-
|IP: New local IP address 
(ip_new_local_ip)
|This trigger is checked once for each new IP belonging to a private network address range.
|since_start_time
|optional
|-
|IP: New L7 protocol 
(ip_new_l7_protocol)
|This trigger is checked once for each new l7 protocol used by an IP.
|since_start_time, local_ip, l7_protocol
|optional
|-
|IP: TCP handshake 
(ip_tcp_handshake)
|This trigger is checked after successful TCP handshake or at connection end if handshake failed.
|handshake_time, server_handshake_time, client_handshake_time, handshake_failed
|mandatory
|-
|IP: Traffic on IP addresses 
(ip_traffic)
|This trigger is checked continuously for each active IP or IP group. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase, total_packets, total_bytes, retransmission_ratio, zero_window_packets, tcp_syn_packets, tcp_fin_packets, tcp_rst_packets
|mandatory
|-
|IP: TTL change 
(ip_ttl_change)
|This trigger is checked continuously for each active IP.
|ttl_change
|mandatory
|-
|LACP: Status change of a channel 
(lacp_channel_status_change)
|This trigger is checked when the status of a LACP port channel changes.
|channel_status
|optional
|-
|MAC: New L7 protocol 
(mac_new_l7_protocol)
|This trigger is checked when a unicast MAC address uses a l7 protocol for the first time.
|since_start_time
|optional
|-
|MAC: New MAC address 
(mac_new_address)
|This trigger is checked once when a new unicast MAC address appears for the first time.
|since_start_time
|optional
|-
|MAC: Traffic on MAC addresses 
(mac_traffic)
|This trigger is checked continuously for each active MAC address. The update interval is defined by the timespan parameter of the attributes.
|broadcast_packet_rate
|mandatory
|-
|PPPoE: PPPoE Discovery traffic 
(pppoe_discovery_traffic)
|This trigger is checked continuously for PPPoE discovery traffic. The update interval is defined by the timespan parameter of the attributes.
|pppoe_discovery_packets
|mandatory
|-
|Profinet: Traffic of Profinet devices 
(profinet_traffic)
|This trigger is checked continuously for Profinet traffic. For max jitter, the update interval is defined by the timespan parameter of the attributes. All other attributes will be checked upon event.
|alarms_low, alarms_high, errors, frames_lost, frames_repeated, frames_wrong_sequence, max_jitter
|mandatory
|-
|PTP: Timestamp packet 
(ptp_timestamp_packet)
|This trigger is checked when a PTP packet containing a valid timestamp is seen.
|time_offset
|mandatory
|-
|QOS: Traffic on QoS classes 
(qos_traffic)
|This trigger is checked continuously for each active QoS class. The update interval is defined by the timespan parameter of the attributes.
|throughput
|mandatory
|-
|RTP: Traffic for RTP connections 
(rtp_traffic)
|This trigger is checked continuously for traffic of each RTP connection. The update interval is defined by the timespan parameter of the attributes.
|jitter, percent_loss
|mandatory
|-
|SIP: Call end 
(sip_call_end)
|This trigger is checked when a SIP call ended.
|duration, status, mos, percent_loss, jitter, total_packets, total_bytes, total_caller_packets, total_callee_packets, total_caller_bytes, total_callee_bytes
|mandatory
|-
|SMB: SMB1 negotiation 
(smb_version_negotiation,

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

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

prior to 4.4: <s>tls_version</s>)
|This trigger is checked when receiving the Server Hello message of each TLS connection.
|used_tls_version, tls_handshake_time_ms
|mandatory
|-
|WiFi: Handshake failure
(wifi_handshake_failure)
|This trigger is checked during certain parts of a WiFi handshake when a client tries to join a network.
|handshake_failure_type
|mandatory
|}

==== Special trigger properties ====
Some triggers are checked continuously every configured time span period, so the incidents are generated differently than for fixed event specific triggers like a call end.

# Repeating incidents: The following triggers will be evaluated every configured time span and will be re-issued whenever the configured attributes match.
## ip_traffic
## mac_traffic
## qos_traffic
## rtp_traffic
# Start/stop incidents: The following triggers are reported once the configured attributes match and for a second time when the attributes no longer match.
## global_traffic

So for repeating incidents you will get repeated incidents for the same attribute every time span. For example, if an IP address has traffic of 100 Mbit/s for 2 minutes and a rule checks for more than 50 Mbit/s over 30 seconds, the rule will hit 4 times. There will be one incident which will contain the exact number of repetitions for reference.

For start/stop incidents, you will only see two rule hits and the incident description will state the start and stop time.

=== Available attributes ===

* '''absolute_loss''': Count of lost packets for IEC104 connection.
* '''alarms_low''', '''alarms_high''': Whether an low/high alarm occurred for a Profinet device.
* '''broadcast_packet_rate''': The attribute is the number of packets per second on average over the configured timespan for MAC broadcast packets.
* '''bytes_captured''': The amount of bytes captured by a ring buffer in the given timespan.
* '''bytes_dropped''': The amount of bytes dropped by a ring buffer in the given timespan.
* '''certificate_expires''': This is the number of days until the certificate expires. If the certificate is already expired, the value is <= 0.
* '''channel_status''': 0 means that the LACP port channel is not synchronized, 1 means that the LACP port channel is synchronized.
* '''duration''':
** ''IP: Connection end'': The time between first and last packet of the flow.
** ''SIP: Call end'': The call duration.
* '''errors''':
** ''Profinet: Traffic of Profinet devices: Whether errors occured.
* '''error_type''': equal or not equal to:
** Format Error: DNS responds a format error.
** Non-existent Domain: DNS could not find queried domain name.
** Server Failure: DNS responds server failure.
* '''frames_lost''', '''frames_repeated''', '''frames_wrong_sequence''': Whether Profinet frames have been seen with problems in sequence. For loss the count of lost frames is calculated.
* '''geolocation''': checks if a country is part of the connection
** '''Direction''': The direction of traffic
*** ''from'': Traffic is coming ''from the'' specified country
*** ''to'': Traffic is going ''to'' the specified country
*** ''any:'' The specified country is on either side of the connection, or on neither side if the inequality is selected.
* '''GoCBRef''', The GOOSE control block reference name of the device to filter.
* '''gps_sync_status''': 0 means that the GPS clock in not synchronized, 1 means that the GPS clock is synchronized.
* '''handshake_failed''': Whether TCP handshake failed, i.e. one packet of SYN, SYN-ACK, ACK sequence is missing. If no handshake is seen at all but data (e.g. Allegro was started in the middle of a connection), no incident is generated.
* '''handshake_failure_type''': The type of failure that occured during a WiFi handshake
** '''Erroneous handshake''': The handshake violated the protocol laid out by IEEE802.11. This is not an authentication failure, this is a technical issue with a network device, or an issue with signal strength at the multimeter.
** '''Failure to authenticate''' '''(WPA)''': A client attempted to join a network but failed to authenticate via WPA2 or WPA3. This indicates a problem during the EAPOL key derivation (most likely invalid credentials).
** '''Failure to authenticate (WEP)''': A client attempted to join a network but failed to authenticate via WEP. This indicates a general authentication failure in an authentication frame. More information can be found in the details panel of the offending authentication frame on the handshake details page.
** '''Failure to (re)associate''': A client attempted to join a network, succeeded authentication but ultimately failed to associate with the network. More information can be found in the details panel of the offending (re)association response frame on the handshake details page. Note that association happens ''after'' successful WEP authentication, but ''before'' WPA authentication.
* '''handshake_time''': The TCP handshake time between the first SYN packet and the ACK packet for the SYN/ACK packet of the server.
** '''client_handshake_time''': The TCP handshake time between the SYN/ACK packet of the server and the ACK packet of the client.
** '''server_handshake_time''': The TCP handshake time between the first SYN packet of the client and the SYN/ACK packet of the server.
* '''interface_speed''': The current speed of the interface in Mbit/s.
* '''interface_status''': 0 means interface is down, 1 means interface is up.
* '''jitter''':
** ''SIP: Call end'': The average jitter of the call, using the maximum value of both call sides.
** ''RTP: Traffic for RTP connections'': The average jitter of the RTP connection for the given timespan, using the maximum value of both directions.
* '''l4_protocol''': The layer 4 protocol. Can be TCP, UDP or other.
* '''l7_protocol''': The layer 7 protocol short name. Can also be a list, e.g. "HTTP, SSH, DHCP"
* '''local_ip''': Whether the IP is local (10/8, 172.16/12, 192.168/16, 169.254/16, fe80::/10, fc00::/7)
* '''link_speed_difference''': This is the absolute difference between the speeds of both interface of a link in Mbit/s.
* '''mac_count''': The number of different MAC addresses for the corresponding IP address.
* '''max_jitter''': The max jitter value for a Profinet device in % in a given timespan.
* '''mos''': The average MOS quality value of the call, using the minimum of both call sides.
* '''new_connections''': The amount of newly created connections (TCP and UDP) for the given timespan.
* '''not_in_order''': Count of not in order packets for IEC104 connection. The sequence number could be too high, too low or repeated.
* '''packet_rate''': The packet rate in packets per second on average during the configured timespan.
* '''packet_rate_increase''': The packet rate increase in % during the configured timespan compared to the average packet rate of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''percent_loss''':
** ''SIP: Call end'': The percentage of RTP packet loss for the call, accounting packets from both directions.
** ''RTP: Traffic for RTP connections'': The percentage of RTP packet loss for the given timespan, accounting packets from both directions of the RTP connection.
** ''IEC104: Traffic for IEC104 connections'': The percentage of IEC104 packet loss for the given timespan, accounting packets from both directions of the IEC104 connection.
* '''percent_transmissions''': The amount of TCP retransmission as a percentage of the total bytes.
* '''port_range''': The TCP or UDP port. Can be also a range, e.g. 80,443,8443-8445
* '''pppoe_discovery_packets''': The number of PPPoE discovery packets seen during the configured timespan.
* '''response_time''': The response time of IEC104 ACT requests and ACTCON replies.
* '''retransmission_ratio''': The TCP retransmission ratio seen in the configured timespan.
* '''since_start_time''':
** ''MAC: New L7 protocol'': This is the number of seconds after packet processing start when a new Layer-7 protocol for the MAC address appeared.
** ''MAC: New MAC address'': This is the number of seconds after packet processing start when the MAC address appeared. This is useful to only report new MAC address after some learning time.
** ''IP: New local IP address'': This is the number of seconds after packet processing start when the IP address appeared. This is useful to only report new IP address after some learning time.
** ''IP: New local L7 protocol'': This is the number of seconds after packet processing start when the Layer-7 protocol for the IP address appeared.
** ''Global: Connection start'': This is the number of seconds after packet processing start when the connection hast been started. This is useful to only report new connections after some learning time.
* '''status''': The call status code (a three digit number, like 200 for Success)
* '''tcp_handshake_time''': The TCP handshake time.
* '''tcp_fin_packets''': The number of TCP FIN packets (RX + TX) seen in the configured timespan.
* '''tcp_rst_packets''': The number of TCP RST packets (RX + TX) seen in the configured timespan.
* '''tcp_syn_packets''': The number of TCP SYN packets (RX + TX) seen in the configured timespan.
* '''throughput''': The throughput bandwidth in bit/s on average during the configured timespan.
* '''throughput_increase''': The throughput bandwidth increase in % during the configured timespan compared to the average throughput of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''time_offset''': The time offset between the local time and the timestamp seen in the PTP packet.
* '''time_since_first_unanswered_request''': This is the time span between when the trigger is checked and the first DNS request that has not been answered by the DNS server.
* '''time_since_last_mac''': This is the number of seconds between changed MAC addresses. If, for examples, dynamic IP assignment is used, changing MAC addresses is normal so the test can be limited to only a certain amount of time.
* '''tls_alert_level''': The alert level of a TLS alert packet. Can be 'fatal', 'warning' or 'unknown'. A fatal alert will be sent if e.g. TLS handshake failed and connection shall be closed.
* '''tls_handshake_time_ms:''' The [[TLS module|TLS handshake response time]] of the TLS handshake.
* '''tls_handshake_first_data:''' The [[TLS module|TLS data response time]] of the TLS handshake.
* '''total_bytes''':
** ''IP: Connection end'': The total number of bytes seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of bytes seen in the configured timespan.
** '''total_callee_bytes''': The number of bytes seen for the callee of the call.
** '''total_caller_bytes''': The number of bytes seen for the caller of the call.
* '''total_packets''':
** ''IP: Connection end'': The total number of packets seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of packets seen in the configured timespan.
** '''total_callee_packets''': The number of packets seen for the callee of the call.
** '''total_caller_packets''': The number of packets seen for the caller of the call.
* '''ttl_change''': Whether TTL or hop limit has changed.
* '''type''': The type of PPPoE discovery packet (PADI, PADO, PADR, PADS, PADT or any).
* '''used_size''': The percentage of the ring buffer that needs to be filled.
* '''used_tls_version''': The TLS version (SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3)
* '''version''':
** ''SMB: SMB version negotiation'': The SMB version SMB1 or SMB2/3
* '''window_below_mss''': Whether the smallest announced TCP window was below the TCP MSS value. An additional offset is available, to check whether window was smaller than MSS + x bytes.
* '''zero_window_packets''': The number of packets with a TCP window of 0 for both directions of the flow.
* '''zero_window_packets''': The number of zero window packets seen in the configured timespan.

=== Capture settings ===
It is possible to automatically capture traffic for occurred incidents. These global settings control where capture files are stored and the capturing itself can be enabled for each rule separately.

The incident capture feature requires an active packet ring buffer since the packets are extracted from the buffer at the end of the incident period.

Available settings:

* Capture cooldown period: For each rule a cooldown period prevents multiple captures from happening in fast succession. By default, new captures happen firstly after 5 seconds, but any other value of at least 1 second can be configured. The cooldown is applied to each rule separately, but for each individual rule it does not matter if the same or a different entity triggers an incident. The incident is still reported within the cooldown period, but no additional capture is started.
* Storage device: Select the storage device where the captures should be stored on.
* Storage directory: Enter the directory where capture files should be stored or leave empty to use the top level directory.
* Select packet ring buffer to capture from: if multiple ring buffer cluster are in use, you can select which ring buffer to use for extraction.
* Capture profile: A capture profile can be configured to apply packet truncation rules to the capture file. If unset, the complete packets are captured (if the ring buffer uses separate truncation rules, truncated packets might still be within the capture file).

== Time Profiles ==
Incident rules can be active configured to be active in configured time spans (time profiles).

Every time profile allows the user to define one or more time spans per day of the week in which a rule should be active. After saving the user is able select the time profile when editing the rule.

Notes: Overlapping time spans will be merged. The earliest a time span is allowed to start is 0 and the latest end is 24, minutes are not allowed. The rule is not active for a day if there is no time span defined for the day.

== Channel configuration ==
[[File:Incidents channels.png|thumb|600x600px|Channel configuration]]
Incidents can be reported on different channels. The configuration allows to add new channels so they can be selected in the rule configuration described above.

Each channel can be of type:

'''email''' Incidents will be sent to the email address configured in the [[Global settings]].

'''kafka''' The incidents are sent to a topic on the configured Apache Kafka server. The message is the same as for syslog.
* Bootstrap Server: hostname/ip:port of a Kafka Broker or multiple Brokers separated by comma
* Protocol: Plaintext (no authentication, no encryption), SASL Paintext (Plain authentication, no encryption), SASL SSL (Plain authentication, TLS/SSL encryption)
* Ignore TLS Certificate: Ignore the TLS Certificate of the Brokers (only SASL SSL)
* Username: Broker Login (only SASL)
* Password: Broker Login (only SASL)
* Topic: The name of the topic into which the Incidents are sent.

'''snmp_trap''' Incidents will be sent to the configured SNMP trap receiver. A MIB file with the Allegro Network Multimeter SNMP trap definitions is available for download in the channel configuration dialog.
* Version: Supported SNMP version of the trap receiver (SNMP v2c or SNMP v3)
* Trap receiver (manager) hostname/IP: The trap receiver hostname or IP address

''SNMP v2c'':
* Community name: SNMP community name expected by the trap receiver

''SNMP v3'':
* Authentication protocol: Protocol for authenticated messages (MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512)
* Authentication password: Pass phrase for authenticated messages
* Privacy protocol: Protocol for message encryption (AES, DES)
* Privacy password: Pass phrase for message encryption
* Security name: Security name for authenticated SNMP messages
* Security level: Security level for SNMP messages (noAuthNoPriv, authNoPriv, authPriv)
* Engine ID: Authoritative (security) engineID (hexadecimal number of an even amount of 10 to 64 hexadecimal digits, optionally prefixed with "0x")

'''syslog''' Incidents will be sent to the configured syslog server via TCP on any TCP or UDP port.

[[File:Incidents add channel.png|thumb|alt=|none|Adding a new channel]]
Each channel also uses a minimum severity setting, so only incidents are reported which are of at least that severity.

Each channel can be configured to only handle incidents from live traffic or from replayed traffic.

Some incidents cannot be configured via rules and you can choose to get those incidents also via email by enabling the settings at the lower part of the settings page.

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

== Other settings ==

=== Interface burst incident ===
[[File:Incidents others.png|thumb|600x600px|Other incidents]]
Burst incidents with milli-second resolution can be generated when the interface throughput exceeds a configurable threshold. The incident contains a graph of traffic for that interface with some data points before and after the threshold has been exceeded depending on the measurement interval. A PCAP link for capturing from the packet ring buffer is shown. For further investigation of that incident, the button "Use as global time range" can be used to set the global range to the start and end of the incident graph (at least 5 seconds) so that all modules of the Allegro Network Multimeter show that time span.

The incident generation can be configured in the "Other settings" tab as follows:
* '''Report "throughput threshold exceeded" with severity''': report an incident with the selected severity level if the throughput of any network interface exceeded.
* '''Throughput threshold (Mbit/s)''': The threshold is configured in Mbit/s.
* '''How long throughput must be above threshold to generate incident (in milliseconds)''': The throughput must exceed the threshold for this duration in order to generate the incident. If set to zero (default) the incident is generated immediately after the threshold has been exceeded.
* '''Throughput cool-down period between two incidents in milliseconds''': Defines the time after an incident where no new incident is generated even if the threshold is exceeded. If this period is passed, throughput incidents could be generated again.
Since each burst incidents stores the high resolution traffic graph, this feature uses a significant amount of memory. The actual amount is shown below and also depends on the maximum number of incidents configured in the section below.

=== Generic incident settings ===
This section allows to modify generic settings regarding the incident feature:

* '''Maximum number of stored incidents''': This value defines how many incidents are stored before old incidents are removed. Increasing this value also increased the amount of memory reserved for this feature. The corresponding value for the active setting is shown below, changing the configuration value requires a restart of the packet processing to take affect.

== Occured incidents ==
This page shows up to the last incidents occurred on the system. The table can be filtered for specific severity levels, as well as for specific trigger sources by selecting the trigger from the drop down menu.
[[File:Incidents list filter.png|thumb|600x600px|Filter incidents by severity or trigger]]
The list can also be filtered for the subject of the incident.

Individual incidents can be viewed in detail by clicking on the subject. The details page shows detailed information including links to the relevant measurement page.

Incidents can be deleted individually by clicking on the delete button next to the incident, or all incidents can be deleted by clicking on the button on the top right of the page.

The number of incidents available in this view is limited by a configurable number (firmware <4.1 was limited to 1000), the configuration as available in the "Other settings" tab.

== Incident statistics ==
[[File:Incidents stats.png|thumb|600x600px|Statistics about rules]]
This page shows graphs about how often each rule has been hit both in absolute numbers as well as relatively to how often the rule has been checked.

== Incident list per measurement modules ==
Since incidents are triggered by different measurement modules (as indicate by the prefix of the trigger name, like the mac or ip module), the list of incidents from that specific module can also be seen in the corresponding tab of the measurement module for quicker access. This per-module view only lists those incidents coming from that module, all other potential incidents are hidden and must be accessed in their corresponding module page, or in the global view in the "Generic -> Incident" menu.

== Limitations ==
Some technical limitations apply:

* continuously checked triggers like "IP traffic" are only evaluated if there was at least one packet in the corresponding time interval. Therefore, rules check for zero packet count or throughput will never match.

Generic Allegro Network Multimeter installation

2024-10-09T12:15:02Z

Hartmut: /* Device specific installation guides */ Add Allegro 1010/3010 installation guides

== Generic install information ==

All Allegro Network Multimeters share the same basic installation steps.

A quick installation guide is provided with each device as a printed document or on our [https://allegro-packets.com/en/support web site].

The basic steps, described in detail in the installation guide, are:

# Connect the external power supply or cable to the internal power supply.
# Connect the LAN connection for management access,
# Or, connect the Wi-Fi device for wireless access.
# Setup Bridge or Sink mode depending on whether you want to deploy the device in-line or on a passive Tap or Mirror Port.
# Connect the measurement ports.
# Start the device.
# Access the web interface.
Note that an initial configuration of the [[Management interface settings on console]] is possible.

== Device specific installation guides ==

{| class="wikitable"
|-
! Allegro model !! Installation guide
|-
| Allegro 200 || [[Media:Installation Guide Allegro 200-1000-3000-en.pdf|Installation Guide 200 (English)]] [[Media:Installation Guide Allegro-200-1000-3000-dt.pdf|Installation Guide 200 (Deutsch)]]
|-
| Allegro 500 || [[Media:Installation Guide Allegro 500-en.pdf|Installation Guide Allegro 500 (English)]] [[Media:Installation Guide Allegro 500-dt.pdf|Installation Guide Allegro 500 (Deutsch)]]
|-
| Allegro 800 Allegro 1000/1200 Allegro 3000/3200
|[[Media:Installation Guide Allegro 800-1000-3000 (English).pdf|Installation Guide 800/1000/1200/3000/3200 (English)]] [[Media:Installation Guide Allegro-200-1000-3000-dt.pdf|Installation Guide 1000/1200/3000/3200 (Deutsch)]]
|-
| Allegro 1010 Allegro 3010
|[[Media:Installation_Guide_1010-3010_en.pdf|Installation Guide Allegro 1010/3010 (English)]] [[Media:Installation_Guide_1010-3010_de.pdf|Installation Guide Allegro 1010/3010 (Deutsch)]]
|-
|Allegro 1210/3210/5210
|[[Media:X210 Installation Guide English.pdf|Installation Guide Allegro 1210/3210/5210 (English)]] [[Media:X210 Installation Guide Deutsch.pdf|Installation Guide Allegro 1210/3210/5210 (Deutsch)]]
|-
| Allegro 1300/3300/5300 || [[Media:Installation Guide x300-en.pdf|Installation Guide Allegro 1300/3300/5300 (English)]] [[Media:Installation Guide Allegro x300-dt.pdf|Installation Guide Allegro 1300/3300/5300 (Deutsch)]]
|-
|Allegro 1310/3310/5310/7310
|[[Media:18.08-Installation Guide x310-en v1.pdf|Installation Guide Allegro 1310/3310/5310/7310 (English)]] [[Media:Installationsanleitung x310 de.pdf|Installation Guide Allegro 1310/3310/5310/7310 (Deutsch)]] [[Media:Installation Guide x310 korean.pdf|Installation Guide Allegro 1310/3310/5310/7310 (Korean)]] [[Media:Installation Guide x310-traditionalChinese.pdf|Installation Guide Allegro 1310/3310/5310/7310 (Traditional Chinese)]]
|-
|Allegro 1400/3400/5400||[[Media:Installation Guide Allegro x400-en.pdf|Installation Guide Allegro 1400/3400/5400 (English)]] [[Media:Installation Guide Allegro x400-dt.pdf|Installation Guide Allegro 1400/3400/5400 (Deutsch)]]
|-
|Allegro 1410/3410/5410/7410
|[[Media:Installation Guide x410 en Web.pdf|Installation Guide Allegro 1410/3410/5410/7410 (English)]] [[Media:Installationsanleitung x410 de.pdf|Installation Guide Allegro 1410/3410/5410/7410 (Deutsch)]] [[Media:Installation Guide x410-korean.pdf|Installation Guide Allegro 1410/3410/5410/7410 (Korean)]] [[Media:Installation Guide x410-traditionalChinese.pdf|Installation Guide Allegro 1410/3410/5410/7410 (Traditional Chinese)]]
|-
|Allegro 1500/3500/5500||[[Media:Installation Guide x500-en.pdf|Installation Guide Allegro 1500/3500/5500 (English)]] [[Media:Installation Guide Allegro x500-dt.pdf|Installation Guide Allegro 1500/3500/5500 (Deutsch)]]
|-
|Allegro 1510/3510/5510/7510
|[[Media:Installation Guide x510-en.pdf|Installation Guide Allegro 1510/3510/5510/7510 (English)]] [[Media:Installationsanleitung x510-de.pdf|Installation Guide Allegro 1510/3510/5510/7510 (Deutsch)]] [[Media:Installation Guide x510 korean.pdf|Installation Guide Allegro 1510/3510/5510/7510 (Korean)]] [[Media:Installation Guide x510-traditionalChinese.pdf|Installation Guide Allegro 1510/3510/5510/7510 (Traditional Chinese)]]
|-
|Allegro Virtual Edition||[[Media:Installation Guide Allegro Virtual Edition-en.pdf|Installation Guide Allegro Virtual Edition (English)]] [[Media:Installation Guide Allegro Virtual Edition-dt.pdf|Installation Guide Allegro Virtual Edition (Deutsch)]]
|}

Generic Allegro Network Multimeter installation

2024-10-09T12:09:08Z

Hartmut: /* Device specific installation guides */ always list english version first

== Generic install information ==

All Allegro Network Multimeters share the same basic installation steps.

A quick installation guide is provided with each device as a printed document or on our [https://allegro-packets.com/en/support web site].

The basic steps, described in detail in the installation guide, are:

# Connect the external power supply or cable to the internal power supply.
# Connect the LAN connection for management access,
# Or, connect the Wi-Fi device for wireless access.
# Setup Bridge or Sink mode depending on whether you want to deploy the device in-line or on a passive Tap or Mirror Port.
# Connect the measurement ports.
# Start the device.
# Access the web interface.
Note that an initial configuration of the [[Management interface settings on console]] is possible.

== Device specific installation guides ==

{| class="wikitable"
|-
! Allegro model !! Installation guide
|-
| Allegro 200 || [[Media:Installation Guide Allegro 200-1000-3000-en.pdf|Installation Guide 200 (English)]] [[Media:Installation Guide Allegro-200-1000-3000-dt.pdf|Installation Guide 200 (Deutsch)]]
|-
| Allegro 500 || [[Media:Installation Guide Allegro 500-en.pdf|Installation Guide Allegro 500 (English)]] [[Media:Installation Guide Allegro 500-dt.pdf|Installation Guide Allegro 500 (Deutsch)]]
|-
| Allegro 800 Allegro 1000/1200 Allegro 3000/3200
|[[Media:Installation Guide Allegro 800-1000-3000 (English).pdf|Installation Guide 800/1000/1200/3000/3200 (English)]] [[Media:Installation Guide Allegro-200-1000-3000-dt.pdf|Installation Guide 1000/1200/3000/3200 (Deutsch)]]
|-
|Allegro 1210/3210/5210
|[[Media:X210 Installation Guide English.pdf|Installation Guide Allegro 1210/3210/5210 (English)]] [[Media:X210 Installation Guide Deutsch.pdf|Installation Guide Allegro 1210/3210/5210 (Deutsch)]]
|-
| Allegro 1300/3300/5300 || [[Media:Installation Guide x300-en.pdf|Installation Guide Allegro 1300/3300/5300 (English)]] [[Media:Installation Guide Allegro x300-dt.pdf|Installation Guide Allegro 1300/3300/5300 (Deutsch)]]
|-
|Allegro 1310/3310/5310/7310
|[[Media:18.08-Installation Guide x310-en v1.pdf|Installation Guide Allegro 1310/3310/5310/7310 (English)]] [[Media:Installationsanleitung x310 de.pdf|Installation Guide Allegro 1310/3310/5310/7310 (Deutsch)]] [[Media:Installation Guide x310 korean.pdf|Installation Guide Allegro 1310/3310/5310/7310 (Korean)]] [[Media:Installation Guide x310-traditionalChinese.pdf|Installation Guide Allegro 1310/3310/5310/7310 (Traditional Chinese)]]
|-
|Allegro 1400/3400/5400||[[Media:Installation Guide Allegro x400-en.pdf|Installation Guide Allegro 1400/3400/5400 (English)]] [[Media:Installation Guide Allegro x400-dt.pdf|Installation Guide Allegro 1400/3400/5400 (Deutsch)]]
|-
|Allegro 1410/3410/5410/7410
|[[Media:Installation Guide x410 en Web.pdf|Installation Guide Allegro 1410/3410/5410/7410 (English)]] [[Media:Installationsanleitung x410 de.pdf|Installation Guide Allegro 1410/3410/5410/7410 (Deutsch)]] [[Media:Installation Guide x410-korean.pdf|Installation Guide Allegro 1410/3410/5410/7410 (Korean)]] [[Media:Installation Guide x410-traditionalChinese.pdf|Installation Guide Allegro 1410/3410/5410/7410 (Traditional Chinese)]]
|-
|Allegro 1500/3500/5500||[[Media:Installation Guide x500-en.pdf|Installation Guide Allegro 1500/3500/5500 (English)]] [[Media:Installation Guide Allegro x500-dt.pdf|Installation Guide Allegro 1500/3500/5500 (Deutsch)]]
|-
|Allegro 1510/3510/5510/7510
|[[Media:Installation Guide x510-en.pdf|Installation Guide Allegro 1510/3510/5510/7510 (English)]] [[Media:Installationsanleitung x510-de.pdf|Installation Guide Allegro 1510/3510/5510/7510 (Deutsch)]] [[Media:Installation Guide x510 korean.pdf|Installation Guide Allegro 1510/3510/5510/7510 (Korean)]] [[Media:Installation Guide x510-traditionalChinese.pdf|Installation Guide Allegro 1510/3510/5510/7510 (Traditional Chinese)]]
|-
|Allegro Virtual Edition||[[Media:Installation Guide Allegro Virtual Edition-en.pdf|Installation Guide Allegro Virtual Edition (English)]] [[Media:Installation Guide Allegro Virtual Edition-dt.pdf|Installation Guide Allegro Virtual Edition (Deutsch)]]
|}

File:Installation Guide 1010-3010 de.pdf

2024-10-09T12:07:36Z

Hartmut: Allegro 1010/3010 Installation Guide (deutsch)

== Summary ==
Allegro 1010/3010 Installation Guide (deutsch)

File:Installation Guide 1010-3010 en.pdf

2024-10-09T12:04:51Z

Hartmut: Allegro 1010/3010 Installation Guide (english)

== Summary ==
Allegro 1010/3010 Installation Guide (english)

TDS module

2024-08-26T16:42:50Z

Hartmut: SQL Query response time feature added

File:TDS overview.png

2024-08-26T12:57:04Z

Hartmut:

File:TDS connections.png

2024-08-26T11:51:36Z

Hartmut: Hartmut uploaded a new version of File:TDS connections.png

== Summary ==
MS-SQL TDS connections page

Incidents

2024-08-08T16:11:17Z

Hartmut: /* Available attributes */ GOOSE control block reference attribute

[[File:Incidents_list.png|alt=|none|thumb|800x800px|Incident page]]
Incidents are used to alarm the user when configured network events occur, usually for traffic based rules, but also for system-specific events. These notifications can be viewed in the web GUI and may also be delivered on various notification channels. Repeating incidents are counted as such and the time of the first and last occurrence of an incident is remembered. This feature can be disabled for some incidents. What makes an incident unique depends on the type of incident.

The incident feature allows to define rules which are checked on the configured trigger point, like when a connection ends, a SIP call ends, or for checks on ongoing traffic. When such a trigger hits, configurable traffic attributes will be checked and if all attributes of a rule match, an incident is created.

Occurred incidents can be seen in the web interface, additionally reporting via the following notification channels is possible:
* email
* Apache Kafka
* SNMP trap
* syslog

The first occurrence of a medium or high severity incident will also trigger a status notification which is visible at the top right of the web GUI.

A configurable number of incidents will be remembered by the system and if the limit is exceeded the oldest incidents will be discarded [fixed number of 1000 incidents in firmware < 4.1].

== Rule configuration ==
[[File:Incidents rules.png|thumb|600x600px|Rule configuration]]
Incident rules can be defined in the "Configuration of incident rules" tab in the menu "Generic -> Incidents". All changes to the rule configuration will only take effect after saving the current configuration by clicking on the save button at the bottom of the page.

The page shows a table containing the existing rules and their configuration.

Each existing rule can be modified by clicking on the pencil symbol, or deleted by clicking on the "minus" symbol.

New rules can be added by clicking on the "Add rule" button. A dialog appears allowing for configuration of the rule. The same dialog is used when modifying an existing rule.

=== Add/modify a rule ===
[[File:Incidents add rule.png|thumb|600x600px|Add rule dialog]]
A rule is defined by the following settings:

* Rule name: This is an arbitrary text describing the purpose of the rule. This text is shown in the incident list and email/Kafka/SNMP trap/syslog ouptut.
* Severity: three different severity values "low", "medium", and "high" can be used to group more important and less important incidents. Reporting channels can be configured to only report incidents of a minimum severity level. A rule can also be disabled by choosing the severity level "disabled". It will not be evaluated and can be enabled later at will.
* Trigger: The trigger defines when a rule is evaluated. For each available trigger, a description is shown next to it giving more details about the trigger. Some triggers are evaluated at a very specific time, like when a VoIP call ends, or are evaluated regularly like for throughput triggers of IP traffic which can be configured to be checked periodically. See list below for a detailed description of the available triggers.
* Attributes: Attributes are used to make actual comparison of expected values vs. actual values.
** Each trigger has a different set of attributes which can be checked for, and some triggers don't need to have an attribute at all. See list below for a detailed description of the available attributes
** Up to four attributes can be added by clicking on the "Add attribute" button.
** Multiple attributes must all match at the same time to let the rule create an incident.
** Each attribute can be compared to a specific value, so that the actual value is lower, equal, or greater than a defined value.
** Some attributes have an additional parameter, like a time span which defines how the attribute value is calculated.
* Virtual link group: The rule can be limited to a selected [[Virtual Link Group functionality|virtual link group]] or to be applied for any group. Some triggers cannot be limited to a virtual link group so the configuration will be hidden.
* IP filter: Depending on the selected trigger, the rule can be limited to a specific IP address. The IP filter can also be an IP subnet in the format IP/mask-length (Example: 10.0.0.0/8)
* IP group: Depending on the selected trigger, the rule can be applied to an IP group instead of an individual IP address.
* Virtual link group, IP and IP filter can also be used inversely by using the != comparator
* Report channel: Incidents are always visible in the web interface, but can also be reported via multiple channels which can be configured separately in the tab "Configuration of notification channels". Up to ten channels can be selected so that the incident for this rule is reported on each channel. Also, no channel can be configured so the incident is only accessible on the web interface.
* Aggregation of recurring Incidents: Incidents are aggregated by default. This means the table only shows the number of incidents of the type and the timestamps of the first and the last incident. This can be disabled for most of the incidents, so that you are able to see every indent of the incident-type.
* Time Profiles: You are able to set a profile which defines the active time of an incident rule.
* Traffic capturing: If supported by the trigger, the rule can be configured to capture the network traffic triggering the rule, including some extra time before and after the incident.
** Possible options:
*** Disabled: capturing is disabled for this rule
*** Live traffic: capturing happens only for live network traffic
*** Replay traffic: capturing happens only for replayed network traffic (from PCAP files)
*** Always: capturing happens in all traffic processing types.
** Extra capture time: configure the number of seconds before the start of the incident and after the end of the incident.
*** If a time span parameter is used for attributes, the capture time includes this time duration as well.
** The traffic is automatically filtered to only contain the traffic that actually triggered the rule, i.e., an IP address or an IP group for IP rules.

=== Available triggers ===
{| class="wikitable"
|+
!Trigger name
!Description
!Attributes
!Attribute usage
|-
|ARP: MAC change for an IP 
(arp_ip_mac_changed)
|This trigger is checked on an ARP response and MAC address changed for a requested IP.
|time_since_last_mac
|optional
|-
|DNS: Server is not responding 
(dns_server_not_responding)
|This trigger is checked when a DNS server is not responding for some time. A server is considered unresponsive when more than 3 requests to the DNS server went unanswered for a period of more than 5 seconds. Such a server must have answered at least two requests previously.
|time_since_first_unanswered_request
|optional
|-
|DNS: Server response error 
(dns_server_response_error)
|This trigger is checked when a DNS server responds a configured error of type format error, server failure or non-existing domain
|error_type
|mandatory
|-
|Global: Connection start 
(global_new_connection)
|This trigger is checked continuously at connection start. It can be used to report new connections with a certain layer 4 protocol and a given port range.
|l4_protocol, port_range, since_start_time
|mandatory
|-
|Global: GPS synchronization status change 
(global_gps_sync_status_change)
|This trigger is checked when the GPS clock synchronization status changes.
|gps_sync_status
|optional
|-
|Global: Number of connections 
(global_connections)
|This trigger is checked continuously whether the amount of newly created connections exceeds a threshold. The update interval is defined by the timespan parameter of the attributes.
|new_connections
|mandatory
|-
|Global: Regular expressions 
(global_regex_match)
|This trigger allows to configure a list of regular expressions and is checked for each packet whose L7 data matches one of the regular expressions in the list. Since there are no attributes associated with this trigger, this effectively means that any packet which matches one of the regular expressions will result in an incident. The incident also contains information about which connection this packet belongs to as well as which of the regular expressions matches the packet.
|
|no attributes are available for this trigger
|-
|Global: Ring buffer 
(global_ring_buffer)
|This trigger is checked continuously to report changes in the ring buffer.
|used_size, bytes_captured, bytes_dropped
|mandatory
|-
|Global: Speed change of an interface 
(global_interface_speed_change)
|This trigger is checked when the speed of an interfaces changes.
|interface_speed
|optional
|-
|Global: Speed mismatch for an interface pair 
(global_interface_speed_mismatch)
|This trigger is checked when the status or speed of an interfaces changes and mismatches the speed of corresponding interface of a link.
|link_speed_difference
|optional
|-
|Global: Status change of an interface 
(global_interface_status_change)
|This trigger is checked when the status of an interfaces changes.
|interface_status
|optional
|-
|Global: Traffic 
(global_traffic)
|This trigger is checked continuously for the total traffic of the device. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase
|mandatory
|-
|IEC 61850 - GOOSE: State number change 
(iec61850_goose_state_change)
|This trigger is checked when a change in the state number of GOOSE packets is detected.
|GoCBRef
|optional
|-
|IEC104: Response times 
(iec104_response_times)
|This trigger is checked whenever an IEC104 ACTCON reply for an ACT has been seen.
|response_time
|mandatory
|-
|IEC104: Traffic 
(iec104_traffic)
|This trigger is checked continuously for each IEC104 connection. The update interval is defined by the timespan parameter of the attributes.
|percent_loss, absolute_loss, not_in_order
|mandatory
|-
|IP: Connection end 
(ip_flow_end)
|This trigger checks the attributes whenever an IP flow ended.
|total_packets, total_bytes, tcp_handshake_time, percent_retransmissions, zero_window_packets, duration, l7_protocol
|mandatory
|-
|IP: Connection start 
(ip_flow_start)
|This trigger checks the attributes whenever an IP flow starts.
|new_connections, geolocation
|mandatory
|-
|IP: Local IP with multiple MAC addresses 
(ip_local_ip_multiple_macs)
|This trigger is checked on each new flow of a local IP address and more than one MAC address uses this IP.
|mac_count
|optional
|-
|IP: New local IP address 
(ip_new_local_ip)
|This trigger is checked once for each new IP belonging to a private network address range.
|since_start_time
|optional
|-
|IP: New L7 protocol 
(ip_new_l7_protocol)
|This trigger is checked once for each new l7 protocol used by an IP.
|since_start_time, local_ip, l7_protocol
|optional
|-
|IP: TCP handshake 
(ip_tcp_handshake)
|This trigger is checked after successful TCP handshake or at connection end if handshake failed.
|handshake_time, server_handshake_time, client_handshake_time, handshake_failed
|mandatory
|-
|IP: Traffic on IP addresses 
(ip_traffic)
|This trigger is checked continuously for each active IP or IP group. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase, total_packets, total_bytes, retransmission_ratio, zero_window_packets, tcp_syn_packets, tcp_fin_packets, tcp_rst_packets
|mandatory
|-
|IP: TTL change 
(ip_ttl_change)
|This trigger is checked continuously for each active IP.
|ttl_change
|mandatory
|-
|LACP: Status change of a channel 
(lacp_channel_status_change)
|This trigger is checked when the status of a LACP port channel changes.
|channel_status
|optional
|-
|MAC: New L7 protocol 
(mac_new_l7_protocol)
|This trigger is checked when a unicast MAC address uses a l7 protocol for the first time.
|since_start_time
|optional
|-
|MAC: New MAC address 
(mac_new_address)
|This trigger is checked once when a new unicast MAC address appears for the first time.
|since_start_time
|optional
|-
|MAC: Traffic on MAC addresses 
(mac_traffic)
|This trigger is checked continuously for each active MAC address. The update interval is defined by the timespan parameter of the attributes.
|broadcast_packet_rate
|mandatory
|-
|PPPoE: PPPoE Discovery traffic 
(pppoe_discovery_traffic)
|This trigger is checked continuously for PPPoE discovery traffic. The update interval is defined by the timespan parameter of the attributes.
|pppoe_discovery_packets
|mandatory
|-
|Profinet: Traffic of Profinet devices 
(profinet_traffic)
|This trigger is checked continuously for Profinet traffic. For max jitter, the update interval is defined by the timespan parameter of the attributes. All other attributes will be checked upon event.
|alarms_low, alarms_high, errors, frames_lost, frames_repeated, frames_wrong_sequence, max_jitter
|mandatory
|-
|PTP: Timestamp packet 
(ptp_timestamp_packet)
|This trigger is checked when a PTP packet containing a valid timestamp is seen.
|time_offset
|mandatory
|-
|QOS: Traffic on QoS classes 
(qos_traffic)
|This trigger is checked continuously for each active QoS class. The update interval is defined by the timespan parameter of the attributes.
|throughput
|mandatory
|-
|RTP: Traffic for RTP connections 
(rtp_traffic)
|This trigger is checked continuously for traffic of each RTP connection. The update interval is defined by the timespan parameter of the attributes.
|jitter, percent_loss
|mandatory
|-
|SIP: Call end 
(sip_call_end)
|This trigger is checked when a SIP call ended.
|duration, status, mos, percent_loss, jitter, total_packets, total_bytes, total_caller_packets, total_callee_packets, total_caller_bytes, total_callee_bytes
|mandatory
|-
|SMB: SMB1 negotiation 
(smb_v1_negotiation)
|This trigger is executed at the beginning of each SMB connection and checks whether insecure SMB1 has been negotiated.
|
|none
|-
|SSL: Handshake 
(ssl_handshake)
|This trigger is checked during handshake of each SSL connection.
|certificate_expires, tls_alert_level
|mandatory
|-
|SSL: SSL/TLS version negotiation 
(tls_version)
|This trigger is checked during version negotiation at handshake of each SSL connection.
|used_tls_version
|mandatory
|}

==== Special trigger properties ====
Some triggers are checked continuously every configured time span period, so the incidents are generated differently than for fixed event specific triggers like a call end.

# Repeating incidents: The following triggers will be evaluated every configured time span and will be re-issued whenever the configured attributes match.
## ip_traffic
## mac_traffic
## qos_traffic
## rtp_traffic
# Start/stop incidents: The following triggers are reported once the configured attributes match and for a second time when the attributes no longer match.
## global_traffic

So for repeating incidents you will get repeated incidents for the same attribute every time span. For example, if an IP address has traffic of 100 Mbit/s for 2 minutes and a rule checks for more than 50 Mbit/s over 30 seconds, the rule will hit 4 times. There will be one incident which will contain the exact number of repetitions for reference.

For start/stop incidents, you will only see two rule hits and the incident description will state the start and stop time.

=== Available attributes ===

* '''absolute_loss''': Count of lost packets for IEC104 connection.
* '''alarms_low''', '''alarms_high''': Whether an low/high alarm occurred for a Profinet device.
* '''broadcast_packet_rate''': The attribute is the number of packets per second on average over the configured timespan for MAC broadcast packets.
* '''bytes_captured''': The amount of bytes captured by a ring buffer in the given timespan.
* '''bytes_dropped''': The amount of bytes dropped by a ring buffer in the given timespan.
* '''certificate_expires''': This is the number of days until the certificate expires. If the certificate is already expired, the value is <= 0.
* '''channel_status''': 0 means that the LACP port channel is not synchronized, 1 means that the LACP port channel is synchronized.
* '''duration''':
** ''IP: Connection end'': The time between first and last packet of the flow.
** ''SIP: Call end'': The call duration.
* '''errors''':
** ''Profinet: Traffic of Profinet devices: Whether errors occured.
* '''error_type''': equal or not equal to:
** Format Error: DNS responds a format error.
** Non-existent Domain: DNS could not find queried domain name.
** Server Failure: DNS responds server failure.
* '''frames_lost''', '''frames_repeated''', '''frames_wrong_sequence''': Whether Profinet frames have been seen with problems in sequence. For loss the count of lost frames is calculated.
* '''geolocation''': checks if a country is part of the connection
** '''Direction''': The direction of traffic
*** ''from'': Traffic is coming ''from the'' specified country
*** ''to'': Traffic is going ''to'' the specified country
*** ''any:'' The specified country is on either side of the connection, or on neither side if the inequality is selected.
* '''GoCBRef''', The GOOSE control block reference name of the device to filter.
* '''gps_sync_status''': 0 means that the GPS clock in not synchronized, 1 means that the GPS clock is synchronized.
* '''handshake_failed''': Whether TCP handshake failed, i.e. one packet of SYN, SYN-ACK, ACK sequence is missing. If no handshake is seen at all but data (e.g. Allegro was started in the middle of a connection), no incident is generated.
* '''handshake_time''': The TCP handshake time between the first SYN packet and the ACK packet for the SYN/ACK packet of the server.
** '''client_handshake_time''': The TCP handshake time between the SYN/ACK packet of the server and the ACK packet of the client.
** '''server_handshake_time''': The TCP handshake time between the first SYN packet of the client and the SYN/ACK packet of the server.
* '''interface_speed''': The current speed of the interface in Mbit/s.
* '''interface_status''': 0 means interface is down, 1 means interface is up.
* '''jitter''':
** ''SIP: Call end'': The average jitter of the call, using the maximum value of both call sides.
** ''RTP: Traffic for RTP connections'': The average jitter of the RTP connection for the given timespan, using the maximum value of both directions.
* '''l4_protocol''': The layer 4 protocol. Can be TCP, UDP or other.
* '''l7_protocol''': The layer 7 protocol short name. Can also be a list, e.g. "HTTP, SSH, DHCP"
* '''local_ip''': Whether the IP is local (10/8, 172.16/12, 192.168/16, 169.254/16, fe80::/10, fc00::/7)
* '''link_speed_difference''': This is the absolute difference between the speeds of both interface of a link in Mbit/s.
* '''mac_count''': The number of different MAC addresses for the corresponding IP address.
* '''max_jitter''': The max jitter value for a Profinet device in % in a given timespan.
* '''mos''': The average MOS quality value of the call, using the minimum of both call sides.
* '''new_connections''': The amount of newly created connections (TCP and UDP) for the given timespan.
* '''not_in_order''': Count of not in order packets for IEC104 connection. The sequence number could be too high, too low or repeated.
* '''packet_rate''': The packet rate in packets per second on average during the configured timespan.
* '''packet_rate_increase''': The packet rate increase in % during the configured timespan compared to the average packet rate of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''percent_loss''':
** ''SIP: Call end'': The percentage of RTP packet loss for the call, accounting packets from both directions.
** ''RTP: Traffic for RTP connections'': The percentage of RTP packet loss for the given timespan, accounting packets from both directions of the RTP connection.
** ''IEC104: Traffic for IEC104 connections'': The percentage of IEC104 packet loss for the given timespan, accounting packets from both directions of the IEC104 connection.
* '''percent_transmissions''': The amount of TCP retransmission as a percentage of the total bytes.
* '''port_range''': The TCP or UDP port. Can be also a range, e.g. 80,443,8443-8445
* '''pppoe_discovery_packets''': The number of PPPoE discovery packets seen during the configured timespan.
* '''response_time''': The response time of IEC104 ACT requests and ACTCON replies.
* '''retransmission_ratio''': The TCP retransmission ratio seen in the configured timespan.
* '''since_start_time''':
** ''MAC: New L7 protocol'': This is the number of seconds after packet processing start when a new Layer-7 protocol for the MAC address appeared.
** ''MAC: New MAC address'': This is the number of seconds after packet processing start when the MAC address appeared. This is useful to only report new MAC address after some learning time.
** ''IP: New local IP address'': This is the number of seconds after packet processing start when the IP address appeared. This is useful to only report new IP address after some learning time.
** ''IP: New local L7 protocol'': This is the number of seconds after packet processing start when the Layer-7 protocol for the IP address appeared.
** ''Global: Connection start'': This is the number of seconds after packet processing start when the connection hast been started. This is useful to only report new connections after some learning time.
* '''status''': The call status code (a three digit number, like 200 for Success)
* '''tcp_handshake_time''': The TCP handshake time.
* '''tcp_fin_packets''': The number of TCP FIN packets (RX + TX) seen in the configured timespan.
* '''tcp_rst_packets''': The number of TCP RST packets (RX + TX) seen in the configured timespan.
* '''tcp_syn_packets''': The number of TCP SYN packets (RX + TX) seen in the configured timespan.
* '''throughput''': The throughput bandwidth in bit/s on average during the configured timespan.
* '''throughput_increase''': The throughput bandwidth increase in % during the configured timespan compared to the average throughput of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''time_offset''': The time offset between the local time and the timestamp seen in the PTP packet.
* '''time_since_first_unanswered_request''': This is the time span between when the trigger is checked and the first DNS request that has not been answered by the DNS server.
* '''time_since_last_mac''': This is the number of seconds between changed MAC addresses. If, for examples, dynamic IP assignment is used, changing MAC addresses is normal so the test can be limited to only a certain amount of time.
* '''tls_alert_level''': The alert level of a TLS alert packet. Can be 'fatal', 'warning' or 'unknown'. A fatal alert will be sent if e.g. TLS handshake failed and connection shall be closed.
* '''total_bytes''':
** ''IP: Connection end'': The total number of bytes seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of bytes seen in the configured timespan.
** '''total_callee_bytes''': The number of bytes seen for the callee of the call.
** '''total_caller_bytes''': The number of bytes seen for the caller of the call.
* '''total_packets''':
** ''IP: Connection end'': The total number of packets seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of packets seen in the configured timespan.
** '''total_callee_packets''': The number of packets seen for the callee of the call.
** '''total_caller_packets''': The number of packets seen for the caller of the call.
* '''ttl_change''': Whether TTL or hop limit has changed.
* '''type''': The type of PPPoE discovery packet (PADI, PADO, PADR, PADS, PADT or any).
* '''used_size''': The percentage of the ring buffer that needs to be filled.
* '''used_tls_version''': The TLS version (SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3)
* '''window_below_mss''': Whether the smallest announced TCP window was below the TCP MSS value. An additional offset is available, to check whether window was smaller than MSS + x bytes.
* '''zero_window_packets''': The number of packets with a TCP window of 0 for both directions of the flow.
* '''zero_window_packets''': The number of zero window packets seen in the configured timespan.

=== Capture settings ===
It is possible to automatically capture traffic for occurred incidents. These global settings control where capture files are stored and the capturing itself can be enabled for each rule separately.

The incident capture feature requires an active packet ring buffer since the packets are extracted from the buffer at the end of the incident period.

Available settings:

* Capture cooldown period: For each rule a cooldown period prevents multiple captures from happening in fast succession. By default, new captures happen firstly after 5 seconds, but any other value of at least 1 second can be configured. The cooldown is applied to each rule separately, but for each individual rule it does not matter if the same or a different entity triggers an incident. The incident is still reported within the cooldown period, but no additional capture is started.
* Storage device: Select the storage device where the captures should be stored on.
* Storage directory: Enter the directory where capture files should be stored or leave empty to use the top level directory.
* Select packet ring buffer to capture from: if multiple ring buffer cluster are in use, you can select which ring buffer to use for extraction.
* Capture profile: A capture profile can be configured to apply packet truncation rules to the capture file. If unset, the complete packets are captured (if the ring buffer uses separate truncation rules, truncated packets might still be within the capture file).

== Time Profiles ==
Incident rules can be active configured to be active in configured time spans (time profiles).

Every time profile allows the user to define one or more time spans per day of the week in which a rule should be active. After saving the user is able select the time profile when editing the rule.

Notes: Overlapping time spans will be merged. The earliest a time span is allowed to start is 0 and the latest end is 24, minutes are not allowed. The rule is not active for a day if there is no time span defined for the day.

== Channel configuration ==
[[File:Incidents channels.png|thumb|600x600px|Channel configuration]]
Incidents can be reported on different channels. The configuration allows to add new channels so they can be selected in the rule configuration described above.

Each channel can be of type:

'''email''' Incidents will be sent to the email address configured in the [[Global settings]].

'''kafka''' The incidents are sent to a topic on the configured Apache Kafka server. The message is the same as for syslog.
* Bootstrap Server: hostname/ip:port of a Kafka Broker or multiple Brokers separated by comma
* Protocol: Plaintext (no authentication, no encryption), SASL Paintext (Plain authentication, no encryption), SASL SSL (Plain authentication, TLS/SSL encryption)
* Ignore TLS Certificate: Ignore the TLS Certificate of the Brokers (only SASL SSL)
* Username: Broker Login (only SASL)
* Password: Broker Login (only SASL)
* Topic: The name of the topic into which the Incidents are sent.

'''snmp_trap''' Incidents will be sent to the configured SNMP trap receiver. A MIB file with the Allegro Network Multimeter SNMP trap definitions is available for download in the channel configuration dialog.
* Version: Supported SNMP version of the trap receiver (SNMP v2c or SNMP v3)
* Trap receiver (manager) hostname/IP: The trap receiver hostname or IP address

''SNMP v2c'':
* Community name: SNMP community name expected by the trap receiver

''SNMP v3'':
* Authentication protocol: Protocol for authenticated messages (MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512)
* Authentication password: Pass phrase for authenticated messages
* Privacy protocol: Protocol for message encryption (AES, DES)
* Privacy password: Pass phrase for message encryption
* Security name: Security name for authenticated SNMP messages
* Security level: Security level for SNMP messages (noAuthNoPriv, authNoPriv, authPriv)
* Engine ID: Authoritative (security) engineID (hexadecimal number)

'''syslog''' Incidents will be sent to the configured syslog server via TCP on any TCP or UDP port.

[[File:Incidents add channel.png|thumb|alt=|none|Adding a new channel]]
Each channel also uses a minimum severity setting, so only incidents are reported which are of at least that severity.

Each channel can be configured to only handle incidents from live traffic or from replayed traffic.

Some incidents cannot be configured via rules and you can choose to get those incidents also via email by enabling the settings at the lower part of the settings page.

== Other settings ==

=== Interface burst incident ===
[[File:Incidents others.png|thumb|600x600px|Other incidents]]
Burst incidents with milli-second resolution can be generated when the interface throughput exceeds a configurable threshold. The incident contains a graph of traffic for that interface with some data points before and after the threshold has been exceeded depending on the measurement interval. A PCAP link for capturing from the packet ring buffer is shown. For further investigation of that incident, the button "Use as global time range" can be used to set the global range to the start and end of the incident graph (at least 5 seconds) so that all modules of the Allegro Network Multimeter show that time span.

The incident generation can be configured in the "Other settings" tab as follows:
* '''Report "throughput threshold exceeded" with severity''': report an incident with the selected severity level if the throughput of any network interface exceeded.
* '''Throughput threshold (Mbit/s)''': The threshold is configured in Mbit/s.
* '''How long throughput must be above threshold to generate incident (in milliseconds)''': The throughput must exceed the threshold for this duration in order to generate the incident. If set to zero (default) the incident is generated immediately after the threshold has been exceeded.
* '''Throughput cool-down period between two incidents in milliseconds''': Defines the time after an incident where no new incident is generated even if the threshold is exceeded. If this period is passed, throughput incidents could be generated again.
Since each burst incidents stores the high resolution traffic graph, this feature uses a significant amount of memory. The actual amount is shown below and also depends on the maximum number of incidents configured in the section below.

=== Generic incident settings ===
This section allows to modify generic settings regarding the incident feature:

* '''Maximum number of stored incidents''': This value defines how many incidents are stored before old incidents are removed. Increasing this value also increased the amount of memory reserved for this feature. The corresponding value for the active setting is shown below, changing the configuration value requires a restart of the packet processing to take affect.

== Occured incidents ==
This page shows up to the last incidents occurred on the system. The table can be filtered for specific severity levels, as well as for specific trigger sources by selecting the trigger from the drop down menu.
[[File:Incidents list filter.png|thumb|600x600px|Filter incidents by severity or trigger]]
The list can also be filtered for the subject of the incident.

Individual incidents can be viewed in detail by clicking on the subject. The details page shows detailed information including links to the relevant measurement page.

Incidents can be deleted individually by clicking on the delete button next to the incident, or all incidents can be deleted by clicking on the button on the top right of the page.

The number of incidents available in this view is limited by a configurable number (firmware <4.1 was limited to 1000), the configuration as available in the "Other settings" tab.

== Statistics about incident rules ==
[[File:Incidents stats.png|thumb|600x600px|Statistics about rules]]
This page shows graphs about how often each rule has been hit both in absolute numbers as well as relatively to how often the rule has been checked.

== Incident list per measurement modules ==
Since incidents are triggered by different measurement modules (as indicate by the prefix of the trigger name, like the mac or ip module), the list of incidents from that specific module can also be seen in the corresponding tab of the measurement module for quicker access. This per-module view only lists those incidents coming from that module, all other potential incidents are hidden and must be accessed in their corresponding module page, or in the global view in the "Generic -> Incident" menu.

== Limitations ==
Some technical limitations apply:

* continuously checked triggers like "IP traffic" are only evaluated if there was at least one packet in the corresponding time interval. Therefore, rules check for zero packet count or throughput will never match.

Incidents

2024-08-08T16:06:42Z

Hartmut: /* Available triggers */ add GOOSE state number change trigger

[[File:Incidents_list.png|alt=|none|thumb|800x800px|Incident page]]
Incidents are used to alarm the user when configured network events occur, usually for traffic based rules, but also for system-specific events. These notifications can be viewed in the web GUI and may also be delivered on various notification channels. Repeating incidents are counted as such and the time of the first and last occurrence of an incident is remembered. This feature can be disabled for some incidents. What makes an incident unique depends on the type of incident.

The incident feature allows to define rules which are checked on the configured trigger point, like when a connection ends, a SIP call ends, or for checks on ongoing traffic. When such a trigger hits, configurable traffic attributes will be checked and if all attributes of a rule match, an incident is created.

Occurred incidents can be seen in the web interface, additionally reporting via the following notification channels is possible:
* email
* Apache Kafka
* SNMP trap
* syslog

The first occurrence of a medium or high severity incident will also trigger a status notification which is visible at the top right of the web GUI.

A configurable number of incidents will be remembered by the system and if the limit is exceeded the oldest incidents will be discarded [fixed number of 1000 incidents in firmware < 4.1].

== Rule configuration ==
[[File:Incidents rules.png|thumb|600x600px|Rule configuration]]
Incident rules can be defined in the "Configuration of incident rules" tab in the menu "Generic -> Incidents". All changes to the rule configuration will only take effect after saving the current configuration by clicking on the save button at the bottom of the page.

The page shows a table containing the existing rules and their configuration.

Each existing rule can be modified by clicking on the pencil symbol, or deleted by clicking on the "minus" symbol.

New rules can be added by clicking on the "Add rule" button. A dialog appears allowing for configuration of the rule. The same dialog is used when modifying an existing rule.

=== Add/modify a rule ===
[[File:Incidents add rule.png|thumb|600x600px|Add rule dialog]]
A rule is defined by the following settings:

* Rule name: This is an arbitrary text describing the purpose of the rule. This text is shown in the incident list and email/Kafka/SNMP trap/syslog ouptut.
* Severity: three different severity values "low", "medium", and "high" can be used to group more important and less important incidents. Reporting channels can be configured to only report incidents of a minimum severity level. A rule can also be disabled by choosing the severity level "disabled". It will not be evaluated and can be enabled later at will.
* Trigger: The trigger defines when a rule is evaluated. For each available trigger, a description is shown next to it giving more details about the trigger. Some triggers are evaluated at a very specific time, like when a VoIP call ends, or are evaluated regularly like for throughput triggers of IP traffic which can be configured to be checked periodically. See list below for a detailed description of the available triggers.
* Attributes: Attributes are used to make actual comparison of expected values vs. actual values.
** Each trigger has a different set of attributes which can be checked for, and some triggers don't need to have an attribute at all. See list below for a detailed description of the available attributes
** Up to four attributes can be added by clicking on the "Add attribute" button.
** Multiple attributes must all match at the same time to let the rule create an incident.
** Each attribute can be compared to a specific value, so that the actual value is lower, equal, or greater than a defined value.
** Some attributes have an additional parameter, like a time span which defines how the attribute value is calculated.
* Virtual link group: The rule can be limited to a selected [[Virtual Link Group functionality|virtual link group]] or to be applied for any group. Some triggers cannot be limited to a virtual link group so the configuration will be hidden.
* IP filter: Depending on the selected trigger, the rule can be limited to a specific IP address. The IP filter can also be an IP subnet in the format IP/mask-length (Example: 10.0.0.0/8)
* IP group: Depending on the selected trigger, the rule can be applied to an IP group instead of an individual IP address.
* Virtual link group, IP and IP filter can also be used inversely by using the != comparator
* Report channel: Incidents are always visible in the web interface, but can also be reported via multiple channels which can be configured separately in the tab "Configuration of notification channels". Up to ten channels can be selected so that the incident for this rule is reported on each channel. Also, no channel can be configured so the incident is only accessible on the web interface.
* Aggregation of recurring Incidents: Incidents are aggregated by default. This means the table only shows the number of incidents of the type and the timestamps of the first and the last incident. This can be disabled for most of the incidents, so that you are able to see every indent of the incident-type.
* Time Profiles: You are able to set a profile which defines the active time of an incident rule.
* Traffic capturing: If supported by the trigger, the rule can be configured to capture the network traffic triggering the rule, including some extra time before and after the incident.
** Possible options:
*** Disabled: capturing is disabled for this rule
*** Live traffic: capturing happens only for live network traffic
*** Replay traffic: capturing happens only for replayed network traffic (from PCAP files)
*** Always: capturing happens in all traffic processing types.
** Extra capture time: configure the number of seconds before the start of the incident and after the end of the incident.
*** If a time span parameter is used for attributes, the capture time includes this time duration as well.
** The traffic is automatically filtered to only contain the traffic that actually triggered the rule, i.e., an IP address or an IP group for IP rules.

=== Available triggers ===
{| class="wikitable"
|+
!Trigger name
!Description
!Attributes
!Attribute usage
|-
|ARP: MAC change for an IP 
(arp_ip_mac_changed)
|This trigger is checked on an ARP response and MAC address changed for a requested IP.
|time_since_last_mac
|optional
|-
|DNS: Server is not responding 
(dns_server_not_responding)
|This trigger is checked when a DNS server is not responding for some time. A server is considered unresponsive when more than 3 requests to the DNS server went unanswered for a period of more than 5 seconds. Such a server must have answered at least two requests previously.
|time_since_first_unanswered_request
|optional
|-
|DNS: Server response error 
(dns_server_response_error)
|This trigger is checked when a DNS server responds a configured error of type format error, server failure or non-existing domain
|error_type
|mandatory
|-
|Global: Connection start 
(global_new_connection)
|This trigger is checked continuously at connection start. It can be used to report new connections with a certain layer 4 protocol and a given port range.
|l4_protocol, port_range, since_start_time
|mandatory
|-
|Global: GPS synchronization status change 
(global_gps_sync_status_change)
|This trigger is checked when the GPS clock synchronization status changes.
|gps_sync_status
|optional
|-
|Global: Number of connections 
(global_connections)
|This trigger is checked continuously whether the amount of newly created connections exceeds a threshold. The update interval is defined by the timespan parameter of the attributes.
|new_connections
|mandatory
|-
|Global: Regular expressions 
(global_regex_match)
|This trigger allows to configure a list of regular expressions and is checked for each packet whose L7 data matches one of the regular expressions in the list. Since there are no attributes associated with this trigger, this effectively means that any packet which matches one of the regular expressions will result in an incident. The incident also contains information about which connection this packet belongs to as well as which of the regular expressions matches the packet.
|
|no attributes are available for this trigger
|-
|Global: Ring buffer 
(global_ring_buffer)
|This trigger is checked continuously to report changes in the ring buffer.
|used_size, bytes_captured, bytes_dropped
|mandatory
|-
|Global: Speed change of an interface 
(global_interface_speed_change)
|This trigger is checked when the speed of an interfaces changes.
|interface_speed
|optional
|-
|Global: Speed mismatch for an interface pair 
(global_interface_speed_mismatch)
|This trigger is checked when the status or speed of an interfaces changes and mismatches the speed of corresponding interface of a link.
|link_speed_difference
|optional
|-
|Global: Status change of an interface 
(global_interface_status_change)
|This trigger is checked when the status of an interfaces changes.
|interface_status
|optional
|-
|Global: Traffic 
(global_traffic)
|This trigger is checked continuously for the total traffic of the device. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase
|mandatory
|-
|IEC 61850 - GOOSE: State number change 
(iec61850_goose_state_change)
|This trigger is checked when a change in the state number of GOOSE packets is detected.
|GoCBRef
|optional
|-
|IEC104: Response times 
(iec104_response_times)
|This trigger is checked whenever an IEC104 ACTCON reply for an ACT has been seen.
|response_time
|mandatory
|-
|IEC104: Traffic 
(iec104_traffic)
|This trigger is checked continuously for each IEC104 connection. The update interval is defined by the timespan parameter of the attributes.
|percent_loss, absolute_loss, not_in_order
|mandatory
|-
|IP: Connection end 
(ip_flow_end)
|This trigger checks the attributes whenever an IP flow ended.
|total_packets, total_bytes, tcp_handshake_time, percent_retransmissions, zero_window_packets, duration, l7_protocol
|mandatory
|-
|IP: Connection start 
(ip_flow_start)
|This trigger checks the attributes whenever an IP flow starts.
|new_connections, geolocation
|mandatory
|-
|IP: Local IP with multiple MAC addresses 
(ip_local_ip_multiple_macs)
|This trigger is checked on each new flow of a local IP address and more than one MAC address uses this IP.
|mac_count
|optional
|-
|IP: New local IP address 
(ip_new_local_ip)
|This trigger is checked once for each new IP belonging to a private network address range.
|since_start_time
|optional
|-
|IP: New L7 protocol 
(ip_new_l7_protocol)
|This trigger is checked once for each new l7 protocol used by an IP.
|since_start_time, local_ip, l7_protocol
|optional
|-
|IP: TCP handshake 
(ip_tcp_handshake)
|This trigger is checked after successful TCP handshake or at connection end if handshake failed.
|handshake_time, server_handshake_time, client_handshake_time, handshake_failed
|mandatory
|-
|IP: Traffic on IP addresses 
(ip_traffic)
|This trigger is checked continuously for each active IP or IP group. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase, total_packets, total_bytes, retransmission_ratio, zero_window_packets, tcp_syn_packets, tcp_fin_packets, tcp_rst_packets
|mandatory
|-
|IP: TTL change 
(ip_ttl_change)
|This trigger is checked continuously for each active IP.
|ttl_change
|mandatory
|-
|LACP: Status change of a channel 
(lacp_channel_status_change)
|This trigger is checked when the status of a LACP port channel changes.
|channel_status
|optional
|-
|MAC: New L7 protocol 
(mac_new_l7_protocol)
|This trigger is checked when a unicast MAC address uses a l7 protocol for the first time.
|since_start_time
|optional
|-
|MAC: New MAC address 
(mac_new_address)
|This trigger is checked once when a new unicast MAC address appears for the first time.
|since_start_time
|optional
|-
|MAC: Traffic on MAC addresses 
(mac_traffic)
|This trigger is checked continuously for each active MAC address. The update interval is defined by the timespan parameter of the attributes.
|broadcast_packet_rate
|mandatory
|-
|PPPoE: PPPoE Discovery traffic 
(pppoe_discovery_traffic)
|This trigger is checked continuously for PPPoE discovery traffic. The update interval is defined by the timespan parameter of the attributes.
|pppoe_discovery_packets
|mandatory
|-
|Profinet: Traffic of Profinet devices 
(profinet_traffic)
|This trigger is checked continuously for Profinet traffic. For max jitter, the update interval is defined by the timespan parameter of the attributes. All other attributes will be checked upon event.
|alarms_low, alarms_high, errors, frames_lost, frames_repeated, frames_wrong_sequence, max_jitter
|mandatory
|-
|PTP: Timestamp packet 
(ptp_timestamp_packet)
|This trigger is checked when a PTP packet containing a valid timestamp is seen.
|time_offset
|mandatory
|-
|QOS: Traffic on QoS classes 
(qos_traffic)
|This trigger is checked continuously for each active QoS class. The update interval is defined by the timespan parameter of the attributes.
|throughput
|mandatory
|-
|RTP: Traffic for RTP connections 
(rtp_traffic)
|This trigger is checked continuously for traffic of each RTP connection. The update interval is defined by the timespan parameter of the attributes.
|jitter, percent_loss
|mandatory
|-
|SIP: Call end 
(sip_call_end)
|This trigger is checked when a SIP call ended.
|duration, status, mos, percent_loss, jitter, total_packets, total_bytes, total_caller_packets, total_callee_packets, total_caller_bytes, total_callee_bytes
|mandatory
|-
|SMB: SMB1 negotiation 
(smb_v1_negotiation)
|This trigger is executed at the beginning of each SMB connection and checks whether insecure SMB1 has been negotiated.
|
|none
|-
|SSL: Handshake 
(ssl_handshake)
|This trigger is checked during handshake of each SSL connection.
|certificate_expires, tls_alert_level
|mandatory
|-
|SSL: SSL/TLS version negotiation 
(tls_version)
|This trigger is checked during version negotiation at handshake of each SSL connection.
|used_tls_version
|mandatory
|}

==== Special trigger properties ====
Some triggers are checked continuously every configured time span period, so the incidents are generated differently than for fixed event specific triggers like a call end.

# Repeating incidents: The following triggers will be evaluated every configured time span and will be re-issued whenever the configured attributes match.
## ip_traffic
## mac_traffic
## qos_traffic
## rtp_traffic
# Start/stop incidents: The following triggers are reported once the configured attributes match and for a second time when the attributes no longer match.
## global_traffic

So for repeating incidents you will get repeated incidents for the same attribute every time span. For example, if an IP address has traffic of 100 Mbit/s for 2 minutes and a rule checks for more than 50 Mbit/s over 30 seconds, the rule will hit 4 times. There will be one incident which will contain the exact number of repetitions for reference.

For start/stop incidents, you will only see two rule hits and the incident description will state the start and stop time.

=== Available attributes ===

* '''absolute_loss''': Count of lost packets for IEC104 connection.
* '''alarms_low''', '''alarms_high''': Whether an low/high alarm occurred for a Profinet device.
* '''broadcast_packet_rate''': The attribute is the number of packets per second on average over the configured timespan for MAC broadcast packets.
* '''bytes_captured''': The amount of bytes captured by a ring buffer in the given timespan.
* '''bytes_dropped''': The amount of bytes dropped by a ring buffer in the given timespan.
* '''certificate_expires''': This is the number of days until the certificate expires. If the certificate is already expired, the value is <= 0.
* '''channel_status''': 0 means that the LACP port channel is not synchronized, 1 means that the LACP port channel is synchronized.
* '''duration''':
** ''IP: Connection end'': The time between first and last packet of the flow.
** ''SIP: Call end'': The call duration.
* '''errors''':
** ''Profinet: Traffic of Profinet devices: Whether errors occured.
* '''error_type''': equal or not equal to:
** Format Error: DNS responds a format error.
** Non-existent Domain: DNS could not find queried domain name.
** Server Failure: DNS responds server failure.
* '''frames_lost''', '''frames_repeated''', '''frames_wrong_sequence''': Whether Profinet frames have been seen with problems in sequence. For loss the count of lost frames is calculated.
* '''geolocation''': checks if a country is part of the connection
** '''Direction''': The direction of traffic
*** ''from'': Traffic is coming ''from the'' specified country
*** ''to'': Traffic is going ''to'' the specified country
*** ''any:'' The specified country is on either side of the connection, or on neither side if the inequality is selected.
* '''gps_sync_status''': 0 means that the GPS clock in not synchronized, 1 means that the GPS clock is synchronized.
* '''handshake_failed''': Whether TCP handshake failed, i.e. one packet of SYN, SYN-ACK, ACK sequence is missing. If no handshake is seen at all but data (e.g. Allegro was started in the middle of a connection), no incident is generated.
* '''handshake_time''': The TCP handshake time between the first SYN packet and the ACK packet for the SYN/ACK packet of the server.
** '''client_handshake_time''': The TCP handshake time between the SYN/ACK packet of the server and the ACK packet of the client.
** '''server_handshake_time''': The TCP handshake time between the first SYN packet of the client and the SYN/ACK packet of the server.
* '''interface_speed''': The current speed of the interface in Mbit/s.
* '''interface_status''': 0 means interface is down, 1 means interface is up.
* '''jitter''':
** ''SIP: Call end'': The average jitter of the call, using the maximum value of both call sides.
** ''RTP: Traffic for RTP connections'': The average jitter of the RTP connection for the given timespan, using the maximum value of both directions.
* '''l4_protocol''': The layer 4 protocol. Can be TCP, UDP or other.
* '''l7_protocol''': The layer 7 protocol short name. Can also be a list, e.g. "HTTP, SSH, DHCP"
* '''local_ip''': Whether the IP is local (10/8, 172.16/12, 192.168/16, 169.254/16, fe80::/10, fc00::/7)
* '''link_speed_difference''': This is the absolute difference between the speeds of both interface of a link in Mbit/s.
* '''mac_count''': The number of different MAC addresses for the corresponding IP address.
* '''max_jitter''': The max jitter value for a Profinet device in % in a given timespan.
* '''mos''': The average MOS quality value of the call, using the minimum of both call sides.
* '''new_connections''': The amount of newly created connections (TCP and UDP) for the given timespan.
* '''not_in_order''': Count of not in order packets for IEC104 connection. The sequence number could be too high, too low or repeated.
* '''packet_rate''': The packet rate in packets per second on average during the configured timespan.
* '''packet_rate_increase''': The packet rate increase in % during the configured timespan compared to the average packet rate of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''percent_loss''':
** ''SIP: Call end'': The percentage of RTP packet loss for the call, accounting packets from both directions.
** ''RTP: Traffic for RTP connections'': The percentage of RTP packet loss for the given timespan, accounting packets from both directions of the RTP connection.
** ''IEC104: Traffic for IEC104 connections'': The percentage of IEC104 packet loss for the given timespan, accounting packets from both directions of the IEC104 connection.
* '''percent_transmissions''': The amount of TCP retransmission as a percentage of the total bytes.
* '''port_range''': The TCP or UDP port. Can be also a range, e.g. 80,443,8443-8445
* '''pppoe_discovery_packets''': The number of PPPoE discovery packets seen during the configured timespan.
* '''response_time''': The response time of IEC104 ACT requests and ACTCON replies.
* '''retransmission_ratio''': The TCP retransmission ratio seen in the configured timespan.
* '''since_start_time''':
** ''MAC: New L7 protocol'': This is the number of seconds after packet processing start when a new Layer-7 protocol for the MAC address appeared.
** ''MAC: New MAC address'': This is the number of seconds after packet processing start when the MAC address appeared. This is useful to only report new MAC address after some learning time.
** ''IP: New local IP address'': This is the number of seconds after packet processing start when the IP address appeared. This is useful to only report new IP address after some learning time.
** ''IP: New local L7 protocol'': This is the number of seconds after packet processing start when the Layer-7 protocol for the IP address appeared.
** ''Global: Connection start'': This is the number of seconds after packet processing start when the connection hast been started. This is useful to only report new connections after some learning time.
* '''status''': The call status code (a three digit number, like 200 for Success)
* '''tcp_handshake_time''': The TCP handshake time.
* '''tcp_fin_packets''': The number of TCP FIN packets (RX + TX) seen in the configured timespan.
* '''tcp_rst_packets''': The number of TCP RST packets (RX + TX) seen in the configured timespan.
* '''tcp_syn_packets''': The number of TCP SYN packets (RX + TX) seen in the configured timespan.
* '''throughput''': The throughput bandwidth in bit/s on average during the configured timespan.
* '''throughput_increase''': The throughput bandwidth increase in % during the configured timespan compared to the average throughput of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''time_offset''': The time offset between the local time and the timestamp seen in the PTP packet.
* '''time_since_first_unanswered_request''': This is the time span between when the trigger is checked and the first DNS request that has not been answered by the DNS server.
* '''time_since_last_mac''': This is the number of seconds between changed MAC addresses. If, for examples, dynamic IP assignment is used, changing MAC addresses is normal so the test can be limited to only a certain amount of time.
* '''tls_alert_level''': The alert level of a TLS alert packet. Can be 'fatal', 'warning' or 'unknown'. A fatal alert will be sent if e.g. TLS handshake failed and connection shall be closed.
* '''total_bytes''':
** ''IP: Connection end'': The total number of bytes seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of bytes seen in the configured timespan.
** '''total_callee_bytes''': The number of bytes seen for the callee of the call.
** '''total_caller_bytes''': The number of bytes seen for the caller of the call.
* '''total_packets''':
** ''IP: Connection end'': The total number of packets seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of packets seen in the configured timespan.
** '''total_callee_packets''': The number of packets seen for the callee of the call.
** '''total_caller_packets''': The number of packets seen for the caller of the call.
* '''ttl_change''': Whether TTL or hop limit has changed.
* '''type''': The type of PPPoE discovery packet (PADI, PADO, PADR, PADS, PADT or any).
* '''used_size''': The percentage of the ring buffer that needs to be filled.
* '''used_tls_version''': The TLS version (SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3)
* '''window_below_mss''': Whether the smallest announced TCP window was below the TCP MSS value. An additional offset is available, to check whether window was smaller than MSS + x bytes.
* '''zero_window_packets''': The number of packets with a TCP window of 0 for both directions of the flow.
* '''zero_window_packets''': The number of zero window packets seen in the configured timespan.

=== Capture settings ===
It is possible to automatically capture traffic for occurred incidents. These global settings control where capture files are stored and the capturing itself can be enabled for each rule separately.

The incident capture feature requires an active packet ring buffer since the packets are extracted from the buffer at the end of the incident period.

Available settings:

* Capture cooldown period: For each rule a cooldown period prevents multiple captures from happening in fast succession. By default, new captures happen firstly after 5 seconds, but any other value of at least 1 second can be configured. The cooldown is applied to each rule separately, but for each individual rule it does not matter if the same or a different entity triggers an incident. The incident is still reported within the cooldown period, but no additional capture is started.
* Storage device: Select the storage device where the captures should be stored on.
* Storage directory: Enter the directory where capture files should be stored or leave empty to use the top level directory.
* Select packet ring buffer to capture from: if multiple ring buffer cluster are in use, you can select which ring buffer to use for extraction.
* Capture profile: A capture profile can be configured to apply packet truncation rules to the capture file. If unset, the complete packets are captured (if the ring buffer uses separate truncation rules, truncated packets might still be within the capture file).

== Time Profiles ==
Incident rules can be active configured to be active in configured time spans (time profiles).

Every time profile allows the user to define one or more time spans per day of the week in which a rule should be active. After saving the user is able select the time profile when editing the rule.

Notes: Overlapping time spans will be merged. The earliest a time span is allowed to start is 0 and the latest end is 24, minutes are not allowed. The rule is not active for a day if there is no time span defined for the day.

== Channel configuration ==
[[File:Incidents channels.png|thumb|600x600px|Channel configuration]]
Incidents can be reported on different channels. The configuration allows to add new channels so they can be selected in the rule configuration described above.

Each channel can be of type:

'''email''' Incidents will be sent to the email address configured in the [[Global settings]].

'''kafka''' The incidents are sent to a topic on the configured Apache Kafka server. The message is the same as for syslog.
* Bootstrap Server: hostname/ip:port of a Kafka Broker or multiple Brokers separated by comma
* Protocol: Plaintext (no authentication, no encryption), SASL Paintext (Plain authentication, no encryption), SASL SSL (Plain authentication, TLS/SSL encryption)
* Ignore TLS Certificate: Ignore the TLS Certificate of the Brokers (only SASL SSL)
* Username: Broker Login (only SASL)
* Password: Broker Login (only SASL)
* Topic: The name of the topic into which the Incidents are sent.

'''snmp_trap''' Incidents will be sent to the configured SNMP trap receiver. A MIB file with the Allegro Network Multimeter SNMP trap definitions is available for download in the channel configuration dialog.
* Version: Supported SNMP version of the trap receiver (SNMP v2c or SNMP v3)
* Trap receiver (manager) hostname/IP: The trap receiver hostname or IP address

''SNMP v2c'':
* Community name: SNMP community name expected by the trap receiver

''SNMP v3'':
* Authentication protocol: Protocol for authenticated messages (MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512)
* Authentication password: Pass phrase for authenticated messages
* Privacy protocol: Protocol for message encryption (AES, DES)
* Privacy password: Pass phrase for message encryption
* Security name: Security name for authenticated SNMP messages
* Security level: Security level for SNMP messages (noAuthNoPriv, authNoPriv, authPriv)
* Engine ID: Authoritative (security) engineID (hexadecimal number)

'''syslog''' Incidents will be sent to the configured syslog server via TCP on any TCP or UDP port.

[[File:Incidents add channel.png|thumb|alt=|none|Adding a new channel]]
Each channel also uses a minimum severity setting, so only incidents are reported which are of at least that severity.

Each channel can be configured to only handle incidents from live traffic or from replayed traffic.

Some incidents cannot be configured via rules and you can choose to get those incidents also via email by enabling the settings at the lower part of the settings page.

== Other settings ==

=== Interface burst incident ===
[[File:Incidents others.png|thumb|600x600px|Other incidents]]
Burst incidents with milli-second resolution can be generated when the interface throughput exceeds a configurable threshold. The incident contains a graph of traffic for that interface with some data points before and after the threshold has been exceeded depending on the measurement interval. A PCAP link for capturing from the packet ring buffer is shown. For further investigation of that incident, the button "Use as global time range" can be used to set the global range to the start and end of the incident graph (at least 5 seconds) so that all modules of the Allegro Network Multimeter show that time span.

The incident generation can be configured in the "Other settings" tab as follows:
* '''Report "throughput threshold exceeded" with severity''': report an incident with the selected severity level if the throughput of any network interface exceeded.
* '''Throughput threshold (Mbit/s)''': The threshold is configured in Mbit/s.
* '''How long throughput must be above threshold to generate incident (in milliseconds)''': The throughput must exceed the threshold for this duration in order to generate the incident. If set to zero (default) the incident is generated immediately after the threshold has been exceeded.
* '''Throughput cool-down period between two incidents in milliseconds''': Defines the time after an incident where no new incident is generated even if the threshold is exceeded. If this period is passed, throughput incidents could be generated again.
Since each burst incidents stores the high resolution traffic graph, this feature uses a significant amount of memory. The actual amount is shown below and also depends on the maximum number of incidents configured in the section below.

=== Generic incident settings ===
This section allows to modify generic settings regarding the incident feature:

* '''Maximum number of stored incidents''': This value defines how many incidents are stored before old incidents are removed. Increasing this value also increased the amount of memory reserved for this feature. The corresponding value for the active setting is shown below, changing the configuration value requires a restart of the packet processing to take affect.

== Occured incidents ==
This page shows up to the last incidents occurred on the system. The table can be filtered for specific severity levels, as well as for specific trigger sources by selecting the trigger from the drop down menu.
[[File:Incidents list filter.png|thumb|600x600px|Filter incidents by severity or trigger]]
The list can also be filtered for the subject of the incident.

Individual incidents can be viewed in detail by clicking on the subject. The details page shows detailed information including links to the relevant measurement page.

Incidents can be deleted individually by clicking on the delete button next to the incident, or all incidents can be deleted by clicking on the button on the top right of the page.

The number of incidents available in this view is limited by a configurable number (firmware <4.1 was limited to 1000), the configuration as available in the "Other settings" tab.

== Statistics about incident rules ==
[[File:Incidents stats.png|thumb|600x600px|Statistics about rules]]
This page shows graphs about how often each rule has been hit both in absolute numbers as well as relatively to how often the rule has been checked.

== Incident list per measurement modules ==
Since incidents are triggered by different measurement modules (as indicate by the prefix of the trigger name, like the mac or ip module), the list of incidents from that specific module can also be seen in the corresponding tab of the measurement module for quicker access. This per-module view only lists those incidents coming from that module, all other potential incidents are hidden and must be accessed in their corresponding module page, or in the global view in the "Generic -> Incident" menu.

== Limitations ==
Some technical limitations apply:

* continuously checked triggers like "IP traffic" are only evaluated if there was at least one packet in the corresponding time interval. Therefore, rules check for zero packet count or throughput will never match.

Path measurement

2024-07-24T15:34:55Z

Hartmut: /* Two-Way-Latency */ language improvements

== Path measurement ==

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

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

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

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

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

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

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

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

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

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

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

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

=== Settings ===

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

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

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

Measurement settings:

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

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

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

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

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

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

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

=== Parameters currently in use ===

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

=== Required actions ===

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

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

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

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

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

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

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

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

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

== Measurement statistics ==

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

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

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

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

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

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

==== Lost packets ====

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

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

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

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

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

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

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

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

=== IP addresses ===

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

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

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

==== Switching graph modes ====

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

== Limitations ==

There are some limitations about the path measurement:

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

== Typical use cases==

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

== Debug information ==

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

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

Possible problematic scenarios:

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

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

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

Both scenarios are not supported by the path measurement.

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

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

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

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

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

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

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

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

Live filtering of tables

2024-04-26T09:12:14Z

Hartmut: /* Available keywords */ add tds.loginack.tdsversion keyword

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Examples ==

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

== Notes ==

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

== Available keywords ==

The available keywords vary depending on the web interface section.

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

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

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

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

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

Measurement modules

2024-04-26T08:57:39Z

Hartmut: /* L7 - Application Layer */ add entries for IEC 61850 and TDS modules

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

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

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

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

* [[Fix_module|FIX module]]
:The FIX module shows information about '''F'''inancial '''I'''nformation e'''X'''change traffic.

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

* [[IEC61850_module|IEC 61850 module]]
:The IEC 61850 module analyzes '''G'''eneric '''O'''bject '''O'''riented '''S'''ubstation '''E'''vent (GOOSE) and IEC 61850 Sampled Values traffic and shows information about the different traffic types and sequence counter correctness.

* [[TDS_module|TDS module]]
:The TDS module analyzes MS-SQL '''T'''abular '''D'''ata '''S'''tream traffic and shows the protocol traffic, response times and the recognized negotiated protocol version.

* [[TETRA_module|TETRA module]]
:The TETRA module shows detailed information about '''Te'''rrestrial '''T'''runked '''Ra'''dio traffic.

* [[QUIC module]]
:The QUIC Analysis Module provides comprehensive insights into '''Q'''uick '''U'''DP '''I'''nternet '''C'''onnections traffic.

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

TDS module

2024-04-22T13:06:28Z

Hartmut: Create TDS module description

The TDS module shows information about TDS (Tabular Data Stream) traffic, used for database connections with Microsoft SQL Servers. Detected connections between clients and SQL servers are shown.

== Connections ==
[[File: TDS_connections.png|thumb|TDS connections common columns]]
All TDS connections with their client and server IPs and ports are shown together with the recognized TDS version. If the ''Timing'' toggle is activated, the start and end time, as well as the duration of the connection will be visible. Common traffic counters for total packets and bytes, as well as traffic rate counters for packets per second and bit per second can be selected with the ''Counters'' toggle. The connection quality can be evaluated in the TCP specific columns: the ''Response times'' toggle enables the view of TCP handshake time separated for client and server, as well as maximum and average response times. Retransmissions (in byte and as a percentage of the total traffic), missed bytes and duplicated ACK-packets are shown when the ''TCP Retransmissions'' toggle is enabled.

When enabled, graphs for bitrate and packet rate (individually selectable) are shown. The TDS traffic of each connection can be captured using the PCAP download button.

File:TDS connections.png

2024-04-22T12:32:52Z

Hartmut: MS-SQL TDS connections page

== Summary ==
MS-SQL TDS connections page

Incidents

2024-04-04T16:50:03Z

Hartmut: /* Configuration of incident rules */ Revert section name to 'Rule configuration' since it is used by manual button

[[File:Incidents_list.png|alt=|none|thumb|800x800px|Incident page]]
Incidents are used to alarm the user when configured network events occur, usually for traffic based rules, but also for system-specific events. These notifications can be viewed in the web GUI and may also be delivered on various notification channels. Repeating incidents are counted as such and the time of the first and last occurrence of an incident is remembered. This feature can be disabled for some incidents. What makes an incident unique depends on the type of incident.

The incident feature allows to define rules which are checked on the configured trigger point, like when a connection ends, a SIP call ends, or for checks on ongoing traffic. When such a trigger hits, configurable traffic attributes will be checked and if all attributes of a rule match, an incident is created.

Occurred incidents can be seen in the web interface, additionally reporting via the following notification channels is possible:
* email
* Apache Kafka
* SNMP trap
* syslog

The first occurrence of a medium or high severity incident will also trigger a status notification which is visible at the top right of the web GUI.

A configurable number of incidents will be remembered by the system and if the limit is exceeded the oldest incidents will be discarded [fixed number of 1000 incidents in firmware < 4.1].

== Rule configuration ==
[[File:Incidents rules.png|thumb|600x600px|Rule configuration]]
Incident rules can be defined in the "Configuration of incident rules" tab in the menu "Generic -> Incidents". All changes to the rule configuration will only take effect after saving the current configuration by clicking on the save button at the bottom of the page.

The page shows a table containing the existing rules and their configuration.

Each existing rule can be modified by clicking on the pencil symbol, or deleted by clicking on the "minus" symbol.

New rules can be added by clicking on the "Add rule" button. A dialog appears allowing for configuration of the rule. The same dialog is used when modifying an existing rule.

=== Add/modify a rule ===
[[File:Incidents add rule.png|thumb|600x600px|Add rule dialog]]
A rule is defined by the following settings:

* Rule name: This is an arbitrary text describing the purpose of the rule. This text is shown in the incident list and email/Kafka/SNMP trap/syslog ouptut.
* Severity: three different severity values "low", "medium", and "high" can be used to group more important and less important incidents. Reporting channels can be configured to only report incidents of a minimum severity level. A rule can also be disabled by choosing the severity level "disabled". It will not be evaluated and can be enabled later at will.
* Trigger: The trigger defines when a rule is evaluated. For each available trigger, a description is shown next to it giving more details about the trigger. Some triggers are evaluated at a very specific time, like when a VoIP call ends, or are evaluated regularly like for throughput triggers of IP traffic which can be configured to be checked periodically. See list below for a detailed description of the available triggers.
* Attributes: Attributes are used to make actual comparison of expected values vs. actual values.
** Each trigger has a different set of attributes which can be checked for, and some triggers don't need to have an attribute at all. See list below for a detailed description of the available attributes
** Up to four attributes can be added by clicking on the "Add attribute" button.
** Multiple attributes must all match at the same time to let the rule create an incident.
** Each attribute can be compared to a specific value, so that the actual value is lower, equal, or greater than a defined value.
** Some attributes have an additional parameter, like a time span which defines how the attribute value is calculated.
* Virtual link group: The rule can be limited to a selected [[Virtual Link Group functionality|virtual link group]] or to be applied for any group. Some triggers cannot be limited to a virtual link group so the configuration will be hidden.
* IP filter: Depending on the selected trigger, the rule can be limited to a specific IP address. The IP filter can also be an IP subnet in the format IP/mask-length (Example: 10.0.0.0/8)
* IP group: Depending on the selected trigger, the rule can be applied to an IP group instead of an individual IP address.
* Virtual link group, IP and IP filter can also be used inversely by using the != comparator
* Report channel: Incidents are always visible in the web interface, but can also be reported via multiple channels which can be configured separately in the tab "Configuration of notification channels". Up to ten channels can be selected so that the incident for this rule is reported on each channel. Also, no channel can be configured so the incident is only accessible on the web interface.
* Aggregation of recurring Incidents: Incidents are aggregated by default. This means the table only shows the number of incidents of the type and the timestamps of the first and the last incident. This can be disabled for most of the incidents, so that you are able to see every indent of the incident-type.
* Time Profiles: You are able to set a profile which defines the active time of an incident rule.
* Traffic capturing: If supported by the trigger, the rule can be configured to capture the network traffic triggering the rule, including some extra time before and after the incident.
** Possible options:
*** Disabled: capturing is disabled for this rule
*** Live traffic: capturing happens only for live network traffic
*** Replay traffic: capturing happens only for replayed network traffic (from PCAP files)
*** Always: capturing happens in all traffic processing types.
** Extra capture time: configure the number of seconds before the start of the incident and after the end of the incident.
*** If a time span parameter is used for attributes, the capture time includes this time duration as well.
** The traffic is automatically filtered to only contain the traffic that actually triggered the rule, i.e., an IP address or an IP group for IP rules.

=== Available triggers ===
{| class="wikitable"
|+
!Trigger name
!Description
!Attributes
!Attribute usage
|-
|ARP: MAC change for an IP 
(arp_ip_mac_changed)
|This trigger is checked on an ARP response and MAC address changed for a requested IP.
|time_since_last_mac
|optional
|-
|DNS: Server is not responding 
(dns_server_not_responding)
|This trigger is checked when a DNS server is not responding for some time. A server is considered unresponsive when more than 3 requests to the DNS server went unanswered for a period of more than 5 seconds. Such a server must have answered at least two requests previously.
|time_since_first_unanswered_request
|optional
|-
|DNS: Server response error 
(dns_server_response_error)
|This trigger is checked when a DNS server responds a configured error of type format error, server failure or non-existing domain
|error_type
|mandatory
|-
|Global: Connection start 
(global_new_connection)
|This trigger is checked continuously at connection start. It can be used to report new connections with a certain layer 4 protocol and a given port range.
|l4_protocol, port_range, since_start_time
|mandatory
|-
|Global: GPS synchronization status change 
(global_gps_sync_status_change)
|This trigger is checked when the GPS clock synchronization status changes.
|gps_sync_status
|optional
|-
|Global: Number of connections 
(global_connections)
|This trigger is checked continuously whether the amount of newly created connections exceeds a threshold. The update interval is defined by the timespan parameter of the attributes.
|new_connections
|mandatory
|-
|Global: Regular expressions 
(global_regex_match)
|This trigger allows to configure a list of regular expressions and is checked for each packet whose L7 data matches one of the regular expressions in the list. Since there are no attributes associated with this trigger, this effectively means that any packet which matches one of the regular expressions will result in an incident. The incident also contains information about which connection this packet belongs to as well as which of the regular expressions matches the packet.
|
|no attributes are available for this trigger
|-
|Global: Ring buffer 
(global_ring_buffer)
|This trigger is checked continuously to report changes in the ring buffer.
|used_size, bytes_captured, bytes_dropped
|mandatory
|-
|Global: Speed change of an interface 
(global_interface_speed_change)
|This trigger is checked when the speed of an interfaces changes.
|interface_speed
|optional
|-
|Global: Speed mismatch for an interface pair 
(global_interface_speed_mismatch)
|This trigger is checked when the status or speed of an interfaces changes and mismatches the speed of corresponding interface of a link.
|link_speed_difference
|optional
|-
|Global: Status change of an interface 
(global_interface_status_change)
|This trigger is checked when the status of an interfaces changes.
|interface_status
|optional
|-
|Global: Traffic 
(global_traffic)
|This trigger is checked continuously for the total traffic of the device. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase
|mandatory
|-
|IEC104: Response times 
(iec104_response_times)
|This trigger is checked whenever an IEC104 ACTCON reply for an ACT has been seen.
|response_time
|mandatory
|-
|IEC104: Traffic 
(iec104_traffic)
|This trigger is checked continuously for each IEC104 connection. The update interval is defined by the timespan parameter of the attributes.
|percent_loss, absolute_loss, not_in_order
|mandatory
|-
|IP: Connection end 
(ip_flow_end)
|This trigger checks the attributes whenever an IP flow ended.
|total_packets, total_bytes, tcp_handshake_time, percent_retransmissions, zero_window_packets, duration, l7_protocol
|mandatory
|-
|IP: Connection start 
(ip_flow_start)
|This trigger checks the attributes whenever an IP flow starts.
|new_connections, geolocation
|mandatory
|-
|IP: Local IP with multiple MAC addresses 
(ip_local_ip_multiple_macs)
|This trigger is checked on each new flow of a local IP address and more than one MAC address uses this IP.
|mac_count
|optional
|-
|IP: New local IP address 
(ip_new_local_ip)
|This trigger is checked once for each new IP belonging to a private network address range.
|since_start_time
|optional
|-
|IP: New L7 protocol 
(ip_new_l7_protocol)
|This trigger is checked once for each new l7 protocol used by an IP.
|since_start_time, local_ip, l7_protocol
|optional
|-
|IP: TCP handshake 
(ip_tcp_handshake)
|This trigger is checked after successful TCP handshake or at connection end if handshake failed.
|handshake_time, server_handshake_time, client_handshake_time, handshake_failed
|mandatory
|-
|IP: Traffic on IP addresses 
(ip_traffic)
|This trigger is checked continuously for each active IP or IP group. The update interval is defined by the timespan parameter of the attributes.
|throughput, throughput_increase, packet_rate, packet_rate_increase, total_packets, total_bytes, retransmission_ratio, zero_window_packets, tcp_syn_packets, tcp_fin_packets, tcp_rst_packets
|mandatory
|-
|IP: TTL change 
(ip_ttl_change)
|This trigger is checked continuously for each active IP.
|ttl_change
|mandatory
|-
|LACP: Status change of a channel 
(lacp_channel_status_change)
|This trigger is checked when the status of a LACP port channel changes.
|channel_status
|optional
|-
|MAC: New L7 protocol 
(mac_new_l7_protocol)
|This trigger is checked when a unicast MAC address uses a l7 protocol for the first time.
|since_start_time
|optional
|-
|MAC: New MAC address 
(mac_new_address)
|This trigger is checked once when a new unicast MAC address appears for the first time.
|since_start_time
|optional
|-
|MAC: Traffic on MAC addresses 
(mac_traffic)
|This trigger is checked continuously for each active MAC address. The update interval is defined by the timespan parameter of the attributes.
|broadcast_packet_rate
|mandatory
|-
|PPPoE: PPPoE Discovery traffic 
(pppoe_discovery_traffic)
|This trigger is checked continuously for PPPoE discovery traffic. The update interval is defined by the timespan parameter of the attributes.
|pppoe_discovery_packets
|mandatory
|-
|Profinet: Traffic of Profinet devices 
(profinet_traffic)
|This trigger is checked continuously for Profinet traffic. For max jitter, the update interval is defined by the timespan parameter of the attributes. All other attributes will be checked upon event.
|alarms_low, alarms_high, errors, frames_lost, frames_repeated, frames_wrong_sequence, max_jitter
|mandatory
|-
|PTP: Timestamp packet 
(ptp_timestamp_packet)
|This trigger is checked when a PTP packet containing a valid timestamp is seen.
|time_offset
|mandatory
|-
|QOS: Traffic on QoS classes 
(qos_traffic)
|This trigger is checked continuously for each active QoS class. The update interval is defined by the timespan parameter of the attributes.
|throughput
|mandatory
|-
|RTP: Traffic for RTP connections 
(rtp_traffic)
|This trigger is checked continuously for traffic of each RTP connection. The update interval is defined by the timespan parameter of the attributes.
|jitter, percent_loss
|mandatory
|-
|SIP: Call end 
(sip_call_end)
|This trigger is checked when a SIP call ended.
|duration, status, mos, percent_loss, jitter, total_packets, total_bytes, total_caller_packets, total_callee_packets, total_caller_bytes, total_callee_bytes
|mandatory
|-
|SMB: SMB1 negotiation 
(smb_v1_negotiation)
|This trigger is executed at the beginning of each SMB connection and checks whether insecure SMB1 has been negotiated.
|
|none
|-
|SSL: Handshake 
(ssl_handshake)
|This trigger is checked during handshake of each SSL connection.
|certificate_expires, tls_alert_level
|mandatory
|-
|SSL: SSL/TLS version negotiation 
(tls_version)
|This trigger is checked during version negotiation at handshake of each SSL connection.
|used_tls_version
|mandatory
|}

==== Special trigger properties ====
Some triggers are checked continuously every configured time span period, so the incidents are generated differently than for fixed event specific triggers like a call end.

# Repeating incidents: The following triggers will be evaluated every configured time span and will be re-issued whenever the configured attributes match.
## ip_traffic
## mac_traffic
## qos_traffic
## rtp_traffic
# Start/stop incidents: The following triggers are reported once the configured attributes match and for a second time when the attributes no longer match.
## global_traffic

So for repeating incidents you will get repeated incidents for the same attribute every time span. For example, if an IP address has traffic of 100 Mbit/s for 2 minutes and a rule checks for more than 50 Mbit/s over 30 seconds, the rule will hit 4 times. There will be one incident which will contain the exact number of repetitions for reference.

For start/stop incidents, you will only see two rule hits and the incident description will state the start and stop time.

=== Available attributes ===

* '''absolute_loss''': Count of lost packets for IEC104 connection.
* '''alarms_low''', '''alarms_high''': Whether an low/high alarm occurred for a Profinet device.
* '''broadcast_packet_rate''': The attribute is the number of packets per second on average over the configured timespan for MAC broadcast packets.
* '''bytes_captured''': The amount of bytes captured by a ring buffer in the given timespan.
* '''bytes_dropped''': The amount of bytes dropped by a ring buffer in the given timespan.
* '''certificate_expires''': This is the number of days until the certificate expires. If the certificate is already expired, the value is <= 0.
* '''channel_status''': 0 means that the LACP port channel is not synchronized, 1 means that the LACP port channel is synchronized.
* '''duration''':
** ''IP: Connection end'': The time between first and last packet of the flow.
** ''SIP: Call end'': The call duration.
* '''errors''':
** ''Profinet: Traffic of Profinet devices: Whether errors occured.
* '''error_type''': equal or not equal to:
** Format Error: DNS responds a format error.
** Non-existent Domain: DNS could not find queried domain name.
** Server Failure: DNS responds server failure.
* '''frames_lost''', '''frames_repeated''', '''frames_wrong_sequence''': Whether Profinet frames have been seen with problems in sequence. For loss the count of lost frames is calculated.
* '''geolocation''': checks if a country is part of the connection
** '''Direction''': The direction of traffic
*** ''from'': Traffic is coming ''from the'' specified country
*** ''to'': Traffic is going ''to'' the specified country
*** ''any:'' The specified country is on either side of the connection, or on neither side if the inequality is selected.
* '''gps_sync_status''': 0 means that the GPS clock in not synchronized, 1 means that the GPS clock is synchronized.
* '''handshake_failed''': Whether TCP handshake failed, i.e. one packet of SYN, SYN-ACK, ACK sequence is missing. If no handshake is seen at all but data (e.g. Allegro was started in the middle of a connection), no incident is generated.
* '''handshake_time''': The TCP handshake time between the first SYN packet and the ACK packet for the SYN/ACK packet of the server.
** '''client_handshake_time''': The TCP handshake time between the SYN/ACK packet of the server and the ACK packet of the client.
** '''server_handshake_time''': The TCP handshake time between the first SYN packet of the client and the SYN/ACK packet of the server.
* '''interface_speed''': The current speed of the interface in Mbit/s.
* '''interface_status''': 0 means interface is down, 1 means interface is up.
* '''jitter''':
** ''SIP: Call end'': The average jitter of the call, using the maximum value of both call sides.
** ''RTP: Traffic for RTP connections'': The average jitter of the RTP connection for the given timespan, using the maximum value of both directions.
* '''l4_protocol''': The layer 4 protocol. Can be TCP, UDP or other.
* '''l7_protocol''': The layer 7 protocol short name. Can also be a list, e.g. "HTTP, SSH, DHCP"
* '''local_ip''': Whether the IP is local (10/8, 172.16/12, 192.168/16, 169.254/16, fe80::/10, fc00::/7)
* '''link_speed_difference''': This is the absolute difference between the speeds of both interface of a link in Mbit/s.
* '''mac_count''': The number of different MAC addresses for the corresponding IP address.
* '''max_jitter''': The max jitter value for a Profinet device in % in a given timespan.
* '''mos''': The average MOS quality value of the call, using the minimum of both call sides.
* '''new_connections''': The amount of newly created connections (TCP and UDP) for the given timespan.
* '''not_in_order''': Count of not in order packets for IEC104 connection. The sequence number could be too high, too low or repeated.
* '''packet_rate''': The packet rate in packets per second on average during the configured timespan.
* '''packet_rate_increase''': The packet rate increase in % during the configured timespan compared to the average packet rate of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''percent_loss''':
** ''SIP: Call end'': The percentage of RTP packet loss for the call, accounting packets from both directions.
** ''RTP: Traffic for RTP connections'': The percentage of RTP packet loss for the given timespan, accounting packets from both directions of the RTP connection.
** ''IEC104: Traffic for IEC104 connections'': The percentage of IEC104 packet loss for the given timespan, accounting packets from both directions of the IEC104 connection.
* '''percent_transmissions''': The amount of TCP retransmission as a percentage of the total bytes.
* '''port_range''': The TCP or UDP port. Can be also a range, e.g. 80,443,8443-8445
* '''pppoe_discovery_packets''': The number of PPPoE discovery packets seen during the configured timespan.
* '''response_time''': The response time of IEC104 ACT requests and ACTCON replies.
* '''retransmission_ratio''': The TCP retransmission ratio seen in the configured timespan.
* '''since_start_time''':
** ''MAC: New L7 protocol'': This is the number of seconds after packet processing start when a new Layer-7 protocol for the MAC address appeared.
** ''MAC: New MAC address'': This is the number of seconds after packet processing start when the MAC address appeared. This is useful to only report new MAC address after some learning time.
** ''IP: New local IP address'': This is the number of seconds after packet processing start when the IP address appeared. This is useful to only report new IP address after some learning time.
** ''IP: New local L7 protocol'': This is the number of seconds after packet processing start when the Layer-7 protocol for the IP address appeared.
** ''Global: Connection start'': This is the number of seconds after packet processing start when the connection hast been started. This is useful to only report new connections after some learning time.
* '''status''': The call status code (a three digit number, like 200 for Success)
* '''tcp_handshake_time''': The TCP handshake time.
* '''tcp_fin_packets''': The number of TCP FIN packets (RX + TX) seen in the configured timespan.
* '''tcp_rst_packets''': The number of TCP RST packets (RX + TX) seen in the configured timespan.
* '''tcp_syn_packets''': The number of TCP SYN packets (RX + TX) seen in the configured timespan.
* '''throughput''': The throughput bandwidth in bit/s on average during the configured timespan.
* '''throughput_increase''': The throughput bandwidth increase in % during the configured timespan compared to the average throughput of the given baseline timespan. The noise can be configured to allow deviations that should not lead to trigger the incident.
* '''time_offset''': The time offset between the local time and the timestamp seen in the PTP packet.
* '''time_since_first_unanswered_request''': This is the time span between when the trigger is checked and the first DNS request that has not been answered by the DNS server.
* '''time_since_last_mac''': This is the number of seconds between changed MAC addresses. If, for examples, dynamic IP assignment is used, changing MAC addresses is normal so the test can be limited to only a certain amount of time.
* '''tls_alert_level''': The alert level of a TLS alert packet. Can be 'fatal', 'warning' or 'unknown'. A fatal alert will be sent if e.g. TLS handshake failed and connection shall be closed.
* '''total_bytes''':
** ''IP: Connection end'': The total number of bytes seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of bytes seen in the configured timespan.
** '''total_callee_bytes''': The number of bytes seen for the callee of the call.
** '''total_caller_bytes''': The number of bytes seen for the caller of the call.
* '''total_packets''':
** ''IP: Connection end'': The total number of packets seen for both directions of the flow.
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of packets seen in the configured timespan.
** '''total_callee_packets''': The number of packets seen for the callee of the call.
** '''total_caller_packets''': The number of packets seen for the caller of the call.
* '''ttl_change''': Whether TTL or hop limit has changed.
* '''type''': The type of PPPoE discovery packet (PADI, PADO, PADR, PADS, PADT or any).
* '''used_size''': The percentage of the ring buffer that needs to be filled.
* '''used_tls_version''': The TLS version (SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3)
* '''window_below_mss''': Whether the smallest announced TCP window was below the TCP MSS value. An additional offset is available, to check whether window was smaller than MSS + x bytes.
* '''zero_window_packets''': The number of packets with a TCP window of 0 for both directions of the flow.
* '''zero_window_packets''': The number of zero window packets seen in the configured timespan.

=== Capture settings ===
It is possible to automatically capture traffic for occurred incidents. These global settings control where capture files are stored and the capturing itself can be enabled for each rule separately.

The incident capture feature requires an active packet ring buffer since the packets are extracted from the buffer at the end of the incident period.

Available settings:

* Capture cooldown period: For each rule a cooldown period prevents multiple captures from happening in fast succession. By default, new captures happen firstly after 5 seconds, but any other value of at least 1 second can be configured. The cooldown is applied to each rule separately, but for each individual rule it does not matter if the same or a different entity triggers an incident. The incident is still reported within the cooldown period, but no additional capture is started.
* Storage device: Select the storage device where the captures should be stored on.
* Storage directory: Enter the directory where capture files should be stored or leave empty to use the top level directory.
* Select packet ring buffer to capture from: if multiple ring buffer cluster are in use, you can select which ring buffer to use for extraction.
* Capture profile: A capture profile can be configured to apply packet truncation rules to the capture file. If unset, the complete packets are captured (if the ring buffer uses separate truncation rules, truncated packets might still be within the capture file).

== Time Profiles ==
Incident rules can be active configured to be active in configured time spans (time profiles).

Every time profile allows the user to define one or more time spans per day of the week in which a rule should be active. After saving the user is able select the time profile when editing the rule.

Notes: Overlapping time spans will be merged. The earliest a time span is allowed to start is 0 and the latest end is 24, minutes are not allowed. The rule is not active for a day if there is no time span defined for the day.

== Channel configuration ==
[[File:Incidents channels.png|thumb|600x600px|Channel configuration]]
Incidents can be reported on different channels. The configuration allows to add new channels so they can be selected in the rule configuration described above.

Each channel can be of type:

'''email''' Incidents will be sent to the email address configured in the [[Global settings]].

'''kafka''' The incidents are sent to a topic on the configured Apache Kafka server. The message is the same as for syslog.
* Bootstrap Server: hostname/ip:port of a Kafka Broker or multiple Brokers separated by comma
* Protocol: Plaintext (no authentication, no encryption), SASL Paintext (Plain authentication, no encryption), SASL SSL (Plain authentication, TLS/SSL encryption)
* Ignore TLS Certificate: Ignore the TLS Certificate of the Brokers (only SASL SSL)
* Username: Broker Login (only SASL)
* Password: Broker Login (only SASL)
* Topic: The name of the topic into which the Incidents are sent.

'''snmp_trap''' Incidents will be sent to the configured SNMP trap receiver. A MIB file with the Allegro Network Multimeter SNMP trap definitions is available for download in the channel configuration dialog.
* Version: Supported SNMP version of the trap receiver (SNMP v2c or SNMP v3)
* Trap receiver (manager) hostname/IP: The trap receiver hostname or IP address

''SNMP v2c'':
* Community name: SNMP community name expected by the trap receiver

''SNMP v3'':
* Authentication protocol: Protocol for authenticated messages (MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512)
* Authentication password: Pass phrase for authenticated messages
* Privacy protocol: Protocol for message encryption (AES, DES)
* Privacy password: Pass phrase for message encryption
* Security name: Security name for authenticated SNMP messages
* Security level: Security level for SNMP messages (noAuthNoPriv, authNoPriv, authPriv)
* Engine ID: Authoritative (security) engineID (hexadecimal number)

'''syslog''' Incidents will be sent to the configured syslog server via TCP on any TCP or UDP port.

[[File:Incidents add channel.png|thumb|alt=|none|Adding a new channel]]
Each channel also uses a minimum severity setting, so only incidents are reported which are of at least that severity.

Each channel can be configured to only handle incidents from live traffic or from replayed traffic.

Some incidents cannot be configured via rules and you can choose to get those incidents also via email by enabling the settings at the lower part of the settings page.

== Other settings ==

=== Interface burst incident ===
[[File:Incidents others.png|thumb|600x600px|Other incidents]]
Burst incidents with milli-second resolution can be generated when the interface throughput exceeds a configurable threshold. The incident contains a graph of traffic for that interface with some data points before and after the threshold has been exceeded depending on the measurement interval. A PCAP link for capturing from the packet ring buffer is shown. For further investigation of that incident, the button "Use as global time range" can be used to set the global range to the start and end of the incident graph (at least 5 seconds) so that all modules of the Allegro Network Multimeter show that time span.

The incident generation can be configured in the "Other settings" tab as follows:
* '''Report "throughput threshold exceeded" with severity''': report an incident with the selected severity level if the throughput of any network interface exceeded.
* '''Throughput threshold (Mbit/s)''': The threshold is configured in Mbit/s.
* '''How long throughput must be above threshold to generate incident (in milliseconds)''': The throughput must exceed the threshold for this duration in order to generate the incident. If set to zero (default) the incident is generated immediately after the threshold has been exceeded.
* '''Throughput cool-down period between two incidents in milliseconds''': Defines the time after an incident where no new incident is generated even if the threshold is exceeded. If this period is passed, throughput incidents could be generated again.
Since each burst incidents stores the high resolution traffic graph, this feature uses a significant amount of memory. The actual amount is shown below and also depends on the maximum number of incidents configured in the section below.

=== Generic incident settings ===
This section allows to modify generic settings regarding the incident feature:

* '''Maximum number of stored incidents''': This value defines how many incidents are stored before old incidents are removed. Increasing this value also increased the amount of memory reserved for this feature. The corresponding value for the active setting is shown below, changing the configuration value requires a restart of the packet processing to take affect.

== Occured incidents ==
This page shows up to the last incidents occurred on the system. The table can be filtered for specific severity levels, as well as for specific trigger sources by selecting the trigger from the drop down menu.
[[File:Incidents list filter.png|thumb|600x600px|Filter incidents by severity or trigger]]
The list can also be filtered for the subject of the incident.

Individual incidents can be viewed in detail by clicking on the subject. The details page shows detailed information including links to the relevant measurement page.

Incidents can be deleted individually by clicking on the delete button next to the incident, or all incidents can be deleted by clicking on the button on the top right of the page.

The number of incidents available in this view is limited by a configurable number (firmware <4.1 was limited to 1000), the configuration as available in the "Other settings" tab.

== Statistics about incident rules ==
[[File:Incidents stats.png|thumb|600x600px|Statistics about rules]]
This page shows graphs about how often each rule has been hit both in absolute numbers as well as relatively to how often the rule has been checked.

== Incident list per measurement modules ==
Since incidents are triggered by different measurement modules (as indicate by the prefix of the trigger name, like the mac or ip module), the list of incidents from that specific module can also be seen in the corresponding tab of the measurement module for quicker access. This per-module view only lists those incidents coming from that module, all other potential incidents are hidden and must be accessed in their corresponding module page, or in the global view in the "Generic -> Incident" menu.

== Limitations ==
Some technical limitations apply:

* continuously checked triggers like "IP traffic" are only evaluated if there was at least one packet in the corresponding time interval. Therefore, rules check for zero packet count or throughput will never match.

Public limited statistics

2024-03-11T10:55:48Z

Hartmut: /* General information */ Typo fixes

The public statistics access allows to see some selected, based statistics without the need to login.

For data privacy reasons, this feature must be enable first in the [[Remote access and export]] settings, and all data visible does not contain any user-related information. The available information are described below.

== General information ==
The start page /public contains a simple list of available statistics, described in detail below.

All URLs can be extended by the following two options to adjust the statistics:

* timespan: sets the amount of time displayed in graphs. It defaults to 1 minute.
** The value is either seconds, minutes or hours, depending on the suffix.
** Examples:
*** timespan=120 This selects 120 seconds or 2 minutes for the timespan.
*** timespan=60m This selects 60 minutes or 1 hour.
*** timespan=24h This selects 24 hours or 1 day.
* update: sets the number of seconds between data updates. It defaults to one update every second.
** Examples:
*** update=60 updates the data once per minute
List of available URLs:
{| class="wikitable"
|+
!URL
!content
|-
|/public
|Basic entry page
|-
|/public/interfaces
|Interface statistics
|-
|/public/voip
|Voice over IP statistics
|-
|/public/topiptraffic
|Top 10 amount of IP traffic
|}

== Interface statistics ==
The URL "/public/interfaces" shows the current throughput of each active interfaces.

For details, log in and go to [[Interface statistics]].

== VoIP statistics ==
The URL "/public/voip" shows the current throughput for SIP and RTP protocol, and the error codes for SIP requests.

To see more details, log in and go to [[SIP module]].

== Top IP traffic ==
The URL "/public/topiptraffic" shows two pie charts with the top amount of traffic in the last timespan. For data privacy reasons, only the amount is visible, not the actual IP addresses. To get detailed information, log in and go to [[IP module#Top IP statistics|IP module]].

Interactive graph features

2024-03-01T14:26:05Z

Hartmut: language improvements

The Allegro Network Multimeter uses a graphical representation of
the historic data in many places. Uses include packet and byte counter
over time for IP addresses, MAC addresses, individual connections,
peers, etc. Response time graphs are also used to display the response
times of different services such as HTTP, SSL, and others.

Those graphs can be interactively manipulated to make exploring
historic data easy. The following mouse commands are available:

* Left mouse click: zooms into the clicked position
* Mouse selection with left mouse button: zoom into selected interval
:[[File:Zoom-in.png|1000px|none]]
* Right mouse click: zooms out of the clicked position
:[[File:Zoom-out.png|1000px|none]]

'''Holding the Shift key allows more interactive features:'''

* Shift + left mouse click: zooms into the clicked position
* Shift + mouse wheel up: zooms into the clicked position
:[[File:Zoom-in+shift.png|1000px|none]]
* Shift + right mouse click: zooms out of the clicked position
* Shift + mouse wheel down: zooms out of the clicked position
:[[File:Zoom-out+shift.png|1000px|none]]
* Shift + mouse drag: move graph to dragged direction without zooming (also known as panning)
:[[File:Diagramm-Move-nach.png|1000px|none]]

These interactive features make it easier to explore past network
events in contrast to manually selecting a specific time frame via the
upper right control buttons.

The [[Back-in-Time_functionality|Back-in-Time functionality]] pages contains additional information about
restrictions of selecting a specific interval.

Each individual graph can also be viewed in a detailed view spanning
the whole window by clicking on the the magnifying glass icon on the
right hand side of the graph. This will open a window containing only
this graph. The detail level is also increased by a factor of 4 to
show more data points. All interactive features like selecting an
interval or dragging the graph are still available.

Beneath the magnifying glass icon there is also an icon which opens a
drop down menu containing additional information about the
graph. First, there is a help button to this manual entry for easier
access. Second, the graph stepping is shown which describes the time
difference between each data point. Depending on the zoom level and
the age of the data the stepping is chosen automatically. For older
data, the graph resolution is reduced to save memory and make data
available for a longer time but this also means the detail level is
reduced. The stepping gives a hint how detailed the information
are. If you zoom in but the stepping remains the same, it basically
means that there is no more detailed data available. If multiple data sources are drawn in a single graph (like multiple IP address graphs), the graph resolution might be different for each data row so the minimum and maximum graph resolution is shown in this case.

It is possible to modify the graph resolution in the [[Global_settings#Graph_detail_settings|Graph detail settings]].

== Additional graph settings ==

The drop down menu beneath the magnifying glass also contains entries
to change the graph style from four different styles:

* Filled: This is the default style which draws lines for each data set and fills the area underneath for better readability.
* Regular lines: This style uses just lines for each data set.
* Thick lines: This style draws thicker lines.
* Stacked: This style uses filled areas and stacks each data set on another.

The settings are stored per user and changing a setting for one graph changes the settings for all other graphs automatically.

Remote access and export

2024-02-27T15:28:52Z

Hartmut: /* SFTP */ Typo fixes

== Statistics Export ==

See [[Statistics Export via POST]] for details about exporting the measurement data via HTTP POST requests.
== Influx Export ==

See [[Statistics Export via InfluxDB]] for details about exporting the measurement data via InfluxDB.

== SSH port forwarding ==

This option allows to use an external SSH server as an proxy to access the device. Via port forwarding the client PC accesses the SSH proxy which forwards the traffic to the actual Allegro Network Multimeter. See [[Self-hosted_SSH_Proxy]] for detailed information how to set up such a server.

== Allegro Remote Service ==

The Allegro Remote Service is similar to the SSH Port Forwarding feature, but the SSH server is provided by Allegro Packets as a public service. Traffic through is proxy is still end-to-end encrypted via your SSL certificate so the data is only accessible to you.

See [[Using the Allegro Remote Service]] for detailed information.

== SNMP ==

See [[SNMP]] for details about SNMP support.

== Pcap export via SFTP ==

The '''Allegro Network Multimeter''' allows the export of captured pcaps via SFTP.
pcap files can be stored in an upload queue and be automatically uploaded to a remote host once a day.

This feature only works if a disk is attached to the device.

When ''PCAP Export via SFTP'' is enabled, a new checkbox ''Save to SFTP export directory'' is added to the capture dialogue. If checked, the pcap will be stored to a special upload directory.

In the configuration view, it is possible to see the files in the upload queue anddelete them or trigger an immediate upload.

SFTP export allows SFTP authentication via public key or via password. The public key is printed at the top of the configuration view. For public key authentication, the password field in the SFTP connection parameters can be left empty.

A "Test upload" button uploads a file '''allegro-upload-test.txt''' into the configured
target directory on the remote host.

Uploaded files are deleted from the storage device after successful upload.

The upload can also be triggered manually via the web frontend or an REST API call:
Method: POST
URL: /API/system/sftp-export
Payload: { uploadNow: true }
Uploads are executed sequentially so it is safe to call the API with already running uploads.

Limitation: There should be no running capture to the SFTP export as it would be uploaded incompletely.

== Public statistics ==
The option allows to enable a public access to some basic statistics, useful for basic system monitoring.

If enabled, the system can be accessed with the URL "/public".

The 'Notes' text-box can be used to set some text which is displayed at the top of each public statistics page.

Read [[Public limited statistics]] for details about the kind of information that are available under the public URL.

== Zabbix agent ==
This module allows to run a Zabbix agent on the Allegro Network Multimeter so that it can be easily monitored from a Zabbix server.

When enabled, the Zabbix agent will listen for connections on the default TCP port 10050.

By default any address can connect to the Zabbix agent but in the 'Allowed servers' field a commas-separated list of servers can be provided. This limits access to the Zabbix agent by only allowing connections from listed Zabbix servers.

A Zabbix template can be downloaded using the 'Allegro Zabbix template' link. When this template is imported on a Zabbix server it then can be used to quickly set up useful items and triggers for monitoring an Allegro Network Multimeter. This also includes several Allegro-specific items like the processing load and memory usage, the IP count, MAC count and connection count as well as the data storage duration.
==SFTP==
The storage can be accessed via SFTP.

The server is off by default and has to be turned on in 'Settings' > 'Remote access and Statistics Export' > 'SFTP Server'.

Authentication is possible via a SSH key or the same credentials as of the web interface.

Only the user with the role 'admin' or users with storage permissions are allowed to access the storage via SFTP.

The SSH key is configurable on a user basis in the user settings.

User Management

2024-02-27T14:12:08Z

Hartmut: /* Password Policy */ language improvements

The user management page allows managing users which can use the Allegro Network Multimeter. It is possible to:

* Create new local users or configure login via LDAP or TACACS+
* Edit user parameters
** Change the password
** Use two-factor authentication with time-based one-time password (TOTP) algorithm. When this option is enabled, a QR code is displayed that needs to be scanned by a TOTP generator (e.g. FreeOTP or Google Authenticator). The Allegro Network Multimeter and the TOTP generator will generate a one-time password independently which needs to be given at login. Both devices need to be time synchronized (e.g. via NTP).
** Modify user roles (and therefore permissions and restrictions)
** Adjust user session timeout/time out in minutes

* Disable users
: Disabled users are not able to login, but their settings are kept.

* Forget Third Party (LDAP or Tacacs+) users (since firmware version 4.1)
** This removes the user settings and Two Factor Authentication Settings from the Multimeter

* Delete users.

:Notes:
:* It is not possible to delete or disable the admin account.
:* It is not possible to delete or disable the currently logged in user.

== Roles before v4.2 ==
Multiple roles can be defined per user to allow different permissions.

Only users with the '''admin''' role can:

* change system settings
* manage users
* configure storage settings
* use webdav

Roles can be created or deleted (except for the '''admin''' role). A role may have several permissions. Permissions are categorized in live view, replay view and 4-eyes authorization. For each category there is a list of permissions that are granted by this role. E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.

Following pre defined roles exist:

* '''admin''': with version 4.1 the admin role became editable. Per default this role has all permissions without restrictions.

*'''users''': Users with this role can see all measurement data, but they are not able to change settings.
*'''capture''': Users with this role are able to start traffic captures.
*'''replay-user''': Users can only view measurement data from replay slots (replay of ring buffer or pcap files). The user cannot see live data.
*'''restart-analysis''': Users can restart already running ring buffer analyses, for example with different start and end time parameters. This is useful if the '''admin''' user wants to select which and when a ring buffer should be analyzed but still letting '''replay-user'''s to restart the analysis in case they want use a smaller time interval for faster/more detailed analysis.
*'''api-pcap-4-eyes-authorization''': This role requires an authorization for performing a PCAP from another user with the '''pcap''' permission in any of the three categories. In the PCAP dialog a dropdown field is displayed where the user needs to select the other user who should grant the capture. The other user will get a popup dialog for granting or denying the PCAP download.
*'''api-voip-4-eyes-authorization''': This role requires an authorization for accessing SIP or RTP statistics pages from another user with the '''sip''' or '''rtp''' (before the version 4.1 this was the voip permission) permissions in a category. On the page that requires authorization an indicator is displayed where the user needs to select the other user who should grant access to that page. The other user will get a popup dialog for granting or denying the access.

These roles can be combined. For example, a user with the '''replay-user''' and '''capture''' role can only see replay data and can capture traffic from this data, but they cannot capture live data.

== Permissions before v4.2 ==
Permissions are categorized in live view, replay view and 4-eyes authorization.

For each category there is a list of permissions that are granted by this role.

E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.

Following permissions exist:

* '''all''': All permissions are granted. This contains all other permissions mentioned below.
* '''pcap''': Captures and Webshark access is permitted.
* '''voip''': Access to SIP and RTP statistics is permitted. (With version 4.1 this was split into the permissions rtp and sip)
* '''other''': Access to everything else.
* '''restart-analysis''': Allows restarting ring buffer analysis
* '''pcap-analysis''': Allows starting and stopping a PCAP analysis.
With version 4.1 there is an additional permission setting restricting the capture functionality. To use this feature a restricting profile has to be set in the capture profile settings.

== Roles after v4.2 ==
Multiple roles can be defined per user to allow for different permissions and some restrictions.

Per default there are the following 5 roles which are meant to be combined, cannot be deleted but are all changeable:
{| class="wikitable"
|+
!Role
!Description
|-
|admin
|This role has all permissions and no restrictions per default. The admin user has this role by default.
|-
|user
|This role can see the traffic in any views but is not allowed to capture data or change settings.
|-
|replay-user
|This role is only able to see the traffic in the replay view (e.g. when analyzing a pcap).
|-
|capture
|This role is only allowed to capture traffic in any view.
|-
|restart-analysis
|This role is allowed to restart the processing in any view (e.g. restarting the processing of live traffic and restarting pcap-replays).
|}
Roles can be created or deleted (except for the '''default''' roles). A role may have several permissions.

== Permissions after v4.2 ==
Permissions are categorized in live view, replay view and 4-eyes authorization. For each category there is a list of permissions that are granted by this role. E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.

There are administrative permissions for the settings and other features (like the incidents) and traffic permissions for the measurement data.

=== Administrative Permissions ===
The administrative permissions are for different resources like the settings and other features like incidents, reports and more.

Users are able to do '''actions''' which are '''read''', '''update''' and '''delete'''. If the user is only allowed to '''read''', they can only see the active settings but cannot change them.

If they are allowed to '''update''', the user is allowed to update the setting (like changing the permissions of a user or creating a report) but are not allowed to delete.

With the '''delete''' action the user is also allowed to delete things.

The '''all''' action includes all three other actions.
{| class="wikitable"
|+
!Resource
!Description
|-
|administration
|Settings to restart the multimeter, processing or other settings which are in the administration menu.
|-
|analysis-profile-settings
|Settings for the analysis profiles.
|-
|analysis-settings
|Settings which control how you analyze traffic, like the global or module settings.
|-
|capture-profile-settings
|Settings for the capture profiles.
|-
|incidents
|Incidents and Incident settings.
|-
|ingress-filter
|Ingress filter settings.
|-
|multi-device
|Multi-Device Settings.
|-
|name-and-lookup
|Name and look-up settings which are under the settings menu, more info can be found here: [[Names and look-ups]].
|-
|remote-export-settings
|Remote access and export settings.
|-
|reports
|Reports and report settings.
|-
|storage
|Access to storage devices and saved files.
|-
|storage-settings
|Storage settings, like sftp server, activating disks etc.
|-
|system-events
|Access to and settings for the system events log
|-
|user-management
|User management settings which includes users, roles, active sessions etc.
|-
|vlg-settings
|Virtual link group settings. (Everyone is able to read names but more access can be limited here)
|-
|wifi-settings
|Settings for the wifi-module.
|}

=== Traffic Permissions ===
The traffic permissions are split into four different views: '''Live''', '''Replay''', '''Requires 4 eyes''' and '''Grants 4 eyes'''. The '''any''' view includes '''Live''' and '''Replay'''.

The Resources are '''traffic''' (which includes all traffic except SIP- and RTP-traffic), '''SIP'''-Traffic, '''RTP'''-Traffic, '''capture''' (for capturing live and replay traffic) and '''restart''' (for restarting the live traffic processing or the replay).

For '''SIP'''- and '''RTP'''-traffic and '''capturing''' traffic it is possible to require the approval of another person by checking the '''Requires 4 Eyes''' for that resource.

The user which approves the action needs to have the '''Grants 4 Eyes''' for the Resource.

There is an additional permission setting restricting the capture functionality.

To use this feature a restricting profile has to be set in the capture profile settings.

== Password Policy ==
With version 4.2 the tab '''Settings''' with the settings for Password Policies was added. By enabling this settings an additional check will be carried out, scoring the new password by complexity and requiring a score of at least 3 out of 4.

By declaring special words like the company- or team-name the scoring-algorithm will score passwords with these words worse.

== LDAP users ==
In the LDAP user tab, it is possible to define an LDAP or Active Directory source for user management. LDAP users are only an addition to the locally defined users. Locally defined users take precedence over LDAP users.

The values required depend on the setup of the LDAP server.

The user filter requires a '''%s''' as a placeholder for the username.

The group filter requires either '''%s''' as a placeholder for the username, or any '''${value}''' attribute of the user. The special value '''${DN}''' references the distinguished name of the user.

In the '''Allegro MM users group''' and '''Allegro MM admins group''', a comma-separated list of the common name of the groups is given. If the user is in any of the groups, they are allowed to log in. If the user is in one of the admins group, they are treated as an administrator.

At the moment, only the roles '''admin''' and '''user''' can be used for LDAP access.

Example for a simple LDAP setup involving only the username:

User filter : (uid=%s)
Group filter : (memberUid=%s)
User group : allegro-mm-users
Admin group : allegro-mm-admins

==== '''Active Directory''' ====
For Active Directory, the distinguished name ('${DN}') is used in the group filter:
User filter : (&(sAMAccountName=%s)(objectCategory=person)(objectClass=user)(!sAMAccountType=805306370)(!userAccountControl:1.2.840.113556.1.4.803:=2))
Group filter : (&(member=${DN})(objectClass=group))
User group : allegro-mm-users
Admin group : allegro-mm-admins
A more complex group filter, using pre-filtering groups for performance reasons in large directories with lots of groups:

Group filter : (&(member=${DN})(objectClass=group)(|(cn=allegro-mm-users)(cn=allegro-mm-admins)))

For recursive group membership resolution, the following group filter can be used (but might be slower):

Group filter : (&(member:1.2.840.113556.1.4.1941:=${DN})(objectClass=group)(|(cn=allegro-mm-users)(cn=allegro-mm-admins)))

Depending on the setup, it is also possible to filter groups by distinguished name:

Group filter : (&(member:1.2.840.113556.1.4.1941:=${DN})(objectClass=group)(|(distinguishedName:=CN=allegro-mm-users,OU=Groups,DC=example,DC=com)(distinguishedName:=CN=allegro-mm-admins,OU=Groups,DC=example,DC=com)))

== TACACS+ users ==
In the TACACS+ user tab, it is possible to define a TACACS+ server for user management. TACACS+ users are only an addition to the locally defined users. Locally defined users take precedence over TACACS+ users. If both TACACS+ and LDAP are configured, LDAP will be queried first.

The '''Authorization service name''' defines the TACACS+ service (defined on the TACACS+ server) which is queried in the authorization request.

The '''Authorization group key''' defines the attribute of the attribute-value pair (AVP) returned in the authroization request, which lists the groups of the user. Theses groups (as defined in the TACACS+ server) can be mapped to roles as defined by the Allegro Network Multimeter.

==== Example ====
Lets assume the TACACS+ server is configured to have a service '<nowiki/>''allegro''<nowiki/>'. For this service, it returns the groups of the user as attribute '<nowiki/>''groups''<nowiki/>'. The user groups defined on the TACACS+ server have the names '<nowiki/>''allegro-admins''<nowiki/>', '<nowiki/>''allegro-users''<nowiki/>' or '''allegro-replay''<nowiki/>'.

This would require the following settings on the Allegro Network Multimeter:

Authorization service name : allegro
Authorization group key : groups
Group mapping :
admin : allegro-admins
user : allegro-users
replay-user : allegro-replay

User Management

2024-02-27T14:10:06Z

Hartmut: /* Administrative Permissions */ typo fixes

The user management page allows managing users which can use the Allegro Network Multimeter. It is possible to:

* Create new local users or configure login via LDAP or TACACS+
* Edit user parameters
** Change the password
** Use two-factor authentication with time-based one-time password (TOTP) algorithm. When this option is enabled, a QR code is displayed that needs to be scanned by a TOTP generator (e.g. FreeOTP or Google Authenticator). The Allegro Network Multimeter and the TOTP generator will generate a one-time password independently which needs to be given at login. Both devices need to be time synchronized (e.g. via NTP).
** Modify user roles (and therefore permissions and restrictions)
** Adjust user session timeout/time out in minutes

* Disable users
: Disabled users are not able to login, but their settings are kept.

* Forget Third Party (LDAP or Tacacs+) users (since firmware version 4.1)
** This removes the user settings and Two Factor Authentication Settings from the Multimeter

* Delete users.

:Notes:
:* It is not possible to delete or disable the admin account.
:* It is not possible to delete or disable the currently logged in user.

== Roles before v4.2 ==
Multiple roles can be defined per user to allow different permissions.

Only users with the '''admin''' role can:

* change system settings
* manage users
* configure storage settings
* use webdav

Roles can be created or deleted (except for the '''admin''' role). A role may have several permissions. Permissions are categorized in live view, replay view and 4-eyes authorization. For each category there is a list of permissions that are granted by this role. E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.

Following pre defined roles exist:

* '''admin''': with version 4.1 the admin role became editable. Per default this role has all permissions without restrictions.

*'''users''': Users with this role can see all measurement data, but they are not able to change settings.
*'''capture''': Users with this role are able to start traffic captures.
*'''replay-user''': Users can only view measurement data from replay slots (replay of ring buffer or pcap files). The user cannot see live data.
*'''restart-analysis''': Users can restart already running ring buffer analyses, for example with different start and end time parameters. This is useful if the '''admin''' user wants to select which and when a ring buffer should be analyzed but still letting '''replay-user'''s to restart the analysis in case they want use a smaller time interval for faster/more detailed analysis.
*'''api-pcap-4-eyes-authorization''': This role requires an authorization for performing a PCAP from another user with the '''pcap''' permission in any of the three categories. In the PCAP dialog a dropdown field is displayed where the user needs to select the other user who should grant the capture. The other user will get a popup dialog for granting or denying the PCAP download.
*'''api-voip-4-eyes-authorization''': This role requires an authorization for accessing SIP or RTP statistics pages from another user with the '''sip''' or '''rtp''' (before the version 4.1 this was the voip permission) permissions in a category. On the page that requires authorization an indicator is displayed where the user needs to select the other user who should grant access to that page. The other user will get a popup dialog for granting or denying the access.

These roles can be combined. For example, a user with the '''replay-user''' and '''capture''' role can only see replay data and can capture traffic from this data, but they cannot capture live data.

== Permissions before v4.2 ==
Permissions are categorized in live view, replay view and 4-eyes authorization.

For each category there is a list of permissions that are granted by this role.

E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.

Following permissions exist:

* '''all''': All permissions are granted. This contains all other permissions mentioned below.
* '''pcap''': Captures and Webshark access is permitted.
* '''voip''': Access to SIP and RTP statistics is permitted. (With version 4.1 this was split into the permissions rtp and sip)
* '''other''': Access to everything else.
* '''restart-analysis''': Allows restarting ring buffer analysis
* '''pcap-analysis''': Allows starting and stopping a PCAP analysis.
With version 4.1 there is an additional permission setting restricting the capture functionality. To use this feature a restricting profile has to be set in the capture profile settings.

== Roles after v4.2 ==
Multiple roles can be defined per user to allow for different permissions and some restrictions.

Per default there are the following 5 roles which are meant to be combined, cannot be deleted but are all changeable:
{| class="wikitable"
|+
!Role
!Description
|-
|admin
|This role has all permissions and no restrictions per default. The admin user has this role by default.
|-
|user
|This role can see the traffic in any views but is not allowed to capture data or change settings.
|-
|replay-user
|This role is only able to see the traffic in the replay view (e.g. when analyzing a pcap).
|-
|capture
|This role is only allowed to capture traffic in any view.
|-
|restart-analysis
|This role is allowed to restart the processing in any view (e.g. restarting the processing of live traffic and restarting pcap-replays).
|}
Roles can be created or deleted (except for the '''default''' roles). A role may have several permissions.

== Permissions after v4.2 ==
Permissions are categorized in live view, replay view and 4-eyes authorization. For each category there is a list of permissions that are granted by this role. E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.

There are administrative permissions for the settings and other features (like the incidents) and traffic permissions for the measurement data.

=== Administrative Permissions ===
The administrative permissions are for different resources like the settings and other features like incidents, reports and more.

Users are able to do '''actions''' which are '''read''', '''update''' and '''delete'''. If the user is only allowed to '''read''', they can only see the active settings but cannot change them.

If they are allowed to '''update''', the user is allowed to update the setting (like changing the permissions of a user or creating a report) but are not allowed to delete.

With the '''delete''' action the user is also allowed to delete things.

The '''all''' action includes all three other actions.
{| class="wikitable"
|+
!Resource
!Description
|-
|administration
|Settings to restart the multimeter, processing or other settings which are in the administration menu.
|-
|analysis-profile-settings
|Settings for the analysis profiles.
|-
|analysis-settings
|Settings which control how you analyze traffic, like the global or module settings.
|-
|capture-profile-settings
|Settings for the capture profiles.
|-
|incidents
|Incidents and Incident settings.
|-
|ingress-filter
|Ingress filter settings.
|-
|multi-device
|Multi-Device Settings.
|-
|name-and-lookup
|Name and look-up settings which are under the settings menu, more info can be found here: [[Names and look-ups]].
|-
|remote-export-settings
|Remote access and export settings.
|-
|reports
|Reports and report settings.
|-
|storage
|Access to storage devices and saved files.
|-
|storage-settings
|Storage settings, like sftp server, activating disks etc.
|-
|system-events
|Access to and settings for the system events log
|-
|user-management
|User management settings which includes users, roles, active sessions etc.
|-
|vlg-settings
|Virtual link group settings. (Everyone is able to read names but more access can be limited here)
|-
|wifi-settings
|Settings for the wifi-module.
|}

=== Traffic Permissions ===
The traffic permissions are split into four different views: '''Live''', '''Replay''', '''Requires 4 eyes''' and '''Grants 4 eyes'''. The '''any''' view includes '''Live''' and '''Replay'''.

The Resources are '''traffic''' (which includes all traffic except SIP- and RTP-traffic), '''SIP'''-Traffic, '''RTP'''-Traffic, '''capture''' (for capturing live and replay traffic) and '''restart''' (for restarting the live traffic processing or the replay).

For '''SIP'''- and '''RTP'''-traffic and '''capturing''' traffic it is possible to require the approval of another person by checking the '''Requires 4 Eyes''' for that resource.

The user which approves the action needs to have the '''Grants 4 Eyes''' for the Resource.

There is an additional permission setting restricting the capture functionality.

To use this feature a restricting profile has to be set in the capture profile settings.

== Password Policy ==
With version 4.2 The Tab '''Settings''' with the settings for Password Policies was added. By enabling this settings an additional check will be carried out, scoring the new password by complexity and requiring a score of 3 out of 4.

By declaring special words like the company- or team-name the scoring-algorithm will score passwords with these words worse.

== LDAP users ==
In the LDAP user tab, it is possible to define an LDAP or Active Directory source for user management. LDAP users are only an addition to the locally defined users. Locally defined users take precedence over LDAP users.

The values required depend on the setup of the LDAP server.

The user filter requires a '''%s''' as a placeholder for the username.

The group filter requires either '''%s''' as a placeholder for the username, or any '''${value}''' attribute of the user. The special value '''${DN}''' references the distinguished name of the user.

In the '''Allegro MM users group''' and '''Allegro MM admins group''', a comma-separated list of the common name of the groups is given. If the user is in any of the groups, they are allowed to log in. If the user is in one of the admins group, they are treated as an administrator.

At the moment, only the roles '''admin''' and '''user''' can be used for LDAP access.

Example for a simple LDAP setup involving only the username:

User filter : (uid=%s)
Group filter : (memberUid=%s)
User group : allegro-mm-users
Admin group : allegro-mm-admins

==== '''Active Directory''' ====
For Active Directory, the distinguished name ('${DN}') is used in the group filter:
User filter : (&(sAMAccountName=%s)(objectCategory=person)(objectClass=user)(!sAMAccountType=805306370)(!userAccountControl:1.2.840.113556.1.4.803:=2))
Group filter : (&(member=${DN})(objectClass=group))
User group : allegro-mm-users
Admin group : allegro-mm-admins
A more complex group filter, using pre-filtering groups for performance reasons in large directories with lots of groups:

Group filter : (&(member=${DN})(objectClass=group)(|(cn=allegro-mm-users)(cn=allegro-mm-admins)))

For recursive group membership resolution, the following group filter can be used (but might be slower):

Group filter : (&(member:1.2.840.113556.1.4.1941:=${DN})(objectClass=group)(|(cn=allegro-mm-users)(cn=allegro-mm-admins)))

Depending on the setup, it is also possible to filter groups by distinguished name:

Group filter : (&(member:1.2.840.113556.1.4.1941:=${DN})(objectClass=group)(|(distinguishedName:=CN=allegro-mm-users,OU=Groups,DC=example,DC=com)(distinguishedName:=CN=allegro-mm-admins,OU=Groups,DC=example,DC=com)))

== TACACS+ users ==
In the TACACS+ user tab, it is possible to define a TACACS+ server for user management. TACACS+ users are only an addition to the locally defined users. Locally defined users take precedence over TACACS+ users. If both TACACS+ and LDAP are configured, LDAP will be queried first.

The '''Authorization service name''' defines the TACACS+ service (defined on the TACACS+ server) which is queried in the authorization request.

The '''Authorization group key''' defines the attribute of the attribute-value pair (AVP) returned in the authroization request, which lists the groups of the user. Theses groups (as defined in the TACACS+ server) can be mapped to roles as defined by the Allegro Network Multimeter.

==== Example ====
Lets assume the TACACS+ server is configured to have a service '<nowiki/>''allegro''<nowiki/>'. For this service, it returns the groups of the user as attribute '<nowiki/>''groups''<nowiki/>'. The user groups defined on the TACACS+ server have the names '<nowiki/>''allegro-admins''<nowiki/>', '<nowiki/>''allegro-users''<nowiki/>' or '''allegro-replay''<nowiki/>'.

This would require the following settings on the Allegro Network Multimeter:

Authorization service name : allegro
Authorization group key : groups
Group mapping :
admin : allegro-admins
user : allegro-users
replay-user : allegro-replay

User Management

2024-02-27T13:59:43Z

Hartmut: /* Roles after v4.2 */

The user management page allows managing users which can use the Allegro Network Multimeter. It is possible to:

* Create new local users or configure login via LDAP or TACACS+
* Edit user parameters
** Change the password
** Use two-factor authentication with time-based one-time password (TOTP) algorithm. When this option is enabled, a QR code is displayed that needs to be scanned by a TOTP generator (e.g. FreeOTP or Google Authenticator). The Allegro Network Multimeter and the TOTP generator will generate a one-time password independently which needs to be given at login. Both devices need to be time synchronized (e.g. via NTP).
** Modify user roles (and therefore permissions and restrictions)
** Adjust user session timeout/time out in minutes

* Disable users
: Disabled users are not able to login, but their settings are kept.

* Forget Third Party (LDAP or Tacacs+) users (since firmware version 4.1)
** This removes the user settings and Two Factor Authentication Settings from the Multimeter

* Delete users.

:Notes:
:* It is not possible to delete or disable the admin account.
:* It is not possible to delete or disable the currently logged in user.

== Roles before v4.2 ==
Multiple roles can be defined per user to allow different permissions.

Only users with the '''admin''' role can:

* change system settings
* manage users
* configure storage settings
* use webdav

Roles can be created or deleted (except for the '''admin''' role). A role may have several permissions. Permissions are categorized in live view, replay view and 4-eyes authorization. For each category there is a list of permissions that are granted by this role. E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.

Following pre defined roles exist:

* '''admin''': with version 4.1 the admin role became editable. Per default this role has all permissions without restrictions.

*'''users''': Users with this role can see all measurement data, but they are not able to change settings.
*'''capture''': Users with this role are able to start traffic captures.
*'''replay-user''': Users can only view measurement data from replay slots (replay of ring buffer or pcap files). The user cannot see live data.
*'''restart-analysis''': Users can restart already running ring buffer analyses, for example with different start and end time parameters. This is useful if the '''admin''' user wants to select which and when a ring buffer should be analyzed but still letting '''replay-user'''s to restart the analysis in case they want use a smaller time interval for faster/more detailed analysis.
*'''api-pcap-4-eyes-authorization''': This role requires an authorization for performing a PCAP from another user with the '''pcap''' permission in any of the three categories. In the PCAP dialog a dropdown field is displayed where the user needs to select the other user who should grant the capture. The other user will get a popup dialog for granting or denying the PCAP download.
*'''api-voip-4-eyes-authorization''': This role requires an authorization for accessing SIP or RTP statistics pages from another user with the '''sip''' or '''rtp''' (before the version 4.1 this was the voip permission) permissions in a category. On the page that requires authorization an indicator is displayed where the user needs to select the other user who should grant access to that page. The other user will get a popup dialog for granting or denying the access.

These roles can be combined. For example, a user with the '''replay-user''' and '''capture''' role can only see replay data and can capture traffic from this data, but they cannot capture live data.

== Permissions before v4.2 ==
Permissions are categorized in live view, replay view and 4-eyes authorization.

For each category there is a list of permissions that are granted by this role.

E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.

Following permissions exist:

* '''all''': All permissions are granted. This contains all other permissions mentioned below.
* '''pcap''': Captures and Webshark access is permitted.
* '''voip''': Access to SIP and RTP statistics is permitted. (With version 4.1 this was split into the permissions rtp and sip)
* '''other''': Access to everything else.
* '''restart-analysis''': Allows restarting ring buffer analysis
* '''pcap-analysis''': Allows starting and stopping a PCAP analysis.
With version 4.1 there is an additional permission setting restricting the capture functionality. To use this feature a restricting profile has to be set in the capture profile settings.

== Roles after v4.2 ==
Multiple roles can be defined per user to allow for different permissions and some restrictions.

Per default there are the following 5 roles which are meant to be combined, cannot be deleted but are all changeable:
{| class="wikitable"
|+
!Role
!Description
|-
|admin
|This role has all permissions and no restrictions per default. The admin user has this role by default.
|-
|user
|This role can see the traffic in any views but is not allowed to capture data or change settings.
|-
|replay-user
|This role is only able to see the traffic in the replay view (e.g. when analyzing a pcap).
|-
|capture
|This role is only allowed to capture traffic in any view.
|-
|restart-analysis
|This role is allowed to restart the processing in any view (e.g. restarting the processing of live traffic and restarting pcap-replays).
|}
Roles can be created or deleted (except for the '''default''' roles). A role may have several permissions.

== Permissions after v4.2 ==
Permissions are categorized in live view, replay view and 4-eyes authorization. For each category there is a list of permissions that are granted by this role. E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.

There are administrative permissions for the settings and other features (like the incidents) and traffic permissions for the measurement data.

=== Administrative Permissions ===
The administrative permissions are for different resources like the settings and other features like incidents, reports and more.

User are able to do '''actions''' which are '''read''', '''update''' and '''delete'''. If the user is only allowed to '''read''', they can only see the active settings but cannot change them.

If they are allowed to '''update''', the user is allowed to update the setting (like changing the permissions of a user or creating a report) but are not allowed to delete.

With the '''delete''' action the user is also allowed to delete things.

The '''all''' action includes all three other actions.
{| class="wikitable"
|+
!Resource
!Description
|-
|administration
|Settings to restart the multimeter, processing or other settings which are in the administration menu.
|-
|analysis-profile-settins
|Settings for the analysis profiles.
|-
|analysis-settings
|Settings which control how you analyze traffic, like the global or module settings.
|-
|capture-profile-settings
|Settings for the capture profiles.
|-
|incidents
|Incidents and Incident settings.
|-
|ingress-filter
|Ingress filter settings.
|-
|multi-device
|Multi-Device Settings.
|-
|name-and-lookup
|Name and look-up settings which are under the settings menu, more info can be found here: [[Names and look-ups]].
|-
|remote-export-settings
|Remote access and export settings.
|-
|reports
|Reports and report settings.
|-
|storage
|Access to storage devices and saved files.
|-
|storage-settings
|Storage settings, like sftp server, activating disks etc.
|-
|system-events
|Access to and settings for the system events log
|-
|user-management
|User management settings which includes users, roles, active sessions etc.
|-
|vlg-settings
|Virtual link group settings. (Everyone is able to read names but more access can be limited here)
|-
|wifi-settings
|Settings for the wifi-module.
|}

=== Traffic Permissions ===
The traffic permissions are split into four different views: '''Live''', '''Replay''', '''Requires 4 eyes''' and '''Grants 4 eyes'''. The '''any''' view includes '''Live''' and '''Replay'''.

The Resources are '''traffic''' (which includes all traffic except SIP- and RTP-traffic), '''SIP'''-Traffic, '''RTP'''-Traffic, '''capture''' (for capturing live and replay traffic) and '''restart''' (for restarting the live traffic processing or the replay).

For '''SIP'''- and '''RTP'''-traffic and '''capturing''' traffic it is possible to require the approval of another person by checking the '''Requires 4 Eyes''' for that resource.

The user which approves the action has to has the '''Grants 4 Eyes''' for the Resource.

There is an additional permission setting restricting the capture functionality.

To use this feature a restricting profile has to be set in the capture profile settings.

== Password Policy ==
With version 4.2 The Tab '''Settings''' with the settings for Password Policies was added. By enabling this settings an additional check will be carried out, scoring the new password by complexity and requiring a score of 3 out of 4.

By declaring special words like the company- or team-name the scoring-algorithm will score passwords with these words worse.

== LDAP users ==
In the LDAP user tab, it is possible to define an LDAP or Active Directory source for user management. LDAP users are only an addition to the locally defined users. Locally defined users take precedence over LDAP users.

The values required depend on the setup of the LDAP server.

The user filter requires a '''%s''' as a placeholder for the username.

The group filter requires either '''%s''' as a placeholder for the username, or any '''${value}''' attribute of the user. The special value '''${DN}''' references the distinguished name of the user.

In the '''Allegro MM users group''' and '''Allegro MM admins group''', a comma-separated list of the common name of the groups is given. If the user is in any of the groups, they are allowed to log in. If the user is in one of the admins group, they are treated as an administrator.

At the moment, only the roles '''admin''' and '''user''' can be used for LDAP access.

Example for a simple LDAP setup involving only the username:

User filter : (uid=%s)
Group filter : (memberUid=%s)
User group : allegro-mm-users
Admin group : allegro-mm-admins

==== '''Active Directory''' ====
For Active Directory, the distinguished name ('${DN}') is used in the group filter:
User filter : (&(sAMAccountName=%s)(objectCategory=person)(objectClass=user)(!sAMAccountType=805306370)(!userAccountControl:1.2.840.113556.1.4.803:=2))
Group filter : (&(member=${DN})(objectClass=group))
User group : allegro-mm-users
Admin group : allegro-mm-admins
A more complex group filter, using pre-filtering groups for performance reasons in large directories with lots of groups:

Group filter : (&(member=${DN})(objectClass=group)(|(cn=allegro-mm-users)(cn=allegro-mm-admins)))

For recursive group membership resolution, the following group filter can be used (but might be slower):

Group filter : (&(member:1.2.840.113556.1.4.1941:=${DN})(objectClass=group)(|(cn=allegro-mm-users)(cn=allegro-mm-admins)))

Depending on the setup, it is also possible to filter groups by distinguished name:

Group filter : (&(member:1.2.840.113556.1.4.1941:=${DN})(objectClass=group)(|(distinguishedName:=CN=allegro-mm-users,OU=Groups,DC=example,DC=com)(distinguishedName:=CN=allegro-mm-admins,OU=Groups,DC=example,DC=com)))

== TACACS+ users ==
In the TACACS+ user tab, it is possible to define a TACACS+ server for user management. TACACS+ users are only an addition to the locally defined users. Locally defined users take precedence over TACACS+ users. If both TACACS+ and LDAP are configured, LDAP will be queried first.

The '''Authorization service name''' defines the TACACS+ service (defined on the TACACS+ server) which is queried in the authorization request.

The '''Authorization group key''' defines the attribute of the attribute-value pair (AVP) returned in the authroization request, which lists the groups of the user. Theses groups (as defined in the TACACS+ server) can be mapped to roles as defined by the Allegro Network Multimeter.

==== Example ====
Lets assume the TACACS+ server is configured to have a service '<nowiki/>''allegro''<nowiki/>'. For this service, it returns the groups of the user as attribute '<nowiki/>''groups''<nowiki/>'. The user groups defined on the TACACS+ server have the names '<nowiki/>''allegro-admins''<nowiki/>', '<nowiki/>''allegro-users''<nowiki/>' or '''allegro-replay''<nowiki/>'.

This would require the following settings on the Allegro Network Multimeter:

Authorization service name : allegro
Authorization group key : groups
Group mapping :
admin : allegro-admins
user : allegro-users
replay-user : allegro-replay

User Profile Settings

2024-02-27T13:34:05Z

Hartmut: clean-up and reordering

The user profile is accessible at the top right button.

The drop down menu allows to change the web site language, to log out, and to access the profile settings.

Each user can have different settings.

== User settings ==
The following user settings are available:

* Use offline manual: if enabled, the manual buttons will link to a local copy of this wiki manual.
* Detail level of displayed graphs: This option allows to configure the displayed graph details. Higher levels use more data points for plotting.
** Advantage: Graphs are more detailed, especially for longer time periods
** Disadvantages:
*** The web interfaces uses more bandwidth when updating the statistics.
*** The web browser uses more processing time for rendering the graphs.
** Note: This settings only affects the graph rendering in the web interface. The available number of data points depend on the settings for the [[Global settings#Graph detail settings|graph resolution]], and some other traffic related factors, like activity of an IP address. So the chosen detail level might not always be available.
** Additional bandwidth requirements for web interface in comparison to the lowest level:
*** level low: +50% data transferred
*** level medium: +100% data transferred
*** level high: +200% data transferred
*** level ultra: +300% data transferred
{| class="wikitable"
|+Example bandwidth usage for the initial dashboard:
!Detail level
!Top users dashboard data transfer
|-
|lowest
|350-400 kbit/s
|-
| low
|530-570 kbit/s
|-
| medium
|700-880 kbit/s
|-
| high
|1 MBit/s-1.4 MBit/s
|-
|ultra
|2 MBit/s
|}

=== Change password ===
The password of the current user can be changed by entering the current password and the new password.

=== Two Factor Authentication ===
Two-factor authentication with time-based one-time password (TOTP) algorithm can be used. When this option is enabled, a QR code is displayed that needs to be scanned by a TOTP generator (e.g. FreeOTP or Google Authenticator). The Allegro Network Multimeter and the TOTP generator will generate a one-time password independently which needs to be given at login. Both devices needs to be time synchronized (e.g. via NTP).

Starting from version 4.1 this is also possible for administrators and third-party accounts.

=== Permissions ===
Users are able to see their own permissions.

=== API Token ===
API Token can be created with either the same or less permissions than the user creating them has got.

These tokens can be used for accessing the API of the multi-device or for adding the device as Remote Multimeter in the [[Multi-device settings]].

=== SSH Keys ===
SSH Keys can be used to access the internal SFTP server of the multimeter.

=== Reset stored settings ===
Many context specific settings are stored in the user session automatically, such as filter expressions, number of elements per table page, etc. Those settings can be cleared by clicking on the corresponding button.

IEC61850 module

2024-02-19T14:57:23Z

Hartmut: Use screenshots of devices and connections

The IEC 61850 module shows information about communication protocols for intelligent electronic devices at electrical substations. These currently supported protocols are:

* GOOSE ('''G'''eneric '''O'''bject '''O'''riented '''S'''ubstation '''E'''vent)
* Sampled Values

The recognized data is transferred as payload of OSI-Layer 2 packets (optionally with VLAN tags). For GOOSE (in '''P'''rotocol '''D'''ata '''U'''nit - PDU) and Sampled Values (in '''A'''pplication '''S'''ervice '''D'''ata '''U'''nit - ASDU) data units, sequence counters are used to allow reordering the received packets and detecting lost packets.

== Overview ==

[[File:IEC61850 dashboard.png|thumb|IEC 61850 overview]]
Information about all recognized IEC 61850 packets are shown as values and graphs to give a quick overview. Global traffic can be shown in the traffic graph to see the share of each IEC 61850 protocol on the overall traffic.

For each of the protocols, measures of packets and data (accumulated and as per second rate), provide an impression of the used network capacity. Problems in the packet sequence are available as counters for expected packets (according to seen sequence numbers), lost packets (expected sequence number missing), repeated packets (sequence number seen multiple times). A PCAP download button allows capturing that traffic.

== Devices ==

[[File:IEC61850 devices.png|thumb|IEC 61850 devices]]
All devices sending or receiving IEC 61850 traffic are shown with their MAC address and the detected protocol. Besides packet counts and data rates of the protocol, quality measures like expected, lost and repeated data units/packets are shown. For having a quick overview, multiple graphs can be shown simultaneously for:

* general IEC 61850 traffic rate
* GOOSE packet rate rate
* Sampled Values data unit rate

The traffic for the specific device and protocol can be captured using the PCAP download button.

A complex filter for the shown row values can be used to limit the shown devices to the specific needs.

== Connections ==

[[File:IEC61850 connections.png|thumb|IEC 61850 connections]]
All connections containing IEC 61850 traffic are shown with their two communication partners' MAC address and the detected protocol. Besides packet counts, data rates and time of last detected activity, quality measures like expected, lost and repeated data units/packets are shown. For having a quick overview, multiple graphs can be shown simultaneously for:
*general IEC 61850 traffic rate
* GOOSE packet rate rate
* Sampled Values data unit rate

The traffic for the specific connection and protocol can be captured using the PCAP download button.

A complex filter for the shown row values can be used to limit the shown connections to the specific needs.

File:IEC61850 devices.png

2024-02-19T14:49:53Z

Hartmut:

File:IEC61850 connections.png

2024-02-19T14:47:33Z

Hartmut:

File:IEC61850 dashboard.png

2024-02-13T09:49:38Z

Hartmut: Hartmut uploaded a new version of File:IEC61850 dashboard.png

== Summary ==
IEC 61850 module overview page

IEC61850 module

2024-02-05T13:05:43Z

Hartmut: /* Overview */ add overview screenshot

The IEC 61850 module shows information about communication protocols for intelligent electronic devices at electrical substations. These currently supported protocols are:

* GOOSE ('''G'''eneric '''O'''bject '''O'''riented '''S'''ubstation '''E'''vent)
* Sampled Values

The recognized data is transferred as payload of OSI-Layer 2 packets (optionally with VLAN tags). For GOOSE (in '''P'''rotocol '''D'''ata '''U'''nit - PDU) and Sampled Values (in '''A'''pplication '''S'''ervice '''D'''ata '''U'''nit - ASDU) data units, sequence counters are used to allow reordering the received packets and detecting lost packets.

== Overview ==

[[File:IEC61850 dashboard.png|thumb|IEC 61850 overview]]
Information about all recognized IEC 61850 packets are shown as values and graphs to give a quick overview. Global traffic can be shown in the traffic graph to see the share of each IEC 61850 protocol on the overall traffic.

For each of the protocols, measures of packets and data (accumulated and as per second rate), provide an impression of the used network capacity. Problems in the packet sequence are available as counters for expected packets (according to seen sequence numbers), lost packets (expected sequence number missing), repeated packets (sequence number seen multiple times). A PCAP download button allows capturing that traffic.

== Devices ==
All devices sending or receiving IEC 61850 traffic are shown with their MAC address and the detected protocol. Besides packet counts and data rates of the protocol, quality measures like expected, lost and repeated data units/packets are shown. For having a quick overview, multiple graphs can be shown simultaneously for:

* general IEC 61850 traffic rate
* GOOSE packet rate rate
* Sampled Values data unit rate

The traffic for the specific device and protocol can be captured using the PCAP download button.

A complex filter for the shown row values can be used to limit the shown devices to the specific needs.

== Connections ==
All connections containing IEC 61850 traffic are shown with their two communication partners' MAC address and the detected protocol. Besides packet counts, data rates and time of last detected activity, quality measures like expected, lost and repeated data units/packets are shown. For having a quick overview, multiple graphs can be shown simultaneously for:
*general IEC 61850 traffic rate
* GOOSE packet rate rate
* Sampled Values data unit rate

The traffic for the specific connection and protocol can be captured using the PCAP download button.

A complex filter for the shown row values can be used to limit the shown connections to the specific needs.

File:IEC61850 dashboard.png

2024-02-05T13:02:45Z

Hartmut: IEC 61850 module overview page

== Summary ==
IEC 61850 module overview page

IEC61850 module

2024-02-05T12:59:13Z

Hartmut: Connections tab description

The IEC 61850 module shows information about communication protocols for intelligent electronic devices at electrical substations. These currently supported protocols are:

* GOOSE ('''G'''eneric '''O'''bject '''O'''riented '''S'''ubstation '''E'''vent)
* Sampled Values

The recognized data is transferred as payload of OSI-Layer 2 packets (optionally with VLAN tags). For GOOSE (in '''P'''rotocol '''D'''ata '''U'''nit - PDU) and Sampled Values (in '''A'''pplication '''S'''ervice '''D'''ata '''U'''nit - ASDU) data units, sequence counters are used to allow reordering the received packets and detecting lost packets.

== Overview ==
Information about all recognized IEC 61850 packets are shown as values and graphs to give a quick overview. Global traffic can be shown in the traffic graph to see the share of each IEC 61850 protocol on the overall traffic.

For each of the protocols, measures of packets and data (accumulated and as per second rate), provide an impression of the used network capacity. Problems in the packet sequence are available as counters for expected packets (according to seen sequence numbers), lost packets (expected sequence number missing), repeated packets (sequence number seen multiple times). A PCAP download button allows capturing that traffic.

== Devices ==
All devices sending or receiving IEC 61850 traffic are shown with their MAC address and the detected protocol. Besides packet counts and data rates of the protocol, quality measures like expected, lost and repeated data units/packets are shown. For having a quick overview, multiple graphs can be shown simultaneously for:

* general IEC 61850 traffic rate
* GOOSE packet rate rate
* Sampled Values data unit rate

The traffic for the specific device and protocol can be captured using the PCAP download button.

A complex filter for the shown row values can be used to limit the shown devices to the specific needs.

== Connections ==
All connections containing IEC 61850 traffic are shown with their two communication partners' MAC address and the detected protocol. Besides packet counts, data rates and time of last detected activity, quality measures like expected, lost and repeated data units/packets are shown. For having a quick overview, multiple graphs can be shown simultaneously for:
*general IEC 61850 traffic rate
* GOOSE packet rate rate
* Sampled Values data unit rate

The traffic for the specific connection and protocol can be captured using the PCAP download button.

A complex filter for the shown row values can be used to limit the shown connections to the specific needs.

IEC61850 module

2024-01-31T17:20:49Z

Hartmut: Overview and Devices section text

GOOSE module

2024-01-31T15:10:23Z

Hartmut: Hartmut moved page GOOSE module to IEC61850 module: Module got renamed during development

#REDIRECT [[IEC61850 module]]

IEC61850 module

2024-01-31T15:10:23Z

Hartmut: Hartmut moved page GOOSE module to IEC61850 module: Module got renamed during development

The GOOSE module shows information about GOOSE ('''G'''eneric '''O'''bject '''O'''riented '''S'''ubstation '''E'''vent) traffic.

IEC61850 module

2023-12-15T11:14:35Z

Hartmut: Initial page

The GOOSE module shows information about GOOSE ('''G'''eneric '''O'''bject '''O'''riented '''S'''ubstation '''E'''vent) traffic.

File:Sip calls.png

2023-12-07T16:19:11Z

Hartmut: Hartmut uploaded a new version of File:Sip calls.png

Sip calls

File:Voip Call details screen.png

2023-12-07T16:16:15Z

Hartmut: Hartmut uploaded a new version of File:Voip Call details screen.png

Voip Call details screen

File:Voip Call analysis.png

2023-12-07T16:16:04Z

Hartmut: Hartmut uploaded a new version of File:Voip Call analysis.png

Voip Call analysis