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 ! policy-map WAN class High bandwidth percent 50 ! interface Serial0/1/0 bandwidth 256 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 Serial0/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 Queueing 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 Match: any
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.