Este artigo destina-se a arquitetos de rede que desejam projetar SD-WANs (redes de longa distância definidas por software) para conectar instalações locais entre si e com o Azure. Ele descreve uma arquitetura que permite que os clientes do Azure usem seus investimentos existentes na plataforma, criando sobreposições SD-WAN globais eficientes sobre o backbone da Microsoft.
Cenários aplicáveis
As recomendações neste artigo são independentes do fornecedor e aplicáveis a qualquer tecnologia SD-WAN que não seja da Microsoft que atenda a dois pré-requisitos básicos:
- Dependência de protocolos de encapsulamento que usam TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol) como o transporte subjacente, como ser IPSec ESP de modo túnel com NAT-Traversal.
- Suporte ao BGP (Border Gateway Protocol) v4 para troca de rotas com entidades externas. Nenhuma suposição é feita sobre o protocolo de roteamento usado pelos dispositivos SD-WAN não Microsoft para trocar informações de roteamento entre si.
Os clientes que aderirem a essas recomendações podem usar sua tecnologia SD-WAN de escolha para atingir as seguintes metas:
- Integrar produtos SD-WAN a uma rede de hub-and-spoke do Azure existente, automatizando a troca de rotas entre a Rede Virtual do Azure e dispositivos SD-WAN.
- Otimizar a conectividade (com o Azure e datacenters locais) para filiais com interrupções locais da Internet. O alcance do backbone da Microsoft, combinado com sua capacidade, resiliência e política de roteamento "cold potato", sugere que ele pode ser usado como uma base de alto desempenho para SD-WANs globais.
- Use o backbone da Microsoft para todo o tráfego do Azure para o Azure (entre regiões e entre geografias).
- Use redes MPLS (Multi-Protocol-Label-Switching) existentes como subcamadas de alto desempenho. Ele também pode ser usado para substituir uma rede MPLS existente em uma abordagem em fases que minimiza o efeito nos negócios.
As seções a seguir pressupõem que o leitor esteja familiarizado com os conceitos básicos do paradigma de SD-WAN e com a arquitetura do backbone da Microsoft. O backbone da Microsoft interconecta as regiões do Azure entre si e com a Internet pública.
Arquitetura
As organizações com presença global e uma área de cobertura do Azure em várias regiões normalmente usam uma combinação de serviços de conectividade para implementar suas redes corporativas e se conectar ao backbone da Microsoft:
- Serviços de conectividade dedicados, como IPVPNs (Internet-Protocol-Virtual-Private-Networks) MPLS, podem ser usados nos maiores locais, como datacenters ou sedes.
- Sites grandes podem incluir conectividade dedicada ao backbone da Microsoft por meio de circuitos do ExpressRoute, usando um dos modelos de conectividade com suporte. Mais especificamente, um site pode usar circuitos ponto a ponto dedicados para se conectar ao local de emparelhamento do ExpressRoute mais próximo. Ou pode aplicar seu IPVPN MPLS para acessar circuitos do ExpressRoute fornecidos pela operadora MPLS.
- As filiais que só têm 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 os recursos do Azure. Ou eles podem usar VPNs IPSec para se conectar diretamente às redes de hub-and-spoke do Azure.
Os projetos SD-WAN podem ter escopos diferentes em termos de quais serviços de rede tradicionais eles pretendem substituir. Algumas organizações podem querer manter links dedicados ou MPLS para grandes instalações e implantar uma SD-WAN apenas para substituir VPNs IPSec herdadas baseadas na Internet 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. Por fim, algumas organizações podem querer descartar seus IPVPNs MPLS. ou qualquer serviço de conectividade dedicado, para adotar o paradigma de SD-WAN. Dessa forma, eles podem desenvolver toda a sua rede corporativa como uma sobreposição lógica sobre subposições públicas ou compartilhadas (a internet pública e o backbone da Microsoft).
A arquitetura descrita neste artigo oferece suporte a todos os escopos listados anteriormente e se baseia nos seguintes princípios:
- Os dispositivos de SD-WAN são implantados como NVAs (Network Virtual Appliances) na rede hub-and-spoke de cada região do Azure e configurados como hubs SD-WAN que encerram túneis de sites locais.
- Os dispositivos SD-WAN no Azure são configurados para estabelecer túneis entre si, criando assim uma sobreposição de hub a hub totalmente interligada que pode transportar com eficiência o tráfego entre regiões do Azure e retransmitir o tráfego entre sites locais geograficamente distantes, sobre o backbone da Microsoft.
- Os dispositivos SD-WAN são implantados em todos os sites locais cobertos pela solução SD-WAN e configurados para estabelecer túneis para os NVAs SD-WAN nas regiões mais próximas do Azure. Diferentes sites podem usar diferentes serviços de transporte como base para os túneis, como internet pública, conectividade do ExpressRoute e assim por diante.
- O tráfego de um site para qualquer destino, seja no Azure ou em outro site local, é roteado para os NVAs SD-WAN na região do Azure mais próxima. Em seguida, ele roteia por meio da sobreposição hub-to-hub.
Os produtos SD-WAN podem usar protocolos e recursos proprietários para detectar, uma vez estabelecidos dinamicamente, túneis diretos entre dois locais podem fornecer melhor desempenho do que retransmitir tráfego por meio de NVAs SD-WAN no Azure.
A arquitetura de alto nível de uma SD-WAN global que usa o backbone da Microsoft, a Internet pública e conexões ER dedicadas como subjacentes é mostrada na imagem a seguir.
Figura 1: Arquitetura de alto nível de uma SD-WAN global que usa o backbone da Microsoft, a Internet pública e conexões ER dedicadas como subjacentes. A linha tracejada preta mostra como o tráfego entre dois sites locais pode ser roteado por meio de NVAs SD-WAN implantados em regiões do Azure geograficamente próximas aos sites. O backbone da Microsoft, devido ao seu alcance, capacidade e política de roteamento "cold potato", pode proporcionar um desempenho substancialmente melhor/previsível do que a internet pública, especialmente para conexões de longa distância.
Produtos SD-WAN em redes hub-and-spoke do Azure
Esta seção fornece recomendações para implantar dispositivos CPE SD-WAN que não sejam da Microsoft como NVAs em uma rede do Azure de hub-and-spoke existente.
NVAs SD-WAN na rede virtual do hub
Hub-and-Spoke é a topologia que a Microsoft recomenda para criar redes escalonáveis em uma região do Azure usando redes virtuais gerenciadas pelo cliente. A rede virtual de hub hospeda componentes compartilhados, como NVAs que não são da Microsoft e serviços nativos que fornecem funções de rede, como firewall, balanceamento de carga e conectividade com VPNs site a site de sites locais ou ExpressRoute A rede virtual de hub é o local natural para NVAs SD-WAN, que, em última análise, são gateways não Microsoft que fornecem acesso a redes remotas.
Os NVAs SD-WAN devem ser implantados em redes virtuais de hub da seguinte maneira:
- Um único NIC (controlador de interface de rede) é usado para todo o tráfego SD-WAN. Outros NICs, como um NIC de gerenciamento, podem ser adicionadas para atender aos requisitos de segurança e conformidade ou para aderir às diretrizes do fornecedor para implantações do Azure.
- O NIC usado para o tráfego SD-WAN deve ser conectado a uma sub-rede dedicada. O tamanho da sub-rede deve ser definido com base no número de NVAs SD-WAN implantados para atender aos requisitos de alta disponibilidade (HA) e escala ou taxa de transferência, discutidos posteriormente neste artigo.
- Os NSGs (Grupos de Segurança de Rede) devem ser associados ao NIC de tráfego SD-WAN, diretamente ou no nível da sub-rede. Essa associação permite conexões de sites locais remotos pelas portas TCP/UDP usadas pela solução SD-WAN.
- O encaminhamento de IP deve estar habilitado no NIC usado para tráfego SD-WAN.
Servidor de Rota do Azure na rede virtual de hub
O Servidor de Rota do Azure automatiza a troca de rotas entre NVAs SD-WAN e a pilha SDN (Rede Definida por Software) 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 Rota e os NVA(s) SD-WAN:
- As rotas para todos os sites locais conectados à SD-WAN são injetadas nas tabelas de rotas da rede virtual e aprendidas por todas as VMs do Azure.
- As rotas para todos os prefixos IP incluídos no espaço de endereço de redes virtuais são propagadas para todos os sites conectados a SD-WAN.
O Servidor de Rota deve ser configurado da maneira a seguir.
- Ele deve ser implantado em uma sub-rede dedicada na rede virtual de hub de acordo com Criar e configurar o Servidor de Rota usando o portal do Azure.
- Para habilitar a troca automatizada de rotas para todas as redes virtuais de spoke, o emparelhamento de rede virtual deve ser configurado para permitir que as redes virtuais spoke usem o gateway da rede virtual de hub e o Servidor de Rota. Detalhes disponíveis nas Perguntas frequentes sobre o Servidor de Rota do Azure.
- Como o Servidor de Rota e os NVAs SD-WAN estão conectados a sub-redes diferentes, as sessões BGP entre o Servidor de Rota e os NVAs SD-WAN devem ser configuradas com suporte a eBGP de vários saltos. Qualquer número de saltos entre 2 e o máximo com suporte do NVA SD-WAN pode ser definido. Detalhes sobre como configurar adjacências BGP para o Servidor de Rota estão disponíveis em Criar e configurar o Servidor de Rota usando o portal do Azure.
- Duas
/32rotas estáticas devem ser configuradas no NVA SD-WAN para os pontos de extremidade BGP expostos pelo Servidor de Rota. Essa configuração garante que a tabela de rotas do NVA sempre contenha rotas para seus pares BGP de vários saltos (não conectados diretamente).
O Servidor de Rota não está no caminho de dados. É uma entidade de plano de controle. Ele propaga rotas entre o NVA SD-WAN e a pilha SDN da rede virtual, mas o encaminhamento de tráfego real entre o NVA SD-WAN e as máquinas virtuais na rede virtual é feito pela pilha SDN do Azure, conforme mostrado na figura a seguir. Para obter esse comportamento de roteamento, o Servidor de Rota injeta todas as rotas aprendidas dos NVAs SD-WAN com o próximo salto definido para o próprio endereço do NVA.
O Servidor de Rota não oferece suporte a IPv6 a partir de agora. Essa arquitetura é apenas para IPv4.
Figura 2. O Servidor de Rota oferece suporte à propagação de rotas entre o CPE SD-WAN e a pilha SDN da rede virtual, mas não encaminha o tráfego entre o CPE SD-WAN e as máquinas virtuais na rede virtual.
Alta disponibilidade para NVAs SD-WAN com o Servidor de Rota
O Servidor de Rota tem HA integrada. Dois nós de computação retornam uma única instância do Servidor de Rota. Eles são implantados em zonas de disponibilidade diferentes, para as regiões que têm suporte à zona de disponibilidade ou no mesmo conjunto de disponibilidade. Eles expõem dois pontos de extremidade BGP. A HA para os NVAs SD-WAN é obtida implantando várias instâncias em diferentes zonas de disponibilidade, para regiões que oferecem suporte a elas ou no mesmo conjunto de disponibilidade. Cada NVA SD-WAN estabelece duas sessões BGP com ambos os pontos de extremidade expostos pelo Servidor de Rota.
A arquitetura descrita neste artigo não depende dos Balanceadores de Carga do Azure. Mais especificamente:
Nenhum balanceador de carga público expõe pontos de extremidade 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, um para cada NVA SD-WAN no Azure.
Nenhum balanceador de carga interno distribui o tráfego originado pelas VMs do Azure para os NVAs SD-WAN. O Servidor de Rota e a pilha de SDN do Azure dão suporte ao roteamento ECMP (Equal-Cost Multipath). Se vários NVAs configurarem adjacências BGP com o Servidor de Rota e anunciarem rotas para os mesmos destinos (como em, redes remotas e sites conectados à SD-WAN) usando o mesmo grau de preferência, o Servidor de Rota:
- Injeta várias rotas para esses destinos na tabela de rotas da rede virtual.
- Define cada rota para usar um NVA diferente como o próximo salto.
A pilha SDN distribui o tráfego para esses destinos em todos os próximos saltos disponíveis.
A arquitetura de HA resultante é mostrada na figura a seguir:
Figura 3. O Servidor de Rota oferece suporte ao roteamento ECMP (Equal-Cost Multipath). Os Balanceadores de Carga do Azure não são necessários quando vários NVAs SD-WAN são usados para fins de disponibilidade e/ou escalabilidade.
N-ativo versus ativo em stand-by de alta disponibilidade
Quando você usa vários NVAs SD-WAN e os emparelha com o Servidor de Rota, o BGP conduz o failover. Se um NVA SD-WAN ficar offline, ele interromperá as rotas de publicidade para o Servidor de Rota. As rotas aprendidas com o dispositivo com falha são retiradas da tabela de rotas da rede virtual. Assim, se um NVA SD-WAN não fornecer mais conectividade a sites SD-WAN remotos devido a uma falha, no próprio dispositivo ou na subposição, ele não aparecerá mais como um possível próximo salto em direção aos sites remotos na tabela de rotas da rede virtual. Todo o tráfego vai para os demais dispositivos íntegros. Para obter mais informações sobre a propagação de rotas entre NVAs SD-WAN e o Servidor de Rota, consulte Rotas anunciadas por um par BGP para o Servidor de Rota.
Figura 4. Failover controlado por BGP. Se o NVA SD-WAN nº 0 ficar offline, suas sessões BGP com o Servidor de Rota serão fechadas. O NVA SD-WAN nº 0 é removido da tabela de rotas da rede virtual como um possível próximo salto para o tráfego que vai do Azure para o site local.
O failover orientado por BGP e o roteamento ECMP naturalmente habilitam arquiteturas de HA N-ativas com dispositivos N processando tráfego simultaneamente. Mas você também pode usar o BGP para implementar arquiteturas HA ativas e passivas: configure o dispositivo passivo para anunciar ao Servidor de Rota as rotas com um grau de preferência menor do que seu par ativo. O Servidor de Rota descarta as rotas recebidas do dispositivo passivo se ele receber do dispositivo ativo quaisquer rotas para os mesmos destinos com um grau mais alto de preferência. E canaliza apenas as últimas rotas na tabela de rotas da rede virtual.
Se o dispositivo ativo falhar ou retirar algumas de suas rotas, o Servidor de Rota:
- Seleciona as rotas correspondentes anunciadas pelo dispositivo passivo.
- Canaliza as rotas na tabela de rotas da rede virtual.
Os únicos atributos BGP que os NVAs SD-WAN podem usar para expressar um grau de preferência pelas rotas que anunciam ao Servidor de Rota são o Caminho AS.
Recomendamos arquiteturas de HA N-ativas porque elas permitem o uso ideal de recursos (não há NVAs SD-WAN em stand-by) e escalabilidade horizontal. Para aumentar a taxa de transferência, vários NVAs podem ser executados em paralelo, até o número máximo de pares BGP com suporte do Servidor de Rota. Para obter mais informações, consulte Pares BGP. Mas 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, as conexões TCP podem ser roteadas assimetricamente. Ou seja, os fluxos ORIGINAL e REPLY da mesma conexão TCP podem ser roteados através de túneis diferentes 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 no site local.
Figura 5. Roteamento assimétrico em arquiteturas de HA ativas/ativas. NVA SD-WAN nº 0 e NVA SD-WAN nº 1 anunciam a mesma rota para o destino 192.168.1.0/24 (site SD-WAN remoto) com o mesmo comprimento de caminho AS para o servidor de rotas. O fluxo ORIGINAL (do site remoto SD-WAN para o Azure, caminho vermelho) é roteado por meio do túnel terminado, no lado do Azure, pelo SD-WAN NVA nº 1. O CPE SD-WAN local seleciona esse túnel. A pilha SDN do Azure roteia o fluxo REPLY (do Azure para o site SD-WAN remoto, caminho verde) para SD-WAN NVA n º0, que é um dos próximos saltos possíveis para 192.168.1.0/24, de acordo com a tabela de rotas da rede virtual. Não é possível garantir que o próximo salto escolhido pela pilha SDN do Azure seja sempre o mesmo CPE SD-WAN que recebeu o fluxo ORIGINAL.
As arquiteturas de HA ativas e passivas só devem ser consideradas quando NVAs SD-WAN no Azure executam outras funções de rede que exigem simetria de roteamento, como firewall com monitoramento de estado. Não recomendamos essa abordagem devido às suas implicações na escalabilidade. A execução de mais funções de rede em NVAs SD-WAN aumenta o consumo de recursos. Ao mesmo tempo, a arquitetura HA ativa e passiva permite ter um único tráfego de processamento NVA pontual. Ou seja, toda a camada SD-WAN só pode ser dimensionada até o tamanho máximo da VM do Azure a que ela dá suporte, não expandida. Execute funções de rede com monitoração de estado que exigem simetria de roteamento em clusters NVA separados que dependem do Standard Load Balancer para HA n-ativa.
Considerações sobre conectividade do ExpressRoute
A arquitetura descrita neste artigo permite que os clientes adotem totalmente o paradigma de SD-WAN e criem sua rede corporativa como uma sobreposição lógica sobre a Internet pública e o backbone da Microsoft. Ele também oferece suporte ao uso de circuitos dedicados do ExpressRoute para abordar cenários específicos, descritos posteriormente.
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 um substituto para VPNs IPSec tradicionais em sites com conectividade com a Internet somente. Em seguida, eles usam serviços MPLS e circuitos do ExpressRoute para grandes sites e datacenters, conforme mostrado na figura a seguir.
Figura 6. As soluções SD-WAN podem coexistir com a conectividade do ExpressRoute quando os dispositivos CPE SD-WAN são implantados apenas em um subconjunto de sites.
Esse cenário de coexistência exige que os NVAs SD-WAN implantados no Azure sejam capazes de rotear o tráfego entre sites conectados à SD-WAN e sites conectados a circuitos do ExpressRoute. O Servidor de Rota pode ser configurado para propagar rotas entre gateways de rede virtual do ExpressRoute e NVAs SD-WAN no Azure habilitando o recurso, conforme documentado AllowBranchToBranch aqui. A propagação de rota entre o gateway de rede virtual do ExpressRoute e as NVA(s) SD-WAN acontece por BGP. O Servidor de Rota estabelece sessões BGP com ambos e propaga para cada peer as rotas aprendidas com o outro. 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 configurá-los explicitamente, mas apenas habilitar o sinalizador AllowBranchToBranch ao implantar o Route Server.
Figura 7. A propagação de rota entre o gateway de rede virtual do ExpressRoute e os NVA(s) SD-WAN acontece por BGP. O Servidor de Rota estabelece sessões BGP com ambas e propaga rotas em ambas as direções quando configurado com "AllowBranchToBranch=TRUE". O Servidor de Rota atua como um refletor de rota, ou seja, não faz parte do caminho de dados.
Esse cenário de coexistência entre SD-WAN e ExpressRoute permite migrações de redes MPLS para SD-WAN. Ele oferece um caminho entre sites MPLS herdados e sites SD-WAN recém-migrados, eliminando a necessidade de rotear o tráfego por meio de datacenters locais. Esse padrão pode ser usado não apenas durante migrações, mas também em cenários decorrentes de fusões e aquisições de empresas, proporcionando uma interconexão perfeita de redes díspares.
Cenário 2: ExpressRoute como uma subposição SD-WAN
Se seus sites locais tiverem conectividade do ExpressRoute, você poderá configurar dispositivos SD-WAN para configurar túneis para os NVAs de hub SD-WAN em execução no Azure sobre o circuito ou circuitos do ExpressRoute. A conectividade do ExpressRoute pode ser feita por meio de circuitos ponto a ponto ou de uma rede MPLS. Você pode usar o emparelhamento privado do ExpressRoute e o emparelhamento da Microsoft.
Emparelhamento privado
Quando você usa o emparelhamento privado do ExpressRoute como base, todos os sites SD-WAN locais estabelecem túneis para os NVAs de hub SD-WAN no Azure. Nenhuma propagação de rota entre os NVAs SD-WAN e o gateway de rede virtual do ExpressRoute é necessária nesse cenário (ou seja, o Servidor de Rota deve ser configurado com o sinalizador "AllowBranchToBranch" definido como falso).
Essa abordagem requer configuração BGP adequada nos roteadores do lado do cliente ou do provedor que encerram a conexão do ExpressRoute. Na verdade, os MSEEs (Microsoft Enterprise Edge Routers) anunciam todas as rotas para as redes virtuais conectadas ao circuito (diretamente ou por meio de emparelhamento de rede virtual). Mas, para encaminhar o tráfego destinado a redes virtuais por meio de um túnel SD-WAN, o site local deve aprender essas rotas desde o dispositivo SD-WAN - e não do circuito ER.
Portanto, os roteadores do lado do cliente ou do provedor que encerram a conexão do ExpressRoute devem filtrar as rotas recebidas do Azure. As únicas rotas configuradas na subposição devem ser aquelas que permitem que os dispositivos SD-WAN locais alcancem os NVAs do hub SD-WAN no Azure. Os clientes que desejam usar o emparelhamento privado do ExpressRoute como uma base SD-WAN devem verificar se podem configurar seus dispositivos de roteamento adequadamente. Isso é especialmente relevante para clientes que não têm controle direto sobre seus dispositivos de borda para o ExpressRoute. Um exemplo é quando o circuito do ExpressRoute é fornecido por uma operadora MPLS sobre um serviço IPVPN.
Figura 8. Emparelhamento privado do ExpressRoute como uma base SD-WAN. Nesse cenário, os roteadores do lado do cliente e do provedor recebem as rotas para a rede virtual que encerram a conexão do ExpressRoute, nas sessões BGP de emparelhamento privado de ER e no CPE SD-WAN. Somente o CPE SD-WAN deve propagar as rotas do Azure para a LAN do site.
Emparelhamento da Microsoft
Você também pode usar o emparelhamento do ExpressRoute da Microsoft como uma base para túneis SD-WAN. Nesse cenário, os NVAs de hub SD-WAN no Azure expõem apenas pontos de extremidade de túnel público, que são usados por CPEs SD-WAN em sites conectados à Internet, se houver, e por CPEs SD-WAN em sites conectados ao ExpressRoute. Embora o emparelhamento da Microsoft do ExpressRoute tenha pré-requisitos mais complexos do que o emparelhamento privado, recomendamos usar essa opção como subjacente devido a estas duas vantagens:
Ele não requer gateways de rede virtual do ExpressRoute na rede virtual de hub. Ele elimina a complexidade, reduz o custo e permite que a solução SD-WAN seja dimensionada além dos limites de largura de banda do próprio gateway quando você não usa o FastPath do ExpressRoute.
Ele fornece uma separação limpa entre rotas de sobreposição e subposição. Os MSEEs só anunciam os prefixos públicos da rede Microsoft para a borda do cliente ou provedor. Você pode gerenciar essas rotas em um VRF separado e propagar apenas para um segmento DMZ da LAN do site. Os dispositivos SD-WAN propagam as rotas para a rede corporativa do cliente na sobreposição, incluindo rotas para redes virtuais. Os clientes que considerarem essa abordagem devem verificar se podem configurar seus dispositivos de roteamento de acordo ou solicitar o serviço adequado à operadora MPLS.
Considerações de MPLS
A migração de redes corporativas MPLS tradicionais para arquiteturas de rede mais modernas baseadas no paradigma SD-WAN requer um esforço significativo e uma quantidade considerável de tempo. A arquitetura descrita neste artigo permite migrações SD-WAN em fases. Dois cenários típicos de migração são discutidos posteriormente.
Desativação de MPLS em fases
Os clientes que desejam criar uma SD-WAN sobre a Internet pública e o backbone da Microsoft e desativar completamente os IPVPNs MPLS ou outros serviços de conectividade dedicados podem usar o cenário de coexistência do ExpressRoute e SD-WAN descrito na seção anterior durante a migração. Ele permite que sites conectados a SD-WAN alcancem sites ainda conectados ao MPLS herdado. Assim que um site é migrado para os dispositivos SD-WAN e CPE são implantados, seu link MPLS pode ser desativado. O site pode acessar toda a rede corporativa por meio de seus túneis SD-WAN para as regiões mais próximas do Azure.
Figura 9. O cenário de "coexistência do ExpressRoute e SD-WAN" permite a desativação em fases do MPLS.
Quando todos os sites são migrados, o IPVPN MPLS pode ser desativado, juntamente com os circuitos do ExpressRoute que o conectam ao backbone da Microsoft. Os gateways de rede virtual do ExpressRoute não são mais necessários e podem ser desprovisionados. Os NVAs de hub SD-WAN em cada região se tornam o único ponto de entrada na rede de 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 um suporte de classe empresarial. As duas opções são:
- Um subconjunto de sites, como datacenters ou grandes filiais.
- Um subconjunto de conexões, normalmente tráfego sensível à latência ou de missão crítica.
O cenário ExpressRoute como uma subposição de SD-WAN descrito anteriormente permite a integração de SD-WAN e MPLS. O emparelhamento da Microsoft do ExpressRoute deve ser preferido em relação ao emparelhamento privado pelos motivos discutidos anteriormente. Além disso, quando o emparelhamento da Microsoft é usado, a rede MPLS e a Internet pública tornam-se subjacentes funcionalmente equivalentes. Eles fornecem acesso a todos os pontos de extremidade de túnel SD-WAN expostos por NVAs de hub SD-WAN no Azure. Um CPE SD-WAN implantado em um site com conectividade MPLS e Internet pode estabelecer vários túneis para os hubs SD-WAN no Azure em ambas as subposições. Eles podem então rotear diferentes conexões por meio de túneis diferentes, com base em políticas de nível de aplicativo gerenciadas pelo plano de controle de SD-WAN.
Figura 10. O cenário "ExpressRoute como uma subposição de SD-WAN" permite a integração de SD-WAN e MPLS.
Preferência de roteamento do Servidor de Rota
Em ambos os cenários MPLS abordados nas duas seções anteriores, alguns sites de filial podem ser conectados tanto ao IPVPN MPLS quanto à SD-WAN. Como resultado, as instâncias do Servidor de Rota implantadas nas redes virtuais de hub podem aprender as mesmas rotas de gateways do ExpressRoute e NVAs SD-WAN. A preferência de roteamento do Servidor de Rota permite controlar qual caminho deve ser preferido e inserido nas tabelas de rotas das redes virtuais. A preferência de roteamento é útil quando a precedência de Caminho AS não pode ser usada. Um exemplo são os serviços IPVPN MPLS que não oferecem suporte a configurações BGP personalizadas nos PEs que encerram conexões do ExpressRoute.
Limites do Servidor de Rota e considerações de design
O Servidor de Rota é a pedra angular da arquitetura descrita neste artigo. Ele propaga rotas entre NVAs SD-WAN implantados em redes virtuais e a pilha SDN subjacente do Azure. Ele fornece uma abordagem baseada em BGP para executar vários NVAs SD-WAN para alta disponibilidade e escalabilidade horizontal. Quando você projeta SD-WANs grandes com base nessa arquitetura, os limites de escalabilidade do Servidor de Rota devem ser levados em consideração.
As seções a seguir fornecem orientação sobre os máximos de escalabilidade e como lidar com cada limite.
Rotas anunciadas por um par BGP para o Servidor de Rota
O Servidor de Rota não define um limite explícito para o número de rotas que podem ser anunciadas para Gateways de Rede Virtual do ExpressRoute quando o sinalizador AllowBranchToBranch é definido. No entanto, os Gateways do ExpressRoute propagam ainda mais as rotas que aprendem do Servidor de Rota para os circuitos do ExpressRoute aos quais estão conectados.
Há um limite para o número de rotas que os Gateways do ExpressRoute podem anunciar para circuitos do ExpressRoute por meio do emparelhamento privado, documentado em Limites de assinatura e serviço, cotas e restrições do Azure. Ao projetar soluções SD-WAN com base nas diretrizes deste artigo, é fundamental garantir que as rotas SD-WAN não façam com que esse limite seja atingido. Se atingido, as sessões BGP entre os circuitos de Gateways do ExpressRoute e do ExpressRoute serão descartadas e a conectividade entre redes virtuais e redes remotas conectadas via ExpressRoute será perdida.
O número total de rotas anunciadas para circuitos pelos Gateways do ExpressRoute é a soma do número de rotas aprendidas do Servidor de Rota e o número de prefixos que compõem o espaço de endereço da rede de hub-and-spoke do Azure. Para evitar paralisações devido a sessões BGP descartadas, recomendamos que você implemente as seguintes atenuações:
- Use os recursos nativos de dispositivos SD-WAN para limitar o número de rotas anunciadas ao Servidor de Rota, se o recurso estiver disponível.
- Use os Alertas do Azure Monitor para detectar proativamente picos no número de rotas anunciadas pelos Gateways do ExpressRoute. A métrica a ser monitorada é denominada Contagem de rotas anunciadas ao par, conforme documentado no monitoramento do ExpressRoute.
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 o número máximo de NVAs SD-WAN que podem estabelecer adjacências BGP com o Servidor de Rota e, portanto, a taxa de transferência agregada máxima que pode ter suporte em todos os túneis SD-WAN. Espera-se que apenas grandes SD-WANs atinjam esse limite. Não existem soluções alternativas para superá-lo, além de criar várias redes de hub-and-spoke, cada uma com seus próprios gateways e servidores de rota.
VMs participantes
Os Gateways de Rede Virtual e o Servidor de Rota configuram as rotas que aprendem de seus pares remotos para todas as VMs em sua própria rede virtual e em redes virtuais diretamente emparelhadas. Para proteger o Servidor de Rota do consumo excessivo de recursos devido a atualizações de roteamento para VMs, o Azure define um limite no número de VMs que podem existir em uma única rede de hub-and-spoke. Não existem soluções alternativas para superar esse limite, além de criar várias redes hub-and-spoke, cada uma com seus próprios gateways e servidores de rota, na mesma região.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Principais autores:
- Federico Guerrini | Arquiteto de Soluções em Nuvem Sênior
- Khush Kaviraj | Arquiteto de Soluções em Nuvem
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.