Este artigo destina-se a arquitetos de rede que desejam projetar redes de longa distância definidas por software (SD-WANs) 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 transporte subjacente, como IPSec ESP de modo de túnel com NAT-Traversal.
- Suporte ao Border Gateway Protocol (BGP) 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 os seguintes objetivos:
- Integre produtos SD-WAN em um hub e rede spoke do Azure existente, automatizando a troca de rotas entre a Rede Virtual do Azure e dispositivos SD-WAN.
- Otimize a conectividade (com o Azure e datacenters locais) para filiais com intervalos de internet locais. O alcance do backbone da Microsoft, combinado com sua capacidade, resiliência e política de roteamento de "batata fria", 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 suportes de alto desempenho. Ele também pode ser usado para substituir uma rede MPLS existente em uma abordagem faseada que minimiza o efeito sobre os negócios.
As seções a seguir pressupõem que o leitor esteja familiarizado com os conceitos básicos do paradigma 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 presença multirregional do Azure 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 (MPLS Internet-Protocol-Virtual-Private-Networks), podem ser usados nos maiores locais, como datacenters ou sede.
- Sites grandes podem incluir conectividade dedicada ao backbone da Microsoft por meio de circuitos de Rota Expressa, usando um dos modelos de conectividade suportados. Mais especificamente, um site pode usar circuitos dedicados ponto-a-ponto para se conectar ao local de emparelhamento de Rota Expressa mais próximo. Ou pode aplicar seu IPVPN MPLS para acessar circuitos de Rota Expressa 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 ExpressRoute desse datacenter para acessar recursos do Azure. Ou eles podem usar VPNs IPSec para se conectar diretamente às redes hub e spoke do Azure.
Os projetos SD-WAN podem ter âmbitos diferentes em termos dos serviços de rede tradicionais que 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 a MPLS e usar a rede MPLS existente como uma base de alto desempenho. Finalmente, algumas organizações podem querer descartar seus IPVPNs MPLS. ou qualquer serviço de conectividade dedicado, para adotar o paradigma SD-WAN. Desta forma, eles podem construir toda a sua rede corporativa como uma sobreposição lógica em cima de underlays públicos ou compartilhados (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 SD-WAN são implantados como Dispositivos Virtuais de Rede (NVAs) na rede hub e spoke de cada região do Azure e configurados como hubs SD-WAN que terminam túneis de sites locais.
- Os dispositivos SD-WAN no Azure são configurados para estabelecer túneis uns com os outros, criando assim uma sobreposição hub-to-hub totalmente interligada que pode transportar tráfego de forma eficiente entre regiões do Azure e retransmitir tráfego entre sites locais geograficamente distantes, além do 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 do Azure mais próximas. Diferentes sites podem usar diferentes serviços de transporte como base para os túneis, como internet pública, conectividade de Rota Expressa, 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 é encaminhado através da sobreposição hub-to-hub.
Os produtos SD-WAN podem usar protocolos e recursos proprietários para detetar, uma vez estabelecidos dinamicamente, túneis diretos entre dois sites 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 underlays é 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 underlays. 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 de "batata fria", pode levar a um desempenho substancialmente melhor/previsível do que a Internet pública, especialmente para conexões de longo curso.
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 existente do Azure hub e spoke.
NVAs SD-WAN na rede virtual do hub
Hub and Spoke é a topologia que a Microsoft recomenda para criar redes escaláveis em uma região do Azure usando redes virtuais gerenciadas pelo cliente. A rede virtual do hub hospeda componentes compartilhados, como NVAs não Microsoft e serviços nativos que fornecem funções de rede, como firewall, balanceamento de carga e conectividade com sites locais por meio de VPNs de site 2 ou Rota Expressa. A rede virtual do hub é o local natural para NVAs SD-WAN, que, em última análise, são gateways que não são da Microsoft que fornecem acesso a redes remotas.
Os NVAs SD-WAN devem ser implantados em redes virtuais de hub da seguinte maneira:
- Um único controlador de interface de rede (NIC) é usado para todo o tráfego SD-WAN. Outras NICs, como uma 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.
- A NIC usada para o tráfego SD-WAN deve ser anexada 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 mais adiante neste artigo.
- Os NSGs (Grupos de Segurança de Rede) devem ser associados à NIC de tráfego SD-WAN, diretamente ou no nível da sub-rede. Essa associação permite conexões de sites locais remotos através das portas TCP/UDP usadas pela solução SD-WAN.
- O encaminhamento de IP deve ser habilitado na NIC usada para o tráfego SD-WAN.
Azure Route Server na rede virtual do hub
O Azure Route Server automatiza a troca de rotas entre NVAs SD-WAN e a pilha de Rede Definida por Software (SDN) do Azure. O Route Server suporta BGP como um protocolo de roteamento dinâmico. Ao estabelecer adjacências BGP entre o Route Server e o SD-WAN NVA(s):
- 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 das redes virtuais são propagadas para todos os sites conectados à SD-WAN.
O Route Server deve ser configurado da seguinte forma.
- Ele deve ser implantado em uma sub-rede dedicada na rede virtual do hub de acordo com Criar e configurar o Servidor de Rotas usando o portal do Azure.
- Para habilitar a troca automatizada de rotas para todas as redes virtuais faladas, o emparelhamento de rede virtual deve ser configurado para permitir que as redes virtuais spoke usem o gateway da rede virtual do hub e o Route Server. Detalhes disponíveis nas Perguntas frequentes do Azure Route Server.
- Como o Route Server e os NVAs SD-WAN estão conectados a sub-redes diferentes, as sessões BGP entre o Route Server e os NVAs SD-WAN devem ser configuradas com suporte a multihop eBGP. Qualquer número de saltos entre 2 e o máximo suportado pelo SD-WAN NVA pode ser definido. Detalhes sobre como configurar adjacências BGP para o Servidor de Rotas estão disponíveis em Criar e configurar o Servidor de Rotas usando o portal do Azure.
- Duas
/32rotas estáticas devem ser configuradas no NVA SD-WAN para os pontos de extremidade BGP expostos pelo Route Server. Essa configuração garante que a tabela de rotas do NVA sempre contenha rotas para seus pares BGP multihop (não conectados diretamente).
O Route Server não está no caminho de dados. É uma entidade de plano de controle. Ele propaga rotas entre o SD-WAN NVA e a pilha SDN da rede virtual, mas o encaminhamento de tráfego real entre o SD-WAN NVA 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 Route Server injeta todas as rotas aprendidas com os NVAs SD-WAN com o próximo salto definido para o próprio endereço do NVA.
O Route Server não suporta IPv6 a partir de agora. Esta arquitetura é apenas para IPv4.
Figura 2. O Route Server suporta a propagação de rota 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 Route Server
O Route Server tem HA integrada. Dois nós de computação revertem uma única instância do Route Server. 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 Route Server.
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 SD-WAN NVA expõe seu próprio ponto de extremidade de túnel. Os pares remotos estabelecem vários túneis, um para cada SD-WAN NVA no Azure.
Nenhum balanceador de carga interno distribui o tráfego originado pelas VMs do Azure para os NVAs SD-WAN. O Route Server e a pilha SDN do Azure suportam o roteamento ECMP (Equal-Cost Multipath). Se vários NVAs configurarem adjacências BGP com o Route Server e anunciarem rotas para os mesmos destinos (como em, redes remotas e sites conectados ao SD-WAN) usando o mesmo grau de preferência, o Route Server:
- 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.
Em seguida, a pilha SDN distribui o tráfego para esses destinos em todos os próximos saltos disponíveis.
A arquitetura HA resultante é mostrada na figura a seguir:
Figura 3. O Route Server suporta 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.
Alta disponibilidade N-active versus ative stand-by
Quando você usa vários NVAs SD-WAN e os emparelha com o Route Server, o BGP direciona o failover. Se um NVA SD-WAN ficar offline, ele interromperá as rotas de publicidade para o Route Server. As rotas aprendidas com o dispositivo com falha são então retiradas da tabela de rotas da rede virtual. Assim, se um SD-WAN NVA não fornecer mais conectividade a sites remotos SD-WAN devido a uma falha, no próprio dispositivo ou na camada inferior, 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 restantes dispositivos saudáveis. Para obter mais informações sobre a propagação de rota entre NVAs SD-WAN e o Route Server, consulte Rotas anunciadas por um par BGP para o Route Server.
Figura 4. Failover orientado por BGP. Se o SD-WAN NVA #0 ficar offline, suas sessões BGP com o Route Server serão fechadas. O SD-WAN NVA #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 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 Route Server as rotas com um grau de preferência menor do que seu par ativo. O Route Server descarta as rotas recebidas do dispositivo passivo se 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 Rotas:
- 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 para as rotas que anunciam ao Route Server é AS Path.
Recomendamos arquiteturas de HA N-ativas porque 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 suportados pelo Route Server. Para obter mais informações, consulte Pares BGP. Mas o modelo de HA N-active requer que os NVAs SD-WAN atuem como roteadores de camada 3 sem monitoração de 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 HA ativas/ativas. SD-WAN NVA #0 e SD-WAN NVA #1 anunciam a mesma rota para o destino 192.168.1.0/24 (site remoto SD-WAN) com o mesmo comprimento de caminho AS para o servidor de rota. O fluxo ORIGINAL (do site remoto SD-WAN para o Azure, caminho vermelho) é roteado através do túnel terminado, no lado do Azure, pelo SD-WAN NVA #1. O CPE SD-WAN local seleciona esse túnel. A pilha SDN do Azure roteia o fluxo REPLY (do Azure para o site remoto SD-WAN, caminho verde) para SD-WAN NVA #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 monitoração 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 em qualquer momento. Ou seja, toda a camada SD-WAN só pode ser dimensionada até o tamanho máximo da VM do Azure suportada, não dimensionada. Execute funções de rede com estado que exigem simetria de roteamento em clusters NVA separados que dependem do Standard Load Balancer para HA n-active.
Considerações sobre conectividade da Rota Expressa
A arquitetura descrita neste artigo permite que os clientes adotem totalmente o paradigma SD-WAN e construam sua rede corporativa como uma sobreposição lógica sobre a Internet pública e o backbone da Microsoft. Ele também suporta o uso de circuitos de rota expressa dedicados para abordar cenários específicos, descritos mais tarde.
Cenário #1: Coexistência entre ExpressRoute e SD-WAN
As soluções SD-WAN podem coexistir com a conectividade 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 à Internet apenas. Em seguida, eles usam serviços MPLS e circuitos de Rota Expressa para grandes sites e datacenters, conforme mostrado na figura a seguir.
Figura 6. As soluções SD-WAN podem coexistir com a conectividade ExpressRoute quando dispositivos CPE SD-WAN são implantados apenas em um subconjunto de sites.
Esse cenário de coexistência requer NVAs SD-WAN implantados no Azure para serem capazes de rotear o tráfego entre sites conectados à SD-WAN e sites conectados a circuitos de Rota Expressa. O Servidor de Rotas pode ser configurado para propagar rotas entre gateways de rede virtual ExpressRoute e NVAs SD-WAN no Azure habilitando o recurso, conforme documentado AllowBranchToBranch aqui. A propagação da rota entre o gateway de rede virtual ExpressRoute e o SD-WAN NVA(s) acontece através do BGP. O Route Server estabelece sessões BGP com ambos e propaga para cada par as rotas aprendidas com o outro. A plataforma gerencia as sessões BGP entre o Route Server e o gateway de rede virtual ExpressRoute. Os usuários não precisam configurá-los explicitamente, mas apenas habilitar o sinalizador ao implantar o AllowBranchToBranch Route Server.
Figura 7. A propagação da rota entre o gateway de rede virtual ExpressRoute e o SD-WAN NVA(s) acontece através do BGP. O Route Server estabelece sessões BGP com ambos e propaga rotas em ambas as direções quando configurado com "AllowBranchToBranch=TRUE". O Route Server atua como um refletor de rota, ou seja, não faz parte do caminho de dados.
Este cenário de coexistência 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 através de datacenters locais. Este 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 base SD-WAN
Se seus sites locais tiverem conectividade de Rota Expressa, você poderá configurar dispositivos SD-WAN para configurar túneis para os NVAs do hub SD-WAN em execução no Azure sobre o circuito ou circuitos da Rota Expressa. A conectividade do ExpressRoute pode ser feita através de circuitos ponto-a-ponto ou de uma rede MPLS. Você pode usar o emparelhamento privado da Rota Expressa e o emparelhamento da Microsoft.
Peering privado
Quando você usa o emparelhamento privado da Rota Expressa como underlay, todos os sites SD-WAN locais estabelecem túneis para os NVAs do hub SD-WAN no Azure. Nenhuma propagação de rota entre os NVAs SD-WAN e o gateway de rede virtual ExpressRoute é necessária neste cenário (ou seja, o Route Server deve ser configurado com o sinalizador "AllowBranchToBranch" definido como false).
Essa abordagem requer uma configuração BGP adequada nos roteadores do lado do cliente ou do provedor que encerram a conexão da Rota Expressa. Na verdade, os Microsoft Enterprise Edge Routers (MSEEs) anunciam todas as rotas para as redes virtuais conectadas ao circuito (diretamente ou via emparelhamento de rede virtual). Mas, a fim de encaminhar o tráfego destinado a redes virtuais através de um túnel SD-WAN, o site local deve aprender essas rotas a partir do dispositivo SD-WAN - não o circuito ER.
Portanto, os roteadores do lado do cliente ou do lado do provedor que encerram a conexão da Rota Expressa devem filtrar as rotas recebidas do Azure. As únicas rotas configuradas na camada inferior 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 da Rota Expressa como uma base SD-WAN devem verificar se podem configurar seus dispositivos de roteamento de acordo. Fazer isso é especialmente relevante para clientes que não têm controle direto sobre seus dispositivos de borda para a Rota Expressa. Um exemplo é quando o circuito ExpressRoute é fornecido por uma operadora MPLS em cima de um serviço IPVPN.
Figura 8. Emparelhamento privado da Rota Expressa como uma camada de suporte 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 ExpressRoute, nas sessões BGP de emparelhamento privado do ER e no CPE SD-WAN. Somente o CPE SD-WAN deve propagar as rotas do Azure para a LAN do site.
Peering da Microsoft
Você também pode usar o emparelhamento Microsoft ExpressRoute como uma base para túneis SD-WAN. Nesse cenário, os NVAs do 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 à Rota Expressa. Embora o emparelhamento Microsoft ExpressRoute tenha pré-requisitos mais complexos do que o emparelhamento privado, recomendamos usar essa opção como uma base devido a estas duas vantagens:
Ele não requer gateways de rede virtual Expressroute na rede virtual do hub. Ele remove a complexidade, reduz os custos 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 ExpressRoute FastPath.
Proporciona uma separação clara entre as rotas de sobreposição e de subposição. Os MSEEs anunciam apenas 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 consideram essa abordagem devem verificar se podem configurar seus dispositivos de roteamento de acordo ou solicitar o serviço adequado para sua operadora MPLS.
Considerações 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 serão discutidos mais adiante.
Desmantelamento faseado da MPLS
Os clientes que desejam criar uma SD-WAN sobre a Internet pública e o backbone da Microsoft, e desativar completamente IPVPNs MPLS ou outros serviços de conectividade dedicados, podem usar o cenário de coexistência ExpressRoute e SD-WAN descrito na seção anterior durante a migração. Ele permite que sites conectados por 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 do Azure mais próximas.
Figura 9. O cenário de "coexistência de Rota Expressa e SD-WAN" permite o descomissionamento faseado do MPLS.
Quando todos os sites são migrados, o IPVPN MPLS pode ser desativado, juntamente com os circuitos ExpressRoute que o conectam ao backbone da Microsoft. Os gateways de rede virtual ExpressRoute não são mais necessários e podem ser desprovisionados. 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 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 base de classe empresarial. 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 base SD-WAN descrito anteriormente permite a integração SD-WAN e MPLS. O emparelhamento Microsoft ExpressRoute deve ser preferido sobre o 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 bases 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 de Internet e MPLS pode estabelecer vários túneis para os hubs SD-WAN no Azure em ambas as bases. Eles podem então rotear diferentes conexões através de túneis diferentes, com base em políticas de nível de aplicativo gerenciadas pelo plano de controle SD-WAN.
Figura 10. O cenário "ExpressRoute as an SD-WAN underlay" permite a integração SD-WAN e MPLS.
Preferência de roteamento do Servidor de Rotas
Em ambos os cenários MPLS abordados nas duas seções anteriores, alguns sites de filial podem ser conectados ao IPVPN MPLS e ao SD-WAN. Como resultado, as instâncias do Route Server implantadas nas redes virtuais do hub podem aprender as mesmas rotas com os Gateways de Rota Expressa e NVAs SD-WAN. A preferência de roteamento do Route Server permite controlar qual caminho deve ser preferido e inserido nas tabelas de rotas das redes virtuais. A preferência de roteamento é útil quando o caminho AS pendente não pode ser usado. Um exemplo são os serviços IPVPN MPLS que não suportam configurações BGP personalizadas nos PEs que encerram conexões ExpressRoute.
Limites do servidor de rotas e considerações de design
O Route Server é 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 grandes SD-WANs com base nessa arquitetura, os limites de escalabilidade do Route Server devem ser considerados.
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 Route Server
O Servidor de Rotas não define um limite explícito para o número de rotas que podem ser anunciadas para os Gateways de Rede Virtual de Rota Expressa quando o AllowBranchToBranch sinalizador é definido. No entanto, os Gateways de Rota Expressa propagam ainda mais as rotas que aprendem do Servidor de Rotas para os circuitos de Rota Expressa aos quais estão conectados.
Há um limite para o número de rotas que os Gateways de Rota Expressa podem anunciar para circuitos de Rota Expressa no emparelhamento privado, documentado em Limites de assinatura, cotas e restrições de serviço e assinatura 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 ExpressRoute Gateways e ExpressRoute são descartadas e a conectividade entre redes virtuais e redes remotas conectadas via ExpressRoute é perdida.
O número total de rotas anunciadas para circuitos pelos Gateways de Rota Expressa é a soma do número de rotas aprendidas com o Servidor de Rotas e o número de prefixos que compõem o espaço de endereçamento do hub do Azure e da rede spoke. Para evitar interrupções devido à queda de sessões de BGP, 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 Route Server, se o recurso estiver disponível.
- Use os Alertas do Azure Monitor para detetar proativamente picos no número de rotas anunciadas pelos Gateways de Rota Expressa. A métrica a ser monitorada é chamada de Contagem de Rotas Anunciadas para Par, conforme documentado no monitoramento de Rota Expressa.
Pares BGP
O Route Server 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 Route Server e, portanto, 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 existem soluções alternativas para superá-lo, além de criar várias redes hub e spoke, cada uma com seus próprios gateways e servidores de rota.
VMs participantes
Os Gateways de Rede Virtual e o Servidor de Rotas configuram as rotas que aprendem com seus pares remotos para todas as VMs em sua própria rede virtual e em redes virtuais diretamente emparelhadas. Para proteger o Route Server do consumo excessivo de recursos devido a atualizações de roteamento para VMs, o Azure define um limite para o número de VMs que podem existir em um único hub e rede spoke. Não existem soluções alternativas para superar esse limite, além de criar várias redes hub e spoke, cada uma com seus próprios gateways e servidores de rota, na mesma região.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Principais autores:
- Federico Guerrini - Brasil | Arquiteto de Soluções Cloud Sênior
- Khush Kaviraj - Brasil | Arquiteto de Soluções Cloud
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.