Posso usar a internet pública para a conectividade de transporte da Região 0?

Embora tecnicamente possível executando túneis sobre a internet, é um design fundamentalmente falho. A Região 0 é o seu backbone core; sua estabilidade dita o desempenho de todo o fabric. Usar a internet pública imprevisível introduz latência e jitter variáveis, minando a confiabilidade que o MRF deveria fornecer. Sempre use transporte privado dedicado como DWDM, Ethernet de operadora ou MPLS premium para a Região 0.

Quantas regiões de acesso devo criar?

Comece com limites continentais: AMER, EMEA e APJC são pontos de partida comuns. Uma boa regra geral é manter os tamanhos das regiões entre 500-1000 sites para permanecer bem dentro dos limites do control plane dos border routers. Evite criar dezenas de pequenas regiões granulares, pois isso aumenta a complexidade de gerenciamento sem fornecer benefícios significativos de escalabilidade.

Preciso de clusters de vSmart controller separados para cada região?

Não, esta é uma concepção errônea comum. Um único cluster centralizado de vSmart controllers gerencia todo o multi-region fabric. Você atribui roteadores e seus sites a números de regiões específicos durante a configuração, e o único cluster vSmart impõe os limites hierárquicos do control plane com base nessas atribuições.

Qual versão do software Catalyst SD-WAN é necessária para o MRF?

O recurso, originalmente denominado Hierarchical SD-WAN, está disponível desde o Viptela OS 18.x. No software Cisco Catalyst SD-WAN moderno (por exemplo, versão 20.9 e posterior), é um recurso estável e maduro. Para qualquer implantação MRF em produção, é crítico usar uma versão estável e de longa duração recomendada pela Cisco, como a próxima 20.13 ou um equivalente futuro.

Um único site de filial pode pertencer a mais de uma região de acesso?

Não, um roteador de borda (cEdge/vEdge) é explicitamente atribuído a uma única região de acesso através de sua configuração de sistema. Todas as suas sessões OMP para aprender TLOCs e rotas são estabelecidas dentro dos limites dessa única região, seja para outras bordas ou para os border routers designados da região.

Como as políticas de roteamento e QoS funcionam com o MRF?

As políticas e QoS são aplicadas hierarquicamente. Você pode aplicar políticas de dados específicas, políticas de controle ou políticas de roteamento com reconhecimento de aplicação que afetam apenas o tráfego dentro de uma região de acesso. Separadamente, você pode aplicar políticas nos transport gateways para governar o tráfego que flui pela Região 0. Isso permite controle granular dentro de uma região e controle de alto nível sobre o tráfego de backbone inter-regional.

O Multi-Region Fabric é o mesmo que o Cisco SD-WAN Cloud OnRamp?

Não, eles resolvem problemas diferentes, mas são complementares. O Cloud OnRamp para SaaS/IaaS é um recurso que otimiza o caminho de um site de filial para uma aplicação cloud específica ou provedor IaaS. O MRF é uma arquitetura fundamental para escalar a própria WAN em muitos sites e geografias. Você normalmente usaria o Cloud OnRamp *dentro* de uma região de acesso de sua implantação MRF.

Cisco SD-WAN Multi-Region Fabric: Um Design Resiliente para 2026

Implantar o Cisco Catalyst SD-WAN além de algumas centenas de sites sem uma arquitetura Multi-Region Fabric (MRF) é uma receita para o colapso do control plane. Embora um fabric de região única pareça mais simples, sua natureza de malha completa cria uma explosão geométrica de sessões BFD e atualizações OMP que nenhum vSmart ou roteador de borda pode sustentar em escala corporativa. O MRF, anteriormente Hierarchical SD-WAN, não é um complemento opcional; é o paradigma de design obrigatório para qualquer rede que exceda 1.000 sites ou abranja vários continentes. No entanto, uma implantação MRF bem-sucedida depende inteiramente de uma Região 0 perfeitamente arquitetada e de gateways de transporte corretamente dimensionados. Se isso for feito de forma errada, você construirá um gargalo distribuído em vez de um fabric escalável.

Compreendendo o Control Plane do Multi-Region Fabric

Uma implantação padrão de Catalyst SD-WAN de região única é um control plane "flat". Cada roteador de borda (cEdge/vEdge) estabelece adjacências OMP com todos os outros roteadores de borda para aprender TLOCs (Transport Locators) e rotas de serviço, e com cada vSmart controller. As sessões BFD verificam a "liveness" do caminho entre todos os TLOCs. Com 100 sites, isso é gerenciável. Com 2.000 sites, cada um com dois transportes, um único roteador pode precisar manter milhares de sessões BFD e OMP. Isso consome CPU e memória significativas, não apenas nos roteadores de borda, mas criticamente nos vSmart controllers, que atuam como os route reflectors centrais. Um único par de vSmart, mesmo em hardware robusto, atinge limites práticos em torno de 2.500 sessões de peering OMP.

O MRF resolve isso introduzindo um control plane hierárquico. O fabric é particionado em uma região central (Região 0) e múltiplas regiões de acesso (Regiões 1-N).

Regiões de Acesso: Contêm os sites reais dos usuários – filiais, campi e ambientes de aplicação de datacenter. Os roteadores dentro de uma região de acesso operam em uma malha completa entre si.
Região 0: Esta região especial não contém sites de usuários. Seu único propósito é interconectar as regiões de acesso. Ela contém roteadores de borda de alta capacidade que atuam como transport gateways.

A magia está na abstração do control plane. Um roteador de borda na Região 1 (por exemplo, Londres) não faz peering com um roteador de borda na Região 2 (por exemplo, Tóquio). Em vez disso, o roteador de Londres aprende um caminho resumido para a região de Tóquio via seu roteador de borda local. Os vSmarts impõem essa segmentação, reduzindo drasticamente o número de sessões OMP e BFD que cada dispositivo deve manter. Isso não é apenas uma sugestão; para redes globais executando o Catalyst SD-WAN 20.9 ou mais recente, é a única arquitetura estável.

Arquitetura Core: Região 0, Border Routers e Transport Gateways

A terminologia aqui é precisa. Um roteador que fornece um ponto de saída para uma região é um border router. Quando esses border routers são usados para interconectar regiões, eles funcionam como transport gateways. Em um design MRF, esses termos são frequentemente usados de forma intercambiável para o mesmo dispositivo.

Projetando o Core: Região 0

A Região 0 é o coração do fabric; seu design determina a estabilidade, latência e throughput de toda a comunicação inter-regional. É uma região de trânsito. Sob nenhuma circunstância VPNs de serviço para filiais de usuários ou datacenters devem terminar diretamente na Região 0. Seus únicos membros são os próprios transport gateways. Para máxima estabilidade, os transport gateways da Região 0 devem ser implantados em pelo menos duas, preferencialmente três ou mais, instalações de operadora neutra geograficamente dispersas com conectividade de alta velocidade. Para uma rede global, pense em localizações Equinix em Ashburn, Londres e Singapura. O transporte que conecta esses sites core não deve ser a internet pública; deve ser um backbone privado de alto desempenho (por exemplo, DWDM de 100 Gbps, Ethernet de operadora dedicada ou um serviço MPLS premium).

Seleção de Hardware: Sem Economia

Para o papel crítico de transport gateways na Região 0 e em regiões de acesso de alta densidade, a seleção de hardware é primordial. Não tente usar roteadores de filial de nível de entrada. O desempenho IPsec crypto e a escalabilidade de sessão necessários exigem plataformas de alta gama. O principal para esta função é a Catalyst 8500 Series, especificamente o C8500-12X, que oferece até 197 Gbps de throughput IPsec. Para implantações virtuais em uma nuvem privada ou colocation, uma instância Catalyst 8000V (Cat8kV) provisionada com núcleos de CPU suficientes (por exemplo, mais de 16 vCPUs em um UCS C220 M7) e SR-IOV para desempenho de NIC é uma alternativa viável. Para border routers de região de acesso em regiões menores, um par de Catalyst 8300s pode ser suficiente, mas o desempenho deve ser cuidadosamente validado contra os requisitos de throughput agregado.

Dimensionamento de Transport Gateways e Componentes de Control Plane

O subdimensionamento dos transport gateways é o erro mais comum e custoso no design de MRF. O cálculo requer uma avaliação honesta dos fluxos de tráfego inter-regionais e uma compreensão do overhead do IPsec.

Um Exemplo Real de Dimensionamento

Vamos modelar um transport gateway para uma região de acesso europeia (Região 1) com 600 sites de filiais, que precisa se comunicar com uma região americana (Região 2).

Throughput Agregado da Filial: Suponha que cada uma das 600 filiais tenha um circuito DIA de 100 Mbps, com uma utilização de pico média de 40%, ou seja, 40 Mbps por site. O throughput de saída agregado teórico é de 600 * 40 Mbps = 24 Gbps.
Estimativa de Tráfego Inter-Regional: Nem todo o tráfego sairá da região. Com base na análise de aplicações, digamos que 30% do tráfego seja destinado à região AMER. Isso significa que o transport gateway deve lidar com 24 Gbps * 0,30 = 7,2 Gbps de tráfego stateful.
Cálculo do Overhead Crypto: O IPsec (ESP no modo túnel com AES-256-GCM) adiciona overhead de encapsulamento. Uma estimativa conservadora é de um impacto de desempenho de 25% no throughput bruto. Assim, o desempenho crypto exigido é de 7,2 Gbps * 1,25 = 9,0 Gbps.
Fator de Failover: Você implantará pelo menos dois transport gateways para redundância (por exemplo, um em Londres, um em Frankfurt). Cada gateway deve ser dimensionado para lidar com toda a carga de 9,0 Gbps se o outro falhar. Dimensioná-los para 4,5 Gbps cada (carga 50/50) garante uma massiva degradação de desempenho durante uma falha.
Seleção da Plataforma: Um único Catalyst 8300 (C8300-2N2S-4T2X) atinge cerca de 10-15 Gbps de throughput IPsec agregado em condições ideais. Empurrar 9 Gbps durante um failover é arriscado e não deixa espaço para crescimento. A escolha correta aqui é um par de Catalyst 8500-12X switches ou instâncias Cat8kV de alto desempenho. Embora um concorrente como um PA-5440 da Palo Alto Networks possa oferecer ~40 Gbps de throughput IPsec, permanecer dentro do ecossistema Catalyst simplifica o gerenciamento sob o vManage.

Design de TLOC e Controle de Caminho

A elegância do MRF reside no uso de TLOCs. Um border router em uma região de acesso executa uma função crucial: extensão de TLOC. Ele estende seus próprios TLOCs para os roteadores de borda dentro de sua região. Quando um cEdge de filial em Frankfurt precisa enviar tráfego para um cEdge de filial em Dallas, ele não vê os TLOCs do cEdge de Dallas diretamente. Ele vê o TLOC de seu transport gateway local (por exemplo, em Londres), que tem um caminho para a região AMER.

O fluxo do control plane é o seguinte:

O cEdge de Dallas anuncia seus TLOCs locais e prefixos de serviço para seu border router local (AMER) via OMP.
O border router AMER anuncia esses prefixos para os vSmarts da Região 0, mas crucialmente, ele os anuncia com seu próprio TLOC como o next hop.
Os vSmarts da Região 0 passam este resumo para o border router EMEA.
O border router EMEA passa as informações de "reachability" para o cEdge de Frankfurt.

O resultado: o cEdge de Frankfurt simplesmente encaminha o tráfego inter-regional para o TLOC do transport gateway de Londres. O complexo caminho intercontinental é tratado pela hierarquia estruturada, não por roteadores de filial individuais. Isso permite a aplicação de políticas poderosas. Você pode criar políticas de controle centralizadas no vManage que ditam, por exemplo, que todo o tráfego da Região 1 para a Região 2 com um DSCP marking específico deve usar o transporte MPLS através da Região 0, enquanto todo o outro tráfego pode usar o transporte da internet.

Armadilhas Comuns: Criando Links Inter-Regionais de Backdoor

Um erro de design fatal é estabelecer conectividade "out-of-band" entre regiões de acesso que contornam a Região 0. Por exemplo, um engenheiro pode conectar diretamente dois datacenters, um na região de acesso 1 e outro na região de acesso 2, com uma conexão Layer 3 dedicada para uma aplicação específica e então redistribuir rotas para o OMP. Isso cria um caminho de "backdoor".

Isso compromete completamente a arquitetura MRF. Introduz o risco de roteamento assimétrico, onde o tráfego da Região 1 para a 2 usa o link de backdoor, mas o tráfego de retorno da 2 para a 1 tenta usar o caminho oficial da Região 0. Isso causa estragos em serviços stateful como firewalls. Viola a hierarquia do control plane, tornando a solução de problemas com as ferramentas do vManage quase impossível, pois o caminho de tráfego real não corresponde ao logicamente configurado. Todo o tráfego inter-regional deve transitar pelos transport gateways via Região 0. Não há exceções.

Quando NÃO Usar o Multi-Region Fabric

O MRF adiciona uma camada de complexidade de design e operacional. Nem sempre é a resposta certa. Uma única região bem dimensionada é preferível a um design multi-region mal implementado.

Você não deve usar MRF se:

Sua rede tiver menos de 500 sites. O overhead do control plane é gerenciável em hardware moderno. Um par de vSmarts (virtual ou físico) pode lidar com a carga OMP, e roteadores de borda como o Catalyst 8200 ou 8300 podem lidar com as sessões BFD para uma rede desse tamanho.
Sua rede estiver geograficamente contida. Se todos os seus sites estiverem dentro de um único continente (por exemplo, América do Norte), os benefícios de latência da regionalização são mínimos. Uma única região com controllers posicionados em datacenters geograficamente centrais (por exemplo, Chicago e Dallas) é mais eficiente.
Você não possui o backbone de rede core para uma Região 0 confiável. Se você não pode provisionar transporte dedicado, de alta velocidade e baixa latência entre seus sites core da Região 0, o MRF não terá um bom desempenho. Tentar construir a Região 0 sobre a internet pública introduz muita imprevisibilidade e anula o propósito de criar um core estável.

O principal gatilho para o MRF é escalar além dos limites OMP/BFD de um único domínio de control plane, tipicamente observado após a marca de 1.000-1.500 sites, ou a necessidade de impor segmentação estrita e "pathing" otimizado em uma implantação global e multi-continente.

Dominar o Multi-Region Fabric é essencial para construir um Catalyst SD-WAN resiliente e em escala planetária. Sua natureza hierárquica é a única maneira de superar as limitações inerentes de escalabilidade dos designs de rede "flat". Ao focar em uma Região 0 robusta e privada, dimensionando corretamente os transport gateways para failover e preservando a integridade da hierarquia do control plane, você pode construir um fabric que fornece conectividade estável e baseada em política para milhares de sites. Para orientação especializada no design, implementação e gerenciamento de sua implantação SD-WAN em larga escala, explore os serviços de consultoria em techleague.io. Para aprimorar ainda mais sua expertise, leia nossas análises sobre a seleção da plataforma Catalyst 8000 vs. ISR 4000 e a intersecção de SASE com o design de fabric em nosso guia de integração ZTNA vs. VPN.