Traceroute “Working & Example”
===================================================
TRACE ROUTE IS THE PATH TAKEN BY A PACKET TO THE
INTERNET.
Traceroute
is a very handy tool available in most of the operating systems by default.
Network
Engineers use this tool most commonly in their day to day activities. It’s
basically a network diagnostic tool that comes very handy.
The
primary objectives of traceroute tools are:
·
It
tells us about entire path that a packet travels through source and
destination.
·
It
tells us about names and identity of routers and devices in the path
·
It
tells us the time taken to send and
receive data to each devices
[Referred
as Network Latency] on the path.
Working
of Traceroute:
================
================
Basics:
Each IP packet that we send on
the internet has got a field called as TTL. TTL stands for Time To Live.
Although it’s called as Time to live, it’s not actually the time in seconds.
Image: IP Packet à TTL is an 8-bit field – so
maximum values is 255.
Note: TTL is not measured by the no. of seconds but the no. of
hops. It’s the maximum number of hops that a packet can travel through across
the internet, before it’s discarded.
Hops
can be computers, routers, or any other devices that comes in between the
source and the destination.
Need of TTL: [What if there was no TTL at all]
==========
If
there was no TTL in an IP packet, the packet will flow endlessly from one
router to another and on and on forever searching for the destination.
TTL value is set by the sender inside his IP packet (the person using the
system, or sending the packet, is unaware of these things going on under the
hood, but is automatically handled by the operating system).
If
the destination is not found after traveling through too many routers in
between ( hops ) and TTL value becomes 0 (which means no further travel) the
receiving router will drop the packet and informs the original sender.
Original sender is informed that the TTl value
exceeded and it cannot forward the packet further.
A SIMPLE EXAMPLE:
==================
Let's
say we need to reach this ip address 10.5.77.88, and my default TTL value is 30
hops. Which means I can travel a maximum of 30 hops to reach my destination,
before which the packet is eventually dropped.
How does the routers in between
determine the TTL value limit has reached??
==========================================================
Each router that comes in between the source
and destination will go on reducing the TTL value before sending to the next
router. Which means if I have a default TTL value of 30, then my first router
will reduce it to 29 and then send that to the next router across the path.
The
receiving router will make it 28 and send to the next and so on. If a router
receives a packet with TTL of 1 (which means that packet cannot go forward),
the packet is discarded.
The router which discards the packet will inform the original
sender that the TTL value has exceeded!
This
information send by the router receiving a packet with TTL of 1 back to the
original sender is called as "ICMP TTL exceeded messages”. In
internet when you send something to a receiver, the receiver will come to know
the address of the sender.
Hence
when an ICMP TTL exceeded message is sent by a router, the original sender will
come to know the address of the router.
Traceroute makes use of this TTL
exceeded messages to find out routers that come across your path to destination
(Because these exceeded messages send by the router will contain its address).
How
does Traceroute find out routers/hops in its path travelled?
Using
“TTL exceeded message”?
==============================================
==============================================
We
might be thinking, TTL exceeded messages are only send by the router that
receives a packet with TTL of 1. That's correct, every router in between you
and your receiver will not send TTL exceeded message. Then how will you find
the address of all the routers/hops in between you and your destination.
Because the main purpose of Traceroute is to identify the hops between you and
your destination.
But we can exploit this behaviour of
sending TTL exceeded messages by routers/hops in between by purposely sending
an IP packet with a TTL value of 1.
Below
is a diagram, where a sender does a traceroute towards one of the servers at a
Remote
location.
So
let's say we want to do a traceroute to Google’s publicly available DNS server
(8.8.8.8).
Let's see what happened here.
When I issue command of traceroute -n 8.8.8.8, what my computer did
is –It made a UDP packet, this UDP
packet will contain the following things.
Ø
My Source Address (Which is my
IP address)
Ø
Destination address (Which is
8.8.8.8 – Google DNS )
Ø
Destination UDP port number
which is invalid. Means the traceroute utility will send packet to a UDP port
in the range of 33434 to 33534, which is normally unused.
Actual Working Steps:
=================
Step
1: My
Source address will make a packet with destination ip address of 8.8.8.8 and a
destination port number between 33434 to 33534.The important thing it does
it to make the TTL Value 1.
Step
2: My
packet will reach the gateway server. On receiving the packet my gateway server
will reduce the TTL by 1 (All routers/hops in between does this job of reducing
the TTL value by 1). Once the TTL is reduced by the value of 1 (1-1= 0), the
TTL value becomes zero. Hence my gateway server will send me back a TTL Time
exceeded message. Please remember that when my gateway server sends a TTL
exceeded message back to me, it will send the first 28 byte header of the
initial packet I send.
Step
3: On receiving this TTL Time exceeded message, my
traceroute program will come to know the source address and other details about
the first hop (Which is my gateway server.).
Step
4: Now the traceroute program will again send the same
UDP packet with the destination of 8.8.8.8, and a random UDP destination port
between 33434 to 33534. But this time I will make the initial TTL
2. This is because my gateway router will reduce it by 1 and
then forwards that same packet which send to the next hop/router (the packet
send by my gateway to its next hop will have a TTL value of 1).
Step
5: On receiving UDP packet, the next hop to my gateway
server will once again reduce it to 1 which means now the TTL has once again
become 0. Hence it will send me back a ICMP Time exceeded message with its
source address, and also the first 28 byte header of the packet which i send.
Step
6: On receiving the
message of TTL Time Exceeded, my traceroute program will come to know about
that hop/routers IP address and it will show that on my screen.
Step
7: Now again my traceroute program will make a similar
UDP packet with again a random udp port with the destination address of
8.8.8.8. But this time the ttl value is made to 3, so that the ttl will
automatically become 0, when it reaches the third hop/router (Please remember
that my gateway and the next hop to it, will reduce it by 1). So that it will
reply me with a TTL Time exceeded message, and my traceroute program will come
to know about that hop/routers IP address.
Step
8: On receiving that reply, the traceroute program
will once again make a UDP packet with TTL value of 4 this time. If i gets a
TTL Time exceeded for that also, then my traceroute program will send a UDP
packet with TTL of 5 and so on.
But
how will my traceroute program come to know that the final destination of
8.8.8.8 has reached. The traceroute program will come to know about that
because, when the original receiver of the packet 8.8.8.8 (remember that all
UDP packet had a destination address of 8.8.8.8) gets the request it will send
me a message that will be completely different from all the messages of "TTL
Time exceeded".
When
the original receiver (8.8.8.8) gets my UDP packet, it will send me a "ICMP
Destination/PORT Unreachable" message. This is bound to happen
because we are always sending a random UDP port between 33434 to 33534. Hence
my Traceroute program will come to know that we have reached the final
destination and will stop sending any further packets.
Now
anything described in words is called a theory. We need to confirm this, by
doing a tcpdump while doing a traceroute. Let's see the tcpdump output. Please
note that I will not show you the entire output of tcpdump because it too long.
Run
traceroute on one terminal of your linux machine. And on another terminal run
the below tcpdump command to see what happens.
The above output only shows the
UDP packets my machine send. I will show the reply messages separate to make
this clearer.
Note:
The
TTL value on each line. It starts from TTL of 1 and then 2, and then 3 till TTL
6. But you might be wondering why my server is sending 3 UDP messages with TTL
value of 1 and then 2 and then 3.
The
reason behind this is to calculate an average Round Trip Time. Traceroute
program sends three UDP packets to each hop to measure the exact average round
trip time. Round trip time is nothing but the time it took to send and then
receive the reply in milliseconds. I purposely didn't mention about this in the
beginning to avoid confusion.
So the bottom line is my traceroute
program sends three UDP packets to each hop to simply calculate the round trip
average. Because the traceroute output shows you those three values in its
output. Please see the traceroute output more closely. It shows three
millisecond values for each hop. To get a clear idea about the round trip time.
Now
let's see the reply we got from all the hops through TCPDUMP. Please note that
the reply messages am showing below are part of the same tcpdump i did above,
but showing you separately to make this more clear.
One
more interesting thing to note is that each time my traceroute program is
sending a different random UDP port number. This is to identify the reply
belonged to which packet. As told before the reply messages send by the hops
and destination contains the header of original packet we send, hence
traceroute program can accurately calculate the round trip time (For each three
UDP packets send to each hop), as it can easily identify the reply and
correlate. The random port numbers are sort of identifiers to identify the
reply.
The
reply messages looks like the below.
Please
note the ICMP time exceeded messages in the reply shown above (I have not shown
all reply messages).
Now
let me show the final message which is different than the ICMP time exceeded
message. This messages is a destination port unreachable, as told before. And
my traceroute program will come to know that our destination has reached.
Note
that there are three replies from 8.8.8.8 to my traceroute program. As told before
traceroute sends three similar UDP packets with different ports to simply
calculate the round trip time. The final destination is nothing different.
Different
types of Traceroute program
============================
============================
There
are different types of traceroute programs. Each of them works slightly
differently. But the overall concept behind each of them is the same. All of
them uses the TTL value.
Why
different implementations? That because you can use the one which is applicable
to your environment. If suppose a firewall block the UDP traffic then you can
use another traceroute for this purpose. The different types are
mentioned below.
Ø UDP Traceroute
Ø ICMP traceroute
Ø TCP Traceroute
The one we used previously is UDP
traceroute. It’s the default protocol used by Linux traceroute program. However we can ask our traceroute utility in Linux to use ICMP instead
of UDP by the below command.
root@work:~# traceroute -I -n 8.8.8.8
|
ICMP for traceroute works the
same way as UDP traceroute. Traceroute program will send ICMP Echo Request
messages and the hops in between will reply with a ICMP Time exceeded messages.
But the final destination will reply with ICMP Echo reply.
Tracert
command available in windows operating system by default uses ICMP traceroute
method.
Now the last is the most
interesting one. Its called TCP traceroute. Its used because almost all
firewall and routers in between allows you to send TCP traffic. And if the
packet is toward port 80, which is the web traffic then most of the routers
allow that packet. TCPTRACEROUTE by default sends TCP SYN requests to port 80.
Source: www.slashroot.in
No comments:
Post a Comment
Note: only a member of this blog may post a comment.