Multicast-Routing und asymmetrisches Routing auf Chassis-Cluster
Die Unterstützung von Multicast-Routing in einem Chassis-Cluster ermöglicht es verschiedenen Multicast-Protokollen, Datenverkehr über Schnittstellen an mehrere Empfänger zu senden. Asymmetrisches Routing ist die Situation, in der Pakete vom Quellhost zum Zielhost einem anderen Pfad folgen als Pakete vom Zielhost zum Quellhost. Weitere Informationen finden Sie in den folgenden Themen:
Grundlegendes zum Multicast-Routing in einem Chassis-Cluster
Die Unterstützung von Multicast-Routing über Knoten in einem Chassis-Cluster hinweg ermöglicht es Multicast-Protokollen, wie z. B. Protocol Independent Multicast (PIM) Version 1 und 2, Internet Group Management Protocol (IGMP), Session Announcement Protocol (SAP) und Distance Vector Multicast Routing Protocol (DVMRP), Datenverkehr über Schnittstellen im Cluster zu senden. Beachten Sie jedoch, dass die Multicast-Protokolle nicht auf der Chassis-Management-Schnittstelle (fxp0) oder auf den Fabric-Schnittstellen (fab0 und fab1) aktiviert werden sollten. Multicast-Sitzungen werden im gesamten Cluster synchronisiert und bei redundanten Gruppen-Failovers beibehalten. Während des Failovers kann es, wie bei anderen Arten von Datenverkehr, zu einem gewissen Multicast-Paketverlust kommen.
Die Multicast-Datenweiterleitung in einem Chassis-Cluster verwendet die eingehende Schnittstelle, um festzustellen, ob die Sitzung aktiv bleibt oder nicht. Pakete werden an den Peer-Knoten weitergeleitet, wenn sich die ausgehende Schnittstelle einer Leaf-Sitzung auf dem Peer und nicht auf dem Knoten der eingehenden Schnittstelle befindet. Multicast-Routing auf einem Chassis-Cluster unterstützt Tunnel sowohl für eingehende als auch für ausgehende Schnittstellen.
Multicast-Datenverkehr hat eine Upstream- (zur Quelle) und eine Downstream-Richtung (zu Abonnenten) in Datenverkehrsströmen. Die Geräte replizieren (Fanout) ein einzelnes Multicast-Paket in mehrere Netzwerke, die Abonnenten enthalten. In der Chassis-Cluster-Umgebung können Multicast-Paket-Fanouts auf beiden Knoten aktiv sein.
Wenn die eingehende Schnittstelle auf dem aktuellen Knoten aktiv ist und die Sicherung auf dem Peer-Knoten erfolgt, ist die Sitzung auf dem aktuellen Knoten aktiv und die Sicherung auf dem Peer-Knoten.
Die Multicast-Konfiguration auf einem Chassis-Cluster ist identisch mit der Multicast-Konfiguration auf einem eigenständigen Gerät. Weitere Informationen finden Sie im Benutzerhandbuch für Multicast-Protokolle .
- Grundlegendes zur PIM-Datenweiterleitung
- Grundlegendes zur Multicast- und PIM-Sitzungssynchronisierung
Grundlegendes zur PIM-Datenweiterleitung
Protocol Independent Multicast (PIM) wird zwischen Geräten verwendet, um die Multicast-Pakete zu verfolgen, die aneinander weitergeleitet werden sollen.
Eine PIM-Sitzung kapselt Multicast-Daten in ein PIM-Unicast-Paket. In einer PIM-Sitzung werden die folgenden Sitzungen erstellt:
Steuerungssitzung
Daten-Session
In der Datensitzung wird die Steuerungssitzungs-ID gespeichert. Die Steuerungssitzung und die Datensitzung werden unabhängig voneinander geschlossen. Die Eingangsschnittstelle wird verwendet, um festzustellen, ob die PIM-Sitzung aktiv ist oder nicht. Wenn die ausgehende Schnittstelle auf dem Peer-Knoten aktiv ist, werden Pakete zur Übertragung an den Peer-Knoten übertragen.
Grundlegendes zur Multicast- und PIM-Sitzungssynchronisierung
Durch das Synchronisieren von Multicast- und PIM-Sitzungen können Paketverluste aufgrund eines Failovers vermieden werden, da die Sitzungen bei einem Failover nicht erneut eingerichtet werden müssen.
In PIM-Sitzungen wird die Steuerungssitzung mit dem Sicherungsknoten synchronisiert, und anschließend wird die Datensitzung synchronisiert.
In Multicastsitzungen wird die Vorlagensitzung mit dem Peerknoten synchronisiert, dann werden alle Blattsitzungen synchronisiert und schließlich wird die Vorlagensitzung erneut synchronisiert.
Siehe auch
Grundlegendes zum asymmetrischen Routing in einem Chassis-Cluster
Sie können Firewalls der SRX-Serie in asymmetrischen Routing-Szenarien mit Chassis-Clustern verwenden (siehe Abbildung 1). Der von einem Knoten empfangene Datenverkehr wird mit der Sitzungstabelle dieses Knotens abgeglichen. Das Ergebnis dieser Suche bestimmt, ob der Knoten das Paket verarbeitet oder über die Fabric-Verbindung an den anderen Knoten weiterleitet. Sitzungen werden auf dem Ausgangsknoten für das erste Paket verankert, das die Sitzung erstellt hat. Wenn Datenverkehr auf dem Knoten empfangen wird, in dem die Sitzung nicht verankert ist, werden diese Pakete über die Fabric-Verbindung an den Knoten weitergeleitet, auf dem die Sitzung verankert ist.
Der Ankerknoten für die Sitzung kann sich ändern, wenn es während der Sitzung Änderungen am Routing gibt.
In diesem Szenario werden zwei Internetverbindungen verwendet, wobei eine bevorzugt wird. Die Verbindung zur Vertrauenszone erfolgt über eine redundante Ethernet-Schnittstelle, um LAN-Redundanz für die Geräte in der Vertrauenszone bereitzustellen. In diesem Szenario werden zwei Failoverfälle beschrieben, in denen Sitzungen ihren Ursprung in der Vertrauenszone mit einem Ziel des Internets (nicht vertrauenswürdige Zone) haben.
- Grundlegendes zu Fehlern in der Trust Zone Redundante Ethernet-Schnittstelle
- Grundlegendes zu Fehlern bei Schnittstellen der nicht vertrauenswürdigen Zone
Grundlegendes zu Fehlern in der Trust Zone Redundante Ethernet-Schnittstelle
Unter normalen Betriebsbedingungen fließt der Datenverkehr von der Trust-Zone-Schnittstelle ge-0/0/1, die zu reth0.0 gehört, ins Internet. Da sich die primäre Internetverbindung auf Knoten 0 befindet, werden Sitzungen in Knoten 0 erstellt und mit Knoten 1 synchronisiert. Sitzungen sind jedoch nur auf Knoten 0 aktiv.
Ein Fehler in der Schnittstelle ge-0/0/1 löst ein Failover der Redundanzgruppe aus, wodurch die Schnittstelle ge-7/0/1 in Knoten 1 aktiv wird. Nach dem Failover trifft der Datenverkehr bei Knoten 1 ein. Nach der Sitzungssuche wird der Datenverkehr an Knoten 0 gesendet, da die Sitzung auf diesem Knoten aktiv ist. Knoten 0 verarbeitet dann den Datenverkehr und leitet ihn an das Internet weiter. Der Rückverkehr folgt einem ähnlichen Prozess. Der Datenverkehr kommt bei Knoten 0 an und wird zu Sicherheitszwecken (z. B. Antispam-Scans, Antivirus-Scans und Anwendung von Sicherheitsrichtlinien) auf Knoten 0 verarbeitet, da die Sitzung an Knoten 0 verankert ist. Das Paket wird dann über die Fabric-Schnittstelle an Knoten 1 gesendet, um den Ausgang zu verarbeiten und schließlich von Knoten 1 über die Schnittstelle ge-7/0/1 zu übertragen.
Grundlegendes zu Fehlern bei Schnittstellen der nicht vertrauenswürdigen Zone
In diesem Fall werden Sitzungen von Knoten zu Knoten migriert. Unter normalen Betriebsbedingungen wird der Datenverkehr nur von Knoten 0 verarbeitet. Ein Ausfall des Interfaces ge-0/0/0 auf Knoten 0 führt zu einer Änderung in der Routing-Tabelle, so dass diese nun auf das Interface ge-7/0/0 in Knoten 1 zeigt. Nach dem Ausfall werden die Sitzungen in Knoten 0 inaktiv und die passiven Sitzungen in Knoten 1 werden aktiv. Datenverkehr, der aus der Vertrauenszone kommt, wird weiterhin auf der Schnittstelle ge-0/0/1 empfangen, aber zur Verarbeitung an Knoten 1 weitergeleitet. Nachdem der Datenverkehr in Knoten 1 verarbeitet wurde, wird er über die Schnittstelle ge-7/0/0 an das Internet weitergeleitet.
In dieser Chassis-Cluster-Konfiguration wird die redundante Ethernet-Schnittstelle, die mit der Trust-Zone verbunden ist, über Redundanzgruppe 1 gesteuert. Wie in diesem Szenario konfiguriert, führt die Redundanzgruppe 1 nur dann ein Failover durch, wenn die Schnittstelle ge-0/0/1 oder ge-7/0/1 ausfällt, jedoch nicht, wenn die mit dem Internet verbundenen Schnittstellen ausfallen. Optional kann die Konfiguration so geändert werden, dass Redundanzgruppe 1 alle mit dem Internet verbundenen Schnittstellen überwachen und bei Ausfall einer Internetverbindung ein Failover ausführen kann. So kann die Konfiguration z. B. der Redundanzgruppe 1 erlauben, ge-0/0/0 zu überwachen und ge-7/0/1 für reth0 zu aktivieren, wenn die Internetverbindung ge-0/0/0 ausfällt. (Diese Option wird in den folgenden Konfigurationsbeispielen nicht beschrieben.)
Siehe auch
Beispiel: Konfigurieren eines asymmetrischen Chassis-Clusterpaars
In diesem Beispiel wird gezeigt, wie ein Chassis-Cluster so konfiguriert wird, dass asymmetrisches Routing möglich ist. Durch die Konfiguration des asymmetrischen Routings für einen Chassis-Cluster kann der auf beiden Geräten empfangene Datenverkehr nahtlos verarbeitet werden.
Anforderungen
Bevor Sie beginnen:
-
Verbinden Sie ein Gerätepaar physisch miteinander und stellen Sie sicher, dass es sich um dieselben Modelle handelt. In diesem Beispiel wird ein Paar SRX1500 oder SRX1600 Geräte verwendet.
-
Um die Fabric-Verbindung zu erstellen, verbinden Sie eine Gigabit-Ethernet-Schnittstelle auf einem Gerät mit einer anderen Gigabit-Ethernet-Schnittstelle auf dem anderen Gerät.
-
Um die Steuerverbindung herzustellen, verbinden Sie den Steuerport der beiden SRX1500 Geräte.
-
-
Stellen Sie über den Konsolenport eine Verbindung zu einem der Geräte her. (Dies ist der Knoten, der den Cluster bildet.)
-
Legen Sie die Cluster-ID und die Knotennummer fest.
user@host> set chassis cluster cluster-id 1 node 0 reboot
-
-
Stellen Sie über den Konsolenport eine Verbindung zum anderen Gerät her.
-
Legen Sie die Cluster-ID und die Knotennummer fest.
user@host> set chassis cluster cluster-id 1 node 1 reboot
-
Überblick
In diesem Beispiel bietet ein Chassis-Cluster asymmetrisches Routing. Wie in Abbildung 2 dargestellt, werden zwei Internetverbindungen verwendet, wobei eine bevorzugt wird. Die Verbindung zur Vertrauenszone wird über eine redundante Ethernet-Schnittstelle bereitgestellt, um LAN-Redundanz für die Geräte in der Vertrauenszone bereitzustellen.
In diesem Beispiel konfigurieren Sie Gruppen- (indem Sie die Konfiguration mit dem apply-groups Befehl anwenden) und Chassis-Clusterinformationen. Anschließend konfigurieren Sie Sicherheitszonen und Sicherheitsrichtlinien. Siehe Tabelle 1 bis Tabelle 4.
Merkmal |
Name |
Konfigurationsparameter |
|---|---|---|
Gruppen |
node0 |
|
|
node1 |
|
Merkmal |
Name |
Konfigurationsparameter |
|---|---|---|
Fabric-Links |
Fab0 |
Schnittstelle: ge-0/0/7 |
|
Fab1 |
Schnittstelle: ge-7/0/7 |
Heartbeat-Intervall |
– |
1000 |
Heartbeat-Schwellenwert |
– |
3 |
Redundanzgruppe |
1 |
|
|
|
Schnittstellenüberwachung
|
Anzahl redundanter Ethernet-Schnittstellen |
– |
1 |
Schnittstellen |
GE-0/0/1 |
|
|
GE-7/0/1 |
|
|
GE-0/0/3 |
Redundantes übergeordnetes Element: reth0 |
|
GE-7/0/3 |
Redundantes übergeordnetes Element: reth0 |
|
reth0 |
|
Name |
Konfigurationsparameter |
|---|---|
vertrauen |
Die reth0.0-Schnittstelle ist an diese Zone gebunden. |
Unglaubwürdigkeit |
Die Schnittstellen ge-0/0/1 und ge-7/0/1 sind an diese Zone gebunden. |
Zweck |
Name |
Konfigurationsparameter |
|---|---|---|
Diese Sicherheitsrichtlinie lässt Datenverkehr von der Vertrauenszone in die nicht vertrauenswürdige Zone zu. |
JEGLICHE |
|
Konfiguration
Verfahren
CLI-Schnellkonfiguration
Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für Ihre Netzwerkkonfiguration erforderlich sind, kopieren Sie die Befehle und fügen Sie sie in die CLI auf Hierarchieebene ein, und geben Sie sie dann aus dem [edit] Konfigurationsmodus ein commit .
{primary:node0}[edit]
set groups node0 system host-name srxseries-1
set groups node0 interfaces fxp0 unit 0 family inet address 192.168.100.50/24
set groups node1 system host-name srxseries-2
set groups node1 interfaces fxp0 unit 0 family inet address 192.168.100.51/24
set apply-groups “${node}”
set interfaces fab0 fabric-options member-interfaces ge-0/0/7
set interfaces fab1 fabric-options member-interfaces ge-7/0/7
set chassis cluster reth-count 1
set chassis cluster heartbeat-interval 1000
set chassis cluster heartbeat-threshold 3
set chassis cluster redundancy-group 1 node 0 priority 100
set chassis cluster redundancy-group 1 node 1 priority 1
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/3 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-7/0/3 weight 255
set interfaces ge-0/0/1 unit 0 family inet address 1.4.0.202/24
set interfaces ge-0/0/3 gigether-options redundant-parent reth0
set interfaces ge-7/0/1 unit 0 family inet address 10.2.1.233/24
set interfaces ge-7/0/3 gigether-options redundant-parent reth0
set interfaces reth0 unit 0 family inet address 10.16.8.1/24
set routing-options static route 0.0.0.0/0 qualified-next-hop 10.4.0.1 metric 10
set routing-options static route 0.0.0.0/0 qualified-next-hop 10.2.1.1 metric 100
set security zones security-zone untrust interfaces ge-0/0/1.0
set security zones security-zone untrust interfaces ge-7/0/1.0
set security zones security-zone trust interfaces reth0.0
set security policies from-zone trust to-zone untrust policy ANY match source-address any
set security policies from-zone trust to-zone untrust policy ANY match destination-address any
set security policies from-zone trust to-zone untrust policy ANY match application any
set security policies from-zone trust to-zone untrust policy ANY then permit
Schritt-für-Schritt-Anleitung
So konfigurieren Sie ein asymmetrisches Chassis-Clusterpaar:
Konfigurieren Sie die Verwaltungsschnittstelle.
{primary:node0}[edit] user@host# set groups node0 system host-name srxseries-1 user@host# set groups node0 interfaces fxp0 unit 0 family inet address 192.168.100.50/24 user@host# set groups node1 system host-name srxseries-2 user@host#set groups node1 interfaces fxp0 unit 0 family inet address 192.168.100.51/24 user@host# set apply-groups “${node}”Konfigurieren Sie die Fabric-Schnittstelle.
{primary:node0}[edit] user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/7 user@host# set interfaces fab1 fabric-options member-interfaces ge-7/0/7Konfigurieren Sie die Anzahl der redundanten Ethernet-Schnittstellen.
{primary:node0}[edit] user@host# set chassis cluster reth-count 1Konfigurieren Sie die Redundanzgruppen.
{primary:node0}[edit] user@host# set chassis cluster heartbeat-interval 1000 user@host# set chassis cluster heartbeat-threshold 3 user@host# set chassis cluster node 0 user@host# set chassis cluster node 1 user@host# set chassis cluster redundancy-group 1 node 0 priority 100 user@host# set chassis cluster redundancy-group 1 node 1 priority 1 user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/3 weight 255 user@host# set chassis cluster redundancy-group 1 interface-monitor ge-7/0/3 weight 255Konfigurieren Sie die redundanten Ethernet-Schnittstellen.
{primary:node0}[edit] user@host# set interfaces ge-0/0/1 unit 0 family inet address 1.4.0.202/24 user@host# set interfaces ge-0/0/3 gigether-options redundant-parent reth0 user@host# set interfaces ge-7/0/1 unit 0 family inet address 10.2.1.233/24 user@host# set interfaces ge-7/0/3 gigether-options redundant-parent reth0 user@host# set interfaces reth0 unit 0 family inet address 10.16.8.1/24Konfigurieren Sie die statischen Routen (eine zu jedem ISP, mit bevorzugter Route über ge-0/0/1).
{primary:node0}[edit] user@host# set routing-options static route 0.0.0.0/0 qualified-next-hop 10.4.0.1 metric 10 user@host# set routing-options static route 0.0.0.0/0 qualified-next-hop 10.2.1.1 metric 100Konfigurieren Sie die Sicherheitszonen.
{primary:node0}[edit] user@host# set security zones security-zone untrust interfaces ge-0/0/1.0 user@host# set security zones security-zone untrust interfaces ge-7/0/1.0 user@host# set security zones security-zone trust interfaces reth0.0Konfigurieren Sie die Sicherheitsrichtlinien.
{primary:node0}[edit] user@host# set security policies from-zone trust to-zone untrust policy ANY match source-address any user@host# set security policies from-zone trust to-zone untrust policy ANY match destination-address any user@host# set security policies from-zone trust to-zone untrust policy ANY match application any user@host# set security policies from-zone trust to-zone untrust policy ANY then permit
Befund
Bestätigen Sie im Betriebsmodus Ihre Konfiguration, indem Sie den show configuration Befehl eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.
Der Kürze halber enthält diese show Befehlsausgabe nur die Konfiguration, die für dieses Beispiel relevant ist. Alle anderen Konfigurationen auf dem System wurden durch Auslassungspunkte (...) ersetzt.
user@host> show configuration
version x.xx.x;
groups {
node0 {
system {
host-name srxseries-1;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.100.50/24;
}
}
}
}
}
node1 {
system {
host-name srxseries-2;
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.100.51/24;
}
}
}
}
}
}
apply-groups "${node}";
chassis {
cluster {
reth-count 1;
heartbeat-interval 1000;
heartbeat-threshold 3;
redundancy-group 1 {
node 0 priority 100;
node 1 priority 1;
interface-monitor {
ge-0/0/3 weight 255;
ge-7/0/3 weight 255;
}
}
}
}
interfaces {
ge-0/0/3 {
gigether–options {
redundant–parent reth0;
}
}
ge-7/0/3 {
gigether–options {
redundant–parent reth0;
}
}
ge–0/0/1 {
unit 0 {
family inet {
address 10.4.0.202/24;
}
}
}
ge–7/0/1 {
unit 0 {
family inet {
address 10.2.1.233/24;
}
}
}
fab0 {
fabric–options {
member–interfaces {
ge–0/0/7;
}
}
}
fab1 {
fabric–options {
member–interfaces {
ge–7/0/7;
}
}
}
reth0 {
gigether–options {
redundancy–group 1;
}
unit 0 {
family inet {
address 10.16.8.1/24;
}
}
}
}
...
routing-options {
static {
route 0.0.0.0/0 {
next-hop 10.4.0.1;
metric 10;
}
}
}
routing-options {
static {
route 0.0.0.0/0 {
next-hop 10.2.1.1;
metric 100;
}
}
}
security {
zones {
security–zone untrust {
interfaces {
ge-0/0/1.0;
ge-7/0/1.0;
}
}
security–zone trust {
interfaces {
reth0.0;
}
}
}
policies {
from-zone trust to-zone untrust {
policy ANY {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}
}
Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .
Verifizierung
Vergewissern Sie sich, dass die Konfiguration ordnungsgemäß funktioniert.
- Überprüfen des Chassis-Cluster-Status
- Überprüfen von Chassis-Cluster-Schnittstellen
- Überprüfen der Chassis-Cluster-Statistiken
- Überprüfen der Statistik der Chassis-Cluster-Steuerungsebene
- Überprüfen der Data Plane-Statistik des Chassis-Clusters
- Überprüfen des Status der Chassis-Cluster-Redundanzgruppe
- Fehlerbehebung mit Protokollen
Überprüfen des Chassis-Cluster-Status
Zweck
Überprüfen Sie den Chassis-Cluster-Status, den Failover-Status und die Redundanzgruppeninformationen.
Aktion
Geben Sie im Betriebsmodus den show chassis cluster status Befehl ein.
{primary:node0}
user@host> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy group: 1 , Failover count: 1
node0 100 primary no no
node1 1 secondary no no
Überprüfen von Chassis-Cluster-Schnittstellen
Zweck
Überprüfen Sie die Informationen zu den Chassis-Cluster-Schnittstellen.
Aktion
Geben Sie im Betriebsmodus den show chassis cluster interfaces Befehl ein.
{primary:node0}
user@host> show chassis cluster interfaces
Control link name: fxp1
Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Up 1
Interface Monitoring:
Interface Weight Status Redundancy-group
ge-0/0/3 255 Up 1
ge-7/0/3 255 Up 1
Überprüfen der Chassis-Cluster-Statistiken
Zweck
Überprüfen Sie Informationen über die Statistiken der verschiedenen Objekte, die synchronisiert werden, die Fabric- und Steuerungsschnittstellen-Hellos sowie den Status der überwachten Schnittstellen im Cluster.
Aktion
Geben Sie im Betriebsmodus den show chassis cluster statistics Befehl ein.
{primary:node0}
user@host> show chassis cluster statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 228
Heartbeat packets received: 2370
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 2272
Probes received: 597
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 160 0
Session close 147 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0
Überprüfen der Statistik der Chassis-Cluster-Steuerungsebene
Zweck
Überprüfen Sie die Informationen zu den Statistiken der Chassis-Cluster-Steuerungsebene (gesendete und empfangene Taktsignale) und zu den Fabric-Link-Statistiken (gesendete und empfangene Tests).
Aktion
Geben Sie im Betriebsmodus den show chassis cluster control-plane statistics Befehl ein.
{primary:node0}
user@host> show chassis cluster control-plane statistics
Control link statistics:
Control link 0:
Heartbeat packets sent: 258689
Heartbeat packets received: 258684
Heartbeat packets errors: 0
Fabric link statistics:
Child link 0
Probes sent: 258681
Probes received: 258681
Überprüfen der Data Plane-Statistik des Chassis-Clusters
Zweck
Überprüfen Sie Informationen über die Anzahl der gesendeten und empfangenen RTOs für Services.
Aktion
Geben Sie im Betriebsmodus den show chassis cluster data-plane statistics Befehl ein.
{primary:node0}
user@host> show chassis cluster data-plane statistics
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 6 0
Session create 160 0
Session close 147 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RPC ALG 0 0
RTSP ALG 0 0
RAS ALG 0 0
MAC address learning 0 0
GPRS GTP 0 0
Überprüfen des Status der Chassis-Cluster-Redundanzgruppe
Zweck
Überprüfen Sie den Status und die Priorität beider Knoten in einem Cluster sowie Informationen darüber, ob der primäre Knoten vorzeitig entfernt wurde oder ob ein manuelles Failover stattgefunden hat.
Aktion
Geben Sie im Betriebsmodus den chassis cluster status redundancy-group Befehl ein.
{primary:node0}
user@host> show chassis cluster status redundancy-group 1
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy-Group: 1, Failover count: 1
node0 100 primary no no
node1 1 secondary no no
Fehlerbehebung mit Protokollen
Zweck
Verwenden Sie diese Protokolle, um Probleme mit dem Chassis-Cluster zu identifizieren. Sie müssen diese Protokolle auf beiden Knoten ausführen.
Aktion
Geben Sie im Betriebsmodus die folgenden show Befehle ein.
user@host> show log jsrpd user@host> show log chassisd user@host> show log messages user@host> show log dcd user@host> show traceoptions