Interconnexion du datacenter (DCI) / Passerelles EVPN distantes

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. Elle est souvent choisie car les équipes des datacenters peuvent la mettre en œuvre avec peu ou pas de coordination avec les groupes WAN ou 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 (étiqueté comme routeur externe) sur le même site, étendant ainsi les attributs EVPN à ladite passerelle. Cette solution crée un domaine de pannes par site, ce qui permet d’éviter que les défaillances n’affectent la convergence sur les sites distants et ne créent plusieurs domaines de pannes. Les tables de points de terminaison IP/MAC des sites distants sont traitées et conservées sur une passerelle de système générique (étiquetée comme routeur externe). Vous pouvez également mettre en œuvre la QoS et la sécurité du WAN, ainsi que les optimisations mises à disposition par la technologie de transport (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.

Routeur de bordure de système autonome (ASBR)

À l’aide de la fonctionnalité de passerelle EVPN distante d’Apstra, vous pouvez éventuellement spécifier que la passerelle EVPN distante est un équipement de périphérie WAN ASBR. Cet EVPN de bout en bout permet une encapsulation uniforme et supprime le besoin de GW dédié. Il est complexe sur le plan opérationnel, mais offre une plus grande évolutivité par rapport aux solutions « DCI utilisant une passerelle » et « Over the Top ».

Cas d’usage 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.
• Fournissez des extensions de domaine de couche 2 pour les réseaux L2VNI / virtuels.
• Étendez le domaine EVPN d’Apstra aux pods gérés par Apstra et d’Apstra aux pods non gérés.
• Pas de terminaison du trafic VXLAN sur les équipements de cœur de réseau : connectez des systèmes génériques externes (étiquetés comme routeurs externes) sur les équipements de cœur de réseau. Il s’agit de prendre en charge la connectivité externe IPv4 (underlay). Dans ce cas, les équipements de cœur de réseau n'ont pas besoin d'arrêter le trafic VXLAN, contrairement aux équipements de branche de bordure, lorsqu'ils sont connectés à des systèmes génériques externes (étiquetés comme routeurs externes). En résumé, cette utilisation permet d’échanger des routes IPv4 vers des VTEP distants (dans la zone de routage/VRF par défaut) et seule la 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 EVPN (Ethernet VPN) basés sur BGP de manière évolutive sur un réseau IP. L’objectif est de prendre en charge l’extension des sites EVPN sans avoir à recourir aux technologies d’interconnexion du datacenter (DCI) typiques telles que MPLS/VPLS, qui sont souvent difficiles à configurer, parfois propriétaires et probablement héritées par nature.

« Over the Top » est une solution simple qui ne nécessite qu’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. Dans le cas contraire, la durée de vie par défaut est réduite à 0 et les paquets sont ignorés et n'arrivent pas au routeur distant. Apstra restitue automatiquement la configuration nécessaire pour remédier à ces limitations.

Cette conception fusionne les domaines EVPN-VXLAN distincts et les tunnels VXLAN entre les sites. La fusion de domaines EVPN auparavant distincts dans différents sites offre l’avantage d’étendre les services de couche 2 et de couche 3 (VRF) entre les sites, mais permet également de transformer les sites en un seul domaine d’erreur. Ainsi, une défaillance dans un site se propage nécessairement. De plus, chaque fois que vous étendez la couche 2 sur le WAN entre deux sites, vous étendez également le domaine flood et, avec lui, tout le trafic diffusé sur vos liaisons WAN coûteuses. Pour l’instant, cette solution n’offre aucun filtrage ni 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 étendu (VRF) et des réseaux virtuels (VLAN/sous-réseaux définis en couche 2 et/ou couche 3) indépendamment sur chaque site. Vous devez mapper manuellement les VRF et les VN entre les sites (ce qui crée des frais administratifs).

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 pools IP différents pour éviter les erreurs de build. 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 la barrière à l’entrée la plus faible. Cependant, l’inconvénient est qu’il n’y a qu’un seul plan de contrôle EVPN et qu’une anomalie de routage sur un site affectera la convergence et l’accessibilité sur les autres sites. L’extension des domaines inondables de couche 2 implique également qu’une tempête diffusée dans un site s’étend à l’autre site.

Toute mise en œuvre d’une DCI nécessite une planification et une coordination minutieuses des ressources. L’ajout de nouveaux sites nécessite une augmentation exponentielle de cette planification et de cette coordination. Les bouclages VTEP dans l’underlay doivent faire l’objet d’une fuite. Les VNID doivent correspondre entre les sites et, dans certains cas, des RT supplémentaires doivent être importées. Cette question est abordée en détail plus loin dans ce document.

Extension du plan de données : couche 3

Les ID de réseau VXLAN (VNID) font partie de l’en-tête VXLAN qui identifie les tunnels VXLAN uniques, chacun d’entre eux é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 rejoignez essentiellement des tunnels VXLAN entre des sites. Les VNID doivent donc correspondre entre les sites.

Il est important de comprendre qu’un VNID particulier ne sera associé qu’à un seul VRF (ou zone de routage dans la terminologie Apstra). Les VNID existent au sein d’un VRF. Ils sont reliés à un VRF. Pour les services de couche 3, l’assemblage ou l’extension de chaque VNID s’effectue avec l’exportation et l’importation des 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. À l’inverse, les RT de la même valeur sont automatiquement importées au niveau de la passerelle EVPN (périphérie) entrant dans la fabric. Par conséquent, si vous coordonnez les VNID de couche 3 sur 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é (Exporter tout) 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 consiste à ajouter manuellement les RT de l’autre site.

Extension du plan de données : couche 2

Un réseau virtuel peut être un service de couche 2 pur (la passerelle anycast de couche 3 n’est pas instanciée). Il peut être local (VLAN sur les ports orientés serveur contenus dans un rack) ou VXLAN (sélectionnez les racks pour étendre le domaine de diffusion et d’inondation 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/adresses MAC de type 2) et les RT correspondants sont automatiquement importés. Toutefois, l’emplacement d’importation et d’exportation des RT n’est pas au niveau de la zone de routage, mais plutôt au niveau du réseau virtuel lui-même.

Extension du plan de contrôle : passerelle EVPN

Apstra utilise le concept de « passerelle EVPN ». Cet appareil peut théoriquement être un nœud de fabric leaf, spine ou superspine, ainsi qu’un équipement DCI. Les passerelles EVPN séparent la partie fabric du réseau qui interconnecte les sites et masquent les VTEP internes au site.

Dans Apstra, une passerelle EVPN est un appareil qui appartient à une fabric EVPN et qui réside à la périphérie d’une fabric EVPN également connectée à un réseau IP externe. Dans un blueprint EVPN d’Apstra, il s’agit toujours d’un équipement border-leaf. La passerelle EVPN d’un datacenter établit l’appairage BGP EVPN avec une ou plusieurs passerelles EVPN réciproques dans un autre datacenter. L'« autre » passerelle EVPN est la « passerelle EVPN distante » dans la terminologie Apstra. La passerelle EVPN locale est considérée comme l’un des équipements 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 est le commutateur border-leaf avec une ou plusieurs connexions de routage externes pour le trafic entrant et sortant de la fabric Clos EVPN.

Grâce à cette fonctionnalité, vous pouvez configurer une passerelle EVPN locale (toujours un commutateur géré par Apstra) pour qu’elle s’appaire à une passerelle non gérée par Apstra, ou même à une passerelle non Spine-équipement leaf, dans un autre datacenter. L’appairage BGP de la passerelle EVPN permet de transférer tous les attributs EVPN de l’intérieur d’un pod vers l’extérieur de celui-ci. Dans l’environnement Apstra, chaque blueprint représente un datacenter. Si au moins deux sites sont sous gestion Apstra, vous devez tout de même configurer chaque site pour qu’il pointe vers la ou les « passerelle(s) EVPN distante(s) » sur 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 futures versions, cette exigence sera supprimée.

Annonces de routes VTEP sous-jacentes

L’accessibilité de la sous-couche aux adresses IP VTEP, ou à un itinéraire récapitulatif équivalent, doit être établie réciproquement. Chaque site doit annoncer ces bouclages VTEP à partir de la zone de routage par défaut dans les annonces 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

PRUDENCE:

Par défaut, ESI MAC msb (octet le plus significatif) est défini sur 2 sur tous les blueprints. Pour éviter tout problème affectant le service, chaque blueprint Apstra connecté doit avoir un MSB unique. Avant de créer des passerelles, modifiez l’adresse MAC d’ESI msb en conséquence. (Vous pouvez laisser l’un d’entre 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 de BGP en général, L2VPN/EVPN AFI/SAFI en particulier. Pour établir une session BGP avec une passerelle EVPN, la connectivité IP, ainsi que la connectivité au port TCP 179 (l’IANA attribue les ports TCP BGP), doivent être disponibles.

Note:

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

1. Dans le blueprint, accédez à Staged > DCI > Over the Top ou External Gateways , puis cliquez sur Create Over the Top (Créer une passerelle Over the Top ou externe).
2. Dans la boîte de dialogue qui s’ouvre, renseignez les informations suivantes concernant la passerelle EVPN distante.

   Lorsque vous étendez des réseaux L2 entre des fabrics de centre de données, vous avez la possibilité d’échanger uniquement les préfixes de type de route EVPN RT-5 (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. Cela se traduit par 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 les équipements DCI.

3. Sélectionnez les nœuds de la passerelle locale. Il s’agit des appareils du blueprint qui seront configurés avec une passerelle EVPN locale. Vous pouvez sélectionner un ou plusieurs équipements à 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 disposant de connexions directes à des systèmes génériques externes (étiquetés comme routeurs externes).
4. Cliquez sur Create (Créer ) pour transférer la passerelle et revenir à la vue tabulaire.
5. Lorsque vous êtes prêt à déployer les équipements dans le blueprint, validez vos modifications.

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

Si vous configurez la ou les passerelles EVPN distantes sur 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 de > actives.

Zone de routage améliorée

Les stratégies d’import/export RT (route-cible) sur les équipements faisant partie du service étendu régissent l’installation du routage EVPN. Spécifiez les stratégies de route cible pour ajouter des routes cibles d’importation et d’exportation qu’Apstra utilise pour les zones de routage/VRF. Vous effectuez cette opération lorsque vous créez des zones de routage. Accédez à Staged > Virtual > Routing Zones (Zones de routage virtuel ) et cliquez sur Create Routing Zone (Créer une zone de routage). Pour plus d’informations, reportez-vous à la section Zones de routage.

Note:

La cible de routage par défaut générée pour les zones de routage est <VNI L3> :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 route 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 route par défaut générée par Apstra pour les réseaux virtuels est <VNI L2> :1. Vous ne pouvez pas changer cela.

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

Représentation topologique de la 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 vers les é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.)