Le 30 avr. 2014 à 11:28, Emmanuel Thierry a écrit : > 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).
Erratum : $ ssh user@server "tshark -i eth0 -w - \"not port 22\"" | wireshark -k -i - ;) > > 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 <[email protected]> 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 <[email protected]> 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 >>>>> >>>>> -- >>>>> [email protected] >>>>> [email protected] >>>>> ------------------------------------------------------------ >>>>> 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! >>>> >>>> >>>> >>>> -- >>>> [email protected] >>>> [email protected] >>>> ------------------------------------------------------------ >>>> 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/ >>> >> >> >> >> -- >> [email protected] >> [email protected] >> ------------------------------------------------------------ >> *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/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
