机房里的核心设备，最怕的不是某一块业务板卡悄悄亮红灯，而是两台核心交换机在关键时刻没人能顶上。传统主备方案里，备机常年空转，切换时间按秒算，业务部门早就开始打电话了。我第一次接触华为的集群CSS，就是在一次核心网改造项目里：两台框式交换机，用一组集群线缆把控制面拉起来，重启之后变成一台逻辑设备，对外只看到一个管理IP、一套配置，转发面却是两台一起扛。这个思路解决的不只是“备机浪费”，而是把主备切换从“秒级”压到了“毫秒级”。
这篇文章不打算讲太多PPT层面的概念，重点放在：CSS到底是什么、为什么值得用、实施前怎么规划、配置命令怎么敲、双主检测怎么配，以及我在实际项目里踩过的坑。想给核心网络做双机冗余，又不想让备机闲着的人，可以参考着看。后面所有命令基于华为较为普及的VRP平台，具体型号和版本有差异，我会在关键地方标注。
1. 先搞清楚CSS到底是什么
1.1 集群系统的本质
CSS全称Cluster Switch System，是华为在企业网核心和数据中心场景里主推的交换机虚拟化技术。通俗讲，就是把两台物理交换机通过专门的集群链路连接起来，在逻辑上合并成一台交换机使用。网络里的其他设备不会感知到背后有两台设备，它们看到的只是一台交换机、一个管理地址、一套配置。
用生活里的例子类比：两个独立的售票窗口，一个在左边一个在右边，排队的人要猜哪个窗口人少。CSS的做法是把两个窗口打通，改成一个大厅、一个入口，里面两个售票员一个主一个备，外面的人永远只面对一个入口。主售票员出问题，备售票员无缝顶上，排队的人甚至没感觉到停顿。
但要注意，CSS不是简单的“设备主备”。传统主备方案中，两台设备各自独立运行、互相同步配置，切换时存在状态不一致的风险；而CSS在控制平面上就是一台设备，只是硬件上分布在两个机框里。
1.2 它真正解决了什么问题
老牌的主备方案存在三个让运维很头疼的问题：
- 主备切换时间长：健康检测、状态迁移、路由收敛，一套流程走完，几秒钟过去了，对敏感业务来说已经算故障。
- 备机利用率低：备机整年不转发业务流量，投资回报率很低。
- 管理成本高：两台设备两套配置，升级、审计、变更都要双倍工作量。
CSS把这几点都改掉了。控制平面一主一备，主设备挂掉时备设备直接接管，切换时间大幅缩短；转发平面两台设备一起工作，带宽资源不被浪费；管理上只有一套配置，登录任何一个成员都能管理整个集群系统，配置统一下发，自动同步到对端。
另一个很实用的价值是跨设备Eth-Trunk。下联交换机可以用一个Eth-Trunk同时连接两台集群成员，把两根物理链路聚合成一根逻辑链路。这样既增加了带宽，又实现了链路冗余，不再需要跑STP去阻塞端口，网络拓扑变得干净许多。
1.3 哪些场景不适合用CSS
CSS不是万能药，我的态度一直是一开始就别神化它。如果你的核心交换机单框容量已经足够，可靠性压力也不大，强上CSS反而引入新的风险点。
比如集群链路本身就是一个故障点。两台设备之间的控制面同步依赖集群链路，虽然有双主检测兜底，但多一个环节就多一套运维工作。再比如，真正的物理隔离要求高的场景，比如等保三级里某些业务要求主备物理独立，CSS把两台设备变成一个逻辑设备，审计上可能说不清楚。
所以我的建议是：流量规模大、业务连续性要求高、希望简化运维的场景，CSS非常合适；单台设备性能富余、维护力量薄弱的小型网络，用传统主备或者干脆单机更实在。
2. CSS的系统架构与关键原理
2.1 控制平面的一主一备机制
集群建立后，两台成员会通过协商选举出一个主交换机和一个备交换机。主交换机的控制平面处理所有协议报文，包括STP、OSPF、BGP、LACP等等，并把协议运行的结果通过集群链路同步到备机。备机的控制平面在线但处于待命状态，不参与协议计算，却始终保持着和主设备一致的协议状态。
这里有个容易混淆的点，CSS不是传统意义上的两台设备各自跑协议再互相同步，而是一个逻辑设备内部有两个“半脑”，一个在工作，一个在热备份。所以从外部看，协议邻居会话只有一个，MAC地址表只有一份，ARP表只有一份。这种架构带来的好处是切换时外部网络几乎感知不到协议变化，因为协议邻居关系本来就不存在断裂。
出故障的时候，备机的控制平面接管协议计算，转发平面本来就在工作，所以业务中断窗口很小。这也是为什么很多核心网络改造愿意上CSS，它不只是冗余，而是一种更高级的一体化设计。
2.2 转发平面的跨框协同
数据转发这块，CSS采用分布式架构。流量从成员1进来，如果目的端口恰好落在成员2上，那么报文会通过集群链路传给成员2，再由成员2完成转发。集群链路因此承担两类流量：控制面的同步报文，以及跨成员的转发流量。
所以集群链路的带宽规划不能拍脑袋。如果你的网络东西向流量大，比如服务器之间的备份、虚拟机迁移，这流量跑到对端成员的概率非常高。集群链路带宽不足时，跨框转发就会出现拥塞和丢包，业务口看起来全正常，但流量一大就掉链子。
我习惯在方案设计阶段就把东西向流量测算进集群链路的带宽需求里，而不是把集群链路单纯当成一根“同步线”。框式交换机如果支持多条集群链路，尽量用满，既提升带宽又增加冗余。
2.3 集群链路的设计与布线
集群链路可以是专用的集群线缆，也可以是普通光纤端口配置成的逻辑集群端口。不同产品系列差异很大：框式交换机往往有专门的集群口，盒式交换机则常常占用业务口来复用。
布线形态有两种常见方式：
- 环形连接：成员1的两个集群口分别连接成员2的两个集群口，形成一个环。任何一条链路断了，另一条还能兜住控制面同步，可靠性高。
- 链形连接：成员1的一个集群口连接成员2的一个集群口，单条链路，简单但存在单点风险。
华为的官方建议基本都推荐环形。我实际操作时还有个习惯：两条集群链路走不同的物理路径，最好分布在不同板卡上。避免出现机柜同一侧的光纤被一起拉断，或者同一块板卡故障导致两条链路同时失效的尴尬。
2.4 双主检测机制：防止脑裂的最后一道防线
这是CSS里我最看重的设计。假设集群链路彻底断开，两台设备之间控制面失去联系，此时如果它们各自都还认为自己是主设备，就会同时处理业务。于是同一个IP地址出现两台交换机都在响应，MAC地址漂移、环路、ARP冲突会全部涌上来。这就是俗称的“脑裂”。
华为的应对机制是双主检测，英文缩写DAD。集群建立后，两台成员之间除了集群链路，还会额外建立一条检测链路。当集群链路断开时，检测链路仍然能把两台设备连在一起，让双方发现彼此都还活着，于是其中一台自动进入禁用状态，整机业务接口全部关闭，避免对网络造成二次冲击。
检测链路有两种形态：
- 直连方式：拿一个专用的业务口或管理口把两台设备直接连起来，简单可靠。
- 中继方式：通过中间交换机转发检测报文，适合两台设备物理距离较远、无法直接拉线的场景。
直连方式配置少、故障点少，但占用一个接口；中继方式灵活，但依赖中间链路的健康状态，需要额外规划和监控。这个机制不能省，生产环境里我从来不开玩笑说“集群链路够稳，不用配DAD”，一旦缆线松动或者光模块劣化，没DAD就是全网事故。
3. 实施前需要完成的准备
3.1 硬件形态与集群口规划
以华为中高端框式交换机为例，CSS有两种实现路径：一种是专用的集群主控板，配合专用集群线缆；另一种是在业务板上用高速接口做逻辑集群口。选型阶段要翻设备手册，确认自己的主控板、业务板是否支持集群，以及最多支持几条集群链路。
我的经验是，预算允许的情况下优先选带专门集群口的框式交换机。专用集群口不占业务接口，线缆是定制的，信号质量有保障。盒式交换机也能做CSS，但会吃掉两到四个业务口，在接口本来就紧张的网络里，这个代价有点肉痛。
3.2 业务口与集群口的冲突处理
这是实施前最容易被忽略的一步。同一个物理端口，不是你想让它做业务口就做业务口、想做集群口就做集群口。把业务口改成集群口，原端口上的业务配置会全部失效。而且不同版本的软件对端口类型的切换要求还不一样，有的直接报错，有的静默覆盖。
所以规划要分两步走：第一步，确定哪些端口作为集群口，优先选在设备两侧、不同板卡上的端口，保证冗余；第二步，把这些端口原本的业务配置提前梳理出来并清理干净。不要等配置做到一半，系统提示“端口已被业务占用，无法创建集群口”，那时候再回头处理就很被动。
3.3 版本、License与兼容性核对
两台设备做集群有一个硬性前提：软件版本一致。如果两台设备的版本不同，集群协商很可能失败，或者即使协商成功，某些特性表现也不正常。我见过某次维护，一台设备在V200R003、另一台在V200R005，组集群后配置能同步，但新版本的特性在老设备上直接不生效，排查了整整半天才定位到版本差异。
建议实施之前把两台设备都升级到同一基线版本，再开始组集群。License方面也要提前确认，特别是双主检测的中继方式、M-LAG这类高级特性，部分功能需要额外授权。现场发现功能被锁，是很尴尬的。
3.4 规划设计表
我每次做CSS项目都会先拉一张规划表，把关键参数写清楚，后面实施时照着执行就行。
| 项目 | 成员1 | 成员2 | 说明 |
|---|---|---|---|
| 成员ID | 1 | 2 | 决定逻辑槽位号，业务上线前定死 |
| 集群优先级 | 高 | 低 | 高者当选主设备 |
| 集群链路端口 | 所在板卡/端口号 | 所在板卡/端口号 | 两侧要对称 |
| 集群链路数量 | 2 | 2 | 环形连接 |
| 双主检测方式 | 直连 | 直连 | 占用专用端口 |
| 双主检测端口 | 端口号 | 端口号 | 可以复用管理口 |
| 业务上联口 | 规划好 | 规划好 | 集群化后编号会变化 |
这张表填完，网络的逻辑结构已经清楚了，后面只是把规划翻译成命令行。
4. 一步步完成CSS配置
4.1 物理连线：先接线路再配软件
接线之前确认设备已经断电或者端口没有承载业务。专用集群线缆一头接成员1的集群口，另一头接成员2的集群口。如果做环形连接，就再用一根线把两边第二组集群口也连起来。连接时注意线缆型号和端口区块的对应关系，别插错。
我习惯在两端贴上标签，边接边记录在规划表上。集群链路不像业务口那样有明确的指示灯可以一眼看出是否正常，线缆接错了往往要等配置完成、重启之后才能发现，那时候排查起来很费劲。
4.2 配置成员ID与优先级
设备处于单机状态下，登录设备A，设置成员ID为1，优先级调高。设备B设置成员ID为2，优先级调低。以华为较新版本的VRP为例：
system-view set css id 1 set css priority 200另一台设备执行：
system-view set css id 2 set css priority 100成员ID的作用非常关键，它决定集群建立后这台设备在逻辑架构中的“槽位号”。比如成员1的10GE接口，集群化后会显示为10GE1/0/1；成员2的接口就会显示为10GE2/0/1。如果ID规划不当，调整之后所有端口编号都会变化，涉及这些端口的配置、策略、网管监控全要跟着改一遍。
优先级的作用是选举主设备。数值越高，越有可能在集群协商时成为主交换机。原则上应该把硬件性能更稳、后续方便维护的那台设成高优先级。
4.3 配置集群链路
框式交换机上，需要把物理端口配置为集群端口。命令大致如下：
system-view interface css-port 1/0/1 port link-type css quit interface css-port 1/0/2 port link-type css quit成员2上执行同样的配置，注意端口编号里要使用自己的成员ID。
盒式交换机的命令形态可能会不同，比如部分型号使用下面的形式：
system-view interface stack-port 1/1 port link-type css quit不同产品系列的命令差异比较大，以设备配套的手册为准。配置完成后立即保存配置，接下来要重启设备，如果配置没有保存，后面的操作等于白做。
4.4 切换到集群模式并重启
集群链路配置好后，还需要把设备运行模式从“单机模式”切换为“集群模式”：
system-view set css mode css系统会提示该操作需要重启设备生效。保存配置后，分别重启两台成员。重启顺序没有硬性要求，但我习惯让优先级高的主设备先启动。设备起来之后，集群链路会进行协商，两台设备开始交换CSS报文，选举主备角色。
重启完成后，需要通过命令确认集群是否建立成功：
display css status display css configuration display device输出信息里能看到成员ID、角色、集群链路状态。如果看到一台设备角色是Master、另一台是Standby，集群链路状态是UP，就说明集群已经成功建立。
4.5 集群状态验证与端口编号确认
集群建立后，再看看业务端口，这时端口编号已经带上了成员ID前缀。比如原来是10GE1/0/1，集群化之后可能变成10GE1/0/1，但成员2上的端口就变成10GE2/0/1。所有涉及成员2端口配置的命令都要用新的编号。
这个阶段我会做几个快速测试：登录集群的管理IP确认能正常访问；从上联口ping下联设备确认转发正常；查看MAC地址表确认是集群统一维护的一份表。确认没问题之后，集群的搭建就算完成了。
5. 双主检测的配置与验证
5.1 直连方式DAD配置
如果两台设备物理位置靠在一起，直连方式是最简单的。直接拿一根网线把两台设备的管理口连起来，然后分别在两台设备上配置：
system-view dual-active detection direct这里有个容易忽略的点：管理口被占用之后，设备的管理通道就没了，需要通过业务口或者带外网络去管理。所以配置之前先想好后续管理走哪条路，别把设备管到“失联”。
5.2 中继方式DAD配置
如果两台设备距离远，或者不想占用额外接口，可以选择中继方式。中继方式的原理是让检测报文穿过中间的交换机网络，两台集群成员之间通过一个逻辑链路Eth-Trunk来传送检测报文。
配置如下：
system-view interface eth-trunk 10 trunkport interface 10ge 1/0/24 quit成员2也要创建编号相同的Eth-Trunk，并把对应的业务口加入。然后开启中继检测：
system-view dual-active detection eth-trunk 10中继链路必须保证有独立的物理路径，不要让检测链路和集群链路走在同一根光缆或同一个中间设备上。如果集群链路和检测链路同时断掉，双主检测就失去了意义。
5.3 模拟故障验证
配置完DAD不能光看状态，一定要在变更窗口做一次演练。演练方法很简单：在保证业务低峰期且做好回退预案的前提下，拔掉集群链路中的一根线。
观察的现象有两个：第一，两台设备是否都检测到了集群链路故障；第二，双主检测是否把备用设备自动置为禁用状态。正常情况下，备机会将所有业务口关闭，整个系统仍然保持单主运行。之后把线接回去，观察两台设备是否自动恢复集群关系。
我在实际操作中测试过多次，这套机制的恢复速度相当不错，前提是检测链路本身健康。如果检测链路经常丢包，建议多做一条冗余检测路径，一条挂掉另一条顶上。
6. 实施与维护中容易踩的坑
6.1 集群模式切换命令找不到
有些型号在普通系统视图下根本没有set css mode css这条命令，需要进入专门的集群配置视图。不同产品系列的命令路径不一样，敲不出来的时候别怀疑设备坏了，先确认设备型号和软件版本，再翻对应的集群配置手册。
这个坑我踩过一次。一台盒式设备，在系统视图下敲set css mode css直接提示未知命令，当时一度以为版本不支持集群。后来才发现这个系列的设备切换到集群模式是通过专门的命令进入集群视图来完成的。多花了大半天查手册，做项目时时间是很贵的。
6.2 集群化之后端口编号全变了
前面反复强调过成员ID的规划，这里讲一个真实教训。某次项目里，实施人员没有提前规划好ID，两台设备默认都是1，集群协商直接失败。临时把其中一台改成2之后，原来写好的下联配置全部失效，VLAN放行、ACL策略、端口描述全要跟着改。
处理办法是：在正式割接之前，把端口映射表完整做出来，把旧的端口号和集群化之后的新端口号一一对应。割接完成后，拿着映射表逐条核对配置，不能靠脑子去记。
6.3 集群链路带宽不足导致转发丢包
有一个典型症状：业务口全部正常，没有告警，但流量一大网络延迟明显升高，甚至出现丢包。排查时注意看集群链路的光口计数，如果发现丢包和CRC错误持续增长，大概率是集群链路带宽被跨框流量打满了。
解决方案有几个：增加集群链路数量，把带宽提上去；或者调整业务部署，把流量尽量控制在成员本地，减少跨框概率。如果是虚拟化环境下的大流量迁移场景，集群链路规划一定要做得更充足。
6.4 集群模式下的软甲升级顺序
集群模式下升级版本，不能两台设备同时重启，否则集群链路断开，业务彻底中断。我的标准流程是：
- 先把备机的业务流量切走，或者使用命令行将备机置为隔离状态。
- 升级备机的软件版本并重启。
- 备机起来之后，执行主备倒换，让升级后的设备接管主角色。
- 升级原主设备的软件版本并重启。
- 两台设备版本一致之后，集群重新协商，业务恢复正常。
如果设备支持ISSU（在线升级），这个流程会简化很多，但ISSU也不是所有特性都支持，操作之前同样要仔细看文档。升级时间选在维护窗口，提前备份配置文件，这是最基本的习惯。
6.5 双主检测误报导致业务被切断
双主检测误报是很少见但后果很严重的故障。检测链路物理端口是UP，但中间交换机的VLAN配置错误，导致检测报文被丢弃。此时集群链路正常，业务也都正常，但设备之间已经失去了DAD通信。一旦集群链路出现短暂抖动，两台设备就可能同时认为自己是主，然后备机自动关闭业务口，造成大面积业务中断。
所以在日常巡检里，不能只看检测端口状态，还要检查检测报文的收发计数。定期执行一下display dual-active detect state，确认两边都在正常收发，这样才能保证这道防线随时可用。
7. 生产环境中的运维实践
7.1 与M-LAG配合使用
CSS之上最常叠加的就是M-LAG，也就是跨设备链路聚合。两台集群成员各出一条物理链路，组合成一个跨设备的Eth-Trunk，和下联交换机对接。下联交换机看到的只是一个普通Eth-Trunk，不知道背后连的是两台设备。
这个组合的优势在于：带宽翻倍、链路冗余、无STP阻塞。配置时注意两台成员上要使用相同的Eth-Trunk编号和成员端口，接口参数也要保持一致，否则跨设备的聚合会话可能协商失败。我习惯在配置完成后，在下联交换机上检查Eth-Trunk的成员端口状态，确认两边的LACP协商都正常。
7.2 日常巡检建议
组了集群之后，巡检重点会比单机多一些。我自己的巡检清单大致是这几个命令：
display css status display device display dual-active detect state display eth-trunk 10 display alarm all每季度至少做一次全量巡检，额外看一下集群链路光模块的收发光功率。光模块劣化是集群断链的隐形杀手，等它真正断了再处理，业务已经被影响了。光功率低于告警阈值时及时更换光模块，成本不高，收益很大。
7.3 变更操作的原则
做网络时间久了，越来越觉得最重要的不是多聪明，而是多守规矩。我给自己定了几个死规矩：任何变更前先保存配置，操作完无论成败都保留现场截图；涉及集群链路的操作一定安排在维护窗口内；拔插线缆必须戴防静电手环；所有命令先在测试环境敲一遍，再到生产环境执行。
有一次，一个小操作只是给集群链路加一条线，结果因为没先在测试环境验证端口类型切换的细节，配置报错后又反复调整，硬是把一个半小时的窗口用完了。从那以后，再简单的变更我也不敢跳过提前验证的环节。
CSS这个技术，从第一次接触到现在，我一直觉得它是一个思路非常清晰的设计。它把两台物理设备的复杂性封装成一个逻辑设备，让网络管理员从繁琐的备机维护里解放出来。但它毕竟也是由物理线路、光模块、软件版本这些环节构成的系统，哪个环节都可能出问题。真正懂得用CSS的人，不是只会把它配起来，而是知道它的边界在哪里、风险在哪里、怎么去验证它是否健康。网络这行当，让业务睡得着觉，比什么都重要。
