Linux for Network Engineers: Tracepath Analysis with Dublin Traceroute

By June 2, 2020Linux

There are a few open-source and free tools out there that can help visualize the path traversed between two hosts. We’ve talked about mtr and traceroute, and recently I came across Dublin traceroute

Actually, the inventor of Dublin traceroute maintains his own blog here, and there you can find many more details about the tool, how to install it and how to use it than this post. However, I wanted to make a summary of the tool’s capabilities, how it is different to other tools and how it can be used.

ECMP

Traceroute displays the route and delays for each packet hop between two hosts. On top of traceroute, mtr provides packet loss and jitter for each hop. Both traceroute and mtr show and analyze just one path, and actually, due to their limitations, they may even show wrong or even impossible paths. 

These drawbacks are caused by Equal-Cost Multi-Path (ECMP) routes which are pretty much expected when traversing the public internet. ECMP is not as common on WANs. The first open-source tool to have solved this problem was Paris traceroute.

Dublin traceroute uses the same techniques as Paris traceroute, and in addition introduces new techniques for NAT detection that improve the reported result accuracy. To put it into the author’s words:

“Paris-traceroute can tell you whether a hop that appears as a loop in a traceroute is due to NAT, while Dublin Traceroute can tell you whether there is a NAT after a given point, and can also identify multiple NATs. At the best of my knowledge, there is no tool nor public research using this technique. If I am wrong, please let me know so that I can give the credit where due.”

And 

“When you run a regular traceroute or paris-traceroute through this kind of (missconfigured) NAT, you will see no response from all the hops located just after these broken NAT boxes.”

Examples

Although Dublin traceroute might be available on standard repositories, I would advise that you install its latest version either from source or from the testing repository.
You can run a test as follows:

I almost always use the -o flag to redirect the JSON output of the results to a file. If you don’t, you will get a very long output that you probably can’t read. The regular output looks like this:

Reference: https://blog.dublin-traceroute.net/2017/10/a-picture-is-worth-a-thousand-words/

These are just two out of the 20 flows that Dublin traceroute generates by default. This includes lots of information, and it might be difficult to read. The last line of the text output informs you that you can plot this by using the Python Dublin traceroute module with python -m dublintraceroute plot trace.json. It looks like this:

dublin traceroute image

Reference: https://blog.dublin-traceroute.net/2017/10/a-picture-is-worth-a-thousand-words/

The visual representation might be more pleasing to the eye, but there’s lots of value to the text output as well, since it allows you to sort through traversed NATs more easily.

Although Dublin traceroute is a superset of regular traceroute, I don’t think it should be the first tool you should use when troubleshooting. The regular traceroute is easier to visually parse and understand. In addition if you are on a WAN network and you know the topology Dublin might not add any value unless you have ECMP on the network. Also, Dublin traceroute doesn’t give you metrics such as packet loss and jitter the same way mtr does out of the box.

All in all it’s a great tool and I am looking forward to learning more about it and exploring how I can use it productively.