Mettre en œuvre de la Qualité de service dans un réseau de campus (Enabling Quality of Service in a campus network) Best Practice Document Document rédigé par le groupe de travail « ToIP » animé par le GIP RENATER (BPD R5.1) Sébastien BOGGIA – [email protected]– Université de Strasbourg / GIP RENATER Benjamin COLLET – [email protected]- Université de Strasbourg / GIP RENATER Gaétan ENDERLE - [email protected]– Université Joseph Fourier Grenoble / GIP RENATER Christophe PALANCHE – [email protected]- Université de Strasbourg / GIP RENATER Guillaume SCHREINER – [email protected]- Université de Strasbourg / GIP RENATER Hervé THALMENSY - [email protected]– MENESR / GIP RENATER V23/03/2015
26
Embed
Mettre en œuvre de la Qualité de service dans un réseau de campus
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Mettre en œuvre de la Qualité de service dans un réseau de campus
(Enabling Quality of Service in a campus network)
Best Practice Document
Document rédigé par le groupe de travail « ToIP » animé par le GIP RENATER
(BPD R5.1)
Sébastien BOGGIA – [email protected] – Université de Strasbourg / GIP RENATER Benjamin COLLET – [email protected] - Université de Strasbourg / GIP RENATER
4.1.1 Classification de type Multifield Classifier (MF) 8
4.1.2 Classification de type Behavior Aggregate (BA) 9
4.2 Gestion de la congestion 9
4.3 Ordonnancement 9
4.4 Remarquage des paquets 9
5 Cas pratique 10
5.1 Exemple d’un réseau de campus 10
5.2 Classes de service mises en œuvre 11
5.3 Politique appliquée à chaque classe de service 12
5.3.1 Paramétrage des classes de services 13
5.4 Configurations des équipements 15
5.4.1 Configurations communes à tous les équipements 15
5.4.2 Configurations spécifiques en fonction du type d’équipement 18
5.5 Mise en production des configurations 24
6 References 26
4
Résumé
Ce document a pour but d’expliquer les principes et l’intérêt de mettre en œuvre une politique de qualité de service (QoS) dans un réseau de campus. Pour s’inscrire dans la lignée des Campus Best Practice, cet article essaye d’apporter une vision synthétique de la question et les bases nécessaires pour démarrer. Ainsi dans une première partie, les concepts de base de la QoS sont introduits. Ils sont par la suite illustrés par un exemple concret de déploiement d’une politique de QoS sur des équipements d’un réseau de campus de marque Juniper. Ce document n’aborde pas la QoS appliquée à du trafic IPv6, multicast ou MPLS. Néanmoins, les mécanismes sont similaires.
5
1 Qu’est ce que la QoS ?
Dans un réseau IP, des flux correspondant à des applications de nature différente se côtoient. Chacun de ces
flux possède des contraintes spécifiques en terme de débit, de latence1, de gigue
2 et de tolérance à la perte de
paquets. La QoS apporte une solution aux problèmes de congestion du réseau en optimisant le transfert de
différents groupes de flux en s’adaptant aux spécificités de chacun.
Détaillons quelques exemples de flux communément rencontrés sur des réseaux de campus :
Utilisation standard (web, mail, applications): les applications standards ne nécessitent pas de débit
particulièrement important. Basée sur des flux TCP/IP, la perte de paquets est tolérée tant qu’elle n’est
pas excessive. La latence et la gigue ne sont pas les facteurs les plus importants.
Voix sur IP : la voix sur IP nécessite des débits limités (64kbit/s par ligne). Cependant, s’agissant de
communications temps réel, la latence, la gigue et la perte de paquets doivent être très faibles.
Vidéo : les flux multimédia nécessitent des débits importants. De plus la latence et la gigue doivent être
faibles. Cependant, contrairement à la voix, selon le type de transmission vidéo on a plus ou moins de
souplesse : Dans une transmission en streaming (cours, conférences en 1 vers N) les effets de la gigue
peuvent être gommés grâce à la mémoire tampon du côté du récepteur. Pour une visioconférence (N
vers N), plus temps réel, il est préférable de limiter latence et gigue.
Sauvegarde, Big Data (transfert de données de gros volumes) : ce type de données est généralement
très gourmand en bande passante et ne doit pas impacter les autres types de flux, mentionnés ci-
dessus, plus temps réels. Le temps de réalisation d’un transfert étant secondaire, la latence, la gigue et
la durée totale du transfert sont de moindre importance.
L’activation de la QoS sur le réseau permettra de répondre à l’ensemble des contraintes décrites ci-dessus en
jouant sur plusieurs paramètres pour chaque groupe de flux : la bande passante allouée, la priorité de
transmission ou la mise en buffer du trafic.
2 Pourquoi déployer de la QoS ?
En amont d’un déploiement de QoS, plusieurs facteurs sont à étudier afin de vérifier la pertinence de sa mise
en œuvre.
Tout d’abord, il convient de tenir compte de la nature des flux transitant sur le réseau. Sur un réseau opérant
uniquement des flux de type data comme du web, de la messagerie, des transferts de fichiers, il n’est pas
1 La latence est le délai de transmission d’un paquet d’un côté à l’autre du réseau. Elle est liée au temps de traitement d’un paquet par un
équipement réseau, au nombre d’équipements réseau (hops) se trouvant sur le chemin et à la distance entre l’émetteur et le récepteur.
2 La gigue est la variation de la latence dans le temps. Elle peut être liée à des problèmes de congestion.
6
nécessaire d’activer une politique de QoS. Par contre, en rajoutant des flux comme de la voix sur IP ou des
transferts de gros volumes, la question se pose sérieusement.
En effet, il est important de tenir compte des capacités des liaisons et de leur taux d’utilisation. Une
communication de qualité en voix sur IP dans un réseau congestionné sans QoS n’est pas garantie. Un
transfert de gros volumes de données occasionnant de la congestion aura un impact important sur le ressenti
utilisateur des autres applications. Pour essayer de généraliser, plus un réseau est encombré et plus il est
utilisé par des applications de nature différente, alors plus la QoS est nécessaire.
3 Fonctionnement et règles de base
La QoS fonctionne grâce à des marqueurs contenus dans les en-têtes Ethernet ou IP (Figure 1). Pour les en-
têtes Ethernet, la technique de QoS appelé COS (IEEE 802.1p [1]) s’utilise obligatoirement avec un TAG de
VLAN (IEEE 802.1Q [2]). Dans le découpage du champ TAG, on trouve dans le champ PCP codé sur 3 bits qui
autorise 8 niveaux différents de priorité pour la COS.
Figure 1: en tête Ethernet
Pour les en-têtes IPv4 ou IPv6, la QoS s’applique grâce au champ DSCP (Differentiated Service Code Point,
RFC2474 [3], voir figure 2) codé sur 6 bits offrant théoriquement 64 niveaux de priorités différents. Le champ
ECN (Early Congestion Notification, RFC3168 [4]) codé sur 2 bits est utilisé pour la gestion séparée et de bout
en bout de la congestion.
7
Figure 2: en tête IPv4
Dans ce document nous nous intéressons plus particulièrement au marqueur DSCP contenu dans l’en-tête IP.
Celui-ci apporte la garantie d’être présent jusqu’à la prise contrairement au champ CoS de l’en-tête Ethernet
présent uniquement sur les trames taguées en 802.1p/q (liaisons inter-commutateurs). Par ailleurs, même si
Ethernet est très présent sur les réseaux, sa présence n’est pas garantie pour tous types de liaisons.
Pour être efficace, la QoS doit être implémentée sur toute la longueur du chemin emprunté par un flux, c’est à
dire sur l’ensemble des équipements d’un réseau de campus ayant la même politique de QoS. Nous
appellerons cet ensemble un domaine.
Avant de configurer les équipements, il est recommandé de faire l’inventaire des différents flux circulant sur le
réseau. En effet, la mise en œuvre de la QoS se base sur la définition de différentes classes de service. Une
classe de service permet d’agréger des flux de même nature afin d’appliquer un traitement de QoS spécifique.
Il existe plusieurs classes de services normalisées décrites dans la RFC4594 [5]. Lorsqu’aucune QoS n’est
activée par défaut, l’ensemble des flux, à l’exception du trafic de contrôle des protocoles réseau, sont associés
à la classe de service Best Effort. En activant la QoS, de nouvelles classes de service seront définies pour
chaque type de flux nécessitant un traitement particulier.
Les classes de services les plus couramment utilisées sont dédiées à :
la voix sur IP,
la vidéo,
les applications métier,
les transferts de données nécessitant une bande passante importante.
8
4 Implémentations sur les équipements
Comme nous l’avons vu, la politique appliquée aux classes de service doit être paramétrée sur chaque
équipement du réseau. Cette configuration se base sur différents paramètres associés aux classes de service :
la taille des buffers d’interface de l’équipement allouée,
le taux de bande passante minimum réservé basé sur le débit de l’interface,
l’ordonnancement des paquets associés aux différentes classes de service.
Ainsi lorsqu’un paquet arrive sur un équipement, il franchit les étapes suivantes :
la classification du paquet. L’équipement détermine à quel type de flux appartient le paquet et donc à
quelle classe de service il doit être associé,
la gestion de la congestion,
l’ordonnancement,
le re-marquage du champ QoS si nécessaire,
le passage à travers des règles de policing3 ou de shaping
4.
A noter : selon le constructeur et la gamme du matériel, les différentes étapes peuvent se dérouler dans un
ordre différent. Ceci a un impact sur les configurations. C’est en partie pour cela que ce document n’est illustré
qu’au travers d’équipements Juniper. Les terminologies utilisées dans les points 4.1.1 et 4.1.2, décrites dans la
RFC2474, sont utilisées par Juniper. Elles ne le sont pas forcement chez les autres constructeurs.
4.1 Classification du trafic
La classification du trafic se fait à l’arrivée d’un paquet sur chacun des équipements du réseau. Pour assurer le
bon fonctionnement de la politique de QoS la classification doit être homogène à l’ensemble du réseau.
Il existe différentes méthodes de classification du trafic. La méthode qui convient dépend de la position des
interfaces d’un équipement au sein du réseau :
soit dans un domaine untrusted (non digne de confiance), c’est à dire si elles sont connectées à des
équipements administrés par un tiers (bordure de réseau, PC, téléphones, serveurs …),
soit dans un domaine trusted (digne de confiance), c’est à dire si elles sont connectées à des
équipements administrés par la même entité.
4.1.1 Classification de type Multifield Classifier (MF)
Dans un domaine untrusted - sur les interfaces d’un équipement de bordure de réseau - il convient de
s’assurer que les paquets provenant d’équipements administrés par un tiers (postes de travail, serveurs,
téléphones, routeur de bordure) utilisent des marqueurs QoS qui seront correctement interprétés.
Dans ce cas, il est conseillé de classifier le trafic qui entre sur l’équipement en fonction :
de règles de filtrage correspondant à des IP, des protocoles ou des ports particuliers,
de l’interface ou du vlan de provenance. Un vlan ou un port peuvent par exemple être dédiés à une
application particulière.
3 Le policing consiste à limiter un flux en marquant ou en jetant les paquets dépassant un seuil fixé.
4 Le shaping consiste à réguler un flux dépassant un seuil fixé en retardant les paquets dans un buffer jusqu’à une limite maximale.
9
4.1.2 Classification de type Behavior Aggregate (BA)5
Dans un domaine trusted, l’intégrité des champs QoS étant garantie par les équipements de bordure (méthode
Multifiled Classifier), la classification est donc possible uniquement par la lecture des marqueurs DSCP des
paquets entrant sur l’équipement. Cette méthode a pour avantage d’être plus simple à configurer et moins
consommatrice en ressources, ce qui convient tout à fait à des équipements de cœur de réseau traitant une
grande quantité de trafic.
4.2 Gestion de la congestion
La classification permet d’associer un paquet à une classe de service. Chaque classe de service est elle même
associée à une file d’attente pour laquelle les paquets sont traités de manière spécifique. Le mécanisme de
gestion de la congestion associe à la classe de service une probabilité de suppression plus ou moins forte en
cas de congestion de la file.
Selon le constructeur ou le modèle d’équipement, le nombre et la position des files varient. Par exemple, les
commutateurs Cisco Catalyst possèdent deux files sur l’interface en entrée et quatre files sur l’interface en
sortie. Les équipements Juniper de type EX possèdent huit files sur les interfaces en sortie.
4.3 Ordonnancement
L’ordonnancement consiste à transmettre le trafic contenu dans les files. Chaque file correspond à une partie
du buffer d’interface dans lequel le trafic est mis en attente avant d’être expédié. Selon la file, le trafic aura une
priorité et une bande passante réservée différentes.
Ainsi, les paramètres suivants varient pour chacune des files :
espace du buffer alloué, plus l’espace est grand plus la file pourra accueillir de paquets,
bande passante allouée, plus ou moins importante,
limitation de la bande passante par des méthodes de policing ou shaping
Selon les équipements, l’ordonnancement du trafic est géré grâce à des algorithmes de Round Robin pouvant
varier en fonction des équipements.
4.4 Remarquage des paquets
Le re-marquage consiste à modifier le marqueur QoS contenu dans le paquet de manière à la rendre conforme
à la politique QoS du réseau. Il est conseillé de remarquer tous les paquets provenant de domaines de non
confiance.
5 Extrait de la RFC2474 : Behavior Aggregate : a collection of packet with the same codepoint crossing a link in
a particular direction.
10
5 Cas pratique
5.1 Exemple d’un réseau de campus
Les éléments qui viennent d’être présentés dans la première partie du document vont être illustrés par un cas
pratique. L’exemple choisi porte sur un réseau de campus sur lequel on souhaite appliquer une politique de
QoS du cœur de réseau jusqu’à la prise.
La figure 3 représente le cas simplifié d’un réseau de campus d’architecture standard composé des éléments
suivants :
un équipement de routage de cœur et de bordure abr1
des commutateurs/routeurs d’agrégation agr1 et agr2
des commutateurs d’accès reliant des postes informatiques ainsi que des téléphones access-sw1 et
access-sw2
un commutateur de datacenter dc-sw1
Comme pour la plupart des réseaux, des postes de travail et des téléphones y sont connectés.
Dans cet exemple, on considèrera trois types de serveurs :
• Un IPBX pour la téléphonie sur IP,
• Un serveur destiné au stockage de masse (images systèmes, sauvegardes ou GRID),
• Un serveur destiné à des applications de visioconférence, de la diffusion vidéo en streaming.
Figure 3: réseau de campus
11
La QoS est appliquée sur tous les équipements du réseau. Ainsi, un exemple de configuration pour chaque
type d’équipement sera donné.
Le réseau a été divisé en deux domaines dont dépend la politique de QoS :
un domaine de confiance : Trusted Area,
un domaine de non digne de confiance : Untrusted Area.
La classification du trafic dépendra du domaine auquel appartient une interface.
Les interfaces des équipements qui sont connectés à d’autres équipements dont les administrateurs de la
même organisation ont la maîtrise sont considérées comme faisant partie du domaine Trusted Area. Il s’agit
des équipements réseau ou de serveurs. On considère que les marqueurs QoS des paquets provenant de ces
interfaces sont fiables.
Les interfaces connectées à des équipements dont les administrateurs n’ont pas la maîtrise ou ne peuvent pas
garantir l’intégrité des marqueurs QoS sont considérées comme faisant partie du domaine Untrusted Area. Sur
un réseau de campus, cela peut être le cas pour les postes de travail raccordés derrière des téléphones. C’est
également le cas en bordure de réseau. On ne peut en effet pas considérer les marqueurs QoS provenant
d’Internet comme fiables.
5.2 Classes de service mises en œuvre
Les classes de services mises en œuvre doivent correspondre aux besoins des différentes applications qui
transitent sur le réseau. C’est aux administrateurs du réseau de faire un choix. Dans notre exemple, nous en
avons retenu quatre (en dehors de la classe de service dédiée contrôle du réseau6).
Le tableau 1 affiche les classes de service retenues pour le réseau servant d’exemple : Pour chaque classe de
service, la valeur du marqueur DSCP positionné dans l’en-tête IP du paquet, ses caractéristiques et les
applications qui l’utilisent y sont décrites.
Classe de service
DSCP (binaire)
PHB7
Caractéristiques Applications ciblées
Best Effort 0 (000000)
be
Par défaut pour le trafic standard. Tolérances :
perte de paquet : moyenne,
latence : moyenne,
gigue : moyenne.
Trafic standard :
web,
mails,
applications métier.
Less than Best Effort
8 (001000) cs1
Trafic consommant beaucoup de bande passante. Ne doit pas impacter les autres flux réseau. Tolérances :
perte de paquet : élevée,
latence : élevée,
gigue : élevée.
Trafics volumineux :
grilles de calcul,
sauvegarde,
gestion d’images de
postes de travail.
Video 34 (100010) af41
Trafic plus prioritaire que Best Effort. Réservation d’une part non négligeable de la bande passante. Tolérances :
perte de paquet : faible - moyenne,
latence : faible,
Diffusion vidéo : ● visioconférences ● retransmissions en direct
de cours, conférences
6 Classe “network control”: utilisée pour transmettre les paquets contenant les informations de contrôle (routage) entre les différents
noeuds du réseau. 7 PHB (Per Hop Behavior) : définit le comportement de l’équipement en fonction de la valeur du champ QoS (DSCP) d’un paquet.
12
gigue : faible.
Voice 46 (101110) ef
Trafic concernant la voix sur IP. Trafic prioritaire pour assurer une bonne qualité. Bande passante limitée. Tolérances :
perte de paquet : très faible,
latence : très faible,
gigue : très faible.
Voix sur IP :
téléphones IP,
softphones,
applications SIP
Tableau 1
Les marquages DSCP n’ont pas été choisis au hasard. Ils s’appuient sur les préconisations de la RFC 4594[5]
.
Note : Les classes de services décrites dans ce document sont utilisées dans un réseau régional fédérant
plusieurs campus universitaires. A l’exception des noms, elles sont équivalentes à celles utilisées par le NREN
français RENATER [6]. Cela a pour avantage d’utiliser des marqueurs QoS mutualisés lorsque l’on utilise des
services nécessitant de la QoS hors du réseau de campus [7]. Le trafic est alors plus facilement classifié. En
contrepartie, un travail de coordination plus important avec le réseau voisin doit être mené.
5.3 Politique appliquée à chaque classe de service
L’application des politiques de classes de services dépend beaucoup des implémentations faites par les
constructeurs d’équipements réseau. Ainsi, un choix a été fait lié à l’expérience. Les explications et les
configurations qui suivent sont donc adaptées aux équipements Juniper de la gamme EX. Un minimum de
connaissances de JunOS est requis pour comprendre les configurations qui suivent.
Remarques :
Selon les modèles de la gamme EX, quelques différences de fonctionnalités selon la maturité du
modèle ou son architecture matérielle peuvent se présenter. Il est conseillé de vérifier les spécifications
techniques des équipements.
Les configurations suivantes, à quelques différences près, s’appliquent également sur d’autres
gammes d’équipements Juniper comme par exemple les gammes MX ou SRX.
Les configurations QoS pour du trafic Multicast [8] ou IPv6 [9], non abordées dans les pages qui
suivent, sont détaillées dans des documents mentionnés dans la partie références.
Pour bien comprendre les configurations, la figure 4 représente le traitement appliqué aux paquets lorsqu’ils
traversent l’équipement.
Figure 4: diagramme de traitement de la QoS
Chaque paquet entrant dans un équipement franchit les étapes suivantes :
Classification du paquet selon :
• le marqueur QoS (BA),
• le port,
13
• le VLAN de provenance,
• des règles de filtrage (MF) appliquées sur le trafic entrant.
Policing : appliqué directement en entrée après la classification,
Queuing : gestion de la congestion en affectant les paquets et les priorités de suppression aux files
d’attentes liées aux interfaces de sortie en fonction de la classification selon les algorithmes WTD
(weighted tail drop) ou WRED (weighted random early detection),
Scheduling : ordonnancement des paquets selon la programmation de chaque file. Les files sont
traitées selon deux méthodes :
• Strict high Priority (SP) : files ultra prioritaires, les paquets de la file sont immédiatement
transmis,
• Shaped Deficit Weighted Round Robin (SDWRR) : les files de ce type se partagent entre elles
la bande passante selon ce qui leur a été alloué.
Shaping : mise en buffer si le trafic dépasse un certain débit,
Remarking : modification, si nécessaire, du marqueur QoS correspondant à la classe de service.
5.3.1 Paramétrage des classes de services
Le paramétrage des classes de services se fait pour chaque file selon plusieurs critères: l’allocation des ressources du buffer, la priorité, la bande passante allouée et le paramétrage d’un seuil maximum de bande passante.
5.3.1.1 Allocation du buffer
Le trafic contenu dans les files est stocké dans le buffer de sortie de l’équipement. Pour chaque port, les
ressources du buffer sont réparties entre les différentes files selon les besoins des classes de services.
Figure 5
La figure 5 représente la répartition du buffer entre les différentes classes de service.
Pour les classes Voice et Network Control la taille du buffer est restreinte car le type de trafic est prioritaire sur
les autres et représente une faible partie de la bande passante du réseau. En outre la latence et la gigue
doivent être très faibles. Les paquets doivent séjourner un minimum de temps dans la file.
Pour la classe Less than Best Effort, la taille du buffer est limitée car en cas de congestion, les paquets doivent
être rapidement jetés pour permettre une meilleure régulation des flux.
5.3.1.2 Priorité des files
Les équipements Juniper ont 8 files en sortie. Ils traitent le trafic contenu dans les files d’attente en
commençant par le numéro de file du plus grand vers le plus petit. Les files Voice et Network Control sont
14
paramétrées en ultra prioritaires (SP). Les autres files sont traitées selon l’algorithme SDWRR. Les classes de
services sont attribuées aux files suivantes :
file 0 : Best Effort,
file 1 : Less than Best Effort,
file 2 : Video,
file 5 : Voice,
file 7 : Network control.
5.3.1.3 Bande passante allouée aux files
Files prioritaires (SP) :
Le trafic des files prioritaires est transmis avant celui des autres files. Il n’y a donc pas besoin de garantir une
bande passante minimale. Cependant une limite haute est positionnée pour éviter que le trafic strictement
prioritaire de ces files monopolise toute la bande passante de l’interface au détriment des autres files.
Des limiteurs de trafic ont été positionnés sur les ports de sortie pour les files :
voice : limitation à 10% de la bande passante,
network control : limitation à 5% de la bande passante
Autres files (SDWRR) :
Une partie de la bande passante est réservée pour les files liées aux classes de services Best Effort (60%),
Video (20%) et Less than Best Effort (le reste disponible). Il s’agit d’une bande passante minimale réservée à
chacune des files en cas de congestion. Le trafic des files peut dépasser ce seuil si des ressources sont
disponibles. La bande passante a été attribuée de manière arbitraire selon les besoins estimés pour chaque
classe de service.
Afin que la classe Less than Best Effort puisse écouler un minimum de trafic même en cas de congestion du
port, la somme des débits maximum des files ultra prioritaires et des bandes passantes des autres classes
n’excède pas 100% (10+5+60+20=95 %).
La figure 6 illustre la priorité, la bande passante et les limiteurs de trafic alloués aux files.
Figure 6: priorité et bande passante
15
Le tableau suivant récapitule les paramétrages QoS :
Classe de Service
DSCP - PHB
Numéro de file
priorité taille du buffer bande passante minimale garantie
rate limiter
Best Effort 0 – be 0 SDWRR 60% 60% -
Less than Best Effort (LBE)
8 - cs1 1 SDWRR le reste disponible
le reste disponible
-
Video 34 - af41 2 SDWRR 20% 20% -
Voice 46 – ef 5 SP 5% sans objet 10%
Network-control (NC)
48,56 7 SP 5% sans objet 5%
Tableau 2
5.4 Configurations des équipements
5.4.1 Configurations communes à tous les équipements
Les configurations suivantes doivent être appliquées et rester équivalentes sur tous les équipements du
réseau. Elles ont été déployées sur des équipements des gammes EX et MX.
Avant de commencer, nous allons rapidement donner un aperçu des configurations par défaut d’un
équipement. Lorsqu’aucune configuration n’est entrée, 4 classes de services sont implémentées et associées à
4 files :
best-effort -> file 0
assured-forwarding -> file 1
expedited-forwarding -> file 5
network-control -> file 7
En dehors du trafic de type Network Control, l’équipement traite l’ensemble du trafic en mode Best Effort
quelques soient les marqueurs QoS des en-têtes Ethernet et IP. Ces derniers ne sont pas altérés. Si vous le
souhaitez, ces configurations par défaut peuvent servir de base aux configurations QoS.
Nous allons maintenant configurer les classes de services détaillées dans le paragraphe précédent. La
majeure partie des configurations se trouve dans la configuration JunOS class-of-service.
Avec le CLI de l’équipement, pour entrer les configurations se positionner dans class-of-service :
eq# top edit class-of-service
16
Les configurations suivantes sont le résultat des paramétrages réalisés à l’aide de la commande set. Il est
possible également de les entrer par un copier/coller fait après avoir lancé la commande load merge
terminal relative.
5.4.1.1 Associations des classes de services aux files
La première action consiste à créer et nommer des classes de services et les affecter aux files.
{master:0}[edit class-of-service]
eq# show
forwarding-classes {
class best-effort queue-num 0;
class lbe queue-num 1;
class video queue-num 2;
class voice queue-num 5;
class network-control queue-num 7;
}
Le résultat de cette commande est visible en tapant la commande :
eq# run show class-of-service forwarding-class
5.4.1.2 Paramétrage des ordonnanceurs
Les ordonnanceurs de files sont paramétrés selon les informations du tableau 2.
{master:0}[edit class-of-service]
eq# show
schedulers {
control-sched {
shaping-rate percent 5;
buffer-size {
percent 5;
exact;
}
priority strict-high;
}
voice-sched {
shaping-rate percent 10;
buffer-size {
percent 5;
exact;
}
priority strict-high;
}
video-sched {
transmit-rate percent 20;
buffer-size percent 20;
priority low;
}
be-sched {
transmit-rate percent 60;
buffer-size percent 60;
priority low;
}
lbe-sched {
transmit-rate {
remainder;
}
buffer-size {
remainder;
}
priority low;
}
}
17
Les ordonnanceurs sont ensuite associés aux classes de services.
{master:0}[edit class-of-service] eq# show scheduler-maps {