Compartir a través de

Consideraciones de diseño de red de Azure VMware Solution

Azure VMware Solution ofrece un entorno de nube privada de VMware al que los usuarios y las aplicaciones pueden acceder desde entornos o recursos locales y basados en Azure. Los servicios de red, como Azure ExpressRoute y las conexiones de red privada virtual (VPN) proporcionan la conectividad.

Hay varias consideraciones de red que se deben revisar antes de configurar el entorno de Azure VMware Solution. En este artículo se proporcionan soluciones para casos de uso que pueden surgir al usar Azure VMware Solution para configurar las redes.

Compatibilidad de Azure VMware Solution con AS-Path Prepend

Azure VMware Solution tiene consideraciones relacionadas con el uso de AS-Path prepend para configuraciones redundantes de ExpressRoute. Si ejecuta dos o más rutas de acceso de ExpressRoute entre el entorno local y Azure, tenga en cuenta las instrucciones siguientes para controlar el tráfico de salida de la solución Azure VMware hacia su ubicación local a través de ExpressRoute GlobalReach.

Debido al enrutamiento asimétrico, se pueden producir problemas de conectividad cuando Azure VMware Solution no observa el anteponer AS-Path y, por tanto, usa el enrutamiento de múltiples rutas de igual costo (ECMP) para enviar tráfico hacia el entorno a través de ambos circuitos ExpressRoute. Este comportamiento puede causar problemas con dispositivos de inspección de firewall con estado colocados detrás de los circuitos ExpressRoute existentes.

Prerrequisitos

Para el anteponer AS-Path, tenga en cuenta los siguientes requisitos previos:

  • El punto clave es que debe anteponer números de sistema autónomo Público (ASN) para influir en cómo Azure VMware Solution enruta el tráfico de vuelta al entorno local. Si utiliza un ASN privado como prefijo, Azure VMware Solution lo ignorará y se producirá el comportamiento de ECMP mencionado anteriormente. Incluso si opera un ASN de BGP privado en sus instalaciones, es posible configurar sus dispositivos locales para que utilicen un ASN público al agregar rutas salientes, con el fin de garantizar la compatibilidad con Azure VMware Solution.
  • Diseñe la ruta de tráfico para los ASN privados después de que Azure VMware Solution honre el ASN público. El circuito ExpressRoute de Azure VMware Solution no quita ningún ASN privado que exista en la ruta de acceso después de procesar el ASN público.
  • Ambos o todos los circuitos están conectados a Azure VMware Solution a través de Global Reach de Azure ExpressRoute.
  • Los mismos netblocks se anuncian desde dos o más circuitos.
  • Desea utilizar AS-Path Prepend para forzar a la solución Azure VMware a preferir un circuito sobre otro.
  • Use números de ASN públicos de 2 bytes o de 4 bytes.

ASN privados reservados en Azure VMware Solution

Azure VMware Solution utiliza números de sistema autónomo (ASN) privados específicos para su infraestructura de red subyacente. Para evitar conflictos y garantizar la integración de red sin problemas, los clientes no deben usar los siguientes ASN dentro de sus configuraciones de red.

ASN reservados para redes subyacentes

Los siguientes ASN están reservados para la infraestructura interna de Azure VMware Solution y deben evitarse por los clientes:

  • ASN de nivel 2: 65300 – 65340

  • ASN de nivel- 1: 65200 – 65240

  • ASN de transporte (puertas de enlace de T0): 64513 (bordes NSX), 64600 – 64940

  • ASN de administración: 65000 – 65412, 398656-398670, 400572-400581

Impacto del uso de ASN reservados

El uso de cualquiera de los ASN enumerados anteriormente en su entorno puede provocar errores de sesión BGP, conflictos de enrutamiento de red o interrupciones del servicio. Asegúrese de que las asignaciones de ASN no se superpongan con estos valores reservados.

Máquinas virtuales de administración y rutas predeterminadas desde el entorno local

Importante

Las máquinas virtuales (VM) de administración de Azure VMware Solution no respetarán una ruta predeterminada desde el entorno local para los destinos de RFC1918.

Si está redireccionando de nuevo a sus redes locales utilizando únicamente una ruta predeterminada anunciada hacia Azure, el tráfico procedente de las máquinas virtuales de vCenter Server y NSX Manager orientado hacia destinos locales con direcciones IP privadas no transitará por esa ruta.

Para acceder a vCenter Server y NSX Manager desde el entorno local, proporcione rutas específicas para permitir que el tráfico tenga una ruta de acceso de retorno a esas redes. Por ejemplo, anuncie los resúmenes de RFC1918 (10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16).

Ruta predeterminada a Azure VMware Solution para la inspección del tráfico de Internet

Algunas implementaciones requieren inspeccionar todo el tráfico de salida de Azure VMware Solution hacia Internet. Aunque es posible crear aplicaciones virtuales de red (NVA) en Azure VMware Solution, hay casos de uso en los que estos dispositivos ya existen en Azure y se pueden aplicar para inspeccionar el tráfico de Internet desde Azure VMware Solution. En este caso, se puede insertar una ruta predeterminada desde la aplicación virtual de red de Azure para atraer el tráfico de Azure VMware Solution e inspeccionar el tráfico antes de salir a la red pública de Internet.

En el diagrama siguiente se describe una topología básica en estrella tipo hub-and-spoke conectada a una nube de Azure VMware Solution y a una red local a través de ExpressRoute. El diagrama muestra cómo el NVA en Azure origina la ruta predeterminada (0.0.0.0/0). Azure Route Server propaga la ruta a Azure VMware Solution a través de ExpressRoute.

Diagrama de Azure VMware Solution con Route Server y una ruta predeterminada.

Importante

La ruta predeterminada que anuncia la aplicación virtual de red se propagará a la red local. Debe agregar rutas definidas por el usuario (UDR) para asegurarse de que el tráfico de Azure VMware Solution transita a través de la aplicación virtual de red.

La comunicación entre Azure VMware Solution y la red local suele producirse a través de ExpressRoute Global Reach, como se describe en Conectar entornos locales con Azure VMware Solution.

Conectividad entre Azure VMware Solution y una red local

Hay dos escenarios principales para la conectividad entre Azure VMware Solution y una red local a través de una NVA de terceros:

  • Las organizaciones tienen un requisito para enviar tráfico entre Azure VMware Solution y la red local a través de una aplicación virtual de red (normalmente un firewall).
  • Global Reach de ExpressRoute no está disponible en una región determinada para interconectar los circuitos ExpressRoute de Azure VMware Solution y la red local.

Hay dos topologías que puede aplicar para cumplir todos los requisitos de esos escenarios: supernet y red virtual radial de tránsito.

Importante

La opción preferida para conectar Azure VMware Solution y entornos locales es una conexión directa de Global Reach de ExpressRoute. Los patrones descritos en este artículo agregan complejidad al entorno.

Topología de diseño de supernet

Si ambos circuitos ExpressRoute (hacia Azure VMware Solution y hacia local) finalizan en la misma puerta de enlace de ExpressRoute, puede suponer que la puerta de enlace va a enrutar los paquetes entre ellos. Sin embargo, una puerta de enlace de ExpressRoute no está diseñada para hacerlo. Debe redisclar el tráfico a una aplicación virtual de red que pueda enrutar el tráfico.

Hay dos requisitos para redirigir el tráfico de red a una NVA:

  • La aplicación virtual de red debe anunciar una supernet para los prefijos locales y Azure VMware Solution.

    Puede usar una supernet que incluya tanto Azure VMware Solution como prefijos locales. O bien, puede usar prefijos individuales para Azure VMware Solution y local (siempre menos específico que los prefijos reales anunciados a través de ExpressRoute). Tenga en cuenta que todos los prefijos de supernet anunciados en Route Server se propagan tanto a Azure VMware Solution como a un entorno local.

  • Las UDR de la subred de puerta de enlace, que coinciden exactamente con los prefijos anunciados desde Azure VMware Solution y el entorno local, provocan el tráfico de la puerta de enlace desde la subred de puerta de enlace a la aplicación virtual de red.

Esta topología da como resultado una sobrecarga de administración alta para redes grandes que cambian con el tiempo. Tenga en cuenta estas limitaciones:

  • Cada vez que se crea un segmento de carga de trabajo en Azure VMware Solution, puede ser necesario agregar UDRs para asegurarse de que el tráfico de Azure VMware Solution transita a través de la NVA.
  • Si el entorno local tiene un gran número de rutas que cambian, es posible que sea necesario actualizar la configuración del Protocolo de puerta de enlace de borde (BGP) y udR en la supernet.
  • Dado que una única puerta de enlace de ExpressRoute procesa el tráfico de red en ambas direcciones, el rendimiento puede estar limitado.
  • Hay un límite de 400 UDR de Azure Virtual Network.

En el diagrama siguiente se muestra cómo la aplicación virtual de red necesita anunciar prefijos que son más genéricos (menos específicos) y que incluyen las redes locales y Azure VMware Solution. Tenga cuidado con este enfoque. El NVA podría atraer tráfico que no debería, porque está anunciando rangos más amplios (por ejemplo, toda la red 10.0.0.0/8).

Diagrama de Azure VMware Solution para la comunicación local con Route Server en una sola región.

Topología de red virtual de radio de tránsito

Nota:

Si los prefijos publicitarios que son menos específicos no son posibles debido a los límites descritos anteriormente, puede implementar un diseño alternativo que use dos redes virtuales independientes.

En esta topología, en lugar de propagar rutas menos específicas para atraer el tráfico a la puerta de enlace de ExpressRoute, dos NVA diferentes en redes virtuales independientes pueden intercambiar rutas entre sí. Las redes virtuales pueden propagar estas rutas a sus respectivos circuitos ExpressRoute a través de BGP y Azure Route Server. Cada aplicación virtual de red tiene control total sobre qué prefijos se propagan a cada circuito ExpressRoute.

En el diagrama siguiente se muestra cómo se anuncia una sola 0.0.0.0/0 ruta en Azure VMware Solution. También muestra cómo se propagan los prefijos individuales de Azure VMware Solution a la red local.

Diagrama de Azure VMware Solution para la comunicación local con Route Server en dos regiones.

Importante

Se requiere un protocolo de encapsulación como VXLAN o IPsec entre las NVA. La encapsulación es necesaria porque el adaptador de red (NIC) de NVA aprendería las rutas de Azure Route Server con la NVA como próximo salto y crearía un bucle de enrutamiento.

Una alternativa al uso de una superposición Aplique NIC secundarias en la NVA que no aprendan las rutas de Azure Route Server. A continuación, configure las UDR para que Azure pueda enrutar el tráfico al entorno remoto a través de esas NIC. Puede encontrar más detalles en Topología de red y conectividad a escala empresarial para Azure VMware Solution.

Esta topología requiere una configuración inicial compleja. A continuación, la topología funciona según lo previsto con una sobrecarga de administración mínima. Las complejidades de configuración incluyen:

  • Hay un costo adicional para agregar otra red virtual de tránsito que incluye Azure Route Server, una puerta de enlace de ExpressRoute y otra aplicación virtual de red. Es posible que las NVA también necesiten usar tamaños de máquina virtual de gran tamaño para cumplir los requisitos de rendimiento.
  • La tunelización de IPsec o VXLAN es necesaria entre las dos NVA, lo que significa que las NVA también están en la ruta de acceso de datos. Según el tipo de NVA que esté utilizando, puede dar lugar a una configuración personalizada y compleja en esos NVAs.

Pasos siguientes

Después de obtener información sobre las consideraciones de diseño de red para Azure VMware Solution, considere la posibilidad de explorar los siguientes artículos:

  • Last updated on