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-address
paramètre qui le pointe vers notre serveur DHCP et une dhcp relay-option 82 replace
ligne 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: