|
|
Just joined AAISP and found an interesting routing difference to Mauritius Telecom server in London. With other ISPs I've used ping is around 8ms, hitting a server somewhere in London.
AAISP is coming in at 227ms, and seems to go via Johannesburg, just wondering what is happening to cause that? What are others seeing doing a tracert or ping to 197.227.5.218?
Via AAISP
| Text | 1
23
45
67
89
1011
1213
| Tracing route to 197.227.5.218 over a maximum of 30 hops
1 6 ms <1 ms <1 ms pfSense.localdomain [192.168.1.1]
2 6 ms 7 ms 7 ms y.witless.thn.aa.net.uk [90.155.53.134] 3 7 ms 7 ms 9 ms g.aimless.thn.aa.net.uk [90.155.53.47]
4 7 ms 7 ms 7 ms 8-1-1.ear1.London2.Level3.net [217.163.102.225] 5 * * * Request timed out.
6 * * * Request timed out. 7 200 ms 206 ms 200 ms be2385.ccr51.jnb01.atlas.cogentco.com [154.54.40.94]
8 227 ms 227 ms 227 ms 206.249.0.154 9 227 ms 227 ms 227 ms 197.226.230.42
10 227 ms 227 ms 238 ms 197.226.230.8 11 227 ms 227 ms 227 ms 197.227.5.218 |
Via a work connection
| Text | 1
23
45
67
89
1011
1213
1415
1617
| Tracing route to 197.227.5.218 over a maximum of 30 hops
1 1 ms <1 ms <1 ms *
2 3 ms 3 ms 3 ms * 3 3 ms 3 ms 3 ms *
4 3 ms 3 ms 3 ms * 5 3 ms 3 ms 3 ms *
6 3 ms 3 ms 3 ms be42973-10.man1.pag.gb.m247.com [164.39.60.82] 7 3 ms 3 ms 3 ms hu0-0-0-3.man1.agg1.gb.m247.com [217.138.224.20]
8 3 ms 3 ms 4 ms hu0-0-1-0.man1.edg.gb.m247.com [217.138.224.17] 9 3 ms 4 ms 3 ms xe-0-4-0-7.r02.londen03.uk.bb.gin.ntt.net [83.231.235.229]
10 8 ms 8 ms 9 ms ae-12.r20.londen12.uk.bb.gin.ntt.net [129.250.4.191] 11 24 ms 13 ms 9 ms ae-13.a03.londen12.uk.bb.gin.ntt.net [129.250.3.249]
12 * 9 ms * 195.219.23.72 13 8 ms 10 ms 8 ms if-ae-66-2.tcore1.ldn-london.as6453.net [80.231.60.144]
14 9 ms 8 ms 8 ms 195.219.83.158 15 8 ms 8 ms 8 ms 197.227.5.218 |
|
|
|
If it's any consolation TalkTalk is the same
traceroute to 197.227.5.218 (197.227.5.218), 30 hops max, 60 byte packets
1 _gateway (192.168.101.250) 0.575 ms 0.547 ms 0.609 ms
2 78.144.1.11 (78.144.1.11) 3.789 ms 3.746 ms 3.647 ms
3 78.144.1.10 (78.144.1.10) 7.928 ms 7.964 ms 7.896 ms
4 * * *
5 * * *
6 * * *
7 154.54.80.202 (154.54.80.202) 184.614 ms 154.54.88.222 (154.54.88.222) 184.206 ms 154.54.88.206 (154.54.88.206) 183.754 ms
8 206.249.0.154 (206.249.0.154) 227.830 ms 228.183 ms 210.351 ms
9 196.20.225.50 (196.20.225.50) 228.284 ms 196.20.225.94 (196.20.225.94) 228.807 ms 228.923 ms
10 197.226.230.50 (197.226.230.50) 228.659 ms 197.227.5.218 (197.227.5.218) 227.783 ms 209.653 ms
AAISP hands over to Level3 at hop 4, so Level3 is presumably advertising what looks like the best route.
Edited by mr_bean (Sun 01-May-22 18:03:24)
|
|
|
Same with BT - goes to Cogent and then to SA.
| Text | 1
23
45
67
89
1011
1213
1415
| Tracing route to 197.227.5.218 over a maximum of 30 hops
1 90 ms 3 ms 2 ms 192.168.1.254
2 6 ms 6 ms 5 ms 172.16.11.199 3 * * * Request timed out.
4 11 ms 9 ms 11 ms 62.172.102.70 5 10 ms 9 ms 9 ms core3-hu0-14-0-6.faraday.ukcore.bt.net [62.172.103.49]
6 11 ms 12 ms 9 ms 166-49-209-132.gia.bt.net [166.49.209.132] 7 10 ms 10 ms 10 ms 166-49-209-131.gia.bt.net [166.49.209.131]
8 127 ms 12 ms 11 ms be3487.ccr41.lon13.atlas.cogentco.com [154.54.60.5] 9 11 ms 10 ms 11 ms be2870.ccr22.lon01.atlas.cogentco.com [154.54.58.174]
10 185 ms 187 ms 186 ms be2389.ccr51.jnb01.atlas.cogentco.com [154.54.80.202] 11 190 ms 188 ms 187 ms 206.249.0.154
12 231 ms 232 ms 231 ms 196.20.225.96 13 238 ms 230 ms 230 ms 197.227.5.218 |
I've never known M247 to operate a particularly good network so the performance of this server looks to be more of a fluke of using NTT than a conscious decision.
Edit: You can run a traceroute from each of the major providers' networks, just search for their looking glass tool:
https://www.cogentco.com/en/looking-glass
https://www.gin.ntt.net/looking-glass/
https://lookingglass.centurylink.com/
Both NTT and Lumen have that server down as being in London, Cogent get there by going via Johannesburg,
Edited by jpm (Sun 01-May-22 18:40:45)
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
Some big pauses on a Zen connection as well.
Tracing route to 197.227.5.218 over a maximum of 30 hops
1 1 ms 1 ms 1 ms server.xxxx.private [192.168.12.101]
2 1 ms 1 ms 1 ms router.xxxx.private [192.168.12.1]
3 24 ms 18 ms 16 ms lo0-0.bng4.thn-lon.zen.net.uk [51.148.77.132]
4 15 ms 15 ms 16 ms lag-14.p2.thn-lon.zen.net.uk [51.148.73.96]
5 17 ms 16 ms 21 ms lag-2.br1.thn-lon.zen.net.uk [51.148.73.167]
6 16 ms 16 ms 16 ms ldn-b3-link.ip.twelve99.net [213.248.84.100]
7 * * * Request timed out.
8 193 ms 193 ms 195 ms be2385.ccr51.jnb01.atlas.cogentco.com [154.54.40.94]
9 256 ms 257 ms 258 ms 206.249.0.154
10 465 ms 463 ms 465 ms 197.226.230.50
11 468 ms 469 ms 468 ms 197.226.230.4
12 470 ms 470 ms 468 ms 197.227.5.218
Trace complete.
|
|
|
|
Post deleted by aquiss
|
|
The above post has been made by an ISP REPRESENTATIVE (although not necessarily the ISP being discussed in the post).
|
|
|
I just thought I would see the route we take here at Aquiss. Seems a bit more logical.
Tracing route to 197.227.5.218 over a maximum of 30 hops
1 2 ms 2 ms 2 ms 192.168.1.1
2 13 ms 12 ms 14 ms lns4.inx.dsl.enta.net [78.33.253.11]
3 13 ms 13 ms 13 ms 100.bundle-ether2.inx.dsl.enta.net [78.33.253.1]
4 13 ms * 25 ms bundle-ether1.interxion3.core.enta.net [188.39.127.242]
5 13 ms 13 ms 13 ms bundle-ether100.telehouse-east4.core.enta.net [188.39.127.102]
6 * 12 ms 13 ms 172.30.1.24
7 14 ms 14 ms 25 ms 212.187.195.89
8 * 13 ms * 195.219.23.10
9 15 ms 13 ms 13 ms if-ae-66-2.tcore1.ldn-london.as6453.net [80.231.60.144]
10 14 ms 15 ms 14 ms 195.219.83.158
11 16 ms 13 ms 14 ms 197.227.5.218
Trace complete.
Martin Pitt
Company Founder
Aquiss Limited
https://www.aquiss.net
FTTC, FTTP, GEA, EFM, Leased Lines, Telecoms and Hosting |
|
The above post has been made by an ISP REPRESENTATIVE (although not necessarily the ISP being discussed in the post).
|
|
|
via IDNet:
| Text | 1
23
45
6 | traceroute to 197.227.5.218 (197.227.5.218), 64 hops max, 52 byte packets
1 rt-ac66u_b1-0208 (192.168.1.1) 0.621 ms 0.414 ms 0.347 ms 2 telehouse-gw10-10g.idnet.net (212.69.63.54) 14.832 ms 14.697 ms 14.425 ms
3 212.69.63.136 (212.69.63.136) 26.364 ms 14.951 ms 14.462 ms 4 195.66.227.71 (195.66.227.71) 15.433 ms 15.463 ms 15.660 ms
5 197.227.5.218 (197.227.5.218) 14.752 ms 15.608 ms 14.962 ms |
eta- on FTTC, DLM has decided I deserve interleave for some reason, damn thing does that now and then 
Bill
Edited by billford (Sun 01-May-22 19:59:41)
|
|
|
Just to add mine as I use AAISP's L2TP.
| Text | 1
23
45
67
89
1011
12 | Tracing route to 197.227.5.218 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.2.254
2 23 ms 52 ms 44 ms l2tp.thn.aa.net.uk [90.155.53.19] 3 45 ms 51 ms 36 ms g.aimless.thn.aa.net.uk [90.155.53.47]
4 43 ms 43 ms 43 ms 8-1-1.ear1.London2.Level3.net [217.163.102.225] 5 40 ms 40 ms 40 ms ae2.3204.ear2.London2.level3.net [4.69.143.194
6 * * * Request timed out. 7 225 ms 214 ms 210 ms be2385.ccr51.jnb01.atlas.cogentco.com [154.54.40.94]
8 311 ms 292 ms 280 ms 206.249.0.154 9 268 ms 268 ms 268 ms 196.20.225.96
10 279 ms 261 ms 255 ms 197.227.5.218 |
|
|
|
Via Cerberus:
$ traceroute 197.227.5.218
traceroute to 197.227.5.218 (197.227.5.218), 64 hops max, 52 byte packets
1 gw2 (10.12.0.1) 0.810 ms 0.543 ms 0.306 ms
2 thn-lns07-l6.cerberus.net.uk (46.37.48.1) 4.691 ms 6.770 ms 5.282 ms
3 hex-gw06-te030-43.cerberus.net.uk (46.37.33.43) 5.486 ms 5.206 ms 5.144 ms
4 te0-0-0-11.rcr21.b015534-1.lon01.atlas.cogentco.com (149.14.248.185) 6.342 ms 5.778 ms 5.749 ms
5 be2186.ccr22.lon01.atlas.cogentco.com (154.54.61.70) 5.785 ms 5.970 ms
be2185.ccr21.lon01.atlas.cogentco.com (154.54.61.62) 5.973 ms
6 be2389.ccr51.jnb01.atlas.cogentco.com (154.54.80.202) 198.969 ms
be2489.ccr51.jnb01.atlas.cogentco.com (154.54.88.222) 164.688 ms
be2485.ccr51.jnb01.atlas.cogentco.com (154.54.88.206) 164.178 ms
7 206.249.0.154 (206.249.0.154) 241.567 ms 241.564 ms 223.588 ms
8 197.226.230.50 (197.226.230.50) 225.892 ms
197.226.230.40 (197.226.230.40) 225.366 ms
197.226.230.50 (197.226.230.50) 208.926 ms
9 197.227.5.218 (197.227.5.218) 225.146 ms
197.226.230.8 (197.226.230.8) 225.637 ms 226.007 ms
You can see the route announcements here:
https://bgp.he.net/ip/197.227.5.218
They are making a more specific route announcement of 197.227.5.0/24, which might be for their London network, or for "Anycast" services (which are supposed to hit the "nearest" server). But in order for this to work, they have to get their peers or upstreams in London to pick this up.
Maybe they have very few peers in London. Maybe they have configured route announcements wrongly. In any case, only Mauritius Telecom can fix this, so you need to raise it with your ISP and ask them to raise it with MT's NOC.
|
|
|
Cogentco have been been issus with DDoS attacts, also this weekend there been some maintenance.
https://ecogent.cogentco.com/network-status
Now DDoS could be issue. Just ask you to join the dots if can.
https://news.abplive.com/news/world/internet-backbon...
Edited by amiga_dude (Mon 02-May-22 10:22:26)
|
|
|
|
Community FIbre and Plusnet both routing via JNB at >200ms.
OVH (UK) routes via France-IX, possibly Marseille for around 40ms.
|
|
|
I manually changed our routing to prefer NTT over Level3/Lumen for this prefix - it's a hop longer, but far lower latency (as it's not been routed to a different contrinent!)
I've also asked Mauritius Telecom if they'd like to peer over LINX...
Edited by andrewhearn (Mon 02-May-22 11:57:10)
|
|
The above post has been made by an ISP REPRESENTATIVE (although not necessarily the ISP being discussed in the post).
|
|
|
I manually changed our routing to prefer NTT over Level3/Lumen for this prefix - it's a hop longer, but far lower latency (as it's not been routed to a different contrinent!)
I've also asked Mauritius Telecom if they'd like to peer over LINX...
In light of recent, and understandable, discussion on whether AAISP's prices are 'worth it' in the FTTP age, I think this is an excellent data point.
Good luck getting that out of anyone else on a bank holiday Monday!
Edited by ft247 (Mon 02-May-22 12:19:53)
|
|
|
Well that sorted it. I posted more as a curiosity than anything else and that's fantastic to see you've fixed it.
Before:
http://www.nperf.com/r/3381921621277277-88i1rUgT
After:
https://www.nperf.com/r/3382265865030995-iQv1phbC
|
|
|
In light of recent, and understandable, discussion on whether AAISP's prices are 'worth it' in the FTTP age, I think this is an excellent data point.
Good luck getting that out of anyone else on a bank holiday Monday!
Quite agree.
|
|
|
|
Ping here in Dumbarton, Scotland is now 15ms on AAISP FTTC connection.
As said before what other ISP could beat that service on a Bank holiday?
|
|
|
I manually changed our routing to prefer NTT over Level3/Lumen for this prefix - it's a hop longer, but far lower latency (as it's not been routed to a different contrinent!)
I've also asked Mauritius Telecom if they'd like to peer over LINX...
While your quick response is to be congratulated (as obviously your primary goal is for your customers to get the best experience), what can be done to push a proper fix higher up the chain?
I checked Zen, Vodafone and Three, they all have problem with this route and aren't using level3 to get there. Surely this is a core routing issue and needs to be addressed?
I checked Cogent (a common peer amongst them all) and there seems to be no way for a normal human to contact them other than their info e-mail address. Wouldn't an ISP have more clout here?
|
|
|
My Plusnet connection looks OK and not going the long way round 
Tracing route to 197.227.5.218 over a maximum of 30 hops
1 1 ms <1 ms 1 ms 192.168.1.1
2 6 ms 5 ms 5 ms 172.16.12.220
3 * * 13 ms 141.hiper04.sheff.dial.plus.net.uk [195.166.143.141]
4 12 ms 11 ms 11 ms 140.hiper04.sheff.dial.plus.net.uk [195.166.143.140]
5 11 ms 11 ms 11 ms peer7-et-0-1-7.telehouse.ukcore.bt.net [109.159.252.240]
6 12 ms 11 ms 15 ms 166-49-214-194.gia.bt.net [166.49.214.194]
7 12 ms 12 ms 12 ms ix-be-68.ecore1.ldn-london.as6453.net [195.219.83.104]
8 12 ms 11 ms 11 ms if-ae-66-2.tcore1.ldn-london.as6453.net [80.231.60.144]
9 12 ms 12 ms 12 ms 195.219.83.158
10 11 ms 11 ms 11 ms 197.227.5.218
Trace complete.
|
|
|
I manually changed our routing to prefer NTT over Level3/Lumen for this prefix - it's a hop longer, but far lower latency (as it's not been routed to a different contrinent!)
I've also asked Mauritius Telecom if they'd like to peer over LINX...
While your quick response is to be congratulated (as obviously your primary goal is for your customers to get the best experience), what can be done to push a proper fix higher up the chain?
I checked Zen, Vodafone and Three, they all have problem with this route and aren't using level3 to get there. Surely this is a core routing issue and needs to be addressed?
I checked Cogent (a common peer amongst them all) and there seems to be no way for a normal human to contact them other than their info e-mail address. Wouldn't an ISP have more clout here?
The underlying issue is with Mauritius Telecom - they are advertising that the preferred way to reach MT is via Level 3, with NTT as a backup. However, they only interconnect with Level 3 in South Africa, not the UK, whereas they interconnect with NTT in London.
MT have multiple ways they could fix this:
1. Change their BGP advertisements to tell ISPs to prefer NTT to Level 3 for this netblock. Chances are that this would cost them more than advertising Level 3.
2. Interconnect with Level 3 in London as well as Johannesburg, and get the traffic for this netblock handed over in London. Again, though, this costs money.
3. Given that they have a London presence, peer at LINX and/or LONAP and advertise this netblock to all comers over that peering. Costs money to set up.
You'll notice a theme here - all the options cost MT money compared to leaving things as-is. Indeed, it's quite likely that by manually overriding their preferences and routing via NTT instead of Level 3, Andrew has increased MT's bills by a small amount.
However, if you're paying Mauritius Telecom for something, and point out this divergence, they may well be willing to adjust their routing to keep their paying customers happy.
|
|
|
|
Also important to have some perspective here - this is a speed test server. Nobody has mentioned any actual services they use being hosted by MT that are affected by this.
|
|
|
Hmm, posted on saturday. Might it be related to a new law introduced on friday (with very little notice).
https://www.ispreview.co.uk/index.php/2022/04/russia...
|
|
|
Also important to have some perspective here - this is a speed test server. Nobody has mentioned any actual services they use being hosted by MT that are affected by this.
+1
|
|
|
I manually changed our routing to prefer NTT over Level3/Lumen for this prefix - it's a hop longer, but far lower latency (as it's not been routed to a different contrinent!)
I've also asked Mauritius Telecom if they'd like to peer over LINX...
While your quick response is to be congratulated (as obviously your primary goal is for your customers to get the best experience), what can be done to push a proper fix higher up the chain?
I checked Zen, Vodafone and Three, they all have problem with this route and aren't using level3 to get there. Surely this is a core routing issue and needs to be addressed?
I checked Cogent (a common peer amongst them all) and there seems to be no way for a normal human to contact them other than their info e-mail address. Wouldn't an ISP have more clout here?
If they do as he requests on the LINX peering, that might work for all the other isp's.
|
|
|
However, if you're paying Mauritius Telecom for something, and point out this divergence, they may well be willing to adjust their routing to keep their paying customers happy.
Might try messaging nPerf about this as it quite likely this anomaly was first noticed by @E300 in speed testing using their system.
In the case of MT it’s noted a 10Gbps connection (one of only three in the UK - the other two being OVH and DataPacket) - the rest being 1Gbps connections and a sole 2 Gbps connection.
I’m sure nPerf folk want their tools to be associated with accurate results 
|
|
|
|
So I've had a response from nPerf Helpdesk this morning...
"Hello,
We have restricted the use of your server to Mauritius. This server will no longer be accessible in London.
Best regards
Virgile"
😂😂
Fair play Virgile, that's one way of tacking the problem...
|
|
|
That is funny, so they've restricted a server that resides in London for those in Mauritius, I bet people are not going to be impressed with the speeds when testing from Mauritius.
Isn't one of the points of having multiple servers in different locations on speed tests to help find issues such as this? A big fail for nPerf then and I was getting my best speed test results from that 10Gbps Mauritius Telecom server on nPerf after the routing was fixed, probably because it wasn't ever being maxed out as most tests were going the roundabout route and slowed down
Edited by E300 (Wed 18-May-22 13:27:16)
|
|
|
Thought I'd add my results here although a bit late.
Cerberus Networks (FTTP):
| Text | 1
23
45
67
89
1011
12 | Tracing route to 197.227.5.218 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms no-ptr.local [192.168.0.1]
2 6 ms 6 ms 6 ms thn-lns07-l6.cerberus.net.uk [46.37.48.1] 3 6 ms 6 ms 6 ms hex-gw06-te030-43.cerberus.net.uk [46.37.33.43]
4 7 ms 7 ms 6 ms te0-0-0-11.rcr21.b015534-1.lon01.atlas.cogentco.com [149.14.248.185] 5 7 ms 7 ms 7 ms be2186.ccr22.lon01.atlas.cogentco.com [154.54.61.70]
6 163 ms 163 ms 163 ms be2489.ccr51.jnb01.atlas.cogentco.com [154.54.88.222] 7 207 ms 207 ms 207 ms 206.249.0.154
8 207 ms 210 ms 207 ms 197.226.230.50 9 207 ms 207 ms 207 ms 197.226.230.4
10 207 ms 207 ms 207 ms 197.227.5.218 |
OVH via GRE tunnel from my network (server is in London):
| Text | 1
23
45
67
89
1011
1213
1415
16 | Tracing route to 197.227.5.218 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms [redacted] [x.x.x.x]
2 * * * Request timed out. 3 7 ms 8 ms 7 ms [redacted]
4 * * * Request timed out. 5 * * * Request timed out.
6 * * * Request timed out. 7 8 ms 8 ms 8 ms be103.lon-drch-sbb1-nc5.uk.eu [91.121.215.118]
8 37 ms 12 ms 12 ms be101.rbx-g4-nc5.fr.eu [54.36.50.231] 9 15 ms 15 ms 15 ms par-gsw-sbb1-nc5.fr.eu [54.36.50.228]
10 30 ms 30 ms 38 ms be101.mrs-mrs2-sbb1-nc5.fr.eu [54.36.50.159] 11 * * * Request timed out.
12 30 ms 30 ms 30 ms mauritius.mrs.franceix.net [37.49.232.43] 13 46 ms 46 ms 47 ms 197.226.230.20
14 44 ms 44 ms 44 ms 197.227.5.218 |
The second result seems to go via France.
Edited by Ixel (Wed 18-May-22 13:58:52)
|
|
|
|
Very much dumped in the "too hard basket" by nPerf
|
|
|
Very much dumped in the "too hard basket" by nPerf
Or maybe the "Can't be ar...d"
|
|
|
Very much dumped in the "too hard basket" by nPerf
Probably dumped in the basket where it shouldn't have been available to the UK to begin with, the complaints drew attention to it, and it was nailed down.
London is a legitimate location for Mauritius Telecom testing.
|
|
|
|
It's not the job of nPerf to fix the routing to another provider's network
|
Pages in this thread: 
Print Thread
aquiss