Création d'une carte TRM multisite VXLAN Nexus 9000 à l'aide de DCNM

Introduction

Ce document explique comment déployer un fabric TRM multisite Cisco Nexus 9000 VXLAN où les passerelles de périphérie sont connectées via des commutateurs DCI

Topologie

Détails de la topologie

• DC1 et DC2 sont deux emplacements de data center qui exécutent VXLAN.
• Les passerelles de périphérie DC1 et DC2 sont connectées entre elles via des commutateurs DCI.
• Les commutateurs DCI n'exécutent aucun VXLAN ; Ils exécutent eBGP pour la sous-couche pour l'accessibilité de DC1 à DC2 et Vice Versa. Les commutateurs DCI sont également configurés avec le vrf du locataire ; Dans cet exemple, il s'agit de vrf- « locataire-1 ».
• Les commutateurs DCI se connectent également aux réseaux externes qui ne sont pas des réseaux VXLAN.
• Les connexions VRFLITE sont interrompues sur les passerelles de frontière(la prise en charge de la coexistence des fonctions VRFLITE et de passerelle de frontière a démarré à partir de NXOS-9.3(3) et DCNM-11.3(1))
• Les passerelles en limite s'exécutent en mode Anycast ; Lors de l'exécution de TRM(Client Routed Multicast) sur cette version, les passerelles en limite ne peuvent pas être configurées en tant que vPC(reportez-vous au guide de configuration de TRM multisite pour d'autres limitations)
• Pour cette topologie, tous les commutateurs BGW auront deux connexions physiques vers chacun des commutateurs DCI ; Une liaison sera dans le VRF par défaut (qui sera utilisé pour le trafic inter-site) et une autre liaison sera dans le locataire VRF-1 qui est utilisé pour étendre le VRFLITE à l'environnement non-vxlan.

Détails PIM/Multicast (TRM spécifique)

• Le RP PIM sous-jacent pour les deux sites sont les commutateurs Spine et Loopback254 est configuré pour le même. Le RP PIM sous-jacent est utilisé pour que les VTEP puissent envoyer des registres PIM et des jointures PIM aux Spines (aux fins de la réplication du trafic BUM pour divers VNID)
• Pour TRM, RP peut être spécifié par différents moyens ; Ici, pour les besoins du document, PIM RP est le routeur principal en haut de la topologie qui est externe au fabric VXLAN. 
• Tous les VTEP auront le routeur principal désigné comme RP PIM configuré dans les VRF respectifs
• DC1-Host1 envoie la multidiffusion au groupe 239.144.144.144 ; DC2-Host1 est récepteur pour ce groupe dans DC2 et un hôte externe (172.17.100.100) au VLAN est également abonné à ce groupe
• DC2-Host1 envoie la multidiffusion au groupe 239.145.145.145 ; DC1-Host1 est récepteur pour ce groupe dans DC1 et un hôte externe (172.17.100.100) au VLAN est également abonné à ce groupe
• DC2-Host2 se trouve dans le VLAN 144 et est récepteur pour les groupes de multidiffusion : 239.144.144.144 et 239.100.100.100.100
• L’hôte externe (172.17.100.100) envoie le trafic pour lequel DC1-Host1 et DC2-Host1 sont des récepteurs.
• Cela couvre les flux de trafic de multidiffusion Est/Ouest Inter et Intra Vlan et Nord/Sud.

Components Used

• Commutateurs Nexus 9k exécutant la version 9.3(3)
• DCNM exécutant 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.

Étapes de haut niveau

1) Étant donné que ce document est basé sur deux DC utilisant la fonctionnalité VXLAN Multisite, deux Fabrics Easy doivent être créés

2) Créer MSD et déplacer DC1 et DC2

3) Créer un fabric externe et ajouter des commutateurs DCI

4) Créer une sous-couche et une superposition multisite

5) Créer des pièces jointes d'extension VRF sur les passerelles en limite

6) Vérification du trafic de monodiffusion

7) Vérification du trafic multidiffusion

Étape 1 : Création d'un fabric facile pour DC1

• Connectez-vous à DCNM et dans le tableau de bord, sélectionnez l'option-> Fabric Builder

• Sélectionnez l'option Créer un fabric.

• Ensuite, vous devez fournir le nom de la structure, le modèle, puis sous l'onglet Général, remplir le numéro de série ASN approprié, la numérotation de l'interface du fabric, Any Cast Gateway MAC(AGM)

# AGM est utilisé par les hôtes du fabric comme adresse MAC de la passerelle par défaut. Ce sera le même sur tous les commutateurs Leaf (tous les commutateurs Leaf du fabric exécutent le transfert de fabric en cascade). L'adresse IP et l'adresse MAC de la passerelle par défaut seront identiques sur tous les commutateurs Leaf

• La prochaine étape consiste à définir le mode de réplication

# Le mode de réplication de ce document est Multicast ; Une autre option consiste à utiliser la réplication d'entrée (IR)

# Le sous-réseau du groupe de multidiffusion sera le groupe de multidiffusion utilisé par les VTEP pour répliquer le trafic BUM (comme les requêtes ARP)

# La case à cocher Activer la multidiffusion routée par le client (TRM) doit être activée.

# Remplissez d'autres cases si nécessaire.

• L'onglet vPC reste intact car la topologie n'utilise aucun vPC
• L'onglet Protocoles s'affiche ensuite.

# Modifiez les cases appropriées si nécessaire.

• Onglet Suivant

# Pour ce document, tous les champs sont laissés par défaut.

# ASN est renseigné automatiquement à partir de celui fourni dans l'onglet Général

• Ensuite, remplissez les champs de l'onglet « Ressources ».

# La plage IP de bouclage de routage sous-jacent serait celle utilisée pour les protocoles tels que BGP, OSPF

# La plage IP de bouclage VTEP sous-jacente est celle qui sera utilisée pour l'interface NVE.

# Le RP de sous-couche est destiné au RP PIM utilisé pour les groupes de multidiffusion BUM.

• Complétez les autres onglets avec les informations pertinentes, puis « enregistrer »

Étape 2 : Création d'un fabric facile pour DC2

• Effectuez la même tâche que l'étape 1 pour créer un fabric facile pour DC2
• Assurez-vous de fournir un bloc d'adresses IP différent sous Ressources pour les boucles de routage et NVE et toute autre zone pertinente
• Les ASN doivent également être différents
• Les VNID de couche 2 et de couche 2 sont identiques

Étape 3 : Création de MSD pour multisite

• Un fabric MSD doit être créé comme indiqué ci-dessous.

• Complétez également l'onglet DCI 

# La méthode de déploiement IFC de superposition multisite est « Direct_To_BGWS » car ici les DC1-BGW formeront la connexion de superposition avec les DC2-BGW. Les commutateurs DCI illustrés dans la topologie ne sont que des périphériques de la couche de transit 3 (ainsi que VRFLITE)

• L'étape suivante consiste à mentionner la plage de bouclage multisite (cette adresse IP sera utilisée comme adresse IP de bouclage multisite sur les BGW DC1 et DC2 ; DC1-BGW1 et DC1-BGW2 partagent la même adresse IP de bouclage multisite ; DC2-BGW1 et DC2-BGW2 partagent la même adresse IP de bouclage multisite, mais seront différents de ceux des DC1-BGW

# Une fois les champs renseignés, cliquez sur « Enregistrer ».

# Une fois les étapes 1 à 3 effectuées, la page Fabric Builder se présente comme suit.

Étape 4 : Déplacement des fabrics DC1 et DC2 vers MSD multisite

# Dans cette étape, les fabrics DC1 et DC2 sont déplacés vers Multisite-MSD qui a été créé à l'étape 3. Ci-dessous, des captures d'écran sur la façon d'obtenir la même chose.

# Sélectionnez le MSD, cliquez sur « déplacer les fabrics », puis sélectionnez DC1 et DC2 un par un, puis « ajouter ».

# Une fois les deux tissus déplacés, la page d'accueil se présente comme suit :

# Multisite-MSD affichera DC1 et DC2 en tant que fabrics membres

Étape 5 : Création de VRF

# La création de VRF peut être effectuée à partir du fabric MSD qui sera applicable aux deux fabrics. Ci-dessous, les captures d'écran pour obtenir le même résultat.

# Complétez également l'onglet avancé, puis « créer »

Étape 6 : Création de réseaux

# La création de VLAN et de VNID correspondants, les interfaces SVI peuvent être effectuées à partir du fabric MSD qui sera applicable aux deux fabrics.

# Dans l'onglet « avancé », activez la case à cocher si les BGW doivent être la passerelle des réseaux.

# Une fois tous les champs renseignés, cliquez sur Créer un réseau.

# Répétez les mêmes étapes pour tous les autres VLAN/réseaux

Étape 7 : Création d'un fabric externe pour les commutateurs DCI

# Cet exemple prend en compte les commutateurs DCI qui se trouvent dans le chemin du paquet de DC1 à DC2 (en ce qui concerne la communication entre sites), ce qui est généralement observé lorsqu'il y a plus de 2 fabrics. 

# Le fabric externe inclut les deux commutateurs DCI qui se trouvent en haut de la topologie indiquée au début de ce document

# Créez le Fabri avec le modèle « externe » et spécifiez l'ASN

# Modifier tous les autres champs pertinents pour le déploiement

Étape 8 : Ajout de commutateurs à chaque fabric

# Ici, tous les commutateurs par fabric seront ajoutés au fabric correspondant.

La procédure d'ajout de commutateurs est présentée dans les captures d'écran ci-dessous.

# Si « Config. prédéfinie » est « NON »; toute configuration de commutateur présente sera effacée ; Exception : nom d'hôte, variable de démarrage, adresse IP MGMT0, route dans la gestion du contexte VRF

# Définir correctement les rôles sur les commutateurs (par un clic droit sur le commutateur, Définir le rôle, puis le rôle approprié)

# Organisez également la disposition des commutateurs en conséquence, puis cliquez sur Enregistrer la disposition.

Étape 9 : Paramètres TRM pour les structures individuelles

• L'étape suivante consiste à activer les cases à cocher TRM sur chaque fabric

# Effectuez cette étape pour tous les réseaux de toutes les structures.

• Une fois que cela est fait, les VRF des tissus individuels sont également nécessaires pour apporter des modifications et ajouter des informations comme ci-dessous.

# Ceci doit être fait dans DC1 et DC2 également pour la section VRF.

# Notez que le groupe de multidiffusion pour le VRF-> 239.1.2.100 a été modifié manuellement à partir du groupe rempli automatiquement ; La meilleure pratique consiste à utiliser un groupe différent pour la VRF VNI de couche 3 et pour tout groupe de multidiffusion de trafic BUM VNI de couche 2

Étape 10 : Configuration VRFLITE sur les passerelles de périphérie

# À partir de NXOS 9.3(3) et DCNM 11.3(1), les passerelles frontalières peuvent servir de passerelles frontalières et de point de connectivité VRFLITE (ce qui permettra à la passerelle frontalière de disposer d'un voisinage VRFLITE avec un routeur externe et de permettre aux périphériques externes de communiquer avec les périphériques du fabric)

# Aux fins de ce document, les passerelles frontalières forment un voisinage VRFLITE avec le routeur DCI qui se trouve au nord de la topologie indiquée ci-dessus. 

# Un point à noter est que : Les liaisons de sous-couche VRFLITE et multisite ne peuvent pas être les mêmes liaisons physiques. Des liaisons séparées devront être créées pour former le vrolet et la sous-couche multisite

# Les captures d'écran ci-dessous illustrent comment réaliser les extensions LITE VRF et multisite sur les passerelles en limite.

# Basculer vers la vue tabulaire

# Passez à l'onglet « Liens », puis ajoutez un lien « VRFLITE inter-fabric » et vous devrez spécifier le fabric source comme DC1 et le fabric de destination comme DCI

# Sélectionnez l'interface appropriée pour l'interface source qui mène au commutateur DCI correct

# sous le profil de liaison, indiquez les adresses IP locales et distantes.

# Activez également la case à cocher : « indicateur de déploiement automatique » pour que la configuration des commutateurs DCI pour VRFLITE soit également renseignée automatiquement (ceci sera fait dans une prochaine étape)

Nombre d'ASN renseignés automatiquement

# Une fois que tous les champs sont remplis avec les informations correctes, cliquez sur le bouton « Enregistrer »

• L'étape ci-dessus devra être effectuée pour toutes les connexions BGW-DCI sur les 4 passerelles frontalières vers les deux commutateurs DCI.
• Compte tenu de la topologie de ce document, il y aura un total de 8 connexions LITE VRF inter-fabric et il ressemble à ceci ci-dessous.

Étape 11 : Configuration de la sous-couche multisite sur les passerelles de périphérie

# L'étape suivante consiste à configurer la sous-couche multisite sur chaque passerelle en limite de chaque fabric.

# À cette fin, nous aurons besoin de liaisons physiques distinctes entre les BGW et les commutateurs DCI. Les liaisons utilisées pour VRFLITE à l'étape 10 ne peuvent pas être utilisées pour la superposition multisite

# Ces interfaces feront partie de « default vrf », contrairement à la précédente où les interfaces feront partie de locataire vrf (dans cet exemple, il s'agit de locataire-1)

# Les captures d'écran ci-dessous vous aideront à parcourir les étapes de cette configuration.

# La même étape doit être effectuée pour toutes les connexions des BGW aux commutateurs DCI

# À la fin, un total de 8 connexions de sous-couche multisite inter-fabric seront vues comme ci-dessous.

Étape 12: Paramètres de superposition multisite pour TRM

# Lorsque la sous-couche multisite est terminée, les interfaces/liaisons de superposition multisite sont remplies automatiquement et peuvent être vues dans la vue Tabulaire sous les liaisons au sein du fabric MSD multisite.

# Par défaut, la superposition multisite formera uniquement le voisinage bgp l2vpn evpn de chaque BGW de site à l'autre qui est requis pour la communication monodiffusion d'un site à un autre. Cependant, lorsque la multidiffusion est requise pour s'exécuter entre les sites (qui sont connectés par la fonctionnalité multisite vxlan), il est nécessaire d'activer la case à cocher TRM comme indiqué ci-dessous pour toutes les interfaces de superposition dans le fabric MSD multisite. Des captures d'écran illustreront comment effectuer cette opération.

Étape 13 : Enregistrer/déployer dans MSD et dans les structures individuelles

# Effectuer un enregistrement/déploiement qui poussera les configurations pertinentes conformément aux étapes ci-dessus qui ont été effectuées

# Lors de la sélection de MSD, les configurations qui seront poussées ne s'appliqueront qu'aux passerelles en limite.

# Par conséquent, il est nécessaire d'enregistrer/de déployer pour chaque fabric, ce qui poussera les configurations appropriées à tous les commutateurs Leaf/VTEP standard

Étape 14 : Pièces jointes d'extension VRF pour MSD

# Sélectionnez le MSD et accédez à la section VRF.

# Notez que l'option Extend doit être « MULTISITE+VRF_LITE » comme dans ce document, la fonctionnalité Border Gateway et VRFLITE sont intégrées aux commutateurs Border Gateway.

# AUTO_VRF_LITE sera défini sur true

# Le NOM VRF PEER doit être renseigné manuellement pour les 8, comme indiqué ci-dessous, des BGW aux commutateurs DCI (ici, l'exemple utilise le même NOM VRF sur les commutateurs DCI)

# Une fois terminé, cliquez sur Enregistrer.

# Lors de la création d'extensions VRF, seules les passerelles de frontière disposent de configurations supplémentaires pour les commutateurs VRFLITE DCI

# Par conséquent, la feuille normale devra être sélectionnée séparément, puis cliquez sur les cases à cocher pour chaque VRF du locataire comme indiqué ci-dessus.

# Cliquez sur Déployer pour afficher les configurations

Étape 15 : Transfert des configurations réseau vers le fabric à partir de MSD

# Sélectionnez les réseaux appropriés dans le fabric MSD 

# Notez que seules les passerelles de frontière sont sélectionnées pour le moment ; Effectuez la même opération et sélectionnez les commutateurs/VTEPs -> DC1-VTEP et DC2-VTEP dans ce cas.

# Une fois terminé, cliquez sur le bouton « déployer » (qui permet de transmettre les configurations aux 6 commutateurs ci-dessus).

Étape 16 : Vérification des VRF et des réseaux sur tous les VRF

# Cette étape consiste à vérifier si le VRF et les réseaux sont affichés comme étant « Déployés » sur tous les fabrics ; si son affichage est en attente, assurez-vous de « déployer » les configurations.

Étape 17 : Déploiement de configurations sur un fabric externe

# Cette étape est nécessaire pour transmettre toutes les configurations d'adressage IP, BGP et VRFLITE pertinentes aux commutateurs DCI.

# Pour ce faire, sélectionnez le fabric externe et cliquez sur Enregistrer et déployer.

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     

# Une fois déployé, nous verrons 4 voisins BGP IPv4 de chaque commutateur DCI vers tous les BGW et 4 voisins BGP VRF IPv4 également (ce qui est pour le client VRF EXtension)

Étape 18 : Configuration d'iBGP entre les commutateurs DCI

# Étant donné que les commutateurs DCI ont des liaisons entre eux, un voisinage IPv4 iBGP est idéal pour que, si des connexions en aval s'arrêtent sur le commutateur DCI-1, le trafic Nord-Sud puisse toujours être transféré via DCI-2

# Pour cela, un voisinage IPv4 iBGP est requis entre les commutateurs DCI et utilisez le saut suivant de chaque côté. 

# Une forme libre devra être exécutée sur les commutateurs DCI pour atteindre cet objectif. Les lignes de configuration requises sont les suivantes :

# Les commutateurs DCI de la topologie ci-dessus sont configurés dans vPC ; Ainsi, l'interface SVI de sauvegarde peut être utilisée pour construire les voisins iBGP

# Sélectionnez le fabric DCI et cliquez avec le bouton droit sur chaque commutateur et « afficher/modifier les stratégies ».

# Effectuez la même modification sur le commutateur DCI-2, puis enregistrez et déployez pour transmettre les configurations réelles aux commutateurs DCI

# Une fois terminé, la vérification de l'interface de ligne de commande peut être effectuée à l'aide de la commande ci-dessous.

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

Étape 19 : Vérification des voisins IGP/BGP

Quartiers OSPF

# Comme tous les protocoles IGP sous-jacents sont OSPF dans cet exemple, tous les protocoles VTEP formeront un voisinage OSPF avec les épines, y compris les commutateurs BGW dans un site également.

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

# Toutes les boucles (ID de routeur BGP, boucles NVE) sont annoncées dans OSPF ; Par conséquent, au sein d'un fabric, tous les bouclages sont appris via le protocole de routage OSPF, ce qui contribuerait à former le voisinage de l2vpn evpn

Quartiers BGP

# Au sein d'un fabric, cette topologie aura des voisins de l2vpn evpn depuis Spines jusqu'aux VTEP réguliers et aux passerelles frontalières.

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

# Étant donné qu'il s'agit d'un déploiement multisite avec des passerelles en limite qui s'appairent d'un site à l'autre à l'aide d'evpn eBGP l2vpn, la même chose peut être vérifiée à l'aide de la commande ci-dessous sur un commutateur de passerelle en limite.

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     

Voisins MVPN BGP pour TRM

# Avec les configurations TRM en place, tous les commutateurs Leaf (y compris les BGW) formeront le voisinage mvpn avec les épines

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    

# En outre, les passerelles de périphérie sont nécessaires pour former le voisinage mvpn entre elles afin que le trafic de multidiffusion est/ouest traverse correctement.

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  

Étape 20 : Création de bouclage VRF sur les commutateurs de passerelle frontière

# Créer des bouclages dans le VRF du client avec des adresses IP uniques sur toutes les passerelles en limite.

# À cette fin, sélectionnez DC1, cliquez avec le bouton droit sur DC1-BGW1, gérez les interfaces, puis créez le bouclage comme indiqué ci-dessous.

# La même étape doit être effectuée sur les 3 autres passerelles de frontière.

Étape 21 : Configurations VRFLITE sur les commutateurs DCI

# Dans cette topologie, les commutateurs DCI sont configurés avec VRFLITE vers les BGW. VRFLITE est également configuré vers le nord des commutateurs DCI (c'est-à-dire vers les commutateurs principaux)

# Pour les besoins de TRM, le RP PIM du locataire VRF-1 est situé dans le commutateur principal connecté via VRFLITE aux commutateurs DCI

# Cette topologie a le voisinage BGP IPv4 des commutateurs DCI au commutateur principal dans le locataire VRF-1 qui se trouve en haut du schéma.

# À cette fin, des sous-interfaces sont créées et attribuées avec des adresses IP et des voisins BGP sont également établis (ces opérations sont effectuées par l'interface de ligne de commande directement sur les commutateurs DCI et principaux)

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

# Au-dessus, en rouge, se trouve le voisin BGP vers le commutateur Core de 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

# Les configurations BGP respectives sont également requises sur le commutateur Core (retour à DCI-1 et DCI-2)

Vérifications de monodiffusion

Est/Ouest de DC1-Hôte1 à DC2-Hôte1

# Avec toutes les configurations ci-dessus envoyées de DCNM et de l'interface de ligne de commande manuelle (étapes 1 à 21), l'accessibilité à la monodiffusion doit fonctionner dans East/West

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

Nord/Sud de DC1-Hôte1 à 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

Vérifications de multidiffusion

À cette fin, le RP PIM pour le VRF « locataire-1 » est configuré et présent en dehors du fabric VXLAN ; Selon la topologie, le RP PIM est configuré sur le commutateur principal avec l'adresse IP-> 10.200.200.100

Source dans non-vxlan (derrière le commutateur principal), récepteur dans DC2

Référez-vous à la topologie qui apparaît au début.

# Trafic de multidiffusion Nord/Sud provenant d'un hôte non VXLAN-> 172.17.100.100, le récepteur est présent dans les deux data centers ; DC1-Hôte1-> 172.16.144.1 et DC2-Hôte1-> 172.16.144.2, Groupe -> 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

Source dans DC1, récepteur dans DC2 et externe

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 ---

Source dans DC2, récepteur dans DC1 et externe

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 ---