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 CRB (Centrally Roudging Bridge) utilisant un modèle de dorsale réduite dans les cas suivants :

• Une interface utilise à la fois des configurations de type entreprise et de type 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 un mélange 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 :

• Une dorsale non réduite et aucun VLAN n’est configuré avec une interface locale.

• Une dorsale réduite et certains VLAN sur l’appareil sont configurés sans interface locale, tandis que d’autres sur l’appareil sont configurés en mode entreprise sur les interfaces 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 dans le style entreprise ou fournisseur de services.

Scénarios non pris en charge :

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

• Une dorsale réduite où certains VLAN de l’appareil ne sont configurés sur aucune interface locale, et d’autres VLAN sont configurés en utilisant le style d’un fournisseur de services sur les interfaces CE. La solution de contournement de ce scénario consiste à configurer un vlan-idfichier .

• Une dorsale réduite où certains VLAN de l’appareil ne font partie d’aucune interface, et d’autres sont configurés à l’aide flexible-ethernet-services de l’encapsulation sur plusieurs interfaces logiques, en utilisant le style d’entreprise. La solution de contournement de ce scénario consiste à configurer un vlan-idfichier .

La prise en charge VXLAN sur un Virtual Chassis ou un Virtual Chassis Fabric (VCF) présente les contraintes et recommandations suivantes :

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

• Les commutateurs EX4400 et EX4400 Virtual Chassis autonomes prennent en charge EVPN-VXLAN. Pour les cas d’usage 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’usage 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 centres de données, nous prenons en charge EVPN-VXLAN uniquement sur un Virtual Chassis ou un VCF composé de tous les commutateurs QFX5100, et non sur un autre Virtual Chassis ou VCF mixte ou non mixte. Nous prenons en charge VCF dans les environnements de centre de données EVPN-VXLAN exécutant les versions de Junos OS à partir de 14.1X53-D40 et antérieures à 17.1R1. Toutefois, nous vous déconseillons d’utiliser EVPN-VXLAN sur un Virtual Chassis QFX5100 ou un VCF, car la prise en charge des fonctionnalités n’est égale qu’à celle des commutateurs QFX5100 autonomes exécutant Junos OS version 14.1X53-D40.

  La prise en charge de VCF en général est obsolète à partir de la version 21.4R1 de Junos OS.

• Lorsqu’un Virtual Chassis QFX5100 apprend un adresse MAC sur une interface VXLAN, l’entrée de la table MAC peut prendre jusqu’à 10 à 15 minutes pour vieillir (deux à trois fois l’intervalle de datation par défaut de 5 minutes). Cela se produit lorsque Virtual Chassis apprend une adresse MAC à partir d’un paquet entrant sur un commutateur membre de Virtual Chassis, puis doit transférer ce paquet sur les liens du port Virtual Chassis (VCP) vers un autre commutateur membre du Virtual Chassis en route vers 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 d’ancienneté 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 ce délai supplémentaire dans ce cas.

(QFX5120 commutateurs uniquement) Le trafic tunnelisé via une interface de balise de couche 3 ou une interface IRB orientée vers le cœur est abandonné. Pour éviter cette limitation, vous pouvez configurer un balisage VLAN flexible. Pour plus d’informations, reportez-vous à la section 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 style fournisseur de services, consultez Encapsulation de services Ethernet flexible. Pour plus d’informations sur la configuration des services Ethernet flexibles dans une fabric EVPN-VXLAN, reportez-vous à la section Présentation de 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 style entreprise, de style 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 style fournisseur de services. Le VLAN natif peut être l’un des VLAN de la configuration de type entreprise. Pour plus d’informations sur les configurations de style entreprise et de style fournisseur de services, consultez Encapsulation de services Ethernet flexible.

(Commutateurs QFX5xxx) Dans une structure EVPN-VXLAN, vous ne pouvez pas configurer l’instruction native-vlan-id sur l’interface où 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 du commutateur par défaut et dans les instances de routage VRF MAC (instance-type mac-vrf).

(Commutateurs EX4300-48MP et EX4600) La configuration VXLAN n’est prise en charge que dans l’instance de routage du 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 sous-jacentes VXLAN. Si vous ne souhaitez pas utiliser plusieurs ports de sortie, mais que vous avez besoin de plusieurs sauts suivants VTEP, vous pouvez effectuer l’une des opérations suivantes pour contourner ce problème :

• Placez un routeur entre le commutateur et les VTEP distants afin qu’un seul saut suivant se trouve entre eux.

• Utilisez des interfaces physiques de couche 3 au lieu d’interfaces IRB pour une accessibilité VTEP à distance.

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

Les interfaces IRB (Integrated Routing and Bridging) utilisées dans les réseaux de superposition 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ésencapsulation VXLAN ne peut pas également ê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 utilisant des configurations d’interface de type 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’identificateur de réseau VXLAN (VNI) à 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 du périphérique. À partir de la version 22.2R3-S3 de Junos OS, nous n’avons plus cette contrainte.

Pour plus d’informations sur l’affectation dynamique de VLAN avec un serveur RADIUS, reportez-vous aux sections Authentification 802.1X et Configuration du serveur RADIUS pour l’authentification .

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).

• Il n’est pas possible d’arrêter une interface de couche 2 ou de l’arrêter temporairement en cas de dépassement d’un niveau de storm control.

• Nous ne prenons pas en charge toutes les fonctionnalités STP, MSTP, RSTP ou VSTP (xSTP) avec VXLAN. Toutefois, vous pouvez configurer xSTP en périphérie (port d’accès) pour la prise en charge BPDU bloc sur tronçon. Pour plus de détails , voir Protection BPDU pour les protocoles Spanning-Tree .

Les fonctionnalités de sécurité des ports d’accès telles que les suivantes ne sont pas prises en charge par VXLAN :

• Surveillance DHCP.

• Inspection ARP dynamique.

• Limitation MAC et limitation des mouvements MAC.

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 les équipements qui servent de passerelles VXLAN de couche 2 dans les réseaux overlay à routage central EVPN-VXLAN :

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

  • Commutateurs EX4400 à partir de Junos OS version 21.1R1

  • Commutateurs multi-gigabit EX4400 à partir de Junos OS version 21.2R1

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

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

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

  • Surveillance DHCPv4 et DHCPv6

  • Inspection ARP dynamique (DAI)

  • Inspection par découverte de voisinage (NDI)

  • Protection de source IPv4 et IPv6

  • Protecteur de publicité de routeur (RA)

  Nous prenons en charge ces fonctionnalités uniquement sur les connexions d’interface d’accès à domicile 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 (VXLAN manuel).

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

La réplication des nœuds entrants est prise en charge par EVPN-VXLAN.

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

Si vous configurez une instance de mise en miroir de port pour refléter le trafic sortant d’une interface qui effectue l’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 et des mécanismes de contrôle du pare-feu :

• (commutateurs QFX5100) Les filtres et mécanismes de contrôle de pare-feu 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 entrant sur les interfaces CE.

• (commutateurs QFX5100) Pour les interfaces IRB d’une fabric IP unicouche EVPN-VXLAN, le filtrage et la surveillance du pare-feu ne sont pris en charge qu’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 aux routes entrantes [IRACL].

• (commutateurs QFX5110, QFX5120 et QFX5210) Nous prenons en charge le filtrage et la surveillance d’entrée sur les interfaces VXLAN non roucheminées en tant que listes de contrôle d’accès de port d’entrée [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 sous forme de listes de contrôle d’accès de port de sortie ([EPACL]).

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

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

• Les services Ethernet flexibles, qui sont un type d’encapsulation qui permet à une interface physique de prendre en charge les styles d’interface de fournisseur de services et d’entreprise.

Pour plus d’informations sur ces styles de configuration d’interface, reportez-vous à la section Encapsulation de services Ethernet flexible.

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

• 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 individuel—set vlans vlan-name no-arp-suppression.

Les commutateurs QFX5120-48Y, QFX5120-32C et QFX5200 prennent en charge le routage ECMP (Equal-cost Multi-Path) hiérarchique, ce qui leur permet d’effectuer une résolution de routage à deux niveaux. Cependant, tous les autres commutateurs QFX5xxx ne prennent pas en charge l’ECMP hiérarchique. Par conséquent, lorsqu’un paquet EVPN de type 5 est encapsulé avec un en-tête VXLAN, puis désencapsulé par un commutateur QFX5xxx qui ne prend pas en charge l’ECMP hiérarchique, le commutateur ne peut pas 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 des VLAN configurés sur une superposition de pontage à routage central et une superposition de pontage à routage périphérique, l’adresse MAC IRB et l’adresse MAC de la passerelle virtuelle sur l’interface IRB pour la superposition 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 la superposition de pontage à routage périphérique.

(Commutateurs QFX5110 et QFX5120 uniquement) 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.

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

• (Commutateurs QFX5xxx uniquement) Lors de la configuration de la 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.

• (QFX5120 commutateurs uniquement) Par défaut, les commutateurs QFX5120 allouent 5 Mo d’une 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 après le dépassement de l’espace tampon. Pour éviter que le commutateur n’abandonne des paquets multicast lorsque cette situation se produit, vous pouvez effectuer l’une des opérations suivantes :

  • Utilisez l’instruction shared-buffer de configuration au niveau de la [edit class-of-service] hiérarchie pour réallouer un pourcentage plus élevé de la mémoire tampon partagée pour le trafic multicast. Pour plus d’informations sur le réglage fin 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 débits de trafic configurés et réels pour l’interface. Cette différence est le résultat d’un compteur interne de Storm Control qui quantifie le débit de trafic réel pour l’interface par incréments de 64 kbit/s, par exemple, 64 kbits/s, 128 kbits/s, 192 kbits/s, etc.

(Commutateurs QFX5xxx et EX46xx) Il n’est pas possible d’utiliser la détection de transfert bidirectionnel (BFD) en ligne assistée par matériel avec l’encapsulation VXLAN des paquets BFD. En outre, si vous configurez des appairages BGP de superposition EVPN, utilisez un BFD distribué au lieu d’un BFD en ligne assisté par matériel. Reportez-vous à la section Comprendre comment BFD détecte les défaillances réseau pour plus d’informations sur les différents types de sessions BFD que vous pouvez configurer.

(Commutateurs QFX5xxx et EX46xx) Il n’est pas possible de configurer et d’utiliser MPLS et EVPN-VXLAN en même temps sur le même équipement. Cette contrainte est due au fait que les plates-formes basées sur Broadcom utilisent les mêmes tables matérielles pour stocker les informations sur les tunnels et les ports virtuels 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 de la même interface avec un IRB dans les configurations de type fournisseur de services.

Les MC-LAG ne sont pas pris en charge par 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 (toutes les variantes).

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

• Surveillance DHCP.

• Inspection ARP dynamique.

• Limitation MAC et limitation des mouvements MAC.

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.

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

Lorsque la base de données de saut suivant sur un commutateur QFX10000 inclut des sauts suivants 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 VTEP (virtual tunnel endpoint).

Les interfaces IRB utilisées dans les réseaux overlay 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 les 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 des VLAN configurés sur une superposition de pontage à routage central et une superposition de pontage à routage périphérique, l’adresse MAC IRB et l’adresse MAC de la passerelle virtuelle sur l’interface IRB pour la superposition 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 la superposition de pontage à routage périphérique.

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.

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

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

Vous devez activer la terminaison de tunnel globale 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 périphériques pour bloquer la fermeture de tunnel VXLAN sur des ports spécifiques, mais vous pouvez utiliser la commande suivante pour bloquer la fermeture de tunnel VXLAN pour un port :

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

Les homologues de multihébergement au sein d’un datacenter doivent provenir d’une famille de produits similaire. Pour le multihébergement, il est déconseillé de mélanger les séries ACX avec les séries QFX, les séries PTX ou les séries MX.

(routeurs ACX 7xxx) Les réseaux dotés d’une évolutivité 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, qui est destiné à la mise à 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) Configurez set system packet-forwarding-options system-profile vxlan-extended pour prendre en charge une sous-couche IPv6 EVPN-VXLAN.

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

(routeurs ACX 7xxx) Configurez set system packet-forwarding-options system-profile vxlan-stitching control-word pour prendre en charge les fonctions de mots de contrôle dans un réseau EVPN-VXLAN vers EVPN-MPLS relié. Reportez-vous à l’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 (virtual-gateway-v4-mac) définie par l’utilisateur et une adresse MACvirtual-gateway-v6-mac IPv6 VGA définie par l’utilisateur () seront prises en charge à l’échelle du système.

(routeurs ACX 7xxx) Configurez 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 sous-jacents EVPN-VXLAN.

(routeurs ACX 7xxx) Pour l’assemblage EVPN-VXLAN vers EVPN-MPLS, les équipements 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 CC.

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.