RE: [FRnOG] [TECH] police cir vs shape average qos
Bonjour, Pour moi la bonne config est la 2eme. Avec le shaper tu vas bufferiser donc ajouter de la latence mais ca va permettre à ta file LLQ de passer devant tout les autres paquets. La latence va permettre à TCP de ralentir les sessions et éviter le drop qui fait chuter trop rapidement le débit. Sur l'exemple 1 par contre si tu veux l'utiliser il faut retirer des 20M le débit voix que tu as besoin. Et attention au burst qui risque aussi de faire du drop au niveau de la liaison avant ton routeur. Et surtout attention ton routeur doit toujours dropper avant ta liaison sinon ca sert à rien. Aymeric Le 3 déc. 2016 2:24 AM, "Michel Py"a écrit : > Antoine Durant a écrit : > Je prends l’exemple d’une fibre 20M dans laquelle je souhaite > réserver de la BW pour 4 canaux (priority 320) J'aimerais bien avoir la réponse aussi quand tu la trouveras. J'ai eu des résultats variables. En supposant que ta fibre soit capable de 100M, çà dépend en partie de la manière dont ton FAI te limite à 20M, ou c'est toi le FAI ? Au pif, j'aurais tendance à favoriser shape average, mais j'ai pas de logique seulement que çà a marché dans le passé. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] police cir vs shape average qos
> Antoine Durant a écrit : > Je prends l’exemple d’une fibre 20M dans laquelle je souhaite > réserver de la BW pour 4 canaux (priority 320) J'aimerais bien avoir la réponse aussi quand tu la trouveras. J'ai eu des résultats variables. En supposant que ta fibre soit capable de 100M, çà dépend en partie de la manière dont ton FAI te limite à 20M, ou c'est toi le FAI ? Au pif, j'aurais tendance à favoriser shape average, mais j'ai pas de logique seulement que çà a marché dans le passé. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Linux, Multicast et VXLAN
Hello Vincent, J'ai déjà lu ta page en fait, pas plus tard qu'hier. J'étais parti pour utiliser pimd (de manière assez arbitraire) à l'étape d'après, mais je te confirme que je n'ai aucun démon configuré pour router. ip mroute ne retourne rien de rien. En revanche, ton idée m'a permis de voir une erreur dans mon setup, et oui j'ai bien quelque chose d'autre qui réinjecte la trame multicast ... comme quoi il était nécessaire par principe que je pose la question, pour me faire lever le nez. Je vais attaquer la partie router. Donc, merci ! PS : toutes mes confuses pour les yeux qui piquent avec les fautes de mon premier mél (s/trop/troll/, etc). Le 2 décembre 2016 à 15:45, Vincent Bernata écrit : > ❦ 2 décembre 2016 14:53 +0100, Baptiste Malguy : > > > Immédiatement les annonces multicast vers 239.0.0.10 sont émises depuis > > 192.168.50.5 sur eth0 et eth1, au lieu de eth0 seul. > > Perso, je trouve cela fort suprenant si tu n'as pas encore mis de démon > de routage multicast. Linux route le multicast comme l'unicast et > consulte la table de routage classique. Es-tu sûr que tu ne vois pas > simplement les trames émises sur eth0 revenir sur eth1 ? ip mroute > est-il vide ? > > Sur le VXLAN Linux, j'avais fait un peu de doc ici quand ça avait été > développé. J'ai retesté récemment et ça fonctionnait toujours : > https://vincent.bernat.im/en/blog/2012-multicast-vxlan.html > > Note que dans ton cas, faire de l'ECMP multicast ne marchera pas sans > démon de routage (genre du PIM-SM). Je compte faire ça très > prochainement, donc tout retour de ta part m'intéresse. > -- > Keep it right when you make it faster. > - The Elements of Programming Style (Kernighan & Plauger) > -- Baptiste Malguy --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Linux, Multicast et VXLAN
❦ 2 décembre 2016 14:53 +0100, Baptiste Malguy: > Immédiatement les annonces multicast vers 239.0.0.10 sont émises depuis > 192.168.50.5 sur eth0 et eth1, au lieu de eth0 seul. Perso, je trouve cela fort suprenant si tu n'as pas encore mis de démon de routage multicast. Linux route le multicast comme l'unicast et consulte la table de routage classique. Es-tu sûr que tu ne vois pas simplement les trames émises sur eth0 revenir sur eth1 ? ip mroute est-il vide ? Sur le VXLAN Linux, j'avais fait un peu de doc ici quand ça avait été développé. J'ai retesté récemment et ça fonctionnait toujours : https://vincent.bernat.im/en/blog/2012-multicast-vxlan.html Note que dans ton cas, faire de l'ECMP multicast ne marchera pas sans démon de routage (genre du PIM-SM). Je compte faire ça très prochainement, donc tout retour de ta part m'intéresse. -- Keep it right when you make it faster. - The Elements of Programming Style (Kernighan & Plauger) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Linux, Multicast et VXLAN
Bonjour, C'est vendredi, et pourtant je n'ai pas de trop à proposer :) Il était une fois Linux, le multicast et VXLAN (et un chouia de BGP). Mon cas de figure est peut-être simplissime à résoudre et je n'ai pas encore lu la bonne page de manuel à ce propos, donc si au final j'obtiens un RTFM avec la référence qui va bien, je suis preneur ! Je teste le setup décrit plus bas, et c'est sur la partie multicast que c'est drôle. La version courte : avec VXLAN (au moins), il semble que quoique je fasse, le noyau semble envoyer les trames multicast sur toutes les interfaces réseau, peu importe que j'ai cherché à le désactiver ou pas. Le trafic étant généré par le noyau et non par un processus qui puisse être influencé, je sèche après avoir testé quelques pistes. Je cherche à réduire au maximum la couche L2 au minimum du setup. Deux machines (et une gw qui n'a pas d'importance), chacune avec eth0 et eth1, et Bird : - host1 : eth0 / 192.168.50.5/28, eth1 / 192.168.50.20/28, lo:1 / 192.168.100.2/32 - host2 : eth0 / 192.168.50.6/28, eth1 / 192.168.50.21/28, lo:1 / 192.168.100.3/32 - gw : 192.168.50.1/28, 192.168.50.17/28 et 192.168.100.1/32 et ses propres uplinks - du BGP entre tout ce petite monde (Bird sur host1 et host2). gw annonce la default route, chacun annonce sa loopback et plus tard d'autres routes - plutôt qu'avoir une redondance en L2 au travers d'un trunk/LAG/portgroup, ça se passe en L3, rien de transcendant jusque là. - Ubuntu Xenial (16.04), avec un noyau 4.4.0-47 A présent je veux ajouter du VXLAN sans mettre (pour le moment) de contrôleur. Avant même de vouloir faire annoncer le VXLAN sur un groupe multicast depuis la loopback (et profiter de la redondance L3), je commence par tester le fonctionnement plus simple. Et déjà là, ça coince : Lorsque je fais ceci : # ip link add vxlan10 type vxlan id 10 group 239.0.0.10 ttl 4 dstport 4789 dev eth0 # ip link set vxlan10 up Immédiatement les annonces multicast vers 239.0.0.10 sont émises depuis 192.168.50.5 sur eth0 et eth1, au lieu de eth0 seul. Idem en configurant vers eth1 plutôt qu'eth0. Idem en ayant préalablement saisi ces commandes avant l'ajout de vxlan10 : # ip link set eth1 multicast off # ip link set eth1 allmulticast off # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth0 A noter qu'utiliser "ip link add ... local 192.168.255.2" fonctionne comme je le le souhaite (ce qui est mon objectif au départ) mais malgré, le trafic multicast part partout, que je puisse le maîtriser sur une évolution "d'archi". Suis-je en mode neuneu ou bien c'est plus subtile ? -- Baptiste Malguy --- Liste de diffusion du FRnOG http://www.frnog.org/