|
|
|
Here's a question for anyone that uses AAISP's L2TP service:
I run a e-mail & web server using AAISP's L2TP to provide public IP, and this has worked reliably over 4G and FTTP for a number of years. Over FTTP the TTB QM showed a consistent 6-8ms latency and max latency peaks of 10-20ms with traffic and no packet loss.
Just after 10pm on 14th August 2025 the connection dropped briefly and the base latency jumped to ~80ms, with the max peaking at around 100ms - and it has remained like that since until a few weeks ago. There was no noticeable difference to the operation of the server, so I didn't worry about it.
On 11th December the base latency increased to ~140ms between around 4pm and 8pm, with a 20% packet loss, and it has repeated that almost every day since - the start and end time varies by half an hour or so.each day.
My server is not showing any load corresponding to this, and the underlying FTTP connection has a steady 7ms latency and no packet loss - so it appears it is the AAISP L2TP service that has the issue.
Has anyone else seen similar issues?
|
|
|
Dont currently use the L2TP service but I think a MTR or pathping to the L2TP is is a good starting point for diagnosis.
|
|
|
|
Post deleted by Mendip
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
Has anyone else seen similar issues?
I have six AAISP L2TP across FTTP, GSM, and Starlink, at three different sites. All appear normal on the AAISP control panel - e.g. Starlink showing average latency of 21ms - no changes observed over the last month. Obviously GSM dances around, but that is to be expected. Starlink and FTTP all solid.
Dont currently use the L2TP service but I think a MTR or pathping to the L2TP is is a good starting point for diagnosis.
Sounds like good advice.
To rule out the TTB monitor, I have just set up a TTB monitor on the Starlink L2TP, and will report the data back in an hour or so.
|
|
|
To rule out the TTB monitor, I have just set up a TTB monitor on the Starlink L2TP, and will report the data back in an hour or so.
FTTP over OR/BT AAISP 8/10/11ms - AAISP Control panel
FTTP over L2TP OR/BT TTB 9/10/12ms - TTB Monitor
Starlink 14/21/68ms - AAISP Control panel
Starlink over L2TP AAISP 15/22/71ms - TTB Monitor
I have also manually verified the latency - the results above are correct.
Just one thought... have you checked that you are not permanently routing over GSM, as the figures you are seeing for latency are 'in the ballpark' for GSM?
Other than that, it doesn't 'appear' to be AAISP or the TTB monitor, so:
I think a MTR or pathping to the L2TP is is a good starting point for diagnosis.
seems like very good advice.
Edited by Mendip (Sun 04-Jan-26 09:19:46)
|
|
|
|
What does your router say the tunnel is connecting over? It sounds like maybe it failed over to 4G and since the session is still open it hasn't failed back.
|
|
|
|
Thanks for all the comments and suggestions - it is useful to know that nobody else is seeing the same issues.
I currently only have FTTP connected, and have TBB QM running on both the L2TP and the underlying FTTP. The latter has a steady 6 ms latency and zero packet loss, while the L2TP shows the high latency and packet loss for a period every evening.
The AAISP trace shows the same issue as the TBB QM. There doesn't appear to be anything unusual in the routing, and that doesn't change at all during the bad periods.
I am away at present, but next week I will set the L2TP up on a different server just to rule that out, even though the server itself shows no problems. I will post an update when I have the results of that experiment.
|
|
|
|
I promised an update on this issue - and on return from being away I find that it magically disappeared at 8am on 8th Jan! The TBB traces over AAISP and the underlying FTTP connection are now effectively identical.
So I have no idea what the cause - or solution - was. Anyway I'm pleased to say it's a happy ending.
|
|
|
I'm seeing this now, a traceroute from IDNet to the l2tp.aa.net.uk endpoint shows it taking a very strange path:
Tracing route to l2tp.aa.net.uk [194.4.172.12]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 10.1.104.1
2 4 ms 4 ms 3 ms 212.69.63.19
3 3 ms 5 ms 5 ms 212.69.63.182
4 4 ms 4 ms 5 ms xe-0-5-0-1.a02.londen12.uk.bb.gin.ntt.net [81.25.207.41]
5 6 ms 6 ms 6 ms ae-1.r23.londen12.uk.bb.gin.ntt.net [129.250.5.8]
6 80 ms 81 ms 80 ms ae-13.r27.asbnva02.us.bb.gin.ntt.net [129.250.2.111]
7 81 ms 81 ms 82 ms ae-2.a08.asbnva02.us.bb.gin.ntt.net [129.250.5.45]
8 87 ms * 87 ms 129.250.8.17
9 86 ms 85 ms 86 ms rest-bb1-link.ip.twelve99.net [62.115.123.122]
10 79 ms 80 ms 80 ms nyk-bb5-link.ip.twelve99.net [62.115.139.34]
11 81 ms 81 ms 81 ms ldn-bb1-link.ip.twelve99.net [62.115.139.245]
12 82 ms 82 ms 82 ms ldn-b3-link.ip.twelve99.net [62.115.140.73]
13 81 ms 81 ms 82 ms arelion-th.as20712.net [192.150.92.23]
14 81 ms 82 ms 80 ms l2tp.aa.net.uk [194.4.172.12]
Edit: My latency jumped up on the 8th Jan in the morning, so it seems like something to do with how the routes are advertised. I've contacted A&A and IDNet.
Edited by jpm (Sat 17-Jan-26 10:32:21)
|
|
|
Yeah return path seems fubar, I did an outbound trace to one of the London ntt hops, and it jumps to 55ms when entering ntt network, my trace shows it never leaving London so I expect its the return path problem you posted.
Edited by Chrysalis (Sat 17-Jan-26 14:07:00)
|
|
|
|
IDNet did something presumably with their routing preferences, down to 4ms now.
Unsure why an ISP like IDNet is reaching A&A through transit rather than peering, but I guess ISP-to-ISP traffic is really minimal compared with traffic going out to content services.
|
|
|
|
It is interesting that my issue went away on 8th Jan, and yours appeared at the same time! Presumably the same network change affected both.
|
|
|
Yeah something is fixed.
Before
Tracing route to ae-1.r23.londen12.uk.bb.gin.ntt.net [129.250.5.8]
over a maximum of 30 hops:
1 4 ms 4 ms 4 ms lns1-th.as20712.net [192.150.92.41]
2 4 ms 4 ms 4 ms lumen-th.as20712.net [192.150.92.17]
3 4 ms 4 ms 4 ms 7-1-4.ear5.London2.Level3.net [217.163.102.225]
4 5 ms 7 ms 4 ms ae1.3115.edge7.lon1.neo.colt.net [171.75.9.213]
5 47 ms 49 ms 52 ms ae-15.a02.londen12.uk.bb.gin.ntt.net [129.250.9.253]
6 55 ms 56 ms 55 ms ae-15.a02.londen12.uk.bb.gin.ntt.net [129.250.9.253]
7 55 ms 56 ms 55 ms ae-1.r23.londen12.uk.bb.gin.ntt.net [129.250.5.8]
After
Tracing route to ae-1.r23.londen12.uk.bb.gin.ntt.net [129.250.5.8]
over a maximum of 30 hops:
1 4 ms 4 ms 4 ms lns1-th.as20712.net [192.150.92.41]
2 4 ms 4 ms 3 ms lumen-th.as20712.net [192.150.92.17]
3 4 ms 4 ms 4 ms 7-1-4.ear5.London2.Level3.net [217.163.102.225]
4 12 ms 5 ms 5 ms ae1.3115.edge7.lon1.neo.colt.net [171.75.9.213]
5 5 ms 5 ms 4 ms ae-15.a02.londen12.uk.bb.gin.ntt.net [129.250.9.253]
6 5 ms 14 ms 8 ms ae-15.a02.londen12.uk.bb.gin.ntt.net [129.250.9.253]
7 5 ms 5 ms 5 ms ae-1.r23.londen12.uk.bb.gin.ntt.net [129.250.5.8]
|
Pages in this thread: 
Print Thread
