traceroute vs. ping

axfalk · ‎05-04-2008

I was just wondering what would be the circumstatnce at which the ping would respond OK and the traceroute would not. I did the extended ping and it worked OK, but the extended teraceroute between the same 2 nodes came back with all asterics for all 30 hops..Thnx..

cisco_lad2004 · ‎05-04-2008

if u are going thru an MPLS network, most ISP would disable traceroute for security purpose.

having said that, both ping and trace use ICMP..but different types of ICMP so there might well be an ACL blocking one type and not the other.

HTH

Sam

andrew.prince · ‎05-04-2008

basically as I understand it:-

1) Ping - you are requesting a response from the remote end IP.

2) Extended Ping - the same as the above by stateing the source ip address of the ping packet.

3) Traceroute you are bascially pinging every hop along the way, and waiting for a response from every hop. Tracing the route to your end host.

4) Extended Traceroute as number 3 - but using a source IP.

The asterix are for hosts that have not responded to the direct ping request from the traceroute....routers/firewalls etc can pass on ping, but if you ping them directly they mostly will not respond, if configured that way.

HTH.

Richard Burts · ‎05-04-2008

Greg

The answer from Sam is incorrect when it states that both ping and traceroute use ICMP. This depends on what device is doing the traceroute. From a Windows PC traceroute does use ICMP but Cisco routers and switches and Unix boxes use UDP packets for traceroute.

Since your post was not specific about which device was doing the traceroute we can not know whether it was using ICMP or UDP. But the potential difference of UDP or ICMP is a possibility to keep in mind.

There is another possibility to consider. Ping and Extended Ping just send packets to the destination and wait for responses. So as long as the ICMP echo request and echo response are permitted then the ping will succeed. But traceroute sends packets varying the TTL and devices along the path respond with Time Exceeded ICMP error messages. It is possible that the Time Exceeded error messages are being filtered out which would prevent traceroute from working.

HTH

Rick

HTH

Rick

cisco_lad2004 · ‎05-04-2008

Rick,

When the question mentions extended PING and extended Traceroute would you think about Windows XP able to provide this ?

I think you are looking too deep at a simple question. It's nice to keep it simple, unless really required.

Sam

cisco_lad2004 · ‎05-04-2008

I would stand corrected, but please take a look at below example. it clearly states 100Bytes ICMP.

!---Ping packets are sourced from this address.

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 162.108.21.8, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 36/97/132 ms .

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f22.shtml

Sam

mohammedmahmoud · ‎05-05-2008

Hi,

I believe that the original poster is talking about Cisco devices (since AFAIK windows doesn't support extended ping/traceroute, at least not in the Cisco extended ping/traceroute context), and accordingly as Rick stated, Cisco devices uses ICMP for ping (despite being normal or extended) and UDP for traceroute (plus ICMP TTL exceeded error messages, please review traceroute operation below), and also as Rick stated, i've seen multiple cases where only ICMP echo requests and echo replies where permitted and thus traceroute didn't operate normally.

http://www.cisco.com/warp/public/63/ping_traceroute.html

BR,

Mohammed Mahmoud.

lamav · ‎05-06-2008

"Greg...The answer from Sam is incorrect when it states that both ping and traceroute use ICMP."

No, this statement is incorrect, actually.

Cisco IOS utilizes BOTH UDP and ICMP time-exceeded messages for Traceroute. UDP when sending the Traceroute packet and ICMP when it receives a reply from a host/router.

This whole discussion seems a little anal, to be frank, but I did want to clarify one thing.

Victor

l.mourits · ‎05-07-2008

But it seems all are in agreement that it must be something being filtered out along the path, either UDP or ICMP Time Exceeded messages.

Meaning, when performing a trace route you could indeed see the asterix (*) a couple of times, and the trace route may fail completely as well, while icmp echo's (ping) works fine.

joseph.derrick · ‎05-09-2008

You are basically correct that Cisco devices use ICMP time-exceeded messages for traceroute. What Rick emphasized for using UDP is for the "sending" device. Cisco devices DO NOT send ICMP for traceroute, ICMP are only used for inbound and hence for replies only to incoming traceroute (UDP queries).

This is simply to say that for traceroute:

OUTBOUND: udp (queries)

INBOUND: icmp, time-exceeded (replies)

Thanks,

k0rg

nissanka123 · ‎05-31-2008

What is Extended ping command?

I know about the command ping?

I can write 'ping www.google.com' on the command line.

It just tell me the existence of that network.

What is the 'Extended ping command'?

scottmac · ‎05-31-2008

Ping (and extended ping) are ICMP packets (send is "echo", reply is "echo reply").

Since ping is so common (and the "Ping of death" DOS has pretty much been handled years ago) it is common to permit echo and echo reply through most firewalls and filters.

Traceroute (MS Windows tracert) sends UDP packets with incrementing Time-To-Live (TTL) values (first is a ttl of 1, next is ttl of 2, etc).

When the UDP packet arrives at a hop with an expired TTL value, that device sends (is supposed to send) an ICMP TTL Expired message back to the source.

Expired TTL messages are frequently filtered in a "baby with the bathwater" security scheme of "nothing gets through unless explicitly permitted."

ICMP is a common source for a number of attacks, so it is generally filtered as a complete protocol, with specific elements permitted, like ping (and possibly TTL Expired/Exceeded).

That is why a ping (even extended ping) works, but a traceroute / tracert does not.

I think that's generally what everyone is trying to say and getting wound up with the semantics.

(This does not take into account the various types of pings ... I'm talking standard TCP/IP suite variety of PING).

Good Luck

Scott

nissanka123 · ‎05-31-2008

Thanks Scott for the comments.

I tried or you can try ' ping www.google.com ' and it works.

What is the extended ping command?

I work with Linux.

scottmac · ‎05-31-2008

Extended ping (at least in this venue, I believe) refers to a facility on many Cisco devices that provides a list of parameters you can change for diagnostic purposes.

On the device (probably a router in most cases) instead of saying "ping 10.20.30.40" you just say "ping", and it asks a list of questions, like:

Mac_Rack-TS#ping

Protocol [ip]:

Target IP address:

% Bad IP address

Mac_Rack-TS#ping

Protocol [ip]:

Target IP address: 10.20.30.40

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 172.16.1.56

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.20.30.40, timeout is 2 seconds:

Whereas your average *nix (this example is Red Hat Enterprise 5.1):

[root@rhel1 ~]# ping

Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]

[-p pattern] [-s packetsize] [-t ttl] [-I interface or address]

[-M mtu discovery hint] [-S sndbuf]

[ -T timestamp option ] [ -Q tos ] [hop1 ...] destination

Ping of Google from MS Windows XP:

C:\Documents and Settings\scottmac>ping www.google.com

Pinging www.l.google.com [64.233.167.99] with 32 bytes of data:

Reply from 64.233.167.99: bytes=32 time=13ms TTL=244

Reply from 64.233.167.99: bytes=32 time=11ms TTL=244

Reply from 64.233.167.99: bytes=32 time=12ms TTL=244

Ping statistics for 64.233.167.99:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 11ms, Maximum = 13ms, Average = 11ms

C:\Documents and Settings\scottmac>

Ping of Google.com from RHEL5.1:

[root@rhel1 ~]# ping www.google.com

PING www.l.google.com (64.233.167.104) 56(84) bytes of data.

64 bytes from py-in-f104.google.com (64.233.167.104): icmp_seq=1 ttl=244 time=15.6 ms

64 bytes from py-in-f104.google.com (64.233.167.104): icmp_seq=2 ttl=244 time=13.4 ms

64 bytes from py-in-f104.google.com (64.233.167.104): icmp_seq=3 ttl=244 time=12.7 ms

64 bytes from py-in-f104.google.com (64.233.167.104): icmp_seq=4 ttl=244 time=14.0 ms

64 bytes from py-in-f104.google.com (64.233.167.104): icmp_seq=5 ttl=244 time=14.4 ms

64 bytes from py-in-f104.google.com (64.233.167.104): icmp_seq=6 ttl=244 time=12.7 ms

64 bytes from py-in-f104.google.com (64.233.167.104): icmp_seq=7 ttl=244 time=14.1 ms

--- www.l.google.com ping statistics ---

7 packets transmitted, 7 received, 0% packet loss, time 5999ms

rtt min/avg/max/mdev = 12.786/13.905/15.664/0.938 ms

[root@rhel1 ~]#

Hope this helps

Scott

nissanka123 · ‎05-31-2008

Thanks Scott

So this is purely for Cisco routers. This borders proprietary commands.

I don't have a Cisco router at home. When I studied networking, I worked with Cisco routers.

I bought a simple D-Link router.