"Petit" bug de la semaine, mais du côté Cisco cette fois.
Contexte: Migration d'un client de la version 8.5 à 10.5, 1200 téléphones IP.
Problème: De mon côté, c'était le baptême du feu pour Cisco PCD en production utilisé dans le cadre de cette migration mais si je l'avais au préalable testé à de nombreuses reprises dans mon lab.
La migration se passe comme prévu, mais, le nombre de téléphone comptabilité avec RTMT avant la migration et après la migration soulève un gap non négligeable.
Les téléphones concernés sont tous dans l'état "configuration IP", la dizaine de modèles de téléphones présents dans l'environnement est concernée. Je recherche le "pourquoi" avant de tenter une résolution, en redémarrant quelques postes opérationnels, je m'aperçois que les délais dans le mode "configuration IP", même si au final le téléphone s'enregistre correctement, est relativement long, de l'ordre de 4-5 minutes, comportement inacceptable.
Les serveurs cucm étant actuellement seuls dans leur vlan, je décide de mirrorer l'ensemble du flux vers mon poste pour sniffer le comportement, je n'ai pas conservé les traces malheureusement, mais les serveurs reçoivent toutes une série de requêtes DHCP Request ou Discovery venant des vlan des différents téléphones impactés sans jamais y répondre... Pour répondre à une partie des téléphones mais pas à tous?
Pour être sur, on crée une plage DHCP sur un serveur Windows pour un des vlan contenant des téléphones IP impactés par le problème, après modification du dhcp helper, les téléphones s'enregistrent immédiatement...
J'entends le mot "Rollback", que nenni, on positionne temporairement les téléphones impactés sur un serveur DHCP externe le temps de trouver une solution.
Une recherche dans les bugs connus confirme le problème: https://tools.cisco.com/bugsearch/bug/CSCup60269
CallManager 10.5 does not respond to DHCP Requests and Discoveries.
Conditions:
Using CallManager 10.5 as the DHCP Server for end points
Workaround:
Use a non-CUCM DHCP Server
Please contact Cisco TAC for permanent fix.
Known Affected Releases: |
(1)
|
Known Fixed Releases: |
(4)
|
Bingo, il s'agit bien de ma version 10.5(1.10000.7)....
Comme quoi, on critique Microsoft, mais un bug de cette sévérité dans une version 10.5, c'est plutôt "irritant".
Bien sûr, impossible de télécharger le "correctif" directement, il faut ouvrir un case, 24h de perdu juste pour recevoir le lien.
Ce n'est pas un simple patch à installer, il faut entamer une procédure d'upgrade type L2
Je vais utiliser PCD pour l'effectuer dans mon lab, depuis la migration, je constater aussi que mon 7911 rester aussi dans l'état "configuration IP":
Positionner l'ISO envoyé par Cisco sur le serveur SFTP de PCD
1/ Découverte du cluster existant: voir article http://microsofttouch.fr/default/b/christophe/archive/2014/07/14/cisco-migration-cucm-avec-cisco-prime-collaboration-deployment.aspx
2/ Création tâche de mise à jour:
Naviguer dans Task - Upgrade et faire Add Upgrade Task:
Sélectionner le cluster découvert précedemment
Sélectionner l'ISO envoyé par Cisco sur le serveur SFTP de PCD.
Sélectionner le temps de départ de la tâche:
PCD crée une stratégie de mise à jour:
La tâche est terminée:
3/ Lancement de la tâche:
Lors de la phase du switch des partitions une erreur est constaté:
ERROR
The switch version status could not be determined. Please manually verify that the switch version completed.
juil. 26, 2014 09:41 EDT
Une vérification sur le serveur confirme que le changement de version est effectif même si le statut dans PCD montre un état Failed:
4/ Résultat:
Les captures d'écrans proviennent de mon lab, la nouvelle release est installée:
Même dans mon environnement, les temps d'enregistrements sont considérablement réduit, le 7911 impacté depuis la migration s'est immédiatement enregistré dans mon cluster.
A méditer avant de migrer! je garde précieusement cet ISO pour la prochaine migration ou installation