<story><title>Traceroute Lies: A Typical Misinterpretation Of Output</title><url>http://movingpackets.net/2017/10/06/misinterpreting-traceroute/</url></story><parent_chain></parent_chain><comment><author>jlgaddis</author><text>As a network engineer who gets similar reports fairly often, I recommend watching &amp;quot;Tutorial: Troubleshooting with Traceroute&amp;quot; (a.k.a. &amp;quot;A Practical Guide to (Correctly) Troubleshooting with Traceroute&amp;quot;), as recorded at NANOG 62 (there&amp;#x27;s also an older presentation from NANOG 47, IIRC). It covers the same stuff John&amp;#x27;s article does and more. A PDF of the slides [1] is also available.&lt;p&gt;John alluded to this in his &amp;quot;side note&amp;quot; but often (the majority of cases, IME) the TTL will not be decremented inside of the MPLS core so you, as an end user, will have no visibility into it. You&amp;#x27;ll just see, for example, hop #4 (Los Angeles) then hop #5 (New York City), completely unaware that the IP packet actually passed through (MPLS &amp;quot;P&amp;quot;) routers in Phoenix, Denver, Kansas City, Chicago, and Washington, DC, in between.&lt;p&gt;You&amp;#x27;ll see the same thing -- although at a different layer -- when Q-in-Q tunneling is in use (assuming L2 protocols are also being tunneled).&lt;p&gt;N.B.: On common Linux distributions, there are usually several traceroute variants available. They are not all created equal. If a &amp;quot;regular&amp;quot; (UDP) traceroute won&amp;#x27;t work, you can try using ICMP or even TCP.&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;a1IaRAVGPEE&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;a1IaRAVGPEE&lt;/a&gt;&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.nanog.org&amp;#x2F;sites&amp;#x2F;default&amp;#x2F;files&amp;#x2F;tuesday_steenbergen_troublshootingtraceroute_62.49.pdf&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.nanog.org&amp;#x2F;sites&amp;#x2F;default&amp;#x2F;files&amp;#x2F;tuesday_steenberge...&lt;/a&gt;</text></comment>
<story><title>Traceroute Lies: A Typical Misinterpretation Of Output</title><url>http://movingpackets.net/2017/10/06/misinterpreting-traceroute/</url></story><parent_chain></parent_chain><comment><author>stephengillie</author><text>Great post. This is a very clear explanation of the routing situation. The last image is especially good.&lt;p&gt;What&amp;#x27;s needed is some kind of L2 Traceroute. It&amp;#x27;s maddening that an increasingly common piece of routing infrastructure is invisible to almost all common troubleshooting tools.&lt;p&gt;Edit: Cisco has one for their routers [0]. Since each hop would have to be traced locally, an L2 Trace would require orchestrating against all hardware devices in the route which introduces legal complications. A new discovery protocol might be needed.&lt;p&gt;[0] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.cisco.com&amp;#x2F;c&amp;#x2F;en&amp;#x2F;us&amp;#x2F;td&amp;#x2F;docs&amp;#x2F;switches&amp;#x2F;lan&amp;#x2F;catalyst6500&amp;#x2F;ios&amp;#x2F;12-2SXF&amp;#x2F;native&amp;#x2F;configuration&amp;#x2F;guide&amp;#x2F;swcg&amp;#x2F;l2trace.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.cisco.com&amp;#x2F;c&amp;#x2F;en&amp;#x2F;us&amp;#x2F;td&amp;#x2F;docs&amp;#x2F;switches&amp;#x2F;lan&amp;#x2F;catalyst6...&lt;/a&gt;</text></comment>