Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Fonctionnalité EVPN-over-VXLAN prise en charge

La fonctionnalité suivante est prise en charge pour l’encapsulation EVPN-over-VXLAN data plan :

VXLAN Encapsulation

EVPN prend en charge le type d’encapsulation de plan de données VXLAN au sein de la même instance EVPN. Pour prendre en charge le type d’encapsulation VXLAN, tous les périphériques EVPN PE spécifient le type de tunnel comme étant VXLAN dans la communauté étendue d’encapsulation BGP. Le PE entrant détermine les types d’encapsulation à utiliser en fonction de sa propre capacité d’encapsulation et de celle annoncée par son périphérique PE distant EVPN.

Lorsqu’EVPN est utilisé comme solution de superposition pour le réseau IP sous-jacent avec encapsulation VXLAN, le paquet de données est encapsulé avec un en-tête VXLAN au niveau du périphérique PE entrant, et le paquet de données est déencapsulé de l’en-tête VXLAN au niveau du périphérique PE de sortie. La figure 1 illustre le format des paquets lorsqu’un paquet est transféré dans le cœur via le réseau IP sous-jacent avec encapsulation VXLAN :

Figure 1 : réseau IP sous-jacent avec encapsulation VXLAN encapsulated packet structure showing outer Ethernet, IP, UDP headers, VXLAN header, and original Ethernet frame. VXLAN

Si le réseau sous-jacent utilise le protocole IPv4 et l’adressage IPv4, l’en-tête IP externe du paquet VXLAN est un en-tête IPv4. Toutes les plates-formes qui prennent en charge EVPN-VXLAN fonctionnent avec un réseau IPv4 underlay.

Sur certaines plateformes, vous pouvez configurer l’underlay pour utiliser le protocole IPv6 et l’adressage IPv6. Dans ce cas, l’en-tête IP externe du paquet VXLAN est un en-tête IPv6 et vous configurez l’adresse source VTEP en tant qu’adresse IPv6. Voir EVPN-VXLAN avec un underlay IPv6 pour plus de détails sur l’utilisation d’un underlay IPv6.

Routes et attributs EVPN BGP

Les routes et attributs EVPN BGP prennent en charge l’encapsulation EVPN-over-VXLAN data plane et sont affectés comme suit :

  • En attachant l’attribut de communauté étendue d’encapsulation BGP à tunnel type d’encapsulation VXLAN dans les routes MAC EVPN, le périphérique PE sortant annonce la route multicast inclusive EVPN et la découverte automatique EVPN par route EVI.

  • Les champs de balise Ethernet de toutes les routes EVPN BGP sont définis sur zéro pour prendre en charge le mode basé sur l’identifiant de réseau VXLAN (VNI) uniquement.

  • Le VNI, également appelé champ VNI dans la superposition EVPN, est placé dans les champs MPLS de la route MAC EVPN, de la route de multicast inclusive EVPN et de la route de découverte automatique par instance EVPN.

  • Le champ Étiquette d’identificateur de segment Ethernet est défini sur zéro pour la route de découverte automatique EVPN par segment Ethernet, car il n’existe pas d’étiquette d’identificateur de segment Ethernet pour le type d’encapsulation VXLAN pris en charge.

  • Toutes les routes EVPN correspondantes de l’appareil PE distant sont résolues sur la table inet.0 ou :vxlan.inet.0 au lieu de la table inet.3 pour IPv4. Lorsque vous utilisez un underlay IPv6 pour la tunnelisation EVPN-VXLAN, il en va de même pour les tables inet6.0 et :vxlan.inet6.0.

Procédure de multihébergement EVPN

Vous pouvez multiconnecter un serveur bare metal (BMS) à une paire de commutateurs top-of-rack (TOR) Juniper Networks, par exemple des commutateurs QFX5100, via une interface LAG (Link Aggregation Group) de couche 2. En raison de l’interface LAG, une seule copie du trafic BUM est transférée d’un BMS au routeur central. Pour empêcher une boucle de couche 2 et le flooding du trafic BUM vers le même segment Ethernet auquel le BMS multihomé est attaché, le trafic BUM applique la règle de filtrage à horizon partagé actif-actif multihoming. Pour prendre pleinement en charge la fonctionnalité de mode actif-actif multihébergement EVPN, le commutateur TOR de Juniper Networks annonce également la route de crénelage EVPN vers d’autres appareils EVPN PE.

L’absence de prise en charge des étiquettes MPLS pour EVPN sur IP avec encapsulation de plan de données VXLAN a un impact sur les fonctions suivantes du mode actif-actif multihébergement EVPN :

Remarque :

EVPN sur VXLAN ne prend pas en charge le mode de fonctionnement actif-veille. Vous pouvez configurer uniquement le mode actif-actif à l’aide de l’option all-active de configuration de l’interface ESI. Les segments Ethernet à hébergement unique avec EVPN utilisant l’encapsulation VXLAN avec l’option single-active ne sont pas pris en charge.

À partir de la version 22.2R1 de Junos OS, EVPN ajoute la redondance entièrement active, l’aliasing et la prise en charge du retrait MAC de masse, y compris l’intégration du plan de données VXLAN, pour fournir une connectivité résiliente entre les centres de données à ses technologies d’interconnexion du datacenter (DCI) établies. Cette nouvelle prise en charge permet de créer une solution DCI de bout en bout en intégrant le multicast EVPN au plan de données VXLAN.

Dans une topologie active-active, les deux liens sont utilisés pour équilibrer la charge du trafic. Le trafic unicast provenant du domaine EVPN-MPLS est équilibré en charge vers les deux passerelles et est transféré via le tunnel VXLAN vers le routeur final VXLAN distant. Les paquets à charge équilibrée peuvent provenir de l’une ou l’autre des passerelles et provoquer un problème de basculement MAC sur le routeur final VXLAN. Vous pouvez surmonter ce problème de bascule MAC en configurant une adresse IP anycast en tant qu’adresse secondaire sur les interfaces de bouclage des passerelles. Lorsque vous définissez l’adresse anycast sur , vxlan-source-iple tunnel VXLAN est créé à l’adresse anycast et le MAC est appris à partir de l’adresse anycast du VTEP.

Utilisez les instructions suivantes pour définir la redondance active-active au niveau ESI et une adresse anycast sur l’interface lo0. Ajoutez une adresse secondaire avec une adresse IP anycast à l’interface lo0 et incluez-la en tant qu’interface vxlan-source-ip VTEP dans l’instance de routage et le secondary-vtep-address PIM sous protocoles.

Biais local et règle de filtrage à horizon partagé

En raison de l’absence de l’étiquette MPLS, la règle de filtrage à horizon partagé pour le segment Ethernet multirésident est modifiée et basée sur l’adresse IP du périphérique EVPN PE au lieu de l’étiquette de segment Ethernet MPLS. Pour le trafic provenant de l’interface d’accès, tout transfert de trafic vers le segment Ethernet multirésident est basé sur le biais local pour EVPN avec encapsulation du plan de données VXLAN. Chaque appareil EVPN PE suit l’adresse IP de son appareil EVPN PE multihébergement homologue pour lequel il partage le même segment Ethernet. Ce suivi fournit l’adresse IP VTEP source (dans l’en-tête IP externe) pour chaque paquet VXLAN reçu de l’autre périphérique EVPN PE. La règle de filtrage à horizon partagé est appliquée aux équipements PE entrants et sortants pour le trafic multi-destinations :

  • Entrée PE : responsable du transfert des paquets multidestinations provenant de l’une de ses interfaces d’accès directement connectées vers les segments Ethernet multirésidents associés restants, quel que soit le statut choisi de redirecteur désigné (DF) de l’équipement PE entrant concerné.

  • Extress PE : ne permet pas le transfert de paquets multi-destinations vers le même segment Ethernet multirésident vers lequel un PE de sortie partage avec son équipement PE entrant, quel que soit le statut d’élection DF du périphérique PE sortant concerné.

Crénelage

Lorsque vous connectez un BMS à une paire de commutateurs TOR de Juniper Networks par le biais d’un bundle d’interfaces LAG, un seul des commutateurs peut apprendre l’adresse MAC locale. Pour prendre en charge la équilibrage de charge du trafic unicast connu provenant du VXLAN vers le BMS entre les commutateurs, l’équipement EVPN PE sur le commutateur doit annoncer EVPN pour chaque route de découverte automatique d’instance EVPN. Cette publicité signale aux périphériques EVPN PE distants que le MAC a appris du segment Ethernet multirésident à partir de son appareil PE multiconnecté pair est également accessible. Pour l’encapsulation VXLAN, la procédure EVPN n’est pas modifiée lors de la fourniture de la fonction d’aliasing EVPN.

Transfert de saut suivant

Le démon d’apprentissage d’adresses de couche 2 (l2ald) crée le prochain saut composite d’encapsulation VXLAN à l’entrée et le prochain saut composite de déencapsulation VXLAN à la sortie. L’encapsulation composite VXLAN next-hop transfère le trafic unicast de couche 2 vers le périphérique PE distant avec l’encapsulation VXLAN. Si plusieurs chemins sont disponibles pour atteindre un MAC distant (comme dans le cas EVPN multirésident actif-actif), le Routing Protocol Daemon (rpd) informe le l2ald de toutes les adresses IP VTEP distantes associées à l’MAC distant. Le l2ald est responsable de la création d’un saut suivant ECMP (Equal-Cost multichemin) pour l’adresse MAC distante. Le saut suivant composite de déencapsulation VXLAN déencapsule l’en-tête du tunnel VXLAN au niveau de la sortie, puis transfère le trafic au BMS.

Pour le trafic unicast connu :

  • À l’entrée, le rpd n’a pas besoin d’ajouter d’itinéraire d’étiquette dans la table mpls.0.

  • À la sortie, le rpd n’a pas besoin d’ajouter une route d’étiquette pour pointer vers le saut suivant de la table dans la table mpls.0.

Prévention des boucles IRB de superposition

Les itinéraires de tunnel VXLAN sont résolus dans l’underlay. La superposition utilise la résolution de route sous-jacente pour l’accessibilité. Dans certaines conditions, l’underlay peut utiliser l’overlay pour l’accessibilité, ce qui peut conduire à des boucles de routage.

Imaginons que vous configuriez à la fois un VXLAN et un IRB dans la même instance de routage, tandis que vous configurez également l’IRB dans le protocole OSPF ou via un routage statique. Vous pouvez configurer l’IRB explicitement à l’aide de l’option set protocols ospf area # interface irb ou de l’option set protocols ospf area # interface all« interface all » . Quelle que soit l’approche sous-jacente, l’overlay est utilisé pour résoudre le routage du tunnel.

Empêchez l’underlay de résoudre les routes à l’aide de l’overlay en configurant l’instruction overlay-vxlan-interfaces . Configurez ensuite une politique de routage, comme indiqué ici :

Examinez la table :vxlan.inet.0 pour vérifier que le système bloque les routes IRB. Tout d’abord, examinez un scénario dans lequel l’underlay peut utiliser des itinéraires superposés. La voie active utilise l’IRB :

Cette option prend en charge IPv4 et IPv6. Voici la table :vxlan.inet6.0 avec la route IRB :

Examinez la même sortie lorsque l’instruction overlay-vxlan-interfaces empêche l’ajout de la route IRB à la table. Les tableaux IPv4 et IPv6 sont présentés ici :

Méthode d’apprentissage MAC du plan de contrôle

L’une des caractéristiques uniques d’EVPN est que l’apprentissage des adresses MAC entre les équipements PE se produit dans le plan de contrôle. Le routeur PE local détecte une nouvelle adresse MAC à partir d’un équipement CE, puis, à l’aide de MP-BGP, annonce l’adresse à tous les équipements PE distants. Cette méthode diffère des solutions VPN de couche 2 existantes telles que VPLS, qui apprennent en inondant un unicast inconnu dans le plan de données. Cette méthode d’apprentissage MAC du plan de contrôle est un composant crucial des fonctionnalités et des avantages fournis par EVPN. L’apprentissage MAC étant géré dans le plan de contrôle, EVPN a la flexibilité nécessaire pour prendre en charge différentes technologies d’encapsulation de plan de données entre les équipements PE. Cette flexibilité est importante, car tous les dorsale ne fonctionnent pas MPLS, en particulier dans les réseaux d’entreprise.

Pour l’apprentissage MAC à distance du plan de contrôle, étant donné que l2ald crée le prochain saut composite d’encapsulation VXLAN et le prochain saut composite de déencapsulation VXLAN, le rpd ne crée plus de saut suivant indirect utilisé dans la table de transfert MAC. Le rpd s’appuie sur le mécanisme existant pour informer le l2ald des adresses MAC distantes apprises à partir du plan de contrôle. Au lieu d’informer le l2ald de l’ID VLAN et de l’index de saut suivant indirect utilisé par l’adresse MAC distante dans la table MAC FIB, le rpd informe l2ald de l’adresse IP du VTEP distant et de l’identifiant de réseau VXLAN. La route MAC apprise à distance du plan de contrôle pointe vers un prochain saut composite d’encapsulation VXLAN ou un prochain saut ECMP créé par l2ald dans la table de transfert MAC.

Pour l’EVPN multihébergement actif-actif, une paire d’adresses IP VTEP distantes est associée à l’adresse MAC distante. Les adresses IP des VTEP distants sont obtenues à partir de la route MAC reçue de l’équipement PE distant ou de la route de crénelage de l’équipement PE distant. Lorsqu’un équipement PE distant retire une route MAC ou la route de crénelage du segment Ethernet à partir duquel le MAC a appris, le rpd avertit le l2ald de la modification de la paire d’adresses IP VTEP distantes en conséquence. En conséquence, le l2ald met à jour le saut suivant uni-list construit pour ce MAC. Lorsque les routes MAC distantes et sa route de crénelage associée sont retirées ou ne sont pas résolues, le rpd informe le l2ald de la suppression de ce MAC distant et le l2ald retire ce MAC de la table de transfert MAC.

Les vRouters Contrail et la table L3-VRF

Le logiciel de virtualisation Contrail crée des réseaux virtuels (VN) associés à des routes dans une table L3-VRF (Layer 3 virtual routing and forwarding).

Les itinéraires associés sont les suivants :

Routes de sous-réseau pour une interface IRB

Pour chaque paire de tables MAC-(virtual routing and forwarding) VRF et L3-VRF créée pour un réseau virtuel sur un routeur MX Series, une interface IRB correspondante est associée à la paire de tables MAC-VRF et L3-VRF. La table L3-VRF du routeur MX Series contient la route de sous-réseau de l’interface IRB associée à ses réseaux virtuels locaux, ainsi que toutes les routes de sous-réseau des interfaces IRB associées à d’autres réseaux virtuels au sein d’un datacenter fourni par la fonctionnalité de fuite de routage de Junos OS. Les routeurs MX Series annoncent ces routes de sous-réseau via MP-BGP vers les nœuds de contrôle Contrail. Par conséquent, la table L3-VRF du vRouter Contrail contient le même ensemble de routes de sous-réseau pour les interfaces IRB dans sa FIB IP, et les routes de sous-réseau pointent leurs sauts suivants vers les routeurs MX Series.

Routes hôtes de machines virtuelles

Les vRouters de Contrail prennent en charge l’ARP de proxy et annoncent l’adresse IP avec la route MAC EVPN de sa machine virtuelle (VM). Pour les routeurs virtuels Contrail et les routeurs MX Series, la table L3-VRF d’un réseau virtuel contient toutes les routes hôtes des machines virtuelles qui résident dans le même réseau virtuel, ainsi que les routes de tous les autres réseaux virtuels. Le trafic entre les machines virtuelles et le réseau intravirtuel entre les machines virtuelles est transféré directement au niveau de la couche 3 entre les vRouters de Contrail.

Routes hôtes de serveurs bare metal

Un commutateur TOR de Juniper Networks, par exemple un commutateur QFX5100, n’annonce pas l’adresse IP avec la route MAC EVPN du serveur bare metal (BMS) auquel il est rattaché. En raison de l’annonce de route MAC EVPN par le commutateur, aucune route hôte BMS n’est installée dans la table L3-VRF sur les routeurs virtuels Contrail et les routeurs MX Series. Toutefois, les routes ARP des BMS sont installées dans le noyau du routeur MX Series si le routeur MX Series reçoit des réponses ARP des BMS.

Choix du transitaire désigné

Pour assurer un meilleur équilibre de charge et une topologie plus flexible, le choix du redirecteur désigné est déterminé en sélectionnant l’ID VLAN ou le ID de réseau VXLAN minimum pour chaque segment Ethernet au lieu de sélectionner en fonction de l’instance EVPN. La figure 2 montre un exemple de topologie d’élection de redirecteur désigné.

Figure 2 : Topologie Network topology with CE devices CE1 and CE2 linked to PE devices PE1, PE2, PE3. Each PE has VLANs configured: PE1 with 100, 101, 201; PE2 with 100, 101; PE3 with 201. CE1 and CE2 use ESIs ES1 and ES2 for redundancy and load balancing. Orange lines show designated links for traffic flow. d’élection du redirecteur désigné

La valeur d’identifiant de segment Ethernet configurée pour l’équipement CE (CE1) est égale à ES1 et est connecté aux équipements PE1 et PE2 avec les VLAN 100 et 101 configurés. Le routeur PE1 est choisi comme redirecteur désigné pour les deux VLAN.

La valeur d’identifiant de segment Ethernet configurée pour l’équipement CE (CE2) est égale à ES2 et est connecté aux équipements PE1 et PE3 avec le VLAN 201 configuré. Le routeur PE3 est choisi comme redirecteur désigné pour ce VLAN.

L’ID de balise Ethernet peut être l’un des suivants :

  • ID de VLAN (pour EVPN-MPLS)

  • ID de réseau VXLAN (pour EVPN-VXLAN)

Documentation connexe