Network Burst Analysis: Difference between revisions

Access restrictions were established for this page. If you see this message, you have no access to this page.
(Created page with "== ''' Problem''' == How can you use the *Allegro Network Multimeter* to quickly and easily detect network bursts and find out the related sender and receiver? <br> == '''...")
 
(Undo revision 5063 by Markus.Geissler (talk))
Tag: Undo
 
(16 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== ''' Problem''' ==
== Problem ==
How can you use the *Allegro Network Multimeter* to quickly and easily detect
How can you use the Allegro Network Multimeter to quickly and easily detect
network bursts and find out the related sender and receiver?
network bursts and find the related sender and receiver?
<br>


== Burst detection ==
The Allegro Network Multimeter provides several options to detect bursts.


* You can use the total throughput graph in the Dashboard. This graph aggregates the incoming traffic on all interfaces. The data is displayed with a resolution of one second. A burst that leads to a significant increase of traffic with a long enough duration can be easily seen as a spike.
* You can view the traffic graphs on the "Interface stats" page. These graphs display traffic per interface and use the same time resolution of one second.
* For an automatic notification when the total bandwidth throughput is too high, you can use bandwidth incidents. They are configured under 'Settings' -> 'Incident settings' -> 'Global incidents'. Just define a lower or upper threshold of bandwidth or packet rate and a severity. The time resolution is one second.
* For a higher resolution of up to 1 ms you can use the "Interface throughput" incidents. They are per interface incidents and will be generated when a threshold is exceeded.


== ''' Burst detection''' ==
== Interface throughput incidents ==
The Allegro Network Multimeter offers several possibilities to detect bursts.
In this example we will use the "Interface throughput" incidents to detect bursts and find  
 
* You can use the total throughput graph in the Dashboard. The graph aggregates
  the incoming traffic of all interfaces. The data is displayed with a resolution
  of one second. A burst that led to a significant increase of traffic
  and had a long enough duration can be easily seen as a spike.
* You can use the traffic graphs on the "Interface stats" page. These graphs display
  traffic per interface and work with the same time resolution of one second.
* For an automatic notification when the bandwidth of the total throughput is too
  high, you can use the bandwidth incidents. They are configured under
  'Settings' -> 'Incident settings' -> 'Gobal incidents'. Just define a lower or upper
  threshold of bandwidth or packet rate and a severity. The time resolution is
  one second.
* For a higher resolution of up to 1 ms you can use the "Interface throughput"
  incidents. They are per interface incidents and will also be generated when a
  threshold is exceeded.
 
<br>
 
 
== ''' Interface throughput incidents''' ==
We will use the "Interface throughput" incidents to detect bursts and find out
who sent the packets.
who sent the packets.


Line 42: Line 26:
After several minutes we get a notification and go to the overview under
After several minutes we get a notification and go to the overview under
'Generic' -> 'Incidents'. When clicking on the incident we see details about the burst.
'Generic' -> 'Incidents'. When clicking on the incident we see details about the burst.
{|  
{|  
| [[File:Ap-mm-burst-analysis-incident.png|600px|thumb|right]]
| [[File:Ap-mm-burst-analysis-incident.png|600px|thumb|right]]
|}
|}
The burst started at 14:42:26.695 and took about 5 measurement cycles (25 ms).
 
A PCAP link is available and will offer a capture of the time around the burst
The burst started at 14:42:26.695 and lasted around 5 measurement cycles (25 ms).
for a deep per packet analysis. Let's download the PCAP and use it later.
A pcap link is available and will offer a capture of the time around the burst
for a deep per-packet analysis. Let's download the pcap and use it later.


The "Use as global time range" button allows for setting the global data range
The "Use as global time range" button allows for setting the global data range
around the time of the burst. By using it, all modules in the *Allegro Network
around the time of the burst. By using it, all modules in the Allegro Network
Multimeter* will display statistics and provide captures for this time range. As
Multimeter will display statistics and provide captures for this time range. Since
we want to analyze the burst we click on it.
we want to analyze the burst we click on it.


<br>
== What was responsible for the burst? ==
Let's take a look at the Dashboard.


== ''' Who was responsible for the burst?''' ==
Let's take a look on the dashboard.
{|  
{|  
|  
|  
[[File:Ap-mm-burst-analysis-dashboard.png|600px|thumb|right]]
[[File:Ap-mm-burst-analysis-dashboard.png|600px|thumb|right]]
|}
|}
The time resolution of the total throughput graph is too low to display the same
 
The total throughput graph time resolution is too low to display the same
values as in the incident graph. But we get a good overview of the IPs with the
values as in the incident graph. But we get a good overview of the IPs with the
most traffic during this time interval. AFP and SSL were the most used protocols. The
most traffic during this time interval. AFP and SSL were the most used protocols. The
traffic value of an IP is bidirectional so a pair of sender and receiver would
traffic value of an IP is bi-directional, so a sender and receiver pair would
have about the same traffic and can be seen quite easily.
have around the same traffic and can be seen quite easily.


We could assume that any of the top four IP addresses is either the sender or
We could assume that any of the top four IP addresses is either the sender or
receiver of the packets of the burst. Although the fifth IP address has a relatively
receiver of the burst packets. Though the fifth IP address has a relatively
high packet rate compared to the others, the amount of Bytes is significantly
high packet rate compared to the others, the byte count is significantly
lower and it is not likely involved in the burst.
lower and it is not likely involved in the burst.


In all graphs you can zoom in and out by pressing the Shift key and use the
You can zoom in and out in all graphs  by pressing the Shift key and use the
mouse wheel. This will set the global time range and update the displayed graphs
mouse wheel. This will set the global time range and update the displayed graphs
and values. After zooming out, we still see the same traffic distribution on the
and values. After zooming out, you still see the same traffic distribution on the
dashboard.
Dashboard.


Let's check the more detailed IP list under 'IP' -> 'IP' statistics to get a clearer
Let's check the more detailed IP list under 'IP' -> 'IP' statistics to get a clearer
Line 83: Line 68:
with each other. Perhaps we can find some pattern in the traffic related to the
with each other. Perhaps we can find some pattern in the traffic related to the
burst?
burst?
{|  
{|  
|  
|  
Line 89: Line 75:


We can immediately see a spike in both IP addresses 10.54.0.108 and 10.54.0.225
We can immediately see a spike in both IP addresses 10.54.0.108 and 10.54.0.225
at around the time of the incident.
around the time of the incident.


Now let's analyze the IP address 10.54.0.108 by clicking on it and opening the
Now let's analyze the IP address 10.54.0.108 by clicking on it and opening the
tab "Peers":
tab "Peers":
{|  
{|  
|  
|  
[[File:Ap-mm-burst-analysis-ip-peer.png|600px|thumb|right]]
[[File:Ap-mm-burst-analysis-ip-peer.png|600px|thumb|right]]
|}
|}
Both IP addresses communicated with each other. 10.54.0.225 suddenly started
Both IP addresses communicated with each other. 10.54.0.225 suddenly started
sending a unusual high amount of packets to 10.54.0.108.
sending a unusually high number of packets to 10.54.0.108.
 
We can now check for more details in the pcap provided by the throughput incident.


We can now check for more details in the PCAP provided by the throughput incident.
{|  
{|  
|[[File:Ap-mm-burst-analysis-wireshark.png|600px|thumb|right]]
|[[File:Ap-mm-burst-analysis-wireshark.png|600px|thumb|right]]
|}
|}
Before the time of the incident the traffic was significantly lower. At
 
14:42:26.69497 IP address 10.54.0.108 sent a packet to 10.54.0.225 and it started
Before the time of the incident, the traffic was significantly lower. At
14:42:26.69497 IP address 10.54.0.108 sent a packet to 10.54.0.225 which triggered
the traffic burst.
the traffic burst.

Latest revision as of 09:57, 16 May 2025

Problem

How can you use the Allegro Network Multimeter to quickly and easily detect network bursts and find the related sender and receiver?

Burst detection

The Allegro Network Multimeter provides several options to detect bursts.

  • You can use the total throughput graph in the Dashboard. This graph aggregates the incoming traffic on all interfaces. The data is displayed with a resolution of one second. A burst that leads to a significant increase of traffic with a long enough duration can be easily seen as a spike.
  • You can view the traffic graphs on the "Interface stats" page. These graphs display traffic per interface and use the same time resolution of one second.
  • For an automatic notification when the total bandwidth throughput is too high, you can use bandwidth incidents. They are configured under 'Settings' -> 'Incident settings' -> 'Global incidents'. Just define a lower or upper threshold of bandwidth or packet rate and a severity. The time resolution is one second.
  • For a higher resolution of up to 1 ms you can use the "Interface throughput" incidents. They are per interface incidents and will be generated when a threshold is exceeded.

Interface throughput incidents

In this example we will use the "Interface throughput" incidents to detect bursts and find who sent the packets.

For back-in-time data capture you can use the packet ring buffer feature.

Under 'Settings' -> 'Modules settings' -> 'Interface' we enable the measurement module and set the duration of the measurement interval to 5 ms. You can set it from several seconds to as low as 1 ms. Under 'Settings' -> 'Incident settings' -> 'Interface throughput' the incident must be enabled by setting the severity to "Low" and a threshold of 700 Mbit/s.

After several minutes we get a notification and go to the overview under 'Generic' -> 'Incidents'. When clicking on the incident we see details about the burst.

The burst started at 14:42:26.695 and lasted around 5 measurement cycles (25 ms). A pcap link is available and will offer a capture of the time around the burst for a deep per-packet analysis. Let's download the pcap and use it later.

The "Use as global time range" button allows for setting the global data range around the time of the burst. By using it, all modules in the Allegro Network Multimeter will display statistics and provide captures for this time range. Since we want to analyze the burst we click on it.

What was responsible for the burst?

Let's take a look at the Dashboard.

The total throughput graph time resolution is too low to display the same values as in the incident graph. But we get a good overview of the IPs with the most traffic during this time interval. AFP and SSL were the most used protocols. The traffic value of an IP is bi-directional, so a sender and receiver pair would have around the same traffic and can be seen quite easily.

We could assume that any of the top four IP addresses is either the sender or receiver of the burst packets. Though the fifth IP address has a relatively high packet rate compared to the others, the byte count is significantly lower and it is not likely involved in the burst.

You can zoom in and out in all graphs by pressing the Shift key and use the mouse wheel. This will set the global time range and update the displayed graphs and values. After zooming out, you still see the same traffic distribution on the Dashboard.

Let's check the more detailed IP list under 'IP' -> 'IP' statistics to get a clearer picture. We want to find out whether the top IP addresses were communicating with each other. Perhaps we can find some pattern in the traffic related to the burst?

We can immediately see a spike in both IP addresses 10.54.0.108 and 10.54.0.225 around the time of the incident.

Now let's analyze the IP address 10.54.0.108 by clicking on it and opening the tab "Peers":

Both IP addresses communicated with each other. 10.54.0.225 suddenly started sending a unusually high number of packets to 10.54.0.108.

We can now check for more details in the pcap provided by the throughput incident.

Before the time of the incident, the traffic was significantly lower. At 14:42:26.69497 IP address 10.54.0.108 sent a packet to 10.54.0.225 which triggered the traffic burst.