Compartilhar via

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

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

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

Compatibilidade da Solução VMware no Azure com AS-Path Prepend

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

Devido ao roteamento assimétrico, podem ocorrer problemas de conectividade quando a Solução VMware no Azure não observa AS-Path Prepend e, assim, utiliza o roteamento ECMP (multipercurso de custo igual) para enviar tráfego para seu ambiente através de ambos os circuitos do ExpressRoute. Esse comportamento pode causar problemas com dispositivos de inspeção de firewall com estado colocados atrás de circuitos ExpressRoute existentes.

Pré-requisitos

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

  • O ponto principal é que você deve acrescentar Números Públicos de Sistema Autônomo (ASNs) para influenciar como o Solução VMware no Azure roteia o tráfego de volta para o local. Se você prefixar usando ASN privado, a Solução VMware no Azure ignorará o prefixo, e ocorrerá o comportamento de ECMP mencionado anteriormente. Mesmo que você opere um ASN BGP privado localmente, ainda é possível configurar seus dispositivos locais para utilizar um ASN público ao preparar rotas de saída, para garantir a compatibilidade com a Solução VMware no Azure.
  • Projete seu caminho de tráfego para ASNs privados após o ASN público a ser honrado pelo Solução VMware no Azure. O circuito do ExpressRoute da Solução VMware no Azure não remove as ASNs privadas que existem no caminho depois que o ASN público é processado.
  • Ambos ou todos os circuitos estão conectados à Solução VMware no Azure por meio do Alcance Global do Azure ExpressRoute.
  • Os mesmos netblocks estão sendo anunciados 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 vez de outro.
  • Use números ASN públicos de 2 bytes ou 4 bytes.

ASNs privados reservados na Solução VMware no Azure

O Solução VMware no Azure utiliza Números de Sistema Autônomo (ASNs) privados específicos para sua infraestrutura de rede subjacente. Para evitar conflitos e garantir a integração de rede perfeita, os clientes não devem usar as seguintes ASNs em suas configurações de rede.

ASNs reservados para redes subjacentes

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

  • ASNs de Camada 2: 65.300 – 65.340

  • ASNs de Camada 1: 65.200 – 65.240

  • 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. Verifique se suas atribuições ASN não se sobrepõem a esses valores reservados.

Gerenciamento de VMs e rotas padrão do local

Importante

As máquinas virtuais (VMs) de gerenciamento do Solução VMware no Azure não respeitarão uma rota padrão do 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 das 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 no Azure para inspeção de tráfego na Internet

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

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

Diagrama da Solução VMware no Azure com o Servidor de Rota e uma rota padrão.

Importante

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

A comunicação entre a Solução VMware no Azure e a rede local geralmente ocorre por meio do ExpressRoute Global Reach, conforme descrito em Conectar ambientes locais com a Solução VMware no Azure.

Conectividade entre a Solução VMware no Azure e uma rede local

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

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

Existem duas topologias que você pode aplicar para atender a todos os requisitos desses cenários: super-rede e rede virtual de trânsito spoke.

Importante

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

Topologia de projeto de super-rede

Se ambos os circuitos do ExpressRoute (para a Solução VMware no Azure e para o local) forem encerrados no mesmo gateway do ExpressRoute, você poderá assumir que o gateway vai rotear pacotes entre eles. No entanto, um gateway do ExpressRoute não foi projetado para fazer isso. Você precisa direcionar o tráfego para uma NVA que possa direcioná-lo.

Há dois requisitos para direcionar o tráfego de rede para uma NVA:

  • O NVA deve anunciar uma super-rede para a Solução VMware no Azure e prefixos locais.

    Você pode usar uma super-rede que inclua prefixos locais e da Solução VMware no Azure. Ou você pode usar prefixos individuais para a Solução VMware no Azure e no local (sempre menos específicos do que os prefixos reais anunciados no ExpressRoute). Tenha em mente que todos os prefixos de super-rede anunciados para o Route Server são propagados para o Solução VMware no Azure e no local.

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

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

  • Sempre que um segmento de carga de trabalho é criado na Solução VMware no Azure, as UDRs podem precisar ser adicionadas para garantir que o tráfego da Solução VMware no Azure esteja transitando pela NVA.
  • Se o ambiente local tiver um grande número de rotas que mudam, a configuração do Border Gateway Protocol (BGP) e das rotas definidas pelo usuário (UDR) na super-rede talvez precise ser atualizada.
  • Como um único gateway do 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 a NVA precisa anunciar prefixos mais genéricos (menos específicos) e que incluem as redes do local e da Solução VMware no Azure. Tenha cuidado com essa abordagem. O NVA poderia potencialmente atrair tráfego que não deveria, porque está anunciando alcances mais amplos (por exemplo, toda a 10.0.0.0/8 rede).

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

Topologia de rede virtual de raios de trânsito

Observação

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

Nessa topologia, em vez de propagar rotas menos específicas para atrair tráfego para o gateway do ExpressRoute, duas NVAs diferentes em redes virtuais separadas podem trocar rotas entre si. As redes virtuais podem propagar essas rotas para seus respectivos circuitos do ExpressRoute por meio do BGP e do Servidor de Rota do Azure. Cada NVA tem controle total sobre quais prefixos são propagados para cada circuito do ExpressRoute.

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

Diagrama da Solução VMware no Azure para comunicação local com o Servidor de Rota em duas regiões.

Importante

Um protocolo de encapsulamento, como VXLAN ou IPsec, é necessário entre os NVAs. O encapsulamento é necessário porque o adaptador de rede da NVA (NIC) aprenderia as rotas do Azure Route Server, considerando a NVA como o próximo salto, e criaria um loop de roteamento.

Existe uma alternativa ao uso de uma sobreposição. Aplique NICs secundárias na NVA que não aprendem as rotas do Servidor de Rota do Azure. Em seguida, configure UDRs para que o Azure possa rotear o tráfego para o ambiente remoto por essas NICs. Você pode encontrar mais detalhes sobre a topologia e conectividade de rede em escala empresarial para a Solução VMware no Azure.

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

  • Há um custo extra para adicionar outra rede virtual de trânsito que inclui o Servidor de Rota do Azure, um gateway ExpressRoute e outro NVA. As NVAs também podem precisar usar tamanhos de VM grandes para atender aos requisitos de desempenho.
  • O tunelamento IPsec ou VXLAN é necessário entre os dois NVAs, o que significa que os NVAs também estão no caminho de dados. Dependendo do tipo de NVA que você está usando, isso pode resultar em configuração personalizada e complexa nesses NVAs.

Próximas etapas

Depois de saber mais sobre considerações de design de rede para a Solução VMware no Azure, considere explorar os seguintes artigos:

  • Last updated on