QoS Configuration Guide

introduction introduction qos (quality of service) is a technology that addresses issues such as network latency and congestion as a security mechanism in the network, qos can provide better service capabilities to improve service quality in normal circumstances, if the network is only used for specific time insensitive applications, such as web applications or email setups, qos may not be necessary however, for critical applications and multimedia applications, qos becomes particularly important during network overload or congestion, qos ensures that important business traffic is not affected by delays or losses while ensuring the efficient operation of the network explanation of principles explanation of principles priority mapping priority mapping networks typically face various types of traffic, each with different performance and service requirements therefore, to meet the needs of different applications and services and ensure the performance of critical applications while improving the overall network performance, users can use different qos priorities in different networks this involves mapping the priority carried by the packet to the local priority processed by the device, providing differentiated qos services based on the local priority the priority carried by the packet is called packet priority, for example vlan packets use 802 1p, and ip packets use dscp the local priority, also known as tc (traffic class), corresponds to the eight queues at the egress by default differentiated services for packets of different priorities are implemented based on the scheduling methods of different egress queues queue scheduling queue scheduling queue scheduling algorithms are one of the core mechanisms for implementing network qos control and an important part of network resource management it controls the use of link bandwidth by different types of packets to provide different levels of service to different data streams each interface of the device in the outbound direction is configured with 8 queues they are identified by queue ids from 0 to 7 packets are assigned to different egress queues based on the mapping from local priority to egress queues, and then processed according to the configured queue scheduling method strict scheduling strict priority scheduling the scheduling is strictly based on the priority of the egress queue, and only when the high priority queue is empty will the low priority queue be scheduled users can put high priority business packets into high priority queues and non critical business packets into low priority queues to ensure that high priority business can be scheduled first during congestion, ensuring business stability the priority scheduling order for queues is queue7> queue6> queue5> queue4> queue3> queue2> queue1> queue0 it is worth noting that this scheduling method may cause packets in low priority queues to be scheduled late, leading to queue starvation dwrr scheduling weighted round robin scheduling queues are scheduled in a round robin manner according to their weights the device supports a mixed scheduling mode of strict and dwrr for different queues under the same interface queues configured with strict scheduling mode are given priority when there are no packets in queues scheduled by the strict mode, queues are scheduled according to the weights in the dwrr mode by default, the scheduling mode for queues is dwrr, with a weight of 100 for each queue traffic shaping traffic shaping when the transmission rate of packets exceeds the reception rate, or when the downstream device interface speed is lower than that of the upstream device, it can lead to network congestion without restricting the size of user generated traffic, a continuous burst of business data from numerous users can further congest the network to ensure that limited network resources are effectively utilized to serve users, it's necessary to impose limits on user generated traffic typically, traffic specifications are evaluated using token buckets a token bucket can be envisioned as a container that holds a certain number of tokens the device deposits tokens into the bucket at a predetermined rate when the bucket is full, any excess tokens overflow, and no more tokens are added to the bucket the token bucket is merely a method for measuring traffic and does not filter or take any action on the traffic, such as discarding packets; these operations are performed by other functionalities qos priority configuration qos priority configuration configure tasks instructions index configure priority mapping relationship required configuring priority mapping relationship bind priority mapping relationship required binding priority mapping relationship configuring priority mapping relationship configuring priority mapping relationship by default, the mapping from the dscp/802 1p priority carried in the packet to the local priority is as follows all mapped to priority 0 the mapping from local priority to the egress queue is as follows tc 0—queue 0, tc 1—queue 1, tc 2—queue 2, tc 3—queue 3, tc 4—queue 4, tc 5—queue 5, tc 6—queue 6, tc 7—queue 7 operation command description enter the system configuration view configure terminal configure priority mapping relationship qos map {dot1p to tc|dscp to t c|tc to queue} \<profile name> \<in value> \<value> dot1p to tc mapping from 802 1p priority to local priority dscp to tc mapping from dscp priority to local priority tc to queue mapping from local priority to egress queue in value input priority (priority carried in the packet) value local priority binding priority mapping relationship binding priority mapping relationship operation command description enter the system configuration view configure terminal bind the specified mapping relationship between local priority and queue globally qos map all bind tc to queue \<profile name> enter the interface view interface ethernet \<id> bind the qos map to the specified interface qos map bind \<type> \<profile name> type qos map type, which includes dot1p to tc and dscp to tc qos queue scheduling configuration qos queue scheduling configuration the device supports a hybrid scheduling mode of strict and dwrr for different queues under the same interface queues configured with strict mode for priority scheduling are given priority, and when there are no packets in the strict mode queues, dwrr queues are scheduled according to their weights by default, the scheduling mode for queues is dwrr, with weights all set to 1 operation command description enter the interface configuration view interface ethernet\<interface num> configure the queue scheduling mode for the interface uc tx queue scheduler \<queue id > mode strict uc tx queue scheduler \<queue id > mode dwrr \[weight \<value>] traffic shaping configuration traffic shaping configuration configure tasks instructions index configure traffic shaping based on the interface optional configuring traffic shaping based on interface configure queue rate limiting required configuring queue rate limiting configure traffic shaping based on flows required configuring traffic shaping based on flows configuring traffic shaping based on interface configuring traffic shaping based on interface operation command description enter the interface configuration view interface ethernet\<interface num> traffic shaping configuration based on interface port shaper enable \<pir> \<pbs> the pir unit is bytes per second (byte/s) the pbs unit is bytes traffic shaping can be directly configured based on the interface, and it takes effect in the outbound direction of the interface configuring queue rate limiting configuring queue rate limiting operation command description enter the interface configuration view interface ethernet\<interface num> configure queue rate limiting uc tx queue scheduler \<queue id> {\<pir>|\<pbs>} pir\<value> maximum allowable rate, measured in bytes per second (byte/s) pbs\<value> peak burst size, measured in bytes configuring traffic shaping based on flows configuring traffic shaping based on flows configure tasks instructions index create a traffic behavior required configure a car (committed access rate) template required bind the traffic behavior to the interface required creating a traffic behavior creating a traffic behavior operation command description enter the system configuration view configure terminal create a traffic behavio traffic behavior \<traffic behavior name> configuring a car template configuring a car template single bucket single rate (sbsr) mode is a traffic control mechanism that uses a token bucket to regulate the forwarding rate of packets, aiming to control the average rate of traffic to ensure that the traffic on the network does not exceed a specific rate limit when evaluating traffic, the parameters of the token bucket include cir (committed information rate) the rate at which tokens are added to the token bucket, default unit is kbps cbs (committed burst size) the capacity of the token bucket, default unit is bytes, representing the size of the burst that can be accommodated by the token bucket in single bucket single rate mode, when the device receives a packet, it compares the number of tokens in the bucket if there are enough tokens, the packet is forwarded if there are not enough tokens, the packet is either dropped or buffered let tc represent the number of tokens in the bucket, and tc is initialized to cbs if the length of the packet does not exceed the number of tokens tc in the bucket, the packet is marked as green, and tc is decremented by the size of the packet (tc = tc b) if the length of the packet exceeds the number of tokens tc in the bucket, the packet is marked as red, and tc remains unchanged dual token bucket dual rate (tbdr) mode uses two token buckets to control packet transmission, each defining the "cbs (committed burst size)" and "pbs (peak burst size)" respectively cir committed information rate, expressed in default units of kbps, represents the rate at which tokens are added to the c bucket cbs committed burst size, expressed in default units of bytes, represents the maximum amount of data that can be transmitted from the c bucket pir peak information rate, expressed in default units of kbps, represents the rate at which tokens are added to the p bucket pir is greater than cir pbs peak burst size, expressed in default units of bytes, represents the maximum amount of data that can be transmitted from the p bucket token addition method tokens are added to the c and p buckets at rates of cir and pir respectively since these two token buckets are independent, if one bucket runs out of tokens, incoming packets to that bucket will be discarded while the other bucket remains unaffected and continues to receive tokens tc and tp represent the token counts in the c and p buckets respectively, with both initialized to cbs and pbs if the length of the packet exceeds the token count in the p bucket (tp), the packet is marked as red, and tc and tp remain unchanged if the length of the packet is greater than tc but less than tp, the packet is marked as yellow, and tp is decreased by the token count (b) while tc remains unchanged if the length of the packet does not exceed the token count in the c bucket (tc), the packet is marked as green, and both tp and tc are decreased by the token count (b) the dual token bucket dual rate (tbdr) mode allows for more granular control over different types of traffic, enabling marking and management based on rate requirements and congestion conditions it facilitates the implementation of more sophisticated qos policies to ensure that different traffic classes receive appropriate treatment, thereby maintaining network stability and service quality operation command description enter traffic behavior configuration view traffic behavior configure car template car {sr tcm|tr tcm} \[meter type {bytes|packets}] cir \<cir> \[cbs \<cbs>] \[pir \<pir>] \[pbs \<pbs>] \[yellow packet action {drop|forward|remark}]\[red packet action {drop|forward|remark}] \[remark dot1p \<value>\[remark dscp \<value>] \[remark tc \<value> cir committed information rate, which represents the guaranteed rate of traffic that can pass through cbs committed burst size, indicating the amount of committed burst traffic that can be passed through instantly pir peak information rate, which represents the maximum rate of traffic that can pass through pbs peak burst size, indicating the amount of peak burst traffic that can be passed through instantly binding traffic behavior binding traffic behavior by configuring a car (committed access rate) template and binding it with an acl (access control list), users can finely control which traffic needs to be rate limited this approach helps in managing bandwidth usage for specific types or sources of traffic, preventing certain flows from excessively consuming network resources and thereby balancing the overall network utilization operation command description enter acl configuration view access list l3 \<name> egress bind the car template with the acl rule \<id> traffic behavior \<traffic behavior name> enter interface configuration view interface ethernet interface id bind the behavior to the interface acl \<name> it is also possible to bind the car template directly to the port operation command description enter interface configuration view interface ethernet interface id bind the behavior to the interface traffic behavior bind \[egress] \<traffic behavior name> egress\ bind in the direction of the output interface display and maintenance display and maintenance operation command view qos map configuration show qos map{all|dot1p to tc |dscp to tc|tc to queue} view the interface mapping table show interface qos map bind view outbound queue statistics show queue counters \[\<interface name>] view interface queue scheduling mode show interface uc tx queue view interface based traffic shaping rules show interface port shaper view configured behaviors and car policies show traffic behavior rule view behavior hit statistics show traffic behavior counters priority mapping and queue scheduling configuration example priority mapping and queue scheduling configuration example network requirement in a certain data center network structure as shown in the diagram below, there are three types of traffic accessing the internet http, ftp, and email, with corresponding dscp values of 33, 35, and 27 the current requirement is to configure the packet transmission priorities on the device as follows http > ftp > email in case of congestion, ensure the priority transmission of http packets http data must be transmitted first before sending other data, and the ratio of ftp to email traffic should be controlled at 2 1 procedure 1 assign ip addresses to interfaces for network access 2 configure dscp to priority mapping sonic(config)# qos map dscp to tc profile1 33 4 sonic(config)# qos map dscp to tc profile1 35 3 sonic(config)# qos map dscp to tc profile1 27 2 sonic(config)# interface ethernet 1 sonic(config if 1)# qos map bind dscp to tc profile1 3 configure mapping from local priority to egress queue sonic(config)# qos map tc to queue test 0 0 sonic(config)# qos map tc to queue test 1 1 sonic(config)# qos map tc to queue test 2 2 sonic(config)# qos map tc to queue test 3 3 sonic(config)# qos map tc to queue test 4 4 sonic(config)# qos map tc to queue test 5 5 sonic(config)# qos map tc to queue test 6 6 sonic(config)# qos map tc to queue test 7 7 sonic(config)# qos map all bind tc to queue 4 configure dwrr scheduling on ethernet1 sonic(config)# interface ethernet 1 sonic(config if 1)# uc tx queue scheduler 4 mode strict sonic(config if 1)# uc tx queue scheduler 3 mode dwrr weight 2 sonic(config if 1)# uc tx queue scheduler 2 mode dwrr weight 1 verify configuration 1 view configuration sonic# show qos map dscp to tc { "profile1" { "27" "2", "33" "4", "35" "3" } } sonic# show interface qos map bind { "ethernet1" { "dscp to tc map" "\[dscp to tc map|profile1]" } } sonic# show interface uc tx queue { "ethernet1|4" { "scheduler|scheduler ethernet1 2" { "type" "strict" } } "ethernet1|3" { "scheduler|scheduler ethernet1 3" { "type" "dwrr" } } "ethernet1|2" { "scheduler|scheduler ethernet1 4" { "type" "dwrr" } } } when congestion occurs, queue4 should be prioritized, and there should be no packet drops in queue4 this means that the packets from the http traffic (dscp 33) in queue4 should be serviced without any drops traffic shaping configuration example traffic shaping configuration example network requirements a data center network structure is shown below, the services from the network side of the network are data, voice and video, carrying 802 1p priorities of 2, 3 and 4 respectively bandwidth jitter may occur because the traffic rate on the ingress side of the device is greater than the rate on the egress side to reduce bandwidth jitter while ensuring bandwidth requirements for various services, it is required that device egress bandwidth is limited to 1000mbit/s; data bandwidth limited to 200mbit/s; voice bandwidth is limited to 300mbit/s; video bandwidth limited to 500mbit/s; procedure 1 configure each interface ip to enable users to access the network through the device 2 configure priority mapping for dot1p to tc sonic(config)# qos map dot1p to tc profile1 2 2 sonic(config)# qos map dot1p to tc profile1 3 3 sonic(config)# qos map dot1p to tc profile1 4 4 sonic(config)# interface ethernet 1 sonic(config if 1)# qos map bind dot1p to tc profile1 3 configure port traffic shaping on ethernet1 of the device, set pir=12500000 byte/s, pbs=1280000 byte sonic(config)# interface ethernet 1 sonic(config if 1)# port shaper enable 12500000 1280000 4 configure queue traffic shaping policies sonic(config)# interface ethernet 1 sonic(config if 1)# uc tx queue scheduler 2 mode strict sonic(config if 1)# uc tx queue scheduler 2 pir 200000000 sonic(config if 1)# uc tx queue scheduler 3 mode strict sonic(config if 1)# uc tx queue scheduler 3 pir 300000000 sonic(config if 1)# uc tx queue scheduler 4 mode strict sonic(config if 1)# uc tx queue scheduler 4 pir 500000000 verify configuration 1 configuration verification sonic# show qos map dot1p to tc sonic# show interface qos map bind sonic# show interface port shaper 2 streaming verification after successful configuration, check the port count through the command show interfaces counters and check the queue reception through the command show queue counters 1 on the device, both meet the requirements