1
00:00:00,890 --> 00:00:04,610
Now in Russia one because it doesn't trust any markings that it's receiving.

2
00:00:05,530 --> 00:00:08,970
There's more configuration in this example.

3
00:00:09,040 --> 00:00:14,220
Notice as an example that we've got a class map matching white control.

4
00:00:14,370 --> 00:00:18,100
There's a class map matching RTP.

5
00:00:18,150 --> 00:00:25,830
This is using n bar or network based application recognition to determine whether the traffic is actually

6
00:00:25,860 --> 00:00:27,240
RTP traffic.

7
00:00:27,450 --> 00:00:30,000
It also matches an access list.

8
00:00:30,060 --> 00:00:36,610
So this is a match any side will either match RTP audio or whatever's configured in the success list.

9
00:00:36,630 --> 00:00:42,910
So let's have a look at that access list notice the access lists are fairly complicated.

10
00:00:42,910 --> 00:00:50,440
We have an access list for RTP traffic Cisco IP phones as an example will send a voice traffic in the

11
00:00:50,440 --> 00:00:56,770
UDP range 16 3 8 for up to 3 2 7 6 7.

12
00:00:56,860 --> 00:00:59,200
So that's voice traffic.

13
00:00:59,230 --> 00:01:06,210
Notice the signaling traffic that's referenced here as an example that's.

14
00:01:06,240 --> 00:01:08,710
This is a treaty 3.

15
00:01:08,820 --> 00:01:10,840
This is MVP.

16
00:01:10,920 --> 00:01:18,780
This is skinny so explicit port numbers are matched for VoIP control.

17
00:01:19,000 --> 00:01:25,040
And here this port range is used for RTP and all DCP

18
00:01:28,620 --> 00:01:38,770
RTP is a protocol used in RTP to give quality of service information back to a sender so notice we are

19
00:01:38,770 --> 00:01:48,790
matching both RTP the actual audio and all DCP traffic that's put into this RTP untrusting Klaus SAP

20
00:01:49,540 --> 00:01:58,930
skinny H3 3 and other signalling protocols are put into this VoIP control untrusted CLOs and here we

21
00:01:58,930 --> 00:02:00,070
have remarking.

22
00:02:00,550 --> 00:02:05,970
So if someone sends us e f traffic what we gonna do is we're going to read market.

23
00:02:06,850 --> 00:02:18,190
So notice down here any traffic that's received marked as E F CLOs elect a 3 or a f 31 is a remarked

24
00:02:18,490 --> 00:02:19,890
as default.

25
00:02:19,930 --> 00:02:27,250
In other words it's marked as a zero based effort traffic save rather three is marking its traffic as

26
00:02:27,280 --> 00:02:34,120
E F and then sends it across this link to write a one rather one is going to read market as a zero because

27
00:02:34,120 --> 00:02:41,320
right one doesn't trust wrote it two in the way that I've configured this so any of these traffic types

28
00:02:41,320 --> 00:02:45,770
will be remarked as default traffic voice traffic.

29
00:02:45,910 --> 00:02:54,910
Based on this match RTP audio and the access list of the RTP port range will have its bandwidth set

30
00:02:54,970 --> 00:02:56,250
to 70 percent.

31
00:02:56,470 --> 00:03:00,950
So again voice traffic will be poor terrorized over other traffic types.

32
00:03:00,970 --> 00:03:06,610
This is an example of low latency queuing with a priority bandwidth set to 70 percent.

33
00:03:06,640 --> 00:03:10,460
But notice it's also mocking the traffic as E.F..

34
00:03:10,660 --> 00:03:16,920
On this side the traffic wasn't marked because we trusting the markings that we receive on the side.

35
00:03:16,920 --> 00:03:19,120
We don't trust the markings that we receive.

36
00:03:19,120 --> 00:03:28,890
So we mock the traffic ourselves so RTP voice traffic is set to E.F. call signaling is set to a f 31

37
00:03:28,890 --> 00:03:35,760
and gets a guaranteed minimum bandwidth of 5 percent traffic that we receive that's already marked as

38
00:03:35,760 --> 00:03:41,900
e f or C as three will f 31 is marked down to best effort.

39
00:03:42,270 --> 00:03:50,390
Other traffic is queued using fake queuing so these two classes share the remaining 25 percent.

40
00:03:50,400 --> 00:03:56,230
That's not used by voice and signaling when there's congestion.

41
00:03:56,310 --> 00:04:03,340
This is an example of using order cause VoIP to provide a good quality of service to voice traffic.

42
00:04:03,510 --> 00:04:11,520
And again it's at the detriment of other traffic on the network but because of voice traffic is high

43
00:04:11,520 --> 00:04:14,500
priority low latency.

44
00:04:14,700 --> 00:04:22,800
It's power to rise over other traffic types and is given a priority queue of 70 percent.

45
00:04:22,800 --> 00:04:25,150
This is an example of using order chaos.

46
00:04:25,200 --> 00:04:31,560
This may not be right for your environment and you may want to manually configure quality of service

47
00:04:32,070 --> 00:04:38,520
or allow order quads to discover the traffic on your network and then suggest policies.

48
00:04:38,520 --> 00:04:43,980
Again you don't need to memorize all of this configuration but I wanted to show you an example of both

49
00:04:43,980 --> 00:04:49,980
trusting and not trusting markings that a rider receives.

50
00:04:49,980 --> 00:04:54,530
So in this example rider 1 doesn't trust Rider 2 but rather to trust the rider one.

51
00:04:54,540 --> 00:04:59,910
Typically you would match those policies up so they would either both trust each other or neither would

52
00:04:59,910 --> 00:05:00,770
trust one another.