Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Aprenda a solucionar algunos de los problemas comunes de Azure Route Server.
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 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 al forzar que el tráfico del plano de control (BGP) pase a través del firewall (este problema se produce cuando está inspeccionando el tráfico dirigido a la red virtual que contiene 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 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 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 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 siguiente salto anunciado es un balanceador de carga sin un grupo de servidores de respaldo configurado, entonces esta ruta no válida tendrá preferencia 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é 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 provocará problemas de enrutamiento. Como resultado, no se recomienda volver a anunciar las rutas de Azure hacia 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 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 el 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. 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 | 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 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 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.
¿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 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 comparten la responsabilidad de enviar las rutas a todas las demás máquinas virtuales que se ejecutan en la red virtual. Cada aplicación virtual de red debe configurar dos sesiones de BGP idénticas (por ejemplo, usar el mismo número de sistema autónomo [AS], la misma ruta AS y anunciar el mismo conjunto de rutas) en las dos IP de protocolo de puerta de enlace de borde (BGP) 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á en una red virtual distinta de la que hospeda el NVA y el Servidor de Rutas. Compruebe si VNet Peering está habilitado entre las dos redes virtuales y si está habilitado el uso de servidor de rutas remoto en la red virtual de su 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.
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 configurados los permisos siguientes: Roles y permisos de Route Server.
Formato del mensaje de error: "El cliente con el identificador de objeto {} no tiene autorización para realizar la acción {} en el á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: