Yup - looks solid, and exactly what you'd hope to have happen.

What this doesn't do, though, is help understand the return route. If your provider has a peer that is bandwidth saturated but is the preferred provider by data coming from Embanet (but not *to* Embanet - these routes are determined independently), then you might still be getting packet loss at the boundary between your provider and that peer without seeing the problem when targeting other servers. This is the challenge with asymmetrical routing. I don't know if that's what's happening, but it's a credible scenario that makes it difficult to pin the problem on one host. This usually only happens in the short-term, though, because everyone figures out that one peer is saturated and starts asking for data to be prioritized to another peer.

It would be really nice to get a traceroute / PingPlotter dataset from the Embanet server back to you - this is usually not possible, but depending on the network situation at Embanet they may be able to do this with you. If the server is hosted in the same facility where support works, and they share a network, then this becomes possible. If the server is hosted in a datacenter with no other support machines available, it's a lot closer to impossible.

I'm kind of taking the provider's viewpoint here just to help you understand what they *might* be thinking so you can investigate more thoroughly.

- Pete