Puis-je utiliser l'internet public pour la connectivité de transport de la Region 0 ?

Bien que techniquement possible en exécutant des "tunnels" sur internet, c'est une conception fondamentalement défectueuse. La Region 0 est votre "backbone" "core" ; sa stabilité dicte les performances de l'ensemble du "fabric". L'utilisation de l'internet public imprévisible introduit une latence et une gigue variables, sapant la fiabilité que le MRF est censé apporter. Utilisez toujours un transport privé dédié comme le DWDM, l'Ethernet "carrier" ou le MPLS "premium" pour la Region 0.

Combien de régions d'accès devrais-je créer ?

Commencez par les frontières continentales : AMER, EMEA et APJC sont des points de départ courants. Une bonne règle de base est de maintenir la taille des régions entre 500 et 1000 sites pour rester dans les limites du "control plane" des "border routers". Évitez de créer des dizaines de petites régions granulaires, car cela augmente la complexité de gestion sans offrir d'avantages significatifs en termes de "scaling".

Ai-je besoin de "clusters" de contrôleurs vSmart séparés pour chaque région ?

Non, c'est une idée fausse courante. Un seul "cluster" centralisé de contrôleurs vSmart gère l'ensemble du "multi-region fabric". Vous attribuez les routeurs et leurs sites à des numéros de région spécifiques lors de la configuration, et le "cluster" vSmart unique applique les limites du "control plane" hiérarchique en fonction de ces attributions.

Quelle version du logiciel Catalyst SD-WAN est requise pour le MRF ?

La fonctionnalité, initialement nommée Hierarchical SD-WAN, est disponible depuis Viptela OS 18.x. Dans le logiciel moderne Cisco Catalyst SD-WAN (par exemple, la version 20.9 et ultérieure), c'est une fonctionnalité stable et mature. Pour tout déploiement MRF en production, il est essentiel d'utiliser une version stable et à long terme recommandée par Cisco, telle que la prochaine 20.13 ou un équivalent futur.

Un seul site "branch" peut-il appartenir à plusieurs régions d'accès ?

Non, un "edge router" (cEdge/vEdge) est explicitement attribué à une seule région d'accès via sa configuration système. Toutes ses sessions OMP pour l'apprentissage des TLOCs et des routes sont établies dans les limites de cette seule région, soit vers d'autres "edges", soit vers les "border routers" désignés de la région.

Comment fonctionnent les politiques de "routing" et le QoS avec le MRF ?

Les politiques et le QoS sont appliqués hiérarchiquement. Vous pouvez appliquer des "data policies", des "control policies" ou des politiques de "routing" "application-aware" spécifiques qui n'affectent le trafic qu'au sein d'une région d'accès. Séparément, vous pouvez appliquer des politiques aux "transport gateways" pour régir le trafic circulant via la Region 0. Cela permet un contrôle granulaire au sein d'une région et un contrôle de haut niveau sur le trafic "backbone" inter-régions.

Le Multi-Region Fabric est-il identique à Cisco SD-WAN Cloud OnRamp ?

Non, ils résolvent des problèmes différents mais sont complémentaires. Cloud OnRamp pour SaaS/IaaS est une fonctionnalité qui optimise le "path" d'un site "branch" vers une application "cloud" spécifique ou un fournisseur IaaS. Le MRF est une architecture fondamentale pour faire évoluer l'ensemble du WAN lui-même sur de nombreux sites et géographies. Vous utiliseriez généralement Cloud OnRamp *au sein* d'une région d'accès de votre déploiement MRF.

Cisco SD-WAN Multi-Region Fabric : Une Conception Résiliente pour 2026

Déployer Cisco Catalyst SD-WAN au-delà de quelques centaines de sites sans architecture Multi-Region Fabric (MRF) est une recette pour l'effondrement du "control plane". Alors qu'un "fabric" à région unique semble plus simple, sa nature "full-mesh" crée une explosion géométrique de sessions BFD et de mises à jour OMP qu'aucun vSmart ou "edge router" ne peut soutenir à l'échelle d'une entreprise. Le MRF, anciennement Hierarchical SD-WAN, n'est pas un "add-on" optionnel ; c'est le paradigme de conception obligatoire pour tout réseau dépassant 1 000 sites ou s'étendant sur plusieurs continents. Cependant, un déploiement MRF réussi dépend entièrement d'une Region 0 impeccablement architecturée et de "transport gateways" correctement dimensionnées. Si vous vous trompez, vous construisez un goulot d'étranglement distribué au lieu d'un "fabric" évolutif.

Comprendre le Control Plane du Multi-Region Fabric

Un déploiement par défaut de Catalyst SD-WAN à région unique est un "control plane" plat. Chaque "edge router" (cEdge/vEdge) établit des adjacences OMP avec chaque autre "edge router" pour apprendre les TLOCs (Transport Locators) et les routes de service, et avec chaque contrôleur vSmart. Les sessions BFD vérifient la "liveness" du "path" entre tous les TLOCs. À 100 sites, c'est gérable. À 2 000 sites, chacun avec deux transports, un seul routeur pourrait avoir besoin de maintenir des milliers de sessions BFD et OMP. Cela consomme une quantité significative de CPU et de mémoire, non seulement sur les "edge routers" mais surtout sur les contrôleurs vSmart, qui agissent comme des "route reflectors" centraux. Une seule paire de vSmart, même sur un "hardware" robuste, atteint des limites pratiques autour de 2 500 sessions de "peering" OMP.

Le MRF résout ce problème en introduisant un "control plane" hiérarchique. Le "fabric" est partitionné en une région centrale (Region 0) et plusieurs régions d'accès (Regions 1-N).

Access Regions : Celles-ci contiennent les sites utilisateurs réels — succursales, campus et environnements applicatifs de centres de données. Les routeurs au sein d'une région d'accès fonctionnent en "full mesh" entre eux.
Region 0 : Cette région spéciale ne contient aucun site utilisateur. Son seul but est d'interconnecter les régions d'accès. Elle contient des "border routers" à haut débit qui agissent comme des "transport gateways".

La magie réside dans l'abstraction du "control plane". Un "edge router" dans la Region 1 (par exemple, Londres) ne "peere" pas avec un "edge router" dans la Region 2 (par exemple, Tokyo). Au lieu de cela, le routeur de Londres apprend un "path" résumé vers la région de Tokyo via son "border router" local. Les vSmarts appliquent cette segmentation, réduisant considérablement le nombre de sessions OMP et BFD que chaque appareil doit maintenir. Ce n'est pas seulement une suggestion ; pour les réseaux mondiaux fonctionnant sur Catalyst SD-WAN 20.9 ou plus récent, c'est la seule architecture stable.

Architecture Fondamentale : Region 0, Border Routers et Transport Gateways

La terminologie ici est précise. Un routeur qui fournit un point de sortie pour une région est un "border router". Lorsque ces "border routers" sont utilisés pour interconnecter des régions, ils fonctionnent comme des "transport gateways". Dans une conception MRF, ces termes sont souvent utilisés de manière interchangeable pour le même appareil.

Concevoir le Core : Region 0

La Region 0 est le cœur du "fabric" ; sa conception détermine la stabilité, la latence et le débit de toutes les communications inter-régions. C'est une région de transit uniquement. En aucun cas les VPNs côté service pour les "branches" ou les "datacenters" des utilisateurs ne devraient se terminer directement dans la Region 0. Ses seuls membres sont les "transport gateways" elles-mêmes. Pour une stabilité maximale, les "transport gateways" de la Region 0 devraient être déployées dans au moins deux, de préférence trois ou plus, installations neutres géographiquement dispersées avec une connectivité haut débit. Pour un réseau mondial, pensez aux emplacements Equinix à Ashburn, Londres et Singapour. Le transport reliant ces sites centraux ne devrait pas être l'internet public ; il doit s'agir d'un "backbone" privé, haute performance (par exemple, DWDM 100Gbps, Ethernet "carrier" dédié, ou un service MPLS "premium").

Sélection du Hardware : Pas de Compromis

Pour le rôle critique des "transport gateways" dans la Region 0 et les régions d'accès à haute densité, la sélection du "hardware" est primordiale. N'essayez pas d'utiliser des routeurs de "branch" d'entrée de gamme. Les performances de chiffrement IPsec requises et l'évolutivité des sessions exigent des plateformes haut de gamme. Le fer de lance pour ce rôle est la série Catalyst 8500, spécifiquement le C8500-12X, qui fournit jusqu'à 197 Gbps de "throughput" IPsec. Pour les déploiements virtuels dans un "private cloud" ou une colocation, une instance Catalyst 8000V (Cat8kV) provisionnée avec suffisamment de cœurs de CPU (par exemple, 16+ vCPUs sur un UCS C220 M7) et SR-IOV pour les performances de NIC est une alternative viable. Pour les "border routers" de la région d'accès dans les régions plus petites, une paire de Catalyst 8300 peut suffire, mais les performances doivent être soigneusement validées par rapport aux exigences de "throughput" agrégé.

Dimensionnement des Transport Gateways et des Composants du Control Plane

Le sous-dimensionnement des "transport gateways" est l'erreur la plus courante et la plus coûteuse dans la conception MRF. Le calcul nécessite une évaluation honnête des flux de trafic inter-régions et une compréhension de l'"overhead" IPsec.

Un Exemple de Dimensionnement Réel

Modélisons une "transport gateway" pour une région d'accès européenne (Region 1) avec 600 sites "branch", qui doit communiquer avec une région américaine (Region 2).

"Throughput" Agrégé des Branches : Supposons que chacun des 600 "branches" dispose d'un circuit DIA de 100 Mbps, avec une utilisation moyenne "peak" de 40%, soit 40 Mbps par site. Le "throughput" d'"egress" agrégé théorique est de 600 * 40 Mbps = 24 Gbps.
Estimer le Trafic Inter-Région : Tout le trafic ne quittera pas la région. Basé sur l'analyse des applications, disons que 30% du trafic est destiné à la région AMER. Cela signifie que la "transport gateway" doit gérer 24 Gbps * 0.30 = 7.2 Gbps de trafic "stateful".
Calculer l'"Overhead" Crypto : IPsec (ESP en mode "tunnel" avec AES-256-GCM) ajoute un "overhead" d'encapsulation. Une estimation conservatrice est un impact de 25% sur les performances brutes. Ainsi, la performance crypto requise est de 7.2 Gbps * 1.25 = 9.0 Gbps.
Prendre en Compte le Failover : Vous déploierez au moins deux "transport gateways" pour la redondance (par exemple, une à Londres, une à Francfort). Chaque "gateway" doit être dimensionnée pour gérer la charge entière de 9.0 Gbps si l'autre tombe en panne. Les dimensionner pour 4.5 Gbps chacune (charge 50/50) garantit une dégradation massive des performances lors d'une panne.
Sélectionner la Plateforme : Un seul Catalyst 8300 (C8300-2N2S-4T2X) atteint au maximum environ 10-15 Gbps de "throughput" IPsec agrégé dans des conditions idéales. Pousser 9 Gbps pendant un "failover" est risqué et ne laisse aucune marge de croissance. Le bon choix ici est une paire de commutateurs Catalyst 8500-12X ou des instances Cat8kV haute performance. Alors qu'un concurrent comme un PA-5440 de Palo Alto Networks pourrait offrir environ 40 Gbps de "throughput" IPsec, rester dans l'écosystème Catalyst simplifie la gestion sous vManage.

Conception TLOC et Path Control

L'élégance du MRF réside dans son utilisation des TLOCs. Un "border router" dans une région d'accès remplit une fonction cruciale : "TLOC extension". Il étend ses propres TLOCs aux "edge routers" de sa région. Lorsqu'un cEdge de "branch" à Francfort doit envoyer du trafic à un cEdge de "branch" à Dallas, il ne voit pas directement les TLOCs du cEdge de Dallas. Il voit le TLOC de sa "transport gateway" locale (par exemple, à Londres), qui a un "path" vers la région AMER.

Le flux du "control plane" est le suivant :

Le cEdge de Dallas annonce ses TLOCs locaux et ses préfixes côté service à son "border router" local (AMER) via OMP.
Le "border router" AMER annonce ces préfixes aux vSmarts de la Region 0, mais surtout, il les annonce avec son propre TLOC comme "next hop".
Les vSmarts de la Region 0 transmettent ce résumé au "border router" EMEA.
Le "border router" EMEA transmet les informations de "reachability" au cEdge de Francfort.

Le résultat : le cEdge de Francfort transmet simplement le trafic inter-régions au TLOC de la "transport gateway" de Londres. Le "pathing" intercontinental complexe est géré par la hiérarchie structurée, et non par des routeurs de "branch" individuels. Cela permet une application puissante des politiques. Vous pouvez créer des "centralized control policies" dans vManage qui imposent, par exemple, que tout le trafic de la Region 1 vers la Region 2 avec un marquage DSCP spécifique doit utiliser le transport MPLS via la Region 0, tandis que tout autre trafic peut utiliser le transport internet.

Piège Courant : Création de Liens Inter-Régions "Backdoor"

Une faille de conception fatale est l'établissement d'une connectivité hors bande entre les régions d'accès qui contourne la Region 0. Par exemple, un ingénieur pourrait lier directement deux centres de données, un dans la région d'accès 1 et un dans la région d'accès 2, avec une connexion Layer 3 dédiée pour une application spécifique, puis redistribuer les routes dans OMP. Cela crée un "path" "backdoor".

Cela sape complètement l'architecture MRF. Cela introduit le risque de "routing" asymétrique, où le trafic de la Region 1 vers 2 prend le lien "backdoor", mais le trafic de retour de 2 vers 1 tente d'utiliser le "path" officiel de la Region 0. Cela ravage les services "stateful" comme les "firewalls". Cela viole la hiérarchie du "control plane", rendant le dépannage avec les outils de vManage presque impossible, car le "path" de trafic réel ne correspond pas à celui logiquement configuré. Tout le trafic inter-régions doit transiter par les "transport gateways" via la Region 0. Il n'y a pas d'exceptions.

Quand NE PAS Utiliser le Multi-Region Fabric

Le MRF ajoute une couche de complexité de conception et opérationnelle. Ce n'est pas toujours la bonne réponse. Une région unique bien dimensionnée est préférable à une conception multi-régions mal implémentée.

Vous ne devriez pas utiliser le MRF si :

Votre réseau compte moins de 500 sites. L'"overhead" du "control plane" est gérable sur le "hardware" moderne. Une paire de vSmarts (virtuels ou physiques) peut gérer la charge OMP, et les "edge routers" comme le Catalyst 8200 ou 8300 peuvent gérer les sessions BFD pour un réseau de cette taille.
Votre réseau est géographiquement contenu. Si tous vos sites se trouvent sur un seul continent (par exemple, l'Amérique du Nord), les avantages de la régionalisation en termes de latence sont minimes. Une région unique avec des contrôleurs placés dans des centres de données géographiquement centraux (par exemple, Chicago et Dallas) est plus efficace.
Vous manquez du "backbone" réseau "core" pour une Region 0 fiable. Si vous ne pouvez pas provisionner un transport dédié, haut débit et à faible latence entre vos sites "core" de la Region 0, le MRF ne fonctionnera pas bien. Essayer de construire la Region 0 sur l'internet public introduit trop d'imprévisibilité et va à l'encontre du but de créer un "core" stable.

Le déclencheur principal pour le MRF est le "scaling" au-delà des limites OMP/BFD d'un seul domaine de "control plane", généralement observé au-delà de 1 000 à 1 500 sites, ou la nécessité d'appliquer une segmentation stricte et un "pathing" optimisé à travers un déploiement mondial et multi-continental.

Maîtriser le Multi-Region Fabric est essentiel pour construire un Catalyst SD-WAN résilient et à l'échelle planétaire. Sa nature hiérarchique est le seul moyen de surmonter les limitations d'échelle inhérentes aux conceptions de réseau plates. En se concentrant sur une Region 0 robuste et privée, en dimensionnant correctement les "transport gateways" pour le "failover", et en préservant l'intégrité de la hiérarchie du "control plane", vous pouvez construire un "fabric" qui fournit une connectivité stable et basée sur des politiques pour des milliers de sites. Pour des conseils d'experts sur la conception, l'implémentation et la gestion de votre déploiement SD-WAN à grande échelle, explorez les services de conseil sur techleague.io. Pour approfondir votre expertise, lisez nos analyses sur la sélection de plateforme Catalyst 8000 vs. ISR 4000 et l'intersection de SASE avec la conception de "fabric" dans notre guide d'intégration ZTNA vs. VPN.