最近帮一个核心机房的网络做改造，两台汇聚交换机要做双机冗余，传统的VRRP+STP方案配置麻烦，链路利用率还低，倒换也要等好几秒。后来直接把这两台设备做成了VSC，也就是中兴交换机的虚拟交换集群，把两台物理交换机虚拟化成一台逻辑设备来管理。这个方案实操下来效果很明显，配置量少了一大半，故障切换基本无感知。这篇就完整记录一下VSC从规划到落地的全过程，包括配置命令、验证方法和我踩过的坑，给同样准备做双机虚拟化的朋友一个参考。
1. 为什么用VSC：双机热备的老问题与虚拟集群的价值
先说清楚VSC到底解决了什么。以前做链路冗余，最常规的思路是两台交换机跑VRRP作为网关冗余，下联交换机或者服务器做双归接入，靠STP阻塞一个端口来防环。这套方案能用，但问题也很明显。
1.1 传统方案的三个痛点
配置量大。一台接入交换机要上联到两台汇聚，两台汇聚要各自配VRRP、MSTP实例、ACL、QoS策略，任何一条策略都要在两边重复操作，漏改一处就容易出故障。如果还有多VLAN网关，VRRP的配置量会成倍上涨。
链路利用率低。STP阻塞掉的那条链路平时是闲置的，你为它付了光模块、光纤和端口的成本，换来的只是备份能力。服务器双网卡做主备模式时同理，真正在跑流量的一侧满载，另一侧在空转。
倒换时间不稳定。VRRP主备倒换加上STP重新收敛，通常在秒级。对普通办公网络没什么，但在数据库、虚拟化集群这种对丢包敏感的场景，一秒的丢包可能引发上层业务超时，然后触发一堆告警。
1.2 VSC把“两台”变成“一台”
VSC的核心思路是让两台成员交换机通过专用的高速链路互联，共享控制面和转发表项，对外呈现为单一的逻辑设备。下联交换机只需要接一次，不需要做双归；服务器通过跨设备链路聚合，两条链路同时转发；网关也只在逻辑设备上配置一份，自动完成跨框备份。
实际体验最明显的一点是，管理起来从“两台设备同步修改”变成“一台设备集中配置”，配置同步是自动完成的。主设备故障后，备机接管控制面，转发层面因为表项本来就在框间同步，所以业务中断时间很短，体感远好于传统VRRP方案。
1.3 适用场景与不适用场景
VSC比较适合同一机房内、物理位置相邻的交换机，比如数据中心的汇聚层、园区的核心层、虚拟化集群的接入层。两台设备距离越近，VSC互联链路越短，可靠性越高。
跨楼宇、跨机房的场景不建议上VSC。VSC要求两台设备之间必须有高性能、低时延的互联链路，距离拉远之后光缆成本高，而且一旦互联链路中断，整个逻辑设备会分裂成两台独立设备，处理不好就是“双主”脑裂。跨地域高可用应该用独立的网关虚拟化方案或者三层路由冗余来实现，而不是靠VSC。
2. 上线前必须定死的五件事：拓扑、编号、转发模式与前置检查
VSC最忌讳“线拉好了直接配”，很多后续排障问题都是规划阶段埋下的。我习惯在动手之前先把下面几件事全部定下来，写成一张表格发给相关同事确认。
2.1 物理拓扑：环形还是链形
VSC成员之间通过VSC链路互联，常见拓扑有环形和链形。环形是每台设备都有两条VSC链路分别连到相邻两台，形成闭合环路；链形则是一条串到头，只在两端闭合。
| 对比项 | 环形 | 链形 |
|---|---|---|
| 链路冗余性 | 单条VSC链路故障不影响集群 | 中间链路断开会分裂 |
| 带宽开销 | VSC流量可走两个方向，带宽更大 | 跨框流量路径单一 |
| 端口占用 | 每台设备至少两个VSC端口 | 每台设备一个端口即可 |
| 推荐场景 | 生产核心、对可靠性要求高 | 接入层、成本敏感场景 |
实际项目里我基本都选环形，两台设备各用四个端口做VSC，组成双环形互联。端口多花一点，换来的是一条链路断掉后整个VSC完全无感的余量，这笔账划算。
2.2 成员编号与接口命名的逻辑
VSC里每台成员交换机有唯一的成员编号，接口命名会带上编号，比如gei_1/1/1和gei_2/1/1分别表示1号机和2号机的1槽位1口。这个编号一开始就要规划好，上线后尽量不要改。
编号一旦和物理位置绑定，后续的端口配置、监控脚本、告警信息都会沿着这套命名走下去。我见过有项目上线时没固定编号，设备重启后槽位号漂移，结果所有涉及接口的脚本全部失效，排查了大半天才发现是编号变了。所以上线前我必做一张“物理位置-设备名-成员编号-管理IP”的对照表，贴在机柜门上，配置时照着写。
2.3 转发模式：本地优先还是跨框转发
VSC支持配置帧的转发模式，这直接决定跨框流量的路径。
- 本地优先转发，也叫Local Prefer转发。流量尽量在本地成员交换机完成转发，只有目的地址在远端成员上时才跨VSC链路。适合南北向流量为主的场景，比如大部分流量是服务器到网关、服务器到上联出口，这种模式跨框带宽占用小，时延也更低。
- 跨框转发。流量统一进入转发面后按转发表决定出端口，不一定本地优先。适合东西向大流量且分布均匀的场景，但会吃掉不少VSC链路带宽。
大多数业务我建议选择本地优先转发，配置前先想清楚自己的流量模型，别随手选。
2.4 版本与License前置检查
VSC要求所有成员交换机的软件版本一致，最好是同型号同BootROM版本。版本不一致在运行中可能不会立刻出问题，但一旦触发主备倒换或配置同步，差异命令会被覆盖或不被识别，故障定位难度直接翻倍。
同时要检查VSC授权是否已激活。部分型号的VSC功能需要License，没有授权就开启会报错或者功能受限。我习惯在配置前执行show license确认，省得配到一半才发现授权缺失。
2.5 VSC链路端口的选择
VSC链路最好是独立的万兆或更高带宽端口，不要和业务口混用。常规经验是VSC链路的总带宽不建议低于上行业务收敛带宽，否则高峰期跨框流量可能把链路打满，影响数据转发。
端口准备好之后还要做光模块自检，检查收发光功率是否正常，别拿一根脏光纤做完互联，上线后再断链就头大了。
3. 配置实例：从物理接线到逻辑设备生效的完整过程
下面以两台同型号中兴交换机做汇聚VSC为例，逐步演示配置过程。命令以常见软件版本为例，不同版本字段可能有差异，执行前请对照当前版本命令参考确认。
3.1 物理连接与基础登录配置
先将两台设备断电规范上架，规划好1号机、2号机的物理位置，用光纤把两台设备的VSC链路端口互联。随后恢复供电，用Console线分别登录两台设备，先完成最基础的主机名和管理地址配置。
// 1号机操作 hostname CORE-SW-01 interface mgi0/1/0 ip address 192.168.10.1/24 no shutdown ! // 2号机操作 hostname CORE-SW-02 interface mgi0/1/0 ip address 192.168.10.2/24 no shutdown !管理地址配好后，通过管理网络远程登录，后续操作不需要再频繁插Console线。这个阶段不建议跳过，因为VSC配置过程中可能会触发设备重启或端口初始化，远程管理和Console双通道都能用得上的话，后续操作容错率高很多。
3.2 创建VSC域并协商主备角色
VSC的核心配置在1号机上进行，2号机后续会自动同步。首先是开启VSC功能并创建域。
vsc enable vsc domain 1配置完成后，成员交换机会通过VSC链路协商主备角色。默认情况下先启动的设备会成为主设备，如果想指定某台设备为主，可以通过调整优先级来控制。比如想让1号机稳定担任主设备，可以配置较高的优先级。
vsc priority 200 vsc device 12号机同样开启VSC功能，加入同一个域。
vsc enable vsc domain 1 vsc priority 100 vsc device 2这里vsc device的作用是固定成员编号，防止设备重启后编号漂移。优先级高的成员会成为控制主设备，承载控制面的处理工作；另一个成员则处于热备状态，同步所有配置和转发状态。
3.3 配置VSC链路端口
接下来要把选定的物理端口加入VSC链路。这部分配置要在每台成员设备上各自完成，同时把对端端口也加进去。这里以1号机端口gei_1/1/1和gei_1/1/2、2号机端口gei_2/1/1和gei_2/1/2为例。
// 1号机配置 interface gei_1/1/1 vsc-port ! interface gei_1/1/2 vsc-port ! // 2号机配置 interface gei_2/1/1 vsc-port ! interface gei_2/1/2 vsc-port !把端口配置为vsc-port后，该端口不再承载普通业务，专门用于成员间通信，包括控制消息和跨框数据转发。配置完成后VSC会开始协商，正常情况下两台设备会建立集群关系。
3.4 配置分裂检测，解决最危险的“双主”场景
VSC最危险的故障是两台成员设备之间的VSC链路全部中断，此时两台设备失去联系，都认为自己还是原来那台逻辑设备，继续同时转发和管理，也就是“双主”脑裂。此时下联交换机如果还在正常转发，网络就可能出大问题。
解决办法是配置分裂检测机制，也就是MAD检测。中兴设备常用专用链路方式，用一根独立的网线或光纤直连两台设备的管理口或专用检测口，一旦VSC链路中断，两台设备通过该链路感知对端仍然存活，从而主动关闭备份设备的业务端口，避免出现双主。
vsc mad enable interface mgi0/1/1这里用的是mgi0/1/1作为MAD检测接口，前提是两台设备之间已经用独立的网线或光纤连接了这个接口。MAD链路必须是独立链路，不能和VSC链路共享同一根物理线路，否则VSC断了，MAD也必然断了，检测就失效了。
3.5 业务配置：只需在主设备上执行一次
VSC生效后，业务配置只需要在主设备上执行，系统会自动同步到备设备。比如配置VLAN、VLAN网关和跨设备链路聚合，都在主设备上完成。
vlan 100 name Server-Vlan ! interface vlan100 ip address 192.168.100.254/24 ! interface gei_1/1/10 switchport access vlan 100 ! interface gei_2/1/10 switchport access vlan 100 !注意这里直接引用了gei_2/1/10也就是2号机的端口，在主设备上一样可以配置，这是VSC配置同步的便利性。如果想配置跨设备链路聚合，让服务器双网卡同时工作，则用聚合口把两台设备的端口绑在一起。
interface smartgroup1 switchport trunk allow vlan all ! interface gei_1/1/10 smartgroup 1 ! interface gei_2/1/10 smartgroup 1 !这样服务器做双归接入时，两条物理链路属于同一个聚合口，同时转发，并且任一台成员设备故障，链路依然通过另一台转发。VSC加跨设备链路聚合的组合，是虚拟化集群接入的标准姿势。
3.6 保存配置并确认同步状态
配置完成后，在主设备上保存配置，并确认配置已同步到备设备。
write show vsc configuration sync-status看到同步状态正常后，再核对一遍两台设备的启动配置，确保所有业务配置都已在备设备上生成。这里有个细节：VSC配置同步有方向性，平时修改配置都应在主设备上进行，如果在备设备上直接修改，下次同步时可能被主设备的配置覆盖掉，这一点全团队都要知道，别各改各的。
4. 验证与排障：怎么看集群健康度，怎么做倒换测试
配置完成后不等于工作结束，验证这一步最能反映集群是否真正健康。VSC的验证分三层：控制面状态、数据面状态、故障倒换能力。
4.1 查看集群成员和角色
登录主设备，执行下面命令确认成员状态。
show vsc status show vsc device正常状态应该是两个成员都处于“正常工作”状态，角色分别为主备。如果某个成员显示“离线”或“协商中”，需要检查VSC链路端口状态和光模块收发光。
4.2 查看VSC链路健康度
VSC链路是集群的生命线，需要单独看端口状态、带宽利用率和错误计数。
show vsc link-status show interface gei_1/1/1重点看两个指标：input errors和output errors是否为非零且持续增长，以及光模块收发光功率是否在正常范围。链路有误码但没断，是最容易忽略的隐患，它不会直接触发倒换，但会悄悄增加跨框转发时延。
4.3 主备倒换测试
验证集群可靠性最直接的方式是主动做一次倒换测试，确认备机可以无缝接管。
vsc switchover执行该命令会强制控制面切换到备设备，此时业务应该无感知或只有极短的中断。测试时要在下联设备上持续ping网关地址，观察倒换过程中的丢包情况。正常情况下丢包应控制在个位数以内甚至为零，如果出现明显丢包，需要检查VSC链路带宽和转发模式。
倒换完成后再次查看show vsc status，确认新的主备角色分配正常，再观察一段时间确认业务无异常。
4.4 MAD分裂测试
找一个维护窗口，拔掉两台设备之间的VSC链路光纤，模拟最极端的分裂故障。
show vsc mad status拔掉VSC链路后，MAD机制应触发，备份设备自动关闭业务端口并进入“分裂检测”状态，主设备继续正常转发业务；恢复VSC链路后，备份设备重新拉起端口，自动回归集群并同步配置。这个测试我不敢说每次都能一次通过，但测试通过后对于整套方案的信心会足很多。
4.5 常见故障定位速查表
| 故障现象 | 排查思路 | 定位结果 |
|---|---|---|
| 成员设备反复重启 | 检查VSC链路端口是否正常协商、光模块收发光 | 大概率是物理链路质量差 |
| 配置同步不生效 | 确认修改操作是否在主设备执行 | 在备设备上做的修改被覆盖 |
| 倒换时业务中断明显 | 检查VSC链路带宽利用率、转发模式 | 跨框流量打满VSC链路 |
| 分裂检测未触发双主 | 检查MAD链路是否被误拔或未配置 | 缺MAD链路或配置失效 |
| 成员编号漂移 | 检查vsc device是否已配置 | 未固定编号导致接口命名变化 |
5. 实战踩坑记录：VSC上线后最容易翻车的几个细节
5.1 VSC链路被业务流量打满
之前有一次上线后某段业务间歇性丢包，查了一圈，发现VSC链路的利用率长期超过90%。原因很直接，VSC链路用的端口带宽只有万兆，而上联业务流量峰值远超这个数，跨框流量一多就拥塞。后面扩容了VSC链路，加了多组端口做链路聚合，丢包就消失了。
经验是VSC链路带宽宁可配大不要配小，并且要纳入监控，设置利用率告警阈值，比如超过70%就通知排查，而不是等业务出现感知才去查。
5.2 版本不一致，升级过程把备机升级挂了
有一次做版本升级，计划是先升备设备、再倒换、再升原主设备。结果备设备升完重启后起不来，排查发现备设备原来的BootROM版本和主设备不一致，升级包只更新了系统版本，BootROM没跟上，导致备设备重启后引导异常。
回滚后老老实实把两台设备的BootROM先对齐，再重新走升级流程，才顺利完成。此后我养成了一个习惯：任何两台设备组VSC前，先对比软件版本、BootROM版本、补丁版本，三个全部一致才允许接入集群。
5.3 MAD检测链路被误拔，差点脑裂
MAD检测链路用的是管理口之间的一根网线，走线的时候和一堆管理网线绑在一起。有一次运维清理线缆，顺手把这根线拔了，当时没注意，后来VSC链路真的中断了一次，两台设备同时进入主状态，配置各走各的，整个网络乱了一阵子。
后来我要求MAD链路单独走线、单独标签，并在交换机和监控系统里做了链路状态告警，只要MAD链路断开就立即通知。VSC链路和MAD链路这种关键连接，细节上多花十分钟，故障时能省好几个小时。
5.4 在备设备上改配置，被同步覆盖
团队里有同事习惯登录某一台设备操作，直接在备设备上改了一个接口配置，结果下次主设备配置刷新时，改动直接被覆盖了，业务没有生效还难排查。VSC的配置同步是有方向的，主设备是配置源，所有改动必须在主设备上操作，备设备上的配置只作为同步副本。
5.5 断电重启后接口编号漂移
有一段老设备在重启后出现接口命名变化，原因是没固定vsc device编号，系统重新分配成员编号后，所有带编号的接口配置全部对不上。监控脚本里写的是旧编号的接口，结果全部失效。后来把所有VSC域的设备都固定了编号，并配合配置备份，这个问题再没出现过。
6. 集群不只是“一台设备”：后续优化与运维建议
6.1 跨设备链路聚合配合虚拟化接入
VSC的上层最佳搭配是跨设备链路聚合（也常被称为M-LAG或双活网关），让服务器或下联交换机通过聚合口双归接入，两条链路同时转发。这个组合能把可靠性从“设备级冗余”再提升到“链路级负载均衡”。
配置聚合口时注意两端成员设备的链路参数要一致，包括速率、双工、允许通过的VLAN，否则聚合协商可能出问题。
6.2 与上层路由协议的联动
VSC作为汇聚或核心时，上联通常会跑OSPF或BGP。VSC对外是一台逻辑设备，上联设备看到的是一个邻居、一个Router ID，不再需要为主备各配一套路由会话。配合网关虚拟化，无论是上联路由器还是下联交换机，配置都能大幅简化。
6.3 监控体系要覆盖到VSC内部
VSC虽然对外是一台设备，但对内仍然是两台物理设备。监控系统不建议只盯逻辑设备本身，还要分别监控两台成员设备的CPU、内存、VSC链路流量、MAD链路状态。否则某台成员已经异常，但只要主设备还在转发，监控看起来就一切正常，隐患一直潜伏到故障发生。
6.4 定期做倒换演练
VSC配置完成后不是一劳永逸的，我建议每个季度做一次主备倒换演练，确认备份设备随时可以接管。演练既验证设备状态，也能验证团队的操作流程是否还熟悉。真正故障来临时，所有人的肌肉记忆都是从平时演练中来的。
我在实际项目里体会最深的一点是，VSC带来的不只是网络架构的简化，更是运维心态的改变。以前做割接总是提心吊胆，现在两台设备是一台逻辑设备，配置、升级、倒换的复杂度都降了一个量级。如果你正在设计核心或汇聚的冗余方案，VSC值得好好尝试。
