Discussion :

[nixmind]

Bonjour,

J'ai un problème dont je n'arrive pas à identifier concrèetement la source.

En effet j'ai un serveur DHCP configuré pour attribuer des adresses statiques et dynamiques.

Au moins une fois par jour que tous les clients perdent leur configuration ip alors que le service dhcpd tourne bien sur le serveur.

Après mes vérifications, je constate que le client ne reçoit simplement plus d'offre dchp du serveur après un DISCOVER broadcasté. et j'ai des messages du style :

No DHCPOFFERS received.

dans les log des clients.

Et le redémarrage du service (qui n'était pas arrêté), permet de résoudre le problème et on peut voir dans les logs des clients un

No DHCPOFFER from X.X.X.X

(X.X.X.X) est l'adresse du serveur dhcp. Puis l'incident se reproduit (je pense après l'expiration du bye), et c'est ainsi tout le temps.

Du côté serveur je ne vois rien de particulier dans les log pouvant m'édifier sur la source du problème, je ne vois aucune trace de ...NACK....

Je ne veux pas augmenter la durée du bail au maximum côté serveur, car je veux déjà comprendre ce qui a pu arriver subitement à ce dernier qui fonctionnait pourtant très bien avant.

J'ai essayé de voir si le fichier /var/lib/dhcpd/dhcpd.leases est plein, mais là aussi tout me semble normal (peut être je ne sais pas checker ce qu'il faut)

Sur la toile je ne vois pas de post qui puisse m'aider sur ma problématique.

J'aimerais dont savoir si quelqu'un ici saurait d'où peut provenir le dysfonctionnement, afin que je puisse corriger définitivement.

Merci beaucoup à vous.

[nixmind]

Bonjour,

Dans la poursuite de mon analyse, je m'aperçois d'une chose :

Ce matin en arrivant encore mes systèmes client (au sens dhcp) étaient tous dans les chous, et je n'ai pas eu le teAmps de faire les tests que j'envisageais, que mon collègue avait naïvement redémarré le serveur.

Toutefois j'ai regardé côté client dans les messages d'avant le redémarrage du serveur (à 7h43 heure système locale) , et j'ai ceci (un extrait):

Apr 30 03:04:47 00-01-80-7e-38-fd dhclient[653]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 (xid=0x1e903fe)
Apr 30 03:04:53 00-01-80-7e-38-fd dhclient[653]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 (xid=0x1e903fe)
Apr 30 03:05:01 00-01-80-7e-38-fd dhclient[653]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10 (xid=0x1e903fe)
Apr 30 03:05:11 00-01-80-7e-38-fd dhclient[653]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16 (xid=0x1e903fe)
Apr 30 03:05:27 00-01-80-7e-38-fd dhclient[653]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18 (xid=0x1e903fe)
Apr 30 03:05:45 00-01-80-7e-38-fd dhclient[653]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x1e903fe)
Apr 30 03:05:48 00-01-80-7e-38-fd dhclient[653]: No DHCPOFFERS received.
Apr 30 03:05:48 00-01-80-7e-38-fd dhclient[653]: No working leases in persistent database - sleeping.

Et côté serveur (dans /var/log/dhcpd.log), je ne vois aucun DISCOVER reçu dans la plage horaire de 2h47 où l'incident est suvenu à 7h43 où le serveur a été redémarré.

Par ailleurs je vois bien qu'il a reçu un DISCOVER à 7H43 (heure de redémarrage) et a bien envoyé un OFFER au client.

J'en déduis pour l'instant qu'à une certaine période (apparemment sur un intervalle de 24h environ), le service dhcpd tourne bien sur le serveur, mais celui-ci n'écoute plus sur le port 67 ou ne reçois plus de paquet DISCOVER. Puisqu'à chaque fois aucune action n'est faite côté client pour résoudre le problème, mais un simple redémarrage du serveur.

Je ne suis pas sur le même LAN que les systèmes impliqués dans cet incident (clients comme serveurs), j'y accède via ssh. J'attends la prochaine occurrence de la panne pour faire moi même des requêtes DHCP depuis un client et voir ce qu'il se passe.

En attendant si quelqu'un à une piste je suis preneur.

Merci

[Invité]

Salut,

le mieux serait de prendre une trace simultanément sur le serveur et le client dhcp.

Steph

[nixmind]

Bonjour

L'incident est de nouveau survenu ce weekend.

Mon fichier dhpcd.leases n'est pas plein, et je ne vois pas comment et pourquoi le vider, car pour le coup par exemple, le serveur est à nouveau tombé (a cessé d'attribuer des ip/bauds) le 02 mais à 12h51, le fichier dhcpd.leases a été modifié la dernière fois ce même jour à la même heure. et ne contient que quatre bauds (blocks lease).

J'ai regardé et le process tournais (comme d'habitude), et j'ai capturé des packets qui me disent que les clients envoient bien des requête, que le serveur reçoit bien également, mais ce dernier ne répond pas. Un extrait de la capture, tout le reste est pareil, à la différence de l'adresse MAC du réquêteur.

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
2014-05-04 12:56:07.419712 00:01:80:7d:db:14 > Broadcast, ethertype IPv4 (0x0800), length 346: (tos 0x0, ttl 128, id 0, offse
t 0, flags [none], proto: UDP (17), length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request fr
om 00:01:80:7d:db:14, length: 300, xid:0xc768345, secs:3, flags: [none] (0x0000)
Client Ethernet Address: 00:01:80:7d:db:14
Vendor-rfc1048:
DHCPISCOVER
RQ:X.X.X.X
HN:"XXXXXXXXX"
PR:SM+BR+TZ+T121+DN+NS+HN+YD+YS+NTP+MTU+T119+DG
0x0000: 4500 0148 0000 0000 8011 39a6 0000 0000
0x0010: ffff ffff 0044 0043 0134 f634 0101 0600
0x0020: 0c76 8345 0003 0000 0000 0000 0000 0000
0x0030: 0000 0000 0000 0000 0001 807d db14 0000
0x0040: 0000 0000 0000 0000 0000 0000 0000 0000
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000
0x0100: 0000 0000 0000 0000 6382 5363 3501 0132
0x0110: 04xx xxxx xx0c 0c46 522d 4c59 532d 4c58
0x0120: 3030 3437 0d01 1c02 790f 060c 2829 2a1a
0x0130: 7703 ff00 0000 0000 0000 0000 0000 0000
0x0140: 0000 0000 0000 0000 9c57 4f09

Je ne pense pas que ça puisse être un épuisement d'ip, car les ip sont attribuées en DHCP statique, c'est à dire c'est la même Ip qui est attribuée au client à chaque fois que le serveur répond à sa requête.

J'ai essayé de rentrer dans le binaire pour débugger, mais je n'ai pas pu le faire à cet instant sur ce système.

J'ai poursuivi mon analyse.

- Dans les logs j'ai également des messages du type : ip length 328 disagrees with bytes received 332, qui peuvent plus être lié à la carte réseau physique de la machine
- Dans les message "dmesg", je constate que l'interface sur laquelle les requête DHCP sont envoyées passe régulièrement en mode promiscuous :
[1046032.037550] device eth0 entered promiscuous mode
[1046210.492175] device eth0 left promiscuous mode
- Il y a également des erreurs de mapping DNS dans les logs, et le serveur ne fait serveur DNS, il interroge un serveur de l'infra pour la résolution des noms : Apr 19 01:41:16 SERVER_HOSTNAME dhcpd: Unable to add forward map from xxxxxxxxxxxx.org to x.x.x.x : DNS format error

Voilà un peu plus sur la situation, j'essaye de corréler toutes ces choses, mais j'arrive pas à établir le lien, là je veux surtout comprendre le comportement du démon DHCPD lorsqu'il frise, car un simple redémarrage du serveur règle le souci. Du coup pour éviter des alertes escaladées, car l'incident survient de façon aléatoire, j'ai mis en place une crontab pour le redémarrage régulier du service, mais je reste sur ma faim.


Merci.