Descriptions des clusters de châssis et scénarios de déploiement
Divers déploiements d’un cluster de châssis
Les déploiements de pare-feu peuvent être actifs/passifs ou actifs/actifs.
Le mode cluster de châssis actif/passif est le type le plus courant de déploiement de pare-feu de cluster de châssis et se compose de deux pare-feu membres d’un cluster. L’un fournit activement des services de routage, de pare-feu, de NAT, de réseau privé virtuel (VPN) et de sécurité, tout en gardant le contrôle du cluster de châssis. L’autre pare-feu conserve passivement son état pour les fonctionnalités de basculement du cluster si le pare-feu actif devient inactif.
Les équipements SRX Series prennent en charge le mode de cluster de châssis actif/actif dans les environnements dans lesquels vous souhaitez maintenir le trafic sur les deux membres du cluster de châssis dans la mesure du possible. Dans un déploiement actif/actif d’un équipement SRX Series, seul le plan de données est en mode actif/actif, alors que le plan de contrôle est en mode actif/passif. Ainsi, un plan de contrôle peut contrôler les deux éléments du châssis comme un seul périphérique logique et, en cas de défaillance du plan de contrôle, le plan de contrôle peut basculer vers l’autre unité. Cela signifie également que le plan de données peut basculer indépendamment du plan de contrôle. Le mode actif/actif permet également aux interfaces entrantes de se trouver sur un membre du cluster et sur l’interface de sortie sur l’autre. Lorsque cela se produit, le trafic de données doit passer par la structure de données pour aller à l’autre membre du cluster et sortir de l’interface de sortie. C’est ce qu’on appelle le mode Z. Le mode actif/actif permet également aux routeurs d’avoir des interfaces locales sur des membres de cluster individuels qui ne sont pas partagées entre le cluster lors du basculement, mais qui n’existent que sur un seul châssis. Ces interfaces sont souvent associées à des protocoles de routage dynamique qui basculent le trafic vers l’autre membre du cluster si nécessaire. La figure 1 montre deux périphériques SRX5800 dans un cluster.
Pour gérer efficacement les clusters SRX, les applications de gestion du réseau doivent effectuer les opérations suivantes :
Identification et surveillance des noeuds primaires et secondaires
Surveiller les groupes de redondance et les interfaces
Surveiller les plans de contrôle et de données
Surveillez les basculements et les défaillances
La Figure 2 illustre la configuration des équipements haut de gamme SRX Series pour la gestion et l’administration hors bande.
de secours
La Figure 3 illustre la configuration des équipements de filiale SRX Series pour la gestion et l’administration hors bande.
de secours
Connexion des noeuds primaires et secondaires
Voici la meilleure configuration pour se connecter au cluster à partir des systèmes de gestion. Cette configuration garantit que le système de gestion est en mesure de se connecter aux nuds principaux et secondaires.
user@host# show groups
node0 {
system {
host-name SRX3400-1;
backup-router 172.19.100.1 destination 10.0.0.0/8;
services {
outbound-ssh {
client nm-10.200.0.1 {
device-id A9A2F7;
secret "$9$T3Ct0BIEylIRs24JDjO1IRrevWLx-VeKoJUDkqtu0BhS"; ## SECRET-DATA
services netconf;
10.200.0.1 port 7804;
}
}
}
syslog {
file messages {
any notice;
structured-data;
}
}
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.19.100.164/24;
}
}
}
}
}
node1 {
system {
host-name SRX3400-2;
backup-router 172.19.100.1 destination 10.0.0.0/8;
services {
outbound-ssh {
client nm-10.200.0.1 {
device-id F007CC;
secret "$9$kPFn9ApOIEAtvWXxdVfTQzCt0BIESrIR-VsYoa9At0Rh"; ## SECRET-DATA
services netconf;
10.200.0.1 port 7804;
}
}
}
}
}
# The following syslog configuration is not applicable for Branch SRX Series Services Gateways:
syslog {
file default-log-messages {
any notice;
structured-data;
}
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.19.100.165/24;
}
}
}
}
user@host# show apply-groups
apply-groups "${node}";
{primary:node0} [edit]
user@host# show interfaces
interfaces {
fxp0 {
unit 0 {
family inet {
filter {
input protect;
}
address 172.19.100.166/24 {
master-only;
}
}
}
}
}
{primary:node0}[edit]
user@host# show snmp
location "Systest lab";
contact "Lab Admin";
view all {
oid .1 include;
}
community srxread {
view all;
}
community srxwrite {
authorization read-write;
}
trap-options {
source-address 172.19.100.166;
}
trap-group test {
targets {
10.200.0.1;
}
}
v3 {
vacm {
security-to-group {
security-model usm {
security-name test123 {
group test1;
}
security-name juniper {
group test1;
}
}
}
access {
group test1 {
default-context-prefix {
security-model any {
security-level authentication {
read-view all;
}
}
}
context-prefix MGMT_10 {
security-model any {
security-level authentication {
read-view all;
}
}
}
}
}
}
target-address petserver {
address 116.197.178.20;
tag-list router1;
routing-instance MGMT_10;
target-parameters test;
}
target-parameters test {
parameters {
message-processing-model v3;
security-model usm;
security-level authentication;
security-name juniper;
}
notify-filter filter1;
}
notify server {
type trap;
tag router1;
}
notify-filter filter1 {
oid .1 include;
}
}
{primary:node0}[edit]
user@host# show routing-options
static {
route 10.200.0.1/32 next-hop 172.19.100.1;
}
primary:node0}[edit]
root@SRX3400-1# show firewall
term permit-ssh {
from {
source-address {
10.200.0.0/24;
}
protocol tcp;
destination-port [ ssh telnet ];
}
then accept;
}
term permit-udp {
from {
source-address {
207.17.137.28/32;
}
protocol udp;
}
then accept;
}
term permit-icmp {
from {
protocol icmp;
icmp-type [ echo-reply echo-request ];
}
then accept;
}
term permit-ntp {
from {
source-address {
149.20.68.16/32;
}
protocol udp;
port ntp;
}
then accept;
}
term permit-ospf {
from {
protocol ospf;
}
then accept;
}
term permit-snmp {
from {
source-address {
10.200.0.0/24;
}
protocol udp;
port [ snmp snmptrap ];
}
then accept;
}
term deny-and-count {
from {
source-address {
0.0.0.0/0;
}
}
then {
count denied;
reject tcp-reset;
}
}
}
Explication de la configuration
La meilleure façon de se connecter à un cluster de châssis SRX Series via l’interface fxp0 (un nouveau type d’interface) consiste à attribuer des adresses IP aux ports de gestion sur les nuds principal et secondaire à l’aide de groupes.
Utilisez une adresse IP primaire uniquement dans le cluster. De cette façon, vous pouvez interroger une seule adresse IP et cette adresse IP est toujours la principale pour le groupe de redondance 0. Si vous n’utilisez pas d’adresse IPv4 principale uniquement, chaque adresse IP de nœud doit être ajoutée et surveillée. La surveillance des nœuds secondaires est limitée, comme détaillé dans cette rubrique.
Note:Nous vous recommandons d’utiliser une adresse IPv4 principale uniquement pour la gestion, en particulier lorsque vous utilisez SNMP. L’appareil reste ainsi joignable même après un basculement.
Avec la configuration de l’interface fxp0 présentée précédemment, l’adresse IPv4 de gestion sur l’interface fxp0 du nœud secondaire d’un cluster de châssis n’est pas accessible. Le sous-système de routage de nœud secondaire n’est pas en cours d’exécution. L’interface fxp0 est accessible par les hôtes qui se trouvent sur le même sous-réseau que l’adresse IPv4 de gestion. Si l’hôte se trouve sur un sous-réseau différent de celui de l’adresse IPv4 de gestion, la communication échoue. Il s’agit d’un comportement attendu qui fonctionne comme prévu. Le moteur de routage du membre de cluster secondaire n’est pas opérationnel avant le basculement. Le processus de protocole de routage ne fonctionne pas dans le noeud secondaire lorsque le noeud principal est actif. Lorsque l’accès à la gestion est nécessaire, l’instruction de
backup-routerconfiguration peut être utilisée.Avec l’instruction
backup-router, le nœud secondaire est accessible à partir d’un sous-réseau externe à des fins de gestion. En raison d’une limitation du système, ne configurez pas l’adresse de destination spécifiée dans le 'backup-router0.0.0.0/0' ou ' ::/0'. Le masque doit avoir une valeur différente de zéro. Plusieurs destinations peuvent être incluses si votre plage d’adresses IP de gestion n’est pas contiguë. Dans cet exemple, le routeur de sauvegarde 172.19.100.1 est accessible via l’interface fxp0 et l’adresse IPv4 du système de gestion du réseau de destination est 10.200.0.1. L’adresse de gestion du réseau est accessible via le routeur de secours. Pour que le routeur de sauvegarde atteigne le système de gestion du réseau, incluez le sous-réseau de destination dans la configuration du routeur de sauvegarde.Nous vous recommandons d’utiliser l’adresse SSH sortante pour vous connecter aux systèmes de gestion à l’aide du protocole SSH, du protocole de gestion XML NETCONF ou du protocole de gestion XML Junos OS. Ainsi, l’appareil se reconnecte automatiquement, même après un basculement.
Nous vous recommandons d’utiliser les mêmes ID de moteur SNMP pour chaque nœud. En effet, SNMPv3 utilise les valeurs d’ID du moteur SNMP pour l’authentification des unités de données de protocole (PDU), et si les valeurs d’ID du moteur SNMP sont différentes pour chaque nœud, SNMPv3 peut échouer après un basculement du moteur de routage.
Gardez les autres configurations SNMP, telles que les communautés SNMP, les groupes d’interruptions, etc., communes entre les nuds, comme indiqué dans l’exemple de configuration.
Note:Les interruptions SNMP sont envoyées uniquement à partir du noeud principal. Cela inclut les événements et les défaillances détectés sur le nœud secondaire. Le noeud secondaire n’envoie jamais d’interruptions ou d’alertes SNMP. Utilisez l’option configurable pour restreindre l’accès
client-onlySNMP aux seuls clients requis. Utilisez SNMPv3 pour le chiffrement et l’authentification.Les messages Syslog doivent être envoyés à partir des deux nœuds séparément car les messages de journal sont spécifiques au nœud.
Si la station de gestion se trouve sur un sous-réseau différent de celui des adresses IP de gestion, spécifiez le même sous-réseau dans la configuration du routeur de sauvegarde et ajoutez une route statique sous le niveau hiérarchique
[edit routing-options]si nécessaire. Dans l’exemple de configuration précédent, l’adresse de gestion du réseau 10.200.0.1 est accessible via le routeur de secours. Par conséquent, une route statique est configurée.Vous pouvez restreindre l’accès à l’appareil à l’aide de filtres de pare-feu. L’exemple de configuration précédent montre que SSH, SNMP et Telnet sont limités au réseau 10.0.0.0/8. Cette configuration autorise le trafic UDP, ICMP, OSPF et NTP et refuse tout autre trafic. Ce filtre est appliqué à l’interface fxp0.
Vous pouvez également utiliser des zones de sécurité pour restreindre le trafic. Pour plus d’informations, consultez le Guide de configuration de la sécurité Junos OS.
Configuration supplémentaire pour les équipements de succursale SRX Series
La configuration d’usine par défaut des équipements SRX100, SRX210 et SRX240 active automatiquement la commutation Ethernet de couche 2. Étant donné que la commutation Ethernet de couche 2 n’est pas prise en charge en mode cluster de châssis, si vous utilisez la configuration d’usine par défaut, vous devez supprimer la configuration de commutation Ethernet avant d’activer la mise en cluster de châssis pour ces périphériques.
Il n’y a pas d’interface de gestion fxp0 dédiée. L’interface fxp0 est réutilisée à partir d’une interface intégrée. Par exemple, sur les équipements SRX100, l’interface fe-0/0/06 est réaffectée en tant qu’interface de gestion et est automatiquement renommée fxp0. Pour plus d’informations sur l’interface de gestion, reportez-vous au Guide de configuration de la sécurité Junos OS.
Syslog doit être utilisé avec prudence. Cela peut entraîner une instabilité du cluster. La journalisation du plan de données ne doit jamais être envoyée via syslogs pour les équipements de succursale SRX Series.
Gestion des clusters de châssis
Gestion des clusters de châssis via des interfaces Ethernet redondantes —Les clusters de châssis SRX Series peuvent être gérés à l’aide des interfaces Ethernet redondantes (reth). La configuration des groupes de redondance et des interfaces Reth diffère en fonction des déploiements tels que le mode actif/actif et le mode actif/passif. Reportez-vous au Guide de configuration de la sécurité Junos OS pour plus de détails sur la configuration. Une fois que les interfaces reth sont configurées et accessibles depuis la station de gestion, les nœuds secondaires sont accessibles via les interfaces reth.
Si l’interface reth appartient au groupe de redondance 1+, la connexion TCP à la station de gestion est transférée de manière transparente vers le nouveau primaire. Toutefois, si le basculement du groupe de redondance 0 se produit et que le moteur de routage bascule vers un nouveau nud, la connectivité est perdue pour toutes les sessions pendant quelques secondes.
Gestion des clusters via les interfaces de transit : les équipements en cluster peuvent être gérés à l’aide d’interfaces de transit. Il n’est pas possible d’utiliser directement une interface de transit pour atteindre un noeud secondaire.
Configuration des équipements pour la gestion et l’administration intrabande
La fonctionnalité de cluster de châssis disponible dans Junos OS pour les passerelles de services SRX Series est modélisée en fonction des fonctionnalités de redondance présentes dans les équipements basés sur Junos OS. Conçus avec des plans de contrôle et de données distincts, les équipements basés sur Junos OS assurent la redondance dans les deux plans. Le plan de contrôle dans Junos OS est géré par les moteurs de routage, qui effectuent tous les calculs de routage et de transfert, à l’exception des autres fonctions. Une fois que le plan de contrôle converge, les entrées de transfert sont envoyées à tous les moteurs de transfert de paquets du système. Les moteurs de transfert de paquets effectuent ensuite des recherches basées sur le routage afin de déterminer la destination appropriée pour chaque paquet sans aucune intervention des moteurs de routage.
Lors de l’activation d’un cluster de châssis dans un SRX Series Passerelle de services, le même modèle d’équipement est utilisé pour assurer la redondance du plan de contrôle, comme illustré à la Figure 4.
de clustering SRX Series
Comme un équipement avec deux moteurs de routage, le plan de contrôle d’un cluster SRX Series fonctionne en mode actif/passif avec un seul nud gérant activement le plan de contrôle à un moment donné. De ce fait, le plan de transfert dirige toujours tout le trafic envoyé au plan de contrôle (également appelé trafic entrant hôte) vers le nœud principal du cluster. Ce trafic comprend (sans s’y limiter) :
Trafic des processus de routage, tel que le trafic BGP, OSPF, IS-IS, RIP et PIM
Messages de négociation IKE
Trafic dirigé vers les processus de gestion, tels que SSH, Telnet, SNMP et NETCONF
Protocoles de surveillance, tels que BFD ou RPM
Ce comportement s’applique uniquement au trafic entrant de l’hôte. Le trafic direct (c’est-à-dire le trafic transféré par le cluster, mais qui n’est destiné à aucune des interfaces du cluster) peut être traité par l’un ou l’autre des nuds, en fonction de la configuration du cluster.
Étant donné que le plan de transfert dirige toujours le trafic entrant de l’hôte vers le nud principal, l’interface fxp0 fournit une connexion indépendante à chaque nud, quel que soit l’état du plan de contrôle. Le trafic envoyé à l’interface fxp0 n’est pas traité par le plan de transfert, mais est envoyé au noyau Junos OS, permettant ainsi de se connecter au plan de contrôle d’un nud, même sur le nud secondaire.
Cette rubrique explique comment gérer un cluster de châssis via le nœud principal sans nécessiter l’utilisation des interfaces fxp0, c’est-à-dire la gestion intrabande. Ceci est particulièrement nécessaire pour les équipements de succursale SRX Series, car le déploiement typique de ces équipements est tel qu’aucun réseau de gestion n’est disponible pour surveiller la succursale distante.
Avant Junos OS version 10.1 R2, la gestion d’un cluster à châssis de site distant SRX Series nécessitait une connectivité au plan de contrôle des deux membres du cluster, ce qui nécessitait un accès à l’interface fxp0 de chaque nud. Sous Junos OS version 10.1 R2 et ultérieure, les équipements de filiale SRX Series peuvent être gérés à distance à l’aide des interfaces reth ou des interfaces de couche 3.
Gestion des clusters SRX Series Branch Chassis via le nud principal
Pour accéder au nœud principal d’un cluster, il suffit d’établir une connexion à l’une des interfaces du nœud (autres que l’interface fxp0). Les interfaces de couche 3 et reth dirigent toujours le trafic vers le nœud principal, quel qu’il soit. Les deux scénarios de déploiement sont communs et sont illustrés aux figures 5 et 6.
Dans les deux cas, l’établissement d’une connexion à l’une des adresses locales se connecte au nœud principal. Pour être précis, vous êtes connecté au nœud principal du groupe de redondance 0. Par exemple, vous pouvez vous connecter au nœud principal même si l’interface reth, membre du groupe de redondance 1, est active dans un autre nœud (il en va de même pour les interfaces de couche 3, même si elles résident physiquement dans le nœud de secours). Vous pouvez utiliser SSH, Telnet, SNMP ou le protocole de gestion XML NETCONF pour surveiller le cluster de châssis SRX.
La Figure 5 illustre la gestion d’un équipement de filiale SRX Series via une interface reth. Ce modèle peut également être utilisé pour les équipements haut de gamme SRX Series, avec Junos OS version 10.4 ou ultérieure.
reth
La Figure 6 montre les connexions physiques pour la gestion intrabande à l’aide d’une interface de couche 3.
de couche 3
En cas de basculement, seules les connexions intrabande doivent pouvoir atteindre le nouveau nœud principal via les interfaces reth ou de couche 3 pour maintenir la connectivité entre la station de gestion et le cluster.
Le tableau 1 répertorie les avantages et les inconvénients de l’utilisation de différentes interfaces.
Interface fxp0 |
Interfaces Reth et de transit |
|---|---|
L’utilisation de l’interface fxp0 avec une adresse IP primaire uniquement permet d’accéder à toutes les instances de routage et à tous les routeurs virtuels du système. L’interface fxp0 ne peut faire que partie de la table de routage inet.0. Étant donné que la table de routage inet.0 fait partie de l’instance de routage par défaut, elle peut être utilisée pour accéder aux données de toutes les instances de routage et routeurs virtuels. |
Une interface transit ou reth n’a accès qu’aux données de l’instance de routage ou du routeur virtuel auquel elle appartient. S’il appartient à l’instance de routage par défaut, il a accès à toutes les instances de routage. |
L’interface fxp0 avec une adresse IP principale uniquement peut être utilisée pour la gestion de l’appareil même après le basculement, et nous vous le recommandons vivement. |
Les interfaces de transit perdent leur connectivité après un basculement (ou lorsque l’appareil hébergeant l’interface tombe en panne ou est désactivé), sauf si elles font partie d’un groupe reth. |
La gestion via l’interface fxp0 nécessite deux adresses IP, une par nœud. Cela signifie également qu’un commutateur doit être présent pour se connecter aux nœuds du cluster à l’aide de l’interface fxp0. |
L’interface reth n’a pas besoin de deux adresses IP et aucun commutateur n’est requis pour se connecter au cluster de châssis SRX Series. Les interfaces de transit sur chaque nud, si elles sont utilisées pour la gestion, ont besoin de deux adresses IP explicites pour chaque interface. Mais comme il s’agit d’une interface de transit, les adresses IP sont également utilisées pour le trafic en dehors de la gestion. |
Les clusters d’équipements de filiale SRX Series avec une liaison non Ethernet (ADSL, T1\E1) ne peuvent pas être gérés à l’aide de l’interface fxp0. |
Les équipements de filiale SRX Series avec une liaison non Ethernet peuvent être gérés à l’aide d’une interface reth ou de transit. |
Communication avec un équipement de cluster de châssis
Les stations de gestion peuvent utiliser les méthodes suivantes pour se connecter aux clusters de châssis SRX Series. Ceci est identique pour tous les équipements Junos OS et ne se limite pas aux clusters de châssis SRX Series. Nous vous recommandons d’utiliser une adresse IP principale uniquement pour l’un des protocoles suivants sur les clusters de châssis SRX Series. Les adresses IP de l’interface Reth peuvent être utilisées pour se connecter aux clusters à l’aide de l’une des interfaces suivantes.
Méthode |
Description |
|---|---|
SSH ou Telnet pour l’accès CLI |
Cette option n’est recommandée que pour la configuration et la surveillance manuelles d’un seul cluster. |
Protocole de gestion XML Junos OS |
Il s’agit d’une interface basée sur XML qui peut s’exécuter sur Telnet, SSH et SSL, et c’est un précurseur du protocole de gestion XML NETCONF. Il permet d’accéder aux API XML de Junos OS pour toutes les commandes de configuration et opérationnelles pouvant être saisies à l’aide de l’interface de ligne de commande. Nous recommandons cette méthode pour accéder aux informations opérationnelles. Il peut également s’exécuter sur une session de protocole de gestion XML NETCONF. |
Protocole de gestion XML NETCONF |
Il s’agit de l’interface XML standard définie par l’IETF pour la configuration. Nous vous recommandons de l’utiliser pour configurer l’appareil. Cette session peut également être utilisée pour exécuter des appels de procédure à distance (RPC) XML Management Protocol de Junos OS. |
SNMP |
Du point de vue d’un cluster de châssis SRX Series, le système SNMP considère les deux nuds des clusters comme un seul système. Un seul processus SNMP est en cours d’exécution sur le moteur de routage principal. Au moment de l’initialisation, le protocole principal indique quel processus SNMP (snmpd) doit être actif en fonction de la configuration principale du moteur de routage. Aucun snmpd n’est exécuté dans le moteur de routage passif. Par conséquent, seul le nud principal répond aux requêtes SNMP et envoie des interruptions à tout moment. Le noeud secondaire peut être interrogé directement, mais sa prise en charge MIB est limitée, comme indiqué dans la section Récupération de l’inventaire et des interfaces du châssis. Le noeud secondaire n’envoie pas d’interruptions SNMP. Les requêtes SNMP au nœud secondaire peuvent être envoyées à l’aide de l’adresse IP de l’interface fxp0 sur le nœud secondaire ou de l’adresse IP de l’interface reth. |
Syslogs (en anglais) |
Les messages de journal système standard peuvent être envoyés à un serveur syslog externe. Notez que les noeuds primaire et secondaire peuvent envoyer des messages syslog. Nous vous recommandons de configurer les nœuds principal et secondaire pour envoyer des messages syslog séparément. |
Messages du journal de sécurité (SPU) |
AppTrack, un outil de suivi des applications, fournit des statistiques pour analyser l’utilisation de la bande passante de votre réseau. Lorsque cette option est activée, AppTrack collecte des statistiques sur les octets, les paquets et la durée des flux d’application dans la zone spécifiée. Par défaut, à la fermeture de chaque session, AppTrack génère un message indiquant le nombre d’octets et de paquets, ainsi que la durée de la session, et envoie le message à l’équipement hôte. Les messages AppTrack sont similaires aux messages de journal de session et utilisent syslog ou les formats syslog structurés. Le message comprend également un champ d’application pour la session. Si AppTrack identifie une application définie sur mesure et renvoie un nom approprié, le nom de l’application personnalisée est inclus dans le message de journal. Notez que l’identification des applications doit être configurée pour que cela se produise. Consultez le Guide de configuration de la sécurité Junos OS pour plus de détails sur la configuration et l’utilisation de l’identification et du suivi des applications. |
J-Web (en anglais seulement) |
Tous les équipements Junos OS disposent d’une interface utilisateur graphique pour la configuration et l’administration. Cette interface peut être utilisée pour l’administration d’appareils individuels. |