Ce que signifie réellement « sans BGP »
Le concept de cœur sans BGP existe depuis plusieurs décennies. Dans cette architecture, les routeurs situés en périphérie du réseau—les routeurs PE dans la terminologie MPLS—échangent et conservent les routes BGP. Les routeurs du cœur, ou routeurs P, ne portent pas ces routes.
Cette séparation modifie la manière dont le trafic traverse le réseau. Un routeur de cœur ne peut pas s’appuyer sur l’adresse IP d’un client pour prendre sa décision d’acheminement. Le routeur de périphérie doit donc savoir comment atteindre le prochain saut BGP grâce à un mécanisme d’encapsulation qui rend le paquet IP d’origine opaque pour le cœur.
L’article source examine ce principe dans le contexte de SRv6. L’objectif architectural reste simple :
Conserver la connaissance des routes clientes en périphérie, tout en fournissant au cœur les informations nécessaires au transport du trafic encapsulé entre les routeurs de bordure.
L’expression « sans BGP » décrit donc la relation du cœur avec les routes BGP. Elle ne signifie pas que le cœur fonctionne sans routage, sans connaissance topologique ou sans état opérationnel.
Pourquoi ce modèle peut simplifier un cœur multi-constructeurs
Une architecture fondée sur des rôles P et PE clairement définis peut réduire la quantité d’informations de routage clientes que les équipements du cœur doivent conserver. Elle crée aussi une frontière indépendante des constructeurs : les routeurs de périphérie gèrent la joignabilité BGP, tandis que les routeurs de cœur transportent un trafic rendu opaque par l’encapsulation.
Dans un environnement multi-constructeurs, cette frontière gagne à être décrite sous forme d’invariants plutôt qu’au moyen de la syntaxe d’un équipement particulier :
Les routes BGP restent sur les routeurs de périphérie prévus à cet effet.
Chaque prochain saut BGP requis est joignable par le mécanisme d’encapsulation.
L’acheminement dans le cœur ne dépend pas de l’examen des adresses IP clientes.
Le même comportement est préservé sur les chemins nominaux et de secours.
Cette approche ne supprime pas le travail d’interopérabilité. Elle clarifie le résultat attendu afin d’évaluer chaque implémentation par rapport à une même architecture.
Commencer par valider la topologie
L’examen des configurations ne suffit pas à démontrer qu’un cœur sans BGP fonctionnera comme prévu. Les opérateurs ont d’abord besoin d’une topologie exacte indiquant quels équipements assurent le rôle de périphérie, lesquels appartiennent au cœur et quels chemins relient ces différents éléments.
La validation doit notamment couvrir :
La classification explicite de chaque routeur en tant que nœud de périphérie ou de cœur.
Les chemins reliant tous les routeurs de périphérie qui échangent de la joignabilité BGP.
Les chemins alternatifs susceptibles d’être utilisés après la défaillance d’un lien ou d’un nœud.
Tout équipement inattendu qui aurait besoin de connaître les routes clientes pour acheminer le trafic.
Les écarts entre l’architecture documentée et les liens ou rôles réellement déployés.
La topologie en situation de panne compte autant que la topologie nominale. Le chemin principal peut respecter la séparation prévue, alors qu’un chemin de secours traverse un équipement dont le rôle ou la configuration diffère.
Contrôler les politiques de routage et d’encapsulation
Il faut ensuite vérifier que les politiques correspondent bien à l’architecture. La question n’est pas seulement de savoir si les sessions BGP sont établies, mais si les informations BGP restent limitées à la couche de périphérie prévue.
Les opérateurs doivent vérifier que :
Les routes BGP sont échangées uniquement par les routeurs chargés de la fonction de périphérie.
Les politiques de routage produisent les relations de prochain saut attendues.
Chaque routeur de périphérie peut résoudre les prochains sauts BGP nécessaires au moyen du mécanisme d’encapsulation choisi.
Les évolutions de politique n’introduisent pas de dépendance aux routes clientes dans le cœur.
Une intention équivalente est mise en œuvre sur les différentes plateformes constructeurs.
Dans un réseau hétérogène, il vaut mieux comparer les résultats que supposer que des fonctions portant des noms similaires ont exactement le même comportement. L’état cible doit être documenté indépendamment des configurations propres à chaque équipement.
Prouver l’état réel de l’acheminement
Une configuration correcte en apparence sur le plan de contrôle ne suffit pas. Les opérateurs doivent également vérifier le comportement obtenu dans le plan d’acheminement.
Les contrôles utiles comprennent :
La confirmation que les routeurs de périphérie d’entrée appliquent l’encapsulation attendue.
Le suivi du trafic sur le chemin prévu dans le cœur.
La vérification que les routeurs de cœur acheminent les paquets sans utiliser l’adresse IP cliente.
La confirmation que le bon routeur de périphérie de sortie reçoit et traite le trafic.
La répétition de ces contrôles lors de défaillances représentatives de liens et de nœuds.
La comparaison des chemins observés avec la topologie approuvée.
Ces essais doivent aller au-delà d’un simple test de joignabilité. Ils doivent démontrer que la séparation architecturale entre le routage en périphérie et le transport dans le cœur reste intacte lorsque les conditions changent.
Comment ConnectMyAssets contribue
ConnectMyAssets fournit une couche opérationnelle sur site et indépendante des constructeurs pour documenter et maîtriser l’infrastructure qui entoure cette architecture.
Dynamic CMDB et Topology consignent les rôles P et PE, les relations entre équipements ainsi que les chemins physiques ou logiques. Les équipes peuvent ainsi comparer l’architecture prévue au réseau réellement déployé.
Backup & History conserve les versions des configurations et permet une restauration en un clic lorsqu’une modification de politique en périphérie ou de configuration dans le cœur produit un résultat indésirable.
Compliance Engine permet d’évaluer les configurations au regard des règles d’architecture approuvées, notamment la séparation des responsabilités entre périphérie et cœur, ainsi que des contrôles NIS2, ISO 27001, PCI, CISA ou NIST de l’organisation.
Automation facilite des changements cohérents et contrôlés sur plusieurs plateformes, plutôt que de dépendre de procédures manuelles sans lien entre elles.
Credential Vault et SSH Bastion fournissent un accès maîtrisé pour collecter les configurations et les éléments opérationnels des routeurs.
Le suivi des CVE par actif et des fins de vie aide à intégrer l’exposition logicielle et le cycle de vie des plateformes dans les décisions concernant les équipements qui assurent des rôles critiques de périphérie ou de cœur.
AI Insights, exécuté localement, peut contribuer à l’analyse des informations d’infrastructure sans transférer ces données opérationnelles vers un service cloud.
ConnectMyAssets ne remplace ni les tests au niveau des paquets ni la validation des protocoles. La plateforme aide à relier la topologie, l’historique des configurations, les preuves de conformité, les risques associés aux actifs et l’exécution des changements à une architecture documentée commune.
Source : ipSpace.net
