-3

Update 2: Obviously, Comcast support's solution is to ask me to reboot the modem. They say they cannot answer more directly, because -- I kid you not -- tech support does not have access to the internet and cannot read this page.

Update: for those people who did not understand the question, let me spell it out in more detail:

  • "What might be the reasons why I'm losing about half of my ping packets on the way to the Comcast name server?"
  • And: "Why is there such a weird rectangular pattern to the packet loss?"
  • And more generally: "Has anybody seen this kind of pattern before anywhere (not just limited to Comcast) and found out what the problem was?"

Thanks to everybody who has provided insightful answers so far.

> ping 75.75.75.75   (Comcast name server)
PING 75.75.75.75 (75.75.75.75): 56 data bytes
64 bytes from 75.75.75.75: icmp_seq=0 ttl=59 time=12.262 ms
64 bytes from 75.75.75.75: icmp_seq=1 ttl=59 time=12.018 ms
64 bytes from 75.75.75.75: icmp_seq=2 ttl=59 time=11.671 ms
64 bytes from 75.75.75.75: icmp_seq=3 ttl=59 time=11.826 ms
64 bytes from 75.75.75.75: icmp_seq=4 ttl=59 time=13.569 ms
64 bytes from 75.75.75.75: icmp_seq=5 ttl=59 time=11.850 ms
64 bytes from 75.75.75.75: icmp_seq=6 ttl=59 time=12.059 ms
64 bytes from 75.75.75.75: icmp_seq=7 ttl=59 time=12.141 ms
64 bytes from 75.75.75.75: icmp_seq=8 ttl=59 time=12.418 ms
64 bytes from 75.75.75.75: icmp_seq=9 ttl=59 time=11.598 ms
64 bytes from 75.75.75.75: icmp_seq=10 ttl=59 time=11.607 ms
64 bytes from 75.75.75.75: icmp_seq=11 ttl=59 time=10.900 ms
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
64 bytes from 75.75.75.75: icmp_seq=21 ttl=59 time=13.082 ms
64 bytes from 75.75.75.75: icmp_seq=22 ttl=59 time=12.650 ms
64 bytes from 75.75.75.75: icmp_seq=23 ttl=59 time=12.920 ms
64 bytes from 75.75.75.75: icmp_seq=24 ttl=59 time=12.497 ms
64 bytes from 75.75.75.75: icmp_seq=25 ttl=59 time=17.745 ms
64 bytes from 75.75.75.75: icmp_seq=26 ttl=59 time=12.116 ms
64 bytes from 75.75.75.75: icmp_seq=27 ttl=59 time=12.211 ms
64 bytes from 75.75.75.75: icmp_seq=28 ttl=59 time=11.455 ms
64 bytes from 75.75.75.75: icmp_seq=29 ttl=59 time=11.393 ms
64 bytes from 75.75.75.75: icmp_seq=30 ttl=59 time=11.429 ms
64 bytes from 75.75.75.75: icmp_seq=31 ttl=59 time=11.624 ms
64 bytes from 75.75.75.75: icmp_seq=32 ttl=59 time=12.239 ms
64 bytes from 75.75.75.75: icmp_seq=33 ttl=59 time=11.702 ms
64 bytes from 75.75.75.75: icmp_seq=34 ttl=59 time=10.930 ms
64 bytes from 75.75.75.75: icmp_seq=35 ttl=59 time=11.987 ms
64 bytes from 75.75.75.75: icmp_seq=36 ttl=59 time=23.932 ms
64 bytes from 75.75.75.75: icmp_seq=37 ttl=59 time=14.720 ms
64 bytes from 75.75.75.75: icmp_seq=38 ttl=59 time=11.730 ms
Request timeout for icmp_seq 39
Request timeout for icmp_seq 40

etc.

It creates a really nice rectangular pattern on the terminal, each state about 7-20 lines long, so it's not totally regular. It's been like this for a while.

The only explanation I can think of is that some firewall guy somewhere had a great amount of fun.

If I traceroute to 75.75.75.75, I can ping any one of the hosts in between with 100% success.

Johannes Ernst
  • 1,097
  • 5
  • 17
  • 27
  • Looks like a route flap somewhere. It could be the far router losing routes back to you, then getting them again. But pings to the 2nd-to-last IP in the traceroute works OK? Are you pinging at a server or a router? – Skaperen Jul 28 '12 at 19:29
  • 1
    63% loss here . – Behrooz Jul 28 '12 at 20:21
  • @Skaperen: Pings to the 2nd-to-last IP in the traceroute is OK, as is for all others in the traceroute. How would the server vs router make a difference? I am pinging from the box behind my Comcast cable modem, and the behavior is the same for a MacBook and a Linux box configured as router. There's no other box between that an the Comcast modem. – Johannes Ernst Jul 29 '12 at 00:23
  • 1
    Sounds like a load balanced system where not all back-end systems respond ti pings, so it depends on just which server you're hitting with a particular packet, or group of packets. – John Gardeniers Jul 29 '12 at 00:27
  • @John Gardeniers: In this case I'd expect something less regular than what I'm seeing? There isn't really any session stickiness in ICMP is there? – Johannes Ernst Jul 29 '12 at 00:29

2 Answers2

3

I suspect firewall rate-limiting. In any case, who here is still using Comcast's DNS servers?

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
2

Just did a ping myself, the problem might not be yourself, but comcast:

--- 75.75.75.75 ping statistics ---
39 packets transmitted, 17 received, 56% packet loss, time 38189ms
rtt min/avg/max/mdev = 85.606/85.778/85.942/0.317 ms

Their servers might be under great stress resulting in a sort of DoS.

Lucas Kauffman
  • 16,880
  • 9
  • 58
  • 93