I'am able to connect between two machines via ssh on port 22.But when i am doing the traceroute to my 2nd machine from my first machine , it is reporting the below error


Can someone please help in understand that why is it so , if i'm able to do ssh to my second machine that means it is reachable via the network then why my traceroute is showing asterick(*) even when i have disabled the firewall

OS details - Centos 6

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
traceroute 30.3.33.111
traceroute to 30.3.33.111 (30.3.33.111), 30 hops max, 60 byte packets



1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

You haven't told us anything about your network topology. I assume that your machines are connected within the same subnet on a LAN? Then traceroute won't show any gateway hops, since the destination is directly reachable (resolved by ARP), so the traceroute packets are sent directly to the host in question. Since the router is not needed to route the packet, it won't show up as a hop. Now why your target host rejects the ICMP packets sent is a another matter again. I would review 'man traceroute' for other options.

sorry for not sharing the complete details ..

I m using AWS virtual machines where my machines are in same VPC but in different subnets .

By default ping is disabled in AWS instances.

Does the traceroute also uses the ping command philosophy or there is any other issue ..please guide me

Similar question asked here that might answer your question. Note the last comment to making sure that UDP ports are allowed (which traceroute uses by default). BTW, if you read the man page for traceroute, you'll note that it is possible to test with other protocol types, including the -T option for probing with TCP SYN packets.

OS level firewall. By default, Windows/RHEL instances do respond to ICMP
RHEL and CentOS are "close enough" to warrant a check of the firewall rules on the target host.

Very likely the network has ICMP disabled.

Traceroute works by generating ICMP traffic - starting with a timeout of 1, then it waits for a return ICMP packet with "time exceeded" status from a gateway. Then it increments the count, and tries again.

If no reply after a rather long timeout, it will increment anyway, and try (this is reported with the *).

If the network has ICMP disabled, then you never get a reply.

The manpage on traceroute lists several alternatives to try to handle that:

-T option, to use TCP, the default target port is 80 (so if the target doesn't have a web server it doesn't work well - try other ports, 22, or whatever you used for a known service...)

-U option, to use UDP.

In both cases, random data is sent, so sometimes the service on the target could get confused...

As usual, refer to the manpage for details..