Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Présentation du traitement du trafic sur les équipements SRX Series

Junos OS pour les équipements de sécurité intègre les fonctionnalités de sécurité et de routage du réseau de Juniper Networks. Les paquets entrants et sortants d’un équipement sont traités à la fois en fonction des paquets et des flux.

Comprendre le traitement du trafic sur les équipements de sécurité

Junos OS pour les équipements de sécurité intègre les capacités de routage et de sécurité réseau de pointe de Juniper Networks. Junos OS comprend un large éventail de filtrage basé sur les paquets, de classificateurs de classe de service (CoS) et de fonctionnalités de mise en forme du trafic, ainsi qu’un ensemble riche et complet de fonctionnalités de sécurité basées sur les flux, notamment des stratégies, des écrans, la traduction des adresses réseau (NAT) et d’autres services basés sur les flux.

Le trafic entrant et sortant d’un équipement de sécurité est traité en fonction des fonctionnalités que vous configurez, telles que les filtres de paquets, les stratégies de sécurité et les écrans. Par exemple, le logiciel peut déterminer :

  • Si le paquet est autorisé dans l’équipement

  • Quels écrans de pare-feu appliquer au paquet

  • Le chemin que prend le paquet pour atteindre sa destination

  • Quel CoS appliquer au paquet, le cas échéant

  • Appliquer le NAT pour traduire l’adresse IP du paquet

  • Si le paquet nécessite une passerelle de couche applicative (ALG)

Les paquets entrants et sortants d’un équipement sont traités à la fois en fonction des paquets et des flux :

  • Le traitement des paquets basé sur les flux traite les paquets associés, ou un flux de paquets, de la même manière. Le traitement des paquets dépend des caractéristiques établies pour le premier paquet du flux de paquets, appelé flux.

    Pour l’architecture de traitement distribué de la passerelle de services, tous les traitements basés sur les flux se produisent sur le SPU et l’échantillonnage est conscient du multi-thread. Le séquençage des paquets est maintenu pour les paquets échantillonnés.

  • Le traitement des paquets basé sur des paquets, ou sans état, traite les paquets de manière distincte. Chaque paquet est évalué individuellement pour le traitement.

    Pour l’architecture de traitement distribué de la passerelle de services, un traitement basé sur des paquets, comme la mise en forme du trafic, se fait sur le NPU. Certains traitements basés sur des paquets, comme l’application de classificateurs à un paquet, se produisent sur le SPU.

Cette rubrique comprend les sections suivantes :

Comprendre le traitement basé sur les flux

Un paquet subit un traitement basé sur les flux après que des filtres basés sur des paquets et certains écrans lui ont été appliqués. Tout le traitement basé sur les flux d’un seul flux s’effectue sur une seule unité de traitement des services (SPU). Un SPU traite les paquets d’un flux en fonction des fonctionnalités de sécurité et des autres services configurés pour la session.

La figure 1 présente une vue conceptuelle du traitement du trafic basé sur les flux sur les passerelles de services.

Figure 1 : Flux de trafic pour le traitement basé sur les flux Traffic Flow for Flow-Based Processing

Un flux est un flux de paquets associés qui répondent aux mêmes critères de correspondance et partagent les mêmes caractéristiques. Junos OS traite de la même manière les paquets appartenant au même flux.

Les paramètres de configuration qui déterminent le sort d’un paquet( par exemple la stratégie de sécurité qui s’applique à ce paquet, s’il nécessite une passerelle de couche application (ALG), si le NAT est appliqué pour traduire l’adresse IP source et/ou de destination du paquet, sont évalués pour le premier paquet d’un flux.

Pour déterminer s’il existe un flux pour un paquet, le NPU tente de faire correspondre les informations du paquet à celles d’une session existante en fonction des critères de correspondance suivants :

  • Adresse source

  • Adresse de destination

  • Port source

  • Port de destination

  • Protocole

  • Numéro de jeton de session unique pour une zone donnée et un routeur virtuel

Zones et stratégies

La stratégie de sécurité à utiliser pour le premier paquet d’un flux est mise en cache dans une table de flux pour une utilisation avec le même flux et des flux étroitement liés. Les stratégies de sécurité sont associées aux zones. Une zone est un ensemble d’interfaces qui définissent une limite de sécurité. La zone entrante d’un paquet, déterminée par l’interface par laquelle il est arrivé, et sa zone sortante, telle que déterminée par la recherche de transfert, déterminent ensemble la stratégie utilisée pour les paquets du flux.

Flux et sessions

Le traitement des paquets basé sur les flux, qui est à états, nécessite la création de sessions. Une session est créée pour le premier paquet d’un flux aux fins suivantes :

  • Pour stocker la plupart des mesures de sécurité à appliquer aux paquets du flux.

  • Pour mettre en cache des informations sur l’état du flux.

    Par exemple, la journalisation et le comptage des informations pour un flux sont mis en cache dans sa session. (Certains écrans de pare-feu à états s’appuient sur des valeurs seuils qui concernent les sessions individuelles ou sur toutes les sessions.)

  • Pour allouer les ressources requises au flux pour des fonctionnalités telles que nat.

  • Pour fournir une infrastructure pour des fonctionnalités telles que les ALG et les fonctionnalités de pare-feu.

La plupart du traitement des paquets s’effectue dans le contexte d’un flux, notamment :

  • Gestion des stratégies, du NAT, des zones et de la plupart des écrans.

  • Gestion des ALG et de l’authentification.

Comprendre le traitement basé sur les paquets

Un paquet subit un traitement basé sur les paquets lorsqu’il est retiré de la file d’attente sur son interface d’entrée et avant qu’il ne soit ajouté à la file d’attente sur son interface de sortie.

Le traitement basé sur les paquets applique des filtres de pare-feu sans état, des fonctionnalités CoS et certains écrans à des paquets distincts.

  • Lorsqu’un paquet arrive à une interface, des vérifications de intégrité, des filtres basés sur les paquets, certaines fonctionnalités CoS et certains écrans sont appliqués.

  • Avant qu’un paquet ne quitte l’équipement, les filtres basés sur les paquets, certaines fonctionnalités CoS et certains écrans associés à l’interface sont appliqués au paquet.

Les filtres et les fonctionnalités CoS sont généralement associés à une ou plusieurs interfaces afin d’influencer les paquets autorisés à transiter par le système et d’appliquer des actions spéciales aux paquets si nécessaire.

Les sujets suivants décrivent les types de fonctionnalités basées sur les paquets que vous pouvez configurer et appliquer au trafic de transit.

Filtres de pare-feu sans état

Aussi appelés listes de contrôle d’accès (ACL), les filtres de pare-feu sans état contrôlent l’accès et limitent les débits de trafic. Ils évaluent statiquement le contenu des paquets transitant par l’équipement d’une source vers une destination, ou des paquets provenant du moteur de routage ou à destination du moteur de routage. Un filtre de pare-feu sans état évalue chaque paquet, y compris les paquets fragmentés.

Vous pouvez appliquer un filtre de pare-feu sans état à une interface d’entrée ou de sortie, ou aux deux. Un filtre contient un ou plusieurs termes, et chaque terme se compose de deux composants: correspondent aux conditions et aux actions. Par défaut, un paquet qui ne correspond pas à un filtre de pare-feu est jeté.

Vous pouvez planifier et concevoir des filtres de pare-feu sans état qui seront utilisés à diverses fins, par exemple pour limiter le trafic à certains protocoles, adresses ip source ou de destination, ou débits de données. Les filtres de pare-feu sans état sont exécutés sur le NPU.

Fonctionnalités de classe de service

Les fonctionnalités CoS vous permettent de classer et de modeler le trafic. Les fonctionnalités CoS sont exécutées sur le NPU.

  • Classificateurs d’agrégation de comportement (BA) : ces classificateurs fonctionnent sur les paquets à l’entrée de l’équipement. À l’aide de classificateurs d’agrégation de comportement, l’équipement agrège différents types de trafic en une seule classe de transfert pour recevoir le même traitement de transfert. Les classificateurs BA vous permettent de définir la classe de transfert et la priorité de perte d’un paquet en fonction de la valeur du service différencié (DiffServ).

  • Mise en forme du trafic : vous pouvez définir le trafic en affectant des niveaux de service avec différentes caractéristiques de retard, de gigue et de perte de paquets à des applications particulières desservies par des flux de trafic spécifiques. La mise en forme du trafic est particulièrement utile pour les applications en temps réel, telles que la transmission vocale et vidéo.

Écrans

Certains écrans, tels que les écrans de déni de service (DoS), sont appliqués à un paquet en dehors du processus de flux. Ils sont exécutés sur l’unité de traitement du réseau (NPU).

Comprendre le comportement de traitement par défaut du trafic IPv4

Le mode de traitement basé sur les flux est requis pour que les fonctionnalités de sécurité telles que les zones, les écrans et les stratégies de pare-feu fonctionnent. Par défaut, l’équipement SRX Series est activé pour le transfert basé sur les flux pour le trafic IPv4 sur tous les équipements, à l’exception des équipements SRX300 Series et SRX550M qui sont configurés en mode drop. À partir de Junos OS version 15.1X49-D70 et Junos OS version 17.3R1, pour les équipements SRX1500 Series, SRX4100, SRX4200, SRX5400, SRX5600, SRX5800 et vSRX, vous n’avez pas besoin de redémarrer l’équipement lorsque vous passez des modes de flux à paquets et en mode drop. Pour les équipements SRX300 Series et SRX550M, vous devez redémarrer l’équipement lors de la commutation entre le mode flux, le mode paquet et le mode drop.

SRX300 Series and SRX550M

Pour les équipements SRX300 Series et SRX550M, le mode de traitement par défaut est défini en mode drop en raison de contraintes de mémoire. Dans ce cas, vous devez redémarrer l’équipement après avoir changé le mode de traitement du mode de chute par défaut au mode de traitement basé sur les flux ou en mode de traitement basé sur les paquets, c’est-à-dire entre les modes sur ces équipements.

Note:

Pour le traitement en mode drop, le trafic est directement supprimé, il n’est pas transféré. Il diffère du traitement en mode paquet pour lequel le trafic est géré, mais aucun processus de sécurité n’est appliqué.

Configuring an SRX Series Device as a Border Router

Lorsqu’un équipement SRX Series de n’importe quel type est activé pour le traitement basé sur les flux ou le mode drop, pour configurer l’équipement en tant que routeur de bordure, vous devez changer le mode de traitement basé sur les paquets pour MPLS. Dans ce cas, pour configurer l’équipement SRX en mode paquet pour MPLS, utilisez l’instruction set security forwarding-options family mpls mode packet-based .

Note:

Comme mentionné précédemment, pour les équipements SRX300 Series et SRX550M, chaque fois que vous changez de mode de traitement, vous devez redémarrer l’équipement.

Comprendre le traitement du trafic sur les équipements SRX210 et SRX320

Cette rubrique décrit le processus que les passerelles de services SRX210 et SRX320 entreprennent pour établir une session pour les paquets appartenant à un flux qui transite par l’équipement. Les services de flux des équipements SRX210 et SRX320 sont à thread unique et non distribués. Bien qu’ils diffèrent des autres équipements SRX Series à cet égard, le même modèle de flux est suivi et la même interface de ligne de commande (CLI) est implémentée.

Pour illustrer l’établissement de session et la « marche » des paquets, y compris les points auxquels les services sont appliqués aux paquets d’un flux, l’exemple décrit dans les sections suivantes utilise le cas simple d’une session unicast :

Comprendre le traitement des flux et la gestion des sessions

Cette rubrique explique comment une session est configurée pour traiter les paquets composant un flux. Dans la rubrique suivante, le SPU fait référence au thread de plan de données de la passerelle de services SRX210 ou SRX320.

Au début, le thread du plan de données récupère le paquet et effectue des vérifications basiques de l’intégrité. Ensuite, il traite le paquet pour les filtres sans état et les classificateurs CoS et applique certains écrans.

Comprendre le traitement des premiers paquets

Pour déterminer si un paquet appartient à un flux existant, l’équipement tente de faire correspondre les informations du paquet à celles d’une session existante en fonction des six critères de correspondance suivants :

  • Adresse source

  • Adresse de destination

  • Port source

  • Port de destination

  • Protocole

  • Jeton unique d’une zone donnée et routeur virtuel

Le SPU vérifie dans sa table de session une session existante pour le paquet. Si aucune session n’est trouvée, le SPU configure une session pour le flux. Si une correspondance de session est trouvée, la session a déjà été créée, de sorte que le SPU effectue un traitement de chemin rapide sur le paquet.

Comprendre la création de sessions

Lors de la configuration de la session, le SPU exécute les services suivants pour le paquet :

  • Écrans

  • Recherche de routage

  • Recherche de stratégies

  • Recherche de services

  • NAT, si nécessaire

Une fois qu’une session est configurée, elle est utilisée pour tous les paquets appartenant au flux. Les paquets d’un flux sont traités en fonction des paramètres de sa session. Pour les autres étapes du traitement des paquets, passez à l’étape 1 de « Fast-Path Processing ». Tous les paquets sont traités rapidement.

Comprendre le traitement rapide

Si un paquet correspond à une session, Junos OS effectue un traitement de chemin rapide comme décrit dans les étapes suivantes. Une fois qu’une session a été configurée pour le premier paquet d’un flux, elle subit également un traitement de chemin rapide. Tous les paquets sont traités rapidement.

  1. Le SPU applique des fonctionnalités de sécurité basées sur les flux au paquet.

    • Les écrans configurés sont appliqués.

    • Des vérifications TCP sont effectuées.

    • Des services de flux, tels que NAT, ALG et IPsec, sont appliqués, si nécessaire.

  2. Le SPU prépare le paquet pour le transfert et le transmet.

    • Des filtres de paquets de routage sont appliqués.

    • La mise en forme du trafic est appliquée.

    • La hiérarchisation du trafic est appliquée.

    • La planification du trafic est appliquée.

    • Le paquet est transmis.

Comprendre le traitement du trafic sur les équipements SRX3000 Line et SRX1400

Junos OS pour les passerelles de services SRX1400, SRX3400 et SRX3600 intègre les capacités de routage et de sécurité réseau de classe mondiale de Juniper Networks. Junos OS pour ces passerelles de services comprend la large gamme de services de sécurité, y compris les stratégies, les écrans, la traduction d’adresses réseau, les classificateurs de classe de service et l’ensemble riche et complet de services basés sur les flux qui sont également pris en charge sur les autres équipements des passerelles de services.

L’architecture de traitement parallèle distribuée des équipements SRX1400, SRX3400 et SRX3600 comprend plusieurs processeurs pour gérer les sessions et exécuter le traitement de la sécurité et d’autres services. Cette architecture offre une plus grande flexibilité et permet un débit élevé et des performances rapides.

Les sections suivantes décrivent l’architecture de traitement utilisant les équipements SRX3400 et SRX3600 comme exemple :

Cette rubrique comprend les informations suivantes :

Composants impliqués dans la configuration d’une session

Voici une présentation des principaux composants impliqués dans la configuration d’une session pour un paquet et le traitement des paquets lors de leur transit par les équipements SRX3400 et SRX3600 :

  • Unités de traitement de services (SPU) : les principaux processeurs des équipements SRX3400 et SRX3600 résident sur des cartes de traitement de services (SPC). Ils établissent et gèrent les flux de trafic et effectuent la plupart du traitement des paquets sur un paquet pendant qu’il transite par l’équipement. Chaque SPU conserve une table de hachage pour une recherche rapide des sessions. Le SPU effectue tous les traitements basés sur les flux pour un paquet, y compris l’application de services de sécurité, de classificateurs et de shapers de trafic. Tous les paquets appartenant au même flux sont traités par le même SPU.

    Le SPU gère une table de sessions avec des entrées pour toutes les sessions qu’il a établies et dont il traite les paquets. Lorsqu’un SPU reçoit un paquet d’un NPU, il vérifie sa table de session pour s’assurer qu’il lui appartient.

    Pour les équipements SRX3400 et SRX3600, un SPU agit de concert en exécutant ses fonctions régulières de gestion des sessions et de traitement des flux, et agissant comme un point central dans lequel il arbitre les sessions et alloue des ressources. Lorsqu’un SPU fonctionne de cette manière, on dit qu’il est en mode combo.

  • Point central : le point central est utilisé pour allouer la gestion des sessions aux SPU en fonction de critères d’équilibrage de charge. Il distribue les sessions de manière intelligente afin d’éviter les événements dans lesquels plusieurs SPUs peuvent gérer à tort le même flux. Le point central suit les critères d’équilibrage de charge lors de l’attribution des sessions aux SPU. Si la session existe, le point central transfère les paquets pour ce flux vers le SPU qui l’héberge. Il redirige également les paquets vers le bon SPU si le NPU ne le fait pas.

    Pour les équipements SRX3400 et SRX3600, un SPU s’exécute toujours en mode combo dans lequel il implémente à la fois les fonctionnalités du point central et la fonctionnalité de gestion des flux et des sessions. En mode combo, le SPU et le point central partagent la même infrastructure de thread d’équilibrage de charge (LBT) et de thread de commande de paquets (POT). .

  • Moteur de routage (RE) : le moteur de routage exécute le plan de contrôle et gère le processeur du plan de contrôle (CPP).

Comprendre le chemin des données pour les sessions unicast

Junos OS pour les passerelles de services SRX3400 et SRX3600 est un système distribué de traitement parallèle haut débit et hautes performances. Cette rubrique décrit le processus d’établissement d’une session pour les paquets appartenant à un flux qui transite par l’équipement.

Pour illustrer l’établissement des sessions et la « marche » des paquets, y compris les points auxquels les services sont appliqués aux paquets d’un flux, l’exemple suivant utilise le cas simple d’une session unicast. Cette « marche » des paquets réunit le traitement basé sur les paquets et le traitement basé sur les flux que Junos OS effectue sur le paquet.

Critères de recherche de session et de correspondance des paquets

Pour déterminer si un paquet appartient à un flux existant, l’équipement tente de faire correspondre les informations du paquet à celles d’une session existante en fonction des six critères de correspondance suivants :

  • Adresse source

  • Adresse de destination

  • Port source

  • Port de destination

  • Protocole

  • Jeton unique d’une zone donnée et routeur virtuel

Comprendre la création de session : premier traitement des paquets

Cette rubrique explique comment une session est configurée pour traiter les paquets composant un flux. Pour illustrer le processus, cette rubrique utilise un exemple avec une source « a » et une destination « b ». La direction de la source à la destination des paquets du flux est appelée (a -> b). La direction de la destination à la source est appelée (b -> a).

  1. Un paquet arrive à une interface sur l’équipement et l’IOC le traite.

    L’IOC décerle le paquet et l’envoie au NPU avec lequel il communique.

  2. Le NPU reçoit le paquet de l’IOC et le traite.

    • Le NPU effectue des vérifications basiques de l’intégrité du paquet et applique certains écrans configurés pour l’interface au paquet.

    • Si une correspondance de session est trouvée, la session a déjà été créée sur un SPU qui lui a été assigné, de sorte que le NPU transfère le paquet au SPU pour traitement avec l’ID de session.

    Exemple : Packet (a ->b) arrive au NPU1 depuis IOC1. NPU1 effectue des vérifications de intégrité et applique des écrans DoS au paquet. NPU1 vérifie la correspondance de sa table de session et ne trouve aucune session existante. NPU1 transfère le paquet au point central du SPU1 pour l’affecter à un SPU.

  3. Le point central crée une session avec un état « En attente ».

    Le point central gère une table de session globale qui inclut les entrées pour toutes les sessions qui existent sur tous les SPU de l’équipement. Il participe à la création des sessions et délègue et arbitre l’allocation des ressources de session.

    Ce processus comprend les éléments suivants :

    1. Le point central vérifie sa table de sessions et sa table de porte pour déterminer s’il existe une session ou une porte pour le paquet qu’il reçoit du NPU. (Un NPU a transféré un paquet vers le point central car sa table indique qu’il n’y a pas de session pour lui. Le point central vérifie ces informations avant d’allouer un SPU à la session.)

    2. S’il n’y a pas d’entrée correspondant au paquet dans l’une ou l’autre table, le point central crée une aile en attente pour la session et sélectionne un SPU à utiliser pour la session, en fonction de son algorithme d’équilibrage de charge.

    3. Le point central transfère le premier paquet du flux au SPU sélectionné dans un message lui demandant de configurer localement une session à utiliser pour le flux de paquets.

      Exemple : le point central crée une aile en attente (un ->b) pour la session. Il sélectionne le SPU1 à utiliser pour la session. Il envoie au SPU1 le paquet (a->b) ainsi qu’un message pour créer une session pour lui. (Il se trouve que SPU1 est le SPU qui s’exécute en mode combo. Par conséquent, ses services de gestion des sessions et de traitement des flux sont utilisés pour la session.

  4. Le SPU configure la session.

    Chaque SPU dispose également d’une table de session qui contient des informations sur ses sessions. Lorsque le SPU reçoit un message du point central pour configurer une session, il vérifie sa table de session pour s’assurer qu’une session n’existe pas déjà pour le paquet.

    1. S’il n’y a pas de session existante pour le paquet, le SPU configure la session localement.

    2. Le SPU envoie un message au point central pour lui dire d’installer la session.

    Lors du premier traitement des paquets, si le NAT est activé, le SPU alloue des ressources d’adresse IP pour nat. Dans ce cas, le traitement du premier paquet pour la session est suspendu jusqu’à ce que le processus d’allocation NAT soit terminé.

    Le SPU ajoute à la file d’attente tous les paquets supplémentaires pour le flux qu’il pourrait recevoir jusqu’à ce que la session ait été installée.

    Exemple : le SPU1 crée la session pour (un ->b) et envoie un message au point central (implémenté sur le même SPU) lui demandant d’installer la session en attente.

  5. Le point central installe la session.

    • Il définit l’état d’activité de l’aile en attente de la session.

    • Il installe l’aile arrière pour la session en tant qu’aile active.

    • Il envoie un message ACK (accuser réception) au SPU, indiquant que la session est installée.

    Exemple : le point central reçoit un message du SPU1 pour installer la session pour (a->b). Il définit l’état de session pour que l’aile (a->b) soit active. Il installe l’aile arrière (b->a) pour la session et le rend actif; cela permet de livrer les paquets depuis le sens inverse du flux : destination (b) à livrer à la source (a).

  6. Le SPU configure la session sur les NPU entrants et sortants.

    Les NPU conservent des informations sur une session pour le transfert et la distribution de paquets. Les informations de session sont configurées sur les NPU sortants et entrants (qui sont parfois les mêmes), de sorte que les paquets peuvent être envoyés directement au SPU qui gère leurs flux et non au point central pour la redirection.

  7. Le traitement des chemins rapides est effectué.

    Pour les autres étapes du traitement des paquets, passez à l’étape 1 de « Comprendre le traitement rapide ».

Comprendre le traitement rapide

Tous les paquets sont traités rapidement. Toutefois, si une session existe pour un paquet, le paquet subit un traitement de chemin rapide et contourne le processus de premier paquet. Lorsqu’il y a déjà une session pour le flux du paquet, le paquet ne transite pas par le point central.

Voici comment fonctionne le traitement de chemin rapide : les NPU des interfaces de sortie et d’entrée contiennent des tables de session qui comprennent l’identification du SPU qui gère le flux d’un paquet. Étant donné que les NPU disposent de ces informations de session, tout le trafic du flux, y compris le trafic inverse, est envoyé directement à ce SPU pour traitement.

Sur les équipements SRX1400, SRX3400 et SRX3600, la fonctionnalité iflset n’est pas prise en charge pour les interfaces agrégées comme reth.

Comprendre le traitement du trafic sur les équipements SRX4600

La passerelle de services SRX4600 de Juniper Networks intègre des services de sécurité et de routage basés sur les flux, y compris la sécurité avancée et l’atténuation des menaces, ainsi que la sécurité traditionnelle à états pare-feu. L’infrastructure basée sur les flux Junos OS fournit la base et l’infrastructure pour les services basés sur les applications de couche 4 à 7. La passerelle de services SRX4600 est conçue pour être déployée en tant que pare-feu intégré à la périphérie et au cœur du centre de données des grandes entreprises, ainsi qu’à la périphérie du campus. Il peut également être déployé en tant que passerelle de sécurité LTE et pare-feu Gi/SGi.

Cette rubrique comprend le contenu suivant :

Présentation des scénarios de déploiement de la passerelle de services SRX4600 et de ses fonctionnalités

La passerelle de services SRX4600 peut être déployée dans de nombreux domaines pour sécuriser votre environnement et ses ressources. Il est souvent utilisé pour protéger la périphérie et le cœur du centre de données des manières suivantes :

  • Déploiement de la passerelle de services SRX4600 en tant que pare-feu de périphérie de centre de données

    Vous pouvez déployer la passerelle de services SRX4600 en périphérie de votre centre de données pour offrir aux applications et services qu’elle héberge une protection optimale. Chaque centre de données dispose d’un point d’entrée permettant aux clients d’accéder aux services du centre de données, mais les agresseurs malveillants peuvent en tirer parti pour lancer des attaques contre ces services. Une grande quantité de trafic entrant dans le centre de données est le trafic Internet entrant. C’est pourquoi il est essentiel de déployer une sécurité robuste et multicouche à la périphérie du centre de données. La passerelle de services SRX4600 bloque efficacement et en toute sécurité les attaques, et vous permet de configurer le système pour déjouer des types d’attaques spécifiques. La passerelle de services SRX4600 prend en charge le framework SDSN (Software-Defined Secure Network) de Juniper, y compris Sky Advanced Threat Prevention (Sky ATP), qui repose sur des informations automatisées et exploitables qui peuvent être partagées rapidement pour détecter et atténuer les menaces. La figure 2 montre la passerelle de services SRX4600 déployée en périphérie du centre de données en conjonction avec un routeur MX480 et des commutateurs EX Series.

    Figure 2 : Déploiement de la passerelle de services SRX4600 à la périphérie Deploying the SRX4600 Services Gateway at the Data Center Edge du centre de données
  • Déploiement de la passerelle de services SRX4600 au cœur du centre de données

    Vous pouvez déployer la passerelle de services SRX4600 au cœur du centre de données pour renforcer la sécurité et garantir le respect des exigences de conformité. Le traitement des centres de données est devenu de plus en plus dynamique, ce qui nécessite une définition claire du réseau et une application des exigences de conformité. Pour garantir la conformité, vous pouvez utiliser la passerelle de services SRX4600 pour segmenter l’ensemble de votre réseau en réseaux de serveurs individuels et sécuriser le trafic qui les contient. La passerelle de services SRX4600 offre une haute disponibilité et une automatisation, et ses services de couche 3 et 4 hautes performances répondent aux exigences de sécurité du centre de données. La figure 3 montre la passerelle de services SRX4600 déployée en tant que pare-feu multicouche au cœur du centre de données.

    Figure 3 : Déploiement de la passerelle de services SRX4600 au cœur Deploying the SRX4600 Services Gateway at the Data Center Core du centre de données

Outre ses fonctionnalités anti-malware avancées, la passerelle de services SRX4600 prend en charge les fonctionnalités suivantes :

  • Pare-feu dynamique

  • Suite de sécurité des applications

  • UTM (antivirus Sophos, filtrage Web, antispam)

  • IDP

  • Haute disponibilité (cluster châssis)

    • Double port de contrôle HA (10G)

    • Prise en charge MACsec des ports HA

  • Interfaces Ethernet via QSFP28 (modes 100G/40G/4x10G), QSFP+ (modes 40G/4x10G) et SFP+ (mode 10G)

  • VPN IPsec, y compris AutoVPN et VPNv2 de groupe

  • QoS et services réseau

  • J-Web

  • Stratégies de routage avec multicast

Traitement basé sur les flux et principes fondamentaux des sessions

Pour comprendre le traitement des flux sur la passerelle de services SRX4600, il est important de comprendre les principes fondamentaux du flux.

Un flux est un flux de paquets associés qui répondent aux mêmes critères de correspondance et partagent les mêmes caractéristiques. Junos OS traite de la même manière les paquets qui appartiennent au même flux. L’architecture d’une passerelle de services SRX Series et la façon dont elle gère les flux de paquets sont étroitement couplées. Par conséquent, en partie, les flux sont implémentés différemment dans la famille des passerelles de services SRX Series en raison de leurs différences architecturales.

Le traitement des paquets basé sur les flux, qui est à états, nécessite la création de sessions. Les sessions sont créées à partir du routage et d’autres informations de classification du trafic pour stocker des informations et allouer des ressources pour un flux. Les sessions cachent des informations sur l’état du flux et stockent la plupart des mesures de sécurité à appliquer aux paquets du flux. En raison des différences architecturales entre les équipements, les sessions sont également gérées différemment par différents équipements.

Indépendamment de ces différences, le processus de flux est théoriquement le même dans toutes les passerelles de services, et les sessions servent les mêmes objectifs et disposent des mêmes fonctionnalités.

Composants sous-jacents de flux et de session implémentés sur les passerelles de services SRX Series

Les passerelles de services SRX Series utilisent les mêmes composants d’infrastructure pour prendre en charge les flux et gérer les sessions, mais tous les équipements ne les implémentent pas tous.

Pour comprendre les flux, il est essentiel de comprendre les composants suivants et comment ils sont utilisés :

  • L’unité de traitement des services (SPU)

    Un SPU gère la session pour un flux de paquets. Il applique des fonctionnalités de sécurité et d’autres services au paquet. Il applique également des filtres de pare-feu sans état basés sur les paquets, des classificateurs et des shapeurs de trafic au paquet.

  • Le point central (CP)

    Le point central est un SPU que le système utilise pour allouer des ressources et distribuer la gestion des sessions entre les SPU. Lorsque le premier paquet d’un flux est traité, le point central détermine le SPU à utiliser pour la session de ce paquet. La passerelle de services SRX4600 n’implémente pas de point central.

  • L’unité de traitement du réseau (NPU) et la session de traitement du réseau

    Un NPU est un processeur qui s’exécute sur une carte d’E/S (IOC) et traite les paquets séparément. Lorsqu’un flux est créé, les paquets suivants du flux sont mis en correspondance avec la session sur le NPU. Le NPU gère des traitements supplémentaires tels que la vérification de la séquence TCP, le traitement TTL (time-to-live) et la traduction des en-têtes de couche 2. Un NPU améliore les performances afin d’éviter le transfert de paquets supplémentaire entre un SPU de session et un SPU de hachage. La passerelle de services SRX4600 implémente un NPU.

L’architecture de flux de la passerelle de services SRX4600 a été améliorée pour optimiser l’utilisation des processeurs Xeon multicœurs™ avancés de l’équipement SRX4600. La passerelle de services SRX4600 implémente l’utilisation d’un thread de session dédié pour contourner des problèmes tels que la gestion des paquets en panne dans un flux. Il utilise la session de traitement du réseau pour s’assurer que les paquets sont transférés vers le thread dédié de droite. Les paquets sont distribués sur différents threads conformément au modèle de distribution de session basé sur le hachage.

Comprendre le traitement du trafic sur les équipements de la ligne SRX5000

Junos OS sur les équipements SRX5000 est un système distribué, parallèle, haut débit et hautes performances. L’architecture de traitement parallèle distribuée de la gamme de passerelles de services SRX5000 comprend plusieurs processeurs pour gérer les sessions et exécuter la sécurité et d’autres services de traitement. Cette architecture offre une plus grande flexibilité et permet un débit élevé et des performances rapides.

Note:

Dans les équipements SRX1400, SRX3400, SRX3600, SRX5400, SRX5600 et SRX5800, les négociations IKE impliquant nat traversal ne fonctionnent pas si l’homologue IKE est derrière un équipement NAT qui va changer l’adresse IP source des paquets IKE pendant la négociation. Par exemple, si l’équipement NAT est configuré avec dip, il modifie l’ADRESSE IP source car le protocole IKE fait passer le port UDP de 500 à 4 500.

Les cartes d’E/S (IOC) et les cartes de traitement des services (SPC) sur les équipements de la gamme SRX5000 contiennent des unités de traitement qui traitent un paquet pendant qu’il traverse l’équipement. Un IOC dispose d’une ou plusieurs unités de traitement du réseau (NPU) et d’un SPC d’une ou plusieurs unités de traitement des services (SPU).

Ces unités de traitement ont différentes responsabilités. Tous les services basés sur les flux d’un paquet sont exécutés sur un seul SPU. Les responsabilités de ces NPU ne sont pas clairement définies en ce qui concerne les autres types de services qui y sont exécutés. .)

Par exemple :

  • Un NPU traite les paquets séparément. Il effectue des vérifications de intégrité et applique certains écrans configurés pour l’interface, tels que les écrans de déni de service (DoS), au paquet.

  • Un SPU gère la session pour le flux de paquets et applique des fonctionnalités de sécurité et d’autres services au paquet. Il applique également des filtres de pare-feu sans état basés sur les paquets, des classificateurs et des shapeurs de trafic au paquet.

  • Un NPU transfère un paquet au SPU à l’aide de l’algorithme de hachage. Cependant, pour certaines applications, comme ALG, le système devra interroger le point central de l’application pour déterminer sur quel SPU le paquet doit être traité.

Ces parties distinctes et coopératives du système, y compris le point central, stockent chacune les informations identifiant l’existence d’une session pour un flux de paquets et les informations avec lesquelles un paquet est apparié pour déterminer s’il appartient à une session existante.

Cette architecture permet à l’équipement de distribuer le traitement de toutes les sessions sur plusieurs SPU. Il permet également à un NPU de déterminer s’il existe une session pour un paquet, de vérifier le paquet et d’appliquer des écrans au paquet. La façon dont un paquet est géré dépend du fait qu’il s’agit du premier paquet d’un flux.

Les sections suivantes décrivent l’architecture de traitement utilisant les équipements SRX5400, SRX5600 et SRX5800 par exemple :

Comprendre le traitement des premiers paquets

La figure 4 illustre le chemin que prend le premier paquet d’un flux à l’entrée de l’équipement: le NPU détermine qu’il n’existe aucune session pour le paquet, et le NPU envoie le paquet au point central distribué pour configurer une session de point central distribué. Le point central distribué envoie ensuite un message au point central de l’application pour sélectionner le SPU afin de configurer une session pour le paquet et de traiter le paquet. Le point central distribué envoie ensuite le paquet à ce SPU. Le SPU traite le paquet et l’envoie au NPU pour transmission depuis l’équipement. (Cette description de haut niveau ne traite pas de l’application de fonctionnalités à un paquet.)

Figure 4 : Traitement First-Packet Processing du premier paquet

Une fois que le premier paquet d’un flux a traversé le système et qu’une session a été établie pour lui, il subit un traitement rapide.

Les paquets suivants dans le flux subissent également un traitement de chemin rapide ; dans ce cas, une fois que chaque paquet est entré dans la session et que le NPU lui a trouvé une correspondance dans sa table de session, le NPU transfère le paquet au SPU qui gère sa session.

La figure 5 illustre le traitement rapide. Il s’agit du chemin qu’un paquet prend lorsqu’un flux a déjà été établi pour ses paquets associés. (Il s’agit également du chemin que prend le premier paquet d’un flux après la session pour le flux que le paquet initié a été configuré.) Une fois le paquet entré dans l’équipement, le NPU trouve une correspondance pour le paquet dans sa table de session et transfère le paquet au SPU qui gère la session du paquet. Notez que le paquet contourne l’interaction avec le point central.

Comprendre le traitement rapide

La section suivante explique comment une session est créée et le processus qu’un paquet subit pendant qu’il transite par l’équipement.

Figure 5 : traitement Fast-Path Processing rapide

Voici une présentation des principaux composants impliqués dans la configuration d’une session pour un paquet et le traitement des paquets à la fois séparément et dans le cadre d’un flux pendant qu’ils transitent par les équipements SRX5400, SRX5600 et SRX5800.

  • Unités de traitement du réseau (NPU) : les NPU résident sur des IOC. Ils gèrent la vérification de la santé des paquets et l’application de certains écrans. Les NPU maintiennent des tables de session qu’elles utilisent pour déterminer si une session existe pour un paquet entrant ou pour le trafic inverse.

    La table de sessions NPU contient une entrée pour une session si la session est établie sur un SPU pour un paquet qui était précédemment entré dans l’équipement via l’interface et qui a été traité par ce NPU. Le SPU installe la session dans la table NPU lorsqu’il crée la session.

    Un NPU détermine si une session existe pour un paquet en vérifiant les informations du paquet par rapport à sa table de session. Si le paquet correspond à une session existante, le NPU envoie le paquet et les métadonnées qui le concernent au SPU. S’il n’y a pas de session, les NPU envoient le paquet à un SPU qui est calculé à l’aide de l’algorithme de hachage.

  • Unités de traitement de services (SPU) : les principaux processeurs des équipements SRX5400, SRX5600 et SRX5800 résident sur des SPC. Les SPU établissent et gèrent les flux de trafic et effectuent la majeure partie du traitement des paquets sur un paquet qui transite par l’équipement. Chaque SPU conserve une table de hachage pour une recherche rapide des sessions. Le SPU applique des filtres de pare-feu, des classificateurs et des shapeurs de trafic sans état au trafic. Un SPU effectue tous les traitements basés sur les flux pour un paquet et la plupart des traitements basés sur les paquets. Chaque SPU multicœur traite les paquets de manière indépendante avec un minimum d’interaction entre les SPU sur le même SPC ou différent. Tous les paquets appartenant au même flux sont traités par le même SPU.

    Le SPU gère une table de sessions avec des entrées pour toutes les sessions qu’il a établies et dont il traite les paquets. Lorsqu’un SPU reçoit un paquet d’un NPU, il vérifie sa table de session pour s’assurer qu’il lui appartient. Il vérifie également sa table de session lorsqu’il reçoit un paquet du point central distribué et envoie un message pour établir une session pour ce paquet afin de vérifier qu’il n’y a pas de session existante pour le paquet.

  • Point central : l’architecture du 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 chargements, 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 le SPU du point central dédié, tandis que la fonctionnalité de point central distribué est distribuée au reste des SPU. Désormais, les sessions de point central ne sont plus sur le SPU central dédié, mais avec le point central distribué sur d’autres SPU de flux.

  • Moteur de routage : le moteur de routage exécute le plan de contrôle.

Comprendre le chemin des données pour les sessions unicast

Cette section décrit le processus d’établissement d’une session pour les paquets appartenant à un flux qui transite par l’équipement.

Pour illustrer l’établissement des sessions et la « marche » des paquets, y compris les points auxquels les services sont appliqués aux paquets d’un flux, cet exemple utilise le cas simple d’une session unicast.

Cette « marche » des paquets réunit le traitement basé sur les paquets et le traitement basé sur les flux que Junos OS effectue sur le paquet.

Critères de recherche de session et de correspondance des paquets

Pour déterminer si un paquet appartient à un flux existant, l’équipement tente de faire correspondre les informations du paquet à celles d’une session existante en fonction des six critères de correspondance suivants :

  • Adresse source

  • Adresse de destination

  • Port source

  • Port de destination

  • Protocole

  • Jeton unique d’une zone donnée et routeur virtuel

Comprendre la création de session : traitement du premier paquet

Cette section explique comment une session est configurée pour traiter les paquets composant un flux. Pour illustrer le processus, cette section utilise un exemple avec une source « a » et une destination « b ». La direction de la source à la destination des paquets du flux est appelée (a ->b). La direction de la destination à la source est appelée (b->a).

Étape 1. Un paquet arrive à une interface sur l’équipement et le NPU le traite.

Cette section décrit comment un paquet est géré lorsqu’il arrive à un ioc entrant d’un équipement SRX Series.

  1. Le paquet arrive au IOC de l’équipement et est traité par le NPU sur l’IOC.

  2. Le NPU effectue des vérifications basiques de l’intégrité du paquet et applique certains écrans configurés pour l’interface au paquet.

  3. Le NPU vérifie dans sa table de session une session existante pour le paquet. (Il vérifie la tuple du paquet par rapport à celle des paquets pour les sessions existantes dans sa table de session.)

    1. Si aucune session existante n’est trouvée, le NPU transfère le paquet vers le SPU de hachage.

    2. Si une correspondance de session est trouvée, la session a déjà été créée sur un SPU qui lui a été assigné, de sorte que le NPU transfère le paquet au SPU pour traitement avec l’ID de session.

Example: Packet (a ->b) arrive à NPU1. NPU1 effectue des vérifications de intégrité et applique des écrans DoS au paquet. NPU1 vérifie la correspondance de sa table de session et ne trouve aucune session existante. NPU1 transfère le paquet vers un SPU.

Étape 2. Le point central distribué crée une session avec un état « en attente ».

Lorsqu’un NPU reçoit un paquet, le NPU l’envoie au point central distribué, en fonction de l’algorithme de hachage. Le point central distribué recherche ensuite la table de session du point central distribué et crée une entrée si nécessaire.

Ce processus comprend les éléments suivants :

  1. Le point central distribué vérifie sa table de session pour déterminer s’il existe une session pour le paquet reçu du NPU. (Un NPU transfère un paquet vers le point central distribué parce qu’il ne trouve pas une session existante pour le paquet)

  2. S’il n’y a pas d’entrée qui correspond au paquet dans la table de session du point central distribué, le point central distribué crée une aile en attente pour la session. Le point central distribué envoie ensuite un message de requête au point central de l’application pour sélectionner un SPU à utiliser pour la session.

  3. Après avoir reçu le message de requête, le point central de l’application vérifie sa table de porte pour déterminer s’il existe une porte pour le paquet. Si un portail est assorti ou qu’un autre algorithme de distribution de session est déclenché, le point central de l’application sélectionne un autre SPU pour traiter le paquet ; dans le cas contraire, le SPU (c’est-à-dire le SPU central distribué) est sélectionné. Enfin, le point central d’application envoie une réponse de requête au point central distribué.

  4. Après avoir reçu la réponse de la requête, le point central distribué transfère le premier paquet dans le flux vers le SPU sélectionné dans un message lui indiquant de configurer une session localement à utiliser pour le flux de paquets. Par exemple, le point central distribué crée une aile en attente (un ->b) pour la session. Le point central de l’application sélectionne le SPU1 à utiliser pour cela. Le point central distribué envoie au SPU1 le paquet (a->b) ainsi qu’un message pour créer une session pour le point central distribué.

Example: Le point central distribué crée une aile en attente (un ->b) pour la session. Il sélectionne le SPU1 pour l’utiliser. Il envoie au SPU1 le paquet (a->b) ainsi qu’un message pour créer une session pour lui.

Étape 3. Le SPU configure la session.

Chaque SPU dispose également d’une table de session qui contient des informations sur ses sessions. Lorsque le SPU reçoit un message du point central distribué pour configurer une session, il vérifie sa table de session pour s’assurer qu’une session n’existe pas déjà pour le paquet.

  1. S’il n’y a pas de session existante pour le paquet, le SPU configure la session localement.

  2. Le SPU envoie un message au point central distribué qui lui ordonne d’installer la session.

    Note:

    Lors du premier traitement des paquets, si le NAT est activé, le SPU alloue des ressources d’adresse IP pour nat. Dans ce cas, le traitement du premier paquet pour la session est suspendu jusqu’à ce que le processus d’allocation NAT soit terminé.

Le SPU ajoute à la file d’attente tous les paquets supplémentaires pour le flux qu’il pourrait recevoir jusqu’à ce que la session ait été installée.

Example: Le SPU1 crée la session pour (un ->b) et envoie un message au point central distribué pour l’ordonner d’installer la session en attente.

Étape 4. Le point central distribué installe la session.

Le point central distribué reçoit le message d’installation du SPU.

  1. Le point central distribué définit l’état d’activité de l’aile en attente de la session.

  2. Le point central distribué installe l’aile arrière pour la session en tant qu’aile active.

    Note:

    Dans certains cas, comme le NAT, l’aile arrière peut être installée sur un point central distribué différent du point central distribué de l’aile d’init.

  3. Il envoie un message de reconnaissance (ACK) au SPU, indiquant que la session est installée.

Example: Le point central distribué reçoit un message du SPU1 pour installer la session pour l’aile (a->b). Il définit l’état de session pour que l’aile (a->b) soit active. Il installe l’aile arrière (b->a) pour la session et le rend actif; cela permet de livrer les paquets depuis le sens inverse du flux : destination (b) à livrer à la source (a).

Étape 5. Le SPU configure la session sur les NPU entrants et sortants.

Les NPU conservent des informations sur une session pour le transfert et la distribution de paquets. Les informations de session sont configurées sur les NPU sortants et entrants (qui sont parfois les mêmes), de sorte que les paquets peuvent être envoyés directement au SPU qui gère leurs flux et non au point central distribué pour la redirection.

Étape 6. Le traitement des chemins rapides est effectué.

Pour le reste des étapes du traitement des paquets, passez à l’étape 1 de Comprendre le traitement rapide.

La figure 6 illustre la première partie du processus que subit le premier paquet d’un flux après avoir atteint l’équipement. À ce stade, une session est configurée pour traiter le paquet et le reste des paquets appartenant à son flux. Par la suite, elle et le reste des paquets du flux subissent un traitement rapide.

Figure 6 : Création de session : traitement Session Creation: First-Packet Processing du premier paquet

Comprendre le traitement rapide

Tous les paquets sont traités rapidement. Toutefois, si une session existe pour un paquet, le paquet subit un traitement de chemin rapide et contourne le processus de premier paquet. Lorsqu’il y a déjà une session pour le flux du paquet, le paquet ne transite pas par le point central.

Voici comment fonctionne le traitement de chemin rapide : les NPU des interfaces de sortie et d’entrée contiennent des tables de session qui comprennent l’identification du SPU qui gère le flux d’un paquet. Étant donné que les NPU disposent de ces informations de session, tout le trafic du flux, y compris le trafic inverse, est envoyé directement à ce SPU pour traitement.

Pour illustrer le processus de chemin rapide, cette section utilise un exemple avec une source « a » et une destination « b ». La direction de la source à la destination des paquets du flux est appelée (a->b). La direction de la destination à la source est appelée (b->a).

Étape 1. Un paquet arrive sur l’équipement et le NPU le traite.

Cette section décrit comment un paquet est géré lorsqu’il arrive à l’IOC d’une passerelle de services.

  1. Le paquet arrive à l’IOC de l’équipement et est traité par le NPU sur la carte.

    Le NPU effectue des vérifications de intégrité et applique certains écrans, tels que les écrans de déni de service (DoS), au paquet.

  2. Le NPU identifie une entrée pour une session existante dans sa table de session que le paquet correspond.

  3. Le NPU transfère le paquet ainsi que les métadonnées de sa table de session, y compris l’ID de session et les informations de paquet tuple, au SPU qui gère la session pour le flux, applique des filtres de pare-feu et des fonctionnalités CoS sans état à ses paquets, et gère le traitement du flux du paquet et l’application de fonctionnalités de sécurité et autres.

Example: Packet (a ->b) arrive à NPU1. NPU1 effectue des vérifications de intégrité sur le paquet, lui applique des écrans DoS et vérifie sa table de session pour une correspondance tuple. Il trouve une correspondance et qu’une session existe pour le paquet sur SPU1. NPU1 transfère le paquet vers SPU1 pour traitement.

Étape 2. Le SPU de la session traite le paquet.

La plupart du traitement d’un paquet s’effectue sur le SPU auquel sa session est affectée. Le paquet est traité pour des fonctionnalités basées sur des paquets telles que les filtres de pare-feu sans état, les shapers de trafic et les classificateurs, le cas échéant. La sécurité basée sur les flux configurée et les services associés tels que les fonctionnalités de pare-feu, nat, ALG, etc. sont appliqués au paquet. (Pour plus d’informations sur la façon dont les services de sécurité sont déterminés pour une session.

  1. Avant qu’il ne traite le paquet, le SPU vérifie sa table de session pour vérifier que le paquet appartient à l’une de ses sessions.

  2. Le SPU traite le paquet pour les fonctionnalités et services applicables.

Example: Le SPU1 reçoit un paquet (a->b) de NPU1. Le SPU1 vérifie sa table de session pour vérifier que le paquet appartient à l’une de ses sessions. Ensuite, il traite le paquet (un ->b) en fonction des filtres d’entrée et des fonctionnalités CoS qui s’appliquent à son interface d’entrée. Le SPU applique les fonctionnalités et services de sécurité configurés pour le flux du paquet vers lui, en fonction de sa zone et de ses stratégies. Le cas échéant, il applique des filtres de sortie, des shapers de trafic et des écrans supplémentaires au paquet.

Étape 3. Le SPU transfère le paquet vers le NPU.
  1. Le SPU transfère le paquet vers le NPU.

  2. Le NPU applique au paquet tous les écrans associés à l’interface.

Example: Le SPU1 transfère le paquet (a ->b) vers NPU2, et NPU2 applique des écrans DoS.

Étape 4. L’interface transmet le paquet de l’équipement.

Example: L’interface transmet le paquet (a->b) de l’équipement.

Étape 5. Un paquet de trafic inversé arrive à l’interface sortante et le NPU le traite.

Cette étape reflète exactement l’étape 1 en arrière. Pour plus de détails, reportez-vous à l’étape 1 de cette section.

Example: Packet (b->a) arrive à NPU2. NPU2 vérifie sa table de session pour une correspondance tuple. Il trouve une correspondance et qu’une session existe pour le paquet sur SPU1. NPU2 transfère le paquet vers SPU1 pour traitement.

Étape 6. Le SPU de la session traite le paquet de trafic inversé.

Cette étape est la même que l’étape 2, sauf qu’elle s’applique au trafic inversé. Pour plus de détails, reportez-vous à l’étape 2 de cette section.

Example: Le SPU1 reçoit le paquet (b->a) de NPU2. Il vérifie sa table de session pour vérifier que le paquet appartient à la session identifiée par NPU2. Ensuite, il applique des fonctionnalités basées sur les paquets configurées pour l’interface du NPU1 au paquet. Il traite les paquets (b->a) en fonction des fonctionnalités de sécurité et des autres services configurés pour son flux, en fonction de sa zone et de ses stratégies.

Étape 7. Le SPU transfère le paquet de trafic inverse vers le NPU.

Cette étape est la même que l’étape 3, sauf qu’elle s’applique au trafic inversé. Pour plus de détails, reportez-vous à l’étape 3 de cette section.

Example: Le SPU1 transfère le paquet (b->a) vers NPU1. NPU1 traite tous les écrans configurés pour l’interface.

8. L’interface transmet le paquet depuis l’équipement.

Cette étape est la même que l’étape 4, sauf qu’elle s’applique au trafic inversé. Pour plus de détails, reportez-vous à l’étape 4 de cette section.

Exemple : l’interface transmet un paquet (b->a) depuis l’équipement.

La figure 7 illustre le processus qu’un paquet subit lorsqu’il atteint l’équipement et qu’une session existe pour le flux à laquelle il appartient.

Figure 7 : Marche des paquets pour le traitement rapide des chemins Packet Walk for Fast-Path Processing

Comprendre les unités de traitement des services

Pour une interface physique donnée, le SPU reçoit des paquets entrants de tous les processeurs réseau de l’offre de processeur réseau associée à l’interface physique. Le SPU extrait les informations d’offre de processeur réseau de l’interface physique et utilise le même algorithme de hachage de 5 tuple pour mapper un flux à un index de processeur réseau. Pour déterminer le processeur réseau, le SPU recherche l’index du processeur réseau dans l’offre de processeur réseau. Le SPU envoie des paquets sortants vers le module d’interface physique (PIM) local de l’interface physique pour le trafic sortant.

Note:

Le processeur réseau et le SPU utilisent le même algorithme de hachage à 5 tuple pour obtenir les valeurs de hachage des paquets.

Comprendre les caractéristiques du planificateur

Pour les équipements SRX5400, SRX5600 et SRX5800, l’IOC prend en charge les caractéristiques hiérarchiques du planificateur suivantes :

  • IFL – La configuration de l’offre de processeur réseau est stockée dans la structure de données de l’interface physique. Par exemple, les équipements SRX5400, SRX5600 et SRX5800 ont un maximum de 48 MIP. L’interface physique peut utiliser un masque de bit 48 bits pour indiquer le PIM, ou le trafic du processeur réseau de cette interface physique est distribué en plus du processeur réseau principal de l’interface physique.

    Sur les équipements de la gamme SRX5000, la fonctionnalité iflset n’est pas prise en charge pour les interfaces agrégées comme reth.

  • IFD – L’interface logique associée à l’interface physique d’un ensemble de processeurs réseau est transmise à tous les CIO qui disposent d’un PIM dans l’offre de processeur réseau.

Comprendre l’empaquetage des processeurs réseau

La fonctionnalité de regroupement de processeurs réseau est disponible sur les équipements de la gamme SRX5000. Cette fonctionnalité permet de distribuer le trafic de données d’une interface à plusieurs processeurs réseau pour le traitement des paquets. Un processeur réseau principal est assigné à une interface qui reçoit le trafic entrant et distribue les paquets à plusieurs autres processeurs réseau secondaires. Un seul processeur réseau peut agir comme processeur réseau principal ou comme processeur réseau secondaire pour plusieurs interfaces. Un seul processeur réseau peut rejoindre une seule offre de processeur réseau.

Limitations des regroupements de processeurs réseau

La fonctionnalité de regroupement de processeurs réseau présente les limites suivantes :

  • Le regroupement de processeurs réseau permet un total de 16 PIM par offre et 8 systèmes d’offre de processeurs réseau différents.

  • Vous devez redémarrer l’équipement pour appliquer les modifications de configuration sur l’offre.

  • L’ensemble des processeurs réseau est en dessous de l’interface reth de l’architecture globale. Vous pouvez choisir une ou les deux interfaces dans l’offre de processeur réseau pour former l’interface reth.

  • Si l’IOC est retiré d’une offre de processeur réseau, les paquets transférés vers le PIM de cet IOC sont perdus.

  • Lorsque l’offre de processeur réseau est activée, les seuils d’inondation icMP, UDP et TCP de synchronisation ne s’appliquent plus à une interface. Les paquets sont distribués à plusieurs processeurs réseau pour traitement. Ces seuils s’appliquent à chaque processeur réseau de l’offre de processeur réseau.

  • Le regroupement de processeurs réseau n’est pas pris en charge en mode de couche 2.

  • En raison des contraintes de mémoire sur le processeur réseau, le nombre de ports fournis par processeur réseau pris en charge par PIM est limité. Dans l’offre de processeur réseau, chaque port doit avoir un index de port global. L’index global des ports est calculé à l’aide de la formule suivante :

    Global_port_index = (global_pic * 16) + port_offset

  • Les groupes d’agrégation de liaisons (LAG) et les LAG d’interface Ethernet redondants dans les implémentations de clusters de châssis peuvent coexister avec le regroupement de processeurs réseau. Toutefois, ni les LAG ni les LAG d’interface Ethernet redondants ne peuvent se chevaucher ou partager des liaisons physiques avec un offre de processeur réseau.

Comprendre le cache de session

Aperçu

Les modèles SRX5K-MPC (IOC2), SRX5K-MPC3-100G10G (IOC3) et SRX5K-MPC3-40G10G (IOC3) sur les équipements SRX5400, SRX5600 et SRX5800 prennent en charge le cache de session et l’installation sélective du cache de session.

Le cache de session est utilisé pour mettre en cache une conversation entre le processeur réseau (NP) et le SPU sur un IOC. Une conversation peut être une session, un trafic tunnel GTP-U, un tunnel VPN IPsec, etc. Une conversation comporte deux entrées de cache de session, une pour le trafic entrant et l’autre pour le trafic inverse. Selon l’emplacement des ports d’entrée et de sortie du trafic, deux entrées peuvent résider dans le même processeur réseau ou dans des processeurs réseau différents. Les iocs prennent en charge le cache de session pour les sessions IPv6.

Une entrée de cache de session est également appelée aile de session.

Le cache de session sur l’IOC exploite la fonctionnalité Express Path (anciennement appelée service offloading) et permet d’éviter les problèmes tels que la latence élevée et les baisses de performances IPsec.

Une entrée de cache de session enregistre :

  • Vers quel SPU le trafic de la conversion doit être transféré

  • Vers quel port sortant le trafic de la conversion doit être transféré en mode Express Path

  • Traitement à effectuer pour le trafic sortant, par exemple la traduction NAT en mode Express Path

À partir de Junos OS version 15.1X49-D10 et junos OS version 17.3R1, le cache des sessions de l’IOC permet de résoudre certains problèmes de performances. Le SPU peut désormais demander au cache de session IOC de transférer le trafic suivant vers un SPU d’ancrage spécifique.

À partir de la version 15.1X49-D10 de Junos OS, le SRX5K-MPC (IOC2) et l’IOC3 prennent en charge l’affinité des sessions VPN grâce à l’amélioration du module de flux et du cache de session. À partir de la version 12.3X48-D30 de Junos OS, sur l’IOC2, l’affinité des sessions VPN via le cache de session est prise en charge.

D’autres trafics ont été hachés vers des SPU en fonction de leurs 5 informations clés. Le trafic VPN a utilisé le concept de SPU ancré, qui ne coïncidait pas nécessairement avec les fonctions du SPU de flux. Le processeur réseau ne pouvait transférer les paquets vers le SPU de flux que sur la base du hachage de 5 tuple. Le SPU de flux a ensuite transféré le paquet vers le SPU ancré. Cela a créé un saut supplémentaire pour le trafic VPN, ce qui a gaspiller la bande passante de la structure de commutation et réduit le débit VPN d’environ de moitié. Cette réduction des performances s’est produite parce que le trafic devait encore revenir au SPU de flux après le traitement sur le SPU ancré.

La table de cache de session est désormais étendue sur IOC pour prendre en charge les sessions NP. Le trafic Express Path et le trafic NP partagent la même table de cache de session sur les IOC. Le trafic Express Path est transféré par l’IOC lui-même, soit localement, soit vers un autre IOC, car il ne nécessite aucun service du SPU. Le trafic NP est transféré au SPU spécifié dans le cache de session pour un traitement ultérieur. Toutes les entrées de cache de session sont partagées à la fois par le trafic de session Express Path et le trafic NP.

Pour activer le cache de session sur les IOC, vous devez exécuter la set chassis fpc <fpc-slot> np-cache commande.

Note:

L’IOC2 et l’IOC3 utilisent le mécanisme de suppression des sessions de retard. Les mêmes sessions (avec les mêmes cinq tuples) qui sont supprimées puis réinstallées immédiatement ne sont pas mises en cache sur les IOC.

Installation sélective du cache de session

Pour éviter une latence élevée, améliorer les performances IPSec et mieux utiliser les précieuses ressources, certains mécanismes de priorité sont appliqués au module de flux et à l’IOC.

Les CIO maintiennent et surveillent les seuils d’utilisation du cache de session. Les IOC communiquent également l’utilisation du cache de session au SPU, de sorte que lorsqu’un certain seuil d’utilisation du cache de session est atteint, le SPU n’envoie que des demandes d’installation de cache de session pour des sessions sélectives de trafic hautement prioritaires.

Les applications comme IDP et ALG doivent traiter les paquets dans l’ordre. Un SPU dispose de plusieurs threads de flux pour gérer les paquets appartenant à une session, le thread d’équilibrage de charge (LBT) et l’ordre de paquets pot (Packet-Ordering Thread) peuvent s’assurer que le trafic passe par le pare-feu afin de garantir que l’application traite les paquets appartenant à la même session dans l’ordre. La sérialisation des flux fournit la méthode selon laquelle un seul paquet de flux SPU de traitement des paquets de flux appartiennent à la même session à la fois, afin que les applications puissent recevoir, traiter et envoyer des paquets dans l’ordre. D’autres threads de flux peuvent traiter simultanément la sérialisation des flux pour d’autres sessions.

Les quatre niveaux de priorité suivants sont utilisés pour déterminer quel type de trafic peut installer le cache de session sur les IOC :

  • Priority 1 (P1)— Trafic qualifié IPSec et Express Path

  • Priority 2 (P2)— Ordre de fragmentation

  • Priority 3 (P3)— Trafic NAT/SZ (sérialisation des sessions)

  • Priority 4(P3)— Tous les autres types de trafic

Les IOC maintiennent et surveillent les seuils d’utilisation du cache de session et mettent à jour l’utilisation actuelle du cache de session en temps réel vers le SPU. Le SPU demande à l’IOC d’installer le cache de session pour certaines sessions de trafic prioritaires. L’utilisation du cache de session pour les sessions de trafic prioritaires est définie dans le tableau :

Tableau 1 : Barres d’installation du cache de session

Type de trafic

0 % d’utilisation < < 25 %

25 % < utilisation < 50 %

50 % < utilisation < 75 %

75 % d’utilisation < < 100 %

Trafic IPsec et Express Path

Oui

Oui

Oui

Oui

Fragmentation Commande du trafic

Oui

Oui

Oui

Non

Trafic NAT/SZ

Oui

Oui

Non

Non

Autre trafic

Oui

Non

Non

Non

Pour conserver les entrées de session sur l’IOC, le module de flux installe les sessions de manière sélective sur l’IOC. Pour faciliter la sélection de l’installation des sessions, l’IOC maintient les seuils correspondants afin de fournir une indication au module de flux (sur l’intégralité de la table de cache de session sur les CIO). Deux bits dans l’en-tête méta sont ajoutés pour indiquer l’état actuel d’utilisation de la table de cache. Tous les paquets allant vers le SPU transporteront ces deux bits d’état pour informer le module de flux de l’utilisation de la table de cache sur l’IOC.

Amélioration de l’affinité des sessions VPN IPsec à l’aide du cache de session

Les équipements SRX Series sont des systèmes entièrement distribués, et un tunnel IPsec est alloué et ancré à un SPU spécifique. Tout le trafic appartenant à un tunnel IPsec est chiffré et déchiffré sur son SPU ancré dans un tunnel. Afin d’obtenir de meilleures performances IPsec, IOC améliore le module de flux pour créer des sessions pour le trafic basé sur un tunnel IPsec (avant le chiffrement et après le déchiffrement) sur son SPU ancré dans un tunnel, et installe le cache de session pour les sessions afin que l’IOC puisse rediriger les paquets directement vers le même SPU afin de minimiser les frais de transfert de paquets. Le trafic Express Path et le trafic NP partagent la même table de cache de session sur les IOC.

Vous devez activer le cache de session sur les IOC et définir la stratégie de sécurité pour déterminer si une session est en mode Express Path (anciennement appelé décharge de services) sur le concentrateur PIC flexible (FPC) sélectionné.

Pour activer l’utilisation de l’affinité VPN IPsec, la set security flow load-distribution session-affinity ipsec commande.

Note:

Pour activer l’affinité VPN IPsec, vous devez également activer le cache de session sur les IOC à l’aide de la set chassis fpc <fpc-slot> np-cache commande.

Configuration de l’IOC vers le mappage NPC

Une carte d’entrée/sortie (IOC) vers une carte de traitement du réseau (NPC) nécessite de mapper un IOC à un PNJ. Cependant, vous pouvez mapper plusieurs IOC à un seul NPC. Pour équilibrer la puissance de traitement du NPC sur les passerelles de services SRX3400 et SRX3600, le processus de châssis (daemon) exécute un algorithme qui effectue le mappage. Il mappe un IOC à un PNJ qui a le moins d’IPC mappé. Vous pouvez également utiliser l’interface de ligne de commande (CLI) pour affecter un IOC spécifique à un NPC spécifique. Lorsque vous configurez le mappage, le processus de châssis utilise d’abord votre configuration, puis applique l’algorithme NPC le moins de nombre pour le reste des CIO.

Note:

La prise en charge de la plate-forme dépend de la version junos OS de votre installation.

Pour configurer le mappage IOC vers NPC :

Voir le tableau 2 pour une description des set chassis ioc-npc-connectivity options.

Tableau 2 : Options de connectivité IOC vers NPC

Option

Description

Cio slot-number

Spécifiez le numéro d’emplacement IOC. La plage est de 0 à 7 pour les équipements SRX3400 et de 0 à 12 pour les équipements SRX3600.

Npc slot-number

Spécifiez le numéro d’emplacement NPC. La plage est de 0 à 7 pour les équipements SRX3400 et de 0 à 12 pour les équipements SRX3600 et SRX 4600.

Aucun

Le processus de châssis cartographie la connexion pour l’IOC spécifique.

Note:

Vous devez redémarrer le contrôle du châssis après avoir valide la set chassis ioc-npc-connectivity commande.

Comprendre le traitement des flux sur les équipements SRX5K-SPC3

La carte de traitement de services SRX5K-SPC3 est introduite pour améliorer les performances des services de sécurité sur la passerelle de services de sécurité SRX5000. La carte SPC3 prend en charge un débit plus élevé et maintient sa fiabilité tout en préservant la fonctionnalité du cluster de châssis et l’évolutivité pour le traitement des services.

La carte SPC3 prend en charge les fonctionnalités de sécurité suivantes :

Le flux de sécurité est amélioré pour prendre en charge la carte SPC3 avec toutes les fonctionnalités de sécurité existantes prises en charge sur la carte SPC2.

Note:

Les limitations suivantes s’appliquent à la carte SPC3 de Junos OS version 18.2R1-S1 :

  • L’interopérabilité des cartes SPC3 et SPC2 n’est pas prise en charge.

  • La fonctionnalité VPN IPsec n’est pas prise en charge avec la carte SPC3.

À partir de la version 18.2R1-S1 de Junos OS, une nouvelle carte de traitement des services (SPC3) est introduite pour les équipements SRX5000 Series. L’introduction de la nouvelle carte améliore l’évolutivité et les performances de l’équipement et maintient sa fiabilité tout en préservant la fonctionnalité de cluster de châssis. La carte SPC3 prend en charge un débit et une évolutivité plus élevés pour le traitement des services.

Sur les équipements SRX5000 Series, la carte SPC3 interopérabilité avec les cartes d’E/S (IOC2, IOC3), la carte de contrôle des commutateurs (SCB2, SCB3), les moteurs de routage et les cartes SPC2.

À partir de la version 18.4R1 de Junos OS, un mélange de cartes SPC3 et SPC2 est pris en charge sur les équipements SRX5000 Series.

Si vous ajoutez les cartes SPC3 sur les équipements de la gamme SRX5000, la nouvelle carte SPC3 doit être installée dans l’emplacement le plus petit de tous les SPC. La carte SPC3 est installée dans l’emplacement le plus faible numéroté d’origine offre la fonctionnalité de point central (CP) en mode mixte. Par exemple, si votre passerelle de services contient un mélange de cartes SPC2 et SPC3, une SPC3 doit occuper l’emplacement numéroté le plus bas de n’importe quel SPC du châssis. Cette configuration garantit que la fonctionnalité de point central (CP) en mode mixte est exécutée par la carte SPC3.

Sur les équipements SRX5000 Series fonctionnant en mode mixte, le traitement de flux est partagé entre les cartes SPC3 et SPC2. Le traitement central s’effectue sur l’emplacement SPC le plus bas pour lequel une carte SPC3 est installée.

Note:

Lorsque les équipements SRX Series fonctionnent en mode cluster de châssis, les cartes SPC3 et SPC2 doivent être installées dans les mêmes emplacements sur chaque châssis.

Comprendre l’architecture logicielle SPC3

L’architecture de flux SPC3 est la même que l’architecture CP-Lite. Le SPC3 dispose physiquement de deux unités de traitement des services (SPU) et chaque SPU a deux processeurs.

Lorsque vous installez un ou deux SPC3, le traitement du trafic utilise 75 % du premier SPC. Lorsque vous installez trois SPC3 ou plus, le traitement du trafic utilise 50 % du premier SPC.

La façon dont l’IOC hache les paquets pour traiter le flux est modifiée. La figure montre le flux de paquets d’un équipement SRX avec SPC3.

Figure 8 : flux de paquets sur SPC3 Packet flow on SPC3

Sur SPC3, les paquets sont distribués directement de l’IOC à chaque cœur. Comme l’IOC hache directement les paquets vers le thread RT fluxé, le thread LBT d’origine est supprimé. Les paquets sont désormais remis au thread flux au lieu du SPU. Si le flux de sécurité installe des sessions NP, au lieu de l’ID SPU, l’ID de thread de session est utilisé par l’IOC pour transférer les paquets afin de corriger l’associé de thread à la session.

Figure 9 : Flux de paquets via un thread Packet flow through flowd thread flux

Comprendre la distribution des charges

Tous les paquets qui passent par un port de revenus seront distribués à différents SPU en fonction de l’algorithme de hachage, qui est le même que le hachage des équipements SRX5000 Line existant basé sur l’architecture CP-Lite. La méthode de hachage varie selon les types de trafic. Le tableau ci-dessous répertorie les méthodes de hachage.

Tableau 3 : Distribution de charge - Méthodes de hachage

Protocole

Ports

Méthode Hash

TCP

Port L4 src et port dst

Hachage de 5 tuple

UDP

Normal

Port L4 src et port dst

Hachage de 5 tuple

GTP

Port L4 src et port dst

Hachage de 5 tuple

IKE

Port L4 src et port dst

Hachage par paire IP

ICMP

  1. Message d’information ICMP version 4 ICMP_ECHO/ICM_ECHOREPLY id/seq ICMP_TSTAMP/ICMP_TSTAMPREPLY id/seq ICMP_IREQ/ICMP_IREQREPLY id/seq ICMP_MASKREQ/ICMP_MASKREPLY 0x00010001

  2. Message d’information ICMP version 6 ICMP6_ECHO_REPLY/ICMP6_ECHO_REQUEST id/seq

  3. Correspondance du message d’erreur ICMP par IP intégrée

  4. Tous les autres 0x00010001

Les informations ICMP sont hachage par 5-tuple ;

L’erreur ICMP est hachage par 3 tuple (pas d’informations sur les ports)

SCTP

Port L4 src et port dst

Hachage de 5 tuple

ESP

SPI

Hachage par paire IP

AH

SPI

Hachage par paire IP

GRE

Si l’alg DUP est activé, sport = id d’appel ; dport = 0

Par défaut, le port est 0x00010001

Hachage par 3-tuple

PIM

Par défaut, les ports PIM 0x00010001

Hachage par 3-tuple

FRAGMENT

Premier fragment, il y a les ports normaux

Aucun premier fragment, aucun port

Hachage par 3-tuple

Autre paquet IP

Ports 0x00010001

Hachage par 3-tuple

AUCUN IP

Sans objet

Hachage par adresse Mac et type Ethernet (ID Vlan)

Comprendre les sessions NP et le déchargement de services (SOF)

La session de processeur réseau (NP) est une session basée sur l’IOC qui permet et établit les sessions SPU. Les paquets qui passent la session NP présentent les avantages suivants :

  • Évite la recherche de session sur le SPU pour améliorer les performances.

  • Évite le transfert de paquets supplémentaire entre le SPU de session et le SPU de hachage.

Le délestage de service est un type spécial de session NP qui fournit une fonctionnalité de faible latence pour les sessions qui ont besoin d’un service de pare-feu de base. Les paquets qui frappent la session SOF sur un IOC contournent le traitement des paquets sur le SPU et sont directement transférés par IOC. Les types de trafic suivants prennent en charge le déchargement des services :

  • Pare-feu de base (sans plugin et fragments), tcp IPv4 et IPv6, trafic UDP

  • IPv4 NAT

  • Multicast 1Fan-in et 1Fan-out

  • ALG tels que les sessions de données FTP

Comprendre la prise en charge de J-Flow sur SPC3

J-Flow est la version Juniper du mécanisme de surveillance du trafic standard du secteur. Il fournit une fonctionnalité d’exportation d’instantanés des statistiques de trafic réseau vers le serveur distant pour la surveillance du réseau et le traitement ultérieur des données. J-Flow prend en charge le format v5, v8 et v9. Toutes ces trois versions sont prises en charge sur SPC3.

Comprendre la prise en charge du SPU (E2E) de chemin de données

Le débogage de chemin de données fournit une fonctionnalité de débogage de paquets de bout en bout (E2E) basée sur des filtres sur les équipements SRX5000 Line. Il trace le chemin des paquets et vide le contenu des paquets.

Sur SPC3, JEXEC est le seul type d’événement E2E pris en charge et les types d’actions E2E suivants sont pris en charge :

  • Compter

  • Décharge

  • Trace

  • Trace-synthèse

Comprendre la gestion de la fragmentation, ISSU et la prise en charge de l’ISHU

Sur SPC3, les paquets fragmentés sont transférés vers un « noyau fragmenté » dans un PFE spécifique en fonction de ses valeurs de tuple d’en-tête. Après avoir reçu un paquet fragmenté, le flux effectue la défragmentation et transfère le paquet vers son cœur de session. La logique de flux ne change pas et reste la même.

Lors de l’exécution de l’ISSU, les SPU virtuels sont synchronisés avec les IDs SPU virtuels associés. La prise en charge de l’ISHU est basée sur l’architecture CP-Lite. En gros, deux opérations ISHU sont prises en charge :

  • Insérez un nouveau SPC vers le nœud secondaire.

  • Remplacez un SPC sur un nœud secondaire, et le nombre de SPC doit être identique à celui du nœud principal.

Tableau de l’historique des versions
Libération
Description
18.4R1
À partir de la version 18.4R1 de Junos OS, un mélange de cartes SPC3 et SPC2 est pris en charge sur les équipements SRX5000 Series.
18.2R1-S1
À partir de la version 18.2R1-S1 de Junos OS, une nouvelle carte de traitement des services (SPC3) est introduite pour les équipements SRX5000 Series. L’introduction de la nouvelle carte améliore l’évolutivité et les performances de l’équipement et maintient sa fiabilité tout en préservant la fonctionnalité de cluster de châssis. La carte SPC3 prend en charge un débit et une évolutivité plus élevés pour le traitement des services.
15.1X49-D70
Par défaut, l’équipement SRX Series est activé pour le transfert basé sur les flux pour le trafic IPv4 sur tous les équipements, à l’exception des équipements SRX300 Series et SRX550M qui sont configurés en mode drop. À partir de Junos OS version 15.1X49-D70 et Junos OS version 17.3R1, pour les équipements SRX1500 Series, SRX4100, SRX4200, SRX5400, SRX5600, SRX5800 et vSRX, vous n’avez pas besoin de redémarrer l’équipement lorsque vous passez des modes de flux à paquets et en mode drop. Pour les équipements SRX300 Series et SRX550M, vous devez redémarrer l’équipement lors de la commutation entre le mode flux, le mode paquet et le mode drop.
15.1X49-D10
À partir de Junos OS version 15.1X49-D10 et junos OS version 17.3R1, le cache des sessions de l’IOC permet de résoudre certains problèmes de performances.
15.1X49-D10
À partir de la version 15.1X49-D10 de Junos OS, le SRX5K-MPC (IOC2) et l’IOC3 prennent en charge l’affinité des sessions VPN grâce à l’amélioration du module de flux et du cache de session
12.1X48-D30
À partir de la version 12.3X48-D30 de Junos OS, sur l’IOC2, l’affinité de session VPN via le cache de session est prise en charge