|
0:00:13
|
In our next QoS section here, we're going to talk about
|
|
0:00:15
|
traffic shaping that is designed to slow the output
|
|
0:00:19
|
rate down as we are moving traffic from the output
|
|
0:00:22
|
queue down to the transmit ring.
|
|
0:00:25
|
Now ultimately, the goal of traffic shaping is to smooth out
|
|
0:00:30
|
or to normalize the traffic weight rate that we are sending
|
|
0:00:33
|
packets out the interface.
|
|
0:00:36
|
So essentially we're going to take packets that would normally be
|
|
0:00:39
|
going out the link and we are going to delay or queue them up
|
|
0:00:43
|
once they exceed a configured rate.
|
|
0:00:47
|
Now the only time that traffic shaping is going to be
|
|
0:00:49
|
required is when the physical serialization rate of the link
|
|
0:00:54
|
which again is based on the physical clocking of the interface's
|
|
0:00:57
|
hardware where the serialization rate outbound is not matching
|
|
0:01:03
|
what is being policed inbound.
|
|
0:01:08
|
So if for example we had a DS3 frame relay
|
|
0:01:11
|
link that is clocked at 45 megabits per second
|
|
0:01:15
|
if we are not actually guaranteed 45 megabits per second by the
|
|
0:01:19
|
provider and when they receive traffic inbound
|
|
0:01:22
|
they are policing it
|
|
0:01:24
|
generally, we would want to configure traffic shaping
|
|
0:01:27
|
outbound to match what their metered rate inbound is.
|
|
0:01:31
|
So if they're policing as in to 10 megabits per second
|
|
0:01:36
|
it doesn't make sense for us to send traffic at the
|
|
0:01:38
|
serialization rate of 45 megabits per second
|
|
0:01:42
|
and then have 35 megabits per second dropped as it is
|
|
0:01:45
|
received in.
|
|
0:01:49
|
Likewise, this could also be used on LAN interfaces
|
|
0:01:52
|
like Fast Ethernet or gigabit Ethernet
|
|
0:01:55
|
if the outbound rate that we're sending does not
|
|
0:01:59
|
match the inbound rate that the service provider
|
|
0:02:01
|
is accepting.
|
|
0:02:05
|
So in the case of IOS's traffic shaping
|
|
0:02:07
|
we're going to meter the traffic as it is leaving the interface
|
|
0:02:10
|
and anything that exceeds this rate is going to be
|
|
0:02:13
|
delayed in the shaping queue.
|
|
0:02:16
|
Now at some point just like weighted fair queuing or
|
|
0:02:19
|
random early detection
|
|
0:02:21
|
if the queue gets too large, eventually the traffic is going to get
|
|
0:02:24
|
dropped, but the idea here is that we want to delay the
|
|
0:02:28
|
traffic and send it later as opposed to just flat out
|
|
0:02:31
|
dropping it when it exceeds the rate.
|
|
0:02:34
|
Now there's typically a lot of confusion as to how the
|
|
0:02:37
|
actual shaping algorithm works and how the
|
|
0:02:39
|
calculations work
|
|
0:02:41
|
partially because the terms that are used are kind of confusing
|
|
0:02:45
|
the way that they are used in the shaping
|
|
0:02:49
|
versus policing where even though the same terminology
|
|
0:02:54
|
is used, it means technically different things when we're talking
|
|
0:02:56
|
about policing versus shaping.
|
|
0:02:59
|
Now in the case of traffic shaping, the first thing that we
|
|
0:03:03
|
care about is how often the shaper is running over the second.
|
|
0:03:09
|
So if we think of a gigabit Ethernet interface
|
|
0:03:13
|
for example the serialization is one billion bits per second.
|
|
0:03:19
|
Now since this is so much data that the router needs to
|
|
0:03:22
|
encapsulate on the link, internally the physical interface driver is not
|
|
0:03:27
|
thinking in terms of a second.
|
|
0:03:29
|
It's thinking in terms of milliseconds or microseconds.
|
|
0:03:34
|
So when the shaping algorithm is applied, generally we don't want to
|
|
0:03:38
|
shape over the entire second, we need to do this
|
|
0:03:42
|
much more often on a smaller time interval basis
|
|
0:03:47
|
in order to achieve what average rate that we want
|
|
0:03:50
|
over the second
|
|
0:03:52
|
because the second value is a time index, that's only
|
|
0:03:55
|
important to us.
|
|
0:03:57
|
From the router's internal clock, it's running at much
|
|
0:03:59
|
much smaller time intervals.
|
|
0:04:02
|
So the time committed or TC
|
|
0:04:04
|
essentially controls how often the shaper is going to
|
|
0:04:07
|
run over the second.
|
|
0:04:09
|
Specifically this is the time in which we are going to
|
|
0:04:13
|
emit traffic bursts at the access rate.
|
|
0:04:18
|
Now the access rate is also the serialization or the
|
|
0:04:22
|
physical clocking that's the physical function of the link
|
|
0:04:26
|
that is controlled by the interface's hardware driver.
|
|
0:04:29
|
So again, Fast Ethernet interface this is going to have an access
|
|
0:04:32
|
rate or a serialization of a 100 megabits per second.
|
|
0:04:39
|
The next we have is the burst committed
|
|
0:04:41
|
this is how much traffic we need to send in the time
|
|
0:04:45
|
committed interval in order to achieve the average
|
|
0:04:49
|
rate over the second.
|
|
0:04:52
|
So if we were to say that our average rate that we are
|
|
0:04:54
|
shaping to is 1 megabit per second
|
|
0:04:57
|
and we had ten intervals per second
|
|
0:05:01
|
it would means that we were shaping to one tenth
|
|
0:05:06
|
of the average rate on a per interval basis
|
|
0:05:11
|
so essentially the burst committed is the same exact
|
|
0:05:14
|
value as the average rate
|
|
0:05:17
|
except we are expressing it on a per interval basis
|
|
0:05:21
|
as opposed to a per second basis.
|
|
0:05:26
|
Now generally, the actual value of burst committed
|
|
0:05:29
|
is not going to matter unless we are dealing with very, very
|
|
0:05:32
|
low speed interfaces and the serialization delay is
|
|
0:05:36
|
going to interfere with our voice priority traffic.
|
|
0:05:40
|
So anything that is about 768 k or below, then the
|
|
0:05:45
|
amount of time it actually takes is to encapsulate the packet
|
|
0:05:48
|
is going to be a problem from the voice application's point of view.
|
|
0:05:53
|
But if we have E1 speed or higher which is 2 megabits per
|
|
0:05:57
|
second, pretty much anything E1 or higher the serialization
|
|
0:06:02
|
delay is going to be fairly negligible from the point of
|
|
0:06:05
|
view of the actual delay that occurs on the interface.
|
|
0:06:11
|
So we'll see when we actually change the burst committed
|
|
0:06:13
|
value what this is going to affect is what is the time
|
|
0:06:17
|
committed or essentially how many intervals do we have
|
|
0:06:21
|
per second.
|
|
0:06:25
|
Then the final value we have is the burst in excess
|
|
0:06:29
|
the BE, this is the amount in addition to our normal
|
|
0:06:33
|
committed burst that we're allowed to send on a per
|
|
0:06:36
|
interval basis if we had accumulated credit to begin with.
|
|
0:06:40
|
Now the key to remember about the traffic shaping
|
|
0:06:43
|
is that no matter how much traffic we are sending on a per
|
|
0:06:47
|
interval basis or how much we burst, we are never going to
|
|
0:06:51
|
exceed the average rate on a per second basis.
|
|
0:06:57
|
Now depending on whether we're configuring the shaper from
|
|
0:07:00
|
the legacy generic traffic shaping, the legacy frame relay
|
|
0:07:04
|
traffic shaping or inside the module of the quality of service
|
|
0:07:08
|
the arguments that we're using are going to be a little bit
|
|
0:07:10
|
different where in the MQC, the logic of this is much more straightforward
|
|
0:07:15
|
because we simply need to tell the router what's the
|
|
0:07:18
|
average that you want to achieve and it is automatically
|
|
0:07:21
|
going to figure out what is the burst committed
|
|
0:07:23
|
what is the time committed and what is the burst in excess.
|
|
0:07:28
|
If we were to set the burst in excess to be zero
|
|
0:07:30
|
it means you are strictly limited to what the burst
|
|
0:07:34
|
committed is on a per interval basis.
|
|
0:07:39
|
But again, regardless of what the BE and what the BC
|
|
0:07:42
|
values are, you're never going to exceed the average
|
|
0:07:46
|
rate per second.
|
|
0:07:51
|
Specifically configuration wise in the module of the quality of
|
|
0:07:54
|
service, this is going to be the shape average command
|
|
0:07:59
|
where we specify what the CIR is, we can specify the burst
|
|
0:08:03
|
committed and the burst excess where the time
|
|
0:08:06
|
committed is implicitly derived based on what the burst committed
|
|
0:08:10
|
is and what the CIR is.
|
|
0:08:14
|
So essentially the CIR per second is the same as BC
|
|
0:08:20
|
per TC, so again the CIR which is your bits per
|
|
0:08:27
|
second average is the same as the burst committed per
|
|
0:08:32
|
interval, the only difference is that CIR is measured in bits
|
|
0:08:37
|
per second where the TC is in milliseconds.
|
|
0:08:42
|
So it's the same as the CIR, it's just on a per
|
|
0:08:45
|
millisecond basis.
|
|
0:08:50
|
Now inside the actual shaper, this by default is going to be
|
|
0:08:54
|
a first in first out queue just like the different
|
|
0:08:57
|
manually defined weighted fair queuing classes were
|
|
0:09:00
|
but they could be configured as the hierarchical queuing
|
|
0:09:04
|
framework if we specify a child policy or a nested policy
|
|
0:09:09
|
inside the shaped rate.
|
|
0:09:13
|
So we'll take a look at some examples where we're shaping
|
|
0:09:16
|
on an interface like maybe Fast Ethernet we want to shape this
|
|
0:09:19
|
down to 25 megabits per second, but then inside of that
|
|
0:09:23
|
rate, we also want to do additional fancy queuing.
|
|
0:09:27
|
We want to do a reservation for web traffic, we want to do
|
|
0:09:29
|
low latency for voice inside the shaper's rate.
|
|
0:09:34
|
So this is why the queuing is now considered hierarchical
|
|
0:09:37
|
because we can have multiple levels of policies where one is
|
|
0:09:41
|
sitting inside another to define more specific information
|
|
0:09:45
|
about the individual queues.
|
|
0:09:48
|
So let's take a look at our topology here
|
|
0:09:50
|
and say that we wanted to apply this on Router 4's
|
|
0:09:57
|
connection as it goes out to BB3
|
|
0:10:04
|
We're going to say that this link even though it is
|
|
0:10:06
|
physically clocked at a 100 megabits per second
|
|
0:10:09
|
let's assume that as BB3 receives the traffic
|
|
0:10:12
|
inbound, it is policing to 25 megabits per second.
|
|
0:10:18
|
So it doesn't make sense for Router 4 to send faster
|
|
0:10:21
|
than that if BB3 is simply going to drop traffic in if
|
|
0:10:25
|
it exceeds 25 megabits per second.
|
|
0:10:29
|
So typically, the outbound shaping rate is going to match
|
|
0:10:33
|
the provider's inbound metering rate or the
|
|
0:10:35
|
inbound policing rate.
|
|
0:10:40
|
If the provider is not policing inbound, then there's
|
|
0:10:42
|
no reason to shape outbound.
|
|
0:10:45
|
It's only when there's a difference between the
|
|
0:10:47
|
physical serialization and what the effective
|
|
0:10:50
|
bandwidth rate of the interface is.
|
|
0:10:54
|
Now traditionally, this usually only happened in virtual circuit
|
|
0:10:57
|
based environments where over frame relay we have
|
|
0:11:00
|
a difference between the physical clocking of the
|
|
0:11:03
|
link like a T1 versus how many channels are actually
|
|
0:11:08
|
assigned to the individual PVC.
|
|
0:11:11
|
So maybe I have a T1 interface that's clocked at 1.5 megabits
|
|
0:11:15
|
per second, but if my PVC is only guaranteed 512 kilobits
|
|
0:11:19
|
per second, then there's a disconnect between what
|
|
0:11:23
|
I'm serializing at which is the T1 speed versus what
|
|
0:11:27
|
the effect of bandwidth is which is 512 k
|
|
0:11:35
|
So again, any time that your outbound rate is different
|
|
0:11:38
|
than the other side inbound rate, that's when it is
|
|
0:11:41
|
appropriate to use shaping.
|
|
0:11:47
|
So on Router 4 the first thing that we're going to do
|
|
0:11:50
|
is define a new policy that is going to configure the shaping.
|
|
0:11:54
|
Now just like any of the other features, we could do this on a per
|
|
0:11:57
|
class basis if we wanted to shape web traffic differently than
|
|
0:12:01
|
we were shaping FTP
|
|
0:12:04
|
but if we want to shape everything, we're going to do
|
|
0:12:05
|
that just in class default.
|
|
0:12:08
|
So on Router 4, I'm going to configure a policy
|
|
0:12:10
|
map that says shape
|
|
0:12:16
|
and inside class class-default
|
|
0:12:21
|
I'm going to do shaping to an average rate.
|
|
0:12:24
|
Now we can see we can do a percentage of the
|
|
0:12:27
|
link bandwidth which just like the bandwidth reservation
|
|
0:12:31
|
is going to be based on the bandwidth keyword
|
|
0:12:33
|
on the interface, so if I wanted to do a relative
|
|
0:12:38
|
reservation on this link based on 25 megabits per
|
|
0:12:41
|
second, what I would first want to do is go to interface
|
|
0:12:46
|
Fast Ethernet 0/0 and say bandwidth 25000
|
|
0:12:51
|
so now the percentage would be based off of
|
|
0:12:54
|
that value as opposed to bandwidth 100 thousand
|
|
0:12:57
|
which is the default.
|
|
0:12:59
|
But let's assume in this case under policy map
|
|
0:13:01
|
shape and under class class-default
|
|
0:13:08
|
we're going to do the shaping to an absolute value.
|
|
0:13:10
|
So we'll shape average to 25 thousand or 25 million
|
|
0:13:16
|
because this is in bits per second.
|
|
0:13:18
|
Now I'm not going to configure any of the other values after this.
|
|
0:13:22
|
I could configure the burst committed, I could configure
|
|
0:13:27
|
the burst in excess so let's see a 100 thousand
|
|
0:13:35
|
bits excess let's say 50 thousand
|
|
0:13:39
|
and then those are the only arguments, but in this case
|
|
0:13:41
|
I'm going to leave both of them out.
|
|
0:13:43
|
Ok, notice it says specifically it's recommended not to configure
|
|
0:13:46
|
this because the algorithm is going to figure out the best value.
|
|
0:13:53
|
Now once we apply this to the interface level
|
|
0:13:55
|
if we say service policy output is shape
|
|
0:14:00
|
then again, this is going to assume we do not have any
|
|
0:14:03
|
other policies so no service policy ou WRED
|
|
0:14:08
|
we want to do shaping
|
|
0:14:11
|
if we look at the show policy map interface Fast Ethernet 0/0
|
|
0:14:21
|
it says that the CIR is 25 megabits per second
|
|
0:14:28
|
with a burst committed of 100 thousand bits.
|
|
0:14:34
|
Burst and excess likewise is a 100 thousand bits.
|
|
0:14:39
|
So if our BC is a 100 thousand
|
|
0:14:44
|
this means that the TC would be how often do we need to
|
|
0:14:48
|
send a 100 thousand bits over the second
|
|
0:14:53
|
in order to reach 25 million bits per second.
|
|
0:14:58
|
So again, when we look at the correlation between these
|
|
0:15:00
|
values, the burst committed is in bits.
|
|
0:15:06
|
The TC is in milliseconds.
|
|
0:15:10
|
The CIR is in bits per second.
|
|
0:15:18
|
So these values are essentially equal to each other
|
|
0:15:21
|
but one difference is that the units are different
|
|
0:15:24
|
so TC is measured in milliseconds as opposed to seconds
|
|
0:15:30
|
and the TC is going to be smaller than one second
|
|
0:15:33
|
which means that the BC is going to be smaller than the CIR
|
|
0:15:37
|
but the ratio between the two of them is going to be the same.
|
|
0:15:40
|
So if we said that a 100 thousand bits
|
|
0:15:47
|
per TC in milliseconds
|
|
0:15:51
|
is equal to 25 million
|
|
0:15:58
|
bits per second
|
|
0:16:00
|
then based on this, the router's going to figure out
|
|
0:16:02
|
what is the time committed value supposed to be.
|
|
0:16:05
|
Now in this particular output, it doesn't show us what the
|
|
0:16:08
|
time committed is. In the previous versions
|
|
0:16:12
|
that did not use the HQF, it would have actually showed us
|
|
0:16:15
|
what the TC is, but technically it doesn't even matter what it is
|
|
0:16:20
|
because from our point of view, we don't need to configure
|
|
0:16:23
|
this, the algorithm is going to figure it out on its own.
|
|
0:16:26
|
Now if I were to take this same type of policy and
|
|
0:16:28
|
apply on an earlier version, it will show us essentially
|
|
0:16:33
|
indirectly what the TC value is based on the BC's configuration.
|
|
0:16:40
|
So on Router 4, if we say show run section
|
|
0:16:43
|
policy map
|
|
0:16:46
|
if I were to take this policy map shape and let's configure it
|
|
0:16:50
|
on Router 1 which is using an older version
|
|
0:16:53
|
then on Fast Ethernet 0/0 we'll say service policy output
|
|
0:16:57
|
is shape
|
|
0:16:59
|
then show policy map interface Fast Ethernet 0/0
|
|
0:17:06
|
notice that the output is a little bit different here.
|
|
0:17:10
|
It's saying that our sustained bits per interval
|
|
0:17:13
|
is 625 thousand
|
|
0:17:16
|
where our interval size is 25 milliseconds long.
|
|
0:17:23
|
So essentially what this means is that 625 thousand
|
|
0:17:32
|
or was it 62?
|
|
0:17:34
|
500 or is it...?
|
|
0:17:36
|
Ok, 625000
|
|
0:17:41
|
every 25 milliseconds, so that's bits per milliseconds.
|
|
0:17:44
|
This is the same. It's saying at 25 thousand or
|
|
0:17:48
|
25 million
|
|
0:17:52
|
25 million bits
|
|
0:17:53
|
per second.
|
|
0:17:59
|
Now if I were to decrease the burst committed in this
|
|
0:18:04
|
configuration
|
|
0:18:06
|
let's say I set it to half of that.
|
|
0:18:12
|
So 625000
|
|
0:18:15
|
divided by two
|
|
0:18:18
|
312500
|
|
0:18:21
|
If we were to go to Router 1's class map or actually the
|
|
0:18:25
|
policy map, so policy map shape under class class-default
|
|
0:18:31
|
we want to shape to an average rate the same
|
|
0:18:33
|
value as before
|
|
0:18:35
|
the only thing that's different is now I'm going to set what
|
|
0:18:38
|
the burst committed is.
|
|
0:18:40
|
If we show policy map
|
|
0:18:45
|
interface Fast Ethernet 0/0
|
|
0:18:49
|
notice that the size of the interval
|
|
0:18:52
|
is about half of what it was before.
|
|
0:18:55
|
The reason why is that if I'm sending half as much
|
|
0:18:58
|
traffic per interval, it means I need twice as many intervals
|
|
0:19:03
|
per second in order to achieve the same average rate.
|
|
0:19:09
|
So the key point being that no matter what we set the
|
|
0:19:11
|
burst committed to, we're never going to exceed the
|
|
0:19:14
|
average which is 25 megabits per second.
|
|
0:19:16
|
The only thing that is changing when we affect the BC is how
|
|
0:19:20
|
often the shaper runs over the second.
|
|
0:19:25
|
Where a smaller burst committed value means that the shaper
|
|
0:19:28
|
runs more often
|
|
0:19:31
|
which means that there would be less delay between
|
|
0:19:34
|
the individual intervals in which we are transmitting traffic.
|
|
0:19:37
|
So unless the serialization of the link is very low
|
|
0:19:40
|
like again, like a 768 k link or below
|
|
0:19:44
|
then normally it doesn't matter what the serialization is between
|
|
0:19:48
|
the shaping intervals, we can just let the router figure it out
|
|
0:19:51
|
on its own and it's really not going to be a problem.
|
|
0:19:55
|
Now in this case, if I were to say that the burst committed
|
|
0:20:01
|
was 25 thousand.
|
|
0:20:06
|
Actually 200 and...
|
|
0:20:08
|
250 thousand.
|
|
0:20:10
|
If we look at the policy map now, it says the interval size is
|
|
0:20:13
|
10 milliseconds
|
|
0:20:16
|
because essentially now the BC is the average rate
|
|
0:20:20
|
divided by a 100
|
|
0:20:21
|
it means that I have a 100 intervals per second
|
|
0:20:26
|
each of these being 10 milliseconds long
|
|
0:20:29
|
so if I send 250 thousand bits per 10 milliseconds
|
|
0:20:35
|
this is the same as sending 25 million bits per second.
|
|
0:20:39
|
Ok, there's a question here, "I understand the BC
|
|
0:20:44
|
the TC and the CIR, if the router cannot send more than
|
|
0:20:49
|
CIR, what is the BE for?"
|
|
0:20:51
|
Ok, the key with the BE is that it's only extra credit
|
|
0:20:56
|
that if we accumulated that over previous intervals because
|
|
0:21:02
|
we did not send enough traffic, then we can make
|
|
0:21:06
|
up for that in later intervals.
|
|
0:21:09
|
Now the best way to understand this is to visualize the second
|
|
0:21:14
|
broken down into these different intervals.
|
|
0:21:17
|
So let's say that we have two, four...
|
|
0:21:25
|
1, 2, 3, 4, 5, 6, 7, 8
|
|
0:21:30
|
let's say that we have ten intervals.
|
|
0:21:33
|
Ok, if we have ten intervals
|
|
0:21:38
|
and this is representing one second
|
|
0:21:43
|
then each interval is how long
|
|
0:21:50
|
so this TC, the time interval, this is going to be a 100 milliseconds.
|
|
0:21:57
|
So if we have ten intervals per second, it means each of
|
|
0:22:00
|
the intervals is going to be a 100 milliseconds long.
|
|
0:22:04
|
Now if I were to say that in each of these intervals
|
|
0:22:07
|
my burst committed was let's say for simplicity let's say
|
|
0:22:12
|
it's a thousand bits.
|
|
0:22:18
|
If I send a thousand bits per interval and I have
|
|
0:22:23
|
ten intervals per second, it essentially means that the
|
|
0:22:28
|
average rate is 10 thousand bits per second.
|
|
0:22:38
|
Right
|
|
0:22:41
|
Ok, so now this is assuming that in order to achieve that
|
|
0:22:45
|
average rate, ok, so the CIR, this is the average rate
|
|
0:22:48
|
in order to get to this, it means that the router would have to
|
|
0:22:51
|
send a thousand bits every single interval
|
|
0:23:02
|
but the potential problem we run into is let's say in one of these
|
|
0:23:06
|
individual intervals we didn't send enough
|
|
0:23:08
|
maybe we only sent 500 bits, not a thousand.
|
|
0:23:14
|
So now this means that when we average this out
|
|
0:23:17
|
over the second, we're not really getting our 10 thousand
|
|
0:23:22
|
bits per second average, we're actually getting 95 hundred
|
|
0:23:29
|
bits per second
|
|
0:23:31
|
because in one of the individual intervals, we didn't send enough traffic.
|
|
0:23:35
|
So the burst in excess is designed to make up
|
|
0:23:39
|
for this specific case.
|
|
0:23:43
|
Where in a following interval later, since I did not send
|
|
0:23:49
|
500 bits. It means I have an additional 500 credit.
|
|
0:23:53
|
I could apply this onto another interval later, so let's say in the
|
|
0:23:58
|
very last interval, the tenth one, I send a thousand which is my BC
|
|
0:24:04
|
but I send an extra 500 which is part of my BE
|
|
0:24:11
|
so even though in that interval I sent 15 hundred bits
|
|
0:24:14
|
as an average, I still never exceeded 10 thousand bits
|
|
0:24:18
|
over the second.
|
|
0:24:24
|
Now the only time that you can actually do this
|
|
0:24:26
|
is that if your BC plus your BE on a per interval basis
|
|
0:24:34
|
does not exceed the actual serialization of the interface
|
|
0:24:40
|
because regardless of what the values that you apply to
|
|
0:24:42
|
the queuing, the router is still going to be controlled by
|
|
0:24:45
|
what is the physical interface speed.
|
|
0:24:49
|
So if I have a Fast Ethernet interface, it doesn't matter what
|
|
0:24:52
|
I configured the shaping as, the router is never going to be
|
|
0:24:54
|
able to send faster than a 100 megabits per second.
|
|
0:24:58
|
So the only thing you would need to watch out for is
|
|
0:25:00
|
to make sure that your BC plus your BE on a per interval
|
|
0:25:05
|
basis isn't faster than the actual physical interface can send.
|
|
0:25:13
|
So the key point with the shaping is that regardless
|
|
0:25:15
|
of how large the BE is, you're still never exceeding the CIR
|
|
0:25:20
|
as an average.
|
|
0:25:21
|
You're just trying to make up for one or more intervals that you
|
|
0:25:25
|
didn't actually send enough traffic previously.
|
|
0:25:29
|
Now the shaping algorithm again is only going to be applied
|
|
0:25:32
|
outbound and it's used with any time that we have a disconnect between
|
|
0:25:36
|
what I can send versus what the other side is receiving inbound.
|
|
0:25:43
|
So where shaping is going to be outbound, on the other end of the link inbound
|
|
0:25:47
|
typically this is where traffic policing is configured.
|
|
0:25:53
|
So policing is used to meter the inbound packet flow rate.
|
|
0:25:57
|
Ok, technically it could be outbound as well
|
|
0:25:59
|
the vast majority of the time it's going to be an inbound function.
|
|
0:26:03
|
Now based on what the packet rate is
|
|
0:26:06
|
so if it conforms or it's less than or equal to the rate that we're
|
|
0:26:10
|
configuring or it exceeds, so it's greater than the rate that we're
|
|
0:26:14
|
configuring, then we're going to mark the packet.
|
|
0:26:17
|
We can mark it by either changing the DSCP or the
|
|
0:26:21
|
IP precedence or we could simply drop the packet.
|
|
0:26:26
|
So technically, dropping it is one of the mark actions
|
|
0:26:29
|
that based on some criteria some level that we're configuring
|
|
0:26:34
|
if you exceed the level, we're going to take some action and this
|
|
0:26:37
|
action is the marking. Whether the marking is to actually change a value
|
|
0:26:41
|
inside the packet or to drop it, that's going to be up to our configuration.
|
|
0:26:51
|
Now where this comes to be different than the traffic shaping
|
|
0:26:54
|
is that there's basically only two parameters.
|
|
0:26:58
|
The metering rate or the average rate that we're trying to
|
|
0:27:02
|
achieve which is the CIR and the averaging interval
|
|
0:27:07
|
or essentially how often the policer is running per second.
|
|
0:27:17
|
Now just like with the traffic shaping, the larger the time interval is
|
|
0:27:24
|
the more traffic that we're allowed to send in that particular interval.
|
|
0:27:27
|
So the larger the interval, the larger the burst size.
|
|
0:27:32
|
So this means that when we're changing the burst size to be
|
|
0:27:35
|
larger, we're telling the policing algorithm to run
|
|
0:27:40
|
less often per second.
|
|
0:27:47
|
So it's essentially the same type of logic where we're saying
|
|
0:27:51
|
how often should you actually enforce this
|
|
0:27:54
|
but the actual algorithm behind the scenes is completely different
|
|
0:27:57
|
in the traffic policing versus the traffic shaping.
|
|
0:28:00
|
Now again, how it's implemented programmatically that's not really
|
|
0:28:03
|
that much concern from our perspective.
|
|
0:28:06
|
The key is that with policing, you specify the rate at which you
|
|
0:28:10
|
want to imply -- apply an action
|
|
0:28:14
|
where again, either this action is I'm going to
|
|
0:28:17
|
change the packet's marking or I'm going to drop the packets.
|
|
0:28:20
|
How the router actually calculates whether that rate is exceeded or
|
|
0:28:24
|
not it doesn't really matter that much to us.
|
|
0:28:28
|
Now in practice, when you go to apply this in production
|
|
0:28:31
|
typically what you do is simply change the burst value up and
|
|
0:28:35
|
down to figure out for your individual traffic pattern
|
|
0:28:40
|
what's the appropriate correct value
|
|
0:28:44
|
because it's actually really hard to calculate what this value
|
|
0:28:46
|
is supposed to be because it depends on the packet size of
|
|
0:28:50
|
your actual applications, how bursty the nature of the
|
|
0:28:54
|
application is to begin with, so there's not really a single
|
|
0:28:58
|
formula that you can apply onto all situations
|
|
0:29:02
|
but in general, it's the same type of logic as shaping
|
|
0:29:05
|
that the larger the interval size, the more you're going to be allowed to
|
|
0:29:10
|
burst which essentially means that you're policing less often per second.
|
|
0:29:17
|
Then just like in traffic shaping, we have the burst in excess
|
|
0:29:22
|
which means that if for some reason you didn't send
|
|
0:29:25
|
enough traffic previously, you could essentially make up
|
|
0:29:29
|
for that in later time intervals.
|
|
0:29:31
|
Now as I mentioned, typically the shaping and policing are going
|
|
0:29:35
|
to be configured together
|
|
0:29:37
|
where we are shaping our traffic outbound
|
|
0:29:40
|
in order to match what the other side is policing inbound.
|
|
0:29:44
|
So if we're using Metro Ethernet, I have a Fast Ethernet link at a
|
|
0:29:48
|
100 megabits per second, but the provider is policing
|
|
0:29:51
|
inbound at 25 megabits per second, it means that I would
|
|
0:29:55
|
want to shape outbound to match that rate.
|
|
0:29:59
|
So my shaping outbound is essentially metering the traffic
|
|
0:30:02
|
to match whatever parameters they have on the other side.
|
|
0:30:07
|
Any time that these parameters do not match, that's when the
|
|
0:30:10
|
policing rate is going to be exceeded and generally the traffic is going to be dropped.
|
|
0:30:17
|
So assuming that you don't care that the traffic dropped, then
|
|
0:30:19
|
you don't need to police in the first -- or you don't need to shape in the first place.
|
|
0:30:23
|
You could theoretically just leave it up to the application
|
|
0:30:26
|
that you could use the TCP slow start and the TCP
|
|
0:30:30
|
sliding windowing to figure out whether traffic should be
|
|
0:30:33
|
sent or dropped, but typically you end up in less throughput
|
|
0:30:37
|
when you do not shape versus when you do shape.
|
|
0:30:44
|
So on a per second basis, you might get less bandwidth when you're
|
|
0:30:48
|
shaping, but over a longer term average it's more
|
|
0:30:51
|
efficient because you're stopping the end host from going into
|
|
0:30:55
|
slow start as often.
|
|
0:30:57
|
So configuration wise, the syntax is going to be similar
|
|
0:31:00
|
between the policing and shaping where we're specifying
|
|
0:31:04
|
essentially just the average rate that we're trying to achieve
|
|
0:31:08
|
then if you exceed the average rate, we can specify what the
|
|
0:31:14
|
action is, so do we want to remark the traffic
|
|
0:31:18
|
so do we want to change the IP precedence, do we want to
|
|
0:31:21
|
change the DSCP value, do we want to send the traffic
|
|
0:31:25
|
or do we want to drop it.
|
|
0:31:30
|
Now there's a couple different ways to apply this, there's a
|
|
0:31:33
|
two rate policer versus a three rate policer
|
|
0:31:36
|
where a three rate policer is going to be used to
|
|
0:31:42
|
essentially give multiple service levels
|
|
0:31:46
|
down to the customer that's sending the traffic to the provider.
|
|
0:31:51
|
So we could say that under the CIR value, the traffic is
|
|
0:31:56
|
going to be conforming.
|
|
0:31:57
|
Between the CIR and the PIR which is the peak information rate
|
|
0:32:03
|
the traffic is exceeding, then once we go above the peak information rate
|
|
0:32:08
|
then the traffic is violating.
|
|
0:32:11
|
So the advantage of this is that the service provider could
|
|
0:32:14
|
say I'm going to give you a guarantee up to the
|
|
0:32:17
|
CIR you're allowed to send up to the peak rate, but that is
|
|
0:32:22
|
not guaranteed, then anything above that is going to be dropped.
|
|
0:32:30
|
So then if the customer wants to send more than they're actually
|
|
0:32:33
|
guaranteed, they can try to send as fast as possible
|
|
0:32:37
|
but anything above the CIR is subject to be dropping if
|
|
0:32:41
|
congestion occurs.
|
|
0:32:43
|
Ok, generally the third rate, the violate action, that's going to be
|
|
0:32:46
|
the hard rate where we do not want to exceed.
|
|
0:32:50
|
Then if you go above that value, the traffic is generally going to be dropped.
|
|
0:32:54
|
But again, you can configure this however you want to
|
|
0:32:56
|
based on the conform, violate and the exceed -- or conform
|
|
0:33:00
|
exceed and violate actions.
|
|
0:33:02
|
So if we were to take a look at this in our case
|
|
0:33:05
|
on Router 1, we have the shaping configured outbound
|
|
0:33:10
|
on Fast Ethernet 0/0
|
|
0:33:14
|
If Router 1 was the customer edge device and Router 4
|
|
0:33:17
|
was the provider edge, generally Router 4 is going to be policing
|
|
0:33:23
|
inbound where Router 1 would be shaping outbound.
|
|
0:33:29
|
So this is one of the key differences between policing and
|
|
0:33:32
|
shaping that policing could be either direction. It's in or out.
|
|
0:33:36
|
But shaping since it is a queuing mechanism, it is
|
|
0:33:40
|
going be applied only output.
|
|
0:33:44
|
So up to this point, all of the methods we saw were
|
|
0:33:47
|
outbound.
|
|
0:33:48
|
Policing is the only one here that can be applied both outbound
|
|
0:33:51
|
and inbound.
|
|
0:33:54
|
So next let's go to Router 4
|
|
0:33:58
|
and we'll configure a new policy that is going to be for
|
|
0:34:00
|
policing.
|
|
0:34:02
|
So we'll say policy map police for class class-default
|
|
0:34:07
|
we want to police the traffic.
|
|
0:34:10
|
Ok, we could say police to an average rate
|
|
0:34:13
|
we could do a percentage of the interface which again is
|
|
0:34:16
|
going to be based on the interface's configured bandwidth value.
|
|
0:34:20
|
So in order to make sure the percentage is accurate
|
|
0:34:22
|
it then assumes that we would have to have the bandwidth statement being accurate.
|
|
0:34:30
|
Now if Router 1 is policed -- or excuse me Router 1 is shaping
|
|
0:34:32
|
outbound to 25 megabits per second, we're going to say on
|
|
0:34:35
|
Router 4, we're going to police inbound to match this.
|
|
0:34:38
|
So we'll say 25 million
|
|
0:34:45
|
if we leave it with all of the defaults, it means that the conform action
|
|
0:34:49
|
is going to be transmit
|
|
0:34:51
|
and the exceed action is going to be drop.
|
|
0:34:56
|
So if we say on interface Fast Ethernet 0/1
|
|
0:34:58
|
service policy input is police
|
|
0:35:04
|
when we show policy map interface Fast Ethernet 0/1
|
|
0:35:10
|
it says that there's two rates or actually there's only
|
|
0:35:13
|
one rate. There's one rate and there are two actions.
|
|
0:35:17
|
The rate is 25 million bits per second.
|
|
0:35:22
|
If you are under that rate based on this particular
|
|
0:35:25
|
burst committed, then packets are going to conform
|
|
0:35:31
|
and the conform action is that they are transmitted.
|
|
0:35:36
|
If you go above this rate, packets are going to exceed
|
|
0:35:40
|
and the resulting action is that they are dropped.
|
|
0:35:48
|
So essentially this is the one rate policer as opposed
|
|
0:35:52
|
to the two rate policer.
|
|
0:35:55
|
A two rate policer is also going to give us the peak information rate
|
|
0:35:58
|
that we could say between the -- up to the CIR that's going to
|
|
0:36:02
|
be your conform action. Between the CIR and the PIR
|
|
0:36:06
|
that's going to be your exceed
|
|
0:36:08
|
then above the PIR, that's going to be your violate action.
|
|
0:36:14
|
So our only difference between this configuration wise is we would
|
|
0:36:16
|
need to specify what the peak rate is, then once we
|
|
0:36:21
|
go to the policing sub configuration mode, so if I go back to the policing
|
|
0:36:26
|
config, let's say policy map
|
|
0:36:36
|
policy map police
|
|
0:36:37
|
class class-default
|
|
0:36:41
|
we said police 25 million
|
|
0:36:46
|
this is where we can specify what the conform action is
|
|
0:36:48
|
which again, by default is transmit
|
|
0:36:53
|
then the exceed action we could either drop the traffic
|
|
0:36:55
|
or remark it.
|
|
0:36:57
|
So in the case of ATM, we have the cell loss priority.
|
|
0:37:02
|
For frame relay, we have the discard eligibility.
|
|
0:37:04
|
MPLS, we have the experimental bits
|
|
0:37:07
|
the DSCP or the IP precedence
|
|
0:37:10
|
both the QoS group and the discard class these are
|
|
0:37:15
|
locally significant values
|
|
0:37:18
|
where the QoS group typically this is used with MPLS
|
|
0:37:22
|
as kind of a temporary place holder between the interfaces
|
|
0:37:25
|
where the discard class could be used with the weighted
|
|
0:37:28
|
random early detection.
|
|
0:37:29
|
So what this effectively would allow me to do
|
|
0:37:33
|
is meter the traffic as it comes in from the customer
|
|
0:37:38
|
then it goes out to the core of the network use
|
|
0:37:40
|
random early detection to figure out what type of
|
|
0:37:43
|
traffic is going to be preferred over another.
|
