Des raccordements routés au VLAN étendu
Le dernier scénario de l’atelier Segment Routing d’ITNOG10 associe des services EVPN à un cœur SR-MPLS. Il reprend la topologie de laboratoire utilisée dans les précédents scénarios consacrés aux services, mais remplace deux sous-réseaux entre PE et hôtes par un VLAN étendu.
Ce changement modifie la démarche de validation. Il ne suffit plus de contrôler des raccordements routés distincts : les équipes doivent également confirmer que le service Ethernet est représenté de manière cohérente sur les deux équipements de bordure et correctement transporté par le cœur sous-jacent.
À haut niveau, l’architecture sépare trois fonctions :
EVPN représente et distribue les informations du service entre les équipements de bordure concernés.
SR-MPLS assure le transport à travers le cœur.
Le VLAN étendu présente le service Ethernet sur des points de raccordement géographiquement ou logiquement distincts.
Cette séparation est utile, mais elle impose d’examiner plusieurs couches conjointement lors d’un déploiement ou d’un dépannage.
Les éléments à valider
Une validation fiable doit mettre en relation la topologie prévue, les configurations enregistrées et l’état opérationnel actuel. L’analyse d’une seule couche peut masquer une incohérence située ailleurs.
1. Topologie physique et logique
Il faut d’abord identifier le chemin complet du service :
Les points de raccordement côté hôtes
Les équipements PE participant au service EVPN
Les nœuds du cœur assurant le transport SR-MPLS
Les liaisons et interfaces entre chaque couche
Le VLAN étendu entre les sites de bordure
La représentation topologique doit distinguer le service Ethernet côté client du chemin de transport sous-jacent. Cette séparation aide à déterminer si une panne se situe dans l’accès, dans le service EVPN ou dans le cœur SR-MPLS.
2. Cohérence des configurations
L’examen des configurations doit déterminer si les deux extrémités expriment le même service attendu, malgré les différences de syntaxe entre constructeurs. Les contrôles utiles portent notamment sur :
L’affectation du VLAN et des interfaces sur chaque point de raccordement
La configuration du service EVPN sur les équipements de bordure participants
La configuration de routage et MPLS requise par l’architecture du cœur
Les relations de voisinage et identifiants d’équipements référencés par le service
Les écarts inattendus par rapport à la dernière configuration connue comme fonctionnelle
Dans un réseau multiconstructeur, une intention identique peut apparaître sous des formes très différentes dans les configurations en ligne de commande. Il faut donc examiner à la fois la configuration brute et une représentation normalisée de l’intention de service.
3. État opérationnel
Une configuration correcte ne garantit pas que le service fonctionne. Les équipes doivent aussi contrôler l’état réel de chaque couche :
État des interfaces côté hôtes et du VLAN
État du plan de contrôle EVPN sur les équipements de bordure
Joignabilité entre les nœuds participants
État du transport MPLS dans le cœur
Informations de transfert associées au service Ethernet étendu
L’objectif consiste à suivre toute la chaîne de dépendances, depuis le circuit d’accès jusqu’au plan de contrôle du service, puis au transport dans le cœur.
Une méthode de validation multiconstructeur
Une procédure reproductible évite de traiter chaque équipement comme un cas de dépannage isolé.
Cartographier le service attendu. Recenser les hôtes, interfaces d’accès, VLAN, équipements PE et chemin prévu dans le cœur.
Capturer les configurations actuelles. Conserver les configurations concernées avant toute modification.
Comparer les définitions aux deux extrémités. Vérifier que le service étendu est représenté de manière cohérente malgré les différences de syntaxe.
Valider le cœur séparément. Confirmer le fonctionnement du transport SR-MPLS avant d’attribuer une panne à EVPN.
Examiner l’état EVPN. Vérifier que les équipements de bordure disposent des informations opérationnelles attendues pour le service.
Tester depuis les points de raccordement. Valider le service côté hôtes au lieu de s’appuyer uniquement sur les contrôles du cœur.
Corréler les pannes avec l’historique des changements. Si le service fonctionnait auparavant, identifier les modifications apportées à tous les équipements de sa chaîne de dépendances.
Le principe essentiel est la corrélation : la topologie, les configurations et l’état opérationnel doivent décrire le même service de bout en bout.
Comment ConnectMyAssets facilite la validation
ConnectMyAssets fournit une plateforme sur site et indépendante des constructeurs pour gérer l’infrastructure qui prend en charge un service EVPN sur un cœur SR-MPLS.
Le module Topology aide à cartographier les équipements de bordure, les nœuds du cœur, les interfaces et les dépendances du service, tous constructeurs confondus.
La Dynamic CMDB maintient les informations sur les actifs et leurs relations en phase avec l’environnement géré.
Backup & History conserve les versions des configurations, met en évidence les changements et permet un retour arrière en un clic lorsqu’un déploiement provoque un incident.
Automation & ZTP facilite des processus reproductibles de collecte et de validation, sans imposer un traitement manuel de chaque plateforme.
Le Compliance Engine peut contrôler les configurations au regard des politiques internes et de référentiels tels que NIS2, ISO 27001, PCI, CISA et NIST.
AI Insights, exécuté localement, peut assister l’analyse des informations d’infrastructure tout en maintenant les opérations sur site.
Dans un déploiement EVPN multiconstructeur, l’intérêt pratique réside dans la création d’un référentiel opérationnel commun. Les équipes peuvent relier la topologie du service à l’historique des configurations et à l’état des actifs, plutôt que de naviguer entre des vues cloisonnées par équipement.
Pour conclure
EVPN sur un cœur SR-MPLS montre comment les couches de service et de transport peuvent être combinées tout en restant distinctes sur le plan opérationnel. Le scénario de VLAN étendu de l’atelier ITNOG10 rappelle également que la validation de bout en bout doit franchir les limites entre ces couches.
Les équipes doivent considérer l’accès, les informations EVPN et le transport SR-MPLS comme les maillons d’une même chaîne de dépendances. Dans un environnement multiconstructeur, une topologie normalisée, l’historique des configurations et une collecte reproductible de l’état réseau rendent cette validation beaucoup plus maîtrisable.
Source : ipSpace.net
