Application des mécanismes de contrôle
Vue d’ensemble de l’application des mécanismes de contrôle
Les mécanismes de contrôle vous permettent d’effectuer un contrôle du trafic simple sur des interfaces spécifiques ou sur des réseaux privés virtuels (VPN) de couche 2 sans avoir à configurer de filtre de pare-feu. Pour appliquer les mécanismes de contrôle, incluez l’énoncé policer
suivant :
policer { arp policer-template-name; input policer-template-name; output policer-template-name; }
Vous pouvez inclure ces instructions aux niveaux hiérarchiques suivants :
[edit interfaces interface-name unit logical-unit-number family family]
[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]
Dans l’instructionfamily
, la famille de protocoles peut être ccc
, , inet6
, , tcc
inet
mpls
ou .vpls
Dans l’instruction, indiquez le nom d’un modèle de mécanisme de contrôle à évaluer lorsque des paquets ARP (Address Resolution Protocol) sont reçus sur l’interface arp
. Par défaut, un mécanisme de contrôle ARP est installé et partagé entre toutes les interfaces Ethernet sur lesquelles vous avez configuré l’instruction family inet
. Si vous souhaitez un contrôle plus strict ou plus indulgent des paquets ARP, vous pouvez configurer un mécanisme de contrôle spécifique à l’interface et l’appliquer à l’interface. Vous configurez un mécanisme de contrôle ARP comme vous le feriez pour n’importe quel autre mécanisme de contrôle, au niveau de la [edit firewall policer]
hiérarchie. Si vous appliquez ce mécanisme de contrôle à une interface, le mécanisme de contrôle des paquets ARP par défaut est remplacé. Si vous supprimez ce mécanisme de contrôle, le mécanisme de contrôle par défaut reprend effet.
Vous pouvez configurer un mécanisme de contrôle différent pour chaque famille de protocoles d’une interface, avec un mécanisme de contrôle d’entrée et un mécanisme de contrôle de sortie pour chaque famille. Lorsque vous appliquez des mécanismes de contrôle, vous pouvez configurer la famille
ccc
, , , , ouvpls
uniquement,inet
mpls
inet6
tcc
ainsi qu’un mécanisme de contrôle ARP pour le protocole familialinet
uniquement. Chaque fois qu’un mécanisme de contrôle est référencé, une copie distincte de celui-ci est installée sur les composants de transfert de paquets de cette interface.Si vous appliquez à la fois des mécanismes de contrôle et des filtres de pare-feu à une interface, les mécanismes de contrôle d’entrée sont évalués avant les filtres de pare-feu d’entrée, et les mécanismes de contrôle de sortie sont évalués après les filtres de pare-feu de sortie. Dans l’instruction, indiquez le nom d’un modèle de mécanisme de contrôle à évaluer lorsque des paquets sont reçus sur l’interface
input
. Dans l’instruction, indiquez le nom d’un modèle de mécanismes de contrôle à évaluer lorsque des paquets sont transmis sur l’interfaceoutput
.Pour les abonnés dont la terminaison se trouve sur des routeurs MX Series sur une interface AE (Aggregated Ethernet) qui s’étend sur plusieurs FPC, il est possible qu’un débit d’abonné global dépasse le débit configuré, car la limite configurée dans le mécanisme de contrôle est appliquée séparément à chaque interface du lot AE. Ainsi, par exemple, si vous avez l’intention de faire en sorte qu’un mécanisme de contrôle sur une interface AE à trois membres applique un de , vous devez configurer le dans le
bandwidth-limit
mécanisme de contrôle pour tenir compte des trois interfaces de l’AE (c’est-à-dire 200 Mbit/s par interface, pour 200m unbandwidth-limit
total combiné de 600m600 Mbit/s).Si vous appliquez le mécanisme de contrôle à l’interface
lo0
, il est appliqué aux paquets reçus ou transmis par le moteur de routage.Sur les plates-formes T Series, M120 et M320, si les interfaces se trouvent sur le même FPC, les filtres ou mécanismes de contrôle n’agissent pas sur la somme du trafic entrant et sortant des interfaces.
Application des mécanismes de contrôle d’agrégation
Application des mécanismes de contrôle d’agrégation
Par défaut, si vous appliquez un mécanisme de contrôle à plusieurs familles de protocoles sur la même interface logique, il restreint le trafic pour chaque famille de protocoles individuellement. Par exemple, un mécanisme de contrôle avec une limite de bande passante de 50 Mbits/s appliquée au trafic IPv4 et IPv6 permettrait à l’interface d’accepter 50 Mbit/s de trafic IPv4 et 50 Mbit/s de trafic IPv6. Si vous appliquez un mécanisme de contrôle d’agrégation, celui-ci permet à l’interface de ne recevoir que 50 Mbit/s de trafic IPv4 et IPv6 combinés.
Pour configurer un mécanisme de contrôle d’agrégation, incluez l’instruction logical-interface-policer
au niveau de la [edit firewall policer policer-template-name]
hiérarchie :
[edit firewall policer policer-template-name] logical-interface-policer;
Pour que le mécanisme de contrôle soit traité comme un agrégat, vous devez l’appliquer à plusieurs familles de protocoles sur une seule interface logique en incluant l’instruction policer
suivante :
policer { arp policer-template-name; input policer-template-name; output policer-template-name; }
Vous pouvez inclure ces instructions aux niveaux hiérarchiques suivants :
[edit interfaces interface-name unit logical-unit-number family family]
[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family family]
Dans l’instructionfamily
, la famille de protocoles peut être ccc
, , inet6
, , tcc
inet
mpls
ou .vpls
Les familles de protocoles sur lesquelles vous n’appliquez pas le mécanisme de contrôle ne sont pas affectées par le mécanisme de contrôle. Par exemple, si vous configurez une seule interface logique pour accepter le trafic MPLS, IPv4 et IPv6 et que vous appliquez le mécanisme de contrôle policer1
des interfaces logiques aux familles de protocoles IPv4 et IPv6 uniquement, le trafic MPLS n’est pas soumis aux contraintes de policer1
.
Si vous postulez policer1
à une interface logique différente, il existe deux instances du mécanisme de contrôle. Cela signifie que Junos OS contrôle le trafic sur des interfaces logiques distinctes séparément, et non en tant qu’agrégat, même si le même mécanisme de contrôle d’interface logique est appliqué à plusieurs interfaces logiques sur le même port d’interface physique.
Exemple : Application des mécanismes de contrôle d’agrégation
Configurez deux mécanismes de contrôle d’interface logique : aggregate_police1
et aggregate_police2
. S’applique aggregate_police1
au trafic IPv4 et IPv6 reçu sur l’interface fe-0/0/0.0
logique. S’applique aggregate_police2
au trafic CCC et MPLS reçu sur l’interface logique fe-0/0/0.0. Cette configuration fait en sorte que le logiciel ne crée qu’une seule instance de et une seule instance de aggregate_police1
aggregate_police2
.
S’applique aggregate_police1
au trafic IPv4 et IPv6 reçu sur une autre interface fe-0/0/0.1
logique. Cette configuration amène le logiciel à créer une nouvelle instance de aggregate_police1
, l’une qui s’applique à l’unité 0 et l’autre qui s’applique à l’unité 1.
[edit firewall] policer aggregate_police1 { logical-interface-policer; if-exceeding { bandwidth-limit 100m; burst-size-limit 500k; } then { discard; } } policer aggregate_police2 { logical-interface-policer; if-exceeding { bandwidth-limit 10m; burst-size-limit 200k; } then { discard; } } [edit interfaces fe-0/0/0] unit 0 { family inet { policer { input aggregate_police1; } } family inet6 { policer { input aggregate_police1; } } family ccc { policer { input aggregate_police2; } } family mpls { policer { input aggregate_police2; } } } unit 1 { family inet { policer { input aggregate_police1; } } family inet6 { policer { input aggregate_police1; } } }
Application de mécanismes de contrôle hiérarchiques sur des PIC de file d’attente intelligents améliorés
Application de mécanismes de contrôle hiérarchiques sur des PIC de file d’attente intelligents améliorés
Les routeurs de périphérie M40e, M120 et M320 et les routeurs centraux T Series avec des PIC IQE (Enhanced Intelligent Queuing) prennent en charge les mécanismes de contrôle hiérarchiques dans le sens entrant et vous permettent d’appliquer un mécanisme de contrôle hiérarchique pour les niveaux de trafic premium et agrégé (premium plus normal) à une interface. Les mécanismes de contrôle hiérarchiques assurent une fonctionnalité croisée entre l’interface physique configurée et le moteur de transfert de paquets.
Avant de commencer, il existe quelques restrictions générales qui s’appliquent aux mécanismes de contrôle hiérarchiques :
Un seul type de mécanisme de contrôle peut être configuré pour une interface logique ou physique. Par exemple, un mécanisme de contrôle hiérarchique et un mécanisme de contrôle normal dans la même direction pour la même interface logique ne sont pas autorisés.
Le chaînage des mécanismes de contrôle, c’est-à-dire l’application de mécanismes de contrôle à la fois à un port et aux interfaces logiques de ce port, n’est pas autorisé.
Il y a une limite de 64 mécanismes de contrôle par interface au cas où il n’y aurait pas de classification BA, ce qui donne un seul mécanisme de contrôle par DLCI.
Un seul type de mécanisme de contrôle peut être appliqué sur une interface physique ou logique.
Le policier doit être indépendant de la classification BA. Sans classification BA, tout le trafic sur une interface sera traité comme EF ou non-EF, en fonction de la configuration. Avec la classification BA, une interface peut prendre en charge jusqu’à 64 mécanismes de contrôle. Encore une fois, l’interface ici peut être une interface physique ou une interface logique (par exemple, DLCI).
Avec la classification BA, le trafic divers (le trafic ne correspondant à aucun des bits DSCP/EXP de la classification BA) sera contrôlé en tant que trafic non-EF. Aucun dispositif de contrôle distinct ne sera installé pour ce trafic.
- Vue d’ensemble du mécanisme de contrôle hiérarchique
- Caractéristiques du maintien de l’ordre hiérarchique
Vue d’ensemble du mécanisme de contrôle hiérarchique
Le contrôle hiérarchique utilise deux compartiments de jetons, l’un pour le trafic agrégé (non-EF) et l’autre pour le trafic premium (EF). Le trafic EF et le trafic non-EF sont déterminés par la configuration de classe de service. Logiquement, le maintien de l’ordre hiérarchique est réalisé en enchaînant deux policiers.
Dans l’exemple de Figure 1, le trafic EF est contrôlé par Premium Policer et le trafic non EF est contrôlé par Aggregate Policer. Cela signifie que, pour le trafic EF, l’action hors spécification sera celle configurée pour Premium Policer, mais le trafic EF in-spec consommera toujours les jetons de l’Aggregate Policer.
Mais le trafic EF ne sera jamais soumis à l’action hors spécification de l’Aggregate Policer. De plus, si l’action hors spécification du mécanisme de contrôle Premium n’est pas définie sur Ignorer, ces paquets hors spécifications ne consommeront pas les jetons du mécanisme de contrôle d’agrégation. Aggregate Policer contrôle uniquement le trafic non-EF. Comme vous pouvez le voir, le compartiment de jetons Aggregate Policer peut devenir négatif si tous les jetons sont consommés par le trafic non-EF et que vous obtenez des rafales de trafic EF. Mais ce sera pour une très courte période, et sur une période de temps, cela se situera en moyenne. Par exemple :
Contrôleur Premium : Bande passante 2 Mbit/s, OOS Action : Jeter
Mécanisme de contrôle d’agrégation : Bande passante 10 Mbit/s, OOS Action : Jeter
Dans le cas ci-dessus, le trafic EF est garanti 2 Mbits/s et le trafic non-EF passera de 8 Mbits/s à 10 Mbits/s, en fonction du débit d’entrée du trafic EF.
Caractéristiques du maintien de l’ordre hiérarchique
Les fonctionnalités du compartiment de jetons hiérarchiques sont les suivantes :
Le trafic entrant est d’abord classé en trafic EF et non-EF avant d’appliquer un mécanisme de contrôle :
La classification est effectuée par recherche Q-tree
Le numéro de canal sélectionne un mécanisme de contrôle de compartiment de jeton partagé :
Le mécanisme de contrôle des compartiments à deux jetons est divisé en deux mécanismes de contrôle à compartiment unique :
Contrôleur1 : trafic EF
Policer2 : trafic non-EF
Le compartiment de jetons partagés est utilisé pour contrôler le trafic comme suit :
Policer1 est défini sur le débit EF (par exemple, 2 Mbits/s)
Policer2 est défini sur le débit contrôlé de l’interface agrégée (par exemple, 10 Mbit/s).
Le trafic EF est appliqué à Policer1.
Si le trafic est conforme aux spécifications, il est autorisé à passer et à décrémenter à la fois Policer1 et Policer2.
Si le trafic n’est pas conforme aux spécifications, il peut être ignoré ou marqué d’une nouvelle FC ou d’une nouvelle priorité de perte. Policer2 ne fera rien avec le trafic EF hors spécifications.
Le trafic non-EF est appliqué uniquement à Policer2.
Si le trafic est conforme aux spécifications, il est autorisé à passer et décrémenté Policer2.
Si le trafic n’est pas conforme aux spécifications, il est ignoré ou marqué avec un nouveau FC ou défini avec une nouvelle priorité d’abandon.
Limitez la vitesse du port à la vitesse souhaitée au niveau de la couche 2
Limite de débit le trafic EF
Limite de débit le trafic non-EF
Gouttes de maintien de l’ordre comptées par couleur
Voir également
Configuration des mécanismes de contrôle hiérarchiques
Pour configurer un mécanisme de contrôle hiérarchique, appliquez l’instruction policing-priority
à la classe de transfert appropriée et configurez un mécanisme de contrôle hiérarchique pour les niveaux d’agrégation et de prime. Pour plus d’informations sur la classe de service, reportez-vous au Guide de l’utilisateur de la classe de service Junos OS pour les périphériques de routage.
Les mécanismes de contrôle hiérarchiques ne peuvent être configurés que sur les interfaces physiques SONET hébergées sur un PIC IQE. Seuls les niveaux agrégés et premium sont pris en charge.
Configuration CoS des classes de transfert pour les mécanismes de contrôle hiérarchiques
[edit class-of-service forwarding-classes] class fc1 queue-num 0 priority high policing-priority premium; class fc2 queue-num 1 priority low policing-priority normal; class fc3 queue-num 2 priority low policing-priority normal; class fc4 queue-num 3 priority low policing-priority normal;
Pour plus d’informations sur la configuration et les instructions de classe de service, reportez-vous au Guide de l’utilisateur de la classe de service de Junos OS pour les périphériques de routage.
Configuration de pare-feu pour les mécanismes de contrôle hiérarchiques
[edit firewall hierarchical-policer foo] aggregate { if-exceeding { bandwidth-limit 70m; burst-size-limit 1500; } then { discard; } premium { if-exceeding { bandwidth-limit 50m; burst-size-limit 1500; } then { discard; } }
Vous pouvez appliquer le mécanisme de contrôle hiérarchique comme suit :
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-hierarchical-policer foo;
Vous avez également la possibilité d’appliquer le mécanisme de contrôle au niveau du port physique comme suit :
[edit interfaces so-0/1/0 layer2-policer] input-hierarchical-policer foo;
Configuration d’un mécanisme de contrôle bicolore à taux unique
Vous pouvez configurer un mécanisme de contrôle bicolore à taux unique comme suit :
[edit firewall policer foo] if-exceeding { bandwidth-limit 50m; burst-size-limit 1500; } then { discard; }
Vous pouvez appliquer le mécanisme de contrôle comme suit :
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-policer foo;
Vous avez également la possibilité d’appliquer le mécanisme de contrôle au niveau du port physique comme suit :
[edit interfaces so-0/1/0 layer2-policer] input-policer foo;
Configuration d’un mécanisme de contrôle daltonien à taux unique
Cette section décrit les mécanismes de contrôle daltoniens et sensibles aux couleurs à débit unique.
Vous pouvez configurer un mécanisme de contrôle daltonien à débit unique comme suit :
[edit firewall three-color-policer foo] single-rate { color-blind; committed-information-rate 50m; committed-burst-size 1500; excess-burst-size 1500; }
Vous pouvez appliquer le mécanisme de contrôle daltonien à taux unique comme suit :
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-three-color foo;
Vous pouvez configurer un mécanisme de contrôle sensible aux couleurs à débit unique comme suit :
[edit firewall three-color-policer bar] single-rate { color-aware; committed-information-rate 50m; committed-burst-size 1500; excess-burst-size 1500; }
Vous pouvez appliquer le mécanisme de contrôle sensible aux couleurs à débit unique comme suit :
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-three-color foo;
Vous avez également la possibilité d’appliquer le mécanisme de contrôle au niveau du port physique comme suit :
[edit interfaces so-0/1/0 layer2-policer] input-three-color bar;
Configuration d’un mécanisme de contrôle des marqueurs tricolores à deux taux
Le contrôle de l’entrée est mis en œuvre à l’aide d’un marqueur tricolore à deux taux (trTCM). Cela se fait à l’aide d’un compartiment à double jeton (DTB) qui maintient deux taux, validé et un pic. Le contrôle statique de sortie utilise également un compartiment de jetons.
Les compartiments de jetons exécutent les fonctions de contrôle d’entrée suivantes :
(1K) trTCM - Seau à deux jetons (marquage rouge, jaune et vert)
Le contrôle est basé sur la taille des paquets de couche 2 :
Après +/- octet ajuster le décalage
Le marquage est conscient des couleurs et daltonien :
La couleur doit être définie par la recherche q-tree en fonction de :
Tos
EXP
Actions de marquage programmables :
Couleur (rouge, jaune, vert)
Baisse en fonction de la couleur et du profil d’encombrement
Le mécanisme de contrôle est sélectionné en fonction du numéro de canal à l’arrivée :
La LUT de numéro de canal produit un index de mécanismes de contrôle et un index de file d’attente
Plusieurs canaux peuvent partager le même mécanisme de contrôle (la LUT produit le même index de mécanisme de contrôleur)
Prise en charge du contrôle d’entrée et de la gestion des intrusions aux niveaux suivants :
File d’attente
Interface logique (ifl/DLCI)
Interface physique (ifd)
Port physique (contrôleur ifd)
Toute combinaison d’interface logique, d’interface physique et de port
Prise en charge du pourcentage de vitesse de l’interface et du nombre de bits par seconde
Des limites de débit peuvent être appliquées à des files d’attente sélectionnées à l’entrée et à des files d’attente prédéfinies à la sortie. Le compartiment de jetons fonctionne en mode sensible aux couleurs et daltonien (spécifié par la RFC 2698).
Configuration d’un trTCM daltonien
[edit firewall three-color-policer foo] two-rate { color-blind; committed-information-rate 50m; committed-burst-size 1500; peak-information-rate 100m; peak-burst-size 3k; }
Vous pouvez appliquer le mécanisme de contrôle daltonien à trois couleurs et à deux taux comme suit :
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-three-color foo;
Vous avez également la possibilité d’appliquer le mécanisme de contrôle au niveau du port physique comme suit :
[edit interfaces so-0/1/0 layer2-policer] input-three-color foo;
Configuration d’un contrôleur trTCM sensible aux couleurs
[edit firewall three-color-policer bar] two-rate { color-aware; committed-information-rate 50m; committed-burst-size 1500; peak-information-rate 100m; peak-burst-size 3k; }
Vous pouvez appliquer le mécanisme de contrôle sensible aux couleurs à trois couleurs et à deux débits comme suit :
[edit interfaces so-0/1/0 unit 0 layer2-policer] input-three-color bar;
Vous avez également la possibilité d’appliquer le mécanisme de contrôle au niveau du port physique comme suit :
[edit interfaces so-0/1/0 layer2-policer] input-three-color bar;