¿Puedo usar internet público para la conectividad de transport de la Región 0?

Aunque técnicamente posible mediante la ejecución de túneles sobre internet, es un diseño fundamentalmente defectuoso. La Región 0 es su core backbone; su estabilidad determina el rendimiento de todo el fabric. Usar internet público impredecible introduce latencia y jitter variables, socavando la fiabilidad que MRF debe proporcionar. Siempre use transport privado dedicado como DWDM, carrier Ethernet o MPLS premium para la Región 0.

¿Cuántas access regions debo crear?

Comience con límites continentales: AMER, EMEA y APJC son puntos de partida comunes. Una buena regla general es mantener los tamaños de las regiones entre 500 y 1000 sitios para mantenerse dentro de los límites del control plane de los border routers. Evite crear docenas de regiones pequeñas y granulares, ya que esto aumenta la complejidad de la gestión sin proporcionar beneficios de escalado significativos.

¿Necesito clusters de vSmart controller separados para cada región?

No, esta es una idea errónea común. Un único cluster centralizado de vSmart controllers gestiona todo el multi-region fabric. Usted asigna routers y sus sitios a números de región específicos durante la configuración, y el único cluster de vSmart aplica los límites del control plane jerárquico basándose en estas asignaciones.

¿Qué versión de software Catalyst SD-WAN se requiere para MRF?

La característica, originalmente llamada Hierarchical SD-WAN, ha estado disponible desde Viptela OS 18.x. En el software moderno de Cisco Catalyst SD-WAN (por ejemplo, la versión 20.9 y posteriores), es una característica estable y madura. Para cualquier despliegue de MRF en producción, es fundamental usar una versión estable y de larga duración recomendada por Cisco, como la próxima 20.13 o un equivalente futuro.

¿Puede un solo sitio de sucursal pertenecer a más de una access region?

No, un edge router (cEdge/vEdge) se asigna explícitamente a una única access region a través de su configuración de sistema. Todas sus sesiones OMP para aprender TLOCs y rutas se establecen dentro de los confines de esa única región, ya sea con otros edges o con los border routers designados de la región.

¿Cómo funcionan las routing policies y QoS con MRF?

Las policies y QoS se aplican jerárquicamente. Puede aplicar data policies específicas, control policies o application-aware routing policies que solo afectan el tráfico dentro de una access region. Por separado, puede aplicar policies en los transport gateways para gobernar el tráfico que fluye a través de la Región 0. Esto permite un control granular dentro de una región y un control de alto nivel sobre el tráfico de backbone inter-región.

¿Es Multi-Region Fabric lo mismo que Cisco SD-WAN Cloud OnRamp?

No, resuelven problemas diferentes pero son complementarios. Cloud OnRamp para SaaS/IaaS es una característica que optimiza la ruta desde un sitio de sucursal a una aplicación en la nube o proveedor IaaS específico. MRF es una arquitectura fundamental para escalar toda la WAN a través de muchos sitios y geografías. Normalmente usaría Cloud OnRamp *dentro* de una access region de su despliegue MRF.

Cisco SD-WAN Multi-Region Fabric: Un diseño resiliente para 2026

Desplegar Cisco Catalyst SD-WAN más allá de unos pocos cientos de sitios sin una arquitectura Multi-Region Fabric (MRF) es una receta para el colapso del control plane. Mientras que un single-region fabric parece más simple, su naturaleza de full-mesh crea una explosión geométrica de sesiones BFD y actualizaciones OMP que ningún vSmart o edge router puede soportar a escala empresarial. MRF, anteriormente Hierarchical SD-WAN, no es un add-on opcional; es el paradigma de diseño obligatorio para cualquier red que supere los 1.000 sitios o que abarque múltiples continentes. Sin embargo, un despliegue exitoso de MRF depende enteramente de una Región 0 arquitectada impecablemente y de transport gateways dimensionados correctamente. Si esto sale mal, se construye un cuello de botella distribuido en lugar de un fabric escalable.

Entendiendo el Control Plane de Multi-Region Fabric

Un despliegue de Catalyst SD-WAN predeterminado de single-region es un control plane plano. Cada edge router (cEdge/vEdge) establece adyacencias OMP con cada otro edge router para aprender TLOCs (Transport Locators) y service routes, y con cada vSmart controller. Las sesiones BFD verifican la liveness del path entre todos los TLOCs. Con 100 sitios, esto es manejable. Con 2.000 sitios, cada uno con dos transports, un solo router podría necesitar mantener miles de sesiones BFD y OMP. Esto consume una cantidad significativa de CPU y memoria, no solo en los edge routers sino críticamente en los vSmart controllers, que actúan como route reflectors centrales. Un único par de vSmart, incluso en hardware robusto, alcanza límites prácticos alrededor de 2.500 sesiones OMP peering.

MRF resuelve esto introduciendo un control plane jerárquico. El fabric se divide en una región core (Región 0) y múltiples regiones de acceso (Regiones 1-N).

Access Regions: Estas contienen los sitios de usuario reales: sucursales, campus y entornos de aplicaciones de datacenter. Los routers dentro de una access region operan en un full mesh entre sí.
Región 0: Esta región especial no contiene sitios de usuario. Su único propósito es interconectar las access regions. Contiene border routers de alto rendimiento que actúan como transport gateways.

La magia reside en la abstracción del control plane. Un edge router en la Región 1 (por ejemplo, Londres) no realiza peering con un edge router en la Región 2 (por ejemplo, Tokio). En su lugar, el router de Londres aprende una ruta resumida a la región de Tokio a través de su border router local. Los vSmarts aplican esta segmentación, reduciendo drásticamente el número de sesiones OMP y BFD que cada dispositivo debe mantener. Esto no es solo una sugerencia; para redes globales que operan con Catalyst SD-WAN 20.9 o posterior, es la única arquitectura estable.

Arquitectura Core: Región 0, Border Routers y Transport Gateways

La terminología aquí es precisa. Un router que proporciona un punto de salida para una región es un border router. Cuando estos border routers se utilizan para interconectar regiones, funcionan como transport gateways. En un diseño MRF, estos términos se usan a menudo indistintamente para referirse al mismo dispositivo.

Diseñando el Core: Región 0

La Región 0 es el corazón del fabric; su diseño determina la estabilidad, latencia y rendimiento de toda la comunicación inter-región. Es una región solo de tránsito. Bajo ninguna circunstancia deben terminar los service-side VPNs para sucursales de usuario o datacenters directamente en la Región 0. Sus únicos miembros son los propios transport gateways. Para una máxima estabilidad, los transport gateways de la Región 0 deben desplegarse en al menos dos, preferiblemente tres o más, ubicaciones geográficamente dispersas y carrier-neutral con conectividad de alta velocidad. Para una red global, piense en ubicaciones de Equinix en Ashburn, Londres y Singapur. El transport que conecta estos sitios core no debe ser internet público; debe ser un backbone privado y de alto rendimiento (por ejemplo, DWDM de 100 Gbps, carrier Ethernet dedicado o un servicio MPLS premium).

Selección de Hardware: Sin Atajos

Para el papel crítico de los transport gateways en la Región 0 y las access regions de alta densidad, la selección de hardware es primordial. No intente utilizar routers de sucursal de nivel de entrada. El rendimiento de criptografía IPsec y la escalabilidad de sesiones requeridos exigen plataformas de gama alta. El equipo clave para este papel es la Catalyst 8500 Series, específicamente el C8500-12X, que proporciona hasta 197 Gbps de rendimiento IPsec. Para despliegues virtuales en una nube privada o colocation, una instancia de Catalyst 8000V (Cat8kV) aprovisionada con suficientes CPU cores (por ejemplo, 16+ vCPUs en un UCS C220 M7) y SR-IOV para el rendimiento de la NIC es una alternativa viable. Para border routers de access region en regiones más pequeñas, un par de Catalyst 8300s puede ser suficiente, pero el rendimiento debe validarse cuidadosamente contra los requisitos de rendimiento agregado.

Dimensionamiento de Transport Gateways y Componentes del Control Plane

Un dimensionamiento insuficiente de los transport gateways es el error más común y costoso en el diseño de MRF. El cálculo requiere una evaluación honesta de los flujos de tráfico inter-región y una comprensión del overhead de IPsec.

Un Ejemplo Real de Dimensionamiento

Modelemos un transport gateway para una access region europea (Región 1) con 600 sucursales, que necesita comunicarse con una región americana (Región 2).

Rendimiento Agregado de Sucursales: Supongamos que cada una de las 600 sucursales tiene un circuito DIA de 100 Mbps, con una utilización máxima promedio del 40%, es decir, 40 Mbps por sitio. El rendimiento de egreso agregado teórico es de 600 * 40 Mbps = 24 Gbps.
Estimación de Tráfico Inter-Región: No todo el tráfico saldrá de la región. Basado en el análisis de aplicaciones, digamos que el 30% del tráfico está destinado a la región AMER. Esto significa que el transport gateway debe manejar 24 Gbps * 0.30 = 7.2 Gbps de tráfico stateful.
Cálculo del Overhead de Criptografía: IPsec (ESP en modo túnel con AES-256-GCM) añade overhead de encapsulación. Una estimación conservadora es un impacto del 25% en el rendimiento sobre el rendimiento bruto. Por lo tanto, el rendimiento de criptografía requerido es 7.2 Gbps * 1.25 = 9.0 Gbps.
Considerar el Failover: Se desplegarán al menos dos transport gateways para redundancia (por ejemplo, uno en Londres, otro en Fráncfort). Cada gateway debe dimensionarse para manejar la carga completa de 9.0 Gbps si el otro falla. Dimensionarlos para 4.5 Gbps cada uno (carga 50/50) garantiza una degradación masiva del rendimiento durante una falla.
Seleccionar la Plataforma: Un único Catalyst 8300 (C8300-2N2S-4T2X) alcanza un máximo de alrededor de 10-15 Gbps de rendimiento IPsec agregado en condiciones ideales. Empujar 9 Gbps durante un failover es arriesgado y no deja margen de crecimiento. La elección correcta aquí es un par de switches Catalyst 8500-12X o instancias de Cat8kV de alto rendimiento. Mientras que un competidor como un PA-5440 de Palo Alto Networks podría ofrecer ~40 Gbps de rendimiento IPsec, permanecer dentro del ecosistema Catalyst simplifica la gestión bajo vManage.

Diseño de TLOC y Control de Ruta

La elegancia de MRF reside en el uso de TLOCs. Un border router en una access region realiza una función crucial: extensión de TLOC. Extiende sus propios TLOCs a los edge routers dentro de su región. Cuando un cEdge de sucursal en Fráncfort necesita enviar tráfico a un cEdge de sucursal en Dallas, no ve directamente los TLOCs del cEdge de Dallas. Ve el TLOC de su transport gateway local (por ejemplo, en Londres), que tiene una ruta a la región AMER.

El flujo del control plane es el siguiente:

El cEdge de Dallas anuncia sus TLOCs locales y service-side prefixes a su border router local (AMER) a través de OMP.
El border router AMER anuncia estos prefijos a los vSmarts de la Región 0, pero crucialmente, los anuncia con su propio TLOC como next hop.
Los vSmarts de la Región 0 pasan este resumen al border router EMEA.
El border router EMEA pasa la información de reachability al cEdge de Fráncfort.

El resultado: el cEdge de Fráncfort simplemente reenvía el tráfico inter-región al TLOC del transport gateway de Londres. El complejo pathing intercontinental es manejado por la jerarquía estructurada, no por los routers de sucursal individuales. Esto permite una potente aplicación de políticas. Puede crear centralized control policies en vManage que dicten, por ejemplo, que todo el tráfico de la Región 1 a la Región 2 con un marcado DSCP específico debe usar el transport MPLS a través de la Región 0, mientras que todo el demás tráfico puede usar el transport de internet.

Error Común: Creación de Enlaces Inter-Región de Puerta Trasera

Un error de diseño fatal es establecer conectividad out-of-band entre access regions que bypasses la Región 0. Por ejemplo, un ingeniero podría vincular directamente dos datacenters, uno en la access Region 1 y otro en la access Region 2, con una conexión Layer 3 dedicada para una aplicación específica y luego redistribuir rutas en OMP. Esto crea una ruta de "puerta trasera".

Esto socava completamente la arquitectura MRF. Introduce el riesgo de enrutamiento asimétrico, donde el tráfico de la Región 1 a la 2 toma el enlace de puerta trasera, pero el tráfico de retorno de la 2 a la 1 intenta usar la ruta oficial de la Región 0. Esto causa estragos en servicios stateful como los firewalls. Viola la jerarquía del control plane, haciendo que la resolución de problemas con las herramientas de vManage sea casi imposible, ya que la ruta de tráfico real no coincide con la configurada lógicamente. Todo el tráfico inter-región debe transitar por los transport gateways a través de la Región 0. No hay excepciones.

Cuando NO usar Multi-Region Fabric

MRF añade una capa de complejidad de diseño y operativa. No siempre es la respuesta correcta. Una single region bien escalada es preferible a un diseño multi-region mal implementado.

No debe usar MRF si:

Su red tiene menos de 500 sitios. El overhead del control plane es manejable en hardware moderno. Un par de vSmarts (virtuales o físicos) pueden manejar la carga OMP, y los edge routers como el Catalyst 8200 o 8300 pueden manejar las sesiones BFD para una red de este tamaño.
Su red está geográficamente contenida. Si todos sus sitios se encuentran dentro de un mismo continente (por ejemplo, América del Norte), los beneficios de latencia de la regionalización son mínimos. Una single region con controllers ubicados en datacenters geográficamente centrales (por ejemplo, Chicago y Dallas) es más eficiente.
Carece del core network backbone para una Región 0 fiable. Si no puede aprovisionar transport dedicado, de alta velocidad y baja latencia entre sus sitios core de la Región 0, MRF no funcionará bien. Intentar construir la Región 0 sobre internet público introduce demasiada imprevisibilidad y anula el propósito de crear un core estable.

El principal detonante para MRF es escalar más allá de los límites de OMP/BFD de un solo dominio de control plane, típicamente observado a partir de los 1.000-1.500 sitios, o la necesidad de aplicar una segmentación estricta y un pathing optimizado en un despliegue global y multi-continental.

Dominar el Multi-Region Fabric es esencial para construir un Catalyst SD-WAN resiliente y a escala planetaria. Su naturaleza jerárquica es la única forma de superar las limitaciones inherentes de escalabilidad de los diseños de red planos. Al centrarse en una Región 0 robusta y privada, dimensionar correctamente los transport gateways para failover y preservar la integridad de la jerarquía del control plane, puede construir un fabric que proporcione conectividad estable y policy-driven para miles de sitios. Para obtener orientación experta sobre el diseño, implementación y gestión de su despliegue SD-WAN a gran escala, explore los servicios de consultoría en techleague.io. Para mejorar su experiencia, lea nuestros análisis sobre selección de plataforma Catalyst 8000 vs. ISR 4000 y la intersección de SASE con el diseño de fabric en nuestra guía de integración ZTNA vs. VPN.