MDT predeterminado de multidifusión de próxima generación: Perfil 0

Introducción

Este documento describe cómo atraviesa el paquete de multidifusión con el uso del núcleo Multiprotocol Label Switching (MPLS) en Next Generation Multicast.

Antecedentes 

MDT predeterminado - PIM C - señalización mcast

Draft Rosen utiliza Generic Routing Encapsulation (GRE) como protocolo de superposición. Esto significa que todos los paquetes multicast se encapsulan dentro del GRE. Una LAN virtual se emula con todos los routers de borde del proveedor (PE) en la VPN para unirse a un grupo de multidifusión. Esto se conoce como el árbol de distribución de multidifusión predeterminado (MDT). El MDT predeterminado se utiliza para los saludo de multidifusión independiente de protocolo (PIM) y otras señalizaciones PIM, pero también para el tráfico de datos. Si el origen envía mucho tráfico, no es eficiente utilizar el MDT predeterminado y se puede crear un MDT de datos. El MDT de datos sólo incluirá los PE que tengan receptores para el grupo en uso.

El proyecto Rosen es bastante sencillo de implementar y funciona bien, pero tiene algunos inconvenientes. Veamos lo siguiente:

Sobrecarga: GRE agrega 24 bytes de sobrecarga al paquete. En comparación con MPLS, que normalmente agrega 8 o 12 bytes, hay un 100% o más de sobrecarga agregada a cada paquete.

PIM en el núcleo - El Borrador Rosen requiere que PIM esté habilitado en el núcleo porque los PE deben unirse al MDT predeterminado y de datos que se hace a través de la señalización PIM. Si se utiliza PIM ASM en el núcleo, también se necesita un RP. Si PIM SSM se ejecuta en el núcleo, no se necesita RP.

Estado del núcleo: el estado innecesario se crea en el núcleo debido a la señalización PIM de los PE. El núcleo debería tener el menor estado posible.

Adyacencias PIM - Los PE se convertirán en vecinos PIM entre sí. Si se trata de una VPN de gran tamaño y de muchos PE, se crearán muchas adyacencias PIM. Esto genera una gran cantidad de hello y otras señales que aumentan la carga del router.

Unidifusión frente a multidifusión: el reenvío unidifusión utiliza MPLS y el multidifusión utiliza GRE. Esto añade complejidad y significa que la unidifusión utiliza un mecanismo de reenvío diferente al multicast, que no es la solución óptima.

Ineficiencia - El MDT predeterminado envía tráfico a todos los PE en la VPN independientemente de si el PE tiene un receptor en (*,G) o (S,G) para el grupo en uso.

• El MDT predeterminado se utilizará para conectar el multicast a todo el PE en un VRF.
• Predeterminado significa que conecta todos los routers PE.
• De forma predeterminada, transporta todo el tráfico.
• Todo el tráfico de control PIM y el tráfico del plano de datos. Por ejemplo, tráfico (*,G) y tráfico (S,G).  
• Esto representa multipunto a multipunto.
• Cualquiera puede enviar y todos pueden recibir del árbol. 

PIM como señalización superpuesta

Topología

Tareas de Configuración

1. Habilite Multicast Routing en todos los nodos.
2. Habilite el modo disperso PIM en toda la interfaz.
3. Con el VRF existente, configure el MDT predeterminado.
4. Configure el VRF en la interfaz Ethernet0/x.
5. Habilite Multicast Routing en VRF.
6. Configure PIM SSM Default en todos los nodos dentro del núcleo.
7. Configure BSR RP en el nodo CE.
8. Preconfigurado:

•      VRF m-GRE
•      MBGP: Familia de direcciones VPNv4
•      Protocolo de ruteo VRF

Configurar

1. Habilite Multicast Routing en todos los nodos.

(config)# ip multicast-routing

2. Habilite el modo disperso PIM en toda la interfaz.

(config)# interface ethernet0/x

(config-if)#ip pim sparse-mode



(config)# interface loopback0

(config-if)#ip pim sparse-mode

 3. Con el VRF que ya existe, configure el MDT predeterminado.

(config)#ip vrf m-GRE

(config-vrf)# mdt default 232.1.1.1

4. Configure el VRF en la interfaz Ethernet0/x.

En PE1, PE2 y PE3.

(config)# interface ethernet0/x

(config-if)# ip vrf forwarding m-GRE

(config-if)# ip address 10.x.0.1 255.255.255.0

5. Habilite Multicast Routing en VRF.

En PE1, PE2 y PE3.

(config)# ip multicast-routing vrf m-GRE

6. Configure RP para el núcleo del proveedor de servicios.

En los nodos PE1, PE2, PE3 y RR-P.

(config)# ip pim rp-address 11.11.11.11

7. Configure BSR RP en el nodo CE (receptor).

Al receptor 2.

(config)# ip pim bsr-candidate loopback0

(config)# ip pim rp-candidate loopback0

Verificación

Utilize esta sección para confirmar que su configuración funcione correctamente.

Tarea 1: Verificar la conectividad física

• Verifique que toda la interfaz conectada esté "ACTIVADA"

Tarea 2: Verificar unidifusión VPNv4 de la familia de direcciones

• Verifique que BGP esté habilitado en todos los routers para la unidifusión AF VPNv4 y que los vecinos BGP estén "ACTIVOS"
• Verifique que la tabla de unidifusión VPNv4 de BGP tenga todos los prefijos del cliente.

Tarea 3: Verifique el tráfico de multidifusión de extremo a extremo.

           

• Verifique la vecindad PIM.
• Verifique que el estado multicast se crea de extremo a extremo.
• Verifique la entrada mRIB en PE1, PE2 y PE3
• Verifique que (S,G) entrada mFIB, el paquete se incrementa en el reenvío de software.
• Verifique que los paquetes ICMP lleguen de CE a CE.

Cuando se crean las interfaces de túnel:

Creación de RP del proveedor de servicios:

Una vez que la información del RP se inunda en el núcleo. Se crea el túnel de interfaz 0.

PIM(0): Iniciando la creación del túnel de encapsulación de registro para RP 11.11.11.11.

PIM(0): La creación del túnel de registro inicial se ha realizado correctamente para RP 11.11.11.

PIM(0): Adición de un túnel de encapsulado de registro como interfaz de reenvío de (1.1.1.1, 232.1.1.1) diferido hasta que se crea el túnel.

*9 de mayo 17:34:56.155: PIM(0): Verifique RP 11.11.11.11 en el (*, 232.1.1.1).

PIM(0): Agregar túnel de encapsulado de registro (Tunnel0) como interfaz de reenvío de (1.1.1.1, 232.1.1.1).

PE1#sh int tunnel 0

Tunnel0 is up, line protocol is up

  Hardware is Tunnel

  Description: Pim Register Tunnel (Encap) for RP 11.11.11.11

  Interface is unnumbered. Using address of Ethernet0/1 (10.0.1.1)

  MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation TUNNEL, loopback not set

  Keepalive not set

  Tunnel source 10.0.1.1 (Ethernet0/1), destination 11.11.11.11 >>>>>>>>>> Tunnel Source and destination 

   Tunnel Subblocks:

      src-track:

         Tunnel0 source tracking subblock associated with Ethernet0/1

          Set of tunnels with source Ethernet0/1, 1 member (includes iterators), on interface <OK>

  Tunnel protocol/transport PIM/IPv4

  Tunnel TOS/Traffic Class 0xC0,  Tunnel TTL 255

  Tunnel transport MTU 1472 bytes

Creación del Túnel MDT:

Creación de MRIB en el núcleo:

PE1#sh ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,



 (3.3.3.3, 232.1.1.1), 00:10:13/00:01:01, flags: JTZ

  Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2

  Outgoing interface list:

    MVRF m-GRE, Forward/Sparse, 00:10:13/00:01:46



(2.2.2.2, 232.1.1.1), 00:10:14/00:00:57, flags: JTZ

  Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2

  Outgoing interface list:

    MVRF m-GRE, Forward/Sparse, 00:10:14/00:01:45



(1.1.1.1, 232.1.1.1), 00:10:15/00:03:20, flags: FT

  Incoming interface: Loopback0, RPF nbr 0.0.0.0

  Outgoing interface list:

    Ethernet0/1, Forward/Sparse, 00:10:15/00:03:04

 Una vez que se crea el RP para la red del cliente:

*May  9 18:54:42.170:  prm_rp->bidir_mode = 0 vs bidir = 0 (224.0.0.0/4, RP:33.33.33.33), PIMv2

*May  9 18:54:42.170: PIM(1): Initiating register encapsulation tunnel creation for RP 33.33.33.33

*May  9 18:54:42.170: PIM(1): Initial register tunnel creation succeeded for RP 33.33.33.33

*May  9 18:54:43.173: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

La interfaz de túnel se crea para llevar la información RP del cliente. 

PIM(1): Iniciando la creación del túnel de encapsulación de registro para RP 22.22.22.22.

Se trata del túnel creado para registrar la encapsulación al RP. 

Para cada RP de modo disperso descubierto, se crea un túnel de encapsulación Register. En el RP de modo disperso en sí, hay una interfaz de túnel de desencapsulación creada para recibir paquetes de Registro.

Vecindad PIM:

PE1#sh ip pim interface  

Address          Interface                Ver/   Nbr    Query  DR     DR

                                          Mode   Count  Intvl  Prior

1.1.1.1          Loopback0                v2/S   0      30     1      1.1.1.1

10.0.1.1         Ethernet0/1              v2/S   1      30     1      10.0.1.2



PE1#sh ip pim vrf  m-GRE neighbor

PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable

Neighbor          Interface                Uptime/Expires    Ver   DR

Address                                                            Prio/Mode

10.1.0.2          Ethernet0/2              03:08:34/00:01:43 v2    1 / DR S P G

3.3.3.3           Tunnel1                  01:44:24/00:01:41 v2    1 / DR S P G

2.2.2.2           Tunnel1                  01:44:24/00:01:38 v2    1 / S P G

Flujo de paquetes:

El flujo de paquetes del plano de control se divide en dos partes.

1. El receptor se conecta.
2. El origen está activo.

Cuando el receptor está activo: 

1. El receptor se conecta, envía PIM JOIN (*,G) hacia PE3.

2. PE3 encapsula el PIM JOIN (*,G) en el paquete GRE y envía a través del túnel 2 (túnel MDT), que se verifica desde la interfaz entrante de show ip mroute vrf m-GRE.

PE3#sh ip mroute 

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E – Extranet



(3.3.3.3, 232.1.1.1), 10:20:04/00:02:56, flags: FT

  Incoming interface: Loopback0, RPF nbr 0.0.0.0

  Outgoing interface list:

    Ethernet0/3, Forward/Sparse, 10:20:04/00:02:40

1. PE2 recibió el paquete GRE con el Origen como 3.3.3.3 y el Destino 232.1.1.1 y lo reenvía a MVRF m-GRE basado en el PETRÓLEO.

PE2#sh ip mroute 

IP Multicast Routing Table

Flags:

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       Z - Multicast Tunnel, z - MDT-data group sender,



(3.3.3.3, 232.1.1.1), 11:47:30/00:01:01, flags: JTZ

  Incoming interface: Ethernet0/3, RPF nbr 10.0.2.2

  Outgoing interface list:

    MVRF m-GRE, Forward/Sparse, 11:47:30/00:00:29

El paquete GRE se desencapsula y PIM JOIN se envía hacia el RP.

Nota: El Vecino RPF es 2.2.2.2 porque la Unión PIM está destinada hacia la dirección RP para formar el RPT a través del núcleo.

Nota: Bit WC y Bit RPT:Activado por el estado (*,G), el DR crea un mensaje Join/Prune con la dirección RP en su lista de unión y el bit comodín (bit WC) y el bit de árbol RP (bit RPT) establecidos en 1. El bit WC indica que cualquier origen puede coincidir y ser reenviado según esta entrada si ya no hay coincidencia; el bit RPT indica que esta unión se envía por el árbol RP compartido. La lista de separación se deja vacía. Cuando el bit RPT está configurado en 1, indica que la unión está asociada con el árbol RP compartido y, por lo tanto, el mensaje Join/Prune se propaga a lo largo del árbol RP. Cuando el bit WC está configurado en 1, indica que la dirección es un RP y que los receptores de flujo descendente esperan recibir paquetes de todos los orígenes a través de esta ruta (árbol compartido).

PE2#sh ip mroute verbose 

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

 L - Local, P - Pruned, R - RP-bit set, F - Register flag,

 T - SPT-bit set, J - Join SPT, M - MSDP created entry, E -

 V - RD & Vector, v - Vector, p - PIM Joins on route



(2.2.2.2, 232.1.1.1), 22:48:12/00:02:04, flags: FTp

Incoming interface: Loopback0, RPF nbr 0.0.0.0

Outgoing interface list:Ethernet0/3, Forward/Sparse, 22:48:12/00:03:12, p

1. Llegada de paquetes encapsulados GRE en PE1 de origen.

PE1#sh ip mroute verbose 

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

       U - URD, I - Received Source Specific Host Report,

       Z - Multicast Tunnel, z - MDT-data group sender,



 (2.2.2.2, 232.1.1.1), 22:55:50/00:02:45, flags: JTZ

  Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2

  Outgoing interface list:MVRF m-GRE, Forward/Sparse, 22:55:50/00:01:09



PIM(1): Received v2 Join/Prune on Tunnel2 from 2.2.2.2, to us

PIM(1): Join-list: (10.1.0.2/32, 224.1.1.1), S-bit set

2. PIM JOIN (S,G) llega a la fuente CE.

3. Ahora el Origen obtuvo la información del Receptor Interesado y el tráfico comienza a enviarse al PE1 de Origen.

4. En el PE PE PE1 de origen:

PIM(1): Add Tunnel2/2.2.2.2 to (10.1.0.2, 224.1.1.1), Forward state, by PIM SG Join



MFIBv4(0x1): Pkt (10.1.0.2,224.1.1.1) from Ethernet0/2 (PS) accepted for forwarding

MFIBv4(0x1): Pkt (10.1.0.2,224.1.1.1) from Ethernet0/2 (PS) sending to Tunnel2, MDT/232.1.1.1

MFIBv4(0x1): Pkt (10.1.0.2,224.1.1.1) from Ethernet0/2 (PS) sent on Tunnel2, MDT/232.1.1.1

En PE2 (RP PE):

PIM(1): Prune-list: (10.1.0.2/32, 224.1.1.1) RPT-bit set

PIM(1): Cancel sending Join for (10.1.0.2/32, 224.1.1.1) on Tunnel2



PE2#sh ip mroute vrf m-GRE

IP Multicast Routing Table

Flags: L - Local, P - Pruned, R - RP-bit set, F - Register flag,



(10.1.0.2, 224.1.1.1), 00:03:52/00:01:29, flags: R

  Incoming interface: Ethernet0/2, RPF nbr 10.2.0.2

  Outgoing interface list:

    Tunnel2, Forward/Sparse, 00:00:52/00:02:58

Captura PCAP de paquetes multidifusión de PE1. Tunelizado en Túnel MDT Predeterminado. Encapsulado con GRE.

5. En el PE PE3 del receptor, se recibe el paquete.

PE3#sh ip mroute verbose 

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       Z - Multicast Tunnel, z - MDT-data group sender,

      

(1.1.1.1, 232.1.1.1), 23:12:51/00:02:50, flags: JTZ

  Incoming interface: Ethernet0/3, RPF nbr 10.0.3.2

  Outgoing interface list:

    MVRF m-GRE, Forward/Sparse, 23:12:51/stopped

 PIM(1):  Building Join/Prune packet for nbr 2.2.2.2

 PIM(1):  Adding v2 (10.1.0.2/32, 224.1.1.1), RPT-bit, S-bit Prune

 PIM(1):  Send v2 join/prune to 2.2.2.2 (Tunnel2)

 PIM(1):  Building Join/Prune packet for nbr 1.1.1.1

 MFIBv4(0x1): Pkt (10.1.0.2,224.1.1.1) from Tunnel2, MDT/232.1.1.1 (PS) accepted for forwarding

 MFIBv4(0x1): Pkt (10.1.0.2,224.1.1.1) from Tunnel2, MDT/232.1.1.1 (PS) sent on Ethernet0/0

 MFIBv4(0x1): Pkt (10.1.0.2,224.1.1.1) from Tunnel2, MDT/232.1.1.1 (PS) accepted for forwarding

 MFIBv4(0x1): Pkt (10.1.0.2,224.1.1.1) from Tunnel2, MDT/232.1.1.1 (PS) sent on Ethernet0/0

*Jun  2 20:09:11.817: PIM(1): Received v2 Join/Prune on Ethernet0/0 from 10.3.0.2, to us



PE3#sh ip mroute  vrf m-GRE  verbose 

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       V - RD & Vector, v - Vector, p - PIM Joins on route



(10.1.0.2, 224.1.1.1), 00:00:07/00:02:52, flags: Tp

  Incoming interface: Tunnel2, RPF nbr 1.1.1.1

  Outgoing interface list:

    Ethernet0/0, Forward/Sparse, 00:00:07/00:03:22, p


RPF Change at PE3 (Receiver PE)


MRT(1): (10.1.0.2,224.1.1.1), RPF change from  /2.2.2.2 to Tunnel1/1.1.1.1

MRT(1): Create (10.1.0.2 ,224.1.1.1), RPF (Tunnel2, 1.1.1.1, 200/0)

MRT(1): Set the T-flag for (10.1.0.2, 224.1.1.1)

MRT(1): WAVL Insert interface: Tunnel1 in (10.1.0.2,224.1.1.1) Successful

MRT(1): set min mtu for (10.1.0.2, 224.1.1.1) 18010->1500

Nota: El Vecino RPF se cambia una vez que se recibe un Paquete Multicast de PE1. Anteriormente, era PE2 como RP alojado detrás de él. Después de recibir el primer paquete de multidifusión, cambia el RPF y establece el bit SPT.

Flujo de tráfico sobre túnel MDT predeterminado:

• El reenvío en el MDT utiliza GRE, el paquete C se convierte en un paquete P.
• Dirección P-Packet S = dirección de peering BGP de PE
  Dirección G = dirección de grupo MDT (predeterminada o datos)
• Los C-Packet IP TOS se copiarán en P-Packet.
• Las etiquetas MPLS NO se utilizan en el núcleo, sólo en la multidifusión nativa.

Flujo de paquetes:

1. Un paquete C llega a una interfaz PE configurada VRF, mVRF se identifica implícitamente. Comprobación de RPF normal en la fuente C.

El C-Packet replicó fuera de la interfaz en el OIL. En este punto, esto sería una interfaz PE en el mismo VRF.

PE1#sh ip mroute vrf  m-GRE verbose 

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, v - Vector, p - PIM Joins on route

Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join

 Timers: Uptime/Expires

 Interface state: Interface, Next-Hop or VCD, State/Mode





(10.1.0.2, 224.1.1.1), 00:00:03/00:02:56, flags: Tp

  Incoming interface: Ethernet0/2, RPF nbr 10.1.0.2

  Outgoing interface list:

    Tunnel2, GRE MDT: 232.1.1.1 (default), Forward/Sparse, 00:00:03/00:03:26, p (Small “p” indicates downstream PIM join)

Si el OIL contiene un MTI, el paquete C se encapsula en un paquete P. Si el indicador "y" está establecido en el destino de entrada utilizado es el grupo DATA-MDT; de lo contrario, el grupo MDT predeterminado. El origen es la dirección del peer BGP PE y el destino es la dirección del grupo MDT.

2. El paquete P se reenvía a través de la red P según la multidifusión normal.

El paquete llega a la interfaz global. Entrada global (S,G) o (*,G) para el grupo MDT al que se hace referencia. Comprobación de RPF normal en la fuente P (par PE).

3. El paquete P se replica fuera de la interfaz en OIL. En este punto, esto es P/PE en la tabla de ruta multicast global.

4. Si el indicador "Z" establece el paquete se desencapsula para revelar el paquete C. El mVRF de destino y la interfaz entrante derivada del grupo MDT es el destino del encabezado encapsulado.

Verificación RPF del C-Packet en mVRF hecho, C Packet replicado fuera de OIL en mVRF.

PE3#sh ip mroute verbose 

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       Z - Multicast Tunnel, z - MDT-data group sender,



(1.1.1.1, 232.1.1.1), 1d01h/00:02:47, flags: JTZ

  Incoming interface: Ethernet0/3, RPF nbr 10.0.3.2

  Outgoing interface list: MVRF m-GRE, Forward/Sparse, 1d01h/stopped

5. Llegada del paquete C nativo al receptor 3.

Encapsulación de Paquetes:

MDT de datos:

¿Qué es Data MDT?

Es opcional. Se crea a demanda y transporta tráfico específico (S,G). En la última versión de IOS®, el umbral configurado es "0" e "infinito". Siempre que un primer paquete llega al VRF, el MDT de datos se inicializa y, si es infinito, nunca se creará el MDT de datos y el tráfico avanza en el MDT predeterminado. El MDT de datos es siempre el árbol receptor, nunca envía tráfico. El MDT de datos es solo para el tráfico (S,G). 

PMSI selectivo:

• Es opcional. Se crea a demanda y transporta tráfico específico (S, G).
• Siempre que un primer paquete llega al VRF, el MDT de datos se inicializa y, si es infinito, nunca se crea el MDT de datos y el tráfico avanza en el MDT predeterminado.
• El MDT de datos es siempre el árbol receptor, nunca envía tráfico. El MDT de datos es solo para el tráfico (S, G). 
• El mensaje PIM lleva C- (S, G) y P-Group.

Cómo se crea DATA MDT:

1. Cuando el tráfico multicast ingresa en el VRF y cuando la velocidad del tráfico alcanza el umbral. Genera un Paquete MDT.

  2. El paquete MDT se encapsula en UDP con Source y Destination 3232. Y envíelo al receptor interesado.

3. Después de enviar el paquete UDP al receptor interesado, establece el indicador "Y" y cambia el siguiente salto MDT a la nueva dirección del grupo MDT.

En el PE PE PE1 de origen:

MRT(1): Set the y-flag for (10.1.0.2,224.1.1.1)

PIM(1): MDT next_hop change from: 232.1.1.1 to 232.2.2.0 for (10.1.0.2, 224.1.1.1) Tunnel2



PE1#sh ip mroute vrf m-GRE verbose

IP Multicast Routing Table

Flags:

       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

       Y - Joined MDT-data group, y - Sending to MDT-data group,

         p - PIM Joins on route





(10.1.0.2, 224.1.1.1), 00:08:09/00:02:46, flags: Typ

  Incoming interface: Ethernet0/2, RPF nbr 10.1.0.2

  Outgoing interface list:

    Tunnel2, GRE MDT: 232.2.2.0 (data), Forward/Sparse, 00:08:09/00:03:27, A, p (Small “p” indicates downstream PIM join)

Nota: El salto siguiente del PETRÓLEO cambia a 232.2.2.0.

2. AT PE3, cuando recibe el paquete MDT encapsulado en el puerto UDP SRC 3232 y el puerto DST 3232.
   
   

UDP: rcvd src=1.1.1.1(3232), dst=224.0.0.13(3232), length=24

PIM(1): Receive MDT Packet (1418) from 1.1.1.1 (Tunnel2), length (ip: 44, udp: 24), ttl: 1

PIM(1): TLV type: 1 length: 16 MDT Packet length: 16

MRT(1): Set the Y-flag for (10.1.0.2,224.1.1.1)



PE3#sh ip mroute vrf m-GRE verbose        

IP Multicast Routing Table

Flags:

       T - SPT-bit set, Y - Joined MDT-data group, y - Sending to MDT-data

       p - PIM Joins on route



(10.1.0.2, 224.1.1.1), 00:08:27/00:00:20, flags: TYp

  Incoming interface: Tunnel1, RPF nbr 1.1.1.1, MDT:232.2.2.0/00:02:15

  Outgoing interface list:

    Ethernet0/0, Forward/Sparse, 00:08:27/00:03:21, p

El mensaje S-PMSI Join es un mensaje encapsulado UDP cuya dirección de destino es ALL-PIM-ROUTERS (224.0.0.13) y cuyo puerto de destino es 3232. 

El mensaje S-PMSI Join (Unión S-PMSI) contiene esta información: un identificador para el flujo multicast concreto que se va a enlazar al túnel P. Esto se puede representar como un par (S,G). Identificador del túnel P concreto al que se enlazará el flujo. Este identificador es un campo estructurado que incluye esta información: 

Flujo de tráfico multidifusión en túnel de DATOS MDT: 

PE1#sh ip pim mdt send                    



MDT-data send list for VRF: m-GRE

  (source, group)                     MDT-data group/num   ref_count

  (10.1.0.2, 224.1.1.1)               232.2.2.0            1





PE3#sh ip pim mdt receive                 



Joined MDT-data [group/mdt number : source]  uptime/expires for VRF: m-GRE

 [232.2.2.0 : 1.1.1.1]  00:00:41/00:02:18

• Si el OIL contiene una interfaz de túnel, el paquete se encapsula con el uso de GRE, siendo la dirección de peering BGP del router PE local y la dirección de destino el grupo MDT.

• La decisión de seleccionar el grupo Data-MDT depende de si el indicador Y está establecido en la entrada (S, G) en mVRF.

• Si la entrada (S, G) o (*, G) tiene el indicador Z establecido, se trata de un MDT predeterminado o de datos con un mVRF asociado.

• El paquete P debe ser desencapsulado para revelar el paquete C.

• Debido a que sólo existe un MTI único en el mVRF por dominio multicast, tanto el Data-MDT como el Default-MDT utilizan la misma interfaz de túnel para el tráfico del cliente.

• Los indicadores Y/Y son necesarios para distinguir el tráfico Default-MDT del tráfico Data-MDT y asegurar que las entradas de ruteo multicast del cliente utilicen el grupo MDT-Data correcto y hagan referencia a una tabla interna que contiene las asignaciones (S, G, Data-MDT).

Troubleshoot

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.