Reenvío multidifusión en vPC basado en la ubicación del origen
Contenido
Introducción
Este documento explica varios escenarios de reenvío de multidifusión cuando un origen se coloca en un entorno vPC
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
- Nexus 7000 que ejecuta el software 8.1(1)
-
Supervisor N7K-SUP2E
-
Tarjeta de línea N7K-M348XP-25L
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Topología
Configurar
Los switches A y B son pares VPC.
El remitente1 está conectado en la VLAN 50 (10.200.255.230, 239.3.0.2)
El Enviador 2 está conectado a L3_switch/Router en la VLAN 30 y es conocido por el peer vpc a través de la VLAN 25 (10.30.30.30, 239.3.0.2)
El receptor 1 está conectado en un puerto huérfano 4/1 en el switch A
El receptor 2 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
Origen conectado a la VLAN vPC
Receiver1 solicita continuamente el tráfico del grupo 239.3.0.2 y registra el (*, G) en el Switch A en la VLAN 10.
El switch B agrega la misma entrada con la ayuda del CFS. El receptor se puede conectar en puerto de miembro huérfano o vpc en VPC vlan.
Dado que el remitente1 está conectado al tráfico de VLAN VPC enviado a VLAN 50 y ambos dispositivos Nexus agregan entrada OIF (S, G).
Ambos dispositivos reenvían el tráfico basado en el algoritmo de reenvío interno PIM a medida que el remitente se conecta directamente a la VLAN vPC.
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)
La OIF también se rellena con los dos pares de vpc.
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 obtiene la secuencia y tan pronto como el Receptor2 solicita el mismo grupo, el Receptor 2 también comienza a recibirla.
Origen conectado al router L3
El Enviador 2 está enviando el flujo al FHRP que es L3_switch en la VLAN 30, que también funciona como RP en este caso.
L3_swicth reenviará el flujo hacia el peer VPC en la VLAN 25 de VPC. Este tráfico se trata como multicast sobre L3 y ambos pares VPC construirán el (S, G).
Petición Receiver1 y Receiver2 para la secuencia multicast y (*, G) creada en ambos pares vpc.
Dado que la secuencia Sender2 se recibe sobre PIM en SVI 25 y no directamente en VPC SVI, sólo un dispositivo (DR) reenviará el tráfico basándose en el algoritmo de reenvío interno PIM, ya que 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, la OIF sólo se rellena en 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, cuando el Receptor1 obtiene el flujo y el Receptor 2 nunca obtendrá el flujo debido a la ausencia de OIF en el Switch B.
Origen conectado entre diferentes VRF
El tráfico de multidifusión se reenvía a sólo un receptor en vlan10 conectado al peer vpc primario mientras que el receptor conectado al peer secundario no lo recibe.
- La multidifusión enviada a fex en vlan 50 (vpc vlan), en este caso, tanto el Switch A como el Switch B tienen OIF para VRF B ya que el origen está conectado directamente a él y está en vpc vlan.
- Este tráfico se reenvía a vlan 51 hacia el VRF A ubicado en un VDC diferente y se envía al RP.
- Este VDC tiene vlan 11 en el VRF A y vlan 51 en el VRF predeterminado.
- El tráfico ahora se envía al switch A vlan 11 que está en el VRF A.
- Solamente uno de los Switch A/Switch B tiene OIF para el VRF A debido a la misma limitación mencionada en el caso del Enviador 2 conectado al router L3 .
- El Receptor1 conectado al Switch A con OIF obtiene el flujo de multidifusión.
Esta es una limitación de diseño.
El par VPC sólo puede tener OIF instalado en ambos switches si el tráfico es reenviado directamente por el remitente en la VLAN VPC y no por el PIM.
Por lo tanto, OIF instalado en el VRF A como remitente conectado directamente al VRF A, pero no en el VRF B ya que está conectado a través de PIM.
Para obtener la OIF en ambos peers VPC, el remitente debe estar conectado directamente a la VLAN vpc.
Esta función se implementará más adelante como parte de la función "L3 sobre VPC"
Referencia
Defectos conocidos
Comentarios