Routing, GRE Tunnels and Why Ping Isn't Distance

You moved the server to Frankfurt because most of your regulars are German. One of them lives in Munich, three hundred kilometres away, and sits at 48 ms. Someone in Warsaw, six hundred kilometres further out, gets 22. The Munich player is now convinced your host is rubbish, you are half convinced too, and you are pricing up a move you do not need.

Nothing here is unusual and nothing here is a hardware fault. Both of you are working from an assumption that has never been true: that a packet goes where the map says it should. It goes where a chain of commercial agreements sends it, and none of the parties involved has heard of your server.

The physics sets the floor. Light in fibre moves at roughly two thirds of its vacuum speed, about a millisecond of round trip per hundred kilometres, and fibre is never laid straight, so multiply by something like 1.4 for a real route. Munich to Frankfurt is four or five milliseconds of unavoidable distance. Your player is paying 48. The other forty-three are a routing decision.

Ping does not measure how far away your server is. It measures which networks agreed to carry your traffic, and where they chose to hand it over.

The guide on choosing a hosting region is the right place to start when you are picking a city, and you should still pick one. This is the part that comes after: why the map stops being the answer once you have chosen.

1. Packets follow money, not maps

The internet is roughly a hundred thousand autonomous systems — networks with their own numbers — announcing to each other which blocks of addresses they can reach. BGP is how they do it, and its decision process is not what people assume. A router picks a route by policy first, which is a business preference typed in by a human, then by AS path length, which counts networks crossed rather than kilometres travelled. Only much further down does anything resembling distance get consulted.

Nothing in that list is geography. A three-network path across an ocean beats a five-network path across town every time, because the tiebreaker is a hop count between companies. That is why two hosts in the same building can give your players different ping, and why moving a server 50 km can gain you 30 ms or cost you 30 ms with no way to tell which from the address.

2. Transit, peering, and the exchange in another country

Three arrangements move traffic between networks, and which ones your host has is worth more than its postcode. Transit is the one you buy: you pay a larger network to carry your traffic everywhere, and it is the fallback when nothing better exists. Settlement-free peering is a direct swap, each network carrying the other's traffic for its own customers with no money changing hands, which happens when the volumes are comparable enough that billing each other would be pointless. An internet exchange — DE-CIX, AMS-IX, LINX — is a shared switch fabric where hundreds of networks peer at once, and joining one is the cheapest way to shorten paths to a lot of destinations.

Now the case that produces your Munich player. Two ISPs in the same city, not peering directly, neither at a local exchange. Both buy transit. The nearest place their two transit providers actually exchange traffic might be Frankfurt, or London, or Amsterdam. Traffic between two houses on the same street crosses a border and comes back, and every kilometre of that detour lands on your player's ping.

Hot-potato routing makes it worse in a way that is easy to miss. A network handing traffic over normally does so at the exit nearest to itself, not the one nearest the destination, because it is cheaper to let the other network carry the packet the long way. So even where the outbound path looks sensible, the return path may leave the region immediately. This is not an edge case, it is the default behaviour of the commercial internet — and at the extreme, two large networks simply refuse to interconnect. Cogent and Hurricane Electric have declined to peer settlement-free for IPv6 since 2009, leaving parts of the IPv6 internet mutually unreachable across that boundary for well over a decade.

3. How to read a traceroute without fooling yourself

Almost every traceroute posted in a support ticket is misread, and the misreading always points at the wrong hop.

A traceroute does not measure the latency of the path at each hop. It measures how long a router took to generate a complaint about your packet expiring. That ICMP Time Exceeded message comes from the router's control plane — its CPU — not from the forwarding hardware carrying real traffic, and routers deliberately rate-limit and deprioritise those messages because generating them at line rate is itself an attack vector. A hop showing 180 ms, or 40% loss, while every later hop shows 22 ms and none, is a router being rude to you. It is not a problem on the path.

Three rules make traceroutes usable. Only the final hop measures the end-to-end path; everything above it measures a router's spare CPU. Loss is real only if it persists through every later hop including the last — loss that appears at hop 6 and vanishes at hop 7 is control-plane policing. And three probes is not a sample: use mtr --report --show-ips -w -c 100, or WinMTR on Windows, and let it run, because a path that is fine 97 times in 100 is exactly what players describe as "it randomly spikes". While you are there, read the hostnames — reverse DNS on carrier routers usually encodes the city, and strings like frnkge, lonuk or ashbva in the middle of a backbone hostname are where the detour becomes visible.

4. The return path is a different path

Routing is asymmetric by default and nothing forces the two directions to match. Your traceroute to a player measures the outbound half. Theirs to you measures the other. A 60 ms round trip can be 20 ms out and 40 ms back, and testing one direction shows you one of two problems.

This is why "my host checked and the route is fine" can be true and useless at once. The host controls its outbound path and has almost no influence over the path a player's ISP picks to reach it, beyond which transit and peering it makes available. So never diagnose a latency complaint from your own machine. Get an mtr from the affected player, running for several minutes, and one from your host's network back towards them. Most serious providers publish a looking glass — a page that runs ping, traceroute and BGP lookups from inside their network — and a test IP. Use both before you pay them anything.

5. What a GRE tunnel actually is, and what it costs

If your host sells filtered or DDoS-protected IPs, there is a fair chance your traffic goes through a GRE tunnel and nobody has mentioned it.

GRE is Generic Routing Encapsulation, defined in RFC 2784 and carried as IP protocol 47. It wraps a complete IP packet inside another one and sends it somewhere else. In filtered hosting the pattern is: the advertised, attackable address lives in a mitigation provider's network, traffic to it is scrubbed there, and the clean remainder is tunnelled to your real server, which may be in another city or another country. Your server sees clean traffic on a tunnel interface and knows nothing about the detour. This is a genuinely good answer to being attacked, and the guide to stopping DDoS on a small server covers when you need one. The bill arrives in three parts.

Hops and distance. Every packet now goes player → scrubbing centre → tunnel → server, and back the same way. If the scrubbing point of presence is in Amsterdam and your box is in Warsaw, every player pays that detour twice, permanently, including for all the time you are not under attack.

MTU. The encapsulation costs 24 bytes — a 20-byte outer IPv4 header plus a 4-byte GRE header. On an ordinary 1500-byte path that leaves 1476 for the real packet. Anything larger is fragmented on the way in, or dropped outright if the Don't Fragment bit is set.

Fragmentation. Fragments cost reassembly work, and plenty of mitigation setups drop IP fragments on sight because fragment floods are an attack technique. A fragmented packet there is not slow. It is gone.

The symptom is "works for most people, breaks for some"

That is the signature of an MTU problem and it is rarely recognised as one. Ping works, small packets work, most players are fine — but a handful cannot get past one specific point: a Minecraft client stuck on Joining world while chat still flows, a FiveM client that hangs on the same resource every time, a large payload that never lands. The people who break are the ones whose own path already has a reduced MTU — a PPPoE line, a mobile network, another tunnel — stacked on top of yours.

Two causes, usually together. The path MTU is below 1500 and nothing clamps for it. And the ICMP message that exists to announce exactly this, type 3 code 4 "Fragmentation Needed", is filtered by somebody's over-enthusiastic firewall, so Path MTU Discovery gets no feedback and black-holes. Blanket ICMP blocking is common bad security advice and this is the damage it does.

Find your real path MTU by hand: ping -M do -s 1448 <ip> on Linux sends a 1476-byte packet that must not be fragmented, ping -f -l 1448 <ip> on Windows. Walk the size down until it stops failing, then add 28 for the IP and ICMP headers. The fixes are small — set the tunnel interface MTU to 1476 or lower, clamp TCP with iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu (or a fixed --set-mss 1436 where the automatic version cannot see the real path), and stop dropping ICMP type 3.

One caveat that matters for games: MSS clamping only works on TCP, because MSS is a TCP option negotiated at connection setup. Minecraft's traffic is TCP, so clamping genuinely fixes it. Source engine and FiveM gameplay is UDP, where there is no handshake to clamp and the application has to keep its own datagrams small. Source exposes net_maxroutable, the size at which the engine splits its own packets rather than letting the network do it; the default sits around 1260, comfortably under a GRE tunnel, and lowering it is the nearest thing UDP has to MSS clamping.

6. What you can actually do about it

Buy the network, not the city. Ask which transit providers the host uses, which exchanges it sits on, and what its AS number is. A host on a single cheap transit in Frankfurt will serve your players worse than one in Frankfurt with three transits and a DE-CIX port. Both listings say "Frankfurt". Only one of them tells you anything.

Test both ways, from where the players are. Run traces from the provider's looking glass towards the address ranges your players actually use, and have players trace back. Your own connection is one sample from one ISP; five regulars in different countries running mtr through a normal evening is worth more than any provider's marketing figure. A host publishing neither a looking glass nor a test IP has told you how much it expects to be measured.

Take filtering only where you need it, and prefer it on-path. If your host filters at its own edge you pay nothing in extra hops. A GRE tunnel to a scrubbing centre elsewhere is a real answer to a real attack and a permanent latency tax on everyone else. So commit to this: if you are not being attacked regularly, do not buy tunnelled protection — it will make the ping worse. Buy it the week you need it, and check where the scrubbing point of presence sits first, because that location, not your server's, now sets your players' latency. The cost breakdown for running a server in 2026 is worth reading alongside this, since filtered bandwidth is usually the line item that moves.

Do not let routing absorb the blame for everything. Tick rate sets how often the server has anything new to send at all, and what tick rate really means is a separate budget. So is a stalling main loop — on FiveM that is more often the cause than the route is.

Finally, measure over time rather than in the moment. A single ping test at 3pm tells you nothing about a transit link that congests every evening, which is why readings taken every 15 minutes and kept hourly beat a one-off check — the methodology page sets that out for listings here and the logic applies to your own monitoring. If the problem turns out not to be latency at all but lists failing to see the server, that is a different mechanism: how server lists actually query you covers it. And on Counter-Strike 2, where a few milliseconds decides a duel, this work is worth doing properly rather than moving cities and hoping.