Koozali.org: home of the SME Server
Contribs.org Forums => General Discussion => Topic started by: crazybob on October 11, 2008, 03:26:39 AM
-
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
-
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
-
I can ping it from another server I have access to, and I can ping yahoo.com.
-
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:
# 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
-
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
-
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. (??!)
-
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.
-
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