On a similar question here Luke Savage explained it perfectly:
Traceroute is not a protocol itself, it is an application and the protocols used depends on the implementation your are using. Primarily this is ICMP.
There are two main implementations:
tracert - tracert is a Windows application that utilises ICMP packets with as incrementing TTL ...
The first version of traceroute was written by Van Jacobson and it used ICMP but it didn't work very well. The vendor interpretation of ICMP in RFC792 was that routers should not send an ICMP error message in response to an ICMP packet (see edit notes below). Therefore most routers would not send a "time exceeded" message in response to an echo request with ...
To add to @naïveRSA's answer, if there's filtering/firewalling in the path one could also have the situation where an ICMP "echo reply" (ping) packet is blocked, but an ICMP "time exceeded" (tracert) packet is allowed. This would give the same results even when only ICMP (Windows) is used.
In both cases (sender using either UDP or ICMP) the error ...
That is a routing loop. The router with IP address 184.108.40.206 keeps sending your packets to another router (220.127.116.11), which keeps sending them back to 18.104.22.168. They keep doing this until the TTL of the packet reaches zero, and the packet is discarded.
This cannot be caused by your bind9 setup, something is wrong with the configuration of the ...
The answer by YLearn is correct but it is important to know more details.
* means that your machine received no response.
!H means that your machine received ICMP message "destination host unreachable" from the host indicated in the traceroute output.
Rarely traceroute can indicate also other unreachable messages like !N or !P (network or protocol) etc.
Let me try to answer this, because it's a little more complicated that it may look initially.
It seems that you already know the basic operation of traceroute but before anything else here is a very small recap:
traceroute tries to determine all the in-between steps from your host to a destination host, or just the distance, i.e. number of hops, from your ...
Your client is only sending the first three packets with a TTL of 1. The next three are sent with a TTL of 2. The next three are sent with a TTL of 3. And so on and so forth.
An easier way to view this is to set the IP TTL field as its own column in Wireshark. Simply right click on the TTL value in any packet, and select "Apply as Column":
From there, ...
There's no such thing as "UDP ICMP "echo"". traceroute sends a UDP probe with an increasing TTL. That probe is a single datagram destined for a high port which is unlikely to be a listening service. As the datagram flows out across the network, the TTL decrements until it hits zero at which point an ICMP ERROR ("time exceeded") is generated. That ICMP ...
1) Traceroute may attempt to resolve the hop's domain name via DNS. As you didn't include any additional flags to explicitly enable this functionality, your traceroute application does so by default. If you just see an IP address, it wasn't able to resolve it.
2) This is because a different path was taken on successive traces. Since traceroute works by ...
Many routers prioritize routing packets over answering ICMP requests, they often have rate limits and queueing in place to reduce load on the router.
As a result, latency on intermittent hops can be shown as higher than the latency to the end node.
The new ICMP message type as defined in this RFC actually was added to the ICMP standard - Though it's currently listed as historical in RFC 6918:
2.6. Traceroute (Type 30)
This message type is specified in [RFC1393] and was meant to provide
an alternative means to discover the path to a destination system.
This message type has never been widely ...
To understand the mechanism, let's see it with an example:
I issue a traceroute to 22.214.171.124 from my PC
My PC sends 3 UDP datagrams to 126.96.36.199 with TLL=1 and port=33434
Inmediately sends 3 UDP datagrams to 188.8.131.52 with TTL=2 and port=33435
Inmediately sends 3 UDP datagrams to 184.108.40.206 with TTL=3 and port=33436
It will keep doing that until TTL=32 ...
Traceroute doesn't give inexact information, it performs tests in a specific way and give some results based on the response it receives (or do not receive).
You have to know how to interpret the response, and for example that a given packet may take a path different than the path shown by a traceroute.
Additionally when you use traceroute in a network you ...
You are "A", you are performing a Traceroute to "B"
First hop is A > R1. The response travels R1 > A. In this case, the RTT time is how long it took for the packet to get from A, to R1, and back. In a way, you could divide the RTT in half, and you would have the time from A to R1, and from R1 to A.
Second Hop is A > R1 > R2. The response ...
Any form of traceroute works by incrementing the TTL of an IP packet by one.
The first packet has a TTL of one and the 1 router decrements the timer and send out an error massage via ICMP (Time to live exceeded). Standard *NIX traceroute uses UDP, Windows tracert ICMP, there are also versions that use TCP.
There are different cases why you don't see a hop:...
I's not exactly the answer at your question, but that a simple (but limited) way to do (in certain case) what you want.
I'm coping-post the option -R of ping man page:
-R Record route. Includes the RECORD_ROUTE option in the ECHO_REQUEST packet and displays the route buffer on returned packets.
Note that the IP header is only large enough for ...
Traceroute deliberately sends packets with low time-to-live values to make the routers between you and your destination send back ICMP TTL exceeded messages. The traceroute output is basically the list of source IP addresses sending these TTL exceeded messages.
So the output tells you the 4th router has sent you a message from a private IP address. This is ...
The virtual world and physical world rarely line up. Just because machines are physically close, doesn't make them logically close. Traffic goes where routing entries, and interconnects take it.
Eons ago, I demonstrated this very thing with two PCs sitting on the same table. Each dialed into different ISPs. Packets between the machines went half way around ...
Traceroute, by its nature, only reports on the path towards the target, and very imperfectly too.
You need to run traceroute from both sides to see if your routes are asymmetric.
It has to be repeated that traceroute only gives you a "sliding snapshot" of a route: the reported hops are backscatter -- the errors of many different, specific, packets failing ...
Let's look at what happens, shall we?
220.127.116.11 makes a good example, because at least from my location, I can reach it both with traceroute and ping.
First let's try ping 18.104.22.168 and watch what happens:
$ tcpdump -n host 22.214.171.124 or icmp
15:36:51.045994 IP 10.4.27.179 > 126.96.36.199: ICMP echo request, id 7215, seq 0, length 64
15:36:51.062458 IP 188.8.131.52 > ...
Unless there is forwarding going on prior to delivery (i.e. the laptop has two interfaces and it crosses between them because its destination is not the port it came in on) then the TTL should not be altered. The source can set a TTL of whatever it likes up to a maximum of 255, and if you are watching it arrive from the device with a TTL of 30 and it only ...
According to RFC1812 the source address of ICMP message generated by the router should be that of the egress interface over which the packet would normally return to the sender.
In reality, it is very likely that you will face non-standard behavior where router will source the ICMP reply with the source of ingress interface. This usually make the ...
I prefer to use tcptraceroute for a better detail of hop-to-hop routing.
tcptraceroute essentially bypasses most protective firewall ignoring ICMP packets that is used by traceroute. Use port 80 or 53.
Tcp traceroutes could be used to test for access lists blocking a given protocol on routers, firewalls or intrusion prevention systems. Both good guys and bad guys have an interest in such knowledge. Tools such as tcptraceroute are common in a penetration testers toolbox and might be found on a savvy network administrators system.
In theory you could send a packet with IP option 7 set (record route). This would return the path the packet took to the destination.
In practice this option is not widely supported, which is exactly why traceroute uses TTL.
Pretty much every post I see along these lines recommends the following document:
Practical Guide To (Correctly) Troubleshooting with Traceroute
Traceroute can you send you down the rabbit hole, I would read the entire thing, in fact, I'm going to read over it again.
Quoting from RFC6814 which obsoletes RFC1393
The Traceroute option is defined in [RFC1393]. The Traceroute option
is defined as Experimental; it was never widely deployed on the
So yes there should have been implementations for this (some one even implemented IP over avian carriers) but I've never seen one.
I highly recommend the Traceroute Guide posted by dareuja. There isn't a more complete single resource on interpreting the results (that I know of, at least).
Here are a few tips I've picked up over the years from correctly reading the output. If you're unfamiliar with how tracreoute works, there is some good info in this thread.
1. Understand the ...
1 - it is because your traceroute client is performing reverse DNS lookup. I.E. it asks to the DNS server which is the domain name associated with this IP address. In one case, there's no such reverse record, so the IP address is displayed in place in the domain name. In the other case, there's a reverse record for this IP address and so traceroute display ...