BGP is the protocol networks use to exchange reachability information between autonomous systems. An autonomous system is a network or group of networks operating under a routing policy, identified by an AS number. For hosting customers, these concepts help explain why the route to an unchanged server IP can change without the server moving.
The terms behind a route discussion
| Term | Meaning in this context |
|---|---|
| Prefix | A range of IP addresses advertised as reachable |
| ASN | An identifier for an autonomous system |
| AS path | Routing information describing autonomous systems traversed by an advertisement |
| Peering | A relationship for exchanging relevant traffic between networks |
| Transit | A service providing reachability through another network |
| Routing policy | Rules influencing which routes a network accepts, prefers or advertises |
Why the shortest geographic path may not be used
Routing decisions include policy and advertised path attributes; they are not a global calculation of the lowest game ping. A physically nearby city can have an indirect route from a particular ISP. A shorter AS path also does not necessarily mean fewer kilometers or lower congestion.
Each network controls its own decisions. The path toward a server can differ from the return path toward the player. A traceroute in one direction therefore does not fully describe the round trip, and the hosting provider may not control every segment that contributes to latency.
What can cause a route to change?
A link failure, maintenance, an advertisement change or a policy adjustment can alter the selected path. Convergence is the process by which networks react to updated reachability. During a transition, some users may see different behavior from others because their networks select different routes.
How to collect useful evidence for a hosting issue
- Record the destination IP, protocol/port, affected source network and exact UTC interval.
- Confirm the application symptom and whether multiple users or regions reproduce it.
- Collect route/latency evidence during the problem and, if possible, a healthy interval.
- Compare IPv4 and IPv6 separately when both are used.
- Provide text reports and service context to support rather than attributing fault from one hop alone.
Use the MTR guide to distinguish diagnostic response loss from loss continuing to the destination. A router that answers probes slowly may still forward traffic normally. BGP route information and packet-level observations describe different layers and should be interpreted together.
What an ASN does not prove
An ASN is not a performance score, an uptime guarantee or proof that a provider owns every facility in a route. Likewise, a long list of peers does not establish the path from your players’ ISPs. Ask for relevant test endpoints and compare the paths your users actually take.
If your requirement involves announcing your own prefixes or using a routing session, confirm whether the service supports that arrangement and what operational prerequisites apply. An ordinary VPS address does not automatically include BGP control.
Review EnderHost network locations alongside latency diagnostics. Use anycast versus unicast to understand another reason the same destination address may reach different infrastructure.
Sources and references
Hosting documentation. Publication and update dates reflect this edition.
Related articles
- How to Read MTR Results Without Mistaking ICMP Loss for an OutageSeparate router reply limits from end-to-end loss and collect a useful network report for a hosting investigation.3 min read
- Anycast vs Unicast: What It Means for Game Server LatencySeparate the route to a distributed ingress from the location and state of the game simulation behind it.3 min read
- Diagnosing latency and lagTell a network problem apart from a server performance problem.1 min read
