12,300
edits
This is the support site for Andrews & Arnold Ltd, a UK Internet provider. Information on these pages is generally for our customers but may be useful to others, enjoy!
mNo edit summary |
mNo edit summary |
||
(21 intermediate revisions by 4 users not shown) | |||
<indicator name="Diagnostics">[[File:menu-spanner.svg|link=:Category:Diagnostic Tools|30px|Back up to the Diagnostics Category]]</indicator>
__NOTOC__The FB6000 [[L2TP]] router provides us with Continuous Quality Monitoring (CQM). This allows us to track the quality of each and every connection in great detail. The router itself produces the graphs in real time, and can also provide csv files with accurate data for each graph.▼
▲
Customers and Staff can view these graphs in near real time (updated every 100 seconds), and can view historical graphs.▼
▲Customers and
{{CPbox|#Click on the line you want to view
#Clicking on the graph again will show
==How does it work?==
Our router sends an LCP echo (a bit like a ping) every second while a line is active. Your router replies. We track how long it takes for each reply to arrive, and how many are lost. These results are collated into 100 second samples and shown as a graph like the one on this page. The graph shows us lots of information about the line, and gives a history covering the last 24 hours.
==What information is on the graph?==
[[File:Cqm-screen-shot-notes.png|
Each column (pixel) represents 100 seconds of samples. The hour of day is shown at the bottom, and the day and date shown next to midnight in the graph. There is additional text superimposed on the graph such as a circuit ID. There are 8 pieces of data shown for each 100 second sample as follows:-▼
▲Each column (pixel) represents 100 seconds of samples. The hour of day is shown at the bottom, and the day and date shown next to midnight in the graph. There is additional text superimposed on the graph such as a circuit ID.
===A note on Tx/Rx download/upload===
===Pins===
=ICMP Graphs=
Optionally,
[[File:Cqm-icmp.png|none|frame|An graph created from ICMP Pings to a WAN address]]
Customers
Sometimes a normal CQM graph may have a salmon background - this would usually be when the line is logged in to our test LNS.
[[File:CQM1.png|none|frame|Lots of upload at the end of the day]]
(Not an ADSL
Here is another, an FTTC line filling the up link whilst doing a backup (
[[File:CQM-FTTC-upload.png|none|frame|Lots of upload in the morning - a backup without any traffic shaping on the client end]]
This line is doing a large backup from just before 6am. The dark red horizontal line shows the traffic, during this time there is lots of packet loss (red) and the light blue at the bottom is showing high latency. So, whilst the backup is happening the line has about 50% packet loss and around
===Redcare===
[[File:Cqm-dropping2.png]]
This line does have a fault. It is dropping sync throughout the day. In this type of case, go through the usual checks, and AAISP will report a fault, which will probably need a BT SFI
===Only Dropping during the day===
[[File:CQM4.png]]
(Probably not an ADSL Fault.) If a line is dropping during the day, and maybe just Monday to Friday, then it's probably not going to be an upstream problem. This could be caused by interference
===Interleaving being applied===
For more info see: [[Interleaving]]
===Heavy
Also see [[Packet Loss]]
[[File:CQM-heavyloss.png|none|frame|This is showing more than 50% packet loss with no usage. A problem!]]
[[File:Cqm-packetloss-contactfault.png|none|frame|This line has loss due to a
[[File:Cqm-VPcongestionOrfault.png|none|frame|Packet loss when a downloading but not filling the line]]
This is a rather strange one. There is
===Phone line half connected - DIS in one leg===
[[File:CQM-FTTC-DIS-in-one-leg.png|none|frame|FTTC running on just a single leg/wire]]
Here we have a perfectly good FTTC, running at 80M. However, in the evening the line goes rather crazy! Here is what happened:
*18:20 The end user was doing some tidying up of wiring and accidental disconnected one of the wires that make up the pair used for the phone line
**The line dropped a few times and reconnected, but the sync speed dropped to from 20 Mbps up and 80 Mbps down to 600 kbps up and 23 kbps down!
*The line continued working for a short while, up until:
*19:20 where a backup job was started which started uploading data
**As the sync speed was so low, the backup filled the link and high latency (blue) ensued.
**At this point, the end user noticed something was not right.
*Looking at the times on the graph gave a clue to the end user what had happened. They had accidentally disconnected one of the wires of the phone line and surprisingly the FTTC was actually still in sync, logged in and passing traffic - just at low speeds.
*20:00 The wiring was repaired and the FTTC came back in to sync at the usual high rates.
===Faulty Switch on the LAN===
===Affect of adjusting the 'rate' setting===
[[File:Cqm-ratedrop.png|none|frame|Example of changing the line rate from 100%-95% reduced average latency when filling the link when downloading]]
===Running a speed test every 15 minutes===
[[File:Cqm-speedtest15mins.png|none|frame|Running an automated speed test every 15 minutes - not a fault, but the test fills the link and causes loss so will be service affecting]]
==Other Examples==
|[[File:Cqm-dropping.png]]
|Going off line is shown in purple, and this is often associated with packet loss (red). Where a line has occasional drops they are shown as purple lines. However, in some case a line can deteriorate over a period of time, staying on line less and less until solid purple (off line). On the live graphs a line that is currently off line has a red square in the bottom right corner where as a line that is on-line has a green square.
|-
|[[File:Cqm-congestion.png]]
[[File:CQM-evening-drops.png|none|200px|Evening Drops]]
===Faulty Card in a TalkTalk LTS===
[[File:Cqm-faulty-lts-card.png|none|800px|Card in a TalkTalk LTS ]]
Here we have three days of graphs, you can see packet loss starting at around 2:50AM, which then gets worse two days later and is then fixed.
This was a faulty line card in a TalkTalk LTS - Only a small number of circuits were affected with packetloss due to this though.
The time ties in with logs from TalkTalk's LTS:
<syntaxHighlight>
8 alarms currently active
Alarm time Class Description
2023-06-29 02:57:46 BST Minor FPC 9 Minor Errors
2023-06-29 02:52:29 BST Minor FPC 1 Minor Errors
2023-06-29 02:52:25 BST Minor FPC 10 Minor Errors
2023-06-29 02:52:23 BST Minor FPC 8 Minor Errors
2023-06-29 02:52:22 BST Minor FPC 11 Minor Errors
2023-06-29 02:52:22 BST Minor FPC 0 Minor Errors
2023-06-29 02:52:22 BST Minor FPC 3 Minor Errors
2023-06-29 02:52:02 BST Major FPC 10 Major Errors
</syntaxHighlight>
From 9AM on day 3, the interface that we have with TalkTalk started reporting input discards.
[[File:Discards.jpg|none|400px|Interface discards ]]
The faulty line card was taken out of service, and the packet loss was no longer.
The incident was: https://aastatus.net/42546
=Other Information=
|
edits