1. 问题现象与复现最近在银河麒麟高级服务器操作系统V10SP2上部署KVM虚拟机时遇到了一个奇怪的网络问题。具体场景是这样的我们在物理机上用两个网口ens224和ens256配置了一个Team模式的网络聚合使用roundrobin负载均衡然后把这个Team接口加入网桥br1最后让虚拟机通过这个网桥连接网络。按理说这种配置应该能正常工作但实际测试发现虚拟机完全无法访问外部网络。我按照标准流程做了以下配置# 创建team及slave nmcli connection add type team con-name team1 ifname team1 config {runner: {name: roundrobin}, link_watch: {name: ethtool}} nmcli connection add type team-slave con-name team1-port1 ifname ens224 master team1 nmcli connection add type team-slave con-name team1-port2 ifname ens256 master team1 # 创建网桥并配置IP nmcli connection add type bridge con-name br1 ifname br1 nmcli c mod team1 master br1 # 激活所有网络配置 nmcli connection up team1 nmcli connection up team1-port1 nmcli connection up team1-port2 nmcli connection up br1配置完成后虚拟机确实能获取IP地址但就是无法ping通网关。有趣的是如果把team1从网桥中移除改用单个物理网口比如ens224直接接入网桥虚拟机网络就立即恢复正常。这说明问题出在Team模式与网桥的交互上。2. 故障排查过程2.1 初步抓包分析为了定位问题我在宿主机上进行了详细的抓包分析。首先启动一个测试虚拟机然后在宿主机上同时开启三个抓包会话# 在team的两个slave接口和虚拟机的vnet接口上抓ICMP包 tcpdump -i ens224 icmp -w slave1.pcap tcpdump -i ens256 icmp -w slave2.pcap tcpdump -i vnet0 icmp -w vnet.pcap 然后在虚拟机内部ping网关地址。观察抓包结果发现ens224和ens256几乎同时收到了ARP回复报文vnet0接口只看到了ARP请求完全没有收到ARP回复物理网络层面交换机能收到并处理所有报文这个现象非常有意思说明问题出在宿主机内部的网络转发环节。进一步测试发现如果执行ifconfig ens224 down虚拟机网络立即恢复正常重新ifconfig ens224 up后问题又会出现换成单个物理网口接入网桥问题不会出现2.2 深入分析FDB表通过brctl showmacs br1命令查看网桥的MAC地址学习表(FDB)发现了关键线索。正常情况下虚拟机的MAC地址应该与vnet0接口关联但实际显示它却与team接口关联了。这就是为什么报文无法正确送达虚拟机的原因。为了理解这个异常我们需要梳理报文流向虚拟机发送ARP请求通过vnet0进入网桥网桥正确学习到虚拟机MAC对应vnet0端口此时FDB表是正确的ARP请求通过team接口发出由于是roundrobin模式两个物理网卡都会发送ARP请求交换机收到ARP请求后会广播到所有端口包括team的另一个slave接口网桥从另一个slave接口收到ARP请求错误地更新了FDB表将虚拟机MAC与team接口关联3. 问题根源与解决方案3.1 根本原因分析问题的本质在于Linux网桥的MAC学习机制与Team模式的roundrobin策略产生了冲突。具体来说Team的roundrobin模式会轮流使用两个物理网卡发送数据包交换机的行为收到广播包后会泛洪到所有端口网桥的学习机制会根据报文入接口更新MAC地址表这种组合导致网桥不断被欺骗错误地更新MAC地址表。当交换机把广播包从team的另一个接口发回来时网桥会误认为虚拟机MAC对应的是team接口而非vnet0接口。3.2 解决方案与实践根据不同的使用场景我们有两种解决方案方案一修改交换机配置推荐# 如果使用Team的roundrobin模式(mode0)需要将交换机端口配置为静态聚合模式 # 以华为交换机为例 interface Eth-Trunk1 mode lacp-static这样配置后交换机会把两个物理端口视为一个逻辑端口不会出现广播报文环回的情况。方案二调整Linux网桥配置# 强制网桥对所有未知单播和组播流量进行泛洪 echo 1 /sys/class/net/br1/bridge/group_fwd_mask echo 1 /sys/class/net/br1/bridge/multicast_router这种方法虽然能解决问题但会增加网络流量不适合高负载环境。4. 其他Team模式的注意事项除了roundrobin模式外银河麒麟服务器OS还支持其他几种Team模式它们的网络配置也有所不同4.1 activebackup模式# 创建activebackup模式的Team nmcli connection add type team con-name team1 ifname team1 config {runner: {name: activebackup}}这种模式下只有一个网卡处于活动状态不会出现roundrobin的问题。但需要注意交换机不需要特殊配置故障切换时会有短暂中断建议配合LLDP或BFD实现快速检测4.2 loadbalance模式# 创建loadbalance模式的Team nmcli connection add type team con-name team1 ifname team1 config {runner: {name: loadbalance}}这种模式需要交换机支持LACP协议两端配置必须匹配需要额外的哈希策略配置5. 最佳实践与经验分享在实际生产环境中部署KVM虚拟机桥接网络时我总结了以下几点经验网络拓扑规划简单场景优先使用单个物理网卡桥接需要冗余时考虑使用activebackup模式高带宽场景建议使用loadbalanceLACP故障排查工具箱# 查看网桥状态 brctl show brctl showmacs br1 brctl showstp br1 # 查看Team状态 teamdctl team1 state view # 网络诊断 ip -d link show ethtool -S ens224性能调优参数# 调整网桥缓存 echo 1048576 /sys/class/net/br1/bridge/max_size # 禁用IGMP snooping如果不需要 echo 0 /sys/class/net/br1/bridge/multicast_snooping监控建议定期检查FDB表是否正确监控网桥转发丢包计数记录Team成员切换事件在实际运维中我们还发现银河麒麟服务器OS的某些内核版本对Team模式的支持有细微差别。建议在重大升级前先在测试环境验证网络配置。如果遇到类似问题可以尝试升级到最新SP版本或应用最新的内核补丁。
【银河麒麟服务器OS实战】KVM虚拟机桥接网络故障排查与修复指南
1. 问题现象与复现最近在银河麒麟高级服务器操作系统V10SP2上部署KVM虚拟机时遇到了一个奇怪的网络问题。具体场景是这样的我们在物理机上用两个网口ens224和ens256配置了一个Team模式的网络聚合使用roundrobin负载均衡然后把这个Team接口加入网桥br1最后让虚拟机通过这个网桥连接网络。按理说这种配置应该能正常工作但实际测试发现虚拟机完全无法访问外部网络。我按照标准流程做了以下配置# 创建team及slave nmcli connection add type team con-name team1 ifname team1 config {runner: {name: roundrobin}, link_watch: {name: ethtool}} nmcli connection add type team-slave con-name team1-port1 ifname ens224 master team1 nmcli connection add type team-slave con-name team1-port2 ifname ens256 master team1 # 创建网桥并配置IP nmcli connection add type bridge con-name br1 ifname br1 nmcli c mod team1 master br1 # 激活所有网络配置 nmcli connection up team1 nmcli connection up team1-port1 nmcli connection up team1-port2 nmcli connection up br1配置完成后虚拟机确实能获取IP地址但就是无法ping通网关。有趣的是如果把team1从网桥中移除改用单个物理网口比如ens224直接接入网桥虚拟机网络就立即恢复正常。这说明问题出在Team模式与网桥的交互上。2. 故障排查过程2.1 初步抓包分析为了定位问题我在宿主机上进行了详细的抓包分析。首先启动一个测试虚拟机然后在宿主机上同时开启三个抓包会话# 在team的两个slave接口和虚拟机的vnet接口上抓ICMP包 tcpdump -i ens224 icmp -w slave1.pcap tcpdump -i ens256 icmp -w slave2.pcap tcpdump -i vnet0 icmp -w vnet.pcap 然后在虚拟机内部ping网关地址。观察抓包结果发现ens224和ens256几乎同时收到了ARP回复报文vnet0接口只看到了ARP请求完全没有收到ARP回复物理网络层面交换机能收到并处理所有报文这个现象非常有意思说明问题出在宿主机内部的网络转发环节。进一步测试发现如果执行ifconfig ens224 down虚拟机网络立即恢复正常重新ifconfig ens224 up后问题又会出现换成单个物理网口接入网桥问题不会出现2.2 深入分析FDB表通过brctl showmacs br1命令查看网桥的MAC地址学习表(FDB)发现了关键线索。正常情况下虚拟机的MAC地址应该与vnet0接口关联但实际显示它却与team接口关联了。这就是为什么报文无法正确送达虚拟机的原因。为了理解这个异常我们需要梳理报文流向虚拟机发送ARP请求通过vnet0进入网桥网桥正确学习到虚拟机MAC对应vnet0端口此时FDB表是正确的ARP请求通过team接口发出由于是roundrobin模式两个物理网卡都会发送ARP请求交换机收到ARP请求后会广播到所有端口包括team的另一个slave接口网桥从另一个slave接口收到ARP请求错误地更新了FDB表将虚拟机MAC与team接口关联3. 问题根源与解决方案3.1 根本原因分析问题的本质在于Linux网桥的MAC学习机制与Team模式的roundrobin策略产生了冲突。具体来说Team的roundrobin模式会轮流使用两个物理网卡发送数据包交换机的行为收到广播包后会泛洪到所有端口网桥的学习机制会根据报文入接口更新MAC地址表这种组合导致网桥不断被欺骗错误地更新MAC地址表。当交换机把广播包从team的另一个接口发回来时网桥会误认为虚拟机MAC对应的是team接口而非vnet0接口。3.2 解决方案与实践根据不同的使用场景我们有两种解决方案方案一修改交换机配置推荐# 如果使用Team的roundrobin模式(mode0)需要将交换机端口配置为静态聚合模式 # 以华为交换机为例 interface Eth-Trunk1 mode lacp-static这样配置后交换机会把两个物理端口视为一个逻辑端口不会出现广播报文环回的情况。方案二调整Linux网桥配置# 强制网桥对所有未知单播和组播流量进行泛洪 echo 1 /sys/class/net/br1/bridge/group_fwd_mask echo 1 /sys/class/net/br1/bridge/multicast_router这种方法虽然能解决问题但会增加网络流量不适合高负载环境。4. 其他Team模式的注意事项除了roundrobin模式外银河麒麟服务器OS还支持其他几种Team模式它们的网络配置也有所不同4.1 activebackup模式# 创建activebackup模式的Team nmcli connection add type team con-name team1 ifname team1 config {runner: {name: activebackup}}这种模式下只有一个网卡处于活动状态不会出现roundrobin的问题。但需要注意交换机不需要特殊配置故障切换时会有短暂中断建议配合LLDP或BFD实现快速检测4.2 loadbalance模式# 创建loadbalance模式的Team nmcli connection add type team con-name team1 ifname team1 config {runner: {name: loadbalance}}这种模式需要交换机支持LACP协议两端配置必须匹配需要额外的哈希策略配置5. 最佳实践与经验分享在实际生产环境中部署KVM虚拟机桥接网络时我总结了以下几点经验网络拓扑规划简单场景优先使用单个物理网卡桥接需要冗余时考虑使用activebackup模式高带宽场景建议使用loadbalanceLACP故障排查工具箱# 查看网桥状态 brctl show brctl showmacs br1 brctl showstp br1 # 查看Team状态 teamdctl team1 state view # 网络诊断 ip -d link show ethtool -S ens224性能调优参数# 调整网桥缓存 echo 1048576 /sys/class/net/br1/bridge/max_size # 禁用IGMP snooping如果不需要 echo 0 /sys/class/net/br1/bridge/multicast_snooping监控建议定期检查FDB表是否正确监控网桥转发丢包计数记录Team成员切换事件在实际运维中我们还发现银河麒麟服务器OS的某些内核版本对Team模式的支持有细微差别。建议在重大升级前先在测试环境验证网络配置。如果遇到类似问题可以尝试升级到最新SP版本或应用最新的内核补丁。
