Dear All,

In VMware ESXi5.1 environment: :
CentOS 6.3 named 'host1', running with apache-tomcat-7.0.32.
And, there's 2nd ethernet interface assigned private subnet(ex. 172.x.x.x) named host2.

Normally, users can connect to http://host1:8011/Web from browser IE or Chrome,
and the ping status like:
64 bytes from host1: icmp_seq=1 ttl=64
64 bytes from host1: icmp_seq=2 ttl=64

But, when users report they failed to connect to http://host1:8011/Web, found the ping status:
64 bytes from host1: icmp_seq=1 ttl=30
64 bytes from host1: icmp_seq=2 ttl=30

After few minutes, the ping status will be back to 'ttl=64', then users can connect successfully again.

I can't figure out what's wrong with that. Since, the conidtion will be happened several times unexpectedly during the day.

But, if users connected to host2 via VPN, they said never failed to connect to http://host2:8011/Web

Should any comments or suggests will be much appreciated.

Thanks,Davis

The TTL value reported by ping is the value in the TTL field of the received ICMP Echo Reply packets.

These values are determined by two factors:

1. The TTL value set by the operating system generating these packets
2. The number of intermediate routers (each router decrements the TTL value by one)

A sudden change in the TTL value when pinging the same host indicates that packets are being routed differently. You should perform a traceroute (ideally from both sides) to determine the path the packets have to travel under these two different circumstances.

1 members found this post helpful.

Thanks. I've been tried 'tracert host1' from my own laptop only, and since we are in the same subnet, so, the result response quickly and showed up the host1 is reached successfully . Maybe the 'wrong' packet condition remained a short period when it happened.
But, I don't understand 'traceroute (ideally from both sides)'? which are the sides?

One side is the computer connecting to (or trying to connect to) "host1", the other is "host1".

From the client, perform a traceroute when the connection is working and save the results. From the server, do a traceroute to the client's IP address (or the nearest routable address if NAT is involved) and save that result as well.

If/when the problem reappears, repeat the procedure and compare the results. They will be different.

1 members found this post helpful.

Thanks a lot.

At the beginning, I choosed a client running Windows7, however, when run 'traceroute -d Windows7' at 'host1', unable to reach after 30 hops until stopped the Windows7 firewall. I've no idea how to make Windows7 firewall to pass the 'traceroute' from 'host1'.

So, I choosed another CentOS machine(host3), better.
Currently, observed that the response by running 'traceroute' to any IP at 'host1' is a little lag than 'host3'.

Will keep watch on the result when the issue happened.
Thanks again.