Bandwidth allocation with class-based weighted fair queuing (CB-WFQ)

Sebastian sent me an interesting question:

I have read that we can only use 75% of the bandwidth for the custom queues as 25% is reserved for the keepalives and routing protocol updates. If I want to set 50% of bandwidth for a particular queue should it 50% of the total bandwidth or 50% of the available 75% of the bandwidth?

Before going into the details, it’s important to remember that the WFQ (CB-WFQ is only a mechanism to sort packets into output queues) uses relative ratios (percentages) between queues to determine which packet to send (the absolute bandwidths are used just to compute the ratios).

To prevent the classified traffic from starving the routing protocols and other important packets (ARP, CDP, ILMI, Frame Relay keepalives …), the router does not allow the class queues to consume more than 75% of the total interface bandwidth. The remaining 25% are used for the default class (all non-classified traffic) as well as all non-IP packets. You can change the limit with the max-reserved-bandwidth interface configuration command; just make sure you have plenty of bandwidth left for the control traffic.

When you configure the class-based queuing with the bandwidth [remaining] percent percent command, the number you specify is the percentage of the total interface bandwidth and is used to determine the ratios in the WFQ system. Obviously, the sum of all percentages and the max-reserved-bandwidth should not be more than 100.

When using the bandwidth kbps command, the traffic in the class you’re configuring will get at least the specified amount of bandwidth. The bandwidth percentage is computed as the specified bandwidth divided by the interface bandwidth.

The interface bandwidth can be set based on the actual hardware (it’s not hard to guess what the bandwidth of a 100BASE-TX interface is), computed for multilink bundles or configured with the bandwidth interface configuration command.

This article is part of You've asked for it series.

5 comments:

  1. Hi ivan

    Thanks a lot for answering my query. after reading ur post i checked by simulating a lab.

    So can i consider the following as a best practise for computing bandwidth for the classes.

    first take 75% of the available bandwidth let;s say the bandwidth of the interface is 512 Kbps. 75% of it would be 384 Kbps.

    now take this bandwidth as the available bandwidth for user traffic .

    so if i want to set 50% of the bandwidth for a particular class. i would take 50% of 384 Kbps.
    and similarly allocate traffic to other classes taking 384 as the available bandiwdth. making sure the allocated bandwidth to classes doesn;t overrun the remaining 25% for control protocols.

    can I consider this as a recommended method for computing bandiwdth for traffic classes using CBWFQ.

    ur guidance on the same would be great.

    thanks for the post

    Regards

    Sebastan

    ReplyDelete
  2. Hi,
    I'm wondering what bandwidth the 25% rule was made for. 25% of 256kbps is much less than 4mbps and I would expect there to be the same amount of control traffic over both links if each were configured similarly. I would assume that there is a particular bandwidth where the 25% rule of thumb no longer applies and would not negatively impact routing or other control traffic. Do you know what that number is?

    Thanks in advance,
    Mark

    ReplyDelete
  3. It was a rule-of-thumb that was never changed. The assumption was (probably) also that not all traffic would be classified and it makes sense to leave some bandwidth available for low-priority (unclassified) traffic.

    ReplyDelete
  4. This can be dangerous on older IOS than 12.4(22)T if a heavy traffic class is configured with “bandwidth” and class-default is left as it is.

    E.g. Consider 4 flows; each of 20Mbps; Total Link is 10Mbps; one flow is reserved for 6Mbps. Rest all flows default. (default flows will use fair-queuing with lower weight)

    Working: heavy traffic will be guaranteed 6Mbps + it’ll eat more based on its higher weight. Practically this went to 9.2 Mbps, other got only in Kbps.
    So make sure class-default is also allocated some remaining bandwidth e.g. 3990kbps in this example.

    Or the same LLQ type behavior can be achieved using shaping on the 6Mbps reserved class so that it doesn’t cross a certain limit. E.g.
    policy-map PM_QOS
    class CM_UDP1000
    bandwidth 6000
    shape average 6000000
    !
    interface FastEthernet0/1
    bandwidth 10000
    ip address 192.168.58.1 255.255.255.0
    load-interval 30
    duplex auto
    speed 10
    no keepalive
    max-reserved-bandwidth 100
    service-policy output PM_QOS

    Let's take an example -

    E.g1:.

    UDP1000 with BW=6000kbps sending at the rate of 8MBps
    UDP1001 sending at 20Mbps


    In 12.4(22)T, CBWFQ behaves as if it has an inbuilt policer for the reserved BW.
    WAN#sh policy-map int fa0/1
    FastEthernet0/1

    Service-policy input: PM_QOS_STATS

    Class-map: CM_UDP1000 (match-all)
    226396 packets, 281183832 bytes
    30 second offered rate 5945000 bps ----> CBWFQ gets 6Mbps even when sending at 8Mbps
    Match: access-group 100

    Class-map: CM_UDP1001 (match-all)
    146264 packets, 181659888 bytes
    30 second offered rate 3864000 bps -> other flow gets remaining 4MBps
    Match: access-group 101

    In 12.4 Mainline (and all IOS prior to 12.4(22)T,
    WAN#sh policy-map int fa0/1
    FastEthernet0/1

    Service-policy input: PM_QOS_STATS

    Class-map: CM_UDP1000 (match-all)
    1185545 packets, 1472446890 bytes
    30 second offered rate 8161000 bps ----> CBWFQ gets 8.0Mbps when sending at 8Mbps based of the higher weight

    Match: access-group 100

    Class-map: CM_UDP1001 (match-all)
    373738 packets, 464182596 bytes
    30 second offered rate 1649000 bps-> other flow get only around 2 Mbps
    Match: access-group 101

    cheers
    Swap
    #19804

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.