Junos CoS Configuration: Classifiers, Schedulers, Rewrite Rules

Juniper Junos Class of Service (CoS) can look intimidating because traffic treatment is split across several mapping components: a classifier marks packets at ingress, a scheduler-map picks which queue each forwarding class uses, and a rewrite rule re-marks packets at egress. This guide explains the data flow between those components and gives you a complete, copy-paste Junos CoS configuration for prioritising voice traffic, from class-of-service hierarchy to verification commands on MX and QFX platforms.

How the Junos CoS Components Map Together

Junos CoS is built from four mapping tables. Classifiers map incoming code-points (DSCP, 802.1p, MPLS EXP) to a forwarding class + loss priority. Scheduler-maps assign each forwarding class to a scheduler (transmit rate, buffer, priority). Drop-profile maps tie loss priority to a drop profile, and rewrite-rules map forwarding class + loss priority back to egress code-points so the marking survives to the next hop. Getting these four tables consistent is the whole game.

The CoS Pipeline: Ingress to Egress

It helps to follow one packet through the box. On the way in, the classifier reads a code-point and stamps the packet with two internal values: a forwarding class (which queue) and a loss priority (how aggressively the packet may be dropped when the queue is busy). Those internal values travel with the packet through the forwarding path. On the way out, the scheduler decides when the packet is transmitted, using the transmit rate, buffer size and priority that the scheduler-map assigned to the forwarding class. Just before the packet leaves the interface, the rewrite rule translates the internal forwarding class and loss priority back into a wire-visible code-point. If any of those four tables is missing a mapping, the packet silently falls into a default class and your careful engineering evaporates.

Classifiers: DSCP, 802.1p and MPLS EXP

Junos ships with sensible default classifiers, and the fastest way to build a custom one is to import the default and override the entries you care about, rather than writing every code-point from scratch. A classifier can also be fixed or multifield: a fixed classifier looks only at the code-point, while a multifield classifier can match on interface, source or destination address and protocol — useful when untrusted hosts arrive with no marking at all.

Trust Boundaries: Where Classification Should Happen

Classify as close to the source as you can trust. A server, IP phone or video endpoint that marks its own traffic correctly lets the first switch simply trust the DSCP. If a device cannot be trusted, mark it on the access switch with a multifield classifier that assigns a class based on VLAN or port, and rewrite the DSCP at the same time so the downstream network sees a consistent value. The trust boundary is a policy decision, not a technical one, but forgetting it is the most common reason a CoS design has no effect.

Defining Forwarding Classes and a Classifier

Start by mapping DSCP EF (voice) to an expedited-forwarding queue and copying the default classifier as a base:

set class-of-service forwarding-classes class expedited-forwarding queue 5
set class-of-service classifiers dscp voice-classifier import default
set class-of-service classifiers dscp voice-classifier forwarding-class expedited-forwarding loss-priority low code-points ef

Creating a Scheduler and Scheduler-Map

Give the voice queue strict-high priority plus a guaranteed transmit rate, and the best-effort queue the remainder:

set class-of-service schedulers ef-scheduler transmit-rate percent 30
set class-of-service schedulers ef-scheduler buffer-size percent 20
set class-of-service schedulers ef-scheduler priority strict-high
set class-of-service scheduler-maps smap1 forwarding-class expedited-forwarding scheduler ef-scheduler

Clarify the semantics before copying these numbers. transmit-rate is a guaranteed share of bandwidth, not a cap — a class can borrow idle bandwidth above its rate unless you also configure shaping. priority strict-high means the scheduler serves this queue before any others as long as it has packets, which is exactly what a voice queue wants and exactly what a greedy data queue must never have. buffer-size controls how much memory the queue may occupy; too small and the queue drops bursts before the scheduler can drain them.

Drop Profiles and Loss Priority (WRED)

Loss priority is what makes drop profiles useful. You classify a packet as low or high loss priority, then a drop-profile map links each loss priority to a WRED curve that drops low-priority packets early as the queue fills, protecting high-priority traffic without a hard tail-drop. In a well-built voice design the EF queue usually needs no drop profile at all — it is small and strictly prioritised — while best-effort and bulk classes benefit from WRED so that responsive TCP flows back off before the queue overflows.

Configuring Rewrite Rules and Applying CoS to an Interface

Rewrite the DSCP value on egress so downstream devices still see the marking, then attach classifier, scheduler-map and rewrite rule to the logical interface:

set class-of-service rewrite-rules dscp dscp-rewrite forwarding-class expedited-forwarding loss-priority low code-point ef
set class-of-service interfaces ge-0/0/0 unit 0 classifiers dscp voice-classifier
set class-of-service interfaces ge-0/0/0 unit 0 scheduler-map smap1
set class-of-service interfaces ge-0/0/0 unit 0 rewrite-rules dscp dscp-rewrite
commit

End-to-End Example: Prioritising Voice Across the Fabric

Put the pieces together for a typical office deployment. IP phones mark their signalling with DSCP CS3 and their media with DSCP EF, so the first access switch is configured to trust DSCP on the phone-facing ports and to classify on a multifield basis on the uplink toward the phones' VLAN. The access switch maps EF to the expedited-forwarding class and CS3 to the assured-forwarding class, and its rewrite rule preserves both values. At the distribution and core layers the DSCP is already correct, so those devices only need a scheduler-map and a rewrite rule — the classifier can simply trust what arrives. Every hop in that chain must agree on which code-point means "voice," because a single device that rewrites EF to BE silently demotes the traffic for the rest of its life.

Where a device is untrusted — a guest port, or a server that marks everything EF — classify by port or VLAN rather than by code-point and rewrite the value you want. That single rule closes the most common CoS loophole, in which a badly behaved host inherits strict priority and starves the queue.

CoS in an Overlay (VXLAN) Fabric

In a VXLAN fabric, the original frame's DSCP lives inside the encapsulated payload while the outer IP header carries its own DSCP that the underlay actually forwards on. Junos can copy the inner value to the outer header so that classification done at the edge survives through the spine-leaf underlay; without that copy, the outer header defaults to a single class and every overlay flow is treated identically by the underlay. On the return path the de-encapsulation restores the original frame, so the marking the server set is what the server sees again. If your overlay priority seems to be ignored, check the copy policy on the VTEP before you rewrite the access-layer classifiers.

Common Mistakes That Neutralise a CoS Design

• Configuring a classifier on the wrong interface direction — classifiers are ingress-only, so placing one on an egress interface does nothing.
• Forgetting the rewrite rule: the internal forwarding class is correct, but the packet leaves with its original DSCP and downstream devices classify it as best effort.
• Giving more than one forwarding class strict-high priority. Two strict queues means the scheduler has no deterministic order between them and the lower one can be starved anyway.
• Setting transmit-rate percent values that add up to more than 100 across the scheduler-map; the excess is not a hard error, it just produces surprises under load.
• Assuming a policy change takes effect without a commit, or forgetting that some queue changes need the interface to be reset.

Verification Commands

Check the applied CoS state on the interface and the configured tables:

show class-of-service interface ge-0/0/0
show class-of-service classifier dscp
show class-of-service scheduler-map
show class-of-service forwarding-class
show class-of-service interface ge-0/0/0 statistics
show class-of-service fabric statistics

Juniper documentation stresses that on QFX and MX switches you should verify the forwarding-class-to-queue mapping matches the platform default queues to avoid accidentally renumbering queues that control traffic uses.

Testing That CoS Actually Works

Configuration that parses is not configuration that shapes. Generate traffic explicitly marked with DSCP EF on one host and unmarked traffic on another, then watch the per-queue transmit counters move in the ratio you designed. A quick sanity check is to confirm that the expedited-forwarding counter increments only for packets you marked, which proves the classifier is reading the code-point you think it is:

monitor interface ge-0/0/0
show interfaces ge-0/0/0 extensive | match "queue"
show class-of-service interface ge-0/0/0 | match "Forwarding class"
clear interfaces statistics ge-0/0/0

If the EF counter never increments, the classifier is not matching — check the code-point value, the direction of the classifier (ingress only), and whether the packet is arriving untagged and being classified by the bridge-domain code-point instead of DSCP.

Platform Differences: MX vs QFX

The same four tables apply on both platforms, but the number of forwarding classes and the default queue assignment differ by hardware. On MX routers the queues are typically fixed per PFE and the scheduler hierarchy moves data through an internal fabric scheduler, while on QFX switches the queue count depends on the port profile you choose (for example a 8-queue or 12-queue profile). Always confirm the queue numbering against the platform default before you remap a forwarding class, because moving control traffic into a low-priority queue is one of the few ways to break a working switch with a CoS change.

Related Guides on This Site

Combine CoS with a working underlay: see our Junos OSPF configuration guide, the Junos static route and qualified next-hop guide, and the Arista EOS QoS configuration guide for a cross-vendor comparison of marking and queueing. For the boundary where trust begins, see QoS trust boundary and DSCP marking on Cisco switches, and for lossless fabrics read RoCEv2 lossless Ethernet with PFC and ECN plus the Cisco IOS XR QoS class-map and shaping examples.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/cos/topics/task/cos-inputs-outputs-sample-configs.html