Fehlerbehebung bei Problemen bei der Verwaltung von Chassis-Clustern
Ein Chassis-Cluster der SRX-Serie kann nicht mithilfe des Management-Ports oder des Umsatz-Ports verwaltet werden
Problem
Beschreibung
Der Chassis-Cluster der SRX-Serie kann nicht mithilfe des Management-Ports oder der Umsatz-Ports verwaltet werden.
Umwelt
Gehäuse-Cluster der SRX-Serie
Diagnose
Welchen Knoten im Chassis-Cluster verwenden Sie für die Verwaltung des Clusters?
Primärer Knoten: Fahren Sie mit folgendem Pfad fort:
Verwalten Sie den Chassis-Cluster mit J-Web.
Anmerkung:Sie können J-Web verwenden, um nur den primären Knoten zu verwalten.
Verwalten Sie den Chassis-Cluster mithilfe des Revenue-Ports oder des FXP0-Management-Ports.
Anmerkung:Sie können den Umsatzport oder den fxp0-Managementport 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
Anmerkung:Sie können den sekundären Knoten nur mithilfe des fxp0-Managementports verwalten.
Auflösung
- Verwalten des Chassis-Clusters mit J-Web
- Verwalten von Gehäuse-Clustern über den Revenue-Port oder den FXP0-Management-Port
- Verwalten des Gehäuse-Clusters mithilfe des fxp0-Management-Ports
- Was kommt als nächstes
- Verwalten des Chassis-Clusters mit J-Web
- Verwalten von Gehäuse-Clustern über den Revenue-Port oder den FXP0-Management-Port
- Verwalten des Gehäuse-Clusters mithilfe des fxp0-Management-Ports
- 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 Web-Management-HTTP/HTTPS-Konfiguration konfiguriert ist. Siehe Web-Management (Systemdienste) .
-
Wenn die Loopback-Schnittstelle (lo0) unter der Web-Management-HTTP/HTTPS-Konfiguration konfiguriert ist, entfernen Sie die Loopback-Schnittstelle, indem Sie den
delete system services web-management http interface lo.0Befehl ausführen. -
Übernehmen Sie die Änderung, und prüfen Sie, ob Sie den Chassis-Cluster jetzt 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-Managementports fort.
Verwalten von Gehäuse-Clustern über den Revenue-Port oder den FXP0-Management-Port
Sie können sowohl den Umsatzport als auch den fxp0-Managementport verwenden, um den primären Knoten zu verwalten.
-
Stellen Sie eine Verbindung zu einer Konsole her, indem Sie den Umsatzport des primären Knotens verwenden, den Sie als Verwaltungsschnittstelle verwenden möchten.
-
Überprüfen Sie die Konfiguration der Verwaltungsschnittstelle:
-
Stellen Sie sicher, dass die erforderlichen Systemdienste (SSH, Telnet, HTTP) auf der host-inbound-traffic Hierarchieebene 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 Ein Chassis-Cluster der SRX-Serie kann nicht mithilfe von FXP0 verwaltet werden, wenn das Ziel im Backup-Router 0/0 ist. Wenn diese Lösung nicht funktioniert, 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 Schritt 4 fort.
-
-
Führen Sie in der CLI den
show interfaces tersefolgenden Befehl aus:Lautet in der Ausgabe der Status
FXP0 interface"Up", 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 richtig konfiguriert ist: show groups.
Beispielausgabe:
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 mit der fxp0 Schnittstelle verbunden ist. Ist das Kabel in gutem Zustand?
-
Yes: Fahren Sie mit dem nächsten Schritt fort.
-
No: Ersetzen Sie das Kabel, und versuchen Sie, das Gehäuse-Cluster zu verwalten. Wenn Sie den Chassis-Cluster immer noch nicht verwalten können, fahren Sie mit dem nächsten Schritt fort.
-
-
Prüfen Sie mithilfe der CLI, ob 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 mit dem technischen Support von Juniper Networks zu eröffnen.
-
No: Wenn die Ausgabe keine Fehler enthält und Sie den Gehäuse-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 keine Route für die IP-Adresse des Verwaltungsgeräts 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 auf dem Services Gateway ein ARP-Eintrag für das Verwaltungsgerät vorhanden ist: show arp no-resolve | match <ip>.
-
Yes: Überprüfen Sie, ob der Gehäusecluster über mehrere Routen zum Verwaltungsgerät verfügt: show route <device-ip>.
-
Yes: Möglicherweise gibt es über die fxp0-Schnittstelle und andere Schnittstellen Routen zum Verwaltungsgerät, was zu asymmetrischem Routing führt. Fahren Sie mit Was als Nächstes fort, um einen Fall mit dem technischen Support von Juniper Networks zu eröffnen.
-
No: Fahren Sie mit der Verwaltung des Gehäuse-Clusters mit dem fxp0-Managementport fort.
-
-
No: Fahren Sie mit Was als Nächstes fort, um einen Fall mit dem technischen Support von Juniper Networks zu eröffnen.
-
Verwalten des Gehäuse-Clusters mithilfe des fxp0-Management-Ports
Sie können nur den Managementport 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 finden Sie unter Ein Chassis-Cluster der SRX-Serie kann nicht mithilfe von FXP0 verwaltet werden, wenn das Ziel im Backup-Router 0/0 ist , und Konfigurieren des Befehls "backup-router"Konfigurieren des Befehls "backup-router" im Chassis-Cluster , um weitere Informationen zu den Konfigurationsrichtlinien zu erhalten.
Wenn die Konfiguration korrekt ist und Sie den 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, lesen Sie den KB-Artikel KB20795.
-
Wenn Sie weiter debuggen möchten, lesen Sie KB-Artikel KB21164 , um die Debug-Protokolle zu überprüfen.
-
Informationen zum Eröffnen eines JTAC-Falls beim Support-Team von Juniper Networks finden Sie unter Datenerfassung für den Kundensupport. Die Daten, die Sie zur Unterstützung der Fehlerbehebung vor der Eröffnung eines JTAC-Falls erfassen sollten, finden Sie unter Datenerfassung für den Kundensupport .
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 Web-Management-HTTP/HTTPS-Konfiguration konfiguriert ist. Siehe Web-Management (Systemdienste) .
Wenn die Loopback-Schnittstelle (lo0) unter der Web-Management-HTTP/HTTPS-Konfiguration konfiguriert ist, entfernen Sie die Loopback-Schnittstelle, indem Sie den
delete system services web-management http interface lo.0Befehl ausführen.Übernehmen Sie die Änderung, und prüfen Sie, ob Sie den Chassis-Cluster jetzt 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-Managementports fort.
Verwalten von Gehäuse-Clustern über den Revenue-Port oder den FXP0-Management-Port
Sie können sowohl den Umsatzport als auch den fxp0-Managementport verwenden, um den primären Knoten zu verwalten.
Stellen Sie eine Verbindung zu einer Konsole her, indem Sie den Umsatzport des primären Knotens verwenden, den Sie als Verwaltungsschnittstelle verwenden möchten.
Überprüfen Sie die Konfiguration der Verwaltungsschnittstelle:
Stellen Sie sicher, dass die erforderlichen Systemdienste (SSH, Telnet, HTTP) auf der host-inbound-traffic Hierarchieebene 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 Ein Chassis-Cluster der SRX-Serie kann nicht mithilfe von FXP0 verwaltet werden, wenn das Ziel im Backup-Router 0/0 ist. Wenn diese Lösung nicht funktioniert, 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 Schritt 4 fort.
Führen Sie in der CLI den
show interfaces tersefolgenden Befehl aus:Lautet in der Ausgabe der Status
FXP0 interface"Up", 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 richtig konfiguriert ist: show groups.
Beispielausgabe:
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 mit der fxp0 Schnittstelle verbunden ist. Ist das Kabel in gutem Zustand?
Yes: Fahren Sie mit dem nächsten Schritt fort.
No: Ersetzen Sie das Kabel, und versuchen Sie, das Gehäuse-Cluster zu verwalten. Wenn Sie den Chassis-Cluster immer noch nicht verwalten können, fahren Sie mit dem nächsten Schritt fort.
Prüfen Sie mithilfe der CLI, ob 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 mit dem technischen Support von Juniper Networks zu eröffnen.
No: Wenn die Ausgabe keine Fehler enthält und Sie den Gehäuse-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 keine Route für die IP-Adresse des Verwaltungsgeräts 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 auf dem Services Gateway ein ARP-Eintrag für das Verwaltungsgerät vorhanden ist: show arp no-resolve | match <ip>.
Yes: Überprüfen Sie, ob der Gehäusecluster über mehrere Routen zum Verwaltungsgerät verfügt: show route <device-ip>.
Yes: Möglicherweise gibt es über die fxp0-Schnittstelle und andere Schnittstellen Routen zum Verwaltungsgerät, was zu asymmetrischem Routing führt. Fahren Sie mit Was als Nächstes fort, um einen Fall mit dem technischen Support von Juniper Networks zu eröffnen.
No: Fahren Sie mit der Verwaltung des Gehäuse-Clusters mit dem fxp0-Managementport fort.
No: Fahren Sie mit Was als Nächstes fort, um einen Fall mit dem technischen Support von Juniper Networks zu eröffnen.
Verwalten des Gehäuse-Clusters mithilfe des fxp0-Management-Ports
Sie können nur den Managementport 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 mithilfe von fxp0, wenn das Ziel im Backup-Router 0/0 ist und Konfigurieren des Befehls backup-router im Chassis-Cluster .
Wenn die Konfiguration korrekt ist und Sie den 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, lesen Sie den KB-Artikel KB20795.
Wenn Sie weiter debuggen möchten, lesen Sie KB-Artikel KB21164 , um die Debug-Protokolle zu überprüfen.
Informationen zum Eröffnen eines JTAC-Falls beim Support-Team von Juniper Networks finden Sie unter Datenerfassung für den Kundensupport. Die Daten, die Sie zur Unterstützung der Fehlerbehebung vor der Eröffnung eines JTAC-Falls erfassen sollten, finden Sie unter Datenerfassung für den Kundensupport .
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.
Umwelt
Gehäuse-Cluster der SRX-Serie
Symptome
Im JSRP-Chassis-Cluster-Modus (Junos Services Redundancy Protocol) können Sie die Redundanzgruppe 0 (RG0) auf dem sekundären Knoten nicht über die J-Web-Schnittstelle verwalten.
Verursachen
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 dem Systemprozess sowohl auf node0 als auch auf node1, nachdem für RG0 ein Failover von node1 auf node0 durchgefü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) von 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 Befehlszeileneingabe (SSH, Telnet und Konsole) verwalten. Weitere Informationen finden Sie unter Verwalten des Chassis-Clusters mithilfe des fxp0-Managementports
Gehäusecluster der SRX-Serie können nicht mithilfe von FXP0 verwaltet werden, wenn das Ziel im Backup-Router 0/0 ist
In diesem Thema wird anhand eines Beispiels erläutert, wie ein Chassis-Cluster der SRX-Serie verwaltet wird, der mit der Konfiguration "Backup-Router" ü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 pingen.
Beispiel-Topologie
Die Topologie, IP-Adressen und 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;
}
}
Umwelt
Gehäuse-Cluster der SRX-Serie
Verursachen
Es gibt eine Route für 172.16.1.1 über andere 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 der Route für 172.16.1.1 über andere Schnittstellen als fxp0 folgt, Telnet jedoch fehlschlägt.
Lösung
Entfernen Sie die Route für 172.16.1.1 in der Routing-Tabelle, und legen Sie ein spezifischeres Backup-Router-Ziel in der Gruppe node0/node1 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 in der Routing-Tabelle keine Änderungen 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 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 wird auf dem sekundären Knoten 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 dem 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:
Anmerkung:Auf dem primären Knoten wird die Route 172.16.1.1/32 des Backup-Routers nicht in der Beispielausgabe 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:
Anmerkung:Auf dem sekundären Knoten wird die Route 172.16.1.1/32 des Backup-Routers in der Beispielausgabe 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 und eine statische Route unter routing-options konfiguriert 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:
Es existiert dieselbe Route als statische Route und über den Backup-Router.
Es gibt eine statische Route, die spezifischer ist als die Route über 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 dem 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 dem Backup-Router zu vermeiden.
Wenn Sie Routen zum gleichen Ziel sowohl mit dem Backup-Router als auch mit der statischen Route konfigurieren möchten, teilen Sie die Routen bei der Konfiguration unter Backup-Router auf. Dadurch werden die unter dem 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 Gehäuse-Cluster kann nicht mithilfe eines Softwareupgrades während des Betriebs aktualisiert werden
Problem
Beschreibung
Ein Chassis-Cluster kann nicht mit der Upgrade-Methode mit minimaler Ausfallzeit aktualisiert werden.
Umwelt
SRX5400 Gehäuse-Cluster.
Symptome
-
Der Cluster steckt in node0 RG1 mit dem IF-Flag fest und kann nicht upgardiert werden.
-
Der Commit-Fehler der Konfiguration wird in der CLI angezeigt.
Verursachen
Die Konfiguration hat das gleiche Präfix für die Backup-Router-Ziele (für die Backup-RE/den Backup-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, die die Befehle edit system backup-router address destination destination-address edit system inet6-backup-router address destination destination-address verwenden, nicht mit der Schnittstellenadresse identisch sein, die mit den Befehlen edit interfaces interface-name unit logical-unit-number family inet address ipv4-address edit interfaces interface-name unit logical-unit-number family inet6 address ipv6-addressund für IPv4 und IPv6 konfiguriert wurde.Konfigurieren des Befehls "backup-router" im Chassis-Cluster
So sichern Sie einen Router in einem Chassis-Cluster der SRX-Serie mithilfe des backup-router Konfigurationsbefehls.
Problem
Beschreibung
Zeitweilige Konnektivitätsprobleme mit NSM und anderen Management-Hosts vom sekundären Knoten.
Umwelt
Gehäuse-Cluster der SRX-Serie
Verursachen
Das Festlegen eines Ziels 0.0.0.0/0 auf 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 unter Verwendung eines Präfixes 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 Gehäuse-Cluster kann nicht mithilfe eines Softwareupgrades während des Betriebs aktualisiert werden
Problem
Beschreibung
Ein Chassis-Cluster kann nicht mit der Upgrade-Methode mit minimaler Ausfallzeit aktualisiert werden.
Umwelt
SRX5400 Gehäuse-Cluster.
Symptome
-
Der Cluster steckt in node0 RG1 mit dem IF-Flag fest und kann nicht upgardiert werden.
-
Der Commit-Fehler der Konfiguration wird in der CLI angezeigt.
Verursachen
Die Konfiguration hat das gleiche Präfix für die Backup-Router-Ziele (für die Backup-RE/den Backup-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