La validation du réseau : une première étape vers une architecture basée sur l’intention

Détermination de l’intention du réseau

Chez NetCraftsmen, nous menons beaucoup de projets d’évaluations de réseaux. Le client dispose rarement d’une documentation détaillée sur la conception de son infrastructure, et même lorsque c’est le cas, je ne me souviens pas avoir jamais vu de documentation sous une forme qui pourrait être utilisée pour vérifier automatiquement l’intention du réseau. Pourtant, il existe plusieurs sources d’information qui peuvent être utilisées pour déterminer l’intention du réseau.

• Intention dérivée de la conception initiale du réseau. Le design d’un réseau doit spécifier les éléments de base, tels que les connexions physiques ; les domaines de broadcast de niveau 2, comme domaines Spanning Tree ; la topologie en étoile ; les domaines d’agrégation de routes ; les niveaux de redondance ; les domaines de sécurité ; les taps réseau pour le diagnostic.
• Intention liée à la configuration du réseau. Les critères de design initiaux d’un réseau déterminent sa configuration. Vous devez admettre qu’il y aura des erreurs durant le processus traduction de l’architecture du réseau dans la configuration réelle du réseau. Vous devrez valider que l’intention implicite de la configuration correspond réellement à l’intention de conception.
• Intention de sécurité. Exprimée en termes de connectivité positive (ou autorisée) et de connectivité négative ou refusée. Vous devez planifier la collecte d’informations sur la connectivité des paquets et sur la connectivité de routage.
• Intention métier. L’intention ultime est de savoir si certaines entités informatiques d’entreprise peuvent communiquer entre elles. Une application web type exigera que le tiers web communique avec le tiers applicatif, qui devra lui-même communiquer avec le tiers de base de données. Mais vous ne souhaitez sans doute pas que le réseau de contrôle des installations d’un bâtiment puisse communiquer avec des applications web destinées vos clients.

Les informations en matière d’intention devraient être stockées dans un référentiel de conception, généralement une base de données, où elles pourront être utilisées par le système de validation. Deux outils open source fournissent les fonctionnalités de base nécessaires pour les parties d’un système basé sur les intentions : Network Source of Truth (NSoT) et NetBox. La documentation de NetBox met l’accent sur la source de ses informations :

« NetBox a pour but de représenter l’état souhaité d’un réseau par rapport à son état opérationnel. En tant que telle, l’importation automatisée de l’état du réseau en direct est fortement déconseillée. Toutes les données créées dans NetBox doivent d’abord être vérifiées par un humain pour garantir leur intégrité. NetBox peut alors être utilisé pour alimenter les systèmes de surveillance et d’approvisionnement avec un haut degré de confiance ».

Notez que le réseau lui-même ne devrait pas être utilisé pour déterminer l’intention. Par exemple, si nous examinons le réseau et constatons que le commutateur A, Gig0/1 est connecté au commutateur B, Gig0/48, nous ne pouvons déterminer si c’était l’intention. Initiale. Et si l’intention était Switch A, Gig01 > Switch B, Gig0/49, mais que le câblage a été mal installé ?

Le schéma de base de données d’un système basique comme ceux mentionnés ci-dessus devra être étendu pour englober toutes les sources d’intention. Je recommande de commencer par les niveaux 1 à 3, ce que les systèmes ci-dessus peuvent fournir. Malheureusement, il y a peu de moyens d’automatisation qui peuvent aider à déterminer l’intention de conception originale d’un grand réseau.

Vous constaterez également que certaines choses deviennent rapidement très compliquées, par exemple lorsque les processus métier nécessitent une certaine connectivité, alors que les pratiques de sécurité exigent une séparation. Lorsque les systèmes deviennent si complexes qu’il n’est pas facile d’expliquer comment ils devraient fonctionner ensemble, il faut les redessiner d’une manière qui permette d’en séparer la complexité. (Voir les exposés de Russ White sur la complexité du réseau.)

Validation du réseau 

Une fois que vous avez recueilli les données d’intention de réseau, vous avez besoin de valider le réseau pour déterminer qu’il fonctionne comme vous l’aviez prévu.

Vérifiez d’abord la connectivité physique et remontez la pile de protocoles. Ce qui suit est une bonne séquence. L’automatisation peut être appliquée à ces tâches. J’ai constaté que de tels systèmes ne devraient signaler que les défaillances. La collecte de données « bavardes » ne fait qu’ajouter à la charge de travail ; il vaut mieux réduire le volume de données générées pour faciliter l’établissement des priorités et le traitement des échecs.

• Connectivité aux niveaux 1 et 2. Les équipements sont-ils câblés correctement et dans l’ordre correct pour ce qui concerne les VLAN, les sous-réseaux, le routage virtuel et les mécanismes de forwarding ? Ce sont des contrôles de base à effectuer en matière de paramétrage des interfaces et des relations de voisinage. Il est aussi important de contrôler des points comme l’agrégation de liens (EtherChannel, LACP…), les interfaces de secours ou les liens VRP.
• Connectivité de niveau 3. Le routage fonctionne-t-il correctement ? Vérifiez que les itinéraires souhaités existent, ainsi que les itinéraires qui ne devraient pas exister. Par exemple, les réseaux peuvent avoir de nombreux routeurs dont la route par défaut est une entrée de table de routage statique, ce qui n’est pas bon, par opposition à une entrée dynamique à la bordure d’un réseau de stub, ce qui est la bonne approche. Les paramètres de routage ECMP devraient également être vérifiés.
• Niveau 4 et plus. Des tests des chemins actifs et des transactions synthétiques peuvent être utilisés pour valider la connectivité de l’entreprise et pour fournir des alertes si les temps de transaction dépassent les critères de conception. Ces contrôles peuvent également fournir des alertes sur l’existence de connectivités indésirables qui peuvent ne pas être visibles à travers les contrôles de routage de base. 

La validation du réseau peut être mise en œuvre à l’aide de plusieurs mécanismes différents :

• Un processus manuel. Ce mécanisme n’est évidemment pas très utile. Il est utile d’identifier le processus à utiliser pour valider quelque chose de complexe, mais le processus lui-même devrait alors être automatisé d’une certaine façon.
• Un système d’administration de réseau. De nombreux systèmes d’administration permettent de configurer des règles personnalisées pour générer des alertes. Chercher des moyens d’automatiser la maintenance des contrôles de connectivité aux niveaux 1 et 2 dans le système d’administration, grâce aux informations contenues dans la base de données « Network Source of Truth ».
• Scripts d’automatisation. Les scripts Python, Ansible, SaltStack et les API REST sont autant d’outils utilisables pour automatiser la validation des réseaux. Étant donné que ces outils peuvent également être utilisés pour automatiser les processus de configuration et de changement, il est également utile de les utiliser pour la validation.
• D’autres mécanismes ? Il existe de nouveaux outils et de nouvelles technologies qui fournissent des mécanismes aux niveaux supérieurs de la pile de validation du réseau. Un exemple est Veriflow, dont le logiciel contient un langage qui permet de créer des vérifications simples des relations réseau.

Nous n'en sommes qu'au début du chemin

Nous n’en sommes qu’au début de la phase d’adoption des réseaux à base d’intention et des outils de validation du réseau. Pour l’instant, les outils sont basiques et leur utilisation demande des efforts supplémentaires. La bonne nouvelle, c’est que cela nous permet de faire un premier pas dans le processus de validation de l’intention du réseau par rapport au réseau tel qu’il est construit. Il y a de nouveaux processus que nous devons apprendre. Pensez-y comme un voyage qui nous permettra éventuellement de gérer nos réseaux de manière plus robuste.