Suite à ce fil, je devais éteindre le switch. J'en profitais pour faire une MAJ majeure du firmware.
Je vais vous retracer la journée (que vous pourrez juger d'enfer). Je me suis dit que cela méritait un nouveau sujet. Et cela pourra peut-être servir à  
d'autres débutants comme moi mais aussi éventuellement permettre de bénéficier des conseils d'expérimentés.
 
La tentative de MAJ a été faite le soir, bien entendu, pour déranger au minimum. Après application de la procédure ProCurve, au reboot le switch restait
en défaut. Reset puis débranchement n'y ont rien fait.
 
Retour le lendemain puisque je ne pouvais rien faire de plus (bonne nuit...). Réseau, internet, FTP, DNS, NAS bloqués... Appel de la hotline pro de  Procurve.
 
Le switch dispose d'une mémoire flash disposant de trois emplacements pour les fichiers de configuration : images primaire et secondaire, bootables,  
et un troisième emplacement de stockage. A cela s'ajoute une mémoire stockant le boot. S'il y a un défaut sur l'image primaire, on peut booter sur la  
secondaire. Comme il n'y a plus d'accès telnet, il faut se brancher en console du switch avec Hyperterminal (ou autre). Le port de la console est un port COM avec un câble null-modem. Il a donc fallu trouver un vieux PC avec port COM et Hyperterminal.
Accès Hyperterminal, reset du switch puis débranchement : le boot n'aboutit jamais.
La mémoire du boot est donc H.S. Selon la hotline, pas de cause particulière à ce crash (je suis rassuré, ma manoeuvre n'est pas en cause).
 
En attendant, il a fallu remplacer à la volée le switch 48 ports par un à... 8 ports, dérouter l'arrivée de la fibre sur un autre switch mais en bypassant le  
routeur-FW pour qu'une partie du réseau puisse continuer à fonctionner. Les problèmes se sont accumulés, les uns avaient les mails mais pas internet,  
les autres n'avaient plus accès au NAS ni au serveur FTP ou réciproquement etc. Ensuite plus de réseau par intermittence : il y avait conflit d'adresse entre un équipement qui était derrière le FW au préalable et... le routeur du FAI, gloups.
 
La hotline pro de Procurve a été efficace (sous garantie) et nous avons reçu le nouveau switch le lendemain matin.
 
Schéma d'architecture : FO ---- routeur FAI ---- Eth. ---- FW (et aussi routeur) ---- DMZ + switchs --...
 
Comble, le firmware du 'nouveau' switch est assez ancien. Mais les problèmes de ports inactifs, de ligne dégradée en 100 Mb/s ne sont plus.
 
Ce que j'en retire. Je suis à peine arrivé et sans expérience et plus doublonné... formateur. Encore qu'il aurait été plus profitable de parfaire et mettre en pratique mes maigres connaissances dans d'autres circonstances plus sereines.
Il faut prévoir une position de repli à l'avance, autant que faire se peut. D'ailleurs peut-être qu'une architecture serait moins vulnérable que celle-ci (je ne vois guère).
Ne pas tenir compte des besoins individuels sinon l'on ne s'en sort pas et essayer de résoudre le problème globalement.
Et... réfléchir avant d'agir.
Au final, je ne sais pas si le peu de pertes engendrées justifieraient un switch doublon pour remplacement au pied levé.

 
Ça dépend de la taille de ta boîte. Mais même si elle est très petite, c’est certainement très supérieur au prix d'un switch de spare (et ça aussi c'est une leçon à vraiment retenir). Plus grosse tu aurais pu perdre de quoi te payer une palette ou deux des switchs en question    
 
Sinon, tu vas pouvoir mettre en place un deuxième switch en failover/load balancing, ça permet de faire ce genre d'opérations l'esprit tranquille. En gardant sous la main un 3e switch de spare.

T'es chaud de flasher un switch fédérateur sans en avoir un autre sous la main. J'ai 13 ans d'exp dans les systèmes et réseaux pro et je suis tout à fait d'accord sur ta conclusion : prévoir une position de repli, réfléchir avant d'agir, et surtout, je n'ai pas honte de le dire même à mes clients : quand on sait pas, on demande à quelqu'un qui sait (autrement dit, s'entourer des bons partenaires). Bye ;-)

Perso je dirais que sauf contrainte de place dans la baie ou le coffret, il vaut mieux avoir 2 switch 24 ports qu'un de 48 ports même si le cout est un peu plus élevé.
 
Tout d'abord la panne d'un switch c'est 24 personnes au tas (moins en pratique vu que les deux switch sont rarement plein) et ça crie donc moins que si tout le monde est au tas.
 
De plus si on veut du spare un switch de 24 ports, c'est moins d'argent immobilisé donc plus facilement justifiable.

Il faut dire que j'avais averti tout le monde avant de faire la manip', le responsable n'a rien trouvé à redire.
Merci pour vos retours et leur ton, je m'attendais à de l'ironie.

Il faut dire que j'avais averti bien entendu tout le monde avant de faire la manip'. J'aurais dû de moi-même ne pas me lancer dans cette voie mais, sans vouloir me dédouaner,  le responsable n'a rien trouvé à redire non plus.
Merci pour vos retours et leur ton, je m'attendais à de l'ironie.

 
Si tu veux on peux te mettre un peu d'ironie et un trait de cynisme gratuit au passage ^^

La màj du Firmware d'un switch est une opération critique, mais pas forcément dangereuse non plus. Y a quelques temps, j'ai mis à jour plus de 1 500 switchs HP 2524 (sur ce modèle, il n'y a qu'un seul emplacement de boot possible), ça s'est passé sans problème (ou presque). Par contre, il faut prendre quelques précautions :  
- Communiquer ! Là, tu as bien joué le coup. En prévenant ta hiérarchie et les utilisateurs sur les risques et le pourquoi de l'intervention, ils acceptent mieux s'il y a un problème.
- Avoir une solution de secours : quid en cas de problème ? Puis-je me passer de ce switch ? Une heure ? Un jour ? Une semaine ? Pas du tout ? La procédure à suivre n'est forcément pas du tout la même...
- Dans l'idéal, maquetter au maximum : que se passe-t-il si j'interromps le transfert ? Si le fichier est corrompu ? Bon, quand tu mets à jour un switch, et que t'en as pas d'autres de dispo, c'est plus compliqué...
- TOUJOURS vérifier le hash md5 du fichier que l'on va charger (ou qui a été chargé, si possible) avec celui (fourni en général par le constructeur) du fichier original.
 
Je crois que dans ce ton cas, ton "erreur" a été de vouloir corriger par une màj firmware un problème qui, si j'en crois ton autre topic, était plutôt physique. Si tu as des problèmes sur un port particulier, la marche à suivre c'est plutôt (pas forcément dans cette ordre là, mais bon) :  
- vérifier la conf du port (vlan, duplex, vitesse)
- vérifier les erreurs (présence de collisions, de CRC, de Giants frames, etc.) : ça peut t'orienter vers un pb de duplex, de câblage, de taggage de trame, etc.
- si possible, brancher sur un autre port (qui a les mêmes paramètres). Si ça résout le problème, c'est que le port est HS. Et là, tu vas pas plus loin => changement de switch. Sinon, changer le câble, brancher un équipement qui fonctionne sur le port en cause, etc.

 
Non merci, sans façon, même si après ma mésaventure, je vois la vie avec plus de recul.  
 
Merci Djoul. Pour info, j'ai exposé mon problème en omettant les vérifications me semblant aller de soi, pour alléger le post. J'avais en effet vérifié/changé port, câble, vu aussi la source.
 
En l'occurence, la même ligne me pose problème, j'ai diminué la fréquence d'apparition d'alertes en dégradant la ligne en 100FDx en attendant d'interenir sur la carte réseau de la source.
 

Maynard de la COGIP ? Comment va Berthier ??

Tu confonds. Moi c'est Maynard de BetaDigix avec Dugommeau en DSI.

lol je sais c'est une référence aux parodies vidéos (je crois que c'est Mozinor qui les avait fait..) ca vaut le coup d'oeil et je pense que tu comprendras mieux : http://www.youtube.com/watch?v=8N_ [...] re=related
 
Maynard et Berthier de la COGIP, mes héros ^^

Sans oublier Michaud de la Sogetruc.