Subject: discriminate ping & traceroute

From: [email-masked]
Date: Fri, 7 Feb 2003 11:03:55 +0900

Hi !
 
I have some question for ping and traceroute in draft "Detecting MPLS Data
Plane Liveness".
 
In draft, ping ICMP Message should reach the end of the path(Egress LSR). 
 
Ping Message is sent to the control plane of the egress LSR. 
 
And, Traceroute ICMP Message is sent to the control plane of each transit
LSR.
 
If yes, How could I discriminate between two messages at each transit LSR ?
 
Best Regards 
 
Ryu Ho Yong.
Internet Department Technology
Netwrok Labratory
Electronics & Telecommunications Research Institue (ETRI)

---

From: [email-masked]
Date: Fri, 7 Feb 2003 18:25:58 +0100

Hi, 

well I have not read the spec in detail   but ip workes like this

ping is a aplication that uses a icmp echo-request and will get a icmp
echo-reply back TTL will always be valid ie a non zero value in the ip
header

for traceroute the outgoing packet could be a lot of different kind
traditionaly its a udp packet but it could be icmp echo-request to
(microsoft is doing this, they just have to do it in a different way)
the important thing for a traceroute packet is that it always has a TTL
value of zero, when you should respond to it and traceroute will usualy get
a icpm destination unreachable back with sub-code of TTL-exeded in transit
since the packet is droped due to TTL value is zero

ps i hope you remember how traceroute work.

/micke

At 11:03 2003-02-07 +0900, you wrote:

Hi ! 

  

  
Best Regards 
  
Ryu Ho Yong.

---

From: Konar Allan-MGIA0525 <[email-masked]>
Date: Fri, 7 Feb 2003 16:34:50 -0500

In most Unix platforms, this is done using a UDP message (nowadays), but,
traditionally, it was all icmp.  Ping is usually implemented using the
Internet Control Message Protocol (ICMP) ECHO facility.  It is also possible
to implement a ping capability using alternate methods, some popular
implementations of which are:
- Using the UDP echo port (7), if supported.
  This is defined by RFC 862
- Timing an SNMP query
- Timing a TCP connect attempt

More explicitly, traceroute will send an icmp echo to the destination
address with a ttl of one, so that when it transits the next hop, the ttl is
decremented and a ttl exceeded is sent.  Then sending host then sends the
next icmp echo with a ttl of one and two hops later, it is returned with ttl
exceeded.  This is continued (incrementing the sending ttl) until it reaches
the destination, at which point we get the final response and can display
the full path (and min/max/average response times).  

In general, almost any request/response flow can be used to generate a
round-trip time.  Often many of the non-ICMP ECHO facility methods stand a
better chance of yielding a good response (not timing out for example) since
some routers don't honor Echo Requests (timeout situation) or they are
handled at lower (or higher) priority, hence possibly giving false
indications of round trip times.

In the Unix world, Traceroute is usually implemented by transmitting a
series of probe packets with increasing time-to-live values.  A probe packet
is a UDP datagram encapsulated into an IP packet.  Traceroute works by
sending a sequence of User Datagram Protocol (UDP) datagrams to an invalid
port address at the remote host.  Using the default settings, three
datagrams are sent, each with a Time-To-Live (TTL) field value set to one.
The TTL value of 1 causes the datagram to timeout as soon as it hits the
first router in the path; this router will then respond with an ICMP Time
Exceeded Message (TEM) indicating that the datagram has expired.

Another three UDP messages are now sent, each with the TTL value set to 2,
which causes the second router to return ICMP TEMs.  This process continues
until the packets actually reach the other destination.  Since these
datagrams are trying to access an invalid port at the destination host, ICMP
Destination Unreachable Messages are returned indicating an unreachable
port; this event signals the Traceroute program that it is finished and can
display the round-trip delay associated with each of the attempts
(min/max/average).

As to the original question, I guess I'm missing the gist of what's being
asked...but, if I'm interpreting it correctly, the question is how will the
transit LSRs be able to differentiate between MPLS Traceroutes and Pings -
and from what I can gather from the  "Detecting MPLS Data Plane Liveness"
draft, there is no difference between the two types of
messages--specifically, the Traceroute mechanism will mimic the standard IP
Traceroute mechanisms by sending MPLS pings with incrementing TTLs.  That
means that when a transit LSR receives an MPLS Ping with a TTL of one, it
will decrement to zero and respond to the sender, whose job it will be to
send the next MPLS Ping with a TTL of two, etc.

I hope this helps.

Cheers,
a

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 07, 2003 12:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: discriminate ping & traceroute

Hi, 

/micke

Hi ! 

  

  
Best Regards 
  
Ryu Ho Yong.