从 MPLS 到 SR，为什么网络越来越臃肿？！

Segment Routing (SR) 的初衷在于简化多协议标签交换 (MPLS) 并赋予网络运营商更大的自主权。然而，遗憾的是，一些供应商却选择通过推销复杂的协议和过度设计的臃肿控制器软件，增加了实施的难度。

MPLS 无疑是一项出色的技术。尽管 SD-WAN 等新兴技术试图与 MPLS 竞争市场份额，但作为传输技术，MPLS 至今尚无真正的替代品。MPLS 的优势包括：

• 低开销服务底层，只有PE路由器需要为 L3VPN 传输的完整 Internet 表和虚拟路由转发 (VRF)。
• 流量工程可以在任何网络拓扑中均匀分配流量负载，为特定服务提供低延迟路径，为 A/B 馈送提供不相交路径等。
• 快速重路由机制能在链路或节点故障后实现低于 50 毫秒的收敛。

然而，在 MPLS 的不断演进过程中，其复杂性也日益增加。接下来，我们将探讨这一现象背后的原因。

传统 MPLS 堆栈

通常情况下，MPLS 网络会运行 IS-IS 或 OSPF 进行 IP 路由，标签分发协议 (LDP) 或资源预留协议 (RSVP) 进行标签分发，以及边界网关协议 (BGP) 及其多个地址系列进行 MPLS 服务。

图 1 — 传统 MPLS 概述

这种传统的MPLS堆栈存在三个问题： 操作复杂性、协议限制和互操作性 。

操作复杂性

LDP 配置和操作很简单，但不支持流量工程，并且对使用远程 LFA 的快速重路由的支持有限。RSVP 支持流量工程，但需要 P2P 隧道网格，限制了可扩展性。在实际部署的时候，LDP 和 RSVP经常结合使用。每个 PoP 内使用 LDP，连接不同 PoP 的 WAN 链路上使用 RSVP，并通过 RSVP 链路进行有针对性的 LDP 会话。这进一步增加了复杂性，类似于图 2。

图 2 — 目标 LDP 拓扑示例

协议限制

• 较差的 ECMP 支持：RSVP 不支持等价多路径 (ECMP)。LDP 支持，但可能会遇到限制。ECMP和Spine/Leaf设计在现代网络中非常常见。
• LDP-IGP 同步：虽然其目的是防止在重新收敛期间出现流量黑洞，但很容易弄巧成拙，造成内部网关协议 (IGP) 会话卡住且永远无法启动的情况。
• 使用 RSVP 的流量工程是不确定的：由于每个路由器都独立于其他路由器发送其 LSP 信号，因此路由的最终状态取决于事件的顺序，并且每次网络重新收敛时都会有所不同。
• RSVP 的可扩展性差：独立的 LSP 信令并不意味着更好的可扩展性。相反，每个路由器都必须为经过它的所有中转 LSP 维护一个状态，因此 RSVP 的可扩展性不佳。

互操作性问题

由于我们要处理至少三种协议及其许多扩展的堆栈，因此使用来自不同供应商的硬件构建 MPLS 网络会变得非常麻烦：

• 并非所有实现都支持所有功能和扩展。对于传统 MPLS 架构，这通常意味着如果一台路由器不支持某个功能，就无法再使用它。
• 不同的供应商有时对 RFC 的解释不同，因此尽管他们都声称支持某种标准，但是真将他们的硬件连接在一起时又无法工作。

实际上，所有这些问题的存在意味着，构建传统的MPLS网络，唯一可行的途径便是从某一大型供应商处采购全部路由器，并严格遵循其成熟的设计方案。然而，这种做法往往会带来供应商锁定的风险，并且也让众多无力承担高昂网络硬件成本的小型网络无法访问MPLS。

什么是Segment Routing

SR 摒弃了所有冗余的标签分发机制，并在IS-IS和OSPF中添加了一些扩展，用于发布链路和前缀的SID （Segment ID），不再有“标签交换”。入口 LER 仅需在数据包上附加出口LER的SID，所有中转 LSR 都不会更改该标签（至少在理论上如此，实际实现仍会用相同的标签交换标签）。

由于 SR 基于 IP，没有像 RSVP 那样的电路交换，因此它本身支持等价多路径 (ECMP) 和任播，拥有极佳的扩展性。

利用 SR 进行流量工程

与 RSVP 不同，SR 不会发送 LSP 信号，而只是添加多个 SID 以沿着流量工程路径转发数据包。

图 3 — 基本 SR 流量工程 (SR-TE) 拓扑的示例

在图 3 所示的拓扑中，为了通过蓝色链路将数据包从 R1 转发到 R6，R1 推送三个标签：

• R3 的节点 SID ->使用最短路径将数据包转发到 R3。
• R3 至 R5 的邻接 SID (Adj-SID) -> 使用该特定链路。
• R6 的节点 SID ->将数据包传送到实际目的地（R6）。

这里有一个问题：由于 SR 是无状态的，其流量工程的实现依赖于控制器，没有控制器就不可能使用带宽预留。虽然可以仅使用关联或显式路径执行约束最短路径优先 (CSPF)，但这种替代方案也会因需要路由器具备额外的功能而变得复杂，增加了部署的难度。

降低进入 MPLS 的门槛

由于SR-TE 策略计算交给了控制器，因此路由器上的 SR 实现变得非常简单：

1.IGP 扩展用于通告SRGB、SRLB、前缀和 Adj-SID（仅一些新的类型长度值 (TLV)）。

2.BGP-LS 将链路状态拓扑通告给 SR 控制器。

3.BGP-SRTE 或 PCEP 从控制器接收 SR-TE 策略。

实际上(2)和(3)是可选的，其他特性如拓扑独立无环路替代（TI-LFA）、Flex算法等也是可选的。实现SR的最基本要求就是添加几个新的 IS-IS TLV，仅此而已。然后就可以使用另一个厂商的路由器将IGP拓扑导出到BGP-LS。至于那些不支持BGP段路由传输（BGP-SRTE）或路径计算元素通信协议（PCEP）的路由器，传统的BGP标签分发（BGP-LU）提供了一个有效的解决方案，用以接收和实施路由策略。

基本的 SR 路由器可以由企业或开源项目构建。因此，网络运营商可以选择更广泛的硬件，也可以使用FRR和VPP等开源软件自行构建。

更简单的互操作性

与传统MPLS堆栈相比，SR的互操作性问题风险显著降低。由于省去了RSVP信令及LDP-IGP同步的复杂性，互操作性问题几乎仅限于IGP层面（例如，计时器设置不同或TLV格式差异），而这些问题在传统LDP/RSVP配置中同样可能出现。

唯一稍显不便之处或许在于SRGB的使用上，不同供应商倾向于采用不同的默认范围。但值得庆幸的是，这一设置在用户需要时是可以进行调整的。

此外，SR还具备实现混合部署的优势——核心网络可以采用大型供应商的硬件以确保性能与稳定性，而在聚合层和接入层则可选择成本更低的硬件，从而在保证网络质量的同时优化成本。

SR 存在什么问题

虽然SR最初是由思科提出的，但它已发展成为一种开放标准，允许任何人部署。如前所述，实现基本的SR其实相当简便，并且已有多种方式能在一定程度上提供支持。

然而，对于大型供应商而言，推广人人皆可复制的简单网络设计显然是不能够接受的。因此，他们推出了所谓的“最佳实践”设计，通过引入路径计算元素协议（PCEP）及其众多扩展，以及设计复杂的控制器来进行流量工程，从而使用户对其SR实现产生依赖。

SR-TE控制器本质上就是一台增添了某些额外功能的路由器，例如处理BGP-LS信息以及运用CSPF算法来计算策略。理论上，它应该比传统的MPLS-TE实施更为简洁，因为无需进行LSP的信令操作。

但实际的控制器却绑定了一些庞大且复杂的软件，它们的功能繁多，包括网络监控、自动化、NetFlow数据收集以及OSS/BSS（运营支撑系统/业务支撑系统）等等，运行起来甚至需要高性能的计算机支持。尽管这些功能确有其优势，但又十分复杂且冗余，这不禁让人质疑：到底是谁要求在路由平台上集成这些功能的呢？

这种过度设计的真正原因在于：

• 厂商锁定：由于实施 SR 比RSVP 容易得多，因此供应商将目标转移到控制器上。
• 销售服务：如果控制器的部署和操作非常困难，那么网络运营商将不得不从供应商那里购买配套的服务。

第二点颇具讽刺意味。倘若产品设计得过于繁复，以至于网络运营商难以部署和操作，那么对于供应商的工程师而言，复杂性是同等的。据悉，某些供应商推出的SR-TE控制器过于复杂，甚至连负责撰写关于SR-TE书籍的自家工程师都无法在实验室顺利安装它。

SR的发明者建议应尽可能采用IGP最短路径路由，同时，针对需要通过不同路径转发的流量部署一些SR-TE策略。当然，这并非总是可行，但无论如何，当SR-TE控制器发生故障时，常规的IGP路由（结合SR扩展）应作为网络可以稳定回退的基准。

然而，尽管有这样的常识性建议，仍有人设计出了极端方案，连基本的端到端连接都完全依赖于SR-TE控制器，似乎这样做就能让网络更加“软件定义”和“可编程”。但实际上这样的设计并没有比在正常IGP路由之上部署控制器更“可编程”。唯一的区别是，一旦控制器出现故障，就会导致灾难性的网络中断，而良好的SR设计本应避免这种情况。

构建真正用户友好的 SR-TE 控制器

考虑到以上所有因素，好的 SR-TE 控制器应该是：

• 纯路由平台。收集路由信息并计算策略 — 仅此而已。提供用于自动化的 API 和用于故障排除的 CLI，但不要试图将所有网络管理平台合并为一个。
• 易于部署、配置和操作。行业标准 CLI 一直适用于路由器和交换机，没有理由它不适用于 SR 控制器。有些人不喜欢 CLI，但实际上，没有良好 CLI 的网络产品是无法使用的。

图 4 — SR-TE 控制器属于控制平面，将控制器变成管理平台是一个错误

• 支持基础路由器：尽管支持多种功能是一个亮点，但控制器理应能够与那些不具备PCEP、按需Nexthop（ODN）及其他复杂特性的简化SR实现协同工作。它仅需依赖IGP和BGP-LU的SR扩展来部署策略，而这一点已是业界普遍支持的基础功能。
• 轻量级基础设置：将控制器部署为在路由器上直接运行的 Docker 容器非常方便，从而省去了在远程数据中心维护额外服务器、搭建冗余连接等繁琐步骤。
• 原生支持 SR 设计：在策略制定中，应充分利用ECMP和任播SID、出口对等工程（EPE）、空端点等SR原生特性。仅仅从传统MPLS-TE中借鉴CSPF算法并以SR取代RSVP是远远不够的，一个合格的SR控制器必须原生运用SR的各项功能。

结合典型的Spine-Leaf拓扑来看：

图 5——典型的Spine-Leaf拓扑示例

通常情况下，从L1到L6的流量会经由所有主干采用ECMP进行传输。如前文所述，相较于LDP，SR在此拓扑中已经展现出多项优势，特别是在扩展性方面。

现在，若出于流量工程的考量，我们期望从L1到L6的流量严格通过S1和S2进行传输，可通过以下两种方法实现：1）使用link affinities链接关系，2）使用显式路径。

若我们在S1和S2上配置了带有任播IP的环回接口，并将此IP作为显式路径的松散跳点，控制器应能解析出经由这两个路由器的路径，并应用ECMP。这一功能在RSVP中是无法实现的。

接下来，关于此策略中的分段列表设计，我们应如何规划？若使用两个分段列表： 和 ，将在硬件中占用更多的转发等价类（FEC）条目。若S1和S2共享一个任播SID，控制器应识别这一点，并在分段列表中运用该任播SID以优化资源使用。

出口对等工程（EPE）

EPE是入口路由器将流量定向至特定出口路由器的指定出口对等体的一种机制。出口路由器需为每个出口对等体分配一个MPLS标签（如BGP Peer SID或BGP-LU），并向控制器宣告这些标签，以便控制器能够制定策略，指示入口路由器如何转发流量。

图 6 - 出口对等工程拓扑的基本示例

将SR与EPE集成相当简便，只需在策略中添加相应的EPE标签即可。

EPE 限制

目前尚没有RFC文档支持使用BGP Peer SID来通告TE扩展，类似于IGP的RFC 3630、RFC 5305和RFC 5329。因此，我们只需在控制器上配置约束条件，这些条件将与从出口路由器接收到的BGP Peer SID相关联。

Null端点

可以使用Null端点（即0.0.0.0或::）进行配置。当需要将流量发送到符合约束条件的最近出口对等点时，这种配置非常合适。在网络设计中，这通常被称为热土豆路由。

可变终点

SR-TE 策略也可以从常规（节点）端点更改为出口对等端点。

图 7 — 跨两个站点的可变端点的示例

以图7的拓扑为例，站点1和站点2都将各自的前缀通告给互联网，但它们之间的首选通信方式是通过暗光纤链路。如果某条链路发生故障，而剩余链路的带宽不足以承载所有流量，则可以将SR-TE策略重新路由到Null端点。

自动转向

自动转向 (AS) 是一种将服务路由 (IP 或 VPN 前缀) 映射到 SR-TE 策略的有效方法。

如果路由器不支持BGP SR-TE或PCEP怎么办？前面已经提到，一个好的控制器应该能够利用最基本的SR实现。虽然我们可以使用BGP-LU从控制器发布策略，但这样做无法将不同的服务映射到不同的策略上。不过，实际上有一个解决方案：

1.配置一个不在 IGP 中通告的单独环回。

2.在 BGP-LU 中以低 LOCAL_PREF 通告此环回。

3.将服务路由的下一跳更改为此环回。

4.当 SR-TE 控制器使用 BGP-LU 发送 SR-TE 策略时，它会通告此“服务环回”而不是实际的策略端点。

这几乎和AS一样好用，只需要多一点配置，但考虑到这是使用成本较低的路由器所付出的代价，这样的配置还是相当值得的。

小结

一些网络之所以选择使用VXLAN来进行L3连接，往往是因为它们在当时找到了成本更低的支持VXLAN的交换机。至少，在理论层面是这样的。而在实际操作中，可能仍然只是在进行简单的标签交换。

这些设计的理念源自RFC 8604，它提出了一种假设性的概念，即利用SR技术可以构建出路由器数量远超20位MPLS标签空间所能承载的网络。然而，在实际的互联网服务提供商（ISP）网络设计中，这一概念并无实际意义，因为ISP网络通常包含数百甚至数千台路由器。诚然，在这种拓扑结构中，主干SID往往并不会被推送到线路上，它仅用于确定下一跳的解析。而在更为复杂的拓扑结构中，任播SID的重要性愈发凸显。

*本文作者为Dmytro Shypovalov，是Vegvísir Systems的创始人，拥有网络架构师背景。

原文链接：

https://blog.apnic.net/2024/12/06/making-segment-routing-user-friendly/

---

【投稿】： SDNLAB原创文章奖励计划