一文看懂SR-MPLS Option C终极形态下的RR流量劫持大法

在上次实验中（告别Full-Mesh噩梦！实战SR-MPLS跨域Option C + RR进阶架构），我们探索了Option C架构中最经典的控制与数据解耦模式。在这种模式下，RR就像一个纯粹的信使，只负责在两端PE设备之间传递控制面的路由信息，而真正的私网数据流量，则完全绕过RR设备，在底层网络中实现端到端的直飞。

这种架构的优点显而易见：数据面效率极高，RR的性能压力极小。

这就不禁让人发问：既然Option C的精髓就是控制与转发解耦，而RR设备通常只是一台性能较弱的纯控制面设备，甚至是一台虚拟机vRR，让海量的数据流去冲击RR，岂不是自寻死路？

确实，在传统的Option C模型中（路由黑科技！如何让两个SR孤岛，无感跨越传统LDP核心网？），绝对不建议让RR参与数据转发。但随着网络规模进入到类似5G承载网、全国级骨干网的超大型网络，传统的直飞暴露出了一个致命缺陷：端到端LSP隧道爆炸。

试想一下，如果全网有10000台PE设备，在标准Option C架构下，核心网的P设备和ASBR设备必须维护去往这10000台PE的底层BGP-LU标签。这会瞬间打爆底层设备的FIB表！

为了拯救底层设备那可怜的FIB表，业界引入了无缝MPLS（Seamless MPLS）架构。在这种终极架构下，我们不再追求端到端的一镜到底，而是通过RR设备对BGP下一跳进行改写，将一条贯穿全国的长隧道，分段切割成PE到RR、RR到远端RR的两段短隧道。这样，边缘PE设备只需要维护去往本区域RR设备的隧道，彻底解决了海量LSP带来的网络扩展性瓶颈。

为了应对这些高级需求，我们需要打破控制与数据解耦的局面，强制把RR设备拉下水，参与到实际的数据转发中来。这正是我们今天要探讨的第三种Option C结构，强制流量牵引架构。

我们依旧使用11台VSR8808-X设备搭建的SR-MPLS骨干网来进行实验，如下所示：

各设备之间的完整接口互联表信息如下：

本次实验，我们主要聚焦于PE1、PE2、PE3、P1、P4、P5这6台设备。其中，PE1设备、P4设备和P5设备位于AS区域65001，PE2设备、PE3设备和P1设备位于AS区域65002，PE1设备和PE3设备是PE角色，由P1设备和P5设备背靠背打通两个SR区域，而P4设备和PE2设备则是我们今天的焦点。

本实验与上个实验的差异甚小，所以我们直接基于上个实验进行配置。当然，我们也可以使用我们的ZTP系统恢复设备的配置快照（众里寻他千百度，最好用的网络实验ZTP系统，我竟然自己写了一个！），省时省力。

如何才能让一台本不该参与数据转发的RR设备，强制变成流量的必经之路呢？答案藏在BGP的一个核心属性中：Next-Hop下一跳。

在上次实验中，我们小心翼翼地配置了next-hop-invariable，生怕RR设备去篡改下一跳。而在此次实验中，我们要反其道而行之，将配置调整为next-hop-local。这样，RR在向客户端PE1设备以及远端RR设备PE2发送VPNv4路由时，就会强行抹去原始签名，将Next-Hop改写为自己的环回口地址。

而一旦Next-Hop变成了RR自己，就会引发不可逆转的蝴蝶效应，以P4设备为例：

1、控制面重构。边缘PE1设备收到路由后，会认为对端的目的地址就在本地的RR设备P4节点身上。

2、标签面重构。由于P4设备宣布自己是下一跳，它就不能再当甩手掌柜了，它必须为这条跨域的VPN路由重新生成并分配一个全新的内层VPN标签。

3、数据面重构。PE1设备发送的数据包，其外层隧道直接指向P4设备，内层标签使用的是P4设备分配的标签。数据流量到达P4设备后，P4设备必须剥离外层隧道标签，查看自己分配的内层VPN标签，然后重新封装，换上发往远端的新标签。

就这样，P4设备彻底沦为了数据转发的中转站，或者可以看成是退化成了一个类似Option B架构中的跨域ASBR角色（SR-MPLS跨域Option B架构全景实战）。

理论听起来非常宏大，但反映在设备上的配置变更，仅仅只有寥寥两行代码。以P4设备为例，我们只需要在VPNv4视图下，删掉原来的next-hop-invariable策略，并追加一条next-hop-local命令即可。这样一来，P4设备在向对BGP邻居宣告路由时，就将下一跳改为自己了。调整后的P4设备配置如下：

#
bgp 65001
#
address-family vpnv4
peer 1.0.2.1 next-hop-local
peer 1.0.2.2 next-hop-local
别看我们仅仅改动了这两行配置，整个骨干网的转发行为就发生了翻天覆地的变化。

首先，我们在PE1设备上查看去往PE3设备私网的路由情况：

display bgp routing-table vpnv4

对比上个实验，这里的NextHop就从远在天边的对端PE3设备，变成了本地的RR设备P4！这就意味着，在PE1设备看来，所有的跨域私网数据，都交由P4设备处理就大功告成了。

既然下一跳变成了P4设备，PE1设备的底层外层隧道也会直接指向P4设备。

display mpls lsp
display mpls tunnel all

注意看，PE1设备发现去往目标的下一跳是本域的RR设备，于是它在封装报文时，外层会压入去往P4设备的底层SR隧道标签16014；而内层标签，使用的则是P4设备亲自为该VPN路由重新分配的全新私网标签600127。原本端到端的贯通LSP隧道，在P4设备这里被硬生生截断了。

除此之外，我们再检查一下ISIS的全局标签段SRGB的分配情况。

display isis segment-routing global-block

还有ISIS的SR邻接段信息：

display isis segment-routing adjacency

我们清晰地看到，整个ISIS域内的SRGB基值成功统一为16000。PE1设备、P4设备和P5设备均在同一个全局空间中分配标签，这就解释了为什么去往P4设备的底层隧道标签天然就是16014。

基础设施的SR化已经完美生效，构成了跨域隧道最坚实的基石。

接下来，我们再到ASBR设备P5上，检查一下BGP-LU对跨越AS边界的环回口是如何分配标签的。

display bgp routing-table ipv4 unicast inlabel

由于我们配置了`route-policy OPC apply mpls-label，P5设备成功为远端RR设备PE2分配了入标签600125，同时记录了发往对端ASBR时的出标签600126。就是这些标签，接力打通了RR设备之间的端到端BGP LSP隧道。

最后，回到PE1设备，我们再看看去往远端私网的详细BGP VPNv4信息，揪出那个关键的内层VPN标签。

display bgp routing-table vpnv4 10.1.33.0 24

可以看到，Original nexthop被改写为了1.0.1.4，也就是RR设备P4，并且RR设备强制分配了一个全新的内层VPN标签OutLabel: 600124。这意味着，PE1设备在转发时，将以此标签作为内层封装。

那回过头来看，隧道被截断到底意味着什么？我们直接用tracert命令来看看私网数据包在跨越骨干网时的真实跳数：

ping -vpn-instance vpna -a 10.1.11.1 10.1.33.1
tracert -vpn-instance vpna -a 10.1.11.1 10.1.33.1

虽然看上去跟上个实验的抓发路径是一样的，这是因为我们开启了mpls ttl propagate vpn，此时无论怎么走都会老老实实显示所有节点。

要想识破伪装，咱们直接通过抓包来看一下。

注意看报文中的标签栈，外层标签为600127，说明这是PE1设备去往下一跳P4设备的公网隧道标签。而内层VPN标签位600124，同事S=1，说明它已处于栈底。结合我们我们在PE1设备上查出来的结果，那个由P4设备强行派发给PE1设备的OutLabel正是600124！

这就说明PE1设备发出数据包的瞬间，完全被P4设备给支配了！它老老实实地打上了P4设备发放的中转门票600124，而没有像上个实验那样，使用对端PE3设备原始的标签。这就是数据流被强制牵引、RR设备沦为数据中转站的绝对物理铁证。

此时此刻，P4设备和PE2设备已经不再是单纯的控制面信使，它们实质上退化成了类似于Option B架构中的跨域ASBR角色，完全参与了数据平面的生死转发！

至此，有关Option C架构的三种核心落地形态我们就研究完了，用一张表来做个总结：

网络架构从来没有一招鲜、吃遍天的绝对银弹，只有结合具体的业务痛点、安全诉求和设备预算，灵活运用这些底层特性的排列组合，才是高级网络架构师的核心壁垒。

从最初的端到端直飞，到今天通过Seamless MPLS强制牵引化解FIB爆炸危机，咱们用实战抓包一层层剥开了SR-MPLS Option C终极形态的面纱。技术的魅力就在于此，你以为修改的只是一行简单的next-hop-local，殊不知在底层已经引发了一场惊天动地的标签重构风暴！