Configuring Strict-High Priority

Note: This section is applicable to only J Series device and SRX210, SRX240, and SRX650 devices.

You can configure one queue per interface to have strict high priority, which causes delay-sensitive traffic, such as voice traffic, to be removed and forwarded with minimum delay. Packets that are queued in a strict-priority queue are removed before packets in other queues, including high-priority queues.

The strict high-priority queuing feature allows you to configure traffic policing that prevents lower-priority queues from being starved. The strict-priority queue does not cause starvation of other queues because the configured policer allows the queue to exceed the configured bandwidth only when other queues are not congested. If the interface is congested, the software polices strict-priority queues to the configured bandwidth.

To prevent queue starvation of other queues, you must configure an output (egress) policer that defines a limit for the amount of traffic that the queue can service. The software services all traffic in the strict-priority queue that is under the defined limit. When strict-priority traffic exceeds the limit, the policer marks the traffic in excess of the limit as out-of-profile. If the output port is congested, the software drops out-of-profile traffic.

You can also configure a second policer with an upper limit. When strict-priority traffic exceeds the upper limit, the software drops the traffic in excess of the upper limit, regardless of whether the output port is congested. This upper-limit policer is not a requirement for preventing starvation of the lower-priority queues. The policer for the lower limit, which marks the packets as out-of-profile, is sufficient to prevent starvation of other queues.

The following steps describe how strict priority queuing and policing works:

1. Identify delay-sensitive traffic by configuring a behavior aggregate (BA) or multifield (MF) classifier.
2. Minimize delay by assigning all delay-sensitive packets to the strict priority queue.
3. Prevent starvation on other queues by configuring a policer that checks the data stream entering the strict priority queue. The policer defines a lower bound, marks the packets that exceed the lower bound as out-of-profile, and drops the out-of-profile packets if the physical interface is congested. If there is no congestion, the software forwards all packets, including the out-of-profile packets.
4. Optionally, configure another policer that defines an upper bound and drops the packets that exceed the upper bound, regardless of congestion on the physical interface.

To configure strict priority queuing and prevent starvation of other queues, include the priority strict-high statement at the [edit class-of-service schedulers scheduler-name] hierarchy level and the if-exceeding and then out-of-profile statements at the [edit firewall policer policer-name] hierarchy level:

To verify your configuration, you can issue the following operational mode commands:

• show class-of-service scheduler-map map-name
• show interfaces interface-name extensive
• show interfaces queue interface-name

Example: Configuring Strict High Priority Using the CLI

Use a BA classifier to classify traffic based on the IP precedence of the packet. The classifier defines IP precedence value 101 as voice traffic and 000 as data traffic.

Configure two policers on the output interface that identify excess voice traffic belonging to the voice-class forwarding class. If the traffic exceeds 1 Mbps, a policer marks the traffic in excess of 1 Mbps as out-of-profile. If the traffic exceeds 2 Mbps, the second policer discards the traffic in excess of 2 Mbps.

Example: Configuring Priority Scheduling

JUNOS Software supports multiple levels of transmission priority, which in order of increasing priority are low, medium-low, medium-high, and high, and strict-high. This allows the software to service higher-priority queues before lower-priority queues.

Priority scheduling determines the order in which an output interface transmits traffic from the queues, thus ensuring that queues containing important traffic are provided better access to the outgoing interface. This is accomplished through a procedure in which the software examines the priority of the queue. In addition, the software determines if the individual queue is within its defined bandwidth profile. This binary decision, which is reevaluated on a regular time cycle, compares the amount of data transmitted by the queue against the amount of bandwidth allocated to it by the scheduler. When the transmitted amount is less than the allocated amount, the queue is considered to be in profile. A queue is out-of-profile when its transmitted amount is larger than its allocated amount.

The queues for a given output physical interface (or output logical interface if per-unit scheduling is enabled on that interface) are divided into sets based on their priority. Any such set contains queues of the same priority.

The software traverses the sets in descending order of priority. If at least one of the queues in the set has a packet to transmit, the software selects that set. A queue from the set is selected based on the weighted round-robin (WRR) algorithm, which operates within the set.

You can configure priority scheduling, as shown in the following example:

1. Configure a scheduler, be-sched, with medium-low priority.
   [edit class-of-service]schedulers {be-sched {priority medium-low;}}
2. Configure a scheduler map, be-map, that associates be-sched with the best-effort forwarding class.
   [edit class-of-service]scheduler-maps {be-map {forwarding-class best-effort scheduler be-sched;}}
3. Assign be-map to a Gigabit Ethernet interface, ge-0/0/0.
   [edit class-of-service]interfaces {ge-0/0/0 {scheduler-map be-map;}}