Comprobación de la conectividad de ExpressRoute
En este artículo encontrará información útil para comprobar y solucionar problemas de conectividad de Azure ExpressRoute. ExpressRoute amplía las redes locales en Microsoft Cloud a través de una conexión privada que suele facilitar un proveedor de conectividad. La conectividad de ExpressRoute implica tradicionalmente tres zonas de red distintas, como se indica a continuación:
- Red de cliente
- Red del proveedor
- Centro de datos de Microsoft
Nota
En el modelo de conectividad de ExpressRoute Direct, puede conectarse directamente al puerto de los enrutadores de Microsoft Enterprise Edge (MSEE). El modelo de conectividad directa incluye solo las zonas de red de Microsoft y sus propias zonas.
Este artículo le ayuda a identificar si existe un problema de conectividad y dónde. Además de ayudarle a solicitar soporte técnico al equipo adecuado para resolver un problema.
Importante
Este documento está pensado para ayudarle a diagnosticar y corregir problemas sencillos. No pretende sustituir al soporte técnico de Microsoft. Si no puede resolver un problema mediante las instrucciones de este artículo, abra un ticket de asistencia técnica con el Soporte técnico de Microsoft.
Información general
El siguiente diagrama muestra la conectividad lógica de una red de cliente a la red de Microsoft mediante ExpressRoute.
En el diagrama anterior, los números indican los puntos de red clave:
- Dispositivo de proceso del cliente (por ejemplo, un servidor o PC).
- Enrutadores en el lado del cliente (CE).
- Enrutadores o conmutadores del lado del proveedor (PE) orientados hacia los enrutadores del lado del cliente.
- PEs que orientados a enrutadores Enterprise Edge ExpressRoute (MSEE) de Microsoft. En este artículo se les llama PE-MSEE.
- MSEE.
- Puerta de enlace de red virtual.
- Proceso del dispositivo en la red virtual de Azure.
En este artículo a veces se hace referencia a los puntos de red por su número asociado.
Dependiendo del modelo de conectividad ExpressRoute, los puntos de red 3 y 4 podrían ser switches (dispositivos de capa 2) o routers (dispositivos de capa 3). Los modelos de conectividad de ExpressRoute son la ubicación de intercambio en la nube, la conexión Ethernet de punto a punto o cualquier tipo de conexión (IPVPN).
En el modelo de conectividad directa, no existen los puntos de red 3 y 4. En su lugar, los CE (2) se conectan directamente a los MSE A través de fibra oscura.
Si se usa el modelo de colocación de intercambio en la nube, Ethernet de punto a punto o de conectividad directa, los enrutadores en el lado del cliente (2) establecen el emparejamiento de protocolo de puerta de enlace de borde (BGP) con MSEE (5).
Si se usa el modelo de conectividad universal (IPVPN), los PE-MSEE (4) podrían establecer un emparejamiento BGP con los MSEE (5). Los PE-MSEE propagan las rutas recibidas de Microsoft de nuevo a la red del cliente a través de la red del proveedor de servicios IPVPN.
Nota:
Para lograr una alta disponibilidad, Microsoft establece una conectividad paralela totalmente redundante entre pares de MSEE (5) y PE-MSEE (4). También se recomienda establecer una ruta de acceso a la red paralela y totalmente redundante entre la red del cliente y los pares PE-CE. Para obtener más información sobre la alta disponibilidad, consulte el artículo Diseño de alta disponibilidad con ExpressRoute.
A continuación se indican los pasos lógicos para solucionar problemas del circuito ExpressRoute.
Comprobación del aprovisionamiento y del estado del circuito
El aprovisionamiento de un circuito ExpressRoute establece conexiones redundantes de nivel 2 entre los CE o PE-MSEE (2/4 o 5) y los MSEE (5). Para más información acerca de cómo crear, modificar, aprovisionar y comprobar un circuito ExpressRoute, consulte el artículo Creación y modificación de un circuito ExpressRoute.
Sugerencia
Una clave de servicio identifica de forma única un circuito ExpressRoute. Si necesita asistencia de Microsoft o de un asociado de ExpressRoute para solucionar un problema de ExpressRoute, especifique la clave de servicio para identificar inmediatamente el circuito.
Comprobación a través de Azure Portal
En Azure Portal, abra la página del circuito ExpressRoute. En la sección 
de la página, se enumera la información esencial de ExpressRoute, tal como se muestra en la captura de pantalla siguiente:
En Fundamentos de ExpressRoute, Estado del circuito indica el estado del circuito en el lado de Microsoft. Estado del proveedor indica si el circuito ha sido aprovisionado o no en el lado del proveedor de servicios.
Para que un circuito ExpressRoute sea operativo, el valor de Estado del circuito debe ser Habilitado y el Estado del Proveedor debe ser aprovisionado.
Nota
Después de configurar un circuito ExpressRoute, si Estado del circuito se encuentra no habilitado, póngase en contacto con el Soporte técnico de Microsoft. Por otro lado, si Estado del proveedor se muestra como no aprovisionado, póngase en contacto con su proveedor de servicios.
Comprobación a través de PowerShell
Para obtener una lista de todos los circuitos ExpressRoute en un grupo de recursos, utilice el siguiente comando:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"
Sugerencia
Si busca el nombre de un grupo de recursos, para encontrarlo, puede enumerar todos los grupos de recursos de la suscripción con el comando Get-AzResourceGroup.
Para seleccionar un circuito ExpressRoute concreto en un grupo de recursos, utilice el siguiente comando:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Este es un ejemplo de respuesta:
Name : Test-ER-Ckt
ResourceGroupName : Test-ER-RG
Location : westus2
Id : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt
Etag : W/"################################"
ProvisioningState : Succeeded
Sku : {
"Name": "Standard_UnlimitedData",
"Tier": "Standard",
"Family": "UnlimitedData"
}
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
ServiceProviderNotes :
ServiceProviderProperties : {
"ServiceProviderName": "****",
"PeeringLocation": "******",
"BandwidthInMbps": 100
}
ServiceKey : **************************************
Peerings : []
Authorizations : []
Para confirmar si un circuito ExpressRoute está operativo, preste especial atención a los campos siguientes:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Nota
Después de configurar un circuito ExpressRoute, si Estado del circuito se encuentra en estado No habilitado, comuníquese con el Soporte técnico de Microsoft. Por otro lado, si Estado del proveedor se muestra como No aprovisionado, comuníquese con su proveedor de servicios.
Validación de la configuración de emparejamiento
Cuando el proveedor de servicios haya completado el aprovisionamiento del circuito ExpressRoute, pueden crearse varias configuraciones de enrutamiento basadas en BGP externo a través del circuito ExpressRoute entre los CE o MSEE-PE (2/4 o 5) y los MSEE (5). Cada circuito ExpressRoute puede tener una o ambas de las opciones de configuración de emparejamiento:
- Emparejamiento privado de Azure: tráfico a redes virtuales privadas en Azure
- Emparejamiento de Microsoft: tráfico a puntos de conexión públicos de plataforma como servicio (PaaS) y software como servicio (SaaS)
Para más información sobre cómo crear y modificar la configuración de enrutamiento, consulte el artículo Creación y modificación del enrutamiento de un circuito ExpressRoute.
Comprobación a través de Azure Portal
Nota:
En un modelo de conectividad de IPVPN, los proveedores de servicios se encargan de configurar los emparejamientos (servicios de nivel 3). En este modelo, una vez que el proveedor de servicios ha configurado un emparejamiento, si este se muestra en blanco en el portal, pruebe a actualizar la configuración del circuito con el botón de actualización del portal. Esta operación extraerá la configuración de enrutamiento actual del circuito.
En Azure Portal, puede comprobar el estado de un circuito ExpressRoute en la página de ese circuito. En la sección de la página, se enumeran los emparejamientos de ExpressRoute, tal como se muestra en la captura de pantalla siguiente:
Como se indicó en el ejemplo anterior, el emparejamiento privado de Azure está aprovisionado, mientras que los emparejamientos públicos de Azure y el emparejamiento de Microsoft no lo están. Un contexto de emparejamiento aprovisionado correctamente también mostrará las subredes de punto a punto principales y secundarias. Las subredes /30 se usan para la dirección IP de interfaz de los MSEE y los CE o los PE-MSEE. En el caso de los emparejamientos que se aprovisionan, también se indica quién modificó la configuración por última vez.
Nota:
Si se produce un error al habilitar un emparejamiento, compruebe si las subredes principales y secundarias asignadas coinciden con la configuración del CE o el PE-MSEE vinculado. Compruebe también si los valores correctos VlanId, AzureASN y PeerASN se utilizan en los MSEE, y si estos valores se asignan a los utilizados en el CE/PE-MSEE vinculado.
Si se elige el hash MD5, la clave compartida debe coincidir en el par MSEE y CE o PE-MSEE. La clave compartida que se ha configurado previamente no se mostraría por motivos de seguridad.
Si necesita cambiar la configuración en un enrutador MSEE, consulte Creación y modificación del enrutamiento de un circuito ExpressRoute.
Nota
En una subred /30 asignada para la interfaz, Microsoft elegirá la segunda dirección IP utilizable de la subred para la interfaz MSEE. Por lo tanto, asegúrese de que se ha asignado la primera dirección IP utilizable de la subred en el CE o el PE-MSEE emparejado.
Comprobación a través de PowerShell
Para obtener los detalles de configuración del emparejamiento privado de Azure, use los siguientes comandos:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt
Aquí tiene una respuesta de ejemplo para un emparejamiento privado configurado correctamente:
Name : AzurePrivatePeering
Id : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt/peerings/AzurePrivatePeering
Etag : W/"################################"
PeeringType : AzurePrivatePeering
AzureASN : 12076
PeerASN : 123##
PrimaryPeerAddressPrefix : 172.16.0.0/30
SecondaryPeerAddressPrefix : 172.16.0.4/30
PrimaryAzurePort :
SecondaryAzurePort :
SharedKey :
VlanId : 200
MicrosoftPeeringConfig : null
ProvisioningState : Succeeded
Un contexto de emparejamiento habilitado correctamente mostrará los prefijos de dirección principal y secundaria en la lista. Las subredes /30 se usan para la dirección IP de interfaz de los MSEE y los CE o los PE-MSEE.
Para obtener los detalles de configuración del emparejamiento público de Azure, use los siguientes comandos:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePublicPeering" -ExpressRouteCircuit $ckt
Para obtener los detalles de configuración del emparejamiento de Microsoft, use los siguientes comandos:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt
Si no se configura un emparejamiento, aparecerá un mensaje de error. Esta es una respuesta de ejemplo de cuando el emparejamiento indicado (emparejamiento público de Azure en este ejemplo) no está configurado en el circuito:
Get-AzExpressRouteCircuitPeeringConfig : Sequence contains no matching element
At line:1 char:1
+ Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePublicPeering ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Get-AzExpr...itPeeringConfig], InvalidOperationException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.Network.GetAzureExpressRouteCircuitPeeringConfigCommand
Nota
Si se produce un error al habilitar un emparejamiento, compruebe si las subredes principales y secundarias asignadas coinciden con la configuración del CE o el PE-MSEE vinculado. Compruebe también si los valores correctos VlanId, AzureASN y PeerASN se utilizan en los MSEE, y si estos valores se asignan a los utilizados en el CE/PE-MSEE vinculado.
Si se elige el hash MD5, la clave compartida debe coincidir en el par MSEE y CE o PE-MSEE. La clave compartida que se ha configurado previamente no se mostraría por motivos de seguridad.
Si necesita cambiar la configuración en un enrutador MSEE, consulte Creación y modificación del enrutamiento de un circuito ExpressRoute.
Nota:
En una subred /30 asignada para la interfaz, Microsoft elegirá la segunda dirección IP utilizable de la subred para la interfaz MSEE. Por lo tanto, asegúrese de que se ha asignado la primera dirección IP utilizable de la subred en el CE o el PE-MSEE emparejado.
Validación de ARP
La tabla ARP proporciona una asignación de la dirección IP y la dirección MAC para un emparejamiento determinado. La tabla ARP de un emparejamiento de circuito ExpressRoute proporciona la siguiente información para cada interfaz (principal y secundaria):
- Asignación de la dirección IP de la interfaz del enrutador local a la dirección MAC
- Asignación de la dirección IP de la interfaz del enrutador de ExpressRoute a la dirección MAC (opcional)
- Antigüedad de la asignación
Las tablas ARP pueden ayudar a validar la configuración de nivel 2 y a solucionar los problemas básicos de conectividad de nivel 2.
Nota:
En función de la plataforma de hardware, los resultados de ARP pueden variar y mostrar solo la interfaz local.
Consulte el documento Obtención de tablas ARP en el modelo de implementación de Resource Manager para ver la tabla ARP de un emparejamiento de ExpressRoute y descubrir cómo usar la información para solucionar problemas de conectividad de nivel 2.
Validación de BGP y las rutas en el MSEE
Para obtener la tabla de enrutamiento de MSEE en la ruta de acceso principal del contexto de enrutamiento privado, use el siguiente comando:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName ******* -PeeringType AzurePrivatePeering -ResourceGroupName ****
Este es un ejemplo de respuesta:
Network : 10.1.0.0/16
NextHop : 10.17.17.141
LocPrf :
Weight : 0
Path : 65515
Network : 10.1.0.0/16
NextHop : 10.17.17.140*
LocPrf :
Weight : 0
Path : 65515
Network : 10.2.20.0/25
NextHop : 172.16.0.1
LocPrf :
Weight : 0
Path : 123##
Nota
Si el estado de un emparejamiento EBGP entre un MSEE y un CE o un PE-MSEE es activo o está en espera, compruebe si las subredes principales y secundarias asignadas del mismo nivel coinciden con la configuración de los CE o de los PE-MSEE vinculados. Compruebe también si los valores correctos VlanId, AzureASN y PeerASN se utilizan en los MSEE, y si estos valores se asignan a los utilizados en el CE/PE-MSEE vinculado. Si se elige el hash MD5, la clave compartida debe coincidir en el par MSEE y CE o PE-MSEE. Si necesita cambiar la configuración en un enrutador MSEE, consulte Creación y modificación del enrutamiento de un circuito ExpressRoute.
Nota:
Si determinados destinos no son accesibles a través de un emparejamiento, compruebe la tabla de rutas de los MSEE para el contexto de emparejamiento correspondiente. Si en la tabla de enrutamiento hay un prefijo que coincida (podría ser IP NATed), compruebe si los firewalls, los grupos de seguridad de red o las listas de control de acceso (ACL) de la ruta de acceso bloquean el tráfico.
En el ejemplo siguiente se muestra la respuesta del comando para un emparejamiento que no existe:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
Confirmación del flujo de tráfico
Para obtener las estadísticas del tráfico de la ruta de acceso principal y secundaria combinados (bytes de entrada y salida) de un contexto de emparejamiento, use el siguiente comando:
Get-AzExpressRouteCircuitStats -ResourceGroupName $RG -ExpressRouteCircuitName $CircuitName -PeeringType 'AzurePrivatePeering'
Este es un ejemplo del resultado del comando:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Esta es una salida de ejemplo del comando para un emparejamiento inexistente:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
Prueba de la conectividad de emparejamiento privado
Pruebe su conectividad de emparejamiento privado contando los paquetes que llegan y salen del borde de Microsoft del circuito ExpressRoute, en los dispositivos Microsoft Enterprise Edge (MSEE). Esta herramienta de diagnóstico funciona aplicando una lista de control de acceso (ACL) al MSEE para contar el número de paquetes que se aplican a reglas ACL específicas. El uso de esta herramienta le permite confirmar la conectividad respondiendo a preguntas como:
- ¿Mis paquetes llegan a Azure?
- ¿Volverán a estar disponibles en local?
Ejecución de una prueba
Para obtener acceso a esta herramienta de diagnóstico, seleccione Diagnosticar y resolver problemas desde el circuito de ExpressRoute en Azure Portal.
Seleccione Conectividad e Incidencias de rendimiento.
En la lista desplegable Cuéntenos más sobre el problema que está experimentando, seleccione Problemas con el emparejamiento privado.
Desplácese hacia abajo hasta la sección Probar la conectividad de emparejamiento privado y expándala.
Ejecute la prueba de PsPing desde la dirección IP local a la dirección IP de Azure y manténgala en ejecución mientras dure la prueba de conectividad.
Rellene los campos del formulario. Asegúrese de escribir las mismas direcciones IP locales y de Azure que usó en el paso 5. A continuación, seleccione Enviar y, después, espere a que se carguen los resultados.
Interpretación de los resultados
Cuando los resultados estén listos, tendrá dos conjuntos de estos para los dispositivos MSEE principal y secundario. Revise el número de coincidencias de entrada y salida y use los siguientes escenarios para interpretar los resultados:
Verá las coincidencias de paquetes enviadas y recibidas en ambos MSEEs: esto indica un tráfico correcto entrante y saliente desde el MSEE en el circuito. Si la pérdida se produce en el entorno local o en Azure, se produce de forma descendente desde el MSEE.
Si está probando PsPing desde el entorno local a Azure, ha recibido coincidencias de resultados, pero los resultados enviados no muestran coincidencias: esto indica que el tráfico está llegando a Azure, pero no está volviendo al entorno local. Compruebe si hay problemas de enrutamiento de ruta de retorno. Por ejemplo, ¿está anunciando los prefijos adecuados a Azure? ¿Una ruta definida por el usuario (UDR) reemplaza los prefijos?
Si está probando PsPing desde el entorno local a Azure, ha recibido coincidencias de resultados, pero los resultados enviados no muestran coincidencias: esto indica que el tráfico está llegando a local, pero no está volviendo a Azure. Debe trabajar con su proveedor para averiguar por qué el tráfico no se enruta a Azure a través de su circuito ExpressRoute.
Un MSEE NO muestra coincidencias, mientras que otro muestra coincidencias buenas: esto indica que un MSEE no recibe ni pasa ningún tráfico. Podría estar sin conexión (por ejemplo, BGP/ARP fuera de servicio).
- Puede ejecutar pruebas adicionales para confirmar la ruta de acceso incorrecta anunciando una ruta /32 local única a través de la sesión de BGP en esta ruta de acceso.
- Ejecute "Probar la conectividad de emparejamiento privado" con la única /32 anunciado como la dirección de destino local y revise los resultados para confirmar el estado de la ruta de acceso.
Los resultados de la prueba para cada dispositivo MSEE serán similares al ejemplo siguiente:
src 10.0.0.0 dst 20.0.0.0 dstport 3389 (received): 120 matches
src 20.0.0.0 srcport 3389 dst 10.0.0.0 (sent): 120 matches
Este resultado de la prueba tiene las siguientes propiedades:
- Puerto IP: 3389
- CIDR de dirección IP local: 10.0.0.0
- CIDR de dirección IP de Azure: 20.0.0.0
Comprobación de la disponibilidad de la puerta de enlace de red virtual
La puerta de enlace de red virtual de ExpressRoute facilita la administración y la conectividad del plano de control a los servicios de vínculos privados e IP privadas implementados en una red virtual de Azure. Microsoft administra la infraestructura de puerta de enlace de red virtual y, a veces, pasa por un proceso de mantenimiento.
Durante un período de mantenimiento, el rendimiento de la puerta de enlace de red virtual puede reducirse. Para solucionar problemas de conectividad con la red virtual y ver si un evento de mantenimiento reciente ha provocado una reducción de la capacidad, siga estos pasos:
Seleccione Diagnosticar y resolver problemas desde el circuito de ExpressRoute en Azure Portal.
Seleccione la opción Problemas de rendimiento.
Espere a que se ejecute el diagnóstico e interprete los resultados.
Si el mantenimiento se ha realizado en la puerta de enlace de red virtual durante un período en el que ha experimentado pérdida o latencia de paquetes. Es posible que la capacidad reducida de la puerta de enlace haya contribuido a problemas de conectividad que experimenta para la red virtual de destino. Siga los pasos recomendados. Siga los pasos recomendados y considere la posibilidad de actualizar la SKU de la puerta de enlace de red virtual para admitir un mayor rendimiento de red y evitar problemas de conectividad durante futuras acciones de mantenimiento.
Pasos siguientes
Para obtener más información, consulte los siguientes artículos: