Nœuds de surveillance dans un cluster de châssis
Pour surveiller le cluster, vous devez découvrir les groupes de redondance. Lorsque vous initialisez un périphérique en mode cluster de châssis, le système crée un groupe de redondance appelé groupe de redondance 0 dans cette rubrique. Le groupe de redondance 0 gère la primauté et le basculement entre les moteurs de routage sur chaque nœud du cluster. Comme c’est le cas pour tous les groupes de redondance, le groupe de redondance 0 ne peut être principal que sur un seul nœud à la fois. Le nœud sur lequel le groupe de redondance 0 est principal détermine quel moteur de routage est actif dans le cluster. Un nœud est considéré comme le nœud principal du cluster si son moteur de routage est actif. Vous pouvez configurer un ou plusieurs groupes de redondance numérotés de 1 à 128, appelés groupe de redondance x dans cette section. Le nombre maximal de groupes de redondance est égal au nombre d’interfaces Ethernet redondantes +1 que vous configurez. Chaque groupe de redondance x agit comme une unité indépendante de basculement et est primaire sur un seul nœud à la fois. Aucune MIBS n’est disponible pour récupérer ces informations.
Utilisation du protocole de gestion XML Junos OS ou du protocole de gestion XML NETCONF
Utilisez l’appel get-configuration de procédure distante (RPC) pour obtenir la configuration de redondance et les groupes de redondance présents sur le périphérique. Les groupes de redondance configurés sont ainsi fournis.
RPC XML pour la récupération de la configuration
<rpc> <get-configuration inherit="inherit" database="committed"> <configuration> <chassis> <cluster> </cluster> </chassis> </configuration> </get-configuration> </rpc>
Réponse:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm" junos:commit-seconds="1277806450" junos:commit-localtime="2010-06-29 03:14:10 PDT" junos:commit-user="regress"> <chassis> <cluster> <reth-count>10</reth-count> <control-ports> <fpc>4</fpc> <port>0</port> </control-ports> <control-ports> <fpc>10</fpc> <port>0</port> </control-ports> <redundancy-group> <name>0</name> <node> <name>0</name> <priority>254</priority> </node> <node> <name>1</name> <priority>1</priority> </node> </redundancy-group> <redundancy-group> <name>1</name> <node> <name>0</name> <priority>100</priority> </node> <node> <name>1</name> <priority>1</priority> </node> </redundancy-group> </cluster> </chassis> </configuration> </rpc-reply> ]]>]]>
Interfaces Ethernet redondantes du cluster de châssis
Une interface Ethernet redondante est une pseudo-interface qui inclut au moins une interface physique à partir de chaque nœud du cluster. Une interface Ethernet redondante est appelée reth dans les commandes de configuration. L’exemple de sortie suivant montre deux groupes de redondance présents et configurés.
- Utilisation du protocole de gestion XML Junos OS ou du protocole de gestion XML NETCONF
- Utilisation de SNMP
Utilisation du protocole de gestion XML Junos OS ou du protocole de gestion XML NETCONF
Utilisez l’appel de procédure distante (RPC) pour obtenir les détails de l’interface
get-chassis-cluster-interfacesreth. L’exemple de sortie suivant montre quatre interfaces reth configurées :XML RPC pour les interfaces de cluster de châssis
user@host>
show chassis cluster interfaces |display xml<rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.4R5/junos"> <chassis-cluster-interface-statistics> <control-interface-status>Up</control-interface-status> <control-link-interfaces> <control-information> <control-link-interface-index>0</control-link-interface-index> <control-link-interface-name>em0</control-link-interface-name> <control-link-interface-status>Up</control-link-interface-status> </control-information> <control-information> <control-link-interface-index>1</control-link-interface-index> <control-link-interface-name>em1</control-link-interface-name> <control-link-interface-status>Down</control-link-interface-status> </control-information> </control-link-interfaces> <dataplane-interface-status>Up</dataplane-interface-status> <dataplane-interfaces> <fabric-information> <fabric-interface-index>0</fabric-interface-index> <fabric-child-interface-name>ge-6/0/15</fabric-child-interface-name> <fabric-child-interface-status>Up</fabric-child-interface-status> <fabric-interface-index>0</fabric-interface-index> </fabric-information> <fabric-information> <fabric-interface-index>1</fabric-interface-index> <fabric-child-interface-name>ge-19/0/15</fabric-child-interface-name> <fabric-child-interface-status>Up</fabric-child-interface-status> <fabric-interface-index>1</fabric-interface-index> </fabric-information> </dataplane-interfaces> <reth> <reth-name>reth0</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth1</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>Not configured</redundancy-group-id-for-reth> <reth-name>reth2</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth3</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>Not configured</redundancy-group-id-for-reth> <reth-name>reth4</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth5</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth6</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth7</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth8</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth9</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth10</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth11</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth12</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>Not configured</redundancy-group-id-for-reth> <reth-name>reth13</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth14</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth15</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth16</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> </reth> <interface-monitoring> </interface-monitoring> </chassis-cluster-interface-statistics> <cli> <banner>{secondary:node0}</banner> </cli> </rpc-reply> user@host>show chassis cluster interfacesControl link status: Up Control interfaces: Index Interface Status 0 em0 Up 1 em1 Down Fabric link status: Up Fabric interfaces: Name Child-interface Status fab0 ge-6/0/15 Up fab0 fab1 ge-19/0/15 Up fab1 Redundant-ethernet Information: Name Status Redundancy-group reth0 Down 1 reth1 Down Not configured reth2 Down 1 reth3 Down Not configured reth4 Down 1 reth5 Down 1 reth6 Down 1 reth7 Down 1 reth8 Down 1 reth9 Down 1 reth10 Up 1 reth11 Down 1 reth12 Down Not configured reth13 Up 1 reth14 Up 1 reth15 Up 1 reth16 Up 1 {secondary:node0}Utilisez l’appel de procédure distante (RPC) pour afficher les détails de l’interface
get-interface-informationreth et identifier les interfaces reth sur le périphérique. Ce RPC indique également quelles interfaces Gigabit Ethernet ou Fast Ethernet appartiennent à quelle interface reth comme indiqué dans l’exemple de sortie suivant :RPC XML pour les informations d’interface
<rpc> <get-interface-information> <terse/> <interface-name>reth0</interface-name> </get-interface-information> </rpc><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <interface-information xmlns="http://xml.juniper.net/junos/10.4I0/junos-interface" junos:style="terse"> <physical-interface> <name> reth0 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <logical-interface> <name> reth0.0 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <filter-information> </filter-information> <address-family> <address-family-name> inet </address-family-name> <interface-address> <ifa-local junos:emit="emit"> 192.168.29.2/24 </ifa-local> </interface-address> </address-family> <address-family> <address-family-name> multiservice </address-family-name> </address-family> </logical-interface> </physical-interface> </interface-information> Now, the interface that belongs to this. Extracting only the relevant information <rpc> <get-interface-information> <terse/> </get-interface-information> </rpc><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <interface-information xmlns="http://xml.juniper.net/junos/10.4I0/junos-interface" junos:style="terse"> <physical-interface> <name> ge-5/1/1 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <logical-interface> <name> ge-5/1/1.0 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <filter-information> </filter-information> <address-family> <address-family-name> aenet </address-family-name> <ae-bundle-name> reth0.0 </ae-bundle-name> </address-family> </logical-interface> </physical-interface> </interface-information>
Dans l’exemple de sortie, la
ae-bundle-namebalise identifie l’interface reth à laquelle elle appartient.
Utilisation de SNMP
La table ifTable MIB indique toutes les interfaces reth.
Utilisez la table ifStackStatus MIB pour mapper l’interface reth aux interfaces sous-jacentes sur les nœuds principal et secondaire. L’interface reth est la couche supérieure, et les interfaces individuelles des deux nœuds apparaissent en tant qu’index de couche inférieure.
Exemple de données SNMP pour les détails de l’interface Reth
Dans l’échantillon suivant, ge-5/1/1 et ge-11/1/1 appartiennent à reth0 :
{primary:node0} user@host>show interfaces terse | grep reth0ge-5/1/1.0 up up aenet --> reth0.0 ge-11/1/1.0 up up aenet --> reth0.0 reth0 up up reth0.0 up up inet 192.168.29.2/24Recherchez l’index de toutes les interfaces à partir de ifTable. Les informations suivantes montrent les index des interfaces requises dans cet exemple :
{primary:node0} user@host>show snmp mib walk ifDescr | grep reth0ifDescr.503 = reth0.0 ifDescr.528 = reth0Maintenant, recherchez l’index pour reth0 dans la table ifStackStatus. Dans l’exemple de sortie suivant, l’index reth0 503 est l’index de couche supérieure et les index 522 et 552 sont les index de couche inférieure. Les indices 522 et 552 représentent les interfaces ge-5/1/1.0 et ge-11/1/1.0, respectivement.
{primary:node0} user@host>show snmp mib walk ifStackStatus | grep 503ifStackStatus.0.503 = 1 ifStackStatus.503.522 = 1 ifStackStatus.503.552 = 1 {primary:node0} user@host>show snmp mib walk ifDescr | grep 522ifDescr.522 = ge-5/1/1.0 {primary:node0} user@host>show snmp mib walk ifDescr | grep 552ifDescr.552 = ge-11/1/1.0
Utilisation du plan de contrôle
Le logiciel du plan de contrôle, qui fonctionne en mode actif/sauvegarde, fait partie intégrante de Junos OS et est actif sur le nœud principal d’un cluster. Il assure la redondance en communiquant l’état, la configuration et d’autres informations au moteur de routage inactif sur le nœud secondaire. Si le moteur de routage principal tombe en panne, le moteur secondaire est prêt à prendre le contrôle. Les méthodes suivantes peuvent être utilisées pour découvrir les informations du port de contrôle.
Utilisation du protocole de gestion XML Junos OS ou du protocole de gestion XML NETCONF
Utilisez l’appel de procédure distante (RPC) pour obtenir la configuration du port de contrôle, comme illustré dans l’exemple get-configuration de sortie suivant.
XML RPC pour la configuration de groupes redondants
<rpc> <get-configuration inherit="inherit" database="committed"> <configuration> <chassis> <cluster> </cluster> </chassis> </configuration> </get-configuration> </rpc>
Utilisation du plan de données
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. 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. 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. 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). Les méthodes suivantes peuvent être utilisées pour déterminer les interfaces de plan de données.
- Utilisation du protocole de gestion XML Junos OS ou du protocole de gestion XML NETCONF
- Utilisation de SNMP
Utilisation du protocole de gestion XML Junos OS ou du protocole de gestion XML NETCONF
Utilisez l’appel de procédure distante (RPC) pour obtenir les interfaces de plan de données, comme illustré dans l’exemple get-chassis-cluster-data-plane-interfaces de sortie suivant.
Détails de l’interface XML RPC pour le plan de données du cluster
<rpc> <get-chassis-cluster-data-plane-interfaces> </get-chassis-cluster-data-plane-interfaces> </rpc><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <chassis-cluster-dataplane-interfaces> <fabric-interface-index>0</fabric-interface-index> <fabric-information> <child-interface-name>xe-5/0/0</child-interface-name> <child-interface-status>up</child-interface-status> </fabric-information> <fabric-interface-index>1</fabric-interface-index> <fabric-information> <child-interface-name>xe-11/0/0</child-interface-name> <child-interface-status>up</child-interface-status> </fabric-information> </chassis-cluster-dataplane-interfaces>
Utilisation de SNMP
La table ifTable MIB signale les interfaces fabric (fab) et les interfaces de liaison. Toutefois, la relation entre les interfaces sous-jacentes et les interfaces de fabric ne peut pas être déterminée à l’aide de SNMP.
Provisionnement des nœuds de cluster de châssis
Utilisez le protocole de gestion XML NETCONF pour la configuration et le provisionnement des équipements SRX Series et Junos OS en général. Nous vous recommandons d’utiliser des groupes pour configurer les clusters de châssis SRX Series. Utilisez des groupes globaux pour toutes les configurations communes entre les nœuds.
Les scripts de validation Junos OS peuvent être utilisés pour personnaliser la configuration comme vous le souhaitez.
Les scripts de validation Junos OS sont les suivants :
S’exécuter au moment de la validation
Inspecter la configuration entrante
Effectuez des actions telles que :
Échec du commit (légitime défense)
Modification de la configuration (autocorrection)
Les scripts de commit peuvent :
Générer des messages d’erreur/d’avertissement/syslog personnalisés
Apporter des modifications ou des corrections à la configuration
Les scripts de validation vous permettent de mieux contrôler la façon dont vos appareils sont configurés pour appliquer :
Vos règles de conception
Détails de votre implémentation
100 % de vos normes de conception