|
What you are asking for is a full performance analysis of your network. That's a pretty reasonable thing to want and yet somehow it's not very easy to produce.
First let's get a few ideas and some vocabulary out where we can use them. An important distinction is whether the "apparent" performance of your network is really about the end hosts, the network, or about the applications using the network. Or a combination of all of the above.
We're really talking about defining the end-to-end network path properly. And then, we're talking about promoting a testing methodology that gives you the best feedback on each of those aspects of the performance.
For example, if a particularly long network path was exhibiting mild packet loss (nothing noticeable with ping), and you were using a Reno-based TCP application that performed intermittent file transfer (like a browser) and you had a poor NIC driver, the application would constantly be inhibited by a combination of slow start and congestion avoidance. Heavily graphic web pages, for example, would download really slowly. But is your network really that slow? No, it's about the end hosts and the application conspiring to limit the performance.
So you first you want to separate out the network itself. You want to use a known pair of end hosts that are performing well and use the right tools for the analysis. Then you can be sure that neither the end hosts nor the applications are the limiting factors. Then you can select your methodology, either stressing the network to identify weaknesses or sampling the network non-intrusively to measure it during actual use.
If you go with stressing, you will have to do after-hours testing and it won't reveal what the regular traffic is contributing to the conditions. A public domain tool like iPerf is excellent for this kind of occasional stress testing - you can deploy it at each site and schedule regular tests. Alternately, industrial strength solutions like SmartBits (hardware) or NetIQ Chariot (software) are available. They will tell you the max bandwidth you can achieve, stuffing packets down the pipe. This will truly test the SLA of your ISP.
If you want to do testing during regular use, you would apply a sampling approach that doesn't disturb the network. This also has the advantage of measuring the traffic present as well as the maximum achievable bandwidth. And it gives a much better sense of the behavior of the network at any given moment. Naturally my favorite tool for that job is appareNet.
This will get you the answer to your original question - confirming the bandwidth that your system has available. But it may not be where your performance limiters reside.
Having isolated the network from the end-to-end equation, identified any problems, resolved them and proven its performance, then you turn your attention to the end hosts, checking each one (across a known good network path) against a known clean end-host. Drivers, NICs, bad cables, duplex mismatches can all be uniquely identified.
Finally, having swept networks and machines for issues, you can turn your attention to the applications that are being used. Application performance can be much trickier since each has its own needs and characteristics. Depending on the critical usages, optimizing the network's use can be approached by mirroring, traffic shaping, protocol analysis and other techniques.
I apologize for the long answer - I find that somewhere in this overview are the specific solutions that you need to resolve the information that you need.
|
