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.
- 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.
- 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
RRWRR
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.
Tenés alguna información adicional que quieras compartir....?
Bienvenido!!!! agregá un comentario con el detalle.
Muchas gracias.Oscar Gerometta
Bienvenido!!!! agregá un comentario con el detalle.
Muchas gracias.Oscar Gerometta
voy a seguir al tanto de tu blog, es necesario que lleve una certifacion en cisco CCNA,para poder aumentar mis posibilidades laborales
ResponderBorrarUna cosa que se suele hacer es configura la cola de máxima prioridad asignandoles un ancho de banda por ejemplo 2Mb y se hace un drop para descartar el exceso para que no se coma todo el ancho de banda. El resto de colas se marca el tráfico pero no se les asigna esa máxima prioridad ¿En caso de que el tráfico multimedia sobrepase el ancho de banda asignado con priority y se necesite mandar tráfico oro o plata? ¿Que se haría con exceso de tráfico multimedia? ¿Se descarta, se encola ..?
ResponderBorrarEn primer lugar, solo puede haber una cola de máxima prioridad, ya que de lo contrario no sería máxima, sino compartida. El resto de las colas de tráfico tienen ancho de banda reservado y el excedente se comparte. Por lo tanto, si el tráfico que está asignado a colas de ancho de banda compartido excede la asignación, se enviará en la medida en que las otras colas no estén utilizando la reserva que se les asignó.
BorrarAhora bien, en Cisco, el comando "priority" se utiliza para definir la cola de máxima prioridad, con si se asigna ancho de banda con priority, eso actúa como reserva y como límite.
Es decir que si asigno ancho de banda con priority en caso de superar el límite que he puesto. se descartará aunque haya ancho de banda sobrante.Por ejemplo en un enlace de ethernet de 10 Mb si yo pongo 2 Mb de priority se descartará aunque no este usando el enlace en esos momentos para nada más y tenga 8Mb libres.
ResponderBorrarExactamente.
BorrarEl comando "priority" en IOS reserva y limita el ancho de banda. Si hay tráfico excedente se descartará.
Oscar, me parece que el comando priority lo que hace es reservar en caso de congestion un porcentaje o una catidad de kb. Si el ancho de banda no se esta utilizando va a utilizar mas de lo que nosotros le asignamos. Al menos ese fue el resultado de un lab que tuve que hacer hace poco.
ResponderBorrarCristian
BorrarCualquier mecanismo de QoS entra en funcionamiento cuando la interfaz comienza a recibir más tráfico del que puede reenviar. Es la explicación que se me ocurre para el laboratorio que mencionás.
Por lo demás, una de las funciones del comando priority es precisamente limitar el uso del ancho de banda a un máximo porque de lo contrario podría provocar estrangulamiento en las sesiones que corren en otras colas de memoria.
La referencia la tienes en este documento que compara los comandos priority y bandwidth: http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-packet-marking/10100-priorityvsbw.html#summaryofdifferences
gracias Oscar por la aclaracion..en donde no puedo lograr hacer funcionar el comando priority es en una interfaz tunnnel..hasta donde entiendo en las interfaces tunnel hay que aplicarlo de manera "heredada" osea creando las clases, y luego una politica (child) que haga referencia a dichas clase. Y luego una politica superior que haga un shape del trafico total y que contenga a la politica "child". Pero asi y todo no le da prioridad a la ACL que le puse..es muy interesante todo esto de QoS pero me esta volviendo loco jaja
ResponderBorrarCristian
BorrarEste instructivo puede servirte para la implementación de QoS en interfaces túnel: http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/10106-qos-tunnel.html
No pierdas de perspectiva que el efecto de estas configuraciones también depende de la versión de IOS que estés implementado.
Oscar, le hago una consulta, si el proveedor configura en la intefaz lan del cliente calidad de servicio y una de las police la configura como class-default.
ResponderBorrarPero el cliente no configuro ninguna politica de QoS, todo el trafico va a matchear con la police de class-default que configuro el proveedor? o solo en caso de congestion va a matchear con esa police? gracias y saludos Oscar.
Javier
BorrarNo me queda muy claro el planteo, ya que por lo que dices el proveedor es el que configura la interfaz LAN del dispositivo del cliente, es decir, el proveedor es el que tiene gestión de ese dispositivo, y en consecuencia no habría configuración de parte del cliente.
Pero para despejar alguna duda que creo adivinar:
1. Las configuraciones de calidad de servicio aplican únicamente a la interfaz a la que están asociadas. La configuración se realiza interfaz por interfaz. Si sólo se configura una interfaz en la ruta, sólo tiene efecto en esa interfaz.
2. Las interfaces tienen una cola de hardware y una cola de memoria. Las políticas aplican a partir de que la cola de hardware está congestionada.
3. Las clases (class) clasifican tráfico, las políticas (policies) aplican herramientas a esas clases.
Una política no se configura como class default, si puede aplicarse a esa clase, que es la clase por defecto.
¿Cuales pueden ser los motivos por los que puede haber descartes en una interfaz más a allá de la saturación? Por ejemplo si una interfaz fasethernet no está limitada y tiene un tráfico máximo de 50 MB suponiendo que no haya por esa interfaz más que tráfico bronce si hay descartes no sería por saturación.
ResponderBorrarGracias
Para poder revisar esta situación sería necesario tener mayores precisiones y conocer mejor la implementación.
ResponderBorrar¿qué significa que hay descartes?
Una cosa es que las estadísticas muestren tráfico "dropeado" y otra es que se bloquee tráfico.
Si hay tráfico "dropeado", lo primero es revisar esas estadísticas ya que deben mostrar el motivo de esa acción; puede tratarse por ejemplo de descarte por errores de CRC lo que manifestaría un potencialmente un problema de cableado.
Si se trata de tráfico bloqueado, entonces puede que se deba a alguna política de seguridad implementada, como puede ser una ACL.
Por lo tanto también hay que ver qué es lo que se toma como referencia para hacer este diagnóstico: ¿estadísticas de la interfaz por CLI, o estadísticas de algún sistema de monitoreo?
Gracias. No, Oscar me refería a haciendo un show interface en la interface conectada a internet se ven drops en out.
ResponderBorrarInput queue: 0/75/17/0 (size/max/drops/flushes); Total output drops: 312000
Ese contador es un acumulativo de paquetes descartados desde la última puesta a cero de los contadores de la interfaz.
BorrarSi sigues hacia abajo encuentras las contadores de los últimos 5 minutos de operación, y allí tendrás un detalle de los motivos de ese descarte cuando son debidos a la operación de la red y no, por ejemplo, a una ACL.
http://librosnetworking.blogspot.com.ar/2017/12/comandos-show-interfaces-serial.html