So now that we've created our policy maps, the policy map is going to establish
a set
of cues that will be mapped to a particular interface.
In our situation here, let's say that we've got four different cues.
And we know that we can map one of these cues to be a priority cue.
And believe it or not, we can actually map a second one of these if we so
desire.
Now where we want to go with this conversation is talking about our bandwidth WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now where we want to go with this conversation is talking about our bandwidth
reservations.
But in order to talk about reserving bandwidth and locking that down for
different cues, we've
got a lot of different ways of doing that, but we need to establish how many
priority
cues we have.
We can have zero priority cues.
We can have one priority cue.
This is known as the low latency cue at that point.
Or we can even have shared multi-level priority cues.
The way this works, if we do multi-level, is we're going to establish two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The way this works, if we do multi-level, is we're going to establish two
different priority
cues and we are going to configure them for either level one or level two.
And what we're doing here is we're establishing a level of hierarchy.
In other words, yeah, both of these are technically priority cues and then we
have all of the
non-priority cues down here.
However, if there are packets at the level one cue, then they will take
priority over
level two. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
level two.
In the real world, generally what we're going to do here is we're going to
place voiceover
IP at the level one priority and then maybe video traffic or some other mission
critical
traffic at level two.
Because voiceover IP is very small packets, we really want these to get going,
to throw
them at the front of the cue and to get them out the gate.
We do not want them waiting behind something that is much larger.
Like a video packet that might be a thousand bytes or even up to fifteen WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Like a video packet that might be a thousand bytes or even up to fifteen
hundred bytes,
voiceover IP packets really don't want to have to wait for that entire large
packet
to be transmitted.
So in our configuration, we can set not just a priority status, but we can also
set the
level of priority.
And if we have two priority cues, then we'd want to absolutely make sure that
we build
level one and level two appropriately.
Now from here, again, we want to be able to talk about bandwidth reservations. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now from here, again, we want to be able to talk about bandwidth reservations.
One of the primary benefits of this model is that we can customize fully the
cueing,
not only from a classification perspective.
Remember I can classify my traffic usually based on tags.
Again, we've got other options that we explored, but I would assign maybe my EF
tags up here
my AF4X packets in here.
Down here, this would be my class default.
And so this would be the catch all. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so this would be the catch all.
And then maybe I have that third cue where, I mean, whatever I'm using in my
organization,
maybe I put three X and two X traffic in here for assured forwarding, something
along those
lines.
But now I want to be able to place bandwidth reservations and for that matter
bandwidth
limits for my priority cues.
Because in times of congestion, I don't want to send all of my voice and video
traffic
at the expense of these other cues and never send anything out. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at the expense of these other cues and never send anything out.
And so at this point, we're going to use a series of commands, a set of
commands in
order to perform our bandwidth reservations.
Now we already took a look at this briefly.
For example, we've got the priority cue or priority command rather that defines
the bandwidth
we're reserving or really limiting for the priority cue.
And then we also have the bandwidth statement.
Now when we're specifying a raw value here, we are going to specify this in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now when we're specifying a raw value here, we are going to specify this in
terms of
kilobits per second.
So I might say 100 kilobits per second for the priority cue.
And then for the other cues, maybe I say 25 megabits per second.
So I could say like 25,000 in order to define the bandwidth reservation for the
other cues.
And a lot of our configurations, this is how we're going to find that we
perform these
configurations.
And that's perfectly fine.
However, keep in mind that when we're using these raw numbers, it's up to us to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However, keep in mind that when we're using these raw numbers, it's up to us to
do the
right math.
Now the class default at the bottom, maybe we can use that as sort of that
catch all
to say we're going to put all of the rest of the bandwidth into that bucket.
But we don't have to necessarily do that.
Each one of these cues is going to get its own bandwidth reservation and we can
put that
into class default.
And so we might end up reserving, let's say, I don't know, by mistake, we
reserve 90 megabits
per second out of the 100 megabits per second on the link. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
per second out of the 100 megabits per second on the link.
And so we are responsible ourselves for doing all the math again, making sure
this all adds
up appropriately.
So in the real world, again, we might see a lot of this.
But generally speaking, we might also see us change our method over to be using
more
of a percentage based methodology.
Now there are two ways to perform percentage reservations.
One is just again a raw percentage now where I have a total bandwidth of 100%. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
One is just again a raw percentage now where I have a total bandwidth of 100%.
And so I would say, hey, I want to use my priority queue and I want to reserve
10%.
So I would specify for my other cues the bandwidth command, but now I'm
specifying a
percent.
So I could say like 35% for one queue.
And then we've got two other cues up here.
So maybe we do like a 40% and then a 15%. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So maybe we do like a 40% and then a 15%.
And I think that adds up to a hundred 75.
Yeah, that looks like a hundred percent.
So this would be a valid configuration.
But again, we're responsible for making sure that it adds up to a hundred.
So ideally, this is supposed to add up to a hundred percent.
And if we don't allocate bandwidth or we don't reserve bandwidth, then that
bandwidth
just goes on reserved.
So the other option that we have available to us is a remaining percent command WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the other option that we have available to us is a remaining percent command
.
And this is an interesting concept.
So now I could say, hey, I want to use not 25 or 35% bandwidth.
And maybe I want to say bandwidth remaining and then 25%.
So what are we talking about here?
What is remaining percentage?
Well, the remaining percentage is going to remove the priority statements from WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, the remaining percentage is going to remove the priority statements from
the bandwidth
reserve or reserved from the priority queue, which is kind of interesting.
So let's say again, I have a hundred megabit per second link.
And I could now say, hey, for my priority queue, I want to reserve 10 megabits
per second.
So that'd be 10,000 kilobits per second.
So this is 10 meg.
So how much is left?
Well, after the 10 meg, there's going to be 90 remaining or 90 meg left. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, after the 10 meg, there's going to be 90 remaining or 90 meg left.
So now I can divide that 90 up among the rest of the queues down here.
And now I can see a little bit more clearly that maybe each one is supposed to
get 25%
of the remaining bandwidth.
So I could do that type of configuration where this adds up to 100%.
Even though we have a priority statement that references a hard bandwidth
amount.
So these are some configurations that we can use to divide up the bandwidth in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So these are some configurations that we can use to divide up the bandwidth in
a way that
makes it so that we have as much control over the bandwidth reservations as
possible.
Now one last option I'll mention here briefly is we can also use a ratio.
This is kind of fun because rather than using percentages and kilobits per
second measurements,
now I can actually do a ratio among my queues. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
now I can actually do a ratio among my queues.
So for example, if I have my three queues and I set a ratio of 2 to 1 to 1,
well now
this queue is going to get twice as much traffic as these other queues for
every 1 kilobits
per second that these queues are reserved.
This queue gets 2 kilobits per second in that ratio order.
Meanwhile I could also make a queuing ratio of 4 to 1, 1 for 4 different queues
.
So now for every 1 kilobit per second of reservation these lower end queues get WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now for every 1 kilobit per second of reservation these lower end queues get
, this
queue gets 2 kilobits per second and this more important, I assume, more
important queue
gets 4 kilobits per second.
So setting this as a ratio is certainly an option as well and if we don't want
to mess
with percentages and we don't want to mess with hard kilobit per second
reservations
then maybe a ratio is a good way to go.
But as we see here, Cisco gives us lots of options for the configuration of our
bandwidth
reservations and keep in mind that we do need to define our priority queues as WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
reservations and keep in mind that we do need to define our priority queues as
part of this
because that's going to tie into any kind of bandwidth percentage remaining
configuration
and it's also going to turn our bandwidth reservations into hard limits in the
event
that our link is saturated because we don't want to cause starvation of the
other queues.