Questions:
  1. Traceroutes to routers
  2. TraceRoute from windows
  3. TraceRoute from Mac
  4. How traceroutes work
  5. How much bandwidth can you handle?
Answers:
  1. 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


    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 * *


    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.
  2. TraceRoute from windows
    The traceroute command for windows is "tracert 209.239.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.
  3. 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.
  4. How traceroutes work
    Here is how 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), and 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", I think, which traceroute now knows it found the host it was tracing to.


    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 dont 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)


    I hope this explains what traceroute is doing and how times CAN accumulate.


    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, or whatever. 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. It is just my transmit is your receive. 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 error'ng 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 * *


    Bottom line is 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.
  5. How much bandwidth can you handle?
    THE QUESTION:
    How much bandwidth per second in terms of no. of HITS and MB can my dedicated machine with Linux and Apache theoretically handle?


    I don't mean number of domains, I mean on an average how many MB/second and how many hits/second can the server take without the processor usage reaching too high.


    THE ANSWER:

    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. So, it really is dependent on what your specific box has to process in addition to simply handling the transfer.


    I have seen some boxes run with 60 gigs of traffic and over 2 million hits a month when most of their traffic is comprised of downloads and basic html pages. I have also seen the same type of box top out with under 10gig of traffic a month and less than 500,000 hits because they have inefficient cgi programming that requires a lot of memory and processor time.


    I hope this helps explain the situation.