Inducing delay in VoIP labs

Some methods for simulating traffic in a VoIP test environment.

This Content Component encountered an error

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.


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 was first published in February 2005

Dig deeper on VoIP Migration and Implementation

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchMobileComputing

SearchNetworking

SearchTelecom

SearchITChannel

SearchEnterpriseWAN

SearchExchange

Close