Présentation du multihébergement EVPN
Introduction au multihébergement EVPN
Un VPN Ethernet (EVPN) comprend des périphériques de périphérie client (CE) qui sont connectés à des périphériques de périphérie du fournisseur (PE), qui forment la périphérie de l’infrastructure MPLS. Il peut s’agir d’un hôte, d’un routeur ou d’un commutateur. Les équipements PE fournissent une connectivité de pont virtuel de couche 2 entre les équipements CE. Il peut y avoir plusieurs EVPN dans le réseau du fournisseur. L’apprentissage entre les routeurs PE se produit dans le plan de contrôle à l’aide de BGP, contrairement au pontage traditionnel, où l’apprentissage a lieu dans le plan de données.
Dans les versions antérieures à la version 15.1 de Junos OS, la prise en charge de la fonctionnalité EVPN sur les routeurs MX Series était limitée aux routeurs utilisant des interfaces MPC et MIC uniquement. À partir de la version 15.1 de Junos OS, les routeurs MX Series utilisant des DPC peuvent être exploités pour assurer la prise en charge EVPN sur l’interface côté périphérique CE.
La prise en charge DPC d’EVPN présente les considérations suivantes :
Les DPC prennent en charge EVPN en mode de fonctionnement actif-veille, y compris les éléments suivants :
Instance EVPN (EVI)
Commutateur virtuel
Interfaces de routage et de pontage intégrées (IRB)
Les DPC destinés à fournir la prise en charge active de la veille EVPN doivent être la carte de ligne orientée vers l’équipement CE. Les appareils PE dans le domaine EVPN doivent être des interfaces MPC ou MIC.
La fonction de multihébergement EVPN vous permet de connecter un site client à deux équipements PE ou plus afin de fournir une connectivité redondante. Un dispositif CE peut être multihébergé sur différents périphériques PE ou sur le même périphérique PE. Un équipement PE redondant peut fournir un service réseau au site du client dès qu’une panne est détectée. Ainsi, le multihébergement EVPN permet de maintenir le service EVPN et le transfert du trafic vers et depuis le site multirésident en cas de défaillances réseau des types suivants :
Défaillance de la liaison entre un appareil PE et un appareil CE
Défaillance d’un appareil PE
Échec de l’accessibilité MPLS entre le périphérique PE local et un périphérique PE distant
La Figure 1 illustre comment un équipement CE peut être multihébergé sur deux routeurs PE. L’appareil CE 1 est multihébergé sur les routeurs PE 1 et PE 2. Le périphérique CE 2 dispose de deux chemins potentiels pour atteindre le périphérique CE 1 et, selon le mode de redondance du multihébergement, un seul chemin ou les deux chemins sont actifs à la fois. Le mode de fonctionnement multihébergement détermine également le ou les routeurs PE qui transfèrent le trafic vers l’équipement CE. Le routeur PE qui transfère le trafic vers le périphérique CE (également appelé redirecteur désigné) utilise des tunnels MPLS, LSP ou GRE pour transférer le trafic. Si une défaillance se produit sur ce chemin, un nouveau redirecteur désigné est choisi pour transférer le trafic vers l’équipement CE 1.
PE
Fonctionnalités multifonctions EVPN MPLS prises en charge par les commutateurs QFX10000
À partir de Junos OS 17.4R1, les commutateurs QFX10000 prennent en charge le multihébergement pour EVPN MPLS. Seul le multihébergement actif-actif est pris en charge. Les sous-fonctionnalités suivantes sont prises en charge :
Configuration ESI (seules la configuration manuelle de type 0 et les IFD (interfaces physiques) sont prises en charge)
Crénelage et route d’étiquettes
Route EVPN de type 4 (route de segment Ethernet)
Communautés étendues
Trafic BUM
Rôles d’élection de transitaire désigné (DF) : DF et BDF
QFX10000 commutateurs sur un cœur MPLS EVPN prennent uniquement en charge l’instance de routage du commutateur par défaut. Les instances EVPN (EVI) ne sont pas prises en charge.
Multihébergement MPLS EVPN sur les routeurs ACX5448
À partir de Junos OS version 19.4R1, les routeurs ACX5448 prennent en charge le multihébergement pour EVPN MPLS. Seul le multihébergement actif-actif est pris en charge. Pour activer le multihébergement actif-actif EVPN sur ACX5448 routeur, incluez l’instruction de evpn-mh-profile configuration au niveau de la hiérarchie [edit system packet-forwarding-options firewall-profile].
user@host# set system packet-forwarding-options firewall-profile ? Possible completions: default-profile Set the profile to support default services. evpn-mh-profile Set the profile to support evpn-mh
Après avoir modifié le profil et l’avoir validé, vous devez redémarrer le processus de gestion du châssis en exécutant la restart chassis-control commande CLI pour afficher le nouveau profil.
Un avertissement syslog s’affiche pour redémarrer le PFE.
Comprendre les concepts de multihébergement EVPN
La figure 2 illustre une topologie de réseau EVPN simple permettant de définir les concepts de multihébergement EVPN.
EVPN simple
Ethernet segment—Lorsqu’un périphérique CE est multihomé sur deux routeurs PE ou plus, l’ensemble de liaisons Ethernet constitue un segment Ethernet. Un segment Ethernet apparaît sous la forme d’un groupe d’agrégation de liens (LAG) vers le périphérique CE.
Les liaisons entre les routeurs PE1 et PE2 et l’appareil CE1 forment un segment Ethernet.
Dans le cas d’un multihoming actif-veille, les liaisons qui constituent un segment Ethernet forment un domaine de pont. Dans le multihoming actif-actif, un segment Ethernet apparaît en tant que LAG vers le périphérique CE.
ESI: un segment Ethernet doit avoir un identificateur unique différent de zéro, appelé identifiant de segment Ethernet (ESI). L’ESI est codé sous la forme d’un entier de 10 octets. Lors de la configuration manuelle d’une valeur ESI, l’octet le plus significatif, appelé octet de type, doit être 00. Lorsqu’un périphérique CE monohoming est connecté à un segment Ethernet, la valeur ESI entière est égale à zéro.
Le segment Ethernet de l’appareil multirésident CE1 a une valeur ESI de 00:11:22:33:44:55:66:77:88:99 attribuée. L’appareil à domicile unique CE2 a une valeur ESI de 0.
EVI: une instance EVPN (EVI) est une instance de routage et de transfert EVPN couvrant tous les routeurs PE participant à ce VPN. Une EVI est configurée sur les routeurs PE pour chaque client. Chaque EVI dispose d’un séparateur de route unique et d’une ou plusieurs cibles de route.
Une EVI est configurée sur les routeurs PE1, PE2 et PE3.
Ethernet tag: une balise Ethernet identifie un domaine de diffusion particulier, tel qu’un VLAN. Une instance EVPN est constituée d’un ou plusieurs domaines de diffusion. Les balises Ethernet sont attribuées aux domaines de diffusion d’une instance EVPN donnée par le fournisseur de cette instance EVPN. Chaque routeur PE de cette instance EVPN effectue un mappage entre les identifiants de domaine de diffusion compris par chacun de ses périphériques CE connectés et la balise Ethernet correspondante.
Ethernet segment route (EVPN Type 4 route): les routeurs PE connectés à un périphérique CE multirésident utilisent les messages de routage de segment Ethernet BGP pour découvrir que chacun des routeurs PE est connecté au même segment Ethernet. Les routeurs PE annoncent la route de segment Ethernet, qui se compose d’une communauté étendue d’importation ESI et ES.
Les routeurs PE1 et PE2 annoncent une route ES avec une communauté étendue ES-import (ainsi que d’autres communautés étendues comme la cible de route). Les routeurs PE construisent également un filtre basé sur une communauté étendue d’importation ES, ce qui fait que seuls ces routeurs PE importent la route ES et identifient qu’ils sont connectés au même segment Ethernet.
Extended community— Une communauté élargie est semblable à bien des égards à une communauté régulière. Les EVPN utilisent des communautés étendues, car la valeur communautaire standard de 4 octets n’offre pas suffisamment d’expansion et de flexibilité. Une communauté étendue est une valeur de 8 octets divisée en deux sections principales.
BUM traffic: ce type de trafic est envoyé vers plusieurs destinations, notamment le trafic de diffusion, le trafic unicast inconnu diffusé dans le segment Ethernet et le trafic multicast.
DF—Lorsqu’un périphérique CE est multihébergé sur deux routeurs PE ou plus, un ou tous les routeurs PE multirésidents sont utilisés pour atteindre le site client, en fonction du mode de fonctionnement du multihébergement. Le routeur PE qui assume le rôle principal de transfert du trafic BUM vers le périphérique CE est appelé le redirecteur désigné (DF).
BDF—Chaque routeur d’un ensemble d’autres routeurs PE annonçant l’itinéraire de découverte automatique par segment Ethernet pour le même ESI et servant de chemin d’accès de secours en cas de défaillance du DF est appelé un redirecteur désigné de secours (BDF). Un BDF est également appelé routeur non-DF.
DF election—Sur chaque segment Ethernet, les routeurs PE participent à une procédure appelée élection du redirecteur désigné pour sélectionner les routeurs DF et BDF PE.
Mode de fonctionnement du multihébergement EVPN
Les différents modes de fonctionnement du multihébergement EVPN sont les suivants :
Single (Unique) : lorsqu’un routeur PE est connecté à un site client de résidence unique, ce mode est actif. Le mode unique est le mode de fonctionnement par défaut et ne nécessite pas de valeurs de segment Ethernet pour être configurées.
Veille active : lorsqu’un seul routeur PE, parmi un groupe de routeurs PE connectés à un segment Ethernet, est autorisé à transférer du trafic vers et depuis ce segment Ethernet, le segment Ethernet est défini comme fonctionnant en mode de redondance actif-veille .
Pour configurer le mode veille-actif, incluez la valeur ESI et l’instruction
single-activesous le niveau hiérarchique[edit interfaces].Note:Nous ne prenons pas en charge le mode multihébergement de veille active sur les commutateurs QFX Series ou dans les configurations EVPN avec superpositions VXLAN. Par conséquent, si vous configurez l’option
single-activesur des commutateurs QFX Series ou dans des configurations EVPN-VXLAN, l’équipement ignore cet élément de configuration.Actif-actif : lorsque tous les routeurs PE connectés à un segment Ethernet sont autorisés à transférer du trafic vers et depuis le segment Ethernet, le segment Ethernet est défini comme fonctionnant en mode de redondance actif-actif .
Note:Sous Junos OS version 14.2 et antérieure, le commutateur EX9200 Series prend uniquement en charge le mode de fonctionnement actif-veille pour le multihébergement EVPN.
Note:À partir de Junos OS version 14.1x53-D30 pour les commutateurs QFX5100 et de Junos OS version 18.2R1 pour les commutateurs EX4600, ces commutateurs prennent en charge le mode de fonctionnement actif-actif pour le multihébergement EVPN. Dans ce scénario, les commutateurs QFX5100 et EX4600 fonctionnent comme des commutateurs top-of-rack (ToR) dans le datacenter pour les réseaux virtuels. La fonctionnalité de multihébergement actif-actif EVPN permet d’accéder aux serveurs bare metal connectés aux commutateurs top-of-rack.
Note:À partir de Junos OS version 14.1R4, 14.2, 15.1F6 et 16.1R1, Junos OS prend en charge le mode actif-actif pour le multihébergement EVPN sur les routeurs MX Series.
À partir des versions 16.1R4 et 16.2R2 de Junos OS, tous les commutateurs EX9200 prennent en charge le mode actif-actif pour le multihébergement EVPN.
À partir de Junos OS versions 17.4R1, les commutateurs QFX10000 prennent en charge le mode actif-actif pour le multihébergement EVPN.
Pour configurer le mode actif-actif, incluez la valeur ESI et l’instruction
all-activeau niveau de la[edit interfaces]hiérarchie.La Figure 3 montre une topologie de référence pour le multihébergement actif-actif EVPN. Le segment Ethernet ESI1 pour l’appareil CE2 est multihébergé sur les routeurs PE1, PE2 et PE3. Le segment Ethernet sur le périphérique CE peut être configuré en tant que groupe d’agrégation de liens (LAG) ou en tant que chemin ECMP. Les appareils CE1 et CE3 sont les appareils de périphérie client monohoming et ont une valeur ESI de 0.
actif-actif
Implémentation du multihébergement EVPN
Le mode de fonctionnement du multihébergement de secours actif EVPN fournit une redondance en cas de défaillance de liaison d’accès et de défaillance de nœud PE pour le périphérique CE multirésident, et est basé sur le projet EVPN-ietf-l2vpn-evpn-03.
L’implémentation Junos OS des modes de fonctionnement multihébergement EVPN actif-veille et actif-actif comprend les éléments suivants :
- Nouveaux NLRI BGP
- Nouvelles communautés étendues
- Nouveaux types de routes EVPN
- Annonce de routes d’adresses MAC et IP de proxy multirésidents
- Mise à jour de la table de transfert MAC
- Circulation
- Crénelage
- Multihébergement actif-actif EVPN et agrégation de liens multichâssis
- Multihébergement actif-actif EVPN et IRB
- Exemple de configuration
Nouveaux NLRI BGP
Pour prendre en charge le multihébergement EVPN, les nouvelles routes NLRI (Network Layer Reachability Information) BGP suivantes ont été introduites :
Route de découverte automatique par segment Ethernet
Fonctionnalités de l’itinéraire de découverte automatique
Les fonctionnalités NLRI de la route d’autodiscovery sont les suivantes :
Il s’agit d’une route obligatoire de type 1, utilisée pour la convergence rapide et pour la publicité de l’étiquette d’horizon divisé. Elle est également connue sous le nom de voie de retrait de masse.
Les distingueurs de route de type 1 sont utilisés avec l’adresse IP (bouclage) du routeur PE d’origine comme valeur de distinction de route.
Cette route porte l’ESI dans le NLRI (différent de zéro lorsqu’il s’agit d’un PE multirésident, zéro sinon).
L’étiquette d’horizon fractionné est réservée à ESI et comporte une valeur NULL explicite (0).
Le bit dans le champ de l’indicateur de veille active dans la communauté étendue de l’étiquette ESI est utilisé pour signaler le mode de veille active (bit set).
Les valeurs d’étiquette sur 3 octets dans le NLRI et la balise Ethernet sont nulles.
Cette route est annoncée et importée par tous les routeurs PE multirésidents et distants qui partagent la même EVI sur l’ESI publicitaire.
Annonce d’itinéraire de découverte automatique
Mode veille active
En mode veille active, le redirecteur désigné (DF) annonce l’itinéraire de découverte automatique par segment Ethernet avec une communauté étendue d’étiquettes MPLS ESI dont le bit de veille est défini sur 1. L’itinéraire de découverte automatique est annoncé par ESI et l’étiquette ESI est définie sur 0 lorsque le mode de veille active est activé.
La route de découverte automatique est importée par tous les routeurs PE multirésidents et distants qui font partie de l’EVI. À la réception de la route de découverte automatique, les routeurs PE de la topologie du réseau apprennent que le mode de multihébergement actif-veille est activé pour l’ESI annoncé.
Mode actif-actif
En mode actif-actif, chaque périphérique PE multihoming annonce une route de découverte automatique obligatoire par segment Ethernet comme dans l’état actif-veille. Toutefois, à l’état actif-actif, l’itinéraire de découverte automatique par segment Ethernet est modifié de telle sorte que le bit actif-veille transporté dans la communauté MPLS étendue soit effacé pour indiquer que le mode actif-actif est en fonctionnement. La route d’autodiscovery par segment Ethernet en mode actif-actif inclut également l’étiquette d’horizon fractionné.
Sur la Figure 3, pour le segment Ethernet ESI1, les routeurs PE1, PE2 et PE3 annoncent la route de découverte automatique. Le routeur PE4 reçoit cette route de découverte automatique.
Retrait d’une route de découverte automatique
L’itinéraire de découverte automatique par retrait de segment Ethernet peut entraîner un retrait massif. La fonction de retrait de masse est utilisée en cas de défaillance d’une liaison sur l’ESI ou lorsque la configuration de l’ESI change.
Lorsque la liaison entre un périphérique CE multihoming et un périphérique PE multihoming échoue, le périphérique PE retire l’itinéraire de découverte automatique par segment Ethernet. Dans ce cas, la fonction de retrait de masse est gérée de la manière suivante par les autres appareils PE :
Dispositif PE à distance
Lorsqu’un périphérique PE distant reçoit la mise à jour BGP pour un retrait en masse, les opérations suivantes sont effectuées au niveau du périphérique PE distant :
Le saut suivant en cours pour atteindre l’équipement ESI ou CE distant est supprimé.
Un nouveau saut suivant entre les périphériques PE multirésidents restants est créé pour atteindre l’équipement ESI ou CE distant.
Toutes les routes MAC derrière le périphérique CE sont mises à jour avec le saut suivant nouvellement créé.
À partir de la version 17.4R1 de Junos OS, Junos OS prend en charge les sauts suivants de liste dynamique dans un réseau EVPN. Désormais, lorsque la liaison entre l’appareil CE et un appareil PE multidomestique échoue, le saut suivant vers l’ESI ou le CE est mis à jour, ce qui réduit le besoin d’un retrait massif. Pour plus d’informations sur l’activation du saut suivant de la liste dynamique, reportez-vous à la section Configuration du saut suivant de la liste dynamique.
Autre appareil PE multihoming
En raison du retrait de masse, l’équilibrage de charge sur le périphérique CE multirésident se produit pour les raisons suivantes :
Lorsque les autres périphériques PE multirésidents reçoivent le même ensemble d’adresses MAC sur la liaison vers l’ESI concerné.
Dans ce cas, les itinéraires locaux sont privilégiés. Si les routes distantes apprises à partir de l’équipement DF PE sont retirées, cela n’affecte pas les routes pointant vers l’ESI local.
Lorsque les autres périphériques PE multirésidents n’ont pas reçu le même ensemble d’adresses MAC sur la liaison vers l’ESI concerné.
Dans ce cas, les périphériques PE installent les routes MAC pointant vers l’ESI concerné, bien que les MAC soient appris à distance à partir du périphérique DF PE. Lorsque l’appareil DF PE retire ces itinéraires, les itinéraires retirés sont villés. Les paquets destinés aux adresses MAC vidées sont inondés sur tous les segments locaux.
Ethernet Segment Route
Fonctionnalités d’Ethernet Segment Route
Les fonctionnalités NLRI de la route de segment Ethernet comprennent :
Il s’agit d’une route EVPN de type 4. Le but de cette route est de permettre aux routeurs PE connectés au même segment Ethernet de se découvrir automatiquement les uns les autres avec une configuration minimale lors de l’échange de cette route.
Cette route est associée à une communauté étendue ES-import avec une valeur ESI condensée à 6 octets, similaire à une cible de route.
Cette route est annoncée et importée uniquement par les routeurs PE multirésidents sur le segment Ethernet publicitaire.
Annonce d’une route de segment Ethernet
L’itinéraire de segment Ethernet est échangé entre tous les routeurs PE d’un datacenter avec la communauté étendue ES-import. La communauté étendue ES-import est construite sur la base des routeurs PE ESI multirésidents, et la route de segment Ethernet porte la valeur ESI associée au segment Ethernet sur lequel les routeurs PE sont multirésidents.
Les routes de segment Ethernet sont filtrées en fonction de la communauté étendue ES-import, de sorte que seuls les routeurs PE multirésidents sur le même segment Ethernet importent cette route. Chaque routeur PE connecté à un segment Ethernet particulier construit une règle de filtrage d’importation pour importer une route qui transporte la communauté étendue ES-import.
Route de découverte automatique par instance EVPN
En mode actif-actif, chacun des périphériques PE multirésidents annonce une route de découverte automatique par instance EVPN (EVI) avec une étiquette MPLS valide. Cet itinéraire est annoncé par ESI et est importé par les périphériques PE distants. L’étiquette MPLS incluse dans l’itinéraire de découverte automatique par EVI est utilisée ultérieurement pour le crénelage.
Nouvelles communautés étendues
Une communauté étendue est similaire à bien des égards à une communauté régulière. Certaines implémentations de mise en réseau, telles que les réseaux privés virtuels (VPN), utilisent des communautés étendues, car la valeur communautaire standard de 4 octets n’offre pas suffisamment d’expansion et de flexibilité. Une communauté étendue est une valeur de 8 octets divisée en deux sections principales.
Pour prendre en charge le multihébergement en veille active, les communautés étendues suivantes ont été introduites :
ESI-Import
Cette communauté étendue est attachée à la route ES et est renseignée à partir de la valeur ESI-import extraite de la valeur ESI configurée sous l’interface. Pour résoudre le problème d’un conflit avec une autre cible de route régulière, le type est défini sur 0x06, qui a été alloué par IANA.
La cible de route de communauté étendue ESI-import remplit la liste des cibles de route d’importation configurées pour l’instance spéciale à partir de laquelle la route ES utilisant cette communauté est annoncée.
Par conséquent, les routes ESI entrantes avec la même valeur ESI-import dans la communauté étendue sont importées par les routeurs PE, si le routeur PE est configuré avec un segment Ethernet ayant la même valeur ESI. Une fois que le routeur PE reçoit un ensemble de ces routes ESI qui ont la même valeur de communauté étendue d’importation ESI, l’élection DF et BDF peut être effectuée localement.
Lorsque la communauté étendue ESI-import n’est pas créée implicitement, une stratégie doit être configurée pour attacher toutes les cibles de route à la route de découverte automatique par segment Ethernet.
Split Horizon
En référence à la Figure 3 , par exemple, lorsqu’un périphérique CE qui est multirésident vers deux périphériques PE ou plus sur un segment Ethernet (ESI1) et fonctionne en mode de redondance actif-actif envoie un paquet BUM à l’un des périphériques PE non-DF (disons PE1), le périphérique PE1 transfère ce paquet à tous les autres périphériques PE ou à un sous-ensemble des autres périphériques PE de cette instance EVPN, y compris le périphérique DF PE pour ce segment Ethernet. Dans ce cas, le périphérique DF PE vers lequel le périphérique CE est multihébergé abandonne le paquet sans le retransférer à l’équipement CE. C’est ce que l’on appelle l’horizon divisé.
Signalisation d’horizon divisé
La communauté étendue Split Horizon est rattachée à la route de découverte automatique par segment Ethernet. La valeur de la communauté étendue est l’horizon fractionné ou l’étiquette de Poisson elle-même, qui est de 3 octets, et est annoncée comme un attribut opaque.
Annonce Split horizon
En mode veille-actif, le bit de veille dans la communauté étendue Split Horizon est défini sur 1 et l’étiquette ESI Split Horizon est définie sur 0.
En mode actif-actif, la communauté étendue Split Horizon est modifiée pour effacer le bit de veille à 0 et inclut une étiquette ESI valide utilisée à des fins d’horizon fractionné.
Routes MPLS à horizon fractionné
L’équipement DF PE annonce une route de découverte automatique par segment Ethernet avec une étiquette d’horizon divisé A, et une route de multidiffusion inclusive avec une étiquette B pour le transfert de trafic BUM. Sur le DF, le paquet BUM du cœur peut porter les étiquettes suivantes :
Lorsque les équipements PE non-DF reçoivent un paquet BUM sur leurs ESI à hébergement unique, le paquet BUM est envoyé au périphérique DF PE avec l’étiquette multicast B.
Lorsque les périphériques non-DF PE reçoivent un paquet BUM sur ESI1, le paquet BUM est envoyé au périphérique DF PE avec deux étiquettes MPLS : l’étiquette multicast B en tant qu’étiquette externe et l’étiquette Split Horizon A en tant qu’étiquette interne.
Dans le scénario de multihébergement EVPN, le bit S de l’étiquette multicast B est défini sur 1 lorsqu’il s’agit de la seule étiquette de la pile d’étiquettes. Dans ce cas, le paquet BUM doit être inondé sur tous les ESI locaux de l’équipement DF PE. Mais l’étiquette B a le bit S défini sur 0 lorsque l’étiquette A de l’horizon fractionné est l’étiquette la plus interne de la pile d’étiquettes. Dans ce cas, les paquets BUM doivent être inondés sur tous les ESI locaux du périphérique DF PE, à l’exception de l’ESI qui correspond à l’étiquette d’horizon fractionné A.
En supposant que les paquets proviennent d’un périphérique CE multirésident vers un périphérique PE non-DF sur le segment multihoming ESI1, lorsque le périphérique PE non-DF envoie ce paquet au périphérique DF PE, l’étiquette ESI que le DF a annoncée au périphérique PE non-DF dans sa route de découverte automatique par segment Ethernet est envoyée en premier. Le périphérique PE non-DF envoie également l’étiquette de multicast inclusif annoncée par le périphérique DF PE dans sa route de multicast inclusif et pousse davantage l’étiquette LSP. L’en-tête MPLS contient donc deux étiquettes à l’intérieur d’un champ de 32 bits.
La fonctionnalité EVPN de base utilise un saut de table suivante pour relier la table MPLS à la table EVI EVPN correspondante. Dans la table EVI EVPN, la recherche mac est effectuée pour basculer le paquet.
Les routes suivantes sont programmées dans la table mpls.0 pour le multicast EVPN :
La route (multicast-label, S=1) pointe vers le saut EVPN-EVI table-next.
Le routage (multicast-label, S=0) pointe vers le saut suivant de la table MPLS. Cette route boucle le paquet vers la table MPLS après l’apparition de l’étiquette multicast.
La route (split horizon-label) pointe vers le saut suivant de la table EVPN-EVI. Il s’agit du même saut de table suivant que celui utilisé par la route multicast label, S=1.
Nouveaux types de routes EVPN
Le mode de multihébergement EVPN prend en charge les types de route EVPN suivants :
Route de découverte automatique par segment Ethernet
Route de découverte automatique par instance EVPN (EVI)
Route de segment Ethernet
Ces types de routes sont conformes à la convention de nommage suivante :
<route-type>:<RD>::<esi>::<route-specific>/304
Par exemple:
Route d’autodiscovery par segment Ethernet—
1:10.255.0.2:0::112233445566778899::0/304Route de découverte automatique par EVI—
1:100.100.100.1:1::22222222222222222222::0/304Route de segment Ethernet—
4:10.255.0.1:0::112233445566778899:10.255.0.1/304
où:
route-type: type de route EVPN.1 : route de découverte automatique par segment Ethernet.
1 : route de découverte automatique par EVI.
4 : routage de segments Ethernet.
5 : routage avec encapsulation VXLAN/MPLS
RD: valeur de distinction de route.La valeur du séparateur de route est définie sur l’adresse IP du routeur PE, suivie de 0.
esi: identificateur de segment Ethernet. Affiché sous la forme de 10 octets hexadécimaux, et les 00 octets non significatifs ne sont pas affichés.route-specific: diffère selon le type de routage.Route de découverte automatique par segment Ethernet et route de découverte automatique par EVI : cette valeur est une étiquette MPLS.
Note:L’étiquette MPLS est affichée dans la sortie étendue, bien qu’elle ne soit pas incluse dans le préfixe.
Ethernet segment route : cette valeur correspond à l’adresse IP d’origine.
304: nombre maximal de bits dans un routage EVPN. Ce n’est pas une information très utile et pourrait être supprimée de l’affichage. Cependant, il peut être utile pour identifier rapidement une route EVPN, que ce soit visuellement ou avec des opérateurs de correspondance.
Annonce de routes d’adresses MAC et IP de proxy multirésidents
À partir de la version 18.4R1 de Junos OS, Junos envoie une annonce de routage d’adresse MAC et IP proxy des PE multirésidents vers un périphérique CE. Junos utilise un indicateur de proxy dans la communauté étendue des attributs de couche 2 EVPN pour identifier le message en tant qu’annonce d’adresse MAC et IP proxy. Un PE qui apprend l’existence d’une adresse MAC et d’une adresse IP envoie une annonce de route EVPN normale de type 2 (adresse MAC et adresse IP). Les autres PE du segment Ethernet qui apprennent la nouvelle route à partir du PE distant envoient désormais un message de route MAC et d’adresse IP avec le bit proxy défini. Si l’entrée d’adresse MAC et IP est obsolète ou si la liaison entre le PE et le CE échoue, les entrées doivent être réapprises et le trafic peut être perdu. Cela permet d’éviter les pertes de trafic en cas d’échec de l’une des connexions à un équipement leaf. L’adresse MAC du proxy multirésident est automatiquement activée.
Mise à jour de la table de transfert MAC
Dans le multihébergement EVPN actif-veille, les adresses MAC sont traitées comme des adresses routables et le protocole MP-IBGP est utilisé pour transporter les adresses MAC des clients. L’apprentissage MAC au niveau des routeurs PE ne se produit pas dans le plan de données, mais dans le plan de contrôle. Cela conduit à plus de contrôle appliqué en termes de mécanisme d’apprentissage.
Un routeur PE effectue l’apprentissage MAC dans le plan de données pour les paquets provenant d’un réseau client pour un EVI particulier. Pour les adresses MAC CE qui se trouvent derrière d’autres routeurs PE, les adresses MAC sont annoncées dans BGP NLRI à l’aide d’un nouveau type de route d’annonce MAC.
L’apprentissage MAC est de deux types :
Apprentissage MAC local : les routeurs PE doivent prendre en charge le processus d’apprentissage MAC local via des protocoles standard.
Apprentissage MAC à distance : une fois le processus d’apprentissage local terminé, les routeurs PE peuvent annoncer l’adresse MAC apprise localement aux nœuds de routeur PE distants via MP-IBGP. Ce processus de réception des adresses MAC distantes des clients connectés via MP-IBGP est connu sous le nom de processus d’apprentissage MAC à distance.
Le type de route d’annonce MAC est utilisé pour annoncer les adresses MAC apprises localement dans BGP aux routeurs PE distants. Si une adresse MAC individuelle est annoncée, le champ Adresse IP correspond à cette adresse MAC. Si le routeur PE voit une requête ARP pour une adresse IP à partir d’un périphérique CE et si le routeur PE a la liaison d’adresse MAC pour cette adresse IP, le routeur PE exécute un proxy ARP et répond à la demande ARP.
Le proxy ARP est exécuté uniquement pour la passerelle et non pour l’hôte.
Le champ d’étiquette MPLS dépend du type d’allocation. Le routeur PE peut annoncer une seule étiquette MPLS pour toutes les adresses MAC par EVI, ce qui nécessite le moins d’étiquettes MPLS et permet d’économiser la mémoire du routeur PE. Toutefois, lors du transfert vers le réseau client, le routeur PE doit effectuer une recherche MAC, ce qui peut entraîner un retard et augmenter le nombre de cycles CPU.
Circulation
Dans le multihébergement EVPN, le flux de trafic est effectué dans le plan de transfert. Des routes d’inondation sont créées pour inonder les paquets et sont utilisées dans les scénarios suivants :
Lorsqu’un paquet est reçu sur un ESI local
Lorsqu’un paquet est reçu du cœur
Les flux de trafic dans le multihébergement EVPN peuvent être basés sur les deux types de trafic suivants :
Trafic unicast
Le trafic unicast est une communication point à point avec un émetteur et un récepteur. Dans un EVPN multirésident, le trafic unicast est transféré comme suit :
En mode veille-active
CE au cœur : le trafic est appris et transféré par le routeur DF PE.
Du cœur vers CE : le routeur PE distant apprend les adresses MAC du DF et transfère tout le trafic unicast vers le routeur DF PE.
En mode actif-actif
CE au cœur : le trafic est équilibré en charge sur tous les équipements PE multirésidents connectés.
Du cœur vers CE : le trafic provenant des périphériques PE distants est équilibré en charge vers tous les équipements PE multirésidents connectés à l’équipement CE distant.
Trafic BUM
Le trafic envoyé vers plusieurs destinations, y compris le trafic de diffusion, le trafic unicast inconnu diffusé dans le segment Ethernet et le trafic multicast est connu sous le nom de trafic BUM. Dans un EVPN multirésident, le trafic BUM est transféré comme suit :
En mode veille-active
CE au cœur : le périphérique CE inonde tout trafic BUM sur toutes les liaisons du segment Ethernet. Le routeur DF PE avec le chemin actif transfère les paquets BUM au cœur. Le routeur BDF PE en mode veille abandonne tout le trafic de l’équipement CE, car l’état multihébergement EVPN de l’interface est en état de blocage. Toutefois, si le périphérique CE est connecté aux périphériques PE à l’aide de liaisons séparées ou LAG, le trafic BUM atteint à la fois les périphériques DF et BDF PE.
Du cœur vers CE : les routeurs PE distants inondent tout le trafic BUM vers les routeurs DF et BDF PE. Seul le DF transfère le trafic BUM à l’équipement CE. Le routeur BDF PE abandonne tout le trafic, car l’état de multihébergement EVPN de l’interface est en état de blocage.
En mode actif-actif
Selon les besoins, le flooding et la commutation entre ESI locaux peuvent être activés ou désactivés en mode actif-actif. C’est ce qu’on appelle le comportement de non-commutation locale.
Le cœur du service EVPN fournit une connectivité maillée complète entre les équipements PE multirésidents. Pour cette raison, EVPN utilise un horizon divisé dans le cœur, de sorte qu’un paquet reçu du cœur n’est jamais commuté ou renvoyé vers le cœur. Au lieu de cela, la réplication entrante est utilisée pour répliquer les paquets vers les périphériques PE distants.
Pour inonder des paquets vers des périphériques PE distants, les sauts multicast et les sauts suivants d’horizon fractionné sont utilisés. Le saut suivant multicast tunnelise le paquet avec l’étiquette multicast inclusive, et le saut suivant d’horizon fractionné tunnelise le paquet avec une étiquette multicast et une étiquette d’horizon divisé. Un de ces sauts suivants est requis par ESI multirésident et par équipement PE distant.
Les routes d’inondation suivantes sont utilisées en mode actif-actif :
Voie d’inondation tout CE
Cette route d’inondation est utilisée par les ESI locales pour les raisons suivantes :
Inonder le paquet sur les ESI locaux (lorsque la commutation locale est autorisée).
Inonder le paquet vers les périphériques PE distants. Les appareils PE distants inondent le paquet sur leurs ESI locaux.
Étant donné que le trafic BUM est transféré uniquement par le redirecteur désigné (DF), et non par les périphériques PE multirésidents non-DF, les non-DF utilisent le saut suivant Split Horizon pour inonder ce paquet vers d’autres périphériques PE. Toutefois, les ESI locales multirésidentes pour lesquelles l’appareil PE est un non-DF ne participent pas à l’inondation.
L’itinéraire d’inondation entièrement CE n’est pas utilisé par les ESI non-DF et le tronçon suivant pour ces itinéraires d’inondation est créé en conséquence. Dans ce cas, l’itinéraire d’inondation ESI non-DF est utilisé.
Voie d’inondation entièrement VE
Cette route d’inondation est utilisée lorsque le paquet est reçu du cœur. Il est utilisé pour inonder le paquet reçu du cœur vers les ESI locaux. Étant donné que le paquet reçu du cœur peut être fourni avec une étiquette multicast uniquement ou avec à la fois une étiquette multicast et une étiquette Split Horizon, les règles de transfert appropriées doivent être suivies pour déposer le paquet sur l’ESI multirésident qui correspond à l’étiquette Split Horizon.
Voie d’inondation non-DF
Cette route d’inondation est utilisée pour les raisons suivantes :
Inonder le paquet sur les ESI locaux.
Inonder le paquet vers les périphériques PE distants à l’aide de la réplication entrante avec l’étiquette SH pour le DF de l’ESI.
Crénelage
À partir de la version 15.1 de Junos OS, Junos OS prend en charge le crénelage dans un EVPN. Le crénelage est la capacité d’un équipement PE distant à équilibrer la charge du trafic unicast de couche 2 sur tous les autres équipements PE qui ont le même segment Ethernet vers un équipement CE.
Crénelage en mode actif-actif
Sur la Figure 3, le crénelage en mode actif-actif fonctionne comme suit :
ESI1 est configuré sur les routeurs PE1, PE2 et PE3. Les routeurs PE1, PE2 et PE3 annoncent la route de découverte automatique par segment Ethernet pour ESI1.
L’appareil CE1 envoie le trafic de couche 2 avec l’adresse MAC source (MAC1) au routeur PE1.
Le routeur PE1 apprend l’adresse MAC1 sur (ESI1, vlan X) et l’annonce à tous les routeurs PE à l’aide de BGP.
Le routeur PE4 reçoit la route MAC1 via BGP.
Étant donné que le routeur PE4 a également reçu la route de découverte automatique par EVI des routeurs PE2 et PE3, il sait que MAC1 doit être accessible via les routeurs PE2 et PE3. Le routeur PE4 construit son état de transfert pour équilibrer la charge du trafic de couche 2 pour MAC1 entre les routeurs PE1, PE2 et PE3.
Routes de crénelage et de découverte automatique
Les routes de découverte automatique des routeurs PE2 et PE3 peuvent être fournies dans n’importe quel ordre. Par conséquent, ces routes sont installées par le processus de couche 2 comme suit :
Après avoir reçu MAC1 du routeur PE1, et si aucune route de découverte automatique n’a été reçue par le routeur PE4, MAC1 est programmé par PE4 avec un saut suivant pointant vers le routeur PE1. Lorsque PE4 reçoit la route de découverte automatique du routeur PE2 pour le même ESI, le tronçon suivant est installé afin que le trafic pour MAC1 soit équilibré en charge vers les routeurs PE1 et PE2. Lorsque PE4 reçoit la route de découverte automatique du routeur PE3 pour le même ESI, le saut suivant est mis à jour pour équilibrer la charge du trafic MAC1 entre les routeurs PE1, PE2 et PE3.
Si le routeur PE4 a déjà reçu les routes de découverte automatique de plusieurs périphériques PE (PE1, PE2 et PE3), PE4 installe les routes MAC avec le saut suivant multi-destination.
Crénelage et route d’étiquettes
Tout équipement PE qui annonce l’itinéraire de découverte automatique par EVI avec une étiquette MPLS valide programme l’étiquette annoncée dans la table de routage MPLS.0. Par exemple, si le routeur PE2 a annoncé la route de découverte automatique par EVI avec l’étiquette A, l’entrée mpls.0 est la suivante :
La route Label A pointe vers le saut suivant de la table EVPN-EVI.
Lorsque le routeur distant PE4 envoie un paquet de données unicast au routeur PE2 avec cette étiquette A, une recherche est effectuée dans la table de transfert du routeur PE2 et, à la suite de cette recherche, le paquet est transféré sur ESI1.
Crénelage et transfert de paquets unicast
Lorsque les paquets unicast pour MAC1 proviennent du routeur distant PE4 vers le routeur PE2, il peut y avoir deux cas :
Le routeur PE2 a également reçu le même ensemble d’adresses MAC sur sa liaison vers ESI1 : dans ce cas, les routes locales sont préférées et, à la suite de la recherche MAC, les paquets sont transférés à ESI1.
Le routeur PE2 n’a pas reçu le même jeu d’adresses MAC sur sa liaison vers ESI1 : dans ce cas, le routeur PE2 installe toujours les routes MAC pointant vers ESI1, bien que les adresses MAC soient apprises à distance à partir du routeur PE1. Par conséquent, les paquets sont transférés à ESI1.
Multihébergement actif-actif EVPN et agrégation de liens multichâssis
Lorsqu’un périphérique CE est configuré avec un LAG vers les périphériques PE, les deux options suivantes sont disponibles pour exécuter LACP sur les périphériques PE :
Configurez le même ID système LACP sur tous les périphériques PE.
Configurez l’agrégation de liens multichâssis sur les équipements PE.
Lorsque l’agrégation de liens multichâssis est configurée avec EVPN, un ensemble réduit de procédures d’agrégation de liens multichâssis actifs-actifs est requis. Ces procédures fournissent une redondance au niveau de la liaison et du nœud. L’agrégation de liens multichâssis est totalement transparente pour l’équipement CE et est réalisée en tant que LAG pur. L’agrégation de liens multichâssis fonctionne également au niveau des ports. Cela signifie essentiellement que si l’agrégation de liens multichâssis est configurée en mode actif-actif, tous les VLAN sur les ports d’agrégation de liens multichâssis fonctionnent en mode multihébergement actif-actif.
Lorsque l’agrégation de liens multichâssis est configurée avec EVPN, les éléments suivants sont pris en compte :
L’agrégation de liens multichâssis et l’ESI EVPN doivent être activés pour fonctionner en mode actif-actif uniquement.
Les fonctions suivantes ne sont pas requises pour l’agrégation de liens multichâssis avec EVPN :
Synchronisation Mac : cette opération est effectuée dans le plan de contrôle BGP d’EVPN.
Liaison ICL : cette opération est gérée par la fonctionnalité de crénelage d’EVPN.
Synchronisation ARP : elle est gérée par le plan de contrôle BGP avec la fonctionnalité IRB.
Multihébergement actif-actif EVPN et IRB
Lorsque l’IRB est configuré, les routes EVPN contiennent à la fois des informations MAC et IP. Le multihébergement actif-actif nécessite une synchronisation ARP entre les périphériques PE multirésidents, car les réponses ARP peuvent être hachées sur un périphérique PE particulier.
Exemple de configuration
Voici un exemple de configuration pour le multihébergement actif-veille EVPN sur les types d’interfaces suivants :
Configuration de l’interface Ethernet
ge-0/1/2 { encapsulation ethernet-bridge; esi XX:XX:XX:XX:XX:XX:XX:XX:XX:XX; unit 0 { family bridge; } }Configuration d’interface VLAN unique
ge-0/1/3 { encapsulation extended-vlan-bridge; esi XX:XX:XX:XX:XX:XX:XX:XX:XX:XX; vlan-tagging unit 0 { family bridge; vlan-id 1; } }
Une valeur ESI de 0 et tous les FF sont réservés et ne sont pas utilisés pour la configuration d’un segment Ehernet multirésident.
Deux interfaces d’une même EVI ne peuvent pas être configurées avec la même valeur ESI.
Voici un exemple de configuration d’instance de routage pour le multihébergement actif-secours EVPN :
Configuration de l’instance de routage
routing-instances { evpn-0 { instance-type evpn; route-distinguisher value; vrf-target value; vlan-id vlan-ID; interface ge-0/1/2.0; interface ge-1/1/1.0; interface ge-2/2/2.0; protocols { evpn { designated-forwarder-election-hold-time time; } } } }
Avec la configuration en mode veille-actif, l’itinéraire de découverte automatique par segment Ethernet est annoncé avec le bit de veille active défini sur 1 pour chaque segment Ethernet.
Choix d’un transitaire désigné
La procédure d’élection du redirecteur désigné (DF) dans EVPN fournit un mécanisme robuste pour élire un redirecteur désigné parmi les périphériques qui desservent un segment Ethernet multirésident. Le choix DF garantit l’efficacité et l’efficience du transfert du trafic BUM (unicast et multicast), l’équilibrage de charge, la haute disponibilité et la gestion du trafic. Les principales caractéristiques sont les suivantes :
-
Algorithmes basés sur modulo ou sur les préférences pour la sélection DF.
-
Réélection dynamique du DF déclenchée par les changements d’état du réseau.
-
Rôles DF et DF de secours pour éviter les boucles de trafic.
Le système traite également les routes ESI pour optimiser le traitement des routes et utilise des mécanismes de retrait massif pour maintenir l’intégrité du réseau. Vous pouvez utiliser ces fonctionnalités et leurs configurations CLI pour assurer la fluidité du trafic et gérer efficacement vos scénarios de multihébergement EVPN.
Pour plus d’informations, reportez-vous à la section Choix du redirecteur désigné pour le multihébergement EVPN.
ESI sur des interfaces physiques, Ethernet agrégées et logiques
Dans les versions antérieures à Junos OS version 15.1F6 et 17.1R1 pour les routeurs MX Series et à Junos OS version 17.3R1 pour les commutateurs EX9200, vous pouvez spécifier un ESI uniquement sur une interface Ethernet physique ou agrégée, par exemple, set interfaces ae0 esi 00:11:22:33:44:55:66:77:88:99. Si vous spécifiez un ESI sur une interface Ethernet physique ou agrégée, gardez à l’esprit qu’un ESI est un facteur dans le processus de choix du redirecteur désigné (DF). Par exemple, supposons que vous configuriez le multihébergement EVPN en veille active sur l’interface Ethernet agrégée ae0 et que, compte tenu de l’ESI configuré sur ae0 et d’autres facteurs déterminants, l’élection DF entraîne la position de ae0 à l’état inactif. En outre, toutes les interfaces logiques configurées sur l’interface Ethernet agrégée ae0, par exemple, set interfaces ae0 unit 1 sont set interfaces ae0 unit 2 également à l’état inactif, ce qui empêche les interfaces logiques ae0.1 et ae0.2 de fournir des services à leurs sites clients respectifs (VLAN).
Pour optimiser l’utilisation des interfaces logiques en mode de multihébergement EVPN actif-veille ou actif-actif, à commencer par Junos OS versions 15.1F6 et 17.1R1 pour les routeurs MX Series et Junos OS version 17.3R1 pour les commutateurs EX9200, vous pouvez spécifier un ESI sur une interface logique. Par conséquent, même si une interface logique n’est pas DF, les autres interfaces logiques sur la même interface Ethernet physique ou agrégée sont toujours en mesure de fournir des services à leurs sites clients respectifs (VLAN).
Pour plus d’informations, reportez-vous à la section Exemple : Configuration d’un ESI sur une interface logique avec multihébergement EVPN.
ESI générées automatiquement
À partir de Junos OS version 18.4R1, vous pouvez configurer des interfaces Ethernet agrégées et des interfaces logiques Ethernet agrégées pour dériver automatiquement les ESI de la configuration LACP. Nous prenons en charge cette fonctionnalité dans les environnements suivants :
Sur les équipements Juniper Networks qui prennent en charge cette fonctionnalité et qui sont multirésidents en mode actif-actif dans un réseau overlay EVPN-VXLAN.
Sur les équipements Juniper Networks qui prennent en charge cette fonctionnalité et qui sont multirésidents en mode actif-veille ou actif-actif dans un réseau overlay EVPN-MPLS.
Pour plus d’informations, reportez-vous à la section Présentation des ESI générées automatiquement dans les réseaux EVPN.
Convergence dans un réseau EVPN
Lorsque la topologie du réseau d’un système EVPN à grande échelle change, le temps de convergence peut être important. Vous pouvez hiérarchiser les mises à jour NLRI qui sont essentielles à la sélection du routage dans les stratégies de routage afin d’améliorer la convergence. Le Tableau 1 répertorie les types de routes NLRI et la priorité qui doivent être configurées dans la stratégie de routage.
NLRI Route Type |
Description |
Priorité |
|---|---|---|
Itinéraire NLRI de type 1 |
Route de découverte automatique Ethernet : le type 1 prend en charge la convergence rapide et le crénelage et est utilisé pour signaler le retrait de masse MAC. |
Haut |
Itinéraire NLRI de type 2 |
MAC/IP advertisement route : le type 2 est utilisé pour annoncer les adresses MAC et les adresses IP dans les réseaux EVPN. |
Bas |
Itinéraire NLRI de type 3 |
Balise Ethernet multicast inclusive : le type 3 permet de configurer un chemin pour le trafic BUM. |
Bas |
Type de route NLRI 4 |
Route de segment Ethernet : l’EVPN de type 4 est utilisé pour sélectionner un redirecteur désigné. |
Haut |
Pour hiérarchiser le type de route NLRI, définissez le bgp-output-queue-priority priority for au niveau de laedit policy-options policy-statement] hiérarchie [nlri-route-typesur tous les routeurs de périphérie du fournisseur et les réflecteurs de route dans le réseau EVPN. Dans cet exemple, une priorité élevée a été configurée pour les routes NLRI de type 1 et NLRI de type 4.
user@PE1#show policy-options
policy-statement evpn-rt-priority-policy {
term 1 {
from {
family evpn;
nlri-route-type 1;
}
then {
bgp-output-queue-priority priority 16;
}
}
term 2 {
from {
family evpn;
nlri-route-type 2;
}
then {
bgp-output-queue-priority priority 1;
}
}
term 3 {
from {
family evpn;
nlri-route-type 3;
}
then {
bgp-output-queue-priority priority 2;
}
}
term 4 {
from {
family evpn;
nlri-route-type 4;
}
then {
bgp-output-queue-priority priority 16;
}
}
}
Il existe 17 files d’attente de sortie hiérarchisées : une file d’attente accélérée qui a la priorité la plus élevée et 16 files d’attente numérotées pour lesquelles 1 est la priorité la plus basse et 16 est la plus élevée.
Pour plus d’informations sur la configuration des stratégies de routage, consultez Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic.
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.