07 - Preparacion Para Servicios Avanzados

© 2007 – 2010, Cisco Systems, Inc. All rights reserved. Cisco Public SWITCH v6 Chapter 7

1

Capítulo 7: Preparación de la infraestructura de campus para servicios avanzados

CCNP SWITCH: Implementing IP Switching

Chapter 7 2 © 2007 – 2010, Cisco Systems, Inc. All rights reserved. Cisco Public

Capítulo 7 - Objetivos § Evaluar el impacto de las WLANs, la voz y el video en las

operaciones de la infraestructura de campus. § Describir la aplicación de calidad de servicio (QoS) en una

infraestructura de campus para soportar servicios avanzados. §  Implementar multicast en una infraestructura de campus para

soportar servicios avanzados. § Preparar las redes de campus para la integración con las

redes LAN inalámbricas. § Preparar las redes de campus para la integración de la voz. § Preparar las redes de campus para la integración del video.


Planificación para las aplicaciones inalámbricas, de voz y video en la red de campus


Objetivo de las implementaciones inalámbricas en la red de campus

§ Productividad: los usuarios mejoran la productividad a través de la habilidad para acceder a los recursos durante las reuniones, entrenamientos y presentaciones.

§ Movilidad: los usuarios que se desplazan dentro del campus pueden convertirse en usuarios móviles con acceso a los recursos del mismo, como ser el e-mail.

§ Colaboración mejorada: las redes wireless permiten la colaboración mejorada entre usuarios, mediante la ventaja de poseer una red sin cables.

§  Interconectividad del campus: las redes wireless tienen la capacidad para interconectar oficinas remotas y redes externas a la red de campus, tarea que no puede ser implementada a través del uso de la red cableada tradicional.


Objetivos del uso de la voz en la red de campus § Uso más eficiente del ancho de banda y del equipamiento. § Costos más bajos para la transmisión en redes telefónicas. § Consolidación del gasto en la red de voz y datos. §  Incremento en los ingresos a partir del nuevo servicio. § Capacidad para apalancar el acceso a nuevos dispositivos

de comunicaciones. § Estructura de precios flexible. § Énfasis en las grandes innovaciones en los servicios.


Objetivo de la implementación de video en la red de campus

§ Colaboración: tecnologías de video conferencia como la TelePresencia y el soporte de video en la colaboración ampliada para el soporte de WebEx.

§ Ahorros de costos: las tecnologías de video reducen los costos de traslados y viajes, habilitando a los usuarios remotos a asistir a reuniones o entrenamientos, sin la necesidad de estar físicamente presentes.


Planificación de la red de campus para soportar tecnologías inalámbricas

1.  Introducción a las redes LAN inalámbricas (WLANs).

2.  Soluciones Cisco WLAN aplicadas a redes de campus.

3.  Comparación y contraste entre las WLAN y las LAN.

4.  Enfoques “standalone” vs. “controller-based” para las implementaciones de WLAN en la red de campus.

5.  Recopilación de requisitos para la planificación de una implementación inalámbrica.


1. Introducción a las redes LAN inalámbricas Métodos de comunicación inalámbrica de datos: §  Infrarrojo (III): alta tasa de datos, bajo costo y corta distancia § Narrowband: baja tasa de datos, costo medio y distancia

limitada. Requiere licencia § Spread spectrum: limitado a la cobertura del campus, costo

medio y alta tasa de datos. § Servicio personal de comunicación (Personal Communication

Service - PCS): baja tasa de datos, costo medio, cobertura urbana.

§ Celular: costo bajo a medio, cobertura nacional e internacional (típica compañía de telefonía celular)

§ Ultra-wide band (UWB): cobertura de corta distancia y gran ancho de banda.


1. Introducción a las redes LAN inalámbricas Tecnología Spread Spectrum § Banda de 900 MHz: 902 MHz a 928 MHz § Banda de 2.4 GHz: 2.4 GHz a 2.483 GHz § Banda de 5 GHz: 5.150 MHz a 5.350 MHz, 5.725 MHz a

5.825 MHz, con algunos países soportando bandas intermedias entre 5.350 MHz y 5.825 MHz


1. Introducción a las redes LAN inalámbricas Tecnologías inalámbricas


1. Introducción a las redes LAN inalámbricas Tasas de datos y áreas de cobertura


2. Soluciones Cisco de LAN inalámbricas aplicadas a redes de campus

Cisco Unified Wireless Network § Dispositivos cliente § Plataforma de movilidad § Unificación de la red § Administración de red de clase mundial § Servicios unificados avanzados.


3. Comparación y contraste entre WLAN y LAN

WLANs: §  Los usuarios se desplazan libremente dentro de su entorno.

§  Los usuarios tienen acceso en tiempo real a la red cableada a velocidades de cable (wired speed) Ethernet.

§  Los usuarios acceden a todos los recursos de las redes cableadas.



WLAN vs. LAN (1): § Ambas redes definen las capas física y de enlace de datos

y utilizan direcciones MAC.

§ En las redes WLAN se usan frecuencias de radio como parte de la capa física de la red.

§  Las redes WLAN usan CSMA/CA (carrier sense multiple access / collision avoidance) en lugar de CSMA/CD (carrier sense multiple access / collision detection), utilizado por las redes LAN Ethernet.



WLAN vs. LAN (2): §  Las redes WLAN usan un formato de trama diferente a las

redes LAN Ethernet. Para el caso de las redes WLAN, se requiere información adicional en el encabezado de la trama de Capa 2.

§  Las ondas de radio usadas en las redes WLAN pueden presentar problemas, situación que no sucede en las redes cableadas.

§  Los problemas de conectividad en las redes WLAN pueden ocurrir por inconvenientes en la cobertura, en la transmisión de RF, por distorsión multipath y por interferencias producidas por otros servicios inalámbricos u otras redes WLAN.


3. Comparación y contraste entre WLAN y LAN WLAN vs. LAN (3): §  Los problemas de privacidad son posibles porque las

frecuencias de radio son accesibles desde fuera del entorno de la red.

§ En las redes WLAN, se usan clientes móviles para conectarse a la red.

§  Los dispositivos móviles siempre requieren alimentación a batería.

§  Las redes WLAN deben contemplar regulaciones específicas sobre potencia y frecuencias RF, propias del país donde se implementan.


4. Enfoque “standalone” vs “controller-based” en la implementación de WLAN en redes de campus

Solución WLAN “standalone”: §  Access Control Server (ACS)

•  RADIUS/TACACS+

§  Cisco Wireless LAN Solution Engine (WLSE) •  Administración centralizada y

monitoreo.

§  Wireless Domain Services (WDS) •  Soporte de administración para

WLSE

§  Infraestructura de red. §  Access points “standalone”


Solución WLAN basada en controlador (1) § Access Control Server (ACS):

•  RADIUS/TACACS+

§ Wireless Control System (WCS) •  Administración centralizada y monitoreo

§ Appliance de locación •  Seguimiento de la locación

§ Wireless LAN Controller (WLC) •  Configuración de APs y WLAN.

§  Infraestructura de red •  Switch con PoE y router

§ Access points basados en controlador


Solución WLAN basada en controlador (2) § Reparto de los procesos de los protocolos wireless 802.11

entre los AP y el WLC (llamado “split MAC”)


Solución WLAN basada en controlador (3) § Funciones MAC del AP:

•  802.11: Beacons, respuestas de sonda •  Control 802.11: reconocimiento y transmisión de paquetes. •  802.11e: encolado de tramas y priorización de paquetes. •  802.11i: encripción y desencripción de datos en capa MAC.


Solución WLAN basada en controlador (4) § Funciones MAC del Wireless LAN Controller:

•  Administración MAC en 802.11: peticiones y acciones de asociación. •  802.11e: reserva de recursos. •  802.11i: autenticación y administración de clave.


Solución WLAN basada en controlador (5)

§  Manipulación del tráfico en soluciones basadas en controlador: •  Los datos y mensajes de control son encapsulados entre el access point y el

controlador WLAN usando el método de control y aprovisionamiento de access points inalámbricos (CAPWAP) o el protocolo Lightweight Access Point (LWAPP). A pesar que ambos están basados en estándares, LWAPP nunca fue adoptado por algún otro fabricante que no fuera Cisco.

•  El tráfico de control entre los access point y el controlador es encapsulado con LWAPP o CAPWAP y luego encriptado.

•  El tráfico de datos entre el access point y el controlador también es encapsulado con LWAPP o CAPWAP, aunque no es encriptado. Éste es conmutado en el WLC, donde también se aplican el etiquetado de VLAN y la calidad de servicio (QoS).

•  El access point logra el intercambio de tramas en tiempo real y ciertas partes de la administración MAC en tiempo real. Todo el tráfico de datos del cliente es enviado a través del controlador WLAN.

•  El WLC y el access point pueden estar en los mismos o en diferentes dominios de broadcast y subredes IP. Los access points obtienen una dirección IP mediante DHCP, y luego se unen al controlador por medio de los mecanismos de descubrimiento CAPWAP o LWAPP.


Solución WLAN basada en controlador (6) § Flujo de tráfico en una

solución basada en controlador •  El tráfico entre dos estaciones

móviles inalámbricas es reenviado desde los access points hacia el controlador y luego enviado hacia las estaciones móviles


Solución WLAN basada en controlador (7)

§ Hybrid Remote Edge Access Points (HREAP) • Provee alta disponibilidad a las soluciones wireless

basadas en controlador en oficinas remotas. •  Los AP siguen ofreciendo conectividad de cliente

wireless aunque su conexión con el WLC esté caída.


Comparación de las soluciones “standalone” y basada en controlador

Objeto/Acción Standalone Basada en controlador Access point IOS “standalone” IOS liberado basado en

controlador

Configuración Mediante el access point Mediante el WLC

Operación Independiente Dependiente del WLC

Administración y monitoreo

A través del WLSE A través del WCS

Redundancia Mediante múltiples access points

Mediante múltiples WLC


5. Requerimientos de planificación para la implementación de wireless

Planificación para la implementación y ejecución:

§  Determinar la cantidad y tipo de puertos que se necesitan y la forma en que deberían ser configurados.

§  Chequear la red para verificar la forma en que los requerimientos pueden integrarse dentro de la implementación existente.

§  Planificar el equipamiento adicional necesario para completar los requerimientos.

§  Planificar la implementación.

§  Implementar los nuevos componentes de la red.


Ejemplo de plan de pruebas § ¿Puede alcanzar el AP o el WLC desde las estaciones de

administración?

§ ¿Puede el AP alcanzar el servidor DHCP?

§ ¿Puede el AP obtener una dirección IP del servidor DHCP?

§ ¿Puede el WLC alcanzar el servidor Radius o TACACS+?

§ ¿Puede el cliente obtener una dirección IP?

§ ¿Puede el cliente acceder a la red, a un servidor o a los servicios de Internet?


Planificación de la red de campus para soporte de voz

§ Comunicaciones unificadas

§ Requerimientos de diseño de la red de campus para la implementación de VoIP


Comunicaciones unificadas

§ Teléfono IP: provee voz IP al escritorio.

§ Gatekeeper: provee control de admisión de conexión (CAC), control de ancho de banda, administración y traducción de dirección.


Comunicaciones unificadas - Gateway

§ Provee traducción entre redes VoIP y no-VoIP, como la PSTN (Public Switched Telephone Network).

§ También provee acceso físico para dispositivos de voz locales (analógicos y digitales), como ser teléfonos, equipos de fax y centrales PBX.


Comunicaciones unificadas - Unidad de control multipunto (MCU)

§ Provee conectividad en tiempo real para participantes en múltiples locaciones, con el fin de atender a una misma videoconferencia o encuentro.


Comunicaciones unificadas - Agente de llamada § Provee control de

llamadas para teléfonos IP, control de admisión de llamadas (CAC), control de ancho de banda, administración y traducción de direcciones de telefonía para direcciones IP o números de teléfono.


Comunicaciones unificadas - Servidor de aplicación

§ Provee servicios como el correo de voz, mensajería unificada y la Cisco Unified Communications Manager Attendant Console.


Comunicaciones unificadas - Estación de videoconferencia

§ Provee acceso al usuario final para la participación en videoconferencias. Esta estación contiene un dispositivo de captura de video para la entrada de video y un micrófono para la entrada de audio. El usuario puede ver el video y escuchar el audio que se origina en una estación de usuario remota.


Requerimientos de diseño en redes de campus para implementación de VoIP

Requerimientos de QoS para voz: §  Los paquetes de voz son pequeños, típicamente entre 60 y

120 bytes de tamaño. § VoIP no puede tolerar dropeo de paquetes o delay porque

ésto podría derivar en una calidad de voz pobre. § VoIP usa UDP porque las capacidades de retransmisión de

TCP no son útiles para la voz. § Para una óptima calidad de voz, el delay debería ser menor

a los 150 mseg. en un sólo sentido. § Una pérdida de paquetes aceptable está alrededor del 1%.


Requerimientos de diseño en redes de campus para implementación de VoIP Comparación del tráfico de voz y datos


Planificación de la red de campus para soporte de video

§ Tráfico de voz y video.

§ Flujo de tráfico de video en la red de campus.

§ Requerimientos de diseño para voz, datos y video en la red de campus.


Planificación de la red de campus para soporte de video – Tráfico de voz y video


Planificación de la red de campus para soporte de video – Flujo de tráfico de video en la red de campus § Determinar qué aplicaciones

serán implementadas: •  Aplicaciones peer-to-peer, como

la TelePresencia. •  Aplicaciones de video streaming,

como el entrenamiento con video on-demand.

•  Aplicaciones de video de tipo TV, como Cisco IP TV.

•  Aplicaciones de videovigilancia IP para seguridad.


Planificación de la red de campus para soporte de video – Requerimientos de diseño para voz, datos y video en la red de campus Requirimiento Datos Voz Video Ancho de banda Alto Bajo Alto

Delay Si es menor a unos pocos mseg, no aplica

Menor a 150 mseg

Menor a 150 mseg para video en tiempo real

Jitter No aplica Bajo Bajo Pérdida de paquetes Menor a 5% Menor a 1% Menor a 1% Disponibilidad Alta Alta Alta Power en línea No Opcional Opcional para

dispositivos específicos

Seguridad Alta Media Baja o Media Aprovisionamiento Esfuerzo medio Esfuerzo

significante Esfuerzo medio


Fundamentos de Quality of Service (QoS)


Modelos de servicio QoS §  Servicio “Best-effort”: es el formato estándar de conectividad sin

garantías. Este tipo de servicio, en referencia a los switches Catalyst, usa colas FIFO, lo que simplemente transmite paquetes a medida que arriban en una cola sin tratamiento preferencial.

§  Servicio integrado: IntServ, también conocido como “hard QoS”, es una reservación de servicios. En otras palabras, el modelo IntServ implica que los flujos de tráfico son explicitamente reservados por todos los sistemas intermedios y recursos.

§  Servicio diferenciado: DiffServ, también conocido como “soft QoS”, está basado en clases, en donde algunas clases de tráfico reciben tratamiento preferencial por sobre otras clases de tráfico. Los servicios diferenciados usan preferencias estadísticas, no una garantía estricta como usan los servicios integrados. En otras palabras, DiffServ categoriza el tráfico y luego lo ordena en colas de distintas eficiencias.


Modelo de QoS Cisco

§ Clasificación y marcado de tráfico. § Traffic shaping y traffic policing. § Administración de la congestión. § Cancelación de la congestión.


Escenarios para AutoQoS § Negocios pequeños a medianos que deban implementar

telefonía IP rápidamente, pero carecen de la experiencia y el personal para planificar y desplegar servicios IP con QoS.

§ Grandes empresas que necesitan implementar soluciones de telefonía IP Cisco a gran escala, mientras reducen los costos, la complejidad y las ventanas de tiempo para su ejecución, asegurando que se aplique en forma consistente la QoS apropiada para las aplicaciones de voz.

§ Empresas internacionales o proveedores de servicio que requieran implementar QoS para VoIP en sitios donde exista poca experiencia en la materia y donde la provisión de QoS de forma remota y en diferentes zonas horarias se haga difícil.


Ayuda de AutoQoS para una implementación exitosa de QoS

§ Clasificación de la aplicación.

§ Generación de políticas.

§ Configuración.

§ Monitoreo y reportes.

§ Consistencia.


Clasificación y marcado de tráfico

§ DSCP, ToS y CoS

§ Métodos de clasificación de paquetes


DSCP, ToS y CoS


Differentiated Services Code Point (DSCP)


Métodos de clasificación de paquetes en switches Cisco

§ Modos de confiabilidad por interface

§ Clasificación manual por interface usando específicamente DSCP, precedencia IP o valores de CoS.

§ Por paquete basado en listas de acceso.

§ Network-Based Application Recognition (NBAR)


Límites de confiabilidad y configuraciones Mapeo CoS-a-DSCP por default CoS 0 1 2 3 4 5 6 7

DSCP 0 8 16 24 32 40 48 56

Mapeo Precedencia IP-a-DSCP por default Precedencia IP 0 1 2 3 4 5 6 7

DSCP 0 8 16 24 32 40 48 56


QoS Trust

§  El concepto de “QoS trust” en un switch Cisco Catalyst se basa en la característica de configuración de “puerto confiable”. Cuando el switch confía en la CoS de los paquetes entrantes en dicho puerto, el switch mapea los valores entrantes a los respectivos valores DSCP. Cuando la configuración de QoS de la interface de ingreso es “no confiable”, el switch usa el valor 0 como valor DSCP interno para todos los paquetes entrantes.


Marcado § El marcado refiere al cambio de los bits de DSCP, CoS o

precedencia IP en las tramas entrantes en un switch Catalyst.

§ Es configurable por interface o mediante un “policy map”.

§ El marcado altera el valor DSCP de los paquetes, lo que a su vez afecta internamente a DSCP.

§ Por caso, un ejemplo de marcado sería configurar un “policy map” para marcar todas las tramas provenientes de un servidor de video, por interface, con un valor DSCP de 40, resultando también en un valor DSCP interno de 40.


Traffic Shaping § Traffic shaping mide tasas de tráfico y delays (buffers) del

tráfico excesivo, de manera que esas tasas permanezcan dentro de un límite deseado. Como resultado, el “shaping” recorta las ráfagas excesivas para lograr un flujo constante de datos.


Traffic Policing §  Traffic policing toma una

acción específica con el tráfico excedente o “fuera de perfil” por encima de una tasa específica. Traffic policing no retrasa o bufferea el tráfico.

§  Usualmente, la acción para el tráfico que excede una tasa específica es el dropeo; sin embargo, otras acciones son permisibles, como el caso del trusting y el marcado.

§  Policing sigue el algoritmo de “balde con fuga de tokens”, lo que permite ráfagas de tráfico en lugar de limitación de la velocidad.


Administración de la congestión § Colas FIFO.

§ Colas “Weighted Round Robin” (WRR).

§ Colas por prioridad.

§ Colas “custom”.


Administración de la congestión – Colas FIFO

§  Las colas FIFO ubican todas las tramas salientes dentro de la misma cola. Esencialmente, una cola FIFO no usa clasificación.


Administración de la congestión – Colas WRR

§  Las colas “Weighted Round Robin” usan un valor de peso configurado para cada cola de egreso.


Administración de la congestión – Colas con prioridad

§  Un método de priorización y programación de tramas provenientes de tráfico saliente es utilizar colas con prioridad. Cuando aplicamos una prioridad estricta a una de esas colas, el switch programará las tramas de esa cola (si es que existen) antes de atender a cualquier otra cola. Los switches Cisco ignoran la programación de WRR para colas configuradas como colas prioritarias; la mayoría de los switches Catalyst soportan la designación de una única cola saliente como cola prioritaria.

§  El encolado prioritario es útil para aplicaciones de voz en las cuales el tráfico de voz ocupa dicha cola. Sin embargo, dado que este tipo de programación puede resultar en la desatención de las colas no prioritarias, y a fin de evitar dicho problema, las colas restantes estarán sujetas al encolado WRR.


Administración de la congestión - Custom Queuing

§ Otro método de encolado disponible en los switches Cisco, estrictamente ligado a interfaces WAN, es Custom Queuing (CQ), el cual reserva un porcentaje del ancho de banda disponible para una interface para cada tipo de tráfico seleccionado. Si un tipo particular de tráfico no está usando el ancho de banda reservado, otras colas y tipos de tráfico podrán usar ese ancho de banda remanente.

§ CQ es configurado estáticamente y no provee adaptación automática a los cambios en las condiciones de la red. Además, CQ no es recomendado en interfaces WAN de alta velocidad; refiérase a las guías de configuración para soporte de CQ en interfaces LAN.


Cancelación de congestión §  Las técnicas de cancelación de congestión monitorean la

carga de tráfico de red, en un esfuerzo por anticipar y evitar la congestión en los habituales “cuellos de botella” de la red.

§  Los dos algoritmos de cancelación de congestión usados en los switches Cisco son:

•  Tail Drop – este es el algoritmo por default

•  Weighted Random Early Detection (WRED)


Cancelación de la congestión – Tail Drop §  El dropeo de tramas afecta habitualmente las sesiones TCP en ejecución.

El dropeo arbitrario de tramas en una sesión TCP resulta en sesiones TCP concurrentes que simultáneamente dan marcha atrás y se reinician, produciendo un efecto “diente de sierra”. Como resultado de ello, ocurre una utilización ineficiente del enlace en el punto de congestión (sincronización global TCP).

§  Como resultado de la aplicación de “tail drop”, los flujos agresivos de TCP podrían aprovechar todo el espacio en las colas salientes por sobre el flujo normal de TCP.

§  Un encolado excesivo de paquetes en las colas de salida en el punto de congestión resulta en delay y jitter durante la transmisión de paquetes.

§  No existe un mecanismo diferenciado de dropeo; el tráfico “premium” es dropeado de la misma manera que el tráfico “best-effort”.

§  Aún en el caso de un único flujo TCP a través de una interface, la presencia de otro tráfico no-TCP podría congestionar la interface. En este escenario, la retroalimentación hacia TCP es pobre; como resultado, TCP no puede adaptarse de manera apropiada a la red congestionada.


Cancelación de la congestión – WRED (1)


Cancelación de la congestión – WRED (2)


Implementación de IP Multicast en una red de campus


Introducción a IP Multicast §  IP multicast es la transmisión de paquetes de datos IP

hacia un grupo de hosts, el cual está definido por una única dirección IP, llamada dirección IP multicast.


Membresía de grupo en multicast § El tráfico IP multicast usa

UDP como protocolo de capa de transporte.

§ Para evitar la duplicación, los protocolos de ruteo multicast usan “reverse path forwarding” (RPF).


Estructura de direccionamiento IP multicast §  IP multicast usa direcciones de Clase D, en el rango entre

224.0.0.0 y 239.255.255.255.


Estructura de direccionamiento IP multicast Descripción Rango

Direcciones reservadas de enlace local 224.0.0.0 a 224.0.0.255

Direcciones de ámbito global 224.0.1.0 a 238.255.255.255

Direcciones Source-Specific Multicast (SSM)

232.0.0.0 a 232.255.255.255

Direcciones GLOP 233.0.0.0 a 233.255.255.255

Direcciones de alcance limitado 239.0.0.0 a 239.255.255.255


Direcciones reservadas de enlace local §  Usan el rango de direcciones 224.0.0.0 a 224.0.0.255

•  Usadas por protocolos de red en un segmento de red local; los routers no reenvían paquetes en este rango de direcciones; enviada con un TTL seteado en 1.

•  OSPF usa las direcciones 224.0.0.5 y 224.0.0.6. •  RIPv2 usa la dirección 224.0.0.9 •  EIGRP usa la dirección 224.0.0.10 •  224.0.0.1: identifica al grupo de “todos-los-hosts”. •  224.0.0.2: identifica al grupo de “todos-los-routers”.


Direcciones de ámbito global

§ Direcciones en el rango de 224.0.1.0 a 238.255.255.255

•  Las compañías usan estas direcciones para la transmisión multicast de datos entre organizaciones y a través de Internet.

•  Las aplicaciones multicast reservan algunas de estas direcciones para uso dentro del ámbito del IANA. Por ejemplo, IANA reserva la dirección IP 224.0.1.1 para NTP.


Direcciones Source-Specific Multicast (SSM)

§ Direcciones en el rango de 232.0.0.0 a 232.255.255.255.

•  SSM es una extensión del protocolo PIM (Protocol Independent Multicast).

•  Las decisiones de reenvío están basadas tanto en una dirección de grupo como en una dirección orígen, denotadas G y S, y referidas como un “canal”.

•  La dirección orígen hace único a cada canal.


Direcciones GLOP § Especificadas por la RFC 3180. §  233.0.0.0/8 – rango reservado para direcciones definidas

estáticamente por organizaciones que ya posean un número de sistema autónomo.

§ GLOP no es un acrónimo. § El número de AS del dominio está embebido dentro del

segundo y tercer octeto del rango de direcciones 233.0.0.0 a 233.255.255.255. Por ejemplo, el AS 62010 es escrito en formato hexadecimal como F23A. Separando los dos octetos F2 y 3A resulta en los valores 242 y 58 en formato decimal, respectivamente. Estos valores nos indican la subred 233.242.58.0/24, la cual es reservada globalmente para ser utilizada por el AS 62010.


Direcciones de alcance limitado § Direcciones en el rango de 239.0.0.0 a 239.255.255.255.

§ Descriptas en la RFC 2365, “Administratively Scoped IP Multicast”.

§ Restringidas a un grupo local u organización.

§  Las compañías, universidades u otras organizaciones usan direcciones de alcance limitado para ejecutar aplicaciones multicast locales, donde los routers de borde hacia Internet no reenvíen tramas multicast fuera del dominio de intranet.


Estructura de una dirección MAC multicast §  Las direcciones MAC multicast comienzan con el prefijo de

25 bits 0x01-00-5E, el cual traducido a numeración binaria es igual a 00000001.00000000.01011110.0xxxxxxx.xxxxxxxx.xxxxxxxx, donde cada x representa un bit wildcard. El vigesimoquinto bit está seteado en 0.


Reverse Path Forwarding (RPF) § El router busca la dirección de origen en la tabla de ruteo

unicast para determinar si el paquete llegó por la interface que está conectada directamente al camino inverso (o camino de menor costo) de regreso al origen.

§ Si el paquete ha arribado a la interface que conduce de retorno al origen, el chequeo RPF es exitoso y el router replica y reenvía el paquete hacia las interfaces salientes.

§ Si el chequeo RPF del paso previo falla, el router descarta el paquete y registra el dropeo como una falla de RPF.


Ejemplo de RPF


Tráfico multicast no-RPF


Árboles de reenvío multicast §  Los routers con capacidad de multicast crean arboles de

distribución multicast, que controlan el camino que el tráfico IP multicast toma a través de la red para despachar el tráfico hacia todos los receptores.

§ Existen dos tipos de árbol de distribución:

•  Árboles de orígen.

•  Árboles compartidos.


Árboles de orígen


Árboles compartidos


Comparación de los tipos de árbol

Shared Tree Source Tree


Protocolos IP Multicast

§  IP multicast usa su propios protocolos para el enrutamiento, para la administración y para su Capa 2.

§ Existen dos protocolos multicast importantes:

•  Protocol Independent Multicast (PIM)

•  Internet Group Management Protocol (IGMP)


Protocol Independent Multicast (PIM) § PIM tiene dos versiones: 1 y 2.

§ PIM posee cuatro modos de operación:

•  PIM en modo “dense”

•  PIM en modo “sparse”

•  PIM en modo “sparse-dense”

•  PIM bidireccional


PIM en modo “dense” (PIM-DM) - Obsoleto


PIM en modo “sparse” (PIM-SM)

§  PIM-SM está optimizado para entornos donde existan varios flujos de datos multipunto.

§  Cuando se planifica la implementación de multicast en una red de campus, optar por PIM-SM con IP ante los siguientes escenarios: •  Existen varios flujos de datos multipunto. •  En cualquier momento dado, hay pocos receptores en un grupo. •  El tipo de tráfico es intermitente o por ráfagas.


PIM en modo “sparse-dense”

§ Habilita individualmente a los grupos a utilizar tanto el modo “sparse” como el modo “dense” dependiendo si la información del RP está disponible para ese grupo.

§ Si el router aprende la información RP para un grupo en particular, se está utilizando modo “sparse”.


PIM Bidireccional (Bidir-PIM)

§ Extensión de PIM-SM.

§ Adecuado para redes multicast con un gran número de orígenes.

§ Puede reenviar tráfico de origen hacia el RP ascendiendo por el árbol compartido sin registración de los orígenes (como en PIM-SM).

§  Introduce un mecanismo denominado “promotor designado” (DF - Designated Forwarder).


Distribución automatizada de RP

§ Auto-RP

§ Router Bootstrap (BSR)

§ Anycast – RP

§ Multicast Source Discovery Protocol (MSDP)


Auto-RP


Bootstrap Router


Comparación y compatibilidad de PIM v1 y PIM v2

§ PIM versión 2 es un estándar IETF.

§ Es la versión recomendada por Cisco.

§ PIM v2 interopera con routers con PIM v1 o PIM v2.

§ En PIM v2 el mecanismo de distribución RP es BSR, pero también puede usar Auto-RP.


Internet Group Management Protocol (IGMP) § Versiones de IGMP:

•  IGMP versión 1 (IGMPv1) RFC 1112



•  IGMP versión 3 lite (IGMPv3 lite)


IGMPv1 §  Los mensajes de consulta de membresía de un host IGMP

son enviados periódicamente para determinar qué grupos multicast poseen miembros en las LANs directamente conectadas a un router.

§  Los mensajes de consulta IGMP son direccionados hacia el grupo de “todos-los-host” (224.0.0.1) y poseen un valor de TTL IP igual a 1.

§ Cuando un dispositivo final recibe un mensaje de consulta IGMP, ese dispositivo responde con un reporte de membresía de host para cada grupo al que pertenece.


IGMPv2 § Tipos de mensajes IGMPv2:

•  Consulta de membresía •  Reporte de membresía versión 2 •  Reporte de salida •  Reporte de membresía versión 1

§ El mensaje de consulta específico del grupo habilita a un router a transmitir una consulta específica a un grupo en particular. Además IGMPv2 define un mensaje de salida de grupo para los hosts, lo que resulta en una menor latencia de salida.


IGMPv3 § Permite que un receptor multicast le indique a un router los

grupos de los que quiere recibir tráfico multicast y de qué origen espera tráfico.

§ Mensajes IGMPv3: •  Consulta de membresía versión 3 •  Reporte de membresía versión 3

§  Los receptores señalan la membresía a un grupo de hosts multicast en modo INCLUDE o en modo EXCLUDE.


IGMPv3 Lite

§ Solución de transición hacia SSM, propietaria de Cisco.

§ Soporta aplicaciones SSM cuando los hosts no soportan IGMPv3.

§ Requiere Host Side IGMP Library (HSIL).


IGMP Snooping

§ Mecanismo de restricción para IP multicast.

§ Configura dinámicamente los puertos de Capa 2 para reenviar tráfico multicast sólo a aquellos puertos con hosts que quieran recibir dicho tráfico.

§ Opera en switches multicapa.

§ Examina los mensajes “join” y “leave” de IGMP.


Configuración de IGMP Snooping (1) §  Paso 1. Habilitar globalmente IGMP Snooping. (Por default, está

habilitado globalmente.) Switch(config)# ip igmp snooping

§  Paso 2. (Opcional) Los switches agregan puertos de router multicast a la tabla de reenvío para cada entrada multicast de Capa 2. El switch aprende sobre esos puertos a través de consultas IGMP snooping, del flujo de paquetes PIM y DVMRP o interpretando paquetes IGMP de otros routers. Configurar el método de IGMP snooping. El default es PIM. Switch(config)# ip igmp snooping vlan vlan-id mrouter learn [cgmp | pim-dvmrp]

§  Paso 3. (Opcional) De ser necesario, configurar estáticamente el puerto del router. Por default, IGMP snooping detecta automáticamente los puertos de router. Switch(config)# ip igmp snooping vlan vlan-id mrouter interface interface-num


Configuración de IGMP Snooping (2) §  Paso 4. (Opcional) Configurar “fast leave” de IGMP si es requerido. Switch(config)# ip igmp snooping vlan vlan-id fast-leave

Switch(config)# ip igmp snooping vlan vlan-id immediate-leave

§  Paso 5. (Opcional) Por default, todos los hosts registran y agregan en forma automática la dirección MAC y el puerto a la tabla de reenvío. De ser necesario, hay que configurar estáticamente un host en una interface. Generalmente, las configuraciones estáticas son necesarias cuando se realiza troubleshooting o cuando se trabaja en la resolución de problemas en IGMP. Switch(config)# ip igmp snooping vlan vlan-id static mac-address interface interface-id


Configuración de IP Multicast (1) § Paso 1. Habilitar globalmente el ruteo multicast en Capa 3. Switch(config)# ip multicast-routing

§ Paso 2. Habilitar PIM en la interface que requiera multicast. Switch(config-if)# ip pim [dense-mode | sparse-mode | sparse-dense-mode]

§ Paso 3. (Opcional) Configurar RP si se está ejecutando PIM en modo “sparse” o PIM en modo “sparse-dense”. El software Cisco IOS puede ser configurado así para que los paquetes de un único grupo multicast puedan usar uno o más RPs. Es importante configurar la dirección RP en todos los routers (incluyendo el router RP). Para configurar la dirección del RP, ingresar el siguiente comando en modo de configuración global: Switch(config)# ip pim rp-address ip-address [access-list-number] [override]


Configuración de IP Multicast (2) § Paso 4. (Opcional) Para designar un router como candidato

RP para todos los grupos multicast o para un grupo multicast particular mediante el uso de una lista de acceso, ingresar el siguiente comando en modo de configuración global: Switch(config)# ip pim send-rp-announce interface-type interface-number scope ttl [group-list access-list-number] [interval seconds]

•  El valor TTL define la frontera multicast, a fin de limitar el número de saltos que pueden realizar los anuncios RP.

§ Paso 5. (Opcional) Para asignar el rol de agente de mapeo RP al router configurado en el Paso 4 para AutoRP, ingresar el siguiente comando en modo de configuración global: Switch(config)# ip pim send-rp-discovery scope ttl


Configuración de IP Multicast (3) § Paso 6. (Opcional) Todos los sistemas que usan Cisco IOS

Release 11.3(2)T o superior arrancan en modo PIM v2 por default. En caso de necesitar rehabilitar PIM v2 o especificar PIM v1 por alguna razón, use el siguiente comando: Switch(config-if)# ip pim version [1 | 2]

§ Paso 7. (Opcional) Configurar un router de borde BSR para el dominio PIM para que los mensajes bootstrap no crucen este límite en cualquier dirección. Esto asegurará que se elijan diferentes BSRs a ambos lados de la frontera de PIM. Se debe configurar este comando en una interface a fin de que los mensajes BSR de PIM v2 no sean enviados o recibidos a través de la misma: Switch(config-if)# ip pim bsr-border


Configuración de IP Multicast (4) § Paso 8. (Opcional) Para configurar una interface como

candidata BSR, ejecutar el siguiente comando: Switch(config)# ip pim bsr-candidate interface-type hash-mask-length [priority] •  El atributo hash-mask-length es una máscara de 32 bits para la

dirección de grupo antes de ejecutarse la función hash. Todos los grupos con la misma semilla de hash corresponden al mismo RP. La prioridad se configura con un número entre 0 y 255. El BSR con la prioridad más alta es el preferido. Si los valores de prioridad son los mismos, el dispositivo con la dirección IP más alta es elegido como BSR. El valor por default es 0.

§ Paso 9. (Opcional) Para configurar una interface como una candidata RP en un router BSR para grupos multicast particulares, ejecute el siguiente comando: Switch(config)# ip pim rp-candidate interface-type interface-number ttl group-list access-list


Ejemplo de configuración del modo “sparse”

§ PIM-SM en Cisco IOS con RP en 10.20.1.254

Router# conf t Router(config)# ip multicast-routing Router(config)# interface vlan 1 Router(config-if)# ip pim sparse-mode Router(config-if)# interface vlan 3 Router(config-if)# ip pim sparse-mode Router(config-if)# exit Router(config)# ip pim rp-address 10.20.1.254


Ejemplo de configuración del modo “sparse-dense”

§ PIM en modo “sparse-dense” con un BSR candidato.

Router(config)# ip multicast-routing Router(config)# interface vlan 1 Router(config-if)# ip pim sparse-dense-mode Router(config-if)# exit Router(config)# ip pim bsr-candidate vlan 1 30 200


Ejemplo de configuración de Auto-RP § Auto-RP anuncia la dirección IP de la VLAN 1 como RP

Router(config)# ip multicast-routing Router(config)# interface vlan 1 Router(config-if)# ip pim sparse-dense-mode Router(config-if)# exit Router(config)# ip pim send-rp-announce vlan 1 scope 15 group-list 1 Router(config)# access-list 1 permit 225.25.25.0.0.0.0.255 Router(config)# exit


Preparación de la infraestructura de campus para soporte de tecnologías inalámbricas


Parámetros Wireless LAN

§ Rango

§  Interferencia

§ Performance

§ Seguridad


Preparación de la red de campus para la integración de una solución WLAN standalone


Preparación de la red de campus para la integración de una solución WLAN basada en controlador


Preparación de la infraestructura de campus para soporte de voz


Componentes de la telefonía IP

§ Teléfonos IP.

§ Switches con alimentación en línea (PoE).

§ Administrador de procesamiento de llamadas.

§ Gateway de voz


Configuración de switches para soporte de VoIP

§ VLAN de voz

§ QoS

§ Power over Ethernet (PoE)


VLAN de voz


Configuración de una VLAN de voz §  Paso 1. Asegurar que QoS esté globalmente habilitada mediante el comando mls qos e ingresar en modo configuración a la interface sobre la cual se quiere configurar la VLAN de voz.

§  Paso 2. Habilitar la VLAN de voz en el puerto del switch y asociarle un ID de VLAN usando el comando switchport voice vlan vlan-id.

§  Paso 3. Configurar el puerto en modo confiable para la CoS o DSCP de las tramas que arriban al switch usando los comandos mls qos trust cos o mls qos trust dscp respectivamente. Recordar que el primero de ellos le indica al switch que confíe en los valores de CoS al ingreso, mientras que el segundo permite confiar en los valores de DSCP al ingreso. No hay que confundir ambos comandos ya que cada uno de ellos configura el switch para que observe diferentes bits de la trama para su clasificación.

§  Paso 4. Verificar la configuración de la VLAN de voz utilizando el comando show interfaces interface-id switchport.

§  Paso 5. Verificar la configuración de QoS de la interface usando el comando show mls qos interface interface-id.


Ejemplo de configuración de una VLAN de voz §  La interface FastEthernet0/24 es configurada para setear los

dispositivos de datos con la VLAN 1 por default y los dispositivos VoIP con la VLAN de voz 700.

§ El switch usa CDP para informar la existencia de un teléfono IP asociado a la VLAN respectiva. Como el puerto tiene conectado un dispositivo final, se habilita portfast.

<output omitted> ! mls qos ! <output omitted> ! interface FastEthernet0/24 switchport mode dynamic desirable switchport voice vlan 700 mls qos trust cos power inline auto spanning-tree portfast ! <output omitted>


QoS para tráfico de voz en los teléfonos IP § Definir los límites de confianza (trust boundaries).

§ Usar CoS o DSCP en dichos límites.

<output omitted> ! mls qos ! <output omitted> ! interface FastEthernet0/24 switchport mode dynamic desirable switchport voice vlan 700 mls qos trust cos power inline auto spanning-tree portfast ! <output omitted>


Power over Ethernet (PoE) §  La tensión de alimentación viaja a través del cable Ethernet de

Categoría 5e o superior.

§  La tensión es provista por el switch o por una fuente de alimentación adicional.

§ Existen dos tipos de estándares para la alimentación en línea: IEEE 802.3af y Cisco Inline Power. Los nuevos dispositivos Cisco soportan ambos esquemas.


Ejemplo de configuración de PoE § El comando show power inline muestra la configuración

y las estadísticas sobre la potencia eléctrica utilizada por los dispositivos conectados y la capacidad de la fuente de alimentación.

Switch# show power inline fa0/24 Interface Admin Oper Power Device Class Max (Watts) --------- ------ ---------- ------- ------------------- ----- ---- Fa0/24 auto on 10.3 IP Phone CP-7970G 3 15.4 Interface AdminPowerMax AdminConsumption (Watts) (Watts) ---------- --------------- ------------------ Fa0/24 15.4 15.4


Requerimientos adicionales de red para VoIP §  Los teléfonos IP Cisco reciben su dirección IP y descargan

su archivo de configuración via TFTP desde un Cisco Unified Communications Manager (CUCM) o un CUCM Express (CUCME).

§ Registrar los teléfonos IP con CUCM o CUCME y obtener sus números de extensión de línea.


Preparación de la infraestructura de campus para soporte de video


Aplicaciones de video

§ Video peer-to-peer.

§ TelePresencia.

§ Vigilancia IP.

§ Sistemas de medios digitales (Digital Media Systems – DMS).


Configuración de switches para soporte de video § Pérdida de paquetes menor a 0.5 %.

§  Jitter menor que 10 mseg en un sentido.

§  Latencia menor que 150 mseg en un sentido.


Mejores prácticas para TelePresencia §  Clasificar y marcar el tráfico usando DSCP lo más próximo posible a

los bordes de la red, preferentemente en el switch de capa de acceso de primer salto. Si un host es confiable, permitirle al mismo marcar su propio tráfico.

§  Configurar “trust QoS” en cada link entre switches o entre switches y routers, a fin de preservar el marcado de los frames que viajan a través de la red. Ver la RFC 4594 para más información.

§  Limitar la cantidad de tráfico de voz en tiempo real y video al 33% de la capacidad del enlace. Por sobre este valor, el flujo de datos de la TelePresencia podría quitar recursos a las otras aplicaciones, lo que derivaría en un desempeño lento o errático de dichas aplicaciones.

§  Reservar al menos el 25% del ancho de banda del enlace para tráfico de datos de tipo “best-effort”.

§  Implementar una clase Scavenger con el 1% para evitar que las aplicaciones no controladas dominen la clase de datos “best-effort”.

§  Siempre que sea posible, usar el encolado WRED basado en DSCP en todos los flujos TCP.


Resumen del Capítulo 7


Capítulo 7 - Resumen (1) § Cuando se planifica una implementación de wireless, se

deberán analizar cuidadosamente tanto la opción “standalone” como la solución basada en controlador. Para redes con más que unos pocos access points, la mejor práctica es el uso de una solución basada en controlador.

§ Cuando se prepara una implementación wireless, se deberá verificar la configuración de los puertos de switch a utilizar en modalidad “trunk”. Opcionalmente los access points soportan trunking y transportan múltiples VLAN. Los clientes wireless pueden mapear a diferentes SSID, lo que a su vez se puede trasladar al uso de diferentes VLAN.


Capítulo 7 - Resumen (2) § Cuando se planifica una implementación de voz en una red

de campus, se recomienda el uso de QoS y la configuración de una VLAN separada para el tráfico de voz. PoE es otra opción a tener en cuenta, a fin de alimentar los teléfonos IP Cisco sin necesidad de usar fuentes externas de AC/DC.

§ Durante la preparación de una implementación de voz, debemos asegurar la configuración de QoS lo más próxima posible al puerto de borde. Se recomienda la configuración de DSCP en modo confiable o CoS para el tratamiento de las tramas entrantes.


Capítulo 7 - Resumen (3) § Cuando se planifica una implementación de video, se debe

determinar si la aplicación de video es “en tiempo real” o “bajo demanda”. El video en tiempo real requiere baja latencia y envío de tráfico en ráfagas con alto uso de ancho de banda.

§ Cuando se prepara una implementación de video del tipo de TelePresencia, se debe consultar con un especialista para asegurarse que la red de campus reúna todos los requisitos en términos de ancho de banda y calidad de servicio (QoS).


Capítulo 7 – Laboratorios §  Lab 7-1: Configuración de switches para soporte de telefonía IP.

§  Lab 7-2: Configuración de un controlador WLAN (WLC).

§  Lab 7-3: Voz y seguridad en una red conmutada - Estudio de caso.


Capítulo 7 – Recursos

§  Referencia de comandos para Catalyst 3560: www.cisco.com/en/US/partner/docs/switches/lan/catalyst3560/software/release/12.2_55_se/command/reference/3560_cr.html

§  Configuración de QoS: www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/swqos.html

§  Configuración de IP Multicast: www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/swqos.html

§  Configuración de IGMP Snooping: www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_55_se/configuration/guide/swigmp.html


Documents

07 - Preparacion Para Servicios Avanzados