Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Présentation de la protection contre les attaques par déni de service distribué (DDoS) du plan de contrôle

Une attaque par déni de service (DoS) est une tentative de refuser à des utilisateurs valides l’accès aux ressources du réseau ou du serveur en utilisant toutes les ressources de l’élément réseau ou du serveur. Les attaques par déni de service distribué (DDoS) impliquent une attaque provenant de plusieurs sources, ce qui permet à une quantité beaucoup plus importante de trafic d’attaquer le réseau. Les attaques utilisent généralement des paquets de contrôle de protocole réseau pour déclencher un grand nombre d’exceptions au plan de contrôle de l’équipement. Il en résulte une charge de traitement excessive qui perturbe les opérations normales du réseau.

Grâce à un point unique de gestion de la protection DDoS, les administrateurs réseau peuvent personnaliser les profils de leur trafic de contrôle réseau. Pour les routeurs, la protection et la surveillance persistent à travers le basculement GRES (Graceful Moteur de routage ) et les basculements ISSU (Unified In-Service-Software-Upgrade). La protection n’est pas diminuée par l’augmentation du nombre d’abonnés.

Mécanismes de contrôle du trafic lié à l’hôte pour les violations DDoS

Pour protéger le plan de contrôle contre les attaques DDoS, les mécanismes de contrôle sont activés par défaut sur les périphériques pour le trafic lié à l’hôte. Si nécessaire, vous pouvez modifier de nombreuses valeurs par défaut du mécanisme de contrôle. Le trafic lié à l’hôte est le trafic destiné au moteur de routage, y compris les paquets de contrôle de protocole pour les protocoles de routage, tels que OSPF et BGP. Le trafic destiné aux adresses IP des routeurs est également considéré comme du trafic lié à l’hôte.

Les mécanismes de contrôle spécifient des limites de débit pour l’ensemble du trafic de contrôle d’un protocole donné ou, dans certains cas, pour des types de paquets de contrôle spécifiques pour un protocole. Vous pouvez surveiller les actions du mécanisme de contrôle pour les types de paquets et les groupes de protocoles au niveau de l’équipement, du moteur de routage et des cartes de ligne. Vous pouvez également contrôler la journalisation des événements du mécanisme de contrôle.

Les appareils abandonnent le trafic de contrôle lorsqu’il dépasse les valeurs par défaut ou configurées du mécanisme de contrôle. Lorsqu’une violation DDoS se produit, l’équipement n’arrête pas de traiter les paquets. cela ne fait que limiter leur taux. Chaque violation génère immédiatement une notification pour alerter les opérateurs d’une éventuelle attaque. L’appareil compte la violation et note l’heure à laquelle la violation commence et l’heure de la dernière violation observée. Lorsque le débit de trafic tombe en dessous du seuil de violation de la bande passante, un minuteur de récupération détermine à quel moment le flux de trafic est considéré comme étant revenu à la normale. Si aucune autre violation ne se produit avant l’expiration du minuteur, l’appareil efface l’état de violation et génère une notification.

Note:

Sur les routeurs PTX et les commutateurs QFX Series, le minuteur est réglé sur 300 secondes et ne peut pas être modifié.

La première ligne de protection est le mécanisme de contrôle du moteur de transfert de paquets (PFE). Sur les équipements comportant plusieurs cartes de ligne, les états des mécanismes de contrôle et les statistiques de chaque carte de ligne sont relayés au moteur de routage et agrégés. Les états de contrôle sont conservés lors d’un basculement. Bien que les statistiques des cartes de ligne et le nombre de violations soient conservés lors d’un basculement, les statistiques du mécanisme de contrôle du moteur de routage ne le sont pas. Le trafic de contrôle arrivant de tous les ports de la carte de ligne converge vers le moteur de transfert de paquets, où il est contrôlé, abandonnant les paquets excédentaires avant qu’ils n’atteignent le moteur de routage et veillant à ce que le moteur de routage ne reçoive que la quantité de trafic qu’il peut traiter.

Les routeurs ACX Series qui prennent en charge cette fonctionnalité prennent uniquement en charge les mécanismes de contrôle agrégés et ne prennent pas en charge le contrôle au niveau de la carte de ligne. Vous pouvez modifier les valeurs par défaut du mécanisme de contrôle au niveau du moteur de routage globalement ou pour des groupes de protocoles spécifiques, ce qui se propage jusqu’au niveau du chipset PFE. Cependant, vous ne pouvez pas appliquer de paramètres de mise à l’échelle supplémentaires au niveau de la carte de ligne comme sur d’autres appareils. Vous pouvez désactiver le contrôle au niveau du moteur de routage globalement ou pour des groupes de protocoles spécifiques. La désactivation globale du contrôle désactive efficacement la protection DDoS du plan de contrôle sur l’appareil.

Les commutateurs et les routeurs PTX Series de la série QFX10000 appliquent les limites de protection contre les DDoS à trois niveaux : dans le chipset PFE, la carte de ligne et le moteur de routage.

En plus de fournir une notification des violations par le biais de la journalisation des événements, la protection DDoS du plan de contrôle vous permet de surveiller les mécanismes de contrôle et d’obtenir des informations telles que la configuration des mécanismes de contrôle, le nombre de violations rencontrées, la date et l’heure des violations, les taux d’arrivée des paquets et le nombre de paquets reçus ou abandonnés.

Note:

Les mécanismes de contrôle de la protection DDoS du plan de contrôle agissent sur les files d’attente de trafic du système. Les lignes de commutateurs QFX5100 et QFX5200 gèrent le trafic pour un nombre de protocoles supérieur au nombre de files d’attente. Le système doit donc souvent mapper plusieurs protocoles à la même file d’attente. Lorsque le trafic d’un protocole partage une file d’attente avec d’autres protocoles et enfreint les limites du mécanisme de contrôle de la protection DDoS, ces périphériques signalent une violation sur cette file d’attente pour tous les protocoles mappés, car le système ne distingue pas le trafic du protocole qui a spécifiquement causé la violation. Vous pouvez utiliser ce que vous savez sur les types de trafic qui transitent par votre réseau pour identifier lequel des protocoles signalés a réellement déclenché la violation.

Assistance pour la plate-forme

Dans Junos OS version 14.2 et ultérieures, la protection DDoS du plan de contrôle est prise en charge sur des plates-formes spécifiques. En général, la protection DDoS du plan de contrôle est activée par défaut sur certains modèles des plates-formes suivantes, et prennent en charge les options de configuration permettant de modifier les paramètres par défaut du mécanisme de contrôle :

  • Routeurs ACX Series.

  • Commutateurs EX9200.

  • Routeurs MX Series sur lesquels seuls des MPC sont installés.

  • Routeurs MX Series avec MPC intégré.

    Note:

    Pour simplifier, lorsque le texte fait référence à des cartes de ligne ou à des mécanismes de contrôle de carte de ligne, cela signifie pour ces routeurs le MPC intégré.

    Étant donné que ces routeurs n’ont pas d’emplacements FPC, les informations affichées dans FPC les champs par show les commandes se réfèrent en fait à TFEB.

  • PTX Series routeurs sur lesquels seuls des FPC basés sur PE sont installés (PTX3000, PTX5000, PTX1000 et PTX10000) prennent en charge la protection DDoS du plan de contrôle à partir de Junos OS version 17.4R1.

    PTX10002 routeurs prennent en charge la protection DDoS du plan de contrôle à partir de la version Junos OS 18.2R1.

    PTX10003 routeurs prennent en charge la protection DDoS du plan de contrôle à partir de Junos OS Evolved version 19.3R1.

    PTX10004 routeurs prennent en charge la protection DDoS du plan de contrôle à partir de Junos OS Evolved version 20.3R1.

    PTX10008 routeurs prennent en charge la protection DDoS du plan de contrôle à partir de Junos OS Evolved version 20.1R1.

  • QFX Series commutateurs, notamment le Gamme QFX5100, la ligne QFX5200 et la Gamme QFX10000 de commutateurs.

    Les commutateurs QFX10002-60C prennent en charge la protection DDoS du plan de contrôle à partir de la version Junos OS 18.1R1.

  • Les routeurs T4000 sur lesquels seuls des FPC de type 5 sont installés.

Note:
  • Sur les plates-formes Junos Evolved, vous devez configurer la famille de protocoles et/ou inet6 la inet famille de protocoles sur l'interface lo0 du périphérique pour que la protection DDoS fonctionne respectivement pour ces familles de protocoles.

  • Certains commutateurs EX Series peuvent être protégés contre les attaques DDoS par le plan de contrôle, mais ne prennent pas en charge les options CLI permettant d’afficher ou de modifier les paramètres de contrôle par défaut.

  • Pour les plates-formes de routeur qui ont d’autres cartes de ligne en plus des MPC (MX Series), des FPC de type 5 (T4000) ou des FPC basés sur PE (PTX3000, PTX5000, PTX1000 et PTX10000), la CLI accepte la configuration, mais les autres cartes de ligne ne sont pas protégées, de sorte que le routeur n’est pas protégé.

  • La prise en charge de la protection DDoS du plan de contrôle pour la gestion améliorée des abonnés a été ajoutée dans Junos OS version 17.3R1 sur les plates-formes de routage.

  • Pour modifier les paramètres de protection DDoS du plan de contrôle configuré par défaut pour les groupes de protocoles et les types de paquets pris en charge, les routeurs ACX Series, les routeurs PTX Series et les commutateurs QFX Series disposent doptions de configuration CLI sensiblement différentes des options disponibles pour les routeurs MX Series et T4000. Consultez les instructions de configuration suivantes pour connaître les options de configuration disponibles sur différents périphériques :

Types de mécanismes de contrôle et priorités des paquets

La protection DDoS du plan de contrôle comprend deux types de mécanismes de contrôle :

  • Un mécanisme de contrôle d’agrégation est appliqué à l’ensemble complet des types de paquets appartenant à un groupe de protocoles. Par exemple, vous pouvez configurer un mécanisme de contrôle d’agrégation qui s’applique à tous les types de paquets de contrôle PPPoE ou à tous les types de paquets de contrôle DHCPv4. Vous pouvez spécifier des limites de bande passante (paquets par seconde [pps]) et de rafale (paquets dans une rafale), mettre à l’échelle les limites de bande passante et de rafale, et définir une priorité de trafic pour les mécanismes de contrôle d’agrégation. Un mécanisme de contrôle d’agrégation est pris en charge par tous les groupes de protocoles.

  • Un mécanisme de contrôle individuel, également appelé mécanisme de contrôle de type paquet, est alloué à chaque type de paquet de contrôle au sein d’un groupe de protocoles. Par exemple, vous pouvez configurer un mécanisme de contrôle pour un ou plusieurs types de paquets de contrôle PPPoE, de paquets de contrôle RADIUS ou de paquets d’écoute multicast. Vous pouvez spécifier des valeurs limites de bande passante (pps) et de rafale (paquets), mettre à l’échelle les limites de bande passante et de rafales, et définir une priorité de trafic pour les mécanismes de contrôle de type paquets. Des mécanismes de contrôle individuels sont disponibles pour certains groupes de protocoles.

La prise en charge des groupes de protocoles et des types de paquets varie selon les plates-formes et les versions de Junos OS, comme suit :

Un paquet de contrôle est contrôlé d’abord par son mécanisme de contrôle individuel (s’il est pris en charge), puis par son mécanisme de contrôle agrégé. Un paquet abandonné par le mécanisme de contrôle individuel n’atteint jamais le mécanisme de contrôle agrégé. Un paquet qui passe par le mécanisme de contrôle individuel peut ensuite être abandonné par le mécanisme de contrôle d’agrégation.

Note:

Les routeurs ACX Series prennent uniquement en charge le mécanisme de contrôle d’agrégation pour les groupes de protocoles pris en charge.

Les types de paquets au sein d’un groupe de protocoles ont une priorité configurable par défaut : faible, moyenne ou élevée. Chaque paquet de contrôle est en concurrence avec d’autres paquets pour la bande passante dans la limite de débit imposée par son mécanisme de contrôle d’agrégation en fonction de la priorité configurée pour chaque type de paquet dans le groupe de protocoles.

Le mécanisme de priorité est absolu. Le trafic à haute priorité obtient de la bande passante de préférence au trafic de priorité moyenne et faible. Le trafic de priorité moyenne obtient de la bande passante de préférence au trafic de faible priorité. Le trafic de faible priorité ne peut utiliser que la bande passante laissée par le trafic de priorité élevée et de priorité moyenne. Si le trafic de priorité supérieure consomme toute la bande passante, tout le trafic de priorité inférieure est abandonné.

Dans les versions antérieures à Junos OS version 23.2R1, sur les équipements MX Series, le type de carte de ligne du périphérique détermine la priorité par déni de service distribué (DDoS) des protocoles entrants. À partir de Junos OS version 23.2R1, le périphérique détermine la priorité DDoS d’un protocole en fonction de la table des paramètres DDoS. Cette amélioration permet à l'équipement de traiter tous les paquets d'un protocole particulier de la même manière par défaut, quelle que soit la carte de ligne de l'appareil. Vous pouvez modifier le tableau des paramètres DDoS à l’aide de l’interface de ligne de commande. Cette fonctionnalité améliore la cohérence dans la façon dont les appareils du réseau hiérarchisent les protocoles pour se protéger contre les attaques DDoS.

Exemple de comportement de priorité du mécanisme de contrôle

Par exemple, sur un périphérique qui prend en charge la protection DDoS du plan de contrôle pour le groupe de protocoles PPPoE, réfléchissez à la manière dont vous pouvez configurer les types de paquets au sein de ce groupe de protocoles. Si l’on ignore les autres types de paquets PPPoE pour cet exemple, supposons que vous configuriez des mécanismes de contrôle individuels pour les paquets PADI et PADT, ainsi qu’un mécanisme de contrôle d’agrégation PPPoE pour tous ces paquets. Vous donnez la priorité aux paquets PADT par rapport aux paquets PADI, car les paquets PADT permettent à l’application PPPoE de libérer des ressources pour accepter de nouvelles connexions. Par conséquent, vous attribuez une priorité élevée aux paquets PADT et une priorité basse aux paquets PADI.

Le mécanisme de contrôle d’agrégation impose une limite de débit total de paquets pour le groupe de protocoles. Les paquets PADT transmis par leur mécanisme de contrôle individuel ont accès à cette bande passante avant les paquets PADI transmis par leur mécanisme de contrôle individuel, car les paquets PADT ont une priorité plus élevée. Si tant de paquets PADT sont passés qu’ils utilisent toute la bande passante disponible, alors tous les paquets PADI sont abandonnés, car il n’y a plus de bande passante restante au niveau du mécanisme de contrôle d’agrégation.

Exemple de hiérarchie de mécanismes de contrôle

Les mécanismes de contrôle DDoS du plan de contrôle sont organisés de manière à correspondre au flux hiérarchique du trafic de contrôle de protocole. Le trafic de contrôle provenant de tous les ports d’une carte de ligne converge vers le moteur de transfert de paquets. Le trafic de contrôle de toutes les cartes de ligne sur le routeur converge vers le moteur de routage. De même, les mécanismes de contrôle DDoS sont placés hiérarchiquement le long des chemins de contrôle afin que les paquets excédentaires soient abandonnés le plus tôt possible sur le chemin. Cette conception préserve les ressources système en supprimant le trafic malveillant excédentaire afin que le moteur de routage ne reçoive que la quantité de trafic qu’il peut traiter.

Pour implémenter cette conception sur les routeurs MX Series, par exemple, cinq mécanismes de contrôle DDoS sont présents : un sur le moteur de transfert de paquets (le chipset), deux sur la carte de ligne et deux sur le moteur de routage. Un mécanisme de contrôle agrégé est également présent sur le moteur de transfert de paquets pour certains groupes de protocoles, pour un total de six mécanismes de contrôle ; Pour simplifier, le texte suit le cas général. Par exemple, la Figure 1 illustre le processus de contrôle pour le trafic PPPoE. La Figure 2 illustre le processus de contrôle pour le trafic DHCPv4. (Le même processus s’applique également au trafic DHCPv6.)

Note:

Rappelez-vous que les routeurs PTX Series et les commutateurs QFX Series ont une conception plus simple avec des mécanismes de contrôle dans le moteur de transfert de paquets uniquement. Les routeurs PTX10003 et PTX10008 appliquent les limites de protection DDoS du plan de contrôle à trois niveaux, deux au niveau du chipset et de la carte de ligne moteur de transfert de paquets et un au niveau du moteur de routage. Toutefois, les mécanismes de contrôle du type de paquet et de l’agrégat fonctionnent de la même manière sur toutes ces plates-formes.

Figure 1 : hiérarchie des mécanismes de contrôle pour les paquets Policer Hierarchy for PPPoE Packets PPPoE

Figure 2 : Hiérarchie des mécanismes de contrôle pour les paquets Policer Hierarchy for DHCPv4 Packets DHCPv4

Les paquets de contrôle arrivent au moteur de transfert de paquets pour traitement et transfert. Le premier mécanisme de contrôle (1) est soit un mécanisme de contrôle individuel (Figure 1), soit un mécanisme de contrôle agrégé (Figure 2).

  • Le premier mécanisme de contrôle est un mécanisme de contrôle individuel pour les groupes de protocole qui prennent en charge les mécanismes de contrôle individuels, à deux exceptions près. Pour le trafic DHCPv4 et DHCPv6, le premier mécanisme de contrôle est un mécanisme de contrôle d’agrégation.

  • Le premier mécanisme de contrôle est un mécanisme de contrôle d’agrégation pour les groupes de protocoles qui ne prennent en charge que les mécanismes de contrôle d’agrégation.

Le trafic qui passe par le premier mécanisme de contrôle est surveillé par l’un ou les deux mécanismes de contrôle de la carte de ligne. Si la carte possède plusieurs moteurs de transfert de paquets, le trafic de tous les moteurs de transfert de paquets converge vers les mécanismes de contrôle des cartes de ligne.

  • Lorsque le trafic appartient à un groupe de protocoles qui prend en charge les mécanismes de contrôle individuels, il passe par le mécanisme de contrôle individuel de la carte de ligne (2), puis par le mécanisme de contrôle d’agrégation de la carte de ligne (3). Le trafic qui passe par le mécanisme de contrôle individuel peut être abandonné par le mécanisme de contrôle agrégé. Bien que le trafic DHCPv4 et DHCPv6 ait été surveillé par un mécanisme de contrôle agrégé au niveau du moteur de transfert de paquets, il est géré au niveau de la carte de ligne comme les autres protocoles qui prennent en charge les mécanismes de contrôle individuels.

  • Lorsque le trafic appartient à un groupe de protocoles qui prend uniquement en charge les mécanismes de contrôle d’agrégation, seul le mécanisme de contrôle d’agrégation de carte de ligne surveille le trafic.

Le trafic qui passe par les mécanismes de contrôle de la carte de ligne est surveillé par l’un ou les deux mécanismes de contrôle du moteur de routage. Le trafic de toutes les cartes de ligne converge vers les mécanismes de contrôle du moteur de routage.

  • Lorsque le trafic appartient à un groupe de protocoles qui prend en charge des mécanismes de contrôle individuels, il passe par le mécanisme de contrôle individuel du moteur de routage (4), puis par le mécanisme de contrôle d’agrégation du moteur de routage (5). Le trafic qui passe par le mécanisme de contrôle individuel peut être abandonné par le mécanisme de contrôle agrégé. Comme au niveau de la carte de ligne, le trafic DHCPv4 et DHCPv6 au niveau du moteur de routage est géré comme les autres protocoles prenant en charge les mécanismes de contrôle individuels.

  • Lorsque le trafic appartient à un groupe de protocoles qui prend uniquement en charge les mécanismes de contrôle d’agrégation, seul le mécanisme de contrôle d’agrégation surveille le trafic.

Avec cette conception, trois mécanismes de contrôle évaluent le trafic pour les groupes de protocoles qui prennent uniquement en charge les mécanismes de contrôle agrégés. Il s’agit, entre autres, du trafic ANCP, du VLAN dynamique, du FTP et du trafic IGMP. Le trafic des groupes de protocoles qui prennent en charge les mécanismes de contrôle agrégés et individuels est évalué par les cinq mécanismes de contrôle. Il s’agit, entre autres, du trafic DHCPv4, MLP, PPP, PPPoE et Virtual Chassis .

La figure 1 montre comment la protection DDoS du plan de contrôle gère les paquets de contrôle PPPoE :

  1. Les paquets PADR, par exemple, sont évalués au premier mécanisme de contrôle du moteur de transfert de paquets pour déterminer s’ils respectent les limites de débit de paquets. Les paquets PADR qui dépassent la limite sont abandonnés.

  2. Tous les paquets PADR qui passent le mécanisme de contrôle sur tous les moteurs de transfert de paquets sur la carte de ligne sont ensuite évalués par le mécanisme de contrôle individuel de la carte de ligne. Les paquets PADR qui dépassent la limite sont abandonnés.

  3. Tous les paquets PADR qui passent par le mécanisme de contrôle individuel de la carte de ligne passent au mécanisme de contrôle de l’agrégation de la carte de ligne. Les paquets PADR qui dépassent la limite sont abandonnés.

  4. Tous les paquets PADR transmis par les mécanismes de contrôle d’agrégation de carte de ligne sur toutes les cartes de ligne du routeur passent au mécanisme de contrôle individuel du moteur de routage. Les paquets PADR qui dépassent la limite sont abandonnés.

  5. Enfin, tous les paquets PADR transmis par le mécanisme de contrôle individuel du moteur de routage passent au mécanisme de contrôle d’agrégation du moteur de routage. Les paquets PADR qui dépassent la limite sont abandonnés. Les paquets PADR qui ne sont pas abandonnés ici sont transmis en tant que trafic normal et sûr.

Par défaut, les trois mécanismes de contrôle individuels (moteur de transfert de paquets, carte de ligne et moteur de routage) ont la même limite de débit de paquets pour un type de paquet donné. Avec cette conception, tout le trafic de contrôle d’un moteur de transfert de paquets et d’une carte de ligne peut atteindre le moteur de routage tant qu’il n’y a pas de trafic concurrent du même type provenant d’autres moteurs de transfert de paquets ou de cartes de ligne. Lorsqu’il y a du trafic concurrent, les paquets excédentaires sont abandonnés aux points de convergence. C’est-à-dire qu’ils sont déposés à la carte de ligne pour tous les moteurs de transfert de paquets concurrents et au moteur de routage pour toutes les cartes de ligne concurrentes.

Exemple de comportement d’un mécanisme de contrôle pour limiter le débit de paquets

Par exemple, supposons que vous définissiez l’option de contrôle bandwidth pour les paquets PADI à 1000 paquets par seconde. Cette valeur s’applique aux mécanismes de contrôle PADI individuels du moteur de transfert de paquets, de la carte de ligne et du moteur de routage. Si seule la carte de l’emplacement 5 reçoit des paquets PADI, alors jusqu’à 1000 PADI pps peuvent atteindre le moteur de routage (si le mécanisme de contrôle d’agrégation PPPoE n’est pas dépassé). Cependant, supposons que la carte de l’emplacement 9 reçoive également des paquets PADI à 1000 pps et que son mécanisme de contrôle d’agrégation PPPoE ne soit pas dépassé. Le trafic passe par les mécanismes de contrôle individuels et agrégés au niveau des deux cartes de ligne et se dirige vers le moteur de routage. Au niveau du moteur de routage, le débit combiné de paquets est de 2000 pps. Parce que le contrôleur PADI du moteur de routage ne laisse passer que 1000 PADI pps, il abandonne les 1000 paquets excédentaires. Il continue d’abandonner les paquets excédentaires tant que la limite de bande passante (pps) est dépassée.

Vous pouvez appliquer un facteur d’échelle à la fois à la limite de bande passante (pps) et à la limite de rafale (paquets en rafale) au niveau de la carte de ligne afin d’affiner les limites de trafic pour chaque emplacement. Par exemple, supposons que le mécanisme de contrôle individuel règle le débit de paquets PADI à 1000 pps et la taille de rafale à 50 000 paquets. Vous pouvez réduire la limite de trafic pour les paquets PADI sur n’importe quelle carte de ligne en spécifiant le numéro d’emplacement et le facteur de mise à l’échelle. Dans cet exemple, un facteur d’échelle de bande passante de 20 pour l’emplacement 5 réduit le trafic à 20 % de 1 000 pps, ou à 200 pps pour la carte de ligne de cet emplacement. De même, un facteur de mise à l’échelle en rafale de 50 pour cet emplacement réduit la taille en rafale de 50 % pour atteindre 25 000 paquets. Par défaut, les facteurs d’échelle sont définis sur 100 afin que le trafic puisse passer à 100 % de la limite de débit.

Comparaison de la protection DDoS du plan de contrôle avec la connexion abonné à la protection contre la surcharge de paquets

Outre la capacité de protection DDoS du plan de contrôle, les routeurs MX Series disposent également d’un mécanisme intégré de protection contre la surcharge de connexion abonné. Le mécanisme de protection contre la surcharge de connexion (également appelé mécanisme de limitation de charge) surveille les paquets de connexion entrants de l’abonné et n’admet que ce que le système est capable de gérer en fonction de la charge dominante sur le système. Les paquets excédant ce que le système peut gérer sont éliminés. En se débarrassant de cette charge excessive, le système est en mesure de maintenir des performances optimales et d’éviter toute dégradation du taux de connexion dans des conditions de surcharge. Ce mécanisme utilise un minimum de ressources et est activé par défaut ; Aucune configuration utilisateur n’est requise.

La protection fournie par ce mécanisme est secondaire par rapport à ce que la protection DDoS du plan de contrôle fournit comme premier niveau de défense contre les taux élevés de paquets entrants. La protection DDoS du plan de contrôle fonctionne sur le moteur de transfert de paquets et protège contre tous les types de paquets de tous les protocoles. En revanche, le mécanisme de protection contre la surcharge de connexion est situé sur le moteur de routage et fonctionne spécifiquement sur les paquets entrants d’initiation de connexion tels que DHCPv4 DHCPDISCOVER, DHCPv6 SOLICIT et PPPoE PADI.

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plate-forme et la version que vous utilisez. Utilisez l’Explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libérer
Description
20.3R1
PTX10004 routeurs prennent en charge la protection DDoS du plan de contrôle à partir de Junos OS Evolved version 20.3R1.
19.4R1-S1
PTX10008 routeurs prennent en charge la protection DDoS du plan de contrôle à partir de Junos OS Evolved version 20.1R1.
19.3R1
PTX10003 routeurs prennent en charge la protection DDoS du plan de contrôle à partir de Junos OS Evolved version 19.3R1.
18.2R1
PTX10002 routeurs prennent en charge la protection DDoS du plan de contrôle à partir de la version Junos OS 18.2R1.
18.2R1
Les commutateurs QFX10002-60C prennent en charge la protection DDoS du plan de contrôle à partir de la version Junos OS 18.1R1.
17.4R1
PTX Series routeurs sur lesquels seuls des FPC basés sur PE sont installés (PTX3000, PTX5000, PTX1000 et PTX10000) prennent en charge la protection DDoS du plan de contrôle à partir de Junos OS version 17.4R1.
17.3R1
La prise en charge de la protection DDoS du plan de contrôle pour la gestion améliorée des abonnés a été ajoutée dans Junos OS version 17.3R1 sur les plates-formes de routage.
14.2
Dans Junos OS version 14.2 et ultérieures, la protection DDoS du plan de contrôle est prise en charge sur des plates-formes spécifiques.