Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

closed as not a real question by Shane Madden, joeqwerty, Chopper3, Mike Pennington, Tom O'Connor Jul 28 '12 at 21:08

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

    
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 0: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 0: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 0:29

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer
    
Same here: 36 packets transmitted, 14 received, 61% packet loss, time 35121ms –  basvdlei Jul 28 '12 at 21:03
    
Thanks for confirming the mystery. I doubt the DoS because in that case I'd expect 1) a more random pattern, and 2) some different behavior over time. This pattern has been identical for several days. –  Johannes Ernst Jul 29 '12 at 0:22
    
Have you tried any other servers, like google (8.8.8.8 and 8.8.4.4) ? –  Lucas Kauffman Jul 29 '12 at 0:23
    
All other pings that I've tried work fine. E.g. the ones you suggest. –  Johannes Ernst Jul 29 '12 at 0:27
    
If google works, you have nothing to be scared of off :). Don't forget to accept an answer :) –  Lucas Kauffman Jul 29 '12 at 0:30

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

share|improve this answer
    
Good idea. But: the original ping was in 1-sec intervals. I re-ran it in 4-sec intervals. The timing is still the same, just fewer lines per state. So that seems to disqualify that theory? –  Johannes Ernst Jul 29 '12 at 0:21
    
I could be wrong. It does happen sometimes. :) –  Michael Hampton Jul 29 '12 at 2:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.