Ingénieur réseau

Je commence par vérifier ce qui est le plus rapide à contrôler plutôt que de supposer d'emblée un problème de routeur. D'abord, je confirme le périmètre : est-ce un seul utilisateur, un seul sous-réseau, un seul site, ou tout le monde, car cela seul élimine déjà la majorité des causes possibles. Je vérifie l'état de la couche physique sur le port ou le lien concerné, puis la couche 2 avec un ping vers la passerelle par défaut, puis la couche 3 avec un traceroute pour voir exactement où le chemin se rompt. Je consulte le journal des changements récents avant de toucher à quoi que ce soit, car dans mon expérience, un changement effectué dans les dernières 24 heures est plus souvent la cause qu'une véritable panne matérielle. Une fois le nœud ou l'équipement défaillant isolé, je vérifie ses journaux et les compteurs d'interface pour repérer des erreurs, des pertes ou des problèmes de CRC plutôt que de deviner. Je note chaque étape au fur et à mesure, à la fois pour rester rigoureux sur ce que j'ai réellement écarté et pour que la personne suivante ne refasse pas mon travail.

OSPF est mon choix par défaut pour le routage interne au sein d'une seule organisation, car il converge rapidement, gère bien les changements de topologie et n'impose pas la charge de gestion des politiques que BGP exige. Je l'utilise à l'intérieur d'un campus ou d'un data center où tous les routeurs sont sous une même administration et où l'objectif est simplement le chemin le plus court et le plus efficace. BGP intervient dès que je route entre systèmes autonomes : connexion à un fournisseur d'accès, peering avec un réseau partenaire, ou WAN multi-sites où j'ai besoin d'un contrôle par politique sur les chemins empruntés par le trafic plutôt que du simple chemin le plus court. BGP me donne aussi des attributs de chemin comme l'AS-PATH et la préférence locale pour orienter le trafic de façon délibérée, ce qu'OSPF ne permet pas. En pratique, j'ai déjà fait fonctionner les deux ensemble : OSPF en interne, redistribué avec précaution vers BGP en bordure, avec un filtrage de routes pour qu'un changement de routage interne ne puisse pas fuiter accidentellement vers internet.

Je maintiens trois éléments à jour en permanence : un schéma de topologie qui reflète le réseau réellement en production, pas celui du design initial ; un système IPAM qui suit chaque sous-réseau, VLAN et allocation d'adresse pour qu'aucune adresse ne soit attribuée deux fois ; et un journal des changements lié à chaque déploiement de configuration, incluant qui l'a fait, pourquoi, et le plan de retour arrière. J'écris des runbooks pour tout ce qui se produit plus d'une fois, en particulier les étapes de réponse aux incidents, pour que la solution ne repose pas uniquement sur la mémoire d'une seule personne. J'ai vu des incidents durer trois fois plus longtemps simplement parce que la documentation ne correspondait plus à la réalité, donc je considère la mise à jour de la documentation comme faisant partie du changement lui-même, pas comme une tâche optionnelle après coup. Je compare le schéma de topologie au réseau réel chaque trimestre pour détecter les écarts avant qu'ils ne posent problème pendant un incident.

J'utilise des plateformes de supervision avec détection d'anomalies intégrée pour repérer des schémas de trafic ou des pics de latence qui sortent des références habituelles, ce qui permet de détecter les problèmes avant que les utilisateurs ne les signalent. Pour les tâches de configuration répétitives, comme déployer le même changement de VLAN ou d'ACL sur vingt commutateurs, j'utilise des playbooks Ansible et des scripts Python plutôt que de le faire manuellement, ce qui réduit aussi les incidents causés par des erreurs de frappe. Là où je ne délègue pas le contrôle, c'est pour tout ce qui touche à la sécurité ou aux clients : les changements de règles de pare-feu, les changements de politique BGP et tout ce qui touche à la bordure internet passent par une revue manuelle de ma part avant leur mise en production, quelle que soit la confiance accordée à l'automatisation. Je considère les outils assistés par IA comme efficaces pour la détection de motifs et l'exécution répétitive, et je garde mon propre jugement comme dernier contrôle sur tout ce qui pourrait mettre à terre un segment du réseau.

Lors d'une panne d'un commutateur cœur de réseau, un bâtiment entier a perdu la connectivité, touchant environ 400 utilisateurs pendant ce qui est devenu une interruption de 45 minutes. J'ai confirmé que la panne était isolée à ce commutateur en vérifiant que le commutateur redondant dans la pile était toujours actif mais ne faisait plus passer le trafic, ce qui pointait vers un problème de spanning tree plutôt qu'une panne matérielle. J'ai examiné la topologie du spanning tree et trouvé une valeur de priorité mal configurée suite à un changement effectué la veille, ce qui avait provoqué une boucle que les mécanismes de protection du commutateur combattaient sans la résoudre proprement. J'ai corrigé la valeur de priorité, forcé un recalcul du spanning tree, et confirmé que le trafic circulait normalement environ six minutes après avoir identifié la cause. Ensuite, j'ai rédigé le compte rendu de l'incident, ajouté une étape de relecture par un pair pour tout changement de priorité de spanning tree, et mis à jour le runbook pour que le prochain ingénieur reconnaisse le même symptôme plus rapidement.

Pendant une période de lenteur intermittente affectant une équipe commerciale avant un appel important avec un client, la directrice voulait un point toutes les quinze minutes et n'avait aucune patience pour le jargon technique. J'ai expliqué la situation comme un embouteillage sur une route précise entre leur bureau et internet, pas comme l'ensemble du réseau en panne, ce qui a fixé la bonne attente : la plupart des systèmes fonctionnaient normalement. J'ai donné un calendrier clair : nous savons où se situe la congestion, nous sommes en train de réacheminer le trafic, et nous attendons une résolution d'ici une heure. J'ai évité des termes comme perte de paquets ou MTU et j'ai plutôt décrit ce qu'ils allaient réellement remarquer, comme des pages qui chargent lentement plutôt que des pages qui ne chargent pas du tout. Une fois le problème résolu, j'ai confirmé avec un chiffre avant et après précis : la latence est passée d'environ 400 millisecondes à moins de 20, ce qui leur a donné quelque chose de concret plutôt que ma seule parole.

J'ai été appelé vers 2 heures du matin pour une session BGP instable avec notre fournisseur d'accès secondaire, qui coupait par intermittence notre chemin internet de secours. Ce n'était pas encore visible pour les clients puisque le lien principal fonctionnait toujours, mais une session BGP instable peut dégénérer rapidement si on la laisse sans surveillance. Je me suis connecté, j'ai vérifié l'interface pour des erreurs de couche physique, et je n'ai rien trouvé localement, ce qui pointait vers un problème côté fournisseur. J'ai ouvert un ticket auprès du fournisseur avec les horodatages précis et les compteurs d'erreurs, temporairement amorti la session pour arrêter l'instabilité qui générait un excès de bruit dans les journaux, et programmé un rappel pour relancer le fournisseur le lendemain matin s'il n'avait pas répondu. J'ai documenté toute la séquence dans notre canal d'incident pour que l'équipe ait le contexte sans avoir besoin de réveiller quelqu'un d'autre. Le fournisseur a confirmé un problème de fibre de son côté le lendemain, et j'ai clôturé le sujet en retirant l'amortissement une fois la session stabilisée.

Un VLAN est une construction de couche 2 : il segmente les domaines de diffusion au sein des commutateurs, de sorte que des équipements dans des VLANs différents ne voient pas le trafic de diffusion des autres même s'ils sont physiquement connectés au même commutateur. Un sous-réseau est une construction de couche 3 : un regroupement logique d'adresses IP qui détermine comment les décisions de routage sont prises. En pratique, je fais correspondre un sous-réseau à un VLAN comme convention standard, car cela simplifie le dépannage : si je connais le VLAN, je connais le sous-réseau, et inversement. La raison d'utiliser les deux ensemble plutôt qu'un seul est que les VLANs apportent l'isolation physique et de diffusion au niveau du commutateur, tandis que les sous-réseaux apportent la frontière de routage et de contrôle d'accès au niveau du routeur ou du pare-feu. Par exemple, je pourrais placer la finance et l'ingénierie sur des VLANs et des sous-réseaux séparés pour appliquer des politiques de pare-feu différentes à chacun sans aucune ambiguïté sur l'appartenance du trafic.

Je conçois autour de zones basées sur le niveau de confiance et la fonction plutôt que sur l'emplacement physique : une DMZ pour tout ce qui est exposé sur internet, une zone interne pour le trafic corporate général, et une zone restreinte pour les systèmes sensibles comme la finance ou les bases de données de production. Le trafic entre zones doit passer par un pare-feu, et j'écris les règles sur une base de refus par défaut, ce qui signifie que rien n'est autorisé sauf si c'est explicitement nécessaire, plutôt que de partir sur une base permissive et essayer de verrouiller plus tard. Chaque règle porte une description de qui l'a demandée et pourquoi, car une règle non documentée est la chose la plus difficile à supprimer sans risque deux ans plus tard. Je revois l'ensemble des règles chaque trimestre pour supprimer tout ce qui n'est plus nécessaire, car les ensembles de règles de pare-feu ont tendance à grossir et rarement à se réduire sans effort délibéré. Pour tout nouveau segment, je pense aussi au trafic est-ouest, pas seulement nord-sud, car beaucoup de vraies intrusions se propagent latéralement une fois entrées dans une seule zone de confiance.

Le réseau on-premise est en grande partie physique : je gère des commutateurs, des câbles et des modes de panne matérielle réels, et les décisions de routage sont liées à la topologie physique. Dans le cloud, le réseau est défini par logiciel : un VPC est un réseau logiquement isolé au sein d'un fournisseur, et le peering VPC permet à deux VPC de router du trafic entre eux de façon privée sans passer par internet public, mais ce n'est pas transitif : peerer A avec B et B avec C ne permet pas à A d'atteindre C sans une connexion de peering directe ou une passerelle de transit. J'ai utilisé des passerelles de transit pour relier plusieurs VPC entre eux plutôt que de construire un maillage complet de connexions de peering individuelles, ce qui devient ingérable au-delà de quelques VPC. Pour les architectures hybrides, j'ai configuré à la fois du VPN et des connexions dédiées comme Direct Connect vers l'on-premise, et la question de conception principale reste toujours la même : quelle est l'exigence de latence et de fiabilité, car le VPN sur internet convient pour des chemins de secours mais pas pour quoi que ce soit sensible à la latence.