Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Présentation du multihébergement EVPN

Introduction au multihébergement EVPN

Un VPN Ethernet (EVPN) comprend des équipements de périphérie client (CE) connectés aux équipements de périphérie des fournisseurs (PE), qui forment la périphérie de l’infrastructure MPLS. Un équipement CE peut être un hôte, un routeur ou 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 fait dans le plan de contrôle à l’aide de BGP, contrairement au pontage traditionnel, où l’apprentissage se fait dans le plan de données.

Note:

Dans les versions antérieures à Junos OS version 15.1, la prise en charge de la fonctionnalité EVPN sur les routeurs MX Series était limitée aux routeurs utilisant uniquement des interfaces MPC et MIC. À partir de la version 15.1 de Junos OS, les routeurs MX Series utilisant des DPC peuvent être exploités pour fournir une prise en charge EVPN sur l’interface de l’équipement CE.

DPC prise en charge d’EVPN est fournie avec les considérations suivantes :

  • Les DPC prennent en charge l’EVPN dans le mode de fonctionnement actif de réserve, y compris la prise en charge des éléments suivants :

    • Instance EVPN (EVI)

    • Commutateur virtuel

    • Interfaces de routage et de pontage intégrés (IRB)

  • Les DPC destinés à fournir la prise en charge active-standby EVPN doivent être la carte d’interface de l’équipement CE. L’équipement PE du domaine EVPN doit être des interfaces MPC ou MIC.

La fonctionnalité de multihébergement EVPN vous permet de connecter un site client à deux équipements PE ou plus pour fournir une connectivité redondante. Un équipement CE peut être multihébergement à différents équipements PE ou au même équipement PE. Un équipement PE redondant peut fournir un service réseau au site du client dès qu’une défaillance est détectée. Ainsi, le multihébergement EVPN permet de maintenir le service EVPN et le transfert de trafic vers et depuis le site multi-hébergement en cas de défaillances réseau suivantes :

  • Échec de liaison entre un équipement PE et un équipement CE

  • Défaillance de l’équipement PE

  • Échec d’accessibilité MPLS entre l’équipement PE local et un équipement PE distant

La figure 1 illustre comment un équipement CE peut multihébergement vers deux routeurs PE. L’équipement CE 1 est multihébergement aux routeurs PE 1 et PE 2. L’équipement CE 2 a deux chemins potentiels pour atteindre l’équipement CE 1, et selon le mode de redondance multihébergement, un seul chemin ou les deux chemins sont actifs à tout moment. 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 transfère le trafic vers l’équipement CE (également appelé forwarder désigné) utilise des tunnels MPLS LSP ou GRE pour transférer le trafic. En cas de défaillance sur ce chemin, un nouveau forwarder désigné est choisi pour transférer le trafic vers l’équipement CE 1.

Figure 1 : équipement CE multihébergement vers deux routeurs CE Device Multihomed to Two PE Routers PE

Fonctionnalités de multhoming MPLS EVPN prises en charge par les commutateurs QFX10000

À partir de Junos OS 17.4R1, les commutateurs QFX10000 prennent en charge le multihébergement pour les MPLS EVPN. Seul le multihébergement actif-actif est pris en charge. Les sous-fonctionnalités suivantes sont prises en charge :

  • Configuration ESI (seules les configurations manuelles de type 0 et IFD (interfaces physiques) sont prises en charge)

  • Routage d’alias et d’étiquettes

  • Route EVPN de type 4 (routage de segments Ethernet)

  • Communautés étendues

  • Trafic BUM

  • Rôles DF (Designated Forwarder Election) : DF et BDF

Les commutateurs QFX10000 sur un cœur EVPN MPLS ne prennent en charge que l’instance de routage de commutateur par défaut. Une instance EVPN (EVI) n’est pas prise en charge.

Multihébergement MPLS EVPN sur les routeurs ACX5448

À partir de la version Junos OS 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 le routeur ACX5448, incluez l’énoncé evpn-mh-profile de configuration au niveau de la hiérarchie [edit system packet-forwarding-options firewall-profile].

Note:

Après avoir modifié le profil et l’avoir engagé, vous devez redémarrer le processus de gestion du châssis en publiant la restart chassis-control commande CLI pour mettre en place le nouveau profil.

Un avertissement syslog apparaît pour redémarrer le PFE.

Comprendre les concepts de multihébergement EVPN

La figure 2 montre une topologie de réseau EVPN simple pour définir les concepts de multihébergement EVPN. .

Figure 2 : Topologie Simple EVPN Topology EVPN simple
  • Ethernet segment— Lorsqu’un équipement CE est multi-accueil à 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 liaisons (LAG) vers l’équipement CE.

    Les liaisons des routeurs PE1 et PE2 vers l’équipement CE1 forment un segment Ethernet.

    Dans le multihébergement actif-veille, les liaisons qui constituent un segment Ethernet forment un domaine de pont. Dans le multihébergement actif-actif, un segment Ethernet apparaît en tant que LAG pour l’équipement CE.

  • ESI: un segment Ethernet doit avoir un identifiant unique non nul, appelé identifiant de segment Ethernet (ESI). L’ESI est encodé sous la forme d’un nombre entier de 10 octets. Lors de la configuration manuelle d’une valeur ESI, l’octet le plus important, connu sous le nom d’octet de type, doit être 00. Lorsqu’un équipement CE à domicile est connecté à un segment Ethernet, la valeur ESI totale est de zéro.

    La valeur ESI du segment Ethernet de l’équipement multihébergement CE1 est 00:11:22:33:44:55:66:77:88:99 assigné. L’équipement ce2 à domicile unique 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 par client. Chaque EVI dispose d’un système de routage unique et d’une ou plusieurs cibles de route.

    Un EVI est configuré 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 se compose 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 EVPN. Chaque routeur PE de cette instance EVPN effectue un mappage entre les identifiants de domaine de diffusion compris par chacun de ses équipements CE connectés et la balise Ethernet correspondante.

  • Ethernet segment route— Les routeurs PE connectés à un équipement CE multihomed utilisent des 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 le routage de segments Ethernet, qui se compose d’une communauté étendue ESI et ES-import.

    Les routeurs PE1 et PE2 annoncent un routage ES avec une communauté étendue d’importation d’ES (ainsi que d’autres communautés étendues comme la cible de routage). Les routeurs PE construisent également un filtre basé sur une communauté étendue d’importation d’ES, ce qui permet uniquement à ces routeurs PE d’importer le routage ES et d’identifier qu’ils sont connectés au même segment Ethernet.

  • Extended community— Une communauté étendue est similaire, à la plupart des égards, à une communauté ordinaire. Les EVPN utilisent des communautés étendues parce que la valeur de la communauté régulière de 4 octets n’offre pas assez 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 qui est diffusé dans le segment Ethernet et le trafic multicast.

  • DF— Lorsqu’un équipement CE est multi-hébergement à deux routeurs PE ou plus, un ou la totalité des routeurs PE multi-hébergement sont utilisés pour atteindre le site du client en fonction du mode de fonctionnement multihébergement. Le routeur PE qui assume le rôle principal pour le transfert du trafic BUM vers l’équipement CE est appelé le forwarder désigné (DF).

  • BDF— Chaque routeur de l’ensemble des autres routeurs PE faisant la publicité du routage de découverte automatique par segment Ethernet pour le même ESI, et servant de chemin de secours en cas de défaillance du DF, est appelé un transfert 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 désignation du forwarder pour sélectionner les routeurs DF et BDF PE.

Mode de fonctionnement multihébergement EVPN

Les différents modes de fonctionnement du multihébergement EVPN comprennent :

  • Unique : lorsqu’un routeur PE est connecté à un site client à domicile unique, ce mode fonctionne. Le mode unique est le mode de fonctionnement par défaut et ne nécessite pas de configurer les valeurs de segment Ethernet.

  • Veille active : lorsqu’un seul routeur PE, parmi un groupe de routeurs PE rattachés à un segment Ethernet, est autorisé à transférer le trafic vers et depuis ce segment Ethernet, le segment Ethernet est défini comme fonctionnant en mode de redondance active-veille .

    Pour configurer le mode veille active, incluez la valeur ESI et l’instruction single-active sous le [edit interfaces] niveau hiérarchique.

    Note:

    Nous ne prenons pas en charge le mode multihébergement de réserve active sur les commutateurs QFX Series ou dans les configurations EVPN avec les superpositions VXLAN. Par conséquent, si vous configurez l’option sur des single-active 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 le trafic vers et depuis le segment Ethernet, le segment Ethernet est défini comme fonctionnant en mode de redondance active-active .

    Note:

    Dans junos OS version 14.2 et versions antérieures, le commutateur EX9200 Series prend uniquement en charge le mode de veille actif pour le multihébergement EVPN.

    Note:

    À partir de la version 14.1x53-D30 de Junos OS pour les commutateurs QFX5100 et de la version 18.2R1 de Junos OS 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 haut de baie (ToR) dans le centre de données pour les réseaux virtuels. La fonctionnalité de multihébergement EVPN active-active permet d’accéder aux serveurs bare metal connectés aux commutateurs haut de baie.

    Note:

    À partir des versions 14.1R4, 14.2, 15.1F6 et 16.1R1 de Junos OS, 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, les commutateurs QFX10000 17.4R1 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-active au 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 les équipements CE2 est multihébergement pour les routeurs PE1, PE2 et PE3. Le segment Ethernet de l’équipement CE peut être configuré en tant que groupe d’agrégation de liaisons (LAG) ou en tant que chemin ECMP. Les équipements CE1 et CE3 sont les équipements de périphérie à domicile unique et ont une valeur ESI de 0.

Figure 3 : Multihébergement Active-Active EVPN Multihoming EVPN actif-actif

Implémentation du multihébergement EVPN

Le mode de fonctionnement multihébergement actif-veille EVPN offre une redondance pour les défaillances de liaison d’accès et les défaillances de nœud PE pour l’équipement CE multi-hébergement, et est basé sur le draft-ietf-l2vpn-evpn-03 EVPN.

L’implémentation par Junos OS des modes de fonctionnement actifs-veille et actifs-actifs du multihébergement EVPN comprend les éléments suivants :

Nouvelles NLRIs BGP

Pour prendre en charge le multihébergement EVPN, les nouveaux routes BGP d’accessibilité de la couche réseau (NLRI) suivantes ont été introduites :

Route de découverte automatique par segment Ethernet

Fonctionnalités de route de découverte automatique

Les fonctionnalités NLRI de découverte automatique des routes comprennent :

  • Il s’agit d’un itinéraire obligatoire de type 1, utilisé pour la convergence rapide et pour la publicité du label split horizon. Il est également connu sous le nom de route de retrait de masse.

  • Les commutateurs de routage de type 1 sont utilisés avec l’adresse IP (bouclage) du routeur PE d’origine comme valeur de distinction de route.

  • Cette route transporte l’ESI dans le NLRI (non nul lorsqu’il s’agit d’un PE multihomed, zéro sinon).

  • Le label d’horizon divisé est par ESI uniquement et porte une valeur NULL explicite (0).

  • Le bit dans le champ de l’indicateur de veille active dans la communauté étendue de labels ESI est utilisé pour signaler le mode de veille active (ensemble de bits).

  • Les valeurs d’étiquette de 3 octets dans le NLRI et la balise Ethernet sont zéro.

  • Ce routage est annoncé et importé par tous les routeurs PE multihomed et distants qui partagent le même EVI sur la publicité ESI.

Publicité de route de découverte automatique
  • Mode veille active

    En mode veille active, le forwarder désigné (DF) annonce le routage de découverte automatique par segment Ethernet avec une communauté étendue de label ESI MPLS dont le bit de veille est défini sur 1. Le routage de découverte automatique est annoncé par ESI, et le label ESI est défini sur 0 lorsque le mode veille actif est en fonctionnement.

    Le routage de découverte automatique est importé par tous les routeurs PE multihébergement et distants qui font partie de l’EVI. En recevant le routage de découverte automatique, les routeurs PE dans la topologie du réseau apprennent que le mode de multihébergement actif-veille fonctionne pour l’ESI annoncé.

  • Mode actif-actif

    En mode actif-actif, chacun des équipements PE multihébergements annonce une route de découverte automatique obligatoire par segment Ethernet, comme dans l’état de veille active. Toutefois, à l’état actif-actif, le routage de découverte automatique par segment Ethernet est modifié de manière à ce que le bit de réserve actif transporté dans la communauté étendue MPLS soit autorisé pour indiquer que le mode actif-actif est opérationnel. Le routage de découverte automatique par segment Ethernet en mode actif-actif comprend également le label d’horizon divisé.

    Sur la figure 3, pour le segment Ethernet ESI1, les routeurs PE1, PE2 et PE3 annoncent le routage de découverte automatique. Le routeur PE4 reçoit ce routage de découverte automatique.

Retrait de route de découverte automatique

Le routage de découverte automatique par retrait de segment Ethernet peut entraîner un retrait massif. La fonctionnalité de retrait massif est utilisée en cas de défaillance de liaison sur l’ESI, ou lorsque la configuration ESI change.

Lorsque la liaison entre un équipement CE multihébergement et un équipement PE multi-accueil échoue, l’équipement PE retire le routage de découverte automatique par segment Ethernet. Dans un tel cas, la fonctionnalité de retrait de masse est gérée de la manière suivante par les autres équipements PE :

  • Équipement PE distant

    Lorsqu’un équipement PE distant reçoit la mise à jour BGP pour un retrait massif, les opérations suivantes sont effectuées sur l’équipement PE distant :

    1. Le saut suivant actuel pour atteindre l’équipement ESI ou CE distant est supprimé.

    2. Un nouveau saut à travers les équipements PE multi-foyers restants est créé pour atteindre l’équipement ESI ou CE distant.

    3. Toutes les routes MAC derrière l’équipement CE sont mises à jour avec le nouveau saut suivant 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. À présent, lorsque la liaison entre l’équipement CE et un équipement PE multi-home échoue, le saut suivant vers l’ESI ou le CE est mis à jour, réduisant ainsi le besoin d’un retrait massif. Pour plus d’informations sur l’activation du saut suivant de liste dynamique, consultez configuration du saut suivant de liste dynamique.

  • Autre équipement PE multihomed

    À la suite du retrait de masse, l’équilibrage de charge sur l’équipement CE multihomed se produit en raison des éléments suivants :

    • Lorsque les autres équipements PE multihébergement reçoivent le même ensemble d’adresses MAC sur le lien vers l’ESI concerné.

      Dans ce cas, les routes locales sont préférées. Si les routes distantes apprises par l’équipement DF PE sont retirées, cela n’affecte pas les routes pointant vers l’ESI local.

    • Lorsque les autres équipements PE multi-foyers n’ont pas reçu le même ensemble d’adresses MAC sur la liaison vers l’ESI concerné.

      Dans ce cas, les équipements PE installent les routes MAC pointant vers l’ESI concerné, bien que les MAC soient appris à distance par l’équipement DF PE. Lorsque l’équipement DF PE retire ces routes, les routes retirées sont rincées. Les paquets destinés aux adresses MAC sont inondés sur tous les segments locaux.

Routage de segments Ethernet

Fonctionnalités de routage de segments Ethernet

Les fonctionnalités NLRI de routage de segments Ethernet comprennent :

  • Il s’agit d’une route de type 4. L’objectif de ce routage est de permettre aux routeurs PE connectés au même segment Ethernet de se découvrir automatiquement avec une configuration minimale lors de l’échange de ce routage.

  • Ce routage est associé à une communauté étendue d’importation d’ES avec une valeur ESI condensée à 6 octets, similaire à une cible de routage.

  • Ce routage est annoncé et importé uniquement par des routeurs PE multi-accueil sur le segment Ethernet publicitaire.

Publicité Ethernet Segment Route

Le routage de segments Ethernet est échangé entre tous les routeurs PE d’un centre de données avec la communauté étendue d’importation d’ES. La communauté étendue d’importation d’ES est construite sur les routeurs ESI PE multihébergement, et le routage de segments Ethernet porte la valeur ESI liée au segment Ethernet sur lequel les routeurs PE sont multihébergement.

Les routes de segments Ethernet sont filtrées en fonction de la communauté étendue d’importation d’ES, de sorte que seuls les routeurs PE multihébergement sur le même segment Ethernet l’importent. Chaque routeur PE connecté à un segment Ethernet particulier construit une règle de filtrage d’importation pour importer un routage qui transporte la communauté étendue d’importation d’ES.

Route de découverte automatique par instance EVPN

En mode actif-actif, chacun des équipements PE multihébergement annoncent une route de découverte automatique par instance EVPN (EVI) avec un label MPLS valide. Ce routage est annoncé par ESI et est importé par les équipements PE distants. Le label MPLS inclus dans la route de découverte automatique par EVI est utilisé ultérieurement pour l’aliasing.

Nouvelles communautés étendues

À bien des égards, une communauté étendue est semblable à une communauté ordinaire. Certaines implémentations réseau, telles que les réseaux privés virtuels (VPN), utilisent des communautés étendues, car la valeur de la communauté régulière de 4 octets n’offre pas assez 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 actif et de réserve, les communautés étendues suivantes ont été introduites :

ESI-Import

Cette communauté étendue est rattachée au routage ES et est peuplé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 l’IANA.

La cible de routage communautaire étendue ESI-import remplit la liste des cibles de routage d’importation configurées pour l’instance spéciale à partir de laquelle le routage ES utilisant cette communauté est annoncé.

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 qui a 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 ESI-import, l’élection DF et BDF peut être effectuée localement.

Note:

Lorsque la communauté étendue ESI-import n’est pas créée implicitement, une stratégie doit être configurée pour associer toutes les cibles de routage au routage de découverte automatique par segment Ethernet.

Horizon divisé

En référence à la figure 3 , par exemple, lorsqu’un équipement CE multihébergement à au moins deux équipements PE sur un segment Ethernet (ESI1) et fonctionnant en mode de redondance active-active envoie un paquet BUM à l’un des équipements PE non-DF (par exemple PE1), alors l’équipement PE1 transfère ce paquet à tous ou à un sous-ensemble des autres équipements PE dans cette instance EVPN, y compris l’équipement DF PE pour ce segment Ethernet. Dans ce cas, l’équipement DF PE que l’équipement CE est multi-hébergement pour laisser tomber le paquet sans le renvoyer vers l’équipement CE. Ce filtrage est appelé horizon divisé.

  • Signalisation à horizon divisé

    La communauté étendue à horizon divisé est rattachée au routage de découverte automatique par segment Ethernet. La valeur de la communauté étendue est l’horizon divisé ou le label Poisson lui-même, qui est de 3 octets et est annoncé comme un attribut opaque.

  • Publicité à horizon partagé

    • En mode veille active, le bit de réserve de la communauté étendue à horizon divisé est défini sur 1, et le label ESI d’horizon divisé est défini sur 0.

    • Dans le mode actif-actif, la communauté étendue d’horizon divisé est modifiée pour effacer le bit de réserve de 0 et inclut un label ESI valide utilisé à des fins d’horizon divisé.

  • Routes MPLS à horizon partagé

    L’équipement DF PE annonce une route de découverte automatique par segment Ethernet avec un label A à horizon divisé, et une route multicast inclusive avec étiquette B pour le transfert de trafic BUM. Sur le DF, le paquet BUM du cœur peut être accompagné de labels suivants :

    • Lorsque les équipements PE non-DF reçoivent un paquet BUM sur leurs IS À domicile unique, le paquet BUM est envoyé à l’équipement DF PE avec le label multicast B.

    • Lorsque les équipements PE non-DF reçoivent un paquet BUM sur ESI1, le paquet BUM est envoyé à l’équipement DF PE avec deux étiquettes MPLS : le label multicast B comme étiquette externe et l’étiquette a à horizon divisé comme étiquette interne.

    Dans le scénario de multihébergement EVPN, le label multicast B a le S-bit défini sur 1 lorsqu’il est le seul label de la pile de labels. Dans ce cas, le paquet BUM doit être inondé sur toutes les ISE locales de l’équipement DF PE. Mais le label B a le S-bit défini sur 0 lorsque le label A est le label le plus interne de la pile de labels. Dans ce cas, les paquets BUM doivent être inondés sur toutes les ISE locales de l’équipement DF PE, à l’exception de l’ESI qui correspond au label A de l’horizon divisé.

    Si l’on suppose que les paquets proviennent d’un équipement CE multihomed vers un équipement PE non DF sur le segment multihébergement ESI1, lorsque l’équipement PE non DF envoie ce paquet à l’équipement DF PE, l’étiquette ESI que le DF a annoncée à l’équipement PE non DF dans son itinéraire de découverte automatique par segment Ethernet est envoyée en premier. L’équipement PE non-DF pousse également le label multicast inclus que l’équipement PE DF annonce dans son routage multicast inclus et pousse le label LSP. L’en-tête MPLS contient ainsi deux labels dans un champ de 32 bits.

    La fonctionnalité EVPN de base utilise un saut de table à côté pour assembler la table MPLS avec sa table EVPN EVI correspondante. Dans la table EVPN EVI, la recherche mac est effectuée pour changer 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 de table-next EVPN-EVI.

    • Le routage (multicast-label, S=0) pointe vers le saut MPLS table-next. Ce routage boucle le paquet vers la table MPLS après avoir sorti le multicast-label.

    • Le routage (split horizon-label) pointe vers le saut de table-next EVPN-EVI. Il s’agit du même saut table-next que celui utilisé par le routage multicast-label, S=1.

Nouveaux types de routes EVPN

Le mode de multihébergement EVPN prend en charge les types de routes EVPN suivants :

  • Routage de découverte automatique par segment Ethernet

  • Route de découverte automatique par instance EVPN (EVI)

  • Routage de segments Ethernet

Ces types de routes sont conformes à la convention de nommage suivante :

<route-type>:<RD>::<esi>::<route-specific>/304

Par exemple :

  1. Routage de découverte automatique par segment Ethernet :1:10.255.0.2:0::112233445566778899::0/304

  2. Route de découverte automatique par EVI :1:100.100.100.1:1::22222222222222222222::0/304

  3. Routage de segments 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 l’encapsulation VXLAN/MPLS

  • RD— Valeur de distinction de route.

    La valeur de distinction de route est définie sur l’adresse IP du routeur PE, suivie de 0.

  • esi— Identifiant de segment Ethernet. Affiché sous la forme de 10 octets hexadécimaux et de 00 octets principaux ne sont pas affichés.

  • route-specific: diffère selon le type de route.

    • Route de découverte automatique par segment Ethernet et route de découverte automatique par EVI : cette valeur est un label MPLS.

      Note:

      Le label MPLS est affiché dans la sortie étendue, bien qu’il ne soit pas inclus dans le préfixe.

    • Routage de segments Ethernet : cette valeur est l’adresse IP d’origine.

  • 304— Nombre maximal de bits dans un routage EVPN. Il ne s’agit pas d’informations très utiles et pourraient être supprimées de l’écran. Toutefois, il peut être utile d’identifier rapidement un routage EVPN, que ce soit visuellement ou avec des opérateurs de correspondance.

Publicité de routage MAC et IP de proxy multihomed

À partir de la version 18.4R1 de Junos OS, Junos envoie des publicités de routage MAC et IP proxy à partir de PE multi-accueil vers un équipement CE. Junos utilise un indicateur de proxy dans la communauté étendue EVPN de couche 2 pour identifier le message en tant que publicité proxy MAC et adresse IP. Un PE qui apprend les adresses MAC et IP envoie une publicité de routage EVPN de type 2 (adresse MAC et IP) normale. Les autres PE du segment Ethernet qui apprennent le nouveau routage à partir du PE distant envoient désormais un message de routage MAC et IP avec l’ensemble de bits proxy. Si l’entrée des adresses MAC et IP est obsolète ou si la liaison entre le PE et le CE échoue, les entrées doivent être réapprisées et le trafic peut être perdu. Cela évite la perte de trafic lorsque l’une des connexions à un équipement de branche échoue. Proxy MAC multi-accueil est automatiquement activé.

Mettre à jour la table de transfert MAC

Dans le multihébergement EVPN de réserve active, 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 fait 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 une EVI particulière. 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 publicitaire 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 de la publicité MAC est utilisé pour annoncer les adresses MAC apprises localement dans BGP vers les routeurs PE distants. Si une adresse MAC est annoncée, le champ adresse IP correspond à cette adresse MAC. Si le routeur PE voit une demande ARP pour une adresse IP provenant d’un équipement 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.

Note:

Le proxy ARP n’est exécuté que pour la passerelle et non pour l’hôte.

Le champ label MPLS dépend du type d’allocation. Le routeur PE peut annoncer un label MPLS unique pour toutes les adresses MAC par EVI, ce qui nécessite le moins de labels MPLS et économise la mémoire du routeur PE. Toutefois, lors du transfert vers le réseau du client, le routeur PE doit effectuer une recherche MAC qui peut entraîner un retard et augmenter le nombre de cycles de processeur.

Circulation

Dans le multihébergement EVPN, le flux de trafic est effectué dans le plan de transfert. Les 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 :

  • Trafic unicast

    Le trafic unicast est une communication point à point avec un expéditeur et un récepteur. Dans un EVPN multihébergement, le trafic unicast est transféré comme suit :

    • En mode veille active

      • CE jusqu’au cœur : le trafic est appris et transféré par le routeur DF PE.

      • Core to 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 jusqu’au cœur : le trafic est équilibré pour tous les équipements PE multi-foyers connectés.

      • Cœur du CE : le trafic provenant des équipements PE distants est équilibré en charge par rapport à tous les équipements PE multihébergements connectés à l’équipement CE distant.

  • Trafic BUM

    Le trafic envoyé vers plusieurs destinations, y compris le trafic de diffusion, le trafic unicast inconnu qui est diffusé dans le segment Ethernet et le trafic multicast est connu sous le nom de trafic BUM. Dans un EVPN multihébergement, le trafic BUM est transféré comme suit :

    • En mode veille active

      • CE jusqu’au cœur : l’équipement CE inonde tout trafic BUM vers toutes les liaisons du segment Ethernet. Le routeur DF PE avec la voie active fait avancer les paquets BUM vers le cœur. Le routeur PE BDF 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 l’équipement CE est connecté aux équipements PE à l’aide de liaisons ou de LAG distincts, le trafic BUM atteint les équipements PE DF et BDF.

      • Core to CE : les routeurs PE distants inondent tout le trafic BUM vers les routeurs DF et PE BDF. Seul le DF transfère le trafic BUM vers l’équipement CE. Le routeur PE BDF abandonne tout le trafic, car le statut multi-accueil EVPN de l’interface est en état de blocage.

    • En mode actif-actif

      En fonction des exigences, l’inondation et la commutation entre les ISE locales peuvent être activées ou désactivées en mode actif-actif. C’est ce que l’on appelle le comportement sans commutation locale.

      Le cœur du service EVPN fournit une connectivité full-mesh entre les équipements PE multi-homes. 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 basculé ou inondé vers le cœur. Au lieu de cela, la réplication entrante est utilisée pour répliquer les paquets vers les équipements PE distants.

      Pour inonder des paquets vers des équipements PE distants, les sauts suivants sont utilisés pour le multicast et l’horizon divisé. Le multicast next hop tunnels le paquet avec le label multicast inclus, et l’horizon divisé next hop tunnels le paquet avec un label multicast et un label d’horizon divisé. Un saut de ce type est requis par ESI multihébergement par équipement PE distant.

      Les routes d’inondation suivantes sont utilisées en mode actif-actif :

      • Route d’inondation tout-CE

        Cette route d’inondation est utilisée par les ISE locales pour les éléments suivants :

        • Inonder le paquet sur les IS locaux (lorsque la commutation locale est autorisée).

        • Inondant le paquet vers les équipements PE distants. Les équipements PE distants inondent le paquet sur leurs IS locaux.

        Étant donné que le trafic BUM n’est transféré que par le forwardeur désigné (DF), et non par les équipements PE multihomed non-DF, les non-DFs utilisent l’horizon divisé suivant pour inonder ce paquet vers d’autres équipements PE. Cependant, les ISE locales multihébergement pour lesquelles l’équipement PE est un non-DF ne participent pas à l’inondation.

        La route d’inondation tout-CE n’est pas utilisée par les ISE non-DF, et le saut suivant pour ces routes d’inondation est créé en conséquence. Dans de tels cas, la route d’inondation ESI non-DF est utilisée.

      • Routage d’inondation tout-VE

        Ce chemin d’inondation est utilisé lorsque le paquet est reçu du cœur. Il est utilisé pour inonder le paquet reçu du cœur vers les ISE locales. Étant donné que le paquet reçu par le cœur peut être accompagné d’un multicast-label uniquement ou d’un label multicast-label et d’un label d’horizon divisé, les règles de transfert appropriées doivent être respectées pour déposer le paquet sur l’ESI multihébergement qui s’aligne sur le label d’horizon divisé.

      • Route d’inondation non-DF

        Cette route d’inondation est utilisée pour les éléments suivants :

        • Inonder le paquet sur les ISE locales.

        • Inondant le paquet vers les équipements PE distants à l’aide d’une réplication entrante avec sh-label pour le DF pour l’ESI.

Aliasing

À partir de la version 15.1 de Junos OS, Junos OS prend en charge l’aliasing dans un EVPN. L’aliasing 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.

Aliasing en mode actif-actif

Sur la figure 3, l’aliasing en mode actif-actif fonctionne comme suit :

  1. ESI1 est configuré sur les routeurs PE1, PE2 et PE3. Les routeurs PE1, PE2 et PE3 annoncent le routage de découverte automatique par segment Ethernet pour ESI1.

  2. L’équipement CE1 envoie le trafic de couche 2 avec l’adresse MAC source (MAC1) au routeur PE1.

  3. Le routeur PE1 apprend l’adresse MAC1 sur (ESI1, vlan X) et l’annonce à tous les routeurs PE utilisant BGP.

  4. Le routeur PE4 reçoit le routage MAC1 via BGP.

  5. Étant donné que le routeur PE4 a également reçu le routage 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.

Aliasing et routes de découverte automatique

Les routes de découverte automatique des routeurs PE2 et PE3 peuvent être disponibles dans n’importe quel ordre. En conséquence, ces routes sont installées par le processus de couche 2 comme suit :

  1. Après avoir reçu MAC1 du routeur PE1, et si des routes de découverte automatique n’ont pas été reçues par le routeur PE4, MAC1 est programmé par PE4 avec un saut suivant pointant vers le routeur PE1. Lorsque PE4 reçoit le routage de découverte automatique du routeur PE2 pour le même ESI, le saut suivant est installé de sorte que le trafic mac1 est équilibré en charge vers les routeurs PE1 et PE2. Lorsque PE4 reçoit le routage 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.

  2. Si le routeur PE4 a déjà reçu les routes de découverte automatique de plusieurs équipements PE (PE1, PE2 et PE3), PE4 installe les routes MAC avec le saut suivant multi-destination.

Routage d’alias et d’étiquettes

Tout équipement PE qui annonce la route de découverte automatique par EVI avec un label MPLS valide programme le label annoncé dans la table de routage mpls.0. Par exemple, si le routeur PE2 annonce le routage de découverte automatique par EVI avec le label A, l’entrée mpls.0 est la suivante :

Label Un routage pointe vers le saut de la table EVPN-EVI- next.

Lorsque le routeur distant PE4 envoie un paquet de données unicast vers le routeur PE2 avec cette étiquette A, la 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.

Aliasing et transfert unicast de paquets

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 de 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 vers ESI1.

  • Le routeur PE2 n’a pas reçu le même ensemble de MAC sur sa liaison vers ESI1. Dans ce cas, le routeur PE2 installe toujours des routes MAC pointant vers ESI1, bien que les MAC soient apprises à distance par le routeur PE1. En conséquence, les paquets sont transférés à ESI1.

Multihébergement actif-actif EVPN et agrégation de liaisons multichâssis

Lorsqu’un équipement CE est configuré avec un LAG vers les équipements PE, les deux options suivantes sont disponibles pour exécuter LACP sur les équipements PE :

  • Configurez le même ID système LACP sur tous les équipements PE.

  • Configurez l’agrégation de liaisons multichâssis sur les équipements PE.

Lorsque l’agrégation de liaisons multichâssis est configurée avec EVPN, un ensemble réduit de procédures pour l’agrégation de liaisons multichâssis actives-actives sont nécessaires. Ces procédures fournissent une redondance au niveau des liaisons et des nœuds. L’agrégation de liaisons multichâssis est totalement transparente pour l’équipement CE et est réalisée sous forme de LAG pur. L’agrégation de liaisons multichâssis fonctionne également au niveau des ports. Cela signifie essentiellement que si l’agrégation de liaisons multichâssis est configurée en tant qu’actif-actif, tous les VLAN sur les ports d’agrégation de liaisons multichâssis fonctionnent en mode multihébergement actif-actif.

Lorsque l’agrégation de liaisons multichâssis est configurée avec EVPN, les éléments suivants sont pris en compte :

  • L’agrégation de liaisons multichâssis et L’ESI EVPN doivent être activés pour fonctionner uniquement en mode actif-actif.

  • Les fonctions suivantes ne sont pas requises pour l’agrégation de liaisons multichâssis avec EVPN :

    • Synchronisation Mac : cette opération est effectuée dans le plan de contrôle BGP d’EVPN.

    • Liaison ICL : cette fonctionnalité est gérée par la fonctionnalité d’aliasing 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 des informations MAC et IP. Le multihébergement actif-actif nécessite une synchronisation ARP entre les équipements PE multi-hébergements, car les réponses ARP peuvent être hachage sur un équipement PE particulier.

Exemple de configuration

Voici un exemple de configuration pour le multihébergement actif-de réserve EVPN sur les types d’interfaces suivants :

  • Configuration de l’interface Ethernet

  • Configuration d’interface VLAN unique

Note:
  • Une valeur ESI de 0 et tous les FF sont réservés et ne sont pas utilisés pour configurer un segment Ehernet multihébergement.

  • Deux interfaces dans un 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-de réserve EVPN :

  • Configuration des instances de routage

Note:

Avec la configuration en mode veille active, le routage de découverte automatique par segment Ethernet est annoncé et le bit de réserve actif est défini sur 1 pour chaque segment Ethernet.

Choix du forwardeur désigné

Les sections suivantes abordent l’élection du DF :

Rôles d’élection DF

Le processus d’élection du forwarder désigné (DF) consiste à sélectionner le routeur PE désigné (DF) et le forwarder désigné de secours (BDF) ou un rôle de routeur PE non-DF (forwarder PE non désigné).

  • DF— L’adresse MAC du site client n’est accessible que par le routeur PE qui annonce le routage de la publicité MAC associée. Ce routeur PE est le routeur PE principal sélectionné pour transférer le trafic BUM vers l’équipement CE multi-accueil, et est appelé routeur PE désigné de transfert (DF).

  • BDF— Chaque routeur PE de l’ensemble des autres routeurs PE faisant la publicité du routage de découverte automatique par segment Ethernet pour le même ESI, et servant de chemin de secours en cas de défaillance du DF, est appelé un routeur de transfert désigné de secours (BDF) ou un routeur PE non-DF (forwarder non désigné).

    À la suite du processus d’élection DF, si un routeur PE local est élu BDF, l’interface multihébergement se connectant au site client est placée dans un état de blocage pour le mode de réserve active. L’interface reste dans l’état de blocage jusqu’à ce que le routeur PE soit choisi comme DF pour le segment Ethernet à lequel l’interface appartient.

Élection DF selon RFC 7432

Procédure d’élection DF

La procédure par défaut pour l’élection DF à la granularité de l’ESI et de l’EVI est appelée découpage de service. Grâce au découpage des services, il est possible d’choisir plusieurs DF par segment Ethernet (un par EVI) afin d’équilibrer la charge du trafic multidestination destiné à un segment Ethernet donné. Les procédures d’équilibrage de charge ont réparti l’espace EVI entre les nœuds PE de manière homogène, de telle sorte que chaque PE est le DF pour un ensemble d’EVIs disjoints.

La procédure de découpage des services est la suivante :

  1. Lorsqu’un routeur PE découvre l’ESI du segment Ethernet attaché, il annonce une route de découverte automatique par segment Ethernet avec l’attribut de communauté étendue ES-import associé.

  2. Le routeur PE lance ensuite un timer (valeur par défaut de 3 secondes) pour permettre la réception des routes de découverte automatique à partir d’autres nœuds PE connectés au même segment Ethernet. Cette valeur de timer doit être la même sur tous les routeurs PE connectés au même segment Ethernet.

    Le délai d’attente par défaut peut être remplacé à l’aide de l’instruction de designated-forwarder-election hold-time configuration.

  3. Lorsque le timer expire, chaque routeur PE construit une liste ordonnée des adresses IP de tous les nœuds PE connectés au segment Ethernet (y compris lui-même), dans un ordre numérique croissant. Chaque routeur PE reçoit alors un ordinal indiquant sa position dans la liste ordonnée, à commencer par 0 comme ordinal pour le PE avec l’adresse IP numériquement la plus basse. Les ordinaux sont utilisés pour déterminer quel nœud PE est le DF pour un EVI donné sur le segment Ethernet.

  4. Le routeur PE choisi comme DF pour un EVI donné débloque le trafic pour les balises Ethernet associées à cet EVI. Le DF PE débloque le trafic multidestination dans le sens sortant vers le segment Ethernet. Tous les routeurs PE non-DF continuent d’abandonner le trafic multidestination (pour les EVIs associés) dans le sens sortant vers le segment Ethernet.

Sur la figure 3, l’élection du DF pour le multihébergement actif-actif est effectuée parmi les routeurs PE1, PE2 et PE3. À la suite de cette élection DF, chacun de ces routeurs peut devenir le DF pour un VLAN particulier à partir d’une gamme de VLAN configurés sur ESI1. Le DF est responsable du transfert du trafic BUM sur les ESI et VLAN pour lesquels il est choisi comme DF. Les routeurs PE non-DF bloquent le trafic BUM sur ce segment Ethernet particulier.

Déclenchement de l’élection DF

En général, un processus d’élection au DF est déclenché dans les conditions suivantes :

  • Lorsqu’une interface est nouvellement configurée avec un ESI non nul, ou lorsque le routeur PE passe d’un état isolé à partir du cœur (pas de session BGP) à un état connecté au cœur (session BGP établie), un délai d’attente est imposé. Par défaut, l’interface est placée dans un état bloquant jusqu’à ce que le routeur PE soit choisi comme DF.

  • Après avoir terminé un processus d’élection DF, un routeur PE reçoit un nouveau routage de segments Ethernet ou détecte le retrait d’un routage de segments Ethernet existant, sans délai d’attente imposé.

  • Lorsqu’une interface d’un routeur PE non-DF se rétablit d’une défaillance de liaison, le routeur PE n’a aucune connaissance du temps d’attente imposé par les autres routeurs PE. En conséquence, aucun délai d’attente n’est imposé pour le routeur PE récupéré pour éviter la perte de trafic.

Choix DF basé sur les préférences

Le choix du DF basé sur la RFC 7432 ne répond pas à certaines des exigences opérationnelles requises par certains fournisseurs de services. Pour y remédier, à partir de la version 17.3 de Junos OS, l’élection DF dans un réseau EVPN multihébergement peut être contrôlée à l’aide d’une valeur de préférence administrative pour un ESI.

Dans la procédure d’élection DF par défaut (comme spécifié dans la RFC 7432), le DF est choisi au hasard à partir de l’un des équipements multihébergement avec un fonctionnement modulo. Avec l’élection DF basée sur les préférences, le DF est choisi manuellement à l’aide d’options de configuration de l’interface, telles que la valeur de préférence, le bit Don’t Preempt (DP) et l’ID du routeur ou l’adresse de bouclage.

Procédure d’élection DF basée sur les préférences

L’élection DF basée sur les préférences est prise en charge sur EVPN et PBB-EVPN, et permet d’choisir manuellement un DF. Cela est utile lorsqu’il est nécessaire de choisir le DF en fonction des attributs d’interface, tels que la bande passante associée à une interface.

L’élection DF basée sur les préférences est exécutée comme suit :

  1. Le type d’élection DF et la valeur de préférence sont configurés sous un ESI. Par défaut, le type d’élection DF basé sur les préférences est basé sur le modulo (MOD).

  2. La valeur de préférence configurée et le bit DP sont annoncés aux équipements PE multihébergement à l’aide de la communauté étendue d’élection DF dans les routes de type 4.

  3. Après avoir reçu le routage de type 4, l’équipement PE construit la liste des équipements DF candidats, dans l’ordre de la valeur de préférence, du bit DP et de l’adresse IP.

  4. Lorsque le timer DF expire, l’équipement PE sélectionne le DF en fonction de la valeur de préférence la plus élevée.

    Par défaut, le DF est choisi en fonction de la préférence la plus élevée par EVI. Toutefois, l’élection DF basée sur les préférences permet d’élire le DF en fonction de la valeur de préférence la plus faible lorsque l’instruction designated-forwarder-preference-least est incluse au niveau de la [edit routing-instances routing-instance-name protocols evpn] hiérarchie.

    Note:

    La designated-forwarder-preference-least configuration doit être la même sur les deux interfaces evis multihébergement, sinon il peut y avoir deux DF entraînant une perte ou une boucle de trafic.

  5. Lorsque la même valeur de préférence est configurée, l’équipement PE sélectionne le DF en fonction du bit DP. Lorsque le bit DP est également le même, le DF est choisi en fonction de l’adresse IP la plus basse.

Incompatibilité de l’algorithme d’élection DF

En cas d’incompatibilité entre un algorithme d’élection DF configuré localement et l’algorithme d’élection DF d’un équipement PE distant, tous les équipements PE doivent revenir à l’élection DF par défaut spécifiée dans la RFC 7432.

Migration de l’algorithme d’élection DF

Lors de la migration de l’ancienne élection DF vers la nouvelle élection DF, il est prévu de modifier la configuration pendant la période de maintenance en mettant en panne l’ESI et en modifiant l’algorithme d’élection DF.

Pour effectuer la migration, effectuez les opérations suivantes :

  1. Après une mise à niveau logicielle, sur l’équipement non-DF, mettez en panne toutes les interfaces qui ont le même ESI.

  2. Configurez le nouvel algorithme d’élection DF sur le DF PE.

  3. Configurez l’algorithme d’élection DF sur d’autres équipements PE multihébergement.

  4. Affichez toutes les interfaces sur les équipements PE non-DF.

Changement de préférence pour la maintenance

Après avoir migré l’algorithme d’élection DF, et que tous les équipements PE multihébergement exécutent l’algorithme d’élection DF basé sur les préférences, les tâches de maintenance requises sur le DF existant peuvent être exécutées en modifiant simplement la valeur de préférence configurée. Cela change le DF pour un ESI donné.

Pour changer le DF pour un ESI donné :

  1. Remplacez la valeur de préférence par une valeur plus élevée sur l’équipement non-DF actuel.

  2. Remplacez la valeur de préférence par une valeur inférieure sur l’équipement DF actuel.

Note:

La modification de la valeur de préférence pour un ESI peut entraîner une perte de trafic pendant la courte durée nécessaire pour intégrer le retard dans la propagation de route BGP mise à jour avec la nouvelle valeur de préférence.

Élection DF pour le commutateur virtuel

Le commutateur virtuel permet plusieurs domaines de pont dans une seule instance EVPN (EVI). Le commutateur virtuel prend également en charge les ports de liaison et d’accès. Junos OS permet des services Ethernet flexibles sur le port ; par conséquent, différents VLAN sur un seul port peuvent faire partie de différentes EVIs.

L’élection DF pour le commutateur virtuel dépend des éléments suivants :

  • Mode port : sous-interface, interface de liaison et port d’accès

  • Mode EVI : commutateur virtuel avec EVPN et EVPN-EVI

Dans le commutateur virtuel, plusieurs balises Ethernet peuvent être associées à une seule EVI, dans laquelle la valeur numériquement la plus faible de l’EVI est utilisée pour l’élection DF.

Gestion des basculements

Un basculement peut se produire lorsque :

  • Le routeur DF PE perd son rôle de DF.

  • Il y a une défaillance de liaison ou de port sur le routeur DF PE.

En cas de perte du rôle DF, l’interface client du routeur DF PE est placée dans l’état de blocage.

En cas de défaillance de liaison ou de port, un processus d’élection DF est déclenché, ce qui permet au routeur BDF PE d’être sélectionné comme DF. À ce moment-là, le trafic unicast et le flux BUM de trafic sont affectés comme suit :

Trafic unicast

  • CE jusqu’au cœur : l’équipement CE continue d’inonder le trafic sur toutes les liaisons. Le routeur PE BDF précédent change le statut multi-accueil EVPN de l’interface de l’état de blocage à l’état de transfert, et le trafic est appris et transféré via ce routeur PE.

  • Core to CE : le routeur PE DF défaillant retire le routage de découverte automatique par segment Ethernet et les routes MAC apprises localement, ce qui permet aux routeurs PE distants de rediriger le trafic vers le BDF.

Note:

La transition du routeur PE BDF vers le rôle DF peut prendre un certain temps, ce qui fait que l’état multihébergement EVPN de l’interface continue d’être dans l’état de blocage, entraînant une perte de trafic.

Trafic BUM

  • Ce vers le cœur : tout le trafic est acheminé vers le BDF.

  • Core to CE : les routeurs PE distants inondent le trafic BUM au cœur du réseau.

ISS sur les interfaces physiques, Ethernet agrégées et logiques

Dans les versions antérieures aux versions 15.1F6 et 17.1R1 de Junos OS 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 d’élection du transfert désigné (DF). Par exemple, supposons que vous configurez le multihébergement EVPN active-standby sur l’interface Ethernet agrégée ae0, et compte tenu de l’ESI configuré sur ae0 et d’autres facteurs déterminants, l’élection DF se traduit par ae0 étant dans l’état descendant. De plus, toutes les interfaces logiques configurées sur l’interface Ethernet agrégée ae0, par exemple, set interfaces ae0 unit 1 et set interfaces ae0 unit 2 sont également à l’état descendant, ce qui rend les interfaces logiques ae0.1 et ae0.2 incapables de fournir des services à leurs sites clients respectifs (VLAN).

Pour mieux utiliser les interfaces logiques dans le multihébergement EVPN en mode actif-veille ou actif-actif, à commencer par les versions 15.1F6 et 17.1R1 de Junos OS 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, d’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, consultez l’exemple : configuration d’un ESI sur une interface logique avec le multihébergement EVPN.

Ises générées automatiquement

À partir de la version 18.4R1 de Junos OS, vous pouvez configurer des interfaces Ethernet agrégées et des interfaces logiques Ethernet agrégées pour extraire automatiquement des IS de la configuration LACP. Nous prenons en charge cette fonctionnalité dans les environnements suivants :

  • Sur les équipements Juniper Networks compatibles avec cette fonctionnalité et multihébergement en mode actif-actif dans un réseau overlay EVPN-VXLAN.

  • Sur les équipements Juniper Networks compatibles avec cette fonctionnalité et multihébergement en mode veille active ou actif-actif dans un réseau de superposition EVPN-MPLS.

Pour plus d’informations, reportez-vous à la section Comprendre les IS générés automatiquement dans les réseaux EVPN.

Convergence dans un réseau EVPN

Lorsqu’il y a des changements dans la topologie du réseau dans un système EVPN à grande échelle, le temps de convergence peut être important. Vous pouvez hiérarchiser les mises à jour NLRI 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é à configurer dans la stratégie de routage.

Tableau 1 : Priorité pour le type de route NLRI

NLRI Route Type

Description

Priorité

Routage NLRI de type 1

Route de découverte automatique Ethernet : le type 1 prend en charge la convergence et l’aliasing rapides et est utilisé pour signaler le retrait de masse MAC.

Haute

Route NLRI de type 2

Route de publicité MAC/IP : le type 2 est utilisé pour annoncer les adresses MAC et les adresses IP dans les réseaux EVPN.

Faible

Route NLRI de type 3

Balise Ethernet multicast inclusive : le type 3 est utilisé pour configurer un chemin pour le trafic BUM.

Faible

Route NLRI de type 4

Routage de segments Ethernet : le type 4 est utilisé dans la sélection d’un forwarder désigné.

Haute

Pour hiérarchiser le type de route NLRI, définissez le bgp-output-queue-priority priority nlri-route-type pour au niveau [edit policy-options policy-statement] hiérarchique sur tous les routeurs de périphérie et réflecteurs de route du réseau EVPN du fournisseur. Dans cet exemple, une priorité élevée a été configurée pour les routes NLRI de type 1 et NLRI de type 4.

Note:

Il y a 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 lesquelles1 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 le Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et du trafic.

Tableau de l’historique des versions
Libération
Description
18.4R1
À partir de la version 18.4R1 de Junos OS, vous pouvez configurer des interfaces Ethernet agrégées et des interfaces logiques Ethernet agrégées pour extraire automatiquement des IS de la configuration LACP.
17.4R1
À 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.
16.1R4
À 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.
16.1R4
À partir de junos OS, les commutateurs QFX10000 17.4R1 prennent en charge le mode actif-actif pour le multihébergement EVPN.
15.1F6
Pour mieux utiliser les interfaces logiques dans le multihébergement EVPN en mode actif-veille ou actif-actif, à commencer par les versions 15.1F6 et 17.1R1 de Junos OS 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, d’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).
15.1
À partir de la version 15.1 de Junos OS, Junos OS prend en charge l’aliasing dans un EVPN.
14,1 x 53-D30
À partir de la version 14.1x53-D30 de Junos OS pour les commutateurs QFX5100 et de la version 18.2R1 de Junos OS pour les commutateurs EX4600, ces commutateurs prennent en charge le mode de fonctionnement actif-actif pour le multihébergement EVPN.
14.1R4
À partir des versions 14.1R4, 14.2, 15.1F6 et 16.1R1 de Junos OS, Junos OS prend en charge le mode actif-actif pour le multihébergement EVPN sur les routeurs MX Series.