LFT(8) | System Manager's Manual | LFT(8) |
lft
— display the
route packets take to a network host/socket using one of several layer-4
protocols and methods; optionally show heuristic network information in
transitu
lft |
[-d dport]
[-s sport]
[-m retry min]
[-M retry max]
[-a ahead]
[-c scatter ms]
[-t timeout ms]
[-l min ttl]
[-H max ttl]
[-L length]
[-q ISN]
[-D device]
[-f device]
[-G icons path]
[-ACEINPRSTUVbeghinpruvxyz ]
[<gateway> <...>]
target:dport |
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
was developed to automate a solution
to the above, taking into account that modern networks contain many
configurations of load balancers, proxies, and stateful firewalls.
lft
implements numerous network tracing
methods and strategies. Generally, lft
sends various
types of layer-4 probes utilizing the IP protocol `time to live' field and
attempts to elicit an ICMP `time exceeded in transit' response from each
gateway along the path to some host. RFC 1393 Traceroute Using an IP Option
is also available as one of several tracing methods.
lft
additionally listens for various
messages along the way to assist network managers in ascertaining
per-protocol heuristic routing information. lft
can
optionally retrieve various information about the networks it traverses
using a variety of sources such as registries, routing arbiters, etc.
The only mandatory parameter is the target host name or IP number. Options toggle the display of more interesting data or change the variables of the trace itself. The (-E/-e) adaptive option tries several combinations of TCP states (changing flags inside the probes it sends) in order to improve the chances of a successful trace and expose stateful packet filters.
Other options are:
-d
dport-s
sport-z
-m
min-M
max-a
ahead-c
scatter ms-t
timeout ms-l
min ttl-q
ISN-L
length-D
devicelft
will attempt to determine and acquire the
appropriate interface based on routing.-f
devicelft
will attempt to determine and acquire the
appropriate interface based on routing. This serves to operate
lft
in a passive mode where you may transmit from
a (potentially) spoofed IP address on one interface, yet receive on
another. This allows you to trace from a different IP address whose
traffic you can see in order to intercept replies.-H
ttl-G
icons path-I
-i
-n
-h
-E/e
-F
-u
-N
-P
-p
-b
-A
-r
-C
-R
-T
-U
-S
-x
-g
-y
-V
-v
Any hosts listed after these options and before the final host/target will comprise the loose source route. Since network operators have security concerns regarding the use of source routing, don't expect the LSRR options to do anything for you in most public networks.
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 adaptive 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 adaptive 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 [226] ln-gateway.centergate.com (206.117.161.1) 1 ms 2 [226] isi-acg.ln.net (130.152.136.1) 2 ms 3 [226] isi-1-lngw2-atm.ln.net (130.152.180.21) 3 ms 4 [1] gigether5-0.lsanca1-cr3.bbnplanet.net (4.24.4.249) 3 ms 5 [1] p6-0.lsanca1-cr6.bbnplanet.net (4.24.4.2) 5 ms 6 [1] p6-0.lsanca2-br1.bbnplanet.net (4.24.5.49) 3 ms 7 [1] p1-0.lsanca2-cr2.bbnplanet.net (4.25.112.1) 3 ms 8 [16852] pos4-0.core1.LosAngeles1.Level3.net (209.0.227.57) 3 ms 9 [3356] so-4-0-0.mp1.LosAngeles1.Level3.net (209.247.10.193) 3 ms 10 [3356] so-3-0-0.mp2.SanJose1.Level3.net (64.159.1.130) 11 ms 11 [3356] gige10-0.ipcolo4.SanJose1.Level3.net (64.159.2.42) 11 ms 12 [3356] cust-int.level3.net (64.152.81.62) 52 ms 13 [10310] vl17.bas2.scd.yahoo.com (66.218.64.150) 53 ms 14 [10310] w9.scd.yahoo.com (66.218.71.88) [target] 54 ms LFT's trace took 5.23 seconds. Resolution required 3.58 seconds.
Note the -Ar above displays ASNs using the RADB as a whois source. A better option may have been to use the -A alone or perhaps -AC.
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
If traces don't appear to go anywhere, there are a number of
things to try. If you are receiving an error related to permissions, be sure
the lft
executable is set-uid root so it may execute
with root-level permissions required to utilize raw sockets on most
operating systems.
If you do not receive permissions-related errors, but traces still don't go anywhere, first activate verbose output by adding -VV to your command line options. Then, reading the verbose output, if you see trace probes going out, but no replies being detected (as indicated by "RCVD" tags), you may: Use the TCP basic (-b) method if you wish to use TCP probes and you fear NAT may be causing your trace to fail. Alternatively, select a different trace method and protocol such as UDP (-u) or ICMP (-p).
If you are attempting to use RFC 1393 (-P) and your trace is failing, this is likely because network equipment somewhere in the path does not conform to RFC 1393. Your only option is to select an alternative tracing method or protocol.
If you are attempting to utilize adaptive mode (-E/-e) and traces fail, first try enabling NAT compatibility using TCP basic (-b). If traces still fail, the most likely reason is a close-proximity stateful firewall in your network, which prevents this feature from working.
Victor Oppleman, Eugene Antsilevitch, Sergey Kondryukov and other helpers around the world.
To report bugs, send e-mail to <lft@oppleman.com>
The lft
command first appeared in 1998 as
'fft'. Renamed as a result of confusion with fast fourier transforms,
lft
stands for 'layer four traceroute.' Thanks also
to Nils McCarthy for writing 'FFT', LFT's predecessor.
August 17, 2002 | LFT |