MULTICAST BÁSICO - CISCO

TOPOLOGÍA MULTICAST BÁSICO

TEORÍA MULTICAST

1- INTRODUCCIÓN

La comunicación IP tradicional permite a un host enviar paquetes a un único destino (transmisión unicast) o a todos los destinos (transmisión broadcast). El multicast IP proporciona una tercera opción, que permite a un host enviar paquetes a un subconjunto dentro de todos los hosts (grupo de transmisión). Estos hosts se conocen como miembros de grupo.

            

 Los paquetes entregados a un grupo de miembros están identificados por una única dirección de grupo multicast. 

El entorno multicast consiste en servidores (emisores) y receptores. Cualquier host, independientemente de su pertenencia a un grupo, puede enviar paquetes a dicho grupo. Sin embargo, solamente los miembros de un grupo reciben los mensajes. La dirección multicast asignada a un grupo es la dirección de destino utilizada por los servidores, para enviar los datagramas que deben llegar a todos los miembros del grupo.

 La pertenencia a un grupo multicast es dinámica, los hosts pueden unirse al grupo y / o abandonarlo en cualquier momento. No existen restricciones de localización o número de miembros en un grupo multicast. Un host puede ser miembro de más de un grupo multicast al mismo tiempo.

            
 La actividad de un grupo multicast y los miembros que pertenezcan a él puede variar de un grupo a otro y de un momento a otro. Un grupo multicast puede estar activo durante un  largo periodo de tiempo, o por el contrario, tener una corta duración. Un grupo que tenga miembros puede carecer de actividad.

            
 Los routers que ejecutan algún protocolo de enrutamiento multicast, como PIM (Protocol-Independent Multicast), necesitan tablas de enrutamiento multicast para enrutar este tipo de datagramas. Estos routers utilizan el protocolo IGMP (Internet Group Management Protocol) para averiguar si están presentes miembros de algún grupo en alguna de sus redes directamente conectadas. Los hosts se unen a los grupos multicast mediante el envío de mensajes IGMP report.

Índice 1- Introducción  1.1- Multicast en equipos Cisco 2- Bases del protocolo Multicast  2.1- Árboles de Distribución Multicast  2.2- Enrutamiento Multicast   2.2.1- RPF (Reverse Path Forwarding) 3- IGMP (Internet Group Management Protocol) 3.1- IGMP  3.2- IGMPv2   3.2.1- Características de IGMPv2   3.2.2- Suscripción a un grupo   3.2.3- Elección de Consultor   3.2.4- Manteniendo un grupo   3.2.5- Abandonando un grupo 3.2.6- Formato de paquetes IGMP 4- PIM SM (Protocol-Independent Multicast Sparse Mode)  4.1- Descubrimiento de vecinos  4.2- Enrutamiento SM  4.3- Suscripción SM  4.4- Registro SM  4.5- SPT Switchover  4.6- Pruning SM  4.7- Mantenimiento de PIM SM 4.8- Formato de paquetes PIM  4.8.1- Cabeceras de paquetes PIM  4.8.2- Mensajes de consulta PIM 4.8.3- Mensajes PIM Join / Prune 4.8.4- Mensajes PIM Register 4.8.5- Mensajes PIM Register-Stop 4.8.6- Mensajes PIM RP-Reachability 4.9- Ejemplo del funcionamiento del PIM SM 4.10- Configuración de PIM SM Anexo A Anexo B Anexo C  Anexo D

1.1- Multicast en Equipos Cisco

          
El sistema operativo de Cisco soporta los siguientes protocolos para la implementación del enrutamiento multicast:

·  IGMP (Internet Group Management Protocol) se utiliza para la comunicación entre los hosts de una LAN y el/los router(s) en esa LAN para esclarecer de que grupos multicast son miembros los hosts de la LAN. Existen 3 versiones de IGMP. En cuanto se habilita PIM en un router, inmediatamente se habilita IGMP para esuchar a los hosts.

·   PIM (Protocol-Independent Multicast) se utiliza para la comunicación entre routers para aclarar qué paquetes deben enrutarse entre sí y hacia las LANs directamente conectadas. Existen tres variantes de este protocolo: Dense Mode (DM), Sparse Mode (SM) y Sparse-Dense Mode.

·   DVMRP (Distance Vector Multicast Routing Protocol) es el protocolo utilizado en el MBONE (el backbone multicast en Internet).

·    CGMP (Cisco Group Management Protocol) es un protocolo alternativo a IGMP, utilizado en routers Cisco conectados a conmutadores Catalyst para realizar similares funciones a las realizadas por IGMP.

2- BASES DEL PROTOCOLO MULTICAST

             

El funcionamiento de los protocolos Multicast (como DVMRP, MOSPF, PIM, etc.), en la transmisión y enrutamiento del tráfico,  se basa, fundamentalmente, en dos puntos:

·         Árboles de Distribución Multicast: Estructuras que definen el camino que recorre el tráfico multicast desde la fuente hasta el/los receptor/es.

·         Enrutamiento Multicast: A diferencia del enrutamiento unicast que utiliza la dirección de destino para tomar la decisión de enrutamiento, el enrutamiento multicast utiliza la dirección de la fuente para tomar dicha decisión. Para enrutar el tráfico multicast utiliza la tabla multicast.

2.1- Árboles de Distribución Multicast

            Existen dos tipos de árboles:

1-      “Shortest Path” o “Source Distribution Tree” (S, G): Es el camino más corto, es decir, aquel con menor número de saltos. Utiliza más memoria que la segunda opción (*, G), pero obtiene los caminos óptimos desde la fuente a todos los receptores. Además, miniza el retardo.

2-      “Shared Distribution Tree” (*,G): Es el camino derivado desde un punto compartido, a través del cual, fuentes y receptores deben enviar / recibir datos multicast. Proporciona caminos “sub-óptimos” (pueden no ser los más cortos y pueden introducir retardo) desde la fuente a todos los receptores, pero requieren menos memoria para mantenerse.

 La notación (S, G) y (*, G) hace referencia a las entradas de la tabla de enrutamiento multicast. Las entradas que comienzan por (S, G) pertenecen al árbol de distribución del camino más corto, mientras que las entradas que comienzan por (*, G) pertenecen al árbol de distribución de camino compartido. Estas entradas hacen referencia a la fuente (S o *) y al grupo G.

La construcción de estos árboles de distribución depende del tipo de protocolo de enrutamiento multicast que se utilice. En nuestro laboratorio básico utilizamos el PIM SM (Protocol-Independent Multicast Sparse Mode). PIM utiliza la tabla de enrutamiento unicast del router (y por extensión cualquier protocolo de enrutamiento unicast), además de la tabla multicast, más las siguientes funciones:

·         Suscripción (Join): Los routers añaden sus interfaces y/o envían mensajes PIM-JOIN para establecerse a sí mismos como ramas del árbol cuando tengan receptores interesados.

·         Reducción (Prune): Los routers reducen sus interfaces y/o envían mensajes PIM-PRUNE para retirarse a sí mismos del árbol de distribución cuando dejen de tener receptores interesados.

·         Reinserción (Graft): Los routers envían mensajes PIM-GRAFT, cuando tienen una interfaz “reducida” y ya han enviado mensajes PIM-PRUNE, pero reciben una petición de suscripción IGMP de un host para un grupo ya “reducido”. Los routers deben restablecerse a sí mismos como ramas del árbol de distribución puesto que tienen nuevos receptores interesados.




-            Afirmación  (Assert): cuando tenemos fuentes  redundadas. Por ejemplo si tenemos 2 routers en un segmento que pueden enviar el miso tráfico multicas y queremos que sea solo uno, este es el Assert, que es una elección entre los routers.

-             Refresco (State Refresh): pregunta a los vecinos downstream si quieren cortar (prune) el tráfico multicast.

            2.2- Enrutamiento Multicast

            
 El enrutamiento multicast se realiza en sentido inverso al enrutamiento unicast. El primero es relativo al origen del paquete mientras que el segundo es relativo al destino del paquete. La dirección de origen del paquete denota fuente conocida mientras que la dirección de destino denota grupo desconocido de receptores.

            El enrutamiento multicast utiliza “Reverse Path Forwarding” (RPF).

            2.2.1- RPF (Reverse Path Forwarding)

            
 Los routers enrutan paquetes multicast si los reciben por la interfaz de entrada perteneciente al árbol de distribución, es decir, enruta el paquete si viene por el camino adecuado, si no es así lo descarta. Para esta comprobación (RPF check), los routers comparan la dirección IP origen del paquete con las entradas de la tabla de enrutamiento multicast, y cuando encuentran la línea comprueban la interfaz de entrada. Si el RPF check tiene éxito, es decir, coinciden la interfaces de entrada de la petición con la interfaz de salida para llegar a la fuente, el paquete se enruta; si no se descarta. El paquete nunca se enruta por la interfaz por el que se ha recibido.

3- IGMP (Internet Group Management Protocol)

         
 Los hosts IP utilizan IGMP para solicitar su suscripción a grupos multicast; esta solicitud se dirige a los routers multicast directamente conectados. IGMP forma parte del protocolo IP, y está definido en el RFC 1112: Extensiones de Hosts para Multicast IP.

 Mandan un IGMP Report:

• IGMVv1/2 -> (*,G) soports solo suscripción a grupos específicos
• IGMPv3 -> (S,G) soporta suscripción a emisor (source) y grupo específico       

 IGMP utiliza direcciones IP de Clase D. Los cuatro bits de orden superior de una dirección de Clase D son 1110, es decir, el rango de direcciones va de 224.0.0.0 a 239.255.255.255. Existen dos tipos de direcciones de grupo: permanentes y temporales. Ejemplos de direcciones permanentes son aquellas reservadas por la IANA para usos específicos. A continuación podemos ver algunos ejemplos:

            224.0.0.1         -           Todos los sistemas en la subred.

            224.0.0.2         -           Todos los routers en la subred.

            224.0.1.39       -           Anuncio RP de Cisco.                       (Auto-RP)

            224.0.1.40       -           Descubrimiento RP de Cisco.            (Auto-RP)

El direccionamiento IPv4 para multicast usa la clase D:

• 224.0.0.0/4 (224.0.0.0 - 239.255.255.255)
• Tiene rangos reservados:
• Link-Local -> 224.0.0.0/24
• SSM (Source Specific Multicast) -> 232.0.0./8 (IGMPv3)
• Uso Administrativo -> 239.0.0.0/8

            

3.1- IGMP

Este protocolo se configura en cada interfaz. Para poder comprobar la versión configurada podemos ejecutar desde modo enable la siguiente instrucción:

            router# show ip igmp interface

Vla15 is up, line protocol is up

  Internet address is 100.100.25.1, subnet mask is 255.255.255.0

  IGMP is enabled on interface

  Current IGMP version is 2

  CGMP is disabled on interface

  IGMP query interval is 60 seconds

  IGMP querier timeout is 120 seconds

  IGMP max query response time is 10 seconds

  Inbound IGMP access group is not set

  Multicast routing is enabled on interface

  Multicast TTL threshold is 0

  Multicast designated router (DR) is 100.100.25.1 (this system)

  IGMP querying router is 100.100.25.1 (this system)

  No multicast groups joined

            3.2- IGMPv2

            Como resultado de algunas de las limitaciones de IGMPv1 apareció la segunda versión para intentar superarlas. La mayor parte de los cambios se refieren a las latencias de suscripción y abandono de los grupos de multicast, así como ambigüedades con las direcciones en la especificación original del protocolo. Las principales características de la v2 de IGMP son las siguientes:

            3.2.1- CARACTERÍSTICAS DE IGMPv2

·         Preguntas específicas de grupo

            A la versión 2 se ha añadido una pregunta específica de grupo para permitir al router consultar la suscripción a un solo grupo, en lugar de a todos. Esta es una forma optimizada para averiguar, rápidamente, si queda algún miembro en un grupo sin consultar a todos los grupos.

La diferencia entre la pregunta específica y la general, es que esta última se realiza a la dirección multicast de todos los hosts (224.0.0.1), mientras que la pregunta de grupo específica para el grupo “G” se realiza a la dirección multicast de dicho grupo.

·         Mensaje de abandono de grupo

            Así mismo, en la versión 2 se ha añadido un mensaje de abandono de grupo. Esto permite a los sistemas terminales (hosts) notificar al router que abandonan el router, lo cual reduce la latencia de abandono del grupo en el segmento, cuando el miembro “saliente” es el último del grupo (en el segmento).

·         Elección de “Consultor o Querier"

            En su segunda versión, IGMP tiene en sí mismo un mecanismo de elección de “consultor”. La dirección IP más baja de los routers configurados con IGMP será la elegida como “equipo consultor”. Todo equipo configurado con IGMP arranca pensando que será el “consultor”, pero debe abandonar ese rol inmediatamente si escucha, en su mismo segmento de red, una “consulta” desde una dirección IP menor.

·         Tiempo de respuesta de intervalo de pregunta

            Las preguntas generales especifican el “Máximo Tiempo de Respuesta” que informa a los hosts del tiempo máximo en el que deben responder.

            3.2.2- Suscripción a un grupo

La suscripción a los grupos de Multicast es asíncrona, es decir, los hosts no tienen que esperar la consulta para suscribirse. Para unirse a un grupo basta con indicar su interés. Este sistema reduce la latencia de suscripción en el ingreso de un host a un grupo, cuando no hay otros miembros del grupo presentes en el segmento de red.

La suscripción de un miembro a un nuevo grupo implica el registro de ese nuevo grupo en el router. Para ver los grupos activos en el router podemos usar el siguiente comando:

router#show ip igmp groups

IGMP Connected Group Membership

Group Address    Interface           Uptime    Expires   Last Reporter

225.20.180.31    Vlan180             5w1d      00:02:10  10.20.180.5

225. 20.180.16    Vlan180             5w1d      00:02:10  10.20.180.6

225.15.1.22    Vlan15             5w1d      00:02:11  10.15.1.6

224.0.1.40          Serial0/1            1w6d      00:02:42  100.100.30.20

224.0.1.40          Serial0/0.2         2w3d      00:02:12  100.100.10.2

224.0.1.40          Serial0/0            2w6d      never        0.0.0.0

Podemos ver algunos de los grupos activos en las interfaces especificadas. En la tabla tenemos el tiempo que lleva activo (Uptime), el tiempo en el que expirará si no hay más refrescos (Expires), y la última máquina que ha solicitado pertenecer al grupo (Last Reporter).

            3.2.3- Elección de consultor o querier

En IGMPv2 se ha establecido en el propio protocolo un proceso para determinar el router “consultor”. Como se ha explicado anteriormente: La dirección IP más baja de los routers configurados con IGMP será la elegida como “equipo consultor”. Todo equipo configurado con IGMP arranca pensando que será el “consultor”, pero debe ceder ese rol inmediatamente si escucha, en su mismo segmento de red, una “consulta” desde una dirección IP menor. Si el router elegido como router “consultor” no envía la consulta en el intervalo correspondiente, se consumirá un temporizador en los otros routers IGMPv2 y reiniciarán el proceso.

IGMPv2 también ha añadido el concepto de “Consultas a Grupos Específicos”. Esta funcionalidad se consigue enviando la consulta de suscripción IGMPv2 a las direcciones multicast de los grupos, en lugar de a la dirección multicast de todos los hosts (224.0.0.1), como es el caso de las consultas generales IGMPv2. Por defecto, las consultas de suscripción se envían cada 60 segundos.

Para conocer el router consultor en una interfaz IGMP podemos utilizar el siguiente comando (extracto representado):

            router# show ip igmp interface

Vla15 is up, line protocol is up

  Internet address is 100.100.25.1, subnet mask is 255.255.255.0

  IGMP is enabled on interface

  Current IGMP version is 2

  CGMP is disabled on interface

  IGMP query interval is 60 seconds

  IGMP querier timeout is 120 seconds

  IGMP max query response time is 10 seconds

  Inbound IGMP access group is not set

  Multicast routing is enabled on interface

  Multicast TTL threshold is 0

  Multicast designated router (DR) is 100.100.25.1 (this system)

  IGMP querying router is 100.100.25.1 (this system)

  No multicast groups joined

            3.2.4- Mantenimiento de un grupo

            Proceso de consulta-respuesta

 
 En un segmento de red, el router multicast envía, periódicamente, consultas de suscripción a la dirección del grupo multicast de todos los hosts (224.0.0.1). Sólo responde un miembro por grupo a la consulta (el resto al escuchar la respuesta cancelan su propio mensaje). Esto permite ahorrar ancho de banda en  la red y tiempo de proceso en los hosts. Este mecanismo se conoce como “Response Suppression”.

            Mecanismo “Response Suppression”

Cuando un host recibe la consulta, comienza la cuenta atrás de un contador para cada grupo multicast al que pertenezca. Los contadores se inicializan con un número aleatorio dentro de un rango establecido. Cuando un contador alcanza cero, el host envía un mensaje  de suscripción para el grupo asociado con el contador, para notificar al router que el grupo está aun activo. Sin embargo, si un host recibe o escucha un mensaje de suscripción antes de que su contador asociado a ese grupo alcance cero, cancela el contador y suprime su propio mensaje.

            3.2.5- Abandonando un grupo

            El protocolo IGMPv2, a diferencia de IGMPv1, incluye mensajes explícitos para abandonar un grupo. Cuando el router consultor recibe un mensaje de abandono, responde enviando una consulta específica al grupo para ver si todavía responden otros hosts que quieran recibir tráfico de ese router. Este proceso ayuda a reducir la “latencia de abandono”.



3.2.6- Formato de paquetes

            La estructura de los paquetes de IGMPv2 es la siguiente

·         Type

Se asegura la compatibilidad hacia atrás con IGMPv1 mediante los valores 0x11 y 0x12 para la consulta de suscripción (v1 y v2) y la respuesta a suscripción v1 respectivamente.

·         Max. Response Time

Este campo permite al router consultor especificar exactamente el tiempo de respuesta para esta pregunta. El valor (entre 1 y 10 segundos) lo utilizan los hosts IGMPv2 como límite superior cuando eligen aleatoriamente el tiempo de su respuesta.

·         Dirección del grupo

Este campo contiene la dirección IP del grupo multicast  al que se refiera el mensaje, excepto en las preguntas generales (para le elección de consultor), en las que contiene 0.0.0.0.

Multicast de Capa 2

IGMP Snooping

Con IGMP Snooping podemos restringir tráfico multicast en la capa 2 haciendo que el tráfico solo se entregue a través de los puertos que tienen al menos un miembro activo del tráfico multicast. Usa la información recogida en los IGMP Reports para construir la "forwarding table" de multicast.

IGMP Snooping nos ayuda a reducir el consumo de ancho de banda.

Solo distingue 2 tipos de puertos: host ports y multicast router ports. Los puertos multicast router se descubren automáticamente (discovery), aunque se pueden configurar manualmente (static). Sin embargo, con el comando "router-guard" podemos hacer que ese puerto no sea descubierto como multicast router port filtrando los mensajes.

IGMP Filter

Nos ofrece mayor control del tráfico multicast. IGMP Filtering solo gestiona los " IGMP Membership Join Reports" y cuando un filtro es aplicado, el Join Report es descartado y el puerto no entonces no tiene permitido el tráfico multicast.

Podemos configurar también el número de grupos multicast que son permitodos en un puerto:

        (config-if)#ip igmp max-groups


IGMP Proxy

Habilita a host que no están directamente conectados a un router que envía multicast poder recibir el tráfico.


Documento de Cisco sobre IGMP Proxy


MLD

Multicast Listener Discovery es un protocolo similar a IGMP pero para IPv6. La versión 1 de MLD se compagina con la IGMPv2 y la MLDv2 se compagina con IGMPv3.

MLD Snooping provee de la misma funcionalidad que IGMP. Usa 3 tipos de mensajes:

•  Multicast Listner Query
• General Query
• Multicast-Address-Specific Query

• Multicast Listener Report
• Multicast Done

PIM Snooping

Esta caracterísitica hace que los switches que tienen puertos conectados a routers que envían multicast cierre los puertos al tráfico de grupos multicast si no tiene ningún tráfico multicast.

Hay que tener habilitado IGMP Snooping en el switch. Esta deshabiliado por defecto.

SIN PIM SNOOPING

El host hace un IGMP Join y los switches lo distribuyen por todos los puertos.

CON PIM SNOOPING

El host hace un IGMP Join y los switches lo distribuyen solo por el puerto interesado. 

Documento de Cisco sobre IGMP



PIM (Protocol Independent Multicast)

Es el protocolo usado entre los routers para señalizar cómo construir el árbol multicast. No construye su propia topología de la red, sino que usa la información de otros protocolos para comprobar que el árbol multicast se puede construir y no tiene bucles.

PIM controla cómo se construye el árbol y quien recibe el tráfico

Tenemos 3 modos de correr PIM:

• Sparse Mode -> El tráfico no se envía a no ser que el equipo lo solicite. Usa un RP (Rendesvouz Point) para procesar las suscripciones (join)
• Dense Mode -> Inunda toda la red. Usa un comportamiento "Flood-Prune". El tráfico llega a todos y los no interesados tienen que rechazarlo con un mensaje Prune. No es eficiente en gandes redes.
• Sparse-Dense Mode -> Los grupos que tienen asignado un RP corren bajo SM y el resto bajo DM.

 



4- PIM SM (Protocol-Independent Multicast Sparse Mode)

Las principales características del PIM SM son las siguientes:

·         Modelo explícito de suscripción.

El PIM SM utiliza un modelo explícito por el cual los receptores envían mensajes “PIM Join” a su “Rendezvous Point” (RP) designado. El RP es  la raíz de un árbol compartido (Shared Distribution Tree) por el que fluye el tráfico multicast.

·         El chequeo RPF depende del tipo de árbol.

Si el tráfico multicast recibido fluye por el árbol compartido (Shared Tree), el chequeo RPF utilizará la dirección IP del RP. Sin embargo, si el tráfico multicast recibido fluye por el camino más corto (SPT), el chequeo RPF utilizará la dirección IP de la fuente. En la sección de enrutamiento PIM SM se describen con más detalle ambas opciones.

·         Sólo un RP puede estar activo para un grupo en un momento dado.

La situación habitual es tener un solo RP para todos las grupos, sin embargo, es posible configurar diferentes RPs para varios grupos. Esto puede hacerse mediante listas de acceso. De esta forma, podemos colocar los RPs en diferentes lugares y mejorar el flujo de tráfico especialmente si están próximos a las fuentes. En la configuración de los routers podemos ver todo esto en las siguientes líneas:

ip pim rp-address 192.168.0.1 21 override

ip pim rp-address 192.168.0.2 11 override

ip pim rp-address 192.168.0.3 31 override

            Donde podemos ver las direcciones IP de los RPs, así como, el número de la lista de acceso asociada. El último parámetro (override) es para que prevalezca la configuración estática ante la automática, es caso de que esta exista

·         Configuración de los RPs.

 Los puntos de encuentro (RP) pueden ser configurados estáticamente en cada router en la red (pero deben coincidir para un correcto funcionamiento). Sin embargo, existe la posibilidad de configurarlos automáticamente mediante Auto-RP o BSR (Bootstrap Router)

·         Enrutamiento.

El enrutamiento multicast en una red “PIM Sparse Mode” se realiza buscando, en primer lugar, una coincidencia (S, G) en la tabla, es decir, una línea en la tabla de enrutamiento multicast en la que coincida fuente y grupo con los del paquete. Si no se encuentra una entrada (S, G), se enruta el datagrama utilizando una entrada (*, G) en la tabla.

            En un router podemos encontrar en la tabla de enrutamiento multicast (accesible mediante el comando “show ip mroute”), los dos tipos de entradas, un ejemplo de cada:

(100.100.1.99/32, 224.100.100.50), 00:01:34/00:01:25, flags: FT

  Incoming interface: Vlan7, RPF nbr 0.0.0.0, Registering

  Outgoing interface list:

    Serial0/1, 10.152.50.11, Forward/Sparse, 00:01:34/00:02:11

(*,224.100.100.50), 7w0d/00:02:59, RP 10.10.28.209, flags: SJC

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    Serial0/0.5, 10.100.10.12, Forward/Sparse, 1w6d/00:02:26

    Vlan209, Forward/Sparse, 6w4d/00:02:22

    Serial0/1, 10.152.30.11, Forward/Sparse, 3w2d/00:02:02

            Para más información, consultar el Anexo C donde se comenta con mayor detalle la tabla de enrutamiento multicast.

4.1- Descubrimiento de Vecinos

             Las consultas PIM se envían periódicamente para descubrir la existencia de otros routers PIM en la red a la dirección multicast 224.0.0.13. Para redes multiacceso (como Ethernet), estos mensajes de consulta se envían a la dirección multicast de “todos los routers” (224.0.0.2). PIM  es independiente y usa otra dirección.

            En redes multiacceso, se elige un “Designated Router” (DR), para cada segmento de red, de forma que los mensajes de consulta puedan llegar a todos los equipos. En redes PIM Sparse Mode, el DR es el responsable de enviar “Joins” (o mensajes de suscripción) de los hosts hacia los RPs. Esta medida es necesaria cuando tenemos dos routers de primer salto, es decir, dos routers que tienen acceso al segmento de red donde se encuentran los hosts. En esta situación solo uno de los dos debe transmitir el mensaje hacia el RP.

Para elegir el DR, cada nodo PIM examina los mensajes de consulta PIM recibidos de sus vecinos y compara sus direcciones IP con la dirección IP de su propia interfaz. El vecino PIM con la dirección IP más alta es elegido como DR. Si no se han recibido mensajes de consulta PIM del DR elegido, en un periodo de tiempo (configurable), el proceso de elección de DR comienza de nuevo.

            En un router podemos ver sus vecinos mediante el comando “show ip pim neighbor”, con el siguiente resultado:

PIM Neighbor Table

Neighbor Address  Interface          Uptime    Expires   Mode

100.0.20.20      Serial0/1          1w6d      00:01:00  Sparse

100.0.20.11      Serial0/1          3w2d      00:01:07  Sparse

100.0.30.11      Serial0/1          3w2d      00:01:27  Sparse

100.0.50.11      Serial0/1          3w2d      00:01:13  Sparse

100.0.50.20      Serial0/1          3w2d      00:01:05  Sparse       (DR)

10.152.40.20      Serial0/1          3w2d      00:01:05  Sparse

10.152.40.11      Serial0/1          3w2d      00:01:23  Sparse

100.0.10.2       Serial0/0.2        3w2d      00:01:29  Sparse       (DR)

100.0.10.12      Serial0/0.5        4w3d      00:01:22  Sparse       (DR)

100.0.29.101      Vlan18             4w3d      00:01:15  Sparse       (DR)

            Los campos que podemos ver son los siguientes:

a)      Neighbor Adress: Dirección IP del vecino PIM.

b)      Interface: La interfaz por la que se ha recibido la consulta PIM de su vecino.

c)      Uptime: El periodo de tiempo que ha estado activo.

d)     Expires: El periodo de tiempo tras el cual el vecino PIM no será considerado activo. (Puesto a  cero por la recepción de otra consulta PIM).

e)      Mode: Modo PIM (Sparse, Dense, Sparse/Dense) utilizado por el vecino.

f)       (DR): Indica que el vecino PIM es el DR para el segmento de red.

         

   4.2- Enrutamiento SM

En los equipos Cisco las interfaces son:

• Incoming Interface -> Upstrema. Es la interface por donde se llega a la fuente
• Outgoing Interface (OIL) -> Downstream. Las interfaces hacia los receptores

            Primera Fase: Chequeo RPF

            
 El primer paso en el enrutamiento IP es el chequeo RPF, que como hemos visto anteriormente depende del tipo de árbol de distribución. Cuando un datagrama multicast llega el router busca, en primer lugar, en la tabla de enrutamiento multicast una coincidencia (S, G), es decir, una línea en la tabla de enrutamiento multicast en la que coincida fuente y grupo con los del datagrama. Si la encuentra se trata de un árbol de camino más corto (Shortest-path). Si no la encuentra, busca una entrada (*, G) en la tabla, que si existiera, indicaría un árbol compartido (Shared). En función del tipo de árbol se realizan las siguientes acciones:

·         Shared Tree (*, G): Se realiza el chequeo RPF con la dirección IP del punto de reunión (RP). Para ello, comprueba en la tabla de enrutamiento unicast, que para alcanzar esa dirección IP debe soltar el paquete por la interfaz por la que ha recibido el datagrama multicast, es decir, lee la tabla al revés. Si se realiza con éxito el datagrama pasa a la segunda fase, si no se descarta. (NOTA: Esta comprobación también puede realizarse con el “Incoming Interface” de la tabla multicast, el resultado será siempre el mismo). Solo para Sparse Mode. Elimina mucho tráfico inncesario.

·         Shortest-path Tree (S, G): Se realiza el chequeo RPF con la dirección IP origen. El mecanismo de comprobación es exactamente el mismo que en el caso anterior, lo único que cambia es la dirección IP utilizada.

Una vez se ha validado el datagrama mediante el chequeo RPF, debemos enviar el paquete a su destino, es decir, realizar el enrutamiento propiamente dicho.

Segunda Fase: Envío de paquetes multicast.

Una vez más, en primer lugar, se busca una entrada en la tabla multicast del tipo (S, G), y si no existe, se busca una del tipo (*, G). El datagrama se envía por las interfaces señaladas como “Outgoing Interfaces” en la línea de la tabla multicast correspondiente a ese grupo.

            Las interfaces se colocan en la lista de “Outgoing Interfaces” si y sólo si se cumple al menos una de las siguientes condiciones:

a)      El router ha recibido un mensaje PIM Join para ese grupo desde otro vecino PIM vía esa interfaz.

b)      Un host en esa interfaz se ha unido a un grupo (vía IGMP).

c)      La interfaz del router ha sido configurada manualmente para unirse al grupo.

NOTA: La interfaz “Incoming” se incluye en el momento que se crea la entrada en la tabla de enrutamiento multicast. En el caso del árbol de distribución compartido, dicha interfaz contiene la interfaz directamente conectada del vecino PIM anterior en el camino hacia el RP (en el propio RP el “Incoming Interface” estará a “null”). Y en el caso del árbol de distribución del camino más corto, contiene la interfaz directamente conectada del vecino PIM anterior en el camino hacia la fuente.

            4.3- Suscripción SM

            El mecanismo de suscripción comienza cuando algún router, en un de último salto del árbol de distribución compartido (Shared Tree), desea recibir tráfico multicast perteneciente a un grupo G (normalmente debido a un mensaje IGMP de unión enviado por un host a dicho router). Para recibir tráfico multicast del grupo G, el router envía un mensaje PIM Join (*, G) a su router superior, o vecino PIM, en el árbol hacia el RP (si hay más de uno, escogerá el DR, como hemos visto anteriormente).  Este es un mensaje multicast a todos los routers (224.0.0.2), pero en el paquete se indica la dirección IP del vecino PIM. De esta forma, todos los routers PIM en la red conocerán la unión, pero sólo el vecino PIM indicado por la dirección IP realizará la suscripción.

           

            Cuando un router PIM recibe un mensaje de suscripción (*, G) para el grupo G, de uno de sus vecinos PIM por debajo de él en el árbol, comprobará si en su tabla de enrutamiento multicast ya existe una entrada (*, G).

a)      Si la entrada (*, G) existe, entonces la interfaz, por la que se ha recibido el mensaje de suscripción, se coloca en la lista de interfaces de salida (Outgoing List).

b)      Si la entrada (*, G) no existe, se crea. La interfaz por la que se ha recibido el mensaje de suscripción se coloca en la lista de interfaces de salida (Outgoing List), y se envía un mensaje de suscripción (*, G) hacia el RP.

El resultado final de todo este mecanismo es la creación de una entrada (*, G) en todos los routers desde los routers de último salto hasta el RP, de forma que el tráfico multicast del grupo G fluya por el árbol compartido hasta el router de último salto.

            4.4- Registro SM

El mecanismo de registro permite a los routers, que constituyen el árbol de distribución, actualizar sus tablas de enrutamiento multicast para conducir correctamente dicho tráfico, desde las fuentes hasta los receptores.

            Las fuentes no son necesariamente receptores y viceversa. En el caso de un host fuente exclusivamente, se le permite comenzar a enviar paquetes multicast sin necesidad de suscribirse a un grupo vía IGMP. El mecanismo desencadenado por el envío de paquetes multicast difiere ligeramente si los receptores se suscriben primero, o si son las fuentes las que actúan primero (la diferencia puede apreciarse cuando el RP recibe mensajes “Register”). Básicamente, el proceso es el siguiente:

·         El router de primer salto envía “Registros” al RP.

En PIM Sparse Mode, cuando un router de primer salto recibe el primer paquete multicast de una fuente directamente conectada “S” para el grupo “G”, crea en la tabla de enrutamiento multicast una entrada (*, G) y otra (S, G), marca esta última como directamente conectada y “Registrándose” (flag “F”), y ambas como “pruned” (flag “P”) porque la OIF está a null. (Nota: En un router Cisco no es posible tener una entrada (S, G) sin una entrada (*, G)).

A continuación, el router de primer salto encapsula el paquete original multicast en un mensaje “PIM Register” y lo manda al RP de forma unicast. (A partir de este momento, cualquier paquete multicast recibido desde la fuente directamente conectada “S”, para el grupo “G”, serán también encapsulados en un mensaje “Register” y mandados por unicast al RP. Esto continuará hasta que se recibe un mensaje “Register Stop” (S, G) desde el RP.

            Es necesario enviar el tráfico multicast encapsulado al RP porque él es la raíz del árbol de distribución compartido, por el que debe fluir el tráfico multicast. Si no se enviara encapsulado, podría ser enrutado a otras ramas por otros equipos intermedios, y entonces el tráfico multicast no pasaría por el RP en el camino compartido (condición necesaria).

·         El RP recibe mensajes “Register”.

Cuando el RP recibe un mensaje “Register” lo desencapsula. En este punto, todo depende de si el RP tiene una entrada (*, G) con el grupo al que se dirigen los paquetes multicast (porque, por ejemplo, otra fuente haya transmitido al mismo grupo), o no.

a)      Si existe la entrada (*, G) en el RP, (implica que hay receptores en el árbol compartido), envía el paquete original por todas las interfaces de salida (Outgoing List). Si todavía no lo ha creado, el RP genera la entrada (S, G) y envía un mensaje Join (S, G) de vuelta hacia la fuente para formar al camino más corto (SPT) con la fuente “S”. Y, como veremos más adelante, terminará por recibir el tráfico multicast por el SPT y cancelará los mensajes “Register”.

b)      Si no existe la entrada (*, G) en el RP (implica que no hay receptores en el árbol compartido), descarta los paquetes multicast hacia ese grupo. Además, al no necesitar tráfico (S, G), el RP envía un mensaje PIM Prune hacia el router de primer salto (que no alcanzará su destino si existen routers en el camino que no conozcan el grupo, y que por lo tanto descartarán los paquetes). Por último, el RP envía al router de primer salto un mensaje “Register Stop” para que detenga el envío de paquetes registrados (encapsulados y enviados como unicast).

·         Router de primer salto recibe un mensaje “Join (S, G)”.

Cuando el router de primer salto recibe el mensaje Join (S, G) (enviado salto a salto desde el RP), lo procesa y añade la interfaz por la que ha llegado el mensaje a la lista de interfaces de salida (Outgoing List), para esa entrada. (Esa entrada fue, originalmente, creada cuando el router de primer salto recibió el primer paquete multicast de la fuente directamente conectada “S”, y se creó con la OIF vacía, como siempre). Este proceso se realiza, salto a salto, en todos los routers intermedios (si existen), de forma que se completa la construcción del camino más corto (Shortest-Path Tree – SPT) desde la fuente hasta el RP.

            A partir de este momento, el router de primer salto comienza a enviar el tráfico multicast de la fuente “S” a través del recientemente construido camino más corto (SPT), hacia la fuente.

            Es importante tener en cuenta que el tráfico multicast (S, G) fluye temporalmente hacia el RP mediante dos métodos diferentes: encapsulado en mensajes “Register” (hasta que se reciba un mensaje “Register-Stop”), y a través del camino más corto (SPT).

·         El RP comienza a recibir tráfico (S, G) por el camino más corto (SPT).

Tan pronto como el RP comienza a recibir tráfico multicast (S, G) natural (sin encapsular en mensajes “Register”) a través del camino más corto, el RP marcará el flag “T” en la entrada (S, G) para indicar que el tráfico fluye por el camino más corto (SPT).

A partir de este momento, cuando se reciba en el RP cualquier mensaje “Register”, al estar el flag “T” activado para esa entrada (S, G), responderá al router de primer salto con un mensaje PIM (S, G) Register-Stop. De esta forma se notifica al router de primer salto que el tráfico multicast está siendo recibido sin encapsular y por el camino más corto (SPT).

·         El router de primer salto recibe el mensaje “Register-Stop”.

Cuando el router de primer salto recibe el mensaje “Register-Stop” desactiva el flag “Registering”, el F, en la entrada (S, G) y deja de encapsular el tráfico multicast (S, G) en mensajes “Register”. Finalmente, el tráfico queda, únicamente, circulando por el camino más corto hacia el RP.

            4.5- SPT - Switchover.

            En PIM SM la conmutación SPT (SPT Switchover) se configura para conmutar al camino más corto. Para determinar el momento de la conmutación se utilizan umbrales aplicados a los anchos de banda de tráfico multicast. Los umbrales SPT se especifican en Kbps y mediante listas de acceso se puede especificar los grupos a los que aplicar los umbrales. El umbral por defecto es 0 Kbps, es decir, que todas y cada una de las fuentes se conmutan al camino más corto. Si se configura un umbral “Infinito” en un grupo, las fuentes no conmutarán nunca al camino más corto, y continuarán en el camino compartido.

            Cuando el umbral SPT de un grupo se supera en un router de último salto, o de último salto, el siguiente paquete recibido para ese grupo, a partir de ese momento, provocará el envío de un  paquete (S, G) Join, salto a salto, hacia la fuente del paquete. De esta forma, se construye el camino más corto desde la fuente “S” hasta el router de último salto.

            Ventajas: Se conmuta al camino más corto (SPT), para utilizar el camino óptimo (normalmente) en la transmisión de paquetes multicast. Dependiendo de la posición de la fuente respecto al RP, esta conmutación puede reducir la latencia de red substancialmente.

            Inconvenientes: En redes con un número alto de fuentes, se debe poner más atención al estado de los routers. En algunos casos, se configura un umbral infinito para forzar el camino compartido cuando la latencia no es una prioridad.

            Para configurar el umbral SPT en un router Cisco, desde el modo de configuración basta con utilizar el comando “ip pim spt-threshold umbral”.

            Mecanismo SPT-Switchover

            Es importante tener en cuenta que este mecanismo no consiste en comparar los tráficos de las fuentes independientemente en un grupo con el umbral especificado. En su lugar, se calcula el tráfico total de un grupo que fluye por el árbol compartido (Shared Tree) en un segundo. Si este valor excede el umbral establecido, el siguiente paquete recibido provoca la conmutación al camino más corto.

            El mecanismo paso a paso es el siguiente:

·         Una vez cada segundo, todo el tráfico dirigido al grupo “G” (*, G) se compara con el umbral SPT. Si el tráfico de todo el grupo supera el umbral, entonces se activa el flag “J” en la entrada (*, G) de la tabla de enrutamiento multicast.

·         A medida que se recibe cada paquete multicast por el camino compartido, el flag “J” se consulta en la entrada (*, G). Si el flag “J” está activado:

a)      Se crea una nueva entrada (S, G) para la fuente del paquete.

b)      Se envía a la fuente un mensaje (S, G) Join, para unirse al camino más corto (SPT).

c)      Se activa el flag “J” en la entrada (S, G) para denotar que esa entrada fue creada como resultado de una conmutación al camino más corto (SPT) por superar el umbral SPT.

d)     Se desactiva el flag “J” en la entrada (*, G). (Que será activado nuevamente en el segundo siguiente si el tráfico conjunto dentro del grupo supera el umbral SPT).

·         Este mecanismo puede, en algunos casos, conmutar por error fuentes con tráfico bajo al SPT. Sin embargo, el mecanismo RPT-Switchback corrige esta situación y, eventualmente, solo las fuentes de alto tráfico serán recibidas por el SPT, mientras que las fuentes de bajo tráfico permanecerán en el camino compartido.

Mecanismo RPT-Switchback

            Este mecanismo se utiliza para conmutar las fuentes de vuelta al camino compartido (Shared Tree), cuando sus tráficos caen por debajo del umbral SPT. A diferencia del mecanismo anterior, el RPT-Switchback se realiza una vez cada minuto, (de esta forma se evita el cambio cíclico, demasiado rápido, de las fuentes entre el camino compartido o Shared Tree y el camino más corto, o Shortest-path Tree).

            Para cada entrada (S_i, G) en la tabla de enrutamiento multicast que tenga activado el flag “J”, el mecanismo calcula el volumen de tráfico para la fuente “S_i”. Si el volumen de tráfico cae por debajo del umbral SPT, se vuelve atrás para conmutar al camino compartido. Este proceso lo realiza el router de último salto mediante los siguientes pasos:

a)      Envía un mensaje de tipo Join / Prune (ver formato de paquetes) que contenga un (*, G) Join, es decir, una solicitud de unión al camino compartido, sin el bit (S_i, G) RP-bit Prune, por el camino compartido (Shared Tree). Esto provocará la reducción (prune), y por lo tanto borrado, de las entradas (S_i, G) en la tabla de enrutamiento multicast, de forma que el tráfico vuelva a fluir por el RPT (Shared Tree) de nuevo.

b)      El router que desata el proceso borra su entrada (S_i, G) de su tabla de enrutamiento multicast.

c)      Dicho router envía un mensaje (S_i, G) Prune por el camino más corto (SPT) para detener el tráfico que fluya por este árbol, para que el proceso se repita en toda la rama.

            4.6- Pruning SM.

            El proceso de reducción o “pruning” es el que se produce cuando el contador de tiempo de un grupo IGMP llega a cero, o cuando el último host o usuario abandona el grupo “G”.

            La interfaz del router que da acceso a los usuarios de dicho grupo se retira de la entrada (*, G), y todas las entradas (S, G) desaparecen de la tabla de enrutamiento multicast. Entonces:

a)      Si la lista de interfaces de salida (Outgoing Interface List) se queda en “Null”, se envía un mensaje (*, G) Prune por el camino compartido hacia el RP.

b)      En cualquier entrada (S, G) se deja agotar el contador “Expires” (ver Anexo C) para que sea borrada de la tabla de enrutamiento multicast.

Cuando los routers, por encima en al árbol compartido, reciben el mensaje (*, G) Prune, retiran las interfaces por las que han recibido el mensaje (hay que comprobar interfaz y salto siguiente), de las “Outgoing Interfaces Lists” de las entradas (*, G) de sus tablas de enrutamiento multicast.

a)      Si como resultado de retirar la interfaz la lista de interfaces de salida de la entrada (*, G) se queda a “Null”, se envía en mensaje (*, G) Prune por el árbol compartido (RPT) hacia el RP.

b)      En cualquier entrada (S, G) se deja agotar el contador para que sea borrada de la tabla de enrutamiento multicast.

            4.7- Mantenimiento de PIM SM.

            En PIM SM, la información de suscripción o abandono (Join / Prune) tiene un tiempo normal de expiración de 3 minutos. Si no se recibe periódicamente un mensaje tipo “Join / Prune” para refrescar este estado, automáticamente, expira y se borra. Por lo tanto, un router PIM envía, periódicamente, mensajes tipo “Join / Prune” a sus vecinos PIM para mantener el estado de la información.

            Cuando se recibe un mensaje “Join” de un vecino PIM, el temporizador de expiración de la interfaz (en la “Outgoing Interface List”) por la que se ha recibido, se reinicializan a 3 minutos. Si el temporizador de expiración de la interfaz llega a cero, la interfaz se retira de la “Outgoing Interface List”. Esto puede activar una reducción o Prune, si al retirar la interfaz de la lista, esta se queda “Null”.

            Cuando se recibe un mensaje Prune en PIM Sparse Mode, la interfaz por la que se ha recibido se retira de la “Outgoing Interface List”. La excepción es el caso especial de las reducciones, o Prunes, (S, G)RP-bit, que se utilizan para reducir tráfico (S, G) de camino compartido (Shared Tree). En este caso, se deben enviar reducciones (S, G)RP-bit para refrescar el estado de reducido (prune) en el vecino hacia el RP.

            Todas las entradas (S, G) tienen unos temporizadores de expiración, que se reinicializan a 3 minutos por la recepción de un paquete (S, G) recibido por el camino más corto (SPT). Si la fuente deja de mandar, este tiempo de expiración se reduce a cero y la entrada (S, G) se borra.

 

4.8- Formato de paquetes PIM.

            En este apartado vamos a ver la estructura de los diferentes tipos de paquetes utilizados en las diferentes funciones del protocolo PIM. Comenzaremos con la cabecera de los paquetes PIM, que es común para todos ellos.

            4.8.1- Cabeceras de paquetes PIM





            4.8.2- Mensajes de consulta PIM

            Estos mensajes se utilizan para establecer o mantener el estado con los equipos vecinos. Se envían periódicamente para indicar a los otros routers PIM de la red que este router PIM está presente todavía.

  

 

4.8.3- Mensajes PIM Join / Prune

            Este es un sencillo formato de paquete que contiene una lista de suscripciones (Joins) y reducciones (Prunes). Cualquiera de las listas puede estar vacías, pero nunca las dos a la vez.

 Listas de grupos

            Las listas de grupos se utilizan en los mensajes Join/Prune, así como en los mensajes Graft y Graft-Ack. Una lista de grupos es una relación de grupos, cada entrada de la lista comienza por la dirección IP de un grupo y su máscara para identificar al grupo multicast.

            Cada entrada de la lista de grupos contiene un conjunto de cero o más fuentes para suscribirse (Join) seguida por un conjunto de cero o más fuentes para cancelar su suscripción (Prune). Estos conjuntos o listas Join / Prune contienen una lista de direcciones de fuentes codificadas.

            Direcciones de fuentes codificadas

Las direcciones fuente contenidas en las listas Join y Prune están codificadas en un formato especial como se puede apreciar en la figura anterior.

a)      S = Sparse Mode bit: Utilizado por los routers en el camino más corto (SPT) para indicar que es un grupo Sparse Mode, Lo cual le dice al receptor de este Join que debe enviar Joins periódicos hacia la fuente.

b)      W = Wildcard bit: Si este bit está a uno, indica que el Join/Prune se aplica a la entrada (*, G), es decir, corresponde a un Join/Prune del camino compartido. Si este bit está a cero, indica que se aplica a la entrada (S, G), es decir, corresponde a un Join/Prune del camino más corto. Los Joins y Prunes enviados a un RP deben tener este bit activado (a uno).

c)      R = RP bit: Si este bit está a uno, indica que esta información se debe enviar por el camino compartido hacia el RP. Si este bit está a cero, la información debe enviarse por el camino más corto hacia la fuente.

d)     Lon. M: Longitud de la máscara en bits.

e)      Dirección de fuente: Dirección IP de la fuente.

 

            4.8.4- Mensajes PIM Register

            Este tipo de mensajes los utiliza el “Designated Router” (DR) para encapsular paquetes multicast y enviarlos al RP, para que sean enrutados por el camino compartido.

            El DR continua enviando al RP los mensajes “Register” con paquetes multicast encapsulados hasta que recibe del RP un mensaje “Register-Stop”.

            4.8.5- Mensajes PIM Register-Stop

            Este tipo de mensajes los utiliza el “Rendevouz Point” (RP) para solicitar al “Designated Router” (DR) que detenga el envío de mensajes “Register”. Estos mensajes se envían después de que el RP forme parte del árbol de distribución junto con el DR, y además, después de comenzar a recibir tráfico multicast “nativo”, es decir, sin encapsular en mensajes “Register”.

4.8.6- Mensajes PIM RP-Reachability

            Este tipo de mensajes los envía el RP periódicamente por el árbol compartido para informar a los routers,por debajo de él en el árbol, que el RP está todavía activo y es alcanzable.

            En cada uno de los routers en el camino compartido por debajo del RP existe un contador que se refresca con estos mensajes. Cuando este contador deje de refrescarse, el router conmutará a un RP de backup.

4.9- Ejemplo del funcionamiento del PIM SM.

            El ejemplo que se muestra a continuación repasa todos los conceptos de PIM SM explicados en los apartados anteriores.

            En las siguientes páginas, describiremos los pasos y procesos que se producen en la suscripción de nuevos receptores, registro de routers intermedios, generación de tráfico multicast por las fuentes, conmutación entre los dos tipos de árboles de distribución, etc.



·         “Receptor 1” se suscribe (Join) al grupo “G” enviando un mensaje IGMP Host a su router de salida C.

·         Al recibir el mensaje IGMP, “C” crea una entrada (*, G) en su tabla de enrutamiento multicast, que tenga la interfaz hacia “Receptor 1” en su “Outgoing List” (OIF).

·         A continuación, “C” envía un mensaje de suscripción (*, G) Join hacia el punto de reunión (RP).

·         El punto de reunión, o “Rendezvous Point” (RP), recibe el mensaje de suscripción de “C” (*, G) y crea su propia entrada (*, G), en su tabla de enrutamiento multicast, que tendrá la interfaz hacia “C” en su “Outgoing List” (OIF).

·         De esta forma, se ha construido el árbol compartido para el grupo “G”

·         “Fuente 1” comienza a generar tráfico con destino al grupo “G”. (Nota: no es necesario que “Fuente 1” se suscriba al grupo “G” mediante un mensaje “IGMP Host Membership” antes de enviar tráfico al grupo “G”).

·         A continuación, “A” encapsula los paquetes multicast de “Fuente 1” en mensajes “PIM Register” y los envía como unicast al Rendezvous Point (RP).

·         El punto de reunión (RP) recibe y desencapsula los mensajes “Register”, de forma que puede apreciar que se trata de paquetes dirigidos al grupo “G”, para el cual tiene una entrada (*, G).

·         El punto de reunión (RP) envía los paquetes desencapsulados como multicast por el camino compartido.

·         Seguidamente, el RP envía un mensaje de suscripción (Join) hacia la “Fuente 1” de forma que pueda empezar a recibir paquetes “nativos” (desencapsulados) desde la “Fuente 1”.

·         Una vez que se comienza a recibir los datos de “Fuente 1” de forma nativa, el punto de reunión (RP) envía un mensaje “Register-Stop” para notificar a “A” que ya no necesita el tráfico encapsulado en registros.

·         El tráfico excede el umbral SPT y “C” comienza el proceso de conmutación al camino más corto (SPT) para la “Fuente 1”, mediante el envío de un mensaje (S, G) Join hacia “A” por el camino más corto.

·         Para reducir  el tráfico de la “Fuente 1” procedente del camino compartido (puesto que lo está recibiendo también por el camino más corto), “C” envía (S, G)RP-bit por el camino compartido. (Nota: el bit RP indica a todos los routers en el camino que esta reducción debe llegar por el RTP hasta el RP).

·         El “RP” recibe el (S, G) RP-bit Prune y retira la interfaz (hacia “C”) en la OIF de la entrada (S, G). Esto detiene el flujo del tráfico de “Fuente 1” por el camino compartido.

·         En este momento, la “Outgoing List” (OIF) del “RP” está a “Null” (siempre y cuando no existan otras ramas en el árbol compartido que quieran el tráfico de “Fuente 1”), y por lo tanto, no necesita más el tráfico de “Fuente 1”. El “RP” responde enviando Prunes hacia “Fuente1”. Esto detendrá el flujo de tráfico de “Fuente 1” hacia el “RP”.

·         El “Receptor 2” también se suscribe al grupo “G” enviando un “IGMP Host message” a “E”.

·         A continuación, ”E” crea una entrada (*, G) que tendrá en su “Outgoing Interface List” la interfaz hacia “Receptor 2”.

·         Seguidamente, “E” envía un (*, G) Join por el camino compartido hacia el punto de encuentro (RP).

·         “C” recibe el mensaje (*, G) Join procedente de “E” y añade la interfaz (hacia “E”) a la “Outgoing List” en ambas entradas (*, G) y (S, G) en la tabla de enrutamiento multicast.

(Nota: Puesto que “C” ya tenía la entrada (*, G), no es necesario enviar un mensaje (*, G) Join hacia el “RP” de nuevo.)

·         El tráfico del grupo “G” comienza a fluir por “C” y “E” hasta el “Receptor 2”.

·         “Fuente 2” comienza a generar tráfico multicast para el grupo “G”.

(Nota: De nuevo, no es necesario que “Fuente 2” se suscriba al grupo “G” mediante el envío de un mensaje IGMP, antes de generar tráfico multicast para dicho grupo.)

·         Seguidamente, “D” encapsula los paquetes multicast en mensajes PIM “Register” y los envía por unicast al punto de reunión (RP).

·         El punto de reunión (RP) recibe y desencapsula los mensajes “Register”, de forma que puede apreciar que se trata de paquetes dirigidos al grupo “G”, para el cual tiene una entrada (*, G).

·         El punto de reunión (RP) envía los paquetes desencapsulados como multicast por el camino compartido.



·         En este momento, el “RP” envía un mensaje PIM Join hacia “Fuente 2” de forma que pueda empezar a recibir paquetes “nativos” (desencapsulados) desde “Fuente 2”.

·         Los datos procedentes de la “Fuente 2” comienzan a llegar en estado nativo por el camino más corto (SPT), a través de “D”.

·         A continuación, el punto de reunión (RP) envía un mensaje “Register-Stop” para notificar a “D” que ya no necesita el tráfico multicast encapsulado en mensajes”Register”.



·         En este punto, ambos caminos, compartido (tráfico “Fuente 2”) y más corto (tráfico “Fuente 1”) se están utilizando para entregar paquetes multicast del grupo “G” a los receptores.



4.10- Configuración de PIM SM.

            Es muy fácil configurar multicast con PIM Sparse Mode, los pasos necesarios son los siguientes:

·         Añadir a la configuración el comando global: “ip multicast-routing”.

·         Añadir el comando “ip pim sparse-mode” en cada interfaz de la configuración del router para habilitar el Multicast IP utilizando PIM SM.

(ATENCIÓN: Se debe utilizar con precaución si el comando anterior no se añade a todos las interfaces del router. Se pueden producir problemas si algunos de las interfaces no están corrinedo multicast. Esto es debido a que el mecanismo RPF Check utiliza la tabla de enrutamiento unicast, para calcular la interfaz RPF. Si la interfaz RPF no está corriendo multicast, se pueden producir “errores RPF”).

·         Configurar la dirección IP del punto de reunión (RP) utilizando el comando de configuración global “ip pim rp-address ”.

ANEXO A

            A continuación podemos ver en la siguiente tabla una relación de las diversas funciones o fases de los protocolos y los mensajes utilizados en cada una de esas fases.

ANEXO B

            Este anexo contiene varios diagramas de flujo que ilustran la construcción de los árboles y la transmisión multicast. La descripción de la construcción de los árboles está fraccionada en dos partes tomando como punto de división el RP. En primer lugar podemos ver la sección entre el receptor y el RP y a continuación, el tramo entre el RP y la fuente (porque depende del primero). Por último, tenemos un ejemplo genérico de la transmisión del tráfico multicast, una vez estén construidos los árboles de transmisión.





ANEXO C

            Este anexo contiene una explicación detallada del formato de la tabla de enrutamiento multicast de un router Cisco. El formato de cada una de las entradas es el siguiente:

            ( Source / Mask_Bits, Group), Uptime / Expires, (RP), Flags

                        Incoming Interface: interface, RPF nbr xxxx

                        Outgoing Interface list:

                                   Interface, Next_hop, State / Mode, Uptime / Expires

Flags:  D  -  Dense Mode,  S  -  Sparse Mode,  C  -  Conectado,  L  -  Local,  P  -  Pruned,  R  -  RP-bit activo,  F  -  Flag Register,  T  -  SPT-bit activo,  J  -  Join SPT.

            Tiempos:   Uptime - Tiempo que lleva la entrada en la tabla.

Expires - Tiempo para borrar la entrada si no llega un refresco antes      (máximo 3 minutos).

            A continuación, se muestra un ejemplo ilustrativo:

·         Entradas (*, G) y (S, G)

(*, 225.1.2.3), 3w0d/00:02:59, RP 100.10.1.2, flags: SJ

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    Vlan209, Forward/Sparse, 3w0d/00:02:04

    Serial0/1, 100.15.3.1, Forward/Sparse, 1w6d/00:02:23

(100.10.1.1/32, 225.1.2.3), 1w6d/00:02:59, flags: CT

  Incoming interface: Vlan209, RPF nbr 0.0.0.0

  Outgoing interface list:

    Serial0/1, 100.15.3.1, Forward/Sparse, 1w6d/00:02:23

(100.10.1.2/32, 225.1.2.3), 1w6d/00:02:59, flags: CT

  Incoming interface: Vlan209, RPF nbr 0.0.0.0

  Outgoing interface list:

    Serial0/1, 100.15.3.1, Forward/Sparse, 1w6d/00:02:2

            Estas tres entradas corresponden al grupo 225.1.2.3. La primera es del tipo (*, G), es decir, de “árbol compartido”, mientras que las dos siguientes son particularizaciones (S, G) para dos fuentes diferentes, y por lo tanto, del tipo “camino más corto”.

            La primera entrada tiene activos los flags S (modo Sparse), J (Join SPT). El modo Sparse es por el tipo de protocolo PIM utilizado. El flag “J” está activo porque se ha superado el umbral SPT. El “Incoming Interface” está a null porque la máquina es el propio RP del grupo.

            En la segunda y tercera entrada están activos los flags C (Conectado) y T (SPT-bit). El flag “C” indica que la fuente está directamente conectada, y el flag “T” indica que se trata del camino más corto (SPT). En el “Incoming Interface” el vecino PIM está a cero porque la fuente está directamente conectada.
  


ANEXO D

Existe un protocolo para intercambiar multicast entre AS. Es el MSDP, Multicast Source Discovery Protocol. Hace que los diferentes RP de los AS intercambien la información de emisores y receptores multicast. No elimina la necesidad de PIM.

Permite a los ISP usar sus RP internos sin descubrir su red.Establecen una sesión TCP.

Directamente propaga la fuentes activas. Cuando un RP recibe un PIM Register (S,G) informa a sus vecinos MSDP usando un mensaje SA (Source Active) permitiendo saber a los otros AS donde están las fuetnes.
  



LABORATORIO - TOPOLOGÍA MULTICAST BÁSICO

La empresa HEINCH tiene instalado un servicio de hilo musical para sus tiendas. la emisión del programa musical se hace desde Madrid a través de MULTICAST.

En este escenario básico vamos a configurar Multicast Sparse-Mode.

Para emular multicast, lo hacemos desde una máquina virtual con Ubuntu. En este Ubuntu hemos instalado el paquete "mcsender", que envía paquetes multicast. Para recibir los paquetes usamos también una maquina virtual Ubuntu pero esta vez con el "mcfirst", que se usa para recibir los paquetes multicast. A parte, tienen instalado el programa VLC para poder enviar y recibir audio y video por multicast. En el escritorio de Madrid podéis encontrar una archivo de audio y otro de video para hacer las pruebas.

Para el enrutamiento unicast configuramos OSPF.

Imágenes:

Cisco 3600

Ubuntu - MADRID MULTICAST

Ubuntu - TARRAGONA-MULTICAST

Ubuntu - SEVILLA-MULTICAST 

Password Ubuntu: reverse

CONFIGURACIONES BÁSICA 

Para la configuración de las interfaces en Ubuntu, os remito a la explicación siguiente en el laboratorio de JCNIA. Solo tenéis que configurar la ip, la máscara y la puerta de enlace.

Los routers Cisco:

MADRID# conf t interface Loopback0  ip address 10.0.10.1 255.255.255.255 ! interface Ethernet0/0  ip address 20.0.0.1 255.255.255.252  full-duplex ! interface Ethernet0/2  ip address 80.0.0.1 255.255.255.252  full-duplex ! interface Ethernet0/3  ip address 192.168.10.1 255.255.255.0  full-duplex ! router ospf 1  router-id 10.0.10.1  log-adjacency-changes  network 10.0.10.1 0.0.0.0 area 0  network 20.0.0.0 0.0.0.3 area 0  network 80.0.0.0 0.0.0.3 area 0  network 192.168.10.0 0.0.0.255 area 0 BARNA conf t interface Loopback0  ip address 10.0.20.1 255.255.255.255 ! interface Ethernet0/0  ip address 20.0.0.2 255.255.255.252  full-duplex ! interface Ethernet0/1  ip address 20.0.21.1 255.255.255.252  full-duplex ! router ospf 1  router-id 10.0.20.1  log-adjacency-changes  network 10.0.20.1 0.0.0.0 area 0  network 20.0.0.0 0.0.0.3 area 0  network 20.0.21.0 0.0.0.3 area 0 ! TARRAGONA conf t interface Loopback0  ip address 10.0.21.1 255.255.255.255 ! interface Ethernet0/0  ip address 20.0.21.2 255.255.255.252  full-duplex ! interface Ethernet0/3  ip address 192.168.21.1 255.255.255.0  full-duplex ! router ospf 1  router-id 10.0.21.1  log-adjacency-changes  network 10.0.21.1 0.0.0.0 area 0  network 20.0.21.0 0.0.0.3 area 0  network 192.168.21.0 0.0.0.255 area 0 ! SEVILLA conf t interface Loopback0  ip address 10.0.80.1 255.255.255.255 ! interface Ethernet0/0  ip address 80.0.0.2 255.255.255.252  full-duplex ! interface Ethernet0/3  ip address 192.168.80.1 255.255.255.0  full-duplex ! router ospf 1  router-id 10.0.80.1  log-adjacency-changes  network 10.0.80.1 0.0.0.0 area 0  network 80.0.0.0 0.0.0.3 area 0  network 192.168.80.0 0.0.0.255 area 0 !

Lo primero que tenemos que hacer es habilitar MULTICAST en los routers que van a cursar este tipo de tráfico (aquí son todos, claro). Para ello:

router(config)#ip multicast-routing

Lo siguiente es configurar el protocolo PIM. Configuramos el Redevendouz Point, el RP.

router(config)#ip pim rp-address 10.0.10.1

Esto lo hacemos en todos los routers, incluido Madrid.

Comprobamos los Rp de PIM con "show ip pim rp" y no vemos nada. Esto es porque tenemos que configurar el modo en que actúa el protocolo PIM:

Configuramos el modo de PIM en las interfaces, que en nuestro caso es Sparse-Mode:

router(config-if)#ip pim sparse-mode

Esto lo hacemos en las interfaces de los routers que vayan a cursar tráfico multicast. En este laboratorio lo hacemos entonces en todas las interfaces que estén conectadas, tanto en WAN como en LAN, en todas.

Comprobamos los RP de los routers:

#show ip pim rp

El RP de Madrid es él mismo. El RP de Tarragona es Barna

Ahora vamos a comprobar la tabla de rutas multicast. Para hacerlo:

#show ip mroute

Miramos el RPF y si nos fijamos es la WAN del Peer, pero en Madrid, al ser el router que propaga al emisor aparece la dirección 0.0.0.0, pues es el mismo el que sabe llegar al emisor (192.168.10.250)

El RPF (Reverse Path Forwarding) chequea que en base a la dirección ip de origen y la interface de entrada de la petición multicast, la interface de salida para llegar por unicast a esa ip de origen sea la misma interface por la que ha entrado. Si no se cumple, fallaŕa el RPF y descarta el paquete.

Y ahora en MADRID-MULTICAST envíamos los paquetes multicast. Lo primero es saber que interface tenemos configurada. Abrimos un terminal y

Para abrir un terminal, vamos al símbolo de Ubuntu que está arriba a la izquierda y buscamos "terminal". Hacemos click para que se abra:

Ahora miramos que interface ethernet tenemos asignada. Escribimos ifconfig. Y con la "eth" que nos indique.¡Antes hemos configurado la ip! Si véis que no os coge la ip, activar y desactivar la interface en Ubuntu.

En mi caso es la eth11. Cuidado que puede cambiar. Miradlo siempre.

Y ahora envíamos tráfico multicast con "mcsender":

mcsender -t15 -ieth11 226.0.0.226:5004

La opción "-t" es para decirle el TTL (Time To Live). Aquí, el número de salto. Le pongo 15 por poner algo.

La opción "-i" es para decirle el interface.

Y luego le decimos la dirección ip y el puerto para multicast con la que va a emitir. En este caso será la 226.0.0.226 y el puerto el 5004.

Madrid empieza a lanzar tráfico al grupo 226.0.0.226 por el puerto 5004

Ahora miramos en el router de Madrid con el comando "sh ip mroute":

El tráfico entra por la e0/3, identifica el grupo 226.0.0.226

Sin embargo en la "outgoing interface" vemos que pone "Null". No hay nadie pidiendo ese tráfico. Y en los demás routers no se ve nada.

Ahora vamos a tanto a Sevilla como a Tarragona y miramos la interfaces y escribimos:

mcfirst -4 -I eth10 -t600 226.0.0.226 5004

SEVILLA: Se ven los paquete multicast recibidos. Para cortar CRTL+C.

Vamos a ver las rutas multicast:

En Madrid ahora la "outgoing interface" muestra la que va hacia Sevilla

En Sevilla se ve la ip emisora, la interface de entrada y salida

sh ip igmp membership y sh ip igmp groups 226.0.0.226

Si por ejemplo nos llaman de Tarragona y nos dicen que se han quedado sin hilo musical, después de hacer todas las pruebas de comunicación a nivel de unicast, es decir, se hace ping de IPv4 entre el emisor y receptor, una prueba que podemos hacer es configurar un grupo igmp estático en el router de Tarragona. De esta manera emulamos un JOIN hacia la fuente emisora. Así, podemos comprobar si el problema del routing multicast está en LAN, en WAN o en origen.

Creamos un grupo estático en la interface WAN, la e0/0 con el comando:

TARRAGONA(config-if)#ip igmp static-group 226.0.0.226

Vemos el árbol multicast creado en Tarragona

Documento Resumen Multicast

Documento de Cisco sobre Multicast