La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: MacMan le 08 juin 2024 à 11:10:07
-
Bonjour,
Je ne parviens pas à obtenir le renew du bail dhcp-client en IPv4 comme prévu par Orange, c'est à dire toutes les 84672 secondes, 23h 31min 12 sec, (toutes les 24 heures avec un petit décalage à chaque fois).
Ca fonctionne sans souci en IPv6, mais en IPv4 le renew se fait à la moitié du bail, 7 jours /2 (RFC...).
On dirait que RouterOS ignore l'option 58, Renewal Time Value
Juste une question : avez-vous sur votre installation ce renew fixé par Orange à 23 heures et quelques ou le renew fixé par le RFC à 3,5 jours ?
Merci d'avance
Cordialement
-
J'avoue ne jamais avoir regardé puisque je n'ai aucun problème visible en IPv4.
Mon bail courant expire dans 6j et 4h, donc en théorie il devrait être renouvelé d'ici la fin de la journée. Je reviendrai poster ici ce soir.
Mon setup si ça peut servir: CCR2004 + CRS305 en frontend (pour appliquer les prio avec les switch rules).
-
Bonjour @zoc,
Merci de ta réponse.
En effet, je pense qu'on ne voit pas ce problème facilement, puisque sans douleur.
Le bail se "renew" juste plus tard.
Ce que je ne comprends pas, c'est qu'en IPv6 ça tourne comme une horloge.
Si tu regardes par la fenetre DHCP-Client (v4), tu vois effectivement Expires after "6d xx:xx:xx.
Le renew devait se produire à exactement 6d 00:28:48 (7d 00:00:00 - 23:31:12) (23:31:12 c'est la valeur de l'option 58 "renewal time" envoyée par Orange)
Je suis vraiment curieux de savoir si ça fait la même chose chez toi. Je cherche depuis plusieurs semaines...
Je crains que ce soit un bug de RouterOS ou une fonctionnalité non implémentée.
J'ai fait le tour du forum Mikrotik, aucun post sur ce problème.
Ici, c'est un CCR2004 aussi, avec un CRS309, mais derrière. Donc c'est le CCR2004 qui fait tout le boulot..
-
Le renew devait se produire à exactement 6d 00:28:48 (7d 00:00:00 - 23:31:12) (23:31:12 c'est la valeur de l'option 58 "renewal time" envoyée par Orange)
Ok, donc 6d 00:11:35 à l'instant, donc pas de renew.
-
Merci de l'info !
Mais bon, j'ai fait un renew manuel et là, surprise, le renewal time (T1) est passé maintenant à 88399 secondes au lieu des 84672 sec....
Alors, je ne suis pas sur que tu aies la même valeur que moi.
Une énigme de plus.
Ne fais pas tout de suite de renew et regarde si il se fait !
[edit] : je ne sais pas à quoi correspondent ces valeurs, elles sont peut-être aléatoires dans une certaine fourchette autour de 24h
-
5d 21:40:30
-
merci pour le décompte !
Je ne connais pas la valeur du renewal time de ton coté, mais je pense que ça doit tourner autour de 24h (renew journalier)
Là je pense que c'est parti pour le renew au 1/2 bail (conformément au RFC je sais plus combien..), soit environ 3d 12:00:00 pour le décompte.
Ceci montrerait que RouterOS ne gère pas effectivement ce renewal time (T1), c'est ce que je suspecte ... en IPv4 du moins ...
Si ça se confirme, je vais m'adresser au bureau des réclamation MikroTik >:(
En tout cas @zoc, merci pour ton aide !
-
Encore un autre élément mikrotruk qui fonctionne à moitié :p
Edit: J'en ai profiter pour regarder mes log debian.
2024-05-16T13:30:29.132698+02:00 xxxxxxxx dhclient[1042]: DHCPREQUEST for xx.xx.xx.xx on vlan832 to xx.xx.xx.xx port 67
2024-05-16T13:30:29.412982+02:00 xxxxxxxx dhclient[1042]: DHCPACK of xx.xx.xx.xx from xx.xx.xx.xx
2024-05-16T13:30:29.458829+02:00 xxxxxxxx dhclient[1042]: bound to xx.xx.xx.xx -- renewal in 75311 seconds.
75311 sec => 20h 55min 11sec
Et exactement 20h 55min 11sec plus tard (à la seconde près)
2024-05-17T10:25:40.716893+02:00 xxxxxxxx dhclient[1042]: DHCPREQUEST for xx.xx.xx.xx on vlan832 to xx.xx.xx.xx port 67
2024-05-17T10:25:41.082628+02:00 xxxxxxxx dhclient[1042]: DHCPACK of xx.xx.xx.xx from xx.xx.xx.xx
2024-05-17T10:25:41.127165+02:00 xxxxxxxx dhclient[1042]: bound to xx.xx.xx.xx -- renewal in 81767 seconds.
Uptime ~2mois, pas de déco
-
Merci @Mastah pour la copie des log.
La valeur du renewal time semble effectivement assez volatile. (bon, pas grave)
En fouinant sur différents forums, j'ai vu que Mikrotik n'est pas le seul impacté : https://forum.opnsense.org/index.php?topic=33376.0
Il semblerait que ce soit un problème de priorité (cos 6) qui ne serait pas envoyée au bon moment et qui affecterait le dhcp-client (d'après ce que j'ai pu comprendre...)
Je continue de chercher, mais je me demande si le jeu en vaut la chandelle car le debug est très compliqué vu les délais de plusieurs dizaines d'heures (voire jours) à attendre...
-
Ca m'étonnerait que ce soit le même problème, surtout chez moi où c'est un équipement à part (le CRS305) qui tag la priorité sur TOUS les paquets DHCP...
-
Bonjour @zoc,
je ne sais pas, mais il y a beaucoup de similitudes, comme par exemple la dualité des deux leases (que je retrouve ici)
Sinon, je suis en train de m'énerver car je ne peux pas entrer cette ligne :
add action=set-priority chain=output dst-port=547 ip-protocol=udp \
mac-protocol=ipv6 new-priority=6 out-interface=vlan832-internet \
passthrough=yes
enfin si, en réalité je peux l'entrer (en SSH), elle est ajoutée sans souci, mais comme le log n'est pas activé, je l'active dans winbox et patatra ça supprime le dst-port et bien sur le filtre est appliqué à toutes les requetes IPv6 ... je commence à avoir du mal à comprendre ce qui se passe dans ce routeur !
Je me demandais pourquoi sur le log je voyais autant de déclenchements de ce filtre...
Mais bon, ça n'a rien à voir avec le DHCP-client IPv4
Tu en es où du compteur "expires after" ? le "renew" ne s'est pas fait après environ une heure donc ?
ici encore 2 heures à attendre
-
Une solution radicale (en attendant mieux) :
-
Tu en es où du compteur "expires after" ? le "renew" ne s'est pas fait après environ une heure donc ?
J'étais vers les 5j avant renew, puis j'ai (finalement) installé la 7.15 du coup je suis reparti pour 7 jours ;)
-
Merci pour ton retour !
Si je comprends bien, le renew IPv4 journalier ne fonctionne pas non plus ?
Le renew ipv6 journalier fonctionne lui ?
-
J'avais écrit 5h au lieu de 5j (corrigé), désolé...
Pour IPv6 je n'ai pas regardé vu que tu as dit que c'était bon.
Et en fait, comme ça ne pose aucun problème, je vais m'arrêter là.
-
@zoc
De mon coté j'ai sniffé tout à l'heure au moment du renew journalier à la sortie du routeur, il n'y a strictement rien.
Je referai la même chose au moment dur 1/2 bail.
De toute façon, je pense que tout le monde avec un RouterOS est dans le même cas :
-soit parce que le routeur ne traite pas le renewal time
-soit l'utilisation de cette valeur n'est pas conventionnelle chez Orange.
un de ces jour, je remettrai en service mon ER6, pour voir .... Ce qui me gêne beaucoup avec RouterOS, c'est le manque d'accès au systeme par ssh.
Merci de ton coup de main !
-
-soit l'utilisation de cette valeur n'est pas conventionnelle chez Orange.
Bonjour
C'est parfaitement dans la norme et c'est géré correctement par plusieurs stack DHCP coté client, tous les équipements intermédiaires du réseau qui font du L2/L3 DHCP Relay aussi.
C'est pas conventionnel dans le sens que ce n'est pas simplement 50% du LeaseTime, mais il y a plein de configuration comme cela.
Et un client DHCP SHALL (dans la RFC :)) respecter le T1 envoyé par le serveur DHCP si la valeur est dans la plage permise par la RFC (ce qui est le cas)
=> à regarder dans cet équipement là ... Bon courage ..
LeVieux
-
-soit parce que le routeur ne traite pas le renewal time
-soit l'utilisation de cette valeur n'est pas conventionnelle chez Orange.
Juste que mikrotruk c'est un poil "meh :o"
-
@LeVieux
Merci pour les précisions qui confirment ce que je suspectais : le Mikrotik ne tient pas compte du T1, du moins en IPv4, car en IPv6 ça fonctionne parfaitement.
La question que je me pose aussi (pas très important) pourquoi le T1 varie ? la valeur stable semble être 84762.
Ce que je trouve bizarre c'est qu'il n'y ait aucune trace de ce souci dans les forums.
@Mastah : oui, comme tu dis ! pas trop sérieux quand même, sans compter tous les bugs et plantages...
L'autre grosse déception : aucun accès root ; sans sniffer ce qui rentre pendant un renew, impossible de connaître la valeur de T1.
-
sans sniffer ce qui rentre pendant un renew, impossible de connaître la valeur de T1.
D'ailleurs, pour ça, on peut envoyer le traffic souhaité vers un wireshark remote avec une règle de la table mangle (action sniff-tzsp).
Disclaimer: C'est ce que la doc dit, j'ai jamais testé ;)
-
Bonjour @zoc,
oui, on peut faire plein de trucs ... je regrette tellement ce manque d'accès de RouterOS.
Sur le Edgerouter, on trouvait tout ce qu'on voulait en SSH...
Hier le CCR a planté complètement ... et je ne sais pas où je peux trouver la cause, car tous les logs disparaissent.
-
Moi je loggue sur un système distant (graylog).
-
@LeVieux
La question que je me pose aussi (pas très important) pourquoi le T1 varie ? la valeur stable semble être 84762.
Clairement de mon coté j'ai plein de valeurs variables.
2024-06-02T09:10:04.230109+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 73570 seconds.
2024-06-03T05:36:14.556590+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 64984 seconds.
2024-06-03T23:39:18.418916+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 67368 seconds.
2024-06-04T18:22:07.041509+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 66033 seconds.
2024-06-05T12:42:40.228151+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 77381 seconds.
2024-06-06T10:12:22.167715+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 76342 seconds.
2024-06-07T07:24:45.393070+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 84497 seconds.
2024-06-08T06:53:02.788872+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 69730 seconds.
-
Bon j'ai trouvé ça: https://forum.mikrotik.com/viewtopic.php?t=95194
Le post date de 2015 ::)
Bon après, le forum n'est sans doute pas le meilleur moyen de remonter des problèmes au support technique.
-
Et un client DHCP SHALL (dans la RFC :)) respecter le T1 envoyé par le serveur DHCP si la valeur est dans la plage permise par la RFC (ce qui est le cas)
Alors ça, je ne l'ai pas trouvé explicitement écrit dans la RFC-2131 (j'ai pu passer à coté mais j'ai cherché toutes les occurrences de T1). La RFC dit:
- La valeur par défaut de T1 est 50% du lease
- Le serveur dhcp DEVRAIT envoyer T1 et T2 (pas obligatoire donc mais recommandé)
- Le client dhcp PEUT passer en RENEW state AVANT T1 (ça ne nous concerne pas ici)
Bref, aucune ligne ne dit que le client DHCP doit respecter le T1 envoyé par les serveur au lieu d'utiliser la valeur par défaut, même si effectivement, le bon sens voudrait que ca soit le cas vu le deuxième point dans la liste.
Accessoirement il n'y a pas de SHALL dans cette RFC... Mais MUST/NOT, SHOULD/NOT et MAY.
-
- La valeur par défaut de T1 est 50% du lease
- Le serveur dhcp DEVRAIT envoyer T1 et T2 (pas obligatoire donc mais recommandé)
- Le client dhcp PEUT passer en RENEW state AVANT T1 (ça ne nous concerne pas ici)
Bref, aucune ligne ne dit que le client DHCP doit respecter le T1 envoyé par les serveur au lieu d'utiliser la valeur par défaut, même si effectivement, le bon sens voudrait que ca soit le cas vu le deuxième point dans la liste.
Tout à fait d'accord avec ça.
L'origine de ce fil c'est tout de même comme marqué dans le titre "souci RouteurOS dhcp-client ..."
Comme tu le dis ce serait mieux si RouterOS tenait compte de T1, c'est le cas en IPv6 (rien à redire) mais pas le cas en IPv4 et j'ignore les conséquences que cela peut avoir.
J'ignore aussi le comportement de la Livebox dur ce point ; pourquoi pas (ce qui n'est pas le cas actuellement) pas de renew à T1 10 foid de suite, donc pas livebox, hop on coupe ...
@LeVieux ... c'est dit sans animosité de ma part ;), puisque ce n'est pas le cas et que le souci vient vraiment de RouterOS
Ca m'énerve d'avoir mis si cher dans un routeur qui a tant de souci...
-
Clairement de mon coté j'ai plein de valeurs variables.
2024-06-02T09:10:04.230109+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 73570 seconds.
2024-06-03T05:36:14.556590+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 64984 seconds.
2024-06-03T23:39:18.418916+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 67368 seconds.
2024-06-04T18:22:07.041509+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 66033 seconds.
2024-06-05T12:42:40.228151+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 77381 seconds.
2024-06-06T10:12:22.167715+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 76342 seconds.
2024-06-07T07:24:45.393070+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 84497 seconds.
2024-06-08T06:53:02.788872+02:00 xxxxxxxxx dhclient[1327]: bound to xx.xx.xx.xx -- renewal in 69730 seconds.
Merci pour ces valeurs ! Avec ton T1 le plus faible (64984) ça fait quand même 5h30 de moins par rapport à 84672 (environ)
-
Mon avis ? Ils font un random pour éviter que l'ensemble des box entre en résonnance sur les dhcp req après un incident OLT.
-
Un T1 et T2 qui varient est spécifiquement recommandé par la RFC justement pour éviter ce genre de problème.
-
Ca je peux comprendre !
seulement le T1 récupéré par mon routeur est stable à 84672 s. De temps à autre il se met à fluctuer.
je verrai cet aprèm la nouvelle valeur.
-
De mon coté, toujours cette valeur stable T1 à 84672
... et pas de renew à T1 pour le dhcp-client IPv4
Testé entre temps sur mon Edgerouter ER6 (avec cette même valeur 84672) : aucun souci ...
-
Bonjour,
Enfin, l'option 58 est prise en compte dans la 7.17rc1.
Installée depuis quelques jours le Renewal Time du dhcp-client 4 fonctionne sans souci !