1 00:00:00,720 --> 00:00:04,650 Now I'd rather one because it doesn't trust any markings that it's receiving. 2 00:00:05,360 --> 00:00:08,450 There's more configuration in this example. 3 00:00:08,870 --> 00:00:11,390 Notice as an example that we've got a class map. 4 00:00:12,120 --> 00:00:14,010 Matching VoIP control. 5 00:00:14,220 --> 00:00:17,640 There's a class map matching RTP. 6 00:00:18,000 --> 00:00:25,830 This is using end bar or network based application recognition to determine whether the traffic is actually 7 00:00:25,830 --> 00:00:27,060 RTP traffic. 8 00:00:27,300 --> 00:00:29,310 It also matches an access list. 9 00:00:29,950 --> 00:00:30,870 So this is a match. 10 00:00:30,880 --> 00:00:36,480 Any set will either match RDP audio or whatever's configured in the success list. 11 00:00:36,490 --> 00:00:38,290 So let's have a look at that access list. 12 00:00:40,250 --> 00:00:42,860 Notice the access lists are fairly complicated. 13 00:00:42,860 --> 00:00:46,040 We have an access list for RTP traffic. 14 00:00:46,640 --> 00:00:55,940 Cisco IP phones, as an example, will send a voice traffic in the UDP range 16 384 up to 32767. 15 00:00:56,720 --> 00:01:05,230 So that's voice traffic notice the signaling traffic that's referenced here as an example, that's up. 16 00:01:06,140 --> 00:01:08,180 This is h33. 17 00:01:08,810 --> 00:01:10,520 This is mgc p. 18 00:01:10,730 --> 00:01:11,750 This is. 19 00:01:12,510 --> 00:01:18,450 Skinny, so explicit port numbers are matched for voice control. 20 00:01:18,780 --> 00:01:22,740 And here this port range is used for RTP. 21 00:01:23,980 --> 00:01:25,240 An TCP. 22 00:01:28,730 --> 00:01:37,340 TCP is a protocol used in OTP to give quality of service information back to a sender. 23 00:01:37,980 --> 00:01:46,380 So notice we are matching both OTP, the actual audio and TCP traffic that's put into this RTP and trust 24 00:01:46,380 --> 00:01:47,190 clause. 25 00:01:48,230 --> 00:01:57,500 Sup skinny h 3d three and other signaling protocols are put into this VoIP control and trust class. 26 00:01:58,310 --> 00:02:00,320 And here we have remarking. 27 00:02:00,320 --> 00:02:06,140 So if someone sends us F traffic, what we're going to do is we're going to remarket. 28 00:02:06,740 --> 00:02:17,390 So notice down here any traffic that's received marked as F plus select selected three or a F 31 is 29 00:02:17,390 --> 00:02:19,610 remarked as default. 30 00:02:19,700 --> 00:02:23,450 In other words, it's marked as zero best effort traffic. 31 00:02:24,440 --> 00:02:29,710 Safe Rider three is mocking its traffic as F and then sends it across this link to rata. 32 00:02:29,720 --> 00:02:37,490 One rather one is going to remarket as zero because rata one doesn't trust rather two in the way that 33 00:02:37,490 --> 00:02:38,720 I've configured this. 34 00:02:38,720 --> 00:02:44,150 So any of these traffic types will be remarked as default traffic. 35 00:02:44,450 --> 00:02:53,960 Voice traffic based on this match, RTP audio and the access list of the RTP port range will have its 36 00:02:53,960 --> 00:02:56,150 bandwidth set to 70%. 37 00:02:56,270 --> 00:03:00,590 So again, voice traffic will be prioritized over other traffic types. 38 00:03:00,800 --> 00:03:07,640 This is an example of low latency queuing with a priority bandwidth set to 70%, but notice it's also 39 00:03:07,640 --> 00:03:14,660 mocking the traffic as F on this side, the traffic wasn't marked because we trusting the markings that 40 00:03:14,660 --> 00:03:19,100 we receive on this side, we don't trust the markings that we receive. 41 00:03:19,100 --> 00:03:21,380 So we mark the traffic ourselves. 42 00:03:22,300 --> 00:03:31,270 So http voice traffic is set to f cole signaling is set to AF 31 and gets a guaranteed minimum bandwidth 43 00:03:31,270 --> 00:03:34,450 of 5% traffic that we receive. 44 00:03:34,450 --> 00:03:41,470 That's already marked as F or C is three or a, F 31 is marked down to best effort. 45 00:03:42,160 --> 00:03:44,680 Other traffic is queued using fare queuing. 46 00:03:45,010 --> 00:03:50,230 So these two classes share the remaining 25%. 47 00:03:50,230 --> 00:03:55,450 That's not used by voice and signalling when there's congestion. 48 00:03:56,170 --> 00:04:02,800 This is an example of using auto quasi VoIP to provide a good quality of service to voice traffic. 49 00:04:03,280 --> 00:04:08,230 And again, it's at the detriment of other traffic on the network. 50 00:04:08,770 --> 00:04:14,050 But because of voice, traffic is high priority, low latency. 51 00:04:14,560 --> 00:04:17,860 It's prioritized over other traffic types and is given. 52 00:04:18,820 --> 00:04:21,790 A priority queue of 70%. 53 00:04:22,690 --> 00:04:24,940 This is an example of using order costs. 54 00:04:24,970 --> 00:04:31,810 This may not be right for your environment and you may want to manually configure quality of service 55 00:04:31,810 --> 00:04:37,840 or allow order costs to discover the traffic on your network and then suggest policies. 56 00:04:38,410 --> 00:04:43,690 Again, you don't need to memorize all of this configuration, but I wanted to show you an example of 57 00:04:43,690 --> 00:04:49,540 both trusting and not trusting markings that a router receives. 58 00:04:49,810 --> 00:04:54,340 So in this example, rather one doesn't trust rather two, but rather two trusts rather one. 59 00:04:54,370 --> 00:04:59,770 Typically, you would match those policies up, so they would either both trust each other or neither 60 00:04:59,770 --> 00:05:00,970 would trust one another.