Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated:
1
00:00:00,640 --> 00:00:06,668
Welcome to Jeremy’s IT Lab. This is a free,\n
2
00:00:06,668 --> 00:00:11,719
these videos, please subscribe to follow along\n
3
00:00:11,720 --> 00:00:16,138
a comment, and share the video to help spread\n
4
00:00:17,660 --> 00:00:23,399
In this video we will continue our study of\n
5
00:00:23,399 --> 00:00:28,288
voice VLANs and Power over Ethernet in the\n
6
00:00:28,289 --> 00:00:34,329
QoS in the second half. Hopefully you understand\n
7
00:00:34,329 --> 00:00:39,969
certain traffic such as voice and video traffic\n
8
00:00:39,969 --> 00:00:45,399
also to ensure it gets the required bandwidth.\n
9
00:00:45,399 --> 00:00:52,160
terms in exam topic 4.7, such as classification,\n
10
00:00:52,159 --> 00:00:58,309
shaping. Note that you don’t need to know\n
11
00:00:58,310 --> 00:01:02,670
As long as you understand the topics I introduce\n
12
00:01:05,159 --> 00:01:12,569
Here’s what we’ll cover in today’s video.\n
13
00:01:12,569 --> 00:01:18,048
how routers and switches identify which traffic\n
14
00:01:18,049 --> 00:01:23,340
cover queuing and congestion management. I\n
15
00:01:23,340 --> 00:01:28,590
but let’s go more in depth. Finally shaping\n
16
00:01:28,590 --> 00:01:35,140
rate at which traffic enters or exits an interface.\n
17
00:01:35,140 --> 00:01:40,519
practice question from Boson Software’s\n
18
00:01:42,540 --> 00:01:48,670
Let’s begin with classification. As you\n
19
00:01:48,670 --> 00:01:54,930
kinds of network traffic priority over others\n
20
00:01:54,930 --> 00:02:01,421
organizes network traffic, meaning packets,\n
21
00:02:01,421 --> 00:02:08,009
is that important for QoS? Classification\n
22
00:02:08,008 --> 00:02:13,429
certain types of traffic, you have to identify\n
23
00:02:13,430 --> 00:02:19,520
So, how can we classify traffic? There are\n
24
00:02:19,520 --> 00:02:25,900
are some examples. You can use an ACL. Traffic\n
25
00:02:25,900 --> 00:02:30,569
treatment, for example it could be treated\n
26
00:02:30,568 --> 00:02:36,179
is denied by the ACL will not be given that\n
27
00:02:36,180 --> 00:02:42,290
dynamic NAT. The ACL isn’t being used to\n
28
00:02:42,289 --> 00:02:50,370
being used to identify certain traffic. There\n
29
00:02:50,370 --> 00:02:54,989
Sometimes just looking at the Lower-layer\n
30
00:02:54,989 --> 00:03:02,009
and IP address, isn’t enough to identify\n
31
00:03:02,009 --> 00:03:07,219
what’s called a ‘deep packet inspection’\n
32
00:03:07,219 --> 00:03:12,840
all the way up to Layer 7 to identify the\n
33
00:03:12,840 --> 00:03:18,150
focus on methods like these in this video.\n
34
00:03:18,150 --> 00:03:23,739
specific fields used for this purpose, for\n
35
00:03:23,739 --> 00:03:29,890
them briefly in previous videos, but finally\n
36
00:03:29,889 --> 00:03:36,339
code point, field of the 802.1Q tag can be\n
37
00:03:36,340 --> 00:03:41,789
Keep in mind that this field can only be used\n
38
00:03:41,789 --> 00:03:47,908
tag is added to the Ethernet header. Then\n
39
00:03:47,908 --> 00:03:53,699
Code Point, field of the IP header. It can\n
40
00:03:53,699 --> 00:03:58,209
traffic. Okay, let’s take a look at each\nof these.
41
00:03:58,209 --> 00:04:05,438
First up, PCP. Here you can see an Ethernet\n
42
00:04:05,438 --> 00:04:11,069
field is in this dot1q tag. Here are the fields\n
43
00:04:11,069 --> 00:04:17,129
in the course, and the PCP field is this 3-bit\n
44
00:04:17,129 --> 00:04:22,699
this field referred to as CoS, class of service.\n
45
00:04:22,699 --> 00:04:31,529
of QoS, CoS just refers to this part of the\n
46
00:04:31,529 --> 00:04:38,409
So, let’s see how it has been defined. Well,\n
47
00:04:38,410 --> 00:04:44,830
0 to 7. This is how they are defined. You\n
48
00:04:44,829 --> 00:04:50,699
but I recommend remembering 0 for best effort,\n
49
00:04:50,699 --> 00:04:58,029
and 5 for voice. Regarding 0, best effort,\n
50
00:04:58,029 --> 00:05:03,259
means there is no guarantee that data is delivered\n
51
00:05:03,259 --> 00:05:08,789
regular traffic, not high-priority. This is\n
52
00:05:08,790 --> 00:05:13,990
have a value of ‘0’ in the PCP field.\n
53
00:05:13,990 --> 00:05:20,590
in the previous video, let me point out something\n
54
00:05:20,589 --> 00:05:27,319
traffic as PCP3. Call signaling traffic is\n
55
00:05:27,319 --> 00:05:32,339
the call is established, the actual voice\n
56
00:05:32,339 --> 00:05:39,610
as PCP5. I put the term mark in bold because\n
57
00:05:39,610 --> 00:05:46,490
to mark traffic is to set the value in the\n
58
00:05:46,490 --> 00:05:51,250
at those markings and use them to classify\n
59
00:05:51,250 --> 00:05:57,509
etc. So, when an IP phone marks its voice\n
60
00:05:57,509 --> 00:06:01,620
routers and switches to classify those packets\nas high-priority.
61
00:06:01,620 --> 00:06:08,939
Here’s a simple network with a couple PCs\n
62
00:06:08,939 --> 00:06:14,319
to demonstrate a very important point about\n
63
00:06:14,319 --> 00:06:19,519
PCP field is found in the dot1q header, it\n
64
00:06:19,519 --> 00:06:26,060
types. First, the obvious one is trunk links.\n
65
00:06:26,060 --> 00:06:30,680
dot1q, unless the traffic is in the native\n
66
00:06:30,680 --> 00:06:36,410
being used. However, as I explained in the\n
67
00:06:36,410 --> 00:06:41,410
well even over access links. So, assuming\n
68
00:06:41,410 --> 00:06:46,040
and phones can communicate with each other\n
69
00:06:46,040 --> 00:06:52,210
of these links are either trunk links or access\n
70
00:06:52,209 --> 00:06:57,500
between the phones and the switches are access\n
71
00:06:57,500 --> 00:07:03,180
the phones will be tagged. And these two connections\n
72
00:07:03,180 --> 00:07:10,300
10 or 20. So, over these connections devices\n
73
00:07:10,300 --> 00:07:15,430
to tell other devices to treat the traffic\n
74
00:07:15,430 --> 00:07:20,650
receiving that marked traffic can classify\n
75
00:07:20,649 --> 00:07:26,859
priority based on the PCP marking. Let me\n
76
00:07:26,860 --> 00:07:32,030
traffic from the PCs is not tagged with dot1q\n
77
00:07:32,029 --> 00:07:39,029
this link. In addition to that, all traffic\n
78
00:07:39,029 --> 00:07:44,939
destinations will not have a dot1q tag. So,\n
79
00:07:44,939 --> 00:07:51,709
with a PCP value, PCP cannot be used to classify\n
80
00:07:51,709 --> 00:07:58,539
using PCP, a limitation which the Layer 3\n
81
00:07:58,540 --> 00:08:05,020
So now let’s look at how marking and classification\n
82
00:08:05,019 --> 00:08:11,839
is a byte that is referred to as the ToS byte,\n
83
00:08:11,839 --> 00:08:18,909
the traffic class byte used for QoS, but let’s\n
84
00:08:18,910 --> 00:08:25,000
here, the second one in the header after the\n
85
00:08:25,000 --> 00:08:33,210
the ToS byte consists of two fields, DSCP,\n
86
00:08:33,210 --> 00:08:39,150
explicit congestion notification. However,\n
87
00:08:39,149 --> 00:08:46,049
Here’s the old use of the ToS byte. Three\n
88
00:08:46,049 --> 00:08:51,279
field. It was used to mark packets according\n
89
00:08:51,279 --> 00:08:58,129
dot1q header. The remaining 5 bits were mostly\n
90
00:08:58,129 --> 00:09:04,129
is that they weren’t really used. So, 3\n
91
00:09:04,129 --> 00:09:10,269
just like in the PCP field of the dot1q header.\n
92
00:09:10,269 --> 00:09:19,500
the one shown above, is this. 6 bits for DSCP\n
93
00:09:19,500 --> 00:09:25,419
total of 64 values, which gives a lot of flexibility\n
94
00:09:28,019 --> 00:09:34,429
Before going in depth about DSCP, let’s\n
95
00:09:34,429 --> 00:09:40,659
markings are similar to PCP. 6 and 7 are reserved\n
96
00:09:40,659 --> 00:09:46,699
traffic. That refers to traffic like OSPF\n
97
00:09:46,700 --> 00:09:54,460
voice traffic is marked as IPP 5, interactive\n
98
00:09:54,460 --> 00:10:00,210
used for voice signaling traffic, for setting\n
99
00:10:00,210 --> 00:10:05,629
is used for best effort traffic, regular data\n
100
00:10:05,629 --> 00:10:12,320
So, with 6 and 7 reserved, only 6 possible\n
101
00:10:12,320 --> 00:10:19,000
many networks, the QoS requirements of some\n
102
00:10:19,000 --> 00:10:24,940
And because IPP only used 3 bits of the ToS\n
103
00:10:24,940 --> 00:10:30,991
it was decided that an extra 3 bits would\n
104
00:10:34,000 --> 00:10:42,120
Now let’s take a look at DSCP. RFC 2474,\n
105
00:10:42,120 --> 00:10:49,220
field, and then other ‘DiffServ’, differentiated\n
106
00:10:49,220 --> 00:10:57,029
of the field. With IPP updated to DSCP, new\n
107
00:10:57,029 --> 00:11:02,789
Why is that? By having generally agreed upon\n
108
00:11:02,789 --> 00:11:08,980
QoS design and implementation is simplified,\n
109
00:11:08,980 --> 00:11:13,129
because they agree upon the markings that\n
110
00:11:13,129 --> 00:11:19,561
too. So, a few sets of industry-standard markings\n
111
00:11:19,561 --> 00:11:24,480
me say that it might feel a bit overwhelming\n
112
00:11:24,480 --> 00:11:28,680
flashcards to help you memorize them, but\n
113
00:11:28,679 --> 00:11:33,509
are some of the more common ones. I’ll point\n
114
00:11:33,509 --> 00:11:40,340
of the markings. So, you should be aware of\n
115
00:11:40,340 --> 00:11:45,700
forwarding, DF. This is the marking for best\n
116
00:11:45,700 --> 00:11:52,490
QoS requirements. Then there is EF, Expedited\n
117
00:11:52,490 --> 00:11:59,919
low loss, latency, and jitter, which is usually\n
118
00:11:59,919 --> 00:12:06,059
AF. This isn’t one marking, but a set of\n
119
00:12:06,059 --> 00:12:12,189
selector, CS, which is a set of 8 standard\n
120
00:12:13,309 --> 00:12:19,620
We won’t cover QoS configuration because\n
121
00:12:19,620 --> 00:12:26,069
you this. I configured a ‘class-map’ called\n
122
00:12:26,070 --> 00:12:31,680
used to identify which traffic you want to\n
123
00:12:31,679 --> 00:12:36,819
that I want to match traffic based on the\n
124
00:12:36,820 --> 00:12:42,210
out the options. At the top is the choice\n
125
00:12:42,210 --> 00:12:50,170
from 0 to 63. Then below that are the 12 AF\n
126
00:12:50,169 --> 00:12:59,139
for example AF11 has a binary value of 001\n
127
00:12:59,139 --> 00:13:04,841
the binary values are displayed on the right.\n
128
00:13:04,841 --> 00:13:12,710
shown here. That’s because the other one,\n
129
00:13:12,710 --> 00:13:20,120
000 000. Finally at the bottom is EF, expedited\n
130
00:13:22,820 --> 00:13:30,640
First up, DF and EF. DF is used for best-effort\n
131
00:13:30,639 --> 00:13:36,919
So, all 6 of these bits will be set to 0.\n
132
00:13:36,919 --> 00:13:41,870
continue, I’ll write the decimal value of\n
133
00:13:41,870 --> 00:13:48,940
traffic like sending an email or downloading\n
134
00:13:48,940 --> 00:13:55,270
DSCP field of the IP header, indicating that\n
135
00:13:55,269 --> 00:14:01,460
Then there is EF, expedited forwarding. EF\n
136
00:14:01,460 --> 00:14:09,160
latency, and jitter. Typically, voice traffic\n
137
00:14:09,159 --> 00:14:18,049
46. So, this is how it looks in binary, 1\n
138
00:14:18,049 --> 00:14:25,639
to remember. DF is used for best-effort traffic,\n
139
00:14:25,639 --> 00:14:31,689
requiring low-loss, low-latency, and low-jitter,\n
140
00:14:31,690 --> 00:14:36,920
is 46. Now things will get a bit more complicated.
141
00:14:36,919 --> 00:14:43,919
So we just looked at default, also called\n
142
00:14:43,919 --> 00:14:49,990
forwarding. AF can be a little tricky to understand,\n
143
00:14:49,990 --> 00:14:55,419
AF defines four traffic classes. All packets\n
144
00:14:55,419 --> 00:15:00,049
class number means higher priority, their\n
145
00:15:00,049 --> 00:15:05,599
than lower-priority packets. Then, within\n
146
00:15:05,600 --> 00:15:11,420
precedence. A higher drop precedence means\n
147
00:15:11,419 --> 00:15:19,278
due to WRED. Now, notice that I’ve set up\n
148
00:15:19,278 --> 00:15:24,899
up, in AF this bit on the end is always set\n
149
00:15:24,899 --> 00:15:31,539
this, it might just be because the designers\n
150
00:15:31,539 --> 00:15:37,409
These two bits in red represent the drop precedence.\n
151
00:15:37,409 --> 00:15:44,059
Now, when we write an AF value, it’s written\n
152
00:15:44,059 --> 00:15:49,588
of the class and Y being the decimal number\n
153
00:15:49,589 --> 00:15:51,850
at an example to see how to do it.
154
00:15:51,850 --> 00:16:01,028
So, we have a binary DSCP value of 001 010.\n
155
00:16:01,028 --> 00:16:06,500
AF X Y, with X being the decimal number of\n
156
00:16:06,500 --> 00:16:13,169
the drop precedence. To do that, we split\n
157
00:16:13,169 --> 00:16:18,849
two bits for the drop precedence. So, the\n
158
00:16:18,850 --> 00:16:25,649
of the drop precedence is also 1. So, this\n
159
00:16:25,649 --> 00:16:33,069
you like. Now, really this is just a 6-bit\n
160
00:16:33,070 --> 00:16:42,839
values up top, 1 2 4 8 16 and 32, we can calculate\n
161
00:16:42,839 --> 00:16:49,960
value as DSCP10. AF is just a set of standard\n
162
00:16:49,960 --> 00:16:55,528
than simply having 64 DSCP values with no\n
163
00:16:55,528 --> 00:17:04,621
Let’s do some more practice. Now we have\n
164
00:17:04,621 --> 00:17:12,300
time it’s class 1, drop precedence 2. So\n
165
00:17:12,299 --> 00:17:18,619
this as a normal decimal DSCP value? Here\n
166
00:17:18,619 --> 00:17:26,589
case, the DSCP value is also written as 12.\n
167
00:17:26,589 --> 00:17:33,049
Here’s another one. Try to figure it out\n
168
00:17:33,049 --> 00:17:37,889
how could we write it as a normal decimal\n
169
00:17:37,890 --> 00:17:43,340
showing you the value of each binary bit.\n
170
00:17:43,339 --> 00:17:52,939
each bit. This is AF2 3, or AF23. Written\n
171
00:17:52,940 --> 00:17:58,799
you were able to figure that out. If not that’s\n
172
00:17:58,799 --> 00:18:06,210
This time we have a binary DSCP value of 011\n
173
00:18:06,210 --> 00:18:13,058
written as a normal DSCP value? Let’s check.\n
174
00:18:13,058 --> 00:18:22,700
is AF3 2, or AF32. Written as a normal DSCP\n
175
00:18:24,789 --> 00:18:30,700
Okay, here’s one more for practice. Again,\n
176
00:18:30,700 --> 00:18:37,880
it as a normal DSCP value? Let’s check.\n
177
00:18:37,880 --> 00:18:48,240
3, so this is AF4 3, or AF43. Written as a\n
178
00:18:48,240 --> 00:18:56,190
is equivalent to DSCP 38. By the way, within\n
179
00:18:56,190 --> 00:19:03,289
5, 6, or 7. Okay, so you should be able to\n
180
00:19:03,289 --> 00:19:08,109
values. If you want a quick way to calculate\n
181
00:19:08,109 --> 00:19:16,599
here’s the formula. 8X plus 2Y, again the\n
182
00:19:16,599 --> 00:19:21,849
reason for this is that 8 is the lowest value\n
183
00:19:21,849 --> 00:19:28,599
value of the ‘Y’ portion. So to calculate\n
184
00:19:28,599 --> 00:19:34,230
understand the binary underneath it all, whether\n
185
00:19:34,230 --> 00:19:40,380
IPv6, matching with ACLs, QoS, whatever. But\n
186
00:19:40,380 --> 00:19:44,720
nice to have some shortcuts like this, 8X\nplus 2Y.
187
00:19:44,720 --> 00:19:51,880
So, here’s a summary of all of the AF values.\n
188
00:19:51,880 --> 00:19:58,520
So, within these AF values traffic marked\n
189
00:19:58,519 --> 00:20:04,500
the highest priority class, but has the lowest\n
190
00:20:04,500 --> 00:20:10,149
marked as AF13 gets the worst treatment, being\n
191
00:20:10,150 --> 00:20:15,450
drop precedence. I will include flashcards\n
192
00:20:15,450 --> 00:20:21,539
them from the AF values to the regular DSCP\n
193
00:20:21,539 --> 00:20:26,849
them, but you should be able to calculate\n
194
00:20:26,849 --> 00:20:34,419
Okay, that’s all for AF. I hope my explanation\n
195
00:20:34,420 --> 00:20:40,500
Finally, let’s look at CS. Fortunately,\n
196
00:20:40,500 --> 00:20:48,400
CS, class selector, defines eight DSCP values\n
197
00:20:48,400 --> 00:20:55,150
that backward compatibility work? The three\n
198
00:20:55,150 --> 00:21:01,530
and the original IPP bits are used to make\n
199
00:21:01,529 --> 00:21:07,539
again. Notice that the three bits on the right\n
200
00:21:07,539 --> 00:21:14,299
the original IP precedence bits, can be either\n
201
00:21:14,299 --> 00:21:22,589
three bits, 1 2 and 4. So, IPP gives us values\n
202
00:21:22,589 --> 00:21:31,649
CS are CS0, CS1, CS2, 3, 4, 5, 6, and 7. Very\n
203
00:21:31,650 --> 00:21:37,400
DSCP value of these. Although CS is a way\n
204
00:21:37,400 --> 00:21:44,280
8 values, they are still DSCP values. Fortunately\n
205
00:21:44,279 --> 00:21:53,190
just 8 multiplied by the CS number. CS0 is\n
206
00:21:53,190 --> 00:22:03,660
32, CS5 is 40, CS6 is 48, and CS7 is 56. Okay,\n
207
00:22:03,660 --> 00:22:12,140
Okay, so we’ve got DF, EF, AF, and CS. How\n
208
00:22:12,140 --> 00:22:18,640
use them? RFC 4954 was developed with the\n
209
00:22:18,640 --> 00:22:24,640
together and standardize their use. Many specific\n
210
00:22:24,640 --> 00:22:30,480
here are a few key ones. Voice traffic is\n
211
00:22:30,480 --> 00:22:37,160
delay, jitter, and loss. Interactive video\n
212
00:22:37,160 --> 00:22:45,570
or 3. Streaming video is marked as AF3x, high\n
213
00:22:45,569 --> 00:22:51,779
is marked as DF, a DSCP value of 0. There\n
214
00:22:51,779 --> 00:22:57,500
the RFC, do a google search for it if you’re\n
215
00:22:57,500 --> 00:23:03,179
to the engineer designing the QoS policy of\n
216
00:23:03,179 --> 00:23:05,370
These are just standard recommendations.
217
00:23:05,369 --> 00:23:12,309
Okay, let’s move on to take a quick look\n
218
00:23:12,309 --> 00:23:16,829
boundary of a network defines where devices\n
219
00:23:16,829 --> 00:23:22,250
received messages. If the markings are trusted,\n
220
00:23:22,250 --> 00:23:26,920
without changing the markings. But if the\n
221
00:23:26,920 --> 00:23:32,420
change the markings according to the configured\n
222
00:23:32,420 --> 00:23:40,820
boundary is here, at SW1. Phone1 sends a message\n
223
00:23:40,819 --> 00:23:47,939
is referring to the PCP field in the dot1q\n
224
00:23:47,940 --> 00:23:54,120
you should be familiar with both terms. Anyway,\n
225
00:23:54,119 --> 00:23:59,409
because it’s from outside of the trust boundary.\n
226
00:23:59,410 --> 00:24:06,240
DF and the CoS marking to 0, before forwarding\n
227
00:24:06,240 --> 00:24:12,529
just the DF marking because there is no dot1q\n
228
00:24:12,529 --> 00:24:16,548
Usually it’s best to trust the markings\n
229
00:24:18,230 --> 00:24:23,259
If an IP phone is connected to the switchport,\n
230
00:24:23,259 --> 00:24:28,808
to the IP phone. This is done via configuration\n
231
00:24:28,808 --> 00:24:35,928
by the way, not directly on the phone itself.\n
232
00:24:35,929 --> 00:24:40,298
PC’s traffic with a high-priority marking\n
233
00:24:40,298 --> 00:24:45,789
changed according to the configured policy.\n
234
00:24:45,789 --> 00:24:52,480
be trusted by the switch. In this case, if\n
235
00:24:52,480 --> 00:24:59,240
SW1 will trust those markings and not change\n
236
00:24:59,240 --> 00:25:04,480
sends an EF-marked packet, the switch should\n
237
00:25:04,480 --> 00:25:13,009
the EF marking, DSCP 46, to DF, DSCP 0. We\n
238
00:25:13,009 --> 00:25:17,539
treated with the same priority as the voice\n
239
00:25:17,539 --> 00:25:22,120
for trust boundaries. You don’t need to\n
240
00:25:22,121 --> 00:25:25,799
just be aware of the concept of trust boundaries\n
241
00:25:25,798 --> 00:25:30,779
Okay, that’s all for classification and\n
242
00:25:30,779 --> 00:25:35,799
congestion management. I already introduced\n
243
00:25:35,799 --> 00:25:41,450
bit more to be covered for the CCNA. For review,\n
244
00:25:41,450 --> 00:25:46,049
a faster rate than it can forward the traffic\n
245
00:25:46,049 --> 00:25:50,539
are placed in that interface’s queue as\n
246
00:25:50,539 --> 00:25:55,039
becomes full, packets that don’t fit in\n
247
00:25:55,039 --> 00:26:03,808
tail drop. RED and WRED, which I already introduced,\n
248
00:26:03,808 --> 00:26:09,549
the image I showed last video. The router\n
249
00:26:09,549 --> 00:26:15,759
the queue gets full and packets start getting\n
250
00:26:18,230 --> 00:26:25,120
However, an essential part of QoS is the use\n
251
00:26:25,119 --> 00:26:30,239
And this is where classification really plays\n
252
00:26:30,240 --> 00:26:35,558
on various factors, for the example the DSCP\n
253
00:26:35,558 --> 00:26:40,819
things, and then place the traffic in the\n
254
00:26:40,819 --> 00:26:46,039
only able to forward one frame out of an interface\n
255
00:26:46,039 --> 00:26:52,178
which queue traffic is forwarded from next.\n
256
00:26:52,179 --> 00:26:57,230
certain queues more priority than others.\n
257
00:26:57,230 --> 00:27:03,490
becomes clear. Here’s that same example\n
258
00:27:03,490 --> 00:27:07,700
router’s interface forwarding the traffic\n
259
00:27:07,700 --> 00:27:13,990
Here’s how it works. Ingress traffic is\n
260
00:27:13,990 --> 00:27:19,630
incoming traffic, traffic entering the router.\n
261
00:27:19,630 --> 00:27:25,280
which interface to send it out of, as well\n
262
00:27:25,279 --> 00:27:30,529
it classifies the traffic and places it into\n
263
00:27:30,529 --> 00:27:35,589
are four queues and traffic is classified\n
264
00:27:35,589 --> 00:27:40,918
the DSCP marking. Then the scheduler decides\n
265
00:27:40,919 --> 00:27:47,030
in which order, and the router forwards the\n
266
00:27:47,029 --> 00:27:51,928
oversimplification, but its basically how\n
267
00:27:51,929 --> 00:27:58,640
to forward the packet out of, it is classified,\n
268
00:27:58,640 --> 00:28:04,288
A common scheduling method is weighted round-robin.\n
269
00:28:04,288 --> 00:28:09,579
each queue in order, cyclically. And weighted\n
270
00:28:09,579 --> 00:28:14,639
queues each time the scheduler reaches that\n
271
00:28:14,640 --> 00:28:22,180
Next, here’s a term you definitely should\n
272
00:28:22,180 --> 00:28:27,259
is a popular method of scheduling, using a\n
273
00:28:27,259 --> 00:28:32,700
each queue a certain percentage of the interface’s\n
274
00:28:32,700 --> 00:28:40,169
let’s put these together. Here’s the process\n
275
00:28:40,169 --> 00:28:45,500
schedule it, and transmit. The device is using\n
276
00:28:45,500 --> 00:28:50,808
a certain amount of traffic from each queue\n
277
00:28:50,808 --> 00:28:56,139
a guaranteed minimum amount of bandwidth,\n
278
00:28:56,140 --> 00:29:00,840
is getting a lot more advanced than just a\n
279
00:29:00,839 --> 00:29:07,429
ideal. Specifically it’s not ideal for voice\n
280
00:29:07,430 --> 00:29:12,220
a guaranteed minimum amount of bandwidth,\n
281
00:29:12,220 --> 00:29:18,339
even the high-priority voice and video queues\n
282
00:29:18,339 --> 00:29:25,548
To solve that, we can configure LLQ, low latency\n
283
00:29:25,548 --> 00:29:31,220
as strict priority queues. Strict priority\n
284
00:29:31,220 --> 00:29:36,200
the scheduler will always take the next packet\n
285
00:29:36,200 --> 00:29:41,120
very effective for reducing the delay and\n
286
00:29:41,119 --> 00:29:46,739
as traffic enters the priority queue, the\n
287
00:29:46,740 --> 00:29:52,201
that same diagram, but this time the top queue\n
288
00:29:52,201 --> 00:29:56,759
is traffic in the queue, so the scheduler\n
289
00:29:56,759 --> 00:30:01,589
the weighted round-robin scheduling of the\n
290
00:30:01,589 --> 00:30:07,269
here. LLQ has the downside of potentially\n
291
00:30:07,269 --> 00:30:12,109
in the designated strict priority queue. The\n
292
00:30:12,109 --> 00:30:17,149
traffic. Policing, which I will cover in the\n
293
00:30:17,150 --> 00:30:22,240
allowed in the strict priority queue so that\n
294
00:30:22,240 --> 00:30:27,049
Okay, so in this section we expanded on the\n
295
00:30:27,049 --> 00:30:33,308
video and examined the use of multiple queues.\n
296
00:30:33,308 --> 00:30:38,990
looking at the DSCP value, then places it\n
297
00:30:38,990 --> 00:30:44,569
example using weighted round-robin logic,\n
298
00:30:44,569 --> 00:30:49,599
With the addition of LLQ, a strict priority\n
299
00:30:49,599 --> 00:30:55,209
priority packets. And by the way, within each\n
300
00:30:55,210 --> 00:31:01,450
like RED or WRED can be used to avoid tail\n
301
00:31:01,450 --> 00:31:08,411
Okay, here are the final topics for today,\n
302
00:31:08,411 --> 00:31:13,090
basically just have to understand what these\n
303
00:31:13,089 --> 00:31:19,699
them in one slide. Traffic shaping and policing\n
304
00:31:19,700 --> 00:31:24,340
In the previous examples of queuing and scheduling\n
305
00:31:24,339 --> 00:31:30,480
at full capacity, or beyond full capacity\n
306
00:31:30,480 --> 00:31:34,839
there are situations in which it is desirable\n
307
00:31:34,839 --> 00:31:40,899
actual maximum capacity of the link. Shaping\n
308
00:31:40,900 --> 00:31:46,461
rate goes over the configured rate. So, this\n
309
00:31:46,461 --> 00:31:50,970
instead of the actual capacity of the link\n
310
00:31:50,970 --> 00:31:57,429
traffic rate configured on the link. Policing\n
311
00:31:57,429 --> 00:32:03,820
if the traffic rate goes over the configured\n
312
00:32:03,819 --> 00:32:08,480
traffic over the configured rate is allowed\n
313
00:32:08,480 --> 00:32:14,279
data applications which are ‘bursty’ in\n
314
00:32:14,279 --> 00:32:19,180
they tend to send data in bursts. Just like\n
315
00:32:19,180 --> 00:32:24,769
traffic allowed is also configurable. And\n
316
00:32:24,769 --> 00:32:29,929
to allow for different rates for different\n
317
00:32:29,929 --> 00:32:35,269
to limit the rate traffic is sent or received?\n
318
00:32:35,269 --> 00:32:42,039
sample network. A customer router is connected\n
319
00:32:42,039 --> 00:32:47,079
The customer configures shaping outbound on\n
320
00:32:47,079 --> 00:32:53,288
ISP configures policing inbound on the G0/0\n
321
00:32:53,288 --> 00:32:58,859
of a reason why this might be done? Although\n
322
00:32:58,859 --> 00:33:05,750
1000 megabits per second, perhaps this customer\n
323
00:33:05,750 --> 00:33:11,150
So the ISP says, you paid for a 300 megabit\n
324
00:33:11,150 --> 00:33:17,070
incoming traffic to 300 megabits per second.\n
325
00:33:17,069 --> 00:33:22,639
faster than 300 megabits per second it will\n
326
00:33:22,640 --> 00:33:28,390
outgoing traffic to 300 megabits per second.\n
327
00:33:28,390 --> 00:33:32,360
and policing, but this is a common use of\nthese tools.
328
00:33:32,359 --> 00:33:37,599
Okay, that was a lot of material to cover.\n
329
00:33:37,599 --> 00:33:44,319
on to the quiz. First, we covered classification\n
330
00:33:44,319 --> 00:33:48,579
different kinds of traffic so that you can\n
331
00:33:48,579 --> 00:33:53,538
priority. Marking refers to setting the values\n
332
00:33:53,538 --> 00:34:00,470
3 headers for use in classification. We covered\n
333
00:34:00,470 --> 00:34:06,910
byte in the IP header, including IP Precedence\n
334
00:34:06,910 --> 00:34:12,608
also introduced the concept of trust boundaries.\n
335
00:34:12,608 --> 00:34:17,980
management, which I introduced in the last\n
336
00:34:17,980 --> 00:34:26,108
queues, weighted round-robin scheduling, CBWFQ,\n
337
00:34:26,108 --> 00:34:31,440
doesn’t actually do anything on its own.\n
338
00:34:31,440 --> 00:34:37,950
LLQ to make the devices treat those packets\n
339
00:34:37,949 --> 00:34:43,538
and policing, which are both tools to control\n
340
00:34:43,539 --> 00:34:48,240
until the end of the quiz for a bonus practice\n
341
00:34:48,239 --> 00:34:52,568
CCNA. Okay, let’s go to quiz question 1.
342
00:34:52,568 --> 00:34:56,168
SLIDE30\nWhich of the following CoS markings are consistent
343
00:34:56,168 --> 00:35:01,348
with standard practice? Select three. Okay,\n
344
00:35:05,639 --> 00:35:13,748
The answers are B, CoS 0 for best effort.\n
345
00:35:13,748 --> 00:35:18,949
Here’s that chart again showing the PCP\n
346
00:35:18,949 --> 00:35:23,998
values, and their traffic types. In your networks\n
347
00:35:23,998 --> 00:35:28,659
but this is standard practice. Okay, let’s\ngo to question 2.
348
00:35:28,659 --> 00:35:31,949
SLIDE31\nWhat bit pattern would you find in the DSCP
349
00:35:31,949 --> 00:35:38,929
field of a packet marked as EF? Pause the\n
350
00:35:38,929 --> 00:35:49,409
Okay, the answer is D, 101 110. Here it is,\n
351
00:35:49,409 --> 00:35:54,539
which is used for traffic requiring low delay,\n
352
00:35:54,539 --> 00:36:01,768
of 46, so the bit pattern is 101 110. Okay,\n
353
00:36:01,768 --> 00:36:04,808
SLIDE32\nWhich of the following AF markings provides
354
00:36:04,809 --> 00:36:12,298
the best service? Pause the video now to think\nabout the answer.
355
00:36:12,298 --> 00:36:19,650
The answer is B, AF41. Here is the table of\n
356
00:36:19,650 --> 00:36:26,289
priority class and it has the lowest drop\n
357
00:36:26,289 --> 00:36:34,068
queue, but it has a higher drop precedence.\n
358
00:36:34,068 --> 00:36:40,608
only uses classes 1, 2, 3, and 4. Okay, let’s\n
359
00:36:40,608 --> 00:36:43,478
SLIDE33\nWhich of the following statements represents
360
00:36:43,478 --> 00:36:50,519
general best practice regarding QoS? Pause\n
361
00:36:50,519 --> 00:36:58,530
Okay, the answer is A, trust markings from\n
362
00:36:58,530 --> 00:37:04,660
IP phones will typically mark their voice\n
363
00:37:04,659 --> 00:37:10,219
should be trusted because voice traffic requires\n
364
00:37:10,219 --> 00:37:15,599
PCs should not be trusted, though. Traffic\n
365
00:37:15,599 --> 00:37:20,019
as low priority so that it doesn’t fill\n
366
00:37:20,018 --> 00:37:27,409
traffic. Now, apps like Zoom or WebEx used\n
367
00:37:27,409 --> 00:37:33,818
we can mark those packets at the switch or\n
368
00:37:33,818 --> 00:37:37,099
SLIDE34\nWhich of the following creates a strict priority
369
00:37:37,099 --> 00:37:42,489
queue for data that requires low delay, jitter,\n
370
00:37:53,909 --> 00:37:58,068
there are packets in that queue the scheduler\n
371
00:37:58,068 --> 00:38:03,219
in the other queues. Okay, that’s all for\n
372
00:38:03,219 --> 00:38:08,313
question in Boson Software’s ExSim for CCNA.\n
373
00:39:58,324 --> 00:40:01,159
There are supplementary materials for this
374
00:40:01,159 --> 00:40:06,789
video. There is a flashcard deck to use with\n
375
00:40:06,789 --> 00:40:12,699
a packet tracer practice lab so you can get\n
376
00:40:12,699 --> 00:40:17,669
isn’t actually part of the CCNA exam and\n
377
00:40:17,670 --> 00:40:22,539
think it will be beneficial to see how it’s\n
378
00:40:22,539 --> 00:40:27,769
will be in the next video. Sign up for my\n
379
00:40:27,768 --> 00:40:32,639
and I’ll send you all of the flashcards\n
380
00:40:32,639 --> 00:40:35,848
SLIDE36\nBefore finishing today’s video I want to
381
00:40:35,849 --> 00:40:41,119
thank my JCNP-level channel members. To join,\n
382
00:40:41,119 --> 00:40:47,019
video. Thank you to Justin, Christopher, Sam,\n
383
00:40:47,018 --> 00:40:52,409
Serge, Njoku, Viktor, Roger, Raj, Kenneth,\n
384
00:40:52,409 --> 00:40:56,969
Gustavo, Benjamin, Prakaash, Nasir, Erlison,\n
385
00:40:56,969 --> 00:41:07,690
Mark, Yousif, Boson Software, Devin , Yonatan,\n
386
00:41:07,690 --> 00:41:13,608
incorrectly, but thank you so much for your\n
387
00:41:13,608 --> 00:41:19,588
at the time of recording by the way, April\n
388
00:41:19,588 --> 00:41:24,808
name isn’t on here don’t worry, you’ll\nbe in future videos.
389
00:41:24,809 --> 00:41:29,690
Thank you for watching. Please subscribe to\n
390
00:41:29,690 --> 00:41:34,630
and share the video with anyone else studying\n
391
00:41:34,630 --> 00:41:40,380
check the links in the description. I'm also\n
392
00:41:40,380 --> 00:41:44,298
or Basic Attention Token, tips via the Brave\n
32140
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.