Configuracion y Manejo de Calidad de Ser PDF

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

Configuración de calidad de servicio (QoS)
en enrutadores Cisco
Í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
Evitamiento de la congestión....................................................................34
1. Congestión y TCP
2. RED : Random Early Detection
3. WRED : Weighted Random Early Detection
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
Mecanismos de eficiencia en enlaces WAN………………………………50

1. Introducción a los mecanismos de eficiencia
2. Compresión de datos (payload)
Autor: Gianpietro Lavado Chiarella Página 2 10/10/04

3. Compresión de cabeceras
4. Fragmentación de tramas
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:
1 2 3
POLÍTICA 1: Interfase
CLASE VOZ
BW y Delay Ethernet0
garantizados
CLASE FTP
POLÍTICA 2: Int. Serial0.1
Mejor esfuerzo,
CLASE SQL BW limitado Int. Serial0.3
class-map match-any VOZ policy-map VOZ_POL interface ethernet0

match access-group 10 class VOZ service-policy output VOZ_POL
match ip precedence 5 priority 100
set ip dscp cs5 interface serial0.1
class-map match-any FTP frame-relay interface-dlci 1
match access-group 101 policy-map DATOS service-policy output VOZ_POL
class FTP
class-map match-all SQL police 128000 1280 0… interface serial0.3
match access-group 110 class SQL frame-relay interface-dlci 3
match access-group 111 bandwidth 100 service-policy output DATOS
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.

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]
VALOR DECIMAL VALOR BINARIO NOMBRE

0 000 routine
1 001 priority
2 010 immediate
3 011 flash
4 100 flash-override
5 101 critical
6 110 internet
7 111 network
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 000000 Default
1 001000 cs1
2 010000 cs2
3 011000 cs3
4 100000 cs4
5 101000 cs5
6 110000 cs6
7 111000 cs7
46 101110 ef
10 001010 af11
12 001100 af12
14 001110 af13
18 010010 af21
20 010100 af22
22 010110 af23
26 011010 af31
28 011100 af32
30 011110 af33
34 100010 af41
36 100100 af42
38 100110 af43
*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.

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.

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

192.168.2.0
s0
192.168.1.0
ROUTER A
s1/1
.2 .3
192.168.3.0 ROUTER C ROUTER_D

s0
ROUTER B
.2 .3
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 ROUTER_B
class-map match-any FILESQL class-map match-any FILESQL
match access-group 10 match access-group 10
policy-map DATOS policy-map DATOS

class FILESQL class FILESQL
set ip precedence 5 set ip precedence
interface serial0 interface serial0

service-policy output DATOS service-policy output DATOS
access-list 10 permit host 192.168.2.2 access-list 10 permit host 192.168.3.2

access-list 10 permit host 192.168.2.3 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

b) Ejemplo de clasificación y marcación en dial-peers
FxS s0 FxS
s0
1234 ROUTER_A ROUTER_B 2345
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 ROUTER_B
class-map match-any VOZ class-map match-any VOZ
match ip precedence 5 match ip precedence 5
policy-map POLIVOZ policy-map POLIVOZ

class VOZ class VOZ
priority 15 priority 15
dial-peer voice 1 voip dial-peer voice 1 voip

destination-pattern 2… destination-pattern 1…
ip qos dscp cs5 media ip qos dscp cs5 media
ip qos dscp cs5 signaling ip qos dscp cs5 signaling

service-policy output POLIVOZ service-policy output POLIVOZ

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:
100Mbps 64Kbps
flujo de tráfico
512Kbps
512Kbps 512Kbps
512Kbps flujo de tráfico
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.

- 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)
IP IP IP IP
COLA SW COLA HW INTERFASE
(FIFO)
ESTRUCTURA TÍPICA DE COLA DE SOFTWARE
ENVÍO O
COLA 1
DESCARTE
ENVÍO O
CLASIFICACIÓN COLA 2 PROGRAMADOR
DESCARTE
(SCHEDULER)
.
.
.
ENVÍO O
COLA n
DESCARTE

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:
1 2
COLA DE SOFTWARE FIFO
UNA TAIL 1 2 3 COLA

UNA SOLA FIFO HW
SOLA DROP COLA SCHEDULER (FIFO)
CLASE
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).

- 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:
C B
COLA DE SOFTWARE WEIGHTED FAIR-QUEUE
¿FLUJO WFQ
DROP COLA 1
1?
¿FLUJO WFQ
COLA 2 B C A COLA
2? DROP
WFQ HW
SCHEDULER (FIFO)
.
.
.
¿FLUJO WFQ
n? DROP COLA 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:
Ancho de banda Número de colas

B ≤ 64Kbps 16
64K < B ≤ 128K 32
128K < B ≤ 256K 64
256K < B ≤ 512K 128
B ≥ 512Kbps 256
- 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.

N > HQO? N > CDT? Peor FT? + ACCIÓN N = Número de paquetes en la

NO NO X A LA COLA cola al llegar un nuevo
NO SI NO A LA COLA paquete.
HQO = Hold-queue out limit
SI X SI DESCARTE
CDT = Congestive discard
SI X NO DESCARTE
threshold
NO SI SI DESCARTE* 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 (100ms)
B1 (300ms)
A2 (20ms)
A3 (10ms)
B2 (300ms)
t 100 70 60 50 0ms
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:

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
B2 B1 A3 A2 A1
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
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.

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:
C B
COLA DE SW CLASS-BASED WEIGHTED FAIR-QUEUE
TAIL
¿CLASE COLA 1
1? DROP
TAIL
¿CLASE COLA 2 B C A COLA
DROP CBWFQ
2? HW
SCHEDULER (FIFO)
(≈WRR)
.
.
.
¿CLASE TAIL
PD? DROP COLA PD
PD = Por defecto

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 128
CLASE A 8 6 4 2
CBWFQ
SCHEDULER 8 6 3 4 2 1
BANDWIDTH 64
CLASE B 7 5 3 1
QUEUE SIZE 4

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:

C B
COLA DE SOFTWARE LLQ – ALTA PRIORIDAD
¿CLASE COLA DE
AP? CAR
PRIORIDAD (FIFO)
AP = Alta Prioridad
COLA DE SOFTWARE LLQ – BAJA PRIORIDAD (CBWFQ)
TAIL
¿CLASE COLA 1
1? DROP
TAIL COLA
¿CLASE COLA 2 HW
2? DROP CBWFQ
A B C (FIFO)
SCHEDULER
(≈WRR)
.
.
.
¿CLASE TAIL
PD? DROP COLA PD
PD = Por defecto
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

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:
PRIORITY 32
Z Y X S R Q P
BANDWIDTH 128
8 6 4 2
CBWFQ 8 6 3 Z Y X 4 2 1 S R Q P
SCHEDULER
BANDWIDTH 64
7 5 3 1
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]

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.
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.
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 No se necesita otra

congestionada? NO técnica que FIFO
SI
¿Se requiere un Utilizar Weighted Fair

control estricto? NO Queuing
SI
¿Aplicaciones Utilizar CBWFQ

sensibles a delay? NO o Custom Queuing
SI
Utilizar LLQ, PQ o PIPQ

a) Ejemplo de técnicas de encolamiento básico.
s0
192.168.2.0 64Kbps
ROUTER_B
s0 Internet
128Kbps
192.168.1.0
ROUTER_A
64Kbps
s0
192.168.3.0
ROUTER_C
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.
ROUTER_A ROUTER_B
128Kbps
s0 s0
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 ROUTER_B
match ip precedence 5 match ip precedence 5
class-map match-any FTP class-map match-any FTP
match protocol ftp match protocol ftp
class-map match-any HTTP class-map match-any HTTP
match protocol http match protocol http
policy-map POLICOLA policy-map POLICOLA

class VOZ class VOZ
class FTP class FTP
bandwidth remaining percent 80 bandwidth remaining percent 80
class HTTP class HTTP
bandwidth remaining percent 20 bandwidth remaining percent 20

bandwidth 128 bandwidth 128
service-policy output POLICOLA 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.

c) Ejemplo de Frame-Relay PIPQ.
ROUTER_B
s0
110
192.168.2.0
FR s0
220
ROUTER_A 192.168.1.0
s0
192.168.3.0
ROUTER_C
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 ROUTER_C
bandwidth 512 bandwidth 512
encapsulation frame-relay encapsulation frame-relay
frame-relay interface-dlci 110 frame-relay interface-dlci 220

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.
Tx Rx Tx Rx
N N
N+1 N+1
ACK ACK
N+1
N+1
N+2
N+3 N+1
ACK
N+1
N+3
N+1
N+3
N+7 ACK
ACK
N+3
N+4 ACK
COMPORTAMIENTO TCP SIN COMPORTAMIENTO TCP CON

PÉRDIDAS 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.
Utilización
del enlace Tasa máxima (congestión)
Tasa promedio
Tiempo
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).
Tail Drop Experimenta una constante congestión
COLA
TCP STARVATION TCP DELAY

Flujo frágil y Flujo agresivo y
precedence 5 precedence 0

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:
Probabilidad Ningún Descarte Descarte
de descarte descarte RED Tail Drop
100 %
10 %
32 40 Ocupación
promedio de la cola
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):
Utilización
del enlace Tasa máxima (congestión)
Tasa promedio
Tiempo
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.

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:
Probabilidad
de descarte
100 %
10 %
20 22 24 26 28 30 32 34 37 40 Ocupación
promedio de la cola
IP PREC Æ 0 1 2 3 4 5 6 7 RSVP
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).

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.

ROUTER_B
96Kbps
ROUTER_C VPN 64Kbps

ROUTER_A ROUTER_GLCH
96Kbps
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 ROUTER_A

class-map match-any ALTA class-map match-any RED_BAJA
match protocol http match ip precedence 0
match protocol sqlserver class-map match-any RED_NORMAL
class-map match-any BAJA match ip precedence 2
match protocol kazaa2 class-map match-any RED_ALTA
match protocol fasttrack match ip precedence 4
match protocol pcanywhere
policy-map MARCAR
policy-map MARCAR class RED_BAJA
class ALTA bandwidth 8
set ip precedence 4 random-detect
class BAJA random-detect precedence 0 20 40 20
set ip precedence 2 class RED_NORMAL
class class-default bandwidth 8
set ip precedence 0 random-detect
random-detect precedence 0 25 40 20
class RED_ALTA
bandwidth 32
random-detect
100%
random-detect precedence 0 30 40 20
Å PERFILES DE WRED
PARA ROUTER_A
20 %
20 25 30 40

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 TRAFFIC SHAPING

- Aplicable en tráfico - Aplicable sólo en tráfico
entrante o saliente. saliente.
- El tráfico que excede el - El tráfico que excede el límite es
límite es descartado. encolado (mayor latencia)
- Soporta marcación de - No soporta marcación de
paquetes. paquetes.
- Uso bajo de los buffers. - Uso alto de los buffers.
- Los descartes aumentan las - El encolamiento minimiza las
retransmisiones TCP. 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:
CIR = Bc_ Be = (PIR - 1) x Bc

Tc CIR
*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]
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]
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
class trafficC
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:
Plataforma 7500/12000 26xx, 36xx, 7200, etc

(VIP: DTS) (no VIP: FRTS, CBS,
Interfaz etc)
Interfaz Aplicar la política

MQC en la Política MQC aplicable,
global pero sin FRTS
interfaz global
Aplicar la política Aplicar la pólítica MQC

Subinterfaz MQC en la dentro del map-class y
Frame-Relay subinterfaz aplicar éste en la
subinterfaz
Aplicar la pólítica MQC
PVC Frame-Relay No aplicable dentro del map-class y
aplicar éste en el PVC

a) Ejemplo de Class-based policing
ROUTER_A ROUTER_B
PPP 1024Kbps
Backup FR 64/64/448Kbps
10.120.2.0 /24
10.120.1.0 /24
FR 192/192/384Kbps
FR 192/192/384Kbps
ROUTER_C ROUTER_D
192.168.100.0 /24 192.168.200.0 /24
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
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
service-policy output TODO

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
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
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
e0.1
Backbone CLIENTE B
de Internet
e0.2
e0
PROVEEDOR
e0.3
CLIENTE C
e0
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
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
interface e0.3

c) Ejemplo de Frame-relay traffic shaping
ROUTER_B
s0
500
192.168.2.0
FR s0
600
ROUTER_A 192.168.1.0
s0
192.168.3.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 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 ROUTER_B y ROUTER_C

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

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.
Header Payload Capa 2 Algoritmo de Header Payload Capa 2

Capa 2 (Paquete IP Capa 3) compresión 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 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.

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):
Método Serie 1000 Serie 3000 Serie 4000 Serie 4500 Serie 4700 Serie 7000
Stacker 128 128 256 500 T1 256
Predictor 256 256 500 T1 2xT1 500
- 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).

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.
Header Header Header Algoritmo de Header cmp

Payload compresión Payload
Capa 2 Capa 3 Capa 4+ Capa 2 HDR
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.
[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.
[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

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.
SIN FRAGMENTACIÓN
cola de salida
CON FRAGMENTACIÓN
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 serialización’ (ver pág.4) y se calcula de la siguiente forma:
Ts = Tamaño de paquete_
Ancho de banda
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.
Ts 56Kbps 64Kbps 128Kbps 256Kbps 512Kbps 768Kbps 1536Kbps

10ms 70 80 160 320 640 1000 2000
15ms 84 96 192 384 768 1152 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.

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.

ROUTER_A ROUTER_B
s0
Satelital s0
2FxO 64Kbps
2FxO
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

b) Ejemplo de fragmentación FRF.12.
ROUTER_B
s0
128Kbps 500
FR s0
128Kbps
s0 600 ROUTER_A
ROUTER_C
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 ROUTER_B y ROUTER_C

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

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

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/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

Configuracion y Manejo de Calidad de Ser PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Configuracion y Manejo de Calidad de Ser PDF

Cargado por

Copyright:

Formatos disponibles

Configuración y manejo de

calidad de servicio en enrutadores Cisco

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

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

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

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

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

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

Este documento cubre los aspectos principales de la implementación de

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

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

Estos tres problemas pueden existir hasta cierto grado dependiendo de

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

Para poder configurar calidad de servicio en un enrutador, es necesario

3. Modelos de calidad de servicio

En general, existen tres modelos de implementación de calidad de

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

Cisco ofrece los siguientes mecanismos para implementar calidad de

a) Clasificación y marcado de paquetes: dado que los paquetes IP

- FIFO (first-in first-out)

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

Los mecanismos anteriormente mencionados cuentan con dos métodos

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

class-map match-any VOZ policy-map VOZ_POL interface ethernet0

El otro método de implementación de calidad de servicio es AutoQos,

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

Actualmente MQC es el método preferido para clasificar y marcar

Existen muchas formas de clasificar tráfico, pero antes veamos la

match-any: si el tráfico cumple una sola sentencia entra en la clase

Luego se ‘llama’ esta clase desde un policy-map, según MQC. A

VALOR DECIMAL VALOR BINARIO NOMBRE

c) IP DSCP: Clasifica el tráfico de acuerdo al valor de los 6 primeros bits

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

VALOR DECIMAL* VALOR BINARIO NOMBRE

*Para los valores class-selector (cs) el valor en decimal

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

NBAR: Para configurar esta herramienta se tener en cuenta lo

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

Este comando permite descubrir y tomar estadísticas de todos los

e) Jerarquía de clases: es posible anidar una clase a otra, con el

Otras formas de clasificar incluyen: QoS group (variante de DSCP), MPLS

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

La marcación de paquetes se realiza generalmente por clase dentro de

Luego se debe asociar la política a una interfaz de entrada o salida con

Las principales formas de marcar paquetes son:

a) IP precedence: Marca los primeros 3 bits del byte TOS de los

Otras formas de marcar incluyen: QoS group (variante de DSCP), MPLS

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

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

192.168.3.0 ROUTER C ROUTER_D

policy-map DATOS policy-map DATOS

interface serial0 interface serial0

access-list 10 permit host 192.168.2.2 access-list 10 permit host 192.168.3.2

interface serial 1/1

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

policy-map POLIVOZ policy-map POLIVOZ

dial-peer voice 1 voip dial-peer voice 1 voip

interface serial0 interface serial0

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

1. Introducción al encolamiento (queuing)

El encolamiento de paquetes es natural en una interfaz congestionada,