Reading various documents describing Class-Based Weighted-Fair-Queueing (CB-WFQ) one gets the impression that the following configuration …
class-map match-all High
match access-group name High
bandwidth percent 50
service-policy output WAN
ip access-list extended High
permit ip any host 10.0.3.1
permit ip host 10.0.3.1 any
… allocates 128 kbps to the traffic to/from IP host 10.0.3.1 and distributes the remaining 128 kbps fairly between conversations in the default class.
I am overly familiar with weighted fair queuing (I was developing QoS training for Cisco when WFQ just left the drawing board) and was thus always wondering how they manage to implement that behavior with WFQ structures. A comment made by Petr Lapukhov re-triggered my curiosity and prompted me to do some actual lab tests.
The answer is simple: CB-WFQ does not work as advertised.
To prove this claim, I’ve started two parallel TTCP sessions: one to IP address 10.0.3.1, the other to IP address 10.0.3.2. This is what show policy-map interface command displayed after a minute:
a1#show policy-map int ser 0/1/0
Service-policy output: WAN
Class-map: High (match-all)
5996 packets, 3424386 bytes
30 second offered rate 200000 bps, drop rate 0 bps
Match: access-group name High
Output Queue: Conversation 73
Bandwidth 50 (%)
Bandwidth 128 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 5981/3421234
(depth/total drops/no-buffer drops) 4/0/0
Class-map: class-default (match-any)
516 packets, 270445 bytes
30 second offered rate 6000 bps, drop rate 0 bps
The printout clearly demonstrates that the TCP session in the High class got way more than its allocated share while the TCP session in the class-default got 30 times less bandwidth.
The conversations in the class-default are treated as low-priority conversations and get significantly less bandwidth than other traffic classes.