Bah, pas besoin justement c'est fait automatiquement, et c'est plus lisible qu'une chaine hexa.

Bonjour @tous,

Pour information:
Reboot quotidien effectué cette nuit avec succès (pas de parkage) en utilisant les 2 chaines suivantes:

Option 77 : 0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7837
Option 15 : 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7837

C’est quoi l’intérêt de rebooter tous les jours ?

Bonjour ZOC

a• J'utilise des Bridges Filters pour appliquer la COS6 sur les dhcp requests (v4 & v6) → je n'ai pas le choix, mon routeur Mikrotik Hex_s ne supporte pas les switchs rules.
b• A la fin du reboot && une fois les Bounds obtenus sur les 2 stacks (v4 & v6) → je désactive les Bridges Filters. Ceci pour m'affranchir de l'impact du Bridge !!
c• Avant d'initier le prochain reboot (1h:am) → je réactive les Bridge Filters afin de récupérer un nouveau bail de 7 jours à la fin du cycle/boot. Je réapplique alors le point b.

Tout ceci est déclenché par le scheduler qui fait appel à 2 petits scripts appelés "rebooting" et "postboot".
Je respeste bien les releases && les disable des 2 clients dhcp (v4 & v6) dans mon script rebooting.

De ce fait je n'ai plus d'impact sur le débit et performance lié au Bridge Filters.

Aussi via le script de (merci @dmfr) à chaque reboot je change le SALT des chaines 90 et 11.
Ce reboot (fait dans les règles) et en pleine nuit n'a aucune incidence sur mon usage personel.

Ps: Je n'utilise que le service 1P (internet only).

Ça a un gros impact les bridge filters ? Même si ceux-ci sont limités aux requêtes DHCP liées à Orange ?

Sinon, tu pourrais faire un script pour

• Release DHCP
• Activation des bridges filters
• Génération des nouvelles options 90 et 11
• Request DHCP
• Désactivation des bridge filters

Lancé périodiquement, ça évite le reboot et il pourrait même être associé à un contrôle de perte de connectivité type netwatch.

Bonjour Yeocti,

Effectivement je pourrais faire cela. Ce qui donnerait le même résultat (sans reboot).
J'y ai pensé également → ajouter un contrôle de perte de connectivité.
à suivre... et tout d'abord mettre en place le contrôle de perte de connectivité.

Pour répondre à ta question sur l'impact des "Bridge Filters":

Bridge Filters activé (mesures avec iPerftool):
[  5]   0.00-1.00   sec  36.2 MBytes   304 Mbits/sec
[  5]   1.00-2.00   sec  39.6 MBytes   332 Mbits/sec
[  5]   2.00-3.00   sec  39.7 MBytes   333 Mbits/sec

Bridge Filters désactivé (mesures avec iPerftool):
[  5]   1.00-2.00   sec  61.7 MBytes   518 Mbits/sec
[  5]   2.00-3.00   sec  61.7 MBytes   518 Mbits/sec
[  5]   3.00-4.00   sec  61.7 MBytes   518 Mbits/sec

Ps1: pour info j'ai une offre à 500 Mbits/sec symétrique
Ps2: on voit l'impact de du bridge...

Bonjour,

J'essaye de faire le point sur l'état de mon routeur (ER-6P) et de sa conf.
Je n'arrive pas à décoder le retour (optionv4 125 et optionv6 17)

Cela ne ressemble pas trop à ce qui est indiqué par @levieuxatorange.
Les deux retours ne sont pas tout à fait identique et c'est cela qui m'interpelle !

 en ipv4, option 125 :

option dhcp-client-identifier 1:a4:ce:xx:xx:xx:xx;
  option Vendor-Specific-Information 0:0:5:58:c:1:a:0:1:0:0:0:0:0:0:0:0; <--------------
  renew 2 2023/04/11 15:30:59;
  rebind 0 2023/04/16 06:38:27;
  expire 1 2023/04/17 16:14:27;
en ipv6, option 17 :

interface "eth1.832";
  ia-pd da:xx:xx:xx{
    starts 1681083538;
    renew 84672;
    rebind 483840;
    iaprefix 2a01:cb10:xxxx:xx00::/56 {
      starts 1681083538;
      preferred-life 604800;
      max-life 604800;
    }
  option dhcp6.vendor-specific-info 0:0:5:58:0:1:0:c:0:1:0:0:0:0:0:0:0:0; <-----------------
  option dhcp6.client-id 0:3:0:1:a4:xx:xx:xx:xx;
  option dhcp6.server-id 0:3:0:1:a4:7b:2c:4f:ca:1f;
  option dhcp6.domain-search "STR.access.orange-multimedia.net.";
  option dhcp6.auth xxxxx
  }
Tout fonctionne sans souci depuis plus d'un an, juste un changement du préfix IPv6 pat une belle nuit d'hiver.

Merci pour vos lumières 

@arnaudf

Merci pour ta réponse

Je pense donc que tout va bien, mais pas clair le truc.

Je n'ai plus qu'à regarder de près le exit-hooks, car je ne comprends pas d'où viennent les id de sous-réseau que récupèrent les interfaces LAN. Ca semble aléatoire !