Proposal for two minor improvements in prtraceroute
- Date: Thu, 6 Jan 1994 15:48:08 +0100 (CET)
I have been using the prtraceroute tool (1.0.1 version) on large scale
for the first time, to verify routing through EuropaNET, and I have a request
for correction of an error and a request for improvement of readability of
output. The tool is extremely useful as it is, but as the changes looks quite
easy to make I try anyway ...
This run shows what I mean:
unix prompt# prtraceroute -v 188.8.131.52
traceroute with AS and policy additions [Jan 6 13:48:40 UTC]
from AS2043 iphost.empb.net (184.108.40.206)
to AS2043 220.127.116.11 (18.104.22.168),
1 AS2043 cisadam.empb.net (22.214.171.124) [I]
2 AS2043 amsterdam3.empb.net (126.96.36.199) [I]
3 AS2043 amsterdam5.empb.net (188.8.131.52) [I]
4 AS1128 Amsterdam1.dante.net (184.108.40.206) [D1]
AS Path followed: 2043 1128
AS2043 = European Multiprotocol Backbone
AS1128 = DANTE Gateway in Amsterdam
At first marking above the value should be AS1128, as specified by an
ias-int field in the 220.127.116.11 database entry. The prtraceroute program
discovers that correctly in line 4 below; it would be nice if it was shown
correctly in the header line too.
At second marking above I would like to have the DNS name, again
as is found in line 4 below. I cannot specify the DNS name in the argument
to prtraceroute, as I very often will do prtraceroute to destinations
where one DNS name covers several IP addresses, and I have to control
which IP address to go for. Also, even when the prtraceroute destination
is finally reached (as in the case above) it is by no means certain that
the destination reply with the same IP address as the one I used for
Please note, that I really want the line to read:
to AS1128 18.104.22.168 (Amsterdam1.dante.net),
even if it looks a bit awkward. The much nicer
to AS1128 Amsterdam1.dante.net (22.214.171.124)
would be worse than now, because the reader of that text could be lead to
believe that the original call was
unix prompt# prtraceroute -v Amsterdam1.dante.net
which is not the case.
Thank you in advance for considering these improvements.
Peder Chr. Norgaard, Telebit Communications A/S, Denmark.