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 :
ping host count number
Exemple de sortie
nom_commande
ping host3 count 4 user@switch> ping host3 count 4 PING host3.site.net (192.0.2.111): 56 data bytes 64 bytes from 192.0.2.111: icmp_seq=0 ttl=122 time=0.661 ms 64 bytes from 192.0.2.111: icmp_seq=1 ttl=122 time=0.619 ms 64 bytes from 192.0.2.111: icmp_seq=2 ttl=122 time=0.621 ms 64 bytes from 192.0.2.111: icmp_seq=3 ttl=122 time=0.634 ms --- host3.site.net ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.619/0.634/0.661/0.017 ms
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
- Affichage des statistiques en temps réel sur une interface sur le routeur ou le commutateur
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 :
user@host> monitor interface traffic
Exemple de sortie
nom_commande
user@host> monitor interface traffic host name Seconds: 15 Time: 12:31:09 Interface Link Input packets (pps) Output packets (pps) so-1/0/0 Down 0 (0) 0 (0) so-1/1/0 Down 0 (0) 0 (0) so-1/1/1 Down 0 (0) 0 (0) so-1/1/2 Down 0 (0) 0 (0) so-1/1/3 Down 0 (0) 0 (0) t3-1/2/0 Down 0 (0) 0 (0) t3-1/2/1 Down 0 (0) 0 (0) t3-1/2/2 Down 0 (0) 0 (0) t3-1/2/3 Down 0 (0) 0 (0) so-2/0/0 Up 211035 (1) 36778 (0) so-2/0/1 Up 192753 (1) 36782 (0) so-2/0/2 Up 211020 (1) 36779 (0) so-2/0/3 Up 211029 (1) 36776 (0) so-2/1/0 Up 189378 (1) 36349 (0) so-2/1/1 Down 0 (0) 18747 (0) so-2/1/2 Down 0 (0) 16078 (0) so-2/1/3 Up 0 (0) 80338 (0) at-2/3/0 Up 0 (0) 0 (0) at-2/3/1 Down 0 (0) 0 (0) Bytes=b, Clear=c, Delta=d, Packets=p, Quit=q or ESC, Rate=r, Up=^U, Down=^D
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 :
user@host> monitor interface interface-name
Exemple de sortie
nom_commande
user@host> monitor interface so-0/0/1 Next='n', Quit='q' or ESC, Freeze='f', Thaw='t', Clear='c', Interface='i' R1 Interface: so-0/0/1, Enabled, Link is Up Encapsulation: PPP, Keepalives, Speed: OC3 Traffic statistics: Input bytes: 5856541 (88 bps) Output bytes: 6271468 (96 bps) Input packets: 157629 (0 pps) Output packets: 157024 (0 pps) Encapsulation statistics: Input keepalives: 42353 Output keepalives: 42320 LCP state: Opened Error statistics: Input errors: 0 Input drops: 0 Input framing errors: 0 Input runts: 0 Input giants: 0 Policed discards: 0 L3 incompletes: 0 L2 channel errors: 0 L2 mismatch timeouts: 0 Carrier transitions: 1 Output errors: 0 Output drops: 0 Aged packets: 0 Active alarms : None Active defects: None SONET error counts/seconds: LOS count 1 LOF count 1 SEF count 1 ES-S 77 SES-S 77 SONET statistics: BIP-B1 0 BIP-B2 0 REI-L 0 BIP-B3 0 REI-P 0 Received SONET overhead: F1 : 0x00 J0 : 0xZ
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.
Action |
Clé |
---|---|
Affichez des informations sur l’interface suivante. La |
|
Affichez des informations sur une autre interface. La commande vous invite à entrer le nom d’une interface spécifique. |
|
Figer l’affichage, interrompant l’affichage des statistiques mises à jour. |
|
Dégelez l’affichage, reprenant l’affichage des statistiques mises à jour. |
|
Effacez (zéro) les compteurs delta actuels depuis |
|
Arrêtez la |
|
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
- Fonctionnalités utilisant la ressource TCAM
- Surveillance de l’utilisation des ressources TCAM
- Exemple : Surveillance et dépannage de la ressource TCAM
- Surveillance et dépannage des ressources TCAM dans les routeurs ACX Series
- Mise à l’échelle des services sur les routeurs ACX5048 et ACX5096
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.
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.
Tâche |
Commande |
---|---|
Afficher les applications partagées et associées pour une application particulière |
|
Affichage de l’utilisation des ressources TCAM pour une application et les étapes (sortie, entrée et pré-entrée) |
|
Affichez les erreurs d’utilisation des ressources TCAM pour les applications et les étapes (sortie, entrée et pré-entrée) |
|
Efface les statistiques d’erreur d’utilisation des ressources TCAM pour les applications et les étapes (sortie, entrée et pré-entrée) |
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.
-
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 lashow pfe filter hw summary
commande pour afficher la ressource TCAM usgae.user@host> show pfe tcam usage all-tcam-stages detail Slot 0 Tcam Resource Stage: Pre-Ingress -------------------------------- Free [hw-grps: 3 out of 3] No dynamic tcam usage Tcam Resource Stage: Ingress ---------------------------- Free [hw-grps: 2 out of 8] Group: 11, Mode: SINGLE, Hw grps used: 3, Tcam apps: 2 Used Allocated Available Errors Tcam-Entries 800 1024 224 0 Counters 800 1024 224 0 Policers 0 1024 1024 0 App tcam usage: ---------------- App-Name Entries Counters Policers Precedence State Related-App-Name .. ----------------------------------------------------------------- cfm-filter 500 500 0 3 OK cfm-bd-filter 300 300 0 2 OK Group: 8, Mode: DOUBLE, Hw grps used: 2, Tcam apps: 1 Used Allocated Available Errors Tcam-Entries 500 512 12 0 Counters 500 1024 524 0 Policers 0 1024 1024 0 App tcam usage: ---------------- App-Name Entries Counters Policers Precedence State Related-App-Name .. ----------------------------------------------------------------- fw-l2-in 500 500 0 2 OK fw-semantics 0 X X 1 OK Group: 14, Mode: SINGLE, Hw grps used: 1, Tcam apps: 1 Used Allocated Available Errors Tcam-Entries 200 512 312 0 Counters 200 512 312 0 Policers 100 512 412 0 App tcam usage: ---------------- App-Name Entries Counters Policers Precedence State Related-App-Name .. ----------------------------------------------------------------- fw-ifl-in 200 200 100 1 OK Tcam Resource Stage: Egress --------------------------- Free [hw-grps: 3 out of 3] No dynamic tcam usage
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 lashow 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.[Sat Jul 11 16:10:33.794 LOG: Err] ACX Error (dfw):acx_dfw_check_phy_slice_availability :Insufficient phy slices to accomodate grp:13/IN_IFF_BRIDGE mode:1/DOUBLE [Sat Jul 11 16:10:33.794 LOG: Err] ACX Error (dfw):acx_dfw_check_resource_availability :Could not write filter: f-bridge-ge-0/0/0.103-i, insufficient TCAM resources [Sat Jul 11 16:10:33.794 LOG: Err] ACX Error (dfw):acx_dfw_update_filter_in_hw :acx_dfw_check_resource_availability failed for filter:f-bridge-ge-0/0/0.103-i [Sat Jul 11 16:10:33.794 LOG: Err] ACX Error (dfw):acx_dfw_create_hw_instance :Status:1005 Could not program dfw(f-bridge-ge-0/0/0.103-i) type(IN_IFF_BRIDGE)! [1005] [Sat Jul 11 16:10:33.794 LOG: Err] ACX Error (dfw):acx_dfw_bind_shim :[1005] Could not create dfw(f-bridge-ge-0/0/0.103-i) type(IN_IFF_BRIDGE) [Sat Jul 11 16:10:33.794 LOG: Err] ACX Error (dfw):acx_dfw_bind :[1000] bind failed for filter f-bridge-ge-0/0/0.103-i
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 :user@host> show pfe tcam errors all-tcam-stages detail Slot 0 Tcam Resource Stage: Pre-Ingress -------------------------------- Free [hw-grps: 3 out of 3] No dynamic tcam usage Tcam Resource Stage: Ingress ---------------------------- Free [hw-grps: 2 out of 8] Group: 11, Mode: SINGLE, Hw grps used: 3, Tcam apps: 2 Used Allocated Available Errors Tcam-Entries 960 1024 64 0 Counters 960 1024 64 0 Policers 0 1024 1024 0 App tcam usage: ---------------- App-Name Entries Counters Policers Precedence State Related-App-Name .. ----------------------------------------------------------------- cfm-filter 600 600 0 3 OK cfm-bd-filter 360 360 0 2 OK Group: 8, Mode: DOUBLE, Hw grps used: 2, Tcam apps: 1 Used Allocated Available Errors Tcam-Entries 510 512 2 18 Counters 510 1024 514 0 Policers 0 1024 1024 0 App tcam usage: ---------------- App-Name Entries Counters Policers Precedence State Related-App-Name .. ----------------------------------------------------------------- fw-l2-in 510 510 0 2 FAILED fw-semantics 0 X X 1 OK App error statistics: ---------------------- App-Name Entries Counters Policers Precedence State Related-App-Name .. ----------------------------------------------------------------- fw-l2-in 18 0 0 2 FAILED fw-semantics 0 X X 1 OK Group: 14, Mode: SINGLE, Hw grps used: 1, Tcam apps: 1 Used Allocated Available Errors Tcam-Entries 240 512 272 0 Counters 240 512 272 0 Policers 120 512 392 0 App tcam usage: ---------------- App-Name Entries Counters Policers Precedence State Related-App-Name .. ----------------------------------------------------------------- fw-ifl-in 240 240 120 1 OK Tcam Resource Stage: Egress --------------------------- Free [hw-grps: 3 out of 3] No dynamic tcam usage
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.
-
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 etshow 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 lashow pfe filter hw summary
commande to pour afficher l’utilisation des ressources TCAM.user@host> show pfe tcam usage all-tcam-stages detail Slot 0 Tcam Resource Stage: Pre-Ingress -------------------------------- Free [hw-grps: 3 out of 3] No dynamic tcam usage Tcam Resource Stage: Ingress ---------------------------- Free [hw-grps: 2 out of 8] Group: 11, Mode: SINGLE, Hw grps used: 3, Tcam apps: 2 Used Allocated Available Errors Tcam-Entries 800 1024 224 0 Counters 800 1024 224 0 Policers 0 1024 1024 0 App tcam usage: ---------------- App-Name Entries Counters Policers Precedence State Related-App-Name .. ----------------------------------------------------------------- cfm-filter 500 500 0 3 OK cfm-bd-filter 300 300 0 2 OK Group: 8, Mode: DOUBLE, Hw grps used: 2, Tcam apps: 1 Used Allocated Available Errors Tcam-Entries 500 512 12 18 Counters 500 1024 524 0 Policers 0 1024 1024 0 App tcam usage: ---------------- App-Name Entries Counters Policers Precedence State Related-App-Name .. ----------------------------------------------------------------- fw-l2-in 500 500 0 2 OK fw-semantics 0 X X 1 OK Group: 14, Mode: SINGLE, Hw grps used: 1, Tcam apps: 1 Used Allocated Available Errors Tcam-Entries 200 512 312 0 Counters 200 512 312 0 Policers 100 512 412 0 App tcam usage: ---------------- App-Name Entries Counters Policers Precedence State Related-App-Name .. ----------------------------------------------------------------- fw-ifl-in 200 200 100 1 OK Tcam Resource Stage: Egress --------------------------- Free [hw-grps: 3 out of 3] No dynamic tcam usage
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.user@host> show pfe tcam errors all-tcam-stages detail Slot 0 Tcam Resource Stage: Pre-Ingress -------------------------------- No tcam usage Tcam Resource Stage: Ingress ---------------------------- Group: 11, Mode: SINGLE, Hw grps used: 3, Tcam apps: 2 Errors Resource-Shortage Tcam-Entries 0 0 Counters 0 0 Policers 0 0 Group: 8, Mode: DOUBLE, Hw grps used: 2, Tcam apps: 1 Errors Resource-Shortage Tcam-Entries 18 0 Counters 0 0 Policers 0 0 Group: 14, Mode: SINGLE, Hw grps used: 1, Tcam apps: 1 Errors Resource-Shortage Tcam-Entries 0 0 Counters 0 0 Policers 0 0 Tcam Resource Stage: Egress --------------------------- No tcam usage
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é.
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.
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
Comment |
Commande |
---|---|
Affichez les applications partagées et associées pour une application particulière. |
|
Affichez le nombre d’applications sur toutes les étapes tcam. |
|
Affichez le nombre d’applications utilisant la ressource TCAM à une étape spécifiée. |
|
Affichez en détail la ressource TCAM utilisée par une application. |
|
Affichez la ressource TCAM utilisée par une application à une étape spécifiée. |
|
Connaître le nombre de ressources TCAM consommées par une tcam-app |
|
Affichez les erreurs d’utilisation des ressources TCAM pour toutes les étapes. |
|
Afficher les erreurs d’utilisation des ressources TCAM pour une étape |
|
Affichez les erreurs d’utilisation des ressources TCAM pour une application. |
|
Affichez les erreurs d’utilisation des ressources TCAM pour une application ainsi que pour ses autres applications partagées. |
|
Effacez les statistiques d’erreur d’utilisation des ressources TCAM pour toutes les étapes. |
|
Effacer les statistiques d’erreur d’utilisation des ressources TCAM pour une étape spécifiée |
|
Effacez les statistiques d’erreur d’utilisation des ressources TCAM d’une application. |
|
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.
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.
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.
Voir également
Dépannage de l’interface des services de liaison
Pour résoudre les problèmes de configuration sur une interface de services de liaison :
- Déterminer quels composants CoS sont appliqués aux liens constitutifs
- Déterminez les causes de la gigue et de la latence sur le bundle de liaisons multiples
- Déterminez si le LFI et l’équilibrage de charge fonctionnent correctement
- Déterminer pourquoi des paquets sont abandonnés sur un circuit virtuel virtuel entre un équipement Juniper Networks et un équipement tiers
Déterminer quels composants CoS sont appliqués aux liens constitutifs
Problème
Description
Vous configurez un bundle multilink, mais vous avez également du trafic sans encapsulation MLPPP qui passe par les liens constitutifs du bundle multilink. Appliquez-vous tous les composants CoS aux liens constitutifs ou leur application au bundle de liaisons multiples est-elle suffisante ?
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.
Composant Cos |
Bundle multiliens |
Liens constitutifs |
Explication |
---|---|---|---|
Classificateur |
Oui |
Non |
La classification CoS a lieu du côté entrant de l’interface, et non du côté émetteur, de sorte qu’aucun classificateur n’est nécessaire sur les liaisons constitutives. |
Classe de transfert |
Oui |
Non |
La classe de transfert est associée à une file d’attente, et la file d’attente est appliquée à l’interface par un mappage de planificateur. L’affectation de la file d’attente est prédéterminée sur les liens constitutifs. Tous les paquets de Q2 du bundle multilink sont affectés à Q2 du lien constitutif, et les paquets de toutes les autres files d’attente sont mis en file d’attente à Q0 du lien constitutif. |
Carte du planificateur |
Oui |
Oui |
Appliquez les cartes du planificateur sur le faisceau de liaisons multiples et le lien constitutif comme suit :
|
Taux de mise en forme d’un planificateur unitaire ou d’un planificateur au niveau de l’interface |
Non |
Oui |
Étant donné que la planification par unité n’est appliquée qu’au point d’extrémité, appliquez ce taux de mise en forme aux liens constitutifs uniquement. Toute configuration appliquée précédemment est remplacée par la configuration du lien constitutif. |
Mise en forme exacte du débit de transmission ou au niveau de la file d’attente |
Oui |
Non |
La mise en forme au niveau de l’interface appliquée aux liens constitutifs remplace toute mise en forme de la file d’attente. Appliquez donc la mise en forme exacte du débit de transmission uniquement sur le faisceau multiliaison. |
Règles de réécriture |
Oui |
Non |
Les bits de réécriture sont automatiquement copiés du paquet dans les fragments lors de la fragmentation. Ainsi, ce que vous configurez sur le faisceau de liens multiples est transporté sur les fragments vers les liens constitutifs. |
Groupe de canaux virtuels |
Oui |
Non |
Les groupes de canaux virtuels sont identifiés à l’aide de règles de filtre de pare-feu qui sont appliquées aux paquets uniquement avant le bundle de liaisons multiples. Ainsi, vous n’avez pas besoin d’appliquer la configuration du groupe de canaux virtuels aux liens constitutifs. |
Voir également
Déterminez les causes de la gigue et de la latence sur le bundle de liaisons multiples
Problème
Description
Pour tester la gigue et la latence, vous envoyez trois flux de paquets IP. Tous les paquets ont les mêmes paramètres de priorité IP. Après la configuration de LFI et CRTP, la latence augmentait même sur une liaison non encombrée. Comment réduire la gigue et la latence ?
Solution
Pour réduire la gigue et la latence, procédez comme suit :
Assurez-vous d’avoir configuré un taux de mise en forme sur chaque lien constitutif.
Assurez-vous que vous n’avez pas configuré de taux de mise en forme sur l’interface des services de liaison.
Assurez-vous que la valeur du taux de mise en forme configurée est égale à la bande passante de l’interface physique.
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).
Déterminez si le LFI et l’équilibrage de charge fonctionnent correctement
Problème
Description
Dans ce cas, vous disposez d’un seul réseau qui prend en charge plusieurs services. Le réseau transmet les données et le trafic vocal sensible à la latence. Après avoir configuré MLPPP et LFI, assurez-vous que les paquets vocaux sont transmis sur le réseau avec très peu de retard et de gigue. Comment savoir si les paquets vocaux sont traités comme des paquets LFI et si l’équilibrage de charge est correctement effectué ?
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 :
Seules les parties significatives de la sortie de la commande sont affichées et décrites dans cet exemple.
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.user@R0#> show interfaces lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Link-level type: LinkService, MTU: 1504 Device flags : Present Running Interface flags: Point-To-Point SNMP-Traps Last flapped : 2006-08-01 10:45:13 PDT (2w0d 06:06 ago) Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface lsq-0/0/0.0 (Index 69) (SNMP ifIndex 42) Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: Multilink-PPP Bandwidth: 16mbps Statistics Frames fps Bytes bps Bundle: Fragments: Input : 0 0 0 0 Output: 1100 0 118800 0 Packets: Input : 0 0 0 0 Output: 1000 0 112000 0 ... Protocol inet, MTU: 1500 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 9.9.9/24, Local: 9.9.9.10
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.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 MLPPPPour 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.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.user@R0> show interfaces queue lsq-0/0/0 Physical interface: lsq-0/0/0, Enabled, Physical link is Up Interface index: 136, SNMP ifIndex: 29 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 600 0 pps Bytes : 44800 0 bps Transmitted: Packets : 600 0 pps Bytes : 44800 0 bps Tail-dropped packets : 0 0 pps RED-dropped packets : 0 0 pps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 400 0 pps Bytes : 61344 0 bps Transmitted: Packets : 400 0 pps Bytes : 61344 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 0 0 pps Bytes : 0 0 bps …
user@R0> show interfaces queue se-1/0/0 Physical interface: se-1/0/0, Enabled, Physical link is Up Interface index: 141, SNMP ifIndex: 35 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps ... Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 100 0 pps Bytes : 15272 0 bps Transmitted: Packets : 100 0 pps Bytes : 15272 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 19 0 pps Bytes : 247 0 bps Transmitted: Packets : 19 0 pps Bytes : 247 0 bps …
user@R0> show interfaces queue se-1/0/1 Physical interface: se-1/0/1, Enabled, Physical link is Up Interface index: 142, SNMP ifIndex: 38 Forwarding classes: 8 supported, 8 in use Egress queues: 8 supported, 8 in use Queue: 0, Forwarding classes: DATA Queued: Packets : 350 0 pps Bytes : 24350 0 bps Transmitted: Packets : 350 0 pps Bytes : 24350 0 bps … Queue: 1, Forwarding classes: expedited-forwarding Queued: Packets : 0 0 pps Bytes : 0 0 bps … Queue: 2, Forwarding classes: VOICE Queued: Packets : 300 0 pps Bytes : 45672 0 bps Transmitted: Packets : 300 0 pps Bytes : 45672 0 bps … Queue: 3, Forwarding classes: NC Queued: Packets : 18 0 pps Bytes : 234 0 bps Transmitted: Packets : 18 0 pps Bytes : 234 0 bps
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/0
par , et les paquets LFI du port200
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 :Déterminez si la liaison physique est
up
(opérationnelle) oudown
(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.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.
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.
Utilisez les résultats pour vérifier l’équilibrage de charge.
Déterminer pourquoi des paquets sont abandonnés sur un circuit virtuel virtuel entre un équipement Juniper Networks et un équipement tiers
Problème
Description
Vous configurez un circuit virtuel permanent (PVC) entre les interfaces T1, E1, T3 ou E3 sur un équipement Juniper Networks et un équipement tiers, et des paquets sont abandonnés et la commande ping échoue.
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.
Dépannage des stratégies de sécurité
- Synchronisation des stratégies entre le moteur de routage et le moteur de transfert de paquets
- Vérification de l’échec d’une validation de stratégie de sécurité
- Vérification d’une validation de stratégie de sécurité
- Recherche de stratégie de débogage
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.
Voir également
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 :
Vérifiez vos données de configuration.
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
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.
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’utilisateurshow
. Si vous ne parvenez pas à déterminer l’indicateur à utiliser, l’optionall
d’indicateur peut être utilisée pour capturer tous les journaux de suivi.user@host#
set security policies traceoptions <flag all>
Vous pouvez également configurer un nom de fichier facultatif pour capturer les journaux.
user@host# set security policies traceoptions <filename>
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
user@host# set security policies traceoptions <flag lookup>
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.