1 00:00:00,890 --> 00:00:04,610 Ahora en Rusia uno porque no confía en ninguna marca que está recibiendo. 2 00:00:05,530 --> 00:00:08,970 Hay más configuración en este ejemplo. 3 00:00:09,040 --> 00:00:14,220 Observe como ejemplo que tenemos un mapa de clase que coincide con el control blanco. 4 00:00:14,370 --> 00:00:18,100 Hay un mapa de clase que coincide con RTP. 5 00:00:18,150 --> 00:00:25,830 Esto está utilizando n barra o reconocimiento de aplicaciones basado en red para determinar si el tráfico es 6 00:00:25,860 --> 00:00:27,240 realmente tráfico RTP. 7 00:00:27,450 --> 00:00:30,000 También coincide con una lista de acceso. 8 00:00:30,060 --> 00:00:36,610 Entonces, esta es una coincidencia de cualquier lado, ya sea que coincida con el audio RTP o lo que esté configurado en la lista de éxito. 9 00:00:36,630 --> 00:00:42,910 Así que echemos un vistazo a esa lista de acceso, observe que las listas de acceso son bastante complicadas. 10 00:00:42,910 --> 00:00:50,440 Tenemos una lista de acceso para el tráfico RTP. Los teléfonos IP de Cisco, como ejemplo, enviarán un tráfico de 11 00:00:50,440 --> 00:00:56,770 voz en el rango UDP 16 3 8 para hasta 3 2 7 6 7. 12 00:00:56,860 --> 00:00:59,200 Entonces ese es el tráfico de voz. 13 00:00:59,230 --> 00:01:06,210 Observe el tráfico de señalización al que se hace referencia aquí como un ejemplo. 14 00:01:06,240 --> 00:01:08,710 Este es un tratado 3. 15 00:01:08,820 --> 00:01:10,840 Este es MVP. 16 00:01:10,920 --> 00:01:18,780 Esto es delgado, por lo que los números de puerto explícitos coinciden para el control VoIP. 17 00:01:19,000 --> 00:01:25,040 Y aquí este rango de puertos se usa para RTP y todo DCP RTP 18 00:01:28,620 --> 00:01:38,770 es un protocolo usado en RTP para devolver información de calidad de servicio a un remitente, así que tenga en cuenta que estamos haciendo 19 00:01:38,770 --> 00:01:48,790 coincidir tanto RTP con el audio real como con todo el tráfico DCP que se pone en este RTP sin confiar en Klaus SAP 20 00:01:49,540 --> 00:01:58,930 skinny H3 3 y otros protocolos de señalización se ponen en este CLO de control de VoIP no confiable y aquí tenemos 21 00:01:58,930 --> 00:02:00,070 un comentario. 22 00:02:00,550 --> 00:02:05,970 Entonces, si alguien nos envía tráfico, lo que haremos es leer el mercado. 23 00:02:06,850 --> 00:02:18,190 Por lo tanto, observe aquí que todo el tráfico que se recibe marcado como E F CLOs elige un 3 o un f 31 se 24 00:02:18,490 --> 00:02:19,890 señala como predeterminado. 25 00:02:19,930 --> 00:02:27,250 En otras palabras, está marcado como un esfuerzo basado en cero, salvo que el tráfico está marcado, en lugar de tres está marcando 26 00:02:27,280 --> 00:02:34,120 su tráfico como EF y luego lo envía a través de este enlace para escribir uno en lugar de uno va 27 00:02:34,120 --> 00:02:41,320 a leer el mercado como cero porque la derecha no confía lo escribió dos en la forma en que lo configuré para que 28 00:02:41,320 --> 00:02:45,770 cualquiera de estos tipos de tráfico se marque como tráfico de voz predeterminado. 29 00:02:45,910 --> 00:02:54,910 En función de esta coincidencia, el audio RTP y la lista de acceso del rango de puertos RTP tendrán su ancho de banda establecido en un 30 00:02:54,970 --> 00:02:56,250 70 por ciento. 31 00:02:56,470 --> 00:03:00,950 Entonces, nuevamente, el tráfico de voz se aterrorizará por otros tipos de tráfico. 32 00:03:00,970 --> 00:03:06,610 Este es un ejemplo de colas de baja latencia con un ancho de banda de prioridad establecido en 70 por ciento. 33 00:03:06,640 --> 00:03:10,460 Pero observe que también se está burlando del tráfico como E. F.. 34 00:03:10,660 --> 00:03:16,920 En este lado, el tráfico no estaba marcado porque confiamos en las marcas que recibimos en el lado. 35 00:03:16,920 --> 00:03:19,120 No confiamos en las marcas que recibimos. 36 00:03:19,120 --> 00:03:28,890 Así que nos burlamos del tráfico nosotros mismos para que el tráfico de voz RTP esté configurado en E. F. la señalización de llamada se establece en f 37 00:03:28,890 --> 00:03:35,760 31 y obtiene un ancho de banda mínimo garantizado del 5 por ciento del tráfico que recibimos que ya 38 00:03:35,760 --> 00:03:41,900 está marcado como e f o C, ya que tres f 31 se marcan al mejor esfuerzo. 39 00:03:42,270 --> 00:03:50,390 Otro tráfico se pone en cola utilizando colas falsas, por lo que estas dos clases comparten el 25 por ciento restante. 40 00:03:50,400 --> 00:03:56,230 Eso no es usado por la voz y la señalización cuando hay congestión. 41 00:03:56,310 --> 00:04:03,340 Este es un ejemplo del uso del pedido porque VoIP proporciona una buena calidad de servicio al tráfico de voz. 42 00:04:03,510 --> 00:04:11,520 Y de nuevo es en detrimento de otro tráfico en la red, pero debido al tráfico de voz 43 00:04:11,520 --> 00:04:14,500 es de alta prioridad baja latencia. 44 00:04:14,700 --> 00:04:22,800 Es poder elevarse sobre otros tipos de tráfico y se le da una cola de prioridad del 70 por ciento. 45 00:04:22,800 --> 00:04:25,150 Este es un ejemplo del uso del caos de orden. 46 00:04:25,200 --> 00:04:31,560 Esto puede no ser adecuado para su entorno y es posible que desee configurar manualmente la calidad 47 00:04:32,070 --> 00:04:38,520 del servicio o permitir que los quads de pedidos descubran el tráfico en su red y luego sugieran políticas. 48 00:04:38,520 --> 00:04:43,980 Una vez más, no es necesario que memorice toda esta configuración, pero 49 00:04:43,980 --> 00:04:49,980 quería mostrarle un ejemplo de las marcas confiables y no confiables que recibe un ciclista. 50 00:04:49,980 --> 00:04:54,530 Entonces, en este ejemplo, el piloto 1 no confía en el piloto 2 sino que confía en el piloto. 51 00:04:54,540 --> 00:04:59,910 Por lo general, coincidiría con esas políticas para que ambas confiaran entre sí o ninguna confiara 52 00:04:59,910 --> 00:05:00,770 entre sí.