Cisconinja’s Blog

Testing Queueing Strategies with Dynamips

Posted by Andy on January 19, 2009

Dynamips works great for emulating the majority of Cisco router functions, but some things just don’t work.  I don’t know a ton about dynamips, but from my understanding it does not emulate the physical layer, and therefore the clock rate command does not actually limit the interface speed.  This creates a problem when trying to test software queueing tools, which are only utilized during congestion when the hardware queue fills, because the hardware queue never actually fills up.  From my experience, it seems that the only thing limiting output rate on an interface in dynamips is CPU usage on the computer running dynamips.  The following example demonstrates this:

R1:
interface Serial0/0
 ip address 10.1.1.1 255.255.255.0
 load-interval 30
 no keepalive
 clock rate 64000

R2:
interface Serial0/0
 ip address 10.1.1.2 255.255.255.0
 load-interval 30
 no keepalive
 clock rate 64000

r1-ping

r2-showint5

Each router’s interface has been configured with a 64kb/sec clock rate – however 1173kb/sec worth of traffic are being sent in each direction out of the interface.  There are 0 packets currently in the software queueing system and not a single packet has been dropped since the time the ping command was issued.  I don’t think there is a way to make software queueing occur using dynamips – however a good alternative for testing the various queueing tools is to use traffic shaping and enable the queueing tool on the shaping queues.  Each of the IOS shaping tools vary in which queueing tools they support on the shaping queues – so different types of shaping may need to be used depending on which queueing tool you are trying to test.  The queueing schemes supported by each shaping tool are:

 

GTS – WFQ

FRTS – FIFO, WFQ, CBWFQ, LLQ, PQ, CQ

Class-based Shaping – FIFO, WFQ, CBWFQ, LLQ

 

A couple limitations that initially come to mind are:

1. The throughput in dynamips is limited

2. The actual rate at which traffic is sent is not limited – only the time at which traffic starts to be sent is limited

The first limitation can be dealt with by shaping to a low rate (simulating a low clock rate) so that the traffic being sent through the dynamips router is higher than the shaped rate and causing the shape queues to fill.  The amount of traffic that can be sent through a dynamips network will probably vary depending on the number of routers running in dynamips and how good the PC running dynamips is.

The second limitation is a little bit more tricky.  An interface that is clocked at 64,000 bps should place 1 bit on the wire every 1/64,000 of a second.  A 1500-byte packet would take approximately 187 ms to be serialized onto such an interface (1500*8/64000).  However, if we were to configure shaping in dynamips to a rate of 64000 with a Bc of 12000 (causing Tc to be 187 ms), the packet would be sent as quickly as the PC’s CPU allows – approximately 1,200,000 bps in the simple network shown above on my PC – and then the interface would remain idle until Tc expired and the bucket was refilled.  In this case, the packet would be sent in approximately 10 ms (1500*8/1,200,000) and then no bits would be sent for 177 ms.  Now consider if instead of a 1500-byte packet, 2x 750 byte packets were being sent.  On the physical interface clocked at 64,000 bps, each packet would take roughly 93 ms (750*8/64,000) to serialize and would experience very low jitter.  On the dynamips router, each packet would take roughly 5 ms to be sent (750*8/1,200,000).  The first 2 packets would arrive 5 ms apart, but the 3rd would have to wait another 177 ms for Tc to expire, resulting in a huge amount of delay and jitter for the traffic.  This is similar to the problem that occurs when shaping is enabled on an interface where the clock rate is significantly faster than the shaped rate.  The best solution to this is to configure Bc so that Tc is set to a low value (less than 10 ms if possible). 

If you’re looking for a very accurate way to measure delay or jitter for a specific queueing scheme as if it were being used for software queueing, this probably won’t cut it even with a low Tc value.  However, if you’re looking to test the logic used by a queueing tool’s scheduling process or how a queueing tool divides bandwidth among different flows, using queueing on the shaping queues in dynamips works great.  This also allows other QoS tools that depend on congestion occuring – such as WRED – to be tested in dynamips.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: