https://allegro-packets.com/wiki/api.php?action=feedcontributions&user=Ralf&feedformat=atomAllegro Network Multimeter Manual - User contributions [en]2024-03-28T13:41:05ZUser contributionsMediaWiki 1.39.6https://allegro-packets.com/wiki/index.php?title=Path_measurement&diff=4717Path measurement2024-03-22T08:05:09Z<p>Ralf: </p>
<hr />
<div>== Path measurement ==<br />
<br />
The path measurement module allows to passively measure the packet loss and latency between two Allegro Network Multimeter installations. <br />
<br />
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. <br />
<br />
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. <br />
<br />
The time synchronization setting (e.g. NTP/PTP or OFF) should be the same on both devices for the best results.<br />
<br />
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.<br />
<br />
Two pcap capture files can be compared to do an offline path measurement with previously captured files in two different locations.<br />
<br />
=== Live analysis ===<br />
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).<br />
<br />
=== PCAP analysis ===<br />
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. <br />
<br />
== Overview ==<br />
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.<br />
<br />
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.<br />
<br />
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).<br />
== Configuration live measurement ==<br />
<br />
{|class="wikitable sortable" <br />
|- <br />
|[[File:Ap-mm-path-measurement-1.png|600px|none|right]]<br />
|}<br />
<br />
=== Settings ===<br />
<br />
* 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.<br />
Primary device settings:<br />
* 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'''.<br />
* '''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.<br />
<br />
The following '''Client device''' configuration section configures the access to the remote device:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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:<br />
*# 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.<br />
*# 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.<br />
<br />
Measurement settings:<br />
<br />
* '''Maximum packet delay''': This field describes the maximum amount of seconds to wait for packet information from the remote device.<br />
: 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.<br />
: 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.<br />
<br />
* '''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.<br />
<br />
* '''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.<br />
<br />
*'''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.<br />
* '''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.<br />
* '''Enable NAT mode''' (Firmware >= 4.3): This feature will enable support for Network-Address-Translation setup (typical for firewalls or internet uplink routers).<br />
** '''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.<br />
** '''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.<br />
** '''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.<br />
<br />
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'''.<br />
<br />
=== Parameters currently in use ===<br />
<br />
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.<br />
<br />
=== Required actions ===<br />
<br />
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.<br />
<br />
== Configuration PCAP measurement ==<br />
[[File:Path-measurement-pcap-settings.png|border|660x660px]]<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
The "Measurement settings" contains all settings from the live measurement plus three options only applicable in PCAP mode.<br />
<br />
* Virtual link group mode: Select to either use:<br />
** Use global VLG settings: Use the VLG configuration configured globally on this device.<br />
** 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.<br />
** Disable use of VLGs: Disable all VLG configurations and use one common view of all data.<br />
* 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.<br />
* 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.<br />
<br />
<u>IMPORTANT NOTE 1:</u> The configuration values for packet rate and packet delay can be adjusted to reflect the actual parameters of the given PCAP files. The values are in relation to packet time of the PCAP files, not real time. So the packet rate does not correlate with the actual processing speed (which might be higher or lower than the packet rate within the PCAP files). The packet rate should be adjusted if the debug value "Packets processed too early" is non-zero. The default packet delay is set to 1 second to reduce the amount of memory required but should be adjusted to the expected maximum delay within the PCAP recording.<br />
<br />
<u>IMPORTANT NOTE 2:</u> If time stamp adjustment is used, all time stamps from the client file are adjusted which affects the analysis, but also the capture of these packets. So when doing a capture from that client file data, the packet time stamps are no longer the original timestamps but adjusted by the configured time delta.<br />
<br />
== Measurement statistics ==<br />
<br />
{|class="wikitable sortable" <br />
|- <br />
|[[File:Ap-mm-path-measurement-2.png|600px|none|right]]<br />
|}<br />
<br />
=== Measurement ===<br />
The '''measurement''' tab show the real-time results of the ongoing measurement.<br />
At the top the current state of the measurement engine and the remote connection is shown. <br />
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.<br />
The '''remote client status''' indicates if the connection to the remote device is established. <br />
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. <br />
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. <br />
If the reconnect fails, an error message appears with detailed information what was going wrong.<br />
<br />
''' Typical errors are:'''<br />
*remote device inaccessible (are the IP and port settings correct?)<br />
* authentication error (invalid credentials?) When both boxes are green, the measurement is running and the four graphs show the real-time results.<br />
* 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)<br />
<br />
==== Two-Way-Latency ====<br />
<br />
The first graph shows the latency measured from the main device to the remote device and back. <br />
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.<br />
Example: Assume a packet A is seen from main to remote device and another packet B is seen from remote to main device.<br />
The time difference when packet A is seen on main and on remote device plus the time difference of packet B being seen on remote and main device is taken into account to determine the two-way latency. Packet A and packet B are does not need to be related in any way.<br />
If traffic is going only in one direction, the measurement will not show any time result (even though packet loss is still visible).<br />
For each second, the average, minimum, and maximum two-way-latency is accounted and shown the graph. <br />
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.<br />
<br />
==== One-Way-Latency ====<br />
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.<br />
<br />
==== Lost packets ====<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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:<br />
<br />
#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.<br />
#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.<br />
#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. <br />
<br />
==== Monitored packet rate ====<br />
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.<br />
<br />
==== NAT collision packet rate ====<br />
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.<br />
<br />
=== IP addresses ===<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Switching graph modes ====<br />
<br />
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.<br />
<br />
== Limitations ==<br />
<br />
There are some limitations about the path measurement:<br />
<br />
# 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.<br />
# The maximum supported packet size for the path measurement is currently 2048 bytes. Larger packets are truncated for the measurement.<br />
# 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.<br />
# 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.<br />
# (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.<br />
<br />
== Typical use cases==<br />
<br />
See [[Analyze connections between remote sites]] to get a detailed overview of use cases and device setup.<br />
<br />
== Debug information ==<br />
<br />
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.<br />
<br />
#'''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.<br />
#'''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.<br />
#'''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.<br />
#'''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.<br />
<br />
<br />
Possible problematic scenarios:<br />
<br />
* 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).<br />
<br />
* There is a device between main and client that changes ports and IP addresses (a NAT): <br />
<br />
You will notice almost zero values for counter 1 and 2, but high values for counter 3 and 4.<br />
<br />
<br />
Both scenarios are not supported by the path measurement. <br />
<br />
Please adjust the test setup to disable any device modifying the network as described above.<br />
<br />
<br />
The table below shows the following counters for the main and remote device:<br />
<br />
#The counter about packets seen on all devices measures the total amount of packets monitored and considered for the analysis.<br />
#The packets seen only on one devices indicates how much packets are lost on the other devices.<br />
#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.<br />
#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. <br />
# 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.<br />
#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.<br />
#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.<br />
<br />
<br />
Below the table, two graphs showing time drift information are visible. <br />
The first graph shows the '''packet delay'''. It is the time between a matching packet from the main device and the client. <br />
This value describes for how long the main device needed to wait to get a matching packet from the client. <br />
This value should always be much lower than the maximum packet delay configured in the path measurement configuration. <br />
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:<br />
<br />
#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.<br />
#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.<br />
<br />
<br />
In this case try to use an alternative network connection to connect to the client device.<br />
<br />
The second graph shows the time drift between the main device and client device. <br />
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. <br />
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.<br />
<br />
== FAQ ==<br />
# What does the note '''Network setup problem detected: Packet modification or complete loss''' means?<br />
#: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.<br />
#: 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.<br />
#: 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.<br />
# What does the note '''VLAN tag mismatch detected for matching packets on main device and client''' means?<br />
#: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.<br />
#: Often, the recommended solution is to enable the configuration option '''Ignore VLAN tags for connection matching'''.<br />
# What kind of packet information is used to determine latency and packet loss?<br />
#: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.<br />
# What can I do if I think the packet loss is wrong?<br />
#: 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.<br />
#: 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.<br />
# How can I distinguish between real packet loss and reported packet loss due to packet modifications?<br />
#: 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<br />
## Actual loss<br />
##: 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.<br />
## Packet modification<br />
##: 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.<br />
## Overloaded management connection<br />
##: 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.<br />
##: 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.<br />
## Temporary network failure<br />
##: 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.<br />
# How is the two-way latency calculated?<br />
#: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.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Path_measurement&diff=4716Path measurement2024-03-20T14:16:40Z<p>Ralf: </p>
<hr />
<div>== Path measurement ==<br />
<br />
The path measurement module allows to passively measure the packet loss and latency between two Allegro Network Multimeter installations. <br />
<br />
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. <br />
<br />
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. <br />
<br />
The time synchronization setting (e.g. NTP/PTP or OFF) should be the same on both devices for the best results.<br />
<br />
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.<br />
<br />
Two pcap capture files can be compared to do an offline path measurement with previously captured files in two different locations.<br />
<br />
=== Live analysis ===<br />
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).<br />
<br />
=== PCAP analysis ===<br />
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. <br />
<br />
== Overview ==<br />
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.<br />
<br />
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.<br />
<br />
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).<br />
== Configuration live measurement ==<br />
<br />
{|class="wikitable sortable" <br />
|- <br />
|[[File:Ap-mm-path-measurement-1.png|600px|none|right]]<br />
|}<br />
<br />
=== Settings ===<br />
<br />
* 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.<br />
Primary device settings:<br />
* 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'''.<br />
* '''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.<br />
<br />
The following '''Client device''' configuration section configures the access to the remote device:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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:<br />
*# 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.<br />
*# 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.<br />
<br />
Measurement settings:<br />
<br />
* '''Maximum packet delay''': This field describes the maximum amount of seconds to wait for packet information from the remote device.<br />
: 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.<br />
: 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.<br />
<br />
* '''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.<br />
<br />
* '''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.<br />
<br />
*'''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.<br />
* '''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.<br />
* '''Enable NAT mode''' (Firmware >= 4.3): This feature will enable support for Network-Address-Translation setup (typical for firewalls or internet uplink routers).<br />
** '''Internal NAT subnet/mask:''' This value describes the internal IP addresses that gets translated into an external IP address.<br />
** '''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).<br />
** '''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.<br />
<br />
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'''.<br />
<br />
=== Parameters currently in use ===<br />
<br />
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.<br />
<br />
=== Required actions ===<br />
<br />
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.<br />
<br />
== Configuration PCAP measurement ==<br />
[[File:Path-measurement-pcap-settings.png|border|660x660px]]<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
The "Measurement settings" contains all settings from the live measurement plus three options only applicable in PCAP mode.<br />
<br />
* Virtual link group mode: Select to either use:<br />
** Use global VLG settings: Use the VLG configuration configured globally on this device.<br />
** 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.<br />
** Disable use of VLGs: Disable all VLG configurations and use one common view of all data.<br />
* 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.<br />
* 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.<br />
<br />
<u>IMPORTANT NOTE 1:</u> The configuration values for packet rate and packet delay can be adjusted to reflect the actual parameters of the given PCAP files. The values are in relation to packet time of the PCAP files, not real time. So the packet rate does not correlate with the actual processing speed (which might be higher or lower than the packet rate within the PCAP files). The packet rate should be adjusted if the debug value "Packets processed too early" is non-zero. The default packet delay is set to 1 second to reduce the amount of memory required but should be adjusted to the expected maximum delay within the PCAP recording.<br />
<br />
<u>IMPORTANT NOTE 2:</u> If time stamp adjustment is used, all time stamps from the client file are adjusted which affects the analysis, but also the capture of these packets. So when doing a capture from that client file data, the packet time stamps are no longer the original timestamps but adjusted by the configured time delta.<br />
<br />
== Measurement statistics ==<br />
<br />
{|class="wikitable sortable" <br />
|- <br />
|[[File:Ap-mm-path-measurement-2.png|600px|none|right]]<br />
|}<br />
<br />
=== Measurement ===<br />
The '''measurement''' tab show the real-time results of the ongoing measurement.<br />
At the top the current state of the measurement engine and the remote connection is shown. <br />
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.<br />
The '''remote client status''' indicates if the connection to the remote device is established. <br />
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. <br />
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. <br />
If the reconnect fails, an error message appears with detailed information what was going wrong.<br />
<br />
''' Typical errors are:'''<br />
*remote device inaccessible (are the IP and port settings correct?)<br />
* authentication error (invalid credentials?) When both boxes are green, the measurement is running and the four graphs show the real-time results.<br />
* 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)<br />
<br />
==== Two-Way-Latency ====<br />
<br />
The first graph shows the latency measured from the main device to the remote device and back. <br />
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.<br />
Example: Assume a packet A is seen from main to remote device and another packet B is seen from remote to main device.<br />
The time difference when packet A is seen on main and on remote device plus the time difference of packet B being seen on remote and main device is taken into account to determine the two-way latency. Packet A and packet B are does not need to be related in any way.<br />
If traffic is going only in one direction, the measurement will not show any time result (even though packet loss is still visible).<br />
For each second, the average, minimum, and maximum two-way-latency is accounted and shown the graph. <br />
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.<br />
<br />
==== One-Way-Latency ====<br />
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.<br />
<br />
==== Lost packets ====<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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:<br />
<br />
#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.<br />
#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.<br />
#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. <br />
<br />
==== Monitored packet rate ====<br />
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.<br />
<br />
==== NAT collision packet rate ====<br />
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.<br />
<br />
=== IP addresses ===<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Switching graph modes ====<br />
<br />
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.<br />
<br />
== Limitations ==<br />
<br />
There are some limitations about the path measurement:<br />
<br />
# 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.<br />
# The maximum supported packet size for the path measurement is currently 2048 bytes. Larger packets are truncated for the measurement.<br />
# 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.<br />
# 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.<br />
# (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.<br />
<br />
== Typical use cases==<br />
<br />
See [[Analyze connections between remote sites]] to get a detailed overview of use cases and device setup.<br />
<br />
== Debug information ==<br />
<br />
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.<br />
<br />
#'''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.<br />
#'''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.<br />
#'''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.<br />
#'''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.<br />
<br />
<br />
Possible problematic scenarios:<br />
<br />
* 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).<br />
<br />
* There is a device between main and client that changes ports and IP addresses (a NAT): <br />
<br />
You will notice almost zero values for counter 1 and 2, but high values for counter 3 and 4.<br />
<br />
<br />
Both scenarios are not supported by the path measurement. <br />
<br />
Please adjust the test setup to disable any device modifying the network as described above.<br />
<br />
<br />
The table below shows the following counters for the main and remote device:<br />
<br />
#The counter about packets seen on all devices measures the total amount of packets monitored and considered for the analysis.<br />
#The packets seen only on one devices indicates how much packets are lost on the other devices.<br />
#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.<br />
#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. <br />
# 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.<br />
#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.<br />
#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.<br />
<br />
<br />
Below the table, two graphs showing time drift information are visible. <br />
The first graph shows the '''packet delay'''. It is the time between a matching packet from the main device and the client. <br />
This value describes for how long the main device needed to wait to get a matching packet from the client. <br />
This value should always be much lower than the maximum packet delay configured in the path measurement configuration. <br />
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:<br />
<br />
#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.<br />
#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.<br />
<br />
<br />
In this case try to use an alternative network connection to connect to the client device.<br />
<br />
The second graph shows the time drift between the main device and client device. <br />
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. <br />
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.<br />
<br />
== FAQ ==<br />
# What does the note '''Network setup problem detected: Packet modification or complete loss''' means?<br />
#: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.<br />
#: 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.<br />
#: 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.<br />
# What does the note '''VLAN tag mismatch detected for matching packets on main device and client''' means?<br />
#: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.<br />
#: Often, the recommended solution is to enable the configuration option '''Ignore VLAN tags for connection matching'''.<br />
# What kind of packet information is used to determine latency and packet loss?<br />
#: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.<br />
# What can I do if I think the packet loss is wrong?<br />
#: 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.<br />
#: 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.<br />
# How can I distinguish between real packet loss and reported packet loss due to packet modifications?<br />
#: 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<br />
## Actual loss<br />
##: 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.<br />
## Packet modification<br />
##: 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.<br />
## Overloaded management connection<br />
##: 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.<br />
##: 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.<br />
## Temporary network failure<br />
##: 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.<br />
# How is the two-way latency calculated?<br />
#: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.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Path_measurement&diff=4715Path measurement2024-03-20T14:05:22Z<p>Ralf: </p>
<hr />
<div>== Path measurement ==<br />
<br />
The path measurement module allows to passively measure the packet loss and latency between two Allegro Network Multimeter installations. <br />
<br />
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. <br />
<br />
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. <br />
<br />
The time synchronization setting (e.g. NTP/PTP or OFF) should be the same on both devices for the best results.<br />
<br />
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.<br />
<br />
Two pcap capture files can be compared to do an offline path measurement with previously captured files in two different locations.<br />
<br />
=== Live analysis ===<br />
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).<br />
<br />
=== PCAP analysis ===<br />
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. <br />
<br />
== Overview ==<br />
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.<br />
<br />
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.<br />
<br />
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).<br />
== Configuration live measurement ==<br />
<br />
{|class="wikitable sortable" <br />
|- <br />
|[[File:Ap-mm-path-measurement-1.png|600px|none|right]]<br />
|}<br />
<br />
=== Settings ===<br />
<br />
* 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.<br />
Primary device settings:<br />
* 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'''.<br />
* '''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.<br />
<br />
The following '''Client device''' configuration section configures the access to the remote device:<br />
<br />
* '''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.<br />
* '''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.<br />
* '''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:<br />
*# 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.<br />
*# 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.<br />
<br />
Measurement settings:<br />
<br />
* '''Maximum packet delay''': This field describes the maximum amount of seconds to wait for packet information from the remote device.<br />
: 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.<br />
: 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.<br />
<br />
* '''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.<br />
<br />
* '''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.<br />
<br />
*'''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.<br />
* '''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.<br />
<br />
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'''.<br />
<br />
=== Parameters currently in use ===<br />
<br />
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.<br />
<br />
=== Required actions ===<br />
<br />
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.<br />
<br />
== Configuration PCAP measurement ==<br />
[[File:Path-measurement-pcap-settings.png|border|660x660px]]<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
The "Measurement settings" contains all settings from the live measurement plus three options only applicable in PCAP mode.<br />
<br />
* Virtual link group mode: Select to either use:<br />
** Use global VLG settings: Use the VLG configuration configured globally on this device.<br />
** 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.<br />
** Disable use of VLGs: Disable all VLG configurations and use one common view of all data.<br />
* 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.<br />
* 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.<br />
<br />
<u>IMPORTANT NOTE 1:</u> The configuration values for packet rate and packet delay can be adjusted to reflect the actual parameters of the given PCAP files. The values are in relation to packet time of the PCAP files, not real time. So the packet rate does not correlate with the actual processing speed (which might be higher or lower than the packet rate within the PCAP files). The packet rate should be adjusted if the debug value "Packets processed too early" is non-zero. The default packet delay is set to 1 second to reduce the amount of memory required but should be adjusted to the expected maximum delay within the PCAP recording.<br />
<br />
<u>IMPORTANT NOTE 2:</u> If time stamp adjustment is used, all time stamps from the client file are adjusted which affects the analysis, but also the capture of these packets. So when doing a capture from that client file data, the packet time stamps are no longer the original timestamps but adjusted by the configured time delta.<br />
<br />
== Measurement statistics ==<br />
<br />
{|class="wikitable sortable" <br />
|- <br />
|[[File:Ap-mm-path-measurement-2.png|600px|none|right]]<br />
|}<br />
<br />
=== Measurement ===<br />
The '''measurement''' tab show the real-time results of the ongoing measurement.<br />
At the top the current state of the measurement engine and the remote connection is shown. <br />
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.<br />
The '''remote client status''' indicates if the connection to the remote device is established. <br />
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. <br />
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. <br />
If the reconnect fails, an error message appears with detailed information what was going wrong.<br />
<br />
''' Typical errors are:'''<br />
*remote device inaccessible (are the IP and port settings correct?)<br />
* authentication error (invalid credentials?) When both boxes are green, the measurement is running and the four graphs show the real-time results.<br />
* 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)<br />
<br />
==== Two-Way-Latency ====<br />
<br />
The first graph shows the latency measured from the main device to the remote device and back. <br />
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.<br />
Example: Assume a packet A is seen from main to remote device and another packet B is seen from remote to main device.<br />
The time difference when packet A is seen on main and on remote device plus the time difference of packet B being seen on remote and main device is taken into account to determine the two-way latency. Packet A and packet B are does not need to be related in any way.<br />
If traffic is going only in one direction, the measurement will not show any time result (even though packet loss is still visible).<br />
For each second, the average, minimum, and maximum two-way-latency is accounted and shown the graph. <br />
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.<br />
<br />
==== One-Way-Latency ====<br />
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.<br />
<br />
==== Lost packets ====<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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:<br />
<br />
#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.<br />
#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.<br />
#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. <br />
<br />
==== Monitored packet rate ====<br />
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.<br />
<br />
=== IP addresses ===<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== Switching graph modes ====<br />
<br />
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.<br />
<br />
== Limitations ==<br />
<br />
There are some limitations about the path measurement:<br />
<br />
# 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.<br />
# The maximum supported packet size for the path measurement is currently 2048 bytes. Larger packets are truncated for the measurement.<br />
# 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.<br />
# 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.<br />
# 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.<br />
<br />
== Typical use cases==<br />
<br />
See [[Analyze connections between remote sites]] to get a detailed overview of use cases and device setup.<br />
<br />
== Debug information ==<br />
<br />
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.<br />
<br />
#'''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.<br />
#'''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.<br />
#'''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.<br />
#'''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.<br />
<br />
<br />
Possible problematic scenarios:<br />
<br />
* 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).<br />
<br />
* There is a device between main and client that changes ports and IP addresses (a NAT): <br />
<br />
You will notice almost zero values for counter 1 and 2, but high values for counter 3 and 4.<br />
<br />
<br />
Both scenarios are not supported by the path measurement. <br />
<br />
Please adjust the test setup to disable any device modifying the network as described above.<br />
<br />
<br />
The table below shows the following counters for the main and remote device:<br />
<br />
#The counter about packets seen on all devices measures the total amount of packets monitored and considered for the analysis.<br />
#The packets seen only on one devices indicates how much packets are lost on the other devices.<br />
#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.<br />
#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. <br />
# 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.<br />
#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.<br />
<br />
<br />
Below the table, two graphs showing time drift information are visible. <br />
The first graph shows the '''packet delay'''. It is the time between a matching packet from the main device and the client. <br />
This value describes for how long the main device needed to wait to get a matching packet from the client. <br />
This value should always be much lower than the maximum packet delay configured in the path measurement configuration. <br />
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:<br />
<br />
#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.<br />
#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.<br />
<br />
<br />
In this case try to use an alternative network connection to connect to the client device.<br />
<br />
The second graph shows the time drift between the main device and client device. <br />
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. <br />
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.<br />
<br />
== FAQ ==<br />
# What does the note '''Network setup problem detected: Packet modification or complete loss''' means?<br />
#: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.<br />
#: 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.<br />
#: 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.<br />
# What does the note '''VLAN tag mismatch detected for matching packets on main device and client''' means?<br />
#: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.<br />
#: Often, the recommended solution is to enable the configuration option '''Ignore VLAN tags for connection matching'''.<br />
# What kind of packet information is used to determine latency and packet loss?<br />
#: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.<br />
# What can I do if I think the packet loss is wrong?<br />
#: 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.<br />
#: 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.<br />
# How can I distinguish between real packet loss and reported packet loss due to packet modifications?<br />
#: 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<br />
## Actual loss<br />
##: 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.<br />
## Packet modification<br />
##: 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.<br />
## Overloaded management connection<br />
##: 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.<br />
##: 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.<br />
## Temporary network failure<br />
##: 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.<br />
# How is the two-way latency calculated?<br />
#: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.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=List_of_Supported_Transceiver_Modules&diff=4677List of Supported Transceiver Modules2024-02-16T12:49:59Z<p>Ralf: </p>
<hr />
<div>== DISCLAIMER ==<br />
<br />
Allegro Packets allows you to use third-party vendor modules in its appliances but guarantees only warranty and support for transceiver modules sold by Allegro Packets. Any malfunction or configuration issue with third-party modules are NOT covered by the warranty.<br />
<br />
Allegro Packets does not restrict the use of third-party SFP+ modules for the devices. However, some hardware limitations apply which are described as follows:<br />
<br />
== Built-in ports vs. expansion cards ==<br />
<br />
The Allegro Network Multimeter 800/1000/1200/3000/3200/x310/x410 series have two on-board SFP+ ports which are restricted to original or branded '''Intel modules'''.<br />
<br />
All non built-in ports are '''not''' vendor locked and can accept all transceiver modules. However, there are modules that do not work because of specific vendor extensions within the modules. This applies for all ports of the Allegro Network Multimeter x300, x310, x400, x410, x500 and x510 series and all expansion cards for the Allegro Network Multimeter 1000/1200/3000/3200.<br />
<br />
The following table shows which kind of modules are supported by Allegro by<br />
port type:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Port type !!original or branded Intel modules !! non-Intel branded modules <br />
|- <br />
| built-in SFP+ ports || x || -<br />
|-<br />
| SFP+ expansion|| x || x<br />
|-<br />
| SFP28 expansion|| x || x<br />
|-<br />
| QSFP expansion|| x|| x<br />
|-<br />
| QSFP28 expansion|| x || x<br />
|-<br />
|}<br />
<br />
The use of Intel branded modules is mandatory for the built-in SFP+ ports. These restrictions do not apply to the additional network expansion cards (2 port and 4 port SFP+, high precision GPS card, etc.) that are available for the Allegro Network Multimeter 1000 and 3000 series. These ports accept generic modules from a wide range of vendors.<br />
<br />
Since auto-negotiation is often not available on 1G/10G SFP+ interfaces, it may be necessary to manually set the correct speed in the `Interface Stats` section of the user interface.<br />
<br />
QSFP+ breakout cables are NOT supported.<br />
<br />
== List of tested third-party modules ==<br />
<br />
The following list of modules have been either tested by Allegro Packets or customers and have been reported to operate. Please be aware that this can change due new module revisions. <br />
<br />
{| class="wikitable"<br />
|-<br />
! Optics/Copper Module !! Transceiver P/N !! Media Type <br />
!Connector<br />
!Speed!! Remarks<br />
|-<br />
|SFP<br />
|Flexoptix T.C12.02.A<br />
|Copper<br />
| RJ45<br />
|10/100/1000M<br />
|requires Intel branding<br />
|-<br />
|SFP<br />
|Finisar FCLF8521P2BTL<br />
|Copper<br />
|RJ45<br />
|10/100/1000M<br />
|not supported in builtin ports in model 1000/1200/3000/3200, only in expansion slots, <br />
|-<br />
|SFP<br />
|Flexoptix S.1312.10.D<br />
|Fiber (LR)<br />
|LC<br />
|1G<br />
|not supported in onboard Allegro 1000/1200/3000/3200 SFP+ ports<br />
supported in Allegro 800 and any SFP+ expansion card<br />
|-<br />
|SFP<br />
|Flexoptix S.8512.02.D<br />
|Fiber (SR)<br />
|LC<br />
|1G<br />
|not supported in onboard Allegro 1000/1200/3000/3200 SFP+ ports<br />
supported in Allegro 800 and any SFP+ expansion card<br />
|-<br />
|SFP<br />
|Flexoptix S.B1312.10.DL<br />
Flexoptix S.B1512.10.DL<br />
|Fiber (LR, BiDi)<br />
|LC<br />
|1G<br />
|not supported in onboard Allegro 1000/1200/3000/3200 SFP+ ports<br />
<br />
supported in Allegro 800 and any SFP+ expansion card<br />
<br />
requires Intel branding<br />
|-<br />
| SFP+ || Intel E10GSFPSR || Fiber (SR)<br />
| <br />
|1G/10G|| <br />
|-<br />
| SFP+ || Intel E10GSFPLR || Fiber (LR)<br />
| <br />
|1G/10G|| <br />
|-<br />
| SFP+ || Intel XDACBL1M, XDACBL3M or XDACBL5M|| DA(Copper, Passive)<br />
| -<br />
| 10G<br />
|<br />
|-<br />
| SFP+ || Flexoptix P.8596.02 || Fiber (SR)<br />
|LC<br />
|1G/10G|| requires Intel branding<br />
|-<br />
| SFP+ || Flexoptix P.1396.10 || Fiber (LR)<br />
|LC<br />
|1G/10G|| requires Intel branding<br />
|-<br />
| SFP+ || fs.com 36431 || Fiber (SR)<br />
|LC<br />
|10G|| requires Intel branding, supports only 10G operation, 1G does NOT work<br />
|-<br />
| SFP+ || fs.com 36432 || Fiber (LR)<br />
|LC<br />
|10G|| requires Intel branding, supports only 10G operation, 1G does NOT work<br />
|-<br />
| SFP28 || Flexoptix P.8525G.01 || Fiber (SR)<br />
|LC<br />
|25G|| recommended with Intel branding<br />
|-<br />
| SFP28 || Flexoptix P.1325G.10 || Fiber (LR)<br />
|LC<br />
|25G|| recommended with Intel branding<br />
|-<br />
| SFP28 || fs.com 68000 || Fiber (SR)<br />
|LC<br />
|25G|| requires Intel branding<br />
|-<br />
| QSFP+ || Flexoptix Q.8540G.02 || Fiber (SR4)<br />
|MPO<br />
|40G|| recommended with Intel branding<br />
|-<br />
| QSFP+ || Flexoptix Q.1640G.10 || Fiber (LR4)<br />
|LC<br />
|40G|| recommended with Intel branding<br />
|-<br />
| QSFP+ || FINISAR FTL4C1QE1C || Fiber (LR4)<br />
| <br />
|40G||<br />
|-<br />
| QSFP+ || FINISAR FTL410QD2C || Fiber (SR4)<br />
| <br />
|40G||<br />
|-<br />
| QSFP+ || FINISAR FTL410QE1C || Fiber (SR4)<br />
| <br />
|40G||<br />
|-<br />
| QSFP+ || FINISAR FTL410QE2C || Fiber (SR4)<br />
| <br />
|40G||<br />
|-<br />
| QSFP+ || FINISAR FTL410QE3C || Fiber (SR4)<br />
| <br />
|40G||<br />
|-<br />
| QSFP+ || Amphenol 603020002, 603020005 || DA(Copper, Passive)<br />
| -<br />
|40G||<br />
|-<br />
| QSFP+ || fs.com 36281 || Fiber (SR4)<br />
|MPO<br />
|40G|| requires Intel branding<br />
|-<br />
| QSFP28 || Flexoptix Q.851HG.02 || Fiber (SR4)<br />
|MPO<br />
|100G||<br />
|-<br />
| QSFP28 || Flexoptix Q.161HG.10 || Fiber (LR4)<br />
|LC<br />
|100G||<br />
|-<br />
| QSFP28 || fs.com 75308 || Fiber (SR4)<br />
|MPO<br />
|100G|| <br />
|-<br />
| QSFP28 || Cisco QSFP-100G-CU (1M, 2M, 3M, 5M) || DA(Copper, Passive)<br />
| -<br />
|100G|| <br />
|-<br />
|QSFP28<br />
|QSFP28-100G-LR4-IX<br />
|Fiber (LR4)<br />
|LC<br />
|100G<br />
|only works in High-Speed-100G card (A-P-2xQSFP28H) due to power budget limit<br />
|}<br />
<br />
== Limited support ==<br />
{| class="wikitable"<br />
|-<br />
! Optics/Copper Module !! Transceiver P/N !! Media Type <br />
!Connector<br />
!Speed!! Remarks<br />
|-<br />
|QSFP28<br />
|QSFP28-100G-LR4-IX<br />
|Fiber (LR4)<br />
|LC<br />
|100G<br />
|only works in High-Speed-100G card (A-P-2xQSFP28H) due to power budget limit<br />
|-<br />
|QSFP+ 40G SR BG<br />
|Cisco qsfp-40g-sr-bg P/N: 191402<br />
|Fiber (SR4)<br />
|<br />
|40G<br />
|only partial support, modules must be (re-) inserted after power up<br />
|-<br />
|QSFP+ 40G SR4<br />
|Cisco qsfp-40g-sr4 P/N: 186602<br />
|Fiber (SR4)<br />
|<br />
|40G<br />
|only partial support, modules must be (re-) inserted after power up<br />
|-<br />
|QSFP+ 40G AOC<br />
|Cisco qsfp-h40g-aoc10m P/N: 187627<br />
|Fiber (SR)<br />
|<br />
|40G<br />
|only partial support, modules must be (re-) inserted after power up<br />
|}<br />
<br />
== Non-working modules ==<br />
<br />
Original Cisco modules have many issues working in the Allegro Network Multimeter. Allegro Packets got the feedback from multiple customers that they have issues with Cisco modules.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Optics/Copper Module !! Transceiver P/N !! Media Type !! Remarks<br />
|-<br />
| QSFP+ 40/100 SRBD || Cisco qsfp-40/100-srbd P/N: 199804 || Fiber (SR) || does '''NOT''' work<br />
|-<br />
| QSFP28 || Cisco QSFP-100G-SM-SR || Fiber (LR4 lite) || may work<br />
|-<br />
|QSFP28<br />
|Innolight QSFP28 MSA LR4 P/N: TR-FC13R-N00<br />
|Fiber (LR4)<br />
|does '''NOT''' work<br />
|}<br />
<br />
== Link status issues with different network equipment ==<br />
<br />
=== Problem: 1G link is not coming up with 1G/10G SFP+ fiber modules ===<br />
There is a known incompatibility with our 1G/10G SFP+ fiber modules when used with some Cisco equipment, such as a Cisco Nexus or Catalyst switch with 1G connectivity.<br />
<br />
The solution is as follows:<br />
<br />
* Disable auto-negotiation for the Cisco switch port which is connected to the Allegro device.<br />
* Manually set speed to 1G for the Cisco switch port<br />
<br />
Example configuration for Nexus:<br />
configure terminal<br />
interface ethernet x/yy<br />
speed 1000<br />
no negotiate auto<br />
Actual commands depends on the Cisco model. Alternative commands are:<br />
speed nonegotiates<br />
set port speed 1000<br />
Combinations known to work for 1G connectivity:<br />
<br />
* Our 1G/10G SFP+ SR module in an Allegro SFP port (article number 700)<br />
* Cisco GLC-SX-MMD in a Cisco switch<br />
* Cisco switch settings applied as described above</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Debugging_Skype_Traffic&diff=4650Debugging Skype Traffic2024-01-25T09:35:25Z<p>Ralf: </p>
<hr />
<div>This page describes how Microsoft Teams and Skype traffic can be analyzed with the '''Allegro Network Multimeter'''.<br />
<br />
== Microsoft Teams and Skype client protocols ==<br />
<br />
The Microsoft Teams and Skype clients rely on SSL for all control based traffic and RTP for all audio/video based traffic.<br />
<br />
The '''Allegro Network Multimeter''' allows you to search for traffic to the Microsoft cloud, helps to analyze the response time of the SSL encrypted control traffic and analyzes the RTP traffic for quality parameters like packet loss, jitter, etc.<br />
<br />
== Microsoft Teams and Skype control traffic ==<br />
<br />
Microsoft Teams and Skype control traffic is SSL encrypted. This does not allow for decoding and analysis of the control connection content. Since SSL uses TCP as the Layer 4 protocol, all of the TCP connection quality statistics can be used for debugging. Additionally, the response time for the SSL handshake and the first encrypted SSL data response time is available.<br />
<br />
The most important quality parameters are:<br />
<br />
* TCP handshake response time<br />
* TCP retransmission rates<br />
* TCP Zero Window times<br />
* SSL hello handshake response time<br />
* SSL first data response time<br />
<br />
Please read the [[TCP module]] and [[SSL module]] for more information on these and more counters.<br />
<br />
A simple way to see an overview of the response time for Microsoft Teams and Skype servers is the '''IP statistics''' table. You can use the free text search for "skype" and select the graph dialogue: "TCP response time". This will present you the top IP addresses with a correlated name to '''skype''' and their TCP response times. You can also enable the '''Timing''' columns to view and sort for response times.<br />
<br />
[[File:Skype response time.png|600px]]<br />
<br />
This graph shows you the TCP stack delay to confirm data reception. Note that many TCP stacks wait a few milliseconds if there is no data to respond to(see [[https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment Wikipedia TCP delayed acknowledgment]]). Any additional delay on top of this time (usually 40 ms) indicates a significant roundtrip time delay. If you have installed the Allegro Network Multimeter close to the Microsoft Teams or Skype client, it will be the roundtrip time of the TCP packets from your network to the Teams/Skype cloud.<br />
<br />
DNS names and IP address ranges for both Microsoft Teams and Skype are subject to change regularly, since the control servers in the Microsoft cloud use load balancing, which can point data to different servers. A current description for Skype for Business can be found here: [https://techcommunity.microsoft.com/t5/skype-for-business-blog/simplified-port-requirements-for-skype-for-business-online/ba-p/77094]<br />
<br />
The analysis can also be done for TCP retransmissions and TCP Zero Window statistics. If you have installed the Allegro Netwok Multimeter close to the Microsoft Teams or Skype client, this will indicate if the data sent to the Teams/Skype server required a retransmission on the WAN link or if the receiver buffer is full, indicating receiver overload.<br />
<br />
=== Teams IP and port ranges: ===<br />
See [https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges#skype-for-business-online-and-microsoft-teams Microsoft support document] for list of IP address ranges and ports used for different Microsoft services.<br />
<br />
== Microsoft Teams and Skype audio/video traffic ==<br />
<br />
The Microsoft Teams and Skype audio/video traffic is sent by encrypted RTP frames. As RTP encryption is applied only on the content and not on the RTP header, you can still debug the RTP traffic with the RTP decoder output of the Allegro Network Multimeter.<br />
<br />
To get an overview of which IPs have used RTP, you can use the '''Applications''' → '''RTP statistics''' page and search for Teams or Skype.<br />
<br />
[[File:Skype rtp statistics overview.png|1000px]]<br />
<br />
This allows you to see which IP address have used the protocol RTP. It shows an overview of the RTP packet loss and jitter based on RTP sequence numbers. To obtain detailed information about individual connections, click on the IP address. This will show RTP packet loss and jitter for each connection.<br />
<br />
[[File:Skype rtp statistics ip detailed.png|1000px]]</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Burst_analysis&diff=4649Burst analysis2024-01-22T08:32:55Z<p>Ralf: </p>
<hr />
<div>The burst analysis module measures throughput per interface or MAC address and displays utilization graphs for fast recognition of bursts.<br />
<br />
===Measurement===<br />
The burst analysis module measures throughput for every interface in a 1 ms interval. Measurement is always done on layer 1, the packet length accounting setting is ignored.<br />
<br />
=== Web interface ===<br />
{| class="wikitable sortable"<br />
|- <br />
|[[File:Burst analysis.png|800px|none|right]]<br />
|}<br />
<br />
The web interface shows a tab with an interface list. Additionally there is a tab with up to five MAC addresses that can be added and removed.<br />
For every interface or MAC address a graph is shown which displays utilization values. Utilization values are stacked on eachother and sum up 100%. <br />
A tooltip shows all utilization values for the desired time slot. <br />
In Live view mode a bar is shown per second, thus if e.g. the '''Utilization 100%''' value is at 3%, the link was completely busy for a total of 3% of the measurement intervals in that second. <br />
For back-in-time intervals or when a larger interval is displayed, the duration of a bar is longer and the utilization values are aggregated accordingly. <br />
The duration can be found out by clicking on the triangle icon next to the graph.<br />
The utilization values are counted exclusively. E.g. '''Utilization >= 99%''' shows the amount of time when the link had an utilization of greater or equal 99% but lesser than 100%. Those utilizations are counted seperately and shown as '''Utilization 100%'''.<br />
The sliders on top of the graphs allow for displaying or hiding several utilization values. These settings are stored per user.<br />
Together with the interface throughput incidents you can easily see when bursts occured and how long they lasted.<br />
<br />
=== Utilization 100% configuration ===<br />
Next to the graph the configured '''Utilization 100%''' threshold is shown and can be configured by clicking on the change link. <br />
<br />
For interfaces either the link speed or any other Mbit/s value can be used. For MAC addresses the tx and rx thresholds can be configured.<br />
<br />
The traffic’s bandwidth will be shown as '''Utilization >> 100%''' if it is larger than 105% of the configuration value.<br />
<br />
In case of PCAP analysis, the interface speed cannot set in advance since the interface numbers or not known and may differ from the interface of the device. Therefore, the [[Pcap analysis module#Analysis profiles|analysis profiles]] can be used to configure the interface speeds for each interface in the PCAP file or for all interfaces all together.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Pcap_analysis_module&diff=4648Pcap analysis module2024-01-22T08:29:18Z<p>Ralf: /* Analysis profiles */</p>
<hr />
<div>The pcap analysis module allows analyzing pcap files by sending them to the device. After analyzing the pcap, the web interface shows all the metadata as if the packets are live traffic at the time of the pcap recording.<br />
<br />
'''Web Interface'''<br />
<br />
{| class="wikitable"<br />
|-<br />
| <br />
[[File:Pcap.png|1000px|none]]<br />
|}<br />
<br />
====Notes====<br />
Starting pcap analyze will stop the network ports and thus the normal packet processing and forwarding is disabled. The network connections of the devices connected to the Allegro Network Multimeter will stop working.<br />
<br />
==== Start new Upload====<br />
To select a file to analyze, simply drag a file from your file manager to the drop zone. The second option is to click into the drop zone. After a click, a file selection dialog will open.<br />
After selecting a file, the name and the size of the pcap will be displayed in the drop zone box. <br />
<br />
To proceed, press the '''Upload and analyze pcap''' button. A modal dialog will open.<br />
<br />
* A warning will be shown if the device is in bridge mode, since no more packets will be forwarded when starting pcap analyze mode.<br />
* If a storage device is active, it is possible to buffer the packets on it. This allows simple extraction of packets as in live packet processing.<br />
<br />
The pcap file itself will not be stored on the storage of the Allegro Network Multimeter (except in the packet ring buffer, if activated in the upload modal dialog).<br />
<br />
==== Analysis profiles ====<br />
Profiles allow for some processing relevant settings to be changed on an per analysis level. If no analysis profile is selected those settings will be equal to the globally configured settings of the multimeter.<br />
[[File:Analysis profile selector.png|none|thumb|687x687px|Select an analysis profile for your pcap analysis]]<br />
<br />
Currently profiles influence the following settings:<br />
<br />
* [[Complex_filter|Complex ingress filter]]<br />
* [[Global_settings#Packet_length_accounting|Packet length accounting]]<br />
* [[Global_settings#Tunnel_view_mode|Tunnel view mode]]<br />
* [[Global_settings#VLAN_handling|VLAN handling]]<br />
* [[Global_settings#External_timestamps|External timestamps]]<br />
* [[Global_settings#Detail_of_traffic_analysis|Detail of traffic analysis]]<br />
* [[Global_settings#Graph_detail_settings|Graph detail settings]]<br />
* Interface speeds for [[Burst analysis]]<br />
Useres without admin privileges can not edit or create analysis profiles but can select and see which settings they change.<br />
[[File:Analysis profile view.png|none|thumb|418x418px|View analysis profile]]<br />
<br />
==== PCAP analysis statistics====<br />
After the upload started, a progress section will be displayed. This includes a progress bar and the time of the last<br />
processed packet. When viewing the progress bar on a different tab or on a different browser, the progress bar<br />
will not show the correct value.<br />
<br />
==== Viewing the pcap metadata====<br />
During and after the upload of the file, all modules will show the metadata produced by analyzing the packets in the pcap file.<br />
<br />
==== Resuming normal operation====<br />
After finishing the analysis, the processing can be set back to live mode by clicking the '''Resume normal operation''' button at the bottom of the page.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=REST_API_description&diff=4647REST API description2024-01-17T12:29:54Z<p>Ralf: </p>
<hr />
<div>This page describes how to access and use the REST API. It allows to post-process data with 3rd party systems. The Allegro Network Multimeter web interface is itself based on this REST API and all displayed statistics can be extracted from the Allegro Network Multimeter with this API.<br />
<br />
== General API Setup ==<br />
<br />
=== REST API Interface ===<br />
<br />
All Allegro Network Multimeter statistics are derived from HTTPS requests and provided as JSON objects.<br />
The requests are stateless, i.e. there are no prerequisites and there is no fixed sequence of requests necessary.<br />
Example requests related to a specific module and statistics can be seen in the web interface by opening the browser development console (Ctrl+Shift+I for Chrome and Firefox, F12 for Edge).<br />
<br />
Here an example of the structured JSON data for the IP overview. This data has been extracted with the Google Chrome developer console while accessing the IP statistics page.<br />
<br />
[[File:Rest api chrome console.png|800px]]<br />
<br />
=== Credentials === <br />
<br />
The credentials are the same as for the web interface. Users with the admin role are allowed to access all APIs per default. With version 4.1 the access can be configured/restricted in the role settings. A non-admin user has read access to most of the statistics. If you have enabled the pcap role, the capture URL is also possible for the API.<br />
<br />
Allegro Packets recommends to set up a separate non-admin user with or without the pcap role for the REST API of only statistics shall be gathered. This will prevent to accidentally shut down or change any configuration by calling the REST API.<br />
<br />
== Useful shell commands and their parameters ==<br />
<br />
=== Curl ===<br />
<br />
Most examples are written for curl [https://en.wikipedia.org/wiki/CURL]. Curl is available as for many operating systems like Linux or Windows. Curl needs a few parameters for the access of the Allegro Network Multimeter:<br />
<br />
The parameter '''-u''' allows you to set a user name and password for the request. <br />
<br />
The parameter '''-k''' will allow self-signed certificates.<br />
<br />
The parameter '''-s''' or '''--silent''' mutes any debugging output.<br />
<br />
The URL of the API call is the first argument. It is recommended to enclose the API call with the character ' to avoid replacing the argument ( unless you need to replace parts of it )<br />
<br />
<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm-XXXX/...'</pre><br />
<br />
Please note that you might need to use <code>curl.exe</code> in windows.<br />
<br />
=== PowerShell ===<br />
<br />
The Integrated Windows PowerShell can be used to access the REST API. This guide requires at least PowerShell v6.<br />
<br />
The command to call a REST API is '''Invoke-RestMethod''' [https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-restmethod].<br />
Invoke-RestMethod on the PowerShell needs a few parameters for the access of the Allegro Network Multimeter:<br />
<br />
To set the user name for basic authorization, use the '''-Headers''' parameter:<br />
<br />
<pre>-Headers @{Authorization = ("Basic {0}" -f [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f 'USER', 'PASSWORD'))))}</pre><br />
<br />
You also need to announce that you accept JSON as response with:<br />
<br />
<pre>-ContentType'application/json; charset=utf-8'</pre> <br />
<br />
To disable the certificate check, use:<br />
<br />
<pre>-SkipCertificateCheck</pre><br />
<br />
The URL must be passed with the parameter '''-Uri''', so the full command is:<br />
<br />
<pre>Invoke-RestMethod -Uri 'https://allegro-mm-XXXX/...' -Headers @{Authorization = ("Basic {0}" -f [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f 'USER', 'PASSWORD'))))} -ContentType'application/json; charset=utf-8' -Method 'Get' -SkipCertificateCheck</pre><br />
<br />
=== jq ===<br />
<br />
jq ([https://stedolan.github.io/jq/]) is a powerful tool to extract parameters from a json document. If called without parameters, jq formats the JSON output into a readable format with indenting and new lines. It also allows to select specific values and do basic operations like addition with this values.<br />
Please read the jq documentation for more information.<br />
<br />
== API hierarchy ==<br />
<br />
=== Query available URIs with OPTIONS ===<br />
<br />
The Allegro Network Multimeter REST API has the fixed URI <code>API/stats</code> for statistics. To see all possible subtrees of a specific request, use the '''OPTIONS''' request instead of '''GET'''. It can be set with the parameter <code>-X OPTIONS</code> for curl.<br />
<br />
<pre><br />
$ curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats' -X OPTIONS<br />
{<br />
"subResources": [<br />
"modules",<br />
"reports",<br />
"incidentReporting",<br />
"time",<br />
"ringBufferReplay",<br />
"pcap",<br />
"reset",<br />
"interfacesError",<br />
"interfaces",<br />
"load",<br />
"processing"<br />
]<br />
}<br />
</pre><br />
<br />
This allows you to query for example for all modules that are available for a specific release of the Allegro Network Multimeter:<br />
<br />
<pre><br />
$ curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules' -X OPTIONS<br />
{<br />
"subResources": [<br />
"pppoe",<br />
"lldp",<br />
"groups",<br />
"mpls",<br />
"opc_ua",<br />
"quality",<br />
"ipsec",<br />
"profinet",<br />
"multicast",<br />
"burst_analysis",<br />
"global_incidents",<br />
"ptp",<br />
"ntp",<br />
"icmp",<br />
"stp",<br />
"sip",<br />
"smb",<br />
"dpa",<br />
"l4_ports",<br />
"netbios",<br />
"crt",<br />
"dpi",<br />
"http",<br />
"ssl",<br />
"dns",<br />
"dhcp",<br />
"location",<br />
"qos",<br />
"ip",<br />
"mac_protocols",<br />
"vlan",<br />
"arp",<br />
"packet_size",<br />
"mac",<br />
"capture"<br />
]<br />
}<br />
</pre><br />
<br />
=== URI content parameters ===<br />
<br />
Some modules allow to use a parameter as part of the URI like the IP or Mac address. The path <code>API/stats/modules/ip/ips</code> allows you to use an IP address as next uri element<br />
<br />
<pre><br />
$ curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips' -X OPTIONS<br />
{<br />
"subResources": [<br />
"protocol",<br />
":ip"<br />
]<br />
}<br />
</pre><br />
<br />
The path of an IP address shows all further available elements:<br />
<br />
<pre><br />
$ curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips/10.0.54.254' -X OPTIONS<br />
{<br />
"subResources": [<br />
"sip_request_responses",<br />
"peers_ports",<br />
"sip_responses",<br />
"sip_requests",<br />
"qos",<br />
"ports",<br />
"connections",<br />
"protocols",<br />
"macs",<br />
"peers",<br />
"tcpStats"<br />
]<br />
}<br />
</pre><br />
<br />
== JSON output traffic counters ==<br />
<br />
All counters are aggregated counters, either for the selected time interval or since the processing start of the Allegro Network Multimeter. Many traffic counters have 4 separate values. These traffic counters are represented as a JSON array with at least 4 lines. The structure is as follows:<br />
* line 1: '''received packets''', extraction example: jq .lastSecond[0]<br />
* line 2: '''received bytes''', extraction example: jq .lastSecond[1]<br />
* line 3: '''transmitted packets''', extraction example: jq .lastSecond[2]<br />
* line 4: '''transmitted bytes''', extraction example: jq .lastSecond[3]<br />
* additional lines are module specific<br />
<br />
The following counters exist for many REST APIs like IP, MAC, l4 protocol, l7 protocol and many more:<br />
* '''interval''': Values of the selected time interval. If no interval is specified, this is similar to lastSecond.<br />
* '''allTime''': Values since start of the Allegro Network Multimeter.<br />
* '''lastSecond''': Values of the last second.<br />
* '''intervalPerSecond''': Average per second value of the selected time interval. If no interval is specified, this is similar to lastSecond.<br />
<br />
Please note that all counters are byte counters, not bit counters. You need to multiply the counters by 8 to get the bitrate.<br />
<br />
This example extracts the received bytes of the last second of a specific IP.<br />
<br />
<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips/10.1.2.3' | jq .lastSecond[1]</pre><br />
<br />
This example extracts received and transmitted bytes of the last second of a specific IP.<br />
<br />
<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips/10.1.2.3' | jq '.lastSecond[1] + .lastSecond[3]'</pre><br />
<br />
== API parameters ==<br />
<br />
The Allegro Network Multimeter REST API has a number of query parameters that can be added to modify the request. By default, the API will display the real time counters since the last restart of the processing unit.<br />
<br />
This example extracts the amount of received and transmitted bytes for an IP address since the processing start of the Allegro Network Multimeter. It queries via the REST API the JSON and then adds the values second value ( row 1, rx bytes ) and 4th value ( row 3, tx bytes ) of the interval counters together. <br />
<br />
<pre><br />
$ curl --silent -k -u USER:PASSWORD "https://allegro-mm/API/stats/modules/ip/ips/10.54.0.254" | jq '.interval[1] + .interval[3]'<br />
</pre><br />
<br />
=== Time interval selection ===<br />
<br />
Requests can be given a time interval. If present, the '''interval''' counters are adjusted to this interval. The following GET parameters are necessary:<br />
* '''starttime''', '''endtime''': Start and end time of the interval. Format: seconds since 1970/01/01 UTC (Unix time, epoch). You can use <code>date +%s</code> on your machine to adjust to the best interval. Please consult the man page of date for more parameters.<br />
* '''skiphistorydata''': shall the JSON include the history data without datasets, this reduces the amount of transferred bytes if datasets are required to render a graph, can be false/true default: false<br />
* '''timespan''': required resolution for the graph dataset<br />
<br />
This example extracts the amount of received and transmitted bytes for an IP address for the last 24 hours.<br />
<pre><br />
$ curl --silent -k -u USER:PASSWORD "https://allegro-mm/API/stats/modules/ip/ips/10.54.0.254?starttime=$(date --date="1 day ago" +%s)&endtime=$(date +%s)&skiphistorydata=true" | jq '.interval[1] + .interval[3]'<br />
</pre><br />
<br />
=== List queries ===<br />
<br />
List queries are requested with pagination parameters to reduce the size of the resulting JSON objects and to increase performance. In the resulting JSON object, the list elements are stored in the displayedItems array.<br />
The following list parameters are possible:<br />
<br />
* sort: Sorting criteria for the list. Following criteria's are supported for most lists:<br />
** bytes: Received and transmitted bytes (either in selected time interval or since start of the Allegro Network Multimeter).<br />
** rxbytes: Received bytes.<br />
** txbytes: Transmitted bytes.<br />
** bps: Received and transmitted bytes per second (either average per second value of the selected time interval or last second, if no interval is specified).<br />
** rxbps: Received bytes per second.<br />
** txbps: Transmitted bytes per second.<br />
* reverse: Sort ascending (= false) or descending (= true).<br />
* page: Requested page.<br />
* count: Amount of entries in the list. Maximum is 100.<br />
* values: Amount of maximal values in history object(s).<br />
<br />
This example shows IP address with the highest amount of traffic<br />
<br />
<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips_paged?sort=bps&reverse=true&page=0&count=1' | jq .displayedItems[0].ip</pre><br />
<br />
This example shows up to 9999 peers of a specific IP address:<br />
<br />
<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips/10.1.2.3/peers?sort=bytes&reverse=true&page=0&count=9999&timespan=60&values=100' | jq '.displayedItems[].ip'</pre><br />
<br />
=== Pcap extraction ===<br />
<br />
The Allegro Network Multimeter allows to extract the raw packets with the REST API with the special capture URI <code>/API/data/modules/capture</code><br />
<br />
<pre>curl -k -u USER:PASSWORD 'https://allegro-mm/API/data/modules/capture?expression=ip==10.1.2.3' > path_to/capture.pcap</pre><br />
<br />
The available parameters are:<br />
<br />
* '''startTime''': The start time of the capture. The first packet with exactly this or a later time will start the capture. The time format must be microseconds after January, 1st 1970 UTC (Unix time, epoch). If the start time is in the past, make sure you set fromCaptureBuffer parameter accordingly. If not specified, the current time will be used.<br />
* '''endTime''': The end time of the capture. The first packet with exactly this or a later time will stop the capture. The time format must be microseconds after January, 1st 1970 UTC (Unix time, epoch). If not specified, unlimited will be used. The end time can also be set to 'now', in this case the timespan parameter will be taken and the corresponding start time will be calculated.<br />
* '''timespan''': The time span in seconds. Will be used if no startTime but endTime with 'now' is set.<br />
* '''expression''': The filter expression. There are no whitespaces allowed. You may use ‘%20’ instead. See [[Capture module]] for available expressions.<br />
* '''snapPacketLength''': The maximum size of a packet applied on Layer 2 without frame check sequence. If a packet is larger than this value, it is truncated. Use 65535 for unlimited size.<br />
* '''fromCaptureBuffer''': Whether to extract data from the packet ring buffer (= true) or just live traffic (= false).<br />
* '''captureBufferSlotId''': In case a cluster packet ring buffer is used, the id of the ring buffer must be given. The id of the first ring buffer is 0. If this parameter is omitted, 0 will be taken as default value.<br />
* '''captureToMedia''': Whether to store a pcap on an external storage device (= true) or download to your computer (= false).<br />
* '''mm-id''': If you are extracting a Pcap from a parallel Pcap analysis job or a multi device connected Allegro Network Multimeter, you have to specify the device and the slot where to get the data from. The syntax is: <code>mm-id=<device name>:<slot id></code>. If the capture shall be performed on the local device, the device name can be omited (e.g. mm-id=:1 for the first replay slot on the local device).<br />
<br />
Example to capture everything from now on:<br />
<br />
<pre>curl -k -u USER:PASSWORD 'https://allegro-mm/API/data/modules/capture' > path_to/capture.pcap</pre><br />
<br />
Example to capture a specific IP of the last hour<br />
<br />
<pre>curl -k -u USER:PASSWORD "https://allegro-mm/API/data/modules/capture?expression=ip==10.1.2.3&starttime=$(($(date --date="1 hour ago" +%s%N)/1000))&endtime=$(($(date +%s%N)/1000))&fromCaptureBuffer=true" > path_to/capture.pcap</pre><br />
<br />
Example to capture a specific IP of a given time span of the first parallel Pcap analysis slot<br />
<br />
<pre>curl -k -u USER:PASSWORD "https://allegro-mm/API/data/modules/capture?expression=ip==10.1.2.3&starttime=$(($(date --date="2020-07-15 08:55:00" +%s%N)/1000))&endtime=$(($(date --date="2020-07-15 09:55:00" +%s%N)/1000))&fromCaptureBuffer=true&mm-id=:1" > path_to/capture.pcap</pre><br />
<br />
=== Pcap upload and analysis ===<br />
<br />
Pcap upload and analysis can also be done via API calls.<br />
<br />
The PCAP upload is split into 3 commands. First, the replay is being initialized. Then the analyzing is started. In the last step the PCAP is streamed to the Allegro Network Multimeter. Depending on the size of the PCAP the third step could take some time, but the Allegro Network Multimeter already allows access to the statistics of the already analyzed packets via web/API.<br />
<br />
The example assumes that PCAP parallel analysis is enabled in the global settings, so the PCAP analysis will be done in slot 1 and a dedicated ring buffer is available.<br />
<br />
<pre><br />
curl -k -u USER:PASSWORD "https://allegro-mm/API/system/replay/upload" --header "Content-Type: application/json" -d '{"fileName": "abc.pcapng", "fileSize": '$(stat -c %s abc.pcapng)', "replaySlotID": 1, "forceSlotID": true, "useReplayBuffer": true}'<br />
curl -k -u USER:PASSWORD "https://allegro-mm/API/data/pcap?mm-id=:1" --header "Content-Type: application/json" -d '{"command":"start"}'<br />
curl -F 'name=file' -F 'filename=abc.pcapng' -F 'file=@path_to/abc.pcapng' -k -u USER:PASSWORD "https://allegro-mm/API/system/analyze-pcap?replaySlotID=1"<br />
</pre><br />
<br />
=== Virtual Link Groups ===<br />
<br />
The Allegro Network Multimeter REST API allows to access all link groups by the parameter '''group'''. The group index starts at zero, which is the default value. If a virtual link group is enabled. <br />
<br />
This example extracts the traffic of the IP 10.54.0.254 from the second virtual link group ( index 1 ).<br />
<br />
<pre><br />
$ curl --silent -k -u USER:PASSWORD "https://allegro-mm/API/stats/modules/ip/ips/10.54.0.254?group=1" | jq '.interval[1] + .interval[3]'<br />
</pre><br />
<br />
=== Parallel pcap analysis ===<br />
<br />
The Allegro Network Multimeter can process in parallel offline traffic like a pcap file or a ring buffer. In case a parallel PCAP analysis is running, the API call must be given either the additional header field <code>"X-AllegroPackets-Multimeter-ID: :1"</code> or the parameter mm-id with the PCAP instance ID.<br />
<br />
This allows to extract information of automated pcap uploads.<br />
<br />
=== Multi-device analysis ===<br />
<br />
If the Allegro Network Multimeter is configured as a gateway for multiple Allegro devices by the [[Multi-device settings]], you need to add either the additional header field <code>"X-AllegroPackets-Multimeter-ID: hostname"</code> or the parameter mm-id where the hostname must be the same as configured in the multi-device settings.<br />
<br />
== REST API Examples ==<br />
<br />
==== MAC statistics ====<br />
<br />
Extract the packets per second statistic of the MAC broadcast address<br />
<br />
<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/mac/macs/ff:ff:ff:ff:ff:ff'</pre><br />
<br />
==== IP statistics ====<br />
<br />
<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm/API/stats/modules/ip/ips/10.1.2.3'</pre><br />
<br />
==== Pretty displaying JSON output with jq ====<br />
<br />
<pre>curl --silent -k -u USER:PASSWORD 'https://allegro-mm-XXXX/API/stats/modules/ip/ips/10.1.2.3' | jq</pre><br />
<br />
==== Capture a specific IP ====<br />
<br />
<pre>curl -k -u USER:PASSWORD 'https://allegro-mm-XXXX/API/data/modules/capture?expression=ip==10.1.2.3' > path_to/capture.pcap</pre><br />
<br />
==== Capture two IP addresses with ports on a specific Layer 4 protocol ====<br />
<br />
<pre>curl -k -u USER:PASSWORD 'https://allegro-mm-XXXX/API/data/modules/capture?expression=IP==10.1.2.3:62887 and IP==10.1.2.100:548 and l4Protocol==TCP' > path_to/capture.pcap</pre><br />
<br />
==== Output IP Table as CSV file ====<br />
<pre>curl -k -u USER:PASSWORD 'https://allegro-mm-XXXX/API/stats/modules/ip/ips_paged?csv=true' > path_to/file.csv</pre><br />
<br />
==== Output Connection Table as CSV file ====<br />
<pre>curl -k -u USER:PASSWORD 'https://allegro-mm-XXXX/API/stats/modules/ip/globalConnections/csv?csv=true' > path_to/file.csv</pre><br />
<br />
==== Multi-device Capture Python Script Example ====<br />
<br />
<pre><br />
#! /usr/bin/python3<br />
<br />
""" This example script starts a parallel download-capture for each 'multi-device' of a given allegro packets multimeter. """<br />
<br />
import requests<br />
import threading<br />
import datetime<br />
import shutil<br />
<br />
<br />
def start_capture_download(host: str, device: dict, duration: int):<br />
start = datetime.datetime.now()<br />
end = start + datetime.timedelta(seconds=duration)<br />
file = device["host"] + start.strftime("%m-%d-%Y_%H-%M-%S") + ".pcap"<br />
params = {<br />
"mm-id": device["id"],<br />
"endTime": int(end.timestamp() * 1000000),<br />
}<br />
<br />
with session.get(host + "/API/data/modules/capture", params=params, stream=True) as resp:<br />
with open(file, "wb") as fh:<br />
shutil.copyfileobj(resp.raw, fh)<br />
<br />
<br />
host = "https://allegro-mm-xxxx"<br />
session = requests.Session()<br />
session.auth = ("user", "password")<br />
# session.verify = False # disable ssl verification<br />
<br />
with session.get(host + "/API/system/multidevice/devices") as resp:<br />
devices = resp.json()<br />
<br />
active_devices = []<br />
for device in devices:<br />
if device["active"]:<br />
active_devices.append(device)<br />
<br />
threads = []<br />
for device in active_devices:<br />
t = threading.Thread(target=start_capture_download, args=(host, device, 30))<br />
t.start()<br />
threads.append(t)<br />
<br />
for t in threads:<br />
t.join()<br />
</pre><br />
<br />
==== Python Script Example - Top IPs ====<br />
<br />
<pre><br />
#! /usr/bin/python3<br />
<br />
import requests<br />
<br />
requests.packages.urllib3.disable_warnings()<br />
<br />
host = "https://allegro-mm-xxxx"<br />
session = requests.Session()<br />
session.auth = ("user", "password")<br />
session.verify = False # disable ssl verification<br />
<br />
params = {<br />
"sort": "bytes",<br />
"reverse": True,<br />
"page": 0,<br />
"count": 10,<br />
"timespan": 60,<br />
"mm-id": "local:1" #0 live traffic, 1 1st PCAP analysis<br />
}<br />
<br />
with session.get(host + "/API/stats/modules/ip/ips_paged", params=params) as resp:<br />
ip_list = resp.json()<br />
<br />
for ip_entry in ip_list["displayedItems"]:<br />
bytes_rx = ip_entry["interval"][1] #meaning of index defined in history.rows<br />
bytes_tx = ip_entry["interval"][3]<br />
print(ip_entry["ip"] + ": " + str(bytes_rx + bytes_tx) + "B")<br />
</pre><br />
<br />
==== Python Script Example - Top IPs pagination ====<br />
<br />
<pre><br />
#! /usr/bin/python3<br />
<br />
import requests<br />
<br />
requests.packages.urllib3.disable_warnings()<br />
<br />
host = "https://allegro-mm-xxxx"<br />
session = requests.Session()<br />
session.auth = ("user", "password")<br />
session.verify = False # disable ssl verification<br />
<br />
params = {<br />
"sort": "bytes",<br />
"reverse": True,<br />
"page": 0,<br />
"count": 10,<br />
"timespan": 60,<br />
"mm-id": "local:1" #0 live traffic, 1 1st PCAP analysis<br />
}<br />
<br />
with session.get(host + "/API/stats/modules/ip/ips_paged", params=params) as resp:<br />
ip_list = resp.json()<br />
number_of_items = ip_list["numberOfItems"]<br />
number_of_pages = ip_list["numberOfPages"]<br />
items_per_page = ip_list["itemsPerPage"]<br />
<br />
for page in range(0, number_of_pages):<br />
params["page"] = page<br />
with session.get(host + "/API/stats/modules/ip/ips_paged", params=params) as resp:<br />
ip_list = resp.json()<br />
<br />
for ip_entry in ip_list["displayedItems"]:<br />
bytes_rx = ip_entry["interval"][1] #meaning of index defined in history.rows<br />
bytes_tx = ip_entry["interval"][3]<br />
print(ip_entry["ip"] + ": " + str(bytes_rx + bytes_tx) + "B")<br />
</pre><br />
<br />
==== Python Script Example - Top IPs CSV download ====<br />
<br />
<pre><br />
#! /usr/bin/python3<br />
<br />
import requests<br />
import shutil<br />
<br />
requests.packages.urllib3.disable_warnings()<br />
<br />
host = "https://allegro-mm-xxxx"<br />
session = requests.Session()<br />
session.auth = ("user", "password")<br />
session.verify = False # disable ssl verification<br />
<br />
params = {<br />
"csv": True,<br />
"mm-id": "local:1" #0 live traffic, 1 1st PCAP analysis<br />
}<br />
<br />
headers = {<br />
"Accept-Encoding": "" # for compression use "gzip"<br />
}<br />
<br />
output = "ip_list_out.csv"<br />
<br />
with session.get(host + "/API/stats/modules/ip/ips_paged", params=params, headers=headers, stream=True) as resp:<br />
with open(output, "wb") as fh:<br />
shutil.copyfileobj(resp.raw, fh)<br />
</pre><br />
<br />
==== Python Script Example - Retrieval of global connections and PCAP download of a certain connection ====<br />
<br />
<pre><br />
#! /usr/bin/python3<br />
<br />
import requests<br />
import shutil<br />
import time<br />
import datetime<br />
<br />
requests.packages.urllib3.disable_warnings()<br />
<br />
host = "https://allegro-mm-xxxx"<br />
session = requests.Session()<br />
session.auth = ("user", "password")<br />
session.verify = False # disable ssl verification<br />
<br />
params = {<br />
"sort": "bytes",<br />
"reverse": True,<br />
"mode": "rtpStats",<br />
"mm-id": "local:1" #0 live traffic, 1 1st PCAP analysis<br />
}<br />
<br />
# get all RTP connections, sorted by bytes<br />
with session.get(host + "/API/stats/modules/ip/globalConnections", params=params) as resp:<br />
asyncID = resp.json()["asyncID"]<br />
asyncUUID = resp.json()["asyncUUID"]<br />
#print(resp.json())<br />
<br />
finished = False<br />
success = False<br />
<br />
params = {<br />
"uuid": asyncUUID,<br />
"mm-id": "local:1" #0 live traffic, 1 1st PCAP analysis<br />
}<br />
<br />
while not finished:<br />
with session.get(host + "/API/async/{}".format(asyncID), params=params) as resp:<br />
if (resp.status_code == 202):<br />
# request still pending<br />
time.sleep(1)<br />
continue;<br />
else:<br />
finished = True<br />
r = resp.json()<br />
if "errorCode" in r and r["errorCode"] == 0:<br />
asyncResult = r["asyncResult"]<br />
success = True<br />
<br />
# get start and end time of second connection<br />
if success and len(asyncResult["displayedItems"]) > 1:<br />
rtpConnection = asyncResult["displayedItems"][1]<br />
print("{}:{} <-> {}:{}".format(rtpConnection["clientIp"],<br />
rtpConnection["clientPort"],<br />
rtpConnection["serverIp"],<br />
rtpConnection["serverPort"]))<br />
print(rtpConnection["l4ProtocolShortName"] + ", " + rtpConnection["dpiProtocol"])<br />
start = datetime.datetime.fromtimestamp(rtpConnection["connectionStart"] / 1000)<br />
end = datetime.datetime.fromtimestamp(rtpConnection["lastActivity"] / 1000)<br />
print("start: " + start.strftime("%m-%d-%Y %H-%M-%S"))<br />
print("end: " + end.strftime("%m-%d-%Y %H-%M-%S"))<br />
<br />
# download PCAP of connection<br />
params = {<br />
"expression": "IP == {}:{} and IP == {}:{}".format(rtpConnection["clientIp"],<br />
rtpConnection["clientPort"],<br />
rtpConnection["serverIp"],<br />
rtpConnection["serverPort"]),<br />
"fromCaptureBuffer": True,<br />
"captureBufferSlotId": 0,<br />
"startTime": rtpConnection["connectionStart"] * 1000,<br />
"endTime": rtpConnection["lastActivity"] * 1000,<br />
"mm-id": "local:1" #0 live traffic, 1 1st PCAP analysis<br />
}<br />
<br />
headers = {<br />
"Accept-Encoding": "" # for compression use "gzip"<br />
}<br />
<br />
output = "rtp_connection.pcapng"<br />
<br />
with session.get(host + "/API/data/modules/capture", params=params, headers=headers, stream=True) as resp:<br />
with open(output, "wb") as fh:<br />
shutil.copyfileobj(resp.raw, fh)<br />
<br />
</pre><br />
<br />
<br />
==== Python Script Example - POST command to pause ring buffer ====<br />
<br />
This script sends a HTTP POST command to suspend the ring buffer #0 (first ring buffer).<br />
<pre><br />
#! /usr/bin/python3<br />
<br />
import requests<br />
import json<br />
<br />
requests.packages.urllib3.disable_warnings()<br />
<br />
host = "https://allegro-mm-xxxx"<br />
session = requests.Session()<br />
session.auth = ("user", "password")<br />
session.verify = False # disable ssl verification<br />
<br />
data = {<br />
"command": "changeConfig",<br />
"config": { "isSuspended": True }<br />
}<br />
<br />
with session.post(f"{host}/API/data/modules/capture/buffer/0", data=json.dumps(data)) as resp:<br />
print(resp.text)<br />
</pre></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4643IPMI BMC update2024-01-17T07:19:21Z<p>Ralf: </p>
<hr />
<div>Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
<ol><br />
<li><br />
Select your model from the following list and download the update zip file and unzip it. Find your model in the "System ID" at the page "Info -> System Info".<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}<br />
</li><br />
<li>To find out the IP address of the IPMI port:<br />
<ol><br />
<li>Connect LAN cable to IPMI Port<br />
<li>On a running Allegro Network Multimeter web interface, the current IPMI address can be found/configured in the management interface settings section.<br />
<li>Otherwise, connect monitor to VGA port and read IPMI address from monitor.</li><br />
</ol><br />
<li>Use web browser and connect to IPMI IP address.</li><br />
<li>Find password on device label and enter username "ADMIN". Older devices are shipped with the default password "ADMIN". If you cannot find the password for your device, you may contact the [[Reaching Allegro Packets Support|Allegro Packets Support]] for more information.[[File:Ipmi login.jpg|none|frame]]</li><br />
<li>Go to "Maintenance => Firmware Update".[[File:Ipmi update1.jpg|none|thumb|524x524px]]<br />
</li><br />
<li>Select "Enter Update Mode" and confirm.[[File:Ipmi update2.jpg|none|thumb|526x526px]]<br />
</li><br />
<li>Select the new BMC Version (.bin file) and upload file.[[File:Ipmi update3.jpg|none|thumb|529x529px]]<br />
</li><br />
<li>Keep all 3 checkboxes selectes and "Start upgrade".[[File:Ipmi update4.jpg|none|thumb|533x533px]]<br />
</li><br />
<li>Power cycle the device to make sure the new BMC firmware is running.</li><br />
</ol></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4642IPMI BMC update2024-01-17T07:16:37Z<p>Ralf: </p>
<hr />
<div>Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
<ol><br />
<li><br />
Select your model from the following list and download the update zip file and unzip it. Find your model in the "System ID" at the page "Info -> System Info".<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}<br />
</li><br />
<li>To find out the IP address of the IPMI port:<br />
<ol><br />
<li>Connect LAN cable to IPMI Port<br />
<li>On a running Allegro Network Multimeter web interface, the current IPMI address can be found/configured in the management interface settings section.<br />
<li>Otherwise, connect monitor to VGA port and read IPMI address from monitor.</li><br />
</ol><br />
<li>Use web browser and connect to IPMI IP address.</li><br />
<li>Find password on device label and enter username "ADMIN". Older devices are shipped with the default password "ADMIN". If you cannot find the password for your device, you may contact the Allegro Packet support for more information.[[File:Ipmi login.jpg|none|frame]]</li><br />
<li>Go to "Maintenance => Firmware Update".[[File:Ipmi update1.jpg|none|thumb|524x524px]]<br />
</li><br />
<li>Select "Enter Update Mode" and confirm.[[File:Ipmi update2.jpg|none|thumb|526x526px]]<br />
</li><br />
<li>Select the new BMC Version (.bin file) and upload file.[[File:Ipmi update3.jpg|none|thumb|529x529px]]<br />
</li><br />
<li>Keep all 3 checkboxes selectes and "Start upgrade".[[File:Ipmi update4.jpg|none|thumb|533x533px]]<br />
</li><br />
<li>Power cycle the device to make sure the new BMC firmware is running.</li><br />
</ol></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4641IPMI BMC update2024-01-17T07:15:59Z<p>Ralf: </p>
<hr />
<div>Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
<ol><br />
<li><br />
Select your model from the following list and download the update zip file and unzip it. Find your model in the "System ID" at the page "Info -> System Info".<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}<br />
</li><br />
<li>To find out the IP address of the IPMI port:<br />
<ol><br />
<li>Connect LAN cable to IPMI Port<br />
<li>On a running Allegro Network Multimeter web interface, the current IPMI address can be found/configured in the management interface settings section.<br />
<li>Otherwise, connect monitor to VGA port and read IPMI address from monitor.</li><br />
<li>Use web browser and connect to IPMI IP address.</li><br />
<li>Find password on device label and enter username "ADMIN". Older devices are shipped with the default password "ADMIN". If you cannot find the password for your device, you may contact the Allegro Packet support for more information.[[File:Ipmi login.jpg|none|frame]]</li><br />
</ol><br />
<li>Go to "Maintenance => Firmware Update".[[File:Ipmi update1.jpg|none|thumb|524x524px]]<br />
</li><br />
<li>Select "Enter Update Mode" and confirm.[[File:Ipmi update2.jpg|none|thumb|526x526px]]<br />
</li><br />
<li>Select the new BMC Version (.bin file) and upload file.[[File:Ipmi update3.jpg|none|thumb|529x529px]]<br />
</li><br />
<li>Keep all 3 checkboxes selectes and "Start upgrade".[[File:Ipmi update4.jpg|none|thumb|533x533px]]<br />
</li><br />
<li>Power cycle the device to make sure the new BMC firmware is running.</li><br />
</ol></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4640IPMI BMC update2024-01-17T07:14:52Z<p>Ralf: /* Update steps */</p>
<hr />
<div>Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
<ol><br />
<li><br />
Select your model from the following list and download the update zip file and unzip it. Find your model in the "System ID" at the page "Info -> System Info".<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}<br />
</li><br />
<li>To find out the IP address of the IPMI port:<br />
<li>Connect LAN cable to IPMI Port<br />
<li>On a running Allegro Network Multimeter web interface, the current IPMI address can be found/configured in the management interface settings section.<br />
<li>Otherwise, connect monitor to VGA port and read IPMI address from monitor.</li><br />
<li>Use web browser and connect to IPMI IP address.</li><br />
<li>Find password on device label and enter username "ADMIN". Older devices are shipped with the default password "ADMIN". If you cannot find the password for your device, you may contact the Allegro Packet support for more information.[[File:Ipmi login.jpg|none|frame]]</li><br />
<li>Go to "Maintenance => Firmware Update".[[File:Ipmi update1.jpg|none|thumb|524x524px]]<br />
</li><br />
<li>Select "Enter Update Mode" and confirm.[[File:Ipmi update2.jpg|none|thumb|526x526px]]<br />
</li><br />
<li>Select the new BMC Version (.bin file) and upload file.[[File:Ipmi update3.jpg|none|thumb|529x529px]]<br />
</li><br />
<li>Keep all 3 checkboxes selectes and "Start upgrade".[[File:Ipmi update4.jpg|none|thumb|533x533px]]<br />
</li><br />
<li>Power cycle the device to make sure the new BMC firmware is running.</li><br />
</ol></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=SIP_module&diff=4637SIP module2024-01-16T08:19:46Z<p>Ralf: /* Call detail page */</p>
<hr />
<div>The SIP statistics includes all SIP calls and their associated metadata.<br />
<br />
== SIP dashboard ==<br />
<br />
The SIP dashboard tab provides an overview of the gathered SIP statistics. <br />
<br />
{| class="wikitable sortable"<br />
|-<br />
|[[File:SIP Statistics.png|1000px|none|right]]<br />
|}<br />
<br />
These include:<br />
<br />
* SIP traffic, RTP traffic as well as total traffic<br />
* Overall RTP packet loss<br />
* Overall RTP jitter<br />
* Distribution of SIP response types<br />
* Number of concurrent calls<br />
<br />
On top, there is a table and a graph showing the number of SIP call response types per response class. <br />
Additionally, there is a table and a graph showing the maximum number of concurrent calls.<br />
<br />
== Per-Call statistics ==<br />
<br />
The SIP calls tab, contains a table listing all SIP calls in realtime or from the selected interval.<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
|[[File:1000px-Sip calls.png|1000px|none|right]]<br />
|}<br />
<br />
For each call, the call statistics and the related RTP statistics are shown. These include:<br />
<br />
* The IP (see [[Common table columns#IP|Common table columns - IP]]) for caller and the callee is shown, as well as the phone number/SIP address and all correlated naming informations. By clicking on the "Details" button on the far right, a detailed summary page for the particular call will be displayed.<br />
* The Call ID column lists the call ID and all similar identifiers (e.g. P-Palladion-ID or Av-Global-Session-ID) for the SIP flow. The small filter icon allows for setting a filter for any of these call identifiers. This allows for filtering all legs of one call, even if several SIP flows were involved.<br />
* The "SIP displayed" and "SIP+RTP displayed" PCAP buttons next to the filter bar will capture all SIP calls visible on the table page. A filter that limits the visible SIP calls is taken into account. You can increase the elements of the table to have more calls captured.<br />
* The RTP IP and port for caller and the callee is shown, if the call is/was successful and an RTP stream could be initiated.<br />
* The RTCP IP and port for caller and the callee is shown, if RTCP packets were seen. RTCP packets contain information about quality parameters such as RTP packet loss and jitter. They are sent by the caller or callee and provide feedback of the RTP packets they have received.<br />
* Call initiation, Call established, Call end time and Call duration are displayed.<br />
* RTP packet loss per direction is shown.<br />
* RTP payload type (codec) per direction is shown.<br />
* RTCP reported packet loss is shown. The loss occurred in the indicated direction.<br />
* QoS tags per direction of both the SIP and RTP flow are shown.<br />
* Jitter of RTP stream per direction is calculated and shown.<br />
* Jitter buffer exceeded: This the amount of events of RTP jitter exceeding the configured jitter buffer threshold. The threshold can be configured in SIP module settings.<br />
* Packet time delta of RTP stream per direction is calculated and shown. This is the time delta between two subsequent RTP packets. It is shown as min/avg/max value for the selected timespan or the duration of the whole connection.<br />
* RTCP reported jitter is shown. The jitter was measured for the indicated direction.<br />
* The maximum clock skew (negative or positive) is shown.<br />
* Mean Opinion Score (MOS) per direction is evaluated and shown.<br />
* Audio level (min, max and RMS) per direction if G.711 codec is used. The values are extracted from the samples of the RTP packets. The max value will show peaks, whereas the RMS will show an average loudness level and a better impression of the whole call. The values are displayed in dbFS. <br />
* Expected and actual sample rate per direction is displayed and the measured bitrate of the RTP stream.<br />
* Status of origin SIP invite request that initiated the call.<br />
* The graph (see [[Common table columns#Graph|Common table columns - Graph]]) shows information of the RTP stream per direction. By using the graphselector<sup>1</sup> packet rate, dropped packets, overhead (duplicated) packets, Jitter, MOS and max audio level over time can be displayed.<br />
[[File:Graphselector.jpg|none]]<br />
<br />
It is also possible to capture traffic for a specific SIP call by clicking on the corresponding button in the last column.<br />
First click the “Zoom” button below the PCAP button, to select the time range of a call. The PCAP button "SIP" will only extract the SIP packets for that specific call by taking IP addresses and SIP call IDs into account. The PCAP button "SIP+RTP/RTCP" allows extracting both the SIP and RTP packets of that specific call.<br />
<br />
The toggle button "Caller/callee (combined)" allows for switching the display to have both caller and callee counters in separate columns for easier sorting. The toggle button "Reduced view" allows switching the display to a condensed mode where one call only needs one row. With this mode it is possible to show up to 100 lines on one page.<br />
<br />
For audible validation of call quality (e.g. distortion not caused by the network), it is possible to extract the audio of RTP streams as an MP3. Buttons allow to capture each direction (A/B) and also both directions of the audio stream mixed into one stereo file (each direction will be a different channel).<br />
The MP3 extraction is only supported for the following codecs:<br />
<br />
* G.711 A-law (ALAW)<br />
* G.711 μ-law (ULAW)<br />
* G.722<br />
* G.729<br />
* Opus (*)<br />
* AMR and AMR-WB (*)<br />
* EVS (*)<br />
* GSM<br />
<br />
(*) These codecs are negotiated in the SIP SDP handshake and can only be extracted if the handshake was seen by the Allegro Network Multimeter.<br />
<br />
On the bottom of the table the "CSV download" button allows exporting all pages of the table in CSV format.<br />
<br />
'''Addendum - MOS:'''<br />
The displayed mean opinion score (MOS) of a call is calculated from various metrics within an RTP stream.<br />
Following scores are used:<br />
<br />
* 5: excellent<br />
* 4: good<br />
* 3: fair<br />
* 2: poor<br />
* 1: bad<br />
<br />
The Mean opinion score is only calculated for the following codecs:<br />
<br />
* G.711 A-law (ALAW)<br />
* G.711 μ-law (ULAW)<br />
* G.722<br />
* G.729<br />
* GSM<br />
<br />
=== Call detail page ===<br />
<br />
By clicking on the "DETAILS" button, next to a call on the far right, a very detailed call statistics page will be opened.<br />
<br />
[[File:SIP call details Screen.png||1000px|none|right|The Allegro's SIP call details screen]]<br />
<br />
On this page all information of the global call list are shown in a very detailed overview summary. Here you'll also find a tab "Correlated calls" that lists all calls with the same SIP call id. The "Events" tab shows all SIP packets per direction for that SIP flow with the given SIP call ID.<br />
<br />
If an RTP connection was found for that SIP call, [[RTP statistics]] are shown as well with additional information for the actual voice/video connection.<br />
<br />
== SIP request methods ==<br />
<br />
The SIP request methods tab lists the observed SIP requests. A table lists the number of events and a graph showing the event distribution.<br />
<br />
For each request method there is a detail view showing the IP addresses seen sending the specific request.<br />
<br />
== SIP response types ==<br />
<br />
The SIP response types tab lists the SIP status codes of observed SIP responses. A table lists the number of events and a graph showing the event distribution.<br />
<br />
The response types are grouped into the following classes:<br />
<br />
* 1xx - Provisional: temporary status information. The server st<br />
* 2xx - Successful: The request was successful.<br />
* 3xx - Redirection: Inform about a new contact address or other services to establish a connection.<br />
* 4xx - Request Failure: The request is invalid and could not be processed.<br />
* 5xx - Server Failure: An involved server could not process the request<br />
* 6xx - Global Failure: The request cannot be processed, even not with alternative destinations<br />
For each response type there is a detail view showing the IP addresses seen sending the specific request.<br />
<br />
== SIP request/response pairs ==<br />
<br />
The SIP requests/responses tab lists the observed SIP request/response pairs. <br />
<br />
A table lists the number of events and a graph showing the event distribution. <br />
<br />
The events are accounted at the time of the response. If there are multiple requests (retransmissions), but only a single response, this will be accounted as one request/response pair.<br />
<br />
For each request/response pair there is a detail view showing the involved IP addresses.<br />
<br />
== SIP connections ==<br />
<br />
This table lists all SIP connections, separated by IP addresses. By clicking on the events magnifier icon the SIP connection events page will be shown with all SIP packets for that connection.<br />
<br />
=== SIP connection events ===<br />
<br />
The events tab shows all SIP packets between two specific IP addresses. The table can be filtered by SIP call IDs and allows displaying SIP packets of a specific call.<br />
<br />
== SIP module options ==<br />
<br />
The following settings are available for the SIP module:<br />
<br />
* Store individual SIP events<br />
: This option enables the storage of individual SIP events for each SIP connections. If enabled, the event list of each connection will list all SIP messages separately (such as OPTION, INVITE,etc). This allows to see the SIP packet flow between the client and server. This however uses more memory so it can be disabled if it is not needed.<br />
* Enable measurement of RTP jitter and packet loss<br />
: This option enables the calculation of jitter values and packet loss which are accounted globally and per interface, and per IP address and connection (if enabled in the [[IP module]]). Disabling this option improves the system performance and reduces the memory utilization.<br />
* Ignore samples below this threshold for audio RMS calculation (negative dbFS, 0 = inactive)<br />
: Audio RMS calculation by default is done for every sample. With this setting, silence or background noise of e.g. < -80 dbFS can be ignored and don't have an impact on the RMS.<br />
* Generate RTP statistics per network interface<br />
: When enabled, the RTP statistics are also stored per network interface. Depending on the number of interfaces and the amount of RTP traffic, this can have an impact on the system performance and the option can therefore be disabled if such information is not needed.<br />
* Calculate audio level for supported codecs<br />
: When enabled, the audio levels are calculated for all supported audio codecs. This option has a large impact on the performance so it can be disabled if such analysis is not needed.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4624IPMI BMC update2023-12-19T12:13:32Z<p>Ralf: </p>
<hr />
<div>Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
<ol><br />
<li><br />
Select your model from the following list and download the update zip file and unzip it. Find your model in the "System ID" at the page "Info -> System Info".<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}<br />
</li><br />
<li>To find out the IP address of the IPMI port:<br />
<ol><br />
<li>Connect monitor to VGA port.</li><br />
<li>Connect LAN cable to IPMI Port and read IPMI address from monitor.</li><br />
</ol><br />
<li>Use web browser and connect to IPMI IP address.</li><br />
<li>Find password on device label and enter username "ADMIN".[[File:Ipmi login.jpg|none|frame]]</li><br />
<li>Go to "Maintenance => Firmware Update".[[File:Ipmi update1.jpg|none|thumb|524x524px]]<br />
</li><br />
<li>Select "Enter Update Mode" and confirm.[[File:Ipmi update2.jpg|none|thumb|526x526px]]<br />
</li><br />
<li>Select the new BMC Version (.bin file) and upload file.[[File:Ipmi update3.jpg|none|thumb|529x529px]]<br />
</li><br />
<li>Keep all 3 checkboxes selectes and "Start upgrade".[[File:Ipmi update4.jpg|none|thumb|533x533px]]<br />
</li><br />
<li>Power cycle the device to make sure the new BMC firmware is running.</li><br />
</ol></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4623IPMI BMC update2023-12-19T12:12:25Z<p>Ralf: </p>
<hr />
<div><accesscontrol>AC:GroupUsers</accesscontrol><br />
<br />
Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
<ol><br />
<li><br />
Select your model from the following list and download the update zip file and unzip it. Find your model in the "System ID" at the page "Info -> System Info".<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}<br />
</li><br />
<li>To find out the IP address of the IPMI port:<br />
<ol><br />
<li>Connect monitor to VGA port.</li><br />
<li>Connect LAN cable to IPMI Port and read IPMI address from monitor.</li><br />
</ol><br />
<li>Use web browser and connect to IPMI IP address.</li><br />
<li>Find password on device label and enter username "ADMIN".[[File:Ipmi login.jpg|none|frame]]</li><br />
<li>Go to "Maintenance => Firmware Update".[[File:Ipmi update1.jpg|none|thumb|524x524px]]<br />
</li><br />
<li>Select "Enter Update Mode" and confirm.[[File:Ipmi update2.jpg|none|thumb|526x526px]]<br />
</li><br />
<li>Select the new BMC Version (.bin file) and upload file.[[File:Ipmi update3.jpg|none|thumb|529x529px]]<br />
</li><br />
<li>Keep all 3 checkboxes selectes and "Start upgrade".[[File:Ipmi update4.jpg|none|thumb|533x533px]]<br />
</li><br />
<li>Power cycle the device to make sure the new BMC firmware is running.</li><br />
</ol></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4622IPMI BMC update2023-12-19T12:10:59Z<p>Ralf: </p>
<hr />
<div><accesscontrol>AC:GroupUsers</accesscontrol><br />
<br />
Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
<ol><br />
<li><br />
Select your model from the following list and download the update zip file. Find your model in the "System ID" at the page "Info -> System Info".<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}<br />
</li><br />
<li>To find out the IP address of the IPMI port:<br />
<ol><br />
<li>Connect monitor to VGA port.</li><br />
<li>Connect LAN cable to IPMI Port and read IPMI address from monitor.</li><br />
</ol><br />
<li>Use web browser and connect to IPMI IP address.</li><br />
<li>Find password on device label and enter username "ADMIN".[[File:Ipmi login.jpg|none|frame]]</li><br />
<li>Go to "Maintenance => Firmware Update".[[File:Ipmi update1.jpg|none|thumb|524x524px]]<br />
</li><br />
<li>Select "Enter Update Mode" and confirm.[[File:Ipmi update2.jpg|none|thumb|526x526px]]<br />
</li><br />
<li>Select the new BMC Version (.bin file) and upload file.[[File:Ipmi update3.jpg|none|thumb|529x529px]]<br />
</li><br />
<li>Keep all 3 checkboxes selectes and "Start upgrade".[[File:Ipmi update4.jpg|none|thumb|533x533px]]<br />
</li><br />
<li>Power cycle the device to make sure the new BMC firmware is running.</li><br />
</ol></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=File:Ipmi_update4.jpg&diff=4621File:Ipmi update4.jpg2023-12-19T12:10:36Z<p>Ralf: </p>
<hr />
<div>IPMI update step 4</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=File:Ipmi_update3.jpg&diff=4620File:Ipmi update3.jpg2023-12-19T12:10:10Z<p>Ralf: </p>
<hr />
<div>IPMI update step 3</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=File:Ipmi_update2.jpg&diff=4619File:Ipmi update2.jpg2023-12-19T12:09:34Z<p>Ralf: </p>
<hr />
<div>IPMI update step 2</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=File:Ipmi_update1.jpg&diff=4618File:Ipmi update1.jpg2023-12-19T12:08:15Z<p>Ralf: </p>
<hr />
<div></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4617IPMI BMC update2023-12-19T12:05:34Z<p>Ralf: </p>
<hr />
<div><accesscontrol>AC:GroupUsers</accesscontrol><br />
<br />
Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
<ol><br />
<li><br />
Select your model from the following list and download the update zip file. Find your model in the "System ID" at the page "Info -> System Info".<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}<br />
</li><br />
<li>To find out the IP address of the IPMI port:<br />
<ol><br />
<li>Connect monitor to VGA port.</li><br />
<li>Connect LAN cable to IPMI Port and read IPMI address from monitor.</li><br />
</ol><br />
<li>Use web browser and connect to IPMI IP address.</li><br />
<li>Find password on device label and enter username "ADMIN".[[File:Ipmi login.jpg|none|frame]]</li><br />
<li>Go to "Maintenance => Firmware Update".<br />
</li><br />
<li>Select "Enter Update Mode" and confirm.</li><br />
<li>Select the new BMC Version (.bin file) and upload file.</li><br />
<li>Keep all 3 checkboxes selectes and "Start upgrade".</li><br />
<li>Power cycle the device to make sure the new BMC firmware is running.</li><br />
</ol></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=File:Ipmi_login.jpg&diff=4615File:Ipmi login.jpg2023-12-19T12:02:04Z<p>Ralf: </p>
<hr />
<div>Ipmi login dialog</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4614IPMI BMC update2023-12-19T11:09:08Z<p>Ralf: </p>
<hr />
<div><accesscontrol>AC:GroupUsers</accesscontrol><br />
<br />
Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
<ol><br />
<li><br />
Select your model from the following list and download the update zip file. Find your model in the "System ID" at the page "Info -> System Info".<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}<br />
</li><br />
<li>To find out the IP address of the IPMI port:<br />
<ol><br />
<li>Connect monitor to VGA port.</li><br />
<li>Connect LAN cable to IPMI Port and read IPMI address from monitor.</li><br />
</ol><br />
<li>Use web browser and connect to IPMI IP address.</li><br />
<li>Find password on device label and enter username "ADMIN".</li><br />
<li>Go to "Maintenance => Firmware Update".</li><br />
<li>Select "Enter Update Mode" and confirm.</li><br />
<li>Select the new BMC Version (.bin file) and upload file.</li><br />
<li>Keep all 3 checkboxes selectes and "Start upgrade".</li><br />
<li>Power cycle the device to make sure the new BMC firmware is running.</li><br />
</ol></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_KVM_on_Allegro_series_1000%2B&diff=4613IPMI KVM on Allegro series 1000+2023-12-19T11:07:52Z<p>Ralf: </p>
<hr />
<div>Many Allegro Network Multimeters come with an on-board [https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface IPMI] interface for basic hardware management.<br />
<br />
This interface can be used to start, reboot, or shutdown the device without accessing the web interface. You can also access a virtual monitor to view the output on the console and use a virtual keyboard to interact with the device (KVM: ''keyboard, video, mouse''). This can be helpful for [[Performing a factory reset or configuration reset]].<br />
<br />
The following table shows if the device supports IPMI and where the IPMI KVM port is located:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Device type !! IPMI support !! Port location<br />
|-<br />
| Allegro 200 || no<br />
|-<br />
| Allegro 500 || no<br />
|-<br />
| Allegro 800-P <br /> Allegro 1000 <br /> Allegro 3000 <br />
| yes || [[File:Allegro-1000-kvm-port.jpg|frameless]]<br />
|-<br />
| Allegro 800-RM <br /> Allegro 1200 <br /> Allegro 3200 <br />
| yes<br />
|[[File:Allegro-1200-kvm.jpg|frameless|528x528px]]<br />
|-<br />
| Allegro 1300 <br /> Allegro 3300 <br /> Allegro 5300 <br />
| yes<br />
|[[File:Allegro-x300-kvm.jpg|frameless|520x520px]]<br />
|-<br />
|Allegro 1310 <br /> Allegro 3310 <br /> Allegro 5310 <br /> Allegro 7310<br />
|yes<br />
|[[File:X310 kvm.png|frameless|520x520px]]<br />
|-<br />
|Allegro 1400 <br /> Allegro 3400 <br /> Allegro 5400<br />
|yes<br />
|[[File:X400 kvm.png|frameless|520x520px]]<br />
|-<br />
|Allegro 1410 <br /> Allegro 3410 <br /> Allegro 5410 <br /> Allegro 7410<br />
|yes<br />
|[[File:X410 kvm.png|frameless|520x520px]]<br />
|-<br />
| Allegro 1500 <br /> Allegro 1510 <br /> Allegro 3500 <br /> Allegro 3510 <br /> Allegro 5500 <br /> Allegro 5510 <br /> Allegro 7510<br />
| yes<br />
|[[File:Allegro-x500-kvm.jpg|frameless|520x520px|alt=]]<br />
|}<br />
<br />
== Access to IPMI ==<br />
<br />
The IPMI interface can be accessed via a LAN using the very top-left Ethernet port, usually above the USB ports. By default, the port will obtain an IP address via DHCP, but it can be reconfigured within the IPMI web interface.<br />
<br />
If you point a browser to that IP address, a SuperMicro login will be presented where you can log into the interface:<br />
<br />
[[File:Kvm login.png|640px]]<br />
<br />
The default credentials are ADMIN/ADMIN but some newer devices come with a random password printed on the serial number sticker. On Allegro x300 series, the password is printed below a retractable plastic plate on top of the top-left 2.5 inch disk drive bay.<br />
<br />
We recommend to change the default password into a secure one.<br />
<br />
== Access to Health event log ==<br />
<br />
There is an event log which shows all system health related events. In case of hardware problems, this can be useful to check.<br />
<br />
[[File:Kvm event log.png|640px]]<br />
<br />
[[File:Kvm event log2.png|640px]]<br />
<br />
== Virtual console ==<br />
<br />
The IPMI interface also allows to use a virtual console to see the monitor output and use a keyboard for input. This is useful when boot changes must be made, for example, a factory reset is required. It also allows to make screenshots from the boot process in case of problems.<br />
<br />
[[File:Kvm console.png|640px]]<br />
<br />
== Additional information ==<br />
<br />
Please refer to the [http://www.supermicro.com/manuals/other/IPMI_Users_Guide.pdf official documentation] for more information.<br />
<br />
== IPMI BMC update ==<br />
The BMC can be updated manually, see [[IPMI BMC update|this page]] for more detailed information.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4612IPMI BMC update2023-12-19T11:03:57Z<p>Ralf: </p>
<hr />
<div><accesscontrol>AC:GroupUsers</accesscontrol><br />
<br />
Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
<ol><br />
<li><br />
Select your model from the following list and download the update zip file:<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}<br />
</li><br />
<li>To find out the IP address of the IPMI port:<br />
<ol><br />
<li>Connect monitor to VGA port.</li><br />
<li>Connect LAN cable to IPMI Port and read IPMI address from monitor.</li><br />
</ol><br />
<li>Use web browser and connect to IPMI IP address.</li><br />
<li>Find password on device label and enter username "ADMIN".</li><br />
<li>Go to "Maintenance => Firmware Update".</li><br />
<li>Select "Enter Update Mode" and confirm.</li><br />
<li>Select the new BMC Version (.bin file) and upload file.</li><br />
<li>Keep all 3 checkboxes selectes and "Start upgrade".</li><br />
<li>Power cycle the device to make sure the new BMC firmware is running.</li><br />
</ol></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4611IPMI BMC update2023-12-19T11:01:57Z<p>Ralf: </p>
<hr />
<div><accesscontrol>AC:GroupUsers</accesscontrol><br />
<br />
Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
<ol><br />
<li><br />
Select your model from the following list and download the update zip file:<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}<br />
</li><br />
<li>To find out the IP address of the IPMI port:<br />
<ol><br />
<li>Connect monitor to VGA port.</li><br />
<li>Connect LAN cable to IPMI Port and read IPMI address from monitor.</li><br />
</ol><br />
<li>Use web browser and connect to IPMI IP address.</li><br />
<li>Find password on device label and enter username "ADMIN".</li><br />
<li>Go to "Maintenance => Firmware Update".</li><br />
<li>Select "Enter Update Mode" and confirm.</li><br />
<li>Select the new BMC Version (.bin file) and upload file.</li><br />
<li>Keep all 3 checkboxes selectes and "Start upgrade".</li><br />
<li>Power cycle the device to make sure the new BMC firmware is running.</li><br />
</ol></div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4610IPMI BMC update2023-12-19T10:45:32Z<p>Ralf: </p>
<hr />
<div><accesscontrol>AC:GroupUsers</accesscontrol><br />
<br />
Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
# Select your model from the following list and download the update zip file:<br />
<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4609IPMI BMC update2023-12-19T10:44:36Z<p>Ralf: </p>
<hr />
<div><accesscontrol>AC:GroupUsers</accesscontrol><br />
<br />
Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
# Select your model from the following list and download the update zip file:<br />
<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC]<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC]<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC]<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC]<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC]<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC]<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC]<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4608IPMI BMC update2023-12-19T10:43:14Z<p>Ralf: </p>
<hr />
<div><accesscontrol>AC:GroupUsers</accesscontrol><br />
<br />
Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
This section lists all known vulnerabilities, affected models and solutions.<br />
<br />
The "System ID" in the Allegro web interface "Info -> System Info" contains the model number, such as "Allegro-5300-rev2+...".<br />
<br />
Firmware version >= 4.2 lists possible updates for the BMC at the page "Settings -> Firmware update".<br />
<br />
List of known vulnerabilities:<br />
*https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** Related CVEs:<br />
*** CVE-2023-40289<br />
*** CVE-2023-40284<br />
*** CVE-2023-40287<br />
*** CVE-2023-40288<br />
*** CVE-2023-40290<br />
*** CVE-2023-40285<br />
*** CVE-2023-40286<br />
** Affected Allegro models:<br />
*** 1000-rev1<br />
*** 1200-rev1<br />
*** 1000-rev3<br />
*** 1200-rev3<br />
*** 3000-rev1<br />
*** 3200-rev1<br />
*** 3000-rev3<br />
*** 3200-rev3<br />
*** x300-rev1<br />
*** x300-rev3<br />
*** x500-rev1<br />
*** x500-rev2<br />
<br />
=== Update steps ===<br />
<br />
# Select your model from the following list and download the update zip file:<br />
<br />
{| class="wikitable"<br />
|+BMC update list<br />
!Model<br />
!Update download<br />
|-<br />
|Allegro 1000/1200 rev 1<br />
|[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC https://www.supermicro.com/en/support/]<br />
[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC resources/downloadcenter/firmware/MBD-]<br />
<br />
[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-TP8F/BMC X10SDV-TP8F/BMC]<br />
|-<br />
|Allegro 1000/1200 rev 3<br />
|[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC https://www.supermicro.com/de/support/]<br />
[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC resources/downloadcenter/firmware/MBD-]<br />
<br />
[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-4C-TP8F/BMC X11SDV-4C-TP8F/BMC]<br />
|-<br />
|Allegro 3000/3200 rev 1<br />
|[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC https://www.supermicro.com/en/support/]<br />
[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC resources/downloadcenter/firmware/MBD-]<br />
<br />
[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SDV-7TP8F/BMC X10SDV-7TP8F/BMC]<br />
|-<br />
|Allegro 3000/3200 rev 3<br />
|[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC https://www.supermicro.com/de/support/]<br />
[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC resources/downloadcenter/firmware/MBD-]<br />
<br />
[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11SDV-16C-TP8F/BMC X11SDV-16C-TP8F/BMC]<br />
|-<br />
|Allegro 1300/3300/5300 rev 1<br />
|[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC https://www.supermicro.com/en/support/]<br />
[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC resources/downloadcenter/firmware/MBD-]<br />
<br />
[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12SSW-NT/BMC H12SSW-NT/BMC]<br />
|-<br />
|Allegro 1300/3300/5300 rev 3<br />
|[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC https://www.supermicro.com/en/support/]<br />
[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC resources/downloadcenter/firmware/MBD-]<br />
<br />
[https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H12DSU-iN/BMC H12DSU-iN/BMC]<br />
|-<br />
|Allegro 1500/3500/5500 rev 1<br />
|[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC https://www.supermicro.com/de/support/]<br />
[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC resources/downloadcenter/firmware/MBD-]<br />
<br />
[https://www.supermicro.com/de/support/resources/downloadcenter/firmware/MBD-X11DPH-T/BMC X11DPH-T/BMC]<br />
|-<br />
|Allegro 1500/3500/5500 rev 2<br />
|https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-H11SSL-NC/BMC<br />
|}</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=IPMI_BMC_update&diff=4607IPMI BMC update2023-12-19T10:26:46Z<p>Ralf: </p>
<hr />
<div><accesscontrol>AC:GroupUsers</accesscontrol><br />
<br />
Most Allegro Network Multimeter come with a separate Management Interface (IPMI) which runs even if the system is powered off.<br />
<br />
This "Baseboard Management controller" (BMC) can be updated by the user manually by logging into the IPMI interface and executing the update steps described below.<br />
<br />
=== Known Vulnerabilities ===<br />
<br />
* https://www.supermicro.com/en/support/security_BMC_IPMI_Oct_2023<br />
** CVE-2023-40289<br />
** CVE-2023-40284<br />
** CVE-2023-40287<br />
** CVE-2023-40288<br />
** CVE-2023-40290<br />
** CVE-2023-40285<br />
** CVE-2023-40286</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=DB_persistence&diff=4602DB persistence2023-12-15T11:51:58Z<p>Ralf: </p>
<hr />
<div>The DB persistence feature (in firmware >= 4.2) can write parts of the In-Memory database onto an selected storage device when stopping the packet processing (either manually or when rebooting the device). On restart, the stored data is imported again to make some data available again after restart.<br />
<br />
The stored data comprises:<br />
[[File:DB persistence settings.png|thumb|DB persistence settings]]<br />
* the list of MAC addresses and their direct graphs, not including the per-element tables.<br />
* the list of IP addresses and their direct graphs (traffic, retransmissions and other TCP stats for that IP address), not including the per-element tables.<br />
* the IP groups data (same elements as the IP addresses).<br />
* the Layer 7 protocol traffic graphs.<br />
<br />
The feature must be enabled in the global settings in the "DB persistence" tab. The storage device must be selected and should be reasonable fast. We recommend using SSD storage only as it can take a few seconds to a few minutes on such fast disc but much longer on slower spinning discs.<br />
<br />
The processing restart dialog will allow to disable dump and/or restoration for one time.<br />
<br />
The dialog also shows progress during restart which also to cancel the operation.<br />
<br />
The configuration dialog also shows the size of the persisted data and allow to remove it.<br />
<br />
=== Limitations ===<br />
<br />
* Data dump and restoration works between the same firmware version and also between different firmware version but due to increasing feature set, importing data from a newer firmware (when downgrading) may not work always. In this case the import will be only partial and normal operation continues.<br />
* Some setting changes will make the import of some data impossible:<br />
** Changing the resolution of graph data is not supported for the DB persistence feature. The import will skip data from written with different settings.<br />
* As with all data on storage devices, the configuration of factory reset will not delete the persisted DB data and it must be removed manually by either selecting the button in the configuration dialog or by formatting the storage device.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=DB_persistence&diff=4599DB persistence2023-12-15T09:23:50Z<p>Ralf: Created page with "The DB persistence feature (in firmware >= 4.2) can write parts of the In-Memory database onto an selected storage device when stopping the packet processing (either manually..."</p>
<hr />
<div>The DB persistence feature (in firmware >= 4.2) can write parts of the In-Memory database onto an selected storage device when stopping the packet processing (either manually or when rebooting the device). On restart, the stored data is imported again to make some data available again after restart.<br />
<br />
The stored data comprises:<br />
<br />
* the list of MAC addresses and their direct graphs, not including the per-element tables.<br />
* the list of IP addresses and their direct graphs (traffic, retransmissions and other TCP stats for that IP address), not including the per-element tables.<br />
* the IP groups data (same elements as the IP addresses).<br />
* the Layer 7 protocol traffic graphs.<br />
<br />
The feature must be enabled in the global settings in the "DB persistence" tab. The storage device must be selected and should be reasonable fast. We recommend using SSD storage only as it can take a few seconds to a few minutes on such fast disc but much longer on slower spinning discs.<br />
<br />
The processing restart dialog will allow to disable dump and/or restoration for one time.<br />
<br />
The dialog also shows progress during restart which also to cancel the operation.<br />
<br />
The configuration dialog also shows the size of the persisted data and allow to remove it.<br />
<br />
=== Limitations ===<br />
<br />
* Data dump and restoration works between the same firmware version and also between different firmware version but due to increasing feature set, importing data from a newer firmware (when downgrading) may not work always. In this case the import will be only partial and normal operation continues.<br />
* Some setting changes will make the import of some data impossible:<br />
** Changing the resolution of graph data is not supported for the DB persistence feature. The import will skip data from written with different settings.<br />
* As with all data on storage devices, the configuration of factory reset will not delete the persisted DB data and it must be removed manually by either selecting the button in the configuration dialog or by formatting the storage device.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Global_settings&diff=4598Global settings2023-12-15T09:13:25Z<p>Ralf: </p>
<hr />
<div>The Global settings section contains parameters for adjusting the behavior of the system.<br />
The settings are split among multiple tabs, described as follows.<br />
<br />
== Generic settings ==<br />
<br />
=== Packet processing mode ===<br />
<br />
This section allows for configuring the main packet processing mode:<br />
<br />
<br />
* '''Bridge mode''': In Bridge mode A.K.A. In-Line mode, all received packets will be transmitted between corresponding port pairs (e.g. 1+2, 3+4 on Allegro 500) so that the Allegro Network Multimeter can be placed in-line between any network component.<br/ >The device will operate transparent and will not modify network traffic in any way. The additional latency will be typically around or less than 1 millisecond.<br>In Bridge mode it is also possible to process network traffic from a mirror port or Tap. However, "only" half of the total available ports on each respective Allegro Network Multimeter model can be used to operate in this way. For example on a 4-port Allegro model 500, you can conveniently leave the unit in bridge mode and connect up to two mirror ports on interfaces 1 and 3 respectively. Aforementioned interfaces are physically separated and not an (in-line) interface pair.<br />Always avoid connecting mirror port traffic on an Allegro Network Multimeter interface pair (e.g. 1+2, 3+4 on Allegro 500), as this will result in TX traffic in the direction of a mirror port which if highly undesirable.<br />[[File:Inline mode.jpg|800px|Allegro in brigde mode (in-line)]]<br />
<br />
* '''Sink mode''': In Sink mode, the Allegro Network Multimeter will operate "receive only".<br />Packets are not forwarded and there's no bi-directional traffic on any of the monitoring ports. This operation mode allows for installation at a Mirror port of a Switch or when using a network Tap to access the network traffic.<br />[[File:Sink mode1.jpg|800px|Allegro in Sink mode on Mirror port or Tap]]<br />
<br />
* '''Mixed bridge/sink mode:''' This mode enables to configure the packet processing mode for each interface pair. Interface pairs default to Bridge mode but the mode can be permanently changed in the [[interface statistics]].<br />
<br />
The packet processing mode can be changed during runtime.<br />
<br />
Attention: Please always keep in mind, that while in bridge mode (Allegro Network Multimeter = in-line), a Link will be (shortly) interrupted when switching processing mode or/and rebooting the Allegro Network Multimeter.<br />
<br />
=== Endpoint mode ===<br />
<br />
If the endpoint mode is enabled for an interface, this interface will only process packets sent to the configured IP address (and potentially the port). If the system is running in bridge packet processing mode, links with an interface configured for endpoint mode will not forward traffic. The following types of traffic are supported:<br />
<br />
* Ethernet packets encapsulated in GRE or GRE+ERSPAN and targeted for the configured IP address.<br />The system will process the packets as if only the inner encapsulated packet is seen and any traffic captures will only contain the encapsulated packet.<br />
* UDP packets to specific port (packets will be analyzed as is).<br />
<br />
An interface with endpoint mode enabled will respond to ARP requests and to ICMP echo requests so it is possible to use ping to verify that the interface is reachable under the configured IP address.<br />
<br />
It must be noted that if the system is running in bridge packet processing mode, any links with an interface configured for endpoint mode will not forward traffic.<br />
<br />
VLAN tag handling is not supported. The Allegro Network Multimeter will accept ARP and ICMP requests with any VLAN tags but will send replies without VLAN tagging.<br />
<br />
Note: In versions 3.0 or older, the mode was named "l3 tunnel mode".<br />
<br />
=== Webshark support ===<br />
<br />
The Allegro Network Multimeter allows having a preview of packets, directly in the browser. This is the so called Webshark. To support Webshark previewing, the Allegro Network Multimeter needs to reserve an amount of system memory.<br />
<br />
This reserved amount of memory (RAM) is configurable and will not be available for the In-Memory database, thus the history of stored statistics in the dashboard becomes a little shorter. If this is not desired, it is possible to disable the Webshark support.<br />
<br />
Multiple parallel sessions/instances of Webshark previewing within one Allegro Network Multimeter is possible. The number of simultaneous Webshark instances and max. preview file size (e.g. 5MB) are configurable but may vary depending on Allegro model and installed RAM.<br />
<br />
Changing Webshark parameters requires a restart of the processing.<br />
<br />
[[File:Webshark.jpg|900px|Built in Webshark - Allegro Network Multimeter ]]<br />
<br />
=== Detail of traffic analysis ===<br />
<br />
Limit module processing, allows you to configure which OSI-layers (2,3,4,7) are actively processed and analyzed by the Allegro Network Multimeter. With this setting, the performance of the Allegro Network Multimeter can be significantly improved and allows for higher throughput when disabling some analysis modules.<br />
<br />
For both realtime and offline parallel analysis, the following modes are possible :<br />
<br />
* Only capturing: Only interface statistics and the capture module is provided. Capture filters are supported without Layer 7 protocol specification/recognition.<br />
* Capturing and protocol detection: Additionally Layer 7 protocol specification in Capture filters will now work.<br />
* Up to Layer 2: Additionally all Layer 2 related modules are active such as MAC, MAC protocols, ARP and Burst Analysis.<br />
* Up to Layer 3: Additionally all Layer 3 related modules are active such as IP and DHCP statistics.<br />
* Up to Layer 4: Additionally all Layer 4 related modules are active such as TCP and Layer 4 server ports.<br />
* Unlimited: All Allegro Network Multimeter modules are active.<br />
<br />
When switching to another mode you need to restart the processing in order to activate the new settings.<br />
<br />
NOTE: The data recorded to/stored in the Packet Ring buffer, will NOT be affected by any of the above settings. Packet ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter<br />
<br />
==== Enable single flow load balancing ====<br />
When the ''Limit module processing'' slider is turned to ''Only capturing'' the option to enable ''single flow load balancing'' appears. If this option is enabled, even a single flow is load-balanced to different analyzer threads.<br />
<br />
This is only recommended when there are very few flows and there is an imbalance in the load of the analyzers. As the packets of a single flow are processed by different analyzers the packets of the flow may be stored out-of-order in the Packet Ring Buffer and a larger amount of memory may be required to reorder the packets when capturing from the Packet Ring Buffer (see [[Capture module#Configuration settings|Capture module]] configuration settings). <br />
<br />
=== Graph detail settings ===<br />
<br />
It is possible to modify the detail level of all graphs in the interface. This settings allow you to see a more detailed view (with higher time resolution) or to reduce the detail level so more data can be stored on the device. Changing the default values has an impact on the performance and memory usage. Changing a slider to the left increases the detail level of graphs, but increases memory usage and decreases performance.<br />
<br />
* Best graph resolution: This option configures how detailed the graph information are shown in the best case (the latest information). The default value is one second which means that a graph sample point represents a second of packet time. You can change the resolution up to 1 millisecond which gives a detailed sub-second representation of the traffic. You can also decide to decrease the resolution which enables the Allegro Network Multimeter to store more data for a longer period of time.<br />
<br />
* Reduce graph resolution of old data by up to: The resolution of older graph data is automatically reduced to save memory and to allow a longer view into the traffic history. This option allows you to change this behaviour. With a reduction factor of 1/1 no reduction is done at all which means the selected graph resolution is available for the complete time. <br />
:This reduces the time period to see historical data. You can choose to increase the reduction factor to store more data for a longer period. The time printed in parentheses represents the worst-case graph resolution based on the chosen resolution and reduction factor. The reduction is done in multiple steps up to this limit. The newest data always has the highest resolution defined by the "Best graph resolution" setting above. Between 60 and 120 data points are stored at a minimum, so with default resolution of 1 second, between one and two minutes are available in the highest resolution. Due to internal compression, the exact number of data points cannot be foreseen but 60 data points are always available at least, usually much more. Once the limit is reached, data is reduced by a factor of two thus doubling the amount of time available in half resolution (2 to 4 minutes in 2 second resolution). When the next limit is reached, the data is halved again thus doubling the time again, until the configured reduction limit is reached. With default settings of one second resolution and reduction limit of 1/6, the worst resolution of 64 seconds (or 1 minute and 4 seconds) is reached not before 2 hours into the past. The drop down menu in graph view gives an exact number about the available graph resolution in the given time period.<br />
<br />
<br />
Note: Regardless of these settings, the graph values are always converted to represent a value per second (when applicable). For example, the packets per second for an IP addresses will always be a value literally per second even if the resolution is larger or smaller than one second. The displayed value is scaled to match this view. Especially with sub-second resolution this might be misleading.<br />
<br />
For instance, if there is a network element sending one packet per second and the resolution is set to 100 milliseconds, the <u>value shown in the graph</u> might be shown as 10 packets per second as each sample point is scaled to represent an value per second.<br>For a detailed investigation it is recommended to always select a specific time interval and look at the (packet) counters shown in all statistics since these are unscaled and represent the actual values.<br />
<br />
<br />
Performance implications: The performance degradation and memory usage depends on the actual network traffic and is not exactly predictable. <br />
<br />
Here are some examples for reference on a Allegro 1000 series with different configuration values (under ideal test conditions):<br />
<br />
* 1 second resolution, 1/1 reduction factor: 90% of default performance<br />
* 100 millisecond resolution, 1/1 reduction factor: 50% of default performance,<br />
* 10 millisecond resolution, 1/1 reduction factor: 15% of default performance<br />
* 1 millisecond resolution, 1/1 reduction factor: 10% of default performance<br />
<br />
=== PCAP parallel analysis ===<br />
<br />
The PCAP parallel analysis feature allows to analyse PCAP files or the<br />
packet ring buffer in parallel to the live measurement. The settings<br />
allow to enable the feature and choose how much memory of the main<br />
memory is used for parallel analysis and how many parallel slots can<br />
be used. Detailed description of the configuration values are<br />
described [[parallel packet processing|here]].<br />
<br />
== IPFIX settings ==<br />
<br />
The Allegro Network Multimeter may be running as an IPFIX exporter. These settings allows for reporting configuration. When enabled, the following settings are possible:<br />
<br />
* IP address: Address of IPFIX collector.<br />
* Port: Corresponding port.<br />
* Protocol: TCP or UDP.<br />
* Update interval: Interval in seconds for sending a status update of flows.<br />
* UDP resend interval: Interval in seconds for resending IPFIX templates for UDP connections.<br />
* TCP reconnect timeout: When TCP connections could not be established, wait for this time period until the next attempt to establish a connection.<br />
<br />
Individual IPFIX messages can be enabled or disabled by toggling corresponding options. See the NetFlow/IPFIX interface documentation for details about the message types.<br />
<br />
== Time settings ==<br />
<br />
The Allegro Network Multimeter can be configured to use a time synchronization service. NTP is supported for all variants of the Allegro Network Multimeter. PTP service may be used if management interface supports hardware time stamping. If a GPS-capable PTP grandmaster card is available, GPS time synchronization is available and the antenna cable delay in nanoseconds can be configured.<br />
<br />
To enable a time service, switch to the desired type in the dropdown box. The time service field will show whether the selected service is running or not.<br />
<br />
'''NTP''' - For active NTP time retrieval, you can specify and edit dedicated NTP servers the Allegro Network Multimeter should communicate with. If you do not specify a NTP server, a set of predefined NTP servers will be automatically selected. <br />
<br />
'''NTP from data plane''' - For passive time retrieval, NTP from data plane can be used to retrieve the time to be synchronized passively from NTP packets within the traffic that is analyzed. The IP address of a desired NTP server must be set. As soon as a NTP server packet is seen, the system time of the Allegro Network Multimeter will be set. The wait period field can be used to set a time period where subsequent updates are ignored. If set to 0, every time packet of that server will be used. NTP from data plane is ideal in situation where the Allegro Network Multimeter MGT interface can not or may not actively connect to the network. <br />
<br />
'''PTP''' - For PTP time retrieval, the PTP grandmaster clock identity is shown. This is usually an EUI-64 address. The first and last set of octets of the identity represent the (EUI-48) MAC address of the grandmaster.<br />
<br />
The following settings are possible for PTP and should match the settings of the PTP grandmaster:<br />
<br />
* Delay mechanism: Use end-to-end (E2E), peer-to-peer (P2P) or automatic delay measurement. In case automatic measurement is selected, E2E is used at the beginning and switched to P2P when a peer delay request is received. Default is '''Auto'''.<br />
* Network transport: Use UDPv4, UDPv6 or Layer 2 as network transport. Default is '''UDPv4'''.<br />
* Domain number: The domain number of the grandmaster. This is used to define logical groups of synchronized clocks.<br />
<br />
'''GPS''' - The GPS time retrieval option will become available when a GPS capable PTP grandmaster card is installed in the Allegro Network Multimeter. <br />
<br />
If no time synchronization mechanism is selected the date and time of the device can be manually configured by entering a properly formatted date and time description.<br />
Below the time synchronization settings, the time zone used by the device can be configured. The drop-down list provides a list of cities grouped by world regions to select the appropriate time zone.<br />
<br />
When a nanosecond-resolution capture card with support for '''PPS'''-synchronization is installed, the toggle ''Enable PPS synchronization'' can be used to enable this type of synchronization. It is only shown when the time service chosen is not ''GPS'' as those two modes cannot be used simultaneously. The time offset in nanoseconds is also configurable allowing to compensate for the PPS connection cable length. This feature should only be enabled when it is made sure that a proper PPS signal is provided to the network adapter. Otherwise the packet timestamps may be incorrect.<br />
<br />
To make any of the above changes take effect, click on the Save settings button at the bottom of the page. To reload the stored settings, click on Reload settings.<br />
<br />
==Email notification==<br />
<br />
Certain modules support the sending of email notifications. The following settings are used to globally configure the SMTP server used and the target email address that will receive the notifications:<br />
<br />
*Enable email notifications: globally enables or disables the sending of email notifications.<br />
*SMTP server address: the address of the SMTP server that will be used to send notification emails.<br />
*SMTP server port: the TCP port on which the SMTP server is listening.<br />
*SMTP server uses SSL: must be set to On if the SMTP server expects an SSL connection from the very start. If the SMTP server uses no SSL or STARTTLS this setting must be set to Off.<br />
*Ignore certificate errors: if the SSL certificate should not be validated because e.g. it is a self-signed certificate this setting can be used to turn off certificate validation.<br />
*Allow unencrypted connections: if an unencrypted connection must be allowed because e.g. a legacy SMTP server does not support it this setting can be used.<br />
*Username: the username used to log in to the SMTP server.<br />
*Password: the password used to log in to the SMTP server.<br />
*From email address: the email address from which incident notifications will be sent.<br />
*Target email address: the email address to which incident notifications will be sent.<br />
*Email links base URL: this base URL will be used to generate the HTML links in notification emails. Since the device cannot by itself determine the proper address by which it is visible to the email recipient this setting can be used to set the correct URL prefix for links sent with the notification emails.<br />
*Send periodic system status mail: if set to hourly or daily, a periodic system status report email will be sent to the configured target address with the selected frequency. It will contain basic system information and system health status, management interface configuration and a list of detected LLDP neighbours if the management LLDP feature is enabled.<br />
<br />
The Send test email button can be used to verify that the entered settings are working.<br />
<br />
==Memory extension (BETA)==<br />
<br />
See [[Memory extension]] for details about this beta feature.<br />
<br />
== DB persistance (BETA) ==<br />
See [[DB persistence]] for details about this feature.<br />
<br />
==Expert settings==<br />
<br />
The Expert settings contains parameter which are only necessary to change in rare installation scenarios or some specific need for a different operation mode.<br />
<br />
===Packet length accounting===<br />
<br />
This setting allows you to configure which packet length is used for all traffic counters and incidents. The following modes are possible:<br />
<br />
*Layer 1: Packet length is accounted on Layer 1 including preamble (7 Byte), SFD (1 Byte) and inter-frame gap (12 Bytes)<br />
*Layer 2 without frame check sequence (default): Packet length is accounted on Layer 2 without a frame check sequence (4 Bytes)<br />
*Layer 2 with frame check sequence: Account packet length on Layer 2 with frame check sequence (4 Bytes) When switching to another mode, it will only be applied on new packets. Older packet size statistics will not be changed.<br />
<br />
=== VLAN handling ===<br />
<br />
The Allegro Network Multimeter can '''ignore VLAN tags''' for connection tracking. Enabling this option may be necessary if network traffic is seen on the Allegro Network Multimeter that contains changing VLAN tags for the same connection. For example, depending on the configuration of the Mirror Port to which the Allegro Network Multimeter is connected, incoming traffic could contain a VLAN tag while outgoing traffic does not. In this example, a connection would appear twice in the statistics which often is desired behaviour to be able to identify a network misconfiguration. In some cases however, such "duplicate" data in the dashboard may be misleading, and the user would want to see only one connection. In these scenarios the option ignore VLAN tags may be enabled.<br />
<br />
===Tunnel view mode===<br />
<br />
The Allegro Network Multimeter can decapsulate GRE, VXLAN, ERSPAN type II and type III, GENEVE, CAPWAP as well as L2TPv3 data traffic. Depending on this option either the outer tunnel or the inner content is shown in all analysis modules.<br />
<br />
There are three possible modes:<br />
<br />
* don't decapsulate traffic (default)<br />
* decapsulate tunnel traffic, discard non-encapsulated traffic<br />
* decapsulate tunnel traffic, process also non-encapsulated traffic<br />
<br />
Optionally, a filter can be set to limit decapsulation on specific packets with a certain IP address, IP ranges or interfaces. If the filter is empty, all packets will be decapsulated.<br />
<br />
In case the mode is active with discarding non-encapsulated traffic, on the Dashboard a dropped counter will display dropped non-encapsulated packets.<br />
<br />
When capturing, packets with complete outer Layer 2, Layer 3, GRE, ERSPAN, GENEVE, CAPWAP and L2TPv3 headers will be stored as seen on the wire.<br />
<br />
===Database mode settings ===<br />
<br />
The database mode is a special analysis mode for high-performance Allegro Network Multimeters with multiple processors to increase the performance on such systems. It is normally enabled automatically but depending on the actual network traffic and system usage, some parameter tweak might be necessary to improve overall system performance. <br />
You should only change these parameters in discussion with the Allegro Packets support department.<br />
These settings are only visible if your Allegro Network Multimeter is capable of running this mode.<br />
<br />
You can read more about the meaning of the settings [[DB mode|here]].<br />
<br />
===Network performance===<br />
<br />
There are several network performance settings available to improve performance on high-performance systems in case of packet drops during very high incoming bandwidth. They are only visible if your Allegro Network Multimeter is capable of changing these settings.<br />
<br />
*Max RX queues per socket: This setting specifies the quantity of threads dedicated to read and write interactions with the network interface controllers. By increasing this value, network receive bandwidth can be increased before packet drops occur. By decreasing this value, data analysis will improve. The default setting of 2 RX queues is suitable for most configurations since data analysis typically needs much more processing ressources.<br />
*Use Hyper-Threading for RX queues: This setting allows enabling or disabling Hyper-Threading for the threads dedicated to read and write interactions with the network interface controllers. By disabling it, network performance can be improved as the RX queues will be distributed to physical CPU cores only. By enabling it, RX queues will also be distributed to virtual Hyper-Threading CPU cores which is not as efficient as physical CPU cores. By using Hyper-Threading, data analysis will improve since there are more CPU cores available for these tasks. Hyper-Threading is used by default. This is suitable for most configurations as data analysis typically needs much more processing ressources.<br />
*Preferred Network interface controller: This setting allows fine tuning of network and data analysis performance for dedicated network controllers. The selected set of network controllers will be preferred over others. Usually the fastest or the network controller with the most traffic should be preferred. The '''Auto''' setting is used by default, preferring the fastest network controller.<br />
<br />
You should only change these parameters in discussion with the Allegro Packets support department.<br />
<br />
===Processing performance===<br />
<br />
Processing performance may be modified on high-performance systems. This is only visible if your Allegro Network Multimeter is capable of changing this setting.<br />
<br />
* Processing performance mode: This setting allows for fine tuning processing performance. By using '''Analysing''', as much processing ressources on all CPUs as possible are used for data analysis. By using '''Capturing''', the focus will be on high data throughput and low latency for capturing purposes by using only the CPU where the preferred network controller is attached to. This has an impact on data analysis performance. '''Analysing''' is used by default.<br />
You should only change this parameter in discussion with the Allegro Packets support department.<br />
<br />
===Packet ring buffer timeouts===<br />
<br />
Two timeout settings related to the packet ring buffer can be adjusted.<br />
<br />
*'''Long timeout''' controls after which maximum amount of time, a packet is actually written to the packet ring buffer. A lower value may decrease the time difference by which packets are stored out of their order in the packet ring buffer but it may increase the amount of unused overhead data in the packet ring buffer.<br />
*'''Short timeout''' controls after which amount of time smaller batches of packets are written to the packet ring buffer, even if waiting for more packets would result in a more efficient operation. A lower value may decrease the time difference by which packets are stored out of their order in the packet ring buffer, but it may also decrease the performance of the packet ring buffer.<br />
<br />
===Data retention timeout===<br />
<br />
When the data retention timeout is set to a value greater than 0, data will be removed everywhere throughout the system after the given number of minutes. This means that entities like IPs, which have been inactive for longer than the timeout, will be removed. History graph data for entities that are still active will be truncated to cover only the given timespan, while the absolute values for the whole runtime will be retained. When a packet ring buffer is active, packets which are older than the timeout will be discarded.<br />
<br />
===Multithreaded capture analysis===<br />
<br />
This option enables the use of multiple CPUs for capture analysis like when<br />
analyzing a pcap capture file or analyzing the packet ring buffer. Depending<br />
on the number of available CPUs this can significantly speed up the analysis.<br />
<br />
It is possible to dedicate a number of CPUs exclusively to capture analysis.<br />
Since these CPUs are not available for live packet processing the performance of<br />
live traffic analysis may be lower.<br />
When set to 0 a lower priority is used for capture analysis than for live analysis<br />
but it cannot be ruled out that the performance of the live processing is<br />
affected.<br />
<br />
===Load balancing===<br />
<br />
This option select the load distribution method. By default, network<br />
traffic is balanced among all processing threads based on the IP<br />
addresses. This is fast and usually the best way for efficient load<br />
balancing.<br />
<br />
If the network traffic only occurs between a few IP addresses, this<br />
method can lead to a load imbalance so that some threads are doing more<br />
work while other threads may be idle. In this scenario, "flow based<br />
balancing" can be enabled to distribute the traffic based on the IP<br />
and port information. This will lead to better utilization of all<br />
processing threads.<br />
<br />
Since this option induces additional processing overhead per packet<br />
and additional memory for all internal IP statistics, it should only<br />
be enabled in cases of significant load imbalance.<br />
<br />
===Ingress packet memory===<br />
<br />
This slider allows to configure the amount of memory which is used to buffer received packets. A larger amount of ingress packet memory may help in processing bursts of high bandwidth traffic without packet drops but it also decreases the amount of memory available for statistics. It is important to know that a restart of the processing does not suffice to make changes to this setting active. A full reboot of the device is required for that. See [[Performance Optimization Guide]].<br />
<br />
=== Jumbo frame mode ===<br />
This options allows to set how jumbo frames are handled by the system.<br />
<br />
Three settings are available and the '''normal''' mode, which is also the default, is the mode that was used before this configuration option was introduced:<br />
<br />
* '''Normal''': the default mode offers the best balance of full support for jumbo frames with an efficient usage of the ingress packet memory. This mode uses efficiently sized packet buffers and splits larger packets over multiple packet buffers.<br />
* '''Large buffers''': this mode uses a single large buffer for each packet which may improve the performance but does not use the ingress packet memory as efficiently and limits the maximum jumbo frame size to 9kB.<br />
* '''Disabled''': this mode disables support for jumbo frames and offers the best performance and efficient usage of the ingress packet memory. Jumbo frames will be discarded by the network interface.<br />
<br />
=== Hardware packet timestamping ===<br />
This option allows to enable the use of high-precision hardware packet timestamps on supported interfaces (quad 25G and dual 100G expansion).<br />
<br />
This feature will require approximately 30% more load in the I/O threads. The load increase can be reduced to about 10% by using the jumbo frame mode "Large buffers" or "Disabled".<br />
<br />
When enabled, packets received on supported interfaces will carry a timestamp with nanosecond resolution instead of microsecond resolution.<br />
<br />
=== External timestamps ===<br />
When this option is enabled, the system will use timestamps contained in the packet data instead of timestamps measured at packet arrival. Currently the Arista and Ixia/Keysight timestamp formats are supported. If this option is enabled, packets without an external timestamp will not be analyzed. The current number of packets that are dropped because they do not contain an external timestamp is displayed in the active interface overview table of the top-user dashboard. If there are no packets with external timestamps arriving the time of the packet processing will effectively stand still and most graphs will not make progress in live-mode.<br />
<br />
=== External original packet lengths ===<br />
This option allows to enable the use of original packet length information contained in the packet data instead of the length of the packet as received. At this time only the Ixia/Keysight original packet length trailer format is supported.<br />
<br />
This feature can also be used in combination with the ''External timestamps'' option to support packets that contain a Ixia/Keysight trailer with both timestamp and original length information.<br />
<br />
=== Memory utilization limit ===<br />
This option allows to reduce the limit until old data is removed from the in-memory database. By default the system tries to target 90% memory utilization. In some case, the load might be too high to match this limit. A smaller limit may enable the system to keep the target memory utilization and perform better in general.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=List_of_Supported_Transceiver_Modules&diff=4505List of Supported Transceiver Modules2023-11-24T09:09:03Z<p>Ralf: /* Non-working modules */</p>
<hr />
<div>== DISCLAIMER ==<br />
<br />
Allegro Packets allows you to use third-party vendor modules in its appliances but guarantees only warranty and support for transceiver modules sold by Allegro Packets. Any malfunction or configuration issue with third-party modules are NOT covered by the warranty.<br />
<br />
Allegro Packets does not restrict the use of third-party SFP+ modules for the devices. However, some hardware limitations apply which are described as follows:<br />
<br />
== Built-in ports vs. expansion cards ==<br />
<br />
The Allegro Network Multimeter 800/1000/1200/3000/3200/x310/x410 series have two on-board SFP+ ports which are restricted to original or branded '''Intel modules'''.<br />
<br />
All non built-in ports are '''not''' vendor locked and can accept all transceiver modules. However, there are modules that do not work because of specific vendor extensions within the modules. This applies for all ports of the Allegro Network Multimeter x300,x310, x400, x410, x500 and x510 series and all expansion cards for the Allegro Network Multimeter 1000/1200/3000/3200.<br />
<br />
The following table shows which kind of modules are supported by Allegro by<br />
port type:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Port type !!original or branded Intel modules !! non-Intel branded modules <br />
|- <br />
| built-in SFP+ ports || x || -<br />
|-<br />
| SFP+ expansion|| x || x<br />
|-<br />
| SFP28 expansion|| x || x<br />
|-<br />
| QSFP expansion|| x|| x<br />
|-<br />
| QSFP28 expansion|| x || x<br />
|-<br />
|}<br />
<br />
The use of Intel branded modules is mandatory for the built-in SFP+ ports. These<br />
restrictions do not apply to the additional network expansion cards<br />
(2 port and 4 port SFP+, high precision GPS card, etc.) that are available for<br />
the Allegro Network Multimeter 1000 and 3000 series. These ports accept<br />
generic modules from a wide range of vendors.<br />
<br />
Since auto-negotiation is often not available on 1G/10G SFP+ interfaces, it<br />
may be necessary to manually set the correct speed in the `Interface Stats`<br />
section of the user interface.<br />
<br />
QSFP+ breakout cables are NOT supported.<br />
<br />
== List of tested third-party modules ==<br />
<br />
The following list of modules have been either tested by Allegro Packets or customers and have been reported to operate. Please be aware that this can change due new module revisions. <br />
<br />
{| class="wikitable"<br />
|-<br />
! Optics/Copper Module !! Transceiver P/N !! Media Type <br />
!Connector<br />
!Speed!! Remarks<br />
|-<br />
|SFP<br />
|Flexoptix T.C12.02.A<br />
|Copper<br />
| RJ45<br />
|10/100/1000M<br />
|requires Intel branding<br />
|-<br />
|SFP<br />
|Finisar FCLF8521P2BTL<br />
|Copper<br />
|RJ45<br />
|10/100/1000M<br />
|not supported in builtin ports in model 1000/1200/3000/3200, only in expansion slots, <br />
|-<br />
|SFP<br />
|Flexoptix S.1312.10.D<br />
|Fiber (LR)<br />
|LC<br />
|1G<br />
|not supported in onboard Allegro 1000/1200/3000/3200 SFP+ ports<br />
supported in Allegro 800 and any SFP+ expansion card<br />
|-<br />
|SFP<br />
|Flexoptix S.8512.02.D<br />
|Fiber (SR)<br />
|LC<br />
|1G<br />
|not supported in onboard Allegro 1000/1200/3000/3200 SFP+ ports<br />
supported in Allegro 800 and any SFP+ expansion card<br />
|-<br />
|SFP<br />
|Flexoptix S.B1312.10.DL<br />
Flexoptix S.B1512.10.DL<br />
|Fiber (LR, BiDi)<br />
|LC<br />
|1G<br />
|not supported in onboard Allegro 1000/1200/3000/3200 SFP+ ports<br />
<br />
supported in Allegro 800 and any SFP+ expansion card<br />
<br />
requires Intel branding<br />
|-<br />
| SFP+ || Intel E10GSFPSR || Fiber (SR)<br />
| <br />
|1G/10G|| <br />
|-<br />
| SFP+ || Intel E10GSFPLR || Fiber (LR)<br />
| <br />
|1G/10G|| <br />
|-<br />
| SFP+ || Intel XDACBL1M, XDACBL3M or XDACBL5M|| DA(Copper, Passive)<br />
| -<br />
| 10G<br />
|<br />
|-<br />
| SFP+ || Flexoptix P.8596.02 || Fiber (SR)<br />
|LC<br />
|1G/10G|| requires Intel branding<br />
|-<br />
| SFP+ || Flexoptix P.1396.10 || Fiber (LR)<br />
|LC<br />
|1G/10G|| requires Intel branding<br />
|-<br />
| SFP+ || fs.com 36431 || Fiber (SR)<br />
|LC<br />
|10G|| requires Intel branding, supports only 10G operation, 1G does NOT work<br />
|-<br />
| SFP+ || fs.com 36432 || Fiber (LR)<br />
|LC<br />
|10G|| requires Intel branding, supports only 10G operation, 1G does NOT work<br />
|-<br />
| SFP28 || Flexoptix P.8525G.01 || Fiber (SR)<br />
|LC<br />
|25G|| recommended with Intel branding<br />
|-<br />
| SFP28 || Flexoptix P.1325G.10 || Fiber (LR)<br />
|LC<br />
|25G|| recommended with Intel branding<br />
|-<br />
| SFP28 || fs.com 68000 || Fiber (SR)<br />
|LC<br />
|25G|| requires Intel branding<br />
|-<br />
| QSFP+ || Flexoptix Q.8540G.02 || Fiber (SR4)<br />
|MPO<br />
|40G|| recommended with Intel branding<br />
|-<br />
| QSFP+ || Flexoptix Q.1640G.10 || Fiber (LR4)<br />
|LC<br />
|40G|| recommended with Intel branding<br />
|-<br />
| QSFP+ || FINISAR FTL4C1QE1C || Fiber (LR4)<br />
| <br />
|40G||<br />
|-<br />
| QSFP+ || FINISAR FTL410QD2C || Fiber (SR4)<br />
| <br />
|40G||<br />
|-<br />
| QSFP+ || FINISAR FTL410QE1C || Fiber (SR4)<br />
| <br />
|40G||<br />
|-<br />
| QSFP+ || FINISAR FTL410QE2C || Fiber (SR4)<br />
| <br />
|40G||<br />
|-<br />
| QSFP+ || FINISAR FTL410QE3C || Fiber (SR4)<br />
| <br />
|40G||<br />
|-<br />
| QSFP+ || Amphenol 603020002, 603020005 || DA(Copper, Passive)<br />
| -<br />
|40G||<br />
|-<br />
| QSFP+ || fs.com 36281 || Fiber (SR4)<br />
|MPO<br />
|40G|| requires Intel branding<br />
|-<br />
| QSFP28 || Flexoptix Q.851HG.02 || Fiber (SR4)<br />
|MPO<br />
|100G||<br />
|-<br />
| QSFP28 || Flexoptix Q.161HG.10 || Fiber (LR4)<br />
|LC<br />
|100G||<br />
|-<br />
| QSFP28 || fs.com 75308 || Fiber (SR4)<br />
|MPO<br />
|100G|| <br />
|-<br />
| QSFP28 || Cisco QSFP-100G-CU (1M, 2M, 3M, 5M) || DA(Copper, Passive)<br />
| -<br />
|100G|| <br />
|}<br />
<br />
== Non-working modules ==<br />
<br />
Original Cisco modules have many issues working in the Allegro Network Multimeter. Allegro Packets got the feedback from multiple customers that they have issues with Cisco modules.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Optics/Copper Module !! Transceiver P/N !! Media Type !! Remarks<br />
|-<br />
| QSFP+ 40G SR BG || Cisco qsfp-40g-sr-bg P/N: 191402 || Fiber (SR4) || only partial support, modules must be (re-) inserted after power up<br />
|-<br />
| QSFP+ 40G SR4 || Cisco qsfp-40g-sr4 P/N: 186602 || Fiber (SR4) || only partial support, modules must be (re-) inserted after power up<br />
|-<br />
| QSFP+ 40G AOC || Cisco qsfp-h40g-aoc10m P/N: 187627 || Fiber (SR) || only partial support, modules must be (re-) inserted after power up<br />
|-<br />
| QSFP+ 40/100 SRBD || Cisco qsfp-40/100-srbd P/N: 199804 || Fiber (SR) || does '''NOT''' work<br />
|-<br />
| QSFP28 || Cisco QSFP-100G-SM-SR || Fiber (LR4 lite) || may work<br />
|-<br />
|QSFP28<br />
|Innolight QSFP28 MSA LR4 P/N: TR-FC13R-N00<br />
|Fiber (LR4)<br />
|does '''NOT''' work<br />
|}<br />
<br />
== Link status issues with different network equipment ==<br />
<br />
=== Problem: 1G link is not coming up with 1G/10G SFP+ fiber modules ===<br />
There is a known incompatibility with our 1G/10G SFP+ fiber modules when used with some Cisco equipment, such as a Cisco Nexus or Catalyst switch with 1G connectivity.<br />
<br />
The solution is as follows:<br />
<br />
* Disable auto-negotiation for the Cisco switch port which is connected to the Allegro device.<br />
* Manually set speed to 1G for the Cisco switch port<br />
<br />
Example configuration for Nexus:<br />
configure terminal<br />
interface ethernet x/yy<br />
speed 1000<br />
no negotiate auto<br />
Actual commands depends on the Cisco model. Alternative commands are:<br />
speed nonegotiates<br />
set port speed 1000<br />
Combinations known to work for 1G connectivity:<br />
<br />
* Our 1G/10G SFP+ SR module in an Allegro SFP port (article number 700)<br />
* Cisco GLC-SX-MMD in a Cisco switch<br />
* Cisco switch settings applied as described above</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Virtual_Link_Group_functionality&diff=4473Virtual Link Group functionality2023-09-29T13:26:35Z<p>Ralf: /* Usage */</p>
<hr />
<div>The Allegro Network Multimeter allows for defining up to '''100''' so called Virtual Link Groups (VLG) to logically separate traffic for easier analysis. <br />
<br />
__TOC__<br />
<br />
== Usage ==<br />
All statistics data for each Virtual Link Group (VLG) are strictly separated. Once at least one VLG is defined, a drop-down menu appears at the top menu bar allowing to select which VLG should be chosen for the displayed statistics.<br />
<br />
Packet capture also takes the VLG into account so when capturing a specific IP for example, the system only returns packets for that IP in the currently selected VLG. Expert capture filters still allows to use multiple VLG filter for a single capture or disable the VLG filter at all (by not using the 'group' filter).<br />
<br />
Statistics for a VLG can also be reset independently from other VLGs (since firmware version 4.2). The drop-down menu contains an eraser-like button to reset the measurement statistics for that VLG. Currently this reset feature is limited to some measurement modules only (IP).<br />
[[File:Vlg selector.png|none|thumb|713x713px]]<br />
<br />
== Configuration ==<br />
<br />
{| class="wikitable"<br />
|-<br />
| <br />
[[File:Virtual Link Group functionality.png|800px|none]]<br />
|}<br />
<br />
The groups can be selected in the web interface in the top menu bar. The configuration can be performed in the settings section.<br />
<br />
The following criteria can be used for defining groups:<br />
<br />
* Interface IDs<br />
* VLAN tags<br />
* MPLS labels<br />
* ERSPAN ID<br />
* VXLAN VNI<br />
* WiFi BSS<br />
<br />
In case of VXLAN, please make sure that Tunnel View Mode is active. Only in this mode VXLANs are analysed and its VNI can be used for VLGs.<br />
<br />
{| class="wikitable"<br />
|-<br />
| <br />
[[File:Virtual Link Group functionality_1.png|200px|none]]<br />
|[[File:Virtual Link Group functionality_2.png|200px|none]]<br />
|[[File:Virtual Link Group functionality_3.png|200px|none]]<br />
|[[File:Virtual Link Group functionality_4.png|200px|none]]<br />
|-<br />
|Interface IDs<br />
|VLAN tags<br />
|MPLS labels<br />
|ERSPAN ID<br />
|}<br />
<br />
A group can contain several entries of the same criterion that form an '''OR''' connection. Different criteria form an '''AND''' connection. E.g. it is possible to define a group with interface '''id 3''' or '''id 4''' and '''VLAN tag 400'''. Don’t forget to push the add button when configuring entries of a criterion.<br />
<br />
A group can be set active or inactive.<br />
<br />
It is also possible to limit the detail of traffic analysis for each group individually. Similar to the [[Global settings]] it allows to let one group be analysed only to layer 3, for example, and for another group full analysis is done. This will improve performance and increase the data storage time.<br />
<br />
The group definition can be exported and imported via in a CSV file by using the "Download CSV" and "Import CSV buttons in the settings page".<br />
<br />
Once a group is defined or changed it will be applied on new packets only. Older packets will not be grouped into a new group. To avoid confusion, it is recommended to restart the processing (see [[Settings]]).<br />
<br />
A packet can only be part of one group. It will be grouped into the first group whose definition matches. The grouping will be applied in the same order as shown in the group list in the web interface. You can use the up and down buttons in the settings section to change that order.<br />
<br />
All statistics in the Allegro Network Multimeter will show information related to the selected group only. Interface graphs, total traffic graph on the dashboard and the burst analysis module will, however, show global information and ignore the group selection.<br />
<br />
=== Traffic color settings === <br />
<br />
A group can be configured so that all traffic counters are displayed in a utilization color. <br />
<br />
Traffic values below medium will be displayed in '''green''', values above medium will be displayed in '''yellow''' and value above high will be displayed in '''red'''. <br />
<br />
{| class="wikitable"<br />
|-<br />
| [[File:Virtual Link Group functionality2.png|800px|none]]<br />
|}<br />
<br />
The thresholds for medium and high can be configured in '''Mbit/s'''.<br />
<br />
The default settings are<br />
* medium 800 Mbit/s<br />
* high 950 Mbit/s<br />
<br />
{| class="wikitable"<br />
|-<br />
|[[File:Virtual Link Group functionality3.png|600px|none]]<br />
|}<br />
<br />
=== Detail of traffic analysis ===<br />
Each virtual link group can limit the detail of traffic analysis to a specific network layer. Reducing the detail will improve overall performance and increase the history time. In contrast to the [[Global settings]] for the detail of traffic analysis, this option still allows for some groups to show more detailed information while for other only limited data is available.<br />
<br />
'''NOTE:''' The configuration can be changed during runtime, but it is recommended to do a processing restart so statistics for already running connections are not mixed between different groups and processing modes.<br />
[[File:Virtual Link Group functionality processing mode.png|none|Virtual Link Group functionality processing mode|thumb|545x545px]]<br />
<br />
=== Statistics timeout ===<br />
Since firmware 4.2, the age of the measurement statistics can be configured individually for each Virtual Link Group separately.<br />
<br />
The configuration dialog allows to enter an arbitrary duration for which the data should be stored. The value can be in plain seconds, or with d/h/m suffixes also in days (d), hours (h), or minutes (m).<br />
<br />
The global timeout is used if no value is entered (or zero). Data can also not be older than the global timeout.<br />
[[File:Virtual Link Group functionality statistics timeout.png|none|Virtual Link Group functionality statistics timeout|thumb|545x545px]]</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Virtual_Link_Group_functionality&diff=4472Virtual Link Group functionality2023-09-29T13:24:26Z<p>Ralf: /* Statistics timeout */</p>
<hr />
<div>The Allegro Network Multimeter allows for defining up to '''100''' so called Virtual Link Groups (VLG) to logically separate traffic for easier analysis. <br />
<br />
__TOC__<br />
<br />
== Usage ==<br />
All statistics data for each Virtual Link Group (VLG) are strictly separated. Once at least one VLG is defined, a drop-down menu appears at the top menu bar allowing to select which VLG should be chosen for the displayed statistics.<br />
<br />
Packet capture also takes the VLG into account so when capturing a specific IP for example, the system only returns packets for that IP in the currently selected VLG. Expert capture filters still allows to use multiple VLG filter for a single capture or disable the VLG filter at all (by not using the 'group' filter).<br />
<br />
Statistics for a VLG can also be reset independently from other VLGs (since firmware version 4.2). The drop-down menu contains an eraser-like button to reset the measurement statistics for that VLG. Currently this reset feature is limited to some measurement modules only (IP).<br />
<br />
== Configuration ==<br />
<br />
{| class="wikitable"<br />
|-<br />
| <br />
[[File:Virtual Link Group functionality.png|800px|none]]<br />
|}<br />
<br />
The groups can be selected in the web interface in the top menu bar. The configuration can be performed in the settings section.<br />
<br />
The following criteria can be used for defining groups:<br />
<br />
* Interface IDs<br />
* VLAN tags<br />
* MPLS labels<br />
* ERSPAN ID<br />
* VXLAN VNI<br />
* WiFi BSS<br />
<br />
In case of VXLAN, please make sure that Tunnel View Mode is active. Only in this mode VXLANs are analysed and its VNI can be used for VLGs.<br />
<br />
{| class="wikitable"<br />
|-<br />
| <br />
[[File:Virtual Link Group functionality_1.png|200px|none]]<br />
|[[File:Virtual Link Group functionality_2.png|200px|none]]<br />
|[[File:Virtual Link Group functionality_3.png|200px|none]]<br />
|[[File:Virtual Link Group functionality_4.png|200px|none]]<br />
|-<br />
|Interface IDs<br />
|VLAN tags<br />
|MPLS labels<br />
|ERSPAN ID<br />
|}<br />
<br />
A group can contain several entries of the same criterion that form an '''OR''' connection. Different criteria form an '''AND''' connection. E.g. it is possible to define a group with interface '''id 3''' or '''id 4''' and '''VLAN tag 400'''. Don’t forget to push the add button when configuring entries of a criterion.<br />
<br />
A group can be set active or inactive.<br />
<br />
It is also possible to limit the detail of traffic analysis for each group individually. Similar to the [[Global settings]] it allows to let one group be analysed only to layer 3, for example, and for another group full analysis is done. This will improve performance and increase the data storage time.<br />
<br />
The group definition can be exported and imported via in a CSV file by using the "Download CSV" and "Import CSV buttons in the settings page".<br />
<br />
Once a group is defined or changed it will be applied on new packets only. Older packets will not be grouped into a new group. To avoid confusion, it is recommended to restart the processing (see [[Settings]]).<br />
<br />
A packet can only be part of one group. It will be grouped into the first group whose definition matches. The grouping will be applied in the same order as shown in the group list in the web interface. You can use the up and down buttons in the settings section to change that order.<br />
<br />
All statistics in the Allegro Network Multimeter will show information related to the selected group only. Interface graphs, total traffic graph on the dashboard and the burst analysis module will, however, show global information and ignore the group selection.<br />
<br />
=== Traffic color settings === <br />
<br />
A group can be configured so that all traffic counters are displayed in a utilization color. <br />
<br />
Traffic values below medium will be displayed in '''green''', values above medium will be displayed in '''yellow''' and value above high will be displayed in '''red'''. <br />
<br />
{| class="wikitable"<br />
|-<br />
| [[File:Virtual Link Group functionality2.png|800px|none]]<br />
|}<br />
<br />
The thresholds for medium and high can be configured in '''Mbit/s'''.<br />
<br />
The default settings are<br />
* medium 800 Mbit/s<br />
* high 950 Mbit/s<br />
<br />
{| class="wikitable"<br />
|-<br />
|[[File:Virtual Link Group functionality3.png|600px|none]]<br />
|}<br />
<br />
=== Detail of traffic analysis ===<br />
Each virtual link group can limit the detail of traffic analysis to a specific network layer. Reducing the detail will improve overall performance and increase the history time. In contrast to the [[Global settings]] for the detail of traffic analysis, this option still allows for some groups to show more detailed information while for other only limited data is available.<br />
<br />
'''NOTE:''' The configuration can be changed during runtime, but it is recommended to do a processing restart so statistics for already running connections are not mixed between different groups and processing modes.<br />
[[File:Virtual Link Group functionality processing mode.png|none|Virtual Link Group functionality processing mode|thumb|545x545px]]<br />
<br />
=== Statistics timeout ===<br />
Since firmware 4.2, the age of the measurement statistics can be configured individually for each Virtual Link Group separately.<br />
<br />
The configuration dialog allows to enter an arbitrary duration for which the data should be stored. The value can be in plain seconds, or with d/h/m suffixes also in days (d), hours (h), or minutes (m).<br />
<br />
The global timeout is used if no value is entered (or zero). Data can also not be older than the global timeout.<br />
[[File:Virtual Link Group functionality statistics timeout.png|none|Virtual Link Group functionality statistics timeout|thumb|545x545px]]</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Virtual_Link_Group_functionality&diff=4462Virtual Link Group functionality2023-09-29T07:43:26Z<p>Ralf: /* Detail of traffic analysis */</p>
<hr />
<div>The Allegro Network Multimeter allows for defining up to '''100''' so called Virtual Link Groups (VLG) to logically separate traffic for easier analysis. <br />
<br />
__TOC__<br />
<br />
== Usage ==<br />
All statistics data for each Virtual Link Group (VLG) are strictly separated. Once at least one VLG is defined, a drop-down menu appears at the top menu bar allowing to select which VLG should be chosen for the displayed statistics.<br />
<br />
Packet capture also takes the VLG into account so when capturing a specific IP for example, the system only returns packets for that IP in the currently selected VLG. Expert capture filters still allows to use multiple VLG filter for a single capture or disable the VLG filter at all (by not using the 'group' filter).<br />
<br />
Statistics for a VLG can also be reset independently from other VLGs (since firmware version 4.2). The drop-down menu contains an eraser-like button to reset the measurement statistics for that VLG. Currently this reset feature is limited to some measurement modules only (IP).<br />
<br />
== Configuration ==<br />
<br />
{| class="wikitable"<br />
|-<br />
| <br />
[[File:Virtual Link Group functionality.png|800px|none]]<br />
|}<br />
<br />
The groups can be selected in the web interface in the top menu bar. The configuration can be performed in the settings section.<br />
<br />
The following criteria can be used for defining groups:<br />
<br />
* Interface IDs<br />
* VLAN tags<br />
* MPLS labels<br />
* ERSPAN ID<br />
* VXLAN VNI<br />
* WiFi BSS<br />
<br />
In case of VXLAN, please make sure that Tunnel View Mode is active. Only in this mode VXLANs are analysed and its VNI can be used for VLGs.<br />
<br />
{| class="wikitable"<br />
|-<br />
| <br />
[[File:Virtual Link Group functionality_1.png|200px|none]]<br />
|[[File:Virtual Link Group functionality_2.png|200px|none]]<br />
|[[File:Virtual Link Group functionality_3.png|200px|none]]<br />
|[[File:Virtual Link Group functionality_4.png|200px|none]]<br />
|-<br />
|Interface IDs<br />
|VLAN tags<br />
|MPLS labels<br />
|ERSPAN ID<br />
|}<br />
<br />
A group can contain several entries of the same criterion that form an '''OR''' connection. Different criteria form an '''AND''' connection. E.g. it is possible to define a group with interface '''id 3''' or '''id 4''' and '''VLAN tag 400'''. Don’t forget to push the add button when configuring entries of a criterion.<br />
<br />
A group can be set active or inactive.<br />
<br />
It is also possible to limit the detail of traffic analysis for each group individually. Similar to the [[Global settings]] it allows to let one group be analysed only to layer 3, for example, and for another group full analysis is done. This will improve performance and increase the data storage time.<br />
<br />
The group definition can be exported and imported via in a CSV file by using the "Download CSV" and "Import CSV buttons in the settings page".<br />
<br />
Once a group is defined or changed it will be applied on new packets only. Older packets will not be grouped into a new group. To avoid confusion, it is recommended to restart the processing (see [[Settings]]).<br />
<br />
A packet can only be part of one group. It will be grouped into the first group whose definition matches. The grouping will be applied in the same order as shown in the group list in the web interface. You can use the up and down buttons in the settings section to change that order.<br />
<br />
All statistics in the Allegro Network Multimeter will show information related to the selected group only. Interface graphs, total traffic graph on the dashboard and the burst analysis module will, however, show global information and ignore the group selection.<br />
<br />
=== Traffic color settings === <br />
<br />
A group can be configured so that all traffic counters are displayed in a utilization color. <br />
<br />
Traffic values below medium will be displayed in '''green''', values above medium will be displayed in '''yellow''' and value above high will be displayed in '''red'''. <br />
<br />
{| class="wikitable"<br />
|-<br />
| [[File:Virtual Link Group functionality2.png|800px|none]]<br />
|}<br />
<br />
The thresholds for medium and high can be configured in '''Mbit/s'''.<br />
<br />
The default settings are<br />
* medium 800 Mbit/s<br />
* high 950 Mbit/s<br />
<br />
{| class="wikitable"<br />
|-<br />
|[[File:Virtual Link Group functionality3.png|600px|none]]<br />
|}<br />
<br />
=== Detail of traffic analysis ===<br />
Each virtual link group can limit the detail of traffic analysis to a specific network layer. Reducing the detail will improve overall performance and increase the history time. In contrast to the [[Global settings]] for the detail of traffic analysis, this option still allows for some groups to show more detailed information while for other only limited data is available.<br />
<br />
'''NOTE:''' The configuration can be changed during runtime, but it is recommended to do a processing restart so statistics for already running connections are not mixed between different groups and processing modes.<br />
[[File:Virtual Link Group functionality processing mode.png|none|Virtual Link Group functionality processing mode|thumb|545x545px]]<br />
<br />
=== Statistics timeout ===<br />
Since firmware 4.2, the age of the measurement statistics can be configured individually for each Virtual Link Group separately.<br />
<br />
The configuration dialog allows to enter an arbitrary duration for which the data should be stored. The value can be in plain seconds, or with d/h/m suffixes also in days (d), hours (h), or minutes (m).<br />
<br />
The global timeout is used if no value is entered (or zero). Data can also not be older than the global timeout.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Capturing&diff=4457Capturing2023-09-12T13:58:22Z<p>Ralf: /* How can I extract traffic from the past? */</p>
<hr />
<div>== Introduction ==<br />
With the Allegro Network Multimeter it is very easy to start and retrieve very specific network packet captures in pcap format.<br>Such pre-filtered pcap files, can then easily be investigated with Allegro Network Multimeter's built in Webshark or a tool like Wireshark.<br />
<br />
== How can I create a pcap of a specific IP or MAC address? ==<br />
All Allegro Network Multimeter L2-L7 analysis modules, feature dedicated pcap buttons throughout the dashboard,<br />
to <u>very specifically</u> capture most traffic types in a really easy way.<br />
<br />
For example; to capture a specific IP address, in the left menu navigate to 'L3 - IP' -> 'IP' statistics.<br><br />
Then, easily find the desired IP address by sorting and/or a filtered search, and clicking the capture button - [[File:Capture button.png]].<br />
<br />
When a specific time interval is displayed in the dashboard, only the payload during that time interval is extracted.<br />
[[File:IP pcap.png|none|thumb|800x800px|alt=]] <br />
<br />
To quickly find an IP address, you can sort the IP table via almost every column. The search bar/filter bar provides a quick method to reduce the table content to your hearts content.<br>This can be done by typing in (fragments of) the<br />
IP address, (fragments of) the DNS name or by entering a "complex" filter. <br />
<br />
[[File:Search bar.png|1100px|thumb|alt=|none]]<br />
<br />
<br />
<br />
Another quick way to create a pcap of a specific address, is to use Allegro Network Multimeter's Simple Capture feature.<br />
<br />
In the menu go to 'Generic' -> 'Capture traffic'. Now, in the "start simple capture" section, toggle the desired capture fields (e.g. MAC, IP), type the address, and click the "Start capture" button.<br />
<br />
[[File:Ap-mm-capture-capture-simple.png|600px|thumb|alt=|none]]<br />
<br />
== Which settings should I choose? ==<br />
<br />
After clicking on the capture button, the dialogue "Choose capture settings" will be<br />
displayed. Here you can limit the start and end time of the capture and select<br />
whether to download the pcap file directly to your<br />
computer or store it on the Allegro Network Multimeter attached storage device. You can<br />
limit the captured packets to a given length if you do not need the full packet<br />
and just want a small pcap file that opens faster in Wireshark.<br />
[[File:Choose capture settings.png|none|thumb|600x600px]]<br />
<br />
Clicking the "Save capture" button begins the configured capture.<br />
<br />
Clicking on the "Webshark preview" will open a basis web-based Wireshark window within the Allegro Network Multimeter web interface.<br />
<br />
A fully detailed explanation of the "Choose Capture Settings" dialog is documented in our Wiki here: [[Capture module#Capture settings dialog]]<br />
<br />
== How can I extract traffic from the past? ==<br />
<br />
With the Allegro Network Multimeter packet ring buffer, it is possible to extract traffic from the past as a pcap file. The packet ring buffer is stored on the internal storage device of an Allegro Network Multimeter (if your model is equipped with one), or on an externally attached USB storage device. A fast USB3.x capable SSD is recommended. A USB thumb drive can also be used, but some burst packets may be dropped if the thumb drive write speed is too slow.<br />
<br />
You can see an overview about all storage devices that can be used for the Allegro Network Multimeter under 'Generic' -> 'Storage'.<br />
{| <br />
| [[File:Ap-mm-capture-storage.png|600px|thumb|right]]<br />
|}<br />
<br />
An external SSD is attached to the USB port and is not yet activated. Click the<br />
"Activate" button so the device can be used. If the filesystem of the disk is not<br />
suitable for the ring buffer a warning will pop up prompting you to format the disk.<br />
After formatting or activating, the storage page will display information<br />
on disk usage and an overview of all files on the disk.<br />
<br />
{| <br />
| [[File:Ap-mm-capture-storage-active.png|600px|thumb|right]]<br />
|}<br />
<br />
Now that the storage is active, the ring buffer has to be created if not already<br />
prepared during formatting. This can be achieved in 'Generic' -> 'Packet ring buffer'.<br />
Click the "Create ring buffer" button.<br />
<br />
{| <br />
| [[File:Ap-mm-capture-create-ring-buffer.png|600px|thumb|right]]<br />
|}<br />
<br />
The size of the ring buffer must be specified. If no pcap is required on<br />
the storage device, the ring buffer will use 100% of the storage device capacity.<br />
<br />
{| <br />
|[[File:Ap-mm-capture-ring-buffer-size.png|600px|thumb|right]]<br />
|}<br />
<br />
When the packet ring buffer is created and running, the "Packet ring buffer"<br />
statistics page displays information about the ring buffer usage and several<br />
graphs restored or filtered traffic are also displayed. A filter can be applied<br />
to determine which packets are stored in the ring buffer. Check out the chapter [[Packet ring buffer]] for more details.<br />
<br />
{| <br />
| <br />
[[File:Ap-mm-capture-ring-buffer-statistics.png|600px|thumb|right]]<br />
|}<br />
<br />
When the packet ring buffer is up and running, any capture may be utilized to<br />
extract traffic from the past. Select a timespan in any graph of the user interface<br />
by left-clicking with the mouse and then click a pcap button.<br />
The selected timespan will be displayed in the start and end time fields of the<br />
"Choose capture settings" dialogue.<br />
<br />
{| <br />
| <br />
[[File:Ap-mm-capture-choose-capture-settings-2.png|600px|thumb|right]]<br />
|}<br />
<br />
Start and end times can be changed by using the date and time popup window when<br />
selecting the time fields or clicking the dedicated buttons for commonly used times.<br />
If the start time is earlier than the start of the packet ring buffer, it will<br />
be adjusted to the start and a hint will be displayed.<br />
<br />
== Is it possible to plan a future capture? ==<br />
<br />
Yes. Simply select the desired start time in the "Choose capture settings" dialogue<br />
and the capture will start with the first packet at that time.<br />
<br />
On the 'Generic' -> 'Capture traffic' page there is also a tab 'Planned captures' where captures to a storage device can be configured and those captures can even be set to automatically repeat.<br />
<br />
== Create complex captures with several criteria ==<br />
<br />
Captures can be started with complex filter expressions for a specific capture of e.g.<br />
an IP address or a Layer 7 protocol.<br />
<br />
To see a basic overview, start a capture from any module. You can see all running active captures at the capture button at the top bar of the web interface.<br />
<br />
{| <br />
| <br />
[[File:Ap-mm-capture-filter-expression.png|600px|thumb|right]]<br />
|}<br />
<br />
On the "Start simple capture" page, all frequently<br />
used filter expressions are easily accessible. The resulting expression is<br />
displayed below.<br />
<br />
{| <br />
| <br />
[[File:Ap-mm-capture-capture-simple-2.png|600px|thumb|right]]<br />
|}<br />
<br />
This expression can be used and edited in the expert filter field. All<br />
filters can be combined with "and" / "&&" or "or" / "||". Parentheses may<br />
be used to clarify precedence.<br />
<br />
The chapter [[Capture_module|Capture module]] explains every possible filter.<br />
<br />
== Generate a pcap via the command line ==<br />
<br />
It is easy to generate a pcap via the command line or in scripts with "curl"<br />
which is a tool available for recent versions of Windows 10, Linux and MacOS.<br />
<br />
Just type:<br />
<br />
{| class="wikitable"<br />
| curl -k -u USER:PASSWORD https://allegro-mm-XXXX/API/data/modules/capture?expression=ip==10.1.2.3 > path_to/capture.pcap<br />
|}<br />
<br />
The user name, password and hostname have to be the same as the ones used to access<br />
the web interface. Every filter expression that can be used in the web interface<br />
can also be used here.<br />
<br />
Check out the chapter [[Capture_module|Capture module]] for further information.<br />
<br />
== It takes too long to open a pcap file in Wireshark. What can I do? ==<br />
If you are in a situation where you have a large pcap and are only<br />
interested in the traffic between two specific IP addresses, you can<br />
use the Allegro Network Multimeter to analyze the pcap file and<br />
extract the specific traffic for post-processing with tools such as<br />
Wireshark. See [[Forensic_pcap_Analysis|Forensic Pcap Analysis]] for details.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Administration&diff=4382Administration2023-08-14T13:42:33Z<p>Ralf: /* Configuration */</p>
<hr />
<div>The administration page allows the following actions:<br />
<br />
{| class="wikitable sortable"<br />
|- <br />
| [[File:Administration.png|800px|none|right]]<br />
|}<br />
<br />
=== Power ===<br />
<br />
Reboot or power off the Allegro Network Multimeter.<br />
<br />
After clicking on the buttons, a confirmation dialogue will appear. Most of the time, rebooting is not necessary since it takes a significant time. If packet processing needs to be restarted because some options cannot be changed during runtime, the next option is a better choice since it minimizes downtime.<br />
<br />
=== Processing ===<br />
<br />
Restart the Allegro Network Multimeter processing software. This will reset all measured statistics.<br />
<br />
Choosing this option will stop packet processing but the machine and its web interface is still available as the device itself is not rebooted. The packet processing core is restarted with the current settings and will begin processing packets after a few seconds.<br />
<br />
=== Configuration ===<br />
<br />
By clicking on the '''Reset System Configuration''' button a dialog is displayed that allows to reset all settings, including the network configuration, to factory defaults and the system will be restarted. As of version 3.4 the dialog allows to keep certain settings (management interface settings, users and passwords, disk and packet ring buffer cluster settings including optional random device-specific encryption keys) while setting the rest of the system configuration to defaults.<br />
<br />
The '''Export System Configuration''' button allows you to export the entire configuration of the *Allegro Network Multimeter*. A zip compressed file can be downloaded and used for import.<br />
<br />
The '''Import System Configuration''' button allows you to select several configuration items:<br />
<br />
* Core settings: All settings of global settings, module settings, incident settings, user defined names, virtual link groups, ingress (NIC) filter and IP groups, excluding management interface settings, multi-device settings, and user settings. Some core settings (network interfaces, virtual link group and time synchronization) can also be retained during import. Simply uncheck the global core setting checkbox und check the child checkboxes for settings to be imported and overwritten.<br />
* Management interface settings: All settings of the management interface (e.g. Wi-Fi, LAN, hostname).<br />
* Multi device settings: All settings on the configured remote devices.<br />
* User and roles: All users and their passwords. The admin user cannot be changed and cannot be deleted by a configuration import.<br />
* User settings: All user settings (such as search history or dashboard configuration)<br />
It is possible to import the selected settings to all configured remote devices by selecting the last check box.<br />
<br />
The button '''Save current system configuration on Multimeter''' will store the current configuration as a file on the device itself (in contrast to the export feature, which will download the file the user's computer).<br />
<br />
When there are saved configuration available, any of them can be selected and load onto the system again. It is also possible to delete the configuration.<br />
<br />
=== CORS Configuration ===<br />
With version 4.1 the option to configure the "Cross-Origin Resource Sharing" (CORS) settings was introduced.<br />
<br />
You can learn about CORS on the MDN Web docs[https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS].<br />
<br />
=== Access Control ===<br />
Since version 4.1 there is the the option to limit the access to the multimeter to specific subnets.<br />
<br />
If you enable the access control, you have the option to specify the subnets from which people are allowed to access the multimeter.<br />
<br />
If you want to allow the access for the clients in the subnet in which the multimeter is deployed you are able to allow that with ticking "Allow local access".<br />
<br />
=== TLS/SSL certificate ===<br />
<br />
The appliance comes with a pre-installed generic TLS certificate but a custom certificate can be uploaded, generated (since 3.6) or downloaded from a Certificate Authority (since 3.6).<br />
<br />
Depending on your firmware-version there are two to four possibilities:<br />
<br />
==== Before 3.6: ====<br />
There are two options:<br />
<br />
* You are able to use the certificates the appliance got delivered with. (You are able to reset to that with the Reset-Button)<br />
* You are able to upload a X.509 certificate file and a key file. Upon successful upload, this certificate will be used to serve the user interface.<br />
<br />
==== Since 3.6: ====<br />
There are four modes:<br />
* Legacy: The default certificates the appliance got shipped with will be used if the appliance got shipped with an older firmware than 3.6. You won't be able to switch back to this option and it will be hidden if it is not selected.<br />
* ACME: The Certificates will be downloaded from the specified Certificate Authority<br />
* Upload: You are able to upload a X.509 certificate file and a key file. Upon successful upload, this certificate will be used to serve the user interface.<br />
* Self-Signed: Self-Signed: Generate self-signed certificates with a custom host-name. They will be valid for 10 years and replace the legacy certificates for devices shipped with firmware version 3.6 or later.<br />
The Default Mode is always the fall-back if the process does not work.<br />
The '''Reset to default SSL certificate''' button will remove any user-provided SSL certificate and the user interface will be served using the default SSL certificate.<br />
<br />
=== Certificate Authority ===<br />
<br />
Some features also connect to external SSL services, for instance when sending email notifications via SMTP or when searching for [[Firmware update|firmware updates]]. Usually these SSL connections are verified with the built-in CA certificate pool. It is also possible to upload one or many own CA certificates which are used additionally to the system ones.<br />
<br />
The button "Install SSL CA certificates" opens a dialoug where the file can be selected and uploaded. This file must contain certificates in the PEM format. It may contain multiple certificates. <br />
<br />
Before version 3.6 uploading new certificates will replace the existing ones. The button "Remove SSL CA certificates" will delete the previously installed custom CA certificates so that only the system CA pool is used again for certificate verification.<br />
<br />
With version 3.6 uploading a new certificate adds to the old one. You can delete all by pressing the "Remove all CA certificates" and also remove separate certificates.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Storage&diff=4381Storage2023-08-14T13:41:46Z<p>Ralf: /* Encryption */</p>
<hr />
<div>==General==<br />
The Allegro Network Multimeter allows for internal or external storage device(s) to be connected.<br />
<br />
Such HDD- or SSD-based storage devices, serve the following purposes:<br />
<br />
* Ring Buffer: Allows for network traffic recording (partial or 100%) onto a fixed size '''ring buffer'''/circular buffer (FiFo)<br />
* Storage: Allows for the creation of a dedicated storage partition, for saving and storing pcap files onto the local device<br />
* Network traffic replay and analysis of data recorded onto the ring buffer<br />
* Retroactive filtered packet capturing, from network traffic data residing in the ring buffer. see -> [[Capture module]]<br />
<br />
{| class="wikitable"<br />
|-<br />
| [[File:Storage.png|1000px|none]]<br />
|}<br />
<br />
== Managing storage devices == <br />
The Allegro Network Multimeter supports disks formatted with an '''ext4 filesystem ''' and will only use '''the first partition''' of each disk.<br />
<br />
If a compatible disk is attached, a dialog will show up and offer to activate the disk as a storage device. As of version 3.6, multiple storage devices can be active at the same time. The active storage device for which the properties and contents are shown can be selected at the top of the 'Storage' page. Next to the drop-down menu there is a little pen icon which allows to set an alternative name for the storage device (which is displayed e.g. in the capture dialog).<br />
<br />
The 'Storage' page will show stats about the selected device as well as the contents.<br />
<br />
If an '''unformatted disk''' or a disk with an '''incompatible file system''' is attached, it will show up on the Storage page where it can be formatted using the '''Format button''' displayed next to the device's type and size. After formatting the disk, it will be automatically activated for use as storage device.<br />
===Encryption===<br />
The Allegro Network Multimeter uses an '''AES256 LUKS encryption container''' for encrypted single shared ring buffers. You can connect and mount the encrypted disk with many Linux Distributions. It will ask for your password to mount the container. The Allegro Network Multimeter uses hardware encryption if available. The Allegro 200 does not have HW encryption support and can encrypt up to 400MBit/s in software. All other Allegro devices can encrypt with 2GB/s by using the built-in hardware encryption.<br />
<br />
The Allegro Network Multimeter does ''not'' store the password of the encrypted device on the disk. you need to re-enter the password if you unmount, reboot or power-off the Allegro Network Multimeter.<br />
<br />
The encryption is not available for the cluster ring buffer.<br />
<br />
To encrypt a storage device with AES256 disk encryption, (re)format the disk and enable the AES256 disk encryption option in the on-screen menu:<br />
<br />
[[File:Disk formatting and encryption.png|700x700px]]<br />
====Random, device specific passwords====<br />
Since firmware version 3.4 it is possible to use a randomly generated password for the encrypted storage device. When used, the storage can be activated and deactivated without entering the password. Also, the storage device is automatically activated on system start/restart. The password is stored encrypted on the device and cannot be moved a different device. The password is also deleted on a configuration reset of the Allegro Network Multimeter. Since the password is stored on the Allegro Network Multimeter, the storage device cannot be used on a different Allegro Network Multimeter without reformatting. When the key is removed (on configuration reset or reformat), it cannot be restored!<br />
<br />
=== Deactivation ===<br />
If an active storage device is to be disconnected from the Allegro Network Multimeter, the deactivate button on the storage page can be used to deactivate the storage device.<br />
<br />
The page will then show that the respective storage device has become inactive. Now, the device can be disconnected safely.<br />
<br />
== Secure erase ==<br />
For security reasons, the "'''Securely erase content"''' button, allows for special formatting algorithms to wipe your disk(s). <br />
<br />
Everything on the disk is overwritten with randomly generated patterns, making attempts to recover data (near to) impossible. <br />
<br />
Allegro Packets utilizes the sata (extended) secure erase instruction set, for sata disks that support it. <br />
<br />
For NVME type SSD's, Allegro Packets utilizes the "Cryptographic Erase" instruction set. <br />
<br />
NOTE: The erasing may take several hours, depending on the size and the speed of the disk. After the secure erase process, a disk needs to be formatted before use. <br />
<br />
== File storage ==<br />
The Allegro Network Multimeter will initially show the top level directory of the storage partition. By clicking on a directory name the view can be switched to the contents of that sub-directory. This will also show the path of the current directory above the table along with a button that allows to change back to the parent directory.<br />
<br />
The following actions for files and directories are available through the following buttons in the same row:<br />
<br />
* '''Analyze PCAP''' or '''Analyze all PCAP files''': will be shown for packet capture files or directories respectively. If '''Analyze PCAP''' is pressed, the Allegro Network Multimeter will either reset all statistics and start analyzing the packet capture file or enables to start a parallel PCAP analysis if this is configured (see [[Parallel packet processing]]). Progress, statistics and the option to resume normal operation will appear at the top of the Storage page. '''Analyze all PCAP files''' will do the same thing but for all packet capture files residing in the directory together (see the '''Analyze selected PCAP files together''' button description).<br />
* '''Webshark preview''': will be shown for packet capture files and, if pressed, opens a Wireshark-like preview of the file.<br />
* '''Download''': starts a browser download of this file.<br />
* '''Meatballs menu:''' contains file system operations<br />
<br />
The '''New directory''' button opens as dialog that can be used to create a new sub-directory in the currently shown directory. Sub-directories can be used as target for storing packet captures (see [[Capture module#Capture settings dialog|Capture settings dialog]]).<br />
<br />
The '''Select or drop file''' area along with the '''Upload file''' button allows to upload a file to the current directory.<br />
<br />
The '''Analyze selected PCAP files together''' button will start analyzing all packet capture files, that have been marked with the checkbox at the start of the row, together. This will happen in a mergecap-style fashion so that the packet capture files are merged based on packet timestamps. Progress will be shown at the top of the page for every file separately.<br />
<br />
=== File system operations ===<br />
The meatballs menu in each entry reveals the options<br />
<br />
* '''Rename'''<br />
* '''Move'''<br />
* '''Copy'''<br />
* '''Delete'''<br />
<br />
Renaming will open a text box where the new name of the file can be entered.<br />
<br />
Deleting will ask for confirmation before removing the file from disk.<br />
<br />
Moving and copying will open a dialog similar to a file explorer. Here the location of the target file can be specified by simply navigating through the folder structure like in any common file browser. If huge files are moved or copied, a new "Pending File System" entry will be created, showing the progress of the file transfer as well as any errors that might have occurred. Any currently pending operations may also be cancelled here.<br />
<br />
[[File:Pending ops.png|510x510px]]<br />
<br />
[[File:Pending op failed.png|510x510px]]<br />
<br />
== WebDAV ==<br />
The Network Multimeter also provides access to the storage contents via WebDAV. <br />
<br />
For this, use the '''Connect to server''' or '''Connect to a network drive''' function on your computer and use the link https://<host name>/webdav.<br />
<br />
The credentials are the same as of the web interface. Use the admin account to access the files on the storage device. <br />
<br />
WebDAV is supported natively by all current operating systems.<br />
<br />
If you have connection problems due to SSL certificate issues under Windows you may try 3rd party tools with WebDAV support.<br />
{| class="wikitable"<br />
|+<br />
!Operating system<br />
!Usage<br />
!Notes<br />
|-<br />
|Windows<br />
|In third-party tools with webdav support:<br />
enter URL<br />
<br />
https://<hostname or ip>/webdav<br />
|Standard windows explorer does not accept self-signed certificates.<br />
Use a third-party tool to use webdav!<br />
|-<br />
|Linux<br />
|In file manger, enter URL<br />
davs://<hostname or ip>/webdav<br />
|System usually asks to accept the certificate and that asks for username and password.<br />
|-<br />
|MacOS<br />
|Open Finder, select menu "go to -> connect to server".<br />
Enter "https://<hostname or ip>/webdev"<br />
|System usually asks to accept the certificate and that asks for username and password.<br />
|}<br />
<br />
<br />
== iSCSI ==<br />
<br />
{| class="wikitable"<br />
|-<br />
| [[File:Configure iSCSI device.png|600px|none|]]<br />
|}<br />
<br />
A remote iSCSI target can be used as a storage device. <br />
<br />
The iSCSI target must be reachable over the management network connection.<br />
<br />
To add an iSCSI target as storage device use the Configure iSCSI device button which is visible on the Storage page when no storage device is currently activated. <br />
<br />
In the displayed dialog you must enter the host which can be an IP address or host name and may include a port number (e.g. 'storageServer:3260'). <br />
<br />
You must also enter the '''iSCSI Qualified Name (IQN)''' of the iSCSI target on the iSCSI host. <br />
<br />
Using authentication like CHAP is optional and if no authentication is to be used the User and Password` fields can be left empty. <br />
<br />
After confirming the dialog by pressing the Configure button the iSCSI storage device will show up in the storage device list after a few seconds.<br />
<br />
The Allegro Network Multimeter will also try to activate a configured iSCSI target automatically after system startup.<br />
<br />
Once an iSCSI device has been configured the device can be modified or removed using the Modify iSCSI device and Remove iSCSI device buttons on the Storage page. <br />
<br />
Only one iSCSI device can be used at a time.<br />
<br />
== SFTP ==<br />
With version 4.0 access to the storage via sftp was added. <br />
<br />
The server is per default off and has to be turned on in 'Settings' > 'Remote access and Statistics Export' > 'SFTP Server'.<br />
<br />
Authentication is possible via a ssh key or the same credentials as of the web interface.<br />
<br />
Only the user with the role 'admin' are allowed to access the storage via sftp.<br />
<br />
The ssh key is configurable on a user basis in the user settings.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Storage&diff=4380Storage2023-08-14T13:41:24Z<p>Ralf: /* Managing storage devices */</p>
<hr />
<div>==General==<br />
The Allegro Network Multimeter allows for internal or external storage device(s) to be connected.<br />
<br />
Such HDD- or SSD-based storage devices, serve the following purposes:<br />
<br />
* Ring Buffer: Allows for network traffic recording (partial or 100%) onto a fixed size '''ring buffer'''/circular buffer (FiFo)<br />
* Storage: Allows for the creation of a dedicated storage partition, for saving and storing pcap files onto the local device<br />
* Network traffic replay and analysis of data recorded onto the ring buffer<br />
* Retroactive filtered packet capturing, from network traffic data residing in the ring buffer. see -> [[Capture module]]<br />
<br />
{| class="wikitable"<br />
|-<br />
| [[File:Storage.png|1000px|none]]<br />
|}<br />
<br />
== Managing storage devices == <br />
The Allegro Network Multimeter supports disks formatted with an '''ext4 filesystem ''' and will only use '''the first partition''' of each disk.<br />
<br />
If a compatible disk is attached, a dialog will show up and offer to activate the disk as a storage device. As of version 3.6, multiple storage devices can be active at the same time. The active storage device for which the properties and contents are shown can be selected at the top of the 'Storage' page. Next to the drop-down menu there is a little pen icon which allows to set an alternative name for the storage device (which is displayed e.g. in the capture dialog).<br />
<br />
The 'Storage' page will show stats about the selected device as well as the contents.<br />
<br />
If an '''unformatted disk''' or a disk with an '''incompatible file system''' is attached, it will show up on the Storage page where it can be formatted using the '''Format button''' displayed next to the device's type and size. After formatting the disk, it will be automatically activated for use as storage device.<br />
===Encryption===<br />
The Allegro Network Multimeter uses an '''AES256 LUKS encryption container''' for encrypted single shared ring buffers. You can connect and mount the encrypted disk with many Linux Distributions. It will ask for your password to mount the container. The Allegro Network Multimeter uses hardware encryption if available. The Allegro 200 does not have HW encryption support and can encrypt up to 400MBit/s in software. All other Allegro devices can encrypt with 2GB/s by using the built-in hardware encryption.<br />
<br />
The Allegro Network Multimeter does ''not'' store the password of the encrypted device on the disk. you need to re-enter the password if you unmount, reboot or power-off the Allegro Network Multimeter.<br />
<br />
The encryption is not available for the cluster ring buffer.<br />
<br />
To encrypt a storage device with AES256 disk encryption, (re)format the disk and enable the AES256 disk encryption option in the on-screen menu:<br />
[[File:Disk formatting and encryption.png|700x700px]]<br />
====Random, device specific passwords====<br />
Since firmware version 3.4 it is possible to use a randomly generated password for the encrypted storage device. When used, the storage can be activated and deactivated without entering the password. Also, the storage device is automatically activated on system start/restart. The password is stored encrypted on the device and cannot be moved a different device. The password is also deleted on a configuration reset of the Allegro Network Multimeter. Since the password is stored on the Allegro Network Multimeter, the storage device cannot be used on a different Allegro Network Multimeter without reformatting. When the key is removed (on configuration reset or reformat), it cannot be restored!<br />
<br />
=== Deactivation ===<br />
If an active storage device is to be disconnected from the Allegro Network Multimeter, the deactivate button on the storage page can be used to deactivate the storage device.<br />
<br />
The page will then show that the respective storage device has become inactive. Now, the device can be disconnected safely.<br />
<br />
== Secure erase ==<br />
For security reasons, the "'''Securely erase content"''' button, allows for special formatting algorithms to wipe your disk(s). <br />
<br />
Everything on the disk is overwritten with randomly generated patterns, making attempts to recover data (near to) impossible. <br />
<br />
Allegro Packets utilizes the sata (extended) secure erase instruction set, for sata disks that support it. <br />
<br />
For NVME type SSD's, Allegro Packets utilizes the "Cryptographic Erase" instruction set. <br />
<br />
NOTE: The erasing may take several hours, depending on the size and the speed of the disk. After the secure erase process, a disk needs to be formatted before use. <br />
<br />
== File storage ==<br />
The Allegro Network Multimeter will initially show the top level directory of the storage partition. By clicking on a directory name the view can be switched to the contents of that sub-directory. This will also show the path of the current directory above the table along with a button that allows to change back to the parent directory.<br />
<br />
The following actions for files and directories are available through the following buttons in the same row:<br />
<br />
* '''Analyze PCAP''' or '''Analyze all PCAP files''': will be shown for packet capture files or directories respectively. If '''Analyze PCAP''' is pressed, the Allegro Network Multimeter will either reset all statistics and start analyzing the packet capture file or enables to start a parallel PCAP analysis if this is configured (see [[Parallel packet processing]]). Progress, statistics and the option to resume normal operation will appear at the top of the Storage page. '''Analyze all PCAP files''' will do the same thing but for all packet capture files residing in the directory together (see the '''Analyze selected PCAP files together''' button description).<br />
* '''Webshark preview''': will be shown for packet capture files and, if pressed, opens a Wireshark-like preview of the file.<br />
* '''Download''': starts a browser download of this file.<br />
* '''Meatballs menu:''' contains file system operations<br />
<br />
The '''New directory''' button opens as dialog that can be used to create a new sub-directory in the currently shown directory. Sub-directories can be used as target for storing packet captures (see [[Capture module#Capture settings dialog|Capture settings dialog]]).<br />
<br />
The '''Select or drop file''' area along with the '''Upload file''' button allows to upload a file to the current directory.<br />
<br />
The '''Analyze selected PCAP files together''' button will start analyzing all packet capture files, that have been marked with the checkbox at the start of the row, together. This will happen in a mergecap-style fashion so that the packet capture files are merged based on packet timestamps. Progress will be shown at the top of the page for every file separately.<br />
<br />
=== File system operations ===<br />
The meatballs menu in each entry reveals the options<br />
<br />
* '''Rename'''<br />
* '''Move'''<br />
* '''Copy'''<br />
* '''Delete'''<br />
<br />
Renaming will open a text box where the new name of the file can be entered.<br />
<br />
Deleting will ask for confirmation before removing the file from disk.<br />
<br />
Moving and copying will open a dialog similar to a file explorer. Here the location of the target file can be specified by simply navigating through the folder structure like in any common file browser. If huge files are moved or copied, a new "Pending File System" entry will be created, showing the progress of the file transfer as well as any errors that might have occurred. Any currently pending operations may also be cancelled here.<br />
<br />
[[File:Pending ops.png|510x510px]]<br />
<br />
[[File:Pending op failed.png|510x510px]]<br />
<br />
== WebDAV ==<br />
The Network Multimeter also provides access to the storage contents via WebDAV. <br />
<br />
For this, use the '''Connect to server''' or '''Connect to a network drive''' function on your computer and use the link https://<host name>/webdav.<br />
<br />
The credentials are the same as of the web interface. Use the admin account to access the files on the storage device. <br />
<br />
WebDAV is supported natively by all current operating systems.<br />
<br />
If you have connection problems due to SSL certificate issues under Windows you may try 3rd party tools with WebDAV support.<br />
{| class="wikitable"<br />
|+<br />
!Operating system<br />
!Usage<br />
!Notes<br />
|-<br />
|Windows<br />
|In third-party tools with webdav support:<br />
enter URL<br />
<br />
https://<hostname or ip>/webdav<br />
|Standard windows explorer does not accept self-signed certificates.<br />
Use a third-party tool to use webdav!<br />
|-<br />
|Linux<br />
|In file manger, enter URL<br />
davs://<hostname or ip>/webdav<br />
|System usually asks to accept the certificate and that asks for username and password.<br />
|-<br />
|MacOS<br />
|Open Finder, select menu "go to -> connect to server".<br />
Enter "https://<hostname or ip>/webdev"<br />
|System usually asks to accept the certificate and that asks for username and password.<br />
|}<br />
<br />
<br />
== iSCSI ==<br />
<br />
{| class="wikitable"<br />
|-<br />
| [[File:Configure iSCSI device.png|600px|none|]]<br />
|}<br />
<br />
A remote iSCSI target can be used as a storage device. <br />
<br />
The iSCSI target must be reachable over the management network connection.<br />
<br />
To add an iSCSI target as storage device use the Configure iSCSI device button which is visible on the Storage page when no storage device is currently activated. <br />
<br />
In the displayed dialog you must enter the host which can be an IP address or host name and may include a port number (e.g. 'storageServer:3260'). <br />
<br />
You must also enter the '''iSCSI Qualified Name (IQN)''' of the iSCSI target on the iSCSI host. <br />
<br />
Using authentication like CHAP is optional and if no authentication is to be used the User and Password` fields can be left empty. <br />
<br />
After confirming the dialog by pressing the Configure button the iSCSI storage device will show up in the storage device list after a few seconds.<br />
<br />
The Allegro Network Multimeter will also try to activate a configured iSCSI target automatically after system startup.<br />
<br />
Once an iSCSI device has been configured the device can be modified or removed using the Modify iSCSI device and Remove iSCSI device buttons on the Storage page. <br />
<br />
Only one iSCSI device can be used at a time.<br />
<br />
== SFTP ==<br />
With version 4.0 access to the storage via sftp was added. <br />
<br />
The server is per default off and has to be turned on in 'Settings' > 'Remote access and Statistics Export' > 'SFTP Server'.<br />
<br />
Authentication is possible via a ssh key or the same credentials as of the web interface.<br />
<br />
Only the user with the role 'admin' are allowed to access the storage via sftp.<br />
<br />
The ssh key is configurable on a user basis in the user settings.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Ingress_filter&diff=4379Ingress filter2023-08-14T09:02:54Z<p>Ralf: /* Packet deduplication */</p>
<hr />
<div><br />
<br />
The ingress filter page, allows setting allow/deny filters for live traffic preprocessing. Filtered out/denied traffic, will NOT become available throughout the dashboard nor the packet ring buffer. Filtered out/denied traffic will be irretrievable for (post) analysis.<br />
<br />
=== Functionality ===<br />
Filters can be applied for:<br />
<br />
* IP addresses (with possible subnet mask).<br />
* pairs of IP addresses (with possible subnet mask).<br />
* MAC addresses.<br />
* VLAN tags (or none for no VLAN tag).<br />
* specific TCP/UDP ports.<br />
* physical interface IDs (as listed in Interface statistics).<br />
* duplicate packets.<br />
* a set of filter via the expert-filter<br />
<br />
They can all be set to either deny list or allow list mode. <br />
Filtering will be evaluated for every packet in tab order. <br />
The more restrictive filter will be applied. <br />
For instance if no IP address is denied but a specific MAC address is on the deny list, no traffic for that MAC address will be processed.<br />
<br />
=== Important Notes ===<br />
The ingress (NIC) filter is applied to live traffic only, i.e. the traffic sent to the monitoring interfaces of an Allegro Network Multimeter. When replaying data from the ring buffer, loading a pcap or using the remote traffic capture feature, filtering is not used and/or applied.<br />
<br />
Empty allow lists will discard all traffic so '''no''' traffic will be available for traffic processing.<br />
<br />
The data recorded to/stored in the Packet Ring buffer, is of course also affected by the Ingress filter. Additional ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here [[Packet ring buffer#Packet%20ring%20buffer%20snapshot%20length%20filter|https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter]]<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
| [[File:NIC filter.png|1000px|none|right]]<br />
|}<br />
<br />
=== IP filters ===<br />
<br />
In the IP filter/IP pair filter, IP addresses and IP ranges can be entered with their respective subnet mask.<br />
* /32 subnet mask: 192.168.1.1/32 means the filter will deny/allow IP 192.168.1.1 <br />
* /24 subnet mask: 192.168.1.0/24 means the filter will deny/allow IP range 192.168.1.0 - 192.168.1.255<br />
* /16 subnet mask: 192.168.0.0/16 means the filter will deny/allow IP range 192.168.0.0 - 192.168.255.255<br />
<br />
The IP filter/IP pair filter allows for importing an IP list in the following format:<br />
<br />
#A line with a comment<br />
1.2.3.1<br />
1.2.3.2<br />
1.2.3.3<br />
<br />
Each entry can be annotated with a comment by clicking on the pencil icon in the table row.<br />
<br />
By clicking on '''Import list''' a dialogue box will be opened where you can choose to download such a list from a given URL or specify a file from your system. The IP addresses are added to the existing ones up to a maximum of 10000 addresses.<br />
<br />
The '''Export list''' button allows for exporting the IP filter list in the same format as the import.<br />
<br />
The '''Delete all''' button allows for deleting all IP addresses from the filter list.<br />
<br />
=== Expert Filter ===<br />
You are able to filter the packets from live traffic via the expert or complex filter which you can also use when capturing traffic. The filter is defined in a C-style syntax and supports combination of AND/OR operators, precedence order with parentheses and equal/not equal comparisons.<br />
<br />
You are also able to select if packets matching the filter should be monitored or excluded from monitoring. More information are on the [[Capture module#Using%20expert%20filters%20to%20start%20captures|Capture module]] and [[Complex filter]] sites in the wiki.<br />
<br />
=== Packet deduplication ===<br />
<br />
Packet deduplication provides the ability to filter packets from live traffic which have already been seen. This feature creates a hash from significant parts of the packet and stores the hash for a certain amount of time and within the configured memory limit. If for a second packet (or possibly further packets) the same hash value is calculated this packet is discarded and will not be analyzed by the system. The feature provides several options for configuring which parts of a packets are regarded as significant for duplicate detection.<br />
<br />
It is also possible to capture packets which have been detected as duplicates but since these packets are excluded from further processing as well as the packet ring buffer it is only possible to create a live capture. Also, since only hash values are stored, the first packet of a series of duplicates will not be part of the duplicate capture, but it can be captured with the regular capture feature as it is part of the packet processing.<br />
<br />
Packet deduplication works on a per [[Virtual Link Group functionality|Virtual Link Group]] basis. Duplicates are detected within each VLG so duplicates from one link groups do not interfere with packets having the same hash in other link groups.<br />
<br />
To utilize the packet deduplication feature, follow the following steps:<br />
<br />
# Configure and enable the packet deduplication engine in the Ingress filter configuration section as described below.<br />
# [[Virtual Link Group Configuration Guide|Configure]] each VLG to enable or disable packet deduplication for that group. It is on by default.<br />
<br />
==== Statistics ====<br />
<br />
The top graph and counter show how many packets have been discarded as duplicates.<br />
<br />
The '''Memory used''' graph shows how much of the memory which has been configured for use by the packet deduplication is actually consumed. If the value is very high it is possible that the configured amount of memory is not sufficient for the actual traffic. Insufficient memory results in reduction of the packet timeout.<br />
<br />
The '''Oldest packet age''' graph shows how old the oldest packet known to the packet deduplication is. If this value is significantly lower than the configured '''Packet timeout''' value the configured amount of memory may not be sufficient for the actual traffic.<br />
<br />
==== Settings ====<br />
<br />
{| class="wikitable"<br />
|-<br />
! Option !! Description<br />
|-<br />
| Enabled || Turns the packet deduplication filter on and off.<br />
|-<br />
| Reserved memory (MB) || Controls how much memory in megabytes is reserved for packet deduplication. This memory then cannot be used for other statistics. Changes to this value will need a restart of the processing to take effect.<br />
|-<br />
| Packet timeout (ms) || The time in milliseconds after which a packet hash is removed from the packet deduplication. If the time is between identical packets is longer than this value the packets will not be detected as duplicates.<br />
|-<br />
| Compare starting at layer || Here it is possible to choose where the packet deduplication will start to analyze the packet. If e.g. 'Layer 3' is chosen it is possible for two packets to have different MAC addresses and still be detected as duplicates.<br />
|-<br />
| Layer 7 length limit for compare (bytes) || This value controls how many bytes of the application payload are actually used for the hash calculation. A very high value may affect the performance while a very low value may increase the risk of false positives.<br />
|-<br />
| Ignore VLAN || The VLAN tag will not be used by the packet deduplication so that two packets from different VLANs can still be detected as duplicates.<br />
|-<br />
| Ignore IP TOS and traffic class || The IP 'type of service' and 'traffic class' fields will not be used by the packet deduplication so that two packets with different values in these fields can still be detected as duplicates.<br />
|-<br />
| Ignore IP TTL and HOP || The IP 'time to live' and 'hop counter' fields will not be used by the packet deduplication so that two packets with different values in these fields can still be detected as duplicates.<br />
|-<br />
| Ignore TCP SEQ and ACK numbers || The TCP sequence and acknowledgement numbers will not be used by the packet deduplication so that two packets with different TCP sequence and acknowledgement numbers can still be detected as duplicates.<br />
|-<br />
| Ignore TCP options || Any TCP options will not be used by the packet deduplication so that two packets with different TCP options can still be detected as duplicates.<br />
|}<br />
<br />
==== Limitations ====<br />
<br />
# In some circumstances, real duplicates cannot be distinguished from retransmissions. For example, for TCP in IPv6 traffic a retransmitted ACK packet might be byte-wise identical to the original ACK packet. The IPv6 header does not have an IP-ID field by default so it is identical and the TCP header is identical too if both the sequence and acknowledge number are the same and no timestamp option header is used. In this case it might help to decrease the packet timeout in the deduplication configuration since real duplicates in a network setup usually appear much faster than actual retransmissions.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Ingress_filter&diff=4378Ingress filter2023-08-14T09:01:53Z<p>Ralf: /* Packet deduplication */</p>
<hr />
<div><br />
<br />
The ingress filter page, allows setting allow/deny filters for live traffic preprocessing. Filtered out/denied traffic, will NOT become available throughout the dashboard nor the packet ring buffer. Filtered out/denied traffic will be irretrievable for (post) analysis.<br />
<br />
=== Functionality ===<br />
Filters can be applied for:<br />
<br />
* IP addresses (with possible subnet mask).<br />
* pairs of IP addresses (with possible subnet mask).<br />
* MAC addresses.<br />
* VLAN tags (or none for no VLAN tag).<br />
* specific TCP/UDP ports.<br />
* physical interface IDs (as listed in Interface statistics).<br />
* duplicate packets.<br />
* a set of filter via the expert-filter<br />
<br />
They can all be set to either deny list or allow list mode. <br />
Filtering will be evaluated for every packet in tab order. <br />
The more restrictive filter will be applied. <br />
For instance if no IP address is denied but a specific MAC address is on the deny list, no traffic for that MAC address will be processed.<br />
<br />
=== Important Notes ===<br />
The ingress (NIC) filter is applied to live traffic only, i.e. the traffic sent to the monitoring interfaces of an Allegro Network Multimeter. When replaying data from the ring buffer, loading a pcap or using the remote traffic capture feature, filtering is not used and/or applied.<br />
<br />
Empty allow lists will discard all traffic so '''no''' traffic will be available for traffic processing.<br />
<br />
The data recorded to/stored in the Packet Ring buffer, is of course also affected by the Ingress filter. Additional ring buffer capture rules may be configured under "Generic - Packet Ring Buffer", further explained in our wiki here [[Packet ring buffer#Packet%20ring%20buffer%20snapshot%20length%20filter|https://allegro-packets.com/wiki/Packet_ring_buffer#Packet_ring_buffer_snapshot_length_filter]]<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
| [[File:NIC filter.png|1000px|none|right]]<br />
|}<br />
<br />
=== IP filters ===<br />
<br />
In the IP filter/IP pair filter, IP addresses and IP ranges can be entered with their respective subnet mask.<br />
* /32 subnet mask: 192.168.1.1/32 means the filter will deny/allow IP 192.168.1.1 <br />
* /24 subnet mask: 192.168.1.0/24 means the filter will deny/allow IP range 192.168.1.0 - 192.168.1.255<br />
* /16 subnet mask: 192.168.0.0/16 means the filter will deny/allow IP range 192.168.0.0 - 192.168.255.255<br />
<br />
The IP filter/IP pair filter allows for importing an IP list in the following format:<br />
<br />
#A line with a comment<br />
1.2.3.1<br />
1.2.3.2<br />
1.2.3.3<br />
<br />
Each entry can be annotated with a comment by clicking on the pencil icon in the table row.<br />
<br />
By clicking on '''Import list''' a dialogue box will be opened where you can choose to download such a list from a given URL or specify a file from your system. The IP addresses are added to the existing ones up to a maximum of 10000 addresses.<br />
<br />
The '''Export list''' button allows for exporting the IP filter list in the same format as the import.<br />
<br />
The '''Delete all''' button allows for deleting all IP addresses from the filter list.<br />
<br />
=== Expert Filter ===<br />
You are able to filter the packets from live traffic via the expert or complex filter which you can also use when capturing traffic. The filter is defined in a C-style syntax and supports combination of AND/OR operators, precedence order with parentheses and equal/not equal comparisons.<br />
<br />
You are also able to select if packets matching the filter should be monitored or excluded from monitoring. More information are on the [[Capture module#Using%20expert%20filters%20to%20start%20captures|Capture module]] and [[Complex filter]] sites in the wiki.<br />
<br />
=== Packet deduplication ===<br />
<br />
Packet deduplication provides the ability to filter packets from live traffic which have already been seen. This feature creates a hash from significant parts of the packet and stores the hash for a certain amount of time and within the configured memory limit. If for a second packet (or possibly further packets) the same hash value is calculated this packet is discarded and will not be analyzed by the system. The feature provides several options for configuring which parts of a packets are regarded as significant for duplicate detection.<br />
<br />
It is also possible to capture packets which have been detected as duplicates but since these packets are excluded from further processing as well as the packet ring buffer it is only possible to create a live capture. Also, since only hash values are stored, the first packet of a series of duplicates will not be part of the duplicate capture, but it can be captured with the regular capture feature as it is part of the packet processing.<br />
<br />
Packet deduplication works on a per [[Virtual Link Group functionality|Virtual Link Group]] basis. Duplicates are detected within each VLG so duplicates from one link groups do not interfere with packets having the same hash in other link groups.<br />
<br />
To utilize the packet deduplication feature, follow the following steps:<br />
<br />
# Configure and enable the packet deduplication engine in the Ingress filter configuration section as described below.<br />
# [[Virtual Link Group Configuration Guide|Configure]] each VLG to enable or disable packet deduplication for that group.<br />
<br />
==== Statistics ====<br />
<br />
The top graph and counter show how many packets have been discarded as duplicates.<br />
<br />
The '''Memory used''' graph shows how much of the memory which has been configured for use by the packet deduplication is actually consumed. If the value is very high it is possible that the configured amount of memory is not sufficient for the actual traffic. Insufficient memory results in reduction of the packet timeout.<br />
<br />
The '''Oldest packet age''' graph shows how old the oldest packet known to the packet deduplication is. If this value is significantly lower than the configured '''Packet timeout''' value the configured amount of memory may not be sufficient for the actual traffic.<br />
<br />
==== Settings ====<br />
<br />
{| class="wikitable"<br />
|-<br />
! Option !! Description<br />
|-<br />
| Enabled || Turns the packet deduplication filter on and off.<br />
|-<br />
| Reserved memory (MB) || Controls how much memory in megabytes is reserved for packet deduplication. This memory then cannot be used for other statistics. Changes to this value will need a restart of the processing to take effect.<br />
|-<br />
| Packet timeout (ms) || The time in milliseconds after which a packet hash is removed from the packet deduplication. If the time is between identical packets is longer than this value the packets will not be detected as duplicates.<br />
|-<br />
| Compare starting at layer || Here it is possible to choose where the packet deduplication will start to analyze the packet. If e.g. 'Layer 3' is chosen it is possible for two packets to have different MAC addresses and still be detected as duplicates.<br />
|-<br />
| Layer 7 length limit for compare (bytes) || This value controls how many bytes of the application payload are actually used for the hash calculation. A very high value may affect the performance while a very low value may increase the risk of false positives.<br />
|-<br />
| Ignore VLAN || The VLAN tag will not be used by the packet deduplication so that two packets from different VLANs can still be detected as duplicates.<br />
|-<br />
| Ignore IP TOS and traffic class || The IP 'type of service' and 'traffic class' fields will not be used by the packet deduplication so that two packets with different values in these fields can still be detected as duplicates.<br />
|-<br />
| Ignore IP TTL and HOP || The IP 'time to live' and 'hop counter' fields will not be used by the packet deduplication so that two packets with different values in these fields can still be detected as duplicates.<br />
|-<br />
| Ignore TCP SEQ and ACK numbers || The TCP sequence and acknowledgement numbers will not be used by the packet deduplication so that two packets with different TCP sequence and acknowledgement numbers can still be detected as duplicates.<br />
|-<br />
| Ignore TCP options || Any TCP options will not be used by the packet deduplication so that two packets with different TCP options can still be detected as duplicates.<br />
|}<br />
<br />
==== Limitations ====<br />
<br />
# In some circumstances, real duplicates cannot be distinguished from retransmissions. For example, for TCP in IPv6 traffic a retransmitted ACK packet might be byte-wise identical to the original ACK packet. The IPv6 header does not have an IP-ID field by default so it is identical and the TCP header is identical too if both the sequence and acknowledge number are the same and no timestamp option header is used. In this case it might help to decrease the packet timeout in the deduplication configuration since real duplicates in a network setup usually appear much faster than actual retransmissions.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=L7_module&diff=4376L7 module2023-08-07T14:29:52Z<p>Ralf: </p>
<hr />
<div>The L7 module operates on results provided by the layer 7 protocol classification engine. This includes information on how much traffic for each protocol was seen for each IPv4 and IPv6 address.<br />
For each protocol the corresponding network traffic is accounted and a list of IP addresses for which the protocol was seen is available.<br />
It is also possible to extend the layer 7 protocol list by configuring custom protocols based on IP addresses or ports.<br />
This allows to track or filter specific IP or IP subnets or specific ports.<br />
<br />
== Web statistics ==<br />
=== L7 protocols ===<br />
<br />
A history graph sits on top of the page containing the top 10 protocols that created the most traffic.<br />
Below the history graph the protocols are listed with the following information available for each of them:<br />
<br />
* Number of total packets<br />
* Current throughput in packets per second<br />
* Number of total bytes (counting full ethernet frames)<br />
* Current throughput in bytes per second<br />
* A list with the Top 5 QoS classes seen for that protocol<br />
* A graph showing throughput history<br />
* A button to trigger a packet capture including only traffic for that protocol (see [[Capture_module|Capture module]])<br />
<br />
When multiple pages of protocols are available, there will be a control field for switching pages in each list.<br />
The protocol search bars allow for entering names to see only those element for which the entered string is part of the name.<br />
The lists are sortable by most of the columns.<br />
Protocol names are linked to the respective detail views which are explained below.<br />
<br />
<br />
<br />
=== Statistics for protocol ===<br />
<br />
These detail view page show statistics for a specific protocol.<br />
<br />
On the top left they contain a table with the following information:<br />
<br />
* The full name of the protocol and its verbose description<br />
* Number of total packets<br />
* Number of total bytes (counting full ethernet frames)<br />
* Current throughput in packets per second<br />
* Current throughput in bytes per second<br />
<br />
On the top right they show two history graphs of which the upper one show packet throughput history while the lower one shows byte throughput history.<br />
On the bottom of a detail view page there are tabs to choose between the list of IP addresses, layer 3 QoS and layer 2 QoS classes seen for that specific protocol.<br />
<br />
<br />
<br />
=== IPs ===<br />
<br />
In this tab there is a table listing all IP addresses that have sent or received traffic of that particular protocol. <br />
The table contains the following information:<br />
<br />
* The IPv4 or IPv6 address (linked to the respective Per IP statistics view of the IP module)<br />
* Alternative names for the IP address like DNS name or DHCP names<br />
* Number of total packets for that IP and protocol<br />
* Number of total bytes for that IP and protocol (counting full ethernet frames)<br />
* The time of the first packet for that IP and protocol<br />
* The time of the most recent packet for that IP and protocol<br />
* A button to trigger a packet capture including only traffic for that IP and protocol (see Capture module)<br />
* A graph showing throughput history for that IP and protocol<br />
<br />
When multiple pages of IPs are available, there will be a control field for switching table pages.<br />
The IP/dns/dhcp search bars allow for entering IP addresses or names to see only those element for which the entered string is part of the IP or dns/dhcp name.<br />
<br />
The table is sortable by most of the columns.<br />
IPs are linked to the respective Per IP statistics view of the [[IP_module|IP module]].<br />
<br />
<br />
<br />
=== Layer 3 QoS ===<br />
<br />
For layer 3 IP differentiated services codepoint (DSCP) are displayed in a table with traffic counters, a history graph of traffic over time and a PCAP button for that certain DSCP value.<br />
More information about QoS can be found in [[QoS_module|QoS module]].<br />
<br />
<br />
=== Layer 2 QoS ===<br />
<br />
For layer 2 VLAN priority code points and MPLS traffic classes are analysed and displayed in a table with traffic counters, a history graph of traffic over time and a PCAP button that certain QoS tag.<br />
More information about QoS can be found in [[QoS_module|QoS module]].<br />
<br />
<br />
<br />
== Configuration ==<br />
<br />
The configuration tab allows to define additional custom protocols. Based on IP addresses or subnets or port ranges, up to 128 different custom protocols may be defined which are shown as regular layer 7 protocols in the statistics described in the previous sections.<br />
These custom protocols can be used to track specific services or IP addresses. It also possible to capture traffic specific to those protocols or define filters.<br />
<br />
Each protocol consists of the following parameters:<br />
<br />
* Name: this is the identifier used in all statistics and layer 7 specific filters. An unique name must be chosen.<br />
* Description: the description is purely informational and is shown in the detailed statistics for that protocol. This field can be used for a detailed description what kind of traffic the protocol covers.<br />
* Layer 4 protocol: The protocol may match any IP traffic but also can be limited to just TCP or UDP traffic. For performance it is recommended to choose either option if this is applicable as only part of the traffic need to be checked against the other matching rules.<br />
* IPs: An IP address can be entered or a subnet using the subnet size parameter. The source and destination IP address of a network packet is used to match the list of IP addresses. <br />
:Example values are:<br />
:* 1.2.3.4<br />
::meaning exactly the IP 1.2.3.4<br />
:* 1.2.3.0/24<br />
::this matches any IP between 1.2.3.0 and 1.2.3.255<br />
:It is possible to use IPv4 or IPv6 addresses.<br />
:Up to 16 IP addresses may be used so that at least one item on the list must match.<br />
* Ports: TCP or UDP ports may be used to match traffic. The source and the destination port is used to match the list of ports. Individual ports or port ranges can be used. <br />
:Example values are:<br />
:* 80<br />
::meaning exactly port 80<br />
:* 100-200<br />
::matches any port between 100 and 200<br />
:Up to 16 ports or port ranges may be defined.<br />
<br />
<br />
Either IP addresses or ports may be left empty, but if both are defined, they must match together. So for a specific packet the source or destination IP must match any entry in the list of IP addresses and the source or destination port must match any entry in the list of ports.<br />
<br />
<br />
<br />
=== Web interface ===<br />
<br />
The configuration tab allows to configure the custom protocols.<br />
<br />
Each of the 128 elements can be configured individually.<br />
<br />
Keep in mind that statistics are always accounted regarding their protocol ID so when changing a configuration for a specific ID, all previous statistics for that ID will still be available even if the IP/port combination would not have matched on the old traffic. It is recommended to restart the packet processing after modifying existing definitions.<br />
<br />
To edit a protocol definition, click on the pencil symbol at the right hand side of the table. A definition can be cleared by clicking on the trash symbol.<br />
<br />
The current configuration can be downloaded via the corresponding button and a previously saved configuration can be uploaded too. Make sure to save the configuration after importing a configuration to make it active.<br />
<br />
==== Editing a protocol ====<br />
<br />
The configuration mask for a specific protocol allows to change the parameters described above.<br />
<br />
* Layer 4 drop down box: Select the layer 4 protocol from the list of possible values.<br />
* IPs: use the 'plus' button to enter a new IP or IP mask. Use the 'minus' button to remove that corresponding ling.<br />
* Ports: Similar to IPs, add or remove lines configuring the ports to match.<br />
<br />
=== Examples ===<br />
<br />
# To define a custom protocol for an internal web server at IP 10.2.0.1, use the following settings:<br />
#* Name: int_server_1<br />
#* Layer 4 protocol: TCP<br />
#* IPs: 10.2.0.1<br />
#* Ports: 80<br />
# To define a custom protocol for a complete subnet 10.3.0.0 - 10.3.0.255, use the following settings:<br />
#* Name: office_computers<br />
#* Layer 4 protocol: Any layer 4 protocol<br />
#* IPs: 10.3.0.0/24<br />
#* Ports: none</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=L7_module&diff=4374L7 module2023-08-07T14:25:37Z<p>Ralf: /* Configuration */</p>
<hr />
<div>The L7 module operates on results provided by the layer 7 protocol classification engine. This includes information on how much traffic for each protocol was seen for each IPv4 and IPv6 address.<br />
For each protocol the corresponding network traffic is accounted and a list of IP addresses for which the protocol was seen is available.<br />
It is also possible to extend the layer 7 protocol list by configuring custom protocols based on IP addresses or ports.<br />
This allows to track or filter specific IP or IP subnets or specific ports.<br />
<br />
== Web statistics ==<br />
=== L7 protocols ===<br />
<br />
A history graph sits on top of the page containing the top 10 protocols that created the most traffic.<br />
Below the history graph the protocols are listed with the following information available for each of them:<br />
<br />
* Number of total packets<br />
* Current throughput in packets per second<br />
* Number of total bytes (counting full ethernet frames)<br />
* Current throughput in bytes per second<br />
* A list with the Top 5 QoS classes seen for that protocol<br />
* A graph showing throughput history<br />
* A button to trigger a packet capture including only traffic for that protocol (see [[Capture_module|Capture module]])<br />
<br />
When multiple pages of protocols are available, there will be a control field for switching pages in each list.<br />
The protocol search bars allow for entering names to see only those element for which the entered string is part of the name.<br />
The lists are sortable by most of the columns.<br />
Protocol names are linked to the respective detail views which are explained below.<br />
<br />
<br />
<br />
=== Statistics for protocol ===<br />
<br />
These detail view page show statistics for a specific protocol.<br />
<br />
On the top left they contain a table with the following information:<br />
<br />
* The full name of the protocol and its verbose description<br />
* Number of total packets<br />
* Number of total bytes (counting full ethernet frames)<br />
* Current throughput in packets per second<br />
* Current throughput in bytes per second<br />
<br />
On the top right they show two history graphs of which the upper one show packet throughput history while the lower one shows byte throughput history.<br />
On the bottom of a detail view page there are tabs to choose between the list of IP addresses, layer 3 QoS and layer 2 QoS classes seen for that specific protocol.<br />
<br />
<br />
<br />
=== IPs ===<br />
<br />
In this tab there is a table listing all IP addresses that have sent or received traffic of that particular protocol. <br />
The table contains the following information:<br />
<br />
* The IPv4 or IPv6 address (linked to the respective Per IP statistics view of the IP module)<br />
* Alternative names for the IP address like DNS name or DHCP names<br />
* Number of total packets for that IP and protocol<br />
* Number of total bytes for that IP and protocol (counting full ethernet frames)<br />
* The time of the first packet for that IP and protocol<br />
* The time of the most recent packet for that IP and protocol<br />
* A button to trigger a packet capture including only traffic for that IP and protocol (see Capture module)<br />
* A graph showing throughput history for that IP and protocol<br />
<br />
When multiple pages of IPs are available, there will be a control field for switching table pages.<br />
The IP/dns/dhcp search bars allow for entering IP addresses or names to see only those element for which the entered string is part of the IP or dns/dhcp name.<br />
<br />
The table is sortable by most of the columns.<br />
IPs are linked to the respective Per IP statistics view of the [[IP_module|IP module]].<br />
<br />
<br />
<br />
=== Layer 3 QoS ===<br />
<br />
For layer 3 IP differentiated services codepoint (DSCP) are displayed in a table with traffic counters, a history graph of traffic over time and a PCAP button for that certain DSCP value.<br />
More information about QoS can be found in [[QoS_module|QoS module]].<br />
<br />
<br />
=== Layer 2 QoS ===<br />
<br />
For layer 2 VLAN priority code points and MPLS traffic classes are analysed and displayed in a table with traffic counters, a history graph of traffic over time and a PCAP button that certain QoS tag.<br />
More information about QoS can be found in [[QoS_module|QoS module]].<br />
<br />
<br />
<br />
== Configuration ==<br />
<br />
The configuration tab allows to define additional custom protocols. Based on IP addresses or subnets or port ranges, up to 128 different custom protocols may be defined which are shown as regular layer 7 protocols in the statistics described in the previous sections.<br />
These custom protocols can be used to track specific services or IP addresses. It also possible to capture traffic specific to those protocols or define filters.<br />
<br />
Each protocol consists of the following parameters:<br />
<br />
* Name: this is the identifier used in all statistics and layer 7 specific filters. An unique name must be chosen.<br />
* Description: the description is purely informational and is shown in the detailed statistics for that protocol. This field can be used for a detailed description what kind of traffic the protocol covers.<br />
* Layer 4 protocol: The protocol may match any IP traffic but also can be limited to just TCP or UDP traffic. For performance it is recommended to choose either option if this is applicable as only part of the traffic need to be checked against the other matching rules.<br />
* IPs: An IP address can be entered or a subnet using the subnet size parameter. The source and destination IP address of a network packet is used to match the list of IP addresses. <br />
:Example values are:<br />
:* 1.2.3.4<br />
::meaning exactly the IP 1.2.3.4<br />
:* 1.2.3.0/24<br />
::this matches any IP between 1.2.3.0 and 1.2.3.255<br />
:It is possible to use IPv4 or IPv6 addresses.<br />
:Up to 16 IP addresses may be used so that at least one item on the list must match.<br />
* Ports: TCP or UDP ports may be used to match traffic. The source and the destination port is used to match the list of ports. Individual ports or port ranges can be used. <br />
:Example values are:<br />
:* 80<br />
::meaning exactly port 80<br />
:* 100-200<br />
::matches any port between 100 and 200<br />
:Up to 16 ports or port ranges may be defined.<br />
<br />
<br />
Either IP addresses or ports may be left empty, but if both are defined, they must match together. So for a specific packet the source or destination IP must match any entry in the list of IP addresses and the source or destination port must match any entry in the list of ports.<br />
<br />
<br />
<br />
=== Web interface ===<br />
<br />
The configuration tab allows to configure the custom protocols.<br />
<br />
Each of the 128 elements can be configured individually.<br />
<br />
Keep in mind that statistics are always accounted regarding their protocol ID so when changing a configuration for a specific ID, all previous statistics for that ID will still be available even if the IP/port combination would not have matched on the old traffic. It is recommended to restart the packet processing after modifying existing definitions.<br />
<br />
The following actions are possible in the configuration tab:<br />
<br />
* opens the configuration mask for that specific protocol.<br />
{| <br />
|[[File:Edit.png|60px|right]]<br />
|}<br />
<br />
* This button make the changes permanent and take effect. A success or error messages will appear indicating the result of the operation.<br />
{| <br />
|[[File:Save.png|150px|right]]<br />
|}<br />
<br />
<br />
* This button undo all configuration changes and restores the currently active configuration.<br />
{| <br />
|[[File:Reload.png|150px|right]]<br />
|}<br />
<br />
* This buttons allows to save the current configuration to a local file for later import.<br />
{| <br />
|[[File:Download.png|300px|right]]<br />
|}<br />
<br />
* This button imports the configuration file selected with the ‘Choose file’ button into the browser configuration. <br />
:The imported configuration must be saved to take effect.<br />
{| <br />
|[[File:Import.png|300px|right]]<br />
|}<br />
<br />
<br />
==== Editing a protocol ====<br />
<br />
The configuration mask for a specific protocol allows to change the parameters described above.<br />
<br />
* '''Layer 4 drop down box: Select the layer 4 protocol from the list of possible values.'''<br />
* This button adds another IP address or port to the corresponding list.<br />
{| <br />
| [[File:Plus.png|60px|right]]<br />
|}<br />
<br />
<br />
* This button removes the entry from the corresponding list.<br />
{| <br />
|[[File:Minus.png|60px|right]]<br />
|}<br />
<br />
<br />
* The configuration can be closed by clicking at this button.<br />
{| <br />
|<br />
[[File:Done.png|60px|right]]<br />
|}<br />
<br />
<br />
=== Examples ===<br />
<br />
# To define a custom protocol for an internal web server at IP 10.2.0.1, use the following settings:<br />
#* Name: int_server_1<br />
#* Layer 4 protocol: TCP<br />
#* IPs: 10.2.0.1<br />
#* Ports: 80<br />
# To define a custom protocol for a complete subnet 10.3.0.0 - 10.3.0.255, use the following settings:<br />
#* Name: office_computers<br />
#* Layer 4 protocol: Any layer 4 protocol<br />
#* IPs: 10.3.0.0/24<br />
#* Ports: none</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Incidents&diff=4371Incidents2023-08-04T13:46:49Z<p>Ralf: /* Interface burst incident */</p>
<hr />
<div><br />
[[File:Incidents_list.png|alt=|none|thumb|800x800px|Incident page]]<br />
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. <br />
<br />
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.<br />
<br />
Occurred incidents can be seen in the web interface, additionally reporting via the following notification channels is possible:<br />
* email<br />
* Apache Kafka<br />
* SNMP trap<br />
* syslog<br />
<br />
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.<br />
<br />
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].<br />
<br />
== Configuration of incident rules ==<br />
[[File:Incidents rules.png|thumb|600x600px|Rule configuration]]<br />
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.<br />
<br />
The page shows a table containing the existing rules and their configuration.<br />
<br />
Each existing rule can be modified by clicking on the pencil symbol, or deleted by clicking on the "minus" symbol.<br />
<br />
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.<br />
<br />
=== Add/modify a rule ===<br />
[[File:Incidents add rule.png|thumb|600x600px|Add rule dialog]]<br />
A rule is defined by the following settings:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
* Attributes: Attributes are used to make actual comparison of expected values vs. actual values.<br />
** 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<br />
** Up to four attributes can be added by clicking on the "Add attribute" button.<br />
** Multiple attributes must all match at the same time to let the rule create an incident.<br />
** Each attribute can be compared to a specific value, so that the actual value is lower, equal, or greater than a defined value.<br />
** Some attributes have an additional parameter, like a time span which defines how the attribute value is calculated.<br />
* 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.<br />
* IP filter: Depending on the selected trigger, the rule can be limited to a specific IP address. In firmware version >= 4.0, the IP filter can also be an IP subnet in the format IP/mask-length (Example: 10.0.0.0/8)<br />
* IP group: Depending on the selected trigger, the rule can be applied to an IP group instead of an individual IP address.<br />
* Virtual link group, IP and IP filter can also be used inversely by using the != comparator<br />
* 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.<br />
* 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.<br />
* Time Profiles: With version 4.0 the new setting time profiles was introduced. You are able to set a profile which defines the active time of an incident rule.<br />
* Traffic capturing [since version >= 4.0]: If supported by the trigger, the rule can be configured to capture the network traffic triggering the rule, including some extra time before and after the incident.<br />
** Possible options:<br />
*** Disabled: capturing is disabled for this rule<br />
*** Live traffic: capturing happens only for live network traffic<br />
*** Replay traffic: capturing happens only for replayed network traffic (from PCAP files)<br />
*** Always: capturing happens in all traffic processing types.<br />
** Extra capture time: configure the number of seconds before the start of the incident and after the end of the incident.<br />
*** If a time span parameter is used for attributes, the capture time includes this time duration as well.<br />
** 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.<br />
<br />
=== Available triggers ===<br />
{| class="wikitable"<br />
|+<br />
!Trigger name<br />
!Description<br />
!Attributes<br />
!Attribute usage<br />
|-<br />
|ARP: MAC change for an IP<br><br />
(arp_ip_mac_changed)<br />
|This trigger is checked on an ARP response and MAC address changed for a requested IP.<br />
|time_since_last_mac<br />
|optional<br />
|-<br />
|DNS: Server is not responding<br><br />
(dns_server_not_responding)<br />
|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.<br />
|time_since_first_unanswered_request<br />
|optional<br />
|-<br />
|DNS: Server response error<br><br />
(dns_server_response_error)<br />
|This trigger is checked when a DNS server responds a configured error of type format error, server failure or non-existing domain<br />
|error_type<br />
|mandatory<br />
|-<br />
|Global: Connection start<br><br />
(global_new_connection)<br />
|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.<br />
|l4_protocol, port_range, since_start_time<br />
|mandatory<br />
|-<br />
|Global: GPS synchronization status change<br><br />
(global_gps_sync_status_change)<br />
|This trigger is checked when the GPS clock synchronization status changes.<br />
|gps_sync_status<br />
|optional<br />
|-<br />
|Global: Number of connections<br><br />
(global_connections)<br />
|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.<br />
|new_connections<br />
|mandatory<br />
|-<br />
|Global: Regular expressions<br><br />
(global_regex_match)<br />
|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.<br />
|<br />
|no attributes are available for this trigger<br />
|-<br />
|Global: Ring buffer<br><br />
(global_ring_buffer)<br />
|This trigger is checked continuously to report changes in the ring buffer.<br />
|used_size, bytes_captured, bytes_dropped<br />
|mandatory<br />
|-<br />
|Global: Speed change of an interface<br><br />
(global_interface_speed_change)<br />
|This trigger is checked when the speed of an interfaces changes.<br />
|interface_speed<br />
|optional<br />
|-<br />
|Global: Speed mismatch for an interface pair<br><br />
(global_interface_speed_mismatch)<br />
|This trigger is checked when the status or speed of an interfaces changes and mismatches the speed of corresponding interface of a link.<br />
|link_speed_difference<br />
|optional<br />
|-<br />
|Global: Status change of an interface<br><br />
(global_interface_status_change)<br />
|This trigger is checked when the status of an interfaces changes.<br />
|interface_status<br />
|optional<br />
|-<br />
|Global: Traffic<br><br />
(global_traffic)<br />
|This trigger is checked continuously for the total traffic of the device. The update interval is defined by the timespan parameter of the attributes.<br />
|throughput, throughput_increase, packet_rate, packet_rate_increase<br />
|mandatory<br />
|-<br />
|IEC104: Response times<br><br />
(iec104_response_times)<br />
|This trigger is checked whenever an IEC104 ACTCON reply for an ACT has been seen.<br />
|response_time<br />
|mandatory<br />
|-<br />
|IEC104: Traffic<br><br />
(iec104_traffic)<br />
|This trigger is checked continuously for each IEC104 connection. The update interval is defined by the timespan parameter of the attributes.<br />
|percent_loss, absolute_loss, not_in_order<br />
|mandatory<br />
|-<br />
|IP: Connection end<br><br />
(ip_flow_end)<br />
|This trigger checks the attributes whenever an IP flow ended.<br />
|total_packets, total_bytes, tcp_handshake_time, percent_retransmissions, zero_window_packets, duration<br />
|mandatory<br />
|-<br />
|IP: Connection start<br><br />
(ip_flow_start)<br />
|This trigger checks the attributes whenever an IP flow starts.<br />
|new_connections, geolocation<br />
|mandatory<br />
|-<br />
|IP: Local IP with multiple MAC addresses<br><br />
(ip_local_ip_multiple_macs)<br />
|This trigger is checked on each new flow of a local IP address and more than one MAC address uses this IP.<br />
|mac_count<br />
|optional<br />
|-<br />
|IP: New local IP address<br><br />
(ip_new_local_ip)<br />
|This trigger is checked once for each new IP belonging to a private network address range.<br />
|since_start_time<br />
|optional<br />
|-<br />
|IP: New local L7 protocol<br><br />
(ip_new_local_l7_protocol)<br />
|This trigger is checked once for each new l7 protocol used by a local IP.<br />
|since_start_time<br />
|optional<br />
|-<br />
|IP: TCP handshake<br><br />
(ip_tcp_handshake)<br />
|This trigger is checked after successful TCP handshake.<br />
|handshake_time, server_handshake_time, client_handshake_time<br />
|mandatory<br />
|-<br />
|IP: Traffic on IP addresses<br><br />
(ip_traffic)<br />
|This trigger is checked continuously for each active IP or IP group. The update interval is defined by the timespan parameter of the attributes.<br />
|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<br />
|mandatory<br />
|-<br />
|LACP: Status change of a channel<br><br />
(lacp_channel_status_change)<br />
|This trigger is checked when the status of a LACP port channel changes.<br />
|channel_status<br />
|optional<br />
|-<br />
|MAC: New L7 protocol<br><br />
(mac_new_l7_protocol)<br />
|This trigger is checked when a unicast MAC address uses a l7 protocol for the first time.<br />
|since_start_time<br />
|optional<br />
|-<br />
|MAC: New MAC address<br><br />
(mac_new_address)<br />
|This trigger is checked once when a new unicast MAC address appears for the first time.<br />
|since_start_time<br />
|optional<br />
|-<br />
|MAC: Traffic on MAC addresses<br><br />
(mac_traffic)<br />
|This trigger is checked continuously for each active MAC address. The update interval is defined by the timespan parameter of the attributes.<br />
|broadcast_packet_rate<br />
|mandatory<br />
|-<br />
|PPPoE: PPPoE Discovery traffic<br><br />
(pppoe_discovery_traffic)<br />
|This trigger is checked continuously for PPPoE discovery traffic. The update interval is defined by the timespan parameter of the attributes.<br />
|pppoe_discovery_packets<br />
|mandatory<br />
|-<br />
|Profinet: Traffic of Profinet devices<br><br />
(profinet_traffic)<br />
|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.<br />
|alarms_low, alarms_high, errors, frames_lost, frames_repeated, frames_wrong_sequence, max_jitter<br />
|mandatory<br />
|-<br />
|PTP: Timestamp packet<br><br />
(ptp_timestamp_packet)<br />
|This trigger is checked when a PTP packet containing a valid timestamp is seen.<br />
|time_offset<br />
|mandatory<br />
|-<br />
|QOS: Traffic on QoS classes<br><br />
(qos_traffic)<br />
|This trigger is checked continuously for each active QoS class. The update interval is defined by the timespan parameter of the attributes.<br />
|throughput<br />
|mandatory<br />
|-<br />
|RTP: Traffic for RTP connections<br><br />
(rtp_traffic)<br />
|This trigger is checked continuously for traffic of each RTP connection. The update interval is defined by the timespan parameter of the attributes.<br />
|jitter, percent_loss<br />
|mandatory<br />
|-<br />
|SIP: Call end<br><br />
(sip_call_end)<br />
|This trigger is checked when a SIP call ended.<br />
|duration, status, mos, percent_loss, jitter, total_packets, total_bytes, total_caller_packets, total_callee_packets, total_caller_bytes, total_callee_bytes<br />
|mandatory<br />
|-<br />
|SMB: SMB1 negotiation<br><br />
(smb_v1_negotiation)<br />
|This trigger is executed at the beginning of each SMB connection and checks whether insecure SMB1 has been negotiated.<br />
|<br />
|none<br />
|-<br />
|SSL: Handshake<br><br />
(ssl_handshake)<br />
|This trigger is checked during handshake of each SSL connection.<br />
|certificate_expires<br />
|mandatory<br />
|-<br />
|SSL: SSL/TLS version negotiation<br><br />
(tls_version)<br />
|This trigger is checked during version negotiation at handshake of each SSL connection.<br />
|used_tls_version<br />
|mandatory<br />
|}<br />
<br />
==== Special trigger properties ====<br />
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.<br />
<br />
# Repeating incidents: The following triggers will be evaluated every configured time span and will be re-issued whenever the configured attributes match.<br />
## ip_traffic<br />
## mac_traffic<br />
## qos_traffic<br />
## rtp_traffic<br />
# Start/stop incidents: The following triggers are reported once the configured attributes match and for a second time when the attributes no longer match.<br />
## global_traffic<br />
<br />
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.<br />
<br />
For start/stop incidents, you will only see two rule hits and the incident description will state the start and stop time.<br />
<br />
=== Available attributes ===<br />
<br />
* '''absolute_loss''': Count of lost packets for IEC104 connection.<br />
* '''alarms_low''', '''alarms_high''': Whether an low/high alarm occurred for a Profinet device.<br />
* '''broadcast_packet_rate''': The attribute is the number of packets per second on average over the configured timespan for MAC broadcast packets.<br />
* '''bytes_captured''': The amount of bytes captured by a ring buffer in the given timespan.<br />
* '''bytes_dropped''': The amount of bytes dropped by a ring buffer in the given timespan.<br />
* '''certificate_expires''': This is the number of days until the certificate expires. If the certificate is already expired, the value is <= 0.<br />
* '''channel_status''': 0 means that the LACP port channel is not synchronized, 1 means that the LACP port channel is synchronized.<br />
* '''duration''':<br />
** ''IP: Connection end'': The time between first and last packet of the flow.<br />
** ''SIP: Call end'': The call duration.<br />
* '''errors''':<br />
** ''Profinet: Traffic of Profinet devices: Whether errors occured.<br />
* '''error_type''': equal or not equal to:<br />
** Format Error: DNS responds a format error.<br />
** Non-existent Domain: DNS could not find queried domain name.<br />
** Server Failure: DNS responds server failure.<br />
* '''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.<br />
* '''geolocation''': checks if a country is part of the connection<br />
** '''Direction''': The direction of traffic<br />
*** ''from'': Traffic is coming ''from the'' specified country<br />
*** ''to'': Traffic is going ''to'' the specified country<br />
*** ''any:'' The specified country is on either side of the connection, or on neither side if the inequality is selected.<br />
* '''gps_sync_status''': 0 means that the GPS clock in not synchronized, 1 means that the GPS clock is synchronized.<br />
* '''handshake_time''': The TCP handshake time between the first SYN packet and the ACK packet for the SYN/ACK packet of the server.<br />
** '''client_handshake_time''': The TCP handshake time between the SYN/ACK packet of the server and the ACK packet of the client.<br />
** '''server_handshake_time''': The TCP handshake time between the first SYN packet of the client and the SYN/ACK packet of the server.<br />
* '''interface_speed''': The current speed of the interface in Mbit/s.<br />
* '''interface_status''': 0 means interface is down, 1 means interface is up.<br />
* '''jitter''':<br />
** ''SIP: Call end'': The average jitter of the call, using the maximum value of both call sides.<br />
** ''RTP: Traffic for RTP connections'': The average jitter of the RTP connection for the given timespan, using the maximum value of both directions.<br />
* '''l4_protocol''': The layer 4 protocol. Can be TCP, UDP or other.<br />
* '''link_speed_difference''': This is the absolute difference between the speeds of both interface of a link in Mbit/s.<br />
* '''mac_count''': The number of different MAC addresses for the corresponding IP address.<br />
* '''max_jitter''': The max jitter value for a Profinet device in % in a given timespan.<br />
* '''mos''': The average MOS quality value of the call, using the minimum of both call sides.<br />
* '''new_connections''': The amount of newly created connections (TCP and UDP) for the given timespan.<br />
* '''not_in_order''': Count of not in order packets for IEC104 connection. The sequence number could be too high, too low or repeated.<br />
* '''packet_rate''': The packet rate in packets per second on average during the configured timespan.<br />
* '''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.<br />
* '''percent_loss''':<br />
** ''SIP: Call end'': The percentage of RTP packet loss for the call, accounting packets from both directions.<br />
** ''RTP: Traffic for RTP connections'': The percentage of RTP packet loss for the given timespan, accounting packets from both directions of the RTP connection.<br />
** ''IEC104: Traffic for IEC104 connections'': The percentage of IEC104 packet loss for the given timespan, accounting packets from both directions of the IEC104 connection.<br />
* '''percent_transmissions''': The amount of TCP retransmission as a percentage of the total bytes.<br />
* '''port_range''': The TCP or UDP port. Can be also a range, e.g. 80,443,8443-8445<br />
* '''pppoe_discovery_packets''': The number of PPPoE discovery packets seen during the configured timespan.<br />
* '''response_time''': The response time of IEC104 ACT requests and ACTCON replies.<br />
* '''retransmission_ratio''': The TCP retransmission ratio seen in the configured timespan.<br />
* '''since_start_time''':<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
* '''status''': The call status code (a three digit number, like 200 for Success)<br />
* '''tcp_handshake_time''': The TCP handshake time.<br />
* '''tcp_fin_packets''': The number of TCP FIN packets (RX + TX) seen in the configured timespan.<br />
* '''tcp_rst_packets''': The number of TCP RST packets (RX + TX) seen in the configured timespan.<br />
* '''tcp_syn_packets''': The number of TCP SYN packets (RX + TX) seen in the configured timespan.<br />
* '''throughput''': The throughput bandwidth in bit/s on average during the configured timespan.<br />
* '''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.<br />
* '''time_offset''': The time offset between the local time and the timestamp seen in the PTP packet.<br />
* '''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.<br />
* '''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.<br />
* '''total_bytes''':<br />
** ''IP: Connection end'': The total number of bytes seen for both directions of the flow.<br />
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of bytes seen in the configured timespan.<br />
** '''total_callee_bytes''': The number of bytes seen for the callee of the call.<br />
** '''total_caller_bytes''': The number of bytes seen for the caller of the call.<br />
* '''total_packets''':<br />
** ''IP: Connection end'': The total number of packets seen for both directions of the flow.<br />
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of packets seen in the configured timespan.<br />
** '''total_callee_packets''': The number of packets seen for the callee of the call.<br />
** '''total_caller_packets''': The number of packets seen for the caller of the call.<br />
* '''type''': The type of PPPoE discovery packet (PADI, PADO, PADR, PADS, PADT or any).<br />
* '''used_size''': The percentage of the ring buffer that needs to be filled.<br />
* '''used_tls_version''': The TLS version (SSl 3.0, TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3)<br />
* '''zero_window_packets''': The number of packets with a TCP window of 0 for both directions of the flow.<br />
* '''zero_window_packets''': The number of zero window packets seen in the configured timespan.<br />
<br />
=== Capture settings ===<br />
Since firmware version 4.0, it is possible to automatically capture traffic for occurred incidents. These global settings control where capture files are stored and the capturing itself can be enabled for each rule separately.<br />
<br />
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.<br />
<br />
Available settings:<br />
<br />
* 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.<br />
* Storage device: Select the storage device where the captures should be stored on.<br />
* Storage directory: Enter the directory where capture files should be stored or leave empty to use the top level directory.<br />
* 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.<br />
* 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).<br />
<br />
== Time Profiles ==<br />
Incident rules can be active configured to be active in configured time spans (time profiles).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Channel configuration ==<br />
[[File:Incidents channels.png|thumb|600x600px|Channel configuration]]<br />
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.<br />
<br />
Each channel can be of type:<br />
<br />
'''email''' Incidents will be sent to the email address configured in the [[Global settings]].<br />
<br />
'''kafka''' The incidents are sent to a topic on the configured Apache Kafka server. Firmware >= 4.0. The message is the same as for syslog.<br />
* Bootstrap Server: hostname/ip:port of a Kafka Broker or multiple Brokers separated by comma<br />
* Protocol: Plaintext (no authentication, no encryption), SASL Paintext (Plain authentication, no encryption), SASL SSL (Plain authentication, TLS/SSL encryption)<br />
* Ignore TLS Certificate: Ignore the TLS Certificate of the Brokers (only SASL SSL)<br />
* Username: Broker Login (only SASL)<br />
* Password: Broker Login (only SASL)<br />
* Topic: The name of the topic into which the Incidents are sent.<br />
<br />
'''snmp_trap''' Incidents will be sent to the configured SNMP trap receiver (firmware >= 4.0). A MIB file with the Allegro Network Multimeter SNMP trap definitions is available for download in the channel configuration dialog.<br />
* Version: Supported SNMP version of the trap receiver (SNMP v2c or SNMP v3)<br />
* Trap receiver (manager) hostname/IP: The trap receiver hostname or IP address<br />
<br />
''SNMP v2c'':<br />
* Community name: SNMP community name expected by the trap receiver<br />
<br />
''SNMP v3'':<br />
* Authentication protocol: Protocol for authenticated messages (MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512)<br />
* Authentication password: Pass phrase for authenticated messages<br />
* Privacy protocol: Protocol for message encryption (AES, DES)<br />
* Privacy password: Pass phrase for message encryption<br />
* Security name: Security name for authenticated SNMP messages<br />
* Security level: Security level for SNMP messages (noAuthNoPriv, authNoPriv, authPriv)<br />
* Engine ID: Authoritative (security) engineID (hexadecimal number)<br />
<br />
'''syslog''' Incidents will be sent to the configured syslog server via TCP on any TCP or UDP port.<br />
<br />
<br />
[[File:Incidents add channel.png|thumb|alt=|none|Adding a new channel]]<br />
Each channel also uses a minimum severity setting, so only incidents are reported which are of at least that severity.<br />
<br />
Each channel can be configured to only handle incidents from live traffic or from replayed traffic.<br />
<br />
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.<br />
<br />
== Other settings ==<br />
<br />
=== Interface burst incident ===<br />
[[File:Incidents others.png|thumb|600x600px|Other incidents]]<br />
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.<br />
<br />
The incident generation can be configured in the "Other settings" tab as follows:<br />
* '''Report "throughput threshold exceeded" with severity''': report an incident with the selected severity level if the throughput of any network interface exceeded.<br />
* '''Throughput threshold (Mbit/s)''': The threshold is configured in Mbit/s.<br />
* '''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.<br />
* '''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.<br />
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.<br />
<br />
=== Generic incident settings ===<br />
This section allows to modify generic settings regarding the incident feature:<br />
<br />
* '''Maximum number of stored incidents''': This value defines how many incidents are stored before old incidents are removed. Increasing this value also increased the amount of memory reserved for this feature.<br>The corresponding value for the active setting is shown below, changing the configuration value requires a restart of the packet processing to take affect.<br />
<br />
== Occured incidents ==<br />
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.<br />
[[File:Incidents list filter.png|thumb|600x600px|Filter incidents by severity or trigger]]<br />
The list can also be filtered for the subject of the incident.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Statistics about incident rules ==<br />
[[File:Incidents stats.png|thumb|600x600px|Statistics about rules]]<br />
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.<br />
<br />
== Incident list per measurement modules ==<br />
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.<br />
<br />
== Limitations ==<br />
Some technical limitations apply:<br />
<br />
* 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.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Incidents&diff=4370Incidents2023-08-04T13:45:20Z<p>Ralf: /* Generic incident settings */</p>
<hr />
<div><br />
[[File:Incidents_list.png|alt=|none|thumb|800x800px|Incident page]]<br />
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. <br />
<br />
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.<br />
<br />
Occurred incidents can be seen in the web interface, additionally reporting via the following notification channels is possible:<br />
* email<br />
* Apache Kafka<br />
* SNMP trap<br />
* syslog<br />
<br />
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.<br />
<br />
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].<br />
<br />
== Configuration of incident rules ==<br />
[[File:Incidents rules.png|thumb|600x600px|Rule configuration]]<br />
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.<br />
<br />
The page shows a table containing the existing rules and their configuration.<br />
<br />
Each existing rule can be modified by clicking on the pencil symbol, or deleted by clicking on the "minus" symbol.<br />
<br />
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.<br />
<br />
=== Add/modify a rule ===<br />
[[File:Incidents add rule.png|thumb|600x600px|Add rule dialog]]<br />
A rule is defined by the following settings:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
* Attributes: Attributes are used to make actual comparison of expected values vs. actual values.<br />
** 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<br />
** Up to four attributes can be added by clicking on the "Add attribute" button.<br />
** Multiple attributes must all match at the same time to let the rule create an incident.<br />
** Each attribute can be compared to a specific value, so that the actual value is lower, equal, or greater than a defined value.<br />
** Some attributes have an additional parameter, like a time span which defines how the attribute value is calculated.<br />
* 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.<br />
* IP filter: Depending on the selected trigger, the rule can be limited to a specific IP address. In firmware version >= 4.0, the IP filter can also be an IP subnet in the format IP/mask-length (Example: 10.0.0.0/8)<br />
* IP group: Depending on the selected trigger, the rule can be applied to an IP group instead of an individual IP address.<br />
* Virtual link group, IP and IP filter can also be used inversely by using the != comparator<br />
* 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.<br />
* 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.<br />
* Time Profiles: With version 4.0 the new setting time profiles was introduced. You are able to set a profile which defines the active time of an incident rule.<br />
* Traffic capturing [since version >= 4.0]: If supported by the trigger, the rule can be configured to capture the network traffic triggering the rule, including some extra time before and after the incident.<br />
** Possible options:<br />
*** Disabled: capturing is disabled for this rule<br />
*** Live traffic: capturing happens only for live network traffic<br />
*** Replay traffic: capturing happens only for replayed network traffic (from PCAP files)<br />
*** Always: capturing happens in all traffic processing types.<br />
** Extra capture time: configure the number of seconds before the start of the incident and after the end of the incident.<br />
*** If a time span parameter is used for attributes, the capture time includes this time duration as well.<br />
** 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.<br />
<br />
=== Available triggers ===<br />
{| class="wikitable"<br />
|+<br />
!Trigger name<br />
!Description<br />
!Attributes<br />
!Attribute usage<br />
|-<br />
|ARP: MAC change for an IP<br><br />
(arp_ip_mac_changed)<br />
|This trigger is checked on an ARP response and MAC address changed for a requested IP.<br />
|time_since_last_mac<br />
|optional<br />
|-<br />
|DNS: Server is not responding<br><br />
(dns_server_not_responding)<br />
|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.<br />
|time_since_first_unanswered_request<br />
|optional<br />
|-<br />
|DNS: Server response error<br><br />
(dns_server_response_error)<br />
|This trigger is checked when a DNS server responds a configured error of type format error, server failure or non-existing domain<br />
|error_type<br />
|mandatory<br />
|-<br />
|Global: Connection start<br><br />
(global_new_connection)<br />
|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.<br />
|l4_protocol, port_range, since_start_time<br />
|mandatory<br />
|-<br />
|Global: GPS synchronization status change<br><br />
(global_gps_sync_status_change)<br />
|This trigger is checked when the GPS clock synchronization status changes.<br />
|gps_sync_status<br />
|optional<br />
|-<br />
|Global: Number of connections<br><br />
(global_connections)<br />
|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.<br />
|new_connections<br />
|mandatory<br />
|-<br />
|Global: Regular expressions<br><br />
(global_regex_match)<br />
|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.<br />
|<br />
|no attributes are available for this trigger<br />
|-<br />
|Global: Ring buffer<br><br />
(global_ring_buffer)<br />
|This trigger is checked continuously to report changes in the ring buffer.<br />
|used_size, bytes_captured, bytes_dropped<br />
|mandatory<br />
|-<br />
|Global: Speed change of an interface<br><br />
(global_interface_speed_change)<br />
|This trigger is checked when the speed of an interfaces changes.<br />
|interface_speed<br />
|optional<br />
|-<br />
|Global: Speed mismatch for an interface pair<br><br />
(global_interface_speed_mismatch)<br />
|This trigger is checked when the status or speed of an interfaces changes and mismatches the speed of corresponding interface of a link.<br />
|link_speed_difference<br />
|optional<br />
|-<br />
|Global: Status change of an interface<br><br />
(global_interface_status_change)<br />
|This trigger is checked when the status of an interfaces changes.<br />
|interface_status<br />
|optional<br />
|-<br />
|Global: Traffic<br><br />
(global_traffic)<br />
|This trigger is checked continuously for the total traffic of the device. The update interval is defined by the timespan parameter of the attributes.<br />
|throughput, throughput_increase, packet_rate, packet_rate_increase<br />
|mandatory<br />
|-<br />
|IEC104: Response times<br><br />
(iec104_response_times)<br />
|This trigger is checked whenever an IEC104 ACTCON reply for an ACT has been seen.<br />
|response_time<br />
|mandatory<br />
|-<br />
|IEC104: Traffic<br><br />
(iec104_traffic)<br />
|This trigger is checked continuously for each IEC104 connection. The update interval is defined by the timespan parameter of the attributes.<br />
|percent_loss, absolute_loss, not_in_order<br />
|mandatory<br />
|-<br />
|IP: Connection end<br><br />
(ip_flow_end)<br />
|This trigger checks the attributes whenever an IP flow ended.<br />
|total_packets, total_bytes, tcp_handshake_time, percent_retransmissions, zero_window_packets, duration<br />
|mandatory<br />
|-<br />
|IP: Connection start<br><br />
(ip_flow_start)<br />
|This trigger checks the attributes whenever an IP flow starts.<br />
|new_connections, geolocation<br />
|mandatory<br />
|-<br />
|IP: Local IP with multiple MAC addresses<br><br />
(ip_local_ip_multiple_macs)<br />
|This trigger is checked on each new flow of a local IP address and more than one MAC address uses this IP.<br />
|mac_count<br />
|optional<br />
|-<br />
|IP: New local IP address<br><br />
(ip_new_local_ip)<br />
|This trigger is checked once for each new IP belonging to a private network address range.<br />
|since_start_time<br />
|optional<br />
|-<br />
|IP: New local L7 protocol<br><br />
(ip_new_local_l7_protocol)<br />
|This trigger is checked once for each new l7 protocol used by a local IP.<br />
|since_start_time<br />
|optional<br />
|-<br />
|IP: TCP handshake<br><br />
(ip_tcp_handshake)<br />
|This trigger is checked after successful TCP handshake.<br />
|handshake_time, server_handshake_time, client_handshake_time<br />
|mandatory<br />
|-<br />
|IP: Traffic on IP addresses<br><br />
(ip_traffic)<br />
|This trigger is checked continuously for each active IP or IP group. The update interval is defined by the timespan parameter of the attributes.<br />
|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<br />
|mandatory<br />
|-<br />
|LACP: Status change of a channel<br><br />
(lacp_channel_status_change)<br />
|This trigger is checked when the status of a LACP port channel changes.<br />
|channel_status<br />
|optional<br />
|-<br />
|MAC: New L7 protocol<br><br />
(mac_new_l7_protocol)<br />
|This trigger is checked when a unicast MAC address uses a l7 protocol for the first time.<br />
|since_start_time<br />
|optional<br />
|-<br />
|MAC: New MAC address<br><br />
(mac_new_address)<br />
|This trigger is checked once when a new unicast MAC address appears for the first time.<br />
|since_start_time<br />
|optional<br />
|-<br />
|MAC: Traffic on MAC addresses<br><br />
(mac_traffic)<br />
|This trigger is checked continuously for each active MAC address. The update interval is defined by the timespan parameter of the attributes.<br />
|broadcast_packet_rate<br />
|mandatory<br />
|-<br />
|PPPoE: PPPoE Discovery traffic<br><br />
(pppoe_discovery_traffic)<br />
|This trigger is checked continuously for PPPoE discovery traffic. The update interval is defined by the timespan parameter of the attributes.<br />
|pppoe_discovery_packets<br />
|mandatory<br />
|-<br />
|Profinet: Traffic of Profinet devices<br><br />
(profinet_traffic)<br />
|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.<br />
|alarms_low, alarms_high, errors, frames_lost, frames_repeated, frames_wrong_sequence, max_jitter<br />
|mandatory<br />
|-<br />
|PTP: Timestamp packet<br><br />
(ptp_timestamp_packet)<br />
|This trigger is checked when a PTP packet containing a valid timestamp is seen.<br />
|time_offset<br />
|mandatory<br />
|-<br />
|QOS: Traffic on QoS classes<br><br />
(qos_traffic)<br />
|This trigger is checked continuously for each active QoS class. The update interval is defined by the timespan parameter of the attributes.<br />
|throughput<br />
|mandatory<br />
|-<br />
|RTP: Traffic for RTP connections<br><br />
(rtp_traffic)<br />
|This trigger is checked continuously for traffic of each RTP connection. The update interval is defined by the timespan parameter of the attributes.<br />
|jitter, percent_loss<br />
|mandatory<br />
|-<br />
|SIP: Call end<br><br />
(sip_call_end)<br />
|This trigger is checked when a SIP call ended.<br />
|duration, status, mos, percent_loss, jitter, total_packets, total_bytes, total_caller_packets, total_callee_packets, total_caller_bytes, total_callee_bytes<br />
|mandatory<br />
|-<br />
|SMB: SMB1 negotiation<br><br />
(smb_v1_negotiation)<br />
|This trigger is executed at the beginning of each SMB connection and checks whether insecure SMB1 has been negotiated.<br />
|<br />
|none<br />
|-<br />
|SSL: Handshake<br><br />
(ssl_handshake)<br />
|This trigger is checked during handshake of each SSL connection.<br />
|certificate_expires<br />
|mandatory<br />
|-<br />
|SSL: SSL/TLS version negotiation<br><br />
(tls_version)<br />
|This trigger is checked during version negotiation at handshake of each SSL connection.<br />
|used_tls_version<br />
|mandatory<br />
|}<br />
<br />
==== Special trigger properties ====<br />
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.<br />
<br />
# Repeating incidents: The following triggers will be evaluated every configured time span and will be re-issued whenever the configured attributes match.<br />
## ip_traffic<br />
## mac_traffic<br />
## qos_traffic<br />
## rtp_traffic<br />
# Start/stop incidents: The following triggers are reported once the configured attributes match and for a second time when the attributes no longer match.<br />
## global_traffic<br />
<br />
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.<br />
<br />
For start/stop incidents, you will only see two rule hits and the incident description will state the start and stop time.<br />
<br />
=== Available attributes ===<br />
<br />
* '''absolute_loss''': Count of lost packets for IEC104 connection.<br />
* '''alarms_low''', '''alarms_high''': Whether an low/high alarm occurred for a Profinet device.<br />
* '''broadcast_packet_rate''': The attribute is the number of packets per second on average over the configured timespan for MAC broadcast packets.<br />
* '''bytes_captured''': The amount of bytes captured by a ring buffer in the given timespan.<br />
* '''bytes_dropped''': The amount of bytes dropped by a ring buffer in the given timespan.<br />
* '''certificate_expires''': This is the number of days until the certificate expires. If the certificate is already expired, the value is <= 0.<br />
* '''channel_status''': 0 means that the LACP port channel is not synchronized, 1 means that the LACP port channel is synchronized.<br />
* '''duration''':<br />
** ''IP: Connection end'': The time between first and last packet of the flow.<br />
** ''SIP: Call end'': The call duration.<br />
* '''errors''':<br />
** ''Profinet: Traffic of Profinet devices: Whether errors occured.<br />
* '''error_type''': equal or not equal to:<br />
** Format Error: DNS responds a format error.<br />
** Non-existent Domain: DNS could not find queried domain name.<br />
** Server Failure: DNS responds server failure.<br />
* '''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.<br />
* '''geolocation''': checks if a country is part of the connection<br />
** '''Direction''': The direction of traffic<br />
*** ''from'': Traffic is coming ''from the'' specified country<br />
*** ''to'': Traffic is going ''to'' the specified country<br />
*** ''any:'' The specified country is on either side of the connection, or on neither side if the inequality is selected.<br />
* '''gps_sync_status''': 0 means that the GPS clock in not synchronized, 1 means that the GPS clock is synchronized.<br />
* '''handshake_time''': The TCP handshake time between the first SYN packet and the ACK packet for the SYN/ACK packet of the server.<br />
** '''client_handshake_time''': The TCP handshake time between the SYN/ACK packet of the server and the ACK packet of the client.<br />
** '''server_handshake_time''': The TCP handshake time between the first SYN packet of the client and the SYN/ACK packet of the server.<br />
* '''interface_speed''': The current speed of the interface in Mbit/s.<br />
* '''interface_status''': 0 means interface is down, 1 means interface is up.<br />
* '''jitter''':<br />
** ''SIP: Call end'': The average jitter of the call, using the maximum value of both call sides.<br />
** ''RTP: Traffic for RTP connections'': The average jitter of the RTP connection for the given timespan, using the maximum value of both directions.<br />
* '''l4_protocol''': The layer 4 protocol. Can be TCP, UDP or other.<br />
* '''link_speed_difference''': This is the absolute difference between the speeds of both interface of a link in Mbit/s.<br />
* '''mac_count''': The number of different MAC addresses for the corresponding IP address.<br />
* '''max_jitter''': The max jitter value for a Profinet device in % in a given timespan.<br />
* '''mos''': The average MOS quality value of the call, using the minimum of both call sides.<br />
* '''new_connections''': The amount of newly created connections (TCP and UDP) for the given timespan.<br />
* '''not_in_order''': Count of not in order packets for IEC104 connection. The sequence number could be too high, too low or repeated.<br />
* '''packet_rate''': The packet rate in packets per second on average during the configured timespan.<br />
* '''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.<br />
* '''percent_loss''':<br />
** ''SIP: Call end'': The percentage of RTP packet loss for the call, accounting packets from both directions.<br />
** ''RTP: Traffic for RTP connections'': The percentage of RTP packet loss for the given timespan, accounting packets from both directions of the RTP connection.<br />
** ''IEC104: Traffic for IEC104 connections'': The percentage of IEC104 packet loss for the given timespan, accounting packets from both directions of the IEC104 connection.<br />
* '''percent_transmissions''': The amount of TCP retransmission as a percentage of the total bytes.<br />
* '''port_range''': The TCP or UDP port. Can be also a range, e.g. 80,443,8443-8445<br />
* '''pppoe_discovery_packets''': The number of PPPoE discovery packets seen during the configured timespan.<br />
* '''response_time''': The response time of IEC104 ACT requests and ACTCON replies.<br />
* '''retransmission_ratio''': The TCP retransmission ratio seen in the configured timespan.<br />
* '''since_start_time''':<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
* '''status''': The call status code (a three digit number, like 200 for Success)<br />
* '''tcp_handshake_time''': The TCP handshake time.<br />
* '''tcp_fin_packets''': The number of TCP FIN packets (RX + TX) seen in the configured timespan.<br />
* '''tcp_rst_packets''': The number of TCP RST packets (RX + TX) seen in the configured timespan.<br />
* '''tcp_syn_packets''': The number of TCP SYN packets (RX + TX) seen in the configured timespan.<br />
* '''throughput''': The throughput bandwidth in bit/s on average during the configured timespan.<br />
* '''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.<br />
* '''time_offset''': The time offset between the local time and the timestamp seen in the PTP packet.<br />
* '''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.<br />
* '''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.<br />
* '''total_bytes''':<br />
** ''IP: Connection end'': The total number of bytes seen for both directions of the flow.<br />
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of bytes seen in the configured timespan.<br />
** '''total_callee_bytes''': The number of bytes seen for the callee of the call.<br />
** '''total_caller_bytes''': The number of bytes seen for the caller of the call.<br />
* '''total_packets''':<br />
** ''IP: Connection end'': The total number of packets seen for both directions of the flow.<br />
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of packets seen in the configured timespan.<br />
** '''total_callee_packets''': The number of packets seen for the callee of the call.<br />
** '''total_caller_packets''': The number of packets seen for the caller of the call.<br />
* '''type''': The type of PPPoE discovery packet (PADI, PADO, PADR, PADS, PADT or any).<br />
* '''used_size''': The percentage of the ring buffer that needs to be filled.<br />
* '''used_tls_version''': The TLS version (SSl 3.0, TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3)<br />
* '''zero_window_packets''': The number of packets with a TCP window of 0 for both directions of the flow.<br />
* '''zero_window_packets''': The number of zero window packets seen in the configured timespan.<br />
<br />
=== Capture settings ===<br />
Since firmware version 4.0, it is possible to automatically capture traffic for occurred incidents. These global settings control where capture files are stored and the capturing itself can be enabled for each rule separately.<br />
<br />
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.<br />
<br />
Available settings:<br />
<br />
* 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.<br />
* Storage device: Select the storage device where the captures should be stored on.<br />
* Storage directory: Enter the directory where capture files should be stored or leave empty to use the top level directory.<br />
* 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.<br />
* 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).<br />
<br />
== Time Profiles ==<br />
Incident rules can be active configured to be active in configured time spans (time profiles).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Channel configuration ==<br />
[[File:Incidents channels.png|thumb|600x600px|Channel configuration]]<br />
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.<br />
<br />
Each channel can be of type:<br />
<br />
'''email''' Incidents will be sent to the email address configured in the [[Global settings]].<br />
<br />
'''kafka''' The incidents are sent to a topic on the configured Apache Kafka server. Firmware >= 4.0. The message is the same as for syslog.<br />
* Bootstrap Server: hostname/ip:port of a Kafka Broker or multiple Brokers separated by comma<br />
* Protocol: Plaintext (no authentication, no encryption), SASL Paintext (Plain authentication, no encryption), SASL SSL (Plain authentication, TLS/SSL encryption)<br />
* Ignore TLS Certificate: Ignore the TLS Certificate of the Brokers (only SASL SSL)<br />
* Username: Broker Login (only SASL)<br />
* Password: Broker Login (only SASL)<br />
* Topic: The name of the topic into which the Incidents are sent.<br />
<br />
'''snmp_trap''' Incidents will be sent to the configured SNMP trap receiver (firmware >= 4.0). A MIB file with the Allegro Network Multimeter SNMP trap definitions is available for download in the channel configuration dialog.<br />
* Version: Supported SNMP version of the trap receiver (SNMP v2c or SNMP v3)<br />
* Trap receiver (manager) hostname/IP: The trap receiver hostname or IP address<br />
<br />
''SNMP v2c'':<br />
* Community name: SNMP community name expected by the trap receiver<br />
<br />
''SNMP v3'':<br />
* Authentication protocol: Protocol for authenticated messages (MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512)<br />
* Authentication password: Pass phrase for authenticated messages<br />
* Privacy protocol: Protocol for message encryption (AES, DES)<br />
* Privacy password: Pass phrase for message encryption<br />
* Security name: Security name for authenticated SNMP messages<br />
* Security level: Security level for SNMP messages (noAuthNoPriv, authNoPriv, authPriv)<br />
* Engine ID: Authoritative (security) engineID (hexadecimal number)<br />
<br />
'''syslog''' Incidents will be sent to the configured syslog server via TCP on any TCP or UDP port.<br />
<br />
<br />
[[File:Incidents add channel.png|thumb|alt=|none|Adding a new channel]]<br />
Each channel also uses a minimum severity setting, so only incidents are reported which are of at least that severity.<br />
<br />
Each channel can be configured to only handle incidents from live traffic or from replayed traffic.<br />
<br />
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.<br />
<br />
== Other settings ==<br />
<br />
=== Interface burst incident ===<br />
[[File:Incidents others.png|thumb|600x600px|Other incidents]]<br />
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.<br />
<br />
The incident generation can be configured in the "Other settings" tab as follows:<br />
* '''Report "throughput threshold exceeded" with severity''': report an incident with the selected severity level if the throughput of any network interface exceeded.<br />
* '''Throughput threshold (Mbit/s)''': The threshold is configured in Mbit/s.<br />
* '''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.<br />
* '''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.<br />
<br />
=== Generic incident settings ===<br />
This section allows to modify generic settings regarding the incident feature:<br />
<br />
* '''Maximum number of stored incidents''': This value defines how many incidents are stored before old incidents are removed. Increasing this value also increased the amount of memory reserved for this feature.<br>The corresponding value for the active setting is shown below, changing the configuration value requires a restart of the packet processing to take affect.<br />
<br />
== Occured incidents ==<br />
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.<br />
[[File:Incidents list filter.png|thumb|600x600px|Filter incidents by severity or trigger]]<br />
The list can also be filtered for the subject of the incident.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Statistics about incident rules ==<br />
[[File:Incidents stats.png|thumb|600x600px|Statistics about rules]]<br />
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.<br />
<br />
== Incident list per measurement modules ==<br />
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.<br />
<br />
== Limitations ==<br />
Some technical limitations apply:<br />
<br />
* 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.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Incidents&diff=4369Incidents2023-08-04T13:44:12Z<p>Ralf: /* Interface burst incident */</p>
<hr />
<div><br />
[[File:Incidents_list.png|alt=|none|thumb|800x800px|Incident page]]<br />
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. <br />
<br />
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.<br />
<br />
Occurred incidents can be seen in the web interface, additionally reporting via the following notification channels is possible:<br />
* email<br />
* Apache Kafka<br />
* SNMP trap<br />
* syslog<br />
<br />
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.<br />
<br />
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].<br />
<br />
== Configuration of incident rules ==<br />
[[File:Incidents rules.png|thumb|600x600px|Rule configuration]]<br />
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.<br />
<br />
The page shows a table containing the existing rules and their configuration.<br />
<br />
Each existing rule can be modified by clicking on the pencil symbol, or deleted by clicking on the "minus" symbol.<br />
<br />
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.<br />
<br />
=== Add/modify a rule ===<br />
[[File:Incidents add rule.png|thumb|600x600px|Add rule dialog]]<br />
A rule is defined by the following settings:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
* Attributes: Attributes are used to make actual comparison of expected values vs. actual values.<br />
** 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<br />
** Up to four attributes can be added by clicking on the "Add attribute" button.<br />
** Multiple attributes must all match at the same time to let the rule create an incident.<br />
** Each attribute can be compared to a specific value, so that the actual value is lower, equal, or greater than a defined value.<br />
** Some attributes have an additional parameter, like a time span which defines how the attribute value is calculated.<br />
* 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.<br />
* IP filter: Depending on the selected trigger, the rule can be limited to a specific IP address. In firmware version >= 4.0, the IP filter can also be an IP subnet in the format IP/mask-length (Example: 10.0.0.0/8)<br />
* IP group: Depending on the selected trigger, the rule can be applied to an IP group instead of an individual IP address.<br />
* Virtual link group, IP and IP filter can also be used inversely by using the != comparator<br />
* 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.<br />
* 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.<br />
* Time Profiles: With version 4.0 the new setting time profiles was introduced. You are able to set a profile which defines the active time of an incident rule.<br />
* Traffic capturing [since version >= 4.0]: If supported by the trigger, the rule can be configured to capture the network traffic triggering the rule, including some extra time before and after the incident.<br />
** Possible options:<br />
*** Disabled: capturing is disabled for this rule<br />
*** Live traffic: capturing happens only for live network traffic<br />
*** Replay traffic: capturing happens only for replayed network traffic (from PCAP files)<br />
*** Always: capturing happens in all traffic processing types.<br />
** Extra capture time: configure the number of seconds before the start of the incident and after the end of the incident.<br />
*** If a time span parameter is used for attributes, the capture time includes this time duration as well.<br />
** 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.<br />
<br />
=== Available triggers ===<br />
{| class="wikitable"<br />
|+<br />
!Trigger name<br />
!Description<br />
!Attributes<br />
!Attribute usage<br />
|-<br />
|ARP: MAC change for an IP<br><br />
(arp_ip_mac_changed)<br />
|This trigger is checked on an ARP response and MAC address changed for a requested IP.<br />
|time_since_last_mac<br />
|optional<br />
|-<br />
|DNS: Server is not responding<br><br />
(dns_server_not_responding)<br />
|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.<br />
|time_since_first_unanswered_request<br />
|optional<br />
|-<br />
|DNS: Server response error<br><br />
(dns_server_response_error)<br />
|This trigger is checked when a DNS server responds a configured error of type format error, server failure or non-existing domain<br />
|error_type<br />
|mandatory<br />
|-<br />
|Global: Connection start<br><br />
(global_new_connection)<br />
|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.<br />
|l4_protocol, port_range, since_start_time<br />
|mandatory<br />
|-<br />
|Global: GPS synchronization status change<br><br />
(global_gps_sync_status_change)<br />
|This trigger is checked when the GPS clock synchronization status changes.<br />
|gps_sync_status<br />
|optional<br />
|-<br />
|Global: Number of connections<br><br />
(global_connections)<br />
|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.<br />
|new_connections<br />
|mandatory<br />
|-<br />
|Global: Regular expressions<br><br />
(global_regex_match)<br />
|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.<br />
|<br />
|no attributes are available for this trigger<br />
|-<br />
|Global: Ring buffer<br><br />
(global_ring_buffer)<br />
|This trigger is checked continuously to report changes in the ring buffer.<br />
|used_size, bytes_captured, bytes_dropped<br />
|mandatory<br />
|-<br />
|Global: Speed change of an interface<br><br />
(global_interface_speed_change)<br />
|This trigger is checked when the speed of an interfaces changes.<br />
|interface_speed<br />
|optional<br />
|-<br />
|Global: Speed mismatch for an interface pair<br><br />
(global_interface_speed_mismatch)<br />
|This trigger is checked when the status or speed of an interfaces changes and mismatches the speed of corresponding interface of a link.<br />
|link_speed_difference<br />
|optional<br />
|-<br />
|Global: Status change of an interface<br><br />
(global_interface_status_change)<br />
|This trigger is checked when the status of an interfaces changes.<br />
|interface_status<br />
|optional<br />
|-<br />
|Global: Traffic<br><br />
(global_traffic)<br />
|This trigger is checked continuously for the total traffic of the device. The update interval is defined by the timespan parameter of the attributes.<br />
|throughput, throughput_increase, packet_rate, packet_rate_increase<br />
|mandatory<br />
|-<br />
|IEC104: Response times<br><br />
(iec104_response_times)<br />
|This trigger is checked whenever an IEC104 ACTCON reply for an ACT has been seen.<br />
|response_time<br />
|mandatory<br />
|-<br />
|IEC104: Traffic<br><br />
(iec104_traffic)<br />
|This trigger is checked continuously for each IEC104 connection. The update interval is defined by the timespan parameter of the attributes.<br />
|percent_loss, absolute_loss, not_in_order<br />
|mandatory<br />
|-<br />
|IP: Connection end<br><br />
(ip_flow_end)<br />
|This trigger checks the attributes whenever an IP flow ended.<br />
|total_packets, total_bytes, tcp_handshake_time, percent_retransmissions, zero_window_packets, duration<br />
|mandatory<br />
|-<br />
|IP: Connection start<br><br />
(ip_flow_start)<br />
|This trigger checks the attributes whenever an IP flow starts.<br />
|new_connections, geolocation<br />
|mandatory<br />
|-<br />
|IP: Local IP with multiple MAC addresses<br><br />
(ip_local_ip_multiple_macs)<br />
|This trigger is checked on each new flow of a local IP address and more than one MAC address uses this IP.<br />
|mac_count<br />
|optional<br />
|-<br />
|IP: New local IP address<br><br />
(ip_new_local_ip)<br />
|This trigger is checked once for each new IP belonging to a private network address range.<br />
|since_start_time<br />
|optional<br />
|-<br />
|IP: New local L7 protocol<br><br />
(ip_new_local_l7_protocol)<br />
|This trigger is checked once for each new l7 protocol used by a local IP.<br />
|since_start_time<br />
|optional<br />
|-<br />
|IP: TCP handshake<br><br />
(ip_tcp_handshake)<br />
|This trigger is checked after successful TCP handshake.<br />
|handshake_time, server_handshake_time, client_handshake_time<br />
|mandatory<br />
|-<br />
|IP: Traffic on IP addresses<br><br />
(ip_traffic)<br />
|This trigger is checked continuously for each active IP or IP group. The update interval is defined by the timespan parameter of the attributes.<br />
|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<br />
|mandatory<br />
|-<br />
|LACP: Status change of a channel<br><br />
(lacp_channel_status_change)<br />
|This trigger is checked when the status of a LACP port channel changes.<br />
|channel_status<br />
|optional<br />
|-<br />
|MAC: New L7 protocol<br><br />
(mac_new_l7_protocol)<br />
|This trigger is checked when a unicast MAC address uses a l7 protocol for the first time.<br />
|since_start_time<br />
|optional<br />
|-<br />
|MAC: New MAC address<br><br />
(mac_new_address)<br />
|This trigger is checked once when a new unicast MAC address appears for the first time.<br />
|since_start_time<br />
|optional<br />
|-<br />
|MAC: Traffic on MAC addresses<br><br />
(mac_traffic)<br />
|This trigger is checked continuously for each active MAC address. The update interval is defined by the timespan parameter of the attributes.<br />
|broadcast_packet_rate<br />
|mandatory<br />
|-<br />
|PPPoE: PPPoE Discovery traffic<br><br />
(pppoe_discovery_traffic)<br />
|This trigger is checked continuously for PPPoE discovery traffic. The update interval is defined by the timespan parameter of the attributes.<br />
|pppoe_discovery_packets<br />
|mandatory<br />
|-<br />
|Profinet: Traffic of Profinet devices<br><br />
(profinet_traffic)<br />
|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.<br />
|alarms_low, alarms_high, errors, frames_lost, frames_repeated, frames_wrong_sequence, max_jitter<br />
|mandatory<br />
|-<br />
|PTP: Timestamp packet<br><br />
(ptp_timestamp_packet)<br />
|This trigger is checked when a PTP packet containing a valid timestamp is seen.<br />
|time_offset<br />
|mandatory<br />
|-<br />
|QOS: Traffic on QoS classes<br><br />
(qos_traffic)<br />
|This trigger is checked continuously for each active QoS class. The update interval is defined by the timespan parameter of the attributes.<br />
|throughput<br />
|mandatory<br />
|-<br />
|RTP: Traffic for RTP connections<br><br />
(rtp_traffic)<br />
|This trigger is checked continuously for traffic of each RTP connection. The update interval is defined by the timespan parameter of the attributes.<br />
|jitter, percent_loss<br />
|mandatory<br />
|-<br />
|SIP: Call end<br><br />
(sip_call_end)<br />
|This trigger is checked when a SIP call ended.<br />
|duration, status, mos, percent_loss, jitter, total_packets, total_bytes, total_caller_packets, total_callee_packets, total_caller_bytes, total_callee_bytes<br />
|mandatory<br />
|-<br />
|SMB: SMB1 negotiation<br><br />
(smb_v1_negotiation)<br />
|This trigger is executed at the beginning of each SMB connection and checks whether insecure SMB1 has been negotiated.<br />
|<br />
|none<br />
|-<br />
|SSL: Handshake<br><br />
(ssl_handshake)<br />
|This trigger is checked during handshake of each SSL connection.<br />
|certificate_expires<br />
|mandatory<br />
|-<br />
|SSL: SSL/TLS version negotiation<br><br />
(tls_version)<br />
|This trigger is checked during version negotiation at handshake of each SSL connection.<br />
|used_tls_version<br />
|mandatory<br />
|}<br />
<br />
==== Special trigger properties ====<br />
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.<br />
<br />
# Repeating incidents: The following triggers will be evaluated every configured time span and will be re-issued whenever the configured attributes match.<br />
## ip_traffic<br />
## mac_traffic<br />
## qos_traffic<br />
## rtp_traffic<br />
# Start/stop incidents: The following triggers are reported once the configured attributes match and for a second time when the attributes no longer match.<br />
## global_traffic<br />
<br />
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.<br />
<br />
For start/stop incidents, you will only see two rule hits and the incident description will state the start and stop time.<br />
<br />
=== Available attributes ===<br />
<br />
* '''absolute_loss''': Count of lost packets for IEC104 connection.<br />
* '''alarms_low''', '''alarms_high''': Whether an low/high alarm occurred for a Profinet device.<br />
* '''broadcast_packet_rate''': The attribute is the number of packets per second on average over the configured timespan for MAC broadcast packets.<br />
* '''bytes_captured''': The amount of bytes captured by a ring buffer in the given timespan.<br />
* '''bytes_dropped''': The amount of bytes dropped by a ring buffer in the given timespan.<br />
* '''certificate_expires''': This is the number of days until the certificate expires. If the certificate is already expired, the value is <= 0.<br />
* '''channel_status''': 0 means that the LACP port channel is not synchronized, 1 means that the LACP port channel is synchronized.<br />
* '''duration''':<br />
** ''IP: Connection end'': The time between first and last packet of the flow.<br />
** ''SIP: Call end'': The call duration.<br />
* '''errors''':<br />
** ''Profinet: Traffic of Profinet devices: Whether errors occured.<br />
* '''error_type''': equal or not equal to:<br />
** Format Error: DNS responds a format error.<br />
** Non-existent Domain: DNS could not find queried domain name.<br />
** Server Failure: DNS responds server failure.<br />
* '''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.<br />
* '''geolocation''': checks if a country is part of the connection<br />
** '''Direction''': The direction of traffic<br />
*** ''from'': Traffic is coming ''from the'' specified country<br />
*** ''to'': Traffic is going ''to'' the specified country<br />
*** ''any:'' The specified country is on either side of the connection, or on neither side if the inequality is selected.<br />
* '''gps_sync_status''': 0 means that the GPS clock in not synchronized, 1 means that the GPS clock is synchronized.<br />
* '''handshake_time''': The TCP handshake time between the first SYN packet and the ACK packet for the SYN/ACK packet of the server.<br />
** '''client_handshake_time''': The TCP handshake time between the SYN/ACK packet of the server and the ACK packet of the client.<br />
** '''server_handshake_time''': The TCP handshake time between the first SYN packet of the client and the SYN/ACK packet of the server.<br />
* '''interface_speed''': The current speed of the interface in Mbit/s.<br />
* '''interface_status''': 0 means interface is down, 1 means interface is up.<br />
* '''jitter''':<br />
** ''SIP: Call end'': The average jitter of the call, using the maximum value of both call sides.<br />
** ''RTP: Traffic for RTP connections'': The average jitter of the RTP connection for the given timespan, using the maximum value of both directions.<br />
* '''l4_protocol''': The layer 4 protocol. Can be TCP, UDP or other.<br />
* '''link_speed_difference''': This is the absolute difference between the speeds of both interface of a link in Mbit/s.<br />
* '''mac_count''': The number of different MAC addresses for the corresponding IP address.<br />
* '''max_jitter''': The max jitter value for a Profinet device in % in a given timespan.<br />
* '''mos''': The average MOS quality value of the call, using the minimum of both call sides.<br />
* '''new_connections''': The amount of newly created connections (TCP and UDP) for the given timespan.<br />
* '''not_in_order''': Count of not in order packets for IEC104 connection. The sequence number could be too high, too low or repeated.<br />
* '''packet_rate''': The packet rate in packets per second on average during the configured timespan.<br />
* '''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.<br />
* '''percent_loss''':<br />
** ''SIP: Call end'': The percentage of RTP packet loss for the call, accounting packets from both directions.<br />
** ''RTP: Traffic for RTP connections'': The percentage of RTP packet loss for the given timespan, accounting packets from both directions of the RTP connection.<br />
** ''IEC104: Traffic for IEC104 connections'': The percentage of IEC104 packet loss for the given timespan, accounting packets from both directions of the IEC104 connection.<br />
* '''percent_transmissions''': The amount of TCP retransmission as a percentage of the total bytes.<br />
* '''port_range''': The TCP or UDP port. Can be also a range, e.g. 80,443,8443-8445<br />
* '''pppoe_discovery_packets''': The number of PPPoE discovery packets seen during the configured timespan.<br />
* '''response_time''': The response time of IEC104 ACT requests and ACTCON replies.<br />
* '''retransmission_ratio''': The TCP retransmission ratio seen in the configured timespan.<br />
* '''since_start_time''':<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
* '''status''': The call status code (a three digit number, like 200 for Success)<br />
* '''tcp_handshake_time''': The TCP handshake time.<br />
* '''tcp_fin_packets''': The number of TCP FIN packets (RX + TX) seen in the configured timespan.<br />
* '''tcp_rst_packets''': The number of TCP RST packets (RX + TX) seen in the configured timespan.<br />
* '''tcp_syn_packets''': The number of TCP SYN packets (RX + TX) seen in the configured timespan.<br />
* '''throughput''': The throughput bandwidth in bit/s on average during the configured timespan.<br />
* '''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.<br />
* '''time_offset''': The time offset between the local time and the timestamp seen in the PTP packet.<br />
* '''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.<br />
* '''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.<br />
* '''total_bytes''':<br />
** ''IP: Connection end'': The total number of bytes seen for both directions of the flow.<br />
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of bytes seen in the configured timespan.<br />
** '''total_callee_bytes''': The number of bytes seen for the callee of the call.<br />
** '''total_caller_bytes''': The number of bytes seen for the caller of the call.<br />
* '''total_packets''':<br />
** ''IP: Connection end'': The total number of packets seen for both directions of the flow.<br />
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of packets seen in the configured timespan.<br />
** '''total_callee_packets''': The number of packets seen for the callee of the call.<br />
** '''total_caller_packets''': The number of packets seen for the caller of the call.<br />
* '''type''': The type of PPPoE discovery packet (PADI, PADO, PADR, PADS, PADT or any).<br />
* '''used_size''': The percentage of the ring buffer that needs to be filled.<br />
* '''used_tls_version''': The TLS version (SSl 3.0, TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3)<br />
* '''zero_window_packets''': The number of packets with a TCP window of 0 for both directions of the flow.<br />
* '''zero_window_packets''': The number of zero window packets seen in the configured timespan.<br />
<br />
=== Capture settings ===<br />
Since firmware version 4.0, it is possible to automatically capture traffic for occurred incidents. These global settings control where capture files are stored and the capturing itself can be enabled for each rule separately.<br />
<br />
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.<br />
<br />
Available settings:<br />
<br />
* 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.<br />
* Storage device: Select the storage device where the captures should be stored on.<br />
* Storage directory: Enter the directory where capture files should be stored or leave empty to use the top level directory.<br />
* 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.<br />
* 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).<br />
<br />
== Time Profiles ==<br />
Incident rules can be active configured to be active in configured time spans (time profiles).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Channel configuration ==<br />
[[File:Incidents channels.png|thumb|600x600px|Channel configuration]]<br />
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.<br />
<br />
Each channel can be of type:<br />
<br />
'''email''' Incidents will be sent to the email address configured in the [[Global settings]].<br />
<br />
'''kafka''' The incidents are sent to a topic on the configured Apache Kafka server. Firmware >= 4.0. The message is the same as for syslog.<br />
* Bootstrap Server: hostname/ip:port of a Kafka Broker or multiple Brokers separated by comma<br />
* Protocol: Plaintext (no authentication, no encryption), SASL Paintext (Plain authentication, no encryption), SASL SSL (Plain authentication, TLS/SSL encryption)<br />
* Ignore TLS Certificate: Ignore the TLS Certificate of the Brokers (only SASL SSL)<br />
* Username: Broker Login (only SASL)<br />
* Password: Broker Login (only SASL)<br />
* Topic: The name of the topic into which the Incidents are sent.<br />
<br />
'''snmp_trap''' Incidents will be sent to the configured SNMP trap receiver (firmware >= 4.0). A MIB file with the Allegro Network Multimeter SNMP trap definitions is available for download in the channel configuration dialog.<br />
* Version: Supported SNMP version of the trap receiver (SNMP v2c or SNMP v3)<br />
* Trap receiver (manager) hostname/IP: The trap receiver hostname or IP address<br />
<br />
''SNMP v2c'':<br />
* Community name: SNMP community name expected by the trap receiver<br />
<br />
''SNMP v3'':<br />
* Authentication protocol: Protocol for authenticated messages (MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512)<br />
* Authentication password: Pass phrase for authenticated messages<br />
* Privacy protocol: Protocol for message encryption (AES, DES)<br />
* Privacy password: Pass phrase for message encryption<br />
* Security name: Security name for authenticated SNMP messages<br />
* Security level: Security level for SNMP messages (noAuthNoPriv, authNoPriv, authPriv)<br />
* Engine ID: Authoritative (security) engineID (hexadecimal number)<br />
<br />
'''syslog''' Incidents will be sent to the configured syslog server via TCP on any TCP or UDP port.<br />
<br />
<br />
[[File:Incidents add channel.png|thumb|alt=|none|Adding a new channel]]<br />
Each channel also uses a minimum severity setting, so only incidents are reported which are of at least that severity.<br />
<br />
Each channel can be configured to only handle incidents from live traffic or from replayed traffic.<br />
<br />
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.<br />
<br />
== Other settings ==<br />
<br />
=== Interface burst incident ===<br />
[[File:Incidents others.png|thumb|600x600px|Other incidents]]<br />
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.<br />
<br />
The incident generation can be configured in the "Other settings" tab as follows:<br />
* '''Report "throughput threshold exceeded" with severity''': report an incident with the selected severity level if the throughput of any network interface exceeded.<br />
* '''Throughput threshold (Mbit/s)''': The threshold is configured in Mbit/s.<br />
* '''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.<br />
* '''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.<br />
<br />
=== Generic incident settings ===<br />
This section allows to modify generic settings regarding the incident feature:<br />
<br />
* '''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.<br />
<br />
== Occured incidents ==<br />
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.<br />
[[File:Incidents list filter.png|thumb|600x600px|Filter incidents by severity or trigger]]<br />
The list can also be filtered for the subject of the incident.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Statistics about incident rules ==<br />
[[File:Incidents stats.png|thumb|600x600px|Statistics about rules]]<br />
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.<br />
<br />
== Incident list per measurement modules ==<br />
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.<br />
<br />
== Limitations ==<br />
Some technical limitations apply:<br />
<br />
* 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.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Incidents&diff=4368Incidents2023-08-04T13:40:34Z<p>Ralf: /* Occured incidents */</p>
<hr />
<div><br />
[[File:Incidents_list.png|alt=|none|thumb|800x800px|Incident page]]<br />
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. <br />
<br />
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.<br />
<br />
Occurred incidents can be seen in the web interface, additionally reporting via the following notification channels is possible:<br />
* email<br />
* Apache Kafka<br />
* SNMP trap<br />
* syslog<br />
<br />
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.<br />
<br />
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].<br />
<br />
== Configuration of incident rules ==<br />
[[File:Incidents rules.png|thumb|600x600px|Rule configuration]]<br />
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.<br />
<br />
The page shows a table containing the existing rules and their configuration.<br />
<br />
Each existing rule can be modified by clicking on the pencil symbol, or deleted by clicking on the "minus" symbol.<br />
<br />
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.<br />
<br />
=== Add/modify a rule ===<br />
[[File:Incidents add rule.png|thumb|600x600px|Add rule dialog]]<br />
A rule is defined by the following settings:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
* Attributes: Attributes are used to make actual comparison of expected values vs. actual values.<br />
** 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<br />
** Up to four attributes can be added by clicking on the "Add attribute" button.<br />
** Multiple attributes must all match at the same time to let the rule create an incident.<br />
** Each attribute can be compared to a specific value, so that the actual value is lower, equal, or greater than a defined value.<br />
** Some attributes have an additional parameter, like a time span which defines how the attribute value is calculated.<br />
* 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.<br />
* IP filter: Depending on the selected trigger, the rule can be limited to a specific IP address. In firmware version >= 4.0, the IP filter can also be an IP subnet in the format IP/mask-length (Example: 10.0.0.0/8)<br />
* IP group: Depending on the selected trigger, the rule can be applied to an IP group instead of an individual IP address.<br />
* Virtual link group, IP and IP filter can also be used inversely by using the != comparator<br />
* 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.<br />
* 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.<br />
* Time Profiles: With version 4.0 the new setting time profiles was introduced. You are able to set a profile which defines the active time of an incident rule.<br />
* Traffic capturing [since version >= 4.0]: If supported by the trigger, the rule can be configured to capture the network traffic triggering the rule, including some extra time before and after the incident.<br />
** Possible options:<br />
*** Disabled: capturing is disabled for this rule<br />
*** Live traffic: capturing happens only for live network traffic<br />
*** Replay traffic: capturing happens only for replayed network traffic (from PCAP files)<br />
*** Always: capturing happens in all traffic processing types.<br />
** Extra capture time: configure the number of seconds before the start of the incident and after the end of the incident.<br />
*** If a time span parameter is used for attributes, the capture time includes this time duration as well.<br />
** 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.<br />
<br />
=== Available triggers ===<br />
{| class="wikitable"<br />
|+<br />
!Trigger name<br />
!Description<br />
!Attributes<br />
!Attribute usage<br />
|-<br />
|ARP: MAC change for an IP<br><br />
(arp_ip_mac_changed)<br />
|This trigger is checked on an ARP response and MAC address changed for a requested IP.<br />
|time_since_last_mac<br />
|optional<br />
|-<br />
|DNS: Server is not responding<br><br />
(dns_server_not_responding)<br />
|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.<br />
|time_since_first_unanswered_request<br />
|optional<br />
|-<br />
|DNS: Server response error<br><br />
(dns_server_response_error)<br />
|This trigger is checked when a DNS server responds a configured error of type format error, server failure or non-existing domain<br />
|error_type<br />
|mandatory<br />
|-<br />
|Global: Connection start<br><br />
(global_new_connection)<br />
|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.<br />
|l4_protocol, port_range, since_start_time<br />
|mandatory<br />
|-<br />
|Global: GPS synchronization status change<br><br />
(global_gps_sync_status_change)<br />
|This trigger is checked when the GPS clock synchronization status changes.<br />
|gps_sync_status<br />
|optional<br />
|-<br />
|Global: Number of connections<br><br />
(global_connections)<br />
|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.<br />
|new_connections<br />
|mandatory<br />
|-<br />
|Global: Regular expressions<br><br />
(global_regex_match)<br />
|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.<br />
|<br />
|no attributes are available for this trigger<br />
|-<br />
|Global: Ring buffer<br><br />
(global_ring_buffer)<br />
|This trigger is checked continuously to report changes in the ring buffer.<br />
|used_size, bytes_captured, bytes_dropped<br />
|mandatory<br />
|-<br />
|Global: Speed change of an interface<br><br />
(global_interface_speed_change)<br />
|This trigger is checked when the speed of an interfaces changes.<br />
|interface_speed<br />
|optional<br />
|-<br />
|Global: Speed mismatch for an interface pair<br><br />
(global_interface_speed_mismatch)<br />
|This trigger is checked when the status or speed of an interfaces changes and mismatches the speed of corresponding interface of a link.<br />
|link_speed_difference<br />
|optional<br />
|-<br />
|Global: Status change of an interface<br><br />
(global_interface_status_change)<br />
|This trigger is checked when the status of an interfaces changes.<br />
|interface_status<br />
|optional<br />
|-<br />
|Global: Traffic<br><br />
(global_traffic)<br />
|This trigger is checked continuously for the total traffic of the device. The update interval is defined by the timespan parameter of the attributes.<br />
|throughput, throughput_increase, packet_rate, packet_rate_increase<br />
|mandatory<br />
|-<br />
|IEC104: Response times<br><br />
(iec104_response_times)<br />
|This trigger is checked whenever an IEC104 ACTCON reply for an ACT has been seen.<br />
|response_time<br />
|mandatory<br />
|-<br />
|IEC104: Traffic<br><br />
(iec104_traffic)<br />
|This trigger is checked continuously for each IEC104 connection. The update interval is defined by the timespan parameter of the attributes.<br />
|percent_loss, absolute_loss, not_in_order<br />
|mandatory<br />
|-<br />
|IP: Connection end<br><br />
(ip_flow_end)<br />
|This trigger checks the attributes whenever an IP flow ended.<br />
|total_packets, total_bytes, tcp_handshake_time, percent_retransmissions, zero_window_packets, duration<br />
|mandatory<br />
|-<br />
|IP: Connection start<br><br />
(ip_flow_start)<br />
|This trigger checks the attributes whenever an IP flow starts.<br />
|new_connections, geolocation<br />
|mandatory<br />
|-<br />
|IP: Local IP with multiple MAC addresses<br><br />
(ip_local_ip_multiple_macs)<br />
|This trigger is checked on each new flow of a local IP address and more than one MAC address uses this IP.<br />
|mac_count<br />
|optional<br />
|-<br />
|IP: New local IP address<br><br />
(ip_new_local_ip)<br />
|This trigger is checked once for each new IP belonging to a private network address range.<br />
|since_start_time<br />
|optional<br />
|-<br />
|IP: New local L7 protocol<br><br />
(ip_new_local_l7_protocol)<br />
|This trigger is checked once for each new l7 protocol used by a local IP.<br />
|since_start_time<br />
|optional<br />
|-<br />
|IP: TCP handshake<br><br />
(ip_tcp_handshake)<br />
|This trigger is checked after successful TCP handshake.<br />
|handshake_time, server_handshake_time, client_handshake_time<br />
|mandatory<br />
|-<br />
|IP: Traffic on IP addresses<br><br />
(ip_traffic)<br />
|This trigger is checked continuously for each active IP or IP group. The update interval is defined by the timespan parameter of the attributes.<br />
|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<br />
|mandatory<br />
|-<br />
|LACP: Status change of a channel<br><br />
(lacp_channel_status_change)<br />
|This trigger is checked when the status of a LACP port channel changes.<br />
|channel_status<br />
|optional<br />
|-<br />
|MAC: New L7 protocol<br><br />
(mac_new_l7_protocol)<br />
|This trigger is checked when a unicast MAC address uses a l7 protocol for the first time.<br />
|since_start_time<br />
|optional<br />
|-<br />
|MAC: New MAC address<br><br />
(mac_new_address)<br />
|This trigger is checked once when a new unicast MAC address appears for the first time.<br />
|since_start_time<br />
|optional<br />
|-<br />
|MAC: Traffic on MAC addresses<br><br />
(mac_traffic)<br />
|This trigger is checked continuously for each active MAC address. The update interval is defined by the timespan parameter of the attributes.<br />
|broadcast_packet_rate<br />
|mandatory<br />
|-<br />
|PPPoE: PPPoE Discovery traffic<br><br />
(pppoe_discovery_traffic)<br />
|This trigger is checked continuously for PPPoE discovery traffic. The update interval is defined by the timespan parameter of the attributes.<br />
|pppoe_discovery_packets<br />
|mandatory<br />
|-<br />
|Profinet: Traffic of Profinet devices<br><br />
(profinet_traffic)<br />
|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.<br />
|alarms_low, alarms_high, errors, frames_lost, frames_repeated, frames_wrong_sequence, max_jitter<br />
|mandatory<br />
|-<br />
|PTP: Timestamp packet<br><br />
(ptp_timestamp_packet)<br />
|This trigger is checked when a PTP packet containing a valid timestamp is seen.<br />
|time_offset<br />
|mandatory<br />
|-<br />
|QOS: Traffic on QoS classes<br><br />
(qos_traffic)<br />
|This trigger is checked continuously for each active QoS class. The update interval is defined by the timespan parameter of the attributes.<br />
|throughput<br />
|mandatory<br />
|-<br />
|RTP: Traffic for RTP connections<br><br />
(rtp_traffic)<br />
|This trigger is checked continuously for traffic of each RTP connection. The update interval is defined by the timespan parameter of the attributes.<br />
|jitter, percent_loss<br />
|mandatory<br />
|-<br />
|SIP: Call end<br><br />
(sip_call_end)<br />
|This trigger is checked when a SIP call ended.<br />
|duration, status, mos, percent_loss, jitter, total_packets, total_bytes, total_caller_packets, total_callee_packets, total_caller_bytes, total_callee_bytes<br />
|mandatory<br />
|-<br />
|SMB: SMB1 negotiation<br><br />
(smb_v1_negotiation)<br />
|This trigger is executed at the beginning of each SMB connection and checks whether insecure SMB1 has been negotiated.<br />
|<br />
|none<br />
|-<br />
|SSL: Handshake<br><br />
(ssl_handshake)<br />
|This trigger is checked during handshake of each SSL connection.<br />
|certificate_expires<br />
|mandatory<br />
|-<br />
|SSL: SSL/TLS version negotiation<br><br />
(tls_version)<br />
|This trigger is checked during version negotiation at handshake of each SSL connection.<br />
|used_tls_version<br />
|mandatory<br />
|}<br />
<br />
==== Special trigger properties ====<br />
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.<br />
<br />
# Repeating incidents: The following triggers will be evaluated every configured time span and will be re-issued whenever the configured attributes match.<br />
## ip_traffic<br />
## mac_traffic<br />
## qos_traffic<br />
## rtp_traffic<br />
# Start/stop incidents: The following triggers are reported once the configured attributes match and for a second time when the attributes no longer match.<br />
## global_traffic<br />
<br />
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.<br />
<br />
For start/stop incidents, you will only see two rule hits and the incident description will state the start and stop time.<br />
<br />
=== Available attributes ===<br />
<br />
* '''absolute_loss''': Count of lost packets for IEC104 connection.<br />
* '''alarms_low''', '''alarms_high''': Whether an low/high alarm occurred for a Profinet device.<br />
* '''broadcast_packet_rate''': The attribute is the number of packets per second on average over the configured timespan for MAC broadcast packets.<br />
* '''bytes_captured''': The amount of bytes captured by a ring buffer in the given timespan.<br />
* '''bytes_dropped''': The amount of bytes dropped by a ring buffer in the given timespan.<br />
* '''certificate_expires''': This is the number of days until the certificate expires. If the certificate is already expired, the value is <= 0.<br />
* '''channel_status''': 0 means that the LACP port channel is not synchronized, 1 means that the LACP port channel is synchronized.<br />
* '''duration''':<br />
** ''IP: Connection end'': The time between first and last packet of the flow.<br />
** ''SIP: Call end'': The call duration.<br />
* '''errors''':<br />
** ''Profinet: Traffic of Profinet devices: Whether errors occured.<br />
* '''error_type''': equal or not equal to:<br />
** Format Error: DNS responds a format error.<br />
** Non-existent Domain: DNS could not find queried domain name.<br />
** Server Failure: DNS responds server failure.<br />
* '''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.<br />
* '''geolocation''': checks if a country is part of the connection<br />
** '''Direction''': The direction of traffic<br />
*** ''from'': Traffic is coming ''from the'' specified country<br />
*** ''to'': Traffic is going ''to'' the specified country<br />
*** ''any:'' The specified country is on either side of the connection, or on neither side if the inequality is selected.<br />
* '''gps_sync_status''': 0 means that the GPS clock in not synchronized, 1 means that the GPS clock is synchronized.<br />
* '''handshake_time''': The TCP handshake time between the first SYN packet and the ACK packet for the SYN/ACK packet of the server.<br />
** '''client_handshake_time''': The TCP handshake time between the SYN/ACK packet of the server and the ACK packet of the client.<br />
** '''server_handshake_time''': The TCP handshake time between the first SYN packet of the client and the SYN/ACK packet of the server.<br />
* '''interface_speed''': The current speed of the interface in Mbit/s.<br />
* '''interface_status''': 0 means interface is down, 1 means interface is up.<br />
* '''jitter''':<br />
** ''SIP: Call end'': The average jitter of the call, using the maximum value of both call sides.<br />
** ''RTP: Traffic for RTP connections'': The average jitter of the RTP connection for the given timespan, using the maximum value of both directions.<br />
* '''l4_protocol''': The layer 4 protocol. Can be TCP, UDP or other.<br />
* '''link_speed_difference''': This is the absolute difference between the speeds of both interface of a link in Mbit/s.<br />
* '''mac_count''': The number of different MAC addresses for the corresponding IP address.<br />
* '''max_jitter''': The max jitter value for a Profinet device in % in a given timespan.<br />
* '''mos''': The average MOS quality value of the call, using the minimum of both call sides.<br />
* '''new_connections''': The amount of newly created connections (TCP and UDP) for the given timespan.<br />
* '''not_in_order''': Count of not in order packets for IEC104 connection. The sequence number could be too high, too low or repeated.<br />
* '''packet_rate''': The packet rate in packets per second on average during the configured timespan.<br />
* '''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.<br />
* '''percent_loss''':<br />
** ''SIP: Call end'': The percentage of RTP packet loss for the call, accounting packets from both directions.<br />
** ''RTP: Traffic for RTP connections'': The percentage of RTP packet loss for the given timespan, accounting packets from both directions of the RTP connection.<br />
** ''IEC104: Traffic for IEC104 connections'': The percentage of IEC104 packet loss for the given timespan, accounting packets from both directions of the IEC104 connection.<br />
* '''percent_transmissions''': The amount of TCP retransmission as a percentage of the total bytes.<br />
* '''port_range''': The TCP or UDP port. Can be also a range, e.g. 80,443,8443-8445<br />
* '''pppoe_discovery_packets''': The number of PPPoE discovery packets seen during the configured timespan.<br />
* '''response_time''': The response time of IEC104 ACT requests and ACTCON replies.<br />
* '''retransmission_ratio''': The TCP retransmission ratio seen in the configured timespan.<br />
* '''since_start_time''':<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
* '''status''': The call status code (a three digit number, like 200 for Success)<br />
* '''tcp_handshake_time''': The TCP handshake time.<br />
* '''tcp_fin_packets''': The number of TCP FIN packets (RX + TX) seen in the configured timespan.<br />
* '''tcp_rst_packets''': The number of TCP RST packets (RX + TX) seen in the configured timespan.<br />
* '''tcp_syn_packets''': The number of TCP SYN packets (RX + TX) seen in the configured timespan.<br />
* '''throughput''': The throughput bandwidth in bit/s on average during the configured timespan.<br />
* '''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.<br />
* '''time_offset''': The time offset between the local time and the timestamp seen in the PTP packet.<br />
* '''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.<br />
* '''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.<br />
* '''total_bytes''':<br />
** ''IP: Connection end'': The total number of bytes seen for both directions of the flow.<br />
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of bytes seen in the configured timespan.<br />
** '''total_callee_bytes''': The number of bytes seen for the callee of the call.<br />
** '''total_caller_bytes''': The number of bytes seen for the caller of the call.<br />
* '''total_packets''':<br />
** ''IP: Connection end'': The total number of packets seen for both directions of the flow.<br />
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of packets seen in the configured timespan.<br />
** '''total_callee_packets''': The number of packets seen for the callee of the call.<br />
** '''total_caller_packets''': The number of packets seen for the caller of the call.<br />
* '''type''': The type of PPPoE discovery packet (PADI, PADO, PADR, PADS, PADT or any).<br />
* '''used_size''': The percentage of the ring buffer that needs to be filled.<br />
* '''used_tls_version''': The TLS version (SSl 3.0, TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3)<br />
* '''zero_window_packets''': The number of packets with a TCP window of 0 for both directions of the flow.<br />
* '''zero_window_packets''': The number of zero window packets seen in the configured timespan.<br />
<br />
=== Capture settings ===<br />
Since firmware version 4.0, it is possible to automatically capture traffic for occurred incidents. These global settings control where capture files are stored and the capturing itself can be enabled for each rule separately.<br />
<br />
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.<br />
<br />
Available settings:<br />
<br />
* 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.<br />
* Storage device: Select the storage device where the captures should be stored on.<br />
* Storage directory: Enter the directory where capture files should be stored or leave empty to use the top level directory.<br />
* 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.<br />
* 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).<br />
<br />
== Time Profiles ==<br />
Incident rules can be active configured to be active in configured time spans (time profiles).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Channel configuration ==<br />
[[File:Incidents channels.png|thumb|600x600px|Channel configuration]]<br />
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.<br />
<br />
Each channel can be of type:<br />
<br />
'''email''' Incidents will be sent to the email address configured in the [[Global settings]].<br />
<br />
'''kafka''' The incidents are sent to a topic on the configured Apache Kafka server. Firmware >= 4.0. The message is the same as for syslog.<br />
* Bootstrap Server: hostname/ip:port of a Kafka Broker or multiple Brokers separated by comma<br />
* Protocol: Plaintext (no authentication, no encryption), SASL Paintext (Plain authentication, no encryption), SASL SSL (Plain authentication, TLS/SSL encryption)<br />
* Ignore TLS Certificate: Ignore the TLS Certificate of the Brokers (only SASL SSL)<br />
* Username: Broker Login (only SASL)<br />
* Password: Broker Login (only SASL)<br />
* Topic: The name of the topic into which the Incidents are sent.<br />
<br />
'''snmp_trap''' Incidents will be sent to the configured SNMP trap receiver (firmware >= 4.0). A MIB file with the Allegro Network Multimeter SNMP trap definitions is available for download in the channel configuration dialog.<br />
* Version: Supported SNMP version of the trap receiver (SNMP v2c or SNMP v3)<br />
* Trap receiver (manager) hostname/IP: The trap receiver hostname or IP address<br />
<br />
''SNMP v2c'':<br />
* Community name: SNMP community name expected by the trap receiver<br />
<br />
''SNMP v3'':<br />
* Authentication protocol: Protocol for authenticated messages (MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512)<br />
* Authentication password: Pass phrase for authenticated messages<br />
* Privacy protocol: Protocol for message encryption (AES, DES)<br />
* Privacy password: Pass phrase for message encryption<br />
* Security name: Security name for authenticated SNMP messages<br />
* Security level: Security level for SNMP messages (noAuthNoPriv, authNoPriv, authPriv)<br />
* Engine ID: Authoritative (security) engineID (hexadecimal number)<br />
<br />
'''syslog''' Incidents will be sent to the configured syslog server via TCP on any TCP or UDP port.<br />
<br />
<br />
[[File:Incidents add channel.png|thumb|alt=|none|Adding a new channel]]<br />
Each channel also uses a minimum severity setting, so only incidents are reported which are of at least that severity.<br />
<br />
Each channel can be configured to only handle incidents from live traffic or from replayed traffic.<br />
<br />
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.<br />
<br />
== Interface burst incident ==<br />
[[File:Incidents others.png|thumb|600x600px|Other incidents]]<br />
Burst incidents with milli-second resolution can be generated when the interface throughput exceeds a configurable threshold. The incident contains a graph of traffic for that interface with some data points before and after the threshold has been exceeded depending on the measurement interval. A PCAP link for capturing from the packet ring buffer is shown. For further investigation of that incident, the button "Use as global time range" can be used to set the global range to the start and end of the incident graph (at least 5 seconds) so that all modules of the Allegro Network Multimeter show that time span. The incident generation can be configured as follows:<br />
* '''Report "throughput threshold exceeded" with severity''': report an incident with the selected severity level if the throughput of any network interface exceeded.<br />
* '''Throughput threshold (Mbit/s)''': The threshold is configured in Mbit/s.<br />
* '''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.<br />
* '''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.<br />
<br />
== Occured incidents ==<br />
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.<br />
[[File:Incidents list filter.png|thumb|600x600px|Filter incidents by severity or trigger]]<br />
The list can also be filtered for the subject of the incident.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Statistics about incident rules ==<br />
[[File:Incidents stats.png|thumb|600x600px|Statistics about rules]]<br />
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.<br />
<br />
== Incident list per measurement modules ==<br />
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.<br />
<br />
== Limitations ==<br />
Some technical limitations apply:<br />
<br />
* 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.</div>Ralfhttps://allegro-packets.com/wiki/index.php?title=Incidents&diff=4360Incidents2023-08-04T11:50:45Z<p>Ralf: </p>
<hr />
<div><br />
[[File:Incidents_list.png|alt=|none|thumb|800x800px|Incident page]]<br />
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. <br />
<br />
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.<br />
<br />
Occurred incidents can be seen in the web interface, additionally reporting via the following notification channels is possible:<br />
* email<br />
* Apache Kafka<br />
* SNMP trap<br />
* syslog<br />
<br />
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.<br />
<br />
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].<br />
<br />
== Configuration of incident rules ==<br />
[[File:Incidents rules.png|thumb|600x600px|Rule configuration]]<br />
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.<br />
<br />
The page shows a table containing the existing rules and their configuration.<br />
<br />
Each existing rule can be modified by clicking on the pencil symbol, or deleted by clicking on the "minus" symbol.<br />
<br />
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.<br />
<br />
=== Add/modify a rule ===<br />
[[File:Incidents add rule.png|thumb|600x600px|Add rule dialog]]<br />
A rule is defined by the following settings:<br />
<br />
* 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.<br />
* 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.<br />
* 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.<br />
* Attributes: Attributes are used to make actual comparison of expected values vs. actual values.<br />
** 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<br />
** Up to four attributes can be added by clicking on the "Add attribute" button.<br />
** Multiple attributes must all match at the same time to let the rule create an incident.<br />
** Each attribute can be compared to a specific value, so that the actual value is lower, equal, or greater than a defined value.<br />
** Some attributes have an additional parameter, like a time span which defines how the attribute value is calculated.<br />
* 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.<br />
* IP filter: Depending on the selected trigger, the rule can be limited to a specific IP address. In firmware version >= 4.0, the IP filter can also be an IP subnet in the format IP/mask-length (Example: 10.0.0.0/8)<br />
* IP group: Depending on the selected trigger, the rule can be applied to an IP group instead of an individual IP address.<br />
* Virtual link group, IP and IP filter can also be used inversely by using the != comparator<br />
* 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.<br />
* 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.<br />
* Time Profiles: With version 4.0 the new setting time profiles was introduced. You are able to set a profile which defines the active time of an incident rule.<br />
* Traffic capturing [since version >= 4.0]: If supported by the trigger, the rule can be configured to capture the network traffic triggering the rule, including some extra time before and after the incident.<br />
** Possible options:<br />
*** Disabled: capturing is disabled for this rule<br />
*** Live traffic: capturing happens only for live network traffic<br />
*** Replay traffic: capturing happens only for replayed network traffic (from PCAP files)<br />
*** Always: capturing happens in all traffic processing types.<br />
** Extra capture time: configure the number of seconds before the start of the incident and after the end of the incident.<br />
*** If a time span parameter is used for attributes, the capture time includes this time duration as well.<br />
** 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.<br />
<br />
=== Available triggers ===<br />
{| class="wikitable"<br />
|+<br />
!Trigger name<br />
!Description<br />
!Attributes<br />
!Attribute usage<br />
|-<br />
|ARP: MAC change for an IP<br><br />
(arp_ip_mac_changed)<br />
|This trigger is checked on an ARP response and MAC address changed for a requested IP.<br />
|time_since_last_mac<br />
|optional<br />
|-<br />
|DNS: Server is not responding<br><br />
(dns_server_not_responding)<br />
|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.<br />
|time_since_first_unanswered_request<br />
|optional<br />
|-<br />
|DNS: Server response error<br><br />
(dns_server_response_error)<br />
|This trigger is checked when a DNS server responds a configured error of type format error, server failure or non-existing domain<br />
|error_type<br />
|mandatory<br />
|-<br />
|Global: Connection start<br><br />
(global_new_connection)<br />
|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.<br />
|l4_protocol, port_range, since_start_time<br />
|mandatory<br />
|-<br />
|Global: GPS synchronization status change<br><br />
(global_gps_sync_status_change)<br />
|This trigger is checked when the GPS clock synchronization status changes.<br />
|gps_sync_status<br />
|optional<br />
|-<br />
|Global: Number of connections<br><br />
(global_connections)<br />
|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.<br />
|new_connections<br />
|mandatory<br />
|-<br />
|Global: Regular expressions<br><br />
(global_regex_match)<br />
|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.<br />
|<br />
|no attributes are available for this trigger<br />
|-<br />
|Global: Ring buffer<br><br />
(global_ring_buffer)<br />
|This trigger is checked continuously to report changes in the ring buffer.<br />
|used_size, bytes_captured, bytes_dropped<br />
|mandatory<br />
|-<br />
|Global: Speed change of an interface<br><br />
(global_interface_speed_change)<br />
|This trigger is checked when the speed of an interfaces changes.<br />
|interface_speed<br />
|optional<br />
|-<br />
|Global: Speed mismatch for an interface pair<br><br />
(global_interface_speed_mismatch)<br />
|This trigger is checked when the status or speed of an interfaces changes and mismatches the speed of corresponding interface of a link.<br />
|link_speed_difference<br />
|optional<br />
|-<br />
|Global: Status change of an interface<br><br />
(global_interface_status_change)<br />
|This trigger is checked when the status of an interfaces changes.<br />
|interface_status<br />
|optional<br />
|-<br />
|Global: Traffic<br><br />
(global_traffic)<br />
|This trigger is checked continuously for the total traffic of the device. The update interval is defined by the timespan parameter of the attributes.<br />
|throughput, throughput_increase, packet_rate, packet_rate_increase<br />
|mandatory<br />
|-<br />
|IEC104: Response times<br><br />
(iec104_response_times)<br />
|This trigger is checked whenever an IEC104 ACTCON reply for an ACT has been seen.<br />
|response_time<br />
|mandatory<br />
|-<br />
|IEC104: Traffic<br><br />
(iec104_traffic)<br />
|This trigger is checked continuously for each IEC104 connection. The update interval is defined by the timespan parameter of the attributes.<br />
|percent_loss, absolute_loss, not_in_order<br />
|mandatory<br />
|-<br />
|IP: Connection end<br><br />
(ip_flow_end)<br />
|This trigger checks the attributes whenever an IP flow ended.<br />
|total_packets, total_bytes, tcp_handshake_time, percent_retransmissions, zero_window_packets, duration<br />
|mandatory<br />
|-<br />
|IP: Connection start<br><br />
(ip_flow_start)<br />
|This trigger checks the attributes whenever an IP flow starts.<br />
|new_connections, geolocation<br />
|mandatory<br />
|-<br />
|IP: Local IP with multiple MAC addresses<br><br />
(ip_local_ip_multiple_macs)<br />
|This trigger is checked on each new flow of a local IP address and more than one MAC address uses this IP.<br />
|mac_count<br />
|optional<br />
|-<br />
|IP: New local IP address<br><br />
(ip_new_local_ip)<br />
|This trigger is checked once for each new IP belonging to a private network address range.<br />
|since_start_time<br />
|optional<br />
|-<br />
|IP: New local L7 protocol<br><br />
(ip_new_local_l7_protocol)<br />
|This trigger is checked once for each new l7 protocol used by a local IP.<br />
|since_start_time<br />
|optional<br />
|-<br />
|IP: TCP handshake<br><br />
(ip_tcp_handshake)<br />
|This trigger is checked after successful TCP handshake.<br />
|handshake_time, server_handshake_time, client_handshake_time<br />
|mandatory<br />
|-<br />
|IP: Traffic on IP addresses<br><br />
(ip_traffic)<br />
|This trigger is checked continuously for each active IP or IP group. The update interval is defined by the timespan parameter of the attributes.<br />
|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<br />
|mandatory<br />
|-<br />
|LACP: Status change of a channel<br><br />
(lacp_channel_status_change)<br />
|This trigger is checked when the status of a LACP port channel changes.<br />
|channel_status<br />
|optional<br />
|-<br />
|MAC: New L7 protocol<br><br />
(mac_new_l7_protocol)<br />
|This trigger is checked when a unicast MAC address uses a l7 protocol for the first time.<br />
|since_start_time<br />
|optional<br />
|-<br />
|MAC: New MAC address<br><br />
(mac_new_address)<br />
|This trigger is checked once when a new unicast MAC address appears for the first time.<br />
|since_start_time<br />
|optional<br />
|-<br />
|MAC: Traffic on MAC addresses<br><br />
(mac_traffic)<br />
|This trigger is checked continuously for each active MAC address. The update interval is defined by the timespan parameter of the attributes.<br />
|broadcast_packet_rate<br />
|mandatory<br />
|-<br />
|PPPoE: PPPoE Discovery traffic<br><br />
(pppoe_discovery_traffic)<br />
|This trigger is checked continuously for PPPoE discovery traffic. The update interval is defined by the timespan parameter of the attributes.<br />
|pppoe_discovery_packets<br />
|mandatory<br />
|-<br />
|Profinet: Traffic of Profinet devices<br><br />
(profinet_traffic)<br />
|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.<br />
|alarms_low, alarms_high, errors, frames_lost, frames_repeated, frames_wrong_sequence, max_jitter<br />
|mandatory<br />
|-<br />
|PTP: Timestamp packet<br><br />
(ptp_timestamp_packet)<br />
|This trigger is checked when a PTP packet containing a valid timestamp is seen.<br />
|time_offset<br />
|mandatory<br />
|-<br />
|QOS: Traffic on QoS classes<br><br />
(qos_traffic)<br />
|This trigger is checked continuously for each active QoS class. The update interval is defined by the timespan parameter of the attributes.<br />
|throughput<br />
|mandatory<br />
|-<br />
|RTP: Traffic for RTP connections<br><br />
(rtp_traffic)<br />
|This trigger is checked continuously for traffic of each RTP connection. The update interval is defined by the timespan parameter of the attributes.<br />
|jitter, percent_loss<br />
|mandatory<br />
|-<br />
|SIP: Call end<br><br />
(sip_call_end)<br />
|This trigger is checked when a SIP call ended.<br />
|duration, status, mos, percent_loss, jitter, total_packets, total_bytes, total_caller_packets, total_callee_packets, total_caller_bytes, total_callee_bytes<br />
|mandatory<br />
|-<br />
|SMB: SMB1 negotiation<br><br />
(smb_v1_negotiation)<br />
|This trigger is executed at the beginning of each SMB connection and checks whether insecure SMB1 has been negotiated.<br />
|<br />
|none<br />
|-<br />
|SSL: Handshake<br><br />
(ssl_handshake)<br />
|This trigger is checked during handshake of each SSL connection.<br />
|certificate_expires<br />
|mandatory<br />
|-<br />
|SSL: SSL/TLS version negotiation<br><br />
(tls_version)<br />
|This trigger is checked during version negotiation at handshake of each SSL connection.<br />
|used_tls_version<br />
|mandatory<br />
|}<br />
<br />
==== Special trigger properties ====<br />
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.<br />
<br />
# Repeating incidents: The following triggers will be evaluated every configured time span and will be re-issued whenever the configured attributes match.<br />
## ip_traffic<br />
## mac_traffic<br />
## qos_traffic<br />
## rtp_traffic<br />
# Start/stop incidents: The following triggers are reported once the configured attributes match and for a second time when the attributes no longer match.<br />
## global_traffic<br />
<br />
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.<br />
<br />
For start/stop incidents, you will only see two rule hits and the incident description will state the start and stop time.<br />
<br />
=== Available attributes ===<br />
<br />
* '''absolute_loss''': Count of lost packets for IEC104 connection.<br />
* '''alarms_low''', '''alarms_high''': Whether an low/high alarm occurred for a Profinet device.<br />
* '''broadcast_packet_rate''': The attribute is the number of packets per second on average over the configured timespan for MAC broadcast packets.<br />
* '''bytes_captured''': The amount of bytes captured by a ring buffer in the given timespan.<br />
* '''bytes_dropped''': The amount of bytes dropped by a ring buffer in the given timespan.<br />
* '''certificate_expires''': This is the number of days until the certificate expires. If the certificate is already expired, the value is <= 0.<br />
* '''channel_status''': 0 means that the LACP port channel is not synchronized, 1 means that the LACP port channel is synchronized.<br />
* '''duration''':<br />
** ''IP: Connection end'': The time between first and last packet of the flow.<br />
** ''SIP: Call end'': The call duration.<br />
* '''errors''':<br />
** ''Profinet: Traffic of Profinet devices: Whether errors occured.<br />
* '''error_type''': equal or not equal to:<br />
** Format Error: DNS responds a format error.<br />
** Non-existent Domain: DNS could not find queried domain name.<br />
** Server Failure: DNS responds server failure.<br />
* '''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.<br />
* '''geolocation''': checks if a country is part of the connection<br />
** '''Direction''': The direction of traffic<br />
*** ''from'': Traffic is coming ''from the'' specified country<br />
*** ''to'': Traffic is going ''to'' the specified country<br />
*** ''any:'' The specified country is on either side of the connection, or on neither side if the inequality is selected.<br />
* '''gps_sync_status''': 0 means that the GPS clock in not synchronized, 1 means that the GPS clock is synchronized.<br />
* '''handshake_time''': The TCP handshake time between the first SYN packet and the ACK packet for the SYN/ACK packet of the server.<br />
** '''client_handshake_time''': The TCP handshake time between the SYN/ACK packet of the server and the ACK packet of the client.<br />
** '''server_handshake_time''': The TCP handshake time between the first SYN packet of the client and the SYN/ACK packet of the server.<br />
* '''interface_speed''': The current speed of the interface in Mbit/s.<br />
* '''interface_status''': 0 means interface is down, 1 means interface is up.<br />
* '''jitter''':<br />
** ''SIP: Call end'': The average jitter of the call, using the maximum value of both call sides.<br />
** ''RTP: Traffic for RTP connections'': The average jitter of the RTP connection for the given timespan, using the maximum value of both directions.<br />
* '''l4_protocol''': The layer 4 protocol. Can be TCP, UDP or other.<br />
* '''link_speed_difference''': This is the absolute difference between the speeds of both interface of a link in Mbit/s.<br />
* '''mac_count''': The number of different MAC addresses for the corresponding IP address.<br />
* '''max_jitter''': The max jitter value for a Profinet device in % in a given timespan.<br />
* '''mos''': The average MOS quality value of the call, using the minimum of both call sides.<br />
* '''new_connections''': The amount of newly created connections (TCP and UDP) for the given timespan.<br />
* '''not_in_order''': Count of not in order packets for IEC104 connection. The sequence number could be too high, too low or repeated.<br />
* '''packet_rate''': The packet rate in packets per second on average during the configured timespan.<br />
* '''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.<br />
* '''percent_loss''':<br />
** ''SIP: Call end'': The percentage of RTP packet loss for the call, accounting packets from both directions.<br />
** ''RTP: Traffic for RTP connections'': The percentage of RTP packet loss for the given timespan, accounting packets from both directions of the RTP connection.<br />
** ''IEC104: Traffic for IEC104 connections'': The percentage of IEC104 packet loss for the given timespan, accounting packets from both directions of the IEC104 connection.<br />
* '''percent_transmissions''': The amount of TCP retransmission as a percentage of the total bytes.<br />
* '''port_range''': The TCP or UDP port. Can be also a range, e.g. 80,443,8443-8445<br />
* '''pppoe_discovery_packets''': The number of PPPoE discovery packets seen during the configured timespan.<br />
* '''response_time''': The response time of IEC104 ACT requests and ACTCON replies.<br />
* '''retransmission_ratio''': The TCP retransmission ratio seen in the configured timespan.<br />
* '''since_start_time''':<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
** ''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.<br />
* '''status''': The call status code (a three digit number, like 200 for Success)<br />
* '''tcp_handshake_time''': The TCP handshake time.<br />
* '''tcp_fin_packets''': The number of TCP FIN packets (RX + TX) seen in the configured timespan.<br />
* '''tcp_rst_packets''': The number of TCP RST packets (RX + TX) seen in the configured timespan.<br />
* '''tcp_syn_packets''': The number of TCP SYN packets (RX + TX) seen in the configured timespan.<br />
* '''throughput''': The throughput bandwidth in bit/s on average during the configured timespan.<br />
* '''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.<br />
* '''time_offset''': The time offset between the local time and the timestamp seen in the PTP packet.<br />
* '''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.<br />
* '''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.<br />
* '''total_bytes''':<br />
** ''IP: Connection end'': The total number of bytes seen for both directions of the flow.<br />
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of bytes seen in the configured timespan.<br />
** '''total_callee_bytes''': The number of bytes seen for the callee of the call.<br />
** '''total_caller_bytes''': The number of bytes seen for the caller of the call.<br />
* '''total_packets''':<br />
** ''IP: Connection end'': The total number of packets seen for both directions of the flow.<br />
** ''IP: Traffic on IP addresses'', ''QOS: Traffic on QoS classes'', ''SIP: Call end'': The number of packets seen in the configured timespan.<br />
** '''total_callee_packets''': The number of packets seen for the callee of the call.<br />
** '''total_caller_packets''': The number of packets seen for the caller of the call.<br />
* '''type''': The type of PPPoE discovery packet (PADI, PADO, PADR, PADS, PADT or any).<br />
* '''used_size''': The percentage of the ring buffer that needs to be filled.<br />
* '''used_tls_version''': The TLS version (SSl 3.0, TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3)<br />
* '''zero_window_packets''': The number of packets with a TCP window of 0 for both directions of the flow.<br />
* '''zero_window_packets''': The number of zero window packets seen in the configured timespan.<br />
<br />
=== Capture settings ===<br />
Since firmware version 4.0, it is possible to automatically capture traffic for occurred incidents. These global settings control where capture files are stored and the capturing itself can be enabled for each rule separately.<br />
<br />
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.<br />
<br />
Available settings:<br />
<br />
* 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.<br />
* Storage device: Select the storage device where the captures should be stored on.<br />
* Storage directory: Enter the directory where capture files should be stored or leave empty to use the top level directory.<br />
* 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.<br />
* 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).<br />
<br />
== Time Profiles ==<br />
Incident rules can be active configured to be active in configured time spans (time profiles).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Channel configuration ==<br />
[[File:Incidents channels.png|thumb|600x600px|Channel configuration]]<br />
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.<br />
<br />
Each channel can be of type:<br />
<br />
'''email''' Incidents will be sent to the email address configured in the [[Global settings]].<br />
<br />
'''kafka''' The incidents are sent to a topic on the configured Apache Kafka server. Firmware >= 4.0. The message is the same as for syslog.<br />
* Bootstrap Server: hostname/ip:port of a Kafka Broker or multiple Brokers separated by comma<br />
* Protocol: Plaintext (no authentication, no encryption), SASL Paintext (Plain authentication, no encryption), SASL SSL (Plain authentication, TLS/SSL encryption)<br />
* Ignore TLS Certificate: Ignore the TLS Certificate of the Brokers (only SASL SSL)<br />
* Username: Broker Login (only SASL)<br />
* Password: Broker Login (only SASL)<br />
* Topic: The name of the topic into which the Incidents are sent.<br />
<br />
'''snmp_trap''' Incidents will be sent to the configured SNMP trap receiver (firmware >= 4.0). A MIB file with the Allegro Network Multimeter SNMP trap definitions is available for download in the channel configuration dialog.<br />
* Version: Supported SNMP version of the trap receiver (SNMP v2c or SNMP v3)<br />
* Trap receiver (manager) hostname/IP: The trap receiver hostname or IP address<br />
<br />
''SNMP v2c'':<br />
* Community name: SNMP community name expected by the trap receiver<br />
<br />
''SNMP v3'':<br />
* Authentication protocol: Protocol for authenticated messages (MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512)<br />
* Authentication password: Pass phrase for authenticated messages<br />
* Privacy protocol: Protocol for message encryption (AES, DES)<br />
* Privacy password: Pass phrase for message encryption<br />
* Security name: Security name for authenticated SNMP messages<br />
* Security level: Security level for SNMP messages (noAuthNoPriv, authNoPriv, authPriv)<br />
* Engine ID: Authoritative (security) engineID (hexadecimal number)<br />
<br />
'''syslog''' Incidents will be sent to the configured syslog server via TCP on any TCP or UDP port.<br />
<br />
<br />
[[File:Incidents add channel.png|thumb|alt=|none|Adding a new channel]]<br />
Each channel also uses a minimum severity setting, so only incidents are reported which are of at least that severity.<br />
<br />
Each channel can be configured to only handle incidents from live traffic or from replayed traffic.<br />
<br />
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.<br />
<br />
== Interface burst incident ==<br />
[[File:Incidents others.png|thumb|600x600px|Other incidents]]<br />
Burst incidents with milli-second resolution can be generated when the interface throughput exceeds a configurable threshold. The incident contains a graph of traffic for that interface with some data points before and after the threshold has been exceeded depending on the measurement interval. A PCAP link for capturing from the packet ring buffer is shown. For further investigation of that incident, the button "Use as global time range" can be used to set the global range to the start and end of the incident graph (at least 5 seconds) so that all modules of the Allegro Network Multimeter show that time span. The incident generation can be configured as follows:<br />
* '''Report "throughput threshold exceeded" with severity''': report an incident with the selected severity level if the throughput of any network interface exceeded.<br />
* '''Throughput threshold (Mbit/s)''': The threshold is configured in Mbit/s.<br />
* '''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.<br />
* '''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.<br />
<br />
== Occured incidents ==<br />
This page shows up to the last 1000 incidents occurred on the system. The table can be filtered for specific severity levels, as well as for specific trigger sources by selecting the trigger from the drop down menu.<br />
[[File:Incidents list filter.png|thumb|600x600px|Filter incidents by severity or trigger]]<br />
The list can also be filtered for the subject of the incident.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Statistics about incident rules ==<br />
[[File:Incidents stats.png|thumb|600x600px|Statistics about rules]]<br />
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.<br />
<br />
== Incident list per measurement modules ==<br />
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.<br />
<br />
== Limitations ==<br />
Some technical limitations apply:<br />
<br />
* 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.</div>Ralf