AlliedWare PlusTM OS Overview of | Quality of Service Features on x900-12, x900-24, and SwitchBlade x908 Switches Introduction This How To Note describes the main features of QoS on switches running the AlliedWare Plus OS. The main features include: C613-16120-00 REV A z Prioritisation and marking Right at the point of ingress into the QoS process, packets classified to particular class maps can have values written to one or more of their associated “markers”.
z Ability to see the current state of egress queues There are commands that enable you to see statistics relating to every egress queue on every port. Each of these features is discussed in much more detail later on in this document. Contents Introduction .............................................................................................................................................. 1 Which products and software version does this Note apply to? ...............................................
Which products and software version does this Note apply to? z Products: SwitchBlade x908, x900-12XT/S, and x900-24 series switches z Software versions: AlliedWare Plus version 5.2.1-0.1 and above The process flow and methodology of the QoS system Before discussing the details of the various processes that comprise the QoS system, it is desirable to first get a picture of what the processes are, and the order in which they are applied to the packets passing through the system.
Packet markers There are four items that are used to mark packets as they pass through the QoS system. z z Two markers that are carried within fields of the packet itself: z 802.1p: The 802.1p or User Priority field in the VLAN tag of an Ethernet frame. This is a 3-bit number, so it can have a value in the range 0-7. z DSCP: The Differentiated Services Code Point within the TOS field of an IP packet header. This is a 6-bit number, so it can have a value in the range 0-63.
Outline of the QoS processing flow Let's look at each QoS process in the order that they are applied to a packet. The following figure gives a quick view of the QoS features we are about to discuss. Packet Ingress port Ingress Tagged: priority mapped to queue Untagged: mapped to default queue Classification using ACLs Premarking Policing Remarking Limiting (dropping non-conformant) Egress Queue shaping Queue emptying and egress QoS4.eps Initial mapping to an egress queue, based on 802.
Classification Classification is simply a method of dividing the incoming traffic into traffic flows so that packets of one type can be treated differently to packets of another type. To do this, you create class maps and if desired ACLs. Incoming packets are inspected and may be classified on a very broad range of criteria. The classification process does not update any of the four marker values on the packet, but does dictate the path that the packet will subsequently take through the QoS system.
Policing Policing involves measuring the bandwidth used by a policer and comparing the measurement to the bandwidth limits that have been set for the policer. The policing process allocates a temporary bandwidth class value to packets. It is important to note that the policing process does not overwrite the bandwidth class value that the packet is already carrying around with it. Instead, an extra, temporary, bandwidth class marker is attached to the packets.
Queue shaping Each egress port has eight egress queues, which are numbered 0-7 with 7 being the highest priority queue. Unfortunately, the queues are of a limited length, so packets cannot be added to them indefinitely; if the switch is congested, the queues may fill up and no more packets can be added. In this case, packets will inevitably be dropped from the end of the queues, even if they are high-priority packets.
Scheduling In addition to managing the way in which packets can be dropped when the egress queues for a given port start to fill up, you can also configure the method that is used to allocate bandwidth to each of the queues to transmit packets onto the line. There are two ways that the queues can be scheduled for transmission: z Strict Priority Scheduling Higher-priority queues are emptied before any packets are transmitted from lowerpriority queues.
Details of the component processes, and how to configure them QoS elements: policy maps, class maps, policers, matches Some aspects of QoS are configured globally, such as default mapping of CoS to egress queue. However, most aspects are configured on a per-port basis, mostly as part of the port’s policy map. The policy map contains QoS settings for a port, and is made of class maps—one class map for each type of traffic you want to control on the port.
Diagram of the overall QoS process flow The following figure summarises the QoS process flow and the commands to configure each stage. The following sections describe the configuration in detail. From L2 switch Tagged packets: set egress queue based on 802.
Enabling QoS globally Before configuring QoS, you need to enable it by entering the following command in global configuration mode: awplus(config)#mls qos enable Initial mapping to queue based on tag When packets arrive at a port, they are assigned to an egress queue. This is done by the switch associating an egress queue marker with the packet. For tagged packets, the switch decides the initial queue setting by looking at the packet’s CoS value (802.1p User Priority field).
awplus(config)#interface awplus(config-if)#mls qos cos <0-7> The value you change the CoS to is not used to look up the initial egress queue setting; the mls qos queue command still determines the queue for untagged packets. Classification The process of assigning packets to class maps requires a two stage configuration.
Setting new values explicitly To explicitly set new values for a particular class map, first create the class map (if necessary), by entering the following command: awplus(config)#class-map Then simply enter the following commands: awplus(config)#policy-map awplus(config-pmap)#class awplus(config-pmap-c)#set cos <0-7> awplus(config-pmap-c)#set queue <0-7> awplus(config-pmap-c)#set bandwidth-class {green|yellow|red} awplus(config-pmap-c)#set dscp <0-63> You can set one or more of the a
Note that there is just a single mark-dscp map for the whole switch—separate class maps do not have separate mark-dscp maps. The configuration required to use the mark-dscp map is a little more complex than the configuration for setting the values explicitly. 1. First, write entries into the mark-dscp map table. This is a matter of specifying the DSCP, CoS, queue, and/or bandwidth class to associate with the given pair of DSCP and bandwidth class values.
Example For the class map called “example”, if you want to take all traffic with a DSCP of 34, 36 or 38 and premark it to CoS 4, queue 4; CoS 5, queue 5; and CoS 6, queue 6 respectively, then enter the following commands: awplus(config)#mls qos map mark-dscp 34 to new-cos 4 new-queue 4 awplus(config)#mls qos map mark-dscp 36 to new-cos 5 new-queue 5 awplus(config)#mls qos map mark-dscp 38 to new-cos 6 new-queue 6 awplus(config)#policy-map example awplus(config-pmap)#class example awplus(config-pmap-c)#trus
Applying ordinary policers to class maps Ordinary policers are used when policing traffic in a single class map in a single policy map on a single port. You create them in policy map class configuration mode, which means they are attached to that policy map and class map at the time they are created. They do not have a name, because they are identified by the policy map and class map.
Single-rate policing Both ordinary and aggregate policers can be single-rate.
Twin-rate policing Both ordinary and aggregate policers can be twin-rate.
Counting policed packets To see the count of policed packets: 1. Turn on the QoS counters enhanced mode by entering global configuration mode and using the command: awplus(config)#platform enhancedmode qoscounters 2. Restart the switch 3. Return to privileged exec mode and use the command: awplus#show mls qos interface policer-counters Counting packets for ordinary policers For each class map, the output shows the total (aggregate) number of bytes, and the number of bytes of each colour.
Counting packets for aggregate policers If a packet is processed by an aggregate policer, it is counted in the output for every port that the aggregate policer applies to, not just for the port that received the packet. The following figure shows output for the example from "Applying aggregate policers to class maps" on page 17. For port1.0.
Remarking Remarking happens after the traffic has been policed. It sets the packet’s QoS markers depending on how well the flow conforms to its bandwidth limits. Remarking is performed by looking up the policed-dscp map and assigning values to the four markers (802.1p, DSCP, egress queue, and bandwidth class). The policed-dscp map is similar to the premarking mark-dscp map, except that the new values can also depend on the temporary bandwidth class from the policing stage.
Queue shaping—queue sets, RED, and tail-drop A queue set defines how the switch determines what traffic to drop when a port’s queues become congested. The queue set applies to one or more of the port’s queues, and specifies the queue size thresholds at which the port starts to drop traffic from that queue. You can use up to four different queue sets across the switch.There are two steps involved in configuring queue sets: 1. configure the queue set parameters 2.
Port speed Setting Value 10G Minimum threshold 1 MB Maximum threshold 1 MB Drop probability 50% Averaging factor 9 Note that by default ports only use the maximum threshold, because they are in tail-drop mode. The other settings are random-detect mode settings. Having defaults means that you can change to random-detect mode without having to configure a queue set (see "Applying RED curves to ports" on page 25).
These fundamental curves are collected into RED curve groups. A group is a collection of three curves, one for each of the three possible bandwidth classes, as shown in the following figure. 100% Drop 3 Drop 2 Drop 1 Drop Probability % BW Class 3 BW Class 2 BW Class 1 0% Start 3 Stop 3 Start 2 Stop 2 Start 1 Stop 1 MAX queue length Queue Length (bytes) QoS3.eps Additionally, one other parameter is defined on each RED curve group. This parameter is the averaging factor.
Specifying which queues to act on To specify which queues to configure, use the optional queues parameter: awplus(config)#mls qos queue-set <1-4> queues ... Specify the desired queues as a space-separated list. For example: awplus(config)#mls qos queue-set <1-4> queues 1 3 4 ... To configure all queues, leave out the queues parameter. If you do not configure RED curve settings on all the queues in a queue set, the unconfigured queues use the default settings—see page 23.
To specify the averaging factor, use the command: awplus(config)#mls qos queue-set <1-4> [queues ] averaging-factor <0-15> Tail-drop mode By default, ports use tail-drop mode and the default queue-set for that port type (see "Default settings" on page 23).
Strict priority scheduling Then, to set queues to use strict priority scheduling, use the command: priority-queue Specify the queues as a space-separated list.
The first of these numbers is the percentage limit for queue 0, the second number is the limit for queue 1, and so on. For example, to give queue 0 less of the buffer space and queues 3 and 4 more, you could use the command: wrr-queue queue-limit 6 12 12 17 17 12 12 12 You can use this command to configure queues that are members of the strict-priority group of queues, even though it begins with the keyword wrr-queue.
Policing Examples Policing is the process of counting the number of packets that the switch processes and determining their level of conformance with their bandwidth limits. The AlliedWare Plus OS enables you to police ports and different types of traffic separately (with “ordinary” policers) or in combination (with aggregate policers). This section describes a number of different policing scenarios.
Use the following commands to configure this policing scenario: mls qos enable class-map cm1 match access-group 3000 class-map cm2 match access-group 3001 policy-map pm1 class cm1 police twin-rate 1000 200 5000 1000 exceed-action drop class cm2 police single-rate 3000 200 4000 exceed-action drop interface port1.3.1-1.3.3 service-policy input pm1 The restricted traffic types are identified by ACLs (which could match, for example, by address or TCP/UDP port).
2: Policing one traffic type on combined ports In this scenario, one type of traffic is collectively policed on several ports. The policer counts all the packets that match the type’s class map on any of the ports. This scenario uses an aggregate policer. Use this type of scenario when you need to police all traffic of a certain type, even if it goes over more than one port.
3: Policing one traffic type on separate ports, and another traffic type on the same ports combined In this scenario, one type of traffic is collectively policed on several ports, while another type of traffic is individually policed on those ports. For the first traffic type, the policer counts all the packets that match that type’s class map on any of the ports. For the second traffic type, the policer separately counts packets that match that type’s class map on each port.
Use the following commands to configure this policing scenario: mls qos enable mls qos aggregate-police aggr1 twin-rate 1000 200 5000 1000 exceed-action drop class-map cm1 match ip-dscp 35 class-map cm2 match access-group 3000 policy-map pm1 class cm1 police aggregate aggr1 class cm2 police single-rate 3000 200 4000 exceed-action drop interface port1.3.1-1.3.
4: Policing combined traffic types on separate ports In this scenario, two types of traffic are collectively policed on a per-port basis. The policing is done on several different ports. On each port, the policer counts all packets that match either type’s class map. This scenario uses multiple aggregate policers. Use this type of scenario when you need to police some particular traffic types on a per-port basis, but not set an overall bandwidth limit on ports.
Use the following commands to configure this policing scenario: mls qos enable mls qos aggregate-police pol1 twin-rate 1000 4000 256000 1000000 exceed-action drop mls qos aggregate-police pol2 single-rate 3000 750000 1000000 exceed-action drop class-map cm1 match access-group 3008 class-map cm2 match access-group 3009 policy-map pm1 class cm1 police aggregate pol1 class cm2 police aggregate pol1 policy-map pm2 class cm1 police aggregate pol2 class cm2 police aggregate pol2 interface port1.0.
5: Policing combined traffic types on combined ports In this scenario, two types of traffic are collectively policed on multiple ports collectively. The policer counts all the packets that match either type’s class map on any of the ports. This scenario uses an aggregate policer.
Use the following commands to configure this policing scenario: mls qos enable mls qos aggregate-police pol1 twin-rate 1000 4000 256000 1000000 exceed-action drop class-map cm1 match vlan 10 class-map cm2 match vlan 20 policy-map pm1 class cm1 police aggregate pol1 class cm2 police aggregate pol1 interface port1.0.1-1.0.3 service-policy input pm1 Two different realtime services are identified by their VLANs.
Mapping the queues in the switching instances to queues in the fabric By default, the mapping of the egress queues of the switching instances to the queues in the fabric is: Switching instance egress queue Fabric queue 0 0 1 0 2 1 3 1 4 2 5 2 6 3 7 3 To alter this mapping, enter global configuration mode and use the command: awplus(config)#mls qos map input-queue q0 q1 q2 q3 q4 q5 q6 q7 The values qn specify which fabric queue q the nth egress queue of the switching instances maps to—q0 i
Scheduling the queues within the fabric The queues within the fabric can be grouped into one set of strict-priority queues and one set of weighted round-robin queues. Like the queues in the switching instances, the strict-priority queues in the fabric are all prioritised above the queues in the WRR set. By default, all the queues in the fabric are in the strict-priority group.
