|
0:00:12
|
Welcome back everybody to internetwork expert CCIE
|
|
0:00:15
|
routing and switching advanced technologies class.
|
|
0:00:18
|
In today's class sessions we're going to be talking about
|
|
0:00:21
|
QoS both from a theory point of view and from an implementation
|
|
0:00:25
|
how we can use the different types of syntax for the
|
|
0:00:28
|
module of the quality of service and then some of the
|
|
0:00:31
|
legacy equivalents.
|
|
0:00:33
|
Now overall our goals today are first going to be to talk
|
|
0:00:37
|
about what are the reasons why we need to use QoS.
|
|
0:00:41
|
This is going to help us understand within the scope of the lab exam
|
|
0:00:44
|
based on the particular questions that they're asking us what is
|
|
0:00:48
|
the method of quality of service that we can use
|
|
0:00:50
|
in order to solve a specific problem.
|
|
0:00:54
|
We'll talk about the different models of QoS the differences
|
|
0:00:56
|
between the integrated services versus differentiated
|
|
0:00:59
|
services and how to mark traffic in order to conform
|
|
0:01:03
|
with the differentiated services model. We'll also look at what are the
|
|
0:01:07
|
different queuing mechanisms that we can do in the IOS,
|
|
0:01:10
|
the differences between the class based weighted fair queuing,
|
|
0:01:14
|
the new hierarchical queuing framework, the low latency
|
|
0:01:18
|
queuing, weighted random early detection etc.
|
|
0:01:22
|
Now we'll also talk about some of the legacy applications
|
|
0:01:25
|
with frame relay traffic shaping, how we can do
|
|
0:01:28
|
per virtual circuit queuing that's a little bit different than
|
|
0:01:31
|
other Layer 2 medias like a PPP link or an Ethernet link
|
|
0:01:35
|
and then lastly we'll take a look at some Layer 2 quality of
|
|
0:01:39
|
service on the Catalyst 3560 IOS
|
|
0:01:43
|
and our very last topic we'll see that the QoS on the Catalyst
|
|
0:01:47
|
switches is very hardware specific so for a lot of this
|
|
0:01:51
|
information your best resource is going to be the actual configuration
|
|
0:01:54
|
guide for that particular platform and its particular IOS release.
|
|
0:01:59
|
Now the reason that we need quality of service to begin with
|
|
0:02:02
|
is that we have multiple traffic flows that are sharing a same
|
|
0:02:05
|
physical or logical interface and ultimately this means that
|
|
0:02:09
|
they're going to be contending for the same resources.
|
|
0:02:12
|
So generally this resource is going to be the bandwidth of the interface.
|
|
0:02:17
|
Now the problem that we run into design wise is that different
|
|
0:02:20
|
applications are going to have different requirements
|
|
0:02:22
|
so when we're looking at our Voice over IP versus
|
|
0:02:25
|
our web browsing versus video conferencing
|
|
0:02:29
|
these different applications are going to have different end to end
|
|
0:02:33
|
application requirements whether they're related to the delay
|
|
0:02:36
|
or the amount of bandwidth or the packet loss
|
|
0:02:38
|
that can occur when the traffic is sent into the network.
|
|
0:02:43
|
Now since we have these multiple applications running over the
|
|
0:02:45
|
same link and they're contending for the same resources
|
|
0:02:48
|
the end result is that the router or whatever Layer 2 device is
|
|
0:02:53
|
in the middle is going to have to queue the traffic up
|
|
0:02:56
|
so this essentially means that the packets are going to be
|
|
0:02:59
|
either delayed or dropped and in any case the result
|
|
0:03:04
|
is generally going to be a decrease in the total
|
|
0:03:08
|
throughput for the particular flow or some sort of change
|
|
0:03:12
|
in the end to end delay or the differences in the delay which
|
|
0:03:16
|
is known as the jitter for that particular application.
|
|
0:03:20
|
So for example in the case of Voice over IP, we would need to
|
|
0:03:24
|
compute on a hop by hop basis what is the delay
|
|
0:03:27
|
budget on that particular interface's queue.
|
|
0:03:30
|
So if we say that for our end to end voice call we don't
|
|
0:03:33
|
want to get more than 150 millisecond delay, we would need to
|
|
0:03:37
|
think about what are all the end to end delays on the outbound
|
|
0:03:42
|
transit from the source to the destination in addition to
|
|
0:03:45
|
the delay from the destination back to the source
|
|
0:03:48
|
so with Voice typically we are measuring the round-trip delay
|
|
0:03:53
|
so it means that we're going to have to deal with the quality of service
|
|
0:03:55
|
both on the outbound direction and as the traffic is returning back inbound.
|
|
0:03:59
|
Now the easiest solution for this problem is to avoid the
|
|
0:04:03
|
contention in the first place.
|
|
0:04:05
|
This simply means that if we do not overprovision the
|
|
0:04:08
|
network, so there's enough bandwidth for all of the
|
|
0:04:11
|
applications, the applications are not going to run into any type of
|
|
0:04:14
|
delay problems, then we're never going to need quality of
|
|
0:04:17
|
service to begin with.
|
|
0:04:19
|
The issue is that not overprovisioning a lot of the times is not possible
|
|
0:04:24
|
simply due to the cost of adding new physical links
|
|
0:04:27
|
or new hardware devices into the network.
|
|
0:04:29
|
So quality of service essentially is going to be our next best solution.
|
|
0:04:34
|
Our goal with QoS is to figure out how can we control
|
|
0:04:38
|
the congestion that's occurring in the network or control the
|
|
0:04:41
|
contention that is occurring on the links.
|
|
0:04:45
|
Now with QoS we can then control what is going to be
|
|
0:04:47
|
the end to end delay
|
|
0:04:50
|
the worst case packet loss, the amount of throughput that an
|
|
0:04:54
|
individual application can get on a per hop basis.
|
|
0:04:59
|
But the key here is that QoS is essentially a band-aid for the network
|
|
0:05:02
|
where it's not a permanent solution.
|
|
0:05:05
|
Basically any time that we need to apply QoS to the network
|
|
0:05:08
|
it means that we don't have enough resources to begin with
|
|
0:05:10
|
so really the long term solution is to add more links or to add
|
|
0:05:14
|
better hardware, but in the meantime you can see that
|
|
0:05:17
|
a lot of the application issues you can fix with QoS
|
|
0:05:20
|
but at certain points once you get to too much contention
|
|
0:05:24
|
then really QoS is not going to help you that much
|
|
0:05:26
|
and you would simply have to upgrade the devices or
|
|
0:05:29
|
actually upgrade the links.
|
|
0:05:31
|
We'll see today in our discussions we're going to focus mainly on two
|
|
0:05:34
|
different types of QoS models which we are going to define
|
|
0:05:39
|
how we deal with the contention in the network.
|
|
0:05:42
|
Generally these two types of models are called the integrated
|
|
0:05:46
|
services model and the differentiated services model
|
|
0:05:50
|
where depending on what type of application we're using or
|
|
0:05:53
|
what type of QoS management that's actually going on in the network
|
|
0:05:56
|
those are going to be defined by these two models either the
|
|
0:05:59
|
IntServ or the DifServ models.
|
|
0:06:03
|
Now the first one the integrated services or IntServ model
|
|
0:06:07
|
essentially means that every application's flow has an
|
|
0:06:10
|
explicit reservation end to end in the network.
|
|
0:06:15
|
Now this also implies that integrated services is a connection
|
|
0:06:18
|
oriented type QoS model which essentially means that the
|
|
0:06:22
|
application itself needs to have awareness of the end to end
|
|
0:06:26
|
QoS in the network.
|
|
0:06:30
|
Now the problem with this is that for every single flow
|
|
0:06:33
|
in the network it means that the devices in the transit path are going to
|
|
0:06:36
|
have to maintain the state for this.
|
|
0:06:39
|
When we look at alternatives to this like the class based weighted fair queuing
|
|
0:06:42
|
or the hierarchical queuing framework, the HQF,
|
|
0:06:48
|
we'll see that generally the router is going to want to
|
|
0:06:50
|
maintain less state or a less amount of queues
|
|
0:06:54
|
on the interface where basically in the case of integrated services
|
|
0:06:58
|
the router would have to keep track of every single
|
|
0:07:00
|
flow and every individual reservation as it's added to the
|
|
0:07:04
|
network and then as it's teared down.
|
|
0:07:09
|
So in general, integrated services is kind of considered a legacy QoS
|
|
0:07:12
|
model. There are some still real world applications for
|
|
0:07:16
|
IntServ. The main one is going to be for MPLS traffic engineering
|
|
0:07:20
|
which uses the resource reservation protocol or RSVP
|
|
0:07:25
|
that is specific to IntServ where it's used to signal
|
|
0:07:30
|
between the MPLS routers and the transit path how much
|
|
0:07:33
|
bandwidth or what are the different types of resources that
|
|
0:07:36
|
we want to reserve on a per MPLS tunnel basis.
|
|
0:07:44
|
But again, as we talked about MPLS within the scope of
|
|
0:07:46
|
CCIE routing and switching I would assume that traffic
|
|
0:07:49
|
engineering is not going to be part of that.
|
|
0:07:52
|
So we'll see that the vast majority of QoS models
|
|
0:07:55
|
or QoS configurations that we're going to look at today are going to
|
|
0:07:58
|
be related to the differentiated services model or DifServ
|
|
0:08:01
|
and not the IntServ model.
|
|
0:08:04
|
Now both of these two different models the DifServ and the IntServ
|
|
0:08:07
|
they are defined by different RFCs
|
|
0:08:10
|
so if you go to either the IETF website or if you
|
|
0:08:15
|
go to rfc-editor.org
|
|
0:08:21
|
and search for difserv QoS or intserv QoS
|
|
0:08:27
|
you'll see the actual definitions of what's going on, so the
|
|
0:08:32
|
aggregation of DifServ service classes
|
|
0:08:35
|
resource reservation protocol over MPLS TE tunnels this
|
|
0:08:38
|
would be for integrated services
|
|
0:08:41
|
where you can see that the RFCs are going to be a
|
|
0:08:44
|
general recommendation as to how these QoS models
|
|
0:08:48
|
are implemented
|
|
0:08:50
|
but then when we actually get to the configuration, we'll see
|
|
0:08:53
|
a lot of this is going to be up to our control how we
|
|
0:08:55
|
actually want to define the different classes of traffic
|
|
0:08:58
|
and then how we actually want to manage them with the
|
|
0:09:01
|
different QoS techniques.
|
|
0:09:04
|
So while technically we'll see with the differentiated services
|
|
0:09:07
|
there are well known per hop behaviors or PHBs
|
|
0:09:12
|
that are supposed to control how a particular traffic class
|
|
0:09:15
|
is going to be treated.
|
|
0:09:16
|
Ultimately it's going to be up to us to define what the
|
|
0:09:19
|
end to end QoS model is. Now the key difference between
|
|
0:09:23
|
the IntServ and the DifServ model is that in integrated services
|
|
0:09:27
|
it's up to the application to actually do the reservation of
|
|
0:09:30
|
the network where each individual flow is going to have
|
|
0:09:35
|
a separate QoS requirement.
|
|
0:09:38
|
But again the disadvantage of this is that the network needs to
|
|
0:09:41
|
maintain a lot of state for the individual flows.
|
|
0:09:44
|
In differentiated services we're trying to aggregate this information
|
|
0:09:47
|
together by grouping different types traffics into user defined classes.
|
|
0:09:55
|
So the classification process of the actual traffic is going to happen
|
|
0:09:58
|
at the network edge when packets are generally received
|
|
0:10:02
|
inbound which either could be through a manual process
|
|
0:10:06
|
that we're going to define or it could be pre-encoded in the packet
|
|
0:10:10
|
which is known as the packet's marking.
|
|
0:10:15
|
So once the network knows what these different marking values are
|
|
0:10:17
|
whether we are manually defining it or whether it's
|
|
0:10:20
|
predefined, the actual quality of service that the traffic
|
|
0:10:24
|
class is going to get is going to be based on the per
|
|
0:10:26
|
hop behavior that is defined for that individual class.
|
|
0:10:31
|
So for probably 95 percent of the QoS mechanisms that we're
|
|
0:10:34
|
going to look at, generally we're going to be talking about the
|
|
0:10:36
|
differentiated services, so any time we define a class
|
|
0:10:40
|
map or specify any criteria of grouping traffic together
|
|
0:10:43
|
that means that we're using the DifServ model.
|
|
0:10:47
|
Now it doesn't necessarily mean that we're using the
|
|
0:10:49
|
differentiated services code point or the DSCP
|
|
0:10:52
|
We'll see that DSCP is just one of the ways that we
|
|
0:10:55
|
can specify the marking and then ultimately control
|
|
0:10:58
|
the per hop behavior of a particular type of traffic.
|
|
0:11:02
|
Now the marking itself for DifServ it can happen
|
|
0:11:05
|
a number of different ways.
|
|
0:11:06
|
It can be in the Layer 3 packet header for both either the
|
|
0:11:11
|
IP version 4 or IP version 6 headers or it can be in the
|
|
0:11:16
|
Layer 2 header whether this is related to frame relay or ATM
|
|
0:11:20
|
or MPLS or Ethernet.
|
|
0:11:24
|
In the case of IP, this is known as the type of service byte or the
|
|
0:11:27
|
TOS which in the case of IPV4
|
|
0:11:31
|
is made up of two separate fields: the differentiated services
|
|
0:11:35
|
code, the DSCP, and the IP precedence value.
|
|
0:11:42
|
Now we'll see that when we actually look at the values in binary inside
|
|
0:11:45
|
the packet header, the IP precedence and DSCP are
|
|
0:11:48
|
going to overlap so there is a compatibility between the two of them
|
|
0:11:53
|
where generally IP precedence is considered the legacy markings
|
|
0:11:57
|
and DSCP would be the preferred marking because it's going to give
|
|
0:12:00
|
us a little bit more granularity as to how we are classifying
|
|
0:12:04
|
the traffic.
|
|
0:12:05
|
Now for the Layer 2 markings generally we cannot get as
|
|
0:12:08
|
granular as we can with Layer 3 where in the case
|
|
0:12:12
|
of MPLS experimental we only have three bits for classification
|
|
0:12:17
|
whereas in the case of DSCP we have six bits.
|
|
0:12:21
|
So in an MPLS network, the service provider could only
|
|
0:12:24
|
classify eight different service levels of traffic.
|
|
0:12:28
|
So MPLS experimental value 0 through 7
|
|
0:12:32
|
whereas with DSCP we have six bits so we have two to the six
|
|
0:12:39
|
different combinations of the different classes.
|
|
0:12:41
|
Now we'll see when we actually get to the queue definitions
|
|
0:12:44
|
typically you wouldn't want that many different classes of traffic
|
|
0:12:47
|
because at the router it has 64 or a 128 queues defined at
|
|
0:12:51
|
the link, at some point we're going to lose visibility as to how we're
|
|
0:12:55
|
processing one type of traffic versus another.
|
|
0:12:59
|
So in a real implementation generally we'll have maybe four
|
|
0:13:02
|
or five queue definitions at the most where typically
|
|
0:13:06
|
we'll have our low latency or guaranteed delay traffic
|
|
0:13:09
|
which would be like our voice or video, then guaranteed bandwidth
|
|
0:13:13
|
traffic which would be our voice signaling
|
|
0:13:16
|
then maybe different particular applications that we need like
|
|
0:13:21
|
web browsing or FTP that we want to guarantee a certain
|
|
0:13:23
|
bandwidth and then lower level classes like best effort forwarding
|
|
0:13:27
|
that says if you fall into this class and there's no available
|
|
0:13:32
|
bandwidth, then we're not going to guarantee you anything.
|
|
0:13:34
|
Now the very last one there the 802.1q and the ISL class of service bits
|
|
0:13:39
|
in the Layer 2 Ethernet header, the key point about this one is that
|
|
0:13:43
|
it only exists in the trunking encapsulation.
|
|
0:13:47
|
So when we look at the Catalyst 3560 QoS
|
|
0:13:52
|
we'll see that we can only use the class of service bits
|
|
0:13:55
|
when we are dealing with a trunking interface.
|
|
0:13:59
|
So as packets go down to an end host through an access port
|
|
0:14:02
|
normally the class of service is not going to exist in the actual
|
|
0:14:06
|
Ethernet header.
|
|
0:14:07
|
So we'll see there's some sort of workarounds that we can
|
|
0:14:10
|
do with the internal temporary markings on the Catalyst switches
|
|
0:14:14
|
that we can ultimately use to figure out when traffic is received
|
|
0:14:17
|
from the end host what type of queues is it supposed to go into
|
|
0:14:20
|
when the traffic is sent outbound.
|
|
0:14:22
|
Now specifically for the DSCP values there's going to be
|
|
0:14:26
|
four main categories that are pre-defined
|
|
0:14:29
|
where the first one is the default class of DSCP 0
|
|
0:14:35
|
which is going to be for our best effort traffic.
|
|
0:14:39
|
So sometimes this is also called the scavenger class
|
|
0:14:41
|
where it's any type of traffic that is not either reserved
|
|
0:14:45
|
low latency where it's not reserved bandwidth, then it's going to
|
|
0:14:48
|
fall back into the worst case scenario class which is the
|
|
0:14:51
|
best effort.
|
|
0:14:54
|
So as traffic is received inbound from our end hosts
|
|
0:14:57
|
if we don't want to do any type of reservations for it,
|
|
0:15:00
|
then generally we're going to set this to the default class which is
|
|
0:15:03
|
DSCP 0
|
|
0:15:08
|
This would be the opposite of the best class which is expedited
|
|
0:15:12
|
forwarding or EF which is generally going to be
|
|
0:15:15
|
reserved for our priority traffic flows.
|
|
0:15:19
|
So in the vast majority of real implementations, DSCP
|
|
0:15:22
|
EF is going to be used for the Voice over IP bearer traffic.
|
|
0:15:26
|
So the actual voice call between the two phones.
|
|
0:15:33
|
We'll see then the voice signaling traffic like the SIP or the H323
|
|
0:15:37
|
generally this traffic is marked with a different type of class
|
|
0:15:42
|
because the signaling versus the actual voice call itself they're going to
|
|
0:15:45
|
have two different types of application requirements in the network.
|
|
0:15:53
|
DSCP EF in decimal is number 46
|
|
0:15:56
|
which in binary is 101110
|
|
0:16:00
|
Now we'll see when we actually look at this on the command line
|
|
0:16:03
|
you don't necessarily have to remember what the
|
|
0:16:05
|
actual marking values are because there are some shortcuts
|
|
0:16:10
|
in the IOS to figure out what's the binary value of EF versus
|
|
0:16:14
|
CS5 versus AF 41
|
|
0:16:17
|
The next one we have is called the assured forwarding
|
|
0:16:21
|
class or AF which is generally supposed to be reserved
|
|
0:16:26
|
for guaranteed bandwidth applications.
|
|
0:16:29
|
So whether these are web traffic flows or FTP or database
|
|
0:16:34
|
synchronization, the DSCP is going to define four different
|
|
0:16:38
|
classes of assured forwarding and three different drop precedences
|
|
0:16:45
|
where the class numbers are 1 through 4 where a higher value is preferred.
|
|
0:16:51
|
For the drop precedences, a higher value means a
|
|
0:16:55
|
higher drop precedence, so essentially lower is better.
|
|
0:17:02
|
When we look at these in binary, the first three bits
|
|
0:17:06
|
are going to define the class where 001 would be class 1
|
|
0:17:12
|
010 would be class 2 011 would be class 3
|
|
0:17:17
|
then the drop precedence is going to be the two bits after that
|
|
0:17:21
|
so when we look at the default values for this, the most preferred
|
|
0:17:26
|
assured forwarding class would be AF 41
|
|
0:17:29
|
because class 4 is higher than classes 1, 2 and 3
|
|
0:17:33
|
and drop precedence 1 means you're less likely
|
|
0:17:36
|
to be dropped than 2 or 3
|
|
0:17:41
|
So again, you don't necessarily have to memorize these because
|
|
0:17:43
|
these -- the shortcuts for them you will be able to see
|
|
0:17:46
|
them on the command line.
|
|
0:17:48
|
Then lastly we have the class selector or CS
|
|
0:17:51
|
per hop behavior for DSCP. This is the one that's going to be
|
|
0:17:55
|
backwards compatible with IP precedence.
|
|
0:17:59
|
So when we actually look at the type of service byte in
|
|
0:18:02
|
the IP header, the three most significant bits are used for
|
|
0:18:06
|
the IP precedence where the six most significant bits
|
|
0:18:10
|
are used for DSCP.
|
|
0:18:15
|
So this essentially means that there's going to be three
|
|
0:18:17
|
bits the very first ones in the type of service that are
|
|
0:18:20
|
overlapping between the two fields.
|
|
0:18:24
|
So we'll see that there are some default mappings
|
|
0:18:26
|
from the assured forwarding to the class selectors
|
|
0:18:32
|
so that if we're using an AF class, it is automatically
|
|
0:18:35
|
going to be backwards compatible with something that is running
|
|
0:18:38
|
IP precedence.
|
|
0:18:40
|
But the actual values IP precedence 1 through 7
|
|
0:18:44
|
those are going to map to CS1 through CS7
|
|
0:18:49
|
Additionally these do have well known keywords
|
|
0:18:51
|
where CS5 would be for our critical traffic
|
|
0:18:55
|
where CS6 and 7 would be for our network
|
|
0:18:59
|
control plane traffics.
|
|
0:19:01
|
But again, you don't necessarily need to memorize this stuff
|
|
0:19:04
|
because you will be able to see it on the IOS
|
|
0:19:07
|
when we look at an access list or when we look at the module of
|
|
0:19:10
|
the quality of service syntax to figure out what are the actual
|
|
0:19:12
|
default values for these different types of markings.
|
|
0:19:16
|
Now once we actually go to implement the quality of service
|
|
0:19:19
|
we'll see that this is very highly dependent on the
|
|
0:19:22
|
marking to begin with.
|
|
0:19:24
|
So in a real end to end QoS model if your packet markings are not
|
|
0:19:29
|
right, it means that your actual queuing or shaping
|
|
0:19:33
|
or policing or admission control is not going to work.
|
|
0:19:37
|
So we need to make sure as traffic is received from the
|
|
0:19:39
|
end hosts that the classification is properly happening on the
|
|
0:19:43
|
network edge.
|
|
0:19:44
|
The vast majority of cases in today's networks this is going to
|
|
0:19:48
|
happen on the Layer 2 Ethernet switches as the traffic is received
|
|
0:19:52
|
inbound from the hosts.
|
|
0:19:56
|
Ok, in the case of wireless then it could either happen
|
|
0:19:59
|
on the like the wireless controller could do the classification
|
|
0:20:02
|
or the Layer 2 switch as the traffic is being received from the end host.
|
|
0:20:08
|
But once we actually figure out what is the traffic's marking
|
|
0:20:12
|
then we need to apply the different QoS tools
|
|
0:20:15
|
to figure out do we want to limit this traffic to the amount of bandwidth it can use
|
|
0:20:19
|
to we want to guarantee it bandwidth, do we want to
|
|
0:20:22
|
guarantee it low latency. This is what the different QoS
|
|
0:20:26
|
tools are going to be used to accomplish.
|
|
0:20:28
|
Now we'll see that these are going to be placed into a couple different categories
|
|
0:20:35
|
where admission control is going to be used for
|
|
0:20:39
|
traffic flows that are entering the network or leaving the network.
|
|
0:20:45
|
An admission control is going to occur generally through traffic
|
|
0:20:49
|
policing either inbound or outbound
|
|
0:20:53
|
or traffic shaping outbound.
|
|
0:20:57
|
Now we'll see within the scope of the lab exam a lot of the
|
|
0:21:01
|
difficulties that are common between a lot of candidates for
|
|
0:21:04
|
QoS is not really the configuration syntax, but to figure out based
|
|
0:21:09
|
on the question what is the appropriate QoS type that we
|
|
0:21:12
|
need to use, so in addition to looking at the actual theory
|
|
0:21:17
|
and the configuration for the different QoS mechanisms
|
|
0:21:20
|
we're going to take a look at some example questions
|
|
0:21:22
|
to figure out based on the requirements of this individual
|
|
0:21:25
|
task what would be an appropriate QoS tool
|
|
0:21:30
|
to apply in order to solve the problem
|
|
0:21:35
|
because again, with QoS the reason that we're using
|
|
0:21:37
|
it to begin with is that there's some problem with the
|
|
0:21:40
|
the contention of the bandwidth on the interfaces.
|
|
0:21:44
|
So when we're trying to solve a problem within the scope of the
|
|
0:21:46
|
lab, unless they specifically say configure the bandwidth
|
|
0:21:49
|
statement for 500 kilobits per second, we're going to need to
|
|
0:21:54
|
figure out what is the reason that we need to apply this in the first place.
|
|
0:21:58
|
So if we know the cases when we would want to apply policing
|
|
0:22:01
|
versus shaping or congestion management versus congestion avoidance
|
|
0:22:05
|
then generally the syntax should be fairly straightforward to piece
|
|
0:22:09
|
together as long as you spent some time with the module of the
|
|
0:22:12
|
quality of service on the IOS.
|
|
0:22:15
|
Now we'll see that there's a difference between the
|
|
0:22:17
|
"queuing" mechanisms on the IOS versus the other
|
|
0:22:22
|
methods of the admission control with policing or shaping or
|
|
0:22:26
|
the link optimizations with things like link fragmentation
|
|
0:22:30
|
and interleaving where queuing is going to occur as packets are
|
|
0:22:35
|
delayed by the router either inbound as they're being received
|
|
0:22:40
|
on the link or outbound as they're trying to leave the link.
|
|
0:22:46
|
We'll see that there can be multiple levels of hierarchy for
|
|
0:22:49
|
queuing where in the case of frame relay, we could have different
|
|
0:22:52
|
queues on a per virtual circuit basis, the PVC queues are
|
|
0:22:58
|
going to be contending for the single interface's software queue
|
|
0:23:03
|
then lastly the software queue is going to be contending for the
|
|
0:23:05
|
actual hardware queue which is known as the transmit ring
|
|
0:23:10
|
or the TXR.
|
|
0:23:13
|
Now the transmit ring is going to be the very last stop for
|
|
0:23:16
|
packets before they're actually encapsulated or serialized on the
|
|
0:23:20
|
interface, so from a hardware point of view, there's really
|
|
0:23:24
|
not that much that we can change with the transmit ring's queuing.
|
|
0:23:27
|
The vast majority of configuration that we're going to do is based
|
|
0:23:31
|
on the software queue before traffic is actually admitted
|
|
0:23:34
|
to the transmit ring.
|
|
0:23:37
|
And sometimes these are called our fancy queuing mechanisms.
|
|
0:23:40
|
So when we're looking at the bandwidth keyword or
|
|
0:23:43
|
the priority keyword or random early detection
|
|
0:23:47
|
those mechanisms are going to happen in the software queue
|
|
0:23:50
|
while traffic is being waited to be processed by the transmit ring.
|
|
0:23:58
|
Now there will be an exception to this for the Catalyst IOS
|
|
0:24:04
|
because the Catalyst switches are implementing QoS in hardware.
|
|
0:24:08
|
Now the end result of this is that we'll see there are
|
|
0:24:10
|
many less mechanisms of QoS that we can apply on the switches
|
|
0:24:15
|
versus the routers
|
|
0:24:17
|
because since it's implemented in hardware, there's a lot different
|
|
0:24:22
|
-- a lot less excuse me, a lot less variations that we can use
|
|
0:24:25
|
on the switches versus the routers.
|
|
0:24:28
|
So this essentially means that if you're pretty comfortable with the
|
|
0:24:32
|
QoS on the regular router's IOS, you'll see that there is really not much
|
|
0:24:37
|
that you need to do in the Catalyst IOS.
|
|
0:24:41
|
The main thing is to understand how the classification process
|
|
0:24:43
|
works, so when the Layer 2 switch is receiving packets
|
|
0:24:47
|
in from the end hosts is it going to drop the previous marking
|
|
0:24:52
|
is it going to maintain the previous marking or is it going to
|
|
0:24:55
|
change it to something else that's ultimately going to
|
|
0:24:58
|
affect what hardware queue the traffic class gets into
|
|
0:25:03
|
when the switch is going to send it to an egress interface or
|
|
0:25:06
|
an outbound interface.
|
|
0:25:08
|
Implementation wise, we'll see today that we are mainly going to
|
|
0:25:12
|
focus on the module of the quality of service command line
|
|
0:25:15
|
interface or the MQC which allows us to do multiple QoS
|
|
0:25:20
|
mechanisms on the same interface in the same direction.
|
|
0:25:27
|
So this means that we could do prioritization for our voice traffic
|
|
0:25:30
|
while we're also doing a bandwidth reservation for web traffic and then
|
|
0:25:35
|
policing our ICMP flows or peer to peer file sharing traffic.
|
|
0:25:40
|
Now the MQC is an alternative to what was previously known as
|
|
0:25:45
|
the legacy QoS mechanisms which are things like the
|
|
0:25:50
|
custom queue, the priority queue, the generic traffic
|
|
0:25:54
|
shaping, generally that stuff is no longer going to be supported
|
|
0:25:57
|
in the IOS going forward so we're really not going to
|
|
0:26:01
|
touch too much on how to implement the legacy Qos mechanisms.
|
|
0:26:08
|
Now in the MQC there's two different versions of it
|
|
0:26:10
|
one is called class based weighted fair queuing or CBWFQ
|
|
0:26:16
|
where the newer version is now called the hierarchical
|
|
0:26:19
|
queuing framework or HQF
|
|
0:26:25
|
so as of IOS 12.4 20 T going forward with
|
|
0:26:28
|
any of the ISRs or ISR 2s
|
|
0:26:31
|
or the 7200s
|
|
0:26:33
|
basically anything that does not implement queuing in
|
|
0:26:37
|
hardware, the HQF is basically a unified behavior
|
|
0:26:44
|
that the 3900 series routers would use
|
|
0:26:48
|
the same as the 1800s
|
|
0:26:52
|
Now we'll see there are a minor -- a few minor differences
|
|
0:26:55
|
with the HQF versus the old class based weighted fair queuing
|
|
0:26:59
|
and there is some good documentation on Cisco's website
|
|
0:27:02
|
that specifically talks about the differences.
|
|
0:27:08
|
So if you go to Cisco's website and simply search for HQF
|
|
0:27:12
|
or the hierarchical queuing framework, this document talks about
|
|
0:27:17
|
what are some of the changes that happen in the MQC syntax
|
|
0:27:22
|
from 12.4 20 T on.
|
|
0:27:27
|
So we'll see there's some changes in the default behavior of the
|
|
0:27:30
|
low latency queue versus the bandwidth reservation versus the
|
|
0:27:34
|
class default where this will affect our configuration
|
|
0:27:40
|
if we're using a version that's older then 12.4 20 T
|
|
0:27:44
|
versus a newer than 12.4 20 T version.
|
|
0:27:48
|
Now as we'll see on the command line, there's always going to be
|
|
0:27:51
|
three steps that we go through for any QoS configuration
|
|
0:27:55
|
regardless if this is on the router's IOS or the Catalyst IOS
|
|
0:28:00
|
the MQC is always going to have the same three-step logic.
|
|
0:28:04
|
First portion is that we need to define what type of traffic
|
|
0:28:08
|
we're trying to match to begin with.
|
|
0:28:10
|
This is going to be done with the class map
|
|
0:28:13
|
not to be confused with the legacy frame relay map
|
|
0:28:16
|
class so a class map is going to be for the MQC where the
|
|
0:28:21
|
map class is for legacy frame relay QoS.
|
|
0:28:28
|
Once we figure out what type of traffic we're trying to deal with
|
|
0:28:31
|
then we're going to define the QoS method through the policy map.
|
|
0:28:37
|
This is where we would specify are we doing prioritization or
|
|
0:28:40
|
a bandwidth reservation or shaping or policing or
|
|
0:28:44
|
weighted random early detection.
|
|
0:28:48
|
Then lastly the policy is going to be applied at the interface
|
|
0:28:52
|
with the service policy command and then we can verify this
|
|
0:28:56
|
by looking at either the show policy map or the show policy map
|
|
0:29:00
|
interface.
|
|
0:29:01
|
Now one of the key changes between the hierarchical
|
|
0:29:04
|
queuing framework and the previous class based weighed fair
|
|
0:29:08
|
queuing is that some of the verification has changed.
|
|
0:29:12
|
So some of the legacy commands like show queuing.
|
|
0:29:18
|
It says the show queuing and show queue commands are no longer
|
|
0:29:20
|
supported, instead you have to use the show policy map and show
|
|
0:29:23
|
policy map interface commands in order to gather QoS related statistics.
|
|
0:29:28
|
Now what this essentially means is that from here on out
|
|
0:29:33
|
there's no reason to apply any legacy QoS mechanisms.
|
|
0:29:38
|
So even if we're doing something as simple as just weighted fair queuing
|
|
0:29:43
|
this should be applied under a module of the quality of service syntax
|
|
0:29:49
|
and not directly at the interface level using the legacy QoS.
|
|
0:29:56
|
So even if the policy matches nothing and just says under
|
|
0:29:59
|
class default we want to do weighted fair queuing
|
|
0:30:02
|
even though that's essentially the same result as the legacy
|
|
0:30:06
|
fair queue command at the interface
|
|
0:30:08
|
simply based on the verification, we want to make sure that we can
|
|
0:30:12
|
actually see that this is working with the show policy map interface command.
|
|
0:30:18
|
So if we apply the legacy QoS, there's going to be no way
|
|
0:30:20
|
to verify it anymore.
|
|
0:30:23
|
So as I mentioned we'll see that the QoS configurations are
|
|
0:30:26
|
fairly straightforward. The bigger issue is to figure out
|
|
0:30:30
|
based on the particular problem what is the issue that they're
|
|
0:30:34
|
describing and which QoS methods are appropriate in order
|
|
0:30:38
|
to solve this particular issue.
|
|
0:30:42
|
So if the question is asking us to do shaping and we configure
|
|
0:30:46
|
policing, then regardless what the values we're putting in
|
|
0:30:49
|
it's not going to be what they want for that particular question.
|
|
0:30:53
|
Now specifically in the module of the quality of service's classification
|
|
0:30:58
|
where we're specifying what type of traffic is going to be
|
|
0:31:01
|
applied to QoS, we'll see that there's a number of different
|
|
0:31:05
|
criteria that we can match things as simple as a standard
|
|
0:31:10
|
access or an extended access list where the traffic is coming
|
|
0:31:13
|
in based on the source interface, different Layer 2 fields like the
|
|
0:31:18
|
source or destination Mac address
|
|
0:31:20
|
or we can get into application level matches with the
|
|
0:31:24
|
network based application recognition or the Nbar feature.
|
|
0:31:29
|
Now with the classification we can do multiple matches
|
|
0:31:31
|
at the same time which can get kind of confusing if we
|
|
0:31:36
|
don't understand the logic between the match any
|
|
0:31:38
|
and the match all and how the MQC is going to be
|
|
0:31:42
|
processing matches that occur on the same line versus multiple lines.
|
|
0:31:47
|
So here we have a visual workflow as to how the classification process
|
|
0:31:50
|
is going to work for the MQC
|
|
0:31:53
|
where we have a class that says we have class map 1
|
|
0:31:58
|
and it's going to match any of the inside child classes.
|
|
0:32:04
|
So essentially we're doing a multiple hierarchy policy
|
|
0:32:09
|
where one class is calling additional classes.
|
|
0:32:13
|
So class map 1 says I'm going to match either class 2 or class 3
|
|
0:32:19
|
where class 2 at the top says it's going to match all of these
|
|
0:32:22
|
parameters which are an access group, so it's going to be
|
|
0:32:27
|
either a standard or extended access list
|
|
0:32:29
|
and the packet's length.
|
|
0:32:32
|
So this means that for class map 2 to be true
|
|
0:32:36
|
not only does the access list match have to occur
|
|
0:32:40
|
but the IP packet payload, so this is not including the Layer 2
|
|
0:32:45
|
header, the IP packet payload would have to be somewhere
|
|
0:32:48
|
between X and Y where X is the minimum length
|
|
0:32:53
|
in bytes and Y is the maximum length in bytes.
|
|
0:32:55
|
Now for the bottom class that is class map 3
|
|
0:32:59
|
even though this is saying match all
|
|
0:33:02
|
we're saying match IP precedence 1, 2, 3
|
|
0:33:05
|
since all three of these are specified in a
|
|
0:33:09
|
single line, it's actually a logical Or not a logical And.
|
|
0:33:16
|
So sometimes you can get into these logic problems
|
|
0:33:18
|
whether you're calling the matches on one single line
|
|
0:33:21
|
versus multiple lines
|
|
0:33:26
|
where again, if you match them on multiple lines, the matches are going to
|
|
0:33:29
|
happen independently and if you match them on one
|
|
0:33:32
|
single line, it's going to be a logical Or.
|
|
0:33:34
|
Now just like a route map or an access list, the MQC policy
|
|
0:33:37
|
is going to be processed in a top-down fashion
|
|
0:33:41
|
so when we define the classes to match the traffic
|
|
0:33:45
|
then actually apply the policy to it, we will see that the
|
|
0:33:49
|
order is specific as to how the classes are referenced from
|
|
0:33:54
|
inside of the policies.
|
|
0:33:57
|
Now a good example of this would be if we were
|
|
0:33:59
|
trying to match all IP traffic
|
|
0:34:03
|
versus some more specific subnet of an IP protocol.
|
|
0:34:08
|
So let's say that we have two different classes.
|
|
0:34:11
|
Class number 1 says class map IP match
|
|
0:34:18
|
protocol IP
|
|
0:34:22
|
so it's saying just look for basically the Layer 2 protocol
|
|
0:34:26
|
type code like if this is Ethernet, we're going to
|
|
0:34:28
|
look at the Ether type value to see if it's 0 by 800
|
|
0:34:33
|
If that match is true, then we're going to break out of the policy map
|
|
0:34:36
|
or actually apply whatever QoS mechanism we have an
|
|
0:34:39
|
then break out of the policy map.
|
|
0:34:43
|
Then if we had a more specific match let's say class map telnet
|
|
0:34:50
|
that says match protocol telnet
|
|
0:35:00
|
since we know that telnet is part of the IP stack
|
|
0:35:03
|
specifically it's a TCP application that's using
|
|
0:35:06
|
port 23 by default, this means that once we
|
|
0:35:10
|
call these from inside the policy map, if I say
|
|
0:35:14
|
policy map P1
|
|
0:35:18
|
then I reference class IP
|
|
0:35:21
|
with whatever QoS mechanism before I reference class telnet
|
|
0:35:30
|
what is then going to happen with the second class of telnet here?
|
|
0:35:33
|
It's never going to match anything because since the policy is processed
|
|
0:35:38
|
in a top-down fashion, as soon as the first match occurs
|
|
0:35:41
|
that says that this is IP traffic, the classifier
|
|
0:35:45
|
applies whatever policy that we define could be a bandwidth
|
|
0:35:49
|
reservation, it could be policing, shaping, low latency queuing
|
|
0:35:53
|
once we apply that method, we're never going to check
|
|
0:35:56
|
the next class which is telnet.
|
|
0:36:01
|
So in general, when we're doing the classification
|
|
0:36:05
|
we want the policy to be applied from the most
|
|
0:36:07
|
specific match down to the least specific match
|
|
0:36:12
|
where the least specific match is going to be the
|
|
0:36:14
|
scavenger class that is known as class-default.
|
|
0:36:23
|
So every policy we define is automatically going to
|
|
0:36:27
|
have class-default which is going to be a catchall
|
|
0:36:29
|
for any particular applications that we do not manually define.
|
|
0:36:37
|
Now we'll see also that there is a change in the behavior
|
|
0:36:39
|
of class default from the previous class based weighted
|
|
0:36:44
|
fair queuing versus the new hierarchical queuing framework.
|
|
0:36:48
|
It has to do with the queuing mechanism that class default is using
|
|
0:36:51
|
and the reservation of the amount of bandwidth that class default has.
|
|
0:36:56
|
Now as I mentioned, once we match the different types of traffic
|
|
0:37:00
|
do the classification with either the Layer 2 or Layer 3 markings
|
|
0:37:04
|
like the frame relay discard eligibility or the IP precedence
|
|
0:37:09
|
then we're actually going to apply the QoS mechanism.
|
|
0:37:13
|
So in general, the classification of the traffic should be pretty
|
|
0:37:16
|
straightforward. If the question is saying I want to match
|
|
0:37:20
|
web traffic, then there's only a limited number of ways that
|
|
0:37:23
|
we can do that. We could either say match TCP port 80
|
|
0:37:27
|
in an access list or just say match protocol http with nbar.
|
|
0:37:33
|
The next step though is going to be a little bit more complicated
|
|
0:37:36
|
to figure out what is the specific QoS type that we actually
|
|
0:37:40
|
want to apply onto this traffic.
|
|
0:37:44
|
So before we get to the detailed differences between the
|
|
0:37:47
|
different QoS types, let's take a look at the command line
|
|
0:37:50
|
and make sure we understand how the different classifications
|
|
0:37:54
|
can work and then the general three point syntax of defining the
|
|
0:37:59
|
class map, defining the policy map and then applying the
|
|
0:38:02
|
service policy to the interface works.
|
