Compartir a través de


Solución de problemas de Azure Route Server

Este artículo le ayuda a diagnosticar y resolver problemas comunes al trabajar con Azure Route Server. Use las instrucciones de este artículo para solucionar problemas de conectividad, problemas del plano de control y problemas operativos.

Problemas de conectividad

¿Por qué mi aplicación virtual de red (NVA) pierde conectividad a Internet después de anunciar la ruta predeterminada (0.0.0.0/0) al servidor de rutas?

Cuando la NVA anuncia la ruta predeterminada, Azure Route Server la programa para todas las máquinas virtuales (VM) de la red virtual, incluida la propia NVA. Esta ruta predeterminada establece la aplicación virtual de red como próximo salto para todo el tráfico enlazado a Internet. Si su NVA necesita conectividad a Internet, debe configurar una ruta definida por el usuario para invalidar la ruta predeterminada en la NVA y adjuntar la ruta definida por el usuario a la subred donde se hospeda la NVA. De lo contrario, la máquina host de NVA sigue enviando el tráfico dirigido a Internet, incluido el tráfico enviado por la NVA, de vuelta a la propia NVA.

Para obtener más información, consulte Rutas definidas por el usuario.

Configuración de UDR necesaria:

Ruta Próximo salto
0.0.0.0/0 Internet

¿Por qué la NVA pierde su conectividad con Route Server después de forzar todo el tráfico a un firewall mediante una ruta definida por el usuario (UDR) en GatewaySubnet?

Si desea inspeccionar el tráfico local mediante un firewall, puede forzar todo el tráfico local al firewall mediante una ruta definida por el usuario (UDR) en GatewaySubnet. Sin embargo, esta UDR podría interrumpir la comunicación entre el servidor de rutas y la puerta de enlace al dirigir el tráfico del plano de control (BGP) hacia el firewall. Este problema se produce si está inspeccionando el tráfico destinado a la red virtual que tiene el Servidor de Rutas.

Para evitar este problema, agregue otra UDR a la tabla de rutas GatewaySubnet para excluir que el tráfico del plano de control se vea forzado al firewall (en caso de que no se desee o sea posible agregar una regla BGP al firewall):

Configuración de UDR de ejemplo:

Ruta Próximo salto
10.0.0.0/16 10.0.2.1
10.0.1.0/27 VirtualNetwork

En este ejemplo:

  • 10.0.0.0/16 es el espacio de direcciones de la red virtual.
  • 10.0.1.0/27 es el espacio de direcciones de RouteServerSubnet
  • 10.0.2.1 es la dirección IP del firewall.

He agregado una ruta definida por el usuario (UDR) con el tipo de próximo salto como Puerta de enlace de red virtual, pero esta UDR no surte efecto. ¿Es normal?

Sí, este es el comportamiento esperado. Las rutas definidas por el usuario con el tipo de próximo salto Puerta de enlace de red virtual no se admiten para subredes dentro de la red virtual de Route Server y las redes virtuales emparejadas. Sin embargo, si desea configurar el próximo salto para que sea una aplicación virtual de red (NVA) o Internet, puede agregar una ruta definida por el usuario con el tipo de próximo salto VirtualAppliance o Internet.

En las rutas efectivas de la interfaz de red de mi máquina virtual, ¿por qué tengo una ruta definida por el usuario (UDR) con el tipo del próximo salto establecido en Ninguno?

Si anuncia una ruta desde su NVA al Servidor de Rutas que coincide exactamente con el prefijo de otra ruta definida por el usuario, entonces el próximo salto de la ruta anunciada debe ser válido. Si el próximo salto anunciado es un equilibrador de carga sin un grupo de back-end configurado, esta ruta no válida tiene prioridad sobre la ruta definida por el usuario. En las rutas efectivas de la interfaz de red, la ruta anunciada no válida se muestra como una ruta definida por el usuario con el tipo de próximo salto establecido en Ninguno.

¿Por qué tengo problemas de conectividad después de volver a anunciar las rutas de Azure en Azure?

Si tiene previsto quitar las comunidades de Azure BGP de las rutas de red virtual y UDR, no anuncie estas rutas de nuevo en Azure, ya que esto provoca problemas de enrutamiento. No se recomienda volver a anunciar rutas de Azure en el entorno de Azure.

¿Por qué pierdo la conectividad después de asociar una directiva de punto de conexión de servicio a RouteServerSubnet o GatewaySubnet?

Si asocia una directiva de punto de conexión de servicio con RouteServerSubnet o GatewaySubnet, la comunicación podría interrumpirse entre la plataforma de administración subyacente de Azure y estos servicios respectivos de Azure (Route Server y la puerta de enlace VPN/ExpressRoute). Esto puede hacer que estos recursos de Azure entren en un estado incorrecto, lo que da lugar a una pérdida de conectividad entre las cargas de trabajo locales y de Azure.

¿Por qué pierdo la conectividad después de usar DNS personalizado en lugar del DNS predeterminado (DNS proporcionado por Azure) para la red virtual de Route Server?

Para la red virtual en la que se implementa Route Server, si no usa DNS predeterminado (proporcionado por Azure), asegúrese de que la configuración de DNS personalizada puede resolver nombres de dominio públicos. Esto garantiza que los servicios de Azure (servidor de rutas y puerta de enlace de VPN/ExpressRoute) puedan comunicarse con el plano de administración subyacente de Azure.

Para más información, consulte la nota sobre las reglas de caracteres comodín en la documentación de Azure DNS Private Resolver.

¿Por qué no puedo hacer ping TCP desde mi aplicación virtual de red a la IP del par BGP de Azure Route Server después de configurar el emparejamiento BGP entre ellos?

En algunas aplicaciones virtuales de red, debe agregar una ruta estática a la subred de Route Server para poder hacer ping TCP al servidor de rutas desde la aplicación virtual de red y evitar la marca de emparejamiento BGP. Por ejemplo, si Route Server se encuentra en 10.0.255.0/27 y la NVA se encuentra en 10.0.1.0/24, debe agregar la siguiente ruta a la tabla de enrutamiento en la NVA:

Ruta estática necesaria:

Ruta Próximo salto
10.0.255.0/27 10.0.1.1

En este ejemplo, 10.0.1.1 es la dirección IP de puerta de enlace predeterminada en la subred donde se hospeda la NVA (o más precisamente, una de las NIC).

¿Por qué se pierde la conectividad a la red local con ExpressRoute o con una VPN de Azure cuando se implementa Route Server en una red virtual que ya tiene una puerta de enlace de ExpressRoute o una puerta de enlace de VPN de Azure?

Al implementar Route Server en una red virtual, es necesario actualizar el plano de control entre las puertas de enlace y la red virtual. Durante esta actualización, hay un período de tiempo en el que las máquinas virtuales de la red virtual pierden la conectividad a la red local. Le recomendamos encarecidamente que programe un mantenimiento para implementar Route Server en el entorno de producción.

Problemas del plano de control

¿Por qué mi red local conectada a Azure VPN Gateway no recibe la ruta predeterminada anunciada por Route Server?

Aunque Azure VPN Gateway puede recibir la ruta predeterminada de sus pares BGP, incluido Route Server, no anuncia la ruta predeterminada a otros pares.

¿Por qué la aplicación virtual de red no recibe rutas de Route Server aunque el emparejamiento de BGP esté activo?

Azure Route Server utiliza el ASN 65515. Asegúrese de configurar un ASN diferente para la aplicación virtual de red para que se pueda establecer una sesión eBGP entre la aplicación virtual de red y route Server para que la propagación de rutas se pueda producir automáticamente. Asegúrese de habilitar saltos múltiples en la configuración de BGP, ya que la NVA y Route Server se encuentran en distintas subredes de la red virtual.

¿Por qué la conectividad no funciona cuando anuncio rutas con un ASN de 0 en la ruta de acceso del sistema autónomo (AS)?

Azure Route Server quita las rutas con un ASN de 0 en la ruta de acceso del sistema autónomo (AS). Para asegurarse de que estas rutas se anuncian correctamente en Azure, la ruta AS no debe incluir 0.

El emparejamiento BGP entre la aplicación virtual de red y Route Server está activo. Puedo ver que las rutas se intercambian correctamente entre ambos. ¿Por qué no están las rutas de la NVA en la tabla de enrutamiento efectiva de mi máquina virtual?

Si la máquina virtual está en la misma red virtual que la NVA y Route Server:

Route Server expone dos direcciones IP del par BGP que comparten la responsabilidad de enviar las rutas a todas las demás máquinas virtuales que se ejecutan en la red virtual. Cada NVA debe configurar dos sesiones de BGP idénticas (por ejemplo, usar el mismo número de AS, la misma ruta AS y anunciar el mismo conjunto de rutas) en las dos IP de par BGP para que las máquinas virtuales de la red virtual puedan obtener información de enrutamiento coherente desde Azure Route Server.

Diagrama que muestra una aplicación virtual de red (NVA) con Azure Route Server.

Si tiene dos o más instancias de la NVA, puede anunciar diferentes rutas AS para la misma ruta desde diferentes instancias de la NVA si quiere designar una instancia de NVA como activa y la otra como pasiva.

Si su máquina virtual está una red virtual distinta de la que hospeda la NVA y Route Server:

Compruebe si el emparejamiento de red virtual está habilitado entre las dos redes virtuales y si el uso de Remote Route Server está habilitado en la red virtual de la máquina virtual.

¿Por qué la función de múltiples rutas de acceso de igual coste (ECMP) de mi conexión de ExpressRoute está desactivada después de implementar Route Server en la red virtual?

Cuando anuncia las mismas rutas desde su red local a Azure a través de varias conexiones de ExpressRoute, normalmente ECMP está habilitado de manera predeterminada para el tráfico destinado a dichas rutas desde Azure de vuelta a su red local. Actualmente, al implementar route Server, se pierde información de varias rutas de acceso en el intercambio BGP entre ExpressRoute y Route Server y, por lo tanto, el tráfico de Azure atraviesa solo en una de las conexiones de ExpressRoute.

Problemas operativos

¿Por qué veo un error sobre alcance y autorización inválidos para realizar operaciones en el servidor de rutas?

Si ve un error en el formato siguiente, asegúrese de que tiene los permisos siguientes configurados: Roles y permisos de Route Server.

Formato del mensaje de error: "El cliente con el identificador {} de objeto no tiene autorización para realizar acciones {} a través del ámbito {} o el ámbito no es válido. Si el acceso se ha concedido recientemente, actualice las credenciales."

Paso siguiente

Obtenga información sobre cómo crear y configurar Azure Route Server. Vea: