Gehäuse-Cluster-Fabric-Schnittstellen

Unterstützte Fabric-Schnittstellentypen für Geräte der SRX-Serie (SRX300-Serie, SRX550M, SRX1500, SRX4100/SRX4200, SRX4600 und SRX5000-Serie)

Für Chassis-Cluster der SRX-Serie kann die Fabric-Verbindung jedes Paar Ethernet-Schnittstellen sein, die den Cluster umspannen. kann die Fabric-Verbindung ein beliebiges Paar Gigabit Ethernet-Schnittstellen sein. Beispiele:

• Für SRX300-, SRX320-, SRX340-, SRX550M- und SRX345-Geräte kann die Fabric-Verbindung jedes paar Gigabit-Ethernet-Schnittstellen sein. Für SRX380-Geräte kann die Fabric-Verbindung ein beliebiges Paar von Gigabit Ethernet-Schnittstellen oder ein paar 10-Gigabit Ethernet-Schnittstellen sein.

• Für Gehäusecluster der SRX-Serie aus SRX550M-Geräten können SFP-Schnittstellen auf Mini-PIMs nicht als Fabric-Verbindung verwendet werden.

• Für SRX1500 kann die Fabric-Verbindung jedes Paar Ethernet-Schnittstellen sein, die den Cluster umspannen. die Fabric-Verbindung kann jedes Paar Gigabit Ethernet-Schnittstellen oder ein 10-Gigabit-Ethernet-Schnittstellenpaar sein.

• Unterstützte Fabric-Schnittstellentypen für SRX4100- und SRX4200-Geräte sind 10-Gigabit Ethernet(xe) (10-Gigabit Ethernet-Schnittstellen-SFP+-Steckplätze).

• Unterstützte Fabric-Schnittstellentypen für SRX4600-Geräte sind 40-Gigabit Ethernet (et) (40-Gigabit Ethernet-Schnittstellen-QSFP-Steckplätze) und 10-Gigabit Ethernet (xe).

• Unterstützte Fabric-Schnittstellentypen, die für Geräte der SRX5000-Reihe unterstützt werden, sind:

  • Fast Ethernet

  • Gigabit Ethernet

  • 10-Gigabit Ethernet

  • 40-Gigabit Ethernet

  • 100-Gigabit Ethernet

    Ab Junos OS Version 12.1X46-D10 und Junos OS Version 17.3R1 wird eine 100-Gigabit Ethernet-Schnittstelle auf Geräten der SRX5000-Reihe unterstützt.

    Ab Junos OS Version 19.3R1 werden srx5K-IOC4-10G und SRX5K-IOC4-MRAT zusammen mit SRX5K-SPC3 auf den Geräten der SRX5000-Serie unterstützt. SRX5K-IOC4-10G MPIC unterstützt MACsec.

Weitere Informationen zur Port- und Schnittstellennutzung für Management-, Steuerungs- und Fabric-Links finden Sie unter Understanding SRX Series Chassis Cluster Slot Numbering and Physical Port and Logical Interface Naming.

Jumbo Frame-Unterstützung

Die Fabric-Datenverbindung unterstützt keine Fragmentierung. Um diesen Zustand zu bewältigen, ist die Jumbo Frame-Unterstützung standardmäßig auf der Verbindung mit einer MTU-Größe (Maximum Transmission Unit) von 9014 Bytes (9000 Bytes Nutzlast + 14 Bytes für den Ethernet-Header) auf Geräten der SRX-Serie aktiviert. Um sicherzustellen, dass der Datenverkehr, der die Datenverbindung durchleitiert, diese Größe nicht überschreitet, empfehlen wir, dass keine anderen Schnittstellen die MTU-Größe des Fabric-Datenlinks überschreiten.

Understanding Fabric Interfaces on SRX5000 Line Devices for IOC2 and IOC3

Ab Junos OS-Version 15.1X49-D10 werden das SRX5K-MPC3-100G10G (IOC3) und das SRX5K-MPC3-40G10G (IOC3) eingeführt.

Das SRX5K-MPC (IOC2) ist ein Modular Port Concentrator (MPC), der auf den SRX5400, SRX5600 und SRX5800 unterstützt wird. Diese Schnittstellenkarte akzeptiert modulare Schnittstellenkarten (MICs), die Ihrem Service-Gateway Ethernet-Ports hinzufügen, um die physischen Verbindungen zu verschiedenen Netzwerkmedientypen bereitzustellen. Die MPCs und MICs unterstützen Fabric-Verbindungen für Gehäuse-Cluster. Das SRX5K-MPC bietet 10-Gigabit Ethernet-Ports (mit 10 x 10 GE MIC), 40-Gigabit Ethernet-, 100-Gigabit Ethernet- und 20 x 1GE-Ethernet-Ports als Fabric-Ports. Auf SRX5400-Geräten werden nur SRX5K-MPCs (IOC2) unterstützt.

Das SRX5K-MPC3-100G10G (IOC3) und das SRX5K-MPC3-40G10G (IOC3) sind Modular Port Concentrators (MPCs), die auf den SRX5400, SRX5600 und SRX5800 unterstützt werden. Diese Schnittstellenkarten akzeptieren modulare Schnittstellenkarten (MICs), die Ihrem Service-Gateway Ethernet-Ports hinzufügen, um die physischen Verbindungen zu verschiedenen Netzwerkmedientypen bereitzustellen. Die MPCs und MICs unterstützen Fabric-Verbindungen für Gehäuse-Cluster.

Die beiden Arten von IOC3 Modular Port Concentrators (MPCs), die über unterschiedliche integrierte MICs verfügen, sind die 24x10GE + 6x40GE MPC und die 2x100GE + 4x10GE MPC.

Aufgrund von Leistungs- und Wärmeeinschränkungen können alle vier PICs auf der 24x10GE + 6x40GE nicht eingeschaltet werden. Maximal zwei PICs können gleichzeitig eingeschaltet werden.

Verwenden Sie den set chassis fpc <slot> pic <pic> power off Befehl, um die PICs auszuwählen, die Sie einschalten möchten.

Auf SRX5400-, SRX5600- und SRX5800-Geräten in einem Gehäuse-Cluster, wenn die PICs mit Fabric-Verbindungen auf dem SRX5K-MPC3-40G10G (IOC3) ausgeschaltet werden, um alternative PICs zu aktivieren, stellen Sie stets sicher, dass:

• Die neuen Fabric-Verbindungen werden auf den neuen PICs konfiguriert, die aktiviert sind. Es muss mindestens eine Fabric-Verbindung vorhanden und online sein, um einen minimalen RTO-Verlust zu gewährleisten.

• Der Gehäuse-Cluster befindet sich im aktiv-passiven Modus, um einen minimalen RTO-Verlust zu gewährleisten, sobald alternative Verbindungen online gebracht werden.

• Wenn auf den aktivierten PICs keine alternativen Fabric-Verbindungen konfiguriert sind, stoppt die synchrone RTO-Kommunikation zwischen den beiden Knoten und der Sitzungsstatus des Gehäuseclusters wird nicht gesichert, da die Fabric-Verbindung fehlt. Sie können die CLI-Ausgabe für dieses Szenario anzeigen, die einen schlechten Gehäuse-Clusterstatus angibt, indem Sie den show chassis cluster interfaces Befehl verwenden.

Informationen zu Sitzungs-RTOs

Die Data Plane-Software, die im Aktiv/Aktiv-Modus arbeitet, verwaltet die Datenflussverarbeitung und Sitzungsstatusredundanz und verarbeitet den Transitdatenverkehr. Alle Pakete einer bestimmten Sitzung werden auf dem selben Knoten verarbeitet, um sicherzustellen, dass die gleiche Sicherheitsbehandlung auf sie angewendet wird. Das System identifiziert den Knoten, auf dem eine Sitzung aktiv ist, und leitet seine Pakete zur Verarbeitung an den Knoten weiter. (Nach der Verarbeitung eines Pakets überträgt die Packet Forwarding Engine das Paket an den Knoten, auf dem seine Ausgangsschnittstelle vorhanden ist, wenn dieser Knoten nicht der lokale ist.)

Um sitzungsbasierte (oder Fluss-)Redundanz zu gewährleisten, synchronisiert die Data Plane-Software ihren Status, indem spezielle Payload-Pakete namens Runtime Objects (RTOs) von einem Knoten zum anderen über die Fabric-Datenverbindung gesendet werden. Durch die Übertragung von Informationen über eine Sitzung zwischen den Knoten gewährleisten RTOs die Konsistenz und Stabilität von Sitzungen, wenn ein Failover durchgeführt wird, und ermöglichen es dem System somit, den Datenverkehr bestehender Sitzungen weiter zu verarbeiten. Um sicherzustellen, dass Sitzungsinformationen immer zwischen den beiden Knoten synchronisiert werden, gibt die Data Plane-Software RTOs-Übertragungsprioritäten gegenüber dem Transitdatenverkehr.

Die Data Plane-Software erstellt RTOs für UDP- und TCP-Sitzungen und überwacht Statusänderungen. Es synchronisiert auch den Datenverkehr für IPv4-Pass-Through-Protokolle wie Generic Routing Encapsulation (GRE) und IPsec.

RTOs zur Synchronisation einer Sitzung umfassen:

• RtOs zur Sitzungserstellung im ersten Paket

• Sitzungslöschung und Altersaussetzung von RTOs

• Änderungsbezogene RTOs, einschließlich:

  • TCP-Statusänderungen

  • Timeout-Synchronisationsanforderungs- und Antwortmeldungen

  • RTOs zum Erstellen und Löschen temporärer Öffnungen in der Firewall (Pinholes) und Pinholes für untergeordnete Sitzungen

Verstehen der Datenweiterleitung

Bei Junos OS erfolgt die Datenstromverarbeitung auf einem einzelnen Knoten, auf dem die Sitzung für den Datenfluss eingerichtet wurde und aktiv ist. Dieser Ansatz stellt sicher, dass die gleichen Sicherheitsmaßnahmen auf alle Pakete angewendet werden, die zu einer Sitzung gehören.

Ein Gehäuse-Cluster kann den Datenverkehr auf einer Schnittstelle auf einem Knoten empfangen und an eine Schnittstelle auf dem anderen Knoten senden. (Im Aktiv/Aktiv-Modus kann die Eingangsschnittstelle für den Datenverkehr auf einem Knoten und seine Ausgangsschnittstelle auf dem anderen vorhanden sein.)

Dieses Traversal ist in den folgenden Situationen erforderlich:

• Wenn Pakete auf einem Knoten verarbeitet werden, aber über eine Ausgangsschnittstelle auf dem anderen Knoten weitergeleitet werden müssen

• Wenn Pakete auf einem Knoten an einer Schnittstelle ankommen, müssen sie jedoch auf dem anderen Knoten verarbeitet werden

  Wenn sich die Eingangs- und Ausgangsschnittstellen für ein Paket auf einem Knoten befinden, das Paket jedoch auf dem anderen Knoten verarbeitet werden muss, da seine Sitzung dort eingerichtet wurde, muss es den Datenlink zweimal durchqueren. Dies kann für einige komplexe Mediensitzungen wie Voice-over-IP (VoIP)-Sitzungen der Fall sein.

Verstehen von Fabric-Datenverbindungsfehlern und -wiederherstellung

Intrusion Detection and Prevention (IDP)-Services unterstützen kein Failover. Aus diesem Grund werden IDP-Dienste nicht auf Sitzungen angewendet, die vor dem Failover vorhanden waren. IDP-Dienste werden für neue Sitzungen angewendet, die auf dem neuen primären Knoten erstellt wurden.

Die Fabric-Datenverbindung ist für den Chassis-Cluster von entscheidender Bedeutung. Wenn die Verbindung nicht verfügbar ist, sind die Weiterleitung des Datenverkehrs und die RTO-Synchronisation betroffen, was zu Datenverkehrsverlusten und unvorhersehbarem Systemverhalten führen kann.

Um diese Möglichkeit zu vermeiden, nutzt Junos OS die Fabric-Überwachung, um zu überprüfen, ob die Fabric-Verbindung oder die beiden Fabric-Verbindungen im Fall einer Dual-Fabric-Linkkonfiguration durch regelmäßige Übertragung von Sondierungen über die Fabric-Verbindungen am Laufen sind. Wenn Junos OS Fabric-Fehler erkennt, ändert sich der RG1+-Status des sekundären Knotens auf "ineligible". Es stellt fest, dass ein Fabric-Fehler aufgetreten ist, wenn eine Fabric-Probe nicht empfangen wird, aber die Fabric-Schnittstelle aktiv ist. Um diesen Zustand wiederherzustellen, müssen beide Fabric-Verbindungen zum Online-Status zurückkehren und mit dem Austausch von Sondierungen beginnen. Sobald dies geschieht, werden alle FPCs auf dem zuvor nicht förderbaren Knoten zurückgesetzt. Dann kommen sie zum Online-Status und treten wieder in den Cluster ein.

Wenn Sie während der Deaktivierung des sekundären Knotens Änderungen an der Konfiguration vornehmen, führen Sie den commit Befehl aus, um die Konfiguration nach dem Neustart des Knotens zu synchronisieren. Wenn Sie keine Konfigurationsänderungen vorgenommen haben, bleibt die Konfigurationsdatei mit der des primären Knotens synchronisiert.

Ab Junos OS Version 12.1X47-D10 und Junos OS Version 17.3R1 ist die Fabric-Überwachungsfunktion standardmäßig auf den Geräten SRX5800, SRX5600 und SRX5400 aktiviert.

Beginnend mit Junos OS Version 12.1X47-D10 und Junos OS Version 17.3R1 erfolgt die Wiederherstellung der Fabric-Verbindung und der Synchronisierung automatisch.

Wenn sowohl der primäre als auch der sekundäre Knoten gesund sind (d. h. es gibt keine Ausfälle) und der Fabric-Link ausfällt, werden RG1+-Redundanzgruppen auf dem sekundären Knoten nicht mehr ineligiierbar. Wenn einer der Knoten ungesund ist (d. h. es kommt zu einem Ausfall), wird die RG1+-Redundanzgruppe(n) auf diesem Knoten (entweder der primäre oder sekundäre Knoten) unwählbar. Wenn beide Knoten ungesund sind und die Fabric-Verbindung ausfällt, wird die RG1+-Redundanzgruppe(n) auf dem sekundären Knoten nicht mehr förderfähig. Wenn der Fabric-Link hochkommt, führt der Knoten, auf dem RG1+ nicht mehr unterstützt werden kann, eine Kaltsynchronisierung auf allen Services Processing Units durch und wechselt zu active Standby.

• Wenn RG0 primär auf einem ungesunden Knoten liegt, schlägt die RG0 von einem ungesunden zu einem gesunden Knoten aus. Wenn beispielsweise Knoten 0 primär für RG0+ ist und Knoten 0 ungesund wird, dann wechselt RG1+ auf Knoten 0 nach 66 Sekunden eines Fabric-Verbindungsausfalls zu unwährbar, und RG0+ schlägt zu Knoten 1 über, dem gesunden Knoten.

• Nur RG1+ wechselt zu einem nicht förderbaren Zustand. RG0 befindet sich weiterhin entweder in einem primären oder sekundären Zustand.

Verwenden Sie den show chassis cluster interfaces CLI-Befehl, um den Status der Fabric-Verbindung zu überprüfen.

Zweck

Anzeige des Gehäuse-Cluster-Datenebenen-Schnittstellenstatus.

Aktion

Geben Sie über die CLI den show chassis cluster data-plane interfaces Befehl ein:

Zweck

Anzeige von Statistiken der Chassis-Cluster-Datenebene.

Aktion

Geben Sie über die CLI den show chassis cluster data-plane statistics Befehl ein: