[Bug 205156] [Hyper-V] NICs' (hn0, hn1) MAC addresses can appear in an uncertain way across reboot

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205156

            Bug ID: 205156
           Summary: [Hyper-V] NICs' (hn0, hn1) MAC addresses can appear in
                    an uncertain way across reboot
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: decui at microsoft.com

FreeBSD VMs  of 10.2 and the head with multiple NICs (e.g., 2 NICs) have such
an issue: 

occasionally hn0 and hn1 can swap their MAC address!

e.g., normally we have this

[root at decui-bsd102 ~/bsd.git/sys]# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
hn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=31b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,TSO6>
        ether 00:15:5d:4c:a1:06
        inet6 fe80::215:5dff:fe4c:a106%hn0 prefixlen 64 scopeid 0x2
        inet 10.156.76.89 netmask 0xfffffc00 broadcast 10.156.79.255
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
hn1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=31b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,TSO6>
        ether 00:15:5d:4c:a1:0f
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

But sometimes, after a VM reboot, hn0's MAC can become 00:15:5d:4c:a1:0f and
hn1's can become 00:15:5d:4c:a1:06.

This causes confusion to users.

This issue was discussed in
http://www.cluster21.comdex.phpw.opensubscriber.com/message/freebsd-net@freebsd.org/17554434.html

I thought the host could enumerate the NIC devices to the VM in an
unpredictable way, but I was wrong: the fact is that: if the VM's devices in
the Hyper-V Manager's Setting remain the same, the order in which the host
enumerates the devices should be the same.

Later I found a race condition in the VM's VMBus driver code and as a result,
the "second" 
 NIC device can be firstly registered, as hn0.

I'm making a patch for this.

-- 
You are receiving this mail because:
You are the assignee for the bug.