Romain Castelli_

Le projet nous demandait de monter chacun notre datacenter, puis de les relier. Avec Alexandre on s'est réparti le travail : lui son DC sous FRRouting, moi le mien sous Arista cEOS, et un CPE Cisco au milieu pour faire le lien. Le tout sur containerlab.

Le fait d'avoir deux stacks différentes n'était pas prévu au départ, c'est venu de nos choix respectifs. Au final c'est ce qui a rendu le projet intéressant.

On a commencé chacun dans son coin : monter sa fabric, vérifier que le routage interne tourne. Ensuite le CPE, pour établir le BGP entre les deux côtés. Et seulement après, l'overlay par-dessus. Cet ordre-là compte : tant que la plomberie n'est pas propre, inutile de poser le réseau logique dessus, on ne saurait pas d'où vient le problème.

Sauf que l'underlay montait bien, le BGP était établi, et rien ne passait entre les deux datacenters. On a cherché quelques heures, les deux configs côte à côte, sans voir.

C'est un prof qui nous a mis sur la piste : regarder du côté du VNI et du route-target. Le premier identifie le segment virtuel, le second dit quelles routes importer et exporter. Les nôtres ne correspondaient pas d'un côté à l'autre, donc chacun annonçait dans le vide : personne n'écoutait ce que l'autre racontait. Tout avait l'air correct, le BGP était up, et pourtant rien ne passait. Rien dans les logs ne le disait, il fallait savoir où regarder.

Une fois les paramètres alignés, le ping inter-DC est passé. Une VM de mon datacenter qui joint une VM du sien comme si elles étaient sur le même segment, alors qu'il y a plusieurs routeurs entre les deux. C'est ce projet qui m'a fait comprendre pour de bon la différence entre le réseau physique routé et le réseau logique qu'on fait passer par-dessus. Tant qu'on n'a pas debuggé les deux séparément, ça reste une notion de cours.

Ce que je garde de ce projet, c'est surtout que la doc ne dit pas tout. On avait bien lu, chacun de notre côté, et pourtant ce détail-là ne nous avait pas sauté aux yeux. Il a fallu quelqu'un qui l'avait déjà vécu.

Et que bosser à deux sur des stacks différentes force à comprendre le protocole plutôt que la syntaxe d'un constructeur. Si Alexandre avait été sur Arista comme moi, on aurait copié-collé nos configs sans réfléchir.

Il n'y avait aucune gestion centralisée du parc mobile. Chaque appareil était configuré à la main, un par un, et une fois dans la nature on n'avait plus la main dessus. Sur plusieurs centaines de terminaux, ça ne tient pas. La mission : mettre en place un MDM. On l'a menée à deux, du début à la fin.

On a commencé par comparer les solutions du marché. La souveraineté des données était un vrai critère : on parle d'un établissement public, savoir où partent les données compte.

Ensuite, test sur quelques appareils seulement. Pas question de lancer sur tout le parc sans savoir comment ça se comporte. Une fois le socle validé, déploiement progressif par lots. Le parc est hétérogène, et chaque plateforme a sa propre logique d'enrôlement, donc il a fallu comprendre les deux avant d'arriver à une configuration commune.

À un moment, un conflit de configuration entre nous deux a verrouillé une partie du parc. Le genre de truc qui fait comprendre pourquoi on teste sur un petit lot avant de généraliser. On a fait le rollback, cherché d'où ça venait, et depuis on se cale avant de pousser une modification.

Le déploiement est toujours en cours, mais ce qui est en place change déjà le quotidien. Un appareil neuf sort du carton, se connecte au réseau, s'enrôle tout seul et récupère sa configuration, ses applications et ses restrictions sans que personne n'y touche. On peut agir à distance, et le parc est mieux sécurisé qu'avant. Sur cette taille de parc, c'est la différence entre une intervention par appareil et zéro.

Avec le recul, ne rien avoir avant était plutôt une chance : on a pu poser les choses comme on les comprenait, sans hériter d'un système existant à rattraper. Et j'ai appris qu'un déploiement progressif, ce n'est pas de la lenteur, c'est ce qui fait qu'un incident touche dix appareils au lieu de tout le parc.

Un TP guidé, avec des consignes précises : comparer deux façons de récupérer l'état d'un équipement réseau. D'un côté le SNMP, où le collecteur demande « alors, ton état ? » toutes les trente secondes et ne sait rien entre deux questions. De l'autre le streaming telemetry, où l'équipement prend l'initiative et notifie quand quelque chose bouge.

J'ai mis en place la collecte gNMI avec gnmic sur des équipements Arista, en testant les deux modes : sample, qui échantillonne à intervalle fixe, et on-change, qui ne notifie que sur changement d'état. En parallèle, un pipeline sFlow pour les flux, et des tableaux de bord Grafana adossés à Prometheus pour visualiser tout ça.

Ce qui m'a pris le plus de temps, c'est YANG. Comprendre comment naviguer dans l'arborescence et construire le bon chemin pour souscrire à la bonne donnée. Ce n'est pas compliqué une fois qu'on a saisi la logique, mais tant qu'on ne l'a pas, on tâtonne sans savoir si on cible le bon nœud.

Au final c'est le mode on-change qui m'a le plus parlé. Un flap d'interface qui se produit entre deux polls SNMP, personne ne le voit jamais. En on-change, il est capturé au moment où il arrive. Ça paraît un détail, mais ça change la façon de superviser : on passe d'une photo prise toutes les X secondes à un flux continu.

Un projet Python en groupe, où je me suis occupé de la partie PKI et cryptographie : génération et gestion des certificats, chiffrement des échanges, hachage des mots de passe.

J'aurais pu prendre le premier algorithme venu et passer à autre chose. J'ai préféré en tester plusieurs : RSA, ECDSA et Ed25519, pour voir ce qui les différencie vraiment. Taille de clé, coût de calcul, maturité de l'écosystème.

Ce qui m'a marqué, c'est que les performances varient énormément d'un algorithme à l'autre, bien plus que je ne l'imaginais. Et que si Ed25519 est considéré comme plus moderne, ce n'est pas une question de mode : clés courtes, signatures rapides, et une construction qui évite certains pièges d'implémentation où RSA et ECDSA peuvent se faire avoir. Ça ne veut pas dire qu'il faut l'utiliser partout pour autant, tout dépend de ce que supporte l'écosystème en face.

Surtout, ça m'a fait comprendre que la crypto n'est pas magique. Ce sont des compromis, et chaque choix se paie quelque part. Au final on est restés sur du TLS, mais au moins je savais pourquoi, et pas juste parce que c'est ce qu'on voit partout.

Un serveur perso, encore assez basique. Ce n'est pas une infra de production et ça n'en a pas la prétention : c'est l'endroit où je peux casser des choses sans que ça dérange personne.

Proxmox comme hyperviseur, des VM jetables pour tester, et Docker pour les services. C'est aussi ce qui héberge cette page.

J'apprends beaucoup plus vite en cassant qu'en lisant une doc. Quand un truc pète chez moi, je suis obligé de comprendre pourquoi, personne ne va le réparer à ma place. Et ça change le rapport aux erreurs : ici je peux me planter, ça n'a aucune conséquence. C'est exactement ce qu'il faut pour tester ce qu'on n'ose pas essayer ailleurs.