Well, we've brought up a couple of situations that we really need to address.
So let's say we have this wireless station and it sends a voiceover IP frame
and it sends
that frame with a user priority of six.
Well, we know once that's received by the access point that it's going to see
this user
priority of six and translate this over to a DSCP value of, well, we multiply
it by
eight and it's 48, which is not a good value for our wired network on top of
the fact it's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the fact it's
just not the right value for voiceover IP in general.
We also have the problem of it just being the situation where we're dishonest.
We say, hey, I'm going to send all of my traffic with a user priority of six
and that lands
on the wired network with a very, very high priority level.
So either way we need to address this problem.
And so we've got a couple of options that we've mentioned one of them, which is
to simply
trust the DSCP tag. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
trust the DSCP tag.
Now this works well for the voiceover IP side of things because when the voice
over IP packet
is sent, it's going to be sent with a DSCP value that's correct of EF, which is
46.
But it doesn't help us with the second problem, which is that our wireless
stations might
be dishonest in sending a DSCP value that, you know, maybe now they're sending
all of
their bulk traffic with a DSCP of 46.
That would really wreck havoc on our voiceover IP network traffic.
So that is one solution. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that is one solution.
The other solution is to going to be to use a couple of Cisco catalyst policies
that
are going to allow us to restrict which DSCP values can end up resulting from a
particular
communication.
So this is going to involve what we call Cisco's precious metals policies or
precious metal
policies.
And sometimes it's just referred to as metal policies as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And sometimes it's just referred to as metal policies as well.
So regardless, what are we talking about here?
Well, Cisco wireless LAN controllers, they want to simplify our QoS
configuration through
some important preset policies.
So these are preset pre-established on our wireless LAN controllers, which help
us to
manage our wireless network.
And interestingly, they take the form of MQC policies at least on our iOS XE
platforms.
Cisco wireless LAN controllers have evolved in recent times. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Cisco wireless LAN controllers have evolved in recent times.
They're no longer the old arrow, S piece of hardware.
Instead they run iOS XE software.
And if we're running one of those new catalyst 9800 wireless LAN controllers
running iOS
XE, we will see in the configuration that they show up as MQC policies, the
same types
of policies we just looked at with class maps and policy maps and all of that.
Now an important question here is why are we calling this a precious metal WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now an important question here is why are we calling this a precious metal
policy or
just a metal policy?
And that is because these policies take the form of either a bronze policy,
silver, gold,
or platinum.
So there's four different policies and they all take the form and name of one
of these
precious metals.
What we're going to do is we're going to take one of these policies and we're
going to apply
one of them to our SSID's. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one of them to our SSID's.
Now the SSID represents the wireless network on a wireless LAN controller.
This is part of a WLAN configuration, which is when we're using our wireless
devices over
here to communicate to the access point.
If I want to join a wireless network, I'm going to look for the SSID that's
appropriate
and then authenticate and join the network.
And so if I have lots of different devices or lots of different SSID's, that is
certainly
possible. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
possible.
I could have an access point and I use one SSID to communicate with my laptops
and my
tablets and things like that.
I can have another SSID that I use to map to the wireless phones that exist in
my network.
So as we might imagine, we want to absolutely enable high prioritization of
traffic on one
side and maybe not on the other.
In a mind that some of these mobile devices might actually have voice over IP
capabilities.
We might be using soft phones that run on these devices so that can definitely WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We might be using soft phones that run on these devices so that can definitely
get a
little bit tricky.
So let's break these down and we'll see very quickly what their purpose is.
If we're looking at the platinum policy, this is going to be used when there's
voice
over IP packets present.
And what it does is it actually maps user priority six and seven to our DSCP of
EF.
So as that user priority traffic is coming in, it's going to be mapped not to D WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So as that user priority traffic is coming in, it's going to be mapped not to D
SCP 48
anymore, but to DSCP 46.
And for that matter, even use a priority seven, which would have gone to 56,
that is now getting
mapped properly as well.
So that's pretty cool.
It also allows video traffic to get mapped to a 41, which is the highest
priority of
assured forwarding, as we recall, with the lowest chance of getting dropped.
So that is what platinum policy allows for.
And it basically, when we're looking at these policies, we're going to find
that it's really WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that it's really
more about what it allows.
These different policies are going to allow for different types of traffic to
exist.
So that's the question is, what are they going to allow?
So next up, we have our gold policy.
And the gold policy is when we don't have real time services or real time
traffic.
So this is both voice over IP and video conferencing.
Now there's a big difference between video streaming and video conferencing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now there's a big difference between video streaming and video conferencing.
Video conferencing, when we're talking about video here, video conferencing is
real time.
It's communicating back and forth between two different users, maybe one's on a
mobile
device, one's on a PC.
Regardless of what the situation is, we understand that's real time traffic.
And that's going to be important because video conferencing falls into platinum
.
But then there's video streaming.
And video streaming is not real time. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And video streaming is not real time.
It involves a server pushing one way down to a PC or a mobile device or just
some sort
of end user.
This is not real time.
And therefore we don't need to map it here.
But rather we need to map it down here.
And so always keep in mind what we're talking about when we say video, we're
talking about
video conferencing, not video streaming.
Video streaming has buffering.
We've got all kinds of mechanisms for handling network delays that video conf WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We've got all kinds of mechanisms for handling network delays that video conf
erencing can't
take advantage of.
So with gold, we're not talking about real time voice or video.
However, when we're talking about video streaming, that's going to get tagged
to AF 41.
And this is the max value, meaning if we have these dishonest stations and they
're sending
things at user priority six, remember, we have no control over how the station
performs
the transmit. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the transmit.
They might well send bulk traffic at a higher priority than they should.
And there's not much we can do to stop them.
But once it hits the access point, I'm going to send that packet on.
At that point, I need to at least protect the wired network.
And so if they are sending with a user priority of six, it's going to get
mapped all the way
down to a 41.
So this is why we say what exactly is allowed by these policies.
Well, we're going to allow video streaming at 41.
And if you're sending me higher level traffic, it will also get mapped to a 41, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if you're sending me higher level traffic, it will also get mapped to a 41,
but we're
not allowing anybody to send traffic that gets mapped to my EF that would mess
with
my voice over IP traffic on the wired side.
So then we've got a couple more here.
We have silver and silver is going to be intended for my normal network traffic
.
And this basically sets all traffic to a DSCP of zero. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this basically sets all traffic to a DSCP of zero.
So again, an SSID like this where we're going out to just normal users,
especially maybe
guest users, we'd want to set a silver policy.
All traffic should be received and put onto the wired network as DSCP zero type
of traffic.
And then I'm out of space.
So I'm going to add bronze over here.
Bronze is going to be very similar, except at this point, this is for our
scavenger traffic,
which we explained earlier.
It's the first traffic to drop and all traffic is going to get mapped to a DSCP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's the first traffic to drop and all traffic is going to get mapped to a DSCP
value here
of CS one that class selector one, which is a value of eight.
And once again, at first glance, we say, well, that's a higher number than zero
.
But again, we're reserving that class selector for scavenger traffic.
And so it might feel backwards at first, but again, with QOS policies with the
fact
that we have a scavenger class.
We just need something to be worth less than zero.
We don't have negative numbers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We don't have negative numbers.
So we can't use negative numbers.
And so that's what we've assigned CS one to do for us.
Now when we look at configuration and the wireless LAN controller, which is a
little
bit beyond the scope of what we need to go into here, Cisco's not asking us to
go in
and configure a bunch of QOS policies, we just need to understand a lot of
these concepts.
But when we are going into the configuration, we will find that there are e
gress policies
and there are ingress policies. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and there are ingress policies.
And these policies will again take different forms here as far as class maps
and policy
maps are concerned.
There'll be different class maps and policy maps used for these egress and ing
ress policies.
Specifically, ingress policies are known, for example, as let's just say for
platinum,
this platinum dash up, whereas egress, this is just known as platinum.
So I'm going to have to deploy an egress policy and an ingress policy.
These will be separate.
And when I use the drop down, I'll see that egress has a platinum as an option. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And when I use the drop down, I'll see that egress has a platinum as an option.
Ingress has platinum dash up as an option.
And if I go to the actual iOS XC CLI configuration, I'll see these clarified in
the MQC policy.
So what's the difference between them?
Well, egress policies, these assume that we have full control over the tags
because we
do.
If it's an an egress, that means that the packet is coming from the network and
it's
about to be sent out of this access point.
So we have good, valid tags coming from the network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we have good, valid tags coming from the network.
The platinum up command or configuration, this is intended to fix these issues
that
we started out by talking about.
And we don't have control.
We know that we don't have control over the tags as they come into the access
points.
And so we need to align.
We need to wipe the tags in some in some situations.
But there are slightly different policies.
Meanwhile, if we're looking at an SSID, we usually want to align that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Meanwhile, if we're looking at an SSID, we usually want to align that.
And again, it has more to do with what devices are out there.
If I have a phone network of phone SSID, I'd want to assign that to platinum.
But if I have this SSID and it also has laptops and users on it, well, I have
no choice.
I have to assign it platinum because of the voice over IP wireless phones.
And so keep that in mind as we're thinking about wireless configurations that
we almost
have to look at the greatest common denominator, so to speak, look at the most
critical devices
that are on a particular SSID and not the lowest common denominator and then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that are on a particular SSID and not the lowest common denominator and then
assign the policy
appropriately.