J'ai bien compris que la COS 6 sur le DHCP va devenir / est deja obligatoire mais est ce aussi le cas sur l'icmp/icmpv6/arp ? ou simplement souhaitable pour la qualité de service ?

J'ai bien peur que oui

Parce que la COS 6 via le bridge filter de mon RB750gr3 fait sur sacré différence sur la charge CPU comparé à aucune regle bridge (le mode fastpath saute sur le bridge).

Pourquoi fait tu porter ton DHCP par le bridge et par par l'interface externe ??

J'envisage donc de faire les renew DHCP via un scheduler par ex ou sur trigger netwatch qui activerai les regles COS6 + renew le DHCP + desactive dans la foulée.

C'est faisable pour le DHCP mais pas vraiment pour les autre flux COS6.

Cela va être chaud de faire cela et de respecter la RFC en même temps ....
Surtout que l'on peut te répondre un bail à zéro dans le renew en cas de changement de contexte pour ta ligne.
Là tu vas perdre pied

LeVieux

si je ne me trompe, voila la logique mikrotik ( je ne demande qu'a être corrigé mais un peu hors sujet )

Le changement de COS sur des paquets en sortie est une opération L2 qui ne peut pas être réalisé par le biais de /ip/firewall/xx

Il faut le faire via du filtrage L2 qui selon le hardware se fait :
- via /interface/bridge/filter pour les petits boitiers type MT7621-based mais ca suppose de metttre l'interface VLAN dans un bridge (pas le meme que le bridge LAN hein) simplement pour donner au CPU l'occasion d'inspecter/modifier
- via /interface/ethernet/switch/rule pour les plus gros boitiers CCR et autres , question de support par le chip qui fait le switching

Dans mon cas sur un petit boitier, la config fonctionne avec un second bridge qui contient juste le vlan 832 du port WAN .. mais la présence de ces règles me fait perdre le flag 'fastpath' et fait 2-3x de charge CPU total à cause du composant 'firewall L2' qui doit inspecter tous les paquets.

Sur mon abo a 300/300 ce n'est pas trop problématique mais pour le principe...

Je dois pouvoir lire le bail en cours dans le script du scheduler toutes heures et trigger le renew ou restart intelligemment

Bonjour

J'ai fait un résumé de nos échanges dans le post 2 de ce thread

Merci de relire et me dire si vous avez besoin d'une clarification.

LeVieux

Un guide officieux d'interopérabilité, par un tech d'un opérateur, pour tracer les limites nécessaires à une connexion avec un routeur non officiel en OneP....

Merci, Levieux.

Merci.

Ce post N°2, là, on en rêve depuis longtemps, et je n'ai pas connaissance d'un précédent (corrigez moi).

En tant que modeste auteur du premier proof of concept d'éradication de tout équipement Orange (zero ONT Orange) et de son fils associé en 2,5Gbps, j'ai poussé un cri de joie en lisant ce post.

Bon, là, je suis déjà hors de chez moi, en trêve diplomatique des confiseurs (vous comprenez, il faut passer voir tout monde, voire même des ceux qui sont encore en ADSL, raaaaaahhh...) alors j'ai placé mon installation dans mode où elle ne spamme pas l'infra Orange de requêtes dhcpv6 2 fois par seconde sans clientid conforme, et j'ai complétement hâte de rentrer vérifier la compliance de mes réglages et corriger le tuto Mikrotik en fonction de ces enseignements.

C'est, vraiment, vraiment, trop cool.

Merci, encore. Merci Levieux.

Gnubyte, plus tout jeune non plus (54 ans)

Au fond, c'est toujours la même raison sous-jacente.
La stack ipv4 ne permet pas d'envoyer des paquets IPv4 avec src=0.0.0.0 et dst=0.0.0.0, c'est interdit.
Sauf que c'est nécéssaire pour le paquet initial DHCPv4/Bootp.
Donc ISC DHClient utilise des raw sockets pour le faire (il forge ses propres datagram IP).
Mais les raw socket contournent completement netfilter (y compris pour les chaines output / mangle), donc on ne peut pas alterer les paquets envoyés par DHClient. Avec DHCPv6 pas de problème, il n'y a pas de paquets "illégaux" à envoyer, donc une socket normale est utilisée, et on peut altérer la TOS avec netfilter.

Il faut alors passer par les vlans pour basculer tout en CS6 (y compris les facheuses trames DHCP reloues), et rebaculer tout le traffic normal en priorité standard.
Je trouve ça vraiment trop laid, donc je rebuild DHClient pour envoyer directement la bonne TOS = CS6.

Bien résumé…
Tu peux aussi utiliser LD_PRELOAD et modifier la so_priority au moment du lancement dhclient, c’est peut être plus élégant… et ça évite de patcher / recompiled dhclient.
Attention aussi, dhclient est deprecated et va mourir (ou pas). J’avais migrer sur systemd-networkd, et la, tu dois utiliser un script à base de tc.

Un expatrié aux USA voit que son réseau Français ne répond plus. La zone où est Sainte-Cécile, commune située dans le département de la Vendée en région Pays de la Loire, fait partie des zones où le durcissement du contrôle de l’option 90/11 est mis en œuvre ?

Bon, de retour des ripailles et libations de Noël, je profite d'un instant de répit de la supervision biologique pour cloner le ClientID procuré par DHCPv4 en option 1 ClientID pour le DHCPv6.

Alors que je lance une option 1 à 0x01488F5AXXXXXX, le log indique que j'envoie 00030001 488f5aXX XXXX.

Fatalement, ça ne matche pas, donc j'ai raté un truc.
Donc, je Read The Fucking Manual, et me plonge dans la RFC 8415 qui décrit DHCPv6, pour enfin comprendre comment ça marche dans le détail une putain de bonne fois pour toute et cesser de laisser la moindre once d'aléas se superposer à de la chance, parce que ce n'est pas comme ça que ça fonctionne.

Lien de la traduction officiellement officieuse de la RFC8415

À l'année prochaine, le temps que je lise, comprenne et intègre le tout, et en mesurer les conséquences sur ma config.

J'ai désactivé DHCPv6 le temps de comprendre, avec un release préalable.
On ne pense jamais assez au release.