iperf is a measurement tool developed by NLANR. It's been used very
extensively in the research community for projects like Web100 and the
Abilene network. iperf can measure node-to-node throughput, packet loss,
jitter and latency. It has a wide variety of options to measure all
sorts of network characteristics. It runs on Linux, Solaris, Windows,
MacOSX and any other platform that can compile the source-code. iperf
(coupled with MRTG or Cricket for graphing) looks like a great
possibility to actively measure the performance of different kinds of
traffic across the network, and because it is portable and inexpensive,
it could easily be deployed pervasively throughout the network.

But I too like Wireshark

Don Moskaluk
http://moskaluk.com/voip_using_wireless_mesh_infrast.htm


-----Original Message-----
From: Philip Mullis [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 06, 2008 5:47 AM
To: Martin Glazer; Jim Van Meggelen
Cc: John Lange; [email protected]
Subject: RE: [on-asterisk] Tools for troubleshooting voice quality

Packs of scripts are a good idea, however something to monitor the
overall quailty after the install should always be considered. There is
many many many things that can go wonk on a voip install from the tos
being set wrong on a switch to using a voip provider thats too far away
(network speaking)
 
Local network switches can be monitored using snmp bundled with cacti or
mrtg to procude pretty graphical reports, its crude but can give you can
idea of bandwidth spikes on your lan and collisions,cpu usages etc...
programs like ntop will give you detailed usuage on the packets and
break it down by program/protocol.
 
 
Wireshark is great as a general tool to see whats happening, when a
local lan is concerned its always a good tool to get an idea of the
bulk/improperly configured network traffic, ie you may find some random
devices like network video cameras spewing large amounts of broadcasts
accross your switch.
 

 
________________________________

From: Martin Glazer [mailto:[EMAIL PROTECTED]
Sent: Thu 3/6/2008 12:23 AM
To: Jim Van Meggelen
Cc: Philip Mullis; 'John Lange'; [email protected]
Subject: Re: [on-asterisk] Tools for troubleshooting voice quality





Jim Van Meggelen wrote:
> Ideally, I'd want to come up with some recipies that contain useful
tips on
> troubleshooting connectivity and quality problems with the network.
How many
> of us run VoIP sets on our customers' networks, and are forced to
prove
> network troubles to the customer because the tell us "the network is
fine",
> even though there is a lot of evidence to suggest that it is not?
Being able
> to produce more detailed data on why we feel the network is "not fine"
would
> often be of use. Being able to do that without having to spend a lot
of time
> on it, and having access to only the Asterisk server, would make
things a
> lot easier, I suspect.

Having a set of scripts or procedures with some metrics that you can
produce would be ideal and extremely valuable.

In the last few months I've had a few client with "perfect" networks
give problems. If a web page or a file takes a few milliseconds longer
to open due to network issues, it is generally not even noticed, but
throw a real time application into the mix and things can go south real
quickly. The problem, as you say, is proving it.

I've found that because we are dealing with UDP packets, this adds to
the difficulties in proving a network issue. At least with TCP, we can
see whether a transmitted packet arrived or was acknowledged, whereas
with UDP, unless you are monitoring both ends (which most of the time
isn't possible) you cannot.

One command that has helped me is netstat - there is a wealth of network
information available. Twice now when I've suspected network problems on
"perfect" networks, I've used netstat to prove that packets were being
dropped/lost and things weren't so happy.

Try netstat -su or netstat -suc for continuous UDP stats.

Martin



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to