|
0:00:13
|
In the next section for QoS we're going to talk about the
|
|
0:00:16
|
specific methods that we can apply to queuing for the routers'
|
|
0:00:19
|
interfaces both for the outbound features like the first in first out
|
|
0:00:24
|
queuing, weighted fair queuing, bandwidth reservations, low
|
|
0:00:27
|
latency queuing for the admission control with both policing and shaping
|
|
0:00:33
|
then we'll talk about some of the specifics of shaping as they apply
|
|
0:00:35
|
to frame relay interfaces differently than regular Ethernet or point to point links.
|
|
0:00:42
|
Now the first mechanism we have is known as the FIFO queue or
|
|
0:00:45
|
the First In First Out which is the simplest to implement
|
|
0:00:49
|
because there's only one parameter that applies to
|
|
0:00:53
|
the queuing.
|
|
0:00:54
|
Essentially FIFO queuing means that the order that the packets are
|
|
0:00:57
|
sent to the interface, so are sent to the interface queue I should say
|
|
0:01:01
|
is the order that they're actually going to be transmitted to
|
|
0:01:04
|
the physical interface for the encapsulation.
|
|
0:01:08
|
Now the other queuing types whether they are weighted fair
|
|
0:01:10
|
queuing or the bandwidth reservation or low latency
|
|
0:01:13
|
queuing, they are going to change the order in which
|
|
0:01:17
|
packets are moving from the output queue to the transmit
|
|
0:01:20
|
ring of the interface.
|
|
0:01:22
|
So again, the output queue is going to be the software queue of the
|
|
0:01:26
|
interface. This is where our different configurations
|
|
0:01:29
|
like weighted fair queuing or low latency queuing are
|
|
0:01:31
|
going to apply onto.
|
|
0:01:34
|
The physical hardware queue or the transmit ring is a physical
|
|
0:01:38
|
function of the interface that we cannot really modify.
|
|
0:01:41
|
It's going to be controlled by the clocking or the serialization
|
|
0:01:45
|
of the link where a Gigabit Ethernet interface for example is going to serialize
|
|
0:01:50
|
traffic at 1 billion bits per second as they're sent to the transmit ring.
|
|
0:01:56
|
So FIFO queuing essentially is controlling just how large
|
|
0:01:59
|
is the buffer as we're waiting to send traffic down to the transmit ring.
|
|
0:02:05
|
So configuration wise, this is simply that we disable any of the
|
|
0:02:10
|
other queuing mechanisms like we say no fair queue, then we can
|
|
0:02:15
|
define what is the depth of the queue or essentially how
|
|
0:02:17
|
many packets we can hold before they start to get dropped
|
|
0:02:21
|
but typically we would see that this is going to be used with other solutions
|
|
0:02:25
|
such as the hierarchical queuing framework in order to do
|
|
0:02:30
|
shaping plus FIFO at the same time or policing
|
|
0:02:35
|
plus FIFO at the same time because we're not doing
|
|
0:02:37
|
any management of the traffic flows that are inside that particular class.
|
|
0:02:44
|
So let's look at a basic example of this where we're going to apply
|
|
0:02:49
|
the first in first out queue
|
|
0:02:51
|
on Router 4's interface that connects to the point to point link
|
|
0:02:54
|
to Router 5
|
|
0:02:58
|
Now again, if we look at the show version
|
|
0:03:01
|
on Router 4
|
|
0:03:03
|
do show version include IOS
|
|
0:03:05
|
we see this is running a version that is later than
|
|
0:03:09
|
12.4 20 T
|
|
0:03:11
|
so it is going to be using the hierarchical queuing framework.
|
|
0:03:15
|
And the reason why that's important we'll see that in a minute where the
|
|
0:03:18
|
the classes are going to be treated differently in the new
|
|
0:03:22
|
versions of the HQF versus the class based weighted fair queuing.
|
|
0:03:31
|
So at this point let's look at the show run interface serial 0/1
|
|
0:03:36
|
or actually here at serial 0/1/0
|
|
0:03:40
|
and we essentially see the only thing we have is just the
|
|
0:03:43
|
Layer 3 address and then the Layer 1 clocking.
|
|
0:03:47
|
Now the clock rate here is a physical function
|
|
0:03:51
|
of the interface.
|
|
0:03:53
|
This essentially means that the transmit ring
|
|
0:03:56
|
is then bound to this physical clocking.
|
|
0:04:00
|
So the interface cannot physically support transmitting
|
|
0:04:04
|
packets faster than 64 thousand bits per second. If the link was
|
|
0:04:08
|
clocked at 128 k, then that's going to be the serialization
|
|
0:04:12
|
of that link or how fast that transmit ring can actually
|
|
0:04:16
|
encapsulate the packets.
|
|
0:04:18
|
So for any type of queuing mechanisms that we apply now
|
|
0:04:22
|
it's going to be based on this hard limit of the clock rate of
|
|
0:04:26
|
64 thousand.
|
|
0:04:29
|
Now for other interfaces that are not serial, for Fast Ethernet
|
|
0:04:33
|
the serialization is going to be a 100 megabits per second.
|
|
0:04:36
|
GigE is going to be 1 gigabit per second where 10 GigE is
|
|
0:04:41
|
then going to be 10 gigabits per second.
|
|
0:04:43
|
So the clocking on those links there's no way to change them.
|
|
0:04:46
|
It's only on the serial links that could be a type of channelized configuration
|
|
0:04:52
|
where maybe we have a physical DS3 interface
|
|
0:04:55
|
but we're not using all 45 megabits per second of it
|
|
0:04:59
|
we have it split up into multiple DS0s or multiple DS1s
|
|
0:05:07
|
So on Router 4, let's look at the show queuing serial 0/1/0
|
|
0:05:13
|
or the show -- let's see let's look at the show queuing
|
|
0:05:18
|
interface serial 0/1/0
|
|
0:05:23
|
Ok, right now it says the interface's output queuing strategy is fair queuing.
|
|
0:05:28
|
This means that by default, this is running WFQ or
|
|
0:05:33
|
Weighted Fair Queuing.
|
|
0:05:35
|
It means that for the packets that are going out this link
|
|
0:05:37
|
they're all going to be contending for the same bandwidth and the
|
|
0:05:41
|
router is going to weight them depending on their IP precedence
|
|
0:05:44
|
and dscp values
|
|
0:05:46
|
where by default the traffic that has a higher precedence or
|
|
0:05:50
|
a higher dscp that's going to be preferred over the
|
|
0:05:53
|
lower traffic, the lower precedence traffic.
|
|
0:05:58
|
Now to do first in first out, it essentially means that we're just
|
|
0:06:01
|
disabling all of the other QoS mechanisms.
|
|
0:06:05
|
So at the link level we'll say no fair queue
|
|
0:06:10
|
if we show queuing for the interface, it says now
|
|
0:06:12
|
the queuing strategy is none which essentially means that it is running
|
|
0:06:16
|
first in first out.
|
|
0:06:18
|
At this point, the only other parameter we would apply
|
|
0:06:21
|
is the hold queue
|
|
0:06:24
|
which is essentially just the number of packets that we can
|
|
0:06:27
|
keep in the software queue before the router starts to do
|
|
0:06:31
|
what is known as tail drop.
|
|
0:06:35
|
Now to understand some of these mechanisms, we kind of have to
|
|
0:06:37
|
visualize what's going on in the queuing where the router
|
|
0:06:41
|
mainly has two different data structures that we're concerned about.
|
|
0:06:46
|
We're concerned about the output queue
|
|
0:06:49
|
which again is the software queue on the interface
|
|
0:06:52
|
and then the transmit ring or the TXR
|
|
0:06:57
|
so as traffic is being switched outbound, so the router's trying to
|
|
0:07:04
|
send it out on Ethernet or out of point to point serial link
|
|
0:07:07
|
the first thing the router's going to do is check to see that if the
|
|
0:07:10
|
transmit ring currently has packets being transmitted.
|
|
0:07:15
|
Now if the link is at zero percent utilization, so there's absolutely
|
|
0:07:19
|
no traffic being sent, then the router is not going to queue
|
|
0:07:23
|
the packets.
|
|
0:07:24
|
So the queuing is only needed when there is contention
|
|
0:07:27
|
for the link, so there are certain cases that when
|
|
0:07:30
|
the router goes to send the packet, it skips over the queue
|
|
0:07:33
|
and just goes to the transmit ring.
|
|
0:07:35
|
But this would only be used -- the case that this would
|
|
0:07:38
|
only happen is that the link is not being utilized.
|
|
0:07:42
|
But the vast majority of cases there is actually traffic going to be
|
|
0:07:45
|
currently being sent out the link.
|
|
0:07:48
|
So that means that the packets are going to go into the output queue.
|
|
0:07:52
|
This is where they are going to be delayed as the router
|
|
0:07:56
|
takes the packet from the output queue and then moves it
|
|
0:07:59
|
onto the transmit ring.
|
|
0:08:02
|
From the output queue's perspective we consider
|
|
0:08:04
|
the entry point of it the tail of the queue
|
|
0:08:08
|
where the exit point is the head of the queue.
|
|
0:08:11
|
So traffic is entering the tail of the output queue
|
|
0:08:15
|
it's waiting a certain amount of time, it's moving to the head
|
|
0:08:18
|
of the queue and then being sent onto the transmit ring.
|
|
0:08:22
|
The transmit ring is where the actual serialization
|
|
0:08:26
|
of the packet happens so when we're taking the data packet
|
|
0:08:31
|
and then we're actually putting it onto the wire whether it's an
|
|
0:08:34
|
electrical interface like DS3 or whether it's an optical interface
|
|
0:08:37
|
like OC48, so that's where the router is actually building the
|
|
0:08:41
|
packet at the interface driver level.
|
|
0:08:44
|
But we're mainly concerned about what happens in the output queue.
|
|
0:08:48
|
If we are dealing with first in first out queuing
|
|
0:08:52
|
it means that if we had packets 3, 2 and 1 arrive in that order
|
|
0:08:59
|
so packet number 1 arrives first followed by packet number 2
|
|
0:09:02
|
and 3, it means that they are going to reach the head of the queue
|
|
0:09:06
|
in the same exact order. 3, 2 and 1
|
|
0:09:11
|
So essentially a FIFO means that we're not doing any
|
|
0:09:13
|
queuing logic at all.
|
|
0:09:15
|
The only thing that we're controlling is how large is the
|
|
0:09:18
|
output queue.
|
|
0:09:20
|
Now if the queue depth
|
|
0:09:23
|
or the size of the queue happens to be equal
|
|
0:09:26
|
to these three packets
|
|
0:09:30
|
and a fourth packet arrives that cannot fit into the output queue
|
|
0:09:35
|
it means the router's going to have to discard it.
|
|
0:09:39
|
For the FIFO queuing strategy this is then considered a
|
|
0:09:42
|
tail drop
|
|
0:09:45
|
because the packet is dropped as it is trying to be
|
|
0:09:47
|
admitted to the tail of the output queue.
|
|
0:09:52
|
We'll see that there's other queuing strategies like
|
|
0:09:54
|
weighted random early detection that try to avoid
|
|
0:09:58
|
this tail drop problem because depending on the application whether we
|
|
0:10:03
|
are dealing with TCP versus UDP, the actual application
|
|
0:10:07
|
is going to perform different actions when the packet is lost.
|
|
0:10:12
|
We'll see that in the case where UDP is the vast majority
|
|
0:10:15
|
of your flow, a lot of times there's not that much we can
|
|
0:10:17
|
do with QoS in order to manage the congestion.
|
|
0:10:21
|
But in the case of TCP, it does have congestion management
|
|
0:10:25
|
techniques built into the application itself
|
|
0:10:29
|
which are known as the TCP sliding windowing
|
|
0:10:31
|
and the TCP slow start feature.
|
|
0:10:36
|
So we'll come back to that when we talk about random early detection
|
|
0:10:39
|
but in the case of first in first out queuing
|
|
0:10:41
|
the only thing that we're defining is what is the
|
|
0:10:43
|
size of the output queue and this is the queue depth.
|
|
0:10:48
|
If any packets exceed the size of the queue
|
|
0:10:51
|
so the transmit ring is currently being utilized and we don't have
|
|
0:10:54
|
enough space to hold all of the packets
|
|
0:10:56
|
those packets are going to be tail dropped.
|
|
0:11:00
|
The next queuing technique we have is known as fair queuing
|
|
0:11:03
|
or max min scheduling
|
|
0:11:06
|
which means that we have multiple applications or
|
|
0:11:09
|
multiple flows that are going to share the resources on the
|
|
0:11:14
|
link equally.
|
|
0:11:16
|
Now the idea behind fair queuing is that if we
|
|
0:11:19
|
have one application flow let's say it's an FTP download
|
|
0:11:22
|
that's taking much more bandwidth than a very
|
|
0:11:26
|
small application flow let's say it's a voice phone call
|
|
0:11:29
|
or it's a telnet session, the low bandwidth application like the
|
|
0:11:35
|
telnet or the voice call is going to be treated the same
|
|
0:11:39
|
as the high bandwidth application like the FTP download.
|
|
0:11:45
|
Now the way that fair queuing does that is first it divides the
|
|
0:11:49
|
resource equally amongst the application requests.
|
|
0:11:55
|
So if we were to visualize the output queue
|
|
0:11:59
|
as a bandwidth pipe
|
|
0:12:03
|
and we have ten individual flows inside the output queue
|
|
0:12:08
|
it means that weighted fair queuing is going to divide these
|
|
0:12:11
|
into ten equal amounts for the individual traffic flows.
|
|
0:12:17
|
So 1, 2, 3, 4, 5 etc. all the way down to 10
|
|
0:12:24
|
This means that whatever is the lowest bandwidth of the flow
|
|
0:12:29
|
then determines what is the ratio that the other
|
|
0:12:32
|
flows can reserve
|
|
0:12:33
|
so let's assume that the link is a 100 megabits per second
|
|
0:12:38
|
so this is a Fast Ethernet interface.
|
|
0:12:40
|
If the tenth flow is asking for 1 megabit per second
|
|
0:12:46
|
but the other flows are all asking for let's say a 100
|
|
0:12:50
|
megabits per second so they want to use the entire link
|
|
0:12:53
|
it means that the first thing the scheduling algorithm is going to
|
|
0:12:57
|
do is divide the link into equal 1 megabit per second
|
|
0:13:02
|
flows so it's essentially making sure that the tenth request
|
|
0:13:07
|
is not being denied bandwidth because the other flows are
|
|
0:13:10
|
using too much of the link.
|
|
0:13:13
|
Now once this 1 megabit per second is subtracted out of the
|
|
0:13:17
|
lowest flow, it's going to take whatever ones are left over
|
|
0:13:21
|
and then continue to divide this equally.
|
|
0:13:25
|
So if the fifth flow is asking for 2 megabits per second
|
|
0:13:29
|
it means that there is one remaining between the difference
|
|
0:13:32
|
of these so now they're each given an additional 1 megabit
|
|
0:13:35
|
per second. If the fourth flow is then asking for three
|
|
0:13:40
|
it's going to give these four flows an additional 1 megabit per second
|
|
0:13:43
|
and keep dividing it over and over and over equally
|
|
0:13:47
|
to make sure that whatever the lowest bandwidth flow
|
|
0:13:50
|
is never going to be dropped in favor of the high bandwidth flows.
|
|
0:13:56
|
Now in practice, this is generally not implemented as just fair
|
|
0:14:00
|
queuing. Most of the time it's implemented as weighted
|
|
0:14:04
|
fair queuing which means that it's using that maximum
|
|
0:14:07
|
minimum scheduling, but the flows are not actually equal.
|
|
0:14:12
|
It's going to be based on the weighting that is determined from
|
|
0:14:15
|
the DSCP value or the IP precedence.
|
|
0:14:19
|
And again, remember the DSCP is the first six most significant
|
|
0:14:23
|
bits of the type of service where the IP precedence is the
|
|
0:14:26
|
three most significant bits.
|
|
0:14:30
|
So in weighted fair queuing, the bandwidth is going to be
|
|
0:14:34
|
allocated in a proportion to the weighting of the flow.
|
|
0:14:39
|
So this means that if the traffic's IP precedence is
|
|
0:14:43
|
five for critical, it's going to get more allocation of the
|
|
0:14:47
|
bandwidth than if we were to have a flow that is a
|
|
0:14:51
|
precedence 0 or a precedence 1
|
|
0:14:57
|
The key point of this feature though is that the flows are dynamically
|
|
0:15:00
|
categorized based on both the source and destination
|
|
0:15:04
|
IPs, the source and destination ports
|
|
0:15:07
|
and the type of service value.
|
|
0:15:11
|
So even if we were to have two different flows that are
|
|
0:15:14
|
coming from the same host going to the same destination
|
|
0:15:19
|
assuming that they're going to have different port values
|
|
0:15:23
|
which would be true even if we were using the same
|
|
0:15:25
|
TCP application so let's say that we have host A
|
|
0:15:30
|
that is web browsing to host B
|
|
0:15:32
|
but it's doing two separate times, so it's opening two web
|
|
0:15:35
|
browser windows, the weighted fair queuing is going to treat those
|
|
0:15:39
|
as two separate flows
|
|
0:15:41
|
because even though the source and destination IP address are the
|
|
0:15:44
|
same, the source and destination ports are not.
|
|
0:15:48
|
So this allows the router to dynamically categorize
|
|
0:15:52
|
how different types of traffic are going to be
|
|
0:15:54
|
treated based on the weighting value
|
|
0:15:58
|
on a per flow basis.
|
|
0:16:02
|
Now the only issue with this is that if the number of
|
|
0:16:05
|
flows exceed the number of queues so let's say that there's
|
|
0:16:10
|
ten queues on the interface, but there's a 100 different
|
|
0:16:12
|
flows, then there's going to be overlap between the
|
|
0:16:15
|
flows and the queues.
|
|
0:16:17
|
So some of them are generally going to be shared
|
|
0:16:20
|
depending on how much traffic is being sent over the link
|
|
0:16:23
|
and how many queues that we're actually configuring.
|
|
0:16:28
|
So there's generally only two parameters that we need
|
|
0:16:30
|
to define to configure this we need to turn fair queuing
|
|
0:16:34
|
on, then we can specify what is the overall queue
|
|
0:16:39
|
depth which again is the hold queue.
|
|
0:16:45
|
So it's the same type of logic as before with the
|
|
0:16:47
|
first in first out queuing that we're contending for the
|
|
0:16:51
|
output queue. The difference is that if we are looking at
|
|
0:16:55
|
packets 3, 2 and 1
|
|
0:16:57
|
if packet number 3 has an IP precedence or 5
|
|
0:17:04
|
this would be preferred over packets 2 and 1
|
|
0:17:07
|
where maybe they have a default IP precedence of zero.
|
|
0:17:12
|
So even though the third packet entered after
|
|
0:17:15
|
packets 2 and 1
|
|
0:17:17
|
it could be preferred as it's waiting in the output queue
|
|
0:17:20
|
to go to the head of the queue and then be admitted
|
|
0:17:23
|
to the transmit ring.
|
|
0:17:29
|
So let's look at the configuration of this. Let's say that in our same type of
|
|
0:17:33
|
scenario where previously on Router 4 we were running
|
|
0:17:36
|
first in first out queuing, we want to run this as
|
|
0:17:40
|
weighted fair queuing.
|
|
0:17:42
|
Now we saw before that with the default QoS
|
|
0:17:46
|
if we do not have any MQC policy defined, the link is
|
|
0:17:50
|
generally going to run weighted fair queuing on its own.
|
|
0:17:54
|
Now it has to do with the bandwidth value of the link
|
|
0:17:56
|
whether the router is going to run WFQ as the default or it's
|
|
0:18:01
|
going to run FIFO as the default, but we really
|
|
0:18:04
|
don't even need to memorize what those are. We can see
|
|
0:18:07
|
that just by looking at the show queuing interface
|
|
0:18:10
|
to figure out what the default strategy is.
|
|
0:18:13
|
If there was any question about it, we can always manually define
|
|
0:18:16
|
what the policy is.
|
|
0:18:18
|
So if I define an MQC policy that forces it to be FIFO
|
|
0:18:22
|
I know exactly what strategy it's going to run.
|
|
0:18:24
|
If I specify it's doing fair queuing inside the class
|
|
0:18:28
|
then likewise it's going to be doing weighted fair queuing.
|
|
0:18:35
|
So now let's say on Router 4 we want to run weighted fair queuing
|
|
0:18:38
|
but we want to do it for all traffic.
|
|
0:18:41
|
We're not going to distinguish between web traffic versus
|
|
0:18:44
|
voice traffic or FTP, we'll let the router automatically
|
|
0:18:48
|
figure that out based on the number of queues
|
|
0:18:51
|
that are allocated to the weighted fair queue process.
|
|
0:18:55
|
And this is what's going to be controlled by the number of
|
|
0:18:59
|
queues in the syntax.
|
|
0:19:01
|
So our first step with the module of the quality of service
|
|
0:19:03
|
again is always going to be to specify what type of traffic
|
|
0:19:07
|
are we doing the classification based on.
|
|
0:19:12
|
If I don't want to separate traffic A from B
|
|
0:19:15
|
it simply means that I could use class-default in the policy
|
|
0:19:19
|
which is going to again be our last effort match
|
|
0:19:25
|
or best effort match.
|
|
0:19:28
|
So if I simply define policy map that I'll specify
|
|
0:19:33
|
as weighted fair queuing
|
|
0:19:35
|
so the name is WFQ
|
|
0:19:37
|
under class class-default
|
|
0:19:44
|
I can specify that this is running fair queuing.
|
|
0:19:50
|
You could specify the number of dynamic conversation queues
|
|
0:19:53
|
if I said a 100, that means a 100 queues total.
|
|
0:19:58
|
If I were to have more than 100 flows
|
|
0:20:01
|
it would then mean that there's an overlap between the
|
|
0:20:05
|
queues and the flows.
|
|
0:20:07
|
But let's just leave this as the default. Let's just say fair queue.
|
|
0:20:14
|
Then lastly, we'll go to the link level and say
|
|
0:20:16
|
service policy output
|
|
0:20:18
|
is WFQ which is the name of it.
|
|
0:20:23
|
So now if we look at the show run section policy map
|
|
0:20:28
|
this is essentially the most basic MQC policy that you could define.
|
|
0:20:34
|
So it's saying for class WFQ, we're not classifying traffic
|
|
0:20:38
|
separately. It's going to be just everything together
|
|
0:20:41
|
in class default.
|
|
0:20:42
|
All of this traffic is going to run flow based fair queuing or
|
|
0:20:46
|
flow based weighted fair queuing.
|
|
0:20:49
|
If we now look at the show policy map interface
|
|
0:20:53
|
serial 0/1/0
|
|
0:20:57
|
so if we look at the show policy map interface serial 0/1/0
|
|
0:21:03
|
it says that this queuing strategy is fair queuing, but it's doing
|
|
0:21:07
|
it per flow.
|
|
0:21:09
|
The queue limit is 16
|
|
0:21:13
|
which it essentially means that if there's more than
|
|
0:21:16
|
16 flows they're going to have to start overlapping on
|
|
0:21:20
|
the number of queues.
|
|
0:21:24
|
Inside each of the individual queues we can have no more than
|
|
0:21:28
|
64 packets, so this is essentially the queue depth.
|
|
0:21:33
|
If inside of any of these individual 16 queues
|
|
0:21:39
|
which again is dynamically categorized based on the flows
|
|
0:21:41
|
if we go over 64, then we are going to have tail drop.
|
|
0:21:47
|
So if we were to actually send traffic over the interface
|
|
0:21:51
|
let's say we were to go to Router 5 and to make sure
|
|
0:21:54
|
that we're using this link for transit, I'm simply going to
|
|
0:21:57
|
shut the frame relay interface down.
|
|
0:21:59
|
So on Router 5 we'll say on interface serial 0/0/0
|
|
0:22:03
|
I'll simply shut this link down
|
|
0:22:07
|
now if I were to go to let's say Router 6
|
|
0:22:14
|
and telnet to Switch 2
|
|
0:22:16
|
actually let's do it the other direction. Let's go to Switch 2
|
|
0:22:19
|
and telnet to Router 6
|
|
0:22:26
|
we'll telnet to 150.28.6.6
|
|
0:22:32
|
then to generate a bunch of traffic, I'll say show
|
|
0:22:35
|
tech support
|
|
0:22:37
|
so it's just going to generate a bunch of ascii characters.
|
|
0:22:42
|
If we look at Router 4 and now look at the show policy map interface
|
|
0:22:48
|
we see that packets are being matched by the queue
|
|
0:22:53
|
168 packets, 179 packets
|
|
0:22:56
|
but right now the queue depth is still zero
|
|
0:23:01
|
because really there's no saturation of the link
|
|
0:23:06
|
because the telnet packets itself just those show commands
|
|
0:23:09
|
it's not enough bandwidth to take up the full link speed
|
|
0:23:13
|
between Router 5 and Router 4
|
|
0:23:17
|
so really only once congestion occurs which means that when we're
|
|
0:23:21
|
going to send packets, the transmit ring is consistently
|
|
0:23:25
|
full and we have to delay packets into the output queue.
|
|
0:23:29
|
Only once that delaying starts to occur will the queue depth
|
|
0:23:34
|
grow and then eventually the router could drop packets
|
|
0:23:38
|
if it doesn't have or if it has more than 64 packets
|
|
0:23:42
|
on a per queue basis.
|
|
0:23:46
|
Now in the previous versions you were able to look at the
|
|
0:23:48
|
show queue
|
|
0:23:54
|
for the interface
|
|
0:23:56
|
let's see if it's still going to show this. No it's not going to show it.
|
|
0:23:59
|
So before you were actually able to see what the flows were
|
|
0:24:03
|
but with the policy map it doesn't show you the active traffic
|
|
0:24:06
|
that's going over the interface.
|
|
0:24:07
|
So there's really no way to verify how the traffic is being
|
|
0:24:11
|
classified into one flow versus the other.
|
|
0:24:14
|
You would simply have to look at what's the end result
|
|
0:24:18
|
of the amount of bandwidth that one application is getting
|
|
0:24:21
|
versus the other.
|
|
0:24:23
|
So for example if you were to do two FTP downloads and
|
|
0:24:26
|
they were to transit over this link, they would both get
|
|
0:24:30
|
an equal allocation of the bandwidth. They would get 50
|
|
0:24:33
|
percent of the link.
|
|
0:24:35
|
Now if I were to send other traffic let's say that the
|
|
0:24:44
|
let's say that from Router 6
|
|
0:24:47
|
we're going to run the http server
|
|
0:24:55
|
which is going to serve its IOS image.
|
|
0:24:58
|
Then from Switch 2 we'll download the IOS image
|
|
0:25:02
|
then from Switch 1 I'll telnet or Switch 4 I'll telnet to Router 1
|
|
0:25:05
|
so there's going to be multiple flows that are going over
|
|
0:25:08
|
the interface.
|
|
0:25:10
|
So on Router 6 the first thing I'm going to do is turn the
|
|
0:25:12
|
web service on, so ip http server
|
|
0:25:17
|
the ip http path is the flash
|
|
0:25:22
|
so basically it means just the root of the flash is going to serve the
|
|
0:25:24
|
files, then I'll have user name cisco password cisco
|
|
0:25:29
|
user name cisco privilege level is 15
|
|
0:25:35
|
so in flash we have this image that's a fairly
|
|
0:25:39
|
big file, it's 40 megs.
|
|
0:25:42
|
So if I were to go to...
|
|
0:25:46
|
say Switch 2
|
|
0:25:48
|
we'll copy http
|
|
0:25:53
|
cisco:cisco so that's the user name and password.
|
|
0:25:58
|
From this particular server that's the file and it's going to null.
|
|
0:26:11
|
No such file or directory.
|
|
0:26:17
|
So copy http -- actually let's see this version may not support...
|
|
0:26:25
|
copy http
|
|
0:26:36
|
that should be correct.
|
|
0:26:38
|
So null -- actually the path on 6 it should not be
|
|
0:26:43
|
well it should be flash
|
|
0:26:47
|
let's see, it may need to be
|
|
0:26:51
|
flash:/ let's try it this way.
|
|
0:27:10
|
So 6 should be listening for the http service
|
|
0:27:13
|
one way I could test to make sure that it's actually running is
|
|
0:27:15
|
just to telnet to Router 6 at port 80
|
|
0:27:18
|
and it is open
|
|
0:27:23
|
so let me see the configure on Router 6 let's say show run
|
|
0:27:25
|
include http
|
|
0:27:31
|
ip http path
|
|
0:27:54
|
That should be the correct file name.
|
|
0:27:57
|
Let's try this. Let's say show run
|
|
0:28:01
|
and we'll redirect this to flash:run.txt
|
|
0:28:12
|
show run | redirect
|
|
0:28:16
|
flash:run.txt
|
|
0:28:20
|
so now it should take the running config and generate that file.
|
|
0:28:25
|
If we say more flash:run.txt
|
|
0:28:30
|
Ok, we can see that's just a text file that is the running config.
|
|
0:28:37
|
There's a question, "I missed the c at the beginning of the file name."
|
|
0:28:40
|
Let's look at the -- Oh, did I copy it wrong?
|
|
0:28:49
|
That's the problem. It's the wrong file name.
|
|
0:28:57
|
Ok, so now it's copying it.
|
|
0:28:58
|
You could see again, it's really really slow because the
|
|
0:29:01
|
link is clocked at 64 k
|
|
0:29:03
|
which essentially should now mean that Router 4's queue is
|
|
0:29:07
|
saturated, so if we look at the show policy map interface serial 0/1/0
|
|
0:29:16
|
we see now the queue depth is growing.
|
|
0:29:19
|
So any time you see this value as not zero
|
|
0:29:23
|
it essentially means that there's congestion on the link.
|
|
0:29:27
|
So the transmit ring is full
|
|
0:29:29
|
the output queue is growing because there's not enough
|
|
0:29:31
|
bandwidth in order to service the requests.
|
|
0:29:35
|
If I were to run the same exact command on
|
|
0:29:44
|
Switch 4
|
|
0:29:46
|
Let's say copy http
|
|
0:29:51
|
cisco:cisco at 150.28.6.6
|
|
0:29:59
|
slash the file name
|
|
0:30:07
|
to null. We should see on Router 4 now that the
|
|
0:30:11
|
the queue depth now continues to grow because now there's
|
|
0:30:15
|
more than one request that's taking up the bandwidth.
|
|
0:30:20
|
It says the five minute offered rate is 24 thousand
|
|
0:30:24
|
bits per second. This here this is going to be an
|
|
0:30:27
|
average based on the load interval of the interface
|
|
0:30:32
|
so since we haven't been doing the transfer for five minutes, it's
|
|
0:30:35
|
not really going to be very accurate. What I could
|
|
0:30:38
|
do is go to the link level and say the load-interval
|
|
0:30:43
|
is the minimum let's set it down to 30 seconds
|
|
0:30:46
|
so now it's basing the utilization on a 30 second average
|
|
0:30:52
|
and we should see that this is going to creep up closer towards
|
|
0:30:59
|
64 k
|
|
0:31:00
|
unless these timed out
|
|
0:31:03
|
no, broken pipe
|
|
0:31:06
|
so you'll see over the very slow connection
|
|
0:31:09
|
basically the TCP connection is timing out
|
|
0:31:22
|
and the packets are going to get dropped.
|
|
0:31:25
|
So we see the 30 second offered rate this keeps going up
|
|
0:31:32
|
eventually it should get pretty close to 64 k
|
|
0:31:36
|
but this does not take into account the Layer 2 overhead
|
|
0:31:41
|
which the physical serialization of the link will.
|
|
0:31:44
|
So it's not going to ever get to exactly 64 k
|
|
0:31:47
|
it's going to get pretty close but then we're still going to have
|
|
0:31:50
|
our Layer 2 overhead.
|
|
0:31:53
|
So the key for the weighted fair queuing is that the only thing we're
|
|
0:31:58
|
doing is allowing the router to automatically categorize
|
|
0:32:02
|
what the flows are.
|
|
0:32:04
|
So when it had the two web downloads, one that was coming
|
|
0:32:08
|
from Switch 2, one that was coming from Switch 4
|
|
0:32:10
|
it's essentially going to equally allocate the bandwidth of
|
|
0:32:15
|
one to the other
|
|
0:32:16
|
assuming that the IP precedence values are the same
|
|
0:32:21
|
so if on Switch 2, I were to configure a policy that was marking the
|
|
0:32:26
|
precedence higher and we were to do a bandwidth sampling
|
|
0:32:30
|
we would see that that flow is going to get more bandwidth across the link.
|
|
0:32:36
|
Now the actual calculation
|
|
0:32:39
|
it's not really that important how it figures out what the
|
|
0:32:42
|
the weighting and what the bandwidth is going to be.
|
|
0:32:45
|
It's essentially going to be a relative proportion based on
|
|
0:32:51
|
the weighting value where if the weight is higher, it's going to
|
|
0:32:53
|
get more bandwidth.
|
|
0:32:55
|
There's a question here, "The whole queue out applies
|
|
0:32:57
|
to both fair queuing and FIFO?" Correct, so when we're specifying
|
|
0:33:03
|
the total hold queue, that's going to control what's the
|
|
0:33:10
|
the total number of packets for the queue limit here.
|
|
0:33:16
|
Now for the module of the quality of service, we would
|
|
0:33:19
|
specify this under the class itself where with the
|
|
0:33:24
|
legacy versions you would do this at the link level.
|
|
0:33:26
|
So if I wanted to change how many buffers there were on
|
|
0:33:29
|
a per queue basis
|
|
0:33:32
|
I would go now under policy map WFQ
|
|
0:33:37
|
for class class-default
|
|
0:33:41
|
change the
|
|
0:33:45
|
the queue limit
|
|
0:33:49
|
and let's say a 100 packets
|
|
0:33:53
|
now if we show policy map interface
|
|
0:33:57
|
this is what the hold queue is here for this particular policy.
|
|
0:34:02
|
So the syntax is a little bit different depending on whether
|
|
0:34:05
|
you're doing it directly at the interface level or under
|
|
0:34:07
|
the policy, but it's affecting the same thing.
|
|
0:34:11
|
So you're saying in each of these individual queues
|
|
0:34:17
|
at what point if the packets go above that do you start
|
|
0:34:20
|
to perform the tail drop?
|
|
0:34:22
|
Now notice that when I change the queue limit, it
|
|
0:34:25
|
automatically changed the number of queues total
|
|
0:34:29
|
so the per flow queue limit
|
|
0:34:32
|
so internally there's going to be a ratio that the router
|
|
0:34:34
|
calculates for these.
|
|
0:34:36
|
But normally you wouldn't have to change these at all.
|
|
0:34:39
|
If the router's dropping packets really there's
|
|
0:34:42
|
nothing that you can change with the weighted fair queuing
|
|
0:34:44
|
it simply means that there's not enough bandwidth that the
|
|
0:34:47
|
applications are contending for.
|
|
0:34:49
|
Now where this configuration is going to be significant
|
|
0:34:53
|
is when we get into the bandwidth reservation
|
|
0:34:55
|
inside the module of the quality of service or inside the
|
|
0:34:58
|
HQF, so essentially what the bandwidth keyword does
|
|
0:35:04
|
is a manual flow definition of the weighted fair queuing
|
|
0:35:10
|
where with the previous example, the router is automatically calculating
|
|
0:35:14
|
based on the source address, the destination address,
|
|
0:35:17
|
the source and destination port and the precedence value
|
|
0:35:21
|
what determines one flow versus another.
|
|
0:35:25
|
But with the class based weighted fair queuing, this
|
|
0:35:27
|
is originally why it was called that HB or CBWFQ
|
|
0:35:33
|
is that we're doing weighted fair queuing, but based on the
|
|
0:35:36
|
class we are defining one flow versus the other.
|
|
0:35:41
|
So now instead of the weight being automatically calculated
|
|
0:35:44
|
based on the precedence, we are defining the weight with
|
|
0:35:48
|
the bandwidth keyword.
|
|
0:35:51
|
So again, now the bandwidth is going to be shared proportionally
|
|
0:35:53
|
to the weight values, but the difference is that we are
|
|
0:35:57
|
manually defining this.
|
|
0:36:00
|
Now there's a couple different ways that we can do this
|
|
0:36:03
|
we could specify this as a kilobit per second value
|
|
0:36:06
|
under the class or we can do it as a percentage of
|
|
0:36:11
|
the interface's bandwidth
|
|
0:36:15
|
where the advantage of doing the latter, percentage reservation,
|
|
0:36:19
|
is that we could specify a standard template
|
|
0:36:23
|
that regardless of whether we apply this on GigE or DS3 or
|
|
0:36:28
|
OC48, you're still going to have the same relative reservations
|
|
0:36:32
|
of one class versus another.
|
|
0:36:34
|
So if I say that my web traffic should get 10 percent
|
|
0:36:39
|
then if I apply that to a Fast Ethernet interface, that's going to
|
|
0:36:43
|
be 10 megabits per second on average
|
|
0:36:45
|
where if it was the GigE, it would be a 100 megabits per second.
|
|
0:36:50
|
But if I specify the absolute reservation with bandwidth in kilobits per second
|
|
0:36:54
|
then it's going to be different depending on the underlying physical
|
|
0:36:57
|
media that the policy is going to apply to.
|
|
0:37:02
|
Now in any case when we're doing the reservations, the
|
|
0:37:06
|
bandwidth is always going to add up to a 100 percent
|
|
0:37:11
|
so what this means is now that we're doing class based weighted fair queuing
|
|
0:37:15
|
the default class is going to be reserved whatever you do not
|
|
0:37:20
|
reserve for the other classes.
|
|
0:37:25
|
So overall, if I were to say that I have let's say
|
|
0:37:29
|
three classes.
|
|
0:37:31
|
I have class map C1
|
|
0:37:39
|
C2, C3 and C4
|
|
0:37:42
|
so I'm specifying whatever match that is classifying traffic one versus
|
|
0:37:46
|
two, three and four separately.
|
|
0:37:49
|
Then I'm referencing all four of these from inside of a policy map.
|
|
0:37:54
|
So policy map P1
|
|
0:37:57
|
I have class C1
|
|
0:38:01
|
I'm specifying the bandwidth let's say bandwidth percent
|
|
0:38:11
|
is 10
|
|
0:38:12
|
If I were to do this for the same in 2, 3 and 4
|
|
0:38:18
|
it means for these four classes as a whole
|
|
0:38:21
|
we are reserving 40 percent of the bandwidth
|
|
0:38:25
|
it then means for the best effort class which is class-default
|
|
0:38:29
|
it's actually being reserved 60 percent of the bandwidth.
|
|
0:38:34
|
So the percentages are always going to add up to 100
|
|
0:38:37
|
regardless of whether you're actually using the percentage command
|
|
0:38:40
|
or you're doing it in bandwidth in kilobits per second
|
|
0:38:44
|
because the router is going to calculate what the relative
|
|
0:38:48
|
share is going to be between the different classes.
|
|
0:38:52
|
Now the key point though is that inside the individual class
|
|
0:38:57
|
so if I specify a class's matching web traffic, inside the web traffic
|
|
0:39:03
|
that is a first in first out queue.
|
|
0:39:08
|
So as compared to the other classes, so class 1 versus class 2
|
|
0:39:12
|
those are different weightings depending on the
|
|
0:39:15
|
bandwidth that I'm defining, but inside of those
|
|
0:39:20
|
all of the class 1 traffic is treated equal to
|
|
0:39:24
|
all of the other class 1 traffic.
|
|
0:39:26
|
So it's first in first out inside of that individual queue.
|
|
0:39:31
|
We can manually modify that and this is why the new policies
|
|
0:39:35
|
are called the hierarchical queuing framework
|
|
0:39:39
|
because if I were to specify that I have let's say on Router 4
|
|
0:39:48
|
we have class map that is
|
|
0:39:51
|
class 1
|
|
0:39:53
|
let's say class 1 is going to be telnet
|
|
0:39:57
|
that is match protocol telnet.
|
|
0:40:01
|
I have a second class map that is SMTP
|
|
0:40:06
|
match protocol smtp
|
|
0:40:09
|
ok, so that's going to be for send mail
|
|
0:40:11
|
then I have a third one class map that is http
|
|
0:40:16
|
match protocol http
|
|
0:40:20
|
so now for these three classes I want to do weighted fair queuing.
|
|
0:40:25
|
Next step is I would define the policy. We'll say policy map
|
|
0:40:30
|
HQF
|
|
0:40:35
|
for class telnet
|
|
0:40:40
|
I'm doing a bandwidth reservation
|
|
0:40:42
|
let's say we do this as relative reservations. We'll say bandwidth
|
|
0:40:45
|
percent is 10 for telnet.
|
|
0:40:50
|
For class smtp, we're giving it 20
|
|
0:40:55
|
For class http, we're giving it 30
|
|
0:41:00
|
Class default I did not specify which means it's getting the rest.
|
|
0:41:05
|
Then at the link level we'll say service policy
|
|
0:41:09
|
output
|
|
0:41:11
|
is HQF
|
|
0:41:15
|
Now it should tell me here that I can only apply one at a
|
|
0:41:17
|
time which means I now need to say no service policy
|
|
0:41:23
|
WFQ or no service policy out WFQ
|
|
0:41:32
|
and then apply the new one HQF
|
|
0:41:36
|
If we look at the show policy map
|
|
0:41:41
|
show policy map interface serial 0/1/0
|
|
0:41:48
|
it says that for telnet
|
|
0:41:51
|
the only thing we're doing in the queuing is specifying the
|
|
0:41:54
|
queue limit.
|
|
0:41:58
|
But this is being queued separately than SMTP
|
|
0:42:01
|
and separately than HTTP.
|
|
0:42:07
|
For the class default this is going to be everything else
|
|
0:42:10
|
that's left over.
|
|
0:42:12
|
So each of these classes they still have individual queue limits
|
|
0:42:16
|
which essentially is the hold queue or the queue depth
|
|
0:42:21
|
but inside of the individual queues, so inside of the
|
|
0:42:25
|
individual classes we're not classifying one web flow
|
|
0:42:29
|
differently than another one.
|
|
0:42:32
|
So if someone's web traffic is using IP precedence 5
|
|
0:42:35
|
it's not going to be treated any different than someone
|
|
0:42:38
|
else's web flow that's using IP precedence 0
|
|
0:42:42
|
Now we can manually define that because now the
|
|
0:42:45
|
queues have hierarchy where I could say for policy map
|
|
0:42:50
|
HQF
|
|
0:42:52
|
for class http
|
|
0:42:56
|
I do want to do fair queuing for this one, but not for the others
|
|
0:43:01
|
If we look at the show policy map interface
|
|
0:43:05
|
we now see that the web traffic is doing per flow
|
|
0:43:08
|
fair queuing where the send mail is essentially just doing
|
|
0:43:15
|
first in first out.
|
|
0:43:20
|
So if we were to look at this visually, we essentially have multiple
|
|
0:43:25
|
levels of hierarchy for the output queue, so if we figure that
|
|
0:43:29
|
this entire structure is the overall output queue
|
|
0:43:35
|
then we're trying to get over to the transmit ring. That's the final stop.
|
|
0:43:39
|
Inside here
|
|
0:43:42
|
we now have four separate queue definitions.
|
|
0:43:47
|
We have the telnet
|
|
0:43:51
|
the send mail SMTP
|
|
0:43:53
|
the web traffic
|
|
0:43:55
|
and then anything else, so any is the class default.
|
|
0:44:00
|
I'm then doing a reservation of saying 10 percent
|
|
0:44:03
|
to 10 percent
|
|
0:44:06
|
to 10 percent
|
|
0:44:07
|
which means the other class is by default getting 70 percent
|
|
0:44:14
|
but as traffic enters telnet when it comes first in the
|
|
0:44:19
|
queue, it's going to be first out the queue.
|
|
0:44:23
|
So whatever the order the telnet packets are received
|
|
0:44:26
|
that's how they're going to be transmitted to the physical
|
|
0:44:30
|
physical interface driver.
|
|
0:44:32
|
But now inside Http, I'm saying that this is running
|
|
0:44:35
|
weighted fair queuing, so now if I had precedence 7
|
|
0:44:41
|
this is going to be weighted higher inside of this queue
|
|
0:44:44
|
versus precedence 5 or precedence 1
|
|
0:44:50
|
so there's essentially multiple levels of hierarchy for the queuing.
|
|
0:44:53
|
We have the overall output queue that's running weighted
|
|
0:44:56
|
fair queuing, but then there's four sub queues three of which are
|
|
0:45:01
|
running first in first out and one that is running weighted
|
|
0:45:04
|
fair queuing, but the key to remember when we're comparing
|
|
0:45:07
|
all four of these together is that at a minimum
|
|
0:45:13
|
they're going to get whatever value that we define them
|
|
0:45:15
|
as the bandwidth, so the weighting here is essentially
|
|
0:45:18
|
a minimum reservation that internally is
|
|
0:45:24
|
calculated based on ratio.
|
|
0:45:25
|
So the router's not really saying I'm going to give this
|
|
0:45:29
|
10 megabits per second, it's saying based on the weighting of the flow
|
|
0:45:33
|
eventually you get the effective rate of 10 megabits per second
|
|
0:45:37
|
but programmatically it's not that simple to implement.
|
|
0:45:40
|
So it has to do with how the flows are weighted
|
|
0:45:44
|
when the router actually admits them to the transmit ring
|
|
0:45:49
|
that the weighting is going to be derived from the bandwidth that
|
|
0:45:52
|
we are configuring.
|
|
0:45:54
|
Now for some reason one class doesn't use that amount of
|
|
0:45:58
|
bandwidth, the other ones are not policed to limit them to
|
|
0:46:02
|
that, so in our particular case here where we're saying
|
|
0:46:06
|
that the default class is getting 70 percent
|
|
0:46:10
|
if this is only 50 percent utilized and we have an additional
|
|
0:46:14
|
20 percent left over, that's going to go to these other
|
|
0:46:19
|
three classes because we're still implementing
|
|
0:46:23
|
that max-min scheduling
|
|
0:46:27
|
where essentially we're saying take the minimum amount that any
|
|
0:46:31
|
class is requesting and then divide -- take that and allocate it
|
|
0:46:36
|
to all of the classes. If there's classes that are still left over that are
|
|
0:46:41
|
asking for more resources, you're going to take the next
|
|
0:46:45
|
minimum one and then spread that against all of the other
|
|
0:46:48
|
remaining classes, so the queuing keeps doing that over and over
|
|
0:46:52
|
and over recursively until either all of the requests are
|
|
0:46:56
|
satisfied or there's no bandwidth left.
|
|
0:46:58
|
So again, that's the regular fair queuing without the weighting.
|
|
0:47:02
|
But now in this case we're manually defining the weighting
|
|
0:47:07
|
but we're saying that that is essentially the minimum
|
|
0:47:09
|
that they are guaranteed so if the default class is only
|
|
0:47:12
|
using 50 percent, this other 20 would be allocated to
|
|
0:47:16
|
the other classes in a max-min fashion.
|
|
0:47:20
|
Now design wise, this means that the weighted fair
|
|
0:47:23
|
queuing or the hierarchical queuing framework you would use
|
|
0:47:27
|
this for any application that you want to guarantee that
|
|
0:47:31
|
it is not going to get dropped up to a certain threshold.
|
|
0:47:36
|
So if I know that my voice signaling is going to take
|
|
0:47:40
|
x amount of bandwidth based on how many phones could potentially
|
|
0:47:43
|
be making calls at the same time, then I would do a reservation
|
|
0:47:48
|
to make sure that up to a certain value, that type of
|
|
0:47:53
|
traffic is always guaranteed admittance to the output queue.
|
|
0:47:57
|
Now it might have to wait I'm not saying how long it's going to be
|
|
0:48:00
|
delayed in the queue, I'm just saying that when we actually
|
|
0:48:03
|
go to get a buffer allocation, we're guaranteed that we're going to
|
|
0:48:06
|
get it, so key point being the bandwidth keyword is a
|
|
0:48:12
|
minimum reservation. It doesn't say anything about how long
|
|
0:48:15
|
you're going to wait in the queue so it's doesn't control
|
|
0:48:17
|
your delay, but it is not policed to the maximum
|
|
0:48:21
|
to the value that you're configuring.
|
|
0:48:24
|
So if I say bandwidth 1000 I'm saying at worst case scenario
|
|
0:48:27
|
I'm guaranteed to get 1 megabit per second at the queue.
|
|
0:48:32
|
If the queue is not a 100 percent saturated
|
|
0:48:36
|
then I really don't need to do the reservation to begin with
|
|
0:48:39
|
because there's extra bandwidth left over, so I can use it if the
|
|
0:48:43
|
if the transmit ring is not a 100 percent utilized or
|
|
0:48:46
|
excuse me, the output queue is not a 100 percent utilized
|
|
0:48:50
|
but the ratio is going to be based on that
|
|
0:48:53
|
max-min scheduling.
|
