Zentrale Punktarchitektur in Sicherheitsgeräten – Übersicht
Der zentrale Punkt delegiert die Sitzungsverarbeitung an eine der SPUs. Wenn keine Sitzung eingerichtet wird, wählt der zentrale Punkt eine SPU aus, um die Sitzung für den Datenfluss basierend auf Lastausgleichskriterien einzurichten. Wenn die Sitzung bereits vorhanden ist, leitet der zentrale Punkt Pakete für diesen Datenstrom an die SPU weiter, die sie hostet.
Grundlegendes zur zentralen Punktarchitektur der Firewalls der SRX-Serie
Die Architektur des zentralen Punktes (CP) verfügt über zwei grundlegende Flow-Funktionen: Load Balancing und Traffic-Identifikation (Global Session Matching). Wie in diesem Thema beschrieben, wird die Architektur des zentralen Punktes entweder im zentrischen Modus implementiert, in dem die gesamte Sitzungsverteilung und der Sitzungsabgleich vom zentralen Punkt durchgeführt wird, oder im gemischten Modus, in dem ein Prozentsatz der Services Processing Unit (SPU) für die Ausführung der zentralen Punktfunktionalität vorgesehen ist.
Die Hauptfunktion des zentralen Punktes besteht darin, die Sitzungsverarbeitung an eine der SPUs zu delegieren. Wenn die Sitzung noch nicht eingerichtet wurde, wählt der zentrale Punkt eine SPU aus, um die Sitzung für den Flow basierend auf Lastausgleichskriterien einzurichten. Wenn die Sitzung bereits vorhanden ist, leitet der zentrale Punkt Pakete für diesen Datenstrom an die SPU weiter, die sie hostet. Außerdem werden Pakete an die richtige SPU umgeleitet, falls die NPU dies nicht tut.
Der zentrale Punkt verwaltet eine globale Sitzungstabelle mit Informationen über die Eigentümer-SPU einer bestimmten Sitzung. Es fungiert als zentrales Repository und Ressourcenmanager für das gesamte System.
Die Architektur des zentralen Punktes ist auch im CP-Lite-Modus implementiert, in dem das Sitzungsmanagement vom zentralen Punkt auf SPUs ausgelagert wird, um die Leistung und die Skalierung der Sitzungen zu verbessern. CP-lite wird in diesem Thema nicht behandelt.
Der Firewall-Typ der SRX-Serie in Verbindung mit der Junos OS-Version bestimmt, welcher Modus unterstützt wird.
Tabelle 1 zeigt die Implementierung der Zentralpunktarchitektur, die von den Firewalls der SRX-Serie für verschiedene Versionen unterstützt wird.
Modus, der auf SRX1400 unterstützt wird |
Unterstützte Modus SRX3000-Reihe |
Modus, der auf SRX5000 Linie unterstützt wird |
|
|---|---|---|---|
Junos OS Release 12.3X48 and Previous Releases |
|
|
|
|
Diese Firewalls der SRX-Serie werden nicht mehr unterstützt. |
Diese Firewalls der SRX-Serie werden nicht mehr unterstützt. |
Anmerkung:
NG-SPC macht den Combo-Modus obsolet. |
Junos OS Release 15.1X49-D30 and later releases |
Diese Firewalls der SRX-Serie werden nicht mehr unterstützt. |
Diese Firewalls der SRX-Serie werden nicht mehr unterstützt. |
Anmerkung:
NG-SPC macht Mixed-Mode obsolet. |
Der zentrale Punkt leitet ein Paket beim Sitzungsabgleich an seine Services Processing Unit (SPU) weiter oder verteilt Datenverkehr zur Sicherheitsverarbeitung an eine SPU, wenn das Paket mit keiner vorhandenen Sitzung übereinstimmt. Die zentrale Punktarchitektur ist im CP-zentrierten Modus implementiert, in dem die gesamte Sitzungsverteilung und der Sitzungsabgleich vom CP oder im Combo-Modus durchgeführt wird
Bei einigen Firewalls der SRX-Serie kann nicht eine gesamte SPU für die Zentralpunktfunktionalität reserviert werden, aber ein bestimmter Prozentsatz der SPU wird automatisch für die Zentralpunktfunktionalität und der Rest für die normale Datenflussverarbeitung zugewiesen. Wenn eine SPU sowohl die Funktion des zentralen Punktes als auch die normale Flussverarbeitung ausführt, spricht man von einer Kombination oder mixed, einem Modus.
Der Prozentsatz der SPU, der für die Funktionalität des zentralen Punktes vorgesehen ist, hängt von der Anzahl der SPUs im Gerät ab. Basierend auf der Anzahl der SPUs stehen für die Firewalls der SRX-Serie drei Modi zur Verfügung: kleiner zentraler Punkt, mittlerer zentraler Punkt und großer zentraler Punkt.
Im Modus mit kleinem Zentralpunkt ist ein kleiner Prozentsatz einer SPU für die Funktionalität des Zentralpunkts und der Rest für die normale Flussverarbeitung vorgesehen. Im mittleren Zentralpunktmodus wird eine SPU für die Zentralpunktfunktionalität und die normale Flussverarbeitung fast zu gleichen Teilen verwendet. Im Modus für große Zentralpunkte ist eine ganze SPU für die Zentralpunktfunktionalität reserviert. Im gemischten Modus teilen sich der zentrale Punkt und die SPU dieselbe Infrastruktur für den Lastausgleichsthread (LBT) und den gleichen Paketbestellthread (POT).
Dieses Thema umfasst die folgenden Abschnitte:
- Lastverteilung im gemischten Modus
- Gemeinsame Nutzung von Rechenleistung und Arbeitsspeicher im gemischten Modus
Lastverteilung im gemischten Modus
Der zentrale Punkt verwaltet eine SPU-Zuordnungstabelle (für die Lastverteilung), in der Live-SPUs mit den logischen SPU-IDs aufgelistet sind, die der physischen Zuordnung von TNP-Adressen (Trivial Network Protocol) zugeordnet sind. Im gemischten Modus ist die SPU, die den zentralen Punkt hostet, in der Tabelle enthalten. Der Lastverteilungsalgorithmus wird basierend auf Sitzungskapazität und Verarbeitungsleistung angepasst, um eine Überlastung von Sitzungen zu vermeiden.
Gemeinsame Nutzung von Rechenleistung und Arbeitsspeicher im gemischten Modus
Die CPU-Rechenleistung in einer SPU im gemischten Modus wird basierend auf der Plattform und der Anzahl der SPUs im System aufgeteilt. In ähnlicher Weise wird der CPU-Speicher auch zwischen dem zentralen Punkt und der SPU geteilt.
Eine SPU verfügt über mehrere Kerne (CPUs) für die Netzwerkverarbeitung. Im "kleinen" SPU-Mixed-Mode nimmt die CPU-Funktionalität einen kleinen Teil der Kerne ein, während der "mittlere" SPU-Mixed-Mode einen größeren Teil der Kerne benötigt. Die Rechenleistung für Zentralpunktfunktionalitäten und Flow-Verarbeitung wird basierend auf der Anzahl der Services Processing Cards (SPC) aufgeteilt, wie in Tabelle 2 dargestellt. Die Plattformunterstützung hängt von der Junos OS-Version in Ihrer Installation ab.
Firewall der SRX-Serie |
Zentralpunktbetrieb mit 1 SPC oder SPC2 |
Zentralpunktmodus mit 2 oder mehr SPCs oder SPC2s |
Zentralpunktbetrieb mit 1 oder 2 SPC3 |
Zentralpunktmodus mit mehr als 2 SPC3 |
|---|---|---|---|---|
SRX1400 |
Klein |
Mittel |
NA |
NA |
SRX3400 |
Klein |
Mittel |
NA |
NA |
SRX3600 |
Klein |
Mittel |
NA |
NA |
SRX3400 (erweiterte Leistungs- und Kapazitätslizenz) |
Klein |
Groß |
NA |
NA |
SRX3600 (erweiterte Leistungs- und Kapazitätslizenz) |
Klein |
Groß |
NA |
NA |
SRX5600 |
Groß |
Groß |
Mittel |
Groß |
SRX5800 |
Groß |
Groß |
Mittel |
Groß |
SRX5400 |
Groß |
Groß |
Mittel |
Groß |
Die Verarbeitung im gemischten Modus ist nur mit SPCI auf Geräten der SRX1400-, SRX3400-, SRX3600- und SRX5000-Reihe verfügbar.
Grundlegendes zu Verbesserungen der Zentralpunktarchitektur für die SRX5000 Line
Bisher war bei den SRX5000 Service-Gateways ein Engpass bei der Geräteleistung und -skalierung der zentrale Punkt. Wenn mehr Services Processing Cards (SPCs) in das System integriert wurden, stieg die Gesamtrechenleistung linear an, aber die Systemverbindungen pro Sekunde (cps) blieben konstant und konnten aufgrund des einzigen zentralen Punktes im System nicht verbessert werden. Dies wirkte sich stark auf die Gesamtsystemauslastung aus, sowohl in Bezug auf die Kapazität als auch auf die cps.
Beginnend mit Junos OS Version 15.1X49-D30 und Junos OS Version 17.3R1 wird auf Geräten der SRX5000-Reihe die Architektur der zentralen Punkte verbessert, um höhere Verbindungen pro Sekunde (cps) zu verarbeiten. Die neue Architektur des zentralen Punktes verhindert, dass Datenpakete über den zentralen Punkt geleitet werden, indem die Funktionalisten des Sitzungsmanagements an die Services Processing Unit (SPU) ausgelagert werden. Daher werden Datenpakete direkt von der Netzwerkverarbeitungseinheit an die SPU weitergeleitet, anstatt über den zentralen Punkt zu gehen.
Die Architektur des zentralen Punktes ist in zwei Module unterteilt, den zentralen Punkt der Anwendung und den verteilten zentralen Punkt. Der zentrale Punkt der Anwendung ist für das globale Ressourcenmanagement und das Load Balancing zuständig, während der verteilte zentrale Punkt für die Identifizierung des Datenverkehrs (Global Session Matching) zuständig ist. Die Funktionalität des zentralen Punktes der Anwendung wird auf der dedizierten SPU des zentralen Punktes ausgeführt, während die Funktionalität des verteilten zentralen Punktes auf die übrigen SPUs verteilt wird. Jetzt befinden sich die zentralen Punktsitzungen nicht mehr auf der dedizierten zentralen Punkt-SPU, sondern mit verteiltem zentralen Punkt auf anderen Flow-SPUs.
Der zentrale Punkt für SRX5000 Zeile bezieht sich auf den zentralen Punkt der Anwendung oder den verteilten zentralen Punkt oder beides, in Bezug auf globales Ressourcenmanagement und Lastausgleich bezieht er sich auf den zentralen Punkt der Anwendung, während er sich in Bezug auf die Datenverkehrsidentifikation und das Sitzungsmanagement auf den verteilten zentralen Punkt bezieht (manchmal auch als SPU bezeichnet).
Das SNMP-Protokoll und der SNMP-Trap wurden vom zentralen Punkt mit Ratenbegrenzung generiert. Jetzt werden das SNMP-Protokoll und der SNMP-Trap von der SPU oder dem zentralen Punkt generiert. Da es mehr als eine SPU gibt, ist die Anzahl der generierten SNMP-Protokolle und Traps höher. Um die Anzahl der Verbindungen pro Sekunde (CPS) auf dem Gerät zu überprüfen, führen Sie den Befehl aus SNMP MIB walk nxJsNodeSessionCreationPerSecond . Der SNMP-Polling-Mechanismus berechnet den CPS-Wert basierend auf der durchschnittlichen Anzahl von CPS in den letzten 96 Sekunden. Wenn der CPS also nicht konstant ist, ist die Anzahl der gemeldeten CPS ungenau.
Grundlegendes zu Leistungsverbesserungen bei Central Point-Sitzungslimits
Ab Junos OS 15.1X49-D70 und Junos OS Version 17.3R1 ist eine neue Tag-Option für Sitzungsverbindungen (conn-tag) verfügbar, mit der Sie einen Datenflussfilter hinzufügen können, um die Datenflusssitzungen des GRPS-Tunneling-Protokolls, der Benutzerebene (GTP-U) und der SCTP-Datenflusssitzungen (Stream Control Transmission Protocol) weiter zu unterscheiden.
Das Verbindungstupel der Flow-Sitzung besteht aus einem 32-Bit-Verbindungstag, das zur eindeutigen Identifizierung von GTP-U-Sitzungen und SCTP-Sitzungen verwendet wird, die nicht nur durch das sechsteilige Tupel unterschieden werden können. Sie können das System so konfigurieren, dass es das Sitzungsverbindungstag-Tupel zur Identifizierung von GTP-U-Sitzungen und SCTP-Sitzungen einschließt, indem Sie das Sitzungsverbindungs-Tag zu den sechs Standardtupeln hinzufügen, die eine Sitzung identifizieren. Das System ermittelt das DCP für GTP-U/SCTP durch Hashing des Session-Verbindungs-Tags.
Die Architektur des zentralen Punktes verteilt den GTP-U-Datenverkehr, der von einem Gateway-GPRS-Supportknoten (GGSN) und einem SGSN-Paar verarbeitet wird, auf alle SPUs, indem auf eine TEID-basierte (Tunnel Endpoint Identifier) Hash-Verteilung umgestellt wird. Um Probleme mit dem Lastenausgleich zu lösen, wird eine Tag-basierte Hash-Verteilung verwendet, um eine gleichmäßige Verteilung des SCTP-Datenverkehrs von verschiedenen Assoziationen auf alle SPUs sicherzustellen. (Das Verbindungs-Tag für GTP-U ist die TEID und für SCTP ist das vTag.)
Grundlegendes zur Datenstromunterstützung der Central Point-Architektur für GTP und SCTP
Ab Junos OS Version 15.1X49-D40 und Junos OS Version 17.3R1 bietet die zentrale Punktarchitektur erweiterte Unterstützung für GPRS Tunneling Protocol, Control (GTP-C), GPRS Tunneling Protocol, User Plane (GTP-U) und Stream Control Transmission Protocol (SCTP).
Die Architektur des zentralen Punktes, die auf den Geräten SRX5400, SRX5600 und SRX5800 unterstützt wird, wurde verbessert, um die GTP-C-Nachrichtenratenbegrenzung zu adressieren, um den GPRS-Supportknoten (GGSN) des Gateways vor der GTP-C-Nachrichtenflut zu schützen, Probleme mit der Paketverwerfung von GTP-C während der SGSN-Übergabe zu verhindern und den GTP-U-Datenverkehr, der von einem GGSN- und SGSN-Paar verarbeitet wird, auf alle SPUs zu verteilen, indem auf eine TEID-basierte Hash-Verteilung (Tunnel Endpoint Identifier) umgestellt wird. Verwenden Sie den Befehl, um die enable-gtpu-distribution GTP-U-Sitzungsverteilung zu aktivieren oder zu deaktivieren. Standardmäßig ist der enable-gtpu-distribution Befehl deaktiviert.
Das Verbindungs-Tag zum Flow-Sitzungstupel wird eingeführt, um das Problem des GTP/SCTP-Lastenausgleichs zu beheben. Alle Sitzungen, einschließlich der DCP-Sitzungen (Distributed CP) und SPU-Sitzungen, werden geändert, um Verbindungs-Tags aufzunehmen. Die Sitzungserstellung hat folgendes Tupel: src-ip, dst-ip, src-port, dst-port, protocol, session-token und connection tag.
Die GTP-ALG erfordert, dass GTP-C-Sitzungen durch Hashing von GGSN-IP-Adressen korrigiert werden. Das GTP-ALG verweigert die Erstellung einer GTP-C-Sitzung, wenn das erste Paket eine unsichere Richtung hat, was zu Paketverlusten führt. Um zu verhindern, dass die GTP-C-Pakete verworfen werden, wird eine neue Datenflusssitzung erstellt, und der GTP-C-Datenverkehr darf passieren, auch wenn die GGSN- oder SGSN-Richtung nicht bestimmt ist. Später wird die GGSN-IP mithilfe der richtigen SPU bestimmt, um die Flow-Sitzung zu erstellen und die alte Sitzung zu altern. Die intermittierenden Pakete, die auf die alte Sitzung treffen, werden an die neue SPU weitergeleitet und in der neuen Sitzung verarbeitet.
Um Probleme mit dem Lastausgleich zu lösen, wird eine Tag-basierte Hash-Verteilung verwendet, um eine gleichmäßige Verteilung des GTP-U/SCTP-Datenverkehrs auf alle SPUs sicherzustellen. Es wird ein 32-Bit-Verbindungs-Tag eingeführt, das die GTP-U- und die SCTP-Sitzungen eindeutig identifiziert. Das Verbindungs-Tag für GTP-U ist die TEID und für SCTP ist das vTag. Das Standardverbindungs-Tag ist 0. Das Verbindungstag bleibt 0, wenn es von den Sitzungen nicht verwendet wird. Flow bestimmt das Verbindungs-Tag für GTP-U/SCTP-Sitzungen und verteilt es durch Hashing des Verbindungs-Tags.
Eine SCTP-Zuordnung ist eine Verbindung zwischen zwei SCTP-Endpunkten. Jeder SCTP-Endpunkt identifiziert die Zuordnung mit einem Tag. Während des Assoziationsaufbaus (4-Wege-Handshakes) tauschen zwei SCTP-Endpunkte ihre eigenen Tags für den Paketempfang aus. Während des 4-Wege-Handshakes zeichnet der Empfänger von INIT/INIT-ACK den Wert von itag auf und fügt ihn in das vtag-Feld jedes SCTP-Pakets ein, das innerhalb dieser Zuordnung sendet. Dann verwendet der Peer den vtag, um den Absender dieses Pakets zu validieren.
Flow-Sitzungen, die nach CP-Lite wie folgt erstellt wurden:
Die SPU wird durch hash(tag) ausgewählt, der Client-zu-Server-Datenverkehr wird auf der Hash-SPU (tagB) verarbeitet und dann an die Hash-SPU (tagA) weitergeleitet. Der Server-zu-Client-Datenverkehr wird direkt über eine Hash-SPU (tagA) verarbeitet.
Nach dem Empfang des INIT-Pakets auf Hash (tagA) SPU:
DCP-Session A1: client=> Server, SCTP, Conn-ID: 0x0;
Sitzung A1: client=> server, SCTP, Conn-ID: 0x0;
Auf Hash (tagB) SPU: keine Sitzung.
Nach dem Empfang des INIT-ACK-Pakets auf Hash (tagA) SPU:
DCP-Session A1: client=> Server, SCTP, Conn-ID: 0x0;
DCP-Session A2: Server => Client, SCTP, Conn ID: tagA;
Sitzung A1: client=> server, SCTP, Conn-ID: 0x0;
Sitzung A2: Server => Client, SCTP, Conn-ID: tagA;
Auf Hash (tagB) SPU: keine Sitzung.
Nach dem Empfang des COOKIE-ECHO-Pakets auf Hash (tagA) SPU:
DCP-Session A1: client=> Server, SCTP, Conn-ID: 0x0;
DCP-Session A2: Server => Client, SCTP, Conn ID: tagA;
Sitzung A1: client=> server, SCTP, Conn-ID: 0x0;
Sitzung A2: Server => Client, SCTP, Conn-ID: tagA;
Sitzung A3: client=> server, SCTP, Conn-ID: tagB;
Auf Hash (TagB) SPU:
DCP-session: client => server, SCTP, Conn ID: tag B
Nach dem Empfang des COOKIE-ACK-Pakets ändern sich die Flow-Sitzungen nicht.
Nachdem der Handshake erfolgreich war, wird HEARBEAT auf allen Pfaden gesendet.
Grundlegendes zur Filteroption für Flow-Sitzungsverbindungsfilter
Ab Junos OS 15.1X49-D70 und Junos OS Version 17.3R1 ist eine neue Tag-Option für Sitzungsverbindungen (conn-tag) verfügbar, mit der Sie einen Datenflussfilter hinzufügen können, um die Datenflusssitzungen des GRPS-Tunneling-Protokolls, der Benutzerebene (GTP-U) und der SCTP-Datenflusssitzungen (Stream Control Transmission Protocol) weiter zu unterscheiden.
Das Verbindungstupel der Flow-Sitzung besteht aus einem 32-Bit-Verbindungstag, das zur eindeutigen Identifizierung von GTP-U-Sitzungen und SCTP-Sitzungen verwendet wird, die nicht nur durch das sechsteilige Tupel unterschieden werden können. Sie können das System so konfigurieren, dass es das Sitzungsverbindungstag-Tupel zur Identifizierung von GTP-U-Sitzungen und SCTP-Sitzungen einschließt, indem Sie das Sitzungsverbindungs-Tag zu den sechs Standardtupeln hinzufügen, die eine Sitzung identifizieren. Das System ermittelt das DCP für GTP-U/SCTP durch Hashing des Session-Verbindungs-Tags.
Die Architektur des zentralen Punktes verteilt den GTP-U-Datenverkehr, der von einem Gateway-GPRS-Supportknoten (GGSN) und einem SGSN-Paar verarbeitet wird, auf alle SPUs, indem auf eine TEID-basierte (Tunnel Endpoint Identifier) Hash-Verteilung umgestellt wird. Um Probleme mit dem Lastenausgleich zu lösen, wird eine Tag-basierte Hash-Verteilung verwendet, um eine gleichmäßige Verteilung des SCTP-Datenverkehrs von verschiedenen Assoziationen auf alle SPUs sicherzustellen. (Das Verbindungs-Tag für GTP-U ist die TEID und für SCTP ist das vTag.)
Tabelle "Änderungshistorie"
Die Funktionsunterstützung hängt von der Plattform und der Version ab, die Sie verwenden. Verwenden Sie den Feature-Explorer , um festzustellen, ob ein Feature auf Ihrer Plattform unterstützt wird.