Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

L'

  • Choix DF basé sur les préférences pour EVPN (QFX5110, QFX5120-32C, QFX5120-48T, QFX5120-48Y, QFX5200, QFX5210, QFX10002, QFX10002-60C, QFX10008 et QFX10016) : à partir de Junos OS version 22.1R1, vous pouvez permettre aux commutateurs QFX Series de sélectionner un redirecteur désigné (DF) en fonction de la valeur de préférence. Les périphériques PE (Provider Edge) envoient la valeur de préférence aux autres périphériques PE multirésidents à l’aide de l’attribut communauté étendue dans la publication de route EVPN Type 4.

    Pour activer l’élection DF basée sur les préférences, incluez l’instruction df-election-type au niveau de la [edit interfaces interface-name esi] hiérarchie. Vous pouvez également activer le choix DF en fonction de la valeur de préférence la plus basse. Pour ce faire, incluez l’instruction designated-forwarder-preference-least au niveau de la [edit routing-instance routing-instance-name protocols evpn] hiérarchie.

    [Voir Élection du transitaire désigné.]

  • Prise en charge du filtrage et de la capacité de contrôle EVPN/VXLAN sur une sous-couche IPv6 pure (QFX10002-60C, QFX10002, QFX10008 et QFX10016) : à partir de Junos OS version 22.1, Juniper prend en charge le transfert basé sur des filtres pour IPV4 et IPV6 sur une topologie EVPN/VXLAN, avec une surveillance par pare-feu supplémentaire des paquets IPV6 une fois le tunnel de transfert terminé.

    [Voir Routage du trafic de données IPv6 via un réseau EVPN-VXLAN avec une sous-couche IPv4.]

  • Zéro perte de trafic lorsque vous ajoutez de nouvelles interfaces membres Saut suivant de sous-couche ECMP (QFX10002-60C, QFX10002, QFX10008 et QFX10016) : à partir de Junos OS version 22.1R1, sur les tunnels VXLAN configurés sur des sous-couches ECMP, il n’y a aucune perte de trafic lorsque vous ajoutez de nouveaux membres au saut suivant ECMP sous-jacent. Auparavant, sur les périphériques FPC uniques, lorsque vous ajoutiez un membre à l’unilist (un pointeur vers une liste de sauts suivants unicast), le nouveau membre était installé au début de la liste pour le pipeline de sortie. Dans le pipeline d’entrée, cependant, l’uniliste indiquait toujours l’ancien membre, mais utilisait le numéro d’index du nouveau membre. Le trafic quitterait alors l’appareil en utilisant l’ancien membre, mais avec le numéro d’index du nouveau membre. Étant donné que l’adresse MAC ne correspondait pas à l’appareil à partir duquel elle a été envoyée, l’appareil suivant supprimait le trafic. Pour résoudre ce problème, vous ajoutez maintenant de nouveaux membres à la fin de la liste afin que les index existants ne soient pas affectés.

    Auparavant, sur plusieurs appareils FPC, chaque FPC mettait à jour ses pipelines d’entrée et de sortie indépendamment et n’était pas synchronisé les uns avec les autres. Par exemple, si vous aviez deux membres dans l’unilist, puis que vous ajoutiez un troisième membre, le troisième membre avait son port sur FPC2. Le correctif pour les périphériques FPC unique n’aide pas dans cette situation. Au lieu de cela, vous pouvez configurer un minuteur de délai, ce qui vous permet de différer le remplissage du pipeline d’entrée pendant une durée prédéterminée tout en programmant le pipeline de sortie. Lorsque le minuteur expire, vous pouvez programmer le pipeline d’entrée.

    [Voir la présentation de l’EVPN.]