Professional Documents
Culture Documents
Cos in Ex Switches PDF
Cos in Ex Switches PDF
Cos in Ex Switches PDF
Although Juniper Networks has attempted to provide accurate information in this guide, Juniper Networks does not warrant or guarantee the accuracy of the
information provided herein. Third party product descriptions and related technical details provided in this document are for information purposes only and such
products are not supported by Juniper Networks. All information provided in this guide is provided as is, with all faults, and without warranty of any kind, either
expressed or implied or statutory. Juniper Networks and its suppliers hereby disclaim all warranties related to this guide and the information contained herein,
whether expressed or implied of statutory including, without limitation, those of merchantability, fitness for a particular purpose and noninfringement, or arising
from a course of dealing, usage, or trade practice.
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Design Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Why CoS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
CoS vs. Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Network Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Software Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
CoS on EX Series Switches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
EX2200/EX3200/EX4200 Switches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
EX8200 Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Deploying CoS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Trust and Untrust Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Edge Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Core Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Deployment Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Unicast Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1 Configuring Edge Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.0 Forwarding class configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.1 BA classifier table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.2 Multifield classifier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.3 Drop profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.4 Schedulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.5 Scheduler map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.6 Rewrite rule table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.7 Binding CoS to interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.8 Binding multifield classifier to interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Configuring core devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.0 Drop profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 Schedulers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.2 Scheduler map profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.3 Binding CoS to interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Unicast/Multicast Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Table of Figures
Figure 1: EX Series CoS stages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 2: EX2200/EX3200/EX4200 PFE buffer allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figure 3: CoS boundaries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 4: Campus LAN topology.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 5: Unicast/multicast topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Introduction
Class of service (CoS) is a complex and challenging feature to deploy in any network. Questions such as how many queues to
configure or how much buffer or bandwidth should be allocated need to be answered when deploying CoS, especially across
a campus network. This implementation guide will describe where and how to configure CoS in a campus LAN network with
Juniper Networks EX Series Ethernet Switches.
Scope
This document will focus solely on deploying CoS with EX Series switches (the Juniper Networks EX2200 line, EX3200 line,
EX4200 line in a standalone or Virtual Chassis configuration, and the EX8200 line of Ethernet switches) for both unicast
and multicast in a campus LAN two-tier network. In addition, this document will cover the configuration for access and core
switches, providing tips and caveats where applicable.
The target audiences for this document are Juniper systems engineers (SEs), professional services organizations, and
customers, although every effort has been made to make this document appeal to the widest possible Juniper audience. It
is assumed that the reader is familiar with Juniper Networks Junos operating system and its command-line interface (CLI),
with general switching terminology, and has a basic understanding of 802.1p and DiffServ code point (DSCP).
Design Considerations
Why CoS?
Before getting into the specifics, the first question that needs to be addressed is, Does CoS need to be enabled on my
network? Unfortunately, there is never a simple yes or no answer to this question as it depends on a number of factors. CoS
decisions shouldnt be based solely on reported packet drops on interfaces; decisions should also consider issues such as
end user Quality of Experience (QoE) and whether an application needs to meet certain service requirements. Other factors
to consider include whether end users are noticing application performance problems such as timeouts, long delays, or voice
or video quality issues like choppy or clipped transmissions and pixilated or constantly buffering video streams. When these
problems do occur, CoS is recommended as a potential solution.
QoE problems are not simply caused by insufficient bandwidth; instead, they are the culmination of multiple issues such as
network design, architecture of the box, and traffic patterns. More often than not, problems are the result of contention on
ports with a many-to-one relationship, speed differences, or packets getting stuck behind other application packets.
Network Architecture
Key advantages of deploying CoS with EX Series switches in a campus network are the common Junos OS across all EX
Series platforms, wire-rate performance for IPv4 and IPv6 unicast and multicast for all packet sizes, and high port densities.
The combination of wire-rate performance and high port counts allows the user to simplify the network by moving from a
three-tier to a two-tier architecture. Reducing the number of network layers translates into lower latency, as there are fewer
hops in the network. The network can even be simplified further with Virtual Chassis technology. However, this document
will not discuss campus architecture or designing networks with Virtual Chassis technology. For more information on campus
architecture, please refer to the Campus LAN Reference Architecture at www.juniper.net/us/en/local/pdf/referencearchitectures/8030005-en.pdf.
This document will focus on implementing CoS in a two-tier architecture irrespective of the Layer 3 boundary within the
campus network, provided the L3 boundary is either at the core or access layer. If a network is a three-tier network with EX
Series switches, then the same core configuration from the two-tier design can be applied to both core and aggregation
devices in the three-tier design.
Hardware Requirements
Although the diagrams may not call out the specific EX Series switch platforms, one can infer that the EX2200, EX3200, or
EX4200 are deployed at the access layer, with the EX8200 line deployed at the core layer.
Software Requirements
All of the CoS configuration and features are based as Junos OS 10.1 release for all platforms.
Implementation
CoS on EX Series Switches
All CoS functionality is performed in hardware to ensure that there is no performance impact when the CoS features are
configured. The entire EX Series switch family supports the following functionality:
Forwarding Classes: Synonymous with traffic class group.
Classifying: Differentiating traffic based on L2, L3, or L4 information. Junos OS supports three different methods of traffic
classification:
-- Fixed configuration classification: Port-based classification where all traffic is placed in a single forwarding class with a
packet loss priority (PLP) of low.
-- Behavioral aggregate (BA) classifier: Classifying traffic based on 802.1p and DSCP values.
-- Multifield classifier: Using ingress firewall filters to classify traffic based on L2, L3, or L4 information. This can be applied
to either L2/L3 physical or logical interfaces, or VLANs, or both.
Traffic rate limiting: EX Series switches support two types of token-based rate limitingpolicing and shaping. Rate
limiters are based on actual packets (preamble and inter-frame gap are excluded).
-- Policing: Any packet that is above the specified rate will be dropped and is only supported at the ingress.
-- Shaping: Any packet that is above the specified rate will be buffered and is only supported at the egress.
Congestion Avoidance/Management: The ability to manage queues during congestion to prevent them from getting
unmanageable. Depending on the platform, EX Series switches support either weighted tail drop (WTD) or weighted
random early detection (WRED).
-- WTD: When the queue reaches a certain buffer capacity (fill level), packets marked with a PLP of high will be
prevented from entering into the queue and will be discarded, hence weighted tail drop. By default, the level is 100% of
the queue. WTD is only supported on the EX2200, EX3200, and EX4200 switches.
-- WRED: With WRED, random packets with a PLP of low or high are gradually dropped once the queue reaches a
certain buffer capacity (fill level). There are two WRED implementations that Junos OS supportssegmented and
interpolated. From a high level, segmented is a stair-step like drop profile, whereas interpolated is a smother (curve)
drop profile. Regardless of implementation, a profile is a graph where the x axis represents current buffer utilization (fill
level) and the y axis is the drop probability. Depending on where the traffic is plotted against the graph, the packet will
either be dropped or buffered. For more information on WRED, please refer to the technical documentation at http://
www.juniper.net/customers/support/. WRED is only supported on the EX8200 line of Ethernet switches.
Scheduling: Scheduling determines how the traffic class (queue) is being serviced, which directly correlates with the
bandwidth allocation. EX Series switches support strict-priority (SP) queuing with shaped deficit weighted round-robin
(SDWRR).
Multiple SP queues are supported on any given interface. The strict-priority queues are always the highest numbered, and
service is based on queue numbersfor example, queue 7 will have a higher priority than queue 6.
Queues that are not SP are SDWRR. SDWRR services queues sequentially, starting with the highest numbered queues
first. These queues share the bandwidth among themselves according to the configured weights. The weights are
configured as a rate or percentage (note that both will be converted into bandwidth ratios). The weight ratio is the
guaranteed minimum bandwidth, but is not limited to that bandwidth.
Remarking: Remarking involves changing the QoS priority markings (802.1p or DSCP) for the next hop to act on.
-- Interface specific rewrite: Binding a rewrite rule to the interface.
-- Multifield remarking: Using egress firewall filters to remark specific traffic bases. This can only be applied to an L2/L3
physical or logical interface. Multifield remarking firewall filter cannot be bound to a VLAN.
CLASSIFICATION
CONGESTION
MANAGEMENT
POLICING
SCHEDULING
SHAPING
REMARKING
EX2200
802.1p/DSCP
Single-rate
two-color
WTD
SP+SDWRR
802.1p*
EX3200/EX4200
802.1p/DSCP
Single-rate
two-color
WTD
SP+SDWRR
802.1p/DSCP
EX8200
802.1p/DSCP
Single-rate
two-color
WRED
SP+SDWRR
802.1p/DSCP
* Plans for enhancement for feature parity between platforms. Please contact local representative for timeline.
Note: On the EX2200, remarking is enabled by default for routed packets. Interface-specific and multifield remarking
capabilities are planned for a future release. Please contact your local representative for a timeline.
Not only are QoS features consistent on EX Series switches, but the CoS packet flow is consistent as well. Figure 1 shows the
packet flow; again, the consistency allows for easy deployment with EX Series switches.
Classifying
Policing
Queuing
Scheduling
Shaping
Remarking
NO. OF
QUEUES PER
PORT
EX2200
1.5 MB per
Packet
Forwarding
Engine
(PFE)
1,000*
16
1 per
802.1p/
DSCP*
1 per
802.1p**
32
EX3200/
EX4200
3 MB per
PFE
1,000*
16
Limited
by ternary
content
addressable
memory
(TCAM)
Limited by
TCAM
32
EX8200
1 GB per
PFE
7,000*
16
Limited by
TCAM
Limited by
TCAM
64
BUFFER
POLICERS/
SHAPERS
FORWARDING
CLASSES
NO. OF
SCHEDULER
MAPS
NO. OF
CLASSIFIER
TABLES
NO. OF
REWRITE
TABLES
NO. OF DROP
PROFILES
* Port shapers are limited by number of available ports. The number of scheduler maps limits the number of queue shapers.
** Plans for enhancement for feature parity between platforms. Please contact local representative for timeline.
Buffering
All EX Series switches support up to eight queues per port. The number of available queues gives network engineers the ability
to impose better traffic segmentation. Applications can be segregated into separate queues and no longer have to compete
with one another for buffer space and bandwidth. With separate QoS queues, Application A is now guaranteed a minimum
amount of bandwidth and is no longer subjected to long waits in the queue behind packets from other applications.
EX2200/EX3200/EX4200 Switches
Buffer sizes vary between platforms; for the buffer size on EX2200, EX3200, and EX4200 switches, all of which share the
same buffering architecture, please refer to Table 2. The buffer is divided between shared ingress, shared buffer pool, and
per-port dedicated buffers.
Egress Buffers
Shared Pool
Port X queue 7
Port X queue 6
Port X queue 5
Port 2 queue 2
Port 2 queue 1
Port 2 queue 0
Port 1 queue 7
Port 1 queue 6
Port 1 queue 5
Port 1 queue 4
Port 1 queue 3
Port 1 queue 2
Port
Port 11 queue
queue 0
1
Port 1 queue 0
Ingress
Buffers
[edit class-of-service]
schedulers {
scheduler-name {
buffer-size exact;
}
Shared buffer slider: The shared buffer slider gives users the flexibility to increase/decrease the per-port and shared
buffers. The default value is 100 percent. If the value is less than 100, then the shared pool is reduced and the remaining
buffers are redistributed evenly across the dedicated port buffers.
[edit class-of-service]
shared-buffer percent percent;
EX8200 Line
On the EX8200 line, there are buffers for the fabric and the egress port. The fabric interface has multiple ingress and egress
queues, which is similar to Virtual Output Queueing (VOQ). This helps ensure that a congested egress queue/port does
not affect other ports sending traffic, otherwise known as Head-of-Line Blocking (HOLB), and prevents the problem from
spreading while maximizing fabric throughput.
In addition to multiple supported fabric queues, the EX8200 line allows users to specify a fabric priority for the forwarding
class (either low or high). Latency-sensitive traffic should be mapped to the high priority fabric queue. The queue size and
transmit rate are optimized by the system and are not user configurable. However, a drop profile can be configured for the
high and low fabric queues for congestion management.
Because of the deep buffers on the EX8200, there is no shared buffer pool concept as with the other EX Series platforms.
While the buffer size of the queue can be allocated through configuration, there is some buffer elasticity between queues
within a port to allow a given queue to borrow some unused buffers from other queues.
Deploying CoS
CoS is only effective if it is deployed end-to-end. It serves no useful purpose if it is only configured in one or a few sections
of the network, and needs to be configured at every hop along the way from the source to the destination. In the next few
sections, this document will discuss a couple of CoS deployments for unicast and a mixture of unicast and multicast. This
document will also cover the why, where, and how for both access and core switches.
The majority of the CoS configuration is done under the class-of-service stanza of the Junos OS CLI. For specific CLI syntax or
additional sample configurations, please refer to the EX Series technical documents at www.juniper.net/customers/support/.
Untrusted Domain
Trusted
Internet
MPLS
VPN
Untrusted Domain
Trusted Domain
It is recommended that some sort of congestion management capability be configured, as this helps prevent certain packets
from being buffered further or even dropped due to lack of buffer availability.
The EX Series switches support SP and SDWRR. While there is no limit to how many SP queues there can be, typically no
more than two are neededone for control traffic and the other for latency-sensitive and jitter-sensitive traffic such as voice.
All other traffic can be serviced as SDWRR, which ensures fair bandwidth distribution between queues while reducing jitter
and offering lower maximum latency.
Lastly, remarking allows the next switch to act on the QoS marking that was established from the edge devices. Remarking
only needs to be applied on the edge links that are connecting to the core.
Core Devices
All validation and compliance, such as rate limiting and remarking, is done at the edge. Therefore, the core devices should
just be switching traffic based on QoS marking. The following recommended QoS features should be enabled on the core
devices:
BA classifier
Congesting avoidance/management
Scheduling
Edge
CLASSIFICATION
Core
BA
CONGESTION
MANAGEMENT
SCHEDULING
RATE LIMITERS
REMARKING
Optional
Deployment Scenarios
Unicast Deployment
The campus network used for this scenario (see Figure 4) is mainly unicast with little to no multicast traffic. If multicast is
present, then it has little importance and can be treated as best-effort traffic. The majority of traffic is north-south, where the
data center is located at a remote site. Because the EX Series switches can support up to eight queues per port, each traffic
class is in a separate queue (see Table 5).
10
Untrusted Domain
EX4200
Virtual Chassis
Trusted
MPLS
VPN
Internet
Untrusted Domain
Trusted Domain
NO. OF
FORWARDING
CLASSES
Edge
Core
CLASSIFICATION
CONGESTION
MANAGEMENT
SCHEDULING
RATE LIMITERS
REMARKING
Note: The following table will be used for the unicast deployment scenario. These parameters may not meet all
requirements and could require modifications.
11
QUEUE
NUMBER
BINARY
QUEUE
PRIORITY
BUFFER SIZE
(%)
TRANSMIT
RATE (%)
Control
NC1/CS6,
NC2/CS7
56, 48
SP
Expedited
forwarding
(EF)
46
SP
AF21
18
SDWRR
PER-HOP
BEHAVIOR
(PHB)
Voice
Business app
RATE LIMITING
ACCESS
PORTS
NETWORK
PORTS
N/A
1%
5%
N/A
1%
5%
40
40
N/A
N/A
Server bulk
AF11
10
SDWRR
20
20
N/A
N/A
Best effort
Best effort
SDWRR
Remainder
Remainder
N/A
N/A
The majority of the configuration will be done under the class-of-service stanza with the exception of the multifield classifier.
Since the multifield classifier uses firewall filters to match on L2, L3, or L4 information, its configuration is done outside of the
class-of-service stanza.
12
13
1.1.4 Schedulers
Buffer size, queue priority (SP or SDWRR), transmit rate, drop profile, and queue shaper are all defined within the scheduler
profile.
For queues configured as SP (priority high), it is recommended that a small percentage of buffers be reserved. Transmit rate
is not permitted because this queue will always be serviced when there is a packet in the queue. Due to the intrinsic behavior
of SP queues, they can potentially consume all of the bandwidth and starve the other queues. Therefore, it is recommended
that shaping be configured to prevent such an event. For more information on policing and shaping configurations, please
refer to the EX Series switch technical documentation at www.juniper.net/customers/support/.
Voice traffic should not be buffered over a long period of time since that will increase latency and jitter; instead the goal is to
drop the packet. Therefore the buffer size for the voice queue should be configured with an exact keyword, which prevents
any excess packets from being buffered into the shared pool, limiting the available buffer to what is allocated.
For other queues configured as SDWRR (priority low), buffer sizes can vary based on application load and requirements. It
is common to match the values for both transmit rate and buffer size. An alternative method of calculating the transmit
rate percentage is subtracting the buffer size percentage from 100. The logic is similar to the SPif the queue has a higher
transmit rate, it will require fewer buffers; if the queue has a lower transmit rate, then it will require more buffers.
Note: Juniper recommends configuring SDWRR as a percentage, which provides an easier bandwidth ratio conversion.
14
}
server-sched {
transmit-rate percent 30;
buffer-size percent 30;
priority low;
}
be-sched {
transmit-rate remainder;
buffer-size remainder;
priority low;
}
15
CLASSIFIER
SCHEDULER MAP
User port
Multifield
BA
Network port
REMARKING
The example shown below assumes that 1GbE ports are user facing, and the 10GbE and link aggregation group (LAG) ports
are networking ports.
16
scheduler-map network-port-sched;
unit * {
classifiers {
dscp dscp_ba;
}
rewrite-rules {
dscp rewrite-dscp;
}
}
17
18
Unicast/Multicast Deployment
In this scenario, the campus LAN has a mix of unicast and multicast traffic. Assume that users are sending voice and data
traffic and receiving voice, data, and video. There are two types of video being received, one that is latency sensitive (i.e., realtime interactive) and one that is not latency sensitive (i.e., multimedia streaming).
19
Untrusted Domain
EX4200
Virtual Chassis
Trusted
Untrusted
MPLS
VPN
Internet
Untrusted Domain
Trusted Domain
NO. OF
FORWARDING
CLASSES
Edge
Core
CLASSIFICATION
CONGESTION
MANAGEMENT
SCHEDULING
RATE LIMITERS
REMARKING
Note: The following table will be used for the unicast and multicast deployment scenarios. These parameters may not meet
all requirements and could require modification.
20
QUEUE
NUMBER
Control
Multicast control
Voice
PHB
BINARY
QUEUE
PRIORITY
BUFFER SIZE
(%)
TRANSMIT
RATE (%)
NC1/CS6,
NC2/CS7
56, 48
SP
EF
46
SP
RATE LIMITER
ACCESS
PORTS
NETWORK
PORTS
N/A
1%
5%
N/A
1%
5%
Video live
CS4
32
SDWRR
10
10
N/A
N/A
Video streaming
AF31
26
SDWRR
10
10
N/A
N/A
Business app
AF21
18
SDWRR
40
40
N/A
N/A
Server bulk
AF11
10
SDWRR
20
20
N/A
N/A
Multicast best
effort *
N/A
N/A
SDWRR
N/A
N/A
Best effort
Best effort
SDWRR
Remainder
Remainder
N/A
N/A
* This is only specific to the EX8200 line; see section 2.1.0 for further details. The access devices do not require multicast best effort forwarding class
to be configured.
From this point on, this document will focus on features not covered in the previous sections. If a specific section is not
mentioned, it can be safely assumed that the configuration is the same as described in the previous section, with the
exception of the CoS parameters which are based on Table 7. Although the drop profile for the edge or core devices were
not outlined in Table 7, the drop profiles created in Unicast Deployment, sections 1.1.3 and 1.2.0 respectively, can be used as a
good reference point.
For uninterrupted unicast/multicast core CoS configuration, please refer to Appendix 2.
21
Multicast configuration only pertains to the EX8200 switches and is global. This means that all EX8200-PFEs will inherit the
configuration.
class-of-service {
multi-destination {
scheduler-map scheduler-map-name;
family {
ethernet {
broadcast queue-number;
}
inet {
classifier {
dscp classifier-name;
inet-precedence classifier-name;
}
}
}
}
}
The scheduler map allows the user to bind the scheduler-map profile for the multicast queue.
The ethernet broadcast allows the user to specify the queue (forwarding class) for unknown unicast, broadcast, and
multicast traffic that is bridged by the device.
The inet classifier allows the user to bind BA classifier for multicast traffic that is routed by the device. Only one type of
classifier is allowed, either DSCP or inet-precedence.
22
2.1.4 Binding the classifier and scheduler map, and moving the default queue for broadcast, L2 multicast, and
unknown unicast to a different queue
Juniper recommends that unicast and multicast be kept in separate queues. If there is a broadcast or unknown unicast storm,
then unicast traffic will not be affected.
multi-destination {
scheduler-map mcast-sched;
family {
ethernet {
broadcast mcast-be;
}
inet {
classifier {
dscp mcast_ba;
}
}
}
}
23
24
Although not shown, the next step is binding the network-port-sched scheduler map profile to the appropriate interfaces, as
well as any BA classifier for the unicast traffic.
25
CoS Validation
The show class-of-service sub-command can be used to validate CoS configurations from the Junos OS operational mode.
Some of the available commands include:
classifier
drop-profile
interface
rewrite-rule
scheduler-map
point
The show class-of-service interface interface-name command provides a good summary of CoS configuration for the
port.
Use show interface queue interface-name to view queue statistics and validate that traffic is being forwarded out of the
configured queue.
The following command is only applicable to EX8200 line switches. To view CoS statistics for multicast traffic, use the
following command:
The PFE numbering starts at zero for the lowest slot number and proceeds from left to right. On the EX8200-8XS 10GbE
line card, there are four PFEs with two 10GbE ports per PFE. On the EX8200-48T/F line cards, there are two PFEs with 24
GbE ports per PFE.
Summary
Juniper Networks offers a pragmatic approach for simplifying the campus network. Running the Junos operating system on
EX Series Ethernet Switches provides consistent management and operations. In addition, the EX Series switches nonblocking architecture offers wire-rate performance for both IPv4 and IPv6 (unicast and multicast) traffic. This simplifies the
network by reducing the campus LAN architecture from three to two tiers. Along with consistent and feature rich CoS, the EX
Series platforms can support the high-performance enterprise and ensure the prioritization of business critical applications
during times of traffic congestion, as well as meet the latency and jitter requirements of specialized types of traffic.
References
RFC4594, Guidelines for DiffServ Service Classes, August 2006
RFC 3246, An Expedited Forwarding PHB (Per-Hop Behavior), March 2002
26
27
}
}
drop-profiles {
80-full {
fill-level 80;
}
}
forwarding-classes {
class control queue-num 7;
class voice queue-num 5;
class business-app queue-num 3;
class server-bulk queue-num 1;
class best-effort queue-num 0;
}
interfaces {
ge-* {
scheduler-map access-port-sched;
}
ae* {
scheduler-map network-port-sched;
unit 0 {
classifiers {
dscp dscp_ba;
}
rewrite-rules {
dscp rewrite-dscp;
}
}
}
}
rewrite-rules {
dscp rewrite-dscp {
forwarding-class control {
loss-priority low code-point nc1;
loss-priority high code-point nc2;
}
forwarding-class voice {
loss-priority low code-point ef;
}
forwarding-class business-app {
loss-priority low code-point af21;
}
forwarding-class server-bulk {
loss-priority low code-point af11;
}
forwarding-class best-effort {
loss-priority low code-point be;
}
}
}
28
scheduler-maps {
network-port-sched {
forwarding-class control scheduler control-network-sched;
forwarding-class voice scheduler voice-network-sched;
forwarding-class business-app scheduler business-sched;
forwarding-class server-bulk scheduler server-sched;
forwarding-class best-effort scheduler be-sched;
}
access-port-sched {
forwarding-class control scheduler control-user-sched;
forwarding-class voice scheduler voice-user-sched;
forwarding-class business-app scheduler business-sched;
forwarding-class server-bulk scheduler server-sched;
forwarding-class best-effort scheduler be-sched;
}
}
schedulers {
control-network-sched {
shaping-rate percent 5;
buffer-size percent 5;
priority strict-high;
drop-profile-map loss-priority high protocol any drop-profile 80-full;
}
control-user-sched {
shaping-rate percent 1;
buffer-size percent 5;
priority strict-high;
drop-profile-map loss-priority high protocol any drop-profile 80-full;
}
voice-network-sched {
shaping-rate percent 5;
buffer-size percent 5 exact;
priority strict-high;
}
voice-user-sched {
shaping-rate percent 1;
buffer-size percent 5 exact;
priority strict-high;
}
business-sched {
transmit-rate percent 60;
buffer-size percent 60;
priority low;
}
server-sched {
transmit-rate percent 30;
buffer-size percent 30;
priority low;
}
be-sched {
transmit-rate remainder;
buffer-size remainder;
priority low;
}
}
user@edge-switch# show vlans
default {
vlan-id 1;
29
}
user {
vlan-id 100;
input mf-cos-classifier;
}
}
voice {
vlan-id 200;
filter {
input mf-cos-classifier;
}
}
30
31
network-port-sched {
forwarding-class
forwarding-class
forwarding-class
forwarding-class
}
}
schedulers {
control-sched {
buffer-size percent 5;
priority strict-high;
drop-profile-map loss-priority high protocol any drop-profile WRED-1;
}
voice-sched {
buffer-size percent 5;
priority strict-high;
}
business-sched {
transmit-rate percent 60;
buffer-size percent 60;
priority low;
}
server-sched {
transmit-rate percent 30;
buffer-size percent 30;
priority low;
}
be-sched {
transmit-rate remainder;
buffer-size remainder;
priority low;
}
}
32
33
dscp dscp_ba;
}
}
xe-* {
scheduler-map network-port-sched;
unit 0 {
classifiers {
dscp dscp_ba;
}
}
}
ae* {
scheduler-map network-port-sched;
unit 0 {
classifiers {
dscp dscp_ba;
}
}
}
}
scheduler-maps {
network-port-sched {
forwarding-class control scheduler control-sched;
forwarding-class voice scheduler voice-sched;
forwarding-class video-live scheduler video-sched;
forwarding-class video-streaming scheduler streaming-sched;
forwarding-class business-app scheduler business-sched;
forwarding-class server-bulk scheduler server-sched;
forwarding-class mcast-be scheduler mcast-sched;
forwarding-class best-effort scheduler be-sched;
}
mcast-sched {
forwarding-class mcast-control scheduler mcast-control-sched;
forwarding-class video-live scheduler mcast-video-sched;
forwarding-class video-streaming scheduler mcast-streaming-sched;
forwarding-class mcast-be scheduler mcast-be-sched;
}
}
schedulers {
control-sched {
buffer-size percent 5;
priority strict-high;
drop-profile-map loss-priority high protocol any drop-profile WRED-1;
}
voice-sched {
buffer-size percent 5;
priority strict-high;
}
video-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority low;
}
streaming-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority low;
34
}
business-sched {
transmit-rate percent 40;
buffer-size percent 40;
priority low;
}
server-sched {
transmit-rate percent 20;
buffer-size percent 20;
priority low;
}
mcast-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority low;
}
be-sched {
transmit-rate remainder;
buffer-size remainder;
priority low;
}
mcast-control-sched {
buffer-size percent 10;
}
mcast-video-sched {
buffer-size percent 35;
}
mcast-streaming-sched {
buffer-size percent 35;
}
mcast-be-sched {
buffer-size percent 20;
}
}
multi-destination {
scheduler-map mcast-sched;
family {
ethernet {
broadcast mcast-be;
}
inet {
classifier {
dscp mcast_ba;
}
}
}
}
35
APAC Headquarters
EMEA Headquarters
representative at 1-866-298-6428 or
Phone: 35.31.8903.600
or 408.745.2000
Phone: 852.2332.3636
Fax: 408.745.2100
Fax: 852.2574.7803
Fax: 35.31.8903.601
authorized reseller.
www.juniper.net
Copyright 2010 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and
ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service
marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no
responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise
revise this publication without notice.
8010073-001-EN
36
June 2010