Layer Four Traceroute (LFT) is a version of traceroute that adds several nice features to the basic traceroute we are all familiar with. In most cases it’s faster, but also might discover routers that the traditional traceroute doesn’t discover unless you tweak the running parameters. In addition, it can perform AS Number Lookup by using a few different sources. The traditional traceroute can also do AS Lookup but has only one source for the lookup and it doesn’t seem to be as accurate.
Installation
For Debian/Ubuntu Linux LFT is available as a package and can be installed with:
apt-get install lft
However, if you want to make sure you install the latest version you’d have to install libpcap, and download and compile LFT as follows:
apt-get install libpcap-dev -y tar xzf lft-3.91.tar.gz cd lft-3.91 ./configure make sudo make install
After that you should be able to run and check the LFT version with:
netbeez$ lft -v
Layer Four Traceroute (LFT) - version 3.91 (04/2020)
- the alternative traceroute tool for network [reverse] engineers
Compile-time options:
+ Linux platform
+ IP length little-endian
+ Full IP headers for raw sockets
+ armv7l-unknown-linux-gnu
LFT comes with WhoB which is a utility to look up Internet DNS and network number records, similar to whois. Like LFT, WhoB puts a new spin to whois by providing an output that is easy to parse and doesn’t include all the output of whois which is usually redundant (e.g. general inquiries email, physical address, etc).
It looks like this:
netbeez$ whob 94.68.104.182 IP: 94.68.104.182 Origin-AS: 6799 Prefix: 94.68.0.0/16 AS-Path: 8220 1299 12713 6799 AS-Org-Name: Athens - Greece Org-Name: Multiprotocol Service Provider to other ISP's and End Users Net-Name: OTENET Cache-Date: 1624943543 Latitude: 35.327870 Longitude: 25.143410 City: Irakleion Region: Kriti Country: Greece Country-Code: GR Route-Originated-Date: May 06 2021 07:53:30 Route-Originated-TS: 1620287610
Usage
Let’s start by showing the difference between LFT and traceroute with a tracer to google.com without using any options for each utility:
traceroute to www.google.com (172.217.164.100), 30 hops max, 60 byte packets 1 192.168.86.1 (192.168.86.1) 7.089 ms 6.858 ms 6.580 ms 2 192.168.1.254 (192.168.1.254) 6.462 ms 9.413 ms 10.864 ms 3 108-193-0-1.lightspeed.sntcca.sbcglobal.net (108.193.0.1) 15.754 ms 17.592 ms 15.523 ms 4 71.148.135.196 (71.148.135.196) 17.275 ms 17.191 ms 27.487 ms 5 cr2.sffca.ip.att.net (12.123.15.186) 30.324 ms 44.533 ms * 6 * * * 7 * * 12.122.163.61 (12.122.163.61) 16.681 ms 8 12.255.10.236 (12.255.10.236) 16.329 ms 12.255.10.230 (12.255.10.230) 17.217 ms * 9 * * * 10 * * * 11 * 209.85.252.251 (209.85.252.251) 20.986 ms 74.125.252.151 (74.125.252.151) 20.763 ms 12 sfo03s18-in-f4.1e100.net (172.217.164.100) 21.645 ms 21.569 ms *
To try to compare apples to apples as much as possible, for LFT we use the IP traceroute targeted for www.google.com
netbeez$ lft 172.217.164.100 Tracing .........**.*T TTL LFT trace to sfo03s18-in-f4.1e100.net (172.217.164.100):80/tcp 1 192.168.86.1 6.1ms 2 192.168.1.254 8.9ms ** [neglected] no reply packets received from TTLs 3 through 4 5 cr2.sffca.ip.att.net (12.123.15.186) 16.1ms 6 12.122.3.70 10.7ms 7 12.122.163.61 12.0ms 8 12.255.10.230 13.3ms 9 209.85.254.132 18.1ms 10 209.85.252.251 19.4ms 11 [target open] 172.217.164.100:80 11.7ms
As you can see, traceroute couldn’t identify hops 6, 9, and 10, while LFT couldn’t identify hops 3 and 4. In this case, it looks like the outputs from the two utilities could be complementary to get the complete picture.
Let’s try another example, that shows better the difference between the two:
netbeez$ traceroute baidu.com traceroute to baidu.com (220.181.38.148), 30 hops max, 60 byte packets 1 192.168.86.1 (192.168.86.1) 17.387 ms 17.042 ms 16.978 ms 2 192.168.1.254 (192.168.1.254) 20.411 ms 20.345 ms 23.791 ms 3 108-193-0-1.lightspeed.sntcca.sbcglobal.net (108.193.0.1) 37.710 ms 37.639 ms * 4 * * * 5 * * * 6 * * * 7 * 192.205.32.78 (192.205.32.78) 19.152 ms 18.817 ms 8 * * * 9 * * * 10 * * * ... ... 29 * * * 30 * * *
Traceroute without any options couldn’t reach the destination after 30 hops, and couldn’t discover any routers after hop 7.
netbeez$ lft 220.181.38.148 Tracing ......**..*****...****.T TTL LFT trace to 220.181.38.148:80/tcp 1 192.168.86.1 6.5ms 2 192.168.1.254 8.0ms ** [neglected] no reply packets received from TTLs 3 through 4 5 cr2.sffca.ip.att.net (12.123.15.186) 14.3ms 6 12.122.114.5 11.1ms 7 192.205.32.78 20.4ms 8 202.97.50.77 23.8ms 9 202.97.59.109 195.0ms 10 202.97.84.213 171.7ms ** [neglected] no reply packets received from TTLs 11 through 12 13 36.110.246.209 213.1ms 14 106.38.244.150 184.5ms 15 106.38.244.174 204.1ms ** [neglected] no reply packets received from TTLs 16 through 17 18 [target open] 220.181.38.148:80 199.6ms
In this case, the default LFT managed to get to the destination and discover the vast majority of intermediate hops. It still is not able to discover hops 3 and 4.
Another utility that can do route discovery is nmap, and let’s see what its output looks like:
netbeez$ nmap -sn -Pn --traceroute 220.181.38.148 Starting Nmap 7.40 ( https://nmap.org ) at 2021-06-29 18:43 EDT Nmap scan report for 220.181.38.148 Host is up (0.22s latency). TRACEROUTE (using proto 1/icmp) HOP RTT ADDRESS 1 8.43 ms 192.168.86.1 2 8.09 ms 192.168.1.254 3 21.52 ms 108-193-0-1.lightspeed.sntcca.sbcglobal.net (108.193.0.1) 4 18.51 ms 71.148.135.196 5 23.65 ms cr2.sffca.ip.att.net (12.123.15.186) 6 21.73 ms 12.122.114.5 7 23.81 ms 192.205.32.78 8 23.86 ms 202.97.50.77 9 191.83 ms 202.97.59.109 10 166.42 ms 202.97.84.213 11 170.99 ms 202.97.48.221 12 188.26 ms 220.181.177.242 13 ... 14 200.68 ms 106.38.244.150 15 208.11 ms 106.38.244.150 16 ... 17 18 215.87 ms 220.181.38.148 Nmap done: 1 IP address (1 host up) scanned in 14.30 seconds
We added the “-sn” and “-Pn” options to skip the unnecessary port scan and host discovery for this test. As you can see, nmap discovered the most routers between LFT and traceroute.
LFT has several more options that you can find here or by typing lft --help. Similar to traceroute, you have the option to fine tune the probing by choosing between TCP or UDP packets, specify ports, etc. With LFT you can also choose between Prefix WhoIs, RIPE NCC, RADB, and Cymru for ASN lookup. In addition, you can print the output in XLM format for easier parsing, or in GraphViz.
All in all, I consider LFT an evolution of traceroute that is more than 30 years old at this point, and basically hasn’t changed in several years. LFT is currently under active maintenance and receives regular updates and improvements.
However, all of these tools are complementary to each other, and in this blog we’ve talked about other tracing tools such as dublin-traceroute and path-ping, concluding that you might need to try a couple of different utilities to get a complete trace between two hosts.
