325
edits
Generic troubleshooting processes: Difference between revisions
Generic troubleshooting processes (view source)
Revision as of 10:39, 12 November 2021
, 12 November 2021no edit summary
Remco.derooy (talk | contribs) No edit summary |
Remco.derooy (talk | contribs) No edit summary |
||
| Line 54: | Line 54: | ||
+++++ IMAGE +++++ | +++++ IMAGE +++++ | ||
=== Burst Analysis === | === ---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 === | === ---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 74: | 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 === | === UDP Jitter & packet loss === | ||
| Line 84: | 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 === | === TCP retransmissions/packet loss === | ||
| Line 94: | 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 === | === TCP Zero window === | ||