|
0:00:14
|
In our next section here for the asa we'r going to talk about the quality of service, features
|
|
0:00:19
|
which as compared to other platforms like the routers or layer 2 switches
|
|
0:00:24
|
there are not as many features that you can figure
|
|
0:00:26
|
with the qos and the asa's
|
|
0:00:28
|
and mainly this is going to focus on the modular policy framework that we'r looking at before
|
|
0:00:34
|
with the class maps and the policy maps
|
|
0:00:37
|
in order to implement either traffic policing
|
|
0:00:39
|
traffic priortirization
|
|
0:00:41
|
traffice shaping or queing higher archive
|
|
0:00:44
|
which is going to allow us to do shaping and
|
|
0:00:47
|
prioritization at the same time
|
|
0:00:52
|
now as the nature the qos is implemented with the modular policy syntax
|
|
0:00:57
|
we see that when multiple context mode its not going to be supported
|
|
0:01:03
|
so mainly this qos features are just going to be for single context mode routerd firewall
|
|
0:01:09
|
not for the multi context mode, or for the transparent firewall features
|
|
0:01:15
|
now for the specific qos that we support
|
|
0:01:19
|
as i mentioned its going to be traffic policing
|
|
0:01:22
|
which can be both inbound and outbound
|
|
0:01:25
|
and either configured both globally or inferred interace basis
|
|
0:01:30
|
or is traffic shaping can only configured outbound
|
|
0:01:35
|
and likewise for priority queing can only be configured outbound
|
|
0:01:40
|
now for priority queing, we can also do this with the
|
|
0:01:44
|
higher acticle queing which means that w're both shaping
|
|
0:01:47
|
and doing priotization at the same time
|
|
0:01:53
|
now with our first method which is traffic policing
|
|
0:01:56
|
we use this to limit the particular rate of a traffic
|
|
0:01:59
|
as it is either coming in an interface or as is it going outbound
|
|
0:02:05
|
so as we talked about the application of about the direction of the policies
|
|
0:02:09
|
as when we actually apply the service policy to the configuration
|
|
0:02:13
|
it is not asked as the interface
|
|
0:02:15
|
as the direction to apply on the interface
|
|
0:02:18
|
which means that the qos policy is then going to be controlled
|
|
0:02:21
|
wheter we are saying police input or police output
|
|
0:02:26
|
for the other two mechanisms we will shaping and priotization
|
|
0:02:28
|
those are only output queing features
|
|
0:02:33
|
now since policing can be applied and both globally and per interface
|
|
0:02:37
|
again we end up in that operations type issue
|
|
0:02:40
|
where we need to know which one is actually going to be applied
|
|
0:02:43
|
is it the global one or is it the interface one
|
|
0:02:45
|
where in this case we are releasing both globally and at the interface level
|
|
0:02:50
|
the more specific per interface setting is override which is in the global policy
|
|
0:02:56
|
now one thing that is different
|
|
0:02:59
|
about policing and asa versus some of the other platforms
|
|
0:03:02
|
is that the policing applies to the class overall
|
|
0:03:06
|
which means that it is an aggreagate policer
|
|
0:03:11
|
now the potential problem that we run into
|
|
0:03:13
|
is that when we are doing
|
|
0:03:15
|
vpn termination wheter it is for site to site vpn's
|
|
0:03:20
|
or remote access vpn's with ipsec or ssl
|
|
0:03:23
|
typically we would want to use qos
|
|
0:03:26
|
to get an individual user
|
|
0:03:28
|
different gurantees onto the network
|
|
0:03:30
|
so this is one of the few exceptions here
|
|
0:03:33
|
with qos and asa
|
|
0:03:35
|
is that the policing can be supported per flow
|
|
0:03:38
|
but only when y're using within the application of the vpn's
|
|
0:03:43
|
so we will see later when we get the more advanced
|
|
0:03:46
|
features of the tunnel groups and the group policies
|
|
0:03:50
|
there are different qos policies that we can apply
|
|
0:03:53
|
onto a proper proper use bases
|
|
0:03:55
|
for the vpn termination
|
|
0:04:02
|
now the configuration of the traffic policing
|
|
0:04:04
|
is very straight foreward
|
|
0:04:06
|
we simply specify what is the particular type of traffic that we want to apply it onto
|
|
0:04:11
|
in this case we are policing icmp
|
|
0:04:14
|
then we specify whether is it the input rate or outpur rate
|
|
0:04:18
|
or bulk that we are trying to apply onto the traffic
|
|
0:04:22
|
now it does take both the policing rate
|
|
0:04:26
|
in bit per second and then a burst value
|
|
0:04:30
|
but you don't need to configure the burst value
|
|
0:04:33
|
unless you have a very specfic latency application
|
|
0:04:36
|
that you need the policer to run a certain amount of time per sec
|
|
0:04:40
|
just like in the router policy service
|
|
0:04:43
|
when you configure the policing rate
|
|
0:04:45
|
it is automatically going to
|
|
0:04:47
|
know what is the proper burst value based on that particular
|
|
0:04:51
|
bit per sec value that you are tying to achieve
|
|
0:04:54
|
now if you do want to confiugre the burst value
|
|
0:04:57
|
you want to make sure that you are aware
|
|
0:04:59
|
that the policing rate is in bits per second
|
|
0:05:04
|
but the burst value is in buts
|
|
0:05:07
|
so in order to convert them you would first need to take your bit per sec value
|
|
0:05:11
|
divide it by 8 to convert it to bytes
|
|
0:05:13
|
and then decide how many times you want the policer to run over the sec
|
|
0:05:20
|
so can see here the service policy being applied
|
|
0:05:22
|
it's applied to the outside interface
|
|
0:05:25
|
but then the actual direction of the traffic flow
|
|
0:05:28
|
is based on how the policing is actually configured whether it is input policing
|
|
0:05:32
|
or wheter it is output policing
|
|
0:05:35
|
so lets take a look at the basic example of this
|
|
0:05:39
|
on the asa's command line
|
|
0:05:41
|
and we have asa to that has a link connected to the outside
|
|
0:05:46
|
and two interfaces that are sharing
|
|
0:05:48
|
with the inside and with the dmz
|
|
0:05:51
|
so i want to configure asa to the limit the amount of traffic that is coming in on the outside or going out
|
|
0:05:57
|
going out the outside interface
|
|
0:06:00
|
and we will do this basic
|
|
0:06:02
|
based on the just simple icmp traffic
|
|
0:06:06
|
now again the policy is going the apply here
|
|
0:06:10
|
aforesaying for
|
|
0:06:12
|
input policing of icmp
|
|
0:06:14
|
this is going to apply assuming that we pass our access list checks
|
|
0:06:18
|
and the traffic is actually going to be allowed from the lower security level interface
|
|
0:06:23
|
to the higher security level interface
|
|
0:06:26
|
so wer not allowing traffic outside in or outside to dmz
|
|
0:06:30
|
that we don't necessarily need to police the traffic
|
|
0:06:37
|
so let go to asa 2's command line
|
|
0:06:41
|
and if you look at the show
|
|
0:06:44
|
service policy
|
|
0:06:46
|
we can see that they are
|
|
0:06:48
|
there is a global policy
|
|
0:06:50
|
that is applied to all of the interface
|
|
0:06:53
|
are interfaces which again, the default policy, global policy
|
|
0:06:57
|
then we have a specific policy that's applied in on the dmz
|
|
0:07:03
|
so if i want to police these seperate rates i could configure
|
|
0:07:06
|
the dmz in class
|
|
0:07:08
|
with policing values
|
|
0:07:10
|
that would apply just to that interface
|
|
0:07:12
|
where as the global policy
|
|
0:07:14
|
with that apply to the outside in the inside interfaces
|
|
0:07:19
|
so this is one of the exceptions
|
|
0:07:21
|
where if the attributes do overlap between the policies
|
|
0:07:25
|
we'r not going to combine them together we'r choose whatever the more specific policy
|
|
0:07:30
|
that is applied at the interface level
|
|
0:07:32
|
as oposed to the combination between the two
|
|
0:07:36
|
so lets say under asa now we want to limit the icmp traffic
|
|
0:07:40
|
to a low grade because its just for
|
|
0:07:42
|
for basic mangement testing with icmp
|
|
0:07:46
|
we want to make sure not taking up 10 mbits per sec
|
|
0:07:49
|
on the outside interface
|
|
0:07:57
|
so just like any other, other policies
|
|
0:07:59
|
frist step is going to be to classify the traffic
|
|
0:08:02
|
so we will configure an access list
|
|
0:08:05
|
we will say access list icmp
|
|
0:08:07
|
is going to permit any icmp traffic
|
|
0:08:11
|
now first could be more specific here, we could say the specific type code
|
|
0:08:15
|
is this echo, is this echo reply
|
|
0:08:17
|
is this time exceeded is this port unreachable
|
|
0:08:20
|
in this case, im saying
|
|
0:08:21
|
as could match the protocol no.
|
|
0:08:24
|
icmp
|
|
0:08:25
|
then its fall under the classifier and then ultimately
|
|
0:08:29
|
fall into the policer
|
|
0:08:31
|
next that we have a class map
|
|
0:08:34
|
that is going to call icmp
|
|
0:08:36
|
notice this a regular layer 3 layer four class
|
|
0:08:39
|
its not an inspection class for layer 7
|
|
0:08:43
|
so the policing will be applied to our normal
|
|
0:08:45
|
layer 3 layer 4 class now the class map type inspect
|
|
0:08:49
|
or match the
|
|
0:08:52
|
access list
|
|
0:08:54
|
that is called icmp
|
|
0:08:57
|
then iam going to create a new policy map
|
|
0:09:00
|
that is going to be for the
|
|
0:09:02
|
outside interface
|
|
0:09:05
|
so policy map outside fs class is icmp
|
|
0:09:08
|
im going to apply policing onto it
|
|
0:09:13
|
so we see we have the option of the direction is it input or output
|
|
0:09:16
|
i will say that for output policing
|
|
0:09:19
|
im going to limit this to 64000 bits per sec or 64K
|
|
0:09:24
|
now i can't specify what's going to happen
|
|
0:09:27
|
on the
|
|
0:09:29
|
interval basis over the sec
|
|
0:09:31
|
how often the policer is going to run
|
|
0:09:34
|
but if i simply leave this
|
|
0:09:35
|
as just police output 64000
|
|
0:09:38
|
again the asa is going to figure out what is the appropriate burst value
|
|
0:09:42
|
for this target rate that we are tying to
|
|
0:09:45
|
to achieve, 64000 bits per sec
|
|
0:09:52
|
so next lets apply this to the link, we will say service policy
|
|
0:09:57
|
policies name is outside
|
|
0:09:59
|
is applied to interface outside
|
|
0:10:03
|
now assuming they are allowing icmp traffic through
|
|
0:10:07
|
based on the inpection policy
|
|
0:10:09
|
lets go to router 6
|
|
0:10:12
|
and we will do a ping from the inside of the asa to the outside
|
|
0:10:16
|
so we will simple ping
|
|
0:10:19
|
router 2 link
|
|
0:10:24
|
so we see that based on the fact we do get the respons
|
|
0:10:27
|
we know either that we are sending icmp through the mps inspection engine
|
|
0:10:32
|
or we have an access list that doing a manual exception for this
|
|
0:10:37
|
now this is going to matter which is occuring
|
|
0:10:39
|
because as long as the traffic is going to be allowed through
|
|
0:10:42
|
then its going to fall down to the policer
|
|
0:10:46
|
one of the commands you can do to test this
|
|
0:10:50
|
whether your traffic flow is actually going to be allowed
|
|
0:10:53
|
is the packet tracer
|
|
0:10:56
|
so the packet is going to say that the traffic is input
|
|
0:11:00
|
unlike inside interface
|
|
0:11:03
|
if it were icmp
|
|
0:11:05
|
coming from lets say router 5 address
|
|
0:11:10
|
and the icmp type
|
|
0:11:13
|
is going to be an echo, so i would actually need to know what this is
|
|
0:11:18
|
and here we can find this in the documentation
|
|
0:11:21
|
so if we go to the asa configuration guide
|
|
0:11:24
|
all the way down to the bottom under reference
|
|
0:11:28
|
address's protocols and ports
|
|
0:11:31
|
the
|
|
0:11:32
|
icmp types
|
|
0:11:34
|
where specifcally icmp echo
|
|
0:11:36
|
is type 8 code 0
|
|
0:11:40
|
and in reply is type 0 code 0
|
|
0:11:46
|
so here my icmp type is 8
|
|
0:11:49
|
the code is 0
|
|
0:11:52
|
the destination is
|
|
0:11:55
|
lets say router 2 200.0.0.2
|
|
0:12:00
|
and now it tells is whether
|
|
0:12:02
|
based on
|
|
0:12:04
|
the different process it has to go through, is this actually going to be allowed or not
|
|
0:12:09
|
the final action we could go through the details of this
|
|
0:12:12
|
but it's the final is that
|
|
0:12:14
|
this traffic is being allowed
|
|
0:12:17
|
so from router 5 if we actually do that ping
|
|
0:12:20
|
we could see that the results we are getting
|
|
0:12:23
|
that it is actally working
|
|
0:12:25
|
now that for reason this was blocked by a policy
|
|
0:12:29
|
if we look at the show
|
|
0:12:31
|
policy map or show
|
|
0:12:34
|
show run policy map
|
|
0:12:40
|
for the global policy
|
|
0:12:43
|
im inspecting icmp for everything
|
|
0:12:46
|
if i were inspecting icmp as in one of the previous examples where we were doing in perhost basis
|
|
0:12:52
|
then we would see in the packet tracer
|
|
0:12:54
|
its going to say that is denied based on the fact that the
|
|
0:12:57
|
the traffic is not going through the mpm
|
|
0:13:00
|
now if we did this the other way around
|
|
0:13:03
|
if we said lets run the packet tracer on the outside interface
|
|
0:13:10
|
and its coming from 200.0.0.2
|
|
0:13:14
|
going to 10.0.125.5
|
|
0:13:19
|
it tells us that the action is dropped
|
|
0:13:22
|
and the reason is that its denied by a configure role
|
|
0:13:25
|
specifically in this case the rule is that we are not allowed to go from the lower security interface
|
|
0:13:31
|
to the higher security interface
|
|
0:13:35
|
now this is not directly related to the qos
|
|
0:13:37
|
but it would one method that you could check whether the traffic is actually is going to match by the qos policy
|
|
0:13:43
|
because the asa is going to drop it anyways
|
|
0:13:46
|
then the qos is not really going to make any difference
|
|
0:13:50
|
but if you trying to troubleshoot some kind of access filtering problem
|
|
0:13:53
|
and you are not really sure is this related to monitor policy framework
|
|
0:13:57
|
is it related to access list or some other type of filter
|
|
0:14:01
|
then the packet tracer command
|
|
0:14:03
|
here is good way to quickly see what exactly the problem is
|
|
0:14:10
|
so now lets look at the show
|
|
0:14:12
|
show service policy interface
|
|
0:14:15
|
outside
|
|
0:14:18
|
and it shows us
|
|
0:14:20
|
that for this particular class we r doing output policing
|
|
0:14:23
|
the rate is 64000 bits per sec
|
|
0:14:27
|
with a burst committed value of 2000 bytes
|
|
0:14:31
|
so esstentially this means
|
|
0:14:33
|
that for the every time the policer runs
|
|
0:14:36
|
we can sends upto 2000 bytes
|
|
0:14:38
|
before we have to wait for the next policing interval
|
|
0:14:42
|
now specificaly in this case
|
|
0:14:44
|
this would mean that the policer runs 4 times per sec
|
|
0:14:48
|
because 64000 bits per sec
|
|
0:14:51
|
is actually 8000 bytes per sec
|
|
0:14:54
|
and would take 8000 bytes per sec
|
|
0:14:56
|
with a burst value of 2000
|
|
0:14:58
|
with the policers running 4 times over the sec
|
|
0:15:03
|
now again the details of the how the intervals are actually calculated
|
|
0:15:07
|
most of the time it doesn't really matter
|
|
0:15:09
|
unless you have a
|
|
0:15:11
|
an application that is very sensitive
|
|
0:15:13
|
to latency, like voice over ip some sort of real time flows
|
|
0:15:18
|
typically when you do that
|
|
0:15:21
|
you would not like your real time flows to police to begin
|
|
0:15:25
|
you would ideally want them in the priority que
|
|
0:15:28
|
and if did need to limit the traffic
|
|
0:15:30
|
you would combine the priority queing with the shaper
|
|
0:15:35
|
which is the case considered the higher article tune
|
|
0:15:37
|
therefore shaping lower the alphabat
|
|
0:15:41
|
also doing priotization
|
|
0:15:44
|
make sure the real time close getting today ahead
|
|
0:15:47
|
of after tune
|
|
0:15:50
|
so now take a look from the inside
|
|
0:15:53
|
network, lets do some things here
|
|
0:15:56
|
but we'r set this to bea hyper peak out
|
|
0:16:00
|
and a timeout of zero
|
|
0:16:04
|
and im going to do this full, from router 6 and router 5
|
|
0:16:09
|
so the timeout is zero and the repeat time is 5
|
|
0:16:12
|
so goint to send some of the bunch of icmp traffic from the inside out
|
|
0:16:17
|
if we now look at the show service policy interfacing in
|
|
0:16:22
|
we can see not all of the traffic is actually being forwarded
|
|
0:16:26
|
because
|
|
0:16:28
|
we are exceeding
|
|
0:16:29
|
what the policing wer setting is
|
|
0:16:32
|
so there are more packets there exceeding then conforming
|
|
0:16:36
|
and the ones that are conformed that the actual rate we are
|
|
0:16:40
|
getting
|
|
0:16:42
|
so if we're look at this for a longer term average
|
|
0:16:45
|
the conformed rate is going to be somewhere closed to 64000 bits per sec
|
|
0:16:50
|
we could see in this case its
|
|
0:16:52
|
a little bit
|
|
0:16:52
|
below 64000 its a bit above 64000
|
|
0:16:56
|
but over the long term average
|
|
0:16:59
|
we could never see it to go over
|
|
0:17:01
|
what the confirmed rate or committed rate of information that were defining it
|
|
0:17:09
|
now the next feature we have for qos
|
|
0:17:11
|
on the asa is the priority que
|
|
0:17:14
|
then its going to be configured in two places
|
|
0:17:17
|
the first is that we are going to enable on a
|
|
0:17:19
|
per interface basis
|
|
0:17:21
|
with the priority que command followed by the interface
|
|
0:17:25
|
like i will say prioity que outside or priority que inside
|
|
0:17:29
|
and at the link level what we can figure the priority que
|
|
0:17:33
|
we can control the depth
|
|
0:17:34
|
of the que of the que limit
|
|
0:17:37
|
which controls how many packets can be in the priority que
|
|
0:17:41
|
before we start to do what known as tail drop
|
|
0:17:43
|
so since that we drop packets because we don't have enough buffers
|
|
0:17:47
|
to allocate to that particular that type of traffic
|
|
0:17:50
|
the other option we have is the transmit ring limit
|
|
0:17:56
|
were the transmit ring is the harware que of the interface
|
|
0:18:00
|
and the queis the software quemen is the software que
|
|
0:18:03
|
are they trying to hold on to the traffic before we are actually admitting it
|
|
0:18:07
|
down to the transmit ring
|
|
0:18:10
|
so for the security applications
|
|
0:18:12
|
you really dont need to get into too much detail as exactally how the qos mechanism's are working
|
|
0:18:19
|
because the policing to shaping the prioritisation
|
|
0:18:22
|
are some of the three most basic
|
|
0:18:24
|
qos tools that we have
|
|
0:18:26
|
so really the only thing this is designed to do the priority queing
|
|
0:18:30
|
is to make that are
|
|
0:18:32
|
important application like voice over ip
|
|
0:18:35
|
or maybe video conferencing
|
|
0:18:38
|
is going to send out the interface
|
|
0:18:40
|
before the other non-real time flows like before web browsing or before ftp download for example
|
|
0:18:49
|
so once the priority que is enabled on the interface
|
|
0:18:52
|
then we are going to specify what exact traffic is going to assigned to
|
|
0:18:57
|
and dot this with teh monitor policy framework
|
|
0:19:00
|
similar to how we define
|
|
0:19:02
|
what traffic is going into the policer
|
|
0:19:05
|
or as will see what type of traffic will go into the shaper
|
|
0:19:11
|
so under the policy map we'r going to use the priority statement
|
|
0:19:14
|
which is a little bit different then how we have this in the ios or some of the other platforms
|
|
0:19:20
|
because the priority queing here
|
|
0:19:22
|
is not having built in policing function
|
|
0:19:26
|
they say what is the limit
|
|
0:19:27
|
of the bit per sec value
|
|
0:19:29
|
that you can actually be sending in the priority traffic
|
|
0:19:33
|
so the only way to limiting the priority que here
|
|
0:19:37
|
is with the que depth or the que limit at the link level
|
|
0:19:41
|
so if i wer to say the que limit were a 100 packets
|
|
0:19:45
|
if im making multiple
|
|
0:19:47
|
voice phonecalls or multiple real time flows
|
|
0:19:50
|
as soon as the que gets 100 packets
|
|
0:19:54
|
the next packets that comes in is going to be dropped
|
|
0:19:57
|
so since we do not have a policer built into the prioritisation
|
|
0:20:01
|
we need to make sure that other non real time flows
|
|
0:20:05
|
do not get starved or bundled
|
|
0:20:09
|
and again the issue is why
|
|
0:20:10
|
why we need to do this is not so policing at the same time
|
|
0:20:15
|
when we look at this from the routers implementation
|
|
0:20:19
|
the low link que or the priority que
|
|
0:20:21
|
typically has a built in policer
|
|
0:20:23
|
that we say this flow is the
|
|
0:20:25
|
priority que
|
|
0:20:27
|
for we want to limit it to a certain value at the same time
|
|
0:20:30
|
so my be my phone calls are the priority traffic
|
|
0:20:33
|
but there only priority
|
|
0:20:34
|
to 768k or
|
|
0:20:37
|
somthing less then that
|
|
0:20:43
|
so configuration wise this is similar
|
|
0:20:45
|
to the
|
|
0:20:47
|
traffic policing
|
|
0:20:49
|
but again since this is an output only feature
|
|
0:20:53
|
we do not need to specify a direction in the service policy
|
|
0:20:57
|
or direction in the class
|
|
0:20:59
|
or the policy map we are actually applying
|
|
0:21:03
|
so just like any other in the mpf
|
|
0:21:06
|
the first we need to
|
|
0:21:08
|
match what is the particular traffic
|
|
0:21:10
|
and this case we are saying match rtp traffic
|
|
0:21:14
|
which a sub encapculation of utp
|
|
0:21:17
|
that the real time protocol
|
|
0:21:19
|
or we'r saying look at port values
|
|
0:21:22
|
that started 16 384
|
|
0:21:24
|
and go
|
|
0:21:26
|
through a range 16 383
|
|
0:21:30
|
so the actual port nos are 16 384 to 32 767
|
|
0:21:35
|
and that's the port range that voice over ip phone is going to use
|
|
0:21:39
|
its going to use some random ports that are depending on
|
|
0:21:41
|
how are actually does the call send
|
|
0:21:45
|
now a other typical way that you could do this
|
|
0:21:47
|
will be to rely
|
|
0:21:49
|
on your
|
|
0:21:50
|
edge classifcasation
|
|
0:21:54
|
and using layer 3 marking like the dscpaef
|
|
0:21:57
|
for expertite forwarding
|
|
0:21:59
|
or teh ip percence 5 value
|
|
0:22:01
|
that your actual phone
|
|
0:22:03
|
is marking your traffic as it is send to the network
|
|
0:22:07
|
so how we are doing the classification wtheter its based on the
|
|
0:22:11
|
the port nos or based on the layer 3 pattern
|
|
0:22:15
|
what if we classify
|
|
0:22:17
|
we'r going to
|
|
0:22:18
|
match this thing under teh policy map
|
|
0:22:20
|
specified with that
|
|
0:22:21
|
class is the priority class
|
|
0:22:24
|
and then enable
|
|
0:22:25
|
the priotiy que on the interface
|
|
0:22:30
|
now there is a question here just this reserve the bandwidth in the output que
|
|
0:22:36
|
it reserve bandwidth but its a little bit different applicaiton
|
|
0:22:40
|
then
|
|
0:22:41
|
we see on the other platforms how it is implemented
|
|
0:22:44
|
its only doing a reservation based on the depth
|
|
0:22:47
|
of the que
|
|
0:22:48
|
not on a bandwith per sec
|
|
0:22:51
|
basis
|
|
0:22:53
|
so typically what we need to do is to look at what the physical links that we'r using r we using r we using a full fast ethernet interface or we'r using a full
|
|
0:23:02
|
gatelink
|
|
0:23:03
|
then look at
|
|
0:23:04
|
what is the exact traffic pattern of the real time traffic
|
|
0:23:08
|
so in the case of voicer over ip, what's the specific
|
|
0:23:11
|
code that we'r using
|
|
0:23:13
|
and based on that how much
|
|
0:23:15
|
bandwidth doest that individual phone call need
|
|
0:23:18
|
and then we would potentialy able to predict
|
|
0:23:21
|
how large the que need to be
|
|
0:23:25
|
in order to accomodate all of the flows at the same time
|
|
0:23:29
|
but the again the que limit there
|
|
0:23:31
|
this is
|
|
0:23:33
|
the sort of
|
|
0:23:35
|
policer that w're using
|
|
0:23:36
|
but its based on the no. of packets, its not on the based on the bandwidth value
|
|
0:23:44
|
now our third method with traffic shaping
|
|
0:23:47
|
this is somewhere to traffic policing
|
|
0:23:49
|
in the term is it trying to limit the rate of traffic
|
|
0:23:53
|
but generally this is used when we are trying to
|
|
0:23:57
|
have a sub-rate connection access
|
|
0:24:00
|
where for example we are using
|
|
0:24:03
|
metro ethernet connection
|
|
0:24:05
|
that's a 100 mbits per sec
|
|
0:24:06
|
but we only have a 15mb per sec guarantee
|
|
0:24:10
|
where the service provider says if you go above 15 mega bits per sec your traffic is going to be dropped
|
|
0:24:17
|
so typically traffic shaping would be used to outbound
|
|
0:24:20
|
in order to format our traffic
|
|
0:24:23
|
in order to match the service providers
|
|
0:24:25
|
input policer
|
|
0:24:28
|
now in the previous example w're using policing both input and output
|
|
0:24:32
|
but typically those are going to for your scavenger type traffic classes
|
|
0:24:36
|
like in the case of icmp
|
|
0:24:38
|
we not only care for some end host
|
|
0:24:39
|
pings are not getting through
|
|
0:24:42
|
but for traffic shaping this is what we use for overall rate
|
|
0:24:46
|
of traffic that is going outof length
|
|
0:24:48
|
if the physical access rates
|
|
0:24:51
|
which is going to be either fast ethernet or
|
|
0:24:53
|
gig ethernet depending on the asa flatform
|
|
0:24:57
|
and if the other side of link is not guranteeing us the entire link
|
|
0:25:03
|
so if we were to try to visualise this
|
|
0:25:06
|
if we had our own internal network
|
|
0:25:11
|
and the asa is the last hub device
|
|
0:25:15
|
before we go out to the service provider
|
|
0:25:18
|
on the service provider edge the pe device
|
|
0:25:22
|
must have the full access rate of the interface
|
|
0:25:26
|
they are going to be doing some sort of input policing
|
|
0:25:34
|
so the provider esentially says
|
|
0:25:36
|
im going to allow traffic into my network upto a certain rate
|
|
0:25:40
|
if you exceed that rate im going to drop whatever else is above that
|
|
0:25:45
|
so if the provider edge is input policing to 10 mega bits per sec
|
|
0:25:51
|
it does make sense that we would send your traffic outbaound at 100 mega bits per sec
|
|
0:25:56
|
because 90 per of the traffic is automatically going to be dropped
|
|
0:26:00
|
assuming that the interface is actually 100 per
|
|
0:26:05
|
so instead what we'r doing for the traffic shaping
|
|
0:26:08
|
it to try to this rate
|
|
0:26:10
|
and slow it down
|
|
0:26:12
|
to match what they are input policing
|
|
0:26:17
|
with the assumption that the traffic that goes above 10 mega bit per sec rate
|
|
0:26:22
|
we would try to que it up
|
|
0:26:24
|
to send at a later
|
|
0:26:26
|
traffic shaping interval
|
|
0:26:28
|
so whether that the 10 milisec from now or one sec from now
|
|
0:26:32
|
the idea is that we don't want to drop our own traffic outbound
|
|
0:26:36
|
we want to try to que it up
|
|
0:26:38
|
sothat we can match whatever the input policing rate is on the other side
|
|
0:26:43
|
and what's sometimes called that subrate access
|
|
0:26:47
|
if any time you are effective traffic rate
|
|
0:26:50
|
is not equal to physical interface in hand
|
|
0:26:54
|
so the interface for
|
|
0:26:59
|
for the provider is policing in at 15
|
|
0:27:02
|
that's your effective
|
|
0:27:06
|
now the actual configuration for this is going to use the average command
|
|
0:27:10
|
in the default class
|
|
0:27:12
|
so its going to be applying to all of the traffic essentially
|
|
0:27:17
|
but it does support a higher of que which is the
|
|
0:27:21
|
policy map point from inside on policy
|
|
0:27:25
|
and the specific application in the case of the asa
|
|
0:27:28
|
is just for priority que
|
|
0:27:31
|
so this is used in the same case where
|
|
0:27:34
|
we have physically fast etherenet link
|
|
0:27:37
|
but the sub rate access is 15 megabits per sec
|
|
0:27:41
|
but at the same time inside those 15 megs i want to make sure that my voice traffic is send first
|
|
0:27:47
|
so when im going to combine
|
|
0:27:50
|
the traffic shaping is the outer parent policy
|
|
0:27:54
|
then the priotirisation on the inside as the child policy
|
|
0:27:58
|
so that the overall traffic rate is never over 15 mega bits per sec
|
|
0:28:03
|
but the inside that rate the voice traffic is going to get priority treatment
|
|
0:28:10
|
so here we have the configuration example of just the overall output shaping rate
|
|
0:28:15
|
we were saying that the effectively the link is just limited
|
|
0:28:18
|
to 15 megabits per sec
|
|
0:28:21
|
for all traffic that leaves towards the outside interface
|
|
0:28:27
|
where a higher arche of queing
|
|
0:28:29
|
would be to take the same logic of the shaping rate
|
|
0:28:33
|
for 15 million bits per sec or 15 megabits per sec
|
|
0:28:37
|
and were calling the child policy
|
|
0:28:40
|
which is then doing the priotirisation of the voice traffic
|
|
0:28:45
|
so again we have a second way of classfication of voice
|
|
0:28:49
|
in this case we were saying look at the layer 3 packet marking
|
|
0:28:53
|
and look for the different services both point or dhcp
|
|
0:28:57
|
marking for expertite forwarding of ef
|
|
0:29:01
|
so your actual ip phone by default when it makes the phone call
|
|
0:29:05
|
it going to generate its own traffic with this marking with dhcp ef
|
|
0:29:10
|
so assuning that your qos classification policy is correct upto the edge
|
|
0:29:14
|
the end result of this
|
|
0:29:16
|
is that the asa would always send a voice traffic first
|
|
0:29:19
|
but as an aggregate
|
|
0:29:21
|
the entire link would never go above 15 megabits per sec
|
