| .1> By subtracting the RTT times between hops (lines in the output), you can
.1> derive the delay in each segment of the path. It won't tell you what
.1> knid of path, but might suggest how efficient the path is and something
.1> about it's bandwitdth.
I agree with the rest, but not this. Real routers are optimised for
forwarding packets, not for returning error responses. So, the
round-trip-time will be the sum of the real network round trip delays PLUS
the delay at the router to do with catching this unusual packet (TTL going
to 0 is very unusual for real data) and generating the error report. This
second part will be very different for different routers and can easily be
similar to the real network delays.
So, it is *not* safe to subtract two lines. In fact it is not unusual for
the values on one line to be *larger* than the values on the next (because
the difference in delay for generating errors is larger than the delay of
the next hop).
Graham
|
| Hi Graham,
I do agree with your statement about the router optimizations, and the fact
that routers will probably preempt the error packet ( by caching or
other priority schemes...) and contribute to some variances in the RTT
values displayed. And it's true that TTL normally wouldn't go to 0. But
tracert does use that facility to determine the number of hops between
the testing host and the target host.
However, in evaluating an IP network with tracert, once the total path
is known, incremental testing of path segments (ie, running tracert to
known hosts on subnets at each hop boundary) and observing the uniformity
of samples on each test still might yield meaningful information about
the links along the path. For instance, if I have a three hop network
between two hosts, and I run tracert from node A->B and then Node A->C I
should be able to examine the results and at least have a reasonable
idea about the links between A->B and B->C. This would assume that several
tests are executed, and that the sample results returned are reasonably
consistent between test. If the test-to-test samples show large
variations, then by looking at which combinations of hops are involved,
then you should be able to deduce which part of the network (routers,
comms lines, etc.) might be having trouble.
If I'm an engineer troubleshooting a network problem, and this is the
only tool I have access to, then it might just suggest where I should
start looking... Just my perspective on how this tool adds value.
George 8^)
|