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/
