Principales différences entre Junos OS Evolved et Junos OS

Différences de système

Le concept de système dans Junos OS Evolved est différent de Junos OS. Junos OS utilise un modèle centré sur le moteur de routage, où le système fait généralement référence à un moteur de routage. Cependant, Junos OS Evolved utilise un modèle basé sur les nœuds, où le système fait référence à tous les nœuds, y compris les moteurs de routage, les concentrateurs PIC flexibles (FPC), etc. Dans Junos OS Evolved, un nœud est un composant capable d’exécuter le noyau Linux et les applications Junos OS Evolved. Tous les nœuds sont considérés comme des nœuds de calcul.

Impact opérationnel

Dans Junos OS Evolved, vous pouvez effectuer de nombreuses actions par nœud. Vous pouvez utiliser les commandes CLI pour afficher des informations et demander des opérations sur des nœuds individuels.

Commandes CLI pertinentes

• show system nodes — Affiche la liste de tous les noeuds du système.

• show node ( reboot | statistics ) node-name — Affichez des informations sur un noeud spécifique.

• show system applications <node node-name> — Affiche les informations récapitulatives de l’application pour tous les noeuds ou un noeud spécifique.

• show system core-dumps <node node-name> — Affiche les fichiers de base du système pour tous les noeuds ou un noeud spécifique.

• show system errors active: utilisez cette commande à la place de la commande pour afficher les show chassis errors active informations d’erreur système.

• show system processes <node node-name> <detail> — Affiche les informations de processus pour tous les noeuds ou un noeud spécifique.

• show system storage node ( re0 | re1 | fpc0 | fpc1 | ...) — Affiche l’espace disque disponible pour un noeud spécifique.

• show version node ( all | node-name ) — Affiche les informations de version du logiciel pour tous les noeuds ou un noeud spécifique.

• request node ( halt | offline | online | power-off/on | reboot ) node-name — Demander une opération sur un noeud spécifique.

• request system reboot — Dans Junos OS Evolved, cette commande redémarre tous les nœuds.

Structure logicielle et applications

Junos OS Evolved fonctionne comme un système d’exploitation Linux distribué dont les processus s’exécutent en tant qu’applications autonomes. Chaque processus Junos OS Evolved s’exécute en tant qu’application. Toutes les applications Junos OS Evolved sont gérées par le processus à l’aide systemd d’unités de service. Les applications s’exécutent en tant que services distincts, ce qui assure l’isolation des pannes, car vous pouvez redémarrer une application séparément sans affecter les autres applications. La plupart des applications publient et consomment l’état, qui est stocké dans une base de données centrale.

Impact opérationnel

Dans Junos OS Evolved, de nombreuses fonctionnalités de haute disponibilité sont appliquées par application plutôt que par nœud. Certaines applications exécutent une sauvegarde permanente pour un basculement rapide, tandis que d’autres applications sont redémarrées sur un nouveau nœud en cas de panne.

Commandes CLI pertinentes

• show system applications <node node-name> — Affiche les informations récapitulatives de l’application pour tous les noeuds ou un noeud spécifique.

• restart process — Sous Junos OS, cette commande redémarre un processus spécifique. Dans Junos OS Evolved, la même commande redémarre une application (processus) spécifique sur le même nœud à partir duquel la commande est émise.

• request system application restart app application node node — Cette commande est spécifique à Junos OS Evolved et permet de redémarrer une application spécifique sur un nœud spécifique.

Modèle d’état

Junos OS Evolved utilise une infrastructure d’état distribuée. Les applications publient ou s’abonnent à des objets d’état, qui sont stockés dans une base de données d’état appelée Distributed Data Store (DDS) qui est répartie sur les nœuds. En comparaison, les processus Junos OS stockent l’état en interne, échangeant les informations d’état et les changements d’état avec d’autres processus via le noyau. Le modèle d’état de Junos OS Evolved est asynchrone et éventuellement cohérent au niveau de la couche de transport avec une cohérence causale au niveau de la couche d’application lors de l’accès à l’état. Cela signifie que si un processus redémarre dans Junos OS Evolved, les informations ne sont pas perdues car il peut récupérer des informations d’état à partir du DDS.

Impact opérationnel

Le modèle d'état de Junos OS Evolved accélère les performances, car vous n'avez pas besoin d'attendre la mise à jour du composant le plus lent. Les applications lisent et écrivent dans l’état du système sans attendre que tous les autres processus effectuent d’abord les mises à jour. Si une application redémarre, l’état est conservé et récupéré à partir du DDS par la nouvelle instance, même si l’application est générée sur un autre nœud.

Gestion logicielle

Chaque fois que vous installez une image logicielle sur Junos OS Evolved, l’image logicielle précédente et la configuration sont automatiquement conservées. Junos OS Evolved stocke les images logicielles dans le répertoire /soft . Chaque version du logiciel est stockée dans une zone distincte, ce qui garantit que l’installation d’un progiciel n’affecte pas les autres versions du logiciel installées sur le système. Alors que Junos OS prend en charge l’installation de deux versions logicielles sur le périphérique, Junos OS Evolved prend en charge le stockage d’autant d’images logicielles que l’espace le permet. Cependant, nous vous recommandons de ne pas conserver plus de cinq versions du logiciel sur le système.

Une fois l’installation réussie, le package d’installation réinstalle complètement le logiciel existant. Il conserve les fichiers de configuration et les informations similaires, telles que le shell sécurisé et les clés d’hôte, de la version précédente. Lorsque vous redémarrez le système après l’installation d’un progiciel, tous les moteurs de routage et FPC du système exécutent la nouvelle version du logiciel.

Impact opérationnel

Junos OS Evolved garantit que tous les moteurs de routage et FPC du système exécutent la même version logicielle. Lorsque vous installez une image logicielle sur le moteur de routage principal, le système installe la nouvelle version du logiciel sur les deux moteurs de routage, si les moteurs de routage sont en ligne et font partie du système. Si vous insérez dans le système un moteur de routage dont la version logicielle est différente et que vous n’avez pas configuré l’instruction system auto-sw-sync enable , le moteur de routage est conservé à l’extérieur du système et le système génère une alarme d’incompatibilité logicielle.

Lorsque vous installez une nouvelle image logicielle, le package logiciel précédent est conservé dans une zone distincte et vous pouvez y revenir manuellement si nécessaire. Junos OS Evolved vous permet de revenir à une autre image avec le fichier de configuration actuel ou avec l’instantané de configuration de la dernière exécution de l’image alternative.

Commandes CLI pertinentes

• show system software list — Sur Junos OS Evolved, affichez les images actuellement installées sur chaque nœud.

• show system storage — Affichez l’espace de stockage disponible. Sur Junos OS Evolved, les répertoires /soft, /var et /data doivent avoir une capacité inférieure à 90 % pour installer des images supplémentaires.

• request system software delete — Nettoyez les vieilles images. À partir de Junos OS Evolved version 20.1R1, utilisez cette commande à la place de la request system storage cleanup commande pour supprimer les images ISO du système.

• request system snapshot — Prenez un instantané des fichiers actuellement utilisés pour exécuter l’appareil et copiez-les sur le disque SSD de remplacement. L’instantané comprend le contenu complet des répertoires /soft, /config et /root , des copies des données utilisateur et le contenu du répertoire /var (à l’exception des répertoires /var/core, /var/external, /var/log et /var/tmp ).

• request system software rollback reboot <package-name> <with-old-snapshot-config> — Restaurez tous les moteurs de routage et FPC vers une autre version du logiciel et redémarrez. Incluez la with-old-snapshot-config possibilité d’utiliser la configuration enregistrée qui correspond à l’image du logiciel de restauration.

• request system software sync ( all-versions | current | rollback ) — Synchronisez les logiciels et les configurations du moteur de routage principal vers les autres nœuds et redémarrez les autres nœuds.

• set system auto-sw-sync enable — Synchronise automatiquement le logiciel et la configuration du moteur de routage principal avec un moteur de routage nouvellement ajouté et redémarre lorsque le moteur de routage nouvellement ajouté a une version logicielle différente du reste du système.

Interfaces de gestion

Sur Junos OS Evolved, les interfaces de gestion sont renommées pour prendre en charge plusieurs ports de gestion par nœud du moteur de routage.

Impact opérationnel

Les interfaces de gestion de Junos OS Evolved n’utilisent pas les mêmes noms que Junos OS (fxp0, em0, me0). Au lieu de cela, le format du nom de l’interface de gestion de Junos OS Evolved est device-name:type-port. Par exemple : re0:mgmt-0, re0:mgmt-1, re1:mgmt-0, re1:mgmt-1.

La show interfaces sortie affiche l’état de toutes les interfaces, y compris les interfaces Ethernet de gestion des deux moteurs de routage d’un système à double moteur de routage.

Noms d’hôte système

Dans Junos OS Evolved, les noms d’hôte système sont accompagnés d’un numéro de moteur de routage correspondant, tel que -re0 ou -re1.

Impact opérationnel

Dans Junos OS Evolved, lorsque vous spécifiez l’instruction host-name , le nom du moteur de routage actuel est ajouté à celui hostname que vous spécifiez. Par exemple, dans le moteur de routage 0, set system host-name my-host définissez le nom d’hôte sur my-host-re0. Vous pouvez également utiliser le %s caractère pour indiquer où remplacer le nom du moteur de routage. Par exemple, sur le moteur de routage 1, set system host-name %s_my_host définissez le nom d’hôte sur re1_my-host .

Commandes CLI pertinentes

• set system host-name hostname

Filtres de pare-feu du moteur de routage

Sous Junos OS, pour contrôler le flux de paquets locaux entre les interfaces physiques et le moteur de routage, vous pouvez appliquer des filtres de pare-feu sans état à l’entrée ou à la sortie de l’interface de bouclage. L’interface de bouclage (lo0) est l’interface du moteur de routage et ne transporte aucun paquet de données. Dans Junos OS, les filtres appliqués à l’interface de bouclage s’appliquent à la fois au trafic de contrôle et au trafic de gestion du réseau.

Junos OS Evolved, quant à lui, prend en charge deux filtres différents pour contrôler le flux de paquets locaux : un pour le trafic de contrôle du réseau (trafic de bouclage) et un pour le trafic de gestion. Par conséquent, les filtres appliqués à l’interface de bouclage s’appliquent uniquement au trafic de contrôle du réseau. Vous pouvez également appliquer des filtres séparément à l’interface de gestion, ce qui vous permet de configurer un filtre plus strict sur le trafic de gestion.

Impact opérationnel

Dans Junos OS Evolved, les filtres de pare-feu appliqués à l’interface de bouclage s’appliquent uniquement au trafic de contrôle réseau. Vous devez explicitement appliquer des filtres de pare-feu à l’interface de gestion pour filtrer le trafic de gestion. Dans Junos OS Evolved, le filtrage de gestion utilise des filtres du moteur de routage basés sur Netfilter, une infrastructure fournie par le noyau Linux. Par conséquent, seules certaines correspondances et actions sont prises en charge. Le Tableau 1 présente l’application de filtre Junos OS Evolved.

Pile réseau Junos OS Evolved

Junos OS Evolved fonctionne sous Linux natif. Il existe certaines différences entre la façon dont Linux affiche les informations de topologie de réseau demandées, telles que les données d’interface et de routage, et la façon dont Junos OS affiche ces informations. La CLI de Junos OS Evolved est conçue pour surmonter ces différences. Par conséquent, nous vous recommandons d’utiliser des commandes CLI plutôt que des commandes shell pour toutes les opérations réseau, en particulier pour les opérations qui nécessitent la spécification d’une instance de routage.

Si vous devez effectuer des opérations dans le shell Linux lorsque vous utilisez Junos OS Evolved, vous devez connaître les instances de routage suivantes, également appelées instances de routage et de transfert virtuelles (VRF) :

• default: gère à la fois le trafic WAN et le trafic de gestion par défaut, sauf si vous configurez l’instance de mgmt_junos routage.
• mgmt_junos: lorsque vous configurez cette instance de routage, elle place le port de gestion dans sa propre instance de routage, ce qui sépare le trafic de gestion du trafic WAN pour le moteur de routage.

• iri: gère le trafic du plan de contrôle (communication entre les nœuds). Dans l’interface de ligne de commande de Junos OS Evolved, cela équivaut à l’instance __juniper_private1__ de routage.

Impact opérationnel

Dans le shell Junos OS Evolved, vous pouvez utiliser l’utilitaire chvrf (change VRF) pour exécuter une commande dans le contexte d’une instance de routage spécifique, ou VRF. Par exemple:

Journalisation système

Dans Junos OS Evolved, chaque nœud dispose de l’outil standard journalctl , qui est une interface permettant de récupérer et de filtrer le journal système. Les messages du journal système sont analysés à partir du journal système. Le relay-eventd processus s’exécute sur tous les nœuds et récupère les événements (en fonction de la configuration syslog) du journal système ainsi que les messages d’erreur des différentes applications et les transmet au master-eventd processus. Le master-eventd processus s’exécute sur le moteur de routage principal et écrit les messages de journal et les erreurs sur le disque.

Utilisez l’application System Log Explorer pour afficher ou comparer les messages du journal système dans différentes versions.

Impact opérationnel

Dans Junos OS Evolved, il n’y a pas messages de fichier sur le moteur de routage de sauvegarde. Tous les journaux de sauvegarde du moteur de routage se trouvent dans le messages fichier sur le nœud principal du moteur de routage.

Format des messages du journal système

Par défaut, Junos OS Evolved ajoute le nom de nœud au nom d’hôte dans les messages du journal système. Ce n’est pas le cas de Junos OS. Cette action permet de conserver Junos OS messages du journal système Evolved conformes à RFC5424. Cependant, certains systèmes de surveillance peuvent ne pas identifier correctement un nom d’hôte Junos OS Evolved, car la combinaison nom d’hôte-nom de nœud ne correspond à aucun nom d’hôte dans l’inventaire des noms d’hôte.

Impact opérationnel

Si votre système de surveillance n’identifie pas correctement les noms d’hôte Junos OS Evolved, vous devez exécuter la set system syslog alternate-format commande configuration mode. Cette commande modifie le format des messages du journal système de Junos OS Evolved. Le nom du noeud est ajouté au nom du processus dans le message plutôt qu’au nom d’hôte, ce qui permet au système de surveillance d’identifier correctement le nom d’hôte.

Architecture de traçage

Junos OS Evolved utilise une nouvelle architecture de traçage. Toutes les applications en cours d’exécution créent des informations de traçage, plusieurs instances d’une même application ayant leurs propres informations de traçage. Junos OS Evolved trace-relay et trace-writer ses applications coordonnent les informations de traçage. L’application trace-relay s’exécute sur des nœuds locaux et partage une mémoire tampon avec chaque application. Lorsqu’une application Junos OS Evolved écrit en mémoire, l’application lit les données directement à partir de la trace-relay mémoire et les envoie aux trace-writer applications. Une trace-writer application s’exécute sur chaque nœud du moteur de routage. Il reçoit les informations de trace envoyées par les trace-relay applications et les écrit dans le fichier approprié au format CTF (Common Trace Format).

Impact opérationnel

Dans Junos OS, vous activez les opérations de suivi en configurant l’instruction traceoptions au niveau hiérarchique spécifique que vous souhaitez tracer. Junos OS Evolved, quant à lui, utilise un modèle basé sur l’application, de sorte que les messages de suivi sont enregistrés, affichés et configurés par application. Par conséquent, Junos OS Evolved ne prend pas en charge l’instruction traceoptions à de nombreux niveaux hiérarchiques pris en charge par Junos OS. Toutefois, certains niveaux hiérarchiques, tels que ceux sous [edit protocols], nécessitent toujours de configurer l’instruction pour activer les traceoptions messages de suivi.

Bien que Junos OS désactive par défaut les opérations de suivi global pour de nombreux niveaux hiérarchiques, certains processus consignent les messages de suivi par défaut pour les événements importants. En revanche, toutes les applications exécutées sur Junos OS Evolved créent par défaut des info informations de trace au niveau.

Dans Junos OS Evolved, vous n’affichez pas directement les fichiers de trace et vous ne devez jamais ajouter, modifier ou supprimer de fichiers de trace dans le répertoire /var/log/traces , car cela pourrait corrompre les traces. Au lieu de cela, vous utilisez la commande pour lire et décoder les show trace application application-name node node-name messages de trace stockés dans les fichiers de trace.

Commandes CLI pertinentes

• show trace application application-name node node-name — Lire et décoder les fichiers de trace.

• clear trace — Nettoyez manuellement les fichiers de trace.

• set system trace application — Modifiez les configurations des messages de suivi au niveau de l’application.