Nous venons de terminer une migration de notre infrastructure d’accès à internet. Nous sommes passés d’un réseau de collecte à un autre, réseaux de collecte nous permettant d’avoir accès à un point d’entrée du réseau RENATER, FAI officiel des établissements d’enseignement supérieur et de recherche.

Concrètement, pour moi, il s’agit d’acheter un appareil électronique qu’on appelle un routeur, le déballer et le visser dans une armoire pleine d’appareils similaires (en fait des switchs), attendre qu’un prestataire approprié vienne configurer cet appareil, et le jour J, au top conjoint donné par un informaticien de RENATER et du réseau de collecte, déconnecter le câble branché sur A pour le mettre sur B. Voilà, voilà.

Oui, mais non.

Jeudi, quand j’ai changé le câble de prises, l’accès à internet a été coupé, mais n’est pas revenu aussitôt le câble rebranché. 1000 personnes ont vu leurs cheveux se dresser sur leurs têtes: plus d’internet (en fait, je les ai rassuré aussitôt, plus d’accès à internet, merci pour lui).

Bah, j’étais prévenu, on ne change pas un chemin d’accès d’un claquement de câble dans une prise. Les plus studieux d’entre vous iront lire cette présentation du changement de routage de manière dynamique avec BGP. Disons pour résumer qu’un expert de ces problématiques s’occupe de tout au NOC (Network Operation Center) de RENATER.

Premier problème : l’ancien réseau de collecte A annonce la route vers mon établissement avec la priorité maximale. Difficile pour le nouveau réseau de collecte de faire mieux et de devenir prioritaire. La migration s’annonce difficile, surtout que la personne en charge de BGP chez A est… en congés aujourd’hui. Je fais finir par croire que A est fâché de ne pas avoir remporté l’appel d’offre et met quelques freins à la migration vers B.

Vendredi, le problème est réglé, je bascule tout l’établissement vers le nouveau réseau de collecte B. Le trafic passe dans les deux sens. Voilà, voilà.

Oui, mais non.

Le trafic ne passe pas. Retour arrière. Sauf que le réseau de collecte A voit d’un mauvais œil les alertes sur sa plate-forme de supervision « un coup je m’en vais », « un coup je reviens », surtout en cette période où plus de 40 établissements font plus ou moins la même chose. Ces choses là se règlent au téléphone, mais ce n’est pas le meilleur moment. Pourtant, je reste calme, cela ne sert à rien d’énerver tout le monde avec mon stress. Autre réunion téléphonique, avec RENATER et le nouveau réseau de collecte B cette fois. Tout le monde me dit que tout est ok de leurs côtés et que les problèmes viennent de chez moi.

C’est là que débute une véritable enquête.

Nous mettons en place en salle serveurs un tableau de papier sur lequel nous listons tous les problèmes rencontrés: perte partiel de l’accès internet (merci le loadbalancing avec une simple LiveBox), sites webs ok mais deux serveurs DNS sur quatre injoignables, accès aux services web internes aléatoires, envois des emails intermittent, etc.

La tension est palpable mais j’avais pris les devant en prévenant tous les clients que nous allions vivre une migration importante et qu’il risquait d’y avoir des perturbations dans La Force. Nous sommes concentrés sur la résolution du problème.

Tout est remis en cause. Et quand je dis tout, je veux vraiment dire tout: câbles, prises, virtualisation des passerelles, virtualisation des switchs, les VLAN, les switchs physiques, l’apparition d’une boucle sur le réseau réel, sur les réseaux virtuels. Les admins réseaux se sont transformés en enquêteurs suspicieux de tout ce qu’ils ont mis en place. Et pour chaque idée, un test est effectué.

Le vendredi soir arrive, la nuit et l’heure tardive n’y change rien. Je rentre chez moi le cœur gros. Le samedi est consacré à mon fils et son tournoi de ping-pong. Mais mon esprit est ailleurs : qu’est-ce que j’ai pu rater pour que notre migration se soit mal passée ?

Le week-end sera court : je décide de travailler tout le dimanche sur le problème. Me voilà donc seul dans cette maudite salle serveurs à faire différents tests. Je reboote les équipements les uns après les autres, y compris les serveurs de virtualisation après avoir migré les différentes machines virtuelles. Et soudain: EUREKA! Le port du switch sur lequel est branché la passerelle n’est pas correctement tagué. Je corrige la configuration, je branche la passerelle et j’ai enfin un accès internet correct. Je suis aux anges. Je préviens mon équipe par SMS, je tweete avec allégresse et finesse, et je rentre le cœur léger.

Mais lundi matin, en arrivant à mon bureau, patatra. Mon équipe me dit que rien ne marche. Nous reprenons toute notre enquête.

Elle durera 14h.

14h à refaire toutes les hypothèses, à reprendre toutes les pannes possibles, à passer des coups de fil pour s’entendre dire « non, non, le problème vient de votre côté ». A un moment, nous nous sommes retrouvés avec tout notre réseau
débranché, une passerelle physique construite de bric et de broc avec un
PC et deux cartes réseaux et un live cédérom pfsense, le tout branché
sur un switch HP récupéré et reconfiguré avec les VLAN adhoc pour
l’occasion… A 23h, je lâche le coup, exténué. Je ferme mon bureau avec le moral au plus bas. Pour la petite histoire, je monte sur mon vélo pour rentrer, et je découvre que la roue arrière est déboîtée. Je cherche dans l’école des outils pour essayer de réparer. Mon moral descend encore d’un cran. Sale journée.

Deux points positifs quand même: j’ai réussi à remettre la roue de mon vélo (j’aurai réussi au moins à réparer une chose ce jour-là). Et j’ai réussi à reproduire le problème sur commande: lorsque la passerelle est branchée seule sur le nouveau routeur du nouveau réseau de collecte, j’arrive à surfer sur internet à partir d’un poste (le seul ayant cette machine comme passerelle). MAIS si j’ouvre plusieurs pages dans plusieurs onglets, au bout d’une dizaine d’onglets, la passerelle n’accède plus à internet. Si j’attends environ une minute, elle retrouve ses esprits et accède de nouveau à internet. A n’y rien comprendre.

J’ai très peu dormi cette nuit là. Cinq jours que nous sommes quasiment coupés d’internet. Quelques personnes disposent d’un accès via la LiveBox du PRA. Nos serveurs web principaux sont sains et sauf (hébergés à l’extérieur en prévision de la migration). Mais beaucoup des outils du SI sont en temps normal accessibles aux étudiants et à leurs parents, et leur inaccessibilité commence à peser sur l’organisation.

Une part importante de mon métier est de penser à des plans B. J’ai d’ailleurs développé un sens aigu du film d’horreur permanent. Seulement voilà, dans le cas présent, j’arrive au bout du bout des idées possibles de tests à imaginer, de pannes possibles, de vérifications à effectuer…

Mais la nuit porte conseil. Je me réveille avec en tête l’hypothèse que le nouveau routeur, bien que configuré correctement (configuration plusieurs fois vérifiée), PEUT présenter un dysfonctionnement en cas de sollicitation. C’est mon dernier espoir. Problème: je ne connais pas ce nouvel équipement qui se configure en ligne de commande, et la documentation fait 300 pages. Je décide de prendre l’option « appel à un ami ».

Nous sommes mardi matin. Je téléphone à un expert du nouveau réseau de collecte pour lui demander de venir m’aider en salle serveurs. Après quelques négociations, il me propose de tout faire depuis son bureau, si je lui ouvre un accès ssh à notre passerelle. Pendant une heure, nous ferons des tests avec lui. Jusqu’au moment où je l’entends dire au téléphone: « tiens, ça me donne une idée ». Cela faisait 24h que je n’avais pas entendu cette phrase.

Quelques minutes après notre problème était résolu.

Rien ne clochait de notre côté. Ni sur notre réseau, ni sur notre passerelle, ni sur nos DNS, ni sur notre routeur. Le problème venait de leur côté à EUX. Le port sur lequel est branché la fibre optique venant de notre routeur était auparavant utilisé pour gérer des échanges entre une adresse IP unique et une adresse IP unique (une connexion entre serveurs proxys appairés). Il avait été configuré pour résister à une attaque DDOS, c’est-à-dire qu’il refusait de fonctionner s’il détectait un comportement anormal. Or, son branchement sur notre routeur a entraîné une discussion entre l’IP de notre routeur et un grand nombre d’adresses IP, ce qui a été détecté comme une anomalie, et donc une mise « OFF » pendant une minute.

Cela explique que dimanche, alors que j’étais seul à surfer, et que je n’avais pas pensé à ouvrir 20 onglets dans mon navigateur, tout fonctionnait. Mais lundi, dès que le personnel et les étudiants ont commencé à vouloir surfer, le système se coupait « quasiment » en permanence.

L’enquête est terminée. La fin a été comme souvent heureuse, grâce à l’entraide des différents admins réseaux, même si le réflexe initial de chacun est d’avoir confiance en SON système et de rejeter la faute sur le système de l’autre.

La morale est sauve: celui par qui le problème est arrivé, est celui qui l’a résolu. Je lui ai promis de boire ensemble une bouteille de champagne. L’erreur de configuration était subtile, mais sa perspicacité lui a permis de la débusquer.

Et grâce à lui, nous avons révisé en profondeur nos configurations…

——————–

Crédit images darkroastedblend.com