- play_arrow Overview
- play_arrow Understanding How Class of Service Manages Congestion and Defines Traffic Forwarding Behavior
- Understanding How Class of Service Manages Congestion and Controls Service Levels in the Network
- How CoS Applies to Packet Flow Across a Network
- The Junos OS CoS Components Used to Manage Congestion and Control Service Levels
- Mapping CoS Component Inputs to Outputs
- Default Junos OS CoS Settings
- Packet Flow Through the Junos OS CoS Process Overview
- Configuring Basic Packet Flow Through the Junos OS CoS Process
- Example: Classifying All Traffic from a Remote Device by Configuring Fixed Interface-Based Classification
- Interface Types That Do Not Support Junos OS CoS
-
- play_arrow Configuring Platform-Specific Functionality
- play_arrow Configuring Class of Service on ACX Series Universal Metro Routers
- CoS on ACX Series Routers Features Overview
- Understanding CoS CLI Configuration Statements on ACX Series Routers
- DSCP Propagation and Default CoS on ACX Series Routers
- Configuring CoS on ACX Series Routers
- Classifiers and Rewrite Rules at the Global, Physical, and Logical Interface Levels Overview
- Configuring Classifiers and Rewrite Rules at the Global and Physical Interface Levels
- Applying DSCP and DSCP IPv6 Classifiers on ACX Series Routers
- Schedulers Overview for ACX Series Routers
- Shared and Dedicated Buffer Memory Pools on ACX Series Routers
- CoS for PPP and MLPPP Interfaces on ACX Series Routers
- CoS for NAT Services on ACX Series Routers
- Hierarchical Class of Service in ACX Series Routers
- Storm Control on ACX Series Routers Overview
- play_arrow Configuring Class of Service on MX Series 5G Universal Routing Platforms
- Junos CoS on MX Series 5G Universal Routing Platforms Overview
- CoS Features and Limitations on MX Series Routers
- Configuring and Applying IEEE 802.1ad Classifiers
- Scheduling and Shaping in Hierarchical CoS Queues for Traffic Routed to GRE Tunnels
- Example: Performing Output Scheduling and Shaping in Hierarchical CoS Queues for Traffic Routed to GRE Tunnels
- CoS-Based Interface Counters for IPv4 or IPv6 Aggregate on Layer 2
- Enabling a Timestamp for Ingress and Egress Queue Packets
- play_arrow Configuring Class of Service on PTX Series Packet Transport Routers
- CoS Features and Limitations on PTX Series Routers
- CoS Feature Differences Between PTX Series Packet Transport Routers and T Series Routers
- Understanding Scheduling on PTX Series Routers
- Virtual Output Queues on PTX Series Packet Transport Routers
- Example: Configuring Excess Rate for PTX Series Packet Transport Routers
- Identifying the Source of RED Dropped Packets on PTX Series Routers
- Configuring Queuing and Shaping on Logical Interfaces on PTX Series Routers
- Example: Configuring Queuing and Shaping on Logical Interfaces in PTX Series Packet Transport Routers
- Example: Configuring Strict-Priority Scheduling on a PTX Series Router
- CoS Support on EVPN VXLANs
- Understanding CoS CLI Configuration Statements on PTX Series Routers
- Classification Based on Outer Header of Decapsulation Tunnel
-
- play_arrow Configuring Line Card-Specific and Interface-Specific Functionality
- play_arrow Feature Support of Line Cards and Interfaces
- play_arrow Configuring Class of Service for Tunnels
- play_arrow Configuring Class of Service on Services PICs
- CoS on Services PICs Overview
- Configuring CoS Rules on Services PICs
- Configuring CoS Rule Sets on Services PICs
- Example: Configuring CoS Rules on Services PICs
- Packet Rewriting on Services Interfaces
- Multiservices PIC ToS Translation
- Fragmentation by Forwarding Class Overview
- Configuring Fragmentation by Forwarding Class
- Configuring Drop Timeout Interval for Fragmentation by Forwarding Class
- Example: Configuring Fragmentation by Forwarding Class
- Allocating Excess Bandwidth Among Frame Relay DLCIs on Multiservices PICs
- Configuring Rate Limiting and Sharing of Excess Bandwidth on Multiservices PICs
- play_arrow Configuring Class of Service on IQ and Enhanced IQ (IQE) PICs
- CoS on Enhanced IQ PICs Overview
- Calculation of Expected Traffic on IQE PIC Queues
- Configuring the Junos OS to Support Eight Queues on IQ Interfaces for T Series and M320 Routers
- BA Classifiers and ToS Translation Tables
- Configuring ToS Translation Tables
- Configuring Hierarchical Layer 2 Policers on IQE PICs
- Configuring Excess Bandwidth Sharing on IQE PICs
- Configuring Rate-Limiting Policers for High Priority Low-Latency Queues on IQE PICs
- Applying Scheduler Maps and Shaping Rate to Physical Interfaces on IQ PICs
- Applying Scheduler Maps to Chassis-Level Queues
- play_arrow Configuring Class of Service on Ethernet IQ2 and Enhanced IQ2 PICs
- CoS on Enhanced IQ2 PICs Overview
- CoS Features and Limitations on IQ2 and IQ2E PICs (M Series and T Series)
- Differences Between Gigabit Ethernet IQ and Gigabit Ethernet IQ2 PICs
- Shaping Granularity Values for Enhanced Queuing Hardware
- Ethernet IQ2 PIC RTT Delay Buffer Values
- Configuring BA Classifiers for Bridged Ethernet
- Setting the Number of Egress Queues on IQ2 and Enhanced IQ2 PICs
- Configuring the Number of Schedulers per Port for Ethernet IQ2 PICs
- Applying Scheduler Maps to Chassis-Level Queues
- CoS for L2TP Tunnels on Ethernet Interface Overview
- Configuring CoS for L2TP Tunnels on Ethernet Interfaces
- Configuring LNS CoS for Link Redundancy
- Example: Configuring L2TP LNS CoS Support for Link Redundancy
- Configuring Shaping on 10-Gigabit Ethernet IQ2 PICs
- Configuring Per-Unit Scheduling for GRE Tunnels Using IQ2 and IQ2E PICs
- Understanding Burst Size Configuration on IQ2 and IQ2E Interfaces
- Configuring Burst Size for Shapers on IQ2 and IQ2E Interfaces
- Configuring a CIR and a PIR on Ethernet IQ2 Interfaces
- Example: Configuring Shared Resources on Ethernet IQ2 Interfaces
- Configuring and Applying IEEE 802.1ad Classifiers
- Configuring Rate Limits to Protect Lower Queues on IQ2 and Enhanced IQ2 PICs
- Simple Filters Overview
- Configuring a Simple Filter
- play_arrow Configuring Class of Service on 10-Gigabit Ethernet LAN/WAN PICs with SFP+
- CoS on 10-Gigabit Ethernet LAN/WAN PIC with SFP+ Overview
- BA and Fixed Classification on 10-Gigabit Ethernet LAN/WAN PIC with SFP+ Overview
- DSCP Rewrite for the 10-Gigabit Ethernet LAN/WAN PIC with SFP+
- Configuring DSCP Rewrite for the 10-Gigabit Ethernet LAN/WAN PIC
- Queuing on 10-Gigabit Ethernet LAN/WAN PICs Properties
- Mapping Forwarding Classes to CoS Queues on 10-Gigabit Ethernet LAN/WAN PICs
- Scheduling and Shaping on 10-Gigabit Ethernet LAN/WAN PICs Overview
- Example: Configuring Shaping Overhead on 10-Gigabit Ethernet LAN/WAN PICs
- play_arrow Configuring Class of Service on Enhanced Queuing DPCs
- Enhanced Queuing DPC CoS Properties
- Configuring Rate Limits on Enhanced Queuing DPCs
- Configuring WRED on Enhanced Queuing DPCs
- Configuring MDRR on Enhanced Queuing DPCs
- Configuring Excess Bandwidth Sharing
- Configuring Customer VLAN (Level 3) Shaping on Enhanced Queuing DPCs
- Simple Filters Overview
- Configuring Simple Filters on Enhanced Queuing DPCs
- Configuring a Simple Filter
- play_arrow Configuring Class of Service on MICs, MPCs, and MLCs
- CoS Features and Limitations on MIC and MPC Interfaces
- Dedicated Queue Scaling for CoS Configurations on MIC and MPC Interfaces Overview
- Verifying the Number of Dedicated Queues Configured on MIC and MPC Interfaces
- Scaling of Per-VLAN Queuing on Non-Queuing MPCs
- Increasing Available Bandwidth on Rich-Queuing MPCs by Bypassing the Queuing Chip
- Flexible Queuing Mode
- Multifield Classifier for Ingress Queuing on MX Series Routers with MPC
- Example: Configuring a Filter for Use as an Ingress Queuing Filter
- Ingress Queuing Filter with Policing Functionality
- Ingress Rate Limiting on MX Series Routers with MPCs
- Rate Shaping on MIC and MPC Interfaces
- Per-Priority Shaping on MIC and MPC Interfaces Overview
- Example: Configuring Per-Priority Shaping on MIC and MPC Interfaces
- Configuring Static Shaping Parameters to Account for Overhead in Downstream Traffic Rates
- Example: Configuring Static Shaping Parameters to Account for Overhead in Downstream Traffic Rates
- Traffic Burst Management on MIC and MPC Interfaces Overview
- Understanding Hierarchical Scheduling for MIC and MPC Interfaces
- Configuring Ingress Hierarchical CoS on MIC and MPC Interfaces
- Configuring a CoS Scheduling Policy on Logical Tunnel Interfaces
- Per-Unit Scheduling and Hierarchical Scheduling for MPC Interfaces
- Managing Dedicated and Remaining Queues for Static CoS Configurations on MIC and MPC Interfaces
- Excess Bandwidth Distribution on MIC and MPC Interfaces Overview
- Bandwidth Management for Downstream Traffic in Edge Networks Overview
- Scheduler Delay Buffering on MIC and MPC Interfaces
- Managing Excess Bandwidth Distribution on Static Interfaces on MICs and MPCs
- Drop Profiles on MIC and MPC Interfaces
- Intelligent Oversubscription on MIC and MPC Interfaces Overview
- Jitter Reduction in Hierarchical CoS Queues
- Example: Reducing Jitter in Hierarchical CoS Queues
- CoS on Ethernet Pseudowires in Universal Edge Networks Overview
- CoS Scheduling Policy on Logical Tunnel Interfaces Overview
- Configuring CoS on an Ethernet Pseudowire for Multiservice Edge Networks
- CoS for L2TP LNS Inline Services Overview
- Configuring Static CoS for an L2TP LNS Inline Service
- CoS on Circuit Emulation ATM MICs Overview
- Configuring CoS on Circuit Emulation ATM MICs
- Understanding IEEE 802.1p Inheritance push and swap from a Transparent Tag
- Configuring IEEE 802.1p Inheritance push and swap from the Transparent Tag
- CoS on Application Services Modular Line Card Overview
- play_arrow Configuring Class of Service on Aggregated, Channelized, and Gigabit Ethernet Interfaces
- Limitations on CoS for Aggregated Interfaces
- Policer Support for Aggregated Ethernet Interfaces Overview
- Understanding Schedulers on Aggregated Interfaces
- Examples: Configuring CoS on Aggregated Interfaces
- Hierarchical Schedulers on Aggregated Ethernet Interfaces Overview
- Configuring Hierarchical Schedulers on Aggregated Ethernet Interfaces
- Example: Configuring Scheduling Modes on Aggregated Interfaces
- Enabling VLAN Shaping and Scheduling on Aggregated Interfaces
- Class of Service on demux Interfaces
- Example: Configuring Per-Unit Schedulers for Channelized Interfaces
- Applying Layer 2 Policers to Gigabit Ethernet Interfaces
-
- play_arrow Configuration Statements and Operational Commands
ON THIS PAGE
Example: Configuring and Applying a Default DSCP Behavior Aggregate Classifier
A Junos OS classifier identifies and separates traffic flows and provides the means to prioritize traffic later in the class-of-service (CoS) process.
A behavior aggregate (BA) classifier performs this function by associating well-known CoS values with forwarding classes and loss priorities. To enable a default classifier, you simply apply it to your device interfaces. If a default classifier is not applied to an interface, it does not take effect.
Junos OS provides multiple default BA classifier types, which you can combine and supplement with custom BA classifiers as needed to achieve your overall traffic classification goals. This example shows how to apply the default (BA) DiffServ code point (DSCP) classifier and verify its functionality.
Requirements
To verify this procedure, this example uses a traffic generator. The traffic generator can be hardware-based or it can be software running on a server or host machine. If you do not have access to a traffic generator, you can use extended ping for verification. This approach is shown as well.
The functionality in this procedure is widely supported on devices that run Junos OS. The example shown here was tested and verified on MX Series routers running Junos OS Release 10.4.
Overview
The basis of Junos OS CoS is traffic differentiation. Assigning traffic to different classes of service provides the necessary differentiation. From the point of view of a router, the class of service assigned to a packet defines how the router behaves toward the packet. The concept of traffic differentiation is present in every CoS tool, and as a result, classes of service are present across the entire CoS design. A classifier has one input, the incoming packet, and it has N possible outputs, where N is the number of possible classes of service into which the packet can be classified.
BA classification is used when the traffic coming into your device already has trusted CoS values in the packet header. For example, the default DSCP BA classifier specifies that packets coming in with code points 000000 are assigned to the best-effort forwarding class and given a loss priority of low.
A forwarding class and loss priority are assigned by default
to each well-known DSCP. To view this, run the show class-of-service classifier
command.
user@host> show class-of-service classifier type dscp Classifier: dscp-default, Code point type: dscp, Index: 7 Code point Forwarding class Loss priority 000000 best-effort low 000001 best-effort low 000010 best-effort low 000011 best-effort low 000100 best-effort low 000101 best-effort low 000110 best-effort low 000111 best-effort low 001000 best-effort low 001001 best-effort low 001010 assured-forwarding low 001011 best-effort low 001100 assured-forwarding high 001101 best-effort low 001110 assured-forwarding high 001111 best-effort low 010000 best-effort low 010001 best-effort low 010010 best-effort low 010011 best-effort low 010100 best-effort low 010101 best-effort low 010110 best-effort low 010111 best-effort low 011000 best-effort low 011001 best-effort low 011010 best-effort low 011011 best-effort low 011100 best-effort low 011101 best-effort low 011110 best-effort low 011111 best-effort low 100000 best-effort low 100001 best-effort low 100010 best-effort low 100011 best-effort low 100100 best-effort low 100101 best-effort low 100110 best-effort low 100111 best-effort low 101000 best-effort low 101001 best-effort low 101010 best-effort low 101011 best-effort low 101100 best-effort low 101101 best-effort low 101110 expedited-forwarding low 101111 best-effort low 110000 network-control low 110001 best-effort low 110010 best-effort low 110011 best-effort low 110100 best-effort low 110101 best-effort low 110110 best-effort low 110111 best-effort low 111000 network-control low 111001 best-effort low 111010 best-effort low 111011 best-effort low 111100 best-effort low 111101 best-effort low 111110 best-effort low 111111 best-effort low
The forwarding class determines the output queue. By default, all best-effort traffic uses queue 0.
To view the queues that are associated, by default, with each
forwarding class, use the show class-of-service forwarding-class
command. (For clarity, some of the output is excluded.)
user@host> show class-of-service forwarding-class Forwarding class ID Queue best-effort 0 0 expedited-forwarding 1 1 assured-forwarding 2 2 network-control 3 3
The loss priority is used by schedulers in conjunction with the random early detection (RED) algorithm to control packet discard during periods of congestion. When you are thinking about loss priorities, keep in mind that unless you configure them, they have no meaning. The default drop behavior is to wait until the queue is 100 percent full and then begin dropping packets indiscriminately. When the queue dips below 100 percent full, packets stop dropping.
The default drop behavior is shown in the show class-of-service
drop-profile
command.
user@host> show class-of-service drop-profile Drop profile: <default-drop-profile>, Type: discrete, Index: 1 Fill level Drop probability 100 100
To create meanings for the various loss priorities, you must configure custom drop profiles. For example, you might define the low loss priority to mean a 10 percent drop probability when the queue is 75 percent full and a 40 percent drop probability when the queue fill level is 95 percent. You might define the high loss priority to mean a 50 percent drop probability when the fill level is 25 percent and a 90 percent drop probability when the fill level is 50 percent. Custom drop profiles are not included in this example, but are mentioned here for clarity because classifiers assign loss priorities. It is important to understand that these assignments are meaningless until you create drop profiles.
The default classifier operation is shown in Figure 1. The figure shows two IPv4 packets entering an interface and being classified according to the DSCP code points in the packet headers.

Classifiers are described in more detail in the following Juniper Networks Learning Byte video.
Video 1: Class of Service Basics, Part 2: Classification Learn...
Topology
Figure 2 shows the sample network.

It is important to apply your class-of-service configuration across the topology, instead of applying it to a single device. Furthermore, even though classification takes effect on incoming interfaces, you should apply BA classifiers to all core and core-facing interfaces. This is because a single interface can be either incoming or outgoing, depending on the direction of the traffic. For example, as traffic flows from Host 1 to Host 2, the incoming interfaces are ge-1/0/7 on Device R2 and ge-2/0/6 on Device R3. As traffic flows in the other direction, from Host 2 to Host R1, the incoming interfaces are ge-1/0/3 on Device R2 and ge-1/0/7 on Device R1.
The BA classifier is not applied to ge-1/0/1 on Device R1 or ge-2/0/5 on Device R3, because these interfaces are not core facing. Generally, at the edge-facing interfaces, you would use a multifield classifier, not a BA classifier.
CLI Quick Configuration shows the configuration for all of the Juniper Networks devices in Figure 2. The section Step-by-Step Procedure describes the steps on Device R2.
Configuration
Procedure
CLI Quick Configuration
To quickly
configure this example, copy the following commands, paste them into
a text file, remove any line breaks, change any details necessary
to match your network configuration, and then copy and paste the commands
into the CLI at the [edit]
hierarchy level.
Device R1
set interfaces ge-1/0/1 unit 0 family inet address 172.16.50.2/30 set interfaces ge-1/0/7 unit 0 family inet address 10.30.0.1/30 set class-of-service interfaces ge-1/0/7 unit 0 classifiers dscp default
Device R2
set interfaces ge-1/0/3 unit 0 family inet address 10.40.0.1/30 set interfaces ge-1/0/7 unit 0 family inet address 10.30.0.2/30 set class-of-service interfaces ge-1/0/3 unit 0 classifiers dscp default set class-of-service interfaces ge-1/0/7 unit 0 classifiers dscp default
Device R3
set interfaces ge-2/0/5 unit 0 family inet address 172.16.70.2/30 set interfaces ge-2/0/6 unit 0 family inet address 10.40.0.2/30 set class-of-service interfaces ge-2/0/6 unit 0 classifiers dscp default
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To enable the default DSCP behavior aggregate classifier:
Configure the device interfaces.
content_copy zoom_out_map[edit interfaces] user@R2# set ge-1/0/3 unit 0 family inet address 10.40.0.1/30 user@R2# set ge-1/0/7 unit 0 family inet address 10.30.0.2/30
Enable the default DSCP classifier on the interfaces.
content_copy zoom_out_map[edit class-of-service interfaces] user@R2# set ge-1/0/3 unit 0 classifiers dscp default user@R2# set ge-1/0/7 unit 0 classifiers dscp default
Results
From configuration mode, confirm your configuration
by entering the show interfaces
and show class-of-service
commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
user@R2# show interfaces ge-1/0/3 { unit 0 { family inet { address 10.40.0.1/30; } } } ge-1/0/7 { unit 0 { family inet { address 10.30.0.2/30; } } }
user@R2# show class-or-service interfaces { ge-1/0/3 { unit 0 { classifiers { dscp default; } } } ge-1/0/7 { unit 0 { classifiers { dscp default; } } } }
If you are done configuring the device, enter commit
from configuration mode.
Verification
Confirm that the configuration is working properly.
Verifying Behavior Aggregate Classifiers
Purpose
Verify that the default behavior aggregate classifier is enabled on the device interfaces. Keep in mind that although the classifier operates on incoming packets, you view the resulting queue assignment on the outgoing interface.
Action
Clear the interface statistics on Device R2.
content_copy zoom_out_mapuser@R2> clear interface statistics ge-1/0/3
Using extended ping from Device R1 or a packet generator running on a host or server, send packets with the code point set to 001010.
Both methods are shown here. The packet generator used is hping.
When you are using extended ping to set the DSCP code points in the IPv4 packet header, the type-of-service (ToS) decimal value (in this case, 40) is required in the
tos
option of theping
command.When you are using hping to set the DSCP code points in the IPv4 packet header, the ToS hex value (in this case, 28) is required in the
--tos
option of thehping
command.
If your binary-to-hex or binary-to-decimal conversion skills are rusty, you can use an online calculator, such as http://www.mathsisfun.com/binary-decimal-hexadecimal-converter.html .
Note:When you convert a binary DSCP code point value, be sure to add two extra zeros at the end. So instead of 001010, use 00101000. These 0 values (the 7th and 8th bits) are reserved and ignored, but if you do not include them in the conversion, your hex and decimal values will be incorrect.
Extended Ping Sent from Device R1
content_copy zoom_out_mapuser@R1> ping 172.16.70.1 tos 40 rapid count 25 PING 172.16.70.1 (172.16.70.1): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.16.70.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.430/0.477/0.847/0.079 ms
hping Sent from Host 1
content_copy zoom_out_maproot@host1> hping 172.16.70.1 --tos 28 -c 25 HPING 172.16.70.1 (eth1 172.16.70.1): NO FLAGS are set, 40 headers + 0 data bytes len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=0 win=0 rtt=0.3 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=1 win=0 rtt=0.6 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=2 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=3 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=4 win=0 rtt=0.6 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=5 win=0 rtt=0.3 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=6 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=7 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=8 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=9 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=10 win=0 rtt=0.5 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=11 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=12 win=0 rtt=0.5 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=13 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=14 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=15 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=16 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=17 win=0 rtt=0.5 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=18 win=0 rtt=0.5 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=19 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=20 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=21 win=0 rtt=0.5 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=22 win=0 rtt=0.4 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=23 win=0 rtt=0.5 ms len=46 ip=172.16.70.1 ttl=61 DF id=0 sport=0 flags=RA seq=24 win=0 rtt=0.4 ms
On Device R2, verify that queue 2 is incrementing.
Code point 001010 is associated with assured-forwarding, which uses queue 2 by default.
content_copy zoom_out_mapuser@R2> show interfaces extensive ge-1/0/3 | find "queue counters" Queue counters: Queued packets Transmitted packets Dropped packets 0 0 0 0 1 0 0 0 2 50 25 0 3 3 3 0 Queue number: Mapped forwarding classes 0 best-effort 1 expedited-forwarding 2 assured-forwarding 3 network-control
Meaning
The output shows that queue 2 has incremented by 50 packets after sending 50 packets through the router.