Cisconinja’s Blog

Custom Queueing Byte Count Deficit

Posted by Andy on February 20, 2009

In older IOS versions, the custom queueing byte count deficit was not carried over to the next round robin pass, which could result in bandwidth sharing that was not proportional to the configured byte counts.  This example will demonstrate the behavior of custom queueing with the byte count deficit not being carried over in IOS 12.0(5), and then with the byte count deficit being carried over in IOS 12.4(18).  Since GTS and CB shaping do not support custom queueing on shaping queues, FRTS will be used.  The network topology and configurations are shown below:

topology1

R1:
interface Serial0/0
 no ip address
 encapsulation frame-relay
 load-interval 30
 no keepalive
!
interface Serial0/0.1 point-to-point
 ip address 10.1.12.1 255.255.255.0
 frame-relay interface-dlci 102
!
interface FastEthernet1/0
 ip address 10.1.1.1 255.255.255.0
 load-interval 30
 speed 100
 full-duplex
 no keepalive
 no mop enabled
!
no cdp run

R2:
interface Serial0/0
 no ip address
 encapsulation frame-relay
 load-interval 30
 no keepalive
!
interface Serial0/0.1 point-to-point
 ip address 10.1.12.2 255.255.255.0
 frame-relay interface-dlci 201
!
no cdp run

First we will use IOS 12.0(5) on R1.  PC will be used to generate 2 different types of traffic to UDP ports 1001 and 1002 (for more information on the method of generating traffic, see WFQ tests).  We will send both types of traffic at 8 packets/second with an L3 size of 996 bytes, which will give us 1000 bytes frames with the frame-relay header added.  This will result in 64,000 bps of each traffic type.  The first traffic type (sent to UDP port 1001) will be classified into custom queue 1 and the second traffic type will be classified into custom queue 2.  Queue 1 will be configured with a byte count of 1000 per round robin pass and queue 2 will be configured with a byte count of 1001.  Configuration and verification on R1:

R1:
queue-list 1 protocol ip 1 udp 1001
queue-list 1 protocol ip 2 udp 1002
queue-list 1 queue 1 byte-count 1000
queue-list 1 queue 2 byte-count 1001

cq-config

Next, we will enable FRTS on R1 with a CIR of 64,000 bps and apply the custom queueing configuration to the shaping queues:

R1:
interface Serial0/0
 frame-relay traffic-shaping
!
map-class frame-relay CQ-shaping-policy
 frame-relay cir 64000
 frame-relay custom-queue-list 1
!
interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 102
  class CQ-shaping-policy

We will also configure R2 to measure incoming traffic of each type:

R2:
access-list 101 permit udp any any eq 1001
access-list 102 permit udp any any eq 1002
!
class-map match-all 1001
 match access-group 101
class-map match-all 1002
 match access-group 102
!
policy-map Traffic-Meter
 class 1001
 class 1002
!
interface Serial0/0
 service-policy input Traffic-Meter

Now we’re ready to start the 2 traffic streams:

flood.pl --port=1001 --size=996 --delay=125 10.1.12.2
flood.pl --port=1002 --size=996 --delay=125 10.1.12.2

On R1, we can see the FRTS and CQ information:

120-r1pvc

On R2 we can see the amount of each traffic type received:

120-r2pmap

Although the byte count allocated to queue 2 was only .1% more than queue 1 (1001/1000), it has sent exactly twice as many packets and bytes.  This is due to the byte count deficit not being carried over in 12.0(5).  The round robin cycle in 12.0(5) will go like this:

1. CQ takes a 1000-byte packet from queue 1.  The byte count for queue 1 has been met so CQ moves on to queue 2.

2. CQ takes a 1000-byte packet from queue 2.  The byte count for queue 2 has not been met (1000 < 1001), so CQ will take another packet from queue 2.

3. CQ takes another 1000-byte packet from queue 2.  The byte count for queue 2 has been met (2000 > 1001).  Since there are no other queues, return to Step #1 and service queue 1 again.

 

Now we will replace R1 with a router running IOS 12.4(18) and put the exact same configuration on it.  On R1, we can see the FRTS and CQ information as well as the packets enqueued in each of the CQ queues:

124-r1pvc

124-r1queue

On R2, the amount of each type of traffic received is shown below:

124-r2pmap

The traffic generator was left running for several hours to show how accurately the proportions of actual traffic sent match the byte counts in more modern IOS versions.  With equal sized packets in each queue, a byte count of 1000 configured for queue 1, and a byte count of 1001 configured for queue 2, queue 2 should be able to send 1 extra packet for every 1000 packets sent by queue 1.  We can see that after a little over 150,000 packets sent by queue 1, queue 2 has sent exactly 150 more packets than queue 1.  The dramatic difference in results is due to the byte count deficit being carried over.  The first 3 rounds of the round robin cycle in 12.4(18) will go like this:

1. CQ takes a 1000-byte packet from queue 1.  The byte count for queue 1 has been met so CQ moves on to queue 2.

2. CQ takes a 1000-byte packet from queue 2.  The byte count for queue 2 has not been met (1000 < 1001), so CQ will take another packet from queue 2.

3. CQ takes another 1000-byte packet from queue 2.  The byte count for queue 2 has been met and exceeded (2000 > 1001).  Subtract the excess bytes (999) from the configured byte count in the next round robin pass through queue 2 (1001 – 999 = 2).  Since there are no other queues, service queue 1 again.

4. CQ takes a 1000-byte packet from queue 1.  The byte count for queue 1 has been met so CQ moves on to queue 2.

5. CQ takes a 1000-byte packet from queue 2.  The byte count for queue 2 has been met and exceeded (1000 > 2).  Subtract the excess bytes (998) from the configured byte count in the next round robin pass through queue 2 (1001 – 998 = 3).  Since there are no other queues, service queue 1 again.

6. CQ takes a 1000-byte packet from queue 1.  The byte count for queue 1 has been met so CQ moves on to queue 2.

7. CQ takes a 1000-byte packet from queue 2.  The byte count for queue 2 has been met and exceeded (1000 > 3).  Subtract the excess bytes (997) from the configured byte count in the next round robin pass through queue 2 (1001 – 997 = 4).  Since there are no other queues, service queue 1 again.

As you can see, with the deficit being carried over, queue 2 will only be allowed to send 2 packets in a single pass once every 1000 rounds, rather than every single pass like in older IOS versions.

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: