Qualité de service globale qui ne se dégrade que chez toi. 

Les Français sont heureux de leur réseau qui ne cesse de s'améliorer chaque jour. Tous les indicateurs le montre. De là a dire que c'est parfait, c'est un pas que je ne franchirait pas. mais ça s'améliore partout, sur tous les vecteurs, chez tous les opérateurs.

Même Free.

Sort tes indicateurs et arrête le trolling et tes banalités non sourcées. Quant à ta remarque "que chez toi", à part chercher encore une fois la m...de et nier l'évidence des autres sujets ici (par exemple et entre autres), tu cherches quoi? À continuer à prouver la pauvreté de ta production ici depuis ton inscription? Bien joué, ça marche!
Et quand bien même ça ne serait que chez moi, où est le problème? En quoi ça te fait suer? Je paye donc je suis en droit d'exiger, non? C'est pas ton discours habituellement ça?

@ochbob

Oui j'ai bien vu, comme j'expliquais hier soir, j'expérimentais avec les "vlan id 832 [...]" suite au conseil de basilix un peu plus tôt sur ce sujet (utiliser également une règle nft pour gérer la prio pour le TV d'orange). Et j'ai poussé la mauvaise conf sur le repo...

Effectivement dans mon message d'hier j'ai zappé le filter hook egress, sorry! Comme j'étais concentré sur l'idée uniquement de remplacer les "vlan id 832" par "vlan type" j'ai juste copier le bloc des règles 

Pour ce qu'y est de pousser sur le repo, je me demande si je ne vais pas plutôt partir sur les règles avec "vlan id 832 [...]", qu'on soit raccord avec la partie du tuto concernant la TV d'orange:
table netdev orange-rules {
        chain orange-rules-chain {
                type filter hook egress device "eth0" priority 0; policy accept;
                vlan id 832 meta l4proto udp udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter accept
                vlan id 832 meta l4proto icmpv6 icmpv6 type { echo-request, echo-reply, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit } vlan pcp set 6 ip6 dscp set cs6 counter accept
                vlan id 832 ip6 dscp set cs0 counter accept
                vlan id 832 meta l4proto udp udp dport 67 vlan pcp set 6 ip dscp set cs6 counter accept
                vlan id 832 ip dscp set cs0 counter accept
                vlan id 832 vlan type arp vlan pcp set 6 counter accept
        }
}
Mais si tu ne t'en sert pas, tu peux très bien utiliser les règles de mon avant dernier post, ... sans oublier le filter hook egress 

@basilix
Il se peut que parfois tes posts soient techniques, régulièrement édités, amené avec un vocabulaire soutenu et s'interdisant toute forme d'anglicismes, ce qui donne à la lecture un combo qui peut être déroutant pour certains. Mais cela n'enlève rien à tes contributions.
Si ton message m'était adressé, ne prend pas mes silences comme une attaque, parfois il me faut un petit moment pour traduire 
Ton avis est toujours le bienvenu, une partie de ma conf est par ailleurs bien grâce à toi, merci!

Par ailleurs, as tu vu que levieux nous éclaire concernant notre interrogation, quand re-généré la chaine n'auth / à chaque xid ou non?

Cela fonctionnerait (de changer les chaine en milieu de bail) mais la logique du DHCP est de garder les mêmes identifiant sur la session.

Il est mieux (mais pas impératif) de garder les info d'auth cohérente sur les deux stack sur la durée de la session dans le BNG. Mais là aussi ce n'est pas impératif dans l'implémentation actuelle.

Pour rappel, une session BNG est ouverte à la monté du premier stack v4 ou v6.
Et est fermée à la cloture (RELEASE ou DECO par timer) du dernier stack.
Entre l'ouverture et la fermeture du contexte BNG, on peut avoir autant de START/STOP des stack v4 ou v6 à la condition que l'un des deux reste connecté.
Le BNG considère qu'un client est "vivant" tant que l'un au moins des stack v4 ou v6 est en vie.