Packet ring buffer and Longterm DB: Difference between pages

From Allegro Network Multimeter Manual
(Difference between pages)
Jump to navigation Jump to search
Access restrictions were established for this page. If you see this message, you have no access to this page.
(mention filters for port ranges and l4 protocols)
 
No edit summary
 
Line 1: Line 1:
== Packet ring buffer==
==Description==
The ring buffer feature allows to create a buffer of fixed size on an external storage device to which all processed packets will be recorded.
The Long-term DB feature (in firmware >= 4.3) uses an attached storage devices to store traffic information of IP addresses and Layer 7 protocols with low resolution for a much longer time than the live statistics.
If the fixed size buffer is full then the oldest packets in the buffer will be replaced with new packets in a round-robin fashion.
If the feature is not enabled, a button titled '''Create ring buffer''' is visible.
Upon clicking on it an empty packet ring buffer is created. To actually store data, storage space needs to allocated to the Packet Ring Buffer. In the ''Configuration'' tab by clicking on a ''Allocate space for Packet Ring Buffer'' button, a dialogue will be displayed and allows you to specify the size of the ring buffer.
It must be ensured that enough space is available on the external storage device.
As soon as storage space has been allocated to the Packet Ring Buffer, packets will be stored and the graphs on the ''Statistics''  tab will reflect this:
 
 
'''Web interface'''
{| class="wikitable sortable"
|-
|[[File:Create Packet ring buffer1.png|600px|none]]
|}
 
{| class="wikitable sortable"
|-
|[[File:Create Packet ring buffer2.png|600px|none]]
|}
 
* Timestamp of oldest packet: The timestamp of the oldest packet in the ring buffer.
 
* Total size: The total size of the ring buffer on the external storage device.
:If the cluster packet ring buffer feature is active and the Write redundancy level is set to a different value than zero replication, an adjusted value is displayed to reflect the redundant copies of packet data.
:The raw on-disk value will be displayed next to it in parentheses.
 
* Used size: The currently used amount of memory in the capture buffer.
:If the cluster packet ring buffer feature is active and the Write redundancy level is set to a different value than zero replication, an adjusted value is displayed to reflect the redundant copies of packet data. The raw on-disk value will be displayed next to it in parentheses.
*Overall bytes captured since start: The amount of captured bytes since start of the packet ring buffer. Starting with version 3.6 this statistic is persisted beyond a restart of the system.
:This value may be larger than the used size in case the ring buffer is full and parts of it were overwritten.
:The history graph shows the captured traffic of the last minute or in the selected interval (if set).
*Bytes/Packets dropped since start: The traffic which was processed but could not be written to the ring buffer since the start of the packet ring buffer. Starting with version 3.6 this statistic is persisted beyond a restart of the system.
: This is usually an indicator that writes to the external storage device were not fast enough. The history graph shows the drops over time.
*Bytes discarded due to filter rules since start: The traffic which matched the filter rules criteria and was not written to the ring buffer. Starting with version 3.6 this statistic is persisted beyond a restart of the system.
: The history graph shows discarding over time.
*Data in flight: The amount of data which is currently stored in the queue that holds processed packets before they are written to the packet ring buffer.
:If larger bursts of traffic need to be stored in this queue, the size can be modified in the capture module settings.
:
When the ring buffer is full and old packets are deleted, the graphs will show the time range with no data with a dark grey background colour.
The time range before start of the ring buffer will be visualized in the same way.
When the ring buffer is running, the behaviour of the pcap capture buttons throughout the system changes: if the user interface is in live mode and a capture is started, a dialogue will appear asking you to specify from how far back in time the capture should start.
This way it is possible to e.g. capture the traffic of an IP address starting from an hour ago.
The capture will also continue with live traffic.
If the user interface is in '''back-in-time''' mode (a timespan from the past is selected) starting a capture will produce a dialogue asking to confirm that the capture will cover exactly the timespan selected.
The capture will automatically stop after the selected timespan has been processed. 
 
{| class="wikitable sortable"
|-
|[[File:Create Packet ring buffer3.png|1200px|none]]
|}
 
====Packet Ring Buffer with multiple disks====
The Packet Ring Buffer feature allows you to use multiple whole disks and multiple storage space allocations on active storage devices in parallel for a single packet ring buffer.
This also allows you to optionally write redundant copies of packets to multiple disks to provide fault tolerance in case of a disk failure.
 
It is also possible to create multiple Packet Ring Buffers that
run in parallel. To enable multiple Packet Ring Buffers, the
option `The maximum number of concurrent packet ring buffers` in the
capture module options can be set to the required number.
 
If multiple Packet Ring Buffers are used, the page will show
a number of buttons at the top to switch between the different Packet Ring Buffers.
Each Packet Ring Buffer has its own statistics and configuration.
 
In the ''Configuration'' tab you can configure the '''Write redundancy level''' at the very top.
This level controls how many redundant copies of each packet are written.
No replication means that only a single copy of each packet is written and provides no redundancy.
This level gives the highest write bandwidth for a given number of disks; single replication means that one additional copy of each packet is written to some other disk and thus reduces the total write performance for a given number of disks to half the performance of no replication.
Double replication and triple replication writes two and three additional copies of each packet respectively.
Note that for each level to work there must be at least the number of replications + 1 disks available in the cluster.
 
 
'''Web interface'''
 
Below the '''Write redundancy level''' setting is the list of all disks available for use in the Packet Ring Buffer.
The following columns are displayed in the list:
*Disk: A description of the disk and its capacity.
*Enclosure: If the disk is part of a multi-disk enclosure this column will show the enclosure number along with the slot number.
*Status: If the disk has been added to the cluster this column will display the current status as '''ok''' or '''failed'''. If multiple Packet Ring Buffers are used this will also show if the disk or storage space is active in another cluster.
*Locator: For disks in a multi-disk enclosure the button displayed in this column allows to turn the slot locator LED on and off.
 
 
In the last unlabelled column, buttons are displayed which have the following functionality.
 
These buttons are shown for working with entire disks:
* Add to Packet Ring Buffer: Add a complete disk to the Packet Ring Buffer.
: The disk will be formatted and added as empty storage to the Packet Ring Buffer. All previous data on the disk is lost.
*Resume in Packet Ring Buffer: If the disk was previously part of a Packet Ring Buffer it can be resumed.
: The data on that disk is now part of the Packet Ring Buffer.
*Remove from Packet Ring Buffer: Remove the disk from the Packet Ring Buffer.
:The data stored on that disk is no longer part of the Packet Ring Buffer but the data is not removed from the disk. It can be resumed in the Packet Ring Buffer at a later time.
:
These buttons are shown for working active storage devices:
 
* Allocate space for Packet Ring Buffer: Allocate space on an active storage device and add that space to the Packet Ring Buffer. It will then be shown in the list below the active storage device.
* Delete: Removes the allocated storage space from the Packet Ring Buffer and permanently deletes it from the storage device.
* Remove from Packet Ring Buffer: Removes the allocated storage space from the Packet Ring Buffer but leaves it on the storage device.
* Resume in Packet Ring Buffer: Add a currently unused storage space from a storage device to the Packet Ring Buffer.


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


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


If a disk is missing because it was e.g. removed from the enclosure, it will be displayed in a separate list with much of the information as in the list described above but only one button with the option to remove it from the Packet Ring Buffer.
The storage is used similar to a swap file mechanism so the long-term data is not kept between restart unless the [[DB persistence]] feature is enabled too, which is recommended when using the long-term feature. To reduce the amount of time to dump/restore, the DB persistence configuration allow to skip storing live data.  


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


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


'''Web interface'''
The navigation menu in the long-term view only contains those modules which are available in this view.
{| class="wikitable sortable"
|-
|[[File:Cluster4.png|1200px|none]]
|}


====Packet ring buffer filter====
If the long-term view is activated on module pages which do not support long-term data, a corresponding info box is shown.
Rules can be configured to control the snapshot length of each packet which will be stored in the packet ring buffer.
These rules can also be used to prevent certain packets from being stored in the packet ring buffer.
This allows you to fine tune how much packet data needs to be written to the packet ring buffer.
The information about the original length of a packet will still be available in captures except when the packet was not written to the packet ring buffer at all (e.g. due to a '''discard''' rule).  


These rules can be created, edited, deleted, moved up and moved down in the rules list by using the respective buttons. They can also be given names to quickly see what rule is used for what purpose.
==Setting==
The configuration can be found in the global settings page in the "Long-term DB and persistence" tab.


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


When creating a filter rule, a dialogue is displayed and allows the following options:
It is recommended to also enable the [[DB persistence]] feature to be able to save and restore the long-term DB data during restarts.
* Rule condition: Specify which packets to match.


:The input field below allows entering the corresponding value.
Once enabled, the utilization of the file is shown and the [[System Info Page]] contains information about how long the data can be kept.


:{| class="wikitable"
Tip: Since the amount of information stored in the long-term DB is limited by the graph resolution, the file size usually don't need to be similar sized as the main memory. 10 GByte is a good starting point.
|-
!Rule condition
!description
|-
|All packets
| everything
|-
|MAC address
|source or destination MAC address
|-
|IP address
|source or destination IP address or subnet
|-
|TCP port
|the source or destination TCP port (lists and ranges are allowed).
|-
|UDP port
|the source or destination UDP port (lists and ranges are allowed).
|-
|Layer 4 protocol
|the selected Layer 4 protocol
|-
|Layer 7 protocol
|the selected Layer 7 protocol
|-
|outer VLAN tag
|the most outer VLAN tag (directly after Ethernet header). It is also possible to match packets that have no VLAN tag at all by choosing 'no VLAN' from the drop-down menu or match packets with an arbitrary VLAN tag by choosing 'any VLAN' form the drop-down menu.
|-
| interface
|the ingress interface the packet originated from
|-
|SIP phone number
|
The number matches part of the 'From:', 'To:', 'Request-URI', 'Contact', 'P-Asserted-Identity' or 'P-Preferred-Identity' entry in a SIP INVITE packet.
*only the part between '''<nowiki>'<'</nowiki>''' and '''<nowiki>'>'</nowiki>''' of the From/To line is tested.
*value '''<nowiki>'234'</nowiki>''' will match '<nowiki>From: "Caller1" <sip:234></nowiki>', but also '<nowiki>From: "Caller2" <sip:12345@test></nowiki>'
*to match from the start, use '''<nowiki>'sip:234'</nowiki>'''


Correlating SIP packets for the same Call-ID will match.
The size can be increase but it requires a restart of the packet processing.


The RTP and RTCP packets correlated to this SIP call will also match.
[[File:DB persistence settings.png|thumb|Long-term DB settings]]
|-
|Calls between SIP phone number A and B
|Match SIP, RTP and RTCP packets related to SIP phone calls between both numbers
|-
|virtual link group
|the virtual link group the packet belongs to
|-
|IP group
|the IP group the packet belongs to
|-
|SSL after handshake
| SSL packets that occur after the SSL handshake (the encrypted part of the SSL communication)
|}


*Negate: Controls comparison of the rule condition to the value. If this is off, the value must match.
== Notes ==
:If this is on, the value must not match.
Recommended storage device types:
*Action: What shall be done with the matching packets.
{| class="wikitable"
:{| class="wikitable"
|+
|-
!Storage device
!Action!!Description
!Note
|-
|-
|Snapshot length
|NMVe based SSD
|The packet is captured with a max length as specified in the input field below. If the packet is larger, the remaining bytes will be discarded.
|recommended
|-
|-
|Discard
|SATA based SSD
|Discard the whole packet.
|can be used for moderate traffic, check system load for high system utilization
|-
|-
|Full
|USB based SSD
|The entire packet is captured.
|not recommended, but might be useful for small systems (Allegro 200/500)
|-
|-
|Header + data
|HDD
|
|not recommended, should not be used
Capture just certain parts of the packet.
 
When selecting '''L3 header''', Layer 2 and Layer 3 headers are stored.
 
When selecting '''L3 + L4 header''', Layer 2, 3 and 4 headers are stored.
 
When selecting '''L3 + L4 + L7 data''', an input field is shown where the length of Layer 7 data can be configured.  In this case Layers 2, 3 and 4 are stored together with the specified amount of Layer 7 data.
 
|}
|}
It is also not recommended to place the long-term DB on the same storage device that is used a packet ring buffer as it will deteriorate the performance of both features.


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


====Extracting the packet ring buffer====
# The data in the long-term DB is limited to a selected subset of the data in the In-Memory-DB. See above for an exact list of elements available.
When the packet ring buffer is active, the entire contents can be extracted by capturing the complete timespan that is contained within.  
# The data is written into the long-term DB in variable intervals depending on traffic and system load. It takes up to 10 minutes (two graph intervals) until the data appears in the graph. Therefore, the last 5-10 minutes appear empty or with less traffic than in live view.
For convenience, a button labelled Extract packet ring buffer is available that opens the capture dialogue with the start time and end time set to the appropriate values.

Revision as of 12:20, 11 February 2025

Description

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

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

  • IP addresses
    1. activity time
    2. traffic graph in 5 minute resolution
  • Layer 7 protocols
    1. traffic graph in 5 minute resolution

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

Usage

Long-term DB activated dashboard
Long-term DB activated dashboard

If this feature is enabled, a view toggle button appears in the top menu bar. This button allows to switch between the real time "RT" view and the long-term ("LT") view.

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

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

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

Setting

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

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

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

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

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

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

Long-term DB settings

Notes

Recommended storage device types:

Storage device Note
NMVe based SSD recommended
SATA based SSD can be used for moderate traffic, check system load for high system utilization
USB based SSD not recommended, but might be useful for small systems (Allegro 200/500)
HDD not recommended, should not be used

It is also not recommended to place the long-term DB on the same storage device that is used a packet ring buffer as it will deteriorate the performance of both features.

Limitations

  1. The data in the long-term DB is limited to a selected subset of the data in the In-Memory-DB. See above for an exact list of elements available.
  2. The data is written into the long-term DB in variable intervals depending on traffic and system load. It takes up to 10 minutes (two graph intervals) until the data appears in the graph. Therefore, the last 5-10 minutes appear empty or with less traffic than in live view.
Retrieved from "https://allegro-packets.com/wiki/index.php?title=Packet_ring_buffer&oldid=4966"