Classe de service sur les interfaces de services
Présentation du service
La configuration CoS disponible pour les cartes de service basées sur M Series et MX Series vous permet de configurer le marquage du point de code des services différenciés (DiffServ) (DSCP) et l’attribution de classe de transfert pour les paquets transitant par les cartes de service PICs. Les cartes de service basées sur les gammes M Series et MX Series comprennent le PIC multiservices, le MS-MIC, LE MS-MPC, LE MS-DPC et le PIC de services adaptatif. Vous pouvez configurer le service CoS en même temps que le pare-feu dynamique et les services NAT, en utilisant une structure de règles similaire. Les structures des composants sont décrites en détail dans le Guide de l’utilisateur de la classe de service (routeurs et commutateurs EX9200).
Les normes relatives aux services différenciés sont décrites dans les documents suivants :
RFC 2474, Définition du champ Services différenciés (champ DS) dans les en-têtes IPv4 et IPv6
RFC 2475, Une architecture pour des services différenciés
Note:La classification CoS BA n’est pas prise en charge sur les interfaces de services. La configuration CoS n’est disponible que pour les services NAT et de pare-feu dynamiques. La configuration CoS ne fonctionne pas avec d’autres services qui s’exécutent sur les cartes de service, tels qu’IPsec.
Restrictions et précautions relatives à la configuration CoS sur les interfaces de services
Les restrictions et avertissements suivants s’appliquent à la configuration CoS sur les interfaces de services :
Vous devez configurer au moins une règle de pare-feu dynamique ou une règle NAT sur l’ensemble de services. Sinon, CoS ne fonctionne pas.
Les interfaces de services ne prennent pas en charge la planification, mais seulement le marquage DiffServ et l’affectation de files d’attente. Vous devez configurer la planification au niveau de la
[edit class-of-service]hiérarchie sur l’interface ou la structure de sortie.Dans la configuration par défaut, les files d’attente 1 et 2 reçoivent 0 % de bande passante. Si des paquets doivent être affectés à ces files d’attente, vous devez configurer une carte de planification.
Vous devez émettre une
commit fullcommande avant d’utiliser des noms de classe de transfert personnalisés dans la configuration.Seuls les noms DiffServ standard Junos peuvent être utilisés dans la configuration. Les noms personnalisés ne sont pas reconnus.
Sur les routeurs M Series, vous pouvez configurer des règles de réécriture qui modifient les en-têtes de paquets et attachent les règles aux interfaces de sortie. Ces règles peuvent remplacer le marquage DSCP configuré sur un pic multiservices. Il est important de garder cet effet indésirable à l’esprit et d’être prudent lors de la création de configurations à l’échelle du système.
Par exemple, sachant que le PIC multiservices peut marquer les paquets avec n’importe quelle valeur ToS ou DSCP et que l’interface de sortie est limitée à seulement huit valeurs DSCP, les règles de réécriture sur l’interface de sortie condensent le mappage de 64 à 8 valeurs avec une perte globale de granularité. Dans ce cas, vous disposez des options suivantes :
Supprimez les règles de réécriture de l’interface de sortie.
Configurez l’interface de sortie pour inclure les mappages les plus importants.
Configuration des règles CoS
Pour configurer une règle CoS, incluez l’instruction suivante rule rule-name au niveau de la [edit services cos] hiérarchie :
[edit services cos] rule rule-name { match-direction (input | output | input-output); term term-name { from { application-sets set-name; applications [ application-names ]; destination-address address; destination-prefix-list list-name <except>; source-address address; source-prefix-list list-name <except>; } then { application-profile profile-name; dscp (alias | bits); forwarding-class class-name; syslog; reflexive; | revert; | reverse { application-profile profile-name; dscp (alias | bits); forwarding-class class-name; syslog; } } } }
Chaque règle CoS se compose d’un ensemble de termes, semblable à un filtre configuré au niveau de la [edit firewall] hiérarchie. Un terme se compose des éléments suivants :
fromstatement : spécifie les conditions de correspondance et les applications incluses et exclues.thenstatement : spécifie les actions et les modificateurs d’action à effectuer par le logiciel du routeur.
Appliquez la règle CoS à un ensemble de services au niveau de la [edit services] hiérarchie :
[edit services]
service-set service-set-name {
cos-rules [cos-rule-name];
}
Les sections suivantes expliquent comment configurer les composants des règles CoS :
- Configuration de la direction de correspondance pour les règles CoS
- Configuration des conditions de correspondance dans les règles CoS
- Configuration des actions dans les règles CoS
- Configuration de la création de session CoS lorsque le paquet est reçu dans une direction non correspondante
- Exemple : Configuration de règles CoS
Configuration de la direction de correspondance pour les règles CoS
Chaque règle doit inclure une match-direction instruction qui spécifie la direction dans laquelle la correspondance de règle est appliquée. Pour configurer l’application de la correspondance, incluez l’instruction match-direction au niveau de la [edit services cos rule rule-name] hiérarchie :
match-direction (input | output | input-output);
Si vous configurez match-direction input-output, la création de règles bidirectionnelles est autorisée.
Le sens de correspondance est utilisé par rapport au flux de trafic à travers le PIC multiservices, le MS-MIC ou le MS-MPC. Lorsqu’un paquet est envoyé au PIC, des informations de direction sont emportées avec lui.
Dans un ensemble de services d’interface, la direction des paquets est déterminée par l’entrée ou la sortie d’un paquet de l’interface sur laquelle l’ensemble de services est appliqué.
Dans le cas d’un ensemble de services de saut suivant, la direction du paquet est déterminée par l’interface utilisée pour acheminer le paquet vers le PIC multiservices, le MS-MIC ou le MS-MPC. Si l’interface interne est utilisée pour acheminer le paquet, la direction du paquet est entrée. Si l’interface externe est utilisée pour diriger le paquet vers le PIC multiservices, le MS-MIC ou le MS-MPC, le sens du paquet est émis. Pour plus d’informations sur les interfaces internes et externes, reportez-vous à la section Configuration des ensembles de services à appliquer aux interfaces de services.
Sur le PIC multiservices, le MS-MIC ou le MS-MPC, une recherche de flux est effectuée. Si aucun flux n’est trouvé, le traitement des règles est effectué. Toutes les règles de l’ensemble de services sont prises en compte. Lors du traitement des règles, la direction des paquets est comparée à la direction de la règle. Seules les règles dont les informations de direction correspondent à la direction du paquet sont prises en compte.
Configuration des conditions de correspondance dans les règles CoS
Pour configurer les conditions de correspondance CoS, incluez l’instruction au from niveau de la [edit services cos rule rule-name term term-name] hiérarchie :
from { application-sets set-name; applications [ application-names ]; destination-address address; destination-prefix-list list-name <except>; source-address address; source-prefix-list list-name <except>; }
L’adresse source et l’adresse de destination peuvent être IPv4 ou IPv6. Vous pouvez utiliser l’adresse source ou l’adresse de destination comme condition de correspondance, de la même manière que vous configureriez un filtre de pare-feu. Pour plus d’informations, reportez-vous au Guide de l’utilisateur Stratégies de routage, filtres de pare-feu et mécanismes de contrôle du trafic.
Vous pouvez également spécifier une liste de préfixes source ou de destination en configurant l’instruction prefix-list au niveau de la [edit policy-options] hiérarchie, puis en incluant l’instruction destination-prefix-list ou source-prefix-list dans la règle CoS. Pour obtenir un exemple, reportez-vous à la section Exemples : configuration de règles de pare-feu dynamiques.
Si vous omettez le from terme, le routeur accepte tout le trafic et les gestionnaires de protocole par défaut prennent effet :
Le protocole UDP (User Datagram Protocol), le protocole TCP (Transmission Control Protocol) et l’ICMP (Internet Control Message Protocol) créent un flux bidirectionnel avec un flux inverse prédit.
IP crée un flux unidirectionnel.
Vous pouvez également inclure les définitions de protocole d’application que vous avez configurées au niveau de la hiérarchie ; pour plus d’informations, reportez-vous à la [edit applications] section Configuration des propriétés de l’application.
Pour appliquer une ou plusieurs définitions de protocole d’application spécifiques, incluez l’instruction
applicationsau niveau de la[edit services cos rule rule-name term term-name from]hiérarchie.Pour appliquer un ou plusieurs ensembles de définitions de protocole d’application que vous avez définies, incluez l’instruction
application-setsau niveau de la[edit services cos rule rule-name term term-name from]hiérarchie.Note:Si vous incluez l’une des instructions spécifiant les protocoles d’application, le routeur dérive les informations de port et de protocole de la configuration correspondante au niveau de la
[edit applications]hiérarchie ; vous ne pouvez pas spécifier ces propriétés en tant que conditions de correspondance.
Configuration des actions dans les règles CoS
Pour configurer les actions CoS, incluez l’instruction suivante then au niveau de la [edit services cos rule rule-name term term-name] hiérarchie :
[edit services cos rule rule-name term term-name] then { application-profile profile-name; dscp (alias | bits); forwarding-class class-name; syslog; reflexive; | revert; | reverse { application-profile profile-name; dscp (alias | bits); forwarding-class class-name; syslog; } }
Les principales actions du CoS sont les suivantes :
dscp: signale le paquet avec la valeur ou l’alias DSCP (DiffServ code point) spécifié.forwarding-class: assigne le paquet à la classe de transfert spécifiée.
Pour plus d’informations sur les valeurs DSCP et les classes de transfert, reportez-vous à la section Exemples : Configuration de la classe de service sur les interfaces de services ou au Guide de l’utilisateur de la classe de service (routeurs et commutateurs EX9200).
Vous pouvez éventuellement définir la configuration pour enregistrer les informations dans la fonction de journalisation système en incluant l’instruction syslog au niveau de la [edit services cos rule rule-name term term-name then] hiérarchie. Cette instruction remplace tout syslog paramètre inclus dans la configuration par défaut de l’ensemble de services ou de l’interface.
Pour plus d’informations sur certaines actions CoS supplémentaires, consultez les sections suivantes :
- Configuration des profils d’application à utiliser en tant qu’actions de règle CoS
- Configuration des actions réflexives, d’annulation et d’inversion des règles de classe de service
Configuration des profils d’application à utiliser en tant qu’actions de règle CoS
Vous pouvez éventuellement définir un ou plusieurs profils d’application à inclure dans les actions CoS. Pour configurer les profils d’application, incluez l’instruction suivante application-profile au niveau de la [edit services cos] hiérarchie :
[edit services cos] application-profile profile-name { ftp { data { dscp (alias | bits); forwarding-class class-name; } } sip { video { dscp (alias | bits); forwarding-class class-name; } voice { dscp (alias | bits); forwarding-class class-name; } } }
L’instruction application-profile comprend deux composants principaux et trois types de trafic : ftp avec le data type de trafic et sip avec les types de video trafic et voice Vous pouvez définir les valeurs et forwarding-class appropriées dscp pour chaque composant dans le profil d’application.
Les ftp instructions et sip ne sont pas prises en charge sur les routeurs Universal Edge 3D MX Series de Juniper Network.
Vous pouvez appliquer le profil d’application à une configuration CoS en l’incluant au niveau de la [edit services cos rule rule-name term term-name then] hiérarchie.
Configuration des actions réflexives, d’annulation et d’inversion des règles de classe de service
Les services CoS sont unidirectionnels. Il peut être nécessaire de spécifier des traitements différents pour des écoulements dans des directions opposées.
Qu’un paquet corresponde ou non à la direction d’entrée, de sortie ou d’entrée-sortie, des flux dans les deux sens sont créés. Une action CoS avant, arrière ou avant/arrière est associée à chaque flux. Gardez à l’esprit que le flux dans le sens inverse peut finir par être associé à une action CoS que vous n’avez pas spécifiquement configurée.
Pour contrôler la direction dans laquelle le service est appliqué, par opposition à la direction dans laquelle la correspondance de règle est appliquée, vous pouvez configurer l’instruction (reflexive | revert | reverse) au niveau de la [edit services cos rule rule-name term term-name then] hiérarchie :
[edit services cos rule rule-name term term-name then]
reflexive; | revert; | reverse {
application-profile profile-name;
dscp (alias | bits);
forwarding-class class-name;
syslog;
}
Les trois actions s’excluent mutuellement :
reflexiveentraîne l’application des actions de règle CoS aux flux dans le sens inverse ainsi qu’aux flux dans le sens correspondant.À partir de Junos OS version 16.1R5 et Junos OS version 17.4R1, stocke le DSCP et la classe de transfert d’un paquet reçu dans le sens de correspondance de la règle,
revertpuis applique ce DSCP et cette classe de transfert aux paquets reçus dans le sens inverse de la même session.reversepermet de définir le comportement CoS des flux dans le sens inverse.
Si vous omettez l’instruction, les flux de données héritent du comportement CoS du flux de contrôle direct.
Configuration de la création de session CoS lorsque le paquet est reçu dans une direction non correspondante
À partir de Junos OS version 16.1R5 et Junos OS version 17.4R1, vous pouvez configurer un ensemble de services pour créer une session CoS, même si un paquet est d’abord reçu dans le mauvais sens de correspondance pour une règle CoS affectée à l’ensemble de services. Il en résulte que les valeurs de la règle CoS sont appliquées dès qu’un paquet est reçu dans la bonne direction de correspondance. Pour configurer cette fonctionnalité, incluez les éléments suivants match-rules-on-reverse-flow au niveau de la [edit services service-set service-set-name cos-options] hiérarchie :
[edit services service-set service-set-name cos-options] match-rules-on-reverse-flow;
Exemple : Configuration de règles CoS
L’exemple suivant montre une configuration CoS contenant deux règles, l’une pour la correspondance d’entrée sur un ensemble d’applications spécifié et l’autre pour la correspondance de sortie sur une adresse source spécifiée :
[edit services]
cos {
rule my-cos-rule {
match-direction input-output;
term term1 {
from {
source-address 10.1.3.2/32;
application-set sip;
}
then {
dscp ef;
syslog;
}
}
term term2 {
from {
destination-address 10.2.3.2;
applications http;
}
then {
dscp af21;
}
}
}
}
Configuration d’ensembles de règles CoS
L’instruction rule-set définit un ensemble de règles CoS qui déterminent les actions que le logiciel du routeur effectue sur les paquets dans le flux de données. Vous définissez chaque règle en spécifiant un nom de règle et en configurant des termes. Ensuite, vous spécifiez l’ordre des règles en incluant l’instruction rule-set au niveau de la [edit services cos] hiérarchie avec une rule instruction pour chaque règle :
rule-set rule-set-name { rule rule-name; }
Le logiciel du routeur traite les règles dans l’ordre dans lequel vous les spécifiez dans la configuration. Si un terme d’une règle correspond au paquet, le routeur effectue l’action correspondante et le traitement de la règle s’arrête. Si aucun terme d’une règle ne correspond au paquet, le traitement se poursuit jusqu’à la règle suivante de l’ensemble de règles. Si aucune des règles ne correspond au paquet, celui-ci est abandonné par défaut.
Exemples : Configuration de la classe de service sur les interfaces de services
Pour que les paramètres soient cohérents entre les routeurs Juniper Networks, vous devez configurer de nombreux paramètres CoS au niveau de la hiérarchie à utiliser sur les [edit class-of-service] interfaces de services. Lorsque vous validez cette configuration avec ce que vous configurez au niveau de la [edit services cos] hiérarchie, ces propriétés sont appliquées au PIC multiservices, au MS-MIC ou au MS-MPC.
Les exemples de configuration suivants au niveau hiérarchique [edit class-of-service] peuvent être appliqués sur les interfaces de services. Pour plus d’informations, reportez-vous au Guide de l’utilisateur de la classe de service (routeurs et commutateurs EX9200).
Les deux premières configurations, à savoir le mappage du nom de la classe de transfert à l’ID de la classe de transfert et le mappage du nom de la classe de transfert au numéro de file d’attente, s’excluent mutuellement.
Mappage du nom de la classe de transfert à l’ID de la classe de transfert
Mappez les noms de classe de transfert aux ID de classe de transfert :
[edit class-of-service]
forwarding-classes {
forwarding-class fc0 0;
forwarding-class fc1 0;
forwarding-class fc2 1;
forwarding-class fc3 1;
forwarding-class fc4 2;
forwarding-class fc5 2;
forwarding-class fc6 3;
forwarding-class fc7 3;
forwarding-class fc8 4;
forwarding-class fc9 4;
forwarding-class fc10 5;
forwarding-class fc11 5;
forwarding-class fc12 6;
forwarding-class fc13 6;
forwarding-class fc14 7;
forwarding-class fc15 7;
}
Mappage du nom de la classe de transfert au numéro de file d’attente
Mappez les noms des classes de transfert aux numéros de file d’attente :
[edit class-of-service]
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
queue 4 ef1;
queue 5 ef2;
queue 6 af1;
queue 7 nc1;
}
Mappage d’alias de points de code Diffserv avec des bits DSCP
Mappez les noms d’alias aux valeurs de bits DSCP. Les alias peuvent alors être utilisés à la place des bits DSCP dans les configurations de services adaptatifs.
[edit class-of-service]
code-point-aliases {
(dscp | dscp-ipv6 | exp | ieee-802.1 | inet-precedence) {
alias | bits;
}
}
Voici un exemple :
code-point-aliases {
dscp {
my1 110001;
my2 101110;
be 000001;
cs7 110000;
}
}
Voir aussi
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme 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.
revert puis applique ce DSCP et cette classe de transfert aux paquets reçus dans le sens inverse de la même session.