Présentation du traitement du trafic sur les pare-feu SRX Series

Comprendre le traitement basé sur les flux

Un paquet subit un traitement basé sur les flux après que des filtres basés sur les paquets et des filtres 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). Une 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 montre une vue conceptuelle de la façon dont le traitement du trafic basé sur les flux s’effectue sur la passerelle de services.

Figure 1 : Flux de trafic pour le traitement basé sur les 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 les paquets appartenant au même flux de la même manière.

Les paramètres de configuration qui déterminent le sort d’un paquet (comme la stratégie de sécurité qui s’applique à lui, s’il nécessite une passerelle de la couche couche applicative (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 et un routeur virtuel donnés

• Zones et politiques
• Flux et sessions

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 d’être 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 aux paquets distincts.

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

• Avant qu’un paquet ne quitte l’appareil, tous 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 pour déterminer quels paquets sont autorisés à transiter par le système et pour appliquer des actions spéciales aux paquets si nécessaire.

Les rubriques suivantes 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
• Fonctionnalités de classe de service
• Écrans

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, la SPU fait référence au thread du plan de données du pare-feu SRX320.

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

Comprendre le traitement du premier paquet

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

• Adresse source

• Adresse de destination

• Port source

• Port de destination

• Protocole

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

Le SPU vérifie sa table de sessions pour une session existante pour le paquet. Si aucune session existante n’est trouvée, la 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 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 route

• Recherche de stratégies

• Recherche de service

• NAT, si nécessaire

Une fois qu’une session est établie, 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 le reste des étapes impliquées dans le traitement des paquets, passez à l’étape 1 du « Traitement accéléré ». Tous les paquets sont traités rapidement.

Comprendre le traitement accéléré

Si un paquet correspond à une session, Junos OS effectue un traitement 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 accéléré. Tous les paquets sont traités rapidement.

1. La 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 modélisation 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 premier paquet

La figure 4 illustre le chemin emprunté par le premier paquet d’un flux lorsqu’il entre dans 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 qu’il sélectionne le SPU afin de configurer une session pour le paquet et de traiter le paquet. Le point central distribué envoie ensuite le paquet à cette unité de protection individuelle. Le SPU traite le paquet et l’envoie au NPU pour transmission à partir de l’appareil. (Cette description de haut niveau ne traite pas de l’application des fonctionnalités à un paquet.)

Figure 4 : Traitement 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 celui-ci, il subit un traitement accéléré.

Les paquets suivants dans le flux subissent également un traitement rapide ; dans ce cas, après que chaque paquet entre dans la session et que le NPU trouve une correspondance pour lui dans sa table de session, le NPU transmet le paquet au SPU qui gère sa session.

La figure 5 illustre un traitement accéléré. Il s’agit du chemin emprunté par un paquet lorsqu’un flux a déjà été établi pour les paquets associés. (Il s’agit également du chemin emprunté par le premier paquet d’un flux après la session pour le flux initié par le paquet.) Une fois le paquet entré dans l’appareil, le NPU trouve une correspondance pour le paquet dans sa table de session et il transmet 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 accéléré

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

Figure 5 : Traitement accéléré

Voici une vue d’ensemble des principaux composants impliqués dans la configuration d’une session pour un paquet et le traitement des paquets à la fois discrètement et dans le cadre d’un flux lorsqu’ils transitent par les périphériques SRX5400, SRX5600 et SRX5800.

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

  La table de session NPU contient une entrée pour une session si la session est établie sur une SPU pour un paquet qui était précédemment entré dans le périphérique via l’interface et qui a été traité par ce NPU. La SPU installe la session dans la table NPU lorsqu’elle 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 de celui-ci à la SPU. S’il n’y a pas de session, le NPU envoie le paquet à une SPU qui est calculée à l’aide de l’algorithme de hachage.

• Unités de traitement des 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 lorsqu’il transite par l’équipement. Chaque SPU gère une table de hachage pour une recherche rapide de session. La SPU applique des filtres de pare-feu sans état, des classificateurs et des traffic shapers au trafic. Une unité de traitement (SPU) effectue tous les traitements basés sur les flux d’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 une interaction minimale entre les SPU du même SPC ou d’un SPC différent. Tous les paquets appartenant au même flux sont traités par la même SPU.

  La SPU gère une table de sessions avec des entrées pour toutes les sessions qu’elle a établies et dont elle traite les paquets. Lorsqu’une SPU reçoit un paquet d’un NPU, elle vérifie sa table de session pour s’assurer que le paquet lui appartient. Il vérifie également sa table de sessions 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’existe pas de session existante pour le paquet.

• Point central : l’architecture de point central est divisée en deux modules, le point central de l’application et le point central distribué. Le point central des applications est responsable de la gestion globale des ressources et de l’équilibrage des charges, tandis que le point central distribué est responsable de l’identification du trafic (correspondance globale des sessions). La fonctionnalité de point central d’application s’exécute sur la SPU de point central dédiée, tandis que la fonctionnalité de point central distribuée est distribuée au reste des SPU. Désormais, les sessions de point central ne se trouvent plus sur la SPU de point central dédiée, mais 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 de 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’appareil.

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

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

• Recherche de session et critères de correspondance des paquets
• Comprendre la création de sessions : traitement des premiers paquets
• Comprendre le traitement accéléré

Comprendre la création de sessions : traitement des premiers paquets

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 ». Le sens des paquets du flux est appelé (a ->b). La direction de la destination à la source est appelée (b->a).

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

Cette section décrit comment un paquet est traité lorsqu’il arrive à un IOC d’entrée du pare-feu SRX Series.

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

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

3. Le NPU vérifie sa table de sessions pour une session existante pour le paquet. (Il compare le tuple du paquet à ceux 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 à la SPU de hachage.

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

Example: Le paquet (a ->b) arrive à NPU1. NPU1 effectue des contrôles d’intégrité et applique des écrans DoS au paquet. NPU1 vérifie sa table de sessions pour une correspondance de uplet, et aucune session existante n’est trouvée. NPU1 transfère le paquet à une SPU.

Étape 2. Le point central distribué crée une session avec l’état « En attente ».

Lorsqu’une NPU reçoit un paquet, elle 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 sessions pour déterminer s’il existe une session pour le paquet reçu du NPU. (Une NPU transfère un paquet au point central distribué car elle ne trouve pas de 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 une unité de protection étendue à utiliser pour la session.

3. À la réception du message de requête, le point central de l’application vérifie sa table de portes pour déterminer s’il existe une porte pour le paquet. Si une porte correspond ou qu’un autre algorithme de distribution de session est déclenché, le point central de l’application sélectionne une autre SPU pour traiter le paquet ; sinon, la SPU (c’est-à-dire la SPU de point central distribuée) est sélectionnée. Enfin, le point central de l’application envoie une réponse de requête au point central distribué.

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

Example: Le point central distribué crée une aile en attente (a ->b) pour la session. Il sélectionne SPU1 à utiliser pour cela. Il envoie à SPU1 le paquet (a->b) avec un message pour créer une session pour celui-ci.

Étape 3. L’USP met en place la séance.

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

1. S’il n’existe aucune session existante pour le paquet, le SPU configure la session localement.

2. La SPU envoie un message au point central distribué lui demandant d’installer la session.

   Remarque :

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

La SPU ajoute à la file d’attente tous les paquets supplémentaires pour le flux qu’elle pourrait recevoir jusqu’à l’installation de la session.

Example: SPU1 crée la session pour (a ->b) et renvoie un message au point central distribué lui demandant 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 de la SPU.

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

2. Le point central distribué installe l’aile inverse de la session en tant qu’aile active.

   Remarque :

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

3. Il envoie un message d’accusé de réception (ACK) à la SPU, indiquant que la session est installée.

Example: Le point central distribué reçoit un message de SPU1 pour installer la session pour l’aile (a->b). Il définit l’état de session pour l’aile (a->b) sur actif. Il installe l’aile inversée (b->a) pour la session et la rend active ; Cela permet de livrer les paquets du sens inverse du flux : la destination (B) à la source (A).

Étape 5. Le SPU configure la session sur les NPU d’entrée et de sortie.

Les NPU conservent les informations sur une session pour le transfert et la livraison des paquets. Les informations de session sont configurées sur les NPU de sortie et d’entrée (qui sont parfois les mêmes) afin que les paquets puissent être envoyés directement à la SPU qui gère leurs flux et non au point central distribué pour être redirigés.

Étape 6. Un traitement accéléré a lieu.

Pour les autres étapes impliquées dans le traitement des paquets, passez à l’étape 1 de Comprendre le traitement fast-path.

La figure 6 illustre la première partie du processus par lequel passe le premier paquet d’un flux une fois qu’il 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, celui-ci et le reste des paquets du flux subissent un traitement accéléré.

Figure 6 : Création de sessions : traitement du premier paquet

Comprendre le traitement accéléré

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

Voici comment fonctionne le traitement accéléré : Les NPU aux interfaces de sortie et d’entrée contiennent des tables de session qui incluent l’identification de la 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 à cette SPU pour traitement.

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

Étape 1. Un paquet arrive à l’appareil et le NPU le traite.

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

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

   La NPU effectue des contrôles d’intégrité et applique certains écrans, tels que des écrans de déni de service (DoS), au paquet.

2. Le NPU identifie une entrée d’une session existante dans sa table de sessions à laquelle le paquet correspond.

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

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

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

La majeure partie du traitement d’un paquet a lieu sur la SPU à laquelle sa session est affectée. Le paquet est traité pour les fonctionnalités basées sur les paquets, telles que les filtres de pare-feu sans état, les traffic shapers 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, le NAT, les 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 de traiter le paquet, la SPU vérifie sa table de sessions pour vérifier que le paquet appartient à l’une de ses sessions.

2. L’USP traite le paquet pour les fonctions et services applicables.

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

Étape 3. Le SPU transmet le paquet au NPU.

1. Le SPU transmet le paquet au NPU.

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

Example: SPU1 transfère le paquet (a ->b) à NPU2, et NPU2 s’applique DoS écrans.

Étape 4. L’interface transmet le paquet à partir de l’appareil.

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

Étape 5. Un paquet de trafic inverse arrive à l’interface de sortie et le NPU le traite.

Cette étape reflète l’étape 1 exactement à l’envers. Voir l’étape 1 de cette section pour plus de détails.

Example: Le paquet (b->a) arrive à NPU2. NPU2 vérifie sa table de sessions pour une correspondance de uplet. Il trouve une correspondance et qu’une session existe pour le paquet sur SPU1. NPU2 transmet le paquet à SPU1 pour traitement.

Étape 6. La SPU de la session traite le paquet de trafic inverse.

Cette étape est la même que l’étape 2, sauf qu’elle s’applique au trafic en sens inverse. Voir l’étape 2 de cette section pour plus de détails.

Example: SPU1 reçoit le paquet (b->a) de NPU2. Il vérifie sa table de sessions pour vérifier que le paquet appartient à la session identifiée par NPU2. Ensuite, il applique au paquet des fonctionnalités basées sur les paquets configurées pour l’interface du NPU1. 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 transmet le paquet de trafic inverse au NPU.

Cette étape est la même que l’étape 3, sauf qu’elle s’applique au trafic en sens inverse. Voir l’étape 3 de cette section pour plus de détails.

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

8. L’interface transmet le paquet à partir de l’appareil.

Cette étape est la même que l’étape 4, sauf qu’elle s’applique au trafic en sens inverse. Voir l’étape 4 de cette section pour plus de détails.

Exemple : L’interface transmet un paquet (b->a) à partir de l’appareil.

La figure 7 illustre le processus par lequel passe un paquet lorsqu’il atteint l’appareil et qu’une session existe pour le flux auquel le paquet appartient.

Figure 7 : Parcours de traitement accéléré des paquets

Comprendre les unités de traitement des services

Pour une interface physique donnée, la SPU reçoit des paquets entrants de tous les processeurs réseau du lot de processeurs réseau associé à l’interface physique. La SPU extrait les informations relatives aux bundles de processeurs réseau de l’interface physique et utilise le même algorithme de hachage à 5 uplets pour mapper un flux à un index de processeur réseau. Pour déterminer le processeur réseau, le SPU effectue une recherche sur l’index du processeur réseau dans le bundle de processeurs réseau. La SPU envoie des paquets de sortie au module d’interface physique (PIM) local de l’interface physique pour le trafic sortant.

Présentation des caractéristiques des planificateurs

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

• IFL : la configuration du bundle de processeurs réseau est stockée dans la structure de données de l’interface physique. Par exemple, les appareils SRX5400, SRX5600 et SRX5800 ont un maximum de 48 PIM. L’interface physique peut utiliser un masque de bits de 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 appareils de la gamme SRX5000, la fonctionnalité iflset n’est pas prise en charge pour les interfaces agrégées telles que reth.

• IFD : interface logique associée à l’interface physique d’un bundle de processeurs réseau est transmise à tous les IOC qui ont un PIM dans le bundle de processeurs réseau.

Comprendre le regroupement des processeurs réseau

La fonctionnalité de regroupement des 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 primaire est affecté à 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 ne peut rejoindre qu’un seul bundle de processeurs réseau.

Vue d’ensemble

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 prendre la forme d’une session, d’un trafic de tunnel GTP-U, d’un trafic de tunnel VPN IPsec, etc. Une conversation comporte deux entrées de cache de session, l’une pour le trafic entrant et l’autre pour le trafic inverse. Selon l’emplacement des ports entrants et sortants du trafic, deux entrées peuvent résider dans le même processeur réseau ou dans des processeurs réseau différents. Les IOC 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 connue sous le nom de déchargement de services) et permet d’éviter les problèmes tels que la latence élevée et la baisse des performances IPsec.

Une entrée de cache de session enregistre :

• À quelle unité de service (SPU) le trafic de la conversion doit être transféré

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

• Traitement du trafic sortant, par exemple, la traduction NAT en mode Express Path

Les autres trafics ont été hachés vers les SPU en fonction de leurs informations clés à 5 uplets. Le trafic VPN utilisait 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 à la SPU de flux qu’en se basant sur le hachage à 5 uplets. La SPU de flux a ensuite transféré le paquet à la SPU ancrée. Cela créait un saut supplémentaire pour le trafic VPN, ce qui gaspillait la bande passante de la fabric du commutateur et réduisait le débit VPN de moitié environ. Cette réduction des performances s’est produite parce que le trafic devait toujours retourner à la SPU de flux après le traitement sur la SPU ancrée.

La table de cache de session est maintenant é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 localement ou vers un autre IOC, car le trafic ne nécessite aucun service de la part de l’unité de protection des données. Le trafic NP est transféré à la SPU spécifiée dans le cache de session pour un traitement ultérieur. Toutes les entrées de cache de session sont partagées 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.

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 à la fois au module de flux et à l’IOC.

Les IOC maintiennent et surveillent les niveaux seuils d’utilisation du cache de session. Les IOC communiquent également l’utilisation du cache de session à la SPU, de sorte que lorsqu’un certain seuil d’utilisation du cache de session est atteint, la SPU envoie uniquement les demandes d’installation de cache de session pour les sessions de trafic sélectives à haute priorité.

Les applications comme IDP et ALG doivent traiter les paquets dans l’ordre. Une SPU a plusieurs threads de flux pour gérer les paquets appartenant à une session, le thread d’équilibrage de charge (LBT) et le thread d’ordre des paquets (POT) peut s’assurer que le trafic passe à travers le pare-feu dans l’ordre, il ne peut pas garantir que l’application traite les paquets qui appartiennent à la même session dans l’ordre. La sérialisation de flux fournit la méthode selon laquelle un seul paquet de traitement de thread de flux SPU appartient à 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 effectuer le traitement de sérialisation de flux pour d’autres sessions en même temps.

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 trafic NAT/SZ (sérialisation de session)

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

Les IOC maintiennent et surveillent les niveaux seuils d’utilisation du cache de session et mettent à jour l’utilisation actuelle du cache de session en temps réel sur la SPU. L’USP demande à l’IOC d’installer le cache de session pour certaines sessions de trafic à priorité élevée. L’utilisation du cache de session pour les sessions de trafic prioritaire est définie dans le tableau :

Pour conserver les entrées de session sur l’IOC, le module de flux installe sélectivement les sessions sur l’IOC. Pour faciliter la sélection de l’installation de session, l’IOC maintient des seuils correspondants pour fournir une indication au module de flux (sur le niveau de remplissage de la table de cache de session sur les IOC). Deux bits dans le méta-en-tête sont ajoutés pour indiquer l’état d’utilisation actuel de la table de cache. Tous les paquets allant à la SPU porteront 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é de session avec VPN IPsec à l’aide du cache de session

Les pare-feu SRX Series sont des systèmes entièrement distribués, dans lesquels un tunnel IPsec est alloué et ancré à une SPU spécifique. L’ensemble du trafic appartenant à un tunnel IPsec est chiffré et déchiffré sur sa SPU ancrée 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 et après déchiffrement) sur sa SPU ancrée dans un tunnel, et installe un cache de session pour les sessions afin que l’IOC puisse rediriger les paquets directement vers la même SPU afin de minimiser la surcharge 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échargement de services) sur le concentrateur PIC flexible (FPC) sélectionné.

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

Fragmentation : classement des paquets à l’aide du cache de session NP

Une session peut être composée de paquets normaux et fragmentés. Grâce à la distribution basée sur le hachage, les clés à 5 et 3 uplets peuvent être utilisées pour distribuer des paquets normaux et fragmentés à différentes SPU, respectivement. Sur les pare-feu SRX Series, tous les paquets de la session sont transférés à une unité SPU de traitement. En raison de la latence de transfert et de traitement, la SPU de traitement peut ne pas garantir l’ordre des paquets de la session.

Le cache de session sur les IOC assure l’ordre des paquets d’une session avec des paquets fragmentés. Une entrée de cache de session est allouée aux paquets normaux de la session et une clé à 3 uplets est utilisée pour trouver les paquets fragmentés. À la réception du premier paquet fragmenté de la session, le module de flux permet à l’IOC de mettre à jour l’entrée du cache de session afin de mémoriser les paquets fragmentés pour la SPU. Par la suite, IOC transfère tous les paquets suivants de la session à la SPU pour s’assurer de l’ordre des paquets d’une session contenant des paquets fragmentés.