Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

9 module online course

Start now!
back to overview

HQF: intra-class WFQ ignores the IP precedence

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.


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
 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
 encapsulation ppp
 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 -t 180 -p 5002
Client connecting to, TCP port 5002
TCP window size: 8.00 KByte (default)
[1916] local port 1064 connected with 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:, destination:, 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:, destination:, 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

I attached the policy map to the interface …

interface Serial0/1/0
 service-policy output WAN

… and repeated the iperf test:

$ iperf -c -t 60 -p 5002
Client connecting to, TCP port 5002
TCP window size: 8.00 KByte (default)
[1916] local port 1062 connected with 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.

Please read our Blog Commenting Policy before writing a comment.


  1. I think this is exactly what Cisco has been stating in their documentation - fair queue no longer honors QoS marking, i.e. no longer is WFQ. I wonder if they are using stochastic fair queueing now in place of WFQ's byte counting.

  2. So now we know the documentation matches the implementation ;) Not always true ... O:-)

  3. Since you are doing QoS tests, perhaps it would be nice to test also the qos pre-classify.
    What I see is that when you use qos pre-classify the policy-map on the physical interface counts the packet sizes before encryption which I'm not so sure it is correct, and in any case it's a bit confusing, especially when you use also compression etc.

  4. probably this is a bug, it happens on direct encapsulation ipsec, but not in vti


Constructive courteous comments are most welcome. Anonymous trolling will be removed with prejudice.