238a62c90b6c7dd762d57225afd6a2689f3c8c72
Rapports-Intervention/ri-30-03-18-remplacement-switch-cassant-lacp-i1-i11.md
| ... | ... | @@ -0,0 +1,50 @@ |
| 1 | +**État :** Infrastructure et services rétablis |
|
| 2 | + |
|
| 3 | +**Date :** Vendredi 30 mars 2018 |
|
| 4 | + |
|
| 5 | +**Admins impliqués :** Clément Courtel, Bruno Mateu (à distance), Thibault Piana, Baptiste Schmitt, Guillaume Weghsteen |
|
| 6 | + |
|
| 7 | +**But :** Rétablir les services du ResEl suite au remplacement du switch d'accès 24 ports du I9. |
|
| 8 | + |
|
| 9 | +**État des lieux avant :** Le problème s'est déroulé sur le campus de Brest. La majorité des utilisateurs semblait avoir accès à internet. Aucun service (sites, passerelle, etc) ResEl autre que internet n'était accessible. Après quelques investigations (voir détail après), il s'est trouvé que le i1 et le i11 n'était plus connectés. Le lien LACP entre kuma (i1) et laëtitia (i11) était down. Elris1 (switch i9) est remplacé par un cisco 3560G (ancien laperouse). |
|
| 10 | + |
|
| 11 | +**État des lieux après :** L'ancien switch du i9 (elris1 100M) est remis en place. Le 3560G est racké mais non connecté. Le lien LACP entre i11 et i1 est de nouveau opérationnel. La connexion entre I1 et I11 est donc rétablie. Les services sont de nouveau up. |
|
| 12 | + |
|
| 13 | +**Machines/Services touchés** : Laëtita, (+ kuma). Toutes les machines du i11 en quelque sorte puisqu'elles étaient injoignables. |
|
| 14 | + |
|
| 15 | +**Détail des modifications :** |
|
| 16 | +Il n'y avait pas de cours (cause : voyage Q) ce 30/03. Guillaume et Baptiste en ont profité pour faire une formation installation et paramétrage de switch.Il était prévu de remplacer un switch d'accès 100M par l'ancien switch de tête Cisco 3560G Laperouse renommé Michelle temporairement, qui possède 4 SFP et 24 ports 1G. |
|
| 17 | +Matinée et début d'après-midi : pré-paramétrage en connexion série (configuration de l'ip, interface downlink, login locaux, ssh). Le switch est racké et branché comme suivant : |
|
| 18 | +kuma(i1) <------------->elris1(i9)<->elris(i9)<->Michelle. |
|
| 19 | +Les tests montrent que Michelle est joignable (ping) depuis yoshi par son ip temporaire en 0.92. Tout va bien. |
|
| 20 | +Fin d'après-midi : Fin de la configuration de Michelle par ssh (recopie de la configuration des ports de Elris1 principalement). |
|
| 21 | +17h40 : intervention i9 pour passer les chambres et les bornes sur Michelle. |
|
| 22 | +Dû à un manque de type de connecteur de fibre, la configuration initialement prévue (kuma<----------->Michelle<->elris) n'était pas possible. Il a été choisi la configuration (kuma<---------->elris<->Michelle). A ce moment, débranchement du downlink kuma<----->elris1 et branchement sur elris. |
|
| 23 | +Branchement des ports d'accès. |
|
| 24 | +Tests.... La connexion en ethernet depuis Michelle fonctionne. Pas en wifi (on comprendra plus tard que ça vient du fait que le contrôlleur n'était plus accessible car au i11). Les services ResEl (sites) ne fonctionnent plus. Impossible de pinger les machines. |
|
| 25 | +Clément au i11 utilise le kvm pour aller sur yoshi. Yoshi est isolé de Zahia. |
|
| 26 | +Guillaume au i1 se log sur zahia en local, et Bruno ssh sur zahia en passant par la passerelle rennaise. Même constat : zahia isolée du i11. |
|
| 27 | +Au i9, Thibault débranche le down link venant de Kuma car il semble que cela ait provoqué la panne. |
|
| 28 | +Au i11, login sur Laëtitia, lecture des logs. l'erreur "%PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Gi0/49, putting Gi0/49 in err-disable state." est notamment présente pour les ports Gi0/49-52 (4 liens du LACP). |
|
| 29 | +Restauration du lien : sur Laëtitia : |
|
| 30 | +- conf t |
|
| 31 | +- interface Port-channel1 |
|
| 32 | +- shutdown |
|
| 33 | +- no shutdown |
|
| 34 | +Les services sont de retour. |
|
| 35 | +20h30 : Retour au i9 pour rebrancher la stack d'accès avec la configuration originale kuma<-------->elris1<->elris |
|
| 36 | +Les services retombent. |
|
| 37 | +Clément retourne au i11 vérifier le LACP. |
|
| 38 | +Rétablissement du lien LACP (mêmes commandes) en laissant la stack d'accès du i9 connectée. |
|
| 39 | +Les services sont de retour en ligne. |
|
| 40 | + |
|
| 41 | +**Problèmes rencontrés :** |
|
| 42 | + |
|
| 43 | +- Les admins sur place ne connaissaient pas les ip des machines pour faire les tests de ping. |
|
| 44 | +- Les admins sur place n'avaient pas les login/mdp locaux des switchs (nécessaires car l’authentification par radius passe par le i11). |
|
| 45 | + |
|
| 46 | +**Tests :** |
|
| 47 | +- Icinga s'excite, les sites sont de retour, yoshi en ligne. |
|
| 48 | + |
|
| 49 | +**Évolutions futures :** |
|
| 50 | +- Trouver le pourquoi du comment. Le mélange kuma (juniper)/STP cisco/LACP est pointé du doigt. Il semble que c'est la première fois depuis l'installation de kuma qu'un switch d'accès est changé. |
|
| ... | ... | \ No newline at end of file |