Cisco QoS v1

Configuracin y manejo de calidad de servicio en enrutadores Cisco
Configuracin de calidad de servicio (QoS) en enrutadores Cisco

ndice Tema Pgina
Introduccin................................................................................................4 Descripcin de QoS en Cisco....................................................................4 1. Cundo se requiere configurar calidad de servicio? 2. Requisitos en el enrutador 3. Modelos de calidad de servicio 4. Mecanismos de calidad de servicio 5. Introduccin a MQC Clasificacin y marcacin de paquetes..................................................9 1. Clasificacin de trfico 2. Marcacin de paquetes 3. Ejemplos de configuracin Manejo de la congestin..........................................................................15 1. Introduccin al encolamiento 2. Arquitectura de colas en Cisco 3. Mtodos bsicos de encolamiento 4. Mtodos avanzados de encolamiento 5. Otras tcnicas de encolamiento 6. Conclusiones sobre encolamiento 7. Ejemplos de configuracin Evitamiento de la congestin....................................................................34 1. Congestin y TCP 2. RED : Random Early Detection 3. WRED : Weighted Random Early Detection 4. Ejemplos de configuracin Control de trfico: Policy & Shaping40 1. Introduccin al control de trfico 2. Implementacin de Traffic Policing 3. Implementacin de Traffic Shaping 4. Ejemplos de configuracin Mecanismos de eficiencia en enlaces WAN50 1. Introduccin a los mecanismos de eficiencia 2. Compresin de datos (payload)
Autor: Gianpietro Lavado Chiarella Pgina 2 10/10/04

3. Compresin de cabeceras 4. Fragmentacin de tramas 5. Ejemplos de configuracin Resolucin de problemas57 1. Comandos tiles 2. Documentos tiles
Autor: Gianpietro Lavado Chiarella
Pgina 3
10/10/04

Introduccin.
Este documento cubre los aspectos principales de la implementacin de calidad de servicio en enrutadores Cisco. Los mtodos ac descritos son los que se utilizan en la actualidad y contienen ejemplos de configuracin, as como aplicaciones a casos reales, recomendaciones y resolucin de problemas. La informacin 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 produccin. A lo largo del documento se utilizarn algunos trminos tcnicos en ingls, para facilitar su comprensin.
Descripcin de QoS en Cisco.

1. Cundo se requiere configurar calidad de servicio? La configuracin de calidad de servicio no es siempre necesaria, incluso realizar configuraciones complejas cuando no se requiere podra 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 ms ancho de banda del que se dispone, generando congestin. Los mecanismos que veremos para contrarrestar este problema son: priorizacin de trfico importante (encolamiento avanzado) y compresin 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 conmutacin de paquetes y configuraciones complejas en las interfaces. - Tiempo de serializacin: 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. - Propagacin: El tiempo que lleva transmitir un paquete segn el medio.

Los mecanismos que estudiaremos para contrarrestar el problema de latencia son: priorizacin de trfico importante (encolamiento avanzado), compresin de paquetes y fragmentacin. c) Prdida o descarte de paquetes: Aparte de las prdidas que puedan encontrarse en el medio fsico, 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 polticas de trfico (police/shape). Estos tres problemas pueden existir hasta cierto grado dependiendo de los requerimientos de la aplicacin. Por ejemplo, para contar con una buena calidad de voz en un enlace se requiere: - Latencia: menor o igual a 150ms* en un sentido. - Variacin en latencia (jitter): menor o igual a 30ms en un sentido. - Ancho de banda fijo garantizado dependiendo del codec. - Prdida 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 seran posibles.
Similar para el video, pero este trfico contiene rfagas. Por esta razn no se necesita garantizar un ancho de banda fijo sino un mnimo, igual al stream + 20%.
VOZ
VIDEO
Pgina 5
10/10/04

2. Requisitos en el enrutador Para poder configurar calidad de servicio en un enrutador, es necesario contar con el IOS correcto. Las tcnicas ms utilizadas actualmente para implementar QoS (CBWFQ/LLQ) estn 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 pgina Web de Cisco (herramienta Software Advisor). 3. Modelos de calidad de servicio En general, existen tres modelos de implementacin 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 diferenciacin entre un tipo de trfico y otro; no hay garanta en la entrega de paquetes ni ancho de banda reservado. Fuera de las desventajas es altamente escalable y fcil de implementar; es muy utilizado actualmente para trfico de Internet. b) Modelo de servicios integrados (IntServ/Hard QoS): permite definir todos los parmetros de calidad de servicio deseados con exactitud de extremo a extremo antes de iniciar la transmisin de datos. El ancho de banda y la latencia estn 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 combinacin con LLQ y WRED); RSVP no ser tratado en este documento. c) Modelo de servicios diferenciados (DiffServ/Soft QoS): permite clasificar el trfico y brindar a cada clase los requerimientos de calidad de servicio que necesite. Los recursos de QoS solicitados no estn 100% garantizados pues se van obteniendo conforme el trfico va cursando la red, sin embargo este modelo es ms utilizado que IntServ actualmente, por su alta escalabilidad y la cantidad de niveles de calidad de servicio que ofrece. Adems, la reserva de ancho de banda es dinmica. Las tcnicas de calidad de servicio descritas en el siguiente punto estn basadas en este modelo.
Pgina 6
10/10/04

4. Mecanismos de calidad de servicio Cisco ofrece los siguientes mecanismos para implementar calidad de servicio en redes IP: a) Clasificacin y marcado de paquetes: dado que los paquetes IP contienen ciertas caractersticas, es posible agruparlos en clases para aplicar en ellos diferentes polticas de calidad de servicio y/o marcarlos para luego identificarlos en un proceso de QoS posterior. b) Manejo de la congestin: La clasificacin de paquetes permite repartir el trfico en distintas colas (segn la tcnica de encolamiento utilizada) para que cada tipo de trfico sea tratado en forma distinta, segn su prioridad. Existen principalmente las siguientes tcnicas 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 congestin: Este mecanismo permite evitar la saturacin 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) Polticas de trfico: permiten limitar la tasa de transferencia de paquetes para descartar, encolar o marcar el trfico de exceso. e) Compresin y fragmentacin: sirven para hacer que los enlaces WAN sean ms eficientes, haciendo un mejor uso del ancho de banda disponible. 5. Introduccin a MQC Los mecanismos anteriormente mencionados cuentan con dos mtodos de implementacin. Modular QoS CLI (MQC) es uno de ellos, ampliamente utilizado para implementar calidad de servicio en enrutadores Cisco. El mtodo MQC consta de 3 pasos: 1) Definir clases: haciendo uso de las sentencias class-map 2) Establecer polticas: haciendo uso de las sentencias policy-map

3) Aplicar las polticas: con el comando service-policy output en general aplicado a interfaces. Por ejemplo:
1
CLASE VOZ CLASE FTP POLTICA 2: CLASE SQL
Mejor esfuerzo, BW limitado
2
POLTICA 1:
BW y Delay garantizados
3
Interfase Ethernet0
Int. Serial0.1 Int. Serial0.3
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
El otro mtodo de implementacin 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 anlisis de trfico y aplicar automticamente las polticas de calidad de servicio. AutoQoS configura desde mtodos de encolamiento hasta fragmentacin 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 encapsulacin de las interfaces.
Pgina 8
10/10/04

Clasificacin y marcacin de paquetes
Actualmente MQC es el mtodo preferido para clasificar y marcar paquetes para implementar calidad de servicio. En versiones anteriores esto se sola hacer con route-maps. 1. Clasificacin de trfico Existen muchas formas de clasificar trfico, pero antes veamos la configuracin:
class-map [ match-any/match-all ] [nombre de clase] match [not] [condicin 1] match [not] [condicin n]
match-any: si el trfico cumple una sola sentencia entra en la clase match-all: el trfico debe cumplir con todas las sentencias para clasificarse not: parmetro opcional que niega la condicin
Luego se llama esta clase desde un policy-map, segn MQC. A continuacin las principales condiciones para clasificar trfico: a) Access-lists: Consiste en crear listas de control de acceso para clasificar tipos de trfico. Comando: match access-group XXX b) IP precedence: Clasifica el trfico segn el valor de los 3 primeros bits del byte TOS en los paquetes IP, pudindose definir desde uno hasta cuatro valores. Comando: match ip precedence [valor 1] [valor 2] [valor 3] [valor 4]
VALOR DECIMAL 0 1 2 3 4 5 6 7 VALOR BINARIO 000 001 010 011 100 101 110 111 NOMBRE routine priority immediate flash flash-override critical internet network
c) IP DSCP: Clasifica el trfico 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]
Pgina 9
10/10/04

VALOR DECIMAL* 0 1 2 3 4 5 6 7 46 10 12 14 18 20 22 26 28 30 34 36 38 VALOR BINARIO 000000 001000 010000 011000 100000 101000 110000 111000 101110 001010 001100 001110 010010 010100 010110 011010 011100 011110 100010 100100 100110 NOMBRE Default cs1 cs2 cs3 cs4 cs5 cs6 cs7 ef af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43
*Para los valores class-selector (cs) el valor en decimal se simplifica asemejndose al de IP Precedence.
d) Protocolo: se puede clasificar segn protocolos de capa 3 ms. Pero adems, con la herramienta NBAR, se dispone de una clasificacin ms avanzada permitiendo al enrutador que descubra ms protocolos dinmicamente, 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 tneles o encriptacin. - 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 clasificacin. Por defecto vienen muchas aplicaciones detectables segn 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 cargndolos en la flash. 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 estadsticas, los protocolos ms usados, notificaciones, etc.
(ms informacin: www.cisco.com/cgi-bin/tablebuild.pl/pdlm)

desde la versin 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 estadsticas de todos los protocolos que ingresan o egresan la interfaz. Algunos comandos tiles para NBAR: - match protocol [protocolo] Clasifica segn protocolos. Se usa dentro del class-map. - show ip nbar protocol-discovery [opciones] Muestra estadsticas 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 configuracin global. Por ejemplo: ip nbar port-map http tcp 80 8080
para clasificar http no slo por el puerto 80 sino por el 8080 tambin.
e) Jerarqua 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 encapsulacin 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 segn la interfaz por la que entraron al enrutador. Comando: match input-interface [interface] h) Direccin MAC: se clasifica trfico por direccin MAC origen o destino. Comando: match [source-address/destination-address] mac [MAC] i) Puertos UDP: el trfico RTP (Real time protocol) puede ser clasificado segn el rango de puertos UDP especificado. Comando: match ip rtp [puerto udp inferior] [nmero total de puertos] j) Todo el trfico: para clasificar todo el trfico que atraviese el enrutador. Comando: match any Otras formas de clasificar incluyen: QoS group (variante de DSCP), MPLS experimental bits, Frame-Relay DE bit.
Pgina 11
10/10/04

2. Marcacin de paquetes La marcacin 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 polticas de calidad de servicio respectivas. Para marcar por clase, se requiere IP CEF. La configuracin es la siguiente:
ip cef
policy-map [nombre de poltica] class [nombre de clase] set [ip precedence/ip dscp/cos/etc...] [valor]
Luego se debe asociar la poltica a una interfaz de entrada o salida con el comando service-policy output [nombre de poltica]. Hay otras formas vigentes de marcar paquetes fuera de MQC (policymaps). Para trfico de voz, es posible marcar los paquetes en los dialpeers. 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 nmero (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 encapsulacin 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 segn el valor especificado por nmero (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 configuracin del dialpeer voip, por ejemplo, dependiendo de la versin de IOS:
dial-peer voice 1 voip ip precedence 5 dial-peer voice 1 voip 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 configuracin a) Ejemplo de clasificacin y marcacin en clases
192.168.2.0 s0 ROUTER A .2 .3 192.168.3.0 s0 ROUTER B .2 .3 ROUTER C s1/1 ROUTER_D 192.168.1.0
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 segn las direcciones IP de los hosts, as evitamos la configuracin de listas de control de acceso en el enrutador central (Router_C). Nota: El funcionamiento del comando bandwidth ser visto ms 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
Pgina 13
10/10/04

b) Ejemplo de clasificacin y marcacin en dial-peers
FxS 1234 ROUTER_A
s0 s0 ROUTER_B
FxS 2345
El enrutador ROUTER_A marca, clasifica y prioriza sus propios paquetes de voz hacia el enrutador ROUTER_B. Igualmente para el trfico de voz de ROUTER_B hacia ROUTER_A. La marcacin es hecha en el dial-peer; si la llamada realizada utiliza dicho dial-peer, entonces los paquetes de voz (y de sealizacin 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 ms 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
Pgina 14
10/10/04

Manejo de la congestin 1. Introduccin 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 congestin, priorizando un tipo de trfico sobre otro. La principal causa de la congestin en las interfaces es la diferencia de velocidad que existe entre ellas, los siguientes dibujos hablan por s solos:
100Mbps
64Kbps
flujo de trfico
512Kbps 512Kbps 512Kbps
512Kbps
flujo de trfico
Dependiendo del tipo de aplicaciones que se estn manejando, se debe determinar qu algoritmo de encolamiento ser el ms conveniente. Las implementaciones propietarias de Cisco estn 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 ms simple. Priority Queuing (PQ) - Mltiples colas, una de ellas tiene alta prioridad. - Los paquetes de la cola de alta prioridad se transmiten hasta que se vace la cola, luego se prosigue con las dems colas. - Transmisiones continuas en la cola de alta prioridad pueden hacer que las dems colas se queden sin transmitir (queue starving). Round Robin (RR) - Mltiples colas, se transmite un paquete por cada una.

- No hay priorizacin. - Generalmente utilizado en switches LAN. Weighted Round Robin (WRR) - Mltiples colas, se asigna un peso a cada una. - La priorizacin es posible, el nmero mximo 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 informacin enviada. Dficit Round Robin (DRR) - Similar a WRR, resolviendo el problema de la cantidad de informacin. - 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 segn los algoritmos disponibles en la plataforma (WFQ, FIFO, CBWFQ, LLQ, etc)
IP
IP
IP
IP
COLA SW
COLA HW
(FIFO)
INTERFASE
ESTRUCTURA TPICA DE COLA DE SOFTWARE ENVO O DESCARTE ENVO O DESCARTE COLA 1
CLASIFICACIN
COLA 2
. . .
ENVO O DESCARTE COLA n
PROGRAMADOR (SCHEDULER)
Pgina 16
10/10/04

As, tenemos tpicamente cuatro etapas en la cola de SW: Clasificacin: Divide el trfico segn criterio establecido por el algoritmo o por el usuario. Envo o descarte: Decide si encolar o descartar el trfico segn 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 segn el algoritmo configurado. Notas adicionales sobre la arquitectura de colas: La cola de software es solamente utilizada cuando existe congestin. Por lo general, el indicador de congestin es la cola de hardware; cuando sta est llena, significa que la interfaz est congestionada. Sin embargo, en interfaces lgicas, como por ejemplo en subinterfaces Frame-Relay, la cola de hardware no es un buen indicador de congestin, pues sta incluye a las dems subinterfaces. En el caso Frame-Relay en particular, los indicadores son los bits FECN y BECN, propios del protocolo, cuyos valores se obtienen en interaccin 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 parmetros de trfico y congestin manualmente. Es posible variar el tamao 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 serializacin de paquetes. - El algoritmo de encolamiento utilizado en la cola de SW tardar ms tiempo en ser aplicado, perdiendo as su utilidad. Cola HW muy corta - Los paquetes sern forzados a ingresar a la cola de SW todo el tiempo, esto puede causar una pobre utilizacin de la interfaz pues algunos algoritmos de SW tienen una multiplexacin 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 utilizacin se ver incrementada.
Pgina 17
10/10/04

Por defecto, el enrutador determinar el tamao ideal de la cola de HW basndose en el ancho de banda configurado en la interfaz (comando bandwidth), el cual normalmente es el correcto; las interfaces ms rpidas tendrn colas de hardware ms largas pues producen menos latencia que las interfaces lentas. En general, el tamao de la cola de HW debe ser suficientemente corto como para evitar una latencia de serializacin muy alta (causada por el encolamiento FIFO) y suficientemente largo como para evitar demasiados descartes de paquetes (perjudicando flujos TCP). 3. Mtodos bsicos de encolamiento a) First-in First-out (FIFO) La cola de software tipo FIFO no tiene clasificacin ni priorizacin, dado que enva los paquetes en el orden en el cual los recibe. Est configurado por defecto en interfaces de 2Mbps o ms, donde generalmente no es necesaria una tcnica de encolamiento compleja por su rapidez de serializacin. La arquitectura es la siguiente:
1 2
COLA DE SOFTWARE FIFO

UNA SOLA CLASE TAIL DROP UNA SOLA COLA FIFO
1 2 3
SCHEDULER
COLA HW (FIFO)
Utiliza el mtodo de descarte por defecto llamado Tail Drop. Este mtodo descarta todos los paquetes que van llegando cuando la cola est llena. Ventajas de FIFO: - Simple y rpido (una sola cola). - Soportado en todas las plataformas y IOS. Desventajas de FIFO: - Puede causar que un solo flujo agresivo de datos monopolice la utilizacin de la cola (starvation).

- Puede causar latencia variable (jitter) si la cola se llena con altas rfagas de paquetes. Configuracin de FIFO: Se aplica el comando no fair-queue en la interfaz global. b) Weighted Fair Queue (WFQ) WFQ es una tcnica de encolamiento automtico, pues se permite que el enrutador calcule a qu trfico darle mayor prioridad. Esto lo hace separando el trfico en flujos o conversaciones y asignndole pesos inversamente proporcionales a su volumen de trfico. 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:
C B A
COLA DE SOFTWARE WEIGHTED FAIR-QUEUE
FLUJO 1?
WFQ DROP
COLA 1
FLUJO 2?
WFQ DROP
COLA 2
WFQ SCHEDULER
. . .
COLA HW (FIFO)
FLUJO n?
WFQ DROP
COLA n
Pgina 19
10/10/04

El proceso de encolamiento WFQ, puede dividirse en tres etapas segn el grfico: - Etapa de clasificacin automtica: WFQ agrupa los paquetes en diferentes flujos para asignar una sola cola a cada uno de ellos. Los criterios de agrupacin son: Direccin IP origen, direccin IP destino, puerto TCP/UDP origen, puerto TCP/UDP destino, protocolo de transporte y campo TOS. Todos estos parmetros pasan por un proceso de codificacin (hash) que define el identificador de la cola a la que sern direccionados. Existe un nmero mximo de colas que WFQ puede armar, este valor es configurable y debe ser mayor al nmero de flujos esperados en la comunicacin, 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 adems 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:
Ancho de banda B 64Kbps 64K < B 128K 128K < B 256K 256K < B 512K B 512Kbps Nmero de colas 16 32 64 128 256
- Etapa de encolamiento o descarte: cuando las colas de WFQ se aproximan al valor lmite de paquetes que stas pueden aceptar, se empieza a descartar paquetes del flujo ms agresivo. Este descarte temprano empieza cuando se sobrepasa el valor definido por el congestive discard threshold (CDT). El lmite 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 lmite, cualquier paquete entrante genera un descarte. El tiempo estimado que demorar un paquete en ser transmitido por la cola WFQ depende de su tamao 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 continuacin resume cundo un paquete se descarta o se enva a la cola.
Pgina 20
10/10/04

N > HQO? N > CDT? Peor FT? + ACCIN
NO NO SI SI NO
NO SI X X SI
X NO SI NO SI
A LA COLA A LA COLA DESCARTE DESCARTE DESCARTE*
N = Nmero 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 programacin (Scheduling): En esta etapa se define el orden en el cual los paquetes de los diferentes flujos o colas se enviarn a la interfaz fsica. Este orden slo 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 tamao y el ancho de banda de la interfaz. Veamos el siguiente ejemplo, donde 2 flujos estn entregando paquetes a las colas A y B respectivamente, partiendo del tiempo 0:
A1 (100ms) B1 (300ms) A2 (20ms)
A3 (10ms)
B2 (300ms)
100
70 60 50
0ms
A1: Llega en el tiempo T + 0ms y tomara 100ms transmitirlo A2: Llega en el tiempo T + 60ms y tomara 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 ms rpida que la de salida.
A3: Llega en el tiempo T + 70ms y tomara 10ms transmitirlo. B1: Llega en el tiempo T + 50ms y tomara 300ms transmitirlo B2: Llega en el tiempo T + 100ms y tomara 300ms transmitirlo. El Finish Time para cada paquete es igual al tiempo que llevara transmitirlo mas el FT del paquete anterior de la misma cola:
Pgina 21
10/10/04

FT(Pn) = TTx(Pn) + FT(Pn-1)
o si la cola est vaca (no existe un paquete anterior):
FT(Pn) = TTx(Pn) + Tactual As, en el ejemplo anterior, el FT para cada paquete sera: FTA1 = 100 + 0 = 100ms FTA2 = 20 + 100 = 120ms FTA3 = 10 + 120 = 130ms FTB1 = 300 + 50 = 350ms FTB2 = 300 + 300 = 650ms
B2 B1
A3 A2 A1
Esto demuestra que en WFQ, un paquete pequeo 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 clculo del Finish Time de la siguiente manera: FT(Pn) = TTx(Pn)/(IP prec.+1) + FT(Pn-1)
o si la cola est vaca (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 transmisin sera: 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
B2
A3 A2
B1
A1
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.
Pgina 22
10/10/04

Desventajas de WFQ: - Puede causar que mltiples flujos terminen en una sola cola, si el nmero de flujos es mucho mayor que el nmero de colas disponibles. Esta probabilidad es mayor en enlaces de ms lata velocidad. - No es posible clasificar el trfico manualmente. - No es posible garantizar valores de ancho de banda fijos. Configuracin de WFQ: Se aplica el siguiente comando en la interfaz global.fair-queue [cdt] [ nmero 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. Mtodos avanzados de encolamiento a) Class-based Weighted Fair Queuing (CBWFQ) CBWFQ es una extensin de WFQ, que permite al usuario hacer la clasificacin de trfico 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:
C B A
COLA DE SW CLASS-BASED WEIGHTED FAIR-QUEUE TAIL DROP
CLASE 1?
COLA 1
CLASE 2?
TAIL DROP
COLA 2
. . .
CLASE PD? TAIL DROP COLA PD PD = Por defecto
Autor: Gianpietro Lavado Chiarella Pgina 23
CBWFQ SCHEDULER (WRR)
COLA HW (FIFO)
10/10/04

El proceso de encolamiento CBWFQ, puede tambin dividirse en tres etapas segn el grfico: - Etapa de clasificacin: La clasificacin en CBWFQ es totalmente configurable por el usuario con el uso de MQC, mtodo descrito en el captulo anterior. - Etapa de encolamiento o descarte: Se utiliza la tcnica de descarte por defecto, Tail Drop. Con esta tcnica, se decartan los paquetes que llegan a la cola cuando alcanz su lmite (queue size). Todas las clases tienen una cola FIFO asignada, slo a la clase por defecto (class-default) se le puede configurar una cola WFQ. - Etapa de programacin (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. Adems, segn el ancho de banda configurado para la clase, el programador extraer ms o menos paquetes de su cola, utilizando un mtodo 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 enviarn antes que los dems a la cola fsica. El equipo slo 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 lmite pero no es muy recomendable, adems, 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 parmetro es utilizado para clculos de CBWFQ.
BANDWIDTH 128 CLASE A 8 6 4 2 CBWFQ SCHEDULER BANDWIDTH 64 CLASE B 7 5 3 1 8 6 3 4 2 1
QUEUE SIZE 4
Pgina 24
10/10/04

Ventajas de CBWFQ: - Configuracin modular (MQC). - Ancho de banda garantizable, es posible priorizar un trfico sobre otro. - Los pesos garantizan un mnimo 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 trfico de voz podra sufrir degradacin. Configuracin de CBWFQ: Siguiendo el procedimiento de configuracin de MQC, primero se configuran las clases.class-map [ match-any/match-all ] [nombre de clase] match [not] [condicin 1] match [not] [condicin n]
Luego se definen las polticas.-
policy-map [nombre de poltica] class [nombre de clase] (hasta 64 clases) bandwidth [Kbps / percent / remaining percent] [valor %] queue-limit [nmero de paquetes] (tail-drop) class class-default (opcional, trfico no clasificado) bandwidth [Kbps / percent / remaining percent] [valor %] queue-limit [nmero de paquetes] (tail-drop) -ofair-queue
Finalmente se aplica la poltica a la interfaz:
interface x service-policy output [nombre de poltica]
b) Low-latency Queuing (LLQ) Este mecanismo aade una cola de alta prioridad a CBWFQ, la cual s garantiza una baja latencia. Esta implementacin permite utilizar la cola de alta prioridad para el trfico de tipo tiempo real y las colas de menor prioridad para el resto de trfico utilizando CBWFQ. La arquitectura de LLQ se muestra a continuacin:
Pgina 25
10/10/04

C B A
COLA DE SOFTWARE LLQ ALTA PRIORIDAD CLASE AP?
CAR
COLA DE PRIORIDAD (FIFO)
AP = Alta Prioridad COLA DE SOFTWARE LLQ BAJA PRIORIDAD (CBWFQ) TAIL DROP
CLASE 1?
COLA 1
CLASE 2?
TAIL DROP
COLA 2
. . .
CLASE PD? TAIL DROP COLA PD PD = Por defecto
CBWFQ SCHEDULER (WRR)
COLA HW (FIFO)
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 trfico de alta prioridad, todas las clases entrarn a la misma cola. El funcionamiento es muy similar a CBWFQ, slo que la cola de prioridad debe vaciarse por completo para luego transmitir las dems. 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 trfico en todo momento (no slo en momentos de congestin). Otra buena costumbre para evitar este problema es no configurar ms ancho de banda del necesario para alta prioridad. El descarte de paquetes en la cola de alta prioridad es muy agresivo, caracterstico 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 razn, para el trfico de voz, se
Pgina 26
10/10/04

debe conocer exactamente cunto consumir cada canal y cuntas llamadas simultneas pueden llegar a existir. Se recomienda que esta cola se use slo para trfico de voz, ya que su capacidad utilizada es de comportamiento constante y se puede conocer con precisin, a diferencia del trfico de video. En general es slo til para trficos de tipo CBR (Constant Bit Rate) ver grfico pg.4 Al igual que con CBWFQ, slo es posible repartir el 75% del ancho de banda disponible entre las clases La siguiente figura nos ayuda a comprender el comportamiento:
PRIORITY 32 Z Y X S R Q P
BANDWIDTH 128 8 6 4 2 CBWFQ SCHEDULER BANDWIDTH 64 7 5 3 1 8 6 3 Z Y X 4 2 1 S R Q P
Ventajas de LLQ - Tiene todas las ventajas de CBWFQ. - Ancho de banda y baja latencia garantizable para trficos de tiempo real. - Previene que la cola de alta prioridad monopolice la utilizacin de la capacidad disponible, fijndole un lmite. Configuracin 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] burst tamao de rfaga en bytes (opcional) priority [Kbps] [burst] -opriority percent [%] [burst]
Pgina 27
10/10/04

c) CBWFQ y LLQ en Frame-Relay No es posible utilizar Frame-Relay Traffic Shaping (FRTS) y aplicar una poltica de CBWFQ/LLQ en la misma interfaz. En este caso, se debe aplicar la poltica 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 poltica en el Frame-Relay map-class. Estas plataformas trabajan con Distributed Traffic Shaping (DTS), donde se debe aplicar la poltica en la interfaz o subinterfaz. Esta poltica debe tener la funcin de encolamiento pero adems la de shaping, configurndola de manera jerrquica. Las opciones y configuraciones de Traffic Shaping disponibles (FRTS, GTS y DTS) se detallarn ms adelante en el captulo de Polticas de trfico. 5. Otras tcnicas de encolamiento Las tcnicas descritas a continuacin nacieron en versiones ms 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 configuracin. En configuracin global, se tienen las siguientes opciones:
priority-list [#lista] protocol [ip/ipx/decnet] [detalle: list[# ACL], tcp[puerto], etc]
(asocia el trfico saliente de una interfaz a una cola)
[high/medium/normal/low]
(asocia un protocolo a una cola, se puede detallar el puerto TCP/UDP, ACL, etc)
priority-list [#lista] interface [interf.] [high/medium/normal/low] priority-list [#lista] default [high, medium, normal, low]
(asocia el trfico no especificado a una cola)
priority-list [#lista] queue-limit [high-limit, medium-limit, normal-limit, low-limit]
Para aplicar en la interfaz:

priority-group [#lista]
(define el tamao de cada cola en nmero mximo de paquetes)
Ventaja: Ofrece un servicio ms dedicado a la cola de alta prioridad.
Pgina 28
10/10/04

Desventaja: Un trfico constante en la cola de ms alta prioridad puede hacer que las dems 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 tamao de las colas y nmero mximo de bytes que pueden transmitir. Comandos de configuracin. En configuracin global, se tienen las siguientes opciones:
queue-list [#lista] protocol [ip/ipx/decnet] [nmero de cola] [detalle: list[# ACL], tcp[puerto], etc]
(asocia el trfico saliente de una interfaz a una cola) (asocia un protocolo a una cola, se puede detallar el puerto TCP/UDP, ACL, etc)
queue-list [#lista] interface [interf.] [nmero de cola] queue-list [#lista] default [nmero de cola]
(asocia el trfico no especificado a una cola)
queue-list [#lista] queue [nmero de cola] limit [lmite en # de paquetes]

(define el tamao de cada cola en nmero mximo de paquetes)
queue-list [#lista] queue [nmero de cola] byte-count [lmite en bytes]

(define el nmero 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 informacin enviada. c) PVC queuing (Frame Relay PIPQ) Similar a Priority Queuing pero a nivel de PVCs. Se asigna uno o ms 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 Mdium y as sucesivamente. Comandos de configuracin. 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 configuracin global: Se aplican las clases a los PVC en las subinterfaces: frame-relay interface-dlci [dlci]
class [nombre del map-class]
map-class frame-relay [nombre] frame-relay interface-queue priority [High/Medium/Normal/Low]
Pgina 29
10/10/04

Ventaja: Ofrece un servicio ms dedicado a la cola de alta prioridad. Desventaja: Un trfico constante en los PVCs de ms alta prioridad puede hacer que los dems PVCs dejen de transmitir por un tiempo prolongado (starving). 6. Conclusiones sobre encolamiento La duda que generalmente surge sobre las diferentes tcnicas 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 tcnica de encolamiento basndonos en las ventajas y desventajas de cada una. El siguiente grfico sugiere cundo utilizar qu tcnica:
Interface WAN congestionada? SI Se requiere un control estricto? SI Aplicaciones sensibles a delay? SI Utilizar LLQ, PQ o PIPQ
NO
No se necesita otra tcnica que FIFO
NO
Utilizar Weighted Fair Queuing
NO
Utilizar CBWFQ o Custom Queuing
Pgina 30
10/10/04

7. Ejemplos de configuracin a) Ejemplo de tcnicas de encolamiento bsico.
s0 192.168.2.0 ROUTER_B 64Kbps s0 128Kbps 192.168.1.0 64Kbps 192.168.3.0 s0 ROUTER_C ROUTER_A Internet
Las redes 192.168.2.0 y 192.168.3.0 utilizan sus enlaces hacia la sede central (ROUTER_A) slo para consultas peridicas en Internet, las cuales nunca llegan a saturar los enlaces de 64Kbps en ningn sentido. Dado que no existe congestin en estas interfaces, el tipo de encolamiento ideal es FIFO. Por el contrario, el trfico hacia Internet en la sede central s llega a saturar el enlace de 128Kbps, tomando en cuenta el trfico de las remotas. Para esta interfaz el tipo de encolamiento ideal es Weighted Fair-Queue, ya que si bien existe congestin, no es necesario, en este caso, un control estricto del trfico saliente ni clases de trfico 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
Pgina 31
10/10/04

b) Ejemplo de tcnicas de encolamiento avanzado.
ROUTER_A 128Kbps s0 s0 ROUTER_B
El enlace entre ROUTER_A y ROUTER_B se congestiona peridicamente debido al trfico de datos excesivo entre ambas sedes. Este trfico es generado principalmente por aplicaciones FTP y HTTP, siendo la ms importante la primera de ellas. Adems, se utilizan 2 canales de voz entre ambas sedes, cada uno de los cuales ocupa 13.3Kbps. Dado que el trfico de voz requiere una baja latencia garantizada, se utiliza LLQ, definiendo adems clases para FTP y HTTP para garantizar ms ancho de banda a la primera de ellas. (Nota: se estn obviando configuraciones de marcacin 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
DISTRIBUCIN 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 Mximo reservado para la voz: 28Kbps Mnimo para FTP: 96 28 = 68 x 0.8 = 54.4Kbps Mnimo 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 segn sus pesos.
Pgina 32
10/10/04

c) Ejemplo de Frame-Relay PIPQ.
ROUTER_B
s0 192.168.2.0 s0 192.168.3.0 110 220
FR
s0
ROUTER_A
192.168.1.0
ROUTER_C
La sede central se conecta con sus dos remotas a travs 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 simultneamente. La gran mayora del trfico en las remotas es de bajada, la red 192.168.3.0 contiene slo servidores de contingencia que continuamente replican la informacin de la sede central, sin embargo, la red 192.168.2.0 es una red de usuarios que hacen consultas en lnea y descarga de informacin vital desde la sede central, siendo para ellos muy importante la rapidez de las descargas. Por esta razn, la sede central otorga mayor prioridad de envo de informacin hacia ROUTER_B, mientras que el trfico 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
Pgina 33
10/10/04

Evitamiento de la congestin 1. Congestin y TCP El comportamiento de los flujos TCP est estrechamente relacionado con la congestin en las interfaces. Primero repasemos algunas caractersticas del trfico de tipo TCP: - El trfico TCP utiliza confirmaciones de recepcin (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 tamao de ventana. - Al comenzar una sesin TCP, el valor del tamao de ventana es pequeo, pero este va creciendo exponencialmente a medida que el emisor va recibiendo confirmaciones del receptor. El receptor siempre enva un ACK pidiendo el segmento que espera recibir. - Cuando un segmento no llega a su destino, el receptor seguir pidiendo que el emisor le enve ese segmento mediante ACKs, obligndolo a retransmitir el segmento. Luego de la retransmisin, el emisor baja el tamao de ventana a la mitad asumiendo que la prdida se debi a una congestin, para as ajustarse al ancho de banda disponible y tratar de no perder ms paquetes. Este comportamiento es llamado Slow Start.
Tx N N+1 ACK N+1 N+3 N+1 N+1 N+1 N+7 N+3 ACK ACK N+3 ACK N+1 N+1
N+2
Rx
Tx N ACK
Rx
ACK N+3
N+4
COMPORTAMIENTO TCP SIN PRDIDAS
COMPORTAMIENTO TCP CON PRDIDAS (SLOW START)
Pgina 34
10/10/04

Como vemos, las prdidas de paquetes afectan a las transferencias TCP. Slow Start es un buen mecanismo para contrarrestar este problema de congestin, pero cuando tenemos muchos flujos TCP simultneos, todos se ven afectados por las prdidas de paquetes generadas por congestin. Entonces, muchos de los flujos bajan su tamao de ventana simultneamente, resultando en una disminucin masiva de la tasa de transferencia, luego todos vuelven a subir al mismo tiempo y as sucesivamente. Este fenmeno se conoce como TCP Global Synchronization.
Utilizacin del enlace Tasa mxima (congestin) Tasa promedio
Tiempo
As, tenemos una estrecha relacin entre el mecanismo de descarte y la performance de TCP. En la mayora de los sistemas de encolamiento el mecanismo ser Tail Drop, el cual descarta paquetes agresivamente en momentos de congestin, sin distincin de clase o prioridad, provocando el fenmeno visto en el prrafo anterior. El mecanismo de descarte de WFQ es ms 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 tambin perjudica a TCP de la siguiente manera: los flujos ms agresivos llenarn las colas rpidamente (siguiendo el mecanismo de ajuste de ventana de TCP), por lo que no sern los primeros en descartarse por Tail Drop, causando una rpida y constante congestin. Muchos de los paquetes pequeos o de flujos ms frgiles no lograrn ingresar a la cola y sern descartados por Tail Drop (TCP Starvation), mientras que los que logren ingresar a la cola sufrirn una gran latencia pues sta estar llena por flujos agresivos (TCP Delay).
Tail Drop COLA Experimenta una constante congestin
TCP STARVATION Flujo frgil y precedence 5

Autor: Gianpietro Lavado Chiarella Pgina 35
TCP DELAY Flujo agresivo y precedence 0

10/10/04

2. RED : Random Early Detection RED es un mecanismo que descarta paquetes aleatoriamente antes de que la cola se llene, as, evita la congestin y la consecuente activacin de Tail Drop. El siguiente grfico detalla algunos conceptos que definen un perfil RED y su funcionamiento:
Probabilidad de descarte 100 % Ningn descarte Descarte RED Descarte Tail Drop
10 % 32 40 Ocupacin promedio de la cola
El descarte aleatorio de RED se da entre cierto rango de tamao 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 tamao de ventana antes de llegar a la congestin. Despus de aplicar RED, el comportamiento de TCP durante la congestin se aprecia en el siguiente grfico (comparar con grfico de la pgina 35):
Utilizacin del enlace Tasa mxima (congestin) Tasa promedio
Tiempo
Podemos apreciar que la utilizacin promedio del enlace aumenta. RED slo tiene efecto sobre trficos TCP y se debe aplicar en las interfaces donde se espera que ocurra congestin. La implementacin de Cisco para RED se llama Weighted Random Early Detection (WRED) y la veremos a continuacin.

3. WRED : Weighted Random Early Detection La idea de WRED es aplicar distintos niveles de RED a diferentes clases de trfico mediante la configuracin de distintos perfiles. As, se logra evitar la congestin descartando tempranamente y con mayor agresividad el trfico TCP menos prioritario mientras que se favorece a los dems. Las caractersticas principales de WRED: - Se pueden definir varios perfiles RED (distintos rangos de descarte para aplicar a diferentes clases de trfico). - La eleccin del perfil a utilizar se hace segn 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 trfico y el mtodo de descarte por defecto sea Tail Drop. Esto nos lleva a centrarnos a la configuracin de WRED en CBWFQ/LLQ (Class-based WRED CB-WRED). El siguiente grfico muestra la configuracin de perfiles de WRED por defecto, los cuales se basan en el valor de IP precedence de cada paquete:
Probabilidad de descarte 100 %
10 %
20 22 24 26 28 30 32 34 37 IP PREC 0 1 2 3 4 5 6 7 RSVP
40
Ocupacin promedio de la cola
El grfico indica que mientras ms alto sea el valor de IP precedence, menor ser el rango de descarte aleatorio para dicho trfico. As, los trficos menos prioritarios (IP precedence 0) sern los que se descarten primero, ms o menos cuando la cola est a la mitad (por defecto).
Pgina 37
10/10/04

Configuracin 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 poltica:
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 mnimo del rango de descarte aleatorio max = valor mximo del rango de descarte aleatorio 1/probabilidad = probabilidad de descarte en el mximo 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 poltica:
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 utilizacin promedio de la cola para verificar en qu rango de descarte se encuentra el trfico, se admiten rfagas de trfico que pueden sobrepasar temporalmente el rango definido sin sufrir el descarte aleatorio. La admisin de rfagas se puede controlar con el siguiente comando:
random-detect exponential-weighting-constant [n]
Teniendo en cuenta la frmula de clculo de utilizacin de cola: Qprom(t+1) = Qprom(t) x (1-2-n) + Qt x 2-n Para altos valores de n, WRED admite rfagas cortas, mientras que para bajos valores, WRED ser ms sensible a las rfagas y el descarte ser ms estricto. El valor por defecto es 9 y funciona bien para la mayora de escenarios.
Pgina 38
10/10/04

4. Ejemplos de configuracin
ROUTER_B 96Kbps
ROUTER_C 96Kbps
ROUTER_A
VPN 64Kbps
ROUTER_GLCH
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 mayora del trfico generado por las remotas termina en la sede central, hay momentos pico en que el trfico generado por stas satura la interfaz de salida de ROUTER_A hacia la VPN. El volumen de trfico es generado por aplicaciones Internet Explorer, Kazaa, pcAnywhere, SQL Server, entre otros. Siendo este trfico TCP en su mayora, se aplica CBWRED en ROUTER_A para evitar la congestin 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
PERFILES DE WRED PARA ROUTER_A 20 % 20 25 30 40
100%
Pgina 39
10/10/04

Control de trfico: Policy & Shaping 1. Introduccin al control de trfico El control de trfico sirve principalmente para limitar la tasa de transferencia de un flujo de datos. Existen dos formas de controlar el trfico: Traffic Policing y Traffic Shaping. Veamos las caractersticas de cada una de ellas: TRAFFIC POLICING - Aplicable en trfico entrante o saliente. - El trfico que excede el lmite es descartado. - Soporta marcacin de paquetes. - Uso bajo de los buffers. - Los descartes aumentan las retransmisiones TCP. TRAFFIC SHAPING - Aplicable slo en trfico saliente. - El trfico que excede el lmite es encolado (mayor latencia) - No soporta marcacin de paquetes. - Uso alto de los buffers. - El encolamiento minimiza las retransmisiones TCP.
A fin de comprender mejor el funcionamiento y configuracin del control de trfico, debemos tener claro primero los siguientes conceptos.- CIR (Commited Information Rate): Tasa de transferencia garantizada. - Bc = Tamao de rfaga normal. - Tc = Tiempo que durar una rfaga en ser transmitida. - PIR (Peak Information Rate): Tasa de transferencia mxima. - Be = Tamao de rfaga de exceso. Las siguientes frmulas sirven para calcular cualquiera de estos valores: CIR = Bc_ Tc Be = (PIR - 1) x Bc CIR
*Be y Bc en bits
Pgina 40
10/10/04

2. Implementacin de Traffic Policing Esta herramienta es normalmente utilizada en los siguientes casos: - Fijar una tasa de transferencia mxima 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 lmites a nivel de clases definidas por usuario. Segn el valor de la tasa de transferencia actual se puede tomar la accin de transmitir, descartar o transmitir remarcando el paquete (ip precedence, dscp, de, etc). La configuracin bsica, 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 accin que se tomar cuando la tasa de transferencia actual no ha pasado el valor de CIR configurado. Por defecto la accin ser transmitir (transmit). exceed-action: la accin que se tomar cuando la tasa de transferencia actual ha pasado el valor de CIR y est dentro del lmite de exceso definido por Be. Por defecto la accin ser descartar (drop). violate-action: la accin que se tomar cuando la tasa de transeferencia actual vaya ms all de los lmites de exceso establecidos por Be. Por defecto la accin 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 tcnica an 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 lmites 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. Implementacin de Traffic Shaping Esta herramienta es normalmente utilizada en los siguientes casos: - Prevenir congestin en redes donde se tienen distintos valores de ancho de banda en cada acceso. - Regular parmetros 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 adems la tasa de transferencia mnima a la cual se ajustar el trfico cuando de recibe algn BECN o FECN:
traffic-shape adaptive [bit-rate] (acta al recibir BECNs) traffic-shape fecn-adapt (adicional, para FECNs)
Tambin es posible aplicar GTS slo para cierto trfico de salida definido con un ACL: traffic-shape group [#ACL] [CIR] [Bc] [Be] b) Class-based shaping Habilita GTS dentro de una configuracin basada en MQC y puede usarse en combinacin con CBWFQ y LLQ. Se configura dentro de la clase de la siguiente manera: shape [average/peak] [CIR/percent] [Bc] [Be] La opcin average es la ms recomendada pues transmite a una tasa igual al PIR slo despus de un periodo de poco trfico, en cambio peak transmite a la tasa mxima (PIR) todo el tiempo, produciendo descarte de paquetes si la red est congestionada. La opcin peak slo debe usarse cuando sobran recursos en la red y las aplicaciones toleran prdidas de paquetes ocasionales.
Pgina 42
10/10/04

El comando shape max-buffers vara el tamao de la cola en nmero de paquetes, de esta forma se puede controlar hasta cuntos 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 combinacin con CBWFQ, se puede anidar una poltica a la otra de manera jerrquica 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 aplicara la poltica SHAPE, de esta forma se est repartiendo manualmente el ancho de banda entre los diversos tipos de trfico y limitando el trfico total a 512000. Al igual que en GTS, es posible la interaccin con los bits FECN y BECN en interfaces frame-relay, emulando as algunos beneficios de FRTS (al final de este captulo).
shape adaptive [bit-rate] (acta al recibir BECNs) shape fecn-adapt (adicional, para FECNs)
c) Distributed Traffic Shaping DTS se configura exactamente igual que Class-based shaping, pero est diseado 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 slo cef. d) Frame-Relay Traffic Shaping Este mecanismo permite modificar cualquier parmetro de control de trfico de un PVC frame-relay. Adems, puede utilizarse en

conjunto con CBWFQ, LLQ y dems tcnicas de encolamiento en la mayora de las plataformas. La configuracin de todos los parmetros de FRTS se aplica dentro de una clase frame-relay creada en el modo de configuracin global:
map-class frame-relay [nombre]
Los parmetros configurables dentro de esta clase varan mucho entre versiones de IOS, a continuacin se muestran los ms 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 mnima de transferencia cuando se detecta congestin en el PVC. service-policy output [nombre]: permite aplicar CBWFQ o LLQ como tcnicas de encolamiento. [no] frame-relay adaptive shaping [becn/foresight]: habilita o deshabilita la variacin automtica 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 tamao mximo de trama habilitando fragmentacin FRF.12. frame-relay priority-group [#]: habilita PQ como tcnica 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, tenindose las siguientes alternativas:
frame-relay class [nombre] para interfaces y subinterfaces. class [nombre] para PVCs, aplicado dentro de la configuracin 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 tendrn un valor de CIR de 56Kbps por defecto. - Se debe configurar los parmetros de control de trfico asumiendo slo un mximo del 95% del ancho de banda fsico 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 automtico del CIR (frame-relay adaptive shaping), desactivando esta opcin y/o igualando el minCIR al CIR. De esta forma se garantiza que los

paquetes de voz no sean descartados por saturacin. Adems, se recomienda hacer que el Bc sea la centsima parte del CIR para evitar grandes rfagas 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 configuracin de traffic-shaping no son aceptados por todas las plataformas, sobretodo FRTS, por lo que la forma de aplicacin de una poltica MQC (policy-map) vara. La siguiente tabla detalla las restricciones:
Plataforma Interfaz
7500/12000 (VIP: DTS) Aplicar la poltica MQC en la interfaz global Aplicar la poltica MQC en la subinterfaz No aplicable
26xx, 36xx, 7200, etc (no VIP: FRTS, CBS, etc) Poltica MQC aplicable, pero sin FRTS Aplicar la pltica MQC dentro del map-class y aplicar ste en la subinterfaz Aplicar la pltica MQC dentro del map-class y aplicar ste en el PVC
Interfaz global
Subinterfaz Frame-Relay
PVC Frame-Relay
Pgina 45
10/10/04

4. Ejemplos de configuracin a) Ejemplo de Class-based policing
ROUTER_A PPP 1024Kbps Backup FR 64/64/448Kbps 10.120.1.0 /24 FR 192/192/384Kbps ROUTER_B
10.120.2.0 /24
FR 192/192/384Kbps ROUTER_D 192.168.200.0 /24
ROUTER_C 192.168.100.0 /24
El enlace PPP de 1024Kbps, de acuerdo a las polticas establecidas por la empresa, debe cursar principalmente trfico 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 msica 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 trfico no tendr lmites. Por otro lado, todo el trfico que sale de la red 192.168.1.0 suele tener como destino la red 192.168.2.0 y viceversa; adems, 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 trfico que intercambien estas redes y que exceda los 192Kbps, sea enrutado a travs 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
Pgina 46
10/10/04

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

b) Ejemplo de GTS y Class-based shaping
CLIENTE A e0.1 e0 CLIENTE B e0.2 PROVEEDOR e0.3 e0 e0 CLIENTE C
Backbone de Internet
La red de la figura muestra las conexiones entre el proveedor y sus clientes a travs subinterfaces ethernet. Se trata de enlaces inalmbricos punto a multipunto tipo bridge en los cuales se utiliza VLANs para poder manejar redes independientes. Cada cliente contrat 512Kbps, la limitacin debe hacerse lo ms cercano posible al origen del trfico optimizando as la utilizacin de los enlaces inalmbricos. Adems cada cliente solicit priorizar el trfico de envo 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
Pgina 48
10/10/04

c) Ejemplo de Frame-relay traffic shaping
ROUTER_B
s0 192.168.2.0 s0 192.168.3.0 500 600
FR
s0
ROUTER_A
192.168.1.0
ROUTER_C
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 trfico salga limitado desde los CPE y no existan descartes en los switches frame-relay de la red del proveedor. Adems, se desea que el trfico del aplicativo del cliente, el cual utiliza los puertos tcp 1003 y 1004, tenga prioridad estricta sobre cualquier otro tipo de trfico.
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
Pgina 49
10/10/04

Mecanismos de eficiencia en enlaces WAN 1. Introduccin a los mecanismos de eficiencia Los mecanismos que veremos a continuacin, buscan optimizar el uso de los enlaces WAN, minimizando el consumo de ancho de banda de ciertos protocolos. Bsicamente existen tres mecanismos de eficiencia para redes WAN: - Compresin de datos (payload): stacker, predictor, MPPC e IP PCP. - Compresin de cabeceras: TCP, CB-TCP, RTP y CB-RTP. - Fragmentacin de tramas: MLP LFI, FRF.12 y FRF.11c. 2. Compresin de datos (payload) Este tipo de compresin generalmente reduce el tamao 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 disminucin de la latencia en el enlace. Se configura enlace por enlace y en ambos extremos, pudindose configurar en un enlace sin afectar al resto de la red.
Header Capa 2 Payload Capa 2 (Paquete IP Capa 3)
Algoritmo de compresin
Header Capa 2
Payload Capa 2 comprimido
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 nmero 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 nmero de ndice de la secuencia del diccionario; de otra forma, contina recorriendo las secuencias en el diccionario y comparndolas con las secuencias de datos. Slo es aplicable en PPP y LAPB, siendo el algoritmo ms rpido pero el que comprime menos que otros. Consume ms recursos de memoria que de procesador (CPU). Se habilita con el siguiente comando en la interfaz:
compress predictor
Stacker: utiliza el algoritmo de compresin Lempel-Ziv, el cual reemplaza secuencias de caracteres por cdigos ms pequeos, creando a su vez un diccionario formado por todos los reemplazos.
Pgina 50
10/10/04

Slo es aplicable en PP, LAPb y HDLC. En general, consume ms recursos de CPU que de memoria. Se habilita con el siguiente comando en la interfaz: compress stac [distributed ] [csa <slot>] [caim] Adicionalmente la opcin distributed concentrar el procesamiento de la compresin en una tarjeta VIP en lugar de hacerlo en el CPU. LA opcin csa habilita la compresin por hardware concentrando el procesamiento en un mdulo externo de compresin (compress service adapter; disponible para la lnea 7200 y 7500). Por otro lado, la opcin caim se utiliza para habilitar la compresin por hardware cuando se dispone de una tarjeta CAIM (Compress Advanced Interface Module). Microsoft Point-to-point compression (MPPC): Este tipo de compresin es similar a la stacker, pero funciona entre un router Cisco y un cliente de Microsoft como Windows, slo 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 algn algoritmo de encriptacin de capa 3 como IPSec, puesto que estos no permiten la configuracin de compresin en capa 2. No se detallarn aspectos de configuracin pues generalmente esta opcin est soportada por defecto en mdulos VPN externos. Recomendaciones en el uso de compresin de datos: - No utilizar compresin por software (CPU) cuando el procesador sobrepasa una utilizacin del 40% en promedio. Tener en cuenta el lmite de ancho de banda para comprimir en las distintas plataformas cuando se utiliza compresin por software (CPU):
Mtodo Stacker Predictor Serie 1000 128 256 Serie 3000 128 256 Serie 4000 256 500 Serie 4500 500 T1 Serie 4700 T1 2xT1 Serie 7000 256 500
Cuando el cuello de botella se encuentra en la carga del enrutador, utilizar el mtodo Predictor; cuando el cuello de botella se encuentra en el enlace o se dispone de tarjetas CSA o CAIM, utilizar el mtodo Stacker. No utilizar compresin de datos cuando se sabe que la mayora de los datos ya vienen comprimidos (MPEG, JPEG, etc).
Pgina 51 10/10/04

3. Compresin de cabeceras La compresin de cabeceras se realiza en las capas 3 y 4, incrementando el ancho de banda disponible y reduciendo la latencia. Estas ventajas slo se logran en protocolos cuyo payload es pequeo, ya que en estos casos las cabeceras ocupan una parte significativa del ancho de banda. Protocolos como VoIP (RTP) y Telnet (TCP) tienen esta caracterstica. Se configura enlace por enlace y en ambos extremos, pudindose configurar en un enlace sin afectar al resto de la red. Este mecanismo es ms efectivo en enlaces de baja velocidad.
Header Capa 2 Header Capa 3 Header Capa 4+ Payload
Algoritmo de compresin
Header Capa 2
cmp HDR
Payload
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 sesin TCP/IP siempre es transmitida sin comprimir, las cabeceras siguientes slo incluyen el ndice de la sesin TCP/IP y los parmetros variables. Se habilita con el siguiente comando en la interfaz: [frame-relay*] ip tcp header-compression Tambin 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 sesin RTP/UDP/IP siempre es transmitida sin comprimir, las cabeceras siguientes slo incluyen el ndice de la sesin RTP/UDP/IP y los parmetros 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 Tambin es posible habilitar TCP header-compression en clases MQC, configurando el siguiente comando dentro de la clase: compression header ip rtp
* solo para interfaces frame-relay
* solo para interfaces frame-relay

4. Fragmentacin de tramas La transmisin de paquetes termina siempre en la cola fsica 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 fragmentacin de tramas es un mecanismo de capa 2 que sirve para dividir una trama grande en varias ms pequeas, permitiendo as que una trama pequea, como la de un paquete de voz, sea intercalada con los fragmentos de una trama ms grande.
SIN FRAGMENTACIN
cola de salida CON FRAGMENTACIN
cola de salida
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 serializacin (ver pg.4) y se calcula de la siguiente forma:
Ts = Tamao de paquete_ Ancho de banda
El tiempo de serializacin recomendado para cuando se tienen paquetes de voz y datos sobre la misma interfaz de salida es de 10 a 15ms. La fragmentacin permite controlar el tamao de paquete mximo garantizando de esta manera una adecuada serializacin. La siguiente tabla nos muestra el tamao de fragmento ideal en bytes para lograr tiempos de serializacin de 10 y 15ms.
Ts 10ms 15ms 56Kbps 70 84 64Kbps 80 96 128Kbps 160 192 256Kbps 320 384 512Kbps 640 768 768Kbps 1000 1152 1536Kbps 2000 2304
*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.
Pgina 53
10/10/04

Existen los siguientes tipos de fragmentacin.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 fragmentacin 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 fragmentacin FRF.12 soportado por Cisco es el end-toend, esto quiere decir que la fragmentacin debe configurarse a ambos extremos del PVC, de otra forma los paquetes grandes se podrn transmitir en una sola direccin. Debe tenerse en cuenta adems, que el tamao de fragmento debe ser mayor al tamao 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 versin 12.1(5)T; se debe hacer lo siguiente: - Configurar la fragmentacin 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.
Pgina 54
10/10/04

5. Ejemplos de configuracin a) Ejemplo de compresin de cabeceras.
ROUTER_A s0 Satelital 64Kbps s0 2FxO ROUTER_B
2FxO
En este enlace punto a punto se tienen aplicaciones de voz y datos a travs de un enlace satelital de 64Kbps. Dada la naturaleza del enlace, la latencia es un tema crtico, sobre todo para la voz, por lo que se busca disminuirla con todos los mecanismos posibles; adems, el ancho de banda disponible es bajo, por lo tanto se necesita adems un mecanismo de optimizacin en el uso del mismo. Entre los protocolos ms utilizados en este enlace, se encuentran la voz comprimida a con g.729 (RTP, payload pequeo) y Telnet (TCP, payload pequeo), por lo que se configura compresin para ambos, as se disminuye la latencia y el ancho de banda utilizado por estas aplicaciones. Adicionalmente se prioriza la voz sobre cualquier otra aplicacin 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
Pgina 55
10/10/04

b) Ejemplo de fragmentacin FRF.12.
ROUTER_B
s0 128Kbps 500 s0
FR
s0 600 128Kbps
ROUTER_A
ROUTER_C
En este ejemplo, similar al de la pgina 49, se tiene adems comunicaciones de voz sobre IP cursando la red frame-relay, por lo cual se ha decidido aplicar fragmentacin a las tramas para dsiminuir la latencia de los paquetes de voz. Se configura FRTS para poder aplicar la fragmentacin y garantizar que el trfico 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 compresin de cabeceras para mejorar an ms 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
Pgina 56
10/10/04

Resolucin de problemas 1. Comandos tiles a) Clasificacin y marcacin de paquetes - show class-map: muestra la configuracin de todas las clases MQC configuradas. - show policy-map: muestra la configuracin de todas las polticas MQC aplicadas a las clases. - show policy-map interface [interfaz]: muestra la poltica aplicada a la interfaz y estadsticas sobre paquetes los clasificados. - show ip nbar protocol-discovery: muestra estadsticas de los protocolos que cursan las interfaces en las cuales NBAR est habilitado. b) Encolamiento - show interface [interfaz]: muestra el mtodo de encolamiento aplicado a la interfaz (WFQ/FIFO) y estadsticas del mismo. - show queue [interfaz]: muestra estadsticas de WFQ. - show policy-map interface [interfaz]: muestra estadsticas de CBWFQ o LLQ. c) Evitamiento de la congestin - show policy-map interface [interfaz]: muestra estadsticas RED aplicado en clases (WRED). d) Control de trfico - show policy-map: muestra la configuracin de todas las polticas de control de trfico aplicadas en clases MQC. - show policy-map interface [interfaz]: muestra estadsticas de ClassBased Policing o Shaping. - show frame-relay pvc [dlci]: muestra estadsticas de FRTS y las polticas de encolamiento aplicadas. e) Mecanismos de eficiencia - show policy-map interface [interfaz]: muestra estadsticas de ClassBased compressed RTP o TCP. - show interfaces multilink [interfaz[: muestra estadsticas de fragmentacin MLP. - show frame-relay fragment [dlci]: muestra la cantidad de paquetes fragmentados transmitidos y recibidos. - show frame-relay pvc [dlci]: muestra estadsticas de fragmentacin 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/prod ucts_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/prod ucts_feature_guide09186a00802000a7.html Para consultas acerca de este documento, comunicarse con: Gianpietro Lavado Chiarella glavado@impsat.com anexo 5470
Pgina 58
10/10/04

Cisco QoS v1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco QoS v1

Uploaded by

Copyright:

Available Formats

Configuracin y manejo de calidad de servicio en enrutadores Cisco

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Descripcin de QoS en Cisco.

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Int. Serial0.1 Int. Serial0.3

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

(ms informacin: www.cisco.com/cgi-bin/tablebuild.pl/pdlm)

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

FxS 1234 ROUTER_A

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

512Kbps 512Kbps 512Kbps

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

ESTRUCTURA TPICA DE COLA DE SOFTWARE ENVO O DESCARTE ENVO O DESCARTE COLA 1

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

COLA DE SOFTWARE FIFO

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

COLA DE SOFTWARE WEIGHTED FAIR-QUEUE

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

A LA COLA A LA COLA DESCARTE DESCARTE DESCARTE*

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

COLA DE SW CLASS-BASED WEIGHTED FAIR-QUEUE TAIL DROP

CBWFQ SCHEDULER (WRR)

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

Luego se definen las polticas.-

Finalmente se aplica la poltica a la interfaz:

interface x service-policy output [nombre de poltica]

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

COLA DE SOFTWARE LLQ ALTA PRIORIDAD CLASE AP?

COLA DE PRIORIDAD (FIFO)

CBWFQ SCHEDULER (WRR)

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco

BANDWIDTH 128 8 6 4 2 CBWFQ SCHEDULER BANDWIDTH 64 7 5 3 1 8 6 3 Z Y X 4 2 1 S R Q P

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS) en enrutadores Cisco