Présentation de l’architecture de point central dans les équipements de sécurité
Le point central délègue le traitement des sessions à l’un des SPU. Lorsqu’une session n’est pas établie, le point central sélectionne un 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’USP qui l’héberge.
Comprendre l’architecture des pare-feu SRX Series
L’architecture à point central (CP) possède 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 du point central est implémentée soit en mode centrique, dans lequel toute la distribution et l’appariement des sessions sont effectués 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é du 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 un 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’USP 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 contenant des informations sur l’USP 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 du 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 l’évolutivité 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 Tableau 1 identifie l’implémentation de l’architecture de point central prise en charge sur les pare-feu SRX Series pour différentes versions.
Mode pris en charge sur SRX1400 |
Mode pris en charge sur la gamme SRX3000 |
Mode pris en charge sur la gamme SRX5000 |
|
|---|---|---|---|
Junos OS Release 12.3X48 and Previous Releases |
|
|
|
|
Ces pare-feu SRX Series ne sont plus pris en charge. |
Ces pare-feu SRX Series ne sont plus pris en charge. |
Note:
NG-SPC rend le mode combo obsolète. |
Junos OS Release 15.1X49-D30 and later releases |
Ces pare-feu SRX Series ne sont plus pris en charge. |
Ces pare-feu SRX Series ne sont plus pris en charge. |
Note:
NG-SPC rend le mode mixte obsolète. |
Le point central transmet un paquet à son unité de traitement des services (SPU) lors de la mise en correspondance des sessions, ou distribue le trafic vers une SPU pour le traitement de la sécurité si le paquet ne correspond à aucune session existante. L’architecture du point central est implémentée en mode CP centré, dans lequel toute la distribution et l’appariement des sessions sont effectués par le CP ou en mode combo
Sur certains pare-feu SRX Series, il n’est pas possible de dédier l’intégralité d’un SPU à la fonctionnalité de point central, mais un certain pourcentage de SPU est automatiquement alloué à la fonctionnalité de point central et le reste est alloué au traitement de flux normal. Lorsqu’une SPU remplit la fonction de point central ainsi que le traitement de flux normal, on dit qu’elle est en combinaison, ou mixed, en mode.
Le pourcentage de SPU dédié à 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 de 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é du point central. En mode mixte, le point central et l’unité de distribution partagent la même infrastructure LBT (Load-Balancing Thread) et 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 SPU (pour la distribution de charge) qui répertorie les SPU actifs avec les ID SPU logiques mappés au mappage physique des adresses TNP (Trivial Network Protocol). En mode mixte, l’USP qui héberge le point central est incluse dans la table. L’algorithme de répartition de la charge est ajusté en fonction de la capacité et de la puissance de traitement des sessions 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 d’un 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.
Un SPU dispose de plusieurs cœurs (CPU) pour le traitement réseau. En mode mixte SPU « petit », la fonctionnalité CPU prend une petite partie des cœurs, tandis qu’en mode mixte SPU « moyen » nécessite une plus grande partie de cœurs. La puissance de traitement pour les fonctionnalités du point central et le traitement des flux est partagée, en fonction du nombre de cartes de traitement des services (SPC), comme indiqué dans le tableau 2. La prise en charge de la plate-forme dépend de la version de Junos OS de 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 |
|---|---|---|---|---|
SRX1400 |
Petit |
Douleur moyenne |
NA |
NA |
SRX3400 |
Petit |
Douleur moyenne |
NA |
NA |
SRX3600 |
Petit |
Douleur moyenne |
NA |
NA |
SRX3400 (licence de performances et de capacité étendues) |
Petit |
Grand |
NA |
NA |
SRX3600 (licence de performances et de capacité étendues) |
Petit |
Grand |
NA |
NA |
SRX5600 |
Grand |
Grand |
Douleur moyenne |
Grand |
SRX5800 |
Grand |
Grand |
Douleur moyenne |
Grand |
SRX5400 |
Grand |
Grand |
Douleur moyenne |
Grand |
Le traitement en mode mixte n’existe qu’avec SPCI sur les appareils SRX1400, SRX3400, SRX3600 et Gamme SRX5000.
Présentation des améliorations apportées à l’architecture des points centraux pour la ligne SRX5000
Auparavant, pour la gamme SRX5000 de passerelles de services, le point central était un goulot d’étranglement dans les performances et l’évolutivité des appareils. Lorsque davantage de cartes de traitement de services (SPC) ont été intégrées dans le système, la puissance de traitement globale a augmenté de manière linéaire, mais les connexions système par seconde (cps) sont restées constantes et n’ont pas pu être améliorées en raison du point centralisé unique dans le système. Cela a eu de graves répercussions sur l’utilisation globale du système, tant en termes de capacité que de cps.
À partir de Junos OS version 15.1X49-D30 et Junos OS version 17.3R1, sur les équipements de la gamme SRX5000, l’architecture du point central a été améliorée pour gérer des connexions par seconde (cps) plus élevées. La nouvelle architecture du point central empêche les paquets de données de passer par le point central en déchargeant les fonctionnalistes de gestion des sessions vers 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’USP au lieu de passer par le point central.
L’architecture du point central est divisée en deux modules, le point central de l’application et le point central distribué. Le point central de l’application est responsable de la gestion globale des ressources et de l’équilibrage de charge, tandis que le point central distribué est responsable de l’identification du trafic (correspondance de session globale). La fonctionnalité de point central de l’application s’exécute sur le SPU de point central dédié, tandis que la fonctionnalité de point central distribué est distribuée au reste des SPU. Désormais, les sessions du point central ne se trouvent plus sur le SPU du point central dédié, mais avec un point central distribué 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é USP).
Le log SNMP et l’interruption SNMP ont été 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 le SPU ou le point central. Comme il y a plusieurs 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. Ainsi, si le CPS n’est pas constant, le nombre de CPS déclarés est inexact.
Présentation des améliorations des performances de limite de session de point central
À partir de Junos OS 15.1X49-D70 et Junos OS version 17.3R1, une nouvelle option de balise de connexion de session (conn-tag) est disponible pour vous permettre d’ajouter un filtre de flux afin de mieux distinguer les sessions de flux du protocole de tunnelisation GRPS, les sessions de flux de plan utilisateur (GTP-U) et les sessions de flux SCTP (Stream Control Transmission Protocol).
Le tuple de connexion de session de flux se compose d’une balise de connexion 32 bits qui est utilisée pour identifier de manière unique les sessions GTP-U et les sessions SCTP qui ne peuvent pas être distinguées uniquement par le tuple en six parties. 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 du point central répartit le trafic GTP-U géré par une passerelle, un nœud de support GPRS (GGSN) 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, une distribution de hachage basée sur les balises est utilisée pour assurer une distribution 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 Central Point pour GTP et SCTP
À partir de Junos OS version 15.1X49-D40 et Junos OS version 17.3R1, l’architecture de point central offre une prise en charge améliorée du protocole de tunnelisation GPRS, du 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 du point central, qui est prise en charge sur les périphériques SRX5400, SRX5600 et SRX5800, a été améliorée pour prendre en charge la limitation du débit des messages GTP-C afin de protéger le nœud de support GPRS de passerelle (GGSN) du flooding de messages GTP-C, d’éviter les problèmes d’abandon 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.
L’ajout d’une balise de connexion au tuple de session de flux est introduit pour résoudre le problème d’équilibrage de charge GTP/SCTP. Toutes les sessions, y compris les sessions CP distribuées (DCP) et les sessions SPU, sont modifiées pour s’adapter à la balise de connexion. Les sessions de création ont les tuples suivants : src-ip, dst-ip, src-port, dst-port, protocol, session-token et connection tag.
L’ALG GTP nécessite que les sessions GTP-C soient corrigées par hachage des 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 éviter l’abandon 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. Par la suite, l’adresse IP GGSN est déterminée à l’aide de l’unité SPU appropriée pour créer la session de flux et vieillir l’ancienne session. Les paquets intermittents arrivant sur l’ancienne session seront transférés à la nouvelle SPU et seront traités sur la nouvelle session.
Pour gérer les problèmes d’équilibrage de charge, une distribution de hachage basée sur des balises est utilisée pour assurer une répartition uniforme du trafic GTP-U/SCTP entre tous les SPU. Une balise de connexion 32 bits est introduite qui identifie 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éterminera la balise de connexion pour les sessions GTP-U/SCTP et les distribuera 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 (négociations à 4 voies), deux points de terminaison SCTP échangent leurs propres balises pour la réception des paquets. Lors d’une négociation à 4 voies, le récepteur d’INIT/INIT-ACK enregistre la valeur d’itag et la place dans le champ vtag de chaque paquet SCTP qui transmet au sein de cette association. Ensuite, l’homologue utilise le vtag pour valider l’expéditeur de ce paquet.
Sessions de flux créées après CP-Lite comme suit :
Le SPU est sélectionné par hash(tag), le trafic client-serveur est géré sur le SPU de hachage (tagB) puis transféré au SPU de hachage (tagA). Le trafic du serveur au client est géré directement par l’unité SPU de hachage (tagA).
Après réception du paquet INIT, sur le SPU de hachage (tagA) :
DCP-session A1 : client=> serveur, SCTP, ID de connexion : 0x0 ;
Session A1 : client=> serveur, SCTP, ID de connexion : 0x0 ;
Sur le SPU de hachage (tagB) : pas de session.
Après réception du paquet INIT-ACK, sur le SPU de hachage (tagA) :
DCP-session A1 : client=> serveur, SCTP, ID de connexion : 0x0 ;
DCP-session A2 : serveur => client, SCTP, ID de connexion : tagA ;
Session A1 : client=> serveur, SCTP, ID de connexion : 0x0 ;
Session A2 : serveur => client, SCTP, ID de connexion : tagA ;
Sur le SPU de hachage (tagB) : pas de session.
Après réception du paquet COOKIE-ECHO, sur le SPU de hachage (tagA) :
DCP-session A1 : client=> serveur, SCTP, ID de connexion : 0x0 ;
DCP-session A2 : serveur => client, SCTP, ID de connexion : tagA ;
Session A1 : client=> serveur, SCTP, ID de connexion : 0x0 ;
Session A2 : serveur => client, SCTP, ID de connexion : tagA ;
Session A3 : client=> serveur, SCTP, ID de connexion : tagB ;
Sur le SPU de hachage (tagB) :
DCP-session : client = serveur >, SCTP, ID de connexion : balise B
Après réception du paquet COOKIE-ACK, les sessions de flux ne sont pas modifiées.
Une fois la poignée de main réussie, HEARBEAT sera envoyé sur tous les chemins.
Présentation de l’option de filtre de connexion de session de flux
À partir de Junos OS 15.1X49-D70 et Junos OS version 17.3R1, une nouvelle option de balise de connexion de session (conn-tag) est disponible pour vous permettre d’ajouter un filtre de flux afin de mieux distinguer les sessions de flux du protocole de tunnelisation GRPS, les sessions de flux de plan utilisateur (GTP-U) et les sessions de flux SCTP (Stream Control Transmission Protocol).
Le tuple de connexion de session de flux se compose d’une balise de connexion 32 bits qui est utilisée pour identifier de manière unique les sessions GTP-U et les sessions SCTP qui ne peuvent pas être distinguées uniquement par le tuple en six parties. 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 du point central répartit le trafic GTP-U géré par une passerelle, un nœud de support GPRS (GGSN) 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, une distribution de hachage basée sur les balises est utilisée pour assurer une distribution 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.