Knowledgebase: Connection
What
is a traceroute?
The traceroute will show each router and the response times for the full
route from your computer to the server your site is hosted on. Our network
will be the last two 'hops' of the traceroute. If there are any asterisks
instead of times the packet was lost. If you see three asterisks at one
hop that link is dead and you will not be able to see your site.
How
do traceroutes work?
A traceroute packet starts from the machine that requested the traceroute.
This packet is created with a TTL(Time To Live) bit of 1. When the first
gateway/router receives the packet it decrements the packet by 1(As every
packet on the network decrements to prevent bouncing packets throughout
the internet) If the TTL = 0, which it would, the router returns an error
indicating that the "TTL was exceeded".
Information about the returned packet would @include the gateway/router's
ip, which is displayed on the command line. The "Round Trip Packet"
(from the time it left the host to the time it returned from the gateway/router)
time is calculated and displayed as well. This is the time from which
it left to the time it returned. If that was not the destination host,
traceroute initiates another packet but increments the TTL to 2.
The first gateway/router decrements the TTL and if it is not 0 it sends
it to the next gateway/router which in turn decrements the TTL and which
should equal 0 at this point. This, again, would be a "TTL was exceeded"
error and the receiving gateway/router would return it to the sender.
Traceroute would again calculate the "Round Trip Packet" time
and display that and the ip (or name) of the gateway/router that the packet
erred out on. This can go on and on until it finds the remote host it
was looking for. At this point the UDP packet that was sent, was delivered
to a port that does not accept the UDP packet and returns an error of
"Port not allowed" which traceroute now knows it found the host
it was tracing to.
If there are no packets being sent back with times in them to be viewed.
If this was the case, one router having a mis-configured clock, would
show unbelievable time losses or negative values. Which in turn may cause
packets to start bouncing all over the place.
Example: RT is round trip time and is the total time as error messages
don't have time stamps between gateways/routers.
./traceroute yahoo.com
Increment TTL to 1
ttl=1 --------->Router 1 (ttl - 1 = 0)
RT <---------- Router 1 (error on ttl)
Increment TTL (previous + 1)
ttl=2 ----------->Router 1 (ttl - 1 = 1)
Router 1 ------------> Router 2 (ttl - 1 = 0)
RT <-------------------------------Router 2 (error on ttl)
Increment TTL (previous + 1)
ttl=3 ------------>Router 1 (ttl - 1 = 2)
Router 1 ------------> Router 2 (ttl - 1 = 1) (Yahoo.com)
Router 2 ---------->RemoteHost
RT <------------------------------------------------- RemoteHost
(Port not allowed error)
Packets may get to a route and return quickly, then the next time through
the route, (could be the other side of the router), they appear to be
slower. Packets may never be consistent as you may hit congestion one
time, or you may be going through a router that responded poorly on the
first packet but is able to send the packet to the next router quickly.
There could be many causes for latency in packets.
Saying that it may be the receive side or the transmit side is not relevant
if one direction is good and the other is bad. Because, they both are
using the same transmitting and receiving paths. Now, if a router is bogged
down, it would also show slowness when getting through it. But if I send
a traceroute out with excellent times making the first couple of hops
and traceroutes coming in are displaying poor times, it would mean that
there is latency somewhere in the poor traceroutes path.
I noticed a few of the customers traceroutes that had displayed 1200,
or so, ms at our router. But if you looked closely there was a 1200 ms
loss earlier in the path. Remember, the packets following that first lengthy
response will be using that exact same path and may display further losses
down the route.
Traceroutes sent to a router should not be expected to respond to the
"destination unreachable" probe. This error is an error that
the destination host that is requested is supposed to respond with. This
is when traceroute, or any other form of traceroute, terminates. All other
routers and such in between the originating and destination hosts, just
move the packet along after stripping of a TTL bit, or erroring out at
the next hop when the TTL has been reached.
Most all routers do not consider the destination unreachable message a
priority to respond to. Which makes sense if you don't want your router
to be bombarded with bogus ports to take the router down. i.e. a Denial
of Service (DoS) attack. Here are some example of tracerouting through
a router then to a router.
Through multiple routers: traceroute to yahoo.com (204.71.200.245), 30
hops max, 40 byte packets
1 209.239.32.1 (209.239.32.1) 1.508 ms 1.233 ms 3.596 ms
2 209.201.44.9 (209.201.44.9) 1.400 ms 1.546 ms 0.978 ms
3 Serial4-1-0.core2.dca1.IConNet.NET (204.245.69.194) 2.591 ms 2.451ms
2.567 ms
4 POS6-0-0.peer1.dca1.IConNet.NET (204.245.71.10) 3.186 ms 2.528 ms3.473
ms
5 fddi3-0.cr1.dca.globalcenter.net (192.41.177.113) 8.625 ms 7.854ms 7.292
ms
6 fe2-0-0.br1.DCA.globalcenter.net (204.152.166.13) 4.435 ms 4.077 ms
10.195 ms
To router 204.245.71.10: traceroute to 204.245.71.10 (204.245.71.10),
30 hops max, 40 byte packets.
1 209.239.32.1 (209.239.32.1) 1.391 ms 1.409 ms 1.473 ms
2 209.201.44.9 (209.201.44.9) 2.258 ms 0.741 ms 3.064 ms
3 Serial4-1-0.core2.dca1.IConNet.NET (204.245.69.194) 3.321 ms 4.426ms
3.132 ms
4 POS6-0-0.peer1.dca1.IConNet.NET (204.245.71.10) 5.052 ms * 2.714ms
To router 192.41.177.118: traceroute to 204.152.166.13 (204.152.166.13),
30 hops max, 40 byte
packets.
1 209.239.32.1 (209.239.32.1) 16.559 ms 1.286 ms 0.932 ms
2 209.201.44.9 (209.201.44.9) 1.646 ms 3.230 ms 2.976 ms
3 Hssi12-0-0.core1.dca1.IConNet.NET (204.245.69.50) 2.678 ms 2.879ms 3.101
ms
4 POS0-0-0.peer1.dca1.IConNet.NET (204.245.71.6) 3.332 ms 5.094 ms2.615
ms
5 fddi2-1-0.br1.dca.globalcenter.net (192.41.177.118) 21.116 ms * *
If a customer is using our router as an example, we can only consider
the ms it took not the timeouts. So this does not make for a good traceroute
to troubleshoot with. We must traceroute through the routers to find connections
that are slow or that are broken.
Traceroute
from Windows?
The traceroute command for windows is "tracert xxx.xxx.xxx.xxx"
or the domain name can be used in place of the IP. Hit 'start' on the
taskbar and then Programs and then MS-DOS Prompt and enter the command
at the prompt.
Traceroute
from Mac?
WhatRoute is a free program that is available over the Internet. With
this program you will be able to run a traceroute from your MAC computer
to the server that hosts your site. You can find this program at http://shareware.com.
Search for traceroute under Macintosh. WhatRoute is a third party software
and thus we do not offer support. It is also shareware and users use it
at their own risk.
Traceroutes
to routers?
Traceroutes sent to a router should not be expected to respond to the
"destination unreachable" probe. This error is an error that
the destination host that is requested is supposed to respond with. This
is when traceroute, or any other form of traceroute, terminates. All other
routers and such in between the originating and destination hosts, just
move the packet along after stripping of a TTL bit, or erroring out at
the next hop when the TTL has been reached.
Most all routers do not consider the destination unreachable message a
priority to respond to. Which makes sense if you don't want your router
to be bombarded with bogus ports to take the router down. i.e. a Denial
of Service (DoS) attack. Here are some example of tracerouting through
a router then to a router.
Through multiple routers:
Traceroute to yahoo.com (204.71.200.245), 30 hops max, 40 byte packets
1 209.239.32.1 (209.239.32.1) 1.508 ms 1.233 ms 3.596 ms
2 209.201.44.9 (209.201.44.9) 1.400 ms 1.546 ms 0.978 ms
3 Serial4-1-0.core2.dca1.IConNet.NET (204.245.69.194) 2.591 ms 2.451ms
2.567 ms
4 POS6-0-0.peer1.dca1.IConNet.NET (204.245.71.10) 3.186 ms 2.528 ms3.473
ms
5 fddi3-0.cr1.dca.globalcenter.net (192.41.177.113) 8.625 ms 7.854ms 7.292
ms
6 fe2-0-0.br1.DCA.globalcenter.net (204.152.166.13) 4.435 ms 4.077 ms
10.195 ms
Bottom line is if a client is using our router as an example, we can only
consider the mili-seconds it took not the timeouts. So this does not make
for a good traceroute to troubleshoot with. We must traceroute through
the routers to find connections that are slow or that are broken.
How
much bandwidth can you handle?
The difficulty with this question is that it deals with a very subjective
situation. The limit on the bandwidth is really limited by the machine's
processor, memory and disk throughput. It's not limited by our local ethernet
which is all switched 100Mb ethernet, nor would it ever be bottlenecked
by our connection to the Internet.
The limit also depends on what you consider acceptable performance for
a web server. Acceptable performance is usually measured by either the
machine's load average or the percentage of memory being used. As these
two numbers increase the machine's performance will gradually decrease
until it crashes.
With this in mind please know that the type of traffic also effects the
total amount that a box can take on. If most of your traffic is straight
html pages then you would be able to handle more bandwidth on that box
than a box that has a number of perl scripts or mySQL queries that have
to run and serve up dynamic content. CGI and queries will exhaust the
system resources much quicker and thus limit the amount of traffic that
a server can handle. It really is dependent on what your specific box
has to process in addition to simply handling the transfer.
© 2003 Burningbulb.net |
