RE: Need your help on traceroute

From: Scott Morris (smorris@ipexpert.com)
Date: Sat Dec 29 2007 - 02:23:25 ART


Nope, I didn't consider that one since I didn't know anyone actually used
it. :) Bummer it didn't work on that option. Ah well.... thanks for
testing it!

Scott

-----Original Message-----
From: Brian Dennis [mailto:bdennis@internetworkexpert.com]
Sent: Saturday, December 29, 2007 12:12 AM
To: swm@emanon.com; 'PANDI MOORTHY'; 'Cisco certification'
Subject: RE: Need your help on traceroute

I tested out your theory for the record-route option and it didn't appear to
hold up :-( Did you consider the ICMP type of traceroute as defined in RFC
1393?

Brian Dennis, CCIE4 #2210 (R&S/ISP-Dial/Security/SP)
bdennis@internetworkexpert.com

Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)

>----- Original Message -----
Subject: RE: Need your help on traceroute
Date: Fri, December 28, 2007 20:36
From: "Scott Morris" <swm@emanon.com>

> While I agree on the idea that there are multiple ways of doing
traceroutes,
> I think the original question was about an ACL with ICMP and the
> "traceroute" option.
>
> R1(config)#access-list 101 permit icmp any any ?
> <0-255> ICMP message type
> administratively-prohibited Administratively prohibited
> alternate-address Alternate address
> conversion-error Datagram conversion
> dod-host-prohibited Host prohibited
> dod-net-prohibited Net prohibited
> dscp Match packets with given dscp value
> echo Echo (ping)
> echo-reply Echo reply
> fragments Check non-initial fragments
> general-parameter-problem Parameter problem
> host-isolated Host isolated
> host-precedence-unreachable Host unreachable for precedence
> host-redirect Host redirect
> host-tos-redirect Host redirect for TOS
> host-tos-unreachable Host unreachable for TOS
> host-unknown Host unknown
> host-unreachable Host unreachable
> information-reply Information replies
> information-request Information requests
> log Log matches against this entry
> log-input Log matches against this entry, including
> input
> interface
> mask-reply Mask replies
> mask-request Mask requests
> mobile-redirect Mobile host redirect
> net-redirect Network redirect
> net-tos-redirect Net redirect for TOS
> net-tos-unreachable Network unreachable for TOS
> net-unreachable Net unreachable
> network-unknown Network unknown
> no-room-for-option Parameter required but no room
> option-missing Parameter required but not present
> packet-too-big Fragmentation needed and DF set
> parameter-problem All parameter problems
> port-unreachable Port unreachable
> precedence Match packets with given precedence value
> precedence-unreachable Precedence cutoff
> protocol-unreachable Protocol unreachable
> reassembly-timeout Reassembly timeout
> redirect All redirects
> router-advertisement Router discovery advertisements
> router-solicitation Router discovery solicitations
> source-quench Source quenches
> source-route-failed Source route failed
> time-exceeded All time exceededs
> time-range Specify a time-range
> timestamp-reply Timestamp replies
> timestamp-request Timestamp requests
> tos Match packets with given TOS value
> traceroute Traceroute
> ttl-exceeded TTL exceeded
> unreachable All unreachables
> <cr>
>
> R1(config)#
>
> There are lots of things listed, and most have to do with the specific
> types/codes laid out in RFC792. However, I believe (and no, I haven't
> tested this) that the traceroute option here is specifically looking
> for option 7 of the header (RFC791) allowing the record route feature of
ICMP.
>
> Just my thoughts, but since everything else really is specific to ICMP
here,
> it would seem strange to either not filter based on that or simply
> ignore it.
>
> HTH,
>
>
> Scott Morris, CCIE4 (R&amp;S/ISP-Dial/Security/Service Provider)
> #4713,
JNCIE-M
> #153, JNCIS-ER, CISSP, et al.
> CCSI/JNCI-M/JNCI-ER
> VP - Technical Training - IPexpert, Inc.
> IPexpert Sr. Technical Instructor
>
> A Cisco Learning Partner - We Accept Learning Credits!
>
> smorris@ipexpert.com
>
>
>
> Telephone: +1.810.326.1444
> Fax: +1.810.454.0130
> http://www.ipexpert.com
>
>
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of Brian Dennis
> Sent: Friday, December 28, 2007 10:16 PM
> To: PANDI MOORTHY; Cisco certification
> Subject: Re: Need your help on traceroute
>
> Here is a reply that I've made on this list in the past in regards to
> traceroute:
>
> Note that traceroute is a technique to have the routers between the
> source and destination reveal themselves and finally have the
> destination reveal itself by replying to a "packet". 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@xxxxxx 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 in.
>
> [root@xxxxxx root]# man traceroute | grep "UDP port number"
> -p Set the base UDP port number used in probes (default is
> 33434).
> [root@xxxxxx root]#
> [root@xxxxxx 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@xxxxxx 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@xxxxxx root]#
>
>
> HTH,
>
> Brian Dennis, CCIE4 #2210 (R&amp;S/ISP-Dial/Security/SP)
> bdennis@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987
> Direct: 775-745-6404 (Outside the US and Canada)
>
>
> >----- Original Message -----
> Subject: Need your help on traceroute
> Date: Fri, December 28, 2007 17:41
> From: "PANDI MOORTHY" <moorthypandi@gmail.com>
>
> > Hi
> >
> >
> >
> >
> >
> > Is there Cisco documentation to explain the real usage of this command
> > "permit
> > icmp any any traceroute"
> >
> >
> >
> > I am trying to capture the source which originate the traceroute
> > packet,
> >
> >
> >
> > I understand we can use the below ACL to capture the traceroute
> > return traffic (to the originator)
> >
> >
> >
> > permit icmp any any time-exceeded log-input
> >
> > permit icmp any any port-unreachable log-input
> >
> >
> >
> >
> > How about on incoming side? is there a way to log
> >
> > Regards
> > Pandi
> >
> > ____________________________________________________________________
> > __ _ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Tue Jan 01 2008 - 12:04:32 ARST