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 fabric (fab) pour la synchronisation de session et le trafic direct entre les deux châssis. La liaison de fabric 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 :

Présentation des interfaces de structure de clusters de châssis

La structure est une connexion physique entre deux nœuds d’un cluster et est formée par la connexion d’une paire d’interfaces Ethernet dos à dos (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 fabric 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 qui doit être traité sur l’autre est transféré via la liaison de données de la fabric. De même, le trafic traité sur un nœud qui doit quitter via une interface sur l’autre nœud est transféré sur la fabric.

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 permet la synchronisation des objets d’état de session créés par des opérations telles que l’authentification, la traduction d’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 la 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 fabric configurées sur un cluster de châssis, la suppression de la configuration de fabric sur l’un ou l’autre nœud entraîne la désactivation du nœud secondaire du groupe de redondance 0 (RG0). (La réinitialisation d’un périphérique à la configuration d’usine par défaut supprime la configuration de la structure et entraîne ainsi le passage du nœud secondaire RG0 à un état désactivé.) Une fois la configuration de la fabric validée, ne réinitialisez pas l’un ou l’autre appareil à la configuration d’usine par défaut.

Types d’interfaces de fabric pris en charge pour les pare-feu SRX Series (SRX300 Series, SRX1500, SRX1600, SRX4100/SRX4200, SRX4600 et SRX5000 line)

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

  • Pour les équipements SRX300, SRX320, SRX340 et SRX345, le lien fabric peut être n’importe quelle paire d’interfaces Gigabit Ethernet. Pour les équipements SRX380, le lien fabric peut être n’importe quelle paire d’interfaces Gigabit Ethernet ou n’importe quelle paire d’interfaces 10 Gigabit Ethernet.

  • Pour SRX1500 et SRX1600, le lien de structure peut être n’importe quelle paire d’interfaces Ethernet couvrant le cluster. le lien fabric peut être n’importe quelle paire d’interface Gigabit Ethernet ou n’importe quelle paire d’interface 10 Gigabit Ethernet. Par SRX1600, le lien fabric peut également être n’importe quelle paire d’interfaces Ethernet 25 Gigabit.

  • Les types d’interfaces de fabric pris en charge pour les périphériques SRX4100 et SRX4200 sont 10 Gigabit Ethernet (xe) (emplacements SFP+ d’interface 10 Gigabit Ethernet).

  • Les types d’interfaces de fabric pris en charge pour les périphériques SRX4600 sont 40 Gigabit Ethernet (ET) (emplacements QSFP 40 Gigabit Ethernet Interface) et 10 Gigabit Ethernet (xe).

  • Les types d’interfaces de fabric pris en charge pour les périphériques de ligne SRX5000 sont les suivants :

    • Fast Ethernet

    • Gigabit Ethernet

    • 10 Gigabit Ethernet

    • Ethernet 40 Gigabits

    • 100 Gigabit Ethernet

      À partir de Junos OS version 12.1X46-D10 et Junos OS version 17.3R1, l’interface Ethernet 100 Gigabit est prise en charge sur les périphériques SRX5000 ligne.

      À 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 de la ligne SRX5000. Le SRX5K-IOC4-10G MPIC prend en charge MACsec.

Pour plus d’informations sur l’utilisation des ports et des interfaces pour la gestion, le contrôle et les liens de structure, voir Présentation de la numérotation des emplacements des clusters de châssis SRX Series et de la dénomination des ports physiques et des interfaces logiques.

Prise en charge des trames Jumbo

La liaison de données de la structure ne prend pas en charge la fragmentation. Pour tenir compte de cet état, la prise en charge des trames jumbo est activée par défaut sur la liaison avec une taille d’unité de transmission (MTU) maximale de 9014 octets (9 000 octets de charge utile + 14 octets pour l’en-tête Ethernet) sur les pare-feu SRX Series. Pour vous assurer que le trafic qui transite par la liaison de données ne dépasse pas cette taille, nous vous recommandons de ne pas dépasser la taille MTU de la liaison de données de la 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 port 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 aux différents types de supports réseau. Les MPC et les MIC prennent en charge les liaisons de structure pour les clusters de châssis. Le SRX5K-MPC fournit des ports Ethernet 10 Gigabit (avec MIC 10x10GE), 40 Gigabit Ethernet, 100 Gigabit Ethernet et 20x1GE Ethernet comme ports de fabric. Sur SRX5400 appareils, seuls les SRX5K-MPC (IOC2) sont pris en charge.

Le SRX5K-MPC3-100G10G (IOC3) et le 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 aux différents types de supports réseau. Les MPC et les MIC 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 des MIC intégrés différents, sont le MPC 24x10GE + 6x40GE et le MPC 2x100GE + 4x10GE.

En raison de contraintes électriques et thermiques, les quatre PIC du 24x10GE + 6x40GE ne peuvent pas être allumés. Un maximum de deux PIC peuvent être mis sous tension en même temps.

Utilisez la set chassis fpc <slot> pic <pic> power off commande pour choisir les PIC que vous souhaitez activer.

Sur les équipements SRX5400, SRX5600 et SRX5800 d’un cluster de châssis, lorsque les PIC contenant des liaisons de fabric du SRX5K-MPC3-40G10G (IOC3) sont éteints pour activer d’autres PIC, veillez toujours à ce que :

  • Les nouveaux liens de fabric sont configurés sur les nouveaux PIC activés. Au moins un lien de fabric doit être présent et en ligne pour minimiser les pertes de RTO.

  • Le cluster de châssis est en mode actif-passif pour minimiser les pertes de RTO une fois que d’autres liens sont mis 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 sauvegarde pas, car le lien de structure est manquant. Vous pouvez afficher la sortie CLI pour ce scénario indiquant un mauvais état de cluster de châssis à l’aide de la show chassis cluster interfaces commande.

Comprendre les RTO de session

Le logiciel du 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 de transit. Tous les paquets appartenant à une session particulière sont traités sur le même nœud pour s’assurer que le même traitement de sécurité leur est appliqué. Le système identifie le nœud sur lequel une session est active et transmet ses paquets à ce nœud pour traitement. (Une fois qu’un paquet est traité, 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 du plan de données synchronise son état en envoyant des paquets de charge utile spéciaux appelés objets d’exécution (RTO) d’un nœud à l’autre via la liaison de données de la structure. En transmettant des informations sur une session entre les nœuds, les RTO assurent la cohérence et la stabilité des sessions en cas de basculement, et permettent ainsi 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é à la transmission des RTO sur le trafic de transit.

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

Les RTO de synchronisation d’une session incluent :

  • RTO de création de session sur le premier paquet

  • RTO de suppression et expiration de sessions

  • OTR liées aux changements, notamment :

    • Changements d’état TCP

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

    • RTO pour créer et supprimer des ouvertures temporaires dans le pare-feu (trous d’épingle) et des trous d’épingle de session enfant

Comprendre le transfert de données

Pour Junos OS, le traitement des flux s’effectue sur un nœud unique sur lequel la session pour 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 pour le trafic peut exister sur un nœud et son interface de sortie sur l’autre.)

Cette traversée est requise dans les situations suivantes :

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

  • Lorsque les 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 la liaison de données deux fois. Cela peut être le cas pour certaines sessions multimédias complexes, telles que les sessions de voix sur IP (VoIP).

Comprendre l’échec et la récupération des liaisons de données de la fabric

Les services de détection et de prévention des intrusions (IDP) ne prennent pas en charge le basculement. Pour cette raison, les services IDP ne sont pas appliqués aux sessions qui étaient 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 vitale pour le 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 imprévisible du système.

Pour éliminer cette possibilité, Junos OS utilise la surveillance de la structure pour vérifier si le lien de structure, ou les deux liens de structure dans le cas d’une configuration de lien de structure double, sont actifs en transmettant périodiquement des sondes sur les liens de structure. Si Junos OS détecte des défauts de structure, l’état RG1+ du nœud secondaire passe à inéligible. Il détermine qu’une défaillance de fabric s’est produite si aucune sonde de fabric n’est reçue mais que l’interface de fabric est active. Pour récupérer de cet état, les deux liens de structure doivent revenir à l’état en ligne et commencer à échanger des sondes. Dès que cela se produit, tous les FPC sur le nœud précédemment inéligible seront réinitialisés. Ils passent 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 commande pour synchroniser la commit configuration après avoir redémarré le nœud. Si vous n’avez pas modifié la configuration, le fichier de configuration reste synchronisé avec celui du nœud principal.

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

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

Lorsque les nœuds principal et secondaire sont sains (c’est-à-dire qu’il n’y a pas de défaillance) et que le lien de fabric tombe en panne, le ou 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 inadmissibles. Lorsque les deux nœuds ne sont pas intègres et que la liaison de fabric tombe en panne, le(s) groupe(s) de redondance RG1+ sur le nœud secondaire devient inéligible. Lorsque le lien fabric apparaît, le nœud sur lequel RG1+ est devenu inéligible effectue une synchronisation à froid sur toutes les unités de traitement des services et passe en veille active.

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

  • Seul le GR1+ passe à un état non admissible. RG0 continue d’être dans un état primaire ou secondaire.

Utilisez la show chassis cluster interfaces commande CLI pour vérifier l’état du lien de fabric.

Voir aussi

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

Cet exemple montre comment configurer la structure du cluster de châssis. La structure est la connexion de données consécutive entre les nœuds d’un cluster. Le trafic sur un nœud qui doit être traité sur l’autre nœud ou qui doit sortir via une interface sur l’autre nœud passe sur la fabric. Les informations sur l’état de session passent également sur la structure.

Exigences

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

Aperçu

Dans la plupart des pare-feu SRX Series d’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 pour 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 le lien de structure. La taille MTU maximale pour les interfaces de fabric est de 9014octets et la taille MTU maximale pour les autres interfaces est de 8900 octets. La prise en charge des trames Jumbo sur les liens membres est activée par défaut.

Cet exemple illustre comment configurer le lien de structure.

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

Si vous connectez chacune des liaisons de fabric via un commutateur, vous devez activer la fonction de trame jumbo sur les ports de commutateur correspondants. Si les deux liaisons de fabric sont connectées via le même commutateur, la paire RTO-sondes doit se trouver dans un réseau local virtuel (VLAN) et la paire de données doit se trouver 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 de l’interface de ligne de commande

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

Procédure étape par étape

Pour configurer la structure du cluster de châssis :

  • Spécifiez les interfaces de la 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 de cet exemple pour la corriger.

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

Si vous avez terminé de configurer l’appareil, entrez commit à partir du mode de configuration.

Vérification

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

But

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

Action

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

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

But

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

Action

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

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

But

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

Action

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

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

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

Voir aussi

Documentation connexe

Tableau de l’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 de la ligne SRX5000. Le 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,1X47
À partir de Junos OS version 12.1X47-D10 et Junos OS version 17.3R1, la fonction de surveillance de la fabric est activée par défaut sur les équipements SRX5800, SRX5600 et SRX5400.
12,1X47
À partir de Junos OS version 12.1X47-D10 et Junos OS version 17.3R1, la récupération du lien de fabric et la synchronisation s’effectuent automatiquement.
12.1X46
À partir de Junos OS version 12.1X46-D10 et Junos OS version 17.3R1, l’interface Ethernet 100 Gigabit est prise en charge sur les périphériques SRX5000 ligne.