Présentation de l’architecture de point central dans les appareils de sécurité
Le point central délègue le traitement de la session à l’une des SPU. Lorsqu’aucune session n’est établie, le point central sélectionne une SPU pour établir la session du flux, en fonction de critères d’équilibrage de charge. Si la session existe déjà, le point central transmet les paquets de ce flux à l’unité de services intensifs qui l’héberge.
Comprendre l’architecture des points centraux des pare-feu SRX Series
L’architecture de point central (CP) comporte deux fonctionnalités de flux de base : l’équilibrage de charge et l’identification du trafic (correspondance globale des sessions). Comme décrit dans cette rubrique, l’architecture de point central est implémentée soit en mode central, dans lequel toute la distribution et la correspondance des sessions sont effectuées par le point central, soit en mode mixte, dans lequel un pourcentage de l’unité de traitement des services (SPU) est dédié à l’exécution de la fonctionnalité de point central.
La fonction principale du point central est de déléguer le traitement des sessions à l’une des SPU. Si la session n’a pas encore été établie, le point central sélectionne une SPU pour établir la session du flux, en fonction de critères d’équilibrage de charge. Si la session existe déjà, le point central transmet les paquets de ce flux à l’unité de services intensifs qui l’héberge. Il redirige également les paquets vers le bon SPU dans le cas où le NPU ne le fait pas.
Le point central gère une table de session globale avec des informations sur le SPU propriétaire d’une session particulière. Il fonctionne comme un référentiel central et un gestionnaire de ressources pour l’ensemble du système.
L’architecture de point central est également implémentée en mode CP-lite, dans lequel la gestion des sessions est déchargée du point central vers les SPU pour améliorer les performances et la mise à l’échelle des sessions. CP-lite n’est pas abordé dans cette rubrique.
Le type de pare-feu SRX Series, associé à la version de Junos OS, détermine le mode pris en charge.
Le point central transfère un paquet à son unité de traitement des services (SPU) lorsque la session correspond, ou distribue le trafic à une SPU pour traitement de sécurité si le paquet ne correspond à aucune session existante. L’architecture de point central est mise en œuvre en mode centré sur le CP, dans lequel toute la distribution et la correspondance des sessions sont effectuées par le CP ou en mode combo
Sur certains pare-feu SRX Series, une unité SPU entière ne peut pas être dédiée à la fonctionnalité de point central, mais un certain pourcentage de la SPU est automatiquement alloué à la fonctionnalité de point central et le reste est affecté au traitement de flux normal. Lorsqu’un SPU remplit la fonction de point central ainsi que de traitement de flux normal, on dit qu’il est en combinaison ou mixed, en mode.
Le pourcentage de SPU dédiée à la fonctionnalité du point central dépend du nombre de SPU dans l’appareil. En fonction du nombre de SPU, trois modes sont disponibles sur les pare-feu SRX Series : petit point central, point central moyen et grand point central.
En mode petit point central, un petit pourcentage d’un SPU est dédié à la fonctionnalité du point central et le reste est dédié au traitement du flux normal. En mode point central moyen, un SPU est partagé presque également pour la fonctionnalité du point central et le traitement du flux normal. En mode grand point central, un SPU entier est dédié à la fonctionnalité de point central. En mode mixte, le point central et la SPU partagent la même infrastructure de thread d’équilibrage de charge (LBT) et de thread de commande de paquets (POT).
Cette rubrique comprend les sections suivantes :
- Répartition de la charge en mode mixte
- Partage de la puissance de traitement et de la mémoire en mode mixte
Répartition de la charge en mode mixte
Le point central gère la table de mappage des SPU (pour la répartition de la charge) qui répertorie les SPU actives avec les ID SPU logiques mappés au mappage d’adresses physiques TNP (Trivial Network Protocol). En mode mixte, le SPU qui héberge le point central est inclus dans le tableau. L’algorithme de répartition de la charge est ajusté en fonction de la capacité des sessions et de la puissance de traitement afin d’éviter la surcharge des sessions.
Partage de la puissance de traitement et de la mémoire en mode mixte
La puissance de traitement du processeur dans une SPU en mode mixte est partagée en fonction de la plate-forme et du nombre de SPU dans le système. De même, la mémoire du processeur est également partagée entre le point central et le SPU.
Une SPU dispose de plusieurs cœurs (CPU) pour le traitement réseau. En mode mixte SPU « petit », la fonctionnalité CPU occupe une petite partie des cœurs, tandis que le mode mixte SPU « moyen » nécessite une plus grande partie des cœurs. La puissance de traitement des fonctionnalités des points centraux et du traitement des flux est partagée, en fonction du nombre de cartes de traitement des services (SPC), comme indiqué dans le Tableau 1. La prise en charge de la plate-forme dépend de la version de Junos OS dans votre installation.
Pare-feu SRX Series |
Mode point central avec 1 SPC ou SPC2 |
Mode point central avec 2 SPC ou SPC2 ou plus |
Mode point central avec 1 ou 2 SPC3 |
Mode point central avec plus de 2 SPC3 |
|---|---|---|---|---|
SRX5600 |
Grande |
Grande |
Moyen |
Grande |
SRX5800 |
Grande |
Grande |
Moyen |
Grande |
SRX5400 |
Grande |
Grande |
Moyen |
Grande |
Comprendre les améliorations apportées à l’architecture du point central pour la ligne SRX5000
Auparavant, pour la gamme SRX5000 de passerelles de services, le point central était un goulot d’étranglement pour les performances et l’évolutivité des appareils. Lorsque davantage de cartes de traitement de services (SPC) étaient intégrées dans le système, la puissance de traitement globale augmentait linéairement, mais les connexions système par seconde (CPS) restaient constantes et ne pouvaient pas être améliorées en raison du point centralisé unique du système. Cela a eu de graves répercussions sur l’utilisation globale du système, tant en termes de capacité que de CPS.
La nouvelle architecture de point central empêche les paquets de données de passer par le point central en déléguant les fonctionnalistes de gestion de session à l’unité de traitement des services (SPU). Par conséquent, les paquets de données sont directement transférés de l’unité de traitement du réseau à l’unité de traitement du réseau au lieu de passer par le point central.
L’architecture de point central est divisée en deux modules, le point central d’application et le point central distribué. Le point central des applications est responsable de la gestion globale des ressources et de l’équilibrage des charges, tandis que le point central distribué est responsable de l’identification du trafic (correspondance globale des sessions). La fonctionnalité de point central d’application s’exécute sur la SPU de point central dédiée, tandis que la fonctionnalité de point central distribuée est distribuée au reste des SPU. Désormais, les sessions de point central ne se trouvent plus sur la SPU de point central dédiée, mais sur d’autres SPU de flux.
Le point central de la gamme SRX5000 fait référence au point central de l’application, ou au point central distribué ou aux deux, en ce qui concerne la gestion globale des ressources et l’équilibrage de charge, il fait référence au point central de l’application, tandis qu’en ce qui concerne l’identification du trafic et la gestion des sessions, il fait référence au point central distribué (parfois également appelé SPU).
Le journal SNMP et l’interruption SNMP étaient générés par le point central avec limite de débit. Désormais, le journal SNMP et l’interruption SNMP sont générés par la SPU ou le point central. Comme il y a plus d’une SPU, le nombre de journaux SNMP et d’interruptions générées est plus élevé. Pour vérifier le nombre de connexions par seconde (CPS) sur l’appareil, exécutez SNMP MIB walk nxJsNodeSessionCreationPerSecond la commande. Le mécanisme d’interrogation SNMP calcule la valeur CPS en fonction du nombre moyen de CPS au cours des 96 dernières secondes. Donc, si le CPS n’est pas constant, le nombre de CPS signalés est inexact.
Comprendre l’amélioration des performances des limites de session au point central
Le tuple de connexion de session de flux consiste en une balise de connexion de 32 bits utilisée pour identifier de manière unique les sessions GTP-U et les sessions SCTP qui ne peuvent pas être distinguées par le n-uplet en six parties uniquement. Vous pouvez configurer le système pour inclure le tuple de balise de connexion de session afin d’identifier les sessions GTP-U et les sessions SCTP en ajoutant la balise de connexion de session aux six tuples standard qui identifient une session. Le système détermine le DCP pour GTP-U/SCTP en hachant la balise de connexion de session.
L’architecture centrale distribue le trafic GTP-U géré par une passerelle GGSN (GPRS support node) et une paire SGSN sur toutes les SPU en passant à une distribution de hachage basée sur l’identifiant de point de terminaison de tunnel (TEID). Pour gérer les problèmes d’équilibrage de charge, la distribution de hachage basée sur les balises garantit une répartition uniforme du trafic SCTP provenant de différentes associations entre toutes les SPU. (La balise de connexion pour GTP-U est le TEID et pour SCTP est le vTag.)
Comprendre la prise en charge des flux de l’architecture de point central pour GTP et STCP
L’architecture à point central offre une prise en charge améliorée du protocole de tunnelisation GPRS, DU PROTOCOLE DE CONTRÔLE (GTP-C), du protocole de tunnelisation GPRS, du plan utilisateur (GTP-U) et du protocole de transmission de contrôle de flux (SCTP).
L’architecture de point central, prise en charge sur les appareils SRX5400, SRX5600 et SRX5800, a été améliorée pour limiter le débit de message GTP-C afin de protéger le nœud de support GPRS de passerelle (GGSN) du flux de messages GTP-C, d’éviter les problèmes de perte de paquets GTP-C lors du transfert SGSN et de distribuer le trafic GTP-U géré par une paire GGSN et SGSN sur toutes les SPU en passant à une distribution de hachage basée sur l’identifiant de point de terminaison de tunnel (TEID). Utilisez la commande pour activer ou désactiver la enable-gtpu-distribution distribution de session GTP-U. Par défaut, la enable-gtpu-distribution commande est désactivée.
Le tuple de session Connection-Tag to Flow est introduit pour résoudre les problèmes d’équilibrage de charge GTP/SCTP. Toutes les sessions, y compris les sessions CP distribuées (DCP) et SPU, sont modifiées pour prendre en charge la balise de connexion. La création de session a le tuple suivant : src-ip, dst-ip, src-port, dst-port, protocole, jeton de session et balise de connexion.
L’ALG GTP nécessite que les sessions GTP-C soient corrigées en hachant les adresses IP GGSN. L’ALG GTP refuse la création de session GTP-C si le premier paquet est de direction incertaine, ce qui entraînera la perte de paquets. Pour empêcher la perte des paquets GTP-C, une nouvelle session de flux est créée et le trafic GTP-C est autorisé à passer même si la direction GGSN ou SGSN n’est pas déterminée. Ensuite, l’adresse IP GGSN est déterminée à l’aide de la bonne SPU pour créer la session de flux et faire vieillir l’ancienne session. Les paquets intermittents atteignant l’ancienne session seront transférés à la nouvelle SPU et traités lors de la nouvelle session.
Pour gérer les problèmes d’équilibrage de charge, la distribution de hachage basée sur les balises garantit une répartition uniforme du trafic GTP-U/SCTP entre toutes les SPU. Une balise de connexion 32 bits est introduite pour identifier de manière unique les sessions GTP-U et SCTP. La balise de connexion pour GTP-U est le TEID et pour SCTP est le vTag. La balise de connexion par défaut est 0. La balise de connexion reste 0 si elle n’est pas utilisée par les sessions. Flow détermine la balise de connexion pour les sessions GTP-U/SCTP et les distribue en hachant la balise de connexion.
Une association SCTP est une connexion entre deux points de terminaison SCTP. Chaque point de terminaison SCTP identifie l’association à l’aide d’une balise. Lors de la configuration de l’association (poignées de main à 4 voies), deux points de terminaison SCTP échangent leurs propres balises pour recevoir des paquets. Lors de l’établissement de liaison à 4 voies, le destinataire de INIT/INIT-ACK enregistre la valeur de itag et place dans le champ vtag de chaque paquet SCTP transmis au sein de cette association. Ensuite, l’homologue utilise le vtag pour valider l’expéditeur de ce paquet.
Flux de sessions créés après CP-Lite comme suit :
SPU est sélectionné par hash(tag), le trafic client-serveur est traité sur le SPU de hachage (tagB) puis transféré au SPU de hachage (tagA). Le trafic serveur-client est traité directement sur le hachage (tagA) SPU.
Après réception du paquet INIT, sur le hachage (tagA) SPU :
DCP-session A1 : client=> serveur, SCTP, ID Conn : 0x0 ;
Session A1 : client=> serveur, SCTP, ID Conn : 0x0 ;
Sur le hachage (tagB) SPU : pas de session.
Après réception du paquet INIT-ACK, sur le hash (tagA) SPU :
DCP-session A1 : client=> serveur, SCTP, ID Conn : 0x0 ;
DCP-session A2 : serveur => client, SCTP, ID Conn : tagA ;
Session A1 : client=> serveur, SCTP, ID Conn : 0x0 ;
Session A2 : serveur => client, SCTP, ID Conn : tagA ;
Sur le hachage (tagB) SPU : pas de session.
Après réception du paquet COOKIE-ECHO, sur le hash (tagA) SPU :
DCP-session A1 : client=> serveur, SCTP, ID Conn : 0x0 ;
DCP-session A2 : serveur => client, SCTP, ID Conn : tagA ;
Session A1 : client=> serveur, SCTP, ID Conn : 0x0 ;
Session A2 : serveur => client, SCTP, ID Conn : tagA ;
Session A3 : client=> serveur, SCTP, ID Conn : tagB ;
Sur le hash (tagB) SPU :
DCP-session : client = > serveur, SCTP, ID de connexion : balise B
Une fois le paquet COOKIE-ACK reçu, les sessions de flux ne sont pas modifiées.
Une fois l’établissement de liaison réussi, HEARBEAT sera envoyé sur tous les chemins.
Présentation de l’option de filtre de connexion de session de flux
Le tuple de connexion de session de flux consiste en une balise de connexion de 32 bits utilisée pour identifier de manière unique les sessions GTP-U et les sessions SCTP qui ne peuvent pas être distinguées par le n-uplet en six parties uniquement. Vous pouvez configurer le système pour inclure le tuple de balise de connexion de session afin d’identifier les sessions GTP-U et les sessions SCTP en ajoutant la balise de connexion de session aux six tuples standard qui identifient une session. Le système détermine le DCP pour GTP-U/SCTP en hachant la balise de connexion de session.
L’architecture centrale distribue le trafic GTP-U géré par une passerelle GGSN (GPRS support node) et une paire SGSN sur toutes les SPU en passant à une distribution de hachage basée sur l’identifiant de point de terminaison de tunnel (TEID). Pour gérer les problèmes d’équilibrage de charge, la distribution de hachage basée sur les balises garantit une répartition uniforme du trafic SCTP provenant de différentes associations entre toutes les SPU. (La balise de connexion pour GTP-U est le TEID et pour SCTP est le vTag.)
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.