ONT Optimizing Converged NetworksJaime de Roque

Optimizing Converged Networks

CCNP ONT

2

Índice Tema 1. Requisitos para la Conectividad de Red Convergente .................................................... 9

1.1 La evolución de la telefonía empresarial .................................................................... 9

1.1.1 El sistema telefónico Básico ....................................................................................... 9

1.1.2 Compañías de servicios telefónicos tradicionales ....................................................... 9

1.1.3 Tecnologías telefónicas digitales ................................................................................ 9

1.1.4 Servicios telefónicos digitales .................................................................................. 10

1.1.5 Servicios PBX y Centrex ........................................................................................... 10

1.1.6 Servicios de Larga Distancia ..................................................................................... 10

1.1.7 El concepto de Convergencia ................................................................................... 11

1.2 Descripción de los Requisitos de las Redes Convergentes ......................................... 11

1.2.1 Modelo de Red Jerárquico ........................................................................................ 11

1.2.2 Arquitectura Empresarial de Cisco ........................................................................... 11

1.2.3 Condiciones de tráfico en una Red Convergente ...................................................... 12

1.2.4 IIN (Red de Información Inteligente) ........................................................................ 12

1.2.5 Marco Cisco SONA .................................................................................................... 13

Tema 2. Implementaciones VoIP de Cisco ................................................................................ 14

2.1 Introducción a las redes VoIP ......................................................................................... 14

2.1.1 Beneficios de las redes VoIP .................................................................................... 14

2.1.2 Componentes de una red VoIP ................................................................................. 14

2.1.3 Interfaces analógicas heredadas en redes VoIP ........................................................ 15

2.1.4 Interfaces digitales .................................................................................................. 15

2.1.5 Fases para completar una llamada telefónica VoIP ................................................... 15

2.1.6 Control de Llamada Distribuido ................................................................................ 16

2.1.7 Control de Llamada Centralizado ............................................................................. 17

2.2 Digitalización y Empaquetado de la Voz ......................................................................... 17

2.2.1 Codificación básica de la voz: Convertir señales analógicas a señales digitales ........ 17

2.2.2 Codificación básica de la voz: Convertir señales digitales a señales analógicas ........ 18

2.2.3 Muestreo (Sampling) ............................................................................................... 18

2.2.4 Cuantización ............................................................................................................ 18

2.2.5 Codificación de la Voz Digital ................................................................................... 19

2.2.6 Companding (Compressing and Expanding) ............................................................. 19

2.2.7 Características de Códecs de voz comunes .............................................................. 19

2.2.8 Selección de un Códec usando un indicador de opiniones ....................................... 19

2.2.9 Vista del DSP con más detalle .................................................................................. 20

2.3 Encapsular paquetes de voz para el transporte .............................................................. 20

2.3.1 Transporte de voz en redes conmutadas por circuitos ............................................. 20

2.3.2 Transporte de voz en redes IP ................................................................................. 20

CCNP ONT

32.3.3 Protocolos usados en la encapsulación de voz......................................................... 21

2.3.4 Códecs de encapsulación de voz ............................................................................. 21

2.3.5 Reducción de la carga con cRTP ............................................................................... 22

2.3.6 Cuando usar compresión de cabeceras RTP ............................................................. 22

2.4 Cálculo de los requisitos de ancho de banda para VoIP .................................................. 22

2.4.1 Impacto del tamaño de las muestras y del tamaño del paquete en el ancho de banda ....................................................................................................................................... 22

2.4.2 Período empaquetado ............................................................................................. 23

2.4.3 Carga de Enlace de datos ........................................................................................ 24

2.4.4 Carga de Seguridad y de Tunneling .......................................................................... 24

2.4.5 Cabeceras Extra de Protocolos de Seguridad y Tunneling ......................................... 24

2.4.6 Cálculo del ancho de banda total para una llamada VoIP ......................................... 24

2.4.7 Cálculo de ancho de banda rápido ........................................................................... 25

2.4.8 Efectos de VAD en el ancho de banda ...................................................................... 26

2.5 Implementación de VoIP en una red empresarial ........................................................... 26

2.5.1 Implementaciones empresariales de Voz ................................................................. 26

2.5.2 Despliegue de CAC ................................................................................................... 27

2.5.3 Funciones del Gateway de Voz en un router Cisco ................................................... 27

2.5.4 Funciones de Cisco Unified CallManager .................................................................. 27

2.5.5 Modelos de despliegue de telefonía IP empresariales .............................................. 28

2.5.6 Configuración Cisco IOS para VoIP ............................................................................ 29

Tema 3. Introducción a QoS IP ................................................................................................. 31

3.1 Introducción a QoS ......................................................................................................... 31

3.1.1 Tareas de calidad en redes convergentes ................................................................. 31

3.1.2 Tareas de calidad en redes convergentes ................................................................. 31

3.1.3 Medida del ancho de banda disponible ................................................................... 31

3.1.4 Incremento del ancho de banda disponible ............................................................. 32

3.1.5 Efectos del retardo de extremo a extremo y del Jitter .............................................. 32

3.1.6 Reducción del Impacto del retardo en la calidad ...................................................... 33

3.1.7 Pérdida de Paquetes ................................................................................................ 33

3.1.8 Gestión de la congestión. Formas de prevenir el borrado de paquetes ..................... 33

3.2 Implementando QoS Cisco IOS ........................................................................................ 34

3.2.1 ¿Qué es QoS? ........................................................................................................... 34

3.2.2 Herramientas de gestión de congestión ................................................................... 35

3.2.3 Gestión de Colas (Herramientas de prevención de congestión) ................................ 35

3.2.4 Preparación para implementar QoS .......................................................................... 36

3.2.5 Paso 1: Identificar tipos de tráfico y sus requisitos .................................................. 36

3.2.6 Paso 2: Definir clases de tráfico ............................................................................... 36

CCNP ONT

43.2.7 Paso 3: Definir una política QoS ............................................................................... 37

3.3 Selección de un modelo de Política QoS apropiado ......................................................... 37

3.3.1 Los 3 modelos QoS .................................................................................................. 37

3.3.2 Modelo Best-Effort ................................................................................................... 37

3.3.3 Modelo IntServ ........................................................................................................ 37

3.3.4 RSVP y el modelo QoS IntServ .................................................................................. 39

3.3.5 Operación de RSVP .................................................................................................. 39

3.3.6 El modelo DiffServ ................................................................................................... 40

3.4 Uso de MQC (CLI Modular QoS) para implementar QoS ................................................... 41

3.4.1 Métodos de implementación de Políticas QoS .......................................................... 41

3.4.2 Configuración QoS con la CLI .................................................................................... 41

3.4.3 QoS CLI Modular ...................................................................................................... 42

3.4.4 Paso 1 QoS CLI Modular: Configurar los Class Maps .................................................. 42

3.4.5 Paso 2: Configurar Policy Maps ................................................................................ 43

3.4.6 Paso 3: Asociar la política a las interfaces ................................................................ 44

3.4.7 Class Maps Anidados ............................................................................................... 44

3.4.8 Ejemplo MQC ........................................................................................................... 45

3.4.9 Comandos de verificación básica de MQC ................................................................ 45

3.5 Implementar QoS con SDM QoS Wizard ........................................................................... 45

3.5.1 Configurar QoS con Cisco SDM QoS Wizard ............................................................... 45

3.5.2 Creación de la Política QoS ...................................................................................... 45

3.5.3 Monitoreo del Estado de QoS ................................................................................... 46

Tema 4. Implementando el modelo QoS DiffServ ...................................................................... 47

4.1 Introducción a la clasificación y marcado ....................................................................... 47

4.1.1 Clasificación ............................................................................................................ 47

4.1.2 Marcado .................................................................................................................. 47

4.1.3 Clasificación y marcado en la capa de enlace de datos ............................................ 47

4.1.4 Modelo DiffServ ....................................................................................................... 48

4.1.5 Procedencia IP y compatibilidad DSCP ...................................................................... 49

4.1.6 Comportamientos por Salto ..................................................................................... 49

4.1.7 Grupos PHB Estándar ............................................................................................... 50

4.1.8 Mapeo del CoS al QoS de la capa de Red ................................................................. 51

4.1.9 Clase de servicio QoS definida ................................................................................. 51

4.1.10 Implementar una política QoS usando una clase de servicio QoS ............................ 51

4.1.11 Límites de Confianza .............................................................................................. 52

4.2 Uso de NBAR para la clasificación ................................................................................... 53

4.2.1 Reconocimiento de aplicación basado en red (NBAR) ............................................... 53

4.2.2 Soporte de aplicación NBAR ..................................................................................... 54

CCNP ONT

54.2.3 PDLM ....................................................................................................................... 54

4.2.4 Descubrimiento de Protocolos ................................................................................. 54

4.2.5 Configurar y monitorear el descubrimiento de protocolos NBAR ............................... 54

4.2.6 Configuración de NBAR para protocolos estáticos ..................................................... 55

4.2.7 Configuración de NBAR stateful para protocolos dinámicos ...................................... 55

4.3 Introducción a implementaciones de Colas..................................................................... 56

4.3.1 Congestión y colas................................................................................................... 56

4.3.2 Gestión de Congestión: algoritmos de colas ............................................................. 57

4.3.3 FIFO ......................................................................................................................... 58

4.3.4 Prioridad de colas (PQ) ............................................................................................ 58

4.3.5 Round Robin ............................................................................................................ 58

4.3.6 Componentes de colas de router ............................................................................. 59

4.4 Configuración WFQ ......................................................................................................... 59

4.4.1 Weighted Fair Queuing ............................................................................................. 59

4.4.2 Arquitectura WFQ y beneficios ................................................................................. 60

4.4.3 Clasificación WFQ ..................................................................................................... 60

4.4.4 Inserción WFQ y política de borrado ......................................................................... 61

4.4.5 Ventajas y desventajas de WFQ ................................................................................ 61

4.4.6 Configuración de WFQ .............................................................................................. 61

4.4.7 Monitoreo de WFQ ................................................................................................... 61

4.5 Configurando CBWFQ y LLQ ............................................................................................. 62

4.5.1 Combinación de métodos de colas .......................................................................... 62

4.5.2 CBWFQ (Class-Based Weighted Fair Queuing) ............................................................ 62

4.5.3 Arquitectura CBWFQ, Clasificación y Programación ................................................... 63

4.5.4 Configuración y Monitoreo de CBWFQ ....................................................................... 64

4.5.5 LLQ (Cola de Baja Latencia) ...................................................................................... 64

4.5.6 Arquitectura LLQ y Beneficios ................................................................................... 65

4.5.7 Configuración y Monitoreo de LLQ ............................................................................ 65

4.6 Prevención de Congestión .............................................................................................. 66

4.6.1 Gestión de la congestión en Interfaces con Tail Drop ............................................... 66

4.6.2 Limitaciones de Tail-Drop ......................................................................................... 67

4.6.3 Uso de RED (Rando Early Detection) ........................................................................ 67

4.6.4 WRED (Weighted Random Early Detection) ............................................................... 68

4.6.5 Perfiles de borrado WRED ........................................................................................ 69

4.6.6 Configuración de CBWRED ........................................................................................ 69

4.6.7 Perfiles WRED: WRED basado en DSCP (AF) ............................................................... 70

4.6.8 Monitoreo de CBWRED ............................................................................................. 71

4.7 Introducción a las Políticas de Tráfico y Modelado (Shaping) .......................................... 71

CCNP ONT

64.7.1 Vistazo a las Políticas de Tráfico y Modelado (Shaping) ........................................... 71

4.7.2 ¿Por qué usar condicionantes de tráfico? ................................................................. 72

4.7.3 Policing vs. Shaping ................................................................................................. 73

4.7.4 Medida de cantidad de tráfico con Tokens ............................................................... 73

4.7.5 Política basada en clases de cubo de tokens simple ................................................ 73

4.7.6 Mecanismos Cisco IOS de Policing y Shaping ............................................................ 74

4.7.7 Aplicar políticas de tráfico ....................................................................................... 74

4.8 Comprensión de los Mecanismos de eficiencia de los enlaces WAN ................................ 74

4.8.1 Mecanismos de eficiencia de enlaces ...................................................................... 74

4.8.2 Vistazo a la compresión ........................................................................................... 75

4.8.3 Compresión del payload de Capa 2 .......................................................................... 76

4.8.4 Compresión de cabecera .......................................................................................... 76

4.8.5 Exclusión de paquetes grandes de voz en enlaces WAN lentos ................................ 77

4.8.6 Fragmentación de enlace e Intercalado .................................................................... 77

4.8.7 Aplicando mecanismos de Eficiencia de Enlaces ...................................................... 78

4.9 Implementar Ple-clasificación QoS .................................................................................. 78

4.9.1 Redes Privadas Virtuales (VPN) ................................................................................ 78

4.9.2 Implementar QoS con Pre-clasificación ..................................................................... 78

4.9.3 Aplicaciones de Pre-clasificación QoS ....................................................................... 78

4.9.4 Opciones de despliegue de pre-clasificación QoS ..................................................... 79

4.10 Despliegue QoS extremo a extremo .............................................................................. 80

4.10.1 SLAs QoS (Acuerdos de Nivel de Servicio QoS) ........................................................ 80

4.10.2 Requisitos SLA típicos de Voz ................................................................................. 81

4.10.3 Despliegue QoS extremo a extremo ........................................................................ 81

4.10.4 Implementaciones QoS en el Campus Empresarial .................................................. 82

4.10.5 Implementaciones QoS en el borde WAN ................................................................ 83

4.10.6 Diseño del Borde WAN ........................................................................................... 84

4.10.7 Control Plane Policing (CoPP) ................................................................................. 85

5. Implementar AutoQoS Cisco ................................................................................................. 87

5.1 Introducción a AutoQoS .................................................................................................. 87

5.1.1 AutoQoS Cisco.......................................................................................................... 87

5.1.2 Evolución AutoQoS ................................................................................................... 88

5.1.3 Despliegue de AutoQoS en switches ......................................................................... 88

5.1.4 Cisco AutoQoS Empresarial: Restricciones de despliegue .......................................... 89

5.1.5 Consideraciones de Diseño ...................................................................................... 89

5.1.6 Pre requisitos del router .......................................................................................... 90

5.1.7 Despliegue de AutoQoS Empresarial en routers: Un enfoque de 2 pasos .................. 90

5.1.8 Verificación de Cisco AutoQoS .................................................................................. 91

CCNP ONT

75.2 Tareas Comunes Cisco AutoQoS ...................................................................................... 93

5.2.1 Automatización con Cisco AutoQoS .......................................................................... 93

5.2.2 Mecanismos DiffServ habilitados por AutoQoS .......................................................... 93

5.2.3 Aprovisionamiento automático para clases DiffServ con AutoQoS ............................. 95

5.2.4 Tareas comunes con AutoQoS .................................................................................. 95

5.2.5 Interpretar las configuraciones AutoQoS ................................................................... 95

5.2.6 Modificar la configuración AutoQoS activa con la MQC ............................................. 96

5.2.7 Modificar la política AutoQoS generada con la MQC .................................................. 97

Tema 6. Implementar Escalabilidad Wireless ............................................................................ 98

6.1 Implementar QoS WLAN .................................................................................................. 98

6.1.1 Un estándar para el QoS WLAN ................................................................................. 98

6.1.2 Descripción del QoS para WLAN ................................................................................ 98

6.1.3 Tiempo de Backoff en WLAN QoS RF ......................................................................... 98

6.1.4 Lightweight AP – Arquitectura MAC partida ............................................................... 99

6.1.5 Desafíos WLAN QoS .................................................................................................. 99

6.1.6 Implementación QoS en WLAN ................................................................................. 99

6.1.7 Etiquetado de Paquetes ......................................................................................... 100

6.1.8 Configuración QoS WLAN ........................................................................................ 101

6.2 Introducción a la seguridad Wireless ............................................................................ 102

6.2.1 La necesidad de seguridad WLAN ........................................................................... 102

6.2.2 WEP 802.11 ............................................................................................................ 102

6.2.3 Seguridad WEP Cisco 802.11 mejorada.................................................................... 103

6.2.4 Vistazo a 802.1x ..................................................................................................... 103

6.2.5 LEAP ...................................................................................................................... 103

6.2.6 EAP-FAST ................................................................................................................ 104

6.2.7 EAP-TLS .................................................................................................................. 105

6.2.8 PEAP ...................................................................................................................... 105

6.2.9 Acceso Protegido Wi-Fi ........................................................................................... 106

6.2.10 Tareas WPA .......................................................................................................... 107

6.3 Gestión de WLANs ........................................................................................................ 108

6.3.1 Red Cisco Unified Wireless ..................................................................................... 108

6.3.2 Componentes e implementación de WLAN Cisco .................................................... 109

6.3.3 CiscoWorks WLSE para la solución WLAN autónoma ................................................ 109

6.3.4 Configuración simplificada de CiscoWorks WLSE Express ........................................ 111

6.3.5 Cisco WCS para la solución LWLAN ......................................................................... 111

6.3.6 Prestaciones del software WCS .............................................................................. 112

6.3.7 Interfaz de usuario WCS ......................................................................................... 113

6.3.9 Dispositivo Cisco Wireless Location ........................................................................ 114

CCNP ONT

86.4 Desplegando Cisco WCS ................................................................................................ 115

6.4.1 Ejemplo de configuración del WCS ......................................................................... 115

6.4.2 Añadir un controlador WLAN al WCS ....................................................................... 115

6.4.3 Configurar un Punto de Acceso .............................................................................. 116

6.4.4 Agregar un mapa del campus a la base de datos del WCS...................................... 116

6.4.5 Detección de Puntos de acceso fakes .................................................................... 117

6.4.6 Localización de los AP rogues ................................................................................ 117

6.5 Configurar Cifrado y Autenticación el Puntos de Acceso Lightweight ............................. 118

6.5.1 Configurar Autenticación Abierta ............................................................................ 118

6.5.2 Configuración de autenticación con clave WEP estática .......................................... 118

6.5.3 Configurar WPA con claves pre-compartidas ........................................................... 119

6.5.4 Configurar autenticación Web ................................................................................ 119

6.5.5 Personalizar la pantalla de login Web .................................................................... 119

6.5.6 Configurar autenticación 802.1x ............................................................................. 120

6.5.7 Configurar WPA con 802.1x ..................................................................................... 121

6.5.8 WPA2 ..................................................................................................................... 121

CCNP ONT

9

Tema 1. Requisitos para la Conectividad de Red Convergente

1.1 La evolución de la telefonía empresarial

1.1.1 El sistema telefónico Básico Un sistema telefónico básico consiste en cuatro elementos primordiales:

- TELÉFONO: Que convierta el sonido en señales eléctricas y viceversa. - UNA O MÁS INSTALACIONES CENTRALES: Para interconectar grupos de suscriptores locales. Los

teléfonos modernos usan TDM para digitalizar las señales analógicas de los suscriptores, asignando posteriormente cada una de ellas a slots de tiempo.

- CONEXIONES A LAS INSTALACIONES CENTRALES: Desde los suscriptores al SP. - CONEXIONES ENTRE LOS MÚLTIPLES CENTROS: Para interconectar los SP mediante redes telefónicas.

Para el suscriptor, Existen 4 formas de conectarse al sistema telefónico: - Usando conexiones cableadas dedicadas físicas. - Mediante radio (usando móviles, satélite o radioteléfono) - Mediante VoIP.

1.1.2 Compañías de servicios telefónicos tradicionales Los servicios de PSTN (Public Switched Telephone Network) y PTT (Postal, Telephone and Telegraph) en la mayoría de los lugares del mundo portan la voz analógica sobre cables de cobre. Este servicio telefónico básico a menudo es conocido como POTS (Post Office Telephone Service), aunque actualmente estas siglas se están traduciendo como Plain Old Telephone Service (Servicio telefónico plano antiguo). Antes de la aparición de los teléfonos móviles, POTS era el único servicio telefónico que la mayoría de la gente conocía. Entre los servicios ofrecidos por la POTS, tenemos: señales bidireccionales o full-duplex que portan el sonido de la voz humana en ambas direcciones a la vez / señales de tono de marcado y de campana / Marcado del suscriptor / Servicios del operador, como asistencia de directorio, larga distancia y asistencia de llamada en conferencia / Alimentación al teléfono.

1.1.3 Tecnologías telefónicas digitales La PSTN ha evolucionado a la telefonía digital, mejorando la capacidad y la calidad de la red. En 1970 las compañías telefónicas comenzaron a modificar sus redes telefónicas analógicas actualizando secciones de transmisión de larga distancia de sus redes con tecnologías de fibra óptica. La transmisión digital hace posible portar múltiples circuitos conmutados digitalizados en un medio único de transmisión (conocido como multiplexación). Aunque los equipos del usuario se mantienen en su mayoría analógicos, los switches en el intercambio telefónico (conocidos como switches de señales de voz analógicos) convierten las señales analógicas a señales digitales. Recientemente, los telcos comenzaron a mover sus redes digitales más cerca de las instalaciones del cliente. Este cambio ha relegado al bucle local analógico a un estado de obsoleto. Generalmente, los telcos ofrecen servicios de transporte digital de una de las siguientes dos formas: RDSI provee un bucle local digital desde la oficina central a las instalaciones del cliente. En Norte América y Japón, la tecnología T1 (Transmission 1) provee líneas troncales entre intercambios. En Europa (E1), el funcionamiento es similar, con las siguientes salvedades:

- Las líneas T1 y E1 son conexiones telefónicas dedicadas que soportan altos radios de datos. La portadora T1 es la más usada en servicios de transmisión digital en los EE.UU., Canada y Japón. El estándar E1 se usa en Europa y otras partes del mundo.

o Una T1 tiene 24 canales individuales, cada uno capaz de soportar el equivalente a una llamada telefónica analógica. La capacidad total de una línea T1 es de 1,54 Mbps. Los ISP comúnmente usan líneas T3 que proveen hasta 44,73 Mbps. Los circuitos T3 son alquilados comúnmente por pequeñas y medianas empresas.

o Una línea E1 tiene 32 canales de 64 Kbps y soporta un agregado de 2,04 Mbps. o T1 y E1 usan señales PCM (Pulse Code Modulation, ver imagen)

en conjunto con TDM (multiplexació n por división de tiempo). Cada canal de 64 Kbps puede configurarse para portar tráfico de voz o de datos. Muchas compañías telefónicas ofrecen a los clientes canales individuales o fracciones de una T1. La línea T1 originalmente usa cables de cobre pero en la actualidad también se ofrece sobre enlaces de fibra e inalámbricos.

o Las líneas T1 son una opción popular de línea alquilada para conectar negocios a Internet y para conexiones entre ISP al backbone de Internet.

- RDSI provee transmisión digital sobre el cable telefónico de cobre tradicional así como sobre otros medios. Conceptualmente, RDSI integra tráfico de voz con datos digitales sobre la misma red. Los hogares y negocios reciben capacidades de datos de hasta 2 veces el obtenido con una conexión vía módem.

CCNP ONT

10o RDSI requiere adaptadores en ambos finales de la transmisión (instalaciones del cliente y

instalación del SP). En muchos lugares donde los SP ofrecen líneas DSL y cable módem, RDSI con es una opción popular.

o Existen 2 niveles de servicios RDSI. Ambos incluyen un número de canales B y un canal D. Cada canal B porta datos, voz y otros servicios a una velocidad de 64 Kbps. Cada canal D porta información de control y de señalización.

� BRI: Se usa para hogares y pequeñas empresas. Contiene 2 canales B y un canal D. � PRI: Se usa para usuarios mayores. Incluye 23 canales B en Norte América y Japón y

30 en Europa, y un canal D. o RDSI se popularizó como una tecnología de red inteligente que añadiría nuevos servicios a

la PSTN dando a los usuarios acceso directo a circuitos end-to-end digitales. o PRI es usado comúnmente en estudios de grabación donde los actores de doblaje están en

un estudio mientras que el director y el productor están en un estudio en otra parte. RDSI se usa ya que garantiza un servicio en tiempo real mucho más fiable que a través de Internet. Algunas compañías realizan llamadas de videoconferencia combinando 3 líneas BRI para crear una buena calidad de imagen.

1.1.4 Servicios telefónicos digitales Con el desarrollo de la telefonía digital, se agregaron nuevos servicios disponibles para el consumidor, como buzón de voz, ID de quien llama, llamada en espera, recordatorio de llamada, llamada por conferencia, etc…

1.1.5 Servicios PBX y Centrex Muchas empresas usan una PBX (Private Branch Exchange / Central Secundaria Privada). La mediana y gran empresa usan una PBX ya que resulta mucho menos caro que conectar una línea de teléfono externa a cada teléfono de la organización. Además, resulta más sencillo realizar llamadas internas con una PBX usando sólo 3 o 4 digitos. Se pueden conectar muchos teléfonos a una PBX, pero los usuarios sólo pueden compartir un cierto número de líneas externas para realizar llamadas al exterior. Normalmente, para asegurar la línea externa, el llamante marca un dígito antes del número telefónico final. Para las empresas que no están dispuestas o no son capaces de invertir en una PBX, algunas compañías telefónicas ofrecen servicios Centrex (Central Office Exchange Service). Centrex es una PBX virtual donde toda la conmutación ocurre en la oficina telefónica en lugar de en las instalaciones del cliente. Típicamente, la compañía telefónica es la propietaria de todos los equipos de comunicaciones necesarios para implementar la PBX, y vende varios servicios a las compañías. Algunos de los servicios ofrecidos por Centrex son: Transferencia de llamada / Desvío de llamadas (con no respuesta activado o con llamadas ocupadas) / Llamada en espera / Conferencia de 3 partes / Descuelgue en grupo / Llamada de vuelta / Alarmas / Remarcación… Los clientes Centrex pueden escoger entre una gran variedad de servicios especiales y prestaciones:

- PACKS CENTREX: Se ofrece a los clientes un conjunto de prestaciones en diferentes lotes. Estos lotes se ofrecen a un consto relativamente bajo, donde la personalización del pack no está permitida. La pérdida de personalización minimiza los costos operaciones de programación y mantenimiento de los servicios.

- DATA CENTREX: Provee servicios de datos de baja velocidad (56 y 64 Kbps) usando la red telefónica conmutada. Aunque han sido eclipsados por Internet y otras redes de datos, los servicios de datos Centrex pueden ofrecer configuraciones de red muy flexibles ya que las conexiones pueden realizarse en cualquier parte donde exista una red telefónica.

- CENTREX PERSONALIZADO: Ofrece un conjunto de opciones altamente personalizables que requieren una programación especial y unas habilidades de solución de problemas que mantener. Una configuración de Centrex personalizado permite marcados de 4 digitos entre personas de la misma red, llamadas “locales” (en ocasiones, las locales están localizadas en diferentes partes de una ciudad), enrutamiento personalizado a través de la red telefónica (como un enrutamiento de menor coste o de hora del día), y códigos personalizados para solicitar prestaciones. Es la solución más cara.

1.1.6 Servicios de Larga Distancia Los servicios de larga distancia representan un gasto significativo. Cuando los costos de larga distancia son relativamente altos, las compañías mantienen el control sobre este tipo de llamadas. Las líneas troncales de larga distancia normalmente usan tecnologías TDM y transportes T1 o E1. El servicio de larga distancia que se ofrece en Norte América se conoce como WATS (Wide Area Telephone Service). Los planes WATS proveen acceso a líneas telefónicas de larga distancia para uso comercial con tasas reducidas. WATS puede ser saliente (OUT-WATS) entrante (IN-WATS) o ambos:

- OUT-WATS: La llamada saliente puede realizar un número ilimitado de llamadas a larga distancia (toll calls / llamadas de peaje) con un precio medio entre un tiempo predeterminado y una distancia. La mayoría de las compañías telefónicas comercial OUT-WATS como algo llamada plan de tarifa plana. Inicialmente, la asistencia del operador era necesaria para controlar el acceso a OUT-WATS desde

CCNP ONT

11una PBX. Siguiente la política de la compañía, los emisores solicitaban a la operadora de la compañía conectarse a una línea OUT-WATS tendida a un sistema de larga distancia. Sin embargo, a medida que se redujeron los costes de las llamadas a larga distancia, la intervención de la operadora fue desapareciendo. Los usuarios que quieren realizar una llamada desde dentro de una PBX normalmente sólo necesitan añadir un prefijo para obtener acceso a número de larga distancia.

- IN-WATS: Los suscriptores tienen un número de teléfono libre de cuotas. El servicio IN-WATS reduce el tiempo que el operador gasta en procesar llamadas. Los códigos de área IN-WATS en Norte América son 800, 888, 877 y 866, pero están reservados más de 800 para el futuro. Los usuarios dentro de un área designada pueden llamar al teléfono IN-WATS de una organización sin tener que pagar. Muchos negocios tienen número 800 gratuitos que pueden reenviar a múltiples call-centers.

1.1.7 El concepto de Convergencia Antes de que las tecnologías de red permitieran la convergencia, las empresas contrataban redes separadas para las aplicaciones de voz, datos y vídeo, en la mayoría de los casos, operando cada una de ellas de forma aislada. En pocas palabras, el tráfico de voz usaba PBX y el tráfico de datos Routers. Las PBX se conectan a líneas alquiladas, mientras que la red de datos usaba líneas alquiladas, Frame Relay o ATM. El desafío empresarial es optimizar la red para portar datos, voz y vídeo sobre una misma red común. Esta consensuado por los expertos que IP será el transporte universal del futuro. Usar IP como el método de transporte ofrece a la empresa ganancias significativas en eficiencia de ancho de banda, facilidad de gestión, y la habilidad de desplegar nuevas aplicaciones rápidamente. Cuando las compañías se suscriben a modelos de red dispares, a menudo pagan por servicios que no están usando. En un entorno convergente, el ancho de banda se comparte entre voz, vídeo y aplicaciones de datos. Cuando la voz es inactiva, los datos pueden usar el ancho de banda disponible. Cuando las aplicaciones de voz o vídeo están activas, el ancho de banda requerido para su operación está garantizado.

1.2 Descripción de los Requisitos de las Redes Convergentes

1.2.1 Modelo de Red Jerárquico El modelo tradicional usa un modelo jerárquico de 3 capas. Inicialmente, el modelo provee un marco modular que permite de forma sencilla flexibilidad, implementación y solución de problemas. El modelo jerárquico divide la red en 3 bloques modulares, cada uno con prestaciones específicas:

- CAPA DE ACCESO: Se encarga de dar acceso a los usuarios. En una red de campus, la capa de acceso usa switches LAN con puertos que proveen conectividad a usuarios finales y servidores. En esta capa se asocian enlaces WAN con sitios remotos y teletrabajadores.

- CAPA DE DISTRIBUCIÓN: Utiliza switches que se encargan de segmentar grupos de trabajo y asilar problemas de red en un entorno de campus. Provee conectividad basada en políticas.

- CAPA DE NÚCLEO: También conocida como backbone. Su función primordial es conmutar paquetes a la máxima velocidad. Debe proveer un alto nivel de disponibilidad y adaptarse a los cambios rápidamente.

Los diseñadores de red pueden aplicar el modelo jerárquico a cualquier tipo de red, incluyendo LANs, WANS, WLANs, MANs y VPNs.

1.2.2 Arquitectura Empresarial de Cisco Desde el punto de vista de un departamento de IT, la Arquitectura Empresarial de Cisco facilita el planeamiento, el diseño, la implementación, la operación y la solución de problemas (PDIOT) centrándose en los elementos de la red y en las relaciones entre los mismos. La arquitectura empresarial de Cisco consiste en 5 elementos:

/ CAMPUS: Combina una infraestructura de núcleo de conmutación y enrutamiento inteligente con tecnologías altamente integradas de mejora de la productividad, incluyendo comunicaciones IP, movilidad y seguridad avanzada. Provee prestaciones del tipo: Alta disponibilidad con un diseño multicapa y hardware y software redundante / Procedimientos automáticos para reconfigurar rutas de red que han fallado / Multicast para optimizar el uso del ancho de banda / QoS para prevenir la eliminación o el retraso de tráfico sensible a demoras / Seguridad integrada para proteger y mitigar el impacto de virus, gusanos y otros ataques. También soporta el uso de 802.1X. / Soporta el uso de IPsec y MPLS.

CCNP ONT

12/ DATA CENTER: Es una arquitectura de red unificada y adaptativa. Soporta consolidación, continuidad en el negocio y seguridad. Al mismo tiempo, habilita arquitecturas emergentes orientadas a servicios, virtualización y computación bajo demanda. El departamento de IT provee un acceso seguro a las aplicaciones y recursos. Esta estructura simplifica la gestión y reduce de forma significativa la carga. Los centros de datos redundantes proveen copias de seguridad usando replicaciones. La red y los dispositivos de red ofrecen balanceo de carga de servidor y de aplicación para maximizar el funcionamiento. Esta solución permite a la empresa escalar sin realizar cambios mayores en la infraestructura. / BRANCH: Permite a las empresas extender las aplicaciones y servicios de la oficina central, como seguridad, comunicaciones IP y aplicaciones avanzadas a miles de localizaciones remotas y usuarios, o a un pequeño grupo de sucursales. Integra seguridad, conmutación, análisis de red y voz convergente dentro de routers ISR (integrated services routers) en la sucursal. Con esta integración, las empresas pueden desplegar nuevos servicios sin necesidad de comprar nuevos equipos. Esta solución provee acceso de voz seguro y transmisiones de datos críticos y aplicaciones de vídeo en cualquier lugar a cualquier hora. Se provee una arquitectura robusta con altos niveles de flexibilidad para todas las sucursales, mediante un enrutamiento avanzado, VPN’s, enlaces WAN redundantes y procesamiento de llamadas telefónicas locales IP. / TELETRABAJADOR: Permite a las empresas entregar servicios de voz y datos seguros a oficinas hogareñas pequeñas (SOHOS) sobre un servicio de acceso de banda ancha (como DSL y cable módem). La gestión centralizada minimiza el costo de soporte. / WAN: Provee servicios de voz, vídeo y datos sobre una red de comunicaciones IP única. QoS, niveles de servicio granulares y un cifrado comprensivo ayudan a asegurar la seguridad entregando recursos de vídeo, voz y datos de alta calidad a todos los sitios corporativos. La seguridad se provee con VPNs multiservicio (IPsec y MPLS) sobre WANs de capa 2 o de capa 3, topologías hub-and-spoke o malla completa.

1.2.3 Condiciones de tráfico en una Red Convergente Las redes convergentes con voz, vídeo y datos integrados contienen una mezcla de patrones de tráfico y requisitos. La diversidad de tráfico impone el uso de medidas de calidad de servicio y de seguridad en la red. Los requisitos pueden variar significativamente, dependiendo del tipo de tráfico. Los servicios QoS son imprescindibles en las redes convergentes. La seguridad es una tarea clave en una red convergente, y es especialmente importante en redes donde se implementa movilidad wireless, donde el acceso a la red es posible desde cualquiera virtualmente. Varias estrategias de seguridad, como endurecimiento de dispositivos con un control de acceso estricto y autenticación, prevención de intrusiones, detección de intrusiones y protección de tráfico con cifrado, pueden mitigar las amenazas de seguridad a la red.

1.2.4 IIN (Red de Información Inteligente) La visión de IIN tiene 3 prestaciones clave:

- INTEGRACIÓN DE RECURSOS DE RED Y RECURSOS DE INFORMACIÓN: Las redes modernas con voz, vídeo y datos integrados permiten al departamento de IT enlazar la infraestructura más de cerca con la red de información.

- INTELIGENCIA A TRAVÉS DE MÚLTIPLES PRODUCTOS Y CAPAS DE INFRAESTRUCTURA: La inteligencia que se construye en cada componente de red extiende a la propia red y se aplica de fin-a-fin.

- PARTICIPACIÓN ACTIVA DE LA RED EN LA ENTREGA DE SERVICIOS Y APLICACIONES: Con inteligencia añadida dentro de los dispositivos de red, el IIN hace posible que la red de forma activa gestione, monitoree y optimice los servicios y aplicaciones a lo largo del entorno empresarial completo.

Con estas prestaciones, el IIN ofrece mucho más que la conectividad básica, ancho de banda para usuarios y el acceso a las aplicaciones. El IIN ofrece una funcionalidad “end-to-end” y un control centralizado y unificado que promueve la transparencia verdadera y la agilidad. La visión de IIN ofrece un enfoque evolutivo. Funcionalmente, puede ser añadido a la infraestructura de red existente en 3 fases:

CCNP ONT

13- TRANSPORTE INTEGRADO: IIN consolida datos, voz y video en una red IP para una convergencia

segura. Integrando el transporte de estos 3 componentes en una red única, basada en estándares y modular, las organizaciones pueden simplificar la gestión de la red y reducir costes de infraestructura.

- SERVICIOS INTEGRADOS: Cuando se completa la convergencia, la red une y comparte, o virtualiza, recursos para lograr alcanzar las necesidades de la organización de forma más flexible. Los servicios integrados unifican elementos comunes incluyendo almacenamiento y capacidad de servidor de centro de datos.

- APLICACIONES INTEGRADAS: La tercera fase es una red orientada a aplicaciones (AON). AON se centra en hacer a la red “consciente” de las aplicaciones para que pueda optimizar el funcionamiento de las mismas y entregar aplicaciones de red a los usuarios de forma más eficiente. Además, ofrece funciones de balanceo de carga y seguridad a nivel de aplicación.

1.2.5 Marco Cisco SONA Cisco SONA es un marco arquitectónico que detalla el conjunto de servicios comunes que se despliegan en la red para cerrar huecos entre los recursos y las aplicaciones. Cisco SONA describe como construir una IIN. El marco Cisco SONA provee las siguientes ventajas: Guías de ruta hacia el IIN / Ilustra cómo construir servicios integrados para una convergencia IIN total / Mejora la flexibilidad e incrementa la eficiencia dando como resultado aplicaciones, procesos y recursos optimizados. La base de SONA es la premisa que la red es el elemento común que conecta y habilita todos los componentes de la infraestructura de IT. Las guías de SONA se centran en las siguientes 3 capas del modelo IIN:

CAPA DE INFRAESTRUCTURA DE RED: Esta capa interconecta todos los recursos de IT a través de una red convergente. Los recursos de IT incluyen servidores, almacenamiento y clientes. Esta capa representa como estos recursos existen en diferentes lugares de la red, incluyendo el campus, sucursales, centros de datos, WAN y MAN y localizaciones de teletrabajadores. Esta capa provee conectividad en cualquier lugar a cualquier hora. CAPA DE SERVICIOS INTERACTIVOS: Esta capa entrega de forma eficiente la localización de los recursos a las aplicaciones y negocios a través de la infraestructura de red. Incluye los siguientes

servicios: Servicios de voz / Servicios de movilidad / Servicios de seguridad e identidad / Servicios de almacenamiento / Servicios de computación / Servicios de aplicaciones de red / Virtualización de la infraestructura de red / Servicios de gestión / Servicios de gestión adaptativos. CAPA DE APLICACIÓN: Incluye aplicaciones de negocios y aplicaciones colaborativas. El objetivo de los clientes en esta capa es encontrar los requisitos de su negocio y lograr la eficiencia maximizando la capa de servicios interactivos.

CCNP ONT

14

Tema 2. Implementaciones VoIP de Cisco

2.1 Introducción a las redes VoIP

2.1.1 Beneficios de las redes VoIP Existen varios beneficios de usar redes VoIP:

- USO MÁS EFICIENTE DEL ANCHO DE BANDA Y DEL EQUIPAMIENTO: Las redes telefónicas tradicionales usan un canal de 64 kbps para cada llamada de voz. Las redes VoIP comparten el ancho de banda a lo largo de múltiples conexiones lógicas.

- MENORES COSTOS DE TRANSMISIÓN: Una cantidad sustancial de equipamiento es necesario para combinar canales de 64 kbps en enlaces de alta velocidad para transportarse a través de la red. La VoIP multiplexa de forma estadística el tráfico de voz con el tráfico de datos. Esta consolidación provee ahorros sustanciales en el equipamiento y los costos operativos.

- GASTOS DE RED CONSOLIDADOS: En lugar de operar con redes de datos y voz separadas, las redes de voz se convierten al uso de una arquitectura de conmutación de paquetes para crear una red de comunicaciones integradas con un sistema de conmutación y transmisión común.

- MEJORA DE LA PRODUCTIVIDAD DE LOS EMPLEADOS A TRAVÉS DE PRESTACIONES PROVISTAS POR LA TELEFONÍA IP: Los teléfonos IP son sólo teléfonos: pueden considerarse dispositivos de comunicación del negocio. Los teléfonos IP ofrecen búsquedas de directorio y un acceso a bases de datos a través de aplicaciones XML. Estas aplicaciones permiten la integración de la telefonía en una aplicación empresarial. Por ejemplo, los empleados pueden usar el teléfono para buscar información sobre un cliente a quien han llamado, buscar información del inventario e ingresar pedidos.

- ACCESO A NUEVOS DISPOSITIVOS DE COMUNICACIÓN: La tecnología de paquetes puede alcanzar a dispositivos que han sido inaccesibles a través de infraestructuras TDM, como por ejemplo computadoras, dispositivos wireless, PDAs, etc. La tecnología de paquetes habilita a las compañías a comerciar con nuevos dispositivos, como teléfonos que incluyen vídeo, terminales multimedia y teléfonos IP avanzados.

2.1.2 Componentes de una red VoIP Una red VoIP tiene varios componentes, de los que podemos destacar:

TELÉFONOS: Pueden ser teléfonos IP, teléfonos basados en software operando en un PC o teléfonos tradicionales (analógicos o RDSI). GATEWAYS: Los gateways interconectan la red VoIP con los dispositivos telefónicos tradicionales. Son habitualmente routers habilitados para voz que proveen las siguientes funciones: En una parte, la línea telefónica se conecta al gateway. El gateway conecta a la PSTN y se comunica con cualquier teléfono del mundo. / En otra parte, el gateway conecta a la red IP y se comunica con cualquier computadora en el mundo. / El gateway toma las señales telefónicas estándar, las digitaliza (si no son ya digitales), las comprime, las hace paquetes usando IP, y las enruta a su destino a través de

la red IP. / El gateway invierte la operación para los paquetes entrantes desde la red y se los hace llegar al teléfono / Ambas operaciones (ida y vuelta a la red telefónica) tienen lugar al mismo tiempo, permitiendo una conversación de 2 vías full-duplex. UNIDADES DE CONTROL MULTIPUNTO (MCU): Requeridas para conferencias. Si más de 2 partes están envueltas en una llamada, todos los miembros de la conferencia envían su tráfico al MCU. El MCU mezcla los tráficos y envía los mismos a los participantes. SERVIDORES DE APLICACIÓN: Proveen servicios basados en XML a los teléfonos IP. Los usuarios tienen acceso a directorios y bases de datos a través de aplicaciones XML. GATEKEEPERS: Son componentes útiles, pero opcionales. Proveen enrutamiento y gestión centralizada de todos los puntos finales (terminales, gateways y MCUs) en un lugar dado. El gatekeeper y los puntos finales forman una “zona de gestión”. AGENTES DE LLAMADA: Proveen control de llamada, CAC (Call Admission Control), control de ancho de banda y servicios de traducción de direcciones a teléfonos IP o a gateways. El CallManager de Cisco es un agente de llamada. El CallManager persigue a todos los componentes activos de la red VoIP incluyendo teléfonos, gateways, etc. A menudo usa el protocolo SCCP (Skinny Client Control Protocol) para señalizar el hardware de los puntos finales del sistema, como teléfonos IP. En cierta forma, el CallManager actúa como una PBX IP. PUNTOS FINALES DE VÍDEO: Proveen prestaciones de vídeo telefonía a los usuarios. Necesitan, al igual que el audio, una MCU cuando realizan multiconferencias.

CCNP ONT

15

2.1.3 Interfaces analógicas heredadas en redes VoIP Una red VoIP que incluye equipo “legacy”, como teléfonos analógicos, necesita gateways que conviertan las señales analógicas en un formato digital y encapsulen las mismas en paquetes IP. Los gateways usan diferentes tipos de interfaces para conectar dispositivos analógicos, como teléfonos, fax, o switches PBX o PSTN. Las interfaces analógicas que se usan incluyen estos 3 tipos:

- FXS (FOREIGN EXCHANGE STATION): FXS es una interfaz telefónica que provee alimentación, envía tono de marcado y genera voltaje de timbre. Un intercambio telefónico es un ejemplo de una FXS. En implementaciones VoIP, la interfaz FXS conecta a sistemas finales analógicos. El sistema final analógico usa la interfaz FXO (Foreign Exchange Office) en su lado. La interfaz FXS se comporta como un PSTN o una PBX de cara los teléfonos, contestando a las máquinas o faxes con alimentación, tono de timbre y tonos de marcado. Si una PBX usa una interfaz FXO, puede conectarse a una interfaz de router FXS. En este caso, la PBX actúa como un teléfono.

- FXO (FOREIGN EXCHANGE OFFICE): Una FXO es una interfaz telefónica que conecta a la PSTN. La FXO genera indicadores de cuelgue/descuelgue que se usan para señalizar un cierre de bucle en el circuito. En implementaciones VoIP, la interfaz FXO se conecta a la PSTN o a una PBX. Tanto la PSTN como la PBX usan una interfaz FXS en su lado. La interfaz FXO del router se comporta como un teléfono, obteniendo alimentación, voltaje de timbre y tonos de llamada del otro lado del cable. Como se mencionó, una PBX pueden usarse también con una interfaz FXO hacia el router, tomando el rol de teléfono.

- EYM (EAR AND MOUTH): Esta interfaz provee señalización para troncales analógicos. Los troncales analógicos interconectan 2 dispositivos del estilo PBX.

2.1.4 Interfaces digitales Los gateways pueden usar interfaces digitales para conectarse a equipamiento de voz. Desde la perspectiva de hardware, existen interfaces BRI y T1/E1. Todas estas interfaces usan TDM para soportar múltiples canales lógicos.

CAS y CCS son métodos de señalización para T1/E1. BRI siempre usa CCS.

2.1.5 Fases para completar una llamada telefónica VoIP Existen 3 componentes básicos de control de llamadas:

- CONFIGURACIÓN DE LLAMADA (CALL SETUP): El call setup chequea la configuración de enrutamiento de llamada para determinar el destino de una llamada. La configuración especifica los requisitos de ancho de banda para la llamada. Sabiendo estos requisitos, CAC determina si el ancho de banda es suficiente para soportar la llamada. Si no existe ancho de banda disponible, el call setup presenta un iniciador de llamada (call initiator) con una señal “busy”. Existen diferentes protocolos de control de llamada, como H.323, MGCP y SIP, con diferentes conjuntos de mensajes que intercambian los dispositivos durante la configuración de la llamada. Sin embargo, todos los mensajes de estos protocolos consultan la misma información básica:

o Dirección IP de los dispositivos que quieren intercambiar VoIP. o Números de puerto UDP que serán usados por el protocolo RTP (Real-Time Protocol) el

cual porta el tráfico de voz.

CCNP ONT

16o El formato (por ejemplo, el algoritmo de compresión) usado por la voz digitalizada.

- MANTENIMIENTO DE LLAMADA: El mantenimiento de llamada genera contadores de paquetes, perdida de paquetes, “jitter” y retardos durante la llamada. La información se pasa los dispositivos habilitados para voz para determinar si la calidad de la conexión es buena o esta tan deteriorada que el gateway deba cerrar la conexión.

- CALL TEARDOWN (TIRAR ABAJO LA LLAMADA): Notifica a los dispositivos habilitados para voz que dejen recursos disponibles para otras llamadas cuando una lado termina una llamada.

2.1.6 Control de Llamada Distribuido Existen 2 tipos de control de llamadas: distribuido y centralizado. En el pasado, todas las redes de voz usaban una arquitectura centralizada en la cual los teléfonos eran controlados por switches centralizados. Aunque este modelo funcionó bien para los servicios de telefonía básica, se necesitaba un equilibrio entre una gestión simplificada y una innovación en el servicio ofrecido. Uno de los beneficios de la VoIP es que permite a las redes usar una arquitectura centralizada o distribuida. Esta flexibilidad permite a las compañías construir redes caracterizadas por la simpleza de su gestión y por la innovación, dependiendo del protocolo usado.

En la figura se muestra el modelo distribuido en el cual múltiples componentes de la red manipulan el control de la llamada. Con el control distribuido, los dispositivos realizan la configuración de la llamada, el mantenimiento y la finalización sin la intervención de la compañía telefónica. 1/ Cuando el teléfono detecta una solicitud de servicio (se descuelga), el gateway R1 envía un tono de marcado.

2/ Después, R1 recoge los dígitos que marca el cliente. 3/ R1 busca el número marcado en su tabla de enrutamiento local de llamadas. De acuerdo a la misma, el número marcado usa el segundo gateway (R2). 4/ R1 ahora ingresa en la primera fase de la llamada (call setup), enviando el mensaje apropiado a R2. 5/ R2 recibe el mensaje call setup de R1. 6/ R2 busca el número llamado en su tabla de enrutamiento de llamada local. De acuerdo a esta tabla, el número llamado usa un puerto de voz local. 7/ R2 envía la llamada al puerto de voz local aplicándole el voltaje del timbre. En este ejemplo del modelo de llamada distribuida, R1 realiza la decisión local de enviar el mensaje call setup a R2 basándose en su tabla de enrutamiento de llamadas. R2, de nuevo, toma su decisión local (usando su tabla de enrutamiento de llamadas local) para que el dispositivo llamado pueda ser alcanzado en un puerto físico. - SUPERVISIÓN DE LA LLAMADA: Durante la llamada, R1 y R2 monitorean la calidad de la llamada. En el

modelo de llamada distribuido, si uno de los gateways detecta que la calidad no es aceptable, termina la llamada. Esta supervisión ocurre durante la segunda fase de la llamada, el “call maintenance”.

- TERMINACIÓN DE LA LLAMADA: Si el usuario que llama conectado a R1 termina la llamada, R1 informa a R2 de la finalización. En el modelo distribuido, el gateway inicia la tercera fase de la llamada, el “call teardown”. El gateway termina la llamada y deja libre los recursos que estaban siendo utilizados por la llamada en cuestión.

En despliegues grandes usando el modelo distribuido, se utilizan dispositivos especializados para una búsqueda centralizada de números. Los gateways y puntos finales usan gatekeepers H.323 o servidores de red SIP para encontrar número que no conocen localmente.

CCNP ONT

17

2.1.7 Control de Llamada Centralizado En la figura se muestra un entorno donde un único componente en la red, conocido como “call agent” manipula el control de la llamada. En el ejemplo, ambos gateways tienen el protocolo MGCP habilitado. Con MGCP habilitado, los gateways usan al call agent para realizar las siguientes funciones:

PROCESAR LOS DIGITOS MARCADOS Y ENRUTAR LA LLAMADA: 1/ Después de detectar una solicitud de servicio (el usuario descuelga el teléfono), R1 informa al call agent de la solicitud. 2/ El call agent le dice a R1 que mande un tono de marcado y R1 recibe los dígitos que marca el usuario. 3/ R1 pasa cada dígito recibido (uno a uno) al call agent 4/ El call agent busca el número marcad en la tabla de enrutamiento de llamadas del agente. De acuerdo a la misma, el número de teléfono solicitado se alcanza usando el segundo gateway (R2). El call agent también controla a R2 y, por tanto, sabe que números de teléfono puede alcanzar R2.

Por ello, el call agent sabe a qué puerto de R2 debe enrutarse la llamada. 5/ El call agen envía un mensaje a R2 solicitando que pase la llamada a dicho puerto, que será aquel que conecta al número de teléfono de destino. Esto es un ejemplo de un modelo centralizado, donde toda la inteligencia de enrutamiento de llamada (en este caso, el call setup) se realiza en el call agent. El call agent instruye a los gateways en la forma de manipular la llamada, por lo que sólo el call agent tiene una tabla de enrutamiento de llamadas. SUPERVISAR LA LLAMADA: Durante la llamada, R1 y R2 monitorean la calidad de la misma. En el modelo centralizado, si uno de los gateways detecta que la calidad no es la adecuada, pasa la información al call agent. El call agent será el encargado de terminar la llamada. TERMINAR LA LLAMADA: Si el “llamante” que conecta a R1 finaliza la llamada, R1 informa al call agent de la terminación. El call agent notifica a ambos gateways de la terminación de la llamada VoIP y libera los recursos que estaban siendo usados por la llamada. El modelo centralizado permite a un dispositivo externo (el call agent) manipular la señalización y el procesamiento de llamada, dejando a los gateways traducir las señales de audio a paquetes de voz después de cada “call setup”. Después que se configura la llamada, la voz fluye directamente entre los dos gateways sin pasar por el call agent.

2.2 Digitalización y Empaquetado de la Voz

2.2.1 Codificación básica de la voz: Convertir señales analógicas a señales digitales Los sistemas VoIP recaen en procesadores de señales digitales (DSPs). Los DSPs convierten señales de voz analógicas a un formato digital, y viceversa. También proveen funciones como compresión de la voz, cambios entre diferentes formatos de voz digitalizada (transcoding) y conferencias. Los DSPs son componentes de hardware a menudo localizados en módulos de voz dentro de los gateways. El “sampling” (muestreo) es la técnica que se usa para digitalizar información analógica. El muestreo es la reducción de una señal continua a una señal discreta. Cuando se convierten ondas analógicas, los DSPs construyen una secuencia de muestras desde las cuales la señal analógica puede ser reconstruida de vuelta “igual” que salió desde el origen.

En el ejemplo, una llamada se realiza desde un teléfono analógico (Phone1) que se conecta al router R1, hacia un teléfono analógico (Phone2) que está conectado al router R2. Los dos routers se conectan a una red IP. El usuario del Phone1 habla por el micrófono del teléfono, y el teléfono

envía señales digitales al puerto FXS del router R1. El router R1 convierte la señal analógica recibida a una señal digital, y encapsula los bits en paquetes IP. La red IP porta los paquetes IP al router R2. Los DSPs de las tarjetas de voz en los routers habilitados para voz realizan la conversión de analógico a digital, siguiendo los siguientes pasos: 1/ MUESTREO: El DSP muestrea periódicamente la señal analógica. La salida del muestreo es una señal PAM medida en voltios. 2/ CUANTIZACIÓN: El DSP hace coincidir la señal PAM a una escala segmentada digital. Esta escala mide la amplitud (voltaje) de la señal PAM. 3/ COMPRESIÓN: El DSP comprime las muestras de voz para reducir los requisitos de ancho de banda.

CCNP ONT

18

2.2.2 Codificación básica de la voz: Convertir señales digitales a señales analógicas Cuando un router recibe entradas de voz en formato digital, convierte de vuelta estas señales a forma analógico antes de enviarla a las interfaces de voz analógicas. El proceso de digital a analógico es lo contrario del proceso de analógico a digital. Los DSP en las tarjetas de voz convierten las señales digitales a señales analógicas, siguiendo los siguientes pasos: 1/ DECOMPRESIÓN: Cualquier muestreo de voz comprimido primero se descomprime. 2/ DECODIFICACIÓN: El DSP decodifica las muestras de voz digital a los valres de amplitud de las muestras y reconstruye una señal PAM de la amplitud original. 3/ RECONSTRUCCIÓN DE LA SEÑAL ANALÓGICA: El DSP para la señal PAM a través de un filtro correctamente diseñado que produce una señal espejo analógica igual a la digitalizada anteriormente.

2.2.3 Muestreo (Sampling) Cuando un DSP convierte una señal analógica a una forma digital, el DSP samplea primero la señal analógica. La frecuencia de muestreo impacta en la calidad de la señal digitalizada. Si la frecuencia de muestreo es baja, el DSP procesa demasiada poca información y la calidad resultante es degradada. El teorema de Nyquist es la base de la conversión analógica a digital. En términos sencillos, este teorema dice que la reconstrucción de una señal desde las muestras tomadas es posible si la frecuencia de muestreo es mayor a 2 veces el ancho de banda de la señal.

Los ingenieros seleccionan frecuencias de muestreo que cumplan los requisitos prácticos de la aplicación específica. En la figura se muestran 2 situaciones. En la primera, la frecuencia de muestreo es muy baja, y la información reconstruida es imprecisa. La reconstrucción práctica es imposible. En la segunda, se usa una frecuencia de muestreo mayor, y las señales PAM resultantes representan la forma de onda

original, permitiendo una reconstrucción práctica. El teorema de Nyquist predice como trabaja un DSP. Cuando el DSP muestrea una señal de forma instantánea a intervalos regulares y se toman muestras al menos 2 veces a la mayor velocidad de frecuencia del canal, los samples contendrán suficiente información para permitir una reconstrucción apropiada de la señal en el receptor. Si tomamos muestras por encima del Nyquist estaremos realizando los que se conoce como oversampling. Los ingenieros han llegado a la decisión de tomar 8000 muestras por segundo para las aplicaciones de telefonía. Aunque el oído humano puede escuchar sonidos de 20 a 20000 Hz, los canales de teléfono operan en el rango de 300 a 3400 Hz.

2.2.4 Cuantización Las aplicaciones telefónicas usan una frecuencia de muestreo de 8000 MHz para convertir una señal analógica a un formato digital. El DSP debe redondear el valor de cada muestra al número más cercano en una escala que varía de acuerdo a la resolución de la señal. El DSP convierte estos números a binarios. La cuantización es el proceso de seleccionar números binarios para representar el nivel de voltaje de cada muestra (la amplitud de la modulación PAM). Los DSP usan la cuantización para aproximar los sonidos analógicos al valor binario más cercano disponible. El DSP debe seleccionar el número binario que más se aproxime al nivel de la señal de la muestra. La diferencia entre la señal analógica original y el nivel de cuantización asignado se conoce como “error de cuantización” o “ruido de cuantización”. Esta diferencia es el origen de la distorsión en la transmisión de sistemas digitales. El ruido y la distorsión son 2 fenómenos distintos. La distorsión es cualquier cambio en la señal que resulta en un resultado diferente al original. El ruido es información/señales adicionales añadidas a la original. Las aplicaciones telefónicas usan normalmente cuantizaciones de 8 bits. Los DSP representan todos los valores posibles de la forma de onda analógica con 256 valores de voltaje distintos, cada uno representado en un número binario de 8 bits. Estas aproximaciones no son exactas totalmente y contienen errores de cuantización (ruido), pero el resultado es más que adecuado para representar la voz humana en aplicaciones telefónicas. En comparación, los compact discs usan cuantizaciones de 16 bits, que permiten definir 65.536 niveles de voltaje diferentes.

En la figura se presenta el ruido o error de cuantización. Las muestras tomadas que no se representan justo en la línea que le corresponde representan un ligero cambio en la señal original cuantizada, puesto que no están ubicándose en la posición exacta en la que se crearon en el origen.

CCNP ONT

19

2.2.5 Codificación de la Voz Digital Las muestras de voz digital se presentan en 8 bits/muestra. Cada muestra se codifica de la siguiente forma:

- 1 BIT DE POLARIDAD: Indica si la señal es positiva o negativa. - 3 BITS DE SEGMENTO: Identifican el tamaño del número de segmento logarítmicamente (0-7). - 4 BITS DE PASO: Identifican el paso lineal dentro de un segmento.

Debido a que la telefonía toma muestras a 8000 muestras por segundo, el ancho de banda necesario por llamada es de 64 Kbps. (64000bps/8bits = 8000).

2.2.6 Companding (Compressing and Expanding) El companding se refiere al proceso de comprimir primero una señal analógica en el origen y expandirla la misma de vuelta a su forma original cuando alcanza el destino. El término compandig viene de combinar 2 términos, compressing y expanding, en una única palabra. Un compander comprime muestras entrantes de señales analógicas en segmentos logarítmicos. El compander cuantiza y codifica cada segmento usando una cuantización uniforme. Bell Systems definió el método “mu-law” de cuantización que se usa en los sistemas de telecomunicaciones digitales de Norte América y Japón. Este método de cuantización fue adoptado como el algoritmo “a-law” en Europa y otras partes del mundo. Con estos métodos, el rango de voltajes se representa con 16 segmentos (0 a 7 positivos y 0 a 7 negativos). Cada segmento tiene 16 pasos para un total de 256 puntos de escala. Comenzando con el segmento 0, el cual está más cerca a la amplitud 0, los segmentos van tomando amplitudes mayores.

2.2.7 Características de Códecs de voz comunes La mayoría de los esquemas de compresión se aprovechan del hecho de que los streams de datos tienen muchas repeticiones. Por ejemplo, mientras un bit 7 ASCII representa caracteres alfanuméricos, un esquema de compresión puede usar un código de 3 bits para representar las 8 letras más comunes. En la voz, existen largas ráfagas de silencio que pueden reemplazarse por un valor que indica cuánto silencio hay, o cuánto tiempo dura este silencio. De forma similar, en la compresión gráfica, un valor puede reemplazar espacios en blanco en una imagen indicando el total de espacios en blanco que se reemplazan. Cuando las líneas troncales de la POST se pasaron a la tecnología digital, usaron la modulación por código de pulso (PCM) para digitalizar las señales. Esta técnica usa un códec-decódec para muestrear la amplitud de una señal de voz 8000 veces por segundo y mostrar el resultado en valores de 8 bits. DPCM (Diferencia o Delta PCM) codifica los valores PCM como diferencias entre los valroes actuales y los previos (por ejemplo, si se representa un 7 binario y después un 8, se podría usar un único bit para definir un 1, que sería la diferencia entre los 2). Para el audio, este tipo de codificación reduce el número de bits requeridos por muestra alrededor de un 25%, en comparación con PCM. ADPCM (Delta PCM Adaptativo) es una variante de DPCM que varía el tamaño de los pasos de cuantización para permitir una reducción mayor del ancho de banda requerido para una señal dado. ADPCM usa una técnica de codificación especial que reduce los datos que se requieren para representar un sample, transmitiendo sólo la diferencia entre una sample y el siguiente. Provee 48 canales de voz en una línea T1 (con PCM eran 24). En la siguiente lista se muestran las técnicas de codificación más populares con su “bit-rat”, estandarizadas por el ITU-T como series G:

- G.711: Describe 64 kbps codificados con PCM. - G.726: Describe ADPCM codificando a 40, 32, 24 y 16 kbps. - G.728: Describe la compresión de voz con CELP a 16 kbps. - G.729: Describe la compresión de voz con CELP en streams de 8 kbps. - G.729A: Describe la compresión de audio en secciones de 10 ms.

2.2.8 Selección de un Códec usando un indicador de opiniones Las características más importantes de un códec son el ancho de banda requerido para el procedimiento y la degradación de la calidad causada por la conversión y compresión de analógico a digital. El marcador de opiniones general (MOS) es un sistema que evalúa la calidad de la conexión telefónica que usa códecs, basado en el juicio de varios suscriptores. Debido a que este marcador se gradúa por humanos, el resultado es subjetivo. MOS usa una escala de 1 (malo) a 5 (excelente). Un MOS de 5 representa una conversación directa. En la siguiente tabla se expresan los valores de referencia tomados por MOS.

CCNP ONT

20

2.2.9 Vista del DSP con más detalle Un DSP (Digital Signal Processor) es un procesador especializado usado para aplicaciones telefónicas. Se ocupa de las siguientes tareas:

- TERMINACIÓN DE VOZ: El DSP termina llamadas al gateway que han sido recibidas desde o hacia interfaces de voz tradicionales. Estas interfaces pueden ser analógicas o digitales. El DSP convierte la señal analógica a digital (y viceversa) y provee cancelación de eco, compresión, detección de actividad de voz (VAD), generación de ruido confortable (CNG), eliminación de jitter y otras funciones similares.

- CONFERENCIA: En audio conferencia, los DSP mezclan flujos de voz desde múltiples participantes en una única llamada de conferencia. Todos los participantes envían su audio al puente de conferencia (es decir, al DSP) donde los streams se mezclan y se envían de vuelta a los participantes.

- TRANSCODING: El DSP toma un stream de voz de un tipo de códec y lo convierte a otro códec diferente. Por ejemplo, el transcoding toma un stream G.711 y lo transforma a un códec de tiempo real G.729.

En la figura se muestra un DSP y donde iría integrado en un módulo de voz.

Un DSP permite a los participantes de la conferencia utilizar códecs diferentes (conferencia en modo mixto). Un DSP que se usa para conferencias en modo único soporta sólo un códec que todos los participantes deben utilizar.

2.3 Encapsular paquetes de voz para el transporte

2.3.1 Transporte de voz en redes conmutadas por circuitos En entornos PSTN, los teléfonos residenciales se conectan a los switches de la oficina central (CO) con circuitos analógicos.

El núcleo de la red se compone de switches interconectados por troncales digitales, como se muestra en la figura. Cuando una persona realiza una llamada a un teléfono, la fase “call setup” (establecimiento de llamada) ocurre en un primer lugar. El CO configura un circuito dedicado de extremo a extremo (DS-0) para la llamada. El switch del CO convierte las señales analógicas recibidas a un formato

digital usando el códec G.711. Durante la fase de transmisión, el circuito dedica el ancho de banda completo (64 Kbps) a la llamada, y debido a que todos los bits siguen el mismo camino, todas las muestras de voz llegan en orden. Cuando la llamada finaliza, los switches liberan los circuitos DS0 individuales, dejándolos disponibles para el uso de otras llamadas.

2.3.2 Transporte de voz en redes IP En redes VoIP, los teléfonos analógicos se conectan a gateways VoIP a través de interfaces analógicas. Los gateways se conectan a través de una red IP. Los teléfonos IP se conectan a switches, y los switches se conectan directamente a los routers.

Cuando una persona llama desde un teléfono a otro, la fase “call setup” configura la llamada de forma lógica, pero no se asocian circuitos dedicados (líneas) con la llamada. El gateway convierte las señales analógicas recibidas en un formato digital usando un códec, como G.711 o G.729 con compresión de voz. Durante la fase de transmisión, los gateways insertan paquetes de voz dentro de paquetes de datos y

envían estos últimos, uno por uno fuera de la red. Los anchos de banda de los enlaces entre routers

CCNP ONT

21individuales no usan TDM en circuitos separados sino que simplemente son circuitos de alto ancho de banda, portando paquetes IP desde varios dispositivos. Como se muestra en la figura, los paquetes de voz y datos comparten la misma ruta y los mismos enlaces. Los paquetes de voz entran a la red de forma periódica. Sin embargo, los paquetes pueden llegar a su destino a tiempos diferentes. Cada paquete encuentra diferentes retrasos en la ruta al destino, y los paquetes pueden tomar diferentes rutas al mismo destino. La condición donde la llegada de los paquetes varía, a tasas impredecibles es conocida como jitter. Para que la voz pueda escucharse correctamente, se deben reinsertar los intervalos de tiempo correctos y asegurarse que los paquetes llegan en orden. Cuando se completa la llamada, el gateway que finaliza la misma (el que primero cuelgue) cierra de forma lógica la llamada y detiene el envío de paquetes de voz dentro de la red.

2.3.3 Protocolos usados en la encapsulación de voz Aplicaciones en tiempo real, como voz y vídeo, requieren una conexión garantizada con características de retardo consistentes y predecibles. IP no garantiza confiabilidad, control de flujo, detección de errores o corrección de errores. El resultado es que los paquetes pueden llegar al destino fuera de secuencia o con errores, o directamente no llegar. Existen 2 protocolos de transporte disponibles para superar las debilidades inherentes de IP: TCP y UDP. El tiempo que los dispositivos requieren para reensamblar los paquetes es importante. Por ejemplo, el jitter viene de una variación en los tiempos de retardo que experimentan los paquetes en el stream de datos. Para reducir los efectos del jitter, la VoIP puede memorizar (buffer) datos en el extremo final del enlace para que los datos se produzcan de forma constante. Estas tareas son realizadas por 2 protocolos:

- RTP (REAL-TIME PROTOCOL): Transporta las muestras digitalizadas de información en tiempo real. - RTCP (RTP CONTROL PROTOCOL): Provee reacciones basadas en la calidad del enlace de transmisión.

RTP tiene otra función importante: reordenar los paquetes. En una red IP, los paquetes pueden llegar en un orden diferente que en el que se transmisión. Las aplicaciones a tiempo real deben saber el tiempo relativo de la transmisión del paquete. RTP coloca una marca horaria a cada paquete para proveer los siguientes beneficios: Los paquetes pueden ser correctamente reordenados / Los paquetes

pueden tener retardos apropiados insertados. Antes que un dispositivo VoIP pase el payload del paquete a la aplicación, el dispositivo debe asegurarse del orden correcto de los paquetes. Aunque TCP también realiza esta función, la transmisión de voz no necesita la función de retransmisión, y el ancho de banda adicional utilizado por una cabecera TCP hace ineficiente dicha opción. Debido a que UDP y RTP usan cabeceras reducidas, estos protocolos no proveen un transporte fiable. Un dispositivo VoIP puede tener múltiples llamadas activas. El dispositivo debe seguir que paquete pertenece a cada uno. Para ello, se usan números de puerto UDP para identificar a que llamada pertenece cada paquete. Durante el establecimiento de llamada, el dispositivo VoIP negocia los números de puerto UDP para cada llamada y se asegura de que los mismos sean únicos para las llamadas actualmente activas. Los números de puerto usados por RTP oscilan en el rango de 16384 a 32767.

2.3.4 Códecs de encapsulación de voz Los dispositivos VoIP encapsulan la voz dentro de RTP y UDP antes de añadirles la cabecera IP. El tamaño del paquete VoIP depende del códec utilizado y del total de voz que se está empaquetando. El tamaño de las muestras puede variar, pero para la voz, el payload máximo que puede enviarse es de unos 20 ms. La selección de la duración de este payload es un compromiso entre los requisitos de ancho de banda y la calidad. Payloads más pequeños requieren mayor ancho de banda ya que cada paquete usa 40 octetos de cabeceras. Sin embargo, si los payloads son más grandes, el retardo total de la llamada se incrementa, y el sistema es más susceptible de perder paquetes individuales por la red.

En la figura se ven muestras de voz encapsuladas en un paquete IP con UDP y RTP. Cada muestra usa un códec diferente, y se basa en la presunción de 20 ms por paquete. Cuando las señales analógicas se digitalizan usando G.711, 20 ms de voz

consisten en 160 muestras, con 8 bits por muestra. El resultado es 160 bytes de información de voz. Estos 160 bytes se encapsulan con una cabecera RTP (12 bytes), una cabecera UDP (8 bytes) y una cabecera IP (20 bytes). Por ello, el paquete IP completo usando G.711 tiene un tamaño de 200 bytes. En contraste, 20 ms de voz usando el códec G.729 consisten en 160 muestras, agrupadas en 10 muestras escritas con un código de 10 bits. El resultado es 160 bits (20 bytes) de información de voz. El tamaño completo del paquete con cabeceras resultará en 60 bytes.

CCNP ONT

22

2.3.5 Reducción de la carga con cRTP La carga combinada de IP, UDP y RTP es enormemente alta, especialmente debido a que los paquetes de voz viajan en paquetes relativamente pequeños y a altas velocidades. G.729 necesita para una llamada unos 24 Kbps. G.711 requiere para una llamada 80 Kbps.

La compresión de cabecera RTP (cRTP) reduce la enorme carga de ancho de banda usada por las cabeceras IP, UDP y RTP. El nombre de este proceso puede ser engañoso, ya que cRTP no sólo comprime la cabecera RTP, sino también las cabeceras IP y UDP.

cRTP se configura en una base enlace por enlace. Es posible usar cRTP en algunos enlaces dentro de la red IP. Cuando se configura cRTP un router que recibe un paquete cRTP en una interfaz y enruta el paquete a otra tiene que descomprimir el paquete en la primera interfaz y comprimir el paquete de nuevo en la segunda. cRTP comprime las cabeceras IP, UDP y RTP de 40 bytes a 2 bytes, si el checksum UDP no se conserva (esta es la configuración por defecto en dispositivos Cisco) y a 4 bytes si se conserva dicho checksum. cRTP es especialmente beneficioso cuando el tamaño del payload RTP es pequeño, por ejemplo, cuando se comprimen payloads de audio de entre 20 y 50 bytes (recordar que el problema era que si se enviaban paquetes más pequeños se ocupaba un mayor ancho de banda con las cabeceras). cRTP trabaja con la premisa de que la mayoría de los campos IP, UDP y RTP no cambian o que el cambio es predecible. Los campos estáticos en las cabeceras incluyen IP origen y destino, puertos UDP origen y destino y otros campos adicionales. La compresión RTP usa los siguientes procesos: Condición Acción

El cambio es predecible El emisor sigue el cambio predicho El cambio predicho es seguido El emisor envía un hash de la cabecera El receptor predice que se producirá un cambio

El receptor sustituye la cabecera original almacenada y calcula los campos que cambian

Existe un cambio inesperado El emisor envía la cabecera completa sin compresión

2.3.6 Cuando usar compresión de cabeceras RTP Quitando las ventajas, existen ciertas desventajas a considerar antes de habilitar cRTP. Debemos considerar los siguientes factores:

- Usaremos cRTP cuando necesitemos conservar ancho de banda en nuestros enlaces WAN, pero sólo lo habilitaremos en enlaces lentos (de menos de 2 Mbps).

- Consideraremos las siguientes desventajas: o cRTP añade una sobrecarga de procesamiento. Deberemos chequear los recursos

disponibles en los routers antes de habilitar cRTP. o cRTP introduce retardos adicionales debido al tiempo que tarda en realizar la compresión y

descompresión. - Afinaremos cRTP para limitar el número de sesiones que se comprimen en la interfaz. Por defecto

son 16 sesiones. Si la CPU de nuestro router no puede gestionar 16 sesiones, debemos reducir el número de sesiones cRTP. Si el router tiene suficiente CPU y queremos comprimir más de 16 sesiones en un enlace, configuraremos el parámetro a un valor superior.

2.4 Cálculo de los requisitos de ancho de banda para VoIP

2.4.1 Impacto del tamaño de las muestras y del tamaño del paquete en el ancho de banda Cuando un dispositivo VoIP envía voz sobre redes por paquetes, el dispositivo encapsula la información de voz digitalizada dentro de paquetes IP. Esta carga de encapsulación requiere un ancho de banda extra, determinado por los siguientes elementos:

- TASA DE PAQUETES: La tasa de paquete especifica el número de paquetes que se envían en un intervalo de tiempo dado. La tasa de paquete es especificada normalmente en paquetes por segundo (pps). El periodo empaquetado es el total de tiempo de voz que será encapsulado por paquete, y se especifica normalmente en milisegundos.

- TAMAÑO DE PAQUETE: Especifica el número de bytes que son necesarios para representar la información de voz que será encapsulada por paquete. El tamaño de paquete depende del periodo empaquetado y del ancho de banda utilizado por el códec.

- CARGA IP: Número de bytes añadidos a la información de voz durante la encapsulación IP. Es la suma de la carga añadida por los encabezados RTP, UDP e IP.

- CARGA DEL ENLACE DE DATOS: Especifica el número de bytes añadidos durante la encapsulación de capa 2. La carga de enlace de datos depende el protocolo de capa 2 usado, que puede ser diferente para cada enlace.

CCNP ONT

23- CARGA DE TUNNELING: Especifica el número de bytes añadidos por cualquier protocolo de seguridad o

de tunneling, como IPsec, GRE o MPLS. Esta carga debe considerarse en todos los enlaces entre el origen y el destino.

- CODECS: en la siguiente figura vemos el ancho de banda utilizado por cada códec, lo cual es otro factor a tener en cuenta a la hora de decidir que códec de audio utilizar en la organización.

2.4.2 Período empaquetado En dispositivos VoIP, podemos especificar, además del códec, el total de voz que se encapsulará por paquete. Normalmente, este valor es configurado por el periodo empaquetado en milisegundos. Un periodo empaquetado mayor resulta en un tamaño de paquete más grande, puesto que el payload es mayor. Sin embargo, este periodo mayor empaquetado resulta en una tasa de paquetes reducida, reduciendo la carga IP puesto que se generan menos paquetes.

En la figura se contrastan 2 escenarios con diferentes períodos de empaquetado. En el primero, se empaquetan porciones de 20 ms de voz (160 muestras PCM). Si el empaquetado se realiza cada 20 ms es igual que se generan 50 paquetes por segundo. Para un total de 60 ms de voz, se necesitan 3 paquetes, cada uno con 20 ms de voz. Por ello, el empaquetado de estos 60 ms de voz incluye una carga adicional de 3 cabeceras IP, UDP y RTP. En el segundo escenario, se empaquetan partes de 30 ms de voz (240 muestras PCM). Este empaquetado resulta en una tasa menor de paquete de 33.3 paquetes por segundo (pps). Para cada 60 ms. De voz, sólo se generan 2 paquetes, por lo que la carga IP se redunde en una tercera parte en comparación con el primer escenario. El valor por defecto de empaquetado es la mayoría de los dispositivos VoIP Cisco es de 20 ms. Este valor es el valor óptimo por defecto para la mayoría de los escenarios. Si consideramos aumentar este valor para beneficiarnos de una carga IP menor, debemos considerar que un período de empaquetado mayor causará un mayor retardo. Este retardo extra se introduce durante el empaquetado ya que se tiene que recolectar más información de voz antes de que el paquete se genere y se envíe.

En la figura se muestran ejemplos de encapsulaciones VoIP con los códecs utilizados y los períodos de empaquetado. Como podemos ver, un período de empaquetado mayor incrementa el tamaño del paquete IP mientras reduce la cantidad de paquetes. En la tabla, la carga IP se asume como de 40 bytes. Este valor es el valor normal de paquetes VoIP compuestos por 20 bytes de la cabecera IP, 8 bytes de la cabecera UDP y 12 bytes de la cabecera RTP. Si se usa cRTP la carga IP disminuye. Nota: Aparte, habría que sumarle la carga de la capa de enlace de datos que aquí no se incluye.

CCNP ONT

24

2.4.3 Carga de Enlace de datos Cuando un dispositivo VoIP envía paquetes sobre un enlace dentro de una red IP, el dispositivo encapsula los paquetes usando el protocolo de capa 2 que utilice ese enlace. Cada enlace puede usar un protocolo de capa 2 diferente. Imaginemos 2 teléfonos IP comunicándose entre ellos a través de una red Frame Relay. Antes de que el teléfono transmisor envíe un paquete VoIP dentro de la LAN, el teléfono tiene que encapsular el paquete en una trama Ethernet. El router que recibe la trama elimina la cabecera Ethernet y encapsula el paquete VoIP en Frame Relay antes de enviarlo a la WAN. El router receptor realiza el proceso inverso. La cabecera Ethernet y la cabecera Frame Relay difieren en su tamaño. La carga Ethernet es de 18 bytes (22 para tramas 802.1Q), y la de Frame Relay es de 6 bytes (al igual que la PPP). Cuando calculamos el ancho de banda de una llamada VoIP para un enlace en concreto, debemos considerar la carga apropiada del protocolo de capa 2.

2.4.4 Carga de Seguridad y de Tunneling Los paquetes IP, y consecuentemente los VoIP, pueden ser asegurados usando IPsec. Existen 2 modos IPsec: Transporte y Túnel. En cualquiera de los 2 modos, los paquetes pueden protegerse con las cabeceras AH y ESP (ya se una o ambas). En el modo túnel, se genera una cabecera IP adicional, permitiendo el uso de VPN. De forma adicional, los paquetes IP pueden ser tuneleados sobre una amplia variedad de protocolos, como los siguientes: GRE, L2F, L2TP, PPPoE o 802.1Q. El agregado de la cabecera de tunneling incrementa el tamaño del paquete original, resultando en unas necesidades de ancho de banda mayores, siendo especialmente dedicado en el transporte de paquetes VoIP, debido a las altas tasas de transmisión de paquetes de pequeño tamaño.

2.4.5 Cabeceras Extra de Protocolos de Seguridad y Tunneling Las cabeceras IPsec y de protocolos de tunneling tienen diferentes tamaños. La carga IPsec depende del uso de AH o ESP, el algoritmo de cifrado o autenticación usado y del modo IPsec (transporte o túnel). ESP es usado de forma más habitual ya que permite el cifrado de los datos. La cabecera ESP, usando DES o 3DES para el cifrado, y MD5 o SHA-1 para la integridad, añade de 30 a 37 bytes en el modo transporte. Cuando se usa AES como algoritmo de cifrado y AES-XCBC para la autenticación, se añaden de 38 a 53 bytes en el modo de transporte. En modo túnel, se deben añadir a los cálculos anteriores 20 bytes más de una nueva cabecera IP. L2TP o GRE añaden 24 bytes a la trama original PPP. MPLS añade 4 bytes al paquete IP original y PPPoE añade una cabecera de 8 bytes PPPoE extra entre la trama Ethernet y el paquete IP.

2.4.6 Cálculo del ancho de banda total para una llamada VoIP Cuando se diseñan redes para VoIP, es crucial saber el ancho de banda total de una llamada VoIP necesita utilizar. Esta información se necesita para determinar la capacidad del los enlaces físicos y desplegar un QoS y un CAC correcto. CAC limita el número de llamadas simultáneas de voz. Este límite previene la saturación del enlace, causando degradación de la calidad de las llamadas. QoS entrega prioridad a los paquetes de voz, previendo que se forme colas con altos retardos, lo cual afectaría a la calidad de la voz. Para calcular el ancho de banda total de una llamada VoIP, seguiremos los siguientes pasos:

- PASO1: Almacenar la información de empaquetado requerida. Primero, debemos determinar el ancho de banda del códec que se usa para digitalizar las señales analógicas. El ancho de banda del códec se especifica en Kbps y está normalmente en el rango de 8 a 64 Kbps. Necesitaremos también el período de empaquetado (en ms) o el tamaño de empaquetado (en bytes). Si tenemos el ancho de banda del coden y uno de estos otros 2 valores, podemos calcular el valor restante.

- PASO2: Almacenar la información del enlace requerida. La carga total que será añadida por paquete en cada enlace es la siguiente parte de información necesaria. Esta carga depende de si se usa o no cRTP, del protocolo de capa 2 en uso, y de la carga de cada protocolo de capa 2 por paquete. IP, UDP y RTP tienen una carga de 40 bytes, sin el uso de cRTP. Con cRTP, la carga es de 2 a 4 bytes. Debemos asegurarnos de incluir la carga en bytes del protocolo de capa 2 en uso. Finalmente, debemos saber si existen otras prestaciones que causen una carga adicional y cuanta carga supone la misma. Como prestaciones adicionales tenemos seguridad, como VLANs, IPsec o aplicaciones de tunneling.

- PASO3: Calcular el tamaño de empaquetado o el período. Dependiendo del dispositivo de voz, debemos saber el período de empaquetado o el tamaño de empaquetado (determinado en el paso 1). Calcular la información perdida basándonos en el valor conocido más el ancho de banda del códec, también obtenido en el paso 1. El tamaño de empaquetado se expresa en bytes y el período de empaquetado en ms.

- PASO4: Añadir juntos el tamaño de empaquetado y todos las cabeceras y trailers. Añadir la carga IP, UDP y RTP (o cRTP), protocolo de capa 2, y cualquier otro protocolo que anotáramos en el paso 2 al payload de la voz (tamaño de empaquetado). Todos los valores deben ser en bytes.

- PASO5: Calcular la cantidad de paquetes. Calcular cuántos paquetes serán enviados por segundo usando la multiplicación inversa del período de empaquetado. Debido a que la tasa de paquetes se

CCNP ONT

25especifica en paquetes por segundo, debemos asegurarnos de convertir el valor en ms al período de empaquetado por segundos.

- PASO6: Calcular el ancho de banda total. Multiplicar el tamaño total de paquete o trama por la tasa de paquete para calcular el ancho de banda. Debido a que el tamaño de paquete se expresa en bytes y el ancho de banda en kpbs, necesitamos convertir bytes a kilobits.

Basándonos en este procedimiento, podemos calcular el ancho de banda usado por una llamada VoIP en un enlace específico. Para el planteamiento de los enlaces físicos, consideraremos el número máximo de llamadas que se supone podría realizarse y el ancho de banda necesario para otras aplicaciones diferentes a VoIP. A su vez, debemos asegurarnos que exista suficiente ancho de banda para las señales de “call setup” y “call teardown”. Siguiendo los pasos del procedimiento de cálculo del ancho de banda, usaremos la siguiente fórmula: BANDWIDTH [EN KBPS] = (TAMAÑO PAQUETE TOTAL [EN BYTES POR PAQUETE] * 8/1000)*TASA DE PAQUETE [EN PPS]. Multiplicamos el tamaño de paquete total x 8 y /1000 para convertir los bytes a Kbps.

- CÁLCULO DEL TAMAÑO DE PAQUETE TOTAL: Usaremos la siguiente fórmula: TAMAÑO DE PAQUETE TOTAL [EN BYTES POR PAQUETE] = CARGA DE CAPA 2 [EN BYTES POR PAQUETE] + OTRA CARGA [EN BYTES POR PAQUETE] + CARGA IP [EN BYTES POR PAQUETE] + TAMAÑO DE EMPAQUETADO [EN BYTES POR PAQUETE].Si no conociéramos el tamaño de empaquetado, usaríamos la siguiente fórmula: TAMAÑO DE EMPAQUETADO [EN BYTES POR PAQUETE] = (PERÍODO DE EMPAQUETADO [EN MS POR PAQUETE] / 1000) * ANCHO DE BANDA DEL CÓDEC [EN KBPS]*1000/8. Debido a que el tamaño de empaquetado está en bytes y el ancho de banda del códec está en kilobits por segundo, convertimos el ancho de banda del códec multiplicándolo por 1000 y dividiéndolo entre 8. Además, debido a que las unidades en el ancho de banda del códec (Kbps) y el período de empaquetado (ms por paquete) no son las mismas, el período de empaquetado tiene que convertirse multiplicando al mismo por 1000.

- CÁLCULO DE LA TASA DE PAQUETE: La tasa de paquetes, especificada en pps, es la multiplicación inversa del período de empaquetado, el cual se especifica en ms por paquete. Por ello, debemos convertir de ms a segundos para obtener un valor recíproco: TASA DE PAQUETES [EN PPS] = 1 / (PERÍODO DE EMPAQUETADO [EN MS PP] / 1000). En ocasiones, no sabremos el período de empaquetado (ms pp), sino el tamaño de empaquetado. En algunos dispositivos, se configura el tamaño en lugar el período. Cuando esto suceda, calcularemos el período de empaquetado primero usando las siguiente fórmula: PERÍODO DE EMPAQUETADO [EN MS PP] = (TAMAÑO DE EMPAQUETADO [EN BYTES PP]*8/1000) / (ANCHO DE BANDA DEL CÓDEC [EN KBPS] / 1000).

Sumario: Asumiendo que conocemos el período de empaquetado (en ms pp), las fórmulas para calcular el ancho de banda total se simplifican en: ANCHO DE BANDA [EN KBPS] = (8 * (CARGA CAPA 2 [EN BYTES PP] + OTRAS CARGAS [EN BYTES PP] + CARGA IP [EN BYTES PP] + PERÍODO DE EMPAQUETADO [EN MS PP] * ANCHO DE BANDA DEL CÓDEC [EN KBPS])/ PERÍODO DE EMPAQUETADO [EN MS PP]. Si, en lugar del período de empaquetado se conoce el tamaño de empaquetado (en bytes pp), usaremos la siguiente fórmula: ANCHO DE BANDA (EN KBPS) = (ANCHO DE BANDA DEL CÓDEC [EN KBPS] / TAMAÑO DE EMPAQUETADO [EN BYTES PP])*(TAMAÑO DE EMPAQUETADO [EN BYTES PP] + CARGA CAPA 2 [EN BYTES PP] + OTRAS CARGAS [EN BYTES PP] + CARGA IP [EN BYTES PP]).

2.4.7 Cálculo de ancho de banda rápido En la figura se muestra una forma rápida de calcular el ancho de banda total cuando se da el tamaño de empaquetado. El tamaño del payload depende del intervalo de muestra y el códec utilizado, siendo normalmente de 20 bytes para G.729 y 160 bytes para G.711, asumiendo intervalos de muestras de 20 ms. Las cabeceras siempre son de 40 bytes con IP, UDP y RTP, más la cabecera del protocolo de capa 2. En nuestro caso, está es de 6 bytes ya que se usa Frame Relay como protocolo de capa 2. El resultado es de un ancho de banda por llamada de 26.4 kbps,

tomando como códec G.729, como vemos en la figura. Existen calculadoras en red que nos permiten realizar este cálculo de forma automatizada, dándole solamente los valores que aparecen en la fórmula de la figura.

CCNP ONT

26

2.4.8 Efectos de VAD en el ancho de banda En una red telefónica switcheada, debido a la naturaleza de la red, el ancho de banda de una llamada está permanentemente disponible y dedicado a esa llamada. No hay forma de aprovecharse de las pausas de voz, las transmisiones de audio de una vía o cosas similares cuando un enlace no está siendo usado. En una red de paquetes, sin embargo, la VAD (Voice Activity Detection) puede tomar ventaja del hecho de que un tercio de la media de la llamada consiste en silencios. VAD detecta el silencio causado, por ejemplo, por pausas de voz o por transmisiones de una vía, mientras un usuario está oyendo una melodía de espera (Music on Hold – MoH) cuando está siendo transferido. VAD suprime la transmisión del silencio y, por tanto, salvaguarda ancho de banda. El total de ancho de banda salvado por VAD depende de varios factores:

- TIPO DE AUDIO: Durante una conversación humana, las 2 partes generalmente no hablan a la vez. Cuando se ejecuta MoH, la llamada normalmente se vuelve de una vía. La persona que escucha la música no envía ningún audio y no tienen que transmitirse paquetes mientras que la llamada está en espera.

- NIVEL DE RUIDO DE FONDO: VAD necesita detectar silencio para ser capaz de suprimir los silencios. Si el fondo es demasiado ruidoso, VAD no podrá detectar silencio y continuará la transmisión.

- OTROS FACTORES: Las diferencias en el lenguaje y el carácter de los interlocutores tienen un impacto en el total de silencio detectado en una llamada. Algunas llamadas, como conferencias o difusiones donde sólo uno de los pocos participantes habla y la mayoría de los demás escucha, permite un mayor ahorro de ancho de banda que otro tipo de llamadas.

Como media, VAD permite el ahorro de alrededor a un 35 % del ancho de banda. En la figura se muestra una estadística según varios factores.

2.5 Implementación de VoIP en una red empresarial

2.5.1 Implementaciones empresariales de Voz Los gateways interconectan a sistemas de telefonía tradicional, como teléfonos analógicos o digitales,

PBX o la PSTN. En la figura se muestra una compañía con el HQ en Chicago, 2 oficinas en San Francisco, y una pequeña en Dallas. En Chicago, existen 3 HQ que se conectan mediante una MAN. La oficina principal de West Coast de San Francisco se conecta con la de San Jose mediante una MAN. Dallas tiene una única oficina en su distrito. Las 3 localizaciones principales de la compañía

(Chicago, San Francisco y Dallas) se conectan mediante una WAN IP. Las 3 localizaciones tienen cada una un clúster Cisco Unified CallManager sirviendo a los teléfonos IP locales y a los teléfonos IP localizados en los sitios MAN interconectados. En el campus “Airport” en Chicago, los teléfonos IP no se usan ya que la compañía está usando un servicio de gestión telefónica ofrecido por el propietario del edificio. Sin embargo, un gateway de voz se conecta a la PBX, permitiendo llamadas VoIP hacia y desde la oficina Airport a través del gateway. Además, cada sitio tiene un gateway de voz que conecta a la PSTN, permitiendo llamadas “fuera de la red”. Estos routers gateway se equipan con DSPs que proveen recursos de conferencia y “transcoding”. Dentro de cada área, se usa el códec G.711, mientras que las llamadas entre las 3 áreas usan el códec G.729. Si la WAN IP falla, o si las llamadas se deniegan por CAC, las llamadas se re-enrutan a través de la PSTN.

CCNP ONT

27

2.5.2 Despliegue de CAC La telefonía IP ofrece CAC para limitar el número de llamadas de voz simultáneas permitidas de forma que previene la extenuación de los recursos WAN. Sin CAC, si se activan demasiadas llamadas y se envía demasiado tráfico de voz a la vez, pueden producirse retardos y borrado de paquetes. Aún dando a los paquetes RTP una prioridad absoluta sobre los demás tipos de tráfico no eliminamos el problema de que el ancho de banda total físico del enlace sea suficiente para los paquetes de voz, puesto que todos los paquetes RTP se tratan por QoS de la misma forma (no se puede dar más prioridad a ciertos paquetes RTP).

En la figura, existe un escenario con 2 sitios y 3 teléfonos en cada sitio conectados a un gateway VoIP a través de una PBX. Los 2 gateways se conectan mediante una red IP. La red se ha diseñado para permitir un máximo de 2 llamadas simultáneas. SI no se usa CAC, en cualquier momento en el existan 3 llamadas

activas, las 3 llamadas experimentarán severas degradaciones en la calidad de la voz. Cuando se usa CAC, el gateway se configura para permitir no más de 2 llamadas a la vez. Cuando se intenta la tercera llamada, la misma se bloquea. Con su uso, no se deben experimentar problemas de calidad.

2.5.3 Funciones del Gateway de Voz en un router Cisco Los routers Cisco, especialmente los ISR, pueden equiparse con interfaces de telefonía tradicional para actuar como gateways para dispositivos analógicos y digitales, incluyendo teléfonos, faxes, PBX y PSTN, permitiendo a los mismos interactuar con redes VoIP. Los gateways con interfaces analógicas convierten las señales analógicas a un formato digital antes de encapsular la voz dentro de paquetes IP. Pueden comprimir la voz digitalizada antes de que se produzca la encapsulación. Esta compresión reduce el ancho de banda necesario para cada llamada. Los routers Cisco soportan H.323, SIP y MGCP para la señalización de la voz. Además, los gateways pueden equiparse con DSPs, donde se proveen recursos de conferencia y transcoding. En entornos de telefonía IP, los gateways pueden soportar escenarios de fallo para teléfonos IP que pierden la conectividad IP con su “call agent” (CallManager). Esta prestación, llamada SRST (Cisco Survivable Remote Site Telephony) habilita al gateway a tomar el rol del agente de llamada durante un fallo WAN. Las llamadas locales pueden realizarse aún si se ha perdido la conectividad con el CallManager. Además, los routers Cisco IOS pueden actuar permanentemente como un agente de llamada para teléfonos IP. La prestación que provee esta funcionalidad es “Cisco Unified CallManager Express”. El router provee funciones de CallManager. Si el router es también un gateway de voz, el router combina funciones de telefonía IP y gateway VoIP en un único chasis.

2.5.4 Funciones de Cisco Unified CallManager Cisco Unified CallManager es una PBX basada en IP. Actúa como agente de llamada para teléfonos IP y gateways MGCP y puede interactuar con dispositivos H.323 o SIP. Se puede realizar un clúster de múltiples servidores Cisco Unified CallManager con propósitos de balanceo de carga y redundancia. Las 6 funciones principales realizadas por Cisco Unified CallManager son:

- PROCESAMIENTO DE LLAMADA: Procesa llamadas entre dispositivos finales y gateways. El procesamiento incluye decisiones de enrutamiento de llamada, señalización entre los dispositivos afectados y auditoría de llamadas. Además, se pueden configurar CoS (clase de servicio) y gestión de ancho de banda para influenciar el procesamiento de las llamadas.

- ADMINISTRACIÓN DEL PLAN DE MARCADO: Actúa como un agente de llamadas para los teléfonos IP y los gateways MGCP eliminando la necesidad de tablas de enrutamiento locales en estos dispositivos. Sólo el call agent (lo que sería el Cisco Unified CallManager) necesita saber el plan de marcado. Esto significa que todo el plan de administración de marcado se realiza en el Cisco Unified CallManager.

- SEÑALIZACIÓN Y CONTROL DE DISPOSITIVOS: En el rol de call agent, el Cisco Unified CallManager controla teléfonos IP y gateways MGCP diciendo a estos dispositivos qué hacer en ciertos eventos. Por ejemplo, cuando un teléfono IP informa al Cisco Unified CallManager que el usuario ha descolgado el teléfono, el Cisco Unified CallManager le dice al teléfono IP que actualice la pantalla y le dé un tono de marcado.

- ADMINISTRACIÓN DE PRESTACIONES DEL TELÉFONO: La configuración completa del teléfono IP se ingresa y almacena en el Cisco Unified CallManager. El teléfono IP carga su fichero de configuración durante el arranque. La administración de teléfonos IP está totalmente centralizada.

- SERVICIOS DE DIRECTORIO Y XML: El Cisco Unified CallManager provee acceso a directorios. Los teléfonos IP pueden usarse para realizar búsquedas en directorios disponibles. También, los teléfonos IP pueden usarse como aplicaciones conscientes de XML.

CCNP ONT

28- PROGRAMACIÓN DE INTERFAZ PARA APLICACIONES EXTERNAS: A través de una interfaz programada, las

aplicaciones externas pueden integrarse con la solución telefónica del Cisco Unified CallManager. Ejemplos de ello son la aplicación de PC “Cisco IP Communicator”, “Cisco IP Interactive Voice Response (IVR)”, Cisco Personal Assistant, y la consola Cisco Unified CallManager Attendant. El “Cisco IP Communicator” es un teléfono virtual, representado por una pantalla interactiva en un PC.

En la figura se muestra una compañía utilizando Cisco Unified CallManager. La compañía tiene 2 sitios: HQ y una oficina. Un clúster Cisco Unified CallManager se localiza en el HQ. Cada sitio tiene un gateway de voz para el acceso a la PSTN. En el ejemplo, un usuario en la oficina “branch” quiere hacer una llamada a un usuario localizado en HQ. El proceso de la llamada sería

el siguiente: - PASO1: Cuando el usuario de la sucursal marca el número de teléfono, el teléfono IP envía un

mensaje de señalización a un miembro del clúster Cisco Unified CallManager. - PASO2: El servidor Cisco Unified procesa la llamada buscando el número marcado en la tabla de

enrutamiento de llamadas Cisco Unified CallManager. - PASO3: Cuando el servidor Cisco Unified CallManager determina la dirección IP del teléfono de

destino, envía un mensaje de señalización al teléfono de destino. El teléfono de destino comienza a sonar, y el usuario al que se está llamando puede aceptar la llamada.

- PASO4: Una vez aceptada, el teléfono comienza a enviar y recibir paquetes RCP que portan señales de aucio.

2.5.5 Modelos de despliegue de telefonía IP empresariales SITIO ÚNICO: Una empresa puede desplegar una solución VoIP en un único sitio. En este caso, hay un cluster Cisco Unified que sirve sólo a teléfonos locales.

MULTISITIO CON PROCESAMIENTO DE LLAMADA CENTRALIZADO: La empresa puede desplegar una solución VoIP en múltiples sitios con un procesamiento de llamada centralizado. Con este modelo, existe un único clúster Cisco Unified que se localiza en uno de los sitios. El clúster Cisco Unified sirve a los teléfonos locales y remotos.

MULTISITIO CON PROCESAMIENTO DE LLAMADA DISTRIBUIDO: La empresa puede desplegar una solución de telefonía IP en múltiples sitios con un procesamiento de llamada distribuido. Con este modelo, hay un clúster Cisco Unified en cada sitio. Cada clúster Cisco Unified sirve a los teléfonos IP locales.

CCNP ONT

29CLUSTERS SOBRE WAN: Una empresa puede desplegar una solución VoIP en múltiples sitios. En este despliegue, los servidores Cisco Unified se localizan en más de un sitio. Sin embargo, todos los servidores pertenecen a un clúster único. Los miembros de este clúster se separan por una WAN IP. Los teléfonos IP normalmente usan el servidor local como su agente de llamada. En este

modelo se requiere que exista un retardo no mayor a 40 ms entre cada pareja de servidores.

2.5.6 Configuración Cisco IOS para VoIP Los routers Cisco pueden usarse como gateways VoIP. Para una configuración VoIP básica, se necesitan 2 gateways. Ambos necesitan una conexión a un dispositivo de teléfono tradicional, como un teléfono analógico. Los gateways tienen que tener conectividad IP.

En la figura, el primer router tiene estas configuraciones: Nombre R1 // IP: 10.1.1.1/24 // Interfaz IP: Fa 0/0 // Puerto de voz: 1/0/0 // Extensión del teléfono conectado al puerto de voz: 1111. En el segundo router, las configuraciones son similares: Nombre R2 // IP: 10.2.2.2/24 // Interfaz IP: FA 0/0 // Puerto de voz: 1/0/0 // Extensión del teléfono conectado al puerto de voz: 2222. Un dial-peer describe donde encontrar un número de teléfono, y la colección de dial peers forma la tabla de enrutamiento de llamadas de un gateway de voz. Dos tipos de dial peers se muestran en este ejemplo: pares de llamada POTS y pares de llamada VoIP. POTS indica que el número de teléfono especificado en el dial-peer se encuentra en un puerto físico. Un dial peer VoIP se refiere a la IP del dispositivo VoIP. Comando Descripción

Dial-peer voice <etiqueta> <tipo> Ingresamos al modo de subconfiguración de dial peer. El valor de etiqueta es un número que ha de ser único para todos los dial peers dentro del mismo gateway. El valor del tipo indica el tipo de dial peer (POTS o VoIP).

Destination-pattern <nº teléfono> Ingresado en el submodo dial peer, define el número de teléfono que se le aplica al dial peer. Una llamada enviada a este número se enruta de acuerdo al tipo de configuración y de puerto (en el caso de un dial peer tipo POTS) o sesión objetivo (en el caso de un dial peer del tipo VoIP) del dial peer.

Número de Puerto El comando port, ingresado en el submodo POTS del submodo dial peer define el número de puerto que se aplica al dial peer. Las llamadas que se enrutan usando este dial peer se envían al puerto especificado. Este comando se usa sólo en dial peers POTS.

Session target ipv4: <dirección IP> Ingresado en el modo de subconfiguración de dial peer en VoIP, defina la IP del dispositivo VoIP

CCNP ONT

30

objetivo que se aplica al dial peer. Las llamadas que se enrutan usando este dial peer se envían a la dirección IP especificada. Este comando sólo puede configurarse en dial peers de VoIP.

CCNP ONT

31

Tema 3. Introducción a QoS IP

3.1 Introducción a QoS

3.1.1 Tareas de calidad en redes convergentes Antes de que la convergencia de red fuera algo común, la ingeniería de red se centraba en la conectividad. En las redes de datos se pueden dar “olas” de información. Por ejemplo, cuando recibimos un e-mail, generalmente no se percibe un retraso de unos pocos segundos. Un retraso de varios minutos puede ser molesto, pero no serio. Cada aplicación tiene características diferentes de tráfico y de requisitos. En una red convergente, constante, pequeños paquetes de voz fluyen compitiendo con olas de flujos de datos. Aunque los paquetes de voz son típicamente muy pequeños, éstos no toleran retrasos o variaciones, donde la voz que portan puede ser incomprensible en el destino. Por el contrario, los paquetes que portan archivos son típicamente grandes y la naturaleza de IP les permite retrasos e inclusive pérdidas. Las redes convergentes deben proveer seguridad y servicio garantizado. Los administradores de red y arquitectos logran el funcionamiento requerido gestionando los retardos, variaciones de los retardos (jitter), aprovisionamiento de ancho de banda y técnicas QoS. Los streams multimedia, como los usados en VoIP o videoconferencia son muy sensibles a demoras de entrega y crean demandas QoS únicas. Si el proveedor de servicio se basa en una red de mayor esfuerzo, los paquetes pueden no llegar en orden o de forma oportuna. El resultado son imágenes distorsionadas, movimientos lentos y sonido no sincronizado con la imagen.

3.1.2 Tareas de calidad en redes convergentes Los retardos causan una interactividad en la llamada pobre, la cual causa eco y superposición de interlocutores. El eco es el efecto del reflejo de la señal de voz emitida por un interlocutor volviendo por el altavoz del mismo. La superposición de interlocutores se causa cuando se producen retardos de una vía mayores a 250 ms. La peor causa del retardo es la desconexión de una llamada. Si existen interrupciones en el habla, alguna de las 2 partes colgará la llamada. Si existen problemas de señalización, la llamada se desconectará. Las redes convergentes empresariales deben realizar 4 tareas mayores:

- CAPACIDAD DE ANCHO DE BANDA: Ficheros de gráficos grandes, usos multimedia y el incremento del uso de voz y vídeo causan problemas de capacidad de ancho de banda en redes de datos.

- RETARDOS DE EXTREMO A EXTREMO (FIJOS Y VARIABLES): El retardo es el tiempo que tarda un paquete en alcanzar al extremo receptor después de transmitirse por el emisor. Este período se conoce como “retardo de extremo a extremo”, y consiste en 2 componentes:

o RETARDO DE RED FIJO: Los 2 tipos de retardos de red fijos son la serialización y los retardos de propagación. La serialización es el proceso de colocar los bits en el circuito. A mayor velocidad del circuito, mayor velocidad del enlace y menos retardo de serialización. El retardo de propagación es el tiempo que tardan las tramas en transmitirse por el medio físico.

o RETARDO DE RED VARIABLE: El retardo de procesamiento es un tipo de retardo variable y es el tiempo requerido por un dispositivo de red en buscar una ruta, cambiar las cabeceras y completar otras tareas de conmutación. En muchos casos el paquete es manipulado, como por ejemplo en el cambio del valor TTL. Cada uno de estos pasos contribuyen en el retardo de procesamiento.

- VARIACIÓN DEL RETARDO (JITTER): El jitter es la diferencia en los valores de retardo totales de extremo a extremo, o de 2 paquetes de voz en el flujo de voz.

- PÉRDIDA DE PAQUETES: La congestión WAN es la causa más común de pérdida de paquetes. En el caso del tráfico de voz, la pérdida de paquetes puede ocasionar pérdidas de habla. Las conversaciones serán difíciles de seguir y la comunicación será confusa.

3.1.3 Medida del ancho de banda disponible En la figura se muestra una red vacía con 4 saltos entre un servidor y un cliente. Cada salto usa un medio diferente con distinto ancho de banda. El ancho de banda total disponible máximo es igual al ancho de banda menor de cualquier enlace en el camino. El cálculo del ancho de banda disponible, sin embargo, es bastante más complejo en casos

donde existen múltiples flujos atravesando la red. Un flujo IP es una serie unidireccional de paquetes IP de un protocolo dado viajando entre un origen y un destino dentro de un período dado. Cuando existen

CCNP ONT

32múltiples flujos, usaremos la siguiente fórmula para calcular la media de ancho de banda disponible por flujo: ANBANDADISPONIBLE = ANBANDAMAX/FLUJOS. Un ancho de banda inadecuado puede tener impactos en el funcionamiento de las aplicaciones de red, especialmente en aquellas que son sensibles al tiempo (como la voz), o que consumen mucho ancho de banda (como la videoconferencia).

3.1.4 Incremento del ancho de banda disponible El ancho de banda es uno de los factores clave que afectan al QoS de una red. Cuanto mayor ancho de banda, mejor QoS. Sin embargo, incrementar solamente el ancho de banda no resuelve necesariamente la congestión y los problemas de flujo. Incrementar el ancho de banda es una solución cara y se tarda tiempo en implementarse. Además, en una red más rápida, el tráfico se incrementará y los problemas volverán.

En la figura se muestra un enfoque más racional usando colas avanzadas y técnicas de compresión. “Queuing” significa clasificar el tráfico dentro de clases QoS y priorizar cada clase de acuerdo a su importancia relativa. El mecanismo de colas básico por defecto es el FIFO (primero en entrar, primero en salir). El tráfico de voz debe recibir un envío prioritario, y el tráfico menos importante debe recibir el ancho de banda no utilizado existente

después de que se ha acomodado al tráfico prioritario. El software QoS Cisco IOS provee varios mecanismos que pueden usarse para asignar prioridades a distintas clases de tráfico: FIFO / Cola Prioritaria (PQ) o Cola Personalizada (CQ) / Déficit Modificado Round Robin (MDRR) / Cola Basada en Tipo de Servicio Distribuido (ToS) y Basada en Grupos QoS (WFQ) / Cola Basada en Clases (CBWFQ) / Cola de Baja Latencia (LLQ). Una forma de incrementar el ancho de banda del enlace es optimizar el uso del mismo usando compresión en el payload o en las tramas. Sin embargo, la compresión incrementa el retardo debido a la complejidad de los algoritmos de compresión. Usar un hardware de compresión puede acelerar la compresión de los payloads de los paquetes. En el IOS se incluyen los métodos Stacker y Predictor. Otro mecanismo para aumentar la eficiencia del ancho de banda de los enlaces es la compresión de las cabeceras. Un ejemplo típico es la compresión de cabeceras TCP y RTP.

En la figura se muestra un ejemplo de cómo usar la eficiencia de ancho de banda utilizando mecanismos de colas y de compresión de cabeceras. En este escenario, un enlace WAN de baja velocidad conecta 2 oficinas. Ambos lugares poseen teléfonos IP, PC’s y servidores que ejecutan

aplicaciones interactivas, como servicios de terminal. Debido a que el ancho de banda disponible es limitado, una estrategia apropiada para usar el ancho de banda de forma eficiente debe ser determinada e implementada.

3.1.5 Efectos del retardo de extremo a extremo y del Jitter El retardo de extremo a extremo es la suma de todos los tipos de retardos. Cada salto en la red tiene su propio conjunto de procesamientos y colas, lo cual puede resultar en variaciones en el retardo (jitter).

El RETARDO DE PROCESAMIENTO depende de los siguientes factores: velocidad de la CPU, uso de la CPU, modo de conmutación IP, arquitectura del router (uso de CEF o no) y prestaciones configuradas en las interfaces de entrada y de salida. El RETARDO DE COLA es el tiempo que un paquete reside en la cola de salida de un router. Depende del número de paquetes que ya están en la cola y del tamaño de los mismos.

El RETARDO DE SERIALIZACIÓN es el tiempo que se tarda en colocar una trama en el medio físico para su transporte. Es normalmente inversamente proporcional el ancho de banda del enlace. El RETARDO DE PROPAGACIÓN es el tiempo que tarda un paquete en atravesar el enlace de un extremo a otro. Depende de si se transmiten datos, voz o vídeo.

CCNP ONT

33 El ITU considera los retardos de red para aplicaciones de voz en el apartado de recomendaciones G.114. Estas recomendaciones definen tres bandas de retardos de una vía, como vemos en la figura.

3.1.6 Reducción del Impacto del retardo en la calidad En la figura se muestra como los administradores pueden acelerar el despacho de paquetes para flujos sensibles a demoras de las siguientes formas: INCREMENTAR LA CAPACIDAD DEL ENLACE: Un ancho de banda adecuado ocasiona colas reducidas y paquetes que no deben esperar mucho para ser transmitidos. PRIORIZAR PAQUETES SENSIBLES A DEMORAS: Este enfoque puede ser más

efectivo a nivel de coste que el anterior. WFQ, CBWFQ y LLQ pueden servir ciertos paquetes primero (esto es una forma proactiva de servicios de colas). RE-PRIORIZAR PAQUETES: En algunos casos, los paquetes importantes necesitan ser re-priorizados cuando entran o salen de un dispositivo. Por ejemplo, cuando los paquetes dejan la red privada para pasar a la red de ISP, el ISP puede requerir que los paquetes sean repriorizados. PAYLOAD COMPRIMIDO: Mediante esta técnica reducimos el tamaño de los paquetes, lo cual incrementa de forma virtual el ancho de banda. Si usamos alguna de estas técnicas, debemos asegurarnos que el tiempo necesario para comprimir el payload justifica los beneficios de tener menos datos que transferir sobre en enlace. COMPRESIÓN DE CABECERAS: La compresión de cabeceras no hace un uso tan intensivo de la CPU como la compresión del payload. Este tipo de compresión reduce los retardos cuando se usa en conjunto con otros mecanismos. Este tipo de compresión es especialmente útil para paquetes de voz que tienen una relación mala de payload-cabecera (una cabecera relativamente grande en comparación con el payload), lo cual se mejora reduciendo las cabeceras del paquete (compresión de cabecera RTP – cRTP).

3.1.7 Pérdida de Paquetes Tras el retardo, la siguiente tarea más importante para las redes es la pérdida de paquetes. Normalmente, la pérdida de paquetes sucede cuando los routers tienen el buffer de una interfaz en particular (output queue) saturado. Una cola de salida llena, causa que los nuevos paquetes que deben colocarse en la misma sean eliminados. El término usado para los paquetes borrados por este motivo se conoce como “BORRADO DE SALIDA”. Los routers pueden borrar paquetes también por las siguientes razones comunes:

- BORRADO DE COLA DE ENTRADA: La CPU central está ocupada y no puede procesar paquetes. - IGNORAR: El router funciona fuera del espacio de memoria. - SOBREESCRIBIR: La CPU del router está demasiado ocupada y no puede asignar un espacio de buffer

libre al nuevo paquete. - ERROR DE TRAMA: El hardware detecta un error en una trama (como CRC, runts o giants).

3.1.8 Gestión de la congestión. Formas de prevenir el borrado de paquetes La pérdida de paquetes suele ser el resultado de la congestión de una interfaz. Para prevenir esta situación, podemos usar uno de los siguientes enfoques:

- Incrementar la capacidad de los enlaces para prevenir la congestión. - Garantizar suficiente ancho de banda e incrementar el espacio de buffer para acomodar tráficos.

Existen varios mecanismos en el software Cisco IOS QoS que pueden garantizar ancho de banda y proveer prioridades enviando aplicaciones sensibles a borrados. Ejemplos son WFQ, CBWFQ y LLQ.

- Prevenir la congestión borrando paquetes de prioridad baja antes de que la misma se produzca. El software Cisco IOS QoS provee mecanismos de colas que empiezan a borrar paquetes de baja prioridad antes de que se produzca la congestión. Un ejemplo es WRED (Detección temprana aleatoria de prioridades).

El software Cisco IOS QoS también provee los siguientes mecanismos para prevenir la congestión: - POLÍTICA DE TRÁFICO (POLICING): La política de tráfico propaga ráfagas. Cuando el radio del tráfico

alcanza el máximo configurado, el tráfico excedido se borra (o se marca). El resultado es un radio de salida que aparece como un gráfico en sierra con crestas y valles.

CCNP ONT

34- POLÍTICA DE CORTA DURACIÓN (SHAPING): A diferencia de la anterior, se retiene el tráfico de paquetes

excedidos en una cola y se programa el exceso para una transmisión posterior. El resultado es un radio de salida liso.

El shaping implica la existencia de una cola y de suficiente memoria para almacenar paquetes retrasados, mientras que el policing no. La cola es concepto de salida: los paquetes van a una interfaz saliente y pueden colocarse en una cola. En la figura se muestra las diferencias entre policing y shaping. Las técnicas de prevención de congestión monitorean la carga de tráfico de red en un esfuerzo de anticiparse y prevenir la congestión antes de que la misma sea un problema. Estas técnicas proveen un tratamiento preferente al tráfico “Premium”

cuando existe congestión, mientras que maximiza la capacidad de la red con una pérdida de paquetes y un retardo mínimos. El algoritmo WRED permite prevención de congestión en interfaces de red proveyendo gestión del buffer y permitiendo al tráfico TCP decrecer, antes que los buffer se saturen.

3.2 Implementando QoS Cisco IOS

3.2.1 ¿Qué es QoS? QoS es un término genérico que se refiere a algoritmos que proveen diferentes niveles de calidad a diferentes tipos de tráficos de red. El QoS gestiona las siguientes características de la red:

- ANCHO DE BANDA: El radio al cual el tráfico es portado a través de la red. - LATENCIA: El retardo en la transmisión de datos desde el origen al destino. - JIITER: La variación en el retardo. - FIABILIDAD: El porcentaje de paquetes descartados por un router.

Las redes simples procesan el tráfico en colas FIFO. Sin embargo, QoS permite proveer un mejor servicio a ciertos flujos dándoles una prioridad superior o inferior. Es a su vez importante asegurarse que proveer prioridades a uno o más flujos no hace que otros flujos fallen. El Cisco IOS QoS es una caja de herramientas, donde varias herramientas pueden obtener el mismo resultado. Estas herramientas pueden ayudar a aliviar problemas de congestión. Sin embargo, en ocasiones existe demasiado tráfico para el ancho de banda disponible. En estas situaciones, QoS sólo será una solución temporal.

- GESTIÓN DE CONGESTIÓN: Debido a la naturaleza inconstante del tráfico de voz, vídeo y datos, el total de tráfico en ocasiones excede la velocidad del enlace. En este punto, ¿qué debe hacer el router? ¿el router almacenará el tráfico en una cola única y permitirá al primer paquete de la misma ser el primero en salir?¿o el router pondrá los paquetes en diferentes colas y servirá ciertas colas más a menudo?. Las herramientas de gestión de congestión dirigen estas preguntas. Para ellos se incluyen PQ, CQ, WFQ y CBWFQ.

- GESTIÓN DE COLAS: Debido a que las colas son finitas en su tamaño, estas pueden desbordarse. Cuando una cola está llena, cualquier paquete adicional no puede colocarse en la misma y el flujo es eliminado. Esto se conoce como “tail drop” o cola borrada. Por ello, se necesita un mecanismo que realiza las siguientes 2 tareas:

o Intentar asegurarse de que las colas no se llenen, donde exista un habitáculo para paquetes de alta prioridad.

o Usar ciertos tipos de criterios de eliminado de paquetes, como eliminar paquetes de baja prioridad antes que paquetes de alta prioridad. WRED provee ambos mecanismos.

- EFICIENCIA DE ENLACES: En ocasiones, los enlaces de baja velocidad representan una tarea para los paquetes pequeños. La fragmentación en ciertos enlaces segmenta un paquete en paquetes más pequeños, pudiendo perderse la sincronización en los paquetes de voz. No hay razón para fragmentar un paquete de voz ya que estos suelen ser normalmente pequeños. Otra mejora en la operación es eliminar bits de las cabeceras. Por ejemplo, la cabecera RTP tiene un tamaño de 20 bytes. La compresión de RTP reduce su cabecera a un tamaño más gestionable.

- TRAFFIC SHAPING Y POLICING: El shaping se usa para crear un flujo de tráfico que limita el ancho de banda total potencial del flujo. Se usa para prevenir los problemas de desbordamiento mencionados anteriormente. Policing es similar a shaping, pero difiere en un factor muy importante: el tráfico que excede el límite configurado no se almacena, si no que se borra directamente.

Sumarizando, QoS es la habilidad de la red para proveer servicios mejorados o especiales a usuarios específicos y aplicaciones.

CCNP ONT

35

3.2.2 Herramientas de gestión de congestión - FIFO; CAPACIDADES DE ALMACENAMIENTO Y ENVÍO BÁSICAS: En su forma más simple, las colas FIFO

representan paquetes almacenados cuando la red está congestionada y el envío de los mismos en el mismo orden de llegada a través del enlace congestionado. Es el algoritmo de colas por defecto en muchas ocasiones. FIFO no toma decisiones sobre prioridad de paquetes. Las redes más sofisticadas de hoy en día necesitan algoritmos más inteligentes.

- PQ – COLA DE PRIORIDAD; TRÁFICO PRIORIZADO: PQ se asegura que el tráfico importante se manipula más rápido en cada punto donde se utiliza. Se diseño para dar una prioridad estricta al tráfico importante. Las colas de prioridad pueden flexibilizar prioridades de acuerdo al protocolo de red (como IP, IPX o AppleTalk), interfaces de entrada, tamaños de paquete, direcciones de origen y destino, etc. Con PQ, cada paquete se coloca en una de las 4 colas existentes: Alta / Media / Normal / Baja, basándose en la prioridad asignada. Los paquetes sin clasificar se colocan en la cola normal por defecto.

- CQ - COLA PERSONALIZADA; ANCHO DE BANDA GARANTIZADO: CQ permite a varias aplicaciones u organizaciones compartir la red entre aplicaciones con un mínimos requisitos de ancho de banda o latencia. En estos entornos, el ancho de banda debe compartirse de forma proporcional entre aplicaciones y usuarios. CQ manipula el tráfico asignándole una cantidad específica de espacio en la cola a cada clase de paquetes, y sirviendo a las colas de una forma round-robin. El algoritmo de colas coloca los mensajes en una de las 17 colas (la cola 0 porta mensajes de sistema como keepalives, señalización y otros) y se vacío con los pesos de las prioridades. El router sirve colas de la 1 a la 16 de una forma round-robin. Esta prestación se asegura de que ninguna aplicación (o grupo de aplicaciones) logra más que la proporción predeterminada de capacidad cuando la línea está saturada.

- WFQ - BASADO EN FLUJO; CREANDO JUSTICIA ENTRE FLUJOS: Para situaciones en las cuales se desea proveer un tiempo de respuesta consistente a usuarios sin tener que agregar un ancho de banda excesivo, la solución es WFQ, referido normalmente como WFQ equitativo o justo. WFQ es una de las colas preferidas por Cisco como técnica de gestión de congestión. Es un algoritmo de colas basado en flujos que permite que cada cola sea servida de forma justa en términos de contadores de bytes. Por ejemplo, si la cola 1 tiene paquetes de 100 bytes y la cola 2 tiene paquetes de 50 bytes, el algoritmo WFQ tomará 2 paquetes de la cola 2 por cada paquete de la cola 1.

- CBWFQ - WFQ BASADO EN CLASES; ASEGURAR EL ANCHO DE BANDA DE LA RED: CBWFQ es una de las herramientas de gestión de congestión más nuevas de Cisco que provee una flexibilidad mayor. Provee una cantidad mínima de ancho de banda a una clase, en oposición a proveer una cantidad máxima de ancho de banda cuando el tráfico es de corta duración. CBWFQ permite al administrador de red crear clases de anchos de banda mínimos garantizados. En lugar de proveer una cola para cada flujo individual, el administrador define una clase que consiste en uno o más flujos, cada clase con un ancho de banda mínimo garantizado. CBWFQ previene que múltiples tráficos de baja prioridad inunden un flujo único de alta prioridad. Por ejemplo, WFQ proveerá un stream de vídeo que necesita la mitad del ancho de banda de una línea T1 si hay 2 flujos. Pero, si se añaden más flujos, el stream de vídeo obtiene menos ancho de banda porque los mecanismos WFQ son equitativos. Si hay 10 flujos, el stream de vídeo obtendrá sólo una décima parte del ancho de banda. CBWFQ provee el mecanismo necesario para proveer la mitad del ancho de banda que el vídeo necesita. El administrador de red define una clase, coloca al stream de vídeo en la clase, y le dice al router que provea 768 kbps (la mitad de una línea T1) a esa clase. El vídeo, por tanto, obtiene el ancho de banda que necesita. El resto de flujos reciben una clase por defecto.

3.2.3 Gestión de Colas (Herramientas de prevención de congestión) La herramienta principal del Cisco IOS para prevenir la congestión es WRED. Los algoritmos RED previenen la congestión en las redes donde esta pueda volverse un problema. RED trabaja monitoreando la carga de tráfico en puntos de la red y descartando aleatoriamente paquetes si la congestión se incrementa. El resultado del borrado es que el origen detecta el tráfico borrado y transmite a una velocidad menor (reduce el tamaño de ventana). RED se diseñó para trabajar preferentemente con TCP en entornos IP. WRED provee una manipulación del tráfico preferente en paquetes de prioridades mayores. Puede descartar de forma selectiva tráfico de baja prioridad cuando la interfaz comienza a congestionarse y proveer funciones diferentes para diferentes clases de servicio (CoS). Como sabemos, cada cola puede albergar un número finito de paquetes. Una cola llena causará el descarte de nuevos paquetes que quieran ingresar en la cola. Esto no es deseable ya que los paquetes descartados podrían tener una prioridad alta y el router no ha tenido la oportunidad de colocarlos en la cola. Si la cola no estuviera llena, el router podría mirar la prioridad de los paquetes y borrar sólo aquellos que tengan una prioridad baja, permitiendo a los de prioridad alta entrar en la cola. WRED usa un umbral mínimo para determinar cuándo borrar un paquete (el tamaño de la cola debe exceder este umbral para que WRED considere a un paquete como candidato de descarte). Consideraremos el siguiente ejemplo para 2 clases de tráfico. La primera clase tiene un umbral mínimo para la procedencia IP de 20. La siguiente cola del ejemplo tiene un umbral de borrado para la precedencia IP de 22. Si el tamaño de la cola es de 21, WRED borrará paquetes para la primera clase,

CCNP ONT

36pero los paquetes de la segunda permanecerán en la cola. Si el tamaño de la cola aumenta y excede 22, los paquetes con la procedencia IP 20 también serán borrados.

3.2.4 Preparación para implementar QoS Existen 3 pasos básicos para implementar QoS en una red:

- PASO1- IDENTIFICAR TIPOS DE TRÁFICO Y SUS REQUISITOS: Estudiar la red para determinar el tipo de tráfico que se origina y determinar los requisitos QoS necesarios para los diferentes tipos de tráfico.

- PASO2- DEFININIR CLASES DE TRÁFICO: Esta parte agrupa tráficos con requisitos QoS similares dentro de clases. Por ejemplo, 3 clases de tráfico podrían definirse como voz, misión crítica y mejor esfuerzo.

- PASO3- DEFINIR POLÍTICAS QOS: Las políticas QoS dictan los requisitos QoS para cada clase de tráfico.

3.2.5 Paso 1: Identificar tipos de tráfico y sus requisitos Este paso consiste en las siguientes actividades:

- DETERMINAR LOS PROBLEMAS DE QOS DE LOS USUARIOS: Mediremos el tráfico de red durante períodos de congestión. Realizaremos un examen de uso de CPU en cada dispositivo de red durante períodos de congestión para determinar dónde pueden producirse los problemas.

- DETERMINAR EL MODELO DE NEGOCIO Y LOS OBJETIVOS Y OBTENER UNA LISTA DE REQUISITOS: Esta actividad ayuda a definir el número de clases necesarias y permite determinar los requisitos empresariales para cada tipo de tráfico.

- DEFINIR LOS NIVELES DE SERVICIO REQUERIDOS POR LAS DIFERENTES CLASES EN TERMINOS DE TIEMPO DE RESPUESTA Y DISPONIBILIDAD: Una asignación de nivel de servicio incluirá la prioridad y el tratamiento de un paquete recibido. Por ejemplo, podríamos asignar un nivel de servicio alto a aplicaciones de voz (prioridad alta, LLQ y cRTP). Podríamos asignar un nivel de servicio bajo a otros flujos (prioridad baja, WFQ y compresión TCP).

Determinar que aplicaciones son “business-critical” requieren revistar todas las aplicaciones que compiten por los recursos de la red. Existen herramientas para analizar patrones de tráfico en la red, como NetFlow Accounting, NBAR (Network-based Application Recognition) y QDM (QoS Device Manager).

- NETFLOW ACCOUNTING: Provee detalles sobre el tráfico de red y puede usarse para capturar la clasificación de tráfico o la precedencia de cada flujo.

- NBAR: Es una herramienta de clasificación que puede identificar tráfico hasta la capa de aplicación. Provee estadísticas por interfaz, por protocolo para cada flujo de tráfico que atraviesa una interfaz.

- QDM: Es una herramienta de gestión basada en web que provee una interfaz de usuario gráfica fácil de utilizar para configurar y monitorear funcionalidades avanzadas de QoS en routers.

3.2.6 Paso 2: Definir clases de tráfico Una clase es un grupo de flujos de red que tienen características similares. Por ejemplo, un ISP podría definir clases que representen diferentes niveles de servicio ofrecidos a sus clientes. Una empresa podría definir acuerdos de niveles de servicio (SLAs) para obtener distintos niveles de servicio a varias aplicaciones. Debido a sus requisitos de QoS estrictos de la voz, el tráfico de voz es normalmente una clase en sí misma. Cisco ha desarrollado mecanismos QoS específicos, como LLQ, para asegurarse que la voz siempre reciba un tratamiento prioritario sobre todos los demás flujos.

Una empresa típica define las siguientes 5 clases de tráfico, como se muestra en la figura, basándose en los requisitos de departamentos o basándose en el predominio de una aplicación: VOZ: Prioriza de forma absoluta el tráfico VoIP. MISSION-CRITICAL: Pequeño conjunto de aplicaciones localmente definidas como críticas. Por ejemplo, una aplicación que ejecuta una base de datos de pedidos que necesita funcionar 24 horas al día. TRANSACCIONAL: Acceso a bases de datos, servicios de transacción, tráfico interactivo

y servicios de datos preferentes. Dependiendo de la importancia de la aplicación de base de datos en la empresa, le daremos a la misma una cantidad mayor de ancho de banda y una prioridad mayor. Por ejemplo, ¿nuestro departamento de nóminas realiza trabajo sensible o crítico?. Su importancia en la organización determina la prioridad y la cantidad de ancho de banda que le otorgaremos en la red. MEJOR ESFUERZO: Aplicaciones como HTTP, FTP y correo electrónico podrían constituir una clase. Nuestra política QoS debe garantizar que los empleados que usan estas aplicaciones tengan un ancho de banda para las mismas y un nivel de prioridad bajo en relación con las anteriores.

CCNP ONT

37SCAVENGER: El tráfico sin especificar se considera como menor a mejore esfuerzo. Aplicaciones como BitTorrent y otras son servidas por esta clase.

3.2.7 Paso 3: Definir una política QoS Una política QoS generalmente define lo siguiente:

- Grupos discretos de tráficos de red (clases de servicio – [CoS]) - Métricas que regulen la cantidad de tráfico de red para cada clase (metering) - Acciones a tomar a flujos de paquetes (comportamiento por salto- [PHB]) - Cualquier estadística almacenada requerida para una CoS.

Cuando los paquetes pasan por la red, QoS evalúa sus cabeceras. La política QoS determina la acción que QoS debe tomar. Definir una política QoS envuelve una o más de las siguientes actividades:

- Configurar un ancho de banda mínimo garantizado. - Configurar un ancho de banda máximo límite. - Asignar prioridades a cada clase. - Usar tecnologías QoS, como colas avanzadas, para gestionar la congestión.

EJEMPLO: DEFINIR UNA POLÍTICA QOS Como ejemplo, considerar una red que tiene una cantidad finita de ancho de banda disponible. Usando clases de tráfico, las políticas QoS previamente definidas pueden ser usadas basándose en las siguientes prioridades (la prioridad 5 es la más alta y la 1 la más baja):

- PRIORIDAD 5: VOZ: Usa LLQ para dar a la voz la máxima prioridad siempre. Un ancho de banda mínimo de 1 Mbps.

- PRIORIDAD 4: MISSION-CRITICAL: Usa CBWFQ para prioridad flujos de tráfico de la clase crítica. Un ancho de banda mínimo de 1 Mbps.

- PRIORIDAD 3: TRANSACCIONAL: Usa CBWFQ para priorizar flujos de tráfico transaccionales. Un ancho de banda mínimo de 1 Mbps.

- PRIORIDAD 2: MEJOR ESFUERZO: Usa CBWFQ para priorizar tráfico de mejor esfuerzo, con un ancho de banda de 500 Kbps.

- PRIORIDAD 1: SCAVENGER: Usa WRED para borrar estos paquetes si la red tiende a congestionarse. Les otorga un ancho de banda de100 Kbps.

3.3 Selección de un modelo de Política QoS apropiado

3.3.1 Los 3 modelos QoS MODELO BEST-EFFORT: Este modelo no utiliza QoS. Si no es importante cuando o como lleguen los paquetes, este modelo es el apropiado. INTSERV (SERVICIOS INTEGRADOS): Puede ofrecer un QoS muy alto a paquetes IP. Esencialmente, este modelo define un proceso de señalización para que las aplicaciones indiquen a la red que requieren un QoS especial durante el cual se debe reservar ancho de banda. Con este modelo, la entrega de paquetes está garantizada. Sin embargo, este modelo puede limitar severamente la escalabilidad de la red. DIFFSERV (SERVICIOS DIFERENCIADOS): Provee la mayor escalabilidad y flexibilidad del QoS de la red. Los dispositivos de red reconocen las clases de tráfico y proveen distintos niveles de QoS a distintas clases de tráfico.

3.3.2 Modelo Best-Effort El diseño básico de Internet provee una entrega best-effort y no provee garantías. Este modelo trata a todos los paquetes de la misma forma. BENEFICIOS: Escalabilidad ilimitada. La única forma de alcanzar los límites de escalabilidad es alcanzar los límites del ancho de banda, punto en el cual todo el tráfico es afectado de la misma forma. Este modelo es el más fácil de desplegar. DESVENTAJAS: No existen garantías de entrega. Los paquetes tienen un tratamiento preferente. Los datos críticos se tratan de la misma forma que un e-mail ocasional.

3.3.3 Modelo IntServ La necesidad de aplicaciones en tiempo real, como videoconferencias, realidad virtual, VoIP, etc. motivaron el despliegue del modelo e arquitectura IntServ (RFC 1633). IntServ provee una forma de entrega de extremo a extremo requerida para proveer QoS a streams de paquetes de usuarios específicos, a menudo denominados “microflujos”. IntServ usa una reserva de recursos y mecanismos de control de admisión para establecer y mantener el QoS. Esta práctica es similar al concepto conocido como “hard QoS”. Hard QoS garantiza características al tráfico de extremo a extremo, como ancho de banda, retardos y umbrales de pérdida de paquetes. IntServ usa el protocolo RSVP (Resource Reservation Protocol) para señalizar las necesidades de QoS del tráfico de una aplicación a lo largo de los dispositivos que existen en el camino de extremo a extremo a través de la red. Si los dispositivos de red a lo largo de la ruta pueden reservar el ancho de banda necesario, la aplicación origen puede comenzar a transmitir. En el caso contrario, la aplicación origen no enviará ningún dato.

CCNP ONT

38El modelo IntServ hereda el enfoque orientado a conexión del diseño de red telefónico. Cada comunicación individual debe especificar explícitamente su descripción de tráfico y los recursos solicitados a la red. El router borde realiza un control de admisión para asegurarse que los recursos disponibles son suficientes. El estándar IntServ asume que los routers a lo largo del camino configuran y mantienen el estado de cada comunicación individual. En este modelo, la aplicación solicita un tipo de servicio específico desde la red antes de enviar datos. La aplicación informa a la red del perfil de su tráfico y solicita un tipo particular de servicio que cumpla sus requisitos de ancho de banda y retardo. La aplicación envía datos sólo después de recibir una confirmación de los requisitos solicitados. La red realiza un control de admisión basado en la información recibida desde la aplicación y los recursos de red disponibles. La red cumple su compromiso manteniendo un estado por flujo y realizando entonces clasificación de paquetes, políticas y colas inteligentes basadas en el estado. La prestación QoS configurada en Cisco IOS incluye estas prestaciones:

- RSVP: puede usarse por aplicaciones para señalizar sus requisitos QoS al router. - MECANISMOS DE COLAS INTELIGENTES: pueden usarse con RSVP para proveer los siguientes niveles de

servicio QoS: o RADIO GARANTIZADO: Permite a las aplicaciones reservar ancho de banda para cumplir sus

requisitos. Por ejemplo, una aplicación VoIP puede reservar 32 Mbps de ancho de banda de extremo a extremo usando este servicio. El Cisco IOS QoS usa LLQ con RSVP para proveer un tipo de servicio garantizado.

o CARGA CONTROLADA: Permite a las aplicaciones tener un retardo pequeño y un alto rendimiento, incluso en períodos de congestión. Por ejemplo, las aplicaciones adaptadas a tiempo real, como una videoconferencia, pueden usar este servicio. El Cisco IOS QoS usa RSVP con WRED para proveer un control de carga.

Funciones IntServ Junto con la señalización de extremo a extremo, IntServ requiere varias funciones para estar disponible en routers y switches a lo largo de la ruta. Estas funciones incluyen las siguientes:

- CONTROL DE ADMISIÓN: Determina si un nuevo flujo solicitado por los usuarios y sistemas puede ser garantizado sin afectar a las reservas existentes. El control de admisión se asegura que los recursos estén disponibles antes de permitir una reserva.

- CLASIFICACIÓN: Implica el uso de un descriptor de tráfico para categorizar paquetes dentro de un grupo específico, para definir el paquete y hacer posible su manipulación QoS en la red. La clasificación es crucial para técnicas de políticas que seleccionan paquetes de distintos tipos de servicios QoS.

- POLÍTICAS: Toma acciones, incluyendo la posibilidad de borrar paquetes, cuando el tráfico no cumple con sus características especificadas.

- COLAS: Acomodan la congestión temporalmente en una interfaz de un dispositivo de red almacenando los paquetes excedentes en buffers hasta que el acceso al ancho de banda vuelva a estar disponible.

- PROGRAMACIÓN: Un componente QoS, el calendario QoS, negocia solicitudes simultáneas de acceso de red y determina que cola recibe prioridad. IntServ usa una programación round robin. Este es un enfoque en el cual el programa le da un pedazo de tiempo pequeño a cada trabajo antes de moverse al siguiente trabajo, realizando cada tarea de esta forma.

El modelo IntServ cuenta con varios y beneficios y algunas desventajas, como vemos a continuación: - BENEFICIOS: Soporta control de admisión que permite a la red rechazar nuevas sesiones RSVP si una

de las interfaces de la ruta alcanza su límite (esto es, si todo el ancho de banda que puede reservar está utilizado.

- RSVP señaliza las solicitudes QoS para cada flujo individual. En la solicitud, el usuario autorizado (objeto de autorización) y la política de tráfico necesario (objeto de política) se envían. La red puede proveer garantías entonces a flujos individuales.

- RSVP informa a los dispositivos de red de los parámetros del flujo (direcciones IP y números de puerto). Algunas aplicaciones usan números de puerto dinámicos, como las basadas en H.323, el cual es difícil de reconocer por dispositivos de red. NBAR (Network-Based Application Recognition) es un mecanismo que complementa a RSVP para aplicaciones que usan números de puertos dinámicos y no usan RSVP.

- DESVENTAJAS: Existe una señalización continua ya que la arquitectura con conexión de RSVP añade una sobrecarga al ancho de banda. RSVP continúa señalizando durante la duración entera del flujo. Si la red cambia, o un enlace falla, la red no es capaz de soportar la reserva realiza en un primer momento.

- El enfoque basado en flujo no es escalable en implementaciones mayores, como la Internet pública, ya que RSVP tiene que hacer seguimiento de cada flujo individual. Esta circunstancia hace la señalización de extremo a extremo difícil. Una solución posible es combinar IntServ con elementos del modelo DiffServ para proveer la escalabilidad necesaria.

CCNP ONT

39

3.3.4 RSVP y el modelo QoS IntServ La arquitectura QoS de Cisco usa RSVP como uno de varios métodos para proveer control de admisión de llamadas (CAC) para una red con VoIP. El método RSVP para CAC es el único método que realiza una reserva de ancho de banda para cada llamada de voz admitida. Otros métodos CAC pueden sólo realizar una decisión basada en suposiciones del estado de la red en el inicio de la llamada. El uso de RSVP no provee sólo CAC, también garantiza QoS para la duración de la llamada sin importarle las condiciones de cambio de la red. Es el método usado por Cisco Unified CallManager 5.0. Si existen recursos disponibles, RSVP acepta la reserva e instala un clasificador de tráfico para asignar una clase QoS temporal al flujo de tráfico en el camino de envío QoS. El clasificador de tráfico le dice al camino QoS como clasificar paquetes desde un flujo particular y como tratar el envío provisto. RSVP es un protocolo IP que usa el ID de protocolo 46 y los puertos TCP y UDP 3455. Es importante anotar que RSVP no es un protocolo de enrutamiento. RSVP trabaja en conjunto con los protocolos de enrutamiento e instala las ACL dinámicas equivalentes junto con los cálculos realizados por el protocolo de enrutamiento. En RSVP, un flujo de datos es una secuencia datagramas que tienen el mismo origen, destino (independientemente de si el destino es una o varias máquinas) y requisitos QoS. Los requisitos QoS se comunican a través de la red mediante una especificación de flujo, lo cual es una estructura de datos que se usa por los host de la internetwork para solicitar servicios especiales a la red. RSVP se centra en los siguientes 2 tipos de tráfico principales:

- TRÁFICO SENSIBLE A VELOCIDADES: El tráfico que requiere una velocidad de transmisión garantizada y constante desde su origen a su destino. Un ejemplo de aplicación es una videoconferencia H.323. RSVP habilita un servicio constante en redes conmutadas por paquetes a través de un servicio de nivel sensible a velocidades. Este servicio se conoce como “guaranteed-bit-rate”.

- TRÁFICO SENSIBLE A RETRASOS: Tráfico que requiere entregas actualizadas y que varía su velocidad de acuerdo a las mismas. Por ejemplo, el vídeo MPEG-II, cubre de 3 a 7 Mbps, dependiendo de la velocidad a la que cambien las imágenes. Los servicios RSVP soportan tráfico sensible a retrasos, refiriéndose a los mismos como servicios de retardo-controlado (para servicios que no son en tiempo real) y servicios predictivos (servicios en tiempo real).

3.3.5 Operación de RSVP A diferencia de los protocolos de enrutamiento, RSVP gestiona flujos de datos, más que tomar decisiones para datagramas individuales. Los flujos de datos consisten en sesiones diferentes entre máquinas origen y destino específicas. La definición de sesión es un flujo simple de datagramas a un destino particular y un protocolo de la capa de transporte. Los siguientes datos identifican sesiones: dirección de destino, ID de protocolo y puerto de destino. RSVP soporta sesiones unicast y multicast. RSVP especifica el QoS usado por hosts y routers. Los hosts usan RSVP para solicitar un nivel de QoS desde la red en representación de un stream de datos de aplicación. Los routers usan RSVP para entregar solicitudes QoS a otros routers a lo largo de la ruta del stream. Haciendo esto, RSVP mantiene los estados de router y host para proveer el servicio solicitado. Para iniciar una sesión RSVP multicast, un receptor primero participa en el grupo multicast especificado por una IP de destino usando el protocolo IGMP. Una vez es partícipe del grupo, un emisor potencial comienza enviado mensajes de ruta RSVP a la IP de destino. La aplicación del receptor recibe un mensaje de ruta y comienza a enviar los mensajes apropiados de solicitud de reserva especificando los descriptores de flujo deseados usando RSVP. Cuando la aplicación emisora recibe un mensaje de solicitud de reserva, comienza a enviar paquetes de datos. ¿CÓMO TRABAJA RSVP? Cada nodo que usa RSVP tiene 2 módulos de decisiones locales:

- CONTROL DE ADMISIÓN: Mantiene el seguimiento de los recursos del sistema y determina si el nodo tiene suficientes recursos para proveer el QoS solicitado. El daemon RSVP monitorea ambas acciones. Si cualquiera de ellas falla, el programa RSVP devuelve un mensaje de error a la aplicación que originó la solicitud. Si ambas son satisfactorias, el daemon RSVP configura parámetros en el clasificador de paquetes y los paquetes son programados para obtener el QoS solicitado.

- CONTROL DE POLÍTICA: El control de política determina si el usuario tiene permisos administrativos para realizar la reserva.

Si se satisfacen el control de admisión y de política, el daemon configura parámetros en 2 entidades, el clasificador de paquetes y el programador de paquetes:

- CLASIFICADOR DE PAQUETES (PACKET CLASSIFIER): Determina la ruta y la clase QoS para cada paquete. - PROGRAMADOR DE PAQUETES (PACKET SCHEDULER): Ordena la transmisión de paquetes para lograr el

QoS prometido a cada stream. - PROCESAMIENTO DE RUTA (ROUTING PROCESS): El daemon RSVP se comunica con el proceso de

enrutamiento para determinar la ruta por la que se enviará su solicitud de reserva y para manipular los cambios de membresía y de rutas. Cada router participa en la reserva de rutas pasando los paquetes de datos entrantes al clasificador de paquetes y poniendo en cola los paquetes si es necesario en un programador de paquetes.

Una vez que el clasificador de paquetes determina la ruta y la clase QoS de cada paquete, y el programador localiza recursos para la transmisión, RSVP pasa la solicitud a todos los nodos (routers y

CCNP ONT

40host) a lo largo de la ruta de datos inversa a los orígenes de la transmisión. En cada nodo, el programa RSVP aplica una decisión local llamado “Control de Admisión” para determinar si ese nodo puede proveer el QoS solicitado. Si el control de admisión pasa en la provisión del QoS requerido, el programa RSVP configura los parámetros del clasificador de paquetes y se programa para obtener el QoS deseado. Si el control de admisión falla en algún nodo, el programa RSVP devuelve una indicación de error a la aplicación que originó la solicitud. COMBINACIÓN DE LA RESERVA Cuando un receptor potencial inicia una solicitud de reserva, la solicitud no necesita viajar por toda la ruta al origen del emisor. En su lugar, esta viaja corriente arriba hasta encontrar otra solicitud de reserva para el mismo stream de origen. La solicitud entonces se combina con esa reserva. La combinación de reserva guía la primera ventaja de RSVP, la escalabilidad. Esto permite que un amplio número de usuarios participen en un grupo multicast sin incrementar significativamente el tráfico de datos. RSVP escala a grandes grupos multicast. La carga media del protocolo decrece a medida que el número de participantes se incrementa.

Como ejemplo, en la figura se muestran los principios básicos de cómo RSVP realiza CAC y reserva de ancho de banda en una red. En este ejemplo, RSVP está habilitado en cada interfaz de cada router. Una WAN habilitada para IntServ conecta 3 teléfonos IP y un CallManager 5.0. Debido a que el ancho de banda está limitado en los enlaces WAN, RSVP determina si el ancho de banda solicitado para una llamada satisfactoria está disponible. Para ello, el CallManager usar RSVP. Una aplicación de voz habilitada para RSVP quiere reservar 20 Kbps de ancho de banda para un stream de datos desde

teléfono IP 1 al teléfono IP 2. RSVP usa los protocolos de enrutamiento subyacentes para determinar donde llevar las solicitudes de reserva. Como el enrutamiento cambia rutas para adaptarse a cambios en la topología, RSVP adapta reservas a las nuevas rutas si existen reservas en ese momento. El protocolo RSVP intenta establecer una reserva de extremo a extremo comprobando los recursos de ancho de banda disponibles en todos los routers habilitados para RSVP a lo largo de la ruta desde IP-Phone 1 a IP-Phone 2. A medida que los mensajes RSVP progresan a lo largo de la red desde el router R1, vía R2 a R3, el ancho de banda RSVP disponible decrece en 20 Kbps en las interfaces del router. Para las llamadas de voz, la reserva debe realizarse en ambas direcciones. El ancho de banda disponible en todas las interfaces es suficiente para aceptar el nuevo stream de datos, por lo que la reserva es satisfactoria y se le notifica a la aplicación para que comience a enviar los datos.

3.3.6 El modelo DiffServ La arquitectura DiffServ especifica un mecanismo simple y escalable de clasificación y gestión de tráfico de red proveyendo garantías QoS en redes IP modernas. DiffServ puede proveer servicios de baja latencia garantizada (GS) a tráficos de red críticos como voz o vídeo mientras provee garantías de tráfico Best-effort a servicios no críticos como tráfico web o transferencia de ficherso. El concepto soft QoS es la base del modelo DiffServ. IntServ usa señalización en la cual los host finales señalizan sus necesidades QoS a la red. DiffServ no usa señalización pero trabajo en el modelo de aprovisionamiento de QoS, donde los elementos de la red se configuran para servir múltiples clases de tráfico cada una con unos requisitos QoS diferentes. Clasificando distintos flujos en clases (aggregates) y proveyendo un QoS apropiado a estas agregates, DiffServ puede evitar una complejidad significativa, costes, e introducir escalabilidad. Por ejemplo, DiffServ agrupa todos los flujos TCP en una clase única, y localiza ancho de banda para esta clase, en lugar de realizar esta tarea por flujos individuales (Hard QoS). El modelo hard QoS (IntServ) provee una solución rica de extremo a extremo, usando señalización de extremo a extremo, mantenimiento de estados y control de admisión en cada elemento de la red. Este enfoque consume una carga significativa, restringiendo la escalabilidad. Por otro lado, DiffServ no es una estrategia QoS de extremo a extremo, ya que no puede cumplir garantías de extremo a extremo, pero el QoS DiffServ es un enfoque más escalable de implementación QoS. DiffServ asigna a cada clase un conjunto de comportamientos QoS y cumple y aplica los mecanismos QoS en una base por salto (PHB). DiffServ divide el tráfico de red dentro de clases basadas en los requisitos de la empresa. A cada clase puede asignársele un nivel de servicio diferente. A medida que los paquetes atraviesan la red, cada dispositivo de red identifica la clase del paquete y sirve el paquete de acuerdo a su clase. Es posible escoger muchos niveles de servicio con DiffServ. Por ejemplo, el tráfico de voz de los teléfonos IP se le suele dar un nivel preferencial con respecto a otros tráficos de aplicación.

CCNP ONT

41DiffServ trabaja como un servicio de entrega de paquetes. Tu solicitas (y pagas) un nivel de servicio cuando envías tus paquetes. A través de la red por paquetes, el nivel de servicio es reconocido y los paquetes tienen un servicio preferencial o normal, dependiendo de la solicitud. Sus beneficios son una muy alta escalabilidad y la provisión de muchos niveles distintos de calidad. Las desventajas son que no hay una garantía absoluta de calidad de servicio y que se requiere un conjunto de mecanismos complejos para trabajar en concierto a través de la red.

3.4 Uso de MQC (CLI Modular QoS) para implementar QoS

3.4.1 Métodos de implementación de Políticas QoS Unos años atrás, la única forma de implementar QoS en una red era usando la CLI para configurar

políticas QoS en cada interfaz. Cisco introdujo MQC para simplificar la configuración QoS haciendo configuraciones modulares. MQC provee un enfoque en bloques que usa un módulo único repetidamente aplicado a una política y a múltiples interfaces. Cisco AutoQoS representa una tecnología innovadora que simplifica el desafío de la administración de red

reduciendo la complejidad QoS. Incorpora una inteligencia en el software Cisco IOS y Catalyst para aprovisionar y asistir en la gestión de despliegues QoS a gran escala. La primera fase del AutoQoS VoIP ofrece capacidades sencillas de automatizar despliegues VoIP para clientes que quieren utilizar telefonía IP pero les falta experiencia y personal para planear y desplegar servicios IP QoS e IP. La segunda fase, el Cisco AutoQoS Enterprise, añade estas prestaciones pero se soporta únicamente en interfaces del router. Cisco AutoQoS Enterprise usa NBAR para descubrir el tráfico. Tras esta fase de descubrimiento, el proceso AutoQoS puede configurar la interfaz para soportar hasta 10 clases de tráfico. Los clientes pueden de forma sencilla configurar, gestionar y resolver problemas de despliegues QoS usando asistentes del SDM. El asistente Cisco SDM AutoQoS provee un diseño QoS centralizado, administración y monitoreo de tráfico que escala a despliegues QoS mayores.

3.4.2 Configuración QoS con la CLI Cisco no recomienda el método heredado CLI para iniciar la implementación de políticas QoS. Sus limitaciones son las siguientes: Es la forma más difícil y tardía de configurar QoS // Tiene pocas oportunidades de ajuste y una menor granularidad que otras técnicas // Las funciones QoS tienen opciones limitadas, como por ejemplo, no podemos separar completamente la clasificación del tráfico desde los mecanismos QoS. La forma de construir una política QoS sería la siguiente, siguiendo estos pasos:

- Identificar los patrones de tráfico de nuestra red usando un analizador de paquetes. Esta actividad nos da la habilidad de identificar los tipos de tráfico, como IP, TCP, UDP, AppleTalk, IPX, etc.

- Tras el primer paso, comenzamos a clasificar el tráfico. Por ejemplo, separamos la clase del tráfico de voz de la clase del tráfico de negocio-crítico.

- Para cada clase de tráfico, especificamos la prioridad de la clase. Por ejemplo, para la voz se asigna una prioridad mayor que para el tráfico de negocio-crítico.

- Después de aplicar las prioridades, seleccionamos un mecanismo QoS apropiado, referente a la forma que tenga de manipular colas, compresión o una combinación de ambos.

EJEMPLO DE QOS CLI HEREDADO En este escenario, un enlace de baja velocidad WAN conecta la oficina a la central. Ambos sitios tienen PCs y servidores que ejecutan aplicaciones interactivas, como servicios de terminal. Debido a que el ancho de banda es limitado, debemos implementar una estrategia apropiada para un uso eficiente del mismo. En una red con sitios remotos que usan tráfico interactivo para su negocio diariamente, la disponibilidad del ancho de banda es una tarea. Debido a que servicios únicos están ejecutando técnicas de colas básicas, como PQ (cola prioritaria) o CQ (Cola personalizada) y mecanismos de compresión de cabeceras, como compresión de cabecera TCP, se necesita usar el ancho de banda de forma mucho más eficiente. Nota: PQ y CQ son mecanismos de prioridad tradicionales de Cisco que han sido sustituidos por mecanismos más avanzados, como WFQ, CBWFQ y LLQ.

CCNP ONT

42Dependiendo del tipo de tráfico de la red, debemos escoger la cola apropiada y los mecanismos de compresión. En el ejemplo, la estrategia utilizada es CQ y compresión de cabecera TCP. Cada prestación QoS necesita una línea separada. CQ necesita 2 líneas, una línea que configura la primera lista de la cola (en el ejemplo para el tráfico telnet), y una segunda línea que “ata” a la lista de cola a una interfaz y activa la lista. La configuración PPP multienlace necesita 4 líneas y otra línea más para la compresión de cabecera TCP.

3.4.3 QoS CLI Modular El MQC de Cisco permite a los usuarios crear políticas de tráfico y adjuntar las mismas a interfaces. Una política QoS contiene una o más clases de tráfico y una o más prestaciones QoS. Una clase clasifica tráfico, y una prestación QoS determina como tratar al tráfico clasificado. El MQC ofrece ventajas significativas sobre el método estudiado en el apartado anterior. Con MQC, el administrador puede reducir notablemente el tiempo y esfuerzo tomado en la configuración QoS dentro de una red compleja. En lugar de configurar comandos “a pelo” en la CLI interfaz por interfaz, el administrador desarrolla un conjunto uniforme de conjuntos de clases de tráfico y políticas QoS que son aplicados a las interfaces. El uso de MQC permite la separación de clasificaciones de tráfico definidos en la política QoS.

Existen 3 pasos que deben seguirse en la configuración de MQC. * CREACIÓN DE UN CLASS MAP: ¿De qué tráfico he de estar pendiente? El primer paso en un despliegue QoS es identificar el tráfico interesante, es decir, clasificar los paquetes. Este paso define un agrupamiento de tráficos de red (lo que sería propiamente un class map en terminología MQC) con varias herramientas de clasificación (ACL, direcciones IP, Procedencia ip, 802.1p, MPLS EXP, NBAR, etc. Usaremos el comando CLASS-MAP para clasificar el tráfico. * POLICY MAP: ¿Qué sucederá con el tráfico clasificado? Decidiremos

en este paso que hacer con un grupo una vez que el tráfico ha sido identificado. Este paso es la construcción actual de la política QoS. Escogeremos el grupo de tráfico (class-map) en el cual realizar funciones QoS. Ejemplos de QoS son colas, borrados, marcas, etc… En este paso, configuraremos cada política de tráfico asociando la clase de tráfico con una o más prestaciones QoS usando el comando POLICY-MAP. * SERVICE POLICY: ¿Dónde aplicamos la política? Aplicamos el policy-map apropiado a las interfaces deseadas, sub-interfaces o PVCs ATM o Frame Relay. Usamos el comando SERVICE-POLICY.

En la figura tenemos un ejemplo del proceso. El paso de clasificación es modular e independiente de qué sucede una vez que el paquete es clasificado.

3.4.4 Paso 1 QoS CLI Modular: Configurar los Class Maps El paso 1 requiere decir al router que tráfico obtendrá QoS y a qué grado. Una ACL es la forma tradicional de definir cualquier tráfico en un router. Un class-map define el tráfico dentro de grupos con plantillas de clasificación que se usan por los policy maps donde los mecanismos QoS son agrupados en clases. Podemos configurar hasta 256 class maps dentro de un router. Por ejemplo, queremos asignar a las aplicaciones de vídeo un class map llamado video, y a las aplicaciones de correo un class map llamado Mail. Podríamos crear también un class map llamado VoIP e incluir todos los protocolos VoIP. El comando CLASS-MAP crea un class-map desde el modo de configuración global. Identificamos el class map con nombres “case-sensitive”. Todas las referencias a dicho class map deben utilizar el nombre utilizado.

CCNP ONT

43Existen 2 formas de procesar condiciones cuando hay más de una condición en un class map:

- MATCH ALL: Se deben cumplir todas las condiciones para atar el paquete a la clase. - MATCH ANY: Con cumplir una sola condición se atará el paquete a la clase.

La estrategia por defecto de los class map es match all. El comando MATCH especifica varios criterios para la clasificación de paquetes. Los paquetes son examinados para determinar si estos coinciden con los criterios especificados en los comandos match. Si un paquete coincide con el criterio especificado el paquete es considerado un miembro de la clase y se envía de acuerdo a las especificaciones QoS configuradas en la política de tráfico. Los paquetes que no cumplen con ninguna clase se clasifican como miembros de la clase de tráfico por defecto. El comando MATCH NOT invierte la condición especificada. Especifica un criterio de coincidencia que previene que los paquetes sean clasificados como miembros de la clase de tráfico especificada. El comando DESCRIPTION se usa para documentar la función del class map. Existen muchas formas de clasificar tráfico cuando configuramos class maps. El comando de la figura

permite usar una ACL como criterio de coincidencia para la clasificación de tráfico.

EJEMPLO: CLASES DE TRÁFICO DEFINIDAS En el siguiente ejemplo, se crearán 2 clases de tráfico se definirán sus criterios de coincidencia. Para la primera clase de tráfico, llamada class1, se usara la ACL 101 como toma de decisión de criterios. Para la segunda, class2, se usará la ACL 102. El router examinará los paquetes sobre los contenidos de estas ACL para determinar si los mismos pertenecen a estas clases. Router(config)# class-map class1 Router(config-cmap)# match access-group 101 Router(config-cmap)# exit Router(config)# class-map class2 Router(config-cmap)# match access-group 102 Router(config-cmap)# exit EJEMPLO: COMANDO MATCH NOT El comando MATCH NOT se usa para especificar un valor de política QoS específico que no se usa como criterio de coincidencia. Cuando usamos este comando, todos los demás valores de la política QoS llegarán a ser satisfactorios como criterios de coincidencia. Por ejemplo, si se usa el comando MATCH NOT QOS-GROUP 4 en el modo de configuración de class map, la clase especificada aceptará todos los valores de grupo QoS excepto el 4 como criterios de coincidencias. En la siguiente clase de tráfico, se considerarán correctos todos los protocolos excepto IP: Router(config)# class-map noip Router(config-cmap)# match not protocol ip Router(config-cmap)# exit

3.4.5 Paso 2: Configurar Policy Maps El comando POLICY-MAP crea una política de tráfico. Su propósito es configurar prestaciones QoS que deberían asociarse con el tráfico, el cual es entonces clasificado dentro de una clase de tráfico. Podemos asignar más ancho de banda a esa clase o darle ciertas prioridades. Una política de tráfico contiene 3 elementos, un nombre case-sensitive, una clase de tráfico (especificada en el paso anterior) y las políticas QoS.

El comando policy-map especifica el nombre de la política de tráfico.

Tras ingresarlo entramos al modo de configuración del policy-map. Desde aquí, podemos ingresar el nombre de una clase de tráfico (class-map), mediante el comando CLASS <NOMBRE CLASS-MAP | CLASS-DEFAULT>. Un paquete puede coincidir sólo con una clase de tráfico dentro de una política de tráfico. Si un paquete coincide con más de una clase de tráfico en la política de tráfico, la primera clase definida en la política será la utilizada. MQC no requiere que asociemos sólo una clase a una política de tráfico. Múltiples clases de tráfico puede asociarse con una política de tráfico única. Todo el tráfico no identificado en cualquiera de los class maps usados por el policy map formará parte de la clase por defecto “class-default”. Esta clase no tiene garantías QoS por defecto. La clase default puede usar colas FIFO o WFQ. EJEMPLO DE POLÍTICA DE TRÁFICO CREADA En el siguiente ejemplo se define la política de tráfico llamada policy1 que contiene especificaciones de políticas para 2 clases: class1 y class2. Los criterios de coincidencia fueron definidos anteriormente. Para la class1, la política incluye una solicitud de reserva de ancho de banda y un contador límite de paquetes máximo para la cola reservado a la clase. Para la class2, la política especifica sólo una solicitud de reserva de ancho de banda. Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# bandwidth 3000 Router(config-pmap-c)# queue-limit 30

Router(config-pmap)# exit Router(config-pmap)# class class2 Router(config-pmap-c)# bandwidth 2000 Router(config-pmap)# exit

EJEMPLO DE CREACIÓN DE UN “SUB-RATE” En este ejemplo, necesitamos hacer valer un “sub-rate” (esto es, un caño de 10 Mbps virtuales en un enlace de 1Gbps) en un enlace particular, mientras ofrecemos un ancho de banda mínimo garantizado a aplicaciones como la voz, misión critica y vídeo dentro de un caño virtual, de la siguiente forma: Voz (1 Mbps) // Misión crítica (2 Mbps) // Vídeo (5 Mbps) // Ancho de banda restante localizado para tráfico de mejor esfuerzo dentro del caño definido de 10 Mbps. La configuración sería la siguiente: Router(config)# policy-map CHILD Router(config-pmap)# class VOICE Router(config-pmap-c)# priority 1000 Router(config-pmap-c)# class MCA Router(config-pmap-c)# bandwidth 2000 Router(config-pmap-c)# class VIDEO Router(config-pmap-c)# bandwidth 5000 Router(config)# policy-map PARENT Router(config-pmap)# class class-default Router(config-pmap-c)# shape average 10000000 Router(config-pmap-c)# service-policy CHILD

Si una aplicación en particular no usa el ancho de banda, puede compartirse el mismo con las demas aplicaciones activas, por lo que el ancho de banda no se desperdicia. EJEMPLO DE CONFIGURACIÓN DE LA CLASE DE TRÁFICO POR DEFECTO El tráfico sin clasificar (que no ha cumplido ningún criterio de los class maps) se trata según la política definida para esta clase. Por defecto, esta clase no tiene prestaciones configuradas, colocándose en colas FIFO. En el siguiente ejemplo se configura una política de tráfico para la clase por defecto de la política de tráfico llamada policy1. La clase por defecto tiene 2 características: 10 colas para el tráfico que no cumple los criterios de las demás clases asociadas a la política // Un máximo de 20 paquetes por cola antes de que se comiencen a eliminar los últimos paquetes llegados a la interfaz (tail-drop). Router(config)# policy-map policy1 Router(config-pmap)# class class-default Router(config-pmap-c)# fair-queue 10 Router(config-pmap-c)# queue-limit 20 EJEMPLO DE CONFIGURACIÓN DE CLASS-MAP MATCH ANY Y CLASS-MAP MATCH-ALL Las opciones MATCH-ANY y MATCH-ALL determinan como se evaluarán los paquetes cuando existen múltiples criterios de coincidencia. Los paquetes deben cumplir todos los criterios de un match-all y uno o más criterios de un match-any para que se les considere miembros de la clase de tráfico. Router(config)# class-map match-all cisco1 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 4 Router(config-cmap)# match access-group 101

Si un paquete llega a un router con tráfico clasificado como cisco1 configurado en la interfaz, el router evalúa el paquete para determinar si cumple ser un paquete IP, un grupo QoS 4 y la lista de acceso 101. Si es así, el paquete se le considera miembro de esta clase.

3.4.6 Paso 3: Asociar la política a las interfaces Como sucede con las ACL, debemos aplicar el policy map a la interfaz específica donde queremos que afecte. Lo podemos colocar de entrada o de salida. Utilizamos el comando SERVICE-POLICY para su inserción.

En el ejemplo se muestra el uso de un policy map para separar el tráfico HTTP de otros tipos de tráfico. El tráfico HTTP tiene un ancho de banda garantizado de 2 Mbps. Todo el demás tráfico pertenece a la clase por defecto y tiene garantizado 6 Mbps de ancho de banda.

3.4.7 Class Maps Anidados EJEMPLO: TRÁFICO ANIDADO PARA MANTENIMIENTO En el siguiente ejemplo, la clase de tráfico llamada class1 tiene las mismas características que la clase de tráfico llamada class2, a excepción que la clase class2 ha añadido una dirección de destino como criterio de coincidencia. En lugar de configurar la clases de tráfico class1 línea a línea, el usuario puede utilizar la clase class2 y añadir el valor adicional de la clase class1. En las siguientes líneas se muestra la configuración utilizada:

CCNP ONT

45Router(config)# class-map match-any class2 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 3 Router(config-cmap)# match access-group 2 Router(config-cmap)# exit Router(config)# class-map match-all class1 Router(config-cmap)# match class-map class2 Router(config-cmap)# match destination-address mac 1.1.1 Router(config-cmap)# exit

3.4.8 Ejemplo MQC En el escenario, la oficina se conecta mediante un enlace WAN lento a la central. Los 2 sitios poseen teléfonos IP, PC’s y servidores que ejecutan aplicaciones interactivas, como servicios de terminal. La estrategia debe cumplir con los requisitos del tráfico de voz (una mayor prioridad, mejor retardo y ancho de banda constante). Los requisitos de clasificación también afectarán a la estrategia. En la figura se muestra un ejemplo de las tareas complicadas de configuración envueltas en el uso de MQC en el router Office.

3.4.9 Comandos de verificación básica de MQC Comando Descripción

Show class-map Muestra las clases configuradas Show policy-map Muestra las políticas configuradas Show policy-map interface Muestra el policy map aplicado a una interfaz

3.5 Implementar QoS con SDM QoS Wizard

3.5.1 Configurar QoS con Cisco SDM QoS Wizard En la sección de configuración QoS del SDM existen varias prestaciones en la definición de clases de tráfico y configuración de políticas QoS. El asistente QoS ofrece una optimización LAN, WAN y VPN efectiva y fácil. Existen 3 categorías predefinidas de necesidades de negocio:

- TIEMPO REAL: VoIP y tráfico de señalización de la voz. - CRÍTICO DE NEGOCIO: Tráfico importante para un entorno corporativo particular. Protocolos que

podrían incluirse en esta categoría son Citrix, SQLNet, LDAP, etc. Los protocolos de enrutamiento también pertenecen a esta categoría.

- MEJOR ESFUERZO: tráfico restante.

3.5.2 Creación de la Política QoS - PASO 1: Pulsar botón de configuración en la ventana SDM. - PASO 2: Pulsar Calidad de Servicio en la barra de tareas en la parte izquierda de la ventana. - PASO 3: Click en la pestaña “Crear Política QoS”. - PASO 4: Pulsamos ejecutar el asistente.

CCNP ONT

46- PASO 5: El asistente QoS SDM informa que configurará 2 clases: real-time y crítico de negocio. Le

damos a siguiente. - PASO 6: Seleccionamos una interfaz. Pulsamos siguiente. - PASO 7: Nos aparecerá una pantalla de Generación de Política QoS solicitándonos el ingreso de los

porcentajes para cada clase. Después de ingresar los números, el SDM automáticamente calculará las clases de mejor esfuerzo y los requisitos de ancho de banda para cada clase. Pulsamos siguiente y nos aparecerá un sumario de la configuración.

3.5.3 Monitoreo del Estado de QoS Entramos al modo monitor, y hacemos click en el botón “QoS Status”. Aparecen 3 estadísticas de tráfico en la barra.

CCNP ONT

47

Tema 4. Implementando el modelo QoS DiffServ

4.1 Introducción a la clasificación y marcado

4.1.1 Clasificación La clasificación es el proceso de identificar tráfico y categorizarlo dentro de clases. La clasificación usa un descriptor de tráfico para categorizar un paquete dentro de un grupo específico para definir ese paquete. Los descriptores de tráfico usados habitualmente son: Interfaces entrantes // Procedencia IP // DSCP (Punto de código de servicio diferenciado) // Dirección origen o destino // Aplicación. Usando la clasificación, los administradores de red pueden particionar el tráfico de red en múltiples clases de servicio (CoS). Cuando se usan descriptores de tráfico para clasificar paquetes, el origen implícitamente acuerda adherirse a los términos contratados y las premisas QoS. La clasificación debe realizarse en el borde de la red, normalmente en el armario de cableado, dentro de teléfonos IP o en puntos finales de la red. Cisco recomienda realizar la clasificación lo más cerca posible del origen del tráfico.

4.1.2 Marcado El marcado se refiere a la clasificación. El marcado permite a los dispositivos de red clasificar un paquete o una trama basándose en el descriptor de tráfico especificado. Las herramientas de clasificación QoS categorizan paquetes examinando los contenidos de la trama, celda y cabeceras de paquete. Para colocar a la voz y a los datos en colas separadas, por ejemplo, debemos usar alguna forma de clasificación para diferenciar los 2 tipos de tráfico y colocar cada tráfico identificado en la cola correcta. El marcado permite a las herramientas QoS cambiar bits de la cabecera del paquete para indicar el nivel de servicio que el paquete debe recibir. Sin el marcado, la trama, el paquete o la celda permanece sin cambios. El marcado utiliza un valor dentro de un pequeño número de campos bien definidos diseñados específicamente para el marcado QoS. Aunque las herramientas de clasificación o marcado no afectan directamente al ancho de banda, retardo, jitter o pérdidas, son los pilares de todas las demás herramientas QoS. Con el marcado y la clasificación, todo el tráfico de la red se identifica para que la siguiente herramienta QoS haga su función. Los descriptores de tráfico que se usan habitualmente incluyen:

- CAPA DE ENLACE DE DATOS: CoS (ISL, 802.1P) // bits EXP MPLS // Frame Relay - CAPA DE RED: DSCP // Procedencia IP.

4.1.3 Clasificación y marcado en la capa de enlace de datos El estándar 802.1Q es una especificación del IEEE para redes conmutadas que usan VLAN. El 802.1Q define 2 campos de 2 bytes (TPID: Identificador de etiqueta del protocolo (protocolo encapsulado) //

TCI: Información de etiqueta de control) que se insertan dentro de una trama Ethernet siguiente a la dirección MAC de origen. El campo TPID actualmente es fijo y tiene asignado el valor de 0x8100, lo cual indica una etiqueta 802.1Q. El campo TCI se compone de 3

campos, como vemos en la figura: - BITS DE PRIORIDAD DE USUARIO (PRI): Las especificaciones de este

campo están definidas por el IEEE 802.1P. Estos bits pueden usarse para marcar paquetes como pertenecientes a un CoS específico. Estos 3 bits permiten 8 niveles de clasificación, permitiendo una correspondencia directa con la procedencia IP (valor ToS de la cabecera IPv4).La imagen muestra las definiciones de cada CoS especificadas por el estándar 802.1P. Una desventaja de usar marcado CoS es que las tramas pierden la marca cuando transitan de un enlace no-802.1Q a un enlace no-802.1P. Tan pronto como un paquete se envía a nivel de capa 3, ya sea por un router o por un switch multicapa, la cabecera LAN antigua se descarta perdiéndose así el valor del campo CoS. Esto se soluciona habitualmente traduciendo las marcas CoS en otras marcas o, simplemente, usando un mecanismo de marcado diferente.

- CFI (INDICADOR DE FORMATO CANÓNICO): Este bit indica si el orden de los bits es canónico o no. Es utilizado para la compatibilidad entre redes Ethernet y Token Ring.

- VLAN IDENTIFIER (VLAN ID): Es un campo de 12 bits que define la VLAN usada por el 802.1Q. El hecho de que el campo sea de 12 bits de longitud restringe el número de VLANs soportadas por 802.1Q a 4096. Para la mayoría de los clientes, estas son suficientes. Para las aplicaciones de proveedores de servicio, probablemente 4096 VLAN no sean suficientes.

CCNP ONT

48CLASIFICACIÓN Y MARCADO EN LA EMPRESA Antes que el IETF definiera métodos QoS en la capa de red, el ITU-T y el Foro Frame Relay (FRF) ya realizaron estándares QoS para la capa de enlace de datos en las redes Frame Relay. Frame Relay provee

un conjunto simple de mecanismos QoS para asegurar una CIR (Velocidad contratada asegurada). Un componente del QoS Frame Relay es el descarte de paquetes cuando existe congestión en la red. Frame Relay permitirá que se envíe tráfico a velocidades superiores al CIR. Las tramas que excedan la velocidad del CIR pueden

marcarse como elegibles para el descarte (DE a 1) en el switch Frame Relay de entrada. Si existe congestión en la red, las tramas marcadas con el bit DE serán descartadas dando preferencia a las no marcadas. Los bits FECN y BECN informan de la existencia de congestión hacia delante y hacia atrás para que los switches borren del buffer las tramas que tengan con el bit DE que pudieran seguir saturando el enlace. MARCADO EN MPLS Cuando un cliente transmite paquetes IP de un sitio a otro, el campo de procedencia IP (los primeros 3 bits del campo DSCP de la cabecera del paquete IP [ToS]) especifican el CoS.

Basándose en el marcado de procedencia IP, al paquete se le da el tratamiento deseado, como ancho de banda garantizado o latencia. Los bits experimentales MPLS (EXP) se componen

de un campo de 3 bits que podemos usar para mapear la procedencia IP (ToS) a la etiqueta MPLS. Esto permite que routers habilitados para MPLS puedan realizar labores QoS basándose en el campo de procedencia IP original dentro del paquete IP encapsulado por MPLS, sin necesidad de gastar recursos en buscar dentro de la cabecera IP y examinar el campo ToS. El campo MPLS EXP permite al SP proveer QoS sin sobreescribir el valor de procedencia IP del cliente. La cabecera IP se mantiene disponible para el cliente, y el paquete marcado IP del paquete no se cambia mientras el mismo atraviesa la red MPLS. MPLS usa un etiqueta de 32 bits (cabecera shim), la cual es insertada entre las cabeceras de capa 2 y de capa 3 (en el modo trama). El campo MPLS EXP soporta hasta 8 CoS. Por defecto, el software Cisco copia los 3 bits más significantes del DSCP de la cabecera IP al campo EXP. Los bits EXP se conservan a través de la cabecera MPLS.

4.1.4 Modelo DiffServ La arquitectura DiffServ se basa en un modelo simple en el cual los paquetes de datos son colocados dentro de un número limitado de clases de tráfico, más que diferenciar el tráfico de red basándose en los requisitos de un flujo individual. Cada router en la red se configura para diferenciar tráficos basándose en su clase. Cada clase de tráfico puede ser gestionada de forma diferente, asegurando un tratamiento preferente al tráfico de alta prioridad. Los routers habilitados para DiffServ implementan conductas por salto (PHB – Per Hop Behaviors), las cuales definen las propiedades de envío de paquetes asociadas con una clase o tráfico. Todo el tráfico que fluye a través de un router que pertenece a la misma clase se le conoce como BA (comportamiento asociado). Los valores DSCP marcan paquetes para seleccionar un PHB. Dentro del núcleo de la red, los paquetes se envían de acuerdo al PHB asociado con el DSCP. Uno de los principios fundamentales de DiffServ es que los paquetes deben marcarse lo más cerca del borde de la red posible. La clasificación de pertenencia de los paquetes es a menudo una tarea difícil y larga. Deberemos clasificar los datos el menor número de veces posible. Marcando el tráfico en el borde de la red, los dispositivos del núcleo y otros existentes en el trayecto serán capaces de forma rápida de determinar el CoS correcto a aplicar a un flujo de tráfico dado. Un beneficio clave de DiffServ en comparación con IntServ es una escalabilidad más fácil. DiffServ se usa para aplicaciones de misión-crítica y para proveer QoS de extremo a extremo. DiffServ describe servicios y permite que varios servicios definidos de usuario usen una red habilitada para DiffServ. Los servicios son definidos como requisitos QoS y garantías provistas para un conjunto de paquetes con el mismo valor DSCP. Los servicios son provistos a clases. Una clase puede ser identificada como una aplicación simple o múltiples aplicaciones con similares necesidades de servicio, o puede basarse en direcciones IP de origen y destino, o en flujos de tráfico.

CCNP ONT

49La idea es que la red reconozca una clase sin tener que recibir solicitudes específicas desde las aplicaciones. Esto permite que los mecanismos QoS se apliquen a otras aplicaciones que no tienen funcionalidades RSVP (Protocolo de Reserva de Recursos), lo cual es el caso del 99% de las aplicaciones que usan IP.

4.1.5 Procedencia IP y compatibilidad DSCP La introducción de DSCP reemplaza la procedencia IP, un campo de 3 bits en el byte ToS de la cabecera IP original usado para clasificar y priorizar tipos de tráfico. Sin embargo, DiffServ mantiene la interoperabilidad con dispositivos no habilitados para DiffServ (es decir, aquellos que todavía usan la procedencia IP). Debido a esta compatibilidad retrospectiva de DiffServ, podemos desplegarlo granularmente en redes grandes.

El significado de los 8 bits del campo DiffServ del paquete IP ha cambiado con el tiempo para alcanzar una expansión en los requisitos de las redes IP. Originalmente, el campo se refería al campo ToS, y los primeros 3 bits definían un valor de procedencia IP. Un paquete podría ser asignado a 6 prioridades basándose en el valor de procedencia IP (2 valores de los 8 quedan reservados). La procedencia IP de 5 tenía la prioridad más alta que podría ser asignada.

En 1998, el RFC 2474 reemplazó el campo ToS con el campo DiffServ, en el cual un rango de 8 valores (selector de clase) se usaba para compatibilidad retrospectiva con la procedencia IP. No hay compatibilidad con los demás bits del campo ToS. El RFC 1812 simplemente prioriza paquetes de acuerdo al valor de procedencia IP. Por ejemplo, consideremos un SP que ofrece un servicio de clases llamado “Olympic” (Oro, Plata

y Bronce). Los paquetes de la clase oro tendrán una prioridad mayor, y así hacia abajo.

4.1.6 Comportamientos por Salto Un PHB es una descripción de un comportamiento de envío de un nodo DiffServ aplicado a una clase (BA) de DiffServ particular. Por ejemplo, en el evento que sólo un BA ocupe un enlace, el comportamiento de envío observable (esto es, pérdidas, retrasos y jitter) dependerá a menudo sólo de la carga relativa del enlace. Las distinciones de comportamientos más útiles se observan principalmente cuando existen múltiples BAs compitiendo por los recursos de buffer y ancho de banda de un nodo. Un PHB puede ser especificado en términos de sus recursos (como buffer, ancho de banda, etc.), prioridad relativa con respecto a otros PHBs, o en términos de sus características de tráfico relativas observables (como retardos o pérdidas). Una definición de grupos PHB debe indicar posibles conflictos con grupos PHB previos que para prevenir una operación simultánea. La arquitectura DiffServ define el campo DS (DiffServ), el cual sustitye el campo ToS en IPv4 para realizar decisiones PHB sobre la clasificación de paquetes y las funciones de condiciones de tráfico, como “metering”, “marking”, “shaping” y “policing”. Como recordatorio:

- METERING (MEDIR): Es el proceso de medir las propiedades temporales (por ejemplo la cantidad) de un stream de tráfico seleccionado por un clasificador. El estado instantáneo de este proceso puede usarse para afectar la operación de “moldeo” (Shaper), borrado, etc.

- MARKING (MARCAR): Es el proceso de configurar el DSCP de un paquete basándose en reglas definidas.

- SHAPING (MOLDEAR): Es el proceso de retrasar paquetes dentro de un stream de tráfico para provocar que el tráfico se adapte a algunos perfiles de tráfico definidos.

- POLICING (DECIDIR SI BORRAR): Es el proceso de descartar paquetes dentro de un stream de tráfico de acuerdo al estado de una medida correspondiente.

El IETF define los siguientes PHBs: - PHB POR DEFECTO: Usado para un servicio de mejor esfuerzo (bits 5 a 7 de DSCP = 000). - PHB ENVÍO ÁGIL (EF): Usado para un servicio de baja retardo (bits 5 a 7 de DSCP = 101). - PHB ENVÍO ASEGURADO (AF): Usado para servicios de ancho de banda garantizado (bits 5 a 7 del

DSCP iguales a 001, 010, 011 o 100).

CCNP ONT

50- SELECTOR DE CASE PHB: Usado para compatibilidad retrospectiva con dispositivos no habilitados para

DiffServ (RFC 1812, bits 2 a 4 del DSCP = 000).

EF PHB En la figura se aporta una vista detallada de EF PHB usado por DSCP. El PHB EF se identifica basándose en lo siguiente:

- EL PHB EF ASEGURA UNA CANTIDAD MÍNIMA DE PARTIDA: Provee el retardo más baja posible a aplicaciones sensibles a demoras.

- EL PHB EF GARANTIZA ANCHO DE BANDA: Previene la saturación de un enlace si existen múltiples aplicaciones usando PHB EF.

- PHB EF DESCARTA CUANDO EXISTE CONGESTIÓN: El EF PHB previene la inanición de otras aplicaciones o clases que no están usando este PHB.

Los paquetes que requieren EF deben marcarse con un DSCP de 101110 (46 o CX2E). Los dispositivos que no están habilitados para DiffServ consideran un valor 101110 como valor de procedencia IP de 5 (101). Esta procedencia es el valor mayor definible de procedencia IP para estos dispositivos, y es

típicamente usado para tráfico sensible a demoras (como VoIP). AF PHB El AF PHB se identifica basándose en lo siguiente:

- El AF PHB garantiza una cierta cantidad de ancho de banda a una clase AF. - El AF PHB permite acceder a ancho de banda extra, si existe disponible.

Los paquetes que requieren AF PHB deben marcarse con un valor DSCP de aaadd0, donde aaa es el número de la case y dd es la probabilidad de borrado (como se ve en la figura). Existen 4 clases estándar de AF definidas: AF1, AF2, AF3 y AF4.

Cada clase debe tratarse de forma independiente y debería tener su ancho de banda localizado basándose en la política QoS. CLASE PROBABILIDAD BORRADO DSCP

AF CLASS 1 AF11 (bajo) 001 01 0 AF12 (medio) 001 10 0 AF13 (alto) 001 11 0 AF CLASS 2 AF21 (bajo) 010 01 0 AF22 (medio) 010 10 0 AF23 (alto) 010 11 0

CLASE PROBABILIDAD BORRADO DSCP

AF CLASS 3 AF31 (bajo) 011 01 0 AF32 (medio) 011 10 0 AF33 (alto) 011 11 0 AF CLASS 4 AF41 (bajo) 100 01 0 AF42 (medio) 100 10 0

AF43 (alto) 100 11 0

4.1.7 Grupos PHB Estándar Con la habilidad del sistema para marcar paquetes de acuerdo a la configuración DSCP, una colección de paquetes (con la misma configuración DSCP y enviados a una dirección particular) pueden ser agrupados dentro de un BA. Los paquetes desde múltiples orígenes o aplicaciones pueden pertenecer al mismo BA. El IETF define un grupo PHB como un conjunto de una o más PHBs que pueden ser especificadas e implementadas en simultáneo, debido a una restricción común aplicada a todas las PHBs del conjunto, como un servicio de colas o una política de gestión de colas. En otras palabras, un grupo PHB se refiere a una programación de paquetes, colas, políticas o comportamientos de moldeo de un nodo o cualquier paquete perteneciente a una BA. La PHB por defecto especifica que un paquete marcado con un valor DSCP de 000000 recibe un servicio de mejor esfuerzo desde un nodo habilitado para DiffServ. Si un paquete llega a un nodo habilitado para DiffServ y el valor DSCP no se mapea a uno PHB, el paquete es mapeado a esta servicio. El PHB AF define 4 clases AF. Cada clase tiene asignada cantidad específica de espacio en el búfer y ancho de banda. Está permitido obtener ancho de banda desde otras clases AF si el mismo está disponible. Los PHB EF definen una clase, la cual asigna a una cantidad fija de ancho de banda sólo para esa clase.

CCNP ONT

51

4.1.8 Mapeo del CoS al QoS de la capa de Red Las cabeceras IP se mantienen de extremo a extremo cuando los paquetes IP se transportan a lo largo de

una red, sin embargo las cabeceras de capa 2 no. Esto significa que la capa IP es el lugar más lógico donde marcar paquetes para un QoS de extremo a extremo. Sin embargo, existen dispositivos que pueden marcar tramas sólo en la capa 2, y existen otros dispositivos que operan sólo en la capa 3. Para proveer un QoS real de extremo a extremo, es esencial el mapeo de marcas QoS entre la capa de enlace de datos y la capa de red. Las redes empresariales consisten típicamente de un número de sitios remotos conectados a un HQ vía WAN. Los sitios remotos consisten típicamente en una LAN switcheada, y la red de campus del HQ es switcheada y enrutada. Si se provee QoS de extremo a extremo se requiere que las marcas CoS que se configuran en el borde LAN se

mapeen dentro de marcas QoS (como procedencia IP o DSCP) para el tránsito a través de los routers del Campus o WAN. Los routers de campus y WAN también pueden mapear las marcas QoS a nuevas cabeceras de capa 2 para su tránsito. Los proveedores de servicio también ofrecen servicios IP con soluciones robustas de QoS a sus clientes. La compatibilidad entre MPLS y la capa de red es lograr mapear los bits EXP de MPLS a los bits de procedencia IP o DSCP.

4.1.9 Clase de servicio QoS definida Cuando creamos una política administrativa que requiere QoS, debemos determinar cómo se tratará al tráfico de red. Como parte de la definición, el tráfico de red debe asociarse con una clase de servicio específica. Una clase de servicio, siendo ello un grupo lógico, puede definirse de varias formas:

- Por organización o departamento (por ejemplo, marketing, ingeniería y ventas). - Un cliente específico o conjunto de clientes. - Aplicaciones específicas o conjuntos de aplicaciones (por ejemplo Telnet, FTP, voz, Oracle, etc…). - Usuarios específicos o conjuntos de usuarios (basados en MAC, IP, puerto LAN, por ejemplo). - Destinos de red específicos (como interfaces túnel y VPN.

En la figura se muestra como definir clases de servicio QoS. Un administrador de red quiere aplicar QoS a la red corporativa para mejorar el control de localización de ancho de banda para las diferentes aplicaciones de red. Antes que el QoS pueda aplicarse, se debe definir primero una política QoS administrativa, como vemos en el ejemplo. En el ejemplo, el 15% restante de ancho de banda disponible se reserva para la gestión, señalización y enrutamiento. Estos porcentajes no son valores necesariamente recomendados, simplemente representan este ejemplo en particular.

4.1.10 Implementar una política QoS usando una clase de servicio QoS Especificar una política administrativa QoS requiere que un conjunto de clases de servicio específicas se definan. Los mecanismos QoS se aplican de forma uniforme a estas clases de servicio individuales para cumplir los requisitos de la política. El primer paso es identificar el tráfico de la red y los requisitos QoS para cada tráfico. Entonces, el tráfico puede ser agrupado dentro de un conjunto de clases de servicio para un tratamiento diferenciado QoS en la red.

Aunque existen muchas variaciones, en la figura se muestra un modelo de cliente que define varias clases de servicio típicas: LA CLASE DE VOZ: entrega servicios de voz con baja lantencia. LA CLASE MISIÓN-CRÍTICA: Garantiza latencia y entrega para el transporte de aplicaciones críticas para el negocio. LA CLASE TRANSACCIONAL garantiza entrega y se usa para aplicaciones generales que no son sensibles a demoras en comparación con las

CCNP ONT

52misión-critica. LA CLASE DE MEJOR ESFUERZO usada para dar soporte a correos electrónicos y otras aplicaciones de mejore esfuerzo. Una política administrativa debe ser proactiva y requiere cuantas menos clases de servicio mejor. Una buena regla es limitar el número de clases de servicio a no más de cuatro o cinco. Un elemento clave a la hora de definir clases de servicio QoS es comprender las necesidades de calidad básicas de las aplicaciones de red. Es esencial que las aplicaciones reciban un tratamiento QoS acorde a sus necesidades. EJEMPLO: CLASES DE SERVICIO DE APLICACIÓN Aunque existen documentos para usar como guías para determinar una política QoS, ninguno de ellos puede determinar de forma exacta cual es el correcto para una red específica. Para implementar correctamente el QoS, se deben declarar metas medibles, y entonces se debe formular e implementar un plan para logar estas metas. QoS debe ser implementado de forma consistente a lo largo de la red entera. En este ejemplo, se

desplegará una política QoS y se definirán varias clases de servicio para los flujos. Como vemos en la figura, los flujos de tráfico pueden ser clasificados con una procedencia IP de 5, PHB EF, o un DSCP de 46. Dependiendo del diseño QoS de la red, los valores de clasificación se mapean en los bits MPLS, por ejemplo.

4.1.11 Límites de Confianza Un límite de confianza es el punto dentro de la red donde ocurre un marcado CoS o DSCP que será aceptado.

En la figura vemos una estructura jerárquica de red. La localización del límite de confianza depende de las capacidades de los dispositivos de acceder al borde de la LAN. El límite de confianza puede ser implementado en una de las siguientes 3 localizaciones: Sistema final // Capa de acceso // Capa de distribución.

Los puntos finales de confianza tienen capacidades e inteligencia para marcar tráfico de aplicación a los valores CoS y/o DSCP apropiados. Los puntos finales también tienen la capacidad de re-marcar tráfico que ha sido previamente marcado por un dispositivo sin confianza. Ejemplos de puntos finales de confianza son: Sistemas y gateways de videoconferencia // Estaciones de Conferencia // Puntos de acceso Wireless. Cuando un dispositivo de confianza se conecta a un puerto de switch, se requiere típicamente ingresar solamente el comando (config-if)#mls qos trust dscp en la interfaz del switch. Si el punto final no es de confianza y el switch del armario de cableado tiene inteligencia QoS, el límite de confianza será movido a dicho dispositivo. Si el punto final no es de confianza y el switch del armario de cableado al que conecta no tiene capacidades QoS, el límite de confianza será movido a la capa de distribución, dentro del switch o el router que recibe el tráfico de la capa de acceso. LÍMITES DE CONFIANZA: TELÉFONOS IP Y ORDENADORES

En la figura se muestra el desafío de seleccionar el lugar apropiado donde marcar el límite de confianza. No se recomienda generalmente confiar en usuarios finales y sus PCs ya que los nuevos sistemas operativos como XP, Vista o Linux hacen relativamente sencillo configurar marcas CoS o DSCP en la NIC. El uso de marcas incorrectas QoS puede afectar a los niveles de servicio de otros usuarios de la empresa. Una de las principales ventajas de la

CCNP ONT

53telefonía IP es la simplicidad y ahorro en costes es añadir, mover o cambiar a un usuario. Para mover un usuario, este simplemente coge el teléfono IP y lo coloca en su nueva localización. Los teléfonos IP son dispositivos de confianza, mientras que los PC no. Esto puede ser un problema cuando se aprovisiona límites a un entorno móvil. Por ejemplo, el puerto A se configura para confiar en el punto final conectado a él, el cual inicialmente es un teléfono IP. El puerto B se configura para no confiar en el punto final conectado a él, el cual es inicialmente un PC. Debido al cambio, estos dispositivos se conectarán a los puertos opuestos. Este cambio provocará fallos en la calidad de las llamadas VoIP desde el teléfono IP y abrirá a la red a un abuso sin intención o deliberado de aprovisionamiento QoS por el PC. Los switches Cisco con inteligencia QoS usan CDP para descubrir si el dispositivo que se conecta a su puerto puede ser de confianza. Si el dispositivo es de confianza (como un teléfono IP9, el switch extiende el límite hasta el mismo de forma dinámica. Si CDP determina que el dispositivo puede que no sea de confianza (como un PC), el switch no extiende el límite de confianza hasta el dispositivo. Generalmente se recomienda que el tráfico de PC de usuario final no sea de confianza. Sin embargo, algunos PC ejecutan aplicaciones críticas que requieren un tratamiento QoS. Un ejemplo clásico es un PC que ejecuta el Cisco Ip Communicator. En este caso, la aplicación necesita identificarse usando una ACL y marcando o re-marcando en el borde de acceso. Si el switch de la capa de acceso no es capaz de marcar tráfico, deberá ser la capa de distribución la que realice la labor.

4.2 Uso de NBAR para la clasificación

4.2.1 Reconocimiento de aplicación basado en red (NBAR) NBAR es una prestación de clasificación y de descubrimiento de protocolo del software Cisco IOS que reconoce una amplia variedad de aplicaciones, incluyendo aquellas basadas en web y aplicaciones cliente/servidor que asignan de forma dinámica puertos TCP o UDP. Una vez que NBAR reconoce una aplicación, la red puede invocar servicios específicos para esa aplicación particular, como garantizar ancho de banda a aplicaciones críticas, limitar el ancho de banda a otras, borrar paquetes de forma selectiva para prevenir la congestión y marcar paquetes de forma apropiada para que la red y el ISP puedan proveer QoS de extremo a extremo. Algunos ejemplos de prestaciones QoS basadas en clases que pueden usarse en el tráfico después que el mismo ha sido clasificado por NBAR pueden ser:

- Marcado basado en clases (el comando set ) - CBWFQ (los comandos bandwidth y queue-limit ). - Cola de baja latencia (LLQ) (el comando priority ). - Política de tráfico (el comando police ). - Modelado de tráfico (el comando shape ).

NBAR realiza las siguientes 2 funciones: Identificación de aplicaciones y protocolos (capa 4 a capa 7) // Descubrimiento de protocolos. PRESTACIONES DE CLASIFICACIÓN NBAR introduce varias prestaciones nuevas de clasificación que identifican aplicaciones y protocolos desde la capa 4 hasta la 7:

- Números de puerto TCP y UDP asignados de forma estática. - Protocolos no UDP o TCP. - Números de puerto TCP y UDP asignados de dinámicamente. La clasificación de estas aplicaciones

requiere una inspección “stateful”, esto es, la habilidad de descubrir conexiones de datos para ser clasificadas analizando las conexiones donde la asignación de puertos se ha realizado.

- Clasificación de sub-puerto o clasificación basada en una inspección profunda, esto es, clasificación mirando profundamente dentro del paquete.

NBAR puede clasificar puertos de protocolo estáticos. Aunque las ACL también pueden usarse para este propósito, NBAR es más fácil de configurar y puede proveer estadísticas de clasificación que no están disponibles con las ACL. DESCUBRIMIENTO DE PROTOCOLOS NBAR incluye una prestación de descubrimiento de protocolo que provee una forma sencilla de descubrir protocolos de aplicación que están atravesando una interfaz. El descubrimiento de protocolos mantiene las siguientes estadísticas por protocolo en interfaces habilitadas para su uso:

- Número total de paquetes de entrada y salida y bytes. - Cantidad de bits de entrada y salida.

AGREGAR NUEVAS APLICACIONES Se pueden añadir nuevas aplicaciones a NBAR usando un PDLM (Módulo de descripción del lenguaje del paquete) que puede cargarse para extender la lista de protocolos reconocidos por NBAR. Esta función permite a NBAR reconocer nuevos protocolos sin necesidad de tener que utilizar una nueva imagen IOS. RESTRICCIONES Se debe habilitar CEF antes de configurar NBAR. NBAR no soporta lo siguiente:

- Más de 24 coincidencias simultáneas de URLs, hosts o Extensiones de correo multipropósito (MIME). - Coincidencias posteriores a los primeros 400 bytes del payload. - Modos de conmutación y multicast distintos a CEF. - Paquetes fragmentados.

CCNP ONT

54- Clasificación de URL, hosts o MIMEs con HTTPS. - Paquetes originados desde o hacia el router que ejecuta NBAR.

NBAR no es soportado en Fast EtherChannel, pero sí lo es en interfaces Gigabit Ethernet. Las interfaces configuradas en modo túnel o con cifrado no soportan NBAR. NBAR no puede usarse para clasificar tráfico de salida en un enlace WAN donde se usa tunneling o cifrado. Por tanto, NBAR debe configurarse en otras interfaces del router (como un enlace LAN) para realizar la clasificación de entrada antes de que el tráfico se conmute al enlace WAN de salida. Sin embargo, el descubrimiento de protocolos NBAR si es soportado en interfaces túnel o donde se usa cifrado. Podemos habilitar NBAR directamente en el túnel o en la interfaz donde se realiza el cifrado para obtener estadísticas clave acerca de las aplicaciones diferentes que atraviesan la interfaz. Las estadísticas de entrada muestran el total de paquetes tuneleados o cifrados recibidos.

4.2.2 Soporte de aplicación NBAR NBAR puede clasificar el tráfico de aplicaciones mirando detrás de los números de puerto TCP y UDP de un paquete. A esto se le conoce como clasificación sub-puerto. NBAR mira dentro del payload TCP/UDP y clasifica paquetes según el contenido del payload, como identificador de transacción, tipo de mensaje u otros datos similares. La clasificación de HTTP por URL, host o MIME es un ejemplo de la clasificación subpuerto. NBAR clasifica el tráfico HTTP por el texto dentro de la URL usando una coincidencia de expresiones regulares (REGEX). Las coincidencias HTTP URL de NBAR soportan la mayoría de los métodos de solicitud HTTP como GET, PUT, HEAD, POST, DELETE y TRACE. NBAR reconoce paquetes que pertenecen a diferentes tipos de aplicaciones:

- Aplicaciones estáticas que establecen sesiones con puertos de destino bien conocidos TCP y UDP. - Aplicaciones dinámicas que usan sesiones múltiples con puertos TCP y UDP dinámicos. - Algunos protocolos no IP, como IPX, pueden ser reconocidos por NBAR. - NBAR también tiene la capacidad de inspeccionar algunas aplicaciones para otra información y

clasificar paquetes basándose en esta información. Por ejemplo, NBAR puede clasificar sesiones HTTP basándose en la URL solicitada.

4.2.3 PDLM NBAR soporta actualizaciones dinámicas sin tener que cambiar de versión de IOS o reiniciar el router. Los PDLM contienen las reglas usadas por NBAR para reconocer una aplicación coincidiendo patrones de texto en los paquetes de datos. Se puede cargar un PDLM externo para extender la lista de protocolos reconocidos por NBAR. Para extender la lista de protocolos reconocidos por NBAR a través de un PDLM provisto por Cisco, usaremos el comando (config)#ip nbar pdlm <nombre-pdlm> . El parámetro nombre-pdlm debe estar en un

formato URL, puede apuntar a la flash donde se almacena el cisco IOS (por ejemplo: flash://citrix.pdlm). El fichero también puede localizarse en un servidor TFTP. Para configurar NBAR para buscar un protocolo que usa un número de puerto diferente a los bien conocidos, usaremos el comando (config)#ip nbar port-map <nombre-protocolo> [tcp | udp ] <puerto> . Con el comando show de la figura mostramos los mapeos puerto-protocolo en uso por NBAR.

4.2.4 Descubrimiento de Protocolos Para desarrollar y aplicar políticas QoS, NBAR incluye una prestación de descubrimiento de protocolo que provee una forma fácil de descubrir protocolos de aplicación que están en tránsito en una interfaz. Esta prestación captura estadísticas clave asociadas con cada protocolo en la red (contador de paquetes, de bytes y cantidad de bits) en una base por interfaz. El descubrimiento de protocolos puede aplicarse a interfaces y usarse para monitorear el tráfico de entrada y de salida.

4.2.5 Configurar y monitorear el descubrimiento de protocolos NBAR La prestación NBAR tiene dos componentes:

- Uno que monitorea aplicaciones que atraviesan la red. - Otro que clasifica el tráfico por protocolo.

Para monitorear aplicaciones que atraviesan la red, el protocolo de descubrimiento NBAR debe estar habilitado. La habilidad para clasificar tráfico por protocolo usando NBAR y aplicar QoS al tráfico clasificado se realiza usando la CLI Cisco Modular QoS (MQC). Para habilitar el descubrimiento de protocolos NBAR se usa el comando (config-if)#ip nbar protocol-discovery . Para mostrar las estadísticas donde se ha habilitado el protocolo de descubrimiento de NBAR se usa el comando #show ip nbar protocol-discovery .

CCNP ONT

55El descubrimiento de protocolos NBAR puede monitorear tráficos de entrada y salid. Esta prestación almacena estadísticas de paquetes conmutados a interfaces de salida. Estas estadísticas no son necesariamente paquetes salientes de la interfaz del router, ya que algunos de estos habrán sido borrados por varias razones (políticas de la interfaz de salida, ACL o colas de borrado).

4.2.6 Configuración de NBAR para protocolos estáticos Cuando configuramos NBAR, el administrador no necesita comprender como trabajan ciertos protocolos. La configuración simplemente requeire que el administrador ingrese el nombre del protocolo. Recordar que las configuraciones NBAR se realizan siempre desde la MQC. En el comando (config-cmap)#match protocol <nombre-protocolo> , el nombre del protocolo se refiere al protocolo usado como criterio de coincidencia. Algunos protocolos soportados serían los

siguientes: arp , cdp , compressedtcp , dlsw , ip , ipx , etc. Algunos protocolos pueden usar puertos TCP y UDP adicionales (como un servidor web trabajando en el puerto 8080). Usaremos el comando (config-cmap)#ip nbar port-map para extender las funciones NBAR para protocolos bien conocidos asociados a números de puerto nuevos. En la figura se muestra un ejemplo de configuración para un servidor web que trabaja en los puertos 80 y 8080.

4.2.7 Configuración de NBAR stateful para protocolos dinámicos Como vemos en la figura, NBAR mejora las opciones de clasificación para HTTP. Puede clasificar paquetes pertenecientes a flujos HTTP basándose en lo siguiente:

- La porción URL después del nombre de host, la cual aparece en la solicitud GET de la sesión HTTP. - El nombre de host especificado en la solicitud GET.

El siguiente ejemplo clasifica, dentro del class-map llamado “class1”, paquetes HTTP basados en cualquier URL que contenga la cadena “whatsnew/latest” seguida de cero o más caracteres. class-map class1 match protocol http url whatsnew/latest*

El siguiente ejemplo clasifica, dentro del class-map llamado “class2”, paquetes basados en cualquier nombre de host que contenga la cadena “cisco” seguido de cero o más caracteres: class-map class2 match protocol http host cisco*

El siguiente ejemplo clasifica, dentro del class map llamado “class3”, paquetes basados en el tipo JPEG: class-map class3 match protocol http mime “*jpeg”

Una expresión regular se usa para identificar tráfico “FastTrack” específico. Aplicaciones que usan el protocolo punto a punto FastTrack son por ejemplo el KazaA, Grokster y Morpheus. Para especificar que todo el tráfico FastTrack sea identificado por la clase de tráfico, usamos la expresión regular “*”. En el siguiente comando se muestra como hacer coincidir todo el tráfico FastTrack: match protocol fasttrack file-transfer “*”

En el siguiente ejemplo, todos los ficheros FastTrack que tengan la extensión .mpeg serán clasificados dentro del class-map nbar: class-map match-all nbar match protocol fasttrack file-transfer “*.mpeg” En el siguiente ejemplo se configure NBAR para coincidir el tráfico FastTrack que contenga la cadena “cisco”. match protocol fasttrack file-transfer “*cisco*”

CCNP ONT

56 En la figura se alistan varias expresiones regulares y su descripción.

El protocolo RTP consiste en una parte de datos y otra de control. La parte de control se la conoce como RTCP. Es importante anotar que la clasificación NBAR del payload RTP no identifica paquetes RTCP y que los paquetes RTCP ejecutan puertos “raros”, mientras que los paquetes RCP ejecutan puertos uniformes. La parte de datos de RTP es un protocolo delgado que provee soporte a aplicaciones con propiedades de tiempo-real (como un audio-vídeo continuo), el cual incluye reconstrucción de tiempo, detección de pérdida, identificación de contenido y seguridad. El tipo de payload RTP son los datos transportados por RTP en un paquete, por ejemplo muestras de audio y datos de vídeo comprimidos. La clasificación del payload RTP por NBAR no sólo permite identificar de forma stateful tráfico de audio y vídeo a tiempo real, si no también diferenciar en base a los códecs de vídeo y audio para proveer un QoS más granular. EJEMPLO DE CLASIFICACIÓN DE UNA SESIÓN RTP

En la figura se muestra una clasificación simple de sesiones RTP, en las interfaces de entrada y salida del router. En la interfaz de entrada se han creado 3 class maps: voice-in , videoconference-in e interactive-in . El class-map voice-in coincidirá el protocolo de audio RTP, el class-map videoconference-in coincidirá el protocolo de vídeo RTP y el class-map interactive-in coincidirá el protocolo Citrix.

La política class-mark hará entonces lo siguiente: - Si el paquete coincide con el class-map voice-in , el campo DSCP será configurado a un valor EF

(Expedited Forwarding). Si el paquete coincide con el class map videoconference-in , el campo DSCP se configurará con un AF41. Si el paquete coincide con el class map interactive-in , el campo DSCP se configurará a un AF31.

- La política class-mark se aplica a la interfaz de entrada Ethernet 0/0. En la interfaz de salida se han creado 3 class maps: voice-out , videoconferencing-out e interactive-out . El class map voice-out coincidirá con campos DSCP EF. El videoconferencing-out coincidirá con campos DSCP AF41. El interactive-out coincidirá con campos DSCP AF31. Como vemos en la figura, la política qos-policy hará lo siguiente:

- Si el paquete coincide con el class-map voice-out , la prioridad del paquete será configurada a un 10% de ancho de banda. Si coincide con el videoconferencing-out , la prioridad del paquete será configurada al 20% del ancho de banda. Si coincide con el interactive-out , la prioridad del paquete será configurada al 30% del ancho de banda. Todos los demás paquetes serán clasificados como class-default .

- La política qos-policy se aplica a la interfaz de salida serial 0/0.

4.3 Introducción a implementaciones de Colas

4.3.1 Congestión y colas La congestión puede producirse en cualquier parte dentro de la red donde existan velocidades diferentes (por ejemplo, un enlace de 1000Mbps con otro de 100Mbps) o por la confluencia de 2 o más streams de tráfico.

CCNP ONT

57La gestión de la congestión controla la congestión cuando la misma se produce. Una forma de que los elementos de red manipulen una sobrecarga de tráfico es usar un algoritmo de colas que clasifique el tráfico y determine algunos métodos de prioridad en el enlace de salida. Cada algoritmo de colas fue diseñado para resolver un tráfico de red específico y tiene un efecto particular en el funcionamiento. EJEMPLO: CONGESTIÓN CAUSADA POR VELOCIDADES DISTINTAS

Las diferencias de velocidad son la causa más típica de congestión en una red. Es posible tener congestiones continuas cuando el tráfico se mueve de una LAN a una WAN.

EJEMPLO: CONGESTIÓN CAUSADA POR AGREGADOS El segundo origen de congestión más común es un punto de agregados de una red, como vemos en la figura. Los puntos típicos de agregación ocurren en WANs donde múltiples sitios remotos se conectan a un sitio central. En un entorno LAN la congestión por agregados ocurre en la capa de distribución donde los dispositivos de acceso se conectan al switch de distribución.

4.3.2 Gestión de Congestión: algoritmos de colas Las colas se diseñan para acomodar congestiones temporales en una interfaz de un dispositivo de red almacenando los paquetes excedentes en búfers hasta que el ancho de banda vuelva a estar disponible o hasta que la profundidad de la cola se exceda, y los paquetes tengan que borrarse. La gestión de la congestión comprende la creación de colas, la asignación de paquetes a estas colas basándose en la clasificación del paquete, y la programación de los paquetes en una cola para su transmisión. Los routers Cisco soportan varios métodos de colas para alcanzar los requisitos de ancho de banda, jitter y retardo de las diferentes aplicaciones. El mecanismo por defecto en la mayoría de las interfaces es una cola FIFO (primero en entrar, primero en salir). Algunos tipos de tráfico, como voz y vídeo, tienen otros requisitos de de retardo y jitter, por lo que se deben configurar mecanismos de colas más sofisticados en las interfaces usadas por el tráfico de voz y vídeo. COLAS Y CONGESTIÓN Las colas complejas ocurren generalmente en interfaces salientes solo. Durante períodos con carga de tráfico bajas, donde no existe congestión, los paquetes dejan la interfaz tan pronto como llegan a la misma. Durante períodos de congestión en la interfaz saliente, los paquetes llegan más rápido de lo que la interfaz puede re-enviarlos. Cuando se usan prestaciones de gestión de congestión, los paquetes acumulados en una interfaz se colocan en colas de software de acuerdo a su prioridad asignada y el mecanismo de colas configurado en la interfaz. Estos son entonces programados para una transmisión cuando el búfer del hardware de la interfaz está libre para enviarlos. Los algoritmos de colas principales son FIFO, PQ (Priority Queuing), Round Robin y WRR (Weigthed Round Robin).

CCNP ONT

58

4.3.3 FIFO FIFO es el algoritmo de colas más simple y el modelo predeterminado. En su forma más simple, las colas FIFO, también conocidas como primero en entrar, primero en salir, almacenan paquetes cuando la red está congestionada y los envían en el orden de llegada cuando la red deja de estar congestionada. FIFO no toma decisiones acerca de la prioridad de los paquetes. Sólo hay una cola y todos los paquetes se tratan por igual. FIFO es el método de colas más rápido y es efectivo en enlaces que tienen un retardo pequeño y una congestión mínima. Todas las colas son, en realidad, colas FIFO. NOTA: Las interfaces seriales a E1 (2048) y superiores usan WFQ por defecto.

4.3.4 Prioridad de colas (PQ) PQ permite priorizar tráfico en la red. Para ello configuramos 4 prioridades de tráfico. Podemos definir una serie de filtros basados en las características del paquete para provocar que el router coloque el tráfico en una de estas 4 colas. La cola con mayor prioridad se sirve primero hasta que está vacía, en ese momento las colas inferiores se sirven secuencialmente. Durante la transmisión, PQ da prioridad preferencial absoluta a las colas de mayor nivel. Los paquetes se clasifican en base a criterios especificados por el usuario. Una lista de prioridades es un conjunto de reglas que describen como se deben asignar los paquetes a las colas de prioridad. Esta lista también describe una prioridad por defecto y limites de tamaño de colas. Los paquetes pueden ser clasificados en base a lo siguiente: Tipo

de protocolo // Interfaz entrante // Tamaño de paquete // Fragmentos // ACL. Los keepalives originados por el servidor de red siempre se asignan a la cola de mayor prioridad. El resto de tráfico de gestión (como EIGRP, por ejemplo) debe ser configurado. PQ provee un tratamiento preferencial absoluto al tráfico de alta prioridad, asegurándose que el tráfico de misión-crítica que atraviesa varios enlaces WAN tenga un tratamiento preferente. Cuando escojamos usar PQ, debemos considerar que al tráfico de baja prioridad a menudo se le deniega ancho de banda a favor del tráfico de alta prioridad, por lo que en el peor caso el resultado es que este tráfico nunca se transmita. Para prevenir este problema, podemos usar un moldeo de tráfico (traffic-shaping) para limitar la cantidad de tráfico de alta prioridad. Con PQ habilitado, el sistema tarda más en conmutar paquetes. Además, PQ usa una configuración estática que no se adapta rápidamente a condiciones de cambio de la red.

4.3.5 Round Robin El round robin se refiere a un arreglo que incluye escoger todos los elementos en un grupo de forma equitativa en algún orden racional, normalmente empezando de arriba abajo y volviendo de nuevo arriba, y así sucesivamente. Una forma sencilla de pensar que es round robin es un esquema “por turnos”. Con las colas round robin, se coge un paquete de cada cola y el proceso se repite. Si todos los paquetes son del mismo tamaño, todas las colas comparten el mismo ancho de banda de forma equitativa. Ninguna cola “pasa hambre” con round robin ya que todas las colas tienen una oportunidad de despachar un paquete en cada turno. Como limitación obtenemos que no se puede priorizar tráfico.

WEIGTHED ROUND ROBIN (WRR) Con WRR, se accede a los paquetes de una forma round robin, pero las colas pueden tener prioridades llamadas “pesos” (weights). Por ejemplo, en una vuelta, 4 paquetes de una clase de alta prioridad pueden ser despachados, seguidos de 2 de una clase de prioridad media y 1 de una clase de baja prioridad. Algunas implementaciones WRR proveen prioridades despachando un número configurable de bytes en cada vuelta, en lugar de paquetes. El mecanismo CQ de Cisco (Custom Queuing) es un ejemplo de esta implementación. El límite o peso de la cola se configura en bytes. La precisión de las colas WRR depende del peso (contador de bytes) y de la MTU. Si el radio entre el contador de bytes y la MTU es muy pequeño, WRR no localizará el ancho de banda de forma correcta. Si es muy grande, WRR causará grandes retardos.

CCNP ONT

59

4.3.6 Componentes de colas de router La formación de colas consta de 2 partes, como vemos en la figura:

UNA COLA DE HARDWARE: Que usa una estrategia FIFO (siempre) para transmitir paquetes uno por uno. La cola de hardware es a menudo referida como cola de transmisión. UNA COLA DE SOFTWARE O

SISTEMA: Que programa paquetes dentro de la cola de hardware basándose en los requisitos QoS. A continuación se describen las acciones que deben producirse antes de transmitir un paquete:

- La mayoría de los mecanismos de colas incluyen la clasificación de paquetes. - Después que un paquete es clasificado, un router tiene que determinar si puede colocar al mismo en

la cola o borrarlo. La mayoría de los mecanismos de colas borrará un paquete sólo si la cola correspondiente está llena (tail drop).

- Si el paquete tiene permitido entrar a la cola, se coloca en la cola FIFO para su clase particular. - Los paquetes son entonces tomados de las colas individuales por clase y colocadas en la cola de

hardware. LA COLA DE SOFTWARE

La implementación de colas de software se optimiza para periodos donde la interfaz no está congestionada. El sistema de cola de software se pasa por alto si no hay paquetes en la cola de software y hay sitio en la cola de hardware. La cola de software se activa sólo cuando los datos deben esperar para ser colocados dentro de la cola de hardware.

LA COLA DE HARDWARE Si la cola de hardware es muy grande, contendrá un gran número de paquetes programados de una forma FIFO. La cola de hardware es cola FIFO de la interfaz final que guarda tramas para ser inmediatamente transmitidas por la interfaz física. Cada vez que un paquete se transmite el driver de la interfaz interrumpe a la CPU y solicita más paquetes para ser entregados a la cola de hardware. Algunos mecanismos de colas tienen programaciones complejas que toman cierto tiempo en entregar paquetes. La interfaz no enviará nada durante este tiempo. La CPU programa paquetes uno por uno, en lugar de muchos a la vez. Este proceso incrementa el uso de la CPU. El tamaño de la cola de transmisión depende del hardware, software, medios de capa 2 y algoritmo de cola configurado en la interfaz. Algunas plataformas y mecanismos QoS ajustan el tamaño de la cola de transmisión a un valor apropiado. Las interfaces rápidas tienen colas de hardware más pequeñas y producen menos retardo. Las interfaces más lentas tienen colas de hardware más pequeñas para prevenir

demasiado retardo en el peor caso en el cual la cola de hardware esté llena. El comando #show controllers serial se usa para ver el tamaño de la cola de transmisión. En la figura se muestra la salida de este comando. En el ejemplo, el tamaño de la cola de hardware definida por la sentencia tx_limited es igual a 2 paquetes.

CONGESTIÓN EN INTERFACES SOFTWARE Las subinterfaces y las interfaces de software no tienen sus propias colas de transmisión separadas, sino que usan la cola de transmisión principal. Estas interfaces incluyen dialers, túneles y subinterfaces Frame Relay, y sólo se ven congestionadas cuando la interfaz de hardware principal transmisora está congestionada.

4.4 Configuración WFQ

4.4.1 Weighted Fair Queuing Para situaciones en las cuales se desea proveer un tiempo de respuesta consistente a usuarios con mucha carga y con poca sin necesidad de añadir un ancho de banda excesivo, la solución es WFQ. WFQ es una de las técnicas de colas preferidas por Cisco. Usa un algoritmo basado en flujos que realiza 2 tareas en simultáneo:

- Programa el tráfico interactivo al frente de la cola para reducir el tiempo de respuesta.

CCNP ONT

60- Moldea con justicia el ancho de banda para todos los flujos previniendo que los flujos de alto

volumen monopolicen la interfaz de salida. La base de WFQ es tener una cola dedicada para cada flujo sin retrasos o jitters dentro de la cola. WFQ hace uso de los bits de la procedencia IP como peso cuando localiza ancho de banda. Los streams de tráfico de bajo volumen, los cuales componen la mayor parte del tráfico, reciben un servicio preferente. Los streams de alto volumen comparten la capacidad restante de forma proporcional entre ellos.

4.4.2 Arquitectura WFQ y beneficios WFQ es un algoritmo basado en flujos que programa de forma simultánea tráficos interactivos al frente de una cola de hardware para reducir el tiempo de respuesta y modelar de forma justa el ancho de banda restante con los flujos de alto ancho de banda.

Como vemos en la figura, WFQ permite dar al tráfico de bajo volumen, como sesiones Telnet, prioridad sobre otros tráficos de alto volumen, como sesiones FTP. WFQ provee la solución para situaciones en las cuales se desea proveer tiempos de respuesta consistentes tanto a usuarios pesados como ligeros, sin necesidad de añadir un ancho de banda excesivo. Además, WFQ puede gestionar flujos de datos dúplex, como aquellos producidos entre un par de aplicaciones, y flujos de datos simples, como la voz o el vídeo. Aunque WFQ se adapta de forma automática a las condiciones del tráfico de red cambiante, no ofrece el grado de precisión de control sobre la localización de ancho de banda que CQ (Custom Queuing) y que CBWFQ. La limitación más significativa de WFQ es que no soporta túneles ni cifrados, ya que estas prestaciones modifican la información contenida en el paquete, requerida para la clasificación de WFQ.

4.4.3 Clasificación WFQ La clasificación WFQ tiene que identificar flujos individuales. La figura muestra como se identifica un flujo

basándose en la información obtenida desde las cabeceras IP y TCP/UDP: Dirección IP origen // Dirección IP destino // Número de protocolo (TCP o UDP) // Campo ToS // Número de puerto TCP o UDP origen // Número de puerto TCP o UDP de destino.

Estos parámetros son normalmente fijos en un flujo de tráfico, aunque existen excepciones. Por ejemplo, un diseño QoS puede marcar paquetes con distintos valores de procedencia IP aún perteneciendo al mismo flujo. Se debe evitar el uso de marcas cuando se usa WFQ. Los parámetros son usados como entrada de un algoritmo de hash que produce en número de tamaño fijo usado como el índice de la cola. WFQ usa un número fijo de colas. La función de hash se usa para asignar una cola a un flujo. Hay 8 colas adicionales para paquetes del sistema y, opcionalmente, hasta 1000 colas para flujos RSVP. El número de colas dinámicas que usa WFQ por defecto se basa en el ancho de banda de la interfaz. Con el ancho de banda por defecto en la interfaz, WFQ usa 256 colas dinámicas. El número de colas puede configurarse en un rango entre 16 y 4096. Si hay un gran número de flujos concurrentes, es probable que 2 flujos acaben en la misma cola. Tendremos muchas veces tantas colas como flujos (de media). Este diseño no es posible en entornos grandes donde el número de flujos concurrentes es de miles.

CCNP ONT

61

4.4.4 Inserción WFQ y política de borrado WFQ usa los siguientes 2 parámetros que afectan al borrado de paquetes:

- El CDT (Umbral de congestión de descarte) se usa para comenzar a borrar paquetes de los flujos más agresivos, siempre antes que se alcance el límite “hold-queue”.

- El límite hold-queue define el número máximo de paquetes que pueden ser almacenados en el sistema WFQ en cualquier momento.

Existen 2 excepciones a la inserción WFQ y política de borrado: - Si el sistema WFQ está encima del límite CDT, el paquete es todavía metido la cola de flujo específica

si está vacía. - La estrategia de borrado no está influenciada directamente por la procedencia IP.

El tamaño de las colas (para propósitos de programación) se determina no por la suma del tamaño en bytes de todos los paquetes, sino por el tiempo que se tardaría en transmitir todos los paquetes en la cola. El resultado final es que WFQ se adapta al número de flujos activos (colas) y localiza cantidades iguales de ancho de banda para cada flujo (cola).

4.4.5 Ventajas y desventajas de WFQ El mecanismo WFQ provee una configuración simple (no es necesaria una clasificación manual) y garantiza capacidad a todos los flujos. Borrará paquetes de los flujos más agresivos. Sin embargo, WFQ también tiene ciertas desventajas:

- Múltiples flujos pueden acabar en una cola única. - WFQ no permite a un ingeniero de red configurar manualmente la clasificación. La clasificación y la

programación son determinadas por el algoritmo WFQ. - WFQ es soportado sólo en enlaces con un ancho de banda menor o igual a 2 Mb. - WFQ no puede proveer garantías fijas a flujos de tráfico.

4.4.6 Configuración de WFQ Los routers Cisco habilitan WFQ automáticamente en todas las interfaces que tienen un ancho de banda por defecto menor a 2,048 Mbps. El comando (config-if)#fair-queue habilita WFQ en interfaces donde no está habilitado por defecto fue previamente deshabilitado. La sintaxis completa del comando es: (config-if)#fair-queue [cdt [dynamic-queues [reservable-queues]]] . Parámetros: cdt (UMBRAL DE DESCARTE POR CONGESTIÓN) � (opcional) Número de mensajes permitidos en el sistema WFQ. Por defecto son 64 mensajes, y un nuevo umbral debe ser una potencia de 2 en el rango de 16 a 4096. Cuando una conversación alcanza este umbral, los nuevos mensajes son descartados. Dyna dynamic-queues (COLAS DINÁMICAS) � (opcional) Número de colas dinámicas usadas para conversaciones de mejor esfuerzo. Los valores posibles son 16, 32, 64, 128, 256, 512, 1024, 2048 y 4096. reservable-queues (COLAS RESERVADAS) � (opcional) Número de colas reservadas usadas para conversaciones reservadas en el rango de 0 a 1000. Por defecto es de 0. Estas colas se usan para interfaces configuradas con prestaciones del tipo RSVP. CONFIGURACIÓN DEL LÍMITE WFQ MÁXIMO El sistema WFQ generalmente nunca alcanzará el límite “hold-queue” ya que el límite CDT comienza a borrar paquetes de flujos agresivos en la cola de software. Bajo circunstancias especiales, puede ser posible alcanzar al sistema WFQ. Por ejemplo, un ataque DoS que inunda la interfaz con un gran número de paquetes (cada uno diferente) podría llenar todas las colas en la misma cantidad. El comando para dar un límite al hold-queue es: (config-if)#hold-queue max-limit out . Especifica el número máximo de paquetes que pueden estar en todas las colas de salida en la interfaz al mismo tiempo. El valor por defecto es 1. Bajo circunstancias especiales, WFQ puede consumir muchos búfers, lo cual puede requerir disminuir este límite.

4.4.7 Monitoreo de WFQ El comando #show interface puede utilizarse para determinar la estrategia de colas. La salida muestra estadísticas sumarizadas. En el comando de la siguiente figura se muestra que actualmente no hay paquetes en el sistema WFQ. El sistema permite hasta 1000 paquetes (límite hold-queue) con un CDT de 64. WFQ está usando 256 colas. El número máximo de flujos concurrentes (conversaciones, o colas activas es de 4). El comando show queue de la figura de la página siguiente se usa para mostrar los contenidos de los paquetes dentro de una cola de una interfaz en particular, incluyendo estadísticas de flujos (conversaciones). El queue depth es el número de paquetes en la cola. El peso es 4096 / Procedencia IP + 1, o 32824, dependiendo de la versión IOS. En la salida del comando, los discards se usan para representar el

CCNP ONT

62número de borrados debidos al límite CDT. Los tail drops representan el número de borrados debidos al límite hold-queue.

4.5 Configurando CBWFQ y LLQ

4.5.1 Combinación de métodos de colas Ni los métodos básicos de colas ni los más avanzados (WFQ) resuelven por completo los problemas de calidad de servicio del tráfico de red convergente. Los siguientes problemas permanecen:

- Si sólo se usa una cola de prioridad para una red habilitada para voz, la voz obtiene la prioridad deseada. Sin embargo, el tráfico de datos sufriría.

- Si sólo se usa CQ (Custom Queuing) en una red habilitada para voz, el tráfico de datos tendría asegurado cierto ancho de banda. Sin embargo, el tráfico de voz sufriría retardos.

- Si se usa WFQ, la voz todavía experimentaría retardos siempre que se le trate como “fairly” (equitativamente) por WFQ.

- En PQ y CQ, todas las clasificaciones, marcado y mecanismos de colas son complicados de usar y consumen mucho tiempo cuando se aplican en una base por interfaz.

Los nuevos mecanismos de colas combinan los mejores aspectos de los métodos de colas existentes. LLQ (Cola de baja latencia) es una combinación de WFQ basada en clases (CBWFQ), la cual asigna “pesos” de acuerdo al ancho de banda, y un sistema de prioridades basada en clases que da a la voz la prioridad que requiere mientras se asegura que los datos se sirven de forma eficiente.

4.5.2 CBWFQ (Class-Based Weighted Fair Queuing) CBWFQ extiende la funcionalidad estándar de WFQ para dar soporte a clases de tráficos de usuario definidos. Con CBWFQ, el usuario define la clase de tráfico basado en criterios de coincidencia (match), incluyendo protocolos, ACL e interfaces de entrada. Los paquetes que cumplen con el criterio de una clase constituyen el tráfico de esa clase. Una cola se reserva para cada clase, y el tráfico que pertenece a la misma es dirigido a la cola de esa clase. Tras definir una clase y formular los criterios de coincidencia para la misma, podemos asignar características a la clase. Para caracterizar una clase, asignamos un ancho de banda a la misma y un número límite máximo de paquetes. El ancho de banda asignado a la clase es el ancho de banda mínimo entregado a la misma durante una etapa de congestión. Para caracterizar a la clase, también especificamos el límite de la cola para esa clase, lo cual es el número de paquetes máximo que pueden acumularse en la cola de la clase. La cola garantiza un ancho de banda mínimo, pero también da a la clase un acceso ilimitado a más ancho de banda si el mismo está disponible. Cuando una cola alcanza el límite de cola configurado, los paquetes adicionales dirigidos a la cola de esa clase provocan un borrado. Se pueden configurar hasta 64 clases en una política de servicio.

CCNP ONT

63

4.5.3 Arquitectura CBWFQ, Clasificación y Programación CBWFQ soporta múltiples class maps para clasificar el tráfico dentro de sus colas FIFO correspondientes. Las clases CBWFQ usan “tail drop” (borrado de cola) a no ser que de forma explícita configuremos una política para una clase que use WRED (Weighted random early detection) para borrar paquetes cuando se produce congestión. Si usamos WRED en lugar de tair drop para una o más clases en un policy map, debemos asegurarnos que WRED no está configurado en la interfaz en la cual asociaremos la política. Las interfaces seriales E1 (2,04 Mbps) e inferiores usan WFQ por defecto (otras interfaces usan FIFO). Habilitar CBWFQ en una interfaz física sobreescribe el método de cola utilizado por defecto. CLASIFICACIÓN Podemos usar cualquier opción de clasificación para CBWFQ, dependiendo de la disponibilidad de la versión IOS que estemos utilizando. Los siguientes ejemplos ilustran algunas de las limitaciones relativas a las opciones de clasificación:

- Coincidencias en bits DE Frame Relay pueden ser usadas sólo en interfaces con encapsulación Frame Relay.

- Coincidencias en los bits EXP de MPLS no tienen efecto si MPLS no está habilitado. - Coincidencias en los bits de prioridad ISL no tienen efecto si ISL no está en uso.

CBWFQ se configura usando MQC (CLI QoS Modular). Las clasificaciones que pueden configurarse dependen de la versión IOS y el tipo de interfaz que se configure. MECANISMOS DE PROGRAMACIÓN El mecanismo CBWFQ calcula pesos basándose en el ancho de banda disponible. Estos pesos son usados por el mecanismo de programación CBWFQ para despachar los paquetes. Podemos configurar garantías de ancho de banda usando uno de los siguientes comandos:

- El comando bandwidth localiza una cantidad fija de ancho de banda especificando el total en Kbps. El ancho de banda reservado es restado al ancho de banda disponible de la interfaz donde se usa la política de servicio.

- El comando bandwidth percent puede usarse para localizar un porcentaje del total de ancho de banda disponible en una interfaz. El ancho de banda total se define usando el comando bandwidth interface . Se recomienda que este comando refleje la velocidad real del enlace. El ancho de banda localizado se resta del ancho de banda disponible de la interfaz donde se usa la política.

- El comando bandwidth remaining percent se usa para localizar el total de ancho de banda garantizado basado en un porcentaje relativo del ancho de banda disponible. Cuando se configura este comando, sólo se asegura un ancho de banda relativo por clase. Esto quiere decir que los anchos de banda de clase son siempre proporcionales a los porcentajes especificados en el ancho de banda de la interfaz. Cuando el ancho de banda de la interfaz es fijo, la clase garantiza una proporción de los porcentajes configurados. Si el ancho de banda es desconocido o variable, el ancho de banda de la clase en Kbps no puede computarse.

CÁLCULO DEL ANCHO DE BANDA DISPONIBLE El ancho de banda disponible mostrado por el comando show interface se calcula sustrayendo todos las reservas de ancho de banda fijas del porcentaje del 75% por defecto del ancho de banda configurado en una interfaz. El ancho de banda disponible se calcula con la siguiente fórmula: ANCHOBANDADISP =ANCHOBANDA * MAXIMORESERVABLE – SUMA(TODOS GARANTIZADOS). El aprovisionamiento correcto de ancho de banda es un componente esencial de un diseño de red satisfactorio. Podemos calcular el ancho de banda requerido añadiendo los requisitos de ancho de banda de cada aplicación mayor (ejemplo: voz, vídeo y datos). La suma resultante representa los requisitos de ancho de banda mínimos para un enlace dado, y no deben exceer el 75% del ancho de banda total disponible del enlace. El 25% restante se usa para otras cargas, incluyendo carga de capa 2 (ej: keepalives), tráfico de enrutamiento, y tráfico de mejor esfuerzo. Sin embargo, bajo circunstancias agresivas en las cuales queramos configurar más del 75% del ancho de banda de la interfaz a clases, podemos sobreescribir el máximo del 75% usando el comando max-reserved-bandwidth . VENTAJAS Y DESVENTAJAS DE CBWFQ CBWFQ permite definir clases de tráfico basadas en criterios de coincidencia personalizados como ACL, interfaz de entrada y tipo de protocolo.

- CLASIFICACIÓN: CBWFQ permite clasificaciones personalizadas basadas en muchos parámetros, como ACL, interfaz de entrada, contadores de bytes, etc.

- LOCALIZACIÓN DE ANCHO DE BANDA: CBWFQ permite especificar el ancho de banda mínimo que será localizado para una clase de tráfico específica. Teniendo en cuenta el ancho de banda disponible en la interfaz, podemos configurar hasta 64 clases y controlar la distribución entre las mismas. WFQ a secas aplica pesos al tráfico para clasificarlo dentro de conversaciones y determina cuanto ancho de banda tiene permitido cada conversación, en relación a otras conversaciones.

- GRANULARIDAD Y ESCALABILIDAD AFINADAS: CBWFQ permite definir la constitución de una clase basándose en criterios que exceden el concepto de un flujo. No necesitamos mantener clasificaciones de tráfico en una base por flujo. Más aún, podemos configurar hasta 64 clases en una única política.

La desventaja es que el tráfico de voz puede todavía sufrir retardos inaceptables si usamos CBWFQ como único mecanismo de colas.

CCNP ONT

64

4.5.4 Configuración y Monitoreo de CBWFQ El comando (config-pmap-c)#bandwidth se usa para especificar o modificar el ancho de banda localizado para una clase que pertenece al policy map. Todas las clases que pertenecen a un policy map debería usar el mismo tipo de ancho de banda garantizado, en Kbps, en porcentaje del ancho de banda de la interfaz o en porcentaje de ancho de banda disponible. bandwidth { bandwidth | percent percent | remaining percent percent}

Las siguientes restricciones se aplican al comando bandwidth: - Si la palabra clave percent se usa, la suma de los porcentajes de ancho de banda de las clases no

puede exceder el 100%. - El total de ancho de banda configurado debería ser lo suficientemente ajustado como para soportar

la carga de capa 2. - Un policy map puede tener todos los anchos de banda de clases especificados en Kbps o en

porcentajes, pero no en una mezcla de los mismos. El límite de cola por defecto de 64 paquetes puede cambiarse usando el comando (config-pmap-c)#queue-limit . No es recomendable cambiar el valor por defecto a no ser que se tenga muy claro el por qué hacerlo. La clase por defecto puede seleccionarse especificando el nombre de clase (config-pmap)#class-default. La clase por defecto soporta 2 tipos de colas: una cola FIFO (por defecto) o un sistema basado en flujos WFQ. Ambos tipos pueden combinarse con WRED. Una cola FIFO puede también tener garantizado un ancho de banda mínimo. EJEMPLO: CONFIGURACIÓN DE UNA COLA FIFO PARA LA CLASE POR DEFECTO Este ejemplo muestra la configuración de una cola FIFO para la clase por defecto. Esta clase tendrá garantizado 1 Mbps de ancho de banda, y el tamaño máximo de cola se limita a 40 paquetes. policy-map A class A bandwidth 1000 class class-default bandwidth 1000 queue-limit 40

EJEMPLO: CONFIGURACIÓN DE UNA COLA WFQ PARA LA CLASE POR DEFECTO En este ejemplo, el número de colas dinámicas se configura a 1024, y el umbral de descarte se configura a 50. policy-map A class A bandwidth 1000 class class-default fair-queue 1024 queue-limit 50

EJEMPLO: USAR CBWFQ PARA GARANTIZAR ANCHO DE BANDA Y MONITOREO

En el ejemplo se muestra como WFQ garantiza un ancho de banda a cada una de las clases. El comando show policy-map interfaz muestra todas las políticas de servicio aplicadas a la interfaz.

4.5.5 LLQ (Cola de Baja Latencia) Aunque WFQ provee una forma equitativa de compartir ancho de banda para cada flujo, no puede proveer ancho de banda garantizado y bajos retardos a aplicaciones seleccionadas.

CCNP ONT

65Con CBWFQ, el peso de un paquete que pertenece a una clase específica se deriva desde el ancho de banda que se asigna a la clase donde colocamos a ese paquete. Por ello, el ancho de banda asignado a los paquetes de una clase determina el orden en el cual los paquetes son enviados. Todos los paquetes se sirven de forma equitativa basándose en su peso interno. Ninguna clase de paquetes tiene garantizada una prioridad estricta. Este esquema plantea un problema al tráfico de voz, el cual es muy intolerante a retardos, especialmente también a la variación en los retardos. Para el tráfico de voz, las variaciones en el retardo introducen irregularidades en la transmisión del audio y jitter (pérdida de sincronización) en la conversación. LLQ reduce el jitter en conversaciones de voz. Para poner en cola al tráfico en tiempo real a una cola de prioridad estricta, configuramos el comando priority para la clase después de especificar el nombre de la clase dentro de un policy map. Dentro de un policy map, podemos dar a una o más clases el estado de prioridad. Cuando múltiples clases dentro de un único policy map se configuran como prioritarias, todo el tráfico de estas clases se coloca en la misma cola única de prioridad estricta.

4.5.6 Arquitectura LLQ y Beneficios LLQ extiende VBWFQ añadiendo colas de prioridad estricta. Estas colas permiten a los datos sensibles a demoras como la voz ser enviados primero. Los paquetes de voz que entra en el sistema LLQ se envían a la cola prioritaria del sistema LLQ, donde tienen un ancho de banda fijo y donde son servidos primero. Los paquetes de datos que entran en el sistema CBWFQ se manipulan directamente por el mismo donde se asignan específicamente pesos para determinar cómo deben ser

tratados los mismos. BENEFICIOS LLQ Usando LLQ como el criterio de entrada para una clase puede ser tan granular como queramos ya que definimos el mismo mediante una ACL. El tráfico VoIP usa un rango de puertos UDP bien conocidos (16384-32767). Mientras que los puertos actuales usados son negociados dinámicamente entre los dispositivos finales o gateways, todos los productos Cisco VoIP usan el mismo rango de puertos.

4.5.7 Configuración y Monitoreo de LLQ Cuando especificamos el comando priority para una clase, podemos usar el argumento bandwidth para especificar el ancho de banda máximo en Kbps. Usamos este parámetro para especificar el total máximo de ancho de banda localizado para los paquetes que pertenecen a la clase configurado con el comando priority . Comando: (config-pmap-c)# priority { bandwidth | percent percentage}

- BANDWIDTH: Ancho de banda garantizado, en Kbps. - PERCENT: Total de ancho de banda garantizado en relación al porcentaje de ancho de banda

disponible. Cuando se produce congestión, el tráfico destinado a la cola prioritaria es medido para asegurarse que la localización de ancho de banda configurada para la clase a la cual pertenece el tráfico no es excedida. La medición de la prioridad del tráfico tiene las siguientes cualidades:

- El tráfico prioritario se mide sólo bajo condiciones de congestión. Cuando el dispositivo no está congestionado, el tráfico de la clase prioritaria tiene permitido exceder el ancho de banda configurado. Cuando está congestionado, el tráfico superior al ancho de banda configurado es descartado.

- La medición se realiza en una base por paquete. - La medición contiene al tráfico prioritario a su ancho de banda configurado para asegurarse que el

tráfico no prioritario, como los paquetes de enrutamiento y otros datos, no son eliminados. Con la medición, las clases son limitadas individualmente. Esto es, aunque un único policy map puede contener 4 clases de prioridades, cada una de ellas colocada en una cola de prioridad única, estas son tratadas como flujos separados con localizaciones de ancho de banda separadas.

CCNP ONT

66 En la figura se muestra un ejemplo donde la clase de tráfico voip, clasificada basándose en la procedencia IP de 5, se pone en la cola LLQ prioritaria. La clase prioritaria está garantizada pero se limita al 10% del ancho de banda de la interfaz.

MONITOREO DE LLQ El comando show policy-map interface muestra estadísticas de paquetes para todas las clases configuradas para políticas de servicio en la interfaz especificada. Los “campos claves” de este comando describen algunos de los siguientes parámetros: CLASS-MAP: clase de tráfico que está siendo mostrado. OFFERED RATE: Cantidad, en Kbps, de paquetes entrando a la clase. DROP RATE: Cantidad, en Kbps, a la cual los

paquetes son borrados de la clase. Este valor se calcula eliminando el número de paquetes transmitidos satisfactoriamente desde la cantidad ofrecida. MATCH: Criterio de coincidencia especificado para la clase de tráfico. PKTS MATCHED/BYTES MATCHED: Número de paquetes (en bytes) que han coincidido con esta clase y que han sido colocados en la cola. DEPTH/TOTAL DROPS/NO-BUFFER DROPS: Número de paquetes, en bytes, descartados para esta clase. “No-buffer” indica que no existe un servicio de buffer para estos paquetes.

4.6 Prevención de Congestión

4.6.1 Gestión de la congestión en Interfaces con Tail Drop Cuando una interfaz en un router no puede transmitir paquetes inmediatamente, el paquee es puesto en cola. Los paquetes son entonces transmitidos eventualmente a través de la interfaz.

Si la cantidad de paquetes que llegan a la interfaz de salida excede la habilidad del router de poner en buffer y enviar el tráfico, la cola se incremente hasta su máximo y la interfaz se vuelve congestionada. Tail Drop trata todo el tráfico de la misma forma y no diferencia entre clases de servicio. Tail Drop ocurre por defecto. Las aplicaciones pueden sufrir una degradación en forma de

pérdida de paquetes a causa de su intervención. Cuando la cola de salida está llena y tail drop en uso, todos los paquetes que intente entrar a la cola son borrados hasta que la cola deje de estar llena. WFQ configurado en una interfaz, provee un esquema más sofisticado de eliminar tráfico. WFQ castiga a los flujos más agresivos usando un umbral de congestión de descarte (CDT) basado en un algoritmo de borrado.

CCNP ONT

67

4.6.2 Limitaciones de Tail-Drop El esquema simple tail-drop no funciona bien en entornos con un gran número de flujos TCP o en entornos en los cuales se requiere un borrado selectivo. Tail drop tiene las siguientes desventajas:

- Normalmente, cuando existe congestión, el borrado afecta a la mayoría de las sesiones TCP, las cuales simultáneamente vuelven de nuevo y se reinician. Este proceso causa un uso ineficiente del enlace en el punto de congestión. Para prevenir el borrado de paquetes TCP, TCP reduce el tamaño de la ventana.

- No existen mecanismos de borrado, y por tanto, el tráfico de mayor prioridad es borrado de la misma forma que el de mejor esfuerzo.

SINCRONIZACIÓN TCP Un router puede manipular múltiples sesiones TCP simultáneamente. Sin embargo, las oleadas de tráfico de red podrían causar que un router falle si el tráfico excede el límite de la cola. Si el router receptor borra todo el tráfico que excede el límite de la cola (por defecto, con tail drop), muchas sesiones TCP cierran por pérdida de ACK y se reinician automáticamente, sincronizándose todas a la vez. A esto se le conoce como “sincronización global”. RETARDO TCP, JITTER E INANICIÓN

Las colas se llenan durante periodos de congestión. Cuando la cola de salida está llena, tail drop borra paquetes para eliminarla. Esto causa retardos. Además, las colas introducen retardos desiguales para paquetes pertenecientes al mismo flujo, resultando en el jitter. En la figura se ilustra este hecho. Otro fenómeno relativo a TCP que reduce el uso óptimo de las aplicaciones de red es la inanición TCP.

Cuando múltiples flujos están siendo transmitidos a través de un router, algunos de estos pueden ser mucho más agresivos que otros. Por ejemplo, cuando el tamaño de ventana TCP se incrementa para aplicaciones de transferencia de ficheros, la sesión TCP puede enviar un gran número de paquetes a su destino. Estos paquetes inmediatamente llenan la cola en el router, y otros, menos agresivos, pueden ser descartados ya que no hay un tratamiento especial indicando que paquetes son los que deben borrarse. Como resultado, los flujos menos agresivos son borrados en la interfaz de salida. Tail drop no es el mecanismo óptimo de prevención de congestión y no debe utilizarse. En su lugar, existen mecanismos de prevención de congestión más inteligentes.

4.6.3 Uso de RED (Rando Early Detection) RED es un mecanismo de borrado que borra paquetes aleatoriamente antes de que la cola esté llena. La base de la estrategia de borrado es el tamaño medio de la cola (esto es, cuando el tamaño medio de la cola se incrementa). Debido a que RED borra paquetes aleatoriamente, no tiene una inteligencia por flujo. Su razón es que un flujo agresivo representa la mayoría del tráfico entrante, y es probable que RED borre un paquete de una sesión agresiva. Como resultado del uso de RED, la sincronización global de TCP es mucho menos probable, y TCP puede usar el ancho de banda del enlace de forma más eficiente. En implementaciones RED, el tamaño medio de la cola decrece significativamente ya que la posibilidad de que la cola se llene es reducida. Esto se debe a que RED es muy agresivo en el borrado cuando el tráfico en oleadas ocurre y la cola ya está bastante llena. PERFILES DE BORRADO RED RED usa perfiles de tráfico para determinar la estrategia de borrado de paquetes basada en el tamaño de cola medio. La probabilidad de borrado de paquete se basa en el umbral mínimo, umbral máximo y la marca denominadora de la probabilidad.

UMBRAL MÍNIMO: Cuando el tamaño de la cola medio esta cerca del umbral mínimo, RED comienza a eliminar paquetes. La cantidad de paquetes borrados se incrementa de forma lineal a medida que el tamaño medio de la cola crece, hasta que el tamaño medio de la cola alcanza su umbral máximo. UMBRAL MÁXIMO: Cuando el tamaño medio de la cola está cerca del umbral máximo, todos los paquetes son eliminados.

CCNP ONT

68MARCA DENOMINADORA DE PROBABILIDAD: Este número es la fracción de paquetes que son eliminados cuando la profundidad media de la cola está en el umbral máximo. Por ejemplo, si el denominador es de 512, uno de cada 512 paquetes es eliminado cuando la media de la cola llega al umbral máximo. El umbral mínimo debe ser lo suficientemente grande para maximizar el uso del enlace. Si el umbral mínimo es muy pequeño, los paquetes pueden ser eliminados de forma innecesaria, y el enlace de transmisión no será utilizado por completo. La diferencia entre los umbrales mínimo y máximo debe ser lo suficientemente grande para prevenir la sincronización global de TCP. Si la diferencia es pequeña, pueden borrarse muchos paquetes a la vez, volviendo al problema de la sincronización global. MODOS RED

- Cuando el tamaño medio de la cola está entre 0 y el umbral mínimo, no ocurren borrados y todos los paquetes son puestos en cola.

- Cuando el tamaño medio de la cola está entre el umbral mínimo y el umbral máximo, se producen borrados aleatorios, lo cual es proporcional al denominador y al tamaño medio de la cola.

- Cuando el tamaño medio de la cola está cerca o es mayor al umbral máximo, RED realiza un borrado total de la cola. Esta situación es poco probable, ya que RED debe eliminar tráficos TCP antes de la congestión.

4.6.4 WRED (Weighted Random Early Detection) Curiosamente, Cisco no soporta RED. En su lugar, Cisco soporta WRED el cual combina RED con la procedencia IP o el DSCP y realiza el borrado de paquetes basándose en la procedencia IP o las marcas DSCP. Por ejemplo, un paquete con una procedencia IP de 0 puede tener un umbral mínimo de 20 paquetes, mientras que un paquete con una procedencia IP de 1 puede tener un umbral mínimo de 25 paquetes. De esta forma, los paquetes con una procedencia IP de 0 serán descartados de forma más frecuente que los que tengan una procedencia IP de 1. Como sucede con RED, WRED monitorea el tamaño de cola medio en el router y determina cuando comenzar a descartar paquetes basándose en el tamaño de la cola de la interfaz. Cuando el tamaño de cola medio excede el umbral mínimo especificado por el usuario, WRED comienza a borrar paquetes de forma aleatoria. Si el tamaño de la cola continúa incrementándose hasta ser mayor al umbral máximo, WRED se vuelve a una estrategia tail drop, en la cual todos los paquetes son eliminados. WRED, al contrario que RED, puede descartar de forma selectiva el tráfico de menor prioridad cuando la interfaz está congestionada y puede proveer un funcionamiento diferenciado, para diferentes clases de servicio. Para interfaces configuradas con RSVP, WRED escoge paquetes desde otros flujos para borrar antes que los flujos RSVP. También, la procedencia IP o el DSCP ayuda a determinar que paquetes eliminar, ya que el tráfico de menor prioridad tiene una cantidad mayor de borrados que el tráfico de mayor prioridad. Además, WRED borra de forma estadística más paquetes de usuarios grandes que de pequeños usuarios. El origen del tráfico que genera más tráfico tiene más probabilidades de ir más lento que el de los orígenes que generan pequeño tráfico. WRED trata al tráfico no IP con un nivel de procedencia 0, es decir, la menor. Por ello tiene más probabilidades de ser borrado que el tráfico IP. WRED debe ser usado si existe un enlace que pueda estar congestionado (cuello de botella). Los routers borde asignan una procedencia IP o DSCP a paquetes que entran a la red. WRED usa estos valores asignados para determinar cómo tratar a los diferentes tipos de tráfico. Anotar que Cisco no recomienda WRED para una cola de voz, aunque podemos habilitar WRED en una interfaz que porta tráfico de voz. BUILDING BLOCKS WRED

En la figura se muestra como implementar WRED y los parámetros usados por WRED para influenciar las decisiones de borrado de paquetes. El router constantemente actualiza el algoritmo WRED con el tamaño de cola medio

calculado, el cual se basa en el historial reciente de tamaños de cola. Los perfiles de tráfico configurados son los parámetros que definen las características de borrado usadas por WRED (umbral mínimo, máximo y marca denominadora de probabilidad). Cuando un paquete llega a la cola de salida, se usa el valor de procedencia IP o DSCP para seleccionar el perfil WRED correcto para el paquete. El paquete es entonces pasado a WRED para su procesamiento. Basándose en el perfil de tráfico seleccionado y en el tamaño medio de la cola, WRED calcula la probabilidad de borrado del paquete actual y, o lo borra, o lo pasa a la cola de salida.

CCNP ONT

69Si la cola ya está llena, el paquete es eliminado. Si no, el paquete es transmitido eventualmente por la interfaz de salida. Si el tamaño medio de la cola es mayor que el umbral mínimo, pero menor que el máximo, basándonos en la probabilidad de borrado, WRED coloca el paquete en la cola o bien realiza un borrado aleatorio. WRED BASADO EN CLASES (CBWRED) Tradicionalmente, el IOS usaba RED y WRED para prevenir la congestión en una interfaz. Estos mecanismos podían realizar diferencias de borrado en base a la procedencia IP o el valor DSCP. CBWFQ soporta el uso de WRED dentro de su mecanismo de colas, declarado como CBWRED. Cada clase es puesta en cola en su cola separada y tiene su límite de cola, realizando un tail drop por defecto. WRED puede configurarse como el método de descarte preferido en una cola, implementando un descarte diferencia basada en la clase de tráfico o en los valores de procedencia IP o DSCP.

4.6.5 Perfiles de borrado WRED Con la habilidad del sistema para marcar paquetes de acuerdo a la configuración DSCP, colecciones de paquetes (cada uno con la misma configuración DSCP y enviado en una dirección particular) puede ser agrupado dentro de un BA DiffServ. Los paquetes desde múltiples orígenes o aplicaciones pueden pertenecer al mismo BA DiffServ. El selector de clase BA se usa para compatibilidad retrospectiva con los dispositivos no compatibles con DiffServ. Por ello, el rango de selector de clase de los valores DSCP se usa para compatibilidad con la procedencia IP. WRED BASADO EN DSCP (EXPEDITED FORWARDING) EF PHB (Expedited Forwarding Per Hop Behavior) es sugerido para aplicaciones que requieren una fuerte garantía de retardo y jitter. Típicamente, las aplicaciones de misión crítica requerirían este servicio y tendrían localizado un pequeño porcentaje de la capacidad total de la red. En DSCP, el EF PHB se identifica basándose en estos parámetros:

- Una cantidad de partida pequeña está asegurada para proveer un bajo retardo a aplicaciones sensibles al mismo.

- El ancho de banda está garantizado para prevenir la inanición de la aplicación si existen múltiples aplicaciones usando EF PHB.

- El ancho de banda se une a una política para prevenir la inanición de otras aplicaciones o clases que no están usando PHB.

- Los paquetes que requieren EF deberían ser marcados con el valor binario DSCP 101110 (46). Para la clase de tráfico EF DiffServ, WRED se configura a sí mismo por defecto de forma que el umbral mínimo es muy alto, incrementando la posibilidad de que no se borren paquetes que pertenezcan a esta clase. Se espera que el tráfico EF se borre muy tarde, comparado a otras clases, y el tráfico EF es por tanto priorizado en caso de congestión.

4.6.6 Configuración de CBWRED El comando (config-pmap-c)#random-detect se usa para habilitar WRED en una interfaz. Por

defecto, WRED está basado en la procedencia IP y usa 8 perfiles por defecto WRED, uno para cada valor de procedencia IP. Dentro del sistema CBWFQ, WRED se usa para realizar un borrado por colas dentro de las colas de cada clase. Por tanto, cada cola de clase tiene su propio método WRED, el cual puede ser basado en pesos (procedencia IP o en valores DSCP). Cada cola puede por ello ser configurada con una política de borrado separada para implementar diferentes políticas de borrado para cada clase de tráfico. WRED no puede ser configurado en la misma interfaz que CQ, PQ o WFQ. Sin embargo, CBWRED puede ser configurado en conjunto con CBWFQ.

CAMBIO DEL PERFIL DE TRÁFICO WRED Cuando WRED está habilitado, los valores por defecto son seleccionados para cada perfil de tráfico basándonos en el peso utilizado (procedencia IP o DSCP). Los administradores de red pueden modificar estos valores por defecto para cumplir sus metas QoS específicas. En la figura se muestra la sintaxis del comando:

- MINIMUN THRESHOLD: Cuando la profundidad media de la cola está cerca de este umbral, WRED

comienza a borrar paquetes. La cantidad de paquetes borrados se incrementa linealmente a medida que el tamaño medio de la cola crece, y hasta que el tamaño de la cola alcanza el umbral máximo, momento en el cual se borran todos los paquetes. El tamaño del contenedor es equivalente al número de paquetes que pueden ser almacenados sin una cola.

- MAXIMUM THRESHOLD: Cuando el tamaño de la cola medio está cerca de este umbral, todos los paquetes son eliminados.

CCNP ONT

70- MARK PROBABILITY DENOMINATOR: Es la fracción de paquetes borrados cuando la profundidad

media de la cola está en el umbral máximo. Por ejemplo, si el denominador es de 10, uno de cada 10 paquetes se borra cuando se alcanza el umbral máximo en la media de la cola.

EJEMPLO DE CBWFQ USANDO PROCEDENCIA IP CON WRED Este ejemplo de CBWFQ con WRED se centra en una red que provee los siguientes 3 tipos de niveles de servicio diferentes para 3 clases de tráfico:

- Clase misión crítica: Esta clase viene marcada con los valores de procedencia IP de 3 y 4 (3 es usado para un servidor de borrado alto y 4 para un servicio de borrado bajo dentro de la clase de servicio) y debería obtener el 30% del ancho de banda de la interfaz.

- Clase Oleadas (Bulk): Esta clase se marca con los valores de procedencia IP de 1 y 2 (con el mismo motivo del anterior) y debería obtener el 20% del ancho de banda de la interfaz.

- Clase de mejor esfuerzo: Esta clase debería obtener el ancho de banda restante compartido y debe ser puesta en cola de forma equitativa.

Para reforzar esta política, un router usa CBWFQ para realizar la compartición del ancho de banda y WRED dentro de las clases de servicio para realizar un borrado diferenciado.

4.6.7 Perfiles WRED: WRED basado en DSCP (AF) En DSCP, los siguientes parámetros identifican AF PHB:

- Garantizar una cierta cantidad de ancho de banda a una clase AF. - Permitir acceso a un ancho de banda extra, si está disponible.

Los paquetes que requieran AF PHB serían marcados con el valor DSCP aaadd0, donde aaa es el número de la clase y dd la probabilidad de borrado (o preferencia de borrado) de la clase de tráfico. Existen 3 clases definidas AF. Cada clase debe tratarse de forma independiente y tener localizado un ancho de banda que está basado en la política QoS. Para la clase de tráfico AF DiffServ, WRED se configura a sí mismo por defecto con 3 perfiles diferentes, dependiendo de los bits DSCP de preferencia de borrado. Por tanto, el tráfico AF debería clasificarse dentro de 3 posibles clases, como AF de alto borrado, AF de borrado medio y AF de bajo borrado. Estas clases están basadas en la sensibilidad a borrado de los paquetes de la aplicación o aplicaciones representadas por la clase. Esto significaría que la clase “misión-crititcal” tendría un AF de bajo borrado, un AF de borrado medio y un AF de alto borrado. CONFIGURACIÓN DE CBWRED BASADO EN DSCP El comando random-detect dscp-based se usa para habilitar WRED basado en DSCO en una interfaz. Podemos configurar WRED como parte de la política de una clase estándar o de la clase por defecto. El comando random-detect y el comando queue-limit son exclusivos mutuamente para la política de la clase. Si configuramos WRED, la capacidad de borrado de paquete se usa para gestionar la cola cuando los paquetes exceden el contador máximo configurado. EJEMPLO DE CBWRED CON DSCP Recordar que el modelo DiffServ provee por sí mismo clases de tráfico definidas y sus PHB asociadas. La clasificación DiffServ se usa en este ejemplo de la siguiente forma:

- CLASE MISIÓN CRÍTICA: Esta clase se marca usando DSCP AF clase 2 y debería obtener el 30% del ancho de banda de la interfaz.

- CLASE OLEADAS: Esta clase se marca usando DSCP AF clase 1 y debería obtener el 20%del ancho de banda de la interfaz.

- CLASE MEJOR ESFUERZO: Este tráfico debería obtener el ancho de banda restante compartido y debería entregarse de forma equitativa.

Para reforzar esta política de servicio, un router usa CBWFQ para gestionar la compartición del ancho de banda y usa WRED dentro de las clases para realizar un borrado selectivo. En la figura vemos la configuración. El ejemplo de configuración muestra como se realiza la clasificación del tráfico usando las clases DSCP, representando el tráfico de misión crítica con la clase AF2, y el tráfico oleadas con la clase AF1. Los 3 valores de cada clase representan la distinción realizada por WRED a la hora de eliminar tráfico, siendo el primero el umbral mínimo, el segundo el máximo y el tercero la marca de probabilidad. Cuando habilitamos WRED con el comando random-detect, los parámetros se configuran a sus valores por defecto. El factor de peso es 9. Para todas las precedencias, el marcado de probabilidad es 10, y el umbral máximo está basado en la capacidad del búfer de salida y la velocidad de transmisión de la interfaz.

CCNP ONT

71

4.6.8 Monitoreo de CBWRED El comando show policy-map interface muestra la configuración de todas las clases para las políticas de servicio en la interfaz especificada.

Algunos de los campos clave son los siguientes: service-policy output : Nombre de la política de servicio aplicada a la interfaz especificada o el VC. class-map : clase de tráfico que está siendo mostrado para cada clase configurada en la política. match : criterio de coincidencia especificado para la clase. exponential weigth : Exponente utsado en el

cálculo del tamaño medio de la cola para un grupo de WRED. mean queue depth : Profundidad media de la cola basada en la profundidad actual de la cola de la interfaz y la constante del peso exponencial. Los umbrales mínimo y máximo se comparan sobre este valor para determinar las decisiones de borrado.

4.7 Introducción a las Políticas de Tráfico y Modelado (Shaping)

4.7.1 Vistazo a las Políticas de Tráfico y Modelado (Shaping) La política de tráfico borra el tráfico excesivo para controlar que el tráfico fluya dentro de la cantidad límite especificada. Esta política puede causar más retransmisiones TCP, ya que el tráfico excesivo es eliminado. Los mecanismos de política de tráficos como políticas basadas en clases o Asignación de Cantidad de Acceso (CAR) también tienen capacidades de marcado además de las capacidades de limitar cantidades. En lugar de borrar el tráfico excedente, la política puede marcarlo y enviarlo. Esta prestación permite que el tráfico excedente sea re-marcado con una prioridad menor antes de ser enviado. Con el modelado del tráfico, el tráfico en ráfagas es alisado colocando en colas el tráfico excedente para producir un flujo fijo de datos. ¿POR QUÉ USAR POLÍTICAS? Las políticas de tráfico se usan normalmente para satisfacer uno de los siguientes requisitos:

- Limitar la cantidad de acceso a una interfaz cuando la infraestructura física de alta velocidad se usa en el transporte. Es normalmente utilizado por SPs para ofrecer a los clientes un acceso por debajo de lo normal. Por ejemplo, un cliente puede tener una conexión OC-3 al SP pero pagar sólo una cantidad de acceso T1.

- Modelar el ancho de banda para que la cantidad de tráfico de ciertas aplicaciones o clases de tráfico siga una política de cantidad de tráfico especificada. Por ejemplo, el tráfico desde aplicaciones de compartición de ficheros puede limitarse a un máximo de 64 Kbps.

- Re-marcar el tráfico excedente con una prioridad menor en la capa 2 o 3 (o ambas) antes de enviarlo hacia fuera. Por ejemplo, el tráfico en exceso puede ser re-marcado a un DSCP inferior y además tener el bit DE en Frame Relay marcado cuando se envía hacia fuera.

¿POR QUÉ USAR MODELADOS (SHAPING)? El modelado se usa normalmente para prevenir y gestionar la congestión en redes ATM, Frame Relay o Metro Ethernet, donde los anchos de banda asimétricos se usan a lo largo de la ruta del tráfico. Si no se utiliza este método, los paquetes podrían colocarse en un búfer final más lento, el cual podría crear colas y causar retardos, y sobrecargas, las cuales causarían el borrado de paquetes.

CCNP ONT

72El “shaping” es un intento de controlar el tráfico en redes ATM, Frame Relay o Metro Ethernet para optimizar o garantizar el funcionamiento, baja latencia y ancho de banda. Provee un mecanismo de control del volumen de tráfico enviado dentro de una red (estrangulación del ancho de banda, o bandwidth throttling) impidiendo al tráfico en oleadas superar la cantidad suscrita. También es necesario identificar el tráfico con una granularidad que permita al mecanismo de control de modelado separar el tráfico en flujos individuales y diferenciar los mismos

4.7.2 ¿Por qué usar condicionantes de tráfico? Los “traffic conditioners”, mecanismos QoS que limitan el ancho de banda, incluyen las políticas y el modelado. Ambos de estos enfoques limitan ancho de banda, pero cada uno con diferentes características:

- POLICING: Típicamente limita el ancho de banda descartando el tráfico que excede una cantidad especificada. También puede remarcar el tráfico de este tipo. Debe usarse en interfaces de alta velocidad. Se puede aplicar en las interfaces como de entrada o de salida.

- SHAPING: Limita el tráfico excesivo, pero en lugar de borrarlo lo guarda en un búfer. Este búfer o exceso de tráfico puede acarrear retardos. Debido a este retardo, el shaping se recomienda en interfaces de baja velocidad. Shaping no puede re-marcar tráfico. Como contraste final, puede aplicarse sólo en dirección saliente en una interfaz.

El traffic policing divide los recursos compartidos (el enlace de subida WAN) entre varios flujos. En el ejemplo de la figura, la interfaz Fast Ethernet del router tiene una política de entrada aplicada a la misma en la cual el tráfico de misión critica no está limitado, pero la aplicación de compartición de ficheros tiene una limitación de 56 Kbps. Todo el tráfico de la aplicación de compartición de ficheros desde el usuario x que excede la cantidad límite de 56 Kbps será eliminado, tal como observamos en la figura.

EJEMPLO DE TRAFFIC POLICING Y SHAPING Las herramientas de policing se configuran a menudo en interfaces del borde de la red para limitar la cantidad de tráfico que entra o deja la red. En su configuración más común, el tráfico que conforma se transmite y el tráfico que excede se envía con una prioridad rebajada o se borra. Estas prioridades pueden basarse en la procedencia IP o en DSCP. El administrador de red puede cambiar estas opciones para cumplir con sus necesidades. Las herramientas de shaping limitan la tasa de transmisión desde un origen poniendo en una cola el tráfico excedente. Este límite normalmente tiene un valor menor a la velocidad de la línea de la interfaz transmisora.

En la figura se muestran los 2 tipos de desacoples de velocidad: · El sitio central puede tener un enlace de velocidad mayor que el sitio remoto. Por tanto, el shaping del tráfico puede ser desplegado en el router del sitio central para modelar la cantidad de tráfico que sale de la central para hacer coincidir la velocidad del enlace del sitio central con la del sitio remoto. Por ejemplo, el router central puede modelar el PVC de tráfico saliente a 128 Kbps para coincidir con la velocidad del enlace remoto. En el router del sitio remoto, el shaping también se implementa para modelar el tráfico saliente a 128 Kbps para coincidir con la CIR contratada.

· Los enlaces agregados de todos los sitios remotos puede ser superior que la velocidad del enlace del sitio central (oversubscription). En este caso, los routers del sitio remoto pueden configurarse para modelar tráfico para prevenir la “oversubscription” del sitio central. Por ejemplo, podría hacerse un shaping en los 3 sitios inferiores para configurar el PVC con la central a 256 Kbps para prevenir en cierta medida esta situación.

· En todos los enlaces entre el sitio central y los remotos, se pueden usar políticas de tráfico para priorizar los paquetes y decidir, por ejemplo, qué paquetes que sean conformes pueden ser transmitidos, qué

CCNP ONT

73paquetes excedentes pueden ser configurados para enviarse con una prioridad disminuida y cuáles que violan la configuración han de eliminarse directamente. Por ejemplo, los paquetes con una procedencia IP de 4 que no excedan 128 Kbps pueden ser transmitidos.

4.7.3 Policing vs. Shaping Policing puede aplicarse en dirección saliente o entrante, mientras que shaping sólo puede aplicarse de forma saliente. Policing borra el tráfico no conforme en lugar de colocarle en una cola, como hace shaping. Policing también soporta el marcado de tráfico. Policing es más eficiente en términos de uso de memoria que shaping debido a que no usa colas adicionales de paquetes. Ambos, policing y shaping se aseguran que el tráfico no exceda un ancho de banda límite, pero cada mecanismo tiene distintos impactos en el tráfico:

- Policing borra paquetes más a menudo, generalmente causando más retransmisiones de TCP. - Shaping añade un retardo variable al tráfico, causando posiblemente jitter. Shaping pone en cola el

tráfico en exceso manteniendo a los paquetes en una cola shaping. Por tanto, shaping incrementa el uso del buffer en un router y causa retardos de paquetes impredecibles. Shaping también puede interactuar con una red Frame Relay, adaptando indicaciones de congestión de capa 2 en la WAN. Por ejemplo, si se recibe un BECN, el router puede disminuir el límite de cantidad para ayudar a reducir la congestión en la red Frame Relay.

4.7.4 Medida de cantidad de tráfico con Tokens El cubo de tokens es un modelo matemático usado por los routers y switches para regular el flujo de tráfico. Este modelo tiene 2 componentes básicos:

- TOKENS: Cada token representa permisos para enviar un número fijo de bits en la red. Los tokens son puestos en un cubo de tokens a una cantidad determinada por el IOS.

- CUBO DE TOKENS: Tiene la capacidad de mantener un número especifico de tokens. Cada paquete entrante, si es enviado, toma tokens desde el cubo representando el tamaño del paquete. Si el cubo llena su capacidad, los nuevos tokens que lleguen son descartados. Los tokens descartados no están disponibles para paquetes futuros. Si no hay suficientes tokens en el cubo para enviar el paquete, los mecanismos de condicionamiento de tráfico pueden tomar las siguientes acciones:

o Esperar que existan suficientes tokens acumulados en el cubo (shaping). o Descartar el paquete (policing).

Usando un modelo simple de cubo de tokens, la cantidad de tráfico medido puede ser conforme o exceder la cantidad de tráfico especificada. La cantidad de tráfico medido es conforme si hay suficientes tokens en el cubo de tokens para transmitir el tráfico. La cantidad de tráfico es excedente si no hay suficientes

tokens en el cubo para transmitir el paquete. En la figura se muestra una implementación de policing con cubo de tokens. Comenzando con una capacidad de 700 bytes de tokens validos acumulados en el cubo de tokens, cuando un paquete de 500 bytes llega a la interfaz, su tamaño se compara con el del cubo de bytes. Los 500 bytes del paquete están dentro del límite, por lo que son conformes, y el paquete es transmitido. 500

bytes de tokens son eliminados del cubo, dejando 200 válidos para el siguiente paquete. Continuando con este ejemplo, cuando el siguiente paquete de 300 bytes inmediatamente después del primer paquete, no han sido todavía tokens añadidos al cubo (lo cual se realiza periódicamente). Este paquete excede el límite de 200 bytes que queda, con lo que se toma una acción de exceso. En la política de tráfico, la acción de exceso puede ser borrar o marcar el paquete. EJEMPLO: CUBO DE TOKENS COMO HUCHA DE CERDITO Pensemos en un cubo de tokens como una hucha de cerdito. Cada día insertamos un dólar dentro de la hucha (el cubo de tokens). En un momento dado, podemos gastar sólo lo que hemos guardado en ella. Si la cantidad de guardado es de un dólar al día, nuestra cantidad de gasto a largo plazo será de 1 dólar al día si constantemente gastamos lo que guardamos. Sin embargo, si no gastamos nada en días, podremos guardar dólares hasta el máximo que pueda almacenar el cerdito. Por ejemplo, si el cerdito está limitado a almacenar 5 dólares, y pasan 5 días sin que gastemos nada, el cerdito tendrá 5 dólares. En este momento, no podemos colocar más dinero en el mismo, puesto que ya está lleno. Este ejemplo del cerdito es una metáfora que representa muy bien el concepto del cubo de tokens, pero recordar que el cubo de tokens funciona a una velocidad infinitamente mayor.

4.7.5 Política basada en clases de cubo de tokens simple La operación del cubo de tokens recae en parámetros como el CIR, ráfaga suscrita (Bc) e intervalo de tiempo suscrito (Tc). Bc es conocido como el tamaño de ráfaga normal. La relación matemática entre CIR, Bc y Tc es la siguiente: CIR (BPS) = BC (BITS) / TC (SEGUNDOS). Con la política de tráfico, se añaden nuevos tokens al cubo basándose en la llegada entrante de paquetes y el CIR. Cada vez que un paquete es “policed” (que viene a ser despachado), se añaden nuevos tokens

CCNP ONT

74de vuelta al cubo de tokens. El número de tokens añadidos de vuelta al cubo se calcula con la siguiente fórmula: Nº TOKENS = (TIEMPO DE LLEGADA DE PQT ACTUAL – TIEMPO DE LLEGADA DE PQT ANTERIOR) * CIR. Una cantidad (Bc) de tokens es enviada sin limitación en cada intervalo de tiempo (Tc). Por ejemplo, si 8000 bits (Bc) válidos de tokens se colocan en el cubo cada 250 ms (Tc), el router puede transmitir sin cesar 8000 bits cada 250 ms si el tráfico llega con esta frecuencia al router. La fórmula sería: CIR = 80000 / 0.25 = 32 Kbps. Cuando se configura la política de tráfico basada en clases en el IOS se recomienda que permitamos al IOS calcular automáticamente los valores de Bc y Tc automáticamente basándose en el CIR configurado.

4.7.6 Mecanismos Cisco IOS de Policing y Shaping El policing basado en clases soporta un cubo de tokens simple o dual. La política también soporta

multiacción. Esto es, por ejemplo, marcar el bit DE Frame Relay y el valor DSCP antes de enviar el tráfico excedente.

Los 2 mecanismos de shaping soportados por el IOS se muestran en la figura: basado en clases y Frame Relay traffic shaping (FRTS).

Class-Based usa MQC para permitir al tráfico ser modelado por clase de tráfico definida en el class-map. Puede usarse en conjunto con CBWFQ, en el cual el SHAPED RATE se usa para definir un límite superior mientras que la sentencia BANDWIDTH dentro de la

configuración CBWFQ se usa para definir un límite mínimo.7 FRST se usa sólo para el tráfico Frame Relay. Permite a un PVC individual ser modelado. Puede usar PQ, CQ o WFQ como cola de shaping y soporta sólo FIFO como método de cola. Los mecanismos de shaping pueden interactuar con una red Frame Relay para adaptarse a las indicaciones de congestión de capa 2 en la WAN. Por ejemplo, si se recibe un indicador BECN, el router puede bajar la cantidad límite para ayudar a reducir la congestión en la red Frame Relay.

4.7.7 Aplicar políticas de tráfico En la figura se muestra como una política de tráfico puede es a menudo implementada en una red empresarial. Típicamente, la capa de acceso o de distribución emplea políticas de tráfico para limitar a ciertas clases de tráfico antes de que el tráfico salga del campus a la WAN. El shaping es a menudo implementado en el borde de la WAN donde hay distintas velocidades u

oversubscription. En una red de TSP típica, la política de tráfico se implementa a menudo de entrada en el router PE para limitar la cantidad de tráfico entrante desde el router CE, para asegurarse que el cliente no excede la cantidad contratada.

4.8 Comprensión de los Mecanismos de eficiencia de los enlaces WAN

4.8.1 Mecanismos de eficiencia de enlaces Aunque hay muchos mecanismos QoS diferentes para optimizar el ancho de banda y reducir el retardo en el tráfico de red, los mecanismos QoS no crean ancho de banda. En su lugar, optimizan los recursos existentes y habilitan la distinción de tráfico de acuerdo a una política. Los enlaces WAN pueden usar mecanismos QoS para optimizar la eficiencia del ancho de banda de los enlaces como la compresión del payload, compresión de la cabecera, y la fragmentación del enlace.

CCNP ONT

75- COMPRESIÓN DEL PAYLOAD: La compresión del payload si que crea ancho de banda adicional, ya que

comprime el payload del paquete, y por tanto incrementa la cantidad de datos que pueden ser enviados a través de un recurso de transmisión en un periodo de tiempo dado. Esta compresión se realiza mayormente en tramas de capa 2, que como resultado, comprimen el paquete entero de capa 3.

- COMPRESIÓN DE LA CABECERA: La base de la compresión de cabecera, como otros métodos de compresión, es la eliminación de redundancias. Esto se aplica especialmente a otras cabeceras de protocolos. La información de cabecera de los paquetes del mismo flujo no cambia mucho durante el tiempo que dura dicho flujo. La compresión de cabecera lee la información de cabecera sólo al principio del flujo y posteriormente almacena esta información en un diccionario para una referencia posterior a través de un índice corto del diccionario.

- LFI: LFI es una técnica de capa 2 en la cual las tramas grandes se rompen en pequeños fragmentos, del mismo tamaño y se transmiten sobre el enlace de una forma intercalada. Usando LFI, las tramas pequeñas son priorizadas, y una mezcla de fragmentos se envía sobre el enlace. LFI reduce el retardo de cola, ya que las tramas pequeñas se envían casi inmediatamente. Los 3 mecanismos de LFI primarios usados por cisco son:

o MLP (MULTILINK PPP): Usado en enlaces PPP. o FRF.12: Usado en enlaces de VoIP sobre Frame Relay (VoIPovFR). o FRF.11 ANEXO C: Usando en enlaces de Voz sobre Frame Relay (VoFR).

4.8.2 Vistazo a la compresión La compresión de datos trabaja identificando patrones en los streams de datos. La compresión escoge un método más eficiente para representar la misma información. Esencialmente, un algoritmo de compresión elimina toda la redundancia que sea posible. El radio de compresión mide la eficiencia y efectividad del esquema de compresión. Una compresión de radio 2:1 (relativamente común) significa que los datos son comprimidos a la mitad del tamaño original. Existen varios algoritmos de compresión. Algunos algoritmos toman ventaja de un medio específico y la redundancia encontrado en el mismo. Sin embargo, cuando se cambia de medio el trabajo que realizan es pobre. Por ejemplo, MPEG se beneficia de la diferencia relativamente pequeña entre una trama de vídeo y otra. Realiza una compresión excelente en imágenes en movimiento, pero no comprime bien un texto. Para un texto, resulta mejor un algoritmo Huffman. La compresión por hardware y software se refiere al lugar donde se aplica el algoritmo de compresión. En la compresión por software, la compresión se implementa en la CPU principal como un proceso de software. En la de hardware, los cálculos de compresión se pasan a un módulo de hardware secundario. Esto libera a la CPU de realizar tareas intensivas de cálculos de compresión.

La compresión del payload “estruja” payloads, ya sean de capa 2 o de capa 3. Con la compresión de capa 2, la cabecera de capa 2 permanece intacta, y su payload (Capa 3 y superiores) son comprimidos. Con el de capa 3, las cabeceras de capa 2 y capa 3 permanecen intactas, y se comprimen las capas superiores. Con la

compresión del payload se incrementa el ancho de banda y se disminuye la latencia en la transmisión, ya que los paquetes al ser más pequeños se toman menos tiempo en transmitirse. La compresión de capa 2 se realiza en una base enlace por enlace, mientras que la de capa 3 se realiza en una base sesión por sesión. Los métodos de compresión trabajan evitando repetir información en cabeceras de paquete a lo largo de una sesión. Los 2 pares de una conexión PPP de capa 2 (un enlace de marcado) están de acuerdo en los índices de una sesión que se guardan en un diccionario de cabeceras de paquete. El diccionario se construye en el inicio de cada sesión y se usa para todos los demás paquetes subsecuentes. Sólo los parámetros que cambian, o inconstantes, de las cabeceras son enviados junto con el índice de sesión. La compresión de cabecera no puede ser realizada a lo largo de múltiples routers ya que estos necesitan información completa de capa 3 para ser capaces de enrutar el paquete al salto siguiente. La compresión incrementa la cantidad de datos enviados a través de un recurso de transmisión. La mayoría de los esquemas de compresión de payload trabajan en tramas de capa 2. Como resultado se comprime el paquete de capa 3 entero. Los métodos de compresión de payload de capa 2 incluyen los siguientes: STACKER // PREDICTOR // MPPC (MICROSOFT POINT-TO-POINT COMPRESSION). Estos algoritmos difieren principalmente en la eficiencia de compresión y en el uso de recursos de router. La compresión elimina redundancias. La cabecera de protocolo es un elemento de datos repetidos. La información de protocolo de la cabecera en cada paquete del mismo flujo no cambia mucho sobre el tiempo que dura dicho flujo. Usando mecanismos de compresión, la mayoría de la información de cabecera puede enviarse sólo al inicio de la sesión, guardarse en un diccionario, y referenciar los paquetes

CCNP ONT

76subsecuentes mediante un pequeño índice en el diccionario. Los métodos de compresión de cabecera incluyen: TCP // RTP // TCP BASADO EN CLASES // RTP BASADO EN CLASES.

4.8.3 Compresión del payload de Capa 2 En la figura se muestra el concepto de compresión del payload de capa 2. Cuando un router envía un paquete, el paquete está sometido al método de compresión de capa 2 después de que ha sido encapsulado a la salida. El método de compresión “estruja”

el payload de la trama de capa 2 (el paquete completo de capa 3) y transmite el mismo a la interfaz. La compresión del payload de capa 2 es una tarea de uso intensivo de la CPU y puede añadir un retardo de compresión por paquete debido a la aplicación de la compresión en cada trama. El retardo de serialización, sin embargo, más reducido, ya que la trama resultante es menor. Este retardo se refiere al retardo fijo que se requiere para colocar la trama en la interfaz de red. Los routers Cisco soportan compresión asistida por hardware para reducir la carga a la CPY y el retardo de compresión del payload de capa 2. La compresión del payload envuelve la compresión del payload del protocolo WAN de capa 2, como PPP, Frame Relay, HDLC, X.25 o LAPB. La capa 2 permanece intacta durante la compresión. Sin embargo, los contenidos completos del payload son comprimidos, usando Stacker o Predictor. RESULTADOS DE LA COMPRESIÓN DEL PAYLOAD DE CAPA 2

Si no se usa compresión, el ancho de banda está limitado por el ancho de banda del enlace, y la media de retardo se ve influenciada por el retardo de envío o de buffer, la serialización y el retardo de propagación. Si se habilita la compresión, el retardo de compresión-descompresión incrementa la latencia total entre 2 saltos. El ancho de banda percibido es generalmente

incrementado ya que el tamaño del payload de capa 2 se reduce, permitiendo más tramas de capa 2 ser enviadas a través de un recurso de transmisión en un período dado. Si se usa una compresión por hardware del payload de capa 2, los retardos de compresión o descompresión pueden llegar a ser insignificantes comparados a los de envío y serialización, y la latencia general decrece.

4.8.4 Compresión de cabecera La compresión de cabecera incrementa la capacidad de ancho de banda y reduce el retardo comprimiendo las cabeceras de protocolo. Esta compresión es más útil para aplicaciones que general pequeños payloads ya que las cabeceras de protocolo de estas aplicaciones usan un porcentaje significativo de ancho de banda en un enlace en relación al payload. La compresión de cabecera se basa en técnicas de diccionario de sesión que trabajan reemplazando frases en la cadena de entrada con índices de una tabla de diccionario. Cuando la compresión se aplica en una cabecera TCP/IP, algunos de los campos redundantes de la conexión son eliminados. La compresión de cabecera mantiene una copia de la cabecera original en cada final del enlace, elimina completamente los campos redundantes, y diferencia códigos de los campos restantes de forma que se permite una compresión de 40 bytes a 5 bytes de media. Este proceso usa un algoritmo muy específico diseñado sobre la estructura constante de las cabeceras TCP/IP. No toca el payload del paquete TCP en ningún momento. La compresión TCP y RCP se aplica a todos los flujos TCP y RTP. Por ejemplo, si la compresión TCP está habilitada en un enlace, no existe un mecanismo para restringir su función a aplicaciones específicas. La compresión de cabecera TCP basada en clases puede realizar se en clases de tráfico específicas, como por ejemplo la clase telnet. La compresión de cabecera TCP basada en clase permite configurar compresión de cabecera RTP o TCP/IP en una base por clase, cuando una clase se configura dentro de un policy map. Los policy maps se crean usando la MQC. El algoritmo de compresión sigue las conexiones activas de la capa de transporte en una interfaz. Cuando un paquete ha sido enviado, el algoritmo comprime las cabeceras de capa 3 y capa 4 dentro de la trama y reemplaza las cabeceras con un índice de sesión desde un diccionario de sesiones. Sólo los parámetros no

CCNP ONT

77constantes de las cabeceras se envían junto con el índice de sesión. El paquete es enviado a la cola de salida y transmitido al par remoto. Cuando el par remoto recibe el paquete, la cabecera es descomprimida usando la tabla de sesión local y pasada al proceso de envío. Por ejemplo, sin la compresión de cabecera RTP, la carga IP, UDP y RTP del paquete de voz es de aproximadamente el 67%. Con la compresión RTP, se puede reducir de un 9 a un 17%. RESULTADOS DE LA COMPRESIÓN DE CABECERA

Si la compresión no está en uso, el ancho de banda se limita al ancho de banda del enlace, y la media de retardo se ve influenciada sólo por el envío o el retardo del búfer, serialización y retardo de propagación. Con la compresión de

cabecera habilitada, comprimir las cabeceras del protocolo provoca que el paquete sea más pequeño, permitiendo a más paquetes ser enviados a través de un recurso de transmisión en un período de tiempo dado, incrementando la capacidad. Debido a que el paquete es más pequeño, el retardo de serialización también es menor, reduciendo el retardo general. La compresión de cabecera tiene un retardo de compresión bajo, y una carga sobre la CPU relativamente pequeño, por lo que siempre se recomienda en enlaces más lentos a 2 Mbps.

4.8.5 Exclusión de paquetes grandes de voz en enlaces WAN lentos Considerando el retardo entre dos saltos en una red, el retardo de cola en un router debe ser tomado en cuenta ya que puede ser comparable a, o incluso superior, al retardo de serialización y propagación en un enlace. En una red vacía, una sesión de voz interactiva experimenta un retardo bajo o ninguno, ya que las sesiones no compiten con otras aplicaciones en una cola de interfaz de salida. También, los retardos pequeños no varían lo suficiente como para producir jitter en el lado receptor. En una red congestionada, los datos interactivos y las aplicaciones de voz compiten en la cola del router. Los mecanismos de colas deben priorizar el tráfico de voz en esta cola, pero las colas de hardware siempre usan el mecanismo de envío FIFO. Después que los paquetes de diferentes aplicaciones dejan la cola de software, los paquetes se mezclarán unos con otros en la cola de hardware, aún cuando el procesamiento en la cola de software fuera explícito. Por tanto, un paquete de voz puede ser inmediatamente enviado a la cola de hardware donde 2 paquetes FTP grandes están esperando su transmisión. El paquete de voz debe esperar hasta que los FTP se transmitan, produciendo un retardo inaceptable en la ruta de voz. Debido a que los enlaces se usan de forma variable, el retardo varía con el tiempo y puede producir un jitter inaceptable en aplicaciones sensitivas al mismo como la voz.

En el ejemplo de la figura, el retardo de serialización de un paquete de 1500 bytes sobre un enlace de 512 Kbps será de 24.3 ms. Para el tráfico VoIP, el máximo recomendado en una vía, de extremo a extremo, es de 150 ms. Por tanto, teniendo un paquete de 1500 bytes por delante de uno VoIP en la cola de hardware de un enlace de 512 Kbps puede causar retardos.

4.8.6 Fragmentación de enlace e Intercalado El uso de un método de colas híbrido como LLQ puede proveer baja latencia y bajo jitter para paquetes VoIP mientras se sirven otros paquetes de datos de una forma equitativa. Pero los paquetes VoIP todavía tienen el riesgo de que exista el retardo de serialización. Un paquete grande puede estar ubicado en la cola de hardware, que usa FIFO.

Cuando el paquete VoIP se envía al frente de la cola de software, la serialización del paquete grande en el hardware puede causar que el paquete VoIP tenga que esperar demasiado tiempo antes de transmitirse.

CCNP ONT

78La solución es fragmentar los paquetes grandes de forma que no causen que un paquete VoIP tenga que esperar más del tiempo predefinido. El paquete VoIP debe también tener permitido transmitirse entre fragmentos de los paquetes grandes (intercalado – interleaving -). Cuando configuramos el tamaño de fragmento correcto a usar en un enlace, una meta típica es tener un retardo de serialización de alrededor de 10 a 15 segundos. Dependiendo de los mecanismos LFI configurados, el tamaño del fragmento puede configurarse en bytes o en milisegundos.

4.8.7 Aplicando mecanismos de Eficiencia de Enlaces Usaremos las siguientes guías para aplicar mecanismos de eficiencia de enlaces:

- Identificar enlaces lentos para ayudar a determinar donde se producen cuellos de botella en la red y decidir cómo aplicar los mecanismos de eficiencia de enlace a las interfaces adecuadas.

- Calcular la carga de capa 2 y capa 3 de cada tipo de medio que transportará el tráfico crítico para el negocio. Este proceso ayudará a escoger el tipo de compresión adecuado.

- Decidir el tipo de compresión a utilizar. - Habilitar la compresión en los enlaces WAN.

4.9 Implementar Ple-clasificación QoS

4.9.1 Redes Privadas Virtuales (VPN) Una VPN se establece entre dos sistemas o entre 2 o más redes. Puede construirse usando túneles, cifrado o ambos. Es una infraestructura WAN alternativa que reemplaza las redes privadas que usan líneas alquiladas o redes Frame Relay. Las VPN proveen 3 funciones críticas: confidencialidad, integridad y autenticación. TIPOS DE VPN Existen 2 tipos de VPN de acceso remoto:

- INICIADAS POR EL CLIENTE: Los usuarios remotos establecen un túnel seguro a través de una conexión a Internet a la empresa.

- INICIADAS POR EL NAS (NETWORK ACCESS SERVER): Los usuarios remotos marcan el número de teléfono en un ISP. El NAS establece un túnel seguro a la red privada de la empresa que soporta múltiples conexiones sesiones iniciadas por el usuario.

Las VPN sitio a sitio incluyen 2 tipos principales: - VPN INTRANET: Conecta centrales corporativas, oficinas remotas y sucursales sobre una

infraestructura pública. - VPN EXTRANET: Enlaza clientes, proveedores, partners o comunidades de interés a una intranet

corporativa sobre una infraestructura pública. PROTOCOLOS VPN

- L2TP: Actúa como un protocolo de la capa de enlace de datos para tunelear tráfico de red entre 2 pares sobre una red existente (normalmente Internet). L2TP es en efecto un protocolo de sesión de capa 5, y usa el puerto UDP registrado 1701. El paquete completo L2TP, incluyendo el payload y la cabecera L2TP, se envía dentro de un datagrama UDP.

- GRE: Este protocolo encapsula IP y cualquier otro paquete dentro de túneles IP. Con GRE, un router Cisco de cada sitio encapsula paquetes específicos en una cabecera IP, creando un enlace virtual punto a punto a routers Cisco en los otros extremo de una nube IP donde la cabecera IP adicional es eliminada. No provee cifrado y puede ser monitoreado con un analizador de protocolos.

- IPSEC: Es la mejor elección para asegurar VPN corporativas. Es un marco abierto de estándares que provee confidencialidad de datos, integridad y autenticación entre pares participantes.

4.9.2 Implementar QoS con Pre-clasificación La preclasificación QoS está diseñada para interfaces túnel. Cuando se habilita esta prestación, la prestación QoS de la interfaz saliente clasifica paquetes antes de cifrarlos, permitiendo que el tráfico que fluyo sea gestionado en entornos congestionados. Esta prestación provee una solución para marcar servicios QoS que operan en conjunto con túneles y cifrados en una interfaz. Esto permite a los SP y empresas tratar voz, vídeo y tráfico de misión crítica con una prioridad mayor a lo largo de la red del SP mientras se usan VPN para un transporte seguro.

4.9.3 Aplicaciones de Pre-clasificación QoS Cuando los paquetes se encapsulan por un túnel o protocolo de cifrado, la cabecera del paquete original deja de estar disponible para su examen. Desde la perspectiva QoS, proveer niveles diferentes de servicio es muy difícil sin la posibilidad de examinar la cabecera del paquete original. Las marcas QoS del paquete original deben estar visibles en la cabecera del paquete, sin importar el tipo de túnel en uso. TÚNELES GRE Los túneles GRE permiten que cualquier protocolo sea tuneleado en un paquete IP. Cisco ofrece soporte de encapsulación de datos usando IPsec o GRE. En cualquiera de los escenarios, el IOS copia los valores ToS de la cabecera del paquete en la cabecera del túnel. Esta prestación permite que los bits ToS sean copiados a la nueva cabecera cuando el router encapsula el paquete. En la figura de la página siguiente se muestra un ejemplo gráfico.

CCNP ONT

79

IPSEC AH IPsec no define algoritmos de seguridad específicos a usar. En su lugar, provee un marco abierto de algoritmos estándares de la industria. AH, un protocolo clave de la arquitectura IPsec, provee integridad no orientada a conexión y autenticación del origen de datos para datagramas IP, y provee protección contra replays. También provee servicios de no repudiación.

IANA ha asignado el número de protocolo IP 51 a AH. Por tanto, en la presencia de una cabecera AH, la cabecera IP usa un valor 51 en el campo protocolo. En la figura se muestra como el ToS se usa con el protocolo AH, manteniéndose los bits ToS de la cabecera original.

IPSEC ESP ESP es un protocolo clave en la arquitectura IPsec. Puede proveer cifrado y autenticación. La cabecera ESP es de al menos 8 bytes. IANA ha asignado el número de protocolo IP 50 a ESP. Con el modo túnel, los bytes ToS se copian automáticamente de la cabecera IP original a la cabecera túnel.

4.9.4 Opciones de despliegue de pre-clasificación QoS La clasificación define el proceso de coincidir uno o más campos de la cabecera de capa 2, 3 o 4 de un paquete y colocar ese paquete dentro de un grupo o clase de tráfico. Usando la clasificación de paquetes, el tráfico de red puede ser dividido en múltiples niveles de prioridad o clases de servicio. Cuando configuramos IPsec con GRE, el enfoque de clasificación más simple es coincidir la procedencia IP o los valores DSCP. Además, con la prestación de mantenimiento del byte ToS, el router automáticamente copia el valor ToS de la cabecera del paquete IP original a la nueva cabecera IP. Alternativamente, el tráfico puede necesitar ser clasificado basado en valores diferentes a la procedencia IP o DSCP. Por ejemplo, los paquetes pueden necesitar clasificarse basados en flujos IP o información de capa 3, como IP origen y destino. Para ello, usamos la prestación QoS para VPN con el comando qos pre-classif y.

Este comando permite a los routers Cisco hacer una copia de la cabecera interna IP y ejecutar la clasificación QoS antes del cifrado, basada en los campos de la cabecera IP interna. En los criterios de clasificación, no es necesario usar el comando qos pre-classify , ya que el valor ToS se copia a la cabecera externa por defecto.

En la siguiente página se muestra un ejemplo de su configuración.

CCNP ONT

80

En la interfaz serial 0/0 del router branch, hay una política de servicio que configura el ancho de banda de la interfaz a 256 Kbps y ejecuta políticas a una cantidad de 512 Kbps. Esta política se aplica a cualquier criterio que coincida con el class map branch 110. Se ha construido un túnel de tráfico en la interfaz serial 0/0 (cuyo destino es el hq de esta sucursal). Es en este tráfico donde la pre-clasificación QoS ha sido configurada. El ejemplo muestra como la pre-clasificación QoS ha sido configurada correctamente en el cripto-map llamado “vpn”. Este crytpo map ha sido

aplicado también a la interfaz serial 0/0. Si la pre-clasificación QoS se habilita sólo en el crypto map y no en la interfaz túnel, el router verá un flujo solamente, el túnel GRE (protocolo 47), en lugar de los múltiples flujos que requieren los beneficios del QoS los cuales están dentro del túnel GRE.

4.10 Despliegue QoS extremo a extremo

4.10.1 SLAs QoS (Acuerdos de Nivel de Servicio QoS) Un SLA estipula la entrega y el precio de los niveles de servicio y detalla las penalizaciones para los déficits. SLA puede cubrir un surtido de servicios de datos, como Frame Relay, líneas alquiladas, Internet, hosting web, etc… La mejor manera de entender una SLA es dividirla en 2 actividades:

- Negociar el acuerdo de tecnología. - Verificar el cumplimiento del acuerdo.

Una SLA QoS provee típicamente un seguro contractual de parámetros como retardo, jitter, pérdida de paquetes, capacidad y disponibilidad. Con el rápido crecimiento de aplicaciones multimedia en tiempo real, como la telefonía IP, video conferencia y e-learnign, las SLAs QoS se están incrementando de forma importante en las redes empresariales. RED EMPRESARIAL CON SERVICIO TRADICIONAL DE CAPA 2

En la figura se muestra un ejemplo de un SP que provee sólo servicios de capa 2 al cliente. Los routers CE de varios sitios cliente están interconectados por circuitos Frame Relay. Estos VC pueden ser malla completa, parcial o hub and spokes, dependiendo de los requisitos del cliente. En este entorno, el SP es responsable sólo de las conexiones de extremo a extremo de capa 2. El SP provee sólo una garantía SLA punto a punto para cada conexión PVC y no está relacionado con el QoS IP del cliente. Para proveer QoS IP para voz, vídeo y datos sobre los PVC de Frame Relay, el cliente debe configurar los mecanismos QoS correctos, como modelado de tráfico, LLQ, FRF.12 y compresión RTP (cRTP) en los routers

CE, ya que el enlace WAN Frame Relay es probable que quede congestionado. RED EMPRESARIAL CON SERVICIOS IP En este ejemplo, otro SP ofrece servicios de capa 3 a los clientes. Los routers CE de varios sitios de cliente se conectan a un router PE del SP. Desde la perspectiva particular de un sitio cliente, cada dirección IP que no se localiza en un sitio es alcanzable a través de la red backbone IP del SP. En este entorno, el SP puede proveer servicios IP de valor añadido al cliente, proveyendo SLAs para conformar el tráfico del cliente.

CCNP ONT

81 Una SLA puede, por ejemplo, dividir el tráfico del cliente en el borde de la red con clases de latencia controlada, carga controlada 1 y carga controlada 2, para proveer seguros QoS IP a cada clase de tráfico conforme a la cantidad contractual sobre un backbone IP DiffServ. Para todo el tráfico no conforme, el SP puede re-marcar y entregar este tráfico con un servicio de mejor esfuerzo.

CONOCER LA SLA OFRECIDA POR NUESTRO SP La SLA QoS IP típica ofrecida por la mayoría de los SP a menudo incluye 3 o 5 clases de tráfico. Por ejemplo, la clase de tráfico a tiempo real, la clase de tráfico de misión crítica, una o dos otras clases de

tráfico de datos, y la clase de tráfico de entrega de mejor esfuerzo. La SLA del tráfico en tiempo real debe ser garantizada con un ancho de banda máximo garantizado, mientras que la clase de tráfico de datos debería tener garantizado un ancho de banda mínimo. Típicamente, la localización de ancho de banda se configura como un porcentaje del ancho de banda de la interfaz. Cada clase de tráfico puede también tener garantías de latencia, retardo, jitter y pérdida de paquetes. Si una única interfaz física está sirviendo a sólo un cliente, la SLA se configura típicamente por interfaz. Para proveer actualizaciones de ancho de banda sencillas, los SP a menudo instalan enlaces de alta velocidad al cliente y ofrecen un acceso

subrate. Si una interfaz física única sirve a varios clientes, la SLA es normalmente configurada por PVC o por VLAN.

4.10.2 Requisitos SLA típicos de Voz Para encontrar los requisitos QoS de los distintos tipos de tráfico, tanto la empresa como el SP deben implementar los mecanismos QoS correctos para proveer QoS de extremo a extremo para los paquetes que atraviesan una red IP del SP. En la figura, la empresa HQ y la empresa Branch se conectan a un SP que provee servicios de capa 3. En este ejemplo, el SP provee una SLA para el tráfico de voz con una latencia de 60 ms o menos, un jitter de 20 ms o menos, y una pérdida de paquetes del 0.5% o menos.

4.10.3 Despliegue QoS extremo a extremo Para encontrar los requisitos de los distintos tipos de tráfico, tanto la empresa como el SP deben implementar los mecanismos correctos QoS IP para proveer QoS de extremo a extremo para los paquetes que atraviesa la red del SP. Como se ve en la figura de la página siguiente, esto significa que en ambas localizaciones del cliente, necesita realizarse la clasificación y el marcado, por ejemplo, para los datos de VoIP. Dependiendo de la conexión del cliente al SP, estas marcas pueden mapearse dentro de los bits EXP de MPLS, y darles prioridades.

CCNP ONT

82El proveedor debe ahora garantizar la transferencia correcta sobre el núcleo a la sucursal. El tráfico llega a la misma con las mismas marcas que salieron desde la oficina central, permitiendo de nuevo la clasificación necesaria para realizar un QoS de extremo a extremo. Para proveer QoS de extremo a extremo, tanto la empresa como el SP deben implementar mecanismos QoS correctos para asegurarse de una correcta conducta por salto (PHB) para cada clase de tráfico a lo largo de la red. En el pasado, el QoS IP no

se tenía en cuenta en la red de campus, donde el ancho de banda era más que suficiente. A medida que surgieron nuevas aplicaciones con mayor demanda de ancho de banda, también se ve implementado dentro del campus.

En la siguiente figura se alista algunos de los requisitos dentro de los building blocks que constituyen la red de extremo a extremo. QoS en la capa de acceso se centra en las configuraciones de velocidad y dúplex, clasificación, requisitos de hardware y de colas. QoS en la capa de distribución del campus, se centra en políticas, marcados, y prevención de

congestión. Las configuraciones QoS más complejas ocurren normalmente en el borde WAN. En el núcleo IP (Nube SP), sólo están operativos mecanismos de gestión de congestión y de prevención de congestión. Los mecanismos QoS clave usados en un núcleo IP incluyen LLQ y WRED.

4.10.4 Implementaciones QoS en el Campus Empresarial Los datos de aplicaciones de telefonía IP, videoconferencia, e-learning y misión crítica se están volviendo más comunes en redes empresariales. Las funciones QoS como la clasificación, programación y aprovisionamiento se requieren dentro del campus para gestionar los buffers de salida para minimizar la pérdida de paquetes, retardos y jitter. Algunas de las guías generales a seguir cuando se implementa QoS en el campus, incluyen las siguientes:

- CLASIFICACIÓN Y MARCADO DEL TRÁFICO LO ANTES POSIBLE: Este principio promueve PHB DiffServ de extremo a extremo. A veces, los puntos finales pueden ser de confianza configurando las marcas CoS y DSCP correctamente, aunque está práctica no se recomienda ya que los usuarios podrían fácilmente abusar de las políticas QoS si los mismos tienen permitido marcar su propio tráfico. Por ejemplo, si el DSCP EF recibe servicios prioritarios a través de la red empresarial, un usuario podría fácilmente configurar la NIC del PC para marcar todo el tráfico como DSCP EF.

- CREAR POLÍTICAS DE TRÁFICO NO DESEADO LO MÁS CERCA POSIBLE DE SU ORIGEN: De esta forma logramos que la política borre el tráfico antes de pasarlo al nodo siguiente. Esto es especialmente importante cuando se trata de un ataque DoS o un gusano.

- REALIZAR SIEMPRE QOS A NIVEL DE HARDWARE EN LUGAR DE SOFTWARE, SI ES POSIBLE: Los routers Cisco realiza QoS a nivel de software. Este diseño provoca una demanda adicional de CPU, dependiendo de la complejidad de la política. Los switches Catalyst, sin embargo, realizan el QoS en un hardware dedicado (ASIC), el cual realiza uso de la CPU para administrar las políticas QoS.

CCNP ONT

83Podemos por tanto aplicar políticas QoS complejas en líneas de velocidad Gigabit y 10 Gigabit en estos switches.

- ESTABLECER LÍMITES DE CONFIANZA CORRECTOS: Por ejemplo, en los switches de la capa de acceso, confiar sólo en los el marcado CoS de los teléfonos IP, y no en el de los PC.

- CLASIFICAR VOZ EN TIEMPO REAL Y VIDEO COMO TRÁFICO DE ALTA PRIORIDAD. - USAR MÚLTIPLES COLAS EN LAS INTERFACES DE TRANSMISIÓN: Minimizamos con ello el borrado

potencial o tráfico retrasado causado por la congestión del buffer de transmisión. IMPLEMENTACIÓN QOS EN LA CAPA DE ACCESO Y DISTRIBUCIÓN

Es bastante raro bajo condiciones operativas normales que una red de campus sufra congestión. Si la misma ocurre, es normalmente momentánea y no continua, como en el borde WAN. Sin embargo, aplicaciones como VoIP requieren garantías de servicio sin importar las condiciones de la red. La única forma de proveer garantías de servicio es habilitar colas en cualquier nodo que tenga una congestión potencial. Este riesgo potencial existe en los

enlaces uplink. La única forma de garantizar el servicio en estos casos es habilitar colas en dichos enlaces. El QoS requerido dentro del campus es el siguiente:

- SWITCHES DE LA CAPA DE ACCESO: Clasificación en una base por paquete // Policing o Shaping // Fragmentación // Compresión // Gestión de Congestión // Prevención de Congestión.

- SWITCHES DE LA CAPA DE DISTRIBUCIÓN Y DE NÚCLEO: Clasificación en una base por paquete // Marcado // Gestión de Congestión // Prevención de Congestión.

4.10.5 Implementaciones QoS en el borde WAN Los routers que terminan el enlace WAN entre el CE y el PE requieren un esfuerzo de configuración importante por parte de los administradores de red. REQUISITOS DE ROUTER CE Y PE PARA EL TRÁFICO QUE DEJA LA RED EMPRESARIAL Primero, consideremos que el tráfico deja la red empresarial. Los requisitos QoS en los routers CE y el PE serán diferentes, dependiendo de si el SP gestiona el CE.

En la figura se ilustran 2 posibilidades, un CE gestionado y un CE no gestionado. Para el tráfico que deja la red empresarial por el router CE moviéndose hacia el PE, en la figura se muestran los requisitos QoS generales en los routers CE y PE.

RESPONSABILDIADES QOS DEL SP PARA EL TRÁFICO QUE DEJA LA RED EMPRESARIAL En un servicio CE gestionado, el SP puede reforzar la SLA de cada clase de tráfico usando la política QoS saliente en el CE. Por ejemplo, podemos usar LLQ o CBWFQ para dar una garantía de ancho de banda máxima a las clases de tráfico de voz y vídeo, dar una garantía de ancho de banda mínima a los datos, y usar shaping basado en clases para proveer una cantidad límite máxima a cada clase de tráfico. En un servicio CE no gestionado, debido a que el SP no tiene control sobre el CE del cliente, el SP puede reforzar la SLA para cada clase de tráfico sólo en la entrada de dicho tráfico por el router PE. En este modelo, la política de salida del CE es gestionada y configurada por el cliente, por lo que de cara al SP la misma es irrelevante. En la interfaz de entrada del PE, el SP tiene una política para clasificar, marcar o mapear tráficos. El SP también típicamente implementa políticas de tráfico para limitar la cantidad de tráfico de entrada desde el cliente, de forma que la misma no exceda la cantidad contratada especificada en la SLA. TRÁFICO QOS DEJANDO LA RED DEL SP Ya sea un servicio gestionado o no, el SP puede reforzar la SLA de cada clase de tráfico usando la política QoS de salida en el PE. Puede habilitarse colas y compresión. EJEMPLO: BORDE CLIENTE GESTIONADO CON 3 CLASES DE SERVICIO En este ejemplo, el SP está implementado un backbone IP DiffServ ofreciente 3 clases de tráfico con diferentes SLA para cada una:

CCNP ONT

84- CLASE TIEMPO REAL: Que incluye VoIP, vídeo y señalización de llamadas. LLQ con un ancho de banda

máximo garantizado del 35% del ancho de banda del enlace. - DATOS CRÍTICOS (ENRUTAMIENTO, MISIÓN CRÍTICA, DATOS TRANSACCIONALES Y GESTIÓN DE RED): Puede

tener un ancho de banda mínimo garantizado del 40% del ancho de banda del enlace después que LLQ este servido.

- MEJOR ESFUERZO: Puede tener un ancho de banda mínimo del 25% del enlace.

4.10.6 Diseño del Borde WAN Para clase de tráfico “real-time”, los paquetes VoIP serán marcados con EF e irán dentro de LLQ con los siguientes parámetros:

- LLQ tendrá un ancho de banda máximo del 35% del CIR. - Todo el tráfico que sobrepase este ancho de banda será borrado. - El tráfico de señalización (5%) será compartido con el LLQ del tráfico VoIP.

Para la clase “critical data”, los paquetes serán marcados con un AF31 e irán dentro de CBWFQ con los siguientes parámetros de clase:

- La clase tendrá una garantía de ancho de banda mínimo del 40% del ancho de banda disponible en el enlace.

- Todo el tráfico excedente será re-marcado y enviado. - WRED será usado en este tráfico para optimizar la capacidad de TCP.

Para la clase “best-effort”, los paquetes serán marcados con la clase CS0, e irán en CBWFQ con los siguientes parámetros:

- Tendrá una garantía de ancho de banda de alrededor al 23% del ancho de banda disponible en el enlace.

- Se usará WRED en esta clase para optimizar la capacidad de TCP. Para la clase “scavenger”, los paquetes serán marcados con un CS2, con los siguientes parámetros de clase:

- Tendrá un garantía del 2% del ancho de banda restante disponible del enlace. QOS CE-A-PE PARA ACCESO FRAME RELAY: CE SALIENTE

La política de tráfico llamada “OUT-POLICY” se configura con 3 clases para proveer LLQ o CBWFQ y WRED. Cada clase de tráfico y sus garantías de ancho de banda se configuran usando un porcentaje en lugar de un valor fijo en Kbps. El tráfico de voz y de señalización será identificado por una ACL (101) y será servido por LLQ con un ancho de banda máximo del 25%. El tráfico de misión crítica será coincidido por la ACL 102 y tendrá una garantía de ancho de banda del 75%. El tráfico restante será clasificado

dentro de la clase por defecto, y tendrá una garantía mínima del 25% del ancho de banda restante disponible.

En la figura se muestra un enlace entre CE y PE usando Frame Relay, y el shaping se implementa en el PVC usando FRTS. FRTS se configura usando un class map Frame Relay con un CIR de 256 Kbps, un Bc de 2560 bits y un Be de 0. El CIR mínimo (mincir) es de 256 Kbps. El CIR es la velocidad a la cual enviaríamos datos normalmente cuando no existe congestión. El Bc es la cantidad de bits que enviaremos por intervalo

de tiempo. El CIR y el Bc se usarán para computar un Tc asignado, donde TC=BC/CIR. Para FRTS, la CLI

CCNP ONT

85sólo permitirá valores Bc que resulten en un Tc entre 10 ms. y 125 ms. El valor recomendado es de 10 ms. Para obtener un Tc de 10 ms., el Bc debe configurarse a 1/100 del CIR. Se requiere el parámetro mincir, ya que el IOS sólo permitirá el 75% del mincir para reservarlo a la política QoS aplicada a la clase FRTS. Si no se configura, tendrá por defecto el 50% del valor del CIR, lo cual normalmente no es lo deseado. La fragmentación FRF.12 y el intercalado, junto con cRTP también se habilitan dentro del class map Frame Relay. El tamaño del fragmento en bytes se configura para derivar en un retardo máximo de 10 ms. a 15 ms. El tamaño de fragmento ha de ser igual en ambos extremos. Finalmente, la política OUT-POLICY es aplicada dentro del class map Frame Relay. QOS CE-A-PE PARA ACCESO FRAME RELAY: PE ENTRANTE

La salida de la figura muestra las configuraciones QoS de entrada. La interfaz entrante del router PE implementa la política QoS requerida para cada una de las 3 clases de tráfico del SP. En el PE, una política llamada “IN-POLICY” se configura para proveer la política basada en clases requerida. Para la clase “premium", la velocidad límite se configura a un 25% del ancho de banda del enlace. Todo el tráfico premium excedente es eliminado. Para la clase “business”, la velocidad límite se configura al 38% del ancho de banda del enlace. Todo el tráfico que excede y viola la clase business es re-marcado con una probabilidad de borrado mayor, y después es enviado. La clase por defecto no tiene políticas. La política de tráfico se aplica dentro del class map Frame Relay.

4.10.7 Control Plane Policing (CoPP) Los ataques a la infraestructura se incrementan de forma común, resaltado la necesidad de protección a la misma. La prestación CoPP permite a los usuarios configurar un filtro QoS que gestiona un plano de control de flujo de tráfico para proteger el “control plane” (donde está la tabla de enrutamiento y se decide qué hacer con los paquetes) de los routers y switches Cisco IOS de ataques DoS. Protegiendo el procesador de rutas, CoPP ayuda a asegurar la estabilidad de la red durante un ataque. Por ello, una recomendación es desplegar CoPP como mecanismo clave de protección. PLANOS DE UN ROUTER CISCO Un router tiene 4 componentes funcionales básicos (conocidos como planes): El data plane // El management plane // el control plane // el services plane. La mayor parte del tráfico atravesado por el router va a través del data plane. Sin embargo, el procesador de rutas debe manipular ciertos paquetes, como actualizaciones de enrutamiento, keepalives y gestión de red, referidos como planos de tráfico de control y gestión (magamentent y control planes). Debido a que el procesador de rutas es crítico para la operación de la red, cualquier interrupción al procesador de rutas o a los planos de control y gestión pueden acarrear problemas de impacto en el negocio con relación a la red. Un ataque DoS con el procesador de ruta como objetivo, el cual puede realizarse de forma inadvertida (sin querer) o maliciosa, típicamente recae en altas cuotas de tráfico que resultan en un uso excesivo de la CPU en el mismo procesador de rutas. Este tipo de ataque, el cual puede devastar la estabilidad y disponibilidad de la red, puede presentar los siguientes síntomas:

- Alto uso de la CPU (cerca al 100%) - Pérdida de keepalives y actualizaciones de enrutamiento. - Respuesta lenta o no obtención de respuesta de la CLI debido al alto uso de la CPU. - Procesador de rutas exhausto, como buffers de memoria no disponibles para paquetes IP legítimos.

CoPP dirige la necesidad de proteger los planos de gestión y control, asegurando la estabilidad de rutas, disponibilidad, y entrega de paquetes. Usa una configuración dedicada a través de la MQC para proveer filtros y capacidades de control de paquetes.

CCNP ONT

86DESPLIEGUE COPP CoPP usa la MQC para definir criterios de clasificación de tráfico y especificar acciones de política configurables para el tráfico clasificado. El tráfico de interés debe ser identificado en primer lugar a través de class maps, los cuales se usan para definir paquetes de una clase de tráfico particular. Tras la clasificación, se crean acciones de política reforzadas para el tráfico identificado a través de policy maps. El comando (config)#control-plane permite adjuntar políticas de servicio al control plane. Existen 4 pasos requeridos para configurar CoPP:

- 1/ Definir un criterio de clasificación de paquetes. - 2/ Definir una política de servicio. - 3/ Ingresar al modo configuración del control plane. - 4/ Aplicar la política QoS.

POLÍTICA COPP Y MQC La MQC provee una interfaz flexible para crear políticas de servicio. El tráfico puede ser identificado a través de un class-map y borrar o permitir su acceso al procesador de rutas. El MQC también permite múltiples criterios de coincidencia dentro de una configuración class-map. El router necesita determinar cómo se evaluarán los paquetes cuando hay múltiples criterios de coincidencia dentro de una clase única. Los paquetes deben o cumplir todos los criterios de coincidencia especificados (match all ) o alguno de los criterios (match any ) para ser considerados miembros de la clase.

CCNP ONT

87

5. Implementar AutoQoS Cisco

5.1 Introducción a AutoQoS

5.1.1 AutoQoS Cisco Cisco AutoQoS automatiza el despliegue de políticas QoS en un entorno de negocio general, particularmente para compañías de tamaño medio y sucursales, o grandes compañías. Cisco AutoQoS incorpora una inteligencia de valor añadido en el software IOS y el sistema operativo de los switches Catalyst para aprovisionar y gestionar despliegues QoS. Protege aplicaciones de datos críticos para el negocio para maximizar su disponibilidad. Provee aprovisionamiento QoS para routers y switches, simplificando su despliegue. Los clientes pueden implementar las prestaciones QoS necesarias para el tráfico de voz, vídeo y datos sin un conocimiento profundo de las tecnologías subyacentes (PPP, Frame Relay, ATM, políticas de servicio, etc…). Simplifica la implementación QoS reduciendo los errores humanos potenciales y disminuyendo los costos de cursillos a personal. Crea class-maps y policy-maps basados en la experiencia de Cisco y una metodología de las mejores prácticas. Sigue los estándares de la industria, como el modelo DiffServ, para logar un entorno interoperable. Los clientes, a su vez, puede usar comandos Cisco IOS existentes para modificar las configuraciones automáticas generadas por el AutoQoS, para cumplir sus requisitos específicos. ELEMENTOS CLAVE DEL DESPLIEGUE AUTOQOS

- CLASIFICACIÓN DE APLICACIONES: Cisco AutoQoS usa clasificación inteligente en routers, usando NBAR para proveer una inspección de paquetes profunda y continua. Usa CDP para el reconocimiento de dispositivos, ayudando a asegurar que el dispositivo conectado a la LAN es realmente un teléfono IP de Cisco.

- GENERACIÓN DE POLÍTICAS: Cisco AutoQoS evalúa el entorno de red y genera una política inicial. Automáticamente determina las configuraciones WAN de fragmentación, compresión, encapsulación e internetworking de ATM y Frame Relay, eliminando la necesidad de comprender la teoría y prácticas de diseño QoS en varios escenarios. Los clientes pueden modificar dicha política generada de forma automática.

- CONFIGURACIÓN: Con un comando, AutoQoS configura la interfaz para priorizar tráfico crítico. AutoQoS no sólo detecta teléfonos IP Cisco y habilita configuraciones QoS en el puerto del teléfono, también deshabilita configuraciones QoS para prevenir actividad maliciosa cuando movemos o relocalizamos un teléfono IP Cisco.

- MONITOREO Y REPORTES: AutoQoS provee visibilidad dentro de clases de servicio desplegadas usando loggings y alertas SNMP, con notificaciones de eventos anormales, como por ejemplo borrado de paquetes VoIP. El Cisco QoS Policy Manager (QPM) es la plataforma de monitoreo QoS, la cual usa la inteligencia de la red IP para proveer visibilidad dentro de la operación de red.

- CONSISTENCIA: Las políticas Cisco AutoQoS trabajan juntas a lo largo de los dispositivos Cisco, ayudando a asegurar una configuración QoS consistente de extremo a extremo. El QPM habilita a los usuarios a ver lo siguiente:

o Estadísticas de coincidencia de políticas y filtros específicos, incluyendo los filtros de aplicaciones por NBAR.

o Cantidad de tráfico antes de cualquier acción de política QoS, tráfico transmitido después de las acciones de política QoS, y tráfico borrad debido a las acciones de borrado de la política QoS.

o Estadísticas de acciones QoS: WRED, policing, shaping y queuing. En la figura se muestra una configuración QoS manual y una configuración AutoQoS. Un total de 34 líneas han sido eliminadas de la figura, para que quepa en la página.

CCNP ONT

88

5.1.2 Evolución AutoQoS Cisco AutoQoS ha evolucionado dentro de 2 implementaciones: AutoQoS para VoIP y AutoQoS empresarial. CISCO AUTOQOS VOIP AutoQoS VoIP ofrece capacidades directas de automatizar despliegues VoIP para clientes que quieren utilizar telefonía IP pero que no tienen la experiencia suficiente para planear y desplegar QoS IP y servicios IP. Cisco AutoQoS VoIP fue la primera entrega de AutoQoS y automatiza configuraciones QoS para despliegues VoIP únicamente. Esta prestación genera automáticamente configuraciones de interfaz, policy maps, class maps, y ACLs. Automáticamente emplea NBAR para clasificar el tráfico de voz y marcar el mismo con el valor DSCP apropiado. Podemos instruir a AutoQoS a marcarlo o confiar en las marcas previamente aplicadas a los paquetes. CISCO AUTOQOS EMPRESARIAL Esta entrega de AutoQoS expande las capacidades a los requisitos QoS de una red empresarial convergente. Añade un paso importante: los usuarios pueden observar las aplicaciones descubiertas durante la fase de observación (Auto Discovery) y revistar la política QoS que el AutoQoS sugiere sin desplegar esa política. Esta entrega mezcla el diseño y la implementación de QoS, basado en la mayoría de los escenarios empresariales comunes, en 2 pasos mayores:

- Usando técnicas de descubrimiento NBAR, AutoQoS descubre automáticamente qué aplicaciones usa la red empresarial y genera una política optimizada. Este paso usa el mecanismo NBAR.

- Posteriormente, AutoQoS implementa la política generada.

5.1.3 Despliegue de AutoQoS en switches DESPLIEGUE DE AUTOQOS VOIP EN SWITCHES Existen varios comandos LAN, dependiendo de la plataforma y el sistema operativo. Para los Catalyst basados en IOS, hay 2 comandos de configuración AutoQoS: uno para las conexiones de teléfonos IP y otro para las conexiones seguras a otros dispositivos de red. Sin embargo, sólo se necesita un único comando para habilitar AutoQoS VoIP. Cisco AutoQoS VoIP en la LAN cumple con los siguientes requisitos QoS:

- Un comando único habilita AutoQoS VoIP en la LAN, y otro comando provee soporte a teléfonos Cisco IP y equipos con Cisco IP Communicator.

- AutoQoS automáticamente configura parámetros QoS para un funcionamiento de la voz óptimo basados en las recomendaciones de mejores-prácticas de Cisco, un testeo de laboratorio intensivo, e información recibida desde instalaciones de clientes.

- AutoQoS VoIP determina confianzas y extiende las configuraciones de límites de confianza automáticamente. Un usuario puede pasar por alto el teléfono IP y conectar un PC directamente al switch, pero la confianza es deshabilitada cuando quitamos el teléfono.

- AutoQoS VoIP configura mapeos de clases de servicio (CoS) a DSCP. - Determina configuraciones PQ (cola prioritaria) y WRR (Round Robin basado en pesos) para VLAN

estáticas, de acceso dinámico, de voz (VVLAN) y puertos troncales. Para configurar prestaciones QoS y límites de confianza para los teléfonos VoIP, debemos habilitar la versión 2 CDP o posterior en el puerto del switch, donde el teléfono es conectado. Si no nos aparecerá un mensaje informándonos del hecho. CONFIGURACIÓN DE AUTOQOS EN SWITCHES CATALYST Para los switches basados en IOS, hay 2 comandos de configuración AutoQoS VoIP. Un comando se usa para conexiones seguras a otros dispositivos de red, y el otro para conexiones a teléfonos IP:

- El comando (config-if)#auto qos voip trust activa AutoQoS VoIP en un switch basado en IOS y configura la interfaz entrante para confiar en las marcas CoS QoS recibidas en los paquetes.

- El comando (config-ig)#auto qos voip cisco-phone habilita la prestación de límites de confianza. Esta prestación usa CDP para detectar la presencia o ausencia de un teléfono IP Cisco. Cuando AutoQoS detecta un teléfono IP Cisco, la clasificación de entrada de la interfaz se configura para confiar en las etiquetas QoS recibidas en los paquetes. Este comando extiende el límite de confianza si se detecta un teléfono IP.

Cuando se habilita Cisco AutoQoS en la primera interfaz, QoS se habilita de forma global (se habilitaría si no con el comando (config)#mls qos ).

En el ejemplo de la figura, se muestra como habilitar AutoQoS VoIP para confiar en las marcas QoS recibidas en los paquetes entrantes cuando el switch se conecta a un dispositivo de confianza (router) usando la interfaz Fast Ethernet 0/24. El ejemplo también puesta como habilitar AutoQoS para confiar en las marcas QoS recibidas en paquetes entrantes cuando el dispositivo conectado a la Fast Ethernet 0/11 se detecte como un teléfono IP.

CCNP ONT

89

5.1.4 Cisco AutoQoS Empresarial: Restricciones de despliegue RESTRICCIONES GENERALES La prestación VoIP es soportada sólo en las siguientes interfaces, DLCI y PVCs:

- Interfaces seriales con PPP o HDLC. - Frame Relay (sólo en subinterfaces punto a punto). - Subinterfaces punto a punto ATM de baja y alta velocidad. - Enlaces de internetworking Frame Relay a ATM.

Las interfaces seriales síncronas se clasifican como de baja velocidad si el ancho de banda es menor o igual a 768 Kbps. Esta clasificación también es válida para PVCs ATM. RESTRICCIONES DE INTERFACES SERIALES Para una interfaz serial con un enlace de baja velocidad, MLP (Multilink PPP) se configura de forma automática. La interfaz serial ha de tener una dirección IP. Debemos cumplir las siguientes condiciones para asegurarnos que el tráfico fluya a través del enlace de baja velocidad:

- Debemos tener Cisco AutoQoS Empresarial configurado en ambos finales del enlace. - El total de ancho de banda configurado debe ser el mismo en ambos finales del enlace.

RESTRICCIONES DLCI FRAME RELAY Cisco AutoQoS tiene las siguientes restricciones en entornos Frame Relay:

- No podemos configurarlo en un DLCI Frame Relay si existe un class map asociado al DLCI. - Para DLCIs de baja velocidad configurados para usar en internetworking Frame Relay a ATM, MLP

sobre Frame Relay se configura automáticamente. La subinterfaz debe tener una dirección IP. RESTRICCIONES DE PVC ATM AutoQoS tiene las siguientes restricciones en entornos ATM:

- En un PVC ATM de baja velocidad, no se puede configurar AutoQoS si ya se ha configurado una plantilla virtual para el PVC ATM.

- Para PVCs de baja velocidad ATM, MLP sobre ATM se configura automáticamente. La subinterfaz debe tener una dirección IP.

5.1.5 Consideraciones de Diseño Cuando configuramos AutoQoS, debemos tener en cuenta la plataforma de router, para tener en cuenta las consideraciones de la figura.

- REQUISITOS QOS GENERALES: Métodos recomendados y valores configurados para cumplir los requisitos QoS para el tráfico en tiempo real. AutoQoS tiene en cuenta el tipo de interfaz y el ancho de banda cuando implementa las siguientes prestaciones QoS

o COLA DE BAJA LATENCIA (LLQ): LLQ (específicamente, la cola prioritaria) se aplica a los paquetes de voz para cumplir sus requisitos de latencia. LLQ da a los paquetes de voz RTP prioridad sobre cualquier otro tipo de tráfico cuando se comparte un enlace de salida con voz.

o CRTP (RTP COMPRIMIDO): Con cRTP, la cabecera IP de 40 bytes se reduce a 2 o 4 bytes. Este mecanismo es utilizado en seriales de baja velocidad para mejorar la eficiencia del enlace y disminuir la carga RTP en el paquete causada por las cabeceras de paquete extensivas de voz. Se debe aplicar cRTP a ambos lados del enlace.

o LFI (FRAGMENTACIÓN E INTERCALADO): LFI reduce el jitter en los paquetes de voz previniendo que los paquetes de voz sean retardados por grandes paquetes de datos en una cola cuando la voz en tiempo real y el tráfico de datos en oleadas comparten el mismo enlace de salida de baja velocidad. Se debe aplicar a ambos lados del enlace.

- IMPLICACIONES DE ANCHO DE BANDA: El ancho de banda de la interfaz serial determina la velocidad del enlace. La velocidad del enlace, sin embargo, determina la configuración generada por AutoQoS:

o Cambiar el ancho de banda durante la configuración de AutoQoS no es recomendable. o AutoQoS usa el ancho de banda localizado en el momento que se configura la

prestación. AutoQoS no responde a cambios realizados al bandwith después de ser configurada la herramienta.

- FRAGMENTACIÓN EN REDES FRAME RELAY: Para redes Frame Relay, la fragmentación se configura basándose en el códec G.729 usando un retardo de 10 ms. y un tamaño mínimo de fragmento de 60 bytes. Esta configuración asegura que los paquetes VoIP no son fragmentados. Sin embargo, cuando

CCNP ONT

90usamos el códec G.711 en enlaces de baja velocidad, el tamaño de fragmento configurado por el AutoQoS puede ser menor que el tamaño de un paquete G.711 VoIP. Para resolver este problema potencial, escogeremos una de las siguientes 2 opciones:

o Cambiar el tamaño de fragmento al valor requerido. o Cambiar el códec G.711 con un códec más adecuado para los enlaces de bajo ancho de

banda, como G.729.

5.1.6 Pre requisitos del router Antes de configurar AutoQoS, debemos cumplir los siguientes pre-requisitos:

- Asegurarnos que la interfaz no tiene políticas QoS (service-policies) adjuntadas. - Tener habilitado CEF. Cisco AutoQoS usa NBAR para identificar varias aplicaciones y tipos de tráfico,

y CEF es un pre-requisito para NBAR. - Cisco AutoQoS clasifica enlaces como de baja velocidad o alta velocidad, en base a su ancho de

banda. Es importante que se especifique el ancho de banda correcto en la interfaz o subinterfaz donde se va a habilitar AutoQoS:

o Para todas las interfaces o subinterfaces, usar el comando bandwidth correctamente. Basar el mismo en la velocidad del enlace o la interfaz.

o Si la interfaz tiene una velocidad de 768 Kbps o menos, debemos configurar una dirección IP en la misma con el comando ip address . Por defecto, AutoQoS habilita MLP y copia la IP configurada a la interfaz “manojo” (bundle) multienlace.

Además de los pre-requisitos AutoQoS, existen otras recomendaciones requisitos para configurar AutoQoS. Debemos ser conscientes de que esto puede cambiar con las versiones de software IOS. Verificar los siguientes pre-requisitos antes de implementar AutoQoS en cualquier entorno:

- Cisco AutoQoS está soportado sólo en las siguientes interfaces y PVCs: o PVCs ATM. o Interfaces seriales PPP o HDLC. o DLCIs Frame Relay en subinterfaces punto a punto.

- Se puede ajustar una plantilla generada por AutoQoS en una interfaz o PVC, si se desea. - Para incluir alertas SNMP (eventos de monitoreo), se debe habilitar SNMP en el router. Las alertas

AutoQoS SNMP se entregan sólo cuando usamos un servidor SNMP en conjunto con AutoQoS y el router sabe cómo alcanzar a dicho servidor.

- La cadena de comunidad SNMP “AutoQoS” debe tener permisos de escritura. - Si reiniciamos el dispositivo con la configuración salvada, la sonda RMON puede generar algunos

mensajes de advertencia. Podemos ignorar los mismos. - Por defecto, los routers Cisco reservan el 75% del ancho de banda de la interfaz para clases

definidas por el usuario. El ancho de banda restante se mantiene para la clase por defecto. Sin embargo, el ancho de banda restante no está garantizado para la clase por defecto. Esta clase y el tráfico excedente comparten este ancho de banda de forma proporcional.

5.1.7 Despliegue de AutoQoS Empresarial en routers: Un enfoque de 2 pasos Cisco AutoQoS empresarial consiste en 2 fases de configuración: 1/ Auto descubrimiento (recolección de datos) ; 2/ Generación de plantilla AutoQoS e instalación. La fase de auto descubrimiento usa NBAR para detectar las aplicaciones en la red y realiza un análisis estadístico del tráfico de red. Los datos recogidos deberían ser una muestra representativa del volumen y tipo de voz, vídeo y datos de la red. Por tanto, se necesita una cierta cantidad de tiempo para coleccionar estos datos. Ejecutaremos la fase de auto descubrimiento tanto tiempo como sea necesario. Este tiempo puede variar, dependiendo del volumen y naturaleza del tráfico de la red. Por defecto, Auto Discovery se ejecuta durante 3 días. La fase de generación de plantilla e instalación genera plantillas desde los datos recolectados durante la fase de descubrimiento, e instala las mismas en la interfaz. AutoQoS entonces usa estas plantillas como la base de la creación de class maps y policy maps para la red. Tras crearlos, instala los mismos en la interfaz. AutoQoS VoIP omite la fase de descubrimiento y va directamente a la generación e instalación de las plantillas, por ello es mejor la prestación que ahora nos compete. FASE 1: PERFILES DE TRÁFICO EN ROUTERS Y AUTO DESCUBRIMIENTO Iniciamos la fase de auto descubrimiento usando el comando (config-if)#auto discovery qos . Antes de usar este comando nos aseguraremos de que los siguientes pre-requisitos existen:

- CEF está habilitado. - Si la interfaz o subinterfaz tiene una velocidad de 768 Kbps o menor, configurar las direcciones IP

primaria o secundaria. - Para todas las interfaces o subinterfaces, configurar la cantidad de ancho de banda usando el

comando bandwidth . Localizar el mismo basado en la velocidad real de la interfaz. Cuando ejecutamos Auto Discovery, observamos estas restricciones:

- El comando (config-if)#auto discovery qos no se soporta en subinterfaces. - No cambiar el ancho de banda de la interfaz cuando se usa este comando. - Eliminar todas las políticas previamente adjuntadas a la interfaz.

CCNP ONT

91La palabra opcional trust indica que las marcas DSCP de un paquete son de confianza para la clasificación de voz, vídeo y tráfico de datos. Si no la especificamos, AutoQoS clasifica la voz, el vídeo y el tráfico de datos usando NBAR, y los paquetes se marcan con el valor DSCP apropiado. Si queremos detener Auto Discovery, usamos el comando (config-if)#no auto discovery qos . Este comando para la re-colección y remueve cualquier dato recolectado generando un reporte. Si queremos ver los resultados temporales de Auto Discovery mientras está en progreso, usamos el comando #show auto discovery qos . Este comando muestra el resultado de los datos recolectados durante la fase de descubrimiento automático. FASE 2: CONFIGURACIÓN POLÍTICAS QOS EN ROUTERS El comando (config-if)#auto qos genera plantillas AutoQoS empresariales basadas en los datos recolectados durante la fase 1 e instala las mismas en la interfaz. Para eliminar la plantilla de la interfaz

usamos la forma no del comando. Podemos usar el comando (config-if)#auto qos para habilitar AutoQoS VoIP, el cual no se beneficia del auto descubrimiento previo. La palabra clave opcional fr-atm habilita AutoQoS VoIP para enlaces de internetworking Frame Relay-a-ATM. Esta opción está disponible en DLCIs Frame Relay para Frame Relay-a-ATM. En la figura se muestra un ejemplo

de configuración.

5.1.8 Verificación de Cisco AutoQoS El comando más importante de verificación usado en routers y switches es #show auto qos . Debido a que los switches Catalyst usan mapeos CoS-a-DSCP para las colas de paquetes salientes, podemos usar el comando #show mls qos maps para verificar como AutoQoS define estos mapeos. MONITOREO DE AUTOQOS EN ROUTERS CISCO

- PASO 1: Mostrar los datos recolectados durante la fase de auto descubrimiento. o Usamos el comando #show auto discovery qos para mostrar los datos

recolectados durante la fase de descubrimiento. o La salida de la política propuesta permite tener una previsualización de los class maps y

policy maps antes de ingresar el comando auto qos en la interfaz. Podemos continuar con la fase de Auto Descubrimiento para atesorar aún más datos, recomendándose hacerlo durante varios días.

o La palabra opcional interface indica que sólo se muestran las configuraciones o específicas de la interfaz descrita.

- PASO 2: Examinar las plantillas AutoQoS y la configuración inicial. o El comando #show auto qos se usa para mostrar las plantillas de interfaz AutoQoS,

policy maps, class maps y ACLs. o Cuando se usa la palabra interfaz el comando muestra las configuraciones AutoQoS

de la interfaz especificada. Si no se muestran todas las interfaces o PVCs donde está habilitado.

o Se muestra el resultado obtenido en la página siguiente.

CCNP ONT

92

- PASO 3: Mostar los datos recolectados durante la fase de Auto Descubrimiento. o Para mostrar las estadísticas de todas las clases que están configuradas para todas las

políticas de servicio ya sea en una interfaz o subinterfaz o en PVC específico de la interfaz, usamos el comando #show policy-map interface .

o Los contadores mostrados después de ingresar el comando se actualizan sólo si hay congestión en la interfaz.

MONITOREO AUTOQOS EN SWITCHES

- PASO 1: Examinar las plantillas AutoQoS y la configuración inicial: o Usar el comando #show auto qos para mostrar la configuración AutoQoS VoIP inicial

en el switch. En la salida del comando mostrada en la siguiente imagen, podemos ver que el switch tiene 4 colas de salida WRR disponibles, con pesos 20, 1, 80 y 0 para las colas 1, 2, 3 y 4 respectivamente. El comando wrr-queue cos muestra el mapeo CoS para cada cola (el primer número es el ID de cola, el segundo el ID de umbral y los demás los valores CoS).

� La cola 4 se usa para tráfico de alta prioridad. � La cola 3 no se usa. � La cola 1 obtiene el 20% de cualquier ancho de banda que no esté siendo

usado por la cola 4, y provee CoS 0, 1, 2 y 4. � La cola 3 obtiene el 80% de cualquier ancho de banda que no se esté usando

por la cola 4 y provee CoS 3, 6 y 7. � El mapeo CoS a DSCP es mostrado.

- PASO 2: Explorar los parámetros QoS autogenerados a nivel de interfaz: o Usamos el comando #show mls qos interface para mostrar la información QoS a nivel

de interfaz, incluyendo la configuración de las colas de salida y los mapeos CoS-a-DSCP, las políticas configuradas y las estadísticas de ingreso y salida (incluyendo el número de bytes borrados).

CCNP ONT

93

- PASO 3: Examinar los mapas CoS-a-DSCP: o Usamos el comando #show mls qos maps , como se muestra en la siguiente figura,

para mostrar los mapeos actuales de DSCP y CoS. Todos los mapas se definen de forma global.

o La palabra cos-dscp presenta el mapeo CoS-a-DSCP por defecto. Los valores soportados son de 0 a 7.

o La palabra dscp-cos , presenta los mapeos por defecto de DSCP-a-CoS. Los valores DSCP soportados son 0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48 y 56.

o Después de aplicar un mapeo por defecto, podemos definir los mapeos CoS-a-DSCP y DSCP-a-CoS insertando comandos mls qos map .

5.2 Tareas Comunes Cisco AutoQoS

5.2.1 Automatización con Cisco AutoQoS Los requisitos típicos empresariales incluyen la siguiente lista:

- Identificar límites de confianza y extender el límite de confianza y los protocolos de interés. - Determinar el número de clases DiffServ que serán definidas por la red empresarial. - Re-marcar tráfico basado en los requisitos de la política local. - Determinar los métodos de colas que deberían ser implementados. - Definir el ancho de banda individual de cada clase para cumplir los requisitos de tráfico a tiempo real

y proveer garantías de ancho de banda mínimo para otras aplicaciones. - Definir prestaciones QoS específicas de transporte (shaping, MLP, …). - Para enlaces de bajo ancho de banda, especificar las prestaciones QoS necesarias (compresión RTP,

fragmentación MLP (LFI), o fragmentación Frame Relay (FRF.12)). - Definir alarmas y configuraciones de eventos para propósitos de monitoreo.

Además, en un entorno LAN, AutoQoS tiene los siguientes requisitos: - Determinar mapeos CoS-a-DSCP y Procedencia IP-a-DSCP. - Mapear valores CoS a diferentes colas de salida (a través de los mapas CoS-a-DSCP). - Configurar el tamaño de las colas y los pesos WRR (Weighted Round Robin).

5.2.2 Mecanismos DiffServ habilitados por AutoQoS Usando las recomendaciones de mejores prácticas de Cisco, AutoQoS habilita varios mecanismos QoS para asegurar un funcionamiento óptimo del auto descubrimiento. AutoQoS de forma automática aprovisiona 6 mecanismos QoS usando la tecnología DiffServ:

- CLASIFICACIÓN: La clasificación de paquetes provee la habilidad de partir el tráfico de red en múltiples niveles de prioridad o clases de servicio. Por ejemplo, usando los valores DSCP definidos, la red puede clasificar tráficos de aplicación en un máximo de 64 clases. AutoQoS define hasta 10 clases. Cuando se clasifican paquetes, usamos varias prestaciones QoS del Cisco IOS para asignar las políticas de manipulación apropiadas a cada clase de tráfico.

- MARCADO: Las herramientas de marcado marcan un paquete o flujo con una prioridad específica. Esta marca se realiza en el límite de confianza. La clasificación y el marcado deben realizarse en el borde de la red, normalmente en los switches de los armarios de cableado, dentro de los mismos teléfonos IP o en puntos finales habilitados para voz. Los paquetes pueden marcarse como importantes usando configuraciones CoS de capa 2, en la parte 802.1p de la cabecera 802.1Q, o en los bits de procedencia IP // DSCP del byte ToS de la cabecera IPv4.

CCNP ONT

94- GESTIÓN DE CONGESTIÓN: Las herramientas de gestión de congestión asignan a un paquete o flujo

una o varias colas, basadas en la clasificación, para un tratamiento adecuado en la red. Cuando se colocan datos, voz y vídeo dentro de la misma cola, la pérdida de paquetes y jitter es más fácil de que se produzca. Podemos incrementar el comportamiento predecible de la red y la calidad de voz usando múltiples colas en interfaces de salida y colocando los paquetes de voz en una cola de prioridad estricta (LLQ) con ancho de banda garantizado, separada de la de los paquetes de datos. Para aliviar los efectos de la congestión y proveer aplicaciones empresariales con ancho de banda garantizado y la menor latencia posible, AutoQoS habilita las siguientes colas IOS:

o LLQ para aplicaciones en tiempo real para experimentar la menor latencia en la cola de salida y asegurar suficiente ancho de banda en el enlace para un funcionamiento de la voz óptimo. LLQ procesa tráfico clasificado dentro de la clase DiffServ de envío explícito (EF) (clase de voz) como de mayor prioridad y coloca ese tráfico en una cola separada de prioridad estricta.

o CBWFQ para aplicaciones de datos para proveer suficiente ancho de banda y reducir la interferencia entre aplicaciones de alta y baja prioridad durante periodos de congestión. CBWFQ procesa tráfico clasificado dentro de clases DiffServ de envío asegurado (AF) (vídeo y datos clasificados) y una clase por defecto para el tráfico sin clasificar (mejor esfuerzo).

o WRR con cola prioritaria (PQ) en switches Catalyst procesa el tráfico en los puertos de salida del switch usando DiffServ (DSCP se mapea al CoS en el puerto de ingreso automáticamente), asegurando prioridad al tráfico en tiempo real y un ancho de banda predecible para otros tipos de tráfico.

- SHAPING: El shaping es un mecanismo QoS usado para enviar tráfico en pequeñas oleadas a radios de transmisión configurados. Es usado comúnmente en entornos Frame Relay donde el clock rate de la interfaz no tiene el mismo ancho de banda configurado o contratado (CIR). El shaping de tráfico Frame Relay (FRTS) es la aplicación más común de shaping de tráfico en entornos VoIP. En los escenarios Frame Relay hub and spoke normalmente la velocidad del enlace hub es mayor que la de cualquiera de los demás enlaces remotos, lo cual causa el fenómeno de la “oversubscription”. Sin FRTS el hub intenta enviar datos a cantidades mayores que las que pueden ser recibidas por los enlaces remotos, causando que la red Frame Relay borre tráfico de forma arbitraria. Sin embargo, los enlaces remotos podrían enviar un agregado de tráfico que podría ser mayor que el que el hub puede recibir, de nuevo causando borrados arbitrarios. Debido a que la red Frame Relay no tiene inteligencia de capa 3, puede borrar tráfico VoIP si se viola el contrato. Por ello, se necesita controlar la tasa de transmisión en una nube Frame Relay para saber que paquetes son borrados y cuales obtienen un servicio de prioridad estricta.

- PREVENCIÓN DE CONGESTION: Las técnicas de prevención de congestión monitorean la carga de tráfico de red en un esfuerzo de anticipación y prevención de congestión en cuellos de botella de red comunes. El funcionamiento por defecto del router es el uso de un mecanismo de borrado de paquetes tosco llamado “tail drop”. Con tail drop, los paquetes se borran durante períodos de congestión si no caben dentro de la cola de salida, lo cual afecta de la misma forma a todos los tipos de tráfico, incluyendo el de alta prioridad. Otro ejemplo del tail drop es la “sincronización global” y ocurre en olas pico de congestión. La sincronización global ocurre cuando múltiples sesiones TCP reducen su tasa de transmisión en respuesta al borrado de paquetes. Posteriormente, todos a la vez incrementan su tasa de transmisión cuando se reduce la congestión, volviéndose a producir la misma. AutoQoS usa WRED para prevenir el borrado de paquetes de alta prioridad y la sincronización global. WRED incrementa la probabilidad de que la congestión se prevenga borrando paquetes de baja prioridad en lugar de paquetes de alta prioridad.

- EFICIENCIA DEL ENLACE: Los enlaces de baja velocidad pueden degradar tremendamente la calidad de la voz. El tráfico de voz puede sufrir grandes retardos antes de alcanzar la línea de transmisión. Cuando AutoQoS detecta un enlace de baja velocidad, minimiza estos problemas habilitando 2 mecanismos de eficiencia de enlaces. LFI es el método utilizado para mejorar el retardo de serialización. Aún cuando las colas están trabajando de la mejor forma y priorizando el tráfico de voz, existen momentos en los que la cola está vacía y un paquete de otra clase es servido. Si un paquete VoIP llega a la cola de salida mientras que el paquete anterior está siendo servido, el paquete VoIP espera detrás del paquete de datos, pudiendo sufrir un retardo que cause una mala calidad de llamada VoIP. Como ejemplo, en una línea de 64 Kbps, con un paquete delante de 1500 bytes el paquete VoIP tendría que esperar 187,5 ms, cuando lo normal es que los paquetes de voz se transmitan a intervalos de 20 ms. AutoQoS habilita 2 de los siguientes mecanismos LFI para fragmentar grandes paquetes para proteger a la voz, cuando se auto descubren enlaces de baja velocidad:

o MLP con intercalado para enlaces PPP. o FRF.12 para PVCs Frame Relay.

cRTP reduce 40 bytes de cabeceras a 2 o 4 bytes, reduciendo el ancho de banda requerido para una llamada de voz en enlaces punto a punto. Cisco AutoQoS habilita cRTP cuando la voz se transmite a través de enlaces de baja velocidad.

CCNP ONT

95

5.2.3 Aprovisionamiento automático para clases DiffServ con AutoQoS La siguiente tabla alista el nombre de la clase, el tipo de tráfico destinado a esa clase, y el valor DSCP para el tipo de tráfico, si es aplicable.

5.2.4 Tareas comunes con AutoQoS Aunque AutoQoS automatiza el despliegue QoS, su objetivo son los escenarios de red empresariales más comunes. Las clases QoS y las plantillas que genera pueden no satisfacer todos los requisitos de la red. Las siguientes 3 tareas más comunes pueden surgir cuando usamos AutoQoS para generar políticas:

- AUTOQOS GENERA DEMASIADAS CLASES Y SE COMPLICA MÁS DE LO NECESARIO: AutoQoS genera hasta 10 clases DiffServ, dependiendo del número y tipos de aplicaciones y protocolos detectados durante el auto descubrimiento. La mayoría de las empresas de hoy en día despliegan sólo de 3 a 6 clases de forma que la configuración sea manejable. No existe un ajuste en AutoQoS para disminuir el número de clases que genera. La única solución es manualmente consolidar clases similares para producir el número de clases deseado.

- AUTOQOS GENERA PLANTILLAS QOS BASADAS EN CONDICIONES DESCUBIERTAS POR EL AUTO DESCUBRIMIENTO: El auto descubrimiento debe ser ejecutado durante varios días para maximizar la probabilidad de que genere políticas que sean cercanas a la realidad diaria de la red. Si las condiciones de red cambian después de que AutoQoS ha auto generado las plantillas, la fase de Auto Descubrimiento y el despliegue de plantillas QoS debe repetirse para adaptarse a la configuración de las nuevas condiciones de tráfico.

- AUTOQOS, AÚN DESPUES DE REPETIRSE Y REALIZAR UN AUTO DESCUBRIMIENTO EXTENSO, NO GENERA LAS PLANTILLAS QOS ESPERADAS: La inteligencia propia de AutoQoS se basa en una guía de mejores prácticas de Cisco y la experiencia con sus clientes. Sin embargo, hay algunas excepciones especiales. En particular, los requisitos de despliegue pueden ser superiores a las capacidades actuales o circunstancias que simplemente no son detectables ya que requieren un factor de inteligencia humana. Por ejemplo, la clasificación puede ser producto de una mezcla de parámetros complejos y específicos. En estas situaciones, se puede usar AutoQoS para generar los class maps y policy maps iniciales, los cuales pueden personalizarse para lograr los requisitos especificados.

5.2.5 Interpretar las configuraciones AutoQoS Para inspeccionar las plantillas resultantes después de aplicar AutoQoS, usamos el comando #show auto qos . El comando se usa específicamente para examinar la siguiente información:

- Cuántas clases identificó AutoQoS. Este valor se ve como un número de class maps. - Qué opciones de clasificación de tráfico seleccionó AutoQoS. Este parámetro se ve como un comando

match dentro del class map respectivo. - Qué opciones de marcas de tráfico seleccionó AutoQoS. Podemos ver estas opciones en los policy

maps buscando el comando set . - Qué mecanismos de colas designó AutoQoS y qué parámetros de colas fueron proyectados. Podemos

ver está información en el policy map buscando el comando bandwidth o el comando priority con su información individual.

- AutoQoS también puede sugerir parámetros de tráfico como el CIR en redes Frame Relay, visto en el class map Frame Relay.

- Como aplicó AutoQoS la política auto generada a la configuración existente del router. AutoQoS puede aplicar la política a una interfaz serial, subinterfaz, DLCI o PVC. La información se provee también con el comando anterior.

- INTERPRETAR LA SALIDA DEL COMANDO SHOW AUTO QOS En la figura de la página siguiente se muestra una salida de este comando. La información detallada del comando varía dependiendo de las condiciones de tráfico descubiertas por AutoQoS, pero siempre tendrá ciertos elementos comunes:

- El comando muestra la política auto generada, aplicada en forma de policy maps. En esta sección, los mecanismos de colas son evidentes (LLQ o CBWFQ), pero esta sección también puede mostrar marcas basadas en clases, shaping basado en clases, prevención de congestión (WRED) y mecanismos de eficiencia de enlaces (cRTP o LFI). Cada mecanismo QoS aparece en la salida generada de la misma forma que si hubiera sido configurado manualmente desde la MQC.

CCNP ONT

96- Otra información importante del comando es la clasificación, mostrada en forma de class maps MQC.

El class map puede usar clasificación NBAR o procedencia IP o DSCP cuando AutoQoS se ejecuta en modo confiable. En cualquier caso, el comando match se usa dentro de class maps individuales con los parámetros apropiados.

- En algunas situaciones especiales, como en PVCs Frame Relay, AutoQoS puede construir 2 policy maps, uno anidado al otro. El propósito es usar shaping basado en clases para adecuar el tráfico dentro de un PVC específico mientras se gestiona la congestión usando técnicas de colas correctas.

RMON Los clientes tienen normalmente avalanchas de montañas de datos, pero muy poca información relevante que les ayude a identificar la raíz de un problema. Obteniendo la información correcta puede ser bastante

caro, y a menudo puede ser demasiado tarde para ser útil. Un ejemplo clásico es encontrar “quien” (esto es, el usuario o dirección IP) está causando congestión o creando cargas anormales en un enlace. Sin automatización, puede llevar varios meses establecer un proceso de monitoreo correcto. AutoQoS provee visibilidad dentro de clases de servicio desplegadas a través de loggings y alertas SNMP, con notificaciones de eventos anormales (como borrar paquetes VoIP).

La salida del comando show auto qos muestra la información de que se envían alertas cuando se borra un paquete de voz. Esto es usado para monitoreo y solución de problemas. En algunas situaciones, como se ve en la figura, AutoQoS también proyecta nuevos parámetros de tráfico. En la figura, AutoQoS genera un nuevo class map Frame Relay, el cual se mapea a el DLCI específico usando el nombre utilizado para el class map. Además de los contenidos de las configuraciones de interfaz, podemos mostrar policy maps y class maps usando el comando show auto qos . Las ACL también se muestran dentro del mismo.

5.2.6 Modificar la configuración AutoQoS activa con la MQC Esta tarea ocurre normalmente en 2 situaciones:

- La configuración AutoQoS generado no cumple las expectativas específicas de la empresa. - Las condiciones de la red o del tráfico han cambiado mientras AutoQoS generaba la configuración, y

los administradores tienen que usar sus habilidades para adaptar la configuración QoS existente en lugar de ejecutar el despliegue AutoQoS de nuevo desde el principio.

MODIFICAR LA CONFIGURACIÓN ACTIVA AUTOQOS CON MQC: CLASIFICACIÓN Comúnmente, AutoQoS usa NBAR y ACL para la clasificación de tráfico. Sin embargo, cualquier mecanismo de clasificación MQC puede suplir o reemplazar la configuración generada.

CCNP ONT

97Se necesitan habilidades significativas y conocimientos de MQC para realizar modificaciones, pero este procedimiento puede adaptar la clasificación a reglas de clasificación más complejas. Hay varias formas de personalizar y modificar los class maps existentes:

- Directamente desde la CLI usando MQC. - Usando QPM (Cisco QoS Policy Manager).

Sin embargo, la forma más fácil de personalizar un class map existente es copiar el mismo a un bloc de notas y modificar su configuración fuera de línea. Añadir la nueva clasificación deseada y eliminar la indeseada existente. La MQC de Cisco ofrece un amplio rango de opciones de clasificación para usar cuando se añaden reglas a un class map generado por AutoQoS.

5.2.7 Modificar la política AutoQoS generada con la MQC Cuando generamos plantillas de políticas QoS, AutoQoS habilita varios mecanismos QoS IOS. Los mecanismos habilitados incluyen:

- Programación de tráfico y gestión de congestión usando LLQ, CBWFQ o WRR. - Marcado de tráfico usando marcas basadas en clases. - Shaping usando shaping basado en clases o FRTS. - Eficiencia del enlace usando cRTP y LFI (MLP o FRF.12). - Prevención de congestión usando WRED.

La configuración generada por AutoQoS puede ser personalizada a través de la MQC. El procedimiento para modificar un política activa existente generada por AutoQoS es similar al de la clasificación.

CCNP ONT

98

Tema 6. Implementar Escalabilidad Wireless

6.1 Implementar QoS WLAN

6.1.1 Un estándar para el QoS WLAN Las WLAN se superponen o sustituyen a las LAN cableadas tradicionales. Están basadas en el estándar 802.11. Este estándar extiende el 802.3 al dominio wireless, aunque con algunas complicaciones:

- Tanto las WLAN como las LAN cableadas definen la capa física y enlace de datos y usan direcciones MAC.

- Las LAN y las WLAN usan muchos protocolos y aplicaciones iguales. Ejemplos de protocolos son IP e IPsec para VPNs. Ejemplos de aplicaciones son web, FTP y SNMP.

- Las WLAN usan la tecnología CSMA/CA en lugar de CSMA/CD de las LAN cableadas. - Las LAN comúnmente usan servicios diferenciados de capa 3 (DSCP) o 802.1p en la capa 2 para

asegurar prioridades y proveer servicios QoS. El estándar nuevo 802.11e es una extensión del 802.11 que provee una transmisión RF más consistente y de más calidad para la voz y el vídeo.

6.1.2 Descripción del QoS para WLAN El IEEE estandarizó en 2005 el 802.11e como un conjunto de tecnologías para priorizar tráfico y prevenir colisiones de paquetes y retardos para mejorar el funcionamiento de la voz y el vídeo sobre WLANs. La especificación 802.11e usa la misma prioridad de 8 niveles que 802.11p. Estos se agrupan en 4 categorías de acceso o clases de tráfico, mostradas a continuación:

- VOZ: Prioridad 7 o 6 para llamadas VoIP que requieren baja latencia. - VÍDEO: Prioridad 5 o 4 para streams de vídeo SRTV o HDTV. - MEJOR ESFUERZO: Prioridad 3 o 0 para aplicaciones de latencia intensiva interactivas. - BACKGROUND: Prioridad 2 o 1 para aplicaciones de transferencia de datos en lote (batch) e indica un

tratamiento menor al mejor esfuerzo. Cada nivel de acceso provee una cola separada. Para identificar la clase de cada paquete, el estándar usa marcas similares a las usadas en Ethernet cableada. Viendo estas marcas, un punto de acceso manipula paquetes de acuerdo a la prioridad que tienen asignada los mismos. Para acelerar la adopción de QoS en el mercado 802.11, se implemento WMM (Wi-Fi multimedia) antes de que el estándar 802.11e fuera aprobado. WMM es un subconjunto

del estándar 802.11e que usa 4 categorías de acceso en lugar de las 8 utilizadas por 802.11e. WMM provee un grupo de prestaciones para redes wireless en busca de mejorar el funcionamiento de las aplicaciones de audio, vídeo y voz. El QoS resultante permite traducir desde el 802.1p o desde el DSCO para usar la técnica de RF apropiada.

6.1.3 Tiempo de Backoff en WLAN QoS RF El método de acceso fundamental en 802.11 es CSMA/CA. CSMA/CA trabaja “escuchando antes de hablar”. WMM usa la función DCF (función de coordinación distribuida). Si el medio no está ocupado, la transmisión se lleva a cabo. CSMA/CA usa un tiempo aleatorio de backoff para prevenir colisiones en estaciones que comparten el medio. Cada cliente espera un tiempo de backoff aleatorio y entonces transmite sólo si ningún dispositivo ha empezado a transmitir antes que él.

Usando EDCF (DCF mejorado), WMM estipula distintos niveles de tiempos de espera aleatorios para las 4 categorías de acceso para proveer el acceso a la red más favorable a aplicaciones que son menos tolerantes a retardos. WMM provee acceso prioritario al medio RF de 2 formas: 1/ Primero, el punto de acceso wireless debe priorizar los datos en 3 categorías de acceso (de mayor a menor: platino, oro, plata y bronce).

2/ Segundo, el tráfico de menor prioridad debe usar un temporizador de espera entre tramas mayor para permitir al tráfico de alta prioridad acceder a la red wireless primero.

CCNP ONT

99

6.1.4 Lightweight AP – Arquitectura MAC partida Existen 3 enfoques opuestos de proveer acceso wireless. El primero, el cual se está volviendo menos popular, usa puntos de acceso autónomos con mucha inteligencia. Los puntos de acceso autónomos pueden comunicarse con routers existentes y soportar aplicaciones robustas. Este estilo de gestión WLAN, referido como arquitectura distribuida, trabaja bien pero es caro y requiere APs que pueden trabajar con una infraestructura de vendedor específica. El segundo enfoque toma la inteligencia de los APs y la coloca dentro de switches o routers para permitir que la red escale reduciendo el costo total del despliegue WLAN. Este enfoque guía el despliegue de LWAPP (Ligtweight Access Point Protocol), resultando en un nuevo paradigma de gestión de despliegues WLAN. LWAPP usa el concepto de “MAC-partida” (Split MAC), el cual tiene la habilidad de separar aspectos de tiempo real del protocolo 802.11 de la mayoría de los aspectos de gestión.

Cisco ha diseñado una arquitectura LWAPP centralizada para que sólo se necesite un único gestor RF en la empresa. El punto de acceso manipula actividades sensibles al tiempo, como manipulación de beacons, handshakes con los clientes, cifrado de capa MAC y monitoreo RF. El controlador WLAN manipula todas las demás funciones. Estas funciones

incluyen la gestión de protocolos, traducción de tramas y funciones de puenteo, así como políticas para movilidad de usuarios, seguridad, QoS y, tal vez la más importante, gestión RF a tiempo real.

6.1.5 Desafíos WLAN QoS Proveer QoS en un entorno WLAN es un desafío a causa de lo siguiente:

- El QoS de extremo a extremo usa marcas DSCP. - Wireless RF usa marcado de capa 2. - En el modelo de despliegue de Cisco, el tráfico destinado a puntos de acceso no contiene

información de etiqueta QoS 802.1p ya que el punto de acceso se conecta a un puerto en modo de acceso del switch Catalyst, y no a un troncal.

- Como resultado, los paquetes transmitidos sobre la WLAN también perderán la información QoS de capa 2.

Es vital usar la información DSCP de la capa 3 para proveer QoS en ausencia de información QoS de capa 2, por lo que se necesita una solución. Los controladores de WLAN que usan la versión 3.2 o superior aseguran que los paquetes reciben la manipulación QoS correcta durante una transmisión de extremo a extremo. Los controladores WLAN aseguran que el paquete mantiene la información QoS mientras atraviesa la red usando marcas IEEE 802.11e o mapeos WMM. El QoS de extremo a extremo requiere un mapeo de capa 2 del 802.1p o de capa 3 del DSCP a wireless RF usando 802.11e o WMM.

6.1.6 Implementación QoS en WLAN Cuando la voz o el vídeo usa un WLAN, el servicio debe integrarse con la red cableada y con los sistemas VoIP para entregar un servicio consistente de alta calidad de extremo a extremo. Los paquetes WLAN 802.11e deben mapearse a paquetes LAN 802.1p y vice-versa.

En la figura se muestra como el tráfico originado en la red cableada pasa a través de un switch LAN a un controlador, a través de túneles LWAPP a un punto de acceso, y finalmente al cliente wireless. PASO 1/ El tráfico viaja desde el switch Ethernet al controlador. PASO 2/ El tráfico viaja desde el punto de acceso al cliente wireless. PASO 3/ El tráfico viaja desde el cliente al punto de acceso. PASO 4/ El tráfico viaja desde el controlador al switch Ethernet.

CCNP ONT

100PASO 1: DESDE EL SWITCH ETHERNET AL CONTROLADOR Y AL TÚNEL LWAPP

Cuando un controlador WLAN envía un paquete LWAPP a un punto de acceso, debe contener la información QoS del paquete Ethernet original que viene desde el switch Ethernet. El controlador coloca esta

información en la cabecera externa del paquete LWAPP. Los paquetes de control LWAPP siempre se etiquetan con un valor 802.1p de 7, mientras que los paquetes de datos encapsulados por LWAPP se derivan del valor DSCP y 802.1p del paquete original. TRADUCCIONES DE MARCAS DE PAQUETE QOS

Existe un mapeo por defecto entre DSCP, 802.1p y 802.11e, como se muestra en la figura. El nivel de prioridad 7 802.1p requiere una manipulación especial ya que este nivel se reserva para el control de LWAPP. Los paquetes de datos con una prioridad de 7 son siempre degradados a 6 o un DSCP de 46.

PASO 2: FUERA DEL TÚNEL Y A TRAVÉS DEL AP O EL CLIENTE WIRELESS Cuando un paquete va desde un AP al cliente, el valor DSCP del paquete LWAPP entrante se mapea a la prioridad 802.11e. Para un cliente WMM, el AP traduce el valor DSCP del

paquete LWAPP entrante al valor de prioridad 802.11e. El AP controla el valor para asegurarse que no excede el máximo permitido, basándose en la política QoS WLAN asignada a ese cliente. Entonces, el AP coloca el paquete en la cola de transmisión 802.11e que se adecúe a la categoría de acceso WMM del nivel de prioridad 802.11e. PASO 3: DESDE EL CLIENTE AL PUNTO DE ACCESO Y DESPUÉS AL TÚNEL Cuando se envía un paquete desde el cliente al AP, el valor de prioridad 802.11e se mapea al valor DSCP correspondiente en el AP. Cuando el AP recibe una trama 802.11 desde un cliente WMM, el AP controla el valor de prioridad 802.11e parar asegurarse que el mismo no excede el valor máximo permitido por la política QoS asignada a ese cliente, y posteriormente mapea este valor al valor DSCP correcto.

Cuando el paquete va desde el AP al controlador, el AP traduce el valor DSCP basándose en el valor 802.11e entrante. El AP no envía paquetes etiquetados ya que haciendo eso causaría un problema a los switches Cisco que no están configurados como

troncales con el AP. Debido a que el AP no tiene un troncal, el mismo no copia el valor 802.11e a un paquete 802.11p. PASO 4: FUERA DEL TÚNEL A TRAVÉS DEL CONTROLADOR AL SWITCH ETHERNET El controlador usa el valor DSCP externo del paquete LWAPP para generar un valor de prioridad 802.11p en los paquetes, los cuales se envían al switch Ethernet por el controlador. Cuando el controlador recibe un paquete LWAPP, el controlador genera el valor de prioridad 802.11p para la red cableada usando el valor DSCP que encontró en el paquete.

6.1.7 Etiquetado de Paquetes Existen 2 situaciones a considerar: Paquetes etiquetados y no etiquetados:

- PAQUETES ETIQUETADOS: Son paquetes 802.1p o con marcas DSCP recibidos desde la LAN. o La etiqueta se propaga a la trama LWAPP. o Se puede aplicar AAA a clientes WLAN con IBNS.

- PAQUETES NO ETIQUETADOS: Paquetes no etiquetados recibidos desde la LAN, los cuales tienen el siguiente tratamiento:

o Se aplica el QoS WLAN configurado para la categoría de acceso.

CCNP ONT

101o Un servidor AAA puede ser aplicado a clientes WLAN con IBNS.

Los paquetes sin QoS recibidos desde la WLAN serán tratados con un servicio de mejor esfuerzo cuando se transmiten a través del controlador a la LAN.

6.1.8 Configuración QoS WLAN INTRODUCCIÓN A CISCO WCS (WIRELESS CONTROL SYSTEM) WCS es una herramienta de gestión que añade capacidades basadas en web y CLI, manejando desde controladores individuales a una red de controladores. WCS incluye la misma configuración, monitoreo,

seguridad y opciones de cuentas usadas a nivel de controlador y añade vistas gráficos de controladores múltiples y AP gestionados. En la figura se muestra una representación de una solución de red de Cisco Unified Wireless en la cual WCS es una parte integral de la misma. La interfaz de usuario WCS habilita operadores para controlar todas las configuraciones Cisco Unified Wireless, monitoreo y funciones de control, a través de Internet Explorer 6.0 o

superior. Los permisos de operador se definen por el administrador usando la interfaz de administración del WCS que habilita el control de cuentas de usuario y programa tareas de mantenimiento periódicas. PÉRFILES DE CONFIGURACIÓN QOS

En la figura se muestran las secciones de la página web desde donde podemos configurar una cantidad de ancho de banda para cada una de las 4 categorías de acceso. Cada “contrato” se divide a su vez en cantidad media y máxima de tráfico UDP o no UDP. Se recomienda usar el ancho de banda por defecto. En la misma web, podemos configurar “Over the Air QoS” que controla el uso de RF máximo para cada categoría de acceso WMM. Por defecto, estas

configuraciones se sitúan al 100%. La profundidad de la cola controla la profundidad de la cola interna para cada categoría de acceso respectiva. El mapeo desde 802.1p a categorías de acceso WMM puede también especificado a nivel de controlador. Los valores por defecto para categoría se muestran en la siguiente tabla (En la figura estamos en la tabla “bronze”):

CATEGORÍA DE ACCESO USO DE RF PROFUNDIDAD DE LA COLA PRIORIDAD 802.1P Platino 100% 100 6 Oro 100% 75 5 Plata 100% 50 3 Bronce 100% 25 1

CONFIGURAR IDS DE WLAN PARA QOS La política general WMM u 802.1p para la interacción de clientes wireless con el AP puede controlarse en el ID de WLAN del controlador wireless. Los 3 posibles valores se alistan y describen en la siguiente tabla:

VALOR DESCRIPCIÓN Disabled El parámetro disabled ignora la

solicitud WMM u 802.11e Allowed Este parámetro ofrece QoS a

clientes wireless habilitados para WMM u 802.11e y un QoS por defecto para clientes wireless sin WMM/802.11e.

Required Este parámetro requiere que todos los clientes wireless sean compatibles con WMM/802.11e.

CCNP ONT

102Nota: El WLAN ID es la asociación desde el SSID a un número interno único, el cual a su vez asocia políticas de seguridad y la interfaz Ethernet existente del controlador.

6.2 Introducción a la seguridad Wireless

6.2.1 La necesidad de seguridad WLAN Debido a que las WLAN usan ondas de radio, estas están abiertas a hackers que intenten acceder a información delicada o interferir en las operaciones de red. Como se vio en el CCNA, las técnicas de filtrado SSID y MAC resultaron insuficientes y débiles. CRACKEAR WEP La seguridad básica 802.11 WEP se diseñó para salvaguardar la red contra amenazas de dispositivos no autorizados fuera de la LAN. Con la WEP, la red considera a cualquier dispositivo que conozca la misma como legítimo y autorizado. WEP cifra el cuerpo de cada trama usando el algoritmo RC4, el cual opera expandiendo una pequeña clave en un stream de claves pseudo aleatorias. El emisor cifra los datos con la clave y el receptor usa una copia de la misma clave para descifrar los datos. Desafortunadamente, un hacker puede crakear cualquier WEP con softwares existentes en menos de 2 minutos. Aunque una clave WEP es mejor que nada, es una opción inadecuada. INICIACIÓN DE UN ATAQUE POR VECTOR Para evitar cifrar 2 textos cifrados con la misma clave, WEP usa una vector de inicialización (IV) que aumenta el la clave compartida secreta y produce una clave RC4 diferente para cada paquete. El IV se incluye en el paquete. Un IV pasivo o débil es otro tipo de ataque. El método de cambio de IV depende de la implementación del vendedor. (Cisco Aironet cambia el IV en una base por paquete). Si el IV se transmite en texto plano, un atacante que esnifa la red puede ver el mismo. Usando este IV repetidamente con la misma clave WEP, el hacker puede capturar tramas y derivar información de datos de la trama y datos desde la red. Se deben configurar timeouts de claves WEP en el servidor de autenticación para proveer protección extra. Esta práctica fuerza a los clientes wireless a reautenticarse, resultando en la generación de una nueva clave WEP.

6.2.2 WEP 802.11 La seguridad WLAN ha evolucionado considerablemente. Cuando la seguridad WLAN se introdujo en un primer momento, los dispositivos sólo soportaban cifrado WEP. En respuesta a las inquietudes del cliente, Cisco introdujo LEAP (Lightweight Extensible Authentication Protocol). LEAP es un protocolo propietario de Cisco que ofrece claves WEP dinámicas y autenticación mutua (entre un cliente wireless y un servidor RADIUS). LEAP permite a los clientes reautenticarse con frecuencia. LEAP hace más seguras a las WLAN, pero el cifrado que usa resultó ser no del todo seguro. Nuevos ataques prueban que se requieren mejoras. Un solución llamada WPA (Wi-Fi Protected Access) provee un cifrado estándar mejorado y una autenticación por usuario más sólida (PEAP, EAP y EAP-FAST). La solución WPA evolucionó a WPA2, el cual provee un cifrado más fuerte a través de AES (Advanced Encryption Standard). WPA2 incluye la autenticación 802.1x así como gestión de claves dinámicas. WPA2 de forma adicional incluye un sistema IDS, el cual identifica y protege contra ataques, incluyendo ataques DoS. Cisco incluye capacidades IPS a los puntos de acceso, los cuales sirven como sensores. WEP Aunque el centro de esta lección se centra en LEAP y WPA2, vale la pena empezar con un repaso a WEP:

- El estándar 802.11 define un tipo de seguridad en la cual 64 bits WEP especifican una clave secreta compartida para cifrar y descifrar datos. Originalmente, WEP usada una clave de 40 bits, la cual se concatena con un IV de 24 bits, para formar una clave de tráfico RC4. El gobierno de los EE.UU. exporta restricciones en la tecnología criptográfica inicial. Por ello, la mayoría de los fabricantes implementaron un protocolo WEP extendido de 128 bits usando una clave de 104 bits. Los AP Cisco Aironet soportan claves de 40 y 120 bits. Una vez que la clave WEP es revelada, un hacker puede transformar el texto cifrado en su valor original y entender el significado de los datos. Si se comprende el algoritmo, este hacker puede usar la clave WEP crakeada para modificar el texto cifrado y enviar el mensaje modificado al receptor.

- WEP usa un cliente wireless y un AP que comparten claves WEP estáticas. Esta clave se verifica durante el proceso de autenticación. Si la clave del cliente no coincide con la del AP, el cliente no tiene permitido asociarse al mismo y no puede conectarse a la red. Desafortunadamente, no existen mecanismos de renovar la clave WEP almacenada.

- WEP usa el algoritmo RC4, un strema de cifrado con vulnerabilidades conocidas. Ambos puntos finales deben compartir una clave.

La prestación de seguridad de Cisco Aironet mejoró algunas de las debilidades mencionadas usando una técnica de derivación de claves más segura y asignando claves WEP de forma dinámica:

- DERIVACIÓN DE CLAVES SEGURAS: Usando la clave compartida inicial, la derivación de clave segura construye respuestas a desafíos mutuos. Hace que los ataques por repetición sean imposibles. Los

CCNP ONT

103valores de hash enviados a través del cable son útiles para una sola vez en el proceso de autenticación inicial, y nunca después.

- CLAVES WEP DINÁMICAS: Cada cliente wireless puede tener garantizada una clave WEP nueva, dinámica cada vez que accede a la red. Estas claves están basadas en sesión, por lo que un intruso no puede aprender las mismas y usarlas para acceder a la WLAN. Las claves WEP usadas de esta forma se conocen como claves de sesión. Cada usuario tiene una única clave WEP. El AP tiene todas las WEP para cada cliente asociado, permitiendo comunicarse con cada uno de ellos. Los demás usuarios que reciben la información no pueden descifrar el contenido de la misma.

6.2.3 Seguridad WEP Cisco 802.11 mejorada CKIP (Cisco Key Integrity Protocol) protege la clave WEP de explotaciones que traten de encontrar la clave usando comparación de paquetes. CMIC (Cisco Message Integrity Check) es un mecanismo usado para proteger el sistema wireless de “ataques inductivos”, los cuales tratan de inducir al sistema a enviar datos de clave o respuestas predecibles que puedan ser analizadas para derivar la clave WEP. SEGURIDAD 802.11 MEJORADA Esta seguridad a través de WPA o WPA2 incorpora autenticación y cifrado mejorado al 802.11 básico. La autenticación en 802.11 desarrolla el estándar 802.1x del IEEE para autenticar usuarios y permitir asignación de políticas basándose en dicha autenticación. La autenticación 802.1x también permite credenciales flexibles para usarse en la autenticación del cliente. Contraseñas, tokens de una vez, certificados PKI, o IDs de dispositivo pueden ser usadas para la autenticación. El uso de 802.1x para la autenticación también tiene la ventaja de permitir claves de cifrado dinámicas para distribuir a cada usuario cada vez que este se autentica en la red. WPA Y WPA2 WPA resuelve debilidades de WEP y provee una forma de asegurar la integridad de los mensajes usando TKIP un cifrado de datos mejorado. Resuelve problemas como el ya publicado “AirSnort”, el cual es una herramienta que recupera claves de cifrado desde las cuales puede sacar la clave original. WPA2 se sobrepone a algunas debilidades encontradas en WPA. WPA2 usa el algoritmo AES, el cual es más seguro que RC4 usado por WPA, con la desventaja que hace un mayor uso de la CPU.

6.2.4 Vistazo a 802.1x BENEFICIOS DE LA AUTENTICACIÓN 802.1X Una de las ventajas mayores de EAP y del estándar 802.1x es que su diseño maximiza los estándares existentes. Con soporte EAP, las WLAN pueden ahora ofrecer las siguientes prestaciones:

- AUTENTICACIÓN DE CONTRASEÑA RFC 2284: Los usuarios son autenticados basados en un nombre de usuario y contraseña existente almacenados en un directorio activo de la red. Este directorio se conecta a un servidor certificado, como un RADIUS.

- OTP (ONE TIME PASSWORD): OTP cifra contraseñas en texto plano. Por tanto, las contraseñas en texto plano no tienen que escribirse en una conexión insegura (como Telnet o FTP).

PROTOCOLOS DE AUTENTICACIÓN 802.1X Y EAP La especificación 802.1x requiere autenticación mutua de cliente y servidor. Este proceso puede acompañarse a través de varios mecanismos, que veremos en los puntos siguientes (LEAP, EAP-FAST, EAP-TLS, PEAP).

Los componentes requeridos para una autenticación 802.1x son los mostrados en la figura.

6.2.5 LEAP LEAP provee algunas capacidades únicas que son difíciles de obtener con otros esquemas de autenticación, las cuales se indican a continuación:

- Roaming seguro y rápido con clientes Cisco y compatibles. - Un rango amplio de sistemas operativos y dispositivos, incluyendo Mac, Linux y DOS. - Login con un Directorio Activo o dominio NT usando credenciales de Microsoft.

Si se usa una base de datos Microsoft, y queremos usar el sistema operativo nativo para el soporte de la autenticación, podemos usar Microsoft PEAP (PEAP [EAP-MSCHAPv2]) o EAP-TLS. El login puede realizarse con estas soluciones. AUTENTICACIÓN LEAP Como vimos en el punto anterior, el proceso de autenticación requiere 3 componentes; el cliente (suplicante), el punto de acceso (autenticador) y el servidor RADIUS (servidor de autenticación). En la figura de la página siguiente se muestran los pasos del proceso de autenticación usando LEAP: * La autenticación puede comenzar de 2 formas: solicitada por el cliente (mensaje start) o por el punto de acceso (mensaje de solicitud de indentidad).

CCNP ONT

104* En ambos casos, el cliente responde al punto de acceso con un nombre de usuario. * El punto de acceso encapsula esta respuesta en un mensaje RADIUS “Access-request” y se lo envía al servidor RADIUS en cuestión. * El servidor RADIUS entonces comienza el proceso de respuesta de desafío con el cliente. * Tras comprobar que la autenticación es correcta, se envía un mensaje “success” al punto de acceso, indicando que el cliente ha sido autenticado. * El cliente necesita validar que el AP y el RADIUS con los que habla son de confianza. Este proceso es

la función de autenticación mutua LEAP. * El cliente envía un desafío al AP y este lo reenvía al RADIUS. * El RADIUS debe responder de forma correcta al mismo para validar la red. * Tras una autenticación satisfactoria, se genera una clave maestra por par (PKM) en ambos, cliente y servidor RADIUS. * El servidor RADIUS envía esta PKM al AP para que la instale para el cliente específico. El AP y el cliente realizan entonces finalmente un saludo de 4 vías.

6.2.6 EAP-FAST EAP-FAST consiste en una fase 0 opcional, seguida de las fases 1 y 2:

- FASE 0: Existente sólo en EAP-FAST, esta fase es un medio de túnel seguro que provee un cliente EAP-FAST con una PAC (Credencial de Acceso Protegido) para las solicitud de acceso a la red por parte del mismo. Esta fase es opcional, y las PACs pueden ser provistas de forma manual a clientes finales. Una PAC es una credencial digital que se distribuye a usuarios para la autenticación. Una PAC siempre consiste en una “parte secreta” y una “parte opaca”. La parte secreta es una clave secreta que puede usarse en transacciones posteriores. La clave opaca se presenta cuando el cliente quiere obtener acceso a los recursos de red. Esta parte ayuda al servidor a determinar si el cliente posee la parte secreta. Cada PAC tiene un ID de usuario específico y un ID de autoridad asociado a la misma.

- FASE 1: En la fase 1 el servidor RADIUS y el cliente usan la PAC para autenticarse mutuamente y establecer un túnel seguro. Como con PEAP, EAP-FAST usa TLS para verificar la identidad del servidor AAA y establecer un túnel seguro entre el cliente y el servidor AAA. La PAC reemplaza el certificado digital usado por PEAP y elimina la necesidad de una infraestructura PKI para gestionar los certificados.

- FASE 2: En esta fase, el servidor RADIUS autentica las credenciales de usuario con EAP-GTC, el cual se protege por el túnel TLS creado en la fase 1.

AUTENTICACIÓN EAP-FAST En la figura se muestran los pasos del proceso de autenticación usando EAP-FAST:

* El punto de acceso restringe todo el tráfico desde el cliente hasta que el mismo sea autenticado por el servidor RADIUS. * El cliente envía una trama EAPOL (EAP over LAN) al punto de acceso. * El AP devuelve una solicitud de identidad al cliente. * El cliente envía un NAI (Identificador de Acceso a la Red) en formato de dirección de correo al AP, el cual pasa el NAI al RADIUS. * El servidor RADIUS y el cliente se autentican mutuamente usando las fases 1 y 2 del proceso EAP-FAST.

CCNP ONT

105* El RADIUS envía una clave de sesión al AP en un paquete “success”. El RADIUS y el cliente negocian y derivan la clave de cifrado de sesión. Este proceso varía basándose en si el cliente está usando WEP u 802.11i (WPA). * El cliente y el AP usan las claves durante la sesión. * Al final de la sesión, el cliente envía un paquete EAPOL-Logout, y el AP vuelve al estado de pre-autenticación (filtrado todo excepto el tráfico EAPOL).

6.2.7 EAP-TLS TLS se usa en diferentes entornos, y se pretende que sea una versión alternativa estandarizada del mecanismo de cifrado SSL ampliamente extendido. EAP-TLS usa un código de mensaje de autenticación derivado de un certificado para autenticar a un usuario. Los certificados son expedidos a los usuarios y a las máquinas por una CA (Autoridad de Certificados) y se usan para validar identidades. El mantenimiento del CA (lo cual es parte de un PKI – Infraestructura de Clave Pública) puede ser una barrera para el despliegue EAP-TLS para algunos clientes. Todos los clientes (usuarios) deben tener su propio certificado personal expedido e instalado en sus máquinas para realizar autenticación TLS. Cada servidor AAA, a su vez, debe tener certificados únicos. EAP-TLS tiene soporte nativo en Windows 2000, XP y Vista. Con la implementación Cisco y Microsoft de EAP-TLS, se puede vincular las credenciales Microsoft de los usuarios con el certificado del usuario en una base de datos Microsoft, la cual permite un login de una vez en un dominio Microsoft. AUTENTICACIÓN EAP-TLS En la figura se muestran los pasos del proceso de autenticación usando EAP-TLS:

* El cliente wireless se asocia con el AP usando autenticación abierta. * El AP restringe todo el tráfico desde el cliente hasta que este haya sido autenticado por el RADIUS. * El cliente envía una trama EAPOL-start al AP. * El AP contesta con una solicitud de identidad. * El cliente envía un NAI (en formato de correo) al AP, el cual pasa la dirección al RADIUS. * El servidor y el cliente se autentican mutuamente usando un certificado digital externo.

* El RADIUS envía la clave de sesión al AP en un paquete Success. El RADIUS y el cliente negocian y derivan la clave de cifrado de sesión. Este proceso varía basándose en si el cliente usa WEP u 802.11i. * El cliente y el AP usan las claves durante la sesión. * Al final de la sesión, el cliente envía un paquete EAPOL-Logout, y el AP vuelve al estado de pre-autenticación (filtrado todo excepto el tráfico EAPOL).

6.2.8 PEAP PEAP es un protocolo de autenticación que fue propuesto en común por Cisco, Microsoft y RSA Security. Su propósito es proteger las transacciones de autenticación con una conexión TLS segura, tanto como si aseguráramos una conexión a un sitio web con e-commerce cuando se realiza una transacción online. Existen 2 implementaciones de PEAP: PEAP-GTC // PEAP MSCHAPv2. PEAP-GTC permite una autenticación genérica a un número de bases de datos (NDS, LDAP, OTP, etc.). PEAP-MSCHAPv2 permite la autenticación a bases de datos que soporten el forma MSCHAPv2, incluyendo Microsoft NT y Microsoft Active Directory. Un certificado debe utilizarse en cada cliente para autenticar al servidor en cada cliente antes de que el cliente aporte sus credenciales de autenticación. En la figura de la página siguiente se muestran los pasos del proceso de autenticación usando PEAP:

CCNP ONT

106* El cliente wireless se asocia con el AP usando autenticación abierta. * El AP restringe todo el tráfico desde el cliente hasta que el mismo se autentique contra el RADIUS. * El saludo inicial entre el cliente y el AP es un handshake TLS, como se vio anteriormente. * El cliente autentica al servidor usando un CA para verificar el certificado digital del mismo. Entonces, el cliente y el servidor establecen un túnel cifrado. * El cliente le da sus credenciales dentro de este

túnel usando MSCHAPv2 o GTC. * El RADIUS envía la clave de sesión al AP en un paquete Success. El RADIUS y el cliente negocian y derivan una clave de sesión de cifrado. Este proceso varía basándose en si el cliente usa WEP u 802.11i. * El cliente y el AP usan las mismas claves durante la sesión. * Al final de la sesión, el cliente envía un paquete EAPOL-logout, y el AP vuelve al estado de pre-autenticación.

6.2.9 Acceso Protegido Wi-Fi CARACTERÍSTICAS WPA COMPONENTES DE WPA WPA es un estándar que describe una combinación de habilidades de seguridad. Estas habilidades estaban disponibles antes de que WPA llegara a ser un estándar de la industria, pero WPA coloca a todas dentro de una única definición. La siguiente lista muestra los aspectos más importantes de WPA:

- Gestión de Claves Autenticadas: Ya sea usando la autenticación 802.1x o claves pre-compartidas, el usuario se autentica antes autenticar a las claves que se utilicen.

- Gestión de claves unicast y Broadcast: Las claves que se derivan después de la autenticación de usuarios se autentican a través de un handshake entre el AP y el cliente.

- TKIP (claves por paquete) y MIC. - Expansión del espacio de IV: El espacio IV se expande de 24 bits (el que venía con WEP) a 48

bits en WPA. - Modo de Migración WPA: Cisco define este modo como una configuración de AP para habilitar a

clientes WPA y no WPA a asociarse al punto de acceso usando el mismo SSID. VISTAZO A LA AUTENTICACIÓN 802.11I O WPA Y GESTIÓN DE CLAVES

La autenticación inicial usando WPA es esencialmente idéntica a la autenticación y asociación estándar usada en 802.11. La diferencia primordial en WPA está en la solicitud de asociación inicial (probe request) que el cliente y el AP envían. El cliente y el AP deben estar de acuerdo en la opción de seguridad durante la asociación. Después de la asociación inicial y el intercambio de opciones de seguridad, el cliente y el servidor de autenticación proceden con la autenticación 802.11x.

Después de una autenticación satisfactoria, el servidor deriva y distribuye una clave maestra al AP. Esta misma clave se deriva al cliente. Con estas claves maestras, el AP y el cliente realizan un handshake de 4 vías para validar al AP, y el cliente valida la clave de broadcast o de grupo usando un handshake de 2 vías. CLAVES UNICAST: HANDSHAKE DE 4 VÍAS Antes de producirse el handshake WPA, el par de claves maestras (PMK), una clave de 256 bits, se genera debido al proceso de autenticación 802.1x entre el cliente y el servidor de autenticación.

- Paso 1: El AP envía un número aleatorio al cliente. - Paso 2: El cliente responde al AP con el número aleatorio del cliente, junto con elementos de

información WPA, el par de claves fugaces (PTK) e información de clave MIC.

CCNP ONT

107- Paso 3: El AP envía el “nonce” (número generado aleatoriamente para la ocasión) de nuevo, junto

con elementos de información WPA, PTK y información de clave MIC, e instala el mensaje. El reenvío de esta información valida al cliente, y el AP comparte información de autenticación común con él.

- Paso 4: El cliente envía la información de clave MIC y el PTK al AP para un acuse de recibo. HANDSHAKE DE GRUPO La clave maestra de grupo (GMK) es generada a su vez utilizando una función de número aleatorio o se inicializa por el primer PTK que el AP usa. Cuando el AP tiene el GMS, un número de grupo aleatorio se genera. Este número se usa para derivar una clave de grupo fugaz (GTK). Las entradas son un PRF que usa el número aleatorio y la dirección del AP. El GTK se usa para proveer un grupo de claves como claves MIC, las cuales pueden usarse para verificar la integridad de la clave de los paquetes. FASES DE GESTIÓN DE CLAVE WPA Como parte de la conformidad con WPA, un AP debe ser capaz de advertir capacidades de seguridad en los beacons que envía. Este proceso describe los tipos de autenticación unicast, multicast y broadcast que son soportados. Desde las capacidades advertidas por el AP, el cliente selecciona el tipo de seguridad “mejor” soportado para la autenticación. Cuando el cliente determina el tipo de autenticación, procede con la autenticación abierta usando 802.1x a un RADIUS, o usando una clave pre-compartida con el AP. Este proceso tiene la ventaja de una autenticación mutua entre cliente y servidor, así como la tenencia de un recurso centralizado para el control de admisión del cliente. Tras completar los mensajes EAP entre el cliente y el servidor, una clave maestra se genera de forma independiente entre el servidor y el cliente. Esta clave se usa para derivar una PTK que se usa en la autenticación de los componentes de la clave cifrada que el AP y el cliente usarán uno con el otro.

6.2.10 Tareas WPA El protocolo TKIP usado por WPA es una mejora del mecanismo RC4 usado por web. TKIP es un “envoltorio” alrededor de los mecanismos WEP y RC4. WPA cuenta con RC4, en lugar de 3DES, AES, u otro algoritmo de cifrado. WPA requiere que las tarjeas incluyan el protocolo en sus drivers. A su vez requiere soporte del S.O. o un cliente suplicante. Algunos vendedores no mezclan WPA y WEP. El despliegue EAP puede ser en ocasiones un desafío importante, dado la gran cantidad de variantes de las que dispone, cada una con sus particularidades específicas. EAP a su vez requiere del uso de un servidor RADIUS externo para autenticar a los usuarios wireless. Para mantener la compatibilidad de hardware retrospectiva, MIC se diseño para inducir muy poca carga de computación. Como resultado, MIC ofrece sólo 20 bits de seguridad efectiva. WPA es susceptible a nuevos tipos de ataques DoS basados en técnicas de contramedidas que emplea MIC. Si un AP que ejecuta WPA recibe 2 paquetes sucesivos rápidamente con MICs erróneos, el AP desactiva el BSS por completo durante 1 minuto. WPA es susceptible a vulnerabilidades descubiertas recientemente cuando se usa claves pre-compartidas en lugar de 802.11i o EAP. Estos problemas, conducen al estándar 802.11i (WPA2), el cual añade 3 prestaciones: autenticación con 802.1x, cifrado con AES y gestión de claves. VISTAZO A WPA2 WPA2 soporta TKIP y generalmente usa bloques de cifrado AES con CCMP (Cipher Block Chaining Message Authentication Code Protocol) para el cifrado.

- Generalmente usa 802.1x como método de autenticación, aunque soporta claves pre-compartidas. - Es comparable a WPA (misma arquitectura de autenticación, distribución de claves y renovación de

claves). - Soporta PKC (Proactive Key Caching) y pre-autenticación. - Se añaden sistemas IDS para identificar y protegerse contra ataques.

IDSS WIRELESS Los IDS cableados se centran en la capa 3 y superiores, pero la naturaleza del medio y los estándares wireless obligan a los IDS a funcionar en las capas física y enlace de datos. El medio RF tiene varias vulnerabilidades, como es el espectro sin licencia, el cual está sujeto a interferencias y no se contiene por límites de seguridad físicos. Como vulnerabilidades estándar se incluyen tramas de gestión no autenticadas, secuestros de sesión y ataques de repetición. La protección IDS incluye detección de falsificadores y mapeo de localizaciones, firmas de ataques IDS, exclusión de clientes y contención y una seguimiento de localización de alta resolución. Cisco ofrece opciones IPS basándose en la selección de arquitectura:

- WLAN basada en controlador. - AP autónomos. - AP autónomos con integración de partner.

MODOS WPA Y WPA2 WPA tiene 2 modos: empresarial y personal. Ambos proveen soporte de cifrado y autenticación de usuario. WPA provee autenticación usando 802.1x y claves pre-compartidas (se recomienda siempre usar

CCNP ONT

108802.1x para despliegues empresariales). WPA también provee cifrado usando TKIP. TKIP incluye MIC y claves por paquete a través de hashear IVs y rotar las claves broadcast. La autenticación WPA2 es idéntica a la WPA, excepto que el cifrado usado por WPA2 es AES-CCMP.

- MODO EMPRESARIAL: Se refiere a productos que se han testeado para ser interoperables con claves pre-compartidas y modos de operación 802.1x o EAP para la autenticación.

- MODO PERSONAL: Este modo es un término dado a productos testeados para ser interoperables con el modo de clave pre-compartida únicamente para la autenticación.

TAREAS WPA2 El uso de AES como método de cifrado requiere una mayor potencia de computación, y el hardware debe soportar WPA2. El suplicante (cliente) debe tener un driver WPA2 que soporte EAP. Este estándar no está implementado de forma general y puede ser una limitación. El RADIUS debe también comprender EAP. No todos los RADIUS lo soportan. PEAP porta tipos de EAP dentro de un canal TLS seguro. Cuando TLS se usa, se utiliza un servidor de certificados. Esta prestación permite claves dinámicas. Comparado con WPA, WPA2 hace un uso intensivo de la CPU. Algunos AP antiguos nunca soportarán WPA2 debido a que no disponen de actualizaciones de hardware.

6.3 Gestión de WLANs

6.3.1 Red Cisco Unified Wireless La red Cisco Unified Wireless es una red de extremo a extremo cableada e inalámbrica que dirige de forma

efectiva los costos de seguridad WLAN, despliegue, gestión y tareas de control. Cómo se muestra en la figura, la red Cisco Unified Wireless se compone de 5 elementos interconectados que trabajan conjuntamente como “building blocks” para entregar una solución wireless de clase empresarial unificada. DISPOSITIVOS CLIENTE: Cisco está guiando el desarrollo de dispositivos cliente interoperables, basados en estándares a través del programa de extensiones compatibles con Cisco. Este programa ayuda a asegurar la disponibilidad de dispositivos wireless desde una gran variedad de proveedores que son compatibles con la infraestructura WLAN de Cisco. PLATAFORMA DE MOVILIDAD: Los AP Aironet proveen acceso omnipresente a la red para una gran variedad de entornos wireless cerrados y abiertos, incluyendo mayas wireless. La solución de Cisco soporta una amplia selección de opciones de despliegue, como radios simples o duales, antenas integradas o remotas, etc… UNIFICACIÓN DE RED: La red Cisco Unified Wireless incluye una forma de migración dentro de todas las plataformas Cisco de switches y routers a través de controladores WLAN. Estos controladores son los responsables de las funciones WLAN.

GESTIÓN DE RED EXCELENTE: La red Cisco Unified Wireless entrega el mismo nivel de seguridad, escalabilidad, confiabilidad, facilidad de despliegue y gestión de WLANs que las organizaciones esperan de sus LAN cableadas. Cisco WCS (Wireless Control System) brinda facilidad en la gestión de la WLAN. Permite a los administradores diseñar, controlar y monitorear la red wireless empresarial desde una localización central, simplificando las operaciones. SERVICIOS UNIFICADOS AVANZADOS: Las soluciones Cisco soportan las siguientes prestaciones:

- Prestaciones avanzadas, como VoIP wireless y VoIP futura unificada móvil. - Tecnologías emergentes, como servicios de localización para aplicaciones críticas, seguimiento de

recursos de alto valor, gestión de IT y seguridad basada en localización. - Prestaciones de seguridad wireless avanzadas, como NAC, red “Self-defending”, IBNS, IDSs y acceso

a invitados. COMPONENTES DE UNA RED CISCO UNIFIED WIRELESS DISPOSITIVOS CLIENTE: Cisco recomienda encarecidamente usar dispositivos clientes compatibles con Cisco o clientes Aironet para la red Cisco Unificada. Con un 90% aproximadamente de dispositivos cliente certificados como compatibles con Cisco, la mayoría de los dispositivos que seleccionemos tiene muchas probabilidades de ser compatible. Estos dispositivos interoperan y soportan prestaciones innovadoras y únicas de la red Cisco Unified Wireless, como roaming seguro rápido, IPS integrado, servicios de localización y una variedad amplia de servicios de autenticación extensible. PLATAFORMA DE MOVILIDAD: Los puntos de acceso Aironet Lightweight se configuran dinámicamente y se gestión a través del protocolo LWAPP. A su vez, se pueden convertir AP autónomos para operar como APs lightweigth que ejecuta LWAPP.

CCNP ONT

109UNIFICACIÓN DE RED: La red Cisco Unified Wireless maximiza la red cableada existente y la inversión en productos Cisco. Esta solución soporta una infraestructura de red sin cortes a lo largo de un amplio rango de plataformas. La unificación wireless y cableada ocurre en los controladores WLAN de la serie 440 y 2000. GESTIÓN DE RED EXCELENTE: Cisco entrega un sistema de

gestión de red excelente (NMS) que visualiza y ayuda a asegurar el espacio aéreo. WCS soporta planeamientos y diseños WLAN, seguimiento de localizaciones, IPS y configuración, monitoreo y gestión de sistemas WLAN. Esta plataforma gestiona de forma sencilla múltiples controladores y sus puntos de acceso ligthweight asociados. SERVICIOS AVANZADOS UNIFICADOS: Estos servicios son entregados por puntos de acceso Lightweight, dispositivos de localización Wireless y teléfonos wireless IP. Dan soporte a aplicaciones de extremo maximizadas.

6.3.2 Componentes e implementación de WLAN Cisco Cisco ofrece 2 implementaciones WLAN, como se muestra en la figura:

- WLAN AUTÓNOMA: Usando un único punto de acceso. - WLAN LIGHWEIGTH: Usando varios puntos de acceso y controladores WLAN.

Los componentes WLAN disponibles son los siguientes: - Clientes wireless conectados a la red (notebooks, teléfonos IP, etc…) - Puntos de acceso autónomos configurados de forma independiente o puntos de acceso Lightweight

configurados a través de controladores LAN. - Monitoreo y control de radio con:

o Puntos de acceso autónomos que agregación información a través de un WDS (Servicios de dominio Wireless) que envía dicha información a un WLSE (CiscoWorks Wireless LAN Solution Engine).

o Puntos de acceso Lightweight que usan encapsulación LWAPP para enviar información independientemente a los controladores WLAN.

- La gestión WLAN gestiona y monitorea largos despliegues WLAN de la siguiente forma: o Los puntos de acceso autónomos usan WLSE para la gestión. o Los puntos de acceso Lightweight usan la gestión WCS.

- La infraestructura de red incluye routers y switches con puntos de acceso conectados, controladores y servidores.

- Los puentes aironet operan en la capa de enlace de datos. COMPARACIÓN DE SOLUCIONES WLAN

- PUNTOS DE ACCESO AUTÓNOMOS: Los puntos de acceso autónomos se configuran por punto de acceso. CiscoWorks WLSE realiza configuraciones, monitoreo y gestión centralizados. WDS facilita el monitoreo de radio y la gestión de comunicación entre el AP y CiscoWorks. WDS es una prestación que está habilitada en cualquier AP que envía información RF desde un grupo de APs a un WLSE.

- PUNTOS DE ACCESO LIGHTWEIGHT: Configuramos AP lightweigth usando el controlador WLAN. El AP normalmente depende del controlador para el control y la transmisión de los datos. El controlador implementa monitoreo y seguridad. Se puede realizar una configuración, gestión y monitoreo centralizados desde un WCS (Wireless Controller System). Pueden instalarse controladores redundantes dentro de grupos de controladores WLAN.

6.3.3 CiscoWorks WLSE para la solución WLAN autónoma WLSE es una solución a nivel de sistema para gestionar la infraestructura entera WLAN Aironet basada en puntos de acceso autónomos. Las prestaciones de gestión RF y de gestión del dispositivo simplifican la operación cotidiana de las WLAN, ayudando a asegurar un despliegue sin complicaciones de seguridad y disponibilidad de red mientras se reduce los gastos de despliegue y los gastos operativos. WLSE opera atesorando defectos, rendimientos e información de configuración de dispositivos Cisco que descubre en la red. Debemos configurar los AP, WDS, switches y routers con CDP y SNMP para proveer información al WLSE para el proceso de descubrimiento de APs. Una vez que WLSE descubre dispositivos, decidiremos que dispositivos gestionar con WLSE. WLSE es un componente núcleo de una solución de AP autónomo.

CCNP ONT

110WLSE tiene las siguientes prestaciones principales:

- CONFIGURACIÓN: Permite aplicar cambios de configuración a puntos de acceso. Se pueden soportar hasta 2500 AP desde una única consola WLSE. Todos los AP Aironet son soportados.

- MONITOREO DE DEFECTOS Y POLÍTICAS: Se monitorean defectos y condiciones de funcionamiento en los dispositivos, respuestas LEAP y desconfiguraciones de políticas.

- REPORTES: Permite hacer seguimiento de dispositivos, clientes e información de seguridad. Podemos mandar los mismos por correo, imprimirlos y exportarlos.

- FIRMWARE: Permite actualizar el firmware de los AP y puentes. - GESTIÓN DE RADIO: Ayuda a gestionar el entorno de radio WLAN. - ADMINISTRACIÓN WLSE: Gestiona el software WLSE, incluyendo actualizaciones, monitoreo de WLSE,

copia de seguridad de los datos, y usando 2 dispositivos WLSE como redundantes, se provee como una solución de gestión de alta disponibilidad.

BENEFICIOS CLAVE DE WLSE Usar WLSE para gestionar AP autónomos provee muchos beneficios. WLSE provee gestión centralizada y visibilidad RF para APs autónomos Aironet y puentes. Esta solución le da al usuario muchos beneficios, de los que se resaltan los siguientes:

- SEGURIDAD WLAN MEJORADA: IDSs Wireless para puntos de acceso fakes, redes ad hoc, gestión de tramas 802.11 excesivas que señalan a un ataque DoS y ataques de hombre en el medio.

- DESPLIEGUE SIMPLIFICADO DE PUNTOS DE ACCESO: Políticas de configuración que se crean usando asistentes de despliegue que se aplican automáticamente a los nuevos puntos de acceso.

- VISIBILIDAD RF: Cobertura RF, pantalla de potencia de señal recibida (RSSI), localización de puntos de acceso fakes y límites de roaming.

- GESTIÓN DINÁMICA DE RF: “Auto-curación”, detección de interferencias y seguimiento de puntos de acceso para clientes.

- OPERACIONES SIMPLIFICADAS: Configuraciones basadas en plantillas y actualizaciones de imágenes y monitoreo basado en umbrales.

En la imagen de la figura se muestra uno de los muchos usos de WLSE. El ejemplo ilustra el escaneo y monitoreo de capacidades mostrando las localizaciones y la cobertura de los puntos de acceso aironet en un plano de planta del edificio.

CISCOWORKS WLSE Y WSLE EXPRESS WLSE se usa para una gestión centralizada de la red wireless que usa APs autónomos. WLSE soporta los siguientes dispositivos WLAN:

- AP y puentes aironet. - Módulos WLSM (Wireless LAN Service Module) WDS en switches Catalyst 6500.

WLSE soporta SSH, HTTP, CDP y SNMP. Existen dos versiones de WLSE. Cada una de ellas cumple las necesidades de diferentes tamaños y topologías de red.

CISCOWORKS WLSE: Soporta hasta 2500 dispositivos WLAN. CISCOWORKS WLSE EXPRESS: Para pequeños negocios, soportando de 250 a 1500 empleados (o hasta 100 dispositivos WLAN).

WLSE requiere un servidor AAA externo, el cual ya viene incluido con WLSE Express. WLSE Express tiene integrada seguridad WLAN y servicios de gestión que soportan 802.1x LEAP, PEAP, EAP-FAST y EAP-TLS. El directorio de usuarios soporta LDAP (Lightweigth Directory Access Protocol) con el Directorio Activo de Microsoft y la base de datos de usuario local. WLSE Express soporta autenticación de usuario cableada e inalámbrica y prestaciones de IDS WLAN.

CCNP ONT

111

6.3.4 Configuración simplificada de CiscoWorks WLSE Express Disponemos de dos modos de configuración inicial de WLSE Express:

- AUTOMÁTICO: Después de instalar WLSE Express, podemos ordenar al WLSE que sea auto-configurado. Cuando el WLSE se inicia por primera vez, se descarga un fichero de configuración especial de forma automática, dejando al WLSE listo para su uso. La configuración se descarga desde un DHCP. La opción DHCP está habilitada por defecto. La IP de un TFTP y un nombre de fichero se proveen en las opciones 66 y 67 del DHCP. WLSE descarga una configuración del TFTP, incluyendo nombre de host, puerta de enlace, etc…

- MANUAL: Por defecto, la interfaz Ethernet del WLSE Express se configura a un modo DHCP. Cuando lo iniciamos, WLSE intenta obtener la configuración de red desde un DHCP, como indicamos en el punto anterior. Si no queremos usar DHCP, podemos logarnos y configurar los parámetros de red manualmente tras el arranque del WLSE, usando la CLI.

PLANTILLAS DE CONFIGURACIÓN WLSE tiene una GUI basada en web para la configuración. WLSE está diseñado para operaciones rutinarias así como para la optimización del funcionamiento y alta disponibilidad. Una de las prestaciones de WLSE es el uso de plantillas, las cuales permiten la auto-configuraicones de nuevos puntos de acceso para simplificar un despliegue de puntos de acceso a gran escala. Cuando se añade un nuevo AP al sistema, podemos usar la plantilla para configurar al mismo. A su vez, los AP nuevos añadidos al sistema requieren correcciones en la configuración. WLSE detecta desconfiguraicones y envía una alerta de las mismas. Este proceso también es el proceso que lleva a cabo WLSE para detectar un AP fake y minimizar las vulnerabilidades de seguridad. WLSE puede detectar el AP que falla, pudiendo compensar su pérdida incrementando automáticamente la potencia y cobertura de celda de los puntos de acceso más cercanos. La prestación de “Auto-Curación” minimiza el impacto de un fallo del tipo mencionado anteriormente. La “Auto-Curación” también recalcula la potencia de cobertura cuando el AP vuelve a estar disponible.

6.3.5 Cisco WCS para la solución LWLAN WCS (Wireless Control System) es una solución WLAN de Cisco, en forma de herramienta de gestión de red, que permite mover controladores individuales a una red de controladores. WCS incluye la misma configuración, monitoreo de funcionamiento, seguridad, gestión de errores y opciones de cuentas que se usan a nivel de controlador y añade una vista gráfica de los múltiples controladores y puntos de acceso gestionados. En la figura se muestra una representación de la funcionalidad completa de WCS.

WCS se ejecuta en plataformas Windows y Linux. WCS puede ejecutarse como aplicación o como servicio, el cual se ejecuta continuamente. La interfaz de usuario WCS permite a los operadores controlar todas las configuraciones de soluciones WLAN, monitorearlas, y controlar funciones a través de Internet Explorer 6.0 o posterior. Se pueden

CCNP ONT

112definir permisos de operador a través del menú administrador de la interfaz de usuario WCS. Desde este menú se pueden definir cuentas de usuario y programar tareas de mantenimiento periódicas. WCS usa SNMP para comunicarse con los controladores. WCS soporta SNMPv1, SNMPv2 y SNMPv3. El software WCS es una plataforma líder en la industria de planeamiento, configuración y gestión de WLAN. Provee una base sólida que los gestores de IT pueden usar para diseñar, controlar y monitorear la red wireless empresarial reduciendo el costo total. Cisco provee una amplia gama de opciones para realizar de forma eficiente el seguimiento de dispositivos wireless, incluyendo portátiles Wi-Fi, PDAa, teléfonos móviles, etc… que estén equipados con transceptores 802.11. Podemos deplegar ECS en cualquiera de las siguientes 3 versiones:

- WCS BASE: Esta versión puede determinar a qué punto de acceso está asociado un dispositivo wireless, dando a los gestores de IT una aproximación genera de donde se sitúan los dispositivos inalámbricos.

- LOCALIZACIÓN WCS: En entornos que requieren servicios de localización granulares se puede implementar una versión opcional de WCS, llamada Cisco WCS Location que usa tecnología de “huella dactilar” RF patentada por Cisco. Esta tecnología compara información RSSI en tiempo real del cliente con características de la arquitectura RF, haciendo posible localizar a un dispositivo wireless de forma correcta dentro de un pequeño rango de metros.

- DISPOSITIVO DE LOCALIZACIÓN WIRELESS: Además, Cisco WCS Location puede ser desplegado en conjunto con un dispositivo que puede hacer seguimiento de miles de clientes wireless en tiempo real, de forma simultánea.

6.3.6 Prestaciones del software WCS El sistema operativo WCS gestiona todos los datos de cliente, comunicaciones, funciones de administración del sistema, funciones de gestión de recursos de radio (RRM), políticas de movilidad, y coordinación de todas las funciones de seguridad usando un marco base. PRESTACIONES DE CISCO WCS BASE WCS Base soporta acceso de datos de clientes inalámbricos, detección de puntos de acceso fakes y funciones de contención (como localización en tiempo real de AP fakes a puntos de acceso cercanos y localización histórica de clientes a puntos de acceso cercanos), así como soluciones de control y monitoreo de la WLAN. El software WCS incluye vistas gráficas de elementos como:

- Auto descubrimiento de puntos de acceso así como de puntos de acceso asociados con controladores.

- Auto descubrimiento y contención de puntos de acceso falsos. - Organización basada en mapas de áreas de cobertura de puntos de acceso, lo cual es útil cuando la

empresa se expande más allá de un área geográfica. - Gráficos provistos por el usuario de campus, edificios y planos de planta, donde se puede ver la

siguiente información: o Localización y estado de los AP gestionados. o Localización de puntos de acceso fakes basados en la señal recibida por los AP más

cercanos a los mismos. o Información de alarma de lugares sin cobertura basada en la información recibida por

los clientes. o Mapas de cobertura RF.

El WCS Base también provee un amplio control del sistema, con las siguientes funciones: - Configuración usando plantillas definidas por el cliente para controladores y puntos de acceso: - Estado y alarmas de monitoreo de red, controladores y puntos de acceso gestionados. - Monitoreo automático y manual de datos de cliente y funciones de control. - Monitoreo automático de puntos de acceso fakes, huecos de cobertura, violaciones de seguridad,

controladores y puntos de acceso. - Logs completos de eventos de datos de cliente, puntos de acceso fakes, huecos de cobertura,

violaciones de seguridad, controladores y puntos de acceso. - Canales automáticos y asignación de niveles de potencia por RRM. - Auditorias de estado automáticas definidas por el usuario, backups de configuración…

PRESTACIONES DEL SOFTWARE WCS LOCATION WCS Location incluye todas las prestaciones de WCS Base más las siguientes mejoras:

- Localización bajo demanda de puntos de acceso fakes dentro de 10 metros. - Localización bajo demanda de clientes dentro de 10 metros. - Habilidad de uso de dispositivos de localización para recolectar y devolver localización histórica de

datos y que podemos ver en la interfaz de usuario del WCS. Los dispositivos WCS Location pueden realizar cómputos de localización basados en la información RSSI que reciben desde los controladores WLAN. Estos controladores han de estar asociados al dispositivo WCS Location. Podemos usar los dispositivos de la serie 2710 Series Location Appliance para estos fines. DESPLIEGUE WCS La solución WLAN consiste en controladores WLAN y sus puntos de acceso lightweight asociados, controlados por el sistema operativo, todos de forma concurrente gestionados por cualquiera de las interfaces de usuario del sistema operativo. Existen las siguientes interfaces de usuario:

CCNP ONT

113- Una interfaz web de usuario HTTPS guardada en los controladores WLAN puede utilizarse para

configurar y monitorear controladores individuales. - Una CLI puede usarse para configurar y monitorear controladores individuales. - WCS puede usarse para configurar y monitorear uno o más controladores y sus puntos de acceso

asociados. WCS tiene herramientas que facilitan el monitoreo y el control de sistemas grandes. - Una interfaz estándar de la industria (SNMPv1, SNMPv2, SNMPv3) puede usarse con sistemas de

gestión de terceras partes compatibles con SNMP. REQUISITOS MÍNIMOS DEL CLIENTE PARA WCS WCS se ejecuta bajo servidores Windows 2000, Windows 2003 y Red Hat Enterprise Linux v.3 como una aplicación normal o como un servicio. Los requisitos mínimos del servidor son:

- Windows 2000 SP4 o superior. Windows 2003 SP1 o superior, o Red Hat Enterprise Linux ES v.3. - Hasta 500 puntos de acceso: Pentium 2.4 GHz con 1 GB de RAM. - Más de 500 puntos de acceso: Doble núcleo (de al menos 2.4 GHz cada uno) con un mínimo de 2 GB

de RAM. - 20 GB de disco duro.

Los requisitos mínimos del cliente son Internet Explorer 6.0 con SP1 o superior.

6.3.7 Interfaz de usuario WCS La interfaz de usuario WCS permite al operador de red crear y configurar plantillas de área de cobertura, parámetros de operación del sistema, monitorear el funcionamiento de la WLAN en tiempo real, y realizar tareas de solución de problemas usando un navegador. Esta interfaz también permite al administrador crear, modificar y borrar cuentas de usuario, cambiar contraseñas, asignar permisos y programar tareas de mantenimiento periódicas. BARRA DE MENÚ Existen 4 menús en cada pantalla. Cuando movemos el ratón sobre cualquiera de los menús, aparece un menú desplegable:

- MONITOR: El menú monitor provee una descripción de los dispositivos de nuestra red. - CONFIGURE: Este menú permite configurar plantillas, controladores y puntos de acceso de la red. - LOCATION: Este menú permite configurar dispositivos Wireless Location. - ADMINISTRATION: Este menú permite programar tareas como backups, chequeos de estado de

dispositivos, auditorías de red, sincronización de servidores Location, etc. EJEMPLO: PÁGINA DEL CONTROLADOR WCS El WCS está diseñado para soportar 50 controladores WLAN y 1500 puntos de acceso. Desde la página que se muestra en la página siguiente se provee acceso a detalles sumarizados del controlador. Usamos el área de selección para acceder a los detalles de los controladores respectivos. En la figura de la página siguiente se muestra un ejemplo de esta página. El área de datos de esta pantalla contiene una tabla con la siguiente información:

- IP ADDRESS: Dirección IP local de la interfaz de gestión del controlador. - NOMBRE DEL CONTROLADOR - LOCATION: La localización geográfica (como un campus o un edificio). - NOMBRE DEL GRUPO DE MOBILIDAD: Nombre del controlador de movilidad o del grupo WPS. - ESTADO DE DISPONIBILIDAD: Como alcanzable o inalcanzable.

CCNP ONT

114

6.3.9 Dispositivo Cisco Wireless Location VISTAZO AL DISPOSITIVO CISCO WIRELESS LOCATION La aplicación Wireless Location es una solución innovadora, fácil de desplegar que usa tecnología de “huella dactilar” RF avanzada para realizar el seguimiento de miles de dispositivos 802.11 simultáneamente desde directamente la infraestructura WLAN, incrementando la visibilidad de los recursos y el control del espacio aéreo.

En la figura se muestra un dispositivo Cisco 2710 Wireless Location. Este dispositivo tiene un WCS incluido dentro del mismo, que recolecta y almacena un historial de datos de localización de hasta 1500 portátiles cliente, agendas electrónicas,

teléfonos VoIP, puntos de acceso fakes, etc… De forma adicional, el dispositivo provee alertas basadas en localización para refuerzo de la política, y graba un histórico de información importante que puede usarse para resolver problemas rápidamente, y gestionar la capacidad RF. Como un componente de la red Wireless Unificada de Cisco, este dispositivo usa controladores WLAN y puntos de acceso lightweigh Aironet para realizar el seguimiento de localizaciones físicas de dispositivos wireless dentro de unos pocos metros. ARQUITECTURA CON DISPOSITIVOS CISCO WIRELESS LOCATION

Un dispositivo 2710 actúa como un servidor de uno o más dispositivos WCS, recolectando, almacenando y pasando datos desde el dispositivo (2710) a los controladores. Los puntos de acceso recogen información desde todos los dispositivos Wi-Fi (mediante RSSI), incluyendo portátiles, teléfonos, puntos de acceso fakes, etc… La información RSSI obtenida se envía a través del protocolo LWAPP a los controladores WLAN o a ciertos routers o switches con capacidades wireless integradas. Los controladores agregan dicha información RSSI y se la envían a la aplicación 2710 utilizando el protocolo SNMP.

Los controladores WLAN almacenan la información RSSI deben estar asociados con los dispositivos Wireless Location. Una vez que se añaden los mapas de la red y se añaden los puntos de acceso al dispositivo, las predicciones RF y los mapas de “calor” pueden generarse para mostrar la localización de miles de

CCNP ONT

115dispositivos en el plano de planta del sitio de forma geográfica. Esta información de localización también está disponible con aplicaciones de terceros a través de Apis XML en el dispositivo. El WCS gestiona el dispositivo Wireless Location mediante una GUI intuitiva y visual que provee una gestión y configuración centralizada. Para una mayor escalabilidad, el WCS puede gestionar uno o más dispositivos Wireless Location.

6.4 Desplegando Cisco WCS

6.4.1 Ejemplo de configuración del WCS LOGIN EN EL SERVIDOR WCS Completaremos los siguientes pasos en el servidor WCS:

- PASO 1: Ejecutamos Microsoft I.E. versión 6.0 o superior. - PASO 2: En la barra de dirección del navegador, ingresamos https://localhost cuando estemos

directamente en la estación servidora del WCS. Ingresaremos https://IP-del-wcs cuando estemos en otra estación de trabajo distinta.

- PASO 3: La interfaz de usuario WCS muestra la página de login WCS. En la misma, ingresamos nuestro nombre de usuario y contraseña. Por defecto, este es root y la contraseña es public.

Tras un login satisfactorio, el WCS está listo para ser utilizado. La página de sumario de red se muestra en la siguiente figura, desde la cual el operador puede comenzar a agregar dispositivos y configurar el sistema usando los menús horizontales y verticales.

Cuando el WCS recibe mensajes de alarma desde el controlador, la interfaz de usuario muestra una alarma en un indicador en la esquina inferior izquierda conocida como monitor de alarmas. Las alarmas indican errores actuales o estados de un elemento que necesita atención. Varios eventos generan alarmas. Podemos borrarlas, pero el evento permanece. Los siguientes códigos de color rigen el nivel de cada alarma: Rojo (alarma crítica) // Naranja (Alarma mayor) // Amarillo (Alarma menor).

6.4.2 Añadir un controlador WLAN al WCS En la figura de la página siguiente se muestra la pantalla que usamos para añadir y cambiar controladores WLAN de la base de datos del WCS. Cuando conocemos la IP del controlador, seguiremos los siguientes pasos para añadirlo a la base de datos del WCS:

CCNP ONT

116

- PASO 1: Nos logamos en la interfaz de usuario del WCS. - PASO 2: Escogemos Configure > Controllers. Aparece la página todos los controladores. - PASO 3: Desde la lista desplegable que aparece en la figura, escogemos Add Controller, y le damos

click a Go. Aparece la página de añadir controlador (siguiente imagen). - PASO 4: En esta nueva pantalla ingresamos la IP del controlador, la máscara de red, y las

configuraciones SNMP requeridas en los campos de la ventana “Add Controller”. - PASO 5: Hacemos click en OK. El WCS muestra un cuadro de diálogo “please wait” mientras contacta

con el controlador. El WCS añade la configuración actual del controlador a la base de datos del WCS y entonces vuelve a mostrar la página “Add Controller” de nuevo.

Si el WCS no encuentra un controlador en la IP que ingresamos, el mismo mostrará un mensaje “No response from device, check SNMP”. Para corregir este problema debemos comprobar que la IP que ingresamos es la correcta. Debemos intentar hacer ping al controlador para ver si obtenemos respuesta del mismo. Las configuraciones SNMP del controlador tienen que coincidir con las que ingresemos en el WCS.

6.4.3 Configurar un Punto de Acceso Los AP asociados a los controladores WLAN se añaden automáticamente al WCS. Para ver todos los puntos de acceso, escogemos Configure > Access Points. La página que obtenemos permite ver un sumario de todos los puntos de acceso Lightweight en la base de datos del WCS. La página también permite añadir puntos de acceso de terceros y eliminar puntos de acceso seleccionándolos. Obtenemos la siguiente información de cada punto de acceso: Su nombre // Dirección MAC // Tipo de radio // Localización de mapa // Controlador // Estado operacional // Estado de alarmas.

6.4.4 Agregar un mapa del campus a la base de datos del WCS Cuando añadimos mapas al WCS, podemos ver nuestros sistemas gestionados en un campus real, edificio, y mapas de planta de los pisos. Completaremos los siguientes pasos para añadir un mapa de campus a la base de datos del WCS:

- PASO 1: Guardamos el mapa en formato .png, .jpg, .jpeg o .gif. El mapa puede ser de cualquier tamaño ya que el WCS lo reajusta para que se adapte a las áreas de trabajo.

- PASO 2: Buscamos e importamos el mapa desde cualquier lugar de nuestro sistema. - PAOS 3: Escogemos la etiqueta Monitor.

CCNP ONT

117- PASO 4: Escogemos Maps desde la página Maps. - PASO 5: Desde la lista desplegable, escogemos “New Campus”, y hacemos click en OK para mostrar

la página de Nuevo Campus. - PASO 6: En la página del Nuevo Campus, ingresamos el nombre del campus y la información de

contacto. - PASO 7: Escogemos Browse para buscar y seleccionar el gráfico del campus. - PASO 8: Marcamos la casilla “Maintain Aspect Ratio” para prevenir que se distorsione la imagen. - PASO 9: Ingresamos la envergadura horizontal y vertical del mapa en pies. - PASO 10: Hacemos click en OK y añadimos el mapa del campus a la base de datos del WCS. El WCS

muestra la página Maps, en la cual se alistan los mapas de su base de datos, tipos de mapas y estado del campus.

6.4.5 Detección de Puntos de acceso fakes Cuando se encienden los AP Lightweight de nuestra WLAN y se asocian a los controladores, el WCS

inmediatamente comienza a escuchar la posibilidad de la existencia de puntos de acceso fakes (rogue). Cuando el controlador detecta un AP rogue, inmediatamente notifica al ECS, el cual crea un alarma apuntando a un rogue AP. En la figura se muestra que el WCS tiene localizados 93 puntos de acceso rogue. Cuando el WCS recibe un mensaje de rogue AP desde un controlador, aparece una alarma en la parte inferior izquierda de la interfaz de usuario del WCS.

Si seleccionamos el indicador se muestra la página de alarmas de puntos de acceso fakes. Esta página alista la severidad de las alarmas, la MAC de los AP fakes, los tipos de AP fakes, el propietario (operadores WCS), el día y la hora cuando se detecto en primer momento este AP, los números de canal que están enviando los AP rogues, y los SSID de los mismos.

6.4.6 Localización de los AP rogues En la página “Rogue AP MAC Address”, escogemos Map para mostrar la localización de los puntos de acceso fakes actuales calculados usando el WCS location. Cisco WCS compara la intensidad de la señal RSSI desde 2 o más puntos de acceso para encontrar la localización más probable del AP rogue y coloca un pequeño indicador con una calavera de la localización posible. Para acusar recibo del AP rogue, navegamos a la página de alarmas de AP rogues. Hacemos click derecho en rogue Access Point (rojo, desconocido) que queremos acusar recibo y configuramos Set state to “Know Internal” o Set state to “Know External”. En cualquier caso, el WCS retira al AP rogue de la página de alarmas.

CCNP ONT

118

6.5 Configurar Cifrado y Autenticación el Puntos de Acceso Lightweight

6.5.1 Configurar Autenticación Abierta

La autenticación abierta se usa cuando no se desea ninguna autenticación o cifrado. Esto es normal para la implementación “invitada” para visitantes. Para las WLANs existentes, escoger WLANs y editarlas. Para nuevas WLAN, creamos una nueva WLAN escogiendo WLANs>New y hacer click en Apply para navegar a esta página. Está página permite editar los parámetros configurables para un WLAN. El método de autenticación por defecto para una nueva WLAN es 802.1x. La razón de ello es protegerse contra autenticaciones abiertas accidentales. El siguiente paso es cambiar el valor de la lista desplegable de seguridad de capa 2 de 802.1x a None. Asegurarse que ambos campos de seguridad, capa 2 y capa 3, se configuran con None.

6.5.2 Configuración de autenticación con clave WEP estática

Para las WLAN existentes, escoger la WLAN y editarla. Para crear una nueva seguimos el mismo proceso del paso anterior. Escoger el método de seguridad de capa 2 Static WEP. La parte inferior de la pantalla se actualizará para mostrar las opciones WEP con los parámetros apropiados. Los parámetros de cifrado WEP son los siguientes:

CCNP ONT

119- Tamaños de clave de 40/64, 104/128 y 128/152 bits. - Índices de clave de 1 a 4. - Ingresar la clave de cifrado. - Escoger el tipo de formato de cifrado de clave (ASII o HEX).

6.5.3 Configurar WPA con claves pre-compartidas

Escogemos WPA como método de seguridad de capa 2. La parte inferior de la pantalla se actualizará para reflejar los parámetros apropiados para WPA. Marcamos la casilla Enabled de la parte inferior en pre-shared key, y escribimos la clave (Passphrase) a utilizar.

6.5.4 Configurar autenticación Web La autenticación web permite a los usuarios autenticarse a través de una interfaz de navegador web. Los clientes que intenten acceder a la WLAN usando HTTP son redirigidos automáticamente a una página de login. Esta página es personalizable (logos y texto). Las solicitudes de autenticación máximas usando este método son 21. El número máximo de usuarios logados vía web es de 2500. Este método de autenticación se usa generalmente para un acceso de invitados. Debido a que no hay cifrado, autenticación por paquete, o integridad del mensaje (MIC), los usuarios deberían usar algún otro mecanismo de seguridad tras la autenticación. Para configurar la autenticación web seguiremos los siguientes pasos:

En el área de seguridad de capa 3, marcamos la casilla Web Policy para habilitar la política web. La parte inferior de la pantalla se actualiza para reflejar esta elección y ofrece los siguientes parámetros de autenticación vía web: AUTHENTICATION: Si escogemos esta opción, se solicitará un usuario y contraseña mientras el cliente se conecta a la red wireless. Las credenciales serán verificadas en una base de datos interna del controlador. Si no coincide el usuario, se usará un servidor RADIUS externo para su comprobación, si el mismo está configurado. PASSTHROUGH: Si escogemos esta opción, podemos acceder a la red directamente sin ingresar usuario y contraseña. Esta opción se usa simplemente para presentar una noticia lega antes de permitir el

acceso. Se puede solicitar un correo electrónico antes de permitir el acceso a la red. PREAUTHENTICATION ACL: Escoger la ACL que será usada para el tráfico entre el cliente y el controlador. El controlador tendrá que reiniciarse para cargar y habilitar la prestación de autenticación web.

6.5.5 Personalizar la pantalla de login Web Escogemos Management>Web Login Page para navegar por la misma. Podemos personalizar el contenido y la apariencia de esta página.

CCNP ONT

120Los parámetros de la pantalla de login web son los siguientes:

USE EXTERNAL WEB AUTHENTICATION: Habilitamos esta opción e ingresamos una URL si queremos usar una pantalla de login personalizada configurada en nuestro servidor web para la autenticación web en lugar de la pantalla por defecto provista por los controladores WLAN de la serie 4000. REDIRECT URL AFTER LOGIN: Ingresamos la URL a la que queremos que el usuario se re-dirigido después de logarse. Podríamos ingresar la URL de nuestra compañía. HEADLINE: Especifica la cabecera de la pantalla de login. Por ejemplo: “Bienvenido a la red Wireless de Cisco”. MENSAJE: Especifica un mensaje en la pantalla de login. Por ejemplo: “Por favor, ingrese su nombre de usuario y contraseña”, o “Esta página no estará disponible de 1:00 a 2:00 p.m. por labores de mantenimiento”.

6.5.6 Configurar autenticación 802.1x

Escogemos 802.1x desde el método de seguridad de capa 2 a utilizar. La parte inferior de la pantalla se actualiza para mostrar las opciones 802.1x con sus parámetros apropiados.

CCNP ONT

121802.1x usa claves WEP 802.11 dinámicas. Las opciones son: 40/64 bits. 104/128 bits. 128/152 bits. Las claves de128/152 bits son soportadas solo por 802.11i, WPA y WPA2.

6.5.7 Configurar WPA con 802.1x

Escogemos WPA desde la seguridad de capa 2. Dejamos sin marcar pre-shared key para utilizar claves WPA dinámicas. El proceso de autenticación usará una autenticación 802.1x EAP con un servidor RADIUS.

6.5.8 WPA2

Escogemos WPA2 desde la lista de seguridad de capa 2. Las opciones de seguridad y los parámetros que aparecen ahora en la parte inferior son los siguientes: MODO DE COMPATIBILIDAD WPA: Esta opción permite soporte para clientes WPA y WPA2 en el mismo SSID para soportar sistemas antiguos durante la migración a WPA.

CCNP ONT

122PERMITIR CLIENTES WPA-2 TKIP: Esta opción permite soportar hardware antiguo que no puede ejecutar AES-CCMP pero que puede ejecutar WPA2. CLAVE PRE-COMPARTIDA: Cuando se marca esta opción, podemos escoger habilitar un clave pre-compartida.