WEBVTT

1
00:00.000 --> 00:04.160
Alright, so we've got a few challenges here. We're going to do some translation

2
00:04.160 --> 00:04.720
. We start with

3
00:04.720 --> 00:09.480
DSCP-55. We're going to translate this to a user priority. Well, if we're

4
00:09.480 --> 00:10.400
translating to a user

5
00:10.400 --> 00:14.820
priority, we simply take this down to the nearest multiple of eight. So that

6
00:14.820 --> 00:16.320
would be 48. And then

7
00:16.320 --> 00:19.400
we divide it by eight, or we could just divide this by eight and scrap the

8
00:19.400 --> 00:20.480
remainder. However,

9
00:20.480 --> 00:25.200
we want to think about this. So ultimately, 55 is going to translate to UP-6.

10
00:25.200 --> 00:26.800
Now we're going from

11
00:26.800 --> 00:32.290
UP-2 to DSCP. This is a little bit simpler. We simply multiply by eight, and we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:26.800 --> 00:32.290
UP-2 to DSCP. This is a little bit simpler. We simply multiply by eight, and we

12
00:32.290 --> 00:32.800
see we get a

13
00:32.800 --> 00:37.800
DSCP-F16. But remember, this does get us into trouble if we have a voice over

14
00:37.800 --> 00:38.400
IP frame.

15
00:38.400 --> 00:44.980
That leverages a UP-6. This gets translated to a DSCP value of 48, which is why

16
00:44.980 --> 00:45.520
we want to use

17
00:45.520 --> 00:49.510
some of those precious metal policies. So this is not a challenge question. It

18
00:49.510 --> 00:51.040
's just a reminder of

19
00:51.040 --> 00:56.160
what one of the issues might be. Now, lastly, we have a wireless SSID that has

20
00:56.160 --> 00:58.000
a mix of normal users.

21
00:58.000 --> 01:02.800
So we've got some laptops out here, maybe some mobile devices, as well as video
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:58.000 --> 01:02.800
So we've got some laptops out here, maybe some mobile devices, as well as video

22
01:02.800 --> 01:03.440
conferencing,

23
01:03.440 --> 01:07.840
which is kind of interesting. So we might actually have users trying to video

24
01:07.840 --> 01:08.720
conference with one

25
01:08.720 --> 01:13.560
another through the wireless, or maybe to other wired users. But either way, we

26
01:13.560 --> 01:14.880
don't have any

27
01:14.880 --> 01:21.150
wireless phones. So which catalyst metal policy should be used? The answer here

28
01:21.150 --> 01:22.080
, believe it or not,

29
01:22.080 --> 01:26.880
is platinum. If you got this, then good job paying attention. We say, "Well,

30
01:26.880 --> 01:27.360
wait a second,

31
01:27.360 --> 01:32.720
platinum's supposed to be for a voice over IP." Sure. But video conferencing is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

31
01:27.360 --> 01:32.720
platinum's supposed to be for a voice over IP." Sure. But video conferencing is

32
01:32.720 --> 01:33.600
not only real-time

33
01:33.600 --> 01:38.190
traffic. It actually uses voice over IP as part of that, which is why it's so

34
01:38.190 --> 01:39.680
critical that we use

35
01:39.680 --> 01:44.010
the platinum policy. Remember, we care about the highest common denominator,

36
01:44.010 --> 01:44.560
not the lowest

37
01:44.560 --> 01:49.280
common denominator, which is why we've got normal user traffic on there, but we

38
01:49.280 --> 01:50.080
're still going to

39
01:50.080 --> 01:55.040
apply a platinum policy to that SSID. So our key takeaways from the skills,

40
01:55.040 --> 01:55.920
just making sure we

41
01:55.920 --> 02:00.700
understand how our wireless QoS mechanisms, especially the user priority
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
01:55.920 --> 02:00.700
understand how our wireless QoS mechanisms, especially the user priority

42
02:00.700 --> 02:02.560
translates to DSCP

43
02:02.560 --> 02:06.440
and the wired world in a real-world scenario, we're going to need to evaluate

44
02:06.440 --> 02:07.360
some of those policies

45
02:07.360 --> 02:11.200
and make sure that we get the right policies and the right SSIDs. And a lot of

46
02:11.200 --> 02:12.240
this just stems from

47
02:12.240 --> 02:17.490
wireless needing to be able to prioritize traffic. So as a wireless station, I

48
02:17.490 --> 02:18.320
need to prioritize

49
02:18.320 --> 02:22.810
my traffic, not over other traffic that I have on me, like a switch would, but

50
02:22.810 --> 02:23.920
I need to prioritize

51
02:23.920 --> 02:28.790
some of my traffic over some of your traffic as another wireless device, which

52
02:28.790 --> 02:30.240
makes things
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

52
02:28.790 --> 02:30.240
makes things

53
02:30.240 --> 02:33.790
pretty interesting in the end. I hope there's been informative for you, and I'd

54
02:33.790 --> 02:34.720
like to thank you for
