sc_tracediff(1) [debian man page]
SC_TRACEDIFF(1) BSD General Commands Manual SC_TRACEDIFF(1) NAME
sc_tracediff -- display traceroute paths where the path has changed. SYNOPSIS
sc_tracediff [-a] [-m method] [-n] file1.warts file2.warts DESCRIPTION
The sc_tracediff utility displays pairs of traceroutes to a destination where the path has changed. It takes two warts files as input and displays paths where a hop differs by its address. The options are as follows: -a dump all traceroute pairs regardless of whether they have changed. -m method specifies the method used to match pairs of traceroutes together. If dst is specified, traceroutes are matched if the destination IP address of both traces are the same. If userid is specified, traceroutes are matched if the userid field of both traces are the same. If dstuserid is specified, traceroutes are matched if the destination IP address and userid fields are the same. By default, the destination IP address is used. -n names should be reported instead of IP addresses, where possible. sc_tracediff can be useful in network monitoring to identify when a forward IP path has changed. In this scenario, it is recommended that Paris traceroute is used with the same UDP source and destination ports for each execution of scamper so that only paths that have changed are identified, not merely alternate paths visible due to per-flow load-balancing. By default scamper uses a source port based on the process ID, which will change with each execution of scamper. EXAMPLES
The command: scamper -O warts -o file1.warts -c 'trace -P udp-paris -s 31337' -f list.txt collects the forward IP paths towards a set of IP addresses found in list.txt using 31337 as the UDP source port value. If the above command is adjusted to subsequently collect file2.warts, then we can identify paths that have subsequently changed with the command: sc_tracediff file1.warts file2.warts If Paris traceroute with ICMP probes is preferred, then the following invocation of scamper is appropriate: scamper -O warts -o file1.warts -c 'trace -P icmp-paris -d 31337' -f list.txt In this case, scamper uses 31337 as the ICMP checksum value in each probe. SEE ALSO
scamper(1), B. Augustin, X. Cuvellier, B. Orgogozo, F. Viger, T. Friedman, M. Latapy, C. Magnien, and R. Teixeira, Avoiding traceroute anomalies with Paris traceroute, Proc. ACM/SIGCOMM Internet Measurement Conference 2006. AUTHOR
sc_tracediff is written by Matthew Luckie <mjl@luckie.org.nz>. BSD
April 21, 2011 BSD
Check Out this Related Man Page
TRACEPATH(8) System Manager's Manual: iputils TRACEPATH(8) NAME
tracepath, tracepath6 - traces path to a network host discovering MTU along this path SYNOPSIS
tracepath [-n] [-b] [-l pktlen] [-p port] destination DESCRIPTION
It traces path to destination discovering MTU along this path. It uses UDP port port or some random port. It is similar to traceroute, only does not require superuser privileges and has no fancy options. tracepath6 is good replacement for traceroute6 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. OPTIONS
-n Print primarily IP addresses numerically. -b Print both of host names and IP addresses. -l Sets the initial packet length to pktlen instead of 65535 for tracepath or 128000 for tracepath6. -p Sets the initial destination port to use. OUTPUT
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 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 ?. 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. The rest of line shows miscellaneous information about path to the correspinding network hop. As rule it contains value of RTT. Addition- ally, 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. 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. SEE ALSO
traceroute(8), traceroute6(8), ping(8). AUTHOR
tracepath was written by Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>. SECURITY
No security issues. This lapidary deserves to be elaborated. tracepath is not a privileged program, unlike traceroute, ping and other beasts of this kind. tracepath may be executed by everyone who has some access to network, enough to send UDP datagrams to investigated destination using given port. AVAILABILITY
tracepath is part of iputils package and the latest versions are available in source form at http://www.skbuff.net/iputils/iputils-cur- rent.tar.bz2. iputils-121221 10 June 2014 TRACEPATH(8)