0x0034's Blog.

Linux bond模式 丢包

字数统计: 572阅读时长: 2 min
2022/01/24

问题描述: 物理机存在双网卡Bond, 宿主机Ping 内部桥接虚拟机IP丢包严重.

网卡示意图


排查思路

思路1: 网络阻塞导致的丢包

查看网络连接数. 在我们的环境中存在大量的timewait.(当时timewait 高达几万).

1
cat /proc/net/nf_conntrack | awk '/^.*tcp.*$/ {count[$6]++} END {for(state in count) print state, count[state]}'

将如下内容追加到/etc/sysctl.conf

1
2
3
4
5
6
7
8
9
# 主动方的最后一个握手,默认是2MSL也就是120s, 这里改为30s
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30

# CLOSE_WAIT是被动方收到FIN发ACK,然后会转到LAST_ACK发FIN
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60

# 使用iptables对已建立的链接超过3600秒没有活动则清除掉
net.netfilter.nf_conntrack_tcp_timeout_established = 3600

过十分钟看一下链接数.
连接数

虽然连接数下去了但是问题还是没有解决.遂观察日志dmesg


思路2: dmesg排查

1
dmesg| tail -n 1000

dmesg

很明显 br0bond0 的mac地址相同, 但是, br0 本身就是bond0桥接的,没有设定过mac地址.
接着查看我们的bond0 proc 信息.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
cat /proc/net/bonding/bond0
Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eno1
MII Status: up
Speed: 100 Mbps
Duplex: full
Link Failure Count: 1
Permanent HW addr: 00:30:48:56:da:72

Slave Interface: eno2
MII Status: up
Speed: 100 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: 00:30:48:56:da:73

如上所示, Bond mode 为0 ,即负载均衡方式, 但是这个模式存在一个限制, 需要在交换机上做端口聚合. 而我们内网的傻瓜交换不支持这个功能. 遂将Bond的模式由 mode=0 ==> mode=1 的主备模式.

再次长ping, 问题解决.

bond的七种模式: https://blog.csdn.net/mingongge/article/details/114109117

七种模式工作原理: https://cloud.tencent.com/developer/article/1527586?from=15425

centos 端口聚合配置: https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/7/html/networking_guide/sec-using_channel_bonding

思路3: 禁止mac地址学习

arp

在如上的dmesg信息的截图中是接收了以自己地址作为源地址的数据包.遂检查网桥接口

1
brctl showstp br0 

br0网桥接口

可以看到arp的老化时间为300s.只需要禁用mac地址学习即可.

1
brctl setageing bro 0 

arp老化机制: https://juejin.cn/post/6844904166545080334

CATALOG
  1. 1. 排查思路
    1. 1.1. 思路1: 网络阻塞导致的丢包
    2. 1.2. 思路2: dmesg排查
    3. 1.3. 思路3: 禁止mac地址学习