At this point, we should be feeling good.
We've got the choice of what packets to drop for the most part in our network.
But that phrase for the most part is kind of a big deal because there's another
situation
that we need to talk about where packets might get dropped.
Here's the common situation.
Let's say I have a router and I have just connected to an internet service
provider.
And that internet service provider has sold me a line for 75 megabits per
second. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
second.
So what kind of handoff do they give me here to plug into my router?
Well, I don't know about you, but I'm not aware of any 75 megabit per second
type of
connections.
So they're probably going to give me a 100 megabit connection, maybe even a gig
, but
either way, it's going to be a standard ethernet speed.
So here's the question.
How exactly are they enforcing this 75 megabits per second?
And the answer is they're going to be using policing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the answer is they're going to be using policing.
Now policing is a problem for us and we're going to see why, but it's also a
very important
part of our QoS configuration methodology.
So let's see what situation is here.
They understand that this router is going to be sending traffic.
And because we're receiving all kinds of traffic and we're connected to a 100
megabit per second
line here, the router could very easily receive all of this.
And even with all of our buffering and everything like that, it might try to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And even with all of our buffering and everything like that, it might try to
send 100 megabits
per second.
The ISP is going to have some kind of device upstream, maybe it's a router,
maybe it's a
layer three switch.
But either way, this device is going to be receiving 100 megabits per second.
It's going to know that we have a policy in place that says 75 megabits per
second.
And so what's it going to do?
It's going to, first of all, allow the 75 megabits per second.
So that's good.
It's also going to drop 25 megabits per second. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's also going to drop 25 megabits per second.
And if the upstream ISP router is performing packet drops, well, what just
happened to our
goal of making sure that I as the organization that I have total control over
what packets
are getting dropped, this is going to be dropping my AF.
Again, we'll use 41, 42, 43 as an example, but it's going to be dropping a 41
as much as
42 and 43. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
42 and 43.
All of these will have an equal chance of getting dropped because the ISP doesn
't care
about my markings.
It's just going to indiscriminately drop packets.
Now we're going to talk about the solution to this in the next video.
The solution is known as traffic shaping.
But in order to properly understand traffic shaping, we need to understand how
exactly
this policy is getting enforced.
How does policing work? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
How does policing work?
And Cisco is even going to expect us to be able to configure policing based on
the current
blueprint for the exam.
So we need to really explore policing first.
And then in the next video, we can explore shaping as a solution to get us back
to this
world where we are controlling all of our traffic drops.
So let's talk about policing.
Policing is an interesting concept because keep in mind everything we just
talked about
here, our focus is on bandwidth limits. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here, our focus is on bandwidth limits.
Well that sounds simple, I've said that I'm allowing 75 megabits per second and
you just
sent me 100 megabits per second.
Therefore I can drop 25.
Now that might work from a math perspective, but it doesn't work great from a
real world
perspective.
Because here's the problem.
Bandwidth is actually measured as a number of bits over time.
And if I'm putting time in the denominator, we think back to our middle school, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if I'm putting time in the denominator, we think back to our middle school,
high school
math, I can't say zero seconds.
I can't narrow this time frame down to just a point in time and say what's the
bandwidth
for this link at 303 PM and zero seconds.
I can't do that because I put a zero in the denominator while we know that
problems start
to occur.
And that's not allowed from a math perspective.
So instead what I have to look at is I have to use a time interval to measure
my bandwidth. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
my bandwidth.
And so what is this time interval?
And for that matter, as I'm sending bits throughout this time interval, what
does the
average bandwidth look like?
And at what point do I start dropping my bits and bytes that the downstream
device has been
sending me?
Let's just paint this situation with an example real quick.
So let's say that my time interval is measured over one, two, one, two, three,
four, five WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
four, five
and six.
There we go.
So let's say that we're measuring over, actually, let's just say three seconds
to start with
and then we'll expand on this.
So let's say that in these first three seconds, this downstream device is
flooding me with
traffic.
I get 100 megabits in the first second.
So transmitting 100 megabits per second.
I get 100 megabits in the second second and I get 100 megabits in the third
second.
So over the course of three seconds, I have just transmitted 100 megabits per WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So over the course of three seconds, I have just transmitted 100 megabits per
second very
consistently.
That's 300 megabits divided by three seconds.
And so that's 100 megabits per second.
That would be a problem.
But what if then the device downstream starts sending me 50 megabits per second
?
So 50 megabits here, 50 megabits here, 50 megabits here.
Well if I were to take the interval of three seconds, then that device just
transmitted
at 100 megabits per second. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at 100 megabits per second.
But if I take the interval of six seconds, that is 450 megabits over six
seconds.
And if we run the math on that, guess what that comes out to?
75 megabits per second.
Do we start to see the problem here?
Depending on how we define our intervals, depending on how we define what our
bandwidth
is measured by, if we say it's three seconds, then we had a clear violation.
If we're measuring it over what happens to be six seconds here, then it's no WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we're measuring it over what happens to be six seconds here, then it's no
violation
at all.
And so this is why we can't just say something as simple as this bandwidth math
that's basic
addition and subtraction.
So how are we going to solve this problem?
Well, we do have a pretty good solution from Cisco for this, and it is known as
the token
bucket system.
Token bucket system has a basic version and an advanced version. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Token bucket system has a basic version and an advanced version.
And so we're not going to drill into all of the advanced stuff that we might be
expected
to know for higher level exams.
Instead, we just really need to understand what the concept is.
Here's the idea of the token bucket.
We are going to have a bucket of tokens.
And any time a packet needs to be sent, I have a packet to send, I'm going to
need to
consume one of these tokens.
So this is essentially the number of packets that I'm able to send. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is essentially the number of packets that I'm able to send.
Meanwhile, I'm going to feed this bucket with additional tokens based on
whatever my rate
is here, let's say 75 megabits per second.
So notice what we're not doing here.
We're not just feeding directly into the packet flow.
If we were, then we could never exceed 75 megabits per second, even for a
single second.
Instead, we are creating a little bit of a buffer here that allows me to build WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Instead, we are creating a little bit of a buffer here that allows me to build
up tokens
when my bandwidth is down and consume those extra tokens when my bandwidth is a
little
bit higher.
And the idea here is that if there is a token, then this places us into a
status that's known
as conforming.
This traffic conforms to our policy.
If there's no token available, then this is known as an exceeding packet.
This packet has exceeded our policy. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This packet has exceeded our policy.
Now importantly, there are other bucket methods that get a little bit more
complex.
For example, we have double bucket systems and two, two colors, single rate,
dual rate,
three color systems.
Essentially what we're saying here is we have the more advanced version that
actually
has two buckets.
And this allows for not only the ability to send packets normally.
So this is our normal bucket.
But then we also have the ability to store extra tokens over here, which is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But then we also have the ability to store extra tokens over here, which is
known as the
burst.
And so if I have a token in the normal, then I can send it.
This again places me into the conform state.
And in this case, if I'm bursting, it's going to place me into the exceed state
.
Well what if I have no token down here?
Well that introduces a third situation, which we call violation.
So this packet has violated our policy, which sounds even more extreme than WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this packet has violated our policy, which sounds even more extreme than
exceeding it.
Now token bucket systems can be pretty complex.
And I want to stress that it's really outside the scope of this exam and of
this content
to really drill into the details of the token bucket system, especially our
advanced form.
But at the same time, we do need to understand that what we're saying is that
we're going
to store tokens in some way, send packets when we have tokens, and we're also
feeding the
token bucket with tokens at a particular rate. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
token bucket with tokens at a particular rate.
The reason why that's important is because later when we're configuring
policing, we're
going to see these rates mentioned.
And so we need to kind of be able to come back and remember what exactly this
process
looks like.
If you want to know more details about token bucket systems, absolutely jump
into the collaboration
core exam course, make sure that we are searching for token buckets where we
explain in a great
amount of detail how these come together.
And that's if you're just curious and you want to know more information about WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's if you're just curious and you want to know more information about
how all
of that comes together.
However, again, keeping things within scope of this conversation, we really
just need
to kind of understand the mechanism of how this works and ultimately the
problem we're
trying to solve, which is that bandwidth must be regulated over the course of
time, showing
a little bit of grace because there are going to be times when we exceed that
amount and
there's going to be times when we are under that amount and we're trying to be
fair to
the person who's sending us traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the person who's sending us traffic.
So that's the idea there.
So notice that we have three different statuses.
So this is the status of the packet, but we haven't said yet what we're going
to do
with the packets.
So we need to define the policy for each one of these situations.
And we have three different options.
Notice we're not hard mapping policy decisions to the status.
We're simply presenting ourselves with policy options and then we can decide WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're simply presenting ourselves with policy options and then we can decide
what to do
with each one of these are three different policy options.
First and foremost, we can allow the packet to go through second of all, of
course, we
could just deny the packet and drop it and that's mostly what we're here to
talk about
with policing.
But there is a middle ground interesting option, which is to remark the packet
and allow it.
And so ultimately we're going to transmit it.
This is implied.
We usually just say it's remarking the packet, but understand that we are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We usually just say it's remarking the packet, but understand that we are
transmitting it
as well.
So what do we mean by remark?
Well, typically what that means is we're going to take our AF, let's say 41 and
we're
going to remark it as AF 42 or AF 43.
What we've done is we've increased the likelihood that this packet gets dropped
later on in
the network.
We might even find that later on that there's still congestion later and we
would want to
drop it at that point.
Now for an ISP and we're trying to mandate specific policies, we're probably WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now for an ISP and we're trying to mandate specific policies, we're probably
not going
to do a whole lot of remarking.
We're just going to focus on denying or dropping the packets.
But if we are allowing the packets through, then we're not going to remark them
at all.
So that is, these are our three different policy options.
So then the question is how exactly do we want to map these to the status?
In a lot of situations we're going to put conforming traffic into the allow
category
to say that we're just going to transmit that as is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to say that we're just going to transmit that as is.
And we're going to put remarking in for exceeding and dropped packets are for
violations.
However keep in mind we might be using the more simple token bucket method
which only
gives us two options conforming exceed at which point deny might actually be
what we
do for the exceeding traffic.
And for that matter, there might be other situations that require us to kind of
change
these around.
And understand that we are in control of the policy as it distributes between WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And understand that we are in control of the policy as it distributes between
the category,
the status here, of what a packet is, and then what exactly we do with the
packet based
on that status.
Now remember, our goal in talking about policing is number one to be able to
understand what
exactly it is and how it works so eventually we can configure it.
But the other consideration is we want to get back to having a choice over what
packets
get dropped.
And right now, as of this moment, we have said that the ISP is going to be the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And right now, as of this moment, we have said that the ISP is going to be the
one dropping
all of these packets using their policing policy.
In our case, what we want to do is we want to leverage this other solution
shaping to
try to make it so we never drop a packet on the ISP, we want to make sure that
we are
always in control over which packets get dropped.
So let's take a moment to go explore how shaping can get us back to that goal
of always
deciding which packets to drop.