When the route is bad
Latency that makes no sense, packet loss in one direction, a path that goes via somewhere strange. Because the routing is ours, this is fixable.
Measure before you conclude
A traceroute from one side tells half the story, because the path back is often a different one. Send us both:
- A traceroute (or better,
mtr --report --report-cycles 100) from your server to the affected destination. - The same from that destination back to your server's IP address.
- The time and the time zone, and whether it is constant or only at peak.
Reading it without panicking
Loss shown at one hop in the middle that does not continue to the end is almost always a router de-prioritising its own ICMP replies, not a problem. What matters is loss and latency that persists to the final hop. A single high hop in the middle is noise; a step up that stays high is a path.
What we can do
We buy from several carriers and run the routing ourselves, so when a path is congested or takes an odd detour we can steer your traffic over a different one. That is a change on our side, usually within the hour, and it does not require you to do anything.
This is the part that providers reselling someone else's transit cannot do: they can only forward your ticket and wait.
What we cannot fix
The far end. If the congestion is inside your visitor's own provider or at the destination network, we can route around it only when an alternative path exists. Sometimes it does not, and we will say so rather than keep you waiting.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base