园区网双核心的项目做多了以后，你会发现 VRRP+MSTP 这套组合几乎是躲不开的：VRRP 负责网关冗余，MSTP 负责二层环路消除和链路负载分担。但真正把这两个协议放在一起跑业务，问题就藏在它们各自的状态机里——VRRP 切主靠的是报文超时和接口状态感知，MSTP 收敛靠的是 BPDU 交换和拓扑变更通知，两者对“故障”的感知路径完全不同。于是经常出现“网关已经切到备用核心，二层流量却还在往旧主核心送”或者“根桥位置和 VRRP 主备错位，回程流量绕一大圈”的尴尬局面。
这篇文章记录的是一套在华为 VRP 系统设备上完成的 VRRP+MSTP 联动接口检测实验。重点不是教你怎么机械地敲命令，而是把接口检测为什么能成为这两个协议之间的“粘合剂”讲清楚。实验会搭一套典型双核心拓扑，配置好 MSTP 多实例和 VRRP 负载分担，再叠加 BFD for VRRP 和 Monitor Link 两种接口检测联动方案，最后通过故障模拟看实际切换效果。适合刚接触园区网冗余设计的人，也适合那些已经配过 VRRP 和 MSTP、但总觉得切换不理想、想搞清楚底层逻辑的同行。
1. VRRP+MSTP组合为什么需要联动接口检测
1.1 双核心网络里的经典组合
先还原一个最常见的双核心场景。两台核心交换机跑 VRRP，给下面的终端提供一个虚拟网关；终端把默认网关指向虚拟 IP，不管哪台核心出问题，网关都能由另一台顶上。这里 VRRP 解决的是“三层网关冗余”的问题，收敛速度取决于 VRRP 报文的超时时间，默认情况下 backup 设备要等大约 3 个通告周期才能确认 master 故障，通常是秒级。
二层这边，接入交换机需要双上行到两台核心，否则单点故障会直接断网。但双上行就意味着物理环路，必须靠生成树协议来阻断冗余路径。普通的 STP 收敛太慢，RSTP 收敛快了却只有一个实例，没法按 VLAN 分担流量。于是 MSTP 成了主流选择，因为它可以把不同 VLAN 映射到不同实例，让一部分 VLAN 走 Core1 方向，另一部分 VLAN 走 Core2 方向，充分利用两条上行链路。
这里就出现了一个容易被忽略的关键点：VRRP 的主备状态和 MSTP 的根桥位置必须匹配。换句话说，VLAN 10 的 VRRP 主设备是 Core1，那么 VLAN 10 所属的 MSTP 实例根桥也应该是 Core1。如果两者错位，接入交换机在二层会优先把流量送到根桥，根桥再把流量跨核心送到真正持有网关的那台设备上，数据路径凭空多绕一跳，时延和故障点都增加了。
1.2 不联动的切换缺陷
假如没有了接口检测联动，只靠 VRRP 和 MSTP 默认机制，故障切换会是什么样？
最常见的一个坑：Core1 的上联出口链路断了，但 Core1 本身没有宕机，VRRP 报文还能照常发。此时 Core1 依然是 VRRP 的 master，终端流量照常进 Core1，但 Core1 已经失去了出口能力，业务实际上已经中断。这就是典型的“哑网关”问题。VRRP 默认只感知对端设备是否存活，并不关心这台设备的“上游”是否健康。
再看二层。假设 Core1 整体宕机，VRRP 检测到 master 消失，Core2 升为主网关。但 MSTP 的收敛是独立的，它要通过 BPDU 超时、拓扑变更通知、端口状态迁移等过程重新计算生成树。这个过程可能长达几秒甚至更久。在网关已经切到 Core2、二层拓扑还没收敛完成的那段时间里，终端的流量要么找不到转发路径，要么还在往已经宕机的 Core1 上送，结果就是大量丢包。
更隐蔽的问题出在环网收敛方向。如果只有 VRRP 切换而没有把 Core1 从二层拓扑里“摘掉”，MSTP 的根桥依然可能是 Core1，接入交换机在生成树计算中仍然把根端口指向 Core1，流量被送到一台已经没有出口能力的核心上，再通过核心互联绕回 Core2。表面上 VRRP 切换成功了，实际转发路径是错的。这就不只是丢包的问题，而是整个路径设计失效。
1.3 接口检测联动要解决的三类问题
所以接口检测联动在这个组合里，本质上是做三件事。
第一件事，让 VRRP 能感知“上游链路”的故障。通过 BFD 或 VRRP track 接口，把上联口的状态变化实时反馈给 VRRP 状态机，让 master 设备在上联故障后主动降低优先级，从而触发抢占，把网关切到备用核心。这解决的是哑网关问题。
第二件事，把核心设备的故障状态传导到二层拓扑。利用 Monitor Link，把上联口和下联口绑定成一个联动组，上联故障后自动关闭下联口。这样接入交换机就会感知到某台核心方向已经不可用，MSTP 重新计算生成树，把转发路径切到另一台核心，从而保证三层网关切换和二层拓扑收敛是同步的。
第三件事，让 VRRP 主备和 MSTP 根桥保持一致性。要么在规划设计阶段就绑定好映射关系，要么在故障场景里通过联动机制强制让根桥跟着主网关走。这个一致性是双核心网络低时延、无绕行转发的前提。
2. 实验拓扑与整体设计思路
2.1 拓扑结构和VLAN规划
为了把问题讲清楚，实验做了一个简化的双核心园区网络模型。两台核心交换机 Core1 和 Core2 作为所有业务 VLAN 的网关，下面接了两台接入交换机 SW1、SW2，每台接入交换机都双上行到两台核心。Core1 和 Core2 之间用两条物理链路做 Eth-Trunk 捆绑互联，保证核心间带宽和心跳链路可靠性。核心再各自上联一台出口设备，模拟互联网出口或上层骨干网。
业务上规划两个 VLAN，分别跑两组不同的业务网段。VLAN 10 是 192.168.10.0/24，虚拟网关 192.168.10.254；VLAN 20 是 192.168.20.0/24，虚拟网关 192.168.20.254。核心之间和核心到接入之间的互联链路都配置为 Trunk，放行这两个业务 VLAN。具体规划可以整理成下面的表：
| 项目 | VLAN 10 | VLAN 20 |
|---|---|---|
| 业务网段 | 192.168.10.0/24 | 192.168.20.0/24 |
| 虚拟网关 | 192.168.10.254 | 192.168.20.254 |
| VRRP 组 | VRID 1 | VRID 2 |
| MSTP 实例 | instance 1 | instance 2 |
| 正常情况下主设备 | Core1 | Core2 |
| 正常情况下根桥 | Core1 | Core2 |
VLAN 10 的主网关放在 Core1，VLAN 20 的主网关放在 Core2，这样两个核心都能承担转发任务，不会出现一台设备闲着、另一台忙死的情况。对应的 MSTP 实例也做了同样的划分：instance 1 映射 VLAN 10，根桥是 Core1；instance 2 映射 VLAN 20，根桥是 Core2。这就是“主备错开、流量分担”的设计思路。
2.2 MSTP多实例与VRRP的耦合设计
MSTP 配置的关键是 region（区域）和 instance（实例）。同一区域内的交换机必须有一致的 region name、修订版本号和 VLAN 与实例的映射关系，否则跨设备的生成树计算就会出问题。实验里所有交换机都规划在同一个 region 下，命名为 RegionA，然后把 VLAN 10 映射到 instance 1，VLAN 20 映射到 instance 2。区域配置不一致，MSTP 会把设备当作不同区域来处理，BPDU 交互会出现异常，这是实验里最容易翻车的地方。
根桥设置上，Core1 执行stp instance 1 root primary，把自身指定为 instance 1 的根桥，同时执行stp instance 2 root secondary，作为 instance 2 的备份根桥；Core2 则反过来。这么做的好处是，正常情况下 VLAN 10 的二层路径以 Core1 为中心，VLAN 20 以 Core2 为中心，两条上行链路都能用起来，带宽利用率翻倍。
VRRP 这边也是同样的逻辑。Core1 在 VLANIF 10 的 VRRP 组里配置较高优先级，比如 120，让它在正常情况下成为 master；在 VLAN 20 里配置默认优先级 100，把 master 位置让给 Core2。两台核心的心跳报文走核心间 Eth-Trunk 链路，保证两端状态同步。这样整个网络在正常状态下的路径就是最优的：接入交换机按照生成树把流量送到对应实例的根桥，而根桥恰好就是这台 VLAN 的 VRRP master，流量不需要跨核心绕行。
2.3 核心互联用Eth-Trunk的必要性
核心之间的互联链路是整个设计的命脉。如果只用一根物理线，一旦这条线断了，VRRP 报文就断了，两台核心可能同时认为自己是 master，出现“双主”现象。虽然 MSTP 也会重新收敛，但双主状态下网关冲突、MAC 地址漂移、广播风暴等问题会接踵而来。
实验里把两条物理口捆绑成 Eth-Trunk，从 VRRP 和 MSTP 的视角看就是一条逻辑链路。任意一条成员口故障，逻辑链路仍然存活，不会触发 VRRP 心跳中断。同时两条链路也为核心间流量提供了带宽冗余，实际项目里如果预算允许，我一般建议核心互联用两条万兆口做捆绑，或者至少保证有一条带外心跳链路，避免 Eth-Trunk 整体故障时出现无法仲裁的局面。
3. 基础配置：先把VRRP和MSTP跑起来
3.1 MSTP区域与实例配置
基础配置要从每台交换机的 MSTP 区域开始。在 Core1、Core2、SW1、SW2 四台设备上，区域配置必须完全一致：
stp mode mstp stp region-configuration region-name RegionA instance 1 vlan 10 instance 2 vlan 20 active region-configuration四台设备都进入 MSTP 模式后，再分别指定根桥优先级。Core1 上的配置是：
stp instance 1 root primary stp instance 2 root secondaryCore2 上的配置正好反过来：
stp instance 1 root secondary stp instance 2 root primary如果你的设备版本不支持root primary这种快捷命令，也可以用优先级手动指定，MSTP 根桥优先级取值为 4096 的倍数，root primary会自动把对应实例的优先级置为 0，root secondary置为 4096。手动配置时写成stp instance 1 priority 0和stp instance 1 priority 4096效果是一样的。这里要注意，优先级相同的两台设备会按照 MAC 地址比较，小的优先，结果不可控，所以必须显式拉开差距。
接入交换机 SW1、SW2 不需要配置根桥，它们只需要保持相同的 region 和实例映射就行。如果没有这台设备对应的接入角色配置，接入交换机可能会因为收到 BPDU 后按默认优先级计算，导致根桥不再是 Core1 或 Core2，整个实验的路径设计就全乱了。接入交换机上同样执行第一段区域配置命令即可。
3.2 VRRP主备与负载均衡配置
MSTP 跑通之后，接着配置 VRRP。Core1 的 VLANIF 接口配置如下：
interface Vlanif10 ip address 192.168.10.253 255.255.255.0 vrrp vrid 1 virtual-ip 192.168.10.254 vrrp vrid 1 priority 120 vrrp vrid 1 preempt-mode timer delay 5 interface Vlanif20 ip address 192.168.20.253 255.255.255.0 vrrp vrid 2 virtual-ip 192.168.20.254 vrrp vrid 2 priority 100 vrrp vrid 2 preempt-mode timer delay 5Core2 上则是 VLANIF 10 配优先级 100，VLANIF 20 配优先级 120。接口的物理 IP 我习惯用 .253，虚拟网关用 .254，这样终端默认网关就是虚拟 IP，而物理 IP 只用于设备管理和 VRRP 报文源地址。如果你把接口 IP 直接配置成虚拟 IP，也不是不行，但会对后续抓包、排障造成一些不必要的混淆，不建议新手这么玩。
preempt-mode timer delay这个参数很多人会忽略，它的作用是设置抢占延迟。上联故障恢复后，原 master 不会立刻抢回主角色，而是等 5 秒再切换。这个延迟可以避免链路抖动或 BFD 误报导致的反复横跳，尤其是当网络里还有 MSTP 在收敛时，延迟抢占能明显减少业务扰动。
3.3 接入交换机的STP保护配置
接入交换机直接连终端的口必须配置边缘端口，否则终端开机、重启、插拔网线时产生的 BPDU 会参与生成树计算，引起不必要的拓扑变更。配置方法是进入接口视图：
interface GigabitEthernet0/0/1 stp edged-port enable同时在系统视图下开启 BPDU 保护：
stp bpdu-protection这样边缘端口一旦收到 BPDU，交换机会直接 error-down 该端口，而不是让它参与生成树计算。这个配置在实验里看着不起眼，实际项目中如果没有它，终端侧一个简单的环路或者非法交换机接入，就能把整台核心的生成树搅乱。
另外，在核心互联口和接入交换机上联口上，建议启用根桥保护stp root-protection。根桥保护的作用是，如果某个端口收到了优先级更高的 BPDU，这个端口会进入 Discarding 状态而不是接受新根桥，防止非法设备或错误配置导致根桥被抢占。配置方法是进入对应互联接口视图后执行stp root-protection。
4. 接口检测联动配置：三种实战做法
4.1 做法一：BFD for VRRP检测上联故障
BFD 是目前最常用的快速检测机制，它可以在毫秒级发现链路故障。实验里 Core1 的上联口连接出口设备，假设互联网段是 192.168.100.0/30，Core1 侧地址是 192.168.100.1，对端是 192.168.100.2。Core1 上配置 BFD 会话：
bfd bfd 1 bind peer-ip 192.168.100.2 source-ip 192.168.100.1 discriminator local 10 discriminator remote 20 min-tx-interval 100 min-rx-interval 100 detect-multiplier 3 commit然后在 VRRP 组里引用这个 BFD 会话：
interface Vlanif10 vrrp vrid 1 track bfd-session 1 reduced 40这样配置的效果是：正常情况下 Core1 的 VRRP 优先级是 120；一旦 BFD 检测到上联链路故障，会话状态变为 Down，VRRP 优先级自动减去 40，变成 80。而 Core2 在 VLAN 10 的优先级是 100，它发现对端优先级比自己低，就会抢占成为 master。
BFD 参数不要配得太激进。我在实际测试中用过 30ms 的发送间隔加 3 倍检测倍数，结果链路稍有拥塞就会产生误报，导致 VRRP 频繁切换。一般建议min-tx-interval和min-rx-interval设置在 100ms 左右，detect-multiplier保持 3，这个组合基本能在 300ms 内发现故障，同时不会因为瞬时抖动误切。
4.2 做法二：Monitor Link实现上联故障自动切断下行
BFD 解决了 VRRP 的切换问题，但没有解决二层拓扑的感知问题。Core1 上联故障后，网关切到了 Core2，但 Core1 还活着，MSTP 的根桥可能还是它。接入交换机在生成树计算中仍然把根端口指到 Core1，流量绕了一个圈才到 Core2，路径不优且多一次跨核心转发。
解决这个问题的思路就是利用 Monitor Link，把 Core1 的上联口和下联口绑定。上联口作为 uplink，下联到接入交换机的口作为 downlink。当所有上联口都故障时，下行口自动 shutdown，从二层拓扑上把 Core1 “摘除”。配置如下：
monitor-link group 1 port GigabitEthernet0/0/3 uplink port GigabitEthernet0/0/1 downlink port GigabitEthernet0/0/2 downlinkCore2 上做同样的配置，但绑定的具体接口按实际拓扑调整。这里的 GE0/0/3 是上联口，GE0/0/1 和 GE0/0/2 是下联到 SW1、SW2 的口。Monitor Link 组的逻辑是：只要组内有一个 uplink 是通的，downlink 就保持正常；当所有 uplink 都 down 时，downlink 才跟着 down。
这个配置的效果非常直观。Core1 的上联口 shutdown 后，它下联 SW1、SW2 的两个口马上也变成 Down。SW1、SW2 发现 Core1 方向不可达，MSTP 在几百毫秒内重新收敛，把根端口切换到 Core2 方向。三层网关切换和二层拓扑收敛同步发生，业务恢复时间大幅缩短。
4.3 做法三：VRRP Track接口优先级联动
如果你的设备不支持 BFD，或者上联口就是直连物理接口，可以用最简单的 track 接口方式：
interface Vlanif10 vrrp vrid 1 track interface GigabitEthernet0/0/3 reduced 40这种方式是让 VRRP 直接监视上联口的物理状态。上联口 down，VRRP 优先级立即降低；恢复后优先级回升。它和 BFD 的主要区别在于，track 接口只能感知物理层的通断，如果链路物理通但对端设备转发功能失效，track 接口是感知不到的。BFD 可以通过双向会话检测对端是否可达，灵敏度更高，但配置也更复杂。
实际项目里我的选择标准很简单：如果上联是对端设备直连，用 track 接口省事且可靠；如果中间还有二层透传设备，或者需要检测对端转发能力，就上 BFD。把 BFD 和 track 接口都配置上也没有冲突，VRRP 可以同时监视多个对象，最终优先级降低量会累加，但要小心别把优先级减成负数。
4.4 三种方案组合使用的推荐套路
这三种做法并不是互斥的，实验里最推荐的组合是 BFD for VRRP 加 Monitor Link。BFD 负责感知上联链路故障并把 VRRP 优先级降下来，Monitor Link 负责把故障传导到二层拓扑，让 MSTP 快速收敛，两者配合才能实现“网关切换”和“路径切换”的同步。只做 BFD 不做 Monitor Link，会出现网关切过去了但二层还在往旧根桥送的绕行问题；只做 Monitor Link 不做 BFD，VRRP 切换可能要等报文超时，切换时间会拉到秒级。
还有个细节，Monitor Link 的 downlink 口一定要选准。如果你把核心间互联的 Eth-Trunk 也放进 downlink，上联一断，两台核心间的链路直接被关掉，VRRP 心跳同步也断了，后续恢复还会出现状态不一致，实验容易进入“越修越乱”的局面。所以核心互联口不能放进 Monitor Link 组，它必须保持独立。
5. 实验验证与故障模拟
5.1 正常态验证命令与输出解读
配置完成后，先看正常状态下的各项输出。Core1 上执行display vrrp brief，输出大致如下：
Interface VRID State RunState Virtual IP Master IP Priority Vlanif10 1 Master Up 192.168.10.254 192.168.10.253 120 Vlanif20 2 Backup Up 192.168.20.254 192.168.20.252 100Core2 的输出则正好相反，VLAN 10 是 Backup，VLAN 20 是 Master。这说明 VRRP 的负载分担关系已经建立。
接着看 MSTP 的根桥状态。Core1 上执行display stp instance 1 root，能看到 instance 1 的根桥是本地设备；执行display stp instance 2 root，能看到 instance 2 的根桥指向 Core2 的 MAC 地址。Core2 上相反。在 SW1 上执行display stp instance 1 brief，可以看到 SW1 连 Core1 的上联口角色是 ROOT，状态为 FORWARDING；连 Core2 的上联口角色是 ALTE，状态为 DISCARDING。这说明 VLAN 10 的流量在二层确实走 Core1 方向。
再检查 BFD 和 Monitor Link。display bfd session verbose能看到两个 BFD 会话状态都是 Up，本地标识符和远端标识符匹配。display monitor-link group 1能看到上联口状态 Up，下行口状态 Up。所有东西就位，接下来就可以制造故障了。
5.2 模拟上联故障：观察VRRP与MSTP联动收敛
故障模拟很简单，在 Core1 上把上联口直接 shutdown：
system-view interface GigabitEthernet0/0/3 shutdown这个动作会同时触发三个连锁反应。第一，BFD 会话在 300ms 内变为 Down，Core1 的 VLAN 10 VRRP 优先级从 120 降到 80。第二，Core2 检测到 Core1 的优先级变化，抢占成为 VLAN 10 的 master。第三，Monitor Link 检测到上联口 down，自动把 Core1 下联 SW1、SW2 的口 shutdown。此时在 Core1 上执行display vrrp brief，VLAN 10 的状态已经变成 Backup；在 Core2 上执行同样命令，VLAN 10 的状态变成 Master。
再到 SW1 上看生成树。由于 Core1 的下联口已经被 Monitor Link 关掉，SW1 在 instance 1 中到 Core1 的上联口状态变为 Down，原来被阻塞的到 Core2 的上联口快速切换为 ROOT 和 FORWARDING。整个收敛过程实测在 1 到 2 秒之间，如果不加 Monitor Link 联动，这个过程可能需要好几秒甚至更久，而且路径可能先绕到 Core1 再跨核心回 Core2，造成不必要的延迟。
用终端持续 ping 虚拟网关 192.168.10.254，能看到故障瞬间会丢 2 到 3 个包，这是 MSTP 在切换端口状态时必然产生的短暂中断。相比不做联动时可能丢 10 个以上甚至持续不通，这个结果已经有明显改善。如果你把 BFD 间隔调小到 50ms，丢包能控制在 1 到 2 个，但前提是链路质量足够好，否则误报率会上升。
恢复故障时，把 Core1 的 GE0/0/3 重新 undo shutdown。Monitor Link 检测到上联恢复，下联口自动恢复 Up；BFD 会话重新建立，Core1 的优先级回到 120。由于配置了抢占延迟 5 秒，Core1 会在 5 秒后重新抢回 VLAN 10 的 master 角色，SW1 的生成树也随之收敛回原路径。
5.3 模拟核心间链路故障：双主风险与对策验证
把核心间 Eth-Trunk 直接 shutdown，可以模拟最极端的情况。此时 Core1 和 Core2 之间的 VRRP 心跳彻底中断，两边都会在超时后主动把自己变成 master。我在实验里实测过，不采取任何额外措施，两台核心会同时显示 VLAN 10 和 VLAN 20 均为 Master，这就是典型的双主状态。
所以核心间的链路可靠是这套方案的前提。用 Eth-Trunk 保证单条成员链路故障不影响逻辑链路，但如果整个 Eth-Trunk 都没了，VRRP 本身是没有仲裁能力的。实验环境里我建议加一条带外心跳链路，或者在核心之间保留一个专用的管理 VLAN，保证极端情况下还有一条路径能传递 VRRP 报文。如果你所在的项目对可用性要求极高，不考虑堆叠但又要严格避免双主，就需要引入更复杂的第三方检测机制或集群仲裁方案，这就超出 VRRP+MSTP 本身的能力范围了。
6. 踩坑实录与常见问题排查
6.1 根桥和VRRP主备错位导致回程绕行
这是我见过最多的问题。现象是业务能通，但延迟偏高，或者在核心上看到的流量走向完全不符合预期。排查第一步一定是同时执行display vrrp brief和display stp instance 1 root，把 VRRP 主设备和 MSTP 根桥的实际位置对齐。如果 VLAN 10 的 VRRP master 在 Core1，根桥却显示 Core2，那么接入交换机就会优先把流量送到 Core2，再由 Core2 跨核心送到 Core1 的网关，路径明显多一跳。
解决办法就是按照前面的设计，把stp instance root primary和 VRRP 优先级放在同一台设备上。如果故障场景下 VRRP 已经切换，而 MSTP 根桥没有跟着切换，就要检查 Monitor Link 有没有生效，或者下联口有没有被正确关闭。
6.2 BFD参数设置不当引发频繁切换
BFD 是好东西，但参数配不好反而是灾难。我在实验里尝试过把发送间隔配成 30ms、检测倍数为 3，结果只是对端设备 CPU 稍微忙一点，BFD 会话就开始抖动，VRRP 优先级忽高忽低，主备关系来回切换，业务反而比不配 BFD 时更不稳定。后来老老实实改回 100ms 间隔加 3 倍检测，整条链路就安静了。这里面要理解一个道理：BFD 检测越快，对网络质量要求越高，对于普通以太网链路，100ms 已经足够快，它能把故障发现时间控制在 300ms 左右，对绝大多数业务来说都是可以接受的。
6.3 Monitor Link配置失误导致大范围断网
Monitor Link 的误配置风险在于 downlink 端口范围过大。有些同行习惯把核心上所有下联口都放进一个 Monitor Link 组，只要上联一断，所有下联口全部 shutdown，整台核心下的所有业务直接全断。虽然设计上这是“强制切换”，但如果对端核心没有正确接管，或者接入交换机的生成树收敛出现异常，影响范围就会失控。建议一个 Monitor Link 组只放同一个故障域下的端口，不同接入区域尽量拆分到不同组，这样单点故障的影响能被限制在局部。
排查 Monitor Link 问题时用display monitor-link group 1，可以清楚看到每个端口的角色（uplink/downlink）和实时状态。如果上联已经 down 但下联没有跟着 down，检查是否还有其他 uplink 处于 up 状态，Monitor Link 的逻辑是只要有一个 uplink 正常，就不触发下行关闭，这是很多人容易忽略的点。
6.4 联动不生效的通用排查思路
如果 VRRP 切换和 MSTP 收敛没有按预期联动，我的排查顺序通常是这样：先看 VRRP 状态是否切换了，没有切换就查 BFD 会话是不是真的 down、track 有没有配错、优先级减完以后是不是仍然高于对端；再看 Monitor Link 有没有动作，没有动作就查 uplink/downlink 绑定关系和端口实际状态；最后查接入交换机的生成树，看端口角色有没有重新计算，如果一直不变，可能是边缘端口没配好，或者下联链路被别的配置锁死了。
这套顺序其实是按照“三层状态→联动机制→二层收敛”的方向来的，每一步都能通过 display 命令确认状态，最后总能找到断点。如果你一上来就查生成树，很容易被冗长的 BPDU 信息带偏思路，浪费很多时间。
6.5 边缘端口和BPDU保护不能省
接入交换机上终端口的stp edged-port enable和全局stp bpdu-protection这两个配置，看起来和 VRRP、MSTP 联动没关系，实际上影响非常大。没有边缘端口配置，终端设备插拔网线会触发拓扑变更，每次变动都会让核心重新计算生成树，联动切换后的收敛速度也会受影响。我见过一个现场，终端重启一次，全网核心 CPU 飙升，生成树反复震荡，就是因为边缘端口没配。实验环境虽然简单，但我建议从一开始就把这些保护配置加上，养成好习惯，等到了生产网络就不会漏。
最后说一点我自己的体会。做这类联动实验，最难的不是敲命令，而是把 VRRP 的状态机、MSTP 的生成树计算、接口检测的触发条件这三件事在脑子里串成一条线。你只有理解了上联故障会先影响 BFD、再影响 VRRP 优先级、再通过 Monitor Link 影响二层拓扑这一整条链路，才能真正明白为什么每一步配置都必不可少。否则出了故障只会看到一个现象，然后凭感觉乱试，那样排障效率会非常低。这套实验做完之后，我建议你再把接入交换机从一台扩展成两台、形成一个真正的环网，重新跑一遍故障模拟，你会对 MSTP 的端口角色切换和 BPDU 交互有更深一层的理解。
