Multicast-Routing und asymmetrisches Routing auf Gehäuse-Cluster
Die Multicast-Routing-Unterstützung in einem Chassis-Cluster ermöglicht es verschiedenen Multicast-Protokollen, Datenverkehr über Schnittstellen an mehrere Empfänger zu senden. Asymmetrisches Routing ist eine Situation, in der Pakete vom Quellhost zum Zielhost aber 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 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. Multicastsitzungen werden im gesamten Cluster synchronisiert und während redundanter Gruppenfailover beibehalten. Während des Failovers kann es, wie bei anderen Datenverkehrstypen, zu einem Multicast-Paketverlust kommen.
Bei der Multicast-Datenweiterleitung in einem Chassis-Cluster wird anhand der eingehenden Schnittstelle bestimmt, ob die Sitzung aktiv bleibt. Pakete werden an den Peer-Knoten weitergeleitet, wenn sich die ausgehende Schnittstelle einer Leaf-Sitzung auf dem Peer-Knoten statt auf dem Knoten der eingehenden Schnittstelle befindet. Multicast-Routing in einem Gehäusecluster unterstützt Tunnel sowohl für eingehende als auch für ausgehende Schnittstellen.
Multicast-Datenverkehr hat eine Upstream- (zur Quelle hin) und eine Downstream-Richtung (zu Abonnenten) in den Datenströmen. Die Geräte replizieren (Fanout) ein einzelnes Multicast-Paket in mehrere Netzwerke, die Teilnehmer enthalten. In der Chassis-Cluster-Umgebung können Multicast-Paketfanouts auf beiden Knoten aktiv sein.
Wenn die eingehende Schnittstelle auf dem aktuellen Knoten und die Sicherung auf dem Peerknoten aktiv ist, ist die Sitzung auf dem aktuellen Knoten und die Sicherung auf dem Peerknoten aktiv.
Die Multicast-Konfiguration auf einem Gehäuse-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
Protokollunabhängiges Multicast (PIM) wird zwischen Geräten verwendet, um die Multicast-Pakete zu verfolgen, die aneinander weitergeleitet werden sollen.
Bei einer PIM-Sitzung werden Multicastdaten in ein PIM-Unicastpaket gekapselt. Eine PIM-Sitzung erstellt die folgenden Sitzungen:
Kontrollsitzung
Datensitzung
In der Datensitzung wird die Steuersitzungs-ID gespeichert. Die Kontrollsitzung und die Datensitzung werden unabhängig voneinander geschlossen. Über die Eingangsschnittstelle wird bestimmt, 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 die Synchronisierung von Multicast- und PIM-Sitzungen werden Paketverluste aufgrund von Failovers vermieden, da die Sitzungen bei einem Failover nicht erneut eingerichtet werden müssen.
In PIM-Sitzungen wird die Steuerungssitzung mit dem Sicherungsknoten synchronisiert, und dann wird die Datensitzung synchronisiert.
Bei 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 für Gehäuse-Cluster einsetzen (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 sich das Routing während der Sitzung ändert.
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 aus der Vertrauenszone mit einem Ziel des Internets (nicht vertrauenswürdige Zone) stammen.
- Grundlegendes zu Fehlern in der Vertrauenszone Redundante Ethernet-Schnittstelle
- Grundlegendes zu Fehlern in nicht vertrauenswürdigen Zonenschnittstellen
Grundlegendes zu Fehlern in der Vertrauenszone Redundante Ethernet-Schnittstelle
Unter normalen Betriebsbedingungen fließt der Datenverkehr von der Vertrauenszonenschnittstelle ge-0/0/1, die zu reth0.0 gehört, zum Internet. Da sich die primäre Internetverbindung auf Knoten 0 befindet, werden Sitzungen auf 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 kommt der Datenverkehr bei Knoten 1 an. 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 ins Internet weiter. Der Rückverkehr verläuft ähnlich. Der Datenverkehr kommt an Knoten 0 an und wird zu Sicherheitszwecken verarbeitet, z. B. für Spamschutzprüfungen, Virenschutzprüfungen und die Anwendung von Sicherheitsrichtlinien, und zwar auf Knoten 0, da die Sitzung an Knoten 0 gebunden ist. Das Paket wird dann über die Fabric-Schnittstelle zur Ausgangsverarbeitung und schließlich zur Übertragung von Knoten 1 über die Schnittstelle ge-7/0/1 gesendet.
Grundlegendes zu Fehlern in nicht vertrauenswürdigen Zonenschnittstellen
In diesem Fall werden Sitzungen von Knoten zu Knoten migriert. Unter normalen Betriebsbedingungen wird der Datenverkehr nur von Knoten 0 verarbeitet. Ein Ausfall der Schnittstelle ge-0/0/0 auf Knoten 0 führt zu einer Änderung der Routing-Tabelle, sodass sie nun auf die Schnittstelle ge-7/0/0 in Knoten 1 verweist. Nach dem Fehler werden die Sitzungen in Knoten 0 inaktiv, und die passiven Sitzungen in Knoten 1 werden aktiv. Datenverkehr, der von der Vertrauenszone eingeht, wird weiterhin an 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 Gehäuse-Cluster-Konfiguration wird Redundanzgruppe 1 zur Steuerung der redundanten Ethernet-Schnittstelle verwendet, die mit der Vertrauenszone verbunden ist. Wie in diesem Szenario konfiguriert, wird für Redundanzgruppe 1 nur ein Failover ausgeführt, wenn die Schnittstelle ge-0/0/1 oder ge-7/0/1 ausfällt, nicht jedoch, wenn die mit dem Internet verbundenen Schnittstellen ausfallen. Optional kann die Konfiguration dahingehend geändert werden, dass Redundanzgruppe 1 alle mit dem Internet verbundenen Schnittstellen überwachen und bei Ausfall einer Internetverbindung ein Failover durchführen kann. So kann die Konfiguration z. B. zulassen, dass die Redundanzgruppe 1 ge-0/0/0 überwacht und ge-7/0/1 für reth0 aktiviert, 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 Gehäusecluster so konfiguriert wird, dass asymmetrisches Routing zulässig 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, um sicherzustellen, dass es sich um die gleichen Modelle handelt. In diesem Beispiel wird ein Paar SRX1500- oder SRX1600-Geräte verwendet.
-
Um den Fabric-Link 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 zu erstellen, 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 Gehäusecluster asymmetrisches Routing. Wie in Abbildung 2 dargestellt, werden zwei Internetverbindungen verwendet, wobei eine bevorzugt wird. Die Verbindung zur Vertrauenszone wird über eine redundante Ethernetschnittstelle bereitgestellt, um LAN-Redundanz für die Geräte in der Vertrauenszone bereitzustellen.
In diesem Beispiel konfigurieren Sie Gruppen- (die Konfiguration wird mit dem apply-groups Befehl angewendet) und Chassis-Cluster-Informationen. Anschließend konfigurieren Sie Sicherheitszonen und Sicherheitsrichtlinien. Siehe Tabelle 1 bis Tabelle 4.
| Merkmal |
Name |
Konfigurationsparameter |
|---|---|---|
| Gruppen |
node0 |
|
| Knoten 1 |
|
| Merkmal |
Name |
Konfigurationsparameter |
|---|---|---|
| Fabric-Verbindungen |
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. |
| Nicht vertrauenswürdig |
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 erforderlichen Details, um sie an Ihre Netzwerkkonfiguration anzupassen, kopieren Sie die Befehle, fügen Sie sie in die CLI auf der 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 Gehäuse-Cluster-Paar:
-
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/7 -
Konfigurieren Sie die Anzahl der redundanten Ethernet-Schnittstellen.
{primary:node0}[edit] user@host# set chassis cluster reth-count 1 -
Konfigurieren 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 255 -
Konfigurieren 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/24 -
Konfigurieren 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 100 -
Konfigurieren 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.0 -
Konfigurieren 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 in der Ausgabe nicht die beabsichtigte Konfiguration angezeigt wird, 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, wechseln commit Sie aus dem Konfigurationsmodus.
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 Statistiken der Chassis-Cluster Control Plane
- Überprüfen der Data Plane-Statistiken 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 Gehäuse-Clusterstatus, den Failover-Status und die Informationen zur Redundanzgruppe.
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 Gehäuse-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 die Informationen über die Statistiken der verschiedenen Objekte, die synchronisiert werden, die Firewall- und Steuerschnittstellen-Hellos und 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 Statistiken der Chassis-Cluster Control Plane
Zweck
Überprüfen Sie die Informationen über die Statistiken der Steuerungsebene des Chassis-Clusters (gesendete und empfangene Taktsignale) und die Fabric-Link-Statistiken (gesendete und empfangene Sondierungen).
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-Statistiken des Chassis-Clusters
Zweck
Überprüfen Sie die Informationen über die Anzahl der RTOs, die für Services gesendet und empfangen wurden.
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 und Informationen darüber, ob der primäre Knoten vorzeitig getrennt 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 Chassis-Clustern 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