Protocolo de reserva de recursos

De Wikipedia, la enciclopedia libre

Saltar a navegación, búsqueda
«RSVP» redirige aquí. Para la fórmula protocolaria y de etiqueta social, véase Rsvp.

El protocolo de reserva de recursos (RSVP), descrito en RFC 2205, es unprotocolo de la

capa de transporte diseñado para reservar recursos de una red bajo la arquitectura de
servicios integrados (IntServ). "RSVP no es una aplicación de transporte, es más bien
unprotocolo de control de internet, como ICMP, IGMP, oprotocolos de enrutamiento" -
RFC 2205. RSVP reserva los canales o rutas en redes internet para la transmisión por
unidifusión y multidifusión con escalabilidad y robustez.

RSVP puede ser utilizado tanto por hosts como por routers para pedir o entregar niveles
específicos de calidad de servicio (QoS) para los flujos de datos de las aplicaciones. RSVP
define cómo deben hacer las reservas las aplicaciones y cómo liberar los recursos
reservados una vez que han terminado. Lasoperaciones RSVP generalmente dan como
resultado una reserva de recursos en cada nodo a lo largo de un camino.

RSVP no es en sí mismo unprotocolo de encaminamiento y fue diseñado para interoperar

con los actuales y futurosprotocolos de encaminamiento.

RSVP por sí mismo rara vez es desplegado en redes de telecomunicaciones hoy en día pero
para RSVP-TE, está comenzando a aceptarse de forma más común en muchas redes con
QoS.

Mensajes

Hay dos tipos principales de mensajes:

• Ruta de los mensajes (ruta)

La ruta de los mensajes es enviada por el remitente de acogida a lo

largo de la ruta de datos y almacena la ruta estatal en cada nodo a lo
largo de la ruta.
La ruta estatal incluye la dirección IP del nodo anterior, y algunos objetos
de datos:

1. Plantilla remitente para describir el formato de los datos de

remitente.
2. Tspec remitente para describir las características de tráfico
del flujo de datos.
3. Adspec que lleva la publicidad de datos (véase el RFC 2210
para más detalles).
 • Reserva de mensajes (resv)

La reserva de mensajes se envía desde el receptor al remitente de

acogida a lo largo de la ruta inversa de datos.
La reserva de mensajes incluye el flowspec objeto de datos que
identifica los recursos del flujo de necesidades.

Los datos sobre los mensajes RSVP se pueden transmitir en cualquier orden. Para la lista
completa de los mensajes RSVP y fecha objetos consulte RFC 2205.

[editar] Operaciones

Es necesario que una acogida envie un flujo de datos específicos con QoS transmitirá a
RSVP una vía mensaje que viajará a lo largo de las rutas de unidifusión y multidifusión
previamente establecido por elprotocolo de enrutamiento de trabajo. Si la ruta mensaje
llega a un router que no entiende RSVP, el router envía el mensaje sin interpretar el
contenido del mensaje y la no reserva de los recursos para la corriente.

Cuando el destino router recibe el camino mensaje:

1. Hacer una reserva sobre la base de parámetros de la petición. Para este

control de la admisión y las políticas de control de parámetros de
proceso de la solicitud puede encargar el clasificador de paquetes para
manejar correctamente el subconjunto seleccionado de paquetes de
datos o de negociar con la capa superior de la forma en que el paquete
de manejo se debe realizar.
2. Adelante la solicitud aguas arriba (en la dirección del remitente). En
cada nodo de la resv mensaje, flowspec puede ser modificado por un
nodo de transmisión.

Cada nodo en el camino puede aceptar o rechazar la petición.

• Modo de operación de RSVP

Protocolo de la gerencia del grupo del Internet (IGMP) es a protocolo de comunicaciones

manejaban la calidad de miembro de Internet Protocol multicastgrupos.IGMP se utiliza cerca IP

anfitriones y adyacente multicast rebajadoras para establecer calidades de miembro de grupo del

multicast.

Es una parte integral de Multicast del IP especificación, funcionando sobre capa de red, aunque no

actúa realmente como a protocolo del transporte[1]. Es análogo a ICMP para unicastconexiones.IGMP

se puede utilizar para en línea vídeo que fluyey el juego, y permite un uso más eficiente de recursos al

apoyar estos tipos de usos.IGMP permite algunos ataques[2] , y los cortafuegos permiten
[3] [4] [5]

comúnmente que el usuario lo inhabilite si no necesitaron.

2.7 IGMP("Internet Group Management Protocol")

IGMP es un protocolo estándar con un número STD de 5 que incluye además a IP(ver
IP("Internet Protocol")) e ICMP (ver ICMP("Internet Control Message Protocol")). Su
status es recomendado y el RFC 1112 lo describe.

Note: IP e ICMP son requeridos.

IGMPse considera más bien como una extensión de ICMP y ocupa el mismo lugar en la
pila de protocolos IP. (3)

Ver Multicasting para una introducción al multicasting.

2.7.1 Mensajes IGMP

Los mensajes ICMP se envían en datagramas IP. La cabecera IP siempre tendrá un número
de protocolo igual a 2, indicando IGMP y un tipo de servicio cero(rutina). El campo de
datos IP contendrá el mensaje IGMP de ocho bytes mostrado en Figura - Formato del
mensaje ICMP.

Figura: Formato del mensaje ICMP

Donde:

Vers

4 bits que indican la versión IP. Siempre vale 1.

Type

Especifica que se trata de una consulta o de un informe.

Especifica una consulta enviada por un "router" multicast.

Especifica un informe enviado por un host.

Checksum
 Un checksum de 16 bits calculado de igual forma que con ICMP.

Class D Address

Es cero para una solicitud, y es una dirección de grupo multicast válida

para un informe.

2.7.2 Funcionamiento de IGMP

Los sistemas que participan en IGMP se clasifican en dos tipos: host y "routers" multicast.

Como se describió en Multicasting, con el fin de recibir datagramas de multicast, un host se

debe unir a un grupo. Cuando un host es "multi-homed"(multipuerto), puede unirse a
cualquier grupo por una o más de sus interfaces(redes a las que está conectado). Los
mensajes multicast que recibe el host del mismo grupo en dos subredes distintas pueden ser
distintos también. Por ejemplo, 244.0.0.1 es el grupo para "todos los host de esta subred",
por lo que los mensajes recibidos en una subred siempre serán diferentes para este grupo
que para los de otra subred. Puede haber múltiples procesos en un host a la escucha de
mensajes para un grupo de multicast. Si es este el caso, los host se unen sólo una vez al
grupo, y llevan la cuenta internamente de qué procesos están interesados en ese grupo.

Para unirse a un grupo, el host envía un informe acerca de una interfaz. El informe se dirige
al grupo multicast interesado. Los "routers" multicast de la misma red reciben el informe y
activan un flag para indicar que al menos un host de esa red es miembro de ese grupo. Todo
host pertenece al grupo 224.0.0.1 de forma automática. Los "routers" multicast tienen que
escuchar a todas las direcciones de multicast(todos los grupos) con el fin de detectar tales
informes. Las alternativas serían el uso del broadcast para los informes o para configurar
host con direcciones unicast para "routers" multicast.

Los "routers" multicast envían regularmente(el RFC 1112 menciona intervalos de 1

minuto) una consulta a la dirección de multicast "todos los hosts". Cada host que aún desee
ser miembro de uno o más grupo replica una vez por cada grupo en el que esté
interesado(nunca al grupo "todos los hosts", al que pertenece de modo automático). Cada
respuesta se envía tras un intervalo de tiempo aleatorio para evitar aglomeraciones en el
tráfico. Como a los "routers" no les importa cuántos hosts son miembro de un grupo y
como todos los miembros de ese grupo pueden oír las respuestas de cada uno de los demás
hosts, cualquier host que escuche a otro host proclamar su pertenencia a mismo grupo
cancelará su respuesta para ahorrar recursos. Si ningún host responde dentro de un intervalo
de tiempo dado, el "router" multicast decide que ningún host pertenece a ese grupo. Cuando
un host o un "router" multicast recibe un datagrama multicast, su acción depende del valor
TTL y de la dirección IP de destino.

Un datagrama enviado con un valor TTL de cero se restringe el host

emisor.
1

Un datagrama con un TTL de uno alcanza todos los hosts de la subred

que son miembros del grupo. Los "router" multicast decrementan el
valor a cero, pero a diferencia de los datagramas unicast, no lo informan
con un mensaje ICMP "Time Exceeded". La expiración de un datagrama
multicast se considera un evento normal.

2+

Todos los hosts que sean miembros del grupo y todos los "routers"
multicast reciben el datagrama. La acción de los "router" depende de la
dirección del grupo multicast.

224.0.0.0 - 224.0.0.255

Este rango se emplea sólo para aplicaciones multicast que hagan uso de
un único salto. Los "routers" multicast no retransmitirán datagramas con
direcciones IP en este rango.

A primera vista puede parecer como si un no tuviera que molestarse en

informar de la pertenencia a un grupo en este rango ya que los "router"
no le retransmitirán los de otras subredes. Sin embargo, el informe
indica además a otros host de la subred que el host informante es
miembro del grupo. El único grupo del que nunca se da parte es el
224.0.0.1.

other

El "router" retransmite normalmente los datagramas con otros valores

para la dirección de destino: el valor TTL se decrementa en al menos un
segundo, como es habitual.

Esto permite a un host localizar al servidor más cercano que esté

escuchando sobre un dirección multicast usando lo que se llama
"expanding ring search"(búsqueda expansiva en anillo). El host envía un
datagrama con un valor TTL de 1(misma subred) y espera una
respuesta. Si no se recibe ninguno, prueba con un TTL de 2, luego de 3,
etc. Al final encontrará al servidor más cercano. (4)

1.- Introducción
MBone (Multicast Backbone On Internet) existe desde 1992 como una red virtual para la
experimentación del uso del IP Multicast en Internet. Esta red se ha empleado mayoritariamente para el
estudio de herramientas de audio/vídeo conferencias multipunto, aunque en principio puede ser
empleada para el intercambio de cualquier tipo de información multimedia. Su principal ventaja, o
debiéramos decir característica, es la de proporcionar el intercambio de información de uno a muchos,
pero sin los inconvenientes de tener que duplicar dicha información para cada uno de los receptores y
en función del número de ellos.
Si esta red virtual se implantó inicialmente hace bastantes años, ¿Por qué no ha abandonado aún su
calidad de experimental y se ha convertido en un servicio operativo? Pues principalmente por ser una
`red virtual'; una red creada como la unión de múltiples `islas' interconectadas entre sí. Esto es así
debido bien a que la mayor parte de equipos de comunicaciones que interconectan la infinidad de redes
que forman Internet aun no hablan el lenguaje del MBone, es decir, el IP Multicast, o lo hacen de forma
incompatible con otros. Pese a que el panorama está cambiando muy rápidamente y que un gran
número de ingenieros, tanto de empresas privadas como pertenecientes al ámbito académico y/o
investigador, se están esforzando conjuntamente para convertir este experimento global en un servicio
operativo, aún existen ciertas complicaciones que apuntan a que MBone seguirá siendo por el momento
una red experimental en la Internet. Esto, evidentemente, no quiere decir que los conceptos de MBone
no puedan ser empleados con éxito y de manera totalmente funcional dentro de redes corporativas o
incluso entre distintas intranets, sino que el objetivo final, el hacer de las comunicaciones multicast algo
inherente a Internet, es algo que aún está lejano. Más adelante volveremos sobre este tema, pero antes
debemos presentar ciertos conceptos que forman la base tecnológica de MBone.

2.- ¿Qué es y cómo funciona el IP Multicast?

Internet es una red en la que el intercambio de información entre equipos locales o remotos se hace a
través de datagramas IP Internet Protocol). Un datagrama IP (o paquete IP) podríamos decir que es la
unidad mínima de información en el lenguaje que hablan todos los equipos que forman parte de Internet.
Estos datagramas IP están formados principalmente por una dirección origen y una dirección destino, y
cada equipo de comunicaciones situado en la ruta entre ambos se encarga de enviar dicho datagrama
por el camino adecuado. Esto implica que cada estación conectada a Internet debe tener una dirección
que la identifique, lo que se llama dirección IP, y constituye un sello de identidad global y único para
cada equipo en Internet.

Pueden clasificarse en tres tipos en función de la dirección de destino:

• IP unicast: La dirección corresponde a un solo receptor y será éste el único que procese los
datagramas IP con ese destino (conexión uno-a-uno).
• IP broadcast: La dirección corresponde a todos los equipos conectados en un mismo tramo de
red local y el datagrama IP es procesado por todos ellos (conexión uno-a-todos dentro de la
misma subred).
• IP multicast: La dirección corresponde a un grupo de equipos, y sólo estos procesarán los
datagramas IP con ese destino (conexión uno-a-muchos, o uno-a-varios).

Cuando un equipo envía un datagrama IP a una determinada dirección IP multicast, sólo es recibida por
aquellos equipos que están a la escucha de esa dirección y, que por tanto, son capaces de entender las
direcciones multicast.

El concepto de direcciones multicast fue una idea original de Steve Deering que describió en su tesis
doctoral en la Universidad de Stanford, y que más tarde continuó desarrollando en el Centro de
Investigación de Xerox en Palo Alto (Xerox PARC). Van Jacobson, de los laboratorios Lawrence
Berkeley (LBL), Steve Casner, del ISI (Information Science Institute) así como varios ingenieros más, se
interesaron por continuar el estudio iniciado por Steve Deering y su implantación experimental en
Internet. Resultado de estas investigaciones fue la publicación del RFC 1112, en el que se definen los
requisitos necesarios que debe cumplir un equipo para poder `hablar' IP multicast.

En 1992, durante una de las reuniones periódicas de coordinación del grupo de trabajo de redes
(Network Working Group) del IETF (Internet Engineering Task Force), se adoptó la implantación
experimental del IP multicast en Internet, reservándose un rango de direcciones IP para el mismo (clase
D de direcciones). Este fue el nacimiento del MBone.

En los comienzos del MBone, pocos ordenadores eran capaces de entender dichas direcciones
multicast. La mayor parte de estos equipos han sido aquellos basados en el sistema operativo UNIX (en
cualquiera de sus variantes) dada la gran flexibilidad del mismo para realizar modificaciones a bajo nivel,
al ser este un sistema operativo compilado del que se puede disponer de los códigos fuentes con cierta
facilidad, o al menos las partes necesarias para acceder directamente a los dispositivos de
comunicaciones. En la actualidad, estos requisitos están implementados (o al menos están disponibles
las herramientas para activarlos) en la gran mayoría de sistemas operativos que incluyen soporte de
comunicaciones para redes TCP/IP: Windows95, WindowsNT, UNIX (todas sus variantes), MacOS, etc.
Es muy probable que, en un futuro no muy lejano, la posibilidad multicast sea un requerimiento básico
de cualquier equipo conectado a Internet.

Volviendo al tema de cómo funciona el IP multicast, decíamos que cuando un ordenador envía un
datagrama IP multicast, este sólo lo recibe un grupo determinado de equipos, mientras que el resto
sencillamente lo ignoran. Para ello es necesario que el ordenador permita, a las aplicaciones que hacen
uso del multicast, configurar el dispositivo de red para recibir, no sólo los datagramas que van
destinados a su dirección IP, como es habitual, sino también aquellos que van destinados a una
determinada dirección multicast. Del mismo modo, se debe poder indicar al dispositivo de red, que deje
de recibir los datagramas de una determina dirección multicast. Estas acciones de unirse (join) o
abandonar (leave) una determinada dirección multicast, también son significativas para los dispositivos
que encaminan los datagramas multicast entre varias subredes (mrouters) y son realizadas por medio
de un protocolo sencillo llamado IGMP (Internet Group Management Protocol), del que hablaremos más
adelante.

Las direcciones IP multicast se suelen denominar `grupo multicast', ya que no están asignadas a un
equipo concreto de forma permanente, sino a un grupo determinado y de forma temporal. Por otro lado,
no es necesario que un equipo pertenezca a un grupo concreto multicast para enviar datagramas al
mismo.

Las direcciones IP multicast, que todo equipo conectado a MBone debe saber reconocer (además de
ser capaces de hablar IGMP, que describiremos más adelante, y de poder enviar y recibir datagramas
UDP a una dirección multicast), forman una clase de direccionamiento llamada clase D, que se
caracteriza porque todas estas direcciones comienzan con el prefijo binario 1110. La siguiente tabla
muestra las diferentes clases de direcciones IP en Internet tanto en binario como en la clásica notación
decimal de cuatro octetos decimales separados por puntos

Tipo Dirección en binario Rango en decimal

-------------------------------------------------------------------------
----------
Clase A 0bbbbbbb bbbbbbbb bbbbbbbb 0.0.0.0 a
127.255.255.255
Clase B 10bbbbbb bbbbbbbb bbbbbbbb 128.0.0.0 a
191.255.255.255
Clase C 110bbbbb bbbbbbbb bbbbbbbb 192.0.0.0 a
223.255.255.255
Clase D 1110bbbb bbbbbbbb bbbbbbbb 224.0.0.0 a
239.255.255.255
Clase E 11110bbb bbbbbbbb bbbbbbbb 240.0.0. a
247.255.255.255

De todas las direcciones IP multicast posibles, algunas están reservadas para uso interno por equipos
de comunicaciones que intercambian información sobre multicast (u otros usos), otras para uso local
dentro de Intranets, otras para controlar el alcance de distribución de multicast en base a criterios
administrativos, y las comprendidas en el rango: 224.2.0.0.0 - 224.2.255.255 son las que forman el
conjunto de direcciones IP multicast usadas en el MBone para las conferencias globales multimedia.
Dentro de este rango hay ciertas direcciones reservadas para los anuncios de sesiones multimedia (de
las que hablaremos cuando expliquemos el funcionamiento del SDR o directorio de sesiones MBone).
Una lista completa de las asignaciones de direcciones multicast se puede encontrar en el RFC 1700
sobre asignación de números en Internet publicado por la IANA (Internet Asigned Numbers Authority), o
sus sucesores. También se puede consultar en la siguiente dirección:
http://www.iana.org/iana/assignments.html

Los datagramas multicast son enviados hacia los miembros del grupo destino usando la misma fiabilidad
`best effort' que los datagramas IP unicast. Esto quiere decir que no existe garantía de que los
datagramas lleguen a su destino, ni de que lo hagan de forma ordenada. El protocolo de transporte
empleado es el UDP (User Datagram Protocol) que ofrece la ventaja de que al ser un protocolo ligero,
los datagramas sufren menos retrasos en alcanzar su destino. Sin embargo la demanda de aplicaciones
en tiempo real, como son las conferencias de audio y vídeo, si bien son tolerantes a perdidas de
paquetes, no lo son en cuanto a que estos lleguen de forma desordenada. Más adelante veremos como
se ha resuelto este problema en MBone.

Hasta ahora nos hemos podido hacer una idea de cómo funciona el IP multicast dentro de un segmento
de red local, pero ¿Cómo se propaga esta información a través de distintos tramos de red? o ampliando
el concepto ¿Cómo se aplica esto a la Internet dando forma a lo que se llama MBone?. Pues bien, esto
se realiza a través de los encaminadores (routers) que interconectan tanto múltiples segmentos de red,
como las múltiples redes que forman la Internet. Cuando un router esta cualificado para intercambiar
datagramas IP multicast con otro u otros, decimos que es un router multicast, o abreviadamente un
mrouter.

Un mrouter debe cumplir dos requisitos básicos:

• Debe tener un mecanismo para conocer en todo momento los equipos que pertenecen a un
determinado grupo multicast en cada una de las redes que interconecta.
• Para cada pareja {dirección IP origen (o fuente), grupo multicast} debe saber cómo encaminar
los datagramas, originados en esa dirección IP, a los segmentos de red donde haya otros
miembros de ese grupo multicast.

Lo primero se consigue con un determinado diálogo entre mrouters y ordenadores según un

determinado lenguaje, o técnicamente, un protocolo de comunicaciones. Este protocolo es el IGMP
(Internet Group Management Protocol), que debe implementar cualquier equipo que `hable' multicast
(ordenadores y mrouters).

Lo segundo se refiere a los criterios de encaminamiento multicast (multicast routing protocol) de los que
debe disponer el mrouter, y que presentaremos en la siguiente sección.

La primera implementación del IGMP fue publicada por Steve Deering en el RFC 1112 que hemos
mencionado antes, a mediados de 1989. Este fue remplazado, en noviembre de 1997, por el RFC 2236
que define la versión 2 del protocolo (IGMPv2), y en la actualidad el grupo de trabajo idmr (Inter-
Domain Multicast Routing) del IETF está trabajando en una nueva versión del mismo (versión 3).

Del mismo modo que el ICMP (Internet Control Message Protocol )(RFC 792), el IGMP (Internet Group
Membership Protocol) es una parte integral del IP. Los mensajes IGMP son transmitidos en datagramas
IP y tienen un tamaño fijo de 8 bytes. La siguiente figura muestra el formato de los mensajes IGMP.
El campo Tipoespecifica los diferentes mensajes IGMP posibles. El campo MRT(Maximun Response
Time) ha sido introducido en el IGMPv2 e indica el tiempo máximo de respuesta permitido a ciertos
mensajes. El checksumes un valor calculado en función de los valores de el mensaje IGMP en su
conjunto y se emplea para comprobar que no se hayan producido errores en la transmisión del mismo.
El último campo es la dirección del grupo multicast.

Los tipos de mensajes IGMP que utilizan ordenadores y mrouters para mantener informados a estos
últimos de la permanencia de los primeros dentro de cada grupo multicast, son los siguientes:

Valor (hex.) Tipo de mensaje Específico de...

------------------------------------------------------------------ 0x11
Consulta de filiación (Membership Query) IGMPv1,v2 y v3 0x12 Informe de
filiación (Membership Report) IGMPv1 0x16 Informe de filiación
(Membership Report) IGMPv2 0x17 Abandono de grupo (Leave group) IGMPv2
0x22 Informe de filiación (Membership Report) IGMPv3
El primero de ellos lo emplean los mrouters para consultar la filiación a cualquier grupo multicast, y lo
envían periódicamente por a un determinado grupo multicast: el 224.0.0.1. En caso de que existan
varios mrouters dentro de una determinada subred, será sólo uno de ellos el encargado de enviar los
mensajes IGMP de consulta de filiación (querier mrouter),este será el que tenga una dirección IP menor.

La dirección multicast 224.0.0.1 es una dirección reservada (asignada por la IANA), que se refiere a
todos los equipos multicast dentro de una misma subred, a la que pertenecen por defecto todos los
equipos que `hablan' multicast.

El resto de los mensajes son enviados por los ordenadores con destino a cada grupo multicast al que
pertenecen, para informar de su filiación a ese determinado grupo. Para evitar una avalancha de
respuestas por parte de los ordenadores miembros de cada grupo, se utiliza una técnica que consiste en
emplear una serie de temporizadores, inicializados a un valor aleatorio, que cada ordenador mantiene
para cada uno de los grupos multicast a los que pertenece. Sólo se responderá a las consultas de
filiación enviadas por los mrouters cuando dichos temporizadores se anulen, y en caso de que otro
ordenador responda antes, el resto de los que pertenecen a dicho grupo volverán a inicializar sus
temporizadores a unos valores aleatorios. De esta forma se consigue, sin colapsar la subred, que el
mrouter conozca si existen miembros activos en la misma.

En caso de que el ordenador no pertenezca a ningún grupo multicast, sencillamente ignora todos los
mensajes IGMP.

Para eludir prolongados tiempos de espera entre la emisión de las consultas de filiación por parte de los
mrouters y su correspondientes respuestas por parte del resto de los equipos, en la versión 2 del IGMP
se introdujo en los mensajes el valor MRT, o tiempo de respuesta máximo para cada consulta. Esto
evita, por otro lado, que se prolongue el tiempo que continúan enviándose datagramas multicast a un
segmento de red en el que no permanecen receptores activos.

En la versión 3 de este protocolo, que actualmente está en fase de estudio por parte del grupo de
trabajo idmr del IETF, se añade la funcionalidad de filtrado por origen, es decir, se permite la opción de
que los equipos multicast puedan expresar su interés en recibir datagramas multicast que provienen
sólo desde determinadas direcciones IP, o de cualquiera excepto de un número limitado de ellas.

Hay que remarcar que los mensajes IGMP se envían dentro de los datagramas IP con un valor de TTL
(Time To Live) igual a 1, para evitar que sean propagados por otros routers tradicionales (routers
unicast) más allá de la subred en la que se emiten, dado que por su definición, su utilidad es mantener
informados a los mrouters de los miembros activos dentro de una subred.

Los detalles de cómo se comportan ordenadores y mrouters en el diálogo IGMP están especificados en
las referencias [6] y [7] de las notas bibliográficas de este documento.
3.- ¿Cómo se encaminan los datagramas multicast?
Las ventajas de la idea del IP multicast se hacen patentes cuando podemos extender el esquema de
funcionamiento entre varias subredes, es decir, cuando los miembros de un determinado grupo multicast
están distribuidos en varios segmentos de red distintos, interconectados a través de mrouters. Para que
el concepto multicast funcione, no basta con que los routers multicast conozcan, por medio del IGMP
(como se ha explicado antes), qué equipos pertenecen a un determinado grupo multicast en los
segmentos de red que este conecta, sino que deben saber tomar las decisiones necesarias para
encaminar los datagramas multicast entre dichas subredes, asegurando que los enviados por un
determinado equipo lleguen a todos los miembros de cada grupo multicast, y procurar, por otro lado, que
no se produzcan bucles, esto es, que cada datagrama llegue a sus destinatarios sólo una vez (y,
preferiblemente, por el camino más corto). Es decir, debe existir una determinada política de
encaminamiento multicast, o dicho de otra forma, estos routers deben implementar un protocolo de
encaminamiento (routing) multicast. Un protocolo de encaminamiento multicast es el que se encarga de
la construcción de los árboles de distribución (delivery trees) y habilitar la remisión (forwarding) de
datagramas multicast. La característica diferencial entre el encaminamiento unicast y el multicast, es
que los datagramas multicast deben ser remitidos acullá de su origen. Si un datagrama IP multicast es
remitido hacia su origen, se podría producir un bucle de remisión, que podría dar lugar a una `avalancha'
multicast.

Todos los protocolos de encaminamiento multicast hacen uso del protocolo IGMP para conocer la
filiación de los equipos finales a cada determinado grupo multicast, pero difieren en la forma de
intercambiar dicha información entre mrouters vecinos, así como en las técnicas empleadas en la
construcción de los árboles de distribución.

En cuanto a los tipos de protocolos de encaminamiento podemos distinguir, del mismo modo que para el
encaminamiento unicast, dos grandes familias:

• Protocolos de vector distancia:Basados en el algoritmo de "camino más corto" del Bellman-

Ford, en el que cada nodo distribuye todo el mapa de encaminamiento a sus vecinos de forma
periódica, de tal forma que cada nodo se va haciendo una imagen de la red en su conjunto.
Cada nodo asigna un "peso" o métrica a cada ruta en función de los saltos necesarios para
alcanzar a otro nodo. Su principal ventaja es su sencillez de operación y por ende, de
implementación. Mientras que su mayor desventaja es su problema de escalabilidad. A medida
que la red se hace mayor y más compleja, el algoritmo se vuelve menos eficiente y se produce
un mayor consumo de ancho de banda en los enlaces por la diseminación de las tablas de
encaminamiento. Por otro lado también es posible la formación de bucles de encaminamiento
(aunque existen implementaciones de este tipo de protocolo que evitan, en gran medida, este
inconveniente).
• Protocolos de estado del enlace: Se basan en el concepto de un "mapa distribuido", es decir,
que todos los nodos tienen una copia del mapa de la red, que se actualiza periódicamente. Se
han desarrollado a partir de un algoritmo más eficiente que el de Bellman-Ford, propuesto por
E.W. Dijkstra, llamado "el camino más corto primero" (shortest path first). Sin entrar en más
detalles comentaremos que algunas de sus principales ventajas son: la rápida convergencia a
la descripción real del estado de la red, la ausencia de creación de bucles, el soporte de
métricas (costes asociados a un determinado enlace) múltiples, soporte de múltiples rutas a un
mismo destino, etc.. Como contrapartida requieren mayor poder de procesamiento en los
routers y son complejos de implementar y/o configurar.

En cuanto a los algoritmos empleados por los protocolos de encaminamiento multicast, su descripción
es compleja y está fuera del propósito de este artículo el proporcionar una explicación de los mismos.
Se puede hallar esta información en las referencias [2] y [8]de la bibliografía. Tan sólo indicaremos que
se podrían dividir en dos grandes categorías:

• Basados en técnicas simples

 • Inundación (flooding).
• MAC-layer Spanning Trees.
• Basados en técnicas de árboles centrados en la fuente (Source-based trees)
• Reverse Path Broadcasting (RPB).
• Truncated Reverse Path Broadcasting (TRPB).
• Reverse Path Multicasting (RPM).

Hay que resaltar que los protocolos de encaminamiento multicast son, por lo general, bastante más
complejos que sus homólogos en unicast, y por otro lado su desarrollo ha sido más tardío, por lo que
aún presentan mayores deficiencias, sobre todo cuando se aplican a redes complejas y no digamos a
toda la Internet. Sin embargo su evolución ha sido más rápida, debido en gran medida, al gran interés
que ha despertado, en función de sus enormes posibilidades de aplicación, tanto en redes académicas
como entre las grandes y pequeñas empresas relacionadas con el sector de las telecomunicaciones.
También, por qué no, por la presión de usuarios finales y empresas que hacen uso de Internet en
demanda de un medio multicast que permita ampliar sus horizontes de oferta de servicios multimedia de
forma eficaz y económica.

Uno de los primeros protocolos de encaminamiento multicast fue el DVMRP (Distance Vector Multicast
Routing Protocol), desarrollado por Steve Deering en la Universidad de Stanford en 1988, y que se
encuentra definido en el RFC 1075.

El DVMRP es un protocolo del tipo `vector distancia' que usa la técnica `Reverse Path Multicasting' (este
es un refinamiento de la técnica `Reverse Path Forwarding' empleada originalmente en este protocolo),
para construir árboles de encaminamiento multicast basados en la fuente (Source-based multicast
delivery trees). De acuerdo con esta técnica, el primer datagrama recibido para cualquier pareja
{origen,grupo multicast} es remitido a todas las interfaces de red del mrouter, excepto a aquella por la
que ha sido recibido, siempre que sea esta interfaz la usada por el protocolo de encaminamiento unicast
para enviar datagramas a dicho origen, o en caso contrario será descartado el datagrama. Tras recibir
estos datagramas, los mrouters de los extremos del árbol de distribución, o mrouters hojas (leaf nodes),
podrían transmitir mensajes de `podado' (pruning) hacia el origen de los mismos, en el caso de que no
existiesen equipos finales conectados a dicho grupo multicast en la sub-red. Por otro lado, se
implementa el mecanismo de `injerto' (graft) que es remitido por cada mrouter a sus vecinos
ascendentes, en caso de que existan equipos que se hayan unido a un grupo multicast en una rama del
árbol de distribución previamente `podada'. El DVMRP construye su propia tabla de encaminamiento
unicast de una forma similar al RIP (Routing Information Protocol), que es un protocolo unicast, también
del tipo vector distancia. Con esta tabla de encaminamiento guarda la información de la interfaz que
conduce a la fuente de un determinado datagrama multicast.

Para poder extender el ámbito de distribución del multicast a través de encaminadores que no son
capaces de entender este tipo de tráfico, se desarrolló el concepto de túneles. De esta forma se pueden
interconectar entre sí las distintas sub-redes o `islas' multicast a través de medios físicos de transporte
convencional unicast. Cada túnel tiene asociado un umbral (threshold) que permite limitar el ámbito de
distribución de los datagramas multicast en función del campo TTL asociado a los mismos. Cada
datagrama multicast recibido por un mrouter decrementa el valor del TTL del mismo y posteriormente lo
compara con los umbrales definidos en sus túneles. Si el TTL resultante es mayor que dicho umbral, el
datagrama será distribuido a través de dicho túnel y en caso contrario será descartado. Este método de
limitación del ámbito de distribución de los datagramas multicast tiene sus limitaciones. Por ejemplo,
aparecen conflictos cuando se trata de aplicar límites simultáneamente en base a criterios topológicos,
geográficos y de ancho de banda. En particular, este esquema no es válido cuando se trata de aplicar a
regiones que se solapan. Con la intención de resolver estos problemas se desarrolló un método de
limitación del alcance en base a criterios administrativos (Administratively Scoped IP Multicast), ya sea
localmente, a un determinado centro u organización, o a un conjunto de ellas. Para ello ha sido
reservado por la IANA un determinado rango de direcciones multicast (239.0.0.0 a 239.255.255.255).
Estas extensiones aún están en proceso de desarrollo dentro del grupo de trabajo mboned del IETF (en
el momento de escribir este artículo el último borrador databa de noviembre de 1997).

La primera implementación de este protocolo fue desarrollada por el grupo de Van Jacobson del LBL
(Lawrence Berkeley Laboratoy, USA) en 1992, como una aplicación diseñada para funcionar en
máquinas UNIX (mrouted). Esta primera implementación del protocolo DVMRP sólo comprobaba la
filiación de miembros a un determinado grupo multicast en los extremos de la red. Como consecuencia
de ello, los datagramas multicast eran distribuidos por toda la red. En 1993 salió a la luz una nueva
versión del mrouted que implementaba correctamente los mecanismos de podado de ramas (pruning).
De hecho, múltiples variaciones se han desarrollado sobre la implementación del mrouted hasta el
momento, alejándose ligeramente de las especificaciones definidas en el RFC 1075, en gran parte para
solventar ciertas deficiencias que la implementación de la definición original presentaba, y en parte para
adaptarlo a nuevas extensiones al protocolo IGMP.

Esta implementación convierte a la computadora en la que opera, en un router multicast que puede
intercambiar información DVMRP con otros routers multicast similares a través de túneles definidos por
los administradores de los mismos. Estos túneles encapsulan los datagramas IP multicast en otros
datagramas IP unicast que son enviados por los caminos habituales y a través de routers
convencionales desde el mrouter origen al destino. Cuando el mrouter destino recibe un datagrama IP
de estas características, se encarga de eliminar las cabeceras sobrantes, obteniendo el datagrama IP
multicast original, e inyectarlo en la red local o re-enviarlo a través de otros túneles en función de los
algoritmos de distribución implementados en el protocolo DVMRP antes mencionados. Estos túneles
constan de cuatro variables a configurar por el administrador: La dirección de destino del túnel (y la
origen, en el caso de que la estación disponga de varias interfaces de red); la métrica, que asocia un
coste a cada uno de los caminos alternativos que tenga el mrouter definidos (otros túneles, si los hay); el
threshold (umbral), que establece una barrera para limitar el ámbito de distribución de los datagramas
en función del TTL asociado a los mismos; y el rate_limit, o ancho de banda máximo permitido a través
de dicho túnel.

El desarrollo de esta primera implementación del DVMRP fue la que permitió el nacimiento de lo que
hoy es MBone. En marzo de 1992 se produjo la primera transmisión de audio y vídeo en tiempo real a
través del recién creado troncal experimental multicast. Desde las apenas 40 redes conectadas en
1992, MBone ha experimentado un crecimiento sin precedentes hasta las más de 4.300 redes
conectadas, a lo ancho del mundo, en 1997.

La interconexión de estos mrouters de fácil instalación, ha ido incrementándose con el paso del tiempo
dando lugar al entramado de routers multicast que forman el MBone. La ventaja de disponer de túneles
de multicast corriendo sobre estaciones de trabajo, es el no comprometer las comunicaciones de cada
centro, de tal forma que cualquier mal funcionamiento de dichos equipos no suponga un detrimento
grave de las comunicaciones del mismo, sino tan sólo de aquellas referentes al tráfico multicast.

Aparte del DVMRP existen otros protocolos de encaminamiento multicast, que han ido surgiendo con el
tiempo en la búsqueda de una solución de más fácil implementación y que resolviese los problemas de
escalabilidad de que adolece el DVMRP (como cualquier protocolo de vector distancia).

El MOSPF (Multicast Open Shortest Path First), definido en el RFC 1584, es una extensión al protocolo
de encaminamiento unicast OSPF (RFC 1583). Este último es un protocolo del tipo `estado del enlace',
que permite un cálculo rápido de las rutas con un mínimo de intercambio de información entre routers. El
MOSPF es una simple extensión al anterior, que incluye la posibilidad del encaminamiento del tráfico
multicast. La ventaja de este esquema es que el protocolo de encaminamiento multicast se aprovecha
del protocolo unicast, y no tiene que construir sus propias tablas de encaminamiento
independientemente. El MOSPF sólo añade la información de origen y grupo multicast a los mensajes
de estado del enlace, con los que el OSPF crea su mapa de la topología de red. El disponer de una
descripción del estado del enlace con la información de filiación de miembros a los distintos grupos
multicast, permite la construcción de las árboles de envío de camino más corto en la memoria de los
mrouters, esto es, no necesita, como DVMRP, diseminar el primer datagrama recibido hacia todas las
interfaces. Por otro lado, la construcción del diagrama de distribución,se realiza "bajo demanda" cuando
un mrouter recibe el primer datagrama para una determinada pareja {fuente, grupo}. Este esquema
presenta la desventaja de que puede sobrecargar la CPU del router en los casos en los que varias
parejas {fuente,grupo} aparecen al mismo tiempo, o cuando concurran muchas circunstancias que
fuercen la reconstrucción de las cachés de remisión (forwarding caches).

El MOSPF, al igual que su homólogo unicast (el OSPF) es un protocolo diseñado para operar dentro del
ámbito de la intra-red (intranet), y no soporta el uso de túneles.

Otros dos protocolos más han sido definidos por el grupo de trabajo idmrdel IETF: el PIM-DM (Protocol
Independent Multicast-Dense Mode) y el PIM-SM (Protocol Independent Multicast-Sparse Mode). Ambos
comparten parte del nombre y emplean mensajes de control similares, pero son dos protocolos
diferentes. PIM recibe su nombre de la independencia que presenta de los mecanismos de
encaminamiento unicast subyacentes. Sencillamente asume que estos mecanismos existen y delega en
ellos la tarea de determinar el camino hacia la fuente de los datagramas multicast, a la hora de construir
el árbol de distribución para cada pareja {fuente, grupo}.

PIM-DM usa, del mismo modo que el DVMRP, el algoritmo de `Reverse Path Multicasting', pero a
diferencia de este último, el protocolo PIM-DM remite los datagramas recibidos para cada pareja
{fuente,grupo} a todas las interfaces de red, excepto a aquella por la que se ha recibido el datagrama
multicast, y sólo son eliminados aquellos caminos por los se han recibido explícitamente mensajes de
`podado' (pruning) porque no existan miembros de ese grupo. Este modelo de funcionamiento presenta
una mayor eficiencia en el caso de que los miembros de los grupos multicast estén próximos entre sí y
el ancho de banda no sea un recurso escaso.

La razón principal del desarrollo del PIM-SM, ha sido el intentar paliar las deficiencias presentadas por el
DVMRP y MOSPF en los casos en que los enlaces entre mrouters están dispersos a lo largo de amplias
zonas y que los miembros de cada grupo multicast no están concentrados en las proximidades de los
mrouters, situación que se presenta en las topologías de red extensa (WAN).

Todos los protocolos mencionados hasta el momento (a excepción del PIM-SM), se comportan más o
menos eficientemente en condiciones de una distribución poblada de receptores dentro de la intranet.
Sin embargo, fallan cuando se aplican a entornos de red extensa o de población esparcida, en las que el
número de receptores puede considerarse, en términos generales, escaso. Para cubrir estos supuestos,
están en desarrollo dos nuevos protocolos de encaminamiento multicast: el PIM-SM (PIM Sparse mode)
y los de árbol basado en el núcleo o `Core-based trees' (CBT).

El protocolo PIM-SM (documentado en el RFC 2117), puede usar simultáneamente las técnicas de árbol
basado en la fuente (source-based tree) o de árbol compartido (shared tree). Por defecto se utilizan
diagramas de árbol compartido centrados en un mrouter principal o `Rendezvous Point', pero con
independencia de la técnica en uso, no se produce la remisión, por defecto, de datagramas multicast.
Para que esto ocurra es necesario que estos RP reciban un mensaje de sus mrouters vecinos con una
petición explícita de filiación a un determinado grupo.

En la actualidad la mayor parte de estos protocolos cohabitan en el MBone y la tónica general es la

implantación de PIM-DM, DVMRP o MOSPF en entornos corporativos, y la conexión de estas `islas'
multicast a través de túneles DVMRP. Sin embargo, es preciso resaltar que la interrelacción de estos
protocolos de encaminamiento multicast está aún en período de estudio y experimentación. Existe un
trabajo en progreso dentro del grupo de trabajo idmrdel IETF, que pretende definir los requisitos que se
deben cumplir en la interacción de distintos protocolos de encaminamiento multicast.

4.- ¿Qué ventajas ofrece el IP multicast?

La ventaja del IP multicast frente a otros tipos de comunicaciones, es la transmisión de información en
tiempo real para múltiples receptores. En estos casos la utilización del multicast permite un ahorro
substancial de los recursos de red consumidos, y por ende una mejora en la transmisión de esta
información y -¿porqué no?- una mejor relación calidad/costes. La ventaja de aprovechar el multicast
para la transmisión de datos multimedia frente a las comunicaciones uno-a-uno, es el ahorro de
recursos telemáticos y por tanto la eficiencia de las aplicaciones a iguales gastos en infraestructura.
Pongamos un ejemplo sencillo: En una conferencia basada en comunicaciones uno-a-uno, la eficiencia
de la misma es inversamente proporcional al número de receptores en un extremo dado de la red. Cada
nuevo receptor en un mismo extremo de la red obliga a que los paquetes de información enviados por el
emisor se dupliquen. En el caso de las comunicaciones uno-a-muchos (IP multicast o MBone) la
eficiencia no se ve afectada por este factor. A cada extremo de la red en la que existen receptores de la
misma, sólo llegan una vez los paquetes que contienen la información, independientemente del número
de receptores. Los protocolos de encaminamiento subyacentes en MBone se encargan de asegurar que
la información que viaja entre el emisor y los receptores no pase más de una vez por el camino entre
ambos, y que sólo sea enviada en el caso de que existan receptores de la misma.

5.- ¿Cuáles son sus inconvenientes y cómo resolverlos?

MBone, como red experimental, existe desde 1992 y ha evolucionado hacia algo más que un simple
experimento. De hecho es un experimento de dimensiones impresionantes que interconecta a decenas
de miles de usuarios de todo el mundo. En todos los sentidos esto puede ser considerado como un
enorme éxito. Por un lado hemos visto como existe una fuerte demanda por los tipos de aplicaciones
que permiten las transmisiones multicast. Por otro lado es difícil la investigación cuando no se cuenta
con usuarios e infraestructuras reales, pero si los experimentos resultan satisfactorios, los propios
usuarios demandan su utilización como un servicio operativo.

Existen un cierto número de inconvenientes que impiden hacer de MBone un servicio operativo en la
actualidad. Algunos de ellos constituyen un defecto intrínseco de la propia filosofía de diseño de MBone
como un experimento en nuevos protocolos de comunicaciones. Otros, por el contrario, son resultado
del estado primitivo aún de estos protocolos, o de la falta de algunas piezas en este complejo
rompecabezas.

La implementación real del MBone como un servicio operativo global, requerirá un cambio topológico
esencial en el que, las cada vez más numerosas islas multicast interconectadas entre sí, dejen paso a
un medio completamente multicast integrado dentro del encaminamiento IP. Esto no implica que se
deba producir de una forma radical, sino más bien tendrá lugar de una forma progresiva. Para que esto
pueda tener lugar, se requieren muchos esfuerzos encaminados a acabar de perfilar los protocolos
existentes hasta adaptarlos a un modelo que ofrezca las cualidades de escalabilidad que una red tan
compleja como la Internet requiere, o descubrir otras vías alternativas que ofrezcan una solución global
a la integración del encaminamiento unicast y multicast. Mientras tanto, MBone ofrece numerosas
ventajas dentro de cada una de estas `islas' multicast que lo forman.

En cuanto a los protocolos de encaminamiento y algoritmos de creación de árboles de distribución,

existen ciertas deficiencias que deben ser corregidas antes de que se puedan considerar aptos para su
implementación masiva. Cualquier protocolo escalable debe tender a minimizar los requisitos del estado
de remisión (forwarding state). En el caso de protocolos orientados a distribuciones pobladas de
fuentes/receptores (DVMRP, PIM-DM), los mrouters deben guardar la información de estado de
remisión o `podado' para cada pareja {fuente,grupo} en la Internet. Es obvio que si el multicast se escala
al tamaño de la Internet, el mantenimiento de tal información se hace insostenible.

Los protocolos de árbol compartido (PIM-SM, CBT) carecen de este problema, pero sin embargo,
pueden dar lugar a la remisión de datagramas por parte de Rendezvous Points o Cores situados en las
fronteras de áreas que se solapan y que están dentro del árbol compartido para las mismas, aún cuando
no haya receptores en su propia subred. También pueden presentar problemas de congestión de red
debido a las concentraciones de tráfico en los árboles compartidos, lo que da lugar a un incremento de
la latencia o pérdida de paquetes.
En cuanto al nivel de transporte, en el primer apartado de este artículo, habíamos indicado que una de
las grandes desventajas del uso del protocolo UDP para el transporte de contenidos multimedia en
tiempo real, es la imposibilidad de garantizar la llegada ordenada de los paquetes de información a sus
destinos. Este problema, inherente a la propia tecnología empleada, ha sido resuelto con la definición de
un nuevo protocolo orientado a este tipo de transmisiones. Este es el protocolo de transporte en tiempo
real o RTP (Real Time Protocol). La implementación de este protocolo está documentada en el RFC
1889, publicado por el IETF en enero de 1996.

El RTP fue pensado para satisfacer las necesidades de multi-conferencias multimedia, sin embargo su
uso no esta limitado a estas aplicaciones. Puede emplearse del mismo modo en el almacenamiento
continuo de datos, la simulación distribuida, control y medida en tiempo real, etc. El RTP permite la
distribución de información a múltiples receptores usando multicast si este modo de distribución es
soportado por la infraestructura de red subyacente. Sin embargo, el protocolo RTP, no garantiza la
entrega a tiempo de la información, sino que confía en el medio subyacente para este propósito. Por
otro lado incluye su propia secuenciación de fragmentos que permite reconstruir ordenadamente la
información en su destino, con independencia de que exista un medio fiable o no de transmisión.

El problema que se presenta entonces es el de poder garantizar una calidad de servicio aceptable en las
transmisiones multimedia. Esta quizás sería una de las últimas piezas que harían funcionar el engranaje
de MBone como un servicio operativo, en cuanto a nivel de transporte se refiere, es decir, sin tener en
cuenta la problemática del encaminamiento multicast descrita anteriormente. Para poder garantizar la
calidad del servicio es necesario disponer de un mecanismo que nos permita reservar los recursos
necesarios, tanto a nivel del equipo transmisor (tiempo de CPU, ancho de banda de acceso a disco,
etc.), como en el camino entre éste y el(los) receptores (ancho de banda mantenido en la ruta entre
ellos). Gran parte de estas características se han definido dentro de un protocolo llamado `Resource
ReSerVation Protocol' (RSVP), documentado en sus múltiples aspectos en los RFCs 2205 a 2216.

El RSVP lo usan los equipos finales para solicitar una determinada calidad de servicio de la red, para un
flujo de datos de una aplicación específica. También lo emplean los routers para distribuir estas
peticiones de calidad de servicio a todos los nodos intermedios en el camino de dicho flujo y para
establecer y mantener el estado que permita prever el servicio solicitado. Este protocolo no se encarga
de transmitir la información, sino que es un protocolo de control como el ICMP, IGMP o los de
encaminamiento.

6.- ¿Cómo sacar provecho al MBone ?

Se han desarrollado gran cantidad de herramientas para experimentar diferentes intercambios
multimedia a través de MBone ya sea en modo interactivo: editores de texto y pizarras electrónicas
compartidas, intercambio de hipertextos; o de procesos no interactivos: sincronización de equipos (NTP
multicast) o distribución de archivos a múltiples receptores simultáneamente (FTP multicast) por poner
algunos ejemplos. Algunas de estas aplicaciones experimentales, como son las de transmisión de audio
y vídeo, se han convertido prácticamente en estándares de facto y son ampliamente utilizadas por un
elevado número de usuarios con cierta regularidad.

Las misiones del transbordador de la agencia espacial americana (NASA), las reuniones periódicas de
los grupos de trabajo del IETF, así como emisiones de radio por multicast, son algunas de las sesiones
disponibles con regularidad en MBone y seguidas por un gran número de usuarios en todo el mundo.

Gran parte de las aplicaciones aquí enumeradas están disponibles para casi cualquier plataforma
informática: desde un simple PC con Windows95, hasta una estación de trabajo con UNIX (en casi
cualquiera de sus variantes), lo cual ha contribuido a la popularidad de las mismas. De este modo
cualquier PC multimedia básico, es decir, que disponga de una tarjeta de audio y un micrófono, nos
permitirá convertirnos en un nodo receptor de MBone y ser capaces de bien asistir a cualquiera de las
videoconferencias que se emiten, o intervenir en aquellas en las que se permita la participación remota.
Con una pequeña inversión, que consistirá en adquirir una cámara digital de bajo coste, podremos
convertirnos en una estación de emisión y recepción de videoconferencias. No es necesario decir que
ésto ofrece unas ventajas substanciales en el desempeño de nuestras actividades profesionales y/o
académicas. Siguiendo esta línea se están produciendo estudios a varios niveles, como es en el campo
de la educación y la medicina, sobre la viabilidad y el impacto social y/o laboral de estas nuevas
tecnologías.

Dentro del amplio abanico de aplicaciones que han aparecido en estos últimos años (gran parte de ellas
continúan en desarrollo), las más populares en MBone han sido las que permiten la realización de
conferencias de audio y vídeo. Dentro de este grupo el rat y el vat son las más empleadas para la
transmisión/recepción de audio, y el vic para la transmisión/recepción de vídeo. En el apéndice
describiremos brevemente estas y otras herramientas existentes, e indicaremos los localizadores en
Internet (URLs) para conseguirlas.

Una utilidad fundamental en MBone, que permite la integración de todas las anteriores, es el SDR
(Session Directory Tool), o directorio de sesiones MBone que nos permite conocer las sesiones que
están activas en todo momento, conectarnos a cualquiera de ellas, o definir nuestra propia sesión
MBone.

La primera implementación del SDR, llamado SD, fue desarrollada por Van Jacobson en el LBNL
(Lawrence Berkeley National Laboratory). El desarrollo posterior de la misma ha sido llevado a cabo
dentro del proyecto europeo de investigación en herramientas multimedia MERCI (antes MICE), dando
lugar al actual SDR. Ciertos cambios en fundamentales en su estructura han hecho que ambas
versiones sean incompatibles y en la actualidad los anuncios de sesiones, se hacen de forma
generalizada con la nueva versión desarrollada por el MERCI, el SDR.

El SDRemplea una dirección multicast asignada por la IANA, la 224.2.127.254 y un puerto UDP
específico (el 9875) para retransmitir los anuncios de sesiones multimedia. Esto se implementa por
medio de un protocolo muy simple, en el que los datos de la sesión van incluidos en forma de texto
ASCII tras una breve cabecera UDP.

Esta simple implementación, permite que estos datos puedan ser capturados fácilmente por una
aplicación y puedan emplearse para lanzar las aplicaciones necesarias para unirse a una determinada
conferencia.

Otras aplicaciones de gran utilidad, y empleadas principalmente como complemento a las anteriores, en
la realización de videoconferencias, son la pizarra electrónica (wb) y el editor de textos compartido. Con
la primera de ellas nos encontramos ante una aplicación que nos proporciona el acceso a una pizarra en
la que disponemos de una serie de utilidades tanto para escribir textos con varios tamaños y formas,
como para realizar dibujos a mano alzada y formas geométricas sencillas. Cualquier diseño que
creemos en esta pizarra virtual, será automáticamente visto por todos los participantes en la sesión, y
cualquiera podrá hacer modificaciones sobre dichas imágenes. También tenemos la posibilidad de
incorporar archivos en formato PostScript a dicha pizarra.

Por otro lado, el editor de texto compartido (Network Text editor) o nt, permite a múltiples usuarios
trabajar en tiempo real sobre un mismo documento de texto: crear nuevos párrafos, borrar, cambiar y
mover los existentes, etc.

El ivs (INRIA Videoconference System), desarrollado por el INRIA (Institut National de Recherche en
Informatique et en Automatique), permite la integración de los canales de audio y vídeo sobre una
misma aplicación. Esta aplicación fue desarrollada en 1992 y actualmente ha dejado de ser mantenida
para dar paso a otras nuevas aplicaciones como el Rendez Vous (nueva generación del ivs) y
FreePhone .

Todas las aplicaciones que hemos descrito aquí son fruto del trabajo desarrollado por varios grupos de
investigación y han sido puestas a disposición de todos los pobladores de Internet como software de
dominio público. Muchas de ellas están aún en fase de desarrollo, pero aún así permiten obtener unos
resultados cuando menos sorprendentes.
Mensajes de Error

Losmensajes de errorde ICMPv6 son similares a losmensajes de errorde ICMPv4. Se

dividen en 4 categorías:destino inaccesible, paquetedemasiado grande, tiempo excedido y
problemasde parámetros.

1 Destination Unreachable (Destino Inalcanzable) 2 Packet Too Big

(PaqueteDemasiado Grande) 3 Time Exceeded (Tiempo Agotado) 4 Parameter
Problem (Problemade Parámetros)

Contenido

• 1 Arquitectura

• 2 Estándares

• 3 Puestas en práctica del anfitrión y de la rebajadora

• 4 Vea también

• 5 Referencias

• 6 Acoplamientos externos

Arquitectura

Una red diseñó entregar un servicio del multicast (como el vídeo) que usabaIGMP pudo utilizar esta

arquitectura básica:

IGMP es utilizado por la computadora del cliente y el adyacente interruptores de la red para conectar a

cliente con una rebajadora local del multicast. Multicast de la independiente delprotocolo (PIM)

entonces se utiliza entre las rebajadoras locales y alejadas del multicast, dirigir tráfico del multicast

del servidor video a muchos clientes del multicast.

Estándares

Hay tres versiones deIGMP, según lo definido por “Request For Comments“Documentos (RFC) del

Internet Engineering Task Force(IETF).IGMP v1 se define cerca RFC 1112,IGMP v2 se define cerca RFC

2236eIGMP v3 se define cerca RFC 3376.

 Puestas en práctica del anfitrión y de la rebajadora

Elprotocolo deIGMP se pone en ejecución como un lado del anfitrión y lado de la rebajadora. Un lado

del anfitrión divulga su calidad de miembro de un grupo a su rebajadora local, y un lado de la

rebajadora escucha los informes de los anfitriones y envió periódicamente preguntas.

Linux sistema operativoayudasIGMP. Núcleo de Linuxen la base del sistema operativo pone

solamenteIGMP en ejecución como lado del anfitrión, no lado de la rebajadora, al menos a demoniopor

ejemplo mrouted puede ser utilizado actuar como rebajadora deIGMP Linux. Hay también habitaciones

enteras de la encaminamiento (por ejemplo XORP), que dan vuelta a una computadora ordinaria en

una rebajadora hecha y derecha del multicast.

Vea también

• IGMP snooping

Referencias

1. ^ Brujería de la red -IGMP

2. ^ Spoofed Negación del informe deIGMP del servicio vulnerabilidad.

3. ^ Paquete hecho fragmentos deIGMP puede promover la “negación ataque del servicio”.

4. ^ Declaración y requisitos del problema de la seguridad deIGMP.

5. ^ Boletín MS06-007 de la seguridad de Microsoft: La vulnerabilidad en el TCP/IP podría permitir la

negación del servicio (913446).

Acoplamientos externos

• Brujería de la red -IGMP

• Herramientas y ajustes del Multicasting IPv4 en Microsoft TechNet

• Diversos versión y detalles enIGMP

• Multidifusión IP en Internet: Protocolo IGMP de gestión de grupos
de Internet
• IPIGMPInterfaz de RedHardwareACCESO A
• REDINTERNETMódulo IGMPMódulo IP
• Figura 1.- Ubicación del protocolo IGMP en la arquitectura TCP/IP.
• En el escenario de las transmisiones IP de multidifusión, los sistemas finales de
usuario comunican sus pertenencias a grupos de multidifusión en Internet al router
de multidifusión local1 de la propia organización mediante el protocolo IGMP
(Internet Group Management Protocol) de Gestión de Grupos de Internet (RFC-
2236). Mediante dicho protocolo IGMP, el propio router de multidifusión local de
 la organización puede encontrar máquinas vecinas con miembros activos de
cualquier grupo de multidifusión que haya en Internet en el escenario de la propia
red de área local de la organización en cuestión.
• Desde el punto de vista de su ubicación en la arquitectura de comunicaciones
TCP/IP, y según se muestra en la anterior Figura 1, el protocolo IGMP ocupa al
igual que el protocolo ICMP, un mismo subnivel de comunicaciones por encima de
IP en el nivel de red o Internet. Además, y al igual que el protocolo ICMP, el
protocolo IGMP está tan íntimamente ligado al protocolo IP2, que de hecho se
puede ver como una parte integral3 de IP, es decir, un módulo más dentro del propio
módulo o proceso IP.
• 1 Que está conectado a la misma red de área local (Ethernet o IEEE 802).
• 2 Seejecuta directamente sobre IP. En el campo PROTOCOLO de la cabecera IP, aparece el valor 2
en decimal (por ejemplo, para ICMP el valor en decimal es 1).
• 3 No como un protocolo separado.

• -1-
• CabeceraIGMPDatosCabeceraIPCabeceraIPCabeceratrama MENSAJE IGMP DE DIFUSIÓNDATAGRAMA IPDatosDatosTRAMA
MAC Ethernet
• Figura 2.- Encapsulación de un mensaje IGMP.
• Según se describe en la anterior Figura 2, el protocolo IGMP encapsula un mensaje
IGMP en un datagrama IP. De ahí que IGMP ocupe un subnivel superior al
ocupado por el protocolo IP en el mismo nivel de Internet o red de la arquitectura
TCP/IP. Se resalta que las direcciones de multidifusión (clase D) sólo pueden
emplearse como direcciones IP de destino. Éstas nunca aparecen en el campo de
dirección del origen de un datagrama. Asimismo, no se generan mensajes de error
ICMP relacionados con datagramas de multidifusión. Cuando se encapsula un
mensaje IGMP en un datagrama IP para su transmisión, la dirección de destino en
la cabecera IP es la dirección de multidifusión del grupo, por ejemplo, 224.0.0.14,
224. 0.1.75, etc. MAC Ethernetde
unidifusiónTCP/UDPAplicaciónAplicaciónmultidifusiónmultidifusiónGrupo 1Grupo
1AplicaciónAplicaciónmultidifusiónmultidifusiónGrupo 2Grupo 2Direcciones IP de unidifusiónde redes y máquinas conocidas
(incluida M1)Hardware EthernetMAC Ethernetde difusión……
Aplicaciónunidifusión1Aplicaciónunidifusiónn……Máquina M1Direcciones IP de difusión conocidas (limitada y dirigida(s)
MAC EthernetEthernetde de multidifusiónmultidifusiónDirecciones Direcciones IP de multidifusiónmultidifusiónconocidas
conocidas (incluidas las de Grupo 1 y Grupo 2)
• Figura 3.- Un ejemplo de correspondencias de direcciones IP y MAC.
• Los datagramas IP que transportan mensajes IGMP o mensajes especifícos de una
aplicación de multidifusión se transmiten finalmente por la red de acceso a través de
• 4 Asignada permanentemente a todas las máquinas en esta red de área local.
• 5 Asignada permanentemente para noticias de audio (audionews).
• -2-
• tramas MAC Ethernet6 mediante el correspondiente software de multidifusión del
interfaz de la red de acceso. Dicho software transforma o adapta una dirección IP
de multidifusión en la correspondiente dirección MAC de multidifusión (ver niveles
implicados en la anterior Figura 3). Consecuentemente, aquellas máquinas que no
soporten el software de multidifusión IP en el nivel del interfaz de la red de acceso
de la arquitectura TCP/IP, nunca transmitirán ni recibirán mensajes de
multidifusión.
• En este contexto, es importante resaltar que toda máquina TCP/IP conectada, por
ejemplo, a la clásica red de acceso de área local del tipo Ethernet; tiene que tener
 potencialmente la capacidad de transmitir y recibir tanto tramas de unidifusión
como de difusión (limitada y dirigida) y, obviamente, de multidifusión. Para ello, es
imprescindible que los datagramas IP que transportan, por ejemplo, mensajes de
unidifusión se transmitan, finalmente, por la red de acceso a través de tramas MAC
Ethernet de unidifusión mediante el correspondiente software de unidifusión del
interfaz de la red de acceso. Dicho software transforma una dirección IP de
unidifusión en la correspondiente dirección MAC de unidifusión. En la siguiente
Figura 4 se muestra el envío de una trama de unidifusión (encapsulando al
pertinente datagrama IP de unidifusión 128.1.1.2), a la máquina cuya dirección IP es
128.1.1.2 y cuya dirección MAC Ethernet de destino comienza con los tres
primeros octetos (en hexadecimal) 08-00-4E7.
• 6 Suponiendo que la red de acceso es una red de área local del tipo Ethernet. Por consiguiente, una
red de área local del tipo Ethernet (IEEE 802.3) soporta multidifusión en el protocolo del interfaz de
acceso a dicha red.
• 7 Propios, en este ejemplo, del fabricante 3COM EUROPE LTD de tarjetas de red Ethernet, según la
normalización realizada por IEEE al respecto para distinguir a un fabricante de otro. Se resalta que el
bit menos significativo del primer octeto si es un 0 denota una dirección Ethernet y si es un 1 una
dirección de multidifusión. A continuación de esos tres primeros octetos seguirían los restantes tres
octetos asignados por 3COM a la tarjeta en cuestión y que identifica a ésta de cualquier otra tarjeta
de dicho fabricante y, obviamente, de otros fabricantes.
• -3-
• 128.1.1.0/255.255.255.0Origen1Dirección destino MAC=08004E08004E…Trama Ethernet……
……DatagramaIPDirección Ethernet………
Dirección destino IP=128128.1.1.2.1.1.2
128128.1.1.2.1.1.2 ………DatagramaIP128.1.1.2
• Figura 4.- Ejemplo de unidifusión mediante tramas.
• A su vez, los datagramas IP que transportan mensajes de difusión han de
transmitirse, finalmente, por la red de acceso a través de tramas MAC Ethernet de
difusión mediante el correspondiente software de difusión del interfaz de la red de
acceso. Dicho software transforma, en este caso, una dirección IP de difusión en la
correspondiente dirección MAC de difusión. En la siguiente Figura 5 se muestra el
envío de una trama de difusión limitada (encapsulando al pertinente datagrama IP
de difusión limitada 255.255.255.255), a todas las máquinas de la red 128.1.1.0
cuyas direcciones MAC Ethernet de destino constan siempre de los mismos 6
octetos o 48 bits todos a unos en binario (FFFFFFFFFFFF en hexadecimal).
128.1.1.0/255.255.255.0Origen1Dirección destino MAC=FFFFFFFFFFFFFFFFFFFFFFFFTrama
Ethernet……Dirección destino IP=255255.255.255.255.255.255.255……DatagramaIPDirección
Ethernet………255255.255.255.255.255.255.255………DatagramaIP
• Figura 5.- Ejemplo de difusión limitada mediante tramas
• En la siguiente Figura 6 se muestra el envío de una trama de difusión dirigida
(encapsulando al pertinente datagrama IP de difusión dirigida 128.1.255.255), a
todas las máquinas de las redes 128.1.1.0 y 128.1.2.0 cuyas direcciones MAC
Ethernet de destino constan siempre de los mismos 6 octetos o 48 bits todos a unos
en binario (FFFFFFFFFFFF en hexadecimal).
• -4-
• 128.1.1.0255.255.255.0128.1.2.0255.255.255.0OrigenRouter1Router3Router2Dirección destino
Ethernet……Dirección destino IP=128128.1.255.255.1.255.255……
MAC=FFFFFFFFFFFFFFFFFFFFFFFFTrama
DatagramaIPDirección Ethernet………128128.1.255.255.1.255.255………DatagramaIP
• Figura 6.- Ejemplo de difusión dirigida mediante tramas-
• Para terminar, los datagramas IP que transportan mensajes de multidifusión deben
enviarse, finalmente, por la red de acceso a través de tramas MAC Ethernet de
multidifusión mediante el correspondiente software de multidifusión del interfaz de
la red de acceso. Dicho software transforma, en este último caso, una dirección IP
de multidifusión en la correspondiente dirección MAC de multidifusión. En la
siguiente Figura 7 se muestra el envío de una trama de multidifusión (encapsulando
al pertinente datagrama IP de multidifusión para el grupo 224.0.1.7), a todas las
máquinas de las redes 128.1.1.0 y 128.1.2.0 cuyas direcciones MAC Ethernet de
destino comienzan siempre con los tres primeros octetos (en hexadecimal) 01-00-
5E. 128.1.1.0255.255.255.0128.1.2.0255.255.255.0OrigenRouter1Router3Router2Dirección destino
Ethernet……Dirección destino IP=224224.0.1.7.0.1.7……DatagramaIPDirección
MAC=01005E01005E…Trama
Ethernet………224224.0.1.7.0.1.7………DatagramaIP
• Figura 7.-Ejemplo de multidifusión mediante tramas
• En la siguiente Figura 8 se muestra, más en concreto, la transformación, traslación
o correspondencia (mapping) de una dirección IPv4 clase D de multidifusión en una
dirección de trama de multidifusión MAC Ethernet o IEEE 8028. La citada
transformación o adaptación se ajusta al siguiente procedimiento:
• 8 Una dirección MAC Ethernet o IEEE 802 consta de 48 bits.
• -5-
• � Se incluyen los 23 bits de menor orden o menos significativos de la dirección IP
de multidifusión9 en los 23 bits de menor orden de la dirección MAC Ethernet de
multidifusión. En este contexto, los diseñadores utilizaron 23 de los 28 bits para una
dirección MAC porque en este conjunto de bits se incluyen la mayor parte de las
direcciones de multidifusión. Por consiguiente, el conjunto de direcciones IP
definidos en esos 23 bits es lo suficientemente extenso10 como para que la
posibilidad de coincidencia11 en el nivel IP sea muy pequeña. Por otro lado, dicha
coincidencia será resuelta en el nivel de red ya que IP sabe qué direcciones de
multidifusión están activas en su máquina. La consecuencia de este diseño es que
algunos datagramas IP de multidifusión pueden recibirse en una máquina, aunque
dichos datagramas no estén destinados a tal máquina. Será la entidad IP quien
verifique cuidadosamente las direcciones en todos los datagramas IP de
multidifusión entrantes y elimine cualquier datagrama IP de multidifusión no
esperado perteneciente a un grupo inexistente en la propia máquina.
00000001000000000 010111101110xxxxxxxxxxxxxxxxxxxxxxxxxxxx23 bits de menor orden de la dirección
IP de multidifusióncopiados en la dirección Ethernet5 bits de la dirección IP de multidifusiónno usados en la dirección

Ethernet 01005EHEXADECIMAL48 bits de una dirección Etherneto IEEE

802Dirección IPv4Clase D00000001000000000 D
• Figura 8.- Transformación IPv4 Clase D en MAC Ethernet o IEEE 802.
• Todas las direcciones Ethernet o IEEE 802 de multidifusión disponen de los mismos
25 primeros bits, 00000001 00000000 01011110 0. Más en concreto, 0x01-00-5E
• 9 Se recuerda que una dirección IP de multidifusión (clase D) comienza por 1110 y, a continuación,
aparecen los 28 bits restantes de identificación del grupo.
• 10 Quedan 5 bits sin usar (exceptuando los 4 bits, 1110, del prefijo clase D); quiere decir esto, que
potencialmente puede haber como máximo 25 ó 32 grupos o combinaciones idénticas; es decir, que al
menos 2 de esos 32 grupos seleccionen una misma combinación de los 223 bits restantes.
• 11 Que dos o más grupos seleccionen seleccionen direcciones MAC idénticas.

• -6-
• (00000001 00000000 01011110) es la notación en hexadecimal de los tres primeros
octetos que se correponden con el identificador12 único del fabricante de la tarjeta.
El bit a continuación, que siempre está a cero, pertenece en direcciones de
unidifusión al siguiente bloque de 24 bits que identifican a la tarjeta del fabricante
en cuestión. Por consiguiente, el rango completo de direcciones MAC Ethernet o
IEEE 802 de multidifusión es de 01:00:5e:00:00:00 a 01:00:5e:7f:ff:ff. Se resalta
que la correspondencia entre las direcciones IP clase D de multidifusión y las
dirección de trama de multidifusión MAC Ethernet o IEEE 802 no es biunívoca, ya
que existen 32 direcciones IP de multidifusión diferentes por cada dirección MAC
de multidifusión. Así, por ejemplo, las direcciones IP de multidifusión 224.0.0.1 y
224.128.0.1 tienen iguales los 23 últimos bits y se corresponden ambas con la
dirección MAC de multidifusión 01.00.5E.00.00.8013. Por consiguiente, puede
suceder que, por ejemplo, en una misma red Ethernet, al menos dos grupos de
multidifusión diferentes utilicen la misma dirección MAC Ethernet de multidifusión;
en este caso, algunas máquinas capturarán tramas MAC de multidifusión que luego
al examinar la cabecera IP, descubrirán que no iban dirigidas a ellas.
Evidentemente, hay una pequeña pérdida de eficiencia por el tiempo que el nivel de
red emplea en analizar una información de control que no iba dirigida al nivel IP de
dicha máquina; pero la probabilidad de que esto ocurra en la práctica es tan pequeña
que la pérdida de eficiencia es despreciable14.
• Obviamente, se recuerda que para poder participar en una multidifusión IP, una
máquina debe poseer el software que le permita enviar y recibir datagramas IP de
multidifusión. El software de IP debe permitir a una aplicación especificar una
dirección de multidifusión como una dirección IP de destino. Asimismo, como ya se
ha indicado, el software del interfaz de la red de acceso debe ser capaz de
transformar una dirección IP de multidifusión en la correspondiente dirección MAC
de multidifusión15.
• En el escenario de IPv6; actualmente, para transformar una dirección IPv6 de
multidifusión en una dirección MAC Ethernet o IEEE 802, se cogen los 32 bits de
menor orden de dicha dirección IPv6.
• 12 OUI (Organizationally Unique Identifier).
• 13 Se resalta que las direcciones MAC en Ethernet se representan empezando por el bit menos
significativo de cada octeto.
• 14 Suponiendo un reparto aleatorio, la probabilidad de coincidencia entre dos grupos de multidifusión
será de 25/228 = 0,0000001.
• 15 O utilizar la difusión si el software del interfaz de la red de acceso no soporta multidifusión.

• -7-
• Bits11111111000 TAlcance44Identificador de grupo808T (transitorio o transient) = 0: Dirección no
transitoriao asignada permanentemente por IANA/ICANNT (transitorio o transient) = 1:Dirección transitoriao no
asignada permanentementeAlcance o límite del grupo de multidifusión: Número entero de 4 bits.0: reservado; 1: Nodo
local o en la propia máquina; 2: enlace local; …; 5: sitio local;…; 8: organización local (compuestas de varios sitios); …
000………………..032Todo a ceros
• Figura 9.- Formato actual de la dirección IPv6 de multidifusión.
• Pero de esos 32 bits, sólo se puede incluir los 23 bits16 anteriormente citados en la
dirección MAC Ethernet de multidifusión. Como ya se ha indicado, será la entidad
IP quien verifique cuidadosamente las direcciones de grupo de todos los datagramas
IP de multidifusión entrantes y elimine cualquier datagrama perteneciente a grupos
de multidifusión inexistentes en la correspondiente máquina.
• Antes de seguir avanzando, es importante diferenciar entre el protocolo de
distribución y actualización de la información de pertenencias a grupos de
multidifusión17 empleado entre routers de multidifusión locales e intermedios18 en
Internet y el protocolo IGMP utilizado, como ya se ha indicado, en la red de área
local (Ethernet o IEEE 802) de una organización entre el router de multidifusión
local y los sistemas finales vecinos.
• Concretamente, los mecanismos de IGMP permiten llevar a cabo dos acciones
fundamentales:
• 1. Que las máquinas destinatarias o sistemas finales de una red de área local
(Ethernet o IEEE 802) informen a su router de multidifusión local de que desean
unirse a un grupo específico de multidifusión; es decir, desean recibir datagramas IP
de multidifusión dirigidas a dicho grupo.
• 16 Por consiguiente, al igual que con IPv4, quedan 5 bits sin usar; quiere decir esto, que
potencialmente puede haber 25 ó 32 grupos potenciales que selecciones idénticas direcciones MAC.
• 17 Como ya se estudiará más adelante, también, denominado protocolo de encaminamiento dinámico
de multidifusión, el cual se utiliza en Internet por los propios routers de multidifusión. Se resalta que
IGMP es un estándar en Internet, no ocurre lo mismo con los protocolos de encaminamiento
dinámico de multidifusión existentes y que ya se analizarán.
• 18 O directamente con routers de multidifusión locales de otras organizaciones si entre medias no hay
routers de multidifusión intermedios.
• -8-
• 2. Que el router de multidifusión local19 interrogue o sondee periódicamente a los
sistemas finales de su red de área local (Ethernet o IEEE 802) para saber si los
miembros, de un grupo conocido, continúan aún activos.
• En este contexto, el protocolo IGMP consta de dos fases:
• • Fase I.- Cuando una máquina o sistema final se une a un nuevo grupo de
multidifusión, envía un mensaje o informe IGMP (tipo 2) de pertenencia a grupo
(Host Membership Report) con la dirección de destino IP conteniendo la dirección
de multidifusión del grupo al que pertenece la máquina de origen. Este mensaje
IGMP también lo escucha el router de multidifusión local, que está conectado a la
misma red, para realizar el correspondiente registro de pertenencia. Asimismo, el
datagrama IP que encapsula dicho informe lleva un TTL = 1 para indicar
expresamente que este tipo de mensaje IGMP se transmite directamente a la red de
acceso y no debe ser reenviado por ningún otro router de multidifusión. A su vez, el
router de multidifusión local se pone en contacto con otros routers de multidifusión
vecinos por Internet, pasando20 la correspondiente información y registrando, en sus
tablas, las oportunas rutas en función de dichas pertenencias para la posterior fase
de transferencia de datos. Un sistema final sólo tiene que emitir un informe IGMP
de pertenencia por cada grupo al que pertenezca. Cuando una máquina final o
destinataria se une a un determinado grupo de multidifusión, envía inmediatamente
un informe de pertenencia sin esperar al siguiente sondeo.
• • Fase II.- Debido a que la pertenencia es dinámica, el router de multidifusión local
sondea de forma periódica, mediante un mensaje IGMP (tipo 1) de solicitud de
pertenencia a grupos (Host Membership Query message) a las máquinas vecinas de
su red de área local para determinar aquéllas que se mantienen como miembros
activos de grupos. Este mensaje IGMP de solicitud o sondeo se envía en un
datagrama IP con la dirección de destino conteniendo la dirección reservada de
multidifusión, 224.0.0.1, que semánticamente quiere decir “a todas las máquinas
 en esta red de área local”. Asimismo, dicho datagrama IP lleva un TTL = 1 para
indicar que este tipo de mensaje IGMP no debe ser reenviado a ninguna otra red por
ningún otro router de multidifusión local que pudiera haber. En este
• 19 Sihay más de un router de multidifusión, uno de ellos se selecciona como emisor de este tipo de
mensajes.
• 20 Mediante otro protocolo diferente a IGMP, denominado protocolo de distribución y actualización
de la información de pertenencias a grupos de multidifusión o de encaminamiento dinámico de
multidifusión.
• -9-
• escenario, para que un router de multidifusión local pueda difundir alguna
información de pertenencia a otros routers de multidifusión intermedios por
Internet, debe determinar si una o más máquinas, en su red de área local, han
decidido unirse a un grupo de multidifusión. Si para un determinado grupo, no se
reciben informes de miembros después de varios sondeos, el router de multidifusión
asume que no hay destinatarios activos en su red y deja de anunciar miembros del
grupo a otros routers de multidifusión vecinos en Internet. Cuando una máquina
destinataria recibe una solicitud, debe responder con un informe por cada grupo al
que pertenece. Asimismo, una máquina destinataria no emite ningún informe si
quiere abandonar21 el grupo. Se resalta, además, que un router de multidifusión
local no tiene porqué conocer cuántas máquinas pertenecen a un grupo particular;
sólo le debe interesar saber que al menos una máquina pertenece a un determinado
grupo.
• Como se puede ver, intercambiando solicitudes IGMP (entre routers y máquinas
destinatarias en la misma red) e informes IGMP (entre máquinas destinatarias y
routers en la misma red), un router de multidifusión local puede conocer los grupos
de multidifusión que están activos en su propias redes. De esta manera, dicho router
puede reenviar un datagrama IP de multidifusión entrante a la máquina o máquinas
destinatarias, pertenecientes al grupo en cuestión. Versión4Bits16Suma de
comprobaciónTipoDirección de grupo clase D (cero en solicitud)031
• Sin uso8
• Figura 10.- Formato de un mensaje IGMP.
• Como se puede apreciar en la anterior Figura 10, el formato de un mensaje
IGMPv2 (8 octetos) es muy simple:
• � Versión (4 bits).- Identifica el número de versión22.
• 21 Cuando una máquina desea darse de baja de un grupo, simplemente desactiva la aplicación.
• 22 Actualmente, existen tres versiones (1, 2 y 3), de las cuales, la versión 1 es la base fundamental de
las otras dos que se mencionan más adelante en este libro. Las versiones 2 y 3 son las versiones
incorporadas en la mayoría de los sistemas operativos. Por tanto, la última versión de IGMP es la 3
que se apoya en las versiones anteriores, fundamentalmente en la 2 (la más extendida), incorporando
nuevas funcionalidades que se comentarán más adelante. Consecuentemente, para centrarse en lo
fundamental de IGMP, éste libro describe la versión 2.
• - 10 -
• � Tipo (4 bits).- Indica el tipo de mensaje. Existen dos tipos de mensaje:
• �Tipo 1.- Indica un mensaje, de solicitud de pertenencia a grupo, enviado por un
router de multidifusión local a todas las máquinas vecinas conectadas a la misma
red de acceso.
• � Tipo 2.- Indica un informe de pertenencia a grupo enviado por una máquina
destinataria incluida en dicho grupo al resto de máquinas, también, pertenecientes al
citado grupo en la misma red de acceso.
• � Sin uso (8 bits).- Todo a ceros.
• � Suma de comprobación (16 bits).- Se aplica a todo el mensaje IGMP (8 octetos).
Se aplica el mismo algoritmo utilizado por IP.
• � Dirección de grupo (32 bits).- Esta es la dirección IPv4 de la clase D. Contiene
todo a ceros en un mensaje de solicitud, o bien una dirección de grupo en un
mensaje de informe.
• Asimismo, el protocolo IGMP se ha diseñado con el objetivo de evitar congestiones
en una red de área local en función de los siguientes apartados:
• � Toda la comunicación entre máquinas destinatarias y el router de multidifusión
local utiliza multidifusión IP.
• � Un router de multidifusión local no envía mensajes de solicitudes individuales
para cada grupo de multidifusión, sino un mensaje de solicitud (sondeo) para
solicitar información relacionada con la pertenencia en todos los grupos.
• � Las máquinas que son miembros de varios grupos no envían respuestas múltiples
al mismo tiempo. Cuando un mensaje de solicitud de IGMP llega desde un router
de multidifusión local, la máquina asigna un retardo23 aleatorio entre 0 y 10
segundos para cada grupo, y envía una respuesta al correspondiente grupo después
del retardo. Así, una máquina separa sus respuestas aleatoriamente dentro de un
lapso de 10 segundos. Resumiendo, cuando un router de multidifusión local envía
un mensaje de solicitud, todas las máquinas destinatarias, en la misma red de área
local, asignan un retardo aleatorio para las respuestas.
• � Mediante una técnica de supresión de informes IGMP de pertenencias a grupos,
las máquinas escuchan las respuestas o informes de otras máquinas y
• 23 Para dar tiempo a que responda la máquina que haya recibido antes el sondeo.
• - 11 -
• no envían respuestas innecesarias. Es importante resaltar que un router de
multidifusión local no necesita conservar un registro exacto de los miembros de un
grupo porque todas las transmisiones hacia el grupo se envían mediante el software
de multidifusión del interfaz de la red de acceso. El router de multidifusión local
sólo tiene que saber si existe al menos una máquina de un grupo en particular.
Cuando la máquina con el retardo más pequeño24 envía su respuesta mediante
multidifusión, otras máquinas participantes reciben una copia. Cada máquina asume
que el router de multidifusión local también recibió una copia de la primera
respuesta y cancela su respuesta. Resumiendo, se puede mejorar la eficiencia si las
máquinas monitorizan si otra envía el mismo informe antes de la transmisión
programada. Si otra máquina ha enviado el mismo informe, la primera cancela el
suyo. Así en la práctica, sólo una máquina de cada grupo responde a un mensaje de
solicitud enviado por el router de multidifusión local. R1R1M3G3M1G1Solicitud de pertenencia a
gruposOrigen IP=R1Destino IP=224.0.0.1TTL=1Grupo IGMP=0M4M2G1G2Me callo porque he escuchado el informe de M1Informe de pertenencia a
G1Origen IP=M1Destino IP=G1TTL=1Grupo IGMP=G1
• Figura 11.- Envío de solicitudes e informes de pertenencias a grupos.
• En el ejemplo de la anterior Figura 11, el router de multidifusión local R1 envía un
mensaje IGMP de solicitud de pertenencia a grupos. Suponiendo que M1 dispone
de un retardo de respuesta inferior a M4, M1 responde con un mensaje IGMP que
contiene un informe de pertenencia al grupo G1. Este último mensaje se transmite
sólo al grupo G125, al que pertenece la máquina de origen, con el objetivo de que el
 resto de máquinas de dicho grupo escuchen el mensaje y desactiven sus
temporizadores de respuesta para no tener que mandar otro
• 24 O lo que es lo mismo, la primera máquina que recibe un mensaje Tipo 1 de sondeo es la primera en
responder.
• 25 En el campo destino de la cabecera IP se pone la dirección IP de multidifusión del grupo G1.

• - 12 -
• informe repetido. Por consiguiente, aparte de R1, este último mensaje también lo
escucha la máquina M4; pero ésta no transmite otro mensaje similar ya que a R1 le
basta con saber26 que al menos una máquina (en este caso M1) pertenece a G1.
• Actualmente, existen tres versiones del protocolo IGMP:
• • IGMP Versión 1 (RFC-1112).- Recoge todo lo que se ha estudiado hasta el
momento.
• • IGMP Versión 2 (RFC-2236).- Es la versión actualizada y mejorada de IGMPv1.
Mantiene la compatibilidad con IGMPv1.
• • IGMP Versión 3 (RFC-3376).- Es la versión actualizada y mejorada de IGMPv1 e
IGMPv2. Aborda algunas debilidades de anteriores versiones como, por ejemplo, la
transmisión de información no deseada a grupos de multidifusión. Para ello, permite
a los sistemas finales especificar la lista de máquinas desde las que quieren recibir
datagramas IP de multidifusión y que dicho tráfico sea bloqueado por los routers27
de multidifusión locales.
• Finalmente, conviene recordar que IGMP se diseñó para operar con IPv4.
Obviamente, IPv6 requiere también las mismas funcionalidades, las cuales se han
añadido, no en otro IGMP para IPv6, sino en los correspondientes mensajes del
protocolo ICMPv6. Por consiguiente, el protocolo de envío de mensajes de control
en Internet, ICMPv6, incluye toda la funcionalidad del protocolo IGMP a través de
los dos mensajes fundamentales que se han estudiado para IGMP: un mensaje de
sondeo o consulta de pertenencia a grupos y otro de informe de pertenencia a
grupo. Dichos mensajes ICMPv6, se usan de la misma manera que en IGMP.
• 26 Elcontenido del campo dirección de grupo clase D (Grupo IGMP en la anterior Figura 11).
• 27 Y como alternativa por los propios sistemas finales.

• - 13 –
 Sho Suppo Commun Principio del form
p rt ity

Final del formular

Support Home Page

Manuals

Regresar a la páginade contenido

Configuraciónde la multidifusión IP

Dell™ PowerConnect™ serie 6200 — Guíadel usuario

DVMRP

IGMP

Multidifusión

PIM-DM

PIM-SM

Losprotocolosde multidifusión se utilizan para entregar paquetesde multidifusiónde un origen a

varios receptores. Facilitan un mejor usode la amplitudde banda y un menor procesamientodel
host ydel enrutador, con lo que su uso es idóneo en aplicacionesde conferenciade vídeo y audio
herramientasde pizarra o tablerosde cotizaciones, entre otras.

Las aplicacionesde multidifusión envían una copiade un paquete y la dirigen a un grupode

receptores (direccióndel grupode multidifusión) quedesea recibirla, en lugarde a un único recep
(direcciónde difusión única). La multidifusióndepende de la red para reenviar los paquetes
únicamente a las redes y hosts quedeben recibirlos.

Los enrutadores que admiten la multidifusión o que la tienen activada reenvían paquetesde
multidifusión según las rutas especificadas en la basede datosde informaciónde enrutamientod
multidifusión (MRIB). Losprotocolosde multidifusión que se ejecutan en el enrutador crean estas
rutas en la MRIB durante el procesode creaciónde árbolesde distribuciónde multidifusión. Los
distintosprotocolosde enrutamientode multidifusión IP utilizan técnicas diferentes para crear
dichos árboles.

Si el tráficode multidifusión va a direccionarse a travésde partede una red que no admite la

multidifusión (enrutadores que no la admiten), los paquetesde multidifusión se encapsulan en u
datagrama IP y se envían como paquetesde difusión única. Cuando el enrutadorde
multidifusióndel extremo remotodel túnel recibe el paquete, extrae la encapsulación IP y reenví
el paquete como paquetede multidifusión IP. Este procesode encapsulaciónde paquetesde
multidifusión IP sedenomina tunelado.

Para ver la páginade menú IP Multicast (Multidifusión IP), haga clic en IP Multicast(Multidifusión
en la vistade árbol. La páginade menú IP Multicast (Multidifusión IP) contiene enlaces a los
procedimientos siguientes:

DVMRP

IGMP

Multidifusión

PIM-DM

PIM-SM

DVMRP

DVMRP intercambia paquetes sonda con todos los enrutadores que lo tienen activado, establec
relaciones bidireccionales entre vecinos y genera una tablade vecinos. Intercambia paquetesde
informe y crea una tablade topologíade difusión única, con la que genera la tablade
enrutamientode multidifusión. Esta tabla se utiliza para direccionar los paquetesde multidifusió
Dado que todos los enrutadores DVMRP utilizan el mismoprotocolo de enrutamientode difusión
única, se evitan los buclesde enrutamiento.

La páginade menú DVMRPcontiene enlaces a páginas web que permitendefinir y visualizar los
parámetros y datosde DVMRP. Para visualizar esta página, haga clic en IP Multicast (Multidifusió
IP)® DVMRP en la vistade árbol.

A continuación figuran las páginas web a las que se puede accederdesde esta páginade menú:

Configuración globalde DVMRP

Configuraciónde la interfaz DVMRP

Resumende la configuraciónde DVMRP

Resumendel siguiente salto

Resumende poda

Resumende rutas

Configuración globalde DVMRP

Utilice la página DVMRP Global Configuration(Configuración globalde DVMRP) paradefinir los

valores globalesde DVMRP.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Global
Configuration(Configuración global) en la vistade árbol.

Ilustración 13-1. Configuración globalde DVMRP

La página DVMRP Global Configuration(Configuración globalde DVMRP) contiene los campos

siguientes:

Admin Mode(Modode administración): seleccione Enable (Activar) o Disable (Desactivar) en el

menúdesplegable.De este modo, sedefine el estadode administraciónde DVMRP como activo o
inactivo. El valor predeterminado es Disable (Desactivar).
Version(Versión): valor actualde la cadenade caracteresde la versiónde DVMRP.

Total Number of Routes(Número totalde rutas): númerode rutas especificadas en la tablade

enrutamientode DVMRP.

Reachable Routes(Rutas accesibles): númerode rutas especificadas en la tablade enrutamiento

DVMRP que tienen una métrica no infinita.

Definicióndel modode administraciónde DVMRP

Abra la página DVMRP Global Configuration(Configuración globalde DVMRP).

Defina Admin Mode(Modode administración) como Enable (Activar) o Disable (Desactivar) para
activar odesactivar DVMRP.

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la configuraciónde DVMRP y se actualiza el dispositivo.

Configuraciónde DVMRP mediante los comandosde la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

Comandosde DVMRP

Configuraciónde la interfaz DVMRP

Utilice la página DVMRP Interface Configuration(Configuraciónde la interfaz DVMRP) para

configurar una interfaz DVMRP.Debe configurar al menos una interfazde enrutador antesde
configurar una interfaz DVMRP.De lo contrario, aparece un mensaje que indica que no hay
interfacesde enrutador disponibles y no se muestra la pantallade configuración.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Interface
Configuration(Configuraciónde interfaz) en la vistade árbol.

Ilustración 13-2. Configuraciónde la interfaz DVMRP

La página DVMRP Interface Configuration(Configuraciónde la interfaz DVMRP) contiene los camp
siguientes:

Interface(Interfaz): seleccione la interfaz cuyos datos se van a configurar.Debe configurar al

menos una interfazde enrutador antesde configurar una interfaz DVMRP.

Interface Mode(Modode interfaz): seleccione Enable (Activar) o Disable (Desactivar) en el

menúdesplegable paradefinir el modode administraciónde la interfazde enrutamientode DVMRP
seleccionada.

Interface Metric(Métricade la interfaz): introduzca la métricade DVMRP para la interfaz

seleccionada. Este valor se envía enmensajes de DVMRP como costede acceder a esta red. Los
valores válidos están comprendidos entre 1 y 31.

Configuraciónde una interfaz DVMRP

Abra la página DVMRP Interface Configuration(Configuraciónde la interfaz DVMRP).

Seleccione la interfaz que va a configurar en el campo Interface (Interfaz).

Modifique los campos restantes según sea necesario.

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la configuraciónde la interfaz y se actualiza el dispositivo.

Configuraciónde una interfaz DVMRP mediante los comandosde la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

Comandosde DVMRP

Resumende la configuraciónde DVMRP

Utilice la página DVMRP Configuration Summary(Resumende la configuraciónde DVMRP) para v

o imprimir los datos y la configuraciónde DVMRP correspondientes a una interfaz
seleccionada.Debe configurar al menos una interfazde enrutador para poder ver los datosde un
interfaz DVMRP.De lo contrario, aparece un mensaje que indica que no hay interfacesde enruta
disponibles y no se muestra la pantallade resumende la configuración.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Configuration
Summary(Resumende la configuración) en la vistade árbol.

Ilustración 13-3. Resumende la configuraciónde DVMRP

La página DVMRP Configuration Summary(Resumende la configuraciónde DVMRP) contiene los

campos siguientes:

Interface(Interfaz): seleccione la interfaz cuyos datos se van a mostrar.Debe configurar al meno

una interfazde enrutador para poder ver los datosde una interfaz DVMRP.

Parámetrosde interfaz

Interface Mode(Modode interfaz): muestra el modode administraciónde la interfazde

enrutamientode DVMRP seleccionada, con los valores Enable (Activar) o Disable (Desactivar).

Protocol State(Estadodelprotocolo): muestra el estado operativodelprotocolo DVMRP en la interf

seleccionada, con los valores Operational (Operativo) o Non-operational (No operativo).

Local Address(Dirección local): muestra la dirección IP que se utiliza como direcciónde origende
los paquetes enviadosdesde la interfaz seleccionada.

Interface Metric(Métricade la interfaz): muestra la métrica que se utiliza para calcular los
vectoresde distancia correspondientes a la interfaz seleccionada.

Estadísticasde la interfaz

Generation ID(IDde generación): muestra la IDde generaciónde DVMRP que el enrutador utiliza
para la interfaz seleccionada. Este valor se restablece cada vez que se inicia o se reinicia una
interfaz y se coloca enmensajes de poda. Si se produce un cambio en una IDde generación, se
informa a los enrutadores vecinosde quedebedescartarse cualquier información previa sobre es
enrutador.

Received Bad Packets(Paquetes erróneos recibidos): númerode paquetes no válidos recibidos e

la interfaz seleccionada.

Received Bad Routes(Rutas erróneas recibidas): númerode rutas no válidas recibidas en la

interfaz seleccionada.

Sent Routes(Rutas enviadas): númerode rutas enviadas en la interfaz seleccionada.

Parámetrosde vecinos

Neighbor IP(IPde vecino): dirección IPdel vecinodel que se muestra información.

State(Estado): estadodel enrutador vecino especificado en la interfaz seleccionada, que puede s

activo o inactivo.

Neighbor Uptime(Tiempode actividaddel vecino): tiempode actividadde DVMRPdel vecino

especificado en la interfaz seleccionada. Se tratadel tiempo transcurridodesde que se obtuvo la
entradadel vecino.

Neighbor Expiry Time(Tiempode caducidaddel vecino): tiempode caducidadde DVMRPdel vecino

especificado en la interfaz seleccionada. Se tratadel tiempo restante antesde que caduque la
entradadel vecino, y no es aplicable si el estadodel enrutador vecino es inactivo.

Generation ID(IDde generación): IDde generaciónde DVMRPdel vecino especificado en la interfa

seleccionada.

Major Version(Versión principal): versión principalde DVMRPdel vecino especificado en la interfa

seleccionada.

Minor Version(Versión secundaria): versión secundariade DVMRPdel vecino especificado en la

interfaz seleccionada.

Capabilities(Funciones): funcionesde DVMRPdel vecino especificado en la interfaz seleccionada.

Received Routes(Rutas recibidas): númerode rutas recibidas para el vecino especificado en la

interfaz seleccionada.

Received Bad Packets(Paquetes erróneos recibidos): númerode paquetes no válidos recibidos

para el vecino especificado en la interfaz seleccionada.

Received Bad Routes(Rutas erróneas recibidas): númerode rutas no válidas recibidas para el
vecino especificado en la interfaz seleccionada.

Visualizacióndel resumende la configuraciónde DVMRP mediante el comandode la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

Comandosde DVMRP

Resumendel siguiente salto

Utilice la página Next Hop Summary(Resumendel siguiente salto) para ver o imprimir el
resumendel siguiente salto por la IPde origen.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Next Hop
Summary(Resumendel siguiente salto) en la vistade árbol.

Ilustración 13-4. Resumendel siguiente salto

La página Next Hop Summary(Resumendel siguiente salto) contiene los campos siguientes:

Source IP(IPde origen): muestra la dirección IP que se utiliza con la máscarade origen para
identificar la redde origen correspondiente a esta entradade la tabla.

Source Mask(Máscarade origen): muestra la máscarade red que se utiliza con la dirección IPde
origen.

Next Hop Interface(Interfazdel siguiente salto): muestra la interfazde salida correspondiente al

siguiente salto.

Type(Tipo): muestra el tipodel siguiente salto. Leaf (Hoja) significa que no existen
vecinosdependientesdescendentes en la interfazde salida.De lo contrario, el tipo es Branch
(Rama).

Visualizacióndel resumendel siguiente salto mediante el comandode la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

Comandosde DVMRP

Resumende poda

Utilice la página Prune Summary(Resumende poda) para ver o imprimir el resumende poda por
IPde grupo.
Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Prune
Summary(Resumende poda) en la vistade árbol.

Ilustración 13-5. Resumende poda

La página Prune Summary(Resumende poda) contiene los campos siguientes:

Group IP(IPde grupo): direccióndel grupo que se ha podado.

Source IP(IPde origen): direccióndel origen ode la redde origen que se ha podado.

Source Mask(Máscarade origen): máscarade subred que se combinará con la dirección IPde orig
para identificar el origen o la redde origen que se ha podado.

Expiry Time (secs)(Tiempode caducidad [seg.]): tiempo restante antesde que caduque esta pod
en el vecino ascendente. Si no se han recibidomensajes de podade los vecinosdescendentes, se
establece en el valordel temporizadorde duraciónde poda predeterminado;de lo contrario, se
establece en el valor más pequeño recibido o en valordel temporizador predeterminado, el que
sea inferiorde los dos.

Visualizacióndel resumende poda mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde DVMRP
Resumende rutas

Utilice la página Route Summary(Resumende rutas) para ver o imprimir el resumende rutasde
DVMRP.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® DVMRP® Route
Summary(Resumende rutas) en la vistade árbol.

Ilustración 13-6. Resumende rutas

La página Route Summary(Resumende rutas) contiene los campos siguientes:

Source Address(Direcciónde origen): direcciónde red que se combina con la máscarade origen
para identificar los orígenesde esta entrada.

Source Mask(Máscarade origen): máscarade subred que se combinará con la direcciónde origen
para identificar los orígenesde esta entrada.

Upstream Neighbor(Vecino ascendente): direccióndel vecino ascendente (por ejemplo, un vecin

RPF)desde la que se reciben datagramas IPde estos orígenes.

Interface(Interfaz): interfaz en la que se reciben los datagramas IP que estos orígenes han
enviado. Un valorde 0 suele indicar que la ruta es un conjunto para el que no existe una
interfazdel siguiente salto.

Metric(Métrica): distancia expresada en saltos a la subredde origen.

Expiry Time(Tiempode caducidad): tiempo mínimo restante antesde que caduque esta entrada.

Up Time(Tiempode actividad): tiempo transcurridodesde que el enrutador obtuvo la ruta

representada por esta entrada.

Visualizacióndel resumende rutasde DVMRP mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde DVMRP

IGMP

Los sistemas IPv4 (hosts y enrutadores) utilizan elprotocolo de administraciónde gruposde

Internet (IGMP) para notificar su pertenencia a gruposde multidifusión IP a cualquier enrutadord
multidifusión vecino. La serie 6200 realiza la funciónde enrutadorde multidifusióndelprotocolo
IGMP, esdecir, recopila la información sobre pertenencia que necesita el enrutamientode
multidifusión activo. Losprotocolosde enrutamientode multidifusión que se admiten actualment
en la serie 6200 son DVMRP, PIM-DM y PIM-SM.

La serie 6200 admite la versión 3deIGMP. Esta versión es compatible con el filtradode orígenes,
que es la capacidad que tiene un sistema para notificar su interés en recibir paquetes
únicamentede direccionesde origen específicas, necesario para admitir la multidifusión
específicade origen (SSM), ode todas las direccionesde origen que no sean específicas enviadas
unadeterminada direcciónde multidifusión. Está diseñada para que pueda interoperar con las
versiones 1 y 2.

La páginade menú IGMPcontiene enlaces a páginas web que permitendefinir y visualizar los
parámetros y datosdeIGMP. Para visualizar esta página, haga clic en IP Multicast (Multidifusión
IP)®IGMP en la vistade árbol.

A continuación figuran las páginas web a las que se puede accederdesde esta páginade menú:

Configuración globaldeIGMP

Interfazde enrutamiento

Interfazde proxy

Configuración globaldeIGMP

Utilice la página IGMP Global Configuration(Configuración globaldeIGMP) paradefinirIGMP en el

sistema como activo o inactivo.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)®IGMP® Global

Configuration(Configuración global) en la vistade árbol.
Ilustración 13-7. Configuración globaldeIGMP

La página IGMP Global Configuration(Configuración globaldeIGMP) contiene el campo siguiente:

Admin Mode(Modode administración): seleccione Enable (Activar) o Disable (Desactivar) en el

menúdesplegable paradefinir el estadode administracióndeIGMP del enrutador como activo o
inactivo. El valor predeterminado es Disable (Desactivar).

Definicióndel mododeIGMP

Abra la página IGMP Global Configuration(Configuración globaldeIGMP).

Defina Admin Mode(Modode administración) como Enable (Activar) o Disable (Desactivar) para
activar odesactivarIGMP.

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la configuracióndeIGMP y se actualiza el dispositivo.

Definicióndel mododeIGMP mediante los comandosde la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

ComandosdeIGMP

Interfazde enrutamiento
La páginade menú Routing Interface(Interfazde enrutamiento) contiene enlaces a páginas web
que permiten configurar y visualizar los parámetros y datosdel enrutamientoIGMP. Para visualiz
esta página, haga clic en IP Multicast (Multidifusión IP)®IGMP® Routing Interface(Interfazde
enrutamiento) en la vistade árbol. A continuación figuran las páginas web a las que se puede
accederdesde esta páginade menú:

Configuraciónde interfazIGMP

Resumende la configuracióndeIGMP

Información sobre cachédeIGMP

Informacióndetalladade pertenencia a la interfazIGMP

Configuraciónde interfazIGMP

Utilice la página IGMP Interface Configuration(Configuraciónde interfazIGMP) para configurar o

mostrar los parámetrosde la interfazdel enrutador.Debe configurar como mínimo una interfazde
enrutamiento válida para poder acceder a esta página y configurar elIGMP de multidifusión IP.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)®IGMP® Routing

Interface(Interfazde enrutamiento)® Interface Configuration(Configuraciónde interfaz) en la
vistade árbol.

Ilustración 13-8. Configuraciónde interfazIGMP

La página IGMP Interface Configuration(Configuraciónde interfazIGMP) contiene los campos

siguientes:

Interface(Interfaz): seleccione en el menúdesplegable la interfaz cuyos datosdesea visualizar o

configurar.

Interface Mode(Modode interfaz): seleccione Enable (Activar) o Disable (Desactivar) en el

menúdesplegable paradefinir el estadode administracióndeIGMP en la interfaz seleccionada. El
valor predeterminado es Disable (Desactivar).

Version(Versión): introduzca la versióndeIGMP quedesea configurar en la interfaz seleccionada.

Los valores válidos están comprendidos entre 1 y 3, y el valor predeterminado es 3. Este campo
sólo puede configurarse si el modode interfazIGMP está activado.

Robustness(Robustez): introduzca el valorde robustez. Esta variable permite la adaptación a la

pérdida previstade paquetes en una subred. Si prevé que en la subred se van a producir
pérdidas,debe introducir un número más alto para este parámetro.IGMP es robusto (variablede
robustez 1) con las pérdidasde paquetes. Los valores válidos están comprendidos entre 1 y 255
El valor predeterminado es 2.

Query Interval (secs)(Intervalode consulta [seg.]): introduzca la frecuencia, expresada en

segundos, a la que se transmitirán los paquetesde consulta al hostIGMP en esta interfaz. Los
valores válidos están comprendidos entre 1 y 3 600. El valor predeterminado es 125.

Query Max Response Time (1/10 of a second)(Tiempo máximode respuesta a consulta [1/10de
segundo]): introduzca el tiempo máximode respuesta a consulta que se anunciará en las
consultasIGMPv2 en esta interfaz, expresado en décimasde segundo. El valor predeterminado e
100. Los valores válidos están comprendidos entre 0 y 255.

Startup Query Interval (secs)(Intervalode consultade inicio [seg.]): introduzca el númerode

segundos entre la transmisiónde consultasde inicio en la interfaz seleccionada. Los valores válid
están comprendidos entre 1 y 300. El valor predeterminado es 31.

Startup Query Count(Recuentode consultasde inicio): introduzca el númerode consultas que se

enviarán durante el inicio. Los valores válidos están comprendidos entre 1 y 20. El valor
predeterminado es 2.

Last Member Query Interval (1/10 of a second)(Intervalode consultade último miembro [1/10de
segundo]): introduzca el intervalode consultade último miembro, expresado en décimasde
segundo. Se tratadel tiempo máximode respuesta que se insertará en consultas específicasde
grupo que se envían como respuesta amensajes de grupode cese. Asimismo, es el tiempo que
transcurre entremensajes de consultas específicasde grupo. Los valores válidos están
comprendidos entre 0 y 255. El valor predeterminado es 10, que no se utiliza en la versión
1deIGMP.

Last Member Query Count(Recuentode consultasde último miembro): introduzca el númerode

consultas que se enviarán al recibir un informede grupode cese. Los valores válidos están
comprendidos entre 1 y 20. El valor predeterminado es 2.

Configuraciónde una interfazde enrutamientoIGMP

Abra la página IGMP Interface Configuration(Configuraciónde interfazIGMP).

Seleccione la interfaz que va a configurar en el campo Interface (Interfaz).

Modifique los campos restantes según sea necesario.

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la configuraciónde la interfaz y se actualiza el dispositivo.

Configuraciónde una interfazde enrutamientoIGMP mediante el comandode la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

ComandosdeIGMP

Resumende la configuracióndeIGMP

Utilice la página IGMP Configuration Summary(Resumende la configuracióndeIGMP) para

visualizar los parámetros y datosdel enrutamientoIGMP.Debe configurar como mínimo una
interfazde enrutadorIGMP para acceder a esta página.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)®IGMP® Routing

Interface(Interfazde enrutamiento)® Configuration Summary(Resumende la configuración) en l
vistade árbol.

Ilustración 13-9. Resumende la configuracióndeIGMP

La página IGMP Configuration Summary(Resumende la configuracióndeIGMP) contiene los camp
siguientes:

Interface (Interfaz): seleccione la interfaz cuyos datos se van a mostrar.

Parámetrosde interfaz

Interface Mode(Modode interfaz): estadode administracióndeIGMP en la interfaz seleccionada.

IP Address(Dirección IP): dirección IPde la interfaz seleccionada.

Subnet Mask(Máscarade subred): máscarade subred correspondiente a la dirección IPde la

interfaz seleccionada.

Protocol State(Estadodelprotocolo): estado operativodeIGMP en la interfaz seleccionada.

Version(Versión): versióndeIGMP configurada en la interfaz seleccionada.

Query Interval (secs)(Intervalode consulta [seg.]): frecuencia con la que se transmiten los
paquetesde consulta al hostIGMP en la interfaz seleccionada.

Query Max Response Time (1/10 of a second)(Tiempo máximode respuesta a consulta [1/10de
segundo]): tiempo máximode respuesta a consulta que se anuncia en las consultasIGMPv2
enviadasdesde la interfaz seleccionada.

Robustness(Robustez): parámetrode robustezde la interfaz seleccionada. Esta variable permite

adaptación a la pérdida previstade paquetes en una subred. Si se prevé que se van a producir
pérdidas en una subred, puede aumentar la variablede robustez.IGMP es robusto (variablede
robustez 1) con las pérdidasde paquetes.

Startup Query Interval (secs)(Intervalode consultade inicio [seg.]): intervalo en el que se envían
consultasde inicio en la interfaz seleccionada.

Startup Query Count(Recuentode consultasde inicio): númerode consultas que se enviarán

durante el inicio.

Last Member Query Interval (1/10 of a second)(Intervalode consultade último miembro [1/10de
segundo]): tiempo máximode respuesta que se inserta en consultas específicasde grupo enviad
en respuesta amensajes de grupode cese. También se tratadel tiempo que transcurre
entremensajes de consultas específicasde grupo. Es posible ajustar este valor para modificar la
latenciade cesede la red. Si se introduce un valor pequeño, se reduce el tiempo paradetectar la
pérdidadel último miembrode un grupo. Este valor no se utiliza en la versión 1deIGMP.

Last Member Query Count(Recuentode consultasde último miembro): númerode consultas que
enviarán al recibir un informede grupode cese.

Estadísticasde la interfaz

Querier(Solicitante): direccióndel solicitanteIGMP en la subred IP a la que se conecta la interfaz

seleccionada.

Querier Status(Estadodel solicitante): indica si la interfaz seleccionada tiene o no solicitantes.

Querier Up Time (secs)(Tiempode actividaddel solicitante [seg.]): tiempo, expresado en segund

que ha transcurridodesde que se modificó por última vez el solicitantede la interfazIGMP.

Querier Expiry Time (secs)(Tiempode caducidaddel solicitante [seg.]): tiempo restante, expresa
en segundos, antesde que caduque el otro temporizador actualdel solicitante. Si el sistema loca
es el solicitante, el valor es cero.

Wrong Version Queries(Consultasde versión errónea): númerode consultas que se han recibido
la interfaz seleccionada con una versióndeIGMP que no coincide con la configurada para la
interfaz durante la duraciónde la entrada.IGMP requiere que todos los enrutadoresde una LAN
estén configurados para que ejecuten la misma versióndeIGMP. Por lo tanto, se indica unerrorde
configuración si se reciben consultas con un númerode versión erróneo.

Number of Joins(Númerode uniones): númerode veces que se ha añadido una pertenencia a gru
en la interfaz seleccionada, esdecir, el númerode veces que se ha añadido una entradade esta
interfaz a la tablade caché. Esto indica la cantidadde actividaddeIGMP que hay en la interfaz.

Number of Groups(Númerode grupos): número actualde entradas correspondientes a la interfaz

seleccionada presentes en la tablade caché.

Visualizaciónde la configuraciónde enrutamientoIGMP mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

ComandosdeIGMP

Información sobre cachédeIGMP

Utilice la página IGMP Cache Information(Información sobre cachédeIGMP) para ver los datos y
parámetrosde caché correspondientes a una direcciónde grupode multidifusión IP.Debe configu
como mínimo una interfazde enrutadorIGMP para acceder a esta página. Asimismo, sedeben
haber recibido los informesde pertenencia a grupo en la interfaz seleccionada para que los dato
se muestren en esta página.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)®IGMP® Routing

Interface(Interfazde enrutamiento)® Cache Information (Información sobre caché) en la vistade
árbol.

Ilustración 13-10. Información sobre cachédeIGMP

La página IGMP Cache Information(Información sobre cachédeIGMP) contiene los campos

siguientes:
Interface (Interfaz): seleccione la interfaz cuyos datos se van a mostrar.

Multicast Group IP(IPde grupode multidifusión): seleccione la direccióndel grupode multidifusión

cuyos datosdesea visualizar. Si no se han recibido informesde pertenencia a grupo en la interfa
seleccionada, no puede realizar esta selección y no se muestra ningún dato en esta página.

Last Reporter(Último informador): dirección IPdel origendel último informede pertenencia recibi
para la direccióndel grupode multidifusión IP en la interfaz seleccionada.

Up Time(Tiempode actividad): tiempo transcurridodesde la creaciónde esta entrada.

Expiry Time(Tiempode caducidad): tiempo mínimo restante antesde que caduque esta entrada.

Version 1 Host Timer(Temporizadorde host versión 1): tiempo restante hasta que el enrutador
local asuma que ya no hay miembrosde la versión 1deIGMP en la subred IP conectada a esta
interfaz. Cuando se recibe un informede pertenencia aIGMPv1, este temporizador se restablece
temporizadorde pertenencia a grupo. Mientras este temporizador no esté en cero, el enrutador
local ignora losmensajes de cesedeIGMPv2de este grupo que recibe en la interfaz seleccionada.
Este campo sólo aparece si la interfaz está configurada para la versión 1deIGMP.

Version 2 Host Timer(Temporizadorde host versión 2): tiempo restante hasta que el enrutador
local asuma que ya no hay miembrosde la versión 1deIGMP en la subred IP conectada a esta
interfaz. Cuando se recibe un informede pertenencia aIGMPv2, este temporizador se restablece
temporizadorde pertenencia a grupo. Mientras este temporizador no esté en cero, el enrutador
local ignora losmensajes de cesedeIGMPv1 eIGMPv3de este grupo que recibe en la interfaz
seleccionada. Este campo sólo aparece si la interfaz está configurada para la versión 2deIGMP.

Compatibility(Compatibilidad): muestra el modode compatibilidadde grupo (versiones 1, 2 y 3)

correspondiente a este grupo en la interfaz especificada.

Filter Mode(Modode filtrado): modode filtradode origen (con los valores Include [Incluir], Exclude
[Excluir] y NA [ND]) correspondiente al grupo especificado en esta interfaz. Si el modo NA (ND)
está activo, el campo aparece en blanco.

Visualizaciónde información sobre caché mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

ComandosdeIGMP

Informacióndetalladade pertenencia a la interfazIGMP

Utilice la página IGMP Interface Detailed Membership Info (Informacióndetalladade pertenencia

la interfazIGMP) para ver informacióndetalladade pertenencia correspondiente a una
interfaz.Debe configurar como mínimo una interfazde enrutadorIGMP para acceder a esta págin
Asimismo, sedeben haber recibido los informesde pertenencia a grupo en la interfaz selecciona
para que los datos se muestren en esta página.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)®IGMP® Routing

Interface(Interfazde enrutamiento)®IGMP Interface Detailed Membership
Info(Informacióndetalladade pertenencia a la interfazIGMP) en la vistade árbol.

Ilustración 13-11. Informacióndetalladade pertenencia a la interfazIGMP

La página IGMP Interface Detailed Membership Info(Informacióndetalladade pertenencia a la

interfazIGMP) contiene los campos siguientes:

Interface (Interfaz): seleccione la interfaz cuyos datos se van a mostrar.

Multicast Group IP(IPde grupode multidifusión): seleccione la direccióndel grupode multidifusión

cuyos datosdesea visualizar. Si no se han recibido informesde pertenencia a grupo en la interfa
seleccionada, no puede realizar esta selección y no se muestra ningunode los campos restantes

Interface(Interfaz): interfaz en la que se reenvían los paquetesde multidifusión.

Group Compatibility Mode(Modode compatibilidadde grupo): modode compatibilidadde grupo

(versiones 1, 2 y 3) correspondiente a este grupo en la interfaz especificada.

Filter Mode(Modode filtrado): modode filtradode origen correspondiente al grupo especificado e

esta interfaz. Los valores posibles son Include (Incluir), Exclude (Excluir) y NA (ND).

Source Hosts(Hostsde origen): direccionesde origen que son miembrosde esta direcciónde
multidifusión.

Expiry Time(Tiempode caducidad): intervalode tiempode caducidad para cada direcciónde orige
que es miembrode este grupode multidifusión. Se tratadel tiempo tras el que caduca la entrada
origen especificada.

Visualizaciónde informacióndetalladade pertenencia a la interfazIGMP

Abra la página IGMP Interface Detailed Membership Info (Informacióndetalladade pertenencia a

interfazIGMP).

Seleccione la interfaz quedesea visualizar en el menúdesplegable Interface (Interfaz).

Seleccione la IP quedesea en Multicast Group IP(IPde grupode multidifusión).

Se muestra informacióndetalladade pertenencia correspondiente a esta interfaz y la IPdel grupo

multidifusión.

Visualizaciónde informacióndetalladade pertenencia a la interfazIGMP mediante el comandode l

CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

ComandosdeIGMP

Interfazde proxy

El propósitodel proxyIGMP es activar un enrutadorde multidifusión para obtener informaciónde

pertenencia a un grupode multidifusión y poder reenviar paquetesde multidifusión según la
informaciónde pertenencia a grupo. El proxyIGMP sólo puede funcionar endeterminadas
topologías que no requierenprotocolosde enrutamientode multidifusión (por ejemplo, DVMRP, P
DM y PIM-SM) y que tienen topologíasde árbol o similares, ya que no admite funciones como
árbolesde extensión para corregir buclesde rutasde paquetes.

La páginade menú Proxy Interface(Interfazde proxy) contiene enlaces a páginas web que
permitendefinir y visualizar los parámetros y datosde la interfazde proxy. Para visualizar esta
página, haga clic en IP Multicast (Multidifusión IP)®IGMP® Proxy Interface(Interfazde proxy) en
vistade árbol. A continuación figuran las páginas web a las que se puede accederdesde esta
páginade menú:

Configuraciónde la interfazde proxyIGMP

Resumende la configuraciónde proxyIGMP

Informaciónde pertenencia a la interfazde proxyIGMP

Informacióndetalladade pertenencia a la interfazde proxyIGMP

Configuraciónde la interfazde proxyIGMP

El enrutadorIGMP (sistema IPv4) utiliza el proxyIGMP para activar el sistema para que
emitamensajes de hostIGMP en nombrede los hosts que el sistema hadetectado mediante
interfacesdel enrutadorIGMP estándar. Por consiguiente, esta función actúa como proxyde todo
los hosts que residen en las interfacesdel enrutador.

Utilice la página IGMP Proxy Interface Configuration (Configuraciónde la interfazde proxyIGMP)

para configurar el proxyIGMP para una interfaz.Debe haber configurado como mínimo una
interfazde enrutador para poder configurar o visualizar los datosde una interfazde proxyIGMP y
nodebe ser una interfazde enrutamientoIGMP.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® IGMP® Proxy
Interface(Interfazde proxy)® Interface Configuration (Configuraciónde interfaz) en la vistade
árbol.

Ilustración 13-12. Configuraciónde la interfazde proxyIGMP

La página IGMP Proxy Interface Configuration(Configuraciónde la interfazde proxyIGMP) contien

los campos siguientes:

Interface(Interfaz): seleccione en el menúdesplegable el puerto cuyos datosdesea visualizar o

configurar.Debe haber configurado como mínimo una interfazde enrutador para poder configura
o visualizar los datosde una interfazde proxyIGMP y nodebe ser una interfazde enrutamientoIGM
Este campo sólo puede configurarse si el modode interfaz estádesactivado.

Interface Mode(Modode interfaz): seleccione Enable (Activar) o Disable (Desactivar) en el

menúdesplegable paradefinir el estadode administracióndel proxyIGMP en la interfaz
seleccionada. El valor predeterminado es Disable (Desactivar). Para activar el modode interfazd
proxyIGMP,deben activarse los modosde administración globalde enrutamiento,IGMP y
multidifusión.

Unsolicited Report Interval(Intervalode informe no solicitado): introduzca el valordel intervalode

tiempo no solicitado en segundos. El intervalode informe no solicitado es el tiempo que transcu
entre las repeticionesde un informe inicialdel host sobre pertenencia a un grupo. Los valores
válidos están comprendidos entre 1 y 260. El valor predeterminado es 1.

Configuraciónde la interfazde proxyIGMP

Abra la página IGMP Proxy Interface Configuration (Configuraciónde la interfazde proxyIGMP).

Seleccione la interfaz quedesea visualizar en el menúdesplegable Interface (Interfaz).

Modifique los campos restantes según sea necesario.

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la configuraciónde la interfazde proxy y se actualiza el dispositivo.

Configuraciónde la interfazde proxyIGMP mediante los comandosde la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

Comandosdel proxyIGMP

Resumende la configuraciónde proxyIGMP

Utilice la página IGMP Proxy Configuration Summary (Resumende la configuraciónde proxyIGMP

para ver las configuracionesde la interfazde proxy por interfaz.Debe haber configurado como
mínimo una interfazde enrutador para que los datos se muestren en esta página.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® IGMP® Proxy
Interface(Interfazde proxy)® Configuration Summary (Resumende la configuración) en la vistad
árbol.

Ilustración 13-13. Resumende la configuraciónde proxyIGMP

La página IGMP Proxy Configuration Summary(Resumende la configuraciónde proxyIGMP)
contiene los campos siguientes:

Interface(Interfaz): muestra la interfaz en la que está activado el proxyIGMP. Sólo puede haber
una interfazde proxyIGMP.

IP Address(Dirección IP): dirección IPde la interfazde proxyIGMP.

Subnet Mask(Máscarade subred): máscarade subred correspondiente a la dirección IPde la

interfazde proxyIGMP.

Admin Mode(Modode administración): estadode administracióndel proxyIGMP en la interfaz

seleccionada.

Operational Mode(Modo operativo): estado operativode la interfazde proxyIGMP.

Number of Groups(Númerode grupos): número actualde entradasde grupode multidifusión

correspondientes a la interfazde proxyIGMP presentes en la tablade caché.

Version(Versión): versióndeIGMP configurada en la interfazde proxyIGMP.

Unsolicited Report Interval(Intervalode informe no solicitado): tiempo que transcurre entre las
repeticionesde un informe inicialdel host sobre pertenencia a un grupo. Valor predeterminado: 1
segundo.

Version 1 Querier Timeout(Tiempode esperadel solicitante versión 1): tiempode esperadel

solicitante correspondiente a la versión 1 anteriordeIGMP expresado en segundos. El intervalod
solicitantede la versión anterior es el tiempode espera para que el host vuelva al modoIGMPv3
cuando se recibe una consultade una versión anterior. Cuando se recibe una consultade una
versión anterior, los hosts establecen el temporizador actualdel solicitantede la versión anterior
en el intervalodel solicitantede la versión anterior.

Version 2 Querier Timeout(Tiempode esperadel solicitante versión 2): tiempode esperadel

solicitante correspondiente a la versión 1 anteriordeIGMP expresado en segundos.

Proxy Start Frequency(Frecuenciade iniciode proxy): númerode veces que se ha activado el pro

Proxy Interface Statistics(Estadísticasde la interfazde proxy): consultas recibidas, informes

recibidos y enviados, y ceses recibidos y enviados.

Visualizaciónde las configuracionesde la interfazde proxyIGMP mediante el comandode la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

Comandosdel proxyIGMP

Informaciónde pertenencia a la interfazde proxyIGMP

Utilice la página IGMP Proxy Interface Membership Info (Informaciónde pertenencia a la interfaz
proxyIGMP) para ver los datosde pertenencia a una interfaz correspondientes a una direcciónde
grupode multidifusión IP específica.Debe haber configurado como mínimo una interfazde
enrutador para poder ver la informaciónde pertenencia a interfaz y nodebe ser una interfazde
enrutamientoIGMP. Asimismo, si no se han recibido informesde pertenencia a grupo en la interf
seleccionada, no se mostrarán datos en esta página.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® IGMP® Proxy
Interface(Interfazde proxy)® Interface Membership Info (Informaciónde pertenencia a interfaz)
la vistade árbol.

Ilustración 13-14. Informaciónde pertenencia a la interfazde proxyIGMP

La página IGMP Proxy Interface Membership Info(Informaciónde pertenencia a la interfazde
proxyIGMP) contiene los campos siguientes:

Interface(Interfaz): muestra la interfaz en la que está activado el proxyIGMP.

Multicast Group IP(IPde grupode multidifusión): seleccione la direccióndel grupode multidifusión

cuyos datosdesea visualizar. Si no se han recibido informesde pertenencia a grupo en la interfa
seleccionada, no puede realizar esta selección y no se muestra ningunode los datos siguientes.

Last Reporter(Último informador): dirección IPdel origendel último informede pertenencia recibi
para la direccióndel grupode multidifusión IP en la interfazde proxyIGMP.

Up Time (secs)(Tiempode actividad [seg.]): tiempo transcurridodesde la creaciónde esta entrad

State(Estado): estadode la entradade host. Un host puede tener unode los estados que se indic
a continuación. Non-member state (Estado no miembro): no pertenece al grupode la
interfaz.Delaying member state (Estado miembro condemora): el host pertenece al grupode la
interfaz y se ejecuta el temporizadorde informes. El temporizadorde informes se utiliza para
enviar los informes. Idle member state (Estado miembro inactivo): el host pertenece al grupode
interfaz y no se ejecuta el temporizadorde informes.

Number of Sources(Númerode orígenes): númerode hostsde origen presentes en el grupode

multidifusión seleccionado.

Visualizaciónde informaciónde pertenencia a la interfazde proxyIGMP mediante el comandode la

CLI
Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosdel proxyIGMP

Informacióndetalladade pertenencia a la interfazde proxyIGMP

Utilice la página IGMP Proxy Interface Membership InfoDetailed (Informacióndetalladade

pertenencia a la interfazde proxyIGMP) para ver informacióndetallada sobre la pertenencia a un
interfaz.Debe haber configurado como mínimo una interfazde enrutador para poder ver la
informacióndetalladade pertenencia a interfaz y nodebe ser una interfazde enrutamientoIGMP.
Asimismo, si no se han recibido informesde pertenencia a grupo en la interfaz seleccionada, no
puede ver los datos.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® IGMP® Proxy
Interface(Interfazde proxy)® Interface Membership InfoDetailed (Informacióndetalladade
pertenencia a interfaz) en la vistade árbol.

Ilustración 13-15. Informacióndetalladade pertenencia a la interfazde proxyIGMP

La página IGMP Proxy Interface Membership InfoDetailed(Informacióndetalladade pertenencia a

interfazde proxyIGMP) contiene los campos siguientes:

Interface (Interfaz): seleccione la interfaz cuyos datos se van a mostrar.

Multicast Group IP(IPde grupode multidifusión): seleccione la direccióndel grupode multidifusión

cuyos datosdesea visualizar. Si no se han recibido informesde pertenencia a grupo en la interfa
seleccionada, no puede realizar esta selección y no se muestran los datos que no pueden
configurarse.

Source IP(IPde origen): muestra las direccionesde origen que son miembrosde esta direcciónde
multidifusión.

Last Reporter(Último informador): dirección IPdel origendel último informede pertenencia recibi
para la direccióndel grupode multidifusión IP en la interfaz seleccionada.

Up Time (secs)(Tiempode actividad [seg.]): muestra el tiempode actividaddesde que se creó la

entrada en la tablade caché.

State(Estado): estadode la entradade host. Un host puede tener unode los estados siguientes:

Non-member State(Estado no miembro): el host no pertenece al grupode la interfaz.

Delaying Member State(Estado miembro condemora): el host pertenece al grupode la interfaz y

se ejecuta el temporizadorde informes. El temporizadorde informes se utiliza para enviar los
informes.

Idle Member State(Estado miembro inactivo): el host pertenece al grupode la interfaz y no se

ejecuta el temporizadorde informes.

Filter Mode(Modode filtrado): modode filtradode grupo (con los valores Include [Incluir], Exclude
[Excluir] y None [Ninguno]) correspondiente al grupo especificado en la interfazde proxyIGMP.

Visualizaciónde informacióndetalladade pertenencia a la interfazde proxyIGMP

Abra la página IGMP Proxy Interface Membership InfoDetailed (Informacióndetalladade

pertenencia a la interfazde proxyIGMP).

Seleccione la interfaz quedesea visualizar en el menúdesplegable Interface (Interfaz).

Seleccione la IP quedesea en Multicast Group IP(IPde grupode multidifusión).

Se muestran datosdetalladosde pertenencia correspondientes a esta interfaz y la IPdel grupode

multidifusión.

Visualizaciónde informacióndetalladade pertenencia a la interfazde proxyIGMP mediante el

comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosdel proxyIGMP

Multidifusión

La páginade menú Multicast(Multidifusión) contiene enlaces a páginas web que permitendefinir

visualizar los parámetros y datosde multidifusión. Para visualizar esta página, haga clic en IP
Multicast (Multidifusión IP)® Multicast (Multidifusión) en la vistade árbol. A continuación figuran
las páginas web a las que se puede accederdesde esta páginade menú:

Configuración globalde multidifusión

Configuraciónde la interfazde multidifusión

Resumende rutasde multidifusión

Configuraciónde rutas estáticasde multidifusión

Resumende rutas estáticasde multidifusión

Configuracióndel límitede administraciónde multidifusión

Resumende los límitesde administraciónde multidifusión

Configuración globalde multidifusión

Utilice la página Multicast Global Configuration (Configuración globalde multidifusión) para

configurar el estadode administracióndel reenvíode multidifusión en el enrutador, así como para
ver los parámetros globalesde multidifusión.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Global Configuration(Configuración global) en la vistade árbol.

Ilustración 13-16. Configuración globalde multidifusión

La página Multicast Global Configuration(Configuración globalde multidifusión) contiene los
campos siguientes:

Admin Mode(Modode administración): seleccione Enable (Activar) o Disable (Desactivar)

paradefinir el estadode administracióndel reenvíode multidifusión en el enrutador. El valor
predeterminado es Disable (Desactivar).

Protocol State(Estadodelprotocolo): estado operativodel módulode reenvíode multidifusión.

Table Maximum Entry Count(Recuento máximode entradasde la tabla): número máximode

entradas que puede haber en la tablade enrutamientode multidifusión IP.

Number Of Packets For Which Source Not Found(Númerode paquetes cuyo origen no se ha
encontrado): númerode paquetesde multidifusión quedebían direccionarse pero que no han
superado la comprobación RPF.

Number Of Packets For Which Group Not Found(Númerode paquetes cuyo grupo no se ha
encontrado): númerode paquetesde multidifusión quedebían direccionarse pero cuya rutade
multidifusión no se ha encontrado.

Protocol (Protocolo): protocolo de enrutamiento de multidifusión activado actualmente en el

enrutador, si hay alguno.

Table Entry Count(Recuentode entradasde la tabla): númerode entradasde rutasde multidifusió

presentes actualmente en la tablade rutasde multidifusión.

Table Highest Entry Count(Recuento más altode entradasde la tabla): número más altode
entradasde rutasde multidifusión que ha habido en la tablade rutasde multidifusión.

Configuracióndel modode administracióndel reenvíode multidifusión

Abra la página Multicast Global Configuration(Configuración globalde multidifusión).

Seleccione Enable (Activar) o Disable (Desactivar) en Admin Mode(Modode administración).

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la configuración globalde multidifusión y se actualiza el dispositivo.

Configuración y visualizaciónde los parámetrosde reenvíode multidifusión mediante los

comandosde la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

Comandosde multidifusión

Configuraciónde la interfazde multidifusión

Utilice la página Multicast Interface Configuration (Configuraciónde la interfazde multidifusión)

para configurar el umbral TTLde una interfazde multidifusión.Debe configurar como mínimo una
interfazde enrutador para que los campos aparezcan en esta página.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Interface Configuration(Configuraciónde interfaz) en la vistade árbol.

Ilustración 13-17. Configuraciónde la interfazde multidifusión

La página Multicast Interface Configuration(Configuraciónde la interfazde multidifusión) contien
los campos siguientes:

Interface(Interfaz): seleccione en el menúdesplegable la interfazde enrutamiento quedesea

configurar.

TTL Threshold(Umbral TTL): introduzca el umbral TTL pordebajodel cual no se reenviará un

paquetede datosde multidifusióndesde la interfaz seleccionada. Introduzca un número entre 0 y
255. Si introduce 0, se reenvían todos los paquetesde multidifusiónde la interfaz
seleccionada.Debe configurar como mínimo una interfazde enrutador para poder ver este camp

Configuraciónde una interfazde multidifusión

Abra la página Multicast Interface Configuration(Configuraciónde la interfazde multidifusión).

Seleccione la interfaz quedesea configurar en el menúdesplegable Interface (Interfaz).

Introduzca el umbral TTL quedesea en TTL Threshold (Umbral TTL).

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la configuraciónde la interfazde multidifusión y se actualiza el dispositivo.

Configuraciónde una interfazde multidifusión mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:
Comandosde multidifusión

Resumende rutasde multidifusión

Utilice la página Multicast MRoute Summary (Resumende rutasde multidifusión) para ver
información sobre las rutasde multidifusión.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
MRoute Summary(Resumende rutasde multidifusión) en la vistade árbol.

Ilustración 13-18. Resumende rutasde multidifusión

La página Multicast MRoute Summary(Resumende rutasde multidifusión) contiene los campos

siguientes:

Source IP(IPde origen): dirección IPdel origendel paquetede multidifusión que, junto con la IPde
grupo, identifica una entradade la tablade rutasde multidifusión.

Group IP(IPde grupo): dirección IPdel grupode destino.

Incoming Interface(Interfazde entrada): interfazde entrada en la que llegan los paquetesde

multidifusiónde este origen o grupo.

Outgoing Interfaces(Interfacesde salida): listade interfacesde salida en las que se reenvían los
paquetesde multidifusiónde este origen o grupo.

Up Time (secs)(Tiempode actividad [seg.]): tiempo, expresado en segundos, que ha

transcurridodesde la creaciónde la entrada.

Expiry Time (secs)(Tiempode caducidad [seg.]): tiempo, expresado en segundos, que falta para
que esta entrada caduque y se eliminede la tabla.

RPF Neighbor(Vecino RPF): dirección IPdel vecinode reenvíode ruta inversa.

Protocol (Protocolo): protocolo de enrutamiento de multidifusión que ha creado esta entrada. A

continuación se indican los posibles protocolos:

PIM-DM

PIM-SM

DVMRP

Flags(Indicadores): el valor que se muestra en este campo es válido si elprotocolo de

enrutamientode multidifusión que se ejecuta es PIM-SM. Los valores posibles son RPT o SPT. Par
el restodeprotocolos se muestra "------".

Visualizacióndel resumende rutasde multidifusión mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde multidifusión

Configuraciónde rutas estáticasde multidifusión

Utilice la página Multicast Static Routes Configuration (Configuraciónde rutas estáticasde

multidifusión) para configurar una entrada estática nueva en la tablade rutasde multidifusión o
para modificar una existente.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Static Routes Configuration (Configuraciónde rutas estáticas) en la vistade árbol.

Ilustración 13-19. Configuraciónde rutas estáticasde multidifusión

La página Multicast Static Routes Configuration(Configuraciónde rutas estáticasde multidifusión
contiene los campos siguientes:

Source (Origen): seleccione Create Static Route(Crear ruta estática) para configurar una entrad
estática nueva en la tablade rutasde multidifusión o bien seleccione unade las entradas
existentes en el menúdesplegable.

Source IP(IPde origen): introduzca la dirección IP que identifica el origendel paquetede

multidifusión para la entrada que está creando.

Source Mask(Máscarade origen): introduzca la máscarade subred que se aplicará a la dirección

IPde origen.

RPF Neighbor(Vecino RPF): introduzca la dirección IPdel enrutador vecino en la rutade acceso al
origen.

Metric(Métrica): introduzca el costede estadodel enlace correspondiente a la rutade acceso al

origende multidifusión. El intervalo es 0-255, y el valor predeterminado es 1. Puede cambiar la
métricade una ruta configurada; para ello, seleccione la ruta estática y edite este campo.

Interface(Interfaz): seleccione en el menúdesplegable el númerode la interfaz. Se tratade la

interfaz que se conecta al enrutador vecino para la dirección IPde origen especificada.

Configuraciónde una ruta estática

Abra la página Static Routes (Rutas estáticas).

Seleccione Create Static Route (Crear ruta estática) en el campo Source(Origen) para configura
una entrada estática nueva o bien seleccione unade las entradas existentes.

Modifique los campos restantes según sea necesario.

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la ruta estática que se ha creado o modificado y se actualiza el dispositivo.

Configuraciónde una ruta estática mediante los comandosde la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

Comandosde multidifusión

Resumende rutas estáticasde multidifusión

Utilice la página Multicast Static Routes Summary(Resumende rutas estáticasde multidifusión)

para ver las rutas estáticas y sus configuraciones.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Static Routes Summary (Resumende rutas estáticas) en la vistade árbol.

Ilustración 13-20. Resumende rutas estáticasde multidifusión

La página Multicast Static Routes Summary(Resumende rutas estáticasde multidifusión) contien

los campos siguientes:

Source IP(IPde origen): dirección IP que identifica el origendel paquetede multidifusión para esta
ruta.

Source Mask(Máscarade origen): máscarade subred que se aplica a la dirección IPde origen.

RPF Address(Dirección RPF): dirección IPdel vecino RPF.

Metric(Métrica): costede estadodel enlace correspondiente a la rutade acceso al origende

multidifusión. El intervalo es 0-255.

VLANID(IDde VLAN): númerode la VLANde entrada cuya dirección IP se utiliza como RPF para la
dirección IPde origen especificada.

Visualizacióndel resumende rutas estáticas mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde multidifusión

Configuracióndel límitede administraciónde multidifusión

Un límitede ámbitode administración puede definirse como un modode detener la entrada y la

salidade tráficode multidifusión para undeterminado intervalode direccionesde multidifusión en
una interfazde enrutamiento específica. Utilice la página Multicast Admin Boundary Configuratio
(Configuracióndel límitede administraciónde multidifusión) para configurar un límitede ámbitod
administración nuevo o uno ya existente. Para ver esta página,debe haber configurado la
multidifusión y una interfazde enrutamiento válida.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Admin Boundary Configuration(Configuracióndel límitede administración) en la vistade árbol.

Ilustración 13-21. Configuracióndel límitede administraciónde multidifusión

La página Multicast Admin Boundary Configuration(Configuracióndel límitede administraciónde
multidifusión) contiene los campos siguientes:

Group (Grupo): seleccione Create Boundary(Crear límite) en el menúdesplegable para crear un

límitede ámbitode administración nuevo o bien seleccione unade las especificacionesde límite y
existentes para ver o actualizar su configuración.

Interface(Interfaz): seleccione la interfazde enrutador para la que va a configurarse el límitede

ámbitode administración.

Group IP(IPde grupo): introduzca la direccióndel grupode multidifusión para el iniciodel intervalo
direcciones que se van a excluir. La direccióndebe estar comprendida en el intervalode 239.0.0
a 239.255.255.255.

Group Mask(Máscarade grupo): introduzca la máscara que se aplicará a la direccióndel grupode

multidifusión. La combinaciónde la máscara y la IPde grupo proporciona el intervalode
direccionesde ámbitode administración para la interfaz seleccionada.

Configuraciónde un límitede administración

Abra la página Multicast Admin Boundary Configuration (Configuracióndel límitede

administraciónde multidifusión).

Seleccione Create Boundary (Crear límite) en el campo Group IP(IPde grupo) para configurar un
límitede ámbitode administración nuevo o bien seleccione unade las entradas existentes.
Modifique los campos restantes según sea necesario.

Haga clic en Apply Changes (Aplicar cambios).

Se guarda el límitede ámbitode administración que se ha creado o modificado y se actualiza el

dispositivo.

Configuraciónde un límitede administración mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde multidifusión

Resumende los límitesde administraciónde multidifusión

Utilice la página Multicast Admin Boundary Summary (Resumende los límitesde administraciónd
multidifusión) para ver los límitesde ámbitode administración existentes.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® Multicast (Multidifusión)®
Admin Boundary Summary(Resumende los límitesde administración) en la vistade árbol.

Ilustración 13-22. Resumende los límitesde administraciónde multidifusión

La página Multicast Admin Boundary Summary(Resumende los límitesde administraciónde

multidifusión) contiene los campos siguientes:

Interface(Interfaz): interfazde enrutador a la que se aplica el intervalode direccionesde ámbitod

administración.

Group IP(IPde grupo): direccióndel grupode multidifusión para el iniciodel intervalode direccione
que se van a excluir.

Group Mask(Máscarade grupo): máscara que se aplica a la direccióndel grupode multidifusión. L

combinaciónde la máscara y la IPde grupo proporciona el intervalode direccionesde ámbitode
administración para la interfaz seleccionada.

Visualizacióndel resumende los límitesde administraciónde multidifusión mediante el comandod

la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde multidifusión

PIM-DM

PIM-DM es un sencilloprotocolo de enrutamientode multidifusión independiente. Utiliza una

tablade enrutamientode difusión única existente y un mecanismode unión, poda e injerto para
crear un árbol. PIM-DM crea árbolesde distribuciónde la rutade acceso más corta basados en el
origen que utilizan RPF. No puede utilizarse para crear un árbolde distribución compartido, com
en el casode PIM-SM. PIM-DM asume que cuando el emisor inicia el envíode datos, todos los hos
y enrutadoresdescendentesdesean recibir un datagramade multidifusión. Inicialmente, distribuy
el tráficode multidifusión a travésde la red. Los enrutadores que no tienen vecinosdescendentes
vuelven a podar el tráfico nodeseado. Ademásde losmensajes de poda, PIM-DM utilizamensajes
injerto y aserción. Losmensajes de injerto se utilizan siempre que un nuevo hostdesee unirse al
grupo. Losmensajes de aserción se utilizan para cerrar los flujos duplicados en la misma redde
acceso múltiple.

PIM-DM tiene dos versiones. La versión 2 no utiliza el mensajeIGMP, sino un mensaje encapsula
en el paquete IP con el númerodeprotocolo 103. En esta versión, se introduce un mensajede
saludo en lugardel mensajede consulta.

PIM-DM es adecuado para:

Receptoresdensamente distribuidos

De pocos emisores a muchos receptores (debido a una distribución frecuente)

Volumen elevadode tráficode multidifusión

Flujo constantede tráfico

La páginade menú PIM-DMcontiene enlaces a páginas web que permitendefinir y visualizar los
parámetros y datosde PIM-DM.? Para visualizar esta página, haga clic en IP Multicast (Multidifus
IP)® PIM-DM en la vistade árbol.

A continuación figuran las páginas web a las que se puede accederdesde esta páginade menú:

Configuración globalde PIM-DM

Configuraciónde la interfaz PIM-DM

Resumende interfaces PIM-DM

Configuración globalde PIM-DM

Utilice la página PIM-DM Global Configuration (Configuración globalde PIM-DM) para configurar e
estadode administraciónde PIM-DM en este sistema.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® PIM-DM® Global
Configuration (Configuración global) en la vistade árbol.

Ilustración 13-23. Configuración globalde PIM-DM

La página PIM-DM Global Configuration(Configuración globalde PIM-DM) contiene el campo

siguiente:

Admin Mode(Modode administración): seleccione Enable (Activar) o Disable (Desactivar) en el

menúdesplegable paradefinir el estadode administraciónde PIM-DM en el sistema. El valor
predeterminado es Disable (Desactivar).
Configuraciónde PIM-DM

Abra la página PIM-DM Global Configuration (Configuración globalde PIM-DM).

Defina Admin Mode(Modode administración) como Enable (Activar) o Disable (Desactivar) para
activar odesactivar PIM-DM.

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la configuraciónde PIM-DM y se actualiza el dispositivo.

Configuraciónde PIM-DM mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde PIM-DM

Configuraciónde la interfaz PIM-DM

Utilice la página PIM-DM Interface Configuration (Configuraciónde la interfaz PIM-DM) para

configurar interfaces específicas con PIM-DM. PIM-DMdebe estar activado en la página PIM-DM
Global Configuration (Configuración globalde PIM-DM) para que se muestre esta páginade
configuraciónde la interfaz.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® PIM-DM® Interface
Configuration (Configuraciónde interfaz) en la vistade árbol.

Ilustración 13-24. Configuraciónde la interfaz PIM-DM

La página PIM-DM Interface Configuration(Configuraciónde la interfaz PIM-DM) contiene los
campos siguientes:

Interface(Interfaz): seleccione la interfaz cuyos datos se van a mostrar o configurar.Debe haber

configurado como mínimo una interfazde enrutador para poder configurar o mostrar datosde un
interfaz PIM-DM;de lo contrario, se muestra un mensajede error.

Interface Mode(Modode interfaz): seleccione Enable (Activar) o Disable (Desactivar) en el

menúdesplegable paradefinir el estadode administraciónde PIM-DM para la interfaz seleccionad
El valor predeterminado es Disable (Desactivar).

Hello Interval (secs)(Intervalode saludo [seg.]): introduzca el númerode segundos quedeben

transcurrir entre losmensajes de saludode PIM transmitidosdesde la interfaz seleccionada. El va
predeterminado es 30. Los valores válidos están comprendidos entre 10 y 3600.

Configuraciónde PIM-DM para una interfaz

Abra la página PIM-DM Interface Configuration (Configuraciónde la interfaz PIM-DM).

Seleccione la interfaz que va a configurar en el campo Interface (Interfaz).

Modifique los campos restantes según sea necesario.

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la configuraciónde la interfaz y se actualiza el dispositivo.

Configuraciónde PIM-DM para una interfaz mediante el comandode la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

Comandosde PIM-DM

Resumende interfaces PIM-DM

Utilice la página PIM-DM Interface Summary (Resumende interfaces PIM-DM) para mostrar una
interfaz PIM-DM y su configuración. Como mínimodebe haber una interfaz configurada como PIM
DM en este enrutador para que se muestre la página.

Para visualizar la página, haga clic en IP Multicast (Multidifusión IP)® PIM-DM® Interface
Summary (Resumende interfaces) en la vistade árbol.

Ilustración 13-25. Resumende interfaces PIM-DM

La página PIM-DM Interface Summary(Resumende interfaces PIM-DM) contiene los campos

siguientes:

Interface(Interfaz): seleccione la interfaz cuyos datos se van a mostrar.Debe haber como mínim
una interfazde enrutador configurada para poder mostrar datosde una interfaz PIM-DM;de lo
contrario, se muestra un mensajede error.

Parámetrosde interfaz

Interface Mode(Modode interfaz): muestra el estadode administraciónde PIM-DM para la interfaz

seleccionada. El valor predeterminado es Disable (Desactivar).

Protocol State(Estadodelprotocolo): estado operativodelprotocolo PIM-DM en esta interfaz.

Hello Interval (secs)(Intervalode saludo [seg.]): frecuencia con la que se transmiten losmensaje
de saludode PIM en la interfaz seleccionada.

IP Address(Dirección IP): dirección IPde la interfaz seleccionada.

Estadísticasde la interfaz

Neighbor Count(Recuentode vecinos): númerode vecinos PIM en la interfaz seleccionada.

Designated Router(Enrutadordesignado): enrutadordesignado en la interfaz PIM seleccionada. E

las interfaces punto a punto, es 0.0.0.0.

Vecinosde la interfaz

Neighbor IP(IPde vecino): dirección IPdel vecino PIM sobre el que esta entrada contiene
información.

Up Time (hh:mm:ss)(Tiempode actividad [hh:mm:ss]): tiempo transcurridodesde que este vecin

PIM fue (por última vez) vecinodel enrutador local.

Expiry Time (hh:mm:ss)(Tiempode caducidad [hh:mm:ss]): tiempo mínimo restante antesde que
caduque este vecino PIM.

Visualizacióndel resumende interfaces PIM-DM mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde PIM-DM

PIM-SM

PIM-SM se utiliza para direccionarde manera eficaz el tráficode multidifusión a gruposde

multidifusión que pueden abarcar redesde área amplia y en casos en que la amplitudde banda
una limitación. Utiliza árboles compartidosde manera predeterminada e implementa árboles
basados en el origen para obtener mayor eficacia. Esta velocidadde umbralde datos se utiliza
para alternar entre árboles. PIM-SM asume que no hay hosts quedeseen el tráficode multidifusió
a menos que lo soliciten específicamente. Crea un árbolde distribución compartido centrado en
puntode encuentro (RP)definidodesde el que el tráficode origen se transmite a los receptores. L
emisores envían primero los datosde multidifusión al RP que, a su vez, envía los datos a los
receptores en direccióndescendente por el árbol compartido. Los árboles compartidos centrado
en un RP no proporcionan necesariamente la rutade acceso más corta u óptima. En estos casos
PIM-SM proporciona un medio para cambiar a árboles específicosdel origen más eficaces.
La páginade menú PIM-SMcontiene enlaces a páginas web que permitendefinir y visualizar los
parámetros y datosde PIM-SM. Para visualizar esta página, haga clic en IP Multicast (Multidifusió
IP)® PIM-SM en la vistade árbol.

A continuación figuran las páginas web a las que se puede accederdesde esta páginade menú:

Configuración globalde PIM-SM

Estado globalde PIM-SM

Configuraciónde la interfaz PIM-SM

Resumende interfaces PIM-SM

Resumende componentes

Resumende conjuntosde RP

Resumende RP candidatos

Configuraciónde RP estático

Configuración globalde PIM-SM

Utilice la página PIM-SM Global Configuration (Configuración globalde PIM-SM) para configurar lo
valores globalesde PIM-SM para este sistema.

Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Global Configuration
(Configuración global) en la vistade árbol.

Ilustración 13-26. Configuración globalde PIM-SM

La página PIM-SM Global Configuration(Configuración globalde PIM-SM) contiene los campos
siguientes:

Admin Mode(Modode administración): seleccione Enable (Activar) o Disable (Desactivar) en el

menúdesplegable paradefinir el estadode administraciónde PIM-SM en el sistema.Debe
activarIGMP antesde activar PIM-SM. El valor predeterminado es Disable (Desactivar).

Join/Prune Interval (secs)(Intervalode unión/poda [seg.]): introduzca el intervalo entre la

transmisióndemensajes de unión y podade PIM-SM. Los valores válidos están comprendidos ent
10 y 3600 segundos. El valor predeterminado es 60.

Data Threshold Rate (Kbps)(Velocidadde umbralde datos [Kbps]): introduzca la velocidad

mínimade datosde origen en kilobits/segundo por encimade la cual el enrutadorde último salto
cambia a un árbolde rutade acceso más corta específicodel origen. Los valores válidos están
comprendidos entre 0 y 2000 kilobits/segundo. El valor predeterminado es 50.

Register Threshold Rate (Kbps)(Velocidadde umbralde registro [Kbps]): introduzca la velocidad

mínimade datosde origen en kilobits/segundo por encimade la cual el enrutadorde puntode
encuentro cambia a un árbolde rutade acceso más corta específicodel origen. Los valores válido
están comprendidos entre 0 y 2000 kilobits/segundo. El valor predeterminado es 50.

Configuraciónde PIM-SM

Abra la página PIM-SM Global Configuration (Configuración globalde PIM-SM).

Defina Admin Mode(Modode administración) como Enable (Activar) o Disable (Desactivar) para
activar odesactivar PIM-SM.

Modifique los campos restantes según sea necesario.

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la configuraciónde la interfaz y se actualiza el dispositivo.

Configuraciónde PIM-SM mediante el comandode la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

Comandosde PIM-SM

Estado globalde PIM-SM

Utilice la página PIM-SM Global Status (Estado globalde PIM-SM) para ver los valores globales
seleccionados en la página PIM-SM Global Configuration(Configuración globalde PIM-SM).

Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Global Status (Estado
global) en la vistade árbol.

Ilustración 13-27. Estado globalde PIM-SM

La página PIM-SM Global Status(Estado globalde PIM-SM) contiene los campos siguientes:

Admin Mode(Modode administración): estadode administraciónde PIM-SM en el enrutador con lo

valores Enable (Activar) o Disable (Desactivar).

Join/Prune Interval (secs)(Intervalode unión/poda [seg.]): intervalo entre la transmisióndemensa

de unión y podade PIM-SM.

Data Threshold Rate (Kbps)(Velocidadde umbralde datos [Kbps]): velocidad mínimade datosde
origen en kilobits/segundo por encimade la cual el enrutadorde último salto cambia a un árbold
rutade acceso más corta específicodel origen.

Register Threshold Rate (Kbps)(Velocidadde umbralde registro [Kbps]): velocidad mínimade

datosde origen en kilobits/segundo por encimade la cual el enrutadorde puntode encuentro
cambia a un árbolde rutade acceso más corta específicodel origen.

Visualizacióndel estado globalde PIM-SM mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde PIM-SM

Configuraciónde la interfaz PIM-SM

Utilice la página PIM-SM Interface Configuration (Configuraciónde la interfaz PIM-SM) para

configurar PIM-SM para una interfaz. PIM-SMdebe estar activado en la página PIM-SM Global
Configuration (Configuración globalde PIM-SM) para que se muestre esta páginade
configuraciónde la interfaz.

Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Interface Configuratio
(Configuraciónde interfaz) en la vistade árbol.

Ilustración 13-28. Configuraciónde la interfaz PIM-SM

La página PIM-SM Interface Configuration(Configuraciónde la interfaz PIM-SM) contiene los camp
siguientes:

Interface(Interfaz): seleccione la interfaz cuyos datos se van a mostrar o configurar. Como

mínimo,debe haber una interfazde enrutamiento para mostrar o configurar los datos.

Mode(Modo): seleccione Enable (Activar) o Disable (Desactivar) en el menúdesplegable

paradefinir el estadode administraciónde PIM-SM en esta interfaz. El valor predeterminado es
Disable (Desactivar).

Hello Interval (secs)(Intervalode saludo [seg.]): introduzca el tiempo en segundos entre la

transmisióndemensajes de saludode PIM en esta interfaz. Los valores válidos están comprendid
entre 10 y 3600 segundos. El valor predeterminado es 30.

CBSR Preference(Preferencia CBSR): introduzca el valorde preferencia para la interfaz local com
enrutadorde inicio automático candidato. El valor –1 se utiliza para indicar que la interfaz local n
es una interfaz BSR candidata. Los valores válidos están comprendidos entre -1 y 255. El valor
predeterminado es 0.

CBSR Hash Mask Length(Longitudde la máscara hash CBSR): introduzca la longitudde la máscar
hash CBSR que se anunciará en losmensajes de inicio automático si esta interfaz se elige como
enrutadorde inicio automático. Esta longitudde máscara hash se utiliza en el algoritmo hash par
seleccionar el RPde un grupodeterminado. Los valores válidos están comprendidos entre 0 y 32
El valor predeterminado es 30.

CRP Preference(Preferencia CRP): introduzca el valorde preferencia para la interfaz local como
enrutadorde inicio automático candidato. El valor –1 se utiliza para indicar que la interfaz local n
es una interfaz BSR candidata. Los valores válidos están comprendidos entre -1 y 255. El valor
predeterminado es 0.

Configuraciónde PIM-SM para una interfaz

Abra la página PIM-SM Interface Configuration (Configuraciónde la interfaz PIM-SM).

Seleccione la interfaz que va a configurar en el campo Interface (Interfaz).

Seleccione Enable (Activar) en el campo Mode (Modo).

Modifique los campos restantes según sea necesario.

Haga clic en Apply Changes (Aplicar cambios).

Se guarda la configuraciónde la interfaz y se actualiza el dispositivo.

Configuraciónde PIM-SM para una interfaz mediante los comandosde la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:

Comandosde PIM-SM

Resumende interfaces PIM-SM

Utilice la página PIM-SM Interface Summary (Resumende interfaces PIM-SM) para mostrar una
interfaz PIM-SM y su configuración. Como mínimodebe haber una interfaz configurada como PIM
SM en este enrutador para que se muestre la página.

Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Interface Summary
(Resumende interfaces) en la vistade árbol.

Ilustración 13-29. Resumende interfaces PIM-SM

La página PIM-SM Interface Summary(Resumende interfaces PIM-SM) contiene los campos
siguientes:

Interface (Interfaz): seleccione la interfaz cuyos datos se van a mostrar.

Mode(Modo): estadode administraciónde PIM-SM en el enrutador con los valores Enable (Activar
Disable (Desactivar).

Protocol State(Estadodelprotocolo): estado operativodelprotocolo PIM-SM en la interfaz

seleccionada, con los valores Operational (Operativo) o Non-operational (No operativo).

IP Address(Dirección IP): dirección IPde la interfaz PIM seleccionada.

Net Mask(Máscarade red): máscarade red correspondiente a la dirección IPde la interfaz PIM
seleccionada.

Designated Router(Enrutadordesignado): enrutadordesignado en la interfaz PIM seleccionada. E

las interfaces punto a punto, este objeto tiene el valor 0.0.0.0.

Hello Interval (secs)(Intervalode saludo [seg.]): frecuencia con la que se transmiten losmensaje
de saludode PIM en la interfaz seleccionada.

CBSR Preference(Preferencia CBSR): valorde preferencia para la interfaz local como enrutadord
inicio automático candidato. El valor –1 se utiliza para indicar que la interfaz local no es una
interfaz BSR candidata.

CBSR Hash Mask Length(Longitudde la máscara hash CBSR): longitudde la máscara hash CBSR
que se anunciará en losmensajes de inicio automático si esta interfaz se elige como enrutadord
inicio automático. Esta longitudde máscara hash se utiliza en el algoritmo hash para selecciona
RPde un grupodeterminado.

CRP Preference(Preferencia CRP): valorde preferencia para la interfaz local como enrutadorde
inicio automático candidato. El valor –1 se utiliza para indicar que la interfaz local no es una
interfaz BSR candidata.

Neighbor Count(Recuentode vecinos): númerode vecinos PIM en la interfaz seleccionada.

IP Address(Dirección IP): dirección IPdel vecino PIM para esta entrada.

Up Time (hh:mm:ss)(Tiempode actividad [hh:mm:ss]): tiempo transcurridodesde que este vecin

PIM fue (por última vez) vecinodel enrutador local.

Expiry Time (hh:mm:ss)(Tiempode caducidad [hh:mm:ss]): tiempo mínimo restante antesde que
caduque este vecino PIM.

Visualizacióndel resumende interfaces PIM-SM

Abra la página PIM-SM Interface Summary (Resumende interfaces PIM-SM).

Seleccione la interfaz quedesea visualizar en el menúdesplegable Interface (Interfaz).

Se muestran los datosde configuraciónde PIM-SM para esta interfaz.

Visualizacióndel resumende interfaces PIM-SM mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde PIM-SM

Resumende componentes

Utilice la página Component Summary (Resumende componentes) para ver información sobre l
componentes PIM-SM.

Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Component Summary
(Resumende componentes) en la vistade árbol.

Ilustración 13-30. Resumende componentes

La página Component Summary(Resumende componentes) contiene los campos siguientes:

Component Index(Índicede componentes): número exclusivo que identifica el índicede

componentes.

Component BSR Address(Dirección BSRdel componente): dirección IPdel enrutadorde inicio

automático (BSR) para la región PIM local.

Component BSR Expiry Time (hh:mm:ss)(Tiempode caducidad BSRdel componente [hh:mm:ss])

tiempo mínimo restante antesde que sedeclare el enrutadorde inicio automático en el dominio
local.

Component CRP Hold Time (hh:mm:ss)(Tiempode espera CRPdel componente [hh:mm:ss]):

tiempode esperadel componente cuando es un puntode encuentro candidato en el dominio loca

Visualizacióndel resumende componentes PIM-SM mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde PIM-SM

Resumende conjuntosde RP

Utilice la página PIM-SM RP Set Summary (Resumende conjuntosde RPde PIM-SM) para ver
información sobre el RP estático correspondiente al enrutador PIM-SM.
Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® RP Set Summary
(Resumende conjuntosde RP) en la vistade árbol.

Ilustración 13-31. Resumende conjuntosde RPde PIM-SM

En la página PIM-SM RP Set Summary(Resumende conjuntosde RPde PIM-SM) se muestran los

campos siguientes en una tabla:

Group Address(Direcciónde grupo): muestra la direccióndel grupode multidifusión IP.

Group Mask(Máscarade grupo): muestra la máscarade direccióndel grupode multidifusión.

Address(Dirección): muestra la dirección IPdel RP candidato.

Hold Time (hh:mm:ss)(Tiempode espera [hh:mm:ss]): tiempode esperade un RP candidato. Si e

enrutador local no es el BSR, este valor es 0.

Expiry Time (hh:mm:ss)(Tiempode caducidad [hh:mm:ss]): tiempo mínimo restante antesde que
sedeclare el RP candidato como fuerade servicio.

Component(Componente): número que identifica el componentede manera exclusiva. Cada

instanciadelprotocolo conectada a un dominio distintodebe tener un valorde índice diferente.

Visualizacióndel resumende conjuntosde RP mediante los comandosde la CLI

Para obtener información sobre los comandosde la CLI que realizan esta función, consulte el
capítulo siguientede la Guíade referenciade la CLI:
Comandosde PIM-SM

Resumende RP candidatos

Utilice la página PIM-SM Candidate RP Summary (Resumende RP candidatosde PIM-SM) para ve

información sobre PIM correspondiente a los puntosde encuentro (RP) candidatos para cada
grupode multidifusión IP.

Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Candidate RP Summa
(Resumende RP candidatos) en la vistade árbol.

Ilustración 13-32. Resumende RP candidatosde PIM-SM

En la página PIM-SM Candidate RP Summary(Resumende RP candidatosde PIM-SM) se muestran

los campos siguientes en una tabla:

Group Address(Direcciónde grupo): direccióndel grupo transmitida en anunciosde RP candidato

Group Mask(Máscarade grupo): máscarade direccióndel grupo transmitida en anunciosde RP

candidatos para identificar completamente el ámbitodel grupo que admite el enrutador si se ha
elegido como puntode encuentro.

Address(Dirección): muestra la direcciónde difusión únicade la interfaz que se anuncia como RP

candidato.

Visualizacióndel resumende RP candidatosde PIM-SM mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde PIM-SM

Configuraciónde RP estático

Utilice la página Static RP Configuration (Configuraciónde RP estático) para crear la dirección IP

RP estático especificado correspondiente al enrutador PIM-SM.

Para visualizar la página, haga clic en Multicast (Multidifusión)® PIM-SM® Static RP Configuratio
(Configuraciónde RP estático) en la vistade árbol.

Ilustración 13-33. Configuraciónde RP estático

La página Static RP Configuration(Configuraciónde RP estático) contiene los campos siguientes:

IP Address(Dirección IP): dirección IPdel RP que va a crearse.

Group(Grupo): direcciónde grupodel RP que va a crearse.

Group Mask(Máscarade grupo): máscara IPde grupodel RP que va a crearse.

Las configuraciones existentes se muestran en una tabla en la parte inferiorde la página.

Configuraciónde un RP estático
Abra la página Static RP Configuration (Configuraciónde RP estático).

Introduzca la dirección IP, la dirección IPdel grupoy la máscarade grupopara la configuracióndel

RP estático.

Haga clic en Apply Changes (Aplicar cambios).

Se crea la dirección IPdel RP estático especificado para el enrutador PIM-SM y se actualiza el

dispositivo.

Configuraciónde un RP estático mediante el comandode la CLI

Para obtener información sobre el comandode la CLI que realiza esta función, consulte el capítu
siguientede la Guíade referenciade la CLI:

Comandosde PIM-SM

Regresar a la páginade contenido

Support Home Page

Shop Support Community

Solutions Home Users Join the Discussion

Services Small Businesses Share Your Ideas

Systems Enterprise IT Read our Blog

Software & Peripherals Ratings & Reviews

Community Home
Large Text

snWEB4