Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configurer l’assemblage VXLAN pour l’interconnexion des centres de données de couche 2

Ce document décrit les étapes de configuration et de validation pour implémenter l’interconnexion du centre de données (DCI) à l’aide de l’assemblage VXLAN dans un périphérique de passerelle. La fonctionnalité d’assemblage VXLAN vous permet d’assembler des identifiants de réseau virtuel (VNI) VXLAN spécifiques pour fournir un étirement de couche 2 entre les datacenters de manière granulaire.

Les appareils de commutation et de routage de Juniper Network prennent en charge un certain nombre d’options DCI différentes. Par exemple, l’over-the-top (OTT) DCI peut être utilisé pour étendre la superposition entre les PODS. Voir OTT DCI pour plus de détails. L’un des inconvénients de la méthode OTT est qu’elle étend tous les VLAN entre les POD, soit au niveau de la couche 2, soit au niveau de la couche 3. De plus, l’OTT DCI exige l’importance d’un VNI VXLAN de bout en bout. Cela peut être un problème si deux DC/POD sont fusionnés et que les attributions VLAN vers VNI ne se chevauchent.

Dans certains cas, vous souhaitez un contrôle plus granulaire sur les VLAN étendus entre les POD. La fonction d’assemblage VXLAN de Junos vous permet d’effectuer une DCI au niveau du VNI afin d’étendre la connectivité de couche 2 par VLAN. Vous devrez peut-être également traduire les VNI pour prendre en compte les instances où les mêmes VNI sont attribués à différents VLAN dans chaque POD. Prenons l’exemple du VNI 10001 du VLAN 1 dans le POD 1, alors que dans le POD 2, c’est le même VLAN qui est attribué au VNI 20002. Dans ce cas, vous devez soit reconfigurer l’un des POD, soit obtenir un mappage global (chevauchement) des VLAN aux VNI. Vous pouvez également utiliser l’assemblage de translation pour mapper les valeurs VNI locales du POD au VNI utilisé sur le WAN.

Juniper Networks prend en charge l’assemblage VXLAN pour les fabrics IP à 3 et 5 niveaux. En outre, l’interconnexion VXLAN est prise en charge pour les architectures de superposition à pontage à routage central (CRB), ERB (Edge Rouded Bridging) et de superposition pontée. Ce cas d’utilisation suppose que vos structures POD EVPN-VXLAN sont déjà configurées avec des feuilles et des curs de réseau à l’aide d’une ou plusieurs des architectures prises en charge indiquées dans le Tableau 1.

Pour activer la connectivité VXLAN entre les deux POD, vous devez ajouter un niveau de routeurs WAN pour étendre la sous-couche. L’extension de sous-couche prolonge la superposition entre les POD. Ensuite, vous configurez l’assemblage VXLAN sur les périphériques de passerelle pour étendre les VLAN souhaités (désormais représentés par des VNI VXLAN) entre les POD.

Note:

Nous utilisons le terme « routeurs WAN » dans ce document. Cela ne signifie pas qu’il existe un réseau WAN entre les POD. Les routeurs WAN peuvent être locaux sur les deux POD, comme c’est le cas dans cet exemple. Vous pouvez également utiliser l’interconnexion VXLAN sur un réseau WAN étendu lorsque les POD sont géographiquement distants.

La figure 1 fournit un diagramme de haut niveau montrant les types de structure POD/DC que nous avons validés dans cette conception de référence.

Figure 1 : architectures de référence d’assemblage VXLAN VXLAN Stitching Reference Architectures

Sur la Figure 1, chaque routeur WAN se connecte à chaque équipement de passerelle dans les deux POD. Ces connexions et les sessions homologues pair BGP associées servent à étendre l’underlay entre les deux POD. Plus précisément, les appareils annoncent les adresses de bouclage des périphériques de passerelle entre les POD. Cette accessibilité de bouclage établit une session d’appairage basée sur EBGP pour étendre la superposition entre les équipements de passerelle dans les deux pods.

Le POD 1 représente une architecture CRB à 3 niveaux avec la fonction de passerelle réduite dans les périphériques de cur de réseau. Ainsi, dans le POD 1, les termes « spine » et « gateway » s’appliquent chacun. En général, nous utiliserons le terme passerelle pour décrire les périphériques de cur de réseau, car l’accent est mis ici sur leur fonctionnalité de passerelle.

Le POD 2, en revanche, est une architecture ERB à 5 étapes avec des spines légers et des passerelles discrètes. Les périphériques de passerelle dans le POD 2 peuvent également être appelés périphériques super-spine ou border leaf. Dans le contexte de cet exemple, ils exécutent la fonctionnalité d’assemblage VXLAN et sont donc appelés périphériques de passerelle.

Le tableau 1 présente les architectures POD que nous avons validées dans le cadre de cette conception de référence.

Tableau 1 : Architectures POD prises en charge pour l’interconnexion VXLAN

POD 1

POD 2

Pontage à routage périphérique

Pontage à routage périphérique

Pontage à routage central

Pontage à routage périphérique

Pontage à routage central

Pontage à routage central

Superposition pontée

Superposition pontée

Tissu à 3 ou 5 étages

Tissu à 3 ou 5 étages

Autres éléments à noter lors de l’utilisation de l’assemblage VXLAN :

  • Vous pouvez combiner le rôle de spine et de gateway dans une conception réduite, comme illustré pour l’espace 1.

  • Le VNI assemblé peut avoir la même valeur (assemblage global) lorsque les POD ont des affectations VLAN à VNI qui se chevauchent, ou peut être converti entre les deux POD. Cette dernière fonctionnalité est utile lors de la fusion de POD (DC) qui n’ont pas d’affectations VNI à VLAN qui se chevauchent.

  • L’assemblage VXLAN prend en charge l’interconnexion de commutateurs par défaut (EVI) et dans les instances de routage MAC-VRF.

  • L’assemblage de couche 2 ne concerne que le trafic unicast et BUM. Dans le cas du trafic BUM, le redirecteur désigné (DF) du LAG ESI de la passerelle locale effectue la réplication d’entrée et transfère une copie du trafic BUM à chaque passerelle distante. Au niveau des périphériques de passerelle distants, le DF du LAG ESI distant effectue la réplication d’entrée et envoie une copie du trafic BUM à tous les nuds Leaf du POD local.

  • Le périphérique de passerelle doit être un commutateur de la gamme QFX10000 exécutant Junos Software version 20.4R3 ou supérieure.

  • Nous vous recommandons de configurer les interfaces IRB sur les équipements de cur de réseau d’une fabric CRB à l’aide de l’instruction proxy-macip-advertisement de configuration. Cette option garantit le bon fonctionnement de l’ARP sur une fabric CRB EVPN-VXLAN et fait partie de l’architecture de référence CRB. Voir proxy-mac-ip-advertisement pour plus d’informations sur cette option.

Notez ce qui suit à propos de la conception de référence de la structure EVPN-VXLAN :

  • Cet exemple part du principe que les niveaux d’équipements Spine et Leaf dans les deux POD existent déjà et sont opérationnels. Par conséquent, cette rubrique fournit la configuration de l’appairage de sous-couche EBGP de passerelle vers routeur WAN, l’appairage de superposition EBGP inter-POD et la configuration nécessaire pour l’assemblage VXLAN.

    Pour plus d’informations sur la configuration des équipements Spine et Leaf dans les deux POD, consultez les rubriques suivantes :

  • Cet exemple intègre les routeurs WAN dans une fabric EVPN-VXLAN existante à deux POD. Pour garder l’accent sur l’assemblage VXLAN, les deux POD de l’exemple utilisent la même structure Clos en 3 étapes basée sur une architecture CRB. En plus de leur rôle de passerelles VXLAN de couche 3, les dorsales assurent également la fonction d’assemblage VXLAN. Le résultat est un exemple d’architecture de passerelle réduite.

    La figure 2 montre l’exemple de topologie d’assemblage VXLAN basé sur le CRB de la passerelle réduite.

    Figure 2 : exemple de topologie VXLAN Stitching Example Topology d’assemblage VXLAN

    Dans cet exemple, vous ajoutez la fonctionnalité de passerelle à une configuration de dorsale CRB préexistante. Comme indiqué ci-dessus, nous prenons également en charge les architectures à 5 niveaux, la couche super-spine exécutant les fonctions d’appairage et d’assemblage de passerelles. Nous vous recommandons d’utiliser une passerelle discrète pour une évolutivité et des performances maximales. Avec une architecture ERB à 3 ou 5 niveaux, vous ajoutez la configuration de la passerelle aux équipements Lean Spine ou Super Spine respectivement.

  • Lors de la configuration de l’appairage BGP superposé entre les POD, vous pouvez utiliser IBGP ou EBGP. En règle générale, vous utilisez IBGP si vos centres de données (POD) utilisent le même numéro de système autonome (AS) et EBGP si vos POD utilisent des numéros AS différents. Notre exemple utilise des numéros AS différents dans chaque POD, c’est pourquoi l’appairage EBGP est utilisé pour étendre la superposition entre les POD.

  • Une fois que vous avez intégré les routeurs WAN pour étendre l’underlay et l’overlay entre les deux POD, vous configurez l’assemblage VXLAN translationnel pour étendre un VLAN donné entre les POD. L’interconnexion VXLAN translationnelle convertit la valeur VNI utilisée localement dans chaque POD en une valeur VNI commune utilisée sur l’ensemble du segment WAN. Notez que dans notre exemple, nous attribuons au VLAN 1 une valeur VNI différente (sans chevauchement) dans chaque POD. C’est pourquoi nous utilisons l’assemblage translationnel dans ce cas. Vous utilisez normalement l’assemblage en mode global lorsque la même valeur VNI est mappée au même VLAN dans les deux POD.

Configurer les équipements de passerelle pour étendre l’underlay sur le WAN

Cette section vous montre comment configurer les périphériques de passerelle réduits (une dorsale CRB avec une fonctionnalité de passerelle d’assemblage VXLAN ajoutée) afin qu’ils puissent communiquer avec les périphériques WAN. Rappelons que chaque POD dispose déjà d’une sous-couche et d’une superposition CRB entièrement fonctionnelles basées sur l’implémentation de référence d’une architecture CRB à 3 étages. Pour plus d’informations, reportez-vous à la section Conception et mise en œuvre de la superposition à pontage à routage central .

Vous configurez les équipements spine/gateway pour qu’ils s’appairent aux routeurs WAN afin d’étendre l’underlay entre les deux POD. Cela implique de configurer l’appairage et la stratégie EBGP pour baliser et annoncer les routes de bouclage à partir de chaque passerelle. Ces routes établissent les sessions d’appairage EBGP inter-POD qui étendent la superposition de structure dans la section suivante.

Note:

La configuration des routeurs WAN n’entre pas dans le cadre de ce document. Il leur suffit de prendre en charge les interfaces Ethernet agrégées et l’appairage EBGP vers les équipements de passerelle. Dans cet exemple, les routeurs WAN doivent annoncer à nouveau toutes les routes reçues d’un POD à l’autre. Dans le cas d’un équipement Junos, il s’agit de la stratégie par défaut pour l’appairage de sous-couche EBGP dans cet exemple.

La Figure 3 fournit des détails concernant les interfaces, l’adressage IP et la numérotation AS pour la partie DCI des réseaux POD.

Figure 3 : Détails de l’extension Underlay et Overlay sur le WAN Details for Underlay and Overlay Extension Across the WAN

La configuration sur tous les périphériques de passerelle est similaire. Nous vous guiderons tout au long de la configuration de l’appareil de la passerelle 1, puis vous fournirons le delta de configuration complet pour les 3 autres passerelles.

Gateway 1

  1. Configurez les interfaces qui connectent l’équipement de passerelle 1 aux deux routeurs WAN.

    Ici, nous créons une interface Ethernet agrégée (AE) qui inclut un seul membre. Avec cette approche, vous pouvez facilement ajouter des liens membres supplémentaires pour augmenter le débit ou la résilience du WAN.

  2. Créez un groupe homologue pair BGP nommé underlay-bgp-wan, puis configurez-le en tant que groupe EBGP.
  3. Configurez le numéro AS de la sous-couche EBGP.

    Dans cette conception de référence, vous attribuez un numéro AS unique à chaque équipement du réseau sous-jacent. Reportez-vous à la Figure 3 pour connaître les numéros AS de la passerelle et des périphériques WAN.

    Vous configurez le numéro AS pour EBGP dans le réseau underlay au niveau du groupe homologue pair BGP à l’aide de l’instruction local-as , car le paramètre de numéro AS système au niveau de la [edit routing-options autonomous-system] hiérarchie est utilisé pour l’appairage de superposition MP-IBGP dans la structure locale et pour l’appairage EBGP utilisé pour étendre la superposition entre les POD.

  4. Configurez l’appairage EBGP avec les équipements WAN 1 et 2.

    Vous configurez chaque périphérique WAN en tant que voisin EBGP en spécifiant l’adresse IP et le numéro AS du périphérique WAN. Reportez-vous à la Figure 3 pour connaître les adresses IP et les numéros AS des périphériques de cur de réseau.

  5. Configurez une stratégie de routage d’importation qui soustrait 10 de la valeur de préférence locale des routes reçues du WAN lorsqu’elles sont balisées avec une communauté spécifique. Cette stratégie garantit que l’équipement de passerelle préfère toujours une route underlay locale, même lorsque la même adresse de bouclage de passerelle est également apprise via l’appairage WAN.

    Rappelons qu’EBGP est utilisé pour l’appairage de la passerelle au routeur WAN. Par défaut, EBGP relance l’annonce de tous les itinéraires reçus à tous les autres voisins EBGP (et IBGP). Cela signifie que lorsque la passerelle 1 annonce sa route de bouclage vers le routeur WAN 1, le routeur WAN annonce à nouveau cette route vers la passerelle 2. Par conséquent, chaque passerelle dispose d’une route intra-fabric et d’une route inter-fabric pour atteindre l’autre passerelle dans son POD local.

    Il faut s’assurer que la passerelle privilégie toujours le chemin intra-fabric. Pour ce faire, nous ajustons la valeur de préférence locale pour les routes reçues du WAN (afin de les rendre moins préférées, quelle que soit la longueur du chemin AS). La stratégie bloque également la réannonce des routes de bouclage de passerelle apprises via l’appairage WAN dans la structure locale. Par conséquent, les équipements Leaf ne voient que l’itinéraire de bouclage de la passerelle intra-fabric, alors qu’ils préfèrent toujours l’itinéraire de la passerelle intra-fabric.

    Vous définissez la communauté référencée à l’étape suivante.

    Note:

    Cet exemple suppose que vous partez d’une architecture de référence de base dans les deux POD. Une partie de la ligne de base de référence préexistante est l’appairage et la stratégie BGP liés à la sous-couche et à la superposition de la structure. Cet exemple est basé sur la fusion du cur de réseau et de la passerelle en un seul équipement. Maintenant que vous avez ajouté l’extension de sous-couche et de superposition via les routeurs WAN, vous devez modifier votre stratégie de sous-couche existante sur la passerelle, ou dans notre cas sur l’équipement de cur de réseau/passerelle, afin de bloquer la nouvelle publication des routes balisées avec le wan_underlay_comm à partir des autres périphériques de structure.

    Nous montrons ici un exemple de cette modification. Le terme nouvellement ajouté from_wan supprime la publication des routes avec la communauté correspondante dans la sous-couche de la structure.

  6. Configurez une stratégie de routage d’exportation pour annoncer l’adresse de l’interface de bouclage de passerelle aux périphériques WAN. Cette politique rejette toutes les autres publicités. Vous définissez maintenant la wan_underlay_comm communauté utilisée pour baliser ces itinéraires.
  7. Configurez multipath avec la possibilité d’activer l’équilibrage multiple-as de charge entre les homologues EBGP dans différents AS.

    Par défaut, EBGP sélectionne un meilleur chemin pour chaque préfixe et installe ce chemin dans la table de transfert. En outre, vous configurez BGP multipath afin que tous les chemins à coût égal vers une destination donnée soient installés dans la table de routage.

  8. Activez la détection de transfert bidirectionnel (BFD) pour les sessions WAN EBGP. BFD permet une détection rapide des défaillances et donc une reconvergence rapide.

Configurer les équipements de passerelle pour étendre la superposition sur le WAN

Cette section montre comment étendre la superposition EVPN entre les deux POD à l’aide d’EBGP. Rappelez-vous que dans cet exemple, les deux POD ont des numéros AS uniques, donc EBGP est utilisé.

Comme c’est généralement le cas pour les structures CRB à 3 étages, nos équipements de cur de réseau (passerelles) fonctionnent comme des réflecteurs de route dans l’overlay pour les équipements de branche dans leurs POD respectifs. Dans cette section, vous allez définir un nouveau groupe d’appairage EBGP qui étend la superposition entre les POD. Reportez-vous à la Figure 3 pour plus de détails sur la numérotation AS et les adresses de bouclage de l’équipement Spine.

La configuration sur tous les périphériques de passerelle est similaire. Une fois de plus, nous vous guiderons tout au long de la configuration de l’appareil de passerelle 1 et vous fournirons le delta de configuration complet pour les 3 autres passerelles.

Gateway 1

  1. Configurez le groupe EBGP pour étendre la superposition EVPN aux périphériques de la passerelle distante.

    Normalement, nous utilisons IBGP pour une superposition EVPN. Nous utilisons EBGP ici parce que nous avons attribué aux PODS des numéros AS différents. Notez ici que vous devez activer l’option multihop . Par défaut, EBGP s’attend à ce que l’homologue soit directement connecté. Dans cet exemple, l’homologue est connecté à distance de l’autre côté du WAN. En outre, vous devez configurer l’option no-nexthop-change . Cette option modifie le comportement EBGP par défaut de la mise à jour du saut suivant BGP vers une valeur locale lors de la nouvelle publication de routes. Avec cette option, vous indiquez à l’appareil de passerelle de laisser inchangé le prochain saut du protocole BGP pour la route de superposition. Ceci est important, car l’adresse IP de la passerelle peut ne pas être une adresse VTEP VXLAN, par exemple, dans une structure ERB où le prochain saut d’une route EVPN de type 2 doit identifier cet équipement Leaf. Le fait de ne pas écraser le saut suivant permet de s’assurer que les VTEP corrects sont utilisés pour les tunnels VXLAN.

    Vous configurez l’appairage EBGP entre les adresses de bouclage des périphériques de passerelle.

  2. Comme pour l’appairage underlay, nous ajoutons BFD pour détecter rapidement les défaillances dans l’extension overlay. Notez qu’ici, nous spécifions un intervalle plus long pour l’appairage de superposition. Pour l’appairage d’extensions de sous-couche, nous avons utilisé un intervalle de 1 seconde. Ici, nous configurons un intervalle de 4 secondes pour nous assurer que les sessions d’overlay restent actives en cas de défaillance d’un underlay nécessitant une reconvergence.
  3. Assurez-vous de valider les modifications sur tous les périphériques de passerelle après ces étapes.

Configurations des périphériques de passerelle pour l’extension Underlay et Overlay

Cette section fournit le delta de configuration pour les quatre périphériques de passerelle. Vous ajoutez ce delta à la ligne de base CRB initiale pour étendre la sous-couche et la superposition du POD sur le WAN.

Note:

Les deux dernières instructions modifient la stratégie de sous-couche de structure existante pour bloquer la nouvelle publication des routes balisées avec la wan_underlay_comm communauté à partir des autres équipements Leaf.

Passerelle 1 (POD 1)

Passerelle 2 (Pod 1)

Passerelle 3 (POD 2)

Passerelle 4 (POD 2)

Vérifier l’extension de la sous-couche et de la superposition sur le WAN

Cette section montre comment vérifier que les périphériques de passerelle sont correctement intégrés dans le WAN pour étendre les réseaux underlay et overlay entre les deux POD.

  1. Vérifiez que les interfaces Ethernet agrégées sont opérationnelles. L’établissement correct d’une session BGP est un bon signe que l’interface peut faire passer le trafic. En cas de doute, envoyez un ping à l’extrémité distante de la liaison AE.

    La sortie confirme que l’interface ae4 Ethernet agrégée est opérationnelle sur la passerelle 1. Les compteurs de trafic confirment également que l’interface envoie et reçoit des paquets.

  2. Vérifiez que les sessions EBGP sous-jacentes vers les périphériques WAN sont établies.

    La sortie montre que les deux sessions d’appairage EBGP sur le périphérique de passerelle 1 sont établies sur les deux routeurs WAN.

  3. Vérifiez que les sessions EBGP superposées sont établies entre les équipements de passerelle sur le WAN.

    La sortie confirme que les deux sessions EBGP superposées de l’équipement de passerelle 1 sont établies sur les deux passerelles distantes dans l’espace 2.

    Une fois l’extension de sous-couche et de superposition vérifiée, vous êtes prêt à passer à la configuration de l’assemblage VXLAN pour le DCI de couche 2 entre les POD.

Configurer l’assemblage VXLAN translationnel DCI dans l’instance de commutateur par défaut

Dans cette section, vous allez configurer l’assemblage VXLAN dans les périphériques de passerelle pour fournir un étirement de couche 2 entre les deux POD à l’aide de l’instance de commutateur par défaut. L’assemblage VXLAN est pris en charge dans l’instance de commutateur par défaut et dans les instances MAC-VRF. Nous commençons par l’instance de commutateur par défaut, puis nous montrons le delta pour le cas de l’instance MAC-VRF.

L’assemblage VXLAN prend en charge à la fois le mode global et le mode translationnel. En mode global, le VNI reste le même de bout en bout, c’est-à-dire à la fois sur les POD et sur le réseau WAN. Vous utilisez le mode global lorsque les attributions VLAN et VNI se chevauchent entre les POD. En mode translationnel, vous mappez une valeur VNI POD locale à un VNI utilisé sur le WAN.

Vous configurez l’assemblage VXLAN uniquement sur les périphériques de passerelle. Les équipements Leaf ne nécessitent aucune modification. Dans les structures ERB, les équipements Lean Spine ne nécessitent pas non plus de modifications si une couche super-spine exécute la fonction de passerelle.

Le Tableau 2 présente les attributions de VLAN et de VNI de POD. Dans cet exemple, les POD utilisent un VNI différent pour le même VLAN. C’est pourquoi vous configurez l’assemblage de translation dans ce cas. Grâce à l’assemblage translationnel, le VNI peut être unique à chaque POD tout en restant assemblé à une affectation VNI partagée sur le WAN.

Tableau 2 : mappages VLAN à VNI

POD 1

POD 2

WAN DCI

VLAN 1

VNI : 100001

VNI : 110001

VNI : 910001

VLAN 2

VNI : 100002

VNI : 110002

VNI : 910002

La figure 4 fournit une vue d’ensemble du plan d’assemblage VXLAN pour le VLAN 1 dans notre exemple.

Figure 4 : récapitulatif de l’interconnexion VXLAN translationnelle pour le VLAN 1 Translational VXLAN Stitching Summary for VLAN 1

La figure 4 montre que le VLAN 1 dans le POD 1 utilise le VNI 100001, tandis que le même VLAN dans le POD 2 correspond à 11000. Vous reliez les deux VLAN à une 910001 VNI commune pour le transport sur le WAN. Lorsqu’elle est reçue du WAN, la passerelle traduit le VNI assemblé en VNI utilisé localement dans son POD.

Là encore, la configuration sur les passerelles est similaire. Nous vous guidons à travers les étapes nécessaires sur l’équipement de passerelle 1 et fournissons le delta de configuration pour les autres nœuds de passerelle.

Procédez comme suit pour configurer l’assemblage VXLAN translationnel sur la passerelle 1.

Gateway 1

  1. Configurez les paramètres EVPN d’instance de commutation par défaut pour l’échange de routes entre les deux POD. Cette configuration inclut la prise en charge d’un LAG ESI entièrement actif entre les passerelles. La mise en place d’un LAG ESI sur le WAN garantit que toutes les liaisons WAN sont activement utilisées pour transférer le trafic sans risque de boucles de paquets. Vous devez utiliser la même valeur ESI pour toutes les passerelles d’un POD donné, et chaque POD doit utiliser une valeur ESI unique. Par conséquent, dans cet exemple, vous configurez deux ESI uniques, une pour chaque paire de passerelles dans chaque POD.

    La cible d’itinéraire contrôle les importations d’itinéraires. Vous configurez la même cible de route sur tous les périphériques de passerelle pour vous assurer que toutes les routes annoncées par un POD sont importées par l’autre. Vous définissez le distingueur de route pour qu’il reflète l’adresse de bouclage de chaque périphérique de passerelle.

  2. Configurez l’assemblage VXLAN pour les VLAN 1 et 2. Vous spécifiez les VNI qui sont assemblés sur le WAN au niveau de la [edit protocols evpn interconnect interconnected-vni-list] hiérarchie. Les équipements de passerelle des deux POD doivent utiliser le même VNI sur le WAN pour chaque VNI assemblé.
  3. Configurez l’assemblage VXLAN translationnel pour le VLAN 1 en liant le VLAN/VNI local à un VNI translationnel. Notez que la valeur du VNI de translation correspond au VNI que vous avez configuré au niveau de la protocols evpn interconnect interconnected-vni-list hiérarchie à l’étape précédente. Ainsi, les commandes suivantes vous permettent de mapper un VNI local à un VNI WAN.

    Pour l’assemblage VXLAN global, il suffit d’omettre l’instruction de traduction et de configurer le VLAN utilisateur pour qu’il utilise la même valeur VNI que celle que vous configurez au niveau de la [edit protocols evpn interconnect interconnected-vni-list] hiérarchie.

    Rappelons que les équipements leaf et spine de chaque pod sont déjà configurés pour l’architecture de référence CRB. Dans le cadre de la configuration préexistante, les VLAN sont définis sur les équipements de cur de réseau et de branche. La définition VLAN sur tous les équipements inclut un ID VLAN vers un mappage VNI VXLAN. Cependant, la configuration VLAN de la dorsale diffère de celle de la branche en ce sens qu’elle inclut l’interface IRB de couche 3, ce qui en fait à nouveau un exemple de CRB. La configuration existante pour le VLAN 1 est illustrée au niveau de l’équipement de passerelle 1 (spine 1) à titre de référence :

    Vous allez maintenant modifier la configuration du VLAN 1 sur l’équipement de passerelle 1 afin d’évoquer l’assemblage VXLAN translationnel. Le VNI que vous spécifiez correspond à l’une des valeurs VNI que vous avez configurées au niveau de la edit protocols evpn interconnect interconnected-vni-list hiérarchie à l’étape précédente. Par conséquent, l’équipement convertit le 100001 VNI (utilisé localement dans le POD 1 pour le VLAN 1) en 910001 VNI lorsqu’il l’envoie sur le WAN. Dans le POD distant, une configuration similaire relie le VNI WAN au VNI local associé au même VLAN dans le POD distant. En mode configuration, entrez la commande suivante :

  4. Configurez l’assemblage VXLAN translationnel pour le VLAN 2.

    Vous modifiez la configuration du VLAN 2 afin d’appeler l’assemblage VXLAN translationnel du 100002 VNI (utilisé localement dans le POD 1 pour le VLAN 2) vers le 910002 VNI sur le WAN.

  5. Confirmez le changement pour le VLAN 1. Nous omettons le VLAN 2 par souci de concision. La commande suivante affiche le passage au VLAN 1 en mode de configuration :
  6. Assurez-vous de valider vos modifications sur tous les périphériques de passerelle lorsque vous avez terminé.

Configurations d’équipement de passerelle pour l’assemblage VXLAN translationnel dans une instance de commutateur par défaut

Cette section fournit le delta de configuration pour les quatre périphériques de passerelle. Vous ajoutez ce delta à la ligne de base CRB que vous avez modifiée pour DCI sur le WAN. Une fois que vous avez étendu l’underlay et l’overlay, les configurations suivantes effectuent un assemblage VXLAN translationnel entre le VNI du POD local et le VNI sur le WAN.

Passerelle 1 (POD 1)

Passerelle 2 (Pod 1)

Passerelle 3 (POD 2)

Passerelle 4 (POD 2)

Vérifier l’assemblage VXLAN translationnel dans l’instance de commutateur par défaut

  1. Vérifiez que le LAG ESI entre les périphériques de passerelle est opérationnel et en mode actif-actif.

    La sortie indique qu’ESI 00 :00 :ff :ff :00 :11 :00 :00 :00 :01 est opérationnel. La sortie affiche également le transfert actif-actif (Mode la colonne affiche all-active) et les Designated forwarder Backup forwarder adresses des périphériques.

  2. Affichez les VTEP VXLAN distants pour confirmer que les équipements de passerelle distants sont répertoriés en tant que VTEP WAN.

    La sortie affiche correctement les deux passerelles distantes sous la forme Wan-VTEP.

  3. Affichez la base de données EVPN sur l’équipement de passerelle 1 pour VXLAN VNI 100001. Rappelez-vous que dans notre exemple, il s’agit du VNI que vous avez attribué au VLAN 1 sur les feuilles et les épines du CRB dans le POD 1.

    La sortie confirme que la valeur VNI 100001 associée au VLAN 1 est annoncée et utilisée dans le POD local.

  4. Affichez la base de données EVPN sur l’équipement de passerelle 1 pour VXLAN VNI 910001. Rappelons qu’il s’agit du VNI associé au VLAN 1 pour l’assemblage VXLAN translationnel sur le WAN.

    La sortie confirme que la valeur VNI 910001 associée au VLAN 1 est annoncée au POD distant. Cela confirme que le 910001 VNI est utilisé sur le WAN. Étant donné que le VNI local diffère du VNI utilisé sur le WAN, cela confirme l’assemblage VXLAN translationnel pour le cas d’utilisation d’instance de commutateur par défaut.

Interconnexion VXLAN dans une instance de routage MAC-VRF

Nous prenons en charge l’assemblage VXLAN global et translationnel dans les instances de routage MAC-VRF. Comme nous avons démontré l’assemblage de translation pour l’instance de commutateur par défaut précédente, pour le cas MAC-VRF, nous montrons l’assemblage VXLAN en mode global.

La couverture des instances de routage MAC-VRF dépasse le cadre du présent document. Encore une fois, nous supposons que vous disposez d’une structure CRB fonctionnelle avec des instances MAC-VRF configurées conformément à la ligne de base de référence. Pour plus d’informations sur la configuration de MAC-VRF, reportez-vous à la section Présentation du type d’instance de routage MAC-VRF et à un exemple de cas d’utilisation des services EVPN-VXLAN DC IP Fabric MAC VRF L2.

Pour garder l’accent sur la fonctionnalité d’assemblage VXLAN, nous appelons le delta pour l’ajout de l’assemblage VXLAN à un MAC-VRF existant. Comme pour l’instance de commutateur par défaut, nous appliquons la configuration d’assemblage uniquement aux périphériques de passerelle. Dans le cas de MAC-VRF, cependant, vous configurez le mappage VLAN vers VNI dans l’instance MAC-VRF, plutôt qu’au niveau de la [edit vlans] hiérarchie. Une autre différence dans le cas MAC-VRF est que vous configurez l’instruction dans l’instance de routage plutôt qu’au interconnected-vni-list niveau de la [edit protocols evpn interconnect interconnected-vni-list] hiérarchie.

L’objectif de cet exemple est d’effectuer un assemblage VXLAN global pour les VLAN 1201 et 1202, qui correspondent respectivement aux VNI VXLAN 401201 et 401201. Vous configurez le même mappage VLAN vers VNI dans les deux PODS. Vous pouvez utiliser l’assemblage en mode global, car les affectations VLAN à VNI se chevauchent dans les deux POD.

Vous ajoutez les commandes suivantes aux périphériques de passerelle pour l’instance MAC-VRF qui effectuera l’assemblage. La configuration définit le LAG ESI utilisé entre les passerelles locales et spécifie la liste des VNI interconnectés.

Vous avez besoin d’une configuration similaire sur tous les périphériques de passerelle. Comme précédemment, nous passons en revue les détails de configuration de l’appareil de la passerelle 1, puis fournissons le delta de configuration complet pour les autres passerelles.

L’exemple ci-dessous va configurer les VNI 401201 et 401202 pour l’assemblage VXLAN sur le segment WAN.

Note:

Lorsque vous configurez l’assemblage VXLAN dans un contexte MAC-VRF, vous devez inclure l’option set forwarding-options evpn-vxlan shared-tunnels sur tous les noeuds Leaf de la QFX5000 gamme de commutateurs exécutant Junos OS. Après avoir ajouté cette instruction, vous devez redémarrer le commutateur. Nous vous déconseillons d’utiliser l’instruction shared tunnels sur les nuds de passerelle de la gamme QFX10000 de commutateurs exécutant Junos OS avec assemblage VXLAN dans les instances de routage MAC-VRF.

Les tunnels partagés sont activés par défaut sur les périphériques exécutant Junos OS Evolved (qui prend en charge EVPN-VXLAN uniquement avec les configurations MAC-VRF).

Comme indiqué, une configuration complète de l’instance de routage MAC-VRF dépasse notre champ d’application. Le bloc de configuration ci-dessous utilise une instance MAC-VRF préexistante basée sur la conception de référence MAC-VRF. Nous montrons cet extrait de configuration pour mieux illustrer pourquoi il s’agit d’un exemple d’assemblage VXLAN en mode global (pour une instance MAC-VRF). L’exemple provient de l’équipement CRB spine 1, qui est également une passerelle dans notre exemple de topologie de passerelle réduite. Par souci de concision, nous ne montrons que la configuration du VLAN 1201.

Dans l’exemple ci-dessus, la définition MAC-VRF du VLAN 1201 spécifie le même VNI (401201) répertorié dans la [edit routing-instances MACVRF-mac-vrf-ep-t2-stchd-1 protocols evpn interconnect interconnected-vni-list] hiérarchie. Il en résulte une signification (globale) de bout en bout pour ce VNI.

Comme pour l’instance de commutateur par défaut, il est facile d’appeler l’assemblage VXLAN translationnel dans le contexte MAC-VRF.

Par exemple, pour passer d’un 300801 VNI local pour le VLAN 801 à un VNI WAN de 920001, il vous suffit de modifier la définition du VLAN dans l’instance MAC-VRF associée pour inclure l’instruction translation-vni 920001 .

En ajoutant l’instruction translation-vni 920001 à la configuration VLAN MAC-VRF, vous indiquez à l’équipement de passerelle de convertir le 300801 VNI local en 920001 VNI lors de l’envoi via le WAN.

Configurations d’équipement de passerelle pour l’assemblage VXLAN global avec MAC-VRF

Cette section fournit le delta de configuration pour que les quatre périphériques de passerelle prennent en charge l’assemblage VXLAN en mode global dans un contexte MAC-VRF. Vous ajoutez ce delta à la ligne de base CRB que vous avez modifiée pour DCI sur le WAN. Une fois que vous avez étendu la couche inférieure et la superposition, les configurations ci-dessous effectuent l’assemblage VXLAN global pour les VNI 401201 et 401202. Comme il s’agit d’un exemple de mode global, vous n’incluez pas l’instruction translation-vni . Les valeurs VLAN et VNI d’interconnexion sont identiques.

Passerelle 1 (POD 1)

Passerelle 2 (Pod 1)

Passerelle 3 (POD 2)

Passerelle 4 (POD 2)

Note:

Lorsque vous configurez l’assemblage VXLAN dans un contexte MAC-VRF, vous devez inclure l’option set forwarding-options evpn-vxlan shared-tunnels sur tous les noeuds Leaf de la gamme QFX5000 de commutateurs. Après avoir ajouté cette instruction, vous devez redémarrer le commutateur. Nous vous déconseillons de configurer l’instruction de tunnel partagé sur les nuds de passerelle de la gamme QFX10000 de commutateurs exécutant Junos OS avec assemblage VXLAN dans des instances de routage MAC-VRF.

Les tunnels partagés sont activés par défaut sur les périphériques exécutant Junos OS Evolved (qui prend en charge EVPN-VXLAN uniquement avec les configurations MAC-VRF).

Vérification de l’assemblage VXLAN global dans une instance MAC-VRF

  1. Vérifiez que le LAG ESI utilisé entre les périphériques de passerelle est opérationnel et en mode actif-actif pour le cas MAC-VRF.

    La sortie indique qu’ESI 00 :00 :ff :ff :00 :11 :00 :00 :00 :01 est opérationnel. Le transfert actif-actif est vérifié par le all-active mode et la présence d’un redirecteur désigné et d’un redirecteur de secours.

  2. Affichez les VTEP VXLAN distants pour confirmer que les équipements de passerelle distants sont répertoriés en tant que VTEP WAN.

    La sortie affiche correctement les deux passerelles distantes sous la forme d’un Wan-VTEPfichier .

  3. Affichez la base de données EVPN sur la passerelle 1 équipement pour VXLAN VNI 401201 pour les annonces sur le WAN. Dans notre exemple, il s’agit du VNI attribué au VLAN 1201 dans les deux POD. Comme il s’agit d’un exemple de CRB, vous avez défini le VLAN 1201 sur les équipements Spine et Leaf. Cependant, seuls les équipements de cur de réseau incluent les interfaces IRB de couche 3 dans leurs configurations VLAN.

    La sortie confirme que la valeur VNI 401201, associée au VLAN 1201 et à l’interface irb.1201, est annoncée au POD distant. Cela confirme que VNI 401201 est utilisé sur le WAN pour le VLAN 1201.

  4. Affichez la base de données EVPN sur le périphérique de passerelle 1 pour VXLAN VNI 401201 pour les annonces vers le POD local. Rappelez-vous qu’il s’agit du VNI associé au VLAN 1201 dans les deux POD. Il s’agit du même VNI que celui que vous avez utilisé dans la commande précédente pour afficher des annonces sur les passerelles distantes.

    La sortie indique que la 401201 VNI est annoncée sur le POD local. Cela confirme que VNI 401201 est utilisé localement. Étant donné que le même VNI est utilisé localement et sur le WAN, cela confirme l’assemblage VXLAN global dans un cas MAC-VRF.

Optimisation du trafic des machines virtuelles (VMTO) avec l’interconnexion VXLAN

Dans certains environnements, vous souhaiterez peut-être installer des routes d’hôte /32 ou /128 pour optimiser le trafic vers une machine virtuelle spécifique. Lorsque vous utilisez l’assemblage VXLAN, configurez les éléments suivants sur tous les nœuds de passerelle pour permettre l’installation des routes hôtes.

La première commande ajoute la prise en charge de l’itinéraire hôte à l’instance de commutateur par défaut. Le second ajoute la prise en charge de l’itinéraire hôte pour une instance MAC-VRF spécifique. Vous devez configurer les deux si vous utilisez un mélange de types d’instances.

Vérifier la prise en charge de l’itinéraire hôte

But

Vérifiez que les routes d’hôte /32 sont importées dans une table VRF de couche 3 lorsque vous utilisez l’instance de commutateur par défaut ou dans une table MAC-VRF lorsque vous utilisez MAC-VRF.

Action

Affichez la table de routage de l’instance de routage associée et recherchez les routes avec un préfixe binaire /32 (ou /128). Nous commençons par l’affichage d’une table VRF de couche 3 utilisée avec l’assemblage VXLAN, l’instance de commutateur par défaut :

Ensuite, nous affichons une table de routage d’instance MAC-VRF.