Well Cisco created a method of queuing known as class-based weighted fair que
uing,
which it sounds familiar, WFQ, we just talked about that. So overall we can
refer to this as CBWFQ. The idea here is now to continue to do fair amounts of
queuing but weighted and the waiting is going to be based on the traffic class.
This allows us to define almost any number of queues. Ultimately it's up to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This allows us to define almost any number of queues. Ultimately it's up to
256 queues on some platforms but again keep in mind that this is from a
software perspective so routers can go that high. A lot of more hardware-based
platforms like switches might have four or eight queues at the most that we can
configure here. But the idea is this we have total control over the queues that
we're creating. We don't have to worry about the high and low priority queues
and the automatic flow-based queues, all of those queues that lack control, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and the automatic flow-based queues, all of those queues that lack control, we
as
the admins, we have total control over the queues that we're creating as well
as
which traffic goes into which queues. So here's how this ends up working. Let's
say that we want to create let's just say six different queues. So one, two,
three,
four, five, six. So once again we're going to look at traffic marking and we're
going to perform classification based on the marking. And so we might place our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to perform classification based on the marking. And so we might place our
voiceover IP traffic. Let's say we have DSCP of EF and all of those packets go
into the top queue. We might do something like AF 40 X maybe all of the assured
forwarding that has a priority of four goes into the next queue and then AF of
three X in here. So three three three two three one and so on and so forth. And
so
we could do this all the way down and then have a best effort queue. So there WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we could do this all the way down and then have a best effort queue. So there
you go. There's six queues that we created that uses all of those per hot
behaviors that we talked about. Furthermore, we can actually assign bandwidth
reservations to each one of these queues. And so we could say that our EF
traffic is guaranteed 10% of the bandwidth. This could be percentage based. It
can be
a raw bytes and bits rate basis. It just depends on the link type and what we
want to do there. We could go on down here. We could say we're going to reserve WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
want to do there. We could go on down here. We could say we're going to reserve
10%
for EF and maybe 20% for what would probably be video traffic and AF for X
world. And then from there we can just kind of go down and say something like
15%, 15%, 15%. So that's 45, 55, 75. So at least 25% for best effort, which is
actually about perfect because we typically do want to leave at least 25% for
our best effort traffic. We can also define each one of these from a packet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
our best effort traffic. We can also define each one of these from a packet
length perspective or a queue length perspective. So how many packets can go
in each queue? We do have that as an option if we really want to fine tune this
creation of these queues. And so packets in each queue are going to be lined up
,
just like what we've drawn here. And so within each queue, within each
prioritization level, we're going to run first in first out. So this packet, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
prioritization level, we're going to run first in first out. So this packet,
for
example, is going to go before this packet within the queue. And then lastly,
with best effort, interestingly, as we fill packets into this queue, this
actually gets serviced based on weighted fair queuing, if we so desire. So we
can do FIFO, or we can do weighted fair queuing. So if we wanted to, we could
carve this up into the thousands of flow based queues. And that way that one
individual flow can't dominate the queue. So something to keep in mind in some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
individual flow can't dominate the queue. So something to keep in mind in some
environments that might make a lot of sense. But all of the other queues, they
are just going to be first in and first out. Now from here, we're going to have
that scheduler. And the scheduler's job is to make sure that we are abiding by
these different percentage amounts. And so we're going to get some amount of
traffic from the top queue. And then we're going to get, you know, probably
twice
as much in theory from the next queue and so on and so forth. So we'll see how WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as much in theory from the next queue and so on and so forth. So we'll see how
much traffic ends up getting sent out out of each one. But we do see that we
are
fairly getting to all of the traffic. And it doesn't matter what order they
arrive. For example, all three of these packets could have arrived before
either
of these EF packets, assuming they voice over IP packets. And yet we're going
to
make sure that we're servicing those packets in order to achieve the bandwidth
goals. One of the beautiful parts about class based weighted fair queuing is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
goals. One of the beautiful parts about class based weighted fair queuing is
also
that bandwidth reservations are flexible. Meaning that unused bandwidth
actually
gets shared. Not every network platform is able to do this. Not every router
and
switch out there. And so this is actually something that shouldn't be
overlooked.
If for example, there's just no voice over IP traffic, we're getting tons of
traffic down here. Well, it can use that 10% of bandwidth and send more traffic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
traffic down here. Well, it can use that 10% of bandwidth and send more traffic
based on the current network loads. And so that is again, is something that we
shouldn't overlook when it comes to Cisco devices. Now a problem, if we want to
call it that at this point, because this is actually a pretty good solution.
But
there is still a problem we need to call it what it is. And that is that we
lack
any sense of prioritization. I mentioned that these packets up here would get
serviced fairly, but we actually are okay with a little bit of unfairness. If
we've got all of these packets that are waiting, and then a voice over IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we've got all of these packets that are waiting, and then a voice over IP
packet
comes through, we're actually okay with just immediately sending that as long
as
it abides by the percentage that we set there, we don't want to go past 10%
because
yes, we want prioritization. That's important, but we want no starvation. So
it feels like it's a lot to ask for, but we have this bandwidth reservation.
And
so what we can do is we can create what's known as a low latency queue or LLQ. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so what we can do is we can create what's known as a low latency queue or LLQ.
So
the low latency queue, which can also be referred to as low latency queuing. So
it's kind of an upgraded form of class based weighted fair queuing. Now we can
call it low latency queuing, basically creates a strict priority queue. And yes
,
I'm putting this into quotes on purpose, because it's not fully strict. It also
turns the bandwidth reservation into a limit. So this creates two situations. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
turns the bandwidth reservation into a limit. So this creates two situations.
First of all, if a packet does arrive, it will get immediately sent out. That
is
the point of having a low latency queue. And yes, we are typically going to
reserve this for voice over IP traffic, which is marked with the SCP E F. So
this
top queue now becomes our LLQ packets show up, they get immediately sent out WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
top queue now becomes our LLQ packets show up, they get immediately sent out
the
interface, even if all of the other packets are waiting. So is that fair? No,
but we're actually okay with that. We like the fact that it's not fair, because
we're treating the voice over IP traffic like it really needs to be treated.
But
again, this bandwidth now becomes a limit, meaning that if voice track packets
pile
up so much that we have 10% of the band network bandwidth that we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
up so much that we have 10% of the band network bandwidth that we're going to
be
consuming, well, we can't just keep servicing packets at that point without
starving all of these other queues. So we are going to continue to perform
scheduling operations that will service these other queues and make sure that
we're not starving them. So it's really best of all world's approach. And it's
really it's something that Cisco came up with a long time ago. And it is the
type of queuing that we deploy into our modern networks and Cisco platforms. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
type of queuing that we deploy into our modern networks and Cisco platforms.
Now the way that we deploy these two queuing mechanisms is with a configuration
methodology that is known as modular QOS config or MQC. We're going to take a
look at MQC coming up. But this is where we're going to find that we've got
commands such as class maps and policy maps and service policies, some
configuration commands that a lot of us might be familiar with from maybe doing
QOS in the past. But either way, we're going to see how this can be leveraged WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
QOS in the past. But either way, we're going to see how this can be leveraged
to
create the number of queues that we want map the policy that we want, such as
bandwidth and queue length. And then also make sure that we configure that low
latency queue for the sake of adding priority functionality to our QOS
deployment for the sake of voice over IP.