Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Ce qui change

Découvrez les changements apportés à cette version des commutateurs QFX Series.

EVPN

  • État de configuration flow-label pour les services EVPN ELAN : la sortie de la show evpn instance extensive commande affiche désormais l’état opérationnel flow-label et flow-label-static d’un périphérique et non des instances de routage. Un appareil activé flow-label prend en charge les étiquettes de flux traNew options for thesport (FAT) et annonce son soutien à ses voisins. Un équipement flow-label-static activé prend en charge les étiquettes de flux FAT, mais n’annonce pas ses capacités.

  • Sortie mise à jour pour show route table : la sortie pour show route table bgp.evpn.0 affiche désormais le type de TLV de service L2. Auparavant, la sortie affichait le service L3 TLV.

  • Erreur de commit si les distingueurs d’interconnexion et de route locale ont la même valeur : sur les passerelles d’interconnexion de datacenter (DCI) EVPN, si vous configurez un RD d’interconnexion au niveau de la edit routing-instances name protocols evpn interconnect hiérarchie, le RD d’interconnexion doit être différent du RD local dans l’instance de routage. Si vous essayez de configurer la même valeur pour le RD d’interconnexion et le RD local dans une instance de routage, l’équipement applique cette exigence en générant une erreur de validation. Cependant, avec l’assemblage transparent DCI pour les routes EVPN de type 5, vous ne voyez pas l’erreur de validation antérieure à cette version. À partir de cette version, l’appareil génère l’erreur de validation pour appliquer cette condition pour l’assemblage DCI avec des routes de type 5.

    [Voir route-distinguisher.]

  • Nouvelle amélioration « port source udp » introduite dans Junos OS version 22.4R1 pour le ping et le traceroute de superposition : dans les versions de Junos OS antérieures à 22.4R1, vous ne pouviez pas configurer le port source udp dans une opération de superposition ping ou de superposition traceroute. Vous pouvez maintenant configurer cette valeur dans un environnement EVPN-VXLAN à l’aide de hash. L’option hash de configuration remplacera toutes les autres options de hachage-* qui peuvent être utilisées pour déterminer la valeur du port source.

Routage général

  • Suppression des certificats de l’autorité de certification Mozilla (AC) (ACX Series, PTX Series et QFX Series) : pour minimiser les risques de sécurité, Junos OS Evolved n’inclut plus par défaut l’ensemble des certificats racine de Mozilla provenant de divers opérateurs AC. Pour utiliser des images de conteneur Docker à partir d’un registre qui nécessite une authentification TLS, vous devez d’abord enregistrer l’image en tant qu’archive tar sur un équipement distant, puis importer le contenu de l’archive sur l’équipement exécutant Junos OS Evolved.

    Voir [ Exécution d’applications tierces dans des conteneurs.]

  • Lors de l’abonnement au chemin de ressource /junos/system/linecard/environment, le préfixe du chemin diffusé côté collecteur s’affichait sous la forme /junos/linecard/environment. Ce problème est résolu dans Junos OS 23.1R1 et Junos OS Evolved 23.1R1 et le chemin d’abonnement et le chemin d’accès diffusé en continu correspondent à l’affichage /junos/system/linecard/environment.

  • Annoncer les chemins RIB locaux inactifs dans BMP : nous avons introduit une nouvelle instruction bmp-loc-rib-add-path de configuration au niveau de la [edit routing-options bmp] hiérarchie.

    [Voir bmp-loc-rib-add-path.]PR1697520

  • Le processus de gestion des erreurs de liaisons Ethernet (lfmd) s’exécute uniquement lorsque le protocole de gestion des erreurs de liaisons est configuré.

  • Auparavant, si le système ne parvenait pas à installer une interface ou un mécanisme de contrôle hiérarchique, le PFE se bloquait en raison d’une assertion. Maintenant, le système installe une défausse de pare-feu et enregistre un message d’erreur DFW_HALP_ERR_MSG_POLICER_ADD_FAILED. Ce message d’erreur fournit le nom du régulateur affecté et le code d’erreur correspondant. Les mécanismes de contrôle pertinents apparaissent sous l’interface > l’unité > famille > l’interface d’entrées/sorties (ou) > l’unité > famille > les strophes de contrôle hiérarchique d’entrée. PR1701676

  • Informations de débogage multicast ajoutées dans les options EVPN pour demander la commande d’informations système (MX Series, QFX Series) : la sortie de la commande request support information evpn-vxlan CLI inclut désormais des informations supplémentaires pour aider à déboguer les problèmes de multicast EVPN.

    [Voir les informations sur la demande d’assistance.]PR1707139

  • XML dans la get-system-yang-packages balise Modification de la réponse RPC (ACX Series, EX Series, MX Series, PTX Series, QFX Series, SRX Series, vMX et vSRX) : la get-system-yang-packages réponse RPC remplace la xmlproxy-yang-modules balise par la proxy-xml-yang-modules balise dans la sortie XML.

  • Informations de débogage multicast ajoutées dans les options EVPN pour demander la commande d’informations système (MX Series, QFX Series) : la sortie de la commande request support information evpn-vxlan CLI inclut désormais des informations supplémentaires pour aider à déboguer les problèmes de multicast EVPN.

    [Voir les informations sur la demande d’assistance.]

  • Avant cette modification, la sortie d’une tâche show task replication | display xml validate a renvoyé une erreur de la forme "ERROR : Duplicate data element <task-protocol-replication-name>. Grâce à cette modification, la sortie XML est correctement structurée et ne comporte aucune erreur de validation.

  • Avant ce changement, la sortie d’une show task replication logical-system all | display xml validate commande signalait une erreur. Après la modification, la sortie est correctement formatée avec une balise racine « logical-system » et aucune erreur de validation ne se produit.

  • Le processus de gestion des pannes de connectivité (cfmd) s’exécute uniquement lorsque le protocole Ethernet connectivity-fault-management est configuré.

  • Étiquette de l’unité de temps des heures affichée dans la sortie : lorsqu’il n’y a aucune minute dans la sortie de la show system uptime commande, l’étiquette de l’unité de temps des heures s’affiche.

    [Voir Afficher la disponibilité du système.]

  • Dans le passé, inet6flow.0 n’était pas autorisé à être une côte primaire dans un groupe de côtes. À partir de la version 22.3, cela est désormais autorisé.

  • Le nombre d’utilisateurs actifs est défini sous la forme d’une valeur entière numérique dans la sortie de la demande ODL : la sortie de la demande ODL get-system-uptime-information contient des informations pour le nombre d’utilisateurs actifs. Le nombre d’utilisateurs actifs est maintenant défini comme une valeur entière numérique et évite une erreur de type valeur invalide.

    [Voir Afficher la disponibilité du système.]

  • Deux nouvelles alarmes sont ajoutées et peuvent être vues avec MPC11E lorsque des modules optiques 400G-ZR sont utilisés. Modules optiques haute puissance trop chauds : avertissement d’augmentation de la température ambiante du châssis sans aucune action fonctionnelle sur les modules optiques Température trop élevée pour la mise sous tension des modules optiques : les nouveaux modules optiques insérés lorsque la température ambiante du châssis est élevée au-delà du seuil ne sont pas mis sous tension et doivent être réinsérés lorsque la température ambiante se situe dans la plage acceptable

  • Les champs de débit de paquets et de débit d’octets pour les capteurs LSP sur AFT (avec l’ancien chemin) ont été renommés jnx-packet-rate et jnx-byte-rate et sont en parité avec le comportement UKERN. Auparavant, ces champs de taux étaient nommés packetRate et byteRate.

  • Vous pouvez spécifier la valeur minimale et maximale de l’intervalle de temps d’arrêt et de maintien entre 0 et 3600000 millisecondes au niveau de la edit protocols network-isolation group group-name detection hiérarchie.PR1726039

  • Prise en charge du déploiement JDM basé sur podman : à partir de la version 23.2R1 de Junos OS, la segmentation de nœud Junos basée sur un serveur externe prend en charge le déploiement de Juniper Device Manager (JDM) à l’aide de l’outil Pod Manager (podman). Cette modification s’applique aux serveurs exécutant Red Hat Enterprise Linux (RHEL) 9. Dans les versions de Junos antérieures à 23.2R1, la segmentation de nœud Junos prenait en charge RHEL 7.3 qui fournissait le pilote LXC de libvirt (libvirt-lxc) pour déployer des JDM.

Interfaces et châssis

  • À partir de Junos OS version 23.2R1 et Junos OS Evolved version 23.2R1-EVO, la sortie de la commande show chassis power affiche l’état du bloc d’alimentation sur les plates-formes PTX10003 et QFX10003.

    Voir [ show chassis power

API et scripts XML Junos

  • L’attribut xmlns:junos inclut la chaîne de version complète du logiciel (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX et vSRX) : la xmlns:junos chaîne de l’espace de noms dans les réponses XML RPC inclut le numéro de version complet du logiciel, qui est identique à la version émise par la show version commande. Dans les versions antérieures, la chaîne ne contient que des informations partielles sur la xmlns:junos version du logiciel.

  • Possibilité de valider extension-service file la configuration lorsque le fichier d’application n’est pas disponible : lorsque vous définissez l’option optional au niveau de la edit system extension extension-service application file file-name hiérarchie, le système d’exploitation peut valider la configuration même si le fichier n’est pas disponible dans le chemin d’accès au fichier /var/db/scripts/jet .

    [Voir le fichier (JET).]

  • Redémarrage des applications démonisées : utilisez la request extension-service restart-daemonize-app application-name commande pour redémarrer une application démoniaque exécutée sur un équipement Junos. Le redémarrage de l’application peut vous aider à déboguer et à dépanner.

    [Voir request extension-service restart-daemonize-app.]

Gestion et surveillance du réseau

  • Modifications apportées à la show system yang package sortie XML (get-system-yang-packages RPC) (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX et vSRX) : show system yang package la commande et <get-system-yang-packages> RPC incluent les modifications suivantes apportées à la sortie XML :

    • L’élément racine est yang-package-information à la place de yang-pkgs-info.

    • Un yang-package élément entoure chaque ensemble de fichiers de package.

    • La yang-pkg-id balise est renommée en package-id.

    • Si le package ne contient pas de scripts de traduction, la valeur du ou des scripts de traduction (trans-scripts) est none.

  • operator La classe login ne peut pas afficher les fichiers de trace NETCONF qui sont no-world-readable (ACX Series, EX Series, MX Series, PTX Series, QFX Series, SRX Series, vMX et vSRX) : lorsque vous configurez les options de suivi NETCONF au niveau de la edit system services netconf traceoptions hiérarchie et que vous limitez l’accès aux fichiers au propriétaire du fichier en définissant ou en omettant l’instruction no-world-readable (valeur par défaut), les utilisateurs affectés à la operator classe login ne sont pas autorisés à afficher le fichier de suivi.

  • Modifications apportées à l’élément du serveur NETCONF lorsque l’opération rpc-error operation="delete" supprime un objet de configuration inexistant (ACX Series, EX Series, MX Series, PTX Series, QFX Series, SRX Series, vMX et vSRX) : nous avons modifié la rpc-error réponse que le serveur NETCONF renvoie operation="delete" lorsque l’opération edit-config ou load-configuration utilise pour supprimer un élément de configuration absent de la configuration cible. La gravité de l’erreur est erreur au lieu d’avertissement, et l’élément rpc-error inclut les error-tagdata-missing error-tag éléments et error-type application error-type .

  • La réponse du <rpc-error> serveur NETCONF changeait lorsqu’il <load-configuration> était utilisé operation="delete" pour supprimer un objet de configuration inexistant (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX et vSRX)—Dans une version antérieure, nous avons modifié la réponse du serveur NETCONF lorsqu’une <rpc-error> <edit-config> opération operation="delete" ou <load-configuration> utilise pour supprimer un élément de configuration absent de la configuration cible. Nous avons annulé les modifications apportées à la <load-configuration> réponse.

  • La prise en charge du junos:cli-feature Extension YANG (ACX Series, EX Series, MX Series, PTX Series, QFX Series, SRX Series, vMX et vSRX) : l’extension cli-feature YANG identifie certaines propriétés CLI associées à certaines options de commande et instructions de configuration. Les modules Junos YANG qui définissent la configuration ou les RPC incluent l’instruction cli-feature extension, le cas échéant, dans les schémas émis avec les extensions. Cette extension est bénéfique lorsqu’un client consomme des modèles de données YANG, mais que pour certains workflows, le client doit générer des outils basés sur CLI.

    [ Voir Présentation du module YANG des extensions DDL de Junos.]

  • Modifications apportées à la réponse RPC pour <validate> les opérations dans les sessions NETCONF conformes à la RFC (ACX Series, EX Series, MX Series, QFX Series, SRX Series, vMX et vSRX) : lorsque vous configurez l’instruction rfc-compliant au niveau de la [edit system services netconf] hiérarchie, le serveur NETCONF émet uniquement un <ok/> élément ou <rpc-error> en réponse aux <validate> opérations. Dans les versions antérieures, la réponse RPC inclut également l’élément <commit-results> .

  • Amélioration du modèle de données d’événement pour la priorité syslog : le modèle de données d’événement a été amélioré pour inclure le priority paramètre dans les journaux d’événements syslog. Cette mise à jour corrige le calcul et la représentation de la priorité syslog. Auparavant, la priorité syslog était mal calculée, ce qui entraînait des erreurs dans la gestion des messages syslog. PR1715868

Plate-forme et infrastructure

  • La ping host | display xml validate commande valide XML sans erreur (ACX Series, EX Series, MX Series, PTX Series, QFX Series, SRX Series, et vMX) : dans les versions de Junos OS et Junos OS Evolved antérieures à 22.4R2, la commande entraîne une ping host | display xml validate ERREUR CRITIQUE : Incompatibilité du nom de la balise racine. Attendu 'ping-results', j’ai 'run-command'. La commande valide maintenant le XML avec succès sans erreur.

    [Voir ping.]

  • Avant cette modification, les appareils répondaient par défaut uniquement aux requêtes ARP provenant du même sous-réseau. Configurez la nouvelle option de la CLI, « respond-out-of-subnet » au niveau de la [edit system arp] hiérarchie pour permettre à ARP de répondre à une demande provenant d’un autre sous-réseau.

Protocoles de routage

  • Ajout d’une option pour la famille RTC (Route Target constrains) : l’option de nexthop-resolution no-resolution configuration a été ajoutée aux configurations BGP. nexthop-resolution no-resolution family route-target Cet ajout permet aux utilisateurs de désactiver la résolution de saut suivant pour les routes de la famille RTC (AFI 1, SAFI 132) et de les considérer comme utilisables pour le filtrage des routes VPN sans dépendre de l’accessibilité du saut suivant de la route RTC.

    [Voir famille route-cible]. PR1690014

  • Option Configurer conserve-mcast-route-in-pfe sur les équipements de branche de serveur et de branche de bordure de l’OISM dans les fabrics EVPN-VXLAN mises à l’échelle pour éviter l’épuisement des routes multicast (commutateurs QFX5130-32CD et QFX5700) : vous pouvez configurer les commutateurs QFX5130-32CD et QFX5700 en tant qu’équipements de serveur leaf ou de branche de bordure optimisés pour les multicast intersous-réseau (OISM) dans une structure EVPN-VXLAN. Dans les fabrics mises à l’échelle avec de nombreux VLAN, instances EVPN et flux de multicast, vous pouvez constater une perte de trafic de multicast sur ces équipements en raison de la taille limitée des tables de routage de surveillance multicast dans le PFE. Pour éviter ce problème sur les commutateurs QFX5130-32CD et QFX5700 avec OISM dans des environnements mis à l’échelle, nous vous demandons de configurer l’option conserve-mcast-routes-in-pfe dans la edit multicast-snooping-options oism hiérarchie de ces plates-formes. Cette option n’est disponible que sur les commutateurs QFX5130-32CD et QFX5700. Utilisez cette option lorsque vous configurez ces périphériques en tant que périphériques leaf de serveur ou de branche de bordure avec OISM. Ne configurez pas cette option si vous configurez ces périphériques en tant que réplicateurs de réplication assistée (AR) autonomes avec OISM.

    [Voir oism (Multicast Snooping Options.]

  • Avant cette modification, la sortie de la show isis statistics interface <interface_name> | display xml commande utilisait la balise XML « interface-name », ce qui générait une erreur. Avec la modification, la sortie XML utilise la balise « isis-interface-name ».

  • Mise à jour de validation de validation de la configuration TI-LFA et LFA héritée (Junos OS et Junos OS Evolved) : vous pouvez désormais activer TI-LFA et FRR (node-link-protection) hérité dans des instances OSPF distinctes. Le système génère une erreur de validation uniquement si vous activez à la fois TI-LFA et FRR hérité sous la même instance OSPF. Dans ce cas, le commit échoue et déclenche le message suivant : « error : commit failed : (statements constraint check eched) ».

    [Voir Alternative sans boucle indépendante de la topologie avec Segment Routing pour IS-IS et OSPF.]PR1718886

  • Calcul de route multichemin BGP : lors de la configuration de routes multichemin dans l’instance de routage, les routes BGP inactives en raison de la longueur de la liste de clusters sont également considérées comme éligibles pour les calculs de chemins multichemins. Cela améliore la sélection d’itinéraire en incluant plus de chemins potentiels dans votre configuration multichemin.

    [Voir Comprendre la sélection de chemin BGP.]PR1719797

Installation et mise à niveau des logiciels

  • Nouvelles options pour la request system snapshot commande (ACX Series, EX Series, MX Series, QFX Series et SRX Series) : la request system snapshot commande inclut de nouvelles options pour les instantanés sans récupération. Vous pouvez inclure l’option name permettant de spécifier un nom défini par l’utilisateur pour l’instantané, et vous pouvez inclure l’option configuration ou no-configuration pour inclure ou exclure des fichiers de configuration dans l’instantané. Par défaut, l’instantané enregistre les fichiers de configuration, qui incluent le contenu des répertoires /config et /var et certains fichiers SSH.

    [Voir requête capture d’écran système (Junos OS avec FreeBSD mis à niveau).]

Interface utilisateur et configuration

  • L’attribut xmlns:junos inclut la chaîne de version complète du logiciel (ACX Series, EX Series, MX Series, PTX Series, QFX Series, SRX Series, vMX et vSRX) : la xmlns:junos chaîne de l’espace de noms dans les réponses XML RPC inclut le numéro de version complet du logiciel, qui est identique à la version émise par la show version commande. Dans les versions antérieures, la chaîne ne contient que des informations partielles sur la xmlns:junos version du logiciel.

    [Voir la présentation des classes de connexion

  • Mise à jour de la configuration de la mise en miroir des ports : les plages d’interfaces ne sont plus prises en charge dans les groupes de configuration pour la création d’analyseurs. Si vous essayez d’utiliser une plage d’interfaces dans un groupe de configuration, vous rencontrerez une erreur indiquant un type d’interface non valide. De plus, les plages d’interfaces ou les listes d’interfaces ne peuvent pas être configurées avec ce paramètre. Cette modification garantit une configuration précise et sans erreur en exigeant la spécification d’interfaces individuelles plutôt que de plages, améliorant ainsi la précision et la fiabilité des configurations de mise en miroir des ports. PR1728883

VPN

  • Amélioration de la configuration du site émetteur MVPN : les sites émetteurs MVPN (réseau privé virtuel multicast) configurés avec un tunnel IR (réplication entrante) envoient des routes de type 1 avec l’étiquette 0. Cela signifie que les PE distants n’ajoutent pas la route de type 1 en tant que branche du tunnel, mais ajoutent tout de même le PE du site expéditeur en tant que voisin MVPN. Cela garantit que le trafic du PE du site expéditeur n’est pas abandonné par les PE distants en raison d’un voisin MVPN inconnu. Toutefois, comme le PE du site émetteur envoie l’étiquette 0, les PE distants n’ajouteront pas le PE du site expéditeur en tant que leaf et le trafic du PE distant ne sera pas répliqué sur ce PE, ce qui garantit le fonctionnement du site émetteur. PR1711769