Order posts by limited to posts

19 Jun 11:30:03
Details
19 Jun 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.
Broadband Users Affected 0.50%
Started 19 Jun 11:26:46
Update was expected 21 Jun 13:00:00
Previously expected 21 Jun 13:00:00

12 Jun 11:06:49
Details
12 Jun 11:00:23
Our office connectivity blipped. We have internet again, but our phones are down. We're investigating. This is not customer affecting.
Update
12 Jun 11:06:49
Phones are working again.
Previously expected 12 Jun 14:57:07

2 Jun 13:51:26
Details
25 May 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.
Update
2 Jun 13:51:26
No updates as yet. We are chasing TT again today.
Update
5 Jun 09:18:13
Sadly no update, we'll chase this via alternate channels!
Started 25 May 22:23:31

26 May 17:55:57
Details
26 May 17:55:57
We have had some issues with printing of SIM cards of late. We have two printers but they are struggling with the card material, and this making the print quality somewhat poorer than we would expect.

In light of this, we will be happy to try and print cards as requested, even if it takes us a few attempts, but we are also prepared to offer the cards at a discount if the print quality is not up to scratch. If you order cards, please feel free to pick artwork or load your own as usual, but staff may contact you if there are issues and offer them at a discount.

We are looking in to a new make of card printer which should address this, but we are being careful to evaluate the printer before we go ahead, so it may be a few more weeks.

Sorry for any inconvenience or disappointment this may cause.

Started 1 May

4 May 21:52:34
Details
4 May 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.
Started 4 May 21:38:34

13 Apr
Details
9 Apr 13:43:39

We have been advised by Three of works on their network which will involve rerouting traffic from one of their nodes via alternate paths in their core. Although connections should automatically reroute, there will be brief amounts of packet loss. As a result, some customers may experience dropped connections. Any device reconnecting will automatically be routed via a new path.

This only affects our data only SIMs.

Started 13 Apr

12 Mar 09:48:01
Details
12 Mar 09:48:01
Our wiki at http://wiki.aa.org.uk/ will be down for a while today due to an internal PEW. Sorry for any inconvenience.

19 Jan 16:08:37
Details
17 Jul 2014 10:08:44
Our email services can learn spam/non-spam messages. This feature is currently down for maintenance as we work on the back-end systems. This means that if you move email in to the various 'learn' folders they will stay there and will not be processed at the moment. For the moment, we advise customers not to use this feature. Will will post updates in the next week or so as we may well be changing how this feature works. This should not affect any spam scores etc, but do contact support if needed.
Update
29 Jul 2014 11:42:12
This project is still ongoing. This should not be causing too many problems though, as the spam checking system has many many other ways to determine if a message is spam or not. However, for now, if customers have email that is miss-classified by the spam checking system then please email the headers in to support and we can make some suggestions.
Update
19 Jan 16:08:37
We are working on rebuilding the spam learning system. We expect to make this live in the next couple of weeks.
Started 17 Jul 2014 10:00:00
Update was expected 29 Jan 13:00:00

8 Jan 12:39:06
Details
8 Jan 12:49:24
We're going to remove the legacy fb6000.cgi page that was originally used to display CQM graphs on the control pages. This does not affect people who use the control pages as normal, but we've noticed that fb6000.cgi URLs are still being accessed occasionally. This is probably because the old page is being used to embed graphs into people's intranet sites, for example, but accessing graph URLs via fb6000.cgi has been deprecated for a long time. The supported method for obtaining graphs via automated means is via the "info" command on our API: http://aa.net.uk/support-chaos.html This is likely to affect only a handful of customers but, if you believe you're affected and require help with accessing the API, please contact support. We will remove the old page after a week (on 2015-01-15).
Update
9 Jan 08:52:28
We'll be coming up with some working examples of using our CHAOS API to get graphs, we'll post an update here today or monday.
Update
12 Jan 16:19:58
We have an example here: https://wiki.aa.net.uk/CHAOS
Started 8 Jan 12:39:06 by AA Staff
Previously expected 15 Jan 17:00:00

03 Jun 2014 17:00:00
Details
03 Jun 2014 18:20:39
The router upgrades went well, and now there is a new factory release we'll be doing some rolling upgrades over the next few days. Should be minimal disruption.
Update
03 Jun 2014 18:47:21
First batch of updates done.
Started 03 Jun 2014 17:00:00
Previously expected 07 Jun 2014

14 Apr 2014
Details
13 Apr 2014 17:29:53
We handle SMS, both outgoing from customers, and incoming via various carriers, and we are now linking in once again to SMS with mobile voice SIM cards. The original code for this is getting a tad worn out, so we are working on a new system. It will have ingress gateways for the various ways SMS can arrive at us, core SMS routing, and then output gateways for the ways we can send on SMS. The plan is to convert all SMS to/from standard GSM 03.40 TPDUs. This is a tad technical I know, but it will mean that we have a common format internally. This will not be easy as there are a lot of character set conversion issues, and multiple TPDUs where concatenation of texts is used. The upshot for us is a more consistent and maintainable platform. The benefit for customers is more ways to submit and receive text messages, including using 17094009 to make an ETSI in-band modem text call from suitable equipment (we think gigasets do this). It also means customers will be able to send/receive texts in a raw GSM 03.40 TPDU format, which will be of use to some customers. It also makes it easier for us to add other formats later. There will be some changes to the existing interfaces over time, but we want to keep these to a minimum, obviously.
Update
21 Apr 2014 16:27:23

Work is going well on this, and we hope to switch Mobile Originated texting (i.e. texts from the SIP2SIM) over to the new system this week. If that goes to plan we can move some of the other ingress texting over to the new system one by one.

We'll be updating documentation at the same time.

The new system should be a lot more maintainable. We have a number of open tickets with the mobile carrier and other operators to try and improve the functionality of texting to/from us. These cover things like correct handling of multi-part texts, and correct character set coding.

The plan is ultimately to have full UTF-8 unicode support on all texts, but that could take a while. It seems telcos like to mess with things rather than giving us a clean GSM TPDU for texts. All good fun.

Update
22 Apr 2014 08:51:09
We have updated the web site documentation on this to the new system, but this is not fully in use yet. Hopefully this week we have it all switched over. Right now we have removed some features from documenation (such as delivery reports), but we plan to have these re-instated soon once we have the new system handling them sensibly.
Update
22 Apr 2014 09:50:44
MO texts from SIP2SIM are now using the new system - please let support know of any issues.
Update
22 Apr 2014 12:32:07
Texts from Three are now working to ALL of our 01, 02, and 03 numbers. These are delivered by email, http, or direct to SIP2SIM depending on the configuration on our control pages.
Update
23 Apr 2014 09:23:20
We have switched over one of our incoming SMS gateways to the new system now. So most messages coming from outside will use this. Any issues, please let support know ASAP.
Update
25 Apr 2014 10:29:50
We are currently running all SMS via the new platform - we expect there to be more work still to be done, but it should be operating as per the current documentation now. Please let support know of any issues.
Update
26 Apr 2014 13:27:37
We have switched the DNS to point SMS to the new servers running the new system. Any issues, please let support know.
Started 14 Apr 2014
Previously expected 01 May 2014

11 Apr 2014 15:50:28
Details
11 Apr 2014 15:53:42
There is a problem with the C server and it needs to be restarted again after the maintenance yesterday evening. We are going to do this at 17:00 as we need it to be done as soon as possible. Sorry for the short notice.
Started 11 Apr 2014 15:50:28

07 Apr 2014 13:45:09
Details
07 Apr 2014 13:52:31
We will be carrying out some maintenance on our 'C' SIP server outside office hours. It will cause disruption to calls, but is likely only to last a couple of minutes and will only affect calls on the A and C servers. It will not affect calls on our "voiceless" SIP platform or SIP2SIM. We will do this on Thursday evening at around 22:30. Please contact support if you have any questions.
Update
10 Apr 2014 23:19:59
Completed earlier this evening.
Started 07 Apr 2014 13:45:09
Previously expected 10 Apr 2014 22:45:00

25 Sep 2013
Details
18 Sep 2013 16:32:41
We have received notification that Three's network team will be carrying out maintenance on one of the nodes that routes our data SIM traffic between 00:00 and 06:00 on Weds 25th September. Some customers may notice a momentary drop in connections during this time as any SIMs using that route will disconnect when the link is shut down. Any affected SIMs will automatically take an alternate route when they try and reconnect. Unfortunately, we have no control over the timing of this as it is dependent on the retry strategy of your devices. During the window, the affected node will be offline therefore SIM connectivity should be considered at risk throughout.
Started 25 Sep 2013

Details
6 Jul 12:49:42
We have been advised by Three of works on their network (22:30 8th July to 04:50 9th July 2015)

Which will involve rerouting traffic from one of their nodes via alternate paths in their core. Although connections should automatically reroute, there will be brief amounts of packet loss. As a result, some partners may experience dropped connections. Any device reconnecting will automatically be routed via a new path. We apologise for any inconvenience this may cause and the short notice of this advisory.


Details
12 Feb 15:57:26
We have received the below PEW notification from one of our carriers that we take voice SIMS from. We have been advised by one of our layer 2 suppliers of emergency works to upgrade firmware on their routers to ensure ongoing stability. This will cause short drops in routing during the following periods: 00:00 to 06:00 Fri 13th Feb 00:00 to 04:00 Mon 16th Feb Although traffic should automatically reroute within our core as part of our MPLS infrastructure, some partners may experience disruption to SIM connectivity due to the short heartbeats used on SIM sessions.

28 Jul 13:00:00
Details
27 Jul 16:17:35
We have a problem at the moment activating data SIMs. This has been escalated to the carrier who are investigating.
Update
28 Jul 10:30:41
No update as yet, but we are chasing the carrier on this.
Update
28 Jul 13:45:21
SIM activation has now been restored.
Resolution Problem at the carrier has been fixed.
Started 27 Jul 09:00:00
Closed 28 Jul 13:00:00

30 Jun 16:26:40
Details
30 Jun 16:27:00
We're investigating some sort of issue affecting lots of broadband showing some packet loss.
Update
30 Jun 16:34:37
Seems to be recovering, and we are trying to find cause now.
Resolution Further issues during the night allowed us to track down the source of the problem which was a compromised customer hosted machine. Steps are being taken to address this in future.
Started 30 Jun 16:16:40
Closed 30 Jun 16:26:40

27 Jul 10:36:06
Details
16 Jun 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.

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

20 Jul 19:00:00
Details
18 Jul 12:40:39
We have had some reports this week of poor call quality on SIP2SIM some of the time, and it seems to be getting worse. We are looking in to it, and have had reports that it is particularly bad today. It seems to be something in the link between us and the mobile carriers.
Update
20 Jul 15:38:24
Detailed logs have been sent to the carrier and they are investigating the cause of this.
Update
20 Jul 18:00:48
The carrier is making changes soon that may address this issue.
Update
21 Jul 14:31:52
Our carrier implemented a change at their end at around 7pm on Monday which should fix call problems. We are monitoring this ourselves and welcome feedback from customers.
Resolution The carriers have made a change which they believe has addressed the issue.
Started 11 Jul
Closed 20 Jul 19:00:00
Previously expected 22 Jul

9 Jul 17:15:00
Details
9 Jul 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 9 Jul 17:00:00
Closed 9 Jul 17:15:00
Previously expected 9 Jul 17:10:00

2 Jul 10:44:33
Details
2 Jul 10:44:33
Some customers have advised that they are unable to call some numbers which they were able to call last week.

This is due to new rules which mandate that we charge a service charge set by the range holder plus our access fee (2p/min) for such numbers.

OFCOM have failed to provide means for telcos to determine the service charge that applies. Their only suggestion was to use the Bt Carrier Price list. We have loaded this (and are doing so every day) but it seems to be lacking a number for 084 and 087 number ranges.

Until those appear in the BT Carrier Price list, or OFCOM actually come up with a means for telcos to comply with the new regulations, the numbers cannot be called as we have no way to comply with OFCOM rules.

Feel free to complain to OFCOM over the stupidity of these new rules.

Update
7 Jul 11:14:47
We have managed a one-off load of current codes, but there still remains no official source of the codes and rates due to OFCOM's failure to define who is responsible for compiling and maintaining this information. As such there is still no sensible way to ensure this data remains correct and complete.
Started 1 Jul
Previously expected Saturday

1 Jul 04:34:32
Details
1 Jul 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 1 Jul 02:18:00
Closed 1 Jul 04:34:32

30 Jun 18:42:13
Details
30 Jun 10:22:49
From tomorrow our rates of 084, 087 and 09 numbers are changing as per OFCOM rules. These will now be the advertised rate for the number plus an access charge. Our access charge is 2p/min inc VAT. This means if someone lists a number at 10p/min plus access charge, we will be charging 12p/minute for the number.

This compares well to many operators working on 10p/min access charges.

Note that SIP2SIM is a separate mobile access service and has its own access charge for all calls either way regardless of the VoIP gateway to which it is connected.

Note that we do not provide access to 09 premium rate numbers at present and most customers have a limit on call rates set which prohibits calls to expensive 084/087 numbers.

Started 1 Jul

28 Jun 16:29:57
Details
28 Jun 14:02:49
Access to accounts and placing orders will be delayed / unavailable for some minutes. Sorry for any inconvenience.
Update
28 Jun 15:24:19
Taking somewhat longer than expected, sorry.
Started 28 Jun 14:00:00
Closed 28 Jun 16:29:57
Previously expected 28 Jun 16:30:00

24 Jun 16:27:39
Details
24 Jun 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 16:25:00

19 Jun 16:28:46
Details
31 May 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 15:27:25
Previously expected 20 Jun

19 Jun 16:28:30
Details
14 May 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 13:12:00

19 Jun 16:27:57
Details
19 Jun 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 16:25:59
Previously expected 20 Jun

18 Jun 15:00:00
[Broadband] - BT Blip - Closed
Details
18 Jun 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.
Update
18 Jun 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 14:47:59
Closed 18 Jun 15:00:00

16 Jun 18:25:11
Details
13 Feb 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.

Update
13 Feb 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.
Update
16 Feb 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 14:25:34

16 Jun 18:24:58
Details
3 Jun 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 3 Jun 11:00:00

10 Jun 02:21:49
Details
10 Jun 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 02:03:19
Closed 10 Jun 02:21:49

4 Jun 22:52:32
Details
4 Jun 16:53:51
We tend to do server maintenance on Thursday evenings. We'll be doing some security updates on servers this evening which will involve some reboots. These tend to be quick, and so service should only be affected for a few minutes. We'll be rebooting the following servers: Control Pages, Email servers, Web servers as well as a few servers that are not accessed by customers directly.
Resolution This work has been completed.
Started 4 Jun 22:00:00
Closed 4 Jun 22:52:32

1 Jun 23:30:51
Details
1 Jun 23:11:35
We're seeing odd routing blips across our network. We're investigating.
Update
1 Jun 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 1 Jun 22:55:00
Closed 1 Jun 23:30:51

12 May 10:27:29
Details
5 May 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.
Update
5 May 12:38:47
TalkTalk have fixed a misconfiguration at their end. This should now be resolved. We'll check again tomorrow.
Update
7 May 08:55:48
Lines still seem to be congested, this is being looked in to by TalkTalk.
Update
13 May 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 5 May 10:00:00
Closed 12 May 10:27:29

2 Jun 11:18:33
Details
2 Jun 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.
Update
2 Jun 11:18:56
Most lines are now back online.
Started 2 Jun 11:07:00
Closed 2 Jun 11:18:33

27 May 14:48:58
Details
27 May 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.
Update
27 May 10:46:58
This appears to be a LINX issue
Update
27 May 10:53:20
We have managed to shut down the port to LINX while this is resolved.
Update
27 May 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.
Update
27 May 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.
Update
27 May 14:39:14
LINX have rectified the issue, so we will be re-enabling LINX ports shortly.
Resolution All working now.
Started 27 May 10:30:00
Closed 27 May 14:48:58

27 May 10:53:48
Details
27 May 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 10:00:00
Closed 27 May 10:53:48
Previously expected 27 May 17:00:00

25 May 21:30:00
Details
25 May 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 18:30:00
Closed 25 May 21:30:00

15 May 14:00:00
Details
15 May 15:29:53
We have had reports of some one way audio calls today. We have not quite got to the bottom of it, and it seems to have gone away. This happened earlier in the week when one carrier had network issues, but we are not convinced that this is the same effect.
Started 15 May 12:00:00
Closed 15 May 14:00:00

13 May 12:16:45
Details
26 Mar 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.

Update
26 Mar 09:55:29
Update
26 Mar 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.
Update
26 Mar 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.
Update
27 Mar 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
Update
9 Apr 14:26:19
This is still ongoing with BT Wholesale and BT Openreach.
Update
16 Apr 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.
Update
24 Apr 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.

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

13 May 12:16:18
Details
12 May 12:50:17
One of our upstream VOIP providers are having some network issues (see below) this may be affecting some VOIP calls and 3G data SIMS.

Affected Systems: Connectivity to some aql core services Affected Customers: Some customers across aql core services Expected Resolution Time:

Dear Customers, We are aware of a connectivity issue in Leeds which engineers are investigating as their top priority. Voice customers may have seen calls drop Customers colocating in Leeds may be experiencing connectivity issues. Resiliency in some services is reduced.

Update
13 May 12:15:45
This issue has now been resolved and below is information from AQL relating to the issue.

It's never a good thing to have to write an email like this. aql operate a resilient core network with an agile edge, allowing changes to be made to accommodate the addition of customers without making any fundamental (or risky) changes to the core network.

Last week, we had an outage related to instability within our core network, due to what we believe is a vendor / O/S bug within some core switch fabric and had started works with the vendor to address the issue with as little impact as possible.

aql have strong procedures and processes to minimise operational and network impact by way of planning core works or changes to core network to have little or no disruption, to be performed during silent hours and to be announced well in advance.

In this instance, regrettably, a senior member of staff did not follow these procedures and that is now under investigation. Please be assured we take such matters seriously and will take all necessary measures to ensure that there cannot be a repeat incident.

As with all incidents, aql prepares a full RFO "Reason for Outage", within 48 hours of any incident. If you require a copy of this, please make contact with your account manager.

Both personally and on behalf of aql, my sincere apologies - You should just be able to rely on us to do our part and you can then concentrate on your business.

Closed 13 May 12:16:18

12 May 13:43:30
Details
10 May 15:04:57
We are making a number of minor changes to the billing system, so as to improve the way the bills are presented, and importantly to improve the quality of the code itself. The billing system has had to evolve over more than 18 years and is in need of some tidying.

We are not changing prices, and so bills should not actually change in total.

We are changing the order that things are presented, and in some cases the number of line items shown, to try and make the bills clearer.

There are a lot of different scenarios to test, and we aim to catch them all, but if anyone thinks there is a billing error, or simply something that looks confusing, please do let us know right away.

Rest assured that will work to correct any billing errors promptly if they do occur.

Update
12 May 13:42:36
Changes have gone well, and dry runs of next month's invoices show the amounts match up. We are pretty confident that there will not be any issues, but please do let us know of any problems with invoices.
Started 1 May
Previously expected 2 Jun

12 May 13:41:47
Details
11 May 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 18:00:00

9 May 14:31:50
Details
5 May 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:

  • FLAX BOURTON
  • REDCLIFFE
  • WEDMORE
  • Yatton
  • Didcot
  • CHURCHDOWN
  • Cheltenham
  • SHRIVENHAM
  • STRATTON ST MARGARET
  • Swindon
  • Blunsdon
  • Cirencester
  • CRICKLADE
  • HAYDON WICK
  • PURTON
  • BATHEASTON
  • BOX
  • BRADENSTOKE
  • Chippenham
  • CORSHAM
  • CHURCHILL
  • Clevedon
  • NAILSEA
  • WRINGTON
  • LONG ASHTON
  • PILL
  • Brimscombe
  • Dursley
  • NAILSWORTH
  • TETBURY
  • Calne
  • Devizes
  • HAWTHORN
  • Melksham
  • NORTH TROWBRIDGE
  • BANWELL
  • BLEADON
  • WINSCOMBE
  • Worle
  • Weston Super Mare
  • ABSON
  • Downend
  • FISHPONDS
  • SALTFORD
  • CHEW MAGNA
  • Midsomer Norton
  • Radstock
  • STRATTON-ON-FOSSE
  • TEMPLE CLOUD
  • TIMSBURY
  • STOKE BISHOP
  • West
  • Frome
  • MELLS
  • WARMINSTER
  • BRADFORD-ON-AVON
  • LIMPLEY STOKE
  • Trowbridge
  • Westbury
  • ALMONDSBURY
  • FILTON
  • HENBURY
  • AVONMOUTH
  • PILNING
  • Portishead
  • BEDMINSTER
  • BISHOPSWORTH
  • BITTON
  • KEYNSHAM
  • Kingswood
  • CHIPPING SODBURY
  • FALFIELD
  • WINTERBOURNE
  • WOTTON UNDER EDGE
  • FAIRFORD
  • LECHLADE
  • MALMESBURY
  • SOUTH CERNEY
  • TOOTHILL
  • WOOTTON BASSETT
  • COMBE DOWN
  • Kingsmead
  • Bristol North
  • WESTBURY-ON-TRYM
  • EASTON
  • EASTVILLE
  • South
  • WHITCHURCH
  • LAVINGTON
  • MARLBOROUGH
  • PEWSEY
  • WROUGHTON
  • WANBOROUGH
  • LULSGATE
  • Glastonbury
  • OAKHILL
  • Wells
  • BERKELEY
  • THORNBURY
We apologise for any inconvenience that these works may cause you
Started 8 May by TalkTalk
Closed 9 May 14:31:50

23 Apr 2014 10:21:03
Details
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.

Update
04 Nov 2013 16:52:49
We have been working on getting more specific information regarding this, we hope to post an update tomorrow.
Update
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.
Update
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.
Update
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.
Update
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.
Update
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.

Update
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.
Update
27 Nov 2013 10:10:13
We have also had reports from someone outside of AAISP reproducing this problem.
Update
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.
Update
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
Update
13 Jan 2014 14:09:08
We are still chasing this with BT.
Update
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.
Update
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.
Update
7 May 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.

--Update--
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

7 May 09:53:49
Details
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.
Update
11 Dec 2014 10:46:42
BT have passed this to TSO for investigation. We are waiting for a further update.
Update
12 Dec 2014 14:23:56
BT's Tso are currently investigating the issue.
Update
16 Dec 2014 12:07:31
Other ISPs are seeing the same problem. The BT Capacity team are now looking in to this.
Update
17 Dec 2014 16:21:04
No update to report yet, we're still chasing BT...
Update
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."
Update
19 Dec 2014 15:47:47
BT are looking to move our affected circuits on to other ports.
Update
13 Jan 10:28:52
This is being escalated further with BT now, update to follow
Update
19 Jan 12:04:34
This has been raised as a new reference as the old one was closed. Update due by tomorrow AM
Update
20 Jan 12:07:53
BT will be checking this further this evening so we should have more of an update by tomorrow morning
Update
22 Jan 09:44:47
An update is due by the end of the day
Update
22 Jan 16:02:24
This has been escalated further with BT, update probably tomorrow now
Update
23 Jan 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.
Update
26 Jan 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.
Update
26 Jan 10:37:45
there will be an SVLAN migration to resolve this issue on Wednesday 28th Jan.
Update
30 Jan 09:33:57
Network rearrangement is happening on Sunday so we will check again on Monday
Update
2 Feb 14:23:12
Network rearrangement was done at 2AM this morning, we will check for paclet loss and report back tomorrow.
Update
3 Feb 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.
Update
4 Feb 10:39:03
Escalated futher with an update due at lunch time
Update
11 Feb 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 ......
Update
24 Feb 12:59:54
escalated further with BT, update due by the end of the day.
Update
2 Mar 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.
Update
17 Mar 11:21:33
We have just put a boot up BT on this, update to follow.
Update
2 Apr 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 7 May 09:53:49
Previously expected 1 Feb 09:34:04 (Last Estimated Resolution Time from AAISP)

7 May 09:52:18
Details
11 Mar 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.
Update
11 Mar 11:44:06
Here is an example graph
Update
12 Mar 12:00:45
This has been escalated further to the BT networK guys and we can expect an update within the next few hours.
Update
17 Mar 15:41:18
Work was done on this overnight so I will check again tomorrow morming and post another update.
Update
18 Mar 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.
Update
19 Mar 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.
Update
23 Mar 14:07:53
BT have still not pinpointed the issue so it has been escalated further.
Update
27 Mar 13:03:38
Latency is hardly noticeable now but we are still chasing BT on sorting the actual issue, update will be mOnday now.
Update
30 Mar 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.
Update
2 Apr 12:28:39
We have requested a further escalation within BT, the time scales they have given for a fix is just not acceptable.
Update
13 Apr 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.
Update
16 Apr 16:01:15
We are still chasing BT up on bringing the 'fix' forward. Hopefully we will have another response by the morning.
Update
21 Apr 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...
Update
24 Apr 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 01:35:37
Closed 7 May 09:52:18

6 May 14:03:19
Details
5 May 16:29:43
Our office internet is currently offline. We're arranging our backup connection at the moment.
Update
5 May 16:55:40
We're making progress on our backup link as well as investigating the cause of the main fault.
Update
5 May 18:57:51
We do apologise about our connectivity problems this afternoon. We have been running on our backup FTTC line, and we're investigating why the direct fibre is down.
Update
6 May 10:34:33
Our main internet connection is still down this morning. We have a number of BT engineers working on this at the moment. This does mean that we are running on our backup FTTC links and most things are working OK! Some telephone calls are a little temperamental, we'd appreciate customers using IRC or email where possible, see: http://aa.net.uk/kb-irc.html for details of connecting to IRC. We hope to be back to normal later this morning.
Update
6 May 11:57:53
BT have identified 2 faults with our fibre. They have fixed one of them (a kink in a fibre patch lead in Bracknell exchange) and are investigating the second (low light level on one leg).
Resolution We're all back to normal now!
Started 5 May 16:25:00
Closed 6 May 14:03:19