Post on 19-Jul-2015
Introducción
¿Qué es Multicast?
Es un protocolo que permite la transmisión de datos desde una fuente hacia varios destinos simultáneamente, generando una sola copia de la información, la cual es replicada bajo un esquema tipo árbol según se necesite.
Características principales de Multicast
• Protocolo basado en la RFC 1112 (Host extensions for IP Multicasting)
• La topología formada por los caminos que el tráfico Multicast atraviesa es representada por “árboles” (trees)
• Las fuentes del tráfico se identifican con su dirección IPv4 convencional, mientras que los destinos se agrupan en direcciones IPv4 de Clase D (224.0.0.0/4)
• Cada grupo Multicast corresponde a un tipo de contenido específico.
• Cualquier host interesado en recibir un contenido específico, debe unirse (join) al grupo Multicast correspondiente a dicho contenido.
Funcionamiento a grandes rasgos
Arquitectura y funcionamiento
2. IGMP “JOIN” A
GRUPO, HACIA
FUENTE DE
TRÁFICO
3. PIM “JOIN” A
GRUPO, HACIA
FUENTE DE
TRÁFICO
1. FUENTE
ENVÍA
CONTENIDO
A DIRECCIÓN
DEL GRUPO
4. ENVÍO DE
TRÁFICO
Funcionamiento a grandes rasgos
Arquitectura y funcionamiento
2. IGMP “LEAVE”
A GRUPO,
HACIA
FUENTE DE
TRÁFICO
3. PIM “PRUNE” A
GRUPO, HACIA
FUENTE DE
TRÁFICO
Direccionamiento IP Multicast
Arquitectura y funcionamiento
224 0 0 0 11100000.00000000.00000000.00000000DESDE
239 255 255 255 11101111.11111111.11111111.11111111HASTA
Los grupos Multicast comprenden la Clase D de IPv4: 224.0.0.0/4
Las direcciones son asignadas por IANA de la siguiente forma:
• 224.0.0.0/8 – Bloque reservado para protocolos de control que utilizan Multicast para enviar sus mensajes. Ejemplos.-
• 224.0.0.1 – “All Multicast Systems on subnet”
• 224.0.0.2 – “All routers on subnet”
• Protocolos de enrutamiento: OSPF, EIGRP, RIP, LDP, etc.
• 224.0.1.0 a 238.255.255.255 – “Global Scope” – asignadas en demanda para Multicast público.
• 239.0.0.0 a 239.255.255.255 – “Limited Scope” – asignadas en demanda para Multicast privado.
• 239.255.0.0/16 – “Site-local Scope” – para cada sede organizacional.
• 239.192.0.0/14 - “Organizational-local Scope” – para toda la organización.
Direccionamiento MAC Multicast
Arquitectura y funcionamiento
Las direcciones destino IP Multicast se mapean a direcciones destino MAC Multicasten una red Ethernet, de la siguiente forma:
00000001.00000000.01011110.00000000.00000000.00000000DESDE 01 00 5E 00 00 00
HASTA 01 00 5E 7F FF FF 00000001.00000000.01011110.01111111.11111111.11111111
Los primeros 25 bits son fijos (01-00-5E mas un bit ‘0’), y los 23 restantes son copiados directamente de los 23 bits menos significativos de la dirección IP clase D.
Por ejemplo.-
224.10.10.1
los 23 bits menos significativos son: 0001010.0001010.00000001
al unirse con los de Multicast forman: 01-00-5E + 00001010.00001010.00000001
La dirección MAC resultante es: 01-00-5E-0A-0A-01
IGMP – Internet Group Management Protocol
Arquitectura y funcionamiento
Es un protocolo que permite a los hosts unirse a grupos Multicast para recibir contenidos. Los mensajes son intercambiados entre los hosts (PC, MAC, etc) y los routers directamente conectados.
• RFC 1112 IGMPv1 – obsoleto
• RFC 2236 IGMPv2 – optimizaciones para abandono de
grupos, reportes específicos y temporizadores.
• RFC 3376 IGMPv3 – optimizaciones para que el host
especifique fuentes de tráfico Multicast.
IGMPv2
Arquitectura y funcionamiento
1. Unión al grupo – el host envía un IGMP Report no solicitado a la dirección 224.0.0.1.
REPORT
Host - 1.1.1.1
Group - 225.1.1.1
Host - 1.1.1.1
Group - 225.1.1.1
IGMPv2
Arquitectura y funcionamiento
1. Unión al grupo – el host envía un IGMP Report no solicitado a la dirección 224.0.0.1.
2. Mantenimiento del grupo – el router envía IGMP Queries cada 60 segundos (por defecto) a la dirección 224.0.0.1, al que los hosts responden con un GroupMembership Report confirmando su pertenencia a los grupos.- Sólo un router hace los Queries por subred, el de menor dirección IP (“Querier”)- Sólo un host responde los Reports por grupo, el que lo hizo primero.
REPORT
QUERYQUERY
Host - 1.1.1.1
Group - 225.1.1.1
Host - 1.1.1.1
Group - 225.1.1.1
IGMPv2
Arquitectura y funcionamiento
1. Unión al grupo – el host envía un IGMP Report no solicitado a la dirección 224.0.0.1.
3. Abandono del grupo – el host envía un IGMP Leave a 224.0.0.2, al que el “Querier” responde con un Query específico enviado al grupo para saber si existe algún otro host aún interesado en el mismo. Si nadie responde, se deja de enviar tráfico al grupo.
2. Mantenimiento del grupo – el router envía IGMP Queries cada 60 segundos (por defecto) a la dirección 224.0.0.1, al que los hosts responden con un GroupMembership Report confirmando su pertenencia a los grupos.- Sólo un router hace los Queries por subred, el de menor dirección IP (“Querier”)- Sólo un host responde los Reports por grupo, el que lo hizo primero.
LEAVE
Host - 1.1.1.1
Group - 225.1.1.1
Host - 1.1.1.1
Group - 225.1.1.1
QUERYQUERY
IGMPv3
Arquitectura y funcionamiento
IGMPv3 funciona de la misma forma que IGMPv2, excepto por las siguientes diferencias:
• Los reportes contienen mensajes INCLUDE o EXCLUDE, para
incluir o excluir fuentes específicas al unirse a los grupos. Esto
permite al host escoger desde qué fuentes específicas quiere
recibir el tráfico para cada grupo.
• Los reportes de cada host van a la dirección 224.0.0.22 (IGMPv3),
y es procesada por los routers que tienen IGMPv3 habilitado.
• Al momento en que el router “Querier” envía una Query para
mantener las pertenencias a los grupos, cada host envía su
mensaje Report independientemente.
IGMP Snooping
Arquitectura y funcionamiento
En redes de capa 2, los switches por defecto tratan al tráfico Multicast como Broadcast, haciendo ‘flooding’ del mismo por todos sus puertos
IGMP Snooping es una optimización de capa 2 que suele estar habilitada por defecto en los switches y que permite analizar las tramas que contienen paquetes IGMP(identificando la dirección MAC ya conocia) y así filtrar los puertos por donde no existen receptores unidos a los grupos Multicast.
Host - 1.1.1.1
Group - 225.1.1.1
Host - 1.1.1.1
Group - 225.1.1.1
1.1.1.1
1.1.1.1IGMP Snooping
Estructura de árboles
Arquitectura y funcionamiento
Existen dos clases de árboles de distribución de tráfico Multicast.
Source Distribution Tree /
Shortest-Path Tree
Shared Distribution Tree
Usan más memoria al especificar fuente
y grupo en las tablas de rutas multicast
(S,G), pero los caminos del tráfico son
los más óptimos.
Usan menos memoria al especificar sólo
al grupo en las tablas de rutas multicast
(*,G), pero los caminos del tráfico no son
los más óptimos.
RP(Rendezvous Point)
Transmisión Multicast (Forwarding)
Arquitectura y funcionamiento
En Multicast, a diferencia de Unicast, importa más de dónde vino el tráfico (ruta hacia la fuente) que hacia dónde va. Por esa razón se utiliza Reverse Path Forwarding.
La regla de RPF es la siguiente: cuando un paquete Multicast llega a un router, éste hace un “RPF check”, que consiste en verificar si el paquete llegó a través de la interfaz por la cual se aprende a la fuente de dicho paquete en la tabla de rutas Unicast. Si el “RPF check” falla, entonces el paquete se descarta.
Es posible forzar la interfaz RPF mediante rutas de tipo ‘mroute’
Destino Intf
150.1.1.1 Eth0
Eth0
Eth1
150.1.1.1
Si el paquete no llega por la interfaz por
donde se aprende la fuente, se descarta!
Protocol Independent Multicast (PIM)
Arquitectura y funcionamiento
PIM permite la transmisión de tráfico Multicast a través de una red de capa 3 (routers), en base a RPF. Existen dos modos de operación:
Modo Descripción Ventajas Desventajas
PIM
Dense
Mode
• Envía el tráfico por toda la red, luego “corta las ramas” (prune) por donde no existen miembros del grupo Multicast.
• Las tablas de multicast se forman a partir de que los datos llegan. Cualquier flujo redundante es eliminado en base al mecanismo PIM Assert.
•Simple de configurar
•Mecanismo simple de transmisión
• No soporta
Shared Tree
• Transmisión
ineficiente
• Estados (S,G)
en todos los
routers
PIM
Sparse
Mode
• Soporta “Shared Trees” y “Source Trees”, asume que nadie quiere el tráfico hasta que se inscribe.
• Utilizan un RP (Rendezvous Point), donde se “encuentran” las fuentes y receptores.
•Las fuentes son “inscritas” hacia el RP por el routerdirectamente conectado (First Hop Router). Los receptores son unidos (join) al árbol, originado en el RP, mediante el DR (Designated/Last-hop Router)
• Mecanismo
de
transmisión
óptimo y
eficiente.
• No tan simple
de configurar
como Dense
Mode
Operación de PIM Dense Mode
Arquitectura y funcionamiento
1. ‘Flooding’ de tráfico – la fuente envía el tráfico y éste es propagado por todas las interfaces habilitadas con PIM Dense Mode, excepto por la interfaz RPF por donde éste se recibe.
Operación de PIM Dense Mode
Arquitectura y funcionamiento
1. ‘Flooding’ de tráfico – la fuente envía el tráfico y éste es propagado por todas las interfaces habilitadas con PIM Dense Mode, excepto por la interfaz RPF por donde éste se recibe.
2. ‘Pruning’ de tráfico – se envían mensajes ‘Prune’ en el sentido‘upstream’ para parar el tráfico por las siguientes interfaces:
• Por las que no son ‘RPF’
• Por las que son RPF, perodonde no existen miembrosregistrados al grupo en sentido‘downstream’
S,G S,G S,G
S,GS,G
•Los Prunes expiran cada 3 minutos, y el proceso se repite hasta que la fuente deje de enviar tráfico.
•La información de estados permanece en las tablas Multicast de todos los routers
SPT = Shortest Path Tree
Operación de PIM Dense Mode
Arquitectura y funcionamiento
• En caso que dos o más routers se conecten a un miembro registradoen el grupo, ambos routers aceptarán el tráfico Multicast.
• En cuanto uno de los routers reciba tráfico correspondiente al grupo a través de una interfaz que debe ser de “salida de tráfico” según su tabla (OIL – Outgoing Interface List), empezará a enviar e intercambiar paquetes de tipo “PIM Assert” con el/los routers adyacentes.
PIM Assert es un mecanismo que en Dense Mode se encarga de eliminar la duplicidad de tráfico ante casos como el expuesto. El router con menor distancia administrativa y métrica hacia la fuente “gana” y queda enviando tráfico (en caso de empate ganará la mayor IP). Los otros routers harán “prune” del tráfico.
ASSERT
Notas adicionales sobre PIM Dense Mode
Arquitectura y funcionamiento
• El mecanismo PIM Assert puede provocar problemas de ‘loop’ o de convergencia lenta cuando ocurren fallas en ciertos escenariosredundantes.
• Debido a su ineficiencia y a lo arriba expuesto, PIM Dense Mode es un mecanismo principalmente utilizado en entornos de prueba o laboratorio.
Operación de PIM Sparse Mode
Arquitectura y funcionamiento
1. Registro de fuente – la fuente envía el tráfico Multicast a routeradyacente (First Hop) quien lo encapsula en Unicast y lo envía al RPcomo mensajes “PIM Register”.
RP FH2. Camino Fuente-RP - El RP recibe
el registro y envía un “PIM Join” hacia la fuente específica, creando así el camino (S,G – sourcedistribution / SPT) desde la fuente al RP. El tráfico empieza a fluir y el RPenvía un mensaje “PIM RegisterStop” hacia el First Hop para que detenga el envío de mensajes de registro.
REGISTER
REGISTER-STOP
JOIN
•Queda establecido el camino directo (SPT) desde la fuente hacia el RP, por el cual fluye el tráfico de la fuente.
• Deben existir interfaces del RP con miembros interesados para que este flujo se mantenga, de lo contrario expirará mediante mensajes “Prune”.
S,G S,GS,G
Operación de PIM Sparse Mode
Arquitectura y funcionamiento
1. Unión al grupo – En cuanto exista un interesado en el grupo, envíaraun reporte IGMP al “Last Hop”, que se traducirá a un “PIM Join” (*,G) hacia el RP.
RP
2. Camino RP-usuario - El RP y los routers en el camino reciben el “PIM Join”, formándose a su vez el camino (*, G – shared distribution) desde el RP hacia el último router(Last Hop).
•Con esto, el camino Fuente-RP (Source Tree) se ha completado con el camino RP-Usuario (Shared Tree).
LH
S,G S,GS,G*,G
*,G
Operación de PIM Sparse Mode
Arquitectura y funcionamiento
3. Cambio a SPT – Por defecto, en cuanto se recibe el primer paquete Multicast, el árbol cambia de Shareda Source (SPT), para optimizar el flujo del tráfico. Esto se logra mediante el envío de “PIM Joins” de tipo S,G desde el Last Hop hacia la fuente.
RP
4. ‘Prune’ hacia el RP– Finalmente, el tráfico vía el RP es eliminado mediante mensajes “Prune”.
• Nota: El RP sólo enviará mensajes ‘Prune’ a la fuente si es que no le quedan más interfaces con miembros en el ‘Shared Tree’
LH S,G
S,G
S,G
Notas adicionales sobre PIM Sparse Mode
Arquitectura y funcionamiento
• PIM Sparse Mode también forma caminos directos de tráfico (SPT), pero lo hace de una manera más eficiente que Dense Mode. Este comportamiento es configurable, pudiéndose definir la cantidad de tráfico que activará el cambio de ‘Shared Tree’ a ‘Source Tree’.
• PIM Sparse Mode es el mecanismo utilizado en redes en producción.
Arquitectura y funcionamiento
171.68.37.2
PIM Router 2
El router con mayor IP es elegido
Como “DR” (Designated Router)
PIM Hello
PIM Router 1
171.68.37.1
PIM Hello
Los PIM Hellos son enviados por Multicast al grupo “All-PIM-Routers”
(224.0.0.13) cada 30 segundos por defecto.
Si el DR expira, se escoge un nuevo DR.
El “DR” es responsable de mandar todos los mensajes ‘PIM Join’ de los
receptores y ‘PIM Register’ de las fuentes en las redes multiacceso.
Operación general de PIM: Vecindades
Comando IOS:
show ip pim neighbors
Arquitectura y funcionamiento
Operación general de PIM: Estados
El estado PIM describe al árbol de distribución desde el punto de vista del router. Se puede visualizar en la tabla de ‘forwarding’ Multicast y consta de los siguientes elementos principales:
• Entradas (*,G) o (S,G) dependiendo del tipo de árbol.
• RPF Interface, que identifica a la interfaz por donde se alcanza a la fuente y por donde se espera recibir el tráfico.
• RPF Neighbor, que identifica al vecino PIM a través del cual se aprende a la fuente, por donde se espera recibir el tráfico.
• Outgoing Interface List (OIL), que lista las interfaces a través de las cuales se enviará tráfico Multicast para la entrada (*,G) o (S,G) correspondiente. Esta lista se suele probar cada vez que se recibe un PIM Join por la interfaz.
Comando IOS:
show ip mroute
Arquitectura y funcionamiento
Elección de Rendezvous Points
Existen cuatro métodos para configurar la selección de un RP.
# Mecanismo Descripción Comandos
asociados
1 Static RP Configuración manual en todos los
routers. Carece de redundancia
automática en caso de caídas.
ip pim rp-address
2 Auto RP Configuración de:
- Candidate RPs: se anuncian al
grupo 224.0.1.39 escuchado por los
agentes.
- Mapping Agents: escogen al mejor
RP y lo anuncian al grupo 224.0.1.40
(al cual todos los demás routers
siempre escuchan)
- Candidate RPs
ip pim send-rp-
announce
- Mapping Agents
ip pim send-rp-
discovery
Arquitectura y funcionamiento
Elección de Rendezvous Points
Existen cuatro métodos para configurar la selección de un RP.
# Mecanismo Descripción Comandos
asociados
3 Bootstrap
Router (BSR)
Configuración de:
- Candidate RPs: se anuncian por
Unicast a los BSR.
- Candidate BSRs: el de mayor
prioridad es elegidoBSR y escoge al
mejor RP, anunciándolo luego al
grupo 224.0.0.13 (All-PIM-routers)
- Candidate RPs
ip pim rp-candidate
- Candidate BSRs
ip pim bsr-candidate
4 Anycast Dos routers RP estáticos configurados
con la misma dirección IP, de tal
manera que cada uno tendrá las
fuentes más cercanas a él.
Se usa MSDP entre los RP para
sincronizar la información de fuentes.
ip pim rp-address
ip msdp peer
ip msdp originator-id
Source Specific Multicast
Arquitectura y funcionamiento
SSM es una optimización de PIM-SM que permite la creación de árboles de tipo ‘Source Distribution Trees’ sin necesidad de un RP.
Esto se logra haciendo que el receptor conozca a la fuente de antemano y se una a la misma utilizando IGMPv3.
Características básicas:
• Usa ‘Source Trees’ únicamente, las tablas sólo contendrán entradas (S,G)
• Asume un modelo de una o pocas fuentes hacia varios destinos, pues muchas fuentes podrían generar demasiados estados (S,G).
• El router con rol de “Last Hop”, los receptores (hosts) y sus aplicaciones deben soportar IGMPv3, de lo contrario es posible implementar alternativas en el “LastHop”
• Se debe habilitar un rango Multicast para SSM (por defecto es 232/8)
Operación de PIM SSM
Arquitectura y funcionamiento
1. Reporte IGMPv3– el receptor envía su solicitud de unirse al grupo con fuente específica (S,G).
2. PIM-SSM Joins – se envían mensajes ‘PIM Join’ con destinohacia la fuente, creándose en el camino entradas (S,G) que formaránel árbol ‘Source Distribution Tree’
S,G S,G
S,G
El camino SPT quedaestablecido
SPT = Shortest Path Tree
Operación de PIM SSM: Alternativas a IGMPv3
Arquitectura y funcionamiento
Es posible configurar al ‘Last Hop’ router de tal manera que mapee una fuente en base al grupo Multicast, manteniendo IGMPv2 hacia los hosts.
Esto se conoce como SSM Mapping.
Características básicas:
• Permite una sola fuente por grupo.
• La asignación se realiza en base a una de las siguientes alternativas:•Base de datos fuente-grupo configurada localmente.•Base de datos fuente-grupo obtenida desde un servidor DNS.
•Esta configuración es sólo necesaria en los ‘Last Hop’ routers, que convertirán el pedido sin fuente específica recibido por IGMPv2, en una entrada (S,G).
Operación de PIM SSM con SSM Mapping
Arquitectura y funcionamiento
1. Reporte IGMPv2– el receptor envía su solicitud de unirse al grupo con fuente específica (*,G).
2. Mapeo a fuente – en base al grupo al cual el host se desea unir, se mapea la solicitud hacia una fuente específica definida manualmente o aprendida por DNS.
S,G S,G
S,G
El camino SPT quedaestablecido
SPT = Shortest Path Tree
3. PIM-SSM Joins – se envían mensajes ‘PIM Join’ con destinohacia la fuente, creándose en el camino entradas (S,G) que formaránel árbol ‘Source Distribution Tree’
Bidirectional PIM
Arquitectura y funcionamiento
• En aplicaciones de muchas fuentes y muchos destinos (“Many to Any”), se pueden generar demasiadas entradas(S,G) en los routers, lo cual representaun potencial problema de recursos.
• El uso de PIM-SM con RP puede disminuir el número de entradas (S,G), pero entre las fuentes y los RP aún podría existir un número significativo de este tipo de entradas.
RP
LH
*,G *,G
*,G
‘SHARED TREE’
TRÁFICO
• Bidirectional PIM nace como un mecanismo para utilizar sólo (*,G), y así permitir la escalabilidad de aplicaciones de tipo “Manyto Any” Se puede tener un número prácticamente ilimitado de
fuentes.
Bidirectional PIM
Arquitectura y funcionamiento
• El principio fundamental de Bidir PIM es permitir que el tráfico “suba” (desde la fuente hacia el RP) por el ‘Shared Tree’, lo que significa una violación a la regla básica de no permitir tráfico entrante por interfaces salientes (OIL)
• Esta regla puede provocar ‘loops’ en redes multiacceso, por lo cual se reemplaza el concepto de DR por DF (Designated Forwarder), el cual es el único router que puede tomar el tráfico para enviarlo hacia el RP o receptores.
RP
LH
*,G *,G
*,G
‘SHARED TREE’
TRÁFICO
• El resultado es que todos los estados (S,G) se eliminan. Tanto el tráfico desde las fuentes como los PIM Joins, crean estados (*,G)
Bidirectional PIM
Arquitectura y funcionamiento
Receptor 2
E1 (DF) E1 (DF) E1 (DF) E1 (DF)
E1 (DF) E1 (DF)
E0 (DF)
C
E0 E0 E0 E0
E0 E0
Fuente Receptor1
El tráfico generado por la fuente hace que el ‘First Hop’ router cree una entrada (*,G)
RP
F
D
E
BA
(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: BP
Bidir-Upstream: Ethernet0, RPF nbr 172.16.7.1
Outgoing interface list:
Ethernet0, Bidir-Upstream/Sparse-Dense, 00:32:20/00:00:00
Bidirectional PIM
Arquitectura y funcionamiento
Receptor 2
E1 (DF) E1 (DF) E1 (DF) E1 (DF)
E1 (DF) E1 (DF)
E0 (DF)RP
C
E0 E0 E0 E0
E0 E0
Fuente Receptor 1
Es necesario que exista el RP físicamente en Bidir PIM?
No, a diferencia de PIM-SM, no existen mensajes de control intercambiados con el RP,
por lo que puede usarse un RP ‘fantasma’
F
D
E
A B
Multicast VPN – Conceptos generales
Arquitectura y funcionamiento
El despliegue de Multicast VPN basado en draft-rosen-vpn-mcast-07
permite el intercambio de tráfico Multicast aprovechando la infraestructura de MPLS L3VPN (RFC2547).
Los componentes principales de Multicast VPN son:
1. Multicast VRF (MVRF) – VRF habilitada para Multicast, utilizando
PIM, IGMP y/o MSDP dentro del contexto de la VRF.
2. Multicast Domain (MD) – Utiliza túneles (Multicast Tunnel Interface -MTI) para formar árboles que agrupan varias MVRFs dentro de un dominio Multicast, el cual funciona como una ‘LAN’ para cada una de ellas, formada por todos los PEs que tienen la MVRF. Cada MVRF creaun MTI.
3. Multicast Distribution Trees – uno o más árboles dentro de la red del proveedor para cada Multicast Domain.
Multicast VPN – Interfaz MTI
Arquitectura y funcionamiento
La interfaz MTI se crea automáticamente (con la misma IP origen de MP-BGP) y forma una especie de LAN entre los PEs que tienen la MVRFconfigurada.
Todos los PEs son vecinos PIM entre sí a través del túnel MTI.
PE PE PE
Cliente A
MDT 239.1.1.1
CE CE CE
Multicast VPN – Vecindades PIM
Arquitectura y funcionamiento
PE-CE
Customer mVRF
PE-CE
Customer mVRF
PE-PE
Customer mVRF
PE-P
Global
PE-P
GlobalMulticast
Tunnel
Interface
PE-P: Multicast nativo en el Core (PIM Global)
PE-CE: en mVRF (PIM dentro de VRF)
PE-PE: en mVRF via MTI (PIM dentro de VRF)
Multicast
Tunnel
Interface
CE CE
PE PE
Multicast VPN – MDT
Arquitectura y funcionamiento
La configuración de mVPN implica la creación de un Multicast DistributionTree (MDT) para cada VRF en la que se quiera habilitar Multicast. Existen dos tipos de MDT:
Tipo de
MDT
Descripción
Default Este árbol se utiliza para enviar tanto el tráfico de control como el tráfico
de datos. Todos los PEs recibirán el tráfico enviado por la fuente,
independientemente de si existen o no receptores interesados detrás de
cada PE. Si el tráfico de control es bajo, entonces se recomienda esta
configuración.
Data Este árbol se puede habilitar de manera adicional al MDT Default para
transportar todo el tráfico de datos del cliente. La particularidad del
MDT Data es que sólo se activa en los PEs que conecten a receptores
interesados y cuando la cantidad de tráfico excede un umbral
configurable. La desventaja de este MDT es que se crean instancias
adicionales de control de Multicast en los routers de Core (P).
Multicast VPN – MDT
Arquitectura y funcionamiento
MDT Default
Para entradas de
cliente (*,G) o
(S,G)
MDT Data
Para entradas de
cliente (S,G)
solamente
Multicast VPN – Encapsulamiento del tráfico
Arquitectura y funcionamiento
Los paquetes Multicast de cliente son encapsulados en los MTI utilizando cabeceras GRE y direccionamiento Multicast del proveedor. NO se utiliza MPLS.
Multicast VPN – Protocolos utilizados
Arquitectura y funcionamiento
Los modos de Multicast configurados dentro de la VRF (cliente) y fuera de la VRF son independientes.
Red Modos Multicast
Cliente
(VRF)
PIM-SM, PIM-DM, PIM-SSM
Proveedor PIM-SM, PIM-SSM
A nivel proveedor, es ventajoso utilizar PIM-SSM para evitar la dependencia en RP’s. Para lograr esto, se necesita un mecanismo para que los PEsconozcan las fuentes para cada grupo MDT.
Multicast VPN – PIM-SSM en Proveedor
Arquitectura y funcionamiento
Existen dos formas para que los PEs puedan conocer las direcciones IP fuente de cada grupo MDT, que serán otros PEs. Ambas formas por MP-BGP.
Versión IOS Mecanismo para intercambiar la
información de fuentes
Pre-estándar
(pre-12.0(29))
RD tipo 0x2 para distinguir de VPNv4
Estándar
(12.0(29) en
adelante)
SAFI MDT (SAFI 66)
Los mensajes contienen la IP del PE y el grupo MDT para el cual es fuente.
IP Multicast – PIM-SM (RP estático)
Ejemplos de configuración
interface Loopback100description RP IDip address 10.1.1.1 255.255.25.255
ip multicast-routingip pim rp-address 10.1.1.1
interface FastEthernet0/0ip pim sparse-mode
interface FastEthernet1/0ip pim sparse-mode
interface FastEthernet1/1ip pim sparse-mode
ip multicast-routingip pim rp-address 10.1.1.1
interface FastEthernet0/0ip pim sparse-mode
interface FastEthernet1/0ip pim sparse-mode! (por defecto corre IGMPv2)
RP – 10.1.1.1
F0/0
F1/0
F1/1
F0/0
F0/0
F1/0
F1/0
IP Multicast – ‘PIM-SSM’ (IGMPv3)
Ejemplos de configuración
access-list 10 permit 225.0.0.0/8
ip multicast-routingip pim ssm range 10
interface FastEthernet0/0ip pim sparse-mode
interface FastEthernet1/0ip pim sparse-mode
interface FastEthernet1/1ip pim sparse-mode
access-list 10 permit 225.0.0.0/8
ip multicast-routingip pim ssm range 10
interface FastEthernet0/0ip pim sparse-mode
interface FastEthernet1/0ip pim sparse-modeip igmp version 3
F0/0
F1/0
F1/1
F0/0
F0/0
F1/0
F1/0
IP Multicast – ‘PIM-SSM’ (SSM Mapping)
Ejemplos de configuración
ip multicast-routingip pim ssm range 10
interface FastEthernet0/0ip pim sparse-mode
interface FastEthernet1/0ip pim sparse-mode
interface FastEthernet1/1ip pim sparse-mode
access-list 10 permit 225.0.0.0/8
ip multicast-routing
interface FastEthernet0/0ip pim sparse-mode
interface FastEthernet1/0ip pim sparse-mode
ip igmp ssm-map enableip igmp ssm-map static 10 10.20.20.1
access-list 10 permit 225.0.0.0/8
F0/0
F1/0
F1/1
F0/0
F0/0
F1/0
F1/0
Fuente10.20.20.1
IP Multicast – Troubleshooting
Ejemplos de configuración
• show ip pim neighbors – Muestra las vecindades PIM adyacentes
• show ip mroute – Muestra el estado por cada entrada (S,G) y (*,G).
• show ip mroute count – Muestra el conteo de paquetes y fallas RPF.
• show ip igmp groups – Muestra la membresía al grupo en el Last Hop.
Multicast VPN – PIM-SSM en proveddor (Pre-estándar)
Ejemplos de configuración
ip vrf CLIENTE-A
rd 100:27
route-target export 100:27
route-target import 100:27
mdt default 239.192.10.2
ip multicast-routingip pim ssm range 10access-list 10 permit 239.0.0.0/8
ip multicast-routing vrf CLIENTE-Aip pim vrf CLIENTE-A rp-address 10.1.1.1
interface GigabiEthernet0/0.100ip vrf forwarding CLIENTE-Aip pim sparse-mode
interface GigabitEthernet1/0ip pim sparse-mode
ip multicast-routingip pim ssm range 10access-list 10 permit 239.0.0.0/8
interface GigabitEthernet0/0ip pim sparse-mode
interface GigabitEthernet1/0ip pim sparse-mode
G0/0.100
G0/0.100
G1/0G1/0
G0/0 G1/0
RP – 10.1.1.1
RR
Ejemplos de configuración
Multicast VPN – PIM-SSM en proveddor (Estándar)
PE
ip vrf ABC
rd 100:1
route-target export 100:1
route-target import 100:1
mdt default 239.192.1.1
ip multicast-routingip pim ssm range 10access-list 10 permit 239.0.0.0/8
ip multicast-routing vrf CLIENTE-Aip pim vrf ABC rp-address 10.1.1.1
interface GigabiEthernet0/0.100ip vrf forwarding ABCip pim sparse-mode
interface GigabitEthernet1/0ip pim sparse-mode
router bgp 100address-family mdtneighbor 1.1.1.10 activate
Pip multicast-routingip pim ssm range 10access-list 10 permit 239.0.0.0/8
interface GigabitEthernet0/0ip pim sparse-mode
interface GigabitEthernet1/0ip pim sparse-mode
G0/0.100
G0/0.100
G1/0G1/0
G0/0 G1/0
RP – 10.1.1.1
RR
RR
router bgp 100address-family mdtneighbor 1.1.1.1 activateneighbor 1.1.1.1 route-reflector-clientneighbor 2.2.2.2 activateneighbor 2.2.2.2 route-reflector-client
1.1.1.1 2.2.2.2
1.1.1.10
Multicast VPN – Troubleshooting
Ejemplos de configuración
• show ip pim neighbors – Muestra las vecindades PIM adyacentes
• show ip mroute – Muestra el estado por cada entrada (S,G) y (*,G).
• show ip pim vrf [vrf] neighbors – Muestra las vecindades PIM adyacentes dentro de la VRF.
• show ip pim vrf [vrf] interface – Muestra las interfaces habilitadas con PIM (monitoreo de MTI)
• show ip mroute vrf [vrf] – Muestra el estado por cada entrada (S,G) y (*,G) dentro de la VRF.
• show ip mroute vrf [vrf] count – Muestra el conteo de paquetes y fallas RPF dentro de la VRF.
• show ip igmp vrf [vrf] groups – Muestra la membresía al grupo en el Last Hop dentro de la VRF.
• show ip bgp vpnv4 all [fuente] – Muestra la información de fuente y grupo dentro del RD tipo 2, para mVPN con SSM (pre-estándar)
• show ip bgp ipv4 mdt all [grupo] – Muestra la información de fuente y grupo dentro del SAFIMDT, para mVPN con SSM (estándar)
Bibliografía y recursos
Libros y otros recursos
• www.cisco.com/go/multicast
• MPLS and VPN Architectures Volume II – Chapter 7 for Multicast VPN
• CCIE Professional Development - Routing TCP-IP, Volume II – Jeff Doyle
Gracias.
Contacto acerca de esta presentación:Gianpietro Lavado Chiarella
Network Consulting Engineer
Cisco Systems
glch@cisco.com / glavado@cisco.com