Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Assistance EVPN de Juniper

Vue d’ensemble

La fonctionnalité multihébergement Junos EVPN ESI vous permet de connecter directement les serveurs finaux aux équipements de branche et de fournir une connectivité redondante via le multihébergement. Cette fonctionnalité n’est prise en charge que sur les LAG qui s’étendent sur deux équipements Leaf de la fabric. L’EVPN ESI supprime également le besoin de « peer-link » et facilite donc une conception leaf-spine propre.

Les blueprints utilisant le protocole de contrôle de superposition MP-EBGP EVPN peuvent utiliser des appareils Juniper Junos. Les racks avec redondance de paire leaf peuvent mettre en œuvre le multihébergement EVPN ESI.

Le multihébergement EVPN ESI permet de maintenir le service EVPN et le transfert du trafic vers et depuis le site multihébergement dans les cas suivants de défaillance du réseau et d’éviter le point de défaillance unique selon les scénarios ci-dessous :

  • Liaison défaillante entre l’un des équipements de branche et le périphérique serveur final
  • Défaillance d’un des équipements de branche
  • Convergence rapide sur le VTEP local en modifiant les contiguïtés des sauts suivants et en maintenant l’accessibilité de l’hôte final à travers plusieurs VTEP distants

Multihébergement EVPN Terminologie et concepts

La terminologie et les concepts suivants sont utilisés avec le multihébergement EVPN :

EVI : instance EVPN qui s’étend entre les équipements de branche composant l’EVPN. Il est représenté par l’identifiant de réseau virtuel (VNI). EVI est mappé à des réseaux virtuels (VN) de type VXLAN.

MAC-VRF : table VRF (Virtual Routing and Forwarding) destinée à héberger les adresses MAC sur le périphérique leaf VTEP (souvent appelée « table MAC »). Un distingueur de route unique et une cible VRF sont configurés par MAC-VRF.

Segment Ethernet (ES) : les liaisons Ethernet s’étendent d’un hôte final à plusieurs équipements leaf ToR et forment des ES. Il s’agit d’un ensemble de liens groupés.

Ethernet Segment Identifier (ESI) : représente chaque ES de manière unique sur le réseau. ESI n’est pris en charge que sur les LAG qui s’étendent sur deux équipements Leaf de la fabric.

ESI contribue à la redondance au niveau de l’hôte final dans un blueprint basé sur EVPN VXLAN. Les liaisons Ethernet de chaque branche ToR de Juniper connectée au serveur sont regroupées sous forme d’interface Ethernet agrégée. LACP est activé pour chaque interface Ethernet agrégée des appareils Juniper. Les interfaces multirésidents dans l’ES sont identifiées à l’aide de l’ESI.

ESI a certaines restrictions et exigences, comme indiqué ci-dessous :

  • Les équipements leaf ToR basés sur ESI ne peuvent pas avoir de liaisons homologues L2/L3, car le multihébergement EVPN élimine les liaisons homologues utilisées par MLAG/vPC.
  • Une liaison de deux interfaces physiques vers un seul leaf n’est pas prise en charge dans l’implémentation ESI ; assurez-vous que le serveur avec LAG dans ce type de rack s’étend sur deux équipements Leaf.
  • Les types de rack ESI et MLAG/vPC ne peuvent pas être mélangés dans un seul blueprint.
  • Les points de connectivité externes (ECP) L2 avec un type de rack basé sur ESI ne sont pas pris en charge. Seules les ECP L3 sont prises en charge.
  • Attribution de VN par leaf : il n’est pas possible d’avoir différents ensembles de VLAN parmi les équipements leaf individuels pour un canal de port basé sur ESI.
  • La connexion d’un serveur unique à une seule branche à l’aide d’une liaison de deux interfaces physiques ne peut pas utiliser d’ESI.
  • ESI n’est pris en charge que sur les LAG (canaux de port) et non directement sur les interfaces physiques. Cela n’a aucun impact fonctionnel, car les canaux de port locaux leaf pour les liaisons multi-homes sont générés automatiquement.
  • Seul le mode de redondance actif-actif ESI est pris en charge. Le mode actif-veille n’est pas pris en charge.
  • Le mode redondance actif-actif n’est pris en charge que pour Juniper multihébergement EVPN, où chaque branche ToR Juniper attachée à un ES est autorisée à transférer du trafic vers et depuis un VLAN donné.
  • Plus de deux équipements leaf dans un même segment ESI utilisant des types de rack basés sur ESI n’est pas pris en charge.
  • Le passage d’un rack ESI à un type de rack MLAG ou vice versa n’est pas pris en charge dans les opérations d’extension de fabric flexible (FFE).

Spécification de la topologie

Dans l’exemple ci-dessous, Leaf1 et Leaf2 font partie du même ES, et Leaf3 est le commutateur qui envoie du trafic vers le SE.

Le multihébergement EVPN de Juniper utilise cinq types de routes :

  • Type 1 - Route EAD (Ethernet Auto-Discovery)
  • Type 2 - Route d’annonce MAC
  • Type 3 - Inclusive Multicast Route
  • Type 4 - Routage de segments Ethernet
  • Type 5 - Route du préfixe IP

Les EVPN BGP fonctionnant sur les appareils Juniper utilisent :

  • Tapez 2 pour annoncer les informations MAC et IP (hôte)
  • Type 3 pour transporter des informations sur les VTEP
  • Tapez 5 pour annoncer les préfixes IP dans une information d’accessibilité de la couche réseau (NLRI).
Remarque :

Dans Junos, le type de route MAC/IP de type 2 ne contient pas de VNI ni ni de RT pour la partie IP de la route, il est dérivé du type de route de type 5 associé.

Les routes de type 1 sont utilisées pour la découverte automatique (A-D) par ES afin d’annoncer le mode multihébergement EVPN. Les équipements leaf ToR distants du réseau EVPN utilisent la fonctionnalité de type de route EVPN de type 1 pour apprendre les routes MAC EVPN de type 2 à partir d’autres équipements leaf. Dans cette route, le type ESI et l’ID de balise Ethernet sont considérés comme faisant partie du préfixe dans la NLRI. En cas de défaillance de liaison entre la branche ToR et le serveur final, le VTEP retire les routes de découverte automatique Ethernet (type 1) par ES. La valeur de la balise Ethernet multihébergement Juniper EVPN est définie sur l’ID de VLAN pour les types de routes ES/de découverte automatique.

Retrait en masse : utilisé pour une convergence rapide lors de scénarios de défaillance de liaison entre des équipements leaf vers le serveur final à l’aide de routes EAD/ES de type 1.

Choix DF - Utilisé pour empêcher le transfert des boucles et des doublons, car un seul commutateur est autorisé à décapsuler et à transférer le trafic pour un ES donné. Ethernet Segment Route est exporté et importé lorsque ESI est configuré localement dans le cadre du LAG. Le NLRI de type 4 est principalement utilisé pour les choix de redirecteur désigné (DF) et pour appliquer le filtrage Split Horizon.

Horizon fractionné : il est utilisé pour empêcher le transfert des boucles et des doublons pour le trafic de diffusion, de unicast inconnu et multicast (BUM). Seul le trafic BUM provenant d’un site distant est autorisé à être transféré vers un site local.

EVPN Services

Compatibilité VLAN EVPN

Junos peut prendre en charge trois services Ethernet : (1) VLAN-based, (2) VLAN Bundle ou (3) VLAN-Aware. La conception de référence du datacenter d’Apstra exploite nativement le modèle VLAN-Aware. Avec le service EVPN VLAN-Aware, chaque VLAN est directement mappé à sa propre instance EVPN (EVI). Le mappage entre le VLAN, le domaine de pont (BD) et l’instance EVPN (EVI) est de N :1:1. Par exemple, N VLAN sont mappés en une seule BD mappée en une seule EVI. Dans ce modèle, tous les ID de VLAN partagent le même EVI, comme indiqué ci-dessous :

Dans Junos services Ethernet compatibles VLAN ont une cible de route distincte pour chaque VLAN (ce qui est Juniper optimisation interne), de sorte que chaque VLAN a une étiquette pour imiter les implémentations basées sur VLAN.

Du point de vue du plan de contrôle, les routes MAC/IP EVPN (type 2) pour les services compatibles VLAN portent un ID de VLAN dans l’attribut ID de balise Ethernet utilisé pour lever l’ambiguïté des routes MAC reçues.

Du point de vue du plan de données, chaque VLAN est étiqueté avec son propre VNI qui est utilisé lors de la recherche de paquets pour le placer sur le bon domaine de pont (BD)/VLAN.

Créer un réseau EVPN

La création d’un réseau EVPN suit le même flux de travail que pour les autres réseaux.

  1. Créer/installer des agents de périphérique offbox pour tous les commutateurs. (Les agents onbox ne sont pas pris en charge sur Junos.)
  2. Confirmez que le catalogue global inclut des équipements logiques (conception > équipements logiques) qui répondent aux exigences de Juniper équipement ; Créez-les si nécessaire :
  3. Vérifiez que le catalogue global inclut des mappages d’interfaces (Design > Interface Maps) qui mappent les périphériques logiques aux profils d’équipements appropriés pour les périphériques Juniper ; créez-les si nécessaire.
  4. Créez un type de rack.
    • Pour les racks à un seul leaf, spécifiez le protocole de redondance Aucun dans la section Leaf .
    • Pour les racks à deux vantaux
      • Spécifiez le protocole de redondance ESI dans la section Leaf .
      • Lorsque vous spécifiez le serveur final dans la section Serveur , spécifiez le type de pièce jointe Dual-Homed vers les équipements leaf ToR basés sur ESI. Les EVPN utilisant des SE ont une option d’agrégation de liens. Sélectionnez le mode LAG LACP (actif)
  5. Créez un modèle basé sur une baie.
  6. Créez un système générique pour un routeur externe.
  7. Créez des pools de ressources pour les ASN, les adresses IP et les VNI.
  8. Créez un blueprint basé sur le modèle ESI, puis construisez la topologie de réseau basée sur EVPN pour les appareils Juniper en attribuant des ressources, des profils d’appareils et des ID d’appareils.

Rendu de la configuration

Modèle de référence

  • Sous-jacent : le sous-jacent de la fabric du datacenter est configuré en couche 3 à l’aide d’eBGP standard sur les interfaces physiques des appareils Juniper.
  • Superposition : la superposition est configurée eBGP sur lo0.0 l’adresse. EVPN VXLAN est utilisé comme protocole de superposition. Tous les équipements TdR sont activés avec un VN L2. La passerelle par défaut de chacun de ces réseaux virtuels L2 peut être hébergée sur des équipements leaf ToR connectés. Pour le trafic inter-VN, VXLAN routage est effectué dans la structure à l’aide de VNI L3 sur les équipements leaf de bordure, conformément à la conception standard.
  • VTEP VXLAN - Sur les équipements de branche Juniper, une adresse IP est lo0.0 affichée, qui est utilisée comme adresse VTEP. L’adresse IP du VTEP est utilisée pour établir le tunnel VXLAN.
  • LAG multihébergement EVPN : la valeur ESI unique et les ID système LACP sont utilisés par LAG EVPN. Les liens multirésidents sont configurés avec un ESI et un identificateur système LACP est spécifié pour chaque liaison. L’ESI est utilisé pour identifier les groupes LAG et éviter les boucles. Pour prendre en charge les fonctions actif/actif et le multihébergement pour les équipements Juniper Leaf, ils sont configurés avec le même paramètre LACP pour un ESI donné afin qu’ils apparaissent comme un seul système.

    Les adresses MAC ESI sont générées automatiquement en interne. Vous pouvez configurer la valeur de l’octet le plus significatif (msb) utilisé dans l’adresse MAC générée. Une nouvelle API de façade est ajoutée pour mettre à jour la valeur MSB. Un nouveau nœud est ajouté au modèle basé sur le rack qui contient la valeur MAC MSB. La valeur par défaut de cet octet est 2 et vous pouvez le remplacer par n’importe quel nombre pair jusqu’à 254. La mise à jour de cette valeur entraîne la régénération de tous les MAC ESI dans le blueprint. Ceci est exposé aux cas d’utilisation DCI où les ESI doivent être uniques sur plusieurs blueprints (fabrics IP).

  • L3VNI : L3VNI est rendu sous forme de zone de routage par VRF. Une fonctionnalité multilocataire est disponible pour garantir que les charges de travail restent séparées logiquement au sein d’une construction VN (overlay) à l’aide de la zone de routage.

  • Route Target (RT) pour les VNI L2/L3 : générée automatiquement pour les VNI L2/L3 au format VNI :1. Il y a 1 RT (à l’échelle de la fabric) par MAC-VRF (c’est-à-dire L3VNI). La valeur doit être la même sur tous les commutateurs participant à une EVI. Vous pouvez trouver le RT dans le blueprint en accédant à Planifié > Réseaux virtuels > Réseaux virtuels , puis en cliquant sur le nom du VN. RT est dans la section des paramètres.

  • Route Distinguisher (RD) pour les VNI L2/L3 : pour le modèle basé sur Junos VLAN-Aware, la RD correspond à chaque EVI (commutateur). Il n’y a pas de RD pour chaque VNI L2. RD n’existe que pour la zone de routage VRF au format {primary_loopback}:vlan_id.

  • Configuration du commutateur virtuel : dans la hiérarchie des options de commutation des appareils Juniper, le paramètre vtep-source-interface est affiché, puis l’adresse IP VTEP utilisée pour établir le tunnel VXLAN est spécifiée. L’accessibilité à l’interface de bouclage (par exemple, lo0.0) est fournie par l’underlay. Le RD définit ici le RD spécifique à l’EVI transporté par des routes de type 1, de type 2, de type 3. RD pour les options de commutation globales est fourni au format {loopback_id}:65534.

    Le RT définit ici le RT global hérité par les routes EVPN. Il est utilisé par les routes de type 1. Une valeur RT par défaut est affichée (100:100) pour les options de commutation globales sur tous les commutateurs.

  • MTU : valeurs MTU affichées pour les appareils Juniper :

    • Ports L2 : 9100
    • Ports L3 : 9216
    • Interfaces de routage et de pontage intégrés (IRB) : 9 000

  • Passerelle anycast : la même adresse IP sur les interfaces IRB de tous les équipements leaf est configurée et aucune passerelle virtuelle n’est définie. Chaque interface IRB qui participe au service L2 étendu a la même adresse IP/MAC configurée que ci-dessous :

Dans ce modèle, toutes les interfaces IRB de passerelle par défaut d’un sous-réseau overlay sont configurées avec la même adresse IP et la même adresse MAC. L’un des avantages de ce modèle est qu’une seule adresse IP est requise par sous-réseau pour l’adressage de l’interface IRB de la passerelle par défaut, ce qui simplifie la configuration de la passerelle sur les systèmes finaux.

Ici, l’adresse MAC de l’IRB est générée automatiquement.

Limites

Les limitations suivantes s’appliquent aux topologies multihébergement EVPN pour les appareils Juniper :

  • Seul le multihébergement bidirectionnel est pris en charge. Plus de deux équipements Leaf Juniper dans un groupe multirésident n’est pas pris en charge.
  • Juniper EVPN avec EVPN sur d’autres fournisseurs réseau dans le même blueprint n’est pas pris en charge.
  • Pas de prise en charge de la fabric IP pure.
  • Les fabrics IPv6 ne prennent pas en charge Junos.
  • Dans le multihébergement EVPN de Juniper, les points de connectivité externes (ECP) L3 vers des systèmes génériques sont pris en charge ; L2 ECP n’est pas pris en charge.
  • Le routage BGP des équipements de branche Junos vers des serveurs de couche 3 gérés par Apstra n’est pas pris en charge.

Voir aussi