Implementación de QoS en la red LAN de la UTPL

(1)

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

La Universidad Católica de Loja

TITULACIÓN DE INGENIERO EN ELECTRÓNICA Y TELECOMUNICACIONES

Implementación de QoS en la red LAN de la UTPL

Trabajo de fin de titulación

AUTORES:

Arrobo León, Jimmy Daniel

Sarmiento Salcedo, María del Cisne

DIRECTOR:

Jaramillo Campoverde, Byron Gustavo, Ing.

(2)

Loja, Abril de 2013

Ing. Byron Gustavo Jaramillo Campoverde

DIRECTOR DEL TRABAJO DE FIN DE TITULACIN

Dejo constancia de haber revisado y estar de acuerdo con el proyecto de fin de carrera, titulado: “Implementación de QoS en la red LAN de la UTPL”.

Presentado por:

Jimmy Daniel Arrobo León

María del Cisne Sarmiento Salcedo

Particular que comunico para los fines legales pertinentes.

---

Ing. Byron Gustavo Jaramillo Campoverde

Visto Bueno Titulación de la Carrera

F)... Ing. Jorge Luis Jaramillo

COORDINADOR DE LA TITULACIÓN DE ELECTRÓNICA Y TELECOMUNICACIONES

(3)

ACTA DE CESIÓN DE DERECHOS EN TESIS DE GRADO

Nosotros, Jimmy Daniel Arrobo León, María del Cisne Sarmiento Salcedo, declaramos ser autores del presente trabajo y eximimos expresamente a la Universidad Técnica Particular de Loja y a sus representantes legales de posibles reclamos o acciones legales.

Adicionalmente declaramos conocer y aceptar la disposición del Art. 67 del Estatuto Orgánico de la Universidad Técnica Particular de Loja que en su parte pertinente textualmente dice: “Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos científicos o técnicos y tesis de grado que se realicen a través, o con el apoyo financiero, académico o institucional (operativo) de la Universidad”

(4)

AUTORÍA

Las ideas, opiniones, conclusiones, y contenidos expuestos en el presente informe de investigación son de exclusiva responsabilidad de sus autores.

(5)

DEDICATORIA

Dedico este trabajo a Dios por darme la vida y la salud de cada día; a mis padres Aurelio y Norma quienes son el ejemplo de mi existencia y la fuerza de superarme en los retos propuestos, y a toda mi familia les dedico este triunfo alcanzado porque su apoyo fue incondicional en las noches de desvelo y en los días difíciles.

A mis abuelos, tíos, primos y amigos que constituyeron uno de los pilares en mi formación como profesional, va por ti abuelo Alejandro quien desde la presencia del señor me regala su bendición como guía en este nuevo caminar.

Este trabajo lo dedico a todos quienes hicieron posible que esta etapa de mi vida concluya con el proyecto que culmina mi formación profesional, en especial a Gabriela Luna por darme aliento, consejos sabios y palabras de constancia.

Jimmy

Dedico este trabajo en primer lugar a Dios y la Virgen del Cisne por darme la fortaleza necesaria para sobrellevar y superar los momentos difíciles; a mis padres Luis Ezequiel y Patricia del Carmen por su confianza infinita en mí, todo lo que soy se lo debo a ellos.

A mi hermano Luis Alberto por ser un ejemplo de superación y perseverancia; a mi hermana María Patricia por su apoyo y protección incondicional, por ser mi mejor amiga, mi compañera, por ser simplemente mi alma gemela. Igualmente dedico este logro al resto de mi familia, abuelitos, tíos, primos que son una parte fundamental de mi vida.

A mis amigas Karen, Gaby V., Nanci, Silvana, Gaby P., Mónica, por las experiencias compartidas, los consejos dados, y su amistad verdadera.

(6)

AGRADECIMIENTO

En primer lugar, agradecemos a Dios por iluminar en el trascurso de nuestras vidas nuestros caminos para obrar con sabiduría, responsabilidad y ética. Agradecemos a nuestros padres por apoyarnos a culminar nuestros estudios con el fin de lograr el desarrollo profesional.

De igual manera, agradecemos al Ing. Byron Jaramillo por ser guía en la elaboración y desarrollo de este proyecto, por sus conocimientos compartidos, empeño y apoyo incondicional en la culminación del mismo. A los docentes de la UTPL que inculcaron sus conocimientos y experiencias en todo nuestro proceso de formación universitaria, para alcanzar el objetivo de ser profesionales activos con el desarrollo de nuestro país.

Agradecemos también a la Universidad Técnica Particular de Loja por facilitar los recursos necesarios en este proyecto, de forma especial al Departamento de Infraestructura de TI, y al Departamento de Cursos Especializados de la Unidad de Gestión de Tecnologías de la Información - UGTI.

Sin olvidarnos de agradecer a nuestros amigos y compañeros de aula que estuvieron presentes con su amistad y apoyo durante los años de estudio como profesionales en formación de la carrera de Electrónica y Telecomunicaciones.

(7)

TABLA DE CONTENIDO

CERTIFICACIÓN: ACEPTACIÓN DE PROYECTO DE FIN DE CARRERA ... I

ACTA DE CESIÓN DE DERECHOS EN TESIS DE GRADO ... II

AUTORÍA ... III

DEDICATORIA ... IV

AGRADECIMIENTO ... V

TABLA DE CONTENIDO ... VI

LISTA DE FIGURAS ... IX

LISTA DE TABLAS ... X

RESUMEN EJECUTIVO ... XIII

INTRODUCCIÓN ... XIV

OBJETIVOS... XV

CAPÍTULO I ... 1

1. ESTUDIO DE LA SITUACIÓN ACTUAL DE LA RED LAN DE LA UTPL ... 1

1.1 ANÁLISIS DE LA INFRAESTRUCTURA DE LA RED LAN-UTPL ... 1

1.1.1 Topología de la red ... 1

1.1.2 Backbone UTPL ... 1

1.1.3 Equipos de red ... 3

1.1.3.1 Serie Catalyst 2950 ... 3

1.1.3.2 Serie Catalyst 2960 ... 3

1.1.3.3 Serie Catalyst 3550/3560 ... 4

1.2 INVENTARIO DE LA RED LAN UTPL ... 4

1.2.1 Modelos y versiones del Sistema Operativo de Interconexión (IOS) en la red LAN ... 4

1.2.1.1 Modelos de switches ... 4

1.2.1.2 Versiones de IOS disponibles en switches ... 5

1.3 ANÁLISIS DEL IOS DE CISCO CON SOPORTE DE QOS ... 8

1.3.1 Características de las imágenes de Cisco para QoS ... 8

1.3.1.1 Imágenes del software de Cisco Catalyst 2950 ... 8

1.3.1.2 Imágenes del software de Cisco Catalyst 2960 ... 10

1.3.1.3 Imágenes del Cisco switch Catalyst 3550 / 3560 ... 11

1.4 CONFIGURACIONES BÁSICAS EN LOS SWITCHES CATALYST CON IMPLEMENTACION DE QOS ... 12

1.4.1 Verificación de la versión del switch ... 13

1.4.1.1 Soporte de la imagen IOS cisco para QoS estándar o mejorado ... 13

1.4.1.2 Resultados de la verificación de versión e imagen IOS de Cisco ... 14

1.5 RESUMEN DE CARACTERÍSTICAS QOS EN LOS SWITCHES DE LA RED LAN UTPL ... 15

1.5.1 Resumen de los modelos de switches ... 15

(8)

CAPÍTULO II ... 19

2. ESTUDIO SOBRE LOS MÉTODOS DE PRIORIZACIÓN DE TRÁFICO ... 19

2.1 MODELOS Y MECANISMOS DE PRIORIZACIÓN DE TRÁFICO ... 19

2.1.1 Marco Teórico ... 19

2.1.2 Calidad de servicio (QoS) ... 19

2.1.2.1 Clase de Servicio (CoS) ... 24

2.1.2.2 Tipo de servicio (ToS) ... 25

2.1.2.3 Grado de servicio (GoS) ... 26

2.1.3 Modelos de priorización QoS ... 26

2.1.3.1 Modelo de servicio “Mejor esfuerzo” ... 26

2.1.3.2 Modelo de servicios integrados (IntServ) ... 26

2.1.3.3 Modelo de servicios diferenciados (DiffServ) ... 30

2.1.4 Mecanismos para administrar calidad de servicio ... 36

2.1.4.1 Manejo de congestión de colas... 37

2.1.4.2 Mecanismo de manejo de tráfico ... 42

2.1.5 Modelamiento y manipulación del tráfico ... 46

2.1.5.1 Manipulación y clasificación del tráfico... 47

2.1.6 Ventajas y desventajas de los modelos de priorización ... 48

2.2 MÉTODOS DE PRIORIZACIÓN PARA UNA RED LAN ... 52

2.2.1 Análisis de modelos y mecanismos de QoS en una red LAN ... 52

2.2.1.1 Requerimientos de QoS de una red LAN ... 52

2.2.2 Mecanismos de priorización QoS en la estructura de una red LAN ... 57

2.2.2.1 Estructura de una red para aplicaciones de voz, video y datos ... 57

2.2.2.2 Características de QoS en el esquema LAN ... 61

2.3 ANÁLISIS DE OTRAS TECNOLOGÍAS DE NETWORKING EN TORNO A QOS ... 71

2.3.1 Características QoS en tecnología 3COM ... 71

2.3.2 Características de QoS en tecnología D-LINK ... 72

2.3.3 Características de QoS en Mikrotik ... 74

2.4 SITUACIÓN ACTUAL DE IMPLEMENTACIÓN DE QOS EN ECUADOR ... 75

2.4.1 Experiencias de empresas e instituciones en torno a la implementación de QoS ... 76

2.5 VENTAJAS Y DESAFÍOS DE MÉTODOS DE PRIORIZACIÓN PARA LA RED LAN ... 76

2.5.1 Ventajas de los métodos de priorización ... 78

REFERENCIAS ... 79

CAPÍTULO III ... 81

3. DESARROLLO DE UN AMBIENTE DE LABORATORIO PARA PRUEBAS ... 81

3.1 DETERMINACIÓN DEL ALCANCE DEL LABORATORIO ... 81

3.2 CARACTERÍSTICAS Y REQUERIMIENTOS DEL LABORATORIO ... 81

3.2.1 Componentes de la red ... 82

3.2.1.1 Esquema general de la red ... 82

3.2.1.2 Equipos de red ... 83

3.2.1.3 Servidores ... 83

3.2.2 Configuración de equipos para el laboratorio ... 86

(9)

3.2.2.2 Características del laboratorio con QoS ... 87

3.2.3 Herramientas usadas en el laboratorio ... 90

3.2.3.1 Inyector de tráfico D-ITG ... 90

3.2.3.2 Analizador de tráfico Wireshark ... 92

3.3 REALIZACIÓN DE PRUEBAS ... 93

3.3.1 Fase 1 ... 93

3.3.2 Fase 2 ... 93

3.3.3 Tipos de escenarios ... 94

3.3.3.1 Escenario uno (sin QoS vs con Qos) ... 94

3.3.3.2 Escenario dos ... 95

3.3.3.3 Escenario tres ... 96

3.4 RESULTADOS DE LAS PRUEBAS ... 97

3.4.1 Cálculo matemático de los parámetros de QoS para el laboratorio ... 97

3.4.2 Tabulación de resultados para cada escenario... 98

3.4.2.1 Escenario uno (sin QoS vs con QoS) ... 99

3.4.2.2 Escenario dos ... 100

3.4.2.3 Escenario tres ... 101

3.4.3 Comparación de resultados medidos y calculados ... 102

3.5 EVALUACIÓN DE RESULTADOS ... 104

3.5.1 Análisis de resultados escenario uno ... 104

3.5.2 Análisis de resultados escenario dos ... 105

3.5.3 Análisis de resultados escenario tres ... 105

3.5.4 Verificación de QoS en la red ... 106

3.5.4.1 Switch Catalyst 2960 ... 106

3.5.4.2 SW Catalyst 3550 ... 107

CAPÍTULO IV ... 108

4. EVALUACIÓN DE MÉTODOS DE PRIORIZACION PARA UNA RED LAN ... 108

4.1 INTRODUCCIÓN ... 108

4.2 CLASIFICACIÓN GENERAL ... 109

4.2.1 Algoritmos de encolamiento y planificación ... 109

4.2.1.1 Algoritmo Round Robin modelado (SRR) ... 109

4.2.1.2 Algoritmo Round Robin balanceado (WRR) ... 110

4.2.2 Algoritmos para el control de la congestión ... 110

4.2.2.1 Descarte de cola balanceado (WTD) ... 110

4.2.2.2 Detección temprana aleatoria balanceada (WRED) ... 111

4.3 ANÁLISIS DE LOS RESULTADOS EN CADA ALGORITMO ... 112

4.3.1 Switch Catalyst 2960... 112

4.3.2 Switch Catalyst 3550... 113

4.4 COMPARACIÓN DEL MEJOR MÉTODO DE PRIORIZACIÓN ... 113

4.5 DETERMINACIÓN DEL MÉTODO DE QOS PARA UNA RED LAN ... 114

REFERENCIAS ... 116

5. IMPLEMENTACIÓN DE QOS EN ÁREA OPERATIVA DE LA RED LAN UTPL ... 117

(10)

5.2 REQUERIMIENTOS DE QOS PARA LA APLICACIÓN EN EL ÁREA OPERATIVA ... 118

5.2.1 Descripción de los requerimientos para la implementación de QoS ... 118

5.2.2 Recursos y herramientas en la implementación de QoS ... 121

5.2.2.1 Cacti ... 121

5.2.2.2 Sincronización... 123

5.3 REALIZACIÓN DE PRUEBAS EN AREA OPERATIVA DE LA UTPL ... 123

5.3.1 Parámetros de ejecución de pruebas ... 123

5.3.2 Resultados de las pruebas realizadas en el área operativa ... 124

5.4 ANÁLISIS DE RESULTADOS ... 125

5.5 EVALUACION DE IMPLEMENTACION ... 128

REFERENCIAS ... 130

CONCLUSIONES ... 131

RECOMENDACIONES ... 134

ANEXOS ... 136

ANEXO A. CAPTURAS DE CONSUMO DE TRÁFICO OBTENIDAS DE SERVIDOR NETFLOW ... 136

ANEXO B. CONFIGURACIONES DE EQUIPOS MEDIANTE CLI ... 149

ANEXO C. CAPTURA DEL TRÁFICO MEDIANTE EL ANALIZADOR WIRESHARK ... 164

ANEXO D. VERIFICACIÓN DE QOS EN LOS SWITCH ... 169

ANEXO E. GRAFICAS DE CONSUMO DE TRÁFICO (SERVIDOR CACTI) ... 175

ANEXO F. PAPER: IMPLEMENTACIÓN DE QOS EN LA RED LAN DE LA UTPL ... 183

[image:10.595.98.514.68.451.2]

LISTA DE FIGURAS FIG. 1.1 BACKBONE DE LA UTPL ... 2

FIG. 1.2 DIFERENCIAS QOS PARA LOS DOS TIPOS DE IMÁGENES SOFTWARE CATALYST 2960 ... 10

FIG. 1.3 CISCO IOS PACKAGING ... 12

FIG. 1.4 RESULTADO COMANDO SHOW VERSION CATALYST 2950-24 ... 14

FIG. 1.5 RESULTADO COMANDO SHOW VERSION CATALYST 2950T-24 ... 14

FIG. 2.1 ARQUITECTURA QOS ... 23

FIG. 2.2 NIVELES DE TOS ... 25

FIG. 2.3 REPARTO DE RECURSOS EN INTSERV ... 27

FIG. 2.4 MODELO DE REFERENCIA DE SERVICIOS INTEGRADOS ... 29

FIG. 2.5 CÓDIGOS DEL PHB AF - RFC 2597 ... 32

FIG. 2.6 ARQUITECTURA MODELO DIFFSERV ... 33

FIG. 2.7 REPARTO DE RECURSOS EN EL MODELO DIFFSERV ... 35

FIG. 2.8 FUNCIONAMIENTO DE DIFFSERV EN INTERNET ... 36

FIG. 2.9 CAUSAS DE CONGESTIÓN EN INTERFACES ... 37

(11)

FIG. 2.11 ESQUEMA GRÁFICO PQ ... 39

FIG. 2.12 ESQUEMA GRÁFICO WFQ] ... 40

FIG. 2.13 DETECCIÓN TEMPRANA ALEATORIA ... 43

FIG. 2.14 PROBABILIDAD DE BLOQUEO Y LONGITUD DE COLA ... 44

FIG. 2.15 ESQUEMA GRÁFICO WRED ... 44

FIG. 2.16 REQUERIMIENTOS QOS PARA VOZ ... 53

FIG. 2.17 REQUERIMIENTOS DE QOS PARA VIDEO ... 55

FIG. 2.18 REQUERIMIENTOS DE QOS PARA DATOS ... 56

FIG. 2.19 NIVEL DE CORE EN UNA RED ... 57

FIG. 2.20 INFRAESTRUCTURA DE RED “CAMPUS” PARA APLICACIONES VOZ, VIDEO Y DATOS ... 58

FIG. 2.21 MECANISMOS DE CONDICIONAMIENTO DE TRÁFICO EN IOS DE CISCO ... 60

FIG. 2.22 ESQUEMA CISCO QOS TOOLSET, QOS TOOLS CISCO ... 61

FIG. 2.23 MODELO BÁSICO DE QOS CATALYST 2950/3550 ... 62

FIG. 2.24 MODELO BÁSICO DE QOS CATALYST 2960, CATALYST 3560 ... 63

FIG. 2.25 UBICACIÓN DE COLAS DE ENTRADA Y SALIDA, QOS CATALYST 2960/CATALYST 3560 ... 68

FIG. 2.26 DIAGRAMA DE FLUJO ENCOLAMIENTO Y PLANIFICACIÓN PARA PUERTOS DE ENTRADA Y SALIDA PARA QOS, CATALYST 2960, CATALYST 3560 ... 68

FIG. 2.27 DIAGRAMAS DE FLUJO DE ENCOLAMIENTO Y PLANIFICACIÓN PARA PUERTOS GIGABIT CATALYST 3550 ... 69

FIG. 2.28 DIAGRAMAS DE FLUJO DE ENCOLAMIENTO Y PLANIFICACIÓN PARA PUERTOS FAST ETHERNET CATALYST 3550 ... 70

FIG. 2.29 OPCIÓN QOS ENGINE. SOPORTE D-LINK TRAFFIC SHAPPING ... 73

FIG. 2.30 DIAGRAMA FLUJO DE PAQUETES ... 74

FIG. 2.31 MODELO DE CLASES DE TRÁFICO EN ENTORNOS EMPRESARIALES ... 77

FIG. 3.1 ESQUEMA DE RED AMBIENTE DE LABORATORIO ... 82

FIG. 3.2 COMANDOS PARA EXPORTAR FLUJOS DEL ROUTER AL NETFLOW ... 85

FIG. 3.3 COMANDOS MQC PARA EL CATALYST 2960 LAN SERIES ... 88

FIG. 3.4 COMANDOS MQC PARA EL CATALYST 3550 IPSERVICES ... 89

FIG. 3.5 TOPOLOGÍA ESCENARIO UNO ... 95

FIG. 3.6 TOPOLOGÍA ESCENARIO DOS Y TRES. ... 96

FIG. 4.1 CLASIFICACIÓN GENERAL DE MÉTODOS DE PRIORIZACIÓN ... 109

FIG. 5.1 ESQUEMA DE RED DEL ÁREA OPERATIVA DE UTPL ... 118

LISTA DE TABLAS TABLA 1.1 MODELOS CATALYST 2950. ... 3

TABLA 1.2 MODELOS CATALYST 2960. ... 3

TABLA 1.3 MODELOS CATALYST3550-3560. ... 4

TABLA 1.4 VERSIONES DE CISCO CONFORME LA TECNOLOGÍA ... 7

TABLA 1.5 CARACTERÍSTICAS DE QOS PARA VERSIONES DE IOS SI / EI ... 9

TABLA 1.6 RESUMEN VERSIONES IOS PARA CATALYST 2950 SERIES ... 15

TABLA 1.7 RESUMEN DE VERSIONES IOS PARA CATALYST 3550 & CATALYST 3560 SERIES ... 15

(12)

TABLA 1.9 RESUMEN DE LOS DIFERENTES MODELOS DE SWITCHES CATALYST 2950 Y SU IMAGEN DE CISCO ... 16

TABLA 1.10 RESUMEN DE LOS DIFERENTES MODELOS DE SWITCHES CATALYST 2960 Y SU IMAGEN DE CISCO ... 16

TABLA 1.11 RESUMEN DE LOS DIFERENTES MODELOS CATALYST 3550 & CATALYST 3560 Y SU IMAGEN DE CISCO ... 17

TABLA 1.12 RESUMEN DE LOS SWITCHES POR SERIES Y TIPO DE QOS QUE SOPORTAN ... 17

TABLA 2.1 PARÁMETROS DE QOS ... 20

TABLA 2.2 REQUERIMIENTOS DE QOS SEGÚN LA APLICACIÓN ... 22

TABLA 2.3 VALORES DE PRIORIDAD COS... 24

TABLA 2.4 APLICACIONES VS FLEXIBILIDAD DE PÉRDIDAS ... 27

TABLA 2.5 COMPONENTES DE UN NODO FRONTERA ... 34

TABLA 2.6 RESUMEN DE LAS TÉCNICAS DE QOS PARA CADA CLASE DE SERVICIO ... 36

TABLA 2.7 NÚMERO DE COLAS WFQ VS ANCHO DE BANDA ... 40

TABLA 2.8 PROCESO DE DESCARTE DE COLAS WFQ ... 41

TABLA 2.9 VENTAJAS Y DESVENTAJAS DE MODELOS DE SERVICIOS INTSERV Y DIFFSERV ... 49

TABLA 2.10 VENTAJAS Y DESVENTAJAS DE LOS MECANISMOS DE ENCOLAMIENTO ... 50

TABLA 2.11 VENTAJAS Y DESVENTAJAS DE LOS MÉTODOS PARA EL MANEJO DE TRÁFICO ... 51

TABLA 2.12 ANCHOS DE BANDA BAJO ETHERNET PARA VOZ ... 54

TABLA 2.13 DIFERENCIAS EN QOS PARA SOFTWARE CISCO CATALYST 2960 ... 67

TABLA 2.14 MECANISMOS DEL MODELO DIFFSERV PARA QOS EN LOS EQUIPOS 3COM ... 72

TABLA 2.15 CARACTERÍSTICAS DE QOS PARA APLICACIONES DE DIFERENTE TRÁFICO... 77

TABLA 3.1 CONFIGURACIÓN PRUEBA 1, SIN SATURACIÓN TABLA 3.2 CONFIGURACIÓN PRUEBA 2, CON SATURACIÓN ... 94

TABLA 3.3 CONFIGURACIÓN PRUEBA 3, CON SATURACIÓN ... 94

TABLA 3.4 RESULTADOS DE LA PRUEBA 1, ESCENARIO UNO SIN SATURACIÓN DEL CANAL ... 99

TABLA 3.5 RESULTADOS DE LA PRUEBA 2, ESCENARIO UNO CON SATURACIÓN DEL CANAL ... 99

TABLA 3.6 RESULTADOS DE LA PRUEBA 3, ESCENARIO UNO CON SATURACIÓN DEL CANAL ... 99

TABLA 3.7 RESULTADOS DE LA PRUEBA 1, ESCENARIO DOS SIN SATURACIÓN DEL CANAL ... 100

TABLA 3.8 RESULTADOS DE LA PRUEBA 2, ESCENARIO DOS CON SATURACIÓN DEL CANAL ... 100

TABLA 3.9 RESULTADOS DE LA PRUEBA 3, ESCENARIO DOS CON SATURACIÓN DEL CANAL ... 100

TABLA 3.10 RESULTADOS DE LA PRUEBA 1, ESCENARIO TRES SIN SATURACIÓN DEL CANAL ... 101

TABLA 3.11 RESULTADOS DE LA PRUEBA 2, ESCENARIO TRES CON SATURACIÓN DEL CANAL ... 101

TABLA 3.12 RESULTADOS DE LA PRUEBA 3, ESCENARIO TRES CON SATURACIÓN DEL CANAL ... 101

TABLA 3.13 RESUMEN DE RESULTADOS ESCENARIO UNO - PRUEBA 1, UDP ... 102

TABLA 3.14 RESUMEN DE RESULTADOS ESCENARIO UNO - PRUEBA 1, TCP ... 102

TABLA 3.15 COMPARACIÓN DE VALOR CALCULADO VS VALOR MEDIDO PARA RETARDO, SIN QOS Y CON QOS ... 103

TABLA 3.16 COMPARACIÓN DE VALOR CALCULADO VS VALOR MEDIDO PARA ANCHO DE BANDA, SIN QOS Y CON QOS ... 103

TABLA 3.17 COMANDOS DE VERIFICACIÓN DE QOS, SWITCH CATALYST 2960 ... 106

TABLA 3.18 COMANDOS DE VERIFICACIÓN DE QOS, SWITCH CATALYST 3550 ... 107

TABLA 5.1 CONFIGURACIÓN PRUEBA 4, SATURACIÓN TABLA 5.2 CONFIGURACIÓN PRUEBA 5, SATURACIÓN ... 123

TABLA 5.3 RESULTADOS DE LA PRUEBA 1, SIN SATURACIÓN DEL CANAL ... 124

TABLA 5.7 RESULTADOS DE LA PRUEBA 5, CON SATURACIÓN DEL CANAL ... 125

TABLA 5.8 CONSUMO DE ANCHO DE BANDA, PRUEBA 1 Y 2. ... 126

(13)

TABLA 5.10 AUMENTO DE RETARDO Y JITTER DE LA PRUEBA 2 EN COMPARACIÓN CON PRUEBA 1. ... 126

TABLA 5.11 AUMENTO DE RETARDO Y JITTER DE LA PRUEBA 4 EN COMPARACIÓN CON PRUEBA 3. ... 127

TABLA 5.12 PÉRDIDA DE PAQUETES EN VLAN4. ... 127

(14)

RESUMEN EJECUTIVO

(15)

INTRODUCCIÓN

En la actualidad, las Redes de Área Local (LAN) poseen una demanda de servicios de tiempo real, tal como VoIP, videoconferencia, y demás aplicaciones acordes a las necesidades empresariales, y que para su normal funcionamiento es necesario que ciertos parámetros como retardo, jitter, ancho de banda y pérdida de paquetes cumplan con un valor confiable para la comunicación, sin afectar el rendimiento de la red. Por tanto, el administrador de una red LAN busca mecanismos para que los tráficos generados por estas aplicaciones sean priorizados de distinta forma que el resto del tráfico presente en la red. Particularmente la red LAN de la Universidad Técnica Particular de Loja (UTPL) es un caso de estudio para que estos mecanismos sean implementados a partir del concepto de calidad de servicio (QoS).

La implementación de QoS parte de la evaluación del estado actual de la red LAN UTPL, analizando la aplicabilidad de QoS en base al entorno de red establecido por su topología y equipamiento. Conforme a la situación actual de la red LAN UTPL, se investigan métodos y mecanismos de QoS aplicables a una red LAN tomando en cuenta las tecnologías que mejores características de priorización provean a la red; por ende, se enfocó el estudio de QoS en la tecnología Cisco. Se constituyó un ambiente de laboratorio para ejecutar pruebas en diferentes escenarios que diferencien una red con características de QoS y sin QoS, además de la evaluación de dos mecanismos de priorización de tráfico. Definiéndose el mejor método de priorización de QoS para éste ambiente de laboratorio, como base para la implementación de QoS en un área operativa de la red LAN UTPL.

(16)

OBJETIVOS

Objetivo General.-

Realizar un estudio de calidad de servicio (QoS) para su implementación en la red LAN de la Universidad Técnica Particular de Loja como una solución de priorización de tráfico.

Objetivos Específicos.-

• Analizar la situación actual de la red LAN de la UTPL con relación al tema de QoS y su aplicabilidad en equipamiento y topología.

• Investigar modelos y mecanismos de QoS en redes de computadoras con enfoque en métodos de priorización de tráfico en redes LAN.

• Estructurar un ambiente de laboratorio para realizar pruebas en escenarios con QoS y sin QoS analizando el rendimiento de una red LAN mediante el uso de algoritmos de priorización.

• Comparar y determinar el mejor método de priorización para QoS en una red LAN en base a resultados del ambiente de laboratorio.

(17)

CAPÍTULO I

1. ESTUDIO DE LA SITUACIÓN ACTUAL DE LA RED LAN DE LA UTPL

Este capítulo consiste en el estudio de la infraestructura física y lógica de la red LAN de la UTPL, con la finalidad de establecer la aplicabilidad de QoS de acuerdo a los recursos que presenta la red en su inventario, así como los flujos de datos que se generan.

1.1 ANÁLISIS DE LA INFRAESTRUCTURA DE LA RED LAN-UTPL

1.1.1 Topología de la red

De acuerdo a la información facilitada por parte del departamento de Tecnologías de la Información (TI), la topología de la red LAN UTPL es de tipo estrella extendida (ver figura 1.1), que mediante la conexión de switches puede extender su alcance y cobertura.

Esta topología de red distingue niveles de acceso, distribución, y core, como esquema principal de la red LAN; dónde el switch de core es localizado en el edificio de UGTI como eje inicial de la red, y posteriormente se manejan switches de distribución y acceso por cada área operativa de la red LAN de UTPL.

De acuerdo a la figura 1.1, la topología está compuesta de un nodo principal (UGTI) y 21 nodos secundarios interconectados mediante fibra óptica, cable Ethernet y enlaces inalámbricos.

1.1.2 Backbone UTPL

(18)

Fig. 1.1 Backbone de la UTPL1

A continuación, se especifica la forma de conexión entre el switch de Core, ubicado en la Unidad de Gestión de Tecnologías de la Información (ver figura 1.1), y los diferentes edificios del campus UTPL.

• Conexión mediante Fibra Óptica: Bellas Artes, Unidad de Medicina Familiar, Microbiología, UCG, Productos Naturales, Administración Central, Modalidad Abierta, Octógono y Centro de Convenciones.

• Conexión mediante UTP: Edificio Virginia Friofrío, Edificio Osckar Handle, Edificio Arquitectura, Laboratorios I, CERART, Cafetería, Editorial, y CEDIB.

• Conexión mediante enlace inalámbrico: MARISTAS, Germoplasma, Museo y Hospital UTPL.

1

(19)

1.1.3 Equipos de red

De acuerdo al inventario de la red LAN UTPL documentado por el departamento de TI de la UTPL, los equipos que componen la red LAN son switches Cisco con diferentes modelos o series. La red LAN posee cuatro series de switches: Catalyst 2950, Catalyst 2960, Catalyst 3550 y Catalyst 3560.

Analizando los diagramas de red de la UTPL2_{y comparando con la información del} inventario proporcionado, se resumen en las siguientes tablas los equipos que existen actualmente en la red LAN de la UTPL.:

1.1.3.1 Serie Catalyst 2950

Tabla 1.1 Modelos Catalyst 2950.

Modelo Switch # SW

Catalyst2950-12 3

Catalyst2950-24 27

Catalyst2950T-24 23

Catalyst2950SX-24 2

Total 55

1.1.3.2 Serie Catalyst 2960

Tabla 1.2 Modelos Catalyst 2960.

Catalyst2960-24TT 53

Catalyst2960-24TT-L 17

Catalyst2960-24PC-L 11

Total 81

2

(20)

1.1.3.3 Serie Catalyst 3550/3560

Tabla 1.3 Modelos Catalyst3550-3560.

Catalyst3550-12T 4

Catalyst3560G 24TS 5

Total 9

Según la información recopilada de los diagramas de red e inventario, actualmente están funcionando 145 switches, todos estos de marca CISCO; de los cuales 55 SW son de la Serie Catalyst 2950, 81 SW Serie Catalyst 2960, 4 SW Catalyst 3550, y 5 SW Catalyst 3560.

1.2 INVENTARIO DE LA RED LAN UTPL

Dimensionando la situación actual de la red LAN UTPL, existen 145 switches que componen el backbone de la red. Por tal razón es necesario consolidar un inventario con información válida de qué equipos disponen al igual que sus características de software IOS (Sistema Operativo de Interconexión), con el objetivo de determinar posibilidad de agregar QoS al esquema actual de la red.

1.2.1 Modelos y versiones del Sistema Operativo de Interconexión (IOS) en la red LAN

Haciendo uso de la información en las tablas 1.1, 1.2, 1.3, existen cuatro series de switches que conforman la red en los niveles de acceso y distribución. En las siguientes sub-secciones se hace un análisis de los modelos e imágenes de software que operan en los switches, determinando tablas resúmenes del inventario de la red LAN en la UTPL.

1.2.1.1 Modelos de switches

(21)

• Catalyst2950-12

• Catalyst2950-24

• Catalyst2950T-24

• Catalyst2950SX-24

Con la Serie Catalyst2960 existen 3 modelos de switches:

• Catalyst2960-24TT

• Catalyst2960-24TT-L

• Catalyst2960-24PC-L

Con la Serie Catalyst3550 existe 1 modelo de switch:

• Catalyst3550-12T

Con la Serie Catalyst3560 existe 1 modelo de switch:

• Catalyst3560G-24TS

1.2.1.2 Versiones de IOS disponibles en switches

Cisco constantemente adapta su tecnología a los nuevos requerimientos de redes empresariales y de Proveedores de Servicios de Internet (ISP); en este sentido, cada nueva versión del software Cisco IOS optimiza las redes IP y otorga funciones más avanzadas de enrutamiento, seguridad, y QoS. Las versiones del Cisco IOS constan de números y letras que denotan diferentes características de la misma según como se agrupan. Dichos números se pueden categorizar en los siguientes grupos según su ubicación [1]:

• Mayor lanzamiento.- Se trata del primer número con punto decimal, éste indica la versión del IOS.

(22)

• Lanzamiento provisional.- Se distingue mediante un punto y el número correspondiente después del número de “lanzamiento en mantenimiento”, qué indica una revisión especial basada en el “mayor lanzamiento”.

• Lanzamiento de despliegue temprano.- Son una o dos letras adicionales al final del número “lanzamiento provisional”, cuya función es indicar que nuevas funcionalidades y hardware han sido introducidos para su rápida incorporación al software IOS de Cisco.

Cada uno de estos switches cuenta con su determinada imagen de software, y según los diagramas de red, los IOS existentes en los equipos con sus respectivas versiones se detallan a continuación:

Con la Serie Catalyst2950 existen 3 versiones:

• C2950-24-I6K2L2Q4-M, Versión 12.1(11)EA1

Con la Serie Catalyst2960 existen 6 versiones:

• C2960-LANBASEK9-M, Versión 12.2(44)SE2

• C2960-LANBASEK9-M, Versión 12.2(25)SEE3

• C2960-LANBASE-M, Versión 12.2(25)SEE3

• C2960-LANBASE-M, Versión 12.2(35)SE5

Con la Serie Catalyst3550 y Catalyst3560 existen 4 versiones:

• C3550-IPSERVICESK9-M, Version 12.2(25)SEE4

• C3560-IPBASEK9-M, Versión 12.2(35)SE5

• C3560-IPBASEK9-M, Versión 12.2(35)SE6

(23)

En resumen los switches de la red LAN UTPL no son unificados en el aspecto de las versiones del IOS ya que existen 13 versiones diferentes. La imagen de software Cisco tiene una nomenclatura específica para distinguir entre las diferentes versiones de productos que ofrece esta marca.

Por ejemplo, la versión del IOS en un switch Catalyst 2960-24TT es la siguiente:

C2960-LANBASEK9-M, Versión12.2(35)SE5

En la referencia [2] especifica que,

LANBASE: Significa el tipo de software que contiene el IOS de Cisco. K9: Significa que esta versión soporta una seguridad encriptada.

12.2 (35): Significa la versión del IOS junto al número de lanzamiento o

desarrollo.

SE: Significa el identificador de la serie para la que fue producido, en este caso

es para proveedores de servicio(S) y ambientes empresariales (E).

5: Significa la revisión del lanzamiento, en este caso la revisión 5.

La tabla 1.4 ejemplifica cómo diferenciar las diferentes versiones de los equipos de Cisco de acuerdo a la tecnología:

Tabla 1.4 Versiones de CISCO conforme la tecnología, [2]

Tecnología Despliegue Inicial

Ancho de banda por cable 12.2BC

Conmutación LAN 12.1EA

Ancho de banda por cable 12.1EC

Redes inalámbricas 12.2JA

Red inalámbrica móvil 12.2MB

Red inalámbrica móvil 12.2MC

(24)

1.3 ANÁLISIS DEL IOS DE CISCO CON SOPORTE DE QoS

1.3.1 Características de las imágenes de Cisco para QoS

Como los equipos existentes actualmente en la red LAN UTPL son de las series Catalyst 2950, Catalyst 2960, Catalyst 3550 y Catalyst 3560, a continuación se detallará las diferentes imágenes de Cisco para estos equipos y sus características en cuanto a QoS.

1.3.1.1 Imágenes del software de Cisco Catalyst 2950

La serie de Catalyst 2950 según el modelo de switch puede traer dos tipos de imagen de Cisco, Estándar o Mejorada, lo que diferencia a una de otra son las características configurables de calidad de servicio (QoS) que brinda cada una, es decir si en un equipo se tiene imagen Estándar solo se puede hacer configuraciones básicas de QoS (QoS Estándar), en cambio la imagen Mejorada permite que en el equipo se configuren todas las características y atributos que ofrece QoS (QoS Avanzada). A continuación se mencionan las imágenes de Cisco para la serie Catalyst 2950:

• Catalyst 2950 SI Series: Soporta QoS (Estándar)

• Catalyst 2950 EI Series: Soporta QoS (Avanzada)

dónde:

SI: Imagen Estándar, es el tipo de imagen de Cisco de capa 2 existente en los switches 2950-12 y 2950-24 de la red LAN UTPL. Da soporte para características de switching básicas y no puede entender paquetes de capa 3 y capa 4 porque solo observan la cabecera Ethernet y paquetes del switch basados en esa cabecera [3].

EI: Imagen Mejorada, es la imagen de Cisco existente en los switches 2950T-24 y 2950SX-24 en la red LAN UTPL. Cuando este software es instalado en estos equipos involucra las siguientes ventajas: servicios inteligentes como QoS avanzado, limitación de velocidad, filtros de seguridad, y administración de redes multicast [3].

(25)

Tabla 1.5 Características de QoS para versiones de IOS SI / EI

QoS

Imagen Estándar Imagen Mejorada

Soporta 64 VLANs Soporta hasta 256 VLANs con uso de ACLs en las interfaces físicas. Soporta características de QoS en colas

y programación de salida

Añade soporte de clasificación, marcad, y políticas

Existen nuevas características en la Imagen Mejorada del IOS para estos switches. A continuación explicamos que diferencias se resaltan en los dos tipos de software.

La serie Catalyst 2950 con imagen SI tiene las siguientes características [4]:

• Clasificación: Se puede hacer clasificación con CoS (Clase de Servicio) o con DSCP (Servicios Diferenciados por Código de Punto):

o Clasificación en base a CDP (Protocolo de Descubrimiento de Cisco) desde un teléfono IP de Cisco

o Colas y programación de salida o Algoritmo de prioridad estricta.

o Algoritmo WRR (Round-Robin Balanceado).

A diferencia de la serie Catalyst 2950 con imagen EI soporta clasificación de Capa 2 (L2) - Capa 4 (L4) con uso de [4]:

• Confiabilidad en estados de puertos

• QoS con Listas de Control de Acceso (ACLs)

• Mapas de clase y mapas de política

Para el IOS de Cisco a partir del lanzamiento 12.1, “Imagen Mejorada” añade las siguientes características [4]:

• Clasificación: En base de

o Confiabilidad en estados de puertos o Listas de Control de Acceso (ACLs) o Mapas de política

(26)

o Configuración de puertos con CoS. o Marcado

o CoS-a-DSCP o DSCP-a-CoS

o Colas y programación de salida o Algoritmo WRR

o Algoritmo de prioridad estricta.

1.3.1.2 Imágenes del software de Cisco Catalyst 2960

La serie de Catalyst 2960 según el modelo de switch puede traer dos tipos de Imagen de Cisco las cuales son:

• Catalyst 2960 LAN Lite Series: Soporta QoS estándar

• Catalyst 2960 LAN Base Series: Soporta QoS avanzado

La diferencia entre estos dos tipos de imagen de Cisco, se muestra a continuación en la figura 1.2 en la que se detalla las características de QoS con las que cuentan tanto las imágenes LAN Base Series y LAN Lite Series.

Fig. 1.2 Diferencias QoS para los dos tipos de imágenes software Catalyst 29603

3

Comparación de QoS en IOS del Switch Catalyst 2960 Series, online:

(27)

La figura 1.2 de la comparación de LAN Base Series y LAN Lite Series nos permite saber qué tipo de QoS se puede implementar en los switches de la serie Catalyst 2960. En la red LAN UTPL los 72 Switch Catalyst 2960 cuentan con la imagen LAN Base Series, la cual según lo especificado anteriormente soporta QoS avanzado.

1.3.1.3 Imágenes del Cisco switch Catalyst 3550 / 3560

Las imágenes del IOS para los dos switches son de dos tipos: SMI (Imagen Multicapa Estándar) y EMI (Imagen Multicapa Mejorada) [3]. Las funcionalidades y características que ofrece cada software instalado en los equipos son específicas para la aplicación o tecnologías que requiere la red.

SMI: Provee conmutación en capa 2, inteligencia en capa 3 y capa 4, para dar seguridad avanzada pero sólo calidad de servicio de característica estándar; igualmente soporta funcionalidad de conmutación en capa 3. Solo soporta enrutamiento estático y el protocolo de información de enrutamiento (RIP), más no otro enrutamiento dinámico [3].

EMI: Provee full switching en capa 2 y capa 3, con soporte para todos los protocolos de enrutamiento dinámico y provee calidad de servicio avanzada [3].

La serie de estos switches poseen el nuevo “IOS Packaging4_{” que consiste en nuevo} método de ordenamiento y nomenclatura de las imágenes de Cisco. El objetivo principal es reducir la cantidad y variedad de versiones de IOS disponibles en cada equipo o dispositivo a solamente 8 versiones. Los ocho packages se resumen en la figura 1.5:

4

(28)

Fig. 1.3 Cisco IOS Packaging5

Cada uno de estos packages reúnen un conjunto de características que como se observó en la figura 1.3, la versión más básica es la IPBase que contiene las características de routing y switching estándar.

1.4 CONFIGURACIONES BÁSICAS EN LOS SWITCHES CATALYST CON IMPLEMENTACION DE QoS

Además del estudio con respecto al software de los equipos en la red LAN, se necesita conocer si el switch soporta configuraciones de QoS. Una forma de verificar esta opción es mediante comandos en el CLI de los equipos Cisco.

5

(29)

1.4.1 Verificación de la versión del switch

Estableciendo una sesión telnet a la dirección IP del switch destino, podremos conocer su configuración por defecto; cuyos comandos básicos se resumen en dos: “show version”, “show running configure”.

Para mostrar la versión del switch, mediante consola como usuario privilegiado se ejecuta el siguiente comando:

Switch# show version

Y aparecerá en la pantalla la información del Cisco IOS Software para ese switch; con este comando se obtendrá la versión del IOS, el número de lanzamiento, fecha de último arranque del sistema, fecha del último re-establecimiento del sistema, entre otras opciones.

1.4.1.1 Soporte de la imagen IOS cisco para QoS estándar o mejorado

La funcionalidad del comando “show version” es muy importante para nuestro trabajo porque comprobamos si los switches de la red LAN UTPL soportan QoS y qué características de calidad de servicio son posibles configurar en los equipos.

Para los switches Catalyst 2950 son dos parámetros importantes que nos muestra el comando “show version”6; primero, la línea “System image file is” que permite visualizar el directorio donde está almacenado la imagen, y segundo, la línea “Running Enhanced Image” o “Running Standard Image” indicando que tipo de imagen está instalada en el equipo.

En los switches Catalyst 2960, mediante el comando “show version” se puede observar si la imagen que está instalada en el equipo es LAN Lite Series o LAN Base Series, esto se muestra en la información que despliega la ejecución de este comando.

Mientras que, en los switches Catalyst 3550 y Catalyst 3560 se puede saber qué tipo de imagen está instalada en el equipo con la ejecución del comando “show versión”, dos tipos de imagen pueden estar instaladas en esta clase de equipos como son, IPBase que es la imagen SMI o IPServices que es la imagen estándar del software

6

(30)

mejorado de capas múltiples para los switches de múltiples capas o imagen EMI. En las tablas 1.6, 1.7, 1.8 se hace una diferenciación de las imágenes de Cisco, en base al software IOS instalado en cada uno de los switches de la red LAN UTPL.

1.4.1.2 Resultados de la verificación de versión e imagen IOS de Cisco

En la figura 1.4 y 1.5 visualizamos una captura del comando show version en el Switch Catalyst 2950-24 y Catalyst 2950T-24

Fig. 1.4 Resultado comando show version Catalyst 2950-24

(31)

La utilización del comando “show version” se vuelve muy útil al momento de conocer en una primera instancia las característica de QoS que posee el switch; en el caso de la figura 1.4, el switch 2950-24 tiene una imagen estándar (SI) dentro de su IOS, en cambio en la figura 1.5 el switch 2950T-24 usa una imagen mejorada (EI), por lo que, por la estructura de la imagen EI en el swtich 2950T-24 se puede configurar todas las características disponibles de QoS.

1.5 RESUMEN DE CARACTERÍSTICAS QOS EN LOS SWITCHES DE LA RED LAN UTPL

1.5.1 Resumen de los modelos de switches

Con respecto al inventario de la infraestructura de la red LAN, se muestran las tablas resumen de los diferentes modelos de switches existentes en la UTPL en la que se detalla el IOS, versión, modelo de switch, y diferencia de la imagen de Cisco y tipo de QoS que soporta.

Tabla 1.6 Resumen versiones IOS para Catalyst 2950 Series

N° de

switches IOS y versión Modelos de switches

Imagen Cisco QoS

SI EI Estándar Avanzada

1 C2950-24-I6K2L2Q4-M, _{Versión 12.1(11)EA1} Catalyst2950T-24 x x

20 C2950-24-I6K2L2Q4-M, Versión 12.1(22)EA4

Catalyst2950-24 x x

3 Catalyst2950T-24 x x

3

C2950-24-I6K2L2Q4-M, Versión 12.1(22)EA9

Catalyst2950-12 x x

21 Catalyst2950-24 x x

2 Catalyst2950T-24 x x

1 Catalyst2950SX-24 x x

4 Sin información Catalyst2950-24 --- --- --- ---

Tabla 1.7 Resumen de versiones IOS para Catalyst 3550 & Catalyst 3560 Series

N° de

switches IOS y versión

Modelos de switches

Imagen

Cisco QoS

SI EI Estándar Avanzada

4 C3550-IPSERVICESK9-M, _{Version 12.2(25)SEE4} Catalyst3550-12T x x

3 C3560-IPBASEK9-M, Versión _12.2(35)SE5 Catalyst3560G-24TS x x

1 C3560-IPBASEK9-M, Versión _12.2(35)SE6 Catalyst3560G-24TS x x

(32)

Tabla 1.8 Resumen de Versiones IOS para Catalyst 2960 Series

N° de

switches IOS y versión Modelos de switches

Imagen Cisco QoS

LAN

LITE BASE LAN Estándar Avanzada

45 C2960-LANBASEK9-M, _{Versión 12.2(44)SE2} Catalyst2960-24TT x x

5 C2960-LANBASEK9-M, _{Versión 12.2(44)SE6} Catalyst2960-24TT x x

1 C2960-LANBASEK9-M, _{Versión 12.2(25)SEE3} Catalyst2960-24TT x x

10 C2960-LANBASEK9-M, _{Versión 12.2(44)SE2} Catalyst2960-24TT-L x x

2 C2960-LANBASEK9-M, _{Versión 12.2(37)SE} Catalyst2960-24TT-L x x

1 _{Versión 12.2(25)SEE3 Catalyst2960-24TT-L}C2960-LANBASE-M, x x

11 C2960-LANBASEK9-M, _{Versión 12.2(44)SE6} Catalyst2960-24PC-L x x

2 NO INFO Catalyst2960-24TT-L --- ---

2 NO INFO Catalyst2960-24TT --- ---

A continuación en las tablas 1.9, 1.10 y 1.11 se muestra un resumen de los modelos de switches existentes con su respectiva imagen de Cisco:

Tabla 1.9 Resumen de los diferentes modelos de switches Catalyst 2950 y su imagen de Cisco

MODELOS SWITCHES IMAGEN CISCO

SI EI

Catalyst2950-12 3 0

Catalyst2950-24 41 0

Catalyst2950T-24 0 6

Catalyst2950SX-24 0 1

Total 44 7

Tabla 1.10 Resumen de los diferentes modelos de switches Catalyst 2960 y su imagen de Cisco

MODELOS SWITCHES IMAGEN CISCO LAN LITE LAN BASE

Catalyst2960-24TT 0 51

Catalyst2960-24TT-L 0 15

(33)

Tabla 1.11 Resumen de los diferentes modelos Catalyst 3550 & Catalyst 3560 y su imagen de Cisco

MODELOS SWITCHES IMAGEN CISCO SMI EMI

Catalyst3550-12T 0 4

Catalyst3560G-24TS 4 1

La tabla 1.12 muestra el resumen total de los switches descritos por serie, y con la respectiva cantidad de equipos con QoS:

Tabla 1.12 Resumen de los switches por series y tipo de QoS que soportan

SERIE SWITCH _{Estándar Avanzada}QoS

Catalyst2950-Series 44 7 Catalyst2960-Series 0 77 Catalyst3550-Series 0 4 Catalyst3560-Series 4 1

Total 48 89

(34)

REFERENCIAS

[1] Versiones del Cisco IOS, [On-line] Disponible en : http://es.scribd.com/doc/75391581/9/Versiones-del-Cisco-IOS

[2] Guide to Cisco IOS Release Naming, Cisco Web Page, [On-line], http://www.cisco.com/en/US/products/sw/iosswrel/ps1818/products_tech_note0 9186a0080101cda.shtml

[3] CCNP(R) Practical Studies: Switching. Google Books. [On-line]: http://books.google.com.ec/books?id=TFdo0H8OKVMC&printsec=frontcover&hl =es&source=gbs_atb#v=onepage&q&f=false

[4] Catalyst 2950 Series Switches Quality of Service (QoS) FAQ, [On-line]

disponible en:

(35)

CAPÍTULO II

2. ESTUDIO SOBRE LOS MÉTODOS DE PRIORIZACIÓN DE TRÁFICO

Este capítulo está dedicado al estudio e investigación de los diversos métodos y mecanismos de priorización de tráfico empleados por las tecnologías de equipos de red para la implementación de calidad de servicio en una red LAN, la finalidad de este capítulo es iniciar y profundizar el conocimiento sobre las temáticas que trae consigo la calidad de servicio (QoS).

2.1 MODELOS Y MECANISMOS DE PRIORIZACIÓN DE TRÁFICO

2.1.1 Marco Teórico

En la actualidad las redes LAN tienen requerimientos de tráfico en tiempo real, tal es el ejemplo de aplicaciones de voz y video donde se hace indispensable contar con la disponibilidad de recursos necesarios para que los datos transmitidos tengan un retardo mínimo hasta llegar hacia el destino, así como bajos porcentajes de pérdida de paquetes que no representen daños significativos en una comunicación multimedia. Y es por esta razón que en la actualidad empresas ya ven la necesidad de priorizar el tráfico con el fin de otorgar preferencias a cierto tipo de datos.

2.1.2 Calidad de servicio (QoS)

(36)

Tabla 2.1 Parámetros de QoS, [2] [3]

De la tabla 2.1, los parámetros que definen QoS varían según la aplicación, y la identificación de los mismos es lo que permitirá en primera instancia clasificar o determinar la prioridad de algunas aplicaciones sobre otras.

A continuación se muestran las fórmulas de cálculo para los parámetros que intervienen en la medición de QoS en una red LAN; estas fórmulas no toman en cuenta modelos de QoS:

• Retardo, parámetro que se determina como el tiempo que usan los paquetes en la transmisión [4]. Su fórmula describe la relación de la longitud del paquete o del flujo de paquetes y la tasa de transmisión que posee para la comunicación.

(2.1)

dónde,

Dprom = Retardo promedio (ms) L = Longitud del paquete (bits)

C = Tasa de transmisión del paquete (bps)

Esta fórmula se aplica en forma general para el cálculo del retardo por transmisión en una red.

(37)

∑ | |

(2.2)

dónde,

Jprom = Jitter promedio (ms) Di = Retardo promedio (ms) n = Número de retardos

• Pérdida de paquetes (Packet Loss Rate), determina una tasa de paquetes que no han sido transmitidos exitosamente, es decir una proporción de los paquetes recibidos sobre los paquetes enviados en la comunicación [6].

∗ 100 (2.3)

dónde,

Tp = Tasa de pérdida de paquetes (%)

Ps = Paquetes enviados

Pr = Paquetes recibidos

Relacionado a QoS, la tasa de pérdida de paquetes es el caso dónde las colas se encuentran llenas en el momento que el paquete llega para ser enviado por el canal, por lo tanto es eliminado [6].

• Ancho de banda, parámetro que indica la cantidad reservada del caudal máximo del canal o enlace [7]; es decir la tasa a la cual se transmiten los datos hacia el receptor.

∗ (2.4) dónde,

AB= Ancho de banda (Mbps)

(38)

ttx = Tiempo total de transmisión (s)

Tfr = Tamaño de trama (bits)

Este parámetro se considera un rendimiento (throughput) por el hecho que es el ancho de banda que necesita el flujo de paquetes (provenientes de alguna aplicación) para poder transmitir sus paquetes hacia el receptor.

Según la tabla 2.2 las aplicaciones interactivas requieren de una tasa de pérdida media, retardo y ancho de banda bajos pero de un jitter medio puesto que no requiere de variaciones de latencia bajos para transmitir correctamente, en cambio videoconferencia requiere de una tasa de pérdida, retardo y jitter bajos pero su demanda de ancho de banda es alto porque son aplicaciones de tiempo real; comparando los parámetros de las dos aplicaciones, la videoconferencia usa más recursos por lo que se la puede categorizar como una aplicación con mayor prioridad.

A continuación en la tabla 2.2 se muestra una lista de diferentes aplicaciones junto con sus respectivos parámetros de QoS:

Tabla 2.2 Requerimientos de QoS según la aplicación, [2] [3]

1 _{Aplicación con pérdida nula bajo protocolo de transporte TCP.}

(39)

Fig. 2.1 Arquitectura QoS, [1]

Identificación y marcado de paquetes: Este campo hace referencia a la priorización de paquetes dependiendo de su origen asegurando con este mecanismo la exitosa recepción de cada paquete [1]. La identificación de flujos requiere de técnicas QoS de clasificación y marcado para coordinar los elementos de extremo a extremo dentro de la red.

Elemento de red: Mediante este componente de QoS se distingue cada elemento de la red, a través de colas, planificación (scheduling) y herramientas de modelamiento de tráfico (Traffic Shaping) [8].

Políticas, administración, conteo: En este campo se describe la política, funciones de administración para controlar el tráfico que fluye en la red. [8]

Cuando se desea implementar QoS en una red, se provee de mejores y más predecibles características a los servicios en la misma: [9]

• Soporte de ancho de banda dedicado.

• Mejora en las características de pérdida de paquetes.

• Control y evasión de la congestión en la red.

• Organización del tráfico.

(40)

En redes de voz, video, y datos, la calidad de servicio tiene variedad de significados de los cuales se identifican tres aspectos distintos de la calidad de servicio utilizados como técnicas en la priorización de tráfico [10]:

• Clase de servicio (CoS)

• Tipo de servicio (ToS)

• Grado de servicio (GoS)

2.1.2.1 Clase de Servicio (CoS)

Clase de servicio es un esquema de prioridad que usa el protocolo IEEE 802.1p7_para proporcionar niveles de clasificación de tráfico, a través de asignación de etiquetas a los paquetes que poseen información sobre ésta marca [10].

El valor de clase de servicio se agrega en la cabecera de capa MAC como un campo de tres bits para priorización del tráfico [11]; el campo 802.1p o comúnmente llamado CoS permite a los paquetes ser agrupados en distintos tráficos definidos por la prioridad.

Tabla 2.3 Valores de prioridad CoS, [10]

Valor CoS Valores de las colas de reenvío

0 Q2 (prioridad baja)

1 Q1 (prioridad más baja)

2 Q1 (prioridad más baja)

3 Q2 (prioridad baja)

4 Q3 (prioridad alta)

5 Q3 (prioridad alta)

6 Q4 (prioridad más alta)

7 Q4 (prioridad más alta)

7

(41)

Como se observa en la tabla 2.3, CoS establece 8 niveles de priorización con su respectiva cola. La prioridad más alta es de siete, lo que podría denominar al tráfico de la red como crítico, tales como actualizaciones de la tabla cuando usen Protocolo de Información de Enrutamiento (RIP) y Open Shortest Path First (OSPF) [11]. Los valores de cinco y seis podrían ser de aplicaciones sensibles al retardo, como el vídeo interactivo y de voz; los cuatro siguientes valores para clases de datos a través de una gama de aplicaciones de carga controlada, tales como el tráfico de streaming multimedia [11]; el valor cero se utiliza como valor predeterminado de mejor esfuerzo, cuando no se ha configurado ningún valor de CoS.

La priorización de tráfico a través de CoS únicamente será una clasificación en capa 2 y reenviado directamente al usuario, pues no se establece reserva de ancho de banda [11]

2.1.2.2 Tipo de servicio (ToS)

Es un campo del datagrama de un paquete IP que indica el tipo de servicio que posee el paquete. El tipo de servicio proporciona una calidad de servicio deseada, a través de parámetros que determinan la prioridad de un servicio como la precedencia, máximo throughput, mínimo retardo, máxima fiabilidad, y mínimo coste [10]. La precedencia tiene 8 niveles ordenados como lo muestra la figura 2.2.

(42)

2.1.2.3 Grado de servicio (GoS)

La calidad de servicio (QoS) está relacionada con las propiedades estadísticas de un flujo de datos, y particularmente el grado de servicio que describe la probabilidad de que los paquetes de un usuario sean admitidos en primer lugar [10]. GoS es una característica de calidad de servicio muy utilizada en redes de VoIP.

2.1.3 Modelos de priorización QoS

Conforme a técnicas y mecanismos para manejar diferentes tráficos y considerando los cuatro parámetros que deben permitir una calidad de servicio en la red, se establecen algunos modelos que permiten priorizar un tráfico. A continuación se hace una descripción de los tres modelos existentes para implementar QoS en una red, los cuales son: mejor esfuerzo (Best Effort), servicios integrados (IntServ), y servicios diferenciados (DiffServ).

2.1.3.1 Modelo de servicio “Mejor esfuerzo”

Se llama modelo de mejor esfuerzo al servicio que provee la red cuando hace todo lo posible para intentar entregar el paquete a su destino, a pesar que no hay garantía de su recepción [13]. Una aplicación enviará datos en cualquier cantidad, cuando lo necesite, sin pedir permiso o notificar a la red. Éste es el modelo utilizado por las aplicaciones de FTP y HTTP [13].

Pero el servicio de mejor esfuerzo no es un modelo apropiado para aplicaciones sensibles al retardo o variaciones de ancho de banda, las cuales necesitan de un tratamiento especial; tal es el caso de aplicaciones de VoIP y videoconferencias.

2.1.3.2 Modelo de servicios integrados (IntServ)

(43)

ancho de banda requerido por ésta sobrepase el límite asignado para dicha aplicación [13].

La idea básica del modelo es hacer reservas de recursos por flujos [13] y su objetivo es preservar el modelo de datagramas de IP, pero al mismo tiempo soportar aplicaciones en tiempos reales. El modelo IntServ exige la clasificación de las aplicaciones de acuerdo a su flexibilidad ante pérdidas [10], cuya información se ve reflejada en la tabla 2.4.

Tabla 2.4 Aplicaciones vs flexibilidad de pérdidas, [10]

Flexible a pérdidas No flexible a pérdidas

Elásticas Datos UDP: DNS, SNMP, NTP, _{entre otros} Datos sobre TCP: FTP, Web, _{e-mail, entre otros.}

Tiempo

real Flujos multimedia, streaming, videoconferencia, VoIP

Emulación de circuitos (simulación de líneas dedicadas)

Para la implementación del modelo se deben habilitar otros servicios puesto que requiere de altos recursos para que el flujo esté siempre activo [14]. La arquitectura del modelo define 3 tipos de servicios, tal como se muestra en la figura 2.3:

Fig. 2.3 Reparto de recursos en IntServ8

8

(44)

• Servicio Garantizado: Mantiene un throughput mínimo y retardo máximo pero supone que cada router del trayecto debe dar garantías al tráfico; limitada por el medio físico.

• Servicio Carga Controlada: Calidad a una red con poca carga, mantiene un retardo bajo pero sin ofrecer garantías en la red.

• Servicio Mejor Esfuerzo: No presta garantías al flujo que circula por la red (sin QoS).

La metodología que usa la aplicación para reservar los recursos sucede antes de iniciar el flujo de paquetes [13] y el proceso se resume en los siguientes pasos:

a) La fuente inicia el establecimiento de una reserva describiendo primero a la red las características del flujo y los requerimientos de los recursos.

b) La red puede aceptar este nuevo flujo de la aplicación sólo si hay suficientes recursos para comprometerse con los recursos solicitados.

c) Ya establecida la reserva, la aplicación sus paquetes a lo largo del canal reservado y la red obtendrá un flujo continuo de tráfico.

El modelo de servicio integrado, comúnmente conocido como servicio “garantizado”, se fundamenta en dos componentes claves: plano de control y plano de datos. [15]

• El plano de control establece la reserva de recursos,

• El plano de datos envía los paquetes de datos basado en el estado de la reserva.

(45)

Fig. 2.4 Modelo de referencia de servicios integrados, [15]

Como se indicó anteriormente, el plano de control debe establecer la reserva de recursos y este proceso empieza con la especificación del flujo que debe realizar una aplicación para dar a conocer a la red su flujo de tráfico y los requerimientos de QoS [15]; así, la solicitud de establecimiento de recursos es enviada a la red. Cuando el router de la red recibe la solicitud, realiza dos tareas: utiliza un protocolo para enrutar la solicitud de reserva para el siguiente salto, y posteriormente coordinar con el control de admisión para decidir si hay suficientes recursos en la red para comprometerse con los recursos solicitados [15].

El modelo IntServ se basa en el Protocolo de Reservación de Recursos (RSVP) para señalizar y reservar la QoS deseada para cada flujo en la red [13]. El protocolo transporta información sobre las características del tráfico y requerimientos de los recursos [15]; RSVP debe salto por salto intentar hacer la reserva solicitada debido a que la información de estados para cada reserva necesita ser mantenida por cada enrutador a lo largo de la ruta [13]; se convierte en una desventaja de escalabilidad para miles de flujos a través de una red central.

(46)

algoritmo WFQ para gestionar el flujo de paquetes, el mismo que es analizado más adelante.

2.1.3.3 Modelo de servicios diferenciados (DiffServ)

Este modelo incluye un conjunto de herramientas de clasificación y mecanismos de encolamiento de paquetes, que proveen a ciertas aplicaciones o protocolos con determinadas prioridades sobre el resto del tráfico en la red [13]. El tráfico de red puede ser clasificado por dirección de red, protocolo, puertos, interfaz de ingreso o cualquier tipo de clasificación que pueda ser alcanzada mediante el uso de listas de acceso, en su variante para la implementación de QoS [13].

El protocolo IPv4 posee el campo ToS para gestionar el marcado de paquetes con el nivel de servicio requerido [13]. Esta definición no se utilizó mayormente debido a la ambigüedad de su significado, por lo que más tarde se convirtió en el denominado campo DSCP (Servicios Diferenciados por Código de Punto). Este campo sí tuvo una aceptación global y se asumió una interpretación estándar que permite a las redes planificar metodologías basándose en ésta [13]. Antes de que apareciera el modelo DiffServ hubo una compatibilidad entre DSCP y el valor de ToS para el proceso de marcado del tráfico por lo que este código se denominó Selector de Clase (CS); conformándose posteriormente un servicio más de DiffServ.

Una vez que existe la capacidad de marcar los paquetes utilizando DSCP, es necesario proveer del tratamiento apropiado para cada una de estas clases [13]. La colección de paquetes con el mismo valor DSCP circulando hacia una dirección determinada, es llamada Comportamiento Agregado (BA). Es así como múltiples aplicaciones/fuentes pueden pertenecer al mismo BA [13].

(47)

Un PHB es seleccionado en un nodo por medio del mapeado del código DiffServ (DS) en un paquete recibido. Los PHB’s estándares tienen un código recomendado. Los PHB’s estándares se especifican por las características de QoS que brinda el modelo DiffServ, donde específicamente son cuatro PHBs [12]:

PHB Default: El valor DSCP es cero (000000) y el servicio esperado es exactamente el servicio por defecto de la Internet de hoy.

• PHB CS: Son siete valores DSCP que funcionan desde el 001000 al 111000 y son específicos para seleccionar hasta siete comportamientos, cada uno de los cuales tiene una mayor probabilidad de un envío de tiempo que su predecesor (CS7-CS1).

• PHB EF: El reenvío prioritario (EF) PHB tiene un valor recomendado DSCP de 101110 porque la tasa de inicio del tráfico EF debe igualar o superar una tasa configurable; éste PHB permite la creación de servicios en tiempo real con una tasa de throughput configurable [12]. El objetivo de este PHB es que el flujo agregado vea siempre o casi siempre, la cola vacía. El EF PHB puede ser usado para construir un servicio punta a punta de bajas pérdidas, baja latencia, bajo jitter (colas muy pequeñas) y/o ancho de banda asegurado.

• PHB AF: El reenvío seguro (AF) PHB [13] es el más utilizado en la arquitectura DiffServ. Dentro de esta PHB los 4 grupos AF (llamados clase AF1, AF2, AF3 y AF4 o clases Cisco) son divididos en 3 grupos “olímpicos”: oro, plata y bronce, representando la tendencia a descartar paquetes. Cada paquete será entregado a una clase de servicio mientras se apegue a un perfil de tráfico. Cualquier exceso de tráfico será aceptado por la red, pero tendrá mayor probabilidad de ser descartado según la clase de servicio y grupo.

Se definen N clases AF tal que a cada clase AF se le reservan ciertos recursos (buffer y ancho de banda) en cada uno de los nodos DiffServ (DS), de forma que los retardos y/o pérdidas de una clase sean siempre inferiores a los de una clase de menor prioridad [12].

(48)

dentro de la clase. Actualmente N=4 y M=3 son definidos para uso general [12]. Un paquete que pertenezca a una clase AFi y tenga una preferencia de descarte j es marcado con el código AFij. Los códigos recomendados por la IETF en su recomendación RFC 2597 se indican en la figura 2.5.

Fig. 2.5 Códigos del PHB AF - RFC 25979

El modelo arquitectónico de DiffServ se constituye por lo general en el funcionamiento de una nube compuesta de muchas redes IP, donde se considera la nube como una región uniforme que es posible agregar diferentes tipos de tráfico con un distinto trato de envío [12]; por tal razón el modelo permite que el tráfico entrante sea clasificado y condicionado en los bordes de la red para ser asignado a diferentes BA’s. La figura 2.6 ejemplifica la arquitectura para el que está diseñado el modelo DiffServ.

(49)

Fig. 2.6 Arquitectura modelo DiffServ, [16]

De acuerdo a la figura 2.6, se encuentra un concepto denominado dominio DiffServ (DS) que es un conjunto de nodos que operan con una política de provisionamiento de servicios común y con un grupo de PHB’s implementados en cada nodo [12]. Está formado por nodos DiffServ de frontera que clasifican y condicionan el tráfico entrante para asegurarse que los paquetes que transitan el dominio estén apropiadamente marcados para seleccionar un PHB de los grupos PHB que son soportados dentro del dominio [12]. Los nodos seleccionan el comportamiento de envío basándose en su código DS, y lo hacen asociando éste valor a unos de los PHB soportados.

A continuación, citamos algunas características del modelo que hace referencia a su arquitectura de priorización y suministro de tráfico [17].

• Sólo los nodos frontera clasifican el tráfico y marcan paquetes,

• Los nodos interiores usan las clases codificadas en la cabecera del paquete para determinar el tratamiento de los paquetes.

(50)

Tabla 2.5 Componentes de un nodo frontera. [16]

Están definidos dos tipos de clasificadores: el clasificador BA clasifica paquetes basado en el código DS solamente; para que esto funcione se requiere que los paquetes sean marcados antes de ingresar al clasificador [17].

El clasificador MF (Multi-Campo) selecciona paquetes basado en el valor de una combinación de uno o más campos de cabecera, como IP origen, IP destino, campo DS, protocolo ID, puertos origen y destino, entre otra información [12]. El clasificador debe autentificar la información que usa para clasificar el paquete y el marcado de paquetes con base en los tipos de aplicaciones, con base en direcciones particulares de origen, destino o prefijos de red. [17]

(51)

Fig. 2.7 Reparto de recursos en el modelo DiffServ10,

a) Servicio Reenvío Prioritario (EF): Este tipo de DiffServ minimiza el retardo y la variación del retardo y provee el más alto nivel de QoS posible. Especifica el tráfico de mayor prioridad, equivale a una línea dedicada.

b) Servicio Reenvío Seguro (AF): Los paquetes se marcan con alta prioridad aunque en este caso no se garantiza un ancho de banda. Se definen cuatro clases posibles pudiéndose asignar a cada clase una cantidad de recursos en los routers como ancho de banda, espacio en buffers, entre otros.

c) Servicio Mejor Esfuerzo: Este servicio se caracteriza por tener a cero los tres primeros bits del DSCP. En este caso los dos bits restantes pueden utilizarse para marcar una prioridad dentro del grupo best effort. Este servicio no ofrece ningún tipo de garantía.

En resumen, la tabla 2.6 especifica las técnicas de QoS para cada clase de servicio o aplicación que gestiona el DiffServ.

10

(52)

Tabla 2.6 Resumen de las técnicas de QoS para cada clase de servicio, [16]

La figura 2.8 es un ejemplo claro de cómo actuaría el modelo DiffServ en un entorno real de red, ya que muestra el tipo de clasificador que usa para una aplicación que requiere establecer entre una empresa X y una empresa Y. Lo importante es analizar los mecanismos de acondicionamiento que usa cada clasificador

Fig. 2.8 Funcionamiento de DiffServ en Internet11

2.1.4 Mecanismos para administrar calidad de servicio

Existen varios mecanismos para administrar QoS que se aplican en los Modelos de Servicio mencionados anteriormente, en este tema entran dos campos muy importantes como son: manejo de congestión, en donde se hace referencia a los mecanismos de administración de cola; y manejo de tráfico, aquí se describen los métodos que se emplean para evitar o prevenir la congestión.

(53)

2.1.4.1 Manejo de congestión de colas

El encolamiento de paquetes es natural en una interfaz congestionada, es por esto que existen diferentes algoritmos de encolamiento que nos permiten controlar la congestión, priorizando un tipo de tráfico sobre otro. La principal causa de la congestión en las interfaces es la diferencia de velocidad que existe entre ellas, en la figura 2.9 se hace referencia a lo dicho anteriormente.

Fig. 2.9 Causas de congestión en interfaces, [18]

Dependiendo del tipo de aplicaciones que se estén manejando, se debe determinar qué algoritmo de encolamiento será el más conveniente. Las implementaciones propietarias de Cisco están basadas o son una mezcla de los siguientes algoritmos generales de manejo de colas [18].

2.1.4.1.1 Primero en ingresar, primero en salir (FIFO)

Es el mecanismo más simple de encolamiento y se basa en el concepto, que el primer paquete en entrar a la interfaz es el primero en salir. Es adecuado para interfaces de alta velocidad, sin embargo, no para bajas, ya que FIFO es capaz de manejar cantidades limitadas de ráfagas de datos. Si llegan más paquetes cuando la cola está llena, estos son descartados porque no tiene mecanismos de diferenciación de paquetes [13].