Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Cisco QoS v1 PDF
Cisco QoS v1 PDF
Tema Página
Introducción................................................................................................4
Manejo de la congestión..........................................................................15
1. Introducción al encolamiento
2. Arquitectura de colas en Cisco
3. Métodos básicos de encolamiento
4. Métodos avanzados de encolamiento
5. Otras técnicas de encolamiento
6. Conclusiones sobre encolamiento
7. Ejemplos de configuración
Evitamiento de la congestión....................................................................34
1. Congestión y TCP
2. RED : Random Early Detection
3. WRED : Weighted Random Early Detection
4. Ejemplos de configuración
Resolución de problemas………………………………………………………57
1. Comandos útiles
2. Documentos útiles
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
5. Introducción a MQC
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
1. Clasificación de tráfico
ip cef
policy-map [nombre de política]
class [nombre de clase]
set [ip precedence/ip dscp/cos/etc...] [valor]
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
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
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
100Mbps 64Kbps
flujo de tráfico
512Kbps
512Kbps 512Kbps
IP IP IP IP
COLA SW COLA HW INTERFASE
(FIFO)
ENVÍO O
COLA 1
DESCARTE
ENVÍO O
CLASIFICACIÓN COLA 2 PROGRAMADOR
DESCARTE
(SCHEDULER)
.
.
.
ENVÍO O
COLA n
DESCARTE
1 2
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).
Configuración de FIFO:
Se aplica el comando ‘no fair-queue’ en la interfaz global.
¿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
A1 (100ms)
B1 (300ms)
A2 (20ms)
A3 (10ms)
B2 (300ms)
t 100 70 60 50 0ms
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.
Configuración de WFQ:
Se aplica el siguiente comando en la interfaz global.-
fair-queue [cdt] [ número de colas] [ colas para rsvp]
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
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
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]
¿CLASE COLA DE
AP? CAR
PRIORIDAD (FIFO)
AP = Alta Prioridad
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
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]
SI
SI
SI
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
ROUTER_A ROUTER_B
128Kbps
s0 s0
ROUTER_A ROUTER_B
class-map match-any VOZ class-map match-any VOZ
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
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
ROUTER_B ROUTER_C
interface serial0 interface serial0
bandwidth 512 bandwidth 512
encapsulation frame-relay encapsulation frame-relay
frame-relay interface-dlci 110 frame-relay interface-dlci 220
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
Utilización
del enlace Tasa máxima (congestión)
Tasa promedio
Tiempo
10 %
32 40 Ocupación
promedio de la cola
Utilización
del enlace Tasa máxima (congestión)
Tasa promedio
Tiempo
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
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 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.
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.
Å PERFILES DE WRED
PARA ROUTER_A
20 %
20 25 30 40
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).
police cir percent [%] [Bc(ms)] pir percent [%] [Be PIR(ms)]
conform-action [action] exceed-action [action]
violate-action [action]
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]
policy-map BW
class trafficA
bandwidth percent 50
class trafficB
bandwidth percent 10
class trafficC
bandwidth percent 15
policy-map SHAPE
class trafficT
shape average 512000
service-policy BW
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)
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
encapsulation frame-relay
service-policy output TODO
ROUTER_D
policy-map TODO
class class-default
police 192000 conform-action transmit exceed-action set-prec-transmit 2
interface s0
encapsulation frame-relay
service-policy output TODO
interface ethernet0
ip policy route-map 10
interface s0
encapsulation ppp
service-policy output AaB
interface s1
encapsulation frame-relay
route-map 10 permit
match ip address 150
set interface s1
route-map 20 permit
set interface s0
ROUTER_B
class-map match-any APP_SEC
match protocol rtp
match access-group 100
policy-map BaA
class APP_SEC
police cir percent 20 conform-action transmit exceed-action drop
interface ethernet0
ip policy route-map 10
interface s0
encapsulation ppp
service-policy output BaA
interface s1
encapsulation frame-relay
route-map 10 permit
match ip address 150
set interface s1
route-map 20 permit
set interface s0
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.
interface ethernet 0
bandwidth 512
service-policy output SHAPE
PROVEEDOR
interface e0.1
traffic-shape rate 512000 51200 51200
interface e0.2
traffic-shape rate 512000 51200 51200
interface e0.3
traffic-shape rate 512000 51200 51200
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.
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
RTP Header Compression: comprime las cabeceras IP, UDP y RTP para el
protocolo Real-Time Protocol generalmente utilizado por aplicaciones
de voz y video. Estas cabeceras suman normalmente 40 bytes, los
culaes se pueden comprimir en 2 a 4 bytes. La primera cabecera de
una sesión RTP/UDP/IP siempre es transmitida sin comprimir, las
cabeceras siguientes sólo incluyen el índice de la sesión RTP/UDP/IP y los
parámetros variables. Es muy recomendable utilizar cRTP en
aplicaciones de voz comprimida.
Se habilita con el siguiente comando en la interfaz:
[frame-relay*] ip rtp header-compression
* solo para interfaces frame-relay
También es posible habilitar TCP header-compression en clases MQC,
configurando el siguiente comando dentro de la clase:
compression header ip rtp
cola de salida
CON FRAGMENTACIÓN
cola de salida
Ts = Tamaño de paquete_
Ancho de banda
*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.
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
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.
1. Comandos útiles
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.
Cisco_VoIP_v1
file:\\10.120.1.9\telepuerto$\Service_Assurance\Tecnologias\Routing\
Cisco\VoIP\Cisco_VoIP_v1.PDF