Centos – traceroute timing out in hop 5 for hostname

centosdedicated-serverhostnamenetworkingtimeout

For some reason, traceroute to hostname (and any domains hosted on this server) always times out on hop 5, right between the two shown below:

76.246.22.2
(Request timed out.)
ggr7.sffca.ip.att.net [12.122.114.17]

The tracert eventually completes at hop 16. The addresses are all unique, and the timed out hop only occurs on hop 5. After the att.net, the hops are all some long hostname at above.net, before finally resolving to another IP, and then, finally, the hostname.

1) What does this timeout effect?

2) Is there anything I can do about this – or it something I've misconfigured? Dedicated CentOS/WHM server.

(The other IP's assigned to the same machine works without this timeout…)

Best Answer

It's just because router that is on Hop 5 is filtering traceroute request.
It's not a problem, there is no impact for your server and you can't do anything about this.

Related Solutions

Setting the Hostname: FQDN or Short Name?

I would choose a consistent approach across the entire environment. Both solutions work fine and will remain compatible with most applications. There is a difference in manageability, though.

I go with the short name as the HOSTNAME setting, and set the FQDN as the first column in /etc/hosts for the server's IP, followed by the short name.

I have not encountered many software packages that enforce or display a preference between the two. I find the short name to be cleaner for some applications, specifically logging. Maybe I've been unlucky in seeing internal domains like server.northside.chicago.rizzomanufacturing.com. Who wants to see that in the logs or a shell prompt?

Sometimes, I'm involved in company acquisitions or restructuring where internal domains and/or subdomains change. I like using the short hostname in these cases because logging, kickstarts, printing, systems monitoring, etc. do not need full reconfiguration to account for the new domain names.

A typical RHEL/CentOS server setup for a server named "rizzo" with internal domain "ifp.com", would look like:

/etc/sysconfig/network:
HOSTNAME=rizzo
...

/etc/hosts:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

172.16.100.13   rizzo.ifp.com rizzo

[root@rizzo ~]# hostname 
rizzo

/var/log/messages snippet:
Dec 15 10:10:13 rizzo proftpd[19675]: 172.16.100.13 (::ffff:206.15.236.182[::ffff:206.15.236.182]) - Preparing to               
 chroot to directory '/app/upload/GREEK'
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - FTP session opened.
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - Preparing to chroot                
to directory '/app/upload/ftp/SRRID'

Firewall – Determining cause of TCP/IP connect issue without traceroute

If your network admins are blocking ICMP (which is done for the wrong reasons wherever it is done), there is hardly anything you can do. No matter what kind of protocol you use for the probing packets (Windows tracert.exe uses ICMP, Windows , Linux traceroute uses UDP by default and TCP if you ask for it), if ICMP as a protocol is generally filtered (especially if ICMP responses generated by foreign hosts are filtered as well), you can't ever get meaningful results back to your machine for diagnosis - as these always will come back as ICMP packets.

Best Answer

Related Solutions

Setting the Hostname: FQDN or Short Name?

Firewall – Determining cause of TCP/IP connect issue without traceroute

Related Topic