Integração de SD-WAN com topologias de rede hub-and-spoke do Azure

Este artigo descreve como criar WANs definidos por software (SD-WANs) que conectam datacenters locais uns com os outros e com Azure. Ela apresenta uma arquitetura que permite que os clientes do Azure usem seus investimentos existentes na plataforma por meio da criação de sobreposições globais de SD-WAN eficientes sobre o backbone da Microsoft.

Cenários aplicáveis

As recomendações neste artigo são independentes do fornecedor e aplicáveis a tecnologias SD-WAN que atendem a dois pré-requisitos básicos:

• Túneis que usam o Protocolo de Controle de Transmissão (TCP) ou o User Datagram Protocol (UDP) como transporte subjacente, como o Encapsulating Security Payload (ESP) do IPsec em modo túnel com travessia de NAT, implementam a sobreposição de SD-WAN.

• O protocolo BGP (Border Gateway Protocol) v4 permite a troca de rotas entre os dispositivos de borda da SD-WAN e as redes conectadas à SD-WAN. Nenhuma suposição é feita sobre o protocolo de roteamento que os dispositivos de borda SD-WAN usam para trocar informações de roteamento.

Você pode usar SD-WAN produtos que atendem a esses pré-requisitos para atingir as seguintes metas:

• Conecte redes hub-and-spoke do Azure a SD-WANs que abrangem ambientes de nuvem e locais, com troca dinâmica de rotas entre redes virtuais do Azure e dispositivos de borda SD-WAN.

• Otimize a conectividade com o Azure e com datacenters locais nas filiais que têm saídas locais para a Internet. O alcance do backbone da Microsoft, combinado com sua capacidade, resiliência e política de roteamento cold potato, pode fazer dele uma rede subjacente de alto desempenho para SD-WANs globais.

• Utilize o backbone da Microsoft para todo o tráfego Azure-para-Azure (entre regiões e entre geografias).

• Use redes MPLS (comutação de rótulos multiprotocolo) existentes como infraestruturas subjacentes de alto desempenho.

• Migre de redes MPLS para conectividade com a internet de forma gradual, minimizando o impacto nos negócios.

As seções a seguir pressupõem que você esteja familiarizado com os conceitos básicos do paradigmaSD-WAN e a arquitetura do backbone Microsoft. As interconexões de backbone da Microsoft interligam as regiões do Azure entre si e com a internet pública.

Architecture

Organizações que têm presença global e uma presença do Azure em várias regiões usam vários serviços de conectividade para criar suas redes corporativas e se conectar ao backbone da Microsoft.

• Serviços de conectividade dedicados, como IPVPNs (redes virtuais privadas de IP) MPLS, normalmente são implantados nos maiores sites.

• Os circuitos do Azure ExpressRoute conectam o backbone da Microsoft às instalações de datacenter usando o modelo de conectividade ponto a ponto ou diretamente à rede MPLS usando o modelo de conectividade de qualquer ponto para qualquer ponto.

• As filiais que têm apenas conectividade com a Internet podem usar VPNs IPsec para se conectar ao datacenter local mais próximo e usar a conexão do ExpressRoute desse datacenter para acessar Azure recursos. Ou eles podem usar VPNs IPsec para se conectar diretamente às redes hub-and-spoke do Azure.

Os projetos de SD-WAN podem diferir quanto aos serviços de conectividade que pretendem substituir. Algumas organizações podem querer continuar a usar links dedicados ou MPLS para grandes instalações e implantar SD-WAN apenas para substituir VPNs IPsec baseadas na Internet herdadas em sites pequenos. Outras organizações podem querer estender sua SD-WAN para sites conectados ao MPLS e usar a rede MPLS existente como uma base de alto desempenho. Algumas organizações também podem desativar sua rede MPLS e criar toda a sua rede corporativa como uma sobreposição lógica em cima de subposições públicas ou compartilhadas, como a Internet pública e o backbone Microsoft.

A arquitetura dá suporte a todos os escopos deste artigo e se baseia nos seguintes princípios:

• Os dispositivos SD-WAN são implantados como appliances virtuais de rede (NVAs) na rede hub-and-spoke do hub de cada região do Azure e configurados como hubs de SD-WAN que encerram túneis provenientes de ambientes locais.

• Os dispositivos SD-WAN no Azure são configurados para estabelecer túneis entre si a fim de criar um overlay hub-to-hub em malha completa que transporta o tráfego com eficiência entre regiões do Azure. Essa sobreposição também encaminha o tráfego entre ambientes locais geograficamente distantes sobre a rede de backbone da Microsoft.

• Dispositivos SD-WAN são implantados em todos os sites locais cobertos pela solução SD-WAN e são configurados para estabelecer túneis com as NVAs de SD-WAN na região ou nas regiões do Azure mais próximas. Diferentes sites podem usar diferentes serviços de transporte de camada subjacente, como a Internet pública ou a conectividade via ExpressRoute.

• O tráfego de um site é roteado para os NVAs de SD-WAN na região do Azure mais próxima, independentemente de o destino estar no Azure ou em outro site local. Em seguida, o tráfego passa pela rede de sobreposição entre hubs.

SD-WAN produtos podem usar protocolos e recursos proprietários para criar túneis diretos entre dois sites e obter melhor desempenho do que retransmitir o tráfego por meio de NVAs SD-WAN em Azure.

O diagrama a seguir mostra a arquitetura de alto nível de um SD-WAN global que usa o backbone Microsoft, a Internet pública e as conexões dedicadas do ExpressRoute como sobreposições.

O diagrama mostra três regiões do Azure na parte superior, e em cada região há NVAs de SD-WAN e redes virtuais. O backbone da Microsoft fica abaixo das regiões e hospeda um overlay SD-WAN de alto desempenho. A internet pública fica sob o backbone. As linhas tracejadas mostram como as SD-WAN NVAs em regiões próximas do Azure roteiam o tráfego entre dois sites locais. Linhas sólidas identificadas como túnel SD-WAN por link de Internet se estendem das NVAs até os equipamentos locais do cliente (CPEs) de SD-WAN nas instalações do cliente. Um símbolo de PoP (ponto de presença) da internet fica onde esses túneis se conectam à internet. À direita, uma linha sólida rotulada como túnel SD-WAN pela conexão dedicada do ExpressRoute liga uma NVA a um CPE, com um símbolo de PoP do ExpressRoute abaixo do backbone. Uma linha final, rotulada como "internet link", conecta a internet ao CPE SD-WAN dentro das instalações do cliente.

Carrege um arquivo PowerPoint desta arquitetura.

Conecte redes hub-and-spoke do Azure às SD-WANs

Esta seção apresenta recomendações para implantar dispositivos de borda SD-WAN como NVAs em uma rede do Azure existente com topologia hub-and-spoke.

SD-WAN NVAs na rede virtual do hub

Recomendamos a topologia hub-and-spoke para a criação de redes escalonáveis em uma região Azure usando redes virtuais gerenciadas pelo cliente. A rede virtual do hub hospeda componentes compartilhados, como NVAs e serviços nativos que fornecem funções de rede, como firewall, balanceamento de carga e conectividade com sites locais por meio de VPNs site a site ou ExpressRoute. A rede virtual do hub é o local lógico para SD-WAN NVAs porque centraliza funções de rede compartilhadas e fornece acesso consistente a redes remotas. Esses NVAs são gateways não Microsoft que conectam o hub a essas redes remotas.

Implante SD-WAN NVAs em redes virtuais de hub das seguintes maneiras:

• Use um NIC (controlador de interface de rede) para todo o tráfego SD-WAN. Você pode adicionar outras NICs, como uma NIC de gerenciamento, para atender aos requisitos de segurança e conformidade ou seguir as diretrizes do fornecedor para implantações de Azure.

• Anexe a NIC usada para SD-WAN tráfego a uma sub-rede dedicada. Defina o tamanho da sub-rede com base no número de NVAs SD-WAN implantadas para atender aos requisitos de alta disponibilidade (HA) e escala ou taxa de transferência. Para obter mais informações, consulte Conectar redes hub-and-spoke do Azure a SD-WANs e Limites e considerações de design do Servidor de Rota do Azure.

• Associe NSGs (grupos de segurança de rede) à NIC de tráfego SD-WAN, diretamente ou no nível da sub-rede, para permitir conexões de sites locais remotos pelas portas TCP/UDP que a solução SD-WAN usa.

• Habilite o encaminhamento de IP na NIC usada para o tráfego de SD-WAN.

Rotear servidor na rede virtual do hub

O Servidor de Rotas automatiza a troca de rotas entre as SD-WAN NVAs e a pilha de rede definida por software (SDN) do Azure. O Route Server oferece suporte ao BGP como um protocolo de roteamento dinâmico. Ao estabelecer adjacências BGP entre o Servidor de Rotas e as SD-WAN NVAs:

• O Servidor de Rota injeta rotas para todos os sites locais conectados à SD-WAN nas tabelas de rotas da rede virtual e todas as VMs (máquinas virtuais) Azure aprendem essas rotas.

• O Route Server propaga rotas para todos os prefixos IP no espaço de endereços das redes virtuais para todos os sites conectados por SD-WAN.

Configure o Servidor de Rota com os seguintes requisitos:

• Implante o Servidor de Rota em uma sub-rede dedicada na rede virtual do hub. Defina a capacidade do Servidor de Rota com base no número de VMs na rede hub-and-spoke.

• Para habilitar a troca dinâmica de rotas para todas as redes virtuais spoke, configure o emparelhamento entre redes virtuais para permitir que essas redes virtuais spoke usem o gateway e o Route Server da rede virtual de hub. Para obter mais informações, consulte as perguntas frequentes do servidor de rota.

• O Servidor de Rota e os NVAs de SD-WAN estão conectados a sub-redes diferentes, portanto, configure as sessões BGP entre o Servidor de Rota e os NVAs de SD-WAN para usar o suporte a multihop do eBGP. Há suporte para qualquer número de saltos entre dois e o máximo suportado pelo SD-WAN NVA. Para obter mais informações sobre como configurar as adjacências do BGP para o Servidor de Rota, consulte Criar e configurar o Servidor de Rota usando o portal Azure.

• Configure duas /32 rotas estáticas na NVA do SD-WAN para os pontos de extremidade do BGP que o Servidor de Rotas expõe. Essa configuração garante que a tabela de rotas do NVA sempre contenha rotas para seus pares BGP de saltos múltiplos (não conectados diretamente).

O servidor de rota não está no caminho dos dados. É uma entidade do plano de controle que propaga rotas entre as NVAs SD-WAN e a pilha SDN da rede virtual. A pilha de SDN do Azure gerencia o encaminhamento efetivo do tráfego entre as NVAs de SD-WAN e as VMs na rede virtual, conforme mostra a figura a seguir. Para obter esse comportamento de roteamento, o Route Server injeta todas as rotas que aprende das NVAs de SD-WAN ao definir o próximo salto como o endereço da NVA.

O Servidor de Rota não dá suporte ao IPv6. Essa arquitetura é apenas para IPv4.

O diagrama mostra a propagação do servidor de rotas entre o equipamento SD-WAN nas instalações do cliente (CPE) e a pilha SDN da rede virtual. Ele não encaminha o tráfego entre o SD-WAN CPE e as VMs na rede virtual. Na parte superior, há três tabelas de rotas de rede virtual com a indicação de próximo salto para as instalações do cliente e uma seta apontando para a SD-WAN NVA. Três linhas partem dessas seções e convergem para a rede virtual. Uma linha aponta da primeira tabela de rotas para o SdWanNvaSubnet. Duas setas pontilhadas de dois lados conectam os NVAs no RouteServerSubnet e no SDwanNvaSubnet. Uma seta pontilhada, rotulada como "ponto de extremidade de túnel SD-WAN de IP público", conecta a NVA à instalação do cliente, que inclui o CPE SD-WAN. Uma tabela de rotas de rede virtual fica abaixo das outras três tabelas. A seção da qual ela faz parte inclui três sub-redes, uma seção do Route Server que inclui a instância 0 e a instância 1, uma NVA SD-WAN e integração com a pilha do DNS do Azure. Uma seta bidirecional conecta a primeira tabela de rotas no canto superior esquerdo, a integração de pilha do DNS do Azure e a tabela de rotas no canto inferior esquerdo. A legenda do diagrama é mostrada no canto inferior direito. Uma seta cinza pontilhada mostra a propagação da rota, que ocorre no plano de controle. Uma seta laranja sólida mostra o caminho de tráfego real, que ocorre no plano de dados.

HA para NVAs SD-WAN com o Servidor de Rota

O Servidor de Rota tem HA integrada. Dois recursos de computação dão suporte a uma única instância do Route Server, e a Azure implanta esses recursos de computação em zonas de disponibilidade diferentes (em regiões com zonas de disponibilidade) ou no mesmo conjunto de disponibilidade (em regiões sem zonas de disponibilidade). Como resultado, uma instância do Servidor de Rota expõe dois endpoints BGP, um endpoint para cada recurso computacional. Você obtém HA para as NVAs SD-WAN implantando várias instâncias em zonas de disponibilidade diferentes ou no mesmo conjunto de disponibilidade. Cada SD-WAN NVA estabelece duas sessões BGP, uma com cada endpoint exposto pelo Servidor de Rotas.

Essa arquitetura não depende de balanceadores de carga Azure. Ele tem as seguintes características:

• Nenhum balanceador de carga público expõe terminais de túnel SD-WAN. Cada NVA SD-WAN expõe seu próprio ponto de extremidade de túnel. Os pares remotos estabelecem vários túneis, com um túnel para cada SD-WAN NVA em Azure.

• Nenhum balanceador de carga interno é necessário para distribuir o tráfego de VMs Azure em vários dispositivos de borda SD-WAN. O Servidor de Rota e a pilha de SDN do Azure dão suporte ao roteamento de múltiplos caminhos de custo igual (ECMP). Se vários dispositivos de borda anunciarem uma rota para o mesmo destino, o Servidor de Rota injetará várias rotas na tabela de rotas da rede virtual, com uma rota para cada dispositivo de borda que anunciou o destino. Cada rota tem um próximo salto diferente que corresponde ao endereço IP do dispositivo de borda que o anunciou, na tabela de rotas da rede virtual. A pilha SDN distribui o tráfego para esse destino em todos os próximos saltos disponíveis.

A figura a seguir mostra a arquitetura de HA resultante.

Diagrama que mostra a arquitetura de alta disponibilidade (HA) para o Servidor de Rotas e as NVAs de SD-WAN em uma rede virtual de um hub. A rede virtual do hub contém três sub-redes organizadas da esquerda para a direita: VmSubnet à esquerda, RouteServerSubnet no meio e SdwanNvaSubnet à direita. A VmSubnet contém uma tabela de rotas de rede virtual que indica que o próximo salto para a instalação do cliente aponta para o SD-WAN NVAs. O RouteServerSubnet contém uma instância do Servidor de Rota com dois recursos de computação rotulados instância 0 na parte superior e instância 1 na parte inferior. A SdwanNvaSubnet contém duas NVAs SD-WAN dispostas verticalmente, com a SD-WAN NVA 0 na parte superior e a SD-WAN NVA 1 na parte inferior. As linhas conectam as instâncias do Servidor de Rotas a ambas as NVAs de SD-WAN e representam sessões BGP para propagação de rotas no plano de controle. Cada SD-WAN NVA estabelece duas sessões BGP, uma com cada instância do Servidor de Rotas. Um rótulo BGP é exibido entre o RouteServerSubnet e o SdwanNvaSubnet. Linhas sólidas se estendem de cada SD-WAN NVA em direção a duas instalações de cliente mostradas à extrema direita e representam caminhos de tráfego redundantes no plano de dados. A instalação superior do cliente contém SD-WAN CPE (equipamento local do cliente) 0 que se conecta ao SD-WAN NVA 0, enquanto a instalação do cliente inferior contém SD-WAN CPE 1 que se conecta ao SD-WAN NVA 1. Os endereços IP públicos (pontos de extremidade de túnel do SD-WAN) situam-se entre as NVAs do SD-WAN e as instalações do cliente e indicam que cada NVA expõe seu próprio ponto de extremidade de túnel público. No canto inferior esquerdo, o componente de integração da pilha de SDN do Azure se conecta à tabela de rotas de rede virtual. Uma legenda no canto inferior direito mostra que setas pontilhadas cinzas representam a propagação de rota no plano de controle, enquanto linhas laranjas sólidas representam caminhos de tráfego redundantes no plano de dados.

N-active versus ativo-em-espera de alta disponibilidade

Quando você usa múltiplos NVAs SD-WAN e os emparelha com um Servidor de Roteamento, o BGP controla o failover. Se um NVA SD-WAN ficar offline, ele interrompe a divulgação de rotas para o Servidor de Roteamento. Em seguida, o Servidor de Rota retira as rotas que aprendeu com esse dispositivo na tabela de rotas da rede virtual. Como resultado, se um SD-WAN NVA não fornecer mais conectividade a sites remotos de SD-WAN devido a uma falha no dispositivo ou na rede de subposição, ele não aparecerá mais como um possível próximo salto para esses sites na tabela de rotas da rede virtual. Todo o tráfego vai para os demais dispositivos operacionais. Para obter mais informações sobre a propagação de rotas entre SD-WAN NVAs e o Route Server, consulte Rotas anunciadas por um par BGP para o Route Server.

O diagrama a seguir mostra esse comportamento de failover.

Diagrama que mostra o failover baseado em BGP em uma arquitetura de alta disponibilidade (HA) de Servidor de Rotas e NVA de SD-WAN quando um dispositivo falha. A rede virtual do hub contém três sub-redes: VmSubnet, RouteServerSubnet e SdwanNvaSubnet. No canto inferior esquerdo, uma tabela de rotas de rede virtual exibe informações sobre o próximo salto para as instalações do cliente. Nesta tabela, a entrada para SD-WAN NVA 0 está riscada, o que indica que houve falha e que ela não é mais um próximo salto válido. Um rótulo abaixo dele indica que o SD-WAN NVA 1 agora é o próximo salto ativo para o tráfego. O RouteServerSubnet contém uma instância do Servidor de Rota com dois recursos de computação rotulados instância 0 e instância 1. O SdwanNvaSubnet contém dois NVAs SD-WAN: SD-WAN NVA 0 e SD-WAN NVA 1. Linhas sólidas que representam sessões BGP conectam as instâncias do Servidor de Rotas a ambas as NVAs SD-WAN no plano de controle, mas a NVA SD-WAN 0 não anuncia mais rotas devido à sua falha. Um rótulo BGP é exibido entre o RouteServerSubnet e o SdwanNvaSubnet. À direita, o diagrama mostra duas instalações do cliente, cada uma associada à sua própria CPE SD-WAN. Uma linha sólida se estende da SD-WAN NVA 1 até as instalações do cliente que atende, representando o caminho ativo redundante do tráfego no plano de dados. Não há caminho de tráfego ativo que conecte o SD-WAN NVA 0 à instalação do cliente que ele atende, porque esse NVA falhou. Os pontos de extremidade do túnel IP público ficam entre as NVAs e as instalações do cliente. No canto inferior esquerdo, o componente de integração da pilha de SDN do Azure se conecta à tabela de rotas de rede virtual. Uma legenda no canto inferior direito explica que as linhas cinza pontilhadas representam a propagação de rota no plano de controle, enquanto linhas laranjas sólidas representam caminhos de tráfego redundantes no plano de dados.

O failover controlado por BGP e o roteamento ECMP permitem arquiteturas de HA N ativas com N dispositivos que processam simultaneamente o tráfego. Arquiteturas ativo-passivas também podem ser implementadas porque o Route Server honra os atributos AS Path do BGP. Se diferentes dispositivos de borda SD-WAN anunciarem rotas para os mesmos destinos com tamanhos de caminho AS diferentes, o dispositivo de borda SD-WAN que anuncia rotas com o caminho mais curto se tornará o próximo salto preferencial. Se esse dispositivo falhar ou retirar algumas de suas rotas, o Servidor de Rota estenderá as rotas com valores de caminho AS mais longos anunciados por outros dispositivos. O único atributo BGP que as NVAs SD-WAN podem usar para expressar um grau de preferência pelas rotas que anunciam ao Servidor de Rotas é o caminho AS.

Recomendamos arquiteturas de HA N-ativas porque elas permitem a utilização otimizada dos recursos sem NVAs de SD-WAN em espera e com escalabilidade horizontal. Para aumentar a capacidade, várias NVAs podem ser executadas em paralelo, até o número máximo de vizinhos BGP com suporte do Route Server. O modelo de HA N ativo requer que os NVAs SD-WAN atuem como roteadores de camada 3 sem estado. Quando existem vários túneis para um site, o sistema pode rotear conexões TCP de forma assimétrica. Os fluxos original e de resposta da mesma conexão TCP podem ser roteados por túneis e NVAs diferentes. A figura a seguir mostra um exemplo de uma conexão TCP roteada assimetricamente. Essas assimetrias de roteamento são possíveis para conexões TCP iniciadas na rede virtual ou em um site local.

Diagrama que mostra o roteamento assimétrico em arquiteturas de HA ativas, em que o fluxo original e o fluxo de resposta de uma conexão TCP atravessam diferentes SD-WAN NVAs. A rede virtual do hub contém três sub-redes organizadas da esquerda para a direita: VmSubnet, RouteServerSubnet e SdwanNvaSubnet. No canto inferior esquerdo, uma tabela de rotas de rede virtual exibe dois possíveis próximos saltos para o destino 192.168.1.0/24: SD-WAN NVA 0 e SD-WAN NVA 1. A RouteServerSubnet na parte central contém uma instância do Servidor de Rotas com dois recursos de computação rotulados como instância 0 e instância 1. O SdwanNvaSubnet à direita contém dois NVAs SD-WAN organizados verticalmente: SD-WAN NVA 0 na parte superior e SD-WAN NVA 1 na parte inferior. Linhas sólidas que representam sessões BGP conectam as instâncias do Servidor de Rotas às duas NVAs de SD-WAN e mostram que ambas as NVAs anunciam a mesma rota para o destino 192.168.1.0/24 com o mesmo comprimento do caminho AS para o Servidor de Rotas. Um rótulo BGP é exibido entre o RouteServerSubnet e o SdwanNvaSubnet. Uma seta vermelha aponta de SdwanNvaSubnet para VMSubnet. Essa seta representa o fluxo de tráfego original do site remoto de SD-WAN local para o Azure. O equipamento nas instalações do cliente (CPE) da SD-WAN local seleciona a SD-WAN NVA 1 para essa conexão de entrada, e o túnel termina na SD-WAN NVA 1 no lado do Azure. Uma seta verde aponta da VMSubnet para SD-WAN NVA 0 na sub-rede SdwanNva. Essa seta representa o tráfego de resposta de Azure para o site de SD-WAN local. A pilha Azure SDN roteia esse fluxo de resposta para SD-WAN NVA 0 porque é um dos próximos saltos possíveis para 192.168.1.0/24, de acordo com a tabela de rotas de rede virtual com roteamento ECMP. As instalações do cliente aparecem à extrema direita e têm como endereço de destino 192.168.1.0/24. No canto inferior esquerdo, o componente de integração da pilha de SDN do Azure se conecta à tabela de rotas de rede virtual. Uma legenda no canto inferior direito mostra duas setas direcionais com rótulos de texto: uma seta vermelha identificada como direção original (do ambiente local para o Azure) e uma seta verde identificada como direção de resposta (do Azure para o ambiente local).

Considere arquiteturas de alta disponibilidade (HA) ativo-passivo apenas quando as NVAs de SD-WAN no Azure executarem funções de rede que exijam simetria de roteamento, como inspeção de firewall com monitoramento de estado. Evite essa abordagem devido a suas implicações de escalabilidade. A execução de mais funções de rede em NVAs SD-WAN aumenta o consumo de recursos. As arquiteturas de HA ativo-passivo permitem que apenas uma NVA processe o tráfego a qualquer momento. Como resultado, toda a camada SD-WAN só pode ser escalada verticalmente até o tamanho máximo de VM do Azure compatível, e não horizontalmente. Implemente funções de rede com estado que exigem simetria de roteamento em clusters de NVA separados que dependem do Azure Load Balancer para alta disponibilidade n-ativa.

Considerações sobre conectividade do ExpressRoute

Essa arquitetura dá suporte a uma abordagem de SD-WAN completa, para que você possa criar sua rede corporativa como uma sobreposição lógica sobre a Internet pública e o backbone Microsoft. Você também pode usar circuitos dedicados do ExpressRoute para abordar cenários específicos descritos nas seções a seguir.

Cenário 1: Coexistência de ExpressRoute e SD-WAN

As soluções SD-WAN podem coexistir com a conectividade do ExpressRoute quando os dispositivos SD-WAN são implantados apenas em um subconjunto de sites. Por exemplo, algumas organizações podem implantar soluções SD-WAN como uma substituição para VPNs IPsec tradicionais em sites que têm apenas conectividade com a Internet e usar serviços MPLS e circuitos do ExpressRoute para grandes sites e datacenters, como mostra a figura a seguir.

Diagrama que mostra SD-WAN e o cenário de coexistência do ExpressRoute em que os dispositivos SD-WAN são implantados em um subconjunto de sites, enquanto os circuitos do ExpressRoute atendem a grandes sites e datacenters. O diagrama exibe três Azure regiões organizadas horizontalmente na parte superior, cada uma contendo uma rede virtual de hub com componentes compartilhados. Cada rede virtual de hub contém uma SD-WAN NVA, um Servidor de Rotas e um gateway do ExpressRoute. O backbone Microsoft fica horizontalmente abaixo das regiões Azure como uma banda horizontal. Um rótulo na camada de backbone da Microsoft diz: overlay de alto desempenho sobre o backbone da Microsoft. Abaixo do backbone Microsoft fica a camada da Internet como outra banda horizontal. Na parte inferior do diagrama, cinco instalações do cliente são exibidas. No lado esquerdo do diagrama, três instalações do cliente contêm, cada uma, um dispositivo CPE (equipamento local do cliente) de SD-WAN, e todas possuem rótulos de link de túnel SD-WAN pela Internet. A instalação de cliente mais à esquerda se conecta por um PoP (ponto de presença na internet) ao SD-WAN NVA na primeira região do Azure. A segunda instalação do cliente se conecta por meio de um PoP de internet ao SD-WAN NVA na primeira região do Azure. A terceira instalação do cliente, da esquerda, conecta-se por meio de um PoP de internet ao SD-WAN NVA na segunda região do Azure. No lado direito do diagrama, duas instalações de cliente se conectam por meio do emparelhamento privado do ExpressRoute. Essas linhas de conexão passam por um PoP do ExpressRoute até os gateways do ExpressRoute nas regiões do Azure. Eles oferecem conectividade dedicada para sites de grande porte.

Esse cenário de coexistência requer NVAs de SD-WAN implantadas no Azure para rotear o tráfego entre sites conectados à SD-WAN e sites conectados a circuitos do ExpressRoute. Você pode configurar o Route Server para propagar rotas entre gateways de rede virtual do ExpressRoute e NVAs SD-WAN no Azure ao habilitar o recurso AllowBranchToBranch. A propagação de rotas entre o gateway de rede virtual do ExpressRoute e as NVAs de SD-WAN ocorre por BGP. O Route Server estabelece sessões BGP com o gateway de rede virtual do ExpressRoute e com as NVAs de SD-WAN, e propaga para cada vizinho as rotas que aprende do outro vizinho. A plataforma gerencia as sessões BGP entre o Servidor de Rota e o gateway de rede virtual do ExpressRoute. Os usuários não precisam configurar essas sessões explicitamente. Eles só precisam habilitar o sinalizador AllowBranchToBranch ao implantar o Route Server.

Diagrama que mostra a configuração do Servidor de Rotas para a propagação de rotas entre gateways de rede virtual do ExpressRoute e NVAs SD-WAN em uma rede virtual de hub. O diagrama exibe três sub-redes organizadas horizontalmente: GatewaySubnet à esquerda, RouteServerSubnet no centro e SdwanNvaSubnet à direita. Um dispositivo de borda do cliente do ExpressRoute aparece ao lado do GatewaySubnet. Uma instância do Servidor de Rota com dois recursos de computação rotulados instância 0 na parte superior e instância 1 na parte inferior aparece ao lado do RouteServerSubnet. Um dispositivo NVA SD-WAN aparece ao lado do SdwanNvaSubnet. Linhas horizontais rotuladas como BGP se estendem entre as três sub-redes e representam sessões de BGP para propagação de rotas no plano de controle. As linhas vão do dispositivo de borda do cliente do ExpressRoute, passando pelas instâncias do Servidor de Rota, e outras linhas BGP vão do Servidor de Rota para o NVA SD-WAN. No canto inferior esquerdo, uma caixa rotulada como instalação conectada ao ExpressRoute do Cliente identifica um site local que usa o emparelhamento privado do ExpressRoute. No canto inferior direito, uma caixa rotulada como "Instalação SD-WAN do cliente" identifica um site local que usa túneis SD-WAN. Uma caixa de anotação horizontal aparece abaixo da sub-rede do Servidor de Rota e exibe a configuração AllowBranchToBranch definida como TRUE, que indica que o sinalizador de configuração do Servidor de Rota está ativo para propagação de rota bidirecional.

Esse cenário de coexistência entre SD-WAN e ExpressRoute permite migrações de redes MPLS para SD-WAN. Ele fornece um caminho entre sites de MPLS herdados e sites de SD-WAN recém-migrados e elimina a necessidade de rotear o tráfego por meio de datacenters locais. Use esse padrão durante as migrações e em cenários que ocorrem de fusões e aquisições da empresa para interconectar redes diferentes.

Cenário nº 2: ExpressRoute como uma rede de subposição SD-WAN

Se os seus sites locais tiverem conectividade com o ExpressRoute, você poderá configurar dispositivos SD-WAN para estabelecer túneis com as NVAs do hub SD-WAN que são executadas no Azure por meio do ExpressRoute. Você pode usar tanto o peering privado do ExpressRoute quanto o Microsoft peering.

Conexão privada de redes

Quando você usa o emparelhamento privado do ExpressRoute como a rede de subposição, todos os sites SD-WAN locais estabelecem túneis para as NVAs do hub SD-WAN em Azure. Esse cenário não requer propagação de rotas entre os NVAs SD-WAN e o gateway de rede virtual do ExpressRoute; portanto, você deve configurar o Route Server com o sinalizador AllowBranchToBranch definido como false.

Essa abordagem requer configuração BGP adequada nos roteadores do lado do cliente ou do provedor que encerram a conexão do ExpressRoute. Os roteadores Microsoft Enterprise Edge (MSEEs) anunciam todas as rotas das redes virtuais conectadas ao circuito, seja diretamente ou por meio de emparelhamento de rede virtual. Para encaminhar o tráfego destinado a redes virtuais por meio de um túnel SD-WAN, o site local deve aprender essas rotas no dispositivo SD-WAN, não no circuito do ExpressRoute.

Como resultado, os roteadores do lado do cliente ou do provedor que terminam a conexão do ExpressRoute devem filtrar as rotas que recebem de Azure. As únicas rotas na rede de sobreposição devem permitir que os dispositivos SD-WAN locais alcancem os NVAs do hub SD-WAN em Azure. Os clientes que planejam usar o emparelhamento privado do ExpressRoute como uma rede de subposição SD-WAN devem verificar se seus dispositivos de roteamento dão suporte a essa configuração. Esse requisito é especialmente relevante para clientes que não controlam os dispositivos de borda usados para o ExpressRoute, como quando uma operadora MPLS fornece o circuito do ExpressRoute sobre um serviço IPVPN.

Diagrama que mostra o peering privado do ExpressRoute usado como rede underlay de SD-WAN. Os sites SD-WAN locais estabelecem túneis para as NVAs de hub SD-WAN no Azure por meio da conectividade do ExpressRoute. O diagrama mostra uma rede virtual de hub com três sub-redes organizadas horizontalmente da esquerda para a direita: GatewaySubnet, RouteServerSubnet e SdwanNvaSubnet. O GatewaySubnet à esquerda contém um dispositivo de borda do cliente do ExpressRoute representado como um ícone de gateway. A RouteServerSubnet na região central contém uma instância do Servidor de Rota com dois recursos de computação mostrados como caixas empilhadas, rotuladas como “instância 0” na parte superior e “instância 1” na parte inferior, que representam a redundância interna integrada do Servidor de Rota. O SdwanNvaSubnet à direita contém um dispositivo NVA SD-WAN. As linhas verticais conectam as sub-redes e representam a conectividade da rede, com conexões do dispositivo de borda do cliente do ExpressRoute que passam pelo Route Server até a NVA de SD-WAN. No canto inferior esquerdo, uma caixa grande rotulada como instalação conectada ao ExpressRoute do Cliente indica um site local com conectividade do ExpressRoute e contém um dispositivo de borda do cliente do ExpressRoute. Uma linha de conexão se estende das instalações do cliente por meio de um circuito do ExpressRoute até o dispositivo de borda do cliente do ExpressRoute na GatewaySubnet. Uma caixa de anotação horizontal abaixo do Servidor de Rota mostra a configuração AllowBranchToBranch definida como false. Essa anotação indica que o sinalizador de configuração do Servidor de Rota está definido como falso porque esse cenário não requer a propagação de rotas entre os NVAs de SD-WAN e o gateway de rede virtual do ExpressRoute. Na parte inferior do diagrama, uma legenda mostra três tipos de linha com seus significados: uma linha tracejada cinza para propagação de rota no Azure e no ExpressRoute (BGP), uma linha laranja contínua para túnel SD-WAN e uma linha tracejada preta para propagação de rota do SD-WAN (qualquer protocolo de roteamento compatível com o fornecedor de SD-WAN).

Emparelhamento da Microsoft

Você também pode usar o emparelhamento Microsoft do ExpressRoute como uma rede de suporte para túneis SD-WAN. Nesse cenário, as NVAs do hub de SD-WAN no Azure expõem apenas pontos de extremidade de túnel públicos, usados pelos CPEs de SD-WAN (equipamentos localizados nas instalações do cliente) tanto nos locais conectados à Internet quanto nos locais conectados ao ExpressRoute. O emparelhamento Microsoft do ExpressRoute tem pré-requisitos mais complexos do que o emparelhamento privado, mas recomendamos essa opção como uma rede subjacente pelas duas razões a seguir:

• Ele não requer gateways de rede virtual do ExpressRoute na rede virtual do hub. Ele remove a complexidade, reduz o custo e permite que a solução SD-WAN dimensione além dos limites de largura de banda do gateway quando você não usa o ExpressRoute FastPath.

• Essa abordagem fornece uma separação clara entre rotas de sobreposição e subposição. Os MSEEs anunciam apenas os prefixos públicos da rede da Microsoft para a borda do cliente ou do provedor. Você pode colocar essas rotas em uma instância de VRF (roteamento e encaminhamento virtual) separada e propagá-las apenas para um segmento de rede de perímetro da LAN do site. Os dispositivos SD-WAN propagam as rotas para a rede corporativa do cliente na camada de sobreposição, incluindo rotas para redes virtuais. Os clientes que consideram essa abordagem devem verificar se podem configurar seus dispositivos de roteamento adequadamente ou solicitar o serviço apropriado de sua operadora MPLS.

Considerações de MPLS

A migração de redes corporativas mpls tradicionais para arquiteturas de rede mais modernas com base no paradigma SD-WAN requer esforço e tempo significativos. Use essa arquitetura para implementar migrações em fases do MPLS para o SD-WAN. As seções a seguir descrevem dois cenários típicos de migração.

Desativação de MPLS em fases

Os clientes que desejam criar um SD-WAN sobre a Internet pública e o backbone Microsoft e desativar completamente os IPVPNs do MPLS ou outros serviços de conectividade dedicados podem usar o cenário de coexistência do ExpressRoute e SD-WAN durante a migração. Nesse cenário, sites conectados ao SD-WAN podem alcançar sites conectados ao MPLS herdado. Depois de migrar um site para o SD-WAN e implantar dispositivos CPE, você poderá desativar o link do MPLS. O site pode acessar toda a rede corporativa por meio de seus túneis SD-WAN para as regiões de Azure mais próximas.

Diagrama que mostra a arquitetura de desativação gradual do MPLS durante a migração das redes corporativas MPLS tradicionais para SD-WAN. Três seções rotuladas como “Azure region” aparecem horizontalmente na parte superior do diagrama, da esquerda para a direita. Cada região do Azure contém uma caixa com borda tracejada que representa uma rede virtual de hub. Cada rede virtual de hub contém uma NVA SD-WAN, um Route Server e um gateway de ExpressRoute. Uma ampla faixa horizontal rotulada Microsoft backbone fica abaixo das três regiões Azure e representa a infraestrutura de rede global Microsoft de alto desempenho que interconecta as regiões Azure. Outra faixa horizontal, rotulada como internet, fica abaixo do backbone da Microsoft e representa a camada subjacente da Internet pública que os túneis de SD-WAN atravessam. Uma terceira faixa identificada como "MPLS backbone" aparece à direita, paralela à faixa da internet, e representa a infraestrutura da rede MPLS privada. Cinco instalações do cliente são exibidas na parte inferior do diagrama. Da esquerda para a direita: três instalações de cliente SD-WAN, cada uma contendo um dispositivo CPE de SD-WAN, com linhas de conexão rotuladas como "túnel SD-WAN por link de Internet", estendendo-se para cima pela camada da Internet para se conectarem a NVAs de SD-WAN em diferentes regiões do Azure por meio de PoPs (pontos de presença). A quarta instalação é rotulada como instalação do cliente migrada para SD-WAN e também contém um dispositivo CPE SD-WAN com um túnel por link da Internet. A quinta instalação, à extrema direita, está identificada como instalação de cliente MPLS e se conecta à terceira região do Azure por meio de uma conexão de emparelhamento privado do ExpressRoute que passa por um PoP do ExpressRoute e se conecta ao gateway do ExpressRoute. Um rótulo no centro diz “desativação gradual do MPLS”.

Quando todos os sites são migrados, você pode desativar o IPVPN do MPLS junto com os circuitos do ExpressRoute que o conectam ao backbone do Microsoft. Você não precisa mais de gateways de rede virtual do ExpressRoute e pode desprovisioná-los. Os NVAs do hub SD-WAN em cada região tornam-se o único ponto de entrada na rede hub-and-spoke dessa região.

Integração do MPLS

As organizações que não confiam em redes públicas e compartilhadas para fornecer o desempenho e a confiabilidade desejados podem decidir usar uma rede MPLS existente como uma subposição de classe empresarial para sites ou aplicativos específicos.

O cenário de ExpressRoute como camada subjacente de SD-WAN oferece suporte à integração de SD-WAN e MPLS. Prefira o emparelhamento Microsoft do ExpressRoute em vez de emparelhamento privado. Quando você usa o peering da Microsoft, a rede MPLS e a internet pública se tornam underlays funcionalmente equivalentes. Eles fornecem acesso a todas as extremidades de túnel SD-WAN expostas pelos NVAs do hub SD-WAN no Azure. Um CPE SD-WAN implantado em um site que tem conectividade de Internet e MPLS pode estabelecer vários túneis para os hubs de SD-WAN em Azure em ambas as camadas. O CPE pode rotear conexões diferentes por meio de túneis diferentes com base em políticas de nível de aplicativo gerenciadas pelo plano de controle SD-WAN.

Diagrama que mostra a arquitetura de integração do MPLS, em que as organizações usam uma rede MPLS existente como uma subposição de classe empresarial para túneis SD-WAN junto com a conectividade com a Internet pública. Três regiões do Azure aparecem horizontalmente ao longo da parte superior do diagrama. Cada região Azure contém uma rede virtual de hub com um dispositivo NVA SD-WAN. Uma ampla faixa horizontal rotulada Microsoft backbone fica abaixo das regiões Azure. Abaixo do backbone da Microsoft, duas redes subjacentes paralelas aparecem como faixas horizontais: no lado esquerdo, uma faixa rotulada como “internet” representa a rede subjacente da Internet pública e, no lado direito, uma faixa rotulada como “MPLS backbone” representa a rede subjacente da rede MPLS privada. Cinco instalações do cliente são exibidas na parte inferior do diagrama. No lado esquerdo, na área de sobreposição da Internet, três instalações aparecem da esquerda para a direita. A primeira instalação é identificada como instalação do cliente SD-WAN com underlay de Internet e contém um dispositivo CPE SD-WAN. Uma linha de conexão identificada como túnel SD-WAN sobre o link da Internet se estende para cima desta instalação, passa pela camada da Internet e se conecta a uma NVA SD-WAN na primeira região do Azure. A segunda instalação é rotulada como instalação do cliente SD-WAN com underlays MPLS e de Internet e contém um dispositivo CPE de SD-WAN. As linhas de conexão se estendem para cima a partir deste local, através das camadas de internet e MPLS. A terceira instalação deste grupo é rotulada como instalação do cliente SD-WAN, com underlays de internet e MPLS, e contém um dispositivo CPE SD-WAN. As linhas de conexão se estendem desse local pelas duas camadas de underlay e se conectam às NVAs de SD-WAN no Azure, o que demonstra como locais com ambos os tipos de conectividade estabelecem vários túneis em diferentes camadas de underlay. No lado direito, na área de backbone MPLS, aparecem duas instalações. A primeira instalação é rotulada SD-WAN de instalação do cliente com MPLS e subposições da Internet e contém um dispositivo CPE SD-WAN. As linhas de conexão se estendem para cima dessa instalação por meio da camada de backbone do MPLS e da camada da Internet. A segunda instalação da extrema direita é rotulada como SD-WAN de instalação do cliente com base em MPLS e contém um dispositivo CPE SD-WAN. Uma linha de conexão rotulada como túnel SD-WAN sobre MPLS se estende para cima dessa instalação, passa pela camada de backbone MPLS e se conecta a uma NVA SD-WAN na terceira região do Azure. A rede MPLS e a Internet pública funcionam como redes subjacentes equivalentes quando o peering da Microsoft do ExpressRoute é usado. Os CPEs de SD-WAN estabelecem vários túneis para hubs de SD-WAN no Azure nas redes subjacentes e roteiam diferentes conexões por túneis distintos com base em políticas no nível do aplicativo gerenciadas pelo plano de controle da SD-WAN.

Preferência de roteamento do Route Server

Em ambos os cenários de MPLS nas duas seções anteriores, algumas filiais podem ser conectadas à MPLS IPVPN e à SD-WAN. Como resultado, as instâncias do Servidor de Rota implantadas nas redes virtuais de hub podem aprender as mesmas rotas por meio de gateways do ExpressRoute e de NVAs de SD-WAN.

Use a preferência de roteamento do Route Server para controlar qual caminho deve ser preferido e propagado nas tabelas de rotas das redes virtuais.

A preferência de roteamento é útil quando não é possível usar prepending de AS Path. Um exemplo são os serviços IPVPN do MPLS que não dão suporte a configurações personalizadas de BGP. Dependendo de como a rede MPLS agrega rotas, o nível de controle que você tem sobre os atributos de suas rotas MPLS e sua preferência entre SD-WAN e MPLS durante a migração, talvez seja necessário forçar o Servidor de Rota a preferir rotas MPLS em vez de rotas SD-WAN ou rotas SD-WAN em rotas MPLS.

Limites do Servidor de Rota e considerações de design

O Servidor de Rota é central para essa arquitetura. Ele propaga rotas entre NVAs SD-WAN implantadas em redes virtuais e a pilha SDN da Azure subjacente. Ele fornece uma abordagem baseada em BGP para operar vários NVAs de SD-WAN para HA e escalabilidade horizontal. Ao projetar grandes SD-WANs com base nessa arquitetura, contabilize os limites de escalabilidade do Servidor de Rota.

As seções a seguir fornecem diretrizes sobre os máximos de escalabilidade e como lidar com cada limite.

Rotas anunciadas por um par BGP para um Servidor de Rotas

O Servidor de Rota não define um limite explícito para o número de rotas que podem ser anunciadas aos gateways de rede virtual do ExpressRoute quando o sinalizador AllowBranchToBranch está definido. No entanto, os gateways do ExpressRoute propagam ainda mais as rotas que aprendem com o Servidor de Rota para os circuitos do ExpressRoute aos quais se conectam.

Azure limita o número de rotas que os gateways do ExpressRoute podem anunciar para os circuitos do ExpressRoute por meio de emparelhamento privado. Ao projetar soluções SD-WAN com base nas diretrizes deste artigo, verifique se as rotas SD-WAN não atingem esse limite. Se você atingir o limite, as sessões BGP entre gateways do ExpressRoute e circuitos do ExpressRoute serão descartadas e a conectividade entre redes virtuais e redes remotas conectadas por meio do ExpressRoute será perdida.

O número total de rotas que os gateways do ExpressRoute anunciam para os circuitos é a soma das rotas aprendidas com o Route Server e dos prefixos que compõem o espaço de endereçamento da rede hub-and-spoke do Azure. Para evitar interrupções causadas pela queda de sessões BGP, recomendamos as seguintes medidas de mitigação:

• Use recursos nativos do dispositivo SD-WAN (resumo e filtragem de rotas) para limitar o número de rotas anunciadas para o Servidor de Rota, se disponível.

• Use os alertas do Azure Monitor para detectar proativamente picos no número de rotas que os gateways do ExpressRoute anunciam. Monitore a métrica contagem de rotas anunciadas ao vizinho.

Pares de BGP

O Servidor de Rota pode estabelecer sessões BGP com até um número máximo de pares BGP. Esse limite determina quantos SD-WAN NVAs podem estabelecer adjacências BGP com o Servidor de Rota. Ele também define a taxa de transferência agregada máxima que pode ser suportada em todos os túneis SD-WAN. Espera-se que apenas grandes SD-WANs atinjam esse limite. Não há solução alternativa além de criar várias redes hub-and-spoke, cada uma com seus próprios gateways e servidores de rotas.

VMs participantes

Os gateways de rede virtual do ExpressRoute e o Servidor de Rota configuram as rotas que aprendem com seus pares remotos para todas as VMs em sua própria rede virtual e em redes virtuais emparelhadas diretamente. Para proteger o Route Server contra o consumo excessivo de recursos causado por atualizações de roteamento para VMs, o Azure define um limite para o número de VMs em uma única rede hub-and-spoke. Ajuste a capacidade do Servidor de Rota com base no número esperado de VMs na rede virtual de hub que contém o Servidor de Rota, bem como em todas as redes virtuais spoke emparelhadas diretamente.

Contributors

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autores principais:

• Federico Guerrini | Arquiteto sênior de soluções de nuvem
• Khush Kaviraj | Arquiteto de Soluções na Nuvem

Para ver perfis de LinkedIn não públicos, entre em LinkedIn.

Próxima etapa

• Microsoft Well-Architected Framework

Recursos relacionados

• Conectar uma rede local para Azure usando o ExpressRoute
• Implantar NVAs altamente disponíveis