Queuing
Queuing is a congestion-avoidance function that prioritizes packet delivery. Queuing ensures discriminate packet discard during network congestion, and can delay a packet in memory until the scheduled transmission.
You can use queuing to manage congestion. Congestion management involves the creation of queues, assignment of packets to the queues based on the classification of the packet, and scheduling of the packets in a queue for transmission.
The system schedules packets for transmission according to their assigned priority and the queuing mechanism configured for the interface. The scheduler determines the order of packet transmission by controlling how the system services queues with respect to each other. The switch uses 16 CPU queues (used by traffic destined to the CPU), and eight unicast and eight multicast queues for each port. The deepest queue does not go beyond 60,000 packets.
A scheduler services the eight queues for each port, using a combination of strict priority and round-robin. Queue zero through five use round robin, and queues six and seven drain completely, or up to certain rate limits.
There are eight priorities on each egress port. Each Weighted Round Robin (WRR) queue has a minimum guaranteed weight to ensure fair bandwidth allocation for each queue in case all QoS queues are utilized and there is congestion. With the default profile, Class of Service (CoS) 0 to CoS 5 are WRR, and the default weights are 10, 20, 30, 40, 50, and 50 respectively. CoS 6 and CoS 7 are strict priority queues. The switch subjects CoS 6 and CoS 7 to traffic shaping at 50 per cent and five per cent of line rate respectively.
All packets destined for the CPU are sent as unicast packets.
Front panel ports also have 8 queues. When a front panel port is oversubscribed with both unicast and multicast packets, the bandwidth is divided so that the unicast packets receive 80% of the bandwidth and multicast packets 20% of the bandwidth.
If there are no multicast packets using the reserved 20%, the bandwidth is evenly distributed between COS levels 0 to 6. This results in approximately 3.3% more bandwidth for each level. If a specific COS level is not oversubscribed, the unused bandwidth is evenly distributed between the other COS levels. The CLI provides commands to map ingressing packets to specific COS levels.
Note
Unicast packets will be tail dropped on the ingress card. Multicast packets will be dropped at egress card.
Among the WRR queues, the approximate bandwidth percentage is relative to the remaining bandwidth after subtracting the Strict Priority queues. The following tables provide the approximate bandwidth percentage based on queue congestion.
| Queue | Approximate bandwidth percentage* |
|---|---|
|
0 |
5% |
|
1 |
10% |
|
2 |
15% |
|
3 |
20% |
|
4 |
25% |
|
5 |
25% |
|
* The approximate value assumes that all queues 0 to 5 are congested and similar packet sizes. Any queue that does not require bandwidth results in adding more bandwidth to the WRR queues. Percentage is relative to the total bandwidth minus the bandwidth consumed by Cos 6 and 7 (strict queues). |
|
| Queue | Approximate bandwidth percentage* |
|---|---|
|
0 |
2.25% |
|
1 |
4.5% |
|
2 |
6.75% |
|
3 |
9% |
|
4 |
11.25% |
|
5 |
11.25% |
|
6 |
50% |
|
7 |
5% |
|
* The approximate value assumes that all queues 0 to 7 are congested and similar packet sizes. |
|
CPU Queues
This section provides information about CPU traffic and queues.
The following table outlines the CPU traffic, and which queue it uses.
|
Queue description |
Queue ID |
Queue pps, burst size |
Traffic type |
|---|---|---|---|
|
Other |
0 |
1400 pps, 100 kbps |
Others |
|
BC_Other |
1 |
1400 pps, 100 kbps |
Broadcast |
|
HI_CPU looper |
2 |
4000 pps, 100 kbps |
IP_COS01 |
|
HI_CPU |
3 |
4000 pps, 100 kbps |
IP_COS23, Multicast Data |
|
HI_CPU |
4 |
4000 pps, 100 kbps |
IP_COS4 |
|
HI_CPU |
5 |
4000 pps, 100 kbps |
IP_COS5, IGMP, PIM Unicast |
|
HI_CPU |
6 |
4000 pps, 100 kbps |
ARP, RARP, ND Multicast and Unicast, MLD |
|
HI_CPU |
7 |
4000 pps, 100 kbps |
IP_COS6, Telnet, SSH |
|
mgmt |
8 |
4000 pps, 200 kbps |
IP_COS7, OSPF |
|
Low rate looper |
9 |
4000 pps, 6000 kbps |
OSPF Multicast, PIM Multicast, RIP_v1, RIP_v2 |
|
Low rate 1 |
10 |
4000 pps,12000 kbps |
ISIS |
|
Low latency |
11 |
4000 pps, 1000 kbps |
ISIS Hello, LLDP, EAP, IST Control |
|
Low latency |
12 |
500 pps, 32 kbps |
VRRP, CFM |
|
Low latency |
13 |
256 pps, 32 kbps |
SLPP |
|
Low latency |
14 |
100 pps, 32 kbps |
BPDU |
|
Low latency |
15 |
250 pps, 32 kbps |
LACP, VLACP, TUNI-extract |
Queue profiles
|
Feature |
Product |
Release introduced |
|---|---|---|
|
QoS per queue rate limiting |
5320 Series |
Fabric Engine 8.6 |
|
5420 Series |
VOSS 8.4 |
|
|
5520 Series |
VOSS 8.2.5 |
This section identifies optional ways to customize the egress queues and scheduling depending on your need to override the default configuration. You can also enable egress queue rate limiting, if desired.
Use a queue profile to apply configured egress queue parameters and modify each queue individually. You can use the queue profile to configure a minimum weight for the queue and to enable rate limiting for the queue. The queue profile applies to all ports in the switch.
Note
If you enable rate limiting for all queues, the scheduler treats all queues as strict priority queues. If all queues are strict priority, the scheduler services the highest priority queue first until the maximum bandwidth is met, and then it services the next highest priority queue. Queue 0 is the lowest priority queue, which means that when over-subscribed, the lower priority queues are serviced last, or not at all.
The switch supports six queue profiles. The default queue profile, with the name default and ID 1, is automatically created during system startup and cannot be deleted.
Note
The egress queues with rate limiting enabled must be contiguous. For example, you can configure queues 3–6, but you cannot configure 3 and 6.
After you make a configuration change to a queue profile, you must apply the profile before the changes take effect.