Cisco QoS v1

Configuración y manejo de calidad de servicio en enrutadores Cisco

Configuración de calidad de servicio (QoS) en enrutadores Cisco

Autor: Gianpietro Lavado Chiarella Página 2 10/10/04

Índice Tema Página Introducción................................................................................................4

Descripción de QoS en Cisco....................................................................4

1. ¿Cuándo se requiere configurar calidad de servicio? 2. Requisitos en el enrutador 3. Modelos de calidad de servicio 4. Mecanismos de calidad de servicio 5. Introducción a MQC

Clasificación y marcación de paquetes..................................................9

1. Clasificación de tráfico 2. Marcación de paquetes 3. Ejemplos de configuración

Manejo de la congestión..........................................................................15

1. Introducción al encolamiento 2. Arquitectura de colas en Cisco 3. Métodos básicos de encolamiento 4. Métodos avanzados de encolamiento 5. Otras técnicas de encolamiento 6. Conclusiones sobre encolamiento 7. Ejemplos de configuración

Evitamiento de la congestión....................................................................34

1. Congestión y TCP 2. RED : Random Early Detection 3. WRED : Weighted Random Early Detection 4. Ejemplos de configuración

Control de tráfico: Policy & Shaping…………………………………………40

1. Introducción al control de tráfico 2. Implementación de Traffic Policing 3. Implementación de Traffic Shaping 4. Ejemplos de configuración

Mecanismos de eficiencia en enlaces WAN………………………………50

1. Introducción a los mecanismos de eficiencia 2. Compresión de datos (payload)



3. Compresión de cabeceras 4. Fragmentación de tramas 5. Ejemplos de configuración

Resolución de problemas………………………………………………………57

1. Comandos útiles 2. Documentos útiles



Introducción. Este documento cubre los aspectos principales de la implementación de calidad de servicio en enrutadores Cisco. Los métodos acá descritos son los que se utilizan en la actualidad y contienen ejemplos de configuración, así como aplicaciones a casos reales, recomendaciones y resolución de problemas. La información está basada en documentos oficiales de Cisco (Implementing Cisco Quality of Service v2.0; CCNP Student Guide v3.0 module II; cisco.com) y en la experiencia obtenida en laboratorios y redes en producción. A lo largo del documento se utilizarán algunos términos técnicos en inglés, para facilitar su comprensión. Descripción de QoS en Cisco.

1. ¿Cuándo se requiere configurar calidad de servicio?

La configuración de calidad de servicio no es siempre necesaria, incluso realizar configuraciones complejas cuando no se requiere podría degradar la performance deseada. Las siguientes son consideradas las tres principales causas por las cuales se configura QoS: a) Ancho de banda escaso: Las aplicaciones que cursan la red ocupan

más ancho de banda del que se dispone, generando congestión. Los mecanismos que veremos para contrarrestar este problema son: priorización de tráfico importante (encolamiento avanzado) y compresión de paquetes.

b) Alta latencia (delay): La cantidad de equipos o procesos que tienen que atravesar los paquetes aumentan la latencia, influyendo negativamente en la calidad de ciertas aplicaciones sensibles a ésta, como la voz o el video. La latencia total en un enlace es la suma de los siguientes componentes: - Tiempo de procesamiento: Tiempo generado por el procesador del

equipo, su arquitectura interna, el modo de conmutación de paquetes y configuraciones complejas en las interfaces.

- Tiempo de serialización: El tiempo que toma colocar los paquetes en la interfaz de salida, el cual depende del ancho de banda.

- Encolamiento: El tiempo que un paquete permanece en la cola de salida del enrutador.

- Propagación: El tiempo que lleva transmitir un paquete según el medio.



Los mecanismos que estudiaremos para contrarrestar el problema de latencia son: priorización de tráfico importante (encolamiento avanzado), compresión de paquetes y fragmentación.

c) Pérdida o descarte de paquetes: Aparte de las pérdidas que puedan encontrarse en el medio físico, existen descartes de paquetes que los enrutadores realizan agresivamente cuando una interfaz se encuentra saturada, perjudicando sobretodo a las sesiones TCP. Los mecanismos de que estudiaremos para contrarrestar este problema son los descartes aleatorios (RED) y las políticas de tráfico (police/shape).

Estos tres problemas pueden existir hasta cierto grado dependiendo de los requerimientos de la aplicación. Por ejemplo, para contar con una buena calidad de voz en un enlace se requiere: - Latencia: menor o igual a 150ms* en un sentido. - Variación en latencia (jitter): menor o igual a 30ms en un sentido. - Ancho de banda fijo garantizado dependiendo del codec. - Pérdida de paquetes: menor o igual al 1%.

* Este valor es el recomendado por Cisco para una muy buena calidad de voz, sin embargo, otros proveedores recomiendan hasta 400ms en un sentido como un nivel bueno, de otra forma las comunicaciones satelitales de voz sobre IP no serían posibles.

Similar para el video, pero este tráfico contiene ráfagas. Por esta razón no se necesita garantizar un ancho de banda fijo sino un mínimo, igual al stream + 20%.

VOZ VIDEO



2. Requisitos en el enrutador Para poder configurar calidad de servicio en un enrutador, es necesario contar con el IOS correcto. Las técnicas más utilizadas actualmente para implementar QoS (CBWFQ/LLQ) están disponibles desde las primeras versiones de 12.2 en features como IP/SP/Enterprise y hasta para plataformas simples como la serie 1600; sin embargo es recomendable consultar previamente en la página Web de Cisco (herramienta Software Advisor).

3. Modelos de calidad de servicio

En general, existen tres modelos de implementación de calidad de servicio, los cuales definen y clasifican los mecanismos que se van desarrollando. a) Modelo mejor-esfuerzo (best-effort): es el modo por defecto. No

existe diferenciación entre un tipo de tráfico y otro; no hay garantía en la entrega de paquetes ni ancho de banda reservado. Fuera de las desventajas es altamente escalable y fácil de implementar; es muy utilizado actualmente para tráfico de Internet.

b) Modelo de servicios integrados (IntServ/Hard QoS): permite definir todos los parámetros de calidad de servicio deseados con exactitud de extremo a extremo antes de iniciar la transmisión de datos. El ancho de banda y la latencia están garantizados y reservados de antemano, sin embargo, esta reserva hace que el ancho de banda no utilizado no pueda ser usado por otras aplicaciones y se desperdicie. El mecanismo que emplea este modelo en Cisco se llama RSVP (en combinación con LLQ y WRED); RSVP no será tratado en este documento.

c) Modelo de servicios diferenciados (DiffServ/Soft QoS): permite clasificar el tráfico y brindar a cada clase los requerimientos de calidad de servicio que necesite. Los recursos de QoS solicitados no están 100% garantizados pues se van obteniendo conforme el tráfico va cursando la red, sin embargo este modelo es más utilizado que IntServ actualmente, por su alta escalabilidad y la cantidad de niveles de calidad de servicio que ofrece. Además, la reserva de ancho de banda es dinámica. Las técnicas de calidad de servicio descritas en el siguiente punto están basadas en este modelo.



4. Mecanismos de calidad de servicio Cisco ofrece los siguientes mecanismos para implementar calidad de servicio en redes IP: a) Clasificación y marcado de paquetes: dado que los paquetes IP

contienen ciertas características, es posible agruparlos en clases para aplicar en ellos diferentes políticas de calidad de servicio y/o marcarlos para luego identificarlos en un proceso de QoS posterior.

b) Manejo de la congestión: La clasificación de paquetes permite repartir el tráfico en distintas colas (según la técnica de encolamiento utilizada) para que cada tipo de tráfico sea tratado en forma distinta, según su prioridad. Existen principalmente las siguientes técnicas de encolamiento:

- FIFO (first-in first-out) - Priority Queuing - Custom Queuing - Weighted Fair Queuing - Class-based Weighted Fair Queuing - Low-latency Queuing

c) Evitamiento de la congestión: Este mecanismo permite evitar la

saturación de la cola de salida de las interfaces, de manera que no haya necesidad de que el enrutador encole los paquetes. Lo hace mediante el descarte temprano de paquetes de baja prioridad (Random Early Detection / Weighted Random Early Detection).

d) Políticas de tráfico: permiten limitar la tasa de transferencia de paquetes para descartar, encolar o marcar el tráfico de exceso.

e) Compresión y fragmentación: sirven para hacer que los enlaces WAN sean más eficientes, haciendo un mejor uso del ancho de banda disponible.

5. Introducción a MQC

Los mecanismos anteriormente mencionados cuentan con dos métodos de implementación. Modular QoS CLI (MQC) es uno de ellos, ampliamente utilizado para implementar calidad de servicio en enrutadores Cisco. El método MQC consta de 3 pasos:

1) Definir clases: haciendo uso de las sentencias ‘class-map’ 2) Establecer políticas: haciendo uso de las sentencias ‘policy-map’



3) Aplicar las políticas: con el comando ‘service-policy output’ en general aplicado a interfaces.

Por ejemplo:

El otro método de implementación de calidad de servicio es AutoQos, el cual es relativamente nuevo y no está desarrollado al 100% a la fecha. Simplemente aplicando el comando ‘autoqos’, el enrutador se toma unos minutos para hacer análisis de tráfico y aplicar automáticamente las políticas de calidad de servicio. AutoQoS configura desde métodos de encolamiento hasta fragmentación en interfaces. Se debe tener cuidado con el uso de este comando, pues el equipo puede llegar a hacer cambios no deseados como modificar el protocolo de encapsulación de las interfaces.

class-map match-any VOZ match access-group 10 match ip precedence 5 class-map match-any FTP match access-group 101 class-map match-all SQL match access-group 110 match access-group 111

policy-map VOZ_POL class VOZ priority 100 set ip dscp cs5 policy-map DATOS class FTP police 128000 1280 0… class SQL bandwidth 100

interface ethernet0 service-policy output VOZ_POL interface serial0.1 frame-relay interface-dlci 1 service-policy output VOZ_POL interface serial0.3 frame-relay interface-dlci 3 service-policy output DATOS

CLASE VOZ

CLASE FTP

CLASE SQL

POLÍTICA 1: BW y Delay garantizados

POLÍTICA 2: Mejor esfuerzo, BW limitado

Interfase Ethernet0

Int. Serial0.1

Int. Serial0.3

1 2 3



Clasificación y marcación de paquetes

Actualmente MQC es el método preferido para clasificar y marcar paquetes para implementar calidad de servicio. En versiones anteriores esto se solía hacer con route-maps. 1. Clasificación de tráfico

Existen muchas formas de clasificar tráfico, pero antes veamos la configuración: class-map [ match-any/match-all ] [nombre de clase] match [not] [condición 1] … match [not] [condición n]

match-any: si el tráfico cumple una sola sentencia entra en la clase match-all: el tráfico debe cumplir con todas las sentencias para clasificarse

not: parámetro opcional que niega la condición Luego se ‘llama’ esta clase desde un policy-map, según MQC. A continuación las principales condiciones para clasificar tráfico: a) Access-lists: Consiste en crear listas de control de acceso para

clasificar tipos de tráfico. Comando: match access-group XXX

b) IP precedence: Clasifica el tráfico según el valor de los 3 primeros bits del byte TOS en los paquetes IP, pudiéndose definir desde uno hasta cuatro valores. Comando: match ip precedence [valor 1] [valor 2] [valor 3] [valor 4]

c) IP DSCP: Clasifica el tráfico de acuerdo al valor de los 6 primeros bits del byte TOS en los paquetes IP. Se pueden definir hasta 8 valores. Comando: match ip dscp [valor 1] [valor 2] [valor 3] [valor 4]

VALOR DECIMAL VALOR BINARIO NOMBRE

0 1 2 3 4 5 6

7

000 001 010 011 100 101 110 111

routine priority

immediate flash

flash-override critical internet network



*Para los valores class-selector (cs) el valor en decimal se simplifica asemejándose al de IP Precedence.

d) Protocolo: se puede clasificar según protocolos de capa 3 ó más.

Pero además, con la herramienta NBAR, se dispone de una clasificación más avanzada permitiendo al enrutador que descubra más protocolos dinámicamente, inspeccionando las capas superiores (4 a 7). Comando: match protocol [protocolo] NBAR: Para configurar esta herramienta se tener en cuenta lo siguiente: - No es soportada en interfaces que utilizan túneles o encriptación. - Requiere IP CEF (Cisco Express Forwarding). - No es posible inspeccionar paquetes IP fragmentados. NBAR permite disponer de una extensa lista de aplicaciones que podemos colocar como condiciones de clasificación. Por defecto vienen muchas aplicaciones detectables según el IOS, sin necesidad de configurar NBAR, pero se pueden cargar aplicaciones adicionales aplicando NBAR, bajando los PDLM (Packet Description Language Module) de Cisco, y luego cargándolos en la flash. (más información: www.cisco.com/cgi-bin/tablebuild.pl/pdlm)

Luego, para aplicar la PDLM bajada, se usa el comando ‘ip nbar pdlm’.

Cabe resaltar que NBAR contiene una MIB que utiliza SNMP para reportar estadísticas, los protocolos más usados, notificaciones, etc.

VALOR DECIMAL* VALOR BINARIO NOMBRE

0 1 2 3 4 5 6 7 46 10 12 14 18 20 22 26 28 30 34 36 38

000000 001000 010000 011000 100000 101000 110000 111000 101110 001010 001100 001110 010010 010100 010110 011010 011100 011110 100010 100100 100110

Default cs1 cs2 cs3 cs4 cs5 cs6 cs7 ef

af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43



desde la versión 12.2(15)T. Para configurar NBAR en una interfaz se utiliza el comando:

ip nbar protocol-discovery (requiere ip cef) Este comando permite descubrir y tomar estadísticas de todos los

protocolos que ingresan o egresan la interfaz. Algunos comandos útiles para NBAR:

- match protocol [protocolo] Clasifica según protocolos. Se usa dentro del class-map. - show ip nbar protocol-discovery [opciones] Muestra estadísticas de los protocolos que NBAR está descubriendo

en la interfaz. - ip nbar port-map [protocolo] [tcp/udp] [puerto adicional] Permite configurar hasta 16 puertos adicionales para que

identifiquen a ciertos protocolos. Se aplica en modo de configuración global. Por ejemplo:

ip nbar port-map http tcp 80 8080 para clasificar http no sólo por el puerto 80 sino por el 8080 también.

e) Jerarquía de clases: es posible anidar una clase a otra, con el objetivo de agrupar varias clases en una sola. Comando: match class-map [nombre]

f) CoS : se clasifican los paquetes por el valor de CoS (Class of Service) en interfaces que usan encapsulación 802.1q o ISL. El valor va de 0 a 7 y se pueden definir hasta 4 valores. Comando: match cos [valor 1] [valor 2] [valor 3] [valor 4]

g) Interfaz de entrada: se clasifican los paquetes según la interfaz por la que entraron al enrutador. Comando: match input-interface [interface]

h) Dirección MAC: se clasifica tráfico por dirección MAC origen o destino. Comando: match [source-address/destination-address] mac [MAC]

i) Puertos UDP: el tráfico RTP (Real time protocol) puede ser clasificado según el rango de puertos UDP especificado. Comando: match ip rtp [puerto udp inferior] [número total de puertos]

j) Todo el tráfico: para clasificar todo el tráfico que atraviese el enrutador. Comando: match any

Otras formas de clasificar incluyen: QoS group (variante de DSCP), MPLS experimental bits, Frame-Relay DE bit.



2. Marcación de paquetes

La marcación de paquetes se realiza generalmente por clase dentro de un policy-map. Sirve para que otros equipos en la red reciban los paquetes ya marcados y puedan aplicar las políticas de calidad de servicio respectivas. Para marcar por clase, se requiere IP CEF. La configuración es la siguiente:

ip cef policy-map [nombre de política] class [nombre de clase] set [ip precedence/ip dscp/cos/etc...] [valor] Luego se debe asociar la política a una interfaz de entrada o salida con el comando service-policy output [nombre de política]. Hay otras formas vigentes de marcar paquetes fuera de MQC (policy-maps). Para tráfico de voz, es posible marcar los paquetes en los dial-peers. Las principales formas de marcar paquetes son: a) IP precedence: Marca los primeros 3 bits del byte TOS de los

paquetes IP con el valor especificado en número (0 a 7) o nombre (critical, priority, etc.) Comando: set ip precedence [valor]

b) CoS : se marcan los paquetes con un valor de CoS (Class of Service) especificado, aplicable en interfaces LAN que usan encapsulación 802.1q o ISL. El valor va de 0 a 7. Comando: set cos [valor]

c) IP DSCP: marca los 6 primeros bits del byte TOS en los paquetes IP según el valor especificado por número (0 a 63) o nombre (af11, cs1, ef, etc.) Comando: set ip dscp [valor]

d) En los dial-peers (voz): marca los paquetes de voz cuando estos mapean un dial-peer. Se aplica dentro de la configuración del dial-peer voip, por ejemplo, dependiendo de la versión de IOS:

dial-peer voice 1 voip dial-peer voice 1 voip ip precedence 5 ó ip qos dscp cs5 media

ip qos dscp cs5 signaling

Otras formas de marcar incluyen: QoS group (variante de DSCP), MPLS experimental bits, Frame-Relay DE bit y ATM CLP bit.



3. Ejemplos de configuración

a) Ejemplo de clasificación y marcación en clases

La red 192.168.2.0 contiene servidores que deben tener mayor prioridad que los de la red 192.168.3.0 cuando sus datos son transmitidos hacia la red de usuario (192.168.1.0) Marcamos los paquetes en los enrutadores de borde según las direcciones IP de los hosts, así evitamos la configuración de listas de control de acceso en el enrutador central (Router_C). Nota: El funcionamiento del comando bandwidth será visto más adelante. ROUTER_A class-map match-any FILESQL match access-group 10 policy-map DATOS class FILESQL set ip precedence 5 interface serial0 service-policy output DATOS access-list 10 permit host 192.168.2.2 access-list 10 permit host 192.168.2.3

ROUTER_B class-map match-any FILESQL match access-group 10 policy-map DATOS class FILESQL set ip precedence interface serial0 service-policy output DATOS access-list 10 permit host 192.168.3.2 access-list 10 permit host 192.168.3.3

ROUTER_C class-map match-any FILESQL_HIGH match ip precedence 5 class-map match-any FILESQL_LOW match ip precedence 1 policy-map DATOS class FILESQL_HIGH bandwidth 256 class FILESQL_LOW bandwidth 128 interface serial 1/1 service-policy output DATOS

ROUTER A

ROUTER B

192.168.2.0

192.168.3.0

192.168.1.0

ROUTER C

.2 .3

.2 .3

s0

s0

s1/1

ROUTER_D



b) Ejemplo de clasificación y marcación en dial-peers

El enrutador ROUTER_A marca, clasifica y prioriza sus propios paquetes de voz hacia el enrutador ROUTER_B. Igualmente para el tráfico de voz de ROUTER_B hacia ROUTER_A. La marcación es hecha en el dial-peer; si la llamada realizada utiliza dicho dial-peer, entonces los paquetes de voz (y de señalización de llamada) se marcan con precedence 5, luego se clasifican en el class-map VOZ y se priorizan en el policy-map POLIVOZ. El funcionamiento del comando priority será visto más adelante.

ROUTER_A class-map match-any VOZ match ip precedence 5 policy-map POLIVOZ class VOZ priority 15 dial-peer voice 1 voip destination-pattern 2… ip qos dscp cs5 media ip qos dscp cs5 signaling interface serial0 service-policy output POLIVOZ

ROUTER_B class-map match-any VOZ match ip precedence 5 policy-map POLIVOZ class VOZ priority 15 dial-peer voice 1 voip destination-pattern 1… ip qos dscp cs5 media ip qos dscp cs5 signaling interface serial0 service-policy output POLIVOZ

ROUTER_A ROUTER_B

FxS s0

s0 FxS

1234 2345



Manejo de la congestión

1. Introducción al encolamiento (queuing) El encolamiento de paquetes es natural en una interfaz congestionada, es por esto que existen diferentes algoritmos de encolamiento que nos permiten controlar la congestión, priorizando un tipo de tráfico sobre otro. La principal causa de la congestión en las interfaces es la diferencia de velocidad que existe entre ellas, los siguientes dibujos hablan por sí solos: Dependiendo del tipo de aplicaciones que se estén manejando, se debe determinar qué algoritmo de encolamiento será el más conveniente. Las implementaciones propietarias de Cisco están basadas o son una mezcla de los siguientes algoritmos generales de manejo de colas: • FIFO (First-in First-out)

- Una sola cola, primer paquete que entra es el primero que sale. - Es el algoritmo más simple.

• Priority Queuing (PQ) - Múltiples colas, una de ellas tiene alta prioridad. - Los paquetes de la cola de alta prioridad se transmiten hasta que se

vacíe la cola, luego se prosigue con las demás colas. - Transmisiones continuas en la cola de alta prioridad pueden hacer que

las demás colas se queden sin transmitir (queue starving). • Round Robin (RR)

- Múltiples colas, se transmite un paquete por cada una.

100Mbps 64Kbps

flujo de tráfico

512Kbps flujo de tráfico

512Kbps

512Kbps 512Kbps



- No hay priorización. - Generalmente utilizado en switches LAN.

• Weighted Round Robin (WRR) - Múltiples colas, se asigna un peso a cada una. - La priorización es posible, el número máximo de bytes transmitidos por

cola depende del peso de cada una de ellas. - Si quedan algunos bytes libres para transmitir, y viene un paquete que

supera esa cantidad de bytes, se transmite el paquete completo no se ofrece un control estricto de la cantidad de información enviada.

• Déficit Round Robin (DRR) - Similar a WRR, resolviendo el problema de la cantidad de información. - Si existe un exceso de bytes transmitidos en una ronda, dicho exceso

se resta en la siguiente ronda. 2. Arquitectura de colas en Cisco

La arquitectura de encolamiento en Cisco está dividida en dos: - Cola de Hardware: propia de la interfaz, utiliza siempre FIFO para que

sus controladores sean capaces de transmitir los paquetes uno a uno. - Cola de Software: configurada por el usuario según los algoritmos

disponibles en la plataforma (WFQ, FIFO, CBWFQ, LLQ, etc)

COLA SW

COLA HW (FIFO)

INTERFASE

CLASIFICACIÓN

ENVÍO O DESCARTE

COLA 1

IP IP IP IP

PROGRAMADOR(SCHEDULER)

ENVÍO O DESCARTE

COLA 2

ENVÍO O DESCARTE COLA n

.

.

.

ESTRUCTURA TÍPICA DE COLA DE SOFTWARE



Así, tenemos típicamente cuatro etapas en la cola de SW: • Clasificación: Divide el tráfico según criterio establecido por el

algoritmo o por el usuario. • Envío o descarte: Decide si encolar o descartar el tráfico según el

algoritmo o mediante herramientas adicionales (p.e. RED) • Colas: Encola los paquetes esperando a que el programador los

transmita. • Programador (Scheduler): Transmite los paquetes hacia la cola de

hardware decidiendo si alguna cola tiene prioridad sobre otra según el algoritmo configurado.

Notas adicionales sobre la arquitectura de colas: La cola de software es solamente utilizada cuando existe congestión. Por lo general, el indicador de congestión es la cola de hardware; cuando ésta está llena, significa que la interfaz está congestionada. Sin embargo, en interfaces lógicas, como por ejemplo en subinterfaces Frame-Relay, la cola de hardware no es un buen indicador de congestión, pues ésta incluye a las demás subinterfaces. En el caso Frame-Relay en particular, los indicadores son los bits FECN y BECN, propios del protocolo, cuyos valores se obtienen en interacción con el Switch Frame-Relay (DCE); en enrutadores Cisco esta funcionalidad está siempre habilitada, a menos que se configure frame-relay Traffic Shaping (FRTS), donde se pueden configurar los parámetros de tráfico y congestión manualmente. Es posible variar el tamaño de la cola de hardware (tx-ring), pero hay que tener en cuenta las siguientes situaciones extremas: • Cola HW muy larga

- La cantidad de paquetes encolados como FIFO es mayor, pudiendo haber problemas de latencia en la serialización de paquetes.

- El algoritmo de encolamiento utilizado en la cola de SW tardará más tiempo en ser aplicado, perdiendo así su utilidad.

• Cola HW muy corta - Los paquetes serán forzados a ingresar a la cola de SW todo el tiempo,

esto puede causar una pobre utilización de la interfaz pues algunos algoritmos de SW tienen una multiplexación compleja la cual por ratos se demora en transmitir.

- Suponiendo que la cola de HW es de 1 byte, la cola de SW entregará los paquetes uno por uno, en lugar de muchos al mismo tiempo. Dado que esta entrega es controlada por el CPU, su utilización se verá incrementada.



Por defecto, el enrutador determinará el tamaño ideal de la cola de HW basándose en el ancho de banda configurado en la interfaz (comando bandwidth), el cual normalmente es el correcto; las interfaces más rápidas tendrán colas de hardware más largas pues producen menos latencia que las interfaces lentas. En general, el tamaño de la cola de HW debe ser suficientemente corto como para evitar una latencia de serialización muy alta (causada por el encolamiento FIFO) y suficientemente largo como para evitar demasiados descartes de paquetes (perjudicando flujos TCP).

3. Métodos básicos de encolamiento

a) First-in First-out (FIFO) La cola de software tipo FIFO no tiene clasificación ni priorización, dado que envía los paquetes en el orden en el cual los recibe. Está configurado por defecto en interfaces de 2Mbps o más, donde generalmente no es necesaria una técnica de encolamiento compleja por su rapidez de serialización. La arquitectura es la siguiente:

Utiliza el método de descarte por defecto llamado Tail Drop. Este método descarta todos los paquetes que van llegando cuando la cola está llena.

Ventajas de FIFO:

- Simple y rápido (una sola cola). - Soportado en todas las plataformas y IOS. Desventajas de FIFO: - Puede causar que un solo flujo agresivo de datos monopolice la

utilización de la cola (starvation).

COLA DE SOFTWARE FIFO

COLA HW

(FIFO)FIFO SCHEDULER

UNA SOLA COLA

TAIL DROP

1 2

3

UNA SOLA CLASE

1 2 3



- Puede causar latencia variable (jitter) si la cola se llena con altas ráfagas de paquetes.

Configuración de FIFO: Se aplica el comando ‘no fair-queue’ en la interfaz global.

b) Weighted Fair Queue (WFQ) WFQ es una técnica de encolamiento automático, pues se permite que el enrutador calcule a qué tráfico darle mayor prioridad. Esto lo hace separando el tráfico en flujos o conversaciones y asignándole pesos inversamente proporcionales a su volumen de tráfico. El flujo con mayor peso tendrá mayor ancho de banda disponible. Normalmente está configurado por defecto en interfaces de menos de 2Mbps. La arquitectura es como sigue:

COLA DE SOFTWARE WEIGHTED FAIR-QUEUE

.

.

.

COLA HW

(FIFO)

WFQ SCHEDULER

COLA 1WFQ DROP

C B

A

¿FLUJO 1?

B C A COLA 2WFQ DROP

¿FLUJO 2?

COLA n WFQ DROP

¿FLUJO n?



El proceso de encolamiento WFQ, puede dividirse en tres etapas según el gráfico: - Etapa de clasificación automática: WFQ agrupa los paquetes en

diferentes flujos para asignar una sola cola a cada uno de ellos. Los criterios de agrupación son: Dirección IP origen, dirección IP destino, puerto TCP/UDP origen, puerto TCP/UDP destino, protocolo de transporte y campo TOS. Todos estos parámetros pasan por un proceso de codificación (hash) que define el identificador de la cola a la que serán direccionados. Existe un número máximo de colas que WFQ puede armar, este valor es configurable y debe ser mayor al número de flujos esperados en la comunicación, para evitar que dos flujos distintos se tengan que poner en la misma cola, disminuyendo así el ancho de banda disponible para cada uno. Existen además 8 colas reservadas para paquetes de sistema y hasta 1000 colas para RSVP. El valor por defecto de colas para WFQ depende del ancho de banda en la interfaz, definido por el comando bandwidth:

- Etapa de encolamiento o descarte: cuando las colas de WFQ se

aproximan al valor límite de paquetes que éstas pueden aceptar, se empieza a descartar paquetes del flujo más agresivo. Este descarte temprano empieza cuando se sobrepasa el valor definido por el congestive discard threshold (CDT). El límite de paquetes que puede aceptar todo el sistema WFQ (todas las colas al mismo tiempo) está definido por el hold-queue out limit. Pasado este límite, cualquier paquete entrante genera un descarte. El tiempo estimado que demorará un paquete en ser transmitido por la cola WFQ depende de su tamaño y es calculado en esta etapa, pues influye en las decisiones de descarte. En adelante llamaremos a este tiempo Finish Time (FT). La tabla que se muestra a continuación resume cuándo un paquete se descarta o se envía a la cola.

Ancho de banda Número de colas

B ≤ 64Kbps 64K < B ≤ 128K 128K < B ≤ 256K 256K < B ≤ 512K

B ≥ 512Kbps

16 32 64 128 256



N = Número de paquetes en la cola al llegar un nuevo paquete. HQO = Hold-queue out limit CDT = Congestive discard threshold FT = Finish Time

+ Paquete nuevo tiene el peor FT del conjunto de paquetes en la cola. * Se descarta el paquete con el peor FT de la cola y se encola el nuevo paquete. - Etapa de programación (Scheduling): En esta etapa se define el

orden en el cual los paquetes de los diferentes flujos o colas se enviarán a la interfaz física. Este orden sólo depende del Finish Time, el cual, como se indicó anteriormente, es el tiempo que demorará un paquete en ser transmitido, calculado en base a su tamaño y el ancho de banda de la interfaz. Veamos el siguiente ejemplo, donde 2 flujos están entregando paquetes a las colas A y B respectivamente, partiendo del ‘tiempo 0’:

A1: Llega en el tiempo T + 0ms y tomaría 100ms transmitirlo A2: Llega en el tiempo T + 60ms y tomaría 20ms transmitirlo. Nota: El hecho de que el tiempo en que llega el paquete A2 sea menor que el tiempo estimado para transmitir A1 indica claramente que la interfaz de entrada es más rápida que la de salida. A3: Llega en el tiempo T + 70ms y tomaría 10ms transmitirlo. B1: Llega en el tiempo T + 50ms y tomaría 300ms transmitirlo B2: Llega en el tiempo T + 100ms y tomaría 300ms transmitirlo.

El Finish Time para cada paquete es igual al tiempo que llevaría transmitirlo mas el FT del paquete anterior de la misma cola:

A1 (100ms)

A2 (20ms)

A3 (10ms)

B1 (300ms)

B2 (300ms)

t 0ms

100 70 60 50

N > HQO? N > CDT? Peor FT? +

NO NO SI SI NO

NO SI X X SI

X NO SI NO SI

ACCIÓN

A LA COLA A LA COLA DESCARTE DESCARTE DESCARTE*



FT(Pn) = TTx(Pn) + FT(Pn-1) o si la cola está vacía (no existe un paquete anterior): FT(Pn) = TTx(Pn) + Tactual Así, en el ejemplo anterior, el FT para cada paquete sería:

FTA1 = 100 + 0 = 100ms FTA2 = 20 + 100 = 120ms FTA3 = 10 + 120 = 130ms FTB1 = 300 + 50 = 350ms FTB2 = 300 + 300 = 650ms

Esto demuestra que en WFQ, un paquete pequeño tendrá preferencia sobre uno grande, sin importar que el grande haya llegado primero. En versiones de IOS anteriores a la 12.3T, se toma en cuenta el valor de IP precedence del paquete para el cálculo del Finish Time de la siguiente manera: FT(Pn) = TTx(Pn)/(IP prec.+1) + FT(Pn-1) o si la cola está vacía (no existe un paquete anterior): FT(Pn) = TTx(Pn) /(IP prec.+1) + Tactual

Supongamos que en el ejemplo anterior los paquetes de la cola B vengan marcados con un valor de 5 en el IP Precedence, y los de A con un valor de 0. El nuevo orden de transmisión sería:

FTA1 = 100/1 + 0 = 100ms FTA2 = 20/1 + 100 = 120ms FTA3 = 10/1 + 120 = 130ms FTB1 = 300/5 + 50 = 110ms FTB2 = 300/5 + 110 = 160ms

Ventajas de WFQ:

- Simple de configurar. - Soportado en todas las plataformas y IOS - Garantiza ancho de banda para todos los flujos y descarta paquetes

en flujos agresivos.

B1 A1 A3 A2 B2

B1 A1 A3 A2 B2



Desventajas de WFQ: - Puede causar que múltiples flujos terminen en una sola cola, si el

número de flujos es mucho mayor que el número de colas disponibles. Esta probabilidad es mayor en enlaces de más lata velocidad.

- No es posible clasificar el tráfico manualmente. - No es posible garantizar valores de ancho de banda fijos. Configuración de WFQ: Se aplica el siguiente comando en la interfaz global.- fair-queue [cdt] [ número de colas] [ colas para rsvp]

Para variar el hold-queue out limit se usa el comando hold-queue [valor] out. Su valor por defecto es 1000 pero se puede bajar en circunstancias en las cuales WFQ está consumiendo muchos buffers.

4. Métodos avanzados de encolamiento

a) Class-based Weighted Fair Queuing (CBWFQ) CBWFQ es una extensión de WFQ, que permite al usuario hacer la clasificación de tráfico manualmente utilizando MQC. De esta manera, cada clase tendrá asignada una cola y es posible garantizar un ancho de banda fijo a cada una de ellas. La arquitectura es la siguiente:

COLA DE SW CLASS-BASED WEIGHTED FAIR-QUEUE

.

.

.

PD = Por defecto

COLA HW

(FIFO)

CBWFQ SCHEDULER (≈WRR)

COLA 1TAIL DROP

C B

¿CLASE 1?

B C A COLA 2 TAIL DROP

¿CLASE 2?

COLA PD TAIL DROP

¿CLASE PD?

A



El proceso de encolamiento CBWFQ, puede también dividirse en tres etapas según el gráfico: - Etapa de clasificación: La clasificación en CBWFQ es totalmente

configurable por el usuario con el uso de MQC, método descrito en el capítulo anterior.

- Etapa de encolamiento o descarte: Se utiliza la técnica de descarte por defecto, Tail Drop. Con esta técnica, se decartan los paquetes que llegan a la cola cuando alcanzó su límite (queue size). Todas las clases tienen una cola FIFO asignada, sólo a la clase por defecto (class-default) se le puede configurar una cola WFQ.

- Etapa de programación (Scheduling): En esta etapa se ordenan los paquetes de acuerdo al peso configurado por el usuario para cada cola. Los pesos se configuran con el comando bandwidth, pudiendo éste ser expresado en kbps, porcentaje del ancho de banda total o porcentaje del ancho de banda disponible. Además, según el ancho de banda configurado para la clase, el programador extraerá más o menos paquetes de su cola, utilizando un método similar a Weighted Round Robin (WRR).

El peso para cada clase es calculado dividiendo el ancho de banda de la interfaz (o subinterfaz/clase frame-relay) entre el ancho de banda configurado en la clase, por lo que las clases con menor ancho de banda asignado se enviarán antes que los demás a la cola física. El equipo sólo permite asignar a las clases el 75% del ancho de banda de la interfaz, pues el resto normalmente es usado para SNMP, LMI, protocolos de ruteo, etc. Se puede cambiar este valor límite pero no es muy recomendable, además, el ancho de banda no utilizado por el 25% reservado es distribuido entre las clases de acuerdo a sus pesos. Es preferible configurar siempre el ancho de banda de las interfaces pues este parámetro es utilizado para cálculos de CBWFQ.

BANDWIDTH 64

135

24 1

7

3 6 8

QUEUE SIZE 4

CLASE A

CLASE B

CBWFQ SCHEDULER

BANDWIDTH 128

246 8



Ventajas de CBWFQ: - Configuración modular (MQC). - Ancho de banda garantizable, es posible priorizar un tráfico sobre

otro. - Los pesos garantizan un mínimo de ancho de banda para las clases

con menor prioridad. - El ancho de banda no utilizado se reparte entre las otras clases. Desventajas de CBWFQ: - No se garantiza una baja latencia (delay) para ninguna clase, por lo

que el tráfico de voz podría sufrir degradación. Configuración de CBWFQ:

Siguiendo el procedimiento de configuración de MQC, primero se configuran las clases.- class-map [ match-any/match-all ] [nombre de clase] match [not] [condición 1] … match [not] [condición n] Luego se definen las políticas.-

policy-map [nombre de política] class [nombre de clase] (hasta 64 clases) bandwidth [Kbps / percent / remaining percent] [valor %] queue-limit [número de paquetes] (tail-drop) class class-default (opcional, tráfico no clasificado) bandwidth [Kbps / percent / remaining percent] [valor %] queue-limit [número de paquetes] (tail-drop) - o - fair-queue

Finalmente se aplica la política a la interfaz: interface x service-policy output [nombre de política]

b) Low-latency Queuing (LLQ)

Este mecanismo añade una cola de alta prioridad a CBWFQ, la cual sí garantiza una baja latencia. Esta implementación permite utilizar la cola de alta prioridad para el tráfico de tipo tiempo real y las colas de menor prioridad para el resto de tráfico utilizando CBWFQ. La arquitectura de LLQ se muestra a continuación:



La cola de prioridad se distingue por tener el comando priority en lugar del comando bandwidth utilizado en CBWFQ. Si se configuran varias clases como tráfico de alta prioridad, todas las clases entrarán a la misma cola. El funcionamiento es muy similar a CBWFQ, sólo que la cola de prioridad debe vaciarse por completo para luego transmitir las demás. A manera de evitar el problema de que las colas de baja prioridad se queden sin transmitir, el ancho de banda configurado en la cola de alta prioridad limita el tráfico en todo momento (no sólo en momentos de congestión). Otra buena costumbre para evitar este problema es no configurar más ancho de banda del necesario para alta prioridad. El descarte de paquetes en la cola de alta prioridad es muy agresivo, característico de CAR (Commited Access Rate). Esto quiere decir que los paquetes que sobrepasan el ancho de banda configurado, son descartados y no encolados; por esta razón, para el tráfico de voz, se

COLA DE SOFTWARE LLQ – BAJA PRIORIDAD (CBWFQ)

.

.

.

PD = Por defecto

COLA HW

(FIFO)

CBWFQ SCHEDULER (≈WRR)

COLA 1TAIL DROP

¿CLASE 1?

COLA 2 TAIL DROP

¿CLASE 2?

COLA PD TAIL DROP

¿CLASE PD?

COLA DE SOFTWARE LLQ – ALTA PRIORIDAD

AP = Alta Prioridad

COLA DE PRIORIDAD (FIFO) CAR

¿CLASE AP?

C B

A

B C A



debe conocer exactamente cuánto consumirá cada canal y cuántas llamadas simultáneas pueden llegar a existir. Se recomienda que esta cola se use sólo para tráfico de voz, ya que su capacidad utilizada es de comportamiento constante y se puede conocer con precisión, a diferencia del tráfico de video. En general es sólo útil para tráficos de tipo CBR (Constant Bit Rate) ver gráfico pág.4 Al igual que con CBWFQ, sólo es posible repartir el 75% del ancho de banda disponible entre las clases La siguiente figura nos ayuda a comprender el comportamiento:

Ventajas de LLQ - Tiene todas las ventajas de CBWFQ. - Ancho de banda y baja latencia garantizable para tráficos de

tiempo real. - Previene que la cola de alta prioridad monopolice la utilización de la

capacidad disponible, fijándole un límite. Configuración de LLQ:

Se configura y aplica igual que CBWFQ, la diferencia es que la clase en la cual se requiere alta prioridad, debe ser configurada de la siguiente forma:

class [nombre de clase] priority [Kbps] [burst] burst tamaño de ráfaga en bytes (opcional) - o - priority percent [%] [burst]

2 4 1 CBWFQ SCHEDULER

BANDWIDTH 128

2 4 6 8

PRIORITY 32

X Y Z

PQRS

PQ R S

68 3 XYZ

BANDWIDTH 64

1 3 5 7



c) CBWFQ y LLQ en Frame-Relay No es posible utilizar Frame-Relay Traffic Shaping (FRTS) y aplicar una política de CBWFQ/LLQ en la misma interfaz. En este caso, se debe aplicar la política en el Frame-Relay map-class y luego vincular este map-class a la interfaz, subinterfaz o dlci. Sin embargo, en la serie 7500, tampoco es posible aplicar una política en el Frame-Relay map-class. Estas plataformas trabajan con Distributed Traffic Shaping (DTS), donde se debe aplicar la política en la interfaz o subinterfaz. Esta política debe tener la función de encolamiento pero además la de shaping, configurándola de manera jerárquica. Las opciones y configuraciones de Traffic Shaping disponibles (FRTS, GTS y DTS) se detallarán más adelante en el capítulo de Políticas de tráfico.

5. Otras técnicas de encolamiento

Las técnicas descritas a continuación nacieron en versiones más viejas de IOS y no se utilizan mucho en la actualidad, algunas de ellas han sido desplazadas por CBWFQ/LLQ. a) Priority Queuing (PQ)

Consiste en configurar hasta cuatro colas, cada una con una prioridad distinta: High, Medium, Normal y Low. Primero se transmiten todos los paquetes dentro de la cola High, luego los paquetes de la cola Medium y así sucesivamente. Comandos de configuración. En configuración global, se tienen las siguientes opciones:

priority-list [#lista] protocol [ip/ipx/decnet…] [high/medium/normal/low] [detalle: list[# ACL], tcp[puerto], etc]

(asocia un protocolo a una cola, se puede detallar el puerto TCP/UDP, ACL, etc) priority-list [#lista] interface [interf.] [high/medium/normal/low] (asocia el tráfico saliente de una interfaz a una cola) priority-list [#lista] default [high, medium, normal, low] (asocia el tráfico no especificado a una cola) priority-list [#lista] queue-limit [high-limit, medium-limit, normal-limit, low-limit] (define el tamaño de cada cola en número máximo de paquetes) Para aplicar en la interfaz: priority-group [#lista] Ventaja: Ofrece un servicio más dedicado a la cola de alta prioridad.



Desventaja: Un tráfico constante en la cola de más alta prioridad puede hacer que las demás colas dejen de transmitir por un tiempo prolongado (starving).

b) Custom Queuing (CQ) Permite configurar hasta 16 colas y asignar pesos a cada una de ellas, especificando el tamaño de las colas y número máximo de bytes que pueden transmitir. Comandos de configuración. En configuración global, se tienen las siguientes opciones:

queue-list [#lista] protocol [ip/ipx/decnet…] [número de cola] [detalle: list[# ACL], tcp[puerto], etc]

(asocia un protocolo a una cola, se puede detallar el puerto TCP/UDP, ACL, etc) queue-list [#lista] interface [interf.] [número de cola] (asocia el tráfico saliente de una interfaz a una cola) queue-list [#lista] default [número de cola] (asocia el tráfico no especificado a una cola) queue-list [#lista] queue [número de cola] limit [límite en # de paquetes] (define el tamaño de cada cola en número máximo de paquetes) queue-list [#lista] queue [número de cola] byte-count [límite en bytes] (define el número de bytes que puede transmitir esta cola) Para aplicar en la interfaz: custom-queue-list [#lista] Desventaja: Si quedan algunos bytes libres para transmitir, y viene un paquete que supera esa cantidad de bytes, se transmite el paquete completo no se ofrece un control estricto de la cantidad de información enviada.

c) PVC queuing (Frame Relay PIPQ) Similar a Priority Queuing pero a nivel de PVCs. Se asigna uno o más PVCs a una de las 4 colas disponibles (High, Medium, Normal y Low). Se atiende primero a los PVCs en la cola High, luego a los de la cola Médium y así sucesivamente. Comandos de configuración.

En la interfaz global: frame-relay interface-queue priority [High queue-limit/Medium queue-limit

/Normal queue-limit /Low queue-limit ] Se crean clases Frame-Relay en configuración global: map-class frame-relay [nombre] frame-relay interface-queue priority [High/Medium/Normal/Low] Se aplican las clases a los PVC en las subinterfaces: frame-relay interface-dlci [dlci] class [nombre del map-class]



Ventaja: Ofrece un servicio más dedicado a la cola de alta prioridad. Desventaja: Un tráfico constante en los PVCs de más alta prioridad puede hacer que los demás PVCs dejen de transmitir por un tiempo prolongado (starving).

6. Conclusiones sobre encolamiento

La duda que generalmente surge sobre las diferentes técnicas de encolamiento es en qué situaciones utilizar cada una de ellas. Primero debemos fijarnos en el tipo de aplicaciones utilizadas en la red y luego escoger una técnica de encolamiento basándonos en las ventajas y desventajas de cada una. El siguiente gráfico sugiere cuándo utilizar qué técnica:

¿Interface WAN congestionada?

No se necesita otra técnica que FIFO

¿Se requiere un control estricto?

Utilizar Weighted Fair Queuing

¿Aplicaciones sensibles a delay?

Utilizar CBWFQ o Custom Queuing

Utilizar LLQ, PQ o PIPQ

SI

SI

SI

NO

NO

NO



Internet

ROUTER_B

ROUTER_A

ROUTER_C

s0

s0

s0

64Kbps

64Kbps

128Kbps

192.168.2.0

192.168.3.0

192.168.1.0


a) Ejemplo de técnicas de encolamiento básico.

Las redes 192.168.2.0 y 192.168.3.0 utilizan sus enlaces hacia la sede central (ROUTER_A) sólo para consultas periódicas en Internet, las cuales nunca llegan a saturar los enlaces de 64Kbps en ningún sentido. Dado que no existe congestión en estas interfaces, el tipo de encolamiento ideal es FIFO. Por el contrario, el tráfico hacia Internet en la sede central sí llega a saturar el enlace de 128Kbps, tomando en cuenta el tráfico de las remotas. Para esta interfaz el tipo de encolamiento ideal es Weighted Fair-Queue, ya que si bien existe congestión, no es necesario, en este caso, un control estricto del tráfico saliente ni clases de tráfico definidas por el usuario.

ROUTER_A interface serial0 bandwidth 64 fair-queue ROUTER_B interface serial0 bandwidth 64 no fair-queue

ROUTER_C interface serial0 bandwidth 128 no fair-queue



b) Ejemplo de técnicas de encolamiento avanzado.

El enlace entre ROUTER_A y ROUTER_B se congestiona periódicamente debido al tráfico de datos excesivo entre ambas sedes. Este tráfico es generado principalmente por aplicaciones FTP y HTTP, siendo la más importante la primera de ellas. Además, se utilizan 2 canales de voz entre ambas sedes, cada uno de los cuales ocupa 13.3Kbps. Dado que el tráfico de voz requiere una baja latencia garantizada, se utiliza LLQ, definiendo además clases para FTP y HTTP para garantizar más ancho de banda a la primera de ellas.

(Nota: se están obviando configuraciones de marcación de IP precedence en dial-peers)

ROUTER_A class-map match-any VOZ match ip precedence 5 class-map match-any FTP match protocol ftp class-map match-any HTTP match protocol http policy-map POLICOLA class VOZ priority 28 class FTP bandwidth remaining percent 80 class HTTP bandwidth remaining percent 20 interface serial0 bandwidth 128 service-policy output POLICOLA

ROUTER_B class-map match-any VOZ match ip precedence 5 class-map match-any FTP match protocol ftp class-map match-any HTTP match protocol http policy-map POLICOLA class VOZ priority 28 class FTP bandwidth remaining percent 80 class HTTP bandwidth remaining percent 20 interface serial0 bandwidth 128

service-policy output POLICOLA

DISTRIBUCIÓN DEL ANCHO DE BANDA DE LA INTERFAZ WAN. Ancho de banda total : 128Kbps Ancho de banda disponible para LLQ (75%): 128 x 0.75 = 96Kbps Máximo reservado para la voz: 28Kbps Mínimo para FTP: 96 – 28 = 68 x 0.8 = 54.4Kbps Mínimo para HTTP: 68 x 0.2 = 13.6Kbps *Todo el ancho de banda no utilizado del 25% reservado o de cualquier clase será repartido entre FTP y HTTP según sus pesos.

128Kbps

ROUTER_A ROUTER_B

s0 s0



c) Ejemplo de Frame-Relay PIPQ.

La sede central se conecta con sus dos remotas a través de PVCs Frame-Relay. Cada uno de los enlaces a la nube FR es de 512Kbps, esto hace que las remotas no puedan utilizar todo su ancho de banda disponible simultáneamente. La gran mayoría del tráfico en las remotas es de bajada, la red 192.168.3.0 contiene sólo servidores de contingencia que continuamente replican la información de la sede central, sin embargo, la red 192.168.2.0 es una red de usuarios que hacen consultas en línea y descarga de información vital desde la sede central, siendo para ellos muy importante la rapidez de las descargas. Por esta razón, la sede central otorga mayor prioridad de envío de información hacia ROUTER_B, mientras que el tráfico hacia ROUTER_C “puede esperar”.

ROUTER_A interface serial0 bandwidth 512 encapsulation frame-relay frame-relay interface-queue priority 80 20 10 5 interface serial0.110 frame-relay interface-dlci 110 class ALTA interface serial0.220 frame-relay interface-dlci 220 class BAJA map-class frame-relay ALTA frame-relay interface-queue priority high map-class frame-relay BAJA frame-relay interface-queue priority normal

ROUTER_B interface serial0 bandwidth 512 encapsulation frame-relay frame-relay interface-dlci 110

ROUTER_C interface serial0 bandwidth 512 encapsulation frame-relay frame-relay interface-dlci 220

FR

ROUTER_A

ROUTER_B

ROUTER_C

110

220

s0

s0

s0 192.168.1.0

192.168.2.0

192.168.3.0



N

N+1

N+3

N+3

N+7

Tx Rx

ACK

ACK

ACK

N+1 N+2

N

N+1

N+1

N+1

N+1

N+1

N+3

Tx Rx

ACK

ACK

N+3

N+4

ACK

Evitamiento de la congestión

1. Congestión y TCP El comportamiento de los flujos TCP está estrechamente relacionado con la congestión en las interfaces. Primero repasemos algunas características del tráfico de tipo TCP: - El tráfico TCP utiliza confirmaciones de recepción (acknowledgements

– ACKs) para garantizar que un segmento o conjunto de segmentos fue recibido correctamente. El conjunto de segmentos que se pueden transmitir antes de recibir un ACK es llamado tamaño de ventana.

- Al comenzar una sesión TCP, el valor del tamaño de ventana es pequeño, pero este va creciendo exponencialmente a medida que el emisor va recibiendo confirmaciones del receptor. El receptor siempre envía un ACK pidiendo el segmento que espera recibir.

- Cuando un segmento no llega a su destino, el receptor seguirá pidiendo que el emisor le envíe ese segmento mediante ACKs, obligándolo a retransmitir el segmento. Luego de la retransmisión, el emisor baja el tamaño de ventana a la mitad asumiendo que la pérdida se debió a una congestión, para así ajustarse al ancho de banda disponible y tratar de no perder más paquetes. Este comportamiento es llamado Slow Start.

COMPORTAMIENTO TCP SIN PÉRDIDAS

COMPORTAMIENTO TCP CON PÉRDIDAS (SLOW START)



Como vemos, las pérdidas de paquetes afectan a las transferencias TCP. Slow Start es un buen mecanismo para contrarrestar este problema de congestión, pero cuando tenemos muchos flujos TCP simultáneos, todos se ven afectados por las pérdidas de paquetes generadas por congestión. Entonces, muchos de los flujos bajan su tamaño de ventana simultáneamente, resultando en una disminución masiva de la tasa de transferencia, luego todos vuelven a subir al mismo tiempo y así sucesivamente. Este fenómeno se conoce como TCP Global Synchronization. Así, tenemos una estrecha relación entre el mecanismo de descarte y la performance de TCP. En la mayoría de los sistemas de encolamiento el mecanismo será Tail Drop, el cual descarta paquetes agresivamente en momentos de congestión, sin distinción de clase o prioridad, provocando el fenómeno visto en el párrafo anterior. El mecanismo de descarte de WFQ es más sofisticado y “justo” y no perjudica tanto a TCP, sin embargo es limitado en cuanto a la velocidad de enlace o circunstancias donde se puede aplicar. Tail Drop también perjudica a TCP de la siguiente manera: los flujos más agresivos llenarán las colas rápidamente (siguiendo el mecanismo de ajuste de ventana de TCP), por lo que no serán los primeros en descartarse por Tail Drop, causando una rápida y constante congestión. Muchos de los paquetes pequeños o de flujos más frágiles no lograrán ingresar a la cola y serán descartados por Tail Drop (TCP Starvation), mientras que los que logren ingresar a la cola sufrirán una gran latencia pues ésta estará llena por flujos agresivos (TCP Delay).

TCP STARVATION

Tasa máxima (congestión)

Flujo frágil y precedence 5

Flujo agresivo y precedence 0

TCP DELAY

Experimenta una constante congestión Tail Drop

Tasa promedio

Utilización del enlace

Tiempo

COLA



2. RED : Random Early Detection

RED es un mecanismo que descarta paquetes aleatoriamente antes de que la cola se llene, así, evita la congestión y la consecuente activación de Tail Drop. El siguiente gráfico detalla algunos conceptos que definen un perfil RED y su funcionamiento: El descarte aleatorio de RED se da entre cierto rango de tamaño cola por defecto o definido por el usuario. Este descarte temprano permite solucionar el problema de TCP Global Synchronization, haciendo que algunas sesiones TCP empiecen a bajar el tamaño de ventana antes de llegar a la congestión. Después de aplicar RED, el comportamiento de TCP durante la congestión se aprecia en el siguiente gráfico (comparar con gráfico de la página 35): Podemos apreciar que la utilización promedio del enlace aumenta. RED sólo tiene efecto sobre tráficos TCP y se debe aplicar en las interfaces donde se espera que ocurra congestión. La implementación de Cisco para RED se llama Weighted Random Early Detection (WRED) y la veremos a continuación.

Probabilidad de descarte

100 %

10 %

32 40 Ocupación promedio de la cola

Ningún descarte

DescarteRED

Descarte Tail Drop

Tasa máxima (congestión)

Tasa promedio

Utilización del enlace

Tiempo



3. WRED : Weighted Random Early Detection

La idea de WRED es aplicar distintos niveles de RED a diferentes clases de tráfico mediante la configuración de distintos perfiles. Así, se logra evitar la congestión descartando tempranamente y con mayor agresividad el tráfico TCP menos prioritario mientras que se favorece a los demás. Las características principales de WRED: - Se pueden definir varios perfiles RED (distintos rangos de descarte

para aplicar a diferentes clases de tráfico). - La elección del perfil a utilizar se hace según el IP Precedence o

DSCP del paquete IP. - Se puede aplicar WRED en una interfaz, subinterfaz o clase. Generalmente aplicaremos WRED donde tengamos definidas distintas clases de tráfico y el método de descarte por defecto sea Tail Drop. Esto nos lleva a centrarnos a la configuración de WRED en CBWFQ/LLQ (Class-based WRED CB-WRED). El siguiente gráfico muestra la configuración de perfiles de WRED por defecto, los cuales se basan en el valor de IP precedence de cada paquete: El gráfico indica que mientras más alto sea el valor de IP precedence, menor será el rango de descarte aleatorio para dicho tráfico. Así, los tráficos menos prioritarios (IP precedence 0) serán los que se descarten primero, más o menos cuando la cola esté a la mitad (por defecto).

Probabilidad de descarte

100 %

10 %

20 40 Ocupación promedio de la cola

22 24 26 28 30 32 34 37

IP PREC 0 1 2 3 4 5 6 7 RSVP



Configuración de CB-WRED Para habilitar WRED basado en IP precedence con valores por defecto, se aplica el siguiente comando en una clase dentro de una política: random-detect Es posible modificar los perfiles por defecto para ip precedence con el siguiente comando (aplicado en la clase): random-detect precedence [valor] [min] [max] [probabilidad]

(se deben definir tantas entradas como sean necesarias)

donde: min = valor mínimo del rango de descarte aleatorio max = valor máximo del rango de descarte aleatorio 1/probabilidad = probabilidad de descarte en el máximo valor del rango

Para habilitar WRED basado en IP DSCP con valores por defecto (similares a IP precedence), se aplica el siguiente comando en una clase dentro de una política: random-detect dscp-based Es posible modificar los perfiles por defecto para ip dscp con el siguiente comando (aplicado en la clase): random-detect dscp [valor] [min] [max] [probabilidad]

(se deben definir tantas entradas como sean necesarias)

Dado que WRED calcula la utilización promedio de la cola para verificar en qué rango de descarte se encuentra el tráfico, se admiten ráfagas de tráfico que pueden sobrepasar temporalmente el rango definido sin sufrir el descarte aleatorio. La admisión de ráfagas se puede controlar con el siguiente comando: random-detect exponential-weighting-constant [n] Teniendo en cuenta la fórmula de cálculo de utilización de cola: Qprom(t+1) = Qprom(t) x (1-2-n) + Qt x 2-n Para altos valores de ‘n’, WRED admite ráfagas cortas, mientras que para bajos valores, WRED será más sensible a las ráfagas y el descarte será más estricto. El valor por defecto es 9 y funciona bien para la mayoría de escenarios.



VPN 64Kbps


La sede central (ROUTER_A) tiene enlaces dedicados de 96Kbps con sus remotas y un enlace VPN de 64Kbps hacia una extranet (ROUTER_GLCH). Si bien la mayoría del tráfico generado por las remotas termina en la sede central, hay momentos pico en que el tráfico generado por éstas satura la interfaz de salida de ROUTER_A hacia la VPN. El volumen de tráfico es generado por aplicaciones Internet Explorer, Kazaa, pcAnywhere, SQL Server, entre otros. Siendo este tráfico TCP en su mayoría, se aplica CBWRED en ROUTER_A para evitar la congestión en la interfaz, con MQC se clasifica y marca en las remotas.

ROUTER_B y ROUTER_C class-map match-any ALTA match protocol http match protocol sqlserver class-map match-any BAJA match protocol kazaa2 match protocol fasttrack match protocol pcanywhere policy-map MARCAR class ALTA set ip precedence 4 class BAJA set ip precedence 2 class class-default set ip precedence 0

ROUTER_A class-map match-any RED_BAJA match ip precedence 0 class-map match-any RED_NORMAL match ip precedence 2 class-map match-any RED_ALTA match ip precedence 4 policy-map MARCAR class RED_BAJA bandwidth 8 random-detect random-detect precedence 0 20 40 20 class RED_NORMAL bandwidth 8 random-detect random-detect precedence 0 25 40 20 class RED_ALTA bandwidth 32 random-detect random-detect precedence 0 30 40 20

ROUTER_A

ROUTER_B

ROUTER_C ROUTER_GLCH

96Kbps

96Kbps

100%

20 %

20 25 30 40

PERFILES DE WRED PARA ROUTER_A



Control de tráfico: Policy & Shaping

1. Introducción al control de tráfico

El control de tráfico sirve principalmente para limitar la tasa de transferencia de un flujo de datos. Existen dos formas de controlar el tráfico: Traffic Policing y Traffic Shaping. Veamos las características de cada una de ellas: TRAFFIC POLICING - Aplicable en tráfico

entrante o saliente. - El tráfico que excede el

límite es descartado. - Soporta marcación de

paquetes. - Uso bajo de los buffers. - Los descartes aumentan las

retransmisiones TCP.

TRAFFIC SHAPING - Aplicable sólo en tráfico

saliente. - El tráfico que excede el límite es

encolado (mayor latencia) - No soporta marcación de

paquetes. - Uso alto de los buffers. - El encolamiento minimiza las

retransmisiones TCP.

A fin de comprender mejor el funcionamiento y configuración del control de tráfico, debemos tener claro primero los siguientes conceptos.- - CIR (Commited Information Rate): Tasa de transferencia garantizada. - Bc = Tamaño de ráfaga normal. - Tc = Tiempo que durará una ráfaga en ser transmitida. - PIR (Peak Information Rate): Tasa de transferencia máxima. - Be = Tamaño de ráfaga de exceso. Las siguientes fórmulas sirven para calcular cualquiera de estos valores:

Be = (PIR - 1) x Bc CIR

CIR = Bc_ Tc

*Be y Bc en bits



2. Implementación de Traffic Policing Esta herramienta es normalmente utilizada en los siguientes casos: - Fijar una tasa de transferencia máxima para ciertas aplicaciones. - Limitar el ancho de banda de acceso para un usuario dentro de un

enlace de acceso compartido (sub-rate) - Remarcar paquetes que excedan la tasa establecida. Se puede implementar principalmente de dos formas: a) Class-Based Policing

Se utiliza en conjunto con CBWFQ para determinar límites a nivel de clases definidas por usuario. Según el valor de la tasa de transferencia actual se puede tomar la acción de transmitir, descartar o transmitir remarcando el paquete (ip precedence, dscp, de, etc). La configuración básica, en una clase de MQC, es la siguiente: police [CIR] [Bc] [Be] conform-action [action]

exceed-action [action] violate-action [action] donde:

conform-action: la acción que se tomará cuando la tasa de transferencia actual no ha pasado el valor de CIR configurado. Por defecto la acción será transmitir (transmit).

exceed-action: la acción que se tomará cuando la tasa de transferencia actual ha pasado el valor de CIR y está dentro del límite de exceso definido por Be. Por defecto la acción será descartar (drop).

violate-action: la acción que se tomará cuando la tasa de transeferencia actual vaya más allá de los límites de exceso establecidos por Be. Por defecto la acción será descartar (drop).

action: transmit, drop, set-prec-transmit ip precedence, set-dscp-transmit dscp, set-qos-transmit qos-group, set-mpls-exp-transmit mpls-exp, set frde-transmit de (frame-relay, set clp-transmit clp (atm).

Otras formas de configurar Class-Based Policing: police [CIR] [Bc] [PIR] [Be (para PIR)] conform-action [action]

exceed-action [action] violate-action [action]

police cir percent [%] [Bc(ms)] pir percent [%] [Be PIR(ms)] conform-action [action] exceed-action [action]

violate-action [action]

b) Commited Access Rate (CAR) Si bien esta técnica aún está disponible en IOS, ya no se seguirá desarrollando, por lo que Cisco recomienda utilizar Class-Based Policing cuando sea posible.



Se utiliza para definir límites a nivel de interfaces o subinterfaces. Se configura dentro de la interface de la siguiente manera: rate-limit [ìnput/output] [CIR] [Bc] [Be] conform-action [action]

exceed-action [action] violate-action [action] Las acciones configurables son transmit y drop.

3. Implementación de Traffic Shaping

Esta herramienta es normalmente utilizada en los siguientes casos: - Prevenir congestión en redes donde se tienen distintos valores de

ancho de banda en cada acceso. - Regular parámetros en redes Frame-Relay o ATM (p.e CIR, Bc, etc) Se puede implementar principalmente de cuatro formas: a) Generic Traffic Shaping

Permite habilitar traffic-shaping a nivel de interfaces o subinterfaces. Se configura dentro de la interface de la siguiente manera: traffic-shape rate [CIR] [Bc] [Be] Si la interfaz tiene encapsulamiento frame-relay, es posible definir además la tasa de transferencia mínima a la cual se ajustará el tráfico cuando de recibe algún BECN o FECN: traffic-shape adaptive [bit-rate] (actúa al recibir BECNs) traffic-shape fecn-adapt (adicional, para FECNs) También es posible aplicar GTS sólo para cierto tráfico de salida definido con un ACL: traffic-shape group [#ACL] [CIR] [Bc] [Be]

b) Class-based shaping Habilita GTS dentro de una configuración basada en MQC y puede usarse en combinación con CBWFQ y LLQ. Se configura dentro de la clase de la siguiente manera: shape [average/peak] [CIR/percent] [Bc] [Be] La opción ‘average’ es la más recomendada pues transmite a una tasa igual al PIR sólo después de un periodo de poco tráfico, en cambio ‘peak’ transmite a la tasa máxima (PIR) todo el tiempo, produciendo descarte de paquetes si la red está congestionada. La opción ‘peak’ sólo debe usarse cuando sobran recursos en la red y las aplicaciones toleran pérdidas de paquetes ocasionales.



El comando shape max-buffers varía el tamaño de la cola en número de paquetes, de esta forma se puede controlar hasta cuántos paquetes encolará el enrutador antes de descartarlos con tail-drop. El valor por defecto es de 1000 paquetes y usualmente no será necesario modificarlo. Cuando este mecanismo es usado en combinación con CBWFQ, se puede anidar una política a la otra de manera jerárquica como muestra el ejemplo: policy-map BW class trafficA bandwidth percent 50 class trafficB bandwidth percent 10 class trafficC bandwidth percent 15 policy-map SHAPE class trafficT shape average 512000 service-policy BW En la interfaz se aplicaría la política ‘SHAPE’, de esta forma se está repartiendo manualmente el ancho de banda entre los diversos tipos de tráfico y limitando el tráfico total a 512000. Al igual que en GTS, es posible la interacción con los bits FECN y BECN en interfaces frame-relay, emulando así algunos beneficios de FRTS (al final de este capítulo). shape adaptive [bit-rate] (actúa al recibir BECNs) shape fecn-adapt (adicional, para FECNs)

c) Distributed Traffic Shaping

DTS se configura exactamente igual que Class-based shaping, pero está diseñado para enrutadores que utilizan tarjetas VIP, como el modelo 7500 o el 12000, donde se distribuye el procesamiento entre las tarjetas. El modelo 7500 requiere tener habilitado distributed cef, mientras que el modelo 12000 requiere sólo cef.

d) Frame-Relay Traffic Shaping Este mecanismo permite modificar cualquier parámetro de control de tráfico de un PVC frame-relay. Además, puede utilizarse en



conjunto con CBWFQ, LLQ y demás técnicas de encolamiento en la mayoría de las plataformas. La configuración de todos los parámetros de FRTS se aplica dentro de una clase frame-relay creada en el modo de configuración global: map-class frame-relay [nombre] Los parámetros configurables dentro de esta clase varían mucho entre versiones de IOS, a continuación se muestran los más importantes, todos son opcionales:

frame-relay cir [CIR]: define el CIR en bps. frame-relay bc [Bc]: define el Bc en bytes. frame-relay be [Be]: define el Be en bytes. frame-relay mincir [minCIR]: define la tasa mínima de transferencia cuando

se detecta congestión en el PVC. service-policy output [nombre]: permite aplicar CBWFQ o LLQ como

técnicas de encolamiento. [no] frame-relay adaptive shaping [becn/foresight]: habilita o deshabilita

la variación automática de la tasa de transferencia cuando se reciben bits BECN o mensajes ‘foresight’. La tasa de transferencia podrá bajar hasta el mincir.

frame-relay fragment [bytes]: define el tamaño máximo de trama habilitando fragmentación FRF.12.

frame-relay priority-group [#]: habilita PQ como técnica de encolamiento en la clase.

Para activar FRTS es necesario aplicar el siguiente comando en la interfaz global: frame-relay traffic shaping Luego se debe aplicar el map-class en una subinterfaz, interfaz o PVC, teniéndose las siguientes alternativas: frame-relay class [nombre] para interfaces y subinterfaces. class [nombre] para PVCs, aplicado dentro de la configuración del dlci.

Notas importantes sobre FRTS:

- No es aplicable en plataformas 7500. - Las interfaces, subinterfaces o PVCs que no pertenezcan a ninguna

clase en particular tendrán un valor de CIR de 56Kbps por defecto. - Se debe configurar los parámetros de control de tráfico asumiendo

sólo un máximo del 95% del ancho de banda físico disponible, ya que las cabeceras no son tomadas en cuenta.

- Para voz, se recomienda no exceder el 95% del ancho de banda disponible garantizado (CIR) y deshabilitar el ajuste automático del CIR (frame-relay adaptive shaping), desactivando esta opción y/o igualando el minCIR al CIR. De esta forma se garantiza que los



paquetes de voz no sean descartados por saturación. Además, se recomienda hacer que el Bc sea la centésima parte del CIR para evitar grandes ráfagas que quizá no contengan voz y retracen tramas subsiguientes conteniendo voz (Tc = 10ms).

Restricciones en el uso de Traffic-shaping y CBWFQ/LLQ.

Los cuatro tipos de configuración de traffic-shaping no son aceptados por todas las plataformas, sobretodo FRTS, por lo que la forma de aplicación de una política MQC (policy-map) varía. La siguiente tabla detalla las restricciones:

7500/12000 (VIP: DTS)

26xx, 36xx, 7200, etc (no VIP: FRTS, CBS,

etc)

Interfaz global

Subinterfaz Frame-Relay

PVC Frame-Relay

Aplicar la política MQC en la

interfaz global

Aplicar la política MQC en la subinterfaz

No aplicable

Política MQC aplicable,

pero sin FRTS

Aplicar la pólítica MQC dentro del map-class y

aplicar éste en la subinterfaz

Aplicar la pólítica MQC dentro del map-class y aplicar éste en el PVC

Interfaz

Plataforma




a) Ejemplo de Class-based policing El enlace PPP de 1024Kbps, de acuerdo a las políticas establecidas por la empresa, debe cursar principalmente tráfico de correo, ftp y http; pero los usuarios hacen uso de aplicaciones secundarias como las de voz y video en tiempo real, un programa de chat que usa el puerto TCP 10048 e incluso han habilitado un servidor de música en MP3 (10.120.1.9) del cual descargan archivos. Entonces, se ha establecido que el 20% del ancho de banda disponible en el enlace PPP será dedicado a las aplicaciones secundarias mientras que el resto del tráfico no tendrá límites. Por otro lado, todo el tráfico que sale de la red 192.168.1.0 suele tener como destino la red 192.168.2.0 y viceversa; además, tiene una tasa garantizada de 192Kbps pero puede llegar a 512Kbps. Al ser éstas redes secundarias, no es deseable que lleguen a ocupar 512Kbps del enlace PPP de 1Mbps, por lo tanto, se ha determinado que todo tráfico que intercambien estas redes y que exceda los 192Kbps, sea enrutado a través del enlace backup Frame-Relay de CIR 64Kbps.

ROUTER_C

policy-map TODO class class-default police 192000 conform-action transmit exceed-action set-prec-transmit 2 interface s0 encapsulation frame-relay service-policy output TODO

ROUTER_D policy-map TODO class class-default police 192000 conform-action transmit exceed-action set-prec-transmit 2 interface s0 encapsulation frame-relay service-policy output TODO

PPP 1024Kbps

ROUTER_A ROUTER_B

10.120.1.0 /24 10.120.2.0 /24

192.168.100.0 /24

FR 192/192/384Kbps

Backup FR 64/64/448Kbps

192.168.200.0 /24

FR 192/192/384Kbps

ROUTER_C ROUTER_D



ROUTER_A class-map match-any APP_SEC match protocol rtp match access-group 100

policy-map AaB class APP_SEC police cir percent 20 conform-action transmit exceed-action drop interface ethernet0 ip policy route-map 10 interface s0 encapsulation ppp service-policy output AaB interface s1 encapsulation frame-relay access-list 100 permit ip host 10.120.1.9 any access-list 100 permit tcp any any eq 10048 access-list 150 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 precedence 2 route-map 10 permit match ip address 150 set interface s1 route-map 20 permit set interface s0

ROUTER_B class-map match-any APP_SEC match protocol rtp match access-group 100

policy-map BaA class APP_SEC police cir percent 20 conform-action transmit exceed-action drop interface ethernet0 ip policy route-map 10 interface s0 encapsulation ppp service-policy output BaA interface s1 encapsulation frame-relay access-list 100 permit ip host any host 10.120.1.9 access-list 100 permit tcp any any eq 10048 access-list 150 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 precedence 2 route-map 10 permit match ip address 150 set interface s1 route-map 20 permit set interface s0



Backbone de Internet

CLIENTE A

CLIENTE B

CLIENTE C

PROVEEDOR

e0.1

e0.2

e0.3

e0

e0

e0

b) Ejemplo de GTS y Class-based shaping La red de la figura muestra las conexiones entre el proveedor y sus clientes a través subinterfaces ethernet. Se trata de enlaces inalámbricos punto a multipunto tipo bridge en los cuales se utiliza VLANs para poder manejar redes independientes. Cada cliente contrató 512Kbps, la limitación debe hacerse lo más cercano posible al origen del tráfico optimizando así la utilización de los enlaces inalámbricos. Además cada cliente solicitó priorizar el tráfico de envío de correos de tal manera que tenga garantizado por lo menos la mitad del ancho de banda disponible. Se utilizará GTS en el proveedor y Class-based shaping en los clientes.

CLIENTE A (igual a CLIENTE B y C) class-map match-any SMTP match protocol smtp policy-map QUEUE class SMTP bandwidth percent 50 class class-default fair-queue policy-map SHAPE class class-default shape average 512000 service-policy output QUEUE interface ethernet 0 bandwidth 512 service-policy output SHAPE

PROVEEDOR

interface e0.1 traffic-shape rate 512000 51200 51200 interface e0.2 traffic-shape rate 512000 51200 51200 interface e0.3 traffic-shape rate 512000 51200 51200



c) Ejemplo de Frame-relay traffic shaping

La sede central tiene enlaces frame-relay a sus dos sedes remotas. Estos son PVCs de 64Kbps y pueden llegar hasta 128Kbps. Se configura FRTS para garantizar que el tráfico salga limitado desde los CPE y no existan descartes en los switches frame-relay de la red del proveedor. Además, se desea que el tráfico del aplicativo del cliente, el cual utiliza los puertos tcp 1003 y 1004, tenga prioridad estricta sobre cualquier otro tipo de tráfico. ROUTER_A interface serial0 encapsulation frame-relay frame-relay traffic shaping interface serial0.5 frame-relay interface-dlci 500 class 64K interface serial0.6 frame-relay interface-dlci 600 class 64K access-list 100 permit tcp any any eq 1003 access-list 100 permit tcp any any eq 1004 priority-group 1 protocol ip high list 100 map-class frame-relay 64K frame-relay cir 61000 frame-relay bc 61000 frame-relay be 60000 frame-relay priority-group 1

ROUTER_B y ROUTER_C interface serial0 encapsulation frame-relay frame-relay traffic-shaping frame-relay interface-dlci 500 (/600) class 64K access-list 100 permit tcp any any eq 1003 access-list 100 permit tcp any any eq 1004 priority-group 1 protocol ip high list 100 map-class frame-relay 64K frame-relay cir 61000 frame-relay bc 61000 frame-relay be 60000 frame-relay priority-group 1

FR

ROUTER_A

ROUTER_B

ROUTER_C

500

600

s0

s0

s0 192.168.1.0

192.168.2.0

192.168.3.0



Mecanismos de eficiencia en enlaces WAN

1. Introducción a los mecanismos de eficiencia

Los mecanismos que veremos a continuación, buscan optimizar el uso de los enlaces WAN, minimizando el consumo de ancho de banda de ciertos protocolos. Básicamente existen tres mecanismos de eficiencia para redes WAN: - Compresión de datos (payload): stacker, predictor, MPPC e IP PCP. - Compresión de cabeceras: TCP, CB-TCP, RTP y CB-RTP. - Fragmentación de tramas: MLP LFI, FRF.12 y FRF.11c.

2. Compresión de datos (payload) Este tipo de compresión generalmente reduce el tamaño del payload de capa 2, es decir, del paquete entero en capa 3. El resultado es un aumento del ancho de banda disponible y muchas veces una disminución de la latencia en el enlace. Se configura enlace por enlace y en ambos extremos, pudiéndose configurar en un enlace sin afectar al resto de la red. Los algoritmos que se pueden utilizar son.- Predictor: tiene un ‘diccionario’ de secuencias de bytes, el cual va recorriendo en orden de acuerdo a un número de índice. Luego compara la secuencia de datos que viene con la secuencia actual del diccionario, si encuentra una coincidencia, reemplaza la secuencia de datos por el número de índice de la secuencia del diccionario; de otra forma, continúa recorriendo las secuencias en el diccionario y comparándolas con las secuencias de datos. Sólo es aplicable en PPP y LAPB, siendo el algoritmo más rápido pero el que comprime menos que otros. Consume más recursos de memoria que de procesador (CPU). Se habilita con el siguiente comando en la interfaz: compress predictor Stacker: utiliza el algoritmo de compresión Lempel-Ziv, el cual reemplaza secuencias de caracteres por códigos más pequeños, creando a su vez un diccionario formado por todos los reemplazos.

Algoritmo de compresión

Header Capa 2

Payload Capa 2 (Paquete IP Capa 3)

Header Capa 2

Payload Capa 2 comprimido



Sólo es aplicable en PP, LAPb y HDLC. En general, consume más recursos de CPU que de memoria. Se habilita con el siguiente comando en la interfaz: compress stac [distributed ] [csa <slot>] [caim] Adicionalmente la opción distributed concentrará el procesamiento de la compresión en una tarjeta VIP en lugar de hacerlo en el CPU. LA opción csa habilita la compresión por hardware concentrando el procesamiento en un módulo externo de compresión (compress service adapter; disponible para la línea 7200 y 7500). Por otro lado, la opción caim se utiliza para habilitar la compresión por hardware cuando se dispone de una tarjeta CAIM (Compress Advanced Interface Module). Microsoft Point-to-point compression (MPPC): Este tipo de compresión es similar a la stacker, pero funciona entre un router Cisco y un cliente de Microsoft como Windows, sólo para PPP. Se habilita con el siguiente comando en la interfaz: compress mppc [ignore-pfc *] *opcional, para no comprimir el flag LCP IP Payload compression protocol (IP PCP): este mecanismo es relativamente nuevo y comprime el payload IP en capa 3, con el algoritmo Lempel-Ziv usado por stacker. Es principalmente utilizado en conjunto con algún algoritmo de encriptación de capa 3 como IPSec, puesto que estos no permiten la configuración de compresión en capa 2. No se detallarán aspectos de configuración pues generalmente esta opción está soportada por defecto en módulos VPN externos. Recomendaciones en el uso de compresión de datos: - No utilizar compresión por software (CPU) cuando el procesador

sobrepasa una utilización del 40% en promedio. Tener en cuenta el límite de ancho de banda para comprimir en las distintas plataformas cuando se utiliza compresión por software (CPU):

- Cuando el cuello de botella se encuentra en la carga del enrutador,

utilizar el método Predictor; cuando el cuello de botella se encuentra en el enlace o se dispone de tarjetas CSA o CAIM, utilizar el método Stacker.

- No utilizar compresión de datos cuando se sabe que la mayoría de los datos ya vienen comprimidos (MPEG, JPEG, etc).

Serie 1000

Predictor

Stacker

Serie 3000 Serie 4000 Serie 4700 Serie 7000Serie 4500

128 128 256

256 256 500

500 T1 256

T1 2xT1 500

Método



3. Compresión de cabeceras

La compresión de cabeceras se realiza en las capas 3 y 4, incrementando el ancho de banda disponible y reduciendo la latencia. Estas ventajas sólo se logran en protocolos cuyo payload es pequeño, ya que en estos casos las cabeceras ocupan una parte significativa del ancho de banda. Protocolos como VoIP (RTP) y Telnet (TCP) tienen esta característica. Se configura enlace por enlace y en ambos extremos, pudiéndose configurar en un enlace sin afectar al resto de la red. Este mecanismo es más efectivo en enlaces de baja velocidad. Los algoritmos que se pueden utilizar son.- TCP Header Compression: comprime las cabeceras IP y TCP, las cuales suman 40 bytes, en una sola cabecera de 3 a 5 bytes. La primera cabecera de una sesión TCP/IP siempre es transmitida sin comprimir, las cabeceras siguientes sólo incluyen el índice de la sesión TCP/IP y los parámetros variables. Se habilita con el siguiente comando en la interfaz: [frame-relay*] ip tcp header-compression

* solo para interfaces frame-relay También es posible habilitar TCP header-compression en clases MQC, configurando el siguiente comando dentro de la clase: compression header ip tcp RTP Header Compression: comprime las cabeceras IP, UDP y RTP para el protocolo Real-Time Protocol generalmente utilizado por aplicaciones de voz y video. Estas cabeceras suman normalmente 40 bytes, los culaes se pueden comprimir en 2 a 4 bytes. La primera cabecera de una sesión RTP/UDP/IP siempre es transmitida sin comprimir, las cabeceras siguientes sólo incluyen el índice de la sesión RTP/UDP/IP y los parámetros variables. Es muy recomendable utilizar cRTP en aplicaciones de voz comprimida. Se habilita con el siguiente comando en la interfaz: [frame-relay*] ip rtp header-compression

* solo para interfaces frame-relay También es posible habilitar TCP header-compression en clases MQC, configurando el siguiente comando dentro de la clase: compression header ip rtp

Algoritmo de compresión

Header Capa 2

Header Capa 3

Header Capa 2

cmp HDR

Header Capa 4+ Payload Payload



4. Fragmentación de tramas

La transmisión de paquetes termina siempre en la cola física de salida, la cual, como vimos anteriormente, siempre tiene arquitectura FIFO; en esta cola un paquete de voz puede ser demorado si es precedido por un paquete muy largo. La fragmentación de tramas es un mecanismo de capa 2 que sirve para dividir una trama grande en varias más pequeñas, permitiendo así que una trama pequeña, como la de un paquete de voz, sea intercalada con los fragmentos de una trama más grande. En general se utiliza este mecanismo cuando se tiene voz y datos sobre un mismo circuito. Los paquetes de voz requieren ser puestos en la interfaz de salida en el menor tiempo posible, este tiempo es llamado ‘tiempo de serialización’ (ver pág.4) y se calcula de la siguiente forma: El tiempo de serialización recomendado para cuando se tienen paquetes de voz y datos sobre la misma interfaz de salida es de 10 a 15ms. La fragmentación permite controlar el tamaño de paquete máximo garantizando de esta manera una adecuada serialización. La siguiente tabla nos muestra el tamaño de fragmento ideal en bytes para lograr tiempos de serialización de 10 y 15ms. *Se puede observar que en enlaces con un ancho de banda cercano o mayor a 1536K, no es necesario fragmentar las tramas ya que éstas por defecto son de 1500bytes.

SIN FRAGMENTACIÓN

CON FRAGMENTACIÓN

cola de salida

cola de salida

Ts = Tamaño de paquete_ Ancho de banda

56Kbps

15ms

10ms 70

84

64Kbps 128Kbps 256Kbps 512Kbps 768Kbps 1536Kbps

80

96

160

192

320

384

640

768

1000

1152

2000

2304

Ts



Existen los siguientes tipos de fragmentación.- Multilink PPP – Interleaving: Para encapsulamiento PPP, es necesario habilitar Multilink PPP (MLP). Se configura de la siguiente forma, en la interfaz PPP: ppp multilink multilink-group [#] En la interfaz multilink: ppp multilink fragment-delay [Ts] ppp multilink interleave FRF.12 Frame Relay Fragmentation: Es la fragmentación recomendada para VoIP sobre frame-relay. Se utiliza con FRTS y se configura dentro del map-class de la siguiente manera: frame-relay fragment [bytes] Luego se aplica esta clase a la interfaz, subinterfaz o PVC y se activa FRTS. El tipo de fragmentación FRF.12 soportado por Cisco es el end-to-end, esto quiere decir que la fragmentación debe configurarse a ambos extremos del PVC, de otra forma los paquetes grandes se podrán transmitir en una sola dirección. Debe tenerse en cuenta además, que el tamaño de fragmento debe ser mayor al tamaño de la trama del paquete de voz, para evitar que éste sea fragmentado. Para plataformas 7500, donde FRTS no es soportado, existe una forma especial de aplicar FRF.12 desde la versión 12.1(5)T; se debe hacer lo siguiente:

- Configurar la fragmentación dentro de un map-class. - Aplicar el map-class al PVC, interfaz o subinterfaz. - Con esto el enrutador empezará a fragmentar los paquetes, no es

necesario ni se podrá habilitar FRTS.




a) Ejemplo de compresión de cabeceras.

En este enlace punto a punto se tienen aplicaciones de voz y datos a través de un enlace satelital de 64Kbps. Dada la naturaleza del enlace, la latencia es un tema crítico, sobre todo para la voz, por lo que se busca disminuirla con todos los mecanismos posibles; además, el ancho de banda disponible es bajo, por lo tanto se necesita además un mecanismo de optimización en el uso del mismo. Entre los protocolos más utilizados en este enlace, se encuentran la voz comprimida a con g.729 (RTP, payload pequeño) y Telnet (TCP, payload pequeño), por lo que se configura compresión para ambos, así se disminuye la latencia y el ancho de banda utilizado por estas aplicaciones. Adicionalmente se prioriza la voz sobre cualquier otra aplicación con el uso de LLQ.

ROUTER_A y ROUTER_B class-map match-any TELNET match protocol telnet class-map match-any VOZ match ip dscp ef policy-map COMPLLQ class TELNET compression header ip tcp class VOZ priority 44 compression header ip rtp interface serial0 encapsulation hdlc bandwidth 64 service-policy output COMPLLQ

dial-peer voice 1 voip codec g729r8 bytes 40 ip qos dscp ef media ip qos dscp ef signalling

ROUTER_A ROUTER_B

2FxO

s0

s0Satelital 64Kbps 2FxO



b) Ejemplo de fragmentación FRF.12.

En este ejemplo, similar al de la página 49, se tiene además comunicaciones de voz sobre IP cursando la red frame-relay, por lo cual se ha decidido aplicar fragmentación a las tramas para dsiminuir la latencia de los paquetes de voz. Se configura FRTS para poder aplicar la fragmentación y garantizar que el tráfico salga limitado desde los CPE y no existan descartes en los switches frame-relay de la red del proveedor. Adicionalmente se aplica LLQ para priorizar los paquetes de voz y compresión de cabeceras para mejorar aún más la latencia.

ROUTER_A

class-map match-any VOZ match ip dscp ef policy-map VoIP class VOZ compression header ip rtp priority 32

interface serial0 encapsulation frame-relay frame-relay traffic shaping interface serial0.5 frame-relay interface-dlci 500 class 128K interface serial0.6 frame-relay interface-dlci 600 class 128K map-class frame-relay 128K frame-relay cir 121000 frame-relay bc 1210 frame-relay be 0 frame-relay mincir 121000 service-policy output VoIP frame-relay fragment 160

ROUTER_B y ROUTER_C class-map match-any VOZ match ip dscp ef policy-map VoIP class VOZ compression header ip rtp priority 32

interface serial0 encapsulation frame-relay frame-relay traffic-shaping frame-relay interface-dlci 500 (/600) class 128K map-class frame-relay 128K frame-relay cir 121000 frame-relay bc 1210 frame-relay be 0 frame-relay mincir 121000 service-policy output VoIP frame-relay fragment 160

FR

ROUTER_A

ROUTER_B

ROUTER_C

500

600

s0

s0

s0 128Kbps

128Kbps



Resolución de problemas

1. Comandos útiles a) Clasificación y marcación de paquetes

- show class-map: muestra la configuración de todas las clases MQC configuradas.

- show policy-map: muestra la configuración de todas las políticas MQC aplicadas a las clases.

- show policy-map interface [interfaz]: muestra la política aplicada a la interfaz y estadísticas sobre paquetes los clasificados.

- show ip nbar protocol-discovery: muestra estadísticas de los protocolos que cursan las interfaces en las cuales NBAR está habilitado.

b) Encolamiento

- show interface [interfaz]: muestra el método de encolamiento aplicado a la interfaz (WFQ/FIFO) y estadísticas del mismo.

- show queue [interfaz]: muestra estadísticas de WFQ. - show policy-map interface [interfaz]: muestra estadísticas de CBWFQ o

LLQ.

c) Evitamiento de la congestión - show policy-map interface [interfaz]: muestra estadísticas RED aplicado

en clases (WRED).

d) Control de tráfico - show policy-map: muestra la configuración de todas las políticas de

control de tráfico aplicadas en clases MQC. - show policy-map interface [interfaz]: muestra estadísticas de Class-

Based Policing o Shaping. - show frame-relay pvc [dlci]: muestra estadísticas de FRTS y las políticas

de encolamiento aplicadas. e) Mecanismos de eficiencia

- show policy-map interface [interfaz]: muestra estadísticas de Class-Based compressed RTP o TCP.

- show interfaces multilink [interfaz[: muestra estadísticas de fragmentación MLP.

- show frame-relay fragment [dlci]: muestra la cantidad de paquetes fragmentados transmitidos y recibidos.

- show frame-relay pvc [dlci]: muestra estadísticas de fragmentación FRF.12.



2. Documentos útiles Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2 http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1835/products_configuration_guide_book09186a00800c5e31.html

Cisco_VoIP_v1 file:\\10.120.1.9\telepuerto$\Service_Assurance\Tecnologias\Routing\Cisco\VoIP\Cisco_VoIP_v1.PDF

AutoQoS for the Enterprise http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_feature_guide09186a00802000a7.html

Para consultas acerca de este documento, comunicarse con: Gianpietro Lavado Chiarella [email protected] anexo 5470

Documents

Cisco QoS v1