H3C S-MLAG与服务器bond4双活接入配置实战

干网络这行时间长了，你会发现一个特别普遍的场景：服务器做了双网卡绑定，上行却接了同一台交换机，结果交换机一宕机，业务照样全挂。我自己就处理过好几起这种“看似冗余、实则单点”的事故。后来在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适合横向高可用。两者对比如下：

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和接口规划表

配置之前先把台账列清楚。我习惯做一个这样的表格，实施时照着填参数就行：

这里要特别强调一下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.1

SW2上的配置类似，但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 shutdown

SW2上同样创建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 10，DR组编号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 shutdown

SW2配置：

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

正常的输出应该看到：

我曾经踩过一个坑：两台设备M-LAG配置看起来都对，但display m-lag verbose显示Keepalive DOWN。一查发现是两台设备之间走了三层交换机，中间设备没有放通VLAN 999，Keepalive包根本没到对端。所以Keepalive链路尽量直连，不要经过中间设备，少一个环节就少一个故障点。

4. 服务器bond4配置与联动验证

4.1 bond4参数选择和内核模块

网络侧S-MLAG做完，服务器侧的bond4如果参数不对，两边照样协商不起来。先说内核模块加载，CentOS/RHEL和Ubuntu都有对应的配置方式。我用CentOS 7/8较多，遇到Ubuntu 20.04/22.04的netplan配置也不难，关键是几个参数的意义要搞清。

bond4必须开启的模块参数包括：

xmit_hash_policy这个参数容易忽略。默认是layer2，只看MAC哈希，对于单台服务器访问不同网段的场景，很容易出现一条链路负载高、另一条闲置的情况。改成layer3+4之后会综合源目IP和端口计算哈希，负载会均衡得多。我在生产环境实测下来，layer3+4配合M-LAG的跨设备负载分担效果最好。

还有一个细节是lacp_rate。交换机侧H3C的dynamic聚合口默认LACP协商速率是slow（30秒），服务器如果配fast，两边仍然能协商，因为rate是各自独立发送LACPDU的。但为了故障收敛速度，建议交换机上也调成fast。H3C命令是lacp period short，在聚合口或成员口下配置，send理论1秒收一次，收敛快很多。

4.2 bond4配置文件实例

CentOS/RHEL的ifcfg方式如下。先建bond0：

vim /etc/sysconfig/network-scripts/ifcfg-bond0

DEVICE=bond0 NAME=bond0 TYPE=Bond BONDING_MASTER=yes BOOTPROTO=static IPADDR=192.168.100.10 NETMASK=255.255.255.0 GATEWAY=192.168.100.1 ONBOOT=yes MTU=1500 BONDING_OPTS="mode=4 miimon=100 lacp_rate=fast xmit_hash_policy=layer3+4"

然后配置两张物理网卡：

vim /etc/sysconfig/network-scripts/ifcfg-eno1

DEVICE=eno1 NAME=eno1 TYPE=Ethernet BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes

另一张网卡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: layer3+4

配置完成后，Ubuntu执行netplan apply，CentOS执行systemctl restart network，然后看bond状态。

4.3 上电验证与LACP协商确认

服务器起来后，第一步看bond0状态：

cat /proc/net/bonding/bond0

重点看两行：MII Status和Slave Interface。正常情况下两个slave都应该是up，bond0的mode显示为IEEE 802.3ad Dynamic link aggregation。再看网卡实际协商速率：

ethtool eno1 | grep Speed ethtool eno2 | grep Speed

如果一张网卡显示1000Mb/s，另一张也应该是相同的速率，出现Mismatch说明物理链路或交换机端口有问题。交换机侧再确认：

display link-aggregation verbose

看到服务器两个成员口的状态都是Selected，LACP协商成功。此时随便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 enable

5.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 常见故障与排查命令

故障排查有一套固定的思路，我从高到低列一下优先级：

MAD分裂场景再单独说一下。如果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 1，SW2上配了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 mode=4 miimon=100，不要完全依赖ifcfg的BONDING_OPTS。

6.3 运维层面的一些建议

最后说点运维上的体会。M-LAG加bond4这套组合，真正的难点不在配置本身，而在变更管理和故障演练。我建议每半年做一次故障切换演练，拔线、整机shutdown、恢复，都形成记录。平时变更时，尽量两台设备分开操作，先做一台，确认业务正常后再动另一台，避免人为把双活改成双死。

另外，登录设备配置时手速快没有用，命令敲之前先把拓扑和配置思路过一遍。H3C的Comware对M-LAG配置有严格的前后依赖，Keepalive必须先通，Peer-link其次，最后才是DR口。按顺序配置，出问题也容易定位。配置完成后立即备份，再在维护窗口内观察一段时间，确认无异常再关闭维护窗口。

我用这套组合处理过的项目里，只要规划时把VLAN、地址、聚合口编号这些基础信息列清楚，实施过程通常很顺利。真正出问题的，十有八九是历史配置残留和服务器侧bond参数细节。希望这篇记录能帮你少走点弯路，有环境的话建议先在测试机上完整演练一遍，再上生产。