Surveillance et dépannage

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 :

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.

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 :

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.

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

Problème

Solution

Vous pouvez appliquer un mappage de planificateur à l’ensemble de liens multiples et à ses liens constitutifs. Bien que vous puissiez appliquer plusieurs composants CoS avec la carte du planificateur, configurez uniquement ceux qui sont nécessaires. Nous vous recommandons de garder la configuration sur les liens constitutifs simple pour éviter tout retard inutile dans la transmission.

Tableau 5 indique les composants CoS à appliquer sur un fibré multiliaisons et ses liaisons constitutives.

Problème

Solution

Pour réduire la gigue et la latence, procédez comme suit :

1. Assurez-vous d’avoir configuré un taux de mise en forme sur chaque lien constitutif.

2. Assurez-vous que vous n’avez pas configuré de taux de mise en forme sur l’interface des services de liaison.

3. Assurez-vous que la valeur du taux de mise en forme configurée est égale à la bande passante de l’interface physique.

4. Si les taux de mise en forme sont correctement configurés et que la gigue persiste, contactez le Centre d’assistance technique de Juniper Networks (JTAC).

Problème

Solution

Lorsque LFI est activé, les paquets de données (non-LFI) sont encapsulés avec un en-tête MLPPP et fragmentés en paquets d’une taille spécifiée. Les paquets vocaux sensibles au retard (LFI) sont encapsulés en PPP et entrelacés entre les fragments de paquets de données. La mise en file d’attente et l’équilibrage de charge sont effectués différemment pour les paquets LFI et non-LFI.

Pour vérifier que LFI est exécuté correctement, déterminez que les paquets sont fragmentés et encapsulés comme configuré. Une fois que vous savez si un paquet est traité comme un paquet LFI ou un paquet non-LFI, vous pouvez vérifier si l’équilibrage de charge est effectué correctement.

Solution Scenario—Supposons que deux équipements Juniper Networks, R0 et R1, soient connectés par un faisceau de liaisons lsq-0/0/0.0 multiples qui agrège deux liaisons série, se-1/0/0 et se-1/0/1. Sur R0 et R1, MLPPP et LFI sont activés sur l’interface des services de liaison et le seuil de fragmentation est défini sur 128 octets.

Dans cet exemple, nous avons utilisé un générateur de paquets pour générer des flux vocaux et de données. Vous pouvez utiliser la fonctionnalité de capture de paquets pour capturer et analyser les paquets sur l’interface entrante.

Les deux flux de données suivants ont été envoyés sur le bundle multilink :

• 100 paquets de données de 200 octets (supérieurs au seuil de fragmentation)

• 500 paquets de données de 60 octets (inférieur au seuil de fragmentation)

Les deux flux vocaux suivants ont été envoyés sur le bundle multilink :

• 100 paquets vocaux de 200 octets à partir du port source 100

• 300 paquets vocaux de 200 octets à partir du port source 200

Pour vérifier que LFI et l’équilibrage de charge sont effectués correctement :

1. Vérifiez la fragmentation des paquets. À partir du mode opérationnel, entrez la show interfaces lsq-0/0/0 commande pour vérifier que les paquets volumineux sont correctement fragmentés.

   Meaning: la sortie affiche un récapitulatif des paquets transitant par le périphérique sur le faisceau de liaisons multiples. Vérifiez les informations suivantes sur le bundle multilink :

   • Le nombre total de paquets en transit = 1000

   • Le nombre total de fragments en transit = 1100

   • Le nombre de paquets de données fragmentés = 100

   Le nombre total de paquets envoyés (600 + 400) sur le bundle multilink correspond au nombre de paquets en transit (1000), ce qui indique qu’aucun paquet n’a été abandonné.

   Le nombre de fragments en transit dépasse de 100 le nombre de paquets en transit, ce qui indique que 100 paquets de données volumineux ont été correctement fragmentés.

   Corrective Action: si les paquets ne sont pas fragmentés correctement, vérifiez la configuration de votre seuil de fragmentation. Les paquets inférieurs au seuil de fragmentation spécifié ne sont pas fragmentés.

2. Vérifiez l’encapsulation des paquets. Pour savoir si un paquet est traité comme un paquet LFI ou non-LFI, déterminez son type d’encapsulation. Les paquets LFI sont encapsulés en PPP, et les paquets non-LFI sont encapsulés en PPP et MLPPP. Les encapsulations PPP et MLPPP ont des overheads différents, ce qui donne des paquets de tailles différentes. Vous pouvez comparer la taille des paquets pour déterminer le type d’encapsulation.

   Un petit paquet de données non fragmenté contient un en-tête PPP et un seul en-tête MLPPP. Dans un paquet de données fragmenté volumineux, le premier fragment contient un en-tête PPP et un en-tête MLPPP, mais les fragments consécutifs ne contiennent qu’un en-tête MLPPP.

   Les encapsulations PPP et MLPPP ajoutent le nombre d’octets suivant à un paquet :

   • L’encapsulation PPP ajoute 7 octets :

     4 octets d’en-tête + 2 octets de séquence de vérification de trame (FCS) + 1 octet inactif ou contenant un indicateur

   • L’encapsulation MLPPP ajoute entre 6 et 8 octets :

     4 octets d’en-tête PPP + 2 à 4 octets d’en-tête multiliaison

   Figure 1 affiche la surcharge ajoutée aux en-têtes PPP et MLPPP.

   Figure 1 : En-têtes PPP et MLPPP

   Pour les paquets CRTP, la surcharge d’encapsulation et la taille des paquets sont encore plus petites que pour un paquet LFI. Pour plus d’informations, reportez-vous à la section Exemple : Configuration du protocole de transport en temps réel compressé.

   Tableau 6 Affiche la surcharge d’encapsulation pour un paquet de données et un paquet vocal de 70 octets chacun. Après encapsulation, la taille du paquet de données est supérieure à la taille du paquet vocal.

   Tableau 6 : Encapsulation PPP et MLPPP

   Type de paquet	Encapsulation	Taille initiale du paquet	Encapsulation Overhead	Taille du paquet après encapsulation
   Paquet vocal (LFI)	PPP	70 octets	4 + 2 + 1 = 7 octets	77 octets
   Fragment de données (non-LFI) avec séquence courte	Le MLPPP	70 octets	4 + 2 + 1 + 4 + 2 = 13 octets	83 octets
   Fragment de données (non-LFI) avec séquence longue	Le MLPPP	70 octets	4 + 2 + 1 + 4 + 4 = 15 octets	85 octets

   À partir du mode opérationnel, entrez la show interfaces queue commande pour afficher la taille du paquet transmis sur chaque file d’attente. Divisez le nombre d’octets transmis par le nombre de paquets pour obtenir la taille des paquets et déterminer le type d’encapsulation.

3. Vérifiez l’équilibrage de charge. En mode opérationnel, entrez la show interfaces queue commande sur le bundle multilink et ses liens constitutifs pour vérifier si l’équilibrage de charge est correctement effectué sur les paquets.

   Meaning: la sortie de ces commandes affiche les paquets transmis et mis en file d’attente sur chaque file d’attente de l’interface de services de liaison et de ses liens constitutifs. Tableau 7 affiche un récapitulatif de ces valeurs. (Étant donné que le nombre de paquets transmis est égal au nombre de paquets en file d’attente sur toutes les liaisons, ce tableau affiche uniquement les paquets en file d’attente.)

   Tableau 7 : Nombre de paquets transmis dans une file d’attente

   Paquets en file d’attente	Bundle lsq-0/0/0.0	Lien constitutif se-1/0/0	Lien constitutif se-1/0/1	Explication
   Paquets au T0	600	350	350	Le nombre total de paquets transitant par les liens constitutifs (350 + 350 = 700) dépassait le nombre de paquets en file d’attente (600) sur le faisceau de liaisons multiples.
   Paquets au T2	400	100	300	Le nombre total de paquets transitant par les liens constitutifs était égal au nombre de paquets sur le faisceau.
   Paquets au T3	0	19	18	Les paquets transitant Q3 des liens constitutifs sont destinés aux messages keepalive échangés entre les liens constitutifs. Ainsi, aucun paquet n’a été compté sur Q3 du paquet.

   Sur le bundle de liens multiples, vérifiez les points suivants :

   • Le nombre de paquets mis en file d’attente correspond au nombre de paquets transmis. Si les nombres correspondent, aucun paquet n’a été abandonné. S’il y avait plus de paquets en file d’attente que de paquets transmis, ils étaient abandonnés car la mémoire tampon était trop petite. La taille de la mémoire tampon sur les liens constitutifs contrôle l’encombrement à l’étape de sortie. Pour corriger ce problème, augmentez la taille de la mémoire tampon sur les liens constitutifs.

   • Le nombre de paquets transitant par Q0 (600) correspond au nombre de paquets de données de grande et de petite taille reçus (100+500) sur le bundle multilink. Si les nombres correspondent, tous les paquets de données ont correctement transité Q0.

   • Le nombre de paquets transitant Q2 sur le faisceau multiliaison (400) correspond au nombre de paquets vocaux reçus sur le faisceau multiliaison. Si les chiffres correspondent, tous les paquets LFI vocaux ont correctement transité Q2.

   Sur les liens constitutifs, vérifiez les points suivants :

   • Le nombre total de paquets transitant Q0 (350+350) correspond au nombre de paquets de données et de fragments de données (500+200). Si les nombres correspondent, tous les paquets de données après fragmentation ont correctement transité Q0 des liens constitutifs.

     Les paquets transitaient par les deux liaisons constitutives, ce qui indique que l’équilibrage de charge était correctement effectué sur les paquets non-LFI.

   • Le nombre total de paquets transitant Q2 (300+100) sur les liaisons constitutives correspond au nombre de paquets vocaux reçus (400) sur le faisceau de liaisons multiples. Si les chiffres correspondent, tous les paquets LFI vocaux ont correctement transité Q2.

     Les paquets LFI du port 100 source ont transité se-1/0/0par , et les paquets LFI du port 200 source ont transité se-1/0/1. Ainsi, tous les paquets LFI (Q2) ont été hachés en fonction du port source et ont correctement transité par les deux liens constitutifs.

   Corrective Action: si les paquets n’ont transité qu’une seule liaison, procédez comme suit pour résoudre le problème :

   1. Déterminez si la liaison physique est up (opérationnelle) ou down (indisponible). Une liaison indisponible indique un problème au niveau du PIM, du port d’interface ou de la connexion physique (erreurs de couche de liaison). Si le lien est opérationnel, passez à l’étape suivante.

   2. Vérifiez que les classificateurs sont correctement définis pour les paquets non-LFI. Assurez-vous que les paquets non-LFI ne sont pas configurés pour être mis en file d’attente Q2. Tous les paquets mis en file d’attente Q2 sont traités comme des paquets LFI.

   3. Vérifiez qu’au moins une des valeurs suivantes est différente dans les paquets LFI : l’adresse source, l’adresse de destination, le protocole IP, le port source ou le port de destination. Si les mêmes valeurs sont configurées pour tous les paquets LFI, les paquets sont tous hachés vers le même flux et transitent par la même liaison.

4. Utilisez les résultats pour vérifier l’équilibrage de charge.

Problème

Solution

Si l’équipement tiers ne prend pas en charge FRF.12 de la même manière que l’équipement Juniper Networks ou s’il prend en charge FRF.12 d’une manière différente, l’interface de l’équipement Juniper Networks sur le circuit circuit virtuel permanent peut ignorer un paquet fragmenté contenant des en-têtes FRF.12 et le considérer comme un « rejet contrôlé ».

Pour contourner ce problème, configurez les bundles multiliens sur les deux homologues et configurez les seuils de fragmentation sur les bundles multilinks.

Problème

• Description
• Environnement
• Symptômes

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.

Problème

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.

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.

Problème

Solution

Problème

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

Problème

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.

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

[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  

[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}

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

Problème

Solution

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

Problème

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.

Problème

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.

Problème

Solution

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

Problème

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.