Je pense que tu as trouvé le problème. Il faudrait que quelqu'un tente de mettre un IAID différent pour voir la réponse. Je ne suis pas migré.
En même temps ton Mikrotik devrait te laisser le choix, il y a un topic pour les Mikrotik.

Il n'y a pas besoin de mettre l'adresse MAC de la Livebox. C'est même probablement mieux que tout soit cohérent entre le DUID, l'IPv6 link-local et l'adresse MAC parceque la configuration légitime est cohérente.

J'ai cloné la Mac de mon ER4 sur mon CCR et déjà vérifié que tout était bon au niveau CoS, cohérence Mac, client-id IPv4 et DUID IPv6

Tout est pareil en gros sauf l'IAID d'où mon post d'ailleurs parce que je sèche là.

Essaye de débrancher la fibre qques minutes.
J’ai aussi deja réussi à débloquer de cliquant plein de fois sur release / renew. Hasard ?

Bonjour,
Je tourne avec une config ipv4/ipv6 et systemd-networkd, le 05/04 le client DHCPv4 a cessé de renouveller correctement les baux.
Je fais tourner un cron toutes les 19h pour restart les clients DHCPv4,6 et ainsi relancer les cycles et redevenir routable sur wan 832.
Quelqu'un a remarqué ce comportement ? Peut-être spécifique à systemd...

Cheers,
johnk

Thank you for responding. I know those settings are advised, but my pfSense with a fs.com ONT SFP worked like a charm for 2 years until this winter when Orange tightned the DHCP protocol compliance. Now I get an IP just fine and it works for about 24 hours until the DHCP renew. Then the line stops responding and I have to login and do a DHCP release and renew to get it going again. I suspect perhaps the Renew is not COS6 tagges out of pfSense as the discover frame is when configured on the DHCP client.

The lease comes with a renew interval of aprox. 24 hours, a rebind interval of about 6 days, and an expiration interval of 7 days.
It’s normal for a DHCP client to attempt renew when the renew timer (T1) expires, so pfSense is just doing what it’s suppose to.
But as soon as a renew reqeust has been sent, the line stops routing traffic, so Orange must consider something wrong with that attempt, and shut down routing.

I then have to do a full DHCP release and renew to get another ~24 hours.

It’s a single stack IPv4 only setup.

Okay - that does seem to indicate this might be my problem. I will stage a full packet capture tonight when the renew attempt happens again, and then I’ll know if the Renew is COS6 tagged or not.
I believe i can create a floating match rule in pfSense that looks for - and priority tags - DHCP frames going out of my WAN VLAN interface.
That way there is no need to have the DHCPv4 client modified to tag renews if it does not support this right now. I know it correctly tags discover frames currently.

What you described was exactly my issue and thanks to everyone's advice here, my issue was indeed due to incorrect VLAN priority.
I managed to solve it with following firewall rule that was missing in my config:

iptables -t mangle -A POSTROUTING -o wan -p udp --sport 68 --dport 67 -j CLASSIFY --set-class 0:6

DHCP renews can be altered with iptables as opposed to initial DISCOVER which I handle with https://www.freedesktop.org/software/systemd/man/systemd.network.html#SocketPriority=

My VLAN mapping being 6-6 with a systemd netdev:
https://www.freedesktop.org/software/systemd/man/systemd.netdev.html#EgressQOSMaps=

Works like a charm now 

systemd-networkd does not have an option to set SO_PRIORITY for renews so I guess iptables is still needed, at least for me. Same goes for IPv6.