干网络这行时间长了你会发现一个特别普遍的场景服务器做了双网卡绑定上行却接了同一台交换机结果交换机一宕机业务照样全挂。我自己就处理过好几起这种“看似冗余、实则单点”的事故。后来在H3C交换机上把S-MLAG和服务器bond4搭起来才真正把这个单点解决掉。今天把整套配置思路、命令和踩坑记录整理出来给准备做服务器高可用接入的兄弟们一个参考。这套方案解决的核心问题很明确服务器双网卡bond4之后两条物理链路分别接到两台H3C交换机上任何一台交换机宕机、任何一根网线断开服务器都不中断业务。适合的对象是正在用H3C核心交换机承载业务、需要给数据库或业务服务器做高可用接入的网络和运维人员。1. 先聊清楚S-MLAG是个什么思路1.1 为什么不是堆叠而是M-LAG很多人第一反应是“高可用直接做IRF堆叠不就行了”。确实H3C的IRF堆叠很成熟两台设备虚拟成一台服务器bond4上去就是标准的跨设备链路聚合。但堆叠有几个让人头疼的点控制平面耦合在一起两台设备必须版本一致、型号一致升级时要整机重启一旦堆叠分裂比如堆叠线缆松动、光模块老化整网都会震荡甚至有脑裂风险。堆叠还有一个隐性成本——堆叠链路占端口如果是S7506E这类核心设备堆叠口和业务口互相挤占的情况下规划起来非常尴尬。S-MLAG也叫M-LAG在H3C Comware V7/V9平台叫法略有差别走的是另一条路两台交换机保持完全独立运行控制平面各自为政只是通过Peer-link和Keepalive链路把跨设备聚合这件事协同起来。M-LAG故障域小一台设备挂了对端不受影响升级可以逐台做对端口占用也没有那么苛刻最关键的是服务器侧完全无感和接一台逻辑交换机没有任何区别。我自己在实际项目中只要是核心设备双活接入现在更偏M-LAG而不是堆叠。不是说堆叠不好而是堆叠适合纵向扩展M-LAG适合横向高可用。两者对比如下维度IRF堆叠S-MLAG控制平面统一耦合独立分离故障域堆叠分裂影响整网单台故障对端继续转版本要求必须严格一致建议一致但松耦合升级操作整机重启风险高逐台升级业务无感服务器侧效果逻辑为单台设备同样逻辑为单台设备脑裂风险有需MAD检测有靠KeepalivePeer-link检测1.2 bond4在这里扮演什么角色服务器侧bond4也就是Linux bonding的mode 4对应IEEE 802.3ad动态链路聚合走的是LACP协议协商。bond4本身并不复杂关键是它要和交换机侧的聚合模式对上。交换机必须是动态聚合LACP服务器发起LACPDU两边协商一致后两条链路同时转发既做冗余又叠带宽。在S-MLAG场景里两台交换机上的DR口跨设备聚合口对外表现成一个逻辑聚合口服务器的两个网卡分别接到这台设备上LACP协商时看到的是同一个聚合系统所以bond4能正常起来而且status是up up双活状态。这里有个好处很多人没意识到传统堆叠下bond4依赖堆叠系统保持LACP系统标识一致而M-LAG本身就具备这个能力所以服务器侧只需要按标准bond4配置不需要额外适配。2. 组网规划与配置前的硬指标2.1 组网拓扑与设备选型我这次用的是两台H3C S7506E作为核心下连服务器区。当然实际环境里你用S6520、S6800、S6850这些框式或盒式设备配置思路完全一样命令也基本是Comware V7/V9通用。关键的组网逻辑是这么几条两台交换机各出一条链路组成Peer-link承载DRCP协议报文和跨设备流量这里我建议捆绑两条万兆做成聚合避免Peer-link本身成为瓶颈。Keepalive链路独立配置用三层接口或者专门的管理VLAN接口做心跳目的就是检测对端设备是否存活绝对不能和业务VLAN混用。服务器的两张网卡分别接到两台交换机的业务口上这两个业务口各自加入自己设备上的DR接口DR接口编号两台设备必须保持一致。如果还有双活网关需求M-LAG配合VRRP是常见组合VRRP虚IP作为服务器网关主备状态由两台设备自行协商。拓扑规划阶段有一个容易忽视的点Peer-link建议放通所有业务VLAN。很多人只放通了当前业务的VLAN后续新增业务时忘记加故障切换时流量就断了。这属于规划时多花一分钟、排障时省两个小时的典型操作。2.2 VLAN、IP和接口规划表配置之前先把台账列清楚。我习惯做一个这样的表格实施时照着填参数就行项目设备ASW1设备BSW2说明管理IP192.168.10.1/24192.168.10.2/24独立管理网段Keepalive接口VLANVLAN 999VLAN 999不承载业务流量Keepalive IP10.0.0.1/3010.0.0.2/30source/destination对调Peer-link聚合口Bridge-Aggregation 1Bridge-Aggregation 1两台都叫BAGG1Peer-link成员端口XGE1/0/23、XGE1/0/24XGE2/0/23、XGE2/0/24建议万兆双线业务DR接口Bridge-Aggregation 10Bridge-Aggregation 10编号必须一致DR口成员端口XGE1/0/1、XGE1/0/2XGE2/0/1、XGE2/0/2分别接服务器两张网卡业务VLANVLAN 100VLAN 100服务器业务网段服务器网关192.168.100.1/24192.168.100.1/24VRRP虚IP或M-LAG转发后的虚网关这里要特别强调一下DR口和Peer-link口不要共用。有的兄弟图省事把一个聚合口既当Peer-link又当DR口这在H3C M-LAG架构下是不允许的配置都做不上去。Peer-link是设备间协同通道DR口是对服务器侧的接入通道功能完全不一样必须分开。2.3 配置前的基础检查别急着敲命令先做三件恶心事但必须做的事第一备份现有配置。S7506E这种核心设备上配置往往积累了几年一个快速备份就能救命。第二检查历史配置里有没有同名的聚合口、残留的VLAN接口或成员口配置。经常遇到的情况是之前做过普通链路聚合把端口加进了别的聚合组现在直接加到M-LAG的聚合口会报错得先清掉旧配置。第三确认两台设备的软件版本。M-LAG对两端版本要求没有堆叠那么变态但差太多时DRCP协商和Keepalive协议报文行为可能有差异保险起见版本先对齐。顺便说一句如果是从一台旧设备上把配置原样复制到新设备务必先检查聚合口、VLAN、接口描述这些东西不要让历史包袱带进M-LAG域里。3. H3C交换机S-MLAG核心配置实操3.1 第一步Keepalive链路配置Keepalive链路在M-LAG里承担的角色是“分裂检测”。两台设备之间如果Peer-link断了Keepalive必须还能通信这样设备才能判断是对端挂了、还是只是聚合链路断了从而决定是否把DR口拉下来防止脑裂。我在SW1上配置如下# 创建VLAN 999 vlan 999 name KEEPALIVE # 创建VLAN三层接口 interface Vlan-interface 999 ip address 10.0.0.1 255.255.255.252 undo shutdown # 把物理口加入VLAN 999 interface Ten-GigabitEthernet1/0/25 port link-type access port access vlan 999 undo shutdown # 进入M-LAG视图配置Keepalive m-lag keepalive ip destination 10.0.0.2 source 10.0.0.1SW2上的配置类似但destination和source要互换m-lag keepalive ip destination 10.0.0.1 source 10.0.0.2很多初学者在这里容易犯迷糊destination到底填谁的地址记住一个原则——在每台设备上destination永远是对端的地址source永远是本机的地址。Keepalive链路不要用业务VLAN里的地址不要在两端走三层路由绕一大圈最好就是物理直连或在一个独立二层网段内。3.2 第二步Peer-link聚合口配置Peer-link是M-LAG域的数据面互联通道。DRCP协议报文、跨设备流量转发都走这条链路所以带宽要给够我建议最少双万兆聚合。SW1上的Peer-link配置如下# 创建三层聚合口配置为动态聚合模式 interface Bridge-Aggregation 1 link-aggregation mode dynamic m-lag peer-link port link-type trunk port trunk permit vlan all # 加入两个物理口 interface Ten-GigabitEthernet1/0/23 port link-aggregation group 1 undo shutdown interface Ten-GigabitEthernet1/0/24 port link-aggregation group 1 undo shutdownSW2上同样创建BAGG1做完全一样的配置。这里有两个细节必须注意一是peer-link口不要配成access口必须是trunk并且放通所有可能的业务VLAN。如果只放通当前业务VLAN以后新加VLAN时忘了更新故障场景下流量就会通过Peer-link传输失败形成黑洞。二是不要给Peer-link配IP地址、不要配OSPF之类的动态路由它不是业务三层口就干两件事跑DRCP、传跨设备流量。有兄弟在Peer-link上配了IP导致路由环路排查了半天其实从一开始就不应该这么做。3.3 第三步DR接口跨设备聚合口配置DR口是M-LAG里最核心的概念也叫DR组。它把两台交换机上各一个聚合口捆绑成一个跨设备的逻辑聚合口服务器看到的是一个LACP聚合组。SW1和SW2上的DR口编号必须一致我这里都使用BAGG 10DR组编号m-lag 1两者是对应关系。SW1配置# 创建动态聚合口绑定DR组 interface Bridge-Aggregation 10 link-aggregation mode dynamic m-lag 1 port link-type access port access vlan 100 # 服务器双网卡分别接到两台交换机SW1接XGE1/0/1和XGE1/0/2 interface Ten-GigabitEthernet1/0/1 port link-aggregation group 10 undo shutdown interface Ten-GigabitEthernet1/0/2 port link-aggregation group 10 undo shutdownSW2配置interface Bridge-Aggregation 10 link-aggregation mode dynamic m-lag 1 port link-type access port access vlan 100 interface Ten-GigabitEthernet2/0/1 port link-aggregation group 10 undo shutdown interface Ten-GigabitEthernet2/0/2 port link-aggregation group 10 undo shutdown注意两台设备上的m-lag编号必须相同否则DRCP协商不起来。你可以把m-lag 1理解为一个“M-LAG域内的聚合组ID”这个ID只需要在M-LAG域内唯一。另外如果业务里既有access口需求又有trunk口需求DR口类型要跟着业务走技术上支持access和trunk但两台设备DR口的类型必须一致一个配access另一个配trunk是起不来的。3.4 对端设备配置与状态确认两台设备都配置完成后先用检查命令看状态。下面这几个命令是我每次必敲的display m-lag verbose display m-lag summary display m-lag keepalive display link-aggregation verbose正常的输出应该看到检查项期望状态KeepaliveUP发送/接收计数都在增长Peer-linkUP聚合口Selected成员数≥1DR口状态ActiveKeepalive链路正常DR口成员端口均为Selected状态Peer-link成员口均为Selected状态我曾经踩过一个坑两台设备M-LAG配置看起来都对但display m-lag verbose显示Keepalive DOWN。一查发现是两台设备之间走了三层交换机中间设备没有放通VLAN 999Keepalive包根本没到对端。所以Keepalive链路尽量直连不要经过中间设备少一个环节就少一个故障点。4. 服务器bond4配置与联动验证4.1 bond4参数选择和内核模块网络侧S-MLAG做完服务器侧的bond4如果参数不对两边照样协商不起来。先说内核模块加载CentOS/RHEL和Ubuntu都有对应的配置方式。我用CentOS 7/8较多遇到Ubuntu 20.04/22.04的netplan配置也不难关键是几个参数的意义要搞清。bond4必须开启的模块参数包括参数推荐值说明mode4802.3ad动态链路聚合miimon100链路监测间隔100mslacp_ratefastLACP报文发送间隔1秒xmit_hash_policylayer34基于IP端口做负载分担updelay0链路恢复后立即启用downdelay0链路故障后立即停用xmit_hash_policy这个参数容易忽略。默认是layer2只看MAC哈希对于单台服务器访问不同网段的场景很容易出现一条链路负载高、另一条闲置的情况。改成layer34之后会综合源目IP和端口计算哈希负载会均衡得多。我在生产环境实测下来layer34配合M-LAG的跨设备负载分担效果最好。还有一个细节是lacp_rate。交换机侧H3C的dynamic聚合口默认LACP协商速率是slow30秒服务器如果配fast两边仍然能协商因为rate是各自独立发送LACPDU的。但为了故障收敛速度建议交换机上也调成fast。H3C命令是lacp period short在聚合口或成员口下配置send理论1秒收一次收敛快很多。4.2 bond4配置文件实例CentOS/RHEL的ifcfg方式如下。先建bond0vim /etc/sysconfig/network-scripts/ifcfg-bond0DEVICEbond0 NAMEbond0 TYPEBond BONDING_MASTERyes BOOTPROTOstatic IPADDR192.168.100.10 NETMASK255.255.255.0 GATEWAY192.168.100.1 ONBOOTyes MTU1500 BONDING_OPTSmode4 miimon100 lacp_ratefast xmit_hash_policylayer34然后配置两张物理网卡vim /etc/sysconfig/network-scripts/ifcfg-eno1DEVICEeno1 NAMEeno1 TYPEEthernet BOOTPROTOnone ONBOOTyes MASTERbond0 SLAVEyes另一张网卡eno2配置一样只是DEVICE和NAME不同。注意一定不要在从网卡上配IP地址IP地址只需要配在bond0上。如果你用的是NetworkManager建议干脆禁用或者通过nmcli来管理否则NetworkManager和network服务经常打架网卡起来一会又掉下去。Ubuntu的netplan配置也很简单network: version: 2 ethernets: eno1: dhcp4: false eno2: dhcp4: false bonds: bond0: interfaces: [eno1, eno2] addresses: [192.168.100.10/24] routes: - to: default via: 192.168.100.1 parameters: mode: 802.3ad mii-monitor-interval: 100 lacp-rate: fast transmit-hash-policy: layer34配置完成后Ubuntu执行netplan applyCentOS执行systemctl restart network然后看bond状态。4.3 上电验证与LACP协商确认服务器起来后第一步看bond0状态cat /proc/net/bonding/bond0重点看两行MII Status和Slave Interface。正常情况下两个slave都应该是upbond0的mode显示为IEEE 802.3ad Dynamic link aggregation。再看网卡实际协商速率ethtool eno1 | grep Speed ethtool eno2 | grep Speed如果一张网卡显示1000Mb/s另一张也应该是相同的速率出现Mismatch说明物理链路或交换机端口有问题。交换机侧再确认display link-aggregation verbose看到服务器两个成员口的状态都是SelectedLACP协商成功。此时随便ping一下网关应该完全无丢包。如果ping通但bond0里的两个slave一上一下优先检查服务器网卡和交换机端口是否都在同一个VLAN、是不是都做成了access口、物理层是否都协商正常。5. 故障切换测试与排错5.1 单根网线断开测试配置做完不能算完必须真刀真枪演练。第一个测试是断开服务器到SW1的那根网线观察bond0的状态变化和业务中断时间。我在实测中的预期表现是拔线的瞬间ping会出现0到1个丢包然后bond0里的eno1变为down流量全部走到eno2业务无感。这里有个关键点如果你发现丢包超过2个甚至中断了几秒优先排查两个地方一是服务器bond0的miimon是不是100二是交换机侧DR口有没有启用STP导致收敛慢。H3C的M-LAG体系下DR口接入服务器的端口建议关闭STP或者直接配成边缘端口。原因很简单DR口本身通过M-LAG机制实现了跨设备冗余STP在接入侧会引入额外的收敛延迟反而拖累切换速度。命令是interface Bridge-Aggregation 10 undo stp enable5.2 整台交换机宕机演练第二个测试更狠直接把SW1整机shutdown。此时服务器bond0两个slave中接SW1的那个网卡会在一秒内切换为down流量全部切换到接SW2的网卡。这个场景对M-LAG来说是最关键的因为对端SW2需要在检测到SW1失联后保持自己的DR口继续转发。如果SW2的DR口DOWN了那就说明M-LAG域状态判断有问题服务器会完全失去网络。实操时你可能会在SW2上看到DR口先短暂变为DOWN又自动恢复UP。这个过程其实是正常的Keepalive超时检测到对端失联后M-LAG会进入单机模式并把DR口重新激活。但如果DR口持续DOWN就要检查Keepalive和Peer-link配置了很可能是Keepalive地址配错或Peer-link承载VLAN不全导致的判断异常。恢复演练同样重要把SW1重新启动等M-LAG协商完成后服务器bond0的另一个slave会自动恢复UP两台交换机重新组成双活转发。整个过程不需要在服务器上做任何操作也不需要重启bond0。5.3 常见故障与排查命令故障排查有一套固定的思路我从高到低列一下优先级现象排查方向命令Keepalive DOWN地址是否对调、VLAN是否放通、物理链路display m-lag keepalivePeer-link成员口不Selected聚合口模式是否一致、成员口配置是否冲突display link-aggregation verboseDR口状态异常两台设备DR编号是否一致、两端VLAN/access配置是否一致display m-lag verbose服务器bond只有一个slave up交换机对应成员口状态、网卡物理协商display link-aggregation member-port故障切换时丢包严重STP是否关闭、lacp_rate是否fastdisplay stp briefM-LAG整体没起来两端软件版本、配置是否互相匹配display m-lag summaryMAD分裂场景再单独说一下。如果Peer-link断了但Keepalive正常两台设备都会认为自己是主设备这就是脑裂的前兆。H3C的机制是此时会保留一端转发、另一端把DR口DOWN掉。我遇到过一次因为光模块故障导致Peer-link中断的情况业务却没有中断靠的就是这个机制。所以Keepalive链路一定不能省它决定了M-LAG在异常状态下是继续干活还是两头一起出乱子。6. 避坑清单与经验总结6.1 设备侧最容易踩的五个坑第一个坑Peer-link忘放业务VLAN。很多兄弟配Peer-link时只想着“放通现有业务就够了”结果后面新增VLAN时忘了更新Peer-link故障切换后跨设备流量全断。Peer-link直接port trunk permit vlan all一劳永逸。第二个坑Keepalive和业务VLAN混用。Keepalive报文是可以被业务流量冲击的如果和业务VLAN共用链路一旦业务出现广播风暴Keepalive被阻塞M-LAG就会误判对端故障把DR口拉下来。隔离到最后用独立口或独立VLAN三层互联别心疼那几个端口。第三个坑两台设备DR组编号不一致。SW1上配了m-lag 1SW2上配了m-lag 2两边都显示配置成功但DRCP协商就是不通。这个检查只要看配置对比就能发现但出问题的时候真容易忽略。第四个坑旧聚合口配置冲突。核心设备上大概率有历史配置某个物理口之前已经被加入过别的聚合组现在直接加到BAGG 10会报错。需要先清掉旧的聚合组或从旧组中移除端口再执行link-aggregation group。第五个坑两台设备软件版本差距过大。M-LAG的Keepalive和DRCP报文在两个大版本之间可能有兼容性问题建议实施前先对齐版本。我之前碰到过一台V7一台V5的奇葩组合M-LAG硬是起不来后来查到版本不兼容才老老实实升级。6.2 服务器侧容易忽略的三个细节第一个细节NetworkManager和network服务冲突。CentOS上同时启用这两个服务网卡配置经常被NetworkManager覆盖bond0起来后slave总是掉。解决方法很简单要么用nmcli把两张网卡和bond0都纳管要么禁用NetworkManager老老实实走ifcfg。第二个细节MTU不一致。交换机侧业务VLAN如果开了巨型帧服务器bond0和物理网卡都要同步调整MTU否则大包全丢、小包正常排查起来特别迷惑。建议先在两端统一MTU为1500业务确需巨帧再单独调整。第三个细节服务器关机后再开机bond0起不来。这种情况经常是bonding模块没加载或者网卡驱动加载顺序变化导致slave网卡注册顺序异常。建议在modprobe配置里显式加载bonding模块并设置options bonding mode4 miimon100不要完全依赖ifcfg的BONDING_OPTS。6.3 运维层面的一些建议最后说点运维上的体会。M-LAG加bond4这套组合真正的难点不在配置本身而在变更管理和故障演练。我建议每半年做一次故障切换演练拔线、整机shutdown、恢复都形成记录。平时变更时尽量两台设备分开操作先做一台确认业务正常后再动另一台避免人为把双活改成双死。另外登录设备配置时手速快没有用命令敲之前先把拓扑和配置思路过一遍。H3C的Comware对M-LAG配置有严格的前后依赖Keepalive必须先通Peer-link其次最后才是DR口。按顺序配置出问题也容易定位。配置完成后立即备份再在维护窗口内观察一段时间确认无异常再关闭维护窗口。我用这套组合处理过的项目里只要规划时把VLAN、地址、聚合口编号这些基础信息列清楚实施过程通常很顺利。真正出问题的十有八九是历史配置残留和服务器侧bond参数细节。希望这篇记录能帮你少走点弯路有环境的话建议先在测试机上完整演练一遍再上生产。