Possible routing issue affecting League of Legends BR match connections (VPN routing works)

[Pedro92]

From Canada, I can launch the League of Legends client normally, but I’m unable to connect to matches on the Brazilian server. When a match starts, the game transitions to a black screen and never completes the connection. This happens consistently, at all times, and has been ongoing for over six months.

The key observation is that the issue is immediately resolved when I route traffic through a Canadian VPN endpoint (NordVPN). With the VPN enabled, matches load and play normally. Without the VPN, match connections consistently fail.

Additional context:

• In the past, traceroutes showed traffic being routed through the United States and India before failing

• Riot Games appears to host its match infrastructure on AWS, which uses dynamic IP addressing and load balancing, so destination IPs change per session

• Because of this, I’m unable to provide fixed destination IPs or consistent traceroute results

Based on the consistent behavior and the VPN workaround, this appears to be a routing or peering issue affecting the path from Bell’s network to Riot Games’ AWS-hosted Brazilian match servers, rather than a client-side issue.

I’d appreciate any insight from the Bell team on:

• Whether this could be related to Bell’s international routing or upstream providers

• If there is a recommended escalation path for review by a network or peering team

• Any additional information that would help with investigation

Thank you for your time and assistance.

[Pedro92]

The match services are not the same though. Remember that each shard has their own ping and other things? They are all under AWS services but they are LOCAL to each region. Like the LATAM one is in Chile despite being for all latin america countries. And so on for each, like NA is in US not Canada. So yeah, there is the difference, it's where the matches are (which are different from the client. As far as I am aware, the client connects always to NA server, to centralize account data)

Am pretty sure it's just route issues. Last time I checked, back when it started, the route was going to a company in India before stopping and I was always like: why the heck is it going overseas instead of just going down through America?

Could always be a relay from that company not in India as well. But yeh, the current issue is kinda crazy that works with VPN or Rogers and just Bell is affected.

[GabNic]

Hello, I am having the same issue and I've been trying to fix it for a very long time. Surprisingly, my VPN (Surfshark) does not work and the worst part is that a few months ago it was working normally. Just out of nowhere, something Bell changed and now it's completely blocked. 

Any news on this ?

[Pedro92]

Gab, for now, we are still waiting on Bell to schedule to do some testing with us. What I use is NordVPN, you can try that one. I know a friend uses the McAfee one (and is free, if I am not mistaken). You can try using those on TFT, the single player version (last option on TFT) to check if it works for you without compromising your game. Hope it helps for now!

[GabNic]

Thank you. I will try a different service then. What infuriates me more in this case is the fact that a few months ago it was working fine and out of nowhere it just doesnt work anymore and the fact that it works with Rogers is all the more weird. It's almost like I am being forced to switch providers to have access to what I want.

[dks]

Internet routing is neither predictable nor stable. That is a foundational principle. Routing is dynamic. It is also unrelated to the provider. 

[Pedro92]

---

@dks wrote:

Internet routing is neither predictable nor stable.

---

FALSE. While routes can change due to many reasons like congestion or to mitigate DDoS (and other reasons), it does NOT mean it's chaotic or unpredictable. Most routes are very stable for long period of times, even years. Large networks carefully engineer routes to be deliberately predictable while operators rely on this stability for perfomance, SLAs and troubleshooting.

---

@dks wrote:

That is a foundational principle.

---

---

FALSE. Foundational principle of internet routing does NOT have unpredictability as principle. Resilience is. Changes happen to PRESERVE connectivity, not to embrace chaos. Other principles are Policy-based routing. Redundancy and fault tolerance, Decentralized control and Best-path selection.

@dks wrote:

Routing is dynamic.

---

TRUE, BUT that does not mean random or unstable. Dynamic when needed, stable when possible.

---

@dks wrote:

It is also unrelated to the provider. 

---

FALSE. Routing is HEAVILY influenced by providers. ISPs control: BGP policies, peering agreements, transit relationships, traffic engineering decisions. Different providers can give different paths to the same destination (this is why Rogers service reaches our destination while Bell isnt). Some companies network explicitly use provider diversity to control routing. ISP is one of the strong determinants of your internet path.

[GabNic]

So, with all that being said (and thank you for the enlightenment, I didn't know any of that) is it fair to assume that Bell will just shake their shoulders and give no care's to our current problem? It's almost like every single time I get a response from the other side is them saying "not my problem". 

I'll have to really start thinking about changing ISPs then. I can't rely solely on NordVPN (which btw, worked. thank you very much), because one day RIOT can just decide to say NOPE to it.

[Jessey]

regarding a routing and latency issue that is occurring within the Bell network. I have already performed extensive local

troubleshooting, and the issue is not on my side.

My local connection from my PC to my modem (Hop 1) and the first ISP gateway (Hop 2) is healthy, with latency under 2ms. However, 1 am seeing massive latency spikes jumping from 150ms to over 350ms starting at Hop 5 and Hop 6.

Specifically, the bottleneck is occurring at Bell's internal nodes:

142.124.127.112 and 142.124.127.63.

Since I have 0% packet loss, this is a congested routing path or a degraded node issue within your core network. I would like a network engineer to review the routing for these specific IP addresses.

i have been doing multiple test and called bell and they updated the software of my modem and rebooted it, it helped the ping on google servers 8.8.8.8 but i am still not able to play online game like valorant, league of legend or battle field 6.

[Vanadiel]

If the destination would be unreachable, you would get a reply with the following results. If you are not getting this ICMP reply back, then the network is reachable.

• Code 0 – Network Unreachable: The router cannot reach the destination network. 

• Code 1 – Host Unreachable: The final router on the path cannot reach the specific host (e.g., no ARP reply). 

• Code 3 – Port Unreachable: The destination host received the packet but the target port or service is not active. 

• Code 4 – Fragmentation Needed and DF Set: The packet is too large and the "Don't Fragment" bit is set.

[dks]

Thank you for your comments. I simply have decades of experience with gaming and internet. You have much greater knowledge.  

[dks]

As consumers, we are always free to find resources which meet our needs. 

[GabNic]

the perfect reply to a problem. hands clean. 

[Vanadiel]

Without a traceroute, it's hard to visualize what is happening.

Common methods of interpreting the values are:

Increasing latency towards the target

If you see a sudden increase in a hop and it keeps increasing to the destination (if it even gets there), then this indicates an issue starting at the hop with the increase. This may well cause packet loss where you will even see asterisks (*) in the report.

  1    10 ms     7 ms     9 ms  172.16.10.2
  2    78 ms   100 ms    32 ms  ip10-167-150-2.at.at.cox.net [70.167.150.2]
  3    78 ms    84 ms    75 ms  100ge7-1.core1.nyc4.he.net [184.105.223.166]
  4   782 ms   799 ms     * ms  10gr10-3.core1.lax1.he.net [72.52.92.226]
  5     * ms   899 ms   901 ms  10g1-3.core1.lax2.he.net [72.52.92.122]
  6   987 ms   954 ms   976 ms  205.134.225.38
  7  1002 ms  1011 ms   999 ms  www.inmotionhosting.com [192.145.237.216]

High latency in the middle but not at beginning or end

If the hop immediately after a long one drops back down, it simply means that the router at the long hop set the signal to a lower priority and does not have an issue. Patterns like this do not indicate an issue.

1  <1 ms     <1 ms       <1 ms 173.247.246.116
2  30 ms      7 ms       11 ms 10.10.0.2
3 200 ms    210 ms      189 ms 4.71.136.1
4 111 ms     98 ms      101 ms ip10-167-150-2.at.at.cox.net [70.167.150.2]
5  99 ms    100 ms       98 ms  205.134.225.38

High latency in the middle that remains consistent

If you see a hop jump but remain consistent throughout the rest of the report, this does not indicate an issue.

1  <1 ms     <1 ms       <1 ms 173.247.246.116
2  30 ms      7 ms       11 ms 10.10.0.2
3  93 ms     95 ms       92 ms 4.71.136.1
4  95 ms     99 ms      101 ms ip10-167-150-2.at.at.cox.net [70.167.150.2]
5  99 ms    100 ms       98 ms 100ge7-1.core1.nyc4.he.net [184.105.223.166]
6  95 ms     95 ms       95 ms 10g1-3.core1.lax2.he.net [72.52.92.122]
7  95 ms     96 ms       94 ms 205.134.225.38]

High latency in the beginning hops

Seeing reported latency in the first few hops indicates a possible issue on the local network level. You will want to work with your local network administrator to verify and fix it.

[Pedro92]

I do agree traceroutes are useful, but after having done many and the amount of ips connecting to the game are a lot, many people wont be able to do a traceroute because they dont know where they are trying to aim towards. You can not ask a traceroute out of everyone and expect them to even know the address they want to reach. While I did have some idea where to find it, does mean the other two with the same issue know the same.

[GabNic]

I'm not nearly as knowledgeable as you guys for the matter and this thread is honestly my only hope. I am here trying to add numbers to the matter to see if this gets the proper attention from someone from Bell to fix the problem because I do believe in that since a couple of months ago it was working normally.