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
Evitamiento de la congestin....................................................................34
1. Congestin y TCP
2. RED : Random Early Detection
3. WRED : Weighted Random Early Detection
Control de trfico: Policy & Shaping40
1. Introduccin al control de trfico
2. Implementacin de Traffic Policing
3. Implementacin de Traffic Shaping
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
Resolucin de problemas57
1. Comandos tiles
2. Documentos tiles
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.
Pgina 4
10/10/04

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
Pgina 7
10/10/04

3) Aplicar las polticas: con el comando service-policy output en
general aplicado a interfaces.
Por ejemplo:
1
CLASE VOZ
POLTICA 1:
Interfase
Ethernet0
POLTICA 2:
Int. Serial0.1
BW y Delay
garantizados
CLASE FTP
CLASE SQL
class-map match-any VOZ

match access-group 10
match ip precedence 5
class-map match-any FTP
class-map match-all SQL
Mejor esfuerzo,
BW limitado
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
Int. Serial0.3
interface ethernet0
service-policy output VOZ_POL
interface serial0.1
frame-relay interface-dlci 1
service-policy output VOZ_POL
interface serial0.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
VALOR BINARIO
NOMBRE
0
1
2
3
4
5
6
7
000
001
010
011
100
101
110
111
routine
priority
immediate
flash
flash-override
critical
internet
network
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*
VALOR BINARIO
NOMBRE
0
1
2
3
4
5
6
7
46
10
12
14
18
20
22
26
28
30
34
36
38
000000
001000
010000
011000
100000
101000
110000
111000
101110
001010
001100
001110
010010
010100
010110
011010
011100
011110
100010
100100
100110
Default
cs1
cs2
cs3
cs4
cs5
cs6
cs7
ef
af11
af12
af13
af21
af22
af23
af31
af32
af33
af41
af42
af43
*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.
(ms informacin: 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 estadsticas, los protocolos ms usados, notificaciones, etc.
Pgina 10
10/10/04

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

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.
Pgina 12
10/10/04

a) Ejemplo de clasificacin y marcacin en clases
192.168.2.0
s0
192.168.1.0
ROUTER A
.2
s1/1
.3
ROUTER_D
ROUTER C
192.168.3.0
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 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
ROUTER_B
class-map match-any FILESQL
policy-map DATOS
class FILESQL
set ip precedence 5
policy-map DATOS
class FILESQL
set ip precedence
interface serial0
interface serial0
access-list 10 permit host 192.168.2.2


ROUTER_C
class-map match-any FILESQL_HIGH
class-map match-any FILESQL_LOW
policy-map DATOS
class FILESQL_HIGH
bandwidth 256
class FILESQL_LOW
bandwidth 128
interface serial 1/1
Pgina 13
10/10/04

b) Ejemplo de clasificacin y marcacin en dial-peers
s0
FxS
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 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
ROUTER_B
policy-map POLIVOZ
class VOZ
priority 15
policy-map POLIVOZ
class VOZ
priority 15

destination-pattern 2

destination-pattern 1
interface serial0
service-policy output POLIVOZ
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.
Pgina 15
10/10/04

- 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 HW
COLA SW
(FIFO)
INTERFASE
ESTRUCTURA TPICA DE COLA DE SOFTWARE
CLASIFICACIN
ENVO O
DESCARTE
COLA 1
ENVO O
DESCARTE
COLA 2
.
.
.
ENVO O
DESCARTE
Pgina 16
PROGRAMADOR
(SCHEDULER)
COLA n
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
COLA DE SOFTWARE FIFO

UNA
SOLA
CLASE
TAIL
DROP
UNA SOLA
COLA
FIFO
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).
Pgina 18
10/10/04

- 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
DROP
COLA n
.
.
.
FLUJO
n?
Pgina 19
WFQ
SCHEDULER
COLA
HW
(FIFO)
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
Nmero de colas
B 64Kbps
64K < B 128K
128K < B 256K
256K < B 512K
B 512Kbps
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? +
NO
NO
SI
SI
NO
NO
SI
X
X
SI
X
NO
SI
NO
SI
ACCIN
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
CLASE
1?
CLASE
2?
TAIL
DROP
COLA 1
TAIL
DROP
COLA 2
TAIL
DROP
COLA PD
.
.
.
CLASE
PD?
CBWFQ
SCHEDULER
(WRR)
COLA
HW
(FIFO)
PD = Por defecto
Pgina 23
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
2
CBWFQ
SCHEDULER
BANDWIDTH 64
CLASE B
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?
COLA DE
PRIORIDAD (FIFO)
CAR
AP = Alta Prioridad
COLA DE SOFTWARE LLQ BAJA PRIORIDAD (CBWFQ)
CLASE
1?
TAIL
DROP
COLA 1
CLASE
2?
TAIL
DROP
COLA 2
TAIL
DROP
COLA PD
.
.
.
CLASE
PD?
CBWFQ
SCHEDULER
(WRR)
COLA
HW
(FIFO)
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 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
BANDWIDTH 128
8
2
CBWFQ
SCHEDULER
BANDWIDTH 64
7
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]
[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]

(asocia el trfico saliente de una interfaz a una cola)
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]

(define el tamao de cada cola en nmero mximo de paquetes)
Para aplicar en la interfaz:

priority-group [#lista]
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.
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 un protocolo a una cola, se puede detallar el puerto TCP/UDP, ACL, etc)
queue-list [#lista] interface [interf.] [nmero de cola]

(asocia el trfico saliente de una interfaz a una 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.
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:
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]
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?
NO
No se necesita otra
tcnica que FIFO
NO
Utilizar Weighted Fair

Queuing
NO
Utilizar CBWFQ
o Custom Queuing
SI
Se requiere un
control estricto?
SI
Aplicaciones
sensibles a delay?
SI
Utilizar LLQ, PQ o PIPQ
Pgina 30
10/10/04

a) Ejemplo de tcnicas de encolamiento bsico.
s0
192.168.2.0
64Kbps
ROUTER_B
s0
Internet
128Kbps
192.168.1.0
ROUTER_A
64Kbps
192.168.3.0
s0
ROUTER_C
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
ROUTER_B
128Kbps
s0
s0
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
match protocol ftp
class-map match-any HTTP
match protocol http
ROUTER_B
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
policy-map POLICOLA
class VOZ
priority 28
class FTP
class HTTP
interface serial0
bandwidth 128
service-policy output POLICOLA
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
110
192.168.2.0
FR
220
s0
192.168.3.0
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
class ALTA
interface serial0.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
ROUTER_C
interface serial0
bandwidth 512
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
Tx
Rx
Rx
N
N+1
N
N+1
ACK
N+1
N+3
ACK
N+1
N+2
N+1
ACK
N+1
N+3
N+1
N+7
N+3
ACK
N+3
N+4
COMPORTAMIENTO TCP SIN

PRDIDAS
ACK
ACK
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
TCP DELAY
Flujo frgil y
precedence 5
Pgina 35
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
Tail Drop
Descarte
RED
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.
Pgina 36
10/10/04

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

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 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
ROUTER_A
class-map match-any RED_BAJA
class-map match-any RED_NORMAL
class-map match-any RED_ALTA
policy-map MARCAR
class RED_BAJA
bandwidth 8
random-detect
random-detect precedence 0 20 40 20
class RED_NORMAL
bandwidth 8
random-detect
class RED_ALTA
bandwidth 32
random-detect
policy-map MARCAR
class ALTA
set ip precedence 4
class BAJA
set ip precedence 2
class class-default
set ip precedence 0
100%
PERFILES DE WRED
PARA ROUTER_A
20 %
20
25
30
40
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]

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.
Pgina 41
10/10/04

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]
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
class trafficC
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
Pgina 43
10/10/04

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
Pgina 44
10/10/04

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)
26xx, 36xx, 7200, etc

(no VIP: FRTS, CBS,
etc)
Interfaz
global
Aplicar la poltica
MQC en la
interfaz global
Poltica MQC aplicable,

pero sin FRTS
Subinterfaz
Frame-Relay
Aplicar la poltica
MQC en la
subinterfaz
Aplicar la pltica MQC

dentro del map-class y
aplicar ste en la
subinterfaz
PVC Frame-Relay
No aplicable
Aplicar la pltica MQC

dentro del map-class y
aplicar ste en el PVC
Pgina 45
10/10/04

a) Ejemplo de Class-based policing
ROUTER_A
ROUTER_B
PPP 1024Kbps
Backup FR 64/64/448Kbps
10.120.1.0 /24
FR 192/192/384Kbps
ROUTER_C
192.168.100.0 /24
10.120.2.0 /24
FR 192/192/384Kbps
ROUTER_D
192.168.200.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
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
Pgina 46
10/10/04

ROUTER_A
class-map match-any APP_SEC
match protocol rtp
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
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 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
Pgina 47
10/10/04

b) Ejemplo de GTS y Class-based shaping
CLIENTE A
e0
e0.1
Backbone
de Internet
CLIENTE B
e0.2
PROVEEDOR
e0
e0.3
CLIENTE C
e0
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
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
Pgina 48
10/10/04

c) Ejemplo de Frame-relay traffic shaping
ROUTER_B
s0
500
192.168.2.0
FR
600
s0
192.168.3.0
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
interface serial0.5
class 64K
interface serial0.6
class 64K
ROUTER_B y ROUTER_C
interface serial0
frame-relay traffic-shaping
frame-relay interface-dlci 500 (/600)
class 64K
priority-group 1 protocol ip high list 100

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

frame-relay bc 61000
frame-relay be 60000
frame-relay priority-group 1
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
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 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.
[frame-relay*] ip tcp header-compression
* solo para interfaces frame-relay
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.
[frame-relay*] ip rtp header-compression
* solo para interfaces frame-relay
Tambin es posible habilitar TCP header-compression en clases MQC,

configurando el siguiente comando dentro de la clase:
compression header ip rtp
Pgina 52
10/10/04

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

a) Ejemplo de compresin de cabeceras.
ROUTER_A
ROUTER_B
s0
2FxO
Satelital
64Kbps
s0
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
match ip dscp ef
policy-map COMPLLQ
class TELNET
compression header ip tcp
class VOZ
priority 44
interface serial0
encapsulation hdlc
bandwidth 64
service-policy output COMPLLQ
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
FR
s0
600
128Kbps
s0
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
match ip dscp ef
policy-map VoIP
class VOZ
priority 32
ROUTER_B y ROUTER_C
match ip dscp ef
policy-map VoIP
class VOZ
priority 32
interface serial0
interface serial0.5
class 128K
interface serial0.6
class 128K
interface serial0
frame-relay traffic-shaping
frame-relay interface-dlci 500 (/600)
class 128K
frame-relay bc 1210
frame-relay be 0
frame-relay mincir 121000
service-policy output VoIP
frame-relay fragment 160

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.
Pgina 57
10/10/04

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

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cisco QoS v1

Transféré par

Droits d'auteur :

Formats disponibles

Configuracin y manejo de

calidad de servicio en enrutadores Cisco

Configuracin de calidad de servicio (QoS)

Configuracin de calidad de servicio (QoS)

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

Descripcin de QoS en Cisco.

Configuracin de calidad de servicio (QoS)

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

FIFO (first-in first-out)

c) Evitamiento de la congestin: Este mecanismo permite evitar la

Configuracin de calidad de servicio (QoS)

class-map match-any VOZ

El otro mtodo de implementacin de calidad de servicio es AutoQos,

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

match [not] [condicin n]

match-any: si el trfico cumple una sola sentencia entra en la clase

Luego se llama esta clase desde un policy-map, segn MQC. A

c) IP DSCP: Clasifica el trfico de acuerdo al valor de los 6 primeros bits

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

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

d) Protocolo: se puede clasificar segn protocolos de capa 3 ms.

Luego, para aplicar la PDLM bajada, se usa el comando ip nbar

Configuracin de calidad de servicio (QoS)

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

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

policy-map [nombre de poltica]

Luego se debe asociar la poltica a una interfaz de entrada o salida con

dial-peer voice 1 voip

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

Configuracin de calidad de servicio (QoS)

access-list 10 permit host 192.168.2.2

access-list 10 permit host 192.168.3.2

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

dial-peer voice 1 voip

dial-peer voice 1 voip

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

Dependiendo del tipo de aplicaciones que se estn manejando, se debe

Configuracin de calidad de servicio (QoS)

ESTRUCTURA TPICA DE COLA DE SOFTWARE

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

COLA DE SOFTWARE FIFO

Utiliza el mtodo de descarte por defecto llamado Tail Drop. Este

Configuracin de calidad de servicio (QoS)

COLA DE SOFTWARE WEIGHTED FAIR-QUEUE

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

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

Autor: Gianpietro Lavado Chiarella

Configuracin de calidad de servicio (QoS)

+ Paquete nuevo tiene el peor FT del conjunto de paquetes en la cola.

- Etapa de programacin (Scheduling): En esta etapa se define el

A1: Llega en el tiempo T + 0ms y tomara 100ms transmitirlo