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 which shows an average of 2ms round-trip response time.
interface FastEthernet0/0
ip address 100.1.1.1 255.255.255.252
duplex auto
speed auto
R4-2610#ping
Protocol [ip]:
Target IP address: 100.1.1.1
Repeat count [5]: 100
Datagram size [100]: 100
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 60-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms
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.
interface FastEthernet0/0
ip address 100.1.1.1 255.255.255.252
duplex auto
speed auto
traffic-shape rate 32000 1000 0 1000
R6-2620#show traffic-shape
Interface Fa0/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
- 32000 125 1000 0 31 125 -
R6-2620#
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:
R4-2610#ping
Protocol [ip]:
Target IP address: 100.1.1.1
Repeat count [5]: 100
Datagram size [100]: 105
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 105-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/29/33 ms
R4-2610#
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?
R6-2620#show traffic-shape statistics
Acc. Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed Active
Fa0/0 0 108 12885 94 11377 no
R6-2620#
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!
R4-2610#ping
Protocol [ip]:
Target IP address: 100.1.1.1
Repeat count [5]: 100
Datagram size [100]: 106 <----- increased to 106
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 106-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/29/56 ms
R4-2610#
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.
interface FastEthernet0/0
ip address 100.1.1.1 255.255.255.252
duplex auto
speed auto
traffic-shape rate 16000 1000 0 1000
R6-2620#show traffic-shape
Interface Fa0/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
- 16000 125 1000 0 62 125 -
R6-2620#
R4-2610#ping
Protocol [ip]:
Target IP address: 100.1.1.1
Repeat count [5]: 100
Datagram size [100]: 105
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 105-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/58/65 ms
R4-2610#
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.
