Contenu

Introduction

Topologie

Détails de la topologie

Composants utilisés:

Étapes de haut niveau

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

Étape 2 : Ajouter des commutateurs au fabric DC1

Étape 3 : Configuration des réseaux/VRF

Étape 4 : Répétez les mêmes étapes pour DC2

Étape 5 : Création d'un fabric facile pour les frontières partagées

Étape 6 - Création de MSD et déplacement de structures DC1 et DC2

Étape 7 : Création d'un fabric externe

Étape 8 : Sous-couche eBGP pour l'accessibilité en mode bouclé entre les BGW(iBGP entre les frontières partagées également)

Étape 9 : Création d'une superposition multisite des BGW aux frontières partagées

Étape 10 : Déploiement de réseaux/VRF sur les deux sites

Étape 11 : Création de ports de liaison/d'accès en aval sur les commutateurs leaf/VTEP

Étape 12: Formes libres requises sur la frontière partagée

Étape 13 : Bouclage dans les VRF de locataire sur les BGW

Étape 14 : Extensions VRFLITE des frontières partagées vers les routeurs externes

a) Ajout de liaisons inter-fabric à partir de frontières partagées vers des routeurs externes

b) Ajout de postes VRF

Introduction

Ce document explique comment déployer un déploiement multisite Cisco Nexus 9000 VXLAN à l'aide d'un modèle de bordure partagée à l'aide de la version DCNM 11.2.

Topologie

Détails de la topologie

DC1 et DC2 sont deux emplacements de centre de données qui exécutent vxlan ;

Les passerelles de frontière DC1 et DC2 ont des connexions physiques aux frontières partagées ;

Les frontières partagées ont une connectivité externe (p. ex. Internet); de sorte que les connexions de la liste VRF sont terminées sur des frontières partagées et qu'une route par défaut est injectée par les frontières partagées aux passerelles de périphérie dans chaque site

Les bordures partagées sont configurées dans vPC(ceci est obligatoire lorsque le fabric est déployé à l'aide de DCNM)

Les passerelles en limite sont configurées en mode Anycast

Composants utilisés:

Nexus 9ks exécutant la version 9.3(2)

DCNM exécutant la version 11.2

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 data centers utilisant la fonctionnalité multisite vxlan, deux Easy Fabrics doivent être créés

2) Créer un autre fabric facile pour la frontière partagée

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

4) Créer un fabric externe

5) Créer une sous-couche et une superposition multisite (Est/Ouest)

6) Créer des pièces jointes d'extension VRF sur des frontières partagées

É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 plusieurs onglets s'ouvriront, ce qui nécessitera des détails tels que ASN, Fabric Interface Numbered, Any Cast Gateway MAC(AGM)

# Les interfaces de fabric (qui sont des interfaces Spine/Leaf) peuvent être « non numérotées » ou point à point ; Si vous utilisez des adresses non numérotées, les adresses IP requises sont inférieures (car l'adresse IP est celle du bouclage non numéroté)

# 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 qui sont les passerelles par défaut

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

# Le mode de réplication sélectionné ici peut être multidiffusion ou réplication d'entrée infrarouge ; IR répliquera tout trafic BUM entrant dans un vlan vxlan de manière monodiffusion vers d'autres VTEP, également appelé réplication de tête de réseau, tandis que le mode multidiffusion enverra le trafic BUM avec une adresse IP de destination externe comme celui du groupe multidiffusion défini pour chaque réseau jusqu'à Spine et Spines effectuera la réplication multidiffusion basée sur l'OIL de l'adresse IP de destination externe vers d'autres VTEP

# Sous-réseau du groupe multidiffusion -> Obligatoire pour répliquer le trafic BUM (comme la requête ARP d'un hôte)

# Si TRM doit être activé, cochez la case correspondante et indiquez l'adresse MDT pour les VRF TRM.

- L'onglet « vPC » est laissé par défaut ; Si des modifications sont nécessaires pour l'interface SVI/VLAN de sauvegarde, elles peuvent être définies ici

- L'onglet Avancé est la section suivante

# L'ID de site mentionné ici est renseigné automatiquement sur cette version DCNM dérivée de l'ASN défini sous l'onglet « Général »

# Remplissez/modifiez les autres champs pertinents

- L'onglet Resources (Ressources) est le suivant qui nécessite le schéma d'adressage IP pour les boucles, les sous-couches

# Plage VNI VXLAN de couche 2-> Il s'agit des VNID qui seront ultérieurement mappés sur des Vlan (l'affichera plus bas)

# Plage VNI VXLAN de couche 3-> Il s'agit des VNID de couche 3 qui seront également ultérieurement mappés au VLAN VNI de couche 3 vers le segment Vn

- Les autres onglets ne sont pas affichés ici ; mais remplissez les autres onglets si nécessaire ;

- Une fois l'enregistrement effectué, la page Fabric Builder affiche Fabric(From DCNM-> Control-> Fabric Builder

# Cette section affiche la liste complète des modes de réplication, ASN et Fabrics pour chacun des Fabrics.

- L'étape suivante consiste à ajouter des commutateurs au fabric DC1

Étape 2 : Ajouter des commutateurs au fabric DC1

Cliquez sur DC1 dans le schéma ci-dessus et vous pouvez ajouter des commutateurs.

- Fournir les adresses IP et les informations d'identification des commutateurs qui doivent être importés dans la structure DC1 (par topologie indiquée au début de ce document, DC1-VTEP, DC1-SPINE, DC1-BGW1 et DC1-BGW2 font partie de DC1)

# Comme il s'agit d'un déploiement Greenfield, notez que l'option « conserver la configuration » est sélectionnée comme « NON »; qui supprimera toutes les configurations des boîtes lors de l'importation et rechargera les commutateurs

# Sélectionnez « Start discovery » pour que DCNM commence à découvrir les commutateurs en fonction des adresses IP fournies dans la colonne « Initial IP ».

- Une fois que la DCNM a fini de découvrir les commutateurs, les adresses IP et les noms d'hôte sont répertoriés dans la gestion de l'inventaire

# Sélectionnez les commutateurs appropriés, puis cliquez sur « Importer dans le fabric »

# Une fois l'importation effectuée, la topologie sous Fabric Builder peut ressembler à la suivante :

# Les commutateurs peuvent être déplacés en cliquant sur un commutateur et en l'alignant à l'emplacement approprié dans le schéma

# Sélectionnez la section Enregistrer la disposition après avoir réorganisé les commutateurs dans l'ordre dans lequel la disposition est nécessaire.

- Définition des rôles pour tous les commutateurs

# Cliquez avec le bouton droit sur chacun des commutateurs et définissez le rôle approprié ; Ici, DC1-BGW1 et DC1-BGW2 sont les passerelles de périphérie

# DC1-SPINE-> Sera défini sur role- Spine, DC1-VTEP-> Sera défini sur role Leaf

- Étape suivante : enregistrer et déployer

# DCNM répertorie maintenant les commutateurs et affiche également un aperçu des configurations que DCNM va transmettre à tous les commutateurs.

# Une fois qu'il a réussi, l'état est reflété et les commutateurs sont également affichés en vert

Étape 3 : Configuration des réseaux/VRF

- Configuration des réseaux/VRF

# Sélectionnez Fabric DC1 (dans la liste déroulante supérieure droite), Control > VRF

# Crée ensuite le VRF

# 11.2 La version DCNM remplit automatiquement l'ID VRF ; Si elle est différente, tapez celle dont vous avez besoin et sélectionnez « Créer VRF »

# Ici, le VNID de couche 3 utilisé est 1001445

- L'étape suivante consiste à créer des réseaux

# Indiquez l'ID réseau (qui correspond au VNID correspondant des VLAN de couche 2).

# Fournir le VRF dont l'interface SVI doit faire partie ; Par défaut, DCNM 11.2 remplit le nom VRF sur le nom précédemment créé ; Modifier en fonction des besoins

# L'ID de VLAN sera le VLan de couche 2 mappé à ce VNID particulier

# Passerelle IPv4-> Il s'agit de l'adresse IP de la passerelle Anycast qui sera configurée sur l'interface SVI et sera identique pour tous les VTEP de la structure

- L'onglet Avancé comporte des lignes supplémentaires qui doivent être remplies si par exemple : Le relais DHCP est utilisé ;

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

# Créer tout autre réseau requis pour faire partie de ce fabric ;

- Actuellement, VRF et les réseaux sont définis dans DCNM ; mais pas poussé de DCNM vers les commutateurs du fabric. Ceci peut être vérifié à l'aide des éléments ci-dessous

# L'état sera dans « NA » si ce n'est PAS déployé sur les commutateurs. Comme il s'agit d'un site multisite qui implique des passerelles en limite, le déploiement de réseaux/VRF sera traité plus en détail.

Étape 4 : Répétez les mêmes étapes pour DC2

- Maintenant que le DC1 est entièrement défini, effectuera la même procédure pour le DC2 également

- Une fois que DC2 est entièrement défini, il se présente comme ci-dessous

Étape 5 : Création d'un fabric facile pour les frontières partagées

- C'est ici qu'est créé un autre fabric facile qui inclura les frontières partagées qui sont dans vPC

- Notez que les bordures partagées lors du déploiement via DCNM Doivent être configurées comme vPC, sinon, les liaisons entre commutateurs seront arrêtées après une opération de « re-synchronisation » sur DCNM

- Les commutateurs dans les bordures partagées doivent être définis avec le rôle « Bordure »

Nombre de VRF créées comme pour les fabrics DC1 et DC2

# Les réseaux ne sont pas requis sur une frontière partagée, car la frontière partagée ne comporte aucun VLAN/VNID de couche 2 ; Les frontières partagées ne sont pas une terminaison de tunnel pour tout trafic Est/Ouest de DC1 à DC2 ; Seules les passerelles de périphérie joueraient un rôle en termes d’encapsulation/désencapsulation vxlan pour le trafic DC1 Est/Ouest<>DC2

Étape 6 - Création de MSD et déplacement de structures DC1 et DC2

Accédez à Fabric Builder et créez un nouveau fabric et utilisez le modèle -> MSD_Fabric_11_1

# Notez que la méthode de déploiement IFC de superposition multisite doit être "central_To_Route_Server« ; Ici, les frontières partagées sont considérées comme des serveurs de routage et cette option est donc utilisée à partir de la liste déroulante

# dans la "liste de serveurs de route multisite« ; Ici, découvrez les adresses IP de bouclage de Loopback0 (qui est le bouclage de routage) sur la bordure partagée et complétez-les

# ASN est celui sur la bordure partagée (voir le schéma en haut de ce document pour plus de détails); Pour les besoins de ce document, les deux bordures partagées sont configurées dans le même ASN ; Compléter en conséquence

- L'onglet suivant indique la plage d'adresses IP de bouclage multisite, comme indiqué ci-dessous

# Une fois tous les champs renseignés, cliquez sur le bouton « Enregistrer » et un nouveau fabric sera créé avec le modèle-> MSD

# Déplacer ensuite les fabrics DC1 et DC2 vers ce MSD

# Après le déplacement de la structure, elle ressemble à ci-dessous

# Une fois terminé, cliquez sur le bouton « Enregistrer et déployer » pour afficher les configurations requises en ce qui concerne les passerelles frontalières multisite.

Étape 7 : Création d'un fabric externe

# Créer un fabric externe et y ajouter le routeur externe comme indiqué ci-dessous ;

# Nommez le fabric et utilisez le modèle-> « External_Fabric_11_1 »;

# Fournir l'ASN

# À la fin, les différents tissus ressembleront à ceux qui suivent

Étape 8 : Sous-couche eBGP pour l'accessibilité en mode bouclé entre les BGW(iBGP entre les frontières partagées également)

# Les bordures partagées exécutent l2vpn eBGP avec les passerelles de périphérie et les connexions VRF-LITE vers le routeur externe

# Avant de créer un evpn l2vpn eBGP avec les boucles, il est nécessaire de s'assurer que les boucles sont accessibles via une méthode quelconque ; Dans cet exemple, nous utilisons l'AF IPv4 eBGP des BGW aux frontières partagées, puis nous annonçons les bouclages pour former le voisinage de l2vpn evpn.

# Une fois le fabric MSD sélectionné, passez en mode tabulaire

# Sélectionnez l'interfabric et utilisez la valeur Multisite_UNDERLAY.

# Nous essayons ici de former un voisinage BGP IPv4 avec le routeur de frontière partagée ; Sélectionnez les commutateurs et les interfaces en conséquence.

# Notez que si CDP détecte le voisin de DC1-BGW1 à SB1, il est seulement nécessaire de fournir les adresses IP ici dans cette section et cela permettra de configurer efficacement les adresses IP sur les interfaces pertinentes après avoir effectué la sauvegarde et le déploiement.

# Une fois l'option Enregistrer et déployer sélectionnée, les lignes de configuration requises sont propagées pour DC1-BGW1 ; La même étape devra être effectuée après avoir sélectionné le fabric « Shared border ».

# À partir de l'interface de ligne de commande, la même chose peut être vérifiée à l'aide de la commande ci-dessous ;

DC1-BGW1# show ip bgp sum

BGP summary information for VRF default, address family IPv4 Unicast

BGP router identifier 10.10.10.1, local AS number 65000

BGP table version is 11, IPv4 Unicast config peers 1, capable peers 1

2 network entries and 2 paths using 480 bytes of memory

BGP attribute entries [1/164], 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.4.10.2       4 65001       6       7       11    0    0 00:00:52 0

# Notez que la commande « save&Deploy » doit également être exécutée sur le fabric DC1 (sélectionnez la liste déroulante pour DC1, puis effectuez la même opération) afin que l'adressage IP approprié, les configurations BGP soient propagées aux commutateurs dans DC1 (qui sont les passerelles de périphérie) ;

# En outre, la sous-couche multisite doit être créée à partir de DC1-BGW, DC2-BGW vers des frontières partagées ; donc, les mêmes étapes que ci-dessus doivent être faites pour la même chose aussi.

# À la fin, les frontières partagées auront un voisinage AF IPv4 eBGP avec tous les BGW dans DC1 et DC2 comme ci-dessous ;

SHARED-BORDER1# 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 38, IPv4 Unicast config peers 4, capable peers 4

18 network entries and 20 paths using 4560 bytes of memory

BGP attribute entries [2/328], 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    1715    1708       38    0    0    1d03h 5

10.4.10.6       4 65000    1461    1458       38    0    0    1d00h 5

10.4.10.18      4 65002    1459    1457       38    0    0    1d00h 5

10.4.10.22      4 65002    1459    1457       38    0    0    1d00h 5

SHARED-BORDER2# 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 26, IPv4 Unicast config peers 4, capable peers 4

18 network entries and 20 paths using 4560 bytes of memory

BGP attribute entries [2/328], 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.10      4 65000    1459    1458       26    0    0    1d00h 5

10.4.10.14      4 65000    1461    1458       26    0    0    1d00h 5

10.4.10.26      4 65002    1459    1457       26    0    0    1d00h 5

10.4.10.30      4 65002    1459    1457       26    0    0    1d00h 5

# Ci-dessus figure les conditions préalables à la construction du voisinage de l2vpn evpn des BGW aux frontières partagées(Notez qu'il n'est pas obligatoire d'utiliser BGP ; tout autre mécanisme d'échange de préfixes de bouclage ferait l'affaire); À la fin, la condition de base est que tous les bouclages (de frontières partagées, BGW) doivent être accessibles à partir de tous les BGW

# Veuillez également noter qu'un voisinage AF IPv4 iBGP doit être établi entre des frontières partagées ; À partir d'aujourd'hui, DCNM n'a pas la possibilité de créer un iBGP entre les bordures partagées à l'aide d'un modèle/liste déroulante ; Pour cela, une configuration de forme libre doit être effectuée, comme indiqué ci-dessous ;

# Recherchez les adresses IP configurées sur l'interface SVI de sauvegarde des frontières partagées ; Comme indiqué ci-dessus, la forme libre est ajoutée sur le commutateur Shared-border1 et le voisin iBGP spécifié est celui de Shared-border2(10.100.100.2)

# Notez que, tout en fournissant les configurations dans la forme libre dans DCNM, indiquez l'espacement correct après chaque commande (laissez un nombre pair d'espaces ; cela signifie qu’après le routeur bgp 65001, fournissez deux espaces, puis donnez la commande neighbor <> et ainsi de suite)

# Veillez également à effectuer une redistribution directe pour les routes directes (routes de bouclage) dans BGP ou sous une autre forme pour annoncer les bouclages ; dans l'exemple ci-dessus, une route-map direct est créée pour correspondre à toutes les routes directes, puis la redistribution directe est effectuée dans le BGP AF IPv4

# Une fois la configuration enregistrée et déployée à partir de DCNM, le voisinage iBGP se forme comme indiqué ci-dessous ;

SHARED-BORDER1# 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 57, IPv4 Unicast config peers 5, capable peers 5

18 network entries and 38 paths using 6720 bytes of memory

BGP attribute entries [4/656], 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    1745    1739       57    0    0    1d04h 5

10.4.10.6       4 65000    1491    1489       57    0    0    1d00h 5

10.4.10.18      4 65002    1490    1487       57    0    0    1d00h 5

10.4.10.22      4 65002    1490    1487       57    0    0    1d00h 5

10.100.100.2    4 65001      14       6       57    0    0 00:00:16 18 # iBGP neighborship from shared border1 to shared border2

# Avec l'étape ci-dessus, la sous-couche multisite est entièrement configurée.

# L'étape suivante consiste à créer la superposition multisite ;

Étape 9 : Création d'une superposition multisite des BGW aux frontières partagées

# Notez que les frontières partagées sont également des serveurs de routage.

# Sélectionnez le MSD, puis accédez à la vue tabulaire où un nouveau lien peut être créé ; À partir de là, une nouvelle liaison de superposition multisite doit être créée et les adresses IP pertinentes doivent être fournies avec le bon ASN comme indiqué ci-dessous ; Cette étape doit être effectuée pour tous les voisins de l2vpn evpn (qui vont de chaque BGW à chaque frontière partagée)

# Ci-dessus est un exemple ; Effectuez la même opération pour toutes les autres liaisons de superposition multisite et à la fin, l'interface de ligne de commande se présente comme suit :

SHARED-BORDER1# sh bgp l2vpn evpn summary

BGP summary information for VRF default, address family L2VPN EVPN

BGP router identifier 10.10.100.1, local AS number 65001

BGP table version is 8, L2VPN EVPN config peers 4, capable peers 4

1 network entries and 1 paths using 240 bytes of memory

BGP attribute entries [1/164], 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      21      19        8    0    0 00:13:52 0

10.10.10.2      4 65000      22      20        8    0    0 00:14:14 0

10.10.20.1      4 65002      21      19        8    0    0 00:13:56 0

10.10.20.2      4 65002      21      19        8    0    0 00:13:39 0

SHARED-BORDER2# sh bgp l2vpn evpn summary

BGP summary information for VRF default, address family L2VPN EVPN

BGP router identifier 10.10.100.2, local AS number 65001

BGP table version is 8, L2VPN EVPN config peers 4, capable peers 4

1 network entries and 1 paths using 240 bytes of memory

BGP attribute entries [1/164], 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      22      20        8    0    0 00:14:11 0

10.10.10.2      4 65000      21      19        8    0    0 00:13:42 0

10.10.20.1      4 65002      21      19        8    0    0 00:13:45 0

10.10.20.2      4 65002      22      20        8    0    0 00:14:15 0

Étape 10 : Déploiement de réseaux/VRF sur les deux sites

# À la fin de la sous-couche et de la superposition multisite, l'étape suivante consiste à déployer les réseaux/VRF sur tous les périphériques ;

# Commençons par les VRF sur les fabrics-> DC1, DC2 et bordures partagées.

# Une fois la vue VRF sélectionnée, cliquez sur « continuer »; Cette opération répertorie les périphériques de la topologie.

# Étant donné que le VRF doit être déployé sur plusieurs commutateurs (y compris les passerelles en limite et les feuilles), activez la case à cocher située à l'extrême droite, puis sélectionnez les commutateurs qui ont le même rôle à la fois ; par exemple : DC1-BGW1 et DC1-BGW2 peuvent être sélectionnés simultanément, puis enregistrer les deux commutateurs ; Ensuite, sélectionnez les commutateurs Leaf qui s'appliquent (ici, il s'agit de DC1-VTEP).

# Comme indiqué ci-dessus, lorsque l'option Déployer est sélectionnée, tous les commutateurs précédemment sélectionnés démarrent le déploiement et finissent par devenir verts si le déploiement a réussi.

# Les mêmes étapes devront être effectuées pour le déploiement des réseaux ;

# Si plusieurs réseaux sont créés, n'oubliez pas de naviguer jusqu'aux onglets suivants pour sélectionner les réseaux avant de les déployer

# L'état va maintenant passer à « DÉPLOYÉ » de « NA » et l'interface de ligne de commande du commutateur ci-dessous peut être utilisée afin de vérifier les déploiements

DC1-VTEP# sh nve vni

Codes: CP - Control Plane        DP - Data Plane

UC - Unconfigured         SA - Suppress ARP

SU - Suppress Unknown Unicast

Xconn - Crossconnect

MS-IR - Multisite Ingress Replication

Interface VNI      Multicast-group   State Mode Type [BD/VRF]      Flags

--------- -------- ----------------- ----- ---- ------------------ -----

nve1      100144   239.1.1.144       Up    CP   L2 [144]                # Network1 which is VLan 144 mapped to VNID 100144

nve1      100145   239.1.1.145       Up    CP   L2 [145]                # Network2 Which is Vlan 145 mapped to VNID 100145

nve1      1001445  239.100.100.100   Up    CP   L3 [tenant-1]           # VRF- tenant1 which is mapped to VNID 1001445

DC1-BGW1# sh nve vni

Codes: CP - Control Plane        DP - Data Plane

UC - Unconfigured         SA - Suppress ARP

SU - Suppress Unknown Unicast

Xconn - Crossconnect

MS-IR - Multisite Ingress Replication

Interface VNI      Multicast-group   State Mode Type [BD/VRF]      Flags

--------- -------- ----------------- ----- ---- ------------------ -----

nve1      100144   239.1.1.144       Up    CP   L2 [144]           MS-IR

nve1      100145   239.1.1.145       Up    CP   L2 [145]           MS-IR

nve1      1001445  239.100.100.100   Up    CP   L3 [tenant-1]

# Ci-dessus provient également de BGW ; bref, tous les commutateurs sélectionnés précédemment dans l'étape seront déployés avec les réseaux et VRF

# Les mêmes étapes doivent être effectuées pour le fabric DC2, la frontière partagée également. Gardez à l'esprit que les frontières partagées NE nécessitent aucun réseau ou VNID de couche 2 ; seul le VRF de couche 3 est requis.

Étape 11 : Création de ports de liaison/d'accès en aval sur les commutateurs leaf/VTEP

# Dans cette topologie, les ports Eth1/2 et Eth1/1 de DC1-VTEP et DC2-VTEP sont respectivement connectés aux hôtes ; Ainsi, déplacez-les en tant que ports trunk dans l'interface utilisateur graphique DCNM, comme indiqué ci-dessous

# Sélectionnez l'interface appropriée et passez de no à all (ou uniquement aux vlan autorisés)

Étape 12: Formes libres requises sur la frontière partagée

# Puisque les commutateurs de frontière partagés sont les serveurs de routage, il est nécessaire d'apporter quelques modifications en termes de voisinage de l2vpn evpn BGP

# le trafic BUM inter-site est répliqué à l'aide de la monodiffusion ; signifie tout trafic BUM dans le VLAN 144(e) après son arrivée sur les BGW ; selon le BGW qui est le répartiteur désigné (DF), DF effectue une réplication monodiffusion sur un site distant ; Cette réplication est effectuée après que le BGW a reçu une route de type 3 du BGW distant ; Ici, les BGW forment l2vpn même appairant uniquement avec des frontières partagées ; et les frontières partagées ne doivent pas avoir de VNID de couche 2 (si elles sont créées, cela entraînera un blocage du trafic Est/Ouest). Puisque les VNID de couche 2 sont manquants et que le type de route 3 est généré par des BGW par VNID, les frontières partagées ne respecteront pas la mise à jour BGP provenant des BGW ; Pour résoudre ce problème, utilisez la commande « keep route-target all » sous AF l2vpn evpn

# Un autre point est de s'assurer que les bordures partagées ne changent pas le tronçon suivant (BGP BY default change le tronçon suivant pour les voisins eBGP); Ici, le tunnel inter-site pour le trafic de monodiffusion du site 1 à 2 et vice versa devrait être de BGW à BGW (de dc1 à dc2 et vice versa); Pour ce faire, une carte de routage doit être créée et appliquée pour chaque voisinage d'événements l2vpn de frontière partagée à chaque BGW

# Pour les deux points ci-dessus, une forme libre doit être utilisée sur les frontières partagées comme ci-dessous

route-map direct

route-map unchanged

set ip next-hop unchanged

router bgp 65001

address-family ipv4 unicast

redistribute direct route-map direct

address-family l2vpn evpn

retain route-target all

neighbor 10.100.100.2

remote-as 65001

address-family ipv4 unicast

next-hop-self

neighbor 10.10.10.1

address-family l2vpn evpn

route-map unchanged out

neighbor 10.10.10.2

address-family l2vpn evpn

route-map unchanged out

neighbor 10.10.20.1

address-family l2vpn evpn

route-map unchanged out

neighbor 10.10.20.2

address-family l2vpn evpn

route-map unchanged out

Étape 13 : Bouclage dans les VRF de locataire sur les BGW

# pour le trafic Nord/Sud provenant d’hôtes connectés au sein des commutateurs Leaf, les BGW utilisent l’adresse IP SRC externe de l’adresse IP NVE Loopback1 ; Les bordures partagées formeront uniquement par défaut l'appairage NVE avec l'adresse IP de bouclage multisite des BGW ; donc, si un paquet vxlan arrive à la frontière partagée avec une adresse IP SRC externe du bouclage BGW 1, le paquet sera abandonné en raison de l'absence de SRCTEP ; Pour éviter cela, un bouclage dans le client-VRF doit être créé sur chaque commutateur BGW, puis annoncé au BGP afin que les frontières partagées reçoivent cette mise à jour, puis forment l'appairage NVE avec l'adresse IP de bouclage BGW 1 ;

# Au début, l'appairage NVE ressemblera à un peu plus bas sur les frontières partagées

SHARED-BORDER1# sh nve pee

Interface Peer-IP                                 State LearnType Uptime   Router-Mac

--------- --------------------------------------  ----- --------- -------- -----------------

nve1      10.222.222.1                            Up    CP        01:20:09 0200.0ade.de01   # Multisite Loopback 100 IP address of DC1-BGWs

nve1      10.222.222.2                            Up    CP        01:17:43 0200.0ade.de02   # Multisite Loopback 100 IP address of DC2-BGWs

# Comme indiqué ci-dessus, le bouclage2 est créé à partir de DCNM et est configuré dans le VRF du locataire-1 et reçoit la balise 12345 car il s'agit de la balise que le routage-map utilise pour correspondre au bouclage lors de l'annonce

DC1-BGW1# sh run vrf tenant-1

!Command: show running-config vrf tenant-1

!Running configuration last done at: Tue Dec 10 17:21:29 2019

!Time: Tue Dec 10 17:24:53 2019

version 9.3(2) Bios:version 07.66

interface Vlan1445

vrf member tenant-1

interface loopback2

vrf member tenant-1

vrf context tenant-1

vni 1001445

ip pim rp-address 10.49.3.100 group-list 224.0.0.0/4

ip pim ssm range 232.0.0.0/8

rd auto

address-family ipv4 unicast

route-target both auto

route-target both auto mvpn

route-target both auto evpn

address-family ipv6 unicast

route-target both auto

route-target both auto evpn

router bgp 65000

vrf tenant-1

address-family ipv4 unicast

advertise l2vpn evpn

redistribute direct route-map fabric-rmap-redist-subnet

maximum-paths ibgp 2

address-family ipv6 unicast

advertise l2vpn evpn

redistribute direct route-map fabric-rmap-redist-subnet

maximum-paths ibgp 2

DC1-BGW1# sh route-map fabric-rmap-redist-subnet

route-map fabric-rmap-redist-subnet, permit, sequence 10

Match clauses:

tag: 12345

Set clauses:

# Après cette étape, les homologations NVE s'affichent pour toutes les adresses Ip de bouclage 1 ainsi que pour l'adresse IP de bouclage multisite.

SHARED-BORDER1# sh nve pee

Interface Peer-IP                                 State LearnType Uptime   Router-Mac

--------- --------------------------------------  ----- --------- -------- -----------------

nve1      192.168.20.1                            Up    CP        00:00:01 b08b.cfdc.2fd7

nve1      10.222.222.1                            Up    CP        01:27:44 0200.0ade.de01

nve1      192.168.10.2                            Up    CP        00:01:00 e00e.daa2.f7d9

nve1      10.222.222.2                            Up    CP        01:25:19 0200.0ade.de02

nve1      192.168.10.3                            Up    CP        00:01:43 6cb2.aeee.0187

nve1      192.168.20.3                            Up    CP        00:00:28 005d.7307.8767

# À ce stade, le trafic Est/Ouest doit être transmis correctement

Étape 14 : Extensions VRFLITE des frontières partagées vers les routeurs externes

# Il y aura des situations où des hôtes en dehors du fabric devront parler aux hôtes du fabric. Dans cet exemple, les frontières partagées rendent possible la même chose ;

# Tout hôte qui vit dans DC1 ou DC2 pourra parler aux hôtes externes via les commutateurs de frontière partagés.

# À cette fin, les bordures partagées terminent la VRF Lite ; Ici, dans cet exemple, eBGP s'exécute à partir des bordures partagées vers les routeurs externes, comme illustré dans le schéma du début.

# Pour la configuration à partir de DCNM, il est nécessaire d'ajouter des pièces jointes d'extension vrf. Les étapes ci-dessous doivent être suivies pour parvenir à la même conclusion.

a) Ajout de liaisons inter-fabric à partir de frontières partagées vers des routeurs externes

# Sélectionnez l'étendue du générateur de fabric sur « bordure partagée » et passez à la vue tabulaire

# Sélectionnez les liens et ajoutez un lien « Inter-Fabric » comme indiqué ci-dessous

# Un sous-type LITE VRF doit être sélectionné dans la liste déroulante

# Le fabric source est des frontières partagées et le fabric de destination est externe car il s'agit d'un LITE VRF de SB vers External

# Sélectionnez les interfaces appropriées qui vont vers le routeur externe

# Indiquez l'adresse IP et le masque, ainsi que l'adresse IP voisine.

# ASN sera renseigné automatiquement.

# Une fois que vous avez terminé, cliquez sur Enregistrer

# Effectuez la même opération pour les frontières partagées et pour toutes les connexions externes de couche 3 qui sont dans VRFLITE

b) Ajout de postes VRF

# Accéder à la section VRF de frontière partagée

# VRF sera en état de déploiement ; Cochez la case à droite pour sélectionner plusieurs commutateurs

# Sélectionnez les bordures partagées et la fenêtre « Pièce jointe VRF EXtension » s'ouvre.

# Sous « étendre », passer de « Aucun » à « VRFLITE »

# Faire la même chose pour les deux bordures partagées

# Une fois cela fait, les « Détails de l'extension » renseigneront les interfaces LITE VRF précédemment indiquées à l'étape a) ci-dessus.

# L'ID DOT1Q est renseigné automatiquement sur 2

# D'autres champs sont également renseignés automatiquement

# Si le voisinage IPv6 doit être établi via VRFLITE, l'étape a) doit être effectuée pour IPv6

# Cliquez maintenant sur Enregistrer.

# Enfin, faites le « Déployer » en haut à droite de la page Web.

# Un déploiement réussi aboutira à pousser les configurations vers les frontières partagées, ce qui inclut la définition d'adresses IP sur ces sous-interfaces et l'établissement de voisins IPv4 BGP avec les routeurs externes

# N'oubliez pas que les configurations de routeur externe (définition d'adresses IP sur les sous-interfaces et les instructions de voisinage BGP) sont effectuées manuellement par l'interface de ligne de commande dans ce cas.

# Les vérifications CLI peuvent être effectuées par les commandes ci-dessous sur les deux bordures partagées ;

SHARED-BORDER1# sh ip bgp sum vr tenant-1

BGP summary information for VRF tenant-1, address family IPv4 Unicast

BGP router identifier 172.16.22.1, local AS number 65001

BGP table version is 18, IPv4 Unicast config peers 1, capable peers 1

9 network entries and 11 paths using 1320 bytes of memory

BGP attribute entries [9/1476], 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

172.16.22.2     4 65100      20      20       18    0    0 00:07:59 1

SHARED-BORDER2# sh ip bgp sum vr tenant-1

BGP summary information for VRF tenant-1, address family IPv4 Unicast

BGP router identifier 172.16.222.1, local AS number 65001

BGP table version is 20, IPv4 Unicast config peers 1, capable peers 1

9 network entries and 11 paths using 1320 bytes of memory

BGP attribute entries [9/1476], 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

172.16.222.2    4 65100      21      21       20    0    0 00:08:02 1

# Avec toutes les configurations ci-dessus, l'accessibilité Nord/Sud sera également établie comme indiqué ci-dessous (requêtes ping du routeur externe aux hôtes du fabric)

EXT_RTR# ping 172.16.144.1                                   # 172.16.144.1 is Host in DC1 Fabric

PING 172.16.144.1 (172.16.144.1): 56 data bytes

64 bytes from 172.16.144.1: icmp_seq=0 ttl=251 time=0.95 ms

64 bytes from 172.16.144.1: icmp_seq=1 ttl=251 time=0.605 ms

64 bytes from 172.16.144.1: icmp_seq=2 ttl=251 time=0.598 ms

64 bytes from 172.16.144.1: icmp_seq=3 ttl=251 time=0.568 ms

64 bytes from 172.16.144.1: icmp_seq=4 ttl=251 time=0.66 ms

^[[A^[[A

--- 172.16.144.1 ping statistics ---

5 packets transmitted, 5 packets received, 0.00% packet loss

round-trip min/avg/max = 0.568/0.676/0.95 ms

EXT_RTR# ping 172.16.144.2                                  # 172.16.144.2 is Host in DC2 Fabric

PING 172.16.144.2 (172.16.144.2): 56 data bytes

64 bytes from 172.16.144.2: icmp_seq=0 ttl=251 time=1.043 ms

64 bytes from 172.16.144.2: icmp_seq=1 ttl=251 time=6.125 ms

64 bytes from 172.16.144.2: icmp_seq=2 ttl=251 time=0.716 ms

64 bytes from 172.16.144.2: icmp_seq=3 ttl=251 time=3.45 ms

64 bytes from 172.16.144.2: icmp_seq=4 ttl=251 time=1.785 ms

--- 172.16.144.2 ping statistics ---

5 packets transmitted, 5 packets received, 0.00% packet loss

round-trip min/avg/max = 0.716/2.623/6.125 ms

# Les routes traceroute pointent également vers les périphériques appropriés dans le chemin du paquet

EXT_RTR# traceroute 172.16.144.1

traceroute to 172.16.144.1 (172.16.144.1), 30 hops max, 40 byte packets

1  SHARED-BORDER1 (172.16.22.1)  0.914 ms  0.805 ms  0.685 ms

2  DC1-BGW2 (172.17.10.2)  1.155 ms DC1-BGW1 (172.17.10.1)  1.06 ms  0.9 ms

3  ANYCAST-VLAN144-IP (172.16.144.254) (AS 65000)  0.874 ms  0.712 ms  0.776 ms

4  DC1-HOST (172.16.144.1) (AS 65000)  0.605 ms  0.578 ms  0.468 ms

EXT_RTR# traceroute 172.16.144.2

traceroute to 172.16.144.2 (172.16.144.2), 30 hops max, 40 byte packets

1  SHARED-BORDER2 (172.16.222.1)  1.137 ms  0.68 ms  0.66 ms

2  DC2-BGW2 (172.17.20.2)  1.196 ms DC2-BGW1 (172.17.20.1)  1.193 ms  0.903 ms

3  ANYCAST-VLAN144-IP (172.16.144.254) (AS 65000)  1.186 ms  0.988 ms  0.966 ms

4  172.16.144.2 (172.16.144.2) (AS 65000)  0.774 ms  0.563 ms  0.583 ms

EXT_RTR#