Numérotation de classe / filtre Linux TC

Je travaille actuellement sur une solution de mise en forme du trafic pour les entreprises de niveau FAI, et est arrivé à un problème intéressant (un peu philosophique).

En regardant le nombre de points finaux que le système devrait gérer (ce qui est d'environ ~ 20k), je me suis un peu inquiété de ce qui se passerait lorsque j'aurais besoin de définir / définir le trafic d'un plus grand nombre d'utilisateurs. Comme j'utilise actuellement l'arbre de mise en forme HFSC (voir tc-hfsc, principalement la même chose mais plus cool que HTB mieux connu) pour l'ensemble du réseau, je devrais utiliser plus de ClassID (évidemment au moins un pour chaque utilisateur sur le réseau). Le problème que j'ai trouvé était que les TC ClassID sont un peu limités - ce sont des nombres de 16 bits, ce qui me donne un maximum possible de 64 000 utilisateurs façonnés par cette solution.

De même, si je souhaite gérer efficacement les filtres TC (par exemple, sans utiliser la «technique de vidage complet»), je dois pouvoir supprimer ou modifier des entrées de filtre individuelles. (J'utilise quelque chose de similaire à la table de hachage de LARTC [1]). Encore une fois, la seule méthode qui semble fonctionner est de numéroter tous les filtres en utilisant des priorités individuelles (filtre tc add dev ... prio 1). Aucun autre paramètre ne peut être utilisé à cette fin, et, malheureusement, prio est également en 16 bits uniquement.

Ma question est la suivante: existe-t-il une bonne méthode pour agrandir "l'espace identifiant" disponible, comme les clsid 32 bits pour la commande 'tc class', et les priorités 32 bits (ou tout autre descripteur de modification) pour 'filtre tc' commander?

Merci beaucoup,

-mk

(btw j'espère que cela n'ira pas au scénario "64k utilisateurs devraient suffire à tout le monde" ...)

— exa
source

Toutes ces valeurs sont stockées dans l'espace du noyau, pour les agrandir, vous devez recompiler votre noyau et les utilitaires de l'espace utilisateur. Avez-vous essayé d'utiliser un noyau 64 bits? Ils peuvent y être définis comme 32 bits.

— Hubert Kario

Le noyau 64 bits utilise les mêmes tailles. Par exemple, le numéro de filtre est un entier u32 qui se compose de la partie supérieure (protocole) et de la partie inférieure (prio), toutes deux évidemment de 16 bits. Les ID de classe sont codés en dur comme u16. Je vais probablement essayer de demander à quelqu'un sur LKML.

— exa

même en utilisant du hachage pour vos filtres, vous allez avoir beaucoup de problèmes d'E / S si vous utilisez autant de filtres (je suppose pour l'amont et pour l'aval). J'ai passé beaucoup de temps et j'ai dû patcher l'implémentation des files d'attente dans le noyau pour que les choses fonctionnent avec ksoftirqd. J'ai utilisé un patch d'un type appelé Simon Lodal que j'ai rencontré sur LARTC il y a 4 ans. Jetez un œil à son patch mail-archive.com/lartc@mailman.ds9a.nl/msg16279.html . Vous pouvez essayer de lui envoyer un e-mail car il a toujours une version très mise à jour (contre le dernier noyau) avec lui.

— Pabluez

@Pabluez Merci beaucoup, je vais essayer d'en tirer le meilleur parti.

— exa

Je pense que votre exigence est valide mais comme l'écrit Pabluez, cela implique certainement beaucoup de changements dans le noyau. Je ne veux pas dire "vous vous trompez", mais je vous encourage à vérifier openflow, où les parties inférieures de la gestion des paquets sont effectuées au niveau du commutateur et la police est effectuée dans un logiciel personnalisé, probablement en cours d'exécution dans l'espace utilisateur. Je ne sais pas si cela correspond à vos besoins, mais cela vaut certainement la peine d'être étudié.

— AndreasM

Réponses:

je pense que vous ne devriez pas mettre 64k utilisateurs avec des classes et des filtres en amont et en aval pour chacun d'eux sur la même interface. Vous pouvez répéter les gestionnaires pour chaque interface dont vous disposez, alors ajoutez d'autres interfaces. Vous aurez besoin d'un travail / serveur / NIC incroyable pour avoir ces choses. Si le serveur tombe en panne, vous aurez 64k utilisateurs hors ligne (et il se plantera facilement avec cette quantité de trafic). N'oubliez pas que CHAQUE paquet qui passe par votre carte réseau sera vérifié et classé par un filtre et envoyé à une classe pour être mis en file d'attente. C'est beaucoup de travail pour une carte réseau d'une passerelle ISP avec 64k clients. Principalement avec tout le flux vidéo que nous avons de nos jours (ce qui est difficile à mettre en file d'attente correctement).

— Pabluez
source

J'assure la disponibilité du service à un autre niveau, mais merci de votre inquiétude. En fait, avec de bonnes cartes réseau, ce n'est pas si difficile d'avoir un routeur linux capable de transmettre 10 Gbits.

— exa

Pour la question d'origine, j'étais plus intéressé par des choses comme l'ajout de 5 classes différentes pour chaque utilisateur, ce qui me permettrait de faire un très bon travail de qualité de service (comme la gestion des flux et du trafic en temps réel séparément), mais est généralement impensable dans les conditions actuelles (avec mon cas d'utilisation actuel de ~ 20 k points de terminaison, je serais déjà derrière la limite).

— exa

D'accord, transmettre 10 Gbits n'est pas un problème, le problème est d'avoir de nombreux filtres et classes 64k * 2 (ups downs). Bonne chance cependant: D

— Pabluez le

Vous pouvez diviser la gestion du trafic en deux machines (en utilisant une troisième) au lieu de gérer tout le trafic sur une machine. Le trafic peut être acheminé simplement en fonction de l'adresse IP source. Ainsi, vous disposerez de 10 000 utilisateurs de manière optimale si vous pouvez diviser la ou les plages IP de manière égale.

Bien sûr, vous pouvez utiliser plus de deux machines si nécessaire. Je pense que cela peut être mieux que de patcher le noyau Linux et de faire d'autres hacks. En bref, la mise en forme du trafic sera répartie sur plusieurs machines. Le nœud central transmettra simplement le trafic au bon nœud de traitement.

— Khaled
source