Re: smarter version of traceroute

Thanks for the heads up on that program Dee, it really rocks.
Marc

The features I like are :

1) Pick which protocol to use for the traceroute. (UDP, TCP, ICMP)
       Great for those networks that don't allow ICMP or UDP past a
certain point.
       Regular traceroute (debian) defaults to UDP and can use ICMP, but
no TCP.
2) Ability to spawn multiple threads - less waiting as it does more than
one thing at a time
3) Differing algorithms - see below, very cool to learn about how
routing and such really works
4) Extra informations on some hops when it determines that load
balancing, false links, MPLS, etc. is used and might give RatherOdd(tm)
results
        In the example below, look at hop 9 :MPLS Label 31761 TTL=1
       The picture below (inline, check attackments or
http://www.paris-traceroute.net/ if you are ASCII-Solesourced) explains
this too:
      

Usage: traceroute [Options] [Destination]

Options:
  -h, --help print this help
  -V, --version print version
  -v, --verbose print debug messages
  -Q, --quiet print only results
  -f, --first_ttl=TTL set the initial ttl to TTL (default: 1)
  -m, --max_ttl=TTL set the maximum ttl to TTL (default: 30)
  -p, --protocol=PROTOCOL use PROTOCOL to send probes (udp, tcp, icmp)
                           The default is 'udp'
  -s, --source_port=PORT set PORT as source port (default: 33456) pid:
use PID
  -d, --dest_port=PORT set PORT as destination port (default: 33457)
  -t, --tos=TOS set TOS as type of service (default: 0)
  -w MS wait MS ms between each probe (default: 50ms)
  -T, --timeout=MS set a timeout of MS ms on each probe
                           The default is 5000ms
  -q, --query=NBR send NBR probes to each host (default: 3)
  -M, --missing_hop=HOP stop traceroute after HOP consecutive down hops
                           The default is 3
  -a, --algo=ALGO algorithm to use (--algo=help for more help)
                           The default is 'hopbyhop'
  -L, --length=LEN set the packet length to be used in outgoing
packets
                           The default is 0
  -n print hop addresses numerically
                           The default is to print hostnames
  -i --ipid print the IP Identifier of the reply
  -l --print_ttl print the TTL of the reply
  -F targets file for the MT algo
  -B set the bandwidth in packets/s
  -c number of threads (default 1)
  -E probe multiplier

tupleroute - algorithms

  --algo=null Do nothing.

  --algo=hopbyhop Send x packets with the same ttl, then wait
for all
                           replies or a timeout. Increment the ttl and
reiter
                           the operation until we reached the destination.
                           All packets hold the same 5-tuples
(addresses, ports
                           and protocol fields).

  --algo=packetbypacket Send one packet at a time, then wait for a
reply or
                           a timeout. Reiter the operation until we
reached the
                           destination. All packets are exactly the same
except
                           the TTL and checkum fields of the IP header.

  --algo=scout Send a scout probe with a ttl max to the
destination.
                           If the destination can be reached, it
computes the
                           number of hops used to reach the destination and
                           start the concurrent algorithm with a max_ttl
equal
                           to this number of hops. If the destination
cannot be
                           reached, the hopbyhop algorithm will be used
instead.
                           This algorithm is only usable with udp probes

  --algo=concurrent Send all probes from min_ttl to max_ttl and
then wait
                           for all replies or a timeout. All packets
hold the
                           same 5-tuples.

  --algo=exhaustive Tries to classify load balancing
                           and find all the interfaces for each hop.

traceroute [(192.168.60.243:33456) -> (198.51.13.30:33457)], protocol
udp, algo hopbyhop, duration 8 s
 1 astaro.chilly.local (192.168.60.1) 2.544 ms 0.163 ms 0.170 ms
 2 l1-rb1.nwc.acsalaska.net (209.193.63.151) 12.288 ms !T0 12.343 ms
!T0 11.633 ms !T0
 3 fe6-36-cr8.nwc.acsalaska.net (209.193.55.137) 11.967 ms 11.201
ms 11.399 ms
 4 ge6-2-gsr1.nwc.acsalaska.net (209.112.165.140) 11.164 ms 60.512
ms 12.119 ms
 5 216.67.94.81 (216.67.94.81) 42.703 ms 43.224 ms 43.448 ms
 6 sl-gw16-sea-2-4.sprintlink.net (144.228.93.21) 40.246 ms 39.130
ms 40.384 ms
 7 144.232.6.163 (144.232.6.163) 43.355 ms 43.642 ms 42.401 ms
 8 sprint-gw.st6wa.ip.att.net (192.205.32.173) 44.905 ms 166.777
ms 116.511 ms
 9 12.127.6.62 (12.127.6.62) 88.019 ms 344.205 ms 88.705 ms
   MPLS Label 31761 TTL=1
10 12.127.6.121 (12.127.6.121) 99.308 ms 161.364 ms 87.894 ms
11 12.119.146.34 (12.119.146.34) 89.324 ms 150.693 ms 89.328 ms
12 penguin.chilly.net (198.51.13.30) 89.722 ms 324.980 ms 89.301 ms

Royce Williams wrote:
> W.D.McKinney wrote, on 4/13/2007 10:12 PM:
>
>> Fo a much smarter version of traceroute to diagnose network issues, see this:
>> http://www.paris-traceroute.net/
>>
>
> Have you used it? Can you post some output with usage so that we can
> see why it's smarter?
>
> I'm interested in distributed processing; if you've already done some
> basic evaluation and can pass it on to us, we can springboard from
> your work. :)
>
> Royce
>
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Fri Apr 20 05:22:23 2007