Contraintes VXLAN sur les équipements EX Series, QFX Series, PTX Series et ACX Series

(Commutateurs QFX5130-32CD et QFX5700) Nous ne prenons pas en charge une architecture de pontage à routage central (CRB) utilisant un modèle de cœur de réseau réduit lorsque :

• Une interface utilise des configurations de type entreprise et fournisseur de services au niveau de la edit interfaces interface-name hiérarchie.

• Plusieurs ports d’accès sur le même domaine de pont VXLAN utilisent une combinaison de styles d’entreprise et de fournisseur de services.

Configuration de style entreprise

Configuration de type fournisseur de services

Flexible Ethernet Services Configuration

Scénarios pris en charge :

• Un cœur non réduit et aucun VLAN sont configurés avec une interface locale.

• Un dorsale réduit et certains VLAN de l'appareil sont configurés sans interface locale, tandis que d'autres VLAN de l'appareil sont configurés de style entreprise sur des interfaces orientées CE.

• Une dorsale réduite et tous les VLAN de l'appareil sont configurés avec flexible-ethernet-services une encapsulation sur une interface physique, tandis que plusieurs interfaces logiques sont configurées avec un style d'entreprise ou de fournisseur de services.

Scénarios non pris en charge :

• Un dorsale réduit et toute interface locale sur l'équipement incluent tous les VLAN configurés. La solution de contournement pour ce scénario consiste à utiliser flexible-ethernet-services l’encapsulation sur l’interface physique.

• Dorsale réduite où certains VLAN de l'appareil ne sont configurés sur aucune interface locale et d'autres sont configurés à l'aide du style fournisseur de services sur des interfaces orientées CE. La solution pour ce scénario consiste à configurer un vlan-idfichier .

• Un cœur de réseau réduit où certains VLAN de l'appareil ne font partie d'aucune interface, et certains VLAN sont configurés à l'aide flexible-ethernet-services de l'encapsulation sur plusieurs interfaces logiques, dans le style de l'entreprise. La solution pour ce scénario consiste à configurer un vlan-idfichier .

La prise en charge de VXLAN sur un Virtual Chassis ou une Virtual Chassis Fabric (VCF) s’accompagne des contraintes et recommandations suivantes :

• Nous prenons en charge EVPN-VXLAN sur un Virtual Chassis EX4300-48MP uniquement dans les réseaux de campus.

• Les commutateurs autonomes EX4400 et EX4400 Virtual Chassis prennent en charge EVPN-VXLAN. Pour les cas d’utilisation de multihébergement, les hôtes peuvent être multihébergés sur des commutateurs EX4400 autonomes, mais nous ne prenons pas en charge le multihébergement d’un hôte avec des interfaces ESI-LAG vers EX4400 Virtual Chassis.

• Les commutateurs autonomes EX4100 (EX4100 et EX4100-F) et EX4100 Virtual Chassis (EX4100 et EX4100-F) prennent en charge EVPN-VXLAN. Pour les cas d'utilisation de multihébergement, les hôtes peuvent être multihébergés sur des commutateurs EX4100 autonomes, mais nous ne prenons pas en charge le multihébergement d'un hôte avec des interfaces ESI-LAG vers EX4100 Virtual Chassis.

• Dans les réseaux de datacenter, nous prenons en charge EVPN-VXLAN uniquement sur un Virtual Chassis ou VCF composé de commutateurs QFX5100, et pas sur un autre Virtual Chassis ou VCF mixte ou non. Nous prenons en charge VCF dans les environnements de datacenter EVPN-VXLAN exécutant les versions de Junos OS à partir de 14.1X53-D40 et antérieures à 17.1R1. Cependant, nous vous déconseillons d'utiliser EVPN-VXLAN sur un Virtual Chassis ou un VCF QFX5100, car la prise en charge des fonctionnalités est identique à celle des commutateurs autonomes QFX5100 exécutant Junos OS version 14.1X53-D40.

  Nous avons déconseillé la prise en charge de VCF en général à partir de Junos OS version 21.4R1.

• Lorsqu’un Virtual Chassis QFX5100 apprend une adresse MAC sur une interface VXLAN, l’entrée de la table MAC peut prendre jusqu’à 10 à 15 minutes pour expirer (deux à trois fois l’intervalle de vieillissement par défaut de 5 minutes). Cela se produit lorsque le Virtual Chassis apprend une adresse MAC à partir d’un paquet entrant sur un commutateur membre du Virtual Chassis, puis doit transférer ce paquet sur les liens du port Virtual Chassis (VCP) à un autre commutateur membre du Virtual Chassis sur le chemin de sa destination. Le Virtual Chassis marque l’adresse MAC telle qu’elle apparaît à nouveau sur le deuxième commutateur membre, de sorte que l’adresse MAC peut ne pas vieillir pendant un ou deux intervalles de vieillissement supplémentaires au-delà du premier. L’apprentissage MAC ne peut pas être désactivé sur les interfaces VXLAN uniquement au niveau du deuxième commutateur membre de Virtual Chassis, vous ne pouvez donc pas éviter le délai supplémentaire dans ce cas.

(Commutateurs QFX5120 uniquement) Le trafic tunnelisé via une interface centrale avec balisage de couche 3 ou une interface IRB est abandonné. Pour éviter cette limitation, vous pouvez configurer un balisage VLAN flexible. Pour plus d’informations, consultez Présentation des VXLAN.

(QFX5110 et QFX5120) Si vous configurez une interface de style entreprise avec une encapsulation flexible des services Ethernet, l’équipement abandonne les paquets encapsulés VXLAN de couche 2 en transit sur cette interface. Pour contourner ce problème, configurez l’interface dans le style fournisseur de services au lieu d’utiliser le style entreprise. Pour plus d’informations sur les configurations de style entreprise et de type fournisseur de services, consultez Encapsulation flexible des services Ethernet. Pour obtenir une vue d’ensemble de la configuration de services Ethernet flexibles dans une fabric EVPN-VXLAN, reportez-vous à la section Comprendre la prise en charge des services Ethernet flexibles avec EVPN-VXLAN.

(Commutateurs QFX5110 et QFX5120) Dans les fabrics EVPN-VXLAN, nous ne prenons pas en charge les configurations de type entreprise, fournisseur de services et VLAN natif sur la même interface physique si le VLAN natif est identique à l'un des VLAN de la configuration de type fournisseur de services. Le VLAN natif peut être l’un des VLAN d’une configuration de style entreprise. Pour plus d’informations sur les configurations de style entreprise et de type fournisseur de services, consultez Encapsulation flexible des services Ethernet.

(Commutateurs QFX5xxx) Dans une fabric EVPN-VXLAN, vous ne pouvez pas configurer l’instruction native-vlan-id sur la même interface que celle sur laquelle vous activez la traduction VLAN avec l’instruction vlan-rewrite .

(Commutateurs QFX5100, QFX5110, QFX5200 et QFX5210) Nous prenons en charge la configuration VXLAN dans l’instance de routage de commutateur par défaut et dans les instances de routage VRF MAC (instance-type mac-vrf).

(Commutateurs EX4300-48MP et EX4600) Nous prenons en charge la configuration VXLAN uniquement dans l’instance de routage de commutateur par défaut.

(commutateurs QFX5100, QFX5200, QFX5210, EX4300-48MP et EX4600) Le routage du trafic entre différents VXLAN n’est pas pris en charge.

(Commutateurs QFX5100, QFX5110, QFX5120, EX4600 et EX4650) Ces commutateurs ne prennent en charge qu’un seul saut suivant VTEP sur les interfaces IRB underlay VXLAN. Si vous ne souhaitez pas utiliser plusieurs ports de sortie, mais que vous avez besoin de plusieurs VTEP au saut suivant, vous pouvez utiliser l’une des méthodes suivantes :

• Placez un routeur entre le commutateur et les VTEP distants afin qu’il n’y ait qu’un seul saut suivant entre eux.

• Utilisez des interfaces physiques de couche 3 au lieu d’interfaces IRB pour atteindre les VTEP à distance.

(Commutateurs QFX5110) Par défaut, le routage du trafic entre une interface VXLAN et une interface logique de couche 3 (par exemple, une interface configurée avec la commande) n’est set interfaces interface-name unit logical-unit-number family inet address ip-address/prefix-length pas activé. Si cette fonctionnalité de routage est requise dans votre réseau EVPN-VXLAN, vous pouvez effectuer une configuration supplémentaire pour la faire fonctionner. Pour plus d’informations, consultez Présentation de l’interopérabilité des VXLAN et des interfaces logiques de couche 3.

Les interfaces IRB (Integrated Routing and Bridging) utilisées dans les réseaux overlay EVPN-VXLAN ne prennent pas en charge le protocole de routage IS-IS.

(Commutateurs QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4300-48MP et EX4600) Une interface physique ne peut pas être membre d’un VLAN et d’un VXLAN. En d’autres termes, une interface qui effectue l’encapsulation et la déencapsulation VXLAN ne peut pas non plus être membre d’un VLAN. Par exemple, si un VLAN mappé à un VXLAN est membre du port trunk xe-0/0/0, tout autre VLAN membre de xe-0/0/0 doit également être affecté à un VXLAN.

(commutateurs QFX5110, QFX5120, EX4100 et EX4400) Nous ne prenons pas en charge les interfaces logiques VXLAN et non VXLAN sur la même interface physique en utilisant des configurations d’interface de style entreprise.

(Commutateurs QFX5120, EX4100, EX4300-48MP, EX4400 et EX4650) Avec l’authentification 802.1X pour le trafic VXLAN sur un port d’accès, lors de l’authentification, le serveur RADIUS bascule dynamiquement le trafic du VLAN d’origine vers un VLAN dynamique que vous configurez en tant que VLAN compatible VXLAN. Un VLAN compatible VXLAN est un VLAN pour lequel vous configurez un mappage d’identifiant de réseau (VNI) VXLAN à l’aide de l’instruction vxlan vni vni de la [edit vlans vlan-name] hiérarchie.

Lorsque vous configurez le VLAN dynamique 802.1X et son mappage VNI correspondant, vous devez également configurer le VLAN d’origine en tant que VLAN compatible VXLAN avec un mappage VNI. Si vous ne configurez pas explicitement le port en tant que membre d'un VLAN, le port utilise le VLAN par défaut. Dans ce cas, vous devez configurer le VLAN par défaut en tant que VLAN compatible VXLAN avec un mappage VNI.

De plus, dans les versions antérieures à Junos OS version 22.2R3-S3, lorsqu’un VLAN dynamique est affecté à un port, ce VLAN doit déjà avoir été configuré statiquement sur un autre port de l’équipement. À partir de la version 22.2R3-S3 de Junos OS, nous n’avons plus cette contrainte.

Pour plus d’informations sur l’attribution dynamique de VLAN avec un serveur RADIUS, reportez-vous à Authentification 802.1X et Configuration du serveur RADIUS .

Les groupes d’agrégation de liens multichâssis (MC-LAG) ne sont pas pris en charge avec VXLAN.

La fragmentation et la défragmentation IP ne sont pas prises en charge du côté de la couche 3.

Les fonctionnalités suivantes ne sont pas prises en charge du côté de la couche 2 :

• (commutateurs QFX5100, QFX5200, QFX5210, EX4300-48MP et EX4600) Surveillance IGMP avec EVPN-VXLAN.

• RTG (Redundant Trunk Groups).

• La possibilité d’arrêter une interface de couche 2 ou de l’arrêter temporairement lorsqu’un niveau de storm control est dépassé n’est pas prise en charge.

• Nous ne prenons pas en charge toutes les fonctionnalités STP, MSTP, RSTP ou VSTP (xSTP) avec VXLAN. Toutefois, vous pouvez configurer xSTP on Edge (port d’accès) pour la prise en charge du blocage sur périphérie BPDU. Pour plus d’informations, reportez-vous à la section Protection BPDU pour les protocoles Spanning-Tree .

Les fonctionnalités de sécurité des ports d’accès, notamment les suivantes, ne sont pas prises en charge avec le VXLAN :

• Surveillance DHCP.

• Inspection ARP dynamique.

• Limitation MAC et limitation MAC des déplacements.

Voici quelques exceptions :

• La limitation MAC est prise en charge sur les interfaces gérées par OVSDB dans un environnement OVSDB-VXLAN avec des contrôleurs Contrail. Pour plus d’informations, consultez Fonctionnalités prises en charge sur les interfaces gérées par OVSDB.

• Sur ces équipements servant de passerelles VXLAN L2 dans les réseaux superposés de pontage central EVPN-VXLAN :

  • Commutateurs multi-gigabits EX4300 à partir de Junos OS version 19.4R1

  • Commutateurs EX4400 à partir de la version 21.1R1 de Junos OS

  • Commutateurs multigigabits EX4400 à partir de Junos OS version 21.2R1

  • Commutateurs EX4100 et EX4100-F à partir de Junos OS version 22.3R1

  • Commutateurs EX4100 multi-gigabits à partir de Junos OS version 22.3R1

  nous prenons en charge les fonctionnalités de sécurité d’accès suivantes sur les interfaces côté accès de couche 2 associées aux VLAN mappés par VXLAN :

  • Surveillance DHCPv4 et DHCPv6

  • Inspection ARP dynamique (DAI)

  • Inspection par détection de voisins (NDI)

  • Protection des sources IPv4 et IPv6

  • Protection des annonces de routeurs (RA)

  Nous ne prenons en charge ces fonctionnalités que sur les connexions d’interface d’accès à homing unique.

La réplication de nœud entrant n’est pas prise en charge dans les cas suivants :

• Lorsque PIM est utilisé pour le plan de contrôle (manuel VXLAN).

• Lorsqu’un contrôleur SDN est utilisé pour le plan de contrôle (OVSDB-VXLAN).

La réplication de nœud entrant est prise en charge avec EVPN-VXLAN.

Les protocoles PIM-BIDIR et PIM-SSM ne sont pas pris en charge avec les VXLAN.

Si vous configurez une instance de mise en miroir des ports pour mettre en miroir le trafic sortant d’une interface qui effectue une encapsulation VXLAN, les adresses MAC source et de destination des paquets mis en miroir ne sont pas valides. Le trafic VXLAN d’origine n’est pas affecté.

(Commutateurs QFX5110 uniquement) Les filtres de pare-feu VLAN ne sont pas pris en charge sur les interfaces IRB sur lesquelles EVPN-VXLAN est activé.

(Commutateurs EX4650 et QFX5000 Series) Prise en charge des filtres de pare-feu et des mécanismes de contrôle :

• (Commutateurs QFX5100) Les filtres de pare-feu et les mécanismes de contrôle ne sont pas pris en charge sur le trafic de transit sur lequel EVPN-VXLAN est activé. Ils ne sont pris en charge que dans le sens d’entrée sur les interfaces orientées CE.

• (Commutateurs QFX5100) Pour les interfaces IRB dans une fabric IP monocouche EVPN-VXLAN, le filtrage et le contrôle du pare-feu sont pris en charge uniquement au point d’entrée des trames non encapsulées acheminées via l’interface IRB.

• (commutateurs EX4650, QFX5110 et QFX5120) Nous prenons en charge le filtrage et le contrôle d’entrée pour les interfaces VXLAN routées (interfaces IRB) en tant que listes de contrôle d’accès [IRACL] de route entrante.

• (commutateurs QFX5110, QFX5120 et QFX5210) Nous prenons en charge le filtrage et le contrôle entrants sur les interfaces VXLAN non routées en tant que listes de contrôle d’accès de port entrant [IPACL]).

• (Commutateurs QFX5110 et QFX5120) La prise en charge du filtrage et du contrôle sur les interfaces VXLAN non routées s’étend à la direction de sortie en tant que ACL de port de sortie ([EPACL]).

(Commutateurs EX4300-48MP uniquement) Les styles de configuration d’interface suivants ne sont pas pris en charge :

• Style fournisseur de services, où une interface physique est divisée en plusieurs interfaces logiques, chacune dédiée à un VLAN client particulier. Le extended-vlan-bridge type d’encapsulation est configuré sur l’interface physique.

• Services Ethernet flexibles, qui sont un type d’encapsulation permettant à une interface physique de prendre en charge les styles de configuration d’interface des fournisseurs de services et des entreprises.

Pour plus d’informations sur ces styles de configuration d’interface, consultez Encapsulation flexible des services Ethernet.

(Commutateurs QFX5100 uniquement) À l’aide de l’instruction no-arp-suppression de configuration, vous pouvez désactiver la suppression des demandes ARP sur un ou plusieurs VLAN spécifiés. Toutefois, à partir de la version 18.4R3 de Junos OS, vous devez désactiver cette fonctionnalité sur tous les VLAN. Pour ce faire, vous pouvez utiliser l’une de ces options de configuration :

• Utilisez une commande batch pour désactiver la fonctionnalité sur tous les VLAN.set groups group-name vlans * no-arp-suppression Avec cette commande, nous utilisons l’astérisque (*) comme caractère générique qui spécifie tous les VLAN.

• Utilisez une commande pour désactiver la fonctionnalité sur chaque VLAN.set vlans vlan-name no-arp-suppression

Les commutateurs QFX5120-48Y, QFX5120-32C et QFX5200 prennent en charge la multichemin hiérarchique à coût égal (ECMP), ce qui permet à ces commutateurs d’effectuer une résolution de route à deux niveaux. Cependant, tous les autres commutateurs QFX5xxx ne prennent pas en charge ECMP hiérarchique. Par conséquent, lorsqu’un paquet EVPN Type-5 est encapsulé avec un en-tête VXLAN, puis désencapsulé par un commutateur QFX5xxx qui ne prend pas en charge ECMP hiérarchique, le commutateur est incapable de résoudre les deux niveaux de routes qui se trouvaient dans le paquet interne. Le commutateur abandonne alors le paquet.

(Commutateurs QFX5100, QFX5110, QFX5120, QFX5200 et QFX5210) Lorsque vous configurez les interfaces IRB sur un périphérique qui prend en charge simultanément les VLAN configurés à la fois sur un overlay de pontage à routage central et un overlay de pontage à routage périphérique, l’adresse MAC IRB et l’adresse MAC de la passerelle virtuelle sur l’interface IRB pour le overlay de pontage à routage central doivent être différentes de l’adresse MAC IRB et de l’adresse MAC de la passerelle virtuelle sur l’interface IRB pour le overlay de pontage à routage Edge.

Les contraintes suivantes s’appliquent à la fois aux VXLAN et aux VLAN.

• (Commutateurs QFX5xxx uniquement) Lors de la configuration d’une fuite de route entre les instances VRF (Virtual Routing and Forwarding), vous devez spécifier chaque préfixe avec un masque de sous-réseau égal ou supérieur à /16 pour les préfixes IPv4 ou égal ou supérieur à /64 pour les préfixes IPv6. Si un masque de sous-réseau que vous spécifiez ne répond pas à ces paramètres, les routes spécifiées ne seront pas divulguées.

• (Commutateurs QFX5120 uniquement) Par défaut, les commutateurs QFX5120 allouent 5 Mo de mémoire tampon partagée pour absorber les rafales de trafic multicast. Si une rafale de trafic multicast dépasse 5 Mo, le commutateur abandonne les paquets qu’il reçoit une fois l’espace tampon dépassé. Pour empêcher le commutateur de perdre des paquets de multicast lorsque cette situation se produit, vous pouvez effectuer l’une des opérations suivantes :

  • Utilisez l’instruction shared-buffer configuration au niveau de la [edit class-of-service] hiérarchie pour réaffecter un pourcentage plus élevé de la mémoire tampon partagée au trafic de multicast. Pour plus d’informations sur l’optimisation d’une mémoire tampon partagée, consultez Présentation de la configuration de la mémoire tampon CoS.

  • Sur le commutateur Juniper Networks d’où proviennent les rafales de trafic multicast, appliquez un modélisateur sur la liaison de sortie.

• (Commutateurs QFX5xxx uniquement) Si vous avez activé le storm control sur une interface, vous remarquerez peut-être une différence significative entre les taux de trafic configurés et réels de l’interface. Cette différence est le résultat d’un compteur de storm control interne qui quantifie le débit de trafic réel de l’interface par incréments de 64 kbit/s, par exemple, 64 kbit/s, 128 kbit/s, 192 kbit/s, etc.

(Commutateurs QFX5xxx et EX46xx) Vous ne pouvez pas utiliser la détection de transfert bidirectionnelle (BFD) en ligne assistée par le matériel avec encapsulation VXLAN des paquets BFD. De plus, si vous configurez des appairages BGP overlay EVPN, utilisez un BFD distribué au lieu d’un BFD en ligne assisté par le matériel. Voir Comprendre comment BFD détecte les défaillances réseau pour plus de détails sur les différents types de sessions BFD que vous pouvez configurer.

(commutateurs QFX5130-32CD, QFX5130E-32CD, QFX5130-48C, QFX5700 et QFX5700E) À partir des versions 25.2X100-D10 et 25.4R1 de Junos OS Evolved, nous prenons en charge le BFD en ligne assisté par le matériel avec des minuteries de 100 x 3 millisecondes sur des tunnels VXLAN uniquement sur les plates-formes répertoriées. Ce support s’applique à :

• BFD à sauts multiples IPv4 ou IPv6 L2 et L3 de type 2 avec ECMP ou VTEP multirésidents avec les exigences suivantes :

  • Minuteries de 100 x 3 ms

  • Appairage BGP superposé entre bouclages

  • BFD configuré sur les sessions BGP overlay

• BFD à sauts multiples IPv4 ou IPv6 de type 5 avec ECMP

• Instances de routage de type 5 pur

(Commutateurs QFX5xxx et EX46xx) Nous ne prenons pas en charge la configuration et l'utilisation simultanées de MPLS et EVPN-VXLAN sur le même appareil. Cette contrainte s’explique par le fait que les plates-formes Broadcom utilisent les mêmes tables matérielles pour stocker les informations de tunnel et de port virtuel utilisées par les ensembles de fonctionnalités MPLS et VXLAN.

De plus, vous ne pouvez pas utiliser un underlay MPLS avec EVPN et un overlay VXLAN ; il s’agit d’une limitation matérielle de Broadcom.

(Commutateurs QFX5xxx et EX46xx) Nous ne prenons pas en charge les interfaces L3 balisées et les domaines de pont L2 en tant que sous-unités d’une même interface avec un IRB dans des configurations de type fournisseur de services.

Les MC-LAG ne sont pas pris en charge avec VXLAN.

La fragmentation IP n’est pas prise en charge du côté de la couche 3.

Les fonctionnalités suivantes ne sont pas prises en charge du côté de la couche 2 :

• Surveillance IGMP avec EVPN-VXLAN dans les versions de Junos OS antérieures à la version 17.2R1 de Junos OS.

• STP (toute variante).

Les fonctionnalités de sécurité des ports d’accès ne sont pas prises en charge avec VXLAN. Par exemple, les fonctionnalités suivantes ne sont pas prises en charge :

• Surveillance DHCP.

• Inspection ARP dynamique.

• Limitation MAC et limitation MAC des déplacements.

La réplication de nœud entrant n’est pas prise en charge lorsqu’un contrôleur SDN est utilisé pour le plan de contrôle (OVSDB-VXLAN). La réplication de nœud entrant est prise en charge pour EVPN-VXLAN.

Les commutateurs QFX10000 déployés dans un environnement EVPN-VXLAN ne prennent pas en charge un réseau physique sous-jacent IPv6.

Lorsque la base de données du saut suivant d’un commutateur QFX10000 inclut des sauts suivants à la fois pour le réseau sous-jacent et le réseau de superposition EVPN-VXLAN, le saut suivant vers un homologue VXLAN ne peut pas être un identifiant de segment Ethernet (ESI) ou une interface de point de terminaison de tunnel virtuel (VTEP).

Les interfaces IRB utilisées dans les réseaux de superposition EVPN-VXLAN ne prennent pas en charge le protocole de routage IS-IS.

Filtres de pare-feu VLAN appliqués aux interfaces IRB sur lesquelles EVPN-VXLAN est activé.

Le transfert basé sur des filtres (FBF) n’est pas pris en charge sur les interfaces IRB utilisées dans un environnement EVPN-VXLAN.

Les commutateurs QFX10002, QFX10008 et QFX10016 ne prennent pas en charge la mise en miroir et l’analyse des ports lorsque EVPN-VXLAN est également configuré.

Lorsque vous configurez les interfaces IRB sur un périphérique qui prend en charge simultanément les VLAN configurés à la fois sur un overlay de pontage à routage central et un overlay de pontage à routage périphérique, l’adresse MAC IRB et l’adresse MAC de la passerelle virtuelle sur l’interface IRB pour le overlay de pontage à routage central doivent être différentes de l’adresse MAC IRB et de l’adresse MAC de la passerelle virtuelle sur l’interface IRB pour le overlay de pontage à routage Edge.

Dans un environnement EVPN-VXLAN, nous ne prenons pas en charge la configuration des passerelles anycast avec l' default-gateway instruction et l'instruction sur les advertise liaisons participant au même segment Ethernet (ES).

Vous devez configurer les règles de réécriture de la classe de service (CoS) pour que les bits DSCP (Differentiated Services Code Point) soient copiés de l’en-tête interne du VXLAN vers l’en-tête du VXLAN externe.

Vous devez activer globalement la terminaison de tunnel sur les équipements PTX10K Series dans les déploiements EVPN-VXLAN, comme suit :

set forwarding-options tunnel-termination

Vous ne pouvez pas utiliser de filtre de pare-feu sur ces appareils pour bloquer la terminaison du tunnel VXLAN sur des ports spécifiques, mais vous pouvez utiliser la commande suivante pour bloquer la terminaison du tunnel VXLAN pour un port :

set interfaces logical-interface-name unit n family inet/inet6 no-tunnel-termination

Les homologues multihébergement d’un datacenter doivent appartenir à une famille de produits similaire. Il est déconseillé de mélanger les ACX Series avec les QFX Series, PTX Series ou MX Series pour le multihébergement.

(routeurs ACX 7xxx) Les réseaux avec des échelles MAC et IP doivent être configurés set system packet-forwarding-options hw-db-profile cloud-metro. La valeur par défaut est lean-edge, ce qui est destiné à l’échelle IP.

(routeurs ACX 7xxx) L’équilibrage de charge n’est pas activé par défaut. Voici un exemple de configuration. Configurez uniquement les options nécessaires à votre déploiement.

(routeurs ACX 7xxx) Configuration set system packet-forwarding-options system-profile vxlan-extended pour prendre en charge un underlay IPv6 EVPN-VXLAN.

(routeurs ACX 7xxx) Configurez set system packet-forwarding-options system-profile vxlan-stitching pour prendre en charge l’assemblage EVPN-VLXAN à EVPN-VXLAN, et l’assemblage EVPN-VXLAN à EVPN-MPLS avec no-control-word prise en charge.

(routeurs ACX 7xxx) Configuration set system packet-forwarding-options system-profile vxlan-stitching control-word configurée pour prendre en charge les fonctions de mot de contrôle dans un réseau EVPN-VXLAN à EVPN-MPLS assemblé. Reportez-vous à la section Assemblage vxlan pour plus d’informations sur la prise en charge des mots de contrôle.

(routeurs ACX 7xxx) Une adresse de passerelle virtuelle (VGA) IPv4 MAC définie par l’utilisateur (virtual-gateway-v4-mac) et un MAC IPv6 VGA défini par l’utilisateur (virtual-gateway-v6-mac) seront prises en charge dans tout le système.

(routeurs ACX 7xxx) Configuration set system packet-forwarding-options no-ip-tos-rewrite pour propager les informations DSCP de la charge utile à l’en-tête du routeur VXLAN pendant l’encapsulation VXLAN.

(routeurs ACX 7xxx) La configuration ESI en mode multihébergement EVPN est prise en charge par périphérique d’interface physique ou par interface LAG uniquement.

(routeurs ACX 7xxx) Les interfaces IRB ne sont pas prises en charge en tant que réseaux underlay EVPN-VXLAN.

(routeurs ACX 7xxx) Pour l'assemblage EVPN-VXLAN à EVPN-MPLS, les périphériques qui ne prennent pas en charge le transfert basé sur des étiquettes de domaine de pont ne seront pas compatibles avec les équipements ACX Series en tant que GW homologues de datacenter.

Si vous configurez plusieurs sous-unités sur un port avec un ESI, nous ne prenons pas en charge l'opération de désactivation (set interfaces logical-interface-name unit n disable) sur ces interfaces logiques.

Dans une superposition EVPN-VXLAN, nous ne prenons pas en charge l'exécution d'un protocole de routage sur une interface IRB qui se trouve dans une instance de routage par défaut (default.inet.0). Nous vous recommandons plutôt d’inclure l’interface IRB dans une instance de routage de type vrf.