325
edits
Remco.derooy (talk | contribs) No edit summary |
Remco.derooy (talk | contribs) No edit summary |
||
Line 12: | Line 12: | ||
Access to “Top users” and “Quality” screens highlighted in the green box | Access to “Top users” and “Quality” screens highlighted in the green box | ||
===TOP users === | |||
The “Top users” screen is a great place to start your generic troubleshooting workflow. The top users screen provides you with high-level information about what is going on in your network. On this page you will find trending graphs and tables, depicting total packets and bytes for the top 5 IPs, top 5 MACs and top 5 protocols that were traversing your network – during the selected time interval. | The “Top users” screen is a great place to start your generic troubleshooting workflow. The top users screen provides you with high-level information about what is going on in your network. On this page you will find trending graphs and tables, depicting total packets and bytes for the top 5 IPs, top 5 MACs and top 5 protocols that were traversing your network – during the selected time interval. | ||
Toggling between tables and graphs, can be easily done by clicking the respective icon next to the widget’s caption. | Toggling between tables and graphs, can be easily done by clicking the respective icon next to the widget’s caption. | ||
Line 38: | Line 38: | ||
=== IP details page === | |||
Line 55: | Line 55: | ||
==== Burst Analysis ==== | |||
The first graph on Allegro’s predefined quality dashboard, represents “Burst Analysis”. Because the Allegro Network Multimeter supports data measurement intervals (sampling rates), as detailed as 1 ms, you can identify instances where a Link is 100% saturated, for very short fractions of time. Evidently, micro bursts could potentially be a root cause for network performance issues. Other than Allegro Packets, most monitoring & troubleshooting solutions are unable to pick this up, because of “low resolution” data sampling (i.e. 1, 5, or even 10 minutes). | The first graph on Allegro’s predefined quality dashboard, represents “Burst Analysis”. Because the Allegro Network Multimeter supports data measurement intervals (sampling rates), as detailed as 1 ms, you can identify instances where a Link is 100% saturated, for very short fractions of time. Evidently, micro bursts could potentially be a root cause for network performance issues. Other than Allegro Packets, most monitoring & troubleshooting solutions are unable to pick this up, because of “low resolution” data sampling (i.e. 1, 5, or even 10 minutes). | ||
==== Response times ==== | |||
The second graph provides you with trending information about global response times for TCP and HTTP, SSL, DNS plus DHCP. Clicking on “Application”, will bring you to the response time overview page, where trending response time graphs for HTTP, SSL, DNS and DHCP are individually presented. | The second graph provides you with trending information about global response times for TCP and HTTP, SSL, DNS plus DHCP. Clicking on “Application”, will bring you to the response time overview page, where trending response time graphs for HTTP, SSL, DNS and DHCP are individually presented. | ||
Line 72: | Line 72: | ||
Because you already zoomed into to a specific time frame on the graph, this page will now only show you the client / DHCP-server relations, that happened during the time frame that you selected in the graph. Also on this page, you’ll find a download button for simple (retroactive) extraction of a Pcap, that is pre-filtered to only contain DHCP and BOOTP packets. | Because you already zoomed into to a specific time frame on the graph, this page will now only show you the client / DHCP-server relations, that happened during the time frame that you selected in the graph. Also on this page, you’ll find a download button for simple (retroactive) extraction of a Pcap, that is pre-filtered to only contain DHCP and BOOTP packets. | ||
==== UDP Jitter & packet loss ==== | |||
The next two graphs provide trending and actionable insights for UDP-based protocols RTP and Profinet. First up is the graph depicting Jitter over time. Bad jitter can have a very negative impact on business critical production services and on VoIP- / Unified Communication services. | The next two graphs provide trending and actionable insights for UDP-based protocols RTP and Profinet. First up is the graph depicting Jitter over time. Bad jitter can have a very negative impact on business critical production services and on VoIP- / Unified Communication services. | ||
Line 80: | Line 81: | ||
From this graphs, it is very easy to quickly identify quality issues, such as instances where jitter is above 20ms in networks where VoIP is being used. | From this graphs, it is very easy to quickly identify quality issues, such as instances where jitter is above 20ms in networks where VoIP is being used. | ||
==== TCP retransmissions/packet loss ==== | |||
The next two graphs provide trending visibility and information about TCP packet loss in your network. TCP retransmission are seen in all networks, it’s the amount of retransmission -and better yet the retransmission ratio in percent- that indicate if things are problematic in your network. This is why graphs for both TCP retransmissions in absolute numbers, as well as in ratio are presented to you. | The next two graphs provide trending visibility and information about TCP packet loss in your network. TCP retransmission are seen in all networks, it’s the amount of retransmission -and better yet the retransmission ratio in percent- that indicate if things are problematic in your network. This is why graphs for both TCP retransmissions in absolute numbers, as well as in ratio are presented to you. | ||
Line 88: | Line 90: | ||
As a reference; for wired infrastructures, a retransmission ratio of up to 2% is generally accepted to still be okay. In wireless infrastructures however, retransmissions of up to 10% are very common and considered to be a well-functioning wireless network. | As a reference; for wired infrastructures, a retransmission ratio of up to 2% is generally accepted to still be okay. In wireless infrastructures however, retransmissions of up to 10% are very common and considered to be a well-functioning wireless network. | ||
==== TCP Zero window ==== | |||
For identifying application performance problems and/or server capacity issues, the “TCP Zero Window” graph is a very, very powerful instrument. Here’s why… | For identifying application performance problems and/or server capacity issues, the “TCP Zero Window” graph is a very, very powerful instrument. Here’s why… | ||
TCP zero window packets are being sent out by a client or (mostly) server, whenever it cannot optimally handle the oncoming traffic any more. Because of whatever reason, its receive buffer is full, and the device will start every sending party to slow down – by means of TCP zero packets. | TCP zero window packets are being sent out by a client or (mostly) server, whenever it cannot optimally handle the oncoming traffic any more. Because of whatever reason, its receive buffer is full, and the device will start every sending party to slow down – by means of TCP zero packets. |
edits