INSTITUTO POLITÉCNICO

NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA

MECÁNICA Y ELÉCTRICA

DISEÑO Y ADMINISTRACIÓN DE
REDES

IP QoS
Prácticas

FECHA: 13 DE NOVIEMBRE DE 2017

NOMBRE DEL ALUMNO: SAMUEL SÁNCHEZ
MORALES
GRUPO: 9CM3
 IP QoS
INTRODUCCIÓN
1. Configure las siguientes tecnologías específicas de QOS:
 Esquemas de colas:
- Primero en entrar primero en salir (FIFO),
- Priority Queuing (PQ),
- Cola personalizada (CQ), y
- Weighted Fair Queuing (WFQ).
 Mecanismo de tasa de acceso comprometido (CAR).
 IPv6 QoS.

2. Proporcione ejemplos de escenarios que resalten los beneficios de estas

tecnologías.

¿CUÁNDO / POR QUÉ DEBERÍA USAR QOS EN MI RED?

Los esquemas de colas proporcionan un servicio de red predecible al proporcionar
ancho de banda dedicado, fluctuación de fase y latencia controladas, y
características mejoradas de pérdida de paquetes.
La idea básica es asignar previamente recursos (por ejemplo, procesador y
espacio en búfer) para datos confidenciales. Cada uno de los siguientes
esquemas requiere una configuración personalizada de las colas de interfaz de
salida.
 Priority Queuing (PQ) garantiza que durante la congestión los datos de
mayor prioridad no se retrasen por el tráfico de menor prioridad. Sin
embargo, el tráfico de menor prioridad puede experimentar retrasos
significativos.
(PQ está diseñado para entornos que se centran en datos de misión crítica,
excluyendo o retrasando el tráfico menos crítico durante los períodos de
congestión).
 Custom Queuing (CQ) asigna un cierto porcentaje del ancho de banda a
cada cola para garantizar un rendimiento predecible para otras colas. Está
diseñado para entornos que necesitan garantizar un nivel mínimo de
servicio a todo el tráfico.
  Weighted Fair Queuing (WFQ) asigna un porcentaje del ancho de banda de
salida igual al peso relativo de cada clase de tráfico durante los períodos de
congestión.
RED es un mecanismo de caída basado en la premisa de que los flujos
adaptativos como el TCP retrocederán y retransmitirán si detectan congestión.
Al monitorear la profundidad promedio de la cola en el enrutador y al dejar caer los
paquetes, el objetivo de RED es prevenir la aceleración de demasiadas fuentes
TCP a la vez y minimizar el efecto de esa congestión.
CAR es un mecanismo de regulación de tráfico, que define un contrato de tráfico
en redes enrutadas. CAR puede clasificar y establecer políticas para manejar el
tráfico que exceda una cierta asignación de ancho de banda.
CAR también se puede usar para configurar la precedencia de IP según la
aplicación, la interfaz de entrada y los TOS. Permite una considerable flexibilidad
para la asignación de precedencia.

CONFIGURACION:
La configuración de QoS se realiza en los siguientes objetos:
 Los enrutadores admiten CAR y las funcionalidades de puesta en cola.

 Las fuentes de tráfico asignan el tipo de servicio

 El objeto de configuración de atributos QoS define los perfiles globales de

QoS utilizados en la red
Glosario:
CAR: Committed Access Rate
COS: Class of Service
CQ: Custom Queuing
FIFO: First In First Out
LLQ: Low Latency Queue
PQ: Priority Queuing
QoS: Quality of Service
RED: Random Early Detection
TOS: Type Of Service
WFQ: Weighted Fair Queuing
WRED: Weighted Early Detection

ESCENARIOS:
Este proyecto incluye nueve escenarios. El rol de cada uno de los escenarios es el
siguiente:
1. Ninguno: este escenario es un escenario de referencia. No se define ninguna
cola en la capa de IP.
Configuración de la red
La red está compuesta por cuatro pares de clientes de video. Cada pareja usa un
TOS (tipo de servicio) distinto para la transferencia de datos. El vínculo entre los
dos enrutadores es un cuello de botella "potencial".
Resultados
El tráfico está en cola en el "enrutador A" debido al cuello de botella. Debido a que
el "enrutador A" tiene una capacidad de búfer ilimitada, ningún paquete se
descarta.
El tiempo de respuesta de la aplicación sigue aumentando a medida que los
paquetes se ponen en cola indefinidamente sin perderse.
2. FIFO: este escenario ilustra la cola FIFO en la capa IP.

Configuración de la red
La red está compuesta por cuatro pares de clientes de video. Cada pareja usa un
TOS (tipo de servicio) distinto para la transferencia de datos. El vínculo entre los
dos enrutadores es un cuello de botella "potencial".
La cola FIFO se puede habilitar en cada interfaz en enrutadores "avanzados".
Queueing el mecanismo de procesamiento de perfiles y colas se establece en un
sub atributo llamado "Información de interfaz" en el atributo compuesto
"Parámetros de QoS de IP".
El perfil de cola define el número de colas y el esquema de clasificación.
Los perfiles de cola globales se definen en el objeto de configuración de QoS.
Resultados
El tráfico está en cola en el "enrutador A" debido al cuello de botella. Como el
"enrutador A" tiene una capacidad limitada de memoria intermedia, algunos
paquetes se eliminan cuando el uso del búfer alcanza su capacidad máxima.
Se puede ver que el tiempo de respuesta de la aplicación alcanza un umbral
porque los paquetes que llegan en una cola completa siempre se descartan.
Tenga en cuenta que la demora máxima que observa un paquete que llega es la
demora encontrada como resultado de dar servicio a todos los paquetes por
delante en una cola casi completa.
3. Priority_Queuing: este escenario ilustra Priority Queuing en la capa IP.

Configuración de la red
La red está compuesta por cuatro pares de clientes de video. Cada pareja usa un
TOS (tipo de servicio) distinto para la transferencia de datos. El vínculo entre los
dos enrutadores es un cuello de botella "potencial".
Los enrutadores admiten múltiples colas para cada tipo de servicio. La cola 4
recibe el tráfico de TOS 4, la cola 3 recibe el tráfico de TOS 3 ... Las colas se
reparan mediante el mecanismo de "Cola de espera prioritaria".
La cola de prioridad se puede habilitar en cada interfaz en enrutadores
"avanzados". Queueing el mecanismo de procesamiento de perfiles y colas se
establece en un sub atributo llamado "Información de interfaz" en el atributo
compuesto "Parámetros de QoS de IP".
El perfil de cola define el número de colas y el esquema de clasificación.
Los perfiles de cola globales se definen en el objeto de configuración de QoS. Este
objeto se encuentra en la paleta "utilidades". Perfiles de cola de prioridad local (no
utilizado en este escenario) se puede configurar en "Perfiles de cola prioritaria" en
el atributo compuesto "Parámetros de QoS IP" en el enrutador.

Resultados
El tráfico está en cola en el "enrutador A" debido al cuello de botella. El
mecanismo de Priority Queuing diferencia las colas de acuerdo con su prioridad.
En este ejemplo, la prioridad se basa en el tipo de servicio (TOS).
La cola 4 envía paquetes siempre que no esté vacía.
La cola 3 envía paquetes cuando la cola 4 está vacía.
La cola 2 envía paquetes cuando la cola 3 y 4 están vacías.
La cola 1 envía paquetes cuando todas las otras colas están vacías.
Como resultado de esta clasificación, el tráfico con mayor TOS obtiene un mejor
retraso.
4. Custom_Queuing: este escenario ilustra Custom Queuing en la capa IP.

Configuración de la red
La red está compuesta por cuatro pares de clientes de video. Cada pareja usa un
TOS (tipo de servicio) distinto para la transferencia de datos. El vínculo entre los
dos enrutadores es un cuello de botella "potencial".
Los enrutadores admiten múltiples colas para cada tipo de servicio. La cola 4
recibe tráfico de TOS 4, la cola 3 recibe tráfico de TOS 3 ... Las colas se atienden
mediante el mecanismo "Cola personalizada".
La cola personalizada se puede habilitar en cada interfaz en enrutadores
"avanzados". Queueing el mecanismo de procesamiento de perfiles y colas se
establece en un sub atributo llamado
"Información de interfaz" en el atributo compuesto "Parámetros de QoS de IP".
El perfil de cola define el número de colas y el esquema de clasificación.
Los perfiles de cola globales se definen en el objeto de configuración de QoS. Este
objeto se encuentra en la paleta "utilidades". Perfiles de cola personalizados
locales (no utilizado en este escenario) se puede configurar en "Perfiles
personalizados de cola" en el atributo compuesto "Parámetros de QoS IP" en el
enrutador.
Resultados
El tráfico está en cola en el "enrutador A" debido al cuello de botella. En este
ejemplo, el mecanismo de cola personalizada diferencia el tráfico entre colas
según el tipo de servicio (TOS).
El tráfico se envía desde cada cola de forma rotativa.
Las colas envían tráfico proporcionalmente a su recuento de bytes. En este
ejemplo, las colas con alto índice tienen un mayor recuento de bytes.
Como resultado de esta clasificación, el tráfico con mayor TOS obtiene un mejor
retraso. Queue 3 y 4 obtienen su parte, pero dejan que otras colas pierdan el
ancho de banda.

5. Custom_Queuing_with_LLQ: este escenario ilustra el impacto del uso de una

cola de baja latencia en Custom Queuing.
Configuración de la red
La configuración de red es similar a la del escenario anterior (Personalizado
Queueing). La única diferencia está en la configuración de detalles del perfil de
Custom Queuing donde Queue 1 está configurado para ser una cola de baja
latencia (LLQ). El LLQ es un estricto funcionamiento de la cola de prioridad dentro
de la programación regular de Custom Queing ambiente. Recibe precedencia
absoluta sobre las otras colas lo que significa que ninguna otra cola en el sistema
puede ser atendida a menos que el LLQ esté vacío.
El atributo "Conteo de bytes" no se utiliza para el LLQ y su valor se ignora por el
programador. Si el LLQ está vacío, otras colas reciben servicio según el
mecanismo regular Custom Queuing basado en su atributo "Byte Count"
configuraciones.

Resultados
El tráfico está en cola en el "enrutador A" debido al cuello de botella. Cola 1, que
está configurado para ser un LLQ, obtiene la prioridad más alta y, por lo tanto, la
más alta compartir el ancho de banda y el retraso más bajo de extremo a extremo.
Otras colas se ponen muerto de hambre debido a la presencia del LLQ (compare
los resultados con el escenario anterior).
6. WFQ: este escenario ilustra WFQ Queuing en la capa IP.

Configuración de la red
La red está compuesta por cuatro pares de clientes de video. Cada pareja usa un
TOS (tipo de servicio) distinto para la transferencia de datos. El vínculo entre los
dos enrutadores es un cuello de botella "potencial".
Los enrutadores admiten múltiples colas para cada tipo de servicio. La cola 4
recibe tráfico de TOS 4, la cola 3 recibe tráfico de TOS 3 ... Las colas se atienden
utilizando el mecanismo "Cola de espera ponderada".
Las colas WFQ pueden habilitarse en cada interfaz en enrutadores "avanzados".
Queueing el mecanismo de procesamiento de perfiles y colas se establece en un
sub atributo llamado "Información de interfaz" en el atributo compuesto
"Parámetros de QoS de IP".
El perfil de cola define el número de colas y el esquema de clasificación.
Los perfiles de cola globales se definen en el objeto de configuración de QoS. Esta
objeto se encuentra en la paleta "utilidades". Perfiles WFQ locales (no utilizados
en este escenario) se puede configurar en "Perfiles WFQ / DWFQ" en los
"Parámetros de QoS IP" atributo compuesto en el enrutador.

Resultados
El tráfico está en cola en el "enrutador A" debido al cuello de botella. En este
ejemplo, el mecanismo WFQ diferencia el tráfico entre colas según el tipo de
servicio (TOS).
Las colas envían tráfico proporcionalmente a su peso. En este ejemplo, las colas
con alto índice tienen un mayor peso.
Como resultado de esta clasificación, el tráfico con mayor TOS obtiene un mejor
retraso. Queue 3 y 4 obtienen su parte, pero dejan que otras colas pierdan el
ancho de banda.

7. WFQ_with_LLQ: este escenario ilustra el impacto del uso de una cola de baja
latencia en WFQ.

Configuración de la red
La configuración de red es similar a la del escenario anterior (WFQ).
La única diferencia se encuentra en la configuración de detalles del perfil WFQ
donde Queue 1 es configurado para ser una cola de baja latencia (LLQ). El LLQ es
una prioridad estricta cola funcionando dentro de la programación regular
Weighted Fair Queuing ambiente. Recibe precedencia absoluta sobre las otras
colas que significa que no se puede dar servicio a ninguna otra cola en el sistema
a menos que el LLQ sea vacío. El atributo "Peso" no se utiliza para el LLQ y su
valor se ignorado por el programador. Si el LLQ está vacío, otras colas reciben
servicio de acuerdo con el mecanismo regular Weighted Fair Queuing basado en
su Configuración del atributo "Peso".
Resultados
El tráfico está en cola en el "enrutador A" debido al cuello de botella. Cola 1, que
está configurado para ser un LLQ, obtiene la prioridad más alta y, por lo tanto, la
más alta parte del ancho de banda y el retraso más bajo de extremo a extremo.
Mientras Queue 4 que tiene el mayor peso entre las otras colas obtiene una parte
completa de la ancho de banda, las colas 2 y 3 se mueren de hambre y tienen
mayores retrasos (comparar los resultados con el escenario anterior).
8-9. CAR_disabled / CAR_enabled: estos escenarios ilustran el impacto de CAR
en una red congestionada.

Configuración de la red
La red se compone de un cliente / servidor web y un cliente / video de video. Una
subred es una red de token de 4Mb, que representa un cuello de botella.
El tráfico de video se pone en cola y se prioriza en el firewall utilizando WFQ. Sin
embargo, la demora del video depende del tráfico HTTP.
Escenario "CAR deshabilitado": todo el tráfico es "mejor esfuerzo".
Scneario "CAR habilitado": CAR está habilitado y configurado de la siguiente
manera:
- El tráfico de video está configurado en TOS 5
- El tráfico Http está limitado a 50 Kbps con buks de 100 Kbps
- El tráfico Http conforme se establece en TOS 1
- Se ha eliminado el tráfico Http no conforme
CAR se puede habilitar en una interfaz entrante o saliente en enrutadores
"avanzados". Los perfiles CAR Policer se configuran en un atributo secundario
denominado "Información de interfaz" en el atributo compuesto "Parámetros de
QoS de IP". Los perfiles de CAR global se definen en el objeto de configuración de
QoS. Este objeto se encuentra en la paleta "utilidades". Los perfiles de CAR
locales (no utilizados en este escenario) pueden configurarse en "Perfiles de
policer" en el atributo compuesto "Parámetros de QoS de IP" en el enrutador.
Resultados
Al habilitar CAR, el tráfico Http está limitado a 50 Kbps, lo que ofrece más ancho
de banda disponible para el tráfico de video.
Por otra parte, el CAR estableció altos TOS para el tráfico de video y bajos TOS
para el tráfico Http. WFQ puede priorizar el tráfico y le da alta prioridad al tráfico de
video.
En este ejemplo, CAR proporciona un tiempo de respuesta más predecible para el
tráfico de video.
10. MDRR_IPv6_IPv4: este escenario ilustra la puesta en cola de IPv6 e IPv4
tráfico en la misma interfaz. El escenario usa perfiles locales de QoS.

Configuración de la red
La red se compone de un cliente / servidor web y un cliente / video de video. Una
subred es una red de token de 4Mb, que representa un cuello de botella.
El tráfico de video se pone en cola y se prioriza en el firewall utilizando WFQ. Sin
embargo, la demora del video depende del tráfico HTTP.
Escenario "CAR deshabilitado": todo el tráfico es "mejor esfuerzo".
Scneario "CAR habilitado": CAR está habilitado y configurado de la siguiente
manera:
- El tráfico de video está configurado en TOS 5
- El tráfico Http está limitado a 50 Kbps con buks de 100 Kbps
- El tráfico Http conforme se establece en TOS 1
- Se ha eliminado el tráfico Http no conforme
CAR se puede habilitar en una interfaz entrante o saliente en enrutadores
"avanzados". Los perfiles CAR Policer se configuran en un atributo secundario
denominado "Información de interfaz" en el atributo compuesto "Parámetros de
QoS de IP". Los perfiles de CAR global se definen en el objeto de configuración de
QoS. Este objeto se encuentra en la paleta "utilidades". Los perfiles de CAR
locales (no utilizados en este escenario) pueden configurarse en "Perfiles de
policer" en el atributo compuesto "Parámetros de QoS de IP" en el enrutador.
Resultados
Al habilitar CAR, el tráfico Http está limitado a 50 Kbps, lo que ofrece más ancho
de banda disponible para el tráfico de video.
Por otra parte, el CAR estableció altos TOS para el tráfico de video y bajos TOS
para el tráfico Http. WFQ puede priorizar el tráfico y le da alta prioridad al tráfico de
video.
En este ejemplo, CAR proporciona un tiempo de respuesta más predecible para el
tráfico de video.

11. Multiple_LLQs_CBWFQ Este escenario ilustra el funcionamiento de múltiples

colas de baja latencia (LLQ) en CBWFQ.
Configuración de la red
La red está compuesta por cuatro pares de clientes de video. Cada pareja usa un
TOS (tipo de servicio) distinto para la transferencia de datos. El tráfico generado
por cada nodo de cliente es de aproximadamente 600,000 bps. Los nodos 1 y 3
generan tráfico IPv4 mientras que los nodos 3 y 4 generan tráfico IPv6.
Como el enlace entre los dos enrutadores es de solo 1Mbps, es un posible cuello
de botella.

La configuración de QoS
El tráfico está en cola en el "enrutador A" debido al cuello de botella. El nodo
emplea una política de tráfico saliente aplicada a la interfaz de cuello de botella
para gestionar la asignación de ancho de banda. Las ACL se usan para clasificar
los diversos flujos de tráfico en clases de tráfico en función de sus direcciones de
origen. La política usa perfiles locales de cola MDRR para manejar el tráfico
perteneciente a diferentes clases de tráfico. El ancho de banda de enlace
disponible se divide entre los cuatro flujos de la siguiente manera:

Client TOS 1 -> TOS del servidor 1: 10% (100,000 bps)

Cliente TOS 2 -> Servidor TOS 2: 20% (200,000 bps)
Cliente TOS 3 -> Servidor TOS 3: 30% (300,000 bps)
Client TOS 4 -> TOS del servidor 4: 40% (400,000 bps)

Compruebe el atributo compuesto "Parámetros de QoS de IP" en el "enrutador A"

para ver los detalles de la configuración de QoS. La política de tráfico "my_policy"
se define en el subartículo "Políticas de tráfico". Las clases de tráfico a las que se
hace referencia en esta política (Class_1, Class_2, ...) se definen en el subartículo
"Clases de tráfico". Los perfiles MDRR locales (Q1, Q2, ...) a los que se hace
referencia en la política se definen en el subartículo "Perfiles MDRR".

Resultados
El panel almacenado muestra que el ancho de banda del enlace se divide entre
los cuatro flujos de acuerdo con los pesos de MDRR.
12. Basic Shaping
Configuración de la red
En este escenario, un cliente genera demanda de tráfico con distribución
exponencial con una carga promedio de 500 Kbps.
Se especifica un perfil de conformación para dar forma al tráfico a 500 Kbps.
Resultados
El tráfico enviado desde la cola de configuración de tráfico está limitado a 500
Kbps. Aunque el tráfico de entrada fluctúa en ocasiones por encima de 500 Kbps,
la salida de la cola está limitada a 500 Kbps, lo que confirma la operación de
configuración.
13.IP QoS: CBWFQ in conjunction with GTS

Configuración de la red
En este escenario, hay dos clientes. Cada uno genera voz, telepresencia y tráfico
HTTP.
Se definen 6 clases separadas en IP QoS Parámetros del Router A:
Cust1-Voice: ancho de banda mínimo 200 Kbps - forma 250 Kbps
Cust1-Tele: ancho de banda mínimo 100 Kbps - forma 125 Kbps
Cust1-HTTP: ancho de banda mínimo 100 Kbps - forma 182 Kbps

Cust2-Voice: ancho de banda mínimo 500 Kbps - forma 625 Kbps

Cust2-Tele: ancho de banda mínimo 150 Kbps - forma 125 Kbps
Cust2-HTTP: ancho de banda mínimo 150 Kbps - forma 182 Kbps

Resultados
1. Observe que cada clase tiene la forma del valor especificado.
2. Observe que se cumplen las garantías mínimas de ancho de banda para todo el
tráfico.
Tenga en cuenta que en este enfoque, cada clase tiene una tasa de configuración
rígida y tiene sentido solo cuando los clientes pueden generar suficiente tráfico de
cada tipo.

14. IP QoS: CBWFQ inside GTS

Configuración de la red
En este escenario, hay dos clientes. Cada uno genera tráfico de voz, telepresencia
y HTTP.
El tráfico se forma primero, y luego pasa a través de WFQ.
El tráfico del cliente 1 tiene una forma de 750 Kbps. En las configuraciones WFQ
del Cliente 1, Voice obtiene un mínimo de 200 Kbps y Telepresencia de 100 Kbps.
Class-default (HTTP) no tiene un requisito de ancho de banda mínimo.
El tráfico del cliente 2 tiene una forma de 1500 Kbps. En las configuraciones de
Customer 2 WFQ, Voice obtiene un mínimo de 500 Kbps y Telepresencia de 150
Kbps.
Class-default (HTTP) no tiene un requisito de ancho de banda mínimo.

Resultados
Customer1 tiene una forma de 750 Kbps, Customer2 tiene una forma de 1500
Kbps.
Después del shaper, en WFQ, se sirve el primer tráfico de voz y telepresencia
para que cumplan con sus requisitos mínimos.
Luego se sirve el tráfico HTTP. Finalmente, el ancho de banda sobrante se
comparte entre Voz y Telepresencia en función de sus ponderaciones.
Tenga en cuenta que en esta configuración, los pesos se calculan dividiendo el
requisito de ancho de banda absoluto por la tasa de conformación respectiva, no
la tasa de datos del enlace de cuello de botella.