Interconnexion des centres de données (DCI) / Passerelles EVPN distantes (virtuelles)

Excessif

DCI « Over the Top » est une solution transparente, ce qui signifie que les routes EVPN sont encapsulées dans l’IP standard et cachées du transport sous-jacent. Cela rend l’extension des services simple et flexible, et est souvent choisie parce que les équipes des centres de données peuvent la mettre en œuvre avec peu ou pas de coordination avec les groupes WAN ou de fournisseurs de services. Cela réduit les délais de mise en œuvre et les frictions internes à l’entreprise. Cependant, le compromis est l’évolutivité et la résilience.

Passerelle (GW)

En vous appuyant sur la fonctionnalité de passerelle EVPN distante d’Apstra, vous pouvez éventuellement spécifier que la passerelle EVPN distante est un système générique externe (marqué comme routeur externe) sur le même site, étendant ainsi les attributs EVPN audit portail. Cette solution crée un domaine d’erreur par site, ce qui empêche les défaillances d’affecter la convergence sur les sites distants et de créer plusieurs domaines d’erreur. Les tables de points de terminaison IP/MAC des sites distants sont traitées et conservées sur une passerelle système générique (étiquetée comme routeur externe). Vous pouvez également implémenter la QoS et la sécurité WAN, ainsi que les optimisations que la technologie de transport met à disposition (MPLS TE par exemple). Cependant, cette solution est plus complexe sur le plan opérationnel et nécessite du matériel et des coûts supplémentaires.

Système autonome Border Router (ASBR)

À l’aide de la fonctionnalité de passerelle EVPN distante d’Apstra, vous pouvez éventuellement spécifier que la passerelle EVPN distante est un périphérique de périphérie WAN ASBR. Cet EVPN de bout en bout permet une encapsulation uniforme et supprime l’exigence GW dédiée. Il est complexe sur le plan opérationnel mais présente une plus grande évolutivité que « DCI Using Gateway » et « Over the Top ».

Cas d’utilisation des passerelles EVPN

• Étendez les domaines d’isolation de couche 3 (VRF / zones de routage) à plusieurs pods gérés par Apstra (blueprints) ou étendez-les aux domaines EVPN distants.
• Fournir des extensions de domaine de couche 2 pour les réseaux L2VNI/virtuels.
• Aidez à étendre le domaine EVPN d’Apstra aux pods gérés par Apstra et Apstra aux pods non gérés.
• Pas de terminaison de trafic VXLAN sur les périphériques spine - connectez des systèmes génériques externes (étiquetés comme routeurs externes) sur les périphériques spine. Il s’agit de prendre en charge la connectivité externe IPv4 (sous-couche). Ici, les périphériques spine n’ont pas besoin de mettre fin au trafic VXLAN, contrairement aux périphériques border leaf, lorsqu’ils sont connectés à des systèmes génériques externes (étiquetés comme routeurs externes). En résumé, cela permet d’échanger des routes IPv4 vers des VTEP distants (dans la zone de routage par défaut/VRF) et seule une connectivité de couche 3 est requise :

Excessif

Lorsque l’appairage BGP EVPN est effectué « over the top », la passerelle de centre de données (DC-GW) est une fonction de transport IP pure et l’appairage BGP EVPN est établi entre les passerelles de différents centres de données.

Les sections suivantes décrivent les procédures d’interconnexion de deux ou plusieurs sites VPN Ethernet basé sur BGP (EVPN) de manière évolutive sur un réseau IP. La motivation est de prendre en charge l’extension des sites EVPN sans avoir à s’appuyer sur des technologies d’interconnexion de centres de données (DCI) typiques telles que MPLS/VPLS, qui sont souvent difficiles à configurer, parfois propriétaires et probablement de nature héritée.

« Over the Top » est une solution simple qui nécessite uniquement un routage IP entre les centres de données et une MTU ajustée pour prendre en charge l’encapsulation VXLAN entre les points de terminaison de passerelle. Dans une telle implémentation, les routes EVPN sont étendues de bout en bout via MP-BGP entre les sites. Le BGP multi-sauts est activé en supposant qu’il y aura plusieurs sauts de couche 3 entre les sites sur un WAN. Sinon, la durée de vie par défaut diminue à 0 et les paquets sont ignorés et n’arrivent pas au routeur distant. Apstra restitue automatiquement la configuration nécessaire pour répondre à ces limitations.

Cette conception fusionne les domaines EVPN-VXLAN et les tunnels VXLAN distincts entre les sites. La fusion de domaines EVPN auparavant distincts dans différents sites permet d’étendre les services de couche 2 et de couche 3 (VRF) entre les sites, mais rend également les sites comme un seul domaine d’erreur. Ainsi, une défaillance dans un site est nécessairement propagée. En outre, chaque fois que vous étendez la couche 2 sur le WAN entre les sites, vous étendez également le domaine d’inondation et, avec lui, tout le trafic de diffusion sur vos liaisons WAN coûteuses. Pour le moment, cette solution n’offre aucun filtrage ou QoS.

Note:

Lorsque des blueprints Apstra distincts gèrent des sites individuels (ou lorsqu’un seul site est géré par Apstra), vous devez créer et gérer des zones de routage étendues (VRF) et des réseaux virtuels (VLAN/sous-réseaux définis par la couche 2 et/ou la couche 3) indépendamment dans chaque site. Vous devez mapper manuellement les VRF et les VN entre les sites (ce qui crée une surcharge administrative).

Note:

Si vous configurez des connexions P2P entre deux centres de données (blueprints) dans le même contrôleur Apstra, chaque blueprint doit extraire des ressources de différents pools d’adresses IP pour éviter les erreurs de génération. Pour ce faire, créez deux pools d’adresses IP avec le même sous-réseau IP, mais avec des noms différents.

Cette solution « Over the Top » est la plus facile à déployer, ne nécessite aucun matériel supplémentaire et n’introduit aucune configuration WAN supplémentaire autre que l’augmentation du MTU. C’est le plus flexible et a la plus faible barrière à l’entrée. Cependant, l’inconvénient est qu’il n’y a qu’un seul plan de contrôle EVPN et qu’une anomalie de routage dans un site affectera la convergence et l’accessibilité dans l’autre ou les autres sites. L’extension des domaines inondables de couche 2 implique également qu’une tempête diffusée sur un site s’étend au(x) autre(s) site(s).

Toute mise en œuvre de DCI exige une planification et une coordination minutieuses des ressources. L’ajout de sites nécessite une augmentation exponentielle de cette planification et de cette coordination. Les bouclages VTEP dans la sous-couche doivent être divulgués. Les VNID doivent correspondre entre les sites et, dans certains cas, des cibles de routage (RT) supplémentaires doivent être importées. Cette question est traitée en détail plus loin dans le présent document.

Extension du plan de données : couche 3

Les ID réseau VXLAN (VNID) font partie de l’en-tête VXLAN qui identifie les tunnels VXLAN uniques, chacun étant isolé des autres tunnels VXLAN d’un réseau IP. Les paquets de couche 3 peuvent être encapsulés dans un paquet VXLAN ou les trames MAC de couche 2 peuvent être encapsulées directement dans un paquet VXLAN. Dans les deux cas, un VNID unique est associé au sous-réseau de couche 3 ou au domaine de couche 2. Lorsque vous étendez des services de couche 3 ou de couche 2 entre des sites, vous assemblez essentiellement des tunnels VXLAN entre des sites. Les VNID doivent donc correspondre entre les sites.

Il est important de comprendre qu’un VNID particulier sera associé à un seul VRF (ou zone de routage dans la terminologie Apstra). Les VNID existent dans un VRF. Ils sont liés à un VRF. Pour les services de couche 3, l’assemblage ou l’extension de chaque VNID s’effectue à l’aide de l’exportation et de l’importation de RT dans une zone de routage (VRF). Les sous-réseaux de couche 3 (routes) sont identifiés via des RT. Tous les VNID sont exportés automatiquement au niveau de la passerelle EVPN (périphérie) vers le WAN. Inversement, les RT de même valeur sont automatiquement importés au niveau de la passerelle EVPN (périphérie) entrant dans la structure. Par conséquent, si vous coordonnez les VNID de couche 3 d’un site pour qu’ils correspondent à l’autre, aucune configuration supplémentaire n’est nécessaire.

Dans l’image ci-dessus, aucune exportation ou importation supplémentaire n’est requise. Tout est automatiquement exporté (Export All) et comme les RT correspondent, ils sont automatiquement importés.

Toutefois, si un VNID dans DC1 est différent d’un VNID dans DC2, vous devez importer les RT respectivement. Chaque passerelle respective importe toujours automatiquement des RT de la même valeur. Dans l’exemple ci-dessous, une étape supplémentaire consistant à ajouter manuellement les thérapeutes de traduction à partir de l’autre site est requise.

Extension du plan de données : couche 2

Un réseau virtuel peut être un pur service de couche 2 (la passerelle anycast de couche 3 n’est pas instanciée). Il peut s’agir d’un rack local (VLAN sur les ports orientés serveur contenus dans un rack) ou VXLAN (sélectionnez les racks pour étendre le domaine d’inondation et de diffusion de couche 2 entre les racks. Ce domaine de couche 2 possède son propre VNID, et les trames MAC (par opposition aux paquets IP) sont encapsulées dans l’en-tête VXLAN avec le VNID du domaine de couche 2.

Les mêmes principes s’appliquent dans la mesure où tous les VNID sont exportés au niveau de la passerelle EVPN (dans ce cas, les routes de type 2/adresses MAC) et les RT correspondants sont automatiquement importés. Toutefois, l’emplacement de l’importation et de l’exportation des RT n’est pas au niveau de la zone de routage, mais au niveau du réseau virtuel lui-même.

Extension du plan de contrôle : passerelle EVPN

Apstra utilise le concept de « passerelle EVPN ». Ce périphérique peut théoriquement être un nœud de tissu de feuille, de colonne vertébrale ou super-dorsale, ainsi que le périphérique DCI. Les passerelles EVPN séparent le côté fabric du réseau qui interconnecte les sites et masque les VTEP internes au site.

Dans Apstra, une passerelle EVPN est un périphérique qui appartient et réside à la périphérie d’une structure EVPN, également connectée à un réseau IP externe. Dans un plan EVPN d’Apstra, il s’agit toujours d’un périphérique border-leaf. La passerelle EVPN d’un centre de données établit un appairage BGP EVPN avec une ou plusieurs passerelles EVPN réciproques dans un autre centre de données. L'« autre » passerelle EVPN est la « passerelle EVPN distante » dans la terminologie Apstra. La passerelle EVPN locale est supposée être l’un des périphériques gérés par Apstra dans le blueprint et est sélectionnée lors de la création de la « passerelle EVPN distante ». La passerelle EVPN locale sera le commutateur border-leaf avec une ou plusieurs connexions de routage externes pour le trafic entrant et sortant de la structure EVPN Clos.

Grâce à cette fonctionnalité, vous pouvez configurer une passerelle EVPN locale (toujours un commutateur géré par Apstra) pour qu’elle corresponde à un périphérique non géré par Apstra, voire non Spine-Leaf, dans un autre contrôleur de domaine. L’appairage BGP de la passerelle EVPN permet de transporter tous les attributs EVPN de l’intérieur d’un pod vers l’extérieur du pod. Dans l’environnement Apstra, chaque plan représente un centre de données. Si deux sites ou plus sont sous gestion Apstra, vous devez quand même configurer chaque site pour qu’il pointe vers la ou les « Passerelles EVPN distantes » dans d’autres sites. Nous vous recommandons de créer plusieurs passerelles EVPN redondantes pour chaque centre de données. Il existe également actuellement une exigence de maillage complet entre les passerelles EVPN, bien que dans les versions futures, cette exigence sera supprimée.

Annonces de routage VTEP sous-jacent

L’accessibilité sous-jacente aux adresses IP VTEP, ou une route récapitulative équivalente, doit être établie réciproquement. Chaque site doit publier ces bouclages VTEP depuis la zone de routage par défaut dans les publications de sous-couche BGP (IPv4) exportées. Les bouclages dans la stratégie de routage sont activés par défaut.

Créer des passerelles EVPN distantes

ATTENTION:

Par défaut, ESI MAC msb (octet le plus significatif) est défini sur 2 sur tous les blueprints. Chaque blueprint Apstra connecté doit avoir une interface MSB unique pour éviter tout problème impactant le service. Avant de créer des passerelles, modifiez ESI MAC msb en conséquence. (Vous pouvez laisser l’un d’eux à la valeur par défaut.)

La passerelle EVPN distante est une fonction logique que vous pouvez instancier n’importe où et sur n’importe quel appareil. Il nécessite la prise en charge BGP en général, L2VPN AFI/SAFI en particulier. Pour établir une session BGP avec une passerelle EVPN, la connectivité IP, ainsi que la connectivité au port TCP 179 (IANA alloue des ports TCP BGP), doivent être disponibles.

Note:

Pour plus de résilience, nous vous recommandons d’avoir au moins deux passerelles distantes pour le même domaine EVPN distant.

1. À partir du blueprint, accédez à Staged > Virtual > Remote EVPN Gateways (Passerelles EVPN distantes ) et cliquez sur Create Remote EVPN Gateway (Créer une passerelle EVPN distante).
2. Dans la boîte de dialogue qui s’ouvre, renseignez les informations suivantes pour la passerelle EVPN distante.

   Lorsque vous étendez des réseaux L2 entre des structures de centre de données, vous avez la possibilité (à partir d’Apstra version 4.1.0) d’échanger uniquement les préfixes RT-5 EVPN Route Type (modèle sans interface). Ceci est utile lorsqu’il n’est pas nécessaire d’échanger toutes les routes hôtes entre les emplacements des centres de données. Il en résulte des exigences moindres pour la base d’informations de routage (RIB), également connue sous le nom de table de routage, et la base d’informations de transfert (FIB), également connue sous le nom de table de transfert, sur l’équipement DCI.

3. Sélectionnez les nœuds de passerelle locale. Il s’agit des périphériques du blueprint qui seront configurés avec une passerelle EVPN locale. Vous pouvez sélectionner un ou plusieurs appareils à appairer avec la passerelle EVPN distante configurée. Vous pouvez utiliser la fonction de requête pour vous aider à localiser les nœuds appropriés. Nous vous recommandons d’utiliser plusieurs périphériques border-leaf qui ont des connexions directes à des systèmes génériques externes (étiquetés comme routeurs externes).
4. Cliquez sur Créer pour mettre en scène la passerelle et revenir à la vue table.
5. Lorsque vous êtes prêt à déployer les appareils du Blueprint, validez vos modifications.

Nous vous recommandons d’utiliser plusieurs passerelles EVPN distantes. Pour configurer des passerelles EVPN distantes supplémentaires, répétez les étapes ci-dessus.

Si vous configurez la ou les passerelles EVPN distantes vers un autre blueprint Apstra, vous devez configurer et déployer la ou les passerelles EVPN distantes séparément dans ce blueprint.

Une fois la modification déployée, Apstra surveille la session BGP pour les passerelles EVPN distantes. Pour afficher les anomalies du Blueprint, accédez à Anomalies > actives.

Zone de routage améliorée

Les stratégies d’importation/exportation RT (route-target) sur les appareils faisant partie du service étendu régissent l’installation de la route EVPN. Spécifiez des stratégies de cibles de routage pour ajouter des cibles de routage d’importation et d’exportation qu’Apstra utilise pour les zones de routage/VRF. C’est ce que vous faites lorsque vous créez des zones de routage. Accédez à Staged > Virtual > Routing Zones , puis cliquez sur Create Routing Zone. Pour plus d’informations, consultez Zones de routage.

Note:

La cible de routage par défaut générée pour les zones de routage est <L3 VNI> :1. Vous ne pouvez pas modifier cette valeur par défaut.

Pour confirmer que les routes correctes sont reçues au VTEP, assurez-vous que les L3VNI et la cible de routage sont identiques entre le blueprint et les domaines EVPN distants.

Réseaux virtuels améliorés

Vous pouvez ajouter des cibles de routage d’importation et d’exportation supplémentaires qu’Apstra utilise pour les réseaux virtuels.

Note:

La cible de routage par défaut générée par Apstra pour les réseaux virtuels est <L2 VNI> :1. Vous ne pouvez pas changer cela.

Pour la communication intra-VNI, le RT spécifique L2VNI est utilisé. Le RT d’importation est utilisé pour déterminer quelles routes reçues sont applicables à un VNI particulier. Pour établir la connectivité, les VNI de couche 2 doivent être les mêmes entre le blueprint et les domaines distants. Les sous-réseaux SVI doivent être identiques d’un domaine à l’autre.

Représentation de la topologie de passerelle distante

Les passerelles EVPN distantes sont représentées dans la vue topologique sous forme d’éléments cloud avec des connexions en pointillés aux éléments de blueprint avec lesquels les sessions BGP sont établies, comme illustré dans l’image ci-dessous. (L’image ci-dessous est légèrement différente des versions plus récentes.)