Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Résilience de la fabric

Résilience et dégradation de la fabric

Les routeurs et commutateurs Juniper intègrent une résilience permettant de faire face aux pannes et aux conditions d’erreur rencontrées en fonctionnement normal. Le logiciel JUNOS prend immédiatement des mesures pour remédier aux conditions de défaillance et minimiser les pertes de trafic. Aucune intervention manuelle n’est nécessaire. La dégradation de la structure peut être l’une des raisons à l’origine de ces conditions d’erreur. Les sections suivantes expliquent comment les PFE se rétablissent de manière résiliente après ces défaillances.

Erreurs et récupération du moteur de transfert de paquets sur les routeurs PTX Series

Les destinations du moteur de transfert de paquets peuvent devenir inaccessibles sur les routeurs PTX Series pour les raisons suivantes :

  • Les cartes d’interface de commutation (SIB) de la structure sont hors ligne à la suite d’une commande CLI.

  • Les SIB de la fabric sont mis hors ligne par la carte de contrôle en raison des conditions de température élevée.

  • Les erreurs d’E/S de tension ou d’interrogation dans les SIB sont détectées par la carte de contrôle.

  • Des erreurs inattendues d’entraînement de liaison se produisent sur tous les plans connectés.

  • Deux moteurs de transfert de paquets peuvent atteindre la fabric, mais pas l’un l’autre.

  • Des erreurs de liaison se produisent lorsque deux moteurs de transfert de paquets sont connectés à la structure, mais pas via un plan commun.

À partir de la version 13.3 de Junos OS, vous pouvez utiliser les routeurs PTX Series pour configurer les niveaux d’erreur liés au moteur de transfert de paquets (PFE) et les actions à effectuer lorsqu’un seuil spécifié est atteint.

Si aucun niveau d’erreur n’est défini, un routeur PTX Series entame les phases suivantes du processus de récupération :

  1. Phase de redémarrage des SIB : le routeur tente de résoudre le problème en redémarrant les SIB un par un. Cette phase ne démarre pas si les SIB fonctionnent correctement et qu’une carte de ligne unique rencontre un problème.

  2. Phase de redémarrage de la carte SIB et de la carte de ligne : le routeur redémarre à la fois les SIB et la carte de ligne. Si certaines cartes de ligne ne sont pas en mesure d’établir des liens haut débit vers la fabric après le redémarrage, cela n’est pas pertinent pour la perte de trafic actif, car aucune interface n’est créée pour ces cartes de ligne, ce qui évite des problèmes au système.

  3. Phase hors ligne de la carte de ligne : en raison de l’échec des tentatives précédentes de récupération, les cartes de ligne et les interfaces sont désactivées et le système évite les problèmes et les conditions d’erreur.

Résilience de la fabric et récupération automatique de la fabric dégradée

À partir de la version 23.4R1 de Junos Evolved, la fonctionnalité de récupération automatique de la structure est disponible pour limiter la perte de données. Les mesures de récupération effectuées incluent le redémarrage de la FRU, le redémarrage de la liaison, etc.

Les actions de récupération de fabric en trois phases suivantes sont tentées au niveau de la FRU :

1. Récupération au niveau de la FRU à l’aide du redémarrage SIB.

2. Récupération du niveau FRU à l’aide du redémarrage FPC ou du redémarrage PFE.

3. Action en cas de PFE irrécupérables, de désactivation de l’IFD ou de PFE hors ligne.

Note: Pour les plates-formes qui ne prennent pas en charge le redémarrage PFE, le redémarrage FPC est fourni comme action par défaut.

Action de récupération de fabric pour les conditions de défaillance SIB : Pour les problèmes d’accessibilité dus à l’absence d’un SIB (utilisateur hors ligne ou SIB absent lors de la mise sous tension du système), la résilience de la fabric ne tente pas de récupération. Dans les systèmes qui ne prennent pas en charge la récupération de fabric, des alarmes de châssis sont générées en cas de problèmes d’accessibilité.

Action de récupération du niveau de PFE sur les routeurs PTX Series (routeurs PTX10004, PTX10008 et PTX10016)

Pour les plates-formes qui peuvent prendre en charge le redémarrage PFE, le redémarrage PFE sera ajouté en tant qu’action de récupération de phase 2 par défaut.

Note: Dans les ASIC comportant plusieurs PFE, le redémarrage affecte les PPFE (PFE par plan), de la même manière que l’action hors ligne des PFE.
La décision de rétablissement pour l’action de phase 2 est prise pour l’un ou l’autre des scénarios suivants :
  • Les PFE présentant des défauts d’accessibilité résident tous dans un seul FPC.
  • PFE présentant des défauts d’accessibilité (dans un ou plusieurs FPC) et n’ayant pas de défaillance commune.

La récupération de phase 2 est tentée sur les PPFE qui n’ont pas récupéré de défauts d’accessibilité après la récupération de phase 1.

Si le nombre de PFE présentant des défauts d’auto-accessibilité dans un FPC est égal ou supérieur à 50 % des PFE, le FPC sera redémarré.

Utilisez l’option CLI suivante pour configurer manuellement l’action de redémarrage PFE par défaut :

Le tableau suivant présente les mesures à prendre lors de la phase 2 de récupération, en fonction de la configuration et du nombre de PFE en cause dans un FPC.

Décision de recouvrement Nombre de PFE impliqués dans le FPC Redémarrage PFE pris en charge Désactiver le redémarrage PFE Désactiver le redémarrage FPC Action
Action de la phase 2 < = 50 % Oui Non x Redémarrage du PFE
Action de la phase 2 < = 50 % Oui Oui Non Redémarrage du FPC
Action de la phase 2 < = 50 % Oui Oui Oui Redémarrage du PFE
Action de la phase 2 >50 % Oui x Non Redémarrage du FPC
Action de la phase 2 >50 % Oui Oui Oui Redémarrage du PFE
Action de la phase 2 >50 % Oui Non Oui Redémarrage du PFE

Erreurs et récupération du moteur de transfert de paquets sur les routeurs matriciels T640, T1600 ou TX

Les destinations du moteur de transfert de paquets peuvent devenir inaccessibles sur les routeurs matriciels T640, T1600 ou TX pour les raisons suivantes :

  • Les cartes d’interface de commutation (SIB) de la fabric sont hors ligne lorsqu’une commande CLI ou un bouton physique est enfoncé.

  • En raison des conditions de température élevée, les SIB de la fabric sont mises hors ligne par la carte mezzanine du processeur de commutation (SPMB).

  • Les erreurs d’E/S de tension ou d’interrogation dans les SIB sont détectées par le SPMB.

  • Tous les moteurs de transfert de paquets reçoivent des erreurs de destination sur tous les plans de la part de moteurs de transfert de paquets distants, même lorsque les SIB sont en ligne.

  • La perte totale de fabric est causée par les délais d’expiration de la destination, même lorsque les SIB sont en ligne.

Le processus de récupération comprend les phases suivantes :

  1. Le routeur redémarre les plans de structure un par un. Cette phase ne démarre pas si le plan de structure fonctionne correctement et qu’une carte à une seule ligne présente des problèmes.

  2. Phase de redémarrage du plan de structure et de la carte de ligne : le routeur redémarre à la fois les SIB et les cartes de ligne. Si certaines cartes de ligne ne sont pas en mesure d’établir des liens haut débit vers la fabric après le redémarrage, cela n’est pas pertinent pour la perte de trafic actif, car aucune interface n’est créée pour ces cartes de ligne, ce qui évite des problèmes au système.

  3. Phase hors ligne de la carte de ligne : en raison de l’échec des tentatives précédentes de récupération, les cartes de ligne et les interfaces sont désactivées et le système évite les problèmes et les conditions d’erreur entraînant de graves conséquences.

Note:

À partir de la version 14.2R6 de Junos OS, si un SIB est hors ligne en raison de conditions extrêmes telles qu’une haute tension ou une température élevée, le routeur ne redémarre pas le plan de structure de ce SIB dans le cadre du processus de récupération.

Le mécanisme de récupération progressive mentionné ci-dessus est exhaustif, à moins qu’il n’y ait d’autres erreurs qui pourraient être corrélées à ces problèmes.

À partir de la version 14.2R6 de Junos OS, vous pouvez mieux gérer la dégradation de la structure dans les systèmes à châssis unique en incorporant les mécanismes d’auto-pingage de la structure et de dynamique du moteur de transfert de paquets. L’auto-ping de la fabric est un mécanisme permettant de détecter les problèmes dans le chemin de données de la fabric. Grâce au mécanisme d’auto-ping de la fabric, chaque moteur de transfert de paquets vérifie qu’un paquet qui lui est destiné l’atteint lorsqu’il est envoyé sur le chemin de la fabric. La vivacité du moteur de transfert de paquets est un mécanisme permettant de détecter si un moteur de transfert de paquets est accessible sur le plan de la structure. Pour vérifier qu’il est accessible, le moteur de transfert de paquets envoie régulièrement un paquet auto-destiné sur le plan de la structure. Si une erreur est détectée par ces deux mécanismes, le gestionnaire de structure déclenche une alarme de dégradation de la structure et lance la récupération en redémarrant la carte de ligne.

Routeurs MX Series Résilience de la fabric

Les routeurs MX fournissent des mécanismes intelligents pour réduire les pertes de paquets en cas de défaillance matérielle. Les routeurs MX Series garantissent la disponibilité du réseau et des services grâce à un large éventail d’aspects de résilience physique, logique et protocolaire multicouches

MX10008 assure redondance et résilience. Tous les principaux composants matériels, y compris le système d’alimentation, le système de refroidissement et la carte de contrôle, sont entièrement redondants.

Le système d’alimentation MX10004 et le carte de contrôle de routage (RCB) assurent redondance et résilience.

Les châssis MX2020 et MX2010 assurent redondance et résilience. Tous les principaux composants matériels, y compris le système d’alimentation, le système de refroidissement, la carte de contrôle et les structures de commutation, sont entièrement redondants.

Les cartes de fabric de commutation (SFB) constituent le plan de données des sous-systèmes du châssis du routeur MX. Les SFB créent une structure de commutation centralisée « tout-active » hautement évolutive et résiliente qui offre jusqu’à 4 Tbit/s de capacité de commutation en duplex intégral à chaque emplacement MPC d’un routeur MX2000.

Les châssis MX240, MX480 et MX960 assurent redondance et résilience. Le système matériel est entièrement redondant, les alimentations, les plateaux de ventilation, les moteurs de routage et les cartes de contrôle des commutateurs sont entièrement redondants.

Le routeur MX304 contient des moteurs de routage redondants enfichables et prend en charge jusqu’à trois MIC à carte de ligne (LMIC).

Cette rubrique contient les sections suivantes qui décrivent les options de résilience de la structure, les méthodes de détection des défaillances utilisées et les actions correctives :

Restauration de la connectivité de la fabric

Les destinations du moteur de transfert de paquets peuvent devenir inaccessibles pour les raisons suivantes :

  • Les cartes de contrôle se déconnectent à la suite d’une commande CLI ou d’une pression sur un bouton physique.

  • Les cartes de contrôle de la fabric sont mises hors ligne en raison de la température élevée.

  • Erreurs d’E/S de tension ou d’interrogation dans la fabric.

  • Tous les moteurs de transfert de paquets reçoivent des erreurs de destination sur tous les plans de la part de moteurs de transfert de paquets distants, même lorsque les structures sont en ligne.

  • Perte totale de fabric causée par les délais d’expiration de destination, même lorsque les fabrics sont en ligne.

Lorsque le système détecte des destinations inaccessibles du moteur de transfert de paquets, il tente de restaurer la connectivité de la fabric. En cas d’échec de la restauration, le système désactive les interfaces pour déclencher une action de protection locale ou une réacheminement du trafic sur les routeurs adjacents.

Le processus de récupération comprend les phases suivantes :

  1. Phase de redémarrage du plan de structure : la restauration est tentée en redémarrant les plans de structure un par un. Cette phase ne démarre pas si le plan de structure fonctionne correctement et qu’une erreur est signalée par une seule carte de ligne. Un message d’erreur est généré pour indiquer qu’une perte de connectivité est la raison de la mise hors ligne du plan de structure. Cette phase est effectuée uniquement pour les erreurs sur le plan de la structure.

  2. Phase de redémarrage du plan de structure et de la carte de ligne : le système attend la fin de la première phase avant d’examiner à nouveau l’état du système. Si la connectivité n’est pas rétablie après la première phase ou si le problème se reproduit dans un délai de 10 minutes, vous tentez de restaurer la connectivité en redémarrant à la fois les plans de structure et les cartes de ligne. Si vous configurez l’instruction action-fpc-restart-disable au niveau de la [edit chassis fabric degraded] hiérarchie pour désactiver le redémarrage des cartes de ligne lors d’une tentative de récupération, une alarme se déclenche pour indiquer qu’une perte de connectivité s’est produite. Dans cette deuxième phase, trois étapes sont franchies :

    1. Toutes les cartes de ligne qui comportent des erreurs de destination sur un PFE sont désactivées.

    2. Les plans de structure sont mis hors ligne et remis en ligne, un par un, en commençant par le plan de rechange.

    3. Les cartes de ligne qui ont été mises hors ligne sont réactivées.

  3. Phase hors ligne de la carte de ligne : le système attend la fin de la deuxième phase avant d’examiner à nouveau l’état du système. La perte de connectivité est limitée en mettant les cartes de ligne hors ligne et en désactivant les interfaces en raison de l’échec des tentatives de récupération précédentes. Si le problème n’est pas résolu par le redémarrage des cartes de ligne ou si le problème se reproduit dans les 10 minutes suivant le redémarrage des cartes de ligne, cette phase est effectuée.

Les trois phases sont contrôlées par des minuteries. Au cours de ces phases, si un événement (par exemple, des cartes de ligne d’offlining/d’onlining ou des plans de fabric) expire, la phase ignore cet événement et passe à l’événement suivant. Le contrôle de la minuterie a une valeur de délai d’attente de 10 minutes. Si la première erreur de fabric se produit dans un système avec deux cartes de ligne ou plus, les plans de fabric sont redémarrés. Si une autre erreur de fabric se produit dans les 10 minutes qui suivent, les plans de fabric et les cartes de ligne sont redémarrés. Toutefois, si la deuxième erreur de fabric se produit en dehors du délai d’expiration de 10 minutes, la première phase est exécutée, soit le redémarrage des plans de fabric uniquement.

Dans les cas où tous les délais d’expiration de destination sont tracés sur une certaine carte de ligne, par exemple, une carte de ligne source ou une carte de ligne de destination, seule cette carte de ligne est mise hors ligne et en ligne. Les plans de structure ne sont pas mis hors ligne et en ligne. Si un autre défaut de fabric se produit dans un délai de 10 minutes, la carte de ligne est mise hors ligne.

Par défaut, le système limite les pertes de connectivité en détectant les structures fortement dégradées. Aucune interaction de l’utilisateur n’est nécessaire.

Cartes de ligne avec structure dégradée

Vous pouvez configurer le déplacement d’une carte de ligne avec une fabric dégradée vers l’état hors connexion. Sur un routeur MX10008, MX10004, MX2020, MX2010, MX960, MX480, MX304 ou MX240, vous pouvez configurer des erreurs de liaison ou des plans de structure défectueux. Cette configuration est particulièrement utile dans les scénarios de perte partielle de connectivité où la mise hors ligne de la carte de ligne entraîne un réacheminement plus rapide. Pour configurer cette option sur une fiche de ligne, utilisez l’instruction offline-on-fabric-bandwidth-reduction au niveau de la [edit chassis fpc slot-number] hiérarchie. Pour plus d’informations, reportez-vous à Gestion du plan de structure sur les routeurs MX304, Gestion du plan de structure sur les MX10K-LC9600 et SFB2 (numéro de modèle : JNP10008-SF2), Gestion du plan de structure sur les périphériques MX10004, Gestion du plan de structure sur les JNP10K-LC2101 et JNP10K-LC480, Gestion du plan de structure sur les périphériques MX10004 et MX10008 et Gestion du plan de structure sur la carte porteuse modulaire AS MLC.

Perte de connectivité vers une destination unique uniquement

Dans certains déploiements, une carte de ligne indique une perte totale de connectivité vers une seule destination, mais elle fonctionne correctement pour les autres destinations. Ces cas sont identifiés et la carte de ligne concernée est récupérée. Considérons un exemple de scénario dans lequel les plans actifs sont 0,1,2,3 et les plans de rechange sont 4,5,6,7 dans la connexion entre la carte de ligne 0 et la carte de ligne 1. Si la carte de ligne 0 présente des défaillances d’une seule liaison pour les plans 0 et 1 et si la carte de ligne 1 présente des défaillances d’une seule liaison pour les plans 2 et 3, une perte complète de connectivité se produit entre les deux cartes de ligne. Les cartes de ligne 0 et 1 subissent toutes deux un mode de récupération progressif et la cicatrisation du tissu a lieu.

Mode de redondance de la structure sur les cartes de contrôle actives

Vous pouvez configurer la carte de contrôle active pour qu’elle soit en mode redondance ou en mode d’augmentation de la bande passante de la fabric. Pour configurer le mode de redondance de la carte de contrôle active, utilisez l’instruction redundancy-mode redundant au niveau de la [edit chassis fabric] hiérarchie.

Détection et actions correctives des cartes de ligne sur les routeurs MX Series

Vous pouvez configurer le déplacement d’une carte de ligne vers l’état hors ligne sur un routeur MX Series (par exemple, MX10008, MX10004, MX2020, MX2010, MX2008, MX960, MX480 ou MX304, MX240, etc.). La configuration de cette fonctionnalité n’affecte pas le système. Vous pouvez configurer cette fonction sans redémarrer la carte de ligne ni redémarrer le système.

Les scénarios suivants peuvent se produire lorsque vous configurez la fonction pour désactiver les fiches de ligne :

  • Si une carte de ligne a été mise hors ligne en raison d’erreurs de fabric et que cette fonctionnalité de déplacement de la carte de ligne à l’état hors ligne est désactivée, la carte de ligne passe automatiquement à l’état en ligne.

  • Si une carte de ligne a été mise hors ligne en raison d’erreurs de fabric et que cette fonctionnalité de déplacement de la carte de ligne à l’état hors ligne est désactivée ou configurée pour une autre carte de ligne, la carte de ligne qui a été mise hors ligne passe automatiquement à l’état en ligne.

  • Toutes les cartes de ligne qui ont été mises hors ligne lorsque vous avez configuré ce paramètre sont réactivées lorsque vous validez une configuration sous le niveau hiérarchique [edit chassis] . De même, un redémarrage du démon de châssis ou l’opération GRES ( Graceful moteur de routage Switchover ) entraîne également le déplacement de la carte de ligne désactivée en raison d’une structure dégradée vers l’état en ligne.

Lorsqu’une carte de ligne fonctionne avec moins de plans de structure actifs que le nombre requis. Si une carte de ligne fonctionne avec moins de quatre plans, le trafic de la fabric fonctionne avec une bande passante réduite.

Les conditions suivantes peuvent entraîner une réduction de la bande passante d’exploitation dans la fabric :

  • Les cartes de contrôle de la fabric se déconnectent à la suite d’un arrêt de courant soudain et involontaire.

  • Une erreur de circuit intégré spécifique à l’application (ASIC), qui entraîne la mise hors ligne automatique d’un plan d’une carte de contrôle.

  • Mise manuelle du plan de structure ou de la carte de contrôle à l’état hors ligne.

  • Retrait de la carte de contrôle

  • Défaillance de l’auto-ping sur n’importe quel avion.

  • Échec de l’entraînement HSL2 pour l’avion actif.

  • Si un plan de fabric de rechange comporte des erreurs CRC et que ce plan de rechange est créé en ligne, la liaison avec l’erreur CRC est désactivée. Ce mécanisme peut provoquer une dégradation de la structure dans un sens et un routage nul dans l’autre sens.

  • En cas d’échec de l’auto-ping ou de l’entraînement HSL2, le plan de structure est désactivé pour une carte de ligne particulière et il est en ligne pour les autres cartes de ligne. Cette condition peut également entraîner une route nulle.

Si vous devez retirer la carte de contrôle ou déplacer un plan de structure à l’état hors ligne pendant une maintenance du système, vous devez activer la fonctionnalité pour transformer les cartes de ligne avec une bande passante dégradée à l’état hors ligne (à l’aide de l’instruction offline-on-fabric-bandwidth-reduction au niveau de la [edit chassis fpc slot-number] hiérarchie).

Les actions correctives suivantes sont effectuées lorsqu’une route nulle ou une bande passante d’exploitation réduite se produit dans la structure :

  • Qu’une carte de contrôle de rechange soit disponible ou non, l’état d’auto-ping de chaque carte de ligne est surveillé toutes les 5 secondes au niveau du moteur de routage. Le gestionnaire de structure détermine la présence de cartes de contrôle de rechange

  • La structure de commutation est hébergée sur les cartes de structure de commutation (SFB) des appareils MX10008, MX10004, MX2020, MX2010 et MX2000 :

    • Le routeur MX10008 dispose de huit emplacements pour les cartes de ligne pouvant prendre en charge un maximum de 768 ports Ethernet 100 Gigabit (4 x 100), 192 ports Ethernet 40 Gigabit, 192 ports Ethernet 100 Gigabit ou 192 ports Ethernet 400 Gigabit avec des emplacements de carte de ligne 0 à 7 qui combinent des interfaces moteur de transfert de paquets (PFE) et Ethernet enfermées dans un seul assemblage. MX10008 prend en charge six cartes de fabric de commutation (SFB) Il existe deux modèles de SFB : le JNP10008-SF et le JNP10008-SF2. Les SFB installés doivent être du même type de modèle dans un châssis en cours d’exécution.

      Pour plus d’informations, consultez Fabric-Plane-Management-on-MX10004 et MX10008-Devices

    • MX10004 dispose d’un châssis modulaire compact 7 U, d’emplacements pour cartes de ligne, de 0 à 3 cartes de ligne en silicium (débit de 2,4 Tbit/s, 480 Gbit/s et 9,6 Tbit/s) et d’une redondance matérielle complète. Les cartes de matrice de commutation (SFB) créent la structure de commutation du MX10004. Chaque SFB dispose d’un ensemble de connecteurs reliant les cartes de ligne et la carte de contrôle de routage (RCB) à la fabric de commutation. Trois SFB fournissent des fonctionnalités de commutation réduites à un routeur MX10004. Six SFB assurent un débit complet. Chaque MX10004 SFB dispose de quatre connecteurs. Chaque connecteur correspond à un emplacement pour carte de ligne, ce qui élimine le besoin d’un fond de panier.

      Pour plus d’informations sur la gestion du plan de structure, reportez-vous à la section Gestion du plan de structure sur les équipements MX10004.

    • Le routeur MX10003 contient des moteurs de routage modulaires et des PFE. Le PFE unique effectue à la fois le transfert des paquets entrants et sortants. Le routeur dispose de deux emplacements pour cartes de ligne dédiées. Le routeur prend en charge une carte de routage et de contrôle (RCB) principale et deux cartes de contrôle (RCB) redondantes.

    • Les appareils MX2020 et MX2010 prennent en charge 8 SFB. Le MX2020 dispose de 20 emplacements pour cartes de ligne dédiées. Le routeur MX2010 dispose de 10 emplacements pour cartes de ligne dédiées Le sous-système hôte se compose de deux cartes de contrôle avec moteurs de routage (CBRE) et de huit cartes de structure de commutation (SFB). Les paquets de données sont transférés entre les MPC sur le fond de panier via les ASIC de fabric des SFB.

      Les cartes de fabric de commutation (SFB) offrent une bande passante de fabric accrue par emplacement. Jusqu’à huit SFB, SFB2 ou

      Les SFB3 peuvent être installés dans un routeur MX2020 ou MX2010. Toutes les cartes de la fabric de commutation du châssis doivent être du même type. Le mode mixte n’est pas pris en charge.

    • Routeurs MX960 avec cartes de ligne à puce I ou à puce I et à puce Trio contenant trois cartes de contrôle.

    • Routeurs MX240 ou MX480 avec cartes de ligne à puce I ou I, et puce Trio, contenant deux cartes de contrôle.

    • Les routeurs MX960, MX480 ou MX240 qui contiennent uniquement des cartes de ligne basées sur Trio ne sont pas considérés comme contenant une carte de contrôle de rechange.

    Si, au cours d’un tel intervalle de 5 secondes, deux cartes de ligne indiquent une défaillance pour le même plan, un basculement vers la carte de commande de rechange. Dans ce cas, la carte de contrôle qui a signalé des erreurs est mise hors ligne et la carte de commande de rechange est mise en ligne.

  • Si une carte de contrôle de rechange est disponible et si vous configurez la fonctionnalité de désactivation des cartes de ligne, l’état d’auto-ping de chaque carte de ligne est surveillé à des intervalles de 5 secondes au niveau du moteur de routage. Les conditions suivantes peuvent se produire :

    • Au cours d’un intervalle de 5 secondes, si une seule carte de ligne indique une défaillance pour un avion, le gestionnaire de structure attend l’intervalle suivant. Au cours de l’intervalle suivant, si aucune autre carte de ligne n’indique une défaillance pour le même plan, le basculement de la carte de commande est effectué.

    • Au cours d’un intervalle de 5 secondes, si plusieurs cartes de ligne affichent des défaillances pour plusieurs cartes de contrôle, le gestionnaire de structure attend l’intervalle suivant. Au cours de l’intervalle suivant, si la même condition demeure, toutes les cartes de ligne défaillantes sont mises hors ligne, même si la carte de contrôle de rechange est présente.

    • Au cours d’un intervalle de 5 secondes, si une carte de ligne indique une défaillance pour plusieurs plans sur plusieurs cartes de contrôle, le gestionnaire de structure attend l’intervalle suivant. Au cours de l’intervalle suivant, si la même condition persiste, la carte de ligne est mise hors ligne même si la carte de contrôle de rechange est présente.

  • Si des plans de rechange ne sont pas disponibles, la carte de ligne est mise hors ligne lorsqu’elle affiche une défaillance pour un ou plusieurs plans. La carte de ligne n’est mise hors ligne que si vous avez préalablement configuré l’instruction offline-on-fabric-bandwidth-reduction au niveau de la [edit chassis fpc slot-number] hiérarchie.

Comprendre la gestion des défaillances de fabric sur les routeurs T4000

Le routeur T4000 se compose d’une carte d’interface de commutation (SIB) avec une bande passante de fabric deux fois supérieure à la capacité du routeur T1600. La fonctionnalité de gestion des défaillances de fabric est similaire à celle des routeurs T1600. Cette rubrique décrit la fonctionnalité de gestion des pannes de fabric sur les routeurs T4000.

La fonctionnalité de gestion des défaillances de fabric implique la surveillance de toutes les liaisons haut débit connectées à la fabric et de celles qui se trouvent au cœur de la fabric pour détecter les défaillances et les erreurs de liaison.

Des mesures sont prises en fonction de la panne et de sa localisation. Parmi ces actions, on peut citer :

  • Signalement des erreurs de lien dans les fichiers journaux système et envoi de ces informations au moteur de routage.

  • Signalez les échecs de liaison au niveau du concentrateur de ports flexibles (FPC) ou du SIB et envoyez ces informations au moteur de routage.

  • Marquage d’un SIB dans l’état Check .

  • Mise en état Fault d’un SIB.

Dans les routeurs T4000, le SIB constitue le cœur de la fabric avec une redondance 4:1 : le SIB redondant devient actif lorsque le SIB actif ne fonctionne plus, est désactivé ou supprimé. Voici les indications de haut niveau des défaillances de fabric surveillées par Junos OS :

  • Une interruption SNMP est générée chaque fois qu’un SIB est signalé comme Check ou Fault.

  • show chassis alarms: indique qu’un SIB est dans Check ou Fault state.

  • show chassis sibs: indique qu’un SIB est dans Check un état ou Fault qu’un SIB est en Offline état lorsque le SIB s’initialise (cela se produit lorsque le SIB ne s’allume pas complètement).

  • show chassis fabric fpcs: indique si des liaisons de structure sont erronées du côté des FPC.

  • show chassis fabric sibs: indique si des liaisons de structure sont erronées du côté des SIB.

  • Le /var/log/messages fichier de messages du journal système du moteur de routage contient des messages d’erreur avec le préfixe CHASSISD_FM_ERROR.

  • Les SIB affichent la FAIL LED.

Note:

Les plans de structure du châssis déterminent s’il s’agit d’un routeur T640, d’un routeur T1600 ou d’un routeur T4000. Les modules d’entrée d’alimentation (PEM), les FPC ou les plateaux de ventilation ne déterminent pas la personnalité du châssis. Des alarmes sont déclenchées si les anciens PEM ou plateaux de ventilation sont présents dans un châssis T4000. Vous pouvez identifier un routeur en fonction de ses plans de structure :

  • Si tous les avions présents sont des SIB basés sur F16, le châssis est un châssis T640.

  • Si tous les plans présents sont des SIB SF, le châssis est un châssis T1600.

  • Si tous les plans présents sont des SIB basés sur XF, le châssis est un châssis T4000.

Notez que la combinaison de plans de structure n’est pas une configuration prise en charge, sauf lors de la mise à niveau. Vous pouvez modifier la personnalité d’un châssis sans redémarrage en modifiant tous les plans de la structure et en exécutant la set chassis fabric upgrade-mode commande CLI pour vérifier la personnalité. Si vous n’exécutez pas la set chassis fabric upgrade-mode commande CLI, la personnalité ne change pas jusqu’au prochain démarrage.

Sur les routeurs T4000, vous rencontrez les défauts suivants :

  • Défauts au niveau de la carte : ces défauts se produisent lors de l’initialisation ou pendant l’exécution. Une panne de courant lors de l’initialisation de la carte, une erreur de transmission des liaisons haut débit et une erreur d’E/S interrogée pendant l’exécution sont quelques exemples de défaillances au niveau de la carte.

  • Faults (Défauts au niveau de la liaison) : ces défauts se produisent lors de l’initialisation ou pendant l’exécution. L’échec de l’entraînement de la liaison au moment de l’initialisation (échec des liaisons de plan de données entre un FPC et un SIB à entraîner lorsque le FPC ou le SIB est initialisé), une erreur détectée sur le canal entre le SIB et un moteur de transfert de paquets, les erreurs CRC (Cyclic Redundancy Check) détectées au moment de l’exécution et les erreurs de destination du moteur de transfert de paquets sont des types d’erreurs au niveau de la liaison.

  • Défaillances basées sur les conditions environnementales : ces défaillances se produisent pendant l’exécution. Le retrait soudain d’un FPC ou d’un SIB peut entraîner une erreur de l’opérateur. Lorsqu’un SIB devient trop chaud ou lorsque les tensions SIB sont au-delà des seuils, les erreurs générées sont classées en erreurs environnementales.

Vous pouvez implémenter l’une des options suivantes pour gérer les pannes :

  • Enregistrez l’erreur et déclenchez une alarme.

  • Passez à l’avion de rechange, si disponible.

  • Continuez avec un nombre réduit de pièces d’un plan.

  • Continuez avec un nombre réduit d’avions utilisables.

  • Utilisez la gestion des pannes basée sur les sondages.

  • Surveillez les erreurs sur les liaisons haut débit et ramenez manuellement la liaison à un seuil approprié.

Les erreurs d’E/S et les erreurs de liaison interrogées sont surveillées toutes les 500 millisecondes, tandis que la température d’échappement et les tensions de la carte sont surveillées toutes les 10 secondes.

Comprendre la gestion des pannes de fabric sur PTX5000 Routeur de transport de paquets

À partir de Junos OS version 14.1, le Routeur de transport de paquets PTX5000 prend en charge neuf cartes d’interface de commutation (SIB). Chaque FPC FPC2-PTX-P1A prend en charge une capacité de 1 Tbit/s par emplacement, ce qui se traduit par une bande passante de fabric de 16 térabits par seconde (Tbit/s), en duplex intégral (8 Tbit/s de commutation any-to-any, non bloquante, semi-duplex).

La fonctionnalité de gestion des défaillances de fabric implique la surveillance de toutes les liaisons haut débit connectées à la fabric et de celles qui se trouvent au cœur de la fabric pour détecter les défaillances et les erreurs de liaison.

Les défauts qui se produisent dans un PTX5000 peuvent être classés en deux grandes catégories :

  • Défaillances de la carte : défaillances survenant dans un SIB ou dans un concentrateur de port flexible (FPC) lors de l’initialisation ou pendant l’exécution, y compris les problèmes survenant lorsqu’un composant de routeur accède au SIB ou au FPC ou les problèmes résultant de défaillances du fond de panier central.

  • Défauts de lien : défauts qui se produisent sur les liens de haut niveau d’un routeur lors de l’initialisation ou pendant l’exécution.

  • Défauts dus aux conditions environnementales : défauts qui se produisent en raison d’une surtension ou d’une surchauffe ; les défaillances qui se produisent en raison d’une mauvaise manipulation d’un SIB ou d’un FPC par un opérateur, etc.

Le routeur prend des mesures en fonction de la catégorie de défaut et de l’emplacement du défaut. Parmi ces actions, on peut citer :

  • Signalement des erreurs de lien dans les fichiers journaux système et envoi de ces informations au moteur de routage.

  • Affichage des erreurs de liaison lors de l’exécution de l’une des commandes opérationnelles répertoriées dans le Tableau 1 :

    Tableau 1 : liste des commandes du mode opérationnel

    Commande en mode opérationnel

    Description

    show chassis sibs

    Affiche les informations d’état des cartes d’interface de commutation (SIB).

    show chassis fabric fpcs <slot number>

    Affiche l’état de la fabric de l’emplacement FPC spécifié. Si aucun numéro d’emplacement n’est fourni, il affiche l’état de tous les FPC.

    show chassis fabric sibs <slot number>

    Affiche l’état de la liaison de la fabric de commutation électrique entre les SIB et les FPC.

    show chassis fabric reachability <detail>

    Affiche l’état actuel de l’accessibilité de la destination de la structure.

    show chassis fabric unreachable-destinations

    Affiche la liste des destinations qui sont passées de l’état accessible à l’état inaccessible.

    show pfe statistics error

    Affiche les statistiques d’erreur du moteur de transfert de paquets.

    show chassis fabric topology <sib_slot>

    Affiche la topologie de la liaison d’entrée-sortie.

    show chassis fabric summary

    Affiche l’état de tous les plans de structure et le temps de disponibilité écoulé.

  • Signalement des défaillances de liaison au niveau FPC ou SIB et envoi de ces informations au moteur de routage.

  • Informations d’erreur de lien de rapport dans la show chassis alarms commande opérationnelle.

  • Déplacement d’un SIB vers l’état de défaut .

Les sections suivantes expliquent la fonctionnalité de gestion des défaillances de fabric sur le PTX5000 :

Défaillances de niveau SIB

Les sections suivantes donnent un bref aperçu des types de défaillances qui se produisent sur un SIB et de la manière de les traiter :

Types de défaillances qui se produisent sur un SIB

Des défaillances de carte et de liaison se produisent sur un SIB lors de l’initialisation et pendant l’exécution. Certains défauts se produisent en raison de conditions environnementales telles qu’une surtension ou une surchauffe, ou lorsqu’un opérateur manipule mal le SIB.

Note:

Exécutez les commandes du mode opérationnel répertoriées dans le Tableau 1 pour détecter les défauts.

Lors de l’initialisation et de l’exécution du SIB, les erreurs suivantes peuvent se produire :

  • Défaillances de la carte, telles que l’échec de la mise sous tension des SIB, la réinitialisation des ASIC, l’interrogation de la carte mezzanine du processeur de commutation (SPMB), l’échec de l’accès aux E/S aux ASIC, la défaillance des composants de la carte telle que la défaillance du PIC ou la défaillance de l’accès aux composants du routeur.

  • Les défaillances de liaison, telles que les erreurs de liaison de haut niveau qui se produisent pendant l’entraînement de la liaison.

  • Les défauts qui se produisent en raison des conditions environnementales ou en raison d’une mauvaise manipulation du SIB par l’opérateur.

Gestion des défaillances de niveau SIB

La liste suivante illustre la façon dont le routeur gère un défaut qui se produit sur un SIB lors de l’initialisation, pendant l’exécution, en raison de conditions environnementales et en raison d’une mauvaise manipulation du SIB par l’opérateur :

  • Pour gérer une défaillance de carte sur un SIB lors de l’initialisation, le démon du châssis (chassisd) marque le SIB comme étant en état de défaut . Une fois que le SIB est marqué comme défectueux, aucune opération n’a lieu sur ce SIB.

  • Pour gérer une défaillance de carte sur un SIB pendant l’exécution, chassisd consigne une erreur dans le fichier journal du système, déclenche un type d’erreur d’indication d’alarme et marque le SIB comme défectueux. Une fois que le SIB est marqué comme défectueux, aucune opération n’a lieu sur ce SIB.

  • Pour gérer une erreur de liaison sur un SIB pendant l’exécution, lorsqu’une erreur de liaison survient pendant l’entraînement de la liaison, chassisd informe le FPC correspondant à la liaison sur laquelle l’erreur s’est produite de désactiver les liens vers la SIB concernée. Le châssis envoie alors un message d’erreur à tous les autres FPC du routeur pour qu’ils cessent d’utiliser la liaison SIB défaillante et une alarme d’erreur de liaison est générée. Notez que lorsque plusieurs FPC signalent des erreurs pour un SIB donné, le SIB est désactivé pour tous les FPC et aucun trafic n’est envoyé par le moteur de transfert de paquets via le SIB concerné.

  • Pour gérer une erreur de liaison sur un SIB pendant l’exécution, chassisd marque le SIB comme défectueux et spécifie la raison de l’erreur, puis le SIB est désactivé.

  • En cas de défaillance environnementale (surtension ou surchauffe), le SIB est immédiatement mis hors ligne. Notez qu’une erreur est consignée périodiquement lorsque la température ou la tension augmente, et que le SIB est mis hors ligne lorsqu’il franchit une certaine tension ou température de seuil.

  • Lorsqu’un SIB est brusquement retiré ou délogé, tous les moteurs de transfert de paquets concernés cessent d’utiliser ce plan pour atteindre d’autres moteurs de transfert de paquets dans le routeur.

Défauts de niveau FPC

Les sections suivantes donnent un bref aperçu des types de défaillances qui se produisent sur un FPC et de la façon de les gérer :

Types de défaillances qui se produisent sur un FPC

Des défaillances de carte et de liaison se produisent sur un FPC lors de l’initialisation et pendant l’exécution. Certains défauts se produisent également en raison de conditions environnementales telles que une surtension, une surchauffe ou lorsque l’opérateur manipule mal le FPC.

Note:

Exécutez les commandes opérationnelles répertoriées dans le Tableau 1 pour détecter les défauts.

Lors de l’initialisation et de l’exécution du protocole FPC, les erreurs suivantes peuvent se produire :

  • Défaillances de la carte, telles que la mise sous tension des FPC, la sortie de la phase de réinitialisation des ASIC, l’échec de l’accès aux E/S aux ASIC interrogés par PMB, la défaillance des composants de la carte telle que la défaillance du PIC ou la défaillance de l’accès aux composants du routeur.

  • Les défaillances de liaison, telles que les erreurs de liaison de haut niveau qui se produisent pendant l’entraînement de la liaison.

  • Les défauts qui se produisent en raison des conditions environnementales ou en raison d’une mauvaise manipulation d’un FPC par l’opérateur.

Gestion des défaillances de niveau FPC

La liste suivante illustre la façon dont le routeur gère un défaut qui se produit sur un FPC lors de l’initialisation, pendant l’exécution, en raison de conditions environnementales et en raison d’une mauvaise manipulation du FPC par l’opérateur :

  • Pour gérer une défaillance de carte sur un FPC lors de l’initialisation, chassisd marque le FPC comme étant en état de défaut . Une fois que le SIB est marqué comme défectueux, aucune opération ne se produit sur ce FPC.

  • Pour gérer une défaillance de la carte sur un FPC pendant l’exécution, chassisd consigne une erreur dans le fichier journal du système, déclenche un type d’erreur d’indication d’alarme et marque le FPC comme défectueux. Une fois que le FPC est marqué comme défectueux, aucune opération ne se produit sur ce FPC.

  • Pour gérer les erreurs de liaison embarquée sur un FPC lors de l’initialisation ou pendant l’exécution, le FPC est désactivé et tous les moteurs de transfert de paquets concernés cessent d’utiliser ce plan pour atteindre d’autres moteurs de transfert de paquets dans le routeur.

    Note:

    Aucun plan n’est mis hors service lors de l’initialisation, car le processus d’entraînement des liens pour la fabric n’est pas encore terminé.

    Les erreurs de liaison embarquées pendant l’exécution sont résolues sur la base de la configuration actuelle ; soit le FPC est redémarré, soit l’erreur est consignée et l’initialisation du FPC se poursuit.

  • En cas de défaillance environnementale (surtension ou surchauffe), le FPC est immédiatement mis hors ligne. Notez qu’une erreur est consignée périodiquement lorsque la température ou la tension augmente, et que le FPC est mis hors ligne lorsqu’il franchit une certaine tension ou température de seuil.

  • Lorsqu’un FPC est brusquement retiré ou délogé, tous les autres moteurs de transfert de paquets cessent d’envoyer du trafic aux moteurs de transfert de paquets de ce FPC.

Comprendre la gestion des pannes de fabric sur la carte SFB2 (Enhanced Switch Fabric Board)

La gamme MX2000 de routeurs prend en charge les cartes de matrice de commutation (SFB) et les SFB améliorées (SFB2), mais pas les deux en même temps. Le SFB et le SFB2 hébergent chacun trois plans de structure. Ainsi, le châssis prend en charge un total de 24 avions. Junos OS versions 15.1F6 et 16.1R1 prend en charge la gestion des pannes de fabric pour chaque plan dans SFB et SFB2. Dans les versions antérieures, la gestion des pannes de fabric était prise en charge pour chaque SFB, et non pour chaque plan.

Le Tableau 2 répertorie les différences entre la gestion des défaillances de fabric par plan et par SFB.

Tableau 2 : gestion des défaillances de fabric SFB et SFB2

Niveau SFB (SFB)

Niveau plan (SFB et SFB2)

Les erreurs de contrôle de redondance cyclique (CRC) sur n’importe quelle liaison du SFB sont indiquées sur le SFB.

Les erreurs CRC sur n’importe quelle liaison sur le SFB ou le SFB2 sont indiquées sur le plan.

En cas d’erreur de destination, la carte de ligne isole le SFB (les 3 plans).

En cas d’erreur de destination, la carte de ligne isole le plan correspondant. D’autres avions continuent de circuler.

La gestion des défaillances de fabric par plan offre les avantages suivants :

  • Granularité accrue, ce qui permet d’identifier, d’isoler et de réparer les défauts.

  • Les alarmes et les messages de journal fournissent des informations sur les défaillances par plan et non par SFB, ce qui facilite le débogage.

  • Si un SFB a un seul plan défectueux, les deux autres plans peuvent continuer à fonctionner. Il n’est pas nécessaire de mettre l’ensemble du SFB hors ligne.

  • En cas d’erreurs transitoires, lors de la réparation, vous pouvez isoler un seul plan au lieu d’isoler le SFB rebondissant.

Pour afficher les informations de gestion des pannes de fabric pour les 24 plans, utilisez l’option extended avec les commandes fabric existantes.

Gestion de la dégradation de la bande passante

Certaines erreurs entraînent l’abandon de paquets par un système sans notification. Les autres systèmes connectés continuent de transférer le trafic vers le système affecté, ce qui a un impact sur les performances du réseau. Un plan de structure fortement dégradé peut en être l’une des raisons.

Par défaut, les routeurs Juniper Networks tentent de commencer à corriger ces situations lorsque le système détecte des problèmes avec les moteurs de transfert de paquets. Si la réparation échoue, le système désactive les interfaces, empêchant ainsi d’autres escalades.

Sous Junos OS, vous pouvez utiliser l’instruction bandwidth-degradation de configuration au niveau de la [edit chassis fpc slot-numberfabric] hiérarchie pour détecter et réagir à la dégradation du plan de structure de la manière que vous jugez appropriée. Vous pouvez configurer le routeur pour qu’il spécifie les actions de réparation qu’il doit effectuer une fois qu’une telle condition est détectée. Vous pouvez également utiliser l’instruction blackhole-action facultative pour déterminer comment la carte de ligne réagit à un scénario de dégradation de 100 % de la fabric. Cette commande est facultative et remplace les procédures de renforcement de fabric par défaut.

Note:

La bandwidth-degradation commande et les instructions s’excluent offline-on-fabric-bandwidth-reduction mutuellement. Si les deux commandes sont configurées, une erreur est émise lors de la vérification de validation.

L’instruction bandwidth-degradation est configurée avec un pourcentage et une action. La percent-age valeur peut être comprise entre 1 et 99 et représente le pourcentage de dégradation de la fabric nécessaire pour déclencher une réponse de la carte de ligne. L’attribut action détermine le type de réponse que la carte de ligne effectue une fois que la dégradation de la structure atteint le pourcentage configuré.

L’instruction est uniquement configurée avec un action attribut, qui se déclenche lorsque le pourcentage de dégradation de la structure atteint 100 %.

Les actions suivantes peuvent être appliquées à l’une ou l’autre des instructions de configuration :

  • log-only: un message est consigné dans le châssis et les fichiers de messages lorsque le seuil de dégradation de la fabric est atteint. Aucune autre mesure n’est prise.

  • restart: La carte de ligne dont le plan de structure est dégradé est redémarrée une fois le seuil atteint.

  • offline: La carte de ligne avec un plan de structure dégradé est mise hors ligne une fois le seuil atteint. La carte de ligne nécessite une intervention manuelle pour être remise en ligne. Il s’agit de l’action par défaut si aucun attribut d’action n’est configuré.

  • restart-then-offline: la carte de ligne dont le plan de structure est dégradé est redémarrée une fois le seuil atteint, et si une nouvelle dégradation du plan de structure est détectée dans les 10 minutes, la carte de ligne est mise hors ligne. La carte de ligne nécessite une intervention manuelle pour être remise en ligne.

Note:

Cette fonctionnalité est disponible dans Junos OS version 15.1R1.

Renforcement et récupération des structures sur les appareils PTX10K

Note: Les fonctionnalités de renforcement et de récupération de la structure sont prises en charge sur les appareils suivants :

  • Routeurs PTX10001-36MR, PTX10004, PTX10008 et PTX100016 avec carte de ligne PTX10K-LC1202-36MR

  • Routeur PTX10008 avec carte de ligne PTX10K-LC1301-36DD

Le renforcement de la structure est une fonctionnalité de résilience qui permet de détecter le blackholing de la structure et de tenter un processus de récupération automatique pour restaurer les moteurs de transfert de paquets à partir de l’état de trou noir.

Nous avons activé le renforcement de la structure par défaut. Lorsque le système détecte une destination inaccessible du moteur de transfert de paquets, cette fonctionnalité tente de restaurer automatiquement la connectivité de la fabric.

En cas d’échec de la restauration, le système désactive les interfaces pour limiter le blackholing et déclencher une alarme pour indiquer les destinations inaccessibles du moteur de transfert de paquets. Toutefois, au lieu de désactiver les interfaces, l’utilisateur peut configurer le moteur de transfert de paquets hors ligne à l’aide d’une set chassis fabric event reachability-fault actions recovery-failure pfe-offline instruction au niveau de la [set chassis fabric event] hiérarchie.

Les destinations du moteur de transfert de paquets peuvent devenir inaccessibles pour les raisons suivantes :

  • Auto-blackhole complet : une perte totale de connectivité se produit sur tous les plans de la structure.

  • Deux moteurs de transfert de paquets peuvent atteindre la fabric, mais pas l’un l’autre.

Vous pouvez configurer un routeur pour qu’il déclenche la récupération de la fabric lorsqu’il détecte une dégradation de la bande passante de la fabric à l’aide d’une degraded instruction au niveau de la [edit chassis fabric event reachability-fault] hiérarchie. L’instruction degradation est configurée avec une valeur de pourcentage qui peut être comprise entre 1 et 99. La valeur en pourcentage représente le seuil d’erreur de dégradation de la bande passante de la fabric et le routeur démarre la récupération une fois le seuil atteint.

Lorsque le seuil d’erreur dégradé est configuré, le routeur peut également tenter de récupérer la fabric pour les raisons suivantes :

  • Autodégradation de l’état de la structure dans une destination du moteur de transfert de paquets.

  • Dégradation par les pairs : état dégradé de la structure entre deux moteurs de transfert de paquets.

Le processus de récupération de fabric implique une ou plusieurs des phases suivantes :

  • Phase de redémarrage des SIB : si les destinations du moteur de transfert de paquets sur plusieurs cartes de ligne présentent des défaillances de connectivité de fabric sur les plans, le routeur tente de résoudre le problème en redémarrant les SIB. Si plusieurs SIB nécessitent un redémarrage, le routeur redémarre les SIB une par une.

  • Phase de redémarrage du FPC : le routeur tente une récupération automatique en redémarrant les FPC dans les scénarios suivants :

    • Toutes les destinations du moteur de transfert de paquets ayant des conditions de blackhole complètes ou partielles se trouvent dans un seul FPC.

    • Si des destinations du moteur de transfert de paquets avec des conditions de trou noir complet ou partiel se produisent sur différents FPC, mais qu’aucun des moteurs de transfert de paquets ne partage le même plan de défaillance.

    • La tentative de redémarrage de la phase SIB n’a pas permis de récupérer les moteurs de transfert de paquets.

    Vous pouvez désactiver le redémarrage des FPC pour limiter les actions de récupération à partir d’un état de fabric dégradé. Pour désactiver le redémarrage des FPC, utilisez l’instruction set chassis fabric event reachability-fault actions fpc-restart-disable au niveau de la [set chassis fabric event] hiérarchie.

  • Phase hors ligne du moteur de transfert de paquets : en raison de l’échec des tentatives précédentes de phases de récupération ou de la désactivation de l’action de récupération dans la configuration, le routeur désactive les interfaces pour limiter le blackholing par défaut. Toutefois, au lieu de désactiver les interfaces, l’utilisateur peut configurer le moteur de transfert de paquets hors ligne à l’aide d’une set chassis fabric event reachability-fault actions recovery-failure pfe-offline instruction au niveau de la [set chassis fabric event] hiérarchie.

Si le routeur ne dispose que de moteurs de transfert de paquets avec un trou noir ou une dégradation de l’homologue, il tente la récupération via la réparation automatique des liaisons en redémarrant les liaisons de structure sur les plans.

Avantages

  • Tente le processus de récupération automatique pour récupérer les moteurs de transfert de paquets des conditions de fabric dégradées afin de minimiser les pertes de trafic.

  • Déclenchez des alarmes qui fournissent des informations d’erreur pour indiquer les destinations inaccessibles du moteur de transfert de paquets, si la récupération échoue.

Désactivation du redémarrage de la carte de ligne pour limiter les actions de récupération à partir de conditions de fabric dégradées

Vous pouvez désactiver les redémarrages de la carte de ligne pour limiter les actions de récupération à partir d’un état de fabric dégradé. Sur les routeurs T640 et T1600, seul le plan de structure est redémarré. Sur les routeurs PTX Series, seules les cartes d’interface de commutation (SIB) sont redémarrées. Pour désactiver le redémarrage des cartes de ligne, utilisez l’instruction au action-fpc-restart-disable niveau de la [edit chassis fabric degraded] hiérarchie :

Chaque fois qu’un redémarrage de carte de ligne est désactivé, une alarme est déclenchée lorsqu’il y a des destinations inaccessibles présentes dans le routeur et vous devez redémarrer les cartes de ligne manuellement.

Pour vous assurer que les plans de structure (routeurs T640 et T1600) ou les SIB (routeurs PTX Series) et les cartes de ligne sont redémarrés pendant le processus de récupération, ne configurez pas l’instruction action-fpc-restart-disable au niveau de la [edit chassis fabric degraded] hiérarchie.

Désactivation d’un FPC avec une bande passante de fabric dégradée

Vous pouvez mettre hors ligne un FPC avec une bande passante de fabric dégradée pour éviter de provoquer une route nulle dans le châssis pendant une période prolongée. Pour configurer l’option permettant de désactiver un FPC avec une bande passante dégradée, utilisez l’instruction au niveau de offline-on-fabric-bandwidth-reduction la [edit chassis fpc slot-number] hiérarchie :

Le gestionnaire de structure vérifie périodiquement le nombre de plans actifs actuels. Si le nombre de plans actifs est inférieur au nombre requis de plans actifs pour un routeur particulier, le système attend 10 secondes avant d’entreprendre des actions correctives. Si la condition de bande passante réduite persiste pour un FPC et si cette fonction a été configurée pour le FPC, le système met le FPC hors ligne.

Gestion des erreurs par OAM de fabric

L’OAM (Operation, Administration, Maintenance) de la fabric permet de détecter les défaillances dans les chemins d’accès à la fabric. L’OAM de fabric valide la connectivité de la fabric avant d’envoyer le trafic sur un plan de fabric chaque fois qu’un nouveau chemin de fabric est créé pour un PFE. Si une défaillance est détectée, le logiciel signale la défaillance et évite d’utiliser ce plan de structure pour ce PFE. Cette fonctionnalité fonctionne en envoyant un trafic OAM auto-destiné à très faible nombre de paquets par seconde (PPS) sur chacun des plans de structure disponibles et en détectant toute perte de trafic aux points de terminaison (vérification auto-ping de la structure).

Note:
  • Dans Junos OS Evolved version 20.4R1, la fonctionnalité OAM de fabric est activée par défaut. Vous pouvez désactiver la fonctionnalité à l’aide de la commande set chassis fabric oam detection-disableCLI .
  • Dans les versions 20.4R2 et 21.1R1 de Junos OS Evolved, la fonctionnalité OAM de fabric est désactivée par défaut.
  • Dans Junos OS Evolved version 22.1R1, la fonctionnalité OAM de la structure d’exécution est activée par défaut. Vous pouvez désactiver la fonctionnalité à l’aide de la commande edit chassis fabric oam runtime-disableCLI . La fonctionnalité OAM de la structure d’exécution est prise en charge sur les routeurs PTX10004, PTX10008 et PTX10016.

Les vérifications OAM de la structure sont effectuées au démarrage. Les chemins ayant échoué sont désactivés. Le système n’effectue aucune action de récupération. Toutefois, vous pouvez essayer de récupérer les plans de structure concernés en redémarrant les SIB. Les étapes de récupération dépendent de la nature de la défaillance.

Un plan de structure représente un chemin bidirectionnel indépendant entre un PFE et un ASIC de structure. Runtime Fabric OAM vérifie régulièrement la connectivité de la fabric et permet de détecter et de signaler les défaillances dans les plans de fabric pendant l’exécution du système. L’OAM de la structure d’exécution détecte l’accessibilité de chaque PFE dans la structure.

Lorsque les mêmes plans de structure tombent en panne sur un ou plusieurs FPC, redémarrez le SIB contenant les plans défaillants à l’aide des commandes suivantes :

user@host> request chassis sib slot slot-number offline

user@host> request chassis sib slot slot-number online

Lorsque des plans de structure aléatoires tombent en panne sur plusieurs FPC, l’erreur ne peut pas être isolée à un FPC ou un SIB spécifique. Toutefois, vous pouvez essayer de récupérer les plans en redémarrant les SIB qui contiennent les plans affectés de manière séquentielle.

Pour chaque erreur détectée par la fonctionnalité OAM de la structure, un syslog est généré. Voici un exemple :

Le message syslog suivant indique qu’une erreur liée à l’OAM de la structure a été effacée.

Vous pouvez également utiliser les commandes show system errors active detail CLI et show system alarms afficher les erreurs liées à l’OAM de la structure.

La sortie suivante indique les détails de la défaillance d’un seul plan de structure (sur le moteur de transfert de paquets 0) et de la défaillance de tous les plans de structure (sur le moteur de transfert de paquets 1).

Vous pouvez utiliser la commande show chassis fabric fpcs CLI pour afficher l’état d’auto-ping OAM de la structure de chaque plan de structure.

La show chassis fabric fpcs commande affiche la sortie suivante lorsque la fonctionnalité OAM de la structure est désactivée :

Documentation connexe

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’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libérer
Description
14.2R6
À partir de la version 14.2R6 de Junos OS, si un SIB est hors ligne en raison de conditions extrêmes telles qu’une haute tension ou une température élevée, le routeur ne redémarre pas le plan de structure de ce SIB dans le cadre du processus de récupération.
14.2R6
À partir de la version 14.2R6 de Junos OS, vous pouvez mieux gérer la dégradation de la structure dans les systèmes à châssis unique en incorporant les mécanismes d’auto-pingage de la structure et de dynamique du moteur de transfert de paquets.
14.1
À partir de Junos OS version 14.1, le Routeur de transport de paquets PTX5000 prend en charge neuf cartes d’interface de commutation (SIB).
13.3
À partir de la version 13.3 de Junos OS, vous pouvez utiliser les routeurs PTX Series pour configurer les niveaux d’erreur liés au moteur de transfert de paquets (PFE) et les actions à effectuer lorsqu’un seuil spécifié est atteint.