Consumers who use a broadband connection supplied via TalkTalk Business‘s wholesale network (not the same as their retail ISP), which is used by a wide variety of ISPs in the United Kingdom, may see an improvement in congestion and packet loss from midnight on 1st August 2017.
Most major data networks will occasionally suffer sporadic problems with traffic congestion and related packet loss, which is something that has been hitting parts of TalkTalk Business‘s Wholesale network for the past couple of months. The impact has been very mild for individual lines and so the chances are good that people connected to one of these circuits may not have even noticed the issue or attributed it to normal behaviour, especially at busy peak periods.
Nevertheless some TalkTalk using providers, such as AAISP (here), have been reporting occasional bouts of congestion and packet loss for awhile. The good news is that the operator looks to have identified the cause and a proper fix is about to be implemented.
TT Wholesale’s Service Update
The wholesale LTS platform has been suffering from packet loss and congestion over the last few months. Juniper have now advised that this is due to a limitation with the hardware we have and we need to carry out some essential vendor recommended maintenance on our DSL Interconnects platform/switch at Telehouse North in order to fix customer slow throughput.
This RFC is to rebuild ldn-vc1.thn from a mixed EX4200/EX4550 estate to a entirely EX4550 virtual switch.
We have a limitation with our EX4550’s – running in a mostly EX4200 VC (mixed mode), whereby the VC cables/modules will not support any more bandwidth past 16gbps (each way). This limitation is because we are running a mixed mode VC. We therefore need to upgrade this VC to run all EX4550s which will mean the VC cables/modules will support 32gbps and the hope is that low speed issues will be resolved.
Some connections at TT Wholesale based ISPs may drop when the work takes place, so if you have such a line then don’t be surprised to see a reconnection event in the logs.
Comments are closed