|
0:00:13
|
In our next section for QoS here, we're going to talk about
|
|
0:00:16
|
the low latency queuing or LLQ
|
|
0:00:19
|
which is used to reorder traffic and prioritize it as it enters
|
|
0:00:24
|
the output queue and then ultimately leaves the tail of the
|
|
0:00:28
|
output queue to be admitted into the transmit ring.
|
|
0:00:34
|
Now the important point to note about the priority queue is
|
|
0:00:36
|
that there's only one per HQF configuration
|
|
0:00:41
|
that can be shared between multiple classes, but in that
|
|
0:00:45
|
case, they are still going to be contending to the
|
|
0:00:47
|
single priority queue.
|
|
0:00:50
|
So what I mean by this is that we can have one class
|
|
0:00:54
|
and a second class that are referenced under the same policy
|
|
0:00:57
|
map that are both having the priority statement, but ultimately
|
|
0:01:01
|
one is not going to be preferred over another.
|
|
0:01:04
|
The only goal of that would be to police the traffic to different
|
|
0:01:08
|
rates because the value x here in kilobits per second
|
|
0:01:13
|
is used as a policing value that if the output queue is congested
|
|
0:01:18
|
traffic above the rate x is subject to drop.
|
|
0:01:25
|
Now typically this priority traffic is going to be
|
|
0:01:28
|
some sort of low bandwidth application like voice traffic
|
|
0:01:32
|
because we do want to avoid the case where there
|
|
0:01:34
|
is too much priority traffic that essentially starves the other
|
|
0:01:38
|
types of applications from bandwidth in the output queue.
|
|
0:01:43
|
Originally this came from the legacy priority queue application
|
|
0:01:47
|
which would say that one particular application
|
|
0:01:50
|
that we're classifying has absolute priority over
|
|
0:01:53
|
all other traffic, then with the low latency queue
|
|
0:01:57
|
it introduced the policer in addition to the prioritization.
|
|
0:02:03
|
So the key here is that since we are always emptying the
|
|
0:02:06
|
priority queue first, the policer ensures that other bandwidth
|
|
0:02:10
|
types or other traffic types are not starved a bandwidth
|
|
0:02:13
|
in the output queue because if the priority traffic goes to
|
|
0:02:16
|
exceed its limit x, there's basically two options that
|
|
0:02:20
|
can occur.
|
|
0:02:21
|
If the output queue is not congested, that traffic will
|
|
0:02:25
|
be admitted, but it is not going to be guaranteed
|
|
0:02:27
|
priority so if I were to say priority 100 for example
|
|
0:02:33
|
that would mean the first 100 kilobits per second of
|
|
0:02:35
|
that particular class will always be sent first out of the
|
|
0:02:39
|
output queue.
|
|
0:02:41
|
If I were to exceed 100 and the output queue is not
|
|
0:02:44
|
congested, then that traffic would be sent, but it would not
|
|
0:02:49
|
be sent first. On the other hand, if I went over
|
|
0:02:53
|
the 100 kilobit per second rate that I'm defining
|
|
0:02:56
|
and congestion is occurring, it means that traffic will be
|
|
0:03:00
|
subject to drop.
|
|
0:03:05
|
Now in newer versions of the HQF, you can also define the
|
|
0:03:08
|
priority as absolute where you do not need to designate
|
|
0:03:13
|
a bit per second value, this means that whatever type
|
|
0:03:17
|
of traffic is matched by the priority queue
|
|
0:03:20
|
is always going to be sent first without a policer.
|
|
0:03:26
|
So again, the potential issue with this is that
|
|
0:03:29
|
if there's too much priority traffic, the other classes
|
|
0:03:32
|
could potentially get starved of bandwidth from the output queue.
|
|
0:03:37
|
Now when we're using the low latency queue, there's
|
|
0:03:39
|
also an option for the manual bandwidth weightings of the
|
|
0:03:43
|
classes to specify the remaining bandwidth as a percentage
|
|
0:03:49
|
or a kilobit per second value of the interface bandwidth
|
|
0:03:53
|
minus what is being reserved by the low latency queue
|
|
0:03:57
|
as either a relative percentage of the link or as a flat
|
|
0:04:01
|
bandwidth in kilobits per second.
|
|
0:04:04
|
Now configuration wise for the documentation
|
|
0:04:08
|
this would be documented under congestion management
|
|
0:04:11
|
so both the weighted fair queuing with the bandwidth command
|
|
0:04:15
|
and prioritization are considered congestion management techniques
|
|
0:04:20
|
because technically, they don't apply unless the output
|
|
0:04:24
|
queue is actually in use.
|
|
0:04:26
|
So again, with the weightings that we're doing manually with the
|
|
0:04:29
|
bandwidth keyword, there's no need to do a reservation if the queue is
|
|
0:04:32
|
not being used to begin with.
|
|
0:04:35
|
So with the bandwidth statement, there's no limit as to how much
|
|
0:04:37
|
you can use as a maximum
|
|
0:04:40
|
but instead we're guaranteeing at a minimum what type of
|
|
0:04:44
|
bandwidth you are guaranteed in the output queue.
|
|
0:04:48
|
Now technically the low latency queue could be
|
|
0:04:50
|
considered the opposite of this where we are
|
|
0:04:53
|
guaranteeing a maximum value because we are
|
|
0:04:56
|
also implementing the policer at the same time.
|
|
0:05:00
|
So here under network or congestion management,
|
|
0:05:03
|
this would be under weighted fair queuing, the low latency queuing
|
|
0:05:07
|
and the weighted fair queuing.
|
|
0:05:10
|
Now if we look at this specific version that we're running here
|
|
0:05:14
|
again, this is IOS version 12.4 24 T so essentially
|
|
0:05:19
|
anything that is 12.4 20 or later that is going to implement
|
|
0:05:23
|
the hierarchical queuing framework. If we were to
|
|
0:05:27
|
define a class let's say for example class map voice
|
|
0:05:32
|
that matches protocol RTP, the real time protocol,
|
|
0:05:38
|
then under a policy map if we say this is the low latency
|
|
0:05:42
|
queue, for class VoIP
|
|
0:05:45
|
we have a couple different options for priority.
|
|
0:05:49
|
Again, in the newer versions we can simply say priority without
|
|
0:05:53
|
a kilobit per second argument, this means that this class
|
|
0:05:56
|
will now be preferred over all other classes regardless.
|
|
0:06:02
|
Now when we do this if we also wanted to do a reservation
|
|
0:06:06
|
for other non-priority classes
|
|
0:06:09
|
there's a change in the way the HQF works than how it did previously
|
|
0:06:14
|
with the class based weighted fair queuing.
|
|
0:06:18
|
So on Router 4 let's look at the show run section class map
|
|
0:06:28
|
and we see that there's the Voice over IP class
|
|
0:06:30
|
which is specifying real time protocol
|
|
0:06:33
|
which would be the actual UDP payload of the voice
|
|
0:06:38
|
in addition to telnet http and SMTP.
|
|
0:06:43
|
So let's say in this particular case I want to do prioritization
|
|
0:06:47
|
for the voice, but I also want to give a weighted fair queuing
|
|
0:06:51
|
weighting to the telnet web traffic and SMTP.
|
|
0:06:57
|
So in this particular class, I've defined the voice
|
|
0:07:02
|
the policy map low latency queue we're specifying if the traffic
|
|
0:07:05
|
is matched by the class VoIP we're going to give it
|
|
0:07:09
|
absolute priority.
|
|
0:07:11
|
For any other non-priority classes now if I were to say
|
|
0:07:16
|
telnet for example, if I tried to do a bandwidth reservation
|
|
0:07:20
|
let's say bandwidth 100
|
|
0:07:23
|
it says now the bandwidth in kilobits per second
|
|
0:07:27
|
or percentage cannot coexist with strict prioritization
|
|
0:07:30
|
or priority levels in the same policy map.
|
|
0:07:34
|
So I can give this a bandwidth reservation, but the behavior is a little
|
|
0:07:39
|
bit different in the new HQF where I would have to say
|
|
0:07:41
|
that this is a remaining bandwidth percentage.
|
|
0:07:45
|
So if I say that telnet is going to get 20 percent of
|
|
0:07:48
|
the remaining bandwidth, it essentially means what the
|
|
0:07:51
|
low latency queue is not using, then telnet
|
|
0:07:56
|
would be weighted whatever internal value to get an
|
|
0:08:00
|
end result of 20 percent of the reservation.
|
|
0:08:04
|
Likewise, if I were to say for class http we'll give this a
|
|
0:08:08
|
reservation of 30 percent and class SMTP
|
|
0:08:13
|
maybe we'll give this a reservation of 40 percent.
|
|
0:08:20
|
Once we go to apply this at the interface if we
|
|
0:08:22
|
now say service policy output
|
|
0:08:25
|
is the LLQ
|
|
0:08:29
|
I'll have to remove the previous policy so no service policy output HQF
|
|
0:08:36
|
add the new policy LLQ
|
|
0:08:38
|
then if we look at the show policy map interface serial 0/1/0
|
|
0:08:46
|
it says that now there is the class VoIP
|
|
0:08:52
|
this is getting strict prioritization
|
|
0:08:57
|
so essentially this means that regardless of the bandwidth value
|
|
0:09:00
|
all voice traffic is always going to be sent out the link first.
|
|
0:09:05
|
If for some reason the voice traffic is not being sent
|
|
0:09:08
|
then the telnet traffic
|
|
0:09:12
|
is going to get 20 percent of the remaining bandwidth
|
|
0:09:16
|
where the web traffic is going to get 30 percent of the remaining bandwidth.
|
|
0:09:24
|
We can see that there are kilobit per second values that
|
|
0:09:26
|
the router has calculated off of these. This is going to be based
|
|
0:09:30
|
on again what is the underlying bandwidth command at the interface level.
|
|
0:09:37
|
Now the reason that this is important is that the bandwidth
|
|
0:09:40
|
keyword at the link level so again, this is separate
|
|
0:09:43
|
from your bandwidth configuration under QoS, if we were to have
|
|
0:09:48
|
let's say a Fast Ethernet interface
|
|
0:09:50
|
that on the other end of the link someone was policing
|
|
0:09:54
|
inbound, so if we were to look at our topology here
|
|
0:09:59
|
let's assume that Router 4's connection to BB3 is the
|
|
0:10:04
|
link to the service provider
|
|
0:10:06
|
and the service provider is offering Router 4
|
|
0:10:10
|
a Metro Ethernet connection into the network.
|
|
0:10:13
|
So as opposed to DS3 or some sort of other legacy
|
|
0:10:17
|
PSTN configuration.
|
|
0:10:21
|
So Router 4's interface physically is going to clocked at a 100
|
|
0:10:24
|
megabits per second.
|
|
0:10:26
|
This is how fast the traffic is going to be serialized
|
|
0:10:29
|
regardless of what the utilization of the queue is.
|
|
0:10:32
|
So whether I have one byte to send or 10 million bytes to send
|
|
0:10:37
|
I'm always sending them at the serialization rate
|
|
0:10:39
|
of a 100 megabits per second.
|
|
0:10:43
|
Now the potential issue that we run into is that if BB3 is policing
|
|
0:10:47
|
inbound, so let's assume they say to Router 4 I'm going to
|
|
0:10:52
|
give you a physical Fast Ethernet interface, but I'm only going to
|
|
0:10:56
|
accept 25 megabits per second inbound.
|
|
0:11:01
|
So the effective bandwidth is 25 megs where the physical
|
|
0:11:04
|
bandwidth is a 100 megs
|
|
0:11:07
|
where this potentially could be a problem is that when we
|
|
0:11:10
|
are doing relative reservations like in this case the bandwidth
|
|
0:11:14
|
remaining percent or just the bandwidth percent on its own.
|
|
0:11:20
|
If the underlying bandwidth keyword that the percentage
|
|
0:11:24
|
reservation comes from does not actually affect or does not
|
|
0:11:27
|
actually reflect the underlying -- the bandwidth rate that is
|
|
0:11:34
|
being policed to on the other side, it means that the router
|
|
0:11:39
|
could potentially be dequeuing the traffic too fast.
|
|
0:11:43
|
So any time that on the other end of the link they are enforcing
|
|
0:11:47
|
a rate that is not equal to the actual physical serialization
|
|
0:11:52
|
we should go to the link level and then specify the bandwidth
|
|
0:11:55
|
keyword. In this case it would be to 25000
|
|
0:12:02
|
Now if I were to do this on serial 0/1/0 let's say the
|
|
0:12:05
|
bandwidth is 25000
|
|
0:12:08
|
then we look at the show policy map interface serial 0/1/0
|
|
0:12:19
|
notice now that these percentage reservations have changed
|
|
0:12:24
|
because the underlying bandwidth value of the link has changed.
|
|
0:12:30
|
So this is a fundamental difference whether we're doing the priority
|
|
0:12:34
|
as a kilobit per second value and a percentage
|
|
0:12:37
|
versus the strict prioritization which is essentially priority of a
|
|
0:12:41
|
100 percent because in the case of the strict prioritization
|
|
0:12:47
|
the additional weighted fair queue weightings can only be in the
|
|
0:12:52
|
remaining bandwidth percentages.
|
|
0:12:59
|
Now also notice that on Router 4 when I applied this configuration
|
|
0:13:02
|
it said that the bandwidth kilobit per second command
|
|
0:13:07
|
cannot coexist with strict prioritization or with priority
|
|
0:13:10
|
levels in the same policy map. In certain versions, the router
|
|
0:13:16
|
supports multiple low latency queues that do not contend with
|
|
0:13:20
|
each other where we have a priority low latency queue level
|
|
0:13:25
|
one and a second low latency queue with a priority level of two
|
|
0:13:31
|
which would mean that the low latency queue one is always
|
|
0:13:34
|
serviced first before low latency queue two.
|
|
0:13:39
|
So this comes from the legacy priority list configuration
|
|
0:13:44
|
where if we were to look at Router 4 and in global config
|
|
0:13:47
|
say priority
|
|
0:13:50
|
priority list 1
|
|
0:13:53
|
the protocol let's say ip for example
|
|
0:14:01
|
would be in the high queue.
|
|
0:14:03
|
So in the case of the legacy prioritization, there were four
|
|
0:14:07
|
different queues high, medium, normal and low
|
|
0:14:10
|
where all the high traffic is processed first followed by the
|
|
0:14:13
|
medium. If there is neither high nor medium, then we would
|
|
0:14:17
|
process the low or excuse me, the normal. If there were neither
|
|
0:14:21
|
high, medium or normal, then we would process the low.
|
|
0:14:27
|
But again the potential problem with this configuration is that
|
|
0:14:29
|
if there are consistently packets in the upper queues like the medium
|
|
0:14:34
|
or high queue, it means that packets in the low or the normal
|
|
0:14:39
|
queue potentially would not get serviced at all.
|
|
0:14:42
|
So in the newer versions you can do this with a low latency
|
|
0:14:45
|
queue the absolute priority value, but unless you know
|
|
0:14:48
|
your actual application utilization that's going to be on the link
|
|
0:14:54
|
like what's the worst case scenario you would use
|
|
0:14:57
|
for your voice bandwidth, then it may not really be a good design
|
|
0:15:00
|
choice in order to do that.
|
|
0:15:02
|
So let's also say that we had another class that was
|
|
0:15:07
|
let's say class map is video
|
|
0:15:12
|
and the video let's say match protocol
|
|
0:15:33
|
and then whatever our video would be let's say Skype in this case.
|
|
0:15:39
|
If we look at the show run section policy map
|
|
0:15:46
|
right now I have four different classes defined in low latency queue
|
|
0:15:50
|
so the VoIP class that is a 100 percent priority that is absolute
|
|
0:15:54
|
strict priority the telnet, web and SMTP those are getting
|
|
0:15:58
|
relative reservation based on whatever else is left over.
|
|
0:16:01
|
So essentially class class-default
|
|
0:16:04
|
is getting 10 percent of the remaining bandwidth
|
|
0:16:09
|
because we didn't reserve it explicitly
|
|
0:16:13
|
it means it's going to be a 100 minus whatever we are manually
|
|
0:16:15
|
reserving.
|
|
0:16:18
|
So now if I were to go under this policy map
|
|
0:16:22
|
and specify for class video I additionally want to go
|
|
0:16:26
|
do prioritization
|
|
0:16:30
|
let's say priority 1000
|
|
0:16:34
|
I don't believe this one actually supports it.
|
|
0:16:41
|
It says multiple priorities within the same priority level
|
|
0:16:47
|
is not allowed, so let's go back to the documentation here
|
|
0:17:00
|
then to the configuring weighted fair queuing
|
|
0:17:04
|
and I'm going to search for priority here
|
|
0:17:07
|
there should be a separate document that specifies
|
|
0:17:09
|
the priority levels. I'm not a 100 percent sure this is
|
|
0:17:14
|
actually supported in 12.4 T though
|
|
0:17:17
|
so let me just search for this. Let's say site www.cisco.com
|
|
0:17:22
|
LLQ priority levels
|
|
0:17:41
|
which is this one multi-level priority queues.
|
|
0:17:45
|
This says 12.2 31 SB2
|
|
0:17:51
|
so I'm not a 100 percent sure whether this is going to be supported
|
|
0:17:53
|
on the lower level platforms, but if we look at the configuration
|
|
0:17:57
|
for this, this simply says that
|
|
0:18:02
|
under the prioritization, there's two different levels. There's
|
|
0:18:06
|
priority level one and there's priority level two.
|
|
0:18:09
|
So each of them are getting a 100 percent strict priority
|
|
0:18:14
|
but then there's a manual policer that they're specifying.
|
|
0:18:19
|
So essentially whatever this class bronze is
|
|
0:18:22
|
it's getting the second level of prioritization up to 1 megabit per second
|
|
0:18:29
|
where level one is assigned to the gold class
|
|
0:18:34
|
and is getting prioritization up to 30 percent of the link level.
|
|
0:18:40
|
Now I'm not a 100 percent sure whether that's actually
|
|
0:18:43
|
supported because they're doing a kilobit per second
|
|
0:18:47
|
policing, but then also a policing in the percentage.
|
|
0:18:51
|
You may see that the parser gives you an error for that
|
|
0:18:55
|
but in this particular case we're saying that there are
|
|
0:18:58
|
two different low latency queues one that's going to be
|
|
0:19:00
|
processed before the other one
|
|
0:19:03
|
where in the vast majority of versions if there are
|
|
0:19:06
|
multiple classes that are both assigned as priority
|
|
0:19:10
|
they will contend for the same priority queue, but they can be
|
|
0:19:15
|
policed to different levels.
|
|
0:19:18
|
Now an example of this would be if we wanted the voice
|
|
0:19:22
|
and the video to both be in the priority queue
|
|
0:19:24
|
but we know that the voice is going to take less bandwidth
|
|
0:19:29
|
than the video is, it might make sense to separate
|
|
0:19:33
|
the voice separately to make sure that the video is not going to
|
|
0:19:38
|
take over the voice's potential bandwidth value.
|
|
0:19:42
|
So if we were to say theoretically that maybe the voice
|
|
0:19:47
|
we want a 100 kilobits per second
|
|
0:19:51
|
of priority
|
|
0:19:54
|
then for the video, we want 900 k
|
|
0:20:00
|
so both of them together are going to add up to
|
|
0:20:03
|
to 1 Megabit per second.
|
|
0:20:06
|
If we were to specify this in a single class
|
|
0:20:10
|
the difference is that the video traffic could take up to
|
|
0:20:13
|
1 Megabit per second
|
|
0:20:16
|
which essentially would starve the voice of all bandwidth.
|
|
0:20:21
|
But in the case where the classes are defined separately
|
|
0:20:24
|
with different rates, as an aggregate they still would
|
|
0:20:28
|
never both exceed 1 Megabit per second together
|
|
0:20:31
|
but if video is using 900, it means that voice has still
|
|
0:20:35
|
allocated at least 100
|
|
0:20:39
|
then in the case that the output queue is a 100 percent full
|
|
0:20:42
|
then either the voice or the video traffic is going to be
|
|
0:20:46
|
subject to drop.
|
|
0:20:47
|
So again, the overall key point here with the low latency
|
|
0:20:50
|
queuing is that this is used to reorder the packets
|
|
0:20:54
|
as they're moving from the output queue to the transmit ring.
|
|
0:20:57
|
So this is typically appropriate for your delay sensitive applications
|
|
0:21:02
|
like the voice phone calls or the video traffic
|
|
0:21:05
|
where we may not have a lot of bandwidth, we just need to
|
|
0:21:08
|
make sure that it goes first out of the interface.
|
|
0:21:12
|
But again, once we get to some sort of level
|
|
0:21:15
|
in the output queue, it is not really going to be a hard
|
|
0:21:18
|
value that if we exceed it's not going to work
|
|
0:21:21
|
but at some point, the QoS logic starts to break down
|
|
0:21:26
|
that if we have too many classes or we're trying to do too much
|
|
0:21:29
|
prioritization, then it's really not going to prefer one
|
|
0:21:34
|
application over another.
|
|
0:21:36
|
So as I mentioned before, this QoS is kind of like a band-aid
|
|
0:21:39
|
on the network.
|
|
0:21:40
|
It might work as a temporary fix, but in the long run
|
|
0:21:44
|
the issue is that you need to get the applications
|
|
0:21:46
|
not to contend for the same resources.
|
|
0:21:49
|
And the way we would do that is either by adding bandwidth or
|
|
0:21:52
|
upgrading the platform so they can forward traffic
|
|
0:21:55
|
faster out the interface
|
|
0:21:59
|
because keep in mind for these devices the bandwidth
|
|
0:22:02
|
value of the physical link a lot of the times is not going to
|
|
0:22:06
|
be the bottleneck of the platform.
|
|
0:22:10
|
So for example if we had a 7206VXR
|
|
0:22:13
|
and it has a gigabit Ethernet interface, it doesn't necessarily
|
|
0:22:17
|
mean that it can forward 1 gigabit per second line rate.
|
|
0:22:20
|
It's going to be dependent on the other software features that are
|
|
0:22:23
|
configured which typically is going to give us a much less
|
|
0:22:27
|
effective rate than 1 gig.
|
|
0:22:31
|
So it's possible that QoS might not even be the problem
|
|
0:22:34
|
it might be the actual platform is not able to forward
|
|
0:22:38
|
as fast as what the physical serialization of the link is.
|
