- play_arrow Overview
- play_arrow Introduction to Class of Service
-
- play_arrow Configuring Class of Service Components
- play_arrow Assigning Service Levels with Classifiers
- play_arrow Controlling Network Access with Traffic Policing
- Simple Filters and Policers Overview
- Two-Rate Three-Color Policer Overview
- Example: Configuring a Two-Rate Three-Color Policer
- Logical Interface (Aggregate) Policer Overview
- Two-Color Policer Configuration Overview
- Example: Configuring a Two-Color Logical Interface (Aggregate) Policer
- Guidelines for Configuring Simple Filters
- Example: Configuring and Applying a Firewall Filter for a Multifield Classifier
- play_arrow Controlling Output Queues with Forwarding Classes
- Forwarding Classes Overview
- Example: Configuring Forwarding Classes
- Example: Assigning Forwarding Classes to Output Queues
- Example: Classifying All Traffic from a Remote Device by Configuring Fixed Interface-Based Classification
- Understanding the SPC High-Priority Queue
- Example: Configuring the SPC High-Priority Queue
- Understanding Queuing and Marking of Host Outbound Traffic
- Default Routing Engine Protocol Queue Assignments
- play_arrow Altering Outgoing Packets Headers with Rewrite Rules
- play_arrow Defining Output Queue Properties with Schedulers
- Schedulers Overview
- Default Scheduler Settings
- Transmission Scheduling Overview
- Excess Bandwidth Sharing and Minimum Logical Interface Shaping
- Excess Bandwidth Sharing Proportional Rates
- Calculated Weights Mapped to Hardware Weights
- Weight Allocation with Only Shaping Rates or Unshaped Logical Interfaces
- Shared Bandwidth Among Logical Interfaces
- Example: Configuring Class-of-Service Schedulers on a Security Device
- Scheduler Buffer Size Overview
- Example: Configuring a Large Delay Buffer on a Channelized T1 Interface
- Configuring Large Delay Buffers in CoS
- Example: Configuring and Applying Scheduler Maps
- Applying Scheduler Maps and Shaping Rate to DLCIs and VLANs
- Example: Applying Scheduling and Shaping to VLANs
- play_arrow Removing Delays with Strict-Priority Queues
- play_arrow Controlling Congestion with Drop Profiles
- play_arrow Controlling Congestion with Explicit Congestion Notification
- play_arrow Controlling Congestion with Adaptive Shapers
- play_arrow Limiting Traffic Using Virtual Channels
- play_arrow Enabling Queuing for Tunnel Interfaces
- play_arrow Naming Components with Code-Point Aliases
-
- play_arrow Configuring Class of Service Scheduler Hierarchy
- play_arrow Controlling Traffic by Configuring Scheduler Hierarchy
-
- play_arrow Configuring Class of Service for IPv6
- play_arrow Configuring Class of Service for IPv6 Traffic
-
- play_arrow Configuration Statements and Operational Commands
Understanding Priority Propagation
SRX5600 and SRX5800 firewalls with input/output cards (IOCs) perform priority propagation. Priority propagation is useful for mixed traffic environments when, for example, you want to make sure that the voice traffic of one customer does not suffer from the data traffic of another customer. Nodes and queues are always serviced in the order of their priority. The priority of a queue is decided by configuration (the default priority is low) in the scheduler. However, not all elements of hierarchical schedulers have direct priorities configured. Internal nodes, for example, must determine their priority in other ways.
The priority of any internal node is decided as follows:
By the highest priority of an active child (interface sets only take the highest priority of their active children
Whether the node is above its configured guaranteed rate (CIR) or not (this is relevant only if the physical interface is in CIR mode)
Each queue has a configured priority and a hardware priority. Table 1 shows the usual mapping between the configured priority and the hardware priority.
Configured Priority | Hardware Priority |
|---|---|
Strict-high | 0 |
High | 0 |
Medium-high | 1 |
Medium-low | 1 |
Low | 2 |
Figure 1 shows a physical interface with hierarchical schedulers configured. The configured priorities are shown for each queue at the top of the figure. The hardware priorities for each node are shown in parentheses. Each node also shows any configured shaping rate (PIR) or guaranteed rate (CIR) and whether or not the queues are above or below the CIR. The nodes are shown in one of the following three states:
Above the CIR (clear)
Below the CIR (dark)
Condition where the CIR does not matter (gray)
In Figure 1, the strict high queue for C-VLAN 0 (cvlan 0) receives service first, even though the C-VLAN is above the configured CIR. Once that queue has been drained, and the priority of the node has become 3 instead of 0 (because of the lack of strict-high traffic), the system moves on to the medium queues (cvlan 1 and cvlan 3), draining them in a round-robin fashion where empty queues lose their hardware priority. The low queue on cvlan 4 (priority 2) is sent next because that mode is below the CIR. Then, the high queues on cvlan 0 and cvlan2 (both now with priority 3) are drained in a round-robin fashion, and finally the low queue on cvlan 0 is drained (because svlan 0 has a priority of 3).
