Embed Size (px)
Citation preview
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
2
© GIP RENATER 2014 © TERENA 2014. All rights reserved. Document No: GN3plus-NA3-T2-R5.1 Version / date: V2 – 23/03/2015 Original language : French Original title: Mettre en œuvre de la Qualité de service dans un réseau de campus Original version / date: V1 - 03/12/2014 Contact: [email protected] RENATER bears responsibility for the content of this document. The work has been carried out by a RENATER led working group on metropolitan network as part of a joint-venture project within the HE sector in France. Parts of the report may be freely copied, unaltered, provided that the original source is acknowledged and copyright preserved. The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 605243, relating to the project 'Multi-Gigabit European Research and Education Network and Associated Services (GN3plus)'.
3
Table of Contents
1 Qu’est ce que la QoS ? 5
2 Pourquoi déployer de la QoS ? 5
3 Fonctionnement et règles de base 6
4 Implémentations sur les équipements 8
4.1 Classification du trafic 8
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 {
port-sched {
forwarding-class voice scheduler voice-sched;
forwarding-class video scheduler video-sched;
forwarding-class lbe scheduler lbe-sched;
forwarding-class network-control scheduler control-sched;
forwarding-class best-effort scheduler be-sched;
}
}
Remarque : Il est possible de créer plusieurs modèles d’association “ordonnanceurs” - “classes de services”.
On peut en effet souhaiter ordonnancer le trafic de différentes manières selon le type de l’interface, sa position
au sein du réseau ou son débit. Il faut dans ce cas créer des ordonnanceurs adaptés aux différents cas puis les
appliquer aux ports de sortie en créant le “scheduler-map” approprié. Par exemple : un “scheduler-map”
nommé port-sched pour les interfaces de type backbone et un scheduler-map nommé access-port-sched pour
les interfaces de type accès.
Dans notre exemple nous nous contenterons d’utiliser le “scheduler-map” port-sched que nous appliquerons à
tous les ports.
Le paramétrage des schedulers liés à port-sched est visible en tapant la commande :
eq# run show class-of-service scheduler-map port-sched
5.4.1.3 Réécriture des marqueurs QoS
Lorsque l’on déploie une politique de QoS sur un réseau, il s’agit de s’assurer que seuls les marqueurs
correspondant aux classes de services définies circulent sur le réseau. Il convient donc de réécrire les champs
QoS sur tout le trafic sortant en particulier sur les équipements possédant des interfaces dans des domaines
untrusted.
{master:0}[edit class-of-service]
eq# show
rewrite-rules {
dscp rewrite-dscp {
import default;
forwarding-class voice {
loss-priority low code-point ef;
}
forwarding-class video {
loss-priority low code-point af41;
}
forwarding-class lbe {
loss-priority high code-point cs1;
}
forwarding-class best-effort {
loss-priority low code-point be;
}
}
}
Le paramétrage de réécriture des marqueurs liés aux classes de services est visible en tapant la commande :
eq# run show class-of-service rewrite-rule name rewrite-dscp
18
5.4.1.4 Paramétrage des classificateurs basés sur les marqueurs QoS
La dernière étape de configuration commune à tous les équipements consiste à mettre en place le
paramétrage de la classification basée sur la valeur des champs DSCP. Nous verrons juste après que cette
méthode sera appliquée sur les paquets provenant d’interfaces placées dans les domaines trusted.
{master:0}[edit class-of-service]
eq# show
classifiers {
dscp dscp_ba {
import default;
forwarding-class voice {
loss-priority low code-points ef;
}
forwarding-class video {
loss-priority low code-points af41;
}
forwarding-class lbe {
loss-priority high code-points cs1;
}
forwarding-class best-effort {
loss-priority low code-points be;
}
}
}
Remarque : la commande import default permet d’importer les classificateurs du groupe de classification
configuré par défaut sur l’équipement. Cet import est nécessaire pour la classe Network Control qui en fait
partie (Taper la commande eq# run show class-of-service classifier name dscp-default pour les
visualiser).
Le paramétrage de la classification faite en fonction du champ DSCP est visible en tapant la commande :
eq# run show class-of-service classifier name dscp_ba
5.4.2 Configurations spécifiques en fonction du type d’équipement
Nous nous référerons à la figure 3 pour le nommage des équipements.
5.4.2.1 Equipements ayant des interfaces uniquement dans le domaine de confiance
Les équipements d’agrégation agr1 et agr2 ont des interfaces appartenant toutes au domaine de confiance.
En outre elles ne sont connectées qu’à des équipements réseau. On peut donc considérer que :
l’on peut se fier aux marqueurs DSCP,
il n’est pas nécessaire de réécrire les marqueurs lorsque les paquets sortent d’une interface.
On applique sur toutes les interfaces une classification du trafic entrant basée sur la valeur du champ DSCP.
{master:0}[edit class-of-service]
agr1# show
interfaces {
all { # all peut être remplacé par xe-*, par ge-* ou un nom complet ge-1/1
unit 0 {
classifiers {
dscp dscp_ba;
}
19
}
}
}
On applique ensuite aux mêmes interfaces les ordonnanceurs pour le trafic sortant.
{master:0}[edit class-of-service]
agr1# show
interfaces {
all {
scheduler-map port-sched;
unit 0 {
classifiers {
dscp dscp_ba;
}
}
}
}
5.4.2.2 Equipements à cheval entre deux domaines
routeur de bordure abr1
L’équipement abr1 est l’équipement de bordure de réseau. Il permet l’accès à Internet que l’on peut aisément
considérer comme un domaine untrusted.
Ainsi les interfaces connectées à Internet :
doivent classifier tout le trafic entrant en Best Effort sauf exception
ne doivent pas tenir compte des marqueurs QoS des paquets entrants et les réécrire.
Il est courant de placer des règles de filtrage en entrée ou sortie d’un réseau de campus. Il suffit d’y ajouter un
term pour classifier tout le trafic entrant en Best Effort.
{master:0}[edit]
abr1# show firewall
firewall {
family inet {
filter internet-in {
...
term best_effort_traffic {
then {
loss-priority low;
forwarding-class best-effort;
next term;
}
}
...
}
}
}
Il est courant que des transferts de type “big data” aient lieu entre différents réseaux de campus. Dans ce cas
le trafic des serveurs émetteurs du trafic peut être identifié à l’entrée du réseau et classifié en Less than Best
Effort.
{master:0}[edit]
abr1# show firewall
firewall {
family inet {
filter internet-in {
...
term best_effort_traffic {
then {
loss-priority low;
forwarding-class best-effort;
next term;
20
}
}
term lbe_traffic {
from {
source-address {
192.0.2.0/24;
203.0.113.0/24;
}
}
then {
forwarding-class lbe;
loss-priority high;
next term;
}
}
...
}
}
}
Remarque : JunOS permet d’appliquer à chaque interface un filtre pour le trafic entrant et un filtre pour le trafic
sortant. Les règles servant à la QoS pour la classification se trouvent dans le filtre appliqué au trafic entrant, au
même titre que les règles de firewall. Attention de ne pas oublier la commande next term dans les règles de
QoS afin que le parcours se poursuivre jusqu’aux règles de firewall.
Le filtre est appliqué aux interfaces d’interconnexion en bordure de réseau.
{master:0}[edit interfaces]
abr1# show
xe-0/0/0 {
description "Internet link1";
unit 0 {
family inet {
filter {
input internet-in;
}
address 198.51.100.1/24;
}
}
}
Les interfaces connectées à agr1 et agr2 sont toutes deux dans le domaine de confiance. On applique le
même traitement QoS que celui des interfaces de agr1 et agr2 en appliquant une réécriture des marqueurs
QoS pour le trafic sortant. Ainsi les marqueurs provenant d’Internet seront ré-étiquetés en Best Effort.
{master:0}[edit class-of-service] agr1# show interfaces interfaces {
xe-1/0/0 { scheduler-map port-sched;
unit 0 {
classifiers {
dscp dscp_ba;
} rewrite-rules {
dscp rewrite-dscp; }
}
} }
Commutateurs d’accès access-sw1 et access-sw2
21
Les commutateurs access-sw1 et access-sw2 ont des ports connectés à des postes informatiques ou des
téléphones. Dans notre exemple de campus universitaire avec des environnements variés, on considère que
ces postes ne sont pas dans un domaine de confiance.
On utilise alors la méthode de classification “Multifield Classifier” basée sur des règles de filtrage appliquées
sur le trafic entrant.
{master:0}[edit] access-sw1# show firewall firewall {
family ethernet-switching { filter mf-edge-class { term voip { from { source-prefix-list { net-ip-phone; } } then { forwarding-class voice; loss-priority low; policer voip-limit; } } term video { from { destination-prefix-list { hosts-visio; } } then { forwarding-class video; loss-priority low; } } term best_effort_traffic { then { forwarding-class best-effort; loss-priority low; } } } }
Le filtre est appliqué aux interfaces connectées aux téléphones IP et aux postes de travail.
{master:0}[edit interfaces] access-sw1# show ge-0/0/0 { description "PC + IPphone";
unit 0 { family ethernet-switching { filter { input mf-edge-class; }
port-mode access; vlan members 4
} } }
22
Le trafic provenant des téléphones IP est classifié en croisant les IP des trames émises qu’ils émettent avec le
prefix-list “net-ip-phone”. Le trafic à destination du serveur de visioconférence est classifié grâce au prefix-
list “hosts-visio”.
{master:0}[edit] access-sw1# show policy-options policy-options { prefix-list net-ip-phone { 172.0.0.0/22; } prefix-list hosts-visio { 10.0.0.1/32; 10.0.0.2/32; } }
En raison du caractère ultra prioritaire de la classe de service Voice, un limiteur de trafic est également
positionné sur chaque port connectant un PC ou un téléphone. Cela permet d’éviter les “accidents” conduisant
à une saturation de la bande passante totale de l’interface par le trafic strictement prioritaire de la classe de
service Voice.
{master:0}[edit] access-sw1# firewall { policer voip-limit { if-exceeding { bandwidth-limit 1m; burst-size-limit 15k; } then discard; } }
La partie classification étant maintenant traitée, on applique sur toutes les interfaces raccordant des postes de
travail ou des téléphones :
le ré-étiquetage des marqueurs QoS en sortie (pour les paquets non ré-étiquetés provenant du trafic de
poste à poste),
les ordonnanceurs (schedulers).
{master:0}[edit class-of-service] agr1# show interfaces interfaces {
ge-0/0/0 { scheduler-map port-sched;
unit 0 { rewrite-rules {
dscp rewrite-dscp; }
}
} }
Pour finir, les mêmes règles que sur les autres équipements s’appliquent aux interfaces dans le domaine de
confiance.
{master:0}[edit class-of-service] agr1# show interfaces interfaces {
xe-1/0/0 {
23
scheduler-map port-sched;
unit 0 {
classifiers {
dscp dscp_ba;
} rewrite-rules {
dscp rewrite-dscp; }
}
} }
Commutateur de datacenter dc-sw1
Le commutateur dc-sw1 connecte au réseau plusieurs serveurs que l’on estime comme faisant partie du
domaine trusted. Ainsi plusieurs méthodes de classification du trafic peuvent exister au niveau des interfaces
du côté serveurs, basées sur :
le champ DSCP,
un VLAN dédié à une application nécessitant de la QoS,
un port connectant un serveur n’émettant qu’un seul type de trafic (Voice, Video, Less than Best Effort),
des règles de filtrage sur des adresses IP.
Si l’application marque les paquets selon la politique QoS décidée, la méthode de classification basée sur le
champ DSCP fait l’affaire. C’est souvent le cas pour les serveurs ToIP qui utilisent le code point 46. Les règles
QoS appliquées à l’interface sont les mêmes que pour les interfaces de cœur de réseau.
{master:0}[edit class-of-service] dc-sw1# show interfaces interfaces {
ge-0/0/0 { scheduler-map port-sched;
unit 0 {
classifiers {
dscp dscp_ba;
}
}
} }
Si un vlan est dédié à une application, la classification peut se faire dans les règles de filtrage du trafic entrant
en fonction du vlan.
dc-sw1# show firewall firewall {
family ethernet-switching {
… filter mf-edge-class { term lbe { from { vlan vlan_GRID; }
…
}
La règle de filtrage est alors appliquée à l’interface sur laquelle est diffusée le Vlan.
{master:0}[edit interfaces] dc-sw1# show ge-0/0/0 {
24
description "serveur de calcul"; unit 0 {
family ethernet-switching { filter { input mf-edge-class; }
port-mode access; vlan members 800 ;
} } }
Pour finir avec le commutateur dc-sw1, les mêmes règles que sur les autres équipements du réseau
s’appliquent aux interfaces dans le domaine de confiance.
{master:0}[edit class-of-service] dc-sw1# show interfaces interfaces {
xe-1/0/0 { scheduler-map port-sched;
unit 0 {
classifiers {
dscp dscp_ba;
} rewrite-rules {
dscp rewrite-dscp; }
}
} }
5.5 Mise en production des configurations
Les équipements Juniper sont configurés par le CLI JunOS qui permet de créer des groupes dans le but de
distinguer les configurations QoS des autres configurations (ports, protocoles, système,…). En plus d’améliorer
la lisibilité des configurations QoS, celles-ci peuvent être rapidement désactivées en cas de problème lors des
phases de mise en production.
Pour améliorer la visibilité, faciliter le déploiement à grande échelle des configurations, les configurations
peuvent être séparées en deux catégories :
Les configurations globales, qui définissent la politique de QoS, semblables sur tous les équipements.
Elles peuvent être déployées et maintenues à jour à l’aide de scripts d’administration du réseau.
Les configurations qui consistent à appliquer les configurations globales QoS sur les ports ou les vlans
de l’équipement (méthode de classification, re-marquage, scheduling). Celles-ci peuvent être
appliquées à l’aide d’un outil d’administration des équipements lors des modifications opérées sur les
ports de l’équipement comme par exemple l’ajout du Vlan TOIP.
Sur chaque équipement, un groupe peut être créé pour les configurations globales, celles qui ne changent que
lorsque la politique de QoS change. Nous l’appellerons “qos-global-conf”.
groups { qos-global-conf { } }
25
Un autre groupe correspond aux configurations appliquées aux différentes interfaces.
groups { qos-apply-conf { } }
La QoS est fonctionnelle en activant les groupes. Ceux-ci ne sont pas activés par défaut sur l’équipement.
eq# set apply-groups qos-global-conf eq# set apply-groups qos-apply-conf
Elle peut être rapidement désactivée à l’aide des commandes suivantes.
eq# delete apply-groups qos-global-conf eq# delete apply-groups qos-apply-conf
26
6 References
[1] IEEE 802.1p – IEEE standard for traffic Class Expediting and Dynamic Multicast
Filtering added to the IEEE 802.1D standard
[2] IEEE 802.1Q - standard specifying Virtual LANs and VLAN Bridges. It is
intended to merge 802.1D into 802.1Q, resulting in a combined bridging
standard.
[3] RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers
[4] RFC 3168 - K. Ramakrishnan, S. Floyd, D. Black, « The Addition of Explicit Congestion
Notification (ECN) to IP », september 2001
[5] RFC 4594 - J. Babiarz, K. Chan, F. Baker, « Configuration Guidelines for DiffServ
Service Classes », August 2006
[6] https://services.renater.fr/connectivite/classes_de_services
[7] https://services.renater.fr/voix_et_image/configuration_qos
[8] Juniper Networks, « ENABLING CLASS OF SERVICE ON EX SERIES SWITCHES IN
A CAMPUS LAN »
http://www.juniper.net/us/en/local/pdf/implementation-guides/8010073-en.pdf
