I'm seeing high rate of packet loss to 220.127.116.11.
Can you please check on this and advise?
Tracing route to ovh.net [18.104.22.168]
over a maximum of 30 hops:
1 2 ms <1 ms <1 ms 192.168.1.1
2 35 ms 35 ms 11 ms 22.214.171.124
3 10 ms 14 ms 9 ms te-8-3-ur02.boulder.co.denver.comcast.net [68.85
4 12 ms 15 ms 11 ms te-0-10-0-10-ar02.aurora.co.denver.comcast.net [
5 13 ms 15 ms 11 ms he-3-10-0-0-cr01.denver.co.ibone.comcast.net [68
6 33 ms 35 ms 43 ms he-5-12-0-0-cr01.350ecermak.il.ibone.comcast.net
7 37 ms 37 ms 34 ms he-0-12-0-0-pe04.350ecermak.il.ibone.comcast.net
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
Hello PR and welcome,
Apparently your ovh.net is not a comcast domain per the following:
|CNAME||No CNAME record found.|
|PTR||No PTR record found.|
So, you may want to make sure that this domain ports are open and whatever device you are connected to behind the Comcast Gateway are also opened. Perhaps you could share some additional detail wrt you network interconnect for some more detailed resolution inputs.
Thanks and look forward to hearing more from you.
Few things I see here. While it is possible for a hop to show as being timed out when large amount of loss occurs, it's generally more likely that the end server isn't accepting ICMP. You should allow that and re-run the test, but this time run an MTR. 500-1000 test is good enough.
It'd also be helpful if you could run one out the outbound(Server to you). Lastly, that specific IP range seems to be dedicated to OVH in France. You appear to be in the US. While GeoIP is pretty inaccurate it's decent for rough estimates.
So with that being said, I'd expect loss from the US to France under most conditions since ther are just so many ISPs/NSP's you need to go through to get to your destination. All it takes is one of those "hops" to have an issue.
Edit 1)I'd also recommend contacting OVH. They're pretty big and likely have the capability to reroute you(assuming the loss is on the outbound), if it's not they may be able to mess with their prepends to encourage traffic over a specific link, which may provide better service.
Though, in my experience, Comcast likes to dominate inbound/outbound routes for business class customers, sometimes it's for the best and others it's not.
Edit 2) Do keep in mind, loss is measured from the start point. So some loss in the middle of an MTR neccessarily isn't an issue. Generally you'll want to check the start and end points.
Great points you make hear in you last post. If you are referring to RFC 792 ICMP standard, then it would be imperative to insure that both sides are talking using ICMPv4 or ICMPv6 specifically, because that could be a root cause for connection problems.
Also, pertaining to your second point, if both devices were not using the same ICMPV4 or V6 then I would expect a start connect issue right up front with error display destination unreachable or datagram conversion error, for a couple instances.
Great stuff !