Puis-je utiliser des commutateurs plus anciens de la série 9300 (non-EX/FX) comme Border Gateways ?

Des ASIC Cloud Scale comme le FX2 ou le GX sont requis car ils supportent la « double lookup » VXLAN-vers-VXLAN nécessaire à un BGW. Les ASIC plus anciens ne peuvent pas effectuer l'encapsulation et la décapsulation nécessaires en un seul passage à la vitesse de ligne.

Le vPC est-il requis pour la haute disponibilité du Border Gateway ?

Anycast BGW est considérablement supérieur pour la scalabilité. Il permet à plusieurs BGWs de partager une IP virtuelle, activant l'ECMP L3 pour le trafic inter-site et évitant les limitations propriétaires et les risques de domaine de panne d'un vPC Peer-Link.

Quelles sont les exigences spécifiques pour l'Inter-Site Network (ISN) ?

L'ISN n'a besoin que de fournir la joignabilité IP et de supporter une MTU d'au moins 1550 octets. Il n'a pas besoin d'être compatible VXLAN ou EVPN ; il route simplement les paquets encapsulés entre les VTEP BGW.

Que fait réellement la commande 'rewrite-evpn-rt-asn' ?

La commande 'rewrite-evpn-rt-asn' permet à un BGW de ré-originater des routes EVPN avec son propre ASN, ce qui est crucial pour les conceptions multi-AS où les Route Targets doivent être mappés correctement entre les domaines BGP indépendants.

Dois-je utiliser l'Ingress Replication ou le Multicast pour le trafic BUM à travers les sites ?

Pour la plupart des entreprises, l'Ingress Replication (IR) est la méthode préférée. Elle simplifie la configuration de l'ISN en utilisant le BGW pour répliquer le trafic BUM en unicast vers les sites distants, supprimant le besoin de PIM ou d'un RP dans le cœur de réseau.

Maîtriser Cisco Nexus 9000 VXLAN EVPN Multi-Site : Guide de conception 2026

L'ère du domaine Layer 2 « étiré » via OTV ou VPLS est révolue, et si vous comptez toujours sur le vPC back-to-back pour la connectivité multi-pod, votre rayon de blast est une bombe à retardement. En 2026, la seule architecture défendable pour interconnecter des data centers distribués haute performance est le modèle Nexus 9000 VXLAN EVPN Multi-Site, tirant parti des fonctions Border Gateway (BGW) matérielles pour localiser les domaines de panne tout en maintenant une mobilité de workload transparente.

L'illusion du "Stretched Fabric"

Pendant des années, les architectes réseau ont cherché le « Saint Graal » d'un fabric unique et unifié à travers plusieurs sites physiques. Cette approche, bien que simplifiant théoriquement le vMotion et la cohérence IP, a créé un environnement fragile de « partage de destin ». Une seule tempête BUM (Broadcast, Unknown Unicast, Multicast) dans le Site A pouvait, et souvent le faisait, faire tomber les Sites B et C simultanément. L’implémentation NX-OS de Cisco pour VXLAN EVPN Multi-Site résout ce problème en découplant les protocoles de site internes de l'Inter-Site Network (ISN).

Dans une conception Multi-Site standard, chaque site opère son propre plan de contrôle BGP EVPN indépendant. Les Border Gateways (BGW) agissent comme le point de terminaison pour les tunnels VXLAN intra-site et le point d'origine pour les tunnels inter-sites. Contrairement à l'étirement traditionnel, le BGW réécrit le Next-Hop et modifie les Route Targets, assurant que l'apprentissage MAC/IP est isolé. Si une boucle se produit dans le Site A, les mécanismes Spanning Tree ou de storm control au sein de ce site la capturent avant qu'elle ne se propage via la liaison ISN à haute latence.

Sélection matérielle : Cloud Scale ou rien

N'essayez pas d'exécuter Multi-Site sur des Nexus 9300 de première génération. Vous avez besoin des ASIC Cloud Scale (EX, FX, FX2, FX3, ou les séries plus récentes GX/GX2) pour supporter la terminaison VXLAN-vers-VXLAN requise et les entrées TCAM nécessaires pour le mapping L3VNI et L2VNI. Pour le rôle de Border Gateway spécifiquement, le Nexus 9364C-GX ou le 9336C-FX2 sont nos standards d'or pour la densité 100G/400G.

La série 9300-GX est particulièrement critique en 2026 alors que nous nous dirigeons vers des backbones 400G. Ils fournissent les buffers profonds nécessaires pour gérer les micro-bursts qui se produisent lors de la transition des spines internes à large bande passante vers des circuits ISN potentiellement moins rapides. Évitez la série 9200 pour les rôles de BGW ; la parité des fonctionnalités n'est tout simplement pas suffisante pour les déploiements EVPN Multi-Site complexes.

Architecture du Border Gateway (BGW)

Le Border Gateway est le composant le plus critique de cette conception. Vous avez deux modèles de déploiement principaux : BGW Distribué (Spines en tant que BGW) ou BGW Dédié (Leafs en tant que BGW). Chez TechLeague, nous recommandons presque exclusivement le modèle BGW Dédié (Border Leafs) pour les environnements d'entreprise à grande échelle. Bien que l'utilisation des Spines comme BGWs économise quelques unités d'espace en rack, cela force vos spines à maintenir une table de routage BGP complète pour le monde extérieur, augmentant la pression CPU et compliquant votre limite de management.

Haute disponibilité : Anycast BGW vs. vPC BGW

Les ingénieurs à l'ancienne essaient toujours de mettre leurs BGWs dans une paire vPC. C'est une erreur. VXLAN EVPN Multi-Site supporte le modèle Anycast BGW (adresse IP virtuelle). Dans cette configuration, plusieurs BGWs partagent la même adresse IP anycast pour le tunnel VXLAN endpoint (VTEP). L'utilisation d'Anycast BGW permet jusqu'à 6 ou 8 chemins ECMP à travers l'ISN, offrant une résilience et un débit bien supérieurs à un cluster vPC à deux nœuds.


evpn multisite border-gateway 100
  delay-restore time 30
  provision-model anycast-gw
  multisite-id 1

En utilisant le modèle anycast, vous éliminez le besoin d'un vPC Peer-Link entre les gateways, ce qui a traditionnellement été un point de défaillance dans les environnements sensibles à la convergence. Si un BGW tombe en panne, la convergence BGP sur l'ISN redirige simplement le trafic vers les autres membres anycast sans nécessiter de négociation LACP complexe.

L'Inter-Site Network (ISN) : Cessez de le sur-compliquer

L'ISN est souvent la partie la plus incomprise de la conception. Il n'a pas besoin de parler EVPN. En fait, il ne devrait pas. L'ISN est purement un support de transport qui fournit la connectivité IP entre les VTEP BGW. Il doit supporter MTU 1550+ (pour accueillir l'en-tête VXLAN de 50 octets) et exécuter un IGP comme OSPF ou IS-IS.

Les BGWs établissent des peerings Multi-Hop MP-BGP EVPN entre eux via l'ISN. Nous préconisons fortement l'utilisation de BGP Peer Groups pour gérer ces connexions, surtout lors d'un scaling au-delà de trois sites. Voici un extrait de configuration BGW typique pour le peering ISN :


router bgp 65001
  neighbor 10.255.255.10 remote-as 65002
    description Peer_to_Site_B_BGW
    update-source loopback1
    ebgp-multihop 5
    address-family l2vpn evpn
      send-community extended
      rewrite-evpn-rt-asn

La commande rewrite-evpn-rt-asn est essentielle. Elle permet au BGW de traduire les Route Targets entre les sites, garantissant que les labels sont correctement interprétés lorsque le trafic transite par l'ISN.

Multicast L3 et gestion du trafic BUM

Gérer le trafic BUM à travers les sites sans faire fondre votre WAN est ce qui différencie un administrateur junior d'un ingénieur senior. Vous avez deux choix : Ingress Replication (IR) ou Local-Bias Multicast. Pour les conceptions 2026, l'Ingress Replication avec optimisations Multi-Site est la norme, sauf si vous avez des exigences multicast à très haut débit spécifiques. L'IR crée des copies unicast individuelles de paquets BUM pour chaque site distant, mais le BGW est suffisamment intelligent pour n'envoyer qu'une seule copie au site distant, que le BGW distant réplique ensuite localement vers ses leafs. Cette « Head-end Replication » réduit considérablement la charge de bande passante sur votre ISN.

Si vous devez utiliser le Multicast dans le cœur de réseau, assurez-vous que votre ISN supporte PIM-BSR ou PIM-RP. Cependant, la complexité de gérer un RP à travers plusieurs domaines administratifs l'emporte généralement sur les gains d'efficacité pour 90% des entreprises.

Sécurité et politique : Micro-segmentation avec Group-Based Policy (GBP)

VXLAN EVPN standard ne transporte que le VNI et les informations L2/L3. Si vous souhaitez maintenir une posture de sécurité à travers les sites, vous devez implémenter VXLAN-GPO (Group-Based Policy). Cela vous permet de transporter les SGTs (Scalable Group Tags) dans l'en-tête VXLAN. Lorsqu'un utilisateur du Site A (SGT 10) communique avec un serveur du Site B, le BGW préserve cette balise. Cela permet à vos firewalls ou aux leafs Nexus du Site B d'appliquer une politique basée sur le SGT plutôt que sur une adresse IP qui aurait pu changer.

Comme nous l'avons détaillé dans notre guide sur Nexus ACI vs. Standalone EVPN, l'orchestration manuelle des SGTs dans NX-OS est le principal « point de douleur » qui pousse souvent les clients vers ACI. Cependant, si vous êtes un utilisateur CLI, rester avec NX-OS Multi-Site vous offre une meilleure visibilité sur le plan de contrôle et évite la nature « boîte noire » de l'APIC.

Vérification et réalité opérationnelle

La résolution de problèmes Multi-Site exige une maîtrise des commandes show nve multisite. Vous ne vérifiez pas seulement l'adjacence ; vous vérifiez si le BGW annonce réellement le bon site-id. Un point de défaillance courant est l'inadéquation des Site-IDs au sein du même fabric, ce qui amène le BGW à désactiver le VIP Inter-Site pour éviter les boucles.


# Vérifier le statut du BGW
show nve multisite border-gateway
# Vérifier la joignabilité du site distant
show bgp l2vpn evpn summary
# Vérifier le mapping VNI à travers les sites
show nve vni

Attendez-vous à ce que la latence de votre ISN joue un rôle dans la convergence BGP. Ajustez vos timers keepalive et holdtime, mais ne descendez pas en dessous de la seconde, sauf si vous disposez d'une liaison de fibre noire dédiée. Sur un transit WAN standard de 10ms-20ms, un keepalive de 3 secondes est le « sweet spot » pour éviter les flaps lors d'événements de jitter mineurs.

Conclusion

Cisco Nexus 9000 VXLAN EVPN Multi-Site est la seule façon de faire évoluer les data centers modernes sans hériter des risques d'un domaine Layer 2 géant et plat. En utilisant des BGWs Anycast et des ASICs Cloud Scale, vous construisez un environnement résilient et multi-homed qui supporte les exigences à haute vitesse de 2026. Si votre conception actuelle repose sur des vPC étirés ou des overlays OTV complexes, il est temps de changer de plateforme. Pour une revue experte de la conception de votre fabric ou pour faire appel à une équipe d'ingénieurs Tier-3 pour votre déploiement, visitez notre page tarification techleague.io pour voir comment nous pouvons accélérer la modernisation de votre infrastructure.