// you’re reading...

QoS & VoIP

Implementing Weighted Fair Queing, Part II

Thanks for visiting! If you're new here, you may want to subscribe to my RSS feed. This blog posts regular tutorials, news, and study tips about networking, especially about Cisco CCIE related topics. Go ahead, subscribe to the rss feed! You can also receive updates from this blog via email. Thanks for visiting!

But Wait…theres still more! QoS Group based WFQ

In my previous article on WFQ, we really only talked about flow based WFQ. Flow based WFQ automatically sorts out traffic flows or conversations into separate queues. Smaller flower get precedence over larger flow. But what about frames that are classified with a QoS marking. If we have a larger frame with a high precedence or high valued ToS it should probably get to be served before a smaller frame with a very low precedence or ToS.

With the fair-queue qos-group command we can use a qos-group, which is an internal classification used by QoS features like Committed Access Rate (CAR).

interface serial0/0
 ip address 150.1.13.1 255.255.255.0
 rate-limit output 80000 10000 20000 conform-action set-qos-transmit 6 exceed-action drop
 fair-queue qos-group
 fair-queue qos-group 6 weight 40
 fair-queue qos-group 6 limit 37 

This is quite a long example with references we haven’t talked about yet like rate-limit command. But essentially what that rate-limit command says is this “Set up a Committed Access Rate on serial 0/0, where the speed is limited to 80 kbps with a 10kps burst normal and 20kps burst max set. If it conforms place all traffic in qos-group 6 and transmit otherwise drop”.

The fair-queue qos-group commands above then set up the traffic in qos-group 6 to have a higher weight hence more priority in the queues. In this case a weight of 30 was applied to all traffic in qos-group 6. The net affect of this is that traffic in qos-group 6 will get 40% of the bandwidth. We have also limited the size of the queues to 37.

That example is pretty simple. We aren’t really doing much more than putting all traffic into qos-group 6 and then giving it 40% of the rate-limited bandwidth (40% of 80kbps).

Lets look at a more complex example. We might want to just put traffic that has an ip precedence of 1 into qos-group 1, everything with an ip precedence of 2 into qos-group 2, and everything with an ip precedence of 3 also goes into qos-group 2.

interface serial0/0
 ip address 150.1.13.1 255.255.255.0
 rate-limit output access-group rate-limit 1 80000 10000 20000 conform-action set-qos-transmit 1 exceed-action drop
 rate-limit output access-group rate-limit 2 80000 10000 20000 conform-action set-qos-transmit 2 exceed-action drop
 rate-limit output access-group rate-limit 3 80000 10000 20000 conform-action set-qos-transmit 2 exceed-action drop
 fair-queue qos-group
 fair-queue qos-group 1 weight 5
 fair-queue qos-group 1 limit 20
 fair-queue qos-group 2 weight 10
 fair-queue qos-group 2 limit 30
!
access-list rate-limit 1 1
access-list rate-limit 2 2
access-list rate-limit 3 3

In the example above, we modify the rate-limit command to utilise a access-list rate-limit command. The rate-limit command says anything that matches this access-list rate-limit list 1, should be put into qos-group 1. access-list rate-limt 1 says anything with an ip precedence of 1 goes into it. We have done that for ip precedence 2 and 3 as well, they go into qos-group 2.

This changes the rate-limit command to say “Set up a Committed Access Rate on serial0/0. Everything with ip precedence 1, goes into QoS-Group 1 and gets limited to 8kbps, 1kpbs burst normal and burst max. Qos-Group 1 has 5% of the bandwidth, and each queue has a size limit of 20. Everything with ip precedence 2 and 3, goes into QoS-Group 2. Qos-Group 2 has 10% of the bandwidth and a queue size limit of 30.

ToS Based Weighted Fair Queue

We can also use Weighted Fair Queue taking into account the Type Of Service (ToS) field in the ip header. The higher the ToS field the more likely the packet train is to get served by the WFQ scheduling algorithm.

Lets have a look at some examples. To set up ToS based WFQ we use the fair-queue tos command:

int serial 0/0
 ip address 150.1.13.1 255.255.255.0
 fair-queue tos
 fair-queue tos 1 weight 10
 fair-queue tos 1 limit 20
 fair-queue tos 2 weight 20
 fair-queue tos 2 limit 30

In the example above, WFQ is implemented. Packet flows with an IP precedence of 1 will get 10% of the bandwidth and each queue will have a size limit of 20 members. Packet flows with an IP precedence of 2 will get 20% of the bandwidth and each queue will have a size limit of 30.

Summary:

  • QoS-group based WFQ places packet flows into QoS-groups. Bandwidth and queue limits can then be placed on those queues.
  • QoS-group based WFQ uses the fair-queue qos-group command
  • ToS based WFQ packets takes into account the ToS field in the IP header and schedules packet flows accordingly (higher ToS, higher chance of serviced by the WFQ scheduler).
  • ToS based WFQ uses the fair-queue tos command

HTH

Discussion

One comment for “Implementing Weighted Fair Queing, Part II”

  1. [...] Implementing Weighted Fair Queing, Part II [...]

    Posted by A hét érdekeségei - December 2, 2008 - xcke’s blog | December 2, 2008, 11:21 pm

Post a comment


Twitter Feed...

Follow me...

View Arden Packeer's profile on LinkedIn Arden Packeer ClaimID Add to Technorati Favorites TwitterCounter for @ardenpackeer