园区网接入双归组网：Smart-Link与Monitor-Link联动配置实战

接入层交换机双上联到两台汇聚设备，这种组网在园区网里太常见了。但越是常见的组网，越容易在切换那一下出问题：主链路光纤一断，如果只靠STP收敛，秒级甚至十秒级的等待时间足以让语音、视频、监控全部卡死。Smart-Link就是专门解决这个问题的，它能在几十毫秒内把流量从主链路切到备用链路。可事情还没完——如果汇聚设备本身的上联断了，接入交换机根本感知不到，因为它到汇聚设备的物理链路还up着，流量照样往黑洞里塞。这时候就得靠Monitor-Link上场，把汇聚设备的“上联故障”翻译成“下行口down”，让接入交换机立刻察觉并切走。这篇内容就是拆解这两个技术怎么配、怎么验证、日常怎么排障，适合正在做园区网交付、维护接入双归组网的网络工程师参考。

1. 先搞清楚Smart-Link和Monitor-Link各自解决什么问题

1.1 为什么接入层双归组网不靠STP，而要单独做Smart-Link

接入层交换机双归到两台汇聚设备，本质上是给接入交换机留了一条备用上行路径。但二层网络最怕环路，STP/RSTP的出现就是为了防环。问题是，STP的收敛过程需要经过端口角色选举、状态机迁移、BPDU交互，即使是最快的RSTP，在复杂的接入汇聚模型下也往往需要几百毫秒到数秒才能恢复转发。对业务来说，这个时间太长了。

Smart-Link的思路完全不一样。它不需要全网计算，只在两台设备之间的两根链路上做文章。一个Smart-Link组里有主链路（primary）和备链路（secondary）两个角色，平时只有主链路转发业务，备链路阻塞；一旦主链路故障，备链路直接顶上来，不需要任何协商。整个过程就像家里的双电源UPS，一路断电另一路瞬间接上，不需要重新拉闸、重新合闸。

这个“快”的代价是，Smart-Link只保护自己组内的两条链路，它不是全网防环工具。所以组网设计时，凡是跑Smart-Link的物理链路之间不能再有其他二层冗余路径，否则环路风险完全暴露。很多新手在这里栽过跟头：配置了Smart-Link，但旁边还挂了根临时链路，结果一发生切换就广播风暴。记住，Smart-Link负责的是“链路互备”，STP负责的“全网防环”职责并没有被取代，只是Smart-Link要求你提前把环剪干净。

1.2 Monitor-Link不是“第二条备份链路”，而是“故障传话人”

Monitor-Link这个名字容易误导人，很多人以为它也是做链路备份的，其实完全不是。Monitor-Link组里有两类成员：上行口（uplink）和下行口（downlink）。它的逻辑特别简单：当所有上行口都down掉时，自动shutdown所有下行口；当上行口恢复up后，再自动undo shutdown下行口。

这个机制有什么用？看一个经典场景。接入交换机SwitchA双上联到汇聚设备C和D，C是主，D是备。SwitchA上配置了Smart-Link，一切看起来很完美。但某天C设备自己的上联——就是C连核心的那根光纤——断了。注意，这根光纤断的是C的“北向”，不是C和SwitchA之间的“南向”。SwitchA到C的链路依然物理up，Smart-Link根本不会触发。SwitchA把业务报文送给C，C却送不上去，流量直接黑洞。

这个时候，Monitor-Link的价值就出来了。在C设备上创建一个Monitor-Link组，把C的上联口设为上行口，把C连接SwitchA的口设为下行口。一旦C的上联口down，C马上把自己连SwitchA的口强制shutdown。这个shutdown动作传下去，SwitchA看到自己到C的物理链路down了，Smart-Link立刻把流量切到D。整个过程是“上游故障→本地端口动作→下游设备感知→冗余机制触发”，故障被一级一级翻译下去。

这里有个关键点：Monitor-Link的联动不依赖下游设备认识任何私有协议，它就是用物理端口up/down做信号。所以哪怕下游是其他厂商设备、甚至是一台傻瓜交换机，都能照样触发切换。这比单纯发协议报文要通用得多。

Smart-Link和Monitor-Link的分工可以这样理解：Smart-Link管的是“本设备自己的两根上行链路怎么互备”，Monitor-Link管的是“怎么把远端故障变成自己的本地端口事件”。一个往内看，一个往外看，两个配合起来才能把一条完整的端到端路径打通。

2. 动手配置前，先把方案和参数想清楚

2.1 典型组网拓扑与角色规划

配置之前先画一张角色表。很多问题不是配置敲错，而是角色没规划明白。以下面这个典型组网为例：

核心层有两台设备，汇聚层有两台设备C和D，接入层有一台交换机SwitchA。SwitchA分别上联C和D，C和D再各自上联核心。SwitchA的Smart-Link组里，到C的链路设为主，到D的链路设为备。C和D上各有一个Monitor-Link组，分别监控各自的上联口，联动各自的南向口。

方向规划上有一个容易被忽略的细节：Smart-Link的主备方向和网关上VRRP/VRRP的主备方向要保持一致。比如SwitchA到C是主链路，C上的VRRP就应该也是主网关，D上是备网关。如果链路主备用的是A方向，网关主备用的却是D方向，切换后流量虽然能从D走，但网关转发路径绕一大圈，延迟和带宽都会出问题。

另外要注意备链路平时的状态。Smart-Link的备链路虽然在转发业务上是阻塞的，但物理链路是up的，控制VLAN也要保证能透传。很多人在display看到备端口状态是“STANDBY”或者“INACTIVE”，就误以为端口坏了，其实那是正常的。只要控制VLAN能通，Smart-Link随时准备着切换。

2.2 控制VLAN、保护VLAN和定时器怎么选

Smart-Link有三个核心参数，配置前必须想明白。

控制VLAN（control-vlan）。这个VLAN专门用来承载Smart-Link的flush报文，不承载业务。规划上建议全网统一一个固定VLAN ID，比如VLAN 100，所有涉及Smart-Link的设备都放通这个VLAN。为什么不用业务VLAN当控制VLAN？因为flush报文是一种控制帧，如果和业务广播混在一起，可能被流量挤掉、延迟，甚至被某些过滤策略误杀。用一个干净的专用VLAN，协议报文走专线，互不干扰。控制VLAN必须在Smart-Link组成员端口和上下游转发链路上都放通，漏了任何一段，切换时下游就收不到刷新MAC的指令。

保护VLAN（protected-vlan）。这个参数定义的是“哪些业务VLAN需要跟随Smart-Link切换并执行MAC地址刷新”。如果业务VLAN是10、20、30，就要把这些VLAN全部列进去，或者使用引用实例的方式，把这个范围内的所有VLAN都覆盖到。漏掉任何一个业务VLAN，结果就是切换后其他VLAN都通了，唯独漏掉的那个VLAN不通，排查起来非常隐蔽。我的习惯是，保护VLAN直接引用实例或者用范围段，宁可大一点，不要漏。

定时器参数。常见的有flush报文发送次数、接收超时时间等。绝大多数场景用默认值就行，重点是理解它影响什么：发送次数太少，下游可能漏收flush报文；接收超时太短，网络有轻微抖动时下游就频繁刷新MAC。如果在实际验证中发现切换后丢包偏多，可以先看看是不是flush报文发送间隔太长了。

还有一个关键参数是抢占模式。默认情况下Smart-Link是不抢占的，主链路恢复后，流量继续走备链路，不会切回去。这是为了防止链路抖动导致反复切换。如果业务要求主链路恢复后必须切回，就需要配置抢占功能，并且把抢占延迟设得大一些，比如60秒以上，给链路一个稳定期。否则光纤刚恢复还没来得及稳定，又断了，来回切两三次，业务比不断还难受。

2.3 与STP、链路聚合、堆叠的关系

Smart-Link和STP的关系必须处理干净。在配置了Smart-Link的成员端口上，要把STP关掉，或者配置成边缘端口加BPDU过滤。原因很简单：STP会基于BPDU计算端口角色，很可能把Smart-Link的备端口阻塞掉。Smart-Link的备链路本来就是靠自身机制阻塞的，STP再插一脚，转发状态就被搅乱了。如果整网必须保留STP防环，那至少要在Smart-Link成员口上做边缘端口+BPDU filter，让它不参与STP计算。

这里要给个实实在在的提醒：关闭STP意味着不再有协议帮你防环，所以必须再次确认组网里没有旁路环路。Smart-Link这个技术本身不防环，它只做主备切换，防环要靠你的组网设计。

那什么时候优先用堆叠和跨设备链路聚合，而不是Smart-Link？如果汇聚设备C和D支持堆叠或集群，把两台虚拟成一台，再用跨设备Eth-Trunk下连SwitchA，这才是最优解。堆叠加聚合不仅能做冗余，还能把两条链路同时用于转发，带宽翻倍，切换也无感知。Smart-Link是用在“实在堆叠不了、只能两台独立设备互相备份”的场景。如果设备支持M-LAG之类的跨设备链路聚合，也优先用它，Smart-Link是退而求其次的选择。

链路聚合和Smart-Link还有一个配合点：Smart-Link的成员端口可以是聚合口。如果SwitchA上联C的链路本身是Eth-Trunk，这个聚合口就直接作为Smart-Link组的primary成员。聚合内部的成员链路down一两条不影响Smart-Link，只有整个聚合口down掉才会触发切换。这样设计更稳，也避免单根物理链路抖动导致Smart-Link反复倒换。

3. 配置实操：以一台接入交换机为例逐步敲命令

3.1 接入交换机的Smart-Link组配置

下面以业内常见的商用交换机命令行风格为例，逐步配置SwitchA。先登录设备，进入系统视图。

第一步，创建Smart-Link组并配置控制VLAN和保护VLAN。组编号建议从1开始，一个设备上如果有多个双归场景，可以建多个组，但每个成员端口只能属于一个组，千万别混用。

<SwitchA> system-view [SwitchA] smart-link group 1 [SwitchA-smart-link-group1] control-vlan 100 [SwitchA-smart-link-group1] protected-vlan 10 20 30 [SwitchA-smart-link-group1] quit

这里control-vlan用了100，protected-vlan列了业务VLAN 10、20、30。如果业务VLAN特别多，可以引用实例的方式，比如protected-vlan reference-instance 0，把实例0里的所有VLAN都覆盖到。这一步配置顺序很关键，必须先创建组、配好参数，再往组里加成员口，最后使能。顺序反了，组处于空状态就使能，部分版本会直接报错。

第二步，给物理端口指定角色。SwitchA的G0/0/1上联C，做主链路；G0/0/2上联D，做备链路。

[SwitchA] interface GigabitEthernet0/0/1 [SwitchA-GigabitEthernet0/0/1] smart-link group 1 role primary [SwitchA-GigabitEthernet0/0/1] quit [SwitchA] interface GigabitEthernet0/0/2 [SwitchA-GigabitEthernet0/0/2] smart-link group 1 role secondary [SwitchA-GigabitEthernet0/0/2] quit

第三步，使能Smart-Link组，并开启flush报文发送功能。

[SwitchA] smart-link group 1 enable [SwitchA] smart-link flush send control-vlan 100

smart-link flush send这行很多人会漏。它的作用是：当发生主备切换时，SwitchA在控制VLAN里发送flush报文，通知下游设备在保护VLAN范围内刷新MAC地址表和ARP表项。没有这个动作，下游设备还记着旧端口的MAC表，切换后流量照样送不到新端口，要等MAC老化（通常是300秒）才恢复，这在业务上等于断线五分钟。

如果在同一个网络里有其他也支持Smart-Link的设备，它们收到flush报文后会自动刷新MAC，不需要额外配置。如果下游设备不支持这些协议，那就得靠Monitor-Link把端口down掉来触发物理层重新学习，这也是为什么这两个功能经常成对出现。

最后处理STP。建议在Smart-Link的成员端口上配置边缘端口和BPDU过滤。命令风格类似stp edged-port enable和stp bpdu-filter enable。不同版本写法有差异，实际项目中按设备支持的命令来。这一步不配置，后面验证时大概率会发现主链路shutdown后流量切不过去，坑就出在STP还阻塞着备端口。

3.2 汇聚设备的Monitor-Link组配置

汇聚设备C上的Monitor-Link配置。假设C的G0/0/1上联核心，G0/0/2下连SwitchA。

<DeviceC> system-view [DeviceC] monitor-link group 1 [DeviceC-monitor-link-group1] uplink GigabitEthernet0/0/1 [DeviceC-monitor-link-group1] downlink GigabitEthernet0/0/2 [DeviceC-monitor-link-group1] quit [DeviceC] monitor-link group 1 enable

配置逻辑很清楚：上行口监控上联核心的链路状态，下行口是连接接入交换机的端口。上行口down掉，下行口被强制shutdown；上行口恢复，下行口自动undo shutdown。汇聚设备D上做同样配置，监控自己的上联口，联动自己的下行口。

这里有几个容易翻车的细节。

上行口不要只盯物理口。如果C的上联是Eth-Trunk（很可能，因为汇聚上联核心一般都做聚合），Monitor-Link的上行口应该配置成Eth-Trunk口，而不是聚合成员物理口。如果配的是物理口，聚合里任何一根成员链路抖动，都会让Monitor-Link以为上联断了，把下行口全down掉，引发一次无谓的接入侧切换。这种误切换最讨厌，因为它不是真故障，却把整片业务切了一遍。

下行口如果原来被手动shutdown过，Monitor-Link恢复时会自动帮你undo shutdown。这个行为在日常维护中很危险：你为了割接把某端口手动down掉，结果Monitor-Link因为另一个上行口抖动，把这个口自动恢复了，业务可能在不该恢复的时候恢复。所以我实操中的习惯是：设备上跑了Monitor-Link组的端口，在变更方案里一定标注清楚，不要对这些端口做手动shutdown操作，真需要断口就先把Monitor-Link组挂掉。

Monitor-Link支持多个上行口。可以理解成逻辑是“所有上行口都down了，下行口才down”，也就是“与”的关系。利用这个特性，汇聚上联核心可以同时监控两个上行口，只要还有一个上行口活着，就说明南向链路还能把流量送出去，不需要联动下行。反过来，如果希望“任意一个上行口down就联动”，那要规划成多个Monitor-Link组，每个组一个上行口，共同down同一个下行口。不同业务诉求对应不同组法，配置前先想清楚故障模型。

3.3 下游设备的配合动作

SwitchA到汇聚C之间的链路，被Monitor-Link强制shutdown后，SwitchA看到的物理口状态会变成down。这时候SwitchA的Smart-Link发现主链路down，就会切到备链路。注意，这个机制不是通过任何协议协商出来的，纯粹是物理层状态变化触发的。所以对端设备不需要认识Monitor-Link，不需要做什么额外配置。

但Smart-Link切换完成后，flush报文要能送到下游。如果SwitchA的南向还有下一级设备（比如还有二级接入交换机），这些设备就需要放通控制VLAN。这个动作特别容易被人遗忘：接入交换机配置了Smart-Link，但往下的汇聚交换机没有放通control-vlan，导致flush报文到不了最终的终端接入设备，MAC表刷不动，切换后还是不通。

如果SwitchA下连的是不支持Smart-Link的场景，也没有Monitor-Link可以联动，那需要在切换后手动清MAC，或者接受MAC老化带来的短暂中断。这种场景在旧网络改造时经常遇到，我的建议是：要么把下联设备纳入Monitor-Link联动范围，要么干脆让SwitchA通过下联口感知主链路down来触发自身的二三层重新学习。具体怎么做，取决于下联设备的冗余机制是什么，不能一概而论。

4. 配置验证与故障切换仿真

4.1 怎么看状态：display命令逐项解读

配置完成不等于能用，必须验证。先看Smart-Link组状态。

[SwitchA] display smart-link group 1

关注几个字段：组成员端口角色是否分别是primary和secondary；组是否使能；控制和保护VLAN的配置是否生效；当前是否有倒换标记。备链路平时显示为“INACTIVE”或者“STANDBY”，这不代表端口down，它物理口是up的，只是被Smart-Link阻塞了转发。很多人第一次看这里以为配置错了，其实只要控制VLAN能通，状态就是对的。

再看Monitor-Link组状态。

[DeviceC] display monitor-link group 1

查看上行口和下行口的状态。正常情况下上行口up，下行口也跟着up。把上联口shutdown后，再执行这条命令，应该能看到下行口变成down。这个验证最直观，也能顺便确认Monitor-Link的动作有没有被其他配置干扰。

还有一条命令值得养成习惯：display interface，看端口的最近一次down原因。Smart-Link切换后，主链路端口的down原因会记录为“物理链路断开”，Monitor-Link联动down的口，原因会是“由Monitor-Link强制shutdown”。如果看到端口的down原因和自己预期的操作对不上，说明联动关系没有按设计走，要回溯配置。

4.2 手动倒换验证：shutdown主链路后看结果

验证Smart-Link的标准动作。在SwitchA上打开一个长ping，目标是网关地址或核心网段，ping包大小和间隔按业务来，建议间隔100ms以内，这样丢包数能精确反映切换耗时。

然后进入SwitchA的主链路端口视图，执行shutdown。

[SwitchA] interface GigabitEthernet0/0/1 [SwitchA-GigabitEthernet0/0/1] shutdown

正常情况下，Smart-Link会在几十毫秒内切换，ping可能丢一个包，甚至一个都不丢。丢包数量能反映切换质量：如果丢了十几个包，说明切换时间在百毫秒级别以上，要查flush报文是否正常发送、备链路端口状态是否被阻塞。如果直接断了几秒，大概率是STP在捣乱，备端口被STP阻塞了，根本没起来。

切换后执行display smart-link group 1，确认状态变为倒换，备链路已经接管转发。然后恢复主链路端口。

[SwitchA] interface GigabitEthernet0/0/1 [SwitchA-GigabitEthernet0/0/1] undo shutdown

如果配置了抢占，等待抢占延迟结束后再次查看状态，主链路应该重新接管。如果没有配置抢占，流量保持在备链路，这是正常的。

Monitor-Link的验证动作类似。在汇聚设备C上，shutdown上联核心的口，然后立刻在SwitchA上ping网关。预期结果是：C下行口在极短时间内被联动shutdown，SwitchA感知主链路down，Smart-Link切到D，整个过程中断时间应该很短。如果SwitchA迟迟不切换，先查Monitor-Link下行口有没有真正down掉，再看Smart-Link有没有正确感知。

验证过程中一定要记得恢复端口。我在现场见过不止一次，验证完忘把shutdown的口undo，业务恢复一半，另一半全走备用链路，主链路空着，一查是上个工程师留下的shutdown。验证前把操作步骤打印出来，每步打个勾，恢复动作也写进去，这是基本功。

4.3 实操中容易踩的三个坑

先说VLAN放通遗漏。控制VLAN和保护VLAN在所有涉及设备上都要放通。我遇到过这样一个案例：Smart-Link配置明明是对的，切换后VLAN 10通，VLAN 20不通。查了半天，最后发现保护VLAN列表里漏了20。保护VLAN漏配的效果就是，切换发生后，漏掉的VLAN不会刷新MAC表，流量继续按旧路径送，直到MAC老化。排查这类问题时，先别查接口状态，直接翻配置，对照业务VLAN列表和protected-vlan列表，一眼就能看出问题。

再说单通链路。Smart-Link判断链路故障靠的是物理端口up/down，但光纤链路有一种故障叫“单通”：一根纤断了，另一根还通，端口物理状态仍然up。这种情况下Smart-Link认为主链路好好的，实际流量已经送不过去了，黑洞就这么产生了。解决思路是别只靠物理状态，在上联口启用BFD单跳检测，检测到链路异常时直接把端口shutdown掉，Smart-Link感知到端口down，才会触发切换。这个方案在实践中很有效，代价是要多做一层BFD配置，但能补上Smart-Link最明显的盲区。

最后说Monitor-Link误管理。前面提过，Monitor-Link恢复时会自动undo shutdown下行口。有一种常见情况：网络工程师做维护，把某台下联口手动shutdown，结果另一个上行口抖动了一下，Monitor-Link把下行口自动恢复了，业务瞬间恢复，又把故障掩盖了。这种“幽灵恢复”比故障本身更难排查。运维规范里要明确：被Monitor-Link管理着的端口，严禁手动shutdown；确需操作，先undo monitor-link或临时把端口从组里摘掉。

5. 常见故障排查速查表

实际排障时，最怕的是现象一样、根因不同。这里整理了一份我在项目中反复用到的排查速查表，按现象分组，照着查能省一半时间。

排障指令方面，有几个东西值得常备：display logbuffer看本设备的Smart-Link和Monitor-Link相关日志；debugging smart-link或debugging monitor-link看协议过程，不过debug命令在生产设备上要慎用，会影响CPU，建议在维护窗口内执行；抓包看控制VLAN里的flush报文，这是定位“切换后流量不通”最直接的手段。

我还想提一个排查思路上的建议：Smart-Link和Monitor-Link的问题，不要只盯着配置那一层。很多时候问题出在物理链路质量上，比如光模块收发功率异常、光纤跳线衰减过大，导致端口状态频繁抖动。先确认物理层稳定，再看协议层逻辑，排障顺序反了会浪费大量时间。用display interface看CRC错误计数和光模块参数，几秒钟就能判断物理链路健康度。

6. 配置之后的一些个人体会

最后说几句我在实际项目里的感受。Smart-Link和Monitor-Link这两个技术，本身并不复杂，命令量也很少，但真正考验人的是组网意识和参数规划。我见过太多配置敲得飞快、最后切换丢包一大片的案例，根子都在配置前没把主备方向、保护VLAN列表、STP边界这些事想清楚。设备不背锅，背锅的是方案。

如果让我给一个配置前检查清单，大概是这么几条：第一，画清物理拓扑和端口角色表，主备方向和网关主备方向保持一致；第二，控制VLAN全网统一编号并确保放通；第三，保护VLAN穷尽所有业务VLAN；第四，成员端口处理完STP；第五，准备好验证步骤和回退命令。这五条都过了，配置本身反而只是二十分钟的活。

这个配置后续还能扩展的地方也很多。比如Smart-Link加BFD做单通检测、Monitor-Link联动堆叠系统的跨设备上行口、甚至用网管平台把Smart-Link的倒换记录做成告警，都是我在实践中验证过有用的方向。技术本身是固定的，但怎么组合进自己的组网里，每个网络工程师都会慢慢积累出自己的一套打法。希望这篇记录能帮你少踩几个坑。