Linux for Network Engineers: Layer Four Traceroute (LFT)

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.