1. 集群CSS到底是什么：一台交换机干不了的活，两台一起干
做数通维护这么多年，只要涉及到核心交换机或者数据中心网关的部署，几乎绕不开华为的CSS集群。不少刚接触的朋友一听"集群"两个字就以为是什么复杂的分布式框架，其实它做的事情非常朴素：把两台物理交换机通过专门的接口和线缆连起来，让它们从控制平面到转发平面都像一台交换机一样工作。
我当年第一次在现网碰CSS，是某公司机房要上两台框式交换机做核心，业务又要跑VRRP（虚拟路由冗余协议）做网关冗余。领导觉得VRRP两台设备总有一台在闲置，带宽利用率太低，就让我研究一下能不能把两台设备当成一台用。这就是CSS最典型的场景：两台物理设备虚拟成一台逻辑设备，网络里其他设备只看到一个邻居、一条链路，而转发面却拥有两台设备的全部端口和带宽。
CSS的全称是Cluster Switch System，翻译成中文叫集群交换系统，是华为在园区网和数据中心网络里的核心竞争力之一。它与传统的堆叠技术相比，不只是把两台设备用堆叠线缆绑在一起那么简单。CSS要求参与集群的成员设备必须同型号、同版本，通过专用的集群接口连接后，设备会选举出主设备和备设备。整个系统对外呈现为一个管理IP、一个MAC地址，所有端口资源统一管理，每个端口都可以配置VLAN、路由、策略，无需区分它究竟属于哪台物理成员。
对网络设计人员来说，这种"虚拟成一台"的能力意味着网络拓扑可以大大简化。原先双核心跑VRRP时，下联交换机要起两个VLAN接口做网关主备，还要调优先级、占位计时器，麻烦不说，主备切换时总有一定延迟。而CSS把两台物理设备变成一台逻辑设备后，下联设备只需要起一个三层网关，链路聚合跨两台物理成员的端口绑定在一起，任何一台成员故障，流量无缝地切到另一台，不需要协议重新收敛。
所以，CSS适合谁来用？我认为是最适合两类需求：一类是核心网络要求高可用、但不愿意承担传统双机方案配置复杂度的场景；另一类是业务增长快、需要横向扩展转发容量和端口密度的场景。前者是"省心"，后者是"省钱"——毕竟两台旧设备通过CSS组合出来的能力，往往比直接换一台更高端的新设备更划算。
2. 核心机制拆解：CSS是怎么把两台设备"焊"在一起的
2.1 集群连接的物理基础：堆叠口和业务口
CSS的物理连接主要有两种方式：一种是用专用的堆叠口（比如华为框式设备上的主控板自带堆叠口）通过堆叠线缆直连；另一种是利用高速业务口（比如10GE、40GE、100GE接口）做集群连接。不同的产品形态支持的连接方式有区别，早期S9700、S12700这类框式交换机通常有专门的CSS接口，而盒式设备如S5731-H、S6730-H则更常用业务口堆叠。
用堆叠口做集群的优势是控制信道和数据信道物理隔离，稳定性高，不占用业务端口资源。缺点是你得先有相应的堆叠线缆和可用的堆叠口，而且堆叠口的带宽一般固定，比如40GE或100GE，一旦设备型号只支持某个速率，你没法灵活调整。用业务口做集群则灵活得多，可以把任意高速端口划为堆叠物理成员端口，但需要注意的是，业务口在做堆叠时会占用端口，并且端口上的业务配置会清空，必须提前规划好哪些口承担集群互联，哪些口留给业务。
我在实操中见过不少人把集群接口和业务接口混在一起，结果设备一重启，端口角色变了，配置全乱。记住一个原则：集群连接端口一旦创建，它就不属于任何业务，只属于集群系统，端口上的所有配置都会失效。
2.2 主备角色与系统选举机制
CSS集群由两台设备组成后，系统会自动选举一台作为主设备（Master），另一台作为备设备（Standby）。主设备负责整个集群的控制管理，运行协议栈，管理成员设备的状态；备设备则同步主设备的配置和状态，转发平面同时工作，数据流量不会因为主备关系而阻塞。
选举的优先级比较规则朴素：优先比较集群优先级，数值越大越优先；如果优先级一样，比较MAC地址，越小越优先；如果还一样，比较设备ID，越小越优先。这和STP根桥选举很像，很多擅长二层交换的朋友就能迅速理解。
最容易被忽略的是：主备角色是全局概念，但不同业务板卡在主备设备上的角色可以不一样。比如，主设备上有一块板卡故障可能引发整机主备切换，但备设备上的板卡故障则更多的是本板卡的业务受影响。所以CSS虽然把两台设备变成一台逻辑设备，内部的冗余逻辑依然遵循"主控备份、转发分布"的原则。
2.3 跨设备链路聚合：CSS最核心的价值点
如果只是把两台设备堆成一个逻辑设备，那意义不大。CSS真正的杀手锏是跨设备链路聚合（Eth-Trunk跨成员绑定）。下联交换机可以创建一条Eth-Trunk，把两个物理成员端口分别接到CSS集群的两台物理设备上，然后在Eth-Trunk上配置二层、三层接口以及网关。这样从下联设备看，它连接的是一个逻辑设备，链路聚合的主备和负载分担都交给Eth-Trunk处理；从CSS集群看，它用两台设备的端口共同承载业务，任何一台设备故障，聚合链路自动把流量迁移到另一台设备端口上，几乎不中断业务。
这条跨设备的聚合链路天然解决了传统VRRP方案中"主设备在用、备设备在睡"的浪费问题。在CSS方案里，两台设备的转发芯片都处于Active状态，流量可以hash到两端，整体吞吐量接近两台设备之和。
2.4 双主检测：防的是"脑裂"而不是"分裂"
CSS在正常工作时只有一个主设备。但如果集群链路发生故障，两台设备都认为对方不可达，就会各自独立启动，争夺主角色，导致集群形成两个主设备，也就是俗称的"双主"或"脑裂"。这会产生灾难性后果：两台设备都接入了同一个二层网络，以相同的MAC地址对外发送报文，造成MAC地址表震荡、广播风暴、业务流量来回翻转。
为了防止双主，华为CSS用了一套双主检测机制，最常见的是直连检测和业务口检测。直连检测是主备设备之间单独拉一根检测线，专门用来探测集群链路状态。业务口检测是复用业务口的链路与对端设备形成检测通道，常见做法是把两台CSS成员分别与上联或下联的汇聚交换机连接，通过这些业务口发送检测报文，一旦超过超时时间没有收到对端的检测报文，就判定集群链路中断，备设备会关闭自己的所有业务端口，进入"备机拒发"状态，避免双主冲突。
我调试的时候特别爱看双主检测是否正常，因为这是CSS可靠性里最容易被忽视的环节。有些现场图省事没有配置双主检测，或者检测通道配置了错误的接口，结果集群链路一断，网络直接瘫痪。
3. 实操解析：从零配置一套华为CSS集群
3.1 配置前检查清单
用一句话总结CSS配置前的准备：物理一致、软件一致、拓扑清晰。
- 成员设备的型号必须一致，主控板、业务板型号及版本一致，最好连固件补丁都一致。
- 设备软件版本必须相同，如果版本不同，建议先升级到相同版本再做集群；否则可能因为版本差异导致CSS组建失败或功能异常。
- 规划好集群连接端口，建议使用两个或以上的集群链路做冗余，如果条件允许，用独立的堆叠口最佳。
- 所有配置操作建议在设备未接入业务网络前进行，避免组网过程中产生环路。
- 备份每台设备的独立配置。组建CSS后，两台设备原来的配置会合并，如果有冲突项，可能覆盖或者报错。
3.2 配置核心步骤演示
我以常见的框式交换机为例，假设两台设备分别叫A和B，我准备用设备A的10GE1/0/1和10GE1/0/2集群口与设备B的10GE1/0/1和10GE1/0/2集群口相连，同时配置双主直连检测。整个过程分几步：
第一步：在A设备上配置集群连接端口并启用集群。
sysname CS_A interface Eth-Trunk 1 trunkport 10GE1/0/1 trunkport 10GE1/0/2 quit css css enable css id 1 css priority 100
系统会提示需要重启生效，重启后A设备就进入了CSS模式，等待与B建立集群。
第二步：在B设备上做同样的配置，但设备ID和优先级与A不同。
sysname CS_B interface Eth-Trunk 1 trunkport 10GE1/0/1 trunkport 10GE1/0/2 quit css css enable css id 2 css priority 50
也需要重启。重启后两台设备如果集群线缆连接正常，应该能协商成功，通过display css status可以看到集群状态正常。
这里有个关键点：CSS模式下，配置是合并而不是覆盖。A和B设备如果原来有管理IP，在合并时可能出现IP冲突，所以建议一开始给每台设备的管理IP设置不同地址，待到集群建立后再统一重新规划。这点坑我踩过，两台设备明明配置正常，但一重启后管理地址互相冲突，登录不上去，最后只能接console口紧急处理。
第三步：进入CSS视图，配置主设备的全局管理接口和业务逻辑。
interface VLANIF 4001 ip address 10.10.10.1 255.255.255.252
CSS集群建立后，主备设备的全局配置是同步的，只需要在主设备上配置即可。集群内部会自动把配置同步到备设备。
3.3 双主检测配置
为了保证集群链路故障时的安全，我建议立即配置双主检测。直连检测方式最简单，在主备设备之间找一根专用的检测线，比如用Eth-Trunk中的一对独立端口做直连检测。
css dual-active detection direct
这个命令配置后，系统会默认使用指定的用于直连检测的接口。也可以用业务口检测方式，需要通过eth-trunk和对端设备配合，复杂一些，但不需要单独拉线。小型组网用直连检测就够了。
3.4 验证集群状态
配置完，使用这几个display命令是每天必看的：
- display css status：查整体集群状态，主备角色、成员数、集群连接状态。
- display css device：查成员设备的详情，包括设备ID、优先级、MAC地址。
- display css channel：查集群链路的状态和带宽，这里能看到集群口是否UP。
- display eth-trunk 1：查看跨设备聚合链路是否正常。
如果看到集群状态显示为"Running"，成员设备都正常，就说明组建成功。我还会进一步用display css binding查看主备设备上的板卡绑定关系，确保各板卡都在正常工作。
4. 常见故障与排查技巧实录
4.1 集群链路协商失败
场景：两台设备配置完成后，display css status显示成员设备离线或协商失败。排查思路：先用display css channel查看集群链路的物理状态，如果显示Down，大概率是线缆问题或光模块问题。如果是光模块，看一下收发光功率，CSS链路对光模块质量要求高，模块参数劣化就会导致协商不稳定。还有一种常见原因是端口类型配置成了普通业务口，没有重新加载为集群口，这在业务口做集群时很常见，确认起来很简单：在接口视图下查看端口属性，如果显示为Stack或CSS端口，就对了。
4.2 双主检测误判导致端口被强制关闭
有一次现网故障让我印象很深：集群物理链路断开后，双主检测端口仍然UP，备设备没有及时关闭业务端口，结果两台设备同时转发流量，下联交换机MAC表疯狂跳动。后来查原因，是双主检测线接到了中间一台傻瓜交换机上，检测报文经过交换机后，备设备能收到主设备的检测报文，但检测通道的物理可靠性很差，问题发生后没有第一时间触发拒发。
这个教训是：检测通道一定要可靠、独立，尽量点对点直连，不要让检测报文经过第三方设备。如果是业务口检测，也要确保检测链路和集群链路是不同路径，这才是真正的冗余。
4.3 跨设备链路聚合流量不均
配置好CSS后，发现跨设备Eth-Trunk的负载不均衡，一条物理链路流量高，一条低。排查思路是看哈希因子是否合理。Eth-Trunk默认按报文的源MAC目的MAC、源IP目的IP做哈希，如果业务报文格式比较单一，比如全是同一种源IP到目的IP的流量，哈希结果就会集中到一个成员口上。解决办法是修改Eth-Trunk的负载分担方式，改为根据VLAN或二层信息进行hash；或者改变hash算法。实际操作中，可以在Eth-Trunk视图下使用load-balance命令调整，最好配合不同业务的流量特征来定，不能盲改。
4.4 版本升级与平滑迁移
CSS集群升级比较方便，通常只需要将备用设备先升级，然后主动执行主备倒换，再升级新的备用设备。核心点在于升级前确认集群的配置一致性、备份配置文件，并确保升级期间业务端口不会全挂。我习惯用issu（In-Service Software Upgrade）方式在框式设备上做，它能做到不中断业务的平滑升级。如果你的设备版本比较老，不支持issu，那就老老实实按传统方式做，但一定要在业务低峰期操作，做好回退预案。
5. 关于CSS，我的几条个人经验
CSS技术本身不复杂，但真正考验功力的是实施细节。我给想做或已经做了CSS的朋友几条基于经验的心得：
第一，不要为了省线缆省端口而使用单条集群链路。任何情况下，集群链路必须冗余，否则一次光口松动就是全网故障。第二，双主检测不能少，一定要配置。即使你的组网觉得不会发生集群链路故障，也要考虑模块老化、灰尘污染等不可控因素。双主检测是最后一道保险，别省。第三，每次变更前先备份配置，CSS的配置合并逻辑和单台设备不同，改坏了容易牵连两台设备。
另外，CSS设备上使用SNMP、NetStream等网管功能时，网管地址和业务地址要分清楚。主设备故障切换后，备设备接管管理角色，网管平台需要能自动识别，否则会误报设备离线。
CSS还有一个容易被忽略的白皮书细节：集群系统只是两台设备虚拟成一台，但在故障切换时，转发面上仍存在一定切换时间，只是比传统协议收敛快得多。所以如果你的业务对毫秒级无缝切换有极致要求，还是需要叠加硬件级冗余方案。CSS适合的是高可用、高性能的核心场景，但不是所有网络问题的万能药。
做技术的都知道，纸上谈兵不如现场练手。有条件的朋友可以找两台支持CSS的设备做测试，普通盒式设备做堆叠也行，原理与CSS一致。自己把配置、断线、倒换完整跑一遍，比看十篇文档都管用。等你能不看文档把双主检测、跨设备聚合、升级回退一次做对，才算真正吃透了集群CSS。
