Concevoir avant de configurer : la leçon d'une architecture multi-sites
VLAN, VRF, BGP/OSPF, VPN IPSEC : retour sur la conception d'un réseau interconnectant plusieurs sites, et sur l'erreur qui coûte le plus cher sauter l'étape du schéma.
Il y a une tentation, quand on maîtrise la ligne de commande, de vouloir configurer directement. Ouvrir un terminal, taper les premières routes, ajuster au fur et à mesure. Sur un routeur isolé, ça passe. Sur une architecture multi-sites, ça se paie cash.
Le problème à résoudre
L’objectif : interconnecter plusieurs sites distants de façon sécurisée et hautement disponible, en intégrant nativement la QoS et la supervision plutôt que de les ajouter après coup. Concrètement : des équipements Cisco pour le routage dynamique (BGP/OSPF), une segmentation logique par VLAN et VRF pour isoler les flux, et des tunnels VPN IPSEC site-à-site pour chiffrer les échanges le tout aligné sur les recommandations de l’ANSSI.
Où ça s’est compliqué
Le tunnel IPSEC, une fois monté, s’est révélé robuste dès le premier essai. Le vrai point de friction est venu d’ailleurs : des interactions OSPF inattendues entre VRF distinctes, qui ont demandé un troubleshooting long et méthodique reprise du modèle OSI couche par couche pour isoler l’origine du problème.
En reconstituant la chronologie après coup, la cause racine était simple : l’absence d’un schéma logique détaillé avant de commencer à taper la configuration. Le plan d’adressage s’est construit progressivement, au fil des besoins, plutôt que d’être figé en amont.
La règle que j’applique maintenant
Sur toute architecture qui dépasse un seul routeur, la phase de conception sur papier (ou sur un outil de schématisation) précède désormais systématiquement la phase de configuration :
- Schéma physique et logique complet, VLAN/VRF et plan d’adressage inclus.
- Politique de sécurité définie avant d’allumer le premier équipement (quels flux sont autorisés, par où, chiffrés comment).
- Configuration, puis validation par une maquette de démonstration (proof of concept) avant tout déploiement réel.
Pourquoi ça compte au-delà du réseau
Ce n’est pas une leçon spécifique à BGP ou aux VRF. C’est une leçon sur la complexité en général : plus un système a de composants qui interagissent, plus le coût d’une improvisation grandit de façon non linéaire. Un schéma clair ne remplace pas la compétence technique, mais il évite de découvrir un problème d’architecture à l’étape la plus coûteuse pour le corriger : en production.