Salut,
 
pour faire suite à un autre post, je suis e ntrain de remplacer nos switchs ( projet de refonte cablage complète et éléments actifs).
 
Je monte, en parallèle du réseau existant de nouveaux cabinets de cablages. A terme, nous aurons 3 stacks de 5 switchs dans chacun des cabinets. Cisco 2960X, en 48 ports. Aujourd'hui seul les switchs de têtes sont montés.
 
Ceux ci sont reliés via des rocades optiques monomodes au nouveaux coeurs de réseaux ( 3850).
 
Chacun des ports switchs sont sur un vlan différent. deux  serveur DHCP ( sous windows 2008 R2) ont été mis en place.  Quand je branche un PC portable ( configuré en DHCP ) sur le switch 1, j'obtiens une adresse IP correspondant à ce VLAN. ça fonctionne.
 
Quand je prend le même portable et que je le branche sur le switch 2 ( ou 3 idem), je fais un ipconfig / release, j'ai ce message d'erreur :
 

 
Si je fais un ipconfig je vois toujours l'Ip attribuée lors de la première connexion sur le switch 1.
 
Si je rentre en dur une IP fixe correspondant au VLAN du switch sur lequel je suis branché, ça fonctionne.  
 
Le VLAN du serveur DHCP est un VLAN "serveur" véhiculé par tout les liens erherchannel.  
 
Après, je ne vois pas de relay DHCP  ip helper address configuré sur les switch de distribution ( je n'ai pas configuré les dit switchs, mais j'ai regardé la conf). Sur le coeur de réseau, je n'ai pas eu le temps de regarder...
 
Mais bon, ça fonctionne pour un poste en DHCP n'ayant pas encore une attribution d'adresse ip, ça foire après, si changement de sous réseaux et donc d'IP. ( Lors de la première connexion, on voit bien le pc en question dans le pool d'adresse du DHCP)
 
j'ai testé avec 2 ordinateurs différents mais le résultat est le même, ce message d'erreur en faisant un ipconfig / release ( un poste client en seven un autre en windows 10).

bonsoir,
 
essaie de faire le DHCP release AVANT de débrancher du 1er switch.

Loopback on s'en fou

 
Bonsoir.
 
C'est vrai que je l'ai fait après, je testerai avant,  demain.
 
Ceci dit, nos postes clients sont pour la plupart dans des bureaux, donc, ils ne bougeront pas et seront toujours sur les mêmes switchs. Mais on a des PC portable qui bougent ( salles réunions etc...). On a aussi svt des réorg ( services qui déménagent, changent d'étages), donc dans ces cas, la question se posera.

ça te permettra de savoir si le soucis est niveau serveur ou client déjà

Mon avis est que le problème est lié au poste de travail

 
Tu as peut être pas tord...Mes test initiaux ont été fait avec des portables ( HP),  de différents modèles...
 
J'ai basculé un bureau sur le nouveau réseau...PC fixes, j'ai toujours ce message d'erreur loopback lors d'un ipconfig /release ( fait avant de migrer le poste) , mais au final, le DHCP attribue bien une ip du bon vlan ensuite.

J'ai l'impression que personne lit mon message....

si....
mais....
 

donc il avait bien un soucis d'attribution d'adresse, le message sur le loopback cachant le reste

 
 
Bonjour, Si si mais si tu pouvais être plus explicite que "le loopback, on s'en fout"?  Car si ce message apparait avec une adresse de test, c'est qu'il doit y avoir un problème  quelque part...
 
Je ne suis pas un spécialiste du dhcp ( on était en IP fixe avant), mais j'ai pas souvenir de ce type d'erreur sur d'autres réseaux en dhcp...

 
 
 
Oui, j'ai l'impression qu'il y a plusieurs problèmes en fait...

J'ai refait des test cet après midi avec un collègue qui a monté le serveur dhcp ( sous windows), il a crée plusieurs étendues avec des plages Ip correspondant à chacun des vlan.  
 
Le pc client envoie une requête DHCP au serveur DHCP au serveur...OUi mais comment il sait quel Ip attribué ( de quel étendue?).
 
Sur une prise brassé sur la vlan 10 par exemple, lors de la requête dhcp, il va m'attribuer une ip, non pas du bon vlan mais de la première étendue configuré sur le DHCP. Pour tester, on a désactivé l'étendue 1 sur le DHCP, sur le poste client, après un ip release puis ipconfig /renew, il m'a attribué une IP de la deuxième étendue. On a désactivé l'étendue 2, il m'attribue une ip de l'étendue 3 etc...
 
J'ai regardé le coeur de réseau, pas de dhcp relay configuré, mais d'un autre côté il y a de l'etherchannel et le VLAN serveur communique avec tout les autres VLANS, donc logiquement pas besoin de dhcp relay (?). D'ailleurs, lors de mes requêtes, il m'atrtribue bien une IP donc il communique, mais pas l'ip de la bonne étendue....
 
Comment on configure cela? Côté switch ou côté serveur? Les deux?  
 
comment un serveur peut savoir quel ip attribué selon quel vlan? Les requêtes sont taggés sur le switch core L3 et il sait qui veut quoi?  
 
 
 

Bienheureux que si il faut un dhcp relay. Comment le serveur dhcp sait sinon d'où vient la requête ?
Par contre ce qui est bizarre c'est qu'il reçoive une ip actuellement vu que le dhcp est du broadcast ça sort pas du vlan même si tu as tt ouvert

 
 
Salut,
 
pour répondre à ta question, dans le cadre de ton test, il ne sait pas sur quelle étendue il doit distribuer, du faite que le serveur et la machine sont sur le même segment de broadcast.
 
 
 
Lorsque ton serveur reçoit la demande, il va commencer par te distribuer les adresses dans l'ordre de ses étendues.
 
Une fois qu'il n'y a plus d'adresse ip distribuable de dispo dans la première étendue, il passera à la second étendue, etc...
 
 
Se sont pour ces raisons que lorsque du désactive une étendue il passe à la suivante.
 
 
Si tu as plusieurs VLAN, il te faudra isoler ton serveur dhcp et passer par un relais dhcp. C'est le relais qui lui indiquera sur quelle étendue il doit distribuer.
 
 
Les relais sont généralement paramétrés sur les routeur(s).

Salut,

ok, je vais faire ça. Par contre le DHCP relays, je le configure ou? sur chacune des interface vlan du switchs coeur de réseau?

Côté coeur de réseau, si je fais un :

Côté un des switch de distribution :

J'ajoute ip-helper address sur les interfaces vlan?

#conf t
#int vlan 130 ( par exemple)
#ip-helper adddress IP_DU_DHCP1
#ip-helper adddress IP_DU_DHCP2 ( j'ai 2 serveurs DHCP)?
#no shut

?

Je viens de faire le test, ça fonctionne pas, il m'atribue toujours une ip de la première étendue du dhcp disponible ( on a crée une étendue DHCP par VLAN sur le serveur DHCP).
 
Donc si je suis le switch 1 ( sur un port appartenant au VLAN 110), il m'atribue une adresse IP 10.30.110.0 ok....
Je fait un ipconfig /release, je me branche en direct sur le switch 2 ( ports sur le VLAN 120)...Après un ipconfig /renew, il m'attribue une IP, toujours en 10.30.110.0 et pas en 10.30.120.0...
 

1 dhcp relay par vlan

 
 
C'est ce que j'ai fait.

J'apporte une précision, j'ai ajouté le relay dhcp sur le nouveau coeur de réseau ( sur les interface vlan), ça ne marche pas mieux.
 
Mais je viens de voir que l'ancien coeur réseau ( enfin, celui en prod actuellement, il s'agit d'une opération d'extension du coeur réseau, le DHCP relay était bien configuré, sur tout les vlan.  
 
Le switch coeur réseau prod est serveur VTP. Le nouveau est client, sur le même domaine évidemment. Les 2 cœurs réseaux sont liés via 2 ports fibres, en trunk.

Vire le VTP (mais ca n'a rien avoir avec tes "problèmes" de DHCP)

 
 
Je peux pas, c'est les précos de la boite, je ne décide pas. C'est quoi le souci avec VTP?
 
Mon collègue penche plus pour un pb de serveur DHCP.  Il avait passé un script créant des stratégies sur chacune des étendues, lesquelles font du filtrage mac. En désactivant les dites stratégies sur chaque étendue, pas de mieux.
 
Mais il m'a dit avoir testé une fois avant l'envoie du script et que le DHCP avait fonctionné, avec les bonnes étendues. Il va donc supprimer les étendus et les recréer, sans appliquer aucune stratégie. On testera après.  
 

https://community.cisco.com/t5/swit [...] -p/2462234
 
Je te laisse lire.
 
Personnellement j'ai jamais eu de problème avec, mais j'ai déjà entendu des histoire un peu morbide ou dans une grosse boite un stagiaire branche un switch sur le réseau qui fut un temps VTP server... j'te fait pas de dessin => wype de la config des vlan.
 
Concernant ton problème de DHCP Relay.. C'est tellement bateau que je comprends pas comment vous pouvez ne pas y arriver à faire fonctionner le truc.
 
 
 
1) ton serveur DHCP dans son réseau avec toutes les plages
2) idéalement sur ton routeur/firewall (équipement avec la passerelle sur les VLANS) tu configure le DHCP Relay qui pointe vers l'ip de l'équipement en 1 => fin de l'histoire.
 
 
Il faut pas que le DHCP ai accès à tout les VLANS ou je ne sais quoi.
 

 
C'est ce qui est configuré. Le DHCP relay est configuré sur toute les interfaces VLAN ( switch coeur de réseau  niveau 3).  
Le serveur DHCP configuré avec toute ses étendues, avec une plage d'adresse par étendue.  

Si ca marche pas quelques pistes :
 
- tu wireshark sur le serveur ou sur un port mirroré qui envoie les requête DHCP au server. Ca te permettra de vérifier que c'est bien le routeur qui envoie la requête DHCP et pas un autre équipement mal config sur le réseau.
- Pareil mais dans l'autre sens, vérifie que tes autre switchs ou équipements actif sur le réseau n'ont pas de DHCP Relay configuré.

tu as pas du proxyarp ou conneries configurées ?

Bonjour,  
 
alors pas de proxy arp.
 
Pour wireshark, oui, c'est le temps ( et la prise en main) qui va me bloquer, car la mise en prod commence...la semaine prochaine.
 
Mais on a avancé. Comme précisé plus haut, nous avons 2 serveur DHCP ( 2 vm en cluster, windows 2016, et non 2008 comme indiqué plus haut).  En mode fail over actif/ actif ( répartition de charge).  
 
Nous avons désactivé un des serveurs DHCP, nous avons viré nos stratégies de filtrage mac, paramètré sur le serveur DHCp ( pas de port-security sur les switch pour l'instant, mais ça sera au programme, plus tard. ( on a eu bien du mal d'ailleurs, on a du réinstaller complètement le rôle dhcp, car en virant juste les étendues et recréant derrière, il nous refout cette stratégie)...Et là...ça fonctionne nickel.  
 
Un poste client sur un vlan donné, reçoit la bonne ip, on le change de vlan, il redonne une IP du nouveau vlan instantanément.  
 
ça permet de dédouaner la partie "réseau".  reste à isoler l'erreur ( pb cluster DHCP? Script... ).
 
On a remis la stratégie filtrage mac sur deux étendues, pour voir. Pas de pb de DHCP, on obtient la bonne IP, par contre, le filtrage mac, il marche pas. On a fait un test avec 2 postes dont la mac adress était dans la règle de filtrage ( autorisé) ça marche, test avec un poste dont la mac adress n'est pas déclaré...ça marche aussi...
 
Mes collègues infras creusent la dessus.
 
Le prochain test sera de remettre en place le second serveur DHCP en fail over, et voir ce qui se passe...

bon beeeh c'est plutot une bonne nouvelle, pas de problème sur le réseau, mais plutot côté serveur

 
 
Oui, un collègue  a refait les dhcp ( à l'identique)  tout retesté étape par étape...avant de réappliquer les stratégies...plus aucun souci pour l'instant...Mais du coup, ça nous dit pas vraiment d'ou venait le problème, on verra à l'usage, mais oui, le problème venait côté serveur...