SUR CETTE PAGE
Comprendre l’interopérabilité EVPN-MPLS avec Junos Fusion Enterprise et MC-LAG
Vous pouvez utiliser Ethernet VPN (EVPN) pour étendre un réseau Junos Fusion Enterprise ou MC-LAG (Multichassis Link Aggregation Group) sur un réseau MPLS à un datacenter ou à un réseau de campus. Avec l’introduction de cette fonctionnalité, vous pouvez désormais interconnecter des campus et des centres de données dispersés pour former un seul pont virtuel de couche 2.
La figure 1 montre une topologie Junos Fusion Enterprise avec deux commutateurs EX9200 qui servent d’équipements d’agrégation (PE2 et PE3) vers lesquels les équipements satellites sont multihomés. Les deux équipements d’agrégation utilisent un lien interchâssis (ICL) et le protocole ICCP (Inter-Chassis Control Protocol) de MC-LAG pour connecter et maintenir la topologie de Junos Fusion Enterprise. PE1 dans l’environnement EVPN-MPLS interfonctionne avec PE2 et PE3 dans Junos Fusion Enterprise avec MC-LAG.
La figure 2 montre une topologie MC-LAG dans laquelle l’équipement de périphérie client (CE) CE1 est multihébergé en PE2 et PE3. PE2 et PE3 utilisent un ICL et le protocole ICCP de MC-LAG pour connecter et maintenir la topologie. PE1 dans l’environnement EVPN-MPLS interagit avec PE2 et PE3 dans l’environnement MC-LAG.
Tout au long de cette rubrique, les figures 1 et 2 servent de références pour illustrer divers scénarios et points.
Les cas d’utilisation illustrés dans les figures 1 et 2 nécessitent de configurer à la fois le multihébergement EVPN en mode actif-actif et MC-LAG sur PE2 et PE3. Les EVPN avec multihébergement actif-actif et MC-LAG ont leur propre logique de transfert pour gérer le trafic, en particulier le trafic de diffusion, d’unicast inconnu et de multicast (BUM). Parfois, la logique de transfert pour EVPN avec multihébergement actif-actif et MC-LAG se contredit et provoque des problèmes. Cette rubrique décrit les problèmes et la manière dont la fonctionnalité d’interopérabilité EVPN-MPLS les résout.
Outre les implémentations spécifiques à l’interconnectabilité EVPN-MPLS décrites dans cette rubrique, EVPN-MPLS, Junos Fusion Enterprise et MC-LAG offrent les mêmes fonctionnalités et fonctions que les fonctions autonomes, sauf dans les scénarios suivants :
-
Nous ne prenons pas en charge la fonctionnalité d’isolation centrale avec l’interopérabilité EVPN-MPLS active/active et MC-LAG actif/actif.
Avantages de l’utilisation d’EVPN-MPLS avec Junos Fusion Enterprise et MC-LAG
Utilisez EVPN-MPLS avec Junos Fusion Enterprise et MC-LAG pour interconnecter des campus et des centres de données dispersés afin de former un seul pont virtuel de couche 2.
Gestion du trafic BUM
Dans les cas d’utilisation illustrés à la figure 1 et à la figure 2, PE1, PE2 et PE3 sont des homologues EVPN, tandis que PE2 et PE3 sont des homologues MC-LAG. Les deux groupes d’homologues échangent des informations de contrôle et se transfèrent le trafic, ce qui pose des problèmes. Le Tableau 1 décrit les problèmes qui se posent et la manière dont nous les résolvons lors de l’implémentation de la fonctionnalité d’interopérabilité EVPN-MPLS.
|
Direction du trafic BUM |
Interfonctionnement EVPN avec Junos Fusion Enterprise et la logique MC-LAG |
Problème |
Approche d’implémentation de Juniper Networks |
|---|---|---|---|
|
Vers le nord (PE2 reçoit les paquets BUM d’une interface mono- ou bihoming connectée localement). |
PE2 inonde le paquet BUM comme suit :
|
Entre PE2 et PE3, il existe deux chemins de transfert BUM : le MC-LAG ICL et un chemin EVPN-MPLS. Le transfert multiple pa=++++ Il en résulte des duplications de paquets et des boucles. |
|
|
Vers le sud (PE1 transfère le paquet BUM à PE2 et PE3). |
PE2 et PE3 reçoivent tous deux une copie du paquet BUM et inondent le paquet de toutes leurs interfaces locales, y compris l’ICL. |
PE2 et PE3 transfèrent tous deux le paquet BUM hors de l’ICL, ce qui entraîne une duplication des paquets et des boucles. |
Horizon divisé
Dans les cas d’utilisation illustrés aux figures 1 et 2, l’horizon fractionné empêche le transfert de plusieurs copies d’un paquet BUM vers un équipement CE (satellite). Cependant, les implémentations EVPN-MPLS et MC-LAG Split Horizon se contredisent, ce qui pose problème. Le tableau 2 explique le problème et la manière dont Juniper Networks le résout en implémentant la fonctionnalité d’interopérabilité EVPN-MPLS.
|
Direction du trafic BUM |
Interfonctionnement EVPN avec Junos Fusion Enterprise et la logique MC-LAG |
Problème |
Approche d’implémentation de Juniper Networks |
|---|---|---|---|
|
Vers le nord (PE2 reçoit le paquet BUM d’une interface multihébergement connectée localement). |
|
La logique de transfert EVPN-MPLS et MC-LAG se contredit et peut empêcher le transfert du trafic BUM vers l’ES. |
Prise en charge du biais local, ignorant ainsi l’état DF et non-DF du port pour le trafic commuté localement. |
|
Vers le sud (PE1 transfère le paquet BUM à PE2 et PE3). |
Le trafic reçu de PE1 suit les règles de transfert DF et non-DF EVPN pour un ES multirésident. |
Aucune. |
Non applicable. |
Apprentissage MAC
L’EVPN et le MC-LAG utilisent la même méthode pour apprendre les adresses MAC, à savoir qu’un appareil PE apprend les adresses MAC de ses interfaces locales et synchronise les adresses avec ses pairs. Cependant, étant donné qu’EVPN et MC-LAG synchronisent les adresses, un problème survient.
Le Tableau 3 décrit le problème et la manière dont l’implémentation de l’interopérabilité EVPN-MPLS l’évite. Les cas d’usage illustrés à la figure 1 et à la figure 2 illustrent le problème. Dans les deux cas d’usage, PE1, PE2 et PE3 sont des homologues EVPN, tandis que PE2 et PE3 sont des homologues MC-LAG.
|
cas d’usage de la synchronisation MAC |
Interfonctionnement EVPN avec Junos Fusion Enterprise et la logique MC-LAG |
Problème |
Approche d’implémentation de Juniper Networks |
|---|---|---|---|
|
Adresses MAC apprises localement sur des interfaces monohoming ou bihoming sur PE2 et PE3. |
|
PE2 et PE3 fonctionnent à la fois comme des homologues EVPN et MC-LAG, ce qui permet à ces appareils d’avoir plusieurs chemins de synchronisation MAC. |
|
|
Adresses MAC apprises localement sur des interfaces monohoming ou bihoming sur PE1. |
Entre les homologues EVPN, les adresses MAC sont synchronisées à l’aide du plan de contrôle EVPN BGP. |
Aucune. |
Non applicable. |
Gestion de la liaison descendante entre les ports en cascade et de liaison montante dans Junos Fusion Enterprise
Cette section s’applique uniquement à l’interopérabilité EVPN-MPLS avec une solution Junos Fusion Enterprise.
Dans Junos Fusion Enterprise illustré à la Figure 1, supposons que l’équipement d’agrégation PE2 reçoit un paquet BUM de PE1 et que la liaison entre le port en cascade de PE2 et le port de liaison montante correspondant sur l’équipement satellite SD1 est interrompue. Que le paquet BUM soit traité par MC-LAG ou par multihébergement EVPN actif-actif, le résultat est le même : le paquet est transmis via l’interface ICL à PE3, qui le transmet à la solution SD1 à double hébergement.
Pour illustrer plus en détail comment EVPN avec multihébergement actif-actif gère cette situation avec un SD1 à multihébergement, supposons que l’interface DF réside sur PE2 et est associée à la liaison descendante et que l’interface non DF réside sur PE3. En règle générale, avec un EVPN avec une logique de transfert multihébergement actif-actif, l’interface non-DF abandonne le paquet. Cependant, en raison de la liaison descendante associée à l’interface DF, PE2 transfère le paquet BUM via l’ICL à PE3, et l’interface non-DF sur PE3 transfère le paquet à SD1.
Prise en charge des passerelles de couche 3
La fonctionnalité d’interopérabilité EVPN-MPLS prend en charge la fonctionnalité de passerelle de couche 3 suivante pour les domaines de pont étendus et les VLAN :
-
Interfaces IRB (Integrated Routing and Bridging) pour transférer le trafic entre les domaines de pont étendus ou les VLAN.
-
Passerelles de couche 3 par défaut pour transférer le trafic d’un serveur physique (bare metal) d’un domaine de pont étendu ou d’un VLAN vers un serveur physique ou une machine virtuelle d’un autre domaine de pont étendu ou d’un autre VLAN.
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.