|
0:00:12
|
In our next section, we're going to look at the Catalyst 3560
|
|
0:00:15
|
QoS which is different than the previous router's implementation
|
|
0:00:19
|
of the module of the quality of service because the Catalyst
|
|
0:00:23
|
QoS is going to be hardware optimized.
|
|
0:00:26
|
Essentially what this means from our perspective
|
|
0:00:29
|
is that there are a lot less features available
|
|
0:00:33
|
in the Catalyst QoS as compared to the module of the quality of service
|
|
0:00:37
|
and the hierarchical queuing framework that's available
|
|
0:00:40
|
on the router.
|
|
0:00:43
|
Now in the Catalyst QoS, there's going to be a multiple stage
|
|
0:00:47
|
process that we are classifying packets as they come inbound
|
|
0:00:51
|
and queuing them as they come inbound
|
|
0:00:54
|
then queuing packets as they go outbound to leave either
|
|
0:00:59
|
our access ports or to our trunk ports.
|
|
0:01:02
|
Now we'll see that the biggest thing that we need to worry about
|
|
0:01:05
|
with the Catalyst QoS is to make sure that the classification
|
|
0:01:09
|
is correct as we are receiving traffic from the access layer
|
|
0:01:13
|
and then forwarding it upstream to our other
|
|
0:01:15
|
Layer 2 neighbors in which case the switch internally
|
|
0:01:20
|
uses its own quality of service label in order to make sure
|
|
0:01:24
|
that the value is properly passed between its different
|
|
0:01:26
|
interfaces.
|
|
0:01:30
|
Now configuration wise, the first thing that we would
|
|
0:01:33
|
do on the switches is enable the MLS QoS process
|
|
0:01:39
|
which means that it is going to allow the switch to classify
|
|
0:01:42
|
traffic as it is coming in and then schedule the
|
|
0:01:45
|
traffic as it is going out.
|
|
0:01:49
|
So without MLS QoS on, the switch is basically going to be
|
|
0:01:53
|
providing no QoS, it's going to be doing just best effort
|
|
0:01:56
|
switching, so whereas with the routers, there's no specific
|
|
0:02:00
|
command to enable the QoS process, in the case of the switches there are
|
|
0:02:04
|
we do need to say MLS QoS globally.
|
|
0:02:08
|
So the first step when we look at the work flow from packets
|
|
0:02:12
|
entering the switch versus leaving, first is the switch is going to
|
|
0:02:15
|
classify and mark the traffic as it's coming inbound.
|
|
0:02:19
|
So this is either based on the configuration at the individual
|
|
0:02:23
|
port like the trust boundary or the service policy that we
|
|
0:02:28
|
have configured at the link level or at the VLAN level.
|
|
0:02:32
|
So we'll see there's a couple different ways that we can
|
|
0:02:34
|
do the marking and classification either at the port or at the
|
|
0:02:37
|
Layer 2 VLAN.
|
|
0:02:41
|
We could then configure policing which could either be
|
|
0:02:45
|
used to transmit or drop the traffic or remark it
|
|
0:02:48
|
to a new value whether this be the IP precedence or
|
|
0:02:53
|
the DSP or the Layer 2 class of service.
|
|
0:02:59
|
Now what's different about the switch's versus the
|
|
0:03:01
|
router's QoS is that there is an input scheduling
|
|
0:03:05
|
algorithm that we can change that is effectively
|
|
0:03:09
|
inbound queuing on the interface.
|
|
0:03:11
|
For the router's mechanisms we saw up to this point, we
|
|
0:03:13
|
were only doing outbound queuing where for the switch
|
|
0:03:17
|
we can change both the inbound and the outbound queuing.
|
|
0:03:21
|
For the outbound queuing there's not as much configuration
|
|
0:03:24
|
that we have. We can map the traffic to one of four different queues
|
|
0:03:29
|
and we can apply some other miscellaneous features like
|
|
0:03:32
|
prioritization which is the same logic as the strict
|
|
0:03:36
|
priority of the low latency queue on the routers.
|
|
0:03:42
|
Now once we enable the QoS process on the switch
|
|
0:03:45
|
it's important to note that the switch will drop all
|
|
0:03:48
|
markings for all packets that are received inbound.
|
|
0:03:54
|
So this means that regardless of what the application is setting
|
|
0:03:56
|
or regardless of what other routers in the transit path
|
|
0:04:00
|
are doing the classification, the switch is going to rewrite
|
|
0:04:02
|
everything to zero when it is received inbound.
|
|
0:04:06
|
The idea behind this is that we would manually define
|
|
0:04:10
|
what is known as the trust boundary where the trust boundary
|
|
0:04:15
|
is going to control whether we honor or reset the marking as it is
|
|
0:04:19
|
coming inbound.
|
|
0:04:23
|
So either at the link level we would say mls qos trust
|
|
0:04:26
|
or in global config, we can simply disable the QoS
|
|
0:04:29
|
rewrite which means that we would not need to
|
|
0:04:32
|
then define the individual trust boundaries.
|
|
0:04:36
|
So depending on where the switches are placed in the network
|
|
0:04:39
|
if the switches are on our Layer 2 access
|
|
0:04:42
|
so connecting down to the end host, connecting
|
|
0:04:44
|
to the IP phones generally we would want to define
|
|
0:04:48
|
on a per port basis what the trust boundary is
|
|
0:04:52
|
to make sure that the end hosts' applications are not
|
|
0:04:56
|
trying to get their traffic put into different queues
|
|
0:04:58
|
by doing different types of markings.
|
|
0:05:01
|
So for example, on your end host you could configure to
|
|
0:05:05
|
send all of its traffic as DSCP EF
|
|
0:05:08
|
even if it was web browsing and FTP and bit torrent
|
|
0:05:12
|
which means it's going to try to get into the priority queues
|
|
0:05:15
|
or to the low drop probability queues as we're doing things
|
|
0:05:19
|
like random detection.
|
|
0:05:22
|
So ideally, to enforce the end to end QoS model, we want to make sure
|
|
0:05:26
|
that the traffic is not being marked as some value that it should not
|
|
0:05:29
|
be processed as and this is what the trust boundary is going to be
|
|
0:05:33
|
used to define, so we could say that for links that connect to the phones
|
|
0:05:38
|
tell the phone what to remark its traffic that is coming from the
|
|
0:05:42
|
PC as behind it and the phone's traffic itself is going to be treated
|
|
0:05:47
|
as priority which is going to be DSCP EF
|
|
0:05:55
|
Now we'll see that there's kind of an indirect way that we need to do
|
|
0:05:57
|
this on the switches which is known as the quality of service
|
|
0:06:01
|
mutation map that maps values as they come in as either class of
|
|
0:06:07
|
service, DSCP or IP precedence and matches them to other
|
|
0:06:12
|
DSCP class of service or IP precedence values or more
|
|
0:06:16
|
importantly to different output queues.
|
|
0:06:19
|
So it's not as simple as on the router where we are doing
|
|
0:06:21
|
classification inbound and then we can apply a service
|
|
0:06:25
|
policy out that's doing the low latency queuing or bandwidth reservation
|
|
0:06:29
|
or random detection. On the switches we may need to make sure that the
|
|
0:06:34
|
classification is correct inbound and based on that, we are going to
|
|
0:06:39
|
select what is the outbound queue, but the key is that
|
|
0:06:43
|
the configuration happens at the input.
|
|
0:06:47
|
So if the IP precedence is zero for example, when the switch
|
|
0:06:52
|
receives that in, that value of zero is going to affect
|
|
0:06:55
|
what is the output queue on the different interfaces.
|
|
0:06:59
|
So if the trust boundary is not configured right, it
|
|
0:07:02
|
ultimately means that the egress queuing on the links is not going to be
|
|
0:07:04
|
the right values.
|
|
0:07:09
|
Now if we did want to change the markings of the packets,
|
|
0:07:13
|
we could do this with a service policy that is applied either at the
|
|
0:07:17
|
interface level or at the VLAN level
|
|
0:07:20
|
where classification could be done with either an access list
|
|
0:07:24
|
or a class map
|
|
0:07:26
|
or excuse me, an access list in conjunction with a class map.
|
|
0:07:29
|
So the access list is going to match whatever values either
|
|
0:07:33
|
the source address, destination address, the Layer 4 protocol
|
|
0:07:38
|
like TCP, UDP, the port numbers
|
|
0:07:42
|
and once the traffic is classified, then we could remark it
|
|
0:07:46
|
with either set precedence or set dscp as it is coming inbound.
|
|
0:07:52
|
Now as I mentioned, we can also do the classification
|
|
0:07:54
|
on a per VLAN basis which is essentially just a shortcut
|
|
0:07:58
|
to apply the service policy to all Layer 2 access ports that
|
|
0:08:03
|
are in that VLAN, but not having to apply the service policy
|
|
0:08:07
|
over and over and over at the interface level.
|
|
0:08:12
|
So what this allows you to do is essentially change the
|
|
0:08:15
|
access VLAN assignment without having to worry what particular
|
|
0:08:19
|
QoS policy is applied onto the link.
|
|
0:08:22
|
So if the link is configured for access VLAN 10, it means it's going to
|
|
0:08:26
|
get the service policy that is applied on interface VLAN 10
|
|
0:08:29
|
but if we change it to access VLAN 20, then it's going to get the
|
|
0:08:33
|
policy that is applied on VLAN 20
|
|
0:08:35
|
So another key point of this that is different from the
|
|
0:08:39
|
normal port based classification again is that it's going to affect
|
|
0:08:43
|
all interfaces that are in that particular VLAN
|
|
0:08:50
|
So we'll see that there's again there's a limitation as to
|
|
0:08:53
|
what particular actions that you can actually apply
|
|
0:08:55
|
on the inbound policies versus the outbound policies
|
|
0:09:00
|
and it's a much smaller subset versus what the router has.
|
|
0:09:03
|
So if you are comfortable with the router's QoS policies that we
|
|
0:09:07
|
talked about up to this point, it's really not that much further of a
|
|
0:09:10
|
stretch in order to implement the Catalyst QoS.
|
|
0:09:16
|
Now another input feature we can configure is policing
|
|
0:09:19
|
same type of logic as we configured on the router's IOS
|
|
0:09:23
|
the difference is that now we have the notion of an aggregate
|
|
0:09:26
|
policer that could be applied to multiple physical interfaces
|
|
0:09:31
|
or multiple classes at the same time.
|
|
0:09:35
|
So if I say that hosts A, B and C that are on switch ports
|
|
0:09:39
|
A, B and C are in the same aggregate policer
|
|
0:09:44
|
then it doesn't matter how much bandwidth host A is sending versus
|
|
0:09:47
|
B versus C as long as as a whole, they do not
|
|
0:09:52
|
exceed what the aggregate rate is that we're configuring.
|
|
0:09:58
|
So depending on what particular links we apply the aggregate policer
|
|
0:10:03
|
there's no way that we can individually control
|
|
0:10:05
|
them, we want host A to be limited to a different rate than host B
|
|
0:10:08
|
Now if we wanted to do that, we could simply apply it per
|
|
0:10:11
|
port, but the aggregate policer is meant to do it as a shared
|
|
0:10:17
|
policing value between multiple interfaces.
|
|
0:10:20
|
As one of the actions for the policing, we can also change
|
|
0:10:24
|
the DSCP value, but the action for this is going to be
|
|
0:10:28
|
a little bit different because the remarking is going to be
|
|
0:10:31
|
based on another QoS map.
|
|
0:10:35
|
So it's not directly set inside of the policy. It says to check
|
|
0:10:39
|
the policed DSCP map
|
|
0:10:42
|
which again essentially is going to be used to figure out
|
|
0:10:45
|
what is the egress queue for the traffic as it leaves
|
|
0:10:48
|
out another interface.
|
|
0:10:52
|
Now one of the shortcuts we'll also look at on the switches
|
|
0:10:55
|
is that you can enable the auto QoS feature
|
|
0:10:58
|
or the smart port macro that is for a particular QoS template
|
|
0:11:04
|
and based on that, you can see a lot of how these
|
|
0:11:07
|
different pieces of syntax fit together and you could
|
|
0:11:12
|
essentially change around what the defaults are
|
|
0:11:14
|
in order to get the particular behavior that you're looking for
|
|
0:11:17
|
or specifically in our case, what the particular question is asking us
|
|
0:11:21
|
to solve. Now once we figure out the correct classification
|
|
0:11:25
|
as the traffic comes inbound or the correct policing rate as the
|
|
0:11:28
|
traffic comes inbound, then we need to figure out which of
|
|
0:11:32
|
the four output queues are the packets going to be placed
|
|
0:11:36
|
into, so on a per port basis, we have four egress queues
|
|
0:11:41
|
that are running a queuing algorithm that's known as shaped
|
|
0:11:44
|
round robin. Now the key point is that the queues
|
|
0:11:49
|
are correspond to the DSCP and class of service
|
|
0:11:53
|
mappings, so DSCP values 0, 1, 2, 3 for example
|
|
0:11:59
|
could be mapped to queue 1 where DSCP values 4, 5, 6
|
|
0:12:03
|
they can be mapped to queue number 2
|
|
0:12:06
|
so then as we're saying when the packets come inbound
|
|
0:12:10
|
since we are either on a ring or remarking their classification
|
|
0:12:15
|
this is ultimately going to follow what is DSCP to queue mapping
|
|
0:12:21
|
or the class of service to queue mapping
|
|
0:12:23
|
to control how the traffic is processes as it leaves the interface.
|
|
0:12:29
|
Now we also use a modified version of the normal queue depth dropping
|
|
0:12:35
|
that would be inherent to first in first out queuing
|
|
0:12:38
|
or weighted fair queuing which is known as weighted tail drop.
|
|
0:12:43
|
So it's not a random dropping procedure like random detection
|
|
0:12:47
|
but it is weighted based on the different class of service values.
|
|
0:12:51
|
Now the shaped round robin queuing outbound
|
|
0:12:54
|
is a change to some of the lower or older Catalyst IOS platforms that
|
|
0:12:59
|
used the weighted round robin, so what this allows us
|
|
0:13:03
|
to do is specify the relative weighting on the individual
|
|
0:13:08
|
queues essentially to give more bandwidth preference
|
|
0:13:12
|
to one type of traffic flows versus another.
|
|
0:13:17
|
So again, based on the DSCP values that are being received or
|
|
0:13:20
|
marked inbound, we put that traffic into a specific egress queue
|
|
0:13:26
|
then based on the shaped round robin weightings
|
|
0:13:28
|
we can control what bandwidth share they're going to get of the interface.
|
|
0:13:34
|
So this can be supported on an individual queue basis or as to the
|
|
0:13:38
|
port as a whole.
|
|
0:13:41
|
Now shaping just like it does on the routers
|
|
0:13:44
|
is going to delay the packets in order to send them to
|
|
0:13:50
|
achieve whatever the target rate is.
|
|
0:13:53
|
So with shaping on the interface we're trying to achieve an average
|
|
0:13:56
|
that is lower than the normal serialization of the link.
|
|
0:14:01
|
So if we're shaping on a Fast Ethernet interface, it means that the
|
|
0:14:04
|
serialization is going to be a 100 Megabits per second
|
|
0:14:07
|
and the shaped rate is going to be something lower than that
|
|
0:14:11
|
so we're essentially controlling how often do we release traffic
|
|
0:14:16
|
from the output queue onto the transmit ring which again is the
|
|
0:14:19
|
hardware queue of the interface.
|
|
0:14:25
|
Now for the egress queuing, the queues are going to have
|
|
0:14:29
|
two possible properties.
|
|
0:14:31
|
Either a shared queue or a shaped queue.
|
|
0:14:35
|
The difference is that with the shared queues
|
|
0:14:39
|
the weighting of the bandwidth values is going to be relative to the
|
|
0:14:43
|
other queues.
|
|
0:14:45
|
So the four queues are going to share what is the available
|
|
0:14:47
|
bandwidth total and we can configure the weighting of
|
|
0:14:51
|
one queue versus the other three to prefer the first
|
|
0:14:54
|
one versus the others.
|
|
0:14:57
|
Now the shaped round robin means that the bandwidth is
|
|
0:15:01
|
going to be guaranteed.
|
|
0:15:03
|
So in shared, technically it's not guaranteed it's going to be based
|
|
0:15:07
|
on whatever is available, so it's a relative weighting.
|
|
0:15:10
|
But in shaped round robin, it's going to be a guarantee based on
|
|
0:15:13
|
what weighting that we manually configure.
|
|
0:15:17
|
So whatever bandwidth that we are assigning
|
|
0:15:20
|
that's going to be subtracted from what's the total available
|
|
0:15:23
|
bandwidth on the link.
|
|
0:15:27
|
So the other queues that are not the shaped queues
|
|
0:15:30
|
are essentially going to get whatever's left over
|
|
0:15:32
|
from what we are previously allocating.
|
|
0:15:38
|
So the configuration syntax can get a little bit complicated
|
|
0:15:41
|
here with the bandwidth share versus the bandwidth shape.
|
|
0:15:46
|
We'll see again once we configure the auto QoS
|
|
0:15:49
|
most of these defaults are going to show up as
|
|
0:15:52
|
minor modifications.
|
|
0:15:55
|
So we'll be able to see what is the difference between the
|
|
0:15:57
|
share syntax versus the shaping syntax.
|
|
0:16:01
|
Then the other additional feature we can configure
|
|
0:16:03
|
as output queuing is prioritization.
|
|
0:16:09
|
So the priority queue generally this is going to be for our voice
|
|
0:16:12
|
or video flows where normally we would want this to correspond
|
|
0:16:16
|
to DSCP EF
|
|
0:16:19
|
So when we look at the default DSCP to queue ID mappings
|
|
0:16:24
|
DSCP 46 does automatically map to queue number 1
|
|
0:16:30
|
so as long as we configure the priority queue out command
|
|
0:16:32
|
at the link level and the classification is correct for the
|
|
0:16:36
|
input interfaces, it means that the voice traffic should automatically be
|
|
0:16:41
|
in the priority queue.
|
|
0:16:44
|
Now there is no policing that applies to this, so if there's a
|
|
0:16:48
|
bunch of traffic that's in the priority queue
|
|
0:16:50
|
it could potentially starve or preempt all of the other
|
|
0:16:53
|
non-priority queues.
|
|
0:16:56
|
So typically you would only want your voice phone calls to be
|
|
0:16:59
|
in here. You don't want any large data flows to be there.
|
|
0:17:03
|
So here we see an example of doing both the shaping
|
|
0:17:06
|
and the sharing at the same time which means that the first
|
|
0:17:11
|
queue is going to be guaranteed a relative weighting of 10 versus the
|
|
0:17:16
|
other ones and this is based on the speed of the
|
|
0:17:22
|
interface being 10 Megabits per second, so again you
|
|
0:17:24
|
do need to take that into account what's the serialization of the link.
|
|
0:17:28
|
If it's 10, 100, 1000 depending on whether
|
|
0:17:32
|
it's negotiating to either those three values to GIG Fast Ethernet
|
|
0:17:36
|
or regular Ethernet, that's ultimately going to affect what the
|
|
0:17:39
|
queuing values are going to be.
|
|
0:17:42
|
Now the weights are still going to be relative
|
|
0:17:44
|
so the syntax wise, it's not really going to matter
|
|
0:17:48
|
whether we're configuring this on GIG Ethernet or Fast Ethernet
|
|
0:17:53
|
but if you're trying to get let's say 1 Megabit per second
|
|
0:17:57
|
for particular type of traffic, then you may need to
|
|
0:17:59
|
hard code the speed to drop it down to 10 Meg
|
|
0:18:03
|
because that's ultimately is changing the serialization.
|
|
0:18:08
|
So this is different than in the router's QoS where we were
|
|
0:18:10
|
using the bandwidth command at the interface
|
|
0:18:13
|
the bandwidth command is not affecting anything of the
|
|
0:18:15
|
physical hardware queue
|
|
0:18:17
|
where the speed does because it changes the transmit ring
|
|
0:18:21
|
where the transmit ring is either for 10 Megabit per second
|
|
0:18:25
|
Ethernet, 100 Megabit per second Fast Ethernet, GIGE or 10 GIGE
|
|
0:18:31
|
We'll also see the mapping tables again these DSCP
|
|
0:18:36
|
to queue ID mappings and the output the class of service
|
|
0:18:39
|
to queue ID mappings these are going to control what particular
|
|
0:18:42
|
types of packets get into each of the four queues.
|
|
0:18:46
|
Now for IP version 4 and IPV6 packets
|
|
0:18:50
|
we're going to use the DSCP values by default
|
|
0:18:53
|
to get them into the queues.
|
|
0:18:55
|
For any non-ip packets, we're going to use the class of service value.
|
|
0:19:00
|
So even if this is not on a trunk interface because again
|
|
0:19:04
|
only the dot1q or the ISL header actually have the
|
|
0:19:07
|
class of service value. The switch is using its own
|
|
0:19:11
|
locally significant internal marking to carry a class of service
|
|
0:19:16
|
value between its interfaces.
|
|
0:19:18
|
So it's kind of confusing here because even though the class of service
|
|
0:19:21
|
is only in the trunking header, the switch is making its own
|
|
0:19:25
|
internal marking between links, so it's kind of like a
|
|
0:19:29
|
locally significant value that's using just as a placeholder.
|
|
0:19:33
|
So let's take a look at this on the command line here.
|
|
0:19:37
|
Now again, the key to remember with the
|
|
0:19:40
|
Catalyst IOS and the QoS configurations
|
|
0:19:44
|
is that the Layer 3 diagram we see here it's not really
|
|
0:19:49
|
going to be a good indication of as to what's going on
|
|
0:19:51
|
in the underlying Layer 2 network.
|
|
0:19:54
|
And the Catalyst QoS is meant to be a Layer 2 QoS
|
|
0:19:58
|
not really a Layer 3 QoS like we're applying on the routers.
|
|
0:20:03
|
So the QoS could be applied between switch ports or between
|
|
0:20:06
|
trunk ports. It could technically be applied on native Layer 3
|
|
0:20:10
|
routed interfaces, but mainly it's when the interface is in switch port mode.
|
|
0:20:16
|
So if we were to look at the link between routers 1, 4 and 6
|
|
0:20:21
|
we need to keep in mind that this is not a physical
|
|
0:20:24
|
connection between these devices.
|
|
0:20:26
|
There's some sort of Layer 2 switches in the middle.
|
|
0:20:30
|
Where specifically in our case, Router 1 is connecting
|
|
0:20:33
|
to Switch 1's port Fast Ethernet 0/1
|
|
0:20:40
|
where Router 4 is connecting to Switch 4's port Fa 0/4
|
|
0:20:48
|
and Router 6 is connecting to Switch 2
|
|
0:20:53
|
Switch 2's port Fast Ethernet 0/6
|
|
0:20:59
|
so let's draw this out in a new diagram
|
|
0:21:02
|
so we can figure out what is the actual physical transit path
|
|
0:21:05
|
between the different devices.
|
|
0:21:11
|
So we have Router 6
|
|
0:21:15
|
Router 6 that is connecting to Switch 2
|
|
0:21:21
|
and on Switch 2, that's Fast Ethernet 0/6
|
|
0:21:25
|
we have Router 4
|
|
0:21:29
|
that is connecting to Switch 4
|
|
0:21:33
|
that's FA 0/4
|
|
0:21:36
|
then Router 1 that is connecting to Switch 1
|
|
0:21:42
|
and that's Fast Ethernet 0/1
|
|
0:21:47
|
Now in order to properly pass the classification between these
|
|
0:21:49
|
three routers, if we're doing Layer 2 QoS in the middle
|
|
0:21:53
|
we need to know what is the physical trunking
|
|
0:21:56
|
configuration between the devices.
|
|
0:22:00
|
So let's quickly go to Switch 1
|
|
0:22:03
|
and let's look at the show interface trunk
|
|
0:22:07
|
and essentially every possible link is trunking here.
|
|
0:22:12
|
So they're all configured as dynamic desirable ports
|
|
0:22:15
|
they have negotiated ISL trunking
|
|
0:22:18
|
this means that when we do our Layer 2 QoS
|
|
0:22:22
|
we would need to take into account that between Switch 1
|
|
0:22:25
|
and Switch 2 we have interfaces Fast Ethernet 13 to 15
|
|
0:22:32
|
between Switch 1 and Switch 4
|
|
0:22:36
|
here I have Fast Ethernet 0/19 to 21
|
|
0:22:41
|
I have 13 to 15 here
|
|
0:22:45
|
13 to 15 here
|
|
0:22:50
|
then 19 to 21
|
|
0:22:53
|
and 16 to 18
|
|
0:22:59
|
so this is then going to affect what are the trust boundaries
|
|
0:23:01
|
between the switches to figure out whether they are
|
|
0:23:04
|
either going to strip or honor each other's markings
|
|
0:23:08
|
on the links.
|
|
0:23:12
|
Now to simplify this here, what we're going to do is actually
|
|
0:23:14
|
remove Router 4 from the topology
|
|
0:23:19
|
because in my particular network, Switch 4 is not
|
|
0:23:22
|
a 3560, it's a 3550
|
|
0:23:26
|
and the QoS configuration is going to be a little bit different
|
|
0:23:31
|
so I want to make sure we're focusing on just that specific platform.
|
|
0:23:43
|
Now to start, let's look at Router 1
|
|
0:23:46
|
and configure it to change its markings for packets
|
|
0:23:50
|
that are leaving its interface going towards that VLAN 146 segment.
|
|
0:23:55
|
So right now if we show run interface Fast Ethernet 0/0
|
|
0:24:00
|
I have a service policy applied output that is called shape.
|
|
0:24:04
|
If we show policy map shape
|
|
0:24:09
|
It says the in the class default I'm doing traffic shaping
|
|
0:24:14
|
to 25 Megabits per second.
|
|
0:24:16
|
Now that's fine in this case because we're not going to
|
|
0:24:18
|
generate testing traffic that's more than 25 Megs
|
|
0:24:21
|
but also what I want to do inside of policy map shape
|
|
0:24:26
|
for class class-default
|
|
0:24:30
|
I'm going to set the DSCP
|
|
0:24:36
|
let's say to af11
|
|
0:24:40
|
Now what I want to do is go to Router 6
|
|
0:24:45
|
and watch for traffic as it comes inbound
|
|
0:24:50
|
because now any packet that Router 1 sends
|
|
0:24:52
|
out onto this segment it should be marked as AF11
|
|
0:24:58
|
When Router 6 receives this inbound, if it's not getting a
|
|
0:25:02
|
classification match on that particular value
|
|
0:25:05
|
that's going to tell us that the Layer 2 switches are
|
|
0:25:08
|
stripping that DSCP
|
|
0:25:14
|
So now on Router 6 we're going to account for this
|
|
0:25:16
|
inbound.
|
|
0:25:24
|
So on our Ethernet sub interface Fast Ethernet 0/0.146
|
|
0:25:27
|
an easy way we can do this is just to create an access list
|
|
0:25:32
|
we'll say access list 100 permit ip any any of dscp af11
|
|
0:25:39
|
then access list 100 is going to permit anything else.
|
|
0:25:45
|
So we're not using it to filter out any traffic. We're
|
|
0:25:47
|
basically just using it as a packet counter.
|
|
0:25:49
|
Then ip access group 100 inbound
|
|
0:25:56
|
so now on Router 1
|
|
0:25:58
|
let's do a trace route to Router 6's loopback
|
|
0:26:02
|
we see it's going directly over that one hop
|
|
0:26:06
|
so if the marking policy is correct on Router 6
|
|
0:26:10
|
we should be able to look at the show access list
|
|
0:26:13
|
and see there are hits on af11 which there are.
|
|
0:26:18
|
If I were to go to Router 1
|
|
0:26:20
|
and let's say we'll do an extended ping
|
|
0:26:24
|
to Router 6's loopback that has a high repeat count
|
|
0:26:27
|
let's say whatever the maximum value is here
|
|
0:26:32
|
on Router 6 if we look at the show access list, we should see that
|
|
0:26:36
|
these hits are constantly going to go up.
|
|
0:26:44
|
Now our next step in the Layer 2 transit path
|
|
0:26:47
|
so on Switch 1 and Switch 2
|
|
0:26:49
|
would be to turn the QoS process on.
|
|
0:26:53
|
So on Switch 1 in global config we'll say mls qos
|
|
0:26:57
|
Once we do this, what we should see on Router 6 is that
|
|
0:27:01
|
the packet counter for af11
|
|
0:27:04
|
is no longer going to go up.
|
|
0:27:07
|
We see now all those pings are falling back to the default match
|
|
0:27:11
|
of permit ip any any
|
|
0:27:14
|
Specifically if I were to put another access list entry here
|
|
0:27:19
|
let's say access list or ip access list extended
|
|
0:27:24
|
100 sequence number 5 permits ip any any with a
|
|
0:27:28
|
dscp of default
|
|
0:27:31
|
which is essentially zero.
|
|
0:27:33
|
When we look at show access list, now these packets are dscp
|
|
0:27:38
|
default, not af11
|
|
0:27:44
|
so what this is telling us is that as soon as Switch 1
|
|
0:27:47
|
it turns the QoS process on
|
|
0:27:50
|
it is going to be stripping the markings.
|
|
0:27:53
|
Now again, there's two ways that we can fix this.
|
|
0:27:55
|
We can either tell the switch to not rewrite the dscp values
|
|
0:28:01
|
or we could configure the trust boundaries
|
|
0:28:04
|
to say that as packets are coming in that particular interface
|
|
0:28:07
|
I want to honor and not remark
|
|
0:28:10
|
the DSCP value.
|
|
0:28:14
|
So first on Switch 1, let's simply disable the process.
|
|
0:28:18
|
Under global config, we'll say no mls qos rewrite.
|
|
0:28:24
|
the ip dscp field
|
|
0:28:28
|
Now on Router 6 when we look at the access list
|
|
0:28:31
|
we see that now the counter of the second line which is af11
|
|
0:28:36
|
is going up.
|
|
0:28:40
|
So now the DSCP is not being stripped.
|
|
0:28:43
|
If I were to go to Switch 2 who is connected from Switch 1
|
|
0:28:49
|
to Switch 2 and then down to Router 6
|
|
0:28:51
|
once Switch 2 configures mls qos
|
|
0:28:55
|
then likewise now the values are going to be stripped again.
|
|
0:28:59
|
So now the counter is going up on the default DSCP
|
|
0:29:03
|
not the af11
|
|
0:29:07
|
If I wanted to honor this particular marking
|
|
0:29:10
|
on Switch 2, I would need to figure out what are the
|
|
0:29:14
|
inbound interfaces for that particular Layer 2 VLAN
|
|
0:29:19
|
So if we look at the show spanning tree for VLAN 146
|
|
0:29:26
|
this is going to control at the port level where the particular
|
|
0:29:32
|
trust should be applied.
|
|
0:29:36
|
So in the case of Switch 2, the root port is Fast Ethernet 16
|
|
0:29:42
|
so even though there's those physical links that are connecting
|
|
0:29:46
|
between Switch 1 and Switch 2
|
|
0:29:48
|
that's not where the traffic is actually forwarding.
|
|
0:29:51
|
So the topology is going to be a little bit more complicated
|
|
0:29:54
|
it's going to look
|
|
0:29:57
|
like this where Router 6 is going to Switch 2
|
|
0:30:03
|
Router 1 is going to Switch 1
|
|
0:30:07
|
then Switch 2 says that its root port is Fast Ethernet 16
|
|
0:30:14
|
where Fast Ethernet 16 goes to Switch 3
|
|
0:30:22
|
then from Switch 3 if we look at the same thing
|
|
0:30:25
|
if we show spanning tree for VLAN 146
|
|
0:30:31
|
Switch 3 says I'm the root.
|
|
0:30:33
|
This means that interface 13 is forwarding down to Switch 1
|
|
0:30:40
|
and Switch 1 should be using this as the root port because that's
|
|
0:30:43
|
the lowest number interface basically has the lowest port
|
|
0:30:47
|
ID that is going to Switch 3
|
|
0:30:50
|
So in Switch 1 we should see Fast Ethernet 16 as the root port
|
|
0:30:57
|
which we do.
|
|
0:30:59
|
Ok, root port is Fast Ethernet 0/16
|
|
0:31:02
|
so now this means that the traffic is actually forwarding
|
|
0:31:06
|
out to Switch 3 first
|
|
0:31:09
|
before it can go to Router 6 or to Router 1
|
|
0:31:16
|
Now the reason that this is significant is that it's going to
|
|
0:31:18
|
affect what is the interface that should be trusted
|
|
0:31:21
|
on Switch 2
|
|
0:31:24
|
It means that port 16 would need to have the DSCP
|
|
0:31:28
|
trusted in order for the marking to maintain from Router 2
|
|
0:31:32
|
all the way to Router 6
|
|
0:31:38
|
So in our next step let's go to Switch 2
|
|
0:31:40
|
and say on interface Fast Ethernet 16
|
|
0:31:43
|
mls qos trust
|
|
0:31:46
|
and I want to trust the dscp
|
|
0:31:52
|
We could also specify here mls qos trust device
|
|
0:32:01
|
then we would look for an IP phone based on cdp
|
|
0:32:07
|
so for example, 7960 phone is plugged into the switch’s
|
|
0:32:11
|
access port, it's going to be able to figure that out based on
|
|
0:32:14
|
CDP, then dynamically decide whether it's going to trust
|
|
0:32:19
|
the markings coming in that port or whether it's going to
|
|
0:32:21
|
automatically remark them.
|
|
0:32:23
|
So now if we look on Router 6 and look at the show access lists
|
|
0:32:27
|
we should see now that the middle entry which is af11
|
|
0:32:32
|
is the one that's getting hits.
|
|
0:32:37
|
So now the values have been maintained end to end.
|
|
0:32:45
|
So next let's look at a case where we are going to remark the
|
|
0:32:47
|
traffic. On Router 6 I need to account for this new marking.
|
|
0:32:53
|
We'll say ip access list extended 100
|
|
0:32:58
|
sequence number 15 is going to permit ip any any
|
|
0:33:02
|
of dscp value let's say af42
|
|
0:33:11
|
Now there's a couple different places where we could do this remarking.
|
|
0:33:15
|
We could do it on Switch 1 as it comes in
|
|
0:33:21
|
Fast Ethernet 1
|
|
0:33:22
|
We could do it on Switch 2 as it comes in Fast Ethernet 16
|
|
0:33:31
|
We could manually do it as it's going out towards
|
|
0:33:34
|
Router 6 or out on the trunk port
|
|
0:33:37
|
from Switch 1 to Switch 3
|
|
0:33:40
|
or we could configure it with a mutation map.
|
|
0:33:47
|
We could also configuring it through policing.
|
|
0:33:52
|
So first let's look at applying this just with the
|
|
0:33:56
|
the policy with a policy map.
|
|
0:33:58
|
So on Switch 1
|
|
0:34:00
|
we'll create a class map.
|
|
0:34:02
|
We'll say class map R1
|
|
0:34:06
|
that matches -- and we can see there's not as many things
|
|
0:34:11
|
that we can match. We could say match ip dscp
|
|
0:34:15
|
ip precedence we can match an access list.
|
|
0:34:19
|
We could match the Layer 3 packet length.
|
|
0:34:24
|
Again, if we look at match protocol, it's not as detailed as the
|
|
0:34:26
|
Nbar on the routers.
|
|
0:34:29
|
So mainly we're just looking at the Layer 3 classification. Either the
|
|
0:34:32
|
dscp or the ip precedence.
|
|
0:34:35
|
So let's say that we're going to match dscp or match
|
|
0:34:40
|
ip dscp
|
|
0:34:44
|
af11
|
|
0:34:49
|
then we have a policy map that is -- we'll say from
|
|
0:34:56
|
from Router 1
|
|
0:34:58
|
it says if it's class R1
|
|
0:35:01
|
we're going to set the dscp
|
|
0:35:06
|
so I'm going to remark this to af42
|
|
0:35:12
|
then at the link level, so interface Fast Ethernet 0/1
|
|
0:35:16
|
service policy input is from Router 1
|
|
0:35:21
|
So the same exact logic as the router's IOS
|
|
0:35:25
|
only difference is that we don't have as many options
|
|
0:35:28
|
under the class map or the policy map.
|
|
0:35:31
|
If we look at the change on Router 6, ideally we should see
|
|
0:35:34
|
this being marked as af42 now.
|
|
0:35:42
|
So right now we do not see it. It says it's still coming in
|
|
0:35:45
|
as af11
|
|
0:35:49
|
So let's look at Switch 1 let's say show policy map
|
|
0:35:56
|
It says if class R1 is true set af to 42
|
|
0:36:01
|
If we show
|
|
0:36:03
|
class map, class map R1 says match ip dscp af11
|
|
0:36:12
|
which
|
|
0:36:23
|
is what we should be setting in on or setting out from
|
|
0:36:27
|
Router 1
|
|
0:36:32
|
so let's see is that applied on the link level? It is
|
|
0:36:36
|
applied in from Router 1 we may need to re-enable
|
|
0:36:39
|
the marking, so previously I said don't do the rewriting
|
|
0:36:49
|
Let's see if now on Router 6 now it's matching it.
|
|
0:36:54
|
So not only does this mean don't do the default remarking
|
|
0:36:58
|
this would also be if we want to apply a policy onto the interface.
|
|
0:37:04
|
So as long as you define your trust boundaries manually
|
|
0:37:06
|
or defining your markings manually, then there's no
|
|
0:37:09
|
reason to remove the dscp rewrite.
|
|
0:37:13
|
The only case you would want to do this is basically you
|
|
0:37:17
|
you want to run some basic QoS on the switch
|
|
0:37:20
|
but you don't want to do any new classification
|
|
0:37:24
|
or any new markings.
|
|
0:37:26
|
So whatever the value that was passed into the
|
|
0:37:28
|
switch, that's what the switch is going to use.
|
|
0:37:33
|
Now another way that we can apply this remarking
|
|
0:37:35
|
here is with the policing action of the Catalyst QoS
|
|
0:37:40
|
and specifically the policed dscp transmit exceed action
|
|
0:37:46
|
that is different from the previous router's IOS
|
|
0:37:49
|
implementation of policing that we saw before.
|
|
0:37:52
|
Now one thing that can be kind of confusing about how this is
|
|
0:37:55
|
implemented is that when we configure the policing on a per port
|
|
0:38:00
|
basis and we specify that the exceed action is the policed
|
|
0:38:04
|
dscp transmit, we are then going to look at the global
|
|
0:38:08
|
policed dscp mutation map
|
|
0:38:11
|
that is going to define what is the incoming dscp
|
|
0:38:15
|
and then what is the value that it is going to be changed to
|
|
0:38:18
|
if it exceeds whatever the particular policing value that
|
|
0:38:21
|
we are defining.
|
|
0:38:24
|
Now again, in our particular application here
|
|
0:38:27
|
if we were to look at the topology, we have Router 1
|
|
0:38:31
|
right now sending packets into Switch 1 that are marked as
|
|
0:38:36
|
AF11
|
|
0:38:39
|
Switch 1 on its direct link that's connecting to Router 1
|
|
0:38:42
|
previously it was applying a service policy that said
|
|
0:38:45
|
as these packets come in, we're simply going to remark
|
|
0:38:48
|
them to af42
|
|
0:38:51
|
and we do that simply by setting the dscp value
|
|
0:38:54
|
under the particular policy map.
|
|
0:38:59
|
Now with the police dscp typically what this is used
|
|
0:39:01
|
for is to apply two different levels of service
|
|
0:39:06
|
similar to the three rate policer that we saw in the
|
|
0:39:09
|
router's IOS before, so we would say that up to a certain
|
|
0:39:13
|
value, your traffic is going to be allowed to come into the network
|
|
0:39:16
|
with its current marking, then if you exceed
|
|
0:39:19
|
whatever the threshold that we specify
|
|
0:39:21
|
we are going to mark your traffic down so that the QoS
|
|
0:39:24
|
behavior is going to change, so maybe up to 1 Megabit per second
|
|
0:39:28
|
you're going to get guaranteed forwarding, but then anything above that
|
|
0:39:31
|
is going to get best effort or anything above that could
|
|
0:39:33
|
potentially be dropped.
|
|
0:39:35
|
Now syntax wise we'll see that there's one important change
|
|
0:39:39
|
here that we need to not only apply the policing
|
|
0:39:42
|
to the traffic, but we also need to say what is the particular
|
|
0:39:45
|
marking value that we want to maintain
|
|
0:39:49
|
if the amount of traffic is within the conform action.
|
|
0:39:53
|
So if we look back at Switch 1 here
|
|
0:39:58
|
right now at the link level, I have the previous policy
|
|
0:40:01
|
removed which was changing the af11 traffic to the af42
|
|
0:40:06
|
if we look at Router 6 and let's clear the access list counters
|
|
0:40:14
|
then look at the show access list, right now we can see
|
|
0:40:18
|
that the af11 traffic is being maintained as it's coming in
|
|
0:40:22
|
on Router 6's interface.
|
|
0:40:25
|
So Router 1 is setting this with the policy out
|
|
0:40:28
|
Switch 1 is saying on the link I am trusting this value
|
|
0:40:32
|
so I'm maintaining it
|
|
0:40:33
|
then eventually it's ending up all the way at Router 6
|
|
0:40:38
|
Now what I'm going to change here with the policing I'll say
|
|
0:40:41
|
that af11 is going to be maintained as long as we do not
|
|
0:40:45
|
exceed whatever the conform threshold that we define.
|
|
0:40:50
|
Now since we're really not generating that much bandwidth
|
|
0:40:52
|
with the pings, I'm going to set this basically to the
|
|
0:40:55
|
lowest value for the policing.
|
|
0:41:00
|
So on Switch 1
|
|
0:41:02
|
I'm going to create a new policy map that is going to mark
|
|
0:41:06
|
down to af 33
|
|
0:41:12
|
For class class-default
|
|
0:41:15
|
we're going to do policing.
|
|
0:41:19
|
I'll say simply the minimum value 8000 bits per second
|
|
0:41:24
|
with whatever the minimum burst size is.
|
|
0:41:27
|
Our exceed action is the policed dscp transmit.
|
|
0:41:32
|
So essentially this is saying if you go over 8 kilobits per second
|
|
0:41:37
|
then the traffic is going to be remarked based on
|
|
0:41:39
|
this policed dscp mutation map.
|
|
0:41:43
|
Now for traffic that does not exceed
|
|
0:41:47
|
I need to specify what marking I want that to receive.
|
|
0:41:50
|
So even though it's coming in as af11 already
|
|
0:41:55
|
I additionally need to say set ip dscp to af11
|
|
0:42:01
|
so this is going to maintain the marking of the traffic
|
|
0:42:04
|
that is not exceeding. For anything that exceeds, we're going to
|
|
0:42:07
|
configure the policed dscp map
|
|
0:42:10
|
to change this to af33
|
|
0:42:14
|
So then at the link level here we'll say service policy input
|
|
0:42:16
|
is mark to af33
|
|
0:42:23
|
At this point if we look at Router 6, what we should see
|
|
0:42:27
|
is that the vast majority of the traffic is going to be remarked
|
|
0:42:29
|
down to dscp
|
|
0:42:37
|
that is based on the mutation map so if we look at let's look at the
|
|
0:42:39
|
clear -- let's say clear access list counters first
|
|
0:42:43
|
and what we'll see here in the access list hits
|
|
0:42:46
|
is that some of the traffic is maintaining as af11
|
|
0:42:50
|
some of it is being changed and we don't actually know
|
|
0:42:53
|
what this remarking value is because we're saying this is the
|
|
0:42:56
|
catchall for all other DSCP markings.
|
|
0:43:02
|
But the key point is that not all of it is af11
|
|
0:43:06
|
Some of it is being changed.
|
|
0:43:08
|
Now the way that we can see this if we look at Switch 1
|
|
0:43:13
|
and at the link level we have the policy applied
|
|
0:43:15
|
and the trusting applied.
|
|
0:43:17
|
If we look at the show mls qos interface
|
|
0:43:22
|
Fast Ethernet 0/1 statistics
|
|
0:43:28
|
we see the incoming DSCP values of 10
|
|
0:43:32
|
which is the decimal value that corresponds to af11
|
|
0:43:38
|
then for the outgoing traffic, it says that the policer says
|
|
0:43:43
|
the vast majority of it is out of profile.
|
|
0:43:46
|
So in other words, the vast majority of it is
|
|
0:43:48
|
exceeding.
|
|
0:43:51
|
So if we look at the statistics again and say just include the
|
|
0:43:54
|
policer,
|
|
0:43:56
|
we see that both counters are going up the in profile
|
|
0:44:00
|
and the outo profile
|
|
0:44:01
|
but the vast majority of it is outo profile
|
|
0:44:04
|
simply because I configured the policing value and the
|
|
0:44:07
|
burst value so low.
|
|
0:44:11
|
Now if we look at the show mls qos maps
|
|
0:44:16
|
the policed dscp map is now going to control
|
|
0:44:20
|
how are we remarking this af11 traffic as it is
|
|
0:44:25
|
coming in on the interface.
|
|
0:44:29
|
Now to read this output, and this is true of the policed
|
|
0:44:33
|
dscp map or the dscp to class of service or class of service
|
|
0:44:36
|
to dscp. Basically any of these that you see from the show
|
|
0:44:39
|
mls qos map output
|
|
0:44:42
|
The value in the first column which in our case is 1 and then
|
|
0:44:48
|
0, the value in the first column this is your first digit in decimal
|
|
0:44:52
|
which in our case is 1
|
|
0:44:55
|
The row at the top this is going to be the second digit
|
|
0:44:58
|
in decimal which ours is 0
|
|
0:45:02
|
is being remarked to the same value as 10
|
|
0:45:05
|
where 4, 2 is being remarked to 42
|
|
0:45:08
|
or 6, 3 is being remarked to 63
|
|
0:45:13
|
so essentially it means that by default, the policed dscp
|
|
0:45:15
|
map is not changing any of the markings.
|
|
0:45:19
|
Now this can be a little bit confusing when you
|
|
0:45:22
|
look at the dscp value
|
|
0:45:24
|
because again, some of these are going to use the
|
|
0:45:26
|
type of service as the full byte.
|
|
0:45:29
|
Where in this case the dscp value in decimal
|
|
0:45:31
|
is looking at just the most -- the six most
|
|
0:45:34
|
significant bits of the type of service field.
|
|
0:45:37
|
Again, we saw this on Router 6 when we were looking at the
|
|
0:45:40
|
access list. If we say access list 100 permit ip any any
|
|
0:45:46
|
with a dscp of ?
|
|
0:45:51
|
It says af11 is 001010
|
|
0:45:59
|
where if we were to take this in binary
|
|
0:46:02
|
001010 convert this to decimal
|
|
0:46:06
|
this 10 here
|
|
0:46:08
|
is then what's being referred to in the policed dscp map
|
|
0:46:16
|
Now if I want to change this to af33
|
|
0:46:19
|
I would then need to know for this particular marking
|
|
0:46:21
|
what is 011110
|
|
0:46:26
|
in decimal
|
|
0:46:30
|
so we'll have 011110
|
|
0:46:33
|
in decimal is 30
|
|
0:46:37
|
so this then should mean if I were to configure the
|
|
0:46:39
|
mutation map to take the inbound value of 1
|
|
0:46:43
|
0 and output it to 30
|
|
0:46:47
|
when Router 6 finally receives these packets inbound
|
|
0:46:50
|
the ones that are exceeding the policing they should be
|
|
0:46:53
|
changed to af33
|
|
0:46:57
|
so now on Router 6 let's account for this
|
|
0:46:59
|
let's say for ip access list extended 100
|
|
0:47:02
|
sequence number 1 is going to permit ip any any
|
|
0:47:05
|
with a dscp of af33
|
|
0:47:10
|
then we'll keep track of this through the show lists.
|
|
0:47:18
|
Now on Switch 1 we're going to change in global config
|
|
0:47:22
|
the mls qos map for policed dscp
|
|
0:47:29
|
I'm saying that my incoming value which is 10
|
|
0:47:34
|
is going to be changed to 30
|
|
0:47:36
|
and again, this is the decimal value of just the six most significant
|
|
0:47:40
|
bits in the type of service field.
|
|
0:47:49
|
If we look at the show policy map
|
|
0:47:53
|
it says that for anything that does not exceed
|
|
0:47:56
|
that's going to stay as af11
|
|
0:47:59
|
Anything that does exceed is then going to look at the
|
|
0:48:01
|
policed dscp map which we're saying we're changing decimal
|
|
0:48:05
|
number 10 or decimal marking 10 to decimal marking 30
|
|
0:48:10
|
Now another shortcut for this if you look at the show class map
|
|
0:48:15
|
here on the class map
|
|
0:48:16
|
for Router 1, previously I was saying match ip dscp af11
|
|
0:48:21
|
In parentheses here this 10 that's the decimal value for that dscp
|
|
0:48:30
|
So now on Router 6 if we look at the show access list
|
|
0:48:32
|
we can see that some of the traffic is now being marked
|
|
0:48:35
|
as af33
|
|
0:48:37
|
If we clear the access list counters
|
|
0:48:44
|
we should see that the vast majority is going to be af33
|
|
0:48:47
|
but not all of it.
|
|
0:48:50
|
So only the packets that exceed are being remarked
|
|
0:48:55
|
the ones that are less than 8000 bits per second those are
|
|
0:48:58
|
maintaining their marking of af11
|
|
0:49:03
|
but the key with this implementation and the documentation doesn't
|
|
0:49:06
|
make it really as clear as it needs to be
|
|
0:49:08
|
that when you specify the policy, if you do not also
|
|
0:49:13
|
remark the dscp back to what it was to begin with
|
|
0:49:18
|
it's going to fall back to dscp 0
|
|
0:49:21
|
So even though the traffic is already coming
|
|
0:49:23
|
in as af11, I need to say set ip dscp af11
|
|
0:49:28
|
for the policy that is in on the interface.
|
|
0:49:32
|
Now the other place that you would see this
|
|
0:49:35
|
if you need a syntax reference for this is with the auto QoS
|
|
0:49:38
|
feature and we'll take a look at that in a little bit
|
|
0:49:40
|
for using the interface macros
|
|
0:49:44
|
in order to figure out what are some of the default
|
|
0:49:46
|
syntax options for these different QoS features.
|
|
0:49:51
|
So now at this point, Router 1 is sending the af11 traffic in
|
|
0:49:56
|
Switch 1 is saying that there's two possible options
|
|
0:49:59
|
if the traffic is conforming
|
|
0:50:02
|
we are maintaining the marking as af11
|
|
0:50:06
|
If the traffic has exceeded, we are setting it to af33
|
|
0:50:16
|
Once this gets up to Switch 2
|
|
0:50:19
|
Switch 2 is saying that this interface Fast Ethernet 16
|
|
0:50:22
|
which is my trunk link that's going to Switch 3
|
|
0:50:24
|
this is a trusted interface, so Switch 2 is maintaining the
|
|
0:50:28
|
af11 and the af33 markings as they come in.
|
|
0:50:34
|
Now the potential design issue we run into
|
|
0:50:37
|
that if Switch 2 want to change these classification values
|
|
0:50:42
|
we would need to take into account what are
|
|
0:50:44
|
all the possible Layer 2 trunk links that the
|
|
0:50:47
|
traffic could be received on.
|
|
0:50:50
|
So specifically in this case, we are using Fast Ethernet 16
|
|
0:50:54
|
because that's what the default root port fell back to
|
|
0:50:58
|
based on the cost values and based on what the lowest
|
|
0:51:00
|
port numbers are up towards the ---
|
|
0:51:03
|
but if something were to change in the spanning tree
|
|
0:51:07
|
topology and let's say now that Switch 2 is no longer
|
|
0:51:11
|
using port 16 maybe at --- port 17 is the root port.
|
|
0:51:17
|
If this link is not trusted and if it does not have
|
|
0:51:20
|
the same exact service policy as applied as port 16 does
|
|
0:51:26
|
that's going to affect our QoS marking and classification.
|
|
0:51:31
|
So typically when we apply the policy directly to the interface
|
|
0:51:35
|
that is most appropriate when you're applying it to the access
|
|
0:51:38
|
port to classify traffic as it comes in from the end host.
|
|
0:51:44
|
For the inter-switch links any time that we're dealing with
|
|
0:51:47
|
multiple Layer 2 trunk links
|
|
0:51:50
|
there's a shortcut that we can apply onto this
|
|
0:51:54
|
by putting the service policy onto the VLAN interface
|
|
0:51:58
|
as opposed to the physical link.
|
|
0:52:01
|
Now not all switch platforms are going to support this
|
|
0:52:04
|
this is considered VLAN based QoS
|
|
0:52:08
|
where implementation wise it's pretty straightforward
|
|
0:52:11
|
we have the same type of syntax for the service policy as
|
|
0:52:13
|
we did before. The change is that we apply the service policy
|
|
0:52:17
|
to the SVI or the VLAN interface
|
|
0:52:21
|
then at the underlying Layer 2 ports that are actually forwarding
|
|
0:52:25
|
that VLAN, we issue a specific command to tell it to look
|
|
0:52:29
|
at the SVI for the individual policy.
|
|
0:52:34
|
So now let's say on Switch 2 that for the af11 traffic
|
|
0:52:38
|
as this comes in
|
|
0:52:40
|
we want to change it back to the af42
|
|
0:52:44
|
but I want to make sure that I can account for this regardless
|
|
0:52:46
|
of whether it's coming in port 16, 17 or 18
|
|
0:52:53
|
So on Switch 2, the service policy configuration is going to be
|
|
0:52:58
|
similar as it was before.
|
|
0:53:01
|
So we'll say policy map is going to remark
|
|
0:53:08
|
and we need to match
|
|
0:53:11
|
the dscp of af11
|
|
0:53:16
|
Ok, so I'll need a class map
|
|
0:53:20
|
I'll say af11
|
|
0:53:21
|
it says match ip dscp af11
|
|
0:53:27
|
policy map remark says that if this is class af11
|
|
0:53:32
|
I'm going to change the dscp
|
|
0:53:36
|
to af42
|
|
0:53:39
|
then for everything else, it's going to be unmodify.
|
|
0:53:41
|
So anything that is not af11, this is going to fall back to
|
|
0:53:44
|
class default.
|
|
0:53:47
|
Now normally, I would apply this policy directly to
|
|
0:53:50
|
the port
|
|
0:53:51
|
which in this case is Fast Ethernet 16
|
|
0:53:54
|
but what I'm going to do instead is apply it to vlan
|
|
0:53:57
|
146, we'll say service policy input is remark
|
|
0:54:08
|
Now note here when we look at the running config of the
|
|
0:54:10
|
VLAN interface
|
|
0:54:12
|
even though we do not have a Layer 3 address and we're
|
|
0:54:15
|
not actually routing for this segment
|
|
0:54:18
|
we can still apply a Layer 3 classification to all of the
|
|
0:54:23
|
traffic that is forwarding through that particular VLAN
|
|
0:54:27
|
So it's essentially a Layer 3 policy that is applying to
|
|
0:54:31
|
all possible Layer 2 links
|
|
0:54:33
|
that have a spanning tree instance of vlan 146
|
|
0:54:39
|
Now the only additional step is at the individual port levels
|
|
0:54:42
|
and typically you would do this everywhere
|
|
0:54:45
|
we'll say interface range Fast Ethernet 1 through 24
|
|
0:54:51
|
The mls qos is now going to be VLAN based.
|
|
0:54:58
|
So assuming that we now have this applied to all of our
|
|
0:55:00
|
trunk links 16, 17, 18 etc.
|
|
0:55:05
|
it really doesn't matter where the vlan 146 traffic is coming
|
|
0:55:08
|
in because it's always now going to be classified
|
|
0:55:14
|
at this vlan 146 interface.
|
|
0:55:20
|
So if this is correct, we should be able to go to Router 6
|
|
0:55:24
|
and look at the show access lists
|
|
0:55:26
|
and we see now that we are getting hits on af42 again.
|
|
0:55:32
|
If we clear the access list counters again, we should see
|
|
0:55:35
|
that only af33
|
|
0:55:49
|
and 42 are getting hits.
|
|
0:55:52
|
So what this is saying is that the 11
|
|
0:55:55
|
is being remarked to 42
|
|
0:55:59
|
and the 33 is not getting trusted.
|
|
0:56:05
|
So we would then need to figure out what is the
|
|
0:56:07
|
incoming interface for that traffic
|
|
0:56:09
|
and make sure that we are trusting the DSCP values.
|
|
0:56:13
|
So depending on how you're applying the policy
|
|
0:56:16
|
it can get kind of complicated as to we need to match
|
|
0:56:20
|
and then reset the value, but you can see the way
|
|
0:56:23
|
that we're doing the verification on Router 6, this is going to be
|
|
0:56:26
|
your final verification to figure out is your policy
|
|
0:56:29
|
actually working or not.
|
|
0:56:31
|
So even though we expected af33 and 42 to be there
|
|
0:56:35
|
since we now have 0 and 42
|
|
0:56:38
|
it tells us that the af33 is being deleted.
|
|
0:56:42
|
Now I could fix this on Switch 2
|
|
0:56:45
|
if I were to simply say for class map af33
|
|
0:56:50
|
class map af33
|
|
0:56:52
|
match ip dscp
|
|
0:56:55
|
af33
|
|
0:56:58
|
then under policy map
|
|
0:57:04
|
that is remark
|
|
0:57:08
|
I would need to call class af33
|
|
0:57:19
|
then set ip dscp af33
|
|
0:57:24
|
So we can also see from this log message says
|
|
0:57:26
|
remove this service policy from the interface
|
|
0:57:31
|
we'll say no service policy input is remark
|
|
0:57:38
|
then reapply it
|
|
0:57:43
|
and we should now have those two different sequences, so if we
|
|
0:57:45
|
look at the show policy map
|
|
0:57:55
|
af11 is being set to 42
|
|
0:57:58
|
and af33 is being set back to itself.
|
|
0:58:03
|
So now on Router 6, if we look at the show
|
|
0:58:07
|
access list, we can see now that 33 is being maintained.
|
|
0:58:13
|
So we should now see mainly 33 and 42
|
|
0:58:19
|
So 33 again is the traffic that is exceeding the policing
|
|
0:58:23
|
configuration that we have on Switch 1
|
|
0:58:26
|
42 is the originally the af11 traffic that was conforming
|
|
0:58:35
|
Switch 1,
|
|
0:58:37
|
it says here with set ip dscp af11, so if the traffic
|
|
0:58:40
|
conforms, it's going to maintain its marking.
|
|
0:58:44
|
Then on Switch 2, we're saying if it's 11, change it to 42
|
|
0:58:51
|
So again, the overall key of this is just to make sure that
|
|
0:58:54
|
at the access layer
|
|
0:58:55
|
your markings are correct.
|
|
0:58:58
|
So that when it actually gets up to the routers to
|
|
0:59:00
|
enforce the different queuing mechanisms
|
|
0:59:03
|
you want to make sure that your classifying your voice
|
|
0:59:05
|
traffic different than your normal data flows.
|
|
0:59:08
|
And if you don't enforce this on the access layer, it basically
|
|
0:59:11
|
means all of the other QoS we talked about up to this point
|
|
0:59:13
|
it's not actually going to have the same effect that we
|
|
0:59:17
|
wanted it to.
|
