How to configure QoS in EOS with Policy

Anonymous — Fri, 15 Dec 2017 19:33:00 GMT

Thought I would share this with the community as hopefully it will be a good source of information for anyone doing the same thing. I need to translate this into EXOS, which I will try and do at a later date and reference back here later.

The details in this article are accurate to the best of my knowledge, so feel free to correct me where wrong.

This article covers implementing a policy based quality of service solution to provide a unified configuration approach that covers all the scenarios of a Mitel IP telephony solution, inclusive of the IP phones, softphones and various telephony appliances like the controller, boarder gateways etc.

This article will also detail the use of LLDP-MED to help with the effectiveness of deploying the Mitel IP phones.

1 Requirements

Although this article goes into the detail of how the
various elements are configured via the command line, QoS is predominantly configured through the
use of Extreme Networks Management Software.

Each model of the Extreme Networks S, K, N, C, B series
switches etc each have their own hardware capabilities and configuration that need to be considered when implementing an end to end QoS solution, a majority of which is provided below.

1.1 Interesting Traffic

The ‘interesting’ traffic defined below will use Extreme Networks policy to identify the traffic and classify it appropriately.

For this reason classification will not be dependent on any quality of service markings within the voice traffic / packet itself, like Layer 2 Priority or Layer 3 DSCP. This is particularly proficient because:

You can use the same policy / configuration across the whole network.
Will classify any interesting traffic regardless of source i.e. Physical IP Phone, soft phone, PBX etc.
Will only classify interesting traffic, and not anything else that might enter the network with a QoS marking in the packet.

The traffic that will be classified is as follows:

Mitel Voice Traffic (RTP / UDP destination port 50000-50127) --> CoS 6
Mitel Control Traffic (TCP destination port 9000-9002) --> CoS 3
Everything Else --> CoS 0

Traffic is classified on Ingress and queued on Egress from each and every port on the switch, or any that wishes to participate in Voice QoS. The form of classification and queuing will be as follows:

CoS 7 --> Strict Priority (1st priority)
CoS 6 --> Strict Priority (2nd priority)
CoS 5 --> Weighted Round Robin (WRR) / Weighted Fair Queuing (WFQ)
CoS 4 --> Weighted Round Robin (WRR) / Weighted Fair Queuing (WFQ)
CoS 3 --> Weighted Round Robin (WRR) / Weighted Fair Queuing (WFQ)
CoS 2 --> Weighted Round Robin (WRR) / Weighted Fair Queuing (WFQ)
CoS 1 --> Weighted Round Robin (WRR) / Weighted Fair Queuing (WFQ)
CoS 0 --> Weighted Round Robin (WRR) / Weighted Fair Queuing (WFQ)

Traffic will be classified on ingress at every entry point of the network. The following diagram depicts each of these ingress points for two typical model switches at the edge and core of the network; including the queuing mechanisms, class of service, transmit queues and type of traffic that are prevalent at each point - these will make more sense later .

2 Recommendations Summary

Extreme Networks Management provides a simple means by which QoS Policies may be centrally managed and deployed to all devices. In addition, any changes to the QoS requirements can be easily accommodated and deployed. Finally, by using Extreme Networks Management all switch device configurations will be unified (i.e. have the same QoS / Policy configuration), ensuring consistency and helping compliance.

2.1 Summary Configuration

Although the configuration is typically done via Extreme Networks Management this is an example of what the configuration may look like:

For S, K, N and C / B series an example of the configuration would look something like the follows (more detail is given on these commands further on):

set policy profile 1 name "Mitel" cos-status enable cos 0
set policy rule 1 ipdestsocket 255.255.255.255:50000 mask 45 cos 6
set policy rule 1 ipdestsocket 255.255.255.255:9000 mask 48 cos 3
set policy rule 1 ipdestsocket 255.255.255.255:9001 mask 48 cos 3
set policy rule 1 ipdestsocket 255.255.255.255:9002 mask 48 cos 3 set policy port ge.x.x 1 (Set ports to enable policy)S & K series policy based QoS configuration:

set cos settings 1 priority 1 tos-value 32 txq-reference 0
set cos settings 2 priority 2 tos-value 64 txq-reference 1
set cos settings 3 priority 3 tos-value 96 txq-reference 3
set cos settings 4 priority 4 tos-value 128 txq-reference 4
set cos settings 5 priority 5 tos-value 160 txq-reference 5
set cos settings 6 priority 6 tos-value 184 txq-reference 10
set cos settings 7 priority 7 tos-value 192 txq-reference 12 S & K series WFQ configuration:

set cos port-config txq 0.0 name WFQ_11Q arb-slice 10,15,2,20,24,29,0,0,0,0,0 C Series CoS configuration

set cos settings 1 priority 1 tos-value 32
set cos settings 2 priority 2 tos-value 64
set cos settings 3 priority 3 tos-value 96
set cos settings 4 priority 4 tos-value 128
set cos settings 5 priority 5 tos-value 160
set cos settings 6 priority 6 tos-value 184
set cos settings 7 priority 7 tos-value 192 S, K, N and C / B series command to enable the use of the CoS

set cos state enable 3 Extreme Quality of Service Overview

This section gives a brief overview of the components that make up the overall quality of service implementation, but is by no means an exhaustive overview and does not include, for example; rate limiting / shaping, flood control, flex-edge and drop precedence etc.

3.1 QoS Marking

Layer 2, 802.1p, priority, values 0-7 is sometimes referred to as Class of Service (CoS), but not to be confused with Class of Service in the Extreme Networks sense. CoS within Extreme Networks refers to a set of references that point to transmit queues, rate limiters, drop precedence, priority and ToS values, flood control etc.

Layer 3 uses the ToS (Type of Service) 8 bit field for QoS / Differentiated Services Code Point (DSCP, 6 bit) / IP Precedence (3 bit).

Below is a useful chart for comparison and translation:

3.2 Queuing

The following sections go into detail about all the different queuing methods available and how they work.

3.2.1 Transmit Preferential Queue Treatment

The following queuing types are as follows:

Strict priority works by a higher queue must be empty before a lower queue can be serviced.
Low latency is a queue specifically designed for voice around packet loss, delay and jitter and works in a strict priority manor.
Weighted takes the amount of time slices and divides it by 100%. So if a 100% is divide by 64 time slices and a queue is defined with 25%, it will have 16 slices.
Hybrid is a mixture of strict priority and weighted queuing,
ETS is based on the 802.1az standard and refers ETS queue contents being forwarded to a fair queue scheduler on a strict priority basis. The fair queue scheduler distributes the remaining bandwidth, after all non-ETS queues are empty, based upon the bandwidth allocation configured for the ETS queues

The following hardware supports the following queuing types:

Strict priority / All Extreme Networks EOS platforms that support QoS.
Low latency / S-Series and K-Series only.
Weighted / All Extreme Networks EOS platforms that support QoS.
Hybrid / All Extreme Networks EOS platforms that support QoS.
Enhanced transmission selection / S-Series and K-Series only.

There are two types a weighted queing called WRR (Weighted Round Robin) and WFQ (Weighted Fair Queing), that certain models support that the detail is given below.

3.2.1.1 Weighted Round Robin

Weighted Round Robin is a scheduling method that addresses the shortcomings of priority queueing, in that packets are removed from a queue each time that queue receives a scheduling turn. The scheduling is done on a per packet basis decided by the weight of the queue, which generally is a percentage of the interface bandwidth. This type of queuing is typically seen on the B & C series.

3.2.1.2 Weighted Fair Queuing

Weighted fair queuing is a bit by bit queuing and scheduling mechanism which gives weight to each of the queues proportional to the interface rate. Although being aware of the variable sized packets, no session with large packets gets anymore scheduling time then a session with small packets because WFQ focuses on bits and not packets. The queuing is scheduled based on a computation of bits on each packet at the head of the queue, which means this method is more resource intensive and therefore available on the S Series.

3.2.2 Default Queues Per Switch

The following switches have the following queues by default. These TxQ’s are defined by port group: port type (0:0)

S & K = TxQ 0.0 = 11 Queues = 100 time slices
S & K = TxQ 0.1 = 15 Queues = 100 time slices
N = TxQ 0.0 = 16 Queues = 64 time slices
N = TxQ 0.1 = 4 Queues = 32 time slices
C / B = TxQ 0.0 = 8 Queues

3.2.3 Default Port Groups Per Switch

The S-Series S-155 module supports port type 1 (15 Queues). All other S-Series modules support port type 0 (11 Queues).
All K-Series modules support port type 0.
The Enterasys N-Series DFE 7GR4270-12, 7G4270-12, 7G4270-09, and 7G4270-10 modules support port type 0. All other N-Series modules support port type 1.
All fixed switches support port type 0.

These port groups can be seen by issuing the ‘show cos port-config’ command on the S, K and N and ‘show port txq’ on the C & B series.

3.2.4 Queue Configuration Per Switch Type

S and K series detail 11 & 15 Queues, but is dependent on the hardware available. All ports are assigned to 11 queues by default, in LLQ arbiter mode.

C & B Series uses a combination of SP and Weighted Round Robin. Queues 6 and 7 are reserved for management traffic and cannot be used or changed. This what they look like by defualt:

3.3 Default Port Priority to Queue Configuration

Extreme Networks EOS switches have an 802.1p priority to Queue configuration for default forwarding treatment, should policy base CoS NOT be used. The top row is equal to the physical queue and the row below is the 802.1p priority:

C / B Series:

S & K Series:

As you will note each switch series is slightly different and uses the amount of queues defined by the default port group and port type. The C / B series although having 8 queues, queues 6 & 7 are reserved for management traffic and cannot be changed. The other thing to note is that anything that has a priority of 0 would (by default) in fact be put into physical queue 1, which would translate to be treated more preferentially than any traffic marked with a priority 1 or 2, as these would go into the physical queue of 0! Similar thing would happen on an S & K Series.

As strange as that might initially seem, I believe it has been done for very good reason. An example might be that you have a threat on the network like a worm that is consuming all the bandwidth, then through Extreme Analytics \ Extreme Control it is possible within an instance to great a policy rule that can be pushed to the whole of the network that re-classifies that traffic.

As this traffic would normally have a priority of 0 and go into transmit queue 1, you instead move it to transmit queue 0 thereby getting less preferentially treated than anything else - restoring full service again.

4 Defining a Class of Service

Defining CoS and priority levels is completely open for change and there is nothing to say it must be configured in a particular way i.e. CoS 6, with a Priority of 6 must be used for Voice – it simply depends on the choice of network requirements. With Extreme Networks, specifically via Extreme Networks Management, the default CoS configuration is defined:

Scavenger – priority 0
Best Effort – priority 1
Bulk Data – priority 2
Critical Data – priority 3
Network Control – priority 4
Network Management – priority 5
RTP/Video/Voice – priority 6
High Priority – priority 7

This also follows the requirement to use a priority of 6 for all Mitel RTP traffic.

In order to follow best practice and to aid any future scaling the proceeding tables show what the TxQ and CoS assignment it recommended by default, obviously this is open to change by any additional requirement. Multiple port groups can be created with different assignments, so for example you could have one port group for edge ports and another for uplink ports. C / B Series switches are fixed in the configuration in terms of the TxQs and will simply follow the same CoS to priority values as the rest.

4.1 Extreme Networks CoS

This sections details how the Extreme Networks CoS is formulated. First is the CoS assignment, which shows the CoS reference number and associated Priority value, Type of Service Value, Transmit Queue reference and In Bound Rate Limit reference.

So to use an example if you take CoS 6 from the table above, which uses a Priority of 6 and a TxQ reference of 12, which uses the physical transmit queue TxQ 10 for port group 0.0 from the table below:

Below is an example of how you could configure the CoS with values for priority, TxQ references, ToS and IRL references – although typically this would be configured within Extreme Networks Management.

4.2 Transmit Queue reference

4.2.1 S,K and N Series TxQs

The command below shows TXQ's (all 11) as show the previous table, These have been configured with the LLQ arbiter using SP, as defined by the last configurable queue 8, being set to 100% - queues 0, 9 & 10 can not be changed. The arbitrator is configurable to WFQ (S & K Series) where you can evenly distribute what amount of traffic goes into what queue, as described in the previous sections. (C & B series use WRR).

To make changes to default settings, an example is provided below.

A couple of rows from the CoS reference looks like the following :

This shows that CoS 5 and 6 is using a comparative priority of 5 and 6. Priority 5 is using a TxQ reference of 10, and priority 6 is using a TxQ reference of 12.

TxQ mappings for TxQ reference 10 and 12 are such that both go to the same physical TxQ 10:

The physical TxQ 10 is already an LLQ, but we want to change the TxQ reference 10 (CoS 5) to point to physical TXQ 9, but keep TXQ reference 12 (CoS 6) the same using physical TXQ 10.

So the following command would be used:

set cos reference txq 0.0 10 queue 9 4.2.2 C & B Series TxQs

For C series there is no TxQ reference and will therefore follow the default priority-queue and TxQ mappings if no policy based QoS is configured.

The C series priority queue definitions left as default will have priorities 6 & 7 serviced by the same queue 5, as per default configuration shown below:

To change this you can set priority 6 to be serviced by queue 4, and configure it on a per port basis:

set port priority-queue ge.1.1 6 4 5 Configuring Policy The following shows the traffic type and port numbers that you want servicing by the particular CoS:

Mitel Voice Traffic (RTP / UDP destination port 50000-50127) --> CoS 6
Mitel Control Traffic (TCP destination port 9000-9002) --> CoS 3

To achieve this a policy is required to highlight the traffic on the required ports and apply the appropriate CoS. For Extreme Network switches creating polices, CoS, TxQ assignments etc is without doubt best configured via Extreme Networks Management, but for reference an example command line configuration is given:

For S, K, N and C Series:

The policy will then need to be assigned to the ports you require policy to work on, this is known as a static policy.

The policy profile has a default action to use CoS 1, which means anything that does not match a rule is assigned a CoS of 1.

On the S & K series CoS 1 uses a WFQ of 10% and a TxQ of 2, for all non-classified traffic i.e ‘Everything Else’ (priority 0). This means we have the opportunity to then classify any disruptive traffic below this via policy with a CoS of 0 that uses a WRD of 2 %.

With the use of Extreme Networks Control, polices can be assigned dynamically based on criteria such as AD account, where the device is, what operating system they use, MAC OUI etc. or as described earlier statically via the following command:

set policy port ge.1.1-22 1 6 Configuring CoS

As an example, the below table provides typical settings for corresponding CoS, Priority and Type Of Service

The following commands use policy to look at the DSCP value and assign it to the appropriate COS based on the table above. It is also possible through TCI Rewrite to rewrite the priority values according to the COS, but this is only supported on selected switches.

set policy rule 3 iptos 32 mask 8 cos 1 forward
set policy rule 3 iptos 64 mask 8 cos 2 forward
set policy rule 3 iptos 96 mask 8 cos 3 forward
set policy rule 3 iptos 104 mask 8 cos 3 forward
set policy rule 3 iptos 128 mask 8 cos 4 forward
set policy rule 3 iptos 136 mask 8 cos 4 forward
set policy rule 3 iptos 160 mask 8 cos 5 forward
set policy rule 3 iptos 184 mask 8 cos 5 forward
set policy rule 3 iptos 192 mask 8 cos 6 forward To enable CoS for S, K, N and C/B series the following command is used:

set cos state enable 6.1 S & K series

This is the configuration used to match the table above:

set cos settings 1 priority 1 tos-value 32 txq-reference 1
set cos settings 2 priority 2 tos-value 64 txq-reference 2
set cos settings 3 priority 3 tos-value 96 txq-reference 3
set cos settings 4 priority 4 tos-value 128 txq-reference 4
set cos settings 5 priority 5 tos-value 160 txq-reference 5
set cos settings 6 priority 6 tos-value 184 txq-reference 6
set cos settings 7 priority 7 tos-value 192 txq-reference 7 6.2 N series

There are some N switches that have 4 queues and therefor will use same config as S & K, but the queue reference will reflect the short number of physical queues:

set cos settings 1 priority 1 tos-value 32 txq-reference 0
set cos settings 2 priority 2 tos-value 64 txq-reference 1
set cos settings 3 priority 3 tos-value 96 txq-reference 1
set cos settings 4 priority 4 tos-value 128 txq-reference 2
set cos settings 5 priority 5 tos-value 160 txq-reference 2
set cos settings 6 priority 6 tos-value 184 txq-reference 3
set cos settings 7 priority 7 tos-value 192 txq-reference 3 6.3 C series

The same configuration for a C Series:

set cos settings 1 priority 1 tos-value 32
set cos settings 2 priority 2 tos-value 64
set cos settings 3 priority 3 tos-value 96
set cos settings 4 priority 4 tos-value 128
set cos settings 5 priority 5 tos-value 160
set cos settings 6 priority 6 tos-value 184
set cos settings 7 priority 7 tos-value 192 7 Configuring Weighted Fair Queuing

As previously detailed by default the S & K use a LLQ arbiter, the N uses SP, whilst the C series uses WRR and SP. To configure WFQ on an S & K series the command would be as follows for an 11Q switch:

set cos port-config txq 0.0 name WFQ_11Q arb-slice 0,0,0,10,10,15,15,20,30,0,0 With the S & K Series you cannot change a LLQ, so the only queues you can change for WFQ are Q2-Q9. So in essence you could configure hybrid queuing. By default the S, K and N are set to strict priority. The strict priority arbiter is set by having all the queues configured to 0% apart from the last one set to 100%. You can see this in the command below, where you can observe Q8 is set to 100% and queues 0,9 and 10 for 11Q are LLQ’s

If configuring via Extreme Networks Management, the change to WFQ may look something like the following:

8 Configuring LLDP In order to help deploy the Mitel phones without the use of additional 'special' options in the default 'Data' VLAN the configuration for LLDP will look something like the below (taken from the following post https://community.extremenetworks.com/extreme/topics/g_d_c_b_a_series_f_w_6_03_use_of_the_lldp_med_n...:

set lldp tx-in

RE: How to configure QoS in EOS with Policy

Drew_C — Tue, 19 Dec 2017 03:44:00 GMT

Martin, This is great! Thank you for sharing with the community!

topic RE: How to configure QoS in EOS with Policy in Network Architecture & Design

How to configure QoS in EOS with Policy

RE: How to configure QoS in EOS with Policy

RE: How to configure QoS in EOS with Policy

RE: How to configure QoS in EOS with Policy

RE: How to configure QoS in EOS with Policy