CCIE Blog

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]#

Hi Brian,

I am using dialer profiles for ISDN and I want protocol broadcasts such as RIP to be sent out accross the ISDN link. I tried to find the command that allows me to configure broadcast but the dialer interfaces do not accept the dialer map command. How do I accomplish this?

When using dialer profiles, dialer interfaces are point-to-point, therefore there is no need for protocol mappings. IP broadcasts should not have any trouble being sent across the interface as long as you have an IP address configured on the interface. Dialer maps are only used on dialer interfaces when using rotary groups. Dialer profiles are for when you have a single physical interface, but multiple destinations to dial. Rotary groups are for when you have multiple physical interfaces, but one destination to dial.

Hi Brian,I configured NTP on 2 Routers back-to-back with authentication (md5). So far everything works fine. I removed authentication on one of the Routers (no ntp authenticate) and they continue to sync. I even rebooted the router on which I had removed the authentication and they still sync. Any ideas why?

A common misconception about NTP authentication is the direction in which authentication occurs, however it makes perfect sense if you ask yourself this question: what is the purpose of using NTP authentication?

One clear answer is that authentication is used to prevent tampering with the timestamps on the logs generated by devices. To implement an attack on NTP, a hacker would make their rogue host appear to be a valid NTP server. NTP authentication is therefore used to authenticate the time source, not the client.

Take the following scenario:

R1–12.0.0.0/8–R2

R1 and R2 share the segment 12.0.0.0/8. R1 is the NTP master, and R2 is the client. To get a better understanding of how NTP authentication works, try the following possible configurations and see which of them work and which of them do not.

Case 1: No authentication

R1#sh run | in ntp
ntp master 1

R2#sh run | in ntp server
ntp server 12.0.0.1

R2#sh ntp status | in synch
Clock is synchronized, stratum 2, reference is 12.0.0.1

R2#show ntp associations detail
12.0.0.1 configured, our_master, sane, valid, stratum 1

Case 2: Authentication on server, no authentication on client

R1#sh run | in ntp
ntp authentication-key 1 md5 121A0C041104 7
ntp authenticate
ntp master 1

R2#sh run | in ntp
ntp clock-period 17179863
ntp server 12.0.0.1

R2#sh ntp status | in sync
Clock is synchronized, stratum 2, reference is 12.0.0.1

R2#sh ntp assoc detail
12.0.0.1 configured, our_master, sane, valid, stratum 1

Case 3: No authentication on server, authentication on client

R1#sh run | in ntp
ntp master 1

R2#sh run | in ntp
ntp authentication-key 1 md5 08701E1F28492647465A5D547E 7
ntp authenticate
ntp trusted-key 1
ntp clock-period 17179863
ntp server 12.0.0.1 key 1

R2#sh ntp status | in sync
Clock is unsynchronized, stratum 16, no reference clock

R2#sh ntp assoc detail
12.0.0.1 configured, insane, invalid, unsynced, stratum 16

Case 4: Authentication on server and client

R1#sh run | in ntp
ntp authentication-key 1 md5 0822455D0A16 7
ntp authenticate
ntp master 1

R2#sh run | in ntp
ntp authentication-key 1 md5 060506324F41 7
ntp authenticate
ntp trusted-key 1
ntp clock-period 17179865
ntp server 12.0.0.1 key 1

R2#sh ntp status | in sync
Clock is synchronized, stratum 2, reference is 12.0.0.1

R2#sh ntp assoc detail
12.0.0.1 configured, authenticated, our_master, sane, valid, stratum 1

As shown by the above configuration, NTP authentication is used to authenticate the NTP source, not any associated clients.