[the lsd]

Lu all

J'ai un souci de DHCP.
[histoire]
J'ai Wireshark de lancé, je regarde tout ce qui passe, quand tout à coup, je vois des trucs bizarres. Des protocoles tordus (SSDP, Intel ANS Probe, que des trucs inutiles). Après avoir enquête sur ces drôles de bêtes, je me penche sur le reste des requêtes. C'est à ce moment précis que mon cœur s'est arrêté ! Incroyable, impossible ! Des requêtes DHCP ! Plein de requêtes DHCP, TROP de requêtes DHCP ! Oh mon dieu que se passe t'il ? Quel est cet étrange phénomène !?
Après mon enquête, et une résolution d'une partie du problème, je me résigne à venir demander un coup de main !
[/histoire]

Bon voila ce qui se passe, sous forme de schéma :

DHCPInform (des clients vers le serveur)
 DHCPAck (du serveur)
 DHCPAck (du serveur avec le Relay Adress rempli)

(3 secondes s'écoulent)

DHCPInform (des clients vers le serveur)
 DHCPAck (du serveur)
 DHCPAck (du serveur avec le Relay Adress rempli)
...
(entre 15 et 25 minutes s'écoulent)
...
DHCPInform (des clients vers le serveur)
 DHCPAck (du serveur)
 DHCPAck (du serveur avec le Relay Adress rempli)

(3 secondes s'écoulent)

DHCPInform (des clients vers le serveur)
 DHCPAck (du serveur)
 DHCPAck (du serveur avec le Relay Adress rempli)


Tous les DHCPInform sont identiques, les DHCPAck également, sauf le Relay Adress (et, btw, l'identifiant de transaction)
Les clients qui envoient le DHCPInform demandent toujours la même liste de paramètres (1, 3, 6, 15, 31, 33, 43, 44, 46, 47, 249, 252).
Le serveur (sous Windows 2003) répond ce qu'on lui dit de répondre c'est à dire actuellement le 6 et le 15.

Le double Ack vient d'une mauvaise mise en place/configuration d'un routeur, la solution à ce problème est trouvé, et je ne m'étend pas plus la dessus.

J'ai donc principalement trois interrogations sur le sujet :
 - pourquoi les clients envoient t'ils des DHCPInform toutes les 15/25 minutes ? (le temps est aléatoire entre ces deux bornes)
 - pourquoi les clients renvoient t'ils un deuxième DHCPInform 3 secondes après le premier, alors qu'il reçoit une réponse ?
 - pourquoi les clients envoient t'ils des DHCPInform alors qu'il reçoivent la configuration par DHCP ? (Or, le DHCPInform est utilisé lorsque le client à reçu sa configuration de manière externe)

J'ai bien sur cherché sur Internet, je pense avoir lu tous les sujets à ce propos, mais aucune réponse valide.

La seule solution que j'imagine est que le client attends en réponse tous les paramètres demandés, mais que le serveur n'en renvoie que deux, mais la rfc ne définit pas ça comme ça :

Si un client a obtenu une adresse réseau grâce à d'autres moyens (par ex. configuration manuelle) il peut utiliser une requête DHCPINFORM pour obtenir d'autres paramètres locaux de configuration. Les serveurs recevant un message DHCPINFORM construisent un message DHCPACK avec n'importe quels paramètres de configuration appropriés pour le client sans : allouer d'adresse, vérifier une liaison existante, remplir le 'yiaddr' ou inclure des durées de bail. Les serveurs DEVRAIENT faire une réponse adressée DHCPACK à l'adresse donnée dans le champs 'ciaddr' du message DHCPINFORM.

Le serveur DEVRAIT vérifier l'adresse réseau dans un message DHCPINFORM, mais il NE DOIT PAS vérifier l'existence d'un bail. Le serveur formule un message DHCPACK contenant les paramètres de configuration pour le client ayant émis la requête et envoie le message DHCPACK directement au client.

Le client envoie un message DHCPINFORM. Le client peut faire la requête de paramètres de configuration spécifiques en incluant l'option 'liste paramètres demandés'. Le client génère et enregistre un identifiant de transaction aléatoire et insère cet identifiant dans le 'xid'. Le client place sa propre adresse réseau dans le champ 'ciaddr'. Le client NE DOIT PAS faire de demande de durée du bail.

Le client adresse alors le message DHCPINFORM au serveur DHCP s'il connaît l'adresse serveur, autrement il diffuse le message aux adresses de diffusion. DHCPINFORM DOIT être dirigé vers le port UDP 'serveur DHCP'.

Une fois le message DHCPACK avec un champ 'xid' vérifiant que le message DHCPINFORM du client vient bien du serveur, le client est alors initialisé.

Si le client ne reçoit pas un DHCPACK dans un délai raisonnable (60 secondes ou 4 essais si on utilise la période définie dans la section 4.1), alors il DEVRAIT afficher un message informant l'utilisateur du problème, et DEVRAIT commencer un processus réseau en utilisant des valeurs par défaut correctes (Annexe A).

Vu que j'ai 80 méga de trames DHCP en 35 minutes à partir de mon poste, (on doit facilement avoisiner les 300 sur le backbone), il me serait utile de trouver une solution

Donc, pour conclure, est ce que quelqu'un dans cette assemblée a déjà vu ce problème, l'a résolu, ou bien sait comment le résoudre ?

Pour l'info :
rfc DHCP
Codes des options DHCP

Enjoy

The lsd