HOWTO: 解决 Windows 11 24H2 Hyper-V VM 中 Windows DHCP Server 无法分发 IP 的问题

        gOxiA 今天要分享的是近期遇到的一个 DHCP Server 和 Hyper-V VM 相关的棘手问题，环境其实很简单！宿主机系统为 Windows 11 24H2，安装了 Hyper-V 并创建了 Private Switch 用于 VM 之间通信，VM 分别是一个 Windows Server 2025（以下简称 WS2025）和一个 Windows 11 24H2（以下简称 Client），其中 WS2025 基于工作组环境，并安装了 DHCP 和 WDS Role，在 DHCP 上配置了一个作用域，WDS 主要提供 PXE Boot。检查各项服务和日志都没有异常，但是很奇怪！通过另一个 VM 执行 PXE Boot 时失败，没有任何服务器响应。之后进入这个 VM 的 Windows 11 24H2 系统，发现无法获取 IP，但是如果手动配置 IP，Client 即可以 Ping 通 WS2025。为了排除 WS2025 DHCP 问题，又导入了以前能够正常使用的 VM 模板，其 DHCP Server 基于 Windows Server 2016，但仍旧无法正常分发 IP，只能手动配置 IP 进行通信。为了进一步的测试验证，又安装了一个 Ubuntu Server 24.04.1，并配置了 DHCP 和 PXE，却能够正常工作。

        到底是哪里出了问题呢？！

        怀疑过 Hyper-V 自身配置，Hyper-V Virtual Switch 是基于软件的第二层以太网网络交换机，包括了以编程方式管理且可扩展的功能，还提供了安全、隔离和服务级别的策略。对应的 Virtual Network Adapter 也提供了丰富的功能选项，在检查并测试了它们的相关功能选项后，均没能解决。

        也怀疑过是 Hyper-V 宿主 Windows 11 24H2 自身的问题，但苦于重装系统麻烦，所以最终选择用抓包的方式排查，抓包的方案是直接在 WS2025 中安装 Wireshark 并执行抓包。非常神奇！在进行抓包时 WS2025 竟然能够正常分发 IP 了，从截图可见 DHCP Offer 和 DHCP ACK，其中 DHCP Offer 表示 DHCP Server 正确接收到请求并发出响应，DHCP ACK 表示 DHCP Server 确认 IP 租用成功。

        为什么 Wireshark 抓包时 DHCP 就能工作正常呢？！

1. Promiscuous Mode，抓包时 Wireshark 将网卡置于混杂模式，让它可以接收所有流经网卡的流量，包括目标不是本设备的数据包（如广播包）。

2. 绕过硬件的 Offload 功能，暂时禁用如 UDP/TCP Checksum Offload，可以让我们捕获到未处理过的原始数据包。

3. 调整网络堆栈行为，以强制网卡处理所有数据包。

        如何做进一步的排错呢？！

        前面提到开启 Wireshark 抓包时 DHCP 可正常分发 IP，说明当前 WS2025 的 DHCP Role 配置正确，且工作正常；Ubuntu Server 默认可正常执行 DHCP 分发，可排除 Hyper-V Virtual Switch 配置；那剩下的就是为 VM 配置的 Virtual Network Adapter 了，前面在 Hyper-V 控制台对 VM 的虚拟网卡进行过调整测试，均未能解决。剩下最后的就是 VM 系统环境中的 Microsoft Hyper-V Network Adapter 驱动部分的高级选项了。经检查包含以下可以的选项。

1. IPSec Offload

2. IPv4 checksum offload

3. Jumbo Packet

4. Large Send Offload Version 2 (IPv4)

5. Large Send offload version 2 (IPv6)

6. Network Direct (RDMA)

7. Packet Direct

8. Receive Side Scaling

9. Recv Segment Coalescing (IPv4)

10. Recv Segment Coalescing (IPv6)

11. RSS Profile

12. TCP Checksum offload (IPv4)

13. TCP Checksum offload (IPv6)

14. UDP Checksum offload (IPv4)

15. UDP Checksum offload (IPv6)

        结合前面 Wireshark 抓包时的情况，重点锁定在以下三个方面：

1. Large Send Offload Version 2，将大数据包的分段操作卸载到网卡硬件上，提高性能。对于 DHCP 这类的广播流量，分段操作可能不适用，如果网卡在广播包处理上有问题，可能导致 DHCP Discover 丢失。

2. Recv Segment Coalescing，将接收的小数据包合并成更大的包以减少处理次数。广播包可能在合并过程中丢失或被延迟处理。

3. UDP Checksum Offload，将 UDP 数据包的校验和计算卸载到网卡硬件上。DHCP 使用 UDP 协议，如果校验和计算错误，可能导致 DHCP Discover 被识别为无效包。

        在研读 Hyper-V Switch 技术文档时留意到不同操作系统版本中，其 NDIS 版本也有所不同，果然在“Introduction to NDIS 6.89”一文中了解到 Windows 11 24H2 使用的便是 NDIS 6.89，而在功能更新中提到了“UDP Receive Segment Coalescing Offload (URO)”，从 Windows 11 24H2 开始，UDP接收段合并卸载使网卡能够合并 UDP 接收段，即将来自同一流中匹配一组规则的 UDP 数据报组合到一个逻辑上连续的缓冲区中。然后，这些组合的数据报将作为单个大数据包指示给 Windows 网络栈。合并 UDP 数据报可降低在高带宽流中处理数据包的 CPU 成本，从而提高吞吐量并减少每个字节的周期数。看来非常适合游戏服务器、实时视频流传输和PXE Boot。

        此外，在文中 Checksum validation and indication 部分的阐述，也给出了进一步的排错方向。OK！至此顿悟，一番折腾后问题也终于解决。