Re: Do network diagnostic tools need upgrade?

[Andre Gironda <andre () operations net>]

Oldies, but goodies:
shaperprobe (1st), pchar (3rd), tcptrace.org, lft (4th), iftop, nsping
(2nd), iperf, sjitter, pathneck (3rd)

These are newer --
http://www.internet2.edu/products-services/performance-monitoring/performance-tools/
(OWAMP,
2nd) -- http://paris-traceroute.net (4th) --
http://packetdrill.googlecode.com

dre



On Mon, Feb 3, 2014 at 4:33 PM, Ammar Salih <ammar.alsalih () gmail com> wrote:

> Hello NANOG list members,
>
>  I have a question for you, are you happy with the current network
> diagnostic tools, like ping, trace route .. etc, don't you think it's time
> to have an upgraded version of icmp protocol? from my side there is a lot
> that I can NOT do with current tools and protocols, here are few scenarios,
> and I would like to hear yours:
>
>
>
> First scenario:
>
>  To be able to troubleshoot advanced networks with complex QoS and
> policy-based routing configuration, where ping, traceroute and other
> network diagnostic tools do not provide accurate readings, for example, you
> are troubleshooting a web server with ping, and it looks functioning quite
> well (packet loss and round trip time is all good), but web services are
> still significantly slow, the fact is icmp and tcp:80 might have different
> priorities and bandwidth limits on each router along the path between the
> client and the server, in this case, network admins usually use telnet
> applications like (Paping), well it may help if the forward and return path
> of all packets are exactly the same.
>
>
>
> Second scenario:
>
> So another possible scenario is that you need to determine readings for
> forward and return paths, TraceRoute for example gives you forward path
> only using icmp. But what if you need to troubleshoot a VoIP server for
> example, assuming that packets return path might not be the same as forward
> path.
>
>
>
> Third scenario:
>
> One of the most common problems in networking, is that you don't have
> access to all equipment between client and server, but you have to
> troubleshoot the path between them and to understand where the problem
> exactly is in order to contact the right person without having the
> privilege to check the configuration on each router.
>
>
>
> Fourth scenario:
>
> Also, with trace route you can't determine the actual path, for example,
> the router may direct http traffic to proxy server while leaving other
> traffic going through a different hop.