1PARIS-TRACEROUTE(8) System Manager's Manual PARIS-TRACEROUTE(8)
2
3
4
6 paris-traceroute - print the IP-level routes between two Internet
7 hosts.
8
10 paris-traceroute [ -fhilnqvV ] [ -b initial_id ]
11 [ -d dest_port ] [ -a algorithm ] [ -f first_ttl ]
12 [ -L packetlen ] [ -m max_ttl ]
13 [ -M max_missing_hops ] [ -p protocol ]
14 [ -q nqueries ] [ -s source_port ] [ -t tos ]
15 [ -T delaymsecs ] [ -w waittime ]
16 host
17
19 Paris traceroute is a new version of the well-known network diagnosis
20 tool. It addresses problems caused by load balancers with the initial
21 traceroute(8) implementation. By controlling the flow identifier of the
22 probes, it is able to follow accurate paths in networks with load bal‐
23 ancers. It is also able to find all the load balanced paths to the
24 destination. Finally, it enriches its output with information
25 extracted from the received packets, allowing a more precise analysis
26 of the discovered paths.
27
28 Options are:
29
30 -a Set the probing algorithm:
31
32 hopbyhop
33 Send q (configured with the -q flag) probes with the same TTL,
34 then wait for all the replies or a timeout. Increment the TTL
35 and reiter the operation until we reach the destination. All
36 packets hold the same flow identifier.
37
38 packetbypacket
39 It is the classic traceroute(8) algorithm: send one probe at a
40 time, then wait for a reply or a timeout. Reiter the operation
41 until we reach the destination.
42
43 concurrent
44 Send all the probes from min_ttl to max_ttl and wait for all
45 replies or a timeout.
46
47 scout Send a scout probe with a ttl max to the destination. If the
48 destination can be reached, compute the number of hops used to
49 reach the destination and start the concurrent algorithm with a
50 max_ttl equal to this number of hops. If the destination cannot
51 be reached, the hopbyhop algorithm will be used instead. This
52 algorithm is only usable with UDP probes.
53
54 exhaustive
55 Print all the possible "load balanced" paths to the destination.
56 (See section EXHAUSTIVE ALGORITHM )
57
58 -b Set the initial probe identifier.
59
60 -d Set the the UDP/TCP destination port (default: 33457).
61
62 -f Set the initial ttl (default: 1).
63
64 -h Print help.
65
66 -i Print the "IP Identifier" value of the responses. It is used to
67 identify the different interfaces of a router, or uncover NAT
68 boxes.
69
70 -l Display the ttl value of the reply. Useful to study asymmetric
71 routing and NAT boxes.
72
73 -L Set the data length to be used in outgoing packets. (default:
74 0).
75
76 -m Set the maximum ttl (default: 30).
77
78 -M Set the maximum number of consecutive unresponsive hops which
79 causes the program to abort (default 3).
80
81 -n Print hop addresses numerically. The default is to print also
82 hostnames.
83
84 -p Set the protocol to use (possible values: udp, tcp, icmp).
85
86 -q Set the number of probes per hop (default: 3).
87
88 -s Set the UDP/TCP source port (default: 33456).
89
90 -t Set the Type of Service (default: 0). This field is taken into
91 account by many per-flow load balancers: in presence of such a
92 load balancer, packets having different TOS values are likely to
93 follow a different paths.
94
95 -T Set the time to wait between probes, in milliseconds (default
96 50ms).
97
98 -v Print debug messages.
99
100 -V Print the program version.
101
102 -w Set the time to wait for a response, in milliseconds (default
103 5000ms).
104
105
107 With the deployment of load balancing, there is no longer only one path
108 between two Internet hosts. This algorithm sends enough probes at each
109 hop to find all the possible interfaces. Unlike the other algorithms,
110 it varies the flow identifier of the probes in a controlled manner, to
111 ensure the discovery of all the interfaces with a high confidence
112 degree. It also categorizes load balancers as "per-packet" (pseudo-
113 random, round-robin packet balancing) or "per-flow" (packets belonging
114 to the same flow follow the same path).
115
116 In case of per-flow load balancing, it prints additional information to
117 track flows. The following trace shows the enriched output:
118
119 14 1.1.1.1:0,1,3 539.065 ms 1.1.1.2:2,4,5 492.152 ms
120 15 2.2.2.2:0,1,3 563.163 ms 2.2.2.3:2,4,5 470.919 ms
121
122 Integers listed after the interface addresses are "flow identifiers":
123 they are used to identify a flow in the set of interfaces found by the
124 algorithm. For example, flow #0 traverses interfaces 1.1.1.1 and
125 2.2.2.2. This is the same for flows 1 and 3 while flows 2, 4 and 5 tra‐
126 verse 1.1.1.2 and 2.2.2.3.
127
128
130 The following information are extracted from the response packets and
131 displayed:
132
133
134 Response TTL
135 The TTL of the responses (from the routers and the destination)
136 is optionally displayed in square brackets (Use the -l flag ).
137
138 Original TTL
139 This is the TTL of the probe when it was received and dropped by
140 the router. If the original TTL is different than 1, it is dis‐
141 played with a !Tx symbol, where x is the value of the TTL. For
142 example, !T0 indicates that the value of the TTL was 0 when the
143 probe reached the router that discarded it.
144
145 IP Identifier
146 This the identifier of the IP error packet sent by the router.
147 This field is set with the value of an internal 16-bit counter
148 usually incremented for each packet sent. This value is option‐
149 ally displayed inside brackets. For instance {1234} indicates
150 that the probe had its identifier set to 1234.
151
152 MPLS labels
153 If the packet contains ICMP extensions for MPLS, the MPLS label
154 stack is diplayed in an additionnal line just after the current
155 hop line. Labels of the same stack are separated with a "|"
156 character.
157
158 Other ICMP error messages
159 Paris traceroutes uses the same convensions as traceroute(8) to
160 display unexpected ICMP messages (i.e. different than
161 TIME_EXCEEDED, PORT_UNREACHABLE and ECHO_REPLY).
162
164 traceroute(8), pathchar(8), netstat(1), ping(8)
165
167 The initial version of traceroute(8) was implemented by Van Jacobson
168 from a suggestion by Steve Deering. Paris traceroute was implemented
169 by Xavier Cuvellier. Debugged and enhanced by Brice Augustin.
170
171 The current version is available at:
172
173 http://www.paris-traceroute.net
174
176 Please send bug reports to brice.augustin@rp.lip6.fr.
177
178
179
1804.3 Berkeley Distribution 28 August 2006 PARIS-TRACEROUTE(8)