All right, so all same deal, we're going to have an eight question quiz here
and make
sure you pause the video appropriately to be able to answer the question
yourself.
So first up here, an edge router is connected to an upstream service provider
router.
Just go ahead and sketch that out here.
So we've got maybe this is our corporate edge router and this is the service
provider and
an SLA of 75 megabits per second has been set, which interface will you shaping
and which
will use policing.
So the general idea here is that we don't have an ethernet speed that we could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the general idea here is that we don't have an ethernet speed that we could
set our
interfaces to that matches the SLA.
If the SLA happened to be 100 megabits per second and this was a gig link, then
we could
set the speed to 100 and everybody would be pretty happy with that.
But we can't do that with 75 megabits per second.
Instead, we're going to have a one gig or 100 meg connection and we're going to
have
to restrict the bandwidth.
So at that point, the service provider is going to use policing and we should WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So at that point, the service provider is going to use policing and we should
use shaping.
So there's our answer shaping on the corporate router, policing on the service
provider router.
So what's going on here?
Well the policing is going to enforce our SLA and it's going to do that by
dropping excess
packets.
So if I exceed that 75 megabits per second with potentially a little bit of
grace in
there, we call that bursting traffic.
I could burst above it for a short amount of time.
And so if I burst above it fine, but ultimately I'm going to eventually run out WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so if I burst above it fine, but ultimately I'm going to eventually run out
of grace and
I'm going to have my packets start to get dropped.
The problem with this is that, yeah, okay, fine, so be it.
I'm sending too much traffic.
You have to drop it.
The problem is that we're going to be indiscriminate about what traffic we drop
.
We can drop any traffic and the service provider does not care, meaning that
voice over IP packets
could be dropped when we start to exceed our traffic, our SLA. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
could be dropped when we start to exceed our traffic, our SLA.
And so we'd rather say, you know what, yeah, you're supposed to drop our excess
traffic,
but we want to make sure that you drop absolutely no traffic whatsoever.
Instead, I will perform the drops myself.
On my end, if I know I'm going to exceed the SLA, and this way I get choice in
the matter.
So I can keep my voice over IP packets intact.
I can intentionally drop my bulk traffic like internet streams and downloads
and file transfers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and file transfers
and things like that that aren't latency sensitive.
And those packets will get resented in some form or another, whereas voice over
IP packets
don't get reset.
And so I'm going to use shaping in order to accomplish this, which may actually
mean
I don't have to drop a whole lot.
If depending on the ebbs and flows of traffic, I can kind of take that traffic
and shape it
down.
And maybe with enough buffering, I can get all of the packets through.
But in times of congestion, I don't get to just not drop any traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But in times of congestion, I don't get to just not drop any traffic.
I'm going to have to drop it at that point.
I can drop the non critical traffic.
So shaping is always an outbound policy.
Policing is usually an inbound policy, but it can technically be used outbound
in most
real world scenarios.
We're going to see shaping be our outbound and policing be our inbound types of
policies.
Next question, what iOS XC command is used to configure the LLQ within a policy WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Next question, what iOS XC command is used to configure the LLQ within a policy
map?
So something to keep in mind is that we had a challenge in our configure QOS
skill that
allowed us to log in and perform configurations.
So in order to best get our hands back on that, I recommend going back to that
skill
and performing the challenge there.
However, in our case, it does still help to be able to answer questions like
this to
yeah, we don't have to have every command memorized, but we should have some of
the
big ones, at least in our minds.
And so this one here about a command used to configure LLQ, the difference WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so this one here about a command used to configure LLQ, the difference
between an
LLQ and a normal Q is I'm going to need to perform a bandwidth command with a
normal
Q. This is how we perform a reservation for, let's say, video traffic or maybe
my best
effort traffic.
But the priority command is what's going to set LLQ.
And I can just say priority and hit enter and it becomes a strict priority
queue or I
can enter like 100 kilobits per second or 100 megabits per second or whatever
value I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
value I
want, which then turns into a limit, which prevents the strict priority queue
from starving
other traffic flows.
But be here, that would be our answer.
All right, similar question here, which iOS XC command is used to apply an MQC
policy
to an interface?
Well, in order to apply our policy to an interface, that's going to be our
service policy.
So C is the answer.
But we do need to remember how this all comes together.
We're going to use class maps in order to perform the classification of the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're going to use class maps in order to perform the classification of the
traffic.
And then, so this is classification, which is why we call it a class map, by
the way,
forming different traffic classes.
And then our policies are going to be defined here in the policy map.
So not too bad to remember which map is supposed to be used for which.
But then I ultimately create this policy map and it consists of multiple class
maps with
the policies within them.
So it sort of becomes this nested type of concept. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it sort of becomes this nested type of concept.
And then I'm going to take this policy map and apply it to an interface using
the service
policy command.
I do have to specify whether it's input or output.
But that is how the basic MQC structure comes together within the iOSXE
configuration.
All right, next up.
What two goals here can be achieved by using weighted random early detect for
congestion
avoidance?
Congestion avoidance is a very important aspect of quality of service and it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Congestion avoidance is a very important aspect of quality of service and it
doesn't
tend to get as much attention as things like packet marking, classification and
queuing
and configuration, all these things.
But congestion avoidance is very important and we have weighted random early
detect as
well as the random early detect concepts within the world of quality of service
.
So what are we trying to do here?
I mean, the name is right there.
We're trying to avoid congestion.
How do we avoid congestion?
I mean, wouldn't that be wonderful if we could just avoid congestion everywhere WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I mean, wouldn't that be wonderful if we could just avoid congestion everywhere
?
But the idea here is my queue and my buffer for an interface is only so large.
And eventually even if I have multiple queues here, I'm going to run out of
packet space.
And so within a queue, let's say we're approaching the end of the queue here
and another packet
shows up that's supposed to go into that queue.
Well now I am out of space and this packet gets dropped.
And this is known as tail drop and it's sort of the default, if we want to call
it congestion
avoidance, it doesn't really avoid anything. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
avoidance, it doesn't really avoid anything.
But it's this default policy that exists within each queue.
So instead I can use weighted random early detect and try to drop packets as
different
thresholds within the queue with a percent chance of being dropped.
And this ties back to our shared forwarding to say that hey, you know, if a
shared forwarding
let's say 2x is going into this queue, well a 23 has a very high probability of
getting
dropped, whereas 22 is right in the middle and 21 has a low chance of being WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
dropped, whereas 22 is right in the middle and 21 has a low chance of being
dropped.
But they all go into the same queue because they all have a priority value of
AF2x.
So at that point, I can say, you know, once I pass this threshold, I should
start dropping
AF23s and once I start, you know, get to this threshold, then I should start
dropping AF22s
and AF21 shouldn't be dropped until the end and then we've got the ability to
kind of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
kind of
increase our rate of drops throughout the queue.
And it's a whole topic of conversation that we looked at in an immense amount
of depth
down here in this skill.
So what is ultimately the purpose of this?
Well, as we just said, we want to prevent tail drop.
We want to enable us to survive that and therefore our more critical packets
like the
21s shouldn't just get tail dropped if we have a bunch of 23s in the queue. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
21s shouldn't just get tail dropped if we have a bunch of 23s in the queue.
And so we're protecting our critical packets from getting tail dropped and that
's a big
part of it.
But what's, but the other aspect of this is it's meant to smooth out my drops
and not
just, hey, sometimes I fill up and then I drop all the packets.
Remember what we said with TCP, it means that I can, we ramp up because of the
TCP
windows, we ramp up our, our throughput and then all of a sudden we drop a
bunch of packets
and so TCP windows throttle back and we get this shark fin effect that we just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and so TCP windows throttle back and we get this shark fin effect that we just
kind of
keep seeing this, that all TCP devices are responding the exact same way to the
traffic
drop.
This is known as global synchronization and we want to prevent that, which
interestingly
enough, red without the weighted actually prevents that, but it doesn't do
anything
to help with the critical packets versus the not critical packets.
And this is where weighted random early detect is able to do both.
So be an E, those would be our answers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So be an E, those would be our answers.
All right, question five, what does it mean to have a three color policeer as
opposed
to two color?
So policeers can get pretty complicated and we want to keep this within the
scope of the
course in the exam.
And as a result, we're not, we don't need to necessarily have the entire token
bucket
system completely down pat, but we should understand some basic concepts such
as what
is a three color versus two color.
The idea here is that we're going to support three different outcomes.
Remember, we have three different actions that we can take. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Remember, we have three different actions that we can take.
We can drop a packet or we can remark a packet or ideally we simply allow the
packet to go
through.
And so if these are three actions, well, that's great and all, do we actually
have three
different categories?
Well, if we have a two color policeer, we really only have two categories, sort
of this
concept of saying that I've got a rate established here and I'm conforming on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
concept of saying that I've got a rate established here and I'm conforming on
this side and I'm
exceeding the rate on the other side.
But with a three color policeer, I have two rates that committed information
rate and
the peak information rate.
And so now I actually have three categories.
I'm conforming or I'm exceeding or I'm violating.
And now I can take these actions and match each one up to one of these
categories.
So that's generally the idea. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's generally the idea.
Now if I only have two colors, then I can take any one of these usually allows
going
to go here and maybe I'm just going to remark.
I'm not actually going to drop anything with my policeer or maybe I'm not going
to remark
it, I'm just going to drop it.
But either way, we see that we have to choose which action goes to which and a
two color
whereas three color kind of gives us these three different scenarios, which is
likely
going to align with the three different actions that we can take.
All right, question number six, a three color policeer like we just talked WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, question number six, a three color policeer like we just talked
about has been
deployed onto an interface with that CIR of 50 megabits per second and a PIR of
75.
If the traffic flows about 70 megabits per second, how is traffic categorized?
Well we basically just map this out for us.
We've got the CIR of 50 megabits per second.
We've got the PIR of 75 megabits per second.
And we're suggesting that we're landing somewhere about here, about 70.
So where are we?
How is it going to be categorized? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
How is it going to be categorized?
Well in this three color policeer conforming is over on the left, exceeding is
between
the two and violating is on the right.
So we are going to fit into the exceeding category.
Notice that those are really the only three pushing was never on the table.
All right, question seven, we are almost there.
Which iOS XC policeer command is only used for three color policeers?
So this is a little bit tricky because BC and CIR, these are definitely part of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is a little bit tricky because BC and CIR, these are definitely part of
two
color policeers.
And so it's not going to be either one of those.
It's there for both two color and three color.
The question is this excess burst as well as the peak information rate, those
are both
three color policeer concepts.
Only one of them applies here though.
And the answer is going to be PIR.
Yeah, bird excess, excess burst, BE can actually be used with the three color WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Yeah, bird excess, excess burst, BE can actually be used with the three color
policeers.
But it can also be used here with the two color policeers.
Otherwise if we don't specify it assumes a default value, or but in the end if
we are,
if we're wanting to configure a three color policeer, we have to specify the P
IR and that's
the only time it's used.
All right, finally last question.
We're going to match the wireless user priorities to the below access category.
So remember how wireless quality of service works. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So remember how wireless quality of service works.
We're not going to use COS and usually we're not going to rely on DSCP.
We have a whole new type of category of our tags and that would be user
priorities.
So these user priorities are going to be three bits, which means it ranges from
zero to seven.
Furthermore, we don't get to define our own queues.
We're not going to use class based weighted fair queuing to define our own.
Instead, we're going to use access categories that have been predefined for us.
And those would be these four on the left, V.O., V.I., BE and BK. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And those would be these four on the left, V.O., V.I., BE and BK.
I did not make those up.
Those are what we use in the wireless world.
And so we need to understand what they represent.
V.O. is voice over IP, V.I. is video, BE is best effort.
I don't just say BE here, MBK would be background.
And in the networking world, we sometimes refer to this as scavenger class of
traffic.
So we could look at this from the perspective that if I'm configuring a Cisco WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we could look at this from the perspective that if I'm configuring a Cisco
router, I
get to decide which tags go into which queues.
If I don't get to do that either with wireless, all of this is kind of set up
for me.
And so the user priorities are just going to go down the pipe here with a
little bit
of an exception.
So we start at the top, voice over IP gets six and seven.
Yes, at the moment, at the time of this video, probably not going to change at
this point.
We get two tags per queue, which means six and seven are treated identically. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We get two tags per queue, which means six and seven are treated identically.
Video would be the next two values, four and five.
Best effort we'd say would be the next two, which is three except, it's not
three and
two.
So we're counting down six, seven, five, six and seven, countdown seven, six,
five, four,
three.
But then we actually are also going to include zero.
Why are we including zero?
Because a no tag or untagged packet is the same thing as a zero.
We want to place that into best effort, not into background.
So zero must land with best effort, even though we're counting down seven, six, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So zero must land with best effort, even though we're counting down seven, six,
five, four,
three.
And so there we get three and zero, which means the last two go into background
.
And the background is scavenger, which again, is sort of a, it's the traffic
type that we
say in times of congestion, just drop it all.
We don't care about it.
If it doesn't go through, if it never goes through, that's perfectly fine.
And it's up to each organization to define what types of traffic fits into
background.
So when it comes to wireless, uh, quality of service, this is some of the main WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So when it comes to wireless, uh, quality of service, this is some of the main
concepts
to try to take away as memorizing the different access categories, as well as
the user priorities
that belong in each one.