Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Interfaces de structure de cluster de châssis

Les équipements SRX Series d’un cluster de châssis utilisent l’interface de structure (fab) pour synchroniser les sessions et transférer le trafic entre les deux châssis. La liaison de structure est une connexion physique entre deux interfaces Ethernet sur le même réseau LOCAL. Les deux interfaces doivent avoir le même type de support. Pour plus d’informations, consultez les rubriques suivantes :

Comprendre les interfaces de structure de cluster de châssis

La structure est une connexion physique entre deux nœuds d’un cluster et se forme en connectant une paire d’interfaces Ethernet de l’arrière vers l’arrière (une de chaque nœud).

Contrairement à la liaison de contrôle, dont les interfaces sont déterminées par le système, vous spécifiez les interfaces physiques à utiliser pour la liaison de données de structure dans la configuration.

La structure est la liaison de données entre les nœuds et est utilisée pour transférer le trafic entre le châssis. Le trafic arrivant sur un nœud devant être traité sur l’autre est transféré sur la liaison de données de la structure. De même, le trafic traité sur un nœud devant sortir via une interface de l’autre nœud est transféré sur la structure.

La liaison de données est appelée interface de structure. Il est utilisé par les moteurs de transfert de paquets du cluster pour transmettre le trafic de transit et synchroniser l'état d'exécution dynamique du logiciel du plan de données. La structure fournit la synchronisation des objets d’état de session créés par des opérations telles que l’authentification, la traduction des adresses réseau (NAT), les passerelles de couche applicative (ALG) et les sessions de sécurité IP (IPsec).

Lorsque le système crée l’interface de structure, le logiciel lui attribue une adresse IP dérivée en interne à utiliser pour la transmission de paquets.

ATTENTION:

Une fois les interfaces de structure configurées sur un cluster de châssis, le retrait de la configuration de structure sur chaque nœud entraînera le déplacement du nœud secondaire RG0 (Redondance Group 0) à un état désactivé. (La réinitialisation de la configuration par défaut définie en usine d’un équipement supprime la configuration de la structure et fait passer le nœud secondaire RG0 à un état désactivé.) Une fois la configuration de la structure validée, ne réinitialisez pas la configuration par défaut définie en usine sur l’un des deux équipements.

Types d’interface de structure pris en charge pour les équipements SRX Series (SRX300 Series, SRX550M, SRX1500, SRX4100/SRX4200, SRX4600 et SRX5000 Series)

Pour les clusters de châssis SRX Series, la liaison de structure peut être n’importe quelle paire d’interfaces Ethernet couvrant le cluster; la liaison de structure peut être n’importe quelle paire d’interfaces Gigabit Ethernet. Exemples:

  • Pour les équipements SRX300, SRX320, SRX340, SRX550M et SRX345, la liaison de structure peut être n’importe quelle paire d’interfaces Gigabit Ethernet. Pour les équipements SRX380, la liaison de structure peut être n’importe quelle paire d’interfaces Gigabit Ethernet ou n’importe quelle paire d’interfaces 10 Gigabit Ethernet.

  • Pour les clusters de châssis SRX Series composés d’équipements SRX550M, les interfaces SFP sur les mini-PIC ne peuvent pas être utilisées comme liaison de structure.

  • Pour le SRX1500, la liaison de structure peut être n’importe quelle paire d’interfaces Ethernet couvrant le cluster ; la liaison de structure peut être n’importe quelle paire d’interface Gigabit Ethernet ou n’importe quelle paire d’interfaces 10 Gigabit Ethernet.

  • Les types d’interface de structure pris en charge pour les équipements SRX4100 et SRX4200 sont des emplacements 10 Gigabit Ethernet (xe) (10 Gigabit Ethernet Interface SFP+).

  • Les types d’interface de structure pris en charge pour les équipements SRX4600 sont les suivants : 40 Gigabit Ethernet (et) (emplacements QSFP pour l’interface 40 Gigabit Ethernet) et 10 Gigabit Ethernet (xe).

  • Les types d’interface de structure pris en charge pour les équipements de la gamme SRX5000 sont les suivants :

    • Fast Ethernet

    • Gigabit Ethernet

    • 10 Gigabit Ethernet

    • 40 Gigabit Ethernet

    • 100 Gigabit Ethernet

      À partir de Junos OS version 12.1X46-D10 et de Junos OS Version 17.3R1, l’interface 100-Gigabit Ethernet est prise en charge sur les équipements de la gamme SRX5000.

      À partir de Junos OS version 19.3R1, les srx5K-IOC4-10G et SRX5K-IOC4-MRAT sont pris en charge avec SRX5K-SPC3 sur les équipements SRX5000 Series. SRX5K-IOC4-10G MPIC prend en charge MACsec.

Pour plus de détails sur l’utilisation des ports et des interfaces pour les liaisons de gestion, de contrôle et de structure, reportez-vous à Understanding SRX Series Chassis Cluster Slot Numbering et Physical Port and Logical Interface Naming.

Prise en charge des trames Jumbo

La liaison de données de la structure ne prend pas en charge la fragmentation. Pour prendre en charge cet état, la prise en charge de trames jumbo est activée par défaut sur la liaison avec une taille d’unité de transmission (MTU) maximale de 9 014 octets (9 000 octets de charge utile + 14 octets pour l’en-tête Ethernet) sur les équipements SRX Series. Pour s'assurer que le trafic transitant la liaison de données ne dépasse pas cette taille, nous recommandons qu'aucune autre interface ne dépasse la taille MTU de la liaison de données de structure.

Comprendre les interfaces de structure sur les équipements de ligne SRX5000 pour IOC2 et IOC3

À partir de Junos OS version 15.1X49-D10, le SRX5K-MPC3-100G10G (IOC3) et le SRX5K-MPC3-40G10G (IOC3) sont introduits.

Le SRX5K-MPC (IOC2) est un concentrateur de ports modulaire (MPC) pris en charge sur les SRX5400, SRX5600 et SRX5800. Cette carte d’interface accepte les cartes d’interface modulaires (MIC), qui ajoutent des ports Ethernet à votre passerelle de services pour fournir les connexions physiques à différents types de supports réseau. Les MPC et MMC prennent en charge les liaisons de structure pour les clusters de châssis. La SRX5K-MPC est dotée de ports de structure 10 Gigabit Ethernet (avec MIC 10 x 10GE), 40 Gigabit Ethernet, 100 Gigabit Ethernet et 20 ports Ethernet 1GE. Sur les équipements SRX5400, seuls les IOC2 (SRX5K-MPC) sont pris en charge.

SrX5K-MPC3-100G10G (IOC3) et SRX5K-MPC3-40G10G (IOC3) sont des concentrateurs de ports modulaires (MPC) pris en charge sur les SRX5400, SRX5600 et SRX5800. Ces cartes d’interface acceptent les cartes d’interface modulaires (MIC), qui ajoutent des ports Ethernet à votre passerelle de services pour fournir les connexions physiques à différents types de supports réseau. Les MPC et MMC prennent en charge les liaisons de structure pour les clusters de châssis.

Les deux types de concentrateurs de ports modulaires (MPC) IOC3, qui ont différents MIC intégrés, sont les MPC 24x10GE + 6x40GE et 2x100GE + 4x10GE MPC.

En raison de contraintes électriques et thermiques, les quatre PIC du 24x10GE + 6x40GE ne peuvent pas être sous tension. Un maximum de deux PIC peut être sous tension simultanément.

Utilisez la set chassis fpc <slot> pic <pic> power off commande pour choisir les PIC sur lesquels vous souhaitez mettre sous tension.

Sur les équipements SRX5400, SRX5600 et SRX5800 dans un cluster de châssis, lorsque les PIC contenant des liens de structure sur le SRX5K-MPC3-40G10G (IOC3) sont éteints pour allumer d’autres PIC, veillent toujours à ce que :

  • Les nouvelles liaisons de structure sont configurées sur les nouveaux PIC activés. Au moins une liaison de structure doit être présente et en ligne pour garantir une perte minimale de RTO.

  • Le cluster de châssis est en mode actif-passif pour garantir une perte de RTO minimale, une fois que les liaisons alternatives sont mises en ligne.

  • Si aucune autre liaison de structure n’est configurée sur les PIC activés, la communication synchrone RTO entre les deux nœuds s’arrête et l’état de session du cluster de châssis ne peut pas être relançé, car la liaison de structure est manquante. Vous pouvez afficher la sortie CLI de ce scénario indiquant l’état d’un cluster de châssis défectueux à l’aide de la show chassis cluster interfaces commande.

Comprendre les RPO de session

Le logiciel de plan de données, qui fonctionne en mode actif/actif, gère le traitement des flux et la redondance de l’état de session, et traite le trafic en transit. Tous les paquets appartenant à une session particulière sont traités sur le même nœud pour s’assurer qu’un même traitement de sécurité leur est appliqué. Le système identifie le nœud sur lequel une session est active et transfère ses paquets vers ce nœud pour traitement. (Après traitement d’un paquet, le moteur de transfert de paquets transmet le paquet au nœud sur lequel se trouve son interface de sortie si ce nœud n’est pas le nœud local.)

Pour assurer la redondance de session (ou de flux), le logiciel de plan de données synchronise son état en envoyant des paquets de charge utile spéciaux appelés objets d’exécution (RPO) d’un nœud à l’autre sur la liaison de données de la structure. En transmettant des informations sur une session entre les nœuds, les RB assurent la cohérence et la stabilité des sessions en cas de basculement, ce qui permet au système de continuer à traiter le trafic appartenant aux sessions existantes. Pour garantir que les informations de session sont toujours synchronisées entre les deux nœuds, le logiciel du plan de données donne la priorité de transmission aux RTO sur le trafic de transit.

Le logiciel de plan de données crée des RCO pour les sessions UDP et TCP et suit les modifications d’état. Il synchronise également le trafic pour les protocoles de transmission IPv4 tels que GRE (Generic Routing Encapsulation) et IPsec.

Les RTO pour la synchronisation d’une session incluent les éléments suivants :

  • Création de sessions RFO sur le premier paquet

  • Suppression de session et RCO obsolètes

  • RFO liés aux changements, notamment :

    • Changements d’état TCP

    • Messages de réponse et de demande de synchronisation de délai d’expiration

    • RPO pour la création et la suppression des ouvertures temporaires dans les pare-feu (trous d’épingle) et les trous d’épingle de session pour enfants

Comprendre le transfert de données

Pour Junos OS, le traitement des flux se produit sur un nœud unique sur lequel la session de ce flux a été établie et est active. Cette approche garantit que les mêmes mesures de sécurité sont appliquées à tous les paquets appartenant à une session.

Un cluster de châssis peut recevoir du trafic sur une interface d’un nœud et l’envoyer à une interface de l’autre nœud. (En mode actif/actif, l’interface d’entrée du trafic peut exister sur un nœud et son interface de sortie sur l’autre.)

Ce passage est requis dans les situations suivantes :

  • Lorsque les paquets sont traités sur un nœud, mais doivent être transféré vers une interface de sortie sur l’autre nœud

  • Lorsque des paquets arrivent sur une interface sur un nœud, mais doivent être traités sur l’autre nœud

    Si les interfaces d’entrée et de sortie d’un paquet se trouvent sur un nœud, mais que le paquet doit être traité sur l’autre nœud parce que sa session y a été établie, il doit traverser deux fois la liaison de données. Cela peut être le cas pour certaines sessions multimédia complexes, telles que les sessions VoIP (Voice-over-IP).

Comprendre la défaillance et la récupération des liaisons de données de la structure

Les services de détection et de prévention des intrusions (IDP) ne prennent pas en charge le basculement. C’est pourquoi les services IDP ne sont pas appliqués aux sessions présentes avant le basculement. Les services IDP sont appliqués aux nouvelles sessions créées sur le nouveau nœud principal.

La liaison de données de la structure est essentielle au cluster de châssis. Si la liaison n’est pas disponible, le transfert de trafic et la synchronisation RTO sont affectés, ce qui peut entraîner une perte de trafic et un comportement système imprévisible.

Pour éliminer cette possibilité, Junos OS utilise la surveillance de la structure pour vérifier si la liaison de structure ou les deux liaisons de structure dans le cas d’une configuration de liaison double de structure sont vivantes en transmettant périodiquement des sondes sur les liaisons de structure. Si Junos OS détecte les pannes de structure, l’état RG1+ du nœud secondaire devient inéligible. Il détermine qu’un problème de structure s’est produit si une sonde de structure n’est pas reçue, mais que l’interface de structure est active. Pour récupérer de cet état, les liaisons de la structure doivent revenir à l’état en ligne et doivent commencer à échanger des sondes. Dès que cela se produira, tous les FPC du nœud préalablement inéligible seront réinitialisés. Ils arrivent ensuite à l’état en ligne et rejoignent le cluster.

Si vous apportez des modifications à la configuration alors que le nœud secondaire est désactivé, exécutez la commit commande pour synchroniser la configuration après le redémarrage du nœud. Si vous n’avez pas apporté de modifications de configuration, le fichier de configuration reste synchronisé avec celui du nœud principal.

À partir de Junos OS version 12.1X47-D10 et de Junos OS version 17.3R1, la fonctionnalité de surveillance de la structure est activée par défaut sur les équipements SRX5800, SRX5600 et SRX5400.

À partir de Junos OS version 12.1X47-D10 et de Junos OS version 17.3R1, la récupération de la liaison de structure et la synchronisation s’effectuent automatiquement.

Lorsque les nœuds primaire et secondaire sont en bonne santé (c’est-à-dire qu’il n’y a pas de défaillance) et que la liaison de structure tombe en panne, les groupes de redondance RG1+ sur le nœud secondaire deviennent inéligibles. Lorsque l’un des nœuds est défectueux (c’est-à-dire qu’il y a une défaillance), le ou les groupes de redondance RG1+ sur ce nœud (le nœud principal ou secondaire) deviennent inéligibles. Lorsque les deux nœuds sont défectueux et que la liaison de structure tombe en panne, le ou les groupes de redondance RG1+ sur le nœud secondaire deviennent inéligibles. Lorsque la liaison de structure est apparue, le nœud sur lequel le RG1+ est devenu inéligible procède à une synchronisation à froid sur toutes les unités de traitement des services et passe à une mise en veille active.

  • Si le RG0 est principal sur un nœud défectueux, le RG0 basculera d’un nœud défectueux vers un nœud sain. Par exemple, si le nœud 0 est principal pour RG0+ et que le nœud 0 devient défectueux, alors le nœud RG1+ sur le nœud 0 passera à inéligible après 66 secondes de défaillance d’une liaison de structure et le nœud RG0+ tombe sur le nœud 1, qui est le nœud sain.

  • Seul le RG1+ passe à un état inéligible. Le RG0 reste à l’état primaire ou secondaire.

Utilisez la show chassis cluster interfaces commande CLI pour vérifier l’état de la liaison de structure.

Voir aussi

Exemple : configuration des interfaces de structure de cluster de châssis

Cet exemple montre comment configurer la structure de cluster de châssis. La structure est la connexion de données d’arrière en arrière entre les nœuds d’un cluster. Le trafic d’un nœud qui doit être traité sur l’autre nœud ou de quitter via une interface de l’autre nœud passe par-dessus la structure. Les informations sur l’état des sessions passent également par la structure.

Exigences

Avant de commencer, définissez l’ID de cluster de châssis et l’ID de nœud de cluster de châssis. Voir l’exemple : définition de l’ID de nœud et de l’ID de cluster pour les équipements de sécurité dans un cluster de châssis .

Aperçu

Dans la plupart des équipements SRX Series dans un cluster de châssis, vous pouvez configurer n’importe quelle paire d’interfaces Gigabit Ethernet ou n’importe quelle paire d’interfaces 10 Gigabit afin de servir de structure entre les nœuds.

Vous ne pouvez pas configurer de filtres, de stratégies ou de services sur l’interface de la structure. La fragmentation n’est pas prise en charge sur la liaison de structure. La taille MTU maximale pour les interfaces de structure est de 9 014 octets et la taille MTU maximale pour les autres interfaces est de 8 900 octets. La prise en charge des trames Jumbo sur les liens membres est activée par défaut.

Cet exemple illustre comment configurer la liaison de structure.

Seul le même type d’interfaces peut être configuré en tant qu’enfants de la structure, et vous devez configurer un nombre égal de liens enfants pour fab0 et fab1.

Si vous connectez chacune des liaisons de la structure via un commutateur, vous devez activer la fonction de trame jumbo sur les ports de commutation correspondants. Si les deux liaisons de structure sont connectées par le même commutateur, la paire RTO-et-sondes doit se retrouver dans un lan virtuel (VLAN) et la paire de données doit être dans un autre VLAN. Ici aussi, la fonction de trame jumbo doit être activée sur les ports de commutation correspondants.

Configuration

Procédure

Configuration rapide CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez tous les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis entrez commit du mode de configuration.

Procédure étape par étape

Pour configurer la structure de cluster de châssis :

  • Spécifiez les interfaces de structure.

Résultats

Depuis le mode configuration, confirmez votre configuration en entrant la show interfaces commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration fournies dans cet exemple pour la corriger.

Par souci de brièveté, cette show sortie de commande inclut uniquement la configuration pertinente à cet exemple. Toute autre configuration du système a été remplacée par des ellipses (...).

Si vous avez terminé la configuration de l’unité, entrez commit dans le mode de configuration.

Vérification

Vérification de la structure de cluster de châssis

But

Vérifiez la structure de cluster de châssis.

Action

Dans le mode opérationnel, saisissez la show interfaces terse | match fab commande.

Vérification des interfaces de plan de données du cluster de châssis

But

Afficher l’état de l’interface du plan de données du cluster de châssis.

Action

Dans l’interface de ligne de commande, saisissez la show chassis cluster data-plane interfaces commande :

Affichage des statistiques du plan de données du cluster de châssis

But

Afficher les statistiques du plan de données du cluster de châssis.

Action

Dans l’interface de ligne de commande, saisissez la show chassis cluster data-plane statistics commande :

Suppression des statistiques sur le plan de données des clusters de châssis

Pour effacer les statistiques du plan de données du cluster de châssis affichées, saisissez la clear chassis cluster data-plane statistics commande de l’interface de ligne de commande :

Voir aussi

Documentation connexe

Tableau Historique des versions
Libération
Description
19,3R1
À partir de Junos OS version 19.3R1, les srx5K-IOC4-10G et SRX5K-IOC4-MRAT sont pris en charge avec SRX5K-SPC3 sur les équipements SRX5000 Series. SRX5K-IOC4-10G MPIC prend en charge MACsec.
15,1X49-D10
À partir de Junos OS version 15.1X49-D10, le SRX5K-MPC3-100G10G (IOC3) et le SRX5K-MPC3-40G10G (IOC3) sont introduits.
12,1 X 47
À partir de Junos OS version 12.1X47-D10 et de Junos OS version 17.3R1, la fonctionnalité de surveillance de la structure est activée par défaut sur les équipements SRX5800, SRX5600 et SRX5400.
12,1 X 47
À partir de Junos OS version 12.1X47-D10 et de Junos OS version 17.3R1, la récupération de la liaison de structure et la synchronisation s’effectuent automatiquement.
12,1 X 46
À partir de Junos OS version 12.1X46-D10 et de Junos OS Version 17.3R1, l’interface 100-Gigabit Ethernet est prise en charge sur les équipements de la gamme SRX5000.