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 comentarios:

  1. Sobre las qos, se habla siempre de la clasificaion. marcado, etc. Pero funciona cuando hay congestión. Pero sino hay congestion funciona la cola de hardware, pero ¿como trata la cola de hardware el trafico? ¿Lo trata todo por el igual? ¿Si lo trata todo por el igual no hay riesgo de jitter en caso de que haya voz ip?

    ResponderBorrar
    Respuestas
    1. Este es un punto clave.
      A respecto:
      1. Si no hay congestión de la interfaz, la implementación de QoS no entra en consideración y todo el tráfico va directamente a la colo de hardware.
      2. La cola de hardware utiliza un algoritmo FIFO, o lo que es lo mismo, no realiza priorización de tráfico.
      3. El riesgo de jitter en este caso se concreta en 2 situaciones: cuando el ancho de banda de la interfaz es muy bajo (menor de 700 Kbps) o cuando la cola de harware es muy grande.
      Ambos se solucionan por configuración: en enlaces de bajo ancho de banda utilizando fragmentación e intercalado, en el otro caso, reduciendo el tamaño de la cola de hardware.

      Borrar

Gracias por tu comentario.
En este blog los comentarios están moderados, por lo que su publicación está pendiente hasta la revisión del mismo.