【银河麒麟高级服务器操作系统实例】虚拟机桥接网络问题分析及处理

 更多银河麒麟操作系统产品及技术讨论，欢迎加入银河麒麟操作系统官方论坛

https://forum.kylinos.cn

了解更多银河麒麟操作系统全新产品，请点击访问

麒麟软件产品专区：https://product.kylinos.cn

开发者专区：https://developer.kylinos.cn

文档中心：https://document.kylinos.cn
 

服务器环境以及配置

现象描述

银河麒麟高级服务器操作系统V10SP2系统，使用kvm运行虚拟机，如果是物理机两个网口做成一个team，然后team接网桥，虚拟机再通过这个网桥连接网络，这种方式网络会有问题。

本地环境验证，使用配置方式一直有问题，采用nmcli如下配置：

物理机：

1、创建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

2、创建网桥

# mcli connection add type bridge con-name br1 ifname br1

配置网桥IP

3、添加team1到br1

# nmcli c mod team1 master br1

4、激活网络

# nmcli connection up team1

# nmcli connection up team1-port1

# nmcli connection up team1-port2

# nmcli connection up br1

虚拟机连接br1

图形化操作

实际测试下来，确实会发现网络不通，此时如把team1从网桥删掉，换成物理网口，网络就可以正常使用，单独配置team，也可以正常使用。

现象分析

1. 针对该问题，做了以下测试。
2. 启动虚拟机1，在宿主机上tcpdump分别在team1-slave1，team1-slave2，vnet0三个口抓icmp报文，虚拟机1里启动ping 网关ip，发现team1-slave1、team2-slave2几乎同时收到arp reply报文，但是vnet0没有收到该报文，只有arp request报文，所以虚拟机网络一直不正常。
3. 在宿主机做ifconfig team1-slave1 down，虚拟机网络恢复正常。
4. 在宿主机做ifconfig team1-slave1 up，虚拟机网络异常。
5. 在宿主机做ifconfig team1-slave2 down，虚拟机网络正常。
6. 宿主机把team1从网桥踢出，将一物理网卡加入网桥，虚拟机网络正常。

分析总结

根据上述分析结果，梳理网络拓扑，本地搭建环境复现问题，发现Linux bridge的fdb表存在问题：

图1 虚拟机mac地址

图二 宿主机mac地址

图三 网桥fdb表

由图三可见，虚拟机的mac地址，应与vnet0同属同一port，但实际却与team网卡同属同一port。故报文在二层即无法到达vnet0，符合上节的抓包现象。

进一步分析fdb表为何不对，梳理网络拓扑及报文路径：

由此可知，由于使用team0（roundrobin ）模式，虚拟机arp广播报文，经vnet0进入网桥，此时网桥mac学习到虚拟机的mac地址对应vnet0的port，此时fdb表是正确的。arp广播报文通过team网卡发出，由于是轮询模式，此时两个物理网卡均会发送arp广播报文。交换机收到物理网卡的广播报文后，会向所有端口进行转发，此时也会转发到team的另一slave网卡。此时网桥会收到该arp广播报文，并进行mac地址学习，记录虚拟机的mac地址对应team的port，此后fdb表便一直为错误的，后续报文均不通。

分析结果

通过上述分析，需要限制交换机将广播报文发回聚合端口，当服务器设置为mode0时，交换机需要设置为手动聚合模式。

后续计划与建议

如果使用mode0模式需要配置交换机为手动聚合模式，或者设置Linux网桥强制泛洪；如果使用mode1模式，交换机侧无需任何修改。