Qualité de Service sur Linux Malik GUILLAUD Nicolas COUTANT

Plan Problématique Analyse État de l’art Nos Propositions

Contexte Qualité de Service (QoS) ? Exemples Disponibilité Bande Passante Latence Gigue Pertes Exemples

Les problèmes concrets (1/2) Vue générale gros download/upload ftp (ralentissement général des autres trafics) les flux multimédia  ex : radio, vidéoconférence, vocal, VoIP favoriser la réactivité des protocoles interactifs légers  ex : ssh, telnet, http, … favoriser/limiter des applications spécifiques  ex : son serveur web, un jeu, messagerie instantanée Disponibilité : première mesure de la qualité de service. Bande passante : Latence : temps entre l’envoie d’un paquet et la réception de celui. Gigue : Variation de latence. Pertes :

Les problèmes concrets (2/2) Vue réseau limiter les trafics parasites et gourmands (ex : p2p, recherche de MAJ automatique) contrôler le partage de la bande passante control suivant des paramètres précis (ex : adresse/masque IP, utilisateur)

Analyse Les principaux ordonnanceurs et les architectures d’ordonnancement Les possibilités du noyau Linux 2.6 La commande TC

Les Ordonnanceurs FIFO : premier arrivé premier servi, les paquets sont envoyés dans l’ordre ou ils sont arrivés. PRIO : les paquets sont envoyés par ordre de priorités. TBF (Token Bucket Filter) : le flux de données est lisser en fonction du nombre de jeton disponible dans le sceau. SFQ (Stochastic Fair Queuing) :

Les Architectures d’ordonnancement (1/2) Class Based Queuing Les differents flux sont divisés en classes avec des priorités différentes. Les autres flux sont envoyés en Best-Effort. Class Based Queuing : la plus utilisée. Hierarchical Token Bucket : la bande passante est partagées en plusieurs classes et sous-classes.

Les Architectures d’ordonnancement (2/2) Heriarchical Token Bucket Même principe que pour CBQ (hiérarchisation des flux) mais avec un sceau à jeton comme ordonnanceur.

Les possibilités du noyau Linux 2.6 Marquage par Netfilter/Iptables : Grâce à la table mangle, qui permet de marquer n’importe quel paquet passant a travers le Netfilter. Les fonctionnalités du noyau Linux 2.6 nous permet de marquer les paquets grâce à Netfilter/Iptables. Ces marquages peuvent être fait sur ….

La Commande TC Les classificateurs : tc qdisc {add | del} dev INTERFACE root cbq [avpkt AVPKT] [bandwidth BP] [cell CELL] [maxburst MAXBURST] [minburst MINBURST] [minidle MINIDLE] [mpu MPU] [rate RATE] Les classificateurs : Fw (Firewall) : suivant le marquage par NetFilter. U32 : peut lire n’importe quel champ d’un paquet IP. Route : permet de classer les paquet en fonction de leur numéro de route. La commande TC est très complexe vu le nombre d’option disponibles et le nombres de possibilités qu’offre les classificateurs.

État de l’Art Les Script de QoS TCNG (Traffic Control Next Generation)

Les Script de QoS CBQ.init et HTB.init WonderShaper Avantage : Puissant, Beaucoup de possibilités Inconvénient : Complexité de configuration WonderShaper Avantage : Simplicité de configuration, « priorisation » de flux interactifs légers (ssh,telnet,…) Inconvénient : Fonctionnalités limitées 3 script principaux pour la QoS. Les deux premiers script ont l’avantages d’être assez puissant, ils fournissent donc de nombreuses possibilités de configuration mais cette dernière est très complexe pour un utilisateur lambda. Pour Wondershaper, ça configuration est très souple mais il fournit une qualité de service assez limitée tout de même (classification de flux important : telnet, ssh, …)

Traffic Control Next Generation (1/2) Génère, à partir d’un pseudo langage du genre C ou Perl et grâce à un compilateur (TCC), plusieurs formes de commandes TC. Offre aussi la possibilité de simuler différents trafics (TCSIM). TCNG n’est pas un script mais un programme qui traduit un fichier de configuration écrit dans un pseudo langage du style C ou Perl afin dans déterminer plusieurs commandes tc correspondants à ce fichier. De plus ce programme contient un simulateur de trafic réseau.

Traffic Control Next Generation (2/2)

Nos propositions Le but de ce projet technique est fournir une implémentation de la QoS facilement configurable pour un utilisateur lambda et permettant de fournir de très bonnes fonctionnalités. Au niveau de l’implémentation, nous avons pensé créer une classe mère contenant les principaux flux de données et en suite de configurer les classes filles . Une fonctionnalité intéressante serait de différencier les flux en fonction de leur sous-réseau.

Les contraintes Utilisable par des personnes ayant les connaissances de bases en réseau (port, adresse IP, bande passante) Relativement simple à configurer Couvre un maximum de besoin en QoS

Architecture et files Quelle architecture choisir ? Implémentation HTB de l’architecture CBQ - la plus performante - exploite les dernières MAJ du kernel Quelles files d’attentes ?  htb semble être un bon choix…

Schéma général

La classe mère Intégration d’une « pré-hiérarchie des priorités » : Forte priorité pour les protocoles interactifs légers : ssh, telnet Priorité « moyenne » pour http Priorité « assez faible » pour ftp  Hiérarchie bénéfique dans la très grande majorité des cas

Les classe filles (1/2) Une classe-fille correspond à un groupe de machines Pour chacun de ses groupes sont à configurer: les adresses des machines du groupe les applications spécifiques (ports et/ou adresses destinations) à forte priorité celles à très faible priorité la bande passante affectée à ce groupe éventuellement les attributs unbounded et isolated (par défaut à faux pour optimiser le réseau)

Les classe filles (2/2) Répond à la plupart des problèmes pouvant se poser Évolutivité Assez léger à configurer (un seul fichier et un nombre de variables raisonnable) Nécessité de connaître tous les ports/adresses destinations des applications à configurer

Hiérarchie des priorités

Partage de bande passante

Test du script pour les priorités, une simple machine sous linux avec accès à internet pour un 1er test sur les groupes, une passerelle et une machine cliente tests poussés: hommel ?

MERCI