Creación de un TRM multisitio de VXLAN Nexus 9000 mediante DCNM

Introducción

Este documento explica cómo implementar un fabric TRM multisitio Cisco Nexus 9000 VXLAN donde los gateways fronterizos se conectan a través de switches DCI

Topología

Detalles de la topología

• DC1 y DC2 son dos ubicaciones de Data Center que ejecutan VXLAN.
• Los gateways de frontera DC1 y DC2 se conectan entre sí a través de los switches DCI.
• Los switches DCI no ejecutan ninguna VXLAN; Éstos ejecutan eBGP para la capa inferior para la disponibilidad de DC1 a DC2 y Vice Versa. También los switches DCI se configuran con el vrf de arrendatario; En este ejemplo, sería vrf- "tenant-1".
• Los switches DCI también se conectan a redes externas que no son VXLAN.
• Las conexiones VRFLITE se terminan en los Gateways de borde(Compatibilidad con la coexistencia de las funciones VRFLITE y de gateway de borde iniciada a partir de NXOS-9.3(3) y DCNM-11.3(1))
• Los gateways de borde se ejecutan en el modo de difusión; Cuando se ejecuta TRM(Multidifusión enrutada de arrendatarios) en esta versión, los Gateways de borde no se pueden configurar como vPC(consulte la guía de configuración de TRM multisitio para ver otras limitaciones)
• Para esta topología, todos los switches BGW tendrán dos conexiones físicas hacia cada uno de los switches DCI; Un link estará en el VRF predeterminado (que se utilizará para el tráfico entre sitios) y otro link estará en el arrendatario VRF-1 que se utiliza para extender VRFLITE al entorno no vxlan.

Detalles de PIM/multidifusión(específico de TRM)

• El PIM RP subyacente para ambos sitios son los switches de columna y Loopback254 está configurado para el mismo. El PIM RP subyacente se utiliza para que los VTEP puedan enviar los Registros PIM así como las Uniones PIM a las Spines(para los propósitos de la replicación del tráfico BUM para varios VNID)
• Para TRM, RP se puede especificar por diferentes medios; Aquí para el propósito del documento, el PIM RP es el router de núcleo en la parte superior de la topología que es externo al fabric VXLAN. 
• Todos los VTEP tendrán el router de núcleo señalado como PIM RP configurado en los VRF respectivos
• DC1-Host1 está enviando multicast al grupo- 239.144.144.144; DC2-Host1 es el receptor para este grupo en DC2 y un host externo(172.17.100.100) en la vxlan también se está suscribiendo a este grupo
• DC2-Host1 está enviando multicast al grupo- 239.145.145.145; DC1-Host1 es el receptor para este grupo en DC1 y un host externo(172.17.100.100) en la vxlan también se está suscribiendo a este grupo
• DC2-Host2 está en la VLAN 144 y es receptor para los grupos de multidifusión- 239.144.144.144 y 239.100.100.100
• El host externo(172.17.100.100) está enviando tráfico para el cual tanto DC1-Host1 como DC2-Host1 son receptores.
• Esto cubre los flujos de tráfico entre este y oeste y dentro de Vlan y multidifusión norte/sur

Componentes Utilizados

• Switches Nexus 9k que ejecutan 9.3(3)
• DCNM en ejecución 11.3(1)

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.

Pasos de alto nivel

1) Teniendo en cuenta que este documento se basa en dos DC que utilizan la función VXLAN Multisite, se deben crear dos fabric sencillos

2) Crear MSD y mover DC1 y DC2

3) Creación de fabric externo y adición de switches DCI

4) Crear superposición y superposición de varios sitios

5) Creación de adjuntos de extensión VRF en los gateways de borde

6) Verificación del tráfico unidifusión

7) Verificación del Tráfico Multicast

Paso 1: Creación de un fabric sencillo para DC1

• Inicie sesión en DCNM y, desde Panel, seleccione la opción -> "Fabric Builder"

• Seleccione la opción "Crear fabric"

• A continuación, se proporciona el nombre de fabric, la plantilla y, a continuación, en la ficha "General", se rellena el ASN pertinente, la numeración de la interfaz de fabric, Any Cast Gateway MAC(AGM)

# AGM es utilizado por los hosts en el fabric como la dirección MAC de gateway predeterminada. Esto será lo mismo en todos los switches de hoja (ya que todos los switches de hoja del fabric ejecutan el reenvío de fabric de cualquier tipo). La dirección IP y la dirección MAC de la puerta de enlace predeterminada serán las mismas en todos los switches de hoja

• A continuación, se establece el modo de replicación

# El modo de replicación para este propósito de documento es multidifusión; Otra opción es utilizar la replicación de entrada (IR)

# La subred del grupo de multidifusión será el grupo de multidifusión utilizado por los VTEP para replicar el tráfico BUM (como las solicitudes ARP)

# La casilla de verificación "Habilitar multidifusión enrutada de arrendatario (TRM)" debe estar activada

# Rellene otros cuadros según sea necesario.

• La pestaña para vPC se deja intacta, ya que la topología aquí no utiliza ningún vPC
• A continuación se encuentra la ficha Protocolos

# Modifique los cuadros relevantes según sea necesario.

• A continuación, la ficha Advanced (Opciones avanzadas)

# A efectos de este documento, todos los campos se dejan de forma predeterminada.

# El ASN se rellena automáticamente a partir del que se proporcionó en la ficha General.

• A continuación, rellene los campos de la ficha "Recursos"

# El rango de IP de loopback de ruteo subyacente sería el utilizado para protocolos como BGP, OSPF

# El rango IP de loopback VTEP subyacente son los que se utilizarán para la interfaz NVE.

# El RP subyacente es para el RP PIM que se utiliza para los grupos de multidifusión BUM.

• Rellene otras fichas con la información pertinente y después "guardar"

Paso 2: Creación de un fabric sencillo para DC2

• Realice la misma tarea que en el paso 1 para crear un entramado sencillo para DC2
• Asegúrese de proporcionar un bloque de direcciones IP diferente en Recursos para los Loopbacks de NVE y de Ruteo y cualquier otra área relevante
• Los ASN también deben ser diferentes
• Los VNID de Capa 2 y Capa 2 son iguales

Paso 3: Creación de MSD para multisitio

• Deberá crearse un fabric MSD como se muestra a continuación.

• Rellene también la ficha DCI 

# El método de implementación de superposición de IFC multisitio es "Direct_To_BGWS", ya que aquí los DC1-BGW formarán la conexión superpuesta con los DC2-BGW. Los switches DCI que se muestran en la topología son solo dispositivos de capa de tránsito 3 (así como VRFLITE)

• El siguiente paso es mencionar el rango de loopback multisitio(Esta dirección IP se utilizará como la IP de loopback multisitio en BGW DC1 y DC2; DC1-BGW1 y DC1-BGW2 comparten la misma IP de loopback multisitio; DC2-BGW1 y DC2-BGW2 comparten la misma IP de loopback multisitio, pero serán diferentes de la de DC1-BGW

# Una vez rellenados los campos, haga clic en "guardar".

# Una vez que se hayan realizado los pasos 1 a 3, la página Fabric Builder se verá como se muestra a continuación.

Paso 4: Traslado de fabric DC1 y DC2 a MSD multisitio

# En este paso, los fabrics DC1 y DC2 se mueven a Multisite-MSD que se creó en el Paso 3. A continuación se muestran las capturas de pantalla sobre cómo lograr lo mismo.

# Seleccione el MSD, haga clic en "mover fabric" y, a continuación, seleccione DC1 y DC2 uno por uno y luego "agregar".

# Una vez que se muevan los dos tejidos, la página de inicio será similar a la siguiente

# Multisite-MSD mostrará DC1 y DC2 como fabrics de miembros

Paso 5: Creación de VRF

# La creación de VRF se puede realizar desde el entramado MSD, que será aplicable para ambos Fabric. A continuación se muestran las capturas de pantalla para lograr lo mismo.

# Rellene también la ficha avanzada y, a continuación, "crear"

Paso 6: Creación de redes

# Creación de VLAN y VNID correspondientes, las SVI se pueden realizar desde el fabric MSD, que será aplicable para ambos fabric.

# En la ficha "avanzado", active la casilla de verificación si se requiere que los BGW sean la puerta de enlace para las redes.

# Una vez cumplimentados todos los campos, haga clic en "Crear red".

# Repita los mismos pasos para cualquier otra VLAN/red

Paso 7: Creación de fabric externo para los switches DCI

# Este ejemplo toma en consideración los switches DCI que están en la trayectoria del paquete de DC1 a DC2 (en lo que respecta a la comunicación entre sitios) que se ve comúnmente cuando hay más de 2 fabrics. 

# External Fabric incluirá los dos switches DCI que se encuentran en la parte superior de la topología que se muestra al principio de este documento

# Cree el Fabri con la plantilla "externa" y especifique el ASN

# Modifique cualquier otro campo relevante para la implementación

Paso 8: Incorporación de switches en cada fabric

# Aquí, todos los switches por fabric se agregarán al fabric correspondiente.

El procedimiento para agregar switches se muestra en las capturas de pantalla siguientes.

# Si "Preseve Config" es "NO"; cualquier configuración de switch presente será borrada; La excepción es el nombre de host, la variable de inicio, la dirección IP MGMT0, la ruta en la administración del contexto VRF

# Establezca las funciones en los switches correctamente(al hacer clic con el botón derecho del ratón en el switch, definir la función y, a continuación, la función pertinente

# También organice el diseño de los switches en consecuencia y, a continuación, haga clic en "guardar diseño".

Paso 9: Configuración TRM para Fabric Individuales

• El siguiente paso es habilitar las casillas de verificación TRM en cada fabric

# Realice este paso para todas las redes para todos los fabric.

• Una vez hecho esto, los VRF en fabrics individuales también deben realizar algunos cambios y agregar información como se indica a continuación.

# Esto debe hacerse en DC1 y DC2, así como para la sección VRF.

# Observe que el grupo multicast para el VRF-> 239.1.2.100 se cambió manualmente del grupo que se rellenó automáticamente; La práctica recomendada es utilizar grupos diferentes para el VRF VNI de Capa 3 y para cualquier grupo de multidifusión de tráfico BUM de L2 VNI Vlan

Paso 10: Configuración de VRFLITE en los Gateways de Borde

# A partir de NXOS 9.3(3) y DCNM 11.3(1), los Gateways de borde pueden actuar como puertas de enlace de borde y punto de conectividad VRFLITE(lo que permitirá que la puerta de enlace de frontera tenga una vecindad VRFLITE con un router externo y de modo que los dispositivos externos puedan comunicarse con los dispositivos del fabric)

# Para el propósito de este documento, los gateways de borde están formando vecindad VRFLITE con el router DCI que están en el norte de la topología mostrada arriba. 

# Un punto a tener en cuenta es que: VRFLITE y los links subyacentes multisitio no pueden ser los mismos links físicos. Habrá que abrir enlaces separados para formar la base de vrflite y multisitio

# Las capturas de pantalla siguientes ilustrarán cómo lograr tanto las extensiones VRF LITE como las de varios sitios en los gateways de borde.

N.º Cambiar a "vista tabular"

# Pase a la ficha "links" y, a continuación, agregue un enlace "VRFLITE entre fabric" y tendrá que especificar el entramado de origen como DC1 y el fabric de destino como DCI

# Seleccione la interfaz adecuada para la interfaz de origen que conduce al switch DCI correcto

# en el perfil de link, proporcione las direcciones IP locales y remotas

# También active la casilla de verificación - "indicador de implementación automática" para que la configuración de los switches DCI para VRFLITE también se rellene automáticamente(Esto se hará en un paso posterior)

Nº de ASN rellenados automáticamente

# Una vez rellenados todos los campos con la información correcta, haga clic en el botón "guardar".

• El paso anterior tendrá que hacerse para todas las conexiones BGW a DCI en los 4 Gateways de borde hacia los dos switches DCI.
• Teniendo en cuenta la topología de este documento, habrá un total de 8 conexiones LITE VRF entre fabric y se verá a continuación.

Paso 11: Configuración subyacente multisitio en los gateways de borde

# El siguiente paso es configurar la subcapa multisitio en cada gateway fronterizo en cada fabric.

# Con este fin, necesitaremos links físicos separados de los BGW a los switches DCI. Los links que se utilizaron para VRFLITE en el paso 10 no se pueden utilizar para la superposición multisitio

# Estas interfaces formarán parte de "vrf predeterminado" a diferencia de la anterior, donde las interfaces formarán parte de vrf de arrendatario (este ejemplo es arrendatario-1)

# Las capturas de pantalla siguientes ayudarán a recorrer los pasos necesarios para realizar esta configuración.

# El mismo paso tendrá que realizarse para todas las conexiones de los BGW a los switches DCI

# Al final, se verá un total de 8 conexiones de la capa subyacente entre fabric multisitio como se muestra a continuación.

Paso 12: Configuración de superposición multisitio para TRM

# Cuando se complete la subcapa multisitio, las interfaces/links superpuestos multisitio se rellenarán automáticamente y se podrán ver en la vista tabular bajo enlaces dentro del fabric MSD multisitio.

# De forma predeterminada, la superposición multisitio sólo formará la vecindad bgp l2vpn evpn de BGW de cada sitio al otro que se requiera para la comunicación unicast de un sitio a otro. Sin embargo, cuando se requiere que la multidifusión se ejecute entre los sitios (que están conectados por la función vxlan multisite), es necesario activar la casilla TRM como se muestra a continuación para todas las interfaces superpuestas dentro de Multisite MSD Fabric. Las capturas de pantalla ilustrarán cómo realizar esto.

Paso 13: Guardar/implementar en MSD y fabric individuales

# Realice un proceso de guardado/implementación que impulsará las configuraciones relevantes según los pasos anteriores que se realizaron

# Al seleccionar MSD, las configuraciones que se enviarán solo serán aplicables para las puertas de enlace de borde.

# Por lo tanto, es necesario ahorrar/implementar para los fabrics individuales, lo que llevará las configuraciones relevantes a todos los switches/VTEP de hoja habituales.

Paso 14: Archivos adjuntos de Extensión VRF para MSD

# Seleccione el MSD y vaya a la sección VRF

# Tenga en cuenta que la opción Extend debe ser "MULTISITE+VRF_LITE" como en este documento, la funcionalidad de la puerta de enlace de borde y VRFLITE se integran en los switches de la puerta de enlace de borde.

# AUTO_VRF_LITE se establecerá en true

# PEER VRF NAME tendrá que rellenarse manualmente para los 8 como se muestra a continuación de BGW a los switches DCI(aquí, el ejemplo utiliza el mismo VRF NAME en los switches DCI)

# Una vez hecho, haga clic en "guardar".

# Mientras se crean extensiones VRF, sólo los gateways de borde tendrán configuraciones adicionales hacia los switches VRFLITE DCI

# Por lo tanto, la hoja normal tendrá que seleccionarse por separado y luego hacer clic en las "casillas" para cada VRF de arrendatario como se muestra arriba.

# Haga clic en Implementar para impulsar las configuraciones

Paso 15: Envío de configuraciones de red al fabric desde MSD

# Seleccione las redes relevantes dentro del fabric de MSD 

# Tenga en cuenta que sólo se seleccionan las puertas de enlace de borde en este momento; Realice lo mismo y seleccione los switches de hoja regular/VTEP-> DC1-VTEP y DC2-VTEP en este caso.

# Una vez hecho, haga clic en "implementar" (lo que transferirá las configuraciones a los 6 switches anteriores).

Paso 16: Verificación de VRF y Redes en todos los VRF

# Este paso es para verificar si el VRF y las redes se muestran como "implementadas" en todos los fabric; si se muestra como pendiente, asegúrese de "implementar" las configuraciones.

Paso 17: Implementación de configuraciones en el fabric externo

# Este paso es necesario para enviar todas las configuraciones de IP, BGP y VRFLITE relevantes a los switches DCI.

# Para ello, seleccione External Fabric y haga clic en "Save & Deploy" (Guardar e implementar).

DCI-1# sh ip bgp sum
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 10.10.100.1, local AS number 65001
BGP table version is 173, IPv4 Unicast config peers 4, capable peers 4
22 network entries and 28 paths using 6000 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.10.1       4 65000      11      10      173    0    0 00:04:42 5         
10.4.10.9       4 65000      11      10      173    0    0 00:04:46 5         
10.4.20.37      4 65002      11      10      173    0    0 00:04:48 5         
10.4.20.49      4 65002      11      10      173    0    0 00:04:44 5         
DCI-1# sh ip bgp sum vrf tenant-1
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.2, local AS number 65001
BGP table version is 14, IPv4 Unicast config peers 4, capable peers 4
2 network entries and 8 paths using 1200 bytes of memory
BGP attribute entries [2/336], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.1      4 65000       8      10       14    0    0 00:01:41 2         
10.33.10.9      4 65000      10      11       14    0    0 00:03:16 2         
10.33.20.1      4 65002      11      10       14    0    0 00:04:40 2         
10.33.20.9      4 65002      11      10       14    0    0 00:04:39 2    

DCI-2# sh ip bgp sum
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 10.10.100.2, local AS number 65001
BGP table version is 160, IPv4 Unicast config peers 4, capable peers 4
22 network entries and 28 paths using 6000 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.10.5       4 65000      12      11      160    0    0 00:05:10 5         
10.4.10.13      4 65000      12      11      160    0    0 00:05:11 5         
10.4.20.45      4 65002      12      11      160    0    0 00:05:10 5         
10.4.20.53      4 65002      12      11      160    0    0 00:05:07 5         
DCI-2# sh ip bgp sum vrf tenant-1 
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.6, local AS number 65001
BGP table version is 14, IPv4 Unicast config peers 4, capable peers 4
2 network entries and 8 paths using 1200 bytes of memory
BGP attribute entries [2/336], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.5      4 65000      10      11       14    0    0 00:03:28 2         
10.33.10.13     4 65000      11      11       14    0    0 00:04:30 2         
10.33.20.5      4 65002      12      11       14    0    0 00:05:05 2         
10.33.20.13     4 65002      12      11       14    0    0 00:05:03 2     

# Una vez implementados, veremos 4 vecindarios BGP IPv4 de cada switch DCI a todos los BGW y 4 vecindarios BGP VRF IPv4 también(que es para el arrendatario VRF EXtension)

Paso 18: Configuración de iBGP entre switches DCI

# Teniendo en cuenta que los switches DCI tienen links conectados entre sí, una vecindad IPv4 de iBGP es ideal para que si alguna conexión descendente se interrumpe en el switch DCI-1, el tráfico Norte a Sur todavía se pueda reenviar a través de DCI-2

# Para esto, se requiere un Vecindario IPv4 de iBGP entre los switches DCI y utilizar next-hop-self también en cada lado. 

# Para lograrlo, se debe activar una forma libre en los switches DCI. Las líneas de configuraciones necesarias son las siguientes.

# Los switches DCI de la topología anterior se configuran en vPC; por lo tanto, la SVI de respaldo se puede utilizar para construir los Vecindarios iBGP

# Seleccione el fabric DCI y haga clic con el botón derecho del ratón en cada switch y "ver/editar políticas"

# Realice el mismo cambio en el switch DCI-2 y, a continuación, "guarde e implemente" para enviar las configuraciones reales a los switches DCI

# Una vez hecho, la verificación de CLI se puede realizar mediante el siguiente comando.

DCI-2# sh ip bgp sum
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 10.10.100.2, local AS number 65001
BGP table version is 187, IPv4 Unicast config peers 5, capable peers 5
24 network entries and 46 paths using 8400 bytes of memory
BGP attribute entries [6/1008], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.10.5       4 65000    1206    1204      187    0    0 19:59:17 5         
10.4.10.13      4 65000    1206    1204      187    0    0 19:59:19 5         
10.4.20.45      4 65002    1206    1204      187    0    0 19:59:17 5         
10.4.20.53      4 65002    1206    1204      187    0    0 19:59:14 5         
10.10.8.1       4 65001      12       7      187    0    0 00:00:12 18    # iBGP neighborship from DCI-2 to DCI-1

Paso 19: Verificación de los vecindarios IGP/BGP

Vecinos OSPF

# Como todo el IGP subyacente es OSPF en este ejemplo, todos los VTEP formarán la vecindad OSPF con las columnas y esto incluye los switches BGW en un sitio también.

DC1-SPINE# show ip ospf neighbors 
 OSPF Process ID UNDERLAY VRF default
 Total number of neighbors: 3
 Neighbor ID     Pri State            Up Time  Address         Interface
 10.10.10.3        1 FULL/ -          1d01h    10.10.10.3      Eth1/1     # DC1-Spine to DC1-VTEP
 10.10.10.2        1 FULL/ -          1d01h    10.10.10.2      Eth1/2     # DC1-Spine to DC1-BGW2
 10.10.10.1        1 FULL/ -          1d01h    10.10.10.1      Eth1/3     # DC1-Spine to DC1-BGW1

# Todos los loopbacks(ID de router BGP, loopbacks NVE) se anuncian en OSPF; Por lo tanto, dentro de un entramado, todos los loopbacks se aprenden a través del protocolo de ruteo OSPF que ayudaría a formar más la vecindad del evpn l2vpn

vecindades BGP

# Dentro de un entramado, esta topología tendrá vecinos de vpn l2vpn desde las columnas hasta los VTEPs normales y también a los Gateways de borde.

DC1-SPINE# show  bgp l2vpn evpn sum
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.10.10.4, local AS number 65000
BGP table version is 80, L2VPN EVPN config peers 3, capable peers 3
22 network entries and 22 paths using 5280 bytes of memory
BGP attribute entries [14/2352], BGP AS path entries [1/6]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4 65000    1584    1560       80    0    0    1d01h 10        # DC1-Spine to DC1-BGW1
10.10.10.2      4 65000    1565    1555       80    0    0    1d01h 10        # DC1-Spine to DC1-BGW2
10.10.10.3      4 65000    1550    1554       80    0    0    1d01h 2         # DC1-Spine to DC1-VTEP

# Teniendo en cuenta que se trata de una implementación multisitio con Gateways de borde que se peinan de un sitio a otro mediante el evpn l2vpn eBGP, se puede verificar lo mismo utilizando el siguiente comando en un switch de gateway de borde.

DC1-BGW1# show  bgp l2vpn evpn sum
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.10.10.1, local AS number 65000
BGP table version is 156, L2VPN EVPN config peers 3, capable peers 3
45 network entries and 60 paths using 9480 bytes of memory
BGP attribute entries [47/7896], BGP AS path entries [1/6]
BGP community entries [0/0], BGP clusterlist entries [2/8]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.4      4 65000    1634    1560      156    0    0    1d01h 8       # DC1-BGW1 to DC1-SPINE  
10.10.20.3      4 65002    1258    1218      156    0    0 20:08:03 9       # DC1-BGW1 to DC2-BGW1  
10.10.20.4      4 65002    1258    1217      156    0    0 20:07:29 9       # DC1-BGW1 to DC2-BGW2  

Neighbor        T    AS PfxRcd     Type-2     Type-3     Type-4     Type-5    
10.10.10.4      I 65000 8          2          0          1          5         
10.10.20.3      E 65002 9          4          2          0          3         
10.10.20.4      E 65002 9          4          2          0          3     

Vecindades BGP MVPN para TRM

# Con las configuraciones TRM implementadas, todos los switches de hoja (incluidos los BGW) formarán una vecindad de mvpn con las columnas

DC1-SPINE# show bgp ipv4 mvpn summary
BGP summary information for VRF default, address family IPv4 MVPN
BGP router identifier 10.10.10.4, local AS number 65000
BGP table version is 20, IPv4 MVPN config peers 3, capable peers 3
0 network entries and 0 paths using 0 bytes of memory
BGP attribute entries [0/0], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4 65000    2596    2572       20    0    0    1d18h 0         
10.10.10.2      4 65000    2577    2567       20    0    0    1d18h 0         
10.10.10.3      4 65000    2562    2566       20    0    0    1d18h 0    

# Además, se requiere que los Gateways de frontera formen la vecindad mvpn entre sí para que el tráfico multicast este/oeste atraviese correctamente.

DC1-BGW1# show bgp ipv4 mvpn summary
BGP summary information for VRF default, address family IPv4 MVPN
BGP router identifier 10.10.10.1, local AS number 65000
BGP table version is 6, IPv4 MVPN config peers 3, capable peers 3
0 network entries and 0 paths using 0 bytes of memory
BGP attribute entries [0/0], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [2/8]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.4      4 65000    2645    2571        6    0    0    1d18h 0         
10.10.20.3      4 65002    2273    2233        6    0    0    1d12h 0         
10.10.20.4      4 65002    2273    2232        6    0    0    1d12h 0  

Paso 20: Creación de loopback VRF de arrendatarios en switches de gateway fronterizo

# Cree loopbacks en el VRF de arrendatario con direcciones IP únicas en Todos los Gateways de Borde.

# Para este propósito, seleccione DC1, haga clic con el botón derecho en DC1-BGW1, Administrar interfaces y, a continuación, cree loopback como se muestra a continuación.

# El mismo paso tendrá que hacerse en otros 3 Gateways de borde.

Paso 21: Configuraciones VRFLITE en switches DCI

# En esta topología, los switches DCI se configuran con VRFLITE hacia los BGW. VRFLITE también se configura hacia el norte de los switches DCI (es decir, hacia los switches de núcleo)

# Para propósitos TRM, el RP PIM dentro del arrendatario VRF-1 se encuentra en el Switch de Núcleo que se conecta a través de VRFLITE a los switches DCI

# Esta topología tiene una vecindad BGP IPv4 de los switches DCI al switch principal dentro del arrendatario VRF 1 que se encuentra en la parte superior del diagrama.

# Para este propósito, las subinterfaces se crean y asignan con direcciones IP y también se establecen vecindarios BGP (estos se realizan mediante CLI directamente en los switches DCI y de núcleo)

DCI-1# sh ip bgp sum vrf tenant-1 
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.2, local AS number 65001
BGP table version is 17, IPv4 Unicast config peers 5, capable peers 5
4 network entries and 10 paths using 1680 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [3/18]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.1      4 65000    6366    6368       17    0    0    4d10h 2         
10.33.10.9      4 65000    6368    6369       17    0    0    4d10h 2         
10.33.20.1      4 65002    6369    6368       17    0    0    4d10h 2         
10.33.20.9      4 65002    6369    6368       17    0    0    4d10h 2         
172.16.111.2    4 65100      68      67       17    0    0 00:49:49 2  # This is towards the Core switch from DCI-1

# Arriba en rojo es el vecino BGP hacia el switch de núcleo desde DCI-1.

DCI-2# sh ip bgp sum vr tenant-1 
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.6, local AS number 65001
BGP table version is 17, IPv4 Unicast config peers 5, capable peers 5
4 network entries and 10 paths using 1680 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [3/18]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.5      4 65000    6368    6369       17    0    0    4d10h 2         
10.33.10.13     4 65000    6369    6369       17    0    0    4d10h 2         
10.33.20.5      4 65002    6370    6369       17    0    0    4d10h 2         
10.33.20.13     4 65002    6370    6369       17    0    0    4d10h 2         
172.16.222.2    4 65100      53      52       17    0    0 00:46:12 2  # This is towards the Core switch from DCI-2

# También se requieren las configuraciones de BGP correspondientes en el switch principal (de vuelta a DCI-1 y DCI-2)

Verificaciones de unidifusión

Este/Oeste de DC1-Host1 a DC2-Host1

# Con todas las configuraciones anteriores impulsadas desde DCNM y CLI manual (pasos 1 a 21), el alcance de unidifusión debería funcionar en este/oeste

DC1-Host1# ping 172.16.144.2 source 172.16.144.1
PING 172.16.144.2 (172.16.144.2) from 172.16.144.1: 56 data bytes
64 bytes from 172.16.144.2: icmp_seq=0 ttl=254 time=0.858 ms
64 bytes from 172.16.144.2: icmp_seq=1 ttl=254 time=0.456 ms
64 bytes from 172.16.144.2: icmp_seq=2 ttl=254 time=0.431 ms
64 bytes from 172.16.144.2: icmp_seq=3 ttl=254 time=0.454 ms
64 bytes from 172.16.144.2: icmp_seq=4 ttl=254 time=0.446 ms

--- 172.16.144.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.431/0.529/0.858 ms

Norte/Sur de DC1-Host1 a PIM RP(10.200.200.100)

DC1-Host1# ping 10.200.200.100 source 172.16.144.1
PING 10.200.200.100 (10.200.200.100) from 172.16.144.1: 56 data bytes
64 bytes from 10.200.200.100: icmp_seq=0 ttl=250 time=0.879 ms
64 bytes from 10.200.200.100: icmp_seq=1 ttl=250 time=0.481 ms
64 bytes from 10.200.200.100: icmp_seq=2 ttl=250 time=0.483 ms
64 bytes from 10.200.200.100: icmp_seq=3 ttl=250 time=0.464 ms
64 bytes from 10.200.200.100: icmp_seq=4 ttl=250 time=0.485 ms

--- 10.200.200.100 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.464/0.558/0.879 ms

Verificaciones de multidifusión

Para este documento, el RP PIM para el VRF "tenant-1" se configura y presenta externo al Fabric VXLAN; Según la topología, el PIM RP se configura en el switch principal con la dirección IP-> 10.200.200.100

Fuente en Non-vxlan (detrás del switch principal), Receptor en DC2

Consulte Topología que se muestra al principio.

# Tráfico de multidifusión norte/sur originado en host no VXLAN-> 172.17.100.100, el receptor está presente en ambos Data Centers; DC1-Host1-> 172.16.144.1 y DC2-Host1-> 172.16.144.2, Grupo -> 239.100.100.100

Legacy-SW#ping 239.100.100.100 source 172.17.100.100 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.100.100.100, timeout is 2 seconds:
Packet sent with a source address of 172.17.100.100

Reply to request 0 from 172.16.144.1, 3 ms
Reply to request 0 from 172.16.144.1, 3 ms
Reply to request 0 from 172.16.144.2, 3 ms
Reply to request 0 from 172.16.144.2, 3 ms

Fuente en DC1, receptor en DC2 así como externo

DC1-Host1# ping multicast 239.144.144.144 interface vlan 144 vrf vlan144 cou 1
PING 239.144.144.144 (239.144.144.144): 56 data bytes
64 bytes from 172.16.144.2: icmp_seq=0 ttl=254 time=0.781 ms       # Receiver in DC2
64 bytes from 172.17.100.100: icmp_seq=0 ttl=249 time=2.355 ms     # External Receiver

--- 239.144.144.144 ping multicast statistics ---
1 packets transmitted,
From member 172.17.100.100: 1 packet received, 0.00% packet loss
From member 172.16.144.2: 1 packet received, 0.00% packet loss
--- in total, 2 group members responded ---

Fuente en DC2, receptor en DC1 así como externo

DC2-Host1# ping multicast 239.145.145.145 interface vlan 144 vrf vlan144  cou 1
PING 239.145.145.145 (239.145.145.145): 56 data bytes
64 bytes from 172.16.144.1: icmp_seq=0 ttl=254 time=0.821 ms       # Receiver in DC1
64 bytes from 172.17.100.100: icmp_seq=0 ttl=248 time=2.043 ms     # External Receiver

--- 239.145.145.145 ping multicast statistics ---
1 packets transmitted,
From member 172.17.100.100: 1 packet received, 0.00% packet loss
From member 172.16.144.1: 1 packet received, 0.00% packet loss
--- in total, 2 group members responded ---