Dec
28

First off we need to understand that traceroute is a technique to have the routers between the source and destination reveal themselves and finally have the destination reveal itself. Traceroute can be implemented using ICMP, UDP, and even TCP so as a CCIE when someone asks you to filter “traceroute” you should get a little background as to the traceroute application/OS’s being used to trigger the reply from the destination. Example: Windows uses ICMP echoes by default, most Linux OS’s use UDP by default but can use ICMP echoes (-I option), and the IOS uses UDP. There are also implementations that use TCP.

The goal of traceroute is to have the routers between the source and destination reveal themselves and finally have the destination reply so that you know you have reached it. The routers reveal themselves by sending Time Exceeded (aka TTL-Exceeded) ICMP packets back to the source when the TTL is decremented to zero. The traceroute implementation can determine its reached the destination by having it reply to an ICMP echo request, send an ICMP port unreachable to a packet sent to an unused UDP port, or completing the TCP three-way handshake.

************************************************************************

ICMP based traceroute:

In this example we are sending ICMP echo requests to www.cisco.com and looking for the ICMP echo reply to know that we have reached the final destination.

[root@digdug root]# traceroute -I www.cisco.com
traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte
packets
1 198.132.102.1 (198.132.102.1) 1.658 ms 1.975 ms 1.968 ms
2 foo.hostrack.net (202.101.143.254) 5.394 ms 22.382 ms 2.966 ms
3 ser4-0.core01.las.switchcommgroup.com (66.209.64.41) 20.132 ms 20.494 ms 20.195 ms
4 pos1-0.core02.las.oc48a.switchcommgroup.com (66.209.64.218) 19.749 ms 25.827 ms 26.814 ms
5 500.POS4-0.GW1.VEG2.alter.net (157.130.238.193) 29.108 ms 19.864 ms 20.066 ms
6 129.at-0-0-0.CL1.PHX2.ALTER.NET (152.63.115.26) 26.338 ms 26.232 ms 26.821 ms
7 0.so-4-0-0.XL1.SJC2.ALTER.NET (152.63.55.101) 46.424 ms 45.996 ms 45.675 ms
8 POS1-0.XR1.SJC2.ALTER.NET (152.63.56.138) 48.653 ms 46.513 ms 46.803 ms
9 193.ATM7-0.GW5.SJC2.ALTER.NET (152.63.48.77) 46.693 ms 46.619 ms 46.446 ms
10 ciscosys-gw1.customer.alter.net (65.208.80.242) 46.556 ms 46.954 ms 46.944 ms
11 sjce-dmzbb-gw1.cisco.com (128.107.239.89) 30.818 ms 31.769 ms 32.685 ms
12 sjck-dmzdc-gw1.cisco.com (128.107.224.69) 30.589 ms 30.626 ms 30.448 ms
13 * * *
14 www.cisco.com (198.133.219.25) 28.916 ms 28.994 ms 28.944 ms
************************************************************************

UDP based traceroute:
In this example we are sending UDP packets with a starting port number of 33434 to www.cisco.com. Note that we don’t ever get a reply from www.cisco.com because their firewall will not allow our UDP packets to arbitrary high ports in.

[root@digdug root]# man traceroute | grep “UDP port number”
-p Set the base UDP port number used in probes (default is 33434).
[root@digdug root]#
[root@digdug root]# traceroute www.cisco.com
traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets
1 198.132.102.1 (198.132.102.1) 1.725 ms 1.866 ms 1.841 ms
2 foo.hostrack.net (202.101.143.254) 4.887 ms 4.281 ms 4.482 ms
3 ser4-0.core01.las.switchcommgroup.com (66.209.64.41) 21.266 ms 21.152 ms 20.826 ms
4 pos1-0.core02.las.oc48a.switchcommgroup.com (66.209.64.218) 58.829 ms 42.033 ms 24.007 ms
5 500.POS4-0.GW1.VEG2.alter.net (157.130.238.193) 21.448 ms 23.277 ms 21.446 ms
6 129.at-0-0-0.CL1.PHX2.ALTER.NET (152.63.115.26) 27.816 ms 27.259 ms 27.210 ms
7 0.so-4-0-0.XL1.SJC2.ALTER.NET (152.63.55.101) 47.540 ms 46.954 ms 47.198 ms
8 POS1-0.XR1.SJC2.ALTER.NET (152.63.56.138) 48.072 ms 47.247 ms 46.667 ms
9 193.ATM7-0.GW5.SJC2.ALTER.NET (152.63.48.77) 51.728 ms 51.437 ms 48.304 ms
10 ciscosys-gw1.customer.alter.net (65.208.80.242) 48.563 ms 48.878 ms 47.807 ms
11 sjce-dmzbb-gw1.cisco.com (128.107.239.89) 31.562 ms 32.653 ms 31.318 ms
12 sjck-dmzdc-gw1.cisco.com (128.107.224.69) 32.327 ms 31.831 ms 31.516 ms
13 * * *
14 * * *

************************************************************************
TCP based traceroute:

In this example we are sending TCP SYN packets to port 80 looking for the destination to complete the three-way-handshake. Once the handshake
is complete we know that we have reached the destination. Obviously Cisco’s firewall is going to allow packets to TCP port 80 destined for it’s web server.

[root@digdug root]# tcptraceroute www.cisco.com
tcptraceroute: Symbol `pcap_version’ has different size in shared object, consider re-linking
Selected device eth3, address 198.132.102.93, port 41440 for outgoing packets
Tracing the path to www.cisco.com (198.133.219.25) on TCP port 80, 30 hops max
1 198.132.102.1 (198.132.102.1) 1.575 ms 1.507 ms 1.469 ms
2 foo.hostrack.net (202.101.143.254) 4.840 ms 5.090 ms 4.596 ms
3 ser4-0.core01.las.switchcommgroup.com (66.209.64.41) 21.205 ms 20.895 ms 21.430 ms
4 pos1-0.core02.las.oc48a.switchcommgroup.com (66.209.64.218) 21.682 ms 21.012 ms 21.059 ms
5 500.POS4-0.GW1.VEG2.alter.net (157.130.238.193) 21.185 ms 21.304 ms 20.939 ms
6 129.at-0-0-0.CL1.PHX2.ALTER.NET (152.63.115.26) 27.176 ms 28.615 ms 27.644 ms
7 0.so-4-0-0.XL1.SJC2.ALTER.NET (152.63.55.101) 47.659 ms 48.220 ms 47.667 ms
8 POS1-0.XR1.SJC2.ALTER.NET (152.63.56.138) 47.534 ms 48.483 ms 47.183 ms
9 193.ATM7-0.GW5.SJC2.ALTER.NET (152.63.48.77) 64.413 ms 51.058 ms 49.007 ms
10 ciscosys-gw1.customer.alter.net (65.208.80.242) 48.156 ms 49.197 ms 47.534 ms
11 sjce-dmzbb-gw1.cisco.com (128.107.239.89) 31.685 ms 32.633 ms32.895 ms
12 sjck-dmzdc-gw1.cisco.com (128.107.224.69) 32.291 ms 33.900 ms35.461 ms
13 www.cisco.com (198.133.219.25) [open] 31.041 ms 31.667 ms 32.775 ms
[root@digdug root]#

About Brian Dennis, CCIE #2210:

Brian Dennis has been in the networking industry for more than 22 years, with a focus on Cisco networking for the past 16 years. Brian achieved his first CCIE in Routing & Switching in 1996, and is currently the only ten year CCIE that holds five CCIE certifications. Prior to working with INE, Brian taught and developed CCIE preparation courses for various well known training organizations. Brian not only brings his years of teaching experience to the classroom, but also years of real world enterprise and service provider experience.

Find all posts by Brian Dennis, CCIE #2210 | Visit Website


You can leave a response, or trackback from your own site.

9 Responses to “Understanding Traceroute”

 
  1. Hi Brian, thanks for the post and the summary of discussion in CCIE group study.

    About 1 year ago, I made similar post in my blog in this post.

    Do you have idea, how to allow pix to allow udp traceroute?
    in my understanding, Unix traceroute is not using fix port number, but use dynamic and sequence port number (ie. 1st hop is using 33444, 2nd hop is using 22445, 3rd hop is using 33446, etc).

    ps: for tcp traceroute, I use tracetcp for windows (because my laptop is using windows).

  2. Hi Anthony,

    The problem with sending UDP traceroute through a stateful firewall is that the outbound packet is UDP, but the inbound reply is either ICMP time-exceeded (for devices in the transit path), or ICMP port-unreachable (for the final devices). To allow this inbound on the outside interface of the PIX firewall you therefore need an inbound access-list such as the follows:

    access-list OUTSIDE_IN extended permit icmp any any time-exceeded
    access-list OUTSIDE_IN extended permit icmp any any unreachable

  3. Ip Address says:

    I like this tutorial about network tool traceroute with example and i use very oft windows command tracert for network troubleshooting.
    Thanks for this!

  4. shopping says:

    So, if I’m running Linux and the server I’m pinging runs Microsoft, I send a UCP trigger but do I receive a USP trigger back or do I receive an ICMP trigger back?
    This is interesting – I wasn’t aware that each operating system was different. What is IOS? That doesn’t sound like Mac OS. It would be interesting if you mentioned Mac OS as well (I can’t for the life of me, figure our what IOS could possibly mean.)

  5. sticktoshopping says:

    if you dont know what IOS is stick to shopping like your name suggests.

  6. jdaniel says:

    I found a weird quirk of UDP traceroute which isn’t mentioned above which I wanted to ask about. It appears that routers do not answer when they are the target, but they do answer as an intermediate.

    When tracerouting to cmu.edu the router 128.2.0.205 answers as hop 10
    > traceroute cmu.edu
    traceroute: Warning: Multiple interfaces found; using 18.187.1.73 @ dmfe0
    traceroute to cmu.edu (128.2.10.162), 30 hops max, 40 byte packets
    1 NW12-RTR-2-W20.MIT.EDU (18.187.0.1) 1.176 ms 0.478 ms 0.435 ms
    2 EXTERNAL-RTR-2-BACKBONE.MIT.EDU (18.168.0.27) 0.577 ms 0.520 ms 0.492 ms
    3 NY32-RTR-1-BACKBONE.MIT.EDU (18.168.0.34) 6.087 ms 6.109 ms 6.037 ms
    4 216.24.184.101 (216.24.184.101) 6.243 ms 5.706 ms 5.819 ms
    5 wash-newy-98.layer3.nlr.net (216.24.186.23) 12.413 ms 12.102 ms 11.766 ms
    6 leviathan-nlr-10g0-0-0-0.3rox.net (192.88.115.164) 17.042 ms 17.061 ms 16.933 ms
    7 bar-leviathan-ge-6-0-0-1.3rox.net (192.88.115.84) 16.031 ms 16.062 ms 16.800 ms
    8 cmu-i2.3rox.net (192.88.115.186) 16.062 ms 16.063 ms 15.999 ms
    9 CORE0-VL986.GW.CMU.NET (128.2.0.249) 16.119 ms 16.254 ms 16.104 ms
    10 POD-D-CYH-VL958.GW.CMU.NET (128.2.0.205) 18.059 ms 17.066 ms POD-D-WEH-VL959.GW.CMU.NET (128.2.0.212) 16.950 ms
    11 WWW-CMU-1.andrew.cmu.edu (128.2.10.162) 17.022 ms 17.097 ms 17.306 ms

    But then it does not answer when tracerouting to 128.2.0.205
    > traceroute 128.2.0.205
    traceroute: Warning: Multiple interfaces found; using 18.187.1.73 @ dmfe0
    traceroute to 128.2.0.205 (128.2.0.205), 30 hops max, 40 byte packets
    1 NW12-RTR-2-W20.MIT.EDU (18.187.0.1) 0.746 ms 0.471 ms 0.426 ms
    2 EXTERNAL-RTR-2-BACKBONE.MIT.EDU (18.168.0.27) 1.529 ms 1.495 ms 1.284 ms
    3 NY32-RTR-1-BACKBONE-2.MIT.EDU (18.168.1.34) 6.858 ms 6.834 ms 6.848 ms
    4 216.24.184.101 (216.24.184.101) 8.661 ms 7.505 ms 6.578 ms
    5 wash-newy-98.layer3.nlr.net (216.24.186.23) 13.190 ms 12.565 ms 12.769 ms
    6 leviathan-nlr-10g0-0-0-0.3rox.net (192.88.115.164) 18.331 ms 17.745 ms 17.710 ms
    7 bar-leviathan-ge-6-0-0-1.3rox.net (192.88.115.84) 134.171 ms 16.896 ms 26.150 ms
    8 cmu-i2.3rox.net (192.88.115.186) 16.839 ms 16.806 ms 16.810 ms
    9 CORE0-VL986.GW.CMU.NET (128.2.0.249) 16.861 ms 18.159 ms 16.899 ms
    10 * * *

  7. It’s possible the router is filtering it. The last hop responds with ICMP port-unreachable. Most production routers have this disabled for security reasons with the “no ip unreachables” command at the interface level. The reason why is that ICMP unreachable can be used for network mapping attacks. If I sent you a packet for host 1.2.3.4, and you don’t have a route to it, you respond back with host unreachable. Based on all the host unreachables I get, I can determine what your routing table looks like (mapping attack).

    The router still responds as an “intermediary” for the traceroute because this ICMP type is ttl-expired/time-exceeded. These types must be manually filtered out with an access-list, and typically are not because they’re useful for troubleshooting routing loops in the network.

    Brian

  8. Bob Watson says:

    Outbound Filter for Unix and Linux systems you would open up UDP destination ports number from 33434 to 33534 and regardless of OS to get the return data whether IOS MSFT or Unix you would allow ICMP Type 11 back to the host initiating the trace. As that is the message that states the TTL has expired.

  9. [...] Also , i did not know that we could do TCP traceroutes. I always thought , there were only 2 types of traceroutes : ICMP ( windows style ) and UDP (Unix, cisco style ). There’s also a TCP traceroute which uses SYN packets sent on port-80. You can find some documentation about that HERE. [...]

 

Leave a Reply

Categories

CCIE Bloggers