Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Exemple : Limitation du trafic entrant au sein de votre réseau en configurant un mécanisme de contrôle bicolore à débit unique d’entrée et en configurant des classificateurs à champs multiples

Cet exemple montre comment limiter le trafic client au sein de votre réseau à l’aide d’un mécanisme de contrôle bicolore à débit unique. Les mécanismes de contrôle utilisent un concept connu sous le nom de compartiment de jetons pour identifier le trafic à abandonner. Le mécanisme de contrôle applique la stratégie de classe de service (CoS) du trafic contractuel et hors contrat au niveau de l’interface. Vous pouvez appliquer un mécanisme de contrôle bicolore à débit unique aux paquets entrants, sortants ou aux deux. Cet exemple applique le mécanisme de contrôle en tant que mécanisme de contrôle d’entrée pour le trafic entrant. L’option de file d’attente CoS du classificateur à champs multiples place le trafic dans les files d’attente affectées, ce qui vous aidera à gérer l’utilisation des ressources au niveau de l’interface de sortie en appliquant la planification et la mise en forme à une date ultérieure.

Une explication détaillée du concept de compartiment de jetons et de ses algorithmes sous-jacents dépasse le cadre de ce document. Pour plus d’informations sur le contrôle de la circulation, et sur le CoS en général, reportez-vous à QOS-Enabled Networks—Tools and Foundations par Miguel Barreiros et Peter Lundqvist. Ce livre est disponible chez de nombreux libraires en ligne et chez www.juniper.net/books.

Exigences

Pour vérifier cette procédure, cet exemple utilise un générateur de trafic. Le générateur de trafic peut être matériel ou logiciel exécuté sur un serveur ou une machine hôte.

La fonctionnalité de cette procédure est largement prise en charge sur les périphériques qui exécutent Junos OS. L’exemple présenté ici a été testé et vérifié sur des routeurs MX Series exécutant Junos OS version 10.4.

Aperçu

Police

Le contrôle bicolore à débit unique applique un débit configuré de flux de trafic pour un niveau de service particulier en appliquant des actions implicites ou configurées au trafic qui ne respecte pas les limites. Lorsque vous appliquez un mécanisme de contrôle bicolore à débit unique au trafic d’entrée ou de sortie au niveau d’une interface, le mécanisme de contrôle mesure le flux de trafic en fonction de la limite de débit définie par les composants suivants :

  • Limite de bande passante : nombre moyen de bits par seconde autorisé pour les paquets reçus ou transmis à l’interface. Vous pouvez spécifier la limite de bande passante sous la forme d’un nombre absolu de bits par seconde ou d’un pourcentage compris entre 1 et 100. Si une valeur de pourcentage est spécifiée, la limite de bande passante effective est calculée sous la forme d’un pourcentage du débit de support de l’interface physique ou du débit de mise en forme configurée de l’interface logique.

  • Limite de taille en rafale : taille maximale autorisée pour les rafales de données. La taille des rafales est mesurée en octets. Nous recommandons deux formules pour calculer la taille de la rafale :

    Taille de la rafale = bande passante x temps autorisé pour le trafic en rafale / 8

    Ou

    Taille de rafale = mtu d’interface x 10

    Pour plus d’informations sur la configuration de la taille de rafale, reportez-vous à la section Détermination de la taille de rafale appropriée pour les mécanismes de contrôle du trafic.

    Note:

    Il y a un espace tampon fini pour une interface. En général, la profondeur totale de la mémoire tampon estimée pour une interface est d’environ 125 ms.

Pour un flux de trafic conforme aux limites configurées (catégorisé comme trafic vert), les paquets sont implicitement marqués d’un niveau de priorité de perte de paquets (PLP) faible et sont autorisés à traverser l’interface sans restriction.

Pour un flux de trafic qui dépasse les limites configurées (catégorisé comme trafic rouge), les paquets sont traités en fonction des actions de contrôle du trafic configurées pour le mécanisme de contrôle. Cet exemple ignore les paquets qui dépassent la limite de 15 Kbits/s.

Pour limiter le débit du trafic de couche 3, vous pouvez appliquer un mécanisme de contrôle à deux couleurs de l’une des manières suivantes :

  • Directement vers une interface logique, au niveau d’un protocole spécifique.

  • Il s’agit de l’action d’un filtre de pare-feu sans état standard appliqué à une interface logique, à un niveau de protocole spécifique. C’est la technique utilisée dans cet exemple.

Pour limiter le débit du trafic de couche 2, vous pouvez appliquer un mécanisme de contrôle bicolore en tant que mécanisme de contrôle d’interface logique uniquement. Vous ne pouvez pas appliquer un mécanisme de contrôle bicolore au trafic de couche 2 à travers un filtre de pare-feu.

ATTENTION:

Vous pouvez choisir la limite de bande passante ou le pourcentage de bande passante dans le mécanisme de contrôle, car ils s’excluent mutuellement. Vous ne pouvez pas configurer un mécanisme de contrôle pour qu’il utilise le pourcentage de bande passante pour les interfaces d’agrégation, de tunnel ou logicielles.

Dans cet exemple, l’hôte est un générateur de trafic émulant un serveur web. Les appareils R1 et R2 appartiennent à un fournisseur de services. Le serveur Web est accessible par les utilisateurs derrière l’appareil R2. L’hôte enverra du trafic avec un port source, un port TCP, un port HTTP 80 et un port source, 12345, aux utilisateurs. Un mécanisme de contrôle bicolore à débit unique est configuré et appliqué à l’interface de l’appareil R1 qui connecte l’hôte à l’appareil R1. Le mécanisme de contrôle applique la disponibilité contractuelle de la bande passante établie entre le propriétaire du serveur Web (dans ce cas, émulé par l’hôte) et le fournisseur de services propriétaire de l’appareil R1 pour le trafic Web qui circule sur la liaison qui relie l’hôte à l’appareil R1.

Conformément à la disponibilité contractuelle de la bande passante établie entre le propriétaire du serveur Web et le fournisseur de services propriétaire des périphériques R1 et R2, le mécanisme de contrôle limitera le trafic du port HTTP 80 et du port 12345 provenant de l’hôte à l’utilisation de 700 Mbit/s (70 %) de la bande passante disponible avec un débit de rafale admissible de 10 fois la taille MTU de l’interface Ethernet gigabit entre l’hôte et le périphérique R1.

Note:

Dans un scénario réel, vous limiteriez probablement le débit du trafic pour une variété d’autres ports tels que FTP, SFTP, SSH, TELNET, SMTP, IMAP et POP3, car ils sont souvent inclus en tant que services supplémentaires avec les services d’hébergement Web.

Note:

Vous devez laisser de la bande passante supplémentaire disponible qui n’est pas limitée en débit pour les protocoles de contrôle réseau tels que les protocoles de routage, le DNS et tout autre protocole requis pour maintenir la connectivité réseau opérationnelle. C’est pourquoi le filtre de pare-feu comporte une condition d’acceptation finale.

Topologie

Cet exemple utilise la topologie de la Figure 1.

Figure 1 : Scénario d’un mécanisme de contrôle bicolore à taux unique Single-Rate Two-Color Policer Scenario

La figure 2 montre le comportement des forces de l’ordre.

Figure 2 : Limitation du trafic dans un scénario de mécanisme de contrôle bicolore à débit unique Traffic Limiting in a Single-Rate Two-Color Policer Scenario

Classification multichamps

Un classificateur est une opération logicielle qu’un routeur ou un commutateur utilise pour inspecter et classer un paquet une fois qu’il a franchi n’importe quel contrôle, si le contrôle est configuré. Au cours de la classification, le contenu de l’en-tête du paquet est examiné, et cet examen détermine la façon dont le paquet est traité lorsque l’interface sortante devient trop chargée pour gérer tous les paquets et que vous souhaitez que votre périphérique abandonne les paquets intelligemment, au lieu de les abandonner indistinctement. Une façon courante de détecter les paquets d’intérêt est le numéro de port source. Les numéros de port source TCP 80 et 12345 sont utilisés dans cet exemple, mais de nombreux autres critères de correspondance pour la détection de paquets sont disponibles pour les classificateurs à champs multiples, à l’aide des conditions de correspondance du filtre de pare-feu. La configuration de cet exemple spécifie que les paquets TCP avec un port source 80 sont classés dans la classe de transfert de données BE et le numéro de file d’attente 0, et que les paquets TCP avec un port source 12345 sont classés dans la classe de transfert de données Premium et le numéro de file d’attente 1. Le trafic provenant des deux numéros de port est d’abord surveillé par le mécanisme de contrôle. Si le trafic passe par le mécanisme de contrôle, il est transféré à l’interface sortante dans la file d’attente affectée pour transmission.

Les classificateurs multichamps sont généralement utilisés à la périphérie du réseau lorsque les paquets entrent dans un système autonome (AS).

Dans cet exemple, vous configurez le filtre de pare-feu mf-classifier et spécifiez des classes de transfert personnalisées sur l’appareil R1. En spécifiant les classes de transfert personnalisées, vous associez également chaque classe à une file d’attente.

Le fonctionnement du classificateur est illustré à la Figure 3.

Figure 3 : classificateur à champs multiples basé sur les ports Multifield Classifier Based on TCP Source Ports source TCP

Vous appliquez le filtre de pare-feu du classifieur à champs multiples en tant que filtre d’entrée sur chaque interface orientée client ou hôte qui a besoin du filtre. Dans cet exemple, l’interface entrante ge-2/0/5 sur l’appareil R1 est utilisée. Vous surveillez le comportement des files d’attente sur les interfaces sur lesquelles le trafic est transmis. Dans cet exemple, pour déterminer la façon dont les files d’attente sont traitées, vous examinez les statistiques de trafic sur l’interface ge-2/0/8 à l’aide de l’option de extensive la show interfaces commande.

Configuration

Procédure

Configuration rapide de l’interface de ligne de commande

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.

Appareil R1

Appareil R2

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette procédure, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration du Guide de l’utilisateur de l’interface de ligne de commande Junos OS.

Pour configurer l’appareil R1 :

  1. Configurez les interfaces de l’appareil.

  2. Configurez le mécanisme de contrôle pour qu’il limite le débit à une bande passante de 700 Mbits/s et à une taille de rafale de 15 Kbits/s.

  3. Configurez le mécanisme de contrôle pour qu’il rejette les paquets dans le flux de trafic rouge.

  4. Configurez les classes de transfert personnalisées et les numéros de file d’attente associés.

  5. Configurez le terme de filtre de pare-feu qui place le trafic TCP avec un port source de 80 (trafic HTTP) dans la classe de transfert de données BE, associée à la file d’attente 0.

  6. Configurez le terme de filtre de pare-feu qui place le trafic TCP avec un port source de 12345 dans la classe de transfert de données Premium, associée à la file d’attente 1.

  7. À la fin du filtre de votre pare-feu, configurez un terme par défaut qui accepte tout le reste du trafic.

    Dans le cas contraire, tout le trafic qui arrive sur l’interface et qui n’est pas explicitement accepté par le filtre de pare-feu est ignoré.

  8. Appliquez le filtre de pare-feu à l’interface ge-2/0/5 en tant que filtre d’entrée.

  9. Configurez OSPF.

Procédure étape par étape

Pour configurer l’appareil R2 :

  1. Configurez les interfaces de l’appareil.

  2. Configurez OSPF.

Résultats

À partir du mode de configuration, confirmez votre configuration en saisissant les show interfacescommandes , , show class-of-serviceshow firewallet show protocols ospf . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer l’appareil R1, passez commit en mode de configuration.

Si vous avez terminé de configurer le périphérique R2, passez en commit mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification des paramètres CoS

But

Vérifiez que les classes de transfert sont correctement configurées.

Action

À partir de l’appareil R1, exécutez la show class-of-service forwarding-class commande.

Sens

La sortie affiche les paramètres du classificateur personnalisé configuré.

Vidage des compteurs

But

Vérifiez que les compteurs de pare-feu et d’interface sont effacés.

Action

  • Sur l’appareil R1, exécutez la clear firewall all commande pour réinitialiser les compteurs du pare-feu à 0.

  • Sur l’appareil R1, exécutez la clear interface statistics ge-2/0/5 commande pour réinitialiser les compteurs d’interface à 0.

Envoi de trafic sur le réseau à partir du port HTTP TCP 80 et surveillance des résultats

But

Envoyez le trafic qui peut être surveillé au niveau du mécanisme de contrôle et de la file d’attente personnalisée.

Action

  1. Utilisez un générateur de trafic pour envoyer 20 paquets TCP avec un port source de 80 dans le réseau.

    L’option -s définit le port source. L’option -k permet au port source de rester stable à 80 au lieu de s’incrémenter. L’option -c définit le nombre de paquets à 20. L’option -d définit la taille du paquet.

    Note:

    Dans cet exemple, les numéros de mécanismes de contrôle sont réduits à une limite de bande passante de 8 Kbits/s et à une limite de taille de rafale de 1 500 Kbits/s pour garantir que certains paquets sont abandonnés.

  2. Sur l’appareil R1, vérifiez les compteurs du pare-feu à l’aide de la show firewall commande.

    Notez que dans la sortie hping, il y a eu une perte de paquets de 20% (4 paquets sur 20) et le même nombre de paquets a été abandonné par le mécanisme de contrôle comme indiqué dans la sortie de la show firewall commande. Notez également que les abandons sont associés aux données BE de la file d’attente, comme spécifié dans le classificateur mf dans la configuration du pare-feu.

  3. Sur l’appareil R1, vérifiez les compteurs de file d’attente à l’aide de la show interfaces extensive ge-2/0/8| find "Queue counters" commande.

    Notez que 16 paquets ont été transmis à l’interface 2/0/8 en utilisant les données BE de la file d’attente comme spécifié dans le classificateur mf dans la configuration du pare-feu. Les 4 paquets restants ont été abandonnés par le policier, comme indiqué ci-dessus. Les 4 paquets envoyés à la file d’attente 3 sont du trafic de contrôle réseau. Il s’agit peut-être de mises à jour du protocole de routage.

Sens

La sortie des deux périphériques montre que 4 paquets ont été rejetés Cela signifie qu’il y avait au moins 8 Kbit/s de trafic vert (port HTTP 80 sous contrat) et que l’option de rafale de 1500 Ko pour le trafic HTTP rouge hors contrat port 80 a été dépassée. Dans les étapes 2 et 3, vous pouvez voir que les files d’attente correctes ont été utilisées pour transmettre l’interface de sortie de trafic restant 2/0/8.

Envoi de trafic sur le réseau à partir du port TCP 12345 et surveillance des résultats

But

Envoyez le trafic qui peut être surveillé au niveau du mécanisme de contrôle et de la file d’attente personnalisée.

Action

  1. Effacez à nouveau les compteurs comme indiqué dans la section Effacer les compteurs.

  2. Utilisez un générateur de trafic pour envoyer 20 paquets TCP avec un port source de 12345 dans le réseau.

    L’option -s définit le port source. L’option -k permet au port source de rester stable à 12345 au lieu de s’incrémenter. L’option -c définit le nombre de paquets à 20. L’option -d définit la taille du paquet.

  3. Sur l’appareil R1, vérifiez les compteurs du pare-feu à l’aide de la show firewall commande.

    Notez que dans la sortie hping, il y a eu une perte de paquets de 20% (4 paquets sur 20) et le même nombre de paquets a été abandonné par le mécanisme de contrôle comme indiqué dans la sortie de la show firewall commande. Notez également que les abandons sont associés à la file d’attente Premium-data comme spécifié dans le classificateur mf dans la configuration du pare-feu.

  4. Sur l’appareil R1, vérifiez les compteurs de file d’attente à l’aide de la show interfaces extensive ge-2/0/8| find "Queue counters" commande.

    Notez que 16 paquets ont été transmis à l’interface 2/0/8 à l’aide des files d’attente de données Premium comme spécifié dans la configuration du pare-feu mf-classifier. Les 4 paquets restants ont été abandonnés par le policier, comme indiqué ci-dessus. Les 19 paquets envoyés à la file d’attente 3 sont du trafic de contrôle réseau. Il s’agit peut-être de mises à jour du protocole de routage.

Sens

La sortie des deux périphériques montre que 4 paquets ont été rejetés. Cela signifie qu’il y avait au moins 8 Kbit/s de trafic vert (port HTTP 80 sous contrat) et que l’option de rafale de 1500 Kbit/s pour le trafic HTTP rouge hors contrat port 80 a été dépassée. Dans les étapes 3 et 4, vous pouvez voir que les files d’attente correctes ont été utilisées pour transmettre le trafic sortant restant interface 2/0/8.