none
Hyper-V build 1703 generation 2 PXE has faulty ARP implementation

    Pergunta

  • Since build 1703 came out for Windows 10 Enterprise x64, with Hyper-v enabled, the ARP protocol does not work correctly in a Gen2 vm during a PXE boot. The result is that the DHCP protocol does not work in a gen2 vm, and thus, pxe booting is broken in a gen2 vm on the 1703 build.

    Host and guest are on subnet: 10.1.29.x /24
    DHCP server IP: 10.1.1.3
    PXE server IP: 10.1.1.3

    Here is correct ARP behavior, on a gen1 vm, notice arp for default gateway mac address, and subsequent successful DHCP, then successful download from the WDS server at 10.1.1.3.

    gen1-vmguest-1703host-ARP-correct

    Here is the faulty arp behavior as found in a Gen2 vm on the same host as above. Notice the ARP protocol trying to get the mac address of a remote subnet IP. Anyone that understands the ARP protocol recognizes immediately that this can never work.

    gen2-vmguest-1703host-ARP-failure

    Somewhere during the 1703 dev cycle this ARP regression was introduced. This needs to be investigated by the developers as there is no way to "configure" how hyper-v's gen2 embedded PXE code implements the ARP protocol.

    Please don't comment regarding "how to pxe boot in hyper-v" this PXE infrastructure is perfect. UEFI and BIOS based physical PCs on the 10.1.29.x subnet can PXE boot just fine from 10.1.1.3. Additionally, reverting the host hyper-v OS back to 1607 build, gen2 vms can successfully PXE boot. The ARP traffic change is the smoking gun for this regression.

    This ARP bug is only present in build 1703, with a generation 2 vm.

    Hope this is useful to help get this critical regression bug fixed.

    -Ben

    sexta-feira, 23 de junho de 2017 19:24

Todas as Respostas

  • Hi peacepenguin,

    Thanks for sharing the information with us. We are trying to reproduce the environment, if we get any result, we'll feedback as soon as possible.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    segunda-feira, 26 de junho de 2017 01:26
    Moderador
  • Hi peacepenguin,

    After some test and research, seems you are right, we will try to report this behavior to our Product Team for further confirmation. We totally understand the inconvenience this issue has brought to you, your kind understanding is appreciated. We will keep pushing and tracking the process.

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    segunda-feira, 26 de junho de 2017 09:57
    Moderador
  • Hi Anne,

    Any updates on this issue?

    Also can I ask another question. Does the Gen 2 UEFI framework support DHCP services for Network Unlock at boot?

    segunda-feira, 17 de julho de 2017 22:30
  • Any further updates? 

    I just ran into this bug myself trying to PXE boot a new VM after upgrading the host machine to Win10 1703.

    Can confirm that physical computers can still PXE with UEFI on my network.

    terça-feira, 1 de agosto de 2017 05:40
  • I'm also having the same issue. I can PXE boot everywhere else in my environment, except on a Windows 10 1703 Hyper-V VM. Packet traces show the same as Ben has posted. ARP requests for the IP address of the PXE server (located in a different subnet), rather than the default gateway.
    segunda-feira, 7 de agosto de 2017 20:01
  • Hi peacepenguin,

     

    This issue has been resolved as of build 16230. Newer builds are available as part of the Windows Insider Program that include this fix.

     

    Thanks,

    SteVen

    quinta-feira, 24 de agosto de 2017 20:55
  • Hello SteVen,

    we have Windows 10 1709 (16299) fresh installation with VM Gen2 config version 8.2, and cant still PXE boot.
    If I create Gen1 VM...PXE boot works.

    Please can You confirm, or anybody, if its truly resolved?

    Thanks,

    Lubos

    sexta-feira, 1 de dezembro de 2017 23:18
  • I can confirm this bug was never resolved - typical Microsoft sticking their heads in thh sand and ignoring users - they just want to ignore us until the next version comes out crossing their fingers that "someone" resolved the issue.  As someone that has worked on the support side of Microsoft i can honesty say, they dont care in the slightest about you mate.... sorry it sucks but hey who are you?  just a consumer who paid for their product.  You don't count unless your a business.

    • Editado kroix0078 segunda-feira, 26 de fevereiro de 2018 07:48
    segunda-feira, 26 de fevereiro de 2018 07:47
  • This is still broken, what a joke.
    quarta-feira, 18 de abril de 2018 15:06
  • 1803 and I get the same result as before, it is still not working with gen2 vm's.
    quarta-feira, 16 de maio de 2018 10:09
  • I have run into a similar problem, but I'm not sure it is identical since my WDS and DHCP servers are on the same subnet.  The error I get with Gen 2 VMs is:

    1. Network Adapter (00155D834F2C)           There was a TFTP error.
    2. SCSI Disk (0,0)    No UEFI-compatible file system was found.

    But, a Gen 1 VM boots just fine.  I'm using Windows Server 2016 for the Hyper-V host, and both my WDS server and DHCP server are also Server 2016 VMs. The client VM is Windows 10 1803.

    I'm investigating this and will provide details about what I find.

    -Greg



    há 21 horas 57 minutos