Ca me l'a fait aussi au boot du routeur.
Le CPU était occupé à 50% et j'ai remarqué que l'interface pppoe dans la webgui était vue comme disconnected (alors que ce n'était pas le cas car j'avais accès au net).
Après un moment dans la webgui elle est repassé en connected et le cpu est redescendu à 5%.

Test de débit OK aux valeurs habituelles.

upnp est pas activé dans ma conf, perso.

Signe que le traffic non offloadé est bien pris en compte dans le traffic analysis, on voit l'ip privée du client sip dans le traffic comptabilisé pour ceux qui activent le dpi analysis (ça n'était pas le cas avant).

MAJ des connaissances concernant l'adaptation de la configuration de l'ERL pour le support de l'archi en DHCP pour ipv4/ipv6 :


Pour les utilisateurs profanes d'ERL, petit récap' de la situation suite à la migration en cours de l'infra Orange vers un modèle DHCP pour l'IPv4 et IPv6.
N'hésitez pas à corriger si j'écris une boulette. C'est plus orienté vers ceux qui suivent d'un œil la discussion et voudraient avoir des informations concrètes des changements et des modifications à mettre en œuvre pour avoir une install 100% fonctionnelle avec un ERL.
J'éditerai au fur et à mesure en fonction des retours des utilisateurs plus expérimentés.

Data : la data arrive dans le vlan 832. Les trames encapsulant les paquets ARP, DHCP, ICMP sont taggés avec un Class of service (CoS) à 6 et les paquets "normaux" à 0.
VoIP : la voip arrive dans le vlan 832 (ou 851 selon le topic Microtik). Les trames encapsulant SIP et RTP arrivent avec un CoS à 5.
TV : la tv arrive sur le vlan 838/840. Prio du CoS à 4 pour 838 et 5 pour 840.


Priorisation des flux
Détail : il semblerait que Orange rejette les paquets reçus s'il n'ont pas le bon CoS. Affirmation variable selon les testeurs. Peut-être différents setup en fonction des zones de collecte.

Difficulté 1 : difficulté pour tagguer dynamiquement les paquets avec le bon CoS en sortie (3 type de CoS possible dans le vlan 832 selon que cela soit de la data, de la VoIP ou d'autres protocoles). Et après modification manuelle avec des règles, l'offload (accélération matérielle) n'est pas garanti.
Difficulté 2 : pour certains protocoles  (ex : DHCP), l'ERL les traite avant qu'on puisse vraiment agir dessus.

Solution 1 : ajout de fonctionnalités par Ubiquiti pour un tag à la volée selon le protocole (par DPI ?) sans faire sauter l'offload. Patch éventuellement possible du dhclient pour fixer la priority à 6 (voir : https://lafibre.info/remplacer-livebox/en-cours-remplacer-sa-livebox-par-un-routeur-ubiquiti-edgemax/msg311274/#msg311274).
Solution 2 : overrider le mécanisme de raw socket sur certains protocoles


IPv4
Détail : Orange attribue une adresse IPv4 publique via requête dhcp discover

Difficulté 1 : l'option dhcp 90 n'est pas géré nativement par l'ERL

Solution 1 : patch du fichier vyatta-interfaces.pl pour permettre l'ajout de l'option 90 (voir : https://lafibre.info/remplacer-livebox/en-cours-remplacer-sa-livebox-par-un-routeur-ubiquiti-edgemax/msg309517/#msg309517)


IPv6
Détail : Orange attribue un préfixe IPv6 en /56 qui est délégué au routeur.

Difficulté 1 : des options spéciales sont requises pour recevoir le préfixe IPv6 et sont à entrer manuellement dans certains fichiers
Difficulté 2 : le client DHCPv6-PD qu'utilise l'ERL (wide-dhcpv6) n'est pas top et nécessite le remplacement par un qui est plus adapté mais qui ne s'intègre donc pas dans la webgui
Difficulté 3 : option 90 non gérée nativement par l'ERL

Solution 1 : ajouter des options manuellement ne serait pas la partie la plus difficile. Ubiquiti qui intègre la possibilité de l'ajout des options dhcp via la webgui serait un plus
Solution 2 : se passer du client dhcpv6 par défaut et le remplacer par un plus adapté (ex : dibbler). Néanmoins le travail de scripting est intensif pour une intégration plus ou moins avancée.
En apparté, sur un sujet posté par Je@nb dans la section béta du forum Edgemax, des représentants d'Ubiquiti ne semblent pas trop fermés à l'idée de virer wide-dhcpv6 et laissent entendre qu'à moyen terme ça sera nécessaire... Mais ça nous amène à plus de 6 mois à 1 ans avant que ça ne puisse se retrouver dans le canal stable, si jamais ça se faisait...
Solution 3 : patch du fichier vyatta-interfaces.pl


Livebox
Détail : dans une configuration avec livebox, il faut réussir à la faire monter. Mais après la migration, il n'est plus question d'utiliser un serveur PPPoE.

Problème 1 : faire monter la livebox

Solution 1 : utiliser un serveur dhcp (avec les bonnes options) dans le scope du lan de la livebox pour la faire monter. Bridger (ou pas ?) les vlan entre la patte wan et la patte livebox.

Dans le topic Microtik, le téléphone monterait sur la livebox avec un bridge entre le vlan 851 wan et le vlan 851 livebox.

J'édite pour préciser l’ambiguïté.

Dans le topic Microtik, le téléphone monterait sur la livebox avec un bridge entre le vlan 851 wan et le vlan 851 livebox.

J'édite pour préciser l’ambiguïté.

Je pense que cela dépend des de la région, a savoir si la migration a été faite ou pas
Il me semble que avant en ipv4 j'étais en vlan 851
Maintenant je suis en ipv6 et ce soir j'ai pu faire fonctionner mon téléphone sur le vlan 832

Merci pour le retour, je vais maj le post récapitulatif.

Solution 3 : Patcher dhclient. J'ai compilé un dhclient qui fixe le skb_priority à 6 (SO_PRIORITY), et qui donc devrait être taggué en prio 6 en utilisant l'egress-qos idoine. Reste à tester, ce que je n'ai pas encore fait.

J'image que ça serait une solution pour le dhcp mais sans résoudre le problème pour les autres protocoles data en CoS 6.
Et sans parler des flux VoIP et TV.

On est vraiment pendu aux basques d'Ubiquity sur le coup...