FTTP – Routing via Marseille (mrs20) – 280ms latency to Xbox Cloud / Azure – IP 147.147.130.x

[#1]

No problem, @Dan_the_Van 

We'll post any updates/findings here.

James

[#2]

Hi @Emeric 

Welcome to the forum.

This is definitely an odd one, I don't think we have much control over which site Microsoft would have you connect to and the geo-IP companies can be a bit odd in how they map IPs to regions/cities.

There are around 2500 routers dotted around the country that our customers connect to in big towns and cities and generally you'll connect to a device in your nearest big town or city. We assign IP addresses to these devices in blocks of 128 which often why when you disconnect/reconnect you get a similar IP address but because most of these routers have more than 128 customers you will sometimes get an IP from another range. Generally the IPs are fixed to a device but they can move from time to time, this can then result in the Geo-IP data being wrong, the IP you had may have recently been in Edinburgh but not updated with the new location yet because there's many ways the Geo-IP companies get the data and most aren't real time.

Oddly you'd think Edinburgh would definitely be UK rather than France.

A couple of questions, are you playing on an Xbox or PC? If Xbox, are you able to compare on a PC? If you see the same on a PC then a netstat output and Wireshark capture while seeing the problem would be really useful if you're able to get them.

I can see if I can find a way of investigating this with Microsoft, I'm also wondering if we try a different IP address with you and see if that makes any difference.

[#3]

@James_B  - thank you for the push - this had “odd ball” written all over it!!

@dave - thank you for running with this … does the linked to thread (see post #5) have any similarity?

[#4]

@dave 

Can you inform my ignorance please: where DNS offers multiple IP addresses (which might be anywhere) which component decides which IP address to use and how is the choice made?

My expectation is the component which requested the resolution - in which case it’s either Hobson’s choice or there needs to be logic to determine the “shortest path” IP addresses.

[#5]

Hi Dave,

Thanks very much for your detailed explanation and for looking into this.

I’m playing on PC (Windows 10) via https://www.xbox.com/play in Microsoft Edge, though the same latency occurs if I test with the Xbox app.

My current public IP is 194.75.95.xxx, and I consistently see traffic to Microsoft routed through mrs20.ntwk.msn.net (~250 ms), whereas other services like Google stay at ~9 ms.

I’m happy to run a Wireshark capture or netstat output while the issue occurs — just let me know what duration or filters would be most useful.

I’d also be happy to test again if you assign a different IP / BNG to check whether the routing changes.

Thanks again for taking the time to investigate this and for offering to liaise with Microsoft if needed.

[#6]

@Townman the streaming issue on the other thread makes it sound different. Even if you'd been directed to a gaming server in Fiji instead of the UK it should just be the game that's poor and not affect other traffic. @Emeric I presume other traffic is the fine for you when the gaming is poor, again worth double checking if you can.

Generally when you get multiple IPs from a DNS lookup it will use whatever is first I think, most people have 2 DNS servers configured on the router and you more often see that the router sends the request to both and then uses whichever arrives back first.

@Emeric I probably only need a minute or so of the gaming traffic and it probably just needs to be to and from the gaming server(s). It's hard to say what I expect to see but it should confirm the IPs of the gaming server as well as the protocol and maybe if there's out of sequence packets, transmits etc. For netstat then to start with just a plain "netstat" will do.

280ms sounds high even to the south of France, I like this site as it shows the pings to different places around the world:

https://wondernetwork.com/pings/London

Marseille is only 17ms https://wondernetwork.com/pings/London/Marseille

Even if we add on the overhead of getting to you we know that's no more than 9ms really because of the Google response so at worse I'd expect less than 30ms so something else could be amiss here.

Not sure you can add a Wireshark here or to our Member Centre so I'll send you a private message with my email address to send it over.

[#7]

@dave 

Thank you for the illumination.  TImely it was, as I had just done my own research now I'm back at my desk.  I think that the answer is less than clear, but there are a few suggestions out there...

domain name system - How do DNS clients choose an IP address when they get multiple answers? - Serve...

A DNS server resolving a query, may prioritize the order in which it uses the listed servers based on historical response time data (RFC1035 section 7.2). It may also prioritize by closer sub-net (I have seen this in RFC but don't recall which). If no history or sub-net priority is available, it may choose by random, or simply pick the first one. I have seen DNS server implementations doing various combinations of above.

A client program picking an IP address from a list (of A/AAAA-records) will generally try the addresses in the order they where returned by the DNS server (round robin). If the client cannot connect to the first IP address returned, it should try the second and so on. For example all major browsers do this, however many other Internet client programs "forget" this step and fail if they cannot connect to the first IP address.

...

As far as the answers go, Most DNS clients will use the first IP address in the list, some do subnet calculations to figure out which is closer, others choose randomly, but most depend on the DNS server to send the list.

...

It depends on the client - of particular relevance for anybody running a Windows shop is the fact that Vista\Windows Server 2008 will choose the address using a different mechanism (if the ipv6 stack is installed) to earlier Windows versions which would choose the first address. In many cases this means they will always choose the same one ie they won't "honor" DNS round robin responses in the same way as the earlier versions. There is a detailed explanation of this in this technet blog article.

I conclude that there is no clear mechanism but ...

@Emeric 

I was intrigued by the implication that different browsers might do this differently.  Do you have a browser other than MS Edge installed with which you can do a comparative test?

Again thinking outside the box, there could be merit in setting one of the more responsive IP addresses as a fixed resolution in the hosts file to see if that changes your experience.  If it does then for sure we have a route related issue; if it does not then the problem is elsewhere.

[#8]

Quick update — after the IP reassignment, my routing is now through London (lon04 → lon22) and Amsterdam (ams30) with latency around 17–20 ms, so the Marseille detour has definitely been fixed.

I’ll test the Xbox Cloud Gaming performance over the next couple of sessions and confirm how it feels in real gameplay before closing the thread.

Many thanks to Dave Tomlinson for the quick and very effective help, and to James_B, Townman, and others for the support and escalation.

— Emeric

[#9]

@dave  though @Emeric has a personal solution (not clear how they got a different IP address) does there remain an issue to be investigated?  Indeed can it still be investigated?  What happens when someone else gets the same dynamic IP address?

If @Emeric was facilitated a ”diagnostic” static IP address, might they be at risk of getting an IP address from the same pool, when the diagnostic address is removed?

[#10]

That’s a very good question. From what I understand, Dave allocated me a different IP range as a diagnostic step to check if the routing anomaly followed the address or the line.

The new IP (84.92.127.x) immediately corrected the route — now going through London → Amsterdam with ~17–20 ms latency — whereas both previous ranges (147.147.130.x and 194.75.95.x) consistently went via Marseille (~250 ms).

This strongly suggests that the older IP blocks are still mapped to the wrong Azure region in Microsoft’s databases, so anyone issued one of those could encounter the same problem until Microsoft or Plusnet update the Geo-IP / peering data for those ranges.

My understanding is that the new address isn’t static, just from a different dynamic pool, but it would be good if Plusnet could confirm whether the affected ranges remain in circulation and if a permanent fix is planned.

— Emeric

[#11]

I suspect that’s in the static pool: mine is 84.92.100.0

[#12]

I'd say sticky rather than static because it's from one of our static ranges but it might change at some point.

[#13]

@dave 

Could this be related: https://community.plus.net/t5/Gaming/xbox-cloud-gaming/m-p/2025574#M20170