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

Comprendre le traitement basé sur les flux

Un paquet est soumis à un traitement basé sur le flux après que des filtres basés sur les paquets et certains écrans lui ont été appliqués. Tous les traitements basés sur les flux d’un flux unique sont effectués 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 montre une vue conceptuelle de la façon dont le traitement du trafic basé sur les flux se produit sur la passerelle de services.

Figure 1 : flux de trafic pour un 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 (par exemple, la stratégie de sécurité qui lui est applicable, s’il nécessite une passerelle de couche applicative (ALG), si 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 se basant sur les 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 fait l’objet d’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 discrets.

• 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’équipement, 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, l’USP fait référence au thread du plan de données du pare-feu SRX210 ou SRX320.

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

Comprendre le traitement du premier paquet

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 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 donnée et d’un routeur virtuel

L’USP vérifie sa table de session à la recherche d’une session existante pour le paquet. Si aucune session existante n’est trouvée, l’USP 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 l’USP effectue un traitement rapide sur le paquet.

Comprendre la création de sessions

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

• Écrans

• Recherche d’itinéraire

• Recherche de stratégie

• Recherche de service

• 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 le reste des étapes du traitement des paquets, passez à l’étape 1 de la section « Traitement accéléré ». Tous les paquets font l’objet d’un traitement accéléré.

Comprendre le traitement accéléré

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

1. L’USP 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. L’USP 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.

Composants impliqués dans la configuration d’une session

Voici une vue d’ensemble des principaux composants impliqués dans la configuration d’une session pour un paquet et le traitement des paquets lorsqu’ils transitent par les périphériques SRX3400 et SRX3600 :

• Unités de traitement des services (SPU) : les processeurs principaux des périphériques SRX3400 et SRX3600 résident sur des cartes de traitement des services (SPC). Ils é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’appareil. Chaque SPU gère une table de hachage pour une recherche rapide des sessions. Le SPU effectue tous les traitements basés sur les flux d’un paquet, y compris l’application des services de sécurité, des classificateurs et des façonneurs de trafic. Tous les paquets appartenant au même flux sont traités par le même SPU.

  L’USP 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’un SPU reçoit un paquet d’un NPU, il vérifie sa table de sessions pour s’assurer que le paquet lui appartient.

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

• Point central : le point central permet d’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 que plusieurs SPU ne gèrent à tort le même flux. Le point central suit des critères d’équilibrage de charge lors de l’attribution des sessions aux SPU. Si la session existe, le point central transmet les paquets de ce flux à l’USP qui l’héberge. Il redirige également les paquets vers le bon SPU dans le cas où le NPU ne le fait pas.

  Pour les appareils SRX3400 et SRX3600, une SPU s’exécute toujours en mode combiné, dans lequel elle met en œuvre à la fois la fonctionnalité du point central et la fonctionnalité de gestion des flux et des sessions. En mode combo, l’unité SPU et le point central partagent la même infrastructure LBT (Load-Balancing Thread) et POT (Packet-Ordering Thread). .

• Moteur de routage (RE) : le moteur de routage exécute le plan de contrôle et gère le processeur de 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 le périphérique.

Pour illustrer l’établissement d’une session 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 rassemble 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 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 donnée et d’un routeur virtuel

Comprendre la création d’une session : traitement du premier paquet

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

1. Un paquet arrive à une interface de l’appareil et l’IOC le traite.

   L’IOC retire le paquet de la file d’attente 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 contrôles d’intégrité de base sur le paquet et applique au paquet certains écrans configurés pour l’interface.

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

   Exemple : Le paquet (a ->b) arrive à NPU1 à partir de IOC1. NPU1 effectue des vérifications d’intégrité et applique des écrans de déni de service au paquet. NPU1 vérifie sa table de sessions à la recherche d’une correspondance de tuple et aucune session existante n’est trouvée. NPU1 transmet le paquet au point central de SPU1 pour qu’il l’assigne à un SPU.

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

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

   Ce processus comprend les parties suivantes :

   1. Le point central vérifie sa table de session 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 au point central parce que sa table indique qu’il n’y a pas de session pour celui-ci. Le point central vérifie ces informations avant d’allouer une SPU pour la session.)

   2. S’il n’y a pas d’entrée qui correspond au paquet dans l’une ou l’autre des tables, 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 transmet le premier paquet du flux à l’USP sélectionnée 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 (a ->b) pour la session. Il sélectionne SPU1 à utiliser pour la session. Il envoie à 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 fonctionne en mode combo. Par conséquent, ses services de gestion et de traitement de flux sont utilisés pour la session.

4. L’USP 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 sessions pour s’assurer qu’aucune session n’existe déjà pour le paquet.

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

   2. L’USP envoie un message au point central pour lui demander d’installer la session.

   Lors du traitement du premier paquet, si NAT est activé, l’USP 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’allocation NAT soit terminé.

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

   Exemple : SPU1 crée la session pour (a ->b) et renvoie 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 de l’aile en attente de la session sur actif.

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

   • Il envoie un message d’accusé de réception au SPU, indiquant que la session est installée.

   Exemple : Le point central reçoit un message de SPU1 lui demandant d’installer la session pour (a->b). Il définit l’état de session pour (a->b) wing sur actif. Il installe l’aile arrière (b->a) pour la séance et la rend active ; Cela permet d’acheminer les paquets dans le sens inverse du flux : la destination (B) pour être livrés à la source (A).

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

   Les NPU conservent des 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 à l’USP qui gère leurs flux et non au point central pour redirection.

7. Un traitement accéléré a lieu.

   Pour le reste des étapes du traitement des paquets, passez à l’étape 1 de la section « Comprendre le traitement accéléré ».

Comprendre le traitement accéléré

Tous les paquets font l’objet d’un traitement accéléré. Toutefois, s’il existe une session pour un paquet, celui-ci subit un traitement rapide et contourne le processus du premier paquet. Lorsqu’il existe déjà une session pour le flux du paquet, celui-ci ne transite pas par le point central.

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

Sur les périphériques SRX1400, SRX3400 et SRX3600, la fonctionnalité iflset n’est pas prise en charge pour les interfaces agrégées telles que reth.

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 l’USP 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 à partir de l’appareil. (Cette description de haut niveau n’aborde pas l’application de 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 sont également soumis à un traitement accéléré ; Dans ce cas, une fois que chaque paquet entre dans la session et que le NPU lui a trouvé une correspondance dans sa table de session, le NPU transmet le paquet à l’SPU qui gère sa session.

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

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 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 session 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 un SPU pour un paquet qui est précédemment entré dans le périphérique via l’interface et qui a été traité par ce NPU. L’UPS installe la session dans la table NPU lors de la création de la session.

  Un NPU détermine si une session existe pour un paquet en comparant les informations du paquet à sa table de session. Si le paquet correspond à une session existante, le NPU envoie le paquet et les métadonnées correspondantes au SPU. S’il n’y a pas de session, les NPU envoient 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 périphériques 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 des sessions. L’USP applique au trafic des filtres, des classificateurs et des modélisateurs de trafic sans état. Un 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 indépendamment avec un minimum d’interaction entre les SPU sur le même SPC ou sur un SPC différent. Tous les paquets appartenant au même flux sont traités par le même SPU.

  L’USP 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’un SPU reçoit un paquet d’un NPU, il vérifie sa table de sessions pour s’assurer que le paquet 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’existe pas de session existante pour le paquet.

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

Pour illustrer l’établissement d’une session 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 rassemble 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 de paquets
• Comprendre la création de session : traitement du premier paquet
• Comprendre le traitement accéléré

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

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

Cette section décrit comment un paquet est traité lorsqu’il arrive à un IOC d’entrée de 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 contrôles d’intégrité de base sur le paquet et applique au paquet certains écrans configurés pour l’interface.

3. Le NPU vérifie que sa table de session contient une session existante pour le paquet. (Il compare le tuple du paquet à celui des paquets des sessions existantes dans sa table de sessions.)

   1. Si aucune session existante n’est trouvée, le NPU transfère le paquet au 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é attribué, de sorte que le NPU transmet le paquet au SPU pour traitement avec l’ID de session.

Example: Le paquet (a ->b) arrive à NPU1. NPU1 effectue des vérifications d’intégrité et applique des écrans de déni de service au paquet. NPU1 vérifie sa table de session à la recherche d’une correspondance de tuple, et aucune session existante n’est trouvée. NPU1 transfère le paquet à un SPU.

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

Lorsqu’un NPU reçoit un paquet, il 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 parties suivantes :

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. (Un NPU transfère un paquet au point central distribué car il 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 qu’il sélectionne un SPU à 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 est mise en correspondance ou si 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 ; sinon, le SPU (c’est-à-dire le SPU du point central distribué) est sélectionné. 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 en cours de flux à l’USP sélectionnée dans un message lui demandant de configurer localement une session à 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 pour 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) ainsi qu’un message pour créer une session pour lui.

Étape 3. L’USP configure la session.

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

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

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

   Note:

   Lors du traitement du premier paquet, si NAT est activé, l’USP 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’allocation NAT soit terminé.

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

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 du 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 arrière de 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’initialisation.

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

Example: Le point central distribué reçoit un message de SPU1 lui demandant d’installer la session pour l’aile (a->b). Il définit l’état de session de l’aile (a->b) sur actif. Il installe l’aile arrière (b->a) pour la séance et la rend active ; Cela permet d’acheminer les paquets dans le sens inverse du flux : la destination (B) pour être livrés à la source (A).

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

Les NPU conservent des 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 à l’USP qui gère leurs flux et non au point central distribué pour redirection.

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

Pour le reste des étapes du traitement des paquets, passez à l’étape 1 de la section Comprendre le traitement accéléré.

La figure 6 illustre la première partie du processus par laquelle subit le premier paquet d’un flux une fois qu’il a atteint l’appareil. À ce stade, une session est mise en place pour traiter le paquet et le reste des paquets appartenant à son flux. Par la suite, lui et le reste des paquets du flux sont soumis à un traitement rapide.

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

Comprendre le traitement accéléré

Tous les paquets font l’objet d’un traitement accéléré. Toutefois, s’il existe une session pour un paquet, celui-ci subit un traitement rapide et contourne le processus du premier paquet. Lorsqu’il existe déjà une session pour le flux du paquet, celui-ci ne transite pas par le point central.

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

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

Étape 1. Un paquet arrive à l’équipement 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 de la carte.

   Le NPU effectue des vérifications 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 pour une session existante dans sa table de sessions à laquelle le paquet correspond.

3. Le NPU transfère le paquet avec les métadonnées de sa table de session, y compris l’ID de session et les informations de tuple du paquet, à l’USP 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 du paquet et l’application de la sécurité et d’autres fonctionnalités.

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

Étape 2. L’unité SPU de la session traite le paquet.

La majeure partie du traitement d’un paquet s’effectue sur l’unité de distribution à 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 modélisateurs 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, les 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, l’UPS 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 fonctionnalités et les 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 les paquets (a ->b) en fonction des filtres d’entrée et des fonctionnalités CoS qui s’appliquent à son interface d’entrée. L’USP lui applique les fonctionnalités et services de sécurité configurés pour le flux du paquet, en fonction de sa zone et de ses stratégies. S’il y en a, il applique des filtres de sortie, des modélisateurs de trafic et des écrans supplémentaires au paquet.

Étape 3. L’USP transfère le paquet à la NPU.

1. L’USP transmet le paquet au NPU.

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

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

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

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

É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 en sens inverse. Reportez-vous à l’étape 1 de cette section pour plus de détails.

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

Étape 6. L’unité SPU de la session traite le paquet de trafic inverse.

Cette étape est identique à l’étape 2, sauf qu’elle s’applique au trafic inverse. Reportez-vous à 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 session pour vérifier que le paquet appartient bien à la session identifiée par NPU2. Ensuite, il applique au paquet les 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. L’USP transfère le paquet de trafic inverse au NPU.

Cette étape est identique à l’étape 3, sauf qu’elle s’applique au trafic inverse. Reportez-vous à 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 identique à l’étape 4, sauf qu’elle s’applique au trafic inverse. Reportez-vous à l’étape 4 de cette section pour plus de détails.

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

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

Figure 7 : Packet Walk pour un traitement accéléré

Présentation des unités de traitement des services

Pour une interface physique donnée, l’USP reçoit les paquets entrants de tous les processeurs réseau du bundle de processeurs réseau associé à l’interface physique. L’UPS extrait les informations du bundle 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, l’USP effectue une recherche sur l’index du processeur réseau dans le bundle de processeurs réseau. Le SPU envoie les paquets sortants au module d’interface physique (PIM) local de l’interface physique pour le trafic sortant.

Présentation des caractéristiques du planificateur

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

• 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 équipements 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 provenant 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 telles que reth.

• IFD : l’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 de processeurs réseau

La fonction 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 principal est affecté à une interface qui reçoit le trafic entrant et distribue les paquets à plusieurs autres processeurs réseau secondaires. Un processeur réseau unique peut agir comme un processeur réseau principal ou comme un processeur réseau secondaire pour plusieurs interfaces. Un seul processeur réseau ne peut rejoindre qu’un seul ensemble de processeurs réseau.

Aperçu

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 l’USP sur un IOC. Il peut s’agir 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 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 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 tire parti de la fonctionnalité Express Path (anciennement appelée déchargement des services) et permet d’éviter des problèmes tels qu’une latence élevée et une baisse des performances IPsec.

Une entrée de cache de session enregistre :

• Vers quelle USP le trafic de la conversion doit-il être transféré ?

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

• Le 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 dans l’IOC permet de résoudre certains problèmes de performances. L’USP peut désormais demander au cache de session IOC de transférer le trafic ultérieur 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é de session 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, l’affinité de session VPN via le cache de session est prise en charge sur l’IOC2.

Le reste du trafic a été haché 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 transmettre les paquets qu’à l’USP de flux en se basant sur le hachage à 5 uplets. L’USP de flux a ensuite transféré le paquet à l’UPU 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 d’environ la moitié. Cette réduction des performances s’est produite parce que le trafic devait toujours revenir à l’USP de flux après traitement sur l’UPU 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 il ne nécessite aucun service de la part du SPU. Le trafic NP est transféré vers l’unité 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

Afin d’éviter une latence élevée, d’améliorer les performances IPSec et de 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 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 envoie uniquement des demandes d’installation de cache de session pour des sessions de trafic sélectives à haute priorité.

Des applications telles que l’IDP ou 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 des paquets POT (Packet-Ordering Thread) 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 appartenant à la même session dans l’ordre. La sérialisation de flux permet à un seul paquet de traitement de thread de flux SPU d’appartenir à 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 la 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 NAT/SZ (sérialisation de session)

• 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. L’USP 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 à haute priorité est définie dans le tableau :

Pour conserver les entrées de session sur l’IOC, le module de flux installe de manière sélective les sessions sur l’IOC. Pour faciliter la sélection de l’installation de session, l’IOC maintient les 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 l’en-tête meta sont ajoutés pour indiquer l’état d’utilisation actuel de la table de cache. Tous les paquets à destination de l’USP porteront ces deux bits d’état pour informer le module de flux de l’utilisation de la table de cache sur l’IOC.

VPN IPsec : amélioration de l’affinité de session à l’aide du cache de session

Les pare-feu 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 le tunnel. Afin d’obtenir de meilleures performances IPsec, IOC améliore le module de flux afin de 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 le 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 des 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.

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

Une session peut être constituée de paquets normaux et fragmentés. Avec la distribution basée sur le hachage, les clés à 5 et 3 tuples peuvent être utilisées pour distribuer des paquets normaux et fragmentés à différents SPU, respectivement. Sur les pare-feu SRX Series, tous les paquets de la session sont transférés à un SPU de traitement. En raison de la latence de transfert et de traitement, l’unité 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 pour les paquets normaux de la session et une clé à 3 tuples est utilisée pour rechercher 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 pour mémoriser les paquets fragmentés pour le SPU. Par la suite, IOC transmet tous les paquets suivants de la session à l’USP pour assurer l’ordre des paquets d’une session avec des paquets fragmentés.