Résolution 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 de revenus
Problème
Description
Impossible de gérer le cluster de châssis SRX Series à l’aide du port de gestion ou des ports de revenus.
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 du port de gestion fxp0.
Note:Vous pouvez utiliser le port de revenus ou le port de gestion fxp0 pour gérer le nœud principal.
Nœud secondaire : passez à la gestion du cluster de châssis à l’aide du port de gestion fxp0
Note:Vous pouvez gérer le nœud secondaire uniquement à 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 revenu ou du port de gestion 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 revenu ou du port de gestion 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 sous la configuration HTTP/HTTPS de gestion Web. Voir 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 pouvez toujours pas gérer le cluster de châssis, passez à Gérer le cluster de châssis à l’aide du port de revenu ou du port de gestion fxp0.
Gérer le cluster de châssis à l’aide du port de revenu ou du port de gestion fxp0
Vous pouvez utiliser le port 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: Voir 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 Prochaines étapes pour ouvrir un dossier auprès du support technique de 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, est-ce que l’état est Up
FXP0 interface, et fournit-il une adresse IP ?-
Yes: Passez à l’étape 5.
-
No: Vérifiez les points suivants :
-
A 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: Replacez le câble et essayez de gérer le cluster de 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 les compteurs d’erreur incrémentés : show interfaces fxp0.0 extensive.
-
Yes: Si vous trouvez des erreurs dans la sortie, passez à la section Prochaines étapes pour ouvrir un dossier auprès de l’assistance technique de Juniper Networks.
-
No: S’il n’y a aucune erreur dans la sortie et si vous ne pouvez toujours pas gérer le cluster de châssis, passez à l’étape 5.
-
-
-
-
Vérifiez si l’adresse IP de l’interface et l’adresse fxp0 IP du périphérique 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 du périphérique de gestion : show route <management device IP>
-
S’il n’existe pas de route pour l’adresse IP du périphérique de gestion, ajoutez une route pour le sous-réseau de gestion dans le tableau avec le inet.0 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 le périphérique 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 matériel de gestion : show route <device-ip>.
-
Yes: Il peut y avoir des routes vers le périphérique de gestion via l’interface fxp0 et d’autres interfaces conduisant à un routage asymétrique. Passez à la section Prochaines étapes pour ouvrir un dossier auprès de l’assistance technique de Juniper Networks.
-
No: Passez à la gestion du cluster de châssis à l’aide du port de gestion fxp0.
-
-
No: Passez à la section Prochaines étapes pour ouvrir un dossier auprès de l’assistance technique de Juniper Networks.
-
Gérer le cluster de châssis à l’aide du port de gestion fxp0
Vous pouvez utiliser uniquement le port de gestion fxp0 pour gérer le nœud secondaire.
-
Vérifiez la configuration de l’interface de gestion sur le nœud 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; }
Consultez 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 pour plus d’informations sur les instructions de configuration.
Si la configuration est correcte et que vous ne pouvez toujours pas gérer le cluster de châssis, passez à l’étape 2.
-
-
Les adresses IP des interfaces fxp0 sont-elles du nœud principal et du nœud secondaire dans le même sous-réseau ?
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, consultez 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 Juniper Networks, consultez Collecte de données pour le support client afin d’obtenir 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 sous la configuration HTTP/HTTPS de gestion Web. Voir 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 pouvez toujours pas gérer le cluster de châssis, passez à Gérer le cluster de châssis à l’aide du port de revenu ou du port de gestion fxp0.
Gérer le cluster de châssis à l’aide du port de revenu ou du port de gestion fxp0
Vous pouvez utiliser le port 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: Voir 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 Prochaines étapes pour ouvrir un dossier auprès du support technique de 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, est-ce que l’état est Up
FXP0 interface, et fournit-il une adresse IP ?Yes: Passez à l’étape 5.
No: Vérifiez les points suivants :
A 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: Replacez le câble et essayez de gérer le cluster de 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 les compteurs d’erreur incrémentés : show interfaces fxp0.0 extensive.
Yes: Si vous trouvez des erreurs dans la sortie, passez à la section Prochaines étapes pour ouvrir un dossier auprès de l’assistance technique de Juniper Networks.
No: S’il n’y a aucune erreur dans la sortie et si vous ne pouvez toujours pas gérer le cluster de châssis, passez à l’étape 5.
Vérifiez si l’adresse IP de l’interface et l’adresse fxp0 IP du périphérique 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 du périphérique de gestion : show route <management device IP>
S’il n’existe pas de route pour l’adresse IP du périphérique de gestion, ajoutez une route pour le sous-réseau de gestion dans le tableau avec le inet.0 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 le périphérique 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 matériel de gestion : show route <device-ip>.
Yes: Il peut y avoir des routes vers le périphérique de gestion via l’interface fxp0 et d’autres interfaces conduisant à un routage asymétrique. Passez à la section Prochaines étapes pour ouvrir un dossier auprès de l’assistance technique de Juniper Networks.
No: Passez à la gestion du cluster de châssis à l’aide du port de gestion fxp0.
No: Passez à la section Prochaines étapes pour ouvrir un dossier auprès de l’assistance technique de Juniper Networks.
Gérer le cluster de châssis à l’aide du port de gestion fxp0
Vous pouvez utiliser uniquement le port de gestion fxp0 pour gérer le nœud secondaire.
Vérifiez la configuration de l’interface de gestion sur le nœud 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; }
Consultez 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 pour plus d’informations sur les instructions de configuration.
Si la configuration est correcte et que vous ne pouvez toujours pas gérer le cluster de châssis, passez à l’étape 2.
Les adresses IP des interfaces fxp0 sont-elles du nœud principal et du nœud secondaire dans le même sous-réseau ?
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, consultez 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 Juniper Networks, consultez Collecte de données pour le support client afin d’obtenir les données que vous devez collecter pour faciliter le dépannage avant d’ouvrir un dossier JTAC.
Impossible de gérer le nœud secondaire d’un cluster de châssis à l’aide de J-Web
Problème
Description
Impossible de gérer le nœud secondaire d’un cluster de châssis à l’aide de l’interface J-Web.
Environnement
Cluster de châssis SRX Series
Symptômes
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.
Causes
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 s’exécutent pas sur le nœud secondaire.
Exemple
L’exemple suivant montre la sortie de syslog et de processus système sur node0 et node1 après le basculement de RG0 de node1 à node0.
Sur le nœud1, le processus de gestion Web (httpd-gk) a été arrêté (quitté).
Sur le nœud0, le processus de gestion Web (httpd-gk) a été lancé.
Deux processus liés à http (httpd-gk et httpd), s’exécutent uniquement sur node0, qui est le nouveau nœud 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) 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 l’interface de ligne de commande (SSH, telnet et console). Voir 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 sauvegarde est 0/0
RÉSUMÉ Cette rubrique explique, à l’aide d’un exemple, comment gérer un cluster de châssis SRX Series configuré à l’aide de la configuration de routeur de sauvegarde via l’interface fxp0.
Problème
Description
Le périphérique de gestion ne peut pas gérer le cluster de châssis via une interface fxp0, mais il peut exécuter une commande ping sur les deux interfaces fxp0.
Exemple de topologie
La topologie, les adresses IP et la configuration sont les suivantes :
Fxp0 primaire : 192.168.1.1/24
Secondaire fxp0 : 192.168.1.2/24
Passerelle pour fxp0 : 192.168.1.254
Périphérique 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
Causes
Il existe un itinéraire pour 172.16.1.1 via les interfaces autres que l’interface fxp0 sur les périphériques de cluster. Nous vous déconseillons d’utiliser 0.0.0.0/0 comme destination du routeur de sauvegarde. Ping fonctionne car la réponse d’écho pour une demande d’écho entrante à l’interface fxp0 est envoyée en suivant le chemin pour 172.16.1.1 via des interfaces autres que fxp0, mais Telnet échoue.
Solution
Supprimez l’itinéraire pour 172.16.1.1 dans la table de routage et définissez une destination de routeur de sauvegarde 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 sauvegarde est destinée à faciliter l’accès de gestion sur le nœud de sauvegarde uniquement. L’accès au nœud principal est activé via le routage sur le nœud principal.Ainsi, lorsque la configuration du routeur de sauvegarde est terminée, vous pouvez voir qu’un itinéraire est injecté dans la table de transfert sur le nœud secondaire. Vous ne pouvez pas voir la table de routage sur le nœud secondaire, car le sous-système de routage ne s’exécute pas sur le nœud secondaire.
Exemple de sortie lorsque le routeur de sauvegarde est configuré avec la destination 0/0
Table de routage sur le nœud 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 le nœud 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 sauvegarde est configuré avec la destination 172.16.1.1/32
Table de routage sur le nœud 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 nœud principal :
Note:Sur le nœud principal, le routage 172.16.1.1/32 du routeur de sauvegarde n’est pas affiché 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 nœud secondaire :
Note:Sur le nœud secondaire, la route 172.16.1.1/32 du routeur de sauvegarde 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 un itinéraire configuré via le routeur de sauvegarde et un itinéraire statique sous options de routage, il peut y avoir des problèmes pour accéder à 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 :
Le même itinéraire existe en tant que routage statique et via le routeur de sauvegarde.
Il existe un itinéraire statique plus spécifique que 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 sauvegarde. Si 0/0 est configuré sous un routeur de sauvegarde, 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 routeur de sauvegarde.
Si vous souhaitez configurer des routes vers la même destination à l’aide du routeur de sauvegarde et de la route statique, divisez les routes lors de la configuration sous routeur de sauvegarde. Cela rend les routes configurées sous routeur de sauvegarde comme 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 d’une méthode de mise à niveau avec un temps d’arrêt minimal.
Environnement
SRX5400 groupe de châssis.
Symptômes
-
Cluster bloqué dans le nœud0 RG1 avec indicateur IF et ne peut pas être mis à niveau.
-
L’erreur de validation de configuration est affichée sur l’interface de ligne de commande.
Causes
La configuration a le même préfixe sur les destinations du routeur de sauvegarde (sur le RE/nœud de sauvegarde) 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 ne doit pas être identique à l'adresse d'interface configurée pour IPv4 et IPv6 à l'aide des edit system backup-router address destination destination-address commandes et edit system inet6-backup-router address destination destination-address edit interfaces interface-name unit logical-unit-number family inet6 address ipv6-address. edit interfaces interface-name unit logical-unit-number family inet address ipv4-addressConfiguration de la commande backup-router sur le cluster de châssis
RÉSUMÉ 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 avec NSM et d’autres hôtes de gestion à partir du nœud secondaire.
Environnement
Cluster de châssis SRX Series
Causes
La définition d’une destination sur 0.0.0.0/0 le routeur de sauvegarde (sans configuration) n’est 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
Voir Configuration d’un routeur de sauvegarde 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 de routeur de sauvegarde 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 sauvegarde 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 sauvegarde est utilisée uniquement par le nœud secondaire RG0. Le nœud 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 d’une méthode de mise à niveau avec un temps d’arrêt minimal.
Environnement
SRX5400 groupe de châssis.
Symptômes
-
Cluster bloqué dans le nœud0 RG1 avec indicateur IF et ne peut pas être mis à niveau.
-
L’erreur de validation de configuration est affichée sur l’interface de ligne de commande.
Causes
La configuration a le même préfixe sur les destinations du routeur de sauvegarde (sur le RE/nœud de sauvegarde) 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