Quelle est la limite de latence réelle pour un IPN ACI Multi-Pod ?

Cisco supporte officiellement jusqu'à 50ms RTT pour l'IPN. Cependant, pour toute conception qui étend les Bridge Domains Layer 2, une limite pratique de 10ms devrait être appliquée. Une latence supérieure à ce niveau augmente considérablement le risque de problèmes de performance d'application pour le trafic au sein du domaine de Broadcast étendu.

Le Nexus Dashboard Orchestrator (NDO) fait-il partie du data path ?

Non. NDO est une plateforme d'orchestration et de gestion de politiques purement Out-Of-Band. Il configure les clusters APIC dans chaque site, mais tout le trafic de données circule directement entre les commutateurs Spine des sites respectifs via l'Inter-Site Network (ISN). Une panne NDO n'affecte pas le trafic de données existant.

Puis-je exécuter Multi-Pod et Multi-Site simultanément ?

Oui, c'est une topologie supportée, bien que complexe. Un fabric Multi-Pod peut être configuré pour agir comme un "site" unique au sein d'une architecture ACI Multi-Site plus large. Cela est généralement utilisé pour consolider la gestion de deux pods proches avant de les connecter comme une seule entité logique à un site de Disaster Recovery distant.

Comment la licence diffère-t-elle entre Multi-Pod et Multi-Site ?

Multi-Pod ne nécessite que les licences standard ACI Premier ou Advantage pour les commutateurs Leaf ; il n'y a pas de licence supplémentaire pour Multi-Pod lui-même. Multi-Site nécessite des licences ACI pour les Leaf de chaque site PLUS des licences Nexus Dashboard et une licence d'application NDO spécifique (par exemple, N-D-ADV-S-GF) qui est échelonnée en fonction du nombre de sites et/ou de commutateurs Leaf gérés.

Que se passe-t-il avec le trafic inter-sites si NDO tombe en panne ?

Le trafic de données existant n'est absolument pas affecté. Les sessions BGP EVPN entre les sites restent actives et les endpoints appris via l'overlay sont maintenus. Le seul impact d'une panne NDO est l'incapacité d'apporter des modifications administratives aux politiques inter-sites tant que le cluster NDO n'est pas restauré.

PIM-Bidir est-il une exigence absolue pour l'IPN Multi-Pod ?

C'est la conception validée et recommandée par Cisco pour gérer efficacement le trafic BUM. Bien que vous puissiez techniquement le faire fonctionner avec d'autres modes Multicast comme PIM Sparse-Mode, cela complique la conception avec le placement des Rendezvous Points et des éventuels Traffic Trombones. Pour tout déploiement Greenfield, PIM-Bidir doit être considéré comme une exigence ferme.

Puis-je utiliser la dark fiber pour l'IPN Multi-Pod ?

Absolument. La dark fiber est un transport idéal pour un IPN, en particulier pour les connexions métropolitaines. Vous placeriez une paire de routeurs ou de commutateurs Layer 3 (comme les Catalyst 9500) à chaque extrémité de la fibre pour servir de périphériques IPN, puis construiriez le peering OSPF/PIM/BGP requis sur ce lien.

Cisco ACI Multi-Pod vs. Multi-Site : Choix d'architectures en 2026

Le choix entre Cisco ACI Multi-Pod et Multi-Site est une décision architecturale fondamentale dont les conséquences vont bien au-delà de la fiche technique. Trop souvent, cette décision est présentée comme une simple question de latence ou de scale. En réalité, le bon choix pour 2026 dépend d'une évaluation rigoureuse des domaines de panne, de la complexité opérationnelle et du Total Cost of Ownership. Multi-Pod offre une simplicité séduisante au prix d'un domaine de panne monolithique, tandis que Multi-Site offre une véritable isolation des pannes mais exige un niveau d'ingénierie plus élevé et un budget nettement supérieur. Mal choisir mène non seulement à de la technical debt, mais aussi à des pannes qui peuvent marquer une carrière.

Concepts architecturaux fondamentaux : Pods et Sites

Avant de comparer les extensions multi-fabric, il est essentiel d'avoir une compréhension précise des composants de base. L'ensemble du portefeuille ACI est construit sur une topologie Spine-Leaf Clos, mais la manière dont ces topologies sont gérées et interconnectées dicte l'architecture.

Le Fabric ACI unique : Un domaine de panne de référence

Un fabric ACI standard se compose d'un cluster d'au moins trois Application Policy Infrastructure Controllers (APICs), d'un ensemble de commutateurs Spine (par exemple, Nexus 9508 avec cartes de ligne Gen3 -FX3) et d'un ensemble de commutateurs Leaf (par exemple, Nexus 93180YC-FX3). Cet ensemble constitue un domaine administratif et de plan de contrôle unique. Un principe fondamental d'ACI est que tous les endpoints au sein du fabric sont à un seul saut les uns des autres du point de vue des politiques et de la reachability, grâce à l'overlay VXLAN. De manière critique, ce fabric unique est un domaine de panne unique. Un bug catastrophique dans le logiciel APIC (exécutant ACI version 6.0+) ou un effondrement du control plane du Council of Oracle Protocol (COOP) peut et va impacter l'ensemble du fabric.

ACI Multi-Pod : Le Fabric unique étendu

ACI Multi-Pod peut être considéré comme un fabric ACI standard "étiré" sur plusieurs emplacements physiques, ou "pods". Chaque pod est sa propre topologie Spine-Leaf. Cependant, tous les pods sont gérés par un *seul* cluster APIC, qui réside dans l'un des pods. Les pods sont connectés via un Inter-Pod Network (IPN) basé sur IP. Du point de vue de la gestion, c'est un seul fabric. Tous les objets de configuration —tenants, EPGs, Bridge Domains (BDs)— sont synchronisés sur tous les pods. Cela signifie que vous avez un Single Pane of Glass pour la gestion, mais cela signifie également que vous avez un domaine de panne unique, géographiquement distribué. Une défaillance du cluster APIC peut rendre toute l'infrastructure Multi-Pod instable.

ACI Multi-Site : Une fédération de Fabrics indépendants

ACI Multi-Site présente un paradigme fondamentalement différent. Chaque "site" est un fabric ACI complet et indépendant avec son propre cluster APIC dédié. Ces sites sont entièrement autonomes ; une défaillance dans Site1 n'a aucun impact opérationnel sur Site2. Les sites sont interconnectés via un réseau IP/MPLS ou VXLAN EVPN standard. La magie opère avec le Nexus Dashboard Orchestrator (NDO), anciennement Multi-Site Orchestrator (MSO). S'exécutant sur un cluster Nexus Dashboard séparé, NDO (version 4.2+) agit comme un moteur de fédération et d'orchestration de politiques. Un administrateur définit des templates et des politiques dans NDO, qui pousse ensuite les configurations correspondantes vers le cluster APIC local de chaque site. Il ne gère pas les fabrics en temps réel ; c'est une couche d'orchestration, pas un composant du control plane.

L'interconnexion : Détails IPN vs. ISN

Le réseau qui connecte vos pods ou sites n'est pas un détail d'implémentation trivial ; c'est un composant fondamental de l'architecture avec des exigences spécifiques et rigides.

Exigences de conception de l'IPN Multi-Pod

L'IPN est un réseau Layer 3 connectant les commutateurs Spine de chaque pod. Les Spines établissent des adjacences OSPF avec les périphériques IPN et des sessions BGP EVPN avec les Spines des autres pods. Les exigences clés comprennent :

High MTU : L'IPN doit prendre en charge un MTU d'au moins 9150 bytes pour accueillir le trafic encapsulé VXLAN (50 bytes d'overhead) sans fragmentation. Non négociable. L'utilisation de périphériques comme le Catalyst 9500-48UXM pour l'IPN nécessite une validation MTU de bout en bout minutieuse.
Multicast : PIM-Bidir est le protocole de routage requis pour gérer efficacement le trafic Broadcast, Unknown Unicast, et Multicast (BUM) qui doit être floodé entre les pods. Bien que d'autres modes PIM puissent fonctionner, Bidir est la conception standard.
DHCP Relay : L'APIC utilise DHCP pour attribuer des adresses TEP aux nœuds, y compris les Spines des pods distants. L'IPN doit être configuré avec des agents DHCP Relay pointant vers le sous-réseau du pool TEP défini dans l'APIC.
Latence : Le Round-Trip Time (RTT) officiel supporté est de 50ms. Cependant, toute conception étirant des BDs L2 sur un IPN avec une latence supérieure à 10ms est une catastrophe annoncée. Une latence élevée amplifie l'impact des Broadcast storms et peut provoquer une dégradation sévère des performances pour des applications comme vMotion. Pour une connectivité routée uniquement L3 entre les pods, 50ms est plus réaliste.

Multi-Site Inter-Site Network (ISN)

L'ISN pour Multi-Site est plus simple dans ses exigences spécifiques à ACI, mais suppose un réseau sous-jacent plus sophistiqué. L'ISN est généralement un MPLS L3VPN fourni par un opérateur ou, de plus en plus, un réseau de dark fiber géré en interne exécutant VXLAN BGP EVPN. La connexion du data plane est de Spine à Spine, qui utilise des sessions BGP EVPN pour échanger des informations de reachability des endpoints entre les sites. NDO orchestre l'établissement de ces sessions BGP, mais le transport réseau sous-jacent est indépendant d'ACI. C'est une distinction cruciale : Multi-Site ne dicte pas *comment* vos sites sont connectés, seulement qu'ils *peuvent* échanger du trafic routé avec un MTU approprié.

Domaines de panne et rayon d'impact (Blast Radius)

C'est la considération la plus importante. Un domaine de panne plus grand simplifie la gestion mais augmente les risques. Multi-Pod et Multi-Site se situent aux extrémités opposées de ce spectre.

Avec Multi-Pod, un bug dans ACI, une configuration erronée poussée, ou une défaillance du control plane de l'APIC est un événement global. Un changement effectué via l'APIC GUI ou l'API est propagé à tous les pods simultanément. Imaginez un scénario où un bug dans COOP entraîne un problème d'apprentissage des endpoints à l'échelle du fabric. Dans une conception Multi-Pod, ce problème s'étendrait instantanément à tous vos data centers. Votre site de Disaster Recovery serait impacté par la même défaillance que votre site principal, le rendant inutile. C'est un risque inacceptable pour la plupart des déploiements de niveau entreprise visant une véritable Business Continuity.

Multi-Site, en revanche, offre une isolation robuste des pannes. Chaque site est un fabric ACI autonome. Le Nexus Dashboard Orchestrator est une plateforme d'orchestration Out-Of-Band. Si le cluster NDO tombe en panne, les *modifications* de politiques inter-sites ne peuvent plus être effectuées, mais le data plane et les control planes existants de chaque site continuent de fonctionner parfaitement. Le trafic de données entre les sites n'est pas affecté. Un bug dans la version ACI exécutée dans Site1 ne se propage pas à Site2. Cela permet des mises à niveau échelonnées et contrôlées (par exemple, mise à niveau de Site2 vers ACI 6.1, validation, puis mise à niveau de Site1 des semaines plus tard), un filet de sécurité opérationnel critique que Multi-Pod n'offre pas.

Exemple de dimensionnement : Bande passante inter-sites et ressources NDO

Modélisons un scénario typique à deux sites : deux data centers distants de 80km, nécessitant le support de clusters d'applications Active/Active et la réplication de bases de données.

Sites : 2
Nombre total de Leafs : 300 (150 par site)
Tenants : 50
EPGs : 3 000
Trafic de réplication inter-sites de pointe : 150 Gbit/s

Approche de dimensionnement Multi-Pod

Pour Multi-Pod, la principale préoccupation est l'IPN. Vous avez besoin de périphériques IPN capables de transférer 150 Gbit/s de trafic à vitesse linéaire et de gros paquets. Une paire de Juniper SRX5800s ou de châssis Cisco Catalyst 9606R avec une densité de ports 100G suffisante serait nécessaire. Le problème majeur est le trafic BUM L2. Si vous étirez 500 VLANs (sous forme de BDs) entre les pods, et que chacun génère en moyenne seulement 10 Mbps de trafic BUM, cela représente 5 Gbit/s de trafic Multicast constant qui consomme de la bande passante IPN et du CPU sur les routeurs IPN. Ce calcul est fréquemment négligé. (Nombre de BDs étirés) * (Trafic BUM moyen par BD) = Charge constante IPN. Cette charge est toujours présente et doit être prise en compte dans votre planification de bande passante.

Approche de dimensionnement Multi-Site

Pour Multi-Site, vous provisionnez un service L3VPN/EVPN Wave de 200 Gbit/s (150 Gbit/s + 33% de marge) auprès d'un opérateur. L'accent est mis sur le dimensionnement du cluster Nexus Dashboard. Selon le guide de dimensionnement Cisco NDO 4.2, la gestion de 2 sites, 3000 EPGs et 50 tenants nécessite un cluster NDO à 3 nœuds où chaque nœud est une machine virtuelle avec environ 16 vCPUs, 64 Go de RAM et 1 To d'espace disque. C'est une empreinte de virtualisation non négligeable. Le coût n'est pas dans le calcul de la bande passante du data path (qui est un simple coût de circuit opérateur) mais dans le calcul et les licences logicielles pour NDO et le cluster APIC redondant dans le deuxième site.

Piège courant : Étirer la couche 2 (L2) sur un DCI

La capacité la plus dangereuse offerte par Multi-Pod et Multi-Site est la possibilité d'étirer un Bridge Domain Layer 2 entre des emplacements géographiquement séparés. Bien que techniquement possible, c'est presque toujours une erreur architecturale. L'étirement de la L2 crée un domaine de Broadcast unique, ce qui signifie qu'un Broadcast storm dans un site inondera les liens DCI/IPN et impactera l'autre site (fate-sharing). Cela complique le troubleshooting et sert souvent de béquille pour éviter de moderniser des applications héritées qui ont des adresses IP hardcodées. Bien que Multi-Site soit plus élégant dans la façon dont il tunnelise le trafic L2 avec VXLAN, le problème fondamental demeure. La meilleure pratique en 2026 est de maintenir les Broadcast domains L2 locaux à un seul site et d'utiliser une connectivité routée uniquement L3 entre les sites pour tout le trafic. N'étirez pas.

Quand NE PAS utiliser ACI Multi-Site

Malgré sa supériorité technique en matière d'isolation des pannes, Multi-Site n'est pas une solution universelle. Il existe des scénarios spécifiques où Multi-Pod est le choix le plus pragmatique.

Le premier est le coût. Un déploiement Multi-Site nécessite un cluster APIC complet (au moins 3 nœuds) pour *chaque site*, plus un cluster Nexus Dashboard (physique ou virtuel), plus la licence logicielle NDO (par exemple, N-D-ADV-S-GF). Cela peut facilement doubler le coût des contrôleurs et des logiciels par rapport à une conception Multi-Pod qui utilise un seul cluster APIC. Si vos deux "sites" sont simplement deux étages du même bâtiment, le coût de Multi-Site est injustifiable.

Le second est le scale et la latence. Pour un petit déploiement (par exemple, <80 commutateurs Leaf au total) sur deux sites métropolitains avec dark fiber et <5ms RTT, Multi-Pod offre un Unified Management Plane plus simple à opérer que NDO. Le risque d'un domaine de panne unique peut être un compromis calculé et acceptable pour la simplicité opérationnelle lorsque la proximité physique et la faible latence limitent le potentiel de problèmes induits par le réseau.

Enfin, considérez les compétences de votre équipe. Multi-Pod est une extension directe de la connaissance d'un fabric ACI unique. Multi-Site, avec NDO, les Schema Templates et la nécessité de gérer un réseau inter-sites BGP EVPN sous-jacent, représente une augmentation significative de la complexité. Si votre équipe n'est pas prête pour ce saut opérationnel, la mise en œuvre de Multi-Site peut introduire plus de risques dus à une mauvaise configuration qu'elle n'en résout par l'isolation des pannes.

En fin de compte, la décision repose sur une évaluation claire des risques. Multi-Pod privilégie les opérations simplifiées au sein d'un domaine de panne unique et étendu, ce qui le rend adapté aux déploiements en zone métropolitaine où le coût et la simplicité sont primordiaux et où le risque est jugé acceptable. Multi-Site privilégie l'isolation des pannes et le scale avant tout, ce qui en fait le choix requis pour les réseaux étendus et géographiquement dispersés où la Business Continuity est non négociable. Choisissez l'architecture qui correspond à votre réalité opérationnelle et à votre budget, et non pas seulement celle qui est techniquement possible.

Chez TechLeague, nos experts certifiés peuvent vous aider à modéliser le TCO et l'impact opérationnel des deux architectures pour votre environnement spécifique. Contactez-nous pour entamer la conversation. Lisez nos articles connexes sur la conception VXLAN EVPN et l'écosystème Nexus Dashboard pour en savoir plus.