Donc un pti coup de tcpdump redirigé vers un fichiers de chaque côté jusqu'à la prochaine occurrence, et ensuite, analyse avec un wireshark et la solution devrait être là. Tu as pensé à réduire le lease time afin de voir si le problème se produit plus souvent ?
Le 30 avr. 2014 à 11:11, Eugène Ngontang a écrit : > Bonjour à tous, > > > "Le serveur et le client sont sur le même subnet ? pas de soucis sur les > switchs intermédiaires quand le phénomène arrive ?" > Oui ils sont sur le même subet, et il n'y a pas de souci de switch > > > "Un truc stupide me vient à l'esprit. > > Tes extraits de logs ci-dessous indiquent que ton serveur dhcp possède > également un client dhcp (dhclient) et fait des requetes sur eth0 pour > obtenir lui-même une IP (?!?!) > > Peut être une piste a explorer de ce côté... Un serveur DHCP ne peut pas être > client DHCP (peut être network-manager qui te fout le bronx ?)" > Les logs que j'ai mis ici sont uniquement ceux des clients (un des > clients). Le serveur ne fait pas tourner de client dhcp, ce serait un peu > débile pour des système en production. Il n'y a pas non plus de network > manager > > Et l'option wireshark n'est pas envisageable, car ce sont des système distant > et je ne peux rien capturer depuis un wireshark installé sur mon dekstop. Un > tcpdump encore sur l'un des systèmes. > > Je penche plus sur l'option de GROS Jerome qui me vient en tête depuis, mais > j'attends la prochaine occurrence de la panne pour me le confirmer > > Merci. > > Eugène NG. > > > > Le 30 avril 2014 10:00, David Ponzone <david.ponz...@gmail.com> a écrit : > L'idéal serait de prendre une trace wireshark du côté d'un client et du côté > du serveur jusqu'à la prochaine occurrence du problème, puis de faire une > analyse comparative > des 2 traces afin de voir ce qu'il s'est passé (DISCOVER jamais envoyé, > DISCOVER envoyé mais pas reçu, DISCOVER reçu mais pas de réaction du serveur, > …). > > Le 30 avr. 2014 à 09:23, Eugène Ngontang a écrit : > > > 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. > > Eugène NG > > > > Le 30 avril 2014 09:22, Eugène Ngontang <sympav...@gmail.com> a écrit : > >> 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. > >> > >> Eugène NG > >> > >> -- > >> ngont...@epitech.net > >> sympav...@gmail.com > >> ------------------------------------------------------------ > >> Aux hommes il faut un chef, et au chef il faut des hommes! > >> L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge! > > > > > > > > -- > > ngont...@epitech.net > > sympav...@gmail.com > > ------------------------------------------------------------ > > Aux hommes il faut un chef, et au chef il faut des hommes! > > L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge! > > > > > > --------------------------- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > > > -- > ngont...@epitech.net > sympav...@gmail.com > ------------------------------------------------------------ > Aux hommes il faut un chef, et au chef il faut des hommes! > L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge! --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
