Posted by JunOS QoS configuration is flexible, albeit a little tricky to understand. It has a few key components which I shall list and then explain. There’s other less common things which are possible, I will not try to explain these here. This is largely based around SRX devices but it should be mostly applicable to other devices such as EX, MX and J Series:
Key Components
- Interface Egress Queues – When a physical interface tries to send more traffic than its bandwidth permits, packets are queued in one of a few different numbered queues
- Interface Bandwidth Definition – You should manually define the bandwidth of an interface if it is lower than the line speed. For example, a 1gbit interface connected to a 200mbit fibre ethernet line needs to be defined as being 200mbit else it will assume 1gbit and QoS will not work
- Forwarding Classes – These effectively assign a name to a numbered queue, for example assured-forwarding
- Assignment of traffic to a forwarding class – This can be done in a number of ways:
- Classifiers – These observe DSCP, Inet Precedence or other marker types to assign ingress traffic to forwarding classes
- Firewall Rules – Ingress traffic can be matched with firewall rules and assigned to forwarding classes
- Drop Profiles – A drop profile defines the probability of packets being dropped when a queue reaches a certain size
- Schedulers – These define how differently queued egress traffic is prioritized
- Scheduler Maps – These link forwarding classes to schedulers
Interface Egress Queues
When a physical interface tries to send more traffic than its bandwidth permits, packets are queued in one of a few different numbered queues. You can see queues in the “extensive” interface output.
Physical interface: pt-1/0/0, Enabled, Physical link is Up
Egress queues: 8 supported, 4 in use
Queue counters: Queued packets Transmitted packets Dropped packets
0 best-effort 1024518 1024201 317
1 expedited-fo 607 607 0
2 assured-forw 7775 7775 0
3 network-cont 7948 7948 0
You can see a few things here:
- 8 queues are supported but only 4 are in use
- Queues have been assigned named forwarding classes
- The number of packets that have passed through each queue
- The number of packets which have been dropped from each queue
Interface Bandwidth Definition
If your egress interface has less bandwidth than the actual interface speed, for example you have 1gbit interface connected to a 200mbit Ethernet circuit, you need to specify the bandwidth of the Interface. The configuration for this is as follows:
reth1 {
description "Internet Connection";
unit 0 {
/* This is the available bandwidth of this connection, minus 10% */
bandwidth 90m;
}
}
}
It is suggested that you set the bandwidth to about 90% of the ISP stated speed. E.g. for a “200mbit fibre ethernet line”, set it to 180m. Setting it too low isn’t going to police your speed – you will still get maximum throughput. Setting it too high will try to allocate too high a minimum bandwidth to each queue and you’ll start to experience issues.
Forwarding Classes
A forwarding class is mapped to a numbered queue. Traffic is assigned to forwarding classes and thus into the right queues. JunOS comes with a default configuration which is suitable for many implementations – for example VOIP prioritization on a small to medium sized office network.
Forwarding class ID Queue Policing priority SPU priority
best-effort 0 0 normal low
expedited-forwarding 1 1 normal low
assured-forwarding 2 2 normal low
network-control 3 3 normal low
If you want to configure more, you can consult the Juniper documentation.
Assignment of Traffic to a Forwarding Class
This can be done in a number of ways. Here I shall cover 2 different ways:
Classifiers
These observe DSCP, Inet Precedence or other marker types to assign ingress traffic to forwarding classes. JunOS comes with a default classifier for each type of classification (DSCP, MPLS, Inet Precedence, etc.). On a private network which you control, this is my preferred way of doing it. You should mark the packets as close to the source as possible. VOIP phones will usually mark packets themselves. Other stuff may need to be marked on switches or other routers.
Here’s a (very) short excerpt of the default DSCP classifier on a branch SRX:
Classifier: dscp-default, Code point type: dscp, Index: 7
Code point Forwarding class Loss priority
000000 best-effort low
001010 assured-forwarding low
101110 expedited-forwarding low
101111 best-effort low
110000 network-control low
Have a look at the default and see how it suits you. You may want to tweak it a little. You can extend default classes and change only a few things, without the need to redefine the whole lot. For VOIP, you may want to assign AF31 (011010) to assured-forwarding. You also need to assign the classifier to your ingress interface in order to classify the traffic as it comes in. Here’s how you do that:
classifiers {
dscp voip {
import default;
forwarding-class assured-forwarding {
/* Default classfier is ok, except we also need AF31 */
loss-priority low code-points 011010;
}
}
}
interfaces {
/* This is the interface(s) behind which VOIP phones reside */
reth2 {
unit * {
classifiers {
dscp voip;
}
}
}
}
}
We “import” the default DSCP classifier and simply assign the AF31 codepoint to the assured-forwarding class.
Firewall Rules
You can use firewall rules to classify traffic into a forwarding class. The below example shows how to classify SIP traffic into the assured-forwarding class:
family inet {
filter VOICE {
term SIP {
from {
protocol udp;
source-port 5060;
destination-port 5060;
}
then {
forwarding-class assured-forwarding;
accept;
}
}
term ALL {
then accept;
}
}
}
}
interfaces {
interface fe-0/0/7 {
unit 0 {
family inet {
filter {
input VOICE;
}
address 1.2.3.4/24;
}
}
}
}
Drop Profiles
A drop profile defines the probability of packets being dropped when a queue reaches a certain size. Here is an example config:
drop-profiles {
low_drop {
fill-level 95 drop-probability 0;
fill-level 100 drop-probability 100;
}
med_drop {
fill-level 75 drop-probability 0;
fill-level 95 drop-probability 30;
}
high_drop {
fill-level 50 drop-probability 0;
fill-level 95 drop-probability 50;
}
}
}
For each drop profile, you define a number of fill levels and drop probabilities. For example in the high_drop profile above, when the queue becomes 95% full, 50% of packets will be dropped.
Schedulers
Schedulers are the key component in the whole setup. They are associated with forwarding classes and define how traffic in the given class is treated with respect to other traffic. They define a few key things:
- The minimum amount of bandwidth a class is to be given
- The minimum amount of buffer that a class is to be given
- The “priority” of that class, relative to other classes
- The drop profiles associated with each loss priority
It is important to understand how JunOS will prioritize traffic based on these settings. This is documented here. The summary is:
A given queue is “in profile” if it has not exceeded its allocated minimum bandwidth. Traffic will be sent from the highest priority queue which is “in profile”.
Here is an example scheduler configuration:
schedulers {
ef {
transmit-rate percent 15;
buffer-size percent 15;
priority high;
drop-profile-map loss-priority high protocol any drop-profile high_drop;
drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
drop-profile-map loss-priority low protocol any drop-profile low_drop;
}
nc {
transmit-rate percent 5;
buffer-size percent 5;
priority medium-high;
drop-profile-map loss-priority high protocol any drop-profile high_drop;
drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
drop-profile-map loss-priority low protocol any drop-profile low_drop;
}
be {
transmit-rate {
remainder;
}
buffer-size {
remainder;
}
priority low;
drop-profile-map loss-priority high protocol any drop-profile high_drop;
drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
drop-profile-map loss-priority low protocol any drop-profile low_drop;
}
af {
transmit-rate percent 50;
buffer-size percent 50;
priority medium-low;
drop-profile-map loss-priority high protocol any drop-profile high_drop;
drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
drop-profile-map loss-priority low protocol any drop-profile low_drop;
}
}
}
This defines a few different schedulers – one for each forwarding class. You will see below how schedulers are associated with forwarding classes. My classes are prioritized in the order ef, nc,. af, be. They are allocated a proportion of the interface’s bandwidth. It is important to note that this is the minimum bandwidth. For example, if there is only best-effort (be) traffic, it will get the full interface bandwidth.
It is important to tweak the percentages to reflect your own traffic. If, for example, you are a large call centre in which VOIP makes up 75% of your Internet traffic, then 15% for EF is probably a little low.
Scheduler Maps
Scheduler maps associate forwarding classes with schedulers. You then assign a scheduler map to an interface such that the schedulers are used for egress traffic on that interface. Below is a map that associates the 4 schedulers that I defined above with the 4 default forwarding classes on an SRX. This map is assigned to each egress interface where the scheduler(s) should be used.
scheduler-maps {
normal {
forwarding-class expedited-forwarding scheduler ef;
forwarding-class assured-forwarding scheduler af;
forwarding-class best-effort scheduler be;
forwarding-class network-control scheduler nc;
}
}
interfaces {
/* This is your egress interface */
reth1 {
scheduler-map normal;
}
}
}
Complete Configuration
A complete configuration to correctly apply QoS to VOIP traffic, assuming phones will set AF31 for signalling (SIP) and EF for media (RTP):
classifiers {
dscp voip {
import default;
forwarding-class assured-forwarding {
/* Default classfier is ok, except we also need AF31 */
loss-priority low code-points 011010;
}
}
}
drop-profiles {
low_drop {
fill-level 95 drop-probability 0;
fill-level 100 drop-probability 100;
}
med_drop {
fill-level 75 drop-probability 0;
fill-level 95 drop-probability 30;
}
high_drop {
fill-level 50 drop-probability 0;
fill-level 95 drop-probability 50;
}
}
interfaces {
/* This is the interface(s) through which VOIP phones access the Internet */
reth1 {
scheduler-map normal;
}
/* This is the interface(s) behind which VOIP phones reside */
reth2 {
/* This is the interface unit(s) through which VOIP phones access the Internet */
unit 123 {
classifiers {
dscp voip;
}
}
}
}
scheduler-maps {
normal {
forwarding-class expedited-forwarding scheduler ef;
forwarding-class assured-forwarding scheduler af;
forwarding-class best-effort scheduler be;
forwarding-class network-control scheduler nc;
}
}
schedulers {
ef {
transmit-rate percent 15;
buffer-size percent 15;
priority high;
drop-profile-map loss-priority high protocol any drop-profile high_drop;
drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
drop-profile-map loss-priority low protocol any drop-profile low_drop;
}
nc {
transmit-rate percent 5;
buffer-size percent 5;
priority medium-high;
drop-profile-map loss-priority high protocol any drop-profile high_drop;
drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
drop-profile-map loss-priority low protocol any drop-profile low_drop;
}
be {
transmit-rate {
remainder;
}
buffer-size {
remainder;
}
priority low;
drop-profile-map loss-priority high protocol any drop-profile high_drop;
drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
drop-profile-map loss-priority low protocol any drop-profile low_drop;
}
af {
transmit-rate percent 50;
buffer-size percent 50;
priority medium-low;
drop-profile-map loss-priority high protocol any drop-profile high_drop;
drop-profile-map loss-priority medium-high protocol any drop-profile med_drop;
drop-profile-map loss-priority medium-low protocol any drop-profile med_drop;
drop-profile-map loss-priority low protocol any drop-profile low_drop;
}
}
}
This was very helpful to me as a beginner. I was getting bogged down in the official Junos documentation and couldn’t quite “get” classifiers vs forwarding classes and schedules vs scheduler-maps.
Thanks for putting out a simple, straight forward tutorial with just enough detail and just enough balance between complexity and simplicity that I was able to get CoS in one go.
Well done!
This stuff is gold for helping me setup CoS on Juniper. I’m pretty dumb, are you still around?
I am still around. Do you have any specific questions?
Ooh great! I would love to run a scenario past you and get your thoughts if you’re willing? Could I email you or something? Or you can email: [REDACTED]
How would you know if this setup is working properly? This has been a great help, thank you.
If I have an internet connection going from an SRX340 to our ISPs modem and we’re paying for 500MB up/down, should we set the interface we’re on to be 500m?
bandwidth 450m;
Hi , i am seeing the bandwidth setting is “informational only” . so how come it limit the interface bandwidth?
root@SRX345-DALLAS-01# set interfaces reth0 unit 11 bandwidth ?
Possible completions:
Logical unit bandwidth (informational only)