Je m'occupe de deux sites dans les environs de Toulouse, tous les deux en contrat Sosh et je confirme qu'aucun des deux n'a été migré (pas d'option 17 en retour en DHCPv6, la chaîne d'auth sans le mot de passe fonctionne encore, etc...)


Je profite justement des vacances pour mettre les choses "au carré" et éviter de perdre la connexion.

Conformément aux recommandations de LeVieux, en plus des options adéquates dans les clients DHCPv4/DHCPv6, j'ai implémenté un mécanisme de vérification de lien montant en utilisant les outils arping pour IPv4 et ndisc6 pour IPv6.

Cependant, j'ai pu constater qu'en cas de saturation de débit, certaines vérifications IPv4 échouaient mais pas celles en IPv6.
J'avais bien pensé à tagger les paquets ARP et NS émis en COS6, via netfilter.
Cependant, arping utilise des raw sockets, donc même problème qu'avec dhclient en IPv4, pas de netfilter possible.

J'ai donc changé de méthode pour passer par une solution basée sur un script tc qui tagge tous les paquets ARP, qu'ils soient émis par le kernel ou arping.
Depuis, tous les tests IPv4 et IPv6 passent sans problème, quelque soit l'état de saturation de la ligne.

Tout ça pour confirmer que, même si vous êtes dans une zone où "ça marche sans", il vaut mieux vraiment appliquer la COS6.


Par ailleurs, pour le DHCPv4, j'ai trouvé un moyen de modifier aussi le DSCP via tc.
Je sais que ce qui importe le plus, c'est la COS6, mais d'après LeVieux c'est mieux si le DSCP est en phase avec la COS.
De plus, la LB le fait, donc moi aussi.

Je ne crois pas avoir vu cette astuce ailleurs, donc je la poste ici, si ça peut servir...

Code: [Sélectionner]

tc -b - <<EOF
qdisc replace dev ${iface} \
root \
handle 1: \
prio
filter del dev ${iface}

# ARP packets emitted by kernel can be modified by netfilter but not those
# emitted by arping as it uses raw socket
filter add dev ${iface} \
parent 1: \
prio 1 \
protocol arp \
u32 \
match u8 0 0 \
action skbedit priority 0:6

# dhclient uses raw socket for DISCOVER/REQUEST
filter add dev ${iface} \
parent 1: \
prio 2 \
protocol ip \
u32 \
match ip ihl 5 0xf \
match u16 0x0000 0x1fff at 6 \
match ip protocol 17 0xff \
match ip sport 68 0xffff \
match ip dport 67 0xffff \
action skbedit priority 0:6 pipe \
action pedit munge ip tos set 0xc0 retain 0xfc pipe \
action csum ip4h
EOF

(Attention, si vous êtes sur un kernel < 5.1, il faut enlever le "protocol ip" du 2ème filter)

Avec cette astuce, il est possible de modifier non seulement la priorité COS6, mais aussi la priorité IP DSCP de n'importe quel paquet, même ceux issus d'une raw socket, sans aucun patch, sans LD_PRELOAD, ni rien compiler.

Sur CRS, il faut passer une switch rule :

/interface ethernet switch rule
add comment="Orange COS dhcpv4" dst-port=67 mac-protocol=ip new-vlan-priority=6 ports=sfp1.router protocol=udp switch=switch1 vlan-id=832
add comment="Orange COS dhcpv6" dst-port=547 mac-protocol=ipv6 new-vlan-priority=6 ports=sfp1.router protocol=udp switch=switch1 vlan-id=832
add comment="Orange COS arp" mac-protocol=arp new-vlan-priority=6 ports=sfp1.router switch=switch1 vlan-id=832
add comment="Orange COS icmpv4" mac-protocol=ip new-vlan-priority=6 ports=sfp1.router protocol=icmp switch=switch1 vlan-id=832
add comment="Orange COS icmpv6" mac-protocol=ipv6 new-vlan-priority=6 ports=sfp1.router protocol=icmp switch=switch1 vlan-id=832

pour ARP, j'hésite à préciser le VLAN-ID...
add comment="Orange COS arp" mac-protocol=arp new-vlan-priority=6 ports=sfp1.router switch=switch1 vlan-id=832
OU
add comment="Orange COS arp" mac-protocol=arp new-vlan-priority=6 ports=sfp1.router switch=switch1

J'ai tenté d'appliquer ça @cyayon sur mon CRS305, mais les paquets DHCP ne semble pas prendre en compte cela quand je fais une capture depuis le RB5009. J'obtiens une DSCP: CS0 dans les 2 sens.

As tu une configuration plus à jour ? Quelqu'un a t'il une autre façon de faire ? Si vous avez une idée ou un morceau de configuration, je suis preneur. Merci !

Hello,

Ces règles ne modifient pas le DSCP (champ ip), mais la priorité vlan (champ Ethernet 802.1p)
Edit : pour le dscp il faudrait regarder côté firewall/mangle.