o If, from your machine "src", you do
1) traceroute -g victim host # to examine LSRR packet receivability
Then this seems to be testing not only whether "host" can receive LSR
packets, but whether the paths from "src" to "victim" and "victim" to
"host" will pass LSR packets (that is, not filter them out and drop them).
Similarly, if you do
2) traceroute -g host victim # to examine LSRR packet forwardability
Then this seems to be testing not only whether "host" will forward LSR
packets, but whether the path from "src" to "host" and the path from
"host" to "victim" will pass LSR packets.
So, in other words, the test so far seems to be conservative, in that it
is only testing the paths from "src" to "victim", "victim" to "host",
"src" to "host", and "host" to "victim" for _one_ _particular_ value of A
and victim. It could be that different values of "src" and "victim" would
yield more combinations that would be LSR-friendly. For example, it could
be that the path from CMU to foo.com is not LSR-friendly. This would
result in a negative result for this test, even though there may be other
paths into foo.com that are LSR-friendly, and would yield a positive
result for this test.
I guess one way to try to get around this would be to try using all N
hosts as "victim"?
Does this make sense to anybody?
o Another question: is there a particular reason that the list of hosts is
limited to the traceroute servers list? Seems like any list of hosts would
do, right?
neal
On Tue, 22 Sep 1998, Kenichi Ishikawa wrote:
> Here is a summary of LSRR traceroute packet acceptability.
>
> Can Can't Error Total
> Receive normal traceroute packets 248 32 3 283
> Receive LSRR traceroute packets 38 242 3 283
> Forward LSRR traceroute packets 31 249 3 283
>
> Hosts using load balancing magic (such as round robin DNS)
> might be counted as "Can't".
>
> Detail is here.
> http://grad-pc29.cs.washington.edu/~ishi/lsrr/trt.html
>
> --
> Kenichi Ishikawa
>
>