Solución de problemas de Azure Route Server
Aprenda a solucionar algunos de los problemas comunes de Azure Route Server.
Problemas de conectividad
¿Por qué la aplicación virtual de red (NVA) pierde la conectividad a Internet después de anunciar la ruta predeterminada (0.0.0.0/0) a Azure Route Server?
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 NVA como el próximo salto para todo el tráfico de 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 la NVA seguirá enviando el tráfico de Internet, incluido el que envía la NVA, a la misma NVA. Para más información, consulte Rutas definidas por el usuario.
| 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 (una tabla de rutas asociada a GatewaySubnet que tenga la UDR). Sin embargo, esta UDR puede interrumpir la comunicación entre el servidor de rutas y la puerta de enlace forzando el tráfico del plano de control (BGP) al 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, debe agregar otra UDR a la tabla de rutas GatewaySubnet para excluir el tráfico del plano de control de ser forzado al firewall (en caso de que no se desee o sea posible agregar una regla BGP al firewall):
| Ruta | Próximo salto |
|---|---|
| 10.0.0.0/16 | 10.0.2.1 |
| 10.0.1.0/27 | VirtualNetwork |
10.0.0.0/16 es el espacio de direcciones de la red virtual y 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 Virtual Network Gateway no se admiten para subredes dentro de la red virtual de Route Server y las redes virtuales emparejadas. Sin embargo, si quiere configurar el próximo salto para que sea una aplicación virtual de red (NVA) o Internet, se permite 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 de la NVA a Route Server que coincide exactamente con el prefijo de otra ruta definida por el usuario, 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 tendrá prioridad sobre la ruta definida por el usuario. En las rutas efectivas de la interfaz de red, la ruta anunciada no válida se mostrará como una ruta definida por el usuario con el tipo del próximo salto establecido en Ninguno.
¿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 a RouteServerSubnet o GatewaySubnet, la comunicación puede interrumpirse entre la plataforma de administración subyacente de Azure y estos servicios de Azure respectivos (Route Server y puerta de enlace de 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 pueda resolver nombres de dominio públicos. Esto garantiza que los servicios de Azure (servidor de rutas y VPN/puerta de enlace de ExpressRoute) puedan comunicarse con el plano de administración subyacente de Azure. Consulte la nota sobre las reglas de caracteres comodín en la documentación de la resolución privada de Azure DNS.
¿Por qué no puedo hacer ping TCP desde mi NVA 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 NVA 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 | Próximo salto |
|---|---|
| 10.0.255.0/27 | 10.0.1.1 |
10.0.1.1 es la dirección IP de la puerta de enlace predeterminada de la subred donde se hospeda la NVA (o de forma más precisa, 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 elementos del mismo nivel.
¿Por qué la NVA 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 NVA, de modo que se pueda establecer una sesión de eBGP entre la NVA y Route Server para que la propagación de rutas se realice 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.
El emparejamiento BGP entre la NVA 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 su máquina virtual está en la misma red virtual que su NVA y Route Server:
Route Server expone dos direcciones IP del par BGP que se hospedan en dos máquinas virtuales que comparten la responsabilidad de enviar las rutas a todas las demás máquinas virtuales que se ejecutan en la red virtual. Cada una de las NVA debe configurar dos sesiones de BGP idénticas (por ejemplo, usar el mismo número AS, la misma ruta AS y anunciar el mismo conjunto de rutas) en las dos máquinas virtuales para que las máquinas virtuales de la red virtual puedan obtener información de enrutamiento coherente desde 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 está habilitado el uso del servidor de rutas remoto 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. Sin embargo, una vez que implementa Route Server, la información de múltiples rutas se pierde en el intercambio BGP entre ExpressRoute y Route Server, por lo que el tráfico de Azure atraviesa solo una de las conexiones de ExpressRoute.
Paso siguiente
Obtenga información sobre cómo crear y configurar Azure Route Server. Vea: