Topic: cannot ping a server

[crazybob]

I am not sure where else to go with this, so here I am.

I am not sure when this started

I am trying to access a website (www.c97.net)

if I putty into my SME7.3 fully updated server when I try to ping c97.net, it will resolve the ip, but will not ping.
I can putty into another another SME7.3 server that uses the same ISP, and I can ping the address without problem.

Both servers are in server/gateway mode, and there is no firewall/router between the server and the internet

Any Ideas?

Thanks

Bob

[Stefano]

hi

there's the possibility that the site you are pinging is set up not to respond to ping..

many firewalls drop ICMP echo..

HTH
Ciao
Stefano

[crazybob]

I can ping it from another server I have access to, and I can ping yahoo.com.

[mmccarn]

you might want to try trace routing to the destination - perhaps the routes from the two SMEs to the destination are different.

Here's what I get from my server:

Code: [Select]

# traceroute -In www.c97.net
traceroute to c97.net (38.114.169.104), 30 hops max, 38 byte packets
 1  10.1.41.82  2.349 ms  1.016 ms  2.148 ms
 2  130.81.110.124  1.724 ms  2.635 ms  1.540 ms
 3  130.81.10.94  3.880 ms  2.779 ms  3.781 ms
 4  130.81.15.74  37.232 ms  5.407 ms  4.099 ms
 5  154.54.5.34  123.202 ms  3.961 ms  224.653 ms
 6  154.54.2.49  236.097 ms  11.146 ms  272.738 ms
 7  154.54.1.69  13.356 ms  244.471 ms  4.533 ms
 8  154.54.5.202  154.175 ms  287.925 ms  264.576 ms
 9  154.54.5.133  79.441 ms  273.814 ms  260.235 ms
10  154.54.5.158  244.101 ms  255.637 ms  238.578 ms
11  154.54.24.81  313.778 ms  254.847 ms  264.363 ms
12  154.54.0.42  80.622 ms  81.238 ms  80.227 ms
13  154.54.1.101  81.189 ms  80.359 ms  80.256 ms
14  38.112.38.226  81.782 ms  80.876 ms  81.900 ms
15  38.112.242.166  80.795 ms  81.756 ms  80.832 ms
16  38.114.169.104  81.717 ms  80.413 ms  81.853 ms

[crazybob]

I just tried that and this is what I get

 1  134.215.197.161  0.412 ms  0.281 ms  0.276 ms
 2  69.129.156.1  3.754 ms  3.658 ms  3.678 ms
 3  69.129.120.10  3.655 ms  3.647 ms  3.704 ms
 4  64.50.239.30  24.135 ms  24.054 ms  23.920 ms
 5  64.50.236.242  25.271 ms  25.231 ms  25.248 ms
 6  154.54.5.17  24.476 ms  24.319 ms  24.234 ms
 7  66.28.4.185  36.744 ms  36.342 ms  36.011 ms
 8  154.54.24.81  48.693 ms  48.618 ms  48.741 ms
 9  154.54.0.42  83.092 ms  82.956 ms  83.058 ms
10  154.54.1.101  82.018 ms  82.173 ms  82.101 ms
11  38.112.38.226  84.113 ms  82.727 ms  82.460 ms
12  38.112.242.166  83.634 ms  83.591 ms  83.492 ms
13  * * *
14  * * *
15  * * *
16  * * *
For some reason it doesn't make the final hop. If I try it on a couple of other servers, it completes properly.

I am not sure where to go from here

Thanks

[arne]

I think the question actually is: "why does not 38.114.169.104 not answer my icmp requests".

Who can know exept for the admin of 38.114.169.104 ?

Theoretically it could help to expand the firewall templates of the local server and reboot the firewall, but I would not think it can/will work, as the first series of icmp requests does obtain an answer.

If something strange happen somewhere out in "the big world" it might not be easy to tell why, if you don't have access to the place where it happen.

Theoretically packet traffic can be dumped from server that does not receive anwer and an other server for comparison, but I would not expect this to give any clear answer either. (??!)

[mmccarn]

I can imagine the results you're seeing in any of the following situations:

1) Odd internet issues -- usually transient. 
I had a situation several years ago where a client in London could not access a mail server in Washington, DC, but I could from Virginia -- I set up some port mirroring in Virginia, and London could get their email through my system.  This situation lasted a bit over 24 hours.

2) Firewall issues
I frequently perform port scans of my clients from my office, as well as monitoring servers and services using smokeping.  Some firewalls detect my scanning as an attack and shut down all connectivity, resulting in loss of 'pingability'.  Sonicwall units can be configured like this.  A couple years ago I wrote a script for SME that did this (the script created iptables rules to block all traffic from hosts rejected by check_earlytalker, but my smokeping probes triggered check_earlytalker, and I ended up blocked out)

3) Load-Balanced Connection
I was told once by someone who knows more about network theory than I ever did or will, that a load balanced link can result in intermittent traceroute and ping failures - if I remember correctly, he said that cisco's load balancing algorithms were likely to send the ping response back on the other half of the load-balanced connection, which would not be detected as a reply by the originating system (since it seems to come from the wrong IP).  Usually this fails for all remote connections, but I can imagine a scenario where it works for some and fails for others.

4) Bad routing table at www.c97.net
If www.c97.net thinks it knows a better way to get to your non-functioning SME, it will use that route for the ping responses, which would therefore never get back to you.  Imagine if I create a "Local Network" on my SME server that includes the public IP of your SME server, but give it an internal router as the gateway: you'll be able to get one hop away from me, but you'll never be able to create a connection to my SME server.

[crazybob]

I have had a chance to try to access that website from another location, and it appears they are having some kind of problem. The connection does appear to be kind of dodgy.

Thanks so much for the help though. I hope they can resolve their problems.

Bob