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 facilita un proveedor de conectividad. La conectividad de ExpressRoute implica tres zonas de red distintas:
- 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). Este modelo incluye solo la red y las zonas de red de Microsoft.
Este artículo le ayuda a identificar problemas de conectividad y a buscar soporte técnico del equipo adecuado para resolverlos.
Importante
Este documento está pensado para ayudarle a diagnosticar y corregir problemas sencillos. No es un reemplazo del soporte técnico de Microsoft. Si no puede resolver un problema con esta guía, abra una incidencia de soporte técnico con 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, los números indican 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 perimetrales del proveedor orientados a enrutadores perimetrales del cliente.
- PE frente a enrutadores Microsoft Enterprise Edge ExpressRoute (MSEE), denominados PE-MSEE.
- MSEE.
- Puerta de enlace de red virtual.
- Proceso del dispositivo en la red virtual de Azure.
A estos puntos de red se hace referencia por su número asociado a lo largo del artículo.
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 son la colocación de intercambio en la nube, la conexión Ethernet de punto a punto o cualquier (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 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 Creación y modificación de un circuito ExpressRoute.
Sugerencia
Una clave de servicio identifica de forma única un circuito ExpressRoute. Si necesita ayuda de Microsoft o de un asociado de ExpressRoute para solucionar un problema, proporcione la clave de servicio para identificar fácilmente el circuito.
Comprobación a través de Azure Portal
En Azure Portal, vaya a 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 los aspectos básicos de ExpressRoute, estado del circuito indica el estado del circuito en el lado de Microsoft y estado del proveedor indica si el proveedor de servicios ha aprovisionado el circuito.
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:
Si el estado del circuito está bloqueado en No habilitado, póngase en contacto con Soporte técnico de Microsoft. Por otro lado, si Estado del proveedor está bloqueado en No aprovisionado, póngase en contacto con el 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
Para buscar el nombre de un grupo de recursos, use el Get-AzResourceGroup comando para enumerar todos los grupos de recursos de la suscripción.
Para obtener detalles de un circuito ExpressRoute específico en un grupo de recursos, use 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 que un circuito ExpressRoute está operativo, asegúrese de que los campos siguientes están configurados correctamente:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Nota:
Si el estado del circuito está bloqueado en No habilitado, póngase en contacto con Soporte técnico de Microsoft. Por otro lado, si Estado del proveedor está bloqueado en No aprovisionado, póngase en contacto con el proveedor de servicios.
Validación de la configuración de emparejamiento
Una vez que el proveedor de servicios ha aprovisionado el circuito ExpressRoute, puede crear varias configuraciones de enrutamiento mediante BGP externo (eBGP) a través del circuito entre CEs/MSEE-PE (2/4) y MSE (5). Cada circuito ExpressRoute puede tener una o ambas de las opciones de configuración de emparejamiento:
- Emparejamiento privado de Azure: para el tráfico a redes virtuales privadas en Azure
- Emparejamiento de Microsoft: para el 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 configuraciones de enrutamiento, consulte Creación y modificación del enrutamiento para 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). Si el emparejamiento está en blanco en el portal después de que el proveedor de servicios lo haya configurado, intente actualizar la configuración del circuito mediante el botón actualizar en el 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 su página. En la sección se enumeran los emparejamientos de ExpressRoute, como se muestra en el recorte de pantalla siguiente:
En el ejemplo anterior, se aprovisiona el emparejamiento privado de Azure, pero los emparejamientos públicos de Azure y Microsoft no lo son. Un contexto de emparejamiento aprovisionado correctamente también enumerará las subredes de punto a punto principal y secundaria. Las subredes /30 se usan para la direcciones IP de interfaz de los MSEE y los CE o los PE-MSEE. La lista también indica quién modificó por última vez la configuración.
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. Además, compruebe que los valores de VlanId, AzureASN, y PeerASN en los MSE coinciden con los del CE/PE-MSEE vinculado.
Si se elige el hash MD5, asegúrese de que la clave compartida es la misma en pares MSEE y CE/PE-MSEE. Las claves compartidas configuradas anteriormente no se mostrarán 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 usará la segunda dirección IP utilizable para la interfaz MSEE. Asegúrese de que se asigna la primera dirección IP utilizable al CE/PE-MSEE con 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 enumera los prefijos de dirección principal y secundaria. Las subredes /30 se usan para la direcciones IP de interfaz de los MSEE y los CE o los PE-MSEE.
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 no está configurado en el circuito:
Get-AzExpressRouteCircuitPeeringConfig : Sequence contains no matching element
At line:1 char:1
+ Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 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. Además, compruebe que los valores de VlanId, AzureASN, y PeerASN en los MSE coinciden con los del CE/PE-MSEE vinculado.
Si se elige el hash MD5, asegúrese de que la clave compartida es la misma en pares MSEE y CE/PE-MSEE. Las claves compartidas configuradas anteriormente no se mostrarán 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 usará la segunda dirección IP utilizable para la interfaz MSEE. Asegúrese de que se asigna la primera dirección IP utilizable al CE/PE-MSEE con 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 recuperar la tabla de enrutamiento de MSEE en la ruta de acceso principal para el contexto de enrutamiento privado, use el siguiente comando:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName <CircuitName> -PeeringType AzurePrivatePeering -ResourceGroupName <ResourceGroupName>
Respuesta de ejemplo:
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 emparejamiento de eBGP entre un MSEE y un CE/PE-MSEE es Active o Idle, compruebe que las subredes del mismo nivel principal y secundaria coinciden con la configuración en el CE/PE-MSEE vinculado. Asegúrese de que los valores de VlanId, AzureASN, y PeerASN son correctos en los MSE y que coincidan con los del CE/PE-MSEE vinculado. Si se usa el hash MD5, la clave compartida debe ser la misma en pares MSEE y CE/PE-MSEE. Para ver los cambios de configuración en un enrutador MSEE, consulte Creación y modificación del enrutamiento de un circuito ExpressRoute.
Nota:
Si no se puede llegar a determinados destinos a través de un emparejamiento, compruebe la tabla de rutas MSEE para el contexto de emparejamiento correspondiente. Si hay un prefijo coincidente, asegúrese de que no haya firewalls, grupos de seguridad de red o ACL que bloqueen el tráfico.
Respuesta de ejemplo para un emparejamiento inexistente:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Confirmación del flujo de tráfico
Para obtener estadísticas de tráfico (bytes dentro y fuera) para un contexto de emparejamiento, use el siguiente comando:
Get-AzExpressRouteCircuitStats -ResourceGroupName <ResourceGroupName> -ExpressRouteCircuitName <CircuitName> -PeeringType 'AzurePrivatePeering'
Ejemplo:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Salida de ejemplo para un emparejamiento inexistente:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> 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 usa una ACL para contar paquetes que alcanzan reglas específicas, lo que confirma la conectividad.
Ejecución de una prueba
En Azure Portal, seleccione Diagnosticar y resolver problemas en el circuito ExpressRoute.
Seleccione Conectividad e Incidencias de rendimiento.
En el Cuéntanos más sobre el problema que experimenta lista desplegable, seleccione Problemas con el emparejamiento privado.
Expanda la sección Probar conectividad de emparejamiento privado.
Ejecute la prueba de PsPingdesde la dirección IP local a la dirección IP de Azure y manténgala en ejecución durante la prueba.
Rellene los campos del formulario con las mismas direcciones IP usadas en el paso 5 y, a continuación, seleccione Enviar y espere los resultados.
Interpretación de los resultados
Revise los resultados de los dispositivos MSEE principal y secundario:
Coincidencias enviadas y recibidas en ambos MSEE: indica el tráfico correcto entrante y saliente. Cualquier pérdida es descendente de los MSEE.
Coincidencias recibidas pero no coincidencias enviadas: el tráfico llega a Azure pero no se devuelve. Compruebe los problemas de enrutamiento de la ruta de acceso de retorno.
Coincidencias enviadas pero no coincidencias recibidas: el tráfico llega al entorno local, pero no vuelve a Azure. Trabaje con el proveedor para resolverlo.
Una MSEE no muestra ninguna coincidencia, la otra muestra buenas coincidencias: indica que un MSEE no recibe ni pasa tráfico. Podría estar sin conexión.
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
Comprobación de la disponibilidad de la puerta de enlace de red virtual
La puerta de enlace de red virtual de ExpressRoute administra la conectividad a servicios de vínculo privado y direcciones IP privadas en una red virtual de Azure. Microsoft administra esta infraestructura y podría realizar tareas de mantenimiento, lo que reduciría el rendimiento.
Para solucionar problemas de conectividad y comprobar si hay mantenimiento reciente:
En Azure Portal, seleccione Diagnosticar y resolver problemas en el circuito ExpressRoute.
Seleccione Problemas de rendimiento.
Espere a que los diagnósticos se ejecuten e interpreten los resultados.
Si se produjo el mantenimiento durante la pérdida o latencia de paquetes, es posible que haya contribuido a problemas de conectividad. Siga los pasos recomendados y considere la posibilidad de actualizar la SKU de puerta de enlace de red virtual para admitir un mayor rendimiento y evitar problemas futuros.
Pasos siguientes
Para obtener más información, consulte los siguientes artículos: