[解决方案] 使用 Azure Route Server 实现中心网络间连接

<!-- AI_TASK_START: AI标题翻译 --> [解决方案] 使用 Azure Route Server 实现中心网络间连接 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 基于 Azure Route Server 的 Hub 间连接解决方案分析 ## 解决方案概述 Azure Route Server (ARS) 旨在解决 **Hub-and-Spoke** 拓扑中 Hub 间连接的复杂性问题，通过 **动态学习和广告路由**，减少手动配置的 User-Defined Routes (UDRs)。该方案适用于多区域 Azure 环境，满足高可用性和冗余需求，如 **bowtie** 配置下的 ExpressRoute 连接。核心技术原理基于 **BGP 协议**，ARS 作为路由服务器，在 Hub VNet 中部署，与 Network Virtual Appliances (NVAs) 建立对等关系，实现路由动态传播和优化。 ## 实施步骤 1. **部署 ARS 和基础架构** - 在每个 Hub VNet 中部署 ARS，并确保与本地和远程 ExpressRoute 电路连接。禁用 VNet-to-VNet 配置以保持可预测路由。理由：ARS 需要与现有 Virtual Network Gateway 集成，可能导致约 10 分钟停机。 2. **配置 BGP 对等关系** - 在每个 Hub 中，让 NVA 与本地 ARS 和远程 ARS 建立 BGP 对等。例如，NVA1 与 ARS1 和 ARS2 对等。启用 **AS-Override** 以防止 BGP 循环。逻辑衔接：这允许 NVA 动态学习 Spoke 前缀，避免手动 UDR 配置。 3. **设置流量路由规则** - 在 Spoke VNet 上应用 UDR，包含默认路由 (0.0.0.0/0) 指向本地 NVA，并将 “Propagate Gateway Routes” 设置为 False。理由：确保所有流量通过 NVA 进行检查，同时避免无效路径。 4. **处理特定场景** - 对于 **Scenario 1 (Option A)**，在 Hub VNet 中共存 ARS 和 NVA，实现全流量检查。 - 对于 **Option B**，NVA 广告超网前缀到远程 ARS，绕过本地对等以简化配置。 - 对于 **Scenario 2**，将 NVA 部署到 Transit VNet，并与本地和远程 Hub VNet 对等。添加静态路由并广告到 ARS。理由：减少 GatewaySubnet 中的 UDR 复杂性，提高可伸缩性。 ## 方案客户价值 - **简化路由管理**：减少手动 UDR 配置，尤其在多 Hub 环境中，节省运维开销。 - **提高可伸缩性和冗余**：通过动态路由处理非连续前缀，实现高可用 bowtie 配置，相比传统方案降低手动错误风险。 - **量化收益**：如减少 UDR 条目需求，间接提升效率；例如，ARS 支持动态学习路由，避免了传统方案中可能导致的路由错误。相比竞品（如 AWS Transit Gateway），该方案在 Azure 生态中提供更无缝的 ExpressRoute 集成，减少跨区域流量延迟。 ## 涉及的相关产品 - **Azure Route Server (ARS)**：作为路由服务器，在 Hub VNet 中部署，用于动态学习和广告路由，确保 Hub 间连接。 - **Network Virtual Appliances (NVAs)**：在 Hub 或 Transit VNet 中部署，与 ARS 建立 BGP 对等，实现流量检查和路由传播。 - **ExpressRoute**：提供 bowtie 配置下的高可用连接，ARS 通过它广告路由到 on-premises 网络。 - **Virtual Network Gateway**：处理 ExpressRoute 连接，支持权重配置以优先本地路径。 ## 技术评估 - **先进性**：方案利用 BGP 的动态特性，提高了路由自动化的水平，适用于大规模 Hub-and-Spoke 架构，优势在于减少手动干预和提升路由预测性。 - **可行性**：部署相对简单，但需注意潜在停机和 BGP 配置细节，如 AS-Override 启用。可行范围限于 Azure 环境，易与现有网络集成。 - **优势**：简化 UDR 管理，支持非连续前缀路由；通过权重和 AS-Path 优化路径选择，确保流量对称性。 - **限制**：ARS 每实例限 8 个 BGP 对等，可能影响多 NVA 场景；UDR 条目限 400，易在 Spoke 数量增加时受限；bowtie 配置下，非最佳路径风险需通过 AS-Prepend 缓解。总体而言，该方案在 Azure 网络中表现出色，但需根据规模评估对等限制。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # 使用 Azure 路由服务器实现 Hub 间连接性 **原始链接:** [https://techcommunity.microsoft.com/blog/azurenetworkingblog/inter-hub-connectivity-using-azure-route-server/4434279](https://techcommunity.microsoft.com/blog/azurenetworkingblog/inter-hub-connectivity-using-azure-route-server/4434279) **发布时间:** 2025-07-18 **厂商:** AZURE **类型:** TECH-BLOG --- Azure 网络博客 # 使用 Azure 路由服务器实现 Hub 间连接性 2025 年 7 月 18 日 作者 [Mays_Algebary](<javascript:void(0)>) [shruthi_nair](<javascript:void(0)>) 随着 Azure 足迹通过 Hub-和-Spoke 拓扑扩展，管理 Hub 间连接性的用户定义路由 (User-Defined Routes, UDRs) [可能很快变得复杂且容易出错](<https://techcommunity.microsoft.com/blog/azurenetworkingblog/inspection-patterns-in-hub-and-spoke-and-vwan-architectures/4430491>)。在本篇文章中，我们将探讨如何使用 **Azure 路由服务器 (Azure Route Server, ARS)** 通过动态学习和广告路由来简化 Hub 间路由，从而减少手动开销并提升可扩展性。 **基准架构** 基准架构包括两个 Hub 虚拟网络 (Virtual Network, VNet)，每个 Hub 虚拟网络都与各自的本地 Spoke 虚拟网络以及另一个 Hub 虚拟网络进行对等连接，以实现 Hub 间连接性。两个 Hub 都连接到本地和远程 ExpressRoute 电路，使用 **bowtie** 配置确保高可用性和冗余，通过 **Weight** 优先选择本地 ExpressRoute 电路而非远程电路。 为了保持可预测的路由行为，ExpressRoute 网关上的 **[VNet 到 VNet 配置](<https://learn.microsoft.com/en-us/azure/expressroute/virtual-network-connectivity-guidance>)** 应 **禁用**。 **基准架构** **注意:**_在现有 Hub 中添加 ARS 时，与虚拟网络网关共存将导致停机，预计持续 10 分钟。[<https://learn.microsoft.com/en-us/azure/route-server/route-server-faq#does-creating-a-route-server-affect-the-operation-of-existing-virtual-network-gateways-vpn-or-expressroute>]_ #### **场景 1: ARS 和 NVA 在 Hub 中共存** ##### **选项 A: 全流量检查** **全检查:** **ARS 和 NVA 在 Hub 中共存** 在此场景中，**ARS** 部署在 **每个 Hub VNet** 中，与网络虚拟设备 (Network Virtual Appliances, NVAs) 共存。 - **NVA1** 在 Region1 与本地 ARS (**ARS1**) 和远程 ARS (**ARS2**) 建立 BGP 对等。 - 类似地，**NVA2** 在 Region2 与 **ARS2** (本地) 和 **ARS1** (远程) 建立对等。 让我们分解每个 BGP 对等关系的作用。为清晰起见，我们关注 **Region1**，尽管相同逻辑适用于 **Region2**： 1. **NVA1 与本地 ARS1 对等** - 通过与 **ARS1** 的 BGP 对等，**NVA1** 在操作系统 (OS) 级别动态学习 **Spoke1** 和 **Spoke2** 前缀，从而无需手动配置这些路由。 - 同样，**NVA2** 通过与 **ARS2** 的 BGP 对等学习 **Spoke3** 和 **Spoke4** 前缀。 2. **NVA1 与远程 ARS2 对等** - 当 **NVA1** 与 **ARS2** 对等时，**Spoke1** 和 **Spoke2** 前缀会传播到 **ARS2**。 - **ARS2** 然后将这些前缀注入到 **NVA2** 中，在网络接口控制器 (NIC) 级别以 **NVA1** 为下一跳，并在 OS 级别。这机制消除了在 NVA 子网上使用 UDRs 来启用 Hub 间路由的需要。 - 此外，**ARS2** 通过 **GW2** 向两个 ExpressRoute 电路 (**EXR2** 和 **EXR1**，由于 bowtie 配置) 广告 **Spoke1** 和 **Spoke2** 前缀，从而使这些前缀从本地 (on-premises) 通过 **EXR1** 或 **EXR2** 可达。 **👉重要:** 为了确保 ARS2 接受并传播通过 NVA1 接收的 **Spoke1/Spoke2** 前缀，必须启用 **AS-Override**。 没有 AS-Override，**BGP 循环预防** 将在 ARS2 阻塞这些路由，因为 **ARS1** 和 **ARS2** 使用默认自治系统号 (Autonomous System Number, ASN) **65515**，ARS2 会认为该路由已本地起源。 相同原则适用于从 **NVA2** 到 **ARS1** 广告的 **Spoke3** 和 **Spoke4** 前缀。 ##### **流量流** - **Hub 间流量:** Spoke 虚拟网络配置有 UDRs，仅包含一个 **默认路由 (0.0.0.0/0)**，下一跳指向本地 NVA。此外，“传播网关路由”设置应设为 **False**，以强制所有流量（无论是 **East-West**（内部/Hub 间）还是 **North-South**（往返互联网））通过本地 NVA 进行检查。本地 NVAs 将由本地 ARS 在 NIC 级别注入下一跳，指向其他区域的 NVA，例如 NVA2 将 Spoke1 和 Spoke2 的下一跳设为 NVA1 (10.0.1.4)，反之亦然。 **从 NVA2 显示 Spoke1 和 Spoke2 的下一跳为 NVA1 NIC 的片段** **_为什么即使 ARS 处理动态路由，Spokes 仍需要 UDRs?_** 即使使用 ARS，UDRs 仍需用于维护流量检查的下一跳控制。 例如，如果 Spoke1 和 Spoke2 没有 UDRs，它们将通过 ARS1 学习远程 Spoke 前缀（如 Spoke3/Spoke4），这些前缀来自 NVA2。这会导致 Spoke1/Spoke2 尝试直接路由流量到 NVA2，这条路径无效，因为 Spokes 没有到 NVA2 的路径。UDR 确保流量正确路由通过 NVA1。 - **本地流量:** 要解释本地流量流，我们将其分为两个方向：Azure 到本地，以及本地到 Azure。 **Azure 到本地流量流:** 如前所述，Spokes 通过 UDR 中的默认路由将所有流量（包括到本地的）发送到 NVA1。 NVA1 然后将流量路由到本地 ExpressRoute 电路，使用 **Weight** 优先选择本地路径。 **注意:**_虽然 **NVA1** 在 OS 级别从本地和远程 ARSs 学习本地前缀，但这不会影响路由决策。实际的 NIC 级别路由注入确定下一跳，确保流量通过正确路径发送——即使 OS 内部选择不同的“最佳”路由。_ 下面的截图从 NVA1 显示到本地网络 10.2.0.0/16 的四个下一跳，包括本地 ARS (ARS1: 10.0.2.5 和 10.0.2.4) 和远程 ARS (ARS2: 10.1.2.5 和 10.1.2.4)。 **从 NVA1 OS 路由表的片段** **本地到 Azure 流量流** 在 **bowtie** ExpressRoute 配置中，Azure VNet 前缀通过本地和远程 ExpressRoute 电路广告到本地网络。由于这种双重广告，本地网络必须确保到 Azure 的 **最佳路径选择**。 从 Azure 侧，为了保持流量对称性，在 GatewaySubnet (GW1 和 GW2) 上添加 UDRs，使用 **特定** 路由到本地 Spoke 虚拟网络，并以本地 NVA 为下一跳。这确保返回流量通过相同路径流动。 **👉ExpressRoute 边缘路由器如何选择最佳路径?** 你可能想知道：_如果 Spoke 前缀由 GW1 和 GW2 广告，ExpressRoute 边缘路由器如何选择最佳路径?_ _(例如，下图显示 EXR1 从 GW1 和 GW2 学习 Region1 前缀)_ **EXR1 从 GW1 和 GW2 学习 Region1 前缀** 过程如下： - **边缘路由器** (如 EXR1) 从 **两个网关** 接收相同的 Spoke 前缀。 - 然而，这些路由具有 **不同的 AS-Path 长度**： - 来自 **本地网关 (GW1)** 的路由具有 **较短的 AS-Path**。 - 来自 **远程网关 (GW2)** 的路由具有 **较长的 AS-Path**，因为 **NVA1 的 ASN (例如 65001)** 在 **AS-Override** 机制中 **两次前置**。 结果，边缘路由器 (EXR1) 将 **优先本地路径** 来自 **GW1**，确保高效且可预测的路由。 例如： EXR1 从 **GW1** 和 **GW2** 接收 **Spoke1**、**Spoke2** 和 **Hub1-VNet** 前缀。但由于通过 **GW1** 的路径具有较短的 AS-Path，EXR1 将选择该路径作为最佳路由。(参考下图以查看 AS-Path 差异的可视化)。 **EXR1 显示 AS-Path 差异的可视化** **最终流量流:** **选项 A: 全检查流量流** **选项 A 见解:** - 此设计简化了 Hub 间路由的 UDR 配置，尤其适用于处理 **非连续前缀** 或跨多个 Hub 的场景。 - 为简化起见，我们在本文中解释设置和流量流时使用了每个 Hub-VNet 中的单个 NVA。然而，推荐使用 **高可用 (HA)** NVA 部署。要在 HA 设置中保持流量对称性，需要在与 Azure 路由服务器 (ARS) 对等时启用 [下一跳 IP 功能](<https://learn.microsoft.com/en-us/azure/route-server/next-hop-ip>)。 - 当 **需要本地流量检查** 时，GatewaySubnet 中的 UDR 设置会随着 Spoke 数量增加而变得更复杂。此外，每个路由表当前限于 **[400 个 UDR 条目](<https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#publicip-address>)**。 - 随着 Azure 网络扩展，请记住 Azure 路由服务器支持每个实例 **[最多 8 个 BGP 对等](<https://learn.microsoft.com/en-us/azure/route-server/route-server-faq#what-are-azure-route-server-limits>)** (撰写本文时)。此限制可能影响涉及多个 NVA 或 Hub 的架构。 ##### **选项 B: 绕过本地检查** 如果不需要本地流量检查，NVAs 可以广告一个 **supernet 前缀** 来总结本地 Spoke 虚拟网络到远程 ARS。这种方法为路由通过 NVA 的流量提供粒度控制，并消除本地 NVA 与本地 ARS 之间的 BGP 对等需求。架构的其他方面与 **选项 A** 相同。 例如，NVA2 可以向 ARS1 广告 supernet **192.168.2.0/23** (Spoke3 和 Spoke4 的 supernet)。结果，Spoke1 和 Spoke2 将学习此路由，以 NVA2 为下一跳。 为了确保适当路由 (如前所述) 和 Hub 间检查，需要在 Spoke1 和 Spoke2 上应用 UDR，以覆盖此确切 supernet 前缀，将流量重定向到 **NVA1** 作为下一跳。 同时， destined 到本地的流量 在此设置中： - Spokes 上的 UDRs 应将 **“传播网关路由”** 设置为 **True**。 - **GatewaySubnet** 不需要 UDRs。 **👉NVA2 仍然可以广告特定 Spoke 前缀吗?** 你可能想知道：_NVA2 可以改为广告从 ARS2 学习的具体前缀 (如 Spoke3 和 Spoke4) 到 ARS1，而不是 supernet?_ 是的，这在技术上是可能的，但需要维护 NVA2 与 ARS2 之间的 BGP 对等。 然而，这会在 Spoke1 和 Spoke2 中引入 **UDR 复杂性**，因为你需要 **手动覆盖每个特定前缀**。这也违背了使用 ARS 简化路由传播的目的，削弱了设计的效率和可扩展性。 **绕过本地检查** **最终流量流:** **选项 B: 绕过本地检查流量流** **选项 B 见解:** - 此方法减少了每个 ARS 的 BGP 对等数量。从每个 Hub 维护两个 BGP 会话 (本地 NVA 和远程 NVA) 改为 **仅一个**，从而为 ARS 的 [8 个对等限制](<https://learn.microsoft.com/en-us/azure/route-server/route-server-faq#what-are-azure-route-server-limits>) 保留容量，以支持额外的 Hub 间 NVA 对等。 - 每个 NVA 应向远程 ARS 广告 supernet 前缀。如果 Spokes 未使用 **连续 IP 地址空间**，这可能具有挑战性，如 **选项 B** 所述。 #### **场景 2: ARS 在 Hub 中，NVA 在 Transit VNet 中** 在 **场景 1** 中，我们强调当需要本地检查时，随着 Spoke 虚拟网络数量增长，GatewaySubnet 中的 UDR 管理变得越来越复杂。这是由于需要 UDRs 包含每个 Spoke 虚拟网络的 **特定** 前缀。在本场景中，我们完全消除了在 GatewaySubnet 上应用 UDRs 的需求。 **ARS 在 Hub 中，NVA 在 Transit VNet 中** 在此设计中，NVA 将部署在 Transit VNet 中，其中： - Transit-VNet 将与本地 Spoke 虚拟网络以及本地 Hub-VNet 进行对等，以启用内部 Hub 和本地连接。 - Transit-VNet 还与远程 Transit VNets (例如 Transit-VNet1 与 Transit-VNet2 对等) 进行对等，以通过 NVAs 处理 Hub 间连接。 - 此外，Transit-VNets 与远程 Hub-VNets 进行对等，以与远程 ARS 建立 BGP 对等。 - NVAs 的 OS 需要添加静态路由，用于本地 Spoke 虚拟网络前缀，可以是特定前缀或 supernet 前缀，这些将通过 BGP 对等广告到 ARSs，然后 ARS 将其通过 ExpressRoute 广告到本地。 - NVAs 将与本地 ARS 和远程 ARS 建立 BGP 对等。 要理解此设计的原理，让我们更仔细地查看 **Region1** 中的设置，重点关注 ARS 和 NVA 如何配置以连接到 Region2。这将帮助说明 Hub 间和本地连接。相同概念从 Region2 到 Region1 反向应用。 **Hub 间:** - 要使 **NVA1** 在 **Region1** 学习 Region2 的前缀，NVA2 将在 OS 级别为 Spoke3 和 Spoke4 (或其 supernet 前缀) 配置静态路由，并通过远程 BGP 对等广告到 ARS1。 - 结果，这些前缀将被 **NVA1** 接收，在 NIC 级别以 NVA2 为下一跳，并在 OS 级别用于适当路由。 - Spoke1 和 Spoke2 将有一个 UDR，其中默认路由指向 **NVA1** 作为下一跳。例如，当 Spoke1 需要与 Spoke3 通信时，流量将首先路由通过 NVA1。NVA1 然后将流量转发到 NVA2，使用两个 Hub 之间的 VNet 对等。 - 在 Region2 中应用类似配置，其中 NVA1 将在 OS 级别为 Spoke1 和 Spoke2 (或其 supernet 前缀) 配置静态路由，并通过远程 BGP 对等广告到 ARS2，结果这些前缀将被 **NVA2** 接收，在 NIC 级别 (由 ARS2 注入) 以 NVA1 为下一跳，并在 OS 级别用于适当路由。 **注意:** _在 OS 级别，NVA1 从本地和远程 ARSs 学习 Spoke3 和 Spoke4 前缀。然而，NIC 级别路由注入确定实际下一跳，因此即使 OS 选择不同的最佳路由，也不会影响转发行为。相同适用于 NVA2。_ - **本地流量:** 要解释本地流量流，我们将其分为两个方向：Azure 到本地，以及本地到 Azure。 **Azure 到本地流量流:** - Region1 中的 Spokes 通过 UDRs 中的默认路由将所有流量路由通过 NVA1。 - 由于 NVA1 与 ARS1 的 BGP 对等，ARS1 通过 ExpressRoute (EXR1) 广告 Spoke1 和 Spoke2 (或其 supernet 前缀) 到本地。 - Transit-VNet1 (托管 NVA1) 与 Hub1-VNet 对等，并启用 “使用远程网关”。这允许 NVA1 从本地 ExpressRoute 网关 (GW1) 学习本地前缀，并由于较高的 BGP Weight 配置，将流量路由到本地 ExpressRoute 电路 (EXR1)。 **注意:** _在 OS 级别，NVA1 从本地和远程 ARSs 学习本地前缀。然而，NIC 级别路由注入确定实际下一跳，因此即使 OS 选择不同的最佳路由，也不会影响转发行为。相同适用于 NVA2。_ **本地到 Azure 流量流:** - 通过与 ARS1 的 BGP 对等，NVA1 使 ARS1 广告 Spoke1 和 Spoke2 (或其 supernet 前缀) 到两个 EXR1 和 EXR2 电路 (由于 ExpressRoute bowtie 设置)。 - 此外，由于 NVA1 与 ARS2 的 BGP 对等，ARS2 也广告 Spoke1 和 Spoke2 (或其 supernet 前缀) 到 EXR2 和 EXR1 电路。 - 结果，Region1 和 Region2 中的两个 ExpressRoute 边缘路由器从 GW1 和 GW2 学习相同的 Spoke 前缀 (或其 supernet 前缀)，具有相同的 AS-Path 长度，如下所示。 **EXR1 从 GW1 和 GW2 学习 Region1 Spokes 的 supernet 前缀** - 这会导致非最佳入站路由，其中 destined 到 Region1 Spokes 的本地流量可能首先到达 Region2 的 Hub2-VNet，然后再遍历到 Region1 中的 NVA1。然而，从 Spoke1 和 Spoke2 的返回流量将始终通过 Hub1-VNet 退出。 - 要防止次优路由，配置 NVA1 在向远程 ARS2 广告 Spoke1 和 Spoke2 (或其 supernet 前缀) 时前置 AS 路径。同样，确保 NVA2 在向 ARS1 广告 Spoke3 和 Spoke4 (或其 supernet 前缀) 时前置 AS 路径。这种方法有助于在正常条件和 ExpressRoute 故障转移场景下保持最佳路由。 下图显示 NVA1 在与远程 ARS (ARS1) 的 BGP 对等时为 Spoke1 和 Spoke2 的 supernet 前缀设置 AS-Prepend，NVA2 在广告 Spoke3 和 Spoke4 前缀到 ARS1 时同样适用。 **NVAs 向远程 ARSs 的 AS-Prepend 以实现最佳路由** **最终流量流:** **全检查: NVA 在 Transit-VNet 中的流量流** **见解:** - 此解决方案适合需要全流量检查的情况。 - 与 **场景 1 - 选项 A** 不同，它消除了 GatewaySubnet 中的 UDRs 需求。 - 当 ARS 部署在 VNet 中 (通常在 Hub VNets 中) 时，该 VNet 将限于 [500 个 VNet 对等](<https://learn.microsoft.com/en-us/azure/route-server/route-server-faq#what-are-azure-route-server-limits>) (撰写本文时)。然而，在此设计中，Spokes 与 Transit-VNet 对等，而不是直接与 ARS VNet 对等，从而通过 [Azure 虚拟网络管理器 (AVNM)](<https://learn.microsoft.com/en-us/azure/virtual-network-manager/overview>) 或提交支持请求来扩展超过 500 个对等的限制。 - 一些企业客户可能遇到 ExpressRoute 电路从 ExpressRoute 网关的 1,000 路由广告限制。在传统 Hub-和-Spoke 设计中，没有原生控制广告内容。通过此架构，NVAs 为路由广告到电路提供更大控制。 - 为简化起见，我们在本文中解释设置和流量流时使用了每个 Hub-VNet 中的单个 NVA。然而，推荐使用 **高可用 (HA)** NVA 部署。要在 HA 设置中保持流量对称性，需要在与 Azure 路由服务器 (ARS) 对等时启用 [下一跳 IP 功能](<https://learn.microsoft.com/en-us/azure/route-server/next-hop-ip>)。 - 此设计确实需要额外的 VNet 对等，包括： - Transit-VNets 之间 (跨区域)， - Transit-VNets 与本地 Spokes 之间，以及 - Transit-VNets 与本地和远程 Hub-VNets 之间。 更新于 2025 年 7 月 18 日 版本 2.0 <!-- AI_TASK_END: AI全文翻译 -->