Skip to content
PR's profile

New Member

 • 

1 Message

Tuesday, April 1st, 2014 5:00 AM

Connectivity Problems through Comcast Router to 213.186.33.6

I'm seeing high rate of packet loss to 213.186.33.6.

Can you please check on this and advise?

 

Tracing route to ovh.net [213.186.33.6]
over a maximum of 30 hops:

  1     2 ms    <1 ms    <1 ms  192.168.1.1
  2    35 ms    35 ms    11 ms  73.252.68.1
  3    10 ms    14 ms     9 ms  te-8-3-ur02.boulder.co.denver.comcast.net [68.85
.107.197]
  4    12 ms    15 ms    11 ms  te-0-10-0-10-ar02.aurora.co.denver.comcast.net [
68.86.179.97]
  5    13 ms    15 ms    11 ms  he-3-10-0-0-cr01.denver.co.ibone.comcast.net [68
.86.92.25]
  6    33 ms    35 ms    43 ms  he-5-12-0-0-cr01.350ecermak.il.ibone.comcast.net
 [68.86.85.249]
  7    37 ms    37 ms    34 ms  he-0-12-0-0-pe04.350ecermak.il.ibone.comcast.net
 [68.86.83.162]
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.

Advocate

 • 

1.4K Messages

11 years ago

Hello PR and welcome,

 

Apparently your ovh.net is not a comcast domain per the following:

A213.186.33.6
 
MX5 mx2.kmx.ovh.net.
1 mx1.kmx.ovh.net.
 
CNAMENo CNAME record found.
 
NSdns11.ovh.net.
dns10.ovh.net.
ns10.ovh.net.
ns11.ovh.net.
dns15.ovh.net.
ns15.ovh.net.
ns12.ovh.net.
dns12.ovh.net.
dns13.ovh.net.
ns13.ovh.net.
 
PTRNo PTR record found.
 
SOA

dns10.ovh.net. tech.ovh.net
2014040276 86400 3600 3600000 600

 

 

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.

 

Problem solver

 • 

305 Messages

11 years ago

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. 

 

http://sourceforge.net/projects/winmtr/

 

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.

 

 

Advocate

 • 

1.4K Messages

11 years ago

Hey kraze,

 

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 !