BTS IG Informatique de Gestion

Résident du forum Sexe: Messages: 394 Localisation: 92

Bonjour,

J'essaie de boucler mes PTI et je me trouve un peu coincé sur le cas suivant :

Sous Virtual PC, j'ai trois machines :
- un serveur Win2003 configuré en serveur DHCP (étendue 10.0.0.10 à 10.0.0.20) possédant une IP fixe 192.168.0.253
- un serveur Win2003 configuré en routeur et relais DHCP possédant 2 interfaces : 192.168.0.250 et 10.0.0.250
- un client sous Win2000 configuré pour recevoir son @IP en DHCP.

... Et ça ne fonctionne pas Sad

L'analyse des trames montre que la requête DCHP Discover part du client et qu'elle est relayée pa le routeur, mais c'est tout. Le serveur DHCP ne répond pas.
Je n'arrive pas à déterminer si le problème vient de la configuration du routeur ou du serveur. Si vous avez une idée, je suis preneur Wink

Merci d'avance,

T.

Modérateur Sexe: Messages: 1298 Localisation: Toulouse

Tu as bien vérifié que ce n'était que le DHCP qui ne fonctionne pas, et pas aussi le routage entre les deux réseaux ? Tu as essayé de faire un ping et un traceroute ?

Résident du forum Sexe: Messages: 394 Localisation: 92

Les ping sur le même réseau fonctionnent, mais pas d'un réseau à l'autre (ex : ping 10.0.0.250 depuis le serveur 192.168.0.253 renvoie impossible de joindre l'hôte de destination)

Si je rajoute au serveur DHCP une étendue 192.168.0.80 à 192.168.0.90, le client reçoit une adresse sans problème. Ce qui me pousse à croire que le problème ne provient pas du serveur DHCP.

Voici par ailleurs la table de routage du routeur :

J'ai l'impression que le souci se situe au niveau du routeur.

Résident du forum Sexe: Messages: 250 Localisation: Paris

La table de routage a l'air correcte mais est-ce que tu as bien précisé 192.168.0.250 comme passerelle à ton serveur DHCP?

Résident du forum Sexe: Messages: 394 Localisation: 92

Oups, non, j'avais oublié. Bon, maintenant Wireshark (ex Ethereal) voit bien le dialogue Discover, Offer, Request, Ack (du serveur vers le relais, puis du relais vers le client) mais le client affiche "l'erreur suivant s'est produite lors du renouvellement de la carte Connexion au réseau local : problème réseau inattendu ou accès insuffisant". Confused

Bizarre, non ?

Résident du forum Sexe: Messages: 250 Localisation: Paris

tipitipi a écrit:

Oups, non, j'avais oublié. Bon, maintenant Wireshark (ex Ethereal) voit bien le dialogue Discover, Offer, Request, Ack (du serveur vers le relais, puis du relais vers le client) mais le client affiche "l'erreur suivant s'est produite lors du renouvellement de la carte Connexion au réseau local : problème réseau inattendu ou accès insuffisant". Confused

Bizarre, non ?

Sur ton client, en ligne de commande, essaie de faire un petit coup de "ipconfig /release" puis "ipconfig /renew" (c'est un peu long, c'est normal).

Résident du forum Sexe: Messages: 394 Localisation: 92

c'est ce que j'ai fait, et c'est à la suite du ipconfig /renew que j'ai ce message. C'est bien ce qui me perturbe Confused

car, comme je te disais, les trames passent bien.

Résident du forum Sexe: Messages: 394 Localisation: 92

Je viens de me rendre compte d'un truc bizarre : après le Ack entre le relais et le client (en théorie, c'est la dernière étape) une nouvelle trame Discover envoyée en broadcast par le client relance un processus (nouveau numéro de transaction).
Là où ça devient bizarre, c'est que cette trame est datée d'avant le Ack, bien qu'apparaissant après dans Wireshark.
Cf dans l'image jointe : les lignes 18 et 19 correspondent aux Ack serveur->relais puis relais->client. Suit la ligne 20 qui est antérieure dans le temps à la ligne18 et qui est un Discover en broadcast du client.
Le phénomène se reproduit sans arrêt (cf lignes 28 à 30)

Résident du forum Sexe: Messages: 250 Localisation: Paris

Je ne suis pas un spécialiste international de la lecture de trames mais moi c'est plutôt les DHCP NAK qui me semblent bizarres...

Résident du forum Sexe: Messages: 394 Localisation: 92

Oui, je les ai regardé dans le détail. Il s'agit d'un refus du serveur envoyé en broadcast, mais l'adresse Mac du destinataire est celle du client. Le problème est qu'il n'y a pas de motif du refus...