In order to test VoIP, or any network element, it is important for value-added resellers (VARs) and networking consultants to be able to simulate real world settings. This tip, posted here courtesy of SearchVoIP.com offers a handy (and inexpensive) method for replicating realistic response times in a VoIP lab.
It's always nice to have the right tools to test your ideas before you implement them, and that goes double for VoIP, but we don't always get what we want. If you have a VoIP lab, odds are that the most unrealistic thing about it is that you're probably getting sub-millisecond response, where your real network has WAN circuits that likely range from 10ms to 120ms or occasionally more. It is of course, much easier to simulate WAN delays with one of those expensive tools, but it can be done the hard way.
If you're in a bind, use a regular router and just configure traffic shaping on it. On a Cisco router, you'll want to use "Generic Traffic Shaping", the details of which are well documented at cisco.com.
Below is an example of the easy, one-line configuration (traffic-shape rate <cir> <bc> <be>) and some extended PINGs to show how changing the numbers a bit changes the delay. I configured GTS on the FastEthernet interface of a 2620 and sourced the pings from a 2612 connected to it via a single Catalyst switch.
We start with the basic configuration of the interface and a baseline PING whi...
To continue reading for free, register below or login
To read more you must become a member of SearchNetworkingChannel.com
ch shows an average of 2ms round-trip response time.
Next, I configure a CIR of 32000 bits per second, with a Bc of 1000 bits and Be of 0. The show command explains how the traffic shaping is configured.
Note that this will allow up to 125 bytes every 31ms, so, let's hop to the other router and send 100 PINGs with a datagram size of 105, plus 20 bytes of IP overhead and see what the times look like:
As you can see, we've artificially inserted 27 or so ms of delay into our little network. Back on the 2620, we can see that 94 of our 100 PING packets were delayed. Not bad, eh?
One more interesting thing to note is that if we bump the datagram size to 106, which generates PING packets that exceed our GTS Increment of 125 Bytes, it will cause some of our round-trip times to roughly double the average. In other words... voila!: jitter!
Back to the delay... I've changed the GTS CIR on the 2620 to half its former rate. And this, predictably, increases the Interval to 62ms, which in turn causes our average PING response time to roughly double.
Cutting the configured CIR to 8000 will in turn yield delays around 120ms. Of course, actual results on your hardware, and any hardware, will vary a bit.
About the author
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex.
This tip originally appeared on SearchVoIP.com.
