Reenvío de multicast en el vPC basado en la ubicación de la fuente

Introducción

Este documento explica los diversos decorados del Reenvío de multicast cuando una fuente se coloca en un entorno del vPC

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Expedición de la encaminamiento y de Mutilcast
• Plataformas del nexo
• Canal de puerto virtual

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Software corriente del nexo 7000 8.1(1)

• Supervisor N7K-SUP2E

• Linecard N7K-M348XP-25L

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Topología

Configurar

El Switch A y el switch B son pares de VPC.

Sender1 está conectado en el VLA N 50 (10.200.255.230, 239.3.0.2)

Sender2 está conectado con L3_swicth/Router en el VLA N 30 y el VPC-par conocido vía VLAN25 (10.30.30.30, 239.3.0.2)

Receiver1 está conectado en un puerto huérfano 4/1 en el Switch A

Receiver2 está conectado en un puerto huérfano 4/1 en el switch B

Switch A

Ip route 10.30.30.0/24 10.25.25.250
ip pim rp-address 10.25.25.250 group-list 224.0.0.0/4
ip pim ssm range 232.0.0.0/8
ip pim pre-build-spt

Switch B

Ip route 10.30.30.0/24 10.25.25.250
ip pim rp-address 10.25.25.250 group-list 224.0.0.0/4
ip pim ssm range 232.0.0.0/8
ip pim pre-build-spt

Fuente conectada con el VLA N del vPC

Receiver1 está pidiendo para el tráfico del grupo 239.3.0.2 y registra continuamente (*, G) en el Switch A en el VLAN10.

El switch B agrega la misma entrada con la ayuda del CFS. El receptor se puede conectar en el puerto de miembro del huérfano o del vpc en VPC vlan.

Puesto que Sender1 está conectado con el tráfico del VLA N de VPC enviado al VLA N 50 y ambos dispositivos del nexo agregan la entrada OIF (S, G).

Ambos dispositivos adelante el tráfico basado en el algoritmo interno de la expedición PIM como el remitente están conectados con el VLA N del vPC directamente.

Switch A# show ip pim internal vpc rpf-source
PIM vPC RPF-Source Cache for Context "default" - Chassis Role Secondary
Source: 10.200.255.230
  Pref/Metric: 0/0
  Ref count: 1
  In MRIB: yes
  Is (*,G) rpf: no
  Source role: Primary
  Forwarding state: Win-force (forwarding)

Switch B# show ip pim internal vpc rpf-source
PIM vPC RPF-Source Cache for Context "default" - Chassis Role Secondary
Source: 10.200.255.230
  Pref/Metric: 0/0
  Ref count: 1
  In MRIB: yes
  Is (*,G) rpf: no
  Source role: secondary
  Forwarding state: Win-force (forwarding) 

El OIF también poblado ambo el vpc mira.

Switch A# show ip mroute

(*, 232.0.0.0/8), uptime: 02:16:01, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

(*, 239.3.0.2/32), uptime: 01:42:35, igmp ip pim
  Incoming interface: Vlan10, RPF nbr: 10.10.10.251
  Outgoing interface list: (count: 1)
    Vlan10, uptime: 01:42:35, igmp, (RPF)

(10.200.255.230/32, 239.3.0.2/32), uptime: 02:15:57, ip pim mrib
  Incoming interface: Vlan50, RPF nbr: 10.200.255.230
  Outgoing interface list: (count: 1)
    Vlan10, uptime: 01:42:35, mrib

Switch B# sh ip mroute

(*, 232.0.0.0/8), uptime: 02:03:17, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

(*, 239.3.0.2/32), uptime: 01:31:59, igmp ip pim
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 1)
    Vlan10, uptime: 01:31:59, igmp

(10.200.255.230/32, 239.3.0.2/32), uptime: 02:03:13, ip pim mrib
  Incoming interface: Vlan50, RPF nbr: 10.200.255.230
  Outgoing interface list: (count: 1)
    Vlan10, uptime: 01:31:59, mrib

Receiver1 consigue la secuencia y tan pronto como el pedido Receiver2 el mismo grupo, el receptor 2 también comience a recibirlo.

Fuente conectada con el router L3

Sender2 está enviando la secuencia al FHRP que es L3_swicth en el VLA N 30, que también está trabajando como el RP en este caso.

L3_swicth remitirá la secuencia hacia el par de VPC en VPC VLAN25. Este tráfico se trata como Multicast sobre el L3 y ambo el par de VPC construirá (S, G).

Pedido Receiver1 y Receiver2 la secuencia de multidifusión y (*, G) creado en ambos pares del vpc.

Puesto que la secuencia Sender2 se recibe sobre PIM en SVI 25 y no no directamente en VPC SVI, sólo un dispositivo (dr) remitirá el tráfico basado en el algoritmo interno de la expedición PIM pues el remitente 2 no está directamente en VPC SVI.

Switch A# show ip pim internal vpc rpf-source
Source: 10.30.30.30
  Pref/Metric: 1/0
  Ref count: 1
  In MRIB: yes
  Is (*,G) rpf: no
  Source role: primary
  Forwarding state: Tie (forwarding)
  MRIB Forwarding state: forwarding

Switch B# sh ip pim internal vpc rpf-source
Source: 10.30.30.30
  Pref/Metric: 1/0
  Ref count: 1
  In MRIB: yes
  Is (*,G) rpf: no
  Source role: secondary
  Forwarding state: Tie (not forwarding)
  MRIB Forwarding state: not forwarding

Por lo tanto OIF poblado solamente en el Dr.

Switch A# show ip mroute
IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 02:37:29, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

(*, 239.3.0.2/32), uptime: 02:37:26, igmp ip pim
  Incoming interface: Vlan25, RPF nbr: 10.25.25.250
  Outgoing interface list: (count: 1)
    Vlan10, uptime: 02:37:26, igmp

(10.30.30.30/32, 239.3.0.2/32), uptime: 02:37:26, ip mrib pim
  Incoming interface: Vlan25, RPF nbr: 10.25.25.250
  Outgoing interface list: (count: 1)
    Vlan10, uptime: 02:37:26, mrib

Switch B# show ip mroute
(*, 232.0.0.0/8), uptime: 02:38:15, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

(*, 239.3.0.2/32), uptime: 02:38:15, igmp ip pim
  Incoming interface: Vlan25, RPF nbr: 10.25.25.250
  Outgoing interface list: (count: 1)
    Vlan10, uptime: 02:38:15, igmp

(10.30.30.30/32, 239.3.0.2/32), uptime: 02:38:15, ip mrib pim
  Incoming interface: Vlan25, RPF nbr: 10.25.25.250
  Outgoing interface list: (count: 1) >>>>>> no OIF

En este caso como Receiver1 consigue la secuencia y el receptor 2 nunca conseguirán la secuencia debido a faltar el OIF en el switch B. 

Fuente conectada entre diverso VRF

                                                                                                                                                                                                                         

El tráfico Multicast se remite a solamente un receptor en vlan10 conectado con el par primario del vpc mientras que el receptor conectado con el par secundario no lo recibe.

1. El Multicast enviado al fex en 50 vlan (vpc vlan), en este caso, Switch A y switch B tiene OIF para VRF B mientras que la fuente está conectada directamente con ella y está en el vpc vlan.
2. Este tráfico se remite a 51 vlan hacia el VRF A situado en un diverso VDC y enviado al RP. 
3. Este VDC tiene 11 vlan en VRF A y 51 vlan en el valor por defecto VRF.
4. El tráfico ahora se envía al Switch A 11 vlan que está en VRF A.
5. Solamente uno del conmutador A/Switch B tiene OIF para el VRF A debido a la misma limitación mencionada en el remitente 2 conectado con el caso del router L3.
6. El Receiver1 conectado con el Switch A con el OIF consigue la secuencia de multidifusión.

Esto es una limitación de diseño.

El par de VPC puede solamente tener OIF instalado en ambo el Switches si el tráfico es remitido directamente por el remitente en el VLA N de VPC y no por el PIM.

Por lo tanto el OIF instaló en VRF A como remitente conectado directamente con el VRF A, pero no en VRF B como está conectado vía PIM.

Para conseguir el OIF en ambos pares de VPC, el remitente se debe conectar directamente con el VLA N del vpc.

Esta característica será ejecutada después como parte de "L3 sobre característica de VPC”

Referencia

Defectos conocidos