Mostrando las entradas con la etiqueta QoS. Mostrar todas las entradas
Mostrando las entradas con la etiqueta QoS. Mostrar todas las entradas

14 de junio de 2021

Transmisiones de video: ancho de banda requerido

Es una pregunta respecto del ancho de banda necesario para sostener comunicaciones de video de diferente tipo es recurrente en nuestra tarea. 
Es que no sólo el streaming de video ha ido ganando cada vez más lugar en el tráfico de la red. También se multiplican las aplicaciones que permiten acceder a contenidos basados en video o establecer comunicaciones de video; y cada vez de mayor calidad. Cuando se implementa QoS o se diseñan redes inalámbricas es necesario considerar la cantidad de comunicaciones de video simultaneas que habrá de sostenerse, y al hacerlo es fundamental conocer la calidad de ese video para poder estimar el ancho de banda necesario para garantizar su fluidez.

¿Qué es un "streaming" de video?
Con este término solemos referirnos a una transmisión de video unidireccional a través de una red de datos.
Es un tipo de transmisión que requiere la transferencia contínua de bits a través de la red de datos (Internet, la red corporativa o la red hogareña) hasta el receptor en el que se reproducirá.
Normalmente se trata de contenido enviado de modo comprimido, utilizando diferentes algoritmos de compresión, que el receptor final visualiza en tiempo real utilizando aplicaciones que no esperan a la descarga completa o a almacenarlo para poder reproducirlo.
Este video puede tener diferente resolución o calidad.
La resolución del video, junto al algoritmo de compresión utilizado, determinan el requerimiento de ancho de banda.

Video HD
Resolución de imagen: 720p, lo que implica una resolución de pantalla de 1280 x 720 píxeles.
Esta calidad de video, utilizando códec H.264 requiere 3 Mbps de ancho de banda.
Si se utiliza códec H.265 es necesario calcular un ancho de banda de 1,5 Mbps.

Video FHD
Resolución de imagen: 1080p, lo que implica una resolución de pantalla de 1920 x 1080 píxeles.
Cuando se utiliza códec H.264 su transmisión requiere 6 Mbps de ancho de banda.
Utilizando H.265 se recomienda estimar 3 Mbps para este streaming.

Video UHD
Resolución de imagen: 2160p, lo que implica una resolución de pantalla de 3840 x 2160 píxeles (el doble que FHD).
Aproximadamente 4 veces la cantidad de píxeles del video FHD.

Video 4K
Esta calidad de video refiere a 2 resoluciones posibles.
La resolución correspondiente a video UHD: 3840 x 2160 píxeles; o la resolución mayor disponible que es 4096 x 2160 píxeles. 
Materiales en esta resolución ya están disponibles en servicios de streaming como Netflix o YouTube.
Para una transmisión en resolución 4096 x 2160, con códec H.264 se recomienda reservar 32 Mbps. Si se utiliza códec H.265 hay que estimar 15 Mbps.

Sintetizando

HD     1280 x 720       H.264    3 Mbps
                                   H.265    1,5 Mbps
FHD   1920 x 1080    H.264     6 Mbps
                                  H.265     3 Mbps
UHD   3840 x 2160    H.264    25 Mbps
                                   H.265   12 Mbps
4K      4096 x 2160   H.264     32 Mbps
                                  H.265   15 Mbps



Estás invitado a participar de nuestro grupo en Facebook:

https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.



6 de enero de 2018

Introducción a QoS - Gráfica

La complejidad y requerimientos de las redes actuales exigen ir más allá de la simple preocupación por la conectividad extremo a extremo con el propósito de garantizar las condiciones en que el flujo de información de las diferentes aplicaciones circulará sobre la red una vez establecida esa conexión entre origen y destino.
El objetivo de implementar calidad de servicio es garantizar condiciones específicas de disponibilidad de ancho de banda, delay y pérdida de paquetes para cada uno de esos diferentes tipos de tráfico. 
Con este propósito se implementan diferentes mecanismos y herramientas que permiten aplicar las políticas de calidad de servicio definidas al tráfico en la infraestructura de la red:
  • Herramientas de clasificación y marcado.
    Son mecanismos que analizan el tráfico para agruparlo en diferentes clases.
    La clasificación es una tarea que requiere recursos de procesamiento, por lo que se procura realizarla la menor cantidad de veces posible y lo más cerca posible del origen; por esto, luego de clasificar el tráfico se lo marca.
  • Herramientas de gestión de la congestión y scheduling.
    Cuando el tráfico excede la capacidad de la red el tráfico es colocado en colas de memoria a la espera de contar con suficientes recursos. Estas herramientas permiten gestionar ese tráfico según parámetros definidos.
  • Herramientas específicas de los enlaces.
    Sobre enlaces WAN es posible aplicar herramientas especiales de calidad de servicio, como es el caso de la fragmentación e intercalado.
Este gráfico intenta mostrar de modo sintético y abarcativo las diferentes herramientas en la secuencia de operación sobre el flujo de paquetes.



Para profundizar en algunos temas de QoS:

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


10 de abril de 2017

Marcado de tráfico para QoS

Cuando se habla de calidad de servicio (QoS) es preciso tener en consideración que para  efectivizar los objetivos de preservación de tráfico que se proponen es necesario completar una serie de tareas específicas.
La primera de esas tareas es la clasificación de tráfico y a continuación el marcado.
El tráfico de la red puede ser marcado aprovechando diferentes campos de los encabezados de capa 2 y/o capa 3 del modelo OSI. Al uso de esos campos está dirigido este apunte sintético en el que recojo las principales convenciones para el marcado de tráfico.
  • DSCP
  • IP Precedence
  • Per-Hop Behavior
  • CoS (802.1p)
E incluido al final también las recomendaciones del RFC 4594 a este respecto.


Otras publicaciones sobre el tema



Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


20 de febrero de 2012

¿Cuál es el ancho de banda disponible de mi interfaz?

Hace ya tiempo dediqué un post a comentar el significado del comando bandwidth. En él explicaba que este comando no establece en "ancho de banda" de un enlace sino que tiene un valor declarativo para establecer un parámetro que luego utilizarán en sus algoritmos de cálculo los protocolos de capa superior, como los protocolos de enrutamiento.
Ahora bien, el ancho de banda declarado (bandwidth) también tiene impacto en las políticas de QoS.
La políticas de QoS por defecto
Un punto que frecuentemente ignoramos u olvidamos, es que Cisco IOS aplica en las interfaces una política por defecto: se reserva solamente un 75% del ancho de banda para el tráfico de datos. Esta reserva recibe el nombre de "available bandwidth".
¿Qué quiere decir esto?
Esto tiene 2 consecuencias:

  • Cisco IOS asegura que siempre hay una reserva de hasta el 25% del bandwith para el tráfico del plano de control.
    Esta  política tiene como propósito asegurar que los protocolos (p.e. protocolos de enrutamiento) que mantienen la infraestructura de la red tengan espacio suficiente para operar.
  • Cuando se aplican políticas de calidad de servicio, no se puede asignar más del 75% del ancho de banda declarado.
    Si una política define un volumen de tráfico garantizado mayor del 75% disponible, al aplicar la política a la interfaz se recibirá un mensaje de error indicando que se está excediendo la disponibilidad actual.
Esta política por defecto es importante en enlaces de baja capacidad ya que asegura el mantenimiento del plano de control. Sin embargo puede representar una mala política de asignación de recursos cuando se trata de enlaces de alta capacidad (por ejemplo enlaces de 10 Mbps o superiores).
De cualquier modo téngase en cuenta que esto no significa que ese 25 % no podrá ser utilizado para datos si está disponibles. Pongamos un ejemplo:

  • Tomemos como base un enlace de 10 Mbps: bandwidth 10000
  • Por defecto: reserva 2,5 Mbps para tráfico de control y permite reservar hasta 7,5 Mbps para datos.
  • ¿Qué ocurre si no tenemos más que 0,5 Mbps de plano de control?
    1. El tráfico de control tiene reservada capacidad de transporte más que suficiente.
    2. El tráfico de datos tiene reservados hasta 7,5 Mbps
    3. Siempre es posible que haya más de 7,5 Mbps de datos porque el tráfico de control no utiliza toda su reserva, pero no es posible garantizar cuánto más podrá usar.
¿Se puede modificar esta política por defecto?
Si, la política por defecto se puede modificar.
Una manera de modificarla es simplemente "mentir" el bandwidth ya que es puramente declarativo. Esta NO es una práctica recomendable ya que el parámetro no se utiliza solamente para el cálculo de las asignación de QoS, sino también como métrica para los protocolos de enrutamiento.
El modo de modificar la política es utilizando el comando max-reserved-bandwidth que permite modificar ese porcentaje por defecto del 75% para aplicar la política que más se ajuste a nuesta necesidad.
Este comando está disponible en todas las versiones actuales de IOS, a partir de 12.0, si bien en IOS 15.0 está como comando oculto ya que está anunciado por Cisco que el comando es reemplazado por otra metodología de configuración de QoS.


Enlaces relacionados

Bibliografía sugerida:
Introducción a Quality or Services - Oscar Gerometta 

2 de septiembre de 2010

Introducción a Quality of Services

Este manual es el inicio de una nueva colección denominada "Manuales CCNP".
Es un primer manual de calidad de servicio que está pensado para brindar el marco teórico necesario para  comprender la complejidad de los modelos teóricos y los procesos de calidad de servicio, y deberá ser seguido luego por otro que aborde la temática de la implementación, monitoreo y administración de las herramientas que desarrollo en este manual. No pretendo en pocas páginas agotar la problemática de calidad de servicio, sino generar una herramienta que sirva como primera aproximación al tema para lo que en sus páginas reviso un conjunto de modelos y protocolos que están hoy vinculados a este tipo de implementaciones.
Fecha de publicación: 20 de septiembre de 2010.
Autor: Oscar Antonio Gerometta
CCSI/CCAI/CCNA/CCNASec/CCDA. 
Ha liderado numerosos proyectos e iniciativas como desarrollador de e-learning, ha sido miembro del Curriculum Review Board de Cisco Networking Academy y uno de los docentes más reconocidos dentro del Programa en la Región Sud América Sur. En el año 2007 fue nominado a los premios "Education Recognition" y "Extraordinary Contributions Recognition" con ocasión de cumplirse 10 años del lanzamiento de Cisco Networking Academy.
En la actualidad se desempeña como consultor independiente. Como Certified Cisco Systems Instructor dicta una amplia variedad de cursos oficiales de Cisco Systems® (ICND, ROUTE, SWITCH, TROUBLE, QoS, BGP, MPLS, CUWN, CWLF, CWLAT, etc.). También es Senior Instructor del Programa de capacitación de Motorola en el área de redes inalámbricas (MWFE, MWSE y EWLAN).
Contenidos:



  • Qué es y por qué QoS
  • El desafío de las redes convergentes
  • La respuesta: QoS
  • Modelos de implementación de QoS
  • Modelo de Servicios Integrados
  • Modelo de servicios diferenciados
  • DSCP
  • Per-Hop Behaviors
  • Mecanismos de Calidad de Servicio
  • Clasificación de tráfico
  • Marcado del tráfico
  • Administración de la congestión
  • Prevención de la congestion
  • Condicionadores de tráfico: Policing y Shaping
  • Eficiencia de los enlaces
  • Anexo 1 Orden de operaciones de QoS en dispositivos de capa 3
  • Anexo 2 RFCs referenciadas en el texto
  • Anexo 3 Delay de serialización de diferentes tamaños de trama
  • Anexo 4 Diccionario de Siglas
Total: 88 páginas
Para ver una demo de este manual, ingrese aquí.


Para la adquisición:
  • Para solicitar tu ejemplar del texto impreso: solicitalo directamente por correo electrónico a libros.networking@gmail.com y lo recibirás en Argentina por Correo Argentino contrareembolso; en el exterior por Correo Argentino y hacen el pago por Western Union o PayPal.
  • La Introducción a Quality of Services en formato e-book está disponible desde el 3 de abril de 2003. Para consultas o adquisiciones, visite el blog de Ediciones EduBooks.
Otros títulos que incluirá la colección:
  • Apunte Rápido ROUTE. (en proceso de redacción)
  • Apunte Rápido SWITCH. (en proceso de redacción)

Cualquier comentario o consulta que consideres importante respecto a este tema,
procuraré responderlo rápidamente.
Por favor, incorporalo a continuación en forma de comentario.
Muchas gracias.
Oscar Gerometta

30 de agosto de 2010

Modelos de implementación de QoS

Calidad de Servicio (QoS) es un requerimiento creciente en las redes actuales. La presencia de tráfico de VoIP y crecientemente de video o multicast en la misma infraestructura que se utiliza para el tráfico de datos requiere de la implementación de QoS a fin de asegurar una correcta prestación de cada uno de los servicios.
Por esto me ha parecido conveniente ir introduciendo algunos conceptos relacionados con este tema. Y en primer lugar, referirme a los diferentes modelos de implementación.


Modelos de implementación de QoS
En la actualidad hay 3 modelos de aplicación de calidad de servicios para redes de datos:
  • Best-Effort.
    No se discrimina ningún tipo de tráfico y se brinda el mejor soporte posible desde la infraestructura.
  • IntServ.
    Las aplicaciones cuyo tráfico requieren tratamiento diferencial señalizan la red para requerir y garantizar los recursos necesarios para el adecuado funcionamiento de la aplicación.
    Garantiza las condiciones de operación de cada una de las sesiones que se establecen.
  • DiffServ.
    La infraestructura de la red es la que reconoce los diferentes tipos de tráfico y aplica políticas diferenciadas para cada clase de tráfico.
    Es más escalable y flexible en su implementación.
Best Effort
Es el modelo aplicado en Internet, y el que aplica por defecto toda red que no tiene políticas explícitamente definidas.
No garantiza ningún tratamiento o recurso específico a ningún flujo de información. Todo paquete es tratado de igual forma; no hay tratamiento preferencial.
Las principales características del modelo son:
  • Altamente escalable.
  • No requiere mecanismos o configuraciones especiales.
  • No garantiza recursos ni diferencia ningún tipo de servicio.
IntServ
Modelo de implementación de servicio bajo demanda. Tiene como objetivo garantizar recursos disponibles a lo largo de una ruta para una aplicación específica.
Antes de iniciarse propiamente la sesión de la aplicación se señaliza la ruta para verificar la disponibilidad de los recursos necesarios para un adecuado desarrollo de la misma .Una vez que la aplicación realiza la reserva de recursos la misma se mantiene aún cuando la aplicación no la esté utilizando, hasta tanto se levante la reserva de recursos. Permite garantizar las condiciones de operación de aplicaciones críticas.
Sus características más importantes son:
  • Negocia condiciones específicas de calidad de servicio antes de que se inicie la comunicación propiamente dicha.
  • Una vez hecha la reserva, la aplicación cuenta con los recursos reservados más allá de la situación de tráfico de la red.
  • Puede adecuarse a demandas específicas y diferentes de cada tipo de tráfico o aplicación.
  • La reserva de recursos se realiza para cada flujo de información en particular. No se reservan recursos en función de la aplicación genéricamente.
  • Cuando se asocia a desarrollos de telefonía IP, da una aproximación orientada a la conexión para este tipo de servicios. Cada dispositivo a lo largo de la ruta configura y mantiene la operación de cada comunicación individualmente.
  • Utiliza los servicios de RSVP (Resource Reservation Protocol).
  • No es escalable en grandes redes o implementaciones muy complejas.
DiffServ
Modelo de implementación de recursos garantizados de modo genérico y no por flujos o sesiones. Permite garantizar diferentes condiciones de servicio para diferentes tipos de tráfico, de modo escalable y efectivo, a través de toda la red.
  • No requiere señalización previa.
  • No permite garantizar condiciones de tráfico extremo a extremo.
  • Es muy flexible y escalable.
  • Divide el tráfico en clases en función de los requerimientos de la organización.
  • Cada paquete recibe el tratamiento que se ha definido para la clase a la cual ese paquete pertenece.
  • A cada clase se le puede asignar un diferente nivel de servicio y con ello diferentes recursos.
  • La asignación de recursos se hace salto por salto en cada dispositivo de la red y no para una ruta específica.
  • El mecanismo de implementación es relativamente complejo.
Para consultar:
¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

27 de abril de 2009

Calidad de servicio en redes WLAN

Nuestras redes de datos son hoy en realidad redes convergentes a través de las cuales no sólo circula tráfico de datos, sino adicionalmente comunicaciones de voz y video, sistemas de seguridad, sistemas críticos, etc.
Diferentes tráficos tienen diferentes requerimientos en cuanto a las prestaciones de nuestra red: delay, jitter, descarte de paquetes, preservación del ancho de banda, etc. Consecuentemente, la implementación de calidad de servicio en la red es hoy casi un supuesto básico.
La red wireless no es una excepción. Nuestras redes Wi-Fi ya no se usan exclusivamente para el tráfico de datos o la navegación de Internet. Esas mismas aplicaciones críticas, así como los sistemas de telefonía IP utilizan la infraestructura IEEE 802.11 para extender sus prestaciones. Es entonces necesario extender también las prestaciones de calidad de servicio a la red inalámbrica.

Lo básico de QoS
La implementación de calidad de servicio se basa en una serie de operaciones: clasificación del tráfico, marcación del tráfico y aplicación de políticas.
El marcado del tráfico es una fase clave de la implementación de QoS ya que es la que permite a los dispositivos reconocer los diferentes tipos de tráfico para luego aplicarle políticas.
Esta marcación se realiza aprovechando algún campo destinado a este propósito en los encabezados de capa 2 o capa 3 de la trama. En principio es fundamental la marcación en capa 3 ya que en una comunicación es el único encabezado que permanece constante de extremo a extremo. Con este propósito se utiliza el campo ToS (Type of Service) del encabezado IP dando lugar a 2 modelos de marcación conocidos como IP precedence y DSCP.
Sin embargo, para poder implementar calidad de servicio en dispositivos de capa 2 (propiamente denominada clase de servicio (CoS)), se requiere algún procedimiento que permita marcar tráfico utilizando el encabezado de la trama.
El tráfico Ethernet no puede ser clasificado, ya que el encabezado Ethernet carece de un campo que pueda destinarse a este propósito. Pero en redes switcheadas, puede apelarse a la utilización de 3 bits en encabezado IEEE 802.1Q utilizado para la identificación de VLANs en los enlaces troncales para la marcación de tráfico. Este procedimiento también suele ser denominado IEEE 802.1p en referencia al estándar desarrollado con este propósito.
Las redes WiFi son redes capa 2. En su definición original (IEEE 802.11) son redes tipo best effort, es decir no ofrecen servicios diferenciales para distinto tipo de tráfico.

QoS en redes IEEE 802.11
Las redes Wi-Fi implementan CSMA/CA como protocolo de acceso al medio que permite a los dispositivos competir por un acceso al medio de manera libre de colisiones, pero sin prioridades. De este modo, los dispositivos wireless "escuchan antes de enviar", y si el medio está libre transmiten. Este mecanismo da a todos los dispositivos la misma posibilidad de transmitir, pero cuando la red está congestionada, la performarce de todos los dispositivos y todas las aplicaciones se ve afectada.
Para poder establecer diferentes tipos de tráficos en el medio inalámbrico la IEEE desarrolló el estándar IEEE 802.11e que define la posibilidad de trabajar con hasta 8 clases de servicio diferentes (igual que IEEE 802.1p).
Para acelerar la adopción de tecnologías de calidad de servicio en redes Wi-Fi y mientras se aprobaba el estándar, la Alianza Wi-Fi desarrolló WiFi MultiMedia (WMM).
WMM es una reformulación de los 8 niveles de prioridad originales de IEEE 802.11e agrupados en 4 "categorías de acceso". De esta forma el tráfico que se recibe clasificado en el AP desde la red cableada utilizando IEEE 802.1p o DSCP, puede ser remarcado en IEEE 802.11 de modo que reciba diferente tratamiento sobre el medio inalámbrico, aumentando la probabilidad de que sea rápidamente transmitido el tráfico de alta prioridad.

WMM
Es una extensión de los mecanismos originales de WiFi basados ene CSMA-CA.
Introduce la priorización de tráfico basándose en la definición de 4 categorías de acceso: platino, oro, plata y bronce. Cuanto más alta es la prioridad, mayor es la probabilidad de que el tráfico sea transmitido en primer lugar. De esta manera el tráfico de clase platino será enviado antes que el oro, el plata o el bronce.
Estas cuatro categorías pueden mapearse a la marcación que se realiza utilizando DSCP u 802.1p para facilitar la interoperabilidad de los mecanismos de calidad de servicio implementados en la red.
WMM mapea las prioridades de las 4 colas de transmisión independientes que genera, con los ocho valores de niveles de prioridad que define IEEE 802.11e, de acuerdo a la siguiente tabla:
  • Voz - Platino - prioridades 6 o 7 de IEEE 802.11e.
  • Video - Oro - prioridades 4 o 5.
  • Background - Plata - prioridades 1 o 2
  • Mejor esfuerzo - Bronce - prioridades 0 o 3
    Es el valor de prioridad que recibe todo el tráfico en sistemas que no aplican QoS.
La mayor parte de los dispositivos wireless de primera marca disponibles en le mercado actualmente implementan WMM, y por lo tanto permiten implementar calidad de servicio en la red inalámbrica.

Tenés alguna información adicional que quieras compartir....?
Bienvenido!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

19 de abril de 2008

Elementos básicos de QoS

El avance progresivo de las redes convergentes ha hecho que nuestras redes de datos brinden soporte de conectividad a tráfico con requerimientos de performance muy diferentes: VoIP, videoconferencias, navegación web, transacciones sobre bases de datos, sistemas de soporte de la operación de la empresa, etc. Cada uno de estos tipos de tráfico tiene requerimientos diferentes de ancho de banda, condiciones diferentes de delay, pérdida de paquetes, etc.
Poder dar respuesta a diferentes requerimientos de performance sobre una misma infraestructura de red supone la implementación de Calidad de Servicio (QoS).
La implementación de QoS requiere varias tareas:
  • Clasificación del tráfico.
    Proceso que permite dividir el tráfico de la red en diferentes categorías, cada una de las cuáles requiere un tratramiento diferente.
  • Marcado del tráfico.
    Proceso por el que se identifica cada trama de acuerdo a una clase o categoría de modo que los dispositivos de la red puedan reconocer a qué clase pertenece y operar en consecuencia.
  • Administración de la congestión del tráfico.
    En función de la clasificación del tráfico se da diferente tratamiento a cada flujo d datos para asegurar que el tráfico perteneciente a aquellas clases que requieren menor delay sea reenviado antes que el tráfico que no es sensible al delay.
  • Control de la congestión del tráfico.
    En caso de congestión del tráfico de la red es posible optar por un descarte selectivo de paquetes (de clases de menor precedencia), para preservar el tráfico de las clases de alta prioridad.
  • Implementación de políticas de tráfico.
    Un problema a resolver son las ráfagas de tráfico que desbordan el ancho de banda reservado para una clase, poniendo en riesgo la integridad de la red. La implementación de policing traffic permite indicar a las interfaces que deben descartar el tráfico excedente de un determinado ancho de banda asignado.
  • Implementación de traffic shaping.
    Una opción para manejar las ráfagas de tráfico excedentes es indicar al dispositivo que haga buffer de esas ráfagas antes de descartar el tráfico.
  • Mecanismos de mejora de la eficiencia del enlace.
    Permiten mejorar la performance de los enlaces.
Para la implementación QoS, Cisco IOS brinda 4 posibilidades diferentes:
  • Configuración por CLI.
    Permite configurar manualmente interfaz por interfaz las opciones de QoS.
    Es un método poco escalable.
  • Configuración por MQC.
    Permite una configuración modular de QoS a partir de la definición de clases y políticas.
    Es la opción para la configuración detallada de QoS en dispositivos Cisco IOS en la actualidad.
  • AutoQoS VoIP.
    Permite de modo simple y rápido configurar requerimientos de QoS en redes que implementan VoIP.
  • AutoQoS Enterprise.
    Implementión que en base a la operación de NBAR detecta hasta 10 tipos diferentes de tráfico que atraviesan enlaces WAN. Disponible a partir de Cisco IOS 12.3(7)T.
Entre las herramientas que ofrece Cisco IOS para la implementación de QoS utilizando MQC, se cuenta con:
  • Clasificación de tráfico:
    ACL
    NBAR.
  • Marcado de tráfico:
    DSCP
    IP Precedence.
    CoS (802.1p
    , ATM, EXP-MPLS, CLP).
  • Administración de congestión:
    FIFO
    PQ
    RR
    WRR
    CQ
    WFQ
    CBWFQ
    LLQ
  • Control de congestión:RED
    WRED
  • Policing:
    CAR
    1Rate/1Bucket.
    1Rate/2Bucket.
    2Rate/2Bucket.
  • Shapping:
    Average.
    Peak
    FRTS
  • Eficiencia de enlaces:Compresión de payload (Predictor, Stacker).
    Compresión de encabezados (cRTP; TCP).
    Fragmentation.
    Interleaving.
Enlaces de utilidad en el sitio de Cisco:
Tenés alguna información adicional que quieras compartir....?
Bienvenido!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

16 de diciembre de 2007

Introduciendo el uso de NBAR

Network-Based Application Recorgnition (NBAR) es un feature incluido en Cisco IOS a partir de su versión 12.0, que agrega habilidades de clasificación de tráfico a la insfraestructura de la red.
Es un motor de clasificación de tráfico que reconoce una amplia variedad de aplicaciones, incluyendo aquellas que utilizan asignación dinámica de puertos TCP o UDP. Esto permite aplicar servicios específicos a las aplicaciones que se reconocen. Es como tener un analizador de tráfico incorporado en nuestra imagen de Cisco IOS. De esta manera nuestos dispositivos ya no sólo pueden operar sobre información de los encabezados de capa 3 y 4, sino que ahora pueden extender su poder de análisis hasta capa 7.
A partir de IOS 12.3, las habilidades de clasificación de tráfico de NBAR merced a la posibilidad de utilizar PDLM (Packet Description Language Module) para extender estas prestaciones. Cisco regularmente lanza nuevos módulos PDLM para nuevas aplicaciones. La lista de PDLM puede ser consultada en la página web de Cisco.
¿Cómo se utiliza NBAR?
NBAR ha sido diseñado como una aplicación para el reconocimiento de tráfico en la red con el propósito de implementar QoS, sin embargo, es posible darle un sinnúmero de aplicaciones adicionale con el propósito de controlar el tráfico con objetivos de seguridad o solamente remover el tráfico indeseable en un determinado enlace.
En este sentido una de las prestaciones más interesantes de NBAR es la posibilidad de identificar campos específicos en un paquete http, tales como una URL específica o ciertos clientes web.
En general, se puede utilizar NBAR para identificar cualquier tráfico decapa de aplicación para el que NBAR tenga una definición en sus módulos. La tabla de protocolos soportados por NBAR puede ser consultada aquí.
Hay algunas limitaciones para la implementación de NBAR: No se puede aplicar en túneles o interfaces encriptadas, tampoco puede operar con flujos de tráfico asimétricos o analizar tráfico https. Para su operación requiere habilitar previamente CEF.
¿Cómo se configura NBAR?
NBAR es simplemente una aplicación para identificación y marcado de tráfico. Para mostrar su implementación desarrollaré un ejemplo en el que se utiliza NBAR para filtrar tráfico http a una URL específica utilizando ACL, sin embargo, con las debidas variantes, este mismo procedimiento se puede aplicar a partir del paso 5 para implementar otro tipo de políticas:
  • Asegúrese de que en el dispositivo se encuentra habilitado CEF.

    Router(config)#ip cef
  • Cree una clase para identificar el tráfico que se desea clasificar y marcas. En este caso y a fines de ejemplo definiré una clase llamada "descarte" que clasifica toda URL de http que contenga un programa nombrado "readme.exe".

    Router(config)#class-map descarte
    Router(config-cmap)#match protocol http url "*readme.exe*"


    Los asteriscos indican que se desea detectar cualquier URL que contenga el texto "readme.exe" sin importar lo que lo precede o siga.

  • Genere una política para marcar el tráfico que se ha clasificado en el paso anterior. Para esto lo marcaremos con un valor de DSCP igual a 1:

    Router(config)#policy-map trafico_indeseable
    Router(config-pmap)#class descarte
    Router(config-pmap)#set ip dscp 1

  • Configure NBAR de modo que inicie el proceso de descubrimiento de tráfico para todos los protocolos conocidos en una interfaz en particular. En el caso del ejemplo, esta tarea se debe realizar en la interfaz a través de la cual ingresa al dispositivo el tráfico que se desea clasificar y marcar para luego filtrarlo.

    Router(config)#interface serial 0/0/0
    Router(config-if)#ip nbar protocol-discovery

    Si se desea realizar una tarea semejante sobre tráfico que ingresa a través de otra interfaz, NBAR deberá ser activado en esa interfaz.

  • Ahora es necesario aplicar la política que hemos definido antes, a la interfaz en la que ingresa el tráfico que se desea marcar.

    Router(config-if)#service-policy input trafico_indeseable

    De este modo se ha definido un procedimiento de monitoreo y marcación de tráfico indeseable. Este tipo de tráfico será marcado con un valor de DSCP igual a 1. Ahora procederemos a filtrarlo sobre el enlace que deseamos preservar, utilizando una ACL.
  • Cree una lista de control de acceso que deniegue el tráfico marcado:

    Router(config)#access-list 110 deny ip any any dscp 1
    Router(config)#access-list 110 permit ip any any

  • A continuación sólo resta aplicar esa lista de acceso a la interfaz elegida para filtrar el tráfico:

    Router(config)#interface fastethernet 0/0
    Router(config-if)#ip access-group 110 out
NBAR es una potente herramienta de monitoreo de tráfico que ya viene instalada en nuestros routers Cisco IOS desde la versión 12.0. Sólo es necesario familiarizarnos con ella y comenzar a implementarla para aprovechar todo su potencial.
Tengamos en cuenta que con procedimientos como este, al filtrado tradicional de ACLs utilizando criterios de capa 3 y 4, podemos ahora agregar la posibilidad de filtrar tráfico en función de información de capa 7.
Información adicional
¿Tenés algún tip para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

22 de enero de 2007

Control del tráfico no deseado utilizando CAR

Muchas de nuestras redes se encuentran hoy "enfermas" de tráfico innecesario, tráfico que no responde a los objetivos de negocio de la empresa y que muchas veces afecta de modo directo la disponibilidad de recursos para la administración del tráfico crítico de la red. Este tráfico "no deseado" puede ser administrado utilizando CAR.

Una situación habitual es la que se provoca cuando un usuario se encuentra "bajando" información de un sitio web (un archivo de gran tramaño, video, música, etc.). Este tráfico puede afectar seriamente el desenvolvimiento normal de la red, o lo que es peor, hacer inaccesible en algún momento los servidores de producción.

CAR (Committed Access Rate) es un método que permite adminsitrar el tráfico no deseado de modo de asegurarnos que no afecte el tráfico propio de la operación de la red. Hay que tener en cuenta algunas consideraciones previas:

  • CAR solamente afecta el trafico IP. No opera sobre el tráfico no-IP.
  • Para utilizar CAR es necesario habilitar CEF en el router.
  • Esencialmente, CAR controla el ancho de banda que puede ocupar cierta tipo de tráfico, que es definido a través de una ACL.
  • CAR puede referirse tanto al tráfico que ingresa, como al que sale a través de la interfaz en la que se aplica CAR.

La implementación de CAR se realiza en 2 pasos sencillos:

  • Creación de una ACL para definir el tráfico que se desea limitar.
  • Utilizar el comando rate-limit, referenciando la ACL anterior en la interfaz más cercana posible al origen del tráfico, para indicar el ancho de banda que se asignará a este tráfico.

Para ver cómo opera esta solución, revisaremos un ejemplo:

Supongamos una red corporativa que une una casa central con sucursales. Una de esas sucursales (que tiene asignada la subred 10.10.20/24) está conectada utilizando una línea punto a punto de 128 Kb, lo que se ha mostrado eficiente para permitir trabajar con la aplicación desarrollada para la operación de la empresa. Ahora bien, se le acaba de dar acceso a la navegación web de Internet a esta sucursal a través de este enlace de 128 Kb, lo que ha afectado notoriamente la performace de la aplicación de trabajo que se encontraba corriendo. El acceso a Internet se da a través del enlace que posee la Casa Central.

Aún cuando la navegación de Internet es una herramienta conveniente en la sucursal en cuestión, está afectando negativamente la performace de la aplicación de producción.

Para controlar esta situación implementaremos CAR en el router de la casa central. El primer paso s definir el tráfico que se desea limitar n el router de casa central, utlizando una ACL. Siguiendo nuestro ejemplo:

Router(config)#access-list 110 permit tcp any eq www 10.10.20.0 0.0.0.255

En este caso estamos definiendo un filtro que seleccionará todo el tráfico originado en cualquier web server de Internet que tenga como destino un nodo de la subred 10.10.20/24 (la sucursal en cuestión).

El próximo paso es implementar el comando rate-limit en la interfaz que conecta a la sucursal:

Router(config)#interface serial0/0
Router(config)#rate-limit output access-group 110 50000 10000 20000 conform-action transmit exceed-action drop

Este comando aplica un límite de uso de ancho de banda en esta interfaz, en función de la selección de tráfico que realiza la lista de acceso 110. Está aplicada sobre el tráfico saliente a través de la interfaz (outup) porque lo estamos aplicando en el router de casa central, de modo de limitar el tráfico no deseado lo más cerca posible de su origen y evitar que afecte el uso del enlace WAN en cuestión.

Las cifras 50000, 10000 y 20000 establecen los límites (en bits por segundo) que se aplicarán al tráfico seleccionado por la ACL. La primera cifra (50000) indica la tasa de transmisión que se asigna para este tráfico. La segunda cifra (10000), el tamaño reservado para una ráfaga de datos. La tercera (20000) indica el tamaño máximo permitido para una ráfaga. En la medida en que el tráfico se ajusta a estos parámetros de requerimiento de ancho de banda disponible, será transmitido (conform-actio transmit).

Si el tráficoi excediera estos parámetros de ancho de banda, será descartado por el router (exceed-action drop).

Sintetizando. La configuración propuesta sobre la interfaz que conecta hacia la sucursal en cuestión hará que el tráfico web que está causando dificultades quede acotado y no pueda consumir más de 50 kbps de los 128 kbps del enlace.

Es preciso tener en cuenta que CAR limita todo y sólo aquel tráfico que se indica en la ACL.

Tenés alguna información o referencia adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta

10 de noviembre de 2006

¿Qué es AutoQos?

Con el avance progresivo de las redes convergentes, y particularmente de algunos servicios como los de telefonía y video sobre IP (CoIP comunicaciones sobre IP) se ha introducido un concepto que es cada día más generalizado: Calidad de Servicio (QoS).

Paralelamente, y como ya nos tiene acostumbrados, Cisco marcha a la vanguardia de la introducción de estas nuevas tecnologías y propuestas. Cisco IOS implementa hoy varios métodos diferentes de implementación de QoS, tantos y tan complejos como para que se haya dedicado libros completos solamente al tema.

Pues bien, Cisco ha desarrollado una nueva forma de QoS denominada AutoQoS y que tiene como propósito facilitarle al Administrador de la red el seteo básico de los atributos de QoS.

Revisemos primero lo básico
QoS ofrece entre otros, estos beneficios:

  • Prioriza el tráfico que es sensible al delay; por ejemplo, para asegurarnos de que el tráfico de voz no sea afectado por un delay excesivo se le da prioridad al momento de reenviarlo.
  • Prioriza tráfico de modo tal que las aplicaciones no-críticas para la operación de la empresa no ralenticen o entorpezcan el tráfico que corresponde a aplicacíones críticas para el negocio de la empresa.
  • Prioriza tráfico para asegurar que tráfico indeseable en la red no sobrecargue el uso de ancho de banda.
  • Preservar el ancho de banda dilatando el reenvío de información no crítica para la empresa.

En dispositivos Cisco IOS se puede configurar QoS de diferentes modos. Las 4 opciones principales son:

  • Configurar QoS manualmente creando listas de acceso para identificar tráfico que luego es controlado con comandos específicos de QoS.
  • Utilizar el QoS Wizard de SDM (Security Device Manager) de Cisco para crear políticas QoS predefinidas que pueden ser editadas más tarde.
  • Utilizar AutoQoS para crear políticas basadas en el flujo de tráfico en tiempo real a través del router o switch.
  • Utilizar AutoQos para crear políticas predefinidas para el flujo de tráfico de VoIP a través de los dispositivos Cisco IOS.

Los beneficios de AutoQoS
AutoQoS se encuentra disponible en los routers Cisco IOS desde la serie 2600 hasta la serie 7200 y también en la mayoría de los routers Cisco que utilizan versiones de IOS 12.2(15)T y posteriores. AutoQoS ofrece los siguientes beneficios:

  • No requiere una comprensión avanzada de QoS del mismo modo que si se desea configurar desde la línea de comandos.
  • Se pueden modificar las políticas de QoS y reutilizarlas, del mismo modo que si se tratara de un template.
  • Se ahorra mucho tiempo de configuración.

Antes de ejecutar los comandos AutoQoS, se debe habilitar CEF utilizando el comando

Router(config)#ip cef

Adicionalmente se requiere la configuración de la declaración de ancho de banda en las interfaces ya que AutoQoS utiliza esta información cuando se configuran limitaciones de ancho de banda por protocolo para ser priorizados.

Router(config)#interface serial0/0
Router(config-if)#bandwidth 2000000

Si se modifica la configuración de este parámetro una vez que se activó AutoQoS, será necesario reiniciar AutoQoS. También es necesario tener presente no configurar AutoQoS en modo configuración global, sino en las interfaces.

Configuración de AutoQoS
Su configuración es muy simple y fácil, lo verdaderamente complicado es comprender qué es lo que se está configurando, modificar la configuración si es necesario, y probar lo hecho para ver si funciona como se esperaba. A modo de ejemplo configuremos AutoQoS para VoIP.

AutoQoS para VoIP opera sobre cierto tipo de interfaces. El ejemplo más simple es su activación en un enlace E1 punto a punto entre las interfaces seriales de 2 routers que utilizan este enlace para enviar tráfico de VoIP.

Para configurar AutoQoS, la secuencia de comandos en la interfaz que hace de origen del tráfico que deseamos controlar es:

Router(config)#interface serial0/0
Router(config-if)#auto qos voip

Con ese solo comando, Cisco IOS automáticamente genera una serie de comandos de configuración que se pueden verificar utilizando show running-config:

class-map match-any AutoQoS-VoIP-Remark
.match ip dscp ef
.match ip dscp cs3
.match ip dscp af31
class-map match-any AutoQoS-VoIP-Control-UnTrust
.match access-group name AutoQoS-VoIP-Control
class-map match-any AutoQoS-VoIP-RTP-UnTrust
.match protocol rtp audio
.match access-group name AutoQoS-VoIP-RTCP
!
!
policy-map AutoQoS-Policy-UnTrust
.class AutoQoS-VoIP-RTP-UnTrust
..priority percent 70
..set dscp ef
.class AutoQoS-VoIP-Control-UnTrust
..bandwidth percent 5
..set dscp af31
.class AutoQoS-VoIP-Remark
..set dscp default
.class class-default
..fair-queue
!

interface Serial0/0
.auto qos voip
.service-policy output AutoQoS-Policy-UnTrust
!
ip access-list extended AutoQoS-VoIP-Control
.permit tcp any any eq 1720
.permit tcp any any range 11000 11999
.permit udp any any eq 2427
.permit tcp any any eq 2428
.permit tcp any any range 2000 2002
.permit udp any any eq 1719
.permit udp any any eq 5060
ip access-list extended AutoQoS-VoIP-RTCP
.permit udp any any range 16384 32767


Calma... no es el objeto de este artículo analizar estas modificaciones :)
Si deseás comprenderlas, sugiero estudiar en serio QoS. Simplemente pretende que tomemos conciencia de lo que quise decir al afirmar que la configución de AutoQoS es fácil, y que lo complejo es comprender lo que se está haciendo y mucho más modificar este configuración.

Algunos elementos básicos para comprender lo que está haciendo:

  • Las listas de acceso definen cierto tipo de tráfico.
  • Los class-maps convierten ese tráfico en clases. El comando identifica el tráfico que debe colocar en cada clase a través de la lista de acceso.
  • El policy-map asigna prioridades a las clases.
  • Ese policy-map está aplicado a la interface, para afectar el tráfico que sale a través de ella.

Este mismo procedimiento debe aplicarse en la interfaz del otro extremo del enlace, Es altamente recomendable implementar primero este comando en un laboratorio de prueba, antes de utilizarlo en la red en producción.

Ir A la información sobre la Guía

Recursos en línea:

¿Tenés alguna información adicional para aportar en este tema....?
Perfecto!!!! agregá un comentario con el detalle.
Muchas gracias.
Oscar Gerometta