CALIDAD DE SERVICIO (QoS)

CALIDAD DE SERVICIO (QoS)

Introducción

Con el modelo de servidor físico que se muestra en la figura 27-2, cada servidor físico ejecuta un SO y ese sistema operativo utiliza todo el hardware de ese servidor. Que era cierto de los servidores en los días anteriores Virtualización de servidores.

Hoy en día, la mayoría de las empresas crean un centro de datos virtualizado. Eso significa que la empresa el hardware del servidor de las compras, lo instala en bastidores, y después trata toda la CPU, RAM, y así sucesivamente como capacidad en el centro de datos. Luego, cada instancia de SO se desempareja del hardware, y es por lo tanto virtual (en contraste con físico). Cada pieza de hardware que antes como un servidor ejecuta varias instancias de un SO al mismo tiempo, cada vez que se instancia de cual os denominada máquina virtual o VM.

Un único host físico (servidor) a menudo tiene más potencia de procesamiento de la que necesita para un SO. Pensando en los procesadores por un momento, las CPUs de servidores modernas tienen múltiples núcleos (procesadores) en un solo chip de CPU. Cada núcleo también puede ser capaz de ejecutar varios subprocesos con una característica se llama multihilo. Por lo tanto, cuando lees acerca de un procesador Intel en particular con 8 núcleos y multihilo (típicamente dos hilos por núcleo), que un chip de CPU puede ejecutar 16 diferentes programas simultáneamente. El hypervisor (introducido en breve) puede entonces tratar cada provecho el hilo de rosca capaz como una CPU virtual (vCPU), y da a cada VM un número de vCPUs, con 16 disponibles en este ejemplo.

Los routers típicamente se sientan en el borde WAN, con interfaces WAN e interfaces LAN. Las interfaces se ejecutan normalmente a velocidades mucho más rápidas, mientras que las interfaces WAN se ejecutan en velocidades más lentas. Mientras que la interfaz WAN más lenta está ocupada enviando los paquetes esperando en el router, cientos o incluso miles más paquetes IP podría llegar en una interfaz, toda la necesidad de ser remitido a la misma interfaz WAN. ¿Qué debe hacer el router? ¿Enviar todos ellos, en el mismo orden en que llegaron? Priorizar los paquetes, para enviar algunos que otros, ¿prefiriendo un tipo de tráfico sobre otro? ¿Descartar algunos de los paquetes Cuando el número de paquetes que esperan para salir del router es demasiado grande?

En ese primer párrafo se describen algunas de las muchas preguntas de calidad de servicio clásica (QoS) en networking. QoS se refiere a las herramientas que utilizan los dispositivos de red para aplicar algunos diferentes tratamientos a los paquetes de la red a medida que pasan a través del dispositivo. Por ejemplo, el XV un Edge router colaría paquetes esperando que la interfaz WAN esté disponible. El router también podría utilizar un algoritmo de programación de colas para determinar qué paquetes deben enviarse siguiente, utilizando algún otro orden que la orden de llegada, dando a algunos paquetes un mejor servicio, y algunos peores servicios.

 

 

QoS: administración de ancho de banda, demora, jitter y pérdida

Cisco ofrece una amplia gama de herramientas QoS tanto en routers como en switches. Todas estas herramientas dan los medios para administrar cuatro características del tráfico de red:

  • Acho de Banda
  • Retraso
  • Jitter
  • Pérdida

El ancho de banda se refiere a la velocidad de un enlace, en bits por segundo (BPS). Pero mientras pensamos en ancho de banda como la velocidad, también ayuda a pensar en el ancho de banda como la capacidad del enlace, en términos de la cantidad de bits que se pueden enviar por el enlace por segundo. Las herramientas QoS del dispositivo de red determinar qué paquete se envía a través del vínculo siguiente, por lo que el dispositivo de red está en control de que los mensajes tienen acceso al ancho de banda siguiente, y cuánto de ese ancho de banda (capacidad) y tipo de tráfico se hace con el tiempo.

Por ejemplo, considere el típico router WAN Edge que tiene cientos de paquetes esperando para salir del enlace WAN. Un ingeniero puede configurar una herramienta de colas para reservar el 10% del ancho de banda para el tráfico de voz, 50 por ciento para aplicaciones de datos de misión crítica, y dejar el resto del ancho de banda para todos los demás tipos de tráfico. La herramienta de colas podría utilizar esos ajustes para hacer la elección sobre qué paquetes enviar a continuación.

 

Delay se puede describir como retardo unidireccional o retardo de ida y vuelta. El retardo unidireccional se refiere a el tiempo entre el envío de un paquete y el mismo paquete que llega al host de destino. El retardo de ida y vuelta cuenta el retardo unidireccional más el tiempo para el receptor del primer paquete para devolver un paquete, es decir, el tiempo que se tarda en enviar un paquete entre dos anfitriones, y recibir una vuelta. Muchas diversas acciones individuales retrasan el impacto; Este capítulo Se discutirán algunos de ellos, incluyendo la cola y la configuración de retraso.

Jitter se refiere a la variación en el retardo unidireccional entre los paquetes consecutivos enviados por el mismo Paquete. Por ejemplo, Imagine que una aplicación envía unos pocos cientos de paquetes a un determinado Host. El retraso unidireccional del primer paquete es de 300 milisegundos (300 ms, o “3 segundos). La siguiente el retardo unidireccional de Packet es 300 ms; también lo es el tercero; y así sucesivamente. En ese caso, no hay jitter. Sin embargo, si en su lugar el primer paquete tiene un retraso unidireccional de 300 ms, el siguiente tiene un solo sentido demora de 310 MS, y el siguiente tiene 325 MS, entonces hay alguna variación en el retraso, 10 ms entre los paquetes 1 y 2, y otros 15 ms entre los paquetes 2 y 3. Esa diferencia es llamado jitter.

Finalmente, él Loss se refiere a la cantidad de mensajes perdidos, usualmente como un porcentaje de paquetes enviados. La comparación es simple: Si el remitente de alguna aplicación envía 100 paquetes, y sólo 98 llegar al destino, ese flujo de aplicación en particular experimentó una pérdida del 2 por ciento. La pérdida puede ser causada por muchos factores, pero a menudo, la gente piensa en la pérdida como algo causado por cableado defectuoso o servicios WAN deficientes. Esa es una causa. Sin embargo, se produce más pérdida debido al funcionamiento normal de los dispositivos de red, en los que las colas de los dispositivos se llenan demasiado, por lo que el dispositivo no tiene ningún lugar para poner nuevos paquetes, y descarta el paquete. Varios Las herramientas QoS administran los sistemas de colas para ayudar a controlar y evitar pérdidas.

 

Tipos de tráfico

Con QoS, un ingeniero de red se pone a punto de preferir un tipo de tráfico sobre otro en respecto al ancho de banda, demora, jitter y pérdida. A veces, esa elección se relaciona con el negocio. Por ejemplo, si todas las aplicaciones de misión crítica se asientan en servidores en tres subredes, a continuación, el plan QoS se podría configurar para que coincida con los paquetes que van a/de esa subred, y dar a ese tráfico un mejor tratamiento comparado con otro tráfico. Sin embargo, en otros casos, la la elección de cómo aplicar las herramientas QoS se relaciona con la naturaleza de diferentes tipos de aplicaciones. Algunas aplicaciones tienen diferentes necesidades de QoS que otras. El siguiente tema compara las diferencias en las necesidades de QoS basadas en el tipo de tráfico.

Aplicaciones de datos

En primer lugar, considere una aplicación web básica, con un usuario en un PC o tableta. El usuario escribe en un identificador URI para solicitar una página web. Esta solicitud puede requerir un solo paquete que vaya al servidor Web, pero puede resultar en cientos o miles de paquetes que regresan al cliente web, como se muestra en la figura 18-1.

 

 

Entonces, ¿cuál es el impacto del ancho de banda, demora, jitter y pérdida en una web interactiva basada en ¿Aplicación? En primer lugar, los paquetes requieren una cierta cantidad de capacidad de ancho de banda. En cuanto al retraso, cada uno de esos paquetes del servidor al cliente toma una cierta cantidad de retardo unidireccional, con un poco de jitter también. De los paquetes 500 mostrados en la figura 18-1, si algunos se pierden (errores de transmisión, descartados por dispositivos u otras razones), entonces la lógica TCP del servidor se retransmitir, pero es posible que partes de la página web no aparezcan de inmediato.

Mientras que las herramientas de QoS se centran en administrar ancho de banda, demora, jitter y pérdida, el usuario se preocupa principalmente sobre la calidad de la experiencia en general. Por ejemplo, con una aplicación Web, ¿cuánto tiempo después de hacer clic ¿ves algo útil en tu navegador web? Así que, como usuario, te importa sobre la calidad de la experiencia (QoE), que es un término que se refiere a la percepción de los usuarios de su uso de la aplicación en la red. Las herramientas QoS directamente impactan ancho de banda, demora, JITTer, y la pérdida, que entonces debe tener un poco de buen efecto general para influir en el QoE de los usuarios. Y puede utilizar herramientas de QoS para crear un mejor QoE para un tráfico más importante, por ejemplo, puede dar a ciertas aplicaciones críticas para el negocio un mejor tratamiento de QoS, que mejora QoE para los usuarios de esas aplicaciones.

Por el contrario, una aplicación de datos no interactiva (históricamente llamada tráfico batch), por ejemplo, backup de datos o transferencias de archivos: tiene diferentes requisitos de QoS que las aplicaciones de datos interactivas. Las aplicaciones por lotes suelen enviar más datos que las aplicaciones interactivas, nadie está sentado allí esperando para ver algo pop en la pantalla, el retraso y el jitter hace no importa mucho. Mucho más importante para estas aplicaciones es satisfacer la necesidad de completar la tarea más grande (transferencia de archivos) dentro de una ventana de tiempo más grande. Las herramientas QoS se pueden utilizar para proporcionar suficiente ancho de banda para satisfacer las necesidades de capacidad de estas aplicaciones, y administrar pérdida para reducir el número de redifusiones.

Aplicaciones de voz y vídeo

Las aplicaciones de voz y vídeo tienen un desglose similar de los flujos no interactivitos. Para hacer los puntos principales acerca de la voz y el vídeo, esta sección se ve más profundamente en el tráfico de voz.

Antes de mirar la voz, sin embargo, primero pensar en el uso del término fluir en la red. Un flujo es todos los datos que se mueven de una aplicación a otra sobre la red, con un flujo para cada dirección. Por ejemplo, si abre un sitio web y se conecta a un servidor Web, el contenido de la página web que se mueve desde el servidor al cliente es un flujo. Escuchar música con una aplicación de música en el teléfono, y que crea un flujo de su aplicación a la aplicación de música servidor, y un flujo desde el servidor de nuevo a su teléfono. Desde una perspectiva de voz, un teléfono la llamada entre dos teléfonos IP crearía un flujo para cada dirección. Para el vídeo, podría ser el tráfico de una cámara de video vigilancia recogida por el software de seguridad.

Ahora sobre la voz, específicamente voz sobre IP (VoIP). VoIP define los medios para tomar el sonido hecho en un teléfono y enviarlo dentro de paquetes IP a través de una red IP, jugando el con él sonido en el otro teléfono. La figura 18-2 muestra la idea general. Los pasos del Figura incluyen

Paso 1.

El usuario del teléfono hace una llamada telefónica y comienza a hablar.

Paso 2

Un chip llamado un codec procesa (digitaliza) el sonido para crear un código binario (160 bytes con el códec G. 711, por ejemplo) durante un período de tiempo determinado (generalmente 20 MS).

Paso 3

El teléfono coloca los datos en un paquete IP.

Paso 4

El teléfono envía el paquete al teléfono IP de destino.

 

Si usted trabaja a través de las matemáticas un poco, está sola llamada, con el codec G. 711, requiere cerca de 80 Kbps de ancho de banda (omitiendo el encabezado de enlace de datos y el overhead del remolque). Contando la cabeza- ERS y VoIP carga útil como se muestra en la figura, cada uno de los paquetes IP tiene 200 bytes. Cada una tiene 20 ms de voz digitalizada, por lo que el teléfono envía 50 paquetes por segundo. 50 paquetes en 200 bytes cada uno es 10.000 bytes por segundo, o 80.000 bits por segundo, que es 80 kbps. Otros códecs de voz requieren aún menos ancho de banda, con el uso de G. 729 comúnmente de 24 Kbps (ignorando otra vez la sobrecarga del enlace de datos).

Al principio, puede parecer como VoIP llamadas requieren poco en lo que respecta a QoS. Para el ancho de banda, una sola llamada de voz o flujo requiere sólo un poco de ancho de banda en comparación con muchas aplicaciones de datos. Sin embargo, la voz interactiva requiere un nivel mucho mejor de calidad para Delay, jitter y Pérdida.

Por ejemplo, piense en hacer una llamada telefónica con alta demora unidireccional. Terminas de hablar, y hacer una pausa para que la otra persona responda. Y no lo hacen, por lo que hablar de nuevo y escuchar la voz de la otra persona se sobrepuso por su cuenta. El problema: demasiado retraso. O, considere llamadas para las que se rompe el sonido. ¿El problema? Podría haber sido pérdida de paquetes, o podría haber estado nervioso.

Puede lograr un tráfico de voz de buena calidad a través de una red IP, pero debe implementar QoS para hacerlo. Herramientas de QoS establecidas a punto de dar diferentes tipos de tráfico el comportamiento de QoS que necesita. Guía de diseño de la red de referencia de la solución Enterprise QoS de Cisco, cita otras fuentes además de depender de la larga experiencia de Cisco en la implementación de QoS, sugiere las siguientes pautas para voz interactiva:

  • Delay (one-way): 150 ms or less
  • Jitter: 30 ms or less
  • Loss: 1% or less

En comparación, la voz interactiva requiere más atención que las aplicaciones de datos interactivas para las características de QoS. Las aplicaciones de datos generalmente toleran más demora, jitter y pérdida que la voz (y el vídeo). Una sola llamada de voz generalmente toma menos ancho de banda que una aplicación de datos típica, pero ese requerimiento de ancho de banda es consistente. Las aplicaciones de datos tienden a ser estallas, con los datos ráfagas en la reacción al usuario que hace algo con la aplicación.

El vídeo tiene un conjunto mucho más variado de requisitos de QoS. Generalmente, piense en el video como voz, pero con un requisito de ancho de banda mucho más alto que la voz (por flujo), y requisitos similares para demora baja, jitter y pérdida. En cuanto al ancho de banda, el video puede usar una variedad de codecs que impactan la cantidad de datos enviados, pero muchas otras características técnicas impactan la cantidad de ancho de banda requerido para un solo flujo de video. (por ejemplo, un evento deportivo con mucho movimiento en la pantalla toma más ancho de banda que un ancla de noticias que lee las noticias delante de un fondo sólido con poco movimiento.) Esta vez citando de end-to-end diseño de red QoS, algunos requisitos para el vídeo incluyen.

  • Bandwidth: 384 Kbps to 20+ Mbps
  • Delay (one-way): 200—400 ms
  • Jitter: 30—50 ms
  • Loss: 0.1% – 1%

QoS on Switches and Routers

Antes de pasar a varias secciones del capítulo acerca de las herramientas específicas de QoS, permítanme hacer un punto acerca de los términos paquete y marco como se utiliza en este capítulo.

Las herramientas QoS que se discuten en este capítulo se pueden utilizar tanto en switches como en routers. Hay algunas diferencias en las características, y las diferencias en la implementación, debido a las diferencias de arquitectura interna entre routers y switches. Sin embargo, a la profundidad discutida aquí, las descripciones se aplican igualmente tanto a los switches LAN como a los routers IP.

Este capítulo utiliza el paquete de palabras de una manera general, para referirse a cualquier mensaje que está siendo procesado por un dispositivo de red, sólo por conveniencia. Normalmente, a lo largo de este libro y el ICNDI CERt Guide, el término paquete se refiere al encabezado IP y a los encabezados y datos encapsulados, pero sin el encabezado y el remolque de enlace de datos. El término marco se refiere al encabezado/Trailer de enlace de datos con sus encabezados y datos encapsulados. Para este capítulo, esas diferencias no importan a la discusión, pero al mismo tiempo, la discusión a menudo muestra un mensaje que a veces es literalmente un paquete (sin el encabezado/Trailer de Data Link) y a veces un frame.

A lo largo del capítulo, el texto utiliza el paquete para todos los mensajes, porque el hecho de que el mensaje tenga o no un encabezado/Trailer de enlace de datos en ese punto es inmaterial para la discusión básica de las características.

Además, tenga en cuenta que todos los ejemplos en el capítulo se refieren a los routers, sólo para ser coherente.

Clasificación y marcado

La primera herramienta QoS que se discute en este capítulo, clasificación y marcado, o simplemente marcado, hace referencia a un tipo de herramienta QoS que clasifica los paquetes basándose en el contenido del encabezado y, a continuación, marca el mensaje cambiando algunos bits en campos de encabezado específicos. Esta sección analiza primero el papel de la clasificación en todas las herramientas QoS y, a continuación, examina la función de marcado.

Fundamentos de la clasificación

Las herramientas QoS se sientan en el path que los paquetes toman al ser reenviados a través de un router o switch, muy parecido al posicionamiento de ACL. Al igual que las ACL, las herramientas QoS están habilitadas en la interfaz. También como ACL, las herramientas QoS están habilitadas para una dirección: paquetes que ingresan a la interfaz (antes de la decisión de reenvío) o para mensajes que salen de la interfaz (después de la decisión de reenvío).

El término clasificación se refiere al proceso de coincidencia de los campos en un mensaje para hacer una elección para tomar alguna acción QoS. Por lo tanto, de nuevo comparando las herramientas QoS con las ACL, las ACL realizan clasificación y filtrado; Esto es, las ACL coinciden (clasifican) los encabezados de paquetes. Las ACL pueden tener el propósito (acción) de elegir los paquetes que se descartarán. Las herramientas QoS realizan la clasificación (coincidencia de campos de encabezado) para decidir qué paquetes deben tomar ciertas acciones de QoS en contra. Estas acciones incluyen los otros tipos de herramientas de QoS que se discuten en este capítulo, como hacer cola, formar, vigilar, etc.

Por ejemplo, considere el procesamiento interno realizado por un router como se muestra en la figura 18-3. En este caso, se ha habilitado una herramienta de cola de salida en una interfaz. Los enrutadores utilizan herramientas de colas para colocar algunos paquetes en una cola de salida, otros paquetes en otro, etc., cuando la interfaz de salida pasa a estar ocupada. Luego, cuando la interfaz de salida esté disponible para enviar otro mensaje, el algoritmo de programador de la herramienta de colas puede seleccionar el siguiente mensaje desde cualquiera de las colas, priorizando el tráfico basándose en las reglas configuradas por el ingeniero de red.

 

 

La figura muestra los elementos internos de un router, y lo que sucede con el paquete durante una parte de ese procesamiento interno, desplazándose de izquierda a derecha dentro del router, de la siguiente manera:

Paso 1.

El router realiza una decisión de reenvío (enrutamiento).

Paso 2.

La herramienta Output Queue Server utiliza la lógica de clasificación para determinar qué paquetes van a la cola de salida.

Paso 3.

El enrutador contiene los paquetes de la cola de salida esperando a que la interfaz saliente esté disponible para enviar el siguiente mensaje.

Paso 4.

La lógica de programación de la herramienta de colas escoge el siguiente paquete, priorizando de forma efectiva un paquete sobre otro.

Si bien el ejemplo muestra una herramienta de cola, tenga en cuenta que la herramienta de colas requiere la capacidad de clasificar los mensajes comparando los mensajes con la configuración, al igual que las ACL.

Fundamentos de coincidencia (clasificación)

Ahora pensemos en la clasificación desde una perspectiva de toda la empresa, lo que nos ayuda a apreciar la necesidad de marcar. Cada herramienta QoS puede examinar varios encabezados para hacer comparaciones para clasificar paquetes. Sin embargo, puede aplicar herramientas QoS en la mayoría de los dispositivos de la red, a veces tanto en la entrada como en la salida de la mayoría de las interfaces. Utilizando complejos la coincidencia de muchos campos de encabezado en cada dispositivo y en la mayoría de las interfaces requiere mucha configuración. El trabajo para emparejar los paquetes puede incluso degradar el rendimiento del dispositivo de algunos dispositivos. Por lo tanto, mientras que usted podría tener todos los dispositivos de combinación de paquetes complejos, al hacerlo es una mala estrategia.

Una estrategia mejor, una recomendada tanto por Cisco como por RFC, sugiere hacer una combinación compleja a principios de la vida útil de un paquete y, a continuación, marcar el paquete. El marcado significa que la herramienta QoS cambia uno o más campos de encabezado, estableciendo un valor en el encabezado. Varios campos de encabezado se han diseñado con el fin de marcar los paquetes para el procesamiento de QoS. Entonces, los dispositivos que procesan el paquete más adelante en su vida pueden utilizar una lógica de clasificación mucho más simple.

La figura 18-4 muestra un ejemplo, con un PC a la izquierda enviando un paquete IP a algún host fuera del lado derecho de la figura (no se muestra). Switch sui, el primer dispositivo de red para reenviar el paquete realiza algunas comparaciones complejas y marca el campo punto de código de los servicios diferenciados de los paquetes (DSCP), un campo de 6 bits en el encabezado IP destinado a marcado QoS. Los tres dispositivos siguientes que procesan este mensaje (SW2, RI y R2) utilizan entonces una coincidencia más simple para clasificar el paquete comparando el valor DSCP del paquete, colocando paquetes con un valor DSCP en la clase 1 y paquetes con otro valor DSCP en la clase 2.

Clasificación en routers con ACL y NBAR

Ahora que conoce los fundamentos de lo que la clasificación y el marcado hacen juntos, esta sección toma la discusión un poco más profunda con una mirada más cercana a la clasificación en enrutadores, que es seguida por una mirada más cercana a la función de la marca.

Primero, la clasificación de QoS suena mucho a lo que hacen las ACL, y debería. De hecho, muchas herramientas de QoS soportan la posibilidad de simplemente referirse a una ACL IP, con este tipo de lógica: para cualquier paquete que coincida con la ACL con una acción de permiso, considere que el paquete de una coincidencia para QoS, así que hacer una acción de QoS en particular.

Como recordatorio, la figura 18-5 muestra el encabezado IP y TCP. Todos estos campos son igualables para la clasificación QoS.

 

Ahora piense en el plan QoS de la empresa por un momento. Ese plan debe enumerar detalles como los tipos de tráfico que se deben clasificar como en la misma clase para el propósito de cola, para dar forma y para cualquier otra herramienta QoS. Ese plan debe detallar los campos del encabezado que se pueden emparejar. Por ejemplo, si todos los teléfonos IP se asientan en subredes dentro del rango de direcciones 10.3.0.0/16, entonces el plan QoS debería indicarlo. A continuación, el ingeniero de red podría configurar una ACL extendida para que coincida con todos los paquetes a/desde direcciones IP dentro de 10.3.0.0/16 y aplicar las acciones de QoS apropiadas a ese tráfico de voz.

Sin embargo, no todas las clasificaciones se pueden hacer fácilmente emparejando con una ACL en casos más desafiadores, el reconocimiento de aplicación basado en la red de Cisco (NBAR) puede ser utilizado. NBAR está básicamente en su segunda versión principal, llamada NBAR2, o NBAR de próxima generación. En Resumen, NBAR2 coincide con los paquetes de clasificación en una gran variedad de formas que son muy útiles para QoS.

NBAR2 se ve mucho más allá de lo que una LCA puede examinar en un mensaje. Muchas aplicaciones no pueden ser identificadas basándose en un puerto bien conocido solo. NBAR resuelve esos problemas.

Cisco también organiza lo que NBAR puede coincidir en formas que hacen que sea fácil separar el tráfico en diferentes clases. Por ejemplo, la aplicación Cisco WebEx proporciona audio y video conferencia en la Web. En un plan QoS, es posible que desee clasificar WebEx de forma diferente a otro tráfico de vídeo, y clasificarlo de forma diferente a las llamadas de voz entre los teléfonos IP. Es decir, puede clasificar el tráfico WebEx y darle un marcador DSCP único. NBAR proporciona la capacidad que empareja fácil incorporada para WebEx, más bien sobre 1000 diversas subcategorías de usos.

Sólo para conducir el punto a casa con NBAR, el ejemplo 18-1 enumera cuatro líneas de salida de ayuda para uno de muchos comandos de configuración de NBAR. Elegí una variedad de artículos que podrían ser más memorable. Con el uso de las palabras clave de la izquierda en el comando de configuración correcto, usted podría coincidir con lo siguiente: video de entretenimiento de Amazon, video de los productos de la cámara de video vigilancia de Cisco, voz de los teléfonos IP de Cisco, y el vídeo de deportes de ESPN Channel. (NBAR se refiere a esta idea de definir las características de las diferentes aplicaciones como firmas de aplicación.)

 

Para concluir la discusión de NBAR para la clasificación, compare las dos primeras entradas resaltadas en la salida. Sin NBAR, sería difícil clasificar un vídeo de entretenimiento de Amazon versus el vídeo de una cámara de seguridad, pero esas dos entradas resaltadas muestran cómo se ha clasificado fácilmente ese tráfico de forma diferente. El tercer elemento destacado muestra cómo hacer coincidir el tráfico de los teléfonos IP de Cisco (y los equivalentes basados en PC), de nuevo para obtener una coincidencia más sencilla de los paquetes de un tipo determinado.

Marcado DSCP IP y cos Ethernet

El plan QoS para una empresa se centra en la creación de clases de tráfico que deben recibir ciertos tipos de tratamiento QoS. Ese plan notaría cómo clasificar los paquetes en cada clasificación, y los valores que deben marcarse en los paquetes, básicamente etiquetando cada paquete con un número para asociarlo con esa clase. Por ejemplo, ese plan podría indicar lo siguiente:

  1. Clasificar todo el tráfico de carga de voz que se utiliza con fines comerciales como DSCP IP EF y cos 5.
  2. Clasifique todas las videoconferencias y otros vídeos interactivos con fines comerciales como DSCP IP AF41 y cos 4.
  3. Clasifique todo el tráfico de aplicaciones de datos críticos para el negocio como DSCP IP AF21 y COS 2.

En este siguiente tema se observa de cerca los campos específicos que se pueden marcar, definiendo los campos DSCP y cos de marcado.

Marcar el encabezado IP

Marcar un campo QoS en el encabezado IP funciona bien con QoS porque el encabezado IP existe para todo el viaje desde el host de origen al host de destino. W Hen un host envía datos, el host envía un marco de enlace de datos que encapsula un paquete IP. Cada enrutador que reenvía el paquete IP descarta el encabezado de vínculo de datos antiguo y agrega un encabezado nuevo. Al marcar el encabezado IP, el marcado puede permanecer con los datos desde el primer lugar que se marca hasta que llegue al host de destino.

IPv4 define un tipo de byte de servicio (tos) en el encabezado IPv4, como se muestra en la figura 18-6. El RFC original definió un campo de precedencia de IP de 3 bits (IPP) para el marcado QoS. Ese campo nos dio ocho valores separados — binarios 000, 001, 010, y así sucesivamente, a través de 111 — los cuales cuando se convierten a decimal son 0 a 7 decimal.

 

Aunque una gran idea, IPP nos dio sólo ocho valores diferentes para marcar, por lo que posteriormente RFC redefinió el byte tos con el campo DSCP. DSCP aumentó el número de bits de marcado a 6 bits, lo que permite 64 valores únicos que se pueden marcar. Las RFC Diffserv, que se convirtieron en RFC a finales de los años 90, se han convertido en aceptadas como el método más común para usar al hacer QoS, y el uso del campo DSCP para el marcado se ha vuelto bastante común.

IPv6 también tiene un campo similar para marcar. El campo de 6 bits también va por el nombre DSCP, con el byte del encabezado IPv6 que se llama el byte de clase de tráfico IPv6. De lo contrario, piense que IPv4 e IPv6 son equivalentes en términos de marcado.

Los campos IPP y DSCP pueden ser referenciados por sus valores decimales, así como también por algunos nombres de texto convenientes. La sección titulada “valores de marcado sugeridos Diffserv” más adelante en esta sección detalla algunos de los nombres.

Marcando el Ethernet 802. Encabezado IQ

Otro campo de marcado útil existe en el encabezado 802.1 q, en un campo definido originalmente por el estándar IEEE 802.1 p. Este campo se encuentra en el tercer byte del encabezado de 4 bytes 802.1 q, como un campo de 3 bits, proporcionando ocho valores posibles a Mark (vea la figura 18-7). Va por dos nombres diferentes: clase de servicio, o cos, y punto de código de prioridad, o PCP.

 

La figura utiliza dos tonos ligeramente diferentes de gris (en impresión) para los campos de encabezado y remolque Ethernet en comparación con el encabezado 802.1 q, como recordatorio: el encabezado 802.1 q no está incluido en todos los marcos Ethernet. El encabezado 802.1 q sólo existe cuando se utiliza la Troncalización 802.1 q en un vínculo. Como resultado, las herramientas QoS sólo pueden hacer uso del campo cos para las funciones de QoS habilitadas en las interfaces que utilizan Troncalización, como se muestra en la figura 18-8.

 

 

Por ejemplo, si el PC de la izquierda enviara datos a un servidor en algún lugar de la figura a la derecha, el campo DSCP existiría para todo el viaje. Sin embargo, el campo de cos existiría sobre los dos troncos solamente, y sería útil principalmente en las cuatro interfaces observadas con las líneas de la flecha.

Otros campos de marcado también existen en otros encabezados. La tabla 18-2 enumera los campos de referencia.

 

Definición de límites de confianza

El dispositivo de usuario final puede marcar el campo DSCP, e incluso el campo cos si se utiliza la Troncalización en el vínculo. ¿podría usted, como Ingeniero de red, confiar en esos ajustes y permitir que sus dispositivos de red confíen y reaccionen a esas marcas para sus diversas acciones QoS?

La mayoría de nosotros no, porque cualquier cosa que los controles de usuario final podrían ser utilizado inapropiadamente a veces. Por ejemplo, un usuario de PC podría saber lo suficiente acerca de Diffserv y puntos DSCP para saber que la mayoría del tráfico de voz está marcado con un DSCP denominado reenvío acelerado (EF), que tiene un valor decimal de 46. El tráfico de voz obtiene un gran tratamiento QoS, por lo que los usuarios de PC podrían marcar todo su tráfico como DSCP 46, con la esperanza de obtener un gran tratamiento QoS.

Las personas que crean un plan QoS para una empresa tienen que elegir dónde colocar el límite de confianza para la red. El límite de confianza se refiere al punto de la ruta de acceso de un paquete que fluye a través de la red en la que los dispositivos de red pueden confiar en las marcas de QoS actuales. Ese límite típicamente se encuentra en un dispositivo bajo el control del personal de ti.

Por ejemplo, se puede establecer un límite de confianza típico en el centro del primer conmutador de entrada de la red, como se muestra en la figura 18-9. No se puede confiar en las marcas del mensaje enviadas por el PC. Sin embargo, debido a que el sui realizó la clasificación y el marcado como los paquetes entraron en el interruptor, las marcas se pueden confiar en ese punto.

 

Curiosamente, cuando la capa de acceso incluye un teléfono IP, el teléfono es típicamente el límite de confianza, en lugar del conmutador de capa de acceso. Los teléfonos IP pueden configurar los campos cos y DSCP de los mensajes creados por el teléfono, así como los reenviados desde el PC a través del teléfono. Los valores de marcado específicos se configuran realmente en el interruptor de acceso adjunto. La figura 18-10 muestra el límite de confianza típico en este caso, con la notación de lo que la lógica de marcado del teléfono suele ser: Marque todo el tráfico del PC con un DSCP y/o cos en particular y el tráfico del teléfono con valores diferentes.

 

Diffserv sugirió valores de marcado

Todo en este capítulo sigue la arquitectura Diffserv definida originalmente por RFC 2475, además de muchas otras RFC Diffserv. En particular, Diffserv va más allá de la teoría en varias áreas, incluso haciendo sugerencias acerca de los valores DSCP específicos que se deben utilizar al marcar paquetes IP. Al sugerir marcas específicas para tipos específicos de tráfico, Diffserv esperaba crear un uso consistente de los valores DSCP en todas las redes. Al hacerlo, los proveedores de productos podrían proporcionar una buena configuración predeterminada para sus funciones de QoS, QoS podría funcionar mejor entre una empresa y un proveedor de servicios, y muchos otros beneficios podrían ser realizados.

Los dos temas siguientes contornean tres conjuntos de valores DSCP como se utilizan en Diffserv.

Expedición acelerada (EF)

Diffserv define el valor DSCP de reenvío acelerado (EF), un valor único, como se sugiere para el uso de paquetes que necesitan latencia baja (demora), baja fluctuación y pérdida baja. El RFC de reenvío acelerado (RFC 3246) define el valor DSCP específico (decimal 46) y un nombre de texto equivalente (reenvío acelerado). Los comandos de configuración de QoS permiten utilizar el valor decimal o el nombre de texto, pero un propósito de tener un acrónimo de texto es hacer que el valor sea más memorable, por lo que muchas configuraciones de QoS se refieren a los nombres de texto.

La mayoría de las veces los planes de QoS usan EF para marcar paquetes de carga de voz. Con las llamadas de voz, algunos paquetes llevan la carga útil de la voz, y otros paquetes llevan mensajes de la señalización de llamada. Mensajes de señalización de llamada configurar (crear) la llamada de voz entre dos dispositivos, y no requieren demora, jitter y pérdida de baja. Los paquetes de la carga útil de la voz llevan la voz convertida a digital, según lo demostrado detrás en la figura 18-2, y estos paquetes necesitan una mejor QoS. De forma predeterminada, los teléfonos IP de Cisco marcan la carga de voz con EF y marcan los paquetes de señalización de voz enviados por el teléfono con otro valor denominado CS3.

Reenvío asegurado (AF)

El RFC Diffserv (2597) de reenvío asegurado (AF) define un conjunto de 12 valores DSCP destinados a ser utilizados en concierto entre sí. En primer lugar, define el concepto de cuatro colas separadas en un sistema de colas. Además, define tres niveles de prioridad de caída dentro de cada cola para su uso con herramientas de evitación de congestión. Con cuatro colas y tres clases de prioridad de Drop por cola, necesita 12 marcadores DSCP diferentes, uno para cada combinación de colas y prioridad de caída. (los mecanismos de prevención de colas y congestión se discuten más adelante en este capítulo.)

El reenvío asegurado define los nombres de texto DSCP específicos y los valores decimales equivalentes indicados en la figura 18-11. Los nombres de texto siguen un formato de AFXY, con X refiriéndose a la cola (1 a 4), y y refiriéndose a la prioridad Drop (1 a 3).

 

Por ejemplo, si marcó paquetes con los 12 valores, los que tienen AFI 1, AF12 y AF13 entrarían en una cola; ésos con AF21, AF22, y AF23 irían en otra coleta; y así sucesivamente. Dentro de la cola con todo el tráfico AF2y, usted trataría el AF21, AF22, y AF23 cada uno diferentemente en lo que se refiere a las acciones de la gota (evitación de la congestión), con AF21 conseguir el tratamiento preferido y AF23 el tratamiento peor.

Selector de clase (CS)

Originalmente, el byte tos se definió con un campo de precedencia de IP de 3 bits (IPP). Cuando Diffserv redefinió el byte tos, tenía sentido crear ocho valores DSCP para compatibilidad con versiones anteriores con valores IPP. Los valores de DSCP del selector de clase (CS) son esos ajustes.

La figura 18-12 muestra la idea principal junto con los ocho valores CS, tanto en nombre como en valor decimal. Básicamente, los valores DSCP tienen los mismos primeros 3 bits que el campo IPP, y con SO binario para los últimos 3 bits, como se muestra en el lado izquierdo de la figura. CSX representa los nombres de texto, donde x es el valor IPP coincidente (0 a 7).

 

 

Esta sección sobre clasificación y marcado le ha dado una base sólida para entender las herramientas exploradas en las siguientes tres secciones principales de este capítulo: hacer cola, formar, vigilar, y evitar la congestión.

Administración de congestión (colas)

Todos los dispositivos de red utilizan colas. Los dispositivos de red reciben mensajes, hacen una decisión de reenvío y, a continuación, envían el mensaje, pero a veces la interfaz de salida está ocupada. Por lo tanto, el dispositivo mantiene el mensaje saliente en una cola, a la espera de que la interfaz saliente esté disponible, lo suficientemente simple.

El término administración de congestiones (que se encuentra en los temas del examen QoS) hace referencia al conjunto de herramientas QoS para administrar las colas que guardan paquetes mientras esperan su turno para salir de una interfaz (y en otros casos en los que un router contiene paquetes esperando algún recurso). Pero la gestión de la congestión se refiere a más de una idea, así que tienes que mirar dentro de los dispositivos para pensar en cómo funcionan. Por ejemplo, considere la figura 18-13, que muestra los elementos internos de un router. El router, por supuesto, hace una decisión de reenvío, y tiene que estar listo para colar paquetes para la transmisión una vez que la interfaz de salida está disponible. Al mismo tiempo, el router puede tomar una variedad de otras acciones también: ingreso ACL, ingreso NAT (en la interfaz interior), ACL de salida después de la decisión de reenvío se hace, y así sucesivamente.

 

 

La figura muestra la cola de salida, un aspecto de la administración de congestión, en el que el dispositivo contiene mensajes hasta que la interfaz de salida está disponible. El sistema de colas puede utilizar una única cola de salida, con un programador de primera en la primera salida (FIFO). (en otras palabras, es como pedir el almuerzo en la tienda de sándwiches que tiene una sola línea de pedido.)

A continuación, pensar un poco más profundamente sobre el sistema de colas. La mayoría de los dispositivos de red pueden tener un sistema de colas con varias colas. Para utilizar varias colas, el sistema de colas necesita una función clasificadora para elegir qué paquetes se colocan en qué cola. (el clasificador puede reaccionar a valores marcados previamente, o hacer una coincidencia más extensa.) El sistema de colas también necesita un programador, para decidir qué mensaje tomar después cuando la interfaz esté disponible, como se muestra en la figura 18-14.

 

 

De todos estos componentes del sistema de colas, el programador puede ser la parte más interesante, ya que puede realizar la priorización. La priorización (otro término de los temas del examen) se refiere al concepto de dar prioridad a una cola sobre otra de alguna manera.

 

Round Robin Programación (Priorización)

Un algoritmo de programación utilizado por los routers y switches de Cisco utiliza la lógica Round Robin. En su forma más básica, Round Robin cicla a través de las colas en orden, tomando turnos con cada cola. En cada ciclo, el programador toma un mensaje o toma un número de bytes de cada cola tomando suficientes mensajes para totalizar ese número de bytes. Tomar algunos mensajes de la cola 1, seguir adelante y tomar algunos de la cola 2, a continuación, tomar algunos de la cola 3, y así sucesivamente, comenzando de nuevo en la cola 1 después de terminar un pase completo a través de las colas.

La programación de Round Robin también incluye el concepto de ponderación (generalmente llamado Round Robin ponderado). Básicamente, el programador toma un número diferente de paquetes (o bytes) de cada cola, dando más preferencia a una cola sobre otra.

Por ejemplo, los enrutadores utilizan una herramienta popular denominada cola de espera justa ponderada basada en clases (CBWFQ) para garantizar una cantidad mínima de ancho de banda para cada clase. Esto es, cada clase recibe al menos la cantidad de ancho de banda configurado durante los tiempos de congestión, pero tal vez más. Internamente, CBWFQ utiliza un algoritmo de programación de Round Robin ponderado, mientras que permite al ingeniero de red definir las ponderaciones como un porcentaje del ancho de banda del enlace. La figura 18-15 muestra un ejemplo en el que las tres colas del sistema han recibido 20, 30 y 50 por ciento del ancho de banda cada uno, respectivamente.

 

Con el sistema de colas que se muestra en la figura, si el enlace saliente está congestionado, el programador garantiza el ancho de banda porcentual que se muestra en la figura en cada cola. Esto es, Queue 1 obtiene el 20 por ciento del enlace incluso durante tiempos ocupados.

Colas de latencia baja (LLQ)

Anteriormente en el capítulo, la sección titulada “aplicaciones de voz y vídeo” discutió las razones por las que la voz y el vídeo, particularmente la voz y el vídeo interactivos como las llamadas telefónicas y la videoconferencia, necesitan latencia baja (demora baja), baja jitter y baja pérdida. Infortunadamente, un programador de Round Robin no proporciona suficiente demora, jitter o pérdida. La solución: Añada colas de latencia baja (LLQ) al programador.

En primer lugar, para una revisión rápida, la tabla 18-3 enumera los requisitos de QoS para una llamada de voz. Los números provienen de la guía de diseño de red de referencia de soluciones de Enterprise QoS, referenciada anteriormente en el capítulo. La cantidad de ancho de banda requerido por llamada varía según el códec utilizado por la llamada. Sin embargo, los requerimientos de demora, jitter y pérdida siguen siendo los mismos para todas las llamadas de voz. (el vídeo interactivo tiene requisitos similares para el retardo, el jitter, y la pérdida.)

Un sistema de colas Round Robin añade demasiado retraso para estos paquetes de voz y vídeo. Para ver por qué, Imagine un paquete de voz llega y se enruta para ser enviado a cabo alguna interfaz con el sistema de colas que se muestra en la figura 18-16. Sin embargo, el siguiente paquete de voz llega justo cuando el programador Round Robin se desplaza para dar servicio a la cola marcada como “Data 1”. Aunque la cola de voz se ha dado 50 por ciento del ancho de banda del vínculo, el programador no envía ese mensaje de voz hasta que envía algunos mensajes de las otras tres colas: agregar retardo y jitter.

 

La solución, LLQ, indica al programador que trate una o más colas como colas de prioridad especiales. El programador LLQ siempre toma el siguiente mensaje de una de estas colas de prioridad especiales. Problema resuelto: muy poco retraso para los paquetes en esa cola, resultando en muy poco jitter también. Además, la cola nunca tiene tiempo para llenar, así que no hay gotas debido a la cola de llenado. La figura 18-17 muestra la adición de la lógica LLQ para la cola de voz.

 

El uso de LLQ, o una cola de prioridad, proporciona la demora, el jitter y la pérdida de baja necesaria para el tráfico en esa cola. Sin embargo, piense en esas otras colas. ¿ves el problema? ¿Qué sucede si la velocidad de la interfaz es x bits/segundo, pero más de x bits/segundo entran en la cola de voz? El programador nunca presta servicios a las otras colas (llamadas inanición de colas).

Como puede suponerse, existe una solución: limite la cantidad de tráfico que se coloca en la cola de prioridad, utilizando una función denominada policía. La siguiente sección habla de los policías con más detalle, pero por ahora, piense en ello como un límite en el ancho de banda utilizado por la cola de prioridad. Por ejemplo, puede reservar el 20% del ancho de banda del enlace para la cola de voz, y convertirlo en un

cola de prioridad. Sin embargo, en este caso, en lugar de que el 20 por ciento sea el ancho de banda mínimo, es el máximo para esa cola. Si más del 20 por ciento del valor del enlace de bits aparece en esa cola, el router descartará el exceso.

La limitación de la cantidad de ancho de banda en la cola de prioridad protege las demás colas, pero causa otro problema. La voz y el vídeo necesitan una pérdida baja, y con LLQ, ponemos la voz y el vídeo en una cola de prioridad que descartará los excesos de mensajes más allá del límite de ancho de banda. ¿La solución? Encuentre una manera de limitar la cantidad de voz y video que la red enruta en este enlace, para que el policía nunca descarte el tráfico. Hay herramientas de QoS para ayudarle a hacer justamente eso, llamadas herramientas de control de admisión de llamadas (CAC). Sin embargo, las herramientas CAC no se mencionan en los temas del examen, por lo que este capítulo deja las herramientas en una breve mención.

Una estrategia de priorización para datos, voz y vídeo

Esta sección acerca de Queue Server introduce varias ideas conectadas, así que antes de dejar la discusión de la cola, piense en esta estrategia para saber cómo la mayoría de las empresas se acercan a la cola en sus planes QoS:

  1. Utilice un método de cola Round Robin como CBWFQ para clases de datos y para voz y vídeo no interactivos.
  2. Si se enfrentan con un ancho de banda muy pequeño en comparación con la cantidad típica de tráfico, dar clases de datos que soporten aplicaciones críticas para el negocio mucho más ancho de banda garantizado que se da a clases de datos menos importantes.
  3. Utilice una cola de prioridad con la programación LLQ para voz y vídeo interactivo, para lograr un retraso, un jitter y una pérdida.
  4. Ponga voz en una cola separada del vídeo, de modo que la función de policía se aplique por separado a cada uno.
  5. Defina el ancho de banda suficiente para cada cola de prioridad de modo que el policía integrado no deba descartar ningún mensaje de las colas de prioridad.
  6. Utilice las herramientas de control de admisión de llamadas (CAC) para evitar añadir demasiada voz o vídeo a la red, lo que desencadenaría la función de policía.

Shaping and Policing

Esta sección presenta dos herramientas de QoS relacionadas, el modelado y la vigilancia. Estas herramientas tienen un uso más especializado, y no se encuentran en tantas ubicaciones en una empresa típica. Estas herramientas se utilizan con mayor frecuencia en el borde WAN en un diseño de red empresarial. Tanto la vigilancia como la configuración monitorean la velocidad de bits de los mensajes combinados que fluyen a través de un dispositivo. Una vez activada, el policía o el modelador toma nota de cada paquete que pasa y mide el número de bits por segundo con el tiempo. Ambos intentan mantener la velocidad de bits en o por debajo del nivel configurado, pero usando dos acciones diferentes: los policías descartan los paquetes y los moldeadores mantienen los paquetes en las colas para retrasar los paquetes.

Los modeladores y los policías monitorean la tasa de tráfico (los bits/segundo que se mueven a través del modelador o el policía) versus una tasa de configuración configurada o una tasa de policía, respectivamente. La pregunta básica que ambos solicitamos se enumera a continuación, con las acciones basadas en las respuestas:

  • ¿el siguiente paquete empuja la tasa medida más allá de la tasa de configuración configurada o la tasa de policía?
  • Si no:
    1. Deje que el paquete siga moviéndose por el camino normal y no haga nada adicional al paquete.
  • En caso afirmativo:
    1. Si configura, retrase el mensaje haciendo cola.
    2. Si la policía, o descartar el mensaje o marcar de manera diferente.

En esta sección se explica por primera vez la actuación policial, que descarta o remarca los mensajes que exceden la tasa policial, seguido de la configuración, lo que ralentiza los mensajes que exceden la tasa de formación.

Policing

Centrarse en la tasa de tráfico versus la tasa de vigilancia configurada por un momento, y la acción policial de descartar los mensajes. Esos conceptos se asientan en el núcleo de lo que hace la función policial.

El tráfico llega a los dispositivos de red a una velocidad variable, con valles y picos. Esto es, si graficas la velocidad de bits de los bits colectivos que entran o salen de cualquier interfaz, el gráfico se vería algo como el que está en el lado izquierdo de la figura 18-18. El policía mediría esa tasa, y hacer una medida similar. Aún en el lado izquierdo de la figura, la línea de trazo horizontal representa la tasa de vigilancia, que es la tasa configurada para el policía. Por lo tanto, el policía tiene cierta conciencia de la tasa de bits medido en el tiempo, que se puede comparar a la tasa configurada.

 

El lado derecho de la figura muestra un gráfico de lo que sucede con el tráfico cuando un policía descarta cualquier mensaje que de otra manera habría empujado la tasa por encima de la tasa de vigilancia configurada. En efecto, el policía corta la parte superior del gráfico a la velocidad policial.

El gráfico de la derecha también muestra un ejemplo de un policía que permite una ráfaga de tráfico. Los policías permiten una explosión más allá de la tarifa policial por un corto tiempo, después de un período de baja actividad. Por lo tanto, que un pico que excede la tasa de vigilancia en el gráfico en el lado derecho permite la naturaleza de las aplicaciones de datos de explosión.

Dónde utilizar la policía

Ahora que comprendes los fundamentos de la policía, tómate un momento para reflexionar. Los policías monitorean los mensajes, miden una tasa y descartan algunos mensajes. ¿Cómo ayuda a una red en cuanto a QoS? A primera vista, parece herir la red, descartando mensajes, muchos de los cuales el transporte o capa de aplicación tendrá que reenviar. ¿Cómo mejora el ancho de banda, loss, jitter o pérdida?

La policía sólo tiene sentido en ciertos casos, y como herramienta general, se puede utilizar mejor en el borde entre dos redes. Por ejemplo, considere una conexión de Ethernet WAN de punto a punto típica entre dos routers Enterprise, RI y R2. Normalmente, los ingenieros de la red Enterprise sólo ven la WAN como una nube, con interfaces Ethernet en los routers, como se muestra en la parte superior de la figura 18-19.

 

Ahora piense en el contrato para esta conexión de metro, como se muestra en la parte inferior de la figura 18-19. En este caso, esta conexión utiliza Gigabit Ethernet para los enlaces de acceso y una tasa de información (CIR) de 200-Mbps comprometida. Esto es, el SP que proporciona el servicio WAN acepta permitir que la empresa envíe 200 Mbps de tráfico en cada dirección. Sin embargo, como se comenta en el capítulo 14, recuerde que los routers Enterprise transmiten los datos a la velocidad del enlace de acceso, o 1 Gbps en este caso.

Piense como el SP por un momento, y piense en apoyar decenas de miles de enlaces Gigabit Ethernet en su servicio WAN, todos con CIRs 200-Mbps. ¿Qué pasaría si acaba de dejar que todos esos clientes envíen datos que, con el tiempo, promediaron cerca de 1000 Mbps (1 Gbps)? Esto es, si todos los clientes mantenían enviando datos mucho más allá de su CIR contratado, que mucho tráfico podría causar congestión en el servicio WAN. También, esos clientes pueden elegir pagar por un CIR de bajar, sabiendo que el SP enviaría los datos de todos modos. Y los clientes que se portaron bien, y no enviaron más datos que su CIR, podrían sufrir de la congestión tanto como los clientes que envían demasiados datos.

La figura 18-19 también toma nota de la solución al problema: el SP puede vigilar los paquetes entrantes, estableciendo la tasa de policía para que coincida con el CIR que el cliente elija para ese enlace. Al hacerlo, el SP protege a todos los clientes de los efectos negativos de los clientes que envían mucho tráfico. Los clientes reciben lo que pagaron. Y el SP puede proporcionar informes de las tasas de tráfico reales, por lo que la empresa sabe cuándo comprar un CIR más rápido para cada enlace.

Los policías pueden descartar el exceso de tráfico, pero también pueden volver a marcar los paquetes. Piense de nuevo en lo que hace un SP con un policía de ingreso como se muestra en la figura 18-19: están descartando los mensajes de sus clientes. Por lo tanto, el SP podría querer hacer un compromiso que funciona mejor.

para sus clientes, sin dejar de proteger la red del SP. El SP podría marcar los mensajes con un nuevo valor de marcado, con esta estrategia:

  1. Vuelva a marcar los paquetes que excedan la tasa de vigilancia, pero Déjenlos entrar en la red del SV.
  2. Si otros dispositivos de red SP experimentan congestión cuando procesan el paquete, el marcado diferente significa que el dispositivo puede descartar el paquete. Sin embargo.
  3. Si no hay otros dispositivos de red de SP que experimenten congestión al reenviar ese paquete remarcado, se obtiene a través de la red SP de todos modos.

Con esta estrategia, el SP puede tratar a sus clientes un poco mejor al descartar menos tráfico, mientras que todavía protege la red del SP durante tiempos de estrés. Resumiendo, las características clave de la policía:

  • Mide la tasa de tráfico con el tiempo para compararla con la tasa de policía configurada.
  • Permite una ráfaga de datos después de un período de inactividad.
  • Se habilita en una interfaz, en cualquier dirección, pero típicamente en ingreso.
  • Puede descartar el exceso de mensajes, pero también puede volver a marcar el mensaje para que sea un candidato para un descarte más agresivo más adelante en su viaje.

Shaping

 

Tiene un enlace de 1 Gbps desde un router a un SP, pero un CIR de 200 Mbps para tráfico a otro sitio, como se ve en la figura 18-19. El SP le ha dicho que siempre descarta el tráfico entrante que excede el CIR. ¿La solución? Utilice un moldeador para ralentizar el tráfico, en este caso a una velocidad de configuración de 200 Mbps.

Ese escenario, que forma antes de enviar datos a un SP que es policial, es uno de los usos típicos de un modelador. Los modeladores pueden ser útiles en otros casos también, pero en términos generales, los modeladores tienen sentido cuando un dispositivo puede enviar a cierta velocidad, pero hay un beneficio para ralentizar la tasa.

El modelador ralentiza los mensajes haciendo cola en los mensajes. A continuación, el modelador ofrece servicios a las colas de configuración, pero no se basa en Cuándo está disponible la interfaz física. En su lugar, el modelador programa los mensajes de las colas de configuración basándose en la velocidad de configuración, como se muestra en la figura 18-20. Siguiendo el flujo de izquierda a derecha en la figura, para un router, el paquete se enruta hacia fuera una interfaz; el modelador pone en cola los paquetes para que la velocidad de envío a través del modelador no exceda la velocidad de configuración; y, a continuación, la cola de salida funciona como normal, si es necesario.

Tenga en cuenta que, en algunos casos, la función de cola de salida tiene poco que hacer. Por ejemplo, en el ejemplo anterior que se muestra en la figura 18-19, el SP está vigilando los mensajes entrantes a 200 Mbps. Si el router (R1 por ejemplo) debía dar forma a todo el tráfico que salía hacia el SP a 200 Mbps también, con esa interfaz de 1 Gbps, la cola de salida rara vez sería congestionada. Dado que los modeladores crean colas donde los mensajes esperan, debe aplicar una herramienta de administración de congestión a esas colas. Es perfectamente normal aplicar las funciones de colas de CBWFQ y LLQ, respectivamente, a las colas de configuración, como se indica en la figura.

 

Configuración de un buen intervalo de tiempo de configuración para voz y vídeo

Una vez más, una herramienta QoS ha intentado resolver un problema de QoS, pero presenta otro. El efecto secundario desafortunado de un modelador es que se ralentiza los paquetes, que luego crea más demora, y probablemente más jitter. El retraso se produce en parte debido al mensaje simplemente esperando en una cola, pero en parte debido a los mecanismos utilizados por un modelador. Afortunadamente, usted puede (y debe) configurar la configuración de un modelador que cambia el funcionamiento interno de la modeladora, que luego reduce el retraso y la fluctuación causada por el tráfico de voz y video.

El intervalo de tiempo de un modelador se refiere a su lógica interna y la forma en que un moldeador promedia, con el tiempo, enviando a una tasa determinada. Un modelador básicamente envía lo más rápido que puede, y luego espera; envía y espera; envía y espera. Por ejemplo, el ejemplo de policía y modelado en esta sección sugiere formar a 200 Mbps en un router que tiene una interfaz saliente de 1000 Mbps (1 Gbps). En ese caso, el modelador resultaría en la interfaz enviando datos el 20 por ciento del tiempo, y permaneciendo en silencio el 80 por ciento del tiempo.

La figura 18-21 muestra un gráfico del concepto de intervalo de tiempo de modelado, asumiendo un intervalo de tiempo de 1 segundo. Para hacer un promedio de 200 millones bits por segundo, el modelador permitiría que 200 millones bits salieran de sus colas de configuración y salieran de la interfaz cada segundo. Debido a que la interfaz transmite bits a 1 Gbps, se tarda sólo .2 segundos, o 200 ms, para enviar todos los 200 millones bits. A continuación, el modelador debe esperar el resto del intervalo de tiempo, otro 800 MS, antes de comenzar el siguiente intervalo de tiempo.

Ahora piense en un paquete de voz o de vídeo que necesita muy poco retraso y jitter, y desafortunadamente, llega justo cuando el modelador termina de enviar datos para un intervalo de tiempo. Incluso si esa voz o el paquete de vídeo se encuentra en una cola de configuración de prioridad, el paquete esperará 800 MS antes de que el modelador programa el siguiente paquete, demasiado tiempo comparado con el objetivo de retardo de una vía de 150 ms para la voz.

La solución a este problema: configure un intervalo de tiempo corto. Por ejemplo, tenga en cuenta los siguientes intervalos de tiempo (TC abreviado) y sus efectos, para este mismo ejemplo (enlace de 1 Gbps, dando forma a 200 Mbps), pero con intervalos de tiempo más cortos y más cortos:

TC = 1 segundo (1000 ms): enviar a 1 Gbps para 200 ms, reposo para 800 MS

TC = .1 en segundo lugar (100 ms): enviar a 1 Gbps por 20 MS, reposo para 80 MS

TC = .01 segundo (10 ms): enviar a 1 Gbps para 2 ms, reposo para 8 ms

Al formar, utilice un intervalo de tiempo corto. Por recomendación, utilice un intervalo de tiempo de 10 ms para apoyar la voz y el vídeo. Con ese ajuste, un paquete de voz o vídeo no debe esperar más de 10 ms mientras espera el siguiente tiempo de configuración inter • al, momento en el que la programación de la cola de prioridad debe tomar todos los mensajes de voz y vídeo que se encuentran a continuación.

Resumiendo, las características clave de los modeladores:

  • Los modeladores miden la tasa de tráfico con el tiempo para compararla con la velocidad de configuración configurada.
  • Los modeladores permiten estallar después de un período de inactividad.
  • Los modeladores están habilitados en una interfaz para salida (paquetes salientes).
  • Los modeladores ralentizan los paquetes haciendo cola, y con el tiempo que los liberan de la
  • cola en la tarifa que forma.
  • Los modeladores utilizan las herramientas de cola para crear y programar las colas de configuración, que es muy
  • importante por las mismas razones discutidas para Output Queue Server.

Evitación de congestión

La función QoS denominada evitación de congestiones intenta reducir la pérdida total de paquetes preferentemente descartando algunos paquetes utilizados en conexiones TCP. Para ver cómo funciona, primero debe ver cómo funciona TCP en lo que se refiere a las ventanas y, a continuación, ver cómo funcionan las funciones de evitación de congestión.

Fundamentos de la ventana de TCP

TCP utiliza un mecanismo de control de flujo llamado Windowing. Cada receptor TCP concede una ventana al remitente. La ventana, que es un número, define el número de bytes que el remitente puede enviar a través de la conexión TCP antes de recibir una confirmación TCP para al menos algunos de esos bytes. Más exactamente, el tamaño de la ventana es el número de bytes no reconocidos que el remitente puede enviar antes de que el remitente simplemente se detenga y espere.

El mecanismo de la ventana TCP proporciona al receptor el control de la velocidad de envío de los datos del remitente. Cada nuevo segmento enviado por el receptor al remitente otorga una nueva ventana, que puede ser más pequeña o más grande que la ventana anterior. Por encima y abajo de la ventana, el receptor puede hacer que el remitente espere más o espere menos.

Por elección, cuando todo está bien, el receptor sigue aumentando la ventana concedida, duplicando cada vez que el receptor reconoce los datos. Eventualmente, la ventana crece hasta el punto de que el remitente nunca tiene que dejar de enviar: el remitente sigue recibiendo reconocimientos de TCP antes de enviar todos los datos en la ventana anterior. Cada nuevo reconocimiento (como se muestra en un segmento TCP y encabezado TCP) otorga una nueva ventana al remitente.

También por elección, cuando un receptor TCP detecta la pérdida de un segmento TCP, reduce la ventana con el siguiente tamaño de ventana que aparece en el siguiente segmento TCP que el receptor envía de vuelta al remitente. Para cada segmento de TCP perdido, la ventana puede reducirse por la mitad, con pérdidas de múltiples segmentos causando que la ventana se reduzca a la mitad varias veces, ralentizando significativamente la tasa del remitente.

Ahora piensa en las colas de router por un momento. Sin una herramienta de evasión de congestión, un evento llamado caída de cola causa la mayor cantidad de gotas en una red. La figura 18-22 muestra la idea, mostrando el mismo sistema de colas, pero en tres condiciones separadas: poca congestión, congestión media y mucha congestión. A la izquierda, con poca congestión, las colas de salida de una interfaz aún no se han completado. En el medio, las colas han empezado a llenarse, con una cola totalmente llena. Todos los paquetes nuevos que lleguen a esa cola en este momento se caerán porque no hay espacio en la cola de la cola (cola Drop).

 

Cuanto peor sea la congestión en las colas, más probable será la caída de la cola, como se muestra con el caso más congestionado en el lado derecho de la figura. Mientras más congestione, mayor es el impacto negativo en el tráfico, tanto en términos de pérdida como en términos de retraso creciente en las conexiones TCP.

Herramientas para evitar congestiones

Las herramientas de evasión de congestión intentan evitar la congestión, principalmente mediante el uso de mecanismos de ventana propios de TCP. Estas herramientas descartan algunos segmentos TCP antes de que las colas se llenen, con la esperanza de que suficientes conexiones TCP se ralentizarán, reduciendo la congestión y evitando un problema mucho peor: los efectos de muchos más paquetes que se han caído debido al drop de la cola. La estrategia es simple: deseche algunas ahora con la esperanza de que el dispositivo descarte mucho menos en el largo plazo.

Las herramientas de evitación de congestión monitorean la profundidad promedio de la cola con el tiempo, desencadenando acciones más severas cuanto más profunda es la cola, como se muestra en la figura 18-23. La altura del cuadro representa la profundidad de la cola o el número de paquetes de la cola. W gallina la profundidad de la cola es baja, por debajo de los valores mínimos de umbral, la herramienta de evitación de congestión no hace nada.

Cuando la profundidad de la cola se encuentra entre los umbrales mínimo y máximo, la herramienta de evitación de congestión descarta un porcentaje de los paquetes, usualmente un porcentaje pequeño, como 5, 10 o 20 por ciento. Si la profundidad de la cola pasa el umbral máximo, la herramienta elimina todos los paquetes, en una acción denominada Drop completo.

 

Por supuesto, al igual que todas las herramientas QoS mencionadas en este capítulo, las herramientas de evitación de congestión pueden clasificar mensajes para tratar algunos paquetes mejor que otros. En la misma cola, los paquetes con una marca pueden ser eliminados de forma más agresiva, y los que tienen mejores marcas de DSCP cayeron menos agresivamente.

¡ÚNETE A NUESTRO GRUPO DE #TELEGRAM https://t.me/joinchat/Gt2Ru0rFda0NR1VMfjWbEA!

Compartir esta publicación

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.