Je reviens sur la gestion de la QoS en général via le réseau Orange, car récemment j'ai eu quelques mauvaises expériences plus ou moins liées à un commit récent sur openssh :
https://github.com/openssh/openssh-portable/commit/5ee8448ad7c306f05a9f56769f95336a8269f379A noter que pas mal de distributions (debian/suse/...) ont annulé temporairement ce commit notamment car il provoque des blocages sous VMware (vmnat).
On peut citer également certains Wifi-N anciens sur lesquels le débit s'effondre lorsque cette QoS est utilisée.
Et ceci met aussi en évidence un comportement du réseau orange identifié ici :
https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg633786/#msg633786Il y a en fait deux effets de QoS sur le réseau Orange :
- le VLAN tagging non désiré via egress-qos sur EgdeOS, si on utilise autre chose que 0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0
- un débit très limité si les paquets IPv4/v6 sont taggés en QoS=0x20, indépendemment de la prio VLAN
Si on veut s'affranchir de cet effet, la seule solution consiste à reproduire ce que fait la livebox, cad remettre tous les paquets montant à IPQoS=0x00, et c'est là que c'est chaud...
Si on prend l'ERL :
- la création de règles firewall modify désactive immédiatement l'offload
- il est possible de faire des règles brutes iptables/ip6tables, mais en IPv6 cela ne fonctionne pas
avec :
iptables -t mangle -A PREROUTING -i $lanintf -j TOS --set-tos=0x00
ip6tables -t mangle -A PREROUTING -i $lanintf -j DSCP --set-dscp=0x00
- la règle IPv4 fonctionne avec l'offload
- la règle IPv6 est sans effet tant que l'offload est actif
Il doit y avoir une différence d'implémentation de l'offload, ou un hook manquant en IPv6, j'essayerai à l'occasion des dernières beta du FW 2.0.9 de le signaler auprès d'UBNT.
Et au-delà je ne vois aucune solution propre, sachant que la plupart des switch ne peuvent pas marquer l'ipv4/v6 simultanément.