1

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

2

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

3

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

4

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

5

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

6

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 Target IP address: 192.168.0.2 Repeat count [5]: 100 Datagram size [100]: 1500 Timeout in seconds [2]: 0 Extended commands [n]: y Source address or interface: Fastethernet0 Type of service [0]: 5 Set DF bit in IP header? [no]: no Validate reply data? [no]: no Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: yes Sweep min size [36]: 36 Sweep max size [18024]: 1500 Sweep interval [1]: 1 Type escape sequence to abort.

Protocolo Destino Número de envíos Tamaño Tiempo de espera para marcar time-out Extensión de comandos Origen Campo Tipo de Servicio (TOS)6 Fijación del bit Don’t Fragment Validación de las repeticiones Patrón en los datos Campo opciones de IP Habilitación de barrido Tamaño minimo de barrido Tamaño máximo de barrido Frecuencia de barrido

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.

7

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

(config)#access-list 111 permit udp any any7 (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””

8

(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

9

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

10

(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

11

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 (config-pmap-c)# random-detect dscp-based10 (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.

12

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 ?

13

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.

14

Router Name= Lab_A EO= 205.7.5.1 E1= 192.5.5.1 SO = 201.100.11.1 S1 = _200.200.200.2 MS(EO)= 255.255.255.0 MS(E1)= 255.255.255.0 MS(S0)= 255.255.255.252 MS(S1)= 255.255.255.252

Router Name= Lab_B EO = 219.17.100.1 SO = 199.6.13.1 S1 = 201.100.11.2 MS(EO)= 255.255.255.0 MS(S0)= 255.255.255.252 MS(S1)= 255.255.255.252

Router Name= Lab_C EO = 223.8.151.1 SO = 204.204.7.1 S1 = 199.6.13.2 MS(EO)= 255.255.255.0 MS(S0)= 255.255.255.252 MS(S1)= 255.255.255.252

Router Name= Lab_D EO = 210.93.105.1 S1 = 204.204.7.2 MS(EO)= 255.255.255.0 MS(S1)= 255.255.255.252

Router Name= Lab_E EO = 210.93.105.2 S1 = 200.200.200.1 MS(EO)= 255.255.255.0 MS(S1)= 255.255.255.252

Name= ET_1 IP= 192.5.5.101 MS= 255.255.255.0 GW = 192.5.5.1

Name= ET_2 IP= 219.17.100.101 MS= 255.255.255.0 GW = 219.17.100.1

Name= ET_3 IP= 223.8.151.101 MS= 255.255.255.0 GW = 223.8.151.1

Name= ET_4 IP= 210.93.105.101 MS= 255.255.255.0 GW = = 210.93.105.1

Name= ET_5 IP= 210.93.105.102 MS= 255.255.255.0 GW = = 210.93.105.2