如果你刚接手一套H3C核心网络又恰好碰上服务器要做双网卡冗余上联那么“S-MLAG”和“bond4”这两个词大概率会同时出现在你的搜索记录里。简单说S-MLAG是H3C交换机上的跨设备链路聚合技术允许两台物理交换机像一台逻辑设备一样给服务器提供两条上行链路而bond4对应Linux服务器上的802.3adLACP模式。两者配合就是一套标准的服务器高可用网络方案——任何一台交换机宕机、任何一条光纤或网线被拔掉业务流量都能在秒级甚至毫秒级切换到幸存链路上对端服务器和业务进程基本无感知。这篇文章我不打算复述官方文档而是把一套我在生产环境里调试过、也踩过坑的完整配置过程拆开讲从S-MLAG和IRF堆叠怎么选到交换机侧和服务器侧的详细配置再到那些”不试不知道、一试吓一跳”的坑。文章比较长但每一步都是按可复现的标准来写的适合网络运维、系统工程师以及负责数据中心基础设施的同行参考。1. 整体设计为什么是S-MLAG而不是堆叠1.1 先搞清楚S-MLAG和堆叠的本质区别很多刚接触H3C设备的人第一反应是“高可用直接做IRF堆叠不就行了”确实IRF在H3C体系里非常成熟两台设备通过堆叠口虚拟成一台逻辑上管理简单跨设备链路聚合也能通过堆叠后的逻辑口来实现。但堆叠有一个隐藏的“耦合”问题控制平面收敛在一起一台设备升级重启往往会让另一台也抖动堆叠线不稳定还会导致整个系统分裂反而触发更大的故障。S-MLAG的思路完全不同它不虚拟控制平面两台交换机各自独立运行只是通过一条peer-link链路和一组专门的协商机制把某个面向服务器的聚合口“做成”跨设备的。服务器看到的依然是一个标准的LACP聚合口但这个聚合口的成员口分别落在两台交换机上。这样做的最大好处是故障隔离一台设备挂了另一台完全不受影响照样转发。坏处是配置复杂度上升很多参数需要两台保持一致。总结成一句话追求极简运维、机房就两台设备且允许统一升级选IRF追求故障隔离、需要跨设备做双活链路且可能面临分批升级的场景选S-MLAG。我在生产环境里因为要支持服务器双活的存储集群网络侧承担不起堆叠分裂的风险所以最终选的是S-MLAG。1.2 S-MLAG的使用场景和部署形态S-MLAG最典型的落地场景有三个服务器双网卡bond4上联两台核心交换机实现物理链路和交换机设备的双重冗余防火墙、负载均衡等网关设备做双机热备通过跨设备聚合口把两台设备接入网络存储阵列双控制器上联避免控制器切换时网络路径中断。部署形态上两台交换机之间需要至少一条peer-link也叫keepalive链路之外的聚合链路负责传递S-MLAG协商报文和跨设备流量转发另外还需要一条独立的物理链路作为keepalive检测用于双主检测和故障分裂后的仲裁。这里要注意peer-link和数据链路、keepalive链路必须明确分开千万别图省事共用链路后面避坑部分我会细说。1.3 方案落地整体逻辑我们的目标拓扑是这样的两台H3C交换机以S7506E和S6520为例型号不同也能配只要是支持S-MLAG的版本分别命名为SW-A和SW-B两者之间用两条40G接口做peer-link聚合再用一条独立千兆物理口互连作为keepalive链路。服务器上装双网卡配置bond4802.3ad分别接到SW-A和SW-B的普通业务口上。两台交换机把这些业务口划分进同一个S-MLAG组对外呈现为一个LACP聚合口而服务器看到的也是聚合口两边就自动协商起来了。这套方案不需要额外的license授权也不需要堆叠线代价是额外占用两个40G口和两个千兆口。如果核心设备是S7506E性能完全够用S6520作为接入/汇聚交换机内存和表项要稍微注意一下建议提前确认版本支持S-MLAG特性。2. S-MLAG配置前的原理准备2.1 S-MLAG的组件拆解peer-link、keepalive、S-MLAG组在开命令行之前有必要把S-MLAG的几个组成概念理清楚否则配置的时候很容易因为“不知道为什么要这么配”而出错。peer-link两台交换机之间的聚合链路主要负责在两台设备之间传输S-MLAG的协商报文以及某些需要跨设备转发的流量。peer-link本身必须配置为聚合口一般是动态聚合不能是单条物理口直接trunk过去否则性能和可靠性都没有保证。keepalive链路用于双主检测的独立物理链路。它的核心作用是当peer-link断掉时两台设备仍然能互相探测到对方心跳避免两边同时认为自己是主设备、同时转发流量导致广播风暴和MAC漂移。keepalive链路通常用独立的千兆管理口或普通业务口配置一个专用的互联IP即可。S-MLAG组在两台设备上定义了同一个编号的聚合口比如两边的Bridge-Aggregation 10都被纳入S-MLAG管理。服务器上联的这两个成员口虽然物理上属于不同的交换机但在逻辑上会被两台设备同步处理成同一个聚合口LACP协商时保持系统ID一致这一点非常关键。2.2 LACP系统ID在跨设备场景下的特殊性普通场景下两台独立交换机的LACP System ID是不一致的服务器如果同时接到两台交换机的两个口上做动态聚合会出问题因为服务器看到的LACP报文来自不同的系统逻辑上会判定是两个不同的聚合组无法形成单条聚合链路。S-MLAG解决这个问题的办法就是把两台交换机在这个S-MLAG组上的LACP System ID改成一致的。也就是说SW-A和SW-B在面向服务器协商LACP时发出的系统ID包括优先级和MAC完全一样服务器才会认为收到的两个成员口属于同一条聚合链路。这也是配置里必须保证两台设备上S-MLAG组编号一致、LACP优先级一致的原因。2.3 S-MLAG转发模型主备还是双活S-MLAG从转发模型上来说是支持双活的也就是说两台设备都可以转发流量不是一台跑一台歇。但具体到某一条已知单播流它只会在其中一条链路上转发不会同一个数据包双发。这样设计是为了避免乱序和重复同时对服务器bond4的负载均衡策略也能达到多链路利用的效果。对服务器而言两台交换机的S-MLAG组看起来就是一个标准的LACP聚合口支持802.3ad的所有所负载分担策略。所以交换机侧的报文hash、服务器侧bond4的xmit_hash_policy这两个参数最好按同一个思路去设计否则可能出现“服务器把流量分担到了两条链路但交换机反方向的流量全走了一条链路”这种半吊子双活。3. 核心配置实操交换机侧S-MLAG3.1 环境检查和版本确认配置之前第一步必须确认设备型号和软件版本支持S-MLAG。H3C S7500E系列、S10500系列、S6800/S6520系列等主流框式/盒式交换机在较新的Comware V7版本上都支持S-MLAG但如果版本太老特性可能不全。建议用display version命令确认版本再用display s-mlag capability命令确认设备是否具备S-MLAG能力。配置前还要确认设备之间至少已有两条物理链路一条做peer-link聚合一条做keepalive并且交换机上有空闲的物理口给服务器用。我这里以SW-A和SW-B两台设备为例物理口规划如下SW-A40GE1/0/1、40GE1/0/2 → peer-link聚合口Bridge-Aggregation 1SW-AGE1/0/1 → keepalive链路IP为10.10.10.1/30SW-A10GE1/0/1 → 服务器bond4成员口S-MLAG成员口Bridge-Aggregation 10SW-B40GE1/0/1、40GE1/0/2 → peer-link聚合口Bridge-Aggregation 1SW-BGE1/0/1 → keepalive链路IP为10.10.10.2/30SW-B10GE1/0/1 → 服务器bond4成员口Bridge-Aggregation 10两台设备的S-MLAG组编号统一为10LACP优先级建议设置一致比如都设为100。桥接VLAN要根据实际业务设置这里演示VLAN 100作为业务VLAN。3.2 SW-A配置完整过程登录SW-A先创建一个二层聚合口用于peer-linksystem-view sysname SW-A lacp system-priority 100 interface bridge-aggregation 1 port link-type trunk port trunk permit vlan 100 port trunk pvid vlan 100 link-aggregation mode dynamic quit interface FortyGigE1/0/1 port link-type trunk port trunk permit vlan 100 port link-aggregation group 1 quit interface FortyGigE1/0/2 port link-type trunk port trunk permit vlan 100 port link-aggregation group 1 quit第二步配置keepalive链路interface GigabitEthernet1/0/1 description keepalive-to-SW-B ip address 10.10.10.1 255.255.255.252 quit第三步配置面向服务器的S-MLAG业务聚合口interface bridge-aggregation 10 port link-type access port access vlan 100 link-aggregation mode dynamic lacp system-priority 100 quit interface Ten-GigabitEthernet1/0/1 port link-type access port access vlan 100 port link-aggregation group 10 quit第四步启用S-MLAG并指定keepalive目的地址s-mlag keepalive destination 10.10.10.2 quit interface bridge-aggregation 10 s-mlag group 10 quit注意s-mlag group 10这个命令必须先在系统视图下开启s-mlag功能然后应用到具体的聚合口上。如果把s-mlag group配在普通物理口上会直接报错提示只能在聚合口下配置。3.3 SW-B配置完整过程SW-B的配置和SW-A基本一致差异点在keepalive的IP地址和端口描述。peer-link聚合ID编号同样用1S-MLAG组编号也用10注意两台设备的S-MLAG组编号必须相同否则S-MLAG协商无法建立。system-view sysname SW-B lacp system-priority 100 interface bridge-aggregation 1 port link-type trunk port trunk permit vlan 100 port trunk pvid vlan 100 link-aggregation mode dynamic quit interface FortyGigE1/0/1 port link-type trunk port trunk permit vlan 100 port link-aggregation group 1 quit interface FortyGigE1/0/2 port link-type trunk port trunk permit vlan 100 port link-aggregation group 1 quit interface GigabitEthernet1/0/1 description keepalive-to-SW-A ip address 10.10.10.2 255.255.255.252 quit interface bridge-aggregation 10 port link-type access port access vlan 100 link-aggregation mode dynamic lacp system-priority 100 quit interface Ten-GigabitEthernet1/0/1 port link-type access port access vlan 100 port link-aggregation group 10 quit s-mlag keepalive destination 10.10.10.1 quit interface bridge-aggregation 10 s-mlag group 10 quit如果两台设备的业务口不完全一致比如SW-A是10GE口、SW-B是GE口也能做S-MLAG只是聚合带宽以低的一端为准而且两端口的速率差距不建议太大否则流量hash会出现严重的负载不均。3.4 S-MLAG状态验证命令配置完成后不要急着接服务器先确认S-MLAG协商状态正常。依次执行display s-mlag summary display s-mlag verbose display lacp system-id display interface bridge-aggregation 10重点关注几个关键信息S-MLAG设备状态显示UP表示两台设备S-MLAG邻居关系正常keepalive状态显示UP且能收到对端心跳说明双主检测链路正常peer-link状态显示UP聚合口状态为Selected说明peer-link链路聚合成功LACP系统ID两台设备显示的System ID必须完全一致包括优先级和MAC否则S-MLAG逻辑上就不成立。我在实际调试中遇到过一种情况S-MLAG summary里状态是UP但display s-mlag verbose里peer-link的接收报文计数不增长后来排查发现是peer-link聚合口的VLAN配置两台不一致导致协商报文被丢弃。这个坑在后面的避坑部分还会单独提。4. 服务器侧bond4配置与联动调试4.1 服务器网卡bond配置服务器侧我以Linux系统RHEL/CentOS 7及以上或Ubuntu 18.04为例配置bond4对应H3C交换机侧的动态LACP。使用NetworkManager或直接改配置文件都可以但推荐直接使用teamd或者内核bonding的802.3ad模式因为交付后更易排查。以RHEL系的/etc/sysconfig/network-scripts/ifcfg-bond4为例DEVICEbond4 NAMEbond4 TYPEBond BONDING_MASTERyes ONBOOTyes BOOTPROTOstatic IPADDR192.168.100.10 NETMASK255.255.255.0 GATEWAY192.168.100.1 BONDING_OPTSmode4 miimon100 lacp_rate1 xmit_hash_policylayer34成员口配置DEVICEeth0 NAMEeth0 TYPEEthernet ONBOOTyes MASTERbond4 SLAVEyes DEVICEeth1 NAMEeth1 TYPEEthernet ONBOOTyes MASTERbond4 SLAVEyes这里的xmit_hash_policy推荐layer34因为纯粹用layer2 hash在跨设备聚合环境里如果源MAC和目的MAC固定很容易把流量全部哈希到一条链路上达不到双活目的。交换机侧同理会话的hash策略H3C默认是逐流的如果你希望基于IP或四层端口做更均匀的分担可以通过聚合口下的port link-aggregation group的hash-type命令调整但要注意保证两端算法匹配否则流量行为不可预期。4.2 ha动态LACP协商的几个关键bond4模式依赖LACP协议默认的lacp_rate是慢速30秒生产环境建议改成快速1秒也就是在BONDING_OPTS里加上lacp_rate1。这个参数直接影响交换机成员口状态感知的速度对故障切换时间有很大改善。我曾经遇到过一种情况服务器两个口都配了bond4交换机S-MLAG组也起来了但聚合口显示只有一个是Selected另一个是Standby。查LACP报文计数发现服务器侧其中一个口的网卡驱动没有正常发送LACP PDU原因是网卡固件版本太老。后来更新了网卡固件问题才消失。所以服务器侧做bond4时务必确认网卡驱动和固件版本正常建议先跑一下ethtool eth0和ethtool -S eth0 | grep -i lacp看看计数。4.3 把服务器接入S-MLAG组的操作顺序很多人喜欢先拔线再配服务器网络最后才想起来交换机没配对结果线上业务中断半小时。正确的接入顺序应该是先把交换机的S-MLAG配置全部做完并验证UP把服务器上的bond4配置写好但先别把两边网线同时插上只插一根网线到SW-A确认bond4能正常协商为UP状态、链路为Selected再插另一根网线到SW-B确认bond4两个slave都变为UPLACP聚合成功最后ping网关、测试跨网段通信确认业务正常。这样做的好处是如果第二根线插上后才发现S-MLAG协商有问题至少此时还有一根链路在正常工作不影响业务。我有一次图省事两台交换机提前配好就直接把服务器两根线插上结果发现交换机S-MLAG的keepalive地址配反了S-MLAG状态根本没起来服务器bond4两个口疯狂抢占网络通了又断。虽然几分钟内查出来改掉但业务已经受了影响。5. 避坑指南和常见问题排查5.1 S-MLAG没起来pair-link、keepalive怎么排查S-MLAG起不来90%的原因是peer-link或keepalive配置错误。排查顺序建议如下先看peer-link聚合口状态。display interface bridge-aggregation 1能看到该聚合口的Selected端口数量。如果只有一个端口是Selected另一个是Unselected大概率是peer-link两端口的VLAN配置不一致或者peer-link两端聚合模式不匹配比如一端是dynamic一端是static。再看keepalive互通性。从SW-A上ping 10.10.10.2如果不通检查keepalive链路两端的IP地址、子网掩码和物理接口状态。keepalive链路建议不要划到业务VLAN里直接做成三层互联口。注意keepalive链路必须独立于peer-link之外的物理链路否则一旦peer-link故障、keepalive同时故障设备会误判双主造成严重后果。最后看S-MLAG下的成员口状态。如果peer-link正常、keepalive正常但S-MLAG组下的业务口状态不对优先检查两台设备上S-MLAG组里的成员口所属VLAN是否一致、聚合口模式是否一致、LACP系统优先级是否一致。S-MLAG对成员口的“对称性”要求很严格任何一端对不上聚合口都可能起不来。5.2 双主分裂后的自愈机制和残留MAC问题S-MLAG最需要警惕的故障模式是“双主分裂”。当peer-link断开但keepalive仍能检测到对端时两台交换机会各自尝试接管S-MLAG组形成双主。这个状态下服务器流量就会出现路径环路和MAC漂移非常危险。H3C的S-MLAG有自愈机制检测到peer-link断开后设备会通过keepalive协商主备角色备设备会将S-MLAG组里的业务口全部shutdown避免双主转发。但这里有个经典坑如果peer-link断了但keepalive也同时断了两台设备都会认为对方失联无法通过协商确定主备就会各自独立双主。所以生产环境务必保证keepalive链路的高可用性最好走独立物理口、独立光纤千万别和业务共用线路。另一个隐蔽问题是“S-MLAG残留MAC”。当双主分裂恢复后一台设备上可能会残留分裂期间学习到的服务器MAC地址导致恢复后的转发路径仍然指向错误的设备。遇到这种情况可以在两台设备上手动执行reset mac-address清空动态MAC表后重新学习业务即可恢复。我这边发生过一次类似情况排查了两个小时才发现是残留MAC在作祟。5.3 那些最容易忽略的小细节lacp system-priority必须一致。H3C的LACP system-priority默认是32768如果你两台设备都保持默认也能协商起来但一旦你只改了其中一台的优先级两台的System ID就不一致了。所以配置S-MLAG时最好显式地在两台设备上设置相同的优先级。S-MLAG成员口上的端口隔离、QoS策略必须同步。交换机上的端口隔离、ACL、QoS策略如果只在SW-A上配了SW-B上没配就会出现同一套S-MLAG组成员口行为不一致流量表现不同。peer-link上不要配置和S-MLAG业务口相同的VLAN广播抑制策略。peer-link主要跑的是跨设备协商报文和部分跨设备转发流量如果对它做了严格的VLAN过滤或广播抑制可能导致S-MLAG协商报文丢失。服务器bond4的lacp_rate最好设成fast。H3C交换机默认的LACP超时是长超时30秒如果服务器侧是慢速LACP链路断开后交换机感知时间可能长达30秒这对业务来说是不可接受的。用fast模式感知时间能缩短到3秒左右。5.4 经典故障速查表现象可能原因排查方向S-MLAG summary显示设备状态DOWNkeepalive链路不通或peer-link未UPping对端keepalive地址检查peer-link物理口状态服务器bond4只有一个口UP跨设备LACP系统ID不一致查看两台设备display lacp system-id是否一致服务器流量全部走一条链路两侧hash策略不一致或成员口配置不对称检查服务器xmit_hash_policy检查S-MLAG组成员口VLAN/模式S-MLAG恢复后ping不通网关残留MAC未清除在核心设备上reset mac-address拔掉一根线后网络中断S-MLAG未协商成功就插线按“先一根线后二根线”的顺序接入6. 从配置到验收我的实操体会配完S-MLAG bond4之后一定要做一轮故障演练再交付不能只看状态UP就觉得完事了。我常用的演练项目有三种拔线、shutdown端口、重启交换机。拔线测试在服务器上ping网关的同时直接拔掉一根网线。正常情况下bond4的另一个口会在1-3秒内接管流量ping应该只丢1-2个包甚至不丢包。如果丢包超过3秒检查LACP超时时间是否过长、bond4的miimon是否配置正确。shutdown接口测试在交换机上执行shutdown Ten-GigabitEthernet1/0/1模拟成员口故障。观察服务器bond4的状态变化确认另一个slave接管。这里要注意shutdown接口后S-MLAG组里如果该口的角色变更为Unselected不要着急等服务器LACP重新协商完成即可。重启交换机测试这是最狠的测试直接在业务低谷期重启SW-A。观察S-MLAG状态、peer-link状态、服务器bond4的状态变化。正常情况下SW-B能继续独立接管所有流量业务不中断。同时需要注意SW-A重启回来后S-MLAG会自动重新协商不会自动shutdown的S-MLAG成员口也需要确认恢复。我在实际测试中见过一次比较典型的现象重启SW-A后服务器bond4的eth0口变成了down状态但交换机上S-MLAG组的成员口已经是UP了。后来一看是服务器网卡的LACP协商超时时间比交换机慢导致交换机认为链路已协商成功但服务器还没恢复。解决办法是给服务器网卡设置更短的LACP超时时间这个可以用ethtool -s eth0 speed/duplex/lacp相关参数微调当然最好直接升级网卡驱动。这整套配置执行下来单独一台交换机的故障对业务产生的网络影响基本控制在3秒以内而且大部分场景下能做到秒级切换。对我个人而言自从用了S-MLAG bond4这套组合核心接入层的周末维护再也不用约后端同事一起熬夜陪跑应用联调了。如果非要说一个最值得注意的经验那就是别把S-MLAG当堆叠来配——它更讲究对称性和细节保持两台设备配置上的“镜像一致”出问题的概率就会小很多。