PRÁCTICA: CALIDAD DE SERVICIO (CoS y QoS)

Autor: Santiago Felici

1.- Objetivo
El objetivo de la presente práctica es configurar calidad de servicio en la maqueta de red que se muestra en la figura
del final, utilizando información tanto de capa 3-4 como de capa 2. Para ello, inicialmente configuraremos en los
routers la calidad de servicio o Quality of Service (QoS) utilizando información de capa 3-4 (dirección IP, puerto,
protocolo, …), aplicada a los enlaces de menor velocidad, enlaces WAN. De forma complementaria a la QoS,
configuraremos la calidad de servicio a nivel local en la LAN, en los propios conmutadores, método que se conoce
como Class of Service (CoS).

2.- Introducción
El mecanismo de calidad de servicio se refiere a la habilidad en la red de ofrecer prioridad a unos determinados tipos
de tráfico, independientemente de la tecnología de red utilizada. Es por ello, que normalmente se aplica en capa 3-4.
Estos mecanismos son inherentemente necesarios a la red cuando esta ofrece servicios de tiempo real: voz IP,
videoconferencia por Internet, video streaming, radio por Internet, etc. Por ejemplo en el caso de voz IP (VOIP), se
necesita una pérdida de paquetes inferior al 1% y un retraso extremo a extremo de 150 msec, prestaciones que no
podemos obtener de forma nativa de TCP/IP (Internet), dado que su funcionamiento es Best Effort.

Sería muy fácil dar calidad de servicio si las redes nunca se congestionaran, pero para ello habría que
sobredimensionar todos los enlaces, cosa no siempre posible. Por tanto, para dar calidad de servicio en gran escala y
en redes con posibilidades de congestión, es preciso tener mecanismos que permitan dar al tráfico un trato
diferenciado acorde con el SLA (Service Level Agreement). De todas formas, aunque el estado de congestión pueda
ser una decisión de compromiso entre sobredimensionamiento y saturación, una situación permanente de congestión
es inabordable y su única solución es el sobredimensionamiento. Es decir, los mecanismos de calidad de servicio son
inútiles en una red saturada permanentemente como podemos ver en la figura 1.

Figura 1: Evolución del rendimiento de una red en función de la carga o tráfico ofrecido

En general, todos estos conceptos quedan encajados dentro de lo que llamamos “ingeniería de tráfico”, que
pretender analizar el tráfico para ofrecer servicios mejores y más predecibles, mediante: soporte de ancho de banda
dedicado, mejorando las características de pérdida de paquetes, evitando y manejando la congestión de la red,
organizando y priorizando el tráfico.

Los parámetros que definen la calidad de un servicio son 4 parámetros: ancho de banda, retraso temporal, variación
de retraso (o jitter) y probabilidad de error (o pérdida de paquetes o fiabilidad). Para poder gestionar estos
parámetros de forma eficiente debemos hacer uso de la prioridad y gestión del tráfico por medio de colas. Varias
alternativas han existido para abordar este problemática, los llamados servicios integrados (que definen circuitos
por flujos establecidos utilzando para su reserva RSVP (Resource Reservation Protocol)) y servicios diferenciados
(basados en el marcado y clasificación). De estos métodos, el más extendido por su escalabilidad y flexibidilidad son
los servicios diferenciados o Differentiated Services (DS) dado que trabaja en base a la clasificacion y su posterior

1
marcado del paquete y no a la reserva para los diferentes flujos establecidos, lo cual arrastra problemas de
escalabilidad.

En los servicios diferenciados por tanto, vamos a distinguir dos tipo de routers tal como observamos en la figura 2.
Los routers frontera que hacen clasificación y marcado del tráfico y los routers internos que se encargan de evitar la
congestión.

Figura 2: servicios diferenciados, basado en routers frontera y routers internos.

Para realizar el marcado de los paquetes se pueden utilizar varias técnicas, pero la más extendida y estandarizada es
utilizar los DSCP (Differentiated Service Code Point) con la asignación de valores tal como aparece en la figura 3.
Este marcado se puede extender a IPv6, MPLS, …

Figura 3: valores estandarizados para DSCP

Donde los servicios definidos para cada DSCP corresponden con las siguientes características:

Servicio Características
‘Expedited Forwarding’ o ‘Premium’ Es el que da más garantías. Equivale a una línea dedicada
Garantiza Caudal, tasa de pérdidas, retardo y jitter.
Valor 101110 en DSCP
‘Assured Forwarding’ Asegura un trato preferente, pero sin fijar garantías (no hay
SLA). Se definen cuatro clases y en cada una tres niveles de
descarte de paquetes según la precedencia.

‘Best Effort’ con prioridad Sin garantías, pero obtendrá trato preferente frente a ‘best
effort sin prioridad’
‘Best Effort’ sin prioridad Ninguna garantía

2
Como hemos dicho, los métodos de marcado son muy diversos. En capa 2, el marcado se realiza en base a una
extensión del 802.1Q tal como podemos ver en la figura 4. El marcado en capa 2 permite asegurar con mayor
garantía la calidad de servicio, dado que se produce muy próximo al origen.

Figura 4: marcado en capa 2 utilizando 802.1Q, con 3 bits para prioridad en las tramas

En la capa 3, el marcado DSCP se realiza en base al RFC 2474 y utiliza un campo de la cabecera IP para definir la
prioridad y/o tipo de servicio tal como se muestra en la figura 3. En este caso el marcado utiliza 6 bits, siendo los 3
primeros bits utilizados para marcar la prioridad y los siguientes para definir estrategias de descarte. Por ejemplo, en
la figura 3 los paquetes marcados con EF tienen prioridad 101 (5 en decimal), pero en este caso el resto de bits no se
interpretan como descarte, si no que son configurables por el usuario.

Visto los mecanismos de marcado y clasificación, otro elemento clave es el proceso de priorización y gestión de
colas. Las colas son gestionadas en los interfaces de salida tal como se observa en la figura 5, donde podemos ver
diferentes disciplinas de servicio que a continuación vamos a detallar.

Figura 5: gestión de colas según su clasificación (DSCP) en la interfaz de salida

En la figura 5, aparecen diferentes colas con diferentes tipo de servicio, asignando a cada cola el tráfico según su
marcado. Para el caso particular de los routers de Cisco Systems, las colas de los interfaces de salida con velocidad
superior a un T1/E1 utilizan disciplina FIFO (First In First Out) que se caracteriza por su rapidez ya que realmente
no hace nada, dado que los paquetes a medida que llegan, van saliendo. Si la velocidad de salida es inferior a un
T1/E1, entonces utiliza WFQ (Weigthed Fair Queueing), que consiste en gestionar los diferentes flujos o sesiones
en colas independientes, buscando un reparto equitativo o justo (fair), priorizando aquellas de menor volumen, las
cuales asocia como más sensibles al retardo como VOIP y Telnet, y penalizando aquellas sesiones más grandes,
dado que no las asocia con aplicaciones de tiempo real, como FTP. WFQ reserva para cada sesión, espacio hasta 64
paquetes y si se excede se descartan y sólo se vuelven a aceptar en el caso que la ocupación descienda al 25%. WFQ
se considera una disciplina adaptativa al estado de la red y las características del tráfico. WFQ no es escalable y por

3
tanto no funciona bien en routers backbone. Una versión de WFQ que sí es escalable es CB-WFQ (Class Based
WFQ) que consiste en atender por clases según el marcado y en cada clase utilizando WFQ, que es el mecanismo
central de la figura 5.

Existen otras disciplinas de servicio objetivamente menos flexibles y adaptativas que WFQ que permiten especificar
con mayor rigor el reparto del ancho de banda, de forma manual, utilizando dos criterios, con prioridades o con
reparto Round Robin :
• PQ (Priority Queueing) que se caracteriza por definir 4 tipos de colas con prioridad high, medium, normal y
low, de forma que mientras queden paquetes en la cola high no se atienden los paquetes de medium y así
sucesivamente. En ocasiones esta configuración puede crear inanición, debido a que el tráfico de VOIP
clasificado como PQ high puede llegar a consumir todo el ancho de banda disponible. Además, cabe resaltar
que su disciplina es estática y no se adapta a los cambios en la red. Los tamaños respectivamente de las
diferentes colas por defecto son 20, 40, 60 y 80 paquetes respectivamente y la cola por defecto para tráfico no
clasificado (o marcado) es nivel normal. El modo de configuración en los routers de Cisco es priority-list,
haciendo clasificación en base al protocolo (y puertos, ej priority-list 41 protocol ip medium TCP 23) o a la
interfaz de entrada (ej, priority-list 4 interface fa0/0 high). En la figura 5, esta disciplina de servicio también
recibe el nombre de LLQ (Low Latency Queueing) cuando va acompañada de CB-WFQ y generalmente es
utilizada por los protocolos de tiempo real.

• CQ (Custom Queueing) que se caracteriza por definir hasta 17 colas (la cola 0 está asociada sólo a funciones
del sistema (routing, keepalives,…) y se atiende siempre primero) que se atienden según Round Robin, con
quantos definidos en bytes y que por defecto queda definido en 1500 bytes. La cola por defecto para tráfico no
marcado es la 1. El modo de configuración en los routers de Cisco es queue-list, haciendo clasificación en base
al protocolo (y puertos, ej queue-list 4 protocol ip 1 TCP 232) o a la interfaz de entrada (ej, queue-list 4
interface fa0/0 2). El tamaño de cada una de estas colas es de 20 paquetes, pero se puede modificar.

De forma complementaria a esta práctica, pero queda excluido, se podría introducir las técnicas de LFI (Link
Fragmentation and Interleaving) y WRED (Weighthed Random Early Discard). Las primeras son utilizadas para
evitar que paquetes grandes obstruyan las salidas en enlaces de baja velocidad, obligando a los paquetes que circulen
por allí tener un tamaño de paquete máximo. Las técnicas WRED se utilizan para realizar descarte inteligente de
paquetes, evitando situación de oscilación y tratando de penalizar el tráfico de mayor volumen.

3.- Realización de la práctica

Los siguientes pasos se han de realizar de forma coordinada de todas las parejas y paso a paso durante toda la sesión
y siguiendo las instrucciones del guión. Previamente, se supone que el alumno debe estar familiarizado con la
práctica o haberse leído este documento.

Los pasos a realizar en esta práctica son:

Paso 0: cableado de la maqueta

En primer lugar comprobar la conectividad física de toda la maqueta tal como indica en la figura anexa. Destacar
que los equipos que la deben componer son routers Cisco Systems modelo 1721 (o superior con IOS 12.2 con IP+) y
conmutadores conectados en las LAN Cisco Catalyst modelo 2950.

Paso 1: configuración de la conectividad IP de toda la maqueta con OSPF

En este paso vamos a configurar lógicamente la maqueta, tanto los routers como los hosts:

Los pasos para configurar los routers son:

NOTA: En ningún momento, se indica a lo largo de la práctica guardar la configuración de los routers. Con ello
se simplifica el último paso de la práctica, que consiste en dejar la maqueta y los routers configurados tal como
estaba en el inicio.

1
Este número identifica la lista de prioridad que se declara, en este caso la número 4, para luego asociarla a un
interfaz determinado
2
En este caso, se identifica la lista de prioridad y además la cola por la que va a ser cursado este tráfico. En
particular 4 identifica la lista de prioridad y 1 identifica la cola que va a procesar el tráfico en el Round Robin
definido para la cola 1

4
a.- utilizaremos la conexión de consola mediante el programa de emulación de terminal “minicom” (comando
‘minicom –s’ u otro programa terminal). La configuración del programa de emulación debe ser la siguiente:

• Velocidad 9600 bits/s

• Sin paridad
• 8 bits de datos
• bit de parada (8N1)
• Dispositivo de entrada: ttyS0

b.- encender el router. Debe aparecer la secuencia de mensajes de arranque. Esto nos confirma que la comunicación
por el puerto de consola es correcta.

c.- Una vez ha arrancado el router debe aparecer el prompt ‘Router>’; teclear el comando ‘enable’ para pasar
a modo Privilegiado. En caso de que pida una password consultar al profesor.

d.- Ejecutar el comando “show ip interface brief” y tomar nota de los nombres asignados a las interfaces
en cada modelo de router. El nombre de las interfaces depende del modelo y se utilizarán a continuación.

e.- Una vez en modo Privilegiado entraremos en modo Configuración Global para introducir la configuración que
corresponde a cada router, siguiendo el siguiente modelo. Utilizad en cada router, el nombre para identificar a las
diferentes interfaces, tal como se ha indicado anteriormente.

Router>enable
Router#configure terminal
Router(config)#hostname Lab-A
Lab-A (config)#no ip domain-lookup
Lab-A (config)#interface fastethernet3 04
Lab-A (config-if)#ip address 205.7.5.1 255.255.255.0
Lab-A (config-if)#no shutdown
Lab-A (config-if)#exit
…. Completar la configuración de forma análoga. Finalmente

Lab-A (config)#line vty 0 4

Lab-A (config-line)#password cisco
Lab-A (config-line)#exit

Como routing vamos a utilizar en este caso un protocolo estado del enlace no propietario, concretamente OSPF
(OSPF, Open Shortest Path First). Para ello hay que habilitar el OSPF declarando todas las interfaces de cada
router dentro del “área 0”, es decir, vamos a configurar todas las redes como parte del área backbone (troncal) y por
tanto todos los routers van a disponer de la misma información de la red. Otra forma para realizar esta configuración
OSPF, sería en el caso de tener una red de mayores dimensiones, utilizando routing jerárquico, con múltiples áreas.
La forma de configurar OSPF es como sigue:

Router(config)#router ospf xxx

Router(config-router)#network d.d.d.d m.m.m.m area 0

Donde xxx es un número o identificativo de proceso que ejecuta OSPF interno para el router (por ejemplo, podemos
poner “router ospf 1” o cualquier valor), d.d.d.d son direcciones de red de redes directamente conectadas y
m.m.m.m es una “wildmask”, es decir tiene el significado inverso de la máscara, 1’s en vez de 0’s. Ejemplo, /24
sería 0.0.0.255 en vez de 255.255.255.0.

Una vez configurado OSPF y antes de ejecutar ningún comando más, vamos a borrar las posibles rutas aprendidas
para forzar que obtenga el router todas las rutas utilizando para ellos el nuevo protocolo de routing configurado. Para
ello, debemos ejecutar

Router#clear ip route *

3
Dependiendo del modelo del router, las interfaces se llamen FastEthernet o Ethernet
4
En los routers modulares la designación de interfaces es módulo/slot, por ejemplo 0/0, en los no modulares
simplemente slot, por ejemplo 0

5
Una vez inicializada la Routing Table (RT), contrastar la información que nos ofrece sobre OSPF los siguientes
comandos. Rellena la tabla de abajo:

Router# show ip protocol

Router# show ip ospf nei

Router# show ip route

¿Se ven todas las redes? En caso de no ver todas las redes comprobar que las configuraciones son correctas y que las
interfaces de todos los routers están operativas.

Prueba realizar ping a todas las interfaces de los routers. Si no funciona, ¡ resuelve los problemas!.

Hasta que no exista conectividad IP total no podemos continuar.

Los pasos para configurar los hosts son:

En este paso vamos a configurar los hosts conectados. Para configurar los host debemos conectarlo al conmutador
de una de las LANs de las sedes y asignar una IP y ruta por defecto. La configuración en los hosts es5:

ifconfig eth0 inet d.d.d.d netmask 255.255.255.0

route add default gw r.r.r.r

donde “d.d.d.d” es la dirección del host acorde con la figura anexa y “r.r.r.r” es la ruta por defecto.

Paso 2: estudio de la simulación de carga

Dado que esta práctica vamos a clasificar y marcar tráfico, así como repartirlo y gestionarlo a través de colas con
diferente disciplina de servicio, es conveniente repasar las posibilidades que nos ofrecen los routers y los hosts para
generar dicho tráfico.

En el caso particular de los routers, utilizamos el comando “ping” extendido con las siguientes opciones:

#ping
Protocol [ip]: ip Protocolo
Target IP address: 192.168.0.2 Destino
Repeat count [5]: 100 Número de envíos
Datagram size [100]: 1500 Tamaño
Timeout in seconds [2]: 0 Tiempo de espera para marcar time-out
Extended commands [n]: y Extensión de comandos
Source address or interface: Fastethernet0 Origen
Type of service [0]: 5 Campo Tipo de Servicio (TOS)6
Set DF bit in IP header? [no]: no Fijación del bit Don’t Fragment
Validate reply data? [no]: no Validación de las repeticiones
Data pattern [0xABCD]: Patrón en los datos
Loose, Strict, Record, Timestamp, Verbose[none]: Campo opciones de IP
Sweep range of sizes [n]: yes Habilitación de barrido
Sweep min size [36]: 36 Tamaño minimo de barrido
Sweep max size [18024]: 1500 Tamaño máximo de barrido
Sweep interval [1]: 1 Frecuencia de barrido
Type escape sequence to abort.

Sending 146500, [36..1500]-byte ICMP Echos to 192.168.0.2, timeout is 0 seconds:

Para comprobar el funcionamiento del tráfico generado, podemos utilizar el analizador de protocolos Ethereal si
conectamos algún hub en vez de algún conmutador. De esta forma, podemos observar el formato de salida de los
paquetes con las opciones de “ping” anteriores.

Para los hosts, podemos ver la ayuda con help (Windows) o man (Linux).

5
Si no funcionara el Telnet, desactivar el servicio DNS moviendo el fichero /etc/resolv.conf a otro nombre.
Acuérdese después de restaurarlo. Si aún así tampoco funcionara, desactive el firewall, “services iptables stop”
6
Los bits del byte de TOS (Type of Service) en los paquetes IP, son los mismos bits del campo DSCP en una versión
más obsoleta.

6
Paso 3: configuración y análisis de WFQ (Weigthed Fair Queueing) en todos los enlaces serie
En este paso vamos a comprobar inicialmente la configuración por defecto de los interfaces serie. Para ello
ejecutaremos para cada interfaz serie del router el siguiente comando, obteniendo una salida similar:

#show interface eth0

Ethernet0 is administratively down, line protocol is down
Hardware is PQUICC Ethernet, address is 000d.28dc.8565 (bia 000d.28dc.8565)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 10BaseT
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)

#show interface s0
Serial0 is administratively down, line protocol is down
Hardware is PowerQUICC Serial
MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/0/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 96 kilobits/sec

Dado que las interfaces funcionan a diferentes velocidades, la disciplina de servicio es FIFO y WFQ para Ethernet0
y Serial0 respectivamente como cabía esperar. En el caso que WFQ no estuviera habilitado en Serial0, se habilita
con el comando
(config)#interface serial 0
(config-if)#fair-queue

En el caso que observáramos un crecimiento de descartes o drops, una de las alternativas es aumentar el tamaño de
las colas por defecto, por ejemplo a 128 paquetes por cola con la siguiente configuración:
(config)#interface serial 0
(config-if)#fair-queue 128

Cambia el tamaño por defecto en todas las interfaces serie de los routers e indica el comando utilizado para
comprobar que la modificación ha tenido efecto.

¿Qué comando has utilizado?: _________________________________________________

Prueba los comandos, para todas las interfaces, tanto LAN como WAN. Por ejemplo, para la interfaz serie 0:

#show queue s0
#show queueing interface s0

Paso 4: configuración y análisis de PQ (Priority Queueing) en todos los enlaces serie

Realmente hemos comprobado que WFQ no da ninguna garantía de calidad de servicio, sin embargo PQ sí. Para
poder configurar PQ debemos definir los filtros que se van a utilizar para clasificar el tráfico mediante listas de
acceso (access-list), luego asociarlo con cada una de las 4 colas de PQ utilizando para ello el modo de configuración
“priority-list nºx” y finalmente asociar esta disciplina nº x a la interfaz de salida del router que nos interese.

En este paso vamos a configurar todas las interfaces serie de los routers de la maqueta con la siguiente
configuración. En particular se muestra la configuración para clasificar como “high” tráfico UDP y aquél
procedente de la Ethernet0, como “medium” tráfico TCP y como “low” tráfico ICMP, siendo el resto de tráfico
clasificado como “normal”:
7
(config)#access-list 111 permit udp any any
(config)#access-list 112 permit tcp any any

7
Recordar sobre la sintaxis de las listas de acceso, que esta es:
“access-list nº permit|deny protocolo “ip/máscara puerto origen” “ip/máscara puerto destino””

7
 (config)#access-list 113 permit icmp any any

(config)#priority-list 5 protocol ip high list 111

(config)#priority-list 5 interface eth0 high
(config)#priority-list 5 protocol ip medium list 112
(config)#priority-list 5 protocol ip low list 113

(config)#interface serial 0
(config-if)#priority-group 5

Esta configuración es relativamente simple, dado que en las diferentes listas de acceso sólo especificamos el
protocolo y no especificamos puertos, lo cual nos permitiría ajustar mejor a las diferentes aplicaciones utilizadas.

Para comprobar que la configuración es correcta, ejecutamos:

#show queueing priority

Para ver la cantidad de paquetes en cada cola (previamente debemos de haber generado cierto tráfico), utilizar el
siguiente comando:

#show queueing interface serial 0

Paso 5: configuración y análisis de CQ (Custom Queueing) en todos los enlaces serie

Sin embargo, uno de los problemas de PQ es que no es adaptativo y en ocasiones puede crear inanición.

Explique una situación donde PQ pueda crear inanición en una interfaz de salida:
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________

Para solucionar el problema de PQ vamos a configurar CQ que es un método más adaptativo. Por ejemplo vamos a
configurar los routers para realizar un reparto del ancho de banda con las siguientes proporciones: Voice over IP
(VoIP) 40%, FTP 20%, y HTTP 20%, dejando el 20% restante para los otros protocolos.

Para poder configurar CQ debemos definir los filtros que se van a utilizar para clasificar el tráfico mediante listas de
acceso (access-list) si fuera necesario, luego asociarlo con cada una de las colas de CQ utilizando para ello el modo
de configuración “queue-list nºx” y finalmente asociar esta disciplina nº x a la interfaz de salida del router que nos
interese.

(config)#queue-list 1 protocol ip 1 tcp ftp

(config)#queue-list 1 protocol ip 2 tcp www
(config)#queue-list 1 default 3

De momento hemos declarado una “queue-list 1” la cual asigna a la cola 1 el tráfico FTP, a la cola 2 el tráfico http y
por defecto a la cola 3 el resto. Ahora, vamos a asignar el tráfico VOIP en la cola 4. Para ello, dado que VOIP utiliza
TCP con puerto destino 1720 de señalización y UDP con rango de puertos destino de 16380 a 16480 para
conversación, vamos a utilizar el siguiente método de clasificación.

(config)#access-list 114 permit tcp any any eq 1720

(config)#access-list 114 permit udp any any range 16380 16480

(config)#queue-list 1 protocol ip 4 list 114

El orden asignado a cada cola es indiferente, pero no así el quanto asignado a cada una de ellas pues debe ser
definido acorde con los porcentajes indicados. Tomando por defecto el quanto de 1500 bytes y lo hacemos
corresponder con el 20% del ancho de banda, entonces para el caso de VOIP el quanto tendrá que ser de 3000 bytes,
el doble, pues su porcentaje es del 40%. Esta modificación de los quantos y reparto proporcional según los
percentiles especificados se realiza con la siguiente configuración:

(config)#queue-list 1 queue 1 byte-count 1500

(config)#queue-list 1 queue 2 byte-count 1500
(config)#queue-list 1 queue 3 byte-count 1500
(config)#queue-list 1 queue 4 byte-count 3000

Dado que una misma interfaz de salida sólo puede disponer de un tipo de disciplina de servicio, desconfiguraremos
PQ de todas las interfaces, por ejemplo para la interfaz serial0 con el comando

8
 (config)#interface serial 0
(config-if)#no priority-group 5

Ahora ya, el último paso es la asignación de la configuración a los interfaces serie respectivos de salida, que por
ejemplo para el interfaz serial 0 es mediante:
(config)#interface serial 0
(config-if)#custom-queue-list 1

Para comprobar que todo ha funcionado correctamente, podemos ejecutar los siguientes comandos:

#show queueing custom

Current custom queue configuration:
List Queue Args
1 3 default
1 1 protocol ip tcp port ftp
1 2 protocol ip tcp port www
1 4 protocol ip list 114
1 4 byte-count 3000

#clear counters
#show interfaces serial 0
Serial0 is up, line protocol is up
Hardware is PowerQUICC Serial
Internet address is …
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 5/255, rxload 5/255
Encapsulation …, loopback not set
…
Queueing strategy: custom-list 1
Output queues: (queue #: size/max/drops)
0: 0/20/0 1: 0/20/0 2: 0/20/0 3: 0/20/0 4: 0/20/0
5: 0/20/0 6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0
10: 0/20/0 11: 0/20/0 12: 0/20/0 13: 0/20/0 14: 0/20/0
15: 0/20/0 16: 0/20/0

Paso 6: configuración y análisis de CB-WFQ (Class Based Weigthed Fair Queueing) clasificación y marcado en
las LAN y política en los serie

De momento, las opciones que hemos visto han sido WFQ, PQ y CQ. En todas ellas tenemos ventajas e
inconvenientes. Con la disciplina CB-WFQ podemos juntar todas las ventajas y disminuir los inconvenientes. La
idea es clasificar y aplicar una política a las diferentes clases. Además, podemos ir más allá y marcar los paquetes de
forma que tenga un trato similar en el resto de la red, es lo que hemos comentado en la introducción de routers
frontera y routers internos.

En la práctica, vamos a realizar el siguiente procesado: el tráfico procedente de la LAN se marca, actuando como
router frontera y el tráfico que circula por los enlaces serie, se trata de guardar su política, actuando como router
interno.

Para poder configurar los routers con CB-WFQ, la versión de IOS que deben llevar debe ser mayor que la IOS 12.28.
Además, tenemos que activar en los routers Cisco 1721 un modo especial de conmutación rápida (por hardware) de
los paquetes, que se llama “Cisco Express Forwarding” o CEF9. También, antes de empezar a configurar debemos
deshabilitar las disciplinas configuradas en el apartado anterior:

(config)#interface serial 0
(config-if)#no custom-queue-list 1

Veamos y analicemos la siguiente configuración. En primer lugar vamos a clasificar el tráfico para VOIP (esto lo
habíamos realizado anteriormente con la ACL nº 114), HTTP, Telnet y FTP en diferentes clases que llamaremos
“voip”, “oro”, “plata” y “bronce” respectivamente.

(config)# ip cef

(config)# class-map voip

(config-cmap)# match access-group 114

(config)# class-map oro

(config-cmap)# match protocol http

(config)# class-map plata

(config-cmap)# match protocol telnet

8
Utilizar para ello el comando “show version”
9
Esto se activa con el comando “ip cef”

9
 (config)# class-map bronce
(config-cmap)# match protocol ftp

Para comprobar que hemos declarado correctamente la clasificación, podemos visualizarlo con:
#show class-map

Con ello, podemos pasar al marcado, que lo realizaríamos en un router frontera con la siguiente configuración.

(config)# policy-map marcado-frontera-LAN

(config-pmap)# class voip
(config-pmap-c)# set ip dscp ef

(config-pmap)# class oro

(config-pmap-c)# set ip dscp af31

(config-pmap)# class plata

(config-pmap-c)# set ip dscp af21

(config-pmap)# class bronce

(config-pmap-c)# set ip dscp af11

Para comprobar que hemos declarado correctamente la política, podemos visualizarlo con:
#show policy-map

Destacar los valores asignados según DSCP de EF (Expedited Forwarding) con prioridad 5 tal como hemos visto en
la figura 3, AF31 (Assured Forwarding31), AF21 y AF11.

Los diferentes valores que se disponen para marcar son tal como se especificó en la figura 3:

(config-pmap-c)#set ip dscp ?
<0-63> Differentiated services codepoint value
af11 Match packets with AF11 dscp (001010)
af12 Match packets with AF12 dscp (001100)
af13 Match packets with AF13 dscp (001110)
af21 Match packets with AF21 dscp (010010)
af22 Match packets with AF22 dscp (010100)
af23 Match packets with AF23 dscp (010110)
af31 Match packets with AF31 dscp (011010)
af32 Match packets with AF32 dscp (011100)
af33 Match packets with AF33 dscp (011110)
af41 Match packets with AF41 dscp (100010)
af42 Match packets with AF42 dscp (100100)
af43 Match packets with AF43 dscp (100110)
cs1 Match packets with CS1(precedence 1) dscp (001000)
cs2 Match packets with CS2(precedence 2) dscp (010000)
cs3 Match packets with CS3(precedence 3) dscp (011000)
cs4 Match packets with CS4(precedence 4) dscp (100000)
cs5 Match packets with CS5(precedence 5) dscp (101000)
cs6 Match packets with CS6(precedence 6) dscp (110000)
cs7 Match packets with CS7(precedence 7) dscp (111000)
default Match packets with default dscp (000000)
ef Match packets with EF dscp (101110)

Este mecanismo de clasificación y marcado lo vamos a aplicar en los routers en sus interfaces LAN, utilizando por
ejemplo para la interfaz FastEthernet.

(config)#interface FastEthernet0
service-policy input marcado-frontera-LAN

Realmente el tráfico procedente de la LAN, como tráfico de entrada ahora tendrá que gestionarse en los interfaces de
salida, en particular en los interfaces serie. Aquí es donde los routers actuarán como routers internos. Para ello
vamos a realizar previamente una clasificación en base al DSCP que es como vendrán todos los paquetes marcados
y luego aplicaremos una política en base a CB-WFQ.

(config)# class-map voip-dscp

(config-cmap)# match ip dscp ef

(config)# class-map oro-dscp

(config-cmap)# match ip dscp af31

(config)# class-map plata-dscp

(config-cmap)# match ip dscp af21

(config)# class-map bronce-dscp

(config-cmap)# match ip dscp af11

10
Para comprobar que hemos declarado correctamente la clasificación, podemos visualizarlo con:
#show class-map

Finalmente definimos las políticas, el trato a recibir, para cada clase de tráfico. Esta gestión caracteriza a los routers
internos y por tanto, una vez los paquetes vayan clasificados y marcados por el router frontera, siempre recibirán el
mismo trato. La definición de la política llamada “politica-qos” es como sigue:

(config)# policy-map politica-qos

(config-pmap)# class voip-dscp

(config-pmap-c)# priority 32 6000
(config-pmap)# class oro-dscp
(config-pmap-c)# bandwidth percent 20 10
(config-pmap-c)# random-detect dscp-based

(config-pmap)# class plata-dscp

(config-pmap-c)# bandwidth percent 10
(config-pmap-c)# random-detect dscp-based

(config-pmap)# class bronce-dscp

(config-pmap-c)# bandwidth percent 5
(config-pmap-c)# random-detect dscp-based

(config-pmap)# class class-default

(config-pmap-c)# fair-queue 16
(config-pmap-c)# queue-limit 20
(config-pmap-c)# random-detect

Para comprobar que hemos declarado correctamente la política, podemos visualizarlo con:
#show policy-map

Que se aplica en todas las interfaces de salida de los routers, tanto LAN como WAN:

(config)#interface Ethernet0
service-policy output politica-qos

(config)#interface FastEthernet0
service-policy output politica-qos

(config)#interface Serial0
service-policy output politica-qos

(config)#interface Serial1
service-policy output politica-qos

Una explicación de esta política es:

• La clase “voip-dscp” se le asigna una cola de prioridad estricta o LLQ (Low Latency Queueing). Esta cola
tendrá reservada 32 Kbps y con un buffer de 6000 bytes.

• La clase "oro-dscp" tiene una reserva de ancho de banda del 20% del canal disponible. Además, en
situaciones de congestión, activamos un mecanismo de descarte inteligente para evitar oscilaciones,
llamado Weigthed Random Early Discard (WRED), que lo configuramos dependiente del valor de DSCP
que tenga el paquete, para que la precedencia de descarte se base en dicho valor. Descartará primero
paquetes con menor valor de DSCP (en este caso particular todos los paquetes de la clase contienen el
mismo).

• La clase "plata-dscp" tiene una reserva de ancho de banda del 10% del canal disponible. También
activamos WRED en función del valor de DSCP.

• La clase "bronce-dscp" tiene una reserva de ancho de banda del 5% del canal disponible. También
activamos WRED en función del valor de DSCP.

• Finalmente, la clase por defecto en la que reservamos un total de 16 colas equitativas con un máximo de 20
paquetes por cola. Además activamos WRED para descarte inteligente de paquetes.

10
En este caso, dado que la clasificación sólo utiliza un criterio por clase de DSCP, pueda ser insignificante este
comando. Sin embargo, en la propia clasificación, se podría haber realizado más de un match y que no fuera sólo en
base a DSCP, por lo cual sí sería interesante hacer uso de los valores de DSCP en cada clase para hacer el descarte
inteligente de paquetes WRED.

11
Para comprobar que la configuración es correcta, podemos observarlo con el siguiente comando:
#show run

Paso 7: clasificación en capa 2, CoS (Class of Service)

En este paso vamos a comprobar las posibilidades de clasificación y marcación que disponen los conmutadores,
llamada CoS. Este tipo de configuración sólo aparece en conmutadores de gama media/alta y nos permite clasificar
las tramas de forma muy próxima al origen, con lo cual se puede garantizar mejor la calidad de servicio.

Para poder realizar la configuración de estos equipos, vamos a realizar un itinerario por sus modos de configuración.
Destacar que la configuración de los 2950 es muy similar a los conmutadores, la línea de comandos es muy parecida
y por tanto resulta familiar. Obviamente, difiere de los routers en su modo de configuración, pues los routers
configuran opciones de capa 3-4 y los conmutadores fundamentalmente de capa 2.

Nos conectamos a cada conmutador y vamos a inspeccionar ejecutando los siguientes comandos para ver las
posibilidades de marcación/clasificación utilizando los comandos de ayuda:

Switch>enable
Switch#configure terminal
Switch(config)#hostname Switch-acceso
Switch-acceso (config)#no ip domain-lookup

Accedemos en primer lugar para configurar un rango de interfaces, en particular para todas las disponibles en el
switch:

(config)#interface range fastethernet 0/1 – 24

El modo para configurar QoS se accede desde el comando “mls” (Multilayer Switch) en los conmtadores Catalyst de
Cisco :

(config-if-range)#mls ?
qos qos command keyword

En este modo, podemos modificar las CoS (cambiar el valor de las tramas entrantes por la interfaz) o bien aceptar
(confiar o trust) con el marcado de las tramas tal como entran por la interfaz. Vamos a ver las posibilidades en cada
uno de los 2 casos:
(config-if-range)#mls qos ?
cos cos keyword
trust trust keyword

(config-if-range)#mls qos cos ?

<0-7> class of service value between 0 and 7
override override keyword

(config-if-range)#mls qos cos 5

(config-if-range)#mls qos cos override

Con estas líneas hemos configurado que la CoS por defecto será de 5 (máxima prioridad o tipo EF según figura 3),
machando cualquier marcado entrante (override).

Continuando con el resto de opciones, tenemos:

(config-if-range)#mls qos ?
cos cos keyword
trust trust keyword

(config-if-range)#mls qos trust ?

cos cos keyword
device trusted device class
<cr>

(config-if-range)#mls qos trust cos ?

pass-through cos pass-through mode
<cr>

(config-if-range)#mls qos trust cos pass-through ?

12
 dscp transmit without dscp modification

Por tanto para confiar en el marcado DSCP de las tramas entrantes, configuramos:
(config-if-range)#mls qos trust cos pass-through dscp

(config-if-range)#mls qos trust device ?

cisco-phone Cisco IP Phone

(config-if-range)#mls qos trust device cisco-phone

Con todo ello, la configuración por ejemplo aplicada a la interfaz FastEthernet 0/1 es:
#show mls qos interface fa0/1
FastEthernet0/1
trust state: not trusted
trust mode: not trusted
COS override: ena
default COS: 5
pass-through: none
trust device: cisco-phone

Paso 8: dejarlo todo como al principio

Finalizada la práctica, dejaremos la configuración de los equipos y la maqueta tal como esta al principio de empezar
la práctica.

13
Router Name= Lab_A Router Name= Lab_B Router Name= Lab_C Router Name= Lab_D Router Name= Lab_E
EO= 205.7.5.1 EO = 219.17.100.1 EO = 223.8.151.1 EO = 210.93.105.1 EO = 210.93.105.2
E1= 192.5.5.1 SO = 199.6.13.1 SO = 204.204.7.1 S1 = 204.204.7.2 S1 = 200.200.200.1
SO = 201.100.11.1 S1 = 201.100.11.2 S1 = 199.6.13.2 MS(EO)= 255.255.255.0 MS(EO)= 255.255.255.0
S1 = _200.200.200.2 MS(EO)= 255.255.255.0 MS(EO)= 255.255.255.0 MS(S1)= 255.255.255.252 MS(S1)= 255.255.255.252
MS(EO)= 255.255.255.0 MS(S0)= 255.255.255.252 MS(S0)= 255.255.255.252
MS(E1)= 255.255.255.0 MS(S1)= 255.255.255.252 MS(S1)= 255.255.255.252
MS(S0)= 255.255.255.252
MS(S1)= 255.255.255.252
Name= ET_1 Name= ET_2 Name= ET_3 Name= ET_4 Name= ET_5
IP= 192.5.5.101 IP= 219.17.100.101 IP= 223.8.151.101 IP= 210.93.105.101 IP= 210.93.105.102
MS= 255.255.255.0 MS= 255.255.255.0 MS= 255.255.255.0 MS= 255.255.255.0 MS= 255.255.255.0
GW = 192.5.5.1 GW = 219.17.100.1 GW = 223.8.151.1 GW = = 210.93.105.1 GW = = 210.93.105.2

14