Un pequeño resumen sobre los modelos multicast
Podemos decir que existen actualmente 2 modelos:
ASM ( Any-Source Multicast) - RFC 1112
- Los Receivers no especifican la source (fuente del tráfico)
- Los routers aprenden la source del tráfico desde la propia source
- Soportan tráfico de una source a varios receivers y de varias source a varios receivers
- Los Receivers especifican la source de la que quieren recibir
- Los routers aprenden la source desde los receivers
- Solo soporta de una source a varios receivers.
También podemos decir que existen 2 modos:
DENSE MODE
- El tráfico inunda toda la red. Se basa en los procesos de inundación (flood) y corte (prune) del tráfico para mantener el estado (S,G) en todos los routers de la red
- Siempre construye un SPT (shortest path tree) entre la source y los receivers
- Incluye los protocolos MOSPF, DVMRP y PIM-DM
SPARSE MODE
- El tráfico solo se envía a los receivers que lo solicitan y a un RP
- El único protocolo es PIM-SM, que al inicio construye un RPT (Rendezvous Point Tree) entre la source y el receiver que mantienen un estado (*,G), pero cuando el router más cercano al receiver aprende el camino para llegar a la source, crea un SPT.
- El RP es el que conoce los grupos activos y el que informa de ellos a los receivers, así estos no necesitan conocer donde está la fuente, se lo dice el RP.
- Una vez creado el SPT, el estado (S,G) solo lo mantienen los routers del camino SPT, aunque el DR más cercano al receiver mantendrá un estado (*,G) con el RPT por si hay otros receivers que no conocen la fuente y quieren recibir tráfico.
- Es importante tener en cuenta donde situar al RP, tanto para la redundancia como para el rendimiento de la red
Nota: el router más cercano a la fuente y al receiver es denominado DR (designated router). En Junos, el DR y el RP necesitan tener activados los servicios de tunneling.
El protocolo PIM permite tanto el mode Dense como el Sparse. Permite incluso combinarlos en un modo sparse-dense, donde algunos grupo operarían en Dense con SPT y, otros en sparse con "shared tree".
Tenemos 3 métodos de elección del RP:
- BSR - Bootstrap Router
- Auto-RP - hace anuncios dinámicos
- Estático - configuración estática
Es indiferente el método que queramos darle al RP: tenemos que configurarlo.
IGMPv3. Se define en la RFC 3376 e introduce soporte para los mensajes de "report" de los grupos. Con estos mensajes, un host puede elegir qué tráfico recibir de un grupo multicast de un fuente específica (SSM). Hasta entonces, IGMPv1 y IGMPv2 solo soportaban el tráfico ASM.
Con SSM, un host identifica la dirección ip de una fuente concreta de la que quiere recibir el tráfico generando un mensaje "report" de inclusión en el grupo multicast. También genera un mensaje "report" de exclusión de la fuente de la que no quiere recibir el tráfico multicast. Es decir, si tenemos el mismo tráfico multicast que se emite desde 2 fuentes diferentes, le decimos de la que queremos el tráfico y de la que no. De esta manera se hace un poco más eficiente el tráfico multicast al poder elegir el equipo fuente, no como en las anteriores versiones donde un equipo podía recibir desde cualquier fuente que estuviera emitiendo el tráfico multicast del grupo solicitado. IGMPv3 sigue usando el mensaje de "leave" cuando quiere dejar de recibir tráfico, una característica ya introducida en IGMPv2. Con SSM podemos usar el modo "sparse-mode" sin la necesidad de un RP (Rendezvous Point)
Los mensajes report para pedir la inclusión el grupo en IGMPv3 se hacen a la dirección 224.0.0.22. Recordad que el rango reservado para SSM es el 232/8.
En Juniper, IGMP se configura bajo protocolos, obviamente. Tenemos las siguientes opciones:
Una vez llegados aquí, vamos a seguir la explicación montando un laboratorio. Por ahora configuraremos un escenario que siga el modelo ASM.
 |
| Configurado OSPF para conocer las rutas |
Nota: las SOURCES y los RECEIVERS son máquinas Unix como las del ejemplo que podéis encontrar en Multicast.
Vamos a configurar PIM con el modo DENSE e IGMP en una interface de un router Juniper. En los equipos con Junos, las interfaces que no sean Point-To-Point, si tenemos habilitado PIM o DVMRP, el protocolo IGMP se habilitará automáticamente. Es importante no habilitar IGMP en la interface "fxp0".
En todos los routers configuramos PIM en las interfaces que interconectan con otros routers y en las que dan acceso a los servidores fuente de multicast:
- set protocols pim interface ge-0/0/X.0 mode dense
Si miramos en cualquiera de los router (show pim join), podremos ver que todos han hecho un JOIN a los grupos multicast una vez configurado el protocolo PIM. Esto se debe a que como IGMP se habilita automáticamente en las interfaces, al estar emitiendo el tráfico las SOURCES y al haber configurado el modo DENSE, pues se acaban uniendo todos los routers a través de las interfaces por las que llegan hasta esas SOURCES. ¡Tenedlo en cuenta!
Pero nosotros queremos probar cómo hacer para que una interface LAN de un router se subscriba a un grupo multicast. Para ello, en las interfaces ge-0/0/0.0 de vMX-2 y vMX-9 configuramos IGMP.
- set protocols igmp interface ge-0/0/0.0 version 2
- set protocols igmp interface ge-0/0/0.0 static group 225.0.0.225
Configurar IGMP de forma estática en una interface nos sirve para probar si el tráfico multicast se recibiría correctamente a esa interface sin necesidad de que un "receiver" en esa LAN solicite el tráfico multicast conunmensaje de "Report". Además, hay veces que nos encontremos con "Receivers" que no sean capaces de mandar ese mensaje de report y, así estaríamos enviándoselo.
Comprobamos si funciona nuestra configuración:
 |
| show igmp group |
Nota: También se ven los grupos multicast dinámicos que usan los diferentes protocolo que tenemos configurados.
 |
| show pim neighbors: vecinos PIM |
 |
| show igmp interfaces |
 |
| show pim join |
Ahora vemos que el router vMX-9 está subscrito al grupo 225.0.0.225. Vemos cuál es la fuente que nos sirve el tráfico (192.168.225.10), el modo (dense) y la interface de salida o upstream para llegar a esa fuente (ge-0/0/8.0).
Ahora vamos a subscribir vMX-9 también al grupo 226.0.0.226:
- set protocols igmp interface ge-0/0/0.0 static group 226.0.0.226
Vemos que está subscrito a los 2 grupos, y al 226.0.0.226, como tiene dos SOURCES diferentes enviando el mismo tráfico, pues se subscribe a los dos. Esto no es del todo eficiente, ya que tenemos a la fuente SOURCE-226-A a solo dos saltos y no queremos recibir el tráfico de SOURCE-226-B. Para remediar esto, vamos a configurar IGMPv3:
- set protocols igmp interface ge-0/0/0.0 version 3
- set protocols igmp interface ge-0/0/0.0 static group 226.0.0.226 source 192.168.126.10
Si esperamos un tiempo, veremos que se vuelven a ver los 3 grupos subscritos. La configuración que ahora tenemos en vMX-9 es la siguiente:
root@vMX-9> show configuration protocols igmp
interface ge-0/0/0.0 {
version 3;
static {
group 225.0.0.225;
group 226.0.0.226 {
source 192.168.126.10;
}
}
}
Nota: para que el uso de IGMPv3 sea eficiente del todo, lo suyo es usar el modo Sparse, ya que el modo DENSE hace que el tráfico llegue a todos los routers y que estos se subscriban. Si miramos el resto de routers, también tendrán creado el árbol de PIM.
Por eso, para tener mayor control de nuestra red y tráfico multicast, vamos configurar en modo SPARSE.
Cuando configuramos este modo, necesitamos que exista un RP.
Ya sabemos que hay 3 maneras de configuarlo: estático, auto y BSR. Vamos a explorar las 3.
Lo primero es cambiar en las interfaces de nuestros routers al modo sparse en la configuración del protocolo PIM:
- set protocols pim interface ge-0/0/X.0 mode sparse
Configuración estática de RP
Vamos a elegir como RP al router vmX-5. En él tenemos que configurar:
- set protocols pim rp local address 5.5.5.5
- set protocols pim rp local group-ranges 224.0.0.0/4
En el resto de routers:
- set protocols pim rp static address 5.5.5.5
Podríamos configurar "group-ranges" específicos si tuvieramos diferentes RP para diferentes grupos multicast. Si no se especifican, por defecto usa 224.0.0.0/4.
Comprobamos en los routers que tienen a vMX-5 como RP.
 |
| show pim rps |
Y también que se han subscrito al grupo:
 |
| show pim join y show igmp group |
Configuración BSR de RP
Se desarrolla enla RFC 5059. Es un modo de elegir el RP cuando tenemos varios candidatos a ello.Todos los routers en el dominio PIM envían/reciben mensajes BSR y necesitan soportar PIMv2, pero ello no conlleva que se necesite el modo dense.
Solo un BSR es elegido dentro del dominio PIM: el criterio de elección del BSR se basa primero en la prioridad más alta (como en OSPF, si la prioridad es 0 ese router no es elegible para ser BSR). Si hay empate entre routers, ganará el que tenga la dirección ip más alta en loopback. Si hay varias direcciones loopbacks configuradas y ninguna tiene la opción de "primary", gana la más baja. Que ganas de liarnos, pero bueno, esto es así de absurdo...
Una de las ventajas de BSR es que, aunque solo puede haber uno activo a la vez, podemos tener varios equipos configurados con diferentes prioridades para ofrecernos redundancia del servicio en caso de fallo del principal.
Al menos debemos tener un BSR y un RP para que el dominio multicast funcione correctamente. Estos dos roles los puede cumplir el mismo equipo.
Una vez que el BSR es conocido por todo el dominio, los candidatos a RP propagan a través de unicast un mensaje "C-RP-adv". Estos mensajes informan al BSR que grupos multicast soportan, el hold time y la prioiridad. Esta información es fundamental en caso de caída del RP para poder cambiar a otro rápidamente.
Con todos los mensajes "C-RP-adv", el equipo que hace de BSR genera un mensaje conocido como RP-set, que contiene todos los RP que tenemos en el dominio que acaba enviando a todo el dominio en un mensaje bootstrap.
El proceso se completa cuando el mensaje RP-set se propaga por todo el dominio. En este punto, los routers pueden elegir el RP al que conectarse. Pueden conectarse a diferentes RP para diferentes grupos.
Podemos decir que con esta configuración tenemos 3 tipos de router:
- RP's
- Bootstrap
- Resto de routers
Para configurar Bootstrap simplemente elegimos el router que queremos que cumpla esta función (en el ejemplo es vMX-3) y le configuramos:
- set protocols pim rp bootstrap-priority X
En los equipos que cumplen la función de RP los dejamos igual y, en el resto de equipos no tenemos que configurar nada, solo deben tener las interfaces en modo Sparse excepto aquellas que necesiten IGMP porque tienen receivers en la LAN.
Para comprobar:
- show pim bootstrap
Ahora tenemos nuestro RP en el dominio y nos hemos ahorrado la configuración estática en cada router.
Si tuviéramos más RP configurados en nuestro dominio los veríamos todos:
Configuración de Auto-RP
Este modo también permite a los router aprender quien es el RP de manera dinámica. SIn embargo necesita que se use el modo DENSE para el tráfico de control que envía los anuncios del RP al grupo 224.0.1.39 y los discovery de los grupos al 224.0.1.40.
La gran ventaja es la posibilidad de tener varios candidatos a RP y de esta manera tener un backup por si cae el RP elegido. Por esto, debe haber un router que haga la función de mapear los grupos a los RP, al que denominamos "Mapping Agent" (funció parecida a la del router Bootstrap). Esto nos limita a que haya un único RP por cada grupo multicast.
Podemos decir que con esta configuración tenemos 3 tipos de router:
- RP's
- Mapping Agent
- Resto de routers
Para configurar Auto-RP las interfaces deben estar en modo sparse-dense y debemos configurar los grupos del tráfico de control:
- set protocols pim interface X sparse-dense
- set protocols pim dense-groups 224.0.1.39/32
- set protocols pim dense-groups 224.0.1.40/32
Ahora, en los equipos que sean RP's:
- set protocols pim rp auto-rp announce
- set protocols pim rp local address X.X.X.X - esto es igual que siempre
- set protocols pim rp local group-ranges X - esto es igual que siempre
En el equipo que sea el Mapping Agent:
- set protocols pim rp auto-rp mapping
En el resto de routers:
- set protocols pim rp auto-rp discovery
 |
| show pim rps extensive |
Si miramos en los RP, veremos que aprende el RP por dos vías: la local y la auto.
Y también vemos que aprende que hay otro RP, el 6.6.6.6, a través de la función auto-rp.
Hasta aquí, todas estas configuraciones entran dentro del modelo ASM. Vamos a hablar del otro modelo, del SSM.
Aunque se sigue usando los mensaje de Join y los de Prune, en SSM se introducen nuevos términos
ASM
|
SSM
|
G
|
S,G
|
GROUP
|
CHANNEL
|
JOIN, LEAVE
|
SUBSCRIBE, UNSUBSCRIBE
|
224/4 excluido el 232/8
|
224/4, solo garantía con el 232/8
|
El grupo 232/8 se trata de manera diferente:
- El router más cercano (DR) al receviver nunca inicia con un mensaje (*,G) para el grupo 232/8
- Los router del camino nunca propagan un mensaje Join (*,G) para el 232/8
- Los RPs no aceptan mensajes de PIM Register o Join (*,G) para el 232/8
- El router más cercano a la fuente (DR) no envía PIM Register al RP para la el grupo 232/8
Para que funcione correctamente SSM se necesita:
- Los receiver y los querier deben soportar IGMPv3. En Juno podemos crear un "ssm-map" para evitar esta necesidad. Esto mapea un grupo a una fuente estática)
- No se necesita un RP porque solo se unsa SPT (Shortest Path Tree). Se informa directmente de la fuente a la que queremos conectarnos. ASM y SSM pueden convivir juntos en una red.
- Múltiples fuentes pueden compartir grupo sin interferir unas con otras
Por lo tanto, el estado de (S,G) se establece en todos los routers a lo largo del camino.
Como no necesitamos RP, solamente configuramos las interfaces en modo sparse y las interfaces LAN con la versión 3 de IGMP.
Para que una interface LAN se una al grupo basta con añadir la fuente:
- set protocols igmp interface ge-0/0/0.0 static group 225.0.0.225 source 192.168.225.10
Como ya hemos dicho, si tenemos routers que no soportan IGMPv3, podemos crear un mapeo en 3 pasos:
Creamos una política:
root@vMX-9# run show configuration policy-options
policy-statement Grupo_Multicast_225 {
term 1 {
from {
route-filter 225.0.0.225/32 exact;
}
then accept;
}
}
Creamos el mapeo:
root@vMX-9# run show configuration routing-options
router-id 9.9.9.9;
multicast {
ssm-map Grupo_225 {
policy Grupo_Multicast_225;
source 192.168.225.10;
}
}
Lo aplicamos a la interface:
root@vMX-9# run show configuration protocols igmp
interface ge-0/0/0.0 {
version 2;
ssm-map Grupo_225;
}
No hay comentarios:
Publicar un comentario