Bonjour,

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.

Sur le serveur :
$ tshark -i eth0 -w capture.pcap

Ou en live :
$ ssh user@server "tshark -i eth0 -w -" | wireshark -k -i -
(ne pas oublier de mettre sa clé ssh sur le serveur pour supprimer 
l'authentification sur le shell).

Dans tous les cas wireshark (sous-entendu la capture de trafic) est la façon la 
plus efficace de débugguer un problème réseau.

Cordialement
Emmanuel Thierry

> 
> 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/


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à