main_icn_My_Vodafone main_icn_Search main_icn_Chevron_right main_icn_Chevron_down main_icn_Close main_icn_Menu social-facebook social-google-plus social-linkedin social-twitter social-youtube main_icn_Community_or_Foundation main_icn_Location main_icn_Network_signal

Other broadband queries

Milton Keynes routed via Manchester, high latency - Gigafast Broadband 900

SOLVED
View solved solution
gerhardlazu
3: Seeker

My Gigafast Broadband 900 connection that is based in Milton Keynes is getting routed through Manchester instead of London. This means that all data packets go 120 miles north, and then 160 miles south before they can start getting routed to the correct destination.

Latency to bbc.co.uk (London area) is no less than 14ms, instead of 2-3ms:

$ ping -c 10 bbc.co.uk
PING bbc.co.uk (151.101.192.81): 56 data bytes
64 bytes from 151.101.192.81: icmp_seq=0 ttl=57 time=14.999 ms
...

--- bbc.co.uk ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 14.359/14.643/15.033/0.213 ms

A service hosted in the Manchester area:

$ ping -c 10 ae5-100-xcr1.man.cw.net
PING ae5-100-xcr1.man.cw.net (195.89.96.113): 56 data bytes
64 bytes from 195.89.96.113: icmp_seq=0 ttl=60 time=9.904 ms
...

--- ae5-100-xcr1.man.cw.net ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.194/9.976/10.692/0.382 ms

Did anyone else experience a similar behaviour? Did you manage to get it solved? How?

Thanks!

View more options
1 ACCEPTED SOLUTION

Accepted Solutions
KeithAlger
16: Advanced member

The dslgb network is mostly the interconnect between OpenReach and Vodafone. For the most part, it's rather opaque but it seems to be via a hub, rather than a dedicated link at the OpenReach local exchange level.  It's also worth noting that while it'll normally connect to the one data-center, if there are outages, it is diverted - with no apparent intermediate routing.

As for connecting to the bbc, the average ping from Teeside is 16ms, but it's worth being aware that there are fallbacks, parallel, and redundant servers in place, so we are almost certainly not all looking at the exact same server, possibly not even in the same location!

Regards the routing of Vodafone/CityFibre gigafast, it's going to be hard routed to a data centre.  At the moment that location for Milton Keynes would appear to the Manchester data centre.  That Manchester data centre has both connections to the UK backbone and to Vodafone/C&Ws parallel network, so everything that connects to Manchester does not then route through London (in fact very little international traffic does).  As for expecting a latency of 2-4ms latency on connections from Milton Keynes to London, those are unrealistic expectations, a congested local WiFi can add almost that much latency!

 

Pinging raspi2 [192.168.1.5] with 32 bytes of data:
Reply from 192.168.1.5: bytes=32 time=1ms TTL=64
Reply from 192.168.1.5: bytes=32 time=2ms TTL=64
Reply from 192.168.1.5: bytes=32 time=2ms TTL=64
Reply from 192.168.1.5: bytes=32 time=2ms TTL=64

 

View solution in original position

View more options
16 REPLIES 16
MarkD
Moderator

Hi @gerhardlazu 

Best option could be to speak to directly to our Gigafast team who can advise you on this. It’s free to call us on 191 from your Vodafone mobile or 03333 040 191 from other UK landlines or mobiles (standard call charges apply). Lines are open Monday to Sunday 8am - 8pm.

 

Let us know how you get on 🙂

View more options
clint_flick
11: Established

Hi

 

PING ms 461 DOWNLOAD Mbps 25.76 UPLOAD Mbps 0.86 Perth

PING ms 20 DOWNLOAD Mbps 33.99 UPLOAD Mbps 18.21 Lancaster

 

C:\>ping bbc.co.uk

Pinging bbc.co.uk [151.101.128.81] with 32 bytes of data:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Minimum = 20ms, Maximum = 20ms, Average = 20ms

 

C:\>tracert bbc.co.uk

Tracing route to bbc.co.uk [151.101.128.81]
over a maximum of 30 hops:

1 2 ms 2 ms 1 ms vodafone.broadband [192.168.1.1]
2 15 ms 16 ms 15 ms host-212-158-250-32.dslgb.com [212.158.250.32]
3 15 ms 15 ms 15 ms 63.130.140.126
4 19 ms 19 ms 19 ms 195.2.23.85
5 19 ms 19 ms 21 ms ae36-xcr1.lns.cw.net [195.2.25.170]
6 19 ms 19 ms 27 ms ae1-xcr1.ltw.cw.net [195.2.24.125]
7 19 ms 19 ms 19 ms 23.235.41.84
8 20 ms 21 ms 20 ms 151.101.128.81

Trace complete.

 

Maybe double check with another tracert?

 

But I am intrigued as to my Point Of Presence, where I enter and leave the network.

 

View more options
KeithAlger
16: Advanced member

The dslgb network is mostly the interconnect between OpenReach and Vodafone. For the most part, it's rather opaque but it seems to be via a hub, rather than a dedicated link at the OpenReach local exchange level.  It's also worth noting that while it'll normally connect to the one data-center, if there are outages, it is diverted - with no apparent intermediate routing.

As for connecting to the bbc, the average ping from Teeside is 16ms, but it's worth being aware that there are fallbacks, parallel, and redundant servers in place, so we are almost certainly not all looking at the exact same server, possibly not even in the same location!

Regards the routing of Vodafone/CityFibre gigafast, it's going to be hard routed to a data centre.  At the moment that location for Milton Keynes would appear to the Manchester data centre.  That Manchester data centre has both connections to the UK backbone and to Vodafone/C&Ws parallel network, so everything that connects to Manchester does not then route through London (in fact very little international traffic does).  As for expecting a latency of 2-4ms latency on connections from Milton Keynes to London, those are unrealistic expectations, a congested local WiFi can add almost that much latency!

 

Pinging raspi2 [192.168.1.5] with 32 bytes of data:
Reply from 192.168.1.5: bytes=32 time=1ms TTL=64
Reply from 192.168.1.5: bytes=32 time=2ms TTL=64
Reply from 192.168.1.5: bytes=32 time=2ms TTL=64
Reply from 192.168.1.5: bytes=32 time=2ms TTL=64

 

View solution in original position

View more options
gerhardlazu
3: Seeker

From previous experiences, it's the type of support query that goes nowhere. I'll give it a go though, thanks!

View more options
gerhardlazu
3: Seeker

Even though this is not the solution, as the forum software claims, it's the best answer with the most detail - thank you!

Here's an mttr of ~1300 pings to 216.58.205.35 (google.co.uk):

 Host                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. unifi.localdomain                0.0%  1294    0.1   0.1   0.1   0.4   0.0
 2. 192.168.101.1                    4.4%  1293    0.6   0.5   0.3   5.8   0.3
 3. 84.65.128.1                     21.1%  1293    9.5   9.4   8.1 200.2   7.3
 4. 63.130.127.221                  37.0%  1293   16.9  16.2  15.0  17.6   0.4
 5. 90.255.251.18                   36.0%  1293   16.2  16.7  15.2 100.6   3.8
 6. 74.125.242.97                   41.9%  1293   17.3  17.5  15.9  69.6   1.9
 7. 172.253.71.191                  36.0%  1293   16.8  16.4  15.3  17.3   0.3
 8. lhr48s23-in-f3.1e100.net        40.4%  1293   16.8  16.3  15.1  21.5   0.4

This shows:

  • 0.6ms LAN latency (wired connection) - unifi.localdomain (Unifi router) & 192.168.101.1 (Vodafone modem)
  • 9.4ms latency to 84.65.128.1, which is a Vodafone gateway in Crewe and adds the most latency (8.8ms) - this is the hop up to Manchester
  • 16.2ms latency to 63.130.127.221, which is a hop inside the Vodafone network and adds the second most latency (6.2ms) - I am assuming this is the hop down to London
  • 16.7ms latency to 90.255.251.18, also a hop inside the Vodafone network with minimal latency - the edge of the Vodafone network
  • 17.5ms latency to 74.125.242.97, which is the entry point to Google's network in the London Heathrow area, most likely one of the Staines data centres

Notice how average latency decreases after packets enter the Google network, as does stddev. Vodafone Manchester gateway (84.65.128.1) has the most stddev, at 7.3ms, as does what I think is the Vodafone London gateway (90.255.251.18), at 3.8ms. They are by far the most congested hops, as hinted by the 200ms & 100ms slowest pings. The Google gateway is third most loaded, with 70ms slowest pings, but that's to be expected given the amount of traffic that it serves.

 

This is how packets travel currently:

Milton Keynes (Vodafone) -> Crewe (Vodafone) -> London (Vodafone) -> WHEREVER

 

This is how I would expect packets to travel:

Milton Keynes (Vodafone) -> London (Vodafone) -> WHEREVER

 

While 2-3ms is unrealistic, 5-6ms would be a reasonable expectation given the above measurements.

View more options
clint_flick
11: Established

Hi

A decade ago, or a dozen years even, I may have been more helpful.....

https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/network/3-8/reference/guide/routpro.html

 

The routing protocols are kinda the metric for this. I thought OSPF myself.

SHORTEST PATH FIRST is an OPEN standard (OSPF) and in theory runs a stopwatch on the time to each/next hop and chooses the one with the lowest time, think Virgin Media and Usain Bolt, rather than Mo Farrer.

 

Since they have no need of human intervention once setup, the route your packets take is variable.

 

 

 

View more options
gerhardlazu
3: Seeker

As a last update, a few weeks after I posted this, the issue fixed itself. Thank you. I'm currently averaging 5.9ms to google.co.uk:

 

                                     Packets       Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. unifi.localdomain                 0.0%  1747    0.1   0.1   0.1  25.0   0.8
 2. 192.168.101.1                     6.8%  1747    0.7   0.6   0.3  11.3   0.4
 3. 84.65.0.1                        17.7%  1746    5.7   5.5   4.2  30.3   1.1
 4. 63.130.127.213                   37.6%  1746    6.1   5.8   4.4  13.9   0.5
 5. 90.255.251.18                    38.7%  1746    6.0   6.6   4.7 123.7   6.2
 6. 74.125.242.65                    38.6%  1746    5.0   6.2   4.8  13.6   0.7
 7. 172.253.50.223                   38.1%  1746    7.3   6.9   4.8  16.6   0.9
 8. dub08s01-in-f163.1e100.net       38.3%  1746    6.0   5.9   4.3  47.7   1.4
View more options
purrbox
2: Seeker
View more options
purrbox
2: Seeker
View more options
KeithAlger
16: Advanced member

The last couple of responses here literally made me face palm!

 

Vodafone have a pool of IP addresses that they can issue from, thanks to historic reasons these IPs are arbitrarily allocated to a multitude of different locations.  However, your IP address is issued to the network hardware which your equipment connects to at the datacentre you are routed through.

 

So you could get one of Vodafone old Mumbai IP addresses, but your data would not be routed through Mumbai, but one of Vodafone's UK datacentres.  It's very similar to how your home router allocates dynamic local IP addresses!

 

*There is an amount of virtualising going on here too.  So the last time your data is in its own wire is when it hits the OpenReach cabinet - for FTTP it's even shorter being the ONT/PON!

View more options
purrbox
2: Seeker
View more options
gerhardlazu
3: Seeker

I'm glad that others are finding this post useful.

 

I am sharing my current setup, which is working pretty well. After the high latency problem solved itself, I've hit another, far worse problem: high packet loss. I've captured that experience here: https://forum.vodafone.co.uk/t5/Broadband-connection/gt-50-packet-loss-and-a-bad-experience-overall/...

 

After removing the Vodafone-supplied router from my network, everything started working well. Right now, I have no packet loss, and the latency isn't too bad either. I had an mtr to google.co.uk running most of the day, and this is the result:

 

# mtr google.co.uk
                                     Packets               Pings
 Host                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. unifi.localdomain               0.0% 18780    0.2   0.1   0.1   1.0   0.1  # Unifi Router
 2. 84.65.192.1                     0.0% 18780    7.5   7.4   7.0  57.0   0.8  # Tamworth, Staffordshire (Vodefone entry)
 3. 63.130.127.221                  0.0% 18780   10.8  11.0  10.6  31.2   0.7  # Vodafone Network
 4. 90.255.251.18                   0.0% 18779   12.1  11.4  10.7 188.8   7.5  # Vodafone Network (Vodafone exit)
 5. 74.125.242.65                   0.0% 18779   13.4  12.1  10.8  20.8   0.9  # Google Network (Google entry)
 6. 142.250.215.125                 0.0% 18779   12.1  11.1  10.7  21.2   0.6  # Google Network
 7. lhr48s27-in-f3.1e100.net        0.0% 18779   13.1  12.3  11.9  21.9   0.6  # Google Network destination, hostname suggests London Heathrow

My worst latency to the Vodafone entry gateway is 57ms, and 7.4ms on average, which accounts for 60% of the total average latency to the final destination (12.3ms). The next hop within Vodafone adds an extra 3ms of latency to the average, and then the Google network adds an extra 0.2ms, for a total average of 12.3ms, as measured over 18779 pings. Yes, my network is fully wired with an average latency of 0.1ms.

 

In conclusion, having experienced massive packet loss after my average latency to google.co.uk dropped to 6ms, I would pick 12.3ms from Milton Keynes to Heathrow and 0% packet loss any day.

View more options
purrbox
2: Seeker

Attention MK (and others with high pings on gigafast). 

Look at the 2nd hop on your traceroutes. Notice how it's around 10ms (it should be much less at this stage), that is the latency that is added before it's handed over from Cityfibre to Vodafone. That might not seem like a high number on it's own, but when you add that onto where you're actually pinging it is.

If you compare your gigafast (city fibre) line to a standard vodafone VDSL line you will always see an extra 10ms on your pings. Ping any server and this can easily be proven. Vodafone host their own speedtest.net server so the pings should be 2 - 3 ms but because of the CityFibre issue they are always > 10ms 

I've spoken with an engineer at City Fibre and even he agreed there is clearly an issue, the problem is they can't work on it until Vodafone 2nd line support issue City Fibre with a ticket.

 

As the issue is within City Fibre's network (before it gets handed off to the Vodafone gateway), there's nothing Vodafone can really do apart from send support tickets to City Fibre. 


Please people, encourage everyone to get this escalated. This isn't going to fix the routed by Manchester issue but it will fix the additional 10ms problem, which by looking at your trace routes you all seem to have.

 

I'm sure most people are fine with an additional 10ms, but I personally do a job that requires less than 13ms to the server and I'm sure the gamers here will agree 10ms is a very welcome reduction. On top of this, you upgrade from DSL to FTTH and expect to see lower pings, not higher. Further to this, City Fibre has a whole mission statement on how reducing latency is one of their core objectives of their product, so it's not unreasonable to request this be fixed. In 2021, it's not unreasonable to demand hops from Milton Keynes to Milton Keynes should be a lot less than 10ms, especially when Vodafone seem capable of getting us from MK to telehouse in less than 3ms.

purrbox_1-1625919106963.png

p.s. If you're wondering why I deleted my prior posts, it's because they contained incorrect advise about static IP's.

View more options
KeithAlger
16: Advanced member

I think you are being completely unrealistic regards your expectations - the only way you are going to guarantee a sub 13ms (0.013 sec) connection to a server is to be sat in the same room as that server and connected to the same LAN.

 

Primer on Latency and Bandwidth

View more options
purrbox
2: Seeker

@KeithAlger wrote:

I think you are being completely unrealistic regards your expectations - the only way you are going to guarantee a sub 13ms (0.013 sec) connection to a server is to be sat in the same room as that server and connected to the same LAN.

 

Primer on Latency and Bandwidth


That link you posted is not only nearly ten years out of date but draws it's sources from even older articles. If 13ms to a server was normal (like you say) we would all have pings of > 50ms to our destinations. 

 

Here is a ping to cloudflare, even with the city fibre issue I still get sub13ms. On vodafone standard VDSL (FTTC) the pings to cloudflare are around 4 - 5 ms. It's not normal to have this level of latency inside City Fibre and they have agreed there is an issue.

 

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=13ms TTL=58
Reply from 1.1.1.1: bytes=32 time=12ms TTL=58
Reply from 1.1.1.1: bytes=32 time=13ms TTL=58
Reply from 1.1.1.1: bytes=32 time=13ms TTL=58

Ping statistics for 1.1.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 13ms, Average = 12ms

 

Here is another ping to Google.com, again clearly showing less than 2ms between most hops. If 13ms the best we could hope for, pings to Google.com would be > 70ms. This may have been true 20 years ago, but it isn't today. 

 

1 1 ms <1 ms 1 ms RT-AX92U-6090 [192.168.50.1]
2 9 ms 9 ms 9 ms 90.247.192.1
3 12 ms 84 ms 11 ms 63.130.127.221
4 11 ms 11 ms 11 ms 90.255.251.18
5 12 ms 12 ms 12 ms 74.125.242.97
6 12 ms 12 ms 11 ms 108.170.234.231
7 12 ms 12 ms 12 ms lhr48s29-in-f4.1e100.net [142.250.200.4]

 

As per my previous post, I am not complaining about Vodafones network, it offers very low latency. But the issue at City Fibre means our gigafast lines are at a disadvantage compared to standard broadband. I'm hopeful that City Fibre will be able to fix this. I've seen other City Fibre lines in Milton Keynes that don't suffer from this issue. The City Fibre engineer did mention about ports that the ONT box is connected to or the routing inside their internal network as possible causes. As end users, those additional hops are hidden from our trace routes.

View more options
cr4zy
1: Seeker

Yeah this is something I noticed upon switching too. I moved from a 80/20 connection that worked pretty flawlessly to vodafone/cityfibre 500/500 and I can't fault the speeds or performance (weirdly enough until tonight I had never had a single disconnect that I was aware of, tonight I have had two... which is how I ended up here)

 

I log a lot of info here's my ping graph for the past year, it's pretty obvious when I switched over from copper to FTTP and well, you'd think it'd get better.

 

This is from Peterborough, i've been conncted to Manchester, Leicester, Birmingham and some others. Would be neat to be connected locally and probably cut a few ms of pointless hops out of the loop.

 

switch.png

View more options