In a previous video, we had a look at how class of service
fits together, and now we'll look at how to configure it.
It's quite easy, so don't find this intimidating at all.
We'll go through each line of config to set up some very basic class of service.
We'll start by looking at forwarding classes.
This is as well as most of the config we'll see
under the class of service hierarchy.
Defining the forwarding classes is just a matter of assigning a name
to a queue number, and the queue number itself isn't really that important.
You've just got to have unique queue numbers to assign to your names.
Traffic then needs to be classified.
If we are to take an action on it.
So when we classify traffic, we're assigning it based on some criteria
to a forwarding class.
These are configured under the class of service classifiers hierarchy.
A simple way to do this is with a 'BA' classifier, and remember
from the last video that looks at markings such as DSCP markings within the packet,
and we are indeed going to use DSCP markings here.
But there is other kinds you can use if you want.
The classifiers will map directly
to a particular forwarding class.
Each forwarding class has one or more loss
priority as well as a code point value.
So the code point value is the marking that's in the packet.
That's something like EF expedite forwarding or AF
or BE one of those sort of markings that you will have used before.
And we can use the name as we just talked about, or the binary value
The loss priority is how likely it is
for this packet to be dropped when there's times of congestion.
So if there is congestion, a higher
loss priority means a higher likelihood that that packet will be dropped.
The classifier needs to be applied to an interface.
This is still under the class of service hierarchy.
And when the packet arrives on the interface,
a classifier will look at the markings that are on it and they can
then use that to assign this packet to the forwarding class.
That was a BA classifier behavior aggregate.
It looks at markings.
Another type is a multi field classifier or MF classifier,
and it looks at other criteria,
which is great if we don't already have markings on our packets.
So multi field classifiers are configured in a firewall filter,
which is much the same as an ACL If you're familiar with other vendors, it
identifies interesting traffic and allows you to take an action on that traffic.
So I have a separate video and firewall filters,
if you want a bit of a catch up on how they work.
So we're creating a simple filter here called MF-Classifier.
The first term identifies HTTP traffic
coming from the 172.16.0.0 network.
It then puts it in the critical forwarding class.
We also need to accept this traffic so we don't filter the traffic out.
Remember, this is a firewall filter.
If we don't accept it, it will drop the traffic.
We can also add more terms to match more traffic if we wanted to,
and that would include
putting more types of traffic into different forwarding classes.
We're going to keep it quite simple here, not go too hard.
We do need a final term, though, to accept remaining traffic.
That's so anything that doesn't get matched
will also still be allowed through and not filtered out.
The firewall filter as normal just needs to be applied
to an interface and that needs to be on an input direction.
So classification happens as packets are received.
And note this is not under the class of service hierarchy.
This is directly on the actual interface configuration.
If we want to, we could use both types
of classifiers, the BA and the MF on the same device.
If we want to
So now we can move on to schedules.
And schedules are used to define how much time and resources we spend on each queue.
We can have many different schedulers defined
but at a minimum, there are two things we need to define here.
One is the transmit rate.
That's the amount of bandwidth that we want to reserve for this class.
And that can be a percentage of the interfaces available bandwidth.
Or it could be a fixed amount of bandwidth, say 10Mbps, 500Mbps, 1Gbps, whatever
we want to put there
and we also allocate the amount of buffer space
that is memory space that each queue can use.
We also have a scheduler-map,
and the scheduler-map links the scheduler to the forwarding class.
And this allows us to be flexible
so we can have different schedulers and different forwarding classes per interface
Now all this
is for nothing if we don't actually apply our configuration to an interface.
So schedulers are applied to packets on egress,
that is packets being sent out of the router.
And that's where we have the most control over our packets,
and the amount of bandwidth that is allocated.
We can't really do any scheduling on ingress packets.
You know why?
Well, we've already received them.
If the link is flooded, it's flooded well before those packets arrive
at our router. So there's very little we can do.
The damage is already done there. We control how good of a neighbor we are or
our router is, by sending or controlling
the sending of packets going out
So when packets are ready to be sent out,
Junos will look up the class of service config for this interface.
It will see the scheduler map
and it will apply the queuing and scheduling that we have just set up
Just to finish
off, just included some show commands here that you can use
to confirm that everything's working properly.
I'm going to be making some more videos on class of service with Junos.
Nice quick short videos I'm sure you find interesting.
In particular, we're going to look at marking packets, drop profiles,
which is also known as RED, WRED, or random early detection
per unit schedulers which are good for multi units
or sub interfaces, and virtual channels, which is really important for
IPsec Tunnels.
I hope to see you there and I hope this has been useful.
Let me know what you thought in the comments.