Enrutamiento de multidifusión EVPN entre VLAN con optimización
Capítulo EVPN Inter-VLAN Multicast Routing without Optimization se han examinado los principios del enrutamiento de multidifusión InterVLAN en una estructura de DC EVPN con PIM, usando un enrutador M externo y con PIM habilitado en IRB en los dispositivos BL. También exploró las características de la multidifusión entre VLAN, en ausencia de optimizaciones como la supervisión de IGMP, el reenvío selectivo (SMET) y la replicación asistida. En este capítulo, exploramos lo que sucedemos Si activamos estas optimizaciones.
Con las optimizaciones, los procedimientos básicos de enrutamiento L3 para la multidifusión entre subredes no cambian. Enrutamiento de envío el tráfico de multidifusión de ruta se reenvía selectivamente a aquellos PEs que expresamente han expresado un interés de oyentes para ese grupo. Los procedimientos optimizados de enrutamiento de multidifusión a VLAN se siguen para cada una de las VLAN receptoras.
Reenvío de multivlan con multidifusión selectivo (SMET)
En Figure 1, el tipo de base 2 en el de la hoja 1 de los originados del tipo 6 en v-red y de hoja-3 se origina en v-Blue basándose en los informes IGMP recibidos. BL-2, que es PIM-DR para v-Blue, dirige el tráfico desde v-red a v-Blue. Enrutamiento post, BL-2 L2: reenvía el tráfico de v-Blue a solo LEAF-3 y BL-1 por los procedimientos de multidifusión en subred optimizados descritos en EVPN Intra-VLAN Multicast with Optimization . Las hojas que no tienen agentes de escucha para v-Blue, LEAF-1, hoja-2 y hoja-5 reciben tráfico de multidifusión enrutado para v-Blue.
Multivlan multidifusión con varias VLAN de escucha
En una estructura EVPN, habrá varias VLAN receptoras en las que se debe enrutar el tráfico. Puede apreciarse el reenvío selectivo de multidifusión (SMET) en una situación en la que hay varias VLAN con reenvío de multidifusión entre VLAN. Considere Figure 2 la posibilidad de que haya dos receptores de VLAN, es decir v-Blue y v-Green. El número de redes VLAN se encuentra en el orden de centenares. Y deje’que diga que BL-1 es PIM-Dr para Blue y el BL-2 es el PIM-Dr para el verde.
Con la multidifusión optimizada habilitada, hoja 2 dará como origen el tipo 6 (v-Blue) y hoja-4 dará como origen el tipo-6 (v-verde). Además, hoja-3 será de tipo de origen-6 (v-red). Cuando el código fuente empieza a enviar tráfico en v-red, LEAF-1 reenviará el tráfico a los dos BLs y a hoja-3 en v-red. HOJA-3 reenviará a su host de acceso recib-red-1.
Cuando el BL-1 recibe el tráfico en v-red, enrutará el tráfico a v-Blue, ya que se trata de PIM-DR on v-Blue. La distribución posterior en la v-Blue será L2: reenviará el tráfico a los demás procedimientos de multidifusión selectivo (BL y hoja-2) de la red interna. HOJA-2 reenviará el tráfico de v-Blue a su interfaz de acceso a la de recib-Blue-1.
Del mismo modo, cuando el cable BL-2 recibe el tráfico en v-red, enrutará el tráfico hacia el en v-verde ya que es PIM-DR on v-Green. La posruta en v-Green será L2-reenviará el tráfico al otro cable BL y a hoja-4 por procedimientos de multidifusión selectivos. HOJA-4 reenviará el tráfico en su interfaz de acceso a la recepción-verde-1.
BL-1 recibirá el mismo tráfico de BL-2 en IRB. v-verde. Este tráfico será rechazado debido a que no coinciden con IIF, ya’que BL-1 s RPF para el origen está sobre IRB v-red.
Por lo tanto, el tráfico sólo se envía al PEs requerido y sólo a las interfaces de acceso en las VLAN del receptor, con lo que se conserva el ancho de banda y los recursos en cada VLAN del receptor.
Interconexiones de multivlan multidifusión con AR y SMET
Ahora vamos’a usar un tejido de centro de datos EVPN típico Figure 3que se ilustra en, donde los dispositivos BL se activan con PIM en IRBs. Aunque los dispositivos BL L3-PIM son de gama alta, cuando es necesario llevar a cabo varias replicaciones de VLAN y varias de entrada para enviar a varias hojas del tejido, existe la posibilidad de que el BLs se quede abrumado. Incluso si los dispositivos BL se mantienen bien, en términos de duplicación, es posible que el vínculo entre el BLs y el de la deformación no pueda llevar las copias replicadas múltiples.
Además de la SMET, al activar AR en el tejido, se obtienen mejoras adicionales en la transferencia de la carga de la replicación de los dispositivos BL al AR-Replicator, lo que también reduce la banda ancha del enlace entre el cable BL y el AR-R.
En Figure 3, en la, hoja-2 y hoja-4 tienen un interés de escuchas en v-Blue, mientras que hoja-2 y hoja-5 tienen interés de oyente en v-Green. Por ejemplo, el cable BL-1 es PIM Dr for v-Blue y BL-2 es PIM DR for v-Green, y tenemos la optimización SMET de AR Plus en la estructura del centro de datos.
Cuando el origen envía tráfico en v-red, LEAF-1, que es la hoja AR, envía sólo una copia del paquete a AR-Replicator, por ejemplo, AR-1. Ahora, AR-1 Replica este paquete en BLs debido a que BLs ejecuta PIM, y restablece el bit en la comunidad de marcadores de multidifusión (MF-COM). Consulte EVPN Intra-VLAN Multicast with Optimization .
BL-1, al ser un dispositivo con PIM habilitado y PIM-Blue, dirige el tráfico de v-red a v-Blue. Generalmente, sin AR, BL habría duplicado dos copias para enviarlas a hoja-2 y hoja-4. Asimismo, el enlace entre el cable BL-1 y el AR-2 llevaría dos copias del mismo paquete. Con AR, BL-1, que es la hoja AR, envía sólo un paquete a uno de los clientes AR-Replicators, por ejemplo, AR-2. Ahora, AR-2 replica el paquete en v-Blue a hoja-2 y hoja-4.
Del mismo modo, el cable BL-2, The PIM DR on v-Green, dirige el paquete de v-red a v-Green. Dado que BL-2 es una hoja de niveles AR, en lugar de hacer varias copias, envía una copia al replicador AR-2. AR-R2 replica y envía debidamente el paquete de v-verde a hoja-2 y hoja-5.
A partir de la recepción del tráfico, se extrae la hoja 3 y el resto de las hojas (hojas-6 a hoja-200). No es necesario decir que las interfaces de acceso de las hojas que’no tienen escuchas también se han puesto de sobra de tráfico.
Por lo tanto, AR y SMET, cuando se utiliza en un entorno de multidifusión entre VLAN, aporta las siguientes ventajas en cada una de las VLAN de escucha:
Conservación del ancho de banda central
Reducción de la carga de replicación en la hoja y BLs
Reenvío selectivo por las hojas, BLs y los replicadores AR
Reducción de la utilización de vínculos entre el nodo/BL y las rotaciones imeficientes
Conservación del ancho de banda de acceso
Reducción de la carga del procesamiento de tráfico innecesario de multidifusión recibido del núcleo
En una configuración a escala, dichos esquemas de optimización ayudan a reducir la carga de la duplicación de paquetes, el procesamiento y el uso del ancho de banda principal. Por lo tanto, AR Plus SMET aporta a EVPN estructura del centro de datos el equivalente a la de multidifusión tradicional selectiva P2MP.
También’existe la carga compartida en varios niveles:
Capa de hoja: Los dispositivos de hoja eligen uno de los replicadores para la replicación para diferentes flujos. En virtud de esto, los distintos subyacente que se vinculan entre la hoja y los replicadores son Equitably compartidos.
Capa BL: Los distintos dispositivos BL son PIM para las distintas VLAN. Por lo tanto, la carga del enrutamiento para diferentes VLANs se comparte entre los dispositivos BL.
Cuando los dispositivos de hoja son de host múltiple, sólo el DF avanza, con lo que se ahorra el ancho de banda de acceso. Por lo tanto, se realiza la elección de DF de modo que distintos dispositivos de hoja entre un conjunto multitarjeta se convierten en DFs para distintas VLAN.
Optimizado enàlas MCAST intervlans no optimizadas en todo el tiempo
Vamos’a hacer algunas comparaciones de manera similar a cómo calculamos en la Assisted Replication with SMET capítulo. Considere un caso en el que hay 200 hojas en una estructura del centro de datos. Suponga que existe un gran volumen de tráfico de multidifusión para 20 grupos, cada grupo tiene una tasa de tráfico de 1 Mbps y hay 10 hojas en la estructura que interesa cada grupo en cada VLAN. Además, suponga que hay 500 VLANs en la estructura del centro de datos. Es’decir, caracterizar el comportamiento de cada mecanismo.
Número de hojas en el tejido: N = 200
Número de grupos: G = 20
Velocidad de tráfico: R = 1 Mbps
Número de hojas interesadas en el tráfico por VLAN por Grupo: T = 10
Número de redes VLAN en el tejido M = 500
Non-optimized Multicast
Consumo de ancho de banda principal:
(N * G * R * M) = (200 * 20 * 1 * 500) = 2000 Gbps
Carga de replicación en BL:
(N * G * M) = 200 * 20 * 500 = = 2 millones de veces
Consumo de ancho de banda de vínculo entre BL y lean-Spine:
(N * G * R * M) = (200 * 20 * 1 * 500) = 2000 Gbps
Assisted Replication
Consumo de ancho de banda principal:
(N * G * R * M) = (200 * 20 * 1 * 500) = 2000 Gbps
Carga de replicación en BL:
(1 * G * M) = 1 * 20 * 500 = 10K Times
Consumo de ancho de banda de vínculo entre BL y lean-Spine:
(1 * G * R * M) = (1 * 20 * 1 * 500) = 10 Gbps
Optimized Multicast (SMET Forwarding) without AR
Consumo de ancho de banda principal:
(T * G * R * M) = (10 * 20 * 1 * 500) = 100 Gbps
Carga de replicación en BL para cada paquete recibido del núcleo:
(T * G * M) = (10 * 20 * 500) = 100 veces
Conexión del consumo de ancho de banda entre la hoja y la espina inclinada:
(T * G * R * M) = (10 * 20 * 1 * 500) = 100.000 = 100 Gbps
AR + SMET
Consumo de ancho de banda principal:
(T * G * R * M) = (10 * 20 * 1 * 500) = 100 Gbps
Carga de replicación en BL para cada paquete recibido del núcleo:
(1 * G * M) = (1 * 20 * 500) = 10 mil veces
Consumo de ancho de banda de vínculo entre BL y lean-Spine:
(1 * G * R * M) = (1 * 20 * 1 * 500) = 10 Gbps
Con AR y SMET puede observar que se reduce de manera significativa el consumo general de ancho de banda. Además, se reduce considerablemente la utilización entre el dispositivo BL y el de la espina de deeficiente. Consulte Table 1 y Figure 4 y Figure 5. Además, la carga de replicación de BLs se reduce.
Table 1: Consumo de ancho de banda
Número de redes VLAN en el tejido: 500 | |||||
Número de TORs en el tejido: N = 200 | Número de grupos: G = 20 | ||||
Número de TORs interesados en la estructura: T = 10 | Velocidad de tráfico: R = 1 Mbps | ||||
Multivlan, multidifusión | Multidifusión no optimizada | AR | SMET | AR + SMET | Factor de ganancia: Vis de AR + SMET con respecto a la no optimizada |
Consumo del ancho de banda principal (en Gbps) | 2000 | 2000 | 100 | 100 | 20 |
Carga de replicación en TOR que hospedan el origen | 2000K | 10K | 100K | 10K | 200 |
Uso de ancho de banda de vínculo entre TOR y lomo eficiente (en Gbps) | 2000 | 10 | 100 | 10 | 200 |
Resumen del capítulo
Este capítulo ha explorado el comportamiento de multidifusión entre VLAN cuando se implementa con optimización. La multidifusión entre VLAN, per se, no tiene cambio de procedimiento. Sin embargo, con los esquemas de optimización, las ventajas se acumulan, ya que éstas son aplicables en cada una de las VLAN de escucha donde se enruta el tráfico. También hemos examinado las diferentes ventajas cuantitativas en un caso de uso típico y explicamos cómo todas las técnicas de optimización de la parte I del libro desempeñan un papel crucial en la multivlan.
Por lo tanto, habiendo cubierto la multidifusión intra-VLAN y inter-VLAN dentro de una’estructura de centro de datos, es hora de explorar las distintas maneras en que esta estructura puede conectarse al mundo exterior y se puede enviar/recibir tráfico de multidifusión de/a la estructura.
Configuración y comprobación
Hasta ahora, nuestros orígenes y receptores han estado en la misma VLAN, VLAN-101. Habiendo explorado la multidifusión InterVLAN, ahora estamos listos para ver el comportamiento de la multidifusión cuando tenemos los orígenes y los destinatarios en el DC pero en distintas VLAN.
Antes de empezar,’deje que se detengan todas las fuentes y los receptores que se iniciaron previamente.
Configuration
Aunque tenemos, hasta ahora, enfocado únicamente en VLAN-101, nuestra configuración básica siempre ha incluido VLAN-102. Por lo tanto, las configuraciones que se realizan en EVPN capítulo de EVPN Inter-VLAN Multicast Routing without Optimization son suficientes para esta sección y podemos pasar directamente a la verificación de tráfico. Recuerde también que nuestras configuraciones ya incluyen optimizaciones SMET y AR.
Traffic Verification
Como antes, comience a enviar tráfico de multidifusión desde host-1 a 10 PPS (paquetes por segundo) para el grupo 225.1.1.1 en VLAN-101.
En host-6 y host-3, inicie los receptores del grupo de multidifusión, 225.1.1.1, pero esta vez en las dos VLAN-101 y VLAN-102.
A partir de las estadísticas de RT, puede ver que el tráfico enviado por host-1 en 10 PPS lo reciben ahora los receptores interesados, host-6 y host-3, y el dispositivo heredado, host-7, en las VLAN-101 y VLAN-102, lo que da como resultado 20 PPS del tráfico entrante en cada uno de ellos.
Multicast Traffic Outputs - LEAF-1, LEAF-2, LEAF-4, LEAF-5, SPINE-2 (VLAN-101)
El comportamiento de reenvío de tráfico para el tráfico de multidifusión que llega a VLAN-101 será el mismo que en el caso de estos dispositivos. Por lo tanto, este flujo contribuye a 10 PPS del tráfico que se ve en host-2, host-6 y host-8.
Ten en cuenta que el tráfico también se replica mediante lomo-2 a BL-1 y BL-2. Hemos retrasado hasta ahora mirar el comportamiento de reenvío de tráfico en estos dispositivos. Ahora que se comprenden los procedimientos interrelacionados’entre VLAN, deje que vea lo que sucede con el tráfico en estos dispositivos.
BL-1, BL-2
VLAN-101 no tiene interfaces de acceso en los dispositivos con hojas de borde, por lo que no hay más conmutación del tráfico de multidifusión en ninguno de los dos. Sin embargo, un IRB habilitado de multidifusión (PIM + IGMP) se asocia con la VLAN en ambos dispositivos.
Dado que el BL-2 tiene una dirección IP más alta, se elige como PIM-DR on IRB. 101 (VLAN-101).
En IRB. 102, dado que configuramos una prioridad de DR específica en BL-1, a pesar de que tiene un IP inferior, se elige como DR PIM en IRB. 102 (VLAN-102):
lab@BL-1> show pim interfaces instance VRF-1 Stat = Status, V = Version, NbrCnt = Neighbor Count, S = Sparse, D = Dense, B = Bidirectional, DR = Designated Router, DDR = Dual DR, DistDR = Distributed DR, P2P = Point-to-point link, P2MP = Point-to-Multipoint, Active = Bidirectional is active, NotCap = Not Bidirectional Capable Name Stat Mode IP V State NbrCnt JoinCnt(sg/*g) DR address irb.101 Up S 4 2 NotDR,NotCap 1 1/0 18.18.18.2 irb.102 Up S 4 2 DR,NotCap 1 0/0 19.19.19.1 lo0.1 Up S 4 2 DR,NotCap 0 0/0 101.101.101.102 pime.32770 Up S 4 2 P2P,NotCap 0 0/0 lab@BL-2> show pim interfaces instance VRF-1 Stat = Status, V = Version, NbrCnt = Neighbor Count, S = Sparse, D = Dense, B = Bidirectional, DR = Designated Router, DDR = Dual DR, DistDR = Distributed DR, P2P = Point-to-point link, P2MP = Point-to-Multipoint, Active = Bidirectional is active, NotCap = Not Bidirectional Capable Name Stat Mode IP V State NbrCnt JoinCnt(sg/*g) DR address irb.101 Up S 4 2 DR,NotCap 1 1/0 18.18.18.2 irb.102 Up S 4 2 NotDR,NotCap 1 0/0 19.19.19.1 lo0.1 Up S 4 2 DR,NotCap 0 0/0 102.102.102.103 pime.32769 Up S 4 2 P2P,NotCap 0 0/0
Multicast Traffic Outputs – BL-1, BL-2
Dado que hay un receptor de interés en IRB. 102, BL-1 son las DR PIM en IRB. 102, distribuye el tráfico que llega a IRB. 101 en IRB. 102 (es decir, VLAN-102):
lab@BL-1> show multicast route extensive instance VRF-1 Instance: VRF-1 Family: INET Group: 225.1.1.1 Source: 18.18.18.30/32 Upstream interface: irb.101 Downstream interface list: irb.102 Number of outgoing interfaces: 1 Session description: Unknown Statistics: 1 kBps, 10 pps, 917043 packets Next-hop ID: 131102 Upstream protocol: PIM Route state: Active Forwarding state: Forwarding Cache lifetime/timeout: 360 seconds Wrong incoming interface notifications: 33 Uptime: 00:03:15
BL-1 luego reenvía el tráfico enrutado en VLAN-102 hacia uno de los giros de AR-Replicator: en este caso, espina-1 (AR-IP = 103.103.103.113).
Además, el tráfico también se envía a través del VTEP hacia el BL-2 (102.102.102.102), ya que es de hosts múltiples a BL-1 (consulte el capítulo Assisted Replication : Reglas de reenvío de Enhanced-AR):
lab@BL-1> show interfaces vtep extensive | grep “Output packets.*pps|VXLAN Endpoint Address” VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 102.102.102.102… Output packets: 4194 10 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 105.105.105.105… Output packets: 57 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 106.106.106.106… Output packets: 57 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 107.107.107.107… Output packets: 0 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 108.108.108.108… Output packets: 55 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 109.109.109.109… Output packets: 57 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 103.103.103.113… Output packets: 4212 9 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 103.103.103.103… Output packets: 1 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 104.104.104.104… Output packets: 0 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 104.104.104.114… Output packets: 3996 0 pps
Multicast Traffic Outputs - SPINE-1 (VLAN-102)
SPINe-1 replica de forma selectiva el tráfico del túnel AR recibido desde BL-1 en VLAN-102 a LEAF-1 (105.105.105.105), hoja-2 (106.106.106.106) y hoja-4 (108.108.108.108), que tienen los receptores interesados, y la hoja de dispositivos heredados-5 (109.109.109.109):
lab@SPINE-1> show interfaces vtep extensive | grep “Output.*packets.*pps|VXLAN Endpoint Type” VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 108.108.108.108… Output packets: 18136 9 pps VXLAN Endpoint Type: AR Remote, VXLAN Endpoint Address: 108.108.108.108… Output packets: 0 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 101.101.101.101… Output packets: 5601 0 pps VXLAN Endpoint Type: AR Remote, VXLAN Endpoint Address: 101.101.101.101… Output packets: 0 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 102.102.102.102… Output packets: 3525 0 pps VXLAN Endpoint Type: AR Remote, VXLAN Endpoint Address: 102.102.102.102… Output packets: 0 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 109.109.109.109… Output packets: 18137 10 pps VXLAN Endpoint Type: AR Remote, VXLAN Endpoint Address: 109.109.109.109… Output packets: 0 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 105.105.105.105… Output packets: 10984 10 pps VXLAN Endpoint Type: AR Remote, VXLAN Endpoint Address: 105.105.105.105… Output packets: 0 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 106.106.106.106… Output packets: 10980 10 pps VXLAN Endpoint Type: AR Remote, VXLAN Endpoint Address: 106.106.106.106… Output packets: 0 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 107.107.107.107… Output packets: 1614 0 pps VXLAN Endpoint Type: AR Remote, VXLAN Endpoint Address: 107.107.107.107… Output packets: 0 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 104.104.104.104… Output packets: 10536 0 pps VXLAN Endpoint Type: AR Remote, VXLAN Endpoint Address: 104.104.104.104… Output packets: 0 0 pps VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 104.104.104.114… Output packets: 0 0 pps
Multicast Traffic Outputs - LEAF-1 (VLAN-102)
HOJA-1 recibe 10 PPS de tráfico de multidifusión de espina-1 en VLAN-102.
Aunque hoja-1 ha aprendido un receptor IGMP interesado en la VLAN-102 en su interfaz de acceso AE 1.0, las reglas de clásico-DF-NDF impiden que hoja 1 reenvíe el tráfico de multidifusión en esta interfaz.
Las otras interfaces de Access, AE 0.0 y xe-0/0/4.0, no tienen ningún interés de los receptores y los procedimientos de supervisión IGMP garantizan que el tráfico no se reenvía a estas interfaces:
lab@LEAF-1> monitor interface traffic detail Interface Link Input packets (pps) Output packets (pps) Description … xe-0/0/4 Up 0 (0) 2564 (0) TO Host-2 … ae0 Up 16487 (10) 0 (0) TO CE-1 ae1 Up 0 (0) 9260 (10) TO CE-2 …
Así que LEAF-1 reenvía de manera eficaz solo 10 PPS en VLAN-101 a host-3.
Multicast Traffic Outputs – LEAF-2 (VLAN-102)
HOJA-2 recibe 10 PPS de tráfico de multidifusión de espina-1 en VLAN-102.
Las siguientes reglas clásica-DF-NDF y los procedimientos de supervisión IGMP en VLAN-102, LEAF-2 son el DF, reenvía el tráfico de multidifusión al receptor IGMP interesado en su interfaz de acceso AE 1.0.
Las otras interfaces de Access, AE 0.0 y xe-0/0/4.0, no tienen ningún interés de los receptores y los procedimientos de supervisión IGMP garantizan que el tráfico no se reenvía a estas interfaces:
lab@LEAF-2> monitor interface traffic detail Interface Link Input packets (pps) Output packets (pps) Description … xe-0/0/4 Up 0 (0) 0 (0) TO Host-4 … ae0 Up 7 (0) 0 (0) TO CE-1 ae1 Up 16 (0) 9561 (10) TO CE-2 …
HOJAS-2 reenvía 10 PPS en VLAN-102 a host-3. Por lo tanto, de hoja 1 y hoja 2, se cuenta para el tráfico total de 20 PPS que se ve en el host-3.
Multicast Traffic Outputs – LEAF-4 (VLAN-102)
HOJA 4 recibe 10 PPS de tráfico de multidifusión de espina-1 en VLAN-102.
La funcionalidad de supervisión IGMP de acceso garantiza que el tráfico de multidifusión que llega a la hoja 4 en VLAN-102 se reenvía a la interfaz de host único xe-0/0/3.0, que tiene un receptor, pero no en la interfaz multitarjeta AE 0.0, que no cuenta con un receptor.
Recuerde que el tráfico de VLAN-101 también se reenvió en la interfaz de host único que interese, XE-0/0/3.0. Por lo tanto, estas juntas tienen en cuenta el tráfico de 20 PPS visto por la salida xe-0/0/3.0 y recibidos en host-6.
lab@LEAF-2> monitor interface traffic detail Interface Link Input packets (pps) Output packets (pps) Description … xe-0/0/3 Up 0 (0) 8283 (20) TO Host-6 ae0 Up 7 (0) 0 (0) TO CE-3 …
Multicast Traffic Outputs - LEAF-5
Si hoja 5 es un dispositivo heredado, recibirá el tráfico en la VLAN-102 y lo inundará en su interfaz de acceso, XE-0/0/2,0, aunque no tenga un receptor.
Recuerde que el tráfico de VLAN-101 también se reenvió en la interfaz xe-0/0/2.0. Por lo tanto, juntos cuenta el tráfico de 20 PPS visto como salida xe-0/0/2.0 y recibido en host-7:
lab@LEAF-5> monitor interface traffic detail Interface Link Input packets (pps) Output packets (pps) Description … xe-0/0/2 Up 0 (0) 8666 (20) TO Host-7 …
Verificación detallada del plano de control
Hasta ahora nos hemos centrado en los Estados de multidifusión L2 integrados en los PEs. Para enrutar el tráfico, además de los Estados de multidifusión L2, los Estados de multidifusión L3 también deben estar configurados correctamente en los PEs que están configurados con IRBs y actúan como enrutadores de multidifusión en nuestro caso son los dispositivos de hojas de borde, BL-1 y BL-2. Una vez que el tráfico de multidifusión se enruta en el PEs de borde de hojas y se envía hacia el PEs de hoja, la conmutación L2 del tráfico en el PEs de la hoja se produce utilizando los Estados intra-VLAN de forma similar a lo que ya se ha tratado detalladamente en los capítulos anteriores.
Verification of Layer 3 IGMP State
Compruebe que en el BL-1, además del estado de proxy de supervisión IGMP aprendido en las VLAN-101 y VLAN-102, la pertenencia al grupo IGMP de EVPN se ha aprendido en las interfaces L3 correspondientes, IRB. 101 y IRB. 102, así:
lab@BL-1> show evpn igmp-snooping proxy Instance: default-switch VN Identifier: 101 Group IP: 225.1.1.1, Source IP: 0.0.0.0 VN Identifier: 102 Group IP: 225.1.1.1, Source IP: 0.0.0.0 lab@BL-1> show igmp group detail Interface: irb.101, Groups: 1 Group: 225.1.1.1 Group mode: Exclude Source: 0.0.0.0 Source timeout: 0 Last reported by: Local Group timeout: 0 Type: EVPN … Interface: irb.102, Groups: 1 Group: 225.1.1.1 Group mode: Exclude Source: 0.0.0.0 Source timeout: 0 Last reported by: Local Group timeout: 0 Type: EVPN …
Verificar que también se han aprendido los mismos Estados en BL-2:
lab@BL-2> show evpn igmp-snooping proxy Instance: default-switch VN Identifier: 101 Group IP: 225.1.1.1, Source IP: 0.0.0.0 VN Identifier: 102 Group IP: 225.1.1.1, Source IP: 0.0.0.0 lab@BL-2> show igmp group detail Interface: irb.102, Groups: 1 Group: 225.1.1.1 Group mode: Exclude Source: 0.0.0.0 Source timeout: 0 Last reported by: Local Group timeout: 0 Type: EVPN … Interface: irb.101, Groups: 1 Group: 225.1.1.1 Group mode: Exclude Source: 0.0.0.0 Source timeout: 0 Last reported by: Local Group timeout: 0 Type: EVPN …
Verification of Layer 3 PIM State
Verifica que en el estado BL-1 y BL-2 PIM haya sido creado para el Grupo:
lab@BL-1> show pim join extensive instance VRF-1 Instance: PIM.VRF-1 Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 225.1.1.1 Source: * RP: 101.101.101.102 Flags: sparse,rptree,wildcard Upstream interface: Local Upstream neighbor: Local Upstream state: Local RP Uptime: 00:05:44 Downstream neighbors: Interface: irb.101 18.18.18.1 State: Join Flags: SRW Timeout: Infinity Uptime: 00:05:44 Time since last Join: 00:05:44 Interface: irb.102 19.19.19.1 State: Join Flags: SRW Timeout: Infinity Uptime: 00:05:44 Time since last Join: 00:05:44 Number of downstream interfaces: 2 Number of downstream neighbors: 2 Group: 225.1.1.1 Source: 18.18.18.30 Flags: sparse,spt Upstream interface: irb.101 Upstream neighbor: Direct Upstream state: Local Source, Local RP, No Prune to RP Keepalive timeout: 335 Uptime: 00:20:58 Downstream neighbors: Interface: irb.102 19.19.19.2 State: Join Flags: S Timeout: Infinity Uptime: 00:05:53 Time since last Join: 00:05:53 Number of downstream interfaces: 1 Number of downstream neighbors: 1 lab@BL-2> show pim join extensive instance VRF-1 Instance: PIM.VRF-1 Family: INET R = Rendezvous Point Tree, S = Sparse, W = Wildcard Group: 225.1.1.1 Source: * RP: 102.102.102.103 Flags: sparse,rptree,wildcard Upstream interface: Local Upstream neighbor: Local Upstream state: Local RP Uptime: 00:05:53 Downstream neighbors: Interface: irb.102 19.19.19.2 State: Join Flags: SRW Timeout: Infinity Uptime: 00:05:53 Time since last Join: 00:05:53 Interface: irb.101 18.18.18.2 State: Join Flags: SRW Timeout: Infinity Uptime: 00:05:53 Time since last Join: 00:05:53 Number of downstream interfaces: 2 Number of downstream neighbors: 2 Group: 225.1.1.1 Source: 18.18.18.30 Flags: sparse,spt Upstream interface: irb.101 Upstream neighbor: Direct Upstream state: Local Source, Local RP, No Prune to RP Keepalive timeout: 328 Uptime: 00:21:07 Downstream neighbors: Interface: irb.101 18.18.18.2 State: Join Flags: S Timeout: Infinity Uptime: 00:05:53 Time since last Join: 00:05:53 Number of downstream interfaces: 1 Number of downstream neighbors: 1
Verification of Layer 3 Multicast Forwarding State
Compruebe que el BL-1 recibe el tráfico en el origen VLAN-101 en IRB. 101, y que es el DR PIM en la VLAN del receptor, VLAN-102 (IRB. 102) enruta el tráfico a VLAN-102 a través de IRB. 102:
lab@BL-1> show multicast route extensive instance VRF-1 Instance: VRF-1 Family: INET Group: 225.1.1.1 Source: 18.18.18.30/32 Upstream interface: irb.101 Downstream interface list: irb.102 Number of outgoing interfaces: 1 Session description: Unknown Statistics: 1 kBps, 10 pps, 917043 packets Next-hop ID: 131102 Upstream protocol: PIM Route state: Active Forwarding state: Forwarding Cache lifetime/timeout: 360 seconds Wrong incoming interface notifications: 33 Uptime: 00:03:15
Compruebe que el BL-2 recibe el tráfico en el origen VLAN-101 en IRB. 101, pero dado que no es el DR PIM en la VLAN del receptor, VLAN-102 (IRB. 102), no dirige el tráfico a VLAN-102 a través de IRB. 102:
lab@BL-2> show multicast route extensive instance VRF-1 Instance: VRF-1 Family: INET Group: 225.1.1.1 Source: 18.18.18.30/32 Upstream interface: irb.101 Number of outgoing interfaces: 0 Session description: Unknown Statistics: 1 kBps, 10 pps, 10575 packets Next-hop ID: 0 Upstream protocol: PIM Route state: Active Forwarding state: Forwarding Cache lifetime/timeout: 360 seconds Wrong incoming interface notifications: 0 Uptime: 00:21:07
Verification of Layer 2 Multicast Forwarding State in the Routed VLAN
En BL-1, el tráfico, por lo tanto, se enrutaba en VLAN-102 mediante IRB. 102 se reenviará en VLAN-102 basándose en el estado de reenvío de multidifusión L2 creado para el grupo 225.1.1.1 y el 18.18.18.30 de origen en VLAN-102:
Dado que estamos utilizando AR, compruebe que el tráfico se reenvía a través del siguiente salto de carga a uno de AR-RS:
lab@BL-1> show multicast snooping route extensive VLAN VLAN-102 group 225.1.1.1 sourceprefix
18.18.18.30
Group: 225.1.1.1/32
Source: 18.18.18.30/32
Vlan: VLAN-102
Mesh-group: __all_ces__
Downstream interface list:
evpn-core-nh -(131092)
…
lab@BL-1> show evpn multicast-snooping next-hops 131092 detail
…
ID Refcount KRefcount Downstream interface Addr
131092 3 1 131084
Flags 0x2100 type 0x18 members 0/0/1/0/0
Address 0xe531928
lab@BL-1> show evpn multicast-snooping assisted-replication next-hops index 131084
Instance: default-switch
AR Role: AR Leaf
VN Identifier: 102
Load Balance Nexthop Index: 131084
Load balance to:
Nexthop Index Interface AR IP
1777 vtep.32777 103.103.103.113
1794 vtep.32780 104.104.104.114
El AR-R que recibe este tráfico en VLAN-102 lo remitirá selectivamente en VLAN-102 a los PEs interesados. Este es el reenvío simple a través de VLAN que ya se ha explicado en los capítulos anteriores; la comprobación se deja como un ejercicio para el lector.