WEBVTT

0:00:03.680000 --> 0:00:07.660000
 Hello and welcome to this video, which
 is a review of some of the QS concepts

0:00:07.660000 --> 0:00:08.760000
 we've talked about.

0:00:08.760000 --> 0:00:12.980000
 In this video, we're going to focus
 in on IP precedence and DSCP.

0:00:12.980000 --> 0:00:18.580000
 Some very critical topics as far as quality
 of service is concerned with.

0:00:18.580000 --> 0:00:25.960000
 All right. So here we have
 the type of service byte.

0:00:25.960000 --> 0:00:31.640000
 Remember, every IPv4 packet has a field,
 a one byte field, eight bits,

0:00:31.640000 --> 0:00:34.180000
 which is called type of service.

0:00:34.180000 --> 0:00:38.780000
 In IPv6, that same one
 byte field exists.

0:00:38.780000 --> 0:00:40.080000
 We just call it a different name.

0:00:40.080000 --> 0:00:41.820000
 We call it traffic class.

0:00:41.820000 --> 0:00:45.440000
 So this slide and the next two or three
 slides, even though they might

0:00:45.440000 --> 0:00:50.300000
 say toss, just think that toss and traffic
 class are synonymous with each

0:00:50.300000 --> 0:00:52.660000
 other. They're both mean, the
 basically the same thing.

0:00:52.660000 --> 0:00:58.360000
 All right. Now, when IPv4 was first
 invented back in ROC 791 back in the

0:00:58.360000 --> 0:01:03.880000
 early 1980s, and when they thought up
 this original byte, they said, okay,

0:01:03.880000 --> 0:01:07.160000
 here's the meanings we're going to come
 up with for each one of the bits

0:01:07.160000 --> 0:01:15.960000
 in that byte. They said that the first
 three bits, bits 0, 1 and 2 are

0:01:15.960000 --> 0:01:17.500000
 going to be the precedence bits.

0:01:17.500000 --> 0:01:20.700000
 This is where you're going to mark
 the relative priority of a packet.

0:01:20.700000 --> 0:01:22.780000
 And you can see here, they
 even came up with names.

0:01:22.780000 --> 0:01:26.740000
 They said, okay, if a packet has the
 default priority of 0, 0, 0, we just

0:01:26.740000 --> 0:01:30.420000
 call that routine all the way up to
 the absolute highest prior, right?

0:01:30.420000 --> 0:01:34.840000
 The higher the number, the higher the
 priority, the packet, that is network

0:01:34.840000 --> 0:01:40.400000
 control. So matter of fact, what's kind
 of interesting is that the vast

0:01:40.400000 --> 0:01:44.980000
 majority of routing protocol packets
 out there, like EIRP, Hello's, OSPF,

0:01:44.980000 --> 0:01:49.500000
 link state updates, BGP packets by default,
 when routing protocols create

0:01:49.500000 --> 0:01:53.980000
 packets, most of the time they set
 the IP precedence to six, one, one,

0:01:53.980000 --> 0:01:59.080000
 zero. I honestly have no idea what protocols,
 if any, use network control,

0:01:59.080000 --> 0:02:00.840000
 the absolute highest value.

0:02:00.840000 --> 0:02:06.260000
 But some exams will require, you know,
 probably more at the, uh, the CCIE

0:02:06.260000 --> 0:02:10.860000
 level will require you to know the
 names of each one of these things.

0:02:10.860000 --> 0:02:15.060000
 Pretty sure at the CCNA level, you
 don't have to know those names, but

0:02:15.060000 --> 0:02:20.160000
 you should know that for IP precedence,
 the lowest value is zero, the

0:02:20.160000 --> 0:02:22.520000
 highest value is seven.

0:02:22.520000 --> 0:02:26.560000
 The other thing you probably want to
 know for the CCNA on up is that voice

0:02:26.560000 --> 0:02:30.200000
 over IP traffic, when, when you're
 talking on your voice over IP phone

0:02:30.200000 --> 0:02:34.380000
 and it's converting your voice traffic
 into IP packets, voice over IP

0:02:34.380000 --> 0:02:38.780000
 by default, uses a
 priority of five.

0:02:38.780000 --> 0:02:42.480000
 All right. So that's the default, uh,
 IP presence, you'll see popping

0:02:42.480000 --> 0:02:44.660000
 out of your voice over IP phone.

0:02:44.660000 --> 0:02:47.360000
 Now, what about these
 other bits here?

0:02:47.360000 --> 0:02:50.900000
 Well, this bit here was
 called the delay bit.

0:02:50.900000 --> 0:02:55.240000
 So if it was a zero that was instructing
 the network, hey, you can forward

0:02:55.240000 --> 0:02:58.160000
 this packet using whatever
 path has normal delay.

0:02:58.160000 --> 0:03:02.800000
 If that bit was a one, that was like
 the pack was saying, Hey, if you

0:03:02.800000 --> 0:03:06.200000
 have a choice of multiple paths to
 route me on, please route me along

0:03:06.200000 --> 0:03:08.080000
 the path that has
 the lowest delay.

0:03:08.080000 --> 0:03:10.600000
 And then we had the
 throughput bit.

0:03:10.600000 --> 0:03:14.140000
 If that was set to one, that was like
 saying, Hey, route me along the

0:03:14.140000 --> 0:03:15.900000
 path that has the highest
 throughput.

0:03:15.900000 --> 0:03:19.680000
 And then we had the reliability bit,
 route me along the path that has

0:03:19.680000 --> 0:03:21.680000
 the highest reliability.

0:03:21.680000 --> 0:03:25.060000
 Now these three, and then these two bits
 here were just reserved for future

0:03:25.060000 --> 0:03:26.900000
 use, not used for anything.

0:03:26.900000 --> 0:03:30.120000
 So these three bits, although they're
 kind of interesting conceptually

0:03:30.120000 --> 0:03:35.980000
 virtually no networking devices from
 any vendors ever actually use those

0:03:35.980000 --> 0:03:39.740000
 bits. As a matter of fact, even if you
 could somehow get your laptop PC

0:03:39.740000 --> 0:03:44.880000
 server to set those bits, you'd be
 wasting your time because virtually

0:03:44.880000 --> 0:03:47.980000
 every route, I don't even really know
 if any routers or switches out there

0:03:47.980000 --> 0:03:50.420000
 that even paid attention
 or look at those bits.

0:03:50.420000 --> 0:03:53.500000
 So whether they're set to ones or zeros
 is kind of irrelevant because

0:03:53.500000 --> 0:03:55.680000
 most networking devices don't
 even pay attention to it.

0:03:55.680000 --> 0:04:00.900000
 So for decades and decades of this entire
 byte, the only bits that were

0:04:00.900000 --> 0:04:04.680000
 really paid attention to by your networking
 devices were the IP precedence

0:04:04.680000 --> 0:04:06.780000
 bits, just those three.

0:04:06.780000 --> 0:04:11.560000
 And you can see here that meant that
 as you were designing QS and you

0:04:11.560000 --> 0:04:15.500000
 were thinking about, okay, I want to
 be able to classify different flows

0:04:15.500000 --> 0:04:19.340000
 of traffic. So what types of flows of
 traffic are going to typically go

0:04:19.340000 --> 0:04:20.120000
 through my network?

0:04:20.120000 --> 0:04:23.280000
 Well, I know voice over IP, so that'll
 be one type of flow and how about

0:04:23.280000 --> 0:04:25.720000
 a multicast video,
 that'll be another.

0:04:25.720000 --> 0:04:29.140000
 Well, as you were doing this, the greatest
 quantity of flows you could

0:04:29.140000 --> 0:04:31.080000
 have would be eight, right?

0:04:31.080000 --> 0:04:32.480000
 Zero through seven.

0:04:32.480000 --> 0:04:36.180000
 That was it. You could only have eight
 quantity of flows because only

0:04:36.180000 --> 0:04:38.280000
 three bits were available to you.

0:04:38.280000 --> 0:04:42.760000
 Then several decades ago, some
 people said, you know what?

0:04:42.760000 --> 0:04:47.400000
 Why don't we just stop looking at bits
 three, four and five as delay through

0:04:47.400000 --> 0:04:50.560000
 putting reliability because nobody's
 looking at those bits anyway.

0:04:50.560000 --> 0:04:54.040000
 And why don't we just add those
 bits to the priority?

0:04:54.040000 --> 0:04:58.460000
 So instead of having three bits that we
 can toggle to specify the priority,

0:04:58.460000 --> 0:05:01.720000
 we'll give ourselves six bits we can
 toggle, which will be a lot more

0:05:01.720000 --> 0:05:04.820000
 classes of traffic
 we can identify.

0:05:04.820000 --> 0:05:07.900000
 And so that's where they said,
 all right, we're now going to.

0:05:07.900000 --> 0:05:12.260000
 So when you go into a router switch
 and you say, hey, if you identify

0:05:12.260000 --> 0:05:17.240000
 this traffic as being voice over IP
 or if you identify this traffic is

0:05:17.240000 --> 0:05:21.260000
 being telnet, I want you to set
 the and now you have a choice.

0:05:21.260000 --> 0:05:24.340000
 You could say, I want you to set the
 IP precedence bits, which means you

0:05:24.340000 --> 0:05:27.680000
 only have eight numbers you can play
 with, or you could say, I want you

0:05:27.680000 --> 0:05:32.960000
 to set the DSCP bits, which are the
 first six bits in the toss by which

0:05:32.960000 --> 0:05:37.660000
 gives you now a lot
 more variation.

0:05:37.660000 --> 0:05:42.240000
 Okay, so with DSCP, we do have some
 terminology we have to know here,

0:05:42.240000 --> 0:05:46.340000
 especially if you're reading QS books
 or documents or something like that.

0:05:46.340000 --> 0:05:52.660000
 So the first three bits, which we go
 back here, the first three bits,

0:05:52.660000 --> 0:05:56.700000
 which we used to call the IP precedence
 bits are now called the class

0:05:56.700000 --> 0:05:59.280000
 selector bit CS.

0:05:59.280000 --> 0:06:03.620000
 And that's supposed to be backwards
 compatible with IP precedence.

0:06:03.620000 --> 0:06:04.620000
 So what do I mean by that?

0:06:04.620000 --> 0:06:10.240000
 I mean that if I go into a router switch
 and I say, hey, when you identify

0:06:10.240000 --> 0:06:14.460000
 this traffic via an access list or something
 else as voice traffic, voice

0:06:14.460000 --> 0:06:19.080000
 over IP, and I want you to set the
 DSCP bits, if I say, hey, the DSCP

0:06:19.080000 --> 0:06:24.400000
 setting I want you
 to use is CS five.

0:06:24.400000 --> 0:06:25.660000
 That's what I select.

0:06:25.660000 --> 0:06:30.620000
 If that's my option, well, CS five
 is the same thing as IP precedence

0:06:30.620000 --> 0:06:38.080000
 five. It's still just
 one zero one, right?

0:06:38.080000 --> 0:06:40.820000
 The one bits turned on and
 the four bit has turned on.

0:06:40.820000 --> 0:06:44.820000
 So class selector five would give you
 the exact same thing as IP precedence

0:06:44.820000 --> 0:06:48.040000
 five, which might be good for backwards
 compatibility, right?

0:06:48.040000 --> 0:06:52.020000
 You might have some much older routers
 or switches further up the line

0:06:52.020000 --> 0:06:55.800000
 that don't have the
 ability to do DSCP.

0:06:55.800000 --> 0:06:59.640000
 Their code is so old that the only QS
 command you can configure on those

0:06:59.640000 --> 0:07:01.540000
 is IP precedence.

0:07:01.540000 --> 0:07:04.760000
 So in that case, you might just want
 to use class selector bits so that

0:07:04.760000 --> 0:07:08.840000
 those those bits are interpreted
 correctly end to end.

0:07:08.840000 --> 0:07:13.380000
 Okay, but if you want to use the full
 range of DSCP, you've got all six

0:07:13.380000 --> 0:07:14.640000
 bits available to you.

0:07:14.640000 --> 0:07:16.980000
 Now, so we got the class
 selector bits.

0:07:16.980000 --> 0:07:22.560000
 These next two bits are called the assured
 forwarding bits, the assured

0:07:22.560000 --> 0:07:24.380000
 forwarding bits.

0:07:24.380000 --> 0:07:27.820000
 And this is what's kind
 of interesting here.

0:07:27.820000 --> 0:07:33.260000
 This is sort of backwards because, you
 know, in the world of IP precedence,

0:07:33.260000 --> 0:07:37.720000
 what you learn is that the higher the
 number like zero, like two is higher

0:07:37.720000 --> 0:07:40.740000
 than one, one is higher than zero, you
 learn the higher the number, the

0:07:40.740000 --> 0:07:42.780000
 higher the priority of the packet.


0:07:42.780000 --> 0:07:47.980000
 And so logically thinking, if I receive,
 if I'm a router and I receive

0:07:47.980000 --> 0:07:51.000000
 in a whole bunch of packets, I need
 to go out this interface right here.

0:07:51.000000 --> 0:07:52.680000
 And this interface is congested.

0:07:52.680000 --> 0:07:54.400000
 I need to start dropping
 some stuff.

0:07:54.400000 --> 0:07:58.400000
 Well, some of those packets come in
 and they have an IP precedence of

0:07:58.400000 --> 0:08:02.380000
 two. And another set of packets come
 in and they have an IP precedence

0:08:02.380000 --> 0:08:05.460000
 of five. I should drop the twos.

0:08:05.460000 --> 0:08:06.800000
 Two is lower priority.

0:08:06.800000 --> 0:08:10.040000
 I should drop those and I should
 try to get those fives out.

0:08:10.040000 --> 0:08:16.740000
 Well, in the world of DSCP, these
 values are just the opposite.

0:08:16.740000 --> 0:08:21.020000
 So for example, if I have a DSCP value
 where let's just look at binary,

0:08:21.020000 --> 0:08:24.960000
 let's say the class
 selector is 010.

0:08:24.960000 --> 0:08:26.160000
 I get two packets.

0:08:26.160000 --> 0:08:28.560000
 All right. There are two packets that
 have to go out this interface that's

0:08:28.560000 --> 0:08:33.180000
 congested. One of those packets starts
 out with 010 as the class selector.

0:08:33.180000 --> 0:08:38.160000
 The other one also starts out with 010,
 but they have different AF values.

0:08:38.160000 --> 0:08:42.140000
 Let's say that the one on the bottom
 has an AF value of that.

0:08:42.140000 --> 0:08:47.420000
 So 01001, the next one has
 an AF value of that.

0:08:47.420000 --> 0:08:51.840000
 If you were thinking in terms of the
 older way of IP precedence, one would

0:08:51.840000 --> 0:08:54.940000
 think that, oh, okay, well,
 this one has a lower value.

0:08:54.940000 --> 0:08:59.160000
 I should probably drop that
 before I drop the other one.

0:08:59.160000 --> 0:09:00.960000
 You would be wrong.

0:09:00.960000 --> 0:09:07.460000
 So with the AF values, the higher the
 AF, the higher the drop probability.

0:09:07.460000 --> 0:09:13.060000
 So the drop probability of this top one
 is greater than the drop probability

0:09:13.060000 --> 0:09:17.000000
 of the bottom one.

0:09:17.000000 --> 0:09:21.600000
 So kind of backwards thinking there,
 but that's how DSCP was designed

0:09:21.600000 --> 0:09:23.480000
 to be operated. All right.

0:09:23.480000 --> 0:09:26.380000
 So let's keep going here with
 this concept of DSCP.

0:09:26.380000 --> 0:09:33.560000
 So DSCP has this concept of
 per hop behavior classes.

0:09:33.560000 --> 0:09:34.600000
 What does that mean?

0:09:34.600000 --> 0:09:40.400000
 All that really means is that, you
 know, from a QS perspective, if I'm

0:09:40.400000 --> 0:09:44.540000
 on a router, right, this router is considered
 a hop in the network, right?

0:09:44.540000 --> 0:09:48.280000
 So if I'm on this router, I can
 configure QS however I want.

0:09:48.280000 --> 0:09:50.900000
 I could have a treat voice
 over IP one way.

0:09:50.900000 --> 0:09:52.700000
 I could have a treat
 data another way.

0:09:52.700000 --> 0:09:56.840000
 Okay. I could configure my per hop
 behavior on this hop right here.

0:09:56.840000 --> 0:10:01.480000
 But if I jump onto another router, is
 router number one, you'll say, hey,

0:10:01.480000 --> 0:10:04.460000
 router number two, this
 is how you should do QS.

0:10:04.460000 --> 0:10:07.540000
 I've been configured that voices,
 you know, should go fast.

0:10:07.540000 --> 0:10:08.560000
 So you should too.

0:10:08.560000 --> 0:10:11.240000
 I've been configured that data should
 be dropped if we have congestion.

0:10:11.240000 --> 0:10:12.220000
 So you should too.

0:10:12.220000 --> 0:10:13.540000
 It doesn't do that.

0:10:13.540000 --> 0:10:17.080000
 QS is configured on
 a hop by hop basis.

0:10:17.080000 --> 0:10:22.720000
 So the per hop behavior of router number
 two may or may not be the same

0:10:22.720000 --> 0:10:26.280000
 as the per hop behavior
 of router number one.

0:10:26.280000 --> 0:10:28.680000
 It's all up to you as a network administrator,
 but they don't talk to

0:10:28.680000 --> 0:10:31.420000
 each other. They don't share
 QS policies dynamically.

0:10:31.420000 --> 0:10:32.860000
 They don't do that.

0:10:32.860000 --> 0:10:39.060000
 So with DSCP, when we say that we have
 per hop behavior classes, that's

0:10:39.060000 --> 0:10:42.440000
 just a fancy way of saying, hey, now
 that you've identified your class

0:10:42.440000 --> 0:10:46.900000
 of traffic, you know, this class's voice,
 this class is data, whatever.

0:10:46.900000 --> 0:10:49.720000
 What do you want your per
 hop behavior to be?

0:10:49.720000 --> 0:10:53.680000
 How do you want this hop
 to behave on that class?

0:10:53.680000 --> 0:10:57.240000
 How do you want this next hop
 to behave on this class?

0:10:57.240000 --> 0:10:58.420000
 It might be the same.

0:10:58.420000 --> 0:11:01.080000
 It might be different depending
 on what your needs are.

0:11:01.080000 --> 0:11:09.860000
 Okay. So when you look at the specification
 for DSCP, this next stuff

0:11:09.860000 --> 0:11:14.100000
 here are all suggested
 guidelines, right?

0:11:14.100000 --> 0:11:16.140000
 Just like IP precedence, right?

0:11:16.140000 --> 0:11:21.600000
 It's suggested that if I'm a router
 and I have a congested interface and

0:11:21.600000 --> 0:11:24.680000
 I get some packets in there, I have
 an IP precedence of two and others

0:11:24.680000 --> 0:11:28.120000
 that have an IP precedence of five,
 it's suggested that I should drop

0:11:28.120000 --> 0:11:30.720000
 the twos so I can let
 the fives go through.

0:11:30.720000 --> 0:11:35.240000
 But ultimately, when you configure QOS,
 you can configure it to do whatever

0:11:35.240000 --> 0:11:39.600000
 you want. I could say, oh, the twos are
 going to go through and the fives

0:11:39.600000 --> 0:11:40.700000
 are going to be dropped.

0:11:40.700000 --> 0:11:43.200000
 Nothing's forcing me to do
 it one way or the other.

0:11:43.200000 --> 0:11:44.860000
 It's just a guideline.

0:11:44.860000 --> 0:11:46.580000
 So the same thing is true here.

0:11:46.580000 --> 0:11:50.220000
 With DSCP, if you read a lot of the white
 papers and documents, they will

0:11:50.220000 --> 0:11:55.740000
 say, hey, there are four traffic
 classes designed for DSCP.

0:11:55.740000 --> 0:11:58.400000
 Here's the traffic classes.

0:11:58.400000 --> 0:12:00.880000
 They say the default forwarding.

0:12:00.880000 --> 0:12:06.300000
 So default behavior of just default traffic
 should be assigned this value.

0:12:06.300000 --> 0:12:08.060000
 You don't have to, right?

0:12:08.060000 --> 0:12:10.700000
 You could just take your normal web browsing
 traffic and assign it whatever

0:12:10.700000 --> 0:12:12.700000
 DSCP value you want.

0:12:12.700000 --> 0:12:18.280000
 But they say the default forwarding
 behavior of DSCP zero is the default

0:12:18.280000 --> 0:12:22.840000
 packets. Then they say, okay,
 expedited forwarding.

0:12:22.840000 --> 0:12:25.580000
 This is what you should apply
 to your voice traffic.

0:12:25.580000 --> 0:12:28.600000
 And in reality, this is pretty
 much what everybody does.

0:12:28.600000 --> 0:12:32.700000
 Even IP phones, a lot of times by default,
 they will go into the toss

0:12:32.700000 --> 0:12:38.660000
 byte or the traffic class byte and
 they will set the six DSCP bits to

0:12:38.660000 --> 0:12:43.720000
 match what we call expedited forwarding,
 which is this value right here.

0:12:43.720000 --> 0:12:47.780000
 Now let me pause for
 just a second.

0:12:47.780000 --> 0:12:52.200000
 You might be saying, well, Keith, where
 the heck did you come up with

0:12:52.200000 --> 0:12:54.240000
 the value of 46?

0:12:54.240000 --> 0:12:56.840000
 Where does that number come from?

0:12:56.840000 --> 0:13:02.900000
 All right. So normally when we look
 at a byte, one, two, three, four,

0:13:02.900000 --> 0:13:06.940000
 five, six, seven, eight, normally when
 we're trying to convert that from

0:13:06.940000 --> 0:13:09.740000
 binary to decimal, we start
 right here, don't we?

0:13:09.740000 --> 0:13:12.320000
 We say, oh, that's the
 value of zero or one.

0:13:12.320000 --> 0:13:16.980000
 That's the value of zero or two, four,
 eight, 16, and so on and so forth.

0:13:16.980000 --> 0:13:22.820000
 But in the world of DSCP, one, two, three,
 four, five, six, seven, eight,

0:13:22.820000 --> 0:13:27.960000
 when we look at our toss byte or our
 traffic class byte, these two bits

0:13:27.960000 --> 0:13:32.640000
 are not used. In the world of DSCP,
 it's just the first six bits.

0:13:32.640000 --> 0:13:34.940000
 Now these two bits do have
 a different meaning.

0:13:34.940000 --> 0:13:38.200000
 They're used for something else, but
 they're not used to indicate the

0:13:38.200000 --> 0:13:39.880000
 relative priority of a packet.

0:13:39.880000 --> 0:13:42.040000
 That's just the first six bits.

0:13:42.040000 --> 0:13:45.640000
 So if we're setting a DSCP value.

0:13:45.640000 --> 0:13:50.700000
 If I want to set a DSCP value of one,
 it would not be setting that bit

0:13:50.700000 --> 0:13:53.440000
 because that's not part
 of my DSCP bits.

0:13:53.440000 --> 0:13:58.320000
 If I want to set a DSCP value of one,
 I would be setting that bit right

0:13:58.320000 --> 0:14:01.820000
 there. That is my first DSCP bit.

0:14:01.820000 --> 0:14:05.640000
 So if you think of it as starting from
 this bit right here, that's my

0:14:05.640000 --> 0:14:11.160000
 one bit. That's two, that's four, that's
 16, that's 32, and that's 64.

0:14:11.160000 --> 0:14:17.760000
 Now it starts to make sense, where
 if I have one, zero, one, one, one,

0:14:17.760000 --> 0:14:19.380000
 zero, all right.

0:14:19.380000 --> 0:14:24.400000
 Now if we start counting it from that
 aspect, one, two, 16, one, two,

0:14:24.400000 --> 0:14:28.760000
 four, oh, I missed something, I missed
 eight, I thought, wait a second,

0:14:28.760000 --> 0:14:30.900000
 that can't be 64 on the back end.

0:14:30.900000 --> 0:14:32.600000
 There's got to be something else.

0:14:32.600000 --> 0:14:36.820000
 So one, two, four, eight, 16, 32.

0:14:36.820000 --> 0:14:41.140000
 All right. So now if we say, all right,
 I've turned on my 32 bit, I've

0:14:41.140000 --> 0:14:46.340000
 turned on my eight bit, which is 40
 between those two, and I've turned

0:14:46.340000 --> 0:14:49.000000
 on my four and two
 bit, which is six.

0:14:49.000000 --> 0:14:52.820000
 That's how we get DSCP 46.

0:14:52.820000 --> 0:14:54.960000
 That's where that number
 comes up with.

0:14:54.960000 --> 0:15:03.700000
 Now, so that's two out of
 the four traffic classes.

0:15:03.700000 --> 0:15:07.060000
 Default forwarding, expedited
 forwarding.

0:15:07.060000 --> 0:15:16.140000
 Now if we continue on here, then there
 is assured forwarding, which is

0:15:16.140000 --> 0:15:19.320000
 AF 11 through AF 43.

0:15:19.320000 --> 0:15:24.260000
 All right. So this also gets a little
 bit weird in how you count it.

0:15:24.260000 --> 0:15:31.260000
 All right. So when you are
 using this, all right.

0:15:31.260000 --> 0:15:35.700000
 So let's say I was in a router, let's
 just say a router, and I was using

0:15:35.700000 --> 0:15:39.820000
 an access list or something
 else to classify my traffic.

0:15:39.820000 --> 0:15:43.460000
 And the access list said, hey, here's
 a packet that matches voice.

0:15:43.460000 --> 0:15:44.600000
 This is what you want to look for.


0:15:44.600000 --> 0:15:46.080000
 This matches voice.

0:15:46.080000 --> 0:15:51.020000
 Okay. And then if I said, okay, well,
 all voice packets, I configure a

0:15:51.020000 --> 0:15:56.180000
 QS command. And I want to mark those
 voice packets with an AF number,

0:15:56.180000 --> 0:16:00.140000
 not EF and not default,
 an AF number.

0:16:00.140000 --> 0:16:03.580000
 Here's how the AF number
 markings work.

0:16:03.580000 --> 0:16:09.420000
 So once again, if we think about our
 first six bits and the last two bits,

0:16:09.420000 --> 0:16:12.320000
 we don't care. Those
 don't belong to DSCP.

0:16:12.320000 --> 0:16:20.520000
 When you are doing an AF value, this
 bit right here is always zeroed out.

0:16:20.520000 --> 0:16:24.820000
 So that bit you can't set,
 it's always a zero.

0:16:24.820000 --> 0:16:30.380000
 When you're using AF,
 it's always a zero.

0:16:30.380000 --> 0:16:33.140000
 So then the way you
 look at it is this.

0:16:33.140000 --> 0:16:39.000000
 The first number after the F, whether
 it be a one or whether it be a four,

0:16:39.000000 --> 0:16:45.280000
 that's what you put in your class selector
 bits, right, which are those

0:16:45.280000 --> 0:16:47.180000
 first three bits right there.

0:16:47.180000 --> 0:16:52.020000
 So if I have an AF one,
 it's zero, zero, one.

0:16:52.020000 --> 0:16:55.560000
 If I had an AF four, it'd
 be one, zero, zero.

0:16:55.560000 --> 0:16:57.060000
 That'd be AF four.

0:16:57.060000 --> 0:17:02.020000
 And then the second number after that
 is what you put in the remaining

0:17:02.020000 --> 0:17:09.180000
 two bits. So like for example, if I
 had AF one, three, and notice with

0:17:09.180000 --> 0:17:18.480000
 these two bits right here, I
 only have three combinations.

0:17:18.480000 --> 0:17:24.840000
 It can either be a zero, one,
 a one, zero, or a one, one.

0:17:24.840000 --> 0:17:29.840000
 You might be thinking about Keith,
 there's also zero, zero, right?

0:17:29.840000 --> 0:17:35.060000
 No, because if you mark, if these bits
 are zero, zero, they're no longer

0:17:35.060000 --> 0:17:38.560000
 considered to be in the assured
 forwarding class.

0:17:38.560000 --> 0:17:42.820000
 Now you're using the class selector,
 which is just basically just using

0:17:42.820000 --> 0:17:44.880000
 those first three bits,
 and that's it.

0:17:44.880000 --> 0:17:49.100000
 So let's go back to AF
 for just a moment.

0:17:49.100000 --> 0:17:54.100000
 Okay, so if I said, hey, I'm going to
 mark my traffic as AF, let's say,

0:17:54.100000 --> 0:17:59.380000
 two, two. This is how
 that works out.

0:17:59.380000 --> 0:18:05.120000
 All right, there's my
 six bits of my DSCP.

0:18:05.120000 --> 0:18:08.400000
 With AF, we know this
 has got to be a zero.

0:18:08.400000 --> 0:18:12.220000
 Okay, two, that's going to be in
 this first section right here.

0:18:12.220000 --> 0:18:14.500000
 So that'll be zero, one, zero.

0:18:14.500000 --> 0:18:18.600000
 There's two. Second two, that's going
 to be this one right here, which

0:18:18.600000 --> 0:18:20.180000
 is going to be one, zero.

0:18:20.180000 --> 0:18:24.960000
 So that's going to be the binary pattern
 that's going to result from AF

0:18:24.960000 --> 0:18:30.640000
 22. Now you should also be able to convert
 back and forth between AF values

0:18:30.640000 --> 0:18:32.840000
 and DSCP values.

0:18:32.840000 --> 0:18:42.060000
 If I was to say, DSCP something equals
 AF 22, what would that be?

0:18:42.060000 --> 0:18:45.320000
 Well, remember, if we're looking at
 DSCP values, now we're looking at

0:18:45.320000 --> 0:18:50.680000
 all six bits. So if we're looking at
 all six bits, we have the one bit,

0:18:50.680000 --> 0:18:55.240000
 two bit, four bit,
 eight, 16, and 32.

0:18:55.240000 --> 0:19:00.340000
 So now we have the 16 turned
 on and the four, that is 20.

0:19:00.340000 --> 0:19:08.600000
 So a DSCP of 20 will come up with
 the exact same markings as AF 22.

0:19:08.600000 --> 0:19:11.980000
 And actually, when you're in a router
 switching out the CCNA level, they

0:19:11.980000 --> 0:19:15.320000
 don't expect you to know
 how to configure QoS.

0:19:15.320000 --> 0:19:16.980000
 It's purely theoretical.

0:19:16.980000 --> 0:19:19.480000
 You just have to know the terminology
 and the concepts.

0:19:19.480000 --> 0:19:22.860000
 But if you were to try to play around
 with this and you went into some

0:19:22.860000 --> 0:19:25.820000
 router switching and said, hey, I
 want to, I want to mark something.

0:19:25.820000 --> 0:19:26.960000
 You did a question mark.

0:19:26.960000 --> 0:19:30.780000
 You would see your option is DSCP.


0:19:30.780000 --> 0:19:34.100000
 And if you chose DSCP, you'd have the
 full range of numbers here available

0:19:34.100000 --> 0:19:37.240000
 to you from zero to 63, right?

0:19:37.240000 --> 0:19:40.500000
 Because if I have all six of those
 bits set to ones, that equals 63.

0:19:40.500000 --> 0:19:46.560000
 So I could have DSCP 17, DSCP 62,
 DSCP 21, anything in that range.

0:19:46.560000 --> 0:19:49.460000
 Or I could choose one
 of these things.

0:19:49.460000 --> 0:19:51.500000
 I could choose default forwarding.


0:19:51.500000 --> 0:19:53.420000
 I could use expedited forwarding.

0:19:53.420000 --> 0:19:55.880000
 I could choose AF 22.

0:19:55.880000 --> 0:20:00.920000
 So if I typed in AF 22, that's exactly
 the same as if I had typed in DSCP

0:20:00.920000 --> 0:20:08.980000
 20. And then lastly, we have CS.

0:20:08.980000 --> 0:20:13.980000
 So if I go into my system and I say,
 hey, if you see a packet that matches

0:20:13.980000 --> 0:20:18.080000
 this criteria, mark it as CS4.

0:20:18.080000 --> 0:20:21.560000
 That's exactly the same thing
 as IP precedence of four.

0:20:21.560000 --> 0:20:26.940000
 All that's doing is taking the IP precedence
 bits of 1, 0, 0, 4, and then

0:20:26.940000 --> 0:20:29.140000
 zeroing out everything else.

0:20:29.140000 --> 0:20:32.380000
 So that's what your
 traffic selector.

0:20:32.380000 --> 0:20:36.300000
 That's what your toss byte will
 look like if you do CS4.

0:20:36.300000 --> 0:20:46.360000
 All right. And that concludes this refresher
 and review of IP precedence