Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Surveillance et dépannage

Cette section décrit les fonctionnalités de surveillance et de dépannage réseau de Junos OS.

Envoyer un ping aux hôtes

But

Utilisez la commande CLI ping pour vérifier qu’un hôte est accessible via le réseau. Cette commande est utile pour diagnostiquer les problèmes de connectivité de l’hôte et du réseau. L’équipement envoie une série de requêtes d’écho ICMP (Internet Control Message Protocol) (ping) à un hôte spécifié et reçoit des réponses d’écho ICMP.

Action

Pour utiliser la ping commande afin d’envoyer quatre requêtes (nombre de pings) à host3 :

Exemple de sortie

nom_commande

Sens

  • Les ping résultats montrent les informations suivantes :

    • Taille du paquet de réponse ping (en octets).

    • Adresse IP de l’hôte à partir duquel la réponse a été envoyée.

    • Numéro de séquence du paquet de réponse ping. Vous pouvez utiliser cette valeur pour faire correspondre la réponse ping à la requête ping correspondante.

    • Time-to-live (ttl) hop-count valeur du paquet de réponse ping.

    • Temps total entre l’envoi du paquet de demande ping et la réception du paquet de réponse ping, en millisecondes. Cette valeur est également appelée temps d’aller-retour.

    • Nombre de requêtes ping (sondes) envoyées à l’hôte.

    • Nombre de réponses ping reçues de l’hôte.

    • Pourcentage de perte de paquets.

    • Statistiques sur le temps aller-retour : Minimum, Moyenne, Maximum et Écart-type du temps aller-retour.

Surveiller le trafic via le routeur ou le commutateur

Pour diagnostiquer un problème, affichez des statistiques en temps réel sur le trafic passant par les interfaces physiques sur le routeur ou le commutateur.

Pour afficher des statistiques en temps réel sur les interfaces physiques, effectuez les tâches suivantes :

Affichage de statistiques en temps réel sur toutes les interfaces du routeur ou du commutateur

But

Affichez des statistiques en temps réel sur le trafic passant par toutes les interfaces du routeur ou du commutateur.

Action

Pour afficher des statistiques en temps réel sur le trafic passant par toutes les interfaces du routeur ou du commutateur :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie affiche les données de trafic pour les interfaces actives et la quantité de modifications apportées à chaque champ depuis le démarrage de la commande ou depuis que les compteurs ont été effacés à l’aide de la C clé. Dans cet exemple, la monitor interface commande est en cours d’exécution depuis 15 secondes depuis qu’elle a été émise ou depuis que les compteurs sont revenus à zéro pour la dernière fois.

Affichage des statistiques en temps réel sur une interface sur le routeur ou le commutateur

But

Affichez des statistiques en temps réel sur le trafic passant par une interface sur le routeur ou le commutateur.

Action

Pour afficher le trafic passant par une interface sur le routeur ou le commutateur, utilisez la commande suivante en mode opérationnel CLI de Junos OS :

Exemple de sortie
nom_commande

Sens

L’exemple de sortie montre les paquets d’entrée et de sortie pour une interface SONET particulière (so-0/0/1). Il peut s’agir de défaillances d’interface courantes, telles que les alarmes SONET/SDH et T3, de bouclages détectés et d’une augmentation des erreurs de tramage. Pour plus d’informations, reportez-vous à la rubrique Liste de contrôle des conditions d’erreur de suivi.

Pour contrôler la sortie de la commande pendant qu’elle est en cours d’exécution, utilisez les touches indiquées à la section Tableau 1.

Tableau 1 : Touches de contrôle de sortie pour la commande de l’interface du moniteur

Action

Clé

Affichez des informations sur l’interface suivante. La monitor interface commande parcourt les interfaces physiques ou logiques dans le même ordre qu’elles sont affichées par la show interfaces terse commande.

N

Affichez des informations sur une autre interface. La commande vous invite à entrer le nom d’une interface spécifique.

I

Figer l’affichage, interrompant l’affichage des statistiques mises à jour.

F

Dégelez l’affichage, reprenant l’affichage des statistiques mises à jour.

T

Effacez (zéro) les compteurs delta actuels depuis monitor interface le démarrage. Il n’efface pas le compteur cumulatif.

C

Arrêtez la monitor interface commande.

Q

Pour plus d’informations sur l’utilisation des conditions de correspondance avec la commande, reportez-vous à l’Explorateurmonitor traffic CLI.

Présentation de la mémoire adressable à contenu ternaire dynamique

Dans les routeurs ACX Series, la mémoire adressable à contenu ternaire (TCAM) est utilisée par diverses applications telles que le pare-feu, la gestion des problèmes de connectivité, PTPoE, RFC 2544, etc. Le moteur de transfert de paquets (PFE) des routeurs ACX Series utilise TCAM avec des limites d’espace TCAM définies. L’allocation des ressources TCAM aux différentes applications de filtrage est répartie de manière statique. Cette allocation statique conduit à une utilisation inefficace des ressources TCAM lorsque toutes les applications de filtrage peuvent ne pas utiliser cette ressource TCAM simultanément.

L’allocation dynamique de l’espace TCAM dans les routeurs ACX alloue efficacement les ressources TCAM disponibles pour diverses applications de filtrage. Dans le modèle TCAM dynamique, diverses applications de filtrage (telles que inet-firewall, bridge-firewall, cfm-filters, etc.) peuvent utiliser de manière optimale les ressources TCAM disponibles en fonction des besoins. L’allocation dynamique des ressources TCAM est basée sur l’utilisation et est allouée dynamiquement aux applications de filtrage en fonction des besoins. Lorsqu’une application de filtrage n’utilise plus l’espace TCAM, la ressource est libérée et disponible pour une utilisation par d’autres applications. Ce modèle TCAM dynamique permet d’utiliser les ressources TCAM à plus grande échelle en fonction de la demande de l’application.

Applications utilisant une infrastructure TCAM dynamique

Les catégories d’applications de filtrage suivantes utilisent l’infrastructure TCAM dynamique :

  • Firewall filter (Filtre de pare-feu) : toutes les configurations de pare-feu

  • Filtre implicite : démons du moteur de routage (RE) utilisant des filtres pour obtenir sa fonctionnalité. Par exemple, la gestion des problèmes de connectivité, la validation IP MAC, etc.

  • Dynamic filters (Filtres dynamiques) : applications utilisant des filtres pour obtenir la fonctionnalité au niveau du PFE. Par exemple, un classificateur fixe au niveau de l’interface logique, RFC 2544, etc. Les démons de l’ER ne connaîtront pas ces filtres.

  • Filtres d’initialisation système : filtres qui nécessitent des entrées au niveau du système ou un ensemble fixe d’entrées dans la séquence de démarrage du routeur. Par exemple, les interruptions de protocole de contrôle des couches 2 et 3, le mécanisme de contrôle ARP par défaut, etc.

    REMARQUE :

    Le filtre System-init qui a les applications pour les protocoles de contrôle de couche 2 et de couche 3 trap est essentiel pour la fonctionnalité globale du système. Les applications de ce groupe de contrôle consomment un espace TCAM fixe et minimal par rapport à l’espace TCAM global. Le filtre d’initialisation système n’utilisera pas l’infrastructure TCAM dynamique et sera créé lorsque le routeur sera initialisé pendant la séquence de démarrage.

Fonctionnalités utilisant la ressource TCAM

Les applications utilisant la ressource TCAM sont appelées tcam-app dans le présent document. Par exemple, inet-firewall, bridge-firewall, la gestion des défauts de connectivité, la gestion des pannes de liaison, etc. sont toutes des applications tcam différentes.

Tableau 2 décrit la liste des applications tcam qui utilisent les ressources TCAM.

Tableau 2 : Fonctionnalités utilisant la ressource TCAM

Applications TCAM/Utilisateurs TCAM

Caractéristique/Fonctionnalité

Étape TCAM

bd-dtag-validate

Validation à double balisage de domaine de pont

REMARQUE :

Cette fonctionnalité n’est pas prise en charge sur les routeurs ACX5048 et ACX5096.

Sortie

bd-tpid-swap

Pont domaine vlan-map avec opération swap tpid

Sortie

cfm-bd-filter

Gestion des défaillances de connectivité : filtres implicites de domaine de pont

Entrée

cfm-filter

Gestion des défaillances de connectivité : filtres implicites

Entrée

cfm-vpls-filter

Gestion des problèmes de connectivité filtres vpls implicites

REMARQUE :

Cette fonctionnalité n’est prise en charge que sur les routeurs ACX5048 et ACX5096.

Entrée

cfm-vpls-ifl-filter

Gestion des problèmes de connectivité filtres d’interface logique vpls implicites

REMARQUE :

Cette fonctionnalité n’est prise en charge que sur les routeurs ACX5048 et ACX5096.

Entrée

cos-fc

Classificateur fixe au niveau de l’interface logique

Pré-entrée

fw-ccc-in

Pare-feu de la famille de connexions croisées de circuit

Entrée

fw-family-out

Pare-feu de sortie au niveau de la famille

Sortie

fw-fbf

Transfert basé sur les filtres de pare-feu

Pré-entrée

fw-fbf-inet6

Transfert basé sur les filtres de pare-feu pour la gamme inet6

Pré-entrée

fw-ifl-in

Pare-feu d’entrée au niveau de l’interface logique

Entrée

fw-ifl-out

Pare-feu de sortie au niveau de l’interface logique

Sortie

fw-inet-ftf

Pare-feu d’entrée de la famille Inet sur une table de transfert

Entrée

fw-inet6-ftf

Pare-feu d’entrée de la famille Inet6 sur une table de transfert

Entrée

fw-inet-in

Pare-feu d’entrée de la famille Inet

Entrée

fw-inet-rpf

Pare-feu d’entrée de la famille Inet lors de la vérification de l’échec RPF

Entrée

fw-inet6-in

Pare-feu d’entrée de la famille Inet6

Entrée

fw-inet6-family-out

Pare-feu de sortie de la gamme Inet6

Sortie

fw-inet6-rpf

Pare-feu d’entrée de la famille Inet6 lors d’une vérification d’échec RPF

Entrée

fw-inet-pm

Pare-feu de la famille Inet avec action port-miroir

REMARQUE :

Cette fonctionnalité n’est pas prise en charge sur les routeurs ACX5048 et ACX5096.

Entrée

fw-l2-in

Pare-feu d’entrée de la famille de ponts sur l’interface de couche 2

Entrée

fw-mpls-in

Pare-feu dentrée de la famille MPLS

Entrée

fw-semantics

Sémantique de partage de pare-feu pour le pare-feu configuré par CLI

Pré-entrée

fw-vpls-in

Pare-feu d’entrée de la famille VPLS sur l’interface VPLS

Entrée

ifd-src-mac-fil

Filtre MAC source au niveau de l’interface physique

Pré-entrée

ifl-statistics-in

Statistiques d’interface au niveau logique à l’entrée

Entrée

ifl-statistics-out

Statistiques d’interface de niveau logique à la sortie

Sortie

ing-out-iff

Application entrante pour le compte du filtre de la famille de sortie pour le journal et syslog

Entrée

ip-mac-val

Validation MAC IP

Pré-entrée

ip-mac-val-bcast

Validation MAC IP pour la diffusion

Pré-entrée

ipsec-reverse-fil

Filtres inverses pour le service IPsec

REMARQUE :

Cette fonctionnalité n’est pas prise en charge sur les routeurs ACX5048 et ACX5096.

Entrée

irb-cos-rw

Réécriture de la CoS de la CISR

Sortie

lfm-802.3ah-in

Gestion des défaillances de liaison (IEEE 802.3ah) à l’entrée

REMARQUE :

Cette fonctionnalité n’est pas prise en charge sur les routeurs ACX5048 et ACX5096.

Entrée

lfm-802.3ah-out

Gestion des défaillances de liaison (IEEE 802.3ah) à la sortie

Sortie

lo0-inet-fil

Filtre d’entrée d’interface Looback

Entrée

lo0-inet6-fil

Filtre inet6 de l’interface Looback

Entrée

mac-drop-cnt

Statistiques sur les abandons par validation MAC et filtres MAC source

Entrée

mrouter-port-in

Port de routeur multicast pour la surveillance

Entrée

napt-reverse-fil

Filtres inverses pour le service de traduction de ports d’adresses réseau (NAPT)

REMARQUE :

Cette fonctionnalité n’est pas prise en charge sur les routeurs ACX5048 et ACX5096.

Entrée

no-local-switching

Pont sans commutation locale

Entrée

ptpoe

Pièges point à point sur Ethernet

REMARQUE :

Cette fonctionnalité n’est pas prise en charge sur les routeurs ACX5048 et ACX5096.

Entrée

ptpoe-cos-rw

Réécriture CoS pour PTPoE

REMARQUE :

Cette fonctionnalité n’est pas prise en charge sur les routeurs ACX5048 et ACX5096.

Sortie

rfc2544-layer2-in

RFC2544 pour le service de couche 2 à l’entrée

Pré-entrée

rfc2544-layer2-out

RFC2544 pour le service de couche 2 à la sortie

REMARQUE :

Cette fonctionnalité n’est pas prise en charge sur les routeurs ACX5048 et ACX5096.

Sortie

service-filter-in

Filtre de service à l’entrée

REMARQUE :

Cette fonctionnalité n’est pas prise en charge sur les routeurs ACX5048 et ACX5096.

Entrée

Surveillance de l’utilisation des ressources TCAM

Vous pouvez utiliser les commandes show et clear pour surveiller et dépanner l’utilisation dynamique des ressources TCAM.

Tableau 3 récapitule les commandes de l’interface de ligne de commande (CLI) que vous pouvez utiliser pour surveiller et dépanner l’utilisation dynamique des ressources TCAM.

Tableau 3 : Afficher et effacer les commandes de surveillance et de dépannage du TCAM dynamique

Tâche

Commande

Afficher les applications partagées et associées pour une application particulière

Afficher l’application PFE TCAM

Affichage de l’utilisation des ressources TCAM pour une application et les étapes (sortie, entrée et pré-entrée)

Afficher l’utilisation du PFE TCAM

(ACX5448) Afficher le filtre PFE Récapitulatif matériel

Affichez les erreurs d’utilisation des ressources TCAM pour les applications et les étapes (sortie, entrée et pré-entrée)

Afficher les erreurs PFE TCAM

Efface les statistiques d’erreur d’utilisation des ressources TCAM pour les applications et les étapes (sortie, entrée et pré-entrée)

Effacer les erreurs PFE TCAM

Exemple : Surveillance et dépannage de la ressource TCAM

Cette section décrit un cas d’utilisation dans lequel vous pouvez surveiller et dépanner les ressources TCAM à l’aide des commandes show. Dans ce scénario d’utilisation, vous avez configuré des services de couche 2 et les applications liées aux services de couche 2 utilisent des ressources TCAM. L’approche dynamique, telle qu’illustrée dans cet exemple, vous offre toute la flexibilité nécessaire pour gérer les ressources TCAM en fonction des besoins.

Les exigences en matière de service sont les suivantes :

  • Chaque domaine de pont dispose d’une interface UNI et d’une interface NNI

  • Chaque interface UNI possède :

    • Un mécanisme de contrôle au niveau de l’interface logique pour contrôler le trafic à 10 Mbit/s.

    • Classificateur à champs multiples avec quatre termes pour attribuer la classe de transfert et la priorité de perte.

  • Chaque interface UNI configure CFM UP MEP au niveau 4.

  • Chaque interface NNI configure CFM DOWN MEP au niveau 2

Imaginons un scénario dans lequel 100 services sont configurés sur le routeur. Avec cette mise à l’échelle, toutes les applications sont correctement configurées et l’état indique OK l’état.

  1. Affichage de l’utilisation des ressources TCAM pour toutes les étapes.

    Pour afficher l’utilisation des ressources TCAM pour toutes les étapes (sortie, entrée et préentrée), utilisez la show pfe tcam usage all-tcam-stages detail commande. Sur ACX5448 routeurs, utilisez la show pfe filter hw summary commande pour afficher la ressource TCAM usgae.

  2. Configurez des services de couche 2 supplémentaires sur le routeur.

    Par exemple, ajoutez 20 services supplémentaires sur le routeur, ce qui porte le nombre total de services à 120. Après avoir ajouté d’autres services, vous pouvez vérifier l’état de la configuration en vérifiant le message syslog à l’aide de la commande show log messages, ou en exécutant la show pfe tcam errors commande.

    Voici un exemple de sortie de message syslog montrant la pénurie de ressources TCAM pour les filtres de la famille de commutation Ethernet pour les configurations plus récentes en exécutant la show log messages commande CLI.

    Si vous utilisez la show pfe tcam errors all-tcam-stages detail commande CLI pour vérifier l’état de la configuration, la sortie sera comme indiqué ci-dessous :

    La sortie indique que l’application fw-l2-in est à court de ressources TCAM et passe à l’état FAILED. Bien que deux tranches TCAM soient disponibles à l’étape d’entrée, l’application fw-l2-in n’est pas en mesure d’utiliser l’espace TCAM disponible en raison de son mode (DOUBLE), ce qui entraîne un échec de pénurie de ressources.

  3. Correction des applications qui ont échoué en raison de la pénurie de ressources TCAM.

    L’application fw-l2-in a échoué en raison de l’ajout d’un plus grand nombre de services sur les routeurs, ce qui a entraîné une pénurie de ressources TCAM. Bien que d’autres applications semblent fonctionner correctement, il est recommandé de désactiver ou de supprimer les services nouvellement ajoutés afin que l’application fw-l2-in passe à l’état OK. Après avoir supprimé ou désactivé les services nouvellement ajoutés, vous devez exécuter les show pfe tcam usage commandes et show pfe tcam error pour vérifier qu’il n’y a plus d’applications en état d’échec.

    Pour afficher l’utilisation des ressources TCAM pour toutes les étapes (sortie, entrée et préentrée), utilisez la show pfe tcam usage all-tcam-stages detail commande. Pour ACX5448 routeurs, utilisez la show pfe filter hw summary commande to pour afficher l’utilisation des ressources TCAM.

    Pour afficher les erreurs d’utilisation des ressources TCAM pour toutes les étapes (sortie, entrée et préentrée), utilisez la show pfe tcam errors all-tcam-stages commande.

    Vous pouvez voir que toutes les applications utilisant les ressources TCAM sont en OK état et indique que le matériel a été correctement configuré.

REMARQUE :

Comme indiqué dans l’exemple, vous devrez exécuter les show pfe tcam errors commandes et show pfe tcam usage à chaque étape pour vous assurer que vos configurations sont valides et que les applications utilisant la ressource TCAM sont à l’état OK. Pour ACX5448 routeurs, utilisez la show pfe filter hw summary commande pour afficher l’utilisation des ressources TCAM.

Surveillance et dépannage des ressources TCAM dans les routeurs ACX Series

L’allocation dynamique de l’espace TCAM (Ternary Content Addressable Memory) dans ACX Series alloue efficacement les ressources TCAM disponibles pour diverses applications de filtrage. Dans le modèle TCAM dynamique, diverses applications de filtrage (telles que inet-firewall, bridge-firewall, cfm-filters, etc.) peuvent utiliser de manière optimale les ressources TCAM disponibles en fonction des besoins. L’allocation dynamique des ressources TCAM est basée sur l’utilisation et est allouée dynamiquement aux applications de filtrage en fonction des besoins. Lorsqu’une application de filtrage n’utilise plus l’espace TCAM, la ressource est libérée et disponible pour une utilisation par d’autres applications. Ce modèle TCAM dynamique permet d’utiliser les ressources TCAM à plus grande échelle en fonction de la demande de l’application. Vous pouvez utiliser les commandes show et clear pour surveiller et dépanner l’utilisation dynamique des ressources TCAM dans les routeurs ACX Series.

REMARQUE :

Les applications utilisant la ressource TCAM sont appelées tcam-app dans le présent document.

Présentation de la mémoire adressable à contenu ternaire dynamique affiche la tâche et les commandes permettant de surveiller et de dépanner les ressources TCAM dans les routeurs ACX Series

Tableau 4 : Commandes de surveillance et de dépannage des ressources TCAM dans ACX Series

Comment

Commande

Affichez les applications partagées et associées pour une application particulière.

show pfe tcam app (list-shared-apps | list-related-apps)

Affichez le nombre d’applications sur toutes les étapes tcam.

show pfe tcam usage all-tcam-stages

Affichez le nombre d’applications utilisant la ressource TCAM à une étape spécifiée.

show pfe tcam usage tcam-stage (ingress | egress | pre-egress)

Affichez en détail la ressource TCAM utilisée par une application.

show pfe tcam usage app <application-name> detail

Affichez la ressource TCAM utilisée par une application à une étape spécifiée.

show pfe tcam usage tcam-stage (ingress | egress | pre-egress) app <application-name>

Connaître le nombre de ressources TCAM consommées par une tcam-app

show pfe tcam usage app <application-name>

Affichez les erreurs d’utilisation des ressources TCAM pour toutes les étapes.

show pfe tcam errors all-tcam-stages detail

Afficher les erreurs d’utilisation des ressources TCAM pour une étape

show pfe tcam errors tcam-stage (ingress | egress | pre-egress)

Affichez les erreurs d’utilisation des ressources TCAM pour une application.

show pfe tcam errors app <application-name>

Affichez les erreurs d’utilisation des ressources TCAM pour une application ainsi que pour ses autres applications partagées.

show pfe tcam errors app <application-name> shared-usage

Effacez les statistiques d’erreur d’utilisation des ressources TCAM pour toutes les étapes.

clear pfe tcam-errors all-tcam-stages

Effacer les statistiques d’erreur d’utilisation des ressources TCAM pour une étape spécifiée

clear pfe tcam-errors tcam-stage (ingress | egress | pre-egress)

Effacez les statistiques d’erreur d’utilisation des ressources TCAM d’une application.

clear pfe tcam-errors app <application-name>

Pour en savoir plus sur le TCAM dynamique dans ACX Series, reportez-vous à la section Présentation de la mémoire adressable de contenu ternaire dynamique.

Mise à l’échelle des services sur les routeurs ACX5048 et ACX5096

Sur les routeurs ACX5048 et ACX5096, un service typique (tel qu’ELINE, ELAN et IP VPN) déployé peut nécessiter des applications (telles que des mécanismes de contrôle, des filtres de pare-feu, une gestion des défauts de connectivité, IEEE 802.1ag, RFC2544) qui utilisent l’infrastructure TCAM dynamique.

REMARQUE :

Les applications de service qui utilisent des ressources TCAM sont limitées par la disponibilité des ressources TCAM. Par conséquent, l’échelle du service dépend de la consommation de la ressource TCAM par ces applications.

Un exemple de cas d’utilisation pour surveiller et dépanner le service à grande échelle dans les routeurs ACX5048 et ACX5096 est disponible dans la section Présentation de la mémoire adressable ternaire dynamique .

Dépannage de la résolution de noms DNS dans les stratégies de sécurité du système logique (administrateurs principaux uniquement)

Problème

Description

L’adresse d’un nom d’hôte dans une entrée du carnet d’adresses utilisée dans une stratégie de sécurité peut ne pas être résolue correctement.

Cause

Normalement, les entrées du carnet d’adresses contenant des noms d’hôte dynamiques sont actualisées automatiquement pour les pare-feu SRX Series. Le champ TTL associé à une entrée DNS indique le délai après lequel l’entrée doit être actualisée dans le cache de stratégie. Une fois la valeur TTL expirée, le pare-feu SRX Series actualise automatiquement l’entrée DNS pour une entrée de carnet d’adresses.

Toutefois, si le pare-feu SRX Series ne parvient pas à obtenir une réponse du serveur DNS (par exemple, si la requête DNS ou le paquet de réponse est perdu dans le réseau ou si le serveur DNS ne peut pas envoyer de réponse), l’adresse d’un nom d’hôte dans une entrée du carnet d’adresses peut échouer à se résoudre correctement. Cela peut entraîner une baisse du trafic, car aucune stratégie de sécurité ou correspondance de session n’est trouvée.

Solution

L’administrateur principal peut utiliser la show security dns-cache commande pour afficher les informations du cache DNS sur le pare-feu SRX Series. Si les informations du cache DNS doivent être actualisées, l’administrateur principal peut utiliser la clear security dns-cache commande.

REMARQUE :

Ces commandes ne sont disponibles que pour l’administrateur principal sur les périphériques configurés pour les systèmes logiques. Cette commande n’est pas disponible dans les systèmes logiques utilisateur ni sur les périphériques qui ne sont pas configurés pour les systèmes logiques.

Dépannage des stratégies de sécurité

Synchronisation des stratégies entre le moteur de routage et le moteur de transfert de paquets

Problème

Description

Les stratégies de sécurité sont stockées dans le moteur de routage et le moteur de transfert de paquets. Les stratégies de sécurité sont transmises du moteur de routage au moteur de transfert de paquets lorsque vous validez les configurations. Si les stratégies de sécurité du moteur de routage ne sont pas synchronisées avec le moteur de transfert de paquets, la validation d’une configuration échoue. Des fichiers de core dump peuvent être générés si la validation est tentée à plusieurs reprises. La désynchronisation peut être due à :

  • Un message de stratégie transmis par le moteur de routage au moteur de transfert de paquets est perdu en transit.

  • Une erreur avec le moteur de routage, telle qu’un UID de stratégie réutilisé.

Environnement

Les stratégies du moteur de routage et du moteur de transfert de paquets doivent être synchronisées pour que la configuration soit validée. Toutefois, dans certaines circonstances, les stratégies du moteur de routage et du moteur de transfert de paquets peuvent ne pas être synchronisées, ce qui entraîne l’échec de la validation.

Symptômes

Lorsque les configurations de stratégie sont modifiées et que les stratégies ne sont pas synchronisées, le message d’erreur suivant s’affiche : error: Warning: policy might be out of sync between RE and PFE <SPU-name(s)> Please request security policies check/resync.

Solution

Utilisez la show security policies checksum commande pour afficher la valeur de la somme de contrôle de la stratégie de sécurité et synchroniser request security policies resync la configuration des stratégies de sécurité dans le moteur de routage et le moteur de transfert de paquets, si les stratégies de sécurité ne sont pas synchronisées.

Vérification de l’échec d’une validation de stratégie de sécurité

Problème

Description

La plupart des échecs de configuration des stratégies se produisent lors d’une validation ou d’un runtime.

Les échecs de validation sont signalés directement sur l’interface de ligne de commande lorsque vous exécutez la commande commit-check de l’interface de ligne de commande en mode de configuration. Ces erreurs sont des erreurs de configuration, et vous ne pouvez pas valider la configuration sans corriger ces erreurs.

Solution

Pour corriger ces erreurs, procédez comme suit :

  1. Vérifiez vos données de configuration.

  2. Ouvrez le fichier /var/log/nsd_chk_only. Ce fichier est écrasé chaque fois que vous effectuez une vérification de validation et contient des informations détaillées sur les échecs.

Vérification d’une validation de stratégie de sécurité

Problème

Description

Lors de l’exécution d’une validation de configuration de stratégie, si vous remarquez que le comportement du système est incorrect, procédez comme suit pour résoudre ce problème :

Solution

  1. Operational Commands (Commandes opérationnelles show ) : exécutez les commandes opérationnelles pour les stratégies de sécurité et vérifiez que les informations affichées dans la sortie correspondent à ce que vous attendiez. Si ce n’est pas le cas, la configuration doit être modifiée en conséquence.

  2. Traceoptions : définissez la commande dans la configuration de traceoptions votre stratégie. Les indicateurs de cette hiérarchie peuvent être sélectionnés en fonction de l’analyse de la sortie de la commande par l’utilisateur show . Si vous ne parvenez pas à déterminer l’indicateur à utiliser, l’option all d’indicateur peut être utilisée pour capturer tous les journaux de suivi.

Vous pouvez également configurer un nom de fichier facultatif pour capturer les journaux.

Si vous avez spécifié un nom de fichier dans les options de traçage, vous pouvez rechercher le fichier journal dans le fichier journal /var/log/<filename> pour vérifier si des erreurs ont été signalées dans le fichier. (Si vous n’avez pas spécifié de nom de fichier, le nom de fichier par défaut est eventd.) Les messages d’erreur indiquent le lieu de la défaillance et la raison appropriée.

Après avoir configuré les options de traçage, vous devez valider à nouveau la modification de configuration à l’origine du comportement incorrect du système.

Recherche de stratégie de débogage

Problème

Description

Lorsque vous disposez de la configuration correcte, mais qu’une partie du trafic a été incorrectement supprimée ou autorisée, vous pouvez activer l’indicateur lookup dans les traceoptions des stratégies de sécurité. L’indicateur lookup consigne les traces associées à la recherche dans le fichier de trace.

Solution

Consigner les messages d’erreur utilisés pour résoudre les problèmes liés à ISSU

Les problèmes suivants peuvent se produire lors d’une mise à niveau d’ISSU : Vous pouvez identifier les erreurs à l’aide des détails dans les journaux. Pour plus d’informations sur des messages de journal système spécifiques, reportez-vous à la section Explorateur de journaux système.

Erreurs de processus Chassisd

Problème

Description

Erreurs liées au chassisd.

Solution

Utilisez les messages d’erreur pour comprendre les problèmes liés à chassisd.

Au démarrage d’ISSU (ISSU démarre), une requête est envoyée à chassisd pour vérifier s’il y a des problèmes liés à l’ISSU du point de vue du châssis. En cas de problème, un message de journal est créé.

Comprendre la gestion des erreurs courantes pour ISSU

Problème

Description

Il se peut que vous rencontriez des problèmes au cours d’une ISSIS. Cette section fournit des détails sur la façon de les gérer.

Solution

Toute erreur rencontrée lors d’un ISSU entraîne la création de messages de journal, qui continuent de fonctionner sans impact sur le trafic. S’il est nécessaire de revenir aux versions précédentes, l’événement est consigné ou l’ISSU est arrêté, afin de ne pas créer de versions incompatibles sur les deux nœuds du cluster de châssis. Tableau 8 Fournit certaines des conditions d’erreur courantes et les solutions de contournement. Les exemples de messages utilisés dans le Tableau 8 proviennent de l’appareil SRX1500 et s’appliquent également à tous les pare-feu SRX Series pris en charge.

Tableau 8 : Erreurs et solutions liées à l’ISSU

Conditions d’erreur

Solutions

Tenter de lancer un ISSU alors qu’une instance précédente d’un ISSU est déjà en cours

Le message suivant s’affiche :

warning: ISSU in progress

Vous pouvez abandonner le processus ISSU en cours et relancer l’ISSU à l’aide de la request chassis cluster in-service-upgrade abort commande.

Échec du redémarrage sur le noeud secondaire

Il n’y a pas d’interruption de service, car le nud principal continue de fournir les services requis. Des messages détaillés de la console s’affichent pour vous demander d’effacer manuellement les états ISSU existants et de restaurer le cluster de châssis.

error: [Oct  6 12:30:16]: Reboot secondary node failed (error-code: 4.1)

       error: [Oct  6 12:30:16]: ISSU Aborted! Backup node maybe in inconsistent state, Please restore backup node
       [Oct  6 12:30:16]: ISSU aborted. But, both nodes are in ISSU window.
       Please do the following:
       1. Rollback the node with the newer image using rollback command
          Note: use the 'node' option in the rollback command
          otherwise, images on both nodes will be rolled back
       2. Make sure that both nodes (will) have the same image
       3. Ensure the node with older image is primary for all RGs
       4. Abort ISSU on both nodes
       5. Reboot the rolled back node

À compter de Junos OS version 17.4R1, le délai de mise en attente pour le redémarrage initial du nœud secondaire pendant le processus ISSU passe de 15 minutes (900 secondes) à 45 minutes (2700 secondes) dans les clusters de châssis sur les périphériques SRX1500, SRX4100, SRX4200 et SRX4600.

Le noeud secondaire n’a pas réussi à terminer la synchronisation à froid

Le noeud principal expire si le noeud secondaire ne parvient pas à terminer la synchronisation à froid. Des messages détaillés de la console s’affichent pour vous indiquer que vous effacez manuellement les états ISSU existants et que vous restaurez le cluster de châssis. Aucun temps d’arrêt de service ne se produit dans ce scénario.

[Oct  3 14:00:46]: timeout waiting for secondary node node1 to sync(error-code: 6.1)
        Chassis control process started, pid 36707 

       error: [Oct  3 14:00:46]: ISSU Aborted! Backup node has been upgraded, Please restore backup node 
       [Oct  3 14:00:46]: ISSU aborted. But, both nodes are in ISSU window. 
       Please do the following: 
      1. Rollback the node with the newer image using rollback command 
          Note: use the 'node' option in the rollback command 
          otherwise, images on both nodes will be rolled back 
      2. Make sure that both nodes (will) have the same image 
      3. Ensure the node with older image is primary for all RGs 
      4. Abort ISSU on both nodes 
      5. Reboot the rolled back node  

Échec du basculement du serveur secondaire nouvellement mis à niveau

Il n’y a pas d’interruption de service, car le nud principal continue de fournir les services requis. Des messages détaillés de la console s’affichent pour vous demander d’effacer manuellement les états ISSU existants et de restaurer le cluster de châssis.

[Aug 27 15:28:17]: Secondary node0 ready for failover.
[Aug 27 15:28:17]: Failing over all redundancy-groups to node0
ISSU: Preparing for Switchover
error: remote rg1 priority zero, abort failover.
[Aug 27 15:28:17]: failover all RGs to node node0 failed (error-code: 7.1)
error: [Aug 27 15:28:17]: ISSU Aborted!
[Aug 27 15:28:17]: ISSU aborted. But, both nodes are in ISSU window.
Please do the following:
1. Rollback the node with the newer image using rollback command
    Note: use the 'node' option in the rollback command
           otherwise, images on both nodes will be rolled back
2. Make sure that both nodes (will) have the same image
3. Ensure the node with older image is primary for all RGs
4. Abort ISSU on both nodes
5. Reboot the rolled back node
{primary:node1}

Échec de la mise à niveau sur le serveur principal

Il n’y a pas d’interruption de service, car le nœud secondaire bascule en tant que nœud principal et continue de fournir les services requis.

Échec du redémarrage sur le nœud principal

Avant le redémarrage du noeud principal, les périphériques étant hors de la configuration ISSU , aucun message d’erreur lié à ISSU ne s’affiche. Le message d’erreur de redémarrage suivant s’affiche si une autre défaillance est détectée :

Reboot failure on     Before the reboot of primary node, devices will be out of ISSU setup and no primary node error messages will be displayed.
Primary node

Erreurs liées à la prise en charge d’ISSU

Problème

Description

L’échec de l’installation se produit en raison d’un logiciel non pris en charge et d’une configuration de fonctionnalités non prise en charge.

Solution

Utilisez les messages d’erreur suivants pour comprendre les problèmes liés à la compatibilité :

Échec des vérifications de validation initiale

Problème

Description

Les vérifications de validation initiales échouent.

Solution

Les vérifications de validation échouent si l’image n’est pas présente ou si le fichier image est endommagé. Les messages d’erreur suivants s’affichent lorsque les vérifications de validation initiales échouent lorsque l’image n’est pas présente et que l’ISSU est abandonné :

Lorsque l’image n’est pas présente

Lorsque le fichier image est corrompu

Si le fichier image est endommagé, la sortie suivante s’affiche :

Le nœud principal valide la configuration de l’équipement pour s’assurer qu’elle peut être validée à l’aide de la nouvelle version du logiciel. En cas de problème, l’ISSU abandonne et des messages d’erreur s’affichent.

Erreurs liées à l’installation

Problème

Description

Le fichier image d’installation n’existe pas ou le site distant est inaccessible.

Solution

Utilisez les messages d’erreur suivants pour comprendre les problèmes liés à l’installation :

ISSU télécharge l’image d’installation comme spécifié dans la commande ISSU en tant qu’argument. Il peut s’agir d’un fichier local ou d’un fichier distant. Si le fichier n’existe pas ou si le site distant est inaccessible, une erreur est signalée.

Erreurs de basculement de groupe de redondance

Problème

Description

Problème lié à la défaillance du groupe de redondance automatique (RG).

Solution

Utilisez les messages d’erreur suivants pour comprendre le problème :

Erreurs de synchronisation de l’état du noyau

Problème

Description

Erreurs liées à ksyncd.

Solution

Utilisez les messages d’erreur suivants pour comprendre les problèmes liés à ksyncd :

ISSU vérifie s’il y a des erreurs ksyncd sur le noeud secondaire (noeud 1) et affiche le message d’erreur s’il y a des problèmes et abandonne la mise à niveau.

Tableau de l'historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Version
Description
17.4R1
À compter de Junos OS version 17.4R1, le délai de mise en attente pour le redémarrage initial du nœud secondaire pendant le processus ISSU passe de 15 minutes (900 secondes) à 45 minutes (2700 secondes) dans les clusters de châssis sur les périphériques SRX1500, SRX4100, SRX4200 et SRX4600.