July 2003
July 2003 Tip O' the Month – Voice over IP
Are you planning to add VoIP, update firmware on switches, or add other apps
to your network? Ensure you know how your network will be affected!
Voice over IP (VoIP) is becoming common place on networks and its logical progression
demands that it move toward the wireless environment. Network analysts will
have to plan for VoIP and troubleshoot errors and issues as they arise. The
best method of troubleshooting is to be proactive and head most issues off before
they become issues!
EtherPeek NX and AiroPeek NX have several features that will aid you in determining
if you will be able to push specific traffic across your network.
You may go the extreme of modifying packets via the ‘Send’ menu
and sending them out across the network! Generally it is best to use EtherPeek
NX or AiroPeek NX to view application performance and attain baseline/benchmark
measurements for reference prior to a rollout or as a measure of troubleshooting.
There are some logical steps to aid you in your quest for adding additional
applications or protocols to your network. You may follow these steps whether
you are adding VoIP or some other protocol/application to your network.
Begin with a baseline of your network. A baseline measurement is used to gauge
the overall scope of bandwidth used and available on your network. You may have
too many network segments to baseline each one, so pick your most heavily used
or the segments that will be carrying the ‘new’ data. Ideally you
will monitor your network segments 24/7/365, but if this is not possible, try
to baseline over a week-long timeframe or at a very minimum-24 hours. If you
have a day-shift only network, there may be batch files running in the off-hours.
Before you can accept the metrics of your baseline as being accurate, ensure
that there are no major network issues that would offset your findings.
Use EtherPeek’s Summary tab and graphs to gauge utilization. Save this
information for long-term trending and reference for changes in utilization.
This information will allow you to raise flags and prove findings of changed
network performance based on additional network load or vendor revisions relating
to hardware/software/firmware.
After you have baselined your network and know how much bandwidth you have
to spare, it’s time to hit the lab (or filter on an individual node on
the live network).
You now need to capture traffic indicative of the application you are going
to introduce to the network (or that you need to get a handle on). Benchmark
measurements provide you with the amount of bandwidth and latency that is acceptable
for individual applications.
Ideally you will be capturing traffic from a machine that is directly in front
of you; this way you will know exactly what is happening as it relates to the
application’s measurements. Filter so you see only applicable traffic.
Start the capture, boot the test machine then start the application. You will
need to benchmark the client machine booting, opening the application, searching
for files or sending information, and closing the application. Use the ‘annotation’
function to annotate the tracefiles for each step as the packets enter the buffer.
It is important to understand the application that you are benchmarking and
how it works. Each step of the process should be benchmarked. If multiple sessions
are to be run from one user at a time you will need to benchmark the effects
on the application. Some applications are written to support up to 10 clients
on a local network and do not work well across a WAN or with 100 or 1000 clients.
By attaining benchmark measurements in a controlled environment you will be
able to gauge the applications performance on the network. Use the ‘Expert
Tab/ Node Details’ to find delay and throughput for individual applications.
The beauty in using an analyzer in this manner is that if the application doesn’t
work as it did in testing, you will have a benchmark measurement to compare
actual performance to and the ability to troubleshoot what is actually happening!