Partilhar via

Considerações sobre o design de rede da Solução VMware do Azure

A Solução VMware do Azure oferece um ambiente de nuvem privada VMware que os usuários e aplicativos podem acessar a partir de ambientes ou recursos locais e baseados no Azure. Serviços de rede, como o Azure ExpressRoute e conexões de rede virtual privada (VPN), fornecem a conectividade.

Há várias considerações de rede a serem analisadas antes de configurar seu ambiente de solução VMware do Azure. Este artigo fornece soluções para casos de uso que você pode encontrar ao usar a Solução VMware do Azure para configurar suas redes.

Compatibilidade da solução VMware do Azure com o AS-Path Prepend

A Solução VMware do Azure tem considerações relacionadas ao uso de AS-Path Prepend para configurações redundantes de Rota Expressa. Se você estiver executando dois ou mais caminhos de Rota Expressa entre o local e o Azure, considere as seguintes orientações para influenciar o tráfego da Solução VMware do Azure para seu local local por meio do ExpressRoute GlobalReach.

Devido ao roteamento assimétrico, problemas de conectividade podem ocorrer quando o Azure VMware Solution não observa AS-Path Prepend e, portanto, usa o roteamento ECMP (equal-cost multipath) para enviar tráfego para seu ambiente em ambos os circuitos da Rota Expressa. Esse comportamento pode causar problemas com dispositivos de inspeção de firewall com monitoração de estado colocados atrás de circuitos de Rota Expressa existentes.

Pré-requisitos

Para AS-Path Prepend, considere os seguintes pré-requisitos:

  • O ponto-chave é que você deve preceder ASNs (Números de Sistema Autônomo Público ) para influenciar como a Solução VMware do Azure roteia o tráfego de volta para o local. Se utilizar o Private ASN para realizar o precedente, a Solução Azure VMware irá ignorar o precedente, e ocorrerá o comportamento ECMP mencionado anteriormente. Mesmo que opere um ASN BGP Privado no local, ainda é possível configurar seus dispositivos locais para utilizar um ASN Público ao acrescentar rotas de saída, para garantir compatibilidade com a Solução Azure VMware.
  • Projete o seu caminho de tráfego para ASNs privadas após o ASN público ser reconhecido pela Solução VMware da Azure. O circuito VMware Solution ExpressRoute do Azure não remove nenhum ASN privado que exista no caminho depois de o ASN público ser processado.
  • Ambos ou todos os circuitos estão conectados à Solução VMware do Azure por meio do Azure ExpressRoute Global Reach.
  • Os mesmos netblocks estão a ser anunciados a partir de dois ou mais circuitos.
  • Você deseja usar AS-Path Prepend para forçar a solução VMware do Azure a preferir um circuito em detrimento de outro.
  • Use números ASN públicos de 2 ou 4 bytes.

ASNs privados reservados na solução VMware do Azure

A Solução VMware do Azure utiliza ASNs (Autonomous System Numbers) privados específicos para sua infraestrutura de rede subjacente. Para evitar conflitos e garantir uma integração de rede perfeita, os clientes não devem usar os seguintes ASNs em suas configurações de rede.

ASNs reservados para redes subjacentes

Os ASNs a seguir são reservados para a infraestrutura interna da Solução VMware do Azure e devem ser evitados pelos clientes:

  • ASNs de nível 2: 65300 – 65340

  • ASNs de nível 1: 65200 – 65240

  • ASNs de transporte (gateways T0): 64513 (NSX Edges), 64600 – 64940

  • ASNs de gerenciamento: 65000 – 65412, 398656-398670, 400572-400581

Impacto do Uso de ASNs Reservados

O uso de qualquer um dos ASNs listados acima em seu ambiente pode levar a falhas de sessão BGP, conflitos de roteamento de rede ou interrupções de serviço. Certifique-se de que suas atribuições ASN não se sobreponham a esses valores reservados.

VMs de administração e rotas padrão no local

Importante

As máquinas virtuais (VMs) de gestão da Azure VMware Solution não respeitarão uma rota padrão definida no local para destinos RFC1918.

Se você estiver roteando de volta para suas redes locais usando apenas uma rota padrão anunciada para o Azure, o tráfego de VMs do vCenter Server e do NSX Manager que estão sendo usadas para destinos locais com endereços IP privados não seguirá essa rota.

Para acessar o vCenter Server e o NSX Manager localmente, forneça rotas específicas para permitir que o tráfego tenha um caminho de retorno para essas redes. Por exemplo, anuncie os resumos RFC1918 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16).

Rota padrão para a solução VMware do Azure para inspeção de tráfego na Internet

Determinadas implantações exigem a inspeção de todo o tráfego de saída da Solução VMware do Azure para a Internet. Embora seja possível criar dispositivos virtuais de rede (NVAs) na Solução VMware do Azure, há casos de uso em que esses dispositivos já existem no Azure e podem ser aplicados para inspecionar o tráfego da Internet da Solução VMware do Azure. Nesse caso, uma rota padrão pode ser injetada a partir do NVA no Azure para atrair tráfego da Solução VMware do Azure e inspecionar o tráfego antes que ele saia para a Internet pública.

O diagrama a seguir descreve uma topologia básica de hub-and-spoke conectada a uma nuvem da Solução VMware do Azure e a uma rede local por meio da Rota Expressa. O diagrama mostra como o NVA no Azure origina a rota padrão (0.0.0.0/0). O Azure Route Server propaga a rota para a Solução VMware do Azure por meio da Rota Expressa.

Diagrama da solução VMware do Azure com o Route Server e uma rota padrão.

Importante

A rota padrão que o NVA anuncia será propagada para a rede local. Você precisa adicionar rotas definidas pelo usuário (UDRs) para garantir que o tráfego da Solução VMware do Azure esteja transitando pelo NVA.

A comunicação entre a Azure VMware Solution e a rede local geralmente ocorre por meio do ExpressRoute Global Reach, conforme descrito em Ligar ambientes locais à Azure VMware Solution.

Conectividade entre a solução VMware do Azure e uma rede local

Há dois cenários principais para a conectividade entre a Solução VMware do Azure e uma rede local por meio de um NVA de terceiros:

  • As organizações têm um requisito para enviar tráfego entre a Solução VMware do Azure e a rede local por meio de um NVA (normalmente um firewall).
  • O ExpressRoute Global Reach não está disponível em uma região específica para interconectar os circuitos ExpressRoute da Solução VMware do Azure e a rede local.

Existem duas topologias que pode aplicar para satisfazer todos os requisitos desses cenários: supernet e rede virtual de spoke de trânsito.

Importante

A opção preferida para conectar a Solução VMware do Azure e ambientes locais é uma conexão direta do ExpressRoute Global Reach. Os padrões descritos neste artigo adicionam complexidade ao ambiente.

Topologia de design de super-rede

Se ambos os circuitos de Rota Expressa (para a Solução VMware do Azure e para o local) forem encerrados no mesmo gateway de Rota Expressa, você poderá presumir que o gateway encaminhará pacotes entre eles. No entanto, um gateway de ExpressRoute não está concebido para isso. É necessário redirecionar o tráfego de forma a alcançar uma NVA (Appliance Virtual de Rede) que possa encaminhá-lo.

Há dois requisitos para fixar o tráfego de rede em um NVA:

  • A NVA deve anunciar um supernet para a Solução Azure VMware e os prefixos locais.

    Você pode usar uma super-rede que inclua a Solução VMware do Azure e prefixos locais. Ou poderá usar prefixos individuais para Azure VMware Solution e no local físico (sempre menos específicos do que os prefixos reais anunciados pelo ExpressRoute). Tenha em mente que todos os prefixos de super-rede anunciados ao Route Server são propagados tanto para a Solução VMware Azure como para as instalações locais.

  • UDRs na sub-rede do gateway, que correspondem exatamente aos prefixos anunciados pela Solução VMware do Azure e no local, causam tráfego em modo hairpin da sub-rede do gateway para o NVA.

Essa topologia resulta em alta sobrecarga de gerenciamento para grandes redes que mudam ao longo do tempo. Considere estas limitações:

  • Sempre que um segmento de carga de trabalho é criado na Solução VMware do Azure, talvez seja necessário adicionar UDRs para garantir que o tráfego da Solução VMware do Azure esteja transitando pelo NVA.
  • Se o seu ambiente local tiver um grande número de rotas que mudam, o protocolo BGP (Border Gateway Protocol) e a configuração UDR na super-rede talvez precisem ser atualizados.
  • Como um único gateway ExpressRoute processa o tráfego de rede em ambas as direções, o desempenho pode ser limitado.
  • Há um limite de Rede Virtual do Azure de 400 UDRs.

O diagrama a seguir demonstra como o NVA precisa anunciar prefixos que são mais genéricos (menos específicos) e que incluem as redes locais e a Solução VMware do Azure. Tenha cuidado com esta abordagem. A NVA poderia potencialmente atrair tráfego que não deveria, porque está a divulgar intervalos mais amplos (por exemplo, toda a rede 10.0.0.0/8).

Diagrama da Solução VMware do Azure para comunicação local com o Route Server em uma única região.

Topologia de rede virtual de spoke Transit

Observação

Se prefixos de publicidade menos específicos não forem possíveis devido aos limites descritos anteriormente, você poderá implementar um design alternativo que use duas redes virtuais separadas.

Nessa topologia, em vez de propagar rotas menos específicas para atrair tráfego para o gateway da Rota Expressa, dois NVAs diferentes em redes virtuais separadas podem trocar rotas entre si. As redes virtuais podem propagar essas rotas para seus respetivos circuitos de Rota Expressa via BGP e Azure Route Server. Cada NVA tem controle total sobre quais prefixos são propagados para cada circuito de ExpressRoute.

O diagrama a seguir demonstra como uma única 0.0.0.0/0 rota é anunciada para a Azure VMware Solution. Ele também mostra como os prefixos individuais da Solução VMware do Azure são propagados para a rede local.

Diagrama da Solução VMware do Azure para comunicação local com o Route Server em duas regiões.

Importante

Um protocolo de encapsulamento como VXLAN ou IPsec é necessário entre os NVAs. É necessário encapsulamento porque o adaptador de rede NVA (NIC) aprenderia as rotas do Azure Route Server com o NVA como o próximo salto, criando um loop de encaminhamento.

Há uma alternativa ao uso de uma sobreposição. Aplique placas de rede secundárias no NVA que não aprendem as rotas do Azure Route Server. Em seguida, configure UDRs para que o Azure possa rotear o tráfego para o ambiente remoto nessas NICs. Você pode encontrar mais detalhes em Topologia de rede de escala empresarial e conectividade para a Solução VMware do Azure.

Essa topologia requer uma configuração inicial complexa. Em seguida, a topologia funciona conforme o esperado com uma sobrecarga de gerenciamento mínima. As complexidades de configuração incluem:

  • Há um custo extra para adicionar outra rede virtual de trânsito que inclui o Azure Route Server, um gateway ExpressRoute e outro NVA. Os NVAs também podem precisar usar tamanhos grandes de VM para atender aos requisitos de largura de banda.
  • O tunnelamento IPsec ou VXLAN é necessário entre os dois NVAs, o que significa que os NVAs também estão integrados na trajetória dos dados. Dependendo do tipo de NVA que você está usando, isso pode resultar em configurações personalizadas e complexas nesses NVAs.

Próximos passos

Depois de aprender sobre as considerações de design de rede para a Solução VMware do Azure, considere explorar os seguintes artigos:

  • Last updated on