Dépannage des problèmes de gestion des clusters de châssis
Impossible de gérer un cluster de châssis SRX Series à l’aide du port de gestion ou des ports commerciaux
Problème
Description
Impossible de gérer le cluster du châssis SRX Series à l’aide du port de gestion ou des ports commerciaux.
Environnement
Cluster de châssis SRX Series
Diagnostic
Quel nœud du cluster de châssis utilisez-vous pour gérer le cluster ?
Nœud principal : passez à :
Gérez le cluster de châssis à l’aide de J-Web.
Note:Vous pouvez utiliser J-Web pour gérer uniquement le nœud principal.
Gérez le cluster de châssis à l’aide du port de gestion Revenue Port ou fxp0.
Note:Vous pouvez utiliser le port de gestion de revenus ou le port de gestion fxp0 pour gérer le nœud principal.
Nœud secondaire : procédez à la gestion du cluster de châssis à l’aide du port de gestion fxp0
Note:Vous ne pouvez gérer le nœud secondaire qu’à l’aide du port de gestion fxp0.
Résolution
- Gérer le cluster de châssis à l’aide de J-Web
- Gérer le cluster de châssis à l’aide du port de gestion Revenue Port ou fxp0
- Gérer le cluster de châssis à l’aide du port de gestion fxp0
- Quelle est la prochaine étape ?
- Gérer le cluster de châssis à l’aide de J-Web
- Gérer le cluster de châssis à l’aide du port de gestion Revenue Port ou fxp0
- Gérer le cluster de châssis à l’aide du port de gestion fxp0
- Quelle est la prochaine étape ?
Gérer le cluster de châssis à l’aide de J-Web
Vous pouvez utiliser J-Web pour gérer uniquement le nœud principal.
-
Connectez une console au nœud principal.
-
À l’aide de l’interface de ligne de commande, exécutez la
show system services web-managementcommande. -
Vérifiez si l’interface de bouclage (lo0) est configurée dans le cadre de la configuration HTTP/HTTPS de gestion Web. Reportez-vous à la section gestion Web (services système) .
-
Si l’interface de bouclage (lo0) est configurée sous la configuration HTTP/HTTPS de gestion Web, supprimez l’interface de bouclage en exécutant la
delete system services web-management http interface lo.0commande. -
Validez la modification et vérifiez si vous pouvez maintenant gérer le cluster de châssis.
-
Si vous ne parvenez toujours pas à gérer le cluster de châssis, passez à la section Gérer le cluster de châssis à l’aide du port de gestion Revenue Port ou fxp0.
Gérer le cluster de châssis à l’aide du port de gestion Revenue Port ou fxp0
Vous pouvez utiliser à la fois le port de gestion de revenus ou le port de gestion fxp0 pour gérer le nœud principal.
-
Connectez-vous à une console à l’aide du port de revenus du nœud principal que vous souhaitez utiliser comme interface de gestion.
-
Vérifiez la configuration de l’interface de gestion :
-
Vérifiez que les services système requis (SSH, Telnet, HTTP) sont activés au niveau hiérarchique host-inbound-traffic dans la zone concernée :
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } } -
Vérifiez que les services système requis (SSH, Telnet, HTTP) sont activés au niveau de la system services hiérarchie :
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
-
-
Le ping vers l’interface de gestion fonctionne-t-il ?
-
Yes: Reportez-vous à la section Impossible de gérer un cluster de châssis SRX Series à l’aide de fxp0 lorsque la destination dans le routeur de sauvegarde est 0/0. Si cette solution ne fonctionne pas, passez à la section Suivant pour ouvrir un dossier auprès du support technique Juniper Networks.
-
No: Passez à l’étape 4.
-
-
À l’aide de l’interface de ligne de commande, exécutez la
show interfaces tersecommande :Dans la sortie, l’état est Actif
FXP0 interfaceet fournit-il une adresse IP ?-
Yes: Passez à l’étape 5.
-
No: Vérifiez les points suivants :
-
À l’aide de l’interface de ligne de commande, vérifiez que l’interface fxp0 est correctement configurée : show groups.
Exemple de sortie :
root@srx# show groups node0 { system { host-name SRX3400-1; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.1/24; } } } } } node1 { system { host-name SRX3400-2; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.2/24; } } } } } } apply-groups "${NODE}"; system { services { ftp; ssh; telnet; } } -
Vérifiez l’état du câble connecté à l’interface fxp0 . Le câble est-il en bon état ?
-
Yes: Passez à l’étape suivante.
-
No: Remplacez le câble et essayez de gérer le cluster du châssis. Si vous ne parvenez toujours pas à gérer le cluster de châssis, passez à l’étape suivante.
-
-
À l’aide de l’interface de ligne de commande, vérifiez l’incrémentation des compteurs d’erreurs : show interfaces fxp0.0 extensive.
-
Yes: Si vous trouvez des erreurs dans la sortie, passez à la section Suivant pour ouvrir un dossier auprès du support technique Juniper Networks.
-
No: S’il n’y a pas d’erreurs dans la sortie et si vous ne parvenez toujours pas à gérer le cluster de châssis, passez à l’étape 5.
-
-
-
-
Vérifiez si l’adresse IP de l’interface fxp0 et l’adresse IP de l’équipement de gestion se trouvent dans le même sous-réseau.
-
Yes: Passez à l’étape 6.
-
No:À l’aide de l’interface de ligne de commande, vérifiez s’il existe un itinéraire pour l’adresse IP de l’équipement de gestion : show route <management device IP>
-
S’il n’existe pas de route pour l’adresse IP de l’équipement de gestion, ajoutez une route pour le sous-réseau de gestion dans la inet.0 table avec le saut suivant comme adresse IP du routeur de secours.
-
-
-
À l’aide de l’interface de ligne de commande, vérifiez s’il existe une entrée ARP pour l’équipement de gestion sur la passerelle de services : show arp no-resolve | match <ip>.
-
Yes: Vérifiez si le cluster de châssis dispose de plusieurs routes vers le périphérique de gestion : show route <device-ip>.
-
Yes: Il peut y avoir des chemins vers le périphérique de gestion via l’interface fxp0 et une autre interface conduisant à un routage asymétrique. Passez à la section Suivant pour ouvrir un dossier auprès du support technique Juniper Networks.
-
No: Procédez à la gestion du cluster de châssis à l’aide du port de gestion fxp0.
-
-
No: Passez à la section Suivant pour ouvrir un dossier auprès du support technique Juniper Networks.
-
Gérer le cluster de châssis à l’aide du port de gestion fxp0
Vous ne pouvez utiliser que le port de gestion fxp0 pour gérer le nœud secondaire.
-
Vérifiez la configuration de l’interface de gestion sur le noeud secondaire :
-
Vérifiez que les services système requis (SSH, Telnet, HTTP) sont activés au niveau de la host-inbound-traffic hiérarchie :
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } } -
Vérifiez que les services système requis (SSH, Telnet, HTTP) sont activés au niveau de la system services hiérarchie :
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
Reportez-vous à la section Impossible de gérer un cluster de châssis SRX Series à l’aide de fxp0 lorsque la destination dans le routeur de secours est 0/0 et configuration de la commande backup-routerConfiguration de la commande backup-router sur le cluster Chassis pour plus d’informations sur les instructions de configuration.
Si la configuration est correcte et que vous ne parvenez toujours pas à gérer le cluster de châssis, passez à l’étape 2.
-
-
Les adresses IP des interfaces fxp0 du noeud primaire et du noeud secondaire se trouvent-elles dans le même sous-réseau ?
-
Yes:Passez à la suite.
-
No: Configurez les interfaces fxp0 du nœud principal et du nœud secondaire dans le même sous-réseau. Passez à l’étape 1 et vérifiez la configuration.
-
Quelle est la prochaine étape ?
-
Si le problème persiste, reportez-vous à l’article KB20795 de la base de connaissances.
-
Si vous souhaitez poursuivre le débogage, reportez-vous à l’article KB21164 de la base de connaissances pour consulter les journaux de débogage.
-
Pour ouvrir un dossier JTAC auprès de l’équipe d’assistance de Juniper Networks, reportez-vous à la section Collecte de données pour l’assistance clientèle afin de connaître les données que vous devez collecter pour faciliter le dépannage avant d’ouvrir un dossier JTAC.
Gérer le cluster de châssis à l’aide de J-Web
Vous pouvez utiliser J-Web pour gérer uniquement le nœud principal.
Connectez une console au nœud principal.
À l’aide de l’interface de ligne de commande, exécutez la
show system services web-managementcommande.Vérifiez si l’interface de bouclage (lo0) est configurée dans le cadre de la configuration HTTP/HTTPS de gestion Web. Reportez-vous à la section gestion Web (services système) .
Si l’interface de bouclage (lo0) est configurée sous la configuration HTTP/HTTPS de gestion Web, supprimez l’interface de bouclage en exécutant la
delete system services web-management http interface lo.0commande.Validez la modification et vérifiez si vous pouvez maintenant gérer le cluster de châssis.
Si vous ne parvenez toujours pas à gérer le cluster de châssis, passez à la section Gérer le cluster de châssis à l’aide du port de gestion Revenue Port ou fxp0.
Gérer le cluster de châssis à l’aide du port de gestion Revenue Port ou fxp0
Vous pouvez utiliser à la fois le port de gestion de revenus ou le port de gestion fxp0 pour gérer le nœud principal.
Connectez-vous à une console à l’aide du port de revenus du nœud principal que vous souhaitez utiliser comme interface de gestion.
Vérifiez la configuration de l’interface de gestion :
Vérifiez que les services système requis (SSH, Telnet, HTTP) sont activés au niveau hiérarchique host-inbound-traffic dans la zone concernée :
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } }Vérifiez que les services système requis (SSH, Telnet, HTTP) sont activés au niveau de la system services hiérarchie :
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
Le ping vers l’interface de gestion fonctionne-t-il ?
Yes:Reportez-vous à la section Impossible de gérer un cluster de châssis SRX Series à l’aide de fxp0 lorsque la destination dans le routeur de sauvegarde est 0/0. Si cette solution ne fonctionne pas, passez à la section Suivant pour ouvrir un dossier auprès du support technique Juniper Networks.
No: Passez à l’étape 4.
À l’aide de l’interface de ligne de commande, exécutez la
show interfaces tersecommande :Dans la sortie, l’état est Actif
FXP0 interfaceet fournit-il une adresse IP ?Yes: Passez à l’étape 5.
No: Vérifiez les points suivants :
À l’aide de l’interface de ligne de commande, vérifiez que l’interface fxp0 est correctement configurée : show groups.
Exemple de sortie :
root@srx# show groups node0 { system { host-name SRX3400-1; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.1/24; } } } } } node1 { system { host-name SRX3400-2; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.2/24; } } } } } } apply-groups "${NODE}"; system { services { ftp; ssh; telnet; } }Vérifiez l’état du câble connecté à l’interface fxp0 . Le câble est-il en bon état ?
Yes: Passez à l’étape suivante.
No: Remplacez le câble et essayez de gérer le cluster du châssis. Si vous ne parvenez toujours pas à gérer le cluster de châssis, passez à l’étape suivante.
À l’aide de l’interface de ligne de commande, vérifiez l’incrémentation des compteurs d’erreurs : show interfaces fxp0.0 extensive.
Yes: Si vous trouvez des erreurs dans la sortie, passez à la section Suivant pour ouvrir un dossier auprès du support technique Juniper Networks.
No: S’il n’y a pas d’erreurs dans la sortie et si vous ne parvenez toujours pas à gérer le cluster de châssis, passez à l’étape 5.
Vérifiez si l’adresse IP de l’interface fxp0 et l’adresse IP de l’équipement de gestion se trouvent dans le même sous-réseau.
Yes: Passez à l’étape 6.
No:À l’aide de l’interface de ligne de commande, vérifiez s’il existe un itinéraire pour l’adresse IP de l’équipement de gestion : show route <management device IP>
S’il n’existe pas de route pour l’adresse IP de l’équipement de gestion, ajoutez une route pour le sous-réseau de gestion dans la inet.0 table avec le saut suivant comme adresse IP du routeur de secours.
À l’aide de l’interface de ligne de commande, vérifiez s’il existe une entrée ARP pour l’équipement de gestion sur la passerelle de services : show arp no-resolve | match <ip>.
Yes: Vérifiez si le cluster de châssis dispose de plusieurs routes vers le périphérique de gestion : show route <device-ip>.
Yes: Il peut y avoir des chemins vers le périphérique de gestion via l’interface fxp0 et une autre interface conduisant à un routage asymétrique. Passez à la section Suivant pour ouvrir un dossier auprès du support technique Juniper Networks.
No: Procédez à la gestion du cluster de châssis à l’aide du port de gestion fxp0.
No: Passez à la section Suivant pour ouvrir un dossier auprès du support technique Juniper Networks.
Gérer le cluster de châssis à l’aide du port de gestion fxp0
Vous ne pouvez utiliser que le port de gestion fxp0 pour gérer le nœud secondaire.
Vérifiez la configuration de l’interface de gestion sur le noeud secondaire :
Vérifiez que les services système requis (SSH, Telnet, HTTP) sont activés au niveau de la host-inbound-traffic hiérarchie :
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } }Vérifiez que les services système requis (SSH, Telnet, HTTP) sont activés au niveau de la system services hiérarchie :
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
Pour plus d’informations sur les instructions de configuration, reportez-vous aux sections Impossible de gérer un cluster de châssis SRX Series à l’aide de fxp0 lorsque la destination dans le routeur de sauvegarde est 0/0 et Configuration de la commande backup-router sur le cluster de châssis .
Si la configuration est correcte et que vous ne parvenez toujours pas à gérer le cluster de châssis, passez à l’étape 2.
Les adresses IP des interfaces fxp0 du noeud primaire et du noeud secondaire se trouvent-elles dans le même sous-réseau ?
Yes:Passez à la suite.
No: Configurez les interfaces fxp0 du nœud principal et du nœud secondaire dans le même sous-réseau. Passez à l’étape 1 et vérifiez la configuration.
Quelle est la prochaine étape ?
Si le problème persiste, reportez-vous à l’article KB20795 de la base de connaissances.
Si vous souhaitez poursuivre le débogage, reportez-vous à l’article KB21164 de la base de connaissances pour consulter les journaux de débogage.
Pour ouvrir un dossier JTAC auprès de l’équipe d’assistance de Juniper Networks, reportez-vous à la section Collecte de données pour l’assistance clientèle afin de connaître les données que vous devez collecter pour faciliter le dépannage avant d’ouvrir un dossier JTAC.
Impossible de gérer le noeud secondaire d’un cluster de châssis à l’aide de J-Web
Problème
Description
Impossible de gérer le noeud secondaire d’un cluster de châssis à l’aide de l’interface J-Web.
Environnement
Cluster de châssis SRX Series
Symptômes
Lorsque vous êtes en mode cluster de châssis JSRP (Junos Services Redundancy Protocol), vous ne pouvez pas gérer le groupe de redondance 0 (RG0) sur le nœud secondaire à l’aide de l’interface J-Web.
Cause
Vous pouvez utiliser l’interface J-Web pour gérer le groupe de redondance 0 uniquement sur le nœud principal.
Les processus référencés par J-Web ne sont pas en cours d’exécution sur le noeud secondaire.
Exemple
L’exemple suivant montre la sortie de syslog et du processus système sur le noeud0 et le noeud1 après le basculement de RG0 du noeud1 au noeud0.
Sur le noeud 1, le processus de gestion Web (httpd-gk) a été arrêté (quitté).
Sur node0, le processus de gestion web (httpd-gk) a été démarré.
Deux processus liés à http (httpd-gk et httpd) s’exécutent uniquement sur node0, qui est le nouveau noeud principal de RG0.
{secondary:node1}
root@SRX210HE-B> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 1
node0 255 primary no yes
node1 1 secondary no yes
Redundancy group: 1 , Failover count: 1
node0 100 primary yes no
node1 1 secondary yes no
{secondary:node1}
root@SRX210HE-B> show log log-any | grep web-management
Jul 5 11:31:52 SRX210HE-B init: web-management (PID 9660) started
Jul 5 12:00:37 SRX210HE-B init: web-management (PID 9660) SIGTERM sent
Jul 5 12:00:37 SRX210HE-B init: web-management (PID 9660) exited with status=0 Normal Exit
{primary:node0}
root@SRX210HE-A> show log log-any | grep web-management
Jul 5 12:00:37 SRX210HE-A init: web-management (PID 9498) started
{primary:node0}
root@SRX210HE-A> show system processes extensive node 0 | grep http
9498 root 1 76 0 12916K 4604K select 0 0:00 0.00% httpd-gk
9535 nobody 1 90 0 8860K 3264K select 0 0:00 0.00% httpd
{primary:node0}
root@SRX210HE-A> show system processes extensive node 1 | grep http
=> No httpd-gk and httpd processes running on node 1 (secondary node)
Cela limite les appels de procédure distante (RPC) à partir de la logique J-Web, et par la suite, les pages qui peuvent être émises à partir du nœud secondaire.
Solution
Vous pouvez gérer le nœud secondaire d’un cluster de châssis à l’aide de la CLI (SSH, telnet et console). Reportez-vous à la section Gérer le cluster de châssis à l’aide du port de gestion fxp0
Impossible de gérer un cluster de châssis SRX Series à l’aide de fxp0 lorsque la destination dans le routeur de secours est 0/0
Cette rubrique explique, à l’aide d’un exemple, comment gérer un cluster de châssis SRX Series configuré à l’aide de la configuration du routeur de secours via l’interface fxp0.
Problème
Description
L’équipement de gestion ne peut pas gérer le cluster de châssis via une interface fxp0, mais il peut envoyer une requête ping aux deux interfaces fxp0.
Exemple de topologie
La topologie, les adresses IP et la configuration sont les suivantes :
Fxp0 primaire : 192.168.1.1/24
Fxp0 secondaire : 192.168.1.2/24
Passerelle pour fxp0 : 192.168.1.254
Équipement de gestion : 172.16.1.1/24
groups {
node0 {
system {
host-name SRX5400-1;
backup-router 192.168.1.254 destination 0.0.0.0/0;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
}
}
node1 {
system {
host-name SRX5400-2;
backup-router 192.168.1.254 destination 0.0.0.0/0;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.1.2/24;
}
}
}
}
}
}
apply-groups "${NODE}";
system {
services {
ftp;
ssh;
telnet;
}
}
Environnement
Cluster de châssis SRX Series
Cause
Il existe un itinéraire pour 172.16.1.1 via les interfaces autres que l’interface fxp0 sur les périphériques du cluster. Nous vous déconseillons d’utiliser 0.0.0.0/0 comme destination du routeur de secours. Ping fonctionne car la réponse d’écho pour une requête d’écho entrante à l’interface fxp0 est envoyée en suivant l’itinéraire de 172.16.1.1 via des interfaces autres que fxp0, mais Telnet échoue.
Solution
Supprimez la route pour 172.16.1.1 dans la table de routage et définissez une destination de routeur de secours plus spécifique dans le groupe node0/node1.
Par exemple:
groups {
node0 {
...
backup-router 192.168.1.254 destination 172.16.1.1/32;
...
}
node1 {
...
backup-router 192.168.1.254 destination 172.16.1.1/32;
...
}
Aucune modification n’est affichée dans la table de routage après l’application de la configuration, car la configuration du routeur de secours est destinée à faciliter l’accès à la gestion sur le nœud de sauvegarde uniquement. L’accès au noeud principal est activé via le routage sur le noeud principal.Ainsi, lorsque la configuration du routeur de secours est terminée, vous pouvez voir qu’une route est injectée dans la table de transfert sur le nœud secondaire. Vous ne pouvez pas voir la table de routage sur le noeud secondaire, car le sous-système de routage ne s’exécute pas sur le noeud secondaire.
Exemple de sortie lorsque le routeur de secours est configuré avec la destination 0/0
Table de routage sur le noeud principal :
{primary:node0}[edit] root@SRX5400-1# run show route inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24 *[Direct/0] 00:00:54 > via fxp0.0 192.168.1.1/32 *[Local/0] 00:00:54 Local via fxp0.0Table de transfert sur noeud secondaire avec destination 0/0 :
root@SRX3400-2# run show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default user 0 28:c0:da:a0:88:0 ucst 345 2 fxp0.0 default perm 0 rjct 36 1 0.0.0.0/32 perm 0 dscd 34 1 192.168.1.0/24 intf 0 rslv 344 1 fxp0.0 192.168.1.0/32 dest 0 192.168.1.0 recv 342 1 fxp0.0 192.168.1.2/32 intf 0 192.168.1.2 locl 343 2 192.168.1.2/32 dest 0 192.168.1.2 locl 343 2 192.168.1.254/32 dest 0 28:c0:da:a0:88:0 ucst 345 2 fxp0.0 192.168.1.255/32 dest 0 192.168.1.255 bcst 336 1 fxp0.0 224.0.0.0/4 perm 0 mdsc 35 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 31 1 255.255.255.255/32 perm 0 bcst 32 1 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 526 1 0.0.0.0/32 perm 0 dscd 524 1 224.0.0.0/4 perm 0 mdsc 525 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 521 1 255.255.255.255/32 perm 0 bcst 522 1
Exemple de sortie lorsque le routeur de secours est configuré avec la destination 172.16.1.1/32
Table de routage sur le noeud principal :
{primary:node0}[edit] root@SRX5400-1# run show route inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24 *[Direct/0] 00:17:51 > via fxp0.0 192.168.1.1/32 *[Local/0] 00:55:50 Local via fxp0.0Table de transfert sur le noeud principal :
Note:Sur le nœud principal, la route 172.16.1.1/32 du routeur de secours n’est pas affichée dans l’exemple de sortie.
{primary:node0}[edit] root@SRX5400-1# run show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 1 0.0.0.0/32 perm 0 dscd 34 1 192.168.1.0/24 intf 0 rslv 334 1 fxp0.0 192.168.1.0/32 dest 0 192.168.1.0 recv 331 1 fxp0.0 192.168.1.1/32 intf 0 192.168.1.1 locl 332 2 192.168.1.1/32 dest 0 192.168.1.1 locl 332 2 192.168.1.3/32 dest 0 5c:5e:ab:16:e3:81 ucst 339 1 fxp0.0 192.168.1.6/32 dest 0 0:26:88:4f:c8:8 ucst 340 1 fxp0.0 192.168.1.11/32 dest 0 0:30:48:bc:9f:45 ucst 342 1 fxp0.0 192.168.1.254/32 dest 0 28:c0:da:a0:88:0 ucst 343 1 fxp0.0 192.168.1.255/32 dest 0 192.168.1.255 bcst 329 1 fxp0.0 224.0.0.0/4 perm 0 mdsc 35 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 31 1 255.255.255.255/32 perm 0 bcst 32 1 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 526 1 0.0.0.0/32 perm 0 dscd 524 1 224.0.0.0/4 perm 0 mdsc 525 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 521 1 255.255.255.255/32 perm 0 bcst 522 1Table de transfert sur le noeud secondaire :
Note:Sur le nœud secondaire, la route 172.16.1.1/32 du routeur de secours est affichée dans l’exemple de sortie. Cela facilite l’accès au nœud secondaire via l’interface fxp0.
{secondary:node1}[edit] root@SRX5400-2# run show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 1 0.0.0.0/32 perm 0 dscd 34 1 172.16.1.1/32 user 0 192.168.1.254 ucst 345 2 fxp0.0 192.168.1.0/24 intf 0 rslv 344 1 fxp0.0 192.168.1.0/32 dest 0 192.168.1.0 recv 342 1 fxp0.0 192.168.1.2/32 intf 0 192.168.1.2 locl 343 2 192.168.1.2/32 dest 0 192.168.1.2 locl 343 2 192.168.1.254/32 dest 0 28:c0:da:a0:88:0 ucst 345 2 fxp0.0 192.168.1.255/32 dest 0 192.168.1.255 bcst 336 1 fxp0.0 224.0.0.0/4 perm 0 mdsc 35 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 31 1 255.255.255.255/32 perm 0 bcst 32 1 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 526 1 0.0.0.0/32 perm 0 dscd 524 1 224.0.0.0/4 perm 0 mdsc 525 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 521 1 255.255.255.255/32 perm 0 bcst 522 1
Si un sous-réseau particulier a une route configurée via le routeur de secours et une route statique sous routing-options, il peut y avoir des problèmes d’accès à l’interface fxp0. Dans l’exemple ci-dessus, le problème d’accès à l’interface fxp0 à partir du périphérique de gestion se produit lorsque :
La même route existe en tant que route statique et via le routeur de secours.
Il existe une route statique qui est plus spécifique que la route via le routeur de secours.
Dans les exemples, lorsque les routes du nœud principal sont synchronisées avec la table de transfert du nœud secondaire, la route configurée sous route statique est prioritaire sur la route sous routeur de secours. Si 0/0 est configuré sous backup-router, les chances d’une meilleure correspondance de route sous route statique sont plus élevées. Par conséquent, nous vous recommandons d’éviter 0/0 sous le routeur de secours.
Si vous souhaitez configurer des routes vers la même destination à l’aide du routeur de secours ainsi que de la route statique, divisez les routes lors de la configuration sous backup-router. Cela fait des routes configurées sous le routeur de secours les routes préférées et garantit que l’interface fxp0 est accessible.
[edit routing-options static route] 0.0.0.0/0 next-hop 100.200.200.254; [edit groups node0 ] backup-router 192.168.1.254 destination [0.0.0.0/1 128.0.0.0/1];
Impossible de mettre à niveau un cluster de châssis à l’aide d’une mise à niveau logicielle en service
Problème
Description
Impossible de mettre à niveau un cluster de châssis à l’aide de la méthode de mise à niveau avec temps d’arrêt minimal.
Environnement
SRX5400 cluster de châssis.
Symptômes
-
Le cluster est bloqué dans le noeud0 RG1 avec l’indicateur IF et ne peut pas être mis à jour.
-
L’erreur de validation de configuration s’affiche sur l’interface de ligne de commande.
Cause
La configuration a le même préfixe sur les destinations du routeur de secours (sur le RE/nœud de secours) et l’adresse de l’interface utilisateur.
regress@R1_re# show interfaces ge-0/0/0
unit 0 {
family inet {
address 192.1.1.1/24;
}
}
regress@R1_re# show groups re1 system backup-router
10.204.63.254 destination 192.1.1.1/18;
regress@R1_re# commit
re0: configuration check succeeds re1: error: Cannot have same prefix for backup-router destination and interface address. ge-0/0/0.0 inet 192.1.1 error: configuration check-out failed re0: error: remote commit-configuration failed on re1
Solution
En mode cluster de châssis, l'adresse de destination du routeur de secours pour les routeurs IPv4 et IPv6 à l'aide des commandes et edit system inet6-backup-router address destination destination-address ne doit pas être identique à l edit system backup-router address destination destination-address'adresse d'interface configurée pour IPv4 et IPv6 à l'aide des edit interfaces interface-name unit logical-unit-number family inet address ipv4-address commandes et edit interfaces interface-name unit logical-unit-number family inet6 address ipv6-address.Configuration de la commande backup-router sur le cluster Chassis
Comment sauvegarder un routeur dans un cluster de châssis SRX Series à l’aide de la backup-router commande configuration.
Problème
Description
Problèmes de connectivité intermittents vers NSM et d’autres hôtes de gestion à partir du nœud secondaire.
Environnement
Cluster de châssis SRX Series
Cause
La définition d’une destination de sur le routeur de sauvegarde (sans configuration) n’est 0.0.0.0/0 pas prise en charge.
Exemple de configuration incorrecte :
set groups node0 system backup-router 10.10.10.1 destination 0.0.0.0/0
Solution
Reportez-vous à la section Configuration d’un routeur de secours pour connaître la méthode recommandée pour configurer un routeur de secours à l’aide d’un préfixe différent de zéro.
Exemple de configuration d’un routeur de secours de sous-réseau différent de zéro :
set groups node0 system backup-router 10.10.10.1 destination 10.100.0.0/16
Comme alternative à la destination du routeur de secours 0/0, voici un autre exemple où 0/0 est divisé en deux préfixes :
set groups node0 system backup-router 10.10.10.1 destination 0.0.0.0/1 set groups node0 system backup-router 10.10.10.1 destination 128.0.0.0/1
Si plusieurs réseaux doivent être accessibles via le routeur de secours, vous pouvez ajouter plusieurs entrées de destination à la configuration. La configuration du routeur de secours n’est utilisée que par le nœud secondaire RG0. Le noeud principal continue d’utiliser la table de routage inet.0.
Impossible de mettre à niveau un cluster de châssis à l’aide d’une mise à niveau logicielle en service
Problème
Description
Impossible de mettre à niveau un cluster de châssis à l’aide de la méthode de mise à niveau avec temps d’arrêt minimal.
Environnement
SRX5400 cluster de châssis.
Symptômes
-
Le cluster est bloqué dans le noeud0 RG1 avec l’indicateur IF et ne peut pas être mis à jour.
-
L’erreur de validation de configuration s’affiche sur l’interface de ligne de commande.
Cause
La configuration a le même préfixe sur les destinations du routeur de secours (sur le RE/nœud de secours) et l’adresse de l’interface utilisateur.
regress@R1_re# show interfaces ge-0/0/0
unit 0 {
family inet {
address 192.1.1.1/24;
}
}
regress@R1_re# show groups re1 system backup-router
10.204.63.254 destination 192.1.1.1/18;
regress@R1_re# commit
re0: configuration check succeeds re1: error: Cannot have same prefix for backup-router destination and interface address. ge-0/0/0.0 inet 192.1.1 error: configuration check-out failed re0: error: remote commit-configuration failed on re1