SUR CETTE PAGE
Comprendre les interfaces de structure de cluster de châssis
Exemple : configuration des interfaces de la structure du cluster de châssis
Vérification des interfaces du plan de données du cluster de châssis
Affichage des statistiques du plan de données du cluster de châssis
Effacement des statistiques du plan de données du cluster de châssis
Comportement des interfaces de structure spécifiques à la plate-forme
Interfaces de structure de cluster de châssis
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Consultez la section Comportement des interfaces de structure spécifiques à la plate-forme pour obtenir des remarques relatives à votre plate-forme.
Consultez la section Informations supplémentaires sur la plate-forme pour plus d’informations.
Les équipements SRX Series d’un cluster de châssis utilisent l’interface de fabric (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 être du même type de support. Pour plus d’informations, consultez les rubriques suivantes :
Comprendre les interfaces de structure de cluster de châssis
La fabric est une connexion physique entre deux nœuds d’un cluster formée par la connexion d’une paire d’interfaces Ethernet l’une à la suite de l’autre (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 les châssis. Le trafic arrivant sur un nœud qui doit être traité sur l’autre est transféré sur la liaison de données de la fabric. De même, le trafic traité sur un nœud qui doit sortir via une interface de 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 de synchroniser les 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 fabric, le logiciel lui attribue une adresse IP dérivée en interne à utiliser pour la transmission de paquets.
Une fois que les interfaces de structure ont été configurées sur un cluster de châssis, la suppression de la configuration de structure sur l’un des nœuds entraîne le passage du nœud secondaire du groupe de redondance 0 (RG0) à l’état désactivé. (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 à l’état désactivé.) Une fois la configuration de la fabric validée, ne réinitialisez aucun des équipements à la configuration d’usine par défaut.
- Types d’interfaces de structure pris en charge pour les pare-feu SRX Series
- Prise en charge des trames Jumbo
- Comprendre les interfaces de structure sur SRX5000 gamme de pare-feu pour IOC2 et IOC3
- Comprendre les RTO de session
- Comprendre le transfert de données
- Comprendre la défaillance et la récupération d’une liaison de données de fabric
Types d’interfaces de structure pris en charge pour les pare-feu SRX 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.
Pour plus d’informations sur l’utilisation des ports et des interfaces pour la gestion, le contrôle et les liaisons de structure, reportez-vous à la section Présentation de la numérotation des emplacements de cluster du 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 fabric ne prend pas en charge la fragmentation. Pour s’adapter à cet état, la prise en charge des trames jumbo est activée par défaut sur la liaison avec une taille maximale de l’unité de transmission (MTU) 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 structure.
Comprendre les interfaces de structure sur SRX5000 gamme de pare-feu pour IOC2 et IOC3
Le SRX5K-MPC (IOC2) est un concentrateur de port modulaire (MPC) compatible avec 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 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 10 x 10GE), 40 Gigabit Ethernet, 100 Gigabit Ethernet et 20 ports Ethernet 1GE comme ports de structure. Sur SRX5400 appareils, seuls les MPC SRX5K (IOC2) sont pris en charge.
Le SRX5K-MPC3-100G10G (IOC3) et le SRX5K-MPC3-40G10G (IOC3) sont des concentrateurs de port modulaires (MPC) compatibles avec 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 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 différents MIC intégrés, sont le MPC 24x10GE + 6x40GE et le MPC 2x100GE + 4x10GE.
En raison de contraintes d’alimentation et thermiques, les quatre PIC du 24x10GE + 6x40GE ne peuvent pas être mis sous tension. 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 mettre sous tension.
Comprendre les RTO de session
Le logiciel de plan de données, qui fonctionne en mode actif/actif, gère le traitement des flux et la redondance des états 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 afin de 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 des sessions (ou 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 sur la liaison de données de la fabric. En transmettant des informations sur une session entre les nœuds, les RTO garantissent 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 s’assurer que les informations de session sont toujours synchronisées entre les deux nœuds, le logiciel de 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 RTO pour les sessions UDP et TCP et suit les changements d’état. Il synchronise également le trafic pour les protocoles d’intercommunication IPv4 tels que GRE (Generic Routing Encapsulation) et IPsec.
Les RTO de synchronisation d’une session sont les suivants :
-
RTO de création de session sur le premier paquet
-
RTO de suppression de session et d’ancienneté
-
RTO liés aux changements, y compris :
-
Changements d’état TCP
-
Messages de demande et de réponse de synchronisation de délai d’expiration
-
RTO pour la création et la suppression d’ouvertures temporaires dans le pare-feu (sténopés) et les trous d’épingle de session enfant
-
Comprendre le transfert de données
Pour Junos OS, le traitement de flux s’effectue 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 entrante 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 des paquets sont traités sur un nœud, mais qu’ils doivent être transférés, une interface de sortie sur l’autre nœud
-
Lorsque les paquets arrivent sur une interface d’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 car 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 la défaillance et la récupération d’une liaison de données de fabric
Les services de détection et de prévention d’intrusion (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 fabric est vitale pour le cluster de châssis. Si la liaison n’est pas disponible, le transfert du 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 fabric pour vérifier si la liaison de fabric, ou les deux liaisons de fabric dans le cas d’une configuration à double liaison de fabric, sont actives en transmettant régulièrement des sondes sur les liaisons de fabric. Si Junos OS détecte des défaillances de la 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 alors que l’interface de fabric est active. Pour récupérer de cet état, les deux liaisons de structure doivent revenir à l’état en ligne et doivent commencer à échanger des sondes. Dès que cela se produit, tous les FPC sur le nœud précédemment inéligible sont réinitialisés. Ils passent ensuite à l’état en ligne et rejoignent le cluster.
Si vous apportez des modifications à la configuration alors que le noeud secondaire est désactivé, exécutez la commit commande pour synchroniser la configuration après avoir redémarré le noeud. Si vous n’avez pas apporté de modifications à la configuration, le fichier de configuration reste synchronisé avec celui du nœud principal.
Lorsque les nœuds principal et secondaire sont sains (c’est-à-dire qu’il n’y a pas de défaillances) et que la liaison de fabric tombe en panne, le ou les groupes de redondance RG1+ sur le nœud secondaire deviennent inéligibles. Lorsque l’un des noeuds est défectueux (c’est-à-dire qu’il y a une défaillance), le(s) groupe(s) de redondance RG1+ sur ce noeud (nœud principal ou secondaire) devient inéligible. Lorsque les deux nœuds sont défectueux et que la liaison de fabric tombe en panne, le ou les groupes de redondance RG1+ sur le nœud secondaire deviennent inéligibles. Lorsque la liaison de structure est établie, 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 vers un nœud sain. Par exemple, si le noeud 0 est principal pour RG0+ et que le noeud 0 devient défectueux, RG1+ sur le noeud 0 devient inéligible 66 secondes après la défaillance d’une liaison fabric et RG0+ bascule vers le noeud 1, qui est le noeud sain.
-
Seul RG1+ passe à un état inéligible. RG0 continue d’être à 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 la structure du cluster de châssis
Cet exemple montre comment configurer la structure du cluster de châssis. La fabric est la connexion de données dos à dos entre les nœuds d’un cluster. Le trafic d’un nœud qui doit être traité sur l’autre nœud ou qui doit sortir via une interface de l’autre nœud passe par la fabric. Les informations sur l’état de la session transitent également par la fabric.
Exigences
Avant de commencer, définissez l’ID du cluster de châssis et l’ID de nœud du cluster de châssis. Reportez-vous à la section Exemple : Définition de l’ID de nœud et de l’ID de cluster pour les équipements de sécurité d’un cluster de châssis .
Aperçu
Dans la plupart des pare-feu SRX Series d’un cluster en 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 fabric 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 9014 octets et la taille MTU maximale pour les autres interfaces est de 8900 octets. La prise en charge des trames Jumbo sur les liaisons membres est activée par défaut.
Cet exemple illustre la configuration du lien 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 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 LAN 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 la CLI
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 commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
{primary:node0}[edit]
set interfaces fab0 fabric-options member-interfaces ge-0/0/1
set interfaces fab1 fabric-options member-interfaces ge-7/0/1
Procédure étape par étape
Pour configurer la structure du cluster de châssis :
Spécifiez les interfaces de la structure.
{primary:node0}[edit] user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/1 {primary:node0}[edit] user@host# set interfaces fab1 fabric-options member-interfaces ge-7/0/1
Résultats
À partir du 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, la sortie de cette show commande inclut uniquement la configuration pertinente pour cet exemple. Toute autre configuration du système a été remplacée par des ellipses (...).
{primary:node0}[edit]
user@host# show interfaces
...
fab0 {
fabric-options {
member-interfaces {
ge-0/0/1;
}
}
}
fab1 {
fabric-options {
member-interfaces {
ge-7/0/1;
}
}
}
Si vous avez terminé de configurer l’appareil, passez commit en 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
À partir du mode opérationnel, entrez la show interfaces terse | match fab commande.
{primary:node0}
user@host> show interfaces terse | match fab
ge-0/0/1.0 up up aenet --> fab0.0
ge-7/0/1.0 up up aenet --> fab1.0
fab0 up up
fab0.0 up up inet 30.17.0.200/24
fab1 up up
fab1.0 up up inet 30.18.0.200/24
Vérification des interfaces du plan de données du cluster de châssis
But
Affichez l’état de l’interface du plan de données du cluster du châssis.
Action
Dans l’interface de ligne de commande, entrez la show chassis cluster data-plane interfaces commande :
{primary:node1}
user@host> show chassis cluster data-plane interfaces
fab0:
Name Status
ge-2/1/9 up
ge-2/2/5 up
fab1:
Name Status
ge-8/1/9 up
ge-8/2/5 up
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 :
{primary:node1}
user@host> show chassis cluster data-plane statistics
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 0 0
Session create 0 0
Session close 0 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RTSP ALG 0 0
Effacement des statistiques du plan de données du cluster de châssis
Pour effacer les statistiques de plan de données du cluster de châssis affichées, entrez la clear chassis cluster data-plane statistics commande à partir de l’interface de ligne de commande :
{primary:node1}
user@host> clear chassis cluster data-plane statistics
Cleared data-plane statistics
Voir aussi
Comportement des interfaces de structure spécifiques à la plate-forme
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
Utilisez le tableau suivant pour examiner le comportement spécifique à votre plate-forme.
| Plateforme |
Différence |
|---|---|
| SRX Series |
|
Informations supplémentaires sur la plate-forme
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.
D’autres plateformes peuvent être prises en charge.
| Plateforme |
Interfaces de structure prises en charge |
|---|---|
| Le SRX380 |
|
| SRX1500 |
|
| SRX1600 |
|
| SRX2300 et SRX4300 |
|
| SRX4600 |
|
| SRX4100 et SRX4200 |
|
| Gamme SRX5000 de pare-feu |
|
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.