Contexte
J'ai un serveur DHCP Windows (Server 2008 R2) distribuant des adresses pour plusieurs étendues. L'une de ces étendues concerne certains téléphones IP Mitel. Les téléphones sont configurés pour utiliser l'option dhcp 125 pour obtenir des informations de configuration. Lorsqu'un téléphone démarre, il ne sait pas quel vlan utiliser, et il obtient donc le vlan par défaut (non balisé) du port auquel il est connecté. Le serveur DHCP lui donne une réponse qui inclut des informations sur l'option 125, et le téléphone est capable de lire le vlan qu'il doit utiliser à partir de cette réponse. Le téléphone libère alors son adresse d'origine et demande un nouveau bail dhcp en utilisant la balise vlan correcte. Les téléphones ont également généralement des ordinateurs connectés à un port d'intercommunication. Les paquets provenant des ordinateurs ne sont jamais étiquetés et les PC resteront donc sur le vlan d'origine (non étiqueté) pour le port. Cela a fonctionné pour nous pendant des années.
Problème et symptômes
Quelque part au cours des dernières semaines, quelque chose a changé et je ne sais pas quoi. Les téléphones continueront de fonctionner tant qu'ils ne redémarreront pas, ce qui signifie que les demandes de renouvellement DHCP doivent être traitées correctement. Les téléphones connectés à certains commutateurs peuvent même survivre à un redémarrage. Cependant, les téléphones connectés à d'autres commutateurs ne parviendront pas à terminer le processus au redémarrage. Tous nos téléphones utilisent PoE qui est sauvegardé par un onduleur, cela fait donc longtemps que aucun n'a redémarré. Cela signifie que je ne sais pas quand le problème est apparu pour la première fois. Ce que je sais, c'est qu'un téléphone a échoué lors de son redémarrage hier, et en le dépannant aujourd'hui, nous avons réinitialisé ce placard. Maintenant, aucun des téléphones de ce commutateur ne fonctionne (heureusement, c'est toujours un petit nombre). Je sais aussi que les choses fonctionnaient vers la fin du mois de janvier,
Lorsque je regarde un téléphone démarrer, je peux voir qu'il a réussi à obtenir la première adresse. Il lit ensuite avec succès les informations de l'option 125, définit la balise vlan correcte et libère le bail IP d'origine. Il est même capable de recevoir et d'accepter une offre sur le bon vlan du serveur . Cependant, c'est là que les choses s'arrêtent. Le téléphone a un message à l'écran qui dit " DHCP: Offer 2 ACC", mais le serveur DHCP Windows n'a pas enregistré le bail et le téléphone ne passe jamais. Je peux seulement deviner que le paquet DHCP REQUEST n'atteint jamais le serveur Windows, et donc le téléphone attend le dernier ACK de Windows qu'il est normal de continuer.
solution de contournement
J'ai enfin réussi à remettre un téléphone en marche. Pour ce faire, j'ai d'abord dû déconnecter l'ordinateur. Ensuite, j'ai défini le port de commutation du téléphone pour qu'il ne soit pas marqué sur le vlan du téléphone, sans appartenance au vlan du PC. Le téléphone va maintenant redémarrer correctement. À ce stade, je peux remettre la configuration du port du commutateur là où elle devrait être, et tant que personne n'essaie d'appeler ce numéro pendant que je réinitialise le port, le téléphone ne manque jamais un battement. Ensuite, je peux reconnecter l'ordinateur. De toute évidence, ce n'est pas un processus idéal, mais comme les téléphones redémarrent si rarement, je serai en mesure de l'utiliser pour que les gens travaillent à nouveau jusqu'à ce que je trouve la cause première. Les bureaux sont fermés maintenant pour la semaine, et donc ce problème sera en fait autorisé à s'asseoir le week-end (je n'ai pas de clés pour les bureaux individuels où se trouvent les téléphones).
Ce téléphone que j'ai réparé est le téléphone de service dans la salle des serveurs, connecté directement à notre commutateur principal. Il est possible que le problème soit lié au routage ou au traitement des balises sur le commutateur principal, de sorte que la solution de contournement ne soit pas efficace sur les bureaux distants où les paquets sont d'abord passés (marqués par) d'autres commutateurs, mais je serai très surpris si cela se produit, étant donné que je sais qu'il doit traiter correctement les renouvellements DHCP et les conversations téléphoniques réelles.
Une torsion est que laisser le port marqué sur le PC VLAN signifie que le téléphone échoue à la place avec le message " DHCP: Offer 1 ACC". Je dois supprimer ce vlan entièrement pour que cela réussisse.
Remarque: J'ai maintenant confirmé que la solution de contournement est efficace dans les bâtiments éloignés. Cela m'amène à soupçonner que mes appareils ne sont en quelque sorte pas affectés au bon vlan. Le fait que j'ai rencontré le problème sur mon commutateur principal et qu'il se soit produit à plusieurs endroits sur le réseau à peu près en même temps indique que le commutateur principal peut être le problème. Avec rien de spécifique à regarder, je planifie une fenêtre de maintenance vers la fin de la semaine pour redémarrer le commutateur. Je peux également mettre à jour le firmware.
Environnement
Notre commutateur principal est un HP 5406zl. Ce commutateur gère le routage inter-VLAN. Le serveur DHCP Windows est connecté directement au commutateur. Les commutateurs d'extrémité sont connectés au commutateur principal via des SFP fibre, et ces ports sont étiquetés pour tous les réseaux locaux virtuels aux deux extrémités. Le commutateur principal configure chaque vlan avec un ip helper-addressparamètre qui le pointe vers notre serveur DHCP et une dhcp relay-option 82 replaceligne afin que le serveur DHCP sache quelle étendue utiliser. Ces configurations et les configurations de port sur les commutateurs de point de terminaison n'ont pas changé depuis au moins 16 mois. Nous avons eu d'autres réinitialisations de commutateur et de téléphone pendant cette période.
La plupart de nos commutateurs d'extrémité sont de la série HP 2530. Ces commutateurs semblent fonctionner correctement (les téléphones sur 3 2530 différents ont redémarré correctement aujourd'hui). Ce sont des commutateurs plus anciens qui ont des problèmes. Nous avons un ancien 3Com 4200 et un 4210 qui ne fonctionneront pas. Le téléphone de service connecté directement au commutateur principal mentionné précédemment ne fonctionnerait pas non plus.
Question
À ce stade, ma meilleure supposition est qu'une mise à jour de Windows sur le serveur DHCP a changé le comportement, mais je ne vois pas comment. Ou peut-être que le commutateur principal ne gère pas correctement ce paquet REQUEST, mais je suis sûr que rien n'a changé là-bas, et cela n'explique pas pourquoi seuls certains commutateurs d'extrémité sont effectués. Comment puis-je résoudre ce problème?
Mise à jour:
Voici un extrait du journal DHCP d'un téléphone en panne:
10,03 / 06 / 15,12: 40: 40, Attribuer, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 11,03 / 06 / 15,12: 40: 40, Renouveler, 10.1.2.158, , 08000F197844,, 3189088995,0 ,,, 12,03 / 06 / 15,12: 40: 41, version, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 15,03 / 06/15/12: 40: 45, NACK, 10.1.2.154,, 08000F197844,, 0,6 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154,, 08000F197844,, 0,6 ,,,
Les adresses 10.xxx sont le vlan PC (ce choix me précède à cet endroit). Les téléphones devraient d'abord obtenir ce type d'adresse, c'est donc normal. Cependant, après le message de sortie, je m'attends également à trouver une offre pour une adresse dans la plage 192.168.16.x, car je peux voir au téléphone qu'une offre a été acceptée (sauf si j'interprète mal "ACC"). Il est intéressant de noter que je ne vois jamais le serveur essayer d'émettre une telle adresse, même si le téléphone pense en avoir reçu une.
J'ai considéré l'idée qu'il y avait un serveur DHCP voyous sur le réseau (il distribue une adresse avant le serveur Windows, mais sans les options DHCP nécessaires au téléphone pour continuer), mais cela n'explique pas pourquoi les téléphones fonctionnent si et seulement si Je supprime complètement tout chemin vers le PC VLAN. Je vais le tester de toute façon le matin en connectant mon ordinateur portable à un port défini pour le téléphone vlan, mais si quelqu'un d'autre a une meilleure explication en attendant, j'aimerais l'entendre.
Voici une copie de la configuration du commutateur:
la source
Réponses:
J'ai résolu le problème aujourd'hui en supprimant la balise vlan pour le téléphone vlan sur le port se connectant à notre serveur DHCP. C'est très étrange pour moi que cela ait fonctionné, car d'autres systèmes qui utilisent un schéma similaire (alias: SSID Wifi utilisant 802.1q) nécessitent la balise ou les clients ne peuvent pas obtenir d'adresses. Cela a fonctionné, donc je ne chercherai pas trop, mais je serais intéressé à voir des réponses avec des théories pour expliquer pourquoi c'est ainsi.
la source
Vous devriez envisager d'exécuter une capture de paquets de chaque côté des commutateurs problématiques, puis de les examiner dans Wireshark. Cela pourra vous dire 1) si le trafic est intercepté par un serveur DHCP escroc (basé sur l'adresse MAC) et 2) si quelque chose devient altéré ou abandonné (par exemple, vous avez peut-être besoin d'un relais DHCP). Cela peut nécessiter une mise en miroir des ports, ou le 3com peut prendre en charge la capture directement sur le commutateur.
la source
Si vous constatez que ce problème réapparaît, vous souhaiterez peut-être vérifier la taille de votre étendue DHCP et le nombre de baux en cours d'utilisation. Si les anciens baux DHCP ne sont pas détruits, votre serveur peut penser qu'il ne reste aucune adresse dans le pool et être incapable d'attribuer de nouvelles adresses. Cela est vrai même si aucun périphérique ne répond dans le vlan. Si votre portée DHCP est de 7 jours, cela peut prendre jusqu'à 7 jours avant que vous puissiez obtenir un nouveau bail. De même, la modification de votre configuration résoudrait le problème car il y aurait une nouvelle plage d'adresses qui pourrait être éliminée, ou elle pourrait vider les baux en fonction des changements de configuration. Je suggérerais de fixer la durée de vie du bail à quelque chose de très bas, comme une heure pour cette portée si tel est le cas.
la source