Continuing my tests of the Hierarchical Queuing Framework, I’ve tested whether the fair queuing works similarly to the previous IOS implementations, where the high-precedence sessions got proportionally more bandwidth.

Summary: Fair queuing within HQF ignores IP precedence.

Setup

I ran an iperf session in parallel with a UDP flood using the same physical setup as with the previous HQF tests. I’ve configured an inbound service-policy on the LAN interface to ensure the packets belonging to TCP sessions had their IP precedence set to 5 (the default value is zero).

policy-map LAN
 class TCP
  set ip precedence 5
!
interface FastEthernet0/0
 ip address 10.0.0.5 255.255.255.0
 no ip redirects
 load-interval 30
 service-policy input LAN

Baseline tests

I configured weighted fair queuing on a 2 Mbps WAN interface:

interface Serial0/1/0
 bandwidth 2000
 ip address 10.0.1.1 255.255.255.252
 encapsulation ppp
 fair-queue
 ip ospf 1 area 0
 load-interval 30

As expected, the iperf session ran in parallel with a UDP flood got more than half the available bandwidth:

$ iperf -c 10.0.20.10 -t 180 -p 5002
------------------------------------------------------------
Client connecting to 10.0.20.10, TCP port 5002
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1916] local 10.0.0.10 port 1064 connected with 10.0.20.10 port 5002
[ ID] Interval       Transfer     Bandwidth
[1916]  0.0-180.1 sec  35.2 MBytes  1.64 Mbits/sec

The show queue command (which is still available in IOS release 15.0 unless you configure HQF on the interface) displayed two sessions within the WFQ system with expected TOS values and weights (the weight of the TCP session was 6 times lower than the weight of the UDP session):

rtr#show queue serial 0/1/0
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 135567
  Queueing strategy: weighted fair
  Output queue: 64/1000/64/12798 (size/max total/threshold/drops)
     Conversations  2/3/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1500 kilobits/sec

  (depth/weight/total drops/no-buffer drops/interleaves) 57/32384/12799/0/0
  Conversation 10, linktype: ip, length: 260
  source: 10.0.0.10, destination: 10.0.20.3, id: 0xB1C1, ttl: 127,
  TOS: 0 prot: 17, source port 1059, destination port 5002

  (depth/weight/total drops/no-buffer drops/interleaves) 7/5397/0/0/0
  Conversation 11, linktype: ip, length: 1304
  source: 10.0.0.10, destination: 10.0.20.10, id: 0xB382, ttl: 127,
  TOS: 160 prot: 6, source port 1064, destination port 5002

Fair queuing within HQF

To test the fair queuing behavior within HQF I configured a simple policy map which used fair-queue within the default class:

policy-map WAN
 class class-default
    fair-queue

I attached the policy map to the interface …

interface Serial0/1/0
 service-policy output WAN

… and repeated the iperf test:

$ iperf -c 10.0.20.10 -t 60 -p 5002
------------------------------------------------------------
Client connecting to 10.0.20.10, TCP port 5002
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[1916] local 10.0.0.10 port 1062 connected with 10.0.20.10 port 5002
[ ID] Interval       Transfer     Bandwidth
[1916]  0.0-60.0 sec  7.18 MBytes  956 Kbits/sec

This time the TCP session got only half of the bandwidth although its packets had higher IP precedence.