La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: renaud07 le 14 février 2019 à 14:21:58
-
Bonjour,
Je cherche à configurer un lease time différent selon le pool d’adresses mais sur le même sous réseau. Si lorsque je mets un lease time général ça fonctionne (mais pas sur toutes les machines bizarrement, notamment sur XP), on dirait que ce n'est pas le cas lorsque chaque pool a le sien puisque que je récupère un bail d'1h sur n'importe quel système, au lieu des 6h configurés.
Voici ce que j'ai essayé (sur isc-dhcp-server) :
subnet 192.168.1.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.2, 192.168.1.10;
option domain-name "lapalisse.lan";
class "vms" { match if substring (hardware,1,3) = 08:00:27; }
pool {
failover peer "lapalisse";
default-lease-time 21600;
max-lease-time 86400;
range 192.168.1.70 192.168.1.90;
allow members of "vms";
}
pool {
failover peer "lapalisse";
default-lease-time 86400;
max-lease-time 604800;
range 192.168.1.30 192.168.1.40;
deny members of "vms";
}
Merci
-
Bonjour,
Je me demande si ta "class" est bien déclarée, j'ai trouvé un exemple ici https://www.isc.org/wp-content/uploads/2017/08/dhcp41conf.html#CLIENT%20CLASSING section "CLIENT CLASSING"
class "ras-clients" {
match if substring (option dhcp-client-identifier, 1, 3) = "RAS";
}
C'est bête mais pour une histoire d'espace ou de guillemets ça peut ne pas marcher.
-
Merci pour ta réponse.
Je viens de tester, mais malheureusement si je rajoute des guillemets autour de l'adresse MAC, c'est encore pire. Malgré le allow/deny members, les machines virtuelles se retrouvent avec le pool d'adresse réservé aux machines invitées.
De plus j'ai remarqué un truc bizarre : la prise en compte du bail de 6h à l'air de fonctionner mais seulement quand le premier bail d'1h a expiré et que la machine doit renouveler son IP...
-
Et tu as vu qu'il y avait des espaces avant les chiffres 1 et 3 ?
-
Toujours pareil...
Je commence à croire que c'est un bug. Je vais lancer 3 VMs et voir le comportement pour être enfin fixé.
Pour le moment toutes ont reçues un bail d'1h.
-
les 3 ip recues ne sont pas dans les ranges de ta config... t'es certain que ton hyperviseur de vm (ou l'hote des vm) ne fait pas un truc au niveau dhcp ?
-
Oups, oui, j'ai oublié de précisé que j'avais changé entre temps le pool, je l'ai passé de .70 .90 à .40 .50 de ce côté là c'est ok.
Et comme je le pensais, au renouvellement suivant les 6h sont biens pris en compte (plus ou moins, en particulier seven qui reprend l'heure de début de premier bail ).
-
donc le renew est bon mais pas le bind initial ?
si tu release/renew a la main ca fait pareil ?
-
apres le mieux a ce niveau ca reste une capture pour voir vraiment ce qui se passe.
-
Exact, c'est toujours pareil.
Un release/renew redonne un bail d'une heure. Les captures n'en disent pas plus.
Pour résumer on a donc :
bind initial : 1h > renew parce qu'il arrive à expiration : 6h, release/renew : 1h.
-
Ça vient de me faire un truc bizarre, j'ai fait un renew simple au bout de 15 minutes environ après avoir fait le release/renew et là le DHCP m'a donné une bail de 6h... Je n'y comprends plus rien. Car avant ça il me redonnait le bail d'une heure amputé du nombre de minutes restantes.
Ou alors il ne faudrait pas que la config en master/slave (j'ai 2 DHCP/DNS sur le réseau) foute le bazar ?
-
oui ca ressemble au comportement quand y'a un failover (notion de MCLT entre 2 serveurs DHCP). Dans ce cas le premier lease est toujours différent et correspond au MCLT. Le 1er renew se fait a MCLT/2 donc 1/2 heure par défaut.
cf https://tools.ietf.org/html/draft-ietf-dhc-failover-12#section-5.2.1 (schema page 23 notamment)
-
ça dit quoi au niveau des logs de ton service dhcp ? et en particulier du moment où s'initialise le lease ?
-
Je pense avoir trouvé : J'ai désactivé le slave et j'ai mes 6h dans tous les cas ! Et si je le réactive c'est reparti avec un bail d'une heure... Y'a bien un problème.
Est-ce que ça serait par hasard du au fait que j'ai mis authoritative sur le slave aussi ? Dans les tutos c'était pas clair s'il fallait le mettre ou pas.
Pour les logs, je n'y avais pas prêté attention jusqu'à présent mais j'ai ça :
Mar 6 18:41:04 serveur dhcpd[7234]: failover peer lapalisse: I move from recover to recover-wait
Mar 6 18:41:55 serveur dhcpd[7234]: DHCPREQUEST for 192.168.1.48 from 08:00:27:a7:76:17 (XP1) via eth0: not responding (recover wait)
Mar 6 18:43:05 serveur dhcpd[7234]: DHCPDISCOVER from 08:00:27:a7:76:17 via eth0: not responding (recover wait)
Mar 6 18:43:06 serveur dhcpd[7234]: uid lease 192.168.1.49 for client 08:00:27:a7:76:17 is duplicate on 192.168.1.0/24
Mar 6 18:43:06 serveur dhcpd[7234]: DHCPREQUEST for 192.168.1.48 (192.168.1.10) from 08:00:27:a7:76:17 via eth0: not responding (recover wait)
Pourquoi not responding ? Pourtant ils ont bien l'air de dialoguer puisque j'ai vu aussi passer :
Mar 6 13:28:47 serveur dhcpd[1606]: Wrote 0 deleted host decls to leases file.
Mar 6 13:28:47 serveur dhcpd[1606]: Wrote 0 new dynamic host decls to leases file.
Mar 6 13:28:47 serveur dhcpd[1606]: Wrote 18 leases to leases file.
Mar 6 13:28:47 serveur dhcpd[1606]: failover peer lapalisse: I move from normal to startup
Mar 6 13:28:47 serveur dhcpd[1607]: Server starting service.
Mar 6 13:28:48 serveur dhcpd[1607]: failover peer lapalisse: peer moves from normal to communications-interrupted
Mar 6 13:28:48 serveur dhcpd[1607]: failover peer lapalisse: I move from startup to normal
Mar 6 13:28:48 serveur dhcpd[1607]: balancing pool 563b0fc77f00 192.168.1.0/24 total 11 free 6 backup 5 lts 0 max-own (+/-)1
Mar 6 13:28:48 serveur dhcpd[1607]: balanced pool 563b0fc77f00 192.168.1.0/24 total 11 free 6 backup 5 lts 0 max-misbal 2
Mar 6 13:28:48 serveur dhcpd[1607]: balancing pool 563b0fc78f30 192.168.1.0/24 total 10 free 5 backup 5 lts 0 max-own (+/-)1
Mar 6 13:28:48 serveur dhcpd[1607]: balanced pool 563b0fc78f30 192.168.1.0/24 total 10 free 5 backup 5 lts 0 max-misbal 2
Mar 6 13:28:48 serveur dhcpd[1607]: failover peer lapalisse: peer moves from communications-interrupted to normal
Mar 6 13:28:48 serveur dhcpd[1607]: failover peer lapalisse: Both servers normal
On dirait que ça déconne par moments...
-
Pour moi ton slave n'est pas authoritative, vu qu'il est slave...
-
Bon... ça n'a aucun effet, authoritative ou pas, j'ai toujours ce fameux not responding sur le master, et le slave distribue toujours un bail d'1h...
Mar 6 19:21:55 serveur dhcpd[7344]: DHCPREQUEST for 192.168.1.40 (192.168.1.10) from 08:00:27:c0:6f:ed via eth0: not responding (recover wait)
:-\
Je pense que je vais finir par les laisser autonomes avec un pool d'adresses séparées, ça sera moins prise de tête.
-
C'est confirmé : la config master/slave est bancale. Là j'ai fait l'inverse en coupant le master et désactiver sur le slave : il distribue enfin un bail de 6h après release/renew !
Je vais donc mettre de 192.168.1.40 à .50 sur un et 192.168.1.51 à .60 sur l'autre, et ce sera au premier qui répondra.
-
Je pense avoir trouvé : J'ai désactivé le slave et j'ai mes 6h dans tous les cas ! Et si je le réactive c'est reparti avec un bail d'une heure... Y'a bien un problème.
....
On dirait que ça déconne par moments...
y'a pas de souci c'est le fonctionnement logique. 1 heure c'est le MCLT par défaut.
https://kb.isc.org/docs/aa-00502
Tu te bas contre la norme du fail-over la ... ;)
-
Ah ok je ne savais pas que ça fonctionnait comme ça. Au passage isc.org ne répond pas (un dig ne retourne aucun ip), je l'ai remarqué à plusieurs reprises quand j'ai voulu consulter la doc dessus.
Du coup, je ne sais pas si c'est le fonctionnement qu'il me faut, car il peut arriver que le master ne soit pas allumé pendant plusieurs jours. Dans ce cas ça se passe comment ? Le slave se comporte comme le master au bout d'un moment ?
-
$ dig +short isc.org @8.8.8.8
149.20.64.69
:o
-
Les DNS de FDN ont du mal avec ce domaine visiblement...
renaud@renaud-pc:~$ dig @80.67.169.40 www.isc.org
; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @80.67.169.40 www.isc.org
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
renaud@renaud-pc:~$ dig @80.67.169.40 kb.isc.org
; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @80.67.169.40 kb.isc.org
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
-
Les DNS de FDN ont du mal avec ce domaine visiblement...
ceci explique cela.
-
Je suis passé sur les DNS d’orange temporairement, problème résolu.
Maintenant que j'ai accès à la doc officielle, tout devient clair. Le tuto que j'avais suivi n'expliquait pas cette notion de MCLT, et dans mon cas c'est bien configuré sur 3600, donc c'est bon.
-
Quelqu'un sait quel mail contacter pour un problème de DNS chez FDN quand on est pas adhérent ?
Je pensais que la panne était temporaire, mais ça fait plusieurs jours que le NDD de isc.org est "irésolvable" au moins depuis la semaine dernière, si c'est pas plus. Il me semble bien que lorsque j'avais commencé mes recherches sur la mise en place master/slave ça ne fonctionnait déjà pas.
-
Cela doit être du a l'attaque DDoS qu'ils ont reçu il y a quelques jours : https://twitter.com/assofdn?lang=fr
Voila l'état des services actuellement : https://isengard.fdn.fr/
Si tu veux les contacter : services@fdn.fr
-
Quand j'ai eu le soucis, je suis allé direct voir l'état des services et c'est là que j'ai vu l'attaque DDoS, pas cool...
Et merci pour l'email ;)
Vu qu'ils sont en train de bosser dessus, je vais donc attendre quelques jours. C'est pour ça que j'avais des coupures intermittentes en début de soirée, sur le coup je pensais que ma connexion avait sautée mais non.