none
Bug in Hyper-V: Network Bridge's ARP proxying broken in certain scenarios

    General discussion

  • Edit

    I am quite sure now this is a bug. The ARP proxying does not work for VMs if the packet-recipient is not directly attached to the external vswitch that is bridged to the wifi-nic!

    /Edit

    I am running a test lab on my Windows 8.1 using Hyper-V.

    My problem is, that the virtual LAN has limited connectivity, when the external vSwitch is configured to use the wifi interface, instead of the cable interface. I am troubleshooting this issue for hours now and I reached the point where I believe the Network Bridge, that is created by the Hyper-V Virtual Switch Manager, is not forwarding packets.

    Pings are delivered from 192.168.178.2 to 192.168.178.1 and back again.

    Pings from 192.168.0.10 are delivered to 192.168.178.1, and the reply does reach the wifi interface …

    == Trace on the WiFi interface ==
    Here you see a log of the trace on the WiFi interface of the Hyper-V-Host,
    while 192.168.0.10 is pinging 192.168.178.1

    No Time Source Destination HW Source HW Destination Protocol Info 3 0.003340000 192.168.0.10 192.168.178.1 24:65:11:cc:c0:9e 24:65:11:2b:35:e4 ICMP Echo (ping) request id=0x0001, seq=44/11264, ttl=127 (reply in 4) 4 0.006094000 192.168.178.1 192.168.0.10 24:65:11:2b:35:e4 24:65:11:cc:c0:9e ICMP Echo (ping) reply id=0x0001, seq=44/11264, ttl=64 (request in 3) 5 0.006152000 192.168.178.1 192.168.0.10 24:65:11:cc:c0:9e 24:65:11:2b:35:e4 ICMP Echo (ping) reply id=0x0001, seq=44/11264, ttl=64

    … but is never forwarded to the Network Bridge interface.

    == Trace on the Network Bridge interface ==
    Here you see a log of the trace on the Network Bridge interface of the Hyper-V-Host,
    while the Hyper-V-Host is pinging 192.168.178.1 (#1)
    and the 192.168.178.2 is pinging 192.168.178.1 (#7)
    -> Note: The ping-reply from 192.168.178.1 to 192.168.0.10 is missing!

    1 0.000000000 192.168.178.1 192.168.178.21 24:65:11:2b:35:e4 24:65:11:cc:c0:9e ICMP Echo (ping) reply id=0x0001, seq=9/2304, ttl=64 7 7.852500000 192.168.178.1 192.168.178.2 24:65:11:2b:35:e4 00:15:5d:b2:21:18 ICMP Echo (ping) reply id=0x0001, seq=439/46849, ttl

    How do I solve this problem?








    Monday, July 07, 2014 1:35 PM

All replies

  • Hi,

    As you can see the protocols bounded to "network bridge" , there are two protocols and one of the two is "Microsoft mac bridge" .

    Based on my test (Atheros AR9485) and understanding  ,  the function of mac bridge  is like "NAT" , source MAC of every VM's traffic will be changed to the physical MAC of Wireless NIC .

    First , if I ping outside machine from the VM , traffic only can be captured on physical Wireless NIC .

    Second , When I ping outside machine from the host , traffic can be captured on physical wireless NIC and external  Vswitch.

    When I ping host from VM ,the traffic can be captured on virtual switch .

    It seems that the VM's traffic which is going to outside  was sent to "network bridge" directly  then sent out over physical NIC .

    As a result , when I check the ARP table on the other physical machine , there is a same MAC (WNIC's MAC) corresponds to multi IPs .

    (I think the "network bridge" is a device re-writing the MAC address and delivering the traffic but I can not select it in network monitor .)

    Hope it helps

    Best Regards

    Elton Ji


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

    Tuesday, July 08, 2014 2:56 PM
  • This article from a Microsoft employee explains what is happening internally. But that does not help me! I tried capturing the vmswitches, vmadapters, physical adapter but I don't quite understand what is happening! I am quite certain this is because they didn't think of this scenario when implementing the new wifi-feature in windows 8. Hence, I believe I discovered a bug.
    Wednesday, July 09, 2014 8:24 PM
  • Hi,

    It is not a bug .

    As the article mentioned , the NIC need to be in promiscuous mode .

    But not all wireless NICs support this mode (at least my wireless NIC doesn't support this mode ).

    I think it is due to hardware compatibility .

    Best Regards

    Elton Ji


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

    Monday, July 14, 2014 3:52 PM
  • Hi Elton,

    no, the article explains that it's impossible to have a wireless NIC in promiscious mode. To work around this limitation, they implemented the network bridge with the "Microsoft MAC Bridge" which works as an ARP proxy.

    I can prove, that my interface receives the packets, but the network bridge, or something in the middle, discards them, instead of forwarding them to the VM.

    Monday, July 14, 2014 4:15 PM
  • Hi,

    In that article I read this :

    " This is supported on wired physical NICs (by putting the NIC in promiscuous mode), but not supported on wireless NICs since the wireless channel established by the WiFi NIC and its access point only allows Ethernet packets with the WiFi NIC’s MAC address and nothing else. In other words, Hyper-V couldn’t use WiFi NICs for an external switch if we continued to use the current virtual switch architecture."

    Based on my understanding , the prerequisite of external virtual switch is physical NIC supports promiscuous mode . The blogger's opinion is that wireless NIC do not support promiscuous mode ,so the workaround "mac bridge " arises .

    (but "microsoft MAC Bridge" is designed by microsoft to support creating external Vswitch on these wireless NIC which doesn't support promiscuous mode , so I think it is not a bug , it is by design ).

    Also we have not yet tested with a wireless NIC which supports promiscuous mode .

    "In computer networking, promiscuous mode or promisc mode is a mode for a wired network interface controller (NIC) or wireless network interface controller (WNIC) that causes the controller to pass all traffic it receives to the central processing unit (CPU) rather than passing only the frames that the controller is intended to receive. "

    http://en.wikipedia.org/wiki/Promiscuous_mode

    Best Regards

    Elton JI


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

    Tuesday, July 15, 2014 5:29 AM
  • The blogger's opinion is that wireless NIC do not support promiscuous mode ,so the workaround "mac bridge " arises .

    (but "microsoft MAC Bridge" is designed by microsoft to support creating external Vswitch on these wireless NIC which doesn't support promiscuous mode , so I think it is not a bug , it is by design ).

    The Blogger is Mathew John, Hyper-V program manager. He writes that promiscous mode "is supported on wired physical NICs, but not supported on wireless NICs since the wireless channel established by the WiFi NIC and its access point only allows Ethernet packets with the WiFi NIC’s MAC address and nothing else".

    Later on he writes: "For the end user who is creating an external network, the workflow is the same whether you select a wired or a wireless NIC." But that is not the case! Applying the NIC workflow to a WNIC causes the virtual network to act funny, dropping packets and losing a big part of its connectivity.

    You write that you "think it is not a bug, it is by design". That is the opposite of the beforementioned quote from Mathew. That it's by design that the Network Bridge (or the vswitch) is dropping packets that are supposed to get to the servers withing the virtual network.

    Tuesday, July 15, 2014 6:21 AM