在园区网和中小型数据中心里华为S7706这台框式交换机的出镜率一直很高。很多人一搜“CSS”脑子里先冒出来的是前端那套层叠样式表但在网络运维的真实语境里CSS是Cluster Switch System华为的集群交换系统。今天要聊的就是怎么把两台S7706通过集群卡虚拟成一台逻辑交换机把核心设备从“单点故障”变成“设备级冗余”顺带把跨框链路聚合、统一管理这些收益也一并拿下。这篇内容适合正在规划核心网络改造、遇到S7706单机承载压力大、或者准备做核心设备虚拟化但不想踩坑的兄弟。我会把硬件准备、参数规划、完整配置命令、常见排障一条龙讲清楚。集群卡方案和普通的集群线缆方案不一样它不占业务口通过专用卡位互联稳定性和带宽都更让人放心这也是我实际项目里优先选它的原因。下面直接进正题。1. CSS是什么为什么我推荐集群卡方案1.1 CSS的核心原理与业务价值CSS集群的本质是把两台独立的框式交换机通过专用的集群通道连接让它们在控制平面和数据平面上都“合并”成一台设备。对业务来说这就是一台交换机对维护者来说只有一套配置、一个管理IP、一个登录入口。两台S7706组成CSS后几个关键价值是实打实的设备级冗余。一台框故障另一台无缝接管转发业务中断时间可以控制在毫秒到秒级比传统的VRRP主备切换要快得多而且不需要等路由协议收敛。跨框Eth-Trunk。下联交换机或服务器可以同时接到两台框上组成一个聚合链路链路不再受单框故障影响。这个是CSS最吸引人的地方。统一管理。双框合并后登录主框就能看到全局所有板卡和端口配置自动同步不用再维护两台设备的重复配置。说白了CSS解决了“核心设备没法做到全年无休”的痛点。单机坏了就是全网瘫痪CSS让两台设备变成一台逻辑设备坏了一台还有一台。1.2 集群卡方案与集群线缆方案的对比华为的框式交换机做CSS常见有两条路集群卡和集群线缆。我一直推荐集群卡原因在于两者根本不是同一个级别的方案。集群线缆方案用的是交换机业务口或者专用集群口互联线缆通常是专用堆叠线缆物理上比较脆弱容易在维护时被误碰松动。而且它要占用业务端口资源本身业务口就紧张的情况下更不合适。集群卡方案则是通过机框上的专用集群卡位安装集群卡两台设备之间通过高速接口互联不占用任何业务板卡和业务口。从可靠性和带宽两个维度看集群卡都明显占优。做一张表更直观对比项集群卡方案集群线缆方案占用资源专用集群卡槽位不占业务口占用业务口或专用集群口互联带宽高多接口聚合取决于线缆规格物理可靠性卡式安装不易松脱线缆易受外力影响维护友好度高插好后免维护需注意线缆绑扎和标签适用场景核心/汇聚长期稳定的场景临时扩容或预算受限场景我实际项目里遇到的情况是核心交换机一旦上线三五年内很少会去动它物理稳定性比什么都重要。集群卡插上之后就是一个固定设备不用像线缆那样担心绑扎不牢、老鼠咬线、被人踢到。所以但凡条件允许我优先选集群卡。1.3 S7706集群卡的硬件准备与连线思路先说硬件清单。要做两台S7706的集群卡CSS需要准备两台S7706机框且主控板、业务板、电源、风扇等都能正常工作每台S7706各配套一块集群卡具体卡型号以设备硬件手册为准采购时和经销商确认“支持CSS集群的集群卡”集群卡之间的互联光纤或专用线缆数量和长度按机柜内两台设备的距离准备光模块若干根据集群卡接口类型选择匹配的单模/多模模块。集群卡的安装位置是在机框的专用卡槽位不是业务槽位这点和插一块业务板是两回事。安装时要把卡推到位、锁紧扳手确保和背板接触良好。装好后两台设备之间用光纤把集群卡的接口成对连接起来。这里我建议至少互联两条链路形成冗余保护。一条链路断了集群会话还能通过另一条链路维持不至于一断就分裂。连线完成后的第一件事是开机验证两条链路都正常。登录设备执行display device确认集群卡状态是Normal对应的接口物理状态是Up。别急着配硬件状态先摸清楚后面排障会省很多事。这一步是我每次必做的跳过的话后面集群协商失败排查范围会大很多。2. 配置前你必须想清楚的几件事2.1 版本与License一致性集群能成功建立的一个隐形前提是两台S7706的软件版本完全一致。注意是完全一致包括大版本、小版本、补丁版本。版本差一个补丁都可能造成集群协商失败或者集群后行为异常。实际项目里我遇到过一次两台设备一个V200R019C00另一个打过一个SPC补丁结果集群状态一直起不来查了半天才发现是这个原因。最后两边软件做到一致重启后集群秒建。License这块重点看CSS使能本身有没有License限制以及你后面要用到的特性比如跨框Eth-Trunk的高级负载均衡模式是否需要特定License。两台设备的License不一定需要完全一样但涉及关键特性的License必须有否则配置命令敲进去会被拒绝或者配置生效了但实际不工作。2.2 成员ID与优先级规划CSS集群中每台设备都要有一个唯一的成员IDMember ID从1开始编号。CSS还有一个优先级Priority参数用于竞选主设备。主设备的选举规则是优先级数值大的成为主设备如果优先级相同则MAC地址小的成为主设备。我习惯的规划方式很直接确定哪台做主就把哪台的优先级设高比如主设备优先级设为10备设备设为5。另一台上把ID设为2。这样即使设备重启主备角色也是稳定的不会出现“抢主”的情况。有个细节值得提醒两台设备的成员ID不能一样否则集群协商会报冲突但如果只是临时把一台设备的配置改了没重启另一台也是同样的ID两台不会立即冲突容易让人误判是链路问题。所以规划好ID后第一时间写进维护文档别只靠脑子记。2.3 槽位与端口号变化预期S7706是框式设备槽位编号和端口编号是运维时绕不开的点。CSS集群建立后第二个成员框的槽位号会在原有基础上发生偏移。这个偏移规律在不同框式产品上可能不一样常用的是按固定偏移量平移比如第二台框原来的槽位0会变成槽位10槽位1变成槽位11依此类推。这个细节直接影响到后面的端口配置。举个例子框2上原来槽位0的业务板其端口从10GE1/0/X变成CSS域内的10GE10/0/X。写配置脚本时所有涉及框2的端口都要用偏移后的新编号写错一个就起不来业务。我踩过这个坑后续会在第4节展开讲。2.4 配置备份与从设备配置合并这是很多人最容易忽略的一点。使能CSS并重启后主设备的配置会成为整台逻辑设备的配置从设备上原有的独立配置不会被完整保留进新的CSS系统。更准确地说CSS系统启动后整个集群的配置是以主设备配置为基础的从设备原来的配置在集群环境中基本不生效。所以配置前要做的功课是把两台设备当前的运行配置分别导出保存作为备份梳理从设备上原有的业务配置把需要保留的配置项比如VLAN、接口、路由、业务策略合并到主设备的配置里明确哪台是主把从设备上可能冲突的管理IP、设备名等信息先改掉。不提前做这一步集群起来后会发现从设备上的业务配置“消失”了到时候不但要现场重配还要处理业务中断的事故压力完全不一样。这个坑我在早期项目里踩得很疼现在形成了固定的配置前检查模板。3. 集群卡CSS配置实操全流程3.1 第一台设备设置ID、优先级并开启CSS硬件的两台设备都上电、系统起来之后开始配第一台。我以主设备为例先登录它的Console口。进入系统视图执行以下命令system-view set css id 1 set css priority 10 set css enable三个命令各说一句。set css id 1是把本机成员ID定为1set css priority 10把优先级设为10确保它竞选成主set css enable是开启CSS功能注意这个命令执行后并不会立刻生效需要保存配置并重启设备。保存配置并重启save y reboot重启过程会提示是否继续输入y确认。设备重启后系统会进入等待集群协商的状态。此时如果第二台的CSS配置还没做完这台设备会以单机模式运行业务不受影响但CSS状态不是normal这是正常的不用慌。这里有一个实操细节set css enable之前务必确认所有配置已经保存完整因为这次重启是进入CSS流程的关键一步。重启前如果还有未保存的配置丢配置的锅只能自己扛。3.2 第二台设备对称配置并重启第二台设备的操作几乎一样只是ID和优先级不同。登录第二台的Console口执行system-view set css id 2 set css priority 5 set css enable保存并重启。这里有一个关键点第二台的优先级5低于主设备的10所以无论如何它都是备。如果两台设备的优先级设成一样系统会按MAC地址选主虽说不影响集群建立但角色不可控不建议这么干。两台都重启完成后集群协商会自动发生。我见过最快的案例是两台设备重启后两三分钟就完成了协商慢的也就五六分钟。如果超过这个时间还没起来优先检查集群卡链路状态和版本一致性。3.3 集群建立后的状态验证集群建没建起来不要靠猜上命令看。登录任意一台设备推荐从主设备看执行display css status正常输出里的关键字段是css enable状态为yescss status为normal同时能看到本机的成员ID和优先级。再执行display device这时候应该能看到两台框上的所有板卡。框1的板卡在原有槽位框2的板卡出现在偏移后的槽位。看到两台设备的板卡都正常在位说明CSS集群已经建立成功。我习惯再执行一次display version确认两台设备的软件版本显示一致顺便看一眼两个框的设备信息都出现在输出里。这套三步验证做完CSS状态才算真正确认无误。实际运维中我还会检查一下系统时间两台设备集群后时间应该统一避免日志分析时出现时间错位。3.4 配置双主检测MADCSS建立只是第一步如果不配双主检测MADMulti-Active Detection这个集群是有隐患的。设想一个场景集群互联链路突然全断了两台设备各自为政都认为自己是主就会出现两台设备同时转发相同IP的双主冲突下联设备学到的MAC表、ARP表完全混乱网络直接瘫痪。MAD的作用就是在分裂发生时让备设备感知到“主设备那边还活着”或者让分裂后的系统快速收敛避免双主。华为S7700可以通过直连检测来实现。直连检测的配置思路在两台成员设备之间单独拉一根光纤作为MAD检测链路链路两端各配一个Eth-Trunk在Eth-Trunk视图下启用MAD直连检测。具体配置主设备上system-view interface Eth-Trunk 20 mad detect mode direct interface 10GE1/0/25 eth-trunk 20 quit备设备上system-view interface Eth-Trunk 20 mad detect mode direct interface 10GE10/0/25 eth-trunk 20因为框2的槽位已经偏移刚才选的框2槽位0板卡上的第25口在CSS域里就是10GE10/0/25。这条MAD检测链路和业务完全隔离平时只跑检测报文不承载业务流量。注意MAD检测链路最好和CSS链路走不同的物理路径比如CSS链路走机柜上部的光纤MAD检测链路走机柜下部的光纤避免一次线缆事故把两条链路同时干掉。还有一种中继检测方式需要借助中间设备做代理配置相对复杂适合两台框之间不方便拉直连线的场景。常规核心组网两台框都在同一个机柜或相邻机柜直连检测最直接也是我项目里的首选。3.5 跨框Eth-Trunk配置与业务流量分担集群建立、MAD配好之后才轮到真正的业务接入。跨框Eth-Trunk就是把一台物理交换机上的聚合口跨越两台物理框让下联交换机的一条聚合链路同时接到两个框上。这样任意一台框故障另一台框上的成员口还能继续转发下联设备完全无感知。配置命令示例system-view interface Eth-Trunk 100 mode lacp-static trunkport 10GE1/0/1 trunkport 10GE10/0/1 quit这里把一个来自框1槽位1的10GE口和一个来自框2槽位10原槽位0的10GE口加进了同一个Eth-Trunk。下联交换机配好LACP两边就能协商起来。做跨框聚合有几个原则要守住聚合成员口尽量分布在不同的板卡上降低单板故障的影响不要只选一个成员口来自框1、另一个来自框2能凑够4个或8个口的尽量均匀分配负载均衡模式要根据业务提前规划比如基于源目MAC还是源目IP这个决定了hash效果。跨框Eth-Trunk配置好之后还要检查一下下联设备的聚合状态确认成员口都处于Selected状态。如果出现Unselected通常是两端LACP参数不一致例如超时时间、优先级配置不同导致的逐项对齐即可。集群模式下还有一类常用命令是CSS域内的管理性操作。比如以后要手动切换主备可以在主设备上执行命令让角色切换运维窗口内需要做设备重启维护时非常有用。不过这类操作要谨慎切换角色本身会导致设备间短暂的协议重协商建议在业务低峰期进行。4. 实际运维中那些必须躲开的坑4.1 集群建不起来先按这三个方向排查集群协商失败的原因90%逃不出三类物理链路、参数配置、软件版本。物理链路排查很简单。看集群卡接口的物理状态是不是Up光模块收发光是不是正常。我遇到过一种情况是光纤标签贴反了实际上两头根本没对应上看起来链路Up但协商不起来最后用光功率计和打光笔一根根核对的。集群卡之间的光纤建议做好A/B端标签避免这种低级别事故。参数配置排查重点看两台设备的成员ID是否有冲突、CSS功能是否都使能。登录设备执行display css status如果能看到本机已经使能CSS再看对端是否也处于使能状态。两边参数不对称协商卡住很正常。软件版本排查相对费时需要对比两台设备的版本字符串精确到补丁级别。差异较大的只能安排维护窗口升级对齐没有捷径。4.2 链路抖动导致的分裂与MAD误判处理集群链路一旦不稳定就会出现一种让人头疼的状态CSS状态在normal和standalone之间反复跳变业务时断时续。MAD机制更尴尬分裂后如果备设备检测到“另一个主”的存在会把备设备上配置了MAD检测的接口置为Down防止双主冲突。但造成的结果是分裂恢复后如果MAD接口没自动恢复业务口就一直Down着。遇到这种情况第一反应不是去物理拔线而是先看MAD状态。在设备上执行相关display命令查看被MAD关掉的接口对接口执行shutdown再undo shutdown恢复。然后确认集群链路恢复后手动触发一次集群重新合并把堆叠状态拉回normal。这个坑我在一次光纤被老鼠咬断的事故里遇过。集群分裂、MAD关了备设备的业务口业务大面积中断现场第一反应是重启备设备结果更乱。现在我的排查顺序很固定先确认物理链路再看CSS状态再处理MAD关断的接口最后恢复业务口不要一上来就重启。4.3 槽位偏移带来的配置错误槽位偏移是CSS配置里最隐蔽的坑。我在给一个项目做割接时配置脚本里框2的端口还写着10GE1/0/X和框1的端口完全重号。配置下发后框1和框2的两个端口都显示了配置但实际只有一个生效。这个问题的根源在于CSS后的端口编号体系变了。框2的所有板卡槽位都发生了偏移端口编号必须跟着变。我后来养成了一个习惯配置前先执行display device把两台框所有板卡的CSS域槽位号列出来做成一张对应表配置脚本里所有端口号都从这张表里取不靠记忆。对应关系确认后跨框Eth-Trunk、MAD链路、下联接口的配置才能真正落对地方。一个端口的配置错了表面上看是业务不通实际排查一圈才能找到真正原因时间成本非常高。4.4 集群状态下的维护与升级注意CSS集群上线只是开始运维期才是真正的考验。这里挑三个最常犯的错误说。第一不要在业务高峰期执行主备切换测试。虽然CSS支持无损切换但真实场景中业务板上的转发表项、硬件表项重新同步需要时间高峰期的突发流量可能造成丢包。这种测试放在凌晨维护窗口做。第二升级软件版本时要严格按照流程来。华为框式CSS的升级支持整机平滑升级流程一般要求先升级备设备观察稳定后再升级主设备。两台设备同时升级等于直接中断业务这种低级错误在运维圈反复出现必须写进操作步骤里加双人复核。第三日常巡检要加CSS专项项。我自己的巡检清单里就固定有两条执行display css status确认状态是normal再检查集群卡接口有没有产生CRC错误或者光功率阈值告警。隐患往往不是突然出现的而是慢慢积累的巡检能把这些苗头提前掐掉。4.5 集群建立后管理面的几个细节集群建完往往会觉得万事大吉但管理面还有几件事要收尾。STP域的处理。两台框合并成一台逻辑设备后原来的STP域会重新收敛。如果之前两台框是分别运行的每台都有自己的根桥CSS建立后要把根桥配置收敛到主设备上否则可能出现STP反复震荡。实际项目里我见过CSS建完后STP重新选举导致网络阻塞几十秒的情况配置确认根桥位置后恢复正常。灵活链路和接口备份策略。S7706支持基于接口的备份和基于链路的切换但CSS模式下业务口的选择、备份关系的设置都要重新梳理。我之前维护过一套老组网CSS切换后原来依赖单框的备份链路没及时调整结果主框故障时备份链路也没法承载流量等于冗余白做了。系统日志和告警同步。CSS集群的主备设备在日志和告警管理上是一个整体建议配置日志主机、SNMP网管同步到统一平台。主设备故障后如果日志只留在主设备上没外发故障分析的素材就全丢了。所以集群搞完后日志外发、告警上报这类“看不见”的配置要作为收尾动作逐项确认。5. 写在最后的一点个人体会S7706的CSS集群配置命令本身不复杂复杂的是你决定用哪种方案、如何规划参数、怎么应对物理链路的不确定性。集群卡方案我认为是框式交换机做设备虚拟化的首选它把可靠性建立在硬件基础上而不是靠一根容易出意外的线缆。这个配置我前前后后做过不少次最大的感悟是所有看起来“理所当然”的故障背后都是一个没提前确认的细节。版本没对齐、槽位号没换算、MAD检测链路走了同一条物理路由这些坑我都踩过。所以你在做之前一定要把检查清单走完不要嫌烦。配置一时爽排障火葬场这句玩笑话在CSS集群这个场景里是真真切切的现实。最后再分享一个小技巧集群配置完成并运行稳定后把整套逻辑设备的配置文件导出一份存好同时把display css status和display device的输出截图存档。后面再做任何变更、排障、升级这些基线数据都能帮你快速判断“当前状态到底正不正常”。运维的本质就是把这些细节管住这台设备就能安安稳稳跑很多年。