All_about_network

As one of the previous posts was about configuration of AR46 and 28 series routers this one will be kind of a follow-up article about the QoS on these devices or rather some real example.

But as usually first things first – the dry theory of QoS.  As you probably know QoS is abbreviation for quality of service which is more of a concept and bundle of various technologies which arise up as  a workaround for disadvantages of packet networks (especially Ethernet). I will not bother you which much details as you can find much more detailed descriptions on various places like here. I will stick to a simple example I was creating while ago on a request made to me through e-mail. This post is not supposed to be a complete guide through Huawei’s QoS. For the complete QoS overview please wait for the full article that will be posted shortly. This is the scenario I was putting together.

Step I. – Finding the traffic of interest

I personally prefer to do this on ACL basis (as opposed to the per interface  and some others) as this method gives you complete freedom of what and how you select your traffic. As usually it is good practise to use the basic ACLs instead of the advanced as they are less CPU hungry. The important consideration is that this method in general will cause some additional load on your router’s CPU. Let’s say that we would like to define three classes Voice, Data and Default.

#
acl number 2001 name voice
rule 5 permit ip source 192.168.130.10 0 destination any
acl number 2002 name data
rule 5 permit ip source 192.168.130.0 255.255.255.0 destination any
acl number 2003 name default
rule 5 permit ip source any destination any
#

As usually the better and simpler you ACLs will be  the better performance will your router have. I used source IP addresses as the way of detection of the traffic flows but you can define the rules on whatever ACLs will allow you. There are no limits for QoS.

Step II. – Setting the scheduling mechanism

The decision what scheduling and queuing mechanism you want to use is probably the most important one as  there is at least five types of them. Those ones I’d like to mention are only two PQ (strict priority queuing) or CBWFQ (class based weighted fair queuing). PQ is more simple and better for certain cases where some bandwidth is permanently assigned to some kind of traffic but it has also one huge disadvantage. It is the most bandwidth wasting method you could think of. The other (and default till VRP 3.40 including) is CBWFQ (class based weighted fair queuing) which is somehow more complex but has some serious advantages. Like better bandwidth management etc. (will be seen later on). So for our example we will use CBWFQ.

Step III. -Setting the classifier

As we are using CBWFQ we have to define the classes of the traffic

#
traffic classifier VOICE operator or
if-match acl 2001
traffic classifier DATA operator or
if-match acl 2002
traffic classifier DEFAULT operator or
if-match acl 2003
#

So now we had bound the ACLs to the classifier so it could be used later on in the QoS policy.

Step IV. – Setting the traffic behaviour (aka what will happen to the traffic in question)

Traffic behavior can be set either in percentage or in absolute numbers, and to be clear the second option is much better as percentage is just an estimation based on number of packets in some previous period of time. I also used dscp values as the queuing mechanism will take the values in consideration while processing the frames so this is in fast prioritization (the packets will be re-marked no matter what the previous value in TOS field would have been).

#
traffic behavior VOICE
queue af bandwidth pct 80
traffic behavior DATA
queue dscp af2 bandwidth pct 15
traffic behavior DEFAULT
queue dscp af1 bandwidth pct 5
#

Step V. – Creating the policy

Here you bind together all the above defined into one policy you will apply later on the interfaces.

#
qos policy qos
classifier VOICE behavior VOICE
classifier DATA behavior DATA
classifier DEFAULT behavior DEFAULT
#

So for every classifier just attach desired behaviour and that is it.

Step VI. – Applying the policy

#
interface Ethernet1/0
ip address 192.168.130.1 255.255.255.224
qos apply policy qos inbound
#

Now your policy is on inbound interface and should be working fine. There is one step missing though and that’s shaping on outbound. This could be done by the following procedure.

Step VII. – Outbound Traffic Shaping (optional)

#

interface Ethernet1/1
ip address 192.168.130.10 255.255.255.
qos gts acl 2001 cir 256000 cbs 128000 ebs 0 queue-length 50
qos gts acl 2002 cir 50000 cbs 2500 ebs 0 queue-length 100
qos gts acl 2003 cir 1000 cbs 6250 ebs 0 queue-length 50
#

As you can notice I used gts (general traffic shaper) for the shaping again matching the same ACL (I could use different but re-using should be more CPU sensitive) with some values which needs to be explained :

• cir = committed information rate = desired reserved bandwidth,
• cbs= committed burst size (buffer) = 1/2 cir (recommended, differs by HW and VRP version)
• ebs= exceeding burs size (overflow buffer) = 0 (unless you have a real need for it)
• queue-length = max buffer in bytes

Shorter queue is for voice as we do not really want to store delayed voice packets and the longer queue is for less delay sensitive services. These numbers were  created for certain case and if you want to use them you should recalculate them for proper values before using! As you can count this scenario was using a 256K as a guaranteed for voice and 50K for the data and 1K some rubbish traffic.

That’s it. In the next articles I will get to some more complex scenarios, QoS on switches and some tweaks.