验证 ExpressRoute 连接
本文可帮助验证 Azure ExpressRoute 连接并对其进行故障排除。 ExpressRoute 可以通过往往已由连接服务提供商优化的专用连接,将本地网络扩展到 Azure 云。 传统上,ExpressRoute 连接涉及到三个不同的网络区域:
- 客户网络
- 提供商网络
- Azure 数据中心
注意
在 ExpressRoute Direct 连接模型中,可以直接连接到 Microsoft Enterprise Edge (MSEE) 路由器的端口。 直接连接模型仅包括客户和 Azure 网络区域。
本文可帮助识别是否存在连接问题以及哪里存在此问题。 然后,可以寻求相应团队的支持来解决问题。
重要
本文旨在帮助诊断和修复简单问题。 它不是为了替代 Azure 支持部门。 如果无法使用本文中的指南解决问题,请向 Azure 支持部门提交支持票证。
概述
下图显示了客户网络通过 ExpressRoute 连接到 Azure 网络时的逻辑连接。
在上图中,数字表示关键网络点:
- 客户计算设备(例如服务器或电脑)。
- 客户边缘路由器 (CE)。
- 提供商边缘路由器/交换机 (PE),面向客户边缘路由器。
- 面向 Microsoft Enterprise Edge ExpressRoute 路由器 (MSEE) 的 PE。 本文称其为“PE-MSEE”。
- MSEE。
- 虚拟网络网关。
- Azure 虚拟网络上的计算设备。
有时,本文通过关联编号引用这些网络点。
根据 ExpressRoute 连接模型,网络点 3 和 4 可能是交换机(第 2 层设备)或路由器(第 3 层设备)。 ExpressRoute 连接模型是云交换归置、点对点以太网连接或任意互连 (IPVPN)。
在直接连接模型中,不存在网络点 3 和 4。 相反,CE (2) 通过暗光纤直接连接到 MSEE。
如果使用云交换场地租用、点对点以太网或直接连接模型,则 CE (2) 将会与 MSEE (5) 建立边界网关协议 (BGP) 对等互连。
如果使用任意互连 (IPVPN) 连接模型,则 PE-MSEE (4) 将与 MSEE (5) 建立 BGP 对等互连。 PE-MSEE 通过 IPVPN 服务提供商网络将从 Azure 收到的路由传播回到客户网络。
注意
为了实现高可用性,Azure 将在 MSEE 和 PE-MSEE 对之间建立完全冗余的并行连接。 另外,建议在客户网络和 PE/CE 对之间建立完全冗余的并行网络路径。 有关高可用性的详细信息,请参阅使用 ExpressRoute 进行高可用性设计一文。
以下部分介绍了对 ExpressRoute 线路进行故障排除的逻辑步骤。
验证线路预配和状态
预配 ExpressRoute 线路可在 CE/PE-MSEE (2/4) 与 MSEE (5) 之间建立冗余的第 2 层连接。 若要详细了解如何创建、修改、预配和验证 ExpressRoute 线路,请参阅创建和修改 ExpressRoute 线路一文。
提示
服务密钥可以唯一地标识 ExpressRoute 线路。 如果需要 Azure 或 ExpressRoute 合作伙伴的帮助来排查 ExpressRoute 问题,请提供服务密钥以轻松识别线路。
通过 Azure 门户进行验证
在 Azure 门户中,打开 ExpressRoute 线路的页面。 该页面的 部分列出了 ExpressRoute 概要,如以下屏幕截图所示:
在 ExpressRoute 概要中,“线路状态”表示 Azure 这一侧线路的状态。 “提供商状态”表示线路在服务提供商这一侧的状态为“已预配”还是“未预配”。
若要确保 ExpressRoute 线路正常运行,“线路状态”必须为“已启用”,“提供商状态”必须为“已预配”。
注意
配置 ExpressRoute 线路后,如果“线路状态”停留在“未启用”状态,请联系 Azure 支持部门。 如果“提供商状态”停留在“未预配”状态,请联系服务提供商。
通过 PowerShell 进行验证
若要列出资源组中的所有 ExpressRoute 线路,请使用以下命令:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"
提示
若要查找资源组的名称,可以使用 Get-AzResourceGroup
命令列出订阅中的所有资源组来获取。
若要选择资源组中的特定 ExpressRoute 线路,请使用以下命令:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
下面是示例响应:
Name : Test-ER-Ckt
ResourceGroupName : Test-ER-RG
Location : chinanorth2
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 : []
若要确认 ExpressRoute 线路正常运行,请特别注意以下字段:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
注意
配置 ExpressRoute 线路后,如果“线路状态”停留在“未启用”状态,请联系 Azure 支持部门。 如果“提供商状态”停滞在“未预配”状态,请联系服务提供商。
验证对等互连配置
服务提供商完成 ExpressRoute 线路预配后,可在 CE/MSEE-PE (2/4) 和 MSEE (5) 之间通过 ExpressRoute 线路创建基于外部 BGP (eBGP) 的多个路由配置。 每个 ExpressRoute 线路可以具有以下一种或两种对等互连配置:
- Azure 专用对等互连:流向 Azure 中的专用虚拟网络的流量
- Microsoft 对等互连:流向平台即服务 (PaaS) 和服务型软件 (SaaS) 的公共终结点的流量
有关如何创建和修改路由配置的详细信息,请参阅创建和修改 ExpressRoute 线路的路由一文。
通过 Azure 门户进行验证
注意
在 IPVPN 连接模型中,服务提供商负责处理对等互连(第 3 层服务)的配置。 在此类模型中,如果在服务提供商配置对等互连后,对等互连在门户中是空白的,请尝试使用门户上的刷新按钮刷新线路配置。 此操作会从线路中提取当前路由配置。
在 Azure 门户中,可以在该线路的页面上检查 ExpressRoute 线路的状态。 该页面的 部分列出了 ExpressRoute 对等互连,如以下屏幕截图所示:
在前面的示例中,已预配 Azure 专用对等互连,但尚未预配 Azure 公共对等互连和 Microsoft 对等互连。 成功预配的对等互连上下文还会列出主要和辅助的点到点子网。 /30 子网用于 MSEE 和 CE/PE-MSEE 的接口 IP 地址。 对于已预配的对等互连,列表中还会指示上次修改配置的用户。
注意
如果对等互连启用失败,请检查分配的主要子网和辅助子网是否与链接的 CE/PE-MSEE 上的配置相匹配。 还要检查 MSEE 上是否使用了正确的 VlanId
、AzureASN
和 PeerASN
值,以及这些值是否映射到链接的 CE/PE-MSEE 上使用的值。
如果选择了 MD5 哈希,则 MSEE 和 CE/PE-MSEE 对上的共享密钥应相同。 出于安全原因,不会显示以前配置的共享密钥。
如果需要在 MSEE 路由器上更改其中的任何配置,请参阅创建和修改 ExpressRoute 线路的路由。
注意
在为接口分配的 /30 子网中,Azure 将为 MSEE 接口选择该子网的第二个可用 IP 地址。 因此,请确保已在对等互连的 CE/PE-MSEE 上分配该子网的第一个可用 IP 地址。
通过 PowerShell 进行验证
若要获取 Azure 专用对等互连的配置详细信息,请使用以下命令:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt
下面是已成功配置的专用对等互连的示例响应:
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
成功启用的对等互连上下文会列出主要的和辅助的地址前缀。 /30 子网用于 MSEE 和 CE/PE-MSEE 的接口 IP 地址。
要获取 Microsoft 对等互连的配置详细信息,请使用以下命令:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt
如果未配置对等互连,将会收到一条错误消息。 下面是未在电路中配置所述对等互连时的示例响应:
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
注意
如果对等互连启用失败,请检查分配的主要子网和辅助子网是否与链接的 CE/PE-MSEE 上的配置相匹配。 还要检查 MSEE 上是否使用了正确的 VlanId
、AzureASN
和 PeerASN
值,以及这些值是否映射到链接的 CE/PE-MSEE 上使用的值。
如果选择了 MD5 哈希,则 MSEE 和 CE/PE-MSEE 对上的共享密钥应相同。 出于安全原因,不会显示以前配置的共享密钥。
如果需要在 MSEE 路由器上更改其中的任何配置,请参阅创建和修改 ExpressRoute 线路的路由。
注意
在为接口分配的 /30 子网中,Azure 将为 MSEE 接口选择该子网的第二个可用 IP 地址。 因此,请确保已在对等互连的 CE/PE-MSEE 上分配该子网的第一个可用 IP 地址。
验证 ARP
地址解析协议 (ARP) 表为特定的对等互连提供 IP 地址和 MAC 地址的映射。 用于 ExpressRoute 线路对等互连的 ARP 表为每个接口(主接口和辅助接口)提供以下信息:
- 将本地路由器接口的 IP 地址映射到 MAC 地址
- 将 ExpressRoute 路由器接口的 IP 地址映射到 MAC 地址(可选)
- 映射的使用期限
ARP 表可帮助验证第 2 层配置,并可针对第 2 层的基本连接问题进行排除故障。
注意
ARP 结果可能会因硬件平台而有所不同,并且仅显示本地接口。
若要了解如何查看 ExpressRoute 对等互连的 ARP 表,以及如何使用这些信息来排查第 2 层连接问题,请参阅在资源管理器部署模型中获取 ARP 表。
验证 BGP 以及 MSEE 上的路由
对于专用路由上下文,若要获取主要路径上的 MSEE 的路由表,请使用以下命令:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName ******* -PeeringType AzurePrivatePeering -ResourceGroupName ****
下面是示例响应:
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##
注意
如果 MSEE 与 CE/PE-MSEE 之间的 eBGP 对等互连状态为“活动”或“空闲”,请检查分配的主要和辅助对等子网是否与链接的 CE/PE-MSEE 上的配置相匹配 。 还要检查 MSEE 上是否使用了正确的 VlanId
、AzureASN
和 PeerASN
值,以及这些值是否映射到链接的 CE/PE-MSEE 上使用的值。 如果选择了 MD5 哈希,则 MSEE 和 CE/PE-MSEE 对上的共享密钥应相同。 如果需要在 MSEE 路由器上更改其中的任何配置,请参阅创建和修改 ExpressRoute 线路的路由。
注意
如果无法通过某个对等互连访问某些目标,请检查相应对等互连上下文的 MSEE 的路由表。 如果路由表中存在匹配的前缀(可能为 NATed IP),则检查路径上是否有防火墙、网络安全组或访问控制列表 (ACL) 正在阻止流量。
以下示例显示不存在的对等互连的命令响应:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
确认流量流
若要获取对等互连上下文在主要路径和辅助路径上的综合流量统计信息(出入字节数),请使用以下命令:
Get-AzExpressRouteCircuitStats -ResourceGroupName $RG -ExpressRouteCircuitName $CircuitName -PeeringType 'AzurePrivatePeering'
这是命令的示例输出:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
以下是不存在的对等互连的命令输出示例:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
测试专用对等互连
通过计算在 MSEE 设备上到达和离开 ExpressRoute 线路 Azure 边缘的数据包来测试专用对等互连连接。 此诊断工具的工作原理是将访问控制列表 (ACL) 应用于 MSEE,以计算命中特定 ACL 规则的数据包数。 使用此工具,可以通过回答问题来确认连接性,例如:
- 我的数据包是否到达了 Azure?
- 它们是否回到了本地?
运行测试
若要访问此诊断工具,请从 Azure 门户的 ExpressRoute 线路选择“诊断并解决问题”。
选择“连接性和性能问题”。
在“告诉我们你遇到的问题”下拉列表中,选择“专用对等互连问题”。
向下滚动到“测试专用对等互连连接”部分并展开它。
运行从本地 IP 地址到 Azure IP 地址的 PsPing 测试,并在连接测试期间保持运行。
填充窗体字段。 请确保输入在步骤 5 中使用的本地和 Azure IP 地址。 选择“提交”,然后等待加载结果。
解释结果
结果准备就绪后,你将拥有两组结果,可用于主要和辅助 MSEE 设备。 查看传入和传出的数据包匹配数,并使用以下方案来解释结果:
两个 MSEE 上发送和接收的数据包数相匹配:该结果表明线路上的 MSEE 的入站和出站流量正常。 如果在本地或 Azure 中发生数据包丢失的事件,则该事件发生在 MSEE 的下游。
如果正在测试从本地到 Azure 的 PsPing,收到的结果显示匹配,但发送的结果显示不匹配:该结果表明流量进入 Azure,但未返回本地。 检查返回路径路由问题。 例如,是否向 Azure 播发了相应的前缀? 用户定义的路由 (UDR) 是否覆盖前缀?
如果正在测试从 Azure 到本地的 PsPing,发送的结果显示匹配,但接收的结果显示不匹配:该结果表明流量进入本地,但未返回 Azure。 请与提供商合作,找出流量未通过 ExpressRoute 线路路由到 Azure 的原因。
某个 MSEE 显示没有匹配,但另一个显示匹配良好:此结果表明该 MSEE 没有接收或传递任何流量。 它可能处于脱机状态(例如 BGP/ARP 已关闭)。
- 可以通过在此路径上的 BGP 会话上播发唯一的 /32 本地路由来运行其他测试以确认不正常的路径。
- 使用播发为本地目标地址的唯一 /32 运行“测试专用对等互连连接”,并查看结果以确认路径运行状况。
每台 MSEE 设备的测试结果如以下示例所示:
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
此测试结果具有以下属性:
- IP 端口:3389
- 本地 IP 地址 CIDR:10.0.0.0
- Azure IP 地址 CIDR:20.0.0.0
验证虚拟网络网关的可用性
ExpressRoute 虚拟网络网关有助于管理和控制平面与部署到 Azure 虚拟网络的专用链接服务和专用 IP 进行连接。 虚拟网络网关基础结构由 Azure 管理,并且有时会进行维护。
在维护期间,虚拟网络网关的性能可能会下降。 要排查虚拟网络的连接问题,并查看最近的维护事件是否导致容量减少,请执行以下步骤:
从 Azure 门户中的 ExpressRoute 线路中选择“诊断和解决问题”。
选择“性能问题”选项。
等待诊断运行,并解释结果。
如果在遇到数据包丢失或延迟的时间段内对虚拟网络网关进行了维护。 网关容量减少可能会导致目标虚拟网络出现连接问题。 请执行建议的步骤。 要支持更高的网络吞吐量并避免在将来的维护事件期间出现连接问题,请考虑升级虚拟网络网关 SKU。
后续步骤
有关详细信息或帮助,请查看以下链接: