7 – Multicast

7.1 – Explaining Multicast

7.1.1 – Explaining the multicast Group conecept

Multicast se usa para mandar el mismo paquete a múltiples receptores. Un servidor

multimedia envía una copia de cada paquete a una ip destino que puede ser
recibida por muchos hosts si deciden escuchar esa dirección.
Los paquetes no se duplican para cada receptor pero se mandan en una sola
emisión. Los routers utilizan menos recursos ya que solo reciben una copia de cada
paquete.
Como los routers de descarga realizan la multiplicación de paquetes y reenvían a
los receptores, la fuente de la información no necesita saber las direcciones unicast
a las que se envía la información.

7.1.2 – Unicast versus Multicast

Las emisiones unicast envían múltiples copias, una para cada destino.
La transmisión multicast envía una única copia de datos a múltiples receptores. La
información se envía a los receptores multicast porque están previamente inscritos
para recibirla.

7.1.3 – Multicast Advantages and Disadvantages

Ventajas:
• Eficiencia mejoradael ancho de banda se utiliza más eficientemente
porque las emisiones múltiples de datos son reemplazadas con una única
transmisión.
• Rendimiento optimizadomenos copias de datos tienen que ser procesados.
• Aplicaciones distribuidaslas aplicaciones multipunto no serán posibles con
transmisiones multicast a medida que la red crece, ya que unicast no es
escalable.
• Para la misma cantidad de tráfico, el que envía usa menos potencia de envío
y ancho de banda.

Desventajas:

• Best-effort ocasionalmente provoca perdidas de paquetes. Las aplicaciones

en tiempo real se ven afectadas por las pérdidas de paquetes. Se debe
realizar retransmisiones, lo cual no es aceptable para las aplicaciones en
tiempo real.
o Grandes perdidas provocan saltos en la conversación.
o Las pérdidas en video provocan congelación de la imagen si son
grandes o pueden llegar a no verse.
• La falta de control de congestión puede degradar la red.
• Pueden aparecer paquetes duplicados a medida que la red cambia.
• UDP no tiene mecanismo de fiabilidad, por lo que los problemas de fiabilidad
deben confiarse en las aplicaciones multicast.

7.1.4 – Multicast Aplications

Tipos:

• Onte-To-Manyun host manda a uno o más receptores. Se suele utilizar

para aplicaciones de video, monitorización… Si la aplicación necesita
información de vuelta se converte en Many-to-Many.
• Many-to-Manycuando un host puede ser emisor y receptor. Recibir
información de diferentes fuentes aumenta la complejidad de las
aplicaciones.
 • Many-to-Onecuando varios emisores mandan información a un único
receptor. Aplicaciones financieras…

Aplicaciones:
• Tiempo realvideo conferencia, difusiones, entrega de datos bancarios…
• No tiempo realtransmisión de ficheros, replicación de datos…
7.1.5 – IP Multicast Addresses

Los router distinguen el tráfico multicast usando las direcciones reservadas de clase
D. Se fijan el los cuatro bits mas significativos, que son siempre 1110. Los
siguientes 28 bits se refieren al grupo de direcciones. Por lo tanto el rango de
direcciones multicast va de 224.0.0.0 a 239.255.255.255.
• Localy scopedreservadas por la IANA para usos de protocolos. 224.0.0.0 a
224.0.0.255. Los multicast de este rango no se propagan nunca fuera de la
red local, su TTL se establece a 1.

• Globally scopedAsignadas dinámicamente a todo Internet. 224.0.1.0 a

238.255.255.255.
o El rango 224.2.X.X se usa en las aplicaciones MBone. Se utilizan para
emisiones de video y/o audio.
• Limited scoped addressesreservadas para uso privado. 239.0.0.0 a
239.255.255.255. No se propagan a Internet.
Dentro de un AS o dominio, las Limited pueden subdividirse, definiéndose limites
multicast. Esta subdivisión se llama address scoping y permite reutilizar direcciones
dentro de pequeños dominios.

• Organization-local scope239.192.0.0 a 239.251.255.255

• Site-local scope239.255.0.0/16, 139.252.0.0/16, 239.253.0.0/16 y
239.254.0.0/16
7.1.6 – Layer 2 Multicast Addressing

El OUI de las direcciones MAC multicast es 0x01005e seguido de 0. El rango de

direcciones MAC multicast es 0100.5e00.0000 a 0100.5e7f.ffff.
Los primeros 25 bits de la MAC son fijos (24+ siguiente bit 0), y permite a los últimos 23 bits de
la MAC corresponderse con los últimos 23 bits de la ip multicast. La traducción entre IPMAC
se consigue mapeando los 23 bits de menor peso de la IP multicast en los 23 bits de menor
peso de la Mac.

Hay 28 bits de ips únicas en el espacio multicast (32 – los cuatro bits de 1110) y 23 bits
mapeados en la MAC. Por lo tanto quedan 5 (32 direcciones) bits sin mapear de las direcciones
IP a MAC.

El resultado es que 32 direcciones IP Multicast mapearán la misma dirección MAC.

Un usuario suscrito a un grupo X (224.1.1.1) y otro suscrito al grupo Y (225.1.1.1),
los dos recibirán las transmisiones X e Y en capa 2. En capa 3 sin embargo solo los
paquetes asociados a la IP del grupo multicast seleccionado serán vistos.
7.1.7 – Multicast Sessions

Cuando una aplicación multicast comienza en un recetor, la aplicación debe saber a

que grupo multicast unirse. Debe aprender las sesiones disponibles, que
normalmente mapean a una o más ips multicast.

Formas de aprender las sesiones:

• La aplicación se une a un grupo predefinido.
• La aplicación se comunica con un servidor de directorio.
• La aplicación es lanzada de una pagina web donde las sesiones están
anunciadas como URLs
• Un usuario configura la aplicación para escuchar una sesión multicast,
introduciendo manualmente la ip dentro de la aplicación.

La aplicación de directorio de sesión (sd) actúa como un guía y muestra el

contenido multicast. Una aplicación cliente funciona sobre un pc y permite al
usuario saber qué contenido está disponible. Este directorio usa SDP (session
description protocol) o SAP (session announcement protocol) para aprender el
contenido. SDP/SAP^

SDP
• Descripción de la sesión y su anuncio
• Transporte de los anuncios de sesión por grupos multicast bien conocidos
224.2.127.254
• Creación de nuevas sesiones

En la parte del receptor, SDR aprende las posibles sesiones o grupos. Si un usuario
selecciona una sesión se une a ella.
Cuando SDR se usa en la parte del emisor, crea nuevas sesiones y evita conflictos
de direcciones. Al crear una sesión consulta la caché SDR y eligen una dirección
multicast que no esté en uso. Cuando la sesión está creada, el emisor empieza a
anunciar la información necesaria para que los clientes se unan a la sesión.
RFC 3266 define el conjunto de variables que describen la sesión. El transporte no
está definido. Los paquetes que describen la sesión se transportan de diferentes
formas:
• SAPtransporta información de la sesión
• SIP(Session Initiation Protocol)protocolo de señalización para telefonía,
mensajería..
• RTSP(Real Time Streaming Protocol)protocolo de control en un entorno
multimedia.
• E-Mailen MIME (Multipurpose Internet Mail Extensions)
• Paginas web dan descripciones de sesión en formato estandarizado SDR
7.2 – IGMP and Layer 2 Issues
7.2.1 – Introducing IGMPv2

Sin control, los paquetes multicast son inundados como tramas unicast
desconocidas por un switch. IGMP snooping y Cisco Group Management Protocol
(CGMP) resuelven este problema.
IGMP es un protocolo host-to-router que se usa cuando los host quieren unirse a un
grupo multicast. Con la V1, los routers envían consultas de miembros periódicas a
la dirección 224.0.0.1. Los host las mandan al grupo al que se quieren unir. Los host
abandonan las sesiones silenciosamente.

V1-V2:
• Consultas específicas de grupo
• Mensajes de abandono de grupo
• Mecanismo de consulta de elección
• Tiempo de respuesta del intervalo de consulta

La consulta especifica de grupo se añade en V2 y permite al router consultar a los

miembros dentro de un grupo especifico en vez de a todos los grupos, que es una
mejor forma de encontrar cuando hay miembros que abandonan la sesión sin tener
que preguntar a todos los grupos. La de V1 se hace mandando una consulta a la
dirección multicast para todos los grupos 224.0.0.1 mientras que la de V2 se manda
únicamente al grupo específico.

El mensaje de abandono de grupo permite a los host decir al router que abandonan
el grupo. Esta información reduce la latencia de abandono en el segmento cuando
el miembro que está abandonando es el último miembro del grupo.

7.2.2 – IGMPv2 Join Group and Leave Group Messages

Los miembros que quieren unirse a un grupo multicast no tienen que mandar una
consulta para unirse. Mandan un informe no solicitado indicando su interés. Este
procedimiento reduce la latencia para el sistema final si no hay otros miembros
presentes.
Cuando hay mas de un router IGMP en el mismo segmento el router con la ip más
alta es el designated querier.
En V1, los hosts abandonan pasivamente el grupo. No indican explícitamente que
abandonan si no que dejan de responder a las consultas. V2 abandonan los grupos
manando un mensaje.
Cuando un router IGMPv2 recibe un mensaje de abandono, responde mandando una
consulta de grupo-específico para ver si quedan hosts interesados en seguir en el
grupo.

show ip igpmp Group

7.2.3 – Introducing IGMPv3

El principal propósito de V3, es permitir a los hosts indicar que quieren recibir
tráfico solo de fuentes en particular dentro de un grupo multicast. V3 añade la
habilidad de filtrar los multicasts basados en la fuente multicast.

Este aumento hace que la utilización de los recursos de routing sean más eficientes.

Los reports son mandados a 224.0.0.22

7.2.4 – IGMPv2 and IGMPv3 Interoperability

show ip igmp interface

Determina que versión de IGMP se está utilizando en la interfaz.

7.2.5 – Multicast in the Layer 2 Switching Enviroment

La mayor parte de los switches de capa 2 tratan al tráfico multicast como una MAC
desconocida o una trama broadcast que hace que se inunde a todas las interfaces
de esa VLAN.
Los Catalyst se pueden configurar para que se asocie una MAC multicast con varios
puertos.

7.2.6 – Multicast in Layer 2 Solutions

CGMPcorre entre un router y un switch. Habilita al router para informar al switch

acerca de la informaron contenida en los paquetes IGMP enviados a los host. Mejor
para equipos de gama baja.
IGMP Snoopingun switch debe examinar cada paquete multicast para determinar
si contiene alguna información de control IGMP y actualizar la MAC acorde a esa
información. Consume recursos. Para equipos con más prestaciones.

7.2.7 – Cisco Group Management Protocol (CGMP)

Es la solución más común.

Está basado en un modelo cliente/servidor, donde el router es considerado el CGMP
Server y el switch asume el rol de cliente. Hay un software funcionando en los dos
dispositivos que traduce los mensajes IGMP en comandos CGMP, que son
procesados en los switches y utilizados para rellenar las tablas de capa 2 con la
correcta información.

La base de CGMP es que un router multicast ve todos los paquetes IGMP e informa
al switch cuando hosts específicos se unen a los grupos multicast. Los routers
utilizan direcciones MAC CGMP conocidas para mandar los mensajes de control al
switch. El switch utiliza esta información para programar la tabla de envío.

Cuando el router ve un paquete de control IGMP, crea un paquete CGMP que

contiene la solicitud (join o leave), la MAC multicast y la MAC del cliente.

Este paquete se manda a la MAC (well-known) 0100.0cdd.dddd a la que los switches

escuchan. El mensaje CGMP es interpretado y las entradas apropiadas son creadas
en la CAM.

7.2.8 – IGMP Snooping

Los swithces escuchan las conversaciones entre los hosts y los routers para buscar
paquetes IGMP membership reports y leaves.
Hay que tener cuidado a la hora de implementar el snooping ya que el switch puede
llegar a interceptar todos los paquetes IGMP. Para solucionarlo se utilizan switches
de capa 3, pero aumentan mucho los costes.

7.3 – Multicast Routing Protocols

7.3.1 – Protocols Used in Multicast

Los árboles de distribución multicast definen el camino de la fuente a los receptores

sobre el cual el trafico multicast fluye.

Source treesSe crea un árbol separado para cada fuente a cada miembro del
grupo. Se llama Shortest Path Tree (STP) porque el origen escoge el camino mas
corto hacia el receptor. Cada source/Group requiere su propia información de
estado. Para grupos que tienen un gran número de fuentes, o redes que tienen un
gran número de grupos con gran número de fuentes, source trees pueden saturar
los routers.

Shared treescrean caminos de encaminamiento multicast que confían en un

punto central (RP rendevouz point) entre fuentes y receptores. Las fuentes mandan
los paquetes al RP, el cual reenvía los datos a través de un shared tree a los
miembros del grupo. Un shared tree es menos eficiente que un SPT, ya que no
tienen que ser los mismos caminos de ida y de vuelta, pero son menos exigentes
con los router.
Tipos de protocolos de routing multicast:

• Dense modeinundan el trafico multicast a todos los caminos de la red y

cortan los caminos en los que no hay receptores, utilizando un mecanismo
periódico de flood-and-prune.
• Sparse modeusan un mecanismo explicito de unión donde los árboles de
distribución son construidos bajo demanda por los mensajes de unión
mandados por los routers que tienen receptores directamente conectados.

7.3.2 – Multicast Distribution Trees

7.3.3 – Multicast Distribution Trees Identification

(S,G)For the source S sending to the group G. Estas entradas reflejan SPT, pero
también pueden aparecer en shared tree.

(*,G)For any source (*) sending to the group (G). Estas entradas reflejan un
shared tree, pero también son creadas para entradas (S,G).

STP usa más memoria al haber una entrada para cada Sender/Group, pero el tráfico
se envía por el camino óptimo a cada receptor, minimizando el retardo en el envío
de paquetes.
Shared distribution tree consume menos memoria, pero se utilizan caminos menos
óptimos a los receptores, introduciendo retardo extra en el envío de paquetes.

7.3.4 – IP Multicast Routing

El envío de paquetes depende de donde vino el paquete.

Los routers multicast deben conocer el origen del paquete. La ip destino muestra el
grupo multicast, osea un grupo de receptores multicast desconocidos.
El routing multicast utiliza un mecanismo llamado Reverse Path Forwarding (RPF)
para prevenir loops y asegurar el camino mas corto del origen al destino.
7.3.5 – Protocol-Independent Multicast: Describing PIM-DM

PIM en modo denso (PIM-DM) inicialmente inunda el trafico hacia todas las
interfaces no RPF donde hay otro vecino PIM-DM o un miembro del grupo
directamente conectado. A medida que los router van recibiendo trafico multicast
por sus interfaces RPF estos direccionan el trafico a sus vecinos PIM-DM.

Esto hace que llegue tráfico multicast a interfaces noRPF. Por las interfaces no RPF
se mandan mensajes prune para no aceptar más trafico multicast por esas
interfaces. Cuando el flujo multicast está correctamente establecido se llega al
estado (S,G) y continuará hasta que el origen pare de mandar información.
Los mensajes de prune duran 3 minutos. Al acabar los tres minutos comienza el
proceso de inundación de nuevo.
7.3.6 – Protocol-Independent Multicast: Describing PIM-SM

DM y SM son independientes de los protocolos unicast. Sm utiliza shared tree pero

puede conmutar a SPT.
SM se basa en un modelo explicito de solicitud. El tráfico es enviado solo a los
caminos de la red que lo necesitan.
SM usa un RP para coordinar el envío de trafico multicast. Las fuentes se registran
en el RP y mandan una copia única de datos multicast a través de el a los
receptores registrados. Los miembros del grupo se han unido al shared tree por su
router designado (DR). Un shared tree formado de esta forma siempre empieza en
el RP.

Es el más apropiado.

Optimizaciones:
• Bidirectional PIM modedestunado a aplicaciones many-to-may
• Source Specifuc Multicast(SSM)es una variante del SM que construye SPT.
7.3.7 – PIM Sparse-Dense-Mode

Se utiliza para escenarios con más de una fuente. Para obtener más eficiencia se
pueden implementar más de un RP en sus localizaciones óptimas. Como es difícil
configurar, administrar y buscar problemas con las configuraciones manuales, S-D-
M utiliza la elección automática de los RP.

Es la solución recomendable para hacer multicast con equipos Cisco.

Si no se descubre ningún RP para el grupo multicast o no hay ninguno configurado

manualmente, se ejecuta el modo PIM-DM.
7.4 – Multicast Configuration and Verification
7.4.1 – Enabling PIM Sparse Mode and Sparse-Dense Mode

Activa multicast:
Router(config)#ip multicast-routing

Activa SM o S-D-M en una interfaz:

Router(config-if)#ip pim {sparse-mode | sparse-dense-mode}

Para activar el RP. Este router manda un mensaje auto-RP a 224.0.1.39, anunciando
el router como un candidate para ser RP a los grupos indicados en el rango:
Router(config)#ip pim send-rp-announce {interface type} scope {ttl}
group-list {acl}

Configurar el router como un RP mapping agent. Escucha la 224.0.1.39 y envía un

mensaje RP-to-group a la 224.0.1.40. Los demás routers PIM escuchan la 224.0.1.40
para descubrir automáticamente el RP:
Router(config)#ip pim send-rp-discovery {interface type} scope {ttl}

Controls the switchover from the shared distribution tree to the shortest path tree
(SPT, or source distribution tree) in sparse mode. The keyword infinity means the
switchover will never occur:
Router(config)# ip pim spt-threshold {rate | infinity}

7.4.2 – Inspecting the Multicast Routing Table

7.4.3 – Finding PIM Neighbors

Cuando se ha configurado PIM-SM, el primer paso para verficar el correcto

funcionamiento, es comprobar las interfaces PIM y determiner si los neighbors son
correctos.

The show ip pim interface command displays the following information:

• Address: IP address of the interface.
• Interface: Type and number of the interface configured for PIM.
• Ver/Mode: PIM version (1 or 2) that is running on the interface and the
mode (dense mode, sparse mode, or sparse-dense mode).
• Nbr Count: Number of neighbors on this link.
• Query Intvl: Frequency at which PIM hellos and queries are sent (default is
30 seconds).
• DR Prior: Priority used in DR election. If all the routers on a multiaccess link
have the same priority (default is 1), the highest IP address is a tiebreaker.
• DR: IP address of the DR. (On point-to-point links, there are no DRs, so the
output shows 0.0.0.0.)
The show ip pim neighbor command displays the following information:
• Neighbor Address: IP address of the PIM neighbor.
• Interface: Interface where the PIM hello (PIM query in PIMv1) of this
neighbor was received.
• Uptime: Period of time that this PIM neighbor has been active.
• Expires: Period of time (hold time) after which this PIM neighbor is no longer
considered active. Receipt of another PIM hello or query resets the timer.
• Ver: PIM version that the neighbor is using (1 or 2).
• DR Priority: If the neighbor supports this option, the numeric value is
shown. If a number is not shown, the neighbor does not support the option.

7.4.4 – Checking RP Information

Router(config)#show ip pim rp [group-name | group-address | mapping]

Muestra información del RP sin argumentos en los grupos activos. Si se pone la ip o

el nombre, solo se muestra la información del RP del grupo seleccionado.

Router(config)#show ip pim rp mapping

Muestra el contenido de todos los group-to-RP que conoce. Este comando es

importante para comprobar la información del mappeo. Muestra:
• Ip del router que distribuye la información
 • Mecanismo por el cual esta información se ha obtenido (Auto RP, Static, BSR)
• Si opera como candidate-RP, mapping agent o BSR

Router(config)#show ip pim rpf { address | name }

Muestra información RPFdel RP o de la fuente. Muestra los grupos activos y los RP

asociados a ellos. Está obsoleto. La dirección especificada no tiene que ser una
fuente activa. Si se usa la ip del RP es muy útil para determinar información del
shared tree.
RPF Interface es la interfaz en la dirección del origen o RP.
RPF neighbor es la dirección del siguiente salto en la dirección del origen o RP.
RPF type indica el origen de la información RPF.

7.4.5 – Checking the Group State

Si el tráfico multicast no llega a los receptores, se debe comprobar la lista de

miembros del grupo IGMP.

Router#show ip igmp interface [type number]

Muestra información del interfaz seleccionado

Router#show ip igmp groups [group-address | type-number]

Muestra los grupos multicast directamente conectados al router.

7.4.6 – Configuring a Router to Be a Member of a Group

En algunos casos, es necesario configurar el trafico multicast para que vaya a un

segmento donde no hay grupos o donde el host no puede reportar su pertenencia a
un grupo usando IGMP.

Router(config-if)#ip igmp join-group [ip-address]

El router acepta los paquetes multicast para reenviarlos. Aceptándolos se previene

al router de hacer Fast switching.

Router(config-if)#ip igmp static-group

El router no acepta los paquetes pero los reenvía. Por lo tanto, este método permite
Fast switching. La interfaz saliente aparece en la cache IGMP, pero el router por si
mismo no es un miembro.

7.4.7 – Configure a Router as a Statically Connnected Member

Show ip igmp interface

Muestra los grupos multicast conectados al router:

• Configuración de la interfaz para multicast e IGMP
• Versión IGMP que corre la interfaz
• IGMPv2 querier on the multiaccess network
• Grupos a los que se ha unido el router

Show ip igmp groups

7.4.8 – Verifying IGMP snooping

Para verificar la configuración snooping para todas las vlan en el switch

show ip igmp snooping

show mac-address-table multicast