Well, like with some of our other reviews, we're going to go through
Equiz together and I'm not going to pause the video between the question and
the
solution. And so go ahead and pause the video yourself to make sure that you
understand what is being asked as well as what the answer is. And then hit the
play button to review the question together or at that point if you know
the answer you can probably just skip ahead to the next question as well.
Whatever works best for you but just make sure that as we go through these that
you're taking some good notes because the purpose of the quiz is not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you're taking some good notes because the purpose of the quiz is not
necessarily
to get everything right. If I'm getting everything right then that's great
because it means that I understand things but it's also good to recognize the
things that I don't understand, identify those areas of weakness. And then at
the
bottom of every quiz question here we have the source skill name. So if there's
a
question that trips you up be sure to go back to that skill and review those
concepts to make sure we've got it all down before moving on
beyond quality of service. So we've got eight questions in this quiz video. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
beyond quality of service. So we've got eight questions in this quiz video.
This is the first one and the question is this what are two properties of the
diff-serve QOS model used in modern networks. So this is going all the way
back to the very basics of quality of service and the idea
is that we want to prioritize certain traffic flows as they go across the
network. And we had two different models that we saw being developed. One was
integrated services or into serve and the other is differentiated services
which
is diff-serve. So this diff-serve is being compared to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is diff-serve. So this diff-serve is being compared to
in-serve and in-serve was trying to replicate that
circuit-switched type of network concept from way back in the day where we'd
get
a dedicated circuit which the good news there is that I don't have to
worry about competing packets. The bad news is not very efficient which led
us to packet-switched networks. So int-serve is trying to say hey let's go
back to that concept where we reserve bandwidth for the entire WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
back to that concept where we reserve bandwidth for the entire
length of the path from the very beginning to the very end and if there's
any device in the middle that can't provide that bandwidth reservation
then we cannot move forward with that traffic prioritization and
reservation. And we're going to use the RSVP protocol in order to
enable the int-serve model which also means we're not using RSVP for
diff-serve. Instead what we're doing is we're going to be looking
at interface based bandwidth reservations and they're going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at interface based bandwidth reservations and they're going to be
relying on packet-based marketing and queuing. So BND are going to be our two
answers here. We are again trying to make sure we understand the
difference between int-serve and diff-serve and also understand that
diff-serve relies on the concept of this marking of my packets. I guess I
should have gotten out of the way. There we go. So it's differentiating
from int-serve in that we're going to use marking so I'm going to tag my
packets with DSVP or IP precedence or class of service WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
packets with DSVP or IP precedence or class of service
and based on that marking I'm going to place those packets into queues
and then every interface itself will manage its bandwidth
reservations. I cannot do something end-to-end
with diff-serve. So that's the downside is I'm going to respect the
reservation on this interface but I'm going to send it to a device
and hope that that device is also going to respect the reservation.
But the reservation is based on that device's configuration and this device WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But the reservation is based on that device's configuration and this device
on the left has no power to enforce that on the other device.
So again let's make sure we understand the difference between these two models
moving forward. All right question number two what are the
Cisco recommended thresholds for voice over IP traffic for each of the
following metrics. So we want to make sure that for
voice over IP traffic that we are hitting these metrics and specific
values and thresholds but we want to make sure we also understand what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
values and thresholds but we want to make sure we also understand what
each one of these metrics means and so latency is just going to be the
delay that it takes how long does it take a packet to
get across to the other side and we have a difference between
one-way latency as well as what we call round trip time so keep that in mind.
Is it the amount of time it takes me to get to one side or is it the amount of
time that it takes for the return traffic to get back.
When I'm doing a ping from one device to another usually I'm looking at round
trip time because I know the time that I sent the packet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
trip time because I know the time that I sent the packet
I know how long it took to get a response back.
So when we're talking about latency with voice over IP in this threshold
Cisco says we want a one-way latency of 150 milliseconds
and as we talked about that's kind of interesting because if I do a ping
and I see hey I've got a 250 millisecond round trip time we might say okay good
so I divide that in half and we know that that's 125 milliseconds
per way and therefore it looks like we hit that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
per way and therefore it looks like we hit that.
Except it's not always fair to say we're just going to divide
that in half. This could get broken down so it's 160 milliseconds
one way and 90 milliseconds coming back which means we did
actually break the one-way recommendation from Cisco
in that we exceeded 150 milliseconds so keep that in mind
when we're doing real-world testing but Cisco does recommend a one-way
latency of 150 milliseconds. Jitter is the difference WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
latency of 150 milliseconds. Jitter is the difference
between delay so if I have a latency of 100 milliseconds
and then the next time I check I'm at 150 milliseconds
well we've just increased by 50 milliseconds of delay and so that causes
some well for lack of better words it causes jitter on the network
and so we want to take the average of the differences as we're hopping up and
down and up and down and Cisco wants us to keep jitter below 30 milliseconds.
Yes jitter is measured by milliseconds and we did some math earlier WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Yes jitter is measured by milliseconds and we did some math earlier
in this skill the describe quality of service skill to make sure we understand
how that works but 30 milliseconds is the recommendation there
for packet loss Cisco wants us to keep this below 1% packet loss for voice
over IP traffic. Packet loss is simply how many packets
of the hundred that I sent made it to the other side as long as 99 out of 100
or making it that's great on local area networks that's usually not a
problem when we go to wide area networks and VPNs WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
problem when we go to wide area networks and VPNs
packet loss can become a much bigger concern.
All right question number three how many bits are used for each of these
marking methods we absolutely must understand the
difference between these marking methods. Class of service this exists at layer
two it's going to be part not just part of the ethernet frame but
specifically it's going to be part of that 802.1q or really 802.1p
header because we're going to ride those existing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
header because we're going to ride those existing
bits and bytes because the ethernet header only really had room for source
and destination address as well as the ether type and therefore if we want to
include a VLAN tag well then we need this additional
header those four bytes and that's great in all except that's
where we're going to put our class of service bits as well and specifically
there are three bits in here two to the third power that means we have
eight different values between zero and seven and
importantly if I am sending my traffic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
importantly if I am sending my traffic
tagged via a trunk to the switch and then it
fords that packet out an interface that's in access mode
remember that my cos tag is officially lost in the same way that if a router
were to take this in and send it out a non-
ethernet serial line like a t1 or an e1.
At that point I'm not running ethernet anymore and so I've lost the cos tag
cos is specific to ethernet and specific to trunking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
cos is specific to ethernet and specific to trunking
so it's useful in layer two environments and it gets heavily used it's not a
legacy concept we need to understand how classes
service works what is a legacy concept is
IP precedence because as we draw the line in the sand and say this is layer two
we do say you know we could use some layer three because layer three
specifically ipv4 and ipv6 that lasts end to end
it doesn't matter if i'm going across an access port or a trunk port i keep my WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it doesn't matter if i'm going across an access port or a trunk port i keep my
ip header and i don't need any extra bits and bytes to make it happen like
the ethernet header requires so it's just always there
so ip precedence is what we started with this
is also three bits and therefore ranges from zero to seven
but eventually we decided as we explored that we needed more bits for
that we wanted the ability to have a lot more
what we call per-hop behaviors or phb's and
be ability to define different traffic types and therefore dscp built on ip WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
be ability to define different traffic types and therefore dscp built on ip
precedence we took the ip precedence bits
though that's not useful it there we go of three bits
and then we added three more bits over here
and the total amount or the total of six bits
rather is known as dscp because we have six bits that's two to the sixth power
that means we have from zero to 63 for a total of 64 values WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that means we have from zero to 63 for a total of 64 values
so let's make sure again that we understand the difference in these
different marking types especially when it comes to something like
class of service and when it's used and when it's not
as well as how dscp and ip precedence relate to one another within the ipv4
and ipv6 headers well speaking of per-hop behaviors
here is a question identify the phb that aligns with each of the following
purposes so phb's what's going on here well we just
said that dscp has values from zero to 63 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
said that dscp has values from zero to 63
and that's a whole lot of numbers from a human perspective having 64 different
potential classes of traffic flow is number one a lot of traffic flows
but number two if i have organization a here an organization b over here
uh what am i using for critical traffic on this side and what am i
using for critical traffic on that side voice over ip
non-voice over ip and we could say well these two organizations don't have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
non-voice over ip and we could say well these two organizations don't have
networks between them and so it doesn't matter and that's not a bad argument to
make except that we as it folks tend to
move around from one organization to another we tend to be consultants that
service multiple organizations and generally speaking having standards
that we can all agree on is good for everyone involved
so those standards resulted in us defining some per-hop behaviors we took
some not all but some of these decimal values and we turn them into WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
some not all but some of these decimal values and we turn them into
per-hop behaviors things like class selector so we might have class
selector five or something like that and then we have assured forwarding and
we've got all kinds of assured forwarding values from
you know 11 to 12 to 13 but then we also have 21 and 22 and 23 and then
31 etc etc and then the big one that we talk about often is expedited
forwarding which is going to be reserved for voice over ip WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
forwarding which is going to be reserved for voice over ip
specifically so let's take a look at our options down here so we're going to
go through all of these first of all a per-hop behavior that matches with
ip precedence three well this has to do with the fact
i'll write this down here that ip precedence is those first three bits
and then dscp uses another three bits over here
so if we're going to only use ip precedence bits that means that
means that these must all be set to zero and therefore we're only going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
means that these must all be set to zero and therefore we're only going to be
looking at if we say a three here three from a
binary perspective is zero one zero that's i said that wrong it's zero one one
there you go that's three so if ip precedence is zero one one
we want a per-hop behavior that aligns with this and this is exactly what
class selector is all about class selector is supposed to match
when ip precedence bits are used and when these extra three bits are not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
when ip precedence bits are used and when these extra three bits are not
used as part of our dscp so simply put ip precedence three
here is going to match with class selector three so that would be our
answer is class selector three be here and see are tied together it's the
assured forwarding we're talking about priority versus drop percentage
so when we recall having assured forwarding value of let's say
twenty two this first value is the priority and the second WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
twenty two this first value is the priority and the second
is the drop likelihood we'll call it the drop percentage in this case
so we want a high priority but we actually want a low
drop priority which means that twenty one is actually better
so to speak greater than something like twenty two or twenty four
and the reason for this i don't know why it's a 24 there
uh af 21 is better than 22 which is better than 23 there we go that makes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
uh af 21 is better than 22 which is better than 23 there we go that makes
more sense why is that because 23 has the
highest drop likelihood whereas 21 here that second number is the lowest
drop likelihood yet if i have an af 31 this number here the higher the
better so it's kind of weird the higher the better in the first one
the lower the better in the second one so when you say the highest af priority
the highest priority is going to be four we only have a range of one to four WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the highest priority is going to be four we only have a range of one to four
for assured forwarding so the lowest in c here the
lowest priority would be have a one there but we need two numbers and that's
the the drop priority so the drop percentage so b here the lowest drop
percentage would be a one so af 41 for b and then the highest drop
percentage that ranges from one to three so that would be af 13
and then lastly matches with voice over ip traffic that is always going to be
our
expedited forwarding value so understand how these phb's tied WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
expedited forwarding value so understand how these phb's tied
together and when we use each one all right question number five we're
halfway done what are the decimal values that align to the
following per hot behaviors so this is a whole conversation of making
sure we can take these per hot behaviors these
mix of letters and numbers and turn them into decimal values
so with cs5 remember we're only using those first three bits and therefore
is this a pretty straightforward class selector WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is this a pretty straightforward class selector
is just an 8x multiplier and that has to do with the way the bits are aligned
and we covered that but in the end when we have a question like this our focus
is do we know the math as long as we know the math we can
make this happen pretty simply because class selector five i just multiply it
by eight and that is a decimal value of 40 pretty
straightforward af 13 and 42 these are going to require a
new equation which is that 8x plus 2y where x is the priority and y is the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
new equation which is that 8x plus 2y where x is the priority and y is the
drop so in other words if i have af 13 here it
would be eight times one that'd be the first number
plus two times three that'd be the second number
and the reason why this equation works once again same as class selector has
to do with where the bits are aligned within the header and we talked about
that early on so this is eight this is six so this would be a value of 14 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that early on so this is eight this is six so this would be a value of 14
don't allow ourselves to get mixed up with the fact that yeah 13 is 14
or anything like that that's just coincidence sometimes they end up
being the same number sometimes they're off
just a little bit but this is just a you know almost like a name that we're
giving it and this is the actual decimal value
based on the binary bits so same equation here we're going to do
eight this time times four and then this is two so two times two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
eight this time times four and then this is two so two times two
and so that's 32 and this is four 32 plus four is 36
lastly expedited forwarding doesn't give us any numbers or equations which is
kind of nice but it does require us to memorize it
and simply put expedited forwarding is a decimal value of 46
so always keep in mind how exactly to do this remember
these two equations can be very instrumental in performing these
decimal conversions all right next question how are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
decimal conversions all right next question how are
packets classified when using weighted fair queuing
choose two so weighted fair queuing was an early adopt or early
queuing method that sesco came up with and it's something we still can use
today in modern networks especially within
cb wfqq's so let's not get this mixed up sisco has class based
weighted fair queuing and this is what we use that mqc
iosac configuration for we configure all of our cues we can configure WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
iosac configuration for we configure all of our cues we can configure
a low latency queue all of this is how we do the class
class maps and policy maps etc but when we talk about weighted fair queuing
weighted fair queuing is a much more automated
method for performing queuing and servicing of packets
it's automated based on two parameters first of all
it's going to be looking at the packet size
that's important because we're going to have the ability to put
small packets into more higher priority queues WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
small packets into more higher priority queues
and the primary reason for this is because voiceover ip
is very small packet sizes the other thing we're going to take a look at
is the traffic flow and truly what happens here is we sort of have this
dividing line in the sand where you have small and large packets
and then the sesco device is just going to observe a traffic flow and place
each flow into its own queue within one of these
areas or regions if you want to call it that so the small packets are going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
areas or regions if you want to call it that so the small packets are going to
be
serviced at a greater rate than the large packets but again the beautiful
thing about this is i as the administrator
it can just rely on the automated nature of identifying things
by traffic flow as well as packet size
all right interesting question here uh we've got an llq that low latency queue
it's been configured on an interface and 10% of the link bandwidth is reserved
that's an important part of all of this an llq packet is arrives is probably a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's an important part of all of this an llq packet is arrives is probably a
voiceover ip packet and the link is congested
in what situation will the packet be sent over packets in the other
queues so our temptation here might be to say oh
the low latency queue this is a strict priority packet and therefore it'll
always get sent out but here's the question is it
a strict priority queue strict priority says i don't care
about any kind of limits i'm just going to send a packet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
about any kind of limits i'm just going to send a packet
that any packet that lands in the strict priority queue i'm going to send it
ahead of other queues which risks starving those other queues
well llq is designed to get around this and as a result
we can deploy this with strict priority however if we add
a reservation to a low latency queue that reservation
actually becomes a restriction and as a result in our case
it's not a strict priority queue so in what situation will the packet be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's not a strict priority queue so in what situation will the packet be
sent over packets in the other queues it's going to be
c it depends on the bandwidth consumption because if we've hit our 10% of link
bandwidth then we're not going to send that packet ahead of the other ones
even though it's in the llq but if it has not consumed 10% then it will be sent
out immediately ahead of the other queues so
little in cq attempts to find a balance between the concept of the strict
priority queue but also not just treat voice over IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
priority queue but also not just treat voice over IP
packets as any other packet all right last question here what does
weighted random early detect consider that random early detect does not
so yeah we probably call this w red or red i know w's are sometimes silent in
front of an r so we can't just call it red and red but
either way the answer here is going to be the packet tag
weighted random early detect is weighted meaning that i can look at the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
weighted random early detect is weighted meaning that i can look at the
the tag of a packet and random early detect doesn't actually
do that uh both are very useful they both aim to
accomplish something similar but weighted random early detect just has that
better capability as far as being able to prioritize certain packets over
others within the same queue