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.alsa...@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. >
