虚拟机网络配置问题——SkyForm 应用平台使用过程中的一次排障案例
环境信息
-
Windows 虚拟机 IP 为 10.10.3.190，Linux 虚拟机为 10.10.3.61； -
两台机器看似在同一网段，但 ping 不通； -
Windows VM 的网卡绑定在vmbr0，而 Linux VM 等其他节点绑定在 vmbr1； -
Windows VM 使用的子网掩码是 /16，Linux VM 使用的是 /24。
-
在 PVE（Proxmox VE）虚拟化环境中，虚拟机要在同一个二层网络中互通，必须接入相同的网桥（vmbr）。 -
Windows VM 快照恢复后仍绑定在 vmbr0，而 Linux VM 在 vmbr1，因此二者物理上不在同一广播域，无法通信。
-
Linux VM：/24 → 10.10.3.0 – 10.10.3.255 -
Windows VM：/16 → 10.10.0.0 – 10.10.255.255
-
掩码不一致时，会导致双方对“是否在同一子网”的判断不一致：
-
情况 1：地址重叠（如 10.10.3.190 vs 10.10.3.61） → 双方都认为对方在本地子网，可以互通。 -
情况 2：地址不重叠（如10.10.4.x vs 10.10.3.61） → Windows 认为在本地，Linux 认为跨网段，回包会走默认网关 → 不通。
-
即便把 Windows VM 改到 vmbr1，一开始仍然不通。 -
这是因为：
-
PVE 网桥 vmbr1 的 FDB（Forwarding Database）里还没学习到新的 MAC–端口映射，仍然认为该 VM 的 MAC 属于 vmbr0。 -
Linux VM 10.10.3.61 的 ARP 缓存里也可能还留着旧的 MAC 映射。
-
只有当 Windows 重新发 ARP 请求（或 FDB aging 超时，默认 300 秒），PVE 才更新映射，通信才能恢复。
-
将 Windows VM 网卡从 vmbr0 改为 vmbr1，与 Linux VM 接入同一桥接网络； -
将 Windows VM 的子网掩码改为 /24，与 Linux VM 保持一致； -
清理 ARP/FDB 缓存或等待刷新，确保映射正确更新。 完成以上步骤后，虚拟机间的通信恢复正常，SkyForm平台上的作业提交流程也随之恢复。
-
Windows 已经接到 vmbr1，但 PVE 的转发表（FDB）可能还认为这个 MAC 在 vmbr0。 -
结果：包被转发到错误的桥接口 → Linux 收不到。 -
一旦触发新的 ARP/FDB 更新 → 正确映射 → 双向通信恢复。
-
发包：主机先判断目标是否在本地子网 → 决定直连还是发给网关。 -
收包：目标主机根据自身掩码判断源地址是否同子网 → 决定是否直连回包。 -
回包：通信能否成功取决于双方判断是否一致，并且 PVE 的 FDB 映射是否正确。
本案例再次证明，深入理解发包、收包、回包机制以及虚拟化平台的FDB缓存机制，是快速定位并解决网络问题的关键。
如在SkyForm应用平台使用过程中遇到问题，或有定制化需求，可通过联系我们的技术团队获取支持。
- 2022-03-22
- 2022-03-22
- 2022-03-22
- 2022-03-22
- 2022-03-18
- 2022-03-18
