# **Bond****模式4****协商不通排查过程** | 适用范围 | 适用版本 | 人员 | 发布时间 | 文档版本 |备注 | | --- | --- | --- | --- | --- |--- | | 服务器操作系统 | V10、V10-SP1、V7 | 王国武 |2022.3.1| V1.0|发布| ## 第一章 问题现象 Bond4模式协商不起来，配置好后网络不通 ## 第二章 问题分析过程 查看/proc/net/bonding/bond0 状态，发现协商不起来，抓包看发现只有交换机在发包，而我们的设备未发送LACPDU报文。 结合内核开源代码分析，ad\_tx\_machine函数无法工作，打印日志发现port->sm\_tx\_timer\_counter=0；  这个函数由于那个if条件不满足，进而导致一些变量无法初始化，从而无法正常工作。 分析sys\_mac\_addr赋值的地方，在配置bond params时，会调用 bond\_3ad\_update\_ad\_actor\_settings函数更新该值。 接下来分析添加从接口的函数bond\_enslave，  首次添加从接口若MAC类型是RANDOM时，会更新成从接口的MAC地址。也就是说，如果这里更新了MAC地址，之前那个初始化函数（bond\_3ad\_initialize）就可以正常执行了。 那继续分析接口MAC地址的类型，  有如上四种，0是物理口的，这里不讨论。1是创建虚拟口时，若未指定mac则内核随机分配一个6Byte的MAC。2是bond口设置为从接口的MAC地址时，此时对于bond而言就是该类型。3是应用层调用了ioctl/netlink等API接口修改了接口MAC。而目前麒麟系统看cat /sys/class/net/bond0/addr\_assign\_type是3，说明有应用层修改了该MAC，后续分析是systemd-udev修改的，udev根据/etc/systemd/network,/usr/lib/systemd/network的link文件去配置mac的，  MACAddressPolicy那个策略起了作用。 ## 第三章 问题结论及方案 基于上述分析，阻止udev去修改bond口的MAC就可以了，对应的team口也需要考虑到，现有方案如下 方案1：修改MACAddressPolicy = none ；华为openEuler用的该策略 方案2：添加优先级更高的link配置，针对bond、team特殊配置，如下