Provided by: lft_2.2-4ubuntu1_amd64 
NAME
lft — display the route packets take to a network host/socket; optionally show heuristic network
information in transitu
SYNOPSIS
lft [-d dport] [-s sport] [-m min] [-M max] [-a ahead] [-c scatter ms] [-t timeout ms] [-l min ttl]
[-q ISN] [-D device] [-H ttl] [-i] [-n] [-E] [-N] [-A] [-T] [-S] [-V] [-v] [<gateway> <...>]
host:dport
DESCRIPTION
The Internet is a large and complex aggregation of network hardware, connected together by gateways.
Tracking the route one's packets follow (or finding the miscreant gateway that's discarding your packets)
can be difficult. (from traceroute(8))
lft sends various TCP SYN and FIN probes (differing from Van Jacobson's UDP-based method) utilizing the
IP protocol `time to live' field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway
along the path to some host. lft also listens for various TCP and ICMP messages along the way to assist
network managers in ascertaining per-protocol heuristic routing information and can optionally retrieve
various information about the networks it traverses.
The only mandatory parameter is the destination host name or IP number. Options toggle the display of
more interesting data or change the variables of the trace itself. The (-E) "smart" option tries several
combinations in order to improve the chance of a successful trace.
Other options are:
-d dport
Set dport as the destination TCP port of the probes LFT generates. Default is 80. This option
is useful to see if packets follow a different route based on protocol destination, a likely
scenario when load balancers or proxies are involved. This option may also bypass less
sophisticated packet filter configurations.
-s sport
Set sport as the origin TCP port of the probes LFT generates. Default is 53. This option is
useful to see if packets follow a different route based on protocol source. This option may also
bypass less sophisticated packet filter configurations.
-m min Set min as the minimum number of probes to send per host. Default is 1 unless "smart" (-E) mode
is used.
-M max Set max as the maximum number of probes to send per host. Default is 5.
-a ahead
Set ahead as the number of hops forward to query before waiting for a response. Default is 5.
-c scatter ms
Set scatter ms as the minimum number of milliseconds to wait between sending probes. Default is
20.
-t timeout ms
Set timeout ms as the maximum number of milliseconds to wait before assuming a probe was
lost/discarded. Default is 1000.
-l min ttl
Set min tll as the minimum TTL (time-to-live) on outgoing probes (essentially, the first hop in
the line that you want to display). Default is 1.
-q ISN Set ISN as the ISN (initial sequence number) of the first probe. If unset, one will be
automatically generated.
-D device
Set device as the network device or IP address to be used. (e.g., "en1") If unset, one will be
automagically selected by default.
-H ttl Set ttl as the maximum TTL, essentially the maximum route traversal distance in hops. Default is
30.
-i Disable "stop" on ICMP other than TTL expired.
-n Print addresses numerically rather than symbolically and numerically. Disables use of the DNS
resolver completely.
-E Enable use of the "smart" engine which tries FIN/SYN/etc tables to improve the chance of a
successful trace. The engine also displays other useful information such as stateful inspection
firewalls it finds along the way.
-N Enable lookup and display of network names (e.g., [GNTY-NETBLK-4]). This option queries various
registries of network address allocation such as ARIN.
-A Enable lookup and display of of AS (autonymous system) numbers (e.g., [1]). This option queries
various registries of network address allocation such as ARIN.
-T Enable display of LFT's execution timer. This option places timers on the trace itself and on
lookups and name resolution to show where LFT is spending its time, waiting on resolvers, or
processing trace packets.
-S Suppress display of the real-time status bar. This option makes LFT show its completed trace
output only, no-frills.
-V Verbose output. Mostly debug garbage. Likely too verbose for regular use.
-v Display version information, then exit().
Any hosts listed after these options and before the final host will comprise the loose source route.
Since network operators have security concerns with regard to the use of source routing, don't expect the
LSRR options to do much for you in most public network environments.
EXAMPLES
A sample use and output might be:
[edge.lax]$ lft -S 4.2.2.2
Hop LFT trace to vnsc-bak.sys.gtei.net (4.2.2.2):80/tcp
1 ln-gateway.centergate.com (206.117.161.1) 0.5ms
2 isi-acg.ln.net (130.152.136.1) 2.3ms
3 isi-1-lngw2-atm.ln.net (130.152.180.21) 2.5ms
4 gigabitethernet5-0.lsanca1-cr3.bbnplanet.net (4.24.4.249) 3.0ms
5 p6-0.lsanca1-cr6.bbnplanet.net (4.24.4.2) 3.4ms
6 p6-0.lsanca2-br1.bbnplanet.net (4.24.5.49) 3.3ms
7 p15-0.snjpca1-br1.bbnplanet.net (4.24.5.58) 10.9ms
8 so-3-0-0.mtvwca1-br1.bbnplanet.net (4.24.7.33) 11.1ms
9 p7-0.mtvwca1-dc-dbe1.bbnplanet.net (4.24.9.166) 11.0ms
10 vlan40.mtvwca1-dc1-dfa1-rc1.bbnplanet.net (128.11.193.67) 11.1ms
** [neglected] no reply packets received from TTLs 11 through 20
** [4.2-3 BSD bug] the next gateway may errantly reply with reused TTLs
21 [target] vnsc-bak.sys.gtei.net (4.2.2.2) 11.2ms
The (-S) option was used to suppress the real-time status bar for clean output. LFT's "**" notifiers in
between hops 10 and 21 represent additional useful information: the first is a "[neglected]" indicator
that lets us know that none of the probes sent with the TTLs indicated elicited responses. This could be
for a variety of reasons, but the cause of this specific occurrence is described in the next informative
message which indicates that this is likely the result of a bug in the 4.[23] BSD network code (and its
derivatives): BSD 4.x (x < 3) sends an unreachable message using whatever TTL remains in the original
datagram. Since, for gateways, the remaining TTL is zero, the ICMP "time exceeded" is guaranteed to not
make it back to us. LFT does its best to identify this condition rather than print lots and lots of hops
that don't exist (trying to reach a high enough TTL).
Now, using the smart engine option:
[edge.lax]$ lft -E -S 4.2.2.1
Hop LFT trace to vnsc-pri.sys.gtei.net (4.2.2.1):80/tcp
1 ln-gateway.centergate.com (206.117.161.1) 0.5/0.5ms
2 isi-acg.ln.net (130.152.136.1) 2.1/2.3ms
3 isi-1-lngw2-atm.ln.net (130.152.180.21) 2.6/7.1ms
4 gigabitethernet5-0.lsanca1-cr3.bbnplanet.net (4.24.4.249) 6.1/3.9ms
** [firewall] the next gateway may statefully inspect packets
5 p0-0-0.lsanca1-csr1.bbnplanet.net (4.24.4.10) 155.4/3.7ms
6 [target] vnsc-pri.sys.gtei.net (4.2.2.1) 22.6/3.7/*/*/*/*/*ms
In the scenario above, the smart engine was able to identify a stateful, packet-inspecting firewall in
the path. Another example with more options:
[edge.lax]$ lft -S -A -T -m 2 -d 80 -s 53 www.yahoo.com
Hop LFT trace to w9.scd.yahoo.com (66.218.71.88):80/tcp
1 [AS226] ln-gateway.centergate.com (206.117.161.1) 1 ms
2 [AS226] isi-acg.ln.net (130.152.136.1) 2 ms
3 [AS226] isi-1-lngw2-atm.ln.net (130.152.180.21) 3 ms
4 [AS1] gigether5-0.lsanca1-cr3.bbnplanet.net (4.24.4.249) 3 ms
5 [AS1] p6-0.lsanca1-cr6.bbnplanet.net (4.24.4.2) 5 ms
6 [AS1] p6-0.lsanca2-br1.bbnplanet.net (4.24.5.49) 3 ms
7 [AS1] p1-0.lsanca2-cr2.bbnplanet.net (4.25.112.1) 3 ms
8 [AS16852] pos4-0.core1.LosAngeles1.Level3.net (209.0.227.57) 3 ms
9 [AS3356] so-4-0-0.mp1.LosAngeles1.Level3.net (209.247.10.193) 3 ms
10 [AS3356] so-3-0-0.mp2.SanJose1.Level3.net (64.159.1.130) 11 ms
11 [AS3356] gige10-0.ipcolo4.SanJose1.Level3.net (64.159.2.42) 11 ms
12 [AS3356] cust-int.level3.net (64.152.81.62) 52 ms
13 [AS10310] vl17.bas2.scd.yahoo.com (66.218.64.150) 53 ms
14 [AS10310] w9.scd.yahoo.com (66.218.71.88) [target] 54 ms
LFT's trace took 5.23 seconds. Resolution required 3.58 seconds.
And why not request netblock lookups?
[edge.lax]$ lft -S -N www.microsoft.com
Hop LFT trace to www.us.microsoft.com (207.46.197.113):80/tcp
1 [LOS-NETTOS-BLK4] ln-gateway.centergate.com (206.117.161.1) 2 ms
2 [LOS-NETTOS] isi-acg.ln.net (130.152.136.1) 3 ms
3 [LOS-NETTOS] isi-1-lngw2-pos.ln.net (130.152.80.30) 5 ms
4 [GNTY-4-0] gigether5-0.lsanca1-cr3.bbnplanet.net (4.24.4.249) 4 ms
5 [GNTY-4-0] p6-0.lsanca1-cr6.bbnplanet.net (4.24.4.2) 3 ms
6 [GNTY-4-0] p6-0.lsanca2-br1.bbnplanet.net (4.24.5.49) 3 ms
7 [GNTY-4-0] p15-0.snjpca1-br1.bbnplanet.net (4.24.5.58) 10 ms
8 [GNTY-4-0] p9-0.snjpca1-br2.bbnplanet.net (4.24.9.130) 11 ms
9 [GNTY-4-0] so-1-0-0.sttlwa2-br1.bbnplanet.net (4.0.3.229) 27 ms
10 [GNTY-4-0] so-0-0-0.sttlwa1-hcr1.bbnplanet.net (4.24.11.202) 28 ms
11 [GNTY-4-0] so-7-0-0.sttlwa1-hcr2.bbnplanet.net (4.24.10.234) 28 ms
12 [GNTY-4-0] p1-0.sttlwa1-cr2.bbnplanet.net (4.24.10.241) 29 ms
13 [GNTY-4-0] p2-0.msseattle.bbnplanet.net (4.25.89.6) 32 ms
14 [MICROSOFT-GLOBAL-NET] 207.46.154.9 32 ms
15 [MICROSOFT-GLOBAL-NET] 207.46.155.17 33 ms
16 [MICROSOFT-GLOBAL-NET] 207.46.129.51 [prohibited] 35 ms
Running LFT as a non-root user
As distributed by Debian, lft can only be run by the root user. To allow regular users to run lft, the
sysadmin needs to read the file /usr/share/doc/lft/HOWTO-UsersLFT.txt and follow the instructions in that
file.
AUTHOR
Nils McCarthy, Victor Oppleman, Ugen Antsilevitch, and other helpers around the world. The source is
currently maintained and administered by MainNerve, Inc.
REPORTING BUGS
To report bugs, send e-mail to <lft-bugs@mainnerve.com>
SEE ALSO
traceroute(8), netstat(1), whois(1)
HISTORY
The lft command first appeared in 1998 as 'fft'. Renamed as a result of confusion with fast fourier
transforms, lft stands for 'layer four trace.'
LFT August 17, 2002 LFT(8)