QoS on a Huawei AR1220F.

The scenario.


Recently, one of our customers purchased a 50Mbit Eurofiber connection and for network connectivity, they leased an AR1220F.
They want to run several services across this connection in which certain traffic is prioritized.
In order to achieve this, QoS needs to be configured on the AR1220F.
The setup will be as follows;

scenario


- the AR1220F will mark inbound traffic and use PQ/CBWFQ outbound
- the traffic will enter the switch of Eurofiber, the company providing layer 1 connectivity.
- the packets will be transported to a wholesale interconnect
- the wholesale interconnect is connected to a MX80, which is used as a BRAS router
- the MX80 will do the downstream shaping and it will use the same classes (MX-QoS is out-of-scope)

The customer has identified three classes:
- Voice: should be low latency. No more than 25% of the bandwidth is needed.
- Data 1: should be able to take 25% of the entire bandwidth when there is congestion
- Data 2: should be able to take 10% of the bandwidth when there is congestion

When there is no congestion, the classes ‘Data 1’ and ‘Data 2’ should be able to use the full bandwidth.
Classless traffic does not need to have any guarantees, but should also be able to use the full bandwidth as long as there is no congestion.
I had to come up with the configuration and the solution for this customer. Huawei's site offers a lot of configuration documents and explanation and so I started reading the 'Configuration Guide - QoS'.
The configuration guide is a lengthy and systematical step by step review of the features that can be activated. This is great if you want to look something up. Problematic if you want to get started.
For this reason, I wanted to create a guide into basic QoS on an AR1220F router.

I will first describe what needs to be done on the WAN-interface. Second, I will describe how to mark the packets on the LAN-side. And finally, I will present the complete configuration of for the scenario.


The WAN side.

The AR1220F has two GigabitEthernet WAN interfaces that support the full breadth of QoS. The other build-in 100-Mbit Ethernet ports support far less features.

scenario


On the WAN interfaces ‘GigabitEthernet0/0/0’ and ‘GigabitEthernet0/0/1’ hierarchical QoS and PQ/CBWFQ is supported.
In this scenario, we will use these features on the GigabitEthernet 0/0/0 interface.
For our scenario, we have the following objectives on the WAN-interface:
- all outbound traffic needs to be shaped to the appropriate bandwidth
- all traffic that is shaped outbound needs to flow through a policy that will treat the traffic based on the customers desires

In order to achieve this, there are 5 configuration elements we need to take into account;
1. Configure the traffic classifiers
2. Configure the traffic behaviors
3. Configure the traffic policy
4. Nest the traffic policy inside a behavior with a shaping rate and configure the main policy
5. Apply the main policy to the appropriate outbound interface

I will use the voice class during these steps as an example.


1: Traffic classifiers.

Classifiers are configured to link a packets properties to a certain user defined class.
To have the Huawei router view packets with their DSCP field set to EF, configure the following:

scenario


In this VOICE classifier, the ‘operator or’ is used. You can choose between ‘or’ (which means any of the following) and ‘and’ (which means all of the following).
In this example, the ‘if-match’ statement will match on a DSCP value. It is possible to match the classifier to other properties as well.
For example, you can use an acl, the 802.1p value, a protocol, a destination mac and much more.


2: Traffic behaviors.

A traffic behavior is used to define an action, or a set of actions, that you wish to perform on packets that are matched by a traffic classifier.
Traffic behaviors in Huawei offer a lot of flexibility and granularity. With a traffic behavior you can, amongst others;
- permit or deny packets
- re-mark packets
- enable statistics
- shape traffic
- perform congestion avoidance

In the example below, the behavior is configured for 2 things:
- put packets classified into the VOICE-class in a low-latency queue capped at 25%
- enable the statistics on the queue

To accomplish this, create the following behavior:

scenario


3: Traffic policy.

Inside a traffic policy, the classifiers are linked with the behavior.
In the example below, we link the VOICE class to the VOICE behavior and we link the DATA class to the DATA behavior.

scenario


4: Nest the traffic policy inside a behavior with a shaping rate and configure the main policy.

The interface of the AR1220F is 1000Mbps. If we were to apply the policy from step 3 to the interface, we would have a low-latency voice queue of 250Mbit.
This would be problematic since we only have 50Mbit we can use.
Therefore, we need to nest our policy inside another traffic behavior. This traffic behavior needs to set the correct bandwidth (50Mbit).
This will look as follows:

scenario


This behavior (NESTED-BEHAVIOR) can then be used inside yet another policy, called MAIN-POLICY:

scenario

The end result is that all behaviors are subjected to the shaping-rate set by the NESTED-BEHAVIOR. This can be very convenient.
Especially when you want to start using standard profiles.
The only variable you will end up with is the shaping rate in the NESTED-BEHAVIOR class.

5: Apply the main policy to the appropriate outbound interface.

The main policy needs to be applied to the WAN-interface in the outbound (away from our device) direction as follows:

scenario

The command in the example will make the AR1220F router install the policy to the interface.
All packets send through the subinterface will be subjected to the applied policy.
Remember that a WAN interface will support other QoS features then a LAN interface.


A recap of the steps to configure the WAN interface:


scenario

In the previous example, the focus was on the individual steps. Now, back to what the customer initially wanted:
- Voice: should be low latency. No more than 25% of the bandwidth is needed.
- Data 1: should be able to take 25% of the entire bandwidth when there is congestion
- Data 2: should be able to take 10% of the bandwidth when there is congestion

To be able to fulfill these requirements, you can use the following example configuration:

scenario

Note;
I spend quite some time trying to get it working on a broken software level.
I tried and successfully tested the policy above on an AR1220F running ‘V200R005C10SPC500’.


The LAN side.
On the LAN-side (towards the customer), we will only have to mark packets with the correct DSCP value.
This is done with the following ingredients:
- traffic classifiers with a reference to an access-list
- traffic behaviors that remark the DSCP field
- a traffic policy that combines the different classifiers and behaviors

In the example below, we are going to do the following:
- put all traffic sourced from 1.1.1.1/32 into the MARK-VOICE classifier
- put all traffic with TCP destination port 11111 into the MARK-DATA_1 classifier
- put all traffic with TCP destination port 22222 into the MARK-DATA_2 classifier
- remark the packets to the desired DSCP values

scenario

To start marking the packets, the traffic policy ‘MARK-PACKETS’ needs to be applied on the LAN interface in the inbound direction.

scenario

29-7-2014