CCNP SWITCH Foundation Learning Guide - En.es

Traducido del inglés al español - www.onlinedoctranslator.
com
Capítulo 7
Preparando el Campus
Infraestructura para Servicios
Avanzados
Este capitulo cubre los siguientes topicos:
■ Planificación de aplicaciones inalámbricas, de voz y de video en la red del campus
■ Comprender la calidad del servicio
■ Implementando IP Multicast en la Red del Campus
■ Preparación de la infraestructura del campus para soportar la tecnología inalámbrica
■ Preparación de la infraestructura del campus para soportar la voz
■ Preparación de la infraestructura del campus para apoyar el video
Los servicios avanzados en la red del campus están impulsando una nueva era de movilidad,
colaboración y negocios virtuales. Considere una red de campus que admita conectividad para cualquier
dispositivo móvil. Considere los ahorros de costos asociados con las videoconferencias de alta definición.
Considere la ventaja comercial de reducir los costos de viaje asociados con la capacitación y participar en
la capacitación virtual. ¿Considera asistir a una reunión en Asia desde su escritorio? ¿Considera usar una
única red convergente para las comunicaciones de voz? Los servicios avanzados como inalámbricos, de
voz y de video en la red del campus están entregando las aplicaciones mencionadas a la red del campus
en la actualidad.
Este capítulo se centra en los servicios avanzados de la red para incluir servicios inalámbricos, de voz y de
video. El capítulo está organizado en secciones en las que se presenta información de planificación para
tecnología inalámbrica, voz y video, seguida de introducciones a QoS y multidifusión, y finaliza con
información sobre la preparación e implementación de tecnología inalámbrica, voz y video. QoS y
multidifusión se presentan porque QoS es un requisito para voz y video en la red del campus, mientras que
varias aplicaciones de video utilizan multidifusión.
420 Implementación de Cisco IP Switched Networks (SWITCH) Guía básica de aprendizaje
Planificación de aplicaciones inalámbricas, de voz y de video en la

red del campus
Como se indicó en la introducción, la documentación de Cisco considera las aplicaciones inalámbricas,
de voz y de video como tecnologías avanzadas. A medida que pasa el tiempo, estas tecnologías
avanzadas tienden a convertirse en una tecnología de implementación estándar. Cada una de estas
tecnologías avanzadas (inalámbrica, voz y video) amplía la amplitud tecnológica de la mayoría de los
ingenieros de redes, ya que las tecnologías de red típicas de capa 2 y 3 son lo suficientemente amplias
por sí mismas. De las tres tecnologías avanzadas, la tecnología inalámbrica requiere el mayor esfuerzo
adicional para su aplicación en la red del campus.
Nota Debido a que este libro trata sobre la conmutación, este capítulo se enfoca solo en la conexión
inalámbrica desde la aplicación en la empresa. El términoinalámbricoen el contexto de este libro se limita
estrictamente a Wi-Fi en el campus y no representa ninguna tecnología celular u otras tecnologías
inalámbricas, como Bluetooth.
Es interesante notar que durante la evolución de este título, Voz sobre IP (VoIP), una aplicación de voz
construida para usar TCP/IP, pasó de ser una característica nueva y elegante a una aplicación de voz de clase
empresarial de uso generalizado en la actualidad. Además, la aplicación de VoIP en la red también se ha
simplificado porque los conmutadores de Cisco ahora admiten funciones inteligentes que facilitan la
configuración de la voz.
Nota En el contexto de este capítulo, los términos voz, telefonía IP y VoIP se usan
indistintamente para describir la aplicación de la telefonía y sus funciones y
aplicaciones adicionales en la red empresarial.
El video como aplicación se utiliza en varias empresas para capacitación, TV interna, etc.; sin embargo, la mayoría
de las empresas también usan video basado en la web, como video flash, para brindar capacitación empresarial de
video a pedido, y demás. Al igual que con VoIP, el video ha pasado de ser una buena característica a ser una
característica estándar que se encuentra en las redes de los campus. Las siguientes tres subsecciones se enfocan
en la motivación detrás de la implementación inalámbrica, de voz y de video en la red del campus, comenzando con
la tecnología inalámbrica.
El Propósito de las Implementaciones de Redes Inalámbricas en la Red del

Campus
La motivación detrás de la implementación inalámbrica en la red del campus es sencilla: la
productividad. Los usuarios finales que pueden acceder a los recursos de la red sin una conexión física
en una reunión, sala de conferencias, durante el almuerzo, etc., son más productivos que los usuarios
finales que no tienen dicho acceso. Además, en el mundo actual de colaboración, los usuarios finales de
la red del campus necesitan acceder a los recursos desde reuniones, capacitaciones, charlas de
enfriadores de agua, etc. En los próximos años, la implementación inalámbrica en el campus
Capítulo 7: Preparación de la infraestructura del campus para servicios avanzados 421
la red será tan estándar como los teléfonos celulares. En resumen, la siguiente lista destaca la motivación
detrás de la implementación de redes inalámbricas en la red del campus:
■ Productividad:Los usuarios obtienen productividad a través de la capacidad de acceder a los recursos durante
reuniones, capacitaciones, presentaciones, almuerzos, etc.
■ Movilidad:Los usuarios en movimiento dentro del campus pueden ser móviles con acceso a los recursos del campus,
como el correo electrónico.
■ Colaboración mejorada:Las redes inalámbricas permiten una colaboración de usuario mejorada a

través del beneficio de una red sin cables.
■ Interconectividad de campus:Las redes inalámbricas tienen la capacidad de interconectar

oficinas remotas, redes externas, etc., que no pueden interconectarse a la red del campus a
través del cable de red físico tradicional.
Nota Los puntos de acceso a la red inalámbrica generalmente se conectan a la capa de acceso de la red del
campus. Sin embargo, ciertos requisitos físicos o de planta de cable pueden requerir que estos dispositivos
estén conectados a las capas de distribución o de núcleo. Sin embargo, un punto de acceso se considera un
dispositivo de borde desde el punto de vista de la red del campus.
Nota La motivación detrás de la implementación inalámbrica en la red del campus es brindar movilidad a
los usuarios finales y las ganancias de productividad asociadas.
Los usuarios inalámbricos no necesitan un cable físico para acceder a los recursos de la red. La
siguiente sección analiza las ventajas de la convergencia de voz con datos en la red del campus.
El Propósito de la Voz en la Red de Campus

Los propósitos principales del uso de voz en una red de campus son simples: ahorro de costos y mayor
productividad. La mayoría de las empresas se han subido al carro de VoIP y están implementando con
éxito esta tecnología. Cada una de estas empresas ha tenido éxito con estas implementaciones, ya que
han logrado ahorros en los costos y han aumentado la productividad de los usuarios. En detalle, la
siguiente lista captura las motivaciones detrás de la implementación de voz en la red del campus:
■ Uso más eficiente del ancho de banda y del equipo:Por ejemplo, las redes de telefonía tradicional utilizan un
canal de 64 kbps para cada llamada de voz. La telefonía por paquetes comparte el ancho de banda entre
múltiples conexiones lógicas y descarga los volúmenes de tráfico de los conmutadores de voz existentes.
■ Menores costos de transmisión de redes telefónicas:Se necesita una cantidad sustancial de equipo
para combinar canales de 64 kbps en enlaces de alta velocidad para el transporte a través de la
red. La telefonía por paquetes multiplexa el tráfico de voz junto con el tráfico de datos. En otras
palabras, el tráfico de voz y el tráfico de datos coexisten en la misma infraestructura de red.
422 Implementación de Cisco IP Switched Networks (SWITCH) Foundation Guía de aprendizaje
Esta consolidación representa ahorros sustanciales en equipos de capital y costos

operativos.
■ Gastos de consolidación de redes de voz y datos:Las redes de datos que funcionan como redes
separadas de las redes de voz se convierten en los principales portadores de tráfico. Las redes de
voz subyacentes se convierten para utilizar la arquitectura de conmutación de paquetes para crear
una única red de comunicaciones integrada con un sistema común de conmutación y transmisión. El
beneficio es un importante ahorro de costos en equipos y operaciones de red.
■ Aumento de los ingresos del nuevo servicio:Por ejemplo, la telefonía de paquetes permite nuevos servicios
integrados, como audio con calidad de transmisión, mensajería unificada y colaboración de voz y datos en
tiempo real. Estos servicios aumentan la productividad de los empleados y los márgenes de beneficio muy
por encima de los de los servicios básicos de voz. Además, estos servicios permiten a las empresas y
proveedores de servicios diferenciarse y mejorar su posición en el mercado.
■ Capacidad para aprovechar el acceso a nuevos dispositivos de comunicación:Usando tecnología de paquete-

La tecnología permite a las empresas y proveedores de servicios llegar a dispositivos que son en gran parte
inaccesibles para las infraestructuras de multiplexación por división de tiempo (TDM) de hoy. Ejemplos de
tales dispositivos son computadoras, dispositivos inalámbricos, electrodomésticos, asistentes digitales
personales y decodificadores de cable. El acceso inteligente a dichos dispositivos permite a las empresas y
proveedores de servicios aumentar el volumen de las comunicaciones que entregan, la amplitud de los
servicios que ofrecen y la cantidad de suscriptores a los que atienden. Por lo tanto, la tecnología de
paquetes permite a las empresas comercializar nuevos dispositivos, incluidos videoteléfonos, terminales
multimedia y teléfonos IP avanzados.
■ Estructura de precios flexible:Las empresas y los proveedores de servicios con redes de conmutación de
paquetes pueden transformar sus modelos de precios y servicios. Debido a que el ancho de banda de la
red se puede asignar dinámicamente, el uso de la red ya no necesita medirse en minutos o distancia. La
asignación dinámica brinda a los proveedores de servicios la flexibilidad para satisfacer las necesidades
de sus clientes de manera que les brinden los mayores beneficios.
■ Énfasis en una mayor innovación en el servicio:Las comunicaciones unificadas utilizan la infraestructura IP.
estructura para consolidar métodos de comunicación que antes eran independientes; por ejemplo, fax,
correo de voz, correo electrónico, teléfonos fijos, teléfonos celulares, centros de llamadas e Internet. La
infraestructura de IP proporciona a los usuarios un método común para acceder a los mensajes e iniciar
comunicaciones en tiempo real, independientemente de la hora, la ubicación o el dispositivo.
Nota Las motivaciones clave detrás de la implementación de voz en la red del campus son el ahorro de costos, el
aumento de la eficiencia de la red y las ganancias de productividad de los servicios de voz.
En resumen, es fácil entender por qué las empresas tienen y continúan implementando VoIP en la red del
campus. La siguiente sección detalla los propósitos detrás de la implementación inalámbrica en la red del
campus.
Desde una perspectiva de implementación, todos los dispositivos de voz y aplicaciones de software para uso
de usuarios finales o clientes se conectan a la capa de acceso de la red del campus. Las funciones de
procesamiento y computación de la voz generalmente se encuentran en el centro de datos. La sección
"Planificación de la red inalámbrica" ofrece más detalles sobre la planificación de la voz en la red del campus.
El propósito de las implementaciones de video en la red del campus
El video tiene un propósito único en la red del campus como se discutió anteriormente. Su propósito es
cierto en torno a la colaboración. Quizás el uso más interesante y práctico del video últimamente es
TelePresence. Si no ha experimentado TelePresence, debe hacerlo. Es absolutamente increíble lo real
que se siente. No obstante, TelePresence requiere una gran cantidad de requisitos de ancho de banda
que impulsan los requisitos de ancho de banda de la red empresarial no solo en el campus sino también
entre las redes del campus. La mejor aplicación de TelePresence es la comunicación entre múltiples
campus y sitios remotos. En resumen, la motivación detrás de la implementación de video en la red del
campus es la siguiente:
■ Colaboración:Las tecnologías de videoconferencia como TelePresence y el soporte de video en

WebEx admiten una colaboración mejorada.
■ Ahorro de costes:Las tecnologías de video reducen los costos de viaje al permitir que los usuarios
remotos asistan a reuniones, capacitaciones, etc. sin estar físicamente presentes.
Nota La principal motivación para implementar video en la red del campus es la colaboración
mejorada y el ahorro de costos asociado con las capacitaciones y reuniones virtuales.
Ahora que se comprende la motivación detrás de cada tecnología avanzada, las siguientes tres
secciones se sumergen en la información básica sobre la tecnología necesaria para comprender la
planificación y la preparación detrás de cada tecnología.
Planificación de la red del campus para soportar tecnologías inalámbricas
Las LAN inalámbricas a menudo se comparan con las LAN estándar y se consideran "LAN sin
cables". Las WLAN en realidad se integran en la infraestructura LAN para ampliarla. Tiene
similitudes con las LAN cableadas. Sin embargo, también presenta diferencias importantes que es
necesario apreciar para realizar una integración exitosa en la red del campus. La siguiente sección
proporciona algunos antecedentes antes de hablar de las LAN inalámbricas a las LAN del campus y
la preparación asociada.
Introducción a las LAN inalámbricas (WLAN)

Las redes inalámbricas resuelven el problema del intercambio de datos sin cables. Los siguientes son diferentes
tipos de métodos de comunicación inalámbrica de datos, cada uno de los cuales tiene sus ventajas y desventajas:
■ Infrarrojos (III):Altas velocidades de datos, menor costo y corta distancia
■ Banda estrecha:Tarifas de datos bajas, costo medio, licencia requerida, distancia limitada
■ Espectro ensanchado:Cobertura limitada a campus, costo medio, velocidades de datos altas
■ Servicio de Comunicaciones Personales (PCS):Tarifas de datos bajas, costo medio, cobertura en toda la
ciudad
■ Celular:Cobertura nacional y mundial de bajo a mediano costo (operador de telefonía

celular típico)
■ Banda ultraancha (UWB):Cobertura de alto ancho de banda de corto alcance
Como está implícito en la lista de métodos de comunicación, la tecnología inalámbrica en el campus

utiliza la metodología de espectro ensanchado. El enfoque inalámbrico de espectro ensanchado está
en las tres bandas sin licencia: 900 MHz, 2,4 GHz y 5 GHz. Las bandas de 900 MHz y 2,4 GHz se
conocen como bandas industriales, científicas y médicas (ISM), y la banda de 5 GHz se conoce
comúnmente como la banda de infraestructura de información nacional sin licencia (UNII).
La Figura 7-1 se refiere a las frecuencias para estas bandas. Son los siguientes:
■ 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, y algunos países
admiten bandas medias entre 5,350 MHz y 5,825 MHz
Radio de onda corta Transmisión FM

Televisión
Emisión AM
Audio Celular (840 Megahercio) LAN inalámbrica por infrarrojos
NPCS (1,9 GHz)
Extremadamente Muy Bajo Medio Alto Muy Ultra Super r Infrarrojo Visible Ultra- rayos x
Bajo Bajo Alto Alto Alto Luz Violeta
2,4-2,4835 GHz 5 GHz

902-928 MHz 83,5 MHz 802.11a
26 MHz 802.11b La frecuencia varía
y 802.11g con países
Figura 7-1 Bandas de frecuencia sin licencia
Hay muchos tipos diferentes de redes que se ofrecen. Cada red única proporciona un área de
cobertura definida. La Figura 7-2 enumera cada tecnología inalámbrica e ilustra las áreas de
cobertura correspondientes.
PÁLIDO
HOMBRE
(Red de área metropolitana)
LAN
CACEROLA
(Área Personal
Red)
CACEROLA LAN HOMBRE PÁLIDO
Estándar ds Bluetooth IEEE 802.11a/b/g, 802.16 G/M, GPRS,

HiperLAN2 MMDS, LMDS CDMA, 2.5-3G
Velocidad <1 Mbps Más de 100 Mbps 22+ Mbps 10-384 kbps
Rango Corto Medio Medio largo Largo
Aplicaciones De igual a igual, Empresa Fijo, Último- PDA, Móvil

Dispositivo a dispositivo Redes Acceso de milla Teléfonos, Celulares
Acceso
Figura 7-2 Tecnologías inalámbricas
La siguiente es una breve lista de las diferentes aplicaciones de las redes inalámbricas, comenzando
con el área más pequeña:
■ Red de área personal (PAN):Típicamente diseñado para cubrir su espacio de trabajo personal.
Las radios suelen ser de baja potencia, no ofrecen opciones en la selección de antena y
limitan el tamaño del área de cobertura a aproximadamente 15 a 20 pies radialmente. Una de
esas redes PAN es Bluetooth. Buenos ejemplos de esta tecnología son las comunicaciones
entre PC y periféricos o entre teléfonos inalámbricos y auriculares. En la red inalámbrica PAN,
el cliente posee el 100 por ciento de la red; por lo tanto, no se incurre en cargos por tiempo
aire.
■ LAN:Diseñado para ser una red basada en la empresa que permite el uso de suites completas de
aplicaciones empresariales sin cables. Una LAN generalmente ofrece velocidades compatibles con
Ethernet (hasta 10 Gbps). En la red inalámbrica LAN, el cliente posee el 100 por ciento de la red; por
lo tanto, no se incurre en cargos por tiempo aire.
■ Red de área metropolitana (MAN):Desplegado dentro de un área metropolitana, lo que permite la

conectividad inalámbrica en toda un área urbana. Un MAN generalmente ofrece velocidades de
banda ancha (similar a la línea de suscriptor digital [DSL]), pero no es capaz de velocidades de
Ethernet. En el MAN inalámbrico, la red inalámbrica puede ser de un operador con licencia, lo
que requiere que el cliente compre tiempo aire, o puede ser construida y respaldada por una
entidad, como un departamento de policía. Viene un nuevo estándar
de edad en el MAN es WiMAX. La información está disponible en Internet con respecto a

WiMAX.
■ PÁLIDO:Por lo general, más lento en velocidad pero ofrece más cobertura, a veces incluso rural
áreas Debido a su gran implementación, todas las WAN inalámbricas requieren que el cliente compre
tiempo aire para la transmisión de datos.
Las redes de campus, por supuesto, aplican redes inalámbricas basadas en LAN (WLAN). Cisco ofrece una amplia
gama de productos inalámbricos para LAN y otras aplicaciones como MAN y WAN. Los productos WLAN tienen
un alcance limitado pero velocidades relativamente altas que superan los 108 Mbps. La figura 7-3 ilustra las
áreas de cobertura y las tasas de datos de varias redes de datos inalámbricas que se utilizan hoy en día para las
WLAN.
50Mbps
10Mbps Desparramar
Espectro
Infrarrojo
2Mbps InalámbricoInalámbrico
LAN LAN
1Mbps
Datos 2.5G
Tasa Servicio
PC de banda ancha
56 kbps Datos de circuitos y paquetes

Celular, CDPD, Mobitex, DataTac
19,6 kbps
banda estrecha y
9,6 kbps LAN inalámbricas PC de banda estrecha Satélite
Local Ancho
Área de cobertura
Figura 7-3 Redes de datos inalámbricas
Con el fin de aplicar las WLAN a la red del campus, tenga en cuenta las velocidades y el rango de los
productos WLAN que se analizan en detalle en esta sección. Debido a que hay libros completos
dedicados a las WLAN, sería demasiado material cubrir la tecnología en detalle desde una perspectiva
de conmutación. Como tal, el resto de la información sobre WLAN en este capítulo se enfoca en la
planificación y preparación en la red del campus. Consulte Cisco.com u otros textos para obtener
información adicional sobre cómo funcionan las WLAN.
Soluciones WLAN de Cisco aplicadas a redes de campus

Cisco clasifica sus soluciones y productos WLAN de red de campus en un marco
denominado Red inalámbrica unificada de Cisco, que se divide en los siguientes
subelementos:
■ Dispositivos cliente:Se recomiendan encarecidamente los adaptadores de cliente compatibles con Cisco o
Cisco Aironet 802.11a/b/g/ para la red inalámbrica unificada de Cisco. Sin embargo, con más del 90 por
ciento de los dispositivos cliente de envío certificados como compatibles con Cisco, casi cualquier
dispositivo cliente que seleccione debe tener la certificación compatible con Cisco. Además, los dispositivos
cliente compatibles con Cisco interoperan y admiten características innovadoras y únicas de Cisco Unified
Wireless Network, como roaming rápido y seguro, IPS integrado, servicios de ubicación y una variedad de
tipos de autenticación extensible.
■ Plataforma de movilidad:Cisco ofrece puntos de acceso y puentes para empresas enmoquetadas,

entornos reforzados y entornos desafiantes, como exteriores. Los puntos de acceso ligeros Cisco
Aironet se configuran y administran dinámicamente a través del protocolo de punto de acceso
ligero (LWAPP), que se analiza más adelante en esta sección. Además, los puntos de acceso
autónomos Cisco Aironet tienen la opción de convertirse para operar como puntos de acceso
livianos que ejecutan LWAPP. Tenga en cuenta que no todos los modelos de AP autónomos de
Cisco Aironet se pueden convertir a AP LWAPP; consulte Cisco.com para obtener más información.
Nota Cisco ofrece una amplia gama de modelos de puntos de acceso inalámbricos. Para obtener una referencia completa y
actual de los modelos de AP, consulte las referencias de los modelos de AP inalámbricos en Cisco.com.
■ Unificación de red:La red inalámbrica unificada de Cisco aprovecha la red cableada existente
del cliente y la inversión en productos de Cisco. Admite una infraestructura de red perfecta
en una variedad de plataformas mediante la unificación con los controladores WLAN de
Cisco.
■ Gestión de red de clase mundial:Cisco ofrece un sistema de administración de red (NMS) de

clase mundial que visualiza y ayuda a proteger su espacio aéreo. Cisco Wireless Control
Systems (WCS) admite la planificación y el diseño de WLAN, la gestión de radiofrecuencia, el
seguimiento de ubicación e IPS, además de la configuración, el control y la gestión de los
sistemas WLAN. Esta plataforma gestiona fácilmente varios controladores y sus puntos de
acceso ligeros asociados.
■ Servicios avanzados unificados:Cisco brinda soporte unificado de aplicaciones de vanguardia.

ciones. Cisco ofrece servicios avanzados líderes en la industria, innovadores y completos. Los
puntos de acceso ligeros inalámbricos, los dispositivos de ubicación y los teléfonos IP
inalámbricos brindan los servicios avanzados de Cisco Unified Wireless Network.
Aunque la información detallada y la configuración de estos elementos no son necesarios para la

conmutación, se pueden hacer referencia a ellos en las implementaciones de voz. La siguiente sección
analiza las similitudes y diferencias de las LAN y las WLAN.
Comparación y contraste de WLAN y LAN

Como se señaló anteriormente, las LAN cableadas requieren que los usuarios se ubiquen en un lugar y permanezcan
allí. Debido a que las WLAN son una extensión de la red LAN cableada, permiten que los usuarios sean móviles
mientras usan los dispositivos móviles en diferentes lugares sin una conexión de red cableada. Una WLAN puede ser
una superposición o un sustituto de una red LAN cableada tradicional.
Con Cisco WLAN, los usuarios móviles pueden
■ Moverse libremente por una instalación
■ Disfrute de acceso en tiempo real a la LAN por cable a velocidades de Ethernet por cable
■ Accede a todos los recursos de las LAN alámbricas
Las WLAN son esencialmente LAN 802.11; recuerde la nomenclatura 802 de 802 de conmutación CCNA.
Fundamentalmente, los datos de las WLAN se envían a través de ondas de radio. En las LAN alámbricas, los datos
se envían a través de cables. Sin embargo, la interfaz de red de las WLAN es similar a la de las LAN alámbricas
para el usuario.
La siguiente lista resume las similitudes y diferencias entre las LAN alámbricas e
inalámbricas:
■ Tanto las WLAN como las LAN cableadas definen las capas de enlace físico y de datos y
utilizan direcciones MAC. Los mismos protocolos y aplicaciones se pueden utilizar en LAN y
WLAN. Ejemplos de tales protocolos son el protocolo IP y Seguridad IP (IPsec) para redes
privadas virtuales (VPN). Ejemplos de aplicaciones son la administración web, FTP y
Protocolo simple de administración de red (SNMP).
■ En las WLAN, las frecuencias de radio se utilizan como capa física de la red.
■ Las WLAN utilizan la prevención de colisiones de acceso múltiple con detección de portadora (CSMA/CA) en lugar de la
detección de colisiones de acceso múltiple con detección de portadora (CSMA/CD), que es utilizada por
LAN Ethernet. La detección de colisiones no es posible porque una estación emisora no

puede recibir al mismo tiempo que transmite y, por lo tanto, no puede detectar una
colisión. En su lugar, se utilizan los protocolos Request To Send (RTS) y Clear To Send (CTS)
para evitar colisiones.
■ Las WLAN utilizan un formato de trama diferente al de las LAN Ethernet cableadas. Se requiere
información adicional para WLAN en el encabezado de capa 2 del marco.
■ Las ondas de radio utilizadas por las WLAN tienen problemas que no se encuentran en los cables.
■ Los problemas de conectividad en las WLAN pueden deberse a problemas de cobertura, transmisión de RF,
distorsión de trayectos múltiples e interferencias de otros servicios inalámbricos u otras WLAN.
■ Los problemas de privacidad son posibles porque las frecuencias de radio pueden llegar fuera de las instalaciones y
del plan de cable físico.
■ En las WLAN, los clientes móviles se utilizan para conectarse a la red.
■ Los dispositivos móviles a menudo funcionan con baterías.

■ Las WLAN están disponibles en todo el mundo; sin embargo, debido a que las WLAN usan frecuencias de
radio, deben seguir las regulaciones específicas del país para frecuencias y potencia de RF. Este requisito
no se aplica a las LAN cableadas.
Las WLAN obviamente presentan desafíos más allá de las LAN alámbricas. La discusión de los problemas, las
posibles soluciones y más información técnica sobre las operaciones de WLAN está fuera del alcance de este texto.
Consulte Cisco.com para obtener más información. La siguiente sección del capítulo presenta los enfoques
independientes frente a los basados en controladores para las implementaciones de WLAN, un tema fundamental
para planificar las implementaciones de WLAN en el campus.
Enfoques autónomos versus basados en controladores para implementaciones de WLAN en

la red del campus
Para la implementación de una red inalámbrica unificada de Cisco en una red de campus, existen dos
estrategias de implementación para las soluciones WLAN. Estas soluciones de implementación son la
solución WLAN independiente y la solución WLAN basada en controlador.
Sinónimo de su denominación, la solución WLAN independiente utiliza puntos de acceso independientes

como estrategia de implementación. Para implementaciones de WLAN escaladas que usan la solución
independiente, Cisco recomienda el uso de Cisco Wireless LAN Solution Engine (WLSE) para administración
y monitoreo centralizados. Las soluciones WLAN independientes pueden denominarse soluciones WLAN
autónomas en otros documentos y textos.
Por el contrario, la solución WLAN basada en controlador utiliza sistemas de administración centralizados no
solo para administrar y monitorear el punto de acceso, sino también para controlar, configurar y operar cada
punto de acceso. Las soluciones WLAN basadas en controladores pueden denominarse soluciones WLAN
ligeras en otros documentos y textos.
En resumen, las soluciones WLAN independientes (soluciones WLAN autónomas) se implementan mediante
puntos de acceso independientes y, opcionalmente, utilizan un WLSE para la administración centralizada. Las
soluciones WLAN basadas en controlador se implementan con un controlador centralizado, mientras que el
controlador no solo administra y supervisa el acceso, sino que también controla, configura y opera cada punto
de acceso.
Las dos subsecciones siguientes profundizan en cada solución WLAN para proporcionar la información
básica necesaria para planificar la implementación de una red de campus.
Solución WLAN independiente

La Figura 7-4 destaca un modelo típico para implementar la solución WLAN independiente en una
red de campus.
Como se indicó anteriormente, la solución WLAN independiente utiliza un punto de acceso independiente
(independiente) con administración y monitoreo centralizados a través de un WLSE. Además, esta solución
también utiliza servidores de control de acceso (ACS) en una configuración RADIUS o TACACS+ para el control de
acceso. Los servicios de dominio inalámbrico pueden proporcionarse para la gestión de frecuencias de radio y la
itinerancia segura. Los conmutadores de Cisco implementados en el campus pueden admitir alimentación de
Ethernet (POE) para alimentar los puntos de acceso. PoE se trata con más detalle más adelante en este capítulo.
WLSE ACS
WDS
Figura 7-4 Solución WLAN independiente
Dado que cada punto de acceso funciona de forma independiente en una solución independiente, los
puntos de acceso simplemente traducen los medios inalámbricos (denominados 802.11) a medios Ethernet
(802.3.) y envían las tramas al conmutador de Cisco. El conmutador de Cisco interpreta las tramas del punto
de acceso como cualquier otro Ethernet y cambia las tramas en consecuencia. En otras palabras, el punto de
acceso es relativamente transparente para el conmutador desde la perspectiva del tráfico.
Solución WLAN basada en controlador

Como se mencionó anteriormente, la solución basada en el controlador proporciona una operación centralizada en
comparación con una solución independiente. La Figura 7-5 ilustra los componentes de una solución WLAN basada
en controlador.
La definición de los dispositivos que se muestran en la Figura 7-5 como parte de una solución basada en controlador se
describe a continuación:
■ Puntos de acceso basados en controladores.
■ Infraestructura de red con enrutador y conmutadores. Los interruptores se pueden utilizar para suministrar
energía a los puntos de acceso (PoE).

LOC WCS ACS
WLC
Figura 7-5 Solución WLAN basada en controlador
■ Cisco Wireless LAN Controller (WLC) para el control, configuración y monitoreo de los
puntos de acceso.
■ Cisco Wireless Control System (WCS) para la gestión de WLAN (recomendado).
■ Dispositivo de ubicación inalámbrica de Cisco para el seguimiento de la ubicación (servidor de aplicaciones opcional).
■ Servidor de control de acceso seguro (ACS) de Cisco para seguridad y autenticación inalámbrica
mediante el protocolo RADIUS y TACACS+.
La solución basada en controlador divide el procesamiento de los protocolos inalámbricos 802.11

entre los puntos de acceso y un controlador de LAN inalámbrica (WLC) de Cisco centralizado. El
procesamiento de los protocolos de administración y datos 802.11 y la funcionalidad del punto de
acceso también se divide entre los puntos de acceso y el WLC. Aunque este proceso suena confuso, la
designación entre lo que administran los puntos de acceso y lo que administra el WLC es simple. La
mayor parte del tiempo, el punto de acceso gestiona las funciones críticas, mientras que el
controlador gestiona todas las demás funciones.
Nota En la solución de WLAN basada en controlador, el proceso de los protocolos inalámbricos 802.11 se
divide entre los puntos de acceso y un controlador centralizado de LAN inalámbrica de Cisco. El punto de
acceso gestiona las funciones de tiempo crítico, mientras que el controlador gestiona todas las demás
funciones.
Nota Dentro de las guías de diseño de la arquitectura inalámbrica, el concepto de dividir las
funciones de procesamiento de gestión y tramas entre el punto de acceso y el WLC se denomina
MAC dividida.
La Figura 7-6 ilustra el comportamiento del procesamiento dividido entre el punto de acceso y el
WLC.
Encapsulación CAPWAP/LWAPP
Mensajes de control
Tráfico de datos
Funciones MAC del punto de acceso:
802.11: balizas, respuestas de sondeo.

Funciones del controlador MAC:
Control 802.11: Reconocimiento y
transmisión de paquetes. Gestión MAC 802.11: Solicitudes y
802.11e: Cola de tramas y priorización acciones de asociación.
de paquetes. 802.11e: Reserva de recursos.
802.11i: Cifrado y descifrado de datos de la 802.11i: Autenticación y gestión
capa MAC. de claves.
Figura 7-6 Dividir MAC de la solución basada en controlador
Como se indica en la Figura 7-6, el punto de acceso maneja las partes del protocolo que tienen
requisitos en tiempo real para incluir lo siguiente:
■ Intercambio de tramas entre un cliente y un punto de acceso al transferir una

trama por aire
■ Transmisión de tramas de baliza
■ Almacenamiento en búfer y transmisión de tramas para clientes en operación de ahorro de energía
■ Respuesta a los marcos de solicitud de sondeo de los clientes
■ Reenvío de notificaciones de solicitudes de sondeo recibidas al controlador

■ Proporcionar información de calidad de señal en tiempo real al controlador con cada cuadro
recibido
■ Monitoreo de cada canal de radio en busca de ruido, interferencia y presencia de otras WLAN
■ Supervisión de la presencia de otros puntos de acceso
Toda la funcionalidad restante se maneja en Cisco WLC, donde la sensibilidad del tiempo no es una preocupación
y se requiere visibilidad de todo el controlador. Las funciones del WLC incluyen lo siguiente:
■ Autenticación y desautenticación 802.11
■ 802.11 asociación y reasociación (movilidad)
■ Puente y traducción de tramas 802.11
Las siguientes dos subsecciones se enfocan en el manejo del tráfico y el flujo del tráfico de las soluciones basadas en
controladores.
Manejo de tráfico en soluciones basadas en controladores
El manejo del tráfico en soluciones basadas en controladores es diferente a las soluciones independientes. Tenga
en cuenta las siguientes notas cuando planifique una implementación inalámbrica en una red de campus:
■ Los datos y los mensajes de control se encapsulan entre el punto de acceso y el controlador WLAN
utilizando el método Control y aprovisionamiento de puntos de acceso inalámbricos (CAPWAP) o el
Protocolo de punto de acceso ligero (LWAPP). Aunque ambos están basados en estándares,
LWAPP nunca fue adoptado por ningún otro proveedor que no sea Cisco.
■ El tráfico de control entre el punto de acceso y el controlador se encapsula con

LWAPP o CAPWAP y se cifra.
■ El tráfico de datos entre el punto de acceso y el controlador también se encapsula con LWAPP o
CAPWAP. El tráfico de datos no está encriptado. Se conmuta en el controlador de WLAN, donde
también se aplican el etiquetado de VLAN y la calidad de servicio (QoS).
■ El punto de acceso realiza el intercambio de tramas en tiempo real y ciertas partes en tiempo real de la
gestión de MAC. Todo el tráfico de datos del cliente se envía a través del controlador WLAN.
■ El controlador WLAN y el punto de acceso pueden estar en los mismos o diferentes dominios de transmisión y
subredes IP. Los puntos de acceso obtienen una dirección IP a través de DHCP y luego se unen a un controlador a
través de un mecanismo de descubrimiento CAPWAP o LWAPP.
La siguiente subsección analiza el flujo de tráfico en una solución basada en controlador.

Flujo de tráfico en una solución basada en controlador
Como se indicó anteriormente, todo el tráfico en una solución basada en controlador fluye a través del WLC. Por
ejemplo, la Figura 7-7 ilustra dos clientes que se comunican a través de una red inalámbrica en una solución
basada en controlador. Como se mencionó anteriormente en la Figura 7-6, el WLC generalmente se implementa
en la capa de distribución.
LOC WCS ACS
WLC
Tráfico de datos entre

los clientes inalámbricos fluyen a
través del controlador WLAN.
Figura 7-7 Flujo de tráfico en una solución basada en controlador
El tráfico entre las dos estaciones móviles inalámbricas se reenvía desde los puntos de acceso al controlador y
luego se envía a las estaciones móviles inalámbricas, respectivamente. Indica los flujos de tráfico al WLC y no
entre las estaciones móviles directamente. El conmutador de la red del campus simplemente cambia las tramas
de Ethernet y no es consciente de que las tramas finalmente terminan en un cliente inalámbrico.
Nota En resumen, el flujo de tráfico para clientes inalámbricos en una solución basada en controlador se realiza a través del
WLC, que difiere significativamente de una solución independiente en la que los puntos de acceso envían tráfico de forma
nativa.
Los controladores (WLC) en la solución basada en controladores generalmente se implementan en la capa de distribución.
Como se indicó anteriormente, los puntos de acceso generalmente se implementan en la capa de acceso, excepto donde
los límites físicos pueden requerir puntos de acceso adicionales en otras ubicaciones.
Puntos de acceso perimetral remotos híbridos (HREAP)

HREAP son útiles para proporcionar alta disponibilidad de soluciones inalámbricas basadas en controladores en
oficinas remotas. El propósito de estos puntos de acceso es seguir ofreciendo conectividad inalámbrica al
cliente cuando se pierde su conexión con el controlador (WLC). Un punto de acceso típico basado en
controlador siempre necesita conectividad con su controlador. Cuando se pierde esta conectividad, el punto de
acceso deja de ofrecer servicios inalámbricos y comienza a buscar otro controlador. Restaura los servicios
inalámbricos solo cuando ha recuperado la conectividad con un controlador.
Los HREAP son puntos de acceso basados en controladores. La principal diferencia con los puntos de acceso
estándar basados en controladores es que HREAP puede sobrevivir a la pérdida de conectividad con su
controlador. El HREAP vuelve a un modo cercano a un punto de acceso independiente y permanece para ofrecer
acceso inalámbrico a sus clientes inalámbricos.
La figura 7-8 ilustra el comportamiento de muestra de una solución HREAP.
Oficina principal
WiFi
Controlador
Remoto
LWAPP/CAPWAP Oficina
Control
Principal
Cambiar
Enlace WAN
En la zona
conmutado
Centralmente
Tronco o Datos del cliente
Puertos de acceso
conmutado
Datos del cliente
Figura 7-8 Ejemplo de una implementación HREAP
El HREAP generalmente se adapta a oficinas remotas donde solo se implementan uno o dos puntos de acceso; por lo
general, las oficinas remotas utilizan implementaciones inalámbricas solo para unos pocos puntos de acceso
porque el tamaño suele ser pequeño. Además, en una situación de oficina remota, el controlador no
es local sino que se accede a través de una conexión WAN. El HREAP también puede adaptarse a
oficinas pequeñas con un solo controlador y sin controlador de respaldo. La Figura 7-8 ilustra un
ejemplo de HREAP.
Nota Importante, planifique la implementación de HREAP para sitios remotos donde los puntos de acceso
redundantes son limitados.
Revisión de soluciones WLAN independientes y basadas en controlador

Las dos soluciones WLAN tienen diferentes características y ventajas. Obviamente, para implementaciones
inalámbricas a escala, la solución basada en controlador ofrece ventajas significativas en términos de
centralización de recursos. Según las guías de diseño inalámbrico de Cisco, cualquier red de campus con más
de 200 usuarios debe utilizar una solución basada en controlador para implementaciones inalámbricas.
La Tabla 7-1 destaca y revisa las principales diferencias que se deben tener en cuenta al planificar la implementación
de una red inalámbrica en la red del campus.
Tabla 7-1 Comparación de soluciones inalámbricas independientes y basadas en controladores
Ser único Basado en controlador
Punto de acceso IOS independiente IOS entregado basado en controlador
Configuración A través del punto de acceso A través del controlador
Operación Independiente Dependiente de WLC
Gestión y seguimiento Vía WLSE Vía WCS
Redundancia A través de múltiples puntos de acceso A través de múltiples WLAN
controladores
Recopilación de requisitos para planificar una implementación inalámbrica

La tecnología inalámbrica abarca el alcance de los temas tratados en este texto. Cualquier plan integral para una
implementación inalámbrica en una red de campus debe incluir el asesoramiento de un especialista o consultor
capacitado como práctica recomendada.
En resumen, puede usar la siguiente lista de requisitos inalámbricos como guía cuando trabaje con
especialistas o consultores al planificar una implementación inalámbrica:
■ Recopile los requisitos para determinar cuántos puertos de qué tipo se necesitan y cómo
deben configurarse.
■ Compruebe la red existente para verificar cómo se pueden integrar los requisitos en la implementación
existente. A menudo encontrará que, más allá del problema del recuento de puertos, el impacto en el ancho
de banda podría implicar conexiones adicionales.
■ Planifique el equipo adicional necesario para cumplir con los requisitos.
■ Implementación del plan.
■ Implementar nuevos componentes de red.
Además, debido a la naturaleza del comportamiento del punto de acceso, considere crear un plan de
prueba para verificar una implementación inalámbrica aceptable. En la revisión del comportamiento de
una conexión inicial de un cliente inalámbrico, primero detecta la red inalámbrica e intenta conectarse
en la Capa 2 (usando 802.11). Esta conexión puede implicar un diálogo 802.1X entre el punto de acceso
(en modo autónomo) o el controlador y un servidor AAA. Cuando se completa este paso, el cliente
inalámbrico intenta pasar a la Capa 3 y obtiene una dirección IP. El cliente inalámbrico entonces tiene
accesibilidad de IP a la red. Conocer estos pasos puede ayudarlo a solucionar problemas de conectividad
inalámbrica. Por ejemplo, si el controlador no puede comunicarse con el servidor RADIUS, es posible que
el cliente no se asocie a la red inalámbrica.
La siguiente lista ilustra una prueba de muestra para verificar una implementación inalámbrica que se puede usar
como guía para crear su propio plan de prueba:
■ ¿Puede comunicarse con el AP o el WLC desde las estaciones de administración?
■ ¿Puede el AP llegar al servidor DHCP?
■ ¿El AP obtiene una dirección IP del servidor DHCP?
■ ¿Puede el WLC comunicarse con el servidor Radius o TACACS+?
■ ¿El cliente obtiene una dirección IP?
■ ¿Puede el cliente acceder a servicios de red, servidor o Internet?
Planificación de la Red de Campus para Apoyo a la Voz
Los servicios de voz que se ejecutan junto con la red de datos en el campus se están convirtiendo en un estándar
de las redes empresariales sobre las redes de telefonía tradicionales por muchas razones. Como se discutió
anteriormente, el ahorro de costos es una razón importante para las implementaciones de voz en el campus.
Las implementaciones de voz en el campus a menudo se denominan implementaciones de VoIP porque, desde
una perspectiva tecnológica, la voz en la red del campus se ejecuta sobre TCP/IP. Sin embargo, el retorno de la
inversión (ROI) asociado con VoIP es significativo ya que VoIP requiere un costo inicial de puesta en marcha. Sin
embargo, el costo de puesta en marcha inicial se devolverá en ahorros de costos durante la vida útil de la
instalación de VoIP.
Desde el punto de vista de la planificación, debido a que los servicios de telefonía asociados con VoIP se ejecutan
en la red del campus, el tráfico de aplicaciones de voz y datos debe coexistir armoniosamente. Como tal, se deben
establecer mecanismos para diferenciar el tráfico y ofrecer un procesamiento prioritario para retrasar el tráfico de
voz sensible. Todos hemos experimentado la situación de mala calidad de audio, eco, inestabilidad y caída de
audio en nuestros teléfonos celulares. Sin una planificación cuidadosa, VoIP en la red del campus podría
experimentar comportamientos similares.
Para resolver el problema de la diferenciación, los switches de Cisco utilizan políticas de QoS para marcar y calificar el tráfico.
Además, los switches de Cisco pueden utilizar una VLAN específica para mantener el tráfico de voz separado
de otros datos para garantizar que se transporta a través de la red con un manejo especial y con un retraso
mínimo. A pesar de la configuración o implementación específica, se deben realizar consideraciones de diseño e
implementación para todos los conmutadores de campus que admitan VoIP.
Nota Como práctica recomendada, los diseños de implementación de voz deben incluir QoS, una VLAN independiente
para el tráfico de voz y alimentación a través de Ethernet (PoE).
Introducción a las Comunicaciones Unificadas

Como referencia al planificar la integración de VoIP en la red del campus, debe revisar toda la
arquitectura de VoIP. Cisco se refiere a su arquitectura y conjunto de productos VoIP y servicios
relacionados como Comunicaciones Unificadas. Las comunicaciones unificadas incluyen más
productos y servicios además del teléfono IP de Cisco. La Figura 7-9 ilustra los productos de la suite
Cisco Unified Communications.
Solicitud
Servidor
multipunto
Unidad de control
RTPC
Agente de llamadas
V
Enrutador/ IP
Puerta
Teléfono IP
Video conferencia
Estación
Figura 7-9 Componentes de comunicaciones unificadas
Los dispositivos de la Figura 7-9 se resumen de la siguiente manera:
■ Teléfono IP:Proporciona voz IP al escritorio.
■ Portero:Proporciona control de admisión de conexión (CAC), control y gestión del ancho de

banda y traducción de direcciones.
■ Puerta:Proporciona traducción entre redes VoIP y no VoIP, como la red telefónica pública
conmutada (PSTN). También proporciona acceso físico para dispositivos de voz analógicos
y digitales locales, como teléfonos, máquinas de fax, juegos de llaves y PBX.
■ Unidad de control multipunto:Proporciona conectividad en tiempo real para que los participantes en
múltiples ubicaciones asistan a la misma videoconferencia o reunión.
■ Agente de llamadas:Proporciona control de llamadas para teléfonos IP, CAC, control y gestión de ancho de
banda y traducción de direcciones de telefonía para direcciones IP o números de teléfono.
■ Servidor de aplicaciones:Proporciona servicios como correo de voz, mensajería unificada y

Consola de operadora de Cisco Unified Communications Manager.
■ Estación de videoconferencia:Proporciona acceso para la participación del usuario final en videoconferencias.
cing La estación de videoconferencia 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 secuencias de video y escuchar el audio que se origina
en una estación de usuario remota.
La implementación de Comunicaciones unificadas puede incluir componentes, como aplicaciones de

software de voz, sistemas de respuesta de voz interactiva (IVR) y softphones, que brindan servicios
adicionales para satisfacer las necesidades de comunicaciones de su implementación empresarial específica.
Para fines de planificación, una implementación de Comunicaciones Unificadas puede requerir la asistencia
de otros especialistas o consultores.
Requisitos de diseño de la red del campus para implementar VoIP

El tráfico de voz tiene requisitos de QoS extremadamente estrictos. El tráfico de voz generalmente genera una
demanda fluida de ancho de banda y tiene un impacto mínimo en el resto del tráfico, siempre que se gestione el
tráfico de voz.
Al planificar una implementación de VoIP, tenga en cuenta los siguientes requisitos de tráfico:
■ Los paquetes de voz son pequeños, típicamente entre 60 bytes y 120 bytes de tamaño.
■ VoIP no puede tolerar caídas o retrasos porque puede conducir a una mala calidad de voz.
■ VoIP usa UDP porque las capacidades de retransmisión de TCP son inútiles para la voz.
■ Específicamente, para una calidad de voz óptima, el retardo debe ser inferior a 150 ms en un sentido.
■ Aunque no es ideal ninguna pérdida de paquetes, la pérdida aceptable de paquetes es del 1 por ciento.
Los requisitos de QoS para el tráfico de datos varían mucho. Diferentes aplicaciones, como una aplicación de
recursos humanos frente a una aplicación de cajero automático, tienen diferentes demandas en la red.
Incluso diferentes versiones de la misma aplicación pueden tener diferentes características de tráfico de red.
El tráfico de datos puede mostrar una característica fluida o en ráfagas, según la aplicación, pero se
diferencia de la voz y el video en términos de retraso y sensibilidad a las caídas. Casi todas las
aplicaciones de datos pueden tolerar algún retraso y, en general, pueden tolerar altas tasas de caída. La
figura 7-10 ilustra las tasas de tráfico típicas de tráfico de voz frente al tráfico de aplicaciones.
Voz Datos
Liso Suave o Burst

Benigno Benigno o Codicioso
Sensible a caídas Gota insensible
Sensible al retardo Insensible a la demora
Prioridad UDP TCP retransmite
Figura 7-10 Comparación del tráfico de voz y datos
Nota En resumen, el tráfico de datos de usuario generalmente utiliza una cantidad variable y es inmune a la latencia y las caídas
de fotogramas promedio. Por el contrario, el tráfico de voz generalmente tiene un ancho de banda bajo pero es sensible a las
caídas de tramas y la latencia.
Debido a que el tráfico de datos puede tolerar caídas, las capacidades de retransmisión de TCP se vuelven importantes y,
como resultado, muchas aplicaciones de datos usan TCP. El tráfico de voz usa UDP porque no hay necesidad de retransmitir
fotogramas descartados ya que la voz es en tiempo real.
En las redes empresariales, las aplicaciones importantes (críticas para el negocio) suelen ser fáciles de
identificar. La mayoría de las aplicaciones se pueden identificar en función de los números de puerto TCP o UDP.
Algunas aplicaciones utilizan números de puerto dinámicos que, hasta cierto punto, dificultan las clasificaciones.
El software Cisco IOS admite el reconocimiento de aplicaciones basado en la red (NBAR), que se puede utilizar
para reconocer aplicaciones de puertos dinámicos.
En consecuencia, es importante planificar QoS en el campus para el tráfico de voz a fin de minimizar las caídas de
tráfico y la latencia en la red del campus. El tráfico de voz generalmente tiene un ancho de banda bajo en
comparación con el ancho de banda disponible en la red del campus.
Nota Al diseñar redes de campus con voz, planifique QoS para minimizar la latencia y las caídas de
tramas del tráfico de voz.
La aplicación de QoS ocurre en todo el campus según la configuración específica de QoS. La

sección "Comprensión de QoS" detalla la preparación e implementación de QoS. La siguiente
sección trata sobre la planificación de video en la red del campus.
Planificación de la Red de Campus para Video de Apoyo
Para los profesionales de redes, el video a menudo se ve solo como una aplicación de Capa 7. Bajo este
término genérico, se pueden agrupar muchos tipos diferentes de aplicaciones, cada una de las cuales tiene
su propio conjunto de especificaciones técnicas y de uso. Las aplicaciones de vídeo suelen verse como
intensivo en ancho de banda. Las aplicaciones que hacen un uso intensivo del ancho de banda se
denominan así porque envían una gran cantidad de tramas a la red. El contenido del marco juega un papel
importante en el consumo total de ancho de banda. El contenido del cuadro depende del tipo de aplicación
para la que se utiliza el vídeo.
Algunas aplicaciones de video son en tiempo real, como videoconferencia o TelePresence. La principal
preocupación de este tipo de vídeo es el tiempo real. Las tramas deben transitar sin demora y QoS es un
elemento crítico. La voz puede estar contenida en el flujo de video o enviarse como un flujo distinto.
Algunas otras aplicaciones de video no son tan sensibles a los problemas en tiempo real. Por lo general, son
flujos unidireccionales, en los que una estación cliente reproduce un flujo de video que se envía desde una
fuente. La estación del cliente puede amortiguar parte del flujo de video. La principal preocupación suele ser la
calidad, y la calidad depende de varios factores, como la resolución, la cantidad de fotogramas por segundo, el
tipo de códec, etc., que no dependen del diseño de la red del campus. Una aplicación práctica de las
transmisiones unidireccionales es el video a pedido que se usa con fines de capacitación.
Debido a que varias personas pueden recibir transmisiones de video unidireccionales simultáneamente, como en el caso
de ver una transmisión de video en vivo, la transmisión de video puede usar multidifusión para enviar el tráfico a varios
usuarios simultáneamente en lugar de enviar el tráfico a cada usuario de forma autónoma. La sección "Comprensión de la
multidifusión IP" analiza más este concepto. En resumen, considere la posibilidad de planificar la implementación de
multidifusión para cualquier aplicación que envíe tráfico a múltiples usuarios en relación con las transmisiones de video en
vivo.
Nota En resumen, las aplicaciones de video en tiempo real como TelePresence requieren un ancho de banda amplio para el
tráfico de video, QoS y alta disponibilidad para garantizar un tiempo de actividad del 99,9 por ciento. Tenga en cuenta que las
aplicaciones de video unidireccionales, como la capacitación a pedido, no son tan sensibles a la latencia y la fluctuación como el
video en tiempo real.
Tenga en cuenta que las aplicaciones de video en tiempo real suelen ser de igual a igual. Además, al planificar las
implementaciones, las aplicaciones de video se implementan en la capa de acceso como un punto final de voz o
datos.
Tráfico de voz y video

Debe comprender los perfiles de tráfico de voz y video asociados con las aplicaciones de video en
la red del campus. Estos perfiles de tráfico impulsan en última instancia el diseño de la red del
campus para una aplicación de voz o video.
Como se ilustra en la Figura 7-11, un flujo de video tiene características diferentes a las de un flujo de voz. El tráfico de
voz generalmente no requiere un uso intensivo del ancho de banda, pero requiere un ancho de banda constante. Por lo
general, se necesitarían enviar 50 paquetes de voz por segundo para voz, y cada paquete representa unos cientos de
bytes de datos de voz.
Debido a la naturaleza del algoritmo utilizado para codificar el flujo, el tráfico de video tiene un patrón diferente. El
tráfico suele ser a ráfagas, ya que cada imagen o grupo de imágenes necesita varios paquetes
para ser transmitido. Dependiendo de los cambios de una imagen a la siguiente, puede haber breves
intervalos de tiempo sin actividad en la red o ráfagas repentinas en las que es necesario cambiar toda la
imagen.
Paquetes de voz Paquetes de voz
1400 1400
Cuadros de vídeo
1000 1000
bytes
600 Audio 600

Muestras
200 200
20 ms 33 ms
Tiempo
Figura 7-11 Tráfico de voz versus tráfico de video
En general, las transmisiones de video en tiempo real generalmente consumen mucho ancho de banda y, a
menudo, tienen ráfagas, aunque generalmente no consumen todo el ancho de banda disponible. Considere
estas características al preparar la red del campus para video y voz.
Flujo de tráfico de video en la red del campus

El flujo de tráfico para aplicaciones de video, en el caso del video interactivo punto a punto, está cerca del
flujo de voz. En la Figura 7-12, dos estaciones de TelePresence (videoconferencia de alta definición) se
están comunicando. El flujo va de una estación al interruptor de acceso, luego al interruptor de
distribución, luego al interruptor central antes de llegar a la capa de distribución del segundo edificio y
luego al interruptor de acceso y la segunda estación. Este patrón está cerca del flujo de voz entre dos
teléfonos. Al igual que una llamada de voz, las estaciones de TelePresence pueden depender de un
servidor central desde donde se puede obtener información sobre la sesión. Una discusión detallada de
TelePresence está fuera del alcance de este libro; consulte Cisco.com para obtener más detalles.
El tráfico de datos no suele transitar de una estación a otra. Los clientes de datos generalmente se comunican con
los centros de datos para cargar o descargar datos. Las aplicaciones de transmisión de video tienen el mismo
comportamiento que los datos: recuperan información de los centros de datos y tienen poca o ninguna
interacción entre pares.
Centro de datos
Edificio 1 Edificio 2
Figura 7-12 Flujo de tráfico de vídeo
Como resultado, cuando planifique la integración de video en la red del campus, indique si se
implementarán las siguientes aplicaciones:
■ Aplicaciones punto a punto, como TelePresence
■ Aplicaciones de transmisión de video, como capacitación de video a pedido
■ Aplicaciones de tipo TV de vídeo, como Cisco IP TV
■ IPSaplicaciones de vigilancia para la seguridad
Denotar estas aplicaciones y hacer referencia al material de esta sección puede determinar los
requisitos de configuración y diseño de la red del campus.
Requisitos de Diseño de Voz, Datos y Video en la Red del Campus

La Tabla 7-2 detalla los requisitos de ancho de banda, demora, fluctuación, pérdida de paquetes,
disponibilidad, energía, seguridad y administración para planificar aplicaciones de voz, datos y video en la
red del campus.
Tabla 7-2 Revisión de requisitos de diseño para voz, datos y video
Requisito Datos Voz Video
Banda ancha Alto Bajo Alto
Demora Si es menos de unos pocos Menos de 150 ms Menos de 150 ms para

mseg, no aplicable vídeo en tiempo real
Estar nervioso No aplica Bajo Bajo
Paquete perdido Menos de 5% Menos que 1% Menos que 1%
Disponibilidad Alto Alto Alto
Potencia en línea No Opcional Opcional para seleccionar
dispositivos
Seguridad Alto Medio Bajo o Medio
Aprovisionamiento Esfuerzo medio Esfuerzo significativo Esfuerzo medio
En resumen, la tolerancia al retraso y la fluctuación del tráfico de video depende del tipo de flujo de video: Video en
tiempo real, comoVLas videoconferencias con voz integrada tienen las mismas limitaciones de retardo y fluctuación que el
tráfico de voz. Las transmisiones de video unidireccionales son menos sensibles a los problemas de retraso y fluctuación.
La mayoría de los dispositivos de reproducción de video pueden almacenar en búfer 5 segundos o más de flujo de video.
El tráfico de video también tiene poca tolerancia a la pérdida de paquetes. Si se pierden demasiados fotogramas, la
imagen no se actualiza correctamente y la experiencia del usuario se degrada. Una vez más, la calidad depende del
tipo de aplicación utilizada. La tolerancia a la pérdida de paquetes suele ser mayor para los flujos de video interactivo
en tiempo real de baja definición y velocidad lenta que para los flujos de video unidireccionales.
La siguiente sección analiza QoS, un requisito de la mayoría de los diseños de red de campus,
especialmente aquellos que integran voz y video.
Comprender la calidad del servicio
Los switches de Cisco brindan una amplia gama de funciones de QoS que satisfacen las necesidades de las
aplicaciones de voz, video y datos que comparten una sola red de campus. La tecnología Cisco QoS le
permite implementar redes complejas que administran servicios de manera predecible para una variedad
de aplicaciones en red y tipos de tráfico, incluidos voz y video.
Con funciones y servicios de QoS, puede diseñar e implementar redes que se ajusten al modelo
de servicios integrados (IntServ) del Grupo de trabajo de ingeniería de Internet (IETF) o
el modelo de servicios diferenciados (DiffServ). Los switches de Cisco brindan servicios diferenciados
mediante funciones de QoS, como clasificación y marcado, acondicionamiento de tráfico, prevención de
congestión y gestión de congestión.
Para un diseño de red de campus, la función de QoS en la red de campus es proporcionar las
siguientes características:
■ Control sobre los recursos:Usted tiene control sobre qué recursos de red (ancho de banda,
equipos, instalaciones de área amplia, etc.) se utilizan. Por ejemplo, el tráfico crítico, como voz,
video y datos, puede consumir un enlace y cada tipo de tráfico compite por el ancho de banda del
enlace. QoS ayuda a controlar el uso de los recursos (por ejemplo, eliminando paquetes de baja
prioridad), evitando así que el tráfico de baja prioridad monopolice el ancho de banda del enlace y
afecte el tráfico de alta prioridad, como el tráfico de voz.
■ Uso más eficiente de los recursos de la red:Mediante el uso de herramientas de administración y

contabilidad de análisis de red, puede determinar cómo se maneja el tráfico y qué tráfico experimenta
problemas de entrega. Si el tráfico no se maneja de manera óptima, puede usar las funciones de QoS
para ajustar el comportamiento del interruptor para flujos de tráfico específicos.
■ Servicios a medida:El control y la visibilidad proporcionados por QoS permiten que el servicio de Internet
proveedores de hielo para ofrecer grados de diferenciación de servicio cuidadosamente adaptados a sus
clientes. Por ejemplo, una aplicación de red empresarial interna puede ofrecer un servicio diferente para
un sitio web de pedidos que recibe de 3000 a 4000 visitas por día, en comparación con un sitio web de
recursos humanos que recibe solo de 200 a 300 visitas por día.
■ Coexistencia de aplicaciones de misión crítica:Las tecnologías QoS aseguran que las aplicaciones
de misión crítica que son más importantes para una empresa reciban el uso más eficiente de la
red. Las aplicaciones de voz y video sensibles al tiempo requieren ancho de banda y demoras
minimizadas, mientras que otras aplicaciones en un enlace reciben un servicio justo sin interferir
con el tráfico de misión crítica.
QoS proporciona soluciones para sus funciones definidas mediante la gestión de la congestión de la red. La
congestión afecta en gran medida las áreas problemáticas de disponibilidad y estabilidad de la red, pero la
congestión no es el único factor para estas áreas problemáticas. Todas las redes, incluidas aquellas sin congestión,
pueden experimentar los siguientes tres problemas de disponibilidad y estabilidad de la red:
■ Retraso (o latencia):La cantidad de tiempo que tarda un paquete en llegar a un destino
■ Variación de retardo (o jitter):El cambio en la latencia entre paquetes dentro de un flujo a lo largo del tiempo
■ Paquete perdido:La medida de los paquetes perdidos entre cualquier origen y destino dados
La latencia, la inestabilidad y la pérdida de paquetes pueden ocurrir incluso en redes conmutadas multicapa con un
ancho de banda adecuado. Como resultado, cada diseño de red conmutada multicapa debe planificar la QoS. Una
implementación de QoS bien diseñada ayuda a prevenir la pérdida de paquetes al tiempo que minimiza la latencia y
la inestabilidad.
Modelos de servicio QoS
Como se discutió en la sección anterior, las dos arquitecturas de QoS que se utilizan en las redes IP al
diseñar una solución de QoS son los modelos IntServ y DiffServ. Los modelos de servicio de QoS difieren
en dos características: cómo los modelos permiten que las aplicaciones envíen datos y cómo las redes
intentan entregar los datos respectivos con un nivel de servicio específico.
Un tercer método de servicio es el servicio de mejor esfuerzo, que es esencialmente el

comportamiento predeterminado del dispositivo de red sin QoS. En resumen, la siguiente lista
reafirma estos tres niveles básicos de servicio para QoS:
■ Servicio de mejor esfuerzo:La forma estándar de conectividad sin garantías. Este tipo de servicio, en
referencia a los switches Catalyst, utiliza colas FIFO (primero en entrar, primero en salir), que
simplemente transmite paquetes a medida que llegan a una cola sin tratamiento preferencial.
■ Servicios integrados:IntServ, también conocido como QoS duro, es una reserva de servicios. En otras
palabras, el modelo IntServ implica que los flujos de tráfico están reservados explícitamente por todos los
sistemas y recursos intermedios.
■ Servicios diferenciados:DiffServ, también conocido como QoS suave, se basa en clases, en el que
algunas clases de tráfico reciben un manejo preferencial sobre otras clases de tráfico. Los
servicios diferenciados usan preferencias estadísticas, no una garantía dura como los servicios
integrados. En otras palabras, DiffServ categoriza el tráfico y luego lo clasifica en colas de varias
eficiencias.
Desde la perspectiva del diseño de la red del campus, el servicio diferenciado es el método utilizado,
porque la mayoría de los conmutadores admiten DiffServ y no IntServ.
La figura 7-13 ilustra los componentes de cola de un conmutador Cisco. Estos componentes coinciden
con los componentes básicos de QoS en una red de campus. La figura ilustra la clasificación que se
produce en los paquetes de entrada. Después de que el conmutador clasifica un paquete, determina si
colocar el paquete en una cola o descartarlo. Los mecanismos de cola descartan paquetes solo si la cola
correspondiente está llena sin el uso de prevención de congestión.
Cola de transmisión
Procesamiento de paquetes QoS Colanorte
Paquete de ingreso Determinar cola 3 Paquete de salida

Clasificación Policía Marca
Cola de transmisión cola 2
La vigilancia puede descartar o reducir el paquete. cola 1
Gestión de la congestión
determina la programación de las
colas. La prevención de la congestión
gestiona el tráfico en las colas.
Figura 7-13Modelo de QoS de Cisco

Como se ilustra en la Figura 7-13, QoS en la red del campus tiene los siguientes componentes principales:
■ Clasificación y señalización del tráfico
■ Conformación de tráfico y vigilancia
■ Gestión de la congestión
■ Evitar la congestión
Las secciones posteriores de este capítulo analizan estos componentes de QoS y cómo se aplican a la red del
campus. La siguiente sección trata un tema secundario relacionado con la configuración de QoS que necesita
consideración de planificación.
AutoQoS
Como nota al margen de los componentes de QoS, Cisco AutoQoS es una característica del producto que permite
a los clientes implementar características de QoS para telefonía IP convergente y redes de datos de manera
mucho más rápida y eficiente. Cisco AutoQoS genera clases de tráfico y plantillas CLI de mapas de políticas. Cisco
AutoQoS simplifica la definición de clases de tráfico y la creación y configuración de políticas de tráfico. Como
resultado, no se requiere un conocimiento profundo de las tecnologías subyacentes, las políticas de servicio, los
mecanismos de eficiencia de enlace y las recomendaciones de mejores prácticas de QoS de Cisco para los
requisitos de voz para configurar Cisco AutoQoS.
Cisco AutoQoS puede ser extremadamente beneficioso para estos escenarios de planificación:
■ Pequeñas y medianas empresas que deben implementar telefonía IP rápidamente pero que carecen de la experiencia y
el personal necesarios para planificar e implementar servicios IP QoS
■ Grandes empresas de clientes que necesitan implementar soluciones de telefonía de Cisco a gran escala, al
tiempo que reducen los costos, la complejidad y el marco de tiempo para la implementación, y garantizan
que la QoS adecuada para las aplicaciones de voz se establezca de manera consistente
■ Empresas internacionales o proveedores de servicios que requieren QoS para VoIP donde existe poca
experiencia en diferentes regiones del mundo y donde el aprovisionamiento de QoS de forma remota y
en diferentes zonas horarias es difícil
Además, Cisco AutoQoS simplifica y acorta el ciclo de implementación de QoS. Cisco AutoQoS ayuda en
los siguientes cinco aspectos principales de una implementación exitosa de QoS:
■ Clasificación de aplicaciones
■ Generación de políticas
■ Configuración
■ Supervisión y presentación de informes
■ Consistencia
Auto-QoS se menciona en esta sección porque es útil saber que los switches de Cisco brindan una función
para facilitar la planificación, preparación e implementación de QoS al abstraer los detalles técnicos
detallados de QoS. Para obtener una configuración de muestra de QoS automático, consulte Cisco.com.
La siguiente sección comienza la discusión de la clasificación y señalización del tráfico.
Clasificación y Señalización del Tráfico
La clasificación y el marcado del tráfico determinan en última instancia la QoS aplicada a una trama. Los
bits especiales se utilizan en marcos para clasificar y marcar para QoS. Hay bits de QoS en el marco para
aplicaciones de Capa 2 y Capa 3. La siguiente subsección entra en la definición de estos bits para su
clasificación y marcado con más detalle.
DSCP, ToS y CoS

La Figura 7-14 ilustra los bits utilizados en los paquetes de Ethernet para la clasificación.
Los dispositivos de red utilizan bits de clase de servicio (CoS) de capa 2 de una trama o bits
de precedencia de IP de capa 3 y punto de código de servicios diferenciados (DSCP) de un
paquete para la clasificación. En la Capa 2, hay 3 bits disponibles en tramas 802.1Q para la
clasificación de hasta ocho valores distintos (niveles de servicio): 0 a 7. Estos bits de
clasificación de la Capa 2 se denominan valores CoS. En la Capa 3, QoS utiliza los seis bits
de ToS más significativos en el encabezado IP para una definición de campo DSCP. Esta
definición de campo de DSCP permite hasta 64 valores distintos (niveles de servicio), del 0
al 63, de clasificación en tramas IP. Los últimos 2 bits representan los bits de notificación
temprana de congestión (ECN). La precedencia de IP son solo los tres bits más significativos
del campo ToS. Como resultado,
Un ejemplo práctico de la interoperación entre DSCP y la precedencia de IP es con los teléfonos IP de Cisco. Los
teléfonos IP de Cisco marcan el tráfico de voz en la capa 3 con un valor DSCP de 46 y, en consecuencia, una
precedencia IP de 5. Debido a que los primeros 3 bits del valor DSCP 46 en binario son 101 (5), la precedencia IP
es 5. Como Como resultado, un dispositivo de red que solo conoce la precedencia de IP comprende la prioridad
del paquete de manera similar a un dispositivo de red que puede interpretar DSCP. Además, los teléfonos IP de
Cisco marcan tramas en la capa 2 con un valor de CoS de 5.
La Figura 7-15 ilustra el byte ToS. P2, P1 y P0 conforman la precedencia de IP. T3, T2, T1 y T0
son los bits ToS. Al ver el byte ToS como DSCP, DS5 a DS0 son los bits DSCP. Para obtener
más información sobre los bits del encabezado IP que determinan la clasificación, consulte
los RFC 791, 795 y 1349.
Nota El uso de valores DSCP para la clasificación de paquetes es el principal método de clasificación en todas
las redes de conmutación empresarial.
Paquete típico de Ethernet
Capa 2 Encabezado IP Datos

Encabezamiento
Trama 802.1Q de capa 2
Otro
Marco de inicio
Preámbulo AD SA Etiqueta
L2 Datos SFC
delimitador
hdrs
3 bits utilizados para CoS
(Prioridad de usuario)
Paquete IPv4 de capa 3
Versión Condiciones de servicio

Len Compensar/
IDENTIFICACIÓN TTL prototipo Suma de verificación IP-SA IP-DA Datos
Longitud (1 byte) Banderas
Precedencia de IP o DSCP
Precedencia de IP: 3 bits más significativos (MSB) de ToS
DSCP: 6 MSB de ToS
Figura 7-14 Bits utilizados en paquetes Ethernet para clasificación
Byte de ToS
P2 P1 P0 T3 T2 T1 T0 CU
DS5 DS4 DS3 DS2 DS1 DS0 ECN ECN
Campo DiffServ
Figura 7-15 Campo DiffServ en encabezado IP
Clasificación
La clasificación distingue una trama o paquete con una prioridad específica o criterios predeterminados. En el caso
de los switches Catalyst, la clasificación determina el valor DSCP interno en las tramas. Los switches Catalyst utilizan
este valor DSCP interno para el manejo de paquetes de QoS, incluidas las políticas y la programación a medida que
las tramas atraviesan el switch.
La primera tarea de cualquier política de QoS es identificar el tráfico que requiere clasificación. Con QoS habilitado y
sin otras configuraciones de QoS, todos los enrutadores y conmutadores de Cisco tratan el tráfico con una
clasificación predeterminada. Con respecto a los valores DSCP, la clasificación predeterminada para las tramas de
ingreso es un valor DSCP de 0. La terminología utilizada para describir una interfaz configurada para
el tratamiento de todas las tramas de entrada con un DSCP de 0 no es de confianza. En resumen, los siguientes métodos de
clasificación de paquetes están disponibles en los switches de Cisco:
■ Modos de confianza por interfaz
■ Clasificación manual por interfaz usando valores específicos de DSCP, IP Precedence o CoS
■ Por paquete basado en listas de acceso
■ Reconocimiento de aplicaciones basado en red (NBAR)
Al planificar implementaciones de QoS en redes de campus, siempre aplique la clasificación de QoS lo más
cerca posible del borde, preferiblemente en la capa de acceso. Esta metodología permite QoS de extremo
a extremo con facilidad de administración.
Nota Aplique las configuraciones de marcado y clasificación de QoS lo más cerca posible del borde,
preferiblemente en la capa de acceso.
Configuraciones y límites de confianza
Las configuraciones de confianza en los switches Catalyst cuantifican cómo se maneja una trama cuando
llega a un switch. Por ejemplo, cuando un conmutador configurado para "confiar en DSCP" recibe un
paquete con un valor DSCP de 46, el conmutador acepta el DSCP de entrada de la trama y utiliza el valor
DSCP de 46 para el DSCP interno.
Los switches de Cisco admiten la confianza a través de valores DSCP, IP Precedence o CoS en tramas de ingreso. Al
confiar en CoS o precedencia de IP, los switches de Cisco asignan la CoS o la precedencia de IP de un paquete de
ingreso a un valor DSCP interno. El concepto de DSCP interno es importante porque representa cómo se maneja el
paquete en el conmutador. Las tablas 7-3 y 7-4 ilustran las tablas de asignación predeterminadas para CoS a DSCP y
precedencia de IP a DSCP, respectivamente. Estas tablas de mapeo son configurables.
Tabla 7-3 Tabla de asignación predeterminada de CoS a DSCP
CoS 0 1 2 3 4 5 6 7
DSCP 0 8 dieciséis 24 32 40 48 56
Tabla 7-4 Tabla de asignación predeterminada de precedencia de IP a DSCP
IP 01234 5 6 7
Precedencia
DSCP 0 8 dieciséis 24 32 40 48 56
La figura 7-16 ilustra el concepto de confianza de QoS de Catalyst mediante la confianza de puertos. Cuando el
switch Catalyst confía en CoS en los paquetes de entrada por puerto, el switch asigna el valor de entrada al valor
DSCP respectivo. Cuando la configuración de QoS de la interfaz de ingreso no es de confianza, el switch usa 0
para el valor DSCP interno para todos los paquetes de ingreso.
Confianza
Catalizador de límites
Cambiar
CoS = 5
De confianza: DSCP interno = 40 (asignado desde CoS = 5)
Anfitrión
No confiable: DSCP interno = 0 (asignado desde CoS = 0)
Figura 7-16 Concepto de confianza QoS
Calificación
El marcado en referencia a QoS en los switches Catalyst se refiere a cambiar los bits de DSCP, CoS o IP
Precedence en las tramas de ingreso. El marcado se puede configurar por interfaz o mediante un mapa de
políticas. El marcado altera el valor DSCP de los paquetes, lo que a su vez afecta el DSCP interno. Por
ejemplo, un ejemplo de marcado sería configurar un mapa de políticas para marcar todos los fotogramas
de un servidor de video por interfaz a un valor DSCP de 40, lo que resulta en un valor DSCP interno de 40
también.
Modelado y vigilancia del tráfico

Tanto los mecanismos de configuración como los de vigilancia controlan la velocidad a la que fluye el tráfico a través
de un conmutador. Ambos mecanismos utilizan la clasificación para diferenciar el tráfico. Sin embargo, existe una
diferencia fundamental y significativa entre dar forma y vigilar.
Dar forma a los índices de tráfico de los medidores y demoras (amortiguadores) del tráfico excesivo para que los índices
de tráfico se mantengan dentro de un límite de índice deseado. Como resultado, la configuración suaviza las ráfagas
excesivas para producir un flujo constante de datos. La reducción de las ráfagas disminuye la congestión en los
enrutadores y conmutadores descendentes y, en consecuencia, reduce la cantidad de tramas descartadas por los
enrutadores y conmutadores descendentes. Debido a que el modelado retrasa el tráfico, no es útil para flujos de tráfico
sensibles a los retrasos, como voz, video o almacenamiento, pero es útil para flujos de TCP típicos en ráfagas. La Figura
7-17 ilustra un ejemplo de modelado de tráfico aplicado al tráfico de datos TCP.
Línea Sin modelado de tráfico

Tasa
Con modelado de tráfico
Conformado
Tasa
El modelado del tráfico limita la tasa de transmisión a la tasa de forma configurada y suaviza
ráfagas comúnmente encontradas con aplicaciones TCP.
Figura 7-17 Modelado de tráfico aplicado al tráfico TCP

Para obtener más información sobre qué switches de Cisco admiten la configuración y las pautas de configuración
para la configuración, consulte el sitio web Cisco.com. En las redes de campus, la vigilancia se usa más
comúnmente y es ampliamente compatible en las plataformas de Cisco en comparación con la configuración.
Vigilancia
En contraste con la configuración, la vigilancia toma una acción específica para el tráfico fuera de perfil por
encima de una tasa específica. La vigilancia no retrasa ni amortigua el tráfico. La acción para el tráfico que
excede una tasa específica generalmente es descartar; sin embargo, se permiten otras acciones, como confiar y
marcar.
La vigilancia de los switches de Cisco sigue el algoritmo de cubeta de fichas con fugas, que permite ráfagas de
tráfico en comparación con la limitación de velocidad. El algoritmo de balde de fichas con fugas es tan efectivo en
el manejo de TCP como en el manejo de ráfagas de flujos UDP. La figura 7-18 ilustra el algoritmo del balde de
fichas con fugas.
Fichas entrantes
Fuera de perfil
fichas
ExplosiónTamaño
Fichas en perfil
Fuga en
FijadoTasa
Figura 7-18 Cubo de fichas con fugas
Cuando los switches aplican vigilancia al tráfico entrante, colocan una cantidad de tokens proporcional al
tamaño de los paquetes de tráfico entrante en un depósito de tokens en el que la cantidad de tokens es
igual al tamaño del paquete. A intervalos regulares, el conmutador elimina una cantidad definida de tokens,
determinada por la tasa configurada, del depósito. Si el contenedor está lleno y no puede acomodar un
paquete de ingreso, el conmutador determina que el paquete está fuera de perfil. Posteriormente, el
conmutador elimina o marca los paquetes fuera de perfil de acuerdo con la acción de vigilancia configurada,
pero observe que la cantidad de paquetes que salen del
la cola es proporcional al número de tokens en el cubo.
Tenga en cuenta que el balde con fugas es solo un modelo para explicar las diferencias entre vigilancia y
modelado.
Una discusión completa del algoritmo del balde de fichas con fugas está fuera del alcance de este libro.
Las siguientes secciones discuten la gestión de la congestión y la evitación de la congestión. La gestión de la

congestión es la característica clave de QoS.
Gestión de la congestión
Los switches de Cisco utilizan múltiples colas de salida para la aplicación de las funciones de QoS de
gestión de congestión y prevención de congestión. Tanto la gestión de la congestión como la prevención
de la congestión son una función por cola. Por ejemplo, las configuraciones del umbral para evitar la
congestión son por cola, y cada cola puede tener su propia configuración para la gestión y prevención
de la congestión.
Además, la clasificación y el marcado tienen poco sentido sin la gestión de la congestión. Los conmutadores
utilizan configuraciones de gestión de congestión para programar los paquetes de forma adecuada desde las
colas de salida cuando se produce la congestión. Los switches de Cisco admiten una variedad de algoritmos de
programación y colas. Cada algoritmo de cola resuelve un tipo específico de condición de tráfico de red.
La gestión de la congestión comprende varios mecanismos de cola, incluidos los siguientes:
■ Cola FIFO
■ Cola por turnos ponderados (WRR)
■ Cola de prioridad
■ Cola personalizada
Las siguientes subsecciones analizan estos mecanismos de cola con más detalle.
Cola FIFO
El método predeterminado de poner en cola las tramas es la cola FIFO, en la que el conmutador coloca
todas las tramas de salida en la misma cola, independientemente de la clasificación. Esencialmente, la cola
FIFO no usa clasificación y todos los paquetes se tratan como si pertenecieran a la misma clase. El
conmutador programa los paquetes de la cola para su transmisión en el orden en que se reciben. Este
comportamiento es el comportamiento predeterminado de los switches Cisco sin QoS
activado. La figura 7-19 ilustra el comportamiento de la cola FIFO.
Cola ponderada de todos contra todos

La programación de paquetes de las colas de salida mediante WRR es un método sencillo y popular para
diferenciar el servicio entre las clases de tráfico. Con WRR, el conmutador utiliza un valor de peso
configurado para cada cola de salida. Este valor de peso determina el ancho de banda implícito de cada
cola. Cuanto mayor sea el valor de ponderación, mayor será la prioridad que el conmutador aplica a la
cola de salida. Por ejemplo, considere el caso de un conmutador Cisco configurado para QoS y WRR. En
este ejemplo, los switches de Cisco utilizan cuatro colas de salida. Si las colas 1
a 4 están configurados con pesos 50, 10, 25 y 15, respectivamente, la Cola 1 puede utilizar el 50 por
ciento del ancho de banda cuando hay congestión. Las colas 2 a 4 pueden utilizar el 10, 25 y 15 por
ciento del ancho de banda, respectivamente, cuando existe congestión. La Figura 7-20 ilustra el
comportamiento de WRR con ocho colas de salida. La figura 7-20 también ilustra las propiedades de
caída de cola y WRED, que se explican en secciones posteriores.
Paquetes reenviados
Sistema de cola FIFO Hardware

Sistema de colas
Todo en uno FIFO
Cola caída de cola cola 1 programador Equipo Q Interfaz
Los enrutadores atienden los

paquetes por orden de llegada.
FIFO utiliza una sola cola.
Los paquetes recién llegados se

eliminan si la cola está llena.
Todos los paquetes son
clasificados en una clase.
Figura 7-19 Cola FIFO
Paquetes reenviados
Clase 1 caída de cola cola 1

WRED
caída de cola
Clase 2 cola 2
WRED Modificado
Hardware
Ponderado Sistema de colas
Redondo
o travesaño Interfaz
Robin Cambio de tela
(WRR)
caída de cola
Clase 8? cola 8
WRED
Figura 7-20 Round Robin Ponderado
La proporción de la cola de transmisión determina la forma en que los búferes se dividen entre las
diferentes colas. Si tiene varias colas con una cola de prioridad, la configuración requiere el mismo peso
en las colas WRR de alta prioridad y para la cola de prioridad estricta. En general, las colas de alta
prioridad no requieren una gran cantidad de memoria para la cola.
porque el tráfico destinado a las colas de alta prioridad es sensible a los retrasos y, a menudo, de bajo
volumen. Como resultado, los tamaños de cola grandes para las colas de prioridad alta y estricta no son
necesarios. La recomendación es usar espacio de memoria para las colas de baja prioridad que
generalmente contienen tráfico de datos que no es sensible a los retrasos en la cola. La siguiente sección
analiza la cola de prioridad estricta con WRR.
Aunque las colas utilizan un porcentaje del ancho de banda, el conmutador en realidad no asigna un ancho
de banda específico a cada cola cuando usa WRR. El conmutador utiliza WRR para programar paquetes de
colas de salida solo en condiciones de congestión. Otro aspecto digno de mención de WRR es que no priva a
las colas de menor prioridad porque el conmutador atiende todas las colas durante un período de tiempo
finito.
Cola de prioridad
Un método para priorizar y programar tramas de las colas de salida es utilizar colas de prioridad. Al
aplicar prioridad estricta a una de estas colas, el conmutador programa tramas de esa cola si hay
tramas en esa cola antes de dar servicio a cualquier otra cola. Los switches de Cisco ignoran los pesos
de programación de WRR para las colas configuradas como colas prioritarias; la mayoría de los switches
Catalyst admiten la designación de una única cola de salida como cola de prioridad.
La cola de prioridad es útil para las aplicaciones de voz en las que el tráfico de voz ocupa la cola de prioridad.
Sin embargo, dado que este tipo de programación puede resultar en el agotamiento de la cola en las colas
no prioritarias, las colas restantes están sujetas a la cola WRR para evitar este problema.
Cola personalizada
Otro método de cola disponible en los switches de Cisco estrictamente para interfaces WAN es Custom
Queuing (CQ), que reserva un porcentaje del ancho de banda disponible para una interfaz para cada
tipo de tráfico seleccionado. Si un tipo particular de tráfico no usa el ancho de banda reservado, otras
colas y tipos de tráfico pueden usar el ancho de banda restante.
CQ está configurado estáticamente y no proporciona una adaptación automática para las condiciones cambiantes de la
red. Además, no se recomienda CQ en interfaces WAN de alta velocidad; consulte las guías de configuración para conocer
la compatibilidad con CQ en las interfaces LAN y los detalles de configuración. Consulte la guía de configuración de cada
conmutador de Cisco para conocer las configuraciones de CQ admitidas.
Prevención de la congestión
Las técnicas para evitar la congestión monitorean las cargas de tráfico de la red en un esfuerzo por anticipar y
evitar la congestión en los puntos de cuello de botella comunes de la red. Los conmutadores y los enrutadores
logran evitar la congestión mediante la eliminación de paquetes utilizando algoritmos complejos (frente al
algoritmo simple de eliminación de cola). Las redes de campus suelen utilizar técnicas para evitar la congestión
en las interfaces WAN (frente a las interfaces Ethernet) debido al ancho de banda limitado de las interfaces WAN.
Sin embargo, para las interfaces Ethernet con una congestión considerable, es útil evitar la congestión.
caída de cola
Cuando una interfaz de un enrutador o conmutador no puede transmitir un paquete inmediatamente debido a la
congestión, el enrutador o conmutador pone en cola el paquete. El enrutador o conmutador finalmente transmite el
paquete desde la cola. Si la tasa de llegada de los paquetes para la transmisión en una interfaz supera la capacidad
del enrutador o del conmutador para amortiguar el tráfico, el enrutador o el conmutador simplemente descarta los
paquetes. Este comportamiento se denomina caída de cola porque todos los paquetes para transmisión que
intentan ingresar a una cola de salida se descartan hasta que haya espacio en la cola para otro paquete. Tail drop es
el comportamiento predeterminado en las interfaces de switch de Cisco.
Para entornos con una gran cantidad de flujos TCP o flujos donde las caídas arbitrarias de paquetes son
perjudiciales, la caída de cola no es el mejor enfoque para descartar tramas. Además, tail drop tiene estas
deficiencias con respecto a los flujos de TCP:
■ La eliminación de tramas suele afectar a las sesiones TCP en curso. La caída arbitraria de tramas con una
sesión TCP da como resultado que las sesiones TCP simultáneas retrocedan y se reinicien
simultáneamente, produciendo un efecto de "diente de sierra". Como resultado, se produce una utilización
ineficiente del enlace en el punto de congestión (sincronización global TCP).
■ Los flujos de TCP agresivos pueden apoderarse de todo el espacio en las colas de salida sobre el flujo de TCP normal como
resultado de la caída de la cola.
■ La cola excesiva de paquetes en las colas de salida en el punto de congestión da como resultado retrasos y
fluctuaciones mientras los paquetes esperan la transmisión.
■ No existe un mecanismo de caída diferenciado; el tráfico premium se elimina de la misma manera que el
tráfico de mejor esfuerzo.
■ Incluso en el caso de un solo flujo TCP a través de una interfaz, la presencia de otro tráfico que no sea
TCP podría congestionar la interfaz. En este escenario, la respuesta al protocolo TCP es deficiente;
como resultado, TCP no puede adaptarse adecuadamente a la red congestionada.
Detección temprana aleatoria ponderada
WRED es un mecanismo para evitar la congestión que es útil para las velocidades de la red troncal. WRED intenta
evitar la congestión descartando aleatoriamente paquetes con una determinada clasificación cuando los búferes de
salida alcanzan un umbral específico.
La Figura 7-21 ilustra el comportamiento de TCP con y sin RED. Como se ilustra en el diagrama, RED
suaviza las sesiones de TCP porque descarta paquetes aleatoriamente, lo que en última instancia
reduce las ventanas de TCP. Sin RED, los flujos de TCP pasan por un comienzo lento simultáneamente.
El resultado final de RED es una mejor utilización del enlace.
antes de ROJO Después de ROJO
Enlace promedio
Enlace promedio Utilización
Utilización
Fila A Fila A
Fila B Fila B
Fila C Fila C
– La sincronización de TCP evita la utilización promedio del - La utilización promedio del enlace está mucho más cerca del ancho
enlace cerca del ancho de banda del enlace. de banda del enlace.
- Las caídas de cola hacen que las sesiones TCP tengan - Las caídas aleatorias de RED hacen que las sesiones TCP
un inicio lento. reduzcan el tamaño de las ventanas.
Figura 7-21 Optimizaciones de utilización de enlaces con evitación de congestión
RED suelta aleatoriamente paquetes en los valores de umbral configurados (porcentaje completo) de los búferes
de salida. A medida que más paquetes llenan las colas de salida, el conmutador elimina marcos aleatoriamente
en un intento de evitar la congestión sin el problema del TCP de diente de sierra. RED funciona solo cuando la
cola de salida no está llena; cuando la cola de salida está llena, el conmutador descarta cualquier paquete
adicional que intente ocupar la cola de salida. Sin embargo, la probabilidad de descartar un paquete aumenta a
medida que la cola de salida comienza a llenarse por encima del umbral ROJO.
RED funciona bien para flujos TCP, pero no para otros tipos de tráfico, como flujos UDP y tráfico de
voz. WRED es similar a RED excepto que WRED tiene en cuenta la clasificación de los marcos. Por
ejemplo, para una sola cola de salida, la configuración de un conmutador podría consistir en un
umbral WRED del 50 por ciento para todo el tráfico de mejor esfuerzo para valores DSCP de hasta 20 y
el 80 por ciento para todo el tráfico con un valor DSCP entre 20 y 31. En En este ejemplo, el
conmutador elimina los paquetes existentes en la cola de salida con un DSCP de 0 a 20 cuando el
umbral de la cola alcanza el 50 por ciento. Si la cola continúa llenándose hasta el umbral del 80 por
ciento, el conmutador comienza a eliminar los paquetes existentes con valores de DSCP superiores a
20. Si la cola de salida está llena incluso con WRED configurado, el conmutador descarta cualquier
paquete adicional que intente ocupar el cola de salida El resultado final de la configuración WRED es
que es menos probable que el conmutador descarte paquetes con prioridades más altas (valor DSCP
más alto). La figura 7-22 ilustra gráficamente el algoritmo WRED.
En la mayoría de los conmutadores de Cisco, WRED se puede configurar por cola. Sin embargo, es
posible usar WRR y WRED juntos. Una recomendación de mejores prácticas es designar una cola de
prioridad estricta para el tráfico de alta prioridad usando WRR y usar WRED para evitar la congestión
con las colas restantes designadas para el tráfico de datos.
Para la planificación de la red del campus, considere usar WRED en interfaces altamente congestionadas,
particularmente las interfaces WAN que interconectan los centros de datos.
Calcular Promedio
Tamaño de cola Actual
Cola
Tamaño
No
Paquete IP WRED Cola Cola FIFO
¿Lleno?
Precedencia de IP
o Sí
DSCP
Seleccionar
WRED
Perfil • Umbral mínimo
Caída aleatoria caída de cola
• Umbral máximo
• Máxima probabilidad
Denominador
Figura 7-22 Detección temprana aleatoria ponderada
Implementando IP Multicast en la Red del Campus

Está aumentando la demanda de aplicaciones de Internet, intranet y multimedia en las que un
remitente transmite a un grupo de receptores simultáneamente. Ejemplos de estas aplicaciones
incluyen lo siguiente:
■ Transmitir un mensaje corporativo a todos los empleados
■ Difusión de video y audio, incluido video interactivo para aprendizaje a distancia e IPTV
■ Transmisión de datos desde un almacén de datos centralizado a varios departamentos
■ Comunicar cotizaciones de acciones a los corredores
■ Informática colaborativa
■ Aplicaciones algorítmicas de parqué que utilizan computación en la nube
Posteriormente, el uso de multidifusión IP en lugar de unidifusión para distribuir esta información reduce la
carga general de la red y el consumo de ancho de banda. Esto es el resultado de la distribución simultánea de
una trama de datos IP de multidifusión IP a un grupo de host que está definido por una única dirección IP o
flujo de multidifusión. Para lograr esta misma distribución con unidifusión, sería necesario que la fuente envíe
una trama de unidifusión a cada host de forma independiente.
Nota La multidifusión reduce la carga general de la red y el ancho de banda al distribuir el tráfico a múltiples
usuarios finales simultáneamente.
Esta sección analiza el enrutamiento de multidifusión IP y sus ventajas inherentes, funcionalidad y

configuración en la red del campus. Este capítulo comienza con una introducción a la multidifusión y
luego analiza los fundamentos de la multidifusión IP. Este capítulo también trata sobre la
importantes protocolos de multidifusión de capa 3 y capa 2 y la recomendación de diseño para

implementar multidifusión en redes conmutadas multicapa.
Introducción a la multidifusión IP
Las aplicaciones multimedia ofrecen la integración de sonido, gráficos, animación, texto y video. A medida
que las formas de realizar negocios se han vuelto más complejas, este tipo de aplicaciones se han vuelto
cada vez más populares en las redes empresariales. Sin embargo,
aplicar varias aplicaciones multimedia en una red conmutada multicapa y enviar los flujos
multimedia a través de una red de datos del campus es un proceso complicado debido al
consumo de ancho de banda en la red.
El tráfico multimedia utiliza uno de los siguientes métodos de transmisión, cada uno de los cuales tiene un efecto
diferente en el ancho de banda de la red:
■ Unidifusión:Con un diseño de unidifusión, una aplicación envía una copia de cada paquete a la dirección
de unidifusión de cada cliente. Como resultado, la transmisión de unidifusión tiene restricciones de
escala significativas. Si el grupo es grande, la misma información debe transportarse varias veces, incluso
en enlaces compartidos.
■ Transmisión:En un diseño de difusión, una aplicación envía solo una copia de cada paquete mediante una
dirección de difusión. La transmisión de un paquete a todos los dispositivos es ineficiente, excepto en el
caso en que solo un pequeño subconjunto de la red realmente necesite ver el paquete. La transmisión
multimedia se dispersa por toda la red de manera similar al tráfico de transmisión normal en el sentido de
que cada dispositivo host debe procesar la trama de datos de transmisión multimedia. Sin embargo, a
diferencia de los marcos de transmisión estándar, que generalmente son pequeños, las transmisiones
multimedia pueden alcanzar velocidades de datos de hasta 13 Mbps o más. Incluso si una estación final no
utiliza aplicaciones multimedia, el dispositivo sigue procesando el tráfico de difusión. Este requisito podría
utilizar la mayor parte, si no todo, el ancho de banda asignado para cada dispositivo. Por esta razón, Cisco
desaconseja encarecidamente la implementación de difusión para aplicaciones que entregan datos,
■ multidifusión:La solución más eficiente para transmitir aplicaciones multimedia es

la multidifusión, que se encuentra entre la unidifusión y la difusión. En la
transmisión de multidifusión, un servidor multimedia envía una copia de cada
paquete a una dirección especial que representa a varios clientes. A diferencia del
entorno de unidifusión, un servidor de multidifusión envía un único flujo de datos
a varios clientes. A diferencia del entorno de difusión, el dispositivo cliente decide
si escucha la dirección de multidifusión. La multidifusión ahorra ancho de banda y
controla el tráfico de la red al obligar a la red a reenviar paquetes solo cuando es
necesario. Al eliminar la redundancia del tráfico, la multidifusión reduce el
consumo de ancho de banda de la red y el procesamiento del host. Además,
La multidifusión IP es la transmisión de un paquete de datos IP a un grupo de host que está definido por una
única dirección IP llamada dirección IP de multidifusión. Un host puede unirse o dejar la IP de multidifusión
agrupar dinámicamente independientemente de la ubicación o el número de miembros. Una característica importante de la
multidifusión es su capacidad para limitar la variación en el tiempo de entrega (fluctuación) de las tramas de multidifusión IP a
lo largo de la ruta completa del servidor al cliente.
En la Figura 7-23, el servidor de video transmite un solo flujo de video para cada grupo de multidifusión. Un grupo de
multidifusión o host se define como un conjunto de dispositivos host que escuchan una dirección de multidifusión
específica. Los enrutadores y conmutadores de Cisco replican el flujo de video según sea necesario para los grupos
de host que se encuentran en la ruta. Esta técnica permite que un número arbitrario de clientes se suscriba a la
dirección de multidifusión y reciba la transmisión. Un host puede ser parte de uno o más grupos de multidifusión
para múltiples aplicaciones. Además, los enrutadores pueden transmitir múltiples flujos de datos para diferentes
aplicaciones para una sola dirección de grupo.
1,5Mbps
Video
Servidor
1,5Mbps 1,5Mbps
1,5Mbps 1,5Mbps 1,5Mbps
Receptor Receptor Receptor No un

Receptor
Figura 7-23 Tráfico de multidifusión
En el escenario de multidifusión que se muestra en la Figura 7-23, solo se utilizan 1,5 Mbps de ancho de banda de
servidor a red, lo que deja el ancho de banda restante libre para otros usos.
Nota En un escenario de unidifusión, el servidor secuencia a través de una transmisión de múltiples copias de los datos, por lo
que la variabilidad en el tiempo de entrega es grande, especialmente para transmisiones grandes o listas de distribución
grandes.
La multidifusión de IP se basa en el concepto de una dirección de grupo virtual denominada dirección IP de

multidifusión. En el enrutamiento de unidifusión IP, un paquete se enruta desde una dirección de origen a una
dirección de destino, atravesando la red IP salto por salto. En la multidifusión IP, la dirección de destino del
paquete no se asigna a un solo destino. En cambio, los receptores se unen a un grupo; cuando lo hacen, los
paquetes dirigidos a ese grupo comienzan a fluir hacia ellos. todos los miembros de
el grupo recibe el paquete; un host debe ser miembro del grupo para recibir el paquete. Las fuentes de
multidifusión no necesitan ser miembros de ese grupo. En la figura 7-24, los paquetes enviados por el miembro
3 del grupo (representado por las flechas sólidas) son recibidos por los miembros 1 y 2 del grupo, pero no por el
que no es miembro del grupo. El host que no es miembro también puede enviar paquetes (representados por
las flechas punteadas) al grupo de multidifusión que reciben los tres miembros del grupo porque todos los
nuevos hosts son miembros del grupo de multidifusión. Los miembros del grupo 1 y 2 no envían paquetes de
multidifusión; ellos son solo los receptores.
Fuente y
Receptor
Grupo
Miembro 3
Fuente
A B D
Grupo
No es miembro
C mi
Grupo Grupo
Miembro 1 Miembro 2
receptores
Figura 7-24 Membresía de grupo de multidifusión
El tráfico de multidifusión IP utiliza UDP como protocolo de capa de transporte. A diferencia de TCP, UDP no agrega
funciones de confiabilidad, control de flujo o recuperación de errores a IP. Debido a la simplicidad de UDP, los
encabezados de los paquetes de datos contienen menos bytes y consumen menos sobrecarga de red que TCP.
Debido a que la ubicación de los hosts en el grupo está muy extendida en la red, el enrutador de multidifusión
envía los paquetes a las respectivas interfaces múltiples para llegar a todos los hosts. Esto hace que el reenvío de
multidifusión sea más complejo. Para evitar la duplicación, varios protocolos de enrutamiento de multidifusión
utilizan el reenvío de ruta inversa (RPF), que se analiza en la sección "Reenvío de ruta inversa", más adelante en
este capítulo.
Esta sección analiza los siguientes fundamentos de la multidifusión IP con más detalle:
■ Estructura de direcciones IP de multidifusión
■ Estructura de direcciones MAC de multidifusión

■ Reenvío de ruta inversa
■ Árbol de reenvío de multidifusión
Estructura de direcciones IP de multidifusión
El rango de direcciones IP se divide en clases según los bits de orden superior de una dirección IP de 32 bits. La
multidifusión IP utiliza las direcciones de Clase D, que van desde 224.0.0.0 hasta 239.255.255.255. Estas
direcciones consisten en 1110 binarios como los bits más significativos (MSB) en el primer octeto, seguidos de
una dirección de grupo de 28 bits, como se muestra en la Figura 7-25. A diferencia de las direcciones IP de
clase A, B y C, los últimos 28 bits de una dirección de clase D no están estructurados.
primeros 4 bits
28 bits
Clase D 1 1 1 0 ID de grupo de multidifusión
Figura 7-25 Estructura de direcciones IP de multidifusión
Estos 28 bits restantes de la dirección IP identifican la ID del grupo de multidifusión, que es una dirección única
que normalmente se escribe como números decimales en el rango de 224.0.0.0 a 239.255.255.255. La
Autoridad de Números Asignados de Internet (IANA) controla la asignación de direcciones IP de multidifusión.
El rango de direcciones de Clase D se usa solo para la dirección de grupo o la dirección de destino del tráfico de
multidifusión IP. La dirección de origen de los datagramas de multidifusión es siempre la dirección de origen
de unidifusión.
Las direcciones IP de multidifusión especifican un conjunto de hosts IP que se han unido a un grupo y están interesados en
recibir tráfico de multidifusión designado para ese grupo en particular. La Tabla 7-5 describe las convenciones de direcciones
de multidifusión IP.
Las aplicaciones asignan direcciones de multidifusión de forma dinámica o estática. El direccionamiento dinámico de
multidifusión proporciona a las aplicaciones una dirección de grupo bajo demanda. Debido a que las direcciones dinámicas
de multidifusión tienen una vida útil específica, las aplicaciones deben solicitar este tipo de dirección solo durante el tiempo
que se necesite.
Tabla 7-5 Intervalos de direcciones IP de multidifusión
Descripción Rango
Direcciones locales de enlaces reservados 224.0.0.0 a 224.0.0.255
Direcciones de alcance global 224.0.1.0 a 238.255.255.255
Direcciones de multidifusión específicas de la fuente 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

Las direcciones de multidifusión asignadas estáticamente están reservadas para protocolos específicos que
requieren direcciones conocidas, como Open Shortest Path First (OSPF). IANA asigna estas direcciones
conocidas, que se denominan grupos de host permanentes y son similares en concepto a los números de
puerto TCP y UDP conocidos.
Las siguientes secciones discuten los detalles de las direcciones de multidifusión enumeradas en la Tabla 7-5.
Direcciones locales de enlaces reservados
IANA ha reservado direcciones en el rango 224.0.0.0 a 224.0.0.255 (direcciones de destino local de enlace) para
ser utilizadas por protocolos de red en un segmento de red local. Los enrutadores no reenvían paquetes en este
rango de direcciones, porque estos paquetes generalmente se envían con un valor de tiempo de vida (TTL) de 1.
Los protocolos de red usan estas direcciones para el descubrimiento automático de enrutadores y para
comunicar información de enrutamiento importante. Por ejemplo, OSPF usa las direcciones IP 224.0.0.5 y
224.0.0.6 para intercambiar información de estado de enlace.
La dirección 224.0.0.1 identifica el grupo de todos los hosts. Cada host con capacidad de multidifusión debe unirse a
este grupo al inicializar su pila de IP. Si envía una solicitud de eco ICMP a esta dirección, todos los hosts con
capacidad de multidifusión en la red responderán a la solicitud con una respuesta de eco ICMP.
La dirección 224.0.0.2 identifica el grupo de todos los enrutadores. Los enrutadores de multidifusión se unen a este grupo en todas las
interfaces habilitadas para multidifusión.
Direcciones de ámbito global

Las direcciones en el rango 224.0.1.0 a 238.255.255.255 se denominan direcciones de alcance global -
es. Las empresas utilizan estas direcciones para multidifundir datos entre organizaciones y a través de
Internet. Las aplicaciones de multidifusión reservan algunas de estas direcciones para usarlas a través
de IANA. Por ejemplo, IANA reserva la dirección IP 224.0.1.1 para el Network Time Protocol (NTP).
Direcciones de multidifusión específicas de la fuente
Las direcciones en el rango 232.0.0.0 a 232.255.255.255 están reservadas para Source-Specific Multicast
(SSM), una extensión del protocolo Protocol Independent Multicast (PIM) que permite un mecanismo
eficiente de entrega de datos en comunicaciones de uno a muchos. En SSM, las decisiones de reenvío
se basan tanto en direcciones de grupo como de origen, lo que se conoce como (S,G). La notación
especial de (S,G), pronunciada "S coma G", utiliza S como la dirección IP de la fuente y G como la
dirección del grupo de multidifusión. Este único (S,G) se conoce dentro de SSM como un canal. SSM
también elimina los problemas de asignación de direcciones porque la dirección de origen hace que
cada canal sea único. SSM requiere que el host conozca la fuente y el grupo del que desea datos y un
método para señalar este requisito (S,G) al enrutador.
Direcciones GLOP
RFC 3180, "Direccionamiento GLOP en 233/8", propone que el rango de direcciones 233.0.0.0 a
233.255.255.255 se reserve para direcciones definidas estáticamente por organizaciones que ya tienen
un número de sistema autónomo reservado. Esta práctica se denomina direccionamiento GLOP y el
término no es un acrónimo. El número de sistema autónomo del dominio está incrustado en el
segundo y tercer octeto del rango de direcciones 233.0.0.0 a 233.255.255.255. Por ejemplo, el sistema
autónomo 62010 se escribe en formato hexadecimal como F23A. Separando los dos octetos F2 y 3A da
como resultado 242 y 58 en formato decimal, respectivamente. Estos valores dan como resultado una
subred de 233.242.58.0/24 que está reservada globalmente para que la use el sistema autónomo
62010.
Direcciones de alcance limitado
Las direcciones en el rango 239.0.0.0 a 239.255.255.255 se denominan direcciones de alcance limitado o

direcciones de alcance administrativo. Estas direcciones se describen en RFC 2365, "Multidifusión de IP con
alcance administrativo", para estar restringidas a un grupo u organización local. Las empresas, universidades u
otras organizaciones utilizan direcciones de alcance limitado para tener aplicaciones de multidifusión locales
donde los enrutadores de borde a Internet no reenvían las tramas de multidifusión fuera de su dominio de
intranet.
Estructura de direcciones MAC de multidifusión
De manera similar a la forma en que una dirección IP se asigna a una dirección MAP única, una dirección de
multidifusión IP también se asigna a una dirección MAC de multidifusión única. La dirección MAC de multidifusión
se deriva de la dirección IP de multidifusión.
Las direcciones MAC de multidifusión comienzan con el prefijo de 25 bits 0x01-00-5E (que en binario es
00000001.00000000.01011110.0xxxxxxx.xxxxxxxx.xxxxxxxx), donde x representa un comodín) con el bit 25
establecido en 0. Porque todas las direcciones IP de multidifusión tenga los primeros 4 bits configurados en
1110, los 28 bits menos significativos (LSB) restantes de las direcciones IP de multidifusión deben asignarse a los
23 LSB de la dirección MAC. Como resultado, la dirección MAC pierde 5 bits de unicidad en el proceso de mapeo
de direcciones IP a MAC. Los 5 bits que no se utilizan son los 5 MSB de los 28 LSB restantes después de 4 bits,
1110, MSB. Este método para mapear direcciones IP de multidifusión a direcciones MAC da como resultado un
mapeo 32:1, donde cada dirección MAC de multidifusión representa 32 posibles direcciones IP de multidifusión
distintas. La figura 7-26 muestra un ejemplo de asignación de direcciones IP a MAC de multidifusión.
Un host que se une a un grupo de multidifusión programa su tarjeta de interfaz de red para escuchar la
dirección MAC asignada por IP. Si la misma dirección MAC se asigna a una segunda dirección de multidifusión
MAC que ya está en uso, la CPU del host procesa ambos conjuntos de tramas de multidifusión IP. Además,
debido a que los switches reenvían tramas en función de la dirección MAC de multidifusión si están
configurados para la indagación de multidifusión de Capa 2, reenvían tramas a todos los miembros
correspondientes a otras direcciones IP de multidifusión de la misma asignación de direcciones MAC, incluso si
las tramas pertenecen a una dirección diferente. Grupo de multidifusión IP. Por ejemplo, las direcciones IP de
multidifusión 238.1.1.2 y 238.129.1.2 se asignan a la misma dirección MAC de multidifusión
01:00:5E:01:01:02. Como resultado, un host que se registró en el grupo 238.1.1.2 también recibe la
tráfico de 238:129:1.2 porque ambos flujos de multidifusión IP utilizan la misma dirección de

multidifusión MAC. Se recomienda evitar la superposición al implementar aplicaciones de
multidifusión en la red conmutada multicapa ajustando las direcciones IP de multidifusión de
destino en el nivel de la aplicación.
Dirección de multidifusión IP
224.1.1.2
224.129.1.2
225.1.1.2
225.129.1.2
226.1.1.2 MAC de multidifusión

DIRECCIÓN
226.129.1.2
0x01-00-5E-01-02
238.1.1.2
238.129.1.2
239.1.1.2
239.129.1.2
Figura 7-26 Ejemplo de mapeo de IP a MAC de multidifusión
Reenvío de ruta inversa

Los enrutadores con capacidad de multidifusión y los conmutadores de múltiples capas crean árboles de distribución
que controlan la ruta que toma el tráfico de multidifusión IP a través de la red para lograr un reenvío sin bucles. El
reenvío de ruta inversa (RPF) es el mecanismo que realiza una verificación de interfaz entrante para determinar si
reenviar o descartar una trama de multidifusión entrante. RPF es un concepto clave en el reenvío de multidifusión.
Esta verificación de RPF ayuda a garantizar que el árbol de distribución para multidifusión esté libre de bucles.
Además, RPF permite que los enrutadores reenvíen correctamente el tráfico de multidifusión por el árbol de
distribución.
En el enrutamiento de unidifusión, el tráfico se enruta a través de la red a lo largo de la ruta desde el

único origen hasta el único host de destino. Un enrutador que reenvía paquetes de unidifusión no
tiene en cuenta la dirección de origen de forma predeterminada; el enrutador considera solo la
dirección de destino y cómo reenviar el tráfico hacia el destino con la excepción de las funciones CEF
especializadas. Al recibir los paquetes de unidifusión, el enrutador busca en su tabla de enrutamiento
la dirección de destino y luego reenvía una sola copia del paquete de unidifusión por la interfaz
correcta al destino.
En el reenvío de multidifusión, la fuente envía tráfico a un grupo arbitrario de hosts que está representado
por una sola dirección de grupo de multidifusión. Cuando un enrutador de multidifusión recibe un paquete
de multidifusión, determina qué dirección es la dirección ascendente (hacia la fuente)
y cuál es la dirección aguas abajo (hacia los receptores). Un enrutador reenvía un paquete
de multidifusión solo si el paquete se recibe en la interfaz ascendente correcta determinada
por el proceso RPF.
Tenga en cuenta que, aunque los enrutadores crean una tabla de enrutamiento de multidifusión de IP separada, la
verificación de RFP depende de la tabla de enrutamiento de IP de unidifusión para determinar las interfaces
ascendentes y descendentes correctas.
Para el tráfico que fluye por un árbol de origen, el procedimiento de verificación de RPF funciona de la siguiente manera:
■ El enrutador busca la dirección de origen en la tabla de enrutamiento de unidifusión para determinar

si llegó a la interfaz que está en la ruta inversa (ruta de menor costo) de regreso a la fuente.
■ Si el paquete ha llegado a la interfaz que conduce de regreso a la fuente, la

verificación de RPF es exitosa y el enrutador replica y reenvía el paquete a las
interfaces salientes.
■ Si falla la verificación de RPF en el paso anterior, el enrutador descarta el paquete y registra la

eliminación como una falla de RPF.
La parte superior de la Figura 7-27 ilustra un ejemplo en el que falla la comprobación de RPF. El enrutador de la
figura recibe un paquete de multidifusión del origen 151.10.3.21 en la interfaz S0. Una verificación de la tabla de
rutas de unidifusión muestra que este enrutador utiliza la interfaz S1 como interfaz de salida para reenviar datos
de unidifusión a 151.10.3.21. Debido a que, en cambio, el paquete llegó a la interfaz S0, el paquete falla en la
verificación de RPF y el enrutador descarta el paquete. En la parte inferior de la Figura 7-27, la verificación de RPF
tiene éxito. Con este ejemplo, el paquete de multidifusión llega a la interfaz S1. El enrutador verifica la tabla de
enrutamiento de unidifusión y encuentra que la Interfaz S1 es la interfaz de ingreso correcta. La verificación de
RPF pasa y el enrutador reenvía el paquete.
En las redes conmutadas multicapa donde varios enrutadores se conectan al mismo segmento LAN, solo
un enrutador reenvía el tráfico de multidifusión desde la fuente a los receptores en las interfaces
salientes. Este enrutador se denomina enrutador designado de multidifusión independiente del
protocolo (PIM DR) y se ilustra en la figura 7-28. El enrutador A, el enrutador designado por PIM (PIM
DR), reenvía datos a VLAN 1 y VLAN 2. El enrutador B recibe el tráfico de multidifusión reenviado en VLAN
1 y VLAN 2, y descarta este tráfico porque el tráfico de multidifusión falla en la verificación de RPF. El
tráfico que no pasa la verificación RPF se denomina tráfico no RPF.
Árbol de reenvío de multidifusión
Los enrutadores con capacidad de multidifusión crean árboles de distribución de multidifusión que controlan la ruta que
toma el tráfico de multidifusión IP a través de la red para entregar el tráfico a todos los receptores.
Los siguientes son los dos tipos de árboles de distribución:
■ árboles fuente
■ árboles compartidos
Paquete de multidifusión desde

Fuente 151.10.3.21
¡Falló la comprobación de RPF!
Tabla de rutas de multidifusión

S0
Red Interfaz paquete llego el
151.10.0.0/16 S1 interfaz incorrecta! S1 S2
Descartar paquete.
198.14.32.0/24 S0
204.1.16.0/24 E0 E0
Paquete de multidifusión desde

¡Comprobación RPF exitosa! Fuente 151.10.3.21
Tabla de rutas de multidifusión

S0
Red Interfaz
S1 S2
151.10.0.0/16 S1 paquete llego el
198.14.32.0/24 S0 interfaz correcta!
204.1.16.0/24 E0 E0
Figura 7-27 Reenvío de ruta inversa
Tráfico de multidifusión
Tráfico no RPF
Instalaciones
Red
Cisco Capa 3 Cisco Capa 3
Interruptor - Designado Interruptor: no designado
enrutador enrutador
Tráfico de multidifusión No RPF

Tráfico
VLAN 1
VLAN 2
Figura 7-28 Tráfico de multidifusión sin RPF
Árboles de origen
La forma más simple de un árbol de distribución de multidifusión es un árbol de origen con su raíz en el
origen y sus ramas formando un árbol a través de la red hasta los receptores. Dado que este árbol
utiliza la ruta más corta a través de la red, también se denomina árbol de ruta más corta (SPT).
La Figura 7-29 muestra un ejemplo de un SPT para el grupo 224.1.1.1 arraigado en la fuente, Host A, y
conectando dos receptores, Hosts B y C.
Anfitrión A
Fuente
224.1.1.1 Tráfico
192.168.1.1
A B D F
C mi
192.168.2.2 192.168.3.3
Receptor Receptor
Anfitrión B Anfitrión C
Figura 7-29 Árbol de distribución de origen de multidifusión IP
Usando la notación (S,G), el SPT para el ejemplo que se muestra en la Figura 7-29 es (192.168.1.1,
224.1.1.1).
La notación (S,G) implica que existe un SPT separado para cada fuente que envía a cada grupo. Por
ejemplo, si el host B también envía tráfico al grupo 224.1.1.1 y los hosts A y C son receptores, existiría
un SPT (S,G) separado con una notación de (192.168.2.2, 224.1.1.1).
Árboles compartidos
A diferencia de los árboles fuente, que tienen su raíz en la fuente, los árboles compartidos usan una
única raíz común ubicada en algún punto elegido de la red. Esta raíz compartida se denomina punto de
encuentro (RP). La Figura 7-30 muestra un árbol unidireccional compartido para el grupo 224.1.1.1 con la
raíz ubicada en el enrutador D. El tráfico de origen se envía hacia el RP en un árbol compartido. Luego, el
tráfico se reenvía por el árbol compartido desde el RP para llegar a todos los receptores, a menos que el
receptor esté ubicado entre la fuente y el RP, en cuyo caso el tráfico de multidifusión se atiende
directamente.
En la Figura 7-30, el tráfico de multidifusión de las fuentes, los hosts A y D, viaja a la raíz (enrutador D) y luego
baja por el árbol compartido hasta los dos receptores, los hosts B y C. Debido a que todas las fuentes en el
grupo de multidifusión usan un común árbol compartido, una notación comodín escrita como (*,G), pronunciada
"estrella coma G", representa el árbol. En este caso, * significa todas las fuentes y G representa el grupo de
multidifusión. Por lo tanto, el árbol compartido que se muestra en la figura se escribe como (*, 224.1.1.1).
Anfitrión A
Fuente 1
224.1.1.1 Tráfico
192.168.1.1
PR
Fuente 2
A B D F Anfitrión D
192.168.4.4
C mi
192.168.2.2 192.168.3.3
Receptor Receptor
Anfitrión B Anfitrión C
Figura 7-30 Distribución de árbol compartido de multidifusión IP
Comparación de árboles de origen y árboles compartidos
Tanto los árboles de origen como los árboles compartidos evitan los bucles de tráfico de multidifusión. Los dispositivos de
enrutamiento replican los paquetes de multidifusión solo donde se ramifica el árbol.
Los miembros de los grupos de multidifusión se unen o se van en cualquier momento; como resultado, los
árboles de distribución se actualizan dinámicamente. Cuando todos los receptores activos en una rama en
particular dejan de solicitar tráfico para un grupo de multidifusión en particular, los enrutadores eliminan esa
rama del árbol y dejan de reenviar el tráfico hacia abajo. Si un receptor en esa rama se activa y solicita el
tráfico de multidifusión, el enrutador modifica dinámicamente el árbol de distribución y comienza a reenviar el
tráfico nuevamente.
Los árboles de fuentes tienen la ventaja de crear la ruta óptima entre la fuente y los receptores. Esta
ventaja garantiza la mínima cantidad de latencia de red para el reenvío de tráfico de multidifusión. Sin
embargo, esta optimización requiere una sobrecarga adicional porque los enrutadores mantienen
información de ruta para cada fuente. En una red que tiene miles de fuentes y miles de grupos, esta
sobrecarga se convierte rápidamente en un problema de recursos en los enrutadores o conmutadores
multicapa. El consumo de memoria y la complejidad de la solución de problemas del tamaño de la tabla
de enrutamiento de multidifusión son factores que los diseñadores de redes deben tener en cuenta al
diseñar redes de multidifusión.
Los árboles compartidos tienen la ventaja de requerir la cantidad mínima de información de estado
en cada enrutador. Esta ventaja reduce los requisitos generales de memoria y la complejidad de una
red que solo permite árboles compartidos. La desventaja de los árboles compartidos es que, bajo
ciertas circunstancias, las rutas entre la fuente y los receptores pueden no ser las óptimas.
caminos, que pueden introducir latencia adicional en la entrega de paquetes. Como resultado, los árboles
compartidos pueden abusar de algunos enlaces y dejar otros sin usar, mientras que los árboles basados en
fuentes (donde se distribuyen las fuentes) generalmente distribuyen el tráfico a través de un conjunto de
enlaces. Por ejemplo, en la figura 7-30, la ruta más corta entre el host A (fuente 1) y el host B (un receptor) es
entre el enrutador A y el enrutador C. Dado que el enrutador D es la raíz de un árbol compartido, el tráfico
atraviesa los enrutadores A , B, D y luego C. Los diseñadores de redes deben considerar detenidamente la
ubicación del RP al implementar un entorno de solo árbol compartido.
Protocolos de multidifusión IP
Similar a IP unicast, IP multicast utiliza sus propios protocolos de enrutamiento, administración y capa 2.
Los siguientes son dos importantes protocolos de multidifusión:
■ Multidifusión independiente del protocolo (PIM)
■ Protocolo de administración de grupos de Internet (IGMP)
PIM
Un protocolo de enrutamiento de multidifusión es responsable de la construcción de árboles de entrega de multidifusión y
de permitir el reenvío de paquetes de multidifusión. Los diferentes protocolos de enrutamiento de multidifusión IP utilizan
diferentes técnicas para construir árboles de multidifusión y reenviar paquetes. El protocolo de enrutamiento PIM
aprovecha los protocolos de enrutamiento de unidifusión que se utilizan para llenar la tabla de enrutamiento de unidifusión
para tomar decisiones de reenvío de multidifusión.
Además, los enrutadores usan el mecanismo de descubrimiento de vecinos PIM para establecer vecinos PIM
mediante mensajes de saludo a la dirección de multidifusión de TODOS LOS PIM-Routers (224.0.0.13) para crear
y mantener árboles de distribución de multidifusión PIM. Además, los enrutadores usan mensajes de saludo
PIM para elegir el enrutador designado (DR) para una red LAN de multidifusión.
PIM abarca dos versiones distintas: PIM versión 1 y PIM versión 2. Este capítulo compara las
dos en la sección "Comparación y compatibilidad de PIM versión 1 y versión 2", más adelante
en este capítulo.
PIM tiene los siguientes cuatro modos de operación, que se analizan en las siguientes
secciones:
■ Modo denso PIM
■ Modo disperso PIM
■ PIM modo escaso-denso
■ PIM bidireccional
El modo disperso-denso es más común en redes de grandes empresas. Hay un pequeño movimiento hacia
PIM bidireccional en redes de grandes empresas; sin embargo, a principios de 2010, existen pocos
adoptantes de grandes empresas.
Modo denso PIM

Los protocolos de enrutamiento de multidifusión en modo denso PIM (PIM-DM) se basan en la inundación
periódica de la red con tráfico de multidifusión para configurar y mantener el árbol de distribución. PIM se basa
en la información de su vecino para formar el árbol de distribución. PIM-DM utiliza un árbol de distribución de
fuentes para reenviar el tráfico de multidifusión, que los enrutadores respectivos crean tan pronto como
cualquier fuente de multidifusión comienza a transmitir. La Figura 7-31 ilustra un ejemplo de PIM-DM.
Esto es un
paquete de multidifusión
para el grupo XYZ.
Mensaje de poda
No tengo
miembros para
grupo XYZ.
Figura 7-31 Modo denso PIM
El modo denso de PIM está obsoleto y ya no se implementa en las redes del campus. Esta sección todavía
existe con el propósito de completarla.
PIM-DM supone que los miembros del grupo de multidifusión están densamente distribuidos por toda la red y
que el ancho de banda es abundante, lo que significa que casi todos los hosts de la red pertenecen al grupo.
Cuando un enrutador configurado para PIM-DM recibe un paquete de multidifusión, el enrutador realiza la
verificación de RPF para validar la interfaz correcta para la fuente y luego reenvía el paquete a todas las
interfaces configuradas para multidifusión hasta que ocurre la poda y el truncamiento. Todos los enrutadores
descendentes reciben el paquete de multidifusión hasta que se agota el tiempo de espera del tráfico de
multidifusión. PIM-DM envía un mensaje de poda aguas arriba solo bajo las siguientes condiciones:
■ El tráfico llega a una interfaz punto a punto que no es RPF; esta es la interfaz del enrutador de siguiente
salto que no tiene la mejor ruta hacia la fuente de multidifusión.
■ Un enrutador hoja sin receptores envía un mensaje de eliminación, como se muestra en la figura 7-31, y el
enrutador, que no tiene miembros ni receptores, envía el mensaje de eliminación al enrutador
ascendente.
■ Un enrutador no hoja recibe un mensaje de eliminación de todos sus vecinos.

En resumen, PIM-DM funciona mejor cuando numerosos miembros pertenecen a cada grupo multimedia.
PIM inunda el paquete multimedia a todos los enrutadores de la red y luego elimina los enrutadores que
no dan servicio a los miembros de ese grupo de multidifusión en particular.
Al planificar la multidifusión en la red del campus, tenga en cuenta que PIM-DM es más útil en los
siguientes casos:
■ Los emisores y los receptores están muy cerca unos de otros.
■ PIM-SM pasa por una fase de inundación de modo denso antes de confiar completamente en el RP para el
reenvío de multidifusión.
■ Hay pocos emisores y muchos receptores.
■ El volumen de tráfico de multidifusión es alto.
■ El flujo de tráfico de multidifusión es constante.
Sin embargo, PIM-DM no es el método de elección para la mayoría de las empresas de redes de campus debido a
sus limitaciones de escalabilidad y propiedades de inundación.
Modo disperso PIM

El segundo enfoque para el enrutamiento de multidifusión, el modo disperso PIM (PIM-SM), se basa en la
suposición de que los miembros del grupo de multidifusión están escasamente distribuidos en toda la red
y que el ancho de banda es limitado.
Es importante señalar que PIM-SM no implica que el grupo tenga pocos miembros, sino que están muy
dispersos. En este caso, la inundación desperdiciaría innecesariamente el ancho de banda de la red y podría
causar serios problemas de rendimiento. Por lo tanto, los protocolos de enrutamiento de multidifusión PIM-
SM se basan en técnicas más selectivas para configurar y mantener árboles de multidifusión.
Los protocolos PIM-SM comienzan con un árbol de distribución vacío y agregan ramas solo como resultado
de solicitudes explícitas para unirse a la distribución. La Figura 7-32 ilustra una muestra del modo disperso
de PIM.
Con PIM-SM, cada flujo de datos va a un número relativamente pequeño de segmentos en

la red del campus. En lugar de inundar la red para determinar el estado de los miembros de
multidifusión, PIM-SM define un RP. Cuando un remitente quiere enviar datos, primero lo
hace al RP. Cuando un receptor quiere recibir datos, se registra con el RP, como se muestra
en la Figura 7-32. Cuando el flujo de datos comienza a fluir del remitente al RP y al receptor,
los enrutadores en la ruta optimizan automáticamente la ruta para eliminar los saltos
innecesarios. PIM-SM asume que ningún host desea el tráfico de multidifusión a menos
que lo solicite específicamente. En PIM-SM, el modo de árbol compartido se puede cambiar
a un árbol de fuente después de cierto umbral para tener la mejor ruta a la fuente. Todos
los enrutadores y conmutadores Cisco IOS, de forma predeterminada, tienen el umbral SPT
establecido en 0,
Nota Para aclarar una confusión común, el modo disperso solo usa el RP como punto inicial para reenviar
multidifusión de forma predeterminada; existen opciones de configuración para adelantar todo el tráfico al RP.
Yo quiero
empezar a enviar
paquetes de multidifusión
al grupo XYZ.
Yo quiero
empezar a recibir
paquetes de multidifusión optimizado A Inicial
del grupo XYZ. Camino Camino
Cita
Punto
D B
Inicial Inicial
Camino Camino
Figura 7-32 Modo disperso PIM de multidifusión
PIM-SM está optimizado para entornos donde hay muchos flujos de datos multipunto. Al
planificar implementaciones de multidifusión en la red del campus, elija PIM-SM con IP en los
siguientes escenarios:
■ Hay muchos flujos de datos multipunto.
■ En cualquier momento, hay pocos receptores en un grupo.
■ El tipo de tráfico es intermitente o congestionado.
Modo PIM Escaso-Denso

PIM puede admitir simultáneamente la operación en modo denso para algunos grupos de multidifusión
y la operación en modo disperso para otros. Sin embargo, Cisco ha implementado una alternativa para
elegir solo el modo denso o solo el modo disperso en una interfaz de enrutador. Esto fue necesario por
un cambio en el paradigma para reenviar tráfico de multidifusión a través de PIM que se hizo evidente
durante su desarrollo. Resultó que era más eficiente elegir el modo disperso o denso por grupo en lugar
de por interfaz de enrutador. El modo disperso-denso facilita esta capacidad.
El modo disperso-denso de PIM permite que los grupos individuales usen el modo disperso o denso dependiendo
de si la información de RP está disponible para ese grupo. Si el enrutador aprende información de RP para un
grupo en particular, se usa el modo disperso; de lo contrario, se utiliza el modo denso. Tenga en cuenta que el
modo denso de repuesto PIM rara vez se usa en redes de campus.
PIM Bidireccional
PIM bidireccional (bidir-PIM) es una extensión de la función PIM-SM existente y comparte muchas
operaciones SPT. Bidir-PIM es adecuado para multidifusión con un gran número de fuentes.
Bidir-PIM puede reenviar incondicionalmente el tráfico de origen hacia el RP aguas arriba en el árbol
compartido sin registrarse para las fuentes como en PIM-SM. Esto permite que el tráfico pase por el árbol
compartido hacia el RP. Para evitar bucles de paquetes de multidifusión, bidir -PIM introduce un
mecanismo llamado elección de reenviador designado (DF), que establece un SPT sin bucles
enraizado en el RP. El DF es responsable de reenviar los paquetes de multidifusión recibidos en esa
red aguas arriba al RP. Existe un DF por cada RP de grupos bidireccionales.
Un enrutador crea solo (*,G) entradas para grupos bidireccionales. La lista de interfaces salientes del
tráfico de multidifusión (olist) de una entrada (*,G) incluye todas las interfaces para las que el enrutador
se ha elegido como DF y que han recibido un mensaje de unión IGMP o PIM. Si se recibe un paquete
desde la interfaz RPF hacia el RP, el paquete se reenvía hacia abajo según la lista de entradas (*,G). De lo
contrario, cuando el enrutador que es DF para la interfaz de recepción reenvía el paquete hacia el RP,
todos los demás enrutadores deben descartar el paquete. Estas modificaciones son necesarias y
suficientes para permitir el reenvío de tráfico en todos los enrutadores basándose únicamente en las
entradas de enrutamiento de multidifusión (*, G). Esta función elimina cualquier estado específico de la
fuente y permite escalar la capacidad a un número arbitrario de fuentes.
Automatización de la distribución de RP
Los modos PIM-SM y PIM disperso-denso utilizan varios métodos, que se analizan en esta sección, para
automatizar la distribución del RP. Este mecanismo tiene los siguientes beneficios:
■ Elimina la necesidad de configurar manualmente la información de RP en cada enrutador y

conmutador de la red.
■ Es fácil usar múltiples RP dentro de una red para atender diferentes rangos de grupos.
■ Permite dividir la carga entre diferentes RP y posibilita la disposición de los RP según

la ubicación de los participantes del grupo.
■ Evita la inconsistencia; las configuraciones manuales de RP pueden causar problemas de conectividad si no

se configuran correctamente.
PIM utiliza los siguientes mecanismos para automatizar la distribución de los RP:
■ Auto-RP
■ Enrutador de arranque (BSR)
■ Anycast-RP
■ MSDPAnycast-RP y MSDP están fuera del contexto de SWITCH; Puede encontrar más
información sobre estos mecanismos en Cisco.com.
Auto-RP
Auto-RP automatiza la distribución de asignaciones de grupo a RP en una red PIM. Las asignaciones de
grupo a RP definen qué grupos de multidifusión usan qué RP para el modo disperso o el modo disperso
denso.
Todos los enrutadores y dispositivos de Capa 3 en la red PIM aprenden sobre el mapeo activo de grupo
a RP del agente de mapeo de RP al unirse automáticamente al grupo de multidifusión Cisco-RP-
discovery (224.0.1.40). El agente de mapeo RP es el enrutador que envía la autoridad
paquetes de descubrimiento que notifican a otros enrutadores qué mapeo de grupo a RP usar, como se muestra
en la Figura 7-33. El agente de mapeo de RP envía esta información cada 60 segundos. Este rol es necesario si se
producen conflictos (como la superposición de rangos de grupo a RP).
Agente de mapeo de RP
Cisco-RP-descubrimiento
224.0.1.40 Enrutador 1 224.0.1.40
Candidato para Anuncio de Cisco-RP 224.0.1.39 Candidato para

224.0.1.39
PR PR
Enrutador 2 Enrutador 3
224.0.1.40 224.0.1.40
Enrutador 4 Enrutador 5
Figura 7-33 Mecanismo de Auto-RP
Los agentes de mapeo también usan multidifusión IP para descubrir qué enrutadores en la red son
posibles RP candidatos uniéndose al grupo Cisco-RP-announce (224.0.1.39) para recibir anuncios de RP
candidatos. Los RP candidatos envían mensajes de multidifusión de anuncios de RP para los grupos
particulares cada 60 segundos. El agente de asignación de RP utiliza la información contenida en el
anuncio para crear entradas en la memoria caché de grupo a RP. Los agentes de mapeo de RP crean
solo una entrada por grupo. Si más de un candidato de RP anuncia el mismo rango, el agente de
mapeo de RP usa la dirección IP del RP para desempatar.
Se recomienda configurar un agente de mapeo RP en el enrutador con la mejor conectividad y estabilidad.

Todos los enrutadores dentro del número TTL de saltos desde el enrutador de asignación de RP reciben los
mensajes de descubrimiento de Auto-RP.
Los entornos de modo disperso requieren un RP predeterminado para unirse al grupo de detección de Auto-RP,
pero los entornos de modo disperso-denso no necesitan un RP predeterminado para Auto-RP. Se recomienda
utilizar RP para los grupos globales. No es necesario reconfigurar el rango de direcciones de grupo que sirve el
RP. Los RP que se descubren dinámicamente a través de Auto-RP tienen prioridad sobre los RP configurados
estáticamente. Normalmente, las redes de campus utilizan un segundo RP para los grupos locales.
Enrutador de arranque
Un enrutador de arranque (BSR) es un enrutador o dispositivo de Capa 3 que se encarga de distribuir

RP. Usar un BSR es otra forma de distribuir información de mapeo de grupo a RP en la red de
multidifusión PIM. Sin embargo, BSR solo funciona con la versión 2 de PIM. Un BSR utiliza la inundación
de salto a salto de mensajes BSR especiales en lugar de multidifusión para distribuir la asignación de
grupo a RP.
BSR utiliza un mecanismo de elección para seleccionar el enrutador BSR de un conjunto de enrutadores
candidatos y conmutadores multicapa en el dominio. La elección de BSR utiliza la prioridad de BSR del
dispositivo contenido en los mensajes de BSR que fluyen salto a salto a través de la red. Cada dispositivo
BSR examina el mensaje y lo reenvía por todas las interfaces solo si el mensaje tiene una prioridad BSR
más alta que la prioridad BSR del enrutador o tiene la misma prioridad BSR pero con una dirección IP BSR
más alta.
El BSR elegido envía mensajes de BSR con un TTL de 1 con su dirección IP para permitir que los BSR
candidatos aprendan automáticamente sobre el BSR elegido. Los enrutadores PIM versión 2 vecinos o los
conmutadores multicapa reciben el mensaje BSR y multidifunden el mensaje en todas las demás
interfaces (excepto en la que se recibió) con un TTL de 1 para distribuir los mensajes BSR salto por salto,
como se muestra en la Figura 7-34.
BSR
Mensajes BSR Mensajes BSR

Reenviado salto a salto Reenviado salto a salto
Enrutador 1
Candidato para unidifusión unidifusión

Candidato para
PR C-RP C-RP PR
anuncios anuncios
2 3
4 5
Figura 7-34 Mecanismos BSR
Los RP candidatos envían anuncios de RP candidatos que muestran el rango de grupo del que cada uno
es responsable al BSR, que almacena esta información en su caché de RP candidato local. El BSR incluye
esta información en sus mensajes de arranque y la difunde a todos los enrutadores PIM usando
224.0.0.13 con un TTL de 1 en el dominio salto por salto. Según esta información, todos los enrutadores
pueden asignar grupos de multidifusión a RP específicos. Siempre que un enrutador reciba el mensaje
de arranque, tiene un mapa RP actual. Los enrutadores y los conmutadores multicapa seleccionan el
mismo RP para un grupo dado porque todos usan un algoritmo hash de RP común.
Comparación y Compatibilidad de PIM Versión 1 y Versión 2

PIM versión 2 es un protocolo de multidifusión basado en estándares del Grupo de Trabajo de Ingeniería de
Internet (IETF). Cisco recomienda encarecidamente utilizar la versión 2 de PIM en toda la red conmutada
multicapa. La implementación de Cisco PIM versión 2 permite la interoperabilidad y la transición entre la versión
1 y la versión 2, aunque hay algunas advertencias. Por ejemplo, si un enrutador PIM versión 2 detecta un
enrutador PIM versión 1, el enrutador versión 2 se degrada a sí mismo a la versión 1 hasta que todos los
enrutadores versión 1 se hayan apagado o actualizado.
La versión 2 de PIM utiliza el BSR para descubrir y anunciar información de mapeo de RP a grupo para
cada prefijo de grupo a todos los enrutadores en un dominio PIM. Esta es la misma función que realiza
Auto-RP. Sin embargo, la función BSR es parte de las especificaciones de la versión 2 de PIM porque los
mensajes de arranque se envían salto por salto, y un enrutador de la versión 1 de PIM evita que estos
mensajes lleguen a todos los enrutadores de una red. Por lo tanto, si una red tiene un enrutador PIM
versión 1 con enrutadores Cisco, es mejor usar Auto-RP en lugar del mecanismo de arranque. No
obstante, Auto-RP es un protocolo independiente, independiente de la versión 1 de PIM, y es propiedad
de Cisco. El mecanismo BSR interopera con Auto-RP en los enrutadores Cisco.
Un BSR de PIM versión 2 que también es un agente de mapeo de Auto-RP anuncia automáticamente el RP
elegido por Auto-RP. Es decir, Auto-RP prevalece en su imposición de un solo RP en cada enrutador del
grupo.
En resumen, PIM versión 2 incluye las siguientes mejoras sobre PIM versión 1:
■ Existe un solo RP activo por grupo de multidifusión, con múltiples RP de respaldo. Este único RP se
compara con múltiples RP activos para el mismo grupo en la versión 1 de PIM.
■ Un BSR proporciona un mecanismo de distribución y descubrimiento de RP automatizado y tolerante a fallas. Por lo
tanto, los enrutadores aprenden dinámicamente las asignaciones de grupo a RP.
■ El modo disperso y el modo denso son propiedades de un grupo, a diferencia de una interfaz. Cisco
recomienda encarecidamente las configuraciones de modo denso-disperso.
■ Los mensajes de unión y eliminación de PIM tienen codificaciones más flexibles para varias familias de
direcciones.
■ Un formato de paquete de saludo más flexible reemplaza el paquete de consulta para codificar las opciones de
capacidad actuales y futuras.
■ Los mensajes de registro a un RP indican si fueron enviados por un enrutador de borde o un

enrutador designado.
■ PIM ya no usa el protocolo IGMP para el transporte; La versión 2 de PIM utiliza paquetes
independientes.
Cuando planifique implementaciones de PIM en la red del campus, prefiera usar la versión 2 de PIM en lugar de la
versión 1 de PIM.
Nota Varias versiones más nuevas de los protocolos de modo disperso PIM están ganando popularidad
en las redes de campus. Estas versiones incluyen lo siguiente:
■ Any Source Multicast (ASM), que utiliza RP con árbol de ruta más corta o árbol
compartido.
■ Source Specific Multicast (SSM)), que no utiliza RP y está diseñado utilizando solo el árbol
de ruta más corto.
■ PIM bidireccional (BI-dir PIM), que se basa únicamente en árboles compartidos.

Estas versiones están fuera del alcance de CCNP SWITCH; consulte Cisco.com para obtener información
adicional sobre estas versiones.
Configuración del protocolo de administración de grupos de Internet
Los hosts usan IGMP para registrarse dinámicamente en un grupo de multidifusión en una LAN en particular. Los
hosts identifican las pertenencias a grupos mediante el envío de mensajes IGMP a su enrutador de multidifusión
local designado. Los enrutadores y los conmutadores multicapa, configurados para IGMP, escuchan los mensajes
IGMP y envían consultas periódicamente para descubrir qué grupos están activos o inactivos en una subred o VLAN
en particular.
La siguiente lista indica las versiones actuales de IGMP:
■ IGMP versión 1 (IGMPv1) RFC 1112
■ IGMP versión 3 lite (IGMPv3 lite)
IGMPv1
De acuerdo con la especificación IGMPv1, un enrutador de multidifusión por LAN debe transmitir
periódicamente mensajes de consulta de membresía del host para determinar qué grupos de host tienen
miembros en las redes LAN conectadas directamente al enrutador. Los mensajes de consulta IGMP se
dirigen al grupo de todos los hosts (224.0.0.1) y tienen un TTL de IP igual a 1. Un TTL de 1 garantiza que el
enrutador correspondiente no reenvíe los mensajes de consulta a ningún otro enrutador de multidifusión.
Cuando la estación final recibe un mensaje de consulta IGMP, la estación final responde con un informe de
membresía de host para cada grupo al que pertenece la estación final.
IGMPv2
La versión 2 de IGMP realizó varias mejoras a la versión anterior, incluida la definición de una consulta
específica de grupo. El mensaje de consulta específico del grupo permite que un enrutador transmita una
consulta específica a un grupo en particular. IGMPv2 también define un mensaje de grupo de abandono para
los hosts, lo que da como resultado una latencia de abandono más baja.
Hay cuatro tipos de mensajes IGMP de interés para la interacción host-router:
■ Consulta de membresía
■ Informe de membresía de la versión 2
■ dejar informe

IGMPv2 usa el informe de membresía de IGMPv1 para compatibilidad con versiones anteriores de IGMPv1. Las versiones
más recientes de IGMP o protocolos de enrutamiento de multidifusión utilizan nuevos tipos de mensajes. Cualquier otro
tipo de mensaje o no reconocido se ignora.
IGMPv3
IGMPv3 es el siguiente paso en la evolución de IGMP. IGMPv3 agrega compatibilidad con el filtrado de
fuentes que permite que un receptor de multidifusión señale a un enrutador los grupos de los que
desea recibir tráfico de multidifusión y de qué fuentes esperar tráfico. Esta información de membresía
permite que el software Cisco IOS reenvíe el tráfico solo desde aquellas fuentes desde las cuales los
receptores solicitaron el tráfico.
En IGMPv3, existen los siguientes tipos de mensajes IGMP:
■ Consulta de membresía de la versión 3
IGMPv3 admite aplicaciones que señalan explícitamente las fuentes desde las que desean recibir
tráfico. Con IGMPv3, los receptores señalan la pertenencia a un grupo host de multidifusión en
uno de los siguientes dos modos:
■ Modo INCLUYE:El receptor anuncia la pertenencia a un grupo de host y proporciona una

lista de direcciones de origen (la lista INCLUDE) de las que desea recibir tráfico.
■ Modo EXCLUIR:El receptor anuncia la pertenencia a un grupo de multidifusión y

proporciona una lista de direcciones de origen (la lista EXCLUDE) de las que no desea recibir
tráfico. El host recibe tráfico solo de fuentes cuyas direcciones IP no figuran en la lista
EXCLUDE. Para recibir tráfico de todas las fuentes, que es el comportamiento de IGMPv2, un
host utiliza la membresía del modo EXCLUDE con una lista EXCLUDE vacía.
IGMPv3 Lite
IGMPv3 lite es una solución de transición desarrollada por Cisco para que los desarrolladores de aplicaciones
comiencen de inmediato a programar aplicaciones para SSM. Específicamente, IGMPv3 lite permite a los
desarrolladores de aplicaciones escribir y ejecutar aplicaciones SSM en hosts que aún no admiten IGMPv3 en el
kernel de su sistema operativo.
Las aplicaciones requieren la biblioteca IGMP del lado del host (HSIL) para IGMPv3 lite. Esta biblioteca de
software proporciona aplicaciones con un subconjunto de la API IGMPv3 necesaria para escribir
aplicaciones SSM. HSIL fue desarrollado para Cisco por Talarian.
Una parte de HSIL es una biblioteca cliente vinculada a la aplicación SSM. Proporciona el subconjunto
SSM de la API IGMPv3 a la aplicación SSM. Si es posible, la biblioteca comprueba si el kernel del
sistema operativo es compatible con IGMPv3. Si es así, las llamadas a la API simplemente pasan al
kernel. Si el kernel no es compatible con IGMPv3, la biblioteca utiliza el mecanismo IGMPv3 lite.
Cuando se usa el mecanismo IGMPv3 lite, la biblioteca le dice al kernel del sistema operativo que se
una a todo el grupo de multidifusión, porque unirse a todo el grupo es el único método para que la
aplicación reciba tráfico para ese grupo de multidifusión para IGMPv1 o IGMPv2. Además, la
biblioteca señala las suscripciones de canales (S,G) a un servidor IGMPv3 lite
proceso. Se necesita un proceso de servidor porque varias aplicaciones de SSM pueden estar en el mismo
host. Este proceso de servidor luego envía suscripciones de canal IGMPv3 lite específicas (S,G) al enrutador
Cisco IOS de último salto o al conmutador multicapa.
Este enrutador Cisco IOS o conmutador multicapa luego ve el informe de membresía del
grupo IGMPv1 o IGMPv2 del kernel del sistema operativo y la suscripción al canal (S,G) del
demonio HSIL. Si el enrutador ve estos dos mensajes, los interpreta como una suscripción al
canal SSM (S,G) y se une al canal a través de PIM-SM. Consulte la documentación que
acompaña al software HSIL para obtener más información sobre cómo usar IGMPv3 lite con
su aplicación.
Indagación IGMP
La indagación IGMP es un mecanismo de restricción de multidifusión IP que examina la información de multidifusión IP
de capa 2 y capa 3 para mantener una tabla de reenvío de multidifusión de capa 2. Esto restringe el tráfico de
multidifusión en la Capa 2 mediante la configuración dinámica de los puertos LAN de la Capa 2 para reenviar el tráfico
de multidifusión solo a aquellos puertos que desean recibirlo.
La indagación de IGMP funciona en conmutadores multicapa, incluso en conmutadores que no admiten el enrutamiento
de capa 3. La indagación de IGMP requiere que el conmutador LAN examine, o "inspeccione", los mensajes de entrada y
salida de IGMP enviados entre los hosts y el enrutador de multidifusión designado como primer salto.
Cuando el host se une a grupos de multidifusión, ya sea enviando un mensaje de unión IGMP no solicitado o
enviando un mensaje de unión IGMP en respuesta a una consulta general de un enrutador de multidifusión, el
conmutador ve un paquete de informe de host IGMP de un host para unirse a un grupo de multidifusión en
particular. El conmutador detecta los paquetes IGMP y agrega la interfaz del host desde la cual se originó el
paquete de informe IGMP a la entrada de la tabla de reenvío de capa 2 de multidifusión asociada. La indagación
IGMP reenvía solo el primer mensaje de unión de host por grupo de multidifusión a los enrutadores de
multidifusión y suprime el resto de los mensajes de unión para ese grupo de multidifusión. El conmutador recibe
el tráfico de multidifusión del enrutador de multidifusión para ese grupo especificado en el mensaje de unión y
reenvía ese tráfico de multidifusión a las interfaces donde se recibieron los mensajes de unión.
Cuando los hosts desean abandonar un grupo de multidifusión, ignoran las consultas IGMP generales periódicas
enviadas por el enrutador de multidifusión (un proceso conocido como salida silenciosa) o envían un mensaje de
salida IGMPv2 específico del grupo. Cuando el conmutador recibe un mensaje de abandono IGMPv2 específico
del grupo de un host, el conmutador responde con una consulta específica del grupo basada en MAC para
determinar si algún otro dispositivo conectado en esa VLAN está interesado en recibir tráfico de multidifusión
para el grupo de multidifusión específico. Si el conmutador no recibe un mensaje de incorporación de IGMP en
respuesta a la consulta general, el conmutador elimina la entrada de la tabla del host. Si el último mensaje de
abandono fue del único host del grupo y el conmutador no recibe un mensaje de incorporación de IGMP en
respuesta a la consulta general, elimina la entrada del grupo y transmite el mensaje de abandono de IGMP al
enrutador de multidifusión. El
El enrutador designado de primer salto luego elimina el grupo de esa interfaz y deja de reenviar el tráfico de
multidifusión en la interfaz para el grupo especificado en el mensaje de abandono.
La indagación de IGMP admite la función de procesamiento de salida rápida, que permite que la indagación
de IGMP elimine una interfaz de capa 2 de la tabla de reenvío de multidifusión sin responder primero con
consultas específicas del grupo IGMP al puerto del host. Al recibir un mensaje de abandono de IGMP
versión 2 o 3 específico del grupo, el conmutador elimina inmediatamente la interfaz de la entrada de la
tabla de reenvío de Capa 2 para ese grupo de multidifusión, a menos que se detecte un enrutador de
multidifusión en la interfaz respectiva. El procesamiento de salida rápida mejora la gestión del ancho de
banda para todos los hosts en una VLAN en una red conmutada multicapa.
El protocolo IGMP transmite mensajes como paquetes de multidifusión IP; como resultado, los conmutadores
no pueden distinguir los paquetes IGMP de los datos de multidifusión IP normales en la Capa 2. Por lo tanto, un
conmutador que ejecuta la indagación IGMP debe examinar cada paquete de datos de multidifusión para
determinar si contiene información de control IGMP pertinente. Si se implementa la indagación de IGMP en un
conmutador de gama baja con una CPU lenta, esto podría tener un impacto severo en el rendimiento cuando los
datos se transmiten a velocidades altas. La solución a este problema es implementar la indagación de IGMP con
ASIC especiales que puedan realizar la indagación de IGMP en el hardware.
Para configurar la indagación de IGMP en un conmutador Cisco IOS, realice los siguientes pasos:
Paso 1. Habilite la indagación de IGMP globalmente. (De forma predeterminada, está habilitado globalmente).
Cambiar (config) # ip igmp indagación
Paso 2. (Opcional). Los switches agregan puertos de enrutador de multidifusión a la tabla de reenvío para cada
entrada de multidifusión de capa 2. El conmutador se entera de dichos puertos mediante la indagación de
consultas IGMP, el flujo de paquetes PIM y DVMRP o la interpretación de paquetes CGMP de otros
enrutadores. Configure el método de indagación IGMP. El valor predeterminado es PIM.
Cambiar (config) # ip igmp snooping vlanid-vlanmrouter aprender [cgmp |

pim-dvmrp]
Paso 3. (Opcional). Si es necesario, configure el puerto del enrutador de forma estática. De forma predeterminada, la
indagación IGMP detecta automáticamente los puertos del enrutador.
Cambiar (config) # ip igmp snooping vlanid-vlan número- interfaz mrouter

interfaz
Etapa 4. (Opcional). Configure la salida rápida de IGMP si es necesario.
Cambiar (config) # ip igmp snooping vlanid-vlan salir rápido
Cambiar (config) # ip igmp snooping vlanid-vlanlicencia inmediata
Paso 5. (Opcional). De forma predeterminada, todos los hosts se registran y agregan la dirección MAC y el
puerto a la tabla de reenvío automáticamente. Si es necesario, configure un host de forma estática en
una interfaz. Por lo general, las configuraciones estáticas son necesarias cuando se solucionan
problemas o se solucionan problemas de IGMP.
Cambiar (config) # ip igmp snooping vlanid-vlanestáticodirección MAC

interfazID de interfaz
Nota La sintaxis de comandos de algunos de los comandos puede ser diferente para diferentes plataformas de
conmutadores. Consulte la documentación del producto para obtener más información.
Para configurar la multidifusión IP en los switches Catalyst que ejecutan Cisco IOS, realice los siguientes
pasos:
Paso 1. Habilite el enrutamiento de multidifusión en la capa 3 globalmente.
Cambiar (config) # ip multidifusión-enrutamiento
Paso 2. Habilite PIM en la interfaz que requiere multidifusión.
Switch(config-if)# ip pim [modo denso | modo disperso | modo escaso-denso]
Paso 3. (Opcional). Configure RP si está ejecutando el modo disperso de PIM o el modo disperso
de PIM. El software Cisco IOS se puede configurar para que los paquetes de un solo grupo
de multidifusión puedan usar uno o más RP. Es importante configurar la dirección RP en
todos los enrutadores (incluido el enrutador RP). Para configurar la dirección del RP,
ingrese el siguiente comando en el modo de configuración global:
Cambiar (config) # ip pim rp-direccióndirección IP[número de lista de acceso] [anular]
Etapa 4. (Opcional). Para designar un enrutador como el RP candidato para todos los grupos de multidifusión o para
un grupo de multidifusión en particular mediante una lista de acceso, ingrese el siguiente comando en el
modo de configuración global:
Cambiar (config) # ip pim enviar-rp-anunciar tipo de interfaz número de interfaz

alcancettl[lista de gruposnúmero de lista de acceso] [intervalosegundos]
El valor TTL define los límites de multidifusión al limitar el número de

saltos que pueden tomar los anuncios RP.
Paso 5. (Opcional). Para asignar la función de agente de mapeo de RP en el enrutador configurado en el
Paso 4 para AutoRP, ingrese el siguiente comando en el modo de configuración global:
Cambiar (config) # ip pim enviar-rp-ámbito de descubrimientottl
Paso 6. (Opcional). Todos los sistemas que utilizan Cisco IOS versión 11.3(2)T o posterior se inician en el modo
PIM versión 2 de manera predeterminada. En caso de que necesite volver a habilitar la versión 2 de PIM
o especificar la versión 1 de PIM por algún motivo, use el siguiente comando:
Cambiar (config-if) # ip pim versión [1 | 2]
Paso 7. (Opcional). Configure un enrutador de borde BSR para el dominio PIM para que los
mensajes de arranque no crucen este borde en ninguna dirección. Esto asegura que se
elegirán diferentes BSR en los dos lados de la frontera de PIM. Configure este comando
en una interfaz de modo que no se envíen ni reciban mensajes BSR de la versión 2 de
PIM a través de la interfaz.
Cambiar (config-if) # ip pim bsr-border

Paso 8. (Opcional). Para configurar una interfaz como candidata a BSR, emita el siguiente
comando:
Cambiar (config) # ip pim bsr-candidatelongitud de máscara hash de tipo de interfaz[prioridad]
hash-mask-longitudes una máscara de 32 bits para la dirección de grupo antes de llamar a la

función hash. Todos los grupos con el mismo hash semilla corresponden al mismo RP.
prioridadestá configurado como un número de 0 a 255. Se prefiere el BSR con la mayor

prioridad. Si los valores de prioridad son los mismos, el dispositivo con la dirección IP más
alta se selecciona como BSR. El valor predeterminado es 0.
Paso 9. (Opcional). Para configurar una interfaz como candidata de RP para el enrutador BSR para
grupos de multidifusión específicos, emita el siguiente comando:
Cambiar (config) # ip pim rp-candidate lista de tipo de interfaz número de interfaz ttl
acceso a la lista de grupos
El ejemplo 7-1 muestra una configuración de muestra del modo disperso de PIM en Cisco IOS con una
dirección RP de 10.20.1.254.
Ejemplo 7-1 Configuración del modo disperso de PIM en Cisco IOS
Número de enrutador conf.
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 modo
Router(config-if)# salir
Enrutador (config) # ip pim rp-dirección 10.20.1.254
El ejemplo 7-2 muestra una configuración de muestra del modo denso-disperso de PIM en Cisco IOS con un
BSR candidato.
Ejemplo 7-2 Configuración de multidifusión del modo disperso-denso con BSR
Router(config)# ip multicast-routing Router(config)# interface

vlan 1 Router(config-if)# ip pim sparse-dense-mode
Router(config-if)# exit
Enrutador (config) # ip pim bsr-candidate vlan 1 30 200
El ejemplo 7-3 muestra una configuración de muestra de Cisco IOS del Auto-RP que anuncia la
dirección IP de la VLAN 1 como el RP.
Ejemplo 7-3 Configuración de multidifusión IP del modo disperso-denso con Auto-RP
Enrutador (configuración) # ip enrutamiento de multidifusión
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 permiso 225.25.25.0.0.0.0.255 Router(config)# exit
Además de los comandos anteriores, todos los conmutadores de Cisco admiten funciones adicionales de ajuste de
multidifusión, como la limitación de velocidad y la modificación de los temporizadores de protocolo. Consulte la
documentación del producto para obtener más información.
Preparación de la infraestructura del campus para soportar la tecnología inalámbrica
Como se señaló anteriormente, las WLAN reemplazan el medio de transmisión de Capa 1 de una
transmisión de radio de red alámbrica tradicional por aire. Esta sección se centra en el escenario
específico en torno a la implementación de una red de campus.
Parámetros de LAN inalámbrica
El soporte inalámbrico requiere una preparación WLAN adicional más allá de la implementación de la red del
campus. Ante todo, el alcance, la interferencia, el rendimiento y la seguridad deben planificarse y prepararse
adecuadamente antes de la integración de la solución en la red del campus. Esta sección se centra en la
implementación inalámbrica en términos de su conectividad de red a los conmutadores de Cisco. La
planificación del alcance inalámbrico, la interferencia, el rendimiento y la seguridad están fuera del alcance de
este libro. La siguiente sección comienza con la discusión sobre la preparación de la red del campus para
admitir la conexión inalámbrica con la solución WLAN independiente.
Configuración de conmutadores para admitir WLAN
La configuración para admitir WLAN en el campus se divide en dos secciones que se centran en la
solución independiente y la basada en controlador, respectivamente.
Preparación de la red del campus para la integración de una solución WLAN independiente
La configuración del puerto del conmutador de la capa de acceso para los puntos de acceso independientes
es sencilla. Como práctica recomendada, el conmutador y la interfaz del puerto de acceso se configuran
como un puerto troncal y llevan al menos una VLAN de administración y datos. La VLAN de administración se
utiliza con fines administrativos y puede ser o no la VLAN nativa. Puede haber una o más VLAN de datos. Si
hay más de una VLAN, cada VLAN estará asociada a diferentes SSID. Al asociarse a uno de los SSID
disponibles, el cliente inalámbrico se convierte en una estación dentro de la VLAN y la subred IP asociada.
Para obtener más información sobre los SSID, consulte la información básica de WLAN en Cisco.com.
Además, el conmutador puede configurarse para admitir Power over Ethernet (PoE); sin embargo, PoE no es un
requisito, sino una función para facilitar las instalaciones. PoE se cubre más en la siguiente sección sobre voz en la
red del campus, ya que PoE se asocia más comúnmente con las instalaciones de voz. Por último, como ocurre con
cualquier implementación de WLAN, un servidor DHCP proporciona direcciones IP, DNS, etc. para los puntos de
acceso y los clientes inalámbricos.
En la figura 7-35 se ilustra un modelo de esta integración.
DHCP
Servidor
Troncal 802.1Q/PoE
Figura 7-35 Solución WLAN independiente integrada en la red del campus
Preparación de la red del campus para la integración de una solución WLAN basada en
controlador
Al igual que con la solución WLAN independiente, el conmutador y la interfaz del puerto de acceso
están configurados como puerto troncal y transportan al menos una VLAN de administración y datos.
La VLAN de administración se utiliza con fines administrativos y puede ser o no la VLAN nativa. Puede
haber una o más VLAN de datos.
Cabe destacar que no es necesario que las VLAN configuradas en los puntos de acceso sean las mismas VLAN
configuradas en el controlador. Esto se debe a que el controlador y los puntos de acceso pueden estar en
diferentes subredes IP.
A diferencia de la solución WLAN independiente, el controlador WLAN realiza la asignación

de la subred SSID, VLAN, QoS e IP. Cuando un cliente se asocia a un SSID en
un punto de acceso, el cliente se convierte en una estación dentro de esa VLAN y la subred
asociada conectada al controlador WLAN. Luego, el cliente inalámbrico obtiene una dirección IP
de la VLAN conectada al controlador de WLAN que se asigna al SSID utilizado por el cliente.
Cualquier VLAN se puede conectar al punto de acceso. Todo el tráfico que llega al punto de acceso se
encapsula y se envía al controlador. Por lo tanto, se hace una clara diferenciación entre la VLAN del cliente
y la VLAN del punto de acceso. Por lo tanto, el punto de acceso y el controlador WLAN pueden estar en la
misma subred IP o en diferentes, y puede haber un enrutador IP de capa 3 entre el punto de acceso y el
controlador WLAN.
En esta configuración, el controlador WLAN admite la itinerancia de capa 2 y capa 3, ya sea que los puntos
de acceso se conecten al mismo controlador o a diferentes controladores que formen parte del mismo
grupo. La figura 7-36 ilustra el comportamiento de la solución basada en controlador descrita.
VLAN de datos
Túnel LWAPP Troncal 802.1Q
VLAN de voz
Ligero WiFi VLAN de gestión

Punto de acceso Controlador
Figura 7-36 Solución WLAN basada en controlador integrada en la red del campus
En el caso de un HREAP, algunas WLAN se conmutan de forma centralizada, lo que significa que los datos de
estas WLAN se encapsulan y se envían al controlador, al igual que un punto de acceso estándar basado en
un controlador. Algunas otras WLAN se conmutan localmente, lo que significa que el tráfico se envía al
conmutador local al HREAP y no se envía al controlador.
La consecuencia de este comportamiento es que el puerto a un HREAP debe ser un enlace troncal
802.1Q. La VLAN nativa es la VLAN HREAP que se comunica con el controlador.
Nota Se requieren listas de acceso y firewalls en la red para habilitar el tráfico entre controladores,
puntos de acceso y estaciones de administración para el funcionamiento exitoso de una red
inalámbrica. Consulte Cisco.com para obtener información adicional sobre qué puertos TCP y UDP
deben permitirse a través de listas de acceso y firewalls para cualquier solución WLAN.
En resumen, la configuración de los switches Cisco conectados a los puntos de acceso son simplemente puertos
troncales. Los capítulos anteriores cubrieron la configuración específica de los puertos troncales; revise los detalles de
configuración en esos capítulos para una configuración específica externa. La siguiente sección repasa los detalles de
preparación para la voz.

Preparación de la infraestructura del campus para soportar la voz

La implementación de voz en una red de campus requiere una estrecha cooperación entre los
ingenieros de red y el especialista en voz empresarial. La integración de voz debe planificarse
minuciosamente para integrarse perfectamente en una red de campus existente. Cuando llegue a la
fase de implementación, debe configurar los conmutadores de acceso para la compatibilidad con VoIP.
Esta sección describe el paso involucrado en la configuración necesaria para admitir VoIP en los
conmutadores del campus. También describe un plan de prueba simple que se puede usar para que un
teléfono se comunique e integre correctamente a la infraestructura de la red.
Componentes de telefonía IP
La siguiente lista de componentes de telefonía IP revisa los dispositivos que se encuentran comúnmente
implementados en las redes del campus:
■ Teléfonos IP:Soporte de llamadas en una red de telefonía IP. Realizan codificación y compresión de voz a IP
(y viceversa) utilizando hardware especial. Los teléfonos IP ofrecen servicios como búsquedas en
directorios de usuarios y acceso a Internet para cotizaciones de acciones. Los teléfonos son dispositivos de
red activos y requieren energía para su funcionamiento. Por lo general, una conexión de red o una fuente
de alimentación externa proporciona la energía.
■ Interruptores con alimentación en línea:Habilite una infraestructura de armario de cableado modular para
proporcionar energía centralizada para las redes de telefonía IP de Cisco. Estos conmutadores son similares
a los conmutadores tradicionales, con la opción de proporcionar energía a los puertos LAN donde se
conectan los teléfonos IP. Además, realizan algunos mecanismos QoS básicos, como la clasificación de
paquetes, que es una línea de base para priorizar la voz a través de la red.
■ Gerente de procesamiento de llamadas:Cisco Unified Communications Manager proporciona central

control de llamadas y gestión de configuración para Teléfonos IP. Cisco Unified Communications Manager
proporciona la funcionalidad principal para inicializar los dispositivos de telefonía IP y realizar la
configuración y el enrutamiento de llamadas en toda la red. Cisco Unified Communications Manager
admite la agrupación en clústeres, lo que proporciona un modelo de telefonía IP distribuido, escalable y de
alta disponibilidad. En redes pequeñas o remotas, Cisco ofrece una solución basada en enrutadores para el
procesamiento de llamadas. Esta solución se conoce como Cisco Unified Communications Manager
Express (CUCME).
■ Pasarela de voz:También llamados enrutadores o conmutadores habilitados para voz, las puertas de enlace de voz brindan
servicios de voz, como codificación y compresión de voz a IP, acceso a PSTN, enrutamiento de paquetes IP, procesamiento de
llamadas de respaldo y servicios de voz. El procesamiento de llamadas de respaldo permite que las puertas de enlace de voz se
hagan cargo del procesamiento de llamadas si falla el administrador de procesamiento de llamadas principal. Por lo general,
las puertas de enlace de voz admiten un subconjunto de la funcionalidad de procesamiento de llamadas admitida por CUCM.
Recuerde de la sección de planificación de voz de este capítulo que el tráfico de voz tiene requisitos específicos. El
flujo de voz necesita un ritmo constante y un ancho de banda constante para funcionar sin demoras ni problemas de
inestabilidad. Por lo tanto, el primer requisito para la integración del tráfico de voz es implementar QoS, que aborde
los requisitos de ancho de banda, demora, fluctuación y pérdida de paquetes.
QoS no resuelve los problemas de ancho de banda per se. QoS solo puede priorizar paquetes. Cuando la congestión
es severa, es posible que QoS ya no sea suficiente para garantizar la calidad del tráfico de voz.
Configuración de conmutadores para admitir VoIP
Desde la perspectiva del conmutador, los conmutadores de Cisco generalmente aplican tres opciones de configuración
para admitir VoIP:
■ VLAN de voz
■ QoS
■ Potencia de Ethernet (PoE)
Las siguientes tres secciones discuten estas características con más detalle.
Cuando se implementa este marco, se puede agregar una configuración específica de voz. En la capa de
acceso, PoE se configura si es necesario. Luego, desde los puertos de acceso y en toda la red, QoS se
configura para abarcar el flujo de voz. AutoQoS se puede utilizar para configurar políticas de QoS para
VoIP en los puertos de acceso y los enlaces troncales.
Dado que la demora es una preocupación permanente, asegúrese de que la alta disponibilidad esté configurada en toda la
red y que los temporizadores de conmutación por error estén configurados en un valor corto para minimizar el impacto de
un dispositivo perdido en las conversaciones de voz en curso.
VLAN de voz
Los switches de Cisco ofrecen una característica única llamada VLAN de voz, alternativamente llamada VLAN
auxiliar. La función de VLAN de voz le permite superponer una topología de voz en una red de datos:
trabaje sin inconvenientes. Las VLAN de voz proporcionan redes lógicas, aunque la infraestructura de datos
y voz sea físicamente la misma.
Nota Las VLAN de voz permiten la separación lógica del tráfico de voz de los teléfonos IP o dispositivos de
red de voz en la misma red física que el tráfico de datos. Las VLAN de voz son opcionales pero muy
recomendables para cualquier implementación de red de campus.
La función VLAN de voz coloca los teléfonos en sus propias VLAN sin intervención del usuario final en el
teléfono IP. Estas asignaciones de VLAN se pueden mantener sin problemas, incluso si el teléfono se
traslada a una nueva ubicación. El usuario simplemente conecta el teléfono al conmutador y el
conmutador proporciona al teléfono la información de VLAN necesaria a través del Protocolo de
descubrimiento de Cisco (CDP). Al colocar los teléfonos en sus propias VLAN, los administradores de red
obtienen las ventajas de la segmentación y el control de la red. Además, los administradores de red
pueden conservar su topología IP existente para las estaciones finales de datos. Los teléfonos IP se
pueden asignar fácilmente a diferentes subredes IP utilizando una operación DHCP basada en
estándares.
Con los teléfonos en sus propias subredes IP y VLAN, los administradores de red pueden identificar
y solucionar problemas de red más fácilmente. Además, los administradores de red pueden crear y
aplicar QoS o políticas de seguridad.
Con la función Voice VLAN, Cisco permite a los administradores de red obtener todas las ventajas
de la convergencia de infraestructura física mientras mantiene topologías lógicas separadas para
terminales de voz y datos. Esto crea la forma más efectiva de administrar una red multiservicio.
Si se adjunta una estación de trabajo de usuario final al teléfono IP de Cisco que se conecta a un conmutador
de Cisco con una configuración de VLAN de voz, el tráfico de la estación de trabajo del usuario se conmuta a
través del teléfono en la VLAN nativa, de manera predeterminada. La VLAN nativa no está etiquetada y es la
configuración de VLAN del puerto de switch real. El teléfono IP de Cisco envía tráfico con una etiqueta 802.1q si
se configura una VLAN de voz para una VLAN además de la VLAN nativa. La Figura 7-37 ilustra este
comportamiento.
Teléfono VLAN = 110 VLAN de PC = 10

(VIDEO) (PVID)
Encapsulación 802.1Q VLAN nativa (PVID)-

con 802.1p Sin configuración
CoS de capa 2 Cambios necesarios en la PC
• El teléfono IP se configura con un VVID durante el intercambio inicial del

Protocolo de descubrimiento de Cisco.
• El teléfono IP se reconoce en el momento mediante el protocolo de descubrimiento de Cisco.
Figura 7-37 VLAN de voz con varias VLAN
La función de VLAN de voz en los switches de Cisco utiliza una nomenclatura especial. El conmutador hace
referencia a la VLAN nativa para el tráfico de datos como ID de VLAN de puerto (PVID) y a la VLAN de voz
para el servicio de voz como ID de VLAN de voz (VVID). Además, el término VLAN de voz se puede
representar con el acrónimo VVLAN, y los switches Catalyst más antiguos pueden referirse a la VLAN de voz
como auxiliar, especialmente aquellos switches que ejecutan Cisco CatOS.
Los siguientes pasos resaltan los comandos para configurar y verificar la funcionalidad básica
de la función VLAN de voz:
Paso 1. Asegúrese de que QoS esté habilitado globalmente con el comandoqos mlsy entrar
el modo de configuración para la interfaz en la que desea configurar las
VLAN de voz.
Paso 2. Habilite la VLAN de voz en el puerto del switch y asocie una ID de VLAN usando
el comando de interfazvlan de voz de puerto de conmutaciónid-vlan.
Paso 3. Configure el puerto para que confíe en CoS o en DSCP a medida que las tramas lleguen al puerto del
switch mediante elmls qos confianza cosomls qos confianza dscpcomandos, respectivamente.
Recuerda que elmls qos confianza cosentrada de confianza CoS dondemls qos confianza dscp
Confíe en los valores DSCP de entrada. No confunda los dos comandos ya que cada uno
configura el interruptor para buscar diferentes bits en el marco para la clasificación.
Etapa 4. Verifique la configuración de VLAN de voz usando el comandomostrar interfaces

ID de interfazpuerto de conmutación.
Paso 5. Verifique la configuración de la interfaz QoS usando el comandomostrar qos mls

interfazID de interfaz.
En el ejemplo 7-4, la interfaz FastEthernet0/24 está configurada para configurar los dispositivos de datos en la VLAN 1 de
forma predeterminada y los dispositivos de VoIP en la VLAN 700 de voz. El conmutador utiliza CDP para informar a un
teléfono IP adjunto de la VLAN. Como el puerto conduce a un dispositivo final, portfast está habilitado. Consulte los
capítulos anteriores para obtener más información sobre el protocolo de árbol de expansión.
Ejemplo 7-4 Ejemplo de configuración de interfaz para VLAN de voz en Cisco IOS
(texto eliminado)
!
mls calidad de servicio
!
(texto borrado)
!
interfazFastEthernet0/24
switchport modo dinámico deseable

switchport voz vlan 700
mls qos confianza cos
poder en línea automático
portfast de árbol de expansión

!
(texto borrado)
!
QoS para tráfico de voz desde teléfonos IP

En una implementación de QoS de campus, los límites se definen donde los valores de QoS existentes de
las tramas se pueden aceptar (confiar) o modificar. Los switches de Cisco aplican configuraciones en estos
"límites de confianza" para hacer cumplir la clasificación y el marcado de QoS a medida que el tráfico
ingresa a la red. En estos límites, se permitirá opcionalmente que el tráfico conserve su marca QoS
original u opcionalmente se le asignará una nueva marca debido a las políticas asociadas con su punto de
entrada a la red.
Nota Cuando un conmutador que está configurado para QoS recibe una trama, el conmutador está
configurado para aceptar la marca DSCP y CoS de las tramas o alterar la marca DSCP o CoS de las tramas.
El término confianza desde el punto de vista de configuración de QoS de un puerto de conmutador implica que el
conmutador acepta cualquier valor DSCP o CoS recibido en su puerto.
Los límites de confianza establecen un límite para el tráfico que ingresa a la red del campus. A medida
que el tráfico atraviesa los conmutadores de la red del campus, se maneja y prioriza de acuerdo con las
marcas recibidas o confiables cuando el tráfico ingresó originalmente a la red en el límite de confianza.
En el dispositivo de límite de confianza, los valores de QoS son confiables si se considera que representan
con precisión el tipo de tráfico y el procesamiento de precedencia que el tráfico debe recibir al ingresar a la
red del campus.
Si no es de confianza, el tráfico se marca con un nuevo valor de QoS que es apropiado para la política vigente en el
punto donde el tráfico ingresa a la red del campus. Idealmente, el límite de confianza existe en el primer
conmutador que recibe tráfico de un dispositivo o teléfono IP. También es aceptable establecer el límite de
confianza como todo el tráfico de un conmutador de acceso que ingresa a un puerto de conmutador de capa de
distribución.
Para habilitar QoS en un conmutador, algunos modelos de conmutadores Cisco solo requieren que ingrese
cualquier comando de QoS; algunos otros necesitan tener el soporte de QoS habilitado globalmente a través del
comandomls qos.Consulte la guía de configuración de Cisco para su modelo específico del conmutador Cisco
para obtener más información.
En el Ejemplo 7-4, el soporte de QoS primero se habilita globalmente. Los valores de CoS recibidos del teléfono son
confiables y no se modifican.
Puedes usar elmostrar qos mlsfamilia de comandos para mostrar la configuración de QoS en modelos
específicos de switches Cisco. Consulte las guías de configuración del producto para su conmutador
específico.
Alimentación a través de Ethernet
Todos los dispositivos habilitados para VoIP necesitan una fuente de energía. Cuando estos dispositivos son dispositivos
portátiles o móviles, la fuente de energía suele ser una batería. Los teléfonos VoIP de escritorio o de pared se pueden
conectar a un adaptador de CA para obtener energía.
Aunque la energía está fácilmente disponible en un entorno de oficina, el uso de un enchufe de CA/CC por
dispositivo VoIP puede considerarse un desperdicio de recursos físicos. Debido a que el teléfono tiene una
conexión por cable al conmutador Ethernet, una solución lógica es usar este cable para proporcionar energía y
conectividad.
Esta configuración, llamada Power over Ethernet (PoE), implica que la energía proviene del cable Ethernet.
La fuente de esta energía puede ser el propio conmutador, si el conmutador es compatible con la función
PoE.
Si el conmutador no puede proporcionar energía, a menudo es posible instalar un dispositivo

intermedio entre el conmutador y el teléfono VoIP. Este dispositivo recibirá energía de una toma de
corriente y se conectará al interruptor con otro cable. Se conecta al puerto al que se supone que debe
conectarse el teléfono. Un tercer cable va desde este dispositivo intermedio hasta el
teléfono, proporcionando energía junto con la transmisión de datos hacia y desde el conmutador. Este dispositivo se llama
inyector de potencia.
Para disminuir el costo y la complejidad de la instalación, la alimentación de los dispositivos directamente desde
el conmutador a menudo se considera la mejor solución.
Una gran ventaja de PoE es que no se requiere electricista. Cualquier persona calificada para ejecutar cable de
categoría 5e puede instalar el cableado necesario para alimentar dispositivos habilitados para PoE. Se siguen
aplicando los requisitos de cable estándar de categoría 5e (máximo 328 pies o 100 metros).
Existen dos métodos PoE comunes: la alimentación en línea de Cisco y el estándar IEEE 802.3af. Cisco
inline power es preestándar porque el estándar IEEE 802.3 no incluía especificaciones para PoE. El grupo
de trabajo 802.3af modificó esta omisión y se creó un estándar en 2003. Cisco participó activamente en
el grupo de trabajo 802.3af y en el soporte del estándar de alimentación en línea IEEE. Una de las
principales diferencias es que 802.3af utiliza un mecanismo de detección de energía que detecta si el
dispositivo conectado necesita energía. La ratificación estándar de 802.3af se produjo el 11 de
septiembre de 2009.
Los nuevos dispositivos de Cisco (conmutadores, puntos de acceso) admiten ambos métodos para la
compatibilidad con versiones anteriores. No se requiere ninguna configuración específica para elegir el
preestándar de Cisco o el estándar 802.3af. El estándar IEEE 803.2af se mejorará con un nuevo estándar
802.3at, que proporcionará más potencia en el futuro.
Nota El protocolo Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP) es un nuevo protocolo
basado en estándares actualmente implementado en los productos de telefonía y conmutación de Cisco.
Este protocolo proporciona la capacidad para que los conmutadores reconozcan y suministren energía a
cualquier teléfono de proveedor conectado a la red.
Una solución provisional de Cisco denominada PoE mejorado proporciona hasta 20 W de potencia con los switches de la
serie E. Aunque la mayoría de los dispositivos pueden usar la energía suministrada por una fuente estándar 802.3af,
algunos dispositivos nuevos requieren más energía.
Los requisitos de energía para los puntos de acceso son específicos. Los teléfonos IP de Cisco utilizan menos de 15 vatios y se
pueden alimentar desde un conmutador 802.3af estándar.
La compatibilidad con PoE se realiza a nivel de puerto. El comandopoder en línea automáticoes suficiente para
habilitar PoE y la detección automática de los requisitos de alimentación. Un dispositivo que no necesita ningún
PoE aún se puede conectar a ese puerto: la alimentación se suministra solo si el dispositivo lo requiere. La
cantidad de energía suministrada se detectará automáticamente. Todavía tiene que planificar la energía total
consumida por todos los dispositivos conectados al conmutador PoE.
El comandomostrar poder en línea,como se muestra en el Ejemplo 7-5, muestra la configuración y las estadísticas
sobre la energía utilizada consumida por los dispositivos alimentados conectados y la capacidad de la fuente de
alimentación.
Ejemplo 7-5 Ejemplo de energía en línea
Switch# show power inline fastethernet 4/1

Disponible:665(w) Usado: 663 (ancho) Restante: 2 (w)
Administrador de interfaz oper Fuerza Dispositivo Clase
(vatios)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Fa4/ 1
encendido automático 5.0 Teléfono IP Cisco 7960 n/a
Interfaz AdminPowerMax AdminAsignación
(milivatios) (milivatios)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Fa4/1
15400 15400
Cambiar#
Cada conmutador tiene una cantidad máxima dedicada de energía disponible para PoE. La energía
utilizada por cada puerto PoE se deduce de la energía total disponible. La energía utilizada por cada
dispositivo se aprende dinámicamente a través de CDP. Esta función permite optimizar el consumo de
energía real, ya que un dispositivo PoE no siempre consume la cantidad máxima de energía que
necesita. Por ejemplo, un teléfono IP clasificado como de 15 vatios puede usar hasta 15 vatios cuando
se utiliza por completo, pero usa solo 6 o 7 vatios cuando está colgado.
Nota Preste mucha atención al presupuesto de energía y los requisitos de fuente de alimentación asociados porque muchos
diseñadores pasan por alto los requisitos de alimentación de PoE.
No obstante, si se dice que un teléfono requiere hasta 15 vatios, si la energía restante en el nivel del interruptor
es inferior a 15 vatios, el teléfono no recibirá energía en absoluto. Tenga en cuenta que no todos los
conmutadores tienen 15 vatios de potencia disponibles para todos los puertos. Algunos conmutadores tienen
todos los puertos PoE con 15 vatios cada uno (que es la potencia máxima posible según el protocolo 802.3af);
algunos otros tienen solo unos pocos puertos compatibles con PoE, y no todos ofrecen 15 vatios.
Cuando un dispositivo VoIP obtiene energía y accede a la red en la Capa 2, necesita obtener una
dirección IP. Como cualquier otro dispositivo cliente, puede obtener esta dirección IP a través de un
servidor DHCP.
Requisitos de red adicionales para VoIP

Un requisito adicional de los teléfonos IP de Cisco es que también necesitan descargar un archivo de
configuración específico que les puede proporcionar información de voz específica, como el códec a utilizar,
la ubicación del CUCM o CUCME. Este archivo de configuración se descarga mediante TFTP. La dirección IP
del servidor TFTP puede configurarse manualmente en cada teléfono IP de Cisco o proporcionarse como
una opción DHCP 150 (dirección del servidor TFTP).
El dispositivo VoIP luego descarga su archivo de configuración del servidor TFTP y también verifica si hay
disponible un firmware más nuevo. A continuación, intenta llegar a un servidor CUCM o CUCME. La dirección IP
de este servidor se puede proporcionar dentro del archivo de configuración o se puede aprovisionar a través
de DNS. Muchas implementaciones tienden a usar CUCM o CUCME como el
Servidor TFTP para simplificar el procedimiento general, eliminando así la necesidad de un servidor
TFTP externo y una resolución de DNS.
Cuando el teléfono se pone en contacto con CUCM o CUCME, se registra, obtiene su número de extensión
de línea y está listo para realizar o recibir llamadas.
Para probar la implementación de voz, se recomienda trabajar a través del proceso de arranque
lógico del teléfono.
Como cualquier otro dispositivo de red, un teléfono al arrancar necesita recibir energía. A continuación,
recibirá una dirección IP. Si la dirección IP se recibe a través de DHCP, la opción DHCP también debe
proporcionar la dirección IP de CUCM o CUCME. El teléfono descarga su configuración y firmware del
servidor de voz, antes de registrarse, obtener una extensión telefónica y está listo para realizar una
llamada.
Al probar una nueva implementación de VoIP, un esquema de prueba lógico es verificar que el
teléfono reciba energía; luego, una dirección IP realmente intenta llegar a CUCM o CUCME y se
registra allí. Cuando se completan todos estos pasos, el teléfono puede realizar y recibir
llamadas.
Preparación de la infraestructura del campus para apoyar el video

Como se discutió anteriormente, el video ya no está en su infancia, pero sigue siendo una tecnología en
crecimiento y evolución que brinda enormes beneficios a la empresa en formas de colaboración. Al
implementar esta tecnología en el campus, se deben considerar varias configuraciones de interruptores.
Esta sección revisa los componentes y aplicaciones de video y analiza algunas de las mejores prácticas para
el almacenamiento.
Componentes de vídeo
Los componentes de video se trataron en la sección de planificación sobre video de este capítulo. Como breve
resumen, la siguiente lista destaca las aplicaciones de video más comunes que se encuentran implementadas
en las redes del campus:
■ Vídeo punto a punto
■ telepresencia
■ Vigilancia IP
■ Sistemas de medios digitales
Los sistemas de vigilancia IP y de medios digitales no se trataron como aplicaciones de video en la sección de
planificación. Los sistemas de vigilancia IP graban video por motivos de seguridad. Las empresas de seguridad
de vigilancia tradicionales ahora ofrecen soluciones IP, y Cisco también ofrece su propia solución. Las soluciones
de vigilancia IP permiten funciones que no son típicas de la videovigilancia tradicional. Estas funciones incluyen
el archivo de video digital, la visualización bajo demanda y las actualizaciones de video por correo electrónico y
web.
Además, los sistemas de medios digitales ofrecen video como medio de comunicación. Cisco actualmente ofrece
un sistema de medios digitales que ofrece un conjunto completo de características que incluyen sistemas de
video social, señalización digital e IPTV. El sistema de medios digitales de Cisco está diseñado para el aprendizaje,
la comunicación y la colaboración.
Al igual que con el video punto a punto y TelePresence, los requisitos de disponibilidad y ancho de banda
de los sistemas de medios digitales y vigilancia IP deben tenerse en cuenta al diseñar una red de campus.
Configuración de interruptores para admitir video
Los conmutadores de Cisco no requieren ninguna configuración específica o estándar para admitir video. Sin embargo,
PoE es opcional para algunos modelos de cámaras de vigilancia IP, y las características de QoS pueden ser necesarias para
garantizar el ancho de banda o resolver problemas de congestión de tráfico causados por aplicaciones de alto ancho de
banda como TelePresence. Los objetivos recomendados de las mejores prácticas para la inestabilidad, la latencia y la
pérdida de paquetes de TelePresence o cualquier aplicación de video en tiempo real (interactivo) son los siguientes:
■ Pérdida de paquetes de menos del 0,5 por ciento
■ Jitter de menos de 10 ms unidireccional
■ Latencia de menos de 150 ms unidireccional
Como práctica recomendada para lograr estos objetivos para TelePresence u otras aplicaciones de video de
gran ancho de banda, considere implementar las configuraciones de QoS:
■ Clasifique y marque el tráfico utilizando DSCP lo más cerca posible de su borde, preferiblemente en el
conmutador de capa de acceso de primer salto. Si un host es de confianza, permita que los hosts de confianza
marquen su propio tráfico.
■ Confíe en QoS en cada interconmutador y cambie a enlaces de enrutador para preservar el marcado a medida que
las tramas viajan a través de la red. Consulte RFC4594 para obtener más información.
■ Limitar la cantidad de tráfico de voz y video en tiempo real al 33 por ciento de la capacidad del enlace; si es más alto
que esto, los datos de TelePresence podrían privar a otras aplicaciones, lo que resultaría en un rendimiento lento
o errático de las aplicaciones de datos.
■ Reserve al menos el 25 por ciento del ancho de banda del enlace para el tráfico de datos de mejor esfuerzo.
■ Implemente una clase Scavenger del 1 por ciento para ayudar a garantizar que las aplicaciones rebeldes no
dominen la clase de datos de mejor esfuerzo.
■ Utilice la cola de detección temprana aleatoria ponderada (WRED) basada en DSCP en todos los flujos de
TCP, siempre que sea posible.
La lista anterior es solo una sinopsis de alto nivel de algunas pautas de mejores prácticas para
TelePresence y otras aplicaciones de gran ancho de banda. Sin embargo, estas aplicaciones requieren
un análisis detallado de extremo a extremo de toda la red empresarial para preparar cualquier
implementación de QoS. Como tal, el contexto de QoS necesario para TelePresence está fuera del
alcance de este libro. Revise la documentación adicional en Cisco.com o consulte con un especialista
antes de implementar TelePresence en una red de campus.
Resumen
Este capítulo presentó temas relacionados con la implementación inalámbrica, de voz y de video en la red
del campus. Como es evidente por la cantidad de material presentado y la brevedad de algunos de los
temas cubiertos, debe consultar a especialistas, expertos y personas con experiencia en estas tecnologías
antes de planificar una implementación. La conmutación es un tema lo suficientemente amplio sin la
inclusión de estas tecnologías avanzadas.
No obstante, la siguiente lista resume varios puntos clave para la conexión inalámbrica, voz y video
de este capítulo:
■ Al planificar una implementación inalámbrica, considere detenidamente la solución WLAN

independiente y la solución basada en controlador. Para redes de más de unos pocos puntos de
acceso, la mejor práctica es utilizar una solución basada en controlador.
■ Cuando se prepare para una implementación inalámbrica, verifique la configuración del puerto de su conmutador
como un puerto de camión. Los puntos de acceso opcionalmente admiten enlaces troncales y transportan
múltiples VLAN. Los clientes inalámbricos pueden asignarse a diferentes SSID, que a su vez pueden transportarse
en diferentes VLAN.
■ Al planificar una implementación de voz en la red del campus, las guías de mejores prácticas
recomiendan el uso de QoS y el uso de una VLAN separada para el tráfico de voz. La alimentación a
través de Ethernet (PoE) es otra opción para alimentar los teléfonos IP de Cisco sin utilizar un
adaptador de CA/CC.
■ Al prepararse para la implementación de voz, asegúrese de configurar QoS lo más cerca posible del
puerto perimetral. Las guías de mejores prácticas recomiendan confiar en DSCP o CoS de las tramas
que ingresan al conmutador.
■ Al planificar una implementación de video, indique si la aplicación de video es video en tiempo real
o video a pedido. El video en tiempo real requiere baja latencia y envía tráfico en ráfagas con un
gran ancho de banda.
■ Al prepararse para una implementación de video como TelePresence, consulte con un especialista o
experto para asegurarse de que la red del campus cumpla con todos los requisitos en términos de ancho
de banda, QoS, etc.
Preguntas de revisión
Use las preguntas aquí para repasar lo que aprendió en este capítulo. Las respuestas correctas se encuentran en
el Apéndice A, “Respuestas a las preguntas de revisión del capítulo”.
1. Al planificar implementaciones de puntos de acceso en una LAN inalámbrica de una red de campus, ¿cuáles
son las dos soluciones de mejores prácticas de Cisco?
a. Soluciones WLAN independientes (soluciones autónomas)
b. Soluciones WLAN basadas en red
C. Soluciones WLAN basadas en controlador
d. Soluciones WLAN basadas en enrutadores de Internet
2. ¿Qué aplicaciones de video impulsan las implementaciones de video en la red del campus?
a. telepresencia
b. Formación y aprendizaje a distancia
C. Aulas virtuales
d. Vídeo a la carta
3. En una solución WLAN basada en controlador, ¿a través de qué dispositivo fluye todo el tráfico
cuando se comunica entre nodos inalámbricos?
a. WLSE
b. Servidor de radio
C. WLC
d. WCS
4. ¿Qué dispositivos pueden admitir alimentación a través de 802.3af?
a. Puntos de acceso
b. WLC
C. cámaras de vigilancia IP
d. Teléfonos IP de Cisco
5. Al planificar una implementación de LAN inalámbrica en una red de campus, ¿qué factor determina
generalmente si implementar una solución independiente o una solución basada en
controlador?
a. Variedad de diferentes modelos de clientes inalámbricos en uso, como Dell, HP, Intel, etc.
b. Número de conmutadores de acceso en el campus
C. Escala y tamaño de la LAN inalámbrica y luego el número de puntos de acceso necesarios
d. Requisitos de cifrado
6. Cuando un conmutador de Cisco se configura para una VLAN de voz, los teléfonos IP de Cisco
conectados aprenden el ID de VLAN de voz (VVID) ¿a través de qué mecanismo?
a. DHCP.
b. ARP.
C. CDP.
d. DNS.
mi. Ninguna de las anteriores. Los teléfonos IP de Cisco deben estar configurados estáticamente para las VLAN de
voz.
7. Al implementar voz (telefonía IP) y video en la red del campus, como mejor práctica, ¿en
qué parte de la red del campus se debe clasificar el tráfico de voz para QoS?
a. Capa de distribución
b. Capa central
C. Capa de acceso
8. ¿QoS no afecta el comportamiento de los flujos de tráfico en la red del campus a menos que se cumpla
una de las siguientes condiciones?
a. Hay congestión en la red.
b. Hay un exceso de ancho de banda disponible en la red.
C. La red utiliza canales de puerto.
d. La red utiliza troncales 802.1q para interconectar conmutadores.
9. Cuando un switch de Cisco asigna un valor de CoS a una trama entrante, ¿a qué componente de
QoS se asigna el procedimiento?
a. Clasificación y marcado
b. Conformación y vigilancia
C. Gestión de la congestión
d. Evitar la congestión
10. ¿Qué comando anula los valores de CoS en tramas de ingreso a 1?
a.mls qos dscp 1
b.mls qos confianza cos
C.ml cos 1
d.mls qos cos 1

11. ¿Cuál es el propósito de los límites de confianza?
a. Para determinar la clasificación de un paquete en una ubicación específica en la red.
b. Para determinar en qué parte de la red se descartan los paquetes.
C. Para determinar en qué parte de la red reclasificar los paquetes.
d. Es una configuración administrativa en la que se aceptan o no las designaciones de

prioridad de capa 2 o capa 3 de tramas o paquetes.
12. Considere un diseño de red en el que un servidor de video necesita una clase superior de servicio
para datos de video en comparación con otro tráfico de datos regular. El servidor no admite el
etiquetado 802.1q ni la configuración de bits en el campo IP para la prioridad. Además, el servidor
transmite otro tráfico de gestión además del vídeo. ¿Cuál de los siguientes componentes y
métodos de QoS priorizaría correctamente el tráfico del servidor de video?
a. Clasificación basada en puertos en la que la configuración establecería todas las tramas de entrada
del servidor en un valor DSCP de 36
b. Clasificación basada en puertos mediante un mapa de políticas que utiliza un mapa de clase con una ACL que
marca de manera distintiva los fotogramas para el tráfico de video con un valor DSCP de 36
C. Uso de un regulador para marcar todos los marcos del servidor por encima de una cierta tasa con un
valor DSCP de 36
d. Uso de una ACL de entrada para clasificar todos los marcos del servidor con un valor DSCP de 36
13. ¿Qué modelo de QoS requiere una configuración de extremo a extremo?
a. LFI
b. IntServ
C. DiffServ
d. Acondicionamiento del tráfico
14. ¿Cuáles son dos beneficios de la función VLAN de voz (auxiliar) de los switches Catalyst?
(Escoge dos.)
a. Reducción de la utilización del ancho de banda
b. Solución de problemas más fácil
C. Segmentación de datos y voz
d. Redundancia
15. ¿Cuál de las siguientes funciones se utiliza para distinguir el tráfico de VLAN de voz del tráfico de
acceso (datos) en un paquete? (Escoge dos.)
a. encapsulación ISL
b. DHCP
C. HSRP
d. etiquetado 802.1Q
mi. calificación
16. De forma predeterminada, los teléfonos IP de Cisco marcan el tráfico en la capa IP y en la capa 2. ¿Cuál de los
siguientes campos está marcado en el encabezado IP por los teléfonos IP de Cisco para indicar la prioridad en
la capa 3?
a. CoS
b. TTL
C. DSCP
d. Suma de verificación
mi. identificador
17. ¿Qué diferencia a la multidifusión IP de otros modos de transmisión?
a. La multidifusión IP envía paquetes a un solo host.
b. La multidifusión IP envía paquetes a grupos de hosts donde hosts específicos procesan el

paquete.
C. La multidifusión IP envía paquetes a todos los hosts de forma secuencial.
d. La multidifusión IP envía paquetes a todos los hosts simultáneamente.
18. ¿Cuál es una posible desventaja de los árboles de distribución de origen en comparación con los árboles de
distribución compartidos?
a. Latencia aumentada
b. Aumento de la sobrecarga de memoria
C. Cálculos de rutas subóptimas
d. Mayor utilización del ancho de banda

19. ¿Bajo qué condición debe elegir el modo disperso de PIM en lugar del modo
denso de PIM?
a. El ancho de banda es abundante.
b. El grupo de multidifusión tiene muchos miembros.
C. Los hosts del grupo de multidifusión están muy dispersos.
d. Casi todos los hosts de la red pertenecen al grupo de multidifusión.
20. ¿Qué versión de IGMP agrega compatibilidad con el filtrado de fuentes?
a. IGMPv1
b. IGMPv2
C. IGMPv3
d. IGMPv3 ligero
21. ¿Qué comando muestra correctamente el contenido de la tabla de enrutamiento de multidifusión IP?
a.mostrar ip mfib
b.Mostrar ruta IP
C.mostrar la tabla de rutas
d.muestre la interfaz ip pim
22. Al prepararse para una implementación de TelePresence en la red del campus, ¿cuál es la latencia
máxima que debe experimentar el flujo de tráfico unidireccional?
a. 1 segundo
b. 150 ms
C. 10 ms
d. 1 ms

CCNP SWITCH Foundation Learning Guide - En.es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

CCNP SWITCH Foundation Learning Guide - En.es

Cargado por

Copyright:

Formatos disponibles

Traducido del inglés al español - www.onlinedoctranslator.

Este capitulo cubre los siguientes topicos:

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

■ Comprender la calidad del servicio

■ Implementando IP Multicast en la Red del Campus

■ Preparación de la infraestructura del campus para soportar la tecnología inalámbrica

■ Preparación de la infraestructura del campus para soportar la voz

■ Preparación de la infraestructura del campus para apoyar el video

Planificación de aplicaciones inalámbricas, de voz y de video en la

El Propósito de las Implementaciones de Redes Inalámbricas en la Red del

como el correo electrónico.

■ Colaboración mejorada:Las redes inalámbricas permiten una colaboración de usuario mejorada a

■ Interconectividad de campus:Las redes inalámbricas tienen la capacidad de interconectar

El Propósito de la Voz en la Red de Campus

Esta consolidación representa ahorros sustanciales en equipos de capital y costos

■ Capacidad para aprovechar el acceso a nuevos dispositivos de comunicación:Usando tecnología de paquete-

El propósito de las implementaciones de video en la red del campus

■ Colaboración:Las tecnologías de videoconferencia como TelePresence y el soporte de video en

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

Introducción a las LAN inalámbricas (WLAN)

■ Infrarrojos (III):Altas velocidades de datos, menor costo y corta distancia

■ Espectro ensanchado:Cobertura limitada a campus, costo medio, velocidades de datos altas

■ Celular:Cobertura nacional y mundial de bajo a mediano costo (operador de telefonía

■ Banda ultraancha (UWB):Cobertura de alto ancho de banda de corto alcance

Como está implícito en la lista de métodos de comunicación, la tecnología inalámbrica en el campus

■ Banda de 900 MHz:902 MHz a 928 MHz

■ Banda de 2,4 GHz:2,4 GHz a 2,483 GHz

Radio de onda corta Transmisión FM

2,4-2,4835 GHz 5 GHz

Figura 7-1 Bandas de frecuencia sin licencia

(Red de área metropolitana)

CACEROLA LAN HOMBRE PÁLIDO

Estándar ds Bluetooth IEEE 802.11a/b/g, 802.16 G/M, GPRS,

Rango Corto Medio Medio largo Largo

Aplicaciones De igual a igual, Empresa Fijo, Último- PDA, Móvil

Figura 7-2 Tecnologías inalámbricas

■ Red de área metropolitana (MAN):Desplegado dentro de un área metropolitana, lo que permite la

de edad en el MAN es WiMAX. La información está disponible en Internet con respecto a

56 kbps Datos de circuitos y paquetes

9,6 kbps LAN inalámbricas PC de banda estrecha Satélite

Figura 7-3 Redes de datos inalámbricas

Soluciones WLAN de Cisco aplicadas a redes de campus

■ Plataforma de movilidad:Cisco ofrece puntos de acceso y puentes para empresas enmoquetadas,

■ Gestión de red de clase mundial:Cisco ofrece un sistema de administración de red (NMS) de

■ Servicios avanzados unificados:Cisco brinda soporte unificado de aplicaciones de vanguardia.

Aunque la información detallada y la configuración de estos elementos no son necesarios para la

Comparación y contraste de WLAN y LAN

Con Cisco WLAN, los usuarios móviles pueden

■ Moverse libremente por una instalación

■ Accede a todos los recursos de las LAN alámbricas

LAN Ethernet. La detección de colisiones no es posible porque una estación emisora no

■ En las WLAN, los clientes móviles se utilizan para conectarse a la red.

■ Los dispositivos móviles a menudo funcionan con baterías.

Enfoques autónomos versus basados en controladores para implementaciones de WLAN en

Sinónimo de su denominación, la solución WLAN independiente utiliza puntos de acceso independientes

Solución WLAN independiente

Figura 7-4 Solución WLAN independiente

Solución WLAN basada en controlador

■ Puntos de acceso basados en controladores.

energía a los puntos de acceso (PoE).

LOC WCS ACS

Figura 7-5 Solución WLAN basada en controlador

■ Cisco Wireless Control System (WCS) para la gestión de WLAN (recomendado).