Multi-tenant, sécurité et automatisation du fabric
Exploiter EVPN/VXLAN pour la ségrégation multi-tenant et intégrer l'automatisation dans l'exploitation du fabric.
À retenir
- Le L3VNI associé à une VRF permet le multi-tenant avec isolation, y compris en cas d'IP qui se chevauchent.
- Les route-targets filtrent les routes EVPN importées/exportées entre tenants et sécurisent l'overlay.
- L'authentification des sessions BGP et le contrôle des ASN autorisés protègent contre les VTEP non fiables.
- L'automatisation (Ansible, fabrics pilotés par intention, télémétrie streaming) réduit les erreurs à l'échelle.
- Versionner les configurations générées permet un retour arrière rapide en cas d'incident après déploiement.
Isoler les locataires avec VRF et VNI L3
Dans un fabric multi-tenant, chaque client ou domaine applicatif doit être isolé au niveau routage, pas seulement au niveau commutation. EVPN/VXLAN combine deux niveaux d'identifiants :
- VNI L2 : identifie un segment de couche 2 (équivalent VLAN étendu) à l'intérieur d'un tenant.
- VNI L3 (L3VNI) : identifie un domaine de routage associé à une VRF, permettant à plusieurs tenants de router en parallèle sans se voir, y compris avec des plages IP qui se chevauchent (overlapping IP).
show vrf
show bgp l2vpn evpn route-type ip-prefix
Point clé
l'isolation multi-tenant s'obtient en associant chaque VRF à un L3VNI distinct et en filtrant les routes EVPN de type 5 (prefix routes) par route-target, exactement comme dans un déploiement MPLS/VPN classique.
Sécurité du plan overlay
Le fabric doit filtrer les annonces EVPN reçues d'un leaf compromis ou mal configuré : les route-targets (import/export) définissent qui peut apprendre quelles routes, et des politiques BGP (route-maps, prefix-lists) limitent les préfixes acceptés d'un VTEP donné. Une isolation stricte entre l'underlay (jamais exposé aux tenants) et l'overlay (seul plan visible des applications) est indispensable.
Attention
un VTEP mal authentifié qui rejoint le fabric BGP EVPN peut potentiellement annoncer des routes MAC/IP usurpées ; l'authentification des sessions BGP (MD5 ou TCP-AO) et le contrôle strict des ASN autorisés à peer sont des mesures de base non négociables.
Automatisation : sortir du CLI manuel
À l'échelle d'un fabric de plusieurs dizaines de leaf et spines, la configuration manuelle par CLI devient une source d'erreurs et d'incohérences. Les approches courantes :
- Templates déclaratifs (Ansible, Nornir) générant la configuration BGP underlay et EVPN overlay de façon homogène sur tous les switches.
- Fabrics pilotés par intention (Cisco NDFC/ACI, Arista CloudVision, Apstra) qui calculent la configuration cible à partir d'un modèle de topologie déclaré, puis vérifient en continu la conformité (day-2 operations).
- Télémétrie streaming (gNMI, plutôt que du SNMP en polling) pour détecter en quasi temps réel une dérive de configuration ou une dégradation de lien.
Sur le terrain
l'ajout d'un nouveau leaf dans un fabric automatisé doit être un événement standardisé (câblage, attribution d'IP loopback, peering BGP, appartenance EVPN) déclenché par un playbook, pas une succession de commandes tapées à la main un soir de déploiement — c'est là que se cachent la majorité des erreurs de mise en production.
Vérifier la cohérence après un changement
show bgp l2vpn evpn summary
show vxlan vni
show mac address-table vlan <id>
Après tout changement de configuration EVPN, comparez le nombre de VTEP actifs attendu avec celui réellement vu par chaque leaf, et vérifiez qu'aucun VNI n'apparaît orphelin (annoncé sans VTEP distant correspondant), signe fréquent d'une erreur de route-target.
Astuce
conservez systématiquement une version antérieure fonctionnelle de la configuration générée par l'outil d'automatisation (git, versioning) : en cas de dérive après un déploiement EVPN, revenir à un état connu est bien plus rapide que de déboguer une politique de route-target en pleine incident.