Order posts by limited to posts

Yesterday 16:00:00
Yesterday 15:55:03
We're looking in to a network issue affecting some DSL customers. You may be seeing a drop on your broadband line and/or problems with routing to parts of the internet. Staff are investigating.
Yesterday 15:58:26
Lines are reconnecting and traffic getting back to normal.
Resolution Service is back to normal.
Started Yesterday 15:45:00
Closed Yesterday 16:00:00

Sunday 17:17:03
[Broadband] - L2TP service - Info
Sunday 17:17:03
We have something of an informal L2TP service. It works as backup to broadband lines, but also as a stand alone service with IPv4 and IPv6 via L2TP with usage charging.

We plan to make changes to billing for this, moving away from a complex units system to a simple one.

The planned new package is £10/month for 100Mb/s and 1 Terabyte download allowance (after which capped to 3Mb/s).

We plan to contact existing users in due course and announce a proper start date for this as our only stand-alone L2TP service offering. Existing DSL users can use L2TP as a back-up as part of their package.

Any queries, please contact us.

Started Sunday 17:14:02

Sunday 17:07:15
22 Jan 17:49:24
We have been working on the new ordering system this month, mainly to allow people to order the new Terabyte services (new lines, and upgrades).

We are also setting up the new system to allow ordering a regrade from BT to TT back-haul, and we plan to be pushing that next month with a view to better pricing for all customers on TT back-haul in a few months if we meet some targets. More on that later.

The ordering platform is going to be made live for initial customer testing some time next week so that we can publish it as the main ordering page at the start of February. It will replace the existing Home::1, Office::1 and older units based ordering systems in the long run.

Anyone that has signed up for the trial of Terabyte services and not yet had the order placed will be contacted to try the new ordering system soon.

Thank you for your assistance on this.

Resolution Launched
Started 25 Jan
Closed Sunday 17:07:15
Previously expected 1 Feb

Sunday 17:06:58
29 Dec 2015 08:47:08
We now have details of our new terabyte services which should start to be available middle of January.

More here http://aa.net.uk/news-2016-terabyte.html

Please do not hassle sales - we'll post more details of when you can order the service once available.

12 Jan 10:16:16
We are now able to process a few orders a day semi-manually for customers. Please email trials@aa.net.uk to add yourself to the list and sales staff will get in touch.
Resolution Launched
Started 29 Dec 2015 08:43:00
Closed Sunday 17:06:58

Sunday 17:06:11
04 Dec 2015 11:28:16
Since 23/11/2015 we have been seeing Packet loss appropriately between noon to 11pm.

BT are being informed and we will update the status shortly.
Broadband Users Affected 0.17%
Started 23 Nov 2015
Closed Sunday 17:06:11

1 Feb 17:05:43
1 Feb 08:10:59
We are investigating the loss of the constant quality monitoring graphs for the last few days. Engineers are investigating.
Resolution Apologies for the inconvenience - we did find the root of the problem which has left two days of missed graph data over weekend. All fixed now.
Closed 1 Feb 17:05:43

2 Feb 19:40:50
2 Feb 15:16:10
BT have a major problem at the moment and lines which log off are unable to log back in again. Our TalkTalk services are unaffected, and lines which stay online are unaffected. This looks to be a country wide problem affecting many ISPs.
2 Feb 16:41:57
BT are aware (obviously!) and have given us notice of this outage as follows:
We are aware of an issue impacting connectivity to Broadband services and are currently investigating with technical support teams. At the moment, we are unable to inform you of your specific affected circuits and services. Once root cause is established we will issue this detail promptly.
2 Feb 16:51:49
Our XML requests are going in to BT now - and very very slowly coming back out... This may be a sign that BT will start working again... However, lines which have disconnected this afternoon have not yet logged back in.
Resolution This seems to be resolved - we'll see if BT have more detail in sue course.
Started 2 Feb 15:00:00
Closed 2 Feb 19:40:50

4 Jan 13:21:57
4 Jan 13:21:57
It seems our bank holiday system was a tad confused and has metered usage this morning for lines in Scotland as a normal day and not as a bank holiday. This has now been corrected, but it may mean units customers have been over metered for 4 hours this morning. If you think you are affected, contact us and we'll add a top-up to cover it. Sorry for any inconvenience, and Happy New Year.
Started 4 Jan 09:00:00

24 Dec 2015 14:49:51
23 Dec 2015 17:21:04
We've noticed several circuits in the South West regions are showing packet loss and severely reduced throughput. This has been reported to BT and they are investigating.
23 Dec 2015 17:32:12
Here is an example graph
23 Dec 2015 19:40:42
The poor throughput and packet loss with this same pattern has also been noted in some areas in the South
24 Dec 2015 14:57:15
The packet loss has appeared to have stopped shortly after 2255 last night.
Resolution BT have identified a core link showing this packet loss, and have swapped line cards to resolve the loss on this core link.
Started 23 Dec 2015 12:00:00
Closed 24 Dec 2015 14:49:51
Cause BT

10 Dec 2015 09:17:29
20 Apr 2015 09:54:30
Customers will have received an email from us. Apologies for not PGP signing it. It asks you to go to a secure link on our control pages and confirm (one click) that you consent to receive notices via email.

Yes, I know it is crazy, and it is already part of our terms, and you already know we email notices, and that this email is a notice we have emailed you... Sorry but OFCOM insist we get *explicit* consent to send some notices we send.

We'd appreciate it if you just click the link and then the confirm button.

We'll email you again if you don't, sorry. If you are not happy about this, please do complain to OFCOM. Thank you.

21 Apr 2015 18:23:01
We have resent the email to all of those that have not followed the link and confirmed. This time, PGP signed. Sorry for any concern the previous email caused.
21 Apr 2015 18:29:59
I'd also like to thank the *thousands* of people that have confirmed their consent so far.
Started 19 Apr 2015
Previously expected 01 Jun 2015

10 Dec 2015 08:49:48
09 Dec 2015 13:30:57
Just to let you know, I will be giving evidence to the joint committee on the Draft Investigatory Powers Bill at 17:15 today.


Adrian, Director.

Started 09 Dec 2015 17:15:00
Previously expected 09 Dec 2015 17:45:00

24 Nov 2015 18:00:00
24 Nov 2015 09:39:31
I'm sorry about this but over night our automated systems changed the balance of LNSs.

This means that this evening, once again, they will be wrong.

As such we have scheduled a ppp restart between 5pm and 6pm today to bring LNSs back to where they should be. Once again this should be a matter of a few seconds outage depending on your equipment.

What we do know is that this worked perfectly last night.

This appears to be entirely my fault as I had scheduled the rebalancing before we decided to do it manually yesterday, and did not cancel the script. I do apologise for the inconvenience.

Adrian, Director.

Started 24 Nov 2015 17:00:00
Closed 24 Nov 2015 18:00:00
Previously expected 24 Nov 2015 18:00:00

23 Nov 2015 18:17:11
23 Nov 2015 11:10:11
We have been rolling out an upgrade to routers and LNSs over the weekend, and this has resulted in an unbalanced set of traffic on LNSs. This meant some customers seeing slower speeds last night, for example.

We have decided that the best move is to rebalance lines between 5pm and 6pm before the evening traffic peak.

This should represent a PPP restart and loss of service for literally a few seconds. For some customers this would happen twice.

It also means some customers will lose their graphs for today as well.

Sorry for any inconvenience, but we believe this is the best way to ensure the best service for everyone this evening.

23 Nov 2015 18:06:27
The work has mostly gone to plan but is taking a tad longer than expected to complete the final stages.
Resolution Rebalancing complete - sorry for the slight overrun.
Started 23 Nov 2015 17:00:00
Closed 23 Nov 2015 18:17:11
Previously expected 23 Nov 2015 18:20:00

18 Nov 2015 16:38:13
18 Nov 2015 14:10:12
Some TalkTalk lines are missing their graphs and connection status from the Control Pages. Customers should still have normal internet access though. This is being looked in to and we expect a fix later today or this evening.
18 Nov 2015 16:38:36
Customers should now be able to re-login and the graphs etc will show again.
Started 18 Nov 2015 09:00:00
Closed 18 Nov 2015 16:38:13

13 Nov 2015 18:30:00
13 Nov 2015 12:31:38
Our constant quality monitoring has identified severe packet loss and latency on some TalkTalk lines connected through the South west of England and South West Wales. An incident has been raised into TalkTalk
13 Nov 2015 12:35:01
Here is an example graph
13 Nov 2015 12:49:42
TalkTalk are aware, it looks like a fibre break in the Plymouth area.
13 Nov 2015 12:53:39
TalkTalk are treating this as priority one incident. More info to follow as and when.
13 Nov 2015 16:56:08
Update from TT: "The incident is still on going and we expect it to be back up by 10pm"
13 Nov 2015 19:00:51
lines are looking back to normal as of 18:30
Started 13 Nov 2015 09:29:25
Closed 13 Nov 2015 18:30:00

09 Nov 2015 10:30:59
27 Apr 2015 14:56:58
Previously Openreach had advised that they intend to run a trial starting today on a small set of lines; where devices aren’t retransmission compatible in the upstream to see if changing certain parameters removes the latency and maintains the other benefits of retransmission. They have now advised us that the trial start date has been put back by two weeks (no idea why)

So if you have an FTTC line that is affected by this then please drop an email to support and we can include it in the list of affected lines that we will get included in the trial.

11 May 2015 11:07:12
Openreach have advised they will start loading the new DLM profiles to lines on Tuesday morning as part of regular DLM runs. Customers that are on the trial will notice a loss of sync when the new profiles are updated.
03 Jun 2015 10:36:31
Apologise for the delay in updating this post. BT have confirmed that all trial lines have been loaded with the new profiles, further to this BT have confirmed that all other affected lines have now had the new profiles loaded. That is all lines across all providers.
Started 27 Apr 2015 14:51:39

15 Oct 2015 16:50:47
15 Oct 2015 16:50:47
We are running a trial, open to everyone on a TalkTalk connected ADSL line (non-annex M at the moment), which will allow us to set the line profile to 3dB. Typically this will give a speed improvement on short lines. Email in to trials@aa.net.uk if you're interested. It's easy for us to move the line back if it is unstable, there is no cost difference.
Started 15 Oct 2015 15:03:03

13 Oct 2015 16:48:23
13 Oct 2015 15:52:41
We had a network incident starting from just after 15:30 today lasting about 15 minutes. This looks like a DDOS attack but we are still investigating.
13 Oct 2015 15:53:35
Normal service resumed at around 15:41
Started 13 Oct 2015 15:30:00
Closed 13 Oct 2015 16:48:23

22 Sep 2015 11:35:00
21 Sep 2015 13:26:39
There is some sort of routing problem affecting customers. We are still investigating
21 Sep 2015 13:35:40
Routing/traffic is back to normal, we continue to monitor...
22 Sep 2015 10:24:49
The burst of traffic that caused this disruption has not returned. We do apologise for the inconvenience this caused.
Started 21 Sep 2015 13:20:00
Closed 22 Sep 2015 11:35:00

10 Sep 2015 10:05:21
25 May 2015 22:24:55
We're seeing peak time (evening) congestion on lines at BERMONDSEY exchange again. It started on evening of 29th April. We've reported this previously, on 14 Jan and was fixed then on the 15 Jan. We'll update this post shortly.
02 Jun 2015 13:51:26
No updates as yet. We are chasing TT again today.
05 Jun 2015 09:18:13
Sadly no update, we'll chase this via alternate channels!
10 Sep 2015 10:05:34
It appears that the issue is resolved.
Started 25 May 2015 22:23:31
Closed 10 Sep 2015 10:05:21

10 Sep 2015 09:54:03
04 May 2015 21:41:59
We are are seeing congestion on HORNDEAN and WATERLOOVILLE exchanges (Hampshire). This is usually noticeable in the evenings. This will be reported to BT, and we'll update this post with updates.
10 Sep 2015 09:54:17
Congestion issues appear to be resolved at both locations.
Started 04 May 2015 21:38:34
Closed 10 Sep 2015 09:54:03

10 Sep 2015 09:53:10
19 Jun 2015 11:28:43
We are seeing around 1-2% packet loss on the MAIDA VALE Exchange. This has been reported to the TSO team within BT Wholesale.
10 Sep 2015 09:53:19
Packet loss appears to be gone
Broadband Users Affected 0.50%
Started 19 Jun 2015 11:26:46
Closed 10 Sep 2015 09:53:10
Previously expected 21 Jun 2015 13:00:00

10 Sep 2015 09:50:07
11 Aug 2015 11:35:34
We have noticed congestion one some of our TalkTalk circuits. customers affected are seeing an increase of latency and some packet loss. We have reported this to TalkTalk and as soon as we have an update we will update this post.
11 Aug 2015 11:42:09
Here is an example graph
11 Aug 2015 14:49:09
Update from TT We lost multiple 10G circuits to our transmission network due to a BT fibre break in the Ipswich area - Openreach have applied for a MBORC on the issue. There was congestion in the Ipswich and Cambridgeshire wider area as a result which was resolved shortly after midnight.
Started 10 Aug 2015 17:32:43
Closed 10 Sep 2015 09:50:07

10 Sep 2015 09:49:30
14 Aug 2015 11:50:09
We have been seeing increased packet loss and latency on certain line on the Forest hill exchange. It appears one VLAN is currently running hot. BT are aware and are investigating.
18 Aug 2015 10:31:33
BT believe the SVLAN has been upgraded. We will monitor the circuits tonight.
10 Sep 2015 09:49:48
Issues appear to be resolved.
Started 14 Aug 2015 11:46:37 by AA Staff
Closed 10 Sep 2015 09:49:30
Previously expected 17 Aug 2015 09:00:00

26 Aug 2015 23:30:00
26 Aug 2015 00:16:15
We've seen a couple of incidents this evening where customers have seen packet loss and some DSL sessions have blipped. It seems to have been caused by a traffic flood, and we're investigating the cause. This status is posted as Minor as things look OK at the moment.
26 Aug 2015 20:33:37
We've had another set of blips affecting internet access for some customers this evening (20:15ish). We are looking in to the cause of this.
26 Aug 2015 21:07:47
This is problem is continuing to cause disruption, please bear with us as we work to get to the bottom of this.
26 Aug 2015 21:37:02
Traffic is has been normal for the past 30 mins or so, we've not yet tracked down the cause and are still looking on to this.
26 Aug 2015 22:37:34
We believe we have found the cause of the network issues. More details to follow in the morning.
26 Aug 2015 23:05:49
Unfortunately we are still having problems, we're still working on this.
26 Aug 2015 23:33:38
We've done further work on this, traffic is back to normal at the moment and we are monitoring the situation.
Resolution The intermittent problems on the evenings of 25th and 26th were caused by a distributed denial of service attack against one of our customers. This type of attack does happen from time to time and we have systems which usually stop an attack in its tracks very quickly. However, in this case the attack was not automatically blocked. Due to the nature of the attack it did take longer than we would have liked to pin point the target of the attack, and this was eventually done at around 23:30 on the 26th. Moving on, we will be looking in to why this was not automatically blocked and how we can improve other systems with a view to prevent this from being a problem in the future. We do apologise for the inconvenience this caused.
Closed 26 Aug 2015 23:30:00

27 Jul 2015 10:36:06
16 Jun 2015 11:32:55
As some of you may know, the new system for migrations of broadband lines comes in this weekend. See http://aa.net.uk/news-20150601-not.html

We expect to enable the new notice emails during this week, maybe even today. These will be sent for customers migrating away from us, and migrating to us (when order commits) and include the options for cancelling the migration.

We are also taking this opportunity to include notices for services ceasing - either because you have requested a cease, or unsolicited (e.g. if ceasing phone line causes cease of broadband).

In any case, if leaving us, the notice details any early termination charges.

If any issues, concerns, or questions, please let us know.

16 Jun 2015 18:24:44
We are now sending NoT emails. Please let us know any issues.
Started 16 Jun 2015
Previously expected 20 Jun 2015

09 Jul 2015 17:15:00
09 Jul 2015 16:35:04
We are reloading one of our route reflectors - this should have little of no impact as routing should automatically fall over to the other.

If this does not resolve the issues we may have to do more work.

Started 09 Jul 2015 17:00:00
Closed 09 Jul 2015 17:15:00
Previously expected 09 Jul 2015 17:10:00

01 Jul 2015 04:34:32
01 Jul 2015 03:11:16
From 2:18 today, we are seeing packet loss and some lines dropping their connection.
Resolution We've identified the caused of this, and traffic is back to normal.
Started 01 Jul 2015 02:18:00
Closed 01 Jul 2015 04:34:32

24 Jun 2015 16:27:39
24 Jun 2015 16:27:39
When Home::1 reaches quota you can opt to have the service stop, slow down, or auto top-up.

Slow mode was around 250kb/s. However, we have changed this so that the speed depends on the tariff. For 100GB users the slow mode will now be around 330kb/s and for 200GB users it will be around 660kb/s. The idea is that at that speed you could not use the whole of the coming month's quote even flat out.

Started 24 Jun 2015 16:25:00

19 Jun 2015 16:28:46
31 May 2015 15:28:31
With the up-coming changes to broadband migrations and the abolishing of Migration Authorisation Codes (MACs), AAISP has launched a new "anti-slamming" service to allow customers to "lock" their line against unwanted migrations to another provider.

This extra service, which is completely free, works on much the same principle as "domain locking" where domains can be locked against migration.

The process is simple and allows each line to be locked against migrations for broadband or the underlying copper pair "phone line" part of the service. It is just a "standing order" from the customer to AAISP to reject all migrations. From the 20th, any migration request that then comes in is automatically rejected if anti-slamming is enabled. An email is sent to advise the customer of what happened, including a simple link to turn off the anti-slamming if they do wish to migrate after all.

The anti-slamming service has been provided by popular demand after many customers expressed concerns that their lines could be "slammed" (maliciously taken over by other telcos) or that mistakes could lead to unwanted migrations, and it would be very easy to miss the notice of transfer that is sent before the migration goes ahead. OFCOM do not seem to have created any "fast correct" of mistakes, so an unwanted migration could mean waiting another 10 working days to fix the situation.

Slamming is just one of the many concerns over the new migration process. There may still be ways LLU providers can take over lines, as can happen now without a MAC, but this new service should avoid mistakes and give customers peace of mind.

The control pages for the line include a simple link to enable or disable the anti-slamming service.

Started 31 May 2015 15:27:25
Previously expected 20 Jun 2015

19 Jun 2015 16:28:30
14 May 2015 15:42:00

We are please to inform customers that we are changing the entry-level router that we supply to our customers. From next week we'll be shipping the ZyXEL VMG1312 by default instead of the Technicolor.

Since around 2012 we have been providing the Technicolor TG852, which was the first consumer level router to support IPv6. With the advent of wires-only FTTC and the need for a more flexible and easy to use router we have been looking for a replacement. The ZyXEL VMG1312 is able to do ADSL, FTTC and PPPoE and is flexible enough to be used on most of our lines. We have been working with ZyXEL over the past few months to iron out bugs that we have found. There are still some bugs to be fixed and these are detailed on our Support site. The biggest bug is the lack of 1500 byte MTU when running in bridge mode, however, ZyXEL expect to have this fixed soon and in the meantime FTTC installations will be installed with the Openreach modem.

More information about the router: https://support.aa.net.uk/Category:ZyXEL_VMG1312

Started 14 May 2015 13:12:00

19 Jun 2015 16:27:57
19 Jun 2015 16:27:57
You no longer need to obtain a Migration Authorisation Code to migrate broadband. Simple contact the new provider with your details to arrange the migration.

If you wish to migrate to us, please complete the order, and you will not be asked for a MAC.

If you wish to migrate away, simply contact the new provider (from tomorrow) and they can arrange the migration.

The lead time has increased from 5 working days to 10 - a significant added delay for which you can thank OFCOM.

Started 19 Jun 2015 16:25:59
Previously expected 20 Jun 2015

18 Jun 2015 15:00:00
[Broadband] - BT Blip - Closed
18 Jun 2015 14:50:08
A number of BT lines dropped out at about 14:44, this appears to be an issue on the BT side, all lines have now recovered. We are chasing Bt for an explanation.
18 Jun 2015 15:03:46
Some lines are still blipping, we are investigating further.
Resolution The blip seems to have gone away - we may move some lines that ended up on the wrong LNS back later. This is not the first time this link to BT had blipped and we are chasing with BT.
Started 18 Jun 2015 14:47:59
Closed 18 Jun 2015 15:00:00

16 Jun 2015 18:25:11
13 Feb 2015 14:29:06
We currently supply the Technicolor TG582 for most ADSL services, but we are considering switching to a new router, the ZyXEL VMG1312-B

It is very comprehensive and does both ADSL and VDSL as well as bridging and wifi. It means we can have one router for all service types. As some of you may know, BT will be changing FTTC to be "wires only" next year, and so a VDSL router will be needed.

We have a small number available now for people to trial - we want to test the routers, our "standard config" and the provisioning process.

Please contact trial@aa.net.uk or #trial on the irc server for more information.

P.S. Obviously it does Internet Protocol, the current one, IPv6 and the old one IPv4

Obviously this initial trial is limited number of routers which we are sending out at no charge to try different scenarios. However, we expect to be shipping these as standard later in the month, and they will be available to purchase on the web site.

13 Feb 2015 15:49:08
Thanks for all the emails and IRC messages about trialling the new routers. We will contact customers back on Monday to arrange shipping of the units.
16 Feb 2015 10:43:54
We now have enough trialists for the new router, we will contact a selection of customers today to arrange delivery of the routers. Thanks
Started 13 Feb 2015 14:25:34

16 Jun 2015 18:24:58
03 Jun 2015 11:30:45

We are now processing FTTC orders as 'wires only'. This means:

  • An Openreach engineer appointment is not required if the phone line already exists
  • Openreach will not provide a modem.
This makes the installation easier to arrange as no onsite appointment is required. There are a number of FTTC (VDSL) modems and routers available on the market, we are providing the ZyXEL VMG1312 router which can act as an all-in-one modem/router or just as a modem in a similar fashion to the original Openreach modem.

Do contact us for more information

Started 03 Jun 2015 11:00:00

10 Jun 2015 02:21:49
10 Jun 2015 10:26:47
It seems that one of our BT links had an issue over night. It was only one of the four links we have and only BT services that were affected. Lines reconnected. If you have not reconnected, try power cycling your router. We don't have any explanation from BT as yet.
Started 10 Jun 2015 02:03:19
Closed 10 Jun 2015 02:21:49

01 Jun 2015 23:30:51
01 Jun 2015 23:11:35
We're seeing odd routing blips across our network. We're investigating.
01 Jun 2015 23:31:30
Traffic is back to normal. We'll investigate this further and will update this post in the morning.
Resolution This looked like it was some sort of DOS that affected our routing, possibly other ISPs too.
Started 01 Jun 2015 22:55:00
Closed 01 Jun 2015 23:30:51

12 May 2015 10:27:29
05 May 2015 10:21:17
BT have had trouble with this exchange (http://aastatus.net/2052) but we are now seeing evening congestion on TalkTalk connected lines. We have reported this and will update this post accordingly.
05 May 2015 12:38:47
TalkTalk have fixed a misconfiguration at their end. This should now be resolved. We'll check again tomorrow.
07 May 2015 08:55:48
Lines still seem to be congested, this is being looked in to by TalkTalk.
13 May 2015 12:13:36
Update from TT 'This should now properly be resolved. A faulty interface meant that we were running at 2/3 of capacity - only a few of your subscribers would have suffered last night hopefully but should now all be good.'
Started 05 May 2015 10:00:00
Closed 12 May 2015 10:27:29

02 Jun 2015 11:18:33
02 Jun 2015 11:15:34
At 11:07 one of our links to BT blipped - this caused a number of BT DSL lines to drop. Lines are reconnecting at the moment.
02 Jun 2015 11:18:56
Most lines are now back online.
Started 02 Jun 2015 11:07:00
Closed 02 Jun 2015 11:18:33

27 May 2015 14:48:58
27 May 2015 10:37:50
One of our routers is misbehaving - the one we planned to reload shortly as it happens, and this seems to be impacting mobile data SIMs.
27 May 2015 10:46:58
This appears to be a LINX issue
27 May 2015 10:53:20
We have managed to shut down the port to LINX while this is resolved.
27 May 2015 11:01:41
This looks to be impacting lots of ISPs, but traffic will go via alternative peering and transit whilst LINX have issues and so this should have minimal impact on customers at present.
27 May 2015 12:09:13
LINX are clearly having some major issues on one of the LANs, and we remain disconnected until this is resolved. Once it is resolved, we may reload one of our routers so as to add more logging and allow us to more carefully monitor further issues.
27 May 2015 14:39:14
LINX have rectified the issue, so we will be re-enabling LINX ports shortly.
Resolution All working now.
Started 27 May 2015 10:30:00
Closed 27 May 2015 14:48:58

27 May 2015 10:53:48
27 May 2015 10:12:22
We have been encountering issues with LINX which result in some routes being "Black-holed" (i.e. going nowhere).

The system normally handles this without any problem, identifying an infeasible route and removing from the routing table to allow alternative routes a chance. However we have identified an edge case where this does not happen.

We plan to do a router upgrade today, as this issue is causing customers problems at present. This is one router and should be pretty seamless in that routing should go via other routers whilst it happens.

However, there is a small risk of some routing blips during the process.

Resolution Upgrade completed
Started 27 May 2015 10:00:00
Closed 27 May 2015 10:53:48
Previously expected 27 May 2015 17:00:00

25 May 2015 21:30:00
25 May 2015 21:45:20
From around 6:30pm there was IPv6 routing problems to some hosts via our Linx peering - notably to Google.
Resolution A temporary workaround was applied at 9:30pm and routing has been restored. Staff were alerted to this via customers using the 'MSO' SMS facility, however, do to individual staff circumstances it was not until 9pm that staff were able to respond. We do apologise for the time this took, it is very rare for all the staff that are alerted in this way to all be unavailable at the same time. We'll consider what can be done to improve this.
Started 25 May 2015 18:30:00
Closed 25 May 2015 21:30:00

13 May 2015 12:16:45
26 Mar 2015 09:53:31

Over the past couple of weeks we have seen FTTC lines drop and reconnect with in increase in latency of around 15ms. This is seen on the monitoring graphs as a thicker blue line.

Upon first glance it looks as if interleaving has been enabled, but a line test shows that this is not the case.

We've been in contact with BT and it does look like BT are rolling out a new profile on to their Huawei DSLAMs in the local green cabinets. It has been expected that BT would be rolling out this new profile, but we didn't expect such an increase in latency.

The profile adds 'Physical Retransmission (ReTX) technology (G.INP / ITU G.998.4)' which helps with spikes of electromagnetic interference and can make lines more stable.

We would hope to have control over the enabling and disabling of this profile, but we don't. Line profiles with FTTC is managed by BT Openreach and are tricky for us and even BT Wholesale to get adjusted.

We're still discussing this with BT and will update this post with news as we have it.

26 Mar 2015 09:55:29
26 Mar 2015 10:48:37
This has been escalated to the head of fibre deployment within BT Wholesale and we are expecting an update by the end of the day.
26 Mar 2015 11:12:08
Further information about G.INP:
  • http://www.ispreview.co.uk/index.php/2015/01/bt-enables-physical-retransmission-g-inp-fttc-broadband-lines.html
  • http://www.thinkbroadband.com/news/6789-impulse-noise-protection-rolling-out-on-openreach-vdsl2.html
  • http://forum.kitz.co.uk/index.php?topic=15099.0
...among others.
27 Mar 2015 16:46:22
BT have asked us for further information which we have provided to them, we don't expect an update now until Monday
09 Apr 2015 14:26:19
This is still ongoing with BT Wholesale and BT Openreach.
16 Apr 2015 15:58:53
This has been escalated to a very senior level within BT and we are expecting a proper update in the next few days.
24 Apr 2015 13:01:45
We have just received the below back from BT on this

Following communications from a small number of BTWholesale FTTC comms providers regarding Openreach’s implementation of Retransmission and the identification of some your customers who have seen increased latency on some lines for some applications since retransmission was applied. Over the last 4 weeks I have been pushing Openreach to investigate,

feedback and provide answers and options related to this issue. As a result attached is a copy of a briefing from Openreach; sent to their CPs today, on how RetX works and what may have caused this increase latency.

This info is being briefed to all BTWholesale customers via our briefing on Saturday morning 25/4/15 but as you have contacted me direct I’m sending this direct as well as providing ann opportunity to participate in a trial.

Openreach have also advise me this afternoon that they intend to run a trial next week (w/c 25/4/15) on a small set of lines; where devices aren’t retransmission compatible in the upstream to see if changing certain parameters removes the latency and maintains the other benefits of retransmission. The exact date lines will be trialled has yet to be confirmed.

However, they have asked if I have any end users who would like to be included in this trail. To that end if you have particular lines you’d like to participate in this trial please can you provide the DN for the service by 17:00 on Monday 28th April so I can get them included.

This is a trial of a solution and should improve latency performance but there is a risk that there may be changes to the headline rate.

05 May 2015 22:28:25
Update to Trial here: https://aastatus.net/2127
Started 26 Mar 2015 09:00:00
Closed 13 May 2015 12:16:45

12 May 2015 13:41:47
11 May 2015 18:07:36
We have changed the way we apply minimum terms.

Instead of charging for all of the service to the end of the minimum term, we now charge an early termination fee for the period from the cease/migrate to the end of the term. This is a simple fee based on the tariff and line type. We are also scrapping the 30 day notice requirement.

Whilst the old system was simple, it did not fit OFCOM rules for the new migration system. We think the new system is equally simple, and saves customers money. As such the change has been introduced today.

More details here http://aa.net.uk/news-20150511-minterm.html

Started 11 May 2015 18:00:00

09 May 2015 14:31:50
05 May 2015 22:22:42

TalkTalk is performing essential maintenance on its internal infrastructure. This work will happen in the early hours of the 8th May 2015. This work will mean that services may be lost for up to 1 hour between midnight and 6am. This is likely to affect the following exchanges:

  • Yatton
  • Didcot
  • Cheltenham
  • Swindon
  • Blunsdon
  • Cirencester
  • BOX
  • Chippenham
  • Clevedon
  • PILL
  • Brimscombe
  • Dursley
  • Calne
  • Devizes
  • Melksham
  • Worle
  • Weston Super Mare
  • Downend
  • Midsomer Norton
  • Radstock
  • West
  • Frome
  • Trowbridge
  • Westbury
  • Portishead
  • Kingswood
  • Kingsmead
  • Bristol North
  • South
  • Glastonbury
  • Wells
We apologise for any inconvenience that these works may cause you
Started 08 May 2015 by TalkTalk
Closed 09 May 2015 14:31:50

23 Apr 2014 10:21:03
01 Nov 2013 15:05:00
We have identified an issue that appears to be affecting some customers with FTTC modems. The issue is stupidly complex, and we are still trying to pin down the exact details. The symptoms appear to be that some packets are not passing correctly, some of the time.

Unfortunately one of the types of packet that refuses to pass correctly are FireBrick FB105 tunnel packets. This means customers relying on FB105 tunnels over FTTC are seeing issues.

The work around is to remove the ethernet lead to the modem and then reconnect it. This seems to fix the issue, at least until the next PPP restart. If you have remote access to a FireBrick, e.g. via WAN IP, and need to do this you can change the Ethernet port settings to force it to re-negotiate, and this has the same effect - this only works if directly connected to the FTTC modem as the fix does need the modem Ethernet to restart.

We are asking BT about this, and we are currently assuming this is a firmware issue on the BT FTTC modems.

We have confirmed that modems re-flashed with non-BT firmware do not have the same problem, though we don't usually recommend doing this as it is a BT modem and part of the service.

04 Nov 2013 16:52:49
We have been working on getting more specific information regarding this, we hope to post an update tomorrow.
05 Nov 2013 09:34:14
We have reproduced this problem by sending UDP packets using 'Scapy'. We are doing further testing today, and hope to write up a more detailed report about what we are seeing and what we have tested.
05 Nov 2013 14:27:26
We have some quite good demonstrations of the problem now, and it looks like it will mess up most VPNs based on UDP. We can show how a whole range of UDP ports can be blacklisted by the modem somehow on the next PPP restart. It is crazy. We hope to post a little video of our testing shortly.
05 Nov 2013 15:08:16
Here is an update/overview of the situation. (from http://revk.www.me.uk/2013/11/bt-huawei-fttc-modem-bug-breaking-vpns.html )

We have confirmed that the latest code in the BT FTTC modems appears to have a serious bug that is affecting almost anyone running any sort of VPN over FTTC.

Existing modems seem to be upgrading, presumably due to a roll out of new code in BT. An older modem that has not been on-line a while is fine. A re-flashed modem with non-BT firmware is fine. A working modem on the line for a while suddenly stopped working, presumably upgraded.

The bug appears to be that the modem manages to "blacklist" some UDP packets after a PPP restart.

If we send a number of UDP packets, using various UDP ports, then cause PPP to drop and reconnect, we then find that around 254 combinations of UDP IP/ports are now blacklisted. I.e. they no longer get sent on the line. Other packets are fine.

Sending 500 different packets, around 254 of them will not work again after the PPP restart. It is not actually the first or last 254 packets, some in the middle, but it seems to be 254 combinations. They work as much as you like before the PPP restart, and then never work after it.

We can send a batch of packets, wait 5 minutes, PPP restart, and still find that packets are now blacklisted. We have tried a wide range of ports, high and low, different src and dst ports, and so on - they are all affected.

The only way to "fix" it, is to disconnect the Ethernet port on the modem and reconnect. This does not even have to be long enough to drop PPP. Then it is fine until the next PPP restart. And yes, we have been running a load of scripts to systematically test this and reproduce the fault.

The problem is that a lot of VPNs use UDP and use the same set of ports for all of the packets, so if that combination is blacklisted by the modem the VPN stops after a PPP restart. The only way to fix it is manual intervention.

The modem is meant to be an Ethernet bridge. It should not know anything about PPP restarting or UDP packets and ports. It makes no sense that it would do this. We have tested swapping working and broken modems back and forth. We have tested with a variety of different equipment doing PPPoE and IP behind the modem.

BT are working on this, but it is a serious concern that this is being rolled out.
12 Nov 2013 10:20:18
Work on this in still ongoing... We have tested this on a standard BT retail FTTC 'Infinity' line, and the problem cannot be reproduced. We suspect this is because when the PPP re-establishes a different IP address is allocated each time, and whatever is session tracking does not match the new connection.
12 Nov 2013 11:08:17

Here is an update with some a more specific explanation as to what the problem we are seeing is:

On WBC FTTC, we can send a UDP packet inside the PPP and then drop the PPP a few seconds later. After the PPP re-establishes, UDP packets with the same source and destination IP and ports won't pass; they do not reach the LNS at the ISP.

Further to that, it's not just one src+dst IP and port tuple which is affected. We can send 254 UDP packets using different src+dest ports before we drop the PPP. After it comes back up, all 254 port combinations will fail. It is worth noting here that this cannot be reproduced on an FTTC service which allocates a dynamic IP which changes each time PPP re-established.

If we send more than 254 packets, only 254 will be broken and the others will work. It's not always the first 254 or last 254, the broken ones move around between tests.

So it sounds like the modem (or, less likely, something in the cab or exchange) is creating state table entries for packets it is passing which tie them to a particular PPP session, and then failing to flush the table when the PPP goes down.

This is a little crazy in the first place. It's a modem. It shouldn't even be aware that it's passing PPPoE frames, let along looking inside them to see that they are UDP.

This only happens when using an Openreach Huawei HG612 modem that we suspect has been recently remotely and automatically upgraded by Openreach in the past couple of months. Further - a HG612 modem with the 'unlocked' firmware does not have this problem. A HG612 modem that has probably not been automatically/remotely upgraded does not have this problem.

Side note: One theory is that the brokenness is actually happening in the street cab and not the modem. And that the new firmware in the modem which is triggering it has enabled 'link-state forwarding' on the modem's Ethernet interface.

27 Nov 2013 10:09:42
This post has been a little quiet, but we are still working with BT/Openreach regarding this issue. We hope to have some more information to post in the next day or two.
27 Nov 2013 10:10:13
We have also had reports from someone outside of AAISP reproducing this problem.
27 Nov 2013 14:19:19
We have spent the morning with some nice chaps from Openreach and Huawei. We have demonstrated the problem and they were able to do traffic captures at various points on their side. Huawei HQ can now reproduce the problem and will investigate the problem further.
28 Nov 2013 10:39:36
Adrian has posted about this on his blog: http://revk.www.me.uk/2013/11/bt-huawei-working-with-us.html
13 Jan 2014 14:09:08
We are still chasing this with BT.
03 Apr 2014 15:47:59
We have seen this affect SIP registrations (which use 5060 as the source and target)... Customers can contact us and we'll arrange a modem swap.
23 Apr 2014 10:21:03
BT are in the process of testing an updated firmware for the modems with customers. Any customers affected by this can contact us and we can arrange a new modem to be sent out.
07 May 2015 22:56:52
Just a side note on this, we're seeing the same problem on the ZyXEL VMG1312 router which we are teting out and which uses the same chipset: info and updates here: https://support.aa.net.uk/VMG1312-Trial
Resolution BT are testing a fix in the lab and will deploy in due course, but this could take months. However, if any customers are adversely affected by this bug, please let us know and we can arrange for BT to send a replacement ECI modem instead of the Huawei modem. Thank you all for your patience.

BT do have a new firmware that they are rolling out to the modems. So far it does seem to have fixed the fault and we have not heard of any other issues as of yet. If you do still have the issue, please reboot your modem, if the problem remains, please contact support@aa.net.uk and we will try and get the firmware rolled out to you.
Started 25 Oct 2013
Closed 23 Apr 2014 10:21:03

07 May 2015 09:53:49
09 Dec 2014 11:20:04
Some lines on the LOWER HOLLOWAY exchange are experiencing peak time packet loss. We have reported this to BT and they are investigating the issue.
11 Dec 2014 10:46:42
BT have passed this to TSO for investigation. We are waiting for a further update.
12 Dec 2014 14:23:56
BT's Tso are currently investigating the issue.
16 Dec 2014 12:07:31
Other ISPs are seeing the same problem. The BT Capacity team are now looking in to this.
17 Dec 2014 16:21:04
No update to report yet, we're still chasing BT...
18 Dec 2014 11:09:46
The latest update from this morning is: "The BT capacity team have investigated and confirmed that the port is not being over utilized, tech services have been engaged and are currently investigating from their side."
19 Dec 2014 15:47:47
BT are looking to move our affected circuits on to other ports.
13 Jan 2015 10:28:52
This is being escalated further with BT now, update to follow
19 Jan 2015 12:04:34
This has been raised as a new reference as the old one was closed. Update due by tomorrow AM
20 Jan 2015 12:07:53
BT will be checking this further this evening so we should have more of an update by tomorrow morning
22 Jan 2015 09:44:47
An update is due by the end of the day
22 Jan 2015 16:02:24
This has been escalated further with BT, update probably tomorrow now
23 Jan 2015 09:31:23
we are still waiting for a PEW to be relayed to us. BT will be chasing this for us later on in the day.
26 Jan 2015 09:46:03
BT are doing a 'test move' this evening where they will be moving a line onto another VLAN to see if that helps with the load, if that works then they will move the other affected lines onto this VLAN. Probably Wednesday night.
26 Jan 2015 10:37:45
there will be an SVLAN migration to resolve this issue on Wednesday 28th Jan.
30 Jan 2015 09:33:57
Network rearrangement is happening on Sunday so we will check again on Monday
02 Feb 2015 14:23:12
Network rearrangement was done at 2AM this morning, we will check for paclet loss and report back tomorrow.
03 Feb 2015 09:46:49
We are still seeing loss on a few lines - I am not at all happy that BT have not yet resolved this. A further escalation has been raised with BT and an update will follow shortly.
04 Feb 2015 10:39:03
Escalated futher with an update due at lunch time
11 Feb 2015 14:14:58
We are getting extremly irritated with BT on this one, it should not take this long to add extra capaity in the affected area. Rocket on it's way to them now ......
24 Feb 2015 12:59:54
escalated further with BT, update due by the end of the day.
02 Mar 2015 09:57:59
We only have a few customers left showing peak time packet loss and for now the fix will be to move them onto another MSAN, I am hoping this will be done in the next few days. We really have been pushing BT hard on this and other areas where we are seeing congestion. I am please that there are now only a handful of affected customers left.
17 Mar 2015 11:21:33
We have just put a boot up BT on this, update to follow.
02 Apr 2015 13:16:10
BT have still not fixed the fault so we have moved some of the affected circuits over to TalkTalk and I am pleased to say that we are not seieng loss on those lines. 100% this is a BT issue and I am struggling to understand why they have still not tracked the fault down.
Closed 07 May 2015 09:53:49
Previously expected 01 Feb 2015 09:34:04 (Last Estimated Resolution Time from AAISP)

07 May 2015 09:52:18
11 Mar 2015 11:39:17
We are seeing some evening time congestion on all BT 21CN lines that connect through BRAS's 21CN-BRAS-RED1-MR-DH up to 21CN-BRAS-RED13-MR-DH I suspect one of the BT nodes is hitting limits some evenings as we don't see the higher latency every night. This has been reported into BT and we will update this past as soon as they respond back.
11 Mar 2015 11:44:06
Here is an example graph
12 Mar 2015 12:00:45
This has been escalated further to the BT networK guys and we can expect an update within the next few hours.
17 Mar 2015 15:41:18
Work was done on this overnight so I will check again tomorrow morming and post another update.
18 Mar 2015 11:38:25
The changes BT made over night have made a significant difference to the latency, still seeing it slightly higher than we would like so we will go back to then again.
19 Mar 2015 14:54:44
Unfortunately the latency has increased again so whatever BT did two nights ago has not really helped. We are chasing again now.
23 Mar 2015 14:07:53
BT have still not pinpointed the issue so it has been escalated further.
27 Mar 2015 13:03:38
Latency is hardly noticeable now but we are still chasing BT on sorting the actual issue, update will be mOnday now.
30 Mar 2015 10:04:14
BT have advised that they are aware of the congestion issue at Manchester, and the solution they have in place is to install some additional edge routers, they are already escalating on this to bring the date in early, currently the date is May. Obviously May is just not acceptable and we are doing all we can to get BT to bring this date forward.
02 Apr 2015 12:28:39
We have requested a further escalation within BT, the time scales they have given for a fix is just not acceptable.
13 Apr 2015 15:12:23
The last update from BT was 'is latency issue has been escalated to high level. BT TSO are currently working on a resolution and are hoping to move into the testing phase soon. We will keep you updated as we get more information' I am chasing for another update now.
16 Apr 2015 16:01:15
We are still chasing BT up on bringing the 'fix' forward. Hopefully we will have another response by the morning.
21 Apr 2015 13:25:21
The latest update from BT: We have identified a solution to the capacity issue identified and are looking to put in a solution this Friday night...
24 Apr 2015 15:25:51
BT have added more capacity on tehir network and last night the latency looked fine. We will review this again on Monday.
Started 11 Mar 2015 01:35:37
Closed 07 May 2015 09:52:18

29 Apr 2015 15:23:27
29 Apr 2015 14:43:36
A third of our BT lines bliped - this looks to be an issue with routing on one of our LNSs in to BT.
29 Apr 2015 14:50:18
Many lines are failing to reconnect properly, we are investigating this.
29 Apr 2015 14:57:42
Lines are connecting successfully now
29 Apr 2015 15:23:27
The bulk of lines are back onlne. There are a small number of lines that are still failing to reconnect. These are being looked in to.
29 Apr 2015 15:36:54
The remain lines are reconnecting successfully now.
Resolution I wanted to try and explain more about what happened today, but it is kind of tricky without saying "Something crazy in the routing to/from BT".

We did, in fact make a change - something was not working with our test LNS and a customer needed to connect. We spotted that, for some unknown reason, the routing used a static route internally instead of one announced by BGP, for just one of the four LNSs, and that on top of that the static route was wrong, hence the test LNS not working via that LNS. It made no sense, and as all three other LNSs were configured sensibly we changed the "A" LNS to be the same, after all, this is clearly a config that just worked and was no problem, or so it seemed.

Things went flappy, but we could not see why. It looks like BGP in to BT was flapping, so people connected and disconnected rather a lot. We returned the config and things seemed to be fixed for most people, but not quite all. This made no sense. Some people are connecting and going on line, and then falling off line.

The "fix" to that was to change the endpoint LNS IP address used by BT to an alias on the same LNS. We have done this in the past where BT have had a faulty link in a LAG. We wonder if this issue was "lurking" and the problem we created showed it up. This shows that there was definitely an issue in BT somehow as the fix should not have made any difference otherwise.

What is extra special is that this looks like it has happened before - the logs suggest the bodge of a static route was set up in 2008, and I have this vague recollection of a mystery flappiness like this which was never solved.

Obviously I do apologise for this, and having corrected the out of data static route this should not need touching again, but damn strange.

Started 29 Apr 2015 14:38:00
Closed 29 Apr 2015 15:23:27
Previously expected 29 Apr 2015 14:50:00

25 Apr 2015 18:46:00
25 Apr 2015 18:48:19
There was an unexpected blip in routing - we are looking in to it.
Started 25 Apr 2015 18:44:00
Closed 25 Apr 2015 18:46:00
Previously expected 25 Apr 2015 22:46:00