1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798 |
- .\" This manpage has been automatically generated by docbook2man
- .\" from a DocBook document. This tool can be found at:
- .\" <http://shell.ipoline.com/~elmert/comp/docbook2X/>
- .\" Please send any bug reports, improvements, comments, patches,
- .\" etc. to Steve Cheng <steve@ggi-project.org>.
- .TH "TRACEPATH" "8" "24 Mayıs 2011" "iputils-101006" "System Manager's Manual: iputils"
- .SH NAME
- tracepath, tracepath6 \- traces path to a network host discovering MTU along this path
- .SH SYNOPSIS
- \fBtracepath\fR [ \fB-n\fR] [ \fB-b\fR] [ \fB-l \fIpktlen\fB\fR] \fB\fIdestination\fB\fR [ \fB\fIport\fB\fR]
- .SH "DESCRIPTION"
- .PP
- It traces path to \fIdestination\fR discovering MTU along this path.
- It uses UDP port \fIport\fR or some random port.
- It is similar to \fBtraceroute\fR, only does not require superuser
- privileges and has no fancy options.
- .PP
- \fBtracepath6\fR is good replacement for \fBtraceroute6\fR
- and classic example of application of Linux error queues.
- The situation with IPv4 is worse, because commercial
- IP routers do not return enough information in ICMP error messages.
- Probably, it will change, when they will be updated.
- For now it uses Van Jacobson's trick, sweeping a range
- of UDP ports to maintain trace history.
- .SH "OPTIONS"
- .TP
- \fB-n\fR
- Print primarily IP addresses numerically.
- .TP
- \fB-b\fR
- Print both of host names and IP addresses.
- .TP
- \fB-l\fR
- Sets the initial packet length to \fIpktlen\fR instead of
- 65536 for \fBtracepath\fR or 128000 for \fBtracepath6\fR.
- .SH "OUTPUT"
- .PP
- .nf
- root@mops:~ # 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 2
- .fi
- .PP
- The first column shows TTL of the probe, followed by colon.
- Usually value of TTL is obtained from reply from network,
- but sometimes reply does not contain necessary information and
- we have to guess it. In this case the number is followed by ?.
- .PP
- The second column shows the network hop, which replied to the probe.
- It is either address of router or word [LOCALHOST], if
- the probe was not sent to the network.
- .PP
- The rest of line shows miscellaneous information about path to
- the correspinding network hop. As rule it contains value of RTT.
- Additionally, it can show Path MTU, when it changes.
- If the path is asymmetric
- or the probe finishes before it reach prescribed hop, difference
- between number of hops in forward and backward direction is shown
- following keyword async. This information is not reliable.
- F.e. the third line shows asymmetry of 1, it is because the first probe
- with TTL of 2 was rejected at the first hop due to Path MTU Discovery.
- .PP
- The last line summarizes information about all the path to the destination,
- it shows detected Path MTU, amount of hops to the destination and our
- guess about amount of hops from the destination to us, which can be
- different when the path is asymmetric.
- .SH "SEE ALSO"
- .PP
- \fBtraceroute\fR(8),
- \fBtraceroute6\fR(8),
- \fBping\fR(8).
- .SH "AUTHOR"
- .PP
- \fBtracepath\fR was written by
- Alexey Kuznetsov
- <kuznet@ms2.inr.ac.ru>.
- .SH "SECURITY"
- .PP
- No security issues.
- .PP
- This lapidary deserves to be elaborated.
- \fBtracepath\fR is not a privileged program, unlike
- \fBtraceroute\fR, \fBping\fR and other beasts of this kind.
- \fBtracepath\fR may be executed by everyone who has some access
- to network, enough to send UDP datagrams to investigated destination
- using given port.
- .SH "AVAILABILITY"
- .PP
- \fBtracepath\fR is part of \fIiputils\fR package
- and the latest versions are available in source form at
- http://www.skbuff.net/iputils/iputils-current.tar.bz2.
|