AUF DIESER SEITE
Der sekundäre Knoten eines Chassis-Clusters kann nicht mit J-Web verwaltet werden
Ein Chassis-Cluster kann nicht mit dem In-Service-Software-Upgrade aktualisiert werden
Konfigurieren des Befehls "backup-router" auf dem Chassis-Cluster
Ein Chassis-Cluster kann nicht mit dem In-Service-Software-Upgrade aktualisiert werden
Fehlerbehebung bei Problemen bei der Verwaltung von Chassis-Clustern
Ein Chassis-Cluster der SRX-Serie kann nicht über den Management-Port oder die Umsatz-Ports verwaltet werden
Problem
Beschreibung
Der Chassis-Cluster der SRX-Serie kann nicht über den Management-Port oder die Umsatz-Ports verwaltet werden.
Umgebung
Chassis-Cluster der SRX-Serie
Diagnose
Welchen Knoten im Chassis-Cluster verwenden Sie zum Verwalten des Clusters?
Primärer Knoten: Fahren Sie fort:
Verwalten Sie das Chassis-Cluster mit J-Web.
Hinweis:Sie können J-Web verwenden, um nur den primären Knoten zu verwalten.
Verwalten Sie den Chassis-Cluster über den Revenue-Port oder den fxp0-Management-Port.
Hinweis:Sie können den Umsatzport oder den fxp0-Verwaltungsport verwenden, um den primären Knoten zu verwalten.
Sekundärer Knoten: Fahren Sie mit der Verwaltung des Chassis-Clusters über den fxp0-Management-Port fort
Hinweis:Sie können den sekundären Knoten nur über den Verwaltungsport fxp0 verwalten.
Auflösung
- Verwalten des Chassis-Clusters mit J-Web
- Verwalten des Chassis-Clusters über den Umsatz-Port oder den fxp0-Management-Port
- Verwalten des Chassis-Clusters über den fxp0-Management-Port
- Was kommt als nächstes
- Verwalten des Chassis-Clusters mit J-Web
- Verwalten des Chassis-Clusters über den Umsatz-Port oder den fxp0-Management-Port
- Verwalten des Chassis-Clusters über den fxp0-Management-Port
- Was kommt als nächstes
Verwalten des Chassis-Clusters mit J-Web
Sie können J-Web verwenden, um nur den primären Knoten zu verwalten.
-
Verbinden Sie eine Konsole mit dem primären Knoten.
-
Führen Sie den
show system services web-managementBefehl über die CLI aus. -
Prüfen Sie, ob die Loopback-Schnittstelle (lo0) unter der HTTP/HTTPS-Konfiguration der Webverwaltung konfiguriert ist. Siehe Web-Management (Systemdienste) .
-
Wenn die Loopback-Schnittstelle (lo0) unter der HTTP/HTTPS-Konfiguration der Webverwaltung konfiguriert ist, entfernen Sie die Loopback-Schnittstelle, indem Sie den
delete system services web-management http interface lo.0Befehl ausführen. -
Bestätigen Sie die Änderung, und prüfen Sie, ob Sie jetzt das Chassis-Cluster verwalten können.
-
Wenn Sie den Chassis-Cluster immer noch nicht verwalten können, fahren Sie mit Verwalten des Chassis-Clusters mithilfe des Umsatzports oder des fxp0-Management-Ports fort.
Verwalten des Chassis-Clusters über den Umsatz-Port oder den fxp0-Management-Port
Sie können sowohl den Umsatzport als auch den fxp0-Verwaltungsport verwenden, um den primären Knoten zu verwalten.
-
Stellen Sie über den Umsatzport des primären Knotens, den Sie als Verwaltungsschnittstelle verwenden möchten, eine Verbindung zu einer Konsole her.
-
Überprüfen Sie die Konfiguration der Verwaltungsschnittstelle:
-
Stellen Sie sicher, dass die erforderlichen Systemdienste (SSH, Telnet, HTTP) auf Hierarchieebene host-inbound-traffic in der entsprechenden Zone aktiviert sind:
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } } -
Stellen Sie sicher, dass die erforderlichen Systemdienste (SSH, Telnet, HTTP) auf Hierarchieebene system services aktiviert sind:
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
-
-
Funktioniert der Ping an die Verwaltungsoberfläche?
-
Yes: Weitere Informationen finden Sie unter Chassis-Cluster der SRX-Serie kann nicht mit fxp0 verwaltet werden, wenn das Ziel im Backup-Router 0/0 ist. Wenn diese Lösung nicht funktioniert, fahren Sie mit "Nächste Schritte " fort, um einen Fall beim technischen Support von Juniper Networks zu eröffnen.
-
No: Fahren Sie mit Schritt 4 fort.
-
-
Führen Sie in der CLI den
show interfaces tersefolgenden Befehl aus:Ist in der Ausgabe der Status Up
FXP0 interface, und wird eine IP-Adresse bereitgestellt?-
Yes: Fahren Sie mit Schritt 5 fort.
-
No: Überprüfen Sie Folgendes:
-
Überprüfen Sie mithilfe der CLI, ob die fxp0-Schnittstelle ordnungsgemäß konfiguriert ist: show groups.
Beispielhafte Ausgabe:
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; } } -
Überprüfen Sie den Zustand des Kabels, das an die fxp0 Schnittstelle angeschlossen ist. Ist das Kabel in einem guten Zustand?
-
Yes: Fahren Sie mit dem nächsten Schritt fort.
-
No: Tauschen Sie das Kabel aus und versuchen Sie, das Chassis-Cluster zu verwalten. Wenn Sie das Chassis-Cluster immer noch nicht verwalten können, fahren Sie mit dem nächsten Schritt fort.
-
-
Überprüfen Sie mithilfe der CLI, ob die Fehlerzähler inkrementiert werden: show interfaces fxp0.0 extensive.
-
Yes: Wenn Sie Fehler in der Ausgabe finden, fahren Sie mit "Was kommt als Nächstes " fort, um einen Fall beim technischen Support von Juniper Networks zu eröffnen.
-
No: Wenn die Ausgabe keine Fehler enthält und Sie das Chassis-Cluster immer noch nicht verwalten können, fahren Sie mit Schritt 5 fort.
-
-
-
-
Überprüfen Sie, ob sich die IP-Adresse der fxp0 Schnittstelle und die IP-Adresse des Verwaltungsgeräts im selben Subnetz befinden.
-
Yes: Fahren Sie mit Schritt 6 fort.
-
No:Überprüfen Sie mithilfe der CLI, ob es eine Route für die IP-Adresse des Verwaltungsgeräts gibt: show route <management device IP>
-
Wenn für die IP-Adresse des Verwaltungsgeräts keine Route vorhanden ist, fügen Sie in der inet.0 Tabelle eine Route für das Verwaltungssubnetz mit dem nächsten Hop als IP-Adresse des Backup-Routers hinzu.
-
-
-
Überprüfen Sie mithilfe der CLI, ob ein ARP-Eintrag für das Verwaltungsgerät auf dem Services Gateway vorhanden ist: show arp no-resolve | match <ip>.
-
Yes: Überprüfen Sie, ob das Chassis-Cluster über mehrere Routen zum Verwaltungsgerät verfügt: show route <device-ip>.
-
Yes: Es kann Routen zum Verwaltungsgerät über die fxp0-Schnittstelle und andere Schnittstellen geben, die zu asymmetrischem Routing führen. Fahren Sie mit " Was kommt als Nächstes" fort, um einen Fall beim technischen Support von Juniper Networks zu eröffnen.
-
No: Fahren Sie mit der Verwaltung des Chassis-Clusters über den fxp0-Management-Port fort.
-
-
No: Fahren Sie mit " Was kommt als Nächstes" fort, um einen Fall beim technischen Support von Juniper Networks zu eröffnen.
-
Verwalten des Chassis-Clusters über den fxp0-Management-Port
Sie können nur den Verwaltungsport fxp0 verwenden, um den sekundären Knoten zu verwalten.
-
Überprüfen Sie die Konfiguration der Verwaltungsschnittstelle auf dem sekundären Knoten:
-
Stellen Sie sicher, dass die erforderlichen Systemdienste (SSH, Telnet, HTTP) auf Hierarchieebene host-inbound-traffic aktiviert sind:
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } } -
Stellen Sie sicher, dass die erforderlichen Systemdienste (SSH, Telnet, HTTP) auf Hierarchieebene system services aktiviert sind:
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
Weitere Informationen zu den Konfigurationsrichtlinien finden Sie unter Verwalten eines Chassis-Clusters der SRX-Serie nicht mit fxp0, wenn das Ziel im Backup-Router 0/0 ist , und Konfigurieren des Befehls backup-router auf dem Chassis-Cluster .
Wenn die Konfiguration korrekt ist und Sie das Chassis-Cluster immer noch nicht verwalten können, fahren Sie mit Schritt 2 fort.
-
-
Befinden sich die IP-Adressen der fxp0-Schnittstellen des primären und des sekundären Knotens im selben Subnetz?
-
Yes: Fahren Sie mit den nächsten Schritten fort.
-
No: Konfigurieren Sie die fxp0-Schnittstellen des primären und des sekundären Knotens im selben Subnetz. Fahren Sie mit Schritt 1 fort und überprüfen Sie die Konfiguration.
-
Was kommt als nächstes
-
Wenn das Problem weiterhin besteht, finden Sie weitere Informationen im KB-Artikel KB20795.
-
Wenn Sie weitere Informationen zum Debuggen benötigen, lesen Sie den KB-Artikel KB21164 , um die Debugprotokolle zu überprüfen.
-
Informationen zum Eröffnen eines JTAC-Falls beim Support-Team von Juniper Networks finden Sie unter Datenerfassung für den Kundensupport für die Daten, die Sie zur Unterstützung der Fehlerbehebung erfassen sollten, bevor Sie einen JTAC-Fall eröffnen.
Verwalten des Chassis-Clusters mit J-Web
Sie können J-Web verwenden, um nur den primären Knoten zu verwalten.
Verbinden Sie eine Konsole mit dem primären Knoten.
Führen Sie den
show system services web-managementBefehl über die CLI aus.Prüfen Sie, ob die Loopback-Schnittstelle (lo0) unter der HTTP/HTTPS-Konfiguration der Webverwaltung konfiguriert ist. Siehe Web-Management (Systemdienste) .
Wenn die Loopback-Schnittstelle (lo0) unter der HTTP/HTTPS-Konfiguration der Webverwaltung konfiguriert ist, entfernen Sie die Loopback-Schnittstelle, indem Sie den
delete system services web-management http interface lo.0Befehl ausführen.Bestätigen Sie die Änderung, und prüfen Sie, ob Sie jetzt das Chassis-Cluster verwalten können.
Wenn Sie den Chassis-Cluster immer noch nicht verwalten können, fahren Sie mit Verwalten des Chassis-Clusters mithilfe des Umsatzports oder des fxp0-Management-Ports fort.
Verwalten des Chassis-Clusters über den Umsatz-Port oder den fxp0-Management-Port
Sie können sowohl den Umsatzport als auch den fxp0-Verwaltungsport verwenden, um den primären Knoten zu verwalten.
Stellen Sie über den Umsatzport des primären Knotens, den Sie als Verwaltungsschnittstelle verwenden möchten, eine Verbindung zu einer Konsole her.
Überprüfen Sie die Konfiguration der Verwaltungsschnittstelle:
Stellen Sie sicher, dass die erforderlichen Systemdienste (SSH, Telnet, HTTP) auf Hierarchieebene host-inbound-traffic in der entsprechenden Zone aktiviert sind:
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } }Stellen Sie sicher, dass die erforderlichen Systemdienste (SSH, Telnet, HTTP) auf Hierarchieebene system services aktiviert sind:
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
Funktioniert der Ping an die Verwaltungsoberfläche?
Yes: Weitere Informationen finden Sie unter Chassis-Cluster der SRX-Serie kann nicht mit fxp0 verwaltet werden, wenn das Ziel im Backup-Router 0/0 ist. Wenn diese Lösung nicht funktioniert, fahren Sie mit "Nächste Schritte " fort, um einen Fall beim technischen Support von Juniper Networks zu eröffnen.
No: Fahren Sie mit Schritt 4 fort.
Führen Sie in der CLI den
show interfaces tersefolgenden Befehl aus:Ist in der Ausgabe der Status Up
FXP0 interface, und wird eine IP-Adresse bereitgestellt?Yes: Fahren Sie mit Schritt 5 fort.
No: Überprüfen Sie Folgendes:
Überprüfen Sie mithilfe der CLI, ob die fxp0-Schnittstelle ordnungsgemäß konfiguriert ist: show groups.
Beispielhafte Ausgabe:
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; } }Überprüfen Sie den Zustand des Kabels, das an die fxp0 Schnittstelle angeschlossen ist. Ist das Kabel in einem guten Zustand?
Yes: Fahren Sie mit dem nächsten Schritt fort.
No: Tauschen Sie das Kabel aus und versuchen Sie, das Chassis-Cluster zu verwalten. Wenn Sie das Chassis-Cluster immer noch nicht verwalten können, fahren Sie mit dem nächsten Schritt fort.
Überprüfen Sie mithilfe der CLI, ob die Fehlerzähler inkrementiert werden: show interfaces fxp0.0 extensive.
Yes: Wenn Sie Fehler in der Ausgabe finden, fahren Sie mit "Was kommt als Nächstes " fort, um einen Fall beim technischen Support von Juniper Networks zu eröffnen.
No: Wenn die Ausgabe keine Fehler enthält und Sie das Chassis-Cluster immer noch nicht verwalten können, fahren Sie mit Schritt 5 fort.
Überprüfen Sie, ob sich die IP-Adresse der fxp0 Schnittstelle und die IP-Adresse des Verwaltungsgeräts im selben Subnetz befinden.
Yes: Fahren Sie mit Schritt 6 fort.
No:Überprüfen Sie mithilfe der CLI, ob es eine Route für die IP-Adresse des Verwaltungsgeräts gibt: show route <management device IP>
Wenn für die IP-Adresse des Verwaltungsgeräts keine Route vorhanden ist, fügen Sie in der inet.0 Tabelle eine Route für das Verwaltungssubnetz mit dem nächsten Hop als IP-Adresse des Backup-Routers hinzu.
Überprüfen Sie mithilfe der CLI, ob ein ARP-Eintrag für das Verwaltungsgerät auf dem Services Gateway vorhanden ist: show arp no-resolve | match <ip>.
Yes: Überprüfen Sie, ob das Chassis-Cluster über mehrere Routen zum Verwaltungsgerät verfügt: show route <device-ip>.
Yes: Es kann Routen zum Verwaltungsgerät über die fxp0-Schnittstelle und andere Schnittstellen geben, die zu asymmetrischem Routing führen. Fahren Sie mit " Was kommt als Nächstes" fort, um einen Fall beim technischen Support von Juniper Networks zu eröffnen.
No: Fahren Sie mit der Verwaltung des Chassis-Clusters über den fxp0-Management-Port fort.
No: Fahren Sie mit " Was kommt als Nächstes" fort, um einen Fall beim technischen Support von Juniper Networks zu eröffnen.
Verwalten des Chassis-Clusters über den fxp0-Management-Port
Sie können nur den Verwaltungsport fxp0 verwenden, um den sekundären Knoten zu verwalten.
Überprüfen Sie die Konfiguration der Verwaltungsschnittstelle auf dem sekundären Knoten:
Stellen Sie sicher, dass die erforderlichen Systemdienste (SSH, Telnet, HTTP) auf Hierarchieebene host-inbound-traffic aktiviert sind:
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } }Stellen Sie sicher, dass die erforderlichen Systemdienste (SSH, Telnet, HTTP) auf Hierarchieebene system services aktiviert sind:
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
Weitere Informationen zu den Konfigurationsrichtlinien finden Sie unter Verwalten eines Chassis-Clusters der SRX-Serie nicht mit fxp0, wenn das Ziel im Backup-Router 0/0 ist , und Konfigurieren des Befehls backup-router auf dem Chassis-Cluster .
Wenn die Konfiguration korrekt ist und Sie das Chassis-Cluster immer noch nicht verwalten können, fahren Sie mit Schritt 2 fort.
Befinden sich die IP-Adressen der fxp0-Schnittstellen des primären und des sekundären Knotens im selben Subnetz?
Yes: Fahren Sie mit den nächsten Schritten fort.
No: Konfigurieren Sie die fxp0-Schnittstellen des primären und des sekundären Knotens im selben Subnetz. Fahren Sie mit Schritt 1 fort und überprüfen Sie die Konfiguration.
Was kommt als nächstes
Wenn das Problem weiterhin besteht, finden Sie weitere Informationen im KB-Artikel KB20795.
Wenn Sie weitere Informationen zum Debuggen benötigen, lesen Sie den KB-Artikel KB21164 , um die Debugprotokolle zu überprüfen.
Informationen zum Eröffnen eines JTAC-Falls beim Support-Team von Juniper Networks finden Sie unter Datenerfassung für den Kundensupport für die Daten, die Sie zur Unterstützung der Fehlerbehebung erfassen sollten, bevor Sie einen JTAC-Fall eröffnen.
Der sekundäre Knoten eines Chassis-Clusters kann nicht mit J-Web verwaltet werden
Problem
Beschreibung
Der sekundäre Knoten eines Chassis-Clusters kann nicht über die J-Web-Schnittstelle verwaltet werden.
Umgebung
Chassis-Cluster der SRX-Serie
Symptome
Wenn Sie sich im Junos Services Redundancy Protocol (JSRP)-Chassis-Cluster-Modus befinden, können Sie die Redundanzgruppe 0 (RG0) auf dem sekundären Knoten nicht über die J-Web-Schnittstelle verwalten.
Ursache
Sie können die J-Web-Schnittstelle verwenden, um die Redundanzgruppe 0 nur auf dem primären Knoten zu verwalten.
Die Prozesse, auf die J-Web verweist, werden nicht auf dem sekundären Knoten ausgeführt.
Beispiel
Das folgende Beispiel zeigt die Ausgabe von syslog und systemprocess sowohl auf node0 als auch auf node1, nachdem für RG0 ein Failover von node1 auf node0 ausgeführt wurde.
Auf node1 wurde der Web-Management-Prozess (httpd-gk) beendet (beendet).
Auf node0 wurde der Web-Management-Prozess (httpd-gk) gestartet.
Zwei HTTP-bezogene Prozesse (httpd-gk und httpd) werden nur auf node0 ausgeführt, dem neuen primären Knoten von 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)
Dies schränkt Remote Procedure Calls (RPCs) aus der J-Web-Logik und anschließend Seiten ein, die vom sekundären Knoten ausgegeben werden können.
Lösung
Sie können den sekundären Knoten eines Chassis-Clusters über die CLI (SSH, Telnet und Konsole) verwalten. Weitere Informationen finden Sie unter Verwalten des Chassis-Clusters mithilfe des fxp0-Management-Ports
Chassis-Cluster der SRX-Serie kann nicht mit fxp0 verwaltet werden, wenn das Ziel im Backup-Router 0/0 ist
ZUSAMMENFASSUNG In diesem Thema wird anhand eines Beispiels erläutert, wie ein Chassis-Cluster der SRX-Serie verwaltet wird, der mit der Backup-Router-Konfiguration über die fxp0-Schnittstelle konfiguriert wurde.
Problem
Beschreibung
Das Verwaltungsgerät kann den Chassis-Cluster nicht über eine fxp0-Schnittstelle verwalten, aber es kann beide fxp0-Schnittstellen anpingen.
Beispieltopologie
Die Topologie, die IP-Adressen und die Konfiguration lauten wie folgt:
Primär fxp0: 192.168.1.1/24
Sekundär fxp0: 192.168.1.2/24
Gateway für fxp0: 192.168.1.254
Verwaltungsgerät: 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;
}
}
Umgebung
Chassis-Cluster der SRX-Serie
Ursache
Es gibt eine Route für 172.16.1.1 über die anderen Schnittstellen als die fxp0-Schnittstelle auf den Clustergeräten. Es wird nicht empfohlen, 0.0.0.0/0 als Backup-Router-Ziel zu verwenden. Ping funktioniert, weil die Echoantwort für eine eingehende Echoanforderung an die fxp0-Schnittstelle gemäß der Route für 172.16.1.1 über andere Schnittstellen als fxp0 gesendet wird, Telnet jedoch fehlschlägt.
Lösung
Entfernen Sie die Route für 172.16.1.1 in der Routing-Tabelle, und legen Sie in der Gruppe node0/node1 ein spezifischeres Backup-Router-Ziel fest.
Zum Beispiel:
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;
...
}
Nach dem Anwenden der Konfiguration werden keine Änderungen in der Routing-Tabelle angezeigt, da die Backup-Router-Konfiguration nur den Verwaltungszugriff auf dem Backup-Knoten erleichtern soll. Der Zugriff auf den primären Knoten wird über das Routing auf dem primären Knoten ermöglicht.Wenn also die Konfiguration des Backup-Routers abgeschlossen ist, können Sie sehen, dass eine Route in die Weiterleitungstabelle auf dem sekundären Knoten eingefügt wird. Die Routing-Tabelle auf dem sekundären Knoten wird nicht angezeigt, da das Routing-Subsystem nicht auf dem sekundären Knoten ausgeführt wird.
Beispielausgabe, wenn der Backup-Router mit Ziel 0/0 konfiguriert ist
Routing-Tabelle auf dem primären Knoten:
{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.0Weiterleitungstabelle auf sekundärem Knoten mit Ziel 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
Beispielausgabe, wenn der Backup-Router mit Ziel 172.16.1.1/32 konfiguriert ist
Routing-Tabelle auf dem primären Knoten:
{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.0Weiterleitungstabelle auf dem primären Knoten:
Hinweis:Auf dem primären Knoten wird die Route 172.16.1.1/32 des Backup-Routers in der Beispielausgabe nicht angezeigt.
{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 1Weiterleitungstabelle auf dem sekundären Knoten:
Hinweis:Auf dem sekundären Knoten wird in der Beispielausgabe die Route 172.16.1.1/32 des Backup-Routers angezeigt. Dies erleichtert den Zugriff auf den sekundären Knoten über die fxp0-Schnittstelle.
{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
Wenn für ein bestimmtes Subnetz eine Route über den Backup-Router konfiguriert wurde und eine statische Route unter routing-options verfügbar ist, kann es zu Problemen beim Zugriff auf die fxp0-Schnittstelle kommen. Im obigen Beispiel tritt das Problem mit dem Zugriff auf die fxp0-Schnittstelle vom Verwaltungsgerät aus auf, wenn:
Die gleiche Route existiert als statische Route und über den Backup-Router.
Es gibt eine statische Route, die spezifischer ist als die Route durch den Backup-Router.
Wenn in den Beispielen die Routen vom primären Knoten mit der Weiterleitungstabelle des sekundären Knotens synchronisiert werden, hat die unter statische Route konfigurierte Route Vorrang vor der Route unter Backup-Router. Wenn 0/0 unter backup-router konfiguriert ist, ist die Wahrscheinlichkeit einer besser passenden Route unter statischer Route höher. Daher empfehlen wir, 0/0 unter Backup-Router zu vermeiden.
Wenn Sie sowohl Routen zum gleichen Ziel mit dem Backup-Router als auch die statische Route konfigurieren möchten, teilen Sie die Routen bei der Konfiguration unter backup-router auf. Dadurch werden die unter Backup-Router konfigurierten Routen zu den bevorzugten Routen und es wird sichergestellt, dass die fxp0-Schnittstelle erreichbar ist.
[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];
Ein Chassis-Cluster kann nicht mit dem In-Service-Software-Upgrade aktualisiert werden
Problem
Beschreibung
Ein Chassis-Cluster kann nicht mit der Upgrade-Methode mit minimaler Ausfallzeit aktualisiert werden.
Umgebung
SRX5400 Chassis-Cluster.
Symptome
-
Der Cluster steckt in node0 RG1 mit IF-Flag fest und kann nicht aktualisiert werden.
-
Der Konfigurationscommit-Fehler wird in der CLI angezeigt.
Ursache
Die Konfiguration hat dasselbe Präfix für Backup-Router-Ziele (auf Backup-RE/Knoten) und die Adresse der Benutzeroberfläche.
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
Lösung
Im Chassis-Cluster-Modus darf die Zieladresse des Backup-Routers für IPv4- und IPv6-Router mit den Befehlen identisch sein und darf nicht mit der Schnittstellenadresse übereinstimmen, die mit den Befehlen edit system backup-router address destination destination-address edit interfaces interface-name unit logical-unit-number family inet address ipv4-address und edit system inet6-backup-router address destination destination-address edit interfaces interface-name unit logical-unit-number family inet6 address ipv6-addressfür IPv4 und IPv6 konfiguriert wurde.Konfigurieren des Befehls "backup-router" auf dem Chassis-Cluster
ZUSAMMENFASSUNG Sichern eines Routers in einem Chassis-Cluster der SRX-Serie mithilfe des backup-router Befehls configuration.
Problem
Beschreibung
Zeitweilige Verbindungsprobleme mit NSM und anderen Management-Hosts vom sekundären Knoten aus.
Umgebung
Chassis-Cluster der SRX-Serie
Ursache
Das Festlegen eines Ziels auf 0.0.0.0/0 dem Backup-Router (ohne Konfiguration) wird nicht unterstützt.
Beispiel für eine fehlerhafte Konfiguration:
set groups node0 system backup-router 10.10.10.1 destination 0.0.0.0/0
Lösung
Unter Konfigurieren eines Backup-Routers finden Sie die empfohlene Methode zum Einrichten eines Backup-Routers mit einem Präfix ungleich Null.
Beispiel für eine Subnetz-Backup-Router-Konfiguration ungleich Null:
set groups node0 system backup-router 10.10.10.1 destination 10.100.0.0/16
Als Alternative zum 0/0-Backup-Router-Ziel ist hier ein weiteres Beispiel, bei dem 0/0 in zwei Präfixe aufgeteilt wird:
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
Wenn mehrere Netzwerke über den Backup-Router erreichbar sein müssen, können Sie der Konfiguration mehrere Zieleinträge hinzufügen. Die Backup-Router-Konfiguration wird nur vom sekundären RG0-Knoten verwendet. Der primäre Knoten verwendet weiterhin die Routing-Tabelle inet.0.
Ein Chassis-Cluster kann nicht mit dem In-Service-Software-Upgrade aktualisiert werden
Problem
Beschreibung
Ein Chassis-Cluster kann nicht mit der Upgrade-Methode mit minimaler Ausfallzeit aktualisiert werden.
Umgebung
SRX5400 Chassis-Cluster.
Symptome
-
Der Cluster steckt in node0 RG1 mit IF-Flag fest und kann nicht aktualisiert werden.
-
Der Konfigurationscommit-Fehler wird in der CLI angezeigt.
Ursache
Die Konfiguration hat dasselbe Präfix für Backup-Router-Ziele (auf Backup-RE/Knoten) und die Adresse der Benutzeroberfläche.
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