traceroute [-46dFITUnrAV] [-f first_TTL] [-m max_TTL] [-q nqueries]
[-i device] [-p port] [-s src_addr]
[-N squeries] [-t tos]
[-l flow_label] [-w waittime] [-z sendwait]
[-g gate,…]
host [packetSize]
traceroute6
is the same as traceroute -6
tracert
is the same as traceroute -I
(ICMP ECHO only root)
tcptraceroute
is the same as traceroute -T -p 80
tracepath
non-priviledge
-f first_TTL | Default 1. | ||||||||||||||||||||||||||||||||||||||||
-m max_ttl |
TTL
) option in attempts to elicit an
ICMP† TIME_EXCEEDED
response from each gateway along the path to the host, thus identifying them.
TTL
is expressed in transfers from each host or gateway aka hops (has nothing to do with time).
Routes are dynamic and 2 packets sent even within milliseconds may not take the same path due to congestion or balancing or performance considerations or router outage.
Starts by sending packets with a TTL
of 1 and increments by 1 until "Port Unreachable" (or TCP reset), which means
host was reached, or max hops. Three packets are sent at each TTL
and a display showing the ttl
, address of the gateway and round trip time of each packet is output.
If the answers come from different gateways, the address of each will be displayed.
If there is no response within a timeout, a "*
" is displayed.
Varying the size of the packet sent to that host (default 40),
in conjunction with -F
(don't fragment) can obtain information about the MTU of individual network hops. (size not used with TCP ).
!
TTL <=1
!H
(host), !N
(network), or !P
protocol unreachable
!S
source route failed
!U
Destination network unknown
!W
host unknown
!I
source host is isolated
!A
communication with destination is network administratively prohibited
!Z
communication with destination is host administratively prohibited
!Q
for this ToS the destination network is unreachable
!T
for this ToS the destination host is unreachable
!F
fragmentation needed ( - the RFC1191 Path MTU Discovery value is displayed)
!X
communication administratively prohibited
!V
host precedence violation
!C
precedence cutoff in effect
!nnn
ICMP unreachable code as in RFC1812
tracepath [-nc] destination[/port]
Uses UDP port or random port, similar to traceroute,
-c
use the return address instead of the reply type (connection refused
) to determine when to stop.
-n
No DNS resolving names
Tracepath6 is good replacement for traceroute6
Some IP routers do not return enough information in icmp error messages.
Uses Van Jacobson's algorithm, sweeping a range of UDP ports to maintain trace history.
# tracepath6 3ffe:2400:0:109::2 1?: [LOCALHOST] pmtu 1500 1: dust.inr.ac.ru 0.411ms 2: dust.inr.ac.ru asymm 1 0.390ms pmtu 1480 2: 3ffe:2400:0:109::2 463.514ms reached Resume: pmtu 1480 hops 2 back 2column
LOCALHOST
(if the packet was not sent to the gateway).
async
Hop 2 shows asymmetry of 1, because the first probe with TTL of 2 was rejected at the first hop due to Path MTU Discovery.
Resume
) shows detected Path MTU, hops to the destination and hops from the destination back, which can be different when the path is asymmetric.
Default packet size of 40 bytes may be increased by specifying size after the destination.
Understanding tracerouteIt is important to understand that the list of hops displayed is only one of the possible paths that packets may take.Routers (dedicated or on general purpose hosts) frequently have more than 2 interfaces. Packets received on one interface may be routed to the second interface or the traffic may better suits routing to the third interface. It would not be unusual for all packets to use the same route during a short time period. It would not be unusual for packets at a later time to use a different route.
Default settings start with a ttl of 1 and increase by 1 until ICMP "port unreachable" is received (i.e target host replied or hit a max)
(defaults to net.inet.ip.ttl hops & can be changed with A sample use and output might be: [yak 71]% traceroute nis.nsf.net. traceroute to nis.nsf.net (35.1.1.48), 64 hops max, 38 byte packet 1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 3 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms 4 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms 5 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms 6 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms 7 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms 8 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms 9 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms 10 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms
gateways at 12, 14, 15, 16 & 17 hops away, either don't send ICMP "time exceeded" messages or send them with a ttl too small to get back to the traceroute server[yak 72]% traceroute allspice.lcs.mit.edu. traceroute to allspice.lcs.mit.edu (18.26.0.115), 64 hops max 1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms 5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms 8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms 9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms 10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms 11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms 12 * * * 13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms gateway 12 is silent which . There are 12 "gateways" (13 is the final destination) and exactly the last half of them are "missing".1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 39 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms 5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms 6 csgw.Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 rip.Berkeley.EDU (128.32.131.22) 59 ms ! 39 ms ! 39 ms ! What could be happening is that rip is using the ttl from our arriving datagram as the ttl in its ICMP reply. The reply will time out on the return path (with no notice sent to anyone since ICMP's aren't sent for ICMP's) until we probe with a ttl that's at least twice the path length. I.e., rip is really only 7 hops away. A reply that returns with a ttl of 1 is a clue this problem exists. traceroute displays a ! after the time if the ttl is <= 1.
Use in network testing, measurement and management, manual fault isolation. Some options could impose excessive load on the network See netstat(1), ping CloudMonitor.ca.com(checks from different locations!!)
BUGS |