FusionAccess R3C00，虚拟机之间业务IP互ping丢包严重

FusionAccess R3C00 虚拟机之间业务IP互ping丢包严重
1. 同一PortGroup内，用户虚拟机不能互通，但都可分别ping通网关；
2. 基础架构虚拟机之间互ping，总会有1%~3%的丢包;
3. 迁移至同一台CNA，问题依旧。

无

可能问题点检查如下：
1. 检查服务器物理连线——正常；
2. 交换机配置错误——使用两个笔记本直连交换机网口，相互之间可以正常ping通；
3. 虚拟机所属Portgroup——创建的用户虚拟机，基础架构虚拟机的业务平面同属Portgroup_102；
4. 虚拟机PVdriver驱动异常——检查Xen网卡驱动状态正常，重新安装问题依旧。
5. 虚拟机防火墙未关闭——检查发现已关闭；
6. 把问题虚拟机迁移到同一台CNA上，以上问题依旧；
7. 在交换机上ping问题VM也不通——此时发现问题虚拟机的MAC有漂移现象（infocenter enable后，可以看到有端口down或up，对应的MAC是问题VM的），即发现VM MAC的port在变化，推测网口绑定错误导致。

FusionCompute GPI手册，“操作与维护—>主机和集群管理—>系统接口管理—>绑定网口”章节，注意：
在轮询模式和基于源目的MAC负荷分担模式下，需要在交换机上做端口汇聚配置，即将主机待绑定的网口在对端交换机上的端口配置到同一个Eth-trunk，否则会导致网络通信闪断。

8. 检查发现服务器eth4和eth5（即业务平面网口）绑定关系为轮询，但是上联交换机的端口并未配置Eth-trunk。将该绑定模式改为主备，再次检查互ping，则通信正常。

9. 为什么当虚拟机在同一台CNA上也会发生丢包或ping不同呢？VM的通信不是在CNA内部吗，与上层交换机何关？
a. CNA中的虚拟机交换机 （OVS）也内部也有MAC_PORT 表，并有老化时间。
b. 如果端口绑定轮询，而对端没有配置Eth-Trunk ，会导致虚拟机内部的广播报文在绑定的2个网卡中的一个发出，而从另外一个网卡又收到该报文。
c. 第2点会导致OVS中的MAC_PORT 会混乱，MAC_PORT 表有老化时间，老化后才会刷新，所以虚拟机内部的会时通时不通。
其实就是说，这个OVS与物理交换机之间也是有MAC_PORT 学习的，当服务器网口绑定轮询，但交换机网口未做Eth-truck，交换机的MAC_PORT 表会因服务器轮询网口发包而更新，从而引起OVS的MAC_PORT 也变化，混乱之后就丢包，甚至不通。

可能原因：
1. 服务器物理连线异常；
2. 交换机配置错误；
3. 虚拟机所属Portgroup不一致；
4. 虚拟机PVdriver驱动异常；
5. 虚拟机防火墙未关闭。

1. 严格遵守GPI的配置要求；
2. 建议产品可在IU界面添加说明，或在点击配置后做远端Eth-truck校验。