Introducción
Este artículo continúa la serie sobre multidifusión IP. Veremos cómo funciona la multidifusión IP básica. Luego veremos cómo funciona el modo denso de PIM (PIM-DM), cómo configurarlo y cómo solucionarlo. Esto nos servirá para entrar en calor antes de abordar el modo PIM Sparse, algo más complejo y escalable, en un artículo posterior.
El artículo inicial sobre multidifusión contiene enlaces a los principales grupos de trabajo del IETF al final del mismo. Se puede encontrar en The Protocols of IP Multicast.
Understanding IP Multicast Forwarding
El propósito de un protocolo de enrutamiento multicast es permitir que los routers trabajen juntos para entregar eficientemente copias de paquetes multicast a los receptores interesados. En el proceso de hacer esto, el protocolo de enrutamiento de multidifusión probablemente también proporciona un mecanismo para que los vecinos descubran y rastreen los routers vecinos que también utilizan el protocolo de enrutamiento de multidifusión.
Como vimos en el último artículo, aquellos ordenadores interesados en recibir un flujo de paquetes de multidifusión utilizan IGMP para notificar a los routers adyacentes. Los routers utilizan entonces el protocolo de multidifusión para organizar el envío de una copia del flujo de paquetes de multidifusión para que puedan reenviarlo a la LAN que contiene al receptor. No hemos mencionado lo que ocurre en el extremo de la fuente del flujo de paquetes. En la multidifusión IP, no hay ningún protocolo para que la fuente se comunique o se registre o notifique a los routers. La fuente simplemente comienza a enviar paquetes de multidifusión IP, y depende de los routers vecinos el hacer lo correcto. (Lo que sea «lo correcto» depende del protocolo de enrutamiento de multidifusión).
La siguiente imagen muestra una fuente enviando un paquete de multidifusión en rojo, y los routers descendentes duplicando el paquete e inundándolo a otros routers y, en última instancia, a todos los segmentos de la LAN. Como veremos en breve, este es el comportamiento inicial (y periódico) del protocolo de enrutamiento de multidifusión independiente del protocolo (PIM) de Cisco, cuando actúa en modo denso.
Nota en la imagen anterior que las flechas azules reenvían las copias de los paquetes de multidifusión de forma organizada. Puede haber dos copias de cada paquete que llegan a algunos de los routers o segmentos LAN. Pero los routers no reenvían los paquetes «hacia atrás». Esto es algo bueno: piensa en lo que podría ocurrir si el router E reenviara una copia del paquete que recibió de C al router B. ¿Renviaría entonces B el paquete a A, que podría reenviarlo a C, y así sucesivamente, en un bucle de reenvío? Esto sería una especie de equivalente en la Capa 3 de lo que ocurre en la Capa 2 cuando Spanning Tree está deshabilitado en una topología de bucle: una buena forma de desperdiciar mucho ancho de banda y capacidad de los routers.
Para evitar los bucles de reenvío de multidifusión, la multidifusión IP siempre realiza una comprobación RPF, de la que hablaremos en breve.
Además de la comprobación RPF, los protocolos de enrutamiento de multidifusión como PIM también pueden funcionar para evitar la ineficiencia. Por ejemplo, el router E de la imagen no necesita recibir dos copias de cada paquete de multidifusión (una de B y otra de C).
El protocolo de enrutamiento de multidifusión determina qué interfaces deben enviar copias (o no enviarlas). Como sugiere la imagen anterior, el reenvío de multidifusión se produce a lo largo de árboles lógicos, rutas de ramificación a través de la red. Toda la información de reenvío de multidifusión se almacena en la tabla de estado de multidifusión, que algunos llaman tabla de enrutamiento de multidifusión. Esta información se puede ver con el comando muy útil, show ip mroute. Echemos un breve vistazo a la salida de ejemplo del comando show ip mroute (con el modo PIM denso en ejecución).
Router# show ip mroute 233.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit setTimers: Uptime/ExpiresInterface state: Interface, Next-Hop, State/Mode(*, 233.1.1.1), uptime 0:57:31, expires 0:02:59, RP is 0.0.0.0, flags: DC Incoming interface: Null, RPF neighbor 0.0.0.0 Outgoing interface list: Ethernet0, Forward/Dense, 0:57:31/0:02:52 FastEthernet1, Forward/Dense, 0:56:55/0:01:28 FastEthernet2, Forward/Dense, 0:56:45/0:01:22(172.16.16.1/32, 233.1.1.1), uptime 20:20:00, expires 0:02:55, flags: C Incoming interface: FastEthernet1, RPF neighbor 10.20.30.1 Outgoing interface list: Ethernet0, Forward/Dense, 20:20:00/0:02:52
Para entender esto, tenga en cuenta que las direcciones que comienzan con 224-239 son direcciones o grupos de multidifusión IP. (El grupo se refiere al grupo de receptores para esa dirección de destino multicast).
La entrada que empieza por (*, 233.1.1.1) es una entrada de árbol multicast compartido, a veces denominada entrada (*, G). (G aquí es sólo 223.1.1.1). PIM-DM no utiliza estas entradas para el reenvío de paquetes, pero sí enumera las interfaces con un papel en la multidifusión (receptor IGMP conocido o vecino PIM) como interfaces de salida bajo tales entradas.
La entrada que comienza con (172.16.16.1, 233.1.1) se conoce como una entrada (S, G). S es fuente, G es grupo. Si lo prefieres, piensa en esto como fuente y destino en la cabecera IP (ya que es donde realmente aparecen en los paquetes). Esta entrada es un árbol de multidifusión específico de la fuente para un grupo de multidifusión concreto. Por lo general, habrá una entrada de este tipo para cada fuente y grupo. Observe que el siguiente salto de enrutamiento unicast aparece como el vecino RPF, y la interfaz entrante es la interfaz RPF, la interfaz utilizada por el enrutamiento unicast hacia la fuente 172.16.16.1. La lista de interfaces de salida muestra que cualquier paquete de 172.16.16.1 con destino 233.1.1.1 recibido en FastEthernet1 se copiará fuera de Ethernet0.
Puede dibujar el árbol de reenvío de multidifusión para un determinado (S, G) para la solución de problemas. Para ello, ejecute el comando show ip mroute en cada router. Tome una copia de su mapa de red y dibuje una flecha de salida para cada interfaz en la lista de interfaces de salida («OIL» u «OILIST»). Terminará con un diagrama parecido al de la imagen anterior.
Banderas de estado que podría ver en la salida de PIM-DM show ip mroute:
- D = Modo denso. Aparece sólo en las entradas (*, G). El grupo está operando en modo Dense.
- C = Host directamente conectado (¡IGMP!)
- L = Local (El router está configurado para ser miembro del grupo multicast).
- P = Pruned (Todas las interfaces OILIST configuradas en Prune). El router generalmente envía Prune a su vecino RPF cuando esto ocurre.
- T = Reenvío a través de Shortest Path Tree (SPT), indica al menos un paquete recibido / reenviado.
- J = Join SPT. Siempre en la entrada (*,G) en PIM-DM, no significa mucho.
¿Qué es la comprobación RPF, y por qué?
El reenvío multicast de IP siempre realiza una comprobación RPF. RPF significa Reverse Path Forwarding. El objetivo de la comprobación RPF es intentar evitar un bucle de reenvío de paquetes multicast de forma sencilla. Para cada flujo de multidifusión, el router de multidifusión comprueba la dirección de origen, qué dispositivo envió la multidifusión. A continuación, busca el remitente en la tabla de enrutamiento de unicast y determina la interfaz que utilizaría para enviar paquetes de unicast a la fuente de multicast. Esa interfaz es la interfaz RPF, aquella en la que el router «espera» recibir multidifusiones. Piensa en ella como la interfaz «oficialmente aprobada» para recibir multicasts de esa fuente en particular. El router almacena la interfaz RPF como parte de la información de estado de multidifusión para esa fuente particular y ese destino (grupo) de multidifusión particular.
Cuando el router recibe un paquete de multidifusión, el router rastrea la interfaz por la que entró el paquete. Si el paquete es el primer paquete de una nueva fuente, se determina la interfaz RPF y se almacena en la tabla mroute, como se acaba de discutir. En caso contrario, el router busca la fuente y el grupo multicast en la tabla mroute. Si el paquete fue recibido en la interfaz RPF, el paquete es copiado y reenviado en cada interfaz de salida listada en la tabla mroute. Si el paquete se recibió en una interfaz no RPF, se descarta. Si el router fuera una persona, esto sería el equivalente a «¿Para qué me envía esto esa persona? Deben estar confundidos, voy a ignorar lo que me acaban de enviar»
El router tampoco envía una copia de un paquete de vuelta por la interfaz por la que entró (la interfaz RPF). En otras palabras, incluso si el router vecino de la interfaz RPF solicitara de alguna manera que se le enviaran copias de un flujo de multidifusión, el router no añadirá la interfaz RPF a la lista de interfaces de salida que reciben copias del flujo de multidifusión. Esto protege contra cualquier tipo de error de protocolo que haga que dos vecinos entren en un bucle de reenvío de multidifusión apretado.
El router E también está probablemente ignorando uno de los dos flujos de paquetes, basado en si B o C está conectado a la interfaz RPF. Incluso con rutas de igual coste, normalmente sólo se elige una interfaz como interfaz RPF. Así que si usted tiene dos enlaces que conectan dos routers, sólo uno será típicamente utilizado para la multidifusión de cualquier subred de origen.
Ver sin embargo el comando ip multicast multipath (nuevo en Cisco IOS Versión 12.0(8) T, 12.0(5) S). Con este comando, utilizado correctamente, puede haber equilibrio de carga para diferentes fuentes para un grupo de multidifusión particular. Dado que esto es por fuente y no por flujo, realmente se convierte en algo más parecido a la división de la carga. Puede que no termine siendo muy equilibrado.
El equilibrio de carga del tráfico para un flujo de paquetes (una fuente y un grupo) a través de dos enlaces entre dos routers también se puede hacer utilizando túneles GRE entre interfaces de loopback, aunque podría preocuparse por las implicaciones de rendimiento de hacer esto con un flujo de gran ancho de banda.
Por cierto, esto también nos dice cómo dirigir la multidifusión IP a través de enlaces de nuestra elección. Controlamos a dónde va el tráfico multicast controlando la comprobación RPF. Si un router no aprende rutas hacia una fuente multicast en alguna interfaz, entonces esa interfaz no será la interfaz RPF. Así que con los protocolos de vector distancia y la «inanición de ruta» (no anunciar una ruta a un vecino), podemos dirigir la multidifusión.
Veremos más adelante que cualquier injerto o unión PIM se envía por la interfaz RPF, de vuelta hacia la fuente (o RP, en el modo PIM Sparse). Al controlar dónde tiene lugar esta actividad, controlamos en qué enlaces se reenvía la multidifusión. Las entradas mroute estáticas (rutas estáticas de vuelta a la fuente para propósitos de comprobación RPF multicast) son otra forma de dirigir el tráfico multicast. Si / cuando hablemos de MBGP Multicast (Multiprotocolo BGP para Multicast), veremos que MBGP también nos proporciona una forma de dirigir o controlar los enlaces utilizados por el tráfico multicast. También hay que tener en cuenta que si la interfaz RPF no tiene habilitada la multidifusión IP, entonces en efecto el router está esperando paquetes donde no los recibirá. La interfaz RPF debe ser siempre una en la que esté habilitada la multidifusión IP.
Modo denso de PIM – Visión general
La multidifusión independiente del protocolo tiene dos modos, el modo denso y el modo disperso. Este artículo sólo tiene espacio para cubrir el primero. Llegaremos a PIM-SM en el próximo artículo.
El modo denso de PIM (PIM-DM) utiliza un enfoque bastante simple para manejar el enrutamiento de multidifusión IP. La suposición básica detrás de PIM-DM es que el flujo de paquetes multicast tiene receptores en la mayoría de los lugares. Un ejemplo de esto podría ser una presentación de la empresa por parte del director general o el presidente de una empresa. Por el contrario, el modo PIM Sparse (PIM-SM) asume que hay relativamente menos receptores. Un ejemplo sería el vídeo de orientación inicial para los nuevos empleados.
Esta diferencia se manifiesta en el comportamiento y mecanismos iniciales de los dos protocolos. PIM-SM sólo envía multicasts cuando se le solicita. Mientras que PIM-DM comienza inundando el tráfico multicast, y luego lo detiene cada enlace donde no es necesario, utilizando un mensaje Prune. Pienso en el mensaje Prune como un router que le dice a otro «no necesitamos esa multidifusión por aquí ahora mismo».
En versiones anteriores de Cisco IOS, PIM-DM volvía a inundar todo el tráfico de multidifusión cada 3 minutos. Esto está bien para la multidifusión de bajo volumen, pero no para los flujos de paquetes de multidifusión de mayor ancho de banda. Las versiones más recientes de Cisco IOS soportan una nueva característica llamada PIM Dense Mode State Refresh, desde 12.1(5)T. Esta función utiliza mensajes de actualización de estado PIM para refrescar el estado Prune en las interfaces salientes. Otra ventaja es que los cambios de topología se reconocen más rápidamente. Por defecto, los mensajes de actualización del estado PIM se envían cada 60 segundos.
Considere los routers E y F en la imagen anterior. Cuando dos routers PIM-DM se conectan a una LAN, verán los paquetes multicast del otro. Uno debe reenviar los paquetes a la LAN, y el otro no. Ambos envían mensajes Assert. La mejor métrica de enrutamiento gana, con la dirección IP más alta como desempate. Si utilizan diferentes protocolos de enrutamiento, un esquema de métrica de enrutamiento ponderado, algo así como la distancia administrativa, establece qué enrutador debe ser el Reenviador (reenviando los paquetes de multidifusión a la LAN). El Forwarder puede ser silenciado por un Prune de un router descendente sin receptores, si tampoco hay receptores en el segmento LAN. Los routers descendentes pueden tener que ajustar su vecino RPF, para reflejar el ganador del proceso Assert.
Para repetirlo con todo detalle: cuando se recibe tráfico multicast en una interfaz no RPF, se envía un mensaje Prune, siempre que la interfaz sea punto a punto. Estos mensajes Prune están limitados en cuanto a la velocidad, para asegurarse de que el volumen de los mismos (potencialmente, uno por cada multidifusión recibida) no cause más problemas.
Si la interfaz no RPF es una LAN, se envía un mensaje Assert. Los routers no-Forwarder envían entonces un Prune en su interfaz RPF si no necesitan el flujo multicast. Sólo se envía un Prune de este tipo, en el momento de la transición a no tener interfaces en la lista de interfaces salientes (OILIST). El receptor del Prune de la LAN retrasa su actuación durante 3 segundos, de manera que si otro router de la LAN todavía necesita el flujo multicast, puede enviar un mensaje PIM Join para contrarrestar (cancelar) el Prune. («¡Oye, ese router no lo necesita, pero yo sí!»)
Supongamos que un router ha Pruned, y algún tiempo después un receptor solicita el flujo multicast con un mensaje IGMP. El router entonces envía un mensaje Graft. En efecto, «oye, necesito ese flujo de multidifusión por aquí ahora».
La siguiente imagen ilustra esto, es cierto que en forma algo comprimida.
Explicación de la imagen:
(1), tal vez el router E elige a B como su vecino RPF, basado en el enrutamiento unicast de vuelta a la fuente. Entonces E recibe un paquete multicast en la interfaz punto a punto de C. Envía un Prune de tasa limitada a C.
(2), los routers E y F en la LAN intercambian paquetes Assert, cuando E o F ven el multicast reenviado por el otro de los dos. Supongamos que E gana, basándose en la métrica de enrutamiento unicast o en la dirección. Entonces F sabe que no debe reenviar multidifusiones en la LAN. Tenga en cuenta que G y H no están involucrados, ya que la Ethernet es su interfaz RPF.
(3), suponga que el router G no tiene receptores aguas abajo. Puede entonces enviar un LAN Prune al Forwarder de la LAN, el router E.
(4), si el router H tiene receptor(es) local(es) o de bajada, lo contrarresta con un LAN Join.
(5), supongamos que el router D no tiene receptores locales o de bajada y envía un Prune a B. Supongamos que algún tiempo después uno de los PC’s a su derecha le envía un mensaje IGMP para el mismo grupo multicast. El router D puede entonces enviar un PIM Graft a B, pidiendo a B que vuelva a enviarle el grupo multicast especificado.
Protocolo PIM y tipos de paquetes
PIM es un protocolo de enrutamiento completo, con varios tipos de mensajes. No voy a zumbar una y otra vez sobre los diferentes mensajes. Pero creo que vale la pena echarle un breve vistazo, ya que nos dice un poco sobre el protocolo.
PIM utiliza mensajes Hello para descubrir vecinos y formar adyacencias. El Hello se envía a la dirección multicast local All-PIM-Routers, 224.0.0.13, cada 30 segundos (PIMv1 utiliza AllRouters, 224.0.0.2). Cada LAN tiene un PIM Designated Router (DR), utilizado en el modo PIM Sparse. También es el Querier IGMPv1: la dirección IP más alta de la LAN. El comando show ip pim neighbor muestra los vecinos y la información de adyacencia y temporización.
Aclaración añadida 12/11/2004: IGMP querier y Designated Router son los dos roles en cuestión. Ver aquí.
En la versión 1 de IGMP, «El DR es responsable de las siguientes tareas:
- Enviar mensajes de registro PIM y de unión y poda PIM hacia el RP para informarle sobre la pertenencia al grupo de hosts.
- Enviar mensajes de consulta de hosts IGMP». El IGMP querier se elige por la IP más baja de la LAN. PIM selecciona el DR por la IP más alta de la LAN, para reenviar los multicasts a la LAN. (Esto descarga el trabajo).
PIM también tiene un mensaje Join/Prune, utilizado como se describe arriba. También hay mensajes Graft y Graft ACK, lo que nos indica que el Graft se hace de forma fiable (¿a diferencia del mundo real?).
Y está el mensaje PIM Assert.
PIM-SM tiene 3 tipos de mensajes más: Register, Register-Stop, y RP-Reachability (no en PIMv2).
Configuración del modo denso PIM
La configuración de PIM-DM es francamente fácil en comparación con todo lo anterior.
Globalmente, habilite el enrutamiento de multidifusión con el comando:
ip multicast-routing
Después, en cada interfaz que desee participar en la multidifusión, habilite la multidifusión IP y el PIM con el comando de interfaz:
interfaz …
ip pim dense-modeEn realidad, es mejor práctica configurar el modo sparse-dense:
interfaz …
ip pim sparse-dense-modeLa razón es que esto le permite simplemente migrar algunos o todos los grupos de multidifusión al modo Sparse, haciendo que el router conozca un punto de encuentro. E incluso se puede hacer esto sin reconfigurar un montón de routers o interfaces de router.
Se pueden configurar redes stub para multicast IP simple. La idea es no ejecutar PIM a partes stub de la red, como pequeños sitios remotos, por simplicidad. Esta es una idea particularmente buena con routers que no están bajo tu control: no quieres que compartan el enrutamiento multicast con tus routers. También elimina la inundación de PIM-DM a dichos routers (con versiones anteriores de Cisco IOS).
Para configurar la multidifusión stub, configure
ip igmp helper-address a.b.c.d
en cualquier interfaz LAN del router stub con potenciales receptores de multidifusión. La dirección a.b.c.d es la dirección del router central que habla PIM. En el router central, se configura un filtro para sintonizar cualquier mensaje PIM que el vecino stub pueda enviar, con:
ip pim neighbor-filter access-list
Vea también la Guía de Comandos en la URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .
Hay varios comandos show para ayudar a solucionar problemas de multidifusión IP. Los que más me gustan:
- show ip mroute
- show ip pim interface
- show ip pim neighbor
- show ip rpf
Como el espacio es reducido, le remitiré a la Referencia de Comandos para los ejemplos.
Una nota de solución de problemas: si usted tiene un gran ancho de banda de multidifusión en su red, asegúrese de utilizar el Prune State Refresh en las nuevas versiones de Cisco IOS si está utilizando el modo disperso-denso. Me preocupa que los routers «olviden» que tienen un RP y vuelvan al modo denso, con inundaciones periódicas. Esto podría ser una ocurrencia accidental rara, pero podría realmente arruinar tu mañana. También puede considerar las técnicas de robustez del RP, un tema para nuestro posterior artículo sobre PIM-SM o Punto de Encuentro.
En Conclusión
El libro recomendado para un montón de temas de multidifusión: Developing IP Multicast Networks: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.
Otro enlace extremadamente bueno sobre multicast de Cisco se puede encontrar aquí.
Siguiente artículo: escalando con PIM Sparse Mode.